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

Looking at the spec carefully, it doesn't look like someone would fail 
1.3.5 by putting user attributes on non-user fields. That causes me 
concern, in that it suggests that the result of this SC is that a user 
can't rely on the attribute. It also doesn't look like making up your own 
attributes is a failure, so long as you apply them to the input fields 
whose purpose is identified in the reference.

There's no reason both the use of the html5 attributes and the use of them 
only on user inputs can't be included in the Sufficient Technique (and it 
looks like both are; perhaps either the Understanding doc or the existing 
technique could go into more detail on ONLY using it for user inputs, and 
the why of that).

Do we want to consider making an advisory technique that uses the section- 
concatenation that appears in example 74 for user family purposes (i.e., 
section-spouse)? 

The other question I had on this is do we have a recommendation on whether 
teams should set the overall form to autocomplete="off" or "on" and in 
what circumstances? Do we have any rec from COGA on whether autofill is 
desirable (especially given one cannot rely on the attribute being used 
correctly ONLY on user fields)? Is anyone looking into whether adding 
something like "prompt" as another value for this attribute would be 
welcome?

Michael Gower
Senior Consultant
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   John Foliot <john.foliot@deque.com>
To:     Detlev Fischer <detlev.fischer@testkreis.de>
Cc:     WCAG group <w3c-wai-gl@w3.org>
Date:   2018-12-19 05:52 AM
Subject:        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