Re: Objection to password role

John, 

Unfortunately, when you have a custom password the text is not always masked. In fact, it may not be to help the end user who cannot remember what they typed. Heck, I forget what I typed often. It is particularly frustrating as some systems are intolerant and will lock you out even after the first try. 

I will also tell you that the HTML password is misleadingly secure. You can, in Firefox, inspect the object value and read the password. These often get cached with pages. So anyone can actually bring up a login page for some sights in the browser where the password is autofilled and read the text. 

What Brad Hill was trying to explain to us when he gave the Web Security IG response is that you need to look at the security icon at the top of the page to let the user know whether what is there is indeed secure. However, as I mentioned, with HTML there is a way around it. The link to Brad’s response is in my response to Michiel. 

So, masked will not work. What we can do is map the password role to a “custom password” type role in the accessibility api and achieve the same thing. This would also alert the user that this was not the standard HTML password field. I had suggested this previously. We could also indicate in the ARIA text that a role of password is a “custom password.” … however, for the reasons I mentioned masked would be insufficient and would mislead the user. 

I believe your warning text was excellent and is still applicable here. However, if we do this we need to know this is the end of the road. We cannot keep rehashing what has already been discussed. I did propose addressing this in the mappings previously. 

Regards,
Rich


> On Jun 21, 2016, at 1:34 PM, John Foliot <john.foliot@deque.com> wrote:
> 
> Hi,
> 
> I've pretty much stayed out of this discussion this time around, but I think Jason has asked what I consider to be one of the fundamental questions, albeit not explicitly.
> 
> > What I don’t understand in this entire discussion is why some people seem to think that adding a password role would make the situation described in the above quote by Rich worse than it is now.
> 
> 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 <https://lists.w3.org/Archives/Public/public-aria/2016Apr/0054.html>.) 
> 
> This, I believe, is also what Virginie Galindo (WSIG) was referencing when she wrote:
> 
> “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).”​ - https://lists.w3.org/Archives/Public/public-aria/2016Apr/0160.html <https://lists.w3.org/Archives/Public/public-aria/2016Apr/0160.html>
> 
> Now you likely all already know this, but you also probably don't actively think about that when presented with a password input. So my overarching concern has always been not just what the screen reader software speaks aloud when you are interacting with the input, but also what you *understand* - that for a non-sighted user, they must *trust* that it is, indeed, a real password input in all of it's presentation (and not just playing one on TV). This is why I pushed hard for the warning language I presented.
> 
> Joanie pointed out the minute difference between a native password input and a custom password input, by noting that the screen readers will read out either "slightly" differently (or, at least, that is her assertion):
> 
> > For instance, given:
>     
> ​​<input type="text" aria-label="password" />
> 
>  When the input gets focus, a screen reader will say something like "password edit" or "password entry". In contrast, given:
> 
>      <input type="password" aria-label="password" />
> 
>  Those same screen readers would say something like: "password edit protected" or "password password text". So if the user refrains from typing until the screen reader has completed its output, that user should be able to distinguish a real password input from a fake one.
> 
>  (Most users I know hear "passwo" and immediately start typing, cutting off the screen reader's output in the process. Such a user would then likely be unhappy to hear his/her password being announced via key echo.
> 
> ​ But if we do live in a world with author-created fake password fields, that might be a habit users who are blind should get out of.)
> ​- https://lists.w3.org/Archives/Public/public-aria/2016Jun/0117.html <https://lists.w3.org/Archives/Public/public-aria/2016Jun/0117.html> ​
> 
> Finally, I will note that both Birkir and Jason​ - both are self-identified SR users - have recently ​entertained a rename to something like role="masked", and honestly I would support that in a heart-beat, as it makes clearer what exactly is happening (the characters are supposed to be masked on-screen), and the proposed functionality of the screen readers would remain the same as for the proposed role="password". So then it just becomes a nomenclature issue, but one that doesn't suggest properties on the faux input that don't exist, which I assert the term "Password" does suggest today.
> 
> ​JF​
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Jun 21, 2016 at 11:57 AM, White, Jason J <jjwhite@ets.org <mailto:jjwhite@ets.org>> wrote:
>  
> 
>   <>
> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
> Sent: Tuesday, June 21, 2016 12:38 PM
> 
> 
> People are doing this already. One example is what if you want the user to see the password they are typing based on their request? You are not going to do that with the HTML password unless you write it elsewhere. Our argument is that people are doing this already. CSS does things that encourages people to break accessibility too. That does not stop them from putting it out the door. JavaScript encouraged people to create custom controls that were not accessible. We invented ARIA. We did not say Don’t do that. Also, it is much more work to do something other than use an HTML password so why would they do it unless they needed to provide additional functionality? I challenge you to tell developers not to use JavaScript because it encourages them to create things that are inaccessible. 
> 
>  
> 
> I would also argue that putting role=“password” on an element does nothing advance the work of someone trying to create a custom password. So, it encourages nothing. In fact, John Foliot placed some excellent warning text about this to address that point which was passed as a decision. 
> 
>  
> 
> [Jason] What I don’t understand in this entire discussion is why some people seem to think that adding a password role would make the situation described in the above quote by Rich worse than it is now. Adding the role would make the custom password widgets more accessible, which can only be desirable. We’ve already addressed the question of how assistive technologies should implement it, and I haven’t noticed any attempt to reopen that issue.
> 
>  
> 
> To be clear, I don’t want to see the progress of ARIA 1.1 toward Candidate Recommendation delayed by continued controversy over this feature. I do not object to the inclusion of the password role, but I don’t mind if it’s deferred to ARIA 2.0 (not, as should be clear, that I’m advocating such deferral).
> 
>  
> 
> 
> 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.
> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion