W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

RE: Password role proposal: Freedom Scientific response

From: Matt King <a11ythinker@gmail.com>
Date: Mon, 2 May 2016 12:08:28 -0700
To: <tink@tink.uk>, "'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>
Message-ID: <00b801d1a4a6$0308f4a0$091adde0$@Gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:26 UTC