WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: Mallory
Date: Nov 2, 2018 9:19AM

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