Как сделать сайты доступными — Полное руководство

Все, что вам нужно знать о специальных возможностях, см. в статье Доступность в Интернете — все, что вам нужно знать, на Programming Duck.

Отказ от ответственности: я не юрист. Эта статья представляет только мое личное мнение и текущее понимание. Это не юридическая консультация. Обратитесь к юристу за информацией о правовых аспектах доступности.

Обеспечение доступности вашего веб-сайта не должно быть трудным. Немного усилий могут помочь вам в вашей повседневной работе.

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

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

Узнайте о ваших юридических требованиях к доступности
Используйте семантический HTML
Часто проверяйте контрольные списки специальных возможностей, чтобы убедиться, что вы правильно применяете специальные возможности в своей работе.
Проверьте доступность вашего веб-сайта, чтобы убедиться, что вы делаете это правильно

По желанию вы также можете:

Сделайте доступность частью стандартов и процесса разработки
Расскажите людям о доступности
Наймите специалистов, если вам нужна дополнительная помощь

Вот более подробная информация о каждой части процесса.

Правовые требования

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

В целом, для большинства компаний вы должны соответствовать стандартам доступности WCAG 2.1 (или, что более вероятно, последней опубликованной версии) уровня AA. Уровень А, вероятно, недостаточен. Уровень АА является стандартным. Уровень ААА является «желательным». Как правило, это не является обязательным требованием закона, однако это здорово, если вы можете.

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

Используйте семантический HTML

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

Используйте полезные контрольные списки

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

Контрольный список WebAIM WCAG

Контрольный список WebAIM WCAG содержит отличные рекомендации о наиболее важных вещах, которые вы можете сделать для обеспечения доступности. Это один из самых простых контрольных списков в этом разделе. В результате, к нему можно часто обращаться в большинстве случаев.

Авторские практики WAI-ARIA

Методы разработки WAI-ARIA предоставляют рекомендации для пользовательских виджетов, созданных с помощью JavaScript (таких вещей, как аккордеоны, настраиваемые раскрывающиеся списки и т. д.). Следование этим рекомендациям очень важно для доступности этих виджетов. Поэтому я рекомендую всегда обращаться к этому ресурсу всякий раз, когда вы работаете над чем-то подобным.

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

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

ВКАГ

WCAG включает официальную спецификацию, которая упоминается в юридических требованиях. Чтобы быть на 100% совместимым, вы должны проверить это.

Однако с этим ресурсом работать сложнее, чем с другими. По этой причине вам может быть проще работать с ресурсом WebAIM в вашей повседневной работе. Затем вы можете проверить этот ресурс, когда захотите провести более полный аудит доступности.

Частота использования чек-листов

Что касается частоты использования этих контрольных списков, у вас есть разные варианты. Ты сможешь:

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

Контрольная работа

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

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

Ручные тесты

Вот некоторые вещи, которые вы должны рассмотреть при тестировании вручную.

Увеличить

Проверьте, как выглядит ваш веб-сайт, когда вы используете масштабирование в браузере. Стандарт WCAG в настоящее время требует, чтобы ваша страница была читаемой и функциональной при увеличении 200%. Тем не менее, не стесняйтесь тестировать выше этого.

Попробуйте также протестировать свой веб-сайт с масштабированием на уровне ОС (настройка масштабирования, применяемая в настройках вашей операционной системы).

Попробуйте также протестировать свой веб-сайт с помощью такого приложения, как ZoomText.

Программы чтения с экрана

Проверьте свой сайт с помощью программы чтения с экрана.

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

Mac или iOS с VoiceOver и Safari
Windows с Jaws или NVDA
ChromeOS с ChromeVox и Chrome
Android с включенными специальными возможностями и Chrome
Линукс с Оркой

Клавиатурная навигация и интерактивность

Проверьте навигацию с помощью клавиатуры и интерактивность вашего веб-сайта. Обратите особое внимание на вещи, которые работают с JavaScript, такие как пользовательские виджеты, модальные окна и т. д.

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

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

Недостатки зрения

В некоторых браузерах есть симулятор дефицита зрения. Если вы используете Chrome, вот учебник Энди Османи по симулятору слабовидящих в Chrome. Вот статья по использованию симулятора цветового зрения в Firefox.

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

Структура документа

Структура документа относится к заголовкам веб-страницы. В частности, это относится к их уровню заголовков и их порядку.

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

Например, это нормально:

<h1>h1</h1>
<h2>h2</h2>
<h2>h2</h2>
<h3>h3</h3>

Однако следующее не подходит, потому что оно пропускает/перескакивает с h2 на h4:

<h1>h1</h1>
<h2>h2</h2>
<h4>h4</h4>
<h2>h2</h4>

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

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

Вот несколько инструментов, которые вы можете использовать для тестирования доступности.

Сторонние сервисы/анализаторы:

"Шип"

Инструменты тестирования страницы:

Инструменты разработчика Chrome:
- Вкладка «Доступность»
- Вкладка Рендеринг - › Симулятор дефектов зрения
- Маяк
Расширения браузера:
"- ВОЛНА"
- Аутлайнер
- Топор
- Тота11й

Инструменты сборки:

Также рассмотрите линтеры кода специальных возможностей для технологий, с которыми вы работаете. Одним из примеров является eslint-plugin-jsx-a11y для JSX.

Модульные, интеграционные и сквозные тесты на доступность

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

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

Сделайте доступность стандартом и частью процесса разработки

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

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

Вы можете заявить в своих стандартах, что доступность важна и что ожидается, что вся работа будет соответствовать спецификации WCAG 2.1 AA или, по крайней мере, рекомендациям WebAIM и рекомендациям по практике разработки ARIA.

Вы также можете сделать это частью процесса разработки:

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

Обучайте людей, чья работа заканчивается на переднем крае

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

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

По этой причине разработчикам интерфейса может быть полезно обучать их.

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

Наймите сторонних консультантов по доступности

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

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

Резюме

Работа с доступностью не должна быть сложной.

Вот простой процесс, который вы можете использовать:

Узнайте о ваших юридических требованиях к доступности
Используйте семантический HTML
Часто проверяйте контрольные списки специальных возможностей, чтобы убедиться, что вы правильно применяете специальные возможности в своей работе.
Проверьте доступность вашего веб-сайта, чтобы убедиться, что вы делаете это правильно