E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 11 (In chronological order)

From: Mark Rogers
Date: Fri, Oct 19 2018 2:02PM
Subject: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
No previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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

From: John Foliot
Date: Sun, Oct 21 2018 9:00AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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
> > > > >
>
> > > > >

From: Mallory
Date: Thu, Nov 01 2018 3:07AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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
> > > > > > > > > >
> >
> > > > > > > > > >
> > > >

From: John Foliot
Date: Thu, Nov 01 2018 7:08AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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

From: Mallory
Date: Thu, Nov 01 2018 10:08AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of
>> > > = EMAIL ADDRESS 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/

From: John Foliot
Date: Thu, Nov 01 2018 10:37AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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

From: Jared Smith
Date: Thu, Nov 01 2018 10:47AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

John -

If I'm understanding the issue correctly, here's a scenario (though,
admittedly, a bit of an edge case)...

Someone is completing an online form to request a background check and the
form has several fields where the user is asked to enter all of their known
"given" or "first" names - any name by which they may be known. Giving all
of these fields an autocomplete attribute would lend itself to incorrect
entry. But NOT giving all of the fields autocomplete would be a WCAG
failure. So which is the proper approach?

Jared

From: John Foliot
Date: Thu, Nov 01 2018 11:31AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Hi Jared,

Yes, I think that *is* an edge case, but OK...(apologies for the long
response - there are two issues at play here)

ISSUE ONE:

> Giving all of these fields an autocomplete attribute would lend itself
to incorrect entry.

...or, if I was completing the form at my local library, NONE of the inputs
would be correctly entered, because *that* user-agent would most likely NOT
be configured to actually supply the specific values associated to ME as
the end user.

As I previously mentioned to Mallory, this SC is tightly scoped to just the
user. *It is critical that people stop thinking about this SC simply in
terms of outcomes*, but rather about meeting the language of the SC: that *the
purpose of the input* can be programmatically determined by a machine -
FULL STOP.


The WCAG requirement mandates the purpose of the input can be
programmatically determined, and NOT that user agents then do something
magic with that information. That's a desired goal or outcome, but the SC
simply states <https://www.w3.org/TR/WCAG21/#identify-input-purpose>:

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

- The input field serves a purpose identified in the Input Purposes for
User Interface Components section
<https://www.w3.org/TR/WCAG21/#input-purposes>; and
- The content is implemented using technologies with support for
identifying the expected meaning for form input data.


*Today*, the only *valid* technique to make form inputs "programmatically
determinable" is to use the @autocomplete attribute and one of the fixed
value tokens <https://www.w3.org/TR/WCAG21/#input-purposes> that are
reserved for the attribute (those fixed token values being the means by
which machines can THEN determine the purpose of the input). In the context
of internationalization, a North American password manager that can also
populate form inputs
<https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research> may
not know what 住所 means, but if coded correctly it will always know what
"street-address" means:

<label> 住所: <input name="青い贈り物を" autocomplete="street-address"> </label>


That's because the token "*street-address*" has been unambiguously defined
as a taxonomy term, so machines can 100% be sure of what the input value
string should be (and/but NOT then what to do with that information).

Looking at it another way... SC 1.1.1 requires "*All non-text content that
is presented to the user has a text alternative that serves the equivalent
purpose...*", and not "All images require alt text (using @alt)" - as using
@alt is but one technique today that we can use to meet that requirement.
Thus, we don't just test for the presence of @alt alone - we test instead
for the presence of "... *a text alternative that serves the equivalent
purpose*", of which there are now multiple techniques available to the page
author (but that was historically not always the case).

The Personalization Task Force at the W3C is however looking at other
possible mechanisms for making inputs and other page-level
components/elements "programmatically determinable". There is work on
an expanded
taxonomy <https://www.w3.org/TR/personalization-semantics-1.0/>, as
well as investigations
into different mechanisms
<https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content>
that may be used to achieve the same larger goal: attaching semantic
metadata to page-level components and elements.

