Re: 1.3.5 Identify Input Purpose: Towards best practice recommendations for pages with info on several users

Hi Detlev,

I actually have, sitting on my over-stuffed To-Do list, an action item to
write up a failure technique around using @autocomplete when *out of
scope*. And I will say that by my reading *that *is the defined pass/fail
criteria - is the usage "in scope" or not. The following is a 'sanitized'
version of an internal email discussion about this that I actually wrote up
yesterday (we're getting similar questions/concerns at our end). I'm not
sure how useful this will be, but it did help our internal SME respond to
the client.

*************

> For example, if a “recipient name” field has autocomplete attribute,
would it fail any SC including 1.3.5 in WCAG 2.1?


This is starting to tread on soft ground... this Success Criteria is
*scoped* to "the user", and I would suggest that "recipient" isn't the
user, but rather an
actor related to "the User" (i.e. the user is giving, and the other person
is receiving - i.e. "the recipient"), and so on the surface
adding @autocomplete
to an input that is NOT related directly to the 'user' is, at the very
least, "out of scope" with regard to WCAG 2.1.
*Whether or not it is a failure however is another question...*

Background:

The HTML5 specification that @autocomplete was taken from
<https://www.w3.org/TR/html5/sec-forms.html#sec-autofill> does not
specifically mandate or forbid the use of @autocomplete in any kind of
context (outside of usage rules), and so if you were to apply
an @autocomplete value on an input labeled "recipient name" it *would *validate
at the W3C
Validation tool, so it isn't "non-valid". However, because the values that
correspond to the tokens are stored locally on the user's machine (for the
auto-completing function), then it begs the question "How would locally
stored values 'know' the recipient name" (when I might have multiple
recipients)?

At this time, the AG WG is still actively discussing this, and I have an
action item to write-up a Failure Technique for the WG to review, that
essentially
illustrates that the *intent* of the WCAG 2.1 Success Criteria is that the
tokens (which are also found directly in WCAG 2.1
<https://www.w3.org/TR/WCAG21/#input-purposes>) *SHOULD only be applied to
fields directly related to the actual user*, and not persons or entities
related to the user.

It might also be helpful to remember (and explain to the client) that the
intention of SC 1.3.5 is to attach those tokens to form inputs using a
'method'
- and today the *only* method we can use is @autocomplete. However, we
(W3C) are actively working on creating a new attribute (perhaps something
like @purpose), which would also allow the attachment of the token value,
WITHOUT imparting any additional functionality (such as auto-completing the
input).

In other words, *in the near future* there is a hope that you could also do
something like this:


<input type="text" name="name2" purpose="family-name">

*(NOTE: this is non-valid, and IS NOT a technique today!)*


I'll also suggest that adding @autocomplete tokens to form inputs NOT
directly related to the actual user will likely result in a poor
user-experience, and
I'd think that user-testing would surface that 'problem' quickly...

*************

Detlev, a) does this make sense? b) does it answer your question/concern?
(If yes, then it will also serve as the basis for my still-to-be-written-up
Failure Technique)

Cheers!

JF

On Tue, Dec 18, 2018 at 1:54 PM Detlev Fischer <detlev.fischer@testkreis.de>
wrote:

> I would like to see more discussion on the ramifications of using
> autocomplete on pages (like passenger details pages in airline booking
> processes) which have personal data input for several people, with a view
> of having valid best practice recommendations for those cases. What these
> pages have in common is that the person whose data is entered may be the
> user him/herself or may not be, and if the user is part of the traveller
> group, the position of this user is not mandated.
>
> I have looked at two airline sites and carried out two fake bookings to
> the point when you have to supply user data (3 passengers).
>
> Ryanair uses autocomplete with an interesting value,
> autocomplete="user-lastname-input", which does not seem to map onto the
> allowed values I found in the HTML 5.2 spec.
> http://3needs.org/p/ryanair-wrong-autocomplete.gif
>
> Eurowings does not use autocomplete on their inputs.
> http://3needs.org/p/eurowings-no-autocomplete.gif
>
> (Note to JF: I know this is not about the autocomplete attribute and
> behavior but about generic (not language-specific) tokens for purpose.)
> BUT: It is to be expected that implementers will want to ascertain that
> whatever policy they adopt towards meeting 1.3.5 does not create issues
> (unwanted side effects) in terms of autofill behaviour. I can imagine that
> airlines may have a policy NOT to use autocomplete here because data
> quality might be better if users are forced to actually type in all the
> names (but I am not sure). In any case, none of my own autofill data was
> offered when I started filling in my surname (but that may also depend on
> browser-specific aspects).
>
> I am not sure whether the examples provided help move the discussion
> forward towards clear best practice recommendations for cases such as this.
> I may explore more examples, but for now I'll stop here.
>
> And then, of course, there is the question of tasing or failing 1.3.5.
> - Would a site like this fail 1.3.5 because autocomplete is not used or
> used with an invalid value? I guess not.
> - Would a site fail SC 1.3.5 if it uses the correct autocomplete
> attributes on ALL instances of passenger even though all but one would
> *not* be the user? I think we have established that such use would not fail
> the SC.
>
> Detlev
>
>
>

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