Краткий ответ

Сначала нужно проверить, видит ли TalkBack элемент в дереве доступности и представлены ли у него роль, имя, состояние и возможность получить фокус. Если другие приложения и стандартные элементы на том же устройстве озвучиваются нормально, а проблемный элемент отсутствует или описан неполно, дефект находится в семантике Android-интерфейса, а не в настройках скринридера.

Исторический контекст

Мобильные интерфейсы изначально часто описывались преимущественно визуально: цветом, расположением и изображениями. Для пользователей, которые не воспринимают экран напрямую, VoiceOver и TalkBack используют специальное дерево доступности, где каждому элементу доступны роль, текстовая метка, состояние и действия.

Такой подход позволяет скринридеру работать не с пикселями, а со смысловой моделью интерфейса. Поэтому визуально одинаковый экран может иметь разное качество доступности на iOS и Android: платформы используют разные API, правила семантики и способы построения дерева элементов.

Постановка проблемы

Элемент может быть видимым и реагировать на обычное нажатие, но при этом не попадать в дерево доступности. Другой вариант — элемент находится в дереве, однако не имеет имени, объявлен неинтерактивным или объединён с соседним содержимым.

Ошибка приводит к тому, что пользователь скринридера не понимает назначение элемента, не может перейти к нему линейной навигацией или не узнаёт его текущее состояние. Простая проверка включённого TalkBack недостаточна: она не показывает, какие свойства элемента реально переданы службе доступности.

Подробное решение

Проверку следует проводить поэтапно:

На том же устройстве открыть несколько стандартных приложений и проверить озвучивание обычных кнопок, полей и переключателей. Если TalkBack не работает и там, сначала проверяют настройки службы, громкость речи, выбранный язык и способ навигации.
Проверить проблемный экран линейным перемещением фокуса TalkBack. Если фокус пропускает элемент, вероятна проблема доступности контейнера или самого элемента.
Если элемент получает фокус, оценить озвученную фразу: в ней должны быть понятные имя, роль и, когда это применимо, состояние — например, включён ли переключатель или доступна ли кнопка.
Сравнить проблемный элемент с нативным контролом того же назначения. Это помогает отделить ошибку приложения от особенностей конкретного устройства или версии TalkBack.
Проверить состояния элемента: отключённый, выбранный, раскрытый, отмеченный и изменивший значение. Недостаток семантики часто проявляется не в начальном состоянии, а после взаимодействия.
Повторить тест на поддерживаемых версиях Android и с разными версиями TalkBack. Различия между версиями допустимы, но базовая роль и назначение элемента должны сохраняться.

На iOS аналогично проверяют, представлен ли объект как accessibility element, какое у него имя, роль и набор признаков состояния. Нельзя автоматически переносить вывод с VoiceOver на TalkBack: корректная реализация для одной платформы не доказывает корректность семантики на другой.

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

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

Ситуация из практики

В приложении иконка фильтра была реализована как визуальный контейнер с обработчиком нажатия. На iOS аналогичный элемент имел доступное имя и озвучивался VoiceOver, а на Android TalkBack пропускал его.

Рассматривались два варианта. Первый — изменить настройки TalkBack или рекомендовать пользователю другой режим навигации; это быстро, но не исправляет отсутствие элемента в дереве доступности. Второй — проверить Android-семантику контейнера, назначить ему корректную роль интерактивного элемента, понятное имя и состояние фильтра; этот вариант требует изменения приложения, зато устраняет причину.

Был выбран второй вариант. После исправления проверили линейную и жестовую навигацию, состояние фильтра до и после нажатия, отключённый вариант и несколько версий Android. В результате TalkBack начал озвучивать назначение и состояние элемента, а поведение стандартных контролов осталось неизменным.

Что кандидаты часто упускают

Достаточно ли проверить, что элемент имеет доступное имя?

Нет. Имя без роли и состояния может быть недостаточным. Пользователь должен понимать, что перед ним: кнопка, переключатель, поле, ссылка или другой объект, а также изменилось ли его состояние после действия. Например, озвучивание слова «Фильтр» без информации о применённых фильтрах не сообщает важную часть поведения интерфейса.

Почему визуально крупная область может озвучиваться как один элемент вместо нескольких?

Дерево доступности может объединять элементы на уровне контейнера. Если несколько независимых действий представлены как один доступный объект, скринридер не даст пользователю отдельно выбрать каждое действие. Нужно определить ожидаемую модель взаимодействия: единый составной контроль должен иметь одно понятное описание, а независимые кнопки — отдельные элементы с собственными ролями и именами.

Как проверить динамическое изменение состояния, а не только первоначальное озвучивание?

Нужно выполнить действие при включённом скринридере и убедиться, что фокус не теряется, а новое состояние становится доступным для чтения. Проверяют также появление и исчезновение элементов, раскрытие списков, ошибки валидации и изменение доступности кнопок. Если визуальное состояние меняется, но дерево доступности не обновляется, пользователь скринридера получает устаревшую информацию даже при корректной начальной семантике.