Proposed ARIA password role

Let me ask you a question: Would you enter your password into a password field, if you couldn’t be confident it was protected from being viewed by other people? The answer is probably not, but a proposed ARIA role could put screen reader users in exactly this position.

When you use <input type=”password”> to create a native password field, the browser obscures the characters that are entered into the field, and prevents them being discoverable with cut/paste. At the accessibility layer the field has a role of “text” and a state of “protected”, which informs assistive technologies like screen readers what type of field they are dealing with. When a screen reader encounters a native password field it automatically stops echoing keys as they’re pressed, and instead announces the characters as they’re rendered inside the password field – as asterisks for example.

When you use a <div> or <span> to create a custom password field you must obscure the characters with scripting, and there is nothing you can do to protect against cut/paste discoverability. At the accessibility layer there is no role or state available to assistive technologies, and because screen readers do not recognise it is a password field they continue to echo keys as they’re pressed.

So there are security issues with custom password fields, irrespective of accessibility. There is no way to tell whether a password field is native or custom, and no guarantee that your password is adequately protected from discoverability.

There are also accessibility issues. It is not possible for assistive technologies to tell that it is a password field (or even a text input), and nothing to stop screen readers announcing the characters of your password as you type them.

To solve the first of the accessibility issues, a password role has been proposed in ARIA 1.1. When applied to a custom password field, the role will inform assistive technologies that the field should be considered a password field. The proposal will likely be extended to make the role more specific – to inform assistive technologies that it is a custom password field.

The password role also attempts to solve the second accessibility issue. According to the password role definition, when the role is applied to a custom password field screen readers should stop echoing keys as they’re pressed and instead announce only the characters as they are rendered inside the password field.

Neither of the other security issues with custom password fields will be solved by the password role, but ARIA is not the place to solve those problems. They do need to be solved (and soon), but it is a much wider discussion than accessibility alone.

If it sounds as though the ARIA password role is a good solution, there is a catch. The role itself is a step in the right direction, but if screen reader vendors don’t implement it properly it could leave screen reader users vulnerable. If the screen reader continues to announce the characters of your password as they’re typed, someone may overhear them. If the scripting fails or is implemented badly, it could also leave screen reader users uncertain about whether their password was displayed on-screen in plain text or whether the characters had been obscured because all they would hear would be the characters of their password echoed back to them. This also leaves open the possibility, however unlikely, of a malicious attack targeted at screen reader users.

So here is the catch… there is no requirement for ARIA to be tested in screen readers before it becomes an official W3C standard. This means the password role could be put out there in the wild with no reassurance that any screen reader had implemented it properly.

Each feature of a W3C standard is expected to be properly implemented and tested in at least two user agents. For most standards this means two shipping browsers or browser engines, but ARIA is unique in that it is the only standard that requires a screen reader to be used.

Until now this hasn’t been a problem. Testing ARIA implementations by examining platform accessibility API and browser support has been more than sufficient. If a screen reader vendor then implemented support for a feature incorrectly it might cause a feature not to work as expected, or a role to be misidentified, but irritating as that might be it does not represent a security risk for screen reader users.

The upshot is that the password role will offer better security for screen reader users if it is implemented correctly, but unless we can be sure it is implemented correctly there is a risk to screen reader users.

Testing ARIA with screen readers seems like the sensible thing to do. Screen readers are dependent on the accessibility APIs and browsers, but they also play a role in correctly supporting ARIA. If the ARIA Working Group chose to include screen readers in its testing for ARIA 1.1, even if only for the password role, that would be another step in the right direction.

There is another option, but it involves breaking the browser’s “fourth wall”. If browsers implemented the same behaviour for custom password fields using the password role, as they do for native password fields, the security problems would go away – all of them, not just the accessibility ones.

Browsers have traditionally held back on providing functionality or making changes to the UI, based on ARIA. Custom password fields give us a compelling use case for revisiting this idea though, so perhaps the more progressive browser vendors will look again at their position on this. Then again, perhaps it is time to look beyond ARIA for an HTML solution that will give us the ability to imbue custom controls with native behaviours.

Update 6th November 2016: On 7th July 2016 the ARIA WG agreed to move the password role to ARIA 2.0. This move was prompted by the realisation that no clear use cases for the role existed.

However, at a joint meeting between the ARIA WG and Web Platform WG on 19th September 2016, there was discussion about ARIA 2.0 roles having parity with all HTML elements. If this goes ahead it would mean the inclusion of the password role by default, as it would be mapped to <input type="password">. It may be that the browser vendors will look again at the role and imbue it with the same characteristics as its native HTML counterpart, but for now the issue of ARIA role and HTML element parity remains open for discussion on Github.

