Перейти к содержанию

Ручное тестирование доступности

Этот модуль о ручном тестировании доступности продолжает предыдущий модуль, автоматизированное тестирование доступности. Если вы ещё не выполнили упражнения из того модуля, рекомендуем сделать это. Этот модуль начинается там, где закончился предыдущий, и посвящён инструментам и приёмам ручного тестирования доступности.

Основы ручного тестирования

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

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

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

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

  • Их относительно просто и быстро провести
  • Они находят больше проблем, чем одни только автотесты
  • Для успеха нужно немного инструментов и экспертизы

Минусы ручных тестов доступности:

  • Они сложнее и дольше автоматических
  • Их трудно повторять в масштабе
  • Чтобы провести тесты и истолковать результаты, нужно больше знаний о доступности

Сравним, какие элементы и подробности доступности автоматический инструмент может обнаружить сейчас, а какие — нет.

Можно автоматизировать Нельзя автоматизировать
Контраст цвета текста на сплошном фоне Контраст цвета текста на градиентах и изображениях
Наличие альтернативного текста у изображения Альтернативный текст изображения точен и назначен правильно
Наличие заголовков, списков и ориентиров Заголовки, списки и ориентиры размечены правильно, и все элементы учтены
Наличие ARIA ARIA используется уместно и применена к нужным элементам
Выявление элементов, доступных для фокуса с клавиатуры Какие элементы лишены фокуса с клавиатуры, логичен ли порядок фокуса и виден ли индикатор фокуса
Обнаружение заголовка iFrame iFrame, порядок фокуса логичен, а индикатор фокуса виден
Наличие элемента video У элемента video есть подходящие альтернативные медиа (например, субтитры и транскрипты)

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

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

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

Некоторые организации считают проверки вспомогательными технологиями (AT) частью ручного тестирования: пересечений много. В этом курсе тестирование AT вынесено в отдельный модуль: оно сложнее остальных ручных проверок и заслуживает отдельного внимания.

Проверки с клавиатуры

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

Тесты с клавиатуры отвечают на вопросы:

  • Нужна ли мышь, чтобы страница или функция работали?
  • Логичен и понятен ли порядок Tab?
  • Всегда ли виден индикатор фокуса с клавиатуры?
  • Можно ли застрять в элементе, который не должен удерживать фокус?
  • Можно ли уйти за элемент или обойти элемент, который должен удерживать фокус?
  • Когда элемент, получивший фокус, закрывают, возвращается ли индикатор фокуса в логичное место?

Влияние клавиатуры велико, а сама проверка проста. Отложите мышь или установите небольшой пакет JavaScript и пройдите сайт только с клавиатуры. Для проверки нужны такие команды.

Клавиша Результат
Tab Переходит вперёд от одного активного элемента к другому
Shift + Tab Переходит назад от одного активного элемента к другому
Arrows Переключает связанные элементы управления
Spacebar Переключает состояния и прокручивает страницу вниз
Shift + Spacebar Прокручивает страницу вверх
Enter Активирует конкретные элементы управления
Escape Закрывает динамически показанные объекты

Визуальные проверки

Визуальные проверки смотрят на зрительные элементы страницы. Для разбора сайта или приложения используют экранную лупу или масштаб браузера.

Визуальные проверки показывают:

  • Есть ли проблемы контраста, которые автоматический инструмент не поймал, например текст поверх градиента или изображения?
  • Есть ли элементы, которые выглядят как заголовки, списки и другие структурные элементы, но так не размечены?
  • Одинаковы ли навигационные ссылки и поля форм по всему сайту или приложению?
  • Есть ли мигание, стробоскоп или анимация сверх рекомендаций?
  • Достаточно ли интервалов у содержания: у букв, слов, строк и абзацев?
  • Видно ли всё содержимое через экранную лупу или масштаб браузера?

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

Проверки содержания

Визуальные тесты смотрят на макет, движение и цвета. Проверки содержания смотрят на слова на странице. Нужно читать не только сам текст, но и контекст: понятен ли он другим людям.

Проверки содержания отвечают на вопросы:

  • Ясны и описательны ли заголовки страниц, заголовки разделов и подписи полей форм?
  • Кратки, точны и полезны ли альтернативы изображений?
  • Цвет — единственный способ передать смысл или информацию?
  • Описательны ли ссылки или в них общий текст вроде «читать дальше» и «нажмите здесь»?
  • Меняется ли язык внутри страницы?
  • Используется ли простой язык, и расшифрованы ли все аббревиатуры при первом упоминании?

