Revealing and Closing content
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.
This section is a combination of 2 from the Accessibility Insights for Web extension: "Revealing Content" and "Closing Content". But both are effectively part of the "Focus Order" guideline in WCAG.
When widgets are included in apps that open new content, like modals, popovers, or dialogs, it is important to ensure that users navigating with a keyboard or screen reader can easily understand and follow the content.
For example, when a modal dialog is opened, the focus should be moved to the first focusable element in the dialog. When the dialog is closed, the focus should be returned to the element that opened the dialog. This helps users to stay grounded in the page and interact in the "flow" of the content in the intended way, instead of being stranded or returned to unexpected areas of the site.
When using native HTML elements, it's apparently quite hard to get this wrong, as the browser handles the focus order for you. So find below an example of a dialog that follows the correct flow.
Note that when opening the modal using Enter on the "Open" button, the focus jumps straight into the modal and focuses the close button, as this is the first element that can be focused in the dialog.
When closing the dialog using "Escape" or the "Close" button, the focus returns to the "Open" button, allowing users to continue where they left off.
How to fix
As mentioned above, it's quite hard to get this wrong when using native HTML elements to handle elements like modals and dialogs. However, if something more custom is needed, then there are many accessible component libraries that can help with this.
Finally, if it does need to be fully custom, then it's best to follow the WAI-ARIA Authoring Practices for modals and dialogs.
Native HTML elements
The dialog element is a powerful tool for creating modals that follow the correct focus order. The MDN Docs on accessibility (opens in a new tab)
for the dialog element show how using the built-in showModal and close methods will handle the focus order for you.
The modal above is built using a better styled version of the below code:
<dialog ref={modalRef}>
<button onClick={() => modalRef.current?.close()}>
Close
</button>
{children}
</dialog>
<button onClick={() => modalRef.current?.showModal()}>
Open
</button>Component libraries
The issues faced by web developers when trying to come up with a fancy new component are often already solved by existing component libraries. there are many with accessibility built in, and they often come with a lot of customisation options, so it's still possible to make the components look and feel unique.
Libraries such as MUI (opens in a new tab), Chakra UI (opens in a new tab), Radix (opens in a new tab), and Cauldron (opens in a new tab) all have accessibility built in.
While these may miss some complex components, most of these cover a wide array of useful components used in the majority of projects and are a great starting point for any new project.
Custom components
If custom components are needed, then it's best to follow the WAI-ARIA Authoring Practices (opens in a new tab). These guides and patterns are set out to help developers create accessible components that have common controls and screen reader support.