For example, as a straw-man proposal, we're investigating minting a new
HTML 5 attribute (@purpose) which, if approved (and we're a long way from
that today) could also serve as an alternative technique:

<label> 住所: <input name="青い贈り物を" purpose="street-address"> </label>

(TO BE VERY CLEAR: THIS IS A PROPOSAL AND NOT AN APPROVED TECHNIQUE TODAY.)

...and so, the pass/fail determination isn't about outcomes, but rather
whether or not the code is constructed in such a way so that the purpose of
the input can be machine-determined, *and nothing more*. Lack of envisioned
future functionality and outcomes today is not, in-and-of-itself a reason
to fail a page on this SC.

(And for those who may ask... because the @autocomplete technique *does*
apply magic *some of the time* - if the end user has configured their
user-agent to support the technique - browsers today CAN programmatically
determine the input purpose and subsequently autocomplete the field inputs.
Because we were able to demonstrate *that *fact is how this SC got through
the W3C process.)


ISSUE TWO:

> the form has several fields where the user is asked to enter all of
their known "given" or "first" names - any name by which they may be known.

In that context, I would surmise that yes, if there were say, three inputs
that were all looking to collect the same "larger" piece of information
about *ME* (Name, Alt-Name1, Alt-Name2, etc.) I'd likely expect that all
three inputs would have an autocomplete attribute with a token value.

Personally I'd envision the "First" input to be tagged as *given-name*,
with subsequent inputs tagged as possibly *additional-name* or
*nickname. *Neither
HTML5's @autocomplete definition, nor WCAG 2.1's appropriation of the
attribute to achieve a higher-level outcome, is specific about whether or
not multiple identical token values are valid or "legal", and so from a
testing perspective I think today it's a value judgement.

