Re: Objection to password role

> On Jun 23, 2016, at 8:27 AM, Marco Zehe <mzehe@mozilla.com> wrote:
> 
> Hi Richard,
> 
> I would like to clarify one point specifically you asked about, and which is in fact my main concern:
> 
> 
> 2016-06-22 17:12 GMT+02:00 Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>>:
> 
>> Another point is that not every AT has a screen curtain or screen obfuscation feature like VoiceOver on iOS (and Mac?) and TalkBack on Android do. Off-hand, I know of no single screen reader on Windows who has this. So there is no way for a Windows user in public to make sure their screen is masked so that nobody can sneak-peek over their shoulder while they're entering text.
> 
> 
> So, how is a password role going to have any effect on that. This is the situation we have today. I am confused. 
> 
> With a input type="password", I can be reasonably sure that the browser masks what I type in. Even Fred's example is good enough in that, if that "show Password" checkbox is checked, I *know* that the password is written in plain text, but if that checkbox is unchecked and the script changes the input to be of type="password", the text is masked.
> 
> In an author-defined password field, with a role="password" on it, the screen reader tells me that this is a password field. So I am under the assumption, this field is masked. Less technical people won't even know the difference. But is it really? Can I be sure that the field is indeed not showing what I type to everybody who happens to glance over at my screen? The screen reader in this instance gives a false sense of security. Why? Because we from the ARIA spec tell authors that it is OK to declare even an ordinary input as role="password”.
You are absolutely right. The screen reader is lying to you. By the introduction of the password role we are working with ATVs to read the “rendered” text vs. lying. The reason they have been saying star star star is for performance reasons. The fact is they have not looked to see what was actually rendered. By isolating the reading of the rendered text vs. star star star or key echo for non-password fields we limiting the performance impact to only password roles. 

So, if the author has not masked the text you will hear the actual text rendered on the screen. If it is what you are typing you know something is wrong and you are indeed not masked. Joanie Diggs is doing this on Orca for all input types. I am working with Freedom Scientific to have JAWS read the rendered text. To exit CR we would require 2 AT implementations but that does not mean we will not be working vendors like NVDA. Freedom is already working on implementing it. 
> 

> Yes, I know you mentioned that you want a custom role for this special case, and want to have ATs do something special with anything that is declared role="password". But that takes time to implement. We need to get it into the different specifications first, get Apple on board to implement this special case in VoiceOver, and even when it's in the specs for ATK and IA2, some ATs like NVDA might pick it up quickly, but others like JAWS are, worst case, a year out from now to implement it. They have an anual development cycle, unless they're willing to shove it into one of their hotfixes, which might or might not happen. Same with Apple, this will probably, if we agree on it, not land in the initial Sierra, so it could be in an update or in the version of Mac OS that comes out next year. Or iOS 11.
> 
We understand iOS support is necessary. However, Apple does not pre-announce anything. We will be working with Apple. Frankly, this is a problem regardless. Sometimes you have a password label and you can’t tell if the app. is obscuring or not as it is just doing a keyboard echo. 


> And with all those questions around it, I am still for postponing this and giving this a well-thought-through and not rushed standing for ARIA 2.0 or an 1.5 if that will be pushed in-between. But the way this is now, it seems terribly rushed to me. And with an issue this important, I don't think we should do that.
> 
Marco, we have addressed all the issues pertaining to the spec and what the AT needs to do. I don’t see anything new being introduced in an ARIA 2.0 time frame. We have more guidance for authors than even the HTML input type of password. Leonie asked me to work on getting implementations and I already started Freedom Scientific on working on this. It is going to cost more money to have to go and rip it out and start over again in ARIA 2.0 when frankly, nothing is going to change. Also, ATs’ not addressing this issue leaves an accessibility and security issue open that we are already in the process of trying to plug. 

I understand your concerns but we know what is needed and we have already started down the path of addressing the issues and putting dollars on it. Delaying to ARIA 2.0 will not buy us anything. If we don’t put the changes in it is not like we are going to keep working on them. We are going to have to rip the code out that is already being developed and start over again. 

Rich

> Marco
> 
> P.S.: I am not yet certain I can make the call later, so if I cannot, please consider this my input on the discussion.