RE: Objection to password role

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Tuesday, June 21, 2016 2:34 PM

The problem with "password" is that for over 20+ years of the internet, the idea of a password field has earned some presumed security and privacy features that you often don't think about - certainly not actively. For example, if you type a character string into an input type="password", you cannot then highlight and copy what is rendered on screen, and paste it into a text editor to see the string - it will copy and paste as "stars". That's just one example, there are others (for example "...browsers are likely to save the value for autocomplete  unless they explicitly recognise the role as defining a real password  field.” - Chaals McCathieNevile (Yandex) - https://lists.w3.org/Archives/Public/public-aria/2016Apr/0054.html.)

[Jason] So the argument is supposed to be that a screen reader user can distinguish <input type=”password”> by how the assistive technology handles it, from custom password widgets, thus having an advantage that the non-AT user lacks. Then we’re supposed to believe that such screen reader users go on to make certain assumptions that may or may not hold. I appreciate John’s setting out this position. I don’t find it convincing since I think such users, to the extent that they make these assumptions now, will have to learn not to make them.

The situation is no different from that of a password field in a desktop or mobile application, which for all the user knows could be a widget provided by the platform or a custom widget supplied by the application that behaves in subtly different ways. Thus the ARIA proposal simply brings the Web use case into line with desktop and mobile applications (where, to the best of my knowledge, it’s possible to write a custom password widget and to make it accessible to screen reader users by declaring it in the accessibility API).

If it’s a choice between this group’s declining to make custom password widgets accessible, and not alerting the user to the possibility that the application author may have violated certain assumptions, then my vote is strongly in support of making the custom fields accessible – and more secure by suppressing keyboard echo. That is, while I think John has well articulated an objection, I’m not persuaded that it’s a good case for changing this group’s position regarding the password role, namely, that it should be included in ARIA.

Note also that the very act of deciding to enter sensitive information into a field requires a certain elvel of trust in the security of the application. If I knew I were confronted with a custom widget rather than an <input type=password” would I have an additional, substantial reason not to enter sensitive password text into it? My answer is: “probably not”, or at best, “not much”. The decision would be dominated by my other reasons to entrust (or not to entrust) the application with sensitive information. I don’t think knowing whether a password field is custom or not is significantly going to affect anybody’s decision about whether to enter password text into it; and that’s the important choice to be made by the user in this context.


________________________________

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.

________________________________