7 comments on “Proposed ARIA password role”

Skip to Post a comment
  1. Comment by Amanda Rush

    Despite my love/hate relationship with Aria, I think I support this. Admittedly, I don’t like all the “ifs” that screen readers present, and I’m still getting the sneaking suspicion that a lot of this accessibility stuff is literally flying by the seat of our pants, (which makes me very uncomfortable as a developer and a security enthusiast), but I say we give it a shot. Can’t be worse than what we’ve got now.

  2. Comment by Šime Vidas

    I wonder what custom functionality could be so important for a website, that it would choose to use a div or span element instead of the standard element a password field. Do websites have legitimate use cases for doing this?

  3. Comment by Steve Sawczyn

    In an ideal world, custom password controls would not be a thing. Alas, I think this is exactly the situation for which ARIA is intended, to help provide support for these types of situations. Even though the road ahead will be a long one in terms of getting screen reader support, I hope this proposal becomes a reality.

  4. Comment by Sina Bahram

    This makes me incredibly uncomfortable. There are four logical possibilities that I feel we should examine here.

    1. characters are not hidden and screen readers think they are.

    2. characters are not hidden and screen readers think they are not.

    3. characters are hidden and screen readers think they are.

    4. characters are hidden and screen readers think they are not.

    I think we can all agree that #2 and #3 are fine e.g. they reflect the sighted experience.

    But let’s examine situations #1 and #4.


    Observe the following one liner.

    <input type="text" aria-role="password" /

    When a screen reader user tabs to such a field in this brave new world of aria-password, they have absolutely no guarantee that their characters are being hidden. This can have disastrous effects in presentations, remote desktops, screen shares and captures, office environments, etc.


    This causes trepidation for users because they think that they are typing their password into an insecure field, and I get it, but the security risk is minimal here.

    We need to recognize and address potential user discomfort, and train developers better, but not at the expense of user security.

    The privacy issues that arise from a lack of role=”password” are very similar to those that arise from a sighted user glancing at a colleague’s keyboard or over their shoulder. The same advice applies to all users: enter in secret information securely e.g. tilt your monitor, wear earbuds, etc.

    1. Comment by Amanda Rush


      I hear you on all of this, and I would agree with you that a password role is unnecessary, if it weren’t for the fact that developers write custom controls every day, as you pointed out to both myself and the WordPress Accessibility Team when we both recommended that they not do so. So, since you’re discouraging others from recommending against custom UI elements, I feel that in order to remain consistent with this position, you have to agree that this is a necessary addition to the Aria spec, despite the security implications.

  5. Comment by Steve Decker

    Wouldn’t this role give users an even greater false sense of security? If I type in a PW field, and my screen reader echos my keystrokes, I will at least be aware that they may not be hidden. However, if this were used, a screen reader may stop echoing my keystrokes while the password is shown visually. I also don’t think any average user will know or care if a PW field is native or custom, and what would they do with this info, if they did know. Further, many sites are starting to add an option to show or hide your PW. This role would introduce another potential A11y bug, if it’s not toggled or removed once a link is toggled to show your password, I.E. VoiceOver may still be hiding the PW characters, though I’ve elected to “show password.”

    Finally, some screen readers, like VoiceOver stil read the characters you touch while exploring the screen, even though they are silenced once entered, and this is the case even with native PW fields. THe practical implication is that you do need to take some proper precautions, so your PW isn’t heard, as Sina suggested.

  6. Comment by Allan

    No. Just… no.

    On the one hand, adding a new role to overcome issues that are already out there in the wild is admirable. Solve problems people are having. It’s good work.

    However, I would echo the comment from @Šime Vidas : what are the use cases?

    @Steve Sawczyn says “… this is exactly the situation for which ARIA is intended, to help provide support for these types of situations.”

    I have to say no. Where there is no native equivalent, e.g. tabs, or accordions, or carousels – collections of standard (hopefully semantic) elements modified by JavaScript to provide rich interactive applications – then give me that sweet, sweet ARIA, lending context where it’s missing, where the use case is outside the norm.

    This is not that. This is a password field. I’m not going to look up how long it’s been part of the HTML specification, but I’d wager it’s been around longer than Bootstrap has been a thing.

    I appreciate the effort, and admire the sentiment, but surely there are better “problems” to solve than this?

Comment on this post

Will not be published

This site uses Akismet to reduce spam. Learn how your comment data is processed.