By itself the password role would not do that. A screen reader would not be able to know the difference between an input type password and a contenteditable with role password unless the browser sets some flag that says the contenteditable is different. This is assuming that the API mapping for the contenteditable would otherwise be identical to the mapping for the input. From: Léonie Watson [mailto:tink@tink.uk] Sent: Monday, May 2, 2016 7:05 AM To: 'Matt King' <a11ythinker@gmail.com>; 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'White, Jason J' <jjwhite@ets.org> Cc: 'John Foliot' <john.foliot@deque.com>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>; public-aria@w3.org Subject: RE: Password role proposal: Freedom Scientific response From: Matt King [mailto:a11ythinker@gmail.com] “The purpose of telling a screen reader that a field is a custom password field is not to pass that info on to the user but to tell the screen reader that this is a password field that the screen reader should treat differently in order to give the user appropriate information.” Understood, but won’t the password role do that without us adding another attribute? Or perhaps I misunderstood what was being suggested before. This discussion has meandered over the weeks! Léonie. -- @LeonieWatson tink.uk Carpe diem
Received on Monday, 2 May 2016 19:08:58 UTC