ARIA or WAI-ARIA or Accessible Rich Internet Applications
Now we know the very basics, we can already start implementing the use of ARIA or Web Accessibility Initiative ARIA, which is a set of special attributes that enhance the accessibility tree, translating the visual UI to a spoken UI.
The most important use of ARIA is to give accessibility features to elements that usually don't have any.
Basically, it allows you to create accessible widgets out of HTML markup.
Let's describe those semantics:
Semantics and programmatic semantics
ROLE -> it tells users how they're expected to interact with this content or what they can get out of it.
NAME -> it provides a text alternative to the
controls.
State and value are pretty self explanatory.
In the code above you can see a representation of programmatic semantics.
In this case the role would be combobox and it's implicit. The name comes from the FOR= attribute in the label.
It is important that you always keep the ARIA authoring guidelines at hand, because as you can imagine, not all elements are allowed all roles, properties and states.
Above you can see a more evident case. This is a special case of a checkbox created with a div.
The first example will be completely misunderstood by the users browsing with assistive technology.
The only thing the screenreader will read is "Check me if you're an ally" . But it will never tell the users that this is a checkbox and what are they meant to do.
The second example, will be read exactly as if it was a native checkbox, because we have programmed the role, and the state!
Implementing ARIA in Angular with attribute binding
The code above shows how you'd code that in your Angular template.
Please pay special attention at how we bind aria as attributes, since they don't have a corresponding DOM property.
Using aria to establish relationships
ARIA can also help establish relationships between elements even if they don't have a parent/child connection.
Like in this example, using the aria-controls attribute, so the sight impaired user knows what element they're controlling with this switch.
Here is what the template looks like
ARIA aria-live for dynamic updates
Another very useful attribute for SPA developers, is aria-live. In the example below we use it implicitly by giving our error message the role=alert, which means the value of aria-live will be assertive. We can also use aria-live explicitly, and give it a value of either assertive or polite.
Polite will wait until the user finishes whatever they are doing, to read the new content or updates. Assertive will interrupt whatever the user is doing to read the message or new content. Assertive may completely override any content in queue.
ARIA does play its role (pun intended!) but you have to play yours!
ARIA helps enhance the accessibility tree. But you have to add keyboard support on top of it!
What this means is, you can bind an aria attribute to an element but unless you write the logic that binds that to a key event, nothing else will happen!
As you can see in the snippet above, that is quite simple by implementing the KeyboardEvent interface's key read-only property key, that returns the value of the key pressed by the user, and even takes into consideration the state of modifier keys like Shift, and even the keyboard locale and layout.
Learn more reading this MDN page!
Other nice things you can do and keep in mind!
Now with all you know in mind, you're ready to make your apps accessible. Another useful piece of advice I could give you in terms of accessibility would be
1- Add skiplinks at the top of the page. Skiplinks allow users using the keyboard or assistive tech to get faster to where they need to go. Imagine yourself browsing over hundreds of links in a mega menu before reaching the section of content you want to go to
2- Avoid keyboard traps in dynamic elements. For example a slider. You have to always ensure users can get out of a feature and off to the next
3- Ensure they can also get out of the page and tab onto the browser controls
Static Analysis: automated help to the rescue!
This sounds like a lot of work, I know...Even after so many years of working with accessibility in mind, I am myself not sure about certain rules.
And we have so much to remember as frontend developers, that a little automation help is always appreciated.
Luckily in Angular we can perform static code analysis out of the box with codelizer, also to lint for accessibility issues.
All you have to do, is update your tslint configuration, with the accessibility rules available.
Code line number 7 makes sure you add alternative text descriptions to all your images, code line number 9, will make sure that you add a for attribute to all your labels. Code line number 10 ensures you don't add tabindex values other than -1 and 0, that we already discussed, can lead to trouble. Code line number 13 makes sure that if you're adding a click event listener to an element without synthetic controls, you have a key event associated.
Linting locally, manually or via an IDE plugin
If you install the tslint plugin to your IDE, then you have tips and indicators at development time, like with other linting errors or issues.
You can also run $ng lint to get a detailed list of issues to fix, across your many files.
So you can basically see all your errors and actually break your build when those errors happen.
Integrating linting to your CI pipeline
You can even execute $ng lint in your CI pipeline, to avoid shipping accessibility issues to production.
This is something I definitely recommend you think about, if you're working for the public sector. Especially some countries have strict accessibility legislations, like the UK and Israel, and I'm sure many more.
A11y Audits
First things, first. I recommend that you always agree on a screenreader (or even assistive technologies) support matrix with your client, just like you do (or should do) with browsers.
Results between the many options, for example Jaws, NVDA or Voiceover, highly vary across browsers and devices.
Chrome Accessibility Inspector
And together with the screenreader tests you can use Chrome Accessibility Inspector to inspect your items, and learn more about the accessibility features you're offering, and those you're missing.
In the screenshot, you can see how it gives very comprehensive information about name, role, state and value of the element inspected.
Lighthouse Audits
Last but not least, use the Lighthouse audits, directly integrated in the developer tools.
Lighthouse will not only give you a score, but tips to solve your current problems.
Keep in mind that this tool warns you know that only a subset of issues can be detected, and you are encouraged to perform manual audits. However, like I mentioned, manual audits, especially with screenreaders, can be very difficult to perform for developers.
Super users, or assistive technology users, use these tools a lot different than we do. Also as mentioned, screenreaders can give very different and unexpected results, between them.
So if your clients are very serious about accessibility compliance and have a target, they're enterprise of public sector, you should probably leave the audits to 3rd party experts, just like you do with pen-testing, for example
I hope you enjoyed these articles and have learned something! And I also hope you give inclusive design, accessibility and UX more thought, at the time of developing great Angular applications!
Top comments (0)