Почему доступность мобильных приложений ломается при доработках
Доступность мобильных приложений ломается не на старте, а на третьей-четвёртой итерации. Новый экран добавляют под конкретную задачу и торопятся: иконку рисуют без подписи, переключатель собирают из готовых слоёв, всплывающую панель ставят поверх основного содержимого. Экранные дикторы такие элементы либо пропускают, либо объявляют безлико — «кнопка», «элемент», и человек не понимает, что произойдёт после нажатия.
Недоступные элементы управления почти всегда находятся в одном и том же месте: там, где бизнес-логика требует минимума действий. Кастомный слайдер не реагирует на жесты управления с зажатием, поле с маской принимает ввод только с экранной клавиатуры, иконка корзины на карточке товара читается как декоративная картинка. Для пользователя экранных дикторов это не мелочь, а тупик: действие есть визуально, но недостижимо на слух и на ощупь.
Сбитый порядок фокуса заметен только при последовательном обходе. Модальное окно открывается, но обход продолжается по затемнённому содержимому под ним, а после закрытия фокус улетает в начало экрана — и человек заново ищет, где он остановился. Стоит поменять блоки местами при редизайне, и логика чтения расходится с визуальной: диктор ведёт по смыслу из прошлой версии, подсказка звучит раньше заголовка.
Крупный системный шрифт и повышенный контраст добивают сценарий: подписи обрезаются, текст уходит под кнопку, обязательные поля не подсвечиваются. Брошенный сценарий — вот реальная цена. Доля незавершённых оформлений растёт, приходит больше обращений «не могу нажать», а магазин приложений снижает приложение в выдаче по критериям доступности. Разбираем, как это закрывается.
Экранные дикторы, крупный шрифт и контраст: что даёт доработка
Доработка доступности измеряется не числом правок в разметке, а тем, сколько сценариев человек проходит самостоятельно. Ниже — три направления, и по каждому мы фиксируем метрику до и после.
Поддержка экранных дикторов
Каждому интерактивному элементу назначается осмысленное описание и роль, а порядок обхода выстраивается по логике экрана, а не по порядку в разметке. Итог: доля сценариев, завершаемых незрячим пользователем без подсказки со стороны, вырастает с единиц процентов до большинства ключевых путей — вход, оплата, запись.
Масштабирование системного шрифта и высококонтрастный режим
Вёрстка перестаёт ломаться при увеличенном шрифте: текст переносится, кнопки растут, ничего не обрезается и не наезжает друг на друга. Параллельно проверяется контраст — состояние элемента считывается по яркости и форме, а не только по цвету. Класс отказов «подпись уехала за границу кнопки» уходит целиком.
Управление переключателями
Сценарии становятся проходимыми без точных касаний: фокус обходит все элементы, порядок предсказуем, внешние переключатели и голосовое управление доводят действие до конца. Это снимает ещё один пласт отказов — «до элемента нельзя добраться».
Замыкающий эффект — снижение обращений в поддержку: жалобы «не вижу кнопку», «шрифт обрезал текст», «не могу нажать» перестают доходить до первой линии, а сам продукт при этом не меняется.
Варианты реализации: правки разметки против переработки навигации
Доступность держится на двух слоях. Первый — семантическая разметка: подписи к элементам, их роли, порядок обхода фокуса, объявление изменений на экране. Второй — навигация: структура экранов, логика переходов и возвратов. Объём работ зависит от того, какой слой просел и на какой стадии продукт.
Правки семантической разметки — самый короткий цикл: экраны и сценарии остаются прежними, меняются атрибуты и тексты подписей. Переработка навигации затрагивает структуру, поэтому требует согласования с дизайном и полного регресса. Автоматические проверки показывают лишь часть картины: они находят элементы без подписи и нарушенный контраст, но не говорят, понятен ли сценарий на слух, — режимы работы диктора всё равно проверяют руками.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правки семантической разметки | Интерфейс стабилен, экраны собраны из типовых блоков; диктор читает элементы, но сбивается на формулировках и порядке | Не меняет логику экранов: запутанный сценарий разметкой не исправить |
| Переработка навигации | Ключевые сценарии проходятся вслепую заметно дольше, есть ловушки фокуса и дублирующие переходы | Затрагивает вёрстку и код экранов, нужен регресс по всем сценариям |
| Комплексный этап: разметка, навигация, ручные прогоны | Продукт готовится к релизу или есть требования доступности от заказчика либо магазина приложений | Самый длинный цикл: аудит, правки, повторные прогоны диктором, регресс |
Автоматические проверки есть смысл включать в конвейер сборки на любом из вариантов: они дешёвы, ловят регресс и не дают разметке «зарасти» при новых экранах. Но отчёт такой проверки нельзя считать приёмкой — он покрывает форму, а не сценарий. Итоговый критерий один: человек проходит основной путь с включённым диктором и укладывается в разумное время.
Этапы работы: аудит, схема обхода экранов, настройка, проверка
Доступность нельзя проверить «на глаз» — её собирают последовательно. Сначала фиксируем текущее состояние, затем строим карту экранов и только после этого меняем разметку и настройки. Так правки не рассыпаются по релизам и не ломают уже работающие сценарии.
- Аудит доступности. Прогоняем ключевые сценарии с включённым экранным диктором, проверяем контраст, размеры зон нажатия, подписи и реакцию на системный масштаб шрифта. Каждый дефект фиксируем с привязкой к экрану и шагом воспроизведения.
- Сверка с требованиями WCAG. Выбираем целевой уровень и раскладываем расхождения по группам: семантика, навигация, альтернативные тексты, устойчивость к крупному шрифту и отключённой анимации.
- Карта экранов и порядок обхода. Описываем дерево переходов, отмечаем места, где фокус теряется, зацикливается или уходит в тупик после закрытия модального окна.
- Описания элементов. Проставляем роли, состояния и подписи для кнопок, полей, изображений и динамических блоков; озвучивание изменений состояния делаем явным.
- Настройка фокуса. Задаём приоритет чтения, перехват фокуса в модальных окнах и корректный возврат на элемент-источник.
- Контрольная проверка на устройстве. Проходим те же сценарии с диктором, крупным шрифтом и внешней клавиатурой, сверяем результат с картой экранов и закрываем расхождения.
- Передача результата. Отдаём карту экранов, правила описания элементов и регламент проверки доступности в релизном цикле — новые экраны сразу делаются по тем же правилам.
Передаём на руки: разметка, описания элементов, регламент
Пакет передаём вместе с исходным кодом: команда заказчика может менять интерфейс дальше, не теряя разметку. Материалы рассчитаны на разработчика и тестировщика без профильной подготовки по доступности — это не выдержки из стандарта, а рабочие указания с конкретными значениями.
- Схема навигации и порядок фокуса. Карта экранов с очерёдностью обхода диктором: где фокус ставится вручную, какие всплывающие слои его захватывают и как возвращают обратно.
- Описания элементов. Таблица «компонент → метка, роль, подсказка» на все повторяющиеся блоки: кнопки, поля, переключатели, состояния загрузки. Отдельно — правила для динамических списков, чтобы диктор не перечитывал список целиком после каждого обновления.
- Правила контраста и масштабирования. Пороговые отношения для текста и иконок, поведение при системном увеличении шрифта до предела, значения для тёмной темы.
- Регламент проверки. Что прогоняют перед каждым выпуском: ручные сценарии с диктором и увеличенным шрифтом плюс автоматические правила в сборке, которые останавливают её при потере метки.
- Инструкция для команды разработки. Куда добавить описание и как назвать элемент, чтобы он попал в обход; какие правки интерфейса требуют обновить таблицу описаний.
- Инструкция для тестировщиков. Набор сценариев с ожидаемым порядком озвучивания и шаблон отчёта о дефекте — воспроизводимость вместо «диктор читает непонятно что».
Кейс: что изменилось после переработки навигации и разметки
Заказчик пришёл с проблемой, которая на первый взгляд не выглядела технической: доля завершённых сценариев оформления заказа держалась около 60%, а в поддержку шёл поток однотипных обращений — «не нахожу кнопку», «озвучивание не читает поле», «не могу вернуться на шаг назад». Отзывы в магазинах приложений повторяли то же: интерфейс работает только для тех, кто видит экран и уверенно попадает пальцем в мелкий элемент.
Что показал разбор
Наши инженеры прошли по всем ключевым экранам покупки, оплаты и отслеживания доставки с аудитом по Web Content Accessibility Guidelines. Нашли три класса дефектов: подписи не связаны с самими полями, порядок обхода элементов не совпадал с визуальным, а зоны нажатия были меньше комфортного минимума. Из-за этого пользователь терял контекст на середине сценария и закрывал приложение.
Что изменили
Переработали навигацию и разметку: у элементов появились корректные имена и роли, фокус пошёл в логичном порядке, зоны нажатия расширили, иконкам без текста добавили описания. Отдельно переписали возврат и подтверждение заказа — при сворачивании приложения терялись шаг и введённые данные.
Что стало
Доля завершённых сценариев выросла с 61% до 88%, обращения в поддержку по навигации упали в 2,4 раза. Доля пользователей с программой экранного доступа поднялась с 4% до 11% — часть из них раньше просто не доходила до оплаты. В отзывах сместились формулировки: вместо «ничего не понятно» всё чаще «всё находится с первого раза».
Метрики сверяли по продуктовой аналитике и выгрузке обращений за сопоставимые периоды, а не по ощущениям команды — источник данных зафиксирован в отчёте по проекту.
Что делать, если доступность не заложена в дизайн изначально?
Что делать, если доступность не закладывали в макеты: готовый продукт не нужно переписывать целиком. Основная часть проблем лежит не в визуальном слое, а в разметке — у элементов нет подписей для скринридера, у иконок нет альтернативного текста, фокус обходит экран в случайном порядке, а состояние кнопки не озвучивается. Такие правки не меняют внешний вид ни на пиксель, поэтому их выкатывают отдельным релизом, не дожидаясь редизайна.
Дальше определяют приоритет экранов по аналитике, а не по расположению в меню. Первыми идут вход, восстановление доступа, ключевой сценарий и оплата — там, где недоступность блокирует пользователя полностью. Экран с формой и валидацией важнее декоративной ленты: ошибку ввода скринридер должен прочитать вслух, а не молча подсветить красным.
Поэтапное внедрение строят так, чтобы каждый шаг был самостоятельным. Правки в семантике не трогают контракты обмена данными и не ломают вёрстку, поэтому обратная совместимость сохраняется, а неудачный релиз откатывается без последствий для остальных экранов. Визуальные изменения — масштабируемость шрифта, контраст, размер зон нажатия — идут вторым этапом, когда невизуальный слой уже закрыт и продукт перестал терять пользователей на базовых действиях.
Чтобы разовые правки не растворились в следующих спринтах, требования к разметке переносят в дизайн-систему и в автоматические проверки на сборке: новые экраны проходят те же правила без ручного контроля. Через два-три цикла доступность перестаёт быть отдельной задачей и становится свойством продукта по умолчанию.
Технические сомнения: объём правок, сроки, риски для релиза
Сомнения по доступности обычно не про саму технологию, а про то, как правки впишутся в цикл выпуска. Ниже — ответы на частые вопросы на старте: объём работ, совместимость со сборкой, сроки проверки и риски для ближайшего релиза.
Придётся ли переписывать экраны?
Нет. Основной объём — семантическая разметка: подписи элементов, порядок обхода экранным диктором, альтернативные тексты, размер зон касания. Логика и вёрстка остаются прежними, правки локальны и не тянут за собой переработку навигации.
Доработки сломают текущий выпуск?
Правки идут отдельной ветвью и включаются удалённой настройкой, а не для всех сразу. Сборку можно выпустить в прежнем виде, открыть доступность части пользователей и расширить охват после подтверждения результата. Если всплыл регресс — настройка снимается без новой сборки.
Сколько это занимает и как проверяется?
Срок зависит от числа экранов и их состояния: типовые списки и формы правятся быстро, настраиваемые графики и кастомные элементы управления разбираем отдельно. Первый проход по основным сценариям занимает недели. Проверяем ручным обходом с экранным диктором на реальных устройствах, контрольным списком по ключевым путям и автотестами на контрастность и размер зон.
Как распределяются роли в команде?
Мы ведём разметку, проверку и отчёт по экранам, ваша команда согласует приоритет и выпускает сборку в своём цикле. С вашей стороны достаточно одного человека, знающего продукт и подтверждающего сценарии.
Обсудим задачу и вернёмся с оценкой и планом работ
Разбор задачи занимает один разговор на 30–40 минут: инженер идёт по вашим сценариям — вход, оплата, оформление заказа, поддержка — и отмечает, где интерфейс теряет пользователей с программами экранного доступа, крупным системным шрифтом или управлением с внешней клавиатуры. По итогам вы получаете не общие слова, а карту экранов с приоритетами и оценку трудозатрат по каждому блоку.
Чтобы разбор был предметным, для старта достаточно прислать:
- перечень платформ и актуальных веток ОС, которые поддерживаете;
- список ключевых сценариев и экранов, где пользователи чаще всего отваливаются;
- отчёты прошлых проверок, обращения в поддержку или снимки проблемных мест;
- доступ к тестовой сборке или макетам — с учётной записью и тестовыми данными;
- целевой уровень соответствия руководствам по доступности (WCAG) и перечень экранов, которые в него входят;
- сроки, к которым нужен результат, и кто на вашей стороне принимает работу.
В ответ приходит оценка и план: состав работ по этапам, порядок старта, роли в команде, точки проверки и формат отчёта о результате. Если часть материалов под соглашением о неразглашении, подписываем его до передачи доступов. Опишите задачу — вернёмся с оценкой и планом работ.