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

Сотрудничайте с людьми с инвалидностью

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

Как применить на практике

Решения, принятые без участия тех, кого они затрагивают, обычно бьют мимо цели. Разработка вместе с людьми с инвалидностью, а не для них, приводит к лучшему программному обеспечению для всех.

Вот несколько способов опереться на живой опыт:

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

Доступность приносит пользу всем

  • Она затрагивает очень многих. По оценке Всемирной организации здравоохранения, около 1,3 миллиарда человек (каждый шестой) имеют значительные нарушения здоровья.
  • Это часть качества. Доступные продукты, как правило, удобнее для всех.
  • Она снижает нагрузку на поддержку. Более понятный интерфейс и документация — меньше запутавшихся пользователей.
  • Она расширяет круг участников. Пользователи вспомогательных технологий могут участвовать в проекте более полноценно.
  • Она стимулирует инновации. Проектирование для разных потребностей часто приводит к возможностям, полезным всем (субтитры, голосовое управление и тёмная тема начинались как решения для доступности).
  • Она нередко обязательна. Многие организации (и некоторые государства) требуют доступности при закупках и для соответствия нормативам.
  • Наше будущее неопределённо. Никто сегодня не может быть уверен в том, какие возможности у него будут завтра.

Начните с заявления о доступности

Прежде чем погружаться в код, потратьте минуту на то, чтобы задокументировать обязательства вашего проекта в области доступности. Заявление о доступности сигнализирует пользователям и участникам, что доступность — это приоритет, а не запоздалая мысль. В качестве руководства обратитесь к документу W3C «Developing an Accessibility Statement».

Добавьте ясное заявление, которое задаёт ожидания и позволяет пользователям легко сообщать о проблемах. Вы можете либо добавить раздел о доступности прямо в README, либо создать отдельный файл ACCESSIBILITY.md и дать на него ссылку из README для заметности. Посмотрите этот пример ACCESSIBILITY.md.

Цели

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

Требования к участникам

Установите ясные правила, чтобы участники знали, чего от них ждут:

  • Тестирование: все изменения интерфейса должны проверяться инструментом тестирования доступности (например, Axe DevTools).
  • Документация: следуйте принятым в проекте правилам доступности для таких компонентов, как SVG, изображения и интерактивные элементы.
  • CI/CD: пулреквесты не пройдут проверку, если внесут нарушения, обнаруженные автоматической проверкой доступности.

Поддерживаемые окружения

  • Перечислите платформы, которые вы поддерживаете (веб, мобильный веб, iOS, Android, терминал/CLI, настольные приложения).
  • Отметьте случаи частичной поддержки.

Сообщения об ошибках доступности

  • Просите авторов сообщений создавать задачи по шаблону для проблем доступности.
  • Совет: честно задавайте ожидания (например, «Мы работаем над этим — отслеживается в ISSUE-123»); подтверждайте получение сообщений и по возможности сообщайте о продвижении или обходном пути.

Почему стоит отделить доступность от общего процесса работы с задачами?

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

  • Время имеет значение. Ошибка доступности может полностью лишить человека возможности пользоваться вашим проектом, а не просто причинить неудобство. Отдельный путь помогает быстрее разбирать такие сообщения.
  • Контекст другой. Для проблем доступности нужна специфическая информация (вспомогательная технология, ОС, браузер, серьёзность), которую обычный шаблон бага не запрашивает.
  • Это демонстрирует приверженность. Заметное отдельное заявление говорит пользователям и участникам, что доступность — первоклассный приоритет, а не что-то, растворённое в «прочих багах».
  • Автор сообщения может сам пользоваться вспомогательными технологиями, чтобы его отправить. Понятный, предсказуемый процесс (известный файл, известная метка, известный шаблон) снижает трение для тех, кого проблема затрагивает сильнее всего.

Делайте документацию доступной по умолчанию

Документация — часто первый «интерфейс», с которым сталкиваются пользователи. Убедитесь, что читать её могут все.

