Доступность мобильного приложения показывает, сможет ли человек выполнить задачу с тем способом взаимодействия, который ему подходит. Пользователь может читать экран через VoiceOver, управлять Android через TalkBack, увеличить текст или пользоваться переключателями. Для QA главный вопрос здесь очень конкретный: можно ли самостоятельно войти, найти нужные данные, исправить ошибку и завершить действие.
Красивый экран ещё не гарантирует доступный сценарий. Иконка может не иметь имени, ошибка — появляться вне фокуса, а кнопка оплаты — исчезать при увеличении текста. Такие дефекты блокируют продукт так же, как неработающий API.
С чего начинать проверку
Возьми критический маршрут и подготовь состояния: первый запуск, авторизованный пользователь, пустой список, заполненный список, ошибка API, открытая клавиатура. Запиши модель устройства, версию ОС, сборку, язык, версию экранного диктора и системные настройки текста. Результат зависит от их сочетания, поэтому фраза «проверено с VoiceOver» без окружения мало помогает при воспроизведении.
Начни с реального устройства и встроенного обучения диктора. Обычный одиночный тап после включения screen reader меняет назначение, и незнание жестов легко принять за дефект приложения.
Имена, роли и состояния элементов
Пользователь должен понимать, что это за элемент, какое действие он выполнит и в каком состоянии находится. Для кнопки с корзиной полезно имя «Корзина, 3 товара»; внутреннее имя изображения «cart_icon_24» не помогает. Переключатель должен сообщать, включён ли он, а выбранная вкладка — отличаться семантически.
Проверяй не только отдельные подписи. В списке заказов повторяющаяся кнопка «Подробнее» должна давать достаточно контекста для выбора нужного заказа. Декоративные изображения не должны засорять последовательность чтения. При этом объединение нескольких элементов в один не должно прятать доступное действие.
Последовательность чтения и управление фокусом
Пройди экран последовательными свайпами, затем исследованием касанием. Все существенные элементы должны быть достижимы, а порядок — соответствовать смыслу задачи. При открытии модального окна фокус должен попадать в него; закрытый фон не должен перехватывать навигацию. После закрытия полезно возвращать пользователя к логичному месту продолжения.
Отдельно проверь обновление списка, удаление выбранной строки, переход назад и появление клавиатуры. Сброс фокуса в начало длинного экрана после каждого изменения количества товара делает формально доступный интерфейс практически тяжёлым.
Крупный текст и масштабирование
На iOS проверь Dynamic Type, включая доступные увеличенные размеры. На Android меняй размер шрифта и масштаб отображения. Для каждого состояния оцени, можно ли прочитать цену, ошибку и условия действия, добраться до кнопки, прокрутить экран и закрыть диалог.
Обрезанное описание иногда допустимо по дизайну, но потерянная сумма заказа или недоступное подтверждение — уже функциональный барьер. Проверяй длинные переводы, крупные числа, альбомную ориентацию там, где она поддерживается, и сочетание крупного текста с открытой клавиатурой.
Размер целей, цвет и альтернативы жестам
Измеряй область нажатия, а не только видимую иконку. Для Android официальные рекомендации используют цель не меньше 48 × 48 dp. Отдельно проверяй расстояние между соседними действиями: увеличенная невидимая область не должна запускать удаление вместо открытия строки.
Ошибка должна объясняться текстом, выбранное состояние — передаваться не только цветом. Для drag-and-drop, сложных свайпов и удержаний проверь альтернативное доступное действие. Оцени контраст инструментом по принятому для продукта стандарту, включая тёмную тему и текст поверх изображений. Для неактивных элементов критерии контраста WCAG предусматривают исключение; их различимость можно отдельно оценивать как вопрос удобства продукта, не объявляя автоматически нарушением стандарта.
Сообщения, звук и движение
После сохранения или ошибки человек должен узнать результат без визуального поиска по экрану. Проверь объявление существенного изменения и возможность вернуться к нему. Слишком частые объявления тоже мешают: обновление таймера каждую секунду может перекрыть чтение формы.
Видеоконтент проверяй с предусмотренными субтитрами, а важные звуковые сигналы — с визуальным эквивалентом. При включённом уменьшении движения оцени анимации переходов: смысл и управление должны сохраняться. Системная настройка сама по себе не доказывает корректное поведение приложения.
Практический пример: оформление заказа
Подготовь корзину из двух товаров на тестовом аккаунте. Включи TalkBack или VoiceOver и выполни маршрут без помощи визуальных подсказок.
- →Найди оба товара и измени количество одного: озвучены название, новое количество и итоговая сумма; фокус остаётся в понятном месте.
- →Удали второй товар: удаляется ровно выбранная позиция, результат доступен диктору, корзина содержит одну строку.
- →Отправь форму с пустым обязательным адресом: поле достижимо, ошибка названа и связана с ним, заказ не создан.
- →Исправь адрес и подтверди покупку: создаётся один тестовый заказ, его номер доступен для чтения, повторный жест не создаёт дубликат.
Повтори маршрут с максимальным согласованным размером текста. Измеримый результат — все четыре шага выполняются самостоятельно, без недостижимых действий и потери обязательной информации. Время прохождения можно записывать для сравнения версий, но случайный норматив скорости не заменяет оценку доступности.
Что дают инструменты и как описывать дефект
Accessibility Scanner, инспекторы и автоматические аудиты помогают находить часть технических проблем. Они не определяют, понятна ли подпись и можно ли завершить задачу. Android прямо рекомендует сочетать ручную проверку, инструменты, автоматизацию и обратную связь пользователей; Apple также рекомендует проверять взаимодействие с assistive technologies, включая VoiceOver.
В баге укажи способ навигации, текущий фокус, фактическую озвучку и ожидаемое поведение. Приложи запись или текстовый transcript без персональных данных. «Кнопка недоступна на шаге оплаты» сильнее, чем «плохая accessibility».
Что должен вынести QA из этой темы
Доступность проверяется через завершение пользовательского сценария. Важны семантика, фокус, текст, альтернативные способы управления и обратная связь. Автоматический аудит полезен как часть процесса, а успешный прогон одного маршрута не подтверждает соответствие всего приложения стандарту. Самый ценный результат QA — воспроизводимый барьер с понятным влиянием на пользователя.