Адаптивные интерфейсы для слабовидящих пользователей: принципы проектирования и практические решения

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

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

Кто такие слабовидящие пользователи и чем их задачи отличаются от задач слепых

Важно не смешивать две разные группы, потому что решения для них противоположны по логике:

• Слепые пользователи обычно работают со скринридерами (программами озвучивания экрана) и не видят визуальное оформление вообще. Для них критична семантическая разметка и порядок чтения контента.
• Слабовидящие пользователи видят экран, но с ограничениями: им нужно больше, крупнее, контрастнее. Они пользуются мышью и тачскрином, увеличивают страницу встроенными средствами браузера, иногда применяют лупу или экранные фильтры.

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

Типичные ограничения зрения, которые влияют на дизайн:

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

Контраст: самый недооценённый параметр интерфейса

Мода на «воздушный» дизайн с бледно-серым текстом на белом фоне напрямую бьёт по слабовидящим пользователям. Контраст измеряется как соотношение яркости текста и фона, и здесь есть общепринятые ориентиры из стандарта WCAG (Web Content Accessibility Guidelines) — международного свода рекомендаций по веб-доступности:

• 4,5:1 — минимальный контраст для обычного текста;
• 3:1 — минимум для крупного текста (примерно от 18–19 пикселей жирного или 24 пикселей обычного начертания) и для графических элементов, важных для понимания: иконок, границ полей ввода, индикаторов состояния;
• 7:1 — усиленный уровень, который заметно облегчает чтение людям со сниженным зрением.

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

Частые ошибки, которые легко избежать:

• серый текст-подсказка внутри поля ввода светлее допустимого минимума;
• белый текст на фотографии без затемняющей подложки — контраст непредсказуем и зависит от картинки;
• кнопка в «выключенном» состоянии почти сливается с фоном, и пользователь не понимает, активна она или нет;
• индикация ошибки только красным цветом, который у части пользователей плохо отличим от обычного состояния.

Масштабируемость: интерфейс должен переживать увеличение

Слабовидящий пользователь часто увеличивает страницу до 200% и выше средствами браузера или системными настройками. Интерфейс должен оставаться работоспособным при этом. На практике это означает несколько требований к вёрстке.

Используйте относительные единицы. Размеры шрифтов задавайте в rem, а не в фиксированных пикселях, чтобы текст реагировал на настройки браузера и операционной системы. Макеты стройте на гибких сетках, а не на жёстко зафиксированной ширине.

Не ломайте макет при увеличении. Проверьте, что при 200% масштабе:

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

Уважайте пользовательские настройки. Если человек увеличил системный размер шрифта в телефоне, приложение должно это учесть. Жёсткая фиксация размеров текста в мобильных приложениях — одна из самых массовых проблем доступности.

Не блокируйте зум. Запрет масштабирования страницы через метатеги viewport или отключение жеста pinch-to-zoom в приложениях лишает слабовидящего пользователя главного инструмента. Делать так допустимо только в исключительных случаях (например, картографические жесты), и даже тогда нужен альтернативный способ увеличения.

Размер целей нажатия и плотность интерфейса

Чем хуже видно, тем труднее точно попасть курсором или пальцем в маленькую цель. Ориентир из WCAG — область нажатия примерно 24×24 CSS-пикселя как минимум, а комфортнее — от 44×44, особенно на сенсорных экранах. Важен не только размер самой кнопки, но и расстояние между соседними целями: рядом стоящие мелкие ссылки в сплошном тексте превращаются в лотерею.

Что помогает на практике:

• увеличенная зона клика за счёт внутренних отступов, даже если видимая иконка маленькая;
• разнесённые интервалы между пунктами меню и ссылками;
• крупные поля форм с чёткими границами, а не только тонкой нижней чертой;
• переключатели и чекбоксы, реагирующие на нажатие по всей строке, а не только по самому квадратику.

Цвет — не единственный носитель смысла

Правило простое: любое состояние или различие, закодированное цветом, должно дублироваться другим способом. Красная рамка у поля с ошибкой должна сопровождаться текстовым сообщением о том, что именно не так. Ссылки в тексте должны отличаться не только цветом, но и подчёркиванием. Обязательные поля помечаются не только звёздочкой цвета, но и явной подписью.

Это требование связано не только с дальтонизмом. При сниженном контрасте или на выцветшем экране оттенки теряются первыми, а форма, текст и положение элемента сохраняются.

Типографика для читаемости

Шрифт влияет на скорость чтения сильнее, чем кажется. Практические ориентиры:

• базовый размер основного текста — не меньше 16 пикселей; меньше — только для действительно второстепенных подписей;
• длина строки — примерно 45–75 символов: слишком длинные строки тяжело возвращать взглядом к началу следующей;
• межстрочный интервал — около 1,5 для основного текста;
• избегайте тонких начертаний (light, thin) для основного текста — они «исчезают» на низкоконтрастных экранах;
• выравнивание по левому краю вместо выключки по ширине: растянутые пробелы создают неровные «реки», мешающие движению взгляда;
• капслок и курсив — дозированно: текст набранный целиком заглавными читается медленнее.

Полезный паттерн — дать пользователю выбор темы оформления: светлая, тёмная и высококонтрастная. Тёмная тема помогает при светочувствительности, высококонтрастная — при выраженном снижении зрения. Системные настройки вроде prefers-color-scheme и prefers-contrast позволяют подхватить предпочтения автоматически.

Структура и навигация: предсказуемость важнее креатива

При увеличенном масштабе пользователь видит лишь фрагмент страницы, поэтому ориентируется по структуре, а не по общему виду. Отсюда требования:

• логичная иерархия заголовков: один h1, разделы h2, подразделы h3 — без пропусков уровней ради визуального размера;
• заголовки описывают содержание раздела, а не являются каламбурами;
• навигация, поиск и основные действия находятся в предсказуемых местах на всех страницах;
• текущее положение в меню и в многошаговых процессах явно обозначено;
• ссылка «перейти к содержанию» в начале страницы позволяет пропустить повторяющееся меню при клавиатурной навигации.

Отдельная тема — фокус при работе с клавиатурой. Многие пользователи с ослабленным зрением комбинируют мышь с клавиатурой или используют её полностью. Индикатор фокуса нельзя убирать через outline: none без замены на другой видимый маркер. Фокус должен быть хорошо заметен (контраст не ниже 3:1 относительно соседних областей), а порядок перехода по Tab — совпадать с визуальным порядком элементов.

Формы: где слабовидящий пользователь теряется чаще всего

Формы — самая чувствительная к доступности часть интерфейса. Рабочий набор правил:

1. У каждого поля есть постоянная видимая подпись над ним, а не только плейсхолдер внутри: плейсхолдер исчезает при вводе и обычно слишком бледный.
2. Ошибки выводятся текстом рядом с полем и суммируются в начале формы после отправки.
3. Сообщение об ошибке объясняет, что исправить: не просто «неверный формат», а «введите телефон в формате +7 XXX XXX-XX-XX».
4. Поля связаны с подписями программно (атрибут for / id в HTML или аналоги в других технологиях), чтобы скринридер и вспомогательные средства правильно их сопоставляли.
5. Автозаполнение и маски ввода снижают нагрузку: чем меньше ручного ввода, тем меньше ошибок.
6. Таймеры на шагах оформления (если они есть) должны быть отключаемыми или продлеваемыми — при увеличенном масштабе заполнение занимает больше времени.

Изображения, видео и анимация

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

• Информативные изображения получают осмысленный alt-текст: не «фото», а «график продаж за квартал: рост во втором квартале». Декоративные помечаются пустым alt, чтобы не засорять чтение.
• Текст, «вшитый» в картинку, недоступен для увеличения и экранных дикторов. Всё существенное дублируйте реальным текстом.
• Иконки без подписей — риск: при плохом зрении абстрактный глиф не считывается. Подписывайте значимые действия словами.
• Автовоспроизведение видео со звуком и мигающие анимации мешают концентрации; движение должно быть останавливаемым, а крупные мигающие области — исключены.
• Если интерфейс поддерживает prefers-reduced-motion, уважайте эту настройку и отключайте декоративные анимации.

Как проверить интерфейс: практический чек-лист

Доступность проверяется в основном вручную и бесплатно. Минимальный цикл проверки:

1. Увеличьте страницу в браузере до 200% и пройдите ключевой сценарий: найти товар, заполнить форму, оформить заказ. Зафиксируйте всё, что обрезалось, перекрылось или стало недостижимым.
2. Пройдите тот же сценарий только с клавиатуры: Tab, Enter, стрелки. Убедитесь, что фокус всегда виден и порядок логичен.
3. Проверьте контраст всех пар «текст/фон» инструментом проверки контрастности, включая второстепенные подписи.
4. Посмотрите страницу в режиме высокой контрастности операционной системы: не «отвалятся» ли иконки и границы.
5. Прослушайте ключевые страницы скринридером хотя бы на базовом уровне — это выявит проблемы структуры, которые не видны глазами.
6. Проверьте формы: подписи, сообщения об ошибках, поведение при пустой отправке.
7. Увеличьте системный шрифт на смартфоне и откройте приложение: помещается ли текст, не режутся ли подписи.

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

Сравнение подходов: адаптация основного интерфейса против отдельной версии

Критерий	Гибкий основной интерфейс	Отдельная «версия для слабовидящих»
Охват пользователей	Помогает всем: и слабовидящим, и остальным	Помогает только тем, кто нашёл переключатель
Сопровождение	Одна кодовая база, правки вносятся один раз	Две версии, которые расходятся со временем
Актуальность контента	Единый источник данных	Высокий риск устаревания дубля
Стоимость внедрения	Окупается постепенно, встраивается в процесс	Разовая большая работа плюс постоянные затраты
Риск стигматизации	Нет отдельного «режима для инвалидов»	Часть пользователей избегает специальной версии

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

Типичные ошибки и как их исправить

• Бледный второстепенный текст. Подписи, даты, копирайт набирают светло-серым «для иерархии». Исправление: держать все читаемые тексты в пределах минимума контраста, а иерархию строить размером и весом.
• Фиксированная высота блоков. При увеличении шрифта текст обрезается. Исправление: min-height вместо height и отказ от жёстких ограничений.
• Плейсхолдер вместо подписи поля. Исправление: постоянная видимая подпись, плейсхолдер — только как пример значения.
• Убранный outline фокуса. Исправление: собственный стиль фокуса с достаточным контрастом.
• Отключённый зум на мобильных. Исправление: убрать запрет масштабирования, проверить сценарии при 200%.
• Доступность «потом». Попытка прикрутить её после релиза обходится дороже, чем закладывание в процесс: переделка форм и сеток стоит больше, чем изначально правильные решения.

Сценарии: с чего начать в вашей ситуации

Если проект ещё на стадии дизайна. Заложите контрастную палитру, типографическую шкалу с базовым размером от 16 пикселей и правила состояний (фокус, ошибка, отключено) прямо в дизайн-систему. Править компоненты дешевле, чем готовые страницы.

Если сайт уже работает и бюджет ограничен. Начните с самого болезненного: контраст текста, подписи и ошибки в формах, видимый фокус, запрет зума. Эти четыре пункта дают наибольший эффект при умеренных затратах.

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

Если проект большой и командный. Добавьте проверки доступности в приёмку задач: контраст новых компонентов, работа при 200%, клавиатурная навигация. Разовые аудиты быстро устаревают — процесс устойчивее.

Частые вопросы

Нужно ли делать отдельную версию сайта для слабовидящих?

В большинстве случаев нет. Гибкий основной интерфейс с настройками размера и контраста решает задачу лучше и дешевле, чем поддержание второй версии, которая неизбежно отстаёт по контенту и функциям.

Достаточно ли следовать WCAG, чтобы интерфейс был удобен?

WCAG задаёт проверяемый минимум, а не потолок качества. Соответствие уровня AA — разумная база, но реальные сценарии (длинные формы, сложные таблицы, нестандартные виджеты) требуют ручной проверки с участием людей, в том числе пользователей с особенностями зрения.

Какой минимальный размер шрифта считать безопасным?

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

Обязательна ли поддержка скринридеров, если статья про слабовидящих?

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

Сколько стоит сделать интерфейс доступным?

Единой цифры нет: цена зависит от текущего состояния проекта, объёма шаблонов и того, насколько доступность заложена в процесс. Точечные исправления (контраст, формы, фокус) обычно недороги, а переделка архитектуры после релиза — заметно дороже профилактики.

Что делать дальше

Начните с аудита одного ключевого сценария вашего продукта: увеличение до 200%, прохождение только с клавиатуры, проверка контраста и форм. Зафиксируйте найденные проблемы, отсортируйте по влиянию на пользователя и закрывайте их в порядке серьёзности, встраивая проверки доступности в обычный процесс разработки. Главный принцип — гибкость: интерфейс должен подстраиваться под настройки пользователя, а не требовать от него идеального зрения.