Автоматизированное тестирование доступности

До этого момента в курсе речь шла об индивидуальных, деловых и правовых сторонах цифровой доступности и об основах соответствия требованиям. Вы разобрали отдельные темы инклюзивного дизайна и кода: когда использовать ARIA, а когда HTML, как измерять контраст цвета, когда необходим JavaScript и другие вопросы.

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

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

За эталон мы берём уровни соответствия A и AA Web Content Accessibility Guidelines (WCAG) 2.1. Отрасль, тип продукта, местные и национальные законы и политики, а также общие цели по доступности определяют, каким рекомендациям следовать и какой уровень закрывать. Если для проекта не задан конкретный стандарт, рекомендуется последняя версия WCAG. Общие сведения об аудите доступности, типах и уровнях соответствия, WCAG и POUR — в модуле «Как измеряют цифровую доступность?».

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

Основы автоматизированного тестирования

Автоматизированное тестирование доступности — это проверка цифрового продукта программой на заранее заданные стандарты соответствия.

Плюсы автоматизированных тестов доступности:

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

Минусы автоматизированных тестов доступности:

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

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

Виды автоматических инструментов

Один из первых онлайн-инструментов автоматизированного тестирования доступности появился в 1996 году в Center for Applied Special Technology (CAST) и назывался «The Bobby Report». Сегодня на выбор есть больше 100 автоматических инструментов.

Реализация бывает разной: расширения браузера, линтеры кода, настольные и мобильные приложения, онлайн-панели и даже открытые API, на которых можно собрать собственный инструмент.

Какой инструмент выбрать, зависит от многих факторов:

• По каким стандартам и уровням соответствия вы проверяете? Это могут быть WCAG 2.1, WCAG 2.0, U.S. Section 508 или изменённый список правил доступности.
• Какой цифровой продукт вы проверяете? Сайт, веб-приложение, нативное мобильное приложение, PDF, киоск или что-то ещё.
• На каком этапе жизненного цикла разработки вы тестируете продукт?
• Сколько времени уходит на настройку и использование инструмента? Для одного человека, команды или компании?
• Кто проводит тест: дизайнеры, разработчики, QA и так далее?
• Как часто нужно проверять доступность? Какие подробности должны быть в отчёте? Нужно ли сразу связывать проблемы с системой задач?
• Какие инструменты лучше работают в вашей среде и у вашей команды?

Есть и другие соображения. Подробнее о выборе — в статье WAI «Selecting Web Accessibility Evaluation Tools».

Демонстрация: автоматизированный тест

Для демонстрации автоматизированного тестирования доступности мы используем Lighthouse в Chrome. Lighthouse — открытый автоматический инструмент. Он помогает улучшать качество веб-страниц аудитами разных типов: производительность, SEO и доступность.

Демонстрация — сайт вымышленной организации Medical Mysteries Club. Страница намеренно сделана недоступной. Часть проблем видна сразу, часть (но не все) поймает автоматический тест.

Шаг 1

В браузере Chrome установите расширение Lighthouse.

Встроить Lighthouse в процесс тестирования можно по-разному. В этой демонстрации мы используем расширение Chrome.

Шаг 2

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/amnpKDgfwnlIa02HYMU1.png", alt="Сайт Medical Mysteries Club вне iframe.", width="400", height="283" %}

Мы собрали демонстрацию в CodePen. Откройте её в режиме отладки, чтобы перейти к следующим тестам. Это важно: так убирается <iframe>, который окружает демо-страницу и может мешать некоторым инструментам. Подробнее — в описании режима отладки CodePen.

Шаг 3

Откройте Chrome DevTools и перейдите на вкладку Lighthouse. Снимите все категории, кроме «Accessibility». Режим оставьте по умолчанию и выберите тип устройства, на котором запускаете тесты.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/yv8fIyUnFaW0yPGJgohj.png", alt="Сайт Medical Mysteries Club с открытой панелью отчёта Lighthouse в DevTools.", width="800", height="421" %}

Шаг 4

