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: Oct 2, 2018 9:20AM

Hi,

I actually wonder about this:

>(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, 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)?
Would be good to know.

cheers,
_mallory

On Fri, Sep 28, 2018, at 6:57 PM, John Foliot wrote:
> > The 'about the user' requirement being hard for software to determine
> presents an interesting problem for plug-ins (or any other user agent)
> consuming autocomplete to enhance presentation. They have no way of knowing
> if the autocomplete attribute is 'about the user' or about something
> else... Is this a problem, or am I missing something here?
>
> Hi Mark,
>
> You are essentially correct, and for the *functionality* assigned to
> autocomplete, it is true that user-agents (browsers and password managers)
> allow the end user to select appropriate stored data to complete the
> fields. My current configuration(s) across multiple browsers actually
> stores multiple 'personas' (i.e. I have a faked-out user: Mr. Joe. Q.
> Tester, complete with a fake address, phone number and email address that I
> use for testing, as well as my *actual* configurations - of which I have
> both a Home profile with my personal email address, as well as a second
> Work profile with my work address.)
>
> However, I think the concern Jared is thinking of (a real concern) is that
> it adds complexity to the testing, in that a tool alone cannot determine
> "compliance" because that compliance is conditional on what type of data is
> being collected (i.e. "of the specific user"). There are a number of other
> use-cases that have surfaced that also add to "manual inspection
> complexity" (imagine an online HR form that collects multiple "First
> names"). As a representative of a company that also provides accessibility
> compliance tools (Deque), we understand that every time you have to include
> a more manual inspection, it adds to complexity, potential
> "false-positives", and potentially additional cost/time to evaluate. While
> not show-stoppers, they are real concerns, especially at large volume
> (enterprise) scale. However, like many other SC in WCAG, at this time I
> cannot see a why around the need for manual intervention in the test
> process.
>
> Not sure if this adds anything new to the discussion, but wanted to reply
> to your thoughts.
>
> JF
>
> On Fri, Sep 28, 2018 at 6:52 AM, Mark Rogers < <EMAIL REMOVED> >
> wrote:
>
> > This makes it a bit difficult to test this automatically. It's
> > difficult to surmise whether a form is collecting information about
> > THE user vs. information about SOME OTHER user. This SC would only
> > apply to the former.
> >
> > The 'about the user' requirement being hard for software to determine
> > presents an interesting problem for plug-ins (or any other user agent)
> > consuming autocomplete to enhance presentation. They have no way of knowing
> > if the autocomplete attribute is 'about the user' or about something else.
> >
> > For example, an online tax form for non-profits might use
> > autocomplete='organization' and autocomplete='street-address' to make it
> > easier to complete. That seems like it could interfere with the input
> > purpose autocomplete use outlined in SC 1.3.5 and cause problems with the
> > WCAG Non-Interference requirement (e.g. if the AT overlays an icon
> > indicating 'Your home address here' on the autocomplete='street-address'
> > element.) But removing autocomplete from the form makes filling it harder
> > for anyone who finds typing difficult due to Parkinson's or Arthritis.
> >
> > Chrome deals with ambiguity of the autocomplete tokens by presenting a
> > dropdown containing alternatives for autocomplete fields - an
> > autocomplete='street-address' field might show addresses for home, work and
> > a relative because you ordered them a gift last birthday.
> >
> > Is this a problem, or am I missing something here?
> >
> > Best Regards
> > Mark
> >
> > --
> > Mark Rogers - <EMAIL REMOVED>
> > PowerMapper Software Ltd - www.powermapper.com
> > Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
> >
> >
> >
> >
> > On 27/09/2018, 18:16, "WebAIM-Forum on behalf of Jared Smith" <
> > <EMAIL REMOVED> on behalf of <EMAIL REMOVED> > wrote:
> >
> > Mark Rogers wrote:
> >
> > > Doesn't the failure only happen when the input field purpose matches
> > one of the input purposes listed:
> > > https://www.w3.org/TR/WCAG21/#input-purposes
> >
> > Yes, and only when collecting information directly from and about the
> > user completing the form.
> >
> > This makes it a bit difficult to test this automatically. It's
> > difficult to surmise whether a form is collecting information about
> > THE user vs. information about SOME OTHER user. This SC would only
> > apply to the former.
> >
> > > I don't think autocomplete='on' counts as a pass, because ‘on' is
> > the default if autocomplete is not specified, and means user agents use
> > heuristics to guess the input type which seems at odds with the SC.
> >
> > Correct. This would not provide the level of field purpose
> > identification necessary for this success criterion.
> >
> > > I think having more documented successes and failures would help
> > clarify this.
> >
> > Yep. I know the documentation for this is still in the works.
> >
> > For what it's worth, I agree with Patrick's assessment of the examples
> > you provided.
> >
> > Jared
> > > > > > > > > >
> >
> > > > > > > > > >
>
>
>
> --
> *​John Foliot* | Principal Accessibility Strategist
> Deque Systems - Accessibility for Good
> deque.com
> > > >