Доступность — это не про комплаенс, а про архитектуру: почему большинство команд неправильно понимают инклюзивный дизайн

Мы поговорили с Богданом Марчуком — старшим iOS-инженером с более чем 12-летним опытом в сфере корпоративной мобильной разработки и бывшим техническим директором компании Boring Owl в Варшаве. Он является членом совета AITEX и Fellow Hackathon Raptors, автором книги о создании глобальных мобильных приложений, а метрику эффективности экранного считывателя, о которой речь идёт ниже, опубликовал в виде рецензируемого исследования.

— Богдан, вы утверждаете, что приложение может пройти любой аудит на доступность и при этом оставаться непригодным для использования со скринридером. Как так получается?

— Аудит проверяет это, но не показывает, сколько действий нужно выполнить, чтобы подтвердить платеж, и в каком порядке будут озвучиваться экраны. Я видел приложения, формально соответствующие WCAG, где подтверждение денежного перевода требовало более двадцати свайпов, потому что фокус перемещался в соответствии с порядком верстки, а не с логикой задачи.

— Большинство инженеров воспринимают доступность как подписи и контраст, которые добавляются в конце. Почему это ошибочно?

— Потому что порядок фокусировки определяется на этапе проектирования компонентов, а не при окончательной проверке. Я работал над приложением для iOS, предназначенным для подключенного очистителя воздуха — IoT-устройства, которым люди управляют с телефона. Там нужно было обеспечить полное соответствие WCAG 2.1 AA для пользователей с нарушениями зрения и дать им возможность управлять самим устройством, а не только просматривать его статус. Интерфейс отображал состояние устройства в реальном времени: не набор статичных экранов, а живой поток данных с фильтра. Когда происходит критическое изменение, скажем, меняется уровень фильтрации или обрывается соединение, приложение чётко объясняет, что пользователю делать дальше. И это касается не только доступности. Я написал книгу о создании приложений для глобальных рынков, и там действует то же правило: поддержка новых языков или платежных систем должна быть заложена с первого дня — добавить её в конце не получится.

— Вы не только сами разрабатываете такие системы — компании также приглашают вас со стороны, чтобы провести аудит их продуктов и оценить инженерную работу на международных саммитах. Что видит независимый рецензент, чего не видит сама команда?

— Дистанцию. Когда ты сам создал продукт, ты перестаёшь его видеть — ориентируешься по памяти. Я провел более тридцати независимых архитектурных аудитов — меня приглашали оценивать такие продукты, как караоке-приложение iSing и платформа SAO Life — а также был судьей по инженерной работе на AITEX Summit. У внешнего рецензента нет привязанности к дорожной карте и старым решениям, поэтому ты воспринимаешь продукт так же, как новый пользователь. Именно в этом и кроются проблемы с доступностью — команда уже давно перестала воспринимать свой собственный продукт свежим взглядом.

— И как часто проблема, с которой мы начали — соответствие на бумаге, сложности на практике — возникает у вас во время таких проверок?

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

Методология Focus-Step Budget

— Вы даже дали этому явлению числовое выражение — "бюджет фокус-шагов". Откуда это взялось и почему именно "бюджет"?

— WCAG требует, чтобы экран был управляемым, но не определяет, сколько навигационных шагов должно занимать подтверждение платежа. А бюджет — это конкретное число: для подтверждения транзакции я установил предел в двенадцать шагов фокуса. С этим числом инженер проектирует экран заранее, вместо того чтобы выявлять недостатки постфактум.

— Почему именно двенадцать? И действительно ли количество пользователей укладывалось в это число?

— Эта цифра не произвольна — она получена в ходе исследования с участием двенадцати человек в Польше, которые ежедневно пользуются VoiceOver и TalkBack. В более длинных потоках они начинали терять нить: забывали, на каком этапе находятся, переспрашивали, что происходит. Именно так мы пришли к двенадцати шагам как пределу для критической задачи. Применение навигационных шаблонов в чистом виде сократило путь в среднем примерно до двадцати шагов — лучше, чем было, но всё ещё выше цели. И в своей публикации на эту тему я привёл именно этот честный результат.

— А что, если из-за этого проект провалится — экран выйдет за рамки бюджета, CI сломается? Как это будет работать?

Бюджет заложен в качестве проверки в конвейере: если экран превышает лимит, слияние блокируется — так же, как при непрохождении unit-теста. Без этого доступность постепенно ухудшается с каждым релизом: дизайнер добавил элемент, разработчик переместил блок — о скринридере никто не подумал, потому что формально ничего не "сломалось". Когда проверка встроена в CI, доступность становится контрольной точкой, о которой невозможно забыть.

Когда интерфейс — подвижная цель

— Вернёмся к очистителю воздуха. Вы создали приложение, которое, по сути, представляет собой "живое" окно в физическое устройство. Как вам удалось сделать так, чтобы движущаяся цель была различима для людей с нарушениями зрения?

— В типичном приложении экран меняется в ответ на действие пользователя — он коснулся экрана, экран обновился, это предсказуемая последовательность. Здесь состояние может меняться само по себе: устройство переключает режимы фильтрации, теряет соединение Wi-Fi, фильтр требует замены — асинхронно, без участия пользователя. Если просто озвучивать каждое изменение через скринридер, пользователя завалит потоком уведомлений. Решением стала иерархия: одни изменения критичны и прерывают текущее действие на устройстве, тогда как о других, менее значимых изменениях, приложение сообщает, не прерывая фокус.

— Практически никто не обеспечивает реальную доступность для подключенных устройств. Почему так и во сколько вам это обошлось?

— Эта категория отстает, поскольку такие приложения разрабатываются как визуальные дашборды — графики, индикаторы, цветовая индикация статуса и т. д. Преобразование этого в линейный интерфейс для экранного считывателя — отдельная задача, которая не вытекает автоматически из дизайна. Для нашей команды это означало переработку модели состояния: вместо проектирования простого интерфейса нам пришлось определить порядок и приоритетность озвучивания уведомлений. Конечно, это заняло больше времени, чем стандартная разметка.

Юридический аспект доступности сегодня

— Законодательство лишь недавно пришло в ногу с этой практикой — требования ADA в отношении мобильной доступности вступили в силу в 2024 году, а European Accessibility Act — в 2025-м. Стала ли доступность теперь однозначно обязательным требованием, а бюджетирование — инструментом обеспечения соответствия?

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

— В вашей публикации отмечается, что этот метод позволил сократить путь примерно до двадцати шагов, а не до двенадцати, как вы планировали. Так он вообще работает?

— Работает в том смысле, что обеспечивает измеримое улучшение и выводит доступность в категорию инженерного контроля. Не работает как окончательное решение — разрыв между двадцатью и двенадцатью шагами реальный, и одним шаблоном его не устранить. Далее требуется работа над тем, как сама модель структурирована для последовательного, а не пространственного восприятия. Это следующий этап — методология рабочая, но ещё не окончательная. Удар по Винницкой области — РФ атаковала "Новую почту" — Фокус