Нажмите кнопку «Analyze page load» и дайте Lighthouse время выполнить проверки.

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

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

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

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/5SUhDMXiDYw43kt5ss3J.png", alt="В тесте декабря 2022 года сайт Medical Mysteries Club получил оценку Lighthouse 62.", width="800", height="421" %}

Шаг 5

Разберём по одному примеру каждой найденной автоматической проблемы доступности и исправим соответствующие стили и разметку.

Проблема 1: роли ARIA

Первая проблема звучит так: «У элементов с ролью ARIA [role], которым нужны дочерние элементы с определённой ролью [role], нет части или всех таких дочерних элементов. Некоторым родительским ролям ARIA нужны конкретные дочерние роли, чтобы выполнять задуманную функцию доступности». Подробнее о правилах ролей ARIA.

В демонстрации не проходит кнопка подписки на рассылку:

<button role="list" type="submit" tabindex="1">
    Subscribe
</button>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

У кнопки «Subscribe» рядом с полем ввода задана неверная роль ARIA. В этом случае роль можно убрать полностью.

<button type="submit" tabindex="1">Subscribe</button>

Проблема 2: aria-hidden

Элементы [aria-hidden="true"] содержат фокусируемых потомков. Фокусируемые потомки внутри элемента с [aria-hidden="true"] делают эти интерактивные элементы недоступными для пользователей вспомогательных технологий, например программ чтения с экрана. Подробнее о правилах aria-hidden.

<input
    type="email"
    placeholder="Enter your e-mail address"
    aria-hidden="true"
    tabindex="-1"
    required
/>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

У поля ввода стоял атрибут aria-hidden="true". Он скрывает элемент и всё, что в него вложено, от вспомогательных технологий.

<input
    type="email"
    placeholder="Enter your e-mail address"
    tabindex="-1"
    required
/>

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

Проблема 3: имя кнопки

У кнопок нет доступного имени. Если у кнопки нет доступного имени, программа чтения с экрана объявляет её просто как «button», и пользоваться ею нельзя. Подробнее о правилах имени кнопки.

<button role="list" type="submit" tabindex="1">
    Subscribe
</button>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

Когда в проблеме 1 с кнопки снимают неверную роль ARIA, слово «Subscribe» становится доступным именем кнопки. Так устроен семантический HTML-элемент кнопки. Для более сложных случаев есть и другие шаблоны.

<button type="submit" tabindex="1">Subscribe</button>

Проблема 4: атрибуты alt у изображений

У элементов изображений нет атрибутов [alt]. У информативных элементов должен быть короткий описательный альтернативный текст. Декоративные элементы можно пропустить пустым атрибутом alt. Подробнее о правилах альтернативного текста изображений.

<a href="index.html">
    <img
        src="https://upload.wikimedia.org/wikipedia/commons/….png"
    />
</a>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

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

<a href="index.html">
    <img
        src="https://upload.wikimedia.org/wikipedia/commons/….png"
        alt="Go to the home page."
    />
</a>

Проблема 5: текст ссылки

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

<a href="#!"
    ><svg><path>...</path></svg></a
>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

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

Для значков социальных сетей на <svg> можно взять другой шаблон альтернативного описания для SVG: поместить сведения между тегами <a> и <svg> и визуально скрыть их, добавить поддерживаемую ARIA или выбрать другой вариант. В зависимости от среды и ограничений кода один способ может быть удобнее другого. Возьмём самый простой шаблон с наилучшим покрытием вспомогательных технологий: role="img" на теге <svg> и элемент <title>.

<a href="#!">
    <svg role="img">
        <title>Connect on our Twitter page.</title>
        <path>...</path>
    </svg>
</a>

Проблема 6: контраст цвета

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

Сообщено о двух примерах.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/3Aeg1osulNGB1EVtGu8r.png", alt="Оценка Lighthouse для названия клуба. Контраст бирюзового значения слишком низкий.", width="320", height="228" %}

Название клуба,

Medical Mysteries Club

