I saw a post on LinkedIn about how some modal accessibility is broken because they trap focus, failing the Web Content Accessibility Guidelines (WCAG) success criterion 2.1.2 No Keyboard Trap. This is wrong, but it’s easy to understand how someone would reach this conclusion.
When talking about accessibility, we often cite WCAG because they lay out the criteria in a comprehensible way.
But practising accessibility (whether by developing accessible websites or apps, analysing or auditing accessibility on existing projects, or fixing these problems) usually requires going deeper.
First, we have the WCAG Understanding Documents. These help developers to better understand each criterion with background information and technical details, including sufficient techniques with examples.
Then, we have the Accessible Rich Internet Applications (ARIA) Suite. It defines how to make web content and web applications accessible to people with disabilities. The Authoring Practices Guide (APG) explains in detail how patterns and practices should be implemented.
We also have EN 301 549, which is the harmonised European standard for Accessibility requirements for ICT products and services. This norm specifies how WCAG applies to web content, documents, and apps.
So many materials can be overwhelming. But this means they go into very specific detail on what to accomplish and how.
Let’s start with criterion 2.1.2 No Keyboard Trap. The WCAG definition is: “If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”
Seems pretty straightforward. If you navigate with the keyboard, no component should trap you in a way you can’t get out using the keyboard.
But let’s explore the ARIA Dialog (Modal) Pattern. The ARIA documentation clarifies: “A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.”
There is no ambiguity. A modal (or dialog) should prevent the user from going outside the modal until it’s closed. Does this contradict the WCAG criterion?
If we take a look at the Understanding Document about success criterion 2.1.2, in the intent section, it explains: “The intent of this success criterion is to ensure that the content does not ‘trap’ keyboard focus within subsections of content on a web page. This is a common problem when multiple formats are combined within a page and rendered using plug-ins or embedded applications.
There may be times when the functionality of the web page restricts the focus to a subsection of the content, as long as the user knows how to leave that state and ‘untrap’ the focus.”
Everything seems to boil down to two considerations: if the exit method is standard, and if the application of the modal pattern is appropriate.
The first is easy to solve, as using the Esc key or a close button is mentioned in the ARIA Dialog (Modal) Pattern.
The second is where the important decision is. Why are we using a modal? This pattern is used to present information or a decision that has to be shown and acknowledged before the user can continue with their task.
If we go back to the post on LinkedIn, we now know that a modal where the user can move past it without acknowledging it is an incorrect implementation. So, where does the confusion come from? Probably the person posting this was thinking of a non-modal dialog where the user should be able to navigate outside the dialog. But naming it a modal and using it as an example of a failure to meet WCAG success criterion 2.1.2, they were just making a misleading claim.
The problem exists because modal is loosely used as a broad concept, encompassing several types of interface components with different behaviours and implementations. However, in the documentation, the modal specification is clearly defined and different from similar concepts.
Accessibility needs a more specific and rigorous use of language than other disciplines. Some may think this rigidness is unnecessary, but we are talking about standards. The rigour and reliability of the different documents and norms are a big part of what makes them valuable.