Адаптация сайта под слабовидящих пользователей

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

В кейсе одной фарм‑e‑commerce, где мы исправили контраст, фокус, alt и навигацию по клавиатуре, отказов стало меньше на 12%, конверсия из карточки товара выросла на 9,3% при неизменном рекламном бюджете.

Юридический риск и комплаенс тоже важны. Европейские директивы (EN 301 549, WAD), ADA и стандарт WCAG 2.1/2.2: ориентиры, к которым уже тяготеют украинские компании, особенно с экспортом или филиалами в ЕС. Публичное accessibility statement повышает доверие и дисциплинирует внутренние процессы: вы фиксируете уровень соответствия (A/AA), roadmap и контакт для обратной связи.

Экономика проекта проста: CAPEX — разовые доработки (аудит, ремедиация, внедрение паттернов), OPEX — поддержка (регресс‑тесты, мониторинг, обучение). ROI складывается из сокращения утечек трафика (рост task completion и conversion rate), снижения риска судебных претензий и роста LTV за счет удержания. В проектах BUSINESS SITE мы считаем ROMI на горизонте 3–6 месяцев, и в e‑commerce часто видим окупаемость за 2–3 спринта.

Практика BUSINESS SITE подтверждает: быстрые победы дают контрастность, видимый фокус, alt‑тексты, корректные labels и skip links. Эти задачи занимают недели, а не месяцы, и сразу влияют на поведение пользователя.

Чек‑лист (бизнес‑блок)

• Определите рынок: доля мобильного трафика, доля пользователей с увеличением шрифта (по событиям CSS prefers-reduced-motion и zoom).
• Утвердите цель: рост конверсии на X%, снижение отказов на Y%.
• Назначьте owner’ов: продукт, дизайн, разработка, QA, маркетинг.
• Примите стандарт соответствия: WCAG 2.2 AA как целевой.
• Подготовьте accessibility statement (уровень, дата, roadmap).

Примеры кода/сниппеты

Инструменты/ресурсы

• WCAG Overview: https://www.w3.org/WAI/standards-guidelines/wcag/
• EN 301 549 summary: https://www.etsi.org
• Accessibility Statements guide: https://www.w3.org/WAI/planning/statements/

Шаблон product ticket

• Заголовок: Низкая контрастность CTA на мобильном
• Проблема: Контраст кнопки «Купить» 2.8:1, ниже 4.5:1.
• Шаги: Открыть карточку товара → проверить контраст в DevTools.
• Критичность: Высокая (влияет на оплату).
• Приоритет: P1
• Критерии приемки: контраст ≥ 4.5:1 на всех состояниях, проверено WAVE/axe.

WCAG: требования для слабовидящих

WCAG 2.1 и 2.2, набор проверяемых критериев (Success Criteria, SC) на уровнях A/AA/AAA. Для коммерческих сайтов целесообразно целиться в уровень AA: он обеспечивает доступный интерфейс без чрезмерных издержек. Уровень AAA полезен для отдельных сценариев, но как общий стандарт слишком затратен.

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

Чек‑лист (уровень AA)

• 1.4.3 Контраст текста ≥ 4.5:1; крупный текст ≥ 3:1.
• 2.1.1 Полная клавиатурная навигация; фокус заметен.
• 2.4.1 Skip links; корректные landmarks.
• 3.3.1/3.3.3 Четкие ошибки форм и подсказки.
• 1.4.4 Текст увеличивается до 200% без потери содержимого.

Код/сниппет

Пропустить к основному контенту
...

