RE: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Hi Rich,

 

After chatting with some folks at CSUN, I share Leonie’s concerns. Unless all of the browser vendors and screen readers are going to programmatically treat the role=”password” *EXACTLY* like input type=”password” I too see a serious security/privacy concern.

 

For example, what should we expect with this piece of code: <input type=”text” role=”password”>? 

 

Will screen readers announce “star, star, star” while displaying “Secret PIN #” in the text field, in the clear and open?  (Saying they shouldn’t do that  isn’t enough, I just did it and so others will as well) 

 

Likewise for a scripted input, perhaps something like <div class=”Input_Field” role=”password”>: how do we guarantee end users that the scripted input *is* being treated like an actual password input, and isn’t a fishing spoof on non-sighted users? Companies like IBM would likely never do that, but IBM isn’t the only folks writing code out there :D



I also understand that this is needed for SVG, so my concern is not that we need a “something”, but rather, again, we’re asking browser vendors to change their UI based upon an ARIA attribute, something that they have refused to do in the past, as for example here: https://lists.w3.org/Archives/Public/public-pfwg/2015Sep/0172.html

 

JF

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Monday, March 28, 2016 5:37 PM
To: Léonie Watson <tink@tink.uk>
Cc: ARIA Working Group <public-aria-admin@w3.org>
Subject: Fwd: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

 

Leonie, 

 

Did my response address your concern? Microsoft confirmed that people were creating their own custom passwords in the wild and there is no ARIA role to indicate to the AT that this is a password and to tell the AT to NOT echo the password text as you type it. This would facilitate that. 

 

Rich

 

 

Rich Schwerdtfeger

 

 





Begin forwarded message:

 

From: Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> >

Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Date: March 20, 2016 at 3:59:23 PM CDT

To: tink@tink.uk <mailto:tink@tink.uk> 

Cc: ARIA Working Group <public-aria-admin@w3.org <mailto:public-aria-admin@w3.org> >

 

Leonie,

 

On the other hand, a screen reader could announce the characters being typed and not know to not do that. Furthermore, people are creating these things today and there is no way to know that the textfield is a password field. Would you prefer to not know? 

 

I don’t understand how your statement supports your argument. Incidentally,we did vet this with the Microsoft browser security people before agreeing to add it to the spec. Microsoft stated that people were creating their own password textbooks in the wild and there is no way for you to know that is what the textfield is. 

 

Rich

 

Rich Schwerdtfeger

 

 

 

On Mar 17, 2016, at 3:06 PM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk> > wrote:

 

From: Rich Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com] 
Sent: 17 March 2016 19:12
To: ARIA Working Group < <mailto:public-aria-admin@w3.org> public-aria-admin@w3.org>
Subject: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

This is a Call for Consensus (CfC) to the Accessible Rich Internet Applications (ARIA) Working Group on the following resolution:
1. Accept Joanie’s addition of a new password addressing Action 2004: 
 <https://rawgit.com/w3c/aria/password-role/aria/aria.html#password> https://rawgit.com/w3c/aria/password-role/aria/aria.html#password 

 

I object to the password role. Unless I’m missing something, it leaves open the possibility that an AT will behave as though the characters input into the field are obscured, when visually they may not be. A screen reader user cannot be certain that their password is adequately protected from being observed.

 

 

Léonie.

 

-- 

@LeonieWatson  <http://tink.uk/> tink.uk Carpe diem.