WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: Mallory
Date: Nov 1, 2018 3:07AM

For example, people in my family have two given names (one is called a "christian name" or a "baptism name" and the other is called a "call name" which is the name people actually use most of the time, and is not the same as a nickname), and my usual beef with metadata is how it's never going to cover enough to meet more than a typical American usage despite being needed worldwide across cultures.

So it looks like, as a manual tester, if there are multiple given-name fields they all just need the given-name value and while no AT that layers on emojis or whatever will be able to separate them because there's no metadata difference between multiple types of given names, I should pass a site that simply labels them all the same and fail a site that labels one but not the other, and the suggested remediation for such a site is to add in the given-name value to the other given name fields (in this example using multiple given names).

Do I have this correct? I was never asking about other peoples' given names on the same form, but the example of a form that asks for, example, all of a single users' given names.

cheers,
Mallory

On Sun, Oct 21, 2018, at 4:00 PM, John Foliot wrote:
> 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
> > > > > > > > > >
> >
> > > > > > > > > >
> > > >