.skip-link { position:absolute; left:-9999px; }
.skip-link:focus { left:16px; top:16px; background:#fff; padding:8px; }

Инструменты/ресурсы

• WCAG 2.2 quickref: https://www.w3.org/WAI/WCAG22/quickref/
• WAVE: https://wave.webaim.org
• axe DevTools: https://www.deque.com/axe/

Шаблон product ticket

• Заголовок: Добавить skip link и landmarks
• Проблема: Пользователь не может быстро перейти к контенту.
• Шаги: Открыть главную, нажать Tab, нет видимой «Пропустить».
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Работает в NVDA/VoiceOver, покрыто SC 2.4.1.

Инклюзивный веб‑дизайн: контрастность

Контрастность, фундамент. Для обычного текста используйте минимум 4.5:1, для крупного текста (≥18pt или 14pt bold), 3:1. Включайте color contrast checkers на этапе дизайна и внедряйте палитры в дизайн‑систему, чтобы избежать ситуативных ошибок.

Учитывайте цветовую слепоту: проверяйте палитры на деутеранопию, протанопию, тританопию. В интерфейсах с финансовыми транзакциями (онлайн‑банк) мы дополнительно вводили иконки и текстовые подсказки, чтобы акцент не зависел только от цвета.

Контрастность текста и фона

Измеряйте и фиксируйте контраст прямо в макетах. В Figma помогает плагин Stark, в браузере, DevTools и расширение axe. Сохраните набор утвержденных токенов цвета в дизайн‑системе и автоматизируйте проверку при сборке.

@media (prefers-reduced-motion: reduce) {
  * { animation-duration: 0.01ms; animation-iteration-count: 1; transition:none; }
}

Чек‑лист

• Проверить контраст всех состояний кнопок/ссылок.
• Ограничить длину строки, настроить line-height.
• Использовать rem/em для масштабирования шрифта.
• Эмулировать дальтонизм (Stark/Sim Daltonism).
• Включить prefers-reduced-motion для анимаций.

Инструменты

• Stark (Figma): https://www.getstark.co
• TPGi CCA: https://www.tpgi.com/color-contrast-checker/

Шаблон product ticket

• Заголовок: Непроходной контраст вторичных ссылок
• Проблема: Цвет #8ea4c8 на белом дает ~2.7:1.
• Шаги: Проверка через CCA на карточке товара.
• Критичность: Высокая
• Приоритет: P1
• Критерии приемки: Контраст ≥ 4.5:1, обновлены токены в дизайн‑системе.

Типографика для слабовидящих

Рекомендации: базовый размер шрифта не менее 16px, на десктопе 18–20px для основного текста в B2C‑сценариях; line-height 1.5; интерлиньяж и межбуквенное: для заголовков аккуратно, без «сплющивания». Масштабирование шрифта до 200% не должно ломать сетку и важные CTA.

html { font-size: 100%; }
body { font-size: 1rem; line-height: 1.5; }
h1 { font-size: clamp(1.8rem, 2.5vw, 2.4rem); }

ARIA и semantic HTML для доступности

Я всегда рекомендую: сначала semantic HTML, потом ARIA. Нативные элементы: кнопки, ссылки, поля форм, уже содержат правильные роли и поведение. Если нужен кастомный компонент, добавляйте ARIA roles осторожно и только при необходимости.

Semantic landmarks (header, nav, main, footer) и заголовки h1–h6 создают логичную структуру для screen reader NVDA, JAWS, VoiceOver и TalkBack. Это ускоряет навигацию и снижает time on task.

Чек‑лист

• Проверить, где нативные элементы заменены div/span → вернуть native.
• Для динамики добавить aria-live, описать поведение.
• Добавить landmarks и корректные заголовки.
• Задокументировать ARIA в библиотеке компонентов.

Инструменты

• ARIA practices: https://www.w3.org/WAI/ARIA/apg/
• Landmarks guide: https://www.w3.org/WAI/tutorials/page-structure/

Шаблон product ticket

• Заголовок: Добавить aria-live для уведомлений «товар в корзине»
• Проблема: Скринридер молчит при добавлении товара.
• Шаги: NVDA + Firefox, «Добавить в корзину» → нет озвучивания.
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Сообщение читается NVDA/JAWS/VoiceOver.

Ошибки ARIA и антипаттерны

Частые ошибки: роль button на div без поведения клавиатуры; скрытие фокуса; aria-hidden на активных элементах; чрезмерное использование aria‑* там, где хватает native. Рекомендуется заменять role=»button» на , а если компонент кастомный, обеспечить Enter/Space и фокусируемость.

Код/сниппет (анти‑паттерн → исправление):

ОК

ОК

Навигация, фокус, доступ с клавиатуры

Клавиатурная навигация обязательна: порядок Tab логичен, фокус видим и контрастен, интерактивные элементы доступны через Enter/Space. Добавляйте skip links и управляйте фокусом в модалках и SPA‑сценариях, чтобы пользователь не терял контекст.

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

:focus { outline: 2px solid #0a84ff; outline-offset: 2px; }

Чек‑лист

• Полная навигация по клавиатуре, без ловушек фокуса.
• Видимый фокус на всех интерактивных элементах.
• Управление фокусом при открытии/закрытии модалок.
• Skip links, логичный порядок Tab.
• Тест в NVDA/VoiceOver, проверка с экранной лупой.

Инструменты

• NVDA: https://www.nvaccess.org
• JAWS: https://www.freedomscientific.com
• VoiceOver guide: https://support.apple.com/guide/voiceover
• TalkBack: https://support.google.com/accessibility/android

Шаблон product ticket

• Заголовок: Добавить управление фокусом в модальном окне оплаты
• Проблема: Фокус уходит под слой, клавиатурой оплату завершить сложно.
• Шаги: Открыть модалку, нажать Tab → фокус прыгает за пределы.
• Критичность: Высокая
• Приоритет: P1
• Критерии приемки: Фокус захватывается при открытии, возвращается на триггер при закрытии.

Кнопки и навигация для слабовидящих

Проектируйте кликабельные области 44×44px и больше, используйте понятные подписи и явные состояния наведения/активации. Ссылки должны выглядеть как ссылки, кнопки: как кнопки; смешение стилей затрудняет восприятие.

button, .btn, a.btn { min-width: 44px; min-height: 44px; }
a { text-decoration: underline; }
a:hover { text-decoration-thickness: 2px; }

alt, аудиоописание и субтитры

Alt‑текст должен передавать цель изображения в контексте. Декоративные изображения получают пустой alt=»». Информационные графики и SVG, с ролями и описаниями; сложные диаграммы — с развернутым текстовым описанием рядом или по ссылке.

Корректные alt‑атрибуты помогают поиску: изображения товаров с релевантными подписями улучшают видимость в image‑поиске и карточках.

Чек‑лист

• Alt по цели: информативный, короткий, без «изображение».
• Пустой alt для декоративных картинок.
• Длинные описания для сложных графиков.
• Субтитры/транскрипты для видео/аудио.
• Проверка озвучивания в NVDA/JAWS.

Инструменты

• W3C alt decision tree: https://www.w3.org/WAI/tutorials/images/decision-tree/
• YouTube/Subtitle tools, Amara: https://amara.org

Шаблон product ticket

• Заголовок: Добавить субтитры к видео «Оплата и доставка»
• Проблема: Нет субтитров, потеря контекста.
• Шаги: Открыть видео, выключить звук → информация недоступна.
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Субтитры и транскрипт опубликованы, проверены на синхронизацию.

Альтернативный текст для изображений

Правильно: alt=»Тонометр для запястья, модель X200, акция -15%». Неправильно: alt=»фото товара». Если изображение: кнопка или ссылка, alt/aria-label должны описывать действие: alt=»Добавить тонометр X200 в корзину». Для коллекций продуктов используйте единый шаблон alt, чтобы улучшить консистентность.

Формы и валидация для слабовидящих

Каждое поле: с label, связанной через for/id, или с aria-label, если label визуально скрыт. Ошибки форм описывайте текстом, связывайте через aria-describedby, озвучивайте через live region. Подсказывайте формат ввода заранее, а не постфактум.

Email

Мы отправим чек

Чек‑лист

• Везде есть labels и подсказки, связанные с полями.
• Ошибки читаются скринридером, явно подсвечены.
• Фокус переходит к первой ошибке.
• Альтернатива CAPTCHA без зрительных задач.
• Даты/телефоны: маски с подсказками формата.

Инструменты

• Inclusive forms: https://www.w3.org/WAI/tutorials/forms/
• GOV.UK Design System patterns: https://design-system.service.gov.uk

Шаблон product ticket

• Заголовок: Доступная валидация формы регистрации
• Проблема: Ошибки не озвучиваются, отсутствуют aria-describedby.
• Шаги: Оставить поле пустым → отправить → скринридер молчит.
• Критичность: Высокая
• Приоритет: P1
• Критерии приемки: Ошибки видимы/озвучены, фокус на первой ошибке.

Инструменты проверки доступности

Автоинструменты ловят до 30–40% проблем. axe‑core, Google Lighthouse, WAVE, Pa11y и Tenon.io обнаруживают явные нарушения: контраст, отсутствующие alt, неверные роли. Ручной аудит закрывает сценарии: логика навигации, управление фокусом, ожидаемое поведение ARIA.

Чек‑лист аудита

• Прогон Lighthouse Accessibility ≥ 90.
• WAVE/axe без критичных ошибок.
• Ручной проход по клавиатуре (без мыши).
• NVDA/VoiceOver: проверка важных сценариев.
• Отчет в виде remediation tickets.

pa11y https://example.com --threshold 0 --reporter json > pa11y.json

Инструменты

• Lighthouse: https://developers.google.com/web/tools/lighthouse
• axe-core: https://github.com/dequelabs/axe-core
• Pa11y: https://pa11y.org
• Tenon: https://tenon.io

Шаблон product ticket

• Заголовок: Исправить ошибки axe на странице корзины
• Проблема: 6 нарушений (контраст, aria-roles).
• Шаги: Запустить axe → сохранить отчет.
• Критичность: Высокая
• Приоритет: P1
• Критерии приемки: 0 критичных ошибок, 0 серьезных предупреждений.

Выбор инструментов аудита доступности

Смотрите на интеграцию в CI, покрытие SC, удобство отчетов и поддержку. Для мультисайтов полезен headless‑режим и экспорт в JSON/HTML. axe‑core CLI и Pa11y хорошо подходят для пайплайнов, WAVE, для быстрых ручных проверок, Lighthouse — для сводной оценки.

Тестирование с пониженным зрением

Рекрутинг участников проводите этично: компенсация времени, понятные инструкции, поддержка в ходе тестов. Ищите пользователей с дальтонизмом, низкой остротой зрения, тех, кто использует screen reader NVDA/JAWS, VoiceOver или TalkBack.

Анализируйте записи, метрики и комментарии, группируйте инсайты, переводите в product backlog с оценкой влияния.

Чек‑лист

• Определить профили участников и сценарии.
• Провести пилотную сессию, откалибровать сценарии.
• Тесты с NVDA/VoiceOver/TalkBack и экранными лупами.
• Собрать метрики и NPS, сформировать рекомендации.
• Конвертировать результаты в тикеты с приоритетами.

Инструменты

• ZoomText/Windows Magnifier
• Screen readers (ссылки выше)

Шаблон product ticket

• Заголовок: Улучшить навигацию в разделе «Акции»
• Проблема: Пользователи с лупой теряют контекст навигации.
• Шаги: Тест с лупой 200% на мобильном, поиск «Акции».
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Time on task ↓ на 20% в повторном тесте.

План внедрения, приоритизация и бюджет

Стратегия внедрения: discovery (цели, аудитория), аудит (авто + ручной), quick wins (контраст, фокус, alt, labels, skip links), sprint‑ремедиация (компоненты, формы, модалки), regression testing (CI). Приоритизируйте remediation tickets по влиянию на пользователей, сложности исправления и юридическим рискам.

Чек‑лист

• Утвердить scope AA и список страниц.
• Сформировать backlog и RICE‑оценку тикетов.
• Выделить бюджет CAPEX (аудит + фикс) и OPEX (регрессии).
• Назначить SLA на исправление критичных регрессий.
• Запланировать обучение команды.

:root { --focus-color: #0a84ff; --focus-width: 2px; }
:focus { outline: var(--focus-width) solid var(--focus-color); }

Инструменты

• RICE Prioritization: Intercom framework
• Jira/YouTrack шаблоны тикетов

Шаблон product ticket

• Заголовок: Включить фокус‑токены на уровне дизайн‑системы
• Проблема: Несогласованный фокус в компонентах.
• Шаги: Проверить Button, Link, Input в Storybook.
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Единый фокус в компонентах, покрытие Storybook.

План внедрения доступности на сайт

30 дней (малый сайт): аудит + quick wins + statement. 60 дней (средний): ремедиация компонентов, формы, навигация, автоматизация проверок. 90 дней (крупный): CI/CD, регрессии, пользовательские тесты, обновление дизайн‑системы и документации.

CI/CD и мониторинг регрессий

Интегрируйте accessibility тесты в pipeline: запуск Pa11y/axe-core CLI на ключевых маршрутах, падение сборки при критических нарушениях. Добавьте accessibility regression testing: скриншотные и DOM‑снимки, чтобы отслеживать контраст, атрибуты, роли.

- name: Pa11y audit
  run: pa11y-ci --config .pa11yci

Чек‑лист

• Настроить CI с порогами ошибок.
• Добавить маршруты для аудита (главная, поиск, корзина, checkout).
• Включить визуальные регресс‑тесты ключевых экранов.
• Обновить Definition of Done (WCAG AA).
• Вести публичный changelog доступности.

Инструменты

• pa11y-ci: https://github.com/pa11y/ci
• axe-core CLI: https://github.com/dequelabs/axe-core-npm

Шаблон product ticket

• Заголовок: Добавить pa11y-ci в GitHub Actions
• Проблема: Нет автоматической проверки доступности.
• Шаги: Настроить конфиг, добавить маршруты, пороги.
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: Пайплайн падает при критических нарушениях.

KPI и метрики доступности для конверсии

Измеряйте: task completion, time on task, conversion rate, снижение отказов, NPS. Связывайте метрики с воронкой: карточка товара → корзина → оплата (Нова Пошта + карта). Доступность повышает предсказуемость сценариев и снижает когнитивную нагрузку, что отражается на метриках.

Для отчетности используйте дашборды: KPI по WCAG‑состоянию (количество нарушений), продуктовые метрики, NPS для пользователей с assistive‑технологиями. Это создает общую картину для маркетинга и продукта.

Чек‑лист

• Определить базовые метрики и целевые значения.
• Настроить события для assistive‑паттернов (skip link click, zoom, prefers-reduced-motion).
• Завести дашборд с трендами по конверсии и отказам.
• Планировать A/B на контраст/фокус/формы.
• Согласовать формат ежемесячного отчета.

document.querySelector('.skip-link')
  ?.addEventListener('click', ()=>analytics.track('skip_link_used'));

Инструменты

• Amplitude/Mixpanel/ga4 события
• Looker/Data Studio для дашбордов

Шаблон product ticket

• Заголовок: Добавить трекинг событий доступности
• Проблема: Нет данных об использовании skip link и zoom.
• Шаги: Настроить события, проверить в отчете.
• Критичность: Низкая
• Приоритет: P3
• Критерии приемки: События в дашборде, сегменты сравнимы.

Шаблоны и чек-листы для старта

Готовые чек‑листы

• Дизайн: контраст 4.5:1, длина строки, line-height, дальтонизм.
• Разработка: semantic HTML, фокус, skip links, ARIA live.
• QA: клавиатурный проход, NVDA/VoiceOver, Lighthouse ≥ 90, WAVE/axe без критичных.

Ресурсы

• WebAIM: https://webaim.org
• W3C WAI Tutorials: https://www.w3.org/WAI/tutorials/

Чек‑лист

• Выбрать 1 кейс‑метрику для быстрого улучшения.
• Утвердить набор обязательных компонентов дизайн‑системы.
• Создать шаблоны тикетов по категориям проблем.
• Назначить ответственных по направлениям.

  Популярное
  Новинки

...

Шаблон product ticket

• Заголовок: Внедрить доступные табы в каталоге
• Проблема: Табы на div, навигация по клавишам отсутствует.
• Шаги: Проверить стрелки/Tab, скринридер не сообщает контекст.
• Критичность: Средняя
• Приоритет: P2
• Критерии приемки: ARIA roles, клавиши стрелок/Enter, озвучивание NVDA.

Заключение и призыв к действию

Я считаю, что доступность — дисциплина эффективности. В итоге вы получаете: больший охват, предсказуемую конверсию, устойчивую репутацию и комплаенс. Практика BUSINESS SITE показывает, что быстрые победы в контрасте, фокусе, формах и навигации приводят к измеримым результатам за один‑два спринта, а системный подход через дизайн‑систему и CI/CD закрепляет эффект.

Рекомендованные первые шаги: 1) провести комбинированный аудит (axe/Lighthouse + ручной), 2) закрыть quick wins на главных сценариях (каталог → корзина → оплата), 3) зафиксировать AA как целевой уровень и опубликовать accessibility statement. Для маркетинга это прозрачно: метрики и ROI, для разработки: понятный backlog, для руководства — управляемый риск и рост воронки.

