We can tell the AT that the role is a password and it is a custom password vs. the standard password. It is up to the AT to convey the information to the user. This is no different than AT properly communicating the accessible name or the role of the element. If we don’t communicate the role then what will happen is the author simply creates an input field with an enter the password label. The average user will know nothing about it being a custom password field. They will simply echo the characters typed. They won’t know if they are obscured or not. Rich > On Apr 26, 2016, at 10:07 AM, Léonie Watson <tink@tink.uk> wrote: > > From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] > Sent: 26 April 2016 15:36 > “That is correct. ARIA is about interoperability at the API/browser level. It is not about mandating user agent visible user experience. It is not about mandating AT behavior. We have stated that from the very beginning.” > > Then we cannot include a role that, when implemented incorrectly by ATs, creates a security vulnerability or which puts users in a position of uncertainty as to their personal data security. > > > Léonie. > > -- > @LeonieWatson tink.uk <http://tink.uk/> Carpe diem
Received on Tuesday, 26 April 2016 15:53:38 UTC