Watch for these common and often overlooked edge cases

Focus management is an essential part of accessibility. If a web page cannot be navigated sequentially (advancing focus with a keyboard interface), it fails one of the most basic accessibility requirements, focus order (WCAG 2.4.3, level A).

Keyboard-only users, including blind people and people with motor impairments preventing the use of a pointer device, may find themselves unable to complete an action because an interactive element is not available to them. When focus is not handled correctly, critical user workflows can become inaccessible, creating a jarring or unusable experience.

For the most part, what is required is not to interfere with the built-in accessibility: do not remove interactive elements from the tab sequence, do not add non-interactive elements to the tab sequence, and do not make the tab order illogical.

But two common cases require particular attention: when focus is moved to another area on the page, which happens for instance when opening a modal, and when the element in focus is removed from the page, which happens for instance with the delete button of an element in a list.

1. Focus redirection

Moving focus should be done with great caution as it can be very confusing to users, in particular blind users. It should be a direct and predictable result of a user-initiated action, or follow a clear pattern, such as a message warning the user that their session is about to expire and requesting them to take action.

In fact, modals are the main use case for moving focus. They are essential for interrupting a user's workflow to present or ask for crucial information. They create a temporary context that requires careful focus control.

The Problem: When a modal opens, keyboard focus must be shifted programmatically into the modal and trapped there. If focus is not managed, the user may have no way to interact with the element in the modal. If focus is not trapped within, elements behind the modal may receive focus, creating confusion.

The Solution: Move focus to the first interactive element inside the modal, and implement a focus trap (typically using JavaScript to manage the Tab key presses).

Note: The native <dialog> focus trap includes the browser's address bar and other browser chrome elements, which differs from the user-expected behavior of focus staying strictly within the modal content. To meet user expectations, Watermark best practice requires additional scripting on top of the built-in <dialog>'s focus handling, to limit the focus trap only to the elements inside the modal.

2. Removal of the element in focus

This second case concerns interactive elements whose action results in their own removal. Think of a list item with a delete button. When pressed, the button will remove the item from the list, and therefore itself.

When the user triggers such an action, this element is — obviously — in focus. Since the action implies the removal of the very element that was triggered, focus is lost. Another instance where the element in focus is removed on click is the closing of a modal.

The Problem: When focus is lost, it goes to the <body> element, disorienting and slowing down the user, who is forced to find their place again. A screen reader will typically announce the page title, or even remain silent, leaving the user unsure if their action was even successful.

The Solution: The script must explicitly calculate and set focus to a logical element near the removed node. For example, after deleting an item from a list, focus should move to the next element in the list (or previous one if the deleted element was last).

Keyboard focus goes to the upload button when the last item is removed

Wrapping up

As a reminder, here are the most important points to keep in mind when it comes to keyboard focus:

These are real, common issues affecting our users. The 2025 accessibility audit revealed that three of them (Keyboard, Focus order and Focus visible) were among the eight most frequent accessibility issues in Watermark products. Ripple components handle focus, which is quite intricate for many of them (Modal, Uploader, Tag Input, Snackbar, Charts, just to name a few). Use them when you can! And when it is not an option, make sure to keep keyboard focus in mind.

Related: Ripple's Focus indicators can be found here.

Back to Top