Чек‑лист завершения

• Утвердить уровень AA и roadmap.
• Запустить аудит и закрыть quick wins.
• Настроить регресс‑тесты в CI.
• Опубликовать accessibility statement.
• Сформировать дашборд KPI.

Шаблон product ticket

• Заголовок: Опубликовать публичное accessibility statement
• Проблема: Отсутствует публичное обязательство и контакт.
• Шаги: Подготовить текст, добавить в footer, уведомить команду.
• Критичность: Низкая
• Приоритет: P3
• Критерии приемки: Страница доступна, содержит уровень, дату и контакт.

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

Чек‑лист

• Использовать Lighthouse/WAVE для первичного среза.
• Подключить axe‑core/Pa11y в CI.
• Согласовать пороги падения пайплайна.
• Запланировать обучающий воркшоп для команды.
• Добавить FAQ в внутренний портал.

Шаблон product ticket

• Заголовок: Подготовить воркшоп по доступности для команды
• Проблема: Недостаток компетенций, риск регрессий.
• Шаги: Сформировать программу, собрать примеры, назначить дату.
• Критичность: Низкая
• Приоритет: P3
• Критерии приемки: Проведено обучение, материалы доступны, вопросы собраны.

P.S. По моему опыту, когда доступность становится частью Definition of Done, маркетинг получает устойчивый прирост эффективности, продукт — управляемую воронку, а бренд — доверие. В BUSINESS SITE мы придерживаемся этой практики во всех проектах: от фарм‑e‑commerce до финтех‑сервисов и туристических порталов.