Ручное тестирование мобильных приложений
Тестирование доступности мобильных приложений
Нативные iOS и Android, React Native и Flutter — на живых устройствах со скринридерами, а не в эмуляторе. Стандарт — раздел 11 «Программное обеспечение» EN 301 549.
Отвечаем в рабочие часы
Приложения названы в законе прямо
Это не «желательно». Четыре документа упоминают мобильные приложения отдельной строкой.
European Accessibility Act
Директива (ЕС) 2019/882 действует с 28 июня 2025 года. Охватывает приложения банков, e-commerce, транспорта, электронных книг и связи.
BFSG · Германия
Национальная имплементация EAA с той же датой. Для немецкого рынка это основной документ, по которому спрашивают приложение.
Постановление КМУ №895
Пункт 7 обязывает поставщиков универсальных электронных коммуникационных услуг обеспечить доступность и сайтов, и мобильных приложений. Действует с 15.07.2028.
ДСТУ EN 301 549:2022
Технический стандарт, на который ссылаются и европейские, и украинские требования. Для приложений работает раздел 11, а не раздел 9.
Раздел 11 — это не тот же чек-лист, что для сайта
Веб-страницу EN 301 549 проверяет по разделу 9, который ссылается на WCAG. Нативное приложение — по разделу 11 «Программное обеспечение»: там свои требования к именам и ролям элементов, фокусу, жестам и системным настройкам. Аудит сайта этого не покрывает, даже если приложение показывает те же данные.
Для приложений автоматики почти нет
Для веба автоматика зрелая: наш Аудит ежедневно проходит сайт по 90+ правилам. Для нативных приложений инструментов такого уровня нет. Accessibility Scanner на Android и Accessibility Inspector в Xcode ловят базовое: отсутствующие подписи, малые цели касания, слабый контраст. Порядок фокуса, логику жестов, озвучивание состояний и поведение при системном увеличении шрифта они не видят.
Поэтому всё ключевое проходится руками
Тестировщик проходит каждый пользовательский путь на живом устройстве с включённым скринридером — регистрацию, оплату, изменение настроек. Именно так находятся экраны, из которых невозможно выйти, кнопки без имени, модальные окна, не забирающие фокус, и формы, ошибки которых никто не озвучивает.
Обе платформы, реальные устройства
Эмулятор не воспроизводит ни скринридер, ни системные настройки доступности
iOS
Ключевые сценарии с VoiceOver на физическом iPhone: порядок фокуса, жесты ротора, подписи и роли элементов, работа с Dynamic Type и Voice Control, поведение со Switch Control.
Android
То же с TalkBack на устройствах разных поколений и версий системы: озвучивание, порядок обхода, Switch Access, поведение после изменения размера шрифта и масштаба экрана.
React Native, Flutter и нативный код
Кросс-платформенные приложения тестируем как нативные — со стороны пользователя разницы нет. В отчёте указываем, на каком уровне лежит проблема: в вашем коде, в компоненте фреймворка или в настройках сборки.
Что именно проверяем
Восемь направлений, каждое — на обеих платформах
Скринридер и порядок фокуса
Каждый экран проходим на слух: есть ли у всех элементов имена и роли, логичен ли порядок обхода, не теряется ли фокус в модальных окнах и есть ли из них выход.
Цели касания и жесты
Минимум 44×44 pt на iOS и 48×48 dp на Android, достаточные отступы между соседними элементами, альтернатива сложным жестам — свайпу, долгому нажатию, перетаскиванию.
Масштабирование текста
Dynamic Type на iOS и системный размер шрифта на Android до максимальных значений: без обрезания, наложения и кнопок, уехавших за пределы экрана.
Контраст и темы
Светлая и тёмная темы, режим высокого контраста, инверсия цветов, читабельность текста поверх изображений и видео.
Ориентация и движение
Работа в портрете и ландшафте без потери контента, уважение к системному Reduce Motion, отсутствие автоматической анимации, которую нельзя остановить.
Формы и ошибки
Подписи полей, подсказки, тип клавиатуры, озвучивание ошибок, возможность исправить введённое без потери уже заполненного.
Медиа и таймауты
Субтитры в видео, управление воспроизведением, автостарт звука, а также все места, где приложение ограничивает время на действие — код из SMS, сессия, корзина.
Системные настройки
Уважает ли приложение то, что человек уже настроил в телефоне: жирный текст, уменьшенную прозрачность, отключённую анимацию, увеличенный курсор, внешнюю клавиатуру.
Что вы получаете
- Отчёт о найденных проблемах с привязкой к разделу 11 EN 301 549 и к критериям WCAG, по критичности и с оценкой сложности исправления
- Видеозаписи экрана с включённым скринридером — видно и слышно, что именно ломается, так что разработчику не надо воспроизводить баг вслепую
- План действий с приоритетами: что исправить до релиза, что в следующем спринте, что требует изменения архитектуры навигации
- Повторная проверка критических проблем после ваших исправлений
Стоимость
Считаем по брифу
Цена зависит от количества экранов, платформ и того, нужны ли сессии с реальными пользователями. Пришлите приложение или опишите его — вернёмся с расчётом и сроками.
Отправить брифНужен ещё и сайт? Ручное тестирование веб-сайтов
Частые вопросы
Можно ли протестировать приложение автоматически, как сайт?
Частично. Accessibility Scanner на Android и Accessibility Inspector в Xcode находят отсутствующие подписи, малые цели касания и слабый контраст. Но для нативных приложений нет ничего уровня веб-сканеров: порядок фокуса, логику жестов, озвучивание состояний и поведение при увеличенном шрифте приходится проходить руками на устройстве.
Подходит ли это для React Native и Flutter?
Да. Со стороны пользователя разницы нет — скринридер работает с тем, что отдаёт платформа. В отчёте мы отдельно указываем, где лежит причина: в вашем коде, в компоненте фреймворка или в настройках сборки, потому что исправления в этих случаях разные.
Какой стандарт применяется к приложениям?
EN 301 549, раздел 11 «Программное обеспечение». Это важно: веб-страницы проверяют по разделу 9, который ссылается на WCAG, а приложения — по разделу 11 с собственными требованиями к именам, ролям, фокусу и системным настройкам. Аудит сайта не покрывает приложение, даже если в них одинаковые данные.
На каких устройствах вы тестируете?
На физических. Эмулятор не воспроизводит ни скринридер, ни системные настройки доступности, ни реальные жесты. Берём несколько поколений устройств и версий системы, потому что поведение TalkBack и VoiceOver между версиями отличается.
Нужен ли нам ещё и аудит сайта?
Если у вас есть и сайт, и приложение — да, это две отдельные проверки по разным разделам стандарта. Сайт закрывает автоматический Аудит плюс ручное тестирование; приложение — только ручное. Заказывать их одновременно дешевле, чем по отдельности, потому что часть подготовки общая.
Расскажите о приложении
Вернёмся в рабочие часы с расчётом, сроками и перечнем того, что проверим.
Отправить брифБриф → предложение со сроками и стоимостью