- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Fri, 08 Apr 2016 18:10:29 +0200
- To: "Rich Schwerdtfeger" <richschwer@gmail.com>, "Gervase Markham" <gerv@mozilla.org>
- Cc: Virginie.Galindo@gemalto.com, public-web-security@w3.org, ARIA <public-aria@w3.org>, "Mike Cooper" <cooper@w3.org>
On Fri, 08 Apr 2016 15:38:53 +0200, Gervase Markham <gerv@mozilla.org> wrote: > On 06/04/16 21:27, Rich Schwerdtfeger wrote: >> ARIA is not meant to be the web police. The reality is that people are >> doing this in the wild and if you are interacting with one of these >> things and you can’t see the screen you want to know what the intent of >> the author is. > > So the target of this feature is people who care enough about web > accessibility to include ARIA roles, but not enough to use semantic > markup? Yes. It seems to me that ARIA should just say "you must not make a custom password" until we discover that Web Components makes that a reasonable thing to do. >> So, we agree that people should not do this but if a user encounters it >> they need to know what it is for. Does adding the role attribute with a >> value of “password" create a security problem that was not there before? > > Well, it encourages people to use non-password fields for passwords, > which is arguably a security problem because if people's password > managers don't save the passwords, they are more likely to use bad > (simple, short) passwords. That's one problem. Another is if it reports pseudo-passwords as if they are the same as real ones, the user doesn't know until they start feeding their password in whether or not it is going to have *minimal* protection, or will render the actual password. More seriously, browsers are likely to save the value for autocomplete unless they explicitly recognise the role as defining a real password field. cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Friday, 8 April 2016 16:11:07 UTC