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 10:08AM

So again I'm not caring about the autocomplete-action part. As a tester,
I never test autocomplete's actually filling in of fields because that's
never within my scope of work.
I'm going to take this original statement:
"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)."
as a "yes, true" until I hear otherwise. That all fields that *could*
match a current value listed in the autocomplete taxonomy need to have
one, even if for whatever (assuming valid) reason that were duplicated
(more than one field with the same autocomplete value, rather than being
left un-autocompleted).
cheers,
_mallory


On Thu, Nov 1, 2018, at 2:08 PM, John Foliot wrote:
> 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[1]
>


Links:

1. http://deque.com/