Checklist for Accessible UI Component Libraries
Accessibility is a choice. Designers can use color combinations with sufficient contrast, or pick colors for purely aesthetic reasons. Web developers can implement a button with the native button tag, or they use the generic div tag instead.
In an ideal development process, accessibility is considered right from the start. The requirements clearly state the needs of people with disabilities. Designers create mockups and prototypes which meet these requirements. Developers implement the features with semantic markup. Testers verify that the web content meets the accessibility requirements.
In reality, accessibility is often treated as an afterthought. This can be especially problematic when it comes to UI component libraries. I will talk about why it's important to check the accessibility of the library before you write your first line of code. And what you should keep in mind when working with UI components.
Photo: © Alena Darmel / pexels.com
The Advantages of UI Component Libraries
HTML elements are the basic building blocks of any website. But they don't cover all types of content and possible use cases. Complex UI patterns like accordions, carousels, or tabs require custom implementations anyway.
To speed up development and ensure a consistent look and feel, a modern web application usually makes use of a UI component library. They're a collection of design elements that are ready to use in your application. Usually, you can apply a color theme and customize the functionality of the components.
Hundreds of different component libraries are available for major web frameworks like Angular, React, or Vue.js. For example, if you like the Material design system, you can use Angular Material, Material UI, or Material Components Vue.
Checking the Library's Accessibility
Here's a checklist for picking an accessible UI component library:
- Is accessibility mentioned on the library's website or documentation? For example, the Angular Material homepage states that they offer: “Internationalized and accessible components for everyone.”
- Does the documentation explain if and how the components are made accessible? The Angular Material documentation has dedicated accessibility sections for every component.
- The documentation usually includes demo pages and examples for the different components. Inspect their markup and accessibility properties using your browser's dev tools. Test with assistive technologies like your keyboard and different desktop and mobile screen readers.
No Guarantee of Complete Accessibility
Picking an accessible UI component library is an important first step towards making you web application accessible. But it doesn't guarantee it. Every time you use a component on a page, you should answer the following questions:
- Where and how is the component included? Think about the context and order of content.
- Is the type of use consistent with the actual purpose of the component? Or are you only trying to achieve a specific visual appearance?
The visual presentation of content should not determine which component you use. It's easy to apply a specific design with CSS. But it's nearly impossible or at least very tedious to override a component's semantic markup and implemented keyboard interaction.
To give you an example: Angular Material's <mat-chip-listbox> component provides a multi-select listbox, following the listbox pattern. The semantic markup communicates to assistive technologies that the element offers several options of which one or more can be selected. The whole listbox receives keyboard focus via the TAB key. The arrow keys move focus to the next or previous option.
Now imagine your client saying: “I love the design of the chips component. I want this list of links styled in the same way!” Do you think you should really use the component for this use case?
It's our responsibility as web developers to pick the right component for the job. And to resist the seemingly easy path that would lead to disaster! 😉
Posted on