WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: John Foliot
Date: Oct 21, 2018 9:00AM


To answer Jared's question, this SC is scoped to the *end user* only, and
not to extended family, friends or work colleagues. The SC states:

"The purpose of each input field collecting information about -> the user
<- can be programmatically determined
<https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable> ..."

In the case of a web-form used to collect names and addresses of multiple
names, the page author does not need to attach this metadata to each
repeated field, as the data (names, addresses, etc.) being collected is
about *other* people. If however there was also a field that collected the
name of the person that was collecting the data about others (aka "Bob"
fills out a new form every day at work, as a hotel receptionist) THEN the
field that collected *his* data would require the attribute.

Additionally, while currently the only technique available to meet this SC
is to use the autocomplete attribute, there is zero expectation that all
user-agents will be configured to always automatically be storing the
requisite values (think a kiosk computer in a public library). None the
less, by attaching this element level meta-data to the form inputs, it
continues to make those inputs machine understandable, allowing for
representation in different modalities, which was the higher-level goal of
this SC. The fact that browsers today can store values associated to the
user, and then pattern-match those values to the appropriately tagged
inputs is but one example of the machine unambiguously "knowing" what to do
with any given field, because it's Purpose can be Programmatically
Determined.

HTH

JF

On Fri, Oct 19, 2018, 10:02 PM Mark Rogers < <EMAIL REMOVED> >
wrote:

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