[Role Parity] What do we do about input (type=password)?

[joanmarie]

No description provided.

[LJWatson]

My concerns with the password role still exist. unless we can guarantee screen reader implementations close the security gap, I don't think we can create this role in good consciounce.

[joanmarie]

@LJWatson understood. Related question though: Since one of the primary motivators of parity is to make custom elements / web components accessible, do we happen to know if there's going to be a custom password element?

[LJWatson]

Since one of the primary motivators of parity is to make custom elements / web components accessible, do we happen
to know if there's going to be a custom password element?>

There is already at least one example password Web Component available on webcomponents.org

[jnurthen]

There is already at least one example password Web Component available on webcomponents.org

Thanks. This example seems to use input type=password as a child element so could be made accessible without a password role.

[jnurthen]

As detailed at https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#no-consensus-yet-will-do-for-1-3 moving to 1.3

[johnfoliot]

There are significant security concerns about this suggestion (role="password") which have been previously discussed in the ARIA WG.

As Léonie notes, until such time as both screen reader vendors AND browser vendors ALL agree to treat this proposed role with all of the same security considerations currently afforded input type="password" (on-screen masking, obfuscated audio output, etc.) I would be prepared to object to the creation of this role, up-to and including a Formal Objection, based on these security concerns.

[jnurthen]

@johnfoliot threatening a formal objection when moving a milestone to a later release seems excessive. We are all aware of your opinions on this topic.

[johnfoliot]

Thanks James, Given that this proposed aria attribute has been previously discussed and (I thought) previously resolved (rejected), I now find it curious to discover it is still being discussed two years later. And while I understand that it has now been moved to a proposed later milestone, without concrete movement from the screen reader and browser vendors, my concerns and objections will remain then as well. I mean no ill-will to the Working Group, however my concerns over this proposed aria attribute remains at a Critical level until such time as all of the vendors indicate robust and universal support to address the significant security concerns this proposed attribute might bring, and I am simply signalling that to you (again). JF

…

On Fri, Sep 27, 2019 at 12:21 PM James Nurthen ***@***.***> wrote: @johnfoliot <https://github.com/johnfoliot> threatening a formal objection when moving a milestone to a later release seems excessive. We are all aware of your opinions on this topic. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#935?email_source=notifications&email_token=AAJL447CXW7L4SHQMECSBVTQLY6IDA5CNFSM4HEUN5YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZR6GI#issuecomment-536026905>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJL44ZKJFBD4US3GNGEFQ3QLY6IDANCNFSM4HEUN5YA> .

-- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[jnurthen]

1. The working group was been asked to provide role parity to HTML in the 1.2 timeframe
2. Issues were logged where there is not parity with HTML
3. Issues for which there is no clear path forward have been moved to 1.3 at this time.

As I previously said and will say again - the working group is well aware of your objections - and this is one of the reasons we did not propose providing role parity in ARIA 1.2 for password fields. There is no reason to make them again every time minor housekeeping is done on an issue.

[johnfoliot]

Thank you James JF

…

On Fri, Sep 27, 2019 at 2:49 PM James Nurthen ***@***.***> wrote: 1. The working group was been asked to provide role parity to HTML in the 1.2 timeframe 2. Issues were logged where there is not parity with HTML 3. Issues for which there is no clear path forward have been moved to 1.3 at this time. As I previously said and will say again - the working group is well aware of your objections - and this is one of the reasons we did not propose providing role parity in ARIA 1.2 for password fields. *There is no reason to make them again every time minor housekeeping is done on an issue.* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#935?email_source=notifications&email_token=AAJL446OXELMNTQFSSK5BVLQLZPWNA5CNFSM4HEUN5YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7Z5RZQ#issuecomment-536074470>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJL4454KUWVI2QFSACYWUDQLZPWNANCNFSM4HEUN5YA> .

-- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[joanmarie]

See also discussion in #166

[annevk]

I think the way to solve this is to not have a public API for the password role (i.e., role="password" is the same as role="gibberish"), but ask it to be implemented for at least <input type=password>. Then if that implementation is solid, make role="password" work as well.

At least, from my reading of @LJWatson's post the primary concern is how this is rolled out and tested and it seems we could be pretty flexible with that.

[johnfoliot]

@annevk If we have a role of "password" it must operate exactly like the native input type of "password" W.R.T. Screen Reader behavior: visible on-screen text is replaced with "*" AND the screen reader announces "star, star, star..." (or similar).

However, this may also contravene the long-standing axiom that ARIA does not effect any visual change to the visual UI. Here however, (or a similar custom component with the same intended functionality) needs to effectively override the semantics AND visual behavior of the native input type of text, effectively turning it into <input type of "password"> by obfuscating the text inputted both visually and auditorally.

If the browser vendors are in agreement to make this exception to the long-held "rule", it would break the log-jam IMHO

[annevk]

I don't think we could guarantee it to be hidden visually. A site today could also listen for the keyboard events and display things, no?

[jnurthen]

I don't think we could guarantee it to be hidden visually. A site today could also listen for the keyboard events and display things, no?

Some flavours of Amazon’s login page do this today.

[LJWatson]

@annevk suggested:

I think the way to solve this is to not have a public API for the password role (i.e., role="password" is the same as role="gibberish"), but ask it to be implemented for at least . Then if that implementation is solid, make role="password" work as well.>

Can you explain this more?

[annevk]

Define the private API, ensure it meets the needs, is implemented, and is what <input type=password> uses, and only once all that is done add a public API. (Another way of describing this is ensuring all software involved agrees on the underlying model before exposing an API to that model.)

[LJWatson]

Thanks @annevk, and also @stevefaulkner for talking through the proposal.

If I understand the proposal, the first step would be to map the current behaviours of the native password input to role password, then once that was robustly supported open up the API so it could be set by authors? If so this seems like a good approach I think.

[7mary4]

We have a tax form that includes personal information that a person may want to hide visually. For instance, their social security number. We tried using type="password" but this causes undesirable autocomplete functionality.

We tried using type="text" and visually obscuring the text, but the value was still announced to a screen reader.
This led us to try aria-valuetext, which is not valid for a text input. But this brings up an instance where an input may have a value, but we'd like to pass a different value to the accessibility api.