Re: Slicing and dicing password role discussion

Ok.

Regarding toggling the role, if the main role stays as text and the sub role changes (implementations vary per platform) and the ATs are programmed to look for a subtitle change then yes. However, role changes are not expected by ATs. They monitor state and occasionally property changes for roles.

Rich

Sent from my iPhone

> On Mar 31, 2016, at 7:02 PM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote:
> 
> 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