Автоматическое, экспертное и другие виды ручного тестирования могут пропустить некоторые важные и неочевидные проблемы. Они могут быть связаны с неправильной разметкой, плохим юзабилити или особенностями вспомогательных технологий. Поэтому в рамках аудита ещё желательно проводить оценочные пользовательские исследования. Тестирование с экранным чтецом очень похоже на тестирование с клавиатуры.
- Методология — это набор методов, правил и этапов, который помогает стандартизировать процесс аудита.
- Мы должны выявить эти взаимоотношения, используя семантическую разметку или атрибуты ARIA.
- В процессе вёрстки рекомендуется постоянно проверять сайт на доступность и вносить изменения, чтобы не упустить ни один из критериев.
- Если не использовать viewport, то сайт может выглядеть как уменьшенная версия десктопного сайта на мобильном экране, что делает его трудночитаемым и неудобным для использования.
- Одной из причин такого поведения может быть отсутствие маленького, но важного элемента в коде страницы — метатега viewport.
Но в то время мы активно внедряли UI-тесты с webdriverio (framework автотестирования на node.js), поэтому знали, что динамика ложится на плечи наших сценариев. Сейчас данная фича перекочевала в нашу конфигурацию cypress. Компании публикуют такие заявления на своих сайтах, если хотят рассказать пользователям и партнёрам о доступности сайта или приложения. Когда недостаточно средств для проведения смешанного или ручного аудита, то в первое время поможет автоматический.
Мы знали, что картинки стоит сопроводить прошедшим локализацию читаемым alt, но также включали для декоративных иллюстраций role-атрибут presentation, который вступал в конфликт с alt. Только с опытом мы пришли к тому, что alt в таких случаях достаточно оставлять пустым, поскольку полезную нагрузку на пользователя подобные иллюстрации не несли. Итог любого аудита — отчёт, который состоит из списка всех найденных проблем и рекомендаций по их исправлению. В проведении исследований есть особенности, которые могут привести к ошибочным выводам. Поэтому лучше всего привлекать людей, которые умеют проводить интервью или юзабилити-тестирование.
Случайных страниц должно быть 10% от числа страниц из структурированной выборки. То есть, если в структурированной выборке их 80, то в случайную попадут 8. Например, с помощью инструментов и скриптов для случайного выбора или просмотра серверных логов.
Какой Инструмент Тестирования Доступности Использовать?
Уровень доступности активно развивающихся больших продуктов постепенно снижается из-за постоянных изменений. В их случае лучше проводить аудит не только каждый год, но и ежеквартально. Годовой будет более полным и глубоким, а квартальные — небольшими и точечными. Ниже описаны шаги по тестированию доступности веб-сайтов и веб-приложений на платформе LambdaTest.
Так как мы не можем видеть экран (и я рекомендую выключить его или закрыть глаза в ходе тестирования), мы не можем пользоваться мышью или трекпадом для выбора элементов страницы – к ним можно только перейти по Tab с клавиатуры. Главное отличие тут в том, что мы не можем опознать такие элементы, как кнопка, зрительно, или связать поля ввода с их метками по их местоположению. Мы должны выявить эти взаимоотношения, используя семантическую разметку или атрибуты ARIA. Для определения достаточной контрастности сайта существуют разные инструменты, например, сервис WebAIM позволяет проверять контрастность цветов элементов и соотносить данные с критериями WCAG. Также есть отдельный инструмент от WebAIM для измерения контрастности ссылок относительно фона и основного текста. Теперь вы можете проводить тестирование доступности ваших сайтов или приложений в режиме реального времени.
Ручное тестирование доступности – это техника использования нестандартных сочетаний взаимодействий с клавиатурой, вспомогательных технологий и браузерных плагинов для проверки доступности веб-сайтов и приложений. Оно помогает выявить проблемы, которые невозможно обнаружить с помощью программ. В то же время ручной прогон тестов требует много времени и не исключает ошибок, вызванных человеческим фактором. Я в значительной степени принял расширение браузера aXe в качестве своего основного инструмента тестирования, как только я разрешил любые проблемы там, я перехожу на SiteImprove, Tenon.io, а затем WAVE. Автоматизированное тестирование доступности – наиболее эффективный способ тестирования веб-приложений. За исключением одного шамболического усилия, все инструменты дали довольно последовательные результаты для этого, по общему признанию, ограниченного теста UI.
Web Accessibility Inspector совместим и с Windows, и с macOS. Кроме того, важно проверить отображение сайта в различных браузерах и на разных платформах. Это несколько проблематично, если у вас есть проблемы с частичными элементами пользовательского интерфейса, которые еще не видны, например, скрытые формы.
Раньше мы уделяли основное внимание устранению «ошибок» в нашем внутреннем тестировании, но теперь мы увеличиваем сферу своей деятельности и в «предупреждениях». Но, к сожалению, так сильно разогнавшись, мы упёрлись в ограничения технологий нашего времени. Пожалуй, на этом этапе я готов признать, что мы столкнулись с новым для нас термином – «кроссридерность». Как жить с данным словом нам ещё предстоит решить, развивая нашу a11y культуру. Процесс же обучения занимал достаточно много времени, а обоснованно донести до продуктовой команды, что у неё баг в Dropdown, и надо перейти на Listbox, порой было довольно сложно.
Элементы
AXe – это бесплатный инструмент с открытым исходным кодом от Deque Systems. С его помощью можно тестировать доступность в Chrome и Firefox. AXe отображает место в коде, в котором возникла проблема, а также предлагает способы ее устранения. В этом разделе https://deveducation.com/ мы обсудим некоторые ключевые моменты при работе с доступностью. Тестирование доступности появилось еще в 1997 году, но не получило широкого распространения в современном веб-дизайне. Различные мифы удерживают людей от его внедрения на своих проектах.
Также полезно знать, как программы чтения с экрана считывают содержимое сайта. Это позволяет разработчику создавать ресурс, который будет читаемым и понятным для всех пользователей. Структура сайта должна быть чётко организована, чтобы пользователи могли без сложностей перемещаться по страницам и находить необходимую информацию.
Создание новой технологии, которая подойдет всем пользователям, требует немалых усилий. В частности, если речь идет о веб-продукте (сайте или приложении), который вы планируете выпустить на рынок. Такой продукт должен быть доступен и удобен в использовании всем, в том числе пользователям с особенными потребностями. Например, люди с нарушениями зрения, слуха и другими физическими или когнитивными проблемами.
Если мы не тестируем доступность сайта или приложения после каждого изменения, то рано или поздно столкнемся с регрессом. Поэтому важно сделать тестирование доступности частью непрерывной интеграции (CI). Нельзя вливать код в базу, не проверив его на доступность. ???? Предоставление текстовых альтернатив для всех не визуальных элементов — изображений, видео и аудио. Для обеспечения доступности аудио и видеоконтента на сайте необходимо добавлять описания, а также субтитры или звуковые сигналы для пользователей с ограниченными возможностями.
Пользователь ожидает привычного поведения фокуса — движения слева направо и сверху вниз. Чаще всего такой порядок будет установлен автоматически, но бывают исключения. Например, при открытии модальных окон, использовании оповещений или при переходе к новому экрану. Для кастомного элемента или стандартного, но используемого не по прямому назначению, прописывайте наиболее подходящие трейты вручную. Если вы присвоили элементу трейт, VoiceOver произнесет его после названия элемента.
Voiceover
Проводится с помощью автоматических инструментов и автотестов. Размеры продукта напрямую влияют на то, как часто проводить аудит. Для небольшого продукта без больших изменений достаточно одного раза в год. Средние проекты с умеренным количеством новых функций можно проверять раз в полгода–год.
Это могут быть описание путей для поиска страниц и их состояний. Также следует проверить, правильно ли работают формы, модальные окна и другие элементы, которые встречаются на пользовательских путях. Они могут выглядеть и вести себя по-разному, содержать уникальный контент и из-за этого иметь разную поддержку доступности.
Прежде, чем разбирать данные пункты, хочу отметить, что доступность – понятие обширное (как интернационализация на фоне локализации). Одними display screen reader (программы экранного доступа, например, VoiceOver, JAWS, NVDA) тут не обойдёшься. Необходимо заботиться также и о людях без гибких средств ввода, без хороших контрастных мониторов, с подсевшим зрением или стремящихся к масштабу страницы 150%. Мы сразу определились, что, если существует управление с клавиатуры без использования мыши, мы также считаем это задачей доступности.
За основу я взяла наш end-to-end тест-план, но опустила некоторые специфичные детали. Для начала, определимся с тем, что такое end-to-end тестирование. Мы уже обсудили основные правила написания alt-текста для фотографий accessibility testing это и изображений. В этот раз поговорим о том, каким именно должно быть описание, чтобы в нём был смысл. Ленивая загрузка делает сайт быстрее и экономит трафик, если у пользователя мобильный интернет с ограничениями.
Html
При разработке необходимо привыкнуть к особенностям взаимодействия с устройством, когда TalkBack включен. Например, чтобы произвести нажатие на элемент на экране, необходимо выбрать элемент касанием и выполнить двойное нажатие на экран, а чтобы прокрутить экран (swipe) необходимо использовать два пальца вместо одного. Есть несколько бесплатных программ, позволяющих просканировать веб-сайт и выявить некоторые дефекты. Поэтому я знаю, что у меня есть все, чтобы исправить, и, честно говоря, я не собираюсь вас утомлять, я буду использовать aXe во время моего первоначального прохода, а затем посмотрю, что мне говорят другие инструменты.
AXe оценивает влияние a11y-проблем по-разному на WAVE, в этом примере проблема с альтернативным текстом имеет решающее значение, проблема tabindex серьезна, а другие умеренные. Стоит отметить, что эта презентация заставляет меня разрешать все нарушения, потому что она говорит мне, что их девять, а не WAVE, сообщивших мне, что есть одна ошибка и девять предупреждений. Каждая проблема четко показывает соответствующую разметку, ударяя «inspect node», перепрыгивая обратно на вкладку элементов DevTools, выделяя элемент. Если вы используете последнюю версию Chrome, у вас, вероятно, уже есть Lighthouse, потому что он встроен! Откройте devtools и перейдите на вкладку «Аудит», нажмите кнопку «Выполнить аудит», и вам будет предоставлен список проверок, которые Lighthouse сможет выполнить, мы только проверим аудит доступности, чтобы сэкономить время. И почему-то ранее мы не так сильно обращали внимание на наш расширенный компонент на основе тега label с заголовком, описанием, подсказкой и ошибкой поля ввода.
Wcag-emскопировать Ссылку
Часто автоматического и ручного экспертного тестирования мало для того, чтобы сделать продукт максимально доступным. Не забывайте про регулярное автоматическое и ручное тестирование. Это поможет заранее отлавливать ошибки и быстро их исправлять. Ещё полезно периодически проводить тестирование с клавиатуры.
HTML поддерживает навигацию с клавиатуры по умолчанию, если она верно сделана, и так повелось с зарождения Интернета. Однако где-то по дороге значительное количество разработчиков или забыли об этом, или никогда об этом и не узнавали. Еще один способ проверить базовые ошибки — использовать фреймворки. Самые распространенные среди них — UBKAccessibilityKit и GSCX. Также в подсказке можно указать, что произойдет при взаимодействии с элементом.