Как скринридер «видит» сайт: DOM, accessibility tree и API простыми словами

Когда речь идет о скринридерах, большинство людей предполагает, что они просто читают HTML-структуру страницы. Это заблуждение.

Скринридер не видит экран, не читает HTML напрямую и не "перемещается" по странице так, как это делает человек с мышкой.

Между веб-страницей и скринридером находятся несколько промежуточных слоев.
И именно из-за них доступность либо функционирует, либо полностью нарушается.

Как браузер взаимодействует со скринридером

У любого сайта есть три ключевых уровня, через которые проходит информация:

1. DOM — элементы, присутствующие на странице.

2. Accessibility Tree — что из этих элементов имеет значение для пользователя.

3. Accessibility API — как браузер передаёт отфильтрованные данные скринридеру.

Скринридер работает не с HTML, а только с тем, что браузер передал ему через эти уровни.

Далее мы рассмотрим каждый из них подробнее, используя простую метафору, чтобы все аспекты сформировались в одну целую картину.

DOM — что такое и как он работает

Представьте себе ситуацию из реальной жизни.

Вы переехали в новую квартиру, и в комнате стоят коробки.
На каждой из них написано:

• «Посуда»

• «Одежда»

• «Документы»

• «Книги»

По этим подписям вы можете предположить, что внутри. Однако вы не знаете точно:

• хрупкое ли содержимое,

• можно ли коробку переворачивать,

• стоит ли открывать её сейчас,

• есть ли внутри что-то важное или срочное.

Таким образом, подписи дают лишь намек, но не инструкцию.

Вот как это все работает и в DOM.

Вернемся к браузеру.

Представьте, что браузер открывает страницу и видит элемент с текстом «Купить». И это всё.

Браузер не знает, что это:

• кнопка,

• ссылка,

• важное действие,

• или просто текст на странице.

Он видит только факт: на странице есть элемент с текстом «Купить».

<div>Купить</div>

Для DOM это означает только одно:

• есть div,

• внутри него — текст.

DOM не делает выводов о смысле. Он не понимает намерение автора и не знает, как пользователь должен взаимодействовать с элементами.

Какова суть DOM?

DOM — это полный список всего, что находится на странице с точки зрения браузера:

• заголовки,

• абзацы,

• кнопки,

• ссылки,

• картинки,

• и порядок, в котором всё это расположено.

DOM фиксирует: «Вот что есть и вот где это расположено».

Но он не объясняет, какой смысл имеют элементы и как с ними взаимодействовать.

Почему понимание DOM критично для доступности

Зрячий пользователь считывает смысл объектов визуально:

• по форме кнопки,

• по цвету,

• по расположению.

Скринридер этого не видит. Он ориентируется только на то, что явно описано в DOM и семантике. Если смысл не задан, пользователь остается в неопределённости.

Accessibility Tree — интерпретация для пользователей

Если 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 Tree:

• нет кнопки,

• нет заголовка,

• нет имени у поля,
  то для пользователя: этого просто не существует.

Именно поэтому:

• визуально «красивый» интерфейс может быть полностью недоступным,

• а семантически простой интерфейс — понятным и управляемым.

Accessibility API — связь между браузером и скринридером

Accessibility API — это коммуникационный канал между браузером и скринридером.

Важно сразу осознать ключевую идею: скринридер не читает HTML, не смотрит на страницу, не знает, что такое DOM.

Скринридер взаимодействует исключительно с Accessibility API.

Как это функционирует на практике

Существует три ключевых элемента:

1. Браузер (Chrome, Safari, Firefox)

2. Accessibility API (часть операционной системы)

3. Скринридер:
   – VoiceOver (macOS, iOS)
   – NVDA, JAWS (Windows)
   – TalkBack (Android)

Скринридер задаёт вопросы API:

• Что вообще есть на экране?

• Какие элементы важные?

• В каком порядке по ним двигаться?

• Это кнопка или просто текст?

• Можно ли с этим взаимодействовать?

API отвечает ему уже готовыми, структурированными данными.

Аналогия для понимания

• DOM → коробки

• Accessibility Tree → опись с пояснениями

• Accessibility API → способ передачи этой описи человеку, который не видит склад

Есть нюанс: Человек не видит склад.

Он не может:

• подойти к коробке,

• прочитать надпись,

• увидеть, что она важная.

Ему нужен кто-то, кто зачитает опись вслух. Вот эту роль и выполняет Accessibility API.

Последовательность работы в браузере

1. Сначала браузер строит DOM — полную техническую модель страницы.

