Write accessible trigger events, page titles, dynamic content, and more.
Trigger events #
Let's look at a click event. If an
onClick() event is used on a semantic HTML element such as a
<a>, it naturally includes both mouse and keyboard functionality. However, keyboard functionality is not automatically applied when an
onClick() event is added to a non-semantic element, such as a generic
Preview this comparison on CodePen.
If a non-semantic element is used for a trigger event, a keydown/keyup event must be added to detect the enter or space key press. Adding trigger events to non-semantic elements is often forgotten. Unfortunately, when it's forgotten, the result is a component that's only accessible via a mouse. Keyboard-only users are left without access to the associated actions.
Page titles #
As we learned in the Document module, the page title is essential for screen reader users. It tells users what page they are on and whether they have navigated to a new page.
index.html file, as transitions or routes (page changes) will not involve a page reload. Each time a user loads a new page in an SPA, the title won't change by default.
Dynamic content #
Let's say you need to send a message to users when they log in to your website or app. You want the message to stand out from the white background and relay the message: "You are now logged in."
You can use the element
innerHTML to set the content:
document.querySelector("#banner").innerHTML = '<p>You are now logged in</p>';
You can apply CSS in a similar way, with
|Possible misuse||Correct use|
|Render large chunks of non-semantic HTML||Render smaller pieces of semantic HTML|
|Not allowing time for dynamic content to be recognized by assistive technology||Using a |
|Applying style attributes for ||Use |
|Applying inline styles may cause user stylesheets to not be read properly||Keep your styles in CSS files to keep the consistency of the theme|
Focus management #
In the Keyboard focus module, we covered focus order and indicator styles. Focus management is knowing when and where to trap the focus and when it shouldn't be trapped.
Focus management is critical for keyboard-only users.
Component level #
You can create keyboard traps when a component's focus is not properly managed. A keyboard trap occurs when a keyboard-only user gets stuck in a component, or the focus is not maintained when it should be.
Page level #
Focus must also be maintained when a user navigates from page-to-page. This is especially true in SPAs, where there is no browser refresh, and all content dynamically changes. Anytime a user clicks on a link to go to another page within your application, the focus is either kept in the same place or potentially placed somewhere else entirely.
When transitioning between pages (or routing), the development team must decide where the focus goes when the page loads.
There are multiple techniques to achieve this:
- Place focus on the main container with an
- Put the focus back to a link to skip to the main content.
- Move the focus to the top-level heading of the new page.
Where you decide to put the focus will depend on the framework you are using and the content you want to serve up to your users. It may be context- or action-dependent.
State management #
Often, the state of a component or page is managed through ARIA attributes, as introduced in the ARIA and HTML module. Let's review a few of the most common types of ARIA attributes used to help manage the state of an element.
Component level #
Depending on your page content and what information your users need, there are many ARIA states to consider when relaying information about a component to the user.
For example, you may use an
aria-expanded attribute to tell the user whether a drop-down menu or list is expanded or collapsed.
Or you might use
aria-pressed to indicate that a button has been pressed.
It's important to be selective when applying ARIA attributes. Think through the user flow to understand what critical information should be conveyed to the user.
Page level #
aria-live and alert regions due to its dynamic nature. Asynchronously adding content into the DOM makes it hard for AT to pick up the region and announce it. For the content to be properly read, the live or alert region must be in the DOM on load, then the text can dynamically be swapped out.
- React: react-aria-live and react-a11y-announcer
- Vue: vue-a11y-utils
Only semantic HTML automatically supports keyboard focus.
All HTML elements can support keyboard users.