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

Мысли и философия о том, как настроить рабочий процесс вашей команды для решения проблем доступности

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

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

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

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

Включение доступности в вашу методологию TDD связано с простой философией: Проблемы доступности - это ошибки.

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

1. Добавьте измеримые цели доступности в свою дорожную карту

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

Конечной целью может быть конкретное соответствие WCAG или оценка доступности Lighthouse с промежуточными целями, такими как полное соответствие вашей дизайн-системы:

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

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

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

Не забывайте: соответствие WCAG похоже на соблюдение HIPAA, оно никогда не заканчивается! Не переставайте заботиться о доступности, когда вы достигнете желаемого уровня соответствия, продолжайте включать и учитывать это в своем рабочем процессе.

2. Добавляйте линтеры в свою кодовую базу

Линтеры решают только 20–25% всех проблем с доступностью, но это только начало. Любой тип автоматизации, который вы можете использовать, очень поможет вам в начале вашего пути к доступности. Вот что мы специально сделали с нашими:

1. Мы добавили eslint-plugin-jsx-a11y в нашу кодовую базу React и написали небольшой скрипт узла, который запускал его для каждого файла, генерируя билет JIRA для каждой проблемы. Мы присвоили каждой заявке приоритет в зависимости от типа правила lint и делегировали их по частям так же, как мы сортируем другие ошибки продукта.
2. Используя хаски, мы запустили eslint как часть нашего хука git перед фиксацией. Мы сделали так, чтобы плагин a11y работал только с новыми добавленными файлами, так как остальные были задокументированы в JIRA, начиная с шага 1. Таким образом мы могли гарантировать, что новый код будет хотя бы минимально соответствовать стандартам линтера доступности.
3. Наша структура непрерывной интеграции запускала ее в каждой ветке, разрешая слияния только в том случае, если она была пройдена. Таким образом, если кто-то обойдет ловушку перед фиксацией, мы все равно будем гарантировать, что наша основная ветвь не получит свежий недоступный код.

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

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

3. Широко распределять ресурсы для развития образования.

Это может быть страшно, когда вашей команде будет поручено 200 ошибок JIRA, не зная, как их исправить. Поэтому мы сделали приоритетным обучение доступности, доступное для всех в компании (хар-хар).

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

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

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

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

Наша компания была разделена на функциональные области с несколькими инженерами и дизайнерами в каждой функциональной группе. Мы попросили каждую команду назначить одного фронтенд-инженера в качестве «защитника доступности» в своей команде и присоединиться к нашей Рабочей группе по цифровой доступности (DAWG).

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

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

5. Измените свое мышление развития, включив в него

Работая над интерфейсом, вы часто будете проверять консоль браузера на наличие ошибок во время разработки. Ошибки должны заставлять ваше сердце немного подпрыгивать, пока вы развиваетесь; какие? Я где-то забыл ключ React? Черт возьми, только не снова!

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

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

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