Re: Slicing and dicing password role discussion

All,

Michael wrote:

> To me, the best choice seems we should negotiate an exception to the
principle that ARIA does not impact UI, and say that because of its
security implications, user agents need to do input masking on the password
role, not just tell the AT about it.

Given that there *are* security concerns here, it strikes me that at a
minimum we reach out to the Web App Security Working Group for some
feedback/input (https://www.w3.org/Security/) as was previously suggested
by Wendy Seltzer.

I have also reached out personally to both Google and Mozilla folks who
might have a stake in this discussion, asking them for their initial
thoughts on this topic. My Google contact has confirmed forwarding the
thread on to their internal security people at Chrome. Standing by for more.

Getting support from all of the screen readers seems reasonable if not
difficult, but I suspect that if we were to get support from the browser
vendors that it may make things even easier, and I for one don't want to
give up on that possibility without at least trying.

JF

On Thu, Mar 31, 2016 at 8:47 PM, Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> 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
>
>


-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion