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

Интерфейс может выглядеть аккуратно при стандартном размере шрифта и при этом быть неудобным в реальной ситуации. Если при увеличенном тексте исчезает основная кнопка, скринридер называет иконку просто «кнопкой», а ошибка обозначена только красной рамкой, пользователь вынужден угадывать или прекращать действие. Поэтому требования доступности стоит фиксировать до того, как разработка закрепит структуру экранов. В рамках услуги POLADO UI/UX и продуктовый дизайн это можно заложить в пользовательские потоки, правила компонентов и критерии приёмки одновременно с визуальной концепцией.

Оценивайте завершение задачи, а не отдельные пункты чек-листа

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

  1. понять следующий шаг;
  2. найти нужный элемент управления;
  3. безошибочно активировать его;
  4. понять, что изменилось после действия;
  5. исправить ошибку без потери данных;
  6. получить ясное подтверждение результата.

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

Проектируйте поведение интерфейса при увеличении текста

В iOS пользователь может включить Dynamic Type, а в Android — системное масштабирование шрифта. Это обычные настройки устройства, а не редкий крайний случай. Макет в Figma при стандартном размере не подтверждает, что экран работает при крупном тексте: заголовки, цены, статусы, сообщения об ошибках и подписи кнопок начинают занимать больше места.

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

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

Цель не в том, чтобы уместить максимум элементов на первом экране. Цель — сохранить возможность читать, сравнивать и действовать, не заставляя человека менять собственные настройки. Apple рекомендует проверять, что при увеличенных размерах текста интерфейс перестраивается без наложений и обрезки.

Контраст, сигналы не только цветом и удобные зоны касания

Доступный цвет — это не только «правильная» главная кнопка. Текст должен достаточно выделяться на своём фоне; распространённый базовый ориентир — 4.5:1 для обычного текста и 3:1 для крупного. Иконки, границы полей, выбранные состояния и другие нетекстовые элементы также должны быть различимы: 3:1 — практический минимум для таких элементов. Проверяйте светлую и тёмную темы, disabled-состояния, оверлеи и текст на изображениях.

Не передавайте смысл только цветом. Красная обводка поля — не полноценная ошибка. Добавьте конкретное сообщение, например «Введите номер карты из 16 цифр», заметный индикатор и объявление изменения статуса для вспомогательных технологий. Аналогично, зелёная линия на графике не должна быть единственным признаком положительной динамики.

Интерактивные области должны прощать неточность касания: дрожание руки, использование одной рукой, яркий свет и обычную ширину пальца. Android рекомендует область касания не менее 48dp × 48dp для каждого интерактивного элемента. WCAG 2.2 описывает минимальный размер цели либо достаточный отступ между маленькими целями. Визуально иконка может быть компактной, но её активная зона — нет. Для удаления, финансового подтверждения и других необратимых действий выбирайте ещё более крупную область и понятное подтверждение.

Задайте скринридеру имя, роль, состояние и порядок фокуса

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

  • Имя: «Открыть фильтры», «Поделиться счётом», «Выбранный тариф: Pro» понятны; «кнопка» и «изображение» — нет.
  • Роль: элемент отправки должен быть кнопкой, настройка — переключателем, выбранная вкладка должна сообщать о своём состоянии.
  • Значение и статус: озвучивайте количество, прогресс, развёрнутое/свёрнутое состояние, выбранные опции, недоступность и загрузку там, где это важно для задачи.
  • Порядок фокуса: он должен соответствовать логике чтения и выполнения задачи. Карточки с визуальной перестановкой элементов, липкий footer и кастомные модальные окна часто создают неправильную последовательность.
  • Декоративный контент: не включайте в цепочку фокуса иллюстрации и разделители, которые не несут информации.

Когда это возможно, выбирайте стандартные нативные элементы управления: они уже имеют привычную семантику и платформенное поведение. Если продукту нужен кастомный слайдер, карта, карточка со свайпом или нижняя панель, ещё на этапе дизайна опишите его имя, доступные действия, переход фокуса при открытии и способ закрытия. В Jetpack Compose порядок обхода при необходимости можно уточнять семантическими группами и индексами traversal.

Делайте формы исправимыми и давайте альтернативы жестам

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

Используйте язык продукта, а не технический язык сервера. Сообщение «Не удалось сохранить заявку. Проверьте номер телефона и повторите попытку» полезнее, чем «Validation error 400». В чувствительных сценариях важно отличать неверно заполненное поле от временной ошибки сервиса и сообщать, была ли операция обработана.

Сложный жест не должен быть единственным способом выполнить действие. Для drag-and-drop добавьте «Переместить выше» и «Переместить ниже»; удаление свайпом продублируйте заметным меню или кнопкой. Если встряхивание устройства запускает функцию, предложите экранный элемент управления. Учитывайте Reduce Motion: убирайте или упрощайте необязательную анимацию и не используйте движение как единственный сигнал изменения состояния.

Матрица mobile app UX testing на реальных устройствах

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

  1. На iOS пройдите ключевые задачи с максимальным размером доступного текста, Increase Contrast, Bold Text и Reduce Motion.
  2. На физическом iPhone включите VoiceOver и завершите поток без опоры на экран; при релевантности продукту проверьте также Voice Control или Switch Control.
  3. На Android проверьте крупный шрифт, TalkBack, светлую и тёмную темы, а при необходимости Switch Access.
  4. Используйте Accessibility Inspector и Android Accessibility Scanner для раннего обнаружения обрезанного текста, пропущенных подписей, контраста и слишком малых целей касания.
  5. Добавляйте автоматические проверки доступности в UI-тесты там, где это поддерживает стек, но не подменяйте ими ручное тестирование сценария.
  6. Фиксируйте дефект с точной задачей, устройством, системной настройкой, ожидаемым и фактическим результатом, а также влиянием на путь пользователя.

Работа идёт быстрее и надёжнее, когда дизайн и разработка принимают эти решения вместе. Если вы планируете нативное приложение или меняете важный сценарий, объедините доступный продуктовый дизайн с услугой разработки мобильных приложений до того, как технические решения станут дорогими для пересмотра. Посмотрите проект POLADO Car City или свяжитесь с POLADO, чтобы обсудить аудит доступности и проектирование вашего мобильного продукта.