Accessibility finding
Failures that only show after a menu, dialog, accordion or form is used
Accessibility Error Severity: High
Part of the audit Interactive states and flows. Finding id: accessibility.dynamicStates.
What it costs you
The content that appears after this step has a failure that a scan of the page as it loads does not show. Menus, dialogs and error messages are where visitors act, so a barrier there stops the task.
What to do
Fix the component that prints the opened content or the error state, so every page that uses it is fixed. The scanner's guidance applies: [help url]
What it checks
- Opened menus and pop-ups have problems
- Form errors not accessible
- Keyboard position lost or misplaced
- Keyboard user gets stuck
- Status messages not announced
How to fix it
Use the native dialog and a live region
- After closing a dialog, check that focus is back on the control that opened it; put it there in script if it is not.
- Find the component named by the selector; it is usually shared by every page of the template.
- Change it once and check each kind of widget on one page.
How to check: Run the interaction script again: the step is no longer reported. Then walk through the widget with the keyboard only.
A real case
The UK Government Digital Service monitored 1,203 public sector websites from January 2022 to September 2024. The most common problems were low colour contrast, missing visible focus, parts that cannot be used with a keyboard, and layouts that do not adapt to screen size or zoom.
Thresholds
| Name | Default | Meaning |
|---|---|---|
min_scanners | 2 | How many scanners must report the same element after a step before it counts as a failure. |