w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
142 stars 55 forks source link

SC 1.3.5 Identify Input Purpose - autocomplete technique VS Privacy/Security #948

Closed goetsu closed 6 years ago

goetsu commented 6 years ago

As the Working group considered an exception to this SC in a context where it may be problematic for security or privacy.

For example imagine a shared device showing (or a lost device by its owner) a website using autocomplete to comply with this SC. If user input personal data and save them by mistake or just because he doesn't know or understand that they will be saved in the browser once for good. It mean that the next people that will use the device will have access to the personal data of the previous user.

This may be a serious issue to consider and I don't think autocomplete must be showed in the understanding as the best and technique to use. This leave use to some aria techniques but that are still fare from being standardized and implemented in tools

alastc commented 6 years ago

imagine a shared device showing (or a lost device by its owner)...

A shared device should not be set to save & use people's data, that's basic IT. I remember browsers asking me whether they should save data (the 1st time), it is not done by default without the user's knowledge. Any shared computer (e.g. in a library) should not be configured to save user-specific data.

If someone looses a device and people can access the contents, they have bigger issues than saved form data.

This is a user-agent issue, and the things you are highlighting are true now regardless of whether people use autofill or not. The browsers (and plugins) also use heuristics to fill in data, so any input with 'name' in the label, ID or somewhere nearby will often be filled in automatically, if you have that setup.

This SC makes it a more concrete requirement, and if people use autocomplete it should improve accuracy, especially for 'enterprise' auto-generated code that uses random IDs.

goetsu commented 6 years ago

A shared device should not be set to save & use people's data

it's a very common situation for family computer for example. I'm not sure someone victim of domestic violence reporting it using family computer would be very happy to let abuser see that the reporting form already been filled by is victim.

it is not done by default without the user's knowledge

people with memory trouble can easily forget it and people have cognitive disability may easily not understand that it will save it once for good

if people use autocomplete it should improve accuracy, especially for 'enterprise' auto-generated code that uses random IDs.

sorry but that was not the exacte purpose of this SC, it was purpose of "SC 2.2.6 Accessible Authentication" that as been removed in most recent version of 2.1. This SC is about possible personalization not about helping to remember format of data to input

alastc commented 6 years ago

This feature (amongst many others) was requested by people with memory / cognitive issues (and people who do research in that area). I'm sure there are some situations where it is not desirable, and there are people who may not understand all the implications. But that has to be balanced against the good it can do for a wide population of people.

For someone who wants privacy, there is private browsing mode (fairly well known), and personal devices, and many other options. [EDIT:] Also, if the name and other bits of info are saved by the browser and autofilled on a particular website, that doesn't tell another user if that particular site has been used (although the browser history might), it only tells you that your information has been saved on a site. In the domestic abuse scenario autofill doesn't tell you about that form.

This SC is about possible personalisation, and identifying the purpose of inputs is a small part of that possible space. For some websites with clean code it's a minor thing, UAs may already be able to accomplish it with heuristics. For some websites with auto-generated IDs etc, the addition of a clear signal should make it more accurate. (Example for a particular website.)

I did a lot of work on "Accessible Authentication", I'm not sure why you raise that as it was to do with having methods of logging in that don't require memory, [EDIT] autofill/autocomplete wasn't a big factor in that.

goetsu commented 6 years ago

I raise "Accessible authentication" because it cover the auto-generated ID situation as with this SC you was supposed to offer a way to recover this kind of hard to remember data

alastc commented 6 years ago

Ok, I see the overlap there.

Do you take the point that autofill doesn't give away what forms you have filled in?

goetsu commented 6 years ago

yes I get it but I still think it may be problematic in certain situations and already know some public administration websites that will not comply with this SC because of that privacy/security issue

alastc commented 6 years ago

I've talked this through with a public org who had set autocomplete to "off" due to how they thought browser entry happens, and it was especially complex because they are in the process of getting organizations off shared-logins and on to unique logins.

The key factors for them were:

I'm struggling to see a scenario where autofill causes an issue, given that:

Can you see a specific scenario where it could be a problem, or is a general feeling that there must be a problem?

michael-n-cooper commented 6 years ago

This issue was moved to w3c/wcag#407