WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: chagnon@pubcom.com
Date: Jul 27, 2018 9:24AM


Agee with Jared, quoted below:
" It favors the machine over the human, and does so by burdening human
authors. "

Which nimrod turned accessibility around to now make machines happy, rather
than the people who use machines? Is this why we're all here?

Flip around the focus: we should figure out how to make content work better
for people, and then program the machines to provide the content in the way
it's needed.

Accessibility is for people, not for machines.

--Bevi Chagnon
- - -
Bevi Chagnon, founder/CEO | <EMAIL REMOVED>
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Jared
Smith
Sent: Friday, July 27, 2018 10:30 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] WCAG 2.1 - 1.3.5 - How to capture a violation?

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
http://webaim.org/discussion/archives