Dynamic content and single page applications require the same accessibility considerations as static websites and content, and in most cases those considerations are handled in the same way for both; however, dynamic sites and features have some key characteristics that require additional attention and testing to ensure they are accessible.
How are single page applications different?
One of the major differences between a standard static website and a single page dynamic application, is that a standard website generally reloads each page as the user navigates to them, or when the context of the page changes and new content is required.
Dynamic applications, however, inject new content into the same page without the need for a server reload.
How does this impact on accessibility?
This can impact on accessibility in a number of ways, most crucially with screen readers users, who are used to being notified of a new page loading, and having the page title announced, along with details about the page. This is clear feedback to the user that the action they took – clicking on a link, for example – resulted in a new page being loaded, and which page that is.
When no page reload occurs, screen readers are not aware that the content on the page has changed, and therefore nothing is announced to the user. The user may be unaware if the feature they activated worked, or if it is broken, and they will have to navigate through the page to try to find out.
Focus management
One way to handle this issue, is focus management. Focus is where the user *is* on the page at any given time. The content they are reading, or the interactive element they are currently in control of.
As focus is moved through content on a page, it is announced by screen readers. Focus is controlled in various ways by the user (using the keyboard, screen reader, mouse, etc), but can also be controlled dynamically using code in certain circumstances – this is focus management.
Focus management allows dynamic features of websites to be recognised and announced by screen readers, to indicate to users what is occurring on the screen.
For example, if a link loads a new page into the single page application, focus can be moved to the top of the new content – the main heading, for instance – which will then be announced by the screen reader to the user, informing them that their action had a result, and new content is now on the page.
Focus can be moved dynamically to a focusable element by using the focus() method in javascript, e.g. document.getElementById("target-id").focus();
It is important to only dynamically control focus when it is absolutely necessary, and as sparingly as possible to ensure users are always in control of how they navigate a page. Generally, the right time to control focus is after the user performs an action, in order to inform the user of the result of their action, and/or to move them to where they expect to be after performing that action.
Focusable elements
Not all elements can receive focus. Semantic interactive elements have the advantage of being focusable by default; however, markup can be added other elements to ensure they are also focusable.
The <button> and <a href=""> elements are two examples of elements that are natively keyboard focusable without additional code.
The <a> element must include the href attribute for keyboard focus.
In the early days of HTML, the tabindex attribute was used to manage the order in which elements on the page (predominately form fields) would receive focus as the user pressed the Tab key on the keyboard.
This would override the order of the elements in the code by following the number values given to the tabindex attribute. Interactive elements without a tabindex attribute have an implied value of 0 – meaning elements with a positive tabindex value (1+) would receive focus first on the page, then followed by every other interactive element in the order they are placed in the code.
Over time, this has proven to be a counter-intuitive approach to user experience, as it overrides user control and expectation, and becomes highly cumbersome to manage over time. While the days of manually controlling the Tab focus order are long gone (at least, they should be), the tabindex attribute itself remains important to building an accessible experience.
There are two tabindex values that are used for managing focus – 0, and -1. The 0 value gives an element the same focus abilities as a native interactive element has – it will be part of the Tab order of the page, and it will also be able to receive focus dynamically using code.
The -1 value will give the element the ability to receive focus dynamically; however, it will not be part of the Tab order. This is particularly useful for non-interactive elements that need to receive focus dynamically for screen reader users to understand dynamic changes on the page, such as the main heading of dynamically loaded content or modal dialog window, or the first item in a list of dynamically validated form errors.
Tips for accessible dynamic pages and content
1. Use semantic HTML elements unless it is not possible e.g.
<button> </button>
- When it is not possible, use ARIA markup to define what elements are, what they do, and their status e.g. <div role="button" tabindex="0"></div>
2. When a new page is loaded dynamically (without a page refresh)
- Update the page title to a unique title that describes the page
- Move focus to the main heading on the page
3. When a form is submitted with errors, move focus to the first field in error, and ensure that the error is communicated.
4. Ensure all (and only) actionable items are keyboard accessible
- If it's clickable, it can be focused and activated via keyboard
- The item in focus at any given time is visible and clearly identified
- Focused items follow a logical order (if using tabindex, only use -1 or 0 values)
- Tabindex="0" makes an item focusable in the Tab order, for actionable items
- Tabindex="-1" makes an item focusable programmatically only, for non-actionable items such as main headings.
5. Modal dialog boxes or content that overlays the screen should
- Be marked up using role="dialog"
- "Trap" keyboard focus within while open (ensure the close button is accessible)
- Move focus to the main heading or content inside the modal when it opens
6. Custom elements often generated by dynamic frameworks and libraries may confuse assistive technology, even if marked up using ARIA attributes. Ideally, include semantic elements inside custom tags rather than marking up the custom elements with custom semantics (i.e. use them as wrappers) e.g. <my-component></my-component>
<my-component> <button>View gallery</button> </my-component>
Additionally, you may look to leverage the community of the frameworks in use to discover accessibility tips and tricks, and packages that may assist. However, do so with caution, as there is a lot of misleading information about accessibility online.
It is important to have a basic understanding of accessibility first in order to understand the merits of any packages, code samples, or suggestions being made, and to be able to test them for yourself, which is essential.
Testing dynamic applications
There is no substitute for testing the application yourself, particularly if you are using solutions provided by the community or online.
The most effective high level testing can be done using a keyboard, and a screen reader. The best combination of free software is to use the NVDA screen reader with FireFox browser, and either VoiceOver on iOS or Talkback on Android for mobile devices. Mobile screen readers work differently to desktop screen readers so it is important to test with them separately.
Testing tips
- Ensure you can use the Tab key to move through each interactive element on the page, each is clearly visible and marked when in focus, and focus does not get "trapped" without being able to escape (i.e. using a close button on a modal).
- Ensure any "on click" functionality also works the same using the keyboard.
- Ensure the screen reader announces all content and features accurately
- Ensure screen readers inform the user of dynamic content updates, such as new pages loading, large changes in context, interactivity of features, status updates, or form submission errors.
Testing resources
NVDA:
More information
For more information about accessibility of dynamic content and single page applications, contact Digital Access.