Angular Accessibility
Tags: angular, a11y, typescript
Published: 2020-02-13 05:05:57

---
title: Angular Accessibility
published: true
date: 2020-02-13 04:37:21 UTC
tags: Angular, Accessibility, A11y, TypeScript
series: Doggo Quest
cover_image: https://i0.wp.com/killalldefects.com/wp-content/uploads/2020/02/image-40.png?fit=639%2C519&ssl=1
canonical_url: https://killalldefects.com/2020/02/12/angular-accessibility/?utm_source=rss&utm_medium=rss&utm_campaign=angular-accessibility
---

The post [Angular Accessibility](https://killalldefects.com/2020/02/12/angular-accessibility/) appeared first on [Kill All Defects](https://killalldefects.com).

---

Let’s talk about building accessible Angular applications. Why? Because Angular apps are awesome, but the amazing things Angular lets you do are wasted unless you can build an app that everyone can use.

Accessibility (sometimes abbreviated as “a11y”) refers to designing software in such a way that it can be used by all users, regardless of any disabilities they may have.

While I’m not an accessibility expert, I can help you get started with accessibility in general and, more specifically, how to follow accessibility practices in Angular.

## Accessibility 101

Before we get into auditing your applications for accessibility issues, let’s look at some common violations.

### Modern HTML Tags

Modern browsers support a rich and diverse set of meaningful HTML tags, and yet the power of modern web technologies like Angular have made it easy for us to simply use `div` elements everywhere throughout our code.

This is bad.

Why? Because screen readers and other accessibility software see a `div` tag and they don’t understand whether this is a button, a paragraph, or a border rectangle.

Don’t do this.

Instead of `<div class="btn">My Button</div>`

Use: `<button class="btn">My Button</button>`

This applies to other HTML elements as well. When you can, use [semantic HTML elements](https://www.w3schools.com/html/html5_semantic_elements.asp) like `nav`, `header`, `footer`, `section`, `article`, and `aside`.

### Use Aria Attributes

Sometimes you _have_ to use HTML in interesting ways. For these times, you need to consider `role` tags as well as the [Accessible Rich Internet Applications (ARIA) tag standards](https://www.w3.org/TR/html-aria/).

Commonly, you’ll need to pay attention to:

- `aria-disabled`
- `aria-hidden`
- `aria-expanded`
- `aria-label`
- `aria-labelledby`

Note that If you need to bind the value of an `aria` attribute to something in Angular you can use syntax like: `<div [attr.aria-expanded]="isExpanded">`

There’s another aria tag to pay attention to: Regions that will receive live updates, inserts, or deletions should use `aria-live`. We’ll get back to this one later when we discuss announcing changes.

Since I’m not an accessibility expert and my focus here is more on enabling accessibility in Angular, I recommend you check out [Ian Forrest’s](https://twitter.com/ianforr) excellent [talk on web accessibility trends](https://app.pluralsight.com/library/courses/codemash-session-09/description) available on Pluralsight for free.

## Integrating Accessibility into your Angular Workflow

Now that we’ve discussed general accessibility, let’s explore some more Angular specific scenarios.

### Storybook Accessibility

I wrote previously about how I love [using Storybook for quickly proofing Angular user interfaces](https://killalldefects.com/2020/02/09/test-angular-components-in-storybook/). Storybook is an amazing library and has a number of very well done add-ons, including [an accessibility add-on](https://github.com/storybookjs/storybook/tree/master/addons/a11y) which can simplify accessibility audits.

You can install this add-on by opening your command line in your Angular application and then running:

`npm i @storybook/addon-a11y --save-dev`

This should install the necessary dependencies as a _development-time_ dependency.

* * *

From there, you’ll need to register the addon in the `.storybook/main.js` file like so:

```js
module.exports = {
  stories: ['../src/**/*.stories.ts'],
  addons: ['@storybook/addon-a11y'], // other addons hidden for clarity
};
```

Next, you need to add `withA11y` to each `stories.ts` file you want to be accessibility tested like so (noting lines 4 and 8 in particular):

{% gist https://gist.github.com/IntegerMan/c30289515f7fa3827223ce44fd0db4ce %}

### Viewing and Fixing A11y Issues in Storybook

Once `addon-a11y` is set up in Storybook, when you execute `npm run storybook` you should see an `Accessibility` tab, which will highlight any accessibility violations detected as shown below:

![](https://i1.wp.com/killalldefects.com/wp-content/uploads/2020/02/image-39.png?w=770&ssl=1)

Here the add-on is telling me that I have a region of the screen that is actively showing a scroll bar, but the region isn’t keyboard focusable. This means that anyone navigating via a keyboard (such as many users who need accessibility features) will not be able to scroll.

In this case, I can click “More info…” to navigate to the failed rule and view some sample recommended fixes. In this case, I need to add `tabindex="0"` to the scrollable region so that. Doing that and rerunning the test resolves the issue.

Note that this isn’t going to be as extensive or comprehensive as a browser plug-in specifically designed for accessibility testing, but if you’re already using [Storybook](https://storybook.js.org/), this is an easy way to also use that for quick checks on accessibility.

* * *

Accessibility doesn’t just refer to people who need screen readers. Many people suffer from various forms of color blindness. The a11y addon gives us a color filter feature (pictured below) that can simulate various forms of color blindness so you can proof your applications and make sure you’re not hiding information based on color sensitivity.

![](https://i0.wp.com/killalldefects.com/wp-content/uploads/2020/02/image-40.png?w=770&ssl=1)

## Aria-Live and Content Updates

[Aria-live](https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live) is used to denote an area of the web application which receives periodic updates.

Using `aria-live` is fairly simple, you add it to any div and specify the _politeness_. This refers to how urgent the notifications are going to be to the end user.

For example, you’d use `<div aria-live="polite">` to only announce events when the user is idle while `assertive` will be more aggressive.

* * *

Setting `aria-live` isn’t enough, however. You also need to use a `LiveAnnouncer` to announce the modification to screen reader software.

Take a look at this sample component:

{% gist https://gist.github.com/IntegerMan/bdd1c7b37219a092e5f6d15e0c600ccb %}

Here on line 20 we inject the `LiveAnnouncer` into the component via Angular’s dependency injection mechanism.

Next, in the `onEntryAdded` method starting on line 35 we call out to the `liveAnnouncer` with our text events. These events will get picked up by the screen reader and presented to the user.

## Linting Accessibility

If you want to easily get some degree of auditing into your development practices, you can add some accessibility rules to the `tslint.json` file that ships with Angular. This will allow you to run accessibility checks during the linting process and can catch some common errors.

To enable this, open `tslint.json` and add the following rules to your rules collection:

```json
    "template-accessibility-alt-text": true,
    "template-accessibility-elements-content": true,
    "template-accessibility-label-for": true,
    "template-accessibility-tabindex-no-positive": true,
    "template-accessibility-table-scope": true,
    "template-accessibility-valid-aria": true,
    "template-click-events-have-key-events": true,
    "template-mouse-events-have-key-events": true,
    "template-no-autofocus": true,
    "template-no-distracting-elements": true,
```

Now when you run `npm run lint` to lint your code, some basic accessibility checks will occur. Note that this is not by any means comprehensive, but even basic checks can help catch things.

## Closing Thoughts

Hopefully this article has given you a quick primer or refresher on accessibility in general and some ideas of how to audit and achieve accessibility concerns in Angular.

I am not an expert on accessibility by any means, and I strongly recommend you also consider purpose-built tools like [Wave](https://wave.webaim.org/) and others if you want to really get serious about auditing your application’s accessibility.

For more up to date details on Angular accessibility, take a look at the framework’s [official docs page on accessibility](https://angular.io/guide/accessibility).