Focus Management in Accessibility

Focus management for screen readers is an important task, especially in web applications. Unfortunately, recurring errors are common, which will be addressed in this article. In this article, I'm assuming that keyboard and screen reader focus are the same thing.

Leave the focus alone

For classic websites without much dynamic changes, it makes sense not to control the focus. Exceptions are the almost always present cookie message and hidden content such as menus.

As a rule, it's useful for the keyboard focus to follow the visual flow of a website, from left to right and from top to bottom, i.e., line by line. In my opinion, however, there are a few exceptions.

When Microsoft Windows was still the dominant operating system, the OK button was always on the left, while the Cancel button was on the right. This may be due – at least in the West – to the common left-to-right viewing direction here; our texts also run from left to right.

This changed at the latest with the advent of Apple's mobile operating system. Apple—and now Android—places the OK button on the right and the Cancel button on the left by default. Perhaps this is because most people hold their smartphones on the left, and the right-handed fingers have a shorter path to confirm. However, we now also find this positioning in web and sometimes desktop applications.

Following the requirement described in the first paragraph, the tab would first have to be placed on the left "Cancel" button, since it is the first visible button. This is problematic because "OK" is usually the action you want to trigger. I'll call it the default action here. There's a risk of accidentally triggering the wrong action.

Of course, it would make more sense to arrange the elements from the outset the way you would use them. Some design patterns make no sense at all. However, this is hardly feasible in an existing application, as it would involve a profound change in the design, and it's rare to convince those responsible; the pattern has largely prevailed.

A difficult case is when a default action is located before the input field. An example of this is Twitter. Here, the Send button is located above the input field. You can't access the element with the arrow keys or with Tab when you move down from the input field. This isn't a problem for sighted keyboard users, as they can see that the button is at the top. It is not convenient, because you get out of the flow: First, tab forward to get to the input field, then tab back to send the text. In my opinion, it would make more sense in this case to position the tab on the send button at the top after leaving the input field. That used to be the case, but since I no longer use Twitter, I don't know the current status.

An even more difficult case is when the elements are located completely above of the triggering content, for example, in Google Mail. Users have to select an email to display the actions and then scroll up using the tab or arrow keys until they reach these actions. In this case, redirecting the keyboard tab wouldn't make sense, because it would completely throw you out of the flow. Note: Since I tested this blind, I don't know if there are standard actions for sighted users in the email list that the screen reader can't find. It would be useful to indicate to the screen reader that and where the actions were displayed, as well as a quick way to get there, for example. via shortcut.

Focus trap for displayed content

A focus trap is generally used for displayed content. This means that the focus remains in the displayed area as long as it is open. Examples include a cookie message or a drop-down navigation.

The key question is, where should the focus go when the element is closed? If the message is triggered by the user, as with the navigation, the focus should return to the triggering element. For cookie messages that are not triggered by the user, the focus should be set either to the top of the page or to the location where the user was when the display was opened. Completely blind people will completely lose their orientation if the focus is not controlled in such cases and ends up somewhere else on the page.

Common Mistakes

In some applications, you can see that the focus is set to an alert. This doesn't make sense. A current example is the Rewe shop: If you add a product to your shopping cart, the focus is set to an alert informing you that you haven't reached the minimum order value, provided you haven't already. The focus is reset to the triggering element, but this takes a few seconds, during which you can clean your screen. This is a classic case of misusing an element. An alert doesn't need focus to be read out. An exception would be if the alert contained a UI element.

Tabindexes for controlling focus should also be used sparingly; they often cause more harm than good. I've seen the craziest focus gradients because someone thought it made sense for some reason.

Dynamic Content

If content changes dynamically, the focus usually doesn't need to be moved. However, changes should always occur behind the screen reader's current focus, not above it. The screen reader won't detect what happens above it, and changed content can be difficult to find.

One example is a form that changes when you make a selection at the top.

More on accessible Components