Re: Slicing and dicing password role discussion

Hi Amelia, 

We can’t mask passwords going to ATs. The user needs to know what was put on the screen for security reasons. The user can tell if something is masked if the based on what the author puts on the screen. For security reasons this would be better than depending on the author to tell whether it is masked. Amelia is going to send you a revised draft text for you to read before posting it to the admin list. 

Rich
Rich Schwerdtfeger




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