In the use-case you've presented, the user only has one legal "given name"
(what's on their birth certificate or passport) even if they have multiple
aliases or nicknames, so I'd expect something like this:

<fieldset><legend>Names by which you may be known</legend>

<label> Legal name <input type="text" name="name"
autocomplete="given-name"></label>

<p>AKA (Also Known as)</p>
<label> Other name <input type="text" name="nickname1"
autocomplete="nickname"></label>
<label> Other name <input type="text" name="nickname2"
autocomplete="nickname"></label>
</fieldset>



I agree that at this level of granularization, we currently lack a
mechanism to 'programmatically' separate one nickname from the other, but
in the context of SC 1.3.5, all of the above inputs *ARE* programmatically
determinable, they are all collecting information about *ME*, and so I'd
pass my own code example <grin> based solely on the language of the SC:

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


HTH

JF

On Thu, Nov 1, 2018 at 11:47 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> John -
>
> If I'm understanding the issue correctly, here's a scenario (though,
> admittedly, a bit of an edge case)...
>
> Someone is completing an online form to request a background check and the
> form has several fields where the user is asked to enter all of their known
> "given" or "first" names - any name by which they may be known. Giving all
> of these fields an autocomplete attribute would lend itself to incorrect
> entry. But NOT giving all of the fields autocomplete would be a WCAG
> failure. So which is the proper approach?
>
> Jared
> > > > >



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

From: Sailesh Panchang
Date: Fri, Nov 02 2018 7:15AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

For SC 1.3.5, the Understanding doc states:
"By adopting and repurposing this predefined taxonomy of definitions,
user agents and assistive technologies can now present the purpose of
the inputs to users in different modalities. For example, assistive
technologies may display familiar icons next to input fields to help
users who have difficulties reading. An icon of a birthday cake may be
shown in front of an input field with autocomplete="bday", or the icon
of a telephone in front of an input field with autocomplete="tel"".

The HTML 5.2 specs do not require user agents or assistive
technologies to use different modalities to elaborate the control's
purpose.
The autocomplete attribute's primary purpose is to enable browsers
perform autofill as per the HTML 5 specs.

So the use of the phrase, "adopting and repurposing " in the above
statement is very significant.
Till such time that user agents or assistive technologies really
exploit the taxonomy defined by autocomplete, the mere use of the
autocomplete attribute does little to enhance accessibility as
intended. In other words, it is not AT-supported at present.
Secondly, when user agents / assistive technologies do start
displaying familiar icons next to input fields as suggested in the
above statement, will it not help if the familiar icons are displayed
next to other date or phone number fields on the page even though they
do not relate to the particular user filling out the form? Developers
may think it it will be a disservice if they do so for some fields and
not for others on the page regardless of what the SC mandates.

The Understanding doc also acknowledges, "For some input fields, the
type attribute already offers a way to specify the purpose, for
example, input type="tel", input type="email". ... these are only
very broad categories, ... does not clarify if the purpose is for
entering the user's e-mail address or some other person's e-mail".
Does this same argument not apply to autocomplete types like name,
given-name, bday, etc.?

The HTML 5.2 guidance on the topic is relevant:
The autocomplete attribute, in contrast, describes what the value that
the user will enter actually represents. Choosing between different
values of this attribute is the same choice as choosing what the label
for the element will be".

Thanks,
Sailesh panchang

On 11/1/18, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> John -
>
> If I'm understanding the issue correctly, here's a scenario (though,
> admittedly, a bit of an edge case)...
>
> Someone is completing an online form to request a background check and the
> form has several fields where the user is asked to enter all of their known
> "given" or "first" names - any name by which they may be known. Giving all
> of these fields an autocomplete attribute would lend itself to incorrect
> entry. But NOT giving all of the fields autocomplete would be a WCAG
> failure. So which is the proper approach?
>
> Jared
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

From: Mallory
Date: Fri, Nov 02 2018 9:19AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Hi,
john: >"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)."

That sounds clear enough, and yeah I did grok that it had to be that-user-personal data. I consider my question answered.

john: "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?"

I don't have a sample. It was an idea other devs I was with thought up of to deal with an issue my family ran into when attempting to enter the US. My father-in-law and brother-in-law (his son) both have exactly the same christian name (and different call-names, though both derived from the christian name). Somehow TSA (or whoever) agents could not comprehend two passports coming in with the same name and different birthdates (seems normal to me with all the John Q Smiths out there, but anyway), and this sort of thing was one of the reasons ESTA exists.
If there was a given-name for "what's on your passport" and "daily-use name", the two individuals would also have had completely different names at that level (Americans tend to solve this by adding "Jr" and sometimes "Sr" or "III" to their full names, and some forms even have fields dedicated to these).

It's absolutely an edge case. I like, when testing, to already have an answer for when I run into edge cases, because I have bad parking mojo, bad grocery line mojo, and therefore I'm almost certain to hit those edge cases.

But it's pretty clear to me now what I can pass and fail, and I can pass this on to an upcoming 2.1 meetup we're having over here in NL. Thanks!

cheers,
Mallory



On Fri, Nov 2, 2018, at 2:15 PM, Sailesh Panchang wrote:
> For SC 1.3.5, the Understanding doc states:
> "By adopting and repurposing this predefined taxonomy of definitions,
> user agents and assistive technologies can now present the purpose of
> the inputs to users in different modalities. For example, assistive
> technologies may display familiar icons next to input fields to help
> users who have difficulties reading. An icon of a birthday cake may be
> shown in front of an input field with autocomplete="bday", or the icon
> of a telephone in front of an input field with autocomplete="tel"".
>
> The HTML 5.2 specs do not require user agents or assistive
> technologies to use different modalities to elaborate the control's
> purpose.
> The autocomplete attribute's primary purpose is to enable browsers
> perform autofill as per the HTML 5 specs.
>
> So the use of the phrase, "adopting and repurposing " in the above
> statement is very significant.
> Till such time that user agents or assistive technologies really
> exploit the taxonomy defined by autocomplete, the mere use of the
> autocomplete attribute does little to enhance accessibility as
> intended. In other words, it is not AT-supported at present.
> Secondly, when user agents / assistive technologies do start
> displaying familiar icons next to input fields as suggested in the
> above statement, will it not help if the familiar icons are displayed
> next to other date or phone number fields on the page even though they
> do not relate to the particular user filling out the form? Developers
> may think it it will be a disservice if they do so for some fields and
> not for others on the page regardless of what the SC mandates.
>
> The Understanding doc also acknowledges, "For some input fields, the
> type attribute already offers a way to specify the purpose, for
> example, input type="tel", input type="email". ... these are only
> very broad categories, ... does not clarify if the purpose is for
> entering the user's e-mail address or some other person's e-mail".
> Does this same argument not apply to autocomplete types like name,
> given-name, bday, etc.?
>
> The HTML 5.2 guidance on the topic is relevant:
> The autocomplete attribute, in contrast, describes what the value that
> the user will enter actually represents. Choosing between different
> values of this attribute is the same choice as choosing what the label
> for the element will be".
>
> Thanks,
> Sailesh panchang
>
> On 11/1/18, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> > John -
> >
> > If I'm understanding the issue correctly, here's a scenario (though,
> > admittedly, a bit of an edge case)...
> >
> > Someone is completing an online form to request a background check and the
> > form has several fields where the user is asked to enter all of their known
> > "given" or "first" names - any name by which they may be known. Giving all
> > of these fields an autocomplete attribute would lend itself to incorrect
> > entry. But NOT giving all of the fields autocomplete would be a WCAG
> > failure. So which is the proper approach?
> >
> > Jared
> > > > > > > > > >
>
>
> --
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> Phone 703-225-0380 ext 105
> Mobile: 571-344-1765
> > > >

From: John Foliot
Date: Fri, Nov 02 2018 10:22AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | No next message

Hi Sailesh,

> The HTML 5.2 specs do not require user agents or assistive
> technologies to use different modalities to elaborate the control's
> purpose.

Correct. HTML 5 does not require any tool to do anything, it simply defines
for authors and implementers the intent of the semantic being provided.

So, in focus, HTML 5 does not *mandate* browsers to do something specific
with @autocomplete (and in fact neither Internet Explorer nor Edge do
*anything* with those attributes today).

However, WCAG SC 1.3.5 *does* state that the purpose of the form input as
related to the end user needs to be programmatically determinable, so that
the semantic (information) about that input can be reinterpreted for
different modalities. The fact that the @autocomplete attribute does in
fact do that is why we were able to proceed with this SC: when the user
agent "knows" what string of text is expected in a form input, and *if*
there is a corresponding string of text stored in the browsers sand-boxed
"memory", *THEN* the user agent can accurately and unambiguously do
something with that input - pre-fill it with the stored data (but the spec
leaves the door open for other types of "hinting"). There are a lot of
conditions present to achieve "autofilling", but only one condition needs
to be present for tools to do specific things with form inputs: accurate
and granular metadata defining the purpose of the input, so that machines,
once they "understand" that purpose, can do something with that information
(be that "fill it out" or augment it with iconography, or... do something
else again).


> The autocomplete attribute's primary purpose is to enable browsers
> perform autofill as per the HTML 5 specs.

Actually, the W3C spec (HTML 5) states the following:


User agents sometimes have features for helping users fill forms in, for
example prefilling the user's address based on earlier user input. The
autocomplete content attribute can be used to hint to the user agent how
to, or indeed whether to, provide such a feature.


..and so by definition, the attribute is there to provide a "hint" to
user-agents, so that user-agents can then provide a feature "...for helping
users fill forms in...". That's literally what the spec says, although in
practice today that feature *is* the auto-filling of forms - but that's not
*required* by user-agents, it's only assumed. (And again, not all user
agents - aka browsers - do anything with this attribute today, right
Microsoft?)


