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

Hi Mallory,

I'd slightly modify your statement to ensure that the information being
gathered is about *the end user* and not 3rd-party user data (aka *I* am
filling out a form, and one of the inputs would be looking for the First
name of my colleagues - that input would be out of scope, as the
requirement is tightly scoped to the end user only).

So, I cannot imagine a scenario where the problem statement you are
articulating would exist. Can you point to sample code / an example page to
better illustrate the potential issue you are raising?

JF

On Thu, Nov 1, 2018 at 11:08 AM, Mallory < <EMAIL REMOVED> > wrote:

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


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