Security Evaluation Request

Virginie, 

I chair the ARIA Working group. We are considering a new ARIA role for ARIA 1.1 called “password”. The definition of this role is here.

https://rawgit.com/w3c/aria/password-role/aria/aria.html#password <https://rawgit.com/w3c/aria/password-role/aria/aria.html#password>

For those who are not familiar with ARIA, ARIA semantics are added to web content so that User agents can then convey semantic information to assistive technologies running on the native platform using Accessibility APIs for the platform. Examples of assistive technologies might be: a screen reader for the blind, an alternate input device for the mobility impaired, or a screen magnifier for low vision users. 

The reason for the new role is that authors are creating custom password input fields instead of the native HTML input type=“password”. By applying a role=“password” to the input element we can convey to the assistive technology that the author intended it to be a password field vs an ordinary text field. Since these are custom password fields it is up to the author and not the user agent to handle the obscuring of text. 

example: <input type=“text” role=“password”>

The browser would convey to the assistive technology that this is a password field vs. an ordinary text field. In this scenario the user should pay attention to the text rendered. 

Does your group believe this adds security risks? If so, what are those risks? 

Thank you,

Rich Schwerdtfeger
ARIA Working Group Chair