WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: John Foliot
Date: Nov 1, 2018 11:31AM

Hi Jared,

Yes, I think that *is* an edge case, but OK...(apologies for the long
response - there are two issues at play here)

ISSUE ONE:

> Giving all of these fields an autocomplete attribute would lend itself
to incorrect entry.

...or, if I was completing the form at my local library, NONE of the inputs
would be correctly entered, because *that* user-agent would most likely NOT
be configured to actually supply the specific values associated to ME as
the end user.

As I previously mentioned to Mallory, this SC is tightly scoped to just the
user. *It is critical that people stop thinking about this SC simply in
terms of outcomes*, but rather about meeting the language of the SC: that *the
purpose of the input* can be programmatically determined by a machine -
FULL STOP.


The WCAG requirement mandates the purpose of the input can be
programmatically determined, and NOT that user agents then do something
magic with that information. That's a desired goal or outcome, but the SC
simply states <https://www.w3.org/TR/WCAG21/#identify-input-purpose>:

The purpose of each input field collecting information about the user can be
programmatically determined
<https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable> when:

- The input field serves a purpose identified in the Input Purposes for
User Interface Components section
<https://www.w3.org/TR/WCAG21/#input-purposes>; and
- The content is implemented using technologies with support for
identifying the expected meaning for form input data.


*Today*, the only *valid* technique to make form inputs "programmatically
determinable" is to use the @autocomplete attribute and one of the fixed
value tokens <https://www.w3.org/TR/WCAG21/#input-purposes> that are
reserved for the attribute (those fixed token values being the means by
which machines can THEN determine the purpose of the input). In the context
of internationalization, a North American password manager that can also
populate form inputs
<https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research> may
not know what 住所 means, but if coded correctly it will always know what
"street-address" means:

<label> 住所: <input name="青い贈り物を" autocomplete="street-address"> </label>


That's because the token "*street-address*" has been unambiguously defined
as a taxonomy term, so machines can 100% be sure of what the input value
string should be (and/but NOT then what to do with that information).

Looking at it another way... SC 1.1.1 requires "*All non-text content that
is presented to the user has a text alternative that serves the equivalent
purpose...*", and not "All images require alt text (using @alt)" - as using
@alt is but one technique today that we can use to meet that requirement.
Thus, we don't just test for the presence of @alt alone - we test instead
for the presence of "... *a text alternative that serves the equivalent
purpose*", of which there are now multiple techniques available to the page
author (but that was historically not always the case).

The Personalization Task Force at the W3C is however looking at other
possible mechanisms for making inputs and other page-level
components/elements "programmatically determinable". There is work on
an expanded
taxonomy <https://www.w3.org/TR/personalization-semantics-1.0/>, as
well as investigations
into different mechanisms
<https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content>
that may be used to achieve the same larger goal: attaching semantic
metadata to page-level components and elements.

For example, as a straw-man proposal, we're investigating minting a new
HTML 5 attribute (@purpose) which, if approved (and we're a long way from
that today) could also serve as an alternative technique:

<label> 住所: <input name="青い贈り物を" purpose="street-address"> </label>

(TO BE VERY CLEAR: THIS IS A PROPOSAL AND NOT AN APPROVED TECHNIQUE TODAY.)

...and so, the pass/fail determination isn't about outcomes, but rather
whether or not the code is constructed in such a way so that the purpose of
the input can be machine-determined, *and nothing more*. Lack of envisioned
future functionality and outcomes today is not, in-and-of-itself a reason
to fail a page on this SC.

(And for those who may ask... because the @autocomplete technique *does*
apply magic *some of the time* - if the end user has configured their
user-agent to support the technique - browsers today CAN programmatically
determine the input purpose and subsequently autocomplete the field inputs.
Because we were able to demonstrate *that *fact is how this SC got through
the W3C process.)


ISSUE TWO:

> the form has several fields where the user is asked to enter all of
their known "given" or "first" names - any name by which they may be known.

In that context, I would surmise that yes, if there were say, three inputs
that were all looking to collect the same "larger" piece of information
about *ME* (Name, Alt-Name1, Alt-Name2, etc.) I'd likely expect that all
three inputs would have an autocomplete attribute with a token value.

Personally I'd envision the "First" input to be tagged as *given-name*,
with subsequent inputs tagged as possibly *additional-name* or
*nickname. *Neither
HTML5's @autocomplete definition, nor WCAG 2.1's appropriation of the
attribute to achieve a higher-level outcome, is specific about whether or
not multiple identical token values are valid or "legal", and so from a
testing perspective I think today it's a value judgement.

In the use-case you've presented, the user only has one legal "given name"
(what's on their birth certificate or passport) even if they have multiple
aliases or nicknames, so I'd expect something like this:

<fieldset><legend>Names by which you may be known</legend>

<label> Legal name <input type="text" name="name"
autocomplete="given-name"></label>

<p>AKA (Also Known as)</p>
<label> Other name <input type="text" name="nickname1"
autocomplete="nickname"></label>
<label> Other name <input type="text" name="nickname2"
autocomplete="nickname"></label>
</fieldset>



I agree that at this level of granularization, we currently lack a
mechanism to 'programmatically' separate one nickname from the other, but
in the context of SC 1.3.5, all of the above inputs *ARE* programmatically
determinable, they are all collecting information about *ME*, and so I'd
pass my own code example <grin> based solely on the language of the SC:

"The *purpose *of each input field collecting information about the user
can be programmatically determined
<https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable>..."


HTH

JF

On Thu, Nov 1, 2018 at 11:47 AM, Jared Smith < <EMAIL REMOVED> > wrote:

> John -
>
> If I'm understanding the issue correctly, here's a scenario (though,
> admittedly, a bit of an edge case)...
>
> Someone is completing an online form to request a background check and the
> form has several fields where the user is asked to enter all of their known
> "given" or "first" names - any name by which they may be known. Giving all
> of these fields an autocomplete attribute would lend itself to incorrect
> entry. But NOT giving all of the fields autocomplete would be a WCAG
> failure. So which is the proper approach?
>
> Jared
> > > > >



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