Совсем недавно пришлось исправить один паттерн в системе дизайна, вызывавший множество ошибок, о которых сообщалось при автоматическом тестировании доступности. А именно — использование aria-hidden="true" для интерактивных элементов (или их предков). Я помнил из своих тренингов и исследований, что такая комбинация плохо сказывается на доступности, поскольку элементы всё равно получают фокус при "табуляции" на них, даже если они намеренно скрыты от дерева доступности.
Чтобы лучше объяснить людям, которых я обучаю, решил поэкспериментировать, что ещё происходит в реальном мире, и написать об этом здесь.
Скринридеры ведут себя по-разному
До тестирования на скринридерах я бы предположил, что элементы с aria-hidden="true" (на их предке или на них самих) будут полностью игнорироваться скринридерами. Я ожидал этого. Затем возникает вопрос: хорошо, а что, если мы используем скринридер и перемещаемся по странице с помощью Tab? Что тогда произойдёт?
Ну, это зависит (почти торговая марка). Опять — зависит от комбинации скринридера и браузера.
Я не тестировал все возможные комбинации и не тестировал разные версии, только последние, которые были под рукой, и вот результаты;
- NVDA и Chrome — при переходе Tab к интерактивным элементам они объявляются безымянными (то есть объявляются их роли, но не их имена). Такие интерактивные элементы недоступны в списке элементов и других ярлыках, поэтому практически невидимы.
- Narrator и Chrome vs. Edge — табуляция по элементам работала так же, как и с обычными интерактивными элементами (в основном игнорируя
aria-hidden="true"), за исключением того, что Edge объявлял неверную роль для кнопки, но не для ссылки. Элементы не были доступны в ярлыках Narrator. - VoiceOver и Safari (iOS) — ничего не было объявлено, и все элементы были недоступны. Даже непосредственный тап по ним не срабатывал. В меню Rotor нет ни единого следа.
- TalkBack и Chrome (Android) — то же самое, что и с VoiceOver и Safari — ничего не объявлено, нигде нет следов.
Это были лишь возможные варианты, и на самом деле неважно, какие версии использовались, так как в любом случае вы никогда не должны использовать aria-hidden="true" на родителях — или непосредственно на интерактивных элементах. Но я просто хотел проверить, какие последствия это имеет для пользователей скринридеров.
Это действительно выглядит запутанным, и мне кажется, что TalkBack и VoiceOver, полностью игнорирующие интерактивные элементы, жёстко соблюдают спецификацию, в то время как реализация NVDA и Narrator немного более свободна.
Учтите — эти тесты могут стать неактуальными в любой момент, поскольку всё может измениться, особенно для такого сценария, который не следует использовать в реальной жизни. Но я наверняка вспомню об этом эксперименте, когда в следующий раз буду объяснять, почему это плохо, и, надеюсь, вы тоже.
Код, использованный для тестирования:
<section aria-hidden="true">
<h3>parent with aria-hidden with a button and a link</h3>
<button type="button">Test button in a parent</button>
<a href="#">Test link in a parent</a>
</section>
<section>
<h3>Button and link that have aria-hidden attribute</h3>
<button type="button" aria-hidden="true">Independent button with aria-hidden</button>
<a href="#" aria-hidden="true">Independent link with aria-hidden</a>
</section>Тестовая страница, если хотите опробовать сценарии.
Как решить эту проблему
В идеале следовало бы использовать CSS display:none; или visibility:hidden; или HTML атрибут hidden, но это не вариант, так как хотелось, чтобы содержимое было как бы
видно (из-за необходимости анимации).
Я использовал — теперь уже хорошо поддерживаемый — HTML аттрибут inert. Он решает все проблемы, которые не может решить aria-hidden="true";
- Контент со всеми дочерними элементами, включая интерактивные, по-прежнему отображается и виден.
- Вы больше не можете перемещаться табом к интерактивным элементам.
- Контент и интерактивные элементы удаляются из дерева доступности.
И снова полезная вещь для обучения людей — возможности, которые у нас есть, когда мы думаем о видимости, фокусе клавиатуры и доступности дерева воздействия.
Заключение — остерегайтесь aria-hidden=true
Я нечасто использую aria-hidden="true", даже для не интерактивных элементов, за исключением случаев, когда имеются дублирующие иконки (иконки, используемые в кнопке или ссылке, где также есть видимый текст). Последнее время я не использую aria-hidden="true" для всего остального. Это может сбивать с толку, когда что-то скрывается для вспомогательных технологий (например, скринридеров), но при этом отображается визуально (некоторые пользователи скринридеров могут видеть экран).
В любом случае не используйте aria-hidden="true" в интерактивных элементах или их родительских элементах — теперь вы знаете, почему (если раньше вы были настроены скептически).