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: Nov 1, 2018 7:08AM

Hi Mallory,

> 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


I think you may be over-thinking this a bit. For one, I've never myself
seen a form which asks for both your "christian name" *AND* your "common
name": I've seen a form that asks for your "Family name" and your "First"
name many times however. (I won't rule out the possibility, but it seems
extremely edge-case)

I'm going to try and put this in context... I live in Texas, where
currently there is a strong political campaign between "Rafael Edward Cruz"
and "Robert Francis O'Rourke".

If either candidate was filling out a legal form (apply for a passport, get
a drivers license, do their taxes) they would use their Christian Names,
and likely not their "common" names of Ted Cruz and Beto O'Rourke. But if
they were signing up for the Daily Dose of Dumb (an online political blog),
perhaps they might use those common names instead - this is your concern,
correct?


My suspicion is that *IF* they take advantage of the feature to store
"Name" information on their user-agent (and remember, there is no
REQUIREMENT for users to do so, and in my test suite I have more than one
browser where I have deliberately chosen to NOT store that data) then
either person would choose the name *they* want to be known by most often,
and as content creator, that should be good enough for me.

In either case, an input of < input type="text" id="name"
autocomplete="first-name"> will be populated by the First Name *CHOSEN BY
THE END USER* - so if one of those men wants me to know them officially as
Robert (instead of Beto) why should I care? *The *accuracy* of the data
supplied in the form remains the responsibility of the end user, not the
content author.* (Additionally, I will note that not all "nicknames" need
to be humorous or unusual: "Ted" is the nickname for Edward, Jon is often
the nickname of Jonathan, Bob is a nickname for Robert (as is, in the case
of the other candidate, "Beto" as well - shortened from Roberto) - heck, in
some territories, Jack is a nickname for John...)

Returning back to this, in the context of SC 1.3.5... The intention is NOT
to ensure that the autocomplete function *ALWAYS* works (it can't - think
public terminals), but rather that *the input is marked up with a logical,
persistent and consistent metadata term, making the input machine
understandable*. Whether the end user chooses to supply "John" as their
first name, or "Ozzy" (as in John Michael "Ozzy" Osbourne) is something of
a red herring: mark up the input as "first-name" and let Ozzy decide what
he wants his "first-name" to be...

HTH

JF



On Thu, Nov 1, 2018 at 4:07 AM, Mallory < <EMAIL REMOVED> > wrote:

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



--
*​John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com