, имеет шестнадцатеричный цвет #01aa9d, а фон — #ffffff. Коэффициент контраста цвета — 2.9:1. Открыть скриншот в полном размере.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/86Iongt2UcohbzEar4Pm.png", alt="Оценка Lighthouse для текста о синдроме русалки. Контраст серого значения слишком низкий.", width="320", height="228" %}

У Mermaid syndrome шестнадцатеричный цвет текста #7c7c7c, а у фона — #ffffff. Коэффициент контраста цвета — 4.2:1. Открыть скриншот в полном размере.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

На странице много проблем с контрастом цвета. Как сказано в модуле цвета и контраста, обычный текст (меньше 18pt / 24px) должен иметь контраст 4.5:1, а крупный текст (не меньше 18pt / 24px или 14pt / 18.5px полужирного) и важные значки — 3:1.

Заголовок страницы набран бирюзовым цветом размером 24px, это крупный текст, поэтому ему достаточно контраста 3:1. Бирюзовые кнопки — обычный текст 16px полужирного начертания, поэтому им нужен контраст 4.5:1.

Можно найти достаточно тёмный бирюзовый цвет под 4.5:1 или увеличить текст кнопки до 18.5px полужирного и слегка изменить бирюзовый. Оба способа остаются в рамках эстетики макета.

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

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/2JyEvvfRBNFr7YdPipLf.png", alt="Бирюзовый цвет исправлен и больше не проваливает проверку.", width="320", height="228" %}

Названию клуба,

Medical Mysteries Club

, задан цвет #008576, фон по-прежнему #ffffff. Обновлённый коэффициент контраста — 4.5:1. Открыть скриншот в полном размере.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/3DgVWG6oIRRVTGYmZP3c.png", alt="Серый цвет исправлен и больше не проваливает проверку.", width="320", height="228" %}

У Mermaid syndrome теперь цвет #767676, фон по-прежнему #ffffff. Коэффициент контраста цвета — 4.5:1. Открыть скриншот в полном размере.

Проблема 7: структура списка

Элементы списка (<li>) не вложены в родительские элементы <ul> или <ol>. Программам чтения с экрана нужно, чтобы элементы списка (<li>) находились внутри родительского <ul> или <ol>, иначе они объявляются неправильно.

Подробнее о правилах списков.

<div class="ul">
    <li><a href="#">About</a></li>
    <li><a href="#">Community</a></li>
    <li><a href="#">Donate</a></li>
    <li><a href="#">Q&A</a></li>
    <li><a href="#">Subscribe</a></li>
</div>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

В демонстрации неупорядоченный список имитировали классом CSS, а не тегом <ul>. Из-за такой разметки пропали встроенные семантические возможности HTML этого тега. Замена класса настоящим тегом <ul> и правка связанного CSS устраняют проблему доступности.

<ul>
    <li><a href="#">About</a></li>
    <li><a href="#">Community</a></li>
    <li><a href="#">Donate</a></li>
    <li><a href="#">Q&A</a></li>
    <li><a href="#">Subscribe</a></li>
</ul>

Проблема 8: tabindex

У некоторых элементов значение [tabindex] больше 0. Значение больше 0 задаёт явный порядок навигации. Формально это допустимо, но часто создаёт неудобный опыт для людей, которые пользуются вспомогательными технологиями. Подробнее о правилах tabindex.

<button type="submit" tabindex="1">Subscribe</button>

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/dNzbda0Lx1XUeCadVLMH.svg", alt="", width="28", height="28" %}

Исправим это.

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

<button type="submit">Subscribe</button>

Шаг 6

Когда все автоматические проблемы доступности исправлены, откройте новую страницу в режиме отладки. Запустите аудит доступности Lighthouse ещё раз. Оценка должна быть заметно выше, чем при первом запуске.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/gcjuv10swXP62s1oT37d.png", alt="Оценка Lighthouse теперь 100: все проблемы Lighthouse устранены.", width="800", height="421" %}

Все эти автоматические исправления доступности собраны в новом CodePen.

Следующий шаг

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

Источник — Automated accessibility testing

Комментарии