diff --git a/_articles/ru/accessibility-best-practices-for-your-project.md b/_articles/ru/accessibility-best-practices-for-your-project.md new file mode 100644 index 00000000000..ca5dc2adf6e --- /dev/null +++ b/_articles/ru/accessibility-best-practices-for-your-project.md @@ -0,0 +1,301 @@ +--- +lang: ru +title: Лучшие практики доступности для вашего проекта +description: Практичные и конкретные шаги, которые помогут сделать ваш открытый проект удобным для всех, особенно для людей с инвалидностью. +class: accessibility-best-practices +order: -1 +image: /assets/images/cards/accessibility-best-practices.png +--- + +Доступность (часто сокращаемая до _a11y_) означает, что люди могут пользоваться вашим проектом независимо от инвалидности, вспомогательных технологий, окружения или устройства. Она включает — но не ограничивается — поддержку программ чтения с экрана, навигацию только с клавиатуры, субтитры и текстовые расшифровки, достаточный цветовой контраст и понятную структуру контента. + +## Сотрудничайте с людьми с инвалидностью + +**«Ничего для нас без нас»** — самое важное, что вы можете сделать для доступности, — поставить в центр внимания людей, которым она служит. Пользователи, участники и тестировщики с инвалидностью понимают барьеры так, как не могут ни руководства, ни автоматические инструменты. Обращайтесь к их живому опыту как можно раньше и как можно чаще. + +### Как применить на практике + +Решения, принятые без участия тех, кого они затрагивают, обычно бьют мимо цели. Разработка вместе с людьми с инвалидностью, а не для них, приводит к лучшему программному обеспечению для всех. + +Вот несколько способов опереться на живой опыт: + +* Приглашайте участников с инвалидностью к обсуждению дизайна, а не только к разбору багов. +* По возможности привлекайте людей с инвалидностью к юзабилити-тестированию и сбору обратной связи. +* Слушайте, когда кто-то описывает, как он пользуется вашим проектом, даже если это ставит под сомнение ваши предположения. +* Относитесь к сообщениям о проблемах доступности как к экспертизе, а не как к жалобам — за ними может стоять больше людей, чем вы думаете. + +### Доступность приносит пользу всем + +* **Она затрагивает очень многих.** По оценке [Всемирной организации здравоохранения](https://www.who.int/news-room/fact-sheets/detail/disability-and-health), около 1,3 миллиарда человек (каждый шестой) имеют значительные нарушения здоровья. +* **Это часть качества.** Доступные продукты, как правило, удобнее для всех. +* **Она снижает нагрузку на поддержку.** Более понятный интерфейс и документация — меньше запутавшихся пользователей. +* **Она расширяет круг участников.** Пользователи вспомогательных технологий могут участвовать в проекте более полноценно. +* **Она стимулирует инновации.** Проектирование для разных потребностей часто приводит к возможностям, полезным всем (субтитры, голосовое управление и тёмная тема начинались как решения для доступности). +* **Она нередко обязательна.** Многие организации (и некоторые государства) требуют доступности при закупках и для соответствия нормативам. +* **Наше будущее неопределённо.** Никто сегодня не может быть уверен в том, какие возможности у него будут завтра. + +## Начните с заявления о доступности + +Прежде чем погружаться в код, потратьте минуту на то, чтобы задокументировать обязательства вашего проекта в области доступности. Заявление о доступности сигнализирует пользователям и участникам, что доступность — это приоритет, а не запоздалая мысль. В качестве руководства обратитесь к [документу W3C «Developing an Accessibility Statement»](https://www.w3.org/WAI/planning/statements/). + +Добавьте ясное заявление, которое задаёт ожидания и позволяет пользователям легко сообщать о проблемах. Вы можете либо добавить раздел о доступности прямо в README, либо создать отдельный файл **ACCESSIBILITY.md** и дать на него ссылку из README для заметности. Посмотрите этот [пример ACCESSIBILITY.md](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/ACCESSIBILITY.md). + +### Цели + +* Сформулируйте измеримые цели и ориентиры (например, [WCAG AA](https://www.w3.org/TR/WCAG22/#wcag-2-layers-of-guidance), где это осуществимо). +* Определите основные приоритеты и то, как вы их выполняете (поддержка клавиатуры и программ чтения с экрана, субтитры и расшифровки и т. д.). +* Опишите известные ограничения и альтернативные обходные пути (если они есть). + +### Требования к участникам + +Установите ясные правила, чтобы участники знали, чего от них ждут: + +* **Тестирование:** все изменения интерфейса должны проверяться инструментом тестирования доступности (например, [Axe DevTools](https://www.deque.com/axe/devtools/extension/#:~:text=Try%20Axe%20DevTools%20Extension%20in%20your%20browser%20of%20choice)). +* **Документация:** следуйте принятым в проекте правилам доступности для таких компонентов, как SVG, изображения и интерактивные элементы. +* **CI/CD:** пулреквесты не пройдут проверку, если внесут нарушения, обнаруженные автоматической проверкой доступности. + +### Поддерживаемые окружения + +* Перечислите платформы, которые вы поддерживаете (веб, мобильный веб, iOS, Android, терминал/CLI, настольные приложения). +* Отметьте случаи частичной поддержки. + +### Сообщения об ошибках доступности + +* Просите авторов сообщений создавать задачи по шаблону для проблем доступности. +* **Совет:** честно задавайте ожидания (например, «Мы работаем над этим — отслеживается в ISSUE-123»); подтверждайте получение сообщений и по возможности сообщайте о продвижении или обходном пути. + +#### Почему стоит отделить доступность от общего процесса работы с задачами? + +Пользователи привыкли ожидать отдельного заявления о доступности и отдельного пути для сообщений о проблемах — это устоявшаяся практика в частном секторе и на государственных сайтах, и многие ищут её в первую очередь, столкнувшись с барьером. Держать доступность отдельно от общего потока задач важно, потому что: + +* **Время имеет значение.** Ошибка доступности может полностью лишить человека возможности пользоваться вашим проектом, а не просто причинить неудобство. Отдельный путь помогает быстрее разбирать такие сообщения. +* **Контекст другой.** Для проблем доступности нужна специфическая информация (вспомогательная технология, ОС, браузер, серьёзность), которую обычный шаблон бага не запрашивает. +* **Это демонстрирует приверженность.** Заметное отдельное заявление говорит пользователям и участникам, что доступность — первоклассный приоритет, а не что-то, растворённое в «прочих багах». +* **Автор сообщения может сам пользоваться вспомогательными технологиями, чтобы его отправить.** Понятный, предсказуемый процесс (известный файл, известная метка, известный шаблон) снижает трение для тех, кого проблема затрагивает сильнее всего. + +## Делайте документацию доступной по умолчанию + +Документация — часто первый «интерфейс», с которым сталкиваются пользователи. Убедитесь, что читать её могут все. + +### Структура и семантика + +* Используйте **логичную иерархию заголовков** и не пропускайте уровни (`#`, `##`, `###`, `####`, `#####` и `######`). +* Используйте **уникальный, содержательный текст ссылок** («Прочитайте руководство для участников» вместо «нажмите сюда»). +* Пишите простым языком, избегайте жаргона и расшифровывайте каждую аббревиатуру при первом употреблении. +* [Используйте **настоящие списки**](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#lists) вместо нумерации, набранной вручную. +* Держите **справку и навигацию в одних и тех же местах** на всех страницах, чтобы их можно было предсказуемо найти. +* Не передавайте смысл только через положение или оформление («см. красный текст справа»). + +### Изображения, диаграммы и видео + +* Добавляйте осмысленный **альтернативный текст** (часто сокращаемый до «alt text») к изображениям (см. [alt Decision Tree от W3C](https://www.w3.org/WAI/tutorials/images/decision-tree/)). +* Вместо изображений с текстом по возможности используйте настоящий текст. +* Для сложных изображений (например, архитектурных диаграмм) добавляйте рядом дополнительную **текстовую альтернативу** (список тезисов или краткое объяснение). +* Если вы публикуете демо, обучающие материалы, доклады или видео о релизах: + * Добавляйте **субтитры** (предпочтительно отредактированные человеком). + * Добавляйте **текстовую расшифровку**. + * Избегайте автоматического воспроизведения аудио и видео. + * Проговаривайте вслух важные действия, происходящие на экране. + +### Таблицы + +* Используйте таблицы только для табличных данных, а не для вёрстки. +* Задавайте **ячейки-заголовки**, чтобы связать заголовки столбцов и строк с ячейками данных. +* Добавляйте **подпись или краткое описание** назначения таблицы. + +### Блоки кода + +* Держите строки достаточно короткими (перенос помогает читабельности). +* Не полагайтесь только на цветовую подсветку для передачи смысла. +* Поясняйте по ходу, что делает код и как выглядит успешный результат. + +## Проектируйте доступные интерфейсы + +Если у вашего проекта есть веб-интерфейс, эти простые правила с большой отдачей помогут всем пользователям. + +### Поддержка клавиатуры + +* Всё интерактивное должно быть достижимо и управляемо **только с клавиатуры**. +* Обеспечьте **видимый индикатор фокуса** (не убирайте обводку фокуса, если не заменяете её чем-то другим). +* Поддерживайте логичный **порядок перехода по Tab**, соответствующий визуальной раскладке. +* Не запирайте фокус внутри компонентов, кроме случаев, когда вы намеренно управляете фокусом (например, в модальных диалогах) и даёте способ выйти. + +### Сначала семантика + +* Используйте **нативные HTML-элементы** (`

`, `