WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

for

From: Jonathan Avila
Date: Oct 2, 2018 10:49AM

Mallory, in your example I think none of them would get the autocomplete.

Jonathan

Sent from my iPhone

> On Oct 2, 2018, at 11:21 AM, Mallory < <EMAIL REMOVED> > wrote:
>
> 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
>> >> >> >> > > > >