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

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

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

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

Помните, что ваша отрасль, тип продукта, местные и национальные законы и политика, а также общие цели в области доступности определяют, каким рекомендациям следовать и каким уровням соответствия необходимо соответствовать. Если для вашего проекта не требуется конкретный стандарт, рекомендуется следовать последней версии WCAG. Для получения общей информации об аудитах доступности, типах/уровнях соответствия, WCAG и POUR обратитесь к разделу « Как измеряется цифровая доступность? ».

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

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

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

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

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

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

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

• Автоматизированные инструменты не выявляют все ошибки доступности в вашем продукте.
• Сообщения о ложных срабатываниях (сообщается о проблеме, которая не является истинным нарушением WCAG)
• Для разных типов продукции и задач может потребоваться несколько инструментов.

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

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

Один из первых онлайн-инструментов для автоматизированного тестирования доступности был разработан в 1996 году Центром прикладных специальных технологий (CAST) и назывался « Отчет Бобби ». Сегодня существует более 100 инструментов автоматизированного тестирования на выбор!

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

Выбор инструмента автоматизации может зависеть от многих факторов, в том числе:

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

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

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

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

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

Шаг 1

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

Существует множество способов интегрировать Lighthouse в ваш рабочий процесс тестирования. Для этой демонстрации мы используем расширение для Chrome.

Шаг 2

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

Узнайте больше о режиме отладки CodePen .

Шаг 3

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

Шаг 4

Нажмите «Анализ загрузки страницы» и дайте Lighthouse время для выполнения тестов.

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

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

Шаг 5

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

Выпуск 1: Роли ARIA

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

В нашей демонстрационной версии кнопка подписки на новостную рассылку не работает:

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

Давайте это исправим.

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

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

Выпуск 2: ARIA скрыта

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

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

Давайте это исправим.

К полю ввода был применен атрибут aria-hidden="true" . Добавление этого атрибута скрывает элемент (и все, что находится под ним) от вспомогательных технологий.

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

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

Проблема 3: Название кнопки

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

Узнайте больше о правилах именования кнопок .

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

Давайте это исправим.

Если удалить неверную роль ARIA из элемента кнопки в выпуске 1 , слово «Подписаться» станет доступным именем кнопки. Эта функциональность встроена в семантический 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>

Давайте это исправим.

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

<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> , но для тегов <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: Цветовой контраст

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

Было зафиксировано два примера.

Давайте это исправим.

На веб-странице обнаружено множество проблем с цветовым контрастом. Как вы узнали из модуля «Цвет и контраст» , для текста обычного размера (менее 18pt / 24px) требуется цветовой контраст 4,5:1, в то время как для текста большого размера (не менее 18pt / 24px или 14pt / 18,5px жирным шрифтом) и основных значков требуется контраст 3:1.

Для заголовка страницы бирюзовый текст должен соответствовать требованию контрастности 3:1, поскольку это крупный текст размером 24 пикселя. Однако бирюзовые кнопки считаются текстом обычного размера (16 пикселей, жирный шрифт), поэтому они должны соответствовать требованию контрастности 4,5:1.

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

Весь серый текст на белом фоне также не соответствует требованиям к цветовому контрасту, за исключением двух самых крупных заголовков на странице. Этот текст необходимо затемнить, чтобы соответствовать требованиям к цветовому контрасту 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>

Давайте это исправим.

В этом примере мы использовали 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>

Давайте это исправим.

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

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

Шаг 6

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

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

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

Отличная работа! Вы уже многого добились, но мы ещё не закончили! Далее мы перейдём к ручным проверкам, как подробно описано в модуле ручного тестирования доступности .