Angular Component Libraries and Accessibility

Nowadays, it feels as if web development is an ever-changing landscape that moves at supersonic speeds. With the demands to keep your content up to date with the latest and greatest designs and frameworks, it can be an overwhelming task to keep up. JavaScript frameworks, such as Angular, play a large role in this with their almost limitless potential to create new and exciting content on the web.

One thing that has become commonplace to take the burden off of developers when creating new content is the use of component libraries. These 3rd-party open-source libraries create components and widgets that developers can pick up and add to their projects with minimal effort. Although these component libraries are wonderful from a development aspect, they do have their faults from an accessibility standpoint.

In general, Angular component libraries suffer from some common accessibility pain points:

• Overuse or misuse of ARIA
• No use of semantic HTML
• Missing keyboard events on some components
• Not tested using assistive technology

These are just a few generic examples of the issues we see day to day in our work when helping developers fix accessibility issues that are using these frameworks. However, we wanted to take a deeper look at some of the top UI frameworks and see how they stack up against each other from an accessibility point of view. Angular has a multitude of different UI frameworks that can be used, however, there are 3 that stand-out more than others: MaterialUI, Ngx-Bootstrap, and primeNg.

Angular Material

Far and away the most popular UI framework is Angular material, and rightfully so. Material allows developers to easily integrate out of the box components with ease and takes most of the burden off of design and development. It also has a vast array of different components to be used.

However, from an accessibility standpoint, a lot of things are lacking within Material itself. Material suffers from a lack of understanding of ARIA and a general lack of flexibility compared to other frameworks that make it pretty inaccessible and difficult to add accessibility to. Not all is bad from an accessibility standpoint, however. Here are the pros and cons of Angular Material:

PROS

• It’s improving from an accessibility standpoint
• Includes documentation on the accessibility of its content
• As well as added accessibility that needs to be added for components (ex: labels for checkboxes/radio buttons)
• Uses semantic HTML for inputs (ex. radios, checkboxes, text fields, text areas)
• An accessible modal out of the box, including background content being hidden

CONS

• Dynamically added components have dynamically added ARIA, which can cause issues for assistive technologies, e.g. Tooltips using dynamic aria-describedby and toasts using alerts and aria-live dynamically.
• Misuse or overuse of ARIA on some components (ex: tables, calendars)
• Some components are somewhat accessible but are missing pieces to make them fully accessible to all (ex: Calendar)
• Not easily customizable to add accessibility into components
• Directives or component life cycles must be used to add in accessibility after render

Ngx-Bootstrap – v4

Ngx-Bootstrap is a well-documented framework that provides developers with a set of modular components that can be styled, adjusted by scripts, or manipulated with ARIA roles. The documentation clearly states, “Authors need to include ARIA roles and attributes” to ensure their website will be accessible to a wider audience.

As with many other frameworks, Ngx-Bootstrap requires the developer to be fastidious about accessibility. Although there are a number of components that are accessible out of the box, there are also a few areas where developers should be aware that there are accessibility violations at play.

PROS

• A number of components are accessible out of the box, such as:
• Accordions
• Buttons
• Dropdowns (these are more like menus than select dropdowns)
• Modals – fully documented as far as how to make sure it’s accessible but require some extra attention to ensure full accessibility
• Caveat: requires the developer to add the accessibility features

CONS

• Some components are not accessible, such as:
• Datepicker is missing a number of key accessibility features that will prevent a non-sighted user from using the datepicker at all. There is also a misuse of many ARIA attributes.
• Some components require more work to be fully accessible, such as:
• Carousel is missing a number of key accessibility features
• Tabs require the developer to add a unique id to each tab panel so they are associated with their subsequent tab
• Tooltips use dynamic aria-describedby, which can yield inconsistent results for assistive technology users
• Radio buttons and checkboxes have a complex integration but lack a group label out-of-box
• Various components have the ability to customize to a point where you can turn off certain features; in general, these should not be used as they will limit the accessibility of your content.

Prime Faces – PrimeNG

PrimeNG is lightweight and easy to use and, to our surprise, is actually a unique take on accessibility in a component library. The framework puts the responsibility on you as the developer to ensure the components you use are 100% accessible. Which in a way is a good thing since, in the end, you are responsible for making your content accessible!

Out-of-box, most of the components in PrimeNG are pretty accessible, however, it is still lacking in some major components from an accessibility perspective. The difference between PrimeNG and other component libraries is that it is extremely customizable and allows you as the developer to add in accessibility with ease on components that may not be fully accessible!

PROS

• The use of accessible properties on tags make for easy integration of ARIA
• Does use semantic HTML for inputs
• Radios, Checkboxes, text fields, text areas
• Flexibility and customization to make components accessible
• Good amount of components come accessible as is
• Float labels done very well with semantic HTML

CONS

• Developers have to take the time to add in accessibility for label association and proper ARIA properties
• Major components such as Calendar and Modal are still lacking in their accessibility out-of-the-box
• Some overuse or misuse of ARIA on a few components
• Various components have the ability to customize to a point where you can turn off certain features; in general, these should not be used because they will limit the accessibility of your content

Angular Accessibility Libraries

Although we have spent most of the time talking about UI Component Libraries and what’s good and bad about them, there are some libraries in Angular that do strictly help support accessibility and enhance automated testing for accessibility! These include angular/CDK and axe webdriver JS with protractor. Let’s take a look at each of these.

angular/CDK

The Angular Material (yes, that Angular Material in the previous section) library houses the Component Dev Kit (CDK), which is a set of behavior primitives for building UI components. Within CDK is the ‘a11y’ suite of attributes and functions that can add a variety of accessibility features easily into your project, including:

• FocusTrap – Allows for trapping focus in components such as modals and menus
• LiveAnnouncer – Fully working live region
• Color Contrast options

axe Webdriver JS with Protractor

If you are using protractor for your E2E testing (end-to-end testing), then you need to be using Deque’s axe webdriverJS integration. The open-source package allows you to catch accessibility violations in your protractor test cases automatically and see specifically what the violations are and how to fix them as well.

Not only will using this tool will allow your development team to catch accessibility violations during the development of your project, but it will also create accessibility-aware developers who make accessible content!

In Summary

This article may seem like it’s pointed directly at teams who use component libraries to say, “you cannot use them because they aren’t accessible!”–that is not the case. The goal for us is to ensure that you as the developer are aware that using libraries like Angular Material, Ngx-Bootstrap, Prime Faces, or any new library comes with the risk of it not being accessible.

If you decide to use a component framework, take your time to explore the framework and check the accessibility of it. At the end of the day, it comes down to you as the developer to fix the issues that exist in your application, even if that means it’s a third-party library. If you choose to use it in your project or in your organization, you are responsible for the accessibility of it. These tools can aid in your quest to create accessible applications, but if you need any further information, be sure to check out Deque University’s courses on developing accessible websites.