In contexts such as the web interfaces of Facebook and Gmail, where users scroll through a seemingly endless stream of fresh or stored content displayed as self-contained items, SPAs make some sense. They offer a fast, smooth app-like user experience, can use local caching, and separate the front end from the back end, which can be useful. However, where it is used, an infinitely scrolling or automatically renewed content display can also create its own accessibility issues.
Impact on users
Accessibility issues that SPAs can present for users with disabilities include:
- Keyboard and screen reader focus might remain on the last focused element rather than moving to newly loaded content.
- Screen readers might not detect and announce all content changes.
- Custom elements might negate the accessibility advantages of semantic HTML.
- Browser Back / Forward or Previous / Next buttons may not work as expected.
Each of these issues can be addressed in some way but many developers will wonder whether the SPA’s benefits outweigh the extra work required to make it accessible.
SPAs are expected to conform to the same requirements of the Web Content Accessibility Guidelines (WCAG) that apply to multi-page websites. Due to their nature, and depending on how they are constructed, SPAs might need to use techniques to conform to specific WCAG success criteria that are different to those used on multi-page websites.
Web pages have titles that describe topic or purpose.
On multi-page websites, this is a straightforward matter of ensuring each web page has a
<title> element in the
<head> with an appropriate value that is announced by a screen reader when a new page loads. In a SPA, you must take steps to make that information available programmatically to assistive technology users when new content is loaded.
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
Focus management can be an issue for SPAs. You must ensure that assistive technology users and keyboard-only users can perceive all content in its proper sequence and can operate all functional controls.
Consider seriously whether using a SPA will benefit your users. Does using a SPA solve a specific problem? If not, reconsider. A multi-page website presents far fewer accessibility issues and those are mostly much easier to address.
If you do choose to use a SPA, use semantic markup. If you use custom elements, whether they come from a framework or you make them yourself, ensure that they don’t remove the accessibility advantages that semantic markup and code deliver. For example, screen readers tell their users what areas of a semantically marked up web page are present, such as navigation in a
<nav> element, main content in a
<main> element and footer content in a
If your SPA is built on a framework that doesn’t use these landmark elements, and/or doesn’t allow you to add them, apply ARIA to add, for example,
role="contentinfo" to the respective containing elements.
Properly marked up landmarks, lists, links, buttons, data tables, search boxes, headings, captions and navigation menus will go a long way to making your SPA navigable for keyboard only and screen reader users.
document.title to give new content a page title. With semantic markup, this ensures assistive technology can announce new content as it appears. One way to do this is to wrap your page title in an
<h2> heading (depending on your site and page structure) and move focus to that heading when new content appears. Since a heading is not in itself focusable, apply
tabindex="-1" to make it focusable. An alternative is to use the same technique to move focus to a wrapper element that contains the fresh content.
Let users know when the content within a page changes. While this is true for all web pages, because it includes content that is dynamically generated such as loading progress indicators, it’s especially important for SPAs that load fresh content without refreshing the page. You must communicate to users of assistive technology that something is happening on the page.
- When in-page content changes are unexpected, such as a form error message, move focus to the error message or, in the case of multiple errors, to a list of error messages at the top of the form.
- When in-page content changes are expected, such as a message confirming the result of user interaction, use live regions to alert the user without moving focus.
Consider implementing what’s sometimes called a hybrid SPA, where individual sections of content are marked by a change in URL in the browser address, even though the user remains in the same browser tab or window. There are several non-accessibility related advantages to this approach (such as being able to send someone a link to a specific article URL) but, when marked up accordingly, hybrid SPAs can be more accessible to keyboard only users and users of assistive technology.
If all of this seems like a lot to do just to make a single page application accessible, it is – and there may be more to do, depending on which framework is used. That alone should make you question whether a SPA is the right solution.