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

Detlev wrote,

> As I see it, developers could avoid the use of autocomplete entirely here
since there are no inputs uniquely scoped to the user,

That would be how I'd counsel it as well Detlev.

Our current problem is that the only mechanism we have for attaching the
metadata today is to use the @autocomplete attribute, along with the
functionality it provides in most browsers (neither IE nor Edge support the
'auto-filling' at this time - I expect Edge to start when they move to
Blink). In you scenarios, the possibility that the functionality of the
attribute would likely impact the larger usability (and inherent cognitive
load that this lousy behavior might impose on impacted users), along with
the possibility that the inputs (more often than not) would NOT be related
to the user suggests not using the attribute in those scenarios.

> 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).


Once we have additional mechanisms for attaching the tokens that do not
impart any specific browser functionality (such as auto-completing), THEN
I'd likely also agree that adding the ability to output the purpose in
different modalities - for *ALL* of the inputs potentially scoped to "user"
- would have a value as well.

Our current Technique is less than perfect today, but we're working on it.
I am reminded of the days, and the differences, between
aria-required="true" and @required, where the HTML5 @required attribute
also includes some basic browser functionality (including rudimentary
error-checking, the out-putting of a generic error message, and a
browser-controlled error indication which potentially collides with the
aesthetics of the site design). Either would be acceptable in the context
of SC 1.3.1, but one technique also has some additional functionality that
may or may not be desired. Today, with 1.3.5, we lack that 'choice', but
our (Personalization TF) meeting at TPAC with WebPlat left us confident
that a new attribute may come forth relatively soon(ish).

JF

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

> 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> 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
>
>
>

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