Re: Objection to password role

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>:

>
> 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".

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.

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

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.