[bug]: screen readers have a hard time with the UI

[zersiax]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current behavior

I had a quick look around the Plane interface and while a lot o things work, marginally, well, there's also a lot of things that could do with some serious accessibility improvements. Many form fields lack an accessible name/label, heading structure is all over the place, several buttons are unlabeled for assistive tech etc. Is there a plan to tackle the accessibility of the interface so people don't get fired when a company decides to adopt this tool only to find out that some of their employees can now no longer keep track of the projects they're working on?

Steps to reproduce

Test using the interface with only the keyboard , while a screen reader like NVDA.

Browser

Google Chrome

Version

Cloud

[aaryan610]

Hi @zersiax, thank you for highlighting the accessibility concerns. We want to emphasize that we are actively working on enhancing keyboard accessibility as well. We recognize the importance of keyboard navigation for users who rely on it and are committed to providing a seamless experience.

Your feedback is greatly appreciated as we strive to make Plane more inclusive and user-friendly. Thank you for your support and patience as we continue to make improvements.

[zersiax]

Please note that keyboard accessibility and screen reader accessibility are not necessarily equivalent. Keyboard accessibility can complement screen reader accessibility, but will not cover both cases.

[vihar]

@zersiax, it would be greatly appreciated if you could suggest any frameworks or libraries that we could utilize for implementing this, or provide ideas if we need to develop it from scratch.

@Shivangi-jain33, @bhaveshraja, let's include this issue in our roadmap.

[zersiax]

This is not really a problem you solve by using a library, for the most part. While design systems and component libraries exis that are pretty accessible out of the box, what it reallly comes down to a lot of the time is the HTML that ultimately gets rendered by whatever framework you're using. If a button a user clicks visually looks like a button, but is really just a div with a whole bunch of JS attached to it to make it act like a button, then you're either going to have to turn that div into an actual button element, or manually add the required aria properties (aria-label, role, tabindex etc) to make it behave like a button. If a button only has an icon on it and no text, a screen reader isn't going to know how to read out its function for its users, so you'd need an aria-label which sets that button's accessible name. Tl,dr: Use semantic HTML and 80% of your problems disappear.

[zersiax]

Look for example at the input.tsx in ui/form-fields. In HTML, there's two ways to attach a label to a form field. THe label element with a for-attribute that points to the ID of the label, or an aria-label or aria-labelledBy on the input element itself. I don't see a prop for aria-label on this component, and I don't see a label UI element in that folder, maybe there's one in components but I don't really have the time to dig deep right now. Therefore, A supersimple fix could be to add aria-label as a prop on input and textarea, make sure that components that call this widget supply a value to it and now your form fields are labeled. A button element generally gets its accessible name from it's inner text, but if there isn't any, you'd have to apply an aria-label there as well. Same for checkboxes, links with just an icon in them, etc. Things like dropdowns, modals and autocompletes are harder, but this'd be a show of commitment already.