Аудит доступности мобильного приложения по WCAG

Аудит доступности мобильного приложения по WCAG

Мы проводим аудит доступности мобильных приложений по стандарту WCAG 2.1. Наши сертифицированные инженеры проверяют контрастность, текстовые альтернативы, навигацию со скринридерами и другие критерии. Закажите аудит под ключ — мы выявим все нарушения уровня A и AA и подготовим отчёт с примерами кода на Swift, Kotlin, Flutter или React Native. Свяжитесь с нами, чтобы оценить ваше приложение.

Почему аудит доступности критичен для вашего приложения?

Без аудита вы рискуете потерять до 15% пользователей с ограничениями, а также столкнуться с судебными исками (например, по ADA в США). WCAG 2.1 через WCAG2ICT применяется к мобильным приложениям. Уровни A и AA — минимальный порог для госзакупок и большинства требований. AA уровень покрывает в 3 раза больше сценариев использования для людей с нарушениями зрения и моторики, чем уровень A. Наш аудит гарантирует, что ваше приложение соответствует EN 301 549 и другим стандартам.

Какие проблемы выявляет аудит WCAG?

Мы обнаруживаем типичные проблемы: отсутствие accessibilityLabel на иконках, низкий контраст текста, неправильный порядок фокуса, невидимые для скринридеров ошибки форм и многое другое. Наш отчёт включает скриншоты каждого нарушения с приоритетом исправления. Пример: серый placeholder #9E9E9E на белом фоне даёт контраст 1.9:1 (требуется 4.5:1).

Что проверяем

Критерий 1.1 — Текстовые альтернативы — аудит доступности мобильного

Все нетекстовые элементы должны иметь текстовую альтернативу. На iOS — accessibilityLabel, на Android — contentDescription. Декоративные элементы помечаются как пропускаемые. Инструмент: Accessibility Inspector (Xcode) и Android Accessibility Scanner.

Критерий 1.3 — Адаптируемость

Структура не должна зависеть от визуального восприятия. Порядок чтения screen reader'а должен совпадать с логическим порядком. Для ConstraintLayout и ZStack порядок фокуса задаём явно.

Критерий 1.4 — Различимость

1.4.3 Контрастность (AA): минимум 4.5:1 для текста, 3:1 для крупного. Проверяем все элементы. 1.4.4 Изменение размера текста: поддержка Dynamic Type (iOS) и font scaling (Android). 1.4.10 Перекомпоновка: контент без горизонтальной прокрутки при масштабе до 400%. 1.4.11 Контраст для нетекстовых элементов: иконки, границы — 3:1.

Критерий 2.1 — Управление с клавиатуры

На мобильном — Switch Control и внешняя клавиатура. Все функции должны быть доступны без сенсорного экрана. Проверяем Tab-навигацию, Enter для активации, Escape для закрытия модалок.

Критерий 2.4 — Навигация

Фокус при открытии модального окна переходит на первый элемент, при закрытии — возвращается. Заголовки экранов структурируют страницу. Видимый фокус обязателен.

Критерий 3.3 — Помощь при вводе

Сообщения об ошибках должны быть связаны с полем через accessibilityHint или UIAccessibility.post(notification:). Только красный border невидим.

Формат аудита

Финальный отчёт содержит:

• Таблицу критериев WCAG с оценками Pass/Fail/N/A
• Скриншоты с описанием нарушений
• Приоритеты (блокирующие vs minor)
• Рекомендации с примерами кода

Пример таблицы:

Что входит в аудит?

В стоимость включено:

• Детальный отчёт с постраничным разбором
• Файл с примерами кода для iOS, Android, Flutter, React Native
• Приоритезация нарушений по критичности
• Консультация по исправлению через 1 неделю после отчёта
• Рекомендации по долгосрочной поддержке доступности

Сравнение уровней A и AA

Уровень A — минимальные требования (25 критериев). Уровень AA добавляет ещё 21 критерий, включая контраст 4.5:1 и субтитры. На практике большинство клиентов выбирают AA, так как он покрывает основные потребности пользователей и соответствует законодательству.

Как мы проводим аудит?

1. Подготовка: изучаем ваше приложение, собираем сценарии использования
2. Автоматизированная проверка: запускаем Accessibility Scanner и Lighthouse
3. Ручное тестирование: 3–5 сценариев на физических устройствах
4. Составление отчёта: документируем каждое нарушение
5. Финальная консультация: обсуждаем план исправлений

