Миф о недоступной реакции

Миф о недоступной реакции

В Twitter, Slack, Discord, IRC или где бы вы ни находились в Интернете, вы, возможно, слышали формулировки следующих утверждений:

• React не поддерживает доступность;
• React делает сайты недоступными;
• Люди должны писать доступный HTML вместо React;
• React разрушает Интернет.

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

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

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

Я расскажу, как можно объединить инструменты линтинга React, аудит DOM и Storybook (инструмент библиотеки компонентов), чтобы обеспечить действительно поддерживающую среду доступности для разработчиков - независимо от того, являются ли они профессионалами в области специальных возможностей или только начинающими.

К концу этой публикации у вас будет следующее настроено для вашего проекта Gatsby (или другого проекта React):

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

Хотите начать прямо сейчас? Я создал стартовый пакет Gatsby со всеми этими встроенными инструментами обеспечения доступности. Взгляните на мой репозиторий gatsby-starter-accessibility, в котором все эти функции доступны прямо из коробки.

Инструменты и настройка

Если вы писали JavaScript в течение последних нескольких лет, вы, вероятно, использовали или, по крайней мере, слышали о eslint. Если нет, то сейчас отличное время, чтобы начать с ним работать!

Eslint - это утилита линтинга для JavaScript, которая помогает выявлять ошибки форматирования и синтаксиса при написании кода. Большинство редакторов имеют встроенную конфигурацию линтинга, которая позволяет вам видеть ошибки в вашем редакторе во время написания кода.

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

Eslint также имеет действительно здоровую экосистему плагинов. Вы можете включить правила, специфичные для платформы JavaScript, с которой вы работаете (например, React, Angular, Vue и т. Д.), Среди прочего. Для React я обычно использую eslint-plugin-react и действительно полезный eslint-plugin-jsx-a11y. Этот плагин проверяет ваш код на известные нарушения доступности, используя эти правила.

Запуск этих автоматических тестов во время написания кода может предотвратить так много ошибок. Несмотря на то, что автоматическое тестирование доступности выявляет только 20–30% всех ошибок доступности, выявление этих ошибок до того, как они попадут в кодовую базу, может сэкономить время, бюджет и энергию для выполнения большего количества ручного тестирования, когда код находится в браузере.

использование

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

Во-первых, нам нужно установить необходимые пакеты eslint:

npm install eslint eslint-plugin-react eslint-plugin-jsx-a11y --save-dev

В вашем package.json добавьте следующую конфигурацию:

Когда это добавлено в ваш package.json, eslint будет использовать правила, рекомендованные eslint, react и плагином jsx-a11y, пока вы работаете.

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

Добавьте ловушку перед фиксацией для предотвращения недоступного кода в базе кода с помощью lint: staged

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

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

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

lint-staged запустит обработчик перед фиксацией, который перехватит любые ошибки доступности, вызванные eslint-plugin-jsx-a11y

использование

Самый простой способ настроить перехватчики линтинга перед фиксацией - использовать lint-staged package. После того, как вы настроили всю свою конфигурацию eslint (с нашего первого шага), выполните следующую команду в каталоге вашего проекта:

npx mrm lint-staged

Эта команда установит husky package для управления обработчиками перед фиксацией и заглянет в ваш package.json, чтобы автоматически настроить обработчик перед фиксацией на основе вашей конфигурации линтинга.

Простая конфигурация, которая связывает все файлы JS на основе существующей конфигурации eslint в репо, будет выглядеть следующим образом (из package.json):

Вы можете настроить это по своему усмотрению. Например, иногда вы хотите ограничить линтинг определенными каталогами. Чтобы запустить обработчик предварительной фиксации только для файлов JS в каталоге src, вы должны обновить конфигурацию lint-staged следующим образом:

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

реактивный топор

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

К счастью, у нас есть решение и для этого. Axe - это движок с открытым исходным кодом для автоматизированного тестирования доступности, поддерживаемый Deque. Я впервые познакомился с Axe, используя их действительно полезное расширение для браузера для тестирования отдельных страниц в браузере.

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

Библиотека react-ax - это простая в использовании реализация движка ax, специально для React.

использование

Вот как начать использовать react-ax с Gatsby (кто-то сделал для него плагин Gatsby!):

npm install --save gatsby-plugin-react-axe

Добавьте gatsby-plugin-react-axe в массив ваших плагинов в gatsby-config.js

Теперь, когда страница отображается, плагин выводит все ошибки доступности в консоль браузера. Вот пример, где я поместил <h5> прямо под <h1>:

React Axe будет показывать ошибки специальных возможностей в консоли во время разработки.

В сообщении Axe в консоли вы можете видеть, что он определил мою проблему с заголовком: Проблемы с заголовком должны увеличиваться только на один как умеренную проблему. Он также включает ссылку, чтобы узнать больше о том, почему возникла проблема и как ее решить: https://dequeuniversity.com/rules/axe/3.2/heading-order. И, наконец, он отображает конкретный элемент, вызывающий проблему, для облегчения идентификации.

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

Сборник рассказов и доступность

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

Storybook - это инструмент с открытым исходным кодом для разработки компонентов пользовательского интерфейса изолированно для React, Vue и Angular. Это делает создание потрясающих пользовательских интерфейсов организованным и эффективным.

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

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

Настраивать

Настройка Storybook немного сложнее, поэтому, если вы раньше не использовали Storybook, вы можете проверить документацию Storybook for React для общей настройки React.

Если вы хотите запустить Storybook с Gatsby, см. Визуальное тестирование с Storybook в документации Gatsby.

После настройки Storybook добавить надстройку специальных возможностей довольно просто.

Сначала установите надстройку:

npm install @storybook/addon-a11y --save-dev

Затем добавьте эту строку в свой addons.js файл в каталоге конфигурации сборника рассказов:

import '@storybook/addon-a11y/register';

И, наконец, добавьте эту строку в файл Storybook config.js, чтобы автоматически добавлять панель специальных возможностей ко всем компонентам:

addDecorator(withA11y);

Когда вы запустите Storybook сейчас, вы должны увидеть панель специальных возможностей (живую версию см. Здесь):

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

В качестве примечания: вы можете контролировать порядок вкладок на панели надстроек в зависимости от порядка, в котором надстройки импортируются в файл addons.js. Если вы хотите, чтобы панель специальных возможностей отображалась по умолчанию, убедитесь, что это первая строка в вашем addons.js.

Заворачивать

Если вы не выполняли установку или просто хотите быстро настроить новый проект с помощью этого рабочего процесса, воспользуйтесь gatsby-starter-accessibility Gatsby starter

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

npx gatsby new my-accessible-project https://github.com/benjamingrobertson/gatsby-starter-accessibility

Или вы можете проверить конкретную конфигурацию в репо.

Выполняете ли вы все вышеперечисленные шаги или просто запускаете программу для начинающих, в вашем проекте Gatsby / React будут настроены следующие функции:

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

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

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

Я знаю, что это помогло мне - надеюсь, это поможет и вашей команде!

Хотите глубже погрузиться в создание доступных веб-сайтов? Присоединяйтесь к моему бесплатному курсу электронной почты:
📨 Распространенные ошибки доступности и как их избежать. 30 дней, 10 уроков, 100% веселье! 😀 Зарегистрируйтесь!

Первоначально опубликовано на сайте benrobertson.io 13 июня 2019 г.