WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jeremy Echols
Date: Jul 27, 2018 3:39PM

I think ambiguity is a slippery thing to define in any kind of normative way. Better to just say "here's a list of terms that are always known to mean a specific thing". With a clearly defined taxonomy, you don't have to build any kind of AI to guess at fields, so the programmatic use of these fields is open to a much wider audience, which can be useful.

That said, "autocomplete" feels very wrong for this purpose. I feel like this should be a new attribute, like aria-purpose or something.

It also seems like this SC should have been rolled out slowly, especially given how much confusion it's generated. I could see this as a AAA failure with some intent to make it higher priority in the future. Those of us targeting AA are going to immediately fail without another massive audit we weren't prepared for. It may even simply put off some authors entirely, and cause them to say, "AA is getting too difficult; let's just support WCAG A", which is a major loss.

I do like the intent behind this, but it's definitely a tricky one.

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

Jeremy -

I absolutely agree. In cases where the purpose of the field is ambiguous, using autocomplete is incredibly helpful and should be required.

But the same software that parses autocomplete="family-name" already knows that <label>Last Name: <input type="text"></label> is the same thing, and thus provides identical functionality when you request help in completing this field? Does it then make sense to require authors to add the autocomplete attribute if it provides no better accessibility?

I'd think it worthwhile to examine this further as a possible sufficient technique, though recognize that this would rely on authors to provide an equivalent label text that is "accessibility supported"
by form fillers (something much more difficult to define than the blanket "autocomplete is required").

I have considered the scenario where the input is for entering someone else's last name. In this case, autocomplete would not be used, yet the form filler would, if activated erroneously, fill it with the user's last name. But this is the current reality anyway. The form fillers already use form labels in their heuristics if autocomplete isn't present (and perhaps even if it is). The only way to avoid this potential issue is for form fillers to ONLY respect @autocomplete, and that certainly is not going to happen - they'd stop working on nearly all web forms (including the ones that passed 2.0, but now fail 2.1 without having changed).

Thanks,

Jared