Re: What is a failure of 1.3.5 Identify Input Purpose?

> Which AT does Success Criterion 1.4.1 Use of Color depend on? SC 2.2.2
Pause, Stop, Hide? SC 3.2.1 On Focus?

The Accessibility support conformance requirement doesn't mean an SC *has* to
depend on AT. Techniques used to meet those SCs don't rely on AT so they
pass accessibility support conformance requirement by default.
Accessibility Support simply means that if a technique (relied upon to meet
an SC) depends on AT, then there has to be AT that actually works with that
technique.
The techniques used to meet the "Identify Purpose" SCs depend on AT, and
therefore have to be accessibility supported.

Maybe in the future, Silver will remove this conformance requirement. But
this is WCAG 2.0 (and 2.1) as its written and has been understood for 10
years. Is there anybody who disagrees with that?
https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Sat, Jan 19, 2019 at 1:32 PM John Foliot <john.foliot@deque.com> wrote:

> David writes:
>
> *But that is not WCAG, which requires that conforming techniques work with
> the AT and the browsers which are depended upon for conformance.  *
>
> Respectfully David, that is an extremely narrow definition of WCAG, and
> one that (I think) flies in the face of logic. Which AT does Success
> Criterion 1.4.1 Use of Color depend on? SC 2.2.2 Pause, Stop, Hide? SC
> 3.2.1 On Focus?
>
> I can find numerous examples of existing 2.0 AND 2.1 SC that do not depend
> on Assistive Technology, and apply to more than just "browsers" (We have an
> entire collection of Techniques for PDFs (that natively open in Acrobat
> Reader, or in your browser *via an extension*); and WCAG - especially WCAG
> 2.1 - is being applied to "Native" Mobile Apps that may or may not require
> a "browser"). The normative definition of Accessibility Supported is:
>
> *Using a technology in a way that is accessibility supported means that it
> works with assistive technologies (AT) and the accessibility features of
> operating systems, browsers, and other user agents.*
>
> ...and...
>
> *Note 2: Assistive technologies often communicate data and messages with
> mainstream user agents by using and monitoring APIs.*
>
> Additionally, I'll re-quote the statement you provided:
>
> "... the Success Criteria require *that something be done in the Web
> content* that would make it possible for assistive technologies to
> successfully present the content's information to the user. "
>
>
> NOT "...guarantee accommodation...", but rather, "...make it
> possible...".
>
> Microdata <https://www.w3.org/TR/microdata/> (the example I provided)
> *IS* a formally published W3C Recommendation, and it *DOES* have consuming
> user-agents and the required API's.  From the Microdata Overview
> <https://www.w3.org/TR/microdata/#overview>:
>
> *For example, search engines can better identify page content using
> schema.org <http://schema.org> annotations, and content management systems
> can find and use information from documents, if it is marked up in a known
> way. *
>
>
> So, from a pure-play technical reading of the Recommendation, it *DOES*
> meet all of the criteria, yet today it doesn't have a 'porting' mechanism
> (perhaps a specialized CMS, or maybe a proxy web site interface that
> ingests marked-up pages at one end, and outputs modified content at the
> other) that actually aids end users (a point I also acknowledged). But
> that's not because the technology eco-system is flawed, but rather not all
> of the gaps have been filled.
>
> Returning to my statement, I'd never "recommend" a page or other marked-up
> content use this technique today (due to the lack of real support), but I'd
> also come-up short in actually "failing" the page or content *IF* all of
> the technical requirements are met, specifically: "The content is *implemented
> *using technologies *with support for identifying the expected meaning*
> for form input data.
> <https://www.w3.org/TR/WCAG21/#identify-input-purpose>" Like it or not,
> Microdata, when implemented, *DOES* support the ability to identify the
> expected meaning. Today, I will suggest, it's not just being leveraged in a
> way that is consistently useful in our context of assisting PwD, but I do
> not believe we could fail it (from a legal conformance reporting
> perspective).
>
> JF
>
> On Sat, Jan 19, 2019 at 11:05 AM David MacDonald <david100@sympatico.ca>
> wrote:
>
>> > if an organization wanted to publicly publish the taxonomy in a more
>> robust format (hello Schema.org), then there is no technical reason why
>> using, say, Microdata to achieve the goal would not be conformant. It might
>> not actually *DO* anything at this time (lack of tooling), but the fairly
>> robust if 'wordy' Microdata syntax and mechanism would not be a fail - *IF
>> it referenced a publicly published taxonomy library that matched the values
>> in Section 7.*
>>
>> I would not pass something that is not accessibility supported.
>> "... the Success Criteria require that something be done in the Web
>> content that would make it possible for assistive technologies to
>> successfully present the content's information to the user. "
>>
>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
>>
>> I understand in Silver there is a proposal to change this and to move to
>> a more standards based approach where everybody builds to the standard and
>> if the AT or Browsers don't do their part then it still passes. But that is
>> not WCAG, which requires that conforming techniques work with the AT and
>> the browsers which are depended upon for conformance. WCAG 2.0 requires
>> real world current benefit to users rather than an aspirational hope that
>> something will happen in the future with an SC. WCAG SCs for 2.0 were not
>> created with the "build it and they will come" approach although this 2.1
>> SC starts to hint in that direction.
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613-806-9005
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>
>>
>>
>> *  Adapting the web to all users*
>> *            Including those with disabilities*
>>
>> If you are not the intended recipient, please review our privacy policy
>> <http://www.davidmacd.com/disclaimer.html>
>>
>>
>> On Fri, Jan 18, 2019 at 1:38 PM John Foliot <john.foliot@deque.com>
>> wrote:
>>
>>> Ha, Part 2...
>>>
>>> I think Josh the answer is far more nuanced than that.
>>>
>>> A "Failure" would be a form - scoped to the *user *(and not, say to the
>>> user's family[1], or work colleagues[2]) - that had inputs that correspond
>>> to the values identified in the chart found in Section 7 of the WCAG
>>> 2.1 Recommendation <https://www.w3.org/TR/WCAG21/#input-purposes>.
>>>
>>> The failure is when any of the corresponding 'required' inputs do not
>>> contain a *metadata taxonomy term *attached to the <input>... however
>>> the *mechanism* by which that is accomplished cannot be specified in the
>>> Recommendation (as you likely know), because 'techniques' are
>>> non-normative, and WCAG leaves open the possibility of more than one
>>> potential solution/technique.
>>>
>>> The testing technique then is dependent (today) on manual code
>>> inspection, where you must examine each <input> (again, scoped exclusively
>>> to the actual user, and on the list of required inputs found in Section 7)
>>> to see if the taxonomy concept/term has been *programmatically
>>> attached.* As I noted in my previous response, today the only fully
>>> 'robust' technique would be to use @autocomplete, but if an organization
>>> wanted to publicly publish the taxonomy in a more robust format (hello
>>> Schema.org), then there is no technical reason why using, say, Microdata to
>>> achieve the goal would not be conformant. It might not actually *DO*
>>> anything at this time (lack of tooling), but the fairly robust if 'wordy'
>>> Microdata syntax and mechanism would not be a fail - *IF it referenced
>>> a publicly published taxonomy library that matched the values in Section 7.* (Part
>>> of being machine-readable is that the machines might need to actually look
>>> up what it is they are reading...)
>>>
>>> [1] A question was posed about *booking airline tickets for you and
>>> your family*. In that instance, the only inputs that would require
>>> the @autocomplete values (or other technique) would be those values
>>> associated to *YOU* - and not to the other members of your family, for
>>> while they may share many of the same 'responses' (i.e. family-name...
>>> maybe, maybe-not: today's nuclear family taking so many different forms),
>>> however those inputs are scoped to other members of the family, AND NOT THE
>>> USER, so there is no need to tag those additional inputs.
>>>
>>>
>>> [2] A similar scenario was queried, where *a "HR" form was collecting
>>> multiple names and address* (i.e. there may be a total of 20 on-screen
>>> inputs labeled "Name"), but again, because this SC is scoped to the *USER*,
>>> then potentially only the input directly related to the user
>>> (owner/completer of the form) would require the metadata, as all of the
>>> other date inputs are scoped to "others".
>>>
>>>
>>> And when you think about it from the "functionality of the @autocomplete
>>> attribute", it's fairly safe to assume that most (not all) browser
>>> configurations, *if the user has opted to store any personal data for
>>> speedier form completion on their local user-agent in the first place*,
>>> would liekly only store data relate to them, and not to their family
>>> members, neighbors or work colleagues. (Currently neither Edge nor Internet
>>> Explorer support the @autocomplete 'functionality' in any fashion, and in
>>> fact the most robust tool supporting the @autocomplete tokens was the Last
>>> Pass password management tool.)
>>>
>>> Additionally, I think it's fairly safe to presume that public terminals
>>> WOULD NOT have this kind of personally identifying data stored locally on
>>> those machines, so in that scenario, the "auto-filling" function would be
>>> disabled (or at least, unable to deliver on the functionality, due to the
>>> lack of stored local data). None-the-less, *OUR* *accessibility value*
>>> is primarily that those form inputs are now tagged with extra metadata that
>>> is machine-readable, and what and how we use that additional information is
>>> now open to tooling (etc.)
>>>
>>> To be clear, while using the @autocomplete attribute solution extends
>>> some real benefit for all users (including the target audience that
>>> inspired this SC - COGA), the 'auto-filling' of those inputs is but one
>>> function *facilitated by adding specific metadata terms to inputs*. And
>>> while SC 1.3.5 is currently only for inputs, that isn't the end of the
>>> story, it's but Chapter 1, and hopefully we'll get more and better tools
>>> and methods to meet the much larger goal of allowing users to customize
>>> their UI (How? when we know the purpose and intent of all of the visual
>>> controls on the page, we can then "output them indifferent modalities" to
>>> meet the needs of the end user - i.e. Personalization)
>>>
>>>
>>>
>>> *HTHJF*
>>>
>>> On Fri, Jan 18, 2019 at 5:22 AM Joshue O Connor - InterAccess <
>>> josh@interaccess.ie> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Are we saying that a well marked up form that does not have a HTML 5.2
>>>> autocomplete attribute (or similar) is basically a fail of this SC? [1]
>>>>
>>>> Thanks
>>>>
>>>> [1]
>>>> https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html
>>>> --
>>>> Joshue O Connor
>>>> Director | InterAccess.ie
>>>>
>>>
>>>
>>> --
>>> *​John Foliot* | Principal Accessibility Strategist | W3C AC
>>> Representative
>>> Deque Systems - Accessibility for Good
>>> deque.com
>>>
>>>
>
> --
> *​John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>