- From: John Foliot <john.foliot@deque.com>
- Date: Tue, 26 Apr 2016 10:41:37 -0500
- To: "'Janina Sajka'" <janina@rednote.net>, 'Léonie Watson' <tink@tink.uk>
- Cc: "'Rich Schwerdtfeger'" <richschwer@gmail.com>, "'White, Jason J'" <jjwhite@ets.org>, "'Birkir Gunnarsson'" <birkir.gunnarsson@deque.com>, <public-aria@w3.org>
Janina Sajka wrote: > > I don't follow this exit criterion. It seems to me with this kind of requirement one > might never cross a street. Again, this strikes me as a new kind of exit criterion > that no other ARIA feature has previously had to meet. We do our best to > specify what correct implementation is, then we show correct implementations > and the W3C requirements are met. I'm simply unaware that we've ever been > required to show that any kind of "incorrect" implementation does no harm. Hi Janina, I think that this proposed role is significantly different from other roles we've added to ARIA in the past, in that there is some actual, specific on-screen functionality suggested in the use of the attribute: it is for custom inputs, and it suggests to the end user that the custom input is one of "password" (with all of the implied functionality and assumptions of privacy and security that comes with the notion of "Password", with none of the guarantees that those assumptions will exist). Leonie is correct, without the Screen Readers actually doing something useful with this attribute (outside of announce that the input is a (faux) password input) there is a real risk that what the author is telling *you* (via code, as a non-sighted user) may or may-not match what is happening on screen. At its simplest, what should happen with this? <div contenteditable role="password"></div> At least a few of us have on-going concerns over this, and we are still awaiting an actual formal security review from the W3C Security folks as part of moving forward. Reviewing the exit criteria for this attribute is, I believe, also very much in scope. JF
Received on Tuesday, 26 April 2016 15:42:08 UTC