2. Затем на его основе формирует Accessibility Tree — отфильтрованную и осмысленную структуру для пользователя.

3. И только эту структуру через Accessibility API он передаёт скринридеру.

«Коробка. Кнопка. Основное действие. Можно нажать.»
«Коробка. Заголовок. Начало раздела.»
«Коробка. Поле ввода. Нужно ввести имя.»

Скринридер не взаимодействует с страницей напрямую.

Пример в браузере

<button>Купить</button>

Что происходит дальше:

1. HTML → попадает в DOM

2. Из DOM → формируется Accessibility Tree

3. Из дерева → данные уходят в Accessibility API

API передаёт скринридеру:

• роль: кнопка

• имя: «Купить»

• состояние: доступна

Скринридер читает: «Кнопка. Купить.»

Почему важность Accessibility API невозможно переоценить

Если элемент:

• не попал в Accessibility Tree,

• не имеет роли,

• не имеет имени,

• не имеет состояния,

то API не сможет передать его скринридеру.

А значит: Для пользователя этого элемента не существует.

Практический пример: форма входа

Визуально всё выглядит логично и предсказуемо: понятно, где начать, куда нажать и как закрыть окно.

Восприятие обычным пользователем

Зрячий пользователь видит привычную картину:

• затемнённый фон сайта,

• модальное окно по центру,

• заголовок «Вход с помощью пароля»,

• поля для логина и пароля,

• чекбокс «Запомнить меня»,

• ссылка «Восстановить пароль»,

• основная кнопка «Войти»,

• вторичная «Отменить»,

• крестик закрытия в углу.

Что происходит под капотом

Если разложить этот экран на слои, получится три разных представления одного и того же интерфейса:

• DOM — просто набор элементов: div’ы, инпуты, кнопки, ссылки.
  Он не знает, что это диалог, где главное действие и что фон в данный момент недоступен.

• Accessibility Tree — версия страницы, которую браузер считает важной для пользователя. Сюда должны попасть заголовок, поля ввода, кнопки и ссылки, а фон — наоборот, исчезнуть.

• Accessibility API — коммуникационный канал, через который браузер передаёт эту структуру скринридеру.

Идеальный сценарий для пользователя со скринридером

Если всё реализовано корректно, сценарий звучит примерно так:

«Диалог. Вход с помощью пароля.»
«Заголовок первого уровня. Вход с помощью пароля.»
«Поле ввода. Номер телефона или почта.»
«Поле ввода. Пароль. Защищенное.»
«Кнопка. Показать пароль.»
«Флажок. Запомнить меня.»
«Ссылка. Восстановить пароль.»
«Кнопка. Войти.»
«Кнопка. Отменить.»

Фокус не уходит за пределы модального окна.

Частые ошибки при реализации доступности

На практике такие экраны часто дают сбой:

• модальное окно не объявлено как диалог,

• фон остаётся доступным для навигации,

• у иконки «глаз» нет имени,

• крестик закрытия — без aria-label,

• Tab-порядок скачет или уводит пользователя «под окно».

В результате человек слышит не форму входа, а случайный набор элементов страницы.

При проверке окна входа на Суточно.ру со скринридером выяснилось, что модальное окно не попадает в accessibility tree. Скринридер продолжает читать элементы основного сайта, игнорируя визуально открытое окно авторизации.

Это означает, что для пользователя скринридера окно входа фактически не существует: фокус не переводится внутрь диалога, поля ввода и кнопки недоступны, закрыть окно также невозможно.

Подобная проблема часто возникает, когда модальное окно реализовано без role="dialog", aria-modal="true" и корректного управления фокусом.

Для сравнения можно посмотреть, как реализовано окно входа в Яндекс ID.
При проверке со скринридером модальное окно авторизации читается как единый логический блок: сначала объявляется заголовок окна, затем — список доступных аккаунтов и действия. Фокус корректно переводится внутрь диалога, а фон страницы исключается из навигации.

В результате пользователь скринридера получает тот же сценарий, что и зрячий пользователь: четкое понимание, где он находится, какую задачу он выполняет и какие действия доступны.

Роль дизайнера в обеспечении доступности интерфейса

Доступность нарушается не в коде, а в более ранних этапах — на этапе проектирования.

Именно дизайнер задает:

• это заголовок или просто крупный текст;

• это кнопка или «кликабельный прямоугольник»;

• у поля есть лейбл или плейсхолдер;

• ошибка объясняется словами или только красной рамкой;

• понятно ли, что происходит, если не видеть экран.

Разработчик может сделать всё «по макету».
Но будет ли этот макет понятен скринридеру — решается на этапе дизайна.