DEV Community

Cover image for Accessible UI Frameworks: A Word of Caution
Mark Steadman
Mark Steadman

Posted on • Updated on

Accessible UI Frameworks: A Word of Caution

A question I get asked a lot in my role as an accessibility developer consultant is 'What framework can I use that is accessible' or 'What framework contains accessible components I could use'. From a developers perspective, I completely understand wanting to get an accessible library or components in your application to minimize effort in fixing accessibility issues and also maintain accessible components going forward.

However, I have a word of caution for any development team thinking of using one of these frameworks. A lot of developers think adding a library that says it is 'accessible' or can help you 'create an accessible application' out of the box requires no effort other than adding the component and it is accessible. This is just not the case, and most frameworks require some level of effort and accessibility awareness in order to fully create accessible components.

What Makes a Library Accessible

I have tested many different UI frameworks in React, Angular and even Vue. Most accessible frameworks are better than your average UI framework, because they do the following:

  • They use of semantic HTML
  • They use of ARIA as props, and properly using them
  • They documentation for how to make component accessible
  • They follow W3C design patterns

Even just these items, compared to other UI Frameworks out there make it so much easier on development teams to have accessible components. However, that does not mean that every component in the framework is accessible, and this is where developers run into implementation issues that can cause accessibility problems.

Implementation Concerns

When implementing these frameworks into an application, what I typically see is a lack of understanding from how the component works and/or the lack of reading over the documentation to add in the needed accessibility features.

For example, a developer implemented a button that had multiple uses and was using it for an expand/collapse section. However, when developer added the button they forgot to add in the aria-expanded prop for the component which sets it equal to true or false, based on the state.

Another example, an input component that comes with a placeholder, but doesn't give a proper accessible label. aria-labelledby may be a prop on the component, but the documentation wasn't followed and the association was not made.

What Can You Do?

Here are few things that you and your development team can do to ensure that the framework you have chosen is being used to create accessible content:

  • Test the UI Framework with screen reader and keyboard
  • Check the rendered HTML of the components
  • Check if it has accessibility advocates contributing
  • Look at open accessibility issues on the project to see if any changes are needed to the component you are using
  • Read over all the documentation for components

In Closing

Although this post is largely about misuse and misunderstanding of accessible UI frameworks, I am a large advocate for using them. What it comes down to is simply taking the time to ensure that the library you choose will fit the needs of your development team from an accessibility perspective, and making sure everyone knows that accessibility isn't just copy and paste.

It will require some effort to make it accessible, but overall can make your application accessible and sustainable for the long run!

Top comments (0)