Re: 7-Day CFC: Move the Password Role to ARIA 2.0

Hi Jason, 

I am moving my response to the ARIA working group list. 

Those are excellent points that we should take up in ARIA 2.0. The turning point on the decision to move this was that people could not specifically point to a sufficient list of sites that actually implemented a custom password. 

This started out as part of an effort to synchronize HTML 5 semantics with ARIA. That was followed by a collection of security concerns which I believe most were addressed but for those that did not feel they were addressed there was nothing in the wild that supported delaying the release of ARIA 1.1 to address those concerns.

I agree we should not rehash old issues that were addressed in 2.0 and focus on what is not sufficient and possible alternatives. It is my hope the the W3C security experts come up with an alternative for HTML password. Passwords in general are problematic, in that you have to remember them. Many, especially the aging population, begin to use passwords that are easy to remember across multiple sights exposing them to greater security risks and identity theft. As I understand it the security interest group is looking at alternatives. Hopefully, enough time will pass to come up with a solution before we take this up again.

Rich 



Rich Schwerdtfeger




> On Jul 1, 2016, at 10:07 AM, White, Jason J <jjwhite@ets.org> wrote:
> 
> While I have no objection to this CFC, I am concerned that the password discussion may well have moved beyond the point of diminishing returns, and that it has reached the stage at which confinement of the remaining issues should be acknowledged and decisions made. Specifically, concerns raised about this role have been thoroughly considered by the working group more than once. Many of them have turned out to be generic, and legitimate, problems either of custom password widgets, or of password authentication as implemented on the Web. Others (such as appropriate treatment of widgets with a password role, notably suppression of keyboard echo by screen readers) have been addressed in the draft as strongly advised guidance for implementors.
> It seems clear that the best way to proceed would be to recognize that the issues are confined as documented in Michael Cooper’s helpful summary to the group, and to make decisions about the limited questions which remain. The idea of an aria-masked property or of a “masked” role remains as a second option which the group could choose. I am comfortable taking this up in ARIA 2.0, but preferably with a process that focuses on the issues which are specific to the proposed introduction of the role, and the alternative proposal which has been advanced.
> 
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
>