WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 - 1.3.5 - How to capture a violation?

for

From: John Foliot
Date: Jul 25, 2018 12:56PM

Respectfully Jared,

I disagree with your reading and understanding. The SC states:

*"The purpose of each input field collecting information about the user can
be programmatically determined when:..."*


...where programmatically determined has been Normatively defined as:

*programmatically determined (programmatically determinable)*


*determined by software* from author-supplied data provided *in a way that
different user agents*, including assistive technologies, *can extract and
present this information to users in different modalities*

For example, Jon has shared his favelet/bookmarklet, which exposes the
values on screen (as opposed to "filling in the form"), and I have
(awaiting packaging) a Chrome extension that takes the @autocomplete values
and injects icons to supplement text labels​ associated to the various
inputs. Both of these functions work because no matter what you as an
author has supplied as the text label (Accessible Name), the machine
readable token remains constant for the software to determine.

For user agents to be able to determine what the input is seeking, it needs
to be working from a fixed list. If I label an input *Số thẻ tín dụng *for
example, how will software understand that? But if I also programmatically
link the accessible name (*Số thẻ tín dụng*) to a machine-understandable
value (cc-number), *THEN* machines can start to figure it out as well and
"....
extract and present this information to users in different modalities
​" (such as the two examples I mentioned).*​*

​​
Again, the main beneficiary of this SC is actually machines (Perceivable -
1.x.x SC), as opposed to end-users (Understandable 3.x.x SC), which is why
the
​A
ccessible
​N
ame alone is insufficient.

I agree this is less than clear or obvious in the Understanding
documentation today, and I have taken this as an action item at the W3C to
revisit the Understanding document to ensure that it reflects the real
intention of this SC beyond a dry reading of the SC text that seems to be
forming your (and other's) interpretation.

JF

On Wed, Jul 25, 2018 at 1:17 PM, Jared Smith < <EMAIL REMOVED> > wrote:

> John Foliot wrote:
>
> > The "gain" here is actually more visible in non-english content,
> > where the accessible name would be localized for the language of the
> page.
> >
> > <label for="ThisInput">Почтовый индекс</label> <input type="text"
> > id="ThisInput" autocomplete="postal-code">
> >
> >
> > No matter what the language of the label text is, the "machine-readable"
> > bit is clearly "postal-code", which is unambiguously defined here:
> > https://www.w3.org/TR/WCAG21/#input-purposes
>
> Yes, using autocomplete is a fantastic idea here, but the SC simply
> does NOT require alignment with a "machine-readable" taxonomy or that
> an unambiguous definition be provided. It only requires that "the
> purpose... can be programmatically determined" (I'm quoting the SC
> directly here).
>
> In your example, the purpose of the field is clearly available and
> associated to the field via the label. So why would the autocomplete
> attribute be required in addition to this? Nothing in the SC suggests
> that anything more than associating the purpose is necessary. If the
> label is somehow not "determinable" here because it happens to be in
> Russian, then how could the exact same label be "determinable" to meet
> 1.3.1 and 3.3.2?
>
> > Currently, the "taxonomy list" being used is in fact that normative list
> of
> > values and definitions that *is* the autocomplete values, and as others
> > have noted, currently the 'best' technique is to use @autocomplete to
> > attach the meta-data term to the input field.
>
> Right. This is the certainly the "best" technique. But is an
> accessible name NOT an acceptable technique?
>
> If it's not, the only other way I can contort my mind to get to this
> interpretation from the SC text is to change the meaning of "purpose"
> to mean "purpose as defined by a machine-readable,
> language-independent taxonomy" (which would be very different than
> "purpose" as used in 1.1.1, 2.4.2, and 2.4.9) or to interpret
> "programmatically determined" very differently here than anywhere else
> in WCAG. I don't think I could be supportive of either of these
> contortions.
>
> Jared
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion