Re: Objection to password role

"
Thus IF authors are creating custom password fields, and IF screen
reader users do have a right to expect that their screen reader will not
disclose their password via key echo, THEN screen readers need a means
to reliably identify that an input is a custom password field. Adding a
role provides that means.
"

An aria-masked attribute would do this more efficiently and provide
better info to users.
That would also help users distinguish between native password fields
and author created ones as well as knowing when other important input
fields mask the user input as it is typed.

After all, most password fields are labeled password,.
A screen reader user cannot easily tell whether the word "password"
announced by the screen reader refers to the type of input or the
input's label.

And it doesn't appear that there is much demand for this role from
people using custom password fields today, at least if the lack of
examples from the wild is an indication.
This demand may grow in future, but we are not talking about taking
this role off the table completely, but to prioritize more important
issues affecting users with disabilities today while making sure to
balance the need for the role with its possible harmful effects on
users.



On 6/17/16, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> On 06/17/2016 06:10 AM, Michiel Bijl wrote:
>> All,
>>
>> A lot has been said about the password role. Security problems, lack of
>> good use cases, and difficulties for users. Despite all that, it seems
>> it will still get into the final specification. I would like to quote
>> the ‘Priority of Constituencies
>> <https://www.w3.org/TR/html-design-principles/#priority-of-constituencies>’
>> (thank you Jonathan Kingston for reminding me
>> <https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/>):
>>
>>> In case of conflict, consider users over authors over implementors
>>> over specifiers over theoretical purity.
>>
>> How is adding a role—where one of the use cases is preventing the use of
>> password managers—helping the users? How does that adhere to the
>> priority of constituencies?
>
> As I've stated on multiple occasions, I'm perfectly fine with removing
> the role from 1.1. But to answer your question with another question, do
> users who are blind have a right to have their screen reader protect
> their password from disclosure via key echo? I think they do.
>
> Thus IF authors are creating custom password fields, and IF screen
> reader users do have a right to expect that their screen reader will not
> disclose their password via key echo, THEN screen readers need a means
> to reliably identify that an input is a custom password field. Adding a
> role provides that means.
>
> Without having such a means, it is up to the user to ensure his/her
> password is not disclosed via key echo. That is certainly doable
> already. 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.)
>
> Having noticed that the input with name of "password" is not really a
> password field, screen reader users who have enabled key echo can use
> their screen reader's command to temporarily toggle off speech. Or they
> can use their screen reader's command to cycle to no key echo. Or they
> can plug in head phones. Or they can mute sound.
>
> (At some point earlier in the discussion, someone pointed out that not
> all screen reader users know the commands to toggle speech output or
> cycle through key echo settings. But, again, in a world with
> author-created fake password fields, this knowledge is probably
> something users who are blind should acquire. And compared to all the
> other skills one needs to access web content non-visually, these
> commands are just not that hard.)
>
> In my mind, and getting back to your original question, the only
> motivation justifying adding the role was to help users.
>
> I would rather authors just used native host language password fields.
> But if authors refuse, and if we cannot do anything about that, at least
> we can try to make the resulting user experience suck less for users who
> are blind.
>
> That said, put me down for wanting to remove it from 1.1. We've invested
> far too much time and energy on something we still don't have consensus
> on when we're already past due on getting 1.1 to CR.
>
> --joanie
>
>
>


-- 
Birkir Gunnarsson, CPACC
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Friday, 17 June 2016 19:10:52 UTC