Fix aria-hidden-focus axe errors
Content hidden from the accessibility tree can still receive keyboard focus, creating a control that is focusable but not announced.
Кого затрагивает
Keyboard and screen-reader users, especially when dialogs, drawers and collapsed navigation change visibility.
Связь с WCAG
4.1.2 Name, Role, Value (A)
Обнаружение
wcagc finds focusable elements inside an aria-hidden subtree, including descendants that remain in the tab order.
Почему возникает эта ошибка
- A closed modal or drawer is visually moved off-screen but its controls stay focusable.
- aria-hidden is toggled without also disabling interaction.
- A focusable descendant is inserted after the parent was hidden.
Проблемная разметка
<div aria-hidden="true"><button type="button">Dismiss</button></div>Исправленный код
<div hidden><button type="button">Dismiss</button></div>Проверьте исправление вручную
Tab through the page while opening and closing the affected component. Focus must never enter hidden content, and it should move to a predictable visible control when content closes.
Границы автоматизации
A static scan cannot prove that focus is managed correctly through every open, close and animation state. Test the complete keyboard interaction.
Источники и стандарты
Метаданные правила и ссылка Deque генерируются из axe-core 4.12.1. Ссылка W3C ведёт на нормативное руководство WCAG для соответствующего критерия.
Вопросы разработчиков
Can I add tabindex=-1 to the hidden control?
That may remove one element from sequential focus, but all descendants and scripted focus paths still need attention. Prefer hidden or inert when the whole subtree is unavailable.
Is aria-hidden the same as hidden?
No. aria-hidden removes content from the accessibility tree but does not visually hide it or prevent focus and pointer interaction.
Одно нарушение редко встречается в одиночку
Запустите проверку страницы в wcagc, чтобы найти это правило, связанные проблемы WCAG, затронутые селекторы и пункты, требующие ручной оценки.
Проверить страницу