Accessibility в iOS-приложении: VoiceOver и Dynamic Type для творческих инструментов

Почему доступность важна даже для «визуального» приложения

Accessibility в iOS принято описывать через семь столпов: семантические лейблы и VoiceOver, адаптивный текст через Dynamic Type, достаточный цвет и контраст, контроль движения и haptics, Voice Control и Switch Control, субтитры и аудио-описания, понятные формы и сообщения об ошибках. Для творческого canvas-приложения первые два столпа дают наибольший эффект при наименьших трудозатратах — именно с них разумно начинать.

Регуляторный фон в 2026 году только усиливает практическую мотивацию: European Accessibility Act (EAA) и стандарт WCAG 2.2 AA всё чаще появляются как требование со стороны корпоративных заказчиков и партнёров, даже если приложение формально не продаётся в ЕС. Это не повод для юридической паники — скорее сигнал, что доступность перестала быть нишевой темой и превратилась в ожидаемый минимум качества продукта.

Для творческой студии вроде oodot вопрос звучит иначе, чем для банковского приложения: у нас нет форм и таблиц, зато есть холст, жесты и свет. Решение — не копировать чужой чек-лист один в один, а применить те же принципы к интерфейсу вокруг холста: кнопкам, панелям инструментов, модалкам — оставив сам творческий процесс нетронутым.

VoiceOver в творческом интерфейсе — с чего начать

VoiceOver озвучивает интерфейс через accessibility-дерево — но дерево работает только там, где элементы описаны правильно. Для canvas-инструментов это значит: холст можно оставить как единый декоративный элемент, а всю работу сделать на обвязке вокруг него.

Семантические лейблы для нестандартных UI-элементов

Любая кастомная кнопка жеста, тулбар-иконка или свайп-переключатель должны получить описательный accessibilityLabel — не «Button 3», а «Выбрать толщину кисти» или «Сохранить рисунок». Стандартные UIButton и UIControl в UIKit и SwiftUI уже частично доступны из коробки, но как только элемент собран вручную (кастомный UIView с жестовым распознавателем), VoiceOver не узнает о нём ничего, пока вы явно не пропишете роль и подпись:

customBrushButton.isAccessibilityElement = true
customBrushButton.accessibilityLabel = "Выбрать толщину кисти"
customBrushButton.accessibilityTraits = .button

В SwiftUI то же самое решается модификатором .accessibilityLabel() на любом View, включая кастомные жесты поверх Canvas или Shape.

Перевод фокуса VoiceOver при открытии модалок и оверлеев

Второй частый провал — модальное окно или боковая панель открывается, а VoiceOver продолжает читать то, что было на экране до этого, потому что фокус не переместился. Решение — явно отправить системе уведомление о смене экрана и указать, на какой элемент перевести фокус:

UIAccessibility.post(notification: .screenChanged, argument: firstElementInSheet)

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

Dynamic Type без потери творческого layout

Dynamic Type — системная настройка, которая меняет размер текста во всех приложениях сразу. Для творческого приложения задача не в том, чтобы увеличить сам холст (это не текст и под Dynamic Type не подпадает), а в том, чтобы интерфейс вокруг него — подписи инструментов, настройки, онбординг — корректно растягивался под крупный текст, не обрезаясь и не наезжая на соседние элементы.

Auto Layout с content-hugging и compression-resistance

Правильно настроенный Auto Layout закрывает порядка 90% проблем вёрстки с Dynamic Type сам, без дополнительного кода. Ключевая идея — не фиксировать высоту текстовых контейнеров жёстко, а задавать приоритеты content-hugging (элемент не растягивается сверх необходимого) и compression-resistance (элемент не сжимается ниже минимально читаемого размера) так, чтобы текстовый label мог вырасти, а соседние иконки — остаться на месте.

adjustsFontForContentSizeCategory и тест на размере AX5

Текст должен подключаться через стили Dynamic Type (.preferredFont(forTextStyle:) в UIKit, встроенные стили шрифта в SwiftUI), а не через хардкод конкретного значения size. Для UIKit-меток дополнительно включите:

label.font = UIFont.preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true

Финальная проверка — выставить в Accessibility Inspector (Xcode → Open Developer Tool → Accessibility Inspector) крупнейший размер текста категории AX5 и визуально пройтись по каждому экрану: текст не должен обрезаться, кнопки — наезжать друг на друга, а панели инструментов — терять читаемость.

Что проверять перед релизом — чек-лист доступности

Перед тем как отправлять творческое приложение на ревью, пройдитесь по короткому списку — он не заменяет полноценный accessibility-аудит, но ловит большинство проблем за один прогон:

1. Включите VoiceOver и пройдите основной сценарий приложения только жестами экранного диктора — от запуска до сохранения результата.
2. Проверьте, что у каждой кастомной кнопки и жестового элемента есть осмысленный accessibilityLabel, а не технический идентификатор.
3. Откройте каждую модалку и оверлей — убедитесь, что VoiceOver переводит фокус на новый контент, а не застревает на фоне.
4. Выставите Dynamic Type на максимальный размер (AX5) и визуально проверьте все экраны на обрезку текста и наложение элементов.
5. Убедитесь, что adjustsFontForContentSizeCategory включён для всех текстовых меток, где используется кастомный шрифт.
6. Проверьте контраст текста интерфейса (не холста) относительно фона — особенно в тёмной теме, которая часто используется в творческих приложениях.
7. Если в приложении есть анимации по умолчанию — проверьте поведение при включённой системной настройке Reduce Motion.

Когда нужна внешняя команда разработки

Встроить accessibility в уже готовое приложение дороже, чем заложить её с нуля: переписывать вёрстку под Auto Layout задним числом и добавлять лейблы россыпью по всему коду — заметно менее эффективно, чем учесть это на этапе архитектуры. Если в штате нет разработчика с опытом именно accessibility-слоя iOS, разумнее привлечь внешнюю команду, которая учтёт VoiceOver и Dynamic Type ещё на этапе разработки мобильного приложения, а не чинить это после первого отказа App Review или жалобы пользователя.

FAQ: частые вопросы про accessibility в iOS-приложениях

Нужен ли VoiceOver, если у приложения визуальный интерфейс?

Да. VoiceOver используют не только незрячие пользователи — его включают и люди с частичной потерей зрения, и те, кто временно не может смотреть на экран. «Визуальность» интерфейса не освобождает от базовой доступности: даже canvas-инструмент можно описать через accessibilityLabel на управляющих элементах, не трогая сам холст.

Что такое Dynamic Type простыми словами?

Dynamic Type — системная настройка iOS, которая позволяет пользователю увеличивать или уменьшать размер текста во всех приложениях сразу, без ручной настройки в каждом из них. Приложение, которое поддерживает Dynamic Type, подстраивает шрифты и вёрстку под выбранный пользователем размер автоматически.

Ломает ли accessibility творческий UX?

Нет, если делать это с самого начала проектирования. Accessibility-слой работает параллельно визуальному: VoiceOver озвучивает семантику элементов управления, а не рисует поверх холста, а Dynamic Type касается текста интерфейса (подписи, кнопки, настройки), а не самого творческого контента — линий, кистей, фильтров.

С чего начать аудит доступности существующего приложения?

Включите VoiceOver (Настройки → Универсальный доступ → VoiceOver) и пройдите по приложению жестами экранного диктора. Отдельно проверьте текст на крупнейшем размере Dynamic Type через Accessibility Inspector в Xcode — это быстро выявит и кнопки без подписей, и обрезанный текст.

Это требование Apple для App Store?

Apple активно продвигает accessibility как часть Human Interface Guidelines и может отклонить явно нерабочее приложение на ревью, но жёсткого технического гейта «без VoiceOver не пропустим» в App Store нет. Регуляторное давление сильнее идёт со стороны рынка — например, European Accessibility Act и стандарт WCAG 2.2 AA, которые всё чаще требуют заказчики и партнёры.

Нужно ли переписывать весь интерфейс ради Dynamic Type?

Обычно нет. Если вёрстка уже построена на Auto Layout с правильными content-hugging и compression-resistance приоритетами, Dynamic Type закрывает подавляющее большинство случаев сам. Переписывать приходится в основном места с хардкодом размеров шрифта и фиксированной высотой текстовых контейнеров.

Как проверить, что VoiceOver правильно работает с кастомными жестами?

Кастомные жесты (рисование пальцем, свайпы по холсту) VoiceOver не озвучивает сам по себе — для них нужны отдельные accessibility actions или альтернативный способ взаимодействия через explicit элементы управления. Проверяйте вручную: включите VoiceOver и попробуйте выполнить основной сценарий приложения только жестами экранного диктора.

Accessibility для творческого iOS-приложения — это не компромисс с визуальным языком продукта, а отдельный слой интерфейса, который можно добавить, не трогая сам холст. VoiceOver и Dynamic Type закрывают основную часть работы и дают ощутимый эффект уже после первого прохода по чек-листу выше — а остальные вспомогательные технологии можно добавлять по мере того, как вы узнаёте реальную аудиторию приложения.