- From: 'Janina Sajka' <janina@rednote.net>
- Date: Tue, 26 Apr 2016 11:59:32 -0400
- To: John Foliot <john.foliot@deque.com>
- Cc: "'Léonie Watson'" <tink@tink.uk>, "'Rich Schwerdtfeger'" <richschwer@gmail.com>, "'White, Jason J'" <jjwhite@ets.org>, "'Birkir Gunnarsson'" <birkir.gunnarsson@deque.com>, public-aria@w3.org
John Foliot writes: > 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. > Hi, John: I think we all expect our ATs to do responsible and useful things. However, it still strikes me as a new exit criterion to somehow show that you couldn't possible do damage by misreading the spec, or by intentionally misusing the feature. That's what's new, imo. I suppose, if one could show, that an "incorrect" implementation can result from a correct reading of the spec, that would be different. But, that's not what I'm hearing in this discussion. Frankly, that's all I expect from a security review--that the feature is, or is not, intrinsically insecure when correctly implemented. Anything else takes me back to not crossing the street because -- well, you know -- I may be crushed by a car. There are no guarantees in life, and there never will be. Just because some may commit murder shouldn't and doesn't prevent us from legislating against murder. This really strikes me as no different. Janina > JF > -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
Received on Tuesday, 26 April 2016 17:03:00 UTC