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 2, 2018 10:22AM

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