Re: Slicing and dicing password role discussion

I agree with Joanie that an important use case is author-constructed
HTML+JS password widgets.  I'm not sure it is different from a regular
<input> for the items in Michael's table, but it is important in other
ways.  Browsers will treat a <div> and <input> differently for form
auto-fill.  Also, a browser always knows the value of an <input> and that
they text isn't obscured.

Which brings me to an aspect I have not yet seen discussed:

*How do you convey the state of whether or not the text is currently
obscured?*

The common thread in all this debate is that A.T. users may not know
whether or not the visible text is obscured, and that A.T.s may not
correctly obscure spoken or other text.  But password field text is not
*always* obscured, and it would be anti-accessibility to insist it should
be: users with difficulty typing accurately (whether because of disability
or because of device) often need to confirm what they have entered.

One main reason password fields with <input type="text"> are still used is
to toggle password visibility, to let the user see what they have typed
into an element initially defined as <input type="password">.  (Search for
"toggle password visibility" to see multiple tutorials and plug-ins to
implement this pattern.)  I suspect that it would be an important use case
for <div contentEditable role="password">, too.

In addition, some browsers provide a toggle-visibility button on their
native password inputs.  I expect this will only become more widespread,
because of user demand on touch screens.

(Aside: The HTML specs do not require that <input type="password"> have any
text-masking at all:
https://www.w3.org/TR/html51/sec-forms.html#password-state-typepassword)

So what is really needed is an ARIA state attribute, representing whether
or not the text is currently obscured. along with appropriate changes to
the accessibility APIs, if they don't already have a marker
for native toggle-able password fields.

*Proposal for the purpose of discussion:*

An attribute named aria-password-masked, with values masked vs plain-text.
This should be required on any custom password widgets, but there should
also be defined behavior consisting to an unknown state if the attribute
was not specified, which would warn ATs that the browser does not know
whether input text should be obscured or not.

For <input> elements, the browser would define this state as a strict
native semantic that *cannot* be over-ridden by setting the aria-*
attribute.  If it is <input type="text"> (or any other input), the state is
always plain-text.  If it is <input type="password">, the state is
determined by the native "show password" feature, if applicable, or is
masked otherwise.

I would also recommend that UAs be *required* to treat the password role of
an <input type="password"> as "sticky".  In other words, even if the type
attribute is toggled by a script, the element continues to have a computed
role of "password".   This is as opposed to the default behavior of
treating it as deletion of the password field and insertion of a new plain
text field.  Author recommendation would be to explicitly provide the role,
but this would address a lot of existing content.

That's all very well and good.  But what if the AT doesn't know about the
password role and the aria-password-masked state?  As Michael said, it is
easier to get a change into major browsers and accessibility APIs than into
every AT in use.

One improvement would be to require browsers and/or accessibility APIs to
only reveal the masked value to ATs (as the text content of the element),
not the actual current value.  This doesn't solve the issue of screen
readers announcing every key press as you type, but it would eliminate the
chance of the password text being read out as the user navigated the form.

For author-created widgets, the browser would explicitly convert the text
content of an element to a masked version (e.g., bullet or asterisk
character repeated for the length of the text).  (This addresses, e.g., an
author-created widget that uses purely visual styles to obscure the text,
although authoring guidelines should of course discourage this!)

Another option (slightly more problematic) is to suggest that browsers
and/or accessibility APIs append a warning to the element's accessible name
for plain-text password fields or unknown-masking password fields.  This
would ensure the information was passed to users even if the AT didn't have
any special behavior for password fields, but it would be redundant content
if it did.  This might be something a browser could turn into a
user-controlled accessibility setting.

~Amelia