Modal Accessibility Audit: The Pattern Everyone Gets Wrong

What We Keep Finding

The modal is a small pattern with five ways to fail, and most hand-rolled implementations pick several. Focus stays behind the dialog, so the keyboard types into a page that is visually gone. Escape does nothing. The screen reader can still wander the background. Closing returns focus to nowhere. And the dialog announces without a name, so what just opened is anyone's guess.

Here is the part that surprises teams. Four of those five come free. A native dialog element opened with showModal() moves focus in, contains the tab sequence, handles Escape, makes the background inert, and returns focus to whatever opened it. What is left for you is where focus lands first and what the dialog is called. Most of what we find is a div wearing a dialog's clothes, rebuilding four solved problems and getting three of them wrong.

The other half of this door is the thing that is not a modal, and it needs the opposite tests. A popover, a coach mark, a non-modal drawer. For those, containing Tab inside is a failure rather than a pass, because the whole point is that the page behind stays reachable. W3C says plainly that constraining focus should be used cautiously, since it can leave keyboard users worse off than mouse users. So the first question on every one of these is whether it should be modal at all, and the checks follow the answer rather than leading it.

One correction while we are here, because it produces false findings constantly. The Level AA rule about a focused control being hidden says "not entirely hidden". A popover half-covering the field you just tabbed to passes. The version that fails on any covering at all is Level AAA. Reports that state the AAA rule under the AA number are the reason somebody, somewhere, is rebuilding a component that was fine.