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 27, 2018 8:30AM

John -

Thank you for the detailed explanations. As I promised, I won't
belabor the discussion about the language further. The fact it's taken
such a lengthy conversation for you to explain the language and nuance
of this success criterion to me should hopefully be a good indication
of how difficult this will be for us to explain to others.

> the goal of this SC is NOT to make forms easier to fill out, but
> rather for machines to understand

> Please stop thinking of this as a human-consumable requirement,
> it isn't, it's for machines to do something with.

These statements pretty much sum up my disappointment in all of this.
WCAG would now demand 100% non-ambiguous perfection for machines in
situations where the field purpose is already fully understood by and
accessible to end users. It favors the machine over the human, and
does so by burdening human authors.

I do hope there will be consideration for a sufficient technique for
basic forms where informative form labels are used (which, as Jonathan
noted, is already required by 2.4.6). Every form filler can (or
readily could) support with very high levels of accuracy the
identification of input purpose for the majority of forms on the web
(username/password, basic registration forms, shipping details, etc.).

As an example, I took your example form
(http://john.foliot.ca/demos/autofill.php) and removed all
autocomplete attributes. With my form filler, the results were nearly
identical both with and without the attributes. Without the attributes
it didn't fill in "sex" (but does work with "gender") and "Telephone:
Country Code" was filled with country name rather than code - both
readily fixable with minor improvements to the text parsing in the
form filler. In short, @autocomplete provided almost no added benefit.

Now I fully understand your argument about fields where the purpose
may be ambiguous or non-standard, that do not have common, informative
label values, or are in a language where user agents do not yet
properly parse the field labels. Certainly autocomplete would be
useful here. But these are the exception, not the norm. And shouldn't
the burden here be more on the user agent to support these fields
rather than the author to add extra code?

Web forms that are currently properly parsed by form fillers (i.e.,
are "accessibility supported"), are WCAG 2.0 conformant, and are fully
accessible to end users are now non-conformant with WCAG 2.1 AA
because they lack an attribute that is intended to tell the machine
something it has already accurately surmised from the label. To become
2.1 conformant the authors of these forms are now required to add code
that would thus do nothing to improve accessibility for end users.

Thanks,

Jared