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

Hi Rich,

The password role could be useful, if implemented consistently to match
the non-assisted interface. I was simply pointing out the possible risks
of inconsistent implementation.

As a security consideration, I would suggest a bi-directional
requirement such as the developer/implementor MUST ensure that the
visibility of characters matches between the default interface and that
available through assistive technologies.

Hope that helps,
--Wendy


On 03/28/2016 05:53 PM, Rich Schwerdtfeger wrote:
> Wendy, 
> 
> I am reading your response. So, if we have no password role there is nothing telling the assistive technology to not echo the characters out your device speaker while you are entering text. 
> 
> If an author takes the time to actually put a role=“password” on a password field it is far more likely that the author who created the custom password field would not want to expose the characters because it is a password field.
> 
> https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0023.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0023.html>
> 
> Why would any developer add a password role to an input field just to silence only a screen reader from echoing text? I don’t understand the logic. It is much harder to get a developer to remember to add a password role. Now, we can help this by saying that the author MUST obscure the text entered if a password role is applied to an input field. Would that satisfy your concern?
> 
> Incidentally, we ran this by the Microsoft Edge browser security team who did not see any issues. They said, authors were already creating custom password fields. 
> 
> Rich
> 
> 
> Rich Schwerdtfeger
> 
> 
> 
> 
> 


-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Tuesday, 29 March 2016 14:07:34 UTC