A11y: controls that act as buttons exposed as links, don't expose state

[patrickhlauke]

Steps To Reproduce

1. Run a screen reader (e.g. NVDA on Windows)
2. Navigate through the desktop app main interface using Tab/Shift + Tab
3. Navigate through all items, and all controls in the left-hand column ("All Items", "Favourites", "Trash", all the Types, all the Folders)

Expected Result

All items in the central item column, and all controls in the left-hand column, as as buttons - activating them doesn't take the user to a new location, but rather toggles a dynamic change somewhere else in the interface. For these sorts of controls, "button" is the most appropriate role.

When an item is selected (i.e. the item itself is showing in the right-most panel of the interface), and when an control in the left-hand column is selected/active (e.g. I'm currently in a particular folder), the control itself should expose this fact - not just through visual styling, but programmatically.

Actual Result

All items in the central item column, as well as "All Items", "Favourites", "Trash", all the Types, all the Folders, in the left-hand column, are currently exposed as link elements.

A selected item or category/folder/type is only denoted visually, but does not expose any extra information to assistive technologies (i.e. it does not programmatically expose that it is selected)

Screenshots or Videos

No response

Additional Context

Ideally, these controls should be implemented as <button> elements, rather than what I assume are angular "router links" <a href="#" ...>.

<button type="button" ...> ... </button>

If it's not possible to actually change the markup used, at least expose these links as buttons using role="button" (and make sure they can be triggered with Space as well Enter, as it's convention for buttons to do so)

<a href="#" role="button" ...> ... </a>

---

when an item of left-hand category control is selected/toggled, expose this fact using aria-pressed="true".

<button type="button" aria-pressed="true">...</button>

or, if you're still using the router links...

<a href="#" role="button" aria-pressed="true" ...> ... </a>

Operating System

Windows

Operating System Version

10

Installation method

Direct Download (from bitwarden.com)

Build Version

Version 1.32.1 Shell 16.0.7 Renderer 96.0.4664.110 Node 16.9.1 Architecture x64

[patrickhlauke]

x-ref bitwarden/clients#1988

[patrickhlauke]

Although i'm not seeing it myself in my copy of the desktop client (probably because I'm on the free tier), it seems that folders (and even a whole separate thing called "Collections") can have nesting. For those controls, beyond changing them to <button> elements, you probably also want to expose whether they're expanded or collapsed, using aria-expanded="true"/aria-expanded="false"

[patrickhlauke]

Similar issues (of controls exposed as links) can also be found on the login view, and for the "Cancel" control in some sub-views.

Wondering if in some cases, you've opted for link because these trigger modal dialogs or similar? In which case I'd say these also should be changed to buttons, for consistency (and it's a common expectation for users that even buttons can trigger things like modals)