Наш опыт и гарантии

За 5 лет работы мы проверили более 100 мобильных приложений на доступность. Наши инженеры сертифицированы IAAP (International Association of Accessibility Professionals). Мы гарантируем, что после исправления по нашему отчёту ваше приложение пройдёт повторный аудит с результатом Pass по выбранному уровню.

Срок аудита: от 2 до 5 дней в зависимости от масштаба. Свяжитесь с нами для точной оценки и заказа.

WCAG

Доступность мобильных приложений: VoiceOver, TalkBack и WCAG на практике

Приложение отклонили в App Store по гайдлайну 1.1, или пришёл запрос от корпоративного клиента с требованием WCAG 2.1 AA — обе ситуации означают одно: accessibility не был заложен в архитектуру с самого начала, а теперь его нужно встраивать в готовый продукт. Это больно.

Почему «добавить доступность потом» не работает

Самая частая проблема — разработчики воспринимают VoiceOver и TalkBack как косметику. Расставили accessibilityLabel, запустили Screen Reader и удивились, почему фокус прыгает с кнопки «Купить» на декоративную иконку в углу.

На iOS ошибка живёт в неправильной группировке элементов. Если UIStackView содержит иконку + текст + цену, VoiceOver будет читать их как три отдельных элемента вместо одного. Решение — isAccessibilityElement = false на контейнере + accessibilityElements с нужным порядком, либо shouldGroupAccessibilityChildren = true. Кажется мелочью, но именно это делает разницу между «формально работает» и «слепой пользователь может купить товар за 30 секунд».

На Android ситуация зеркальная: contentDescription ставят везде, включая ImageView, которые несут только декоративную функцию. TalkBack начинает зачитывать «иконка стрелка» между каждым значимым элементом. Правильно — android:importantForAccessibility="no" для декора и явные contentDescription только там, где это несёт смысл.

Dynamic Type и масштабирование шрифтов

iOS Dynamic Type ломает верстку предсказуемо: фиксированные высоты строк в UILabel, захардкоженные frame в Auto Layout, numberOfLines = 1 без adjustsFontSizeToFitWidth. Когда пользователь ставит размер шрифта XXL в настройках, текст обрезается или перекрывает соседние элементы.

Правильная реализация использует .font = UIFont.preferredFont(forTextStyle: .body) с adjustsFontForContentSizeCategory = true и numberOfLines = 0 везде, где контент динамический. В SwiftUI это работает из коробки через .dynamicTypeSize() modifier.

На стороне Flutter эквивалент — textScaleFactor через MediaQuery. Компоненты Material 3 поддерживают масштабирование нативно, но кастомные виджеты требуют явного учёта.

WCAG 2.1 в мобильном контексте

Мобильные приложения формально не обязаны следовать WCAG (он писался для веба), но WCAG 2.1 + дополнения WCAG для мобильных стали де-факто стандартом при корпоративных тендерах и госзакупках.

Критичные критерии применительно к мобилу:

• 1.4.3 Contrast Minimum — соотношение контраста текста к фону минимум 4.5:1. Проверяем через Xcode Accessibility Inspector или Android Studio Layout Inspector
• 2.4.7 Focus Visible — при работе с внешней клавиатурой на iPad/Android планшете фокус должен быть виден. Часто забытый сценарий
• 2.5.8 Target Size (AA) — минимум 24x24dp для интерактивных элементов, рекомендуется 44pt/48dp
• 4.1.3 Status Messages — уведомления об ошибках форм должны озвучиваться через UIAccessibility.post(notification: .announcement) или AccessibilityNodeInfo.RoleDescription на Android

Как строим процесс

Аудит начинается с Accessibility Inspector в Xcode и TalkBack developer settings на Android — проходим все экраны со Screen Reader включённым и фиксируем каждый случай, когда требуется более 3 действий для выполнения целевой операции.

Дальше — автоматизированные проверки. XCUITest поддерживает accessibility assertions; для Android используем Accessibility Test Framework (ATF), который встроен в Espresso. Это ловит регрессии на CI.

Финальный этап — тестирование с реальными пользователями, использующими вспомогательные технологии. Никакой автоматизацией это не заменить.

Сроки

Аудит и базовое исправление существующего приложения — от 2 до 5 недель в зависимости от числа экранов и глубины проблем. Внедрение accessibility с нуля в новый проект практически не влияет на сроки при правильном дизайне компонентной системы — закладываем 10-15% overhead на разработку UI-слоя.