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 29, 2018 12:34PM

Hi Jon,

Spot on. In both of your examples, heuristics *could* perhaps make accurate
predictions for end users, whether predicting the language of the page, or
accurately pairing a label to an input... maybe, but also maybe not. (We
can point to YouTube auto-captions as another example where machine
guessing also fails the end user as often as not)

But by being explicit, authors remove any ambiguity, which, as you noted in
reference to the language SC's, is one of the primary goals. The human user
rarely if ever *sees* <html lang="en"> (usually only machines do), but the
benefits derived by that Requirement DOES benefit end-users, and meeting
those SC has proven to be beneficial over-all.

Related to SC 1.3.5, I think much of the confusion is due to the fact that
we are looking to re-purpose a concept that HTML5 originally solved (how to
attach a more granular definition of an input's purpose) to allow us to do
more for the end user: speed the filling of those inputs, yes, but also,
because that more granular purpose is encoded in the code, reliably perform
other functions leading towards page modifications (different modalities)
i.e., Personalization. (For example, using [autocomplete="password"] as a
CSS Selector.)

And while indeed using the autocomplete attribute technique is the
preferred method going forward, the SC language is careful to not prescribe
that, instead requiring the functional outcome of these more granular
definitions be programmatically determinable, while leaving open the
possibility of other techniques to emerge.

JF


On Jul 28, 2018 7:34 PM, "Jonathan Avila" < <EMAIL REMOVED> > wrote:

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
> > > >