> So the use of the phrase, "adopting and repurposing " in the above
> statement is very significant.
> Till such time that user agents or assistive technologies really
> exploit the taxonomy defined by autocomplete, the mere use of the
> autocomplete attribute does little to enhance accessibility as
> intended. In other words, it is not AT-supported at present.

I'll push back on that statement harder: it may not provide any additional
functionality to a specific assistive technology today (such as a screen
reader), but not all disabilities require specific AT.

For users with mobility impairments, auto-completing forms saves multiple
key stokes, making form filling far easier for them. That's a win! For
users with cognitive disabilities, not having to remember complex pieces of
information (for users with dyscalculia remembering phone numbers is a real
challenge) is a real and tangible benefit (and another "win"!), and so
overall, even with little additional tooling, we *are* indeed still
exploiting native functionality in most browsers to specifically assist
some users today. More tooling will of course broaden the circle of
benefited users, but to suggest that it has little to no
'accessibility' benefit
today is missing out on a large swath of users with other disabilities.


> Secondly, when user agents / assistive technologies do start
> displaying familiar icons next to input fields as suggested in the
> above statement,

...again, this is but a suggestion: no AT is being forced or required to do
so, all we can do is illustrate the need, suggest a solution, and then, via
the code, leave open the "hooks" that AT would require to do it's magic...
but the W3C never specifies what tools must do - ever.


