Richard, and all,
Some people mentioned also other possibilities do implement the password role outside ARIA with password or web component, I will leave that question to the web technologist.
My concern is more aligning a user context, and the behavior of the browser/tool : aka taking special care of the data. It seems to me that in terms of security, the creation of the role, password, is valuable if you have a secure expected usage associated. By secure, I mean, making sure the content is protected from direct reading on the screen, special protection against (including unexpected cloning or storage) *and* that the user is getting a sense of the sensitive situation he/she is dealing with, while entering the password (as mentioned by Chaals and others).
Do you have the feeling that this conversation helped you to take a decision on the password role.
Note that the Web Security IG will soon have a call, where we could address the remaining questions that you have on this.
Regards,
Virginie
From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: mardi 5 avril 2016 20:39
To: GALINDO Virginie
Cc: public-web-security@w3.org; ARIA; Mike Cooper
Subject: 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
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
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.