Доступный адаптивный веб-сайт — это не то же самое, что доступное приложение, хотя оба «работают на телефоне». В этой статье объясняются критические различия между обеспечением доступности веб-сайта и обеспечением доступности собственного приложения для iOS или Android.
Короче — о чем эта статья
Разные технологии, схожие правила
Адаптивный веб-сайт создается на основе HTML, который уже имеет встроенный уровень доступности (семантические теги, ARIA), который браузеры и программы чтения с экрана умеют интерпретировать. Нативное приложение, напротив, создается на основе собственных компонентов пользовательского интерфейса операционной системы (UIKit/SwiftUI на iOS, Jetpack Compose/Views на Android) — и каждому компоненту требуется собственный тег доступности, отдельный от его визуального дизайна. Базовые принципы напоминают WCAG (контраст, сенсорный размер, понятное доступное название), но инструменты для их реализации совершенно другие.
VoiceOver и TalkBack: разные программы чтения с экрана
VoiceOver (iOS) и TalkBack (Android) — это две разные программы чтения с экрана, с разными жестами навигации и разной поддержкой пользовательских компонентов. Компонент, который идеально тегирован на iOS, может некорректно работать на Android, если разработчики не протестировали обе платформы по отдельности. Вы не можете считать, что «мы тестировали это на iOS, значит, оно должно работать и на Android».
💡 Важный момент
На обеих платформах каждому интерактивному компоненту (кнопке, полю ввода, изображению) необходимы: четкая метка доступности, определенная роль/характеристика доступности, а иногда также подсказка доступности, объясняющая, что происходит при нажатии на нее.
Что уникального в нативных приложениях
Нативные приложения также сталкиваются с проблемами, которых нет на веб-сайтах: пользовательские сенсорные жесты (смахивание, сведение пальцем), которым нужна доступная альтернатива; навигация между экранами, которая также должна иметь смысл с помощью программы чтения с экрана; и push-уведомления, которые должны быть доступны, даже если они появляются за пределами самого приложения. Кроме того, размеры сенсорных целей должны соответствовать минимуму 44x44 пикселей согласно рекомендациям Apple и 48x48dp согласно рекомендациям Google — требование, которое не всегда существует в одинаковой форме на веб-сайтах.
Как протестировать доступное приложение
- Включите VoiceOver или TalkBack и попробуйте выполнить основные задачи приложения (регистрация, покупка, поиск), используя только их.
- Проверьте контрастность и размер текста с включенными настройками специальных возможностей системы (крупный текст, высокая контрастность).
- Подтвердите поддержку динамического изменения размера текста (Динамический тип на iOS) без «ломки» макета.
- Тестируйте на обеих платформах отдельно — протестировать только один недостаточно.
Есть ли у вас документы, сопровождающие ваше приложение?
Наш инструмент сканирует PDF-файлы, связанные с вашим приложением или веб-сайтом — условия использования, руководства, формы — и показывает, какие именно из них требуют внимания.
Сканируйте ваш сайт бесплатно ←После сканирования вы также можете сделать найденные документы доступными напрямую и бесплатно через AccessiDoc.