WebAIM - Web Accessibility In Mind

E-mail List Archives

WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: Mark Rogers
Date: Oct 19, 2018 2:02PM

It's worth considering what browsers do with autocomplete in this case disregarding the AT angle. I think this helps clarify the issue

Current-password
If you're an administrator using a user management interface on http://admin.example.com the browser has already stored your password for admin.example.com. If you, the administrator, is adding new users you definitely don't want *your admin password* being autofilled into a password field for *another user*.

CC-number
The same issue applies to credit card numbers - you definitely don't want *your credit card number* being autofilled into a credit card field for *another user*

There are similar privacy / security issues with the other user data fields since by definition they deal with personal data. I think this points to the autocomplete attribute being strictly reserved for the user's own personal data.

Best Regards
Mark

--
Mark Rogers - <EMAIL REMOVED>
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL


On 02/10/2018, 17:58, "WebAIM-Forum on behalf of Jared Smith" < <EMAIL REMOVED> on behalf of <EMAIL REMOVED> > wrote:

> >(imagine an online HR form that collects multiple "First names").
>
> As a manual tester, should each of these get the "given-name" and or some with "additional-name" even though there may be more than one of each of these

I'm not sure. This is why John presented this as an edge case. It can
be difficult to know *which* autocomplete values are correct in this
case. By a strict interpretation, it's a failure if all of the first
name fields don't have an autocomplete attribute value, and it's also
a failure if an incorrect autocomplete value is defined (such as
given-name or additional-name for more than one field?).

> and if they are present is that a pass even if in practicality any AT/browser/software which would be assisting someone wouldn't know the differentiation either (the label string would have to do that)?

This is precisely the problem. If the end user relies on the
autocomplete attribute to guide their browser or software to complete
the form, and if the autocomplete values are ambiguous (e.g., multiple
given-name or additional-name), then it could actually lead to errant
input, even if interpreted to be WCAG conformant.

Jared