> ... will it not help if the familiar icons are displayed
> next to other date or phone number fields on the page even though they
> do not relate to the particular user filling out the form? Developers
> may think it it will be a disservice if they do so for some fields and
> not for others on the page regardless of what the SC mandates.

No, because, again, this SC is tightly scoped to the actual end user. I may
have a form that collects multiple data points for multiple users, and
applying autocomplete="tel" on each telephone input would result in
populating *every* telephone input with the same data string (if in fact
that data-string has already been "remembered" by the browser - which may
not always be the case, as I've noted in the "terminal/library/coffee-shop"
scenario. So educating developers that this is applicable only to data
about the user filling in the form (and not 3rd parties), is one of the
tasks the AG Working Group needs to continue to tackle. (It's also one of
the reasons why I've written extensively on this here and elsewhere).


> The Understanding doc also acknowledges, "For some input fields, the
> type attribute already offers a way to specify the purpose, for
> example, input type="tel", input type="email". ... these are only
> very broad categories, ... does not clarify if the purpose is for
> entering the user's e-mail address or some other person's e-mail".
> Does this same argument not apply to autocomplete types like name,
> given-name, bday, etc.?

The HTML 5 spec address this by noting that there are some token values
that are "broad", while others are more "tightly focused". It states:

NOTE:
Generally, authors are encouraged to use the broader fields rather than the
narrower fields, as the narrower fields tend to expose Western biases. For
example, while it is common in some Western cultures to have a given name
and a family name, in that order (and thus often referred to as a *first
name* and a *surname*), many cultures put the family name first and the
given name second, and many others simply have one name (a *mononym*).
Having a single field is therefore more flexible.


...and again, this WCAG SC is also scoped *to just the user,* and not all
field inputs on a complex form, so there may be some author error we'll
see, but overall, when used correctly, the application of the @autocomplete
attribute actually narrows down <input type="tel"> (which could take any
telephone number), to <input type="tel" autocomplete="tel"> thus scoping
the input to *JUST* the end user's telephone number, and not every
telephone number field on the form.

HTH

JF




On Fri, Nov 2, 2018 at 10:19 AM, Mallory < = EMAIL ADDRESS REMOVED = > wrote:

> Hi,

john: >"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)."


> That sounds clear enough, and yeah I did grok that it had to be
> that-user-personal data. I consider my question answered.


> john: "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?"


> I don't have a sample. It was an idea other devs I was with thought up of
> to deal with an issue my family ran into when attempting to enter the US.
> My father-in-law and brother-in-law (his son) both have exactly the same
> christian name (and different call-names, though both derived from the
> christian name). Somehow TSA (or whoever) agents could not comprehend two
> passports coming in with the same name and different birthdates (seems
> normal to me with all the John Q Smiths out there, but anyway), and this
> sort of thing was one of the reasons ESTA exists.

If there was a given-name for "what's on your passport" and "daily-use
> name", the two individuals would also have had completely different names
> at that level (Americans tend to solve this by adding "Jr" and sometimes
> "Sr" or "III" to their full names, and some forms even have fields
> dedicated to these).


> It's absolutely an edge case. I like, when testing, to already have an
> answer for when I run into edge cases, because I have bad parking mojo, bad
> grocery line mojo, and therefore I'm almost certain to hit those edge cases.


> But it's pretty clear to me now what I can pass and fail, and I can pass
> this on to an upcoming 2.1 meetup we're having over here in NL. Thanks!


> cheers,

Mallory


>
>
> On Fri, Nov 2, 2018, at 2:15 PM, Sailesh Panchang wrote:

> For SC 1.3.5, the Understanding doc states:

> "By adopting and repurposing this predefined taxonomy of definitions,

> user agents and assistive technologies can now present the purpose of

> the inputs to users in different modalities. For example, assistive

> technologies may display familiar icons next to input fields to help

> users who have difficulties reading. An icon of a birthday cake may be

> shown in front of an input field with autocomplete="bday", or the icon

> of a telephone in front of an input field with autocomplete="tel"".

>

> The HTML 5.2 specs do not require user agents or assistive

> technologies to use different modalities to elaborate the control's

> purpose.

> The autocomplete attribute's primary purpose is to enable browsers

> perform autofill as per the HTML 5 specs.

>

> So the use of the phrase, "adopting and repurposing " in the above

> statement is very significant.

> Till such time that user agents or assistive technologies really

> exploit the taxonomy defined by autocomplete, the mere use of the

> autocomplete attribute does little to enhance accessibility as

> intended. In other words, it is not AT-supported at present.

> Secondly, when user agents / assistive technologies do start

> displaying familiar icons next to input fields as suggested in the

> above statement, will it not help if the familiar icons are displayed

> next to other date or phone number fields on the page even though they

> do not relate to the particular user filling out the form? Developers

> may think it it will be a disservice if they do so for some fields and

> not for others on the page regardless of what the SC mandates.

>

> The Understanding doc also acknowledges, "For some input fields, the

> type attribute already offers a way to specify the purpose, for

> example, input type="tel", input type="email". ... these are only

> very broad categories, ... does not clarify if the purpose is for

> entering the user's e-mail address or some other person's e-mail".

> Does this same argument not apply to autocomplete types like name,

> given-name, bday, etc.?

>

> The HTML 5.2 guidance on the topic is relevant:

> The autocomplete attribute, in contrast, describes what the value that

> the user will enter actually represents. Choosing between different

> values of this attribute is the same choice as choosing what the label

> for the element will be".

>

> Thanks,

> Sailesh panchang

>
>
> On 11/1/18, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > John -
>
> >
>
> > If I'm understanding the issue correctly, here's a scenario (though,
>
> > admittedly, a bit of an edge case)...
>
> >
>
> > Someone is completing an online form to request a background check and
> the
>
> > form has several fields where the user is asked to enter all of their
> known
>
> > "given" or "first" names - any name by which they may be known. Giving
> all
>
> > of these fields an autocomplete attribute would lend itself to incorrect
>
> > entry. But NOT giving all of the fields autocomplete would be a WCAG
>
> > failure. So which is the proper approach?
>
> >
>
> > Jared
>
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
> --

> Sailesh Panchang

> Principal Accessibility Consultant

> Deque Systems Inc

> Phone 703-225-0380 ext 105

> Mobile: 571-344-1765

> >
> >
> >
> >
>
>
>
>



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