Re: Slicing and dicing password role discussion

After some off-list discussion with Joanie, I'm supportive with moving
ahead with the changes.

Joanie's text:
https://rawgit.com/w3c/aria/password-role/aria/aria.html#password

The important feature in Joanie's proposal (which I hadn't picked up on) is
that the AT should always be given the actual rendered text, whether that
is in a native input password field (obscured or plain text, depending on
native features), native input text field (plain text), or a custom
editable HTML element (obscured or plain text, depending on how the
author's JS is updating the text content in response to keystrokes).  A
"should" on authors of custom widgets requires them to obscure the value by
modifying the actual text content, instead of using visual-only styles to
obscure.

That addresses the issue of the AT reading out the current value by
mistake.  Conforming ATs that recognize the password role should also avoid
echoing keystrokes, instead reading the new character inserted into the
displayed value.

I still think it would be useful to have a standard ARIA state that
indicates whether or not the password is currently obscured, so that users
can know before they start to type.  But that could be an ARIA 2 feature.
I've added an issue to the tracker so it doesn't get forgotten:
https://www.w3.org/WAI/ARIA/track/issues/1022

I also think it's important -- until such time as that state exists and is
well supported -- that authors should indicate when a password field is not
going to obscure the text.

For ARIA 1.1, this could be as simple as an additional author "should".  My
sample text here:
https://rawgit.com/AmeliaBR/aria/password-role/aria/aria.html#password

This could be expanded on in the Authoring Practices Guide.  Here's a quick
demo I put together using <input> elements and a toggled type attribute, if
any of the APG editors want to use it as a starting point:

Editor (JSBin): https://jsbin.com/gagarohale/edit?html,js,output
Result: https://output.jsbin.com/gagarohale


Joanie had some concerns about whether this is really the best approach.
I'll leave it up to her to forward those to the list.

That leaves one issue remaining from my original email.  To address
existing content (that does not use role="password" explicitly), would it
be possible to have user agents treat a toggled native password element
(e.g., an <input type="password"> that is changed to type="text") as if it
is still the same element with the same role?

This would be material for the HTML-AAM, if a normative requirement is
desired. I'd be interested to hear from implementers whether it sounds like
an easy fix or a horrible mess.

~ABR