Как скринридер «видит» сайт: DOM, accessibility tree и API простыми словами
Д
Джексон Стей
·7 мин читать
Когда речь идет о скринридерах, большинство людей предполагает, что они просто читают HTML-структуру страницы. Это заблуждение. Скринридер не видит экран, не…
Статья была полезной?
Когда речь идет о скринридерах, большинство людей предполагает, что они просто читают HTML-структуру страницы. Это заблуждение.
Скринридер не видит экран, не читает HTML напрямую и не "перемещается" по странице так, как это делает человек с мышкой.
Между веб-страницей и скринридером находятся несколько промежуточных слоев.
И именно из-за них доступность либо функционирует, либо полностью нарушается.
У любого сайта есть три ключевых уровня, через которые проходит информация:
DOM — элементы, присутствующие на странице.
Accessibility Tree — что из этих элементов имеет значение для пользователя.
Accessibility API — как браузер передаёт отфильтрованные данные скринридеру.
Скринридер работает не с HTML, а только с тем, что браузер передал ему через эти уровни.
Далее мы рассмотрим каждый из них подробнее, используя простую метафору, чтобы все аспекты сформировались в одну целую картину.
Представьте себе ситуацию из реальной жизни.
Вы переехали в новую квартиру, и в комнате стоят коробки.
На каждой из них написано:
«Посуда»
«Одежда»
«Документы»
«Книги»
По этим подписям вы можете предположить, что внутри. Однако вы не знаете точно:
хрупкое ли содержимое,
можно ли коробку переворачивать,
стоит ли открывать её сейчас,
есть ли внутри что-то важное или срочное.
Таким образом, подписи дают лишь намек, но не инструкцию.
Вот как это все работает и в DOM.
Вернемся к браузеру.
Представьте, что браузер открывает страницу и видит элемент с текстом «Купить». И это всё.
Браузер не знает, что это:
кнопка,
ссылка,
важное действие,
или просто текст на странице.
Он видит только факт: на странице есть элемент с текстом «Купить».
<div>Купить</div>Для DOM это означает только одно:
есть div,
внутри него — текст.
DOM не делает выводов о смысле. Он не понимает намерение автора и не знает, как пользователь должен взаимодействовать с элементами.
DOM — это полный список всего, что находится на странице с точки зрения браузера:
заголовки,
абзацы,
кнопки,
ссылки,
картинки,
и порядок, в котором всё это расположено.
DOM фиксирует: «Вот что есть и вот где это расположено».
Но он не объясняет, какой смысл имеют элементы и как с ними взаимодействовать.
Зрячий пользователь считывает смысл объектов визуально:
по форме кнопки,
по цвету,
по расположению.
Скринридер этого не видит. Он ориентируется только на то, что явно описано в DOM и семантике. Если смысл не задан, пользователь остается в неопределённости.
Если DOM — это просто коробки на складе (они есть, находятся в каком-то порядке, на них что-то написано), то Accessibility Tree — это момент, когда к этим коробкам появляется инструкция.
Браузер смотрит на DOM и решает:
это вообще важно для пользователя?
с этим можно взаимодействовать?
это нужно читать вслух?
или это просто декор, и его можно игнорировать?
В Accessibility Tree попадает не все, что есть в DOM.
Представьте склад.
Коробки те же самые, но теперь:
не все коробки внесены в опись,
к важным добавлены пояснения,
стало понятно, что с ними делать.
На коробке появляются не просто слова, а смысл:
«Кнопка. Основное действие. Можно нажать».
«Заголовок. Описывает раздел».
«Поле ввода. Нужно ввести имя».
Accessibility Tree — это перевод DOM на человеческий язык.
Рассмотрим простой пример.
<button>Купить</button>В Accessibility Tree это преобразуется в:
роль: кнопка
имя: «Купить»
Скринридер скажет: Кнопка. Купить.
Теперь другой вариант:
<div class="btn">Купить</div>Для DOM это просто:
div с текстом «Купить»
Но в Accessibility Tree:
нет роли
нет имени
нет возможности взаимодействия
Для пользователя со скринридером этого элемента не существует, даже если зрячий его прекрасно видит.
Скринридер не читает страницу сверху вниз, как это делает человек. Он ориентируется по структуре.
Если в Accessibility Tree:
нет кнопки,
нет заголовка,
нет имени у поля,
то для пользователя: этого просто не существует.
Именно поэтому:
визуально «красивый» интерфейс может быть полностью недоступным,
а семантически простой интерфейс — понятным и управляемым.
Accessibility API — это коммуникационный канал между браузером и скринридером.
Важно сразу осознать ключевую идею: скринридер не читает HTML, не смотрит на страницу, не знает, что такое DOM.
Скринридер взаимодействует исключительно с Accessibility API.
Существует три ключевых элемента:
Браузер (Chrome, Safari, Firefox)
Accessibility API (часть операционной системы)
Скринридер:
– VoiceOver (macOS, iOS)
– NVDA, JAWS (Windows)
– TalkBack (Android)
Скринридер задаёт вопросы API:
Что вообще есть на экране?
Какие элементы важные?
В каком порядке по ним двигаться?
Это кнопка или просто текст?
Можно ли с этим взаимодействовать?
API отвечает ему уже готовыми, структурированными данными.
DOM → коробки
Accessibility Tree → опись с пояснениями
Accessibility API → способ передачи этой описи человеку, который не видит склад
Есть нюанс: Человек не видит склад.
Он не может:
подойти к коробке,
прочитать надпись,
увидеть, что она важная.
Ему нужен кто-то, кто зачитает опись вслух. Вот эту роль и выполняет Accessibility API.
Сначала браузер строит DOM — полную техническую модель страницы.
Затем на его основе формирует Accessibility Tree — отфильтрованную и осмысленную структуру для пользователя.
И только эту структуру через Accessibility API он передаёт скринридеру.
«Коробка. Кнопка. Основное действие. Можно нажать.»
«Коробка. Заголовок. Начало раздела.»
«Коробка. Поле ввода. Нужно ввести имя.»
Скринридер не взаимодействует с страницей напрямую.
Пример в браузере
<button>Купить</button>Что происходит дальше:
HTML → попадает в DOM
Из DOM → формируется Accessibility Tree
Из дерева → данные уходят в Accessibility API
API передаёт скринридеру:
роль: кнопка
имя: «Купить»
состояние: доступна
Скринридер читает: «Кнопка. Купить.»
Если элемент:
не попал в Accessibility Tree,
не имеет роли,
не имеет имени,
не имеет состояния,
то API не сможет передать его скринридеру.
А значит: Для пользователя этого элемента не существует.
Визуально всё выглядит логично и предсказуемо: понятно, где начать, куда нажать и как закрыть окно.
Визуально всё выглядит логично и предсказуемо: понятно, где начать, куда нажать и как закрыть окно.
Зрячий пользователь видит привычную картину:
затемнённый фон сайта,
модальное окно по центру,
заголовок «Вход с помощью пароля»,
поля для логина и пароля,
чекбокс «Запомнить меня»,
ссылка «Восстановить пароль»,
основная кнопка «Войти»,
вторичная «Отменить»,
крестик закрытия в углу.
Если разложить этот экран на слои, получится три разных представления одного и того же интерфейса:
DOM — просто набор элементов: div’ы, инпуты, кнопки, ссылки.
Он не знает, что это диалог, где главное действие и что фон в данный момент недоступен.
Accessibility Tree — версия страницы, которую браузер считает важной для пользователя. Сюда должны попасть заголовок, поля ввода, кнопки и ссылки, а фон — наоборот, исчезнуть.
Accessibility API — коммуникационный канал, через который браузер передаёт эту структуру скринридеру.
Идеальный сценарий для пользователя со скринридером
Если всё реализовано корректно, сценарий звучит примерно так:
«Диалог. Вход с помощью пароля.»
«Заголовок первого уровня. Вход с помощью пароля.»
«Поле ввода. Номер телефона или почта.»
«Поле ввода. Пароль. Защищенное.»
«Кнопка. Показать пароль.»
«Флажок. Запомнить меня.»
«Ссылка. Восстановить пароль.»
«Кнопка. Войти.»
«Кнопка. Отменить.»
Фокус не уходит за пределы модального окна.
На практике такие экраны часто дают сбой:
модальное окно не объявлено как диалог,
фон остаётся доступным для навигации,
у иконки «глаз» нет имени,
крестик закрытия — без aria-label,
Tab-порядок скачет или уводит пользователя «под окно».
В результате человек слышит не форму входа, а случайный набор элементов страницы.
При проверке окна входа на Суточно.ру со скринридером выяснилось, что модальное окно не попадает в accessibility tree. Скринридер продолжает читать элементы основного сайта, игнорируя визуально открытое окно авторизации.
При проверке окна входа на Суточно.ру со скринридером выяснилось, что модальное окно не попадает в accessibility tree. Скринридер продолжает читать элементы основного сайта, игнорируя визуально открытое окно авторизации.
Это означает, что для пользователя скринридера окно входа фактически не существует: фокус не переводится внутрь диалога, поля ввода и кнопки недоступны, закрыть окно также невозможно.
Подобная проблема часто возникает, когда модальное окно реализовано без role="dialog", aria-modal="true" и корректного управления фокусом.
Для сравнения можно посмотреть, как реализовано окно входа в Яндекс ID.
При проверке со скринридером модальное окно авторизации читается как единый логический блок: сначала объявляется заголовок окна, затем — список доступных аккаунтов и действия. Фокус корректно переводится внутрь диалога, а фон страницы исключается из навигации.
В результате пользователь скринридера получает тот же сценарий, что и зрячий пользователь: четкое понимание, где он находится, какую задачу он выполняет и какие действия доступны.
Доступность нарушается не в коде, а в более ранних этапах — на этапе проектирования.
Именно дизайнер задает:
это заголовок или просто крупный текст;
это кнопка или «кликабельный прямоугольник»;
у поля есть лейбл или плейсхолдер;
ошибка объясняется словами или только красной рамкой;
понятно ли, что происходит, если не видеть экран.
Разработчик может сделать всё «по макету».
Но будет ли этот макет понятен скринридеру — решается на этапе дизайна.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…