Структура и семантика

  • Используйте логичную иерархию заголовков и не пропускайте уровни (#, ##, ###, ####, ##### и ######).
  • Используйте уникальный, содержательный текст ссылок («Прочитайте руководство для участников» вместо «нажмите сюда»).
  • Пишите простым языком, избегайте жаргона и расшифровывайте каждую аббревиатуру при первом употреблении.
  • Используйте настоящие списки вместо нумерации, набранной вручную.
  • Держите справку и навигацию в одних и тех же местах на всех страницах, чтобы их можно было предсказуемо найти.
  • Не передавайте смысл только через положение или оформление («см. красный текст справа»).

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

  • Добавляйте осмысленный альтернативный текст (часто сокращаемый до «alt text») к изображениям (см. alt Decision Tree от W3C).
  • Вместо изображений с текстом по возможности используйте настоящий текст.
  • Для сложных изображений (например, архитектурных диаграмм) добавляйте рядом дополнительную текстовую альтернативу (список тезисов или краткое объяснение).
  • Если вы публикуете демо, обучающие материалы, доклады или видео о релизах:
    • Добавляйте субтитры (предпочтительно отредактированные человеком).
    • Добавляйте текстовую расшифровку.
    • Избегайте автоматического воспроизведения аудио и видео.
    • Проговаривайте вслух важные действия, происходящие на экране.

Таблицы

  • Используйте таблицы только для табличных данных, а не для вёрстки.
  • Задавайте ячейки-заголовки, чтобы связать заголовки столбцов и строк с ячейками данных.
  • Добавляйте подпись или краткое описание назначения таблицы.

Блоки кода

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

Проектируйте доступные интерфейсы

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

Поддержка клавиатуры

  • Всё интерактивное должно быть достижимо и управляемо только с клавиатуры.
  • Обеспечьте видимый индикатор фокуса (не убирайте обводку фокуса, если не заменяете её чем-то другим).
  • Поддерживайте логичный порядок перехода по Tab, соответствующий визуальной раскладке.
  • Не запирайте фокус внутри компонентов, кроме случаев, когда вы намеренно управляете фокусом (например, в модальных диалогах) и даёте способ выйти.

Сначала семантика

  • Используйте нативные HTML-элементы (<h1>, <button>, <a>, <input>, <label>), когда это возможно.
  • Используйте ARIA только тогда, когда нативного HTML недостаточно. Отсутствие ARIA лучше, чем плохой ARIA. Если всё же используете, следуйте документации Accessible Rich Internet Applications (ARIA) и убедитесь, что все интерактивные ARIA-элементы доступны с клавиатуры.
  • Объявляйте язык документа (например, lang="ru" в HTML) и размечайте фрагменты на другом языке.

Имена, подписи, инструкции

  • Каждому элементу формы нужна связанная с ним подпись (label).
  • Пишите понятные сообщения об ошибках, указывайте, в каком поле ошибка, и программно связывайте сообщение с полем (например, через aria-describedby).
  • Для обязательных полей описывайте требования текстом (а не только звёздочкой).

Цвет и контраст

  • Не используйте цвет как единственный способ передать смысл («ошибки красные»).
  • Обеспечьте достаточный контраст для текста, значков и элементов управления (см. Contrast Checker от WebAIM).

Движение и анимация

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

Динамический контент

Когда контент обновляется без перезагрузки страницы, позаботьтесь о том, чтобы пользователи вспомогательных технологий узнали об этом:

  • Умеренно используйте подходящие ARIA live regions для объявлений.
  • Управляйте фокусом при открытии и закрытии диалогов, меню и выдвижных панелей.

Зависимости и паттерны

  • Используйте библиотеки компонентов с документированной поддержкой доступности.
  • Отслеживайте баги доступности в зависимостях и давайте на них ссылки в своих задачах.
  • Будьте осторожны с самодельными элементами управления. Нативные элементы (такие как <button>, <select>, <input type="checkbox">, <details>) идут в комплекте со встроенной поддержкой клавиатуры, управлением фокусом, семантикой для программ чтения с экрана и интеграцией с формами, которые браузеры и вспомогательные технологии уже понимают. Воссоздавать это поведение в собственных компонентах долго, легко ошибиться, и это добавляет затраты на сопровождение по мере развития платформ и вспомогательных технологий. Беритесь за собственные элементы управления только тогда, когда нативный элемент действительно не может решить задачу.

Особенности мобильных устройств

  • Делайте области касания размером не менее 24×24 CSS-пикселей.
  • Предусматривайте альтернативы одним указателем для мультитач-жестов и жестов по траектории (щипок, свайп).
  • Предлагайте альтернативы перетаскиванию (кнопки, меню).
  • Не ограничивайте контент одной ориентацией экрана, если только показываемому контенту не нужна конкретная ориентация.
  • Предусматривайте альтернативы для функций, запускаемых движением устройства (например, встряхнуть для отмены).

Делайте инструменты доступными

Инструменты командной строки и панели мониторинга могут быть весьма доступными, если продуманно их спроектировать.

CLI-инструменты

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

  • Поддерживайте --help с понятными примерами использования.
  • Предоставляйте варианты машиночитаемого вывода (например, --json) для пользователей, которым трудно разбирать таблицы.
  • Не полагайтесь только на цвета ANSI для обозначения успеха или неудачи; добавляйте текстовые метки и коды выхода.
  • Пишите сообщения об ошибках, которые:
    • объясняют, что произошло,
    • показывают, как это исправить, и
    • при необходимости ссылаются на документацию.
  • Используйте стандартные коды выхода и возвращайте ненулевой код при неудаче.

Терминалы, логи и панели мониторинга

  • Предпочитайте простой язык жаргону.
  • Избегайте аббревиатур без объяснения.
  • Используйте единообразное форматирование для уровней серьёзности (ERROR, WARN, INFO) и добавляйте отметки времени, когда это полезно.
  • Убедитесь, что «статус» не передаётся только цветом.

Встраивайте доступность в процессы участия

Доступность легче поддерживать, когда она — часть вашего обычного процесса.

Добавьте метки и шаблон для задач

  • Создайте метку для доступности (например, «accessibility» или «a11y»).
  • Создайте шаблон задачи о доступности, включающий:
    • метку accessibility;
    • ожидаемое и фактическое поведение;
    • шаги воспроизведения (в том числе, по желанию, запись экрана);
    • использованные инструменты (ОС, браузер, вспомогательная технология и её версия);
    • шкалу серьёзности, помогающую расставлять приоритеты:
      • Критическая: не даёт пользователю выполнить ключевую задачу (например, «Невозможно оформить заказ»).
      • Высокая: значительные трудности, но обходной путь существует.
      • Средняя: раздражающая или непоследовательная работа.
      • Низкая: незначительная проблема с минимальным влиянием на удобство.
    • контакты или порядок эскалации, если это уместно.

Посмотрите этот пример шаблона задачи о доступности.

Добавьте чек-лист доступности в пулреквесты (PR)

Для проектов с изменениями интерфейса включите такие пункты:

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

Посмотрите этот пример шаблона PR.

Определите, что значит «готово»

Добавьте критерии приёмки по доступности для новых возможностей и исправлений, чтобы она не была чем-то необязательным или оставленным на последний момент.

Используйте GitHub Copilot

Обрабатывайте сообщения о проблемах доступности уважительно и эффективно

Проблемы доступности часто трудно описать, трудно воспроизвести, а для автора сообщения от них зависит сама возможность пользоваться вашим проектом. Работая с такими сообщениями:

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

Тестируйте доступность непрерывно

Автоматические инструменты ловят регрессии, но настоящую уверенность даёт ручное тестирование.

Автоматические проверки (хорошо ловят регрессии)

  • Линтинг доступности в коде интерфейса.
  • Автоматическое сканирование в CI на типичные нарушения WCAG (например, GitHub Accessibility Scanner).
  • Модульные и интеграционные тесты, проверяющие роли и имена ключевых компонентов.

Ручное тестирование (обязательно для настоящей уверенности)

  • Проход только с клавиатуры: можете ли вы пройти основные сценарии без мыши?
  • Выборочная проверка программой чтения с экрана:
    • macOS: VoiceOver
    • Windows: NVDA (распространена в open source), JAWS (корпоративный сегмент)
  • Масштабирование и перекомпоновка: тестируйте при 200% и на узких экранах.
  • Режимы высокой контрастности / принудительных цветов, где применимо.

Совет: добавьте лёгкий раздел «Смоук-тест доступности» в чек-лист релиза.

Начните с маленьких побед на этой неделе

Не обязательно делать всё сразу — начните с нескольких быстрых улучшений.

Выберите несколько пунктов:

  • Добавьте ACCESSIBILITY.md и метку доступности (например, «accessibility» или «a11y»)
  • Убедитесь, что каждый интерактивный элемент достижим с клавиатуры
  • Исправьте отсутствующие подписи у полей форм
  • Объявите язык документа (например, lang="ru" в HTML) и разметьте фрагменты на другом языке
  • Добавьте альтернативный текст и структуру заголовков в README и документацию
  • Добавьте в чек-лист PR пункт про клавиатуру и фокус
  • Добавьте субтитры и расшифровку к самому популярному видео
  • Добавьте вывод --json к команде CLI

Файлы, которые помогут формализовать ваши обязательства по доступности.

Подумайте о добавлении в репозиторий:

Дополнительные примеры — в этом проекте.

Заключение: несколько шагов для вас — огромное улучшение для ваших пользователей

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

Доступность — это не разовое исправление, а постоянная практика, и не обязательно делать всё сразу. Начните с навигации с клавиатуры и семантики, вносите небольшие изменения и просите о ревью пораньше.

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

Благодарности

Большое спасибо всем мейнтейнерам, которые поделились с нами своим опытом и советами для этого руководства!

Это руководство написал(а) @mlama007 при участии: @ericwbailey, @andyfeller, @mgifford, @smockle и @weboverhauls