Single Page Applications

This is a technique pulled from KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.


A Single Page Application (SPA) loads a website as a single web page. There is no page refresh, and content is added dynamically with the aid of JavaScript. This creates an online experience that is faster and more like a native app than a traditional multi-page website.

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.

Facebook, Gmail, Twitter and Netflix all use SPAs, while Amazon, CNN, Forbes and eBay have remained multi-page applications

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.

WCAG conformance

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.

Success Criterion 2.4.2: Page Titled (Level A) states:

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.

Success Criterion 2.4.3 Focus Order (Level A) states:

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.

Techniques

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 <footer> element.

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="navigation", role="main" and 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.

While the entire SPA website is a single page, freshly loaded content should still be identified by page titles. Use the JavaScript property 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 <h1> or <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.

In a multi-page website, the user can activate the browser’s BACK button to go to the previous page. In a SPA, activating the BACK button will most likely exit the website. One way to deal with this is use JavaScript and the History API to store different states of browser history and provide access to those states with the BACK and FORWARD (or PREVIOUS and NEXT) browser buttons.

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.

Resources

Categories: KnowledgeBase Content

About Ricky Onsman

Veteran Australian web designer, front end developer, writer and editor. As a writer and/or editor, I've worked with the likes of UX Australia, SitePoint, Web Directions and Smashing Magazine. As a freelance designer and front end dev, I focused on building accessible websites, then worked with a number of design, UX and accessibility-focused companies in Australia, North America and Europe before joining the Knowledge Center team at TPGi.