RE: Password role proposal: Freedom Scientific response

While I do have some concerns around user-awareness, my concerns are more focused on authors who might deliberately seek to fool non-sighted users. 

For the past 20+ years, we have had a mental concept of “password” on the web, complete with the expected behaviors and related security checks we instinctively expect of an input of “type=password”. These include a ‘guarantee’ (for example) that characters will be obfuscated on screen as a default, and that content entered into this type of input cannot be copied and pasted: these are standardized functions/features enforced at the browser level, and cannot be over-ridden by the content author.

We will not have that same confidence when any author can open a text editor and suggest to those users who are dependent on ARIA attribute information, that a custom widget is somehow “secure” because, “hey, I told you it is”. While the non-sighted user is more likely to believe this statement from a content author such as IBM or Google, on today’s web, they are but two of the millions of web-page authors who will be able to use this attribute, and without the ability to have some kind of behavior enforcement I assert this attribute will remain a serious security concern, ripe for misuse and abuse: <div class=”really_crappy_not_secure_input_widget” role=”password”></div>

 

Birkir, I think adding an additional attribute of “aria-custom-password” might help well-intentioned authors to better do the right thing; it still does not address the malicious author intent on fooling you into believing that something is more secure than it actually is. Rich has suggested that “…It will require changes in AT behavior and end-user education…” however I also assert that it will require some changes at the browser level: *if* browsers treat role=”password” the same way they treat type=”password” then we’ve got (I believe) a solution. 

 

Minus the browser support however, you are only addressing a part of the total ‘stack’ of tools and applications that is today’s web platform for non-sighted users. (i.e. for this, it’s more than just what the screen readers report).

JF



 

From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
Sent: Monday, April 25, 2016 9:57 AM
To: 'Rich Schwerdtfeger' <richschwer@gmail.com>; tink@tink.uk
Cc: 'Rich Schwerdtfeger' <schwer@us.ibm.com>; public-aria@w3.org
Subject: RE: Password role proposal: Freedom Scientific response

 

I am much more onboard with the idea if we add the “aria-custom-password” attribute along with the password role.

 

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Monday, April 25, 2016 9:35 AM
To: tink@tink.uk <mailto:tink@tink.uk> 
Cc: Rich Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> >; public-aria@w3.org <mailto:public-aria@w3.org> 
Subject: Re: Password role proposal: Freedom Scientific response

 

I would agree with that statement. Security should be what is important. 

 

I would interpret this is that if the ARIA spec. says ATs SHOULD expose the rendered text vs. the star star star approach then we should expect them to do that in the future as they have publicly committed to supporting ARIA.

 

If it is not in the ARIA spec. we may never see it in JAWS. 

 

This is our opportunity to get them to do things correctly by putting it in the ARIA spec. One thing we might do, however, is to also expose an additional attribute at the platform layer to indicate these are custom password roles. 

 

This would address some of John’s concerns about not knowing that this is a custom password field. It will require changes in AT behavior and end-user education. 

 

Thoughts? 

 

Rich

 

 

Rich Schwerdtfeger

 

 

 

On Apr 25, 2016, at 3:32 AM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk> > wrote:

 

From: Richard Schwerdtfeger [ <mailto:schwer@us.ibm.com> mailto:schwer@us.ibm.com] 
Sent: 22 April 2016 19:30
“Following up on Leonie's request to contact ATVs. I contacted Freedom Scientific's CTO regarding the changes we have put in the ARIA password role regarding what ATs should do in response to speaking the actual text rendered.

 

Statement from Glen Gordon at FS:

Freedom Scientific actively embraces ARIA. We recognize that this is an evolving standard and do our best to support newly added items in a timely fashion.”

 

Thanks for following up on this Rich. I understand that FS is reluctant to commit to a particular course of action, and I daresay they wouldn’t be the only ones if we were to reach out to other proprietary screen reader vendors.

 

“They have a policy to not commit to dates or product features publicly so this is as good as it gets.”

 

A commitment to implement the password role is understandably something FS might be reluctant to provide, but a general commitment to protecting consumer security would have been better than this.

 

As things stand we do not have a clear commitment from any screen reader vendor other than Orca, that the password role will be implemented in a secure way. This is troubling.

 

 

Léonie.

 

-- 

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