Re: Slicing and dicing password role discussion

Looking again at Michael's table of possibilities [1], It seems that one of
the main concerns is not represented.

The concern (as originally raised by Léonie on 17 March [2] and re-iterated
on 2 April [3], among many other messages) is that most ATs *do* support a
password role (as defined in the accessibility APIs), but they do *not
*necessarily
support it in the way ARIA would want them to.  In particular, many screen
readers provide their own masking to all values read out & all keys typed,
regardless of the value exposed by the browser.

If browsers expose role=password elements in the same way they currently
expose native password elements, users of these existing ATs may get false
assurances of security in negligently or maliciously coded websites, and
will not get a "show password" functionality if implemented by the author.
In either situation, text may seem to be obscured when it is not.

Since that seems to be the main obstacle to adopting role=password, perhaps
what is needed is to circumvent all existing implementations and approach
this as a *new* enhancement to plain text fields.

Browsers could expose role=password, but do so in a *different* way than
native password fields.  E.g., define a new "custom password" subrole or
state, as a modifier to the text field role, in all the accessibility
APIs.  It would require more code to implement for all concerned, but would
allow the ideal implementation to be pursued, without problems caused by
incompatible existing software.

To support the "custom password" role:

   - User agents MUST always expose the actual rendered text content of all
   password fields (custom OR native), whether this is currently plain text or
   substituted characters.
   - ATs MUST use the provided text content when reading the value of a
   custom password field.
   - When the user is entering text in a custom password field, if an AT is
   set to normally echo all keypresses, it SHOULD instead read back the
   inserted text value as exposed by the user agent.  If that is not possible,
   it MUST suppress key echo altogether.  The AT MUST NOT provide its own
   masking.
   - ATs SHOULD treat native password fields equivalently to a custom
   password field.

If *either* the browser, the API, or the AT has not yet implemented the new
role, then the experience of a custom password field is the same as it is
currently: it gets presented as a plain text field.

The downside is therefore that a user does not get an enhanced experience
unless all three links in the chain have adopted the new approach.
However, no user gets a false sense of security, with the impression that
text is masked when it is not.  So security is never *worse* than it
currently is.

The other downside, of course, is the extra time and work it will take to
implement and the ongoing requirement for two different password-element
mappings.  Looking at the current API mappings for native password elements
[4], this approach would seem to cause the most headache for ATK, which has
a distinct major role for password fields.  All the other APIs use a text
field role and a password-related modifier (subrole and/or state), so it
would be a case of adding a second modifier option.

Because of that ongoing requirement for extra code, this is definitely not
an ideal solution.  But it provides a path forward that does not introduce
any new problems beyond those that currently exist.

[1]:
https://lists.w3.org/Archives/Public/public-aria/2016Mar/att-0231/password-role-exploration.html
[2]:
https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0018.html
[3]:
https://lists.w3.org/Archives/Public/public-aria-admin/2016Apr/0014.html
[4]:
https://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-input-password