В 2026 году доступность (accessibility) перестала быть опциональной для команд iOS-разработки. European Accessibility Act действует с 28 июня 2025 года, в США в 2024-м количество исков по ADA против веб- и мобильных продуктов перевалило за 4 000 и продолжает расти, а Apple за последние десять лет выпустила полный набор нативных API (VoiceOver, Dynamic Type, Voice Control, Switch Control, Accessibility Nutrition Labels в iOS 18/19), благодаря которым разрыв между приложением, соответствующим требованиям, и приложением, грубо их нарушающим, закрывается за несколько недель сфокусированной инженерной работы. Этот гайд — рабочий плейбук, который мы применяем при запуске iOS-продуктов: семь столпов доступности, которые действительно нужно закрывать, конкретные Swift API и инструменты Xcode по каждому из них, оценочная матрица по WCAG 2.2 AA и EN 301 549, фреймворк выбора между ретрофитом и переписыванием, цикл аудита для поддержания соответствия и пять подводных камней, которые тихо топят проекты. Все рекомендации проверены в продакшене iOS-приложений, которые наша команда выпускала для клиентов в США, ЕС и на Ближнем Востоке.
КЛЮЧЕВЫЕ ВЫВОДЫ
- Рынок — это 1,3 млрд человек и 90 трлн ₽ располагаемого дохода в США. Откладывать доступность на пост-релизный спринт — это потеря выручки, а не только этический промах.
- EAA уже работает на принуждение. Цифровые B2C-продукты, продаваемые в ЕС, должны соответствовать EN 301 549 / WCAG 2.2 AA с 28 июня 2025 года. Несоответствие грозит штрафами до 1 млн € и запретом продаж в ряде стран-членов.
- Семь столпов закрывают 95% проблем: VoiceOver и семантические метки, Dynamic Type и адаптивная вёрстка, цвет и контраст, движение и тактильная отдача, Voice Control и Switch Control, субтитры и аудиоописания, формы и обработка ошибок.
- Аудит стоит 0,5–2% бюджета разработки, если делать его рано, и 10–20% — если как ретрофит. Это соотношение не меняется уже пять лет: чем раньше начнёте, тем дешевле останется.
- Accessibility Nutrition Labels в iOS 18 теперь показываются прямо на странице App Store: это маркетинговый актив для приложений, прошедших проверку, и красный флаг для конкурентов, которые её пропускают.
- Автоматизация ловит ~30% проблем; остальное — только реальные пользователи. Сочетайте Xcode Accessibility Inspector и Accessibility Audit с пользовательским тестом со слабовидящим пользователем в каждом крупном релизе.
Почему Фора Софт можно доверить доступность на iOS
Фора Софт выпускает iOS-приложения с 2008 года — 17 лет Swift, SwiftUI и протестированных с VoiceOver продакшен-релизов для клиентов из health-tech, e-learning, видеостриминга и финтеха в США, ЕС, Великобритании и на Ближнем Востоке. Мы проводим ревью доступности как обязательный гейт на каждом релизе, а не раз в квартал постфактум. Со стороны мультимедиа наша платформа BrainCert обеспечила более 500 миллионов минут живых уроков и видеосессий, поэтому у нас есть продакшен-данные о задержке субтитров, взаимодействии VoiceOver с поверхностями WebRTC и работе Dynamic Type на всём длинном хвосте моделей iPhone. Мы входим в Clutch Top 1000 Global и в топ-3 по рейтингу Clutch в категории разработки видеосервисов. Плейбук ниже — это тот же материал, с которым мы работаем со своими клиентами в 2026-м, а не пересказ сессий WWDC.
Нужен аудит доступности уже выпущенного iOS-приложения?
Наша команда проведёт аудит по WCAG 2.2 AA / EN 301 549, подготовит готовый к работе бэклог в Jira и оценит объём доработок.
Ландшафт доступности iOS в 2026 году — кратко
За последние два года три сдвига заметно перекроили доступность на iOS. Первый — регулирование догнало реальность: European Accessibility Act действует с 28 июня 2025 года и охватывает e-commerce, банкинг, транспорт, электронные книги и большинство B2C-цифровых сервисов, включая мобильные приложения. Иски по ADA против недоступных цифровых продуктов в США в 2024 году перешагнули отметку в 4 000 (по данным Seyfarth ADA Title III Tracker), и в 2026-м ожидается такой же или ещё больший показатель. Канадский ACA, австралийский DDA и британский Equality Act теперь все ссылаются на WCAG 2.2 AA как на практический ориентир.
Второй сдвиг — Apple существенно расширила поверхность доступности. В iOS 17 появились Personal Voice, Assistive Access и Point and Speak; в iOS 18 — Eye Tracking, Music Haptics, Vocal Shortcuts и Accessibility Nutrition Label, которая теперь показывается на каждой странице App Store. SwiftUI обзавёлся первоклассными traits доступности, ротором, кастомными actions и тройкой модификаторов `.accessibilityLabel`, `.accessibilityHint`, `.accessibilityValue`. В UIKit к протоколу `UIAccessibility` добавили управление фокусом и API анонсов — то, чего годами не хватало.
Третий — инструменты аудита стали реально пригодными. В Xcode встроен Accessibility Inspector с аудитами; Accessibility Audit в XCUITest позволяет гонять автоматические проверки в CI; сторонние вендоры — Deque axe DevTools Mobile, Evinced, Assistiv Labs — встают в те же пайплайны. Правило большого пальца на 2026 год: автоматизировать 30% проверок, держать в команде тестирования оплачиваемого пользователя с экранным диктором и идти в релиз.
Столп 1. VoiceOver и семантические метки
VoiceOver — самая важная поверхность доступности на iOS: именно через него работают с приложением незрячие и слабовидящие пользователи. У каждого элемента, который видит зрячий пользователь, должна быть программная метка, trait и (если есть состояние) value. В UIKit это `accessibilityLabel`, `accessibilityTraits` и `accessibilityValue`; в SwiftUI — модификаторы `.accessibilityLabel()`, `.accessibilityAddTraits()` и `.accessibilityValue()`. Кастомная отрисовка в Canvas или Core Graphics требует `.accessibilityElement(children: .combine)` или собственного `UIAccessibilityElement`.
Подводные камни 2026 года: SwiftUI внутри `LazyVStack` и `ScrollView` склеивает метки непредсказуемо, поэтому явная композиция меток всегда выигрывает у неявной. Кастомные роторы (`accessibilityRotor`) резко повышают удобство в плотных лентах — добавляйте их для основного типа контента (сообщения, товары, посты). Экраны с живыми обновлениями нуждаются в `UIAccessibility.post(notification: .announcement, argument:)` или `.accessibilityAnnouncement()`, чтобы VoiceOver сообщил пользователю об изменении.
Что внедрять: семантические метки на каждый интерактивный элемент, роторы для длинных списков, живые анонсы при асинхронных изменениях состояния, управление фокусом при показе модальных окон. Закладывайте 2–4 недели на типовое iOS-приложение среднего размера, чтобы выйти на паритет по VoiceOver.
Делайте дизайн «VoiceOver в первую очередь», когда у приложения высокая сложность (ленты, чаты, дашборды, e-commerce). Любое iOS-приложение должно выходить с паритетом по VoiceOver, но чем богаче интерфейс, тем больше времени на дизайн вы экономите на этапе разработки.
Запускайте аудит «VoiceOver в первую очередь», когда: выпускаете любое потребительское iOS-приложение в ЕС или США после вступления EAA в силу — пустые или общие значения accessibilityLabel на интерактивных контролах остаются самой частой причиной провала аудита экранного диктора.
Столп 2. Dynamic Type и адаптивная вёрстка
Dynamic Type позволяет пользователю задать системный размер контента — от Extra Small до AX5 (максимальный accessibility-размер). Приложения с захардкоженными размерами шрифтов катастрофически ломаются на AX3+, и примерно 30% пользователей iOS поднимают размер текста хотя бы на одну ступень выше дефолта. В SwiftUI используйте `.font(.body)`, `.font(.title)` и другие системные стили; в UIKit — `UIFontMetrics(forTextStyle:).scaledFont(for:)`. Избегайте `UIFont.systemFont(ofSize:)` для всего, что видит пользователь.
Вёрстка должна растягиваться. Автоматическая раскладка SwiftUI справляется с большинством случаев, но кастомные `HStack` с детьми фиксированного размера будут обрезать или клипать контент на AX-размерах — используйте `ViewThatFits`, протокол `Layout` или явные `@ScaledMetric`-свойства. В UIKit Auto Layout с `.systemLayoutSizeFitting(_:)` и приоритетами content-hugging / compression-resistance закрывает 90% проблем Dynamic Type. Тестируйте на AX5 на самом маленьком целевом устройстве (iPhone SE 3rd gen и до моделей 2026 года): если там выжило — выживет везде.
Что внедрять: модификаторы `.dynamicTypeSize`, где вы ограничиваете верхнюю планку (только для брендовых поверхностей), масштабируемые изображения через `@ScaledMetric`, гибкие контейнеры для всего текста. Закладывайте 1–2 недели на ретрофит.
Делайте Dynamic Type приоритетом, когда ваша аудитория — это старшая возрастная группа, health-tech, контент, насыщенный текстом, или любой B2C-рынок в ЕС (EAA это требует).
Столп 3. Цвет, контраст и режимы повышенного контраста
WCAG 2.2 AA требует контраст 4,5:1 для обычного текста и 3:1 для крупного текста и UI-элементов. Уважайте `UIAccessibility.isDarkerSystemColorsEnabled` (iOS «Увеличение контраста») и `.accessibilityContrast(.increased)` в SwiftUI. Никогда не передавайте состояние (ошибка, статус, выбор) только цветом — сочетайте цвет с иконкой, подписью или формой. Accessibility Inspector в Xcode 16 теперь сам подсвечивает текст с низким контрастом.
Каталоги цветовых ассетов с вариантами `Any / Dark / High Contrast` позволяют задать четыре состояния на каждый цвет без единой строки рантайм-кода. SwiftUI `Color` и UIKit `UIColor(named:)` сами подберут нужный вариант по trait collection. Для графиков и визуализации данных используйте различимые формы и паттерны в дополнение к цвету (WCAG 1.4.1).
Что внедрять: прошедшая аудит контраста цветовая палитра, варианты для повышенного контраста в Assets.xcassets, индикаторы состояния помимо цвета. Закладывайте около недели на ретрофит, если в дизайн-системе уже есть токены.
Используйте режим высокого контраста, когда у приложения есть сценарии на улице или в движении (доставка, такси, полевые сотрудники) или когда аудитория смещена в сторону 50+. Просмотр на ярком солнце и возрастное слабое зрение — самые заметные драйверы роста использования контрастных режимов.
Запускайте автоматический прогон по контрасту, когда: в дизайн-системе больше 20 токенов или есть и светлая, и тёмная темы — ручные точечные проверки пропускают пороги 3:1 для UI-элементов и 7:1 для AAA в 40% реальных приложений.
Столп 4. Движение, тактильная отдача и вестибулярная безопасность
Сильное движение (параллакс, перелистывание страниц, полноэкранные зумы, автозапуск видео) у части пользователей провоцирует симптомы вестибулярных нарушений. Уважайте `UIAccessibility.isReduceMotionEnabled` (в SwiftUI — `.accessibilityReduceMotion`): меняйте длинные анимации на cross-fade, отключайте параллакс и учитывайте аналог `prefers-reduced-motion` для контента в WebView. Автозапуск видео в ленте: по умолчанию пауза или уважение режима экономии заряда и Reduce Motion.
Тактильная отдача — это канал доступности, а не украшение. `UIImpactFeedbackGenerator` и `UISelectionFeedbackGenerator` дают невизуальный сигнал об изменении состояния. API Music Haptics и track haptics в iOS 18 расширяют это направление. Воспринимайте `UIAccessibility.isReduceMotionEnabled` и `UIAccessibility.shouldDifferentiateWithoutColor` как слои: например, на критическом изменении состояния сочетайте смену цвета, тактильный отклик и анонс VoiceOver.
Что внедрять: переключатель длительности анимаций при включённом Reduce Motion, слой тактильной отдачи на критичных изменениях состояния, подавление автозапуска в режимах энергосбережения и сниженного движения. Закладывайте около недели.
Внедряйте безопасность движения и тактильную отдачу, когда у приложения много анимаций (онбординг, игры, AR, соцленты) или когда есть жалобы пользователей, похожие на вестибулярные симптомы.
Столп 5. Voice Control, Switch Control и моторная доступность
Voice Control позволяет управлять устройством и любым приложением голосом. Switch Control делает то же самое через внешнее оборудование для пользователей с ограниченной подвижностью. Ваше приложение работает с обоими, если у каждого активного элемента есть осмысленная метка и достаточный размер цели нажатия (минимум 44×44 пт, WCAG 2.2 AA). Vocal Shortcuts в iOS 18 позволяют пользователям задавать собственные голосовые команды, запускающие ваши shortcut-сценарии: продуманные App Intents теперь — реальный рычаг доступности.
Тестируйте с включённым AssistiveTouch. Имитируйте пользователя Switch Control, проходя весь сценарий только виртуальным указателем Dwell Control. Самый частый промах в 2026 году — кастомные жесты (свайп для закрытия, длительное нажатие для меню, сложный drag-and-drop) без альтернатив на клавиатуре или голосе. Для каждого кастомного жеста нужна замена — кнопка, пункт меню или Accessibility Custom Action.
Что внедрять: цели нажатия 44×44 пт, `accessibilityCustomAction` на жестовых поверхностях, App Intents для критичных сценариев, отказ от фичей «только жестом». Закладывайте 1–2 недели.
Стремитесь к паритету по Voice / Switch Control, когда в приложении есть сложные жесты, drag-and-drop или свайп-навигация. Любое приложение со значимыми пользовательскими действиями должно поставлять App Intents для 3–5 самых ценных сценариев.
Тестируйте Voice / Switch Control, когда: в приложении больше 30 уникальных интерактивных экранов или есть сценарии длиннее 10 шагов — проблемы моторной доступности группируются в длинных сценариях и редко всплывают в пятиминутных точечных проверках VoiceOver.
Столп 6. Субтитры, аудиоописания и живая транскрипция
Если приложение проигрывает видео — ему нужны субтитры для зрителей с нарушениями слуха (closed captions, WCAG 1.2.2). Если это записанный контент, в котором аудио передаёт смысл, не отображённый на видео, ему нужны ещё и аудиоописания (WCAG 1.2.5). AVPlayer и AVFoundation отдают `AVMediaCharacteristic.legible` для субтитров и `.describesVideoForAccessibility` для аудиоописаний — используйте оба.
Для живого контента (видеозвонки, прямые трансляции, эфир) в iOS 16+ есть Live Captions на уровне системы, но это не замена встроенным субтитрам в медиа, которыми вы управляете. Apple Speech, OpenAI Whisper (на устройстве через WhisperKit), а также SDK AssemblyAI и Deepgram дают продакшен-уровень с задержкой меньше двух секунд и WER ниже 5% на английском. Для видеозвонков встраивайте субтитры в ту же иерархию view, что и видео, чтобы VoiceOver корректно их анонсировал.
Что внедрять: поддержку VTT/CEA-608-субтитров в AVPlayer, дорожки аудиоописаний для записанного видео, живую транскрипцию для любого голосового UX в реальном времени. Закладывайте 2–4 недели на интеграцию живой транскрипции.
Делайте субтитры, когда вы поставляете любое аудио или видео — точка. Делайте аудиоописания, когда сами владеете производством видео (стриминг, обучение, корпоративные ролики). Делайте живую транскрипцию для голосовых и видеозвонков.
Столп 7. Формы, ошибки и когнитивная нагрузка
На формах доступность ломается сильнее всего. У каждого поля ввода должна быть видимая подпись (не только placeholder), понятное состояние ошибки и программная связь между текстом ошибки и полем (WCAG 3.3.1). iOS 17+ даёт `.textContentType`, `.keyboardType`, `.autocorrectionDisabled` и системный автозаполнятор для адресов, банковских карт, одноразовых кодов и паролей — всё это снижает когнитивную нагрузку для всех и обязательно для пользователей с когнитивными нарушениями.
Валидируйте по событию blur, а не на каждое нажатие клавиши. Сообщайте об ошибках через `UIAccessibility.post(notification: .announcement, argument:)`. Не используйте CAPTCHA без доступной альтернативы (WCAG 1.1.1); Apple Private Access Tokens (PAT) и attestation в iOS 16+ во многом сняли её необходимость. Применяйте `accessibilityElement`-группировку, чтобы многострочный адрес VoiceOver отдавал как один элемент.
Что внедрять: видимые подписи у каждого поля, `textContentType` для автозаполнения, программную связь ошибки с полем, сгруппированные VoiceOver-элементы для составных вводов. Закладывайте около недели на каждую крупную форму.
Делайте формы по принципу accessibility-first, когда приложение включает регистрацию, оформление заказа, запись на приём или любой многошаговый процесс. Падение конверсии на формах — прямой путь, по которому проблемы доступности превращаются в потерю выручки.
Делайте ревью когнитивной нагрузки, когда: завершаемость онбординга ниже 60% или пользовательский уровень ошибок выше 2% — эти числа почти всегда упираются в UX-долг, смежный с доступностью, а не в чистые баги доступности.
Сравнительная матрица: 7 столпов доступности кратко
Фреймворк решения: ретрофит, переписать или отложить
Не каждому приложению нужен полный WCAG 2.2 AA с первого дня. Пользуйтесь такой лестницей:
Делайте ретрофит на месте, когда приложение уже на рынке, базовая архитектура здорова и аудит показал меньше ~50 проблем. Большинство приложений попадают сюда. Ожидаемые затраты: 4–8 недель разработки и 1 неделя дизайна.
Переписывайте ключевые поверхности, когда приложение собрано до iOS 14, использует тяжёлую кастомную отрисовку без элементов доступности или у вас больше 100 проблем аудита, сосредоточенных в 2–3 экранах. Обычно переписывают 20–30% UI, остальное идёт в ретрофит. Ожидаемые затраты: 8–16 недель.
Откладывайте (аккуратно), когда вы до Product-Market Fit, поставляете на один рынок B2B вне регулирования ЕС и у вас есть чёткий полугодовой план это закрыть. Каждый месяц отсрочки добавляет примерно неделю будущего ретрофита.
Никогда не откладывайте, когда вы продаёте потребителям в ЕС (EAA), госсектору США (Section 508), на любые медицинские рынки и в любые сегменты с большой долей пользователей вспомогательных технологий (образование, финансы, госуслуги).
Не уверены, в какую категорию вы попадаете?
Мы проведём 90-минутный аудит вашего рабочего iOS-приложения и пришлём письменное решение «ретрофит или переписать» с оценкой работ по каждому экрану.
Мини-кейс: как выглядит ретрофит доступности на практике
Один наш health-tech-клиент выпустил в 2023 году iOS-приложение для записи на приём, набрал ~150 тыс. MAU в США и начал выходить в ЕС в 2025-м. К моменту вступления EAA в силу сторонний аудит нашёл 72 проблемы по WCAG 2.2 AA — 26 по VoiceOver, 19 по Dynamic Type, 12 по контрасту, 8 по формам и ошибкам, 5 по движению, 2 по субтитрам. Мы провели шестинедельный спринт ремедиации: на 1–2-й неделях переработали модель VoiceOver в сценарии записи на приём с кастомными роторами и `accessibilityCustomAction`, на 3–4-й перевели типографику и вёрстку на Dynamic Type и `@ScaledMetric`, на 5-й перебалансировали палитру и выкатили варианты для повышенного контраста, на 6-й переработали обработку ошибок в формах и добавили App Intents для трёх ключевых сценариев. Послеремедиационный аудит: 4 остаточные проблемы, все косметические. Клиент выпустил релиз, соответствующий EAA, за две недели до дедлайна 28 июня 2025 года. Анекдотический эффект: ~18% рост завершаемости сессий у пользователей с увеличенным текстом >130% и заметное падение обращений в поддержку с формулировками «не вижу» и «не могу нажать».
Стек инструментов доступности iOS на 2026 год
В IDE: Accessibility Inspector в Xcode 16 (встроенный аудит, point-and-inspect, захват из симулятора), Accessibility Audit в XCUITest для CI, превью SwiftUI с `.accessibilityInspectorAudit()`, шаблон Accessibility в Instruments.
На устройстве: VoiceOver, Switch Control, Voice Control, ползунок Dynamic Type (Настройки → Универсальный доступ → Дисплей и размер текста), Reduce Motion, Increase Contrast, Button Shapes, Bold Text. Настройте «Тройное нажатие боковой кнопки» как Accessibility Shortcut для VoiceOver — QA сможет переключать его моментально.
Сторонние: Deque axe DevTools Mobile (генерирует исправленные SwiftUI-сниппеты), Evinced Mobile SDK, Assistiv Labs (удалённое тестирование с пользователями экранных дикторов), BrowserStack App Accessibility Testing, Appium и XCUITest с assert'ами доступности.
Со стороны дизайна: Stark (симулятор контраста и цветовой слепоты для Figma и Sketch), плагин Accessibility для Figma, Contrast Finder, проверка доступности Adobe Color. Встраивайте их на этапе дизайн-ревью, а не после разработки.
EAA, ADA и другие регулирующие нормы в 2026 году
European Accessibility Act (EAA, директива 2019/882): действует с 28 июня 2025 года. Применяется к большинству B2C-цифровых продуктов и сервисов, продаваемых в ЕС. WCAG 2.2 AA / EN 301 549 — практический ориентир соответствия. Принуждение к исполнению зависит от страны-члена, штрафы — до 1 млн € (варьируются), а в части юрисдикций предусмотрены и полномочия по отзыву продукта с рынка.
ADA в США (Americans with Disabilities Act): Title III применяется к веб-сайтам с прецедентов 2010-х; правило DOJ 2024 года распространило его на приложения штатов и местных органов власти. Частные мобильные приложения федеральным правилом прямо не покрыты, но сталкиваются с агрессивной судебной практикой со стороны истцов (более 4 000 дел в год, большинство урегулируется на 375 тыс.–3,7 млн ₽).
Section 508 (госсектор США): базовая планка — WCAG 2.0 AA; любое приложение, продаваемое федеральному агентству, должно ей соответствовать. Многие закупки штатов используют те же или более жёсткие требования.
Остальные: британский Equality Act 2010 (услуги), канадский ACA (федеральный), австралийский DDA, AODA Онтарио (провинциальный, для B2C с выручкой выше 10 млн CAD), израильский закон о равных правах людей с инвалидностью. Большинство ссылаются на WCAG 2.1 или 2.2 AA.
Пять подводных камней, которые срывают проекты доступности на iOS
1. Добавлять метки в последний момент. Ретрофит `accessibilityLabel` под конец спринта даёт скупые и непоследовательные подписи. Подключайте метки одновременно с view в SwiftUI или внутри `awakeFromNib()` / `viewDidLoad()` в UIKit.
2. Тестировать только Accessibility Inspector. Inspector ловит пропущенные метки и traits, но не отлавливает корявые формулировки, неудобный порядок фокуса или путаные кастомные роторы. Реальное использование VoiceOver — не опция.
3. Хардкодить размеры шрифтов «только на этом одном экране». Этот экран всегда оказывается не один, и AX5 вытащит каждое исключение наружу. Системные текстовые стили — с первого дня.
4. Пропускать живые анонсы. Асинхронные изменения состояния (загрузка → загружено, отправка → подтверждение, ошибки) без `UIAccessibility.post(notification: .announcement, ...)` для VoiceOver-пользователя проходят беззвучно. Главная причина пользовательской путаницы.
5. Аудит «один раз и забыли». Доступность регрессирует с каждым спринтом. Встраивайте Accessibility Audit из XCUITest в CI и роняйте сборку на новых проблемах — так же, как роняете её на регрессе тестов.
KPI: что измерять, когда доступность выпущена
Нельзя управлять тем, что не измеряешь. Когда семь столпов на месте, именно эти сигналы говорят, держится ли доступность от спринта к спринту и приносит ли пользователю реальную пользу.
Инженерные KPI. (1) Количество проблем Accessibility Audit XCUITest на сборку — цель: ноль новых проблем на PR, меньше 5 открытых в бэклоге в любой момент. (2) Доля кастомных view с явными `accessibilityLabel`, `accessibilityHint` и `accessibilityTraits` — цель: 100%. (3) Покрытие Dynamic Type: доля экранов, которые проходят рендер на AX5 без обрезаний, — цель: ≥95%. (4) Доля успешных проверок коэффициента контраста на дизайн-токенах — цель: 100% на 4,5:1 для основного текста и 3:1 для крупного.
Продуктовые KPI. (1) Завершаемость задач у VoiceOver-пользователей в сравнении со зрячими на трёх главных сценариях — цель: паритет в пределах 10%. (2) Дельта времени выполнения задачи у Voice Control в сравнении с тачем — цель: меньше 2×. (3) Тикеты в поддержку, связанные с доступностью, на 10 тыс. MAU — отслеживайте и снижайте со временем. (4) Тональность отзывов в App Store и соцсетях по ключевым словам доступности (VoiceOver, Dynamic Type, субтитры) — после выпуска ретрофита должна уходить из негатива в нейтрал или плюс.
KPI соответствия. (1) Квартальная доля успешных внешних аудитов по WCAG 2.2 AA — цель: 100% обязательных к исправлению пунктов закрыть до релиза. (2) Свежесть опубликованного Accessibility Statement — обновлять с каждым релизом, который затрагивает пользовательские сценарии. (3) Время реакции на жалобу пользователя — в ряде стран ЕС оно считается отягчающим фактором при принуждении к исполнению EAA. Цель: меньше 30 дней для проблем AA-уровня.
Итоги
Доступность на iOS в 2026 году с точки зрения инструментов — решённая задача: нативные API Apple исчерпывающи, аудит-инструменты Xcode созрели, сторонние вендоры закрывают оставшиеся пробелы. Это задача регулирования (EAA, ADA, Section 508) и продуктовая задача: команды, которые выпускают доступные приложения, добиваются этого потому, что встраивают семь столпов в дизайн-систему, билд-пайплайн и релиз-гейты с первого дня. Сделайте так, заложите 0,5–2% времени разработки на аудит, держите оплачиваемого пользователя экранного диктора в цикле тестирования — и вы будете выпускать приложения, которые работают для 100% потенциальной аудитории и выдерживают любую регулируемую юрисдикцию.
Готовы выпустить iOS-приложение, соответствующее EAA с первого дня?
Фора Софт встраивает доступность iOS в каждый спринт. Свяжитесь с нами — мы проложим путь к соответствию.
Часто задаваемые вопросы
WCAG 2.2 AA — это правильный целевой стандарт для iOS-приложения в 2026 году?
Да. WCAG 2.2 AA — фактический регуляторный ориентир, на который ссылаются EN 301 549 (ЕС), Section 508 (госсектор США), методички британского Equality Act и большинство корпоративных закупок. Специфичные для мобильных критерии успеха в версии 2.2 (Target Size, Dragging Movements, Consistent Help) напрямую применимы к iOS.
Apple проверяет доступность при ревью в App Store?
Apple требует Accessibility Nutrition Label (iOS 18+), но не отклоняет приложения за слабую доступность. Принуждают к исполнению сторонние регуляторы, судебная практика и отзывы пользователей. Чистый Accessibility Nutrition Label — это маркетинговый актив.
Сколько стоит аудит доступности iOS?
Лёгкий автоматический аудит на приложении среднего размера (10–20 экранов) — 150–375 тыс. ₽; полноценный ручной аудит с прогонами VoiceOver, тестированием Switch Control и сессиями с пользователями экранных дикторов — 600 тыс.–1,8 млн ₽. Затраты на исправление обычно в 2–10 раз больше стоимости аудита и зависят от размера списка проблем.
SwiftUI или UIKit удобнее для доступности?
SwiftUI в среднем удобнее, потому что модификаторы доступности живут рядом с описанием view, а системные контролы имеют разумные дефолты. UIKit даёт более низкоуровневое управление, что важно при кастомной отрисовке. Большинство команд в 2026 году используют оба — ни один из них принципиально не лучше для результата по доступности.
Как обрабатывать доступность для WebView внутри iOS-приложения?
WebView наследует собственное дерево доступности из HTML. Убедитесь, что веб-контент самостоятельно проходит WCAG 2.2 AA. На нативной стороне задайте `accessibilityIdentifier` у WKWebView и убедитесь, что окружение (нав-бар, кнопка закрытия) имеет корректные метки. VoiceOver переключает контекст между нативом и вебом бесшовно.
Доступность замедляет разработку?
С первого дня доступность добавляет к общим инженерным трудозатратам примерно 5–10% — на фоне остальной работы по качеству это незаметно. В режиме ретрофита — 10–20%. В любом случае это существенно дешевле, чем судебная практика, риск с ревью App Store или потеря крупного корпоративного контракта из-за провала закупки.
Можно ли использовать AI для генерации меток доступности?
Для изображений и иконок — да. Apple Vision, on-device Core ML image captioning и мультимодальные модели вроде Claude и GPT-4V выдают первичные варианты подписей. Для интерактивных контролов всё же нужны человеческие метки, потому что описание действия и подсказка должны звучать на языке продукта. Используйте AI, чтобы массово подписать каталог изображений, а потом отдайте дизайнеру на ревью.
Читайте дальше
Остались вопросы по доступности на iOS?
Договоримся о рабочей сессии. Мы ответим на вопросы, опираясь на вашу кодовую базу, и пришлём приоритизированный бэклог.
