Angular rocket ship with astronaut that has an a11y flag on the moon

Angular and Accessibility: Issues and Strategies

The trend of web development is heading in the direction of JavaScript frameworks and libraries to build single-page apps (SPAs). With this new trend, in turn, comes a whole new set of web accessibility concerns. These concerns are unique to single-page applications because of the behavior of client-side rendering that adds a layer of complexity when trying to understand and create accessible applications.

Angular is no stranger to the accessibility concerns that come with it being a javascript framework. In fact, Angular has become one of the most popular of the javascript frameworks. It is a powerful and robust javascript framework with the ability to create complex websites.

While Angular is powerful and robust, developers still need to be aware of the accessibility issues that could be created while using this framework. While the approach and key concerns are largely the same in Angular as with other web content when trying to meet WCAG standards, it is important to understand the key accessibility issues that exist within Angular.

Issue #1: Page View/Titles

Angular is a  single-page application and, as a result, a majority of the transitions (i.e moving to a new page) will not involve a page reload. The tendency of many developers is to think “single page” equals “single title” and there is no way to fix the issue. However, this assumption is not true. There are ways in which developers can carefully manage the page title change within the components or transitions, such as using title service that comes within the framework itself.

Issue #2: Keyboard Navigation

Keyboard navigation can be tricky in Angular. There is one main culprit when it comes to keyboard navigation, and that is the use of non-semantic HTML. As cool at may be to have a nicely designed button made with all <div> tags and CSS, without proper semantics keyboard users will not be able to the content properly.

Thanks to Angular’s straightforward use of binding syntax to a component you can literally add click events on HTML tag. When possible, it is important to use semantic HTML to make keyboard navigation easier.

Issue #3: Focus Management

By far, the largest accessibility issue that Angular applications face is the concept of “focus management.” Although the load times and speeds of websites greatly increase with asynchronous loading of content, accessible users are left behind.

When content is asynchronously added on the page, screen readers users and keyboard-only users can lose context of where they are on the page or even be unaware that new content has appeared. This can lead to a very difficult and frustrating experience when a person using assistive technology is trying to use your web content.

Strategies to Follow

Angular is a fantastic framework that provides the ability to create clean, fast, and wonderfully interactive applications that move web development into the future. However, there is a cost from an accessibility perspective if it is not implemented properly.

Keep the following points in mind when trying to make sure your application reaches all audiences:

  • If a page/view changes, manage the page title properly
  • Be sure to use proper semantic HTML where possible
  • No semantic HTML, then use ARIA to properly markup the content.
  • Try to limit the use of custom HTML tags
  • Be sure to manage focus properly whenever asynchronous content is used.
  • Use accessibility testing tools such as axe-core to test your content for accessibility issues as you code your components

In Summary

If you’re not aware of the critical accessibility issues and above strategies in your Angular application, you can leave accessible users in the dust. However, if you can follow the strategies above, and keep up to date on the latest accessibility support within the framework, you will begin to create Angular applications that reach a much wider audience!

For more information on Angular and accessibility, check out our new Angular Accessibility course on that deep dives into more advanced issues, technical remediation and testing strategies for your application!

update selasa

Comments 3 responses

  1. I ran Axe on some pages of my company’s website, which is written with AngularJS and we get a lot of violations such as: ” elements must be contained in a or “. The thing is, the element is contained in a , there just happens to be a custom directive in the middle, which the is part of (that’s how it is added to the DOM). So we’d have something like this:

    Do you have any recommendations or resources for dealing with this issue without completely re-writing the part of our site? Google search wasn’t particularly helpful.
    I also don’t completely understand if custom directives are issue for screen readers, or if they just don’t play nicely with the Axe tool?

  2. Hey Allyson,

    The issue you are seeing with axe-core running against your website could be one of two things. The first being that when you added that custom directive, it is specifically that you added that directive on an HTML element that is inside of a list. If that is the case, anything that is not a ‹li› would get marked as a violation.

    The other case would be if you are dynamically adding your list items with data, and there is a wrapper element around those items that is being added in (meaning it is a separate component). This is a very common issue in Angular when you have to wrap your content with a ‹div› and then it can cause accessibility issues in your markup.

    Hope this helps!

Leave a Reply

Your email address will not be published. Required fields are marked *