Automating Accessibility In Angular

Crystal Finch is a user experience engineer for productOps and in this blog tackles some of the challenges of making applications accessible to all people, regardless of disability type.

Accessibility is a critical aspect of our development pipeline especially for our clients in education and government. Every member of the team brings talent to the table, but not every member is necessarily an expert in accessibility. In a web application with many moving parts, ensuring new functionality is accessible can be a herculean effort. A module that took hours to comb through for issues could soon have new issues introduced when code is added by well-meaning teammates. If you’re like us, you want to continue to have fun coding without sacrificing quality. You also don’t want to go to sleep at night dreading the thought of your hard work being undone or becoming a tiresome accessibility watchdog.

“In a web application with many moving parts, ensuring new functionality is accessible can be a herculean effort.”

After some hours of brainstorming, we created an approach for guiding the whole team in the right direction. In recent months, we have been building an Angular application that contains hundreds of form fields. To be accessible, all fields must have an associated label. Without them, clearly understanding the form is impossible for users who depend on assistive technology. A very common oversight during development.

Now for the fix! We put together a generic component called input-field. It takes a native form input element, identified by the input-ref directive, that has an id attribute. When you instantiate the component, you pass a string to thelabelText attribute. A native label is automagically output with that string and gets associated with the native form input element — the id of the input is used as the for attribute of the label. If any necessary value is missing, an error message is printed out to the console. Issues are caught right away and can be fixed before anything gets committed. Though these errors will get resolved during development, we use a special Logger class that prevents any errors from appearing in a production environment.

The input-field component also provides the option to make the label hidden. This comes in handy when using inputs in parts of the UI that do not allow space for a visible label, such as the inside of table cells. When this option is used, the labelText is applied to the native form input element as an aria-label attribute instead of a nativelabel element.

This approach takes the guess work out of the equation for everyone touching the application’s form fields. We maintain compliance with accessibility guidelines and give developers the guidance they need when they need it. Of course, this solution applies to only a fraction of the tasks required to build an accessible application, but even this small effort goes a long way in creating a friendly and inclusive experience for the widest possible audience.