Автоматизируйте и больше никогда не сталкивайтесь с проблемами доступности в производстве.

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

Давайте сделаем следующий шаг и посмотрим, что мы можем сделать, чтобы сделать ваш сайт лучше. Конечно, вы можете прочитать Руководство по доступности веб-контента (WCAG) и исправить найденные проблемы, но мы программисты или нет?

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

WAVE

WAVE, разработанный компанией WebAim, представляет собой набор инструментов для оценки доступности веб-контента для людей с ограниченными возможностями. Он визуально представляет проблемы доступности в пределах веб-страницы и явно охватывает проблемы доступности изображений, заголовков, меток и цветового контраста. Введите URL-адрес онлайн, установите расширение для браузера или воспользуйтесь API-сервисом.

AChecker

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

Инструменты разработчика Google для обеспечения доступности

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

Tanaguru

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

Pa11y

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

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

Какой инструмент выбрать?

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

Установка PA11y проста. Просто выполните одну команду в вашем окружении node:
npm, install -g pa11y.

Из коробки Pa11y предоставляет все необходимое. Вы можете проверить локальный файл, используя pa11y ./path/to/your/file.html. Или запустить аудит по умолчанию с помощью одной команды pa11y http://example.com. Вы можете скомпилировать файл .CSV, используя флаг --reporter или выбрать внутренний отчет, который будет распечатан на экране.

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

Поначалу отчет может быть немного сложным для понимания, но вы привыкнете к нему. Например, если в списке ошибок указано «WCAG2AA.Principle1.Guideline1_1.1_1_1_1.H37», то ошибка в руководстве — это WCAG 2.0 AA Principle 1, Guideline 1.1, Success Criterion 1.1.1.

Это хорошо для начала, но очевидно, что вручную вы его не запустите, особенно на огромных сайтах. Поэтому пришло время для инструмента номер два, Pa11y-CI. Как следует из названия, Pa11y-CI пригодится при работе с непрерывной интеграцией. Созданный на основе Pa11y, он запускает тесты доступности по нескольким URL. Вы можете запускать его автоматически на всех ваших сайтах на каждом PR, прежде чем они будут объединены, гарантируя, что никакие ошибки доступности не попадут в продакшн.

Вы можете найти более подробную информацию о процессе интеграции Pa11y, если готовы приступить к практике. Я считаю, что эта статья охватывает практически все, что нам нужно на этом этапе: https://webdesign.tutsplus.com/tutorials/web-accessibility-testing-via-the-command-line-with-pa11y—cms-34538.

Однако при первом запуске вы, вероятно, получите много ошибок, поэтому включать его сразу на полную мощность и застрять в ситуации, когда никто не сможет объединить свои PR, может быть не очень хорошей идеей. Поэтому вы можете отключить его с помощью флага --threshold <number>, изначально установив количество ошибок, которое у вас есть на данный момент. Таким образом, вы по-прежнему сможете получать отчеты, но не будете увеличивать количество ошибок. И пока другие будут работать над своими задачами, вы сможете продолжать исправлять все проблемы с доступностью. Со временем вы уменьшите порог до нуля и больше никогда не будете иметь проблем с доступностью, отслеживаемых Pa11y в производстве.

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

Стоит отметить, что вы не должны работать над проблемой в одиночку. Расскажите коллегам о своей важной работе и вовлеките их в процесс. В противном случае вы навсегда застрянете на устранении проблем, в то время как другие будут продолжать их создавать. Поэтому поделитесь этой статьей, объясните, почему этот процесс является основополагающим, объясните, что означают ошибки и как думать о потенциальных проблемах до их появления. Отличным местом для начала обучения ваших коллег может стать бесплатный курс Udacity по веб-доступности: https://www.udacity.com/course/web-accessibility—ud891.

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

Поэтому, если вы еще не сделали этого, начните прямо сейчас с простых шагов и выключите свой трекпад.

Оцените статью
Procodings.ru
Добавить комментарий