Сокращение трубопровода тестирования доступности

На eBay мы серьезно относимся к доступу, и мы стремимся «быть для всех». С этой целью у нас есть команда экспертов, которые неустанно работают, чтобы гарантировать, что наши страницы доступны для всех. Мы твердо верим, что проблемы с доступностью следует рассматривать как ошибки, и решать с тем же уровнем медицинской помощи, поэтому мы рады объявить о нашем следующем продвижении в нашем фронтальном инструменте с открытым исходным кодом. А Доступность Линтер для Марко Предоставляет разработчикам обратную связь с доступностью непосредственно на исходном коде, очень похожий на проверку орфографии в текстовом процессоре. Прежде чем выйти в детали, давайте рассмотрим некоторый контекст о том, почему это такая важная функция.

История тестирования доступности на eBay

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

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

Во -первых, разработчики и тестеры должны быть осведомлены обо всех возможных ошибках доступности, которые отображаются на странице. Чтобы помочь с этим, команда доступности eBay создала Овсянка (Открытые методы тестирования доступности для экспертов и непрофессионалов), универсальный магазин для тестирования доступности, который предназначен для усваивания всеми, независимо от их опыта работы с доступностью. Это помогло улучшить качество нашего ручного тестирования, но не могло полностью преодолеть некоторые неотъемлемые ограничения с помощью ручного тестирования, с которым мы хотели помочь.

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

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

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

Автоматизированное тестирование с WAE

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

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

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

За прошедшие годы с тех пор, как мы начали этот проект, созданное решение сообщества с открытым исходным кодом для тестирования доступности под названием топорпо Deque Systems, возник. Но мы обнаружили, что Axe-Core не был идеальным решением для наших потребностей.

Одна из проблем состоит в том, что современные приложения не написаны непосредственно в HTML -коде; На eBay мы используем нашу структуру с открытым исходным кодом, называемая МаркоПолем Эта структура выглядит как HTML и генерирует ее для браузера, но не существует прямого отображения из кода для визуализированной страницы обратно в код Марко. Это означает, что, хотя WAE отлично подходит для поиска ошибок с доступностью на странице, разработчик должен выяснить, откуда взялась каждая ошибка. Вот почему для некоторых из самых простых ошибок мы создали новый инструмент, который помечает проблемы доступности в режиме реального времени как разработчики пишут кодПолем

Динамическая лининг для Марко

Линтер – это инструмент, который анализирует код и находит его части, которые могут потребовать некоторого внимания со стороны разработчика. Это включает в себя ошибки, но также дополнительные предложения, такие как несоответствия стиля и логические анти-паттерны. Марко языковой сервер Недавно имел огромное обновление, когда мы добавили полную поддержку Linting для TypeScript, которая помогает разработчикам улавливать логические ошибки в своем коде по мере их печати. При разработке этой функции мы устанавливаем основу для другого инструмента, который интегрирует Двигатель Deque Axe-Core в языковом сервере.

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

Axe-Core дает все возможные методы решения проблемы, как правило, от большинства до наименее принятых.

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

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