RE: Risks the password role does create

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Wednesday, June 22, 2016 6:47 PM

In a perfect world, when browsers address this crater of a hole (type="password") through tightened security restrictions, it would be awesome that the role of password would also get the same treatment. Ideally, an author could use *that* role value to actually impart the behaviour natively in the browser (rather than depending on custom scripting to do the obfuscation part), so that role="password" is the 'one-stop-solution' that both delivered the on-screen functionality, drove the AAPI, and locked-down the input-string all in one.
[Jason] We need better security mechanisms than passwords. I know I’m not alone in having far too many to remember, so they’re stored in password managers. Biometrics present their own accessibility challenges, but they’re a better solution than passwords. Let’s take this up in the Research Questions Task Force if APA concurs.

________________________________

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.

________________________________