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

*Success Criterion 1.3.5 Identify Input Purpose (Level AA)
<https://www.w3.org/TR/WCAG21/#identify-input-purpose>: *The purpose of
each input field collecting information about the user can be
programmatically determined when:


   - The input field serves a purpose identified in the Input Purposes for
         User Interface Components section; and
         - The content is implemented using technologies with support for
         identifying the expected meaning for form input data.

David writes:

> ...with support for identifying the expected meaning for form input data.
[JF notes that the SC doesn't say "...and then do something with that
information..."]


Patrick writes:

> ...What can be done *without AT* in terms of identifying the purpose of
the input?


From the Understanding document
<https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html>:

*The intent of this Success Criterion is to ensure that the purpose of a
form input collecting information about the user can be programmatically
determined, so that user agents can extract and present this purpose to
users using different modalities. The ability to programmatically declare
the specific kind of data expected in a particular field makes filling out
forms easier, especially for people with cognitive disabilities.*


(Which also brings us back to the scoping it to the actual user discussion)

   - [Element + machine-readable & parsable metadata] = machine can do
   something with the metadata based upon the value of the metadata
   - [<input> + "purpose"] = machine "knows" (or can know) what the purpose
   of the input is, and can potentially do something with that "knowledge"
   - [<input> + @autocomplete with fixed token value] = browsers can
   auto-fill input values based upon which token is specified
           (2 X independent implementations = exit criteria)

As previously noted however, machines (browsers) *DO NOT* have to autofill
the inputs for this SC to be conformant, as

a) not all browsers support the 'feature' (looking at you Microsoft), and
b) not all browsers are expected to be storing the corresponding values
(public terminals, etc.) associated to the end user, and finally
c) that specific functionality is not part of the SC requirements.

None-the-less, *IF* the author has set the conditions, *THEN* when the
user-configuration is set accordingly, something happens.

YES, this SC has a lot of aspiration behind it, and minimal support today
(*one* technique does "something" that benefits the end user), because it
has been made 'machine-readable' and 'machine understandable'. But we have
the evidence of the SC meeting it's stated goal, and we've cracked the
chicken and egg problem by starting to have developers add metadata to
content at the element level.

Do we want it to do more? Absolutely, but we have to crawl before we can
sprint, and we had to start somewhere. But just like WCAG CANNOT *mandate*
the use of, say, @alt to successfully meet SC 1.1.1, here as well we cannot
mandate the use of @autocomplete to meet this SC; and if an organization
(and we have a few working in this space today) want to build out the
larger tool-sets to support another valid and conformant W3C technology
(like Microdata) to identifying the expected meaning, we cannot "forbid" it
nor "fail" it, because *we don't fail based upon techniques, but on
outcomes*.

In the simplest of terms, the functional outcome expected here is that
inputs are 'tagged' with appropriate metadata so that "the purpose" of the
input can be unambiguously understood by a machine.

Do we need more tooling? Absolutely! But the fact that we have enough
robust support from tools "doing something" with the appropriately tagged
inputs today (and not just browsers BTW, we tested password managers as
well) because they can "...identify the expected meaning..." and then
autofill the inputs, was the justification for this SC passing the exit
criteria. This was discussed at length during the F2F last CSUN, when we
ran these test sprints.

JF


On Wed, Jan 23, 2019 at 8:03 PM David MacDonald <david100@sympatico.ca>
wrote:

> > What AT is required to support the technique for this SC? Serious
> question.
>
> What can be done without AT in terms of identifying the purpose of the
> input and doing interesting things with that purpose envisioned by COGA
> such as inserting icons, swapping out labels, etc. as per the Understanding
> doc. etc....  ?
>
> 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 Wed, Jan 23, 2019 at 4:57 PM Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 23/01/2019 21:51, John Foliot wrote:
>> > Hi David,
>> >
>> > What AT is required to support the technique for this SC? Serious
>> question.
>>
>> Some AT (or UA, or UA extension) that does something meaningful with
>> whatever means of adding "purpose" the author chose?
>>
>> Probably depends on the exact reading of what "support" really
>> means/refers to in
>>
>> "The content is implemented using technologies with support for
>> identifying the expected meaning for form input data."
>>
>> Support in a theoretical "well, it's exposed programmatically by the UA"
>> way, or support in a "and there's some real-world, actually used UA etc
>> that does something with it"?
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com