Краткий ответ
Чек-лист доступности мобильного приложения должен охватывать ключевые пользовательские сценарии, порядок фокуса, названия и состояния элементов, контраст, масштабирование текста, жесты, анимацию и области касания. Одних автоматических проверок недостаточно: сборку нужно вручную пройти с экранным диктором, клавиатурой или переключателями. Выпуск допустим, только если критические действия выполняются без обходных путей, а исправления подтверждены повторной проверкой.
Что проверяет аудит и как подготовить испытание
Аудит доступности отвечает не на вопрос «соответствует ли экран правилам», а на вопрос «может ли человек самостоятельно получить обещанную бизнесом ценность». Поэтому сначала выбирают критические сценарии, устройства и ограничения пользователя, а уже затем проверяют отдельные элементы.
Начните с действий, потеря которых бьёт по выручке или обязательствам: регистрация, вход, поиск, оформление заказа, оплата, обращение в поддержку, управление подпиской. Для каждого сценария зафиксируйте исходное состояние, тестовые данные и ожидаемый результат. Если состав продукта ещё меняется, сначала определите MVP мобильного приложения: иначе команда потратит силы на второстепенные экраны, пока основной путь остаётся непроходимым.
- Подготовьте реальные устройства разных размеров и системные настройки крупного текста, повышенного контраста и уменьшения движения.
- Создайте тестовые учётные записи: новый пользователь, постоянный клиент, пользователь с ошибочным вводом и ограниченными правами.
- Проверьте сценарий при медленной загрузке, пустом результате, отказе разрешения и ошибке сервера — доступность ломается не только в счастливом пути.
- Назначьте владельца каждого сценария и заранее сформулируйте, какое наблюдаемое действие означает успешное прохождение.
Эмулятор и автоматический анализатор полезны для раннего отсечения дефектов, но не показывают, понятна ли озвученная последовательность живому человеку. Минимальный комплект перед выпуском — автоматическая проверка, ручное прохождение вспомогательными средствами и повторная приёмка исправлений. Практический вывод: тестовый план должен строиться вокруг задач пользователя, а не вокруг списка экранов.
Навигация без зрительного контроля и точного касания
Пользователь должен пройти приложение в логичном порядке, всегда понимать, где находится фокус, и активировать каждое значимое действие без сложного жеста. Видимая кнопка, которую пропускает экранный диктор или внешняя клавиатура, фактически не существует.
Проведите фокус от начала каждого экрана до конца. Он должен следовать смыслу: заголовок, пояснение, поле, ошибка, основное действие. После открытия окна фокус переносится внутрь него, после закрытия возвращается к вызвавшему элементу. При переходе на новый экран он не должен случайно попадать на нижнюю навигацию или скрытый объект. Отдельно проверьте возврат назад, длинные списки, вкладки, раскрывающиеся блоки и обновление содержимого.
- Все действия доступны последовательным перемещением фокуса с экранным диктором, внешней клавиатурой или переключателем.
- Фокус не зацикливается, не исчезает и не попадает на декоративные изображения, невидимые слои или отключённые элементы.
- Свайп, перетаскивание и долгое нажатие имеют понятную альтернативу: кнопку, меню или пошаговое действие.
- Автоматическая смена экрана не лишает пользователя контекста; при загрузке и обновлении сохраняется предсказуемая позиция.
- Кнопка возврата отменяет текущий уровень действия, а не неожиданно закрывает приложение или очищает введённые данные.
Проверяйте не только достижимость, но и стоимость пути: лишние остановки фокуса превращают короткую операцию в утомительный обход. Однако декоративные элементы не следует озвучивать лишь ради полноты — шум столь же вреден, как молчание. Следующее действие команды: записать прохождение каждого критического сценария и приложить к дефекту точное место, ожидаемый порядок и фактическое поведение.
Названия, роли и состояния элементов интерфейса
Экранный диктор должен сообщать, что это за элемент, что он делает и в каком состоянии находится. Подпись «кнопка» бесполезна, а озвучивание внутреннего имени компонента выдаёт устройство интерфейса вместо смысла действия.
Названия делайте короткими и различимыми вне визуального контекста: «Добавить адрес», а не несколько одинаковых «Добавить». Роль должна соответствовать поведению: кнопка запускает действие, переключатель имеет состояние, заголовок задаёт структуру, поле сообщает назначение и введённое значение. Изображения с функцией получают смысловую подпись, декоративные исключаются из фокуса. Не объединяйте всю карточку в длинный монолог, если внутри есть отдельные действия.
- Подсказка внутри поля не заменяет постоянную подпись и не исчезает как единственный источник смысла после ввода.
- Обязательность, ошибка и способ исправления передаются словами, а не только цветом, значком или расположением.
- Выбранное, раскрытое, отключённое, загруженное и выполняющееся состояние корректно объявляется при изменении.
- Временное уведомление озвучивается без захвата управления; важное сообщение остаётся доступным после исчезновения плашки.
- Код подтверждения, сумма, дата и другие чувствительные данные читаются в понятном порядке и не смешиваются с соседним текстом.
Не добавляйте в подпись тип элемента, если система уже произносит его сама: фраза «кнопка Оплатить, кнопка» раздражает и замедляет работу. Но краткость не должна скрывать последствия необратимого действия. После проверки составьте словарь повторяющихся компонентов и закрепите единые правила именования — так исправление переживёт следующий выпуск, а не растворится в отдельных экранах.
Чек-лист доступности мобильного приложения: зрение, движение и касание
Интерфейс должен сохранять смысл без различения цвета, выдерживать системное увеличение текста, не принуждать к просмотру движения и прощать неточное касание. Эти свойства проверяют на реальном содержимом, потому что короткие макетные подписи редко ломают макет — фамилии, адреса и ошибки ломают.
| Область | Как проверить | Условие допуска |
|---|---|---|
| Контраст и цвет | Просмотреть текст, значки, поля и состояния при разных настройках экрана | Смысл и границы элементов различимы без опоры только на цвет |
| Масштаб текста | Увеличить системный шрифт и пройти ключевой сценарий | Текст не обрезан, действия доступны, чтение не требует горизонтальной прокрутки |
| Движение | Включить уменьшение анимации и повторить переходы | Сценарий не зависит от эффекта, а автоматическое движение можно остановить |
| Касание | Выполнить действия одной рукой без высокой точности | Цели не перекрываются, ошибочное соседнее нажатие не становится нормой |
Проверьте светлую и тёмную темы, отключённые элементы, ошибки, выбранные вкладки, ссылки внутри текста и содержимое поверх изображений. При увеличении шрифта допускается перестройка макета, но не исчезновение цены, согласия или кнопки продолжения. Для жестов предусмотрите явные альтернативы, а опасные действия отделите от часто используемых. Анимация не должна быть единственным объяснением результата; системная настройка уменьшения движения должна учитываться.
Снимок одного идеального экрана не подтверждает доступность всего продукта. Проверяйте длинные переводы, динамические данные и появление клавиатуры. Практический вывод: дизайнер утверждает состояния, разработчик реализует адаптацию, а проверяющий принимает не соответствие макету, а сохранение функции при изменённых настройках.
В каталоге товаров название в две строки выглядит аккуратно, но после увеличения шрифта занимает больше места, вытесняет цену и перекрывает кнопку. Правильное решение не обязательно сохраняет прежнюю плотность: карточка может стать выше, вторичные сведения — перейти ниже, а основное действие — остаться доступным. Затем тот же экран проверяют с длинным названием, отсутствующим изображением и сообщением об ошибке. Для интерфейса с карточками полезен прототип мобильного приложения на реальном устройстве, но он подтверждает только проектное решение; окончательную приёмку проводят на рабочей сборке с данными и системными настройками.
Как оформить дефекты и принять решение о выпуске
Доступность становится управляемой, когда каждый дефект связан со сценарием, воспроизводится на указанном устройстве, имеет владельца и проверяемый критерий устранения. Решение о выпуске принимают по влиянию на задачу пользователя, а не по общему числу замечаний.
В карточке дефекта укажите сборку и устройство, системные настройки, вспомогательную технологию, начальное состояние, шаги, фактический и ожидаемый результат. Приложите запись экрана или голосового вывода, но не заменяйте ею описание. Критичность повышается, если пользователь не может войти, оплатить, подтвердить согласие, получить важное сообщение или выйти из тупика. Косметическое несовершенство без потери смысла рассматривается отдельно.
| Класс проблемы | Решение | Подтверждение |
|---|---|---|
| Блокирует ключевой сценарий | Выпуск не допускается до исправления | Повторное полное прохождение сценария |
| Есть доступный обходной путь | Решение принимает владелец продукта с зафиксированным риском и сроком | Проверка обходного пути и задачи на исправление |
| Не мешает выполнению задачи | Можно включить в план улучшений | Снимок состояния и однозначный критерий приёмки |
Закрывать задачу по комментарию разработчика нельзя: изменение подтверждает независимая повторная проверка на той же конфигурации, затем короткая регрессия соседних сценариев. Результаты включите в общую поддержку мобильного приложения после запуска, поскольку обновление библиотеки, новый экран или изменённый серверный ответ могут вернуть дефект. Полезное правило для выпуска: неизвестный результат проверки не равен успешному.
Рабочий пример: проверка обнаружила, что после неверного кода подтверждения экранный диктор не сообщает ошибку, фокус остаётся на кнопке, а повторный ввод невозможно быстро найти. Владелец продукта помечает дефект как блокирующий вход, разработчик связывает сообщение с полем и управляет фокусом, проверяющий повторяет весь путь — от получения кода до успешного входа — и сохраняет доказательство. Даже если остальные экраны безупречны, средняя оценка здесь бессмысленна: пользователь всё равно не попадёт в сервис. После такого решения чек-лист превращается из документа «для галочки» в реальный выпускной шлюз.
Заложите доступность до приёмки
Большинство дорогих исправлений возникает не потому, что доступность сложна сама по себе, а потому, что о ней вспоминают после утверждения компонентов и сценариев. Требования к фокусу, состояниям, масштабированию и альтернативным действиям лучше включить в состав функций и критерии готовности ещё при планировании.
Если вы определяете объём продукта, выбираете подход к разработке и готовите реалистичные требования, разберите весь путь создания приложения — от идеи и MVP до выпуска. Так чек-лист доступности станет частью проекта, а не аварийной работой перед публикацией.
Часто задаваемые вопросы
Что такое доступность мобильного приложения?
Это способность людей с разными особенностями зрения, слуха, моторики и восприятия самостоятельно пользоваться приложением и завершать основные задачи.
Достаточно ли автоматической проверки доступности?
Нет. Она находит часть технических дефектов, но не оценивает понятность озвучивания, логичность фокуса и проходимость полного пользовательского сценария.
Какие сценарии проверять в первую очередь?
Регистрацию, вход, покупку или заявку, оплату, восстановление доступа, поддержку и управление подпиской — то есть действия, от которых зависит ценность сервиса.
Как проверить приложение без зрительного контроля?
Включить системный экранный диктор, убрать визуальную опору и последовательно пройти сценарий жестами фокуса, слушая названия, роли, состояния и сообщения.
Когда дефект доступности должен остановить выпуск?
Когда он блокирует критический сценарий, скрывает важную информацию, не имеет доступного обходного пути или создаёт риск ошибочного необратимого действия.
Нужно ли тестировать и Android, и iOS?
Да, если обе платформы входят в выпуск. Одинаковый интерфейс может по-разному взаимодействовать с системными дикторами, фокусом и настройками текста.
Кто отвечает за доступность приложения?
Владелец продукта задаёт критерии допуска, дизайнер проектирует состояния, разработчик реализует семантику, а специалист по качеству проверяет сценарии и исправления.
Нужно ли повторять аудит после запуска?
Да. Новые функции, обновления компонентов, изменения содержимого и серверных ответов способны вернуть ранее устранённые препятствия.
Продуктовый дизайнер в Scrile. Фокусируется на пользовательской ценности и бизнес-результатах. Пишет про интерфейсные решения, экономику design-system и где UX-инвестиции реально окупаются.