WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Avila
Date: Jul 28, 2018 6:34PM

This argument is much like the one for the language attribute. Machines can figure out what language is being used and people know the language of the page and their assistive technology therefore why burden authors with setting a language on every page - that only befits machines.

Or why explicitly set form labels as long as the label precedes the form file AT and users can figure that out. Explicit labels for something that is adjacent is a lot of work with page authors.

These are real arguments that have been made against WCAG 2.0.

Jonathan

Sent from my iPhone

> On Jul 27, 2018, at 10:30 AM, Jared Smith < <EMAIL REMOVED> > wrote:
>
> 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
> > > >