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

JF wrote:
> 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)
Hi John,

What you say makes sense when you have clear-cut cases (say, a one user registration or login for a site), and also for cases where you are dealing with information about other people (Human Resources context, for example). In my view, it does however not answer the questions around the (not infrequent) use case presented in the two examples I have given (air travel booking for several people). As I see it, developers could avoid the use of autocomplete entirely here since there are no inputs uniquely scoped to the user, and on the other hand, there would be no grounds to fail the use of autocomplete on all fields (having iconic indications of name, email etc might even be a beneficial for people with certain conditions on fields not related to themselves). Still, I would not be sure what I would or should recommend to a customer dealing with such a situation (fortunately, this is not an acute need, but it will arrive at some point). 

Detlev
> 
> Cheers!
> 
> JF
> 
> On Tue, Dec 18, 2018 at 1:54 PM Detlev Fischer <detlev.fischer@testkreis.de <mailto: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 <http://3needs.org/p/ryanair-wrong-autocomplete.gif>
> 
> Eurowings does not use autocomplete on their inputs.
> http://3needs.org/p/eurowings-no-autocomplete.gif <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 <http://deque.com/>
>