June 9th, 2021
During #GoogleIO2021, we released a new Angular codelab focused on accessibility. In this post we’ll walk through ten tools for building more accessible applications, then head to the codelab for hands-on practice exercising these skills.
Accessibility is a vital part of web development – ensuring that users can perceive, understand, navigate, and interact with apps. Developing accessible apps starts from ideation all the way through deployment, so let’s take a look at how you can begin incorporating a11y into your apps!
In the current state of the web, manually testing accessibility is mandatory. Start by learning to navigate using your computer’s built-in screen reader.
We recommend adding the following rules to your .eslintrc.json, which apply to accessibility.
Providing unique, concise page titles helps users using a11y services quickly understand a web page’s content and purpose. To fix this, you use Angular’s Title service to define unique titles for each of your pages.
Your design might seem cool, but it’s not if people with visual impairments like color blindness can’t read your content. Use the Material theming guides and inspection tools to ensure you meet the Web Content Accessibility Guidelines (WCAG 2.0) color contrast ratio guidelines.
Native HTML elements capture a number of standard interaction patterns that are important to accessibility.
When authoring Angular components, you should reuse these native elements directly when possible, rather than reimplement well-supported behaviors. This means using <button> and <a> instead of making everything a <div>.
Simplify menus and controls to create navigable components by simplifying controls as much as possible.
The Web Accessibility Initiative’s Accessible Rich Internet Applications specification (WAI-ARIA or ARIA) helps bridge issues that can’t be managed with native HTML.
Specify aria-label and other ARIA attributes that modify the way an element is translated into the accessibility tree.
Add the Angular CDK’s a11y module to help solve more complicated and Angular-specific issues. Importing the module package provides access to a number of tools which developers can utilize to improve accessibility:
ListKeyManager: manage the active option in a list of items based on keyboard interaction.
FocusTrap: trap Tab key focus within an element for components like modal dialogs, where focus must be constrained.
InteractivityChecker: check the interactivity of an element, capturing disabled, visible, tabbable, and focusable states for accessibility purposes.
LiveAnnouncer: announce messages for screen-reader users using an aria-live region.
FocusMonitor: used to listen for changes in the focus state of an element.
Styling utilities: Sass mixins that produce styles for hiding elements in an accessible way, targeting high contrast users and more.
In Angular, FocusTrap’s cdkTrapFocus directive traps tab-key focus within an element. This is intended to be used to create accessible experience for components like modal dialogs, where focus must be constrained.
Screen readers need to be notified when something on the page changes. Imagine attempting to submit a form or complete a purchase, and not knowing an error has popped up preventing the form submission. That’s frustrating!
LiveAnnouncer is used to announce messages for screen-reader users using an aria-live region to ensure screen readers are notified about notifications and live page changes.
Use the cdk-high-contrast @mixin provided in @angular/cdk/a11y to add an outline to your buttons in High Contrast mode to respect user’s preferences and to dramatically increase contrast.
And that’s it!
Ten ways to begin building more accessible apps. Head to the codelab to put your Angular skills to the test!
Let us know in the comments what @angular/cdk/a11y tools you use in your apps, and what accessibility tools you use!
The original post Build more accessible Angular apps.