Skip to content

A11y 101: 2.4.11 Focus Not Obscured (Minimum)

Modern dynamic websites use layers of content on a page. We have tooltips, popups, dialogs, menus, navigation, and modals that bring more functionality by using these layers. But they can introduce a problem for keyboard-only users when focus can fall on content underneath. Let’s explore how this can resolved.

The quick description around this is that some portion of the focused item must still be visible when focused if something covers it. A good example of this might be a compare dialog. You’ve picked a product to compare. The dialog is shown at the bottom of the viewport. As you continue to navigate down the page, the focused content scrolls into view. When the focus moves to the next row visible in the screen, the focus on the “Add to Cart” button is hidden by the compare dialog.

For the keyboard-only user, they can feel lost due to not seeing the focus. Many may use arrows to find scroll the page until they are viewed. But not all users will do this. If they also zoomed in due to low vision, they may have to scroll quite a while.

At the AA level, we need to make sure that at all resolutions, zoom up to 200%, resized text, or any other modifications to the UI the item currently in focus must have part of the component or focus ring visible.

Best Buy TV product listing page. On the left, we see the comparison dialog. Focus is on the product name for the second TV show. But it isn't visible until you scroll. Scrolled version on the right.

How do we support 2.4.11?

We have a few things we can do. The first thing we want to do is understand what kind of component we are working with. Starting with our comparison dialog, we need to compensate for the ehight of it when something gains focus. Similar to a sticky nav, we might need to bump the page up by 20, 30, 50 pixels until the focus indicator is seen.

Another method would be to minimize the dialog while the focus goes behind it. We won’t close it all the way, but we only need to leave a button to open it. But this doesn’t always work. It’s great for comparison, side panels, chat windows. It doesn’t work for modals or site navigation.

For modals, we need to remember that the user should not be able to get focus on the background. So we don’t worry about this criteria.

For non-modal dialogs on the page, we want to offer a way to move them. Calcite Design System has a great example of how to do drag and drop via keyboard. They offer a handle to grab by mouse to drag or resize the component. They enable keyboard accessibility by using enter and spacebar to grab and drop the component. When grabbed, arrows will position the item.

Of course, we also need to keep 1.4.13 Content on Hover or Focus in consideration too. In most cases, if an item is being obscured, the obscuring item should have followed this criterion to close those layers.

Summary

If you have to have overlapping layers, make sure the top layers move out of the way so that at least a portion of the item is exposed when it has focus.

Want to talk about this more? Reach me on BlueSky or LinkedIn!

Published ina11ya11y 101accessibilitydevelopmentEAAEN 301 549physical impairmentTestingW3CWCAGWeb Content Accessibility Guidelines

Comments are closed.