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

Hi Jason,
Correct. But more than proposing anything in particular, I desire clarity regarding best practice recommendations in situations like those outlined.
Best, Detlev

> Am 19.12.2018 um 00:48 schrieb White, Jason J <jjwhite@ets.org>:
> 
> Your proposition appears to be that if the input field can be used to supply information about the user or about someone else, then it should be treated as not “collecting information about the user” within the terms of 1.3.5. This seems to be a reasonable interpretation, though it may be worthy of a note or example if there is a future revision of WCAG 2, or at least a comment in the Understanding document.
>  
> From: Detlev Fischer <detlev.fischer@testkreis.de> 
> Sent: Tuesday, December 18, 2018 5:57 PM
> To: John Foliot <john.foliot@deque.com>
> Cc: WCAG group <w3c-wai-gl@w3.org>
> Subject: 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 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F3needs.org%2Fp%2Fryanair-wrong-autocomplete.gif&data=02%7C01%7Cjjwhite%40ets.org%7C4116441c4e9e478dbf0808d6653c405d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636807706789980093&sdata=IovJ%2BtG7vKMO42mG42L4EeX9GRRDD6m%2FY4%2FZssFjclo%3D&reserved=0>
> 
> Eurowings does not use autocomplete on their inputs.
> http://3needs.org/p/eurowings-no-autocomplete.gif <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F3needs.org%2Fp%2Feurowings-no-autocomplete.gif&data=02%7C01%7Cjjwhite%40ets.org%7C4116441c4e9e478dbf0808d6653c405d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636807706789980093&sdata=dPfHlDAujO2i4byJbPwcH8g3y3VhuvBLtPbzlWCCXHM%3D&reserved=0>
> 
> (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 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdeque.com%2F&data=02%7C01%7Cjjwhite%40ets.org%7C4116441c4e9e478dbf0808d6653c405d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636807706789990102&sdata=5hdlK5gARHmxJlRTIeq%2F5282iq4%2FEx7dWnlaG3nDxQ4%3D&reserved=0>
>  
>  
> 
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
> 

Received on Wednesday, 19 December 2018 06:21:07 UTC