Часть проверок содержания можно автоматизировать частично. Например, можно написать линтер на JavaScript, который ищет «Click here» и предлагает изменить текст. Но такие решения всё равно обычно требуют человека, который заменит текст на уместный по контексту.

Демонстрация: ручной тест

Мы уже прогнали автоматические тесты демо-страницы, нашли и исправили восемь типов проблем. Теперь можно провести ручные проверки и поискать ещё проблемы доступности.

Шаг 1

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

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

Шаг 2

Начните ручное тестирование: отложите мышь или трекпад и перемещайтесь по DOM вверх и вниз только с клавиатуры.

Проблема 1: видимый индикатор фокуса

Первую проблему с клавиатуры вы увидите сразу — точнее, не увидите: видимый индикатор фокуса убран. Если просмотреть CSS демонстрации, в коде найдётся печально известное outline: none.

1
2
3
:focus {
    outline: none;
}


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

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

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

1
2
3
:focus {
    outline: 3px dotted #008576;
}

Проблема 2: порядок фокуса

Когда индикатор фокуса изменён и виден, пройдите страницу клавишей Tab. Поле ввода для подписки на рассылку фокус не получает. Его вывели из естественного порядка фокуса отрицательным tabindex.

1
2
3
4
5
6
7
<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" %}

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

Люди должны пользоваться этим полем, чтобы подписаться на рассылку. Достаточно убрать отрицательный tabindex или поставить ноль, и поле снова сможет получать фокус с клавиатуры.

1
2
3
4
5
6
<input
    type="email"
    placeholder="Enter your e-mail address"
    aria-hidden="true"
    required
/>

Шаг 3

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

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

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


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

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

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

Если подчёркивание не добавлять, цвета нужно изменить так, чтобы выполнить требования и к фону, и к тексту.

Если посмотреть демонстрацию в инструменте проверки контраста ссылок, цвет ссылки проходит требование 4.5:1 между обычным текстом и фоном. Но ссылки без подчёркивания должны ещё иметь контраст 3:1 с окружающим текстом.

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

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/DaRljFteyjHtmNuui4u1.png", alt="Скриншот WebAIM для текста ссылки: ссылка относительно основного текста не проходит уровень WCAG A.", width="724", height="503" %}
Когда цвет ссылки и основного текста совпадает, тест не проходит.
{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/YWk49YgsMcwT8ynusu7b.png", alt="Скриншот WebAIM: все тесты проходят, когда цвет ссылки зелёный.", width="724", height="503" %}
Когда цвет ссылки и основного текста различается, тест проходит.

Проблема 4: контраст цвета значков

Ещё одна пропущенная проблема контраста — значки социальных сетей. В модуле цвета и контраста сказано, что важным значкам нужен контраст 3:1 с фоном. В демонстрации у значков социальных сетей контраст 1.3:1.


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

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

Чтобы выполнить требование 3:1, значки социальных сетей делают более тёмно-серыми.

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/E02bbVtKS9QCkQi8PvCc.png", alt="Скриншот демонстрации с анализатором цвета: контраст значков не проходит проверку.", width="800", height="570" %}

Рамка вокруг текстового поля может не давать контраст 3:1 с фоном. Но у этого поля есть текст-заполнитель, и он выполняет требование контраста для своего размера, как сказано на странице обзора контраста нетекстовых элементов.

Проблема 5: вёрстка содержания

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

1
2
3
p.bullet {
    text-align: justify;
}


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

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

Чтобы вернуть выравнивание в демонстрации, замените значение на text-align: left; или уберите эту строку из CSS: для браузеров выравнивание влево — значение по умолчанию. Проверьте код: другие унаследованные стили могут снимать выравнивание по умолчанию.

1
2
3
p.bullet {
    text-align: left;
}

Шаг 4

{% Img src="image/VbsHyyQopiec0718rMq2kTE1hke2/9O3rKmEIy3u1gqn3HfYT.png", alt="Скриншот демо-сайта Medical Mysteries Club.", width="800", height="570" %}
Все ручные проблемы в демонстрации теперь устранены, как на этом изображении.

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

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

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

Модули автоматизированного и ручного тестирования пройдены. Посмотрите обновлённый CodePen: в нём применены все автоматические и ручные исправления доступности.

Дальше — последний модуль о тестировании, тестирование вспомогательными технологиями.

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

Комментарии