Let's look at a click event.
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
is added to a non-semantic element, such as a generic
<div role="button" tabindex="0" onclick="doAction()">Click me!</div>
<button onclick="doAction()">Click me!</button>
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.
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.
titles. This is especially important for
single-page apps (SPAs)
that load from a singular
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.
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
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
|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|
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.
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.
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.
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.
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
attribute to tell the user whether a drop-down menu or list is expanded or
Or you might use
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.
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.
Check your understanding