Re: Objection to password role

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

Received on Friday, 17 June 2016 18:43:28 UTC