WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jared Smith
Date: Jul 25, 2018 12:17PM

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