{"id":13664,"url":"\/distributions\/13664\/click?bit=1&hash=f8e0aba14203df6cd2281fdd3f7f0563673921d2f335ea835255d6e0e69e1151","title":"\u041a\u0430\u043a \u0441\u0432\u044f\u0437\u0430\u043d\u0430 \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u0430\u044f \u043a\u0430\u0440\u0442\u0430 Tinkoff Black \u0438 \u043a\u0430\u0440\u0442\u0438\u043d\u044b \u0422\u0440\u0435\u0442\u044c\u044f\u043a\u043e\u0432\u043a\u0438","buttonText":"\u041a\u0430\u043a?","imageUuid":"86efc643-7e85-501c-b3c6-e2620ee53cdf","isPaidAndBannersEnabled":false}
Артем Плаксин

Невизуальное тестирование в Everland, или Отдел слепых тестировщиков

В инклюзивном социально-предпринимательском проекте Everland есть большое направление, которое занимается доступностью офлайн- и онлайн-инфраструктуры, соответствующими курсами для бизнеса.

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

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

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

  • Скринридер — программа экранного доступа, переводящая весь текст на экране в доступный для незрячего человека формат: синтез речи или брайлевский вывод.
  • WCAG (Web content accessibility guideline) — основной документ консорциума W3C о веб-доступности.
  • WAI-ARIA — техническая спецификация ролей и атрибутов HTML, служащих для адаптации веб-ресурса для слепых людей.

Кто такой тестировщик?

Прежде всего, давайте определимся с тем, кто такой тестировщик применительно к моему отделу.

Это человек, который:

  • Умеет пользоваться скринридером на уровне опытного пользователя.
  • Знаком с нормативными документами о доступности (WCAG, ГОСТ, наша система сертификации).
  • Разбирается в верстке и в спецификациях HTML/WAI-ARIA хотя бы на базовом уровне.

Обо всем этом читайте ниже более подробно.

Работа со скринридером

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

Я, как руководитель отдела, настаиваю на том, что основным скринридером у человека должен быть NVDA. Причем, «основным» означает, что будущий тестировщик, как минимум, владеет программой экранного доступа на уровне профессионального пользователя.

Почему NVDA? Скорость работы, отсутствие искажений в виртуальном буфере окна браузера, более предсказуемое поведение, одинаковый рабочий набор у всех тестировщиков.

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

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

Знание HTML

Это требование, на котором зачастую отваливается 60% всех желающих.

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

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

  • Незнание верстки закрывает для тестировщика задачи, связанные с web-сайтами, оставляя лишь мобильные приложения, да и то зачастую лишь на одной платформе (Android/iOS).
  • Человек, который не заинтересован в том, как создаются web-страницы, не заинтересован в улучшении их доступности, как бы он не пытался доказать обратное.

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

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

Показанные ниже две фразы повлекут за собой совершенно разные результаты, особенно если тестировщик не разбирается в WAI-ARIA и не сможет поправить разработчика при финальном одобрении.

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

Тестировщик без знания верстки

Необходимо тегу <nav> задать атрибут aria-label="Основное меню".

Тестировщик, владеющий основами верстки

Вид инвалидности

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

Здесь стоит обговорить важный момент, потому что часто возникает соответствующий вопрос: «Если тестировщики слепые, как они проверят доступность для слабовидящих?»

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

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

Работать тестировщиком

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

Предварительная оценка

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

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

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

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

Внутренние задачи

У Everland есть собственные проекты, заказы на создание сайтов, запросы от партнеров на проверку доступности. Как правило, это небольшие внутренние задачи, которые требуют уже знание верстки на том уровне, чтобы давать разработчикам рекомендации по возможному решению проблем, связанных с accessibility.

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

Заказы организаций

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

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

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

В случае тестирования с компьютера, то есть сайтов, а не мобильных приложений, мы выработали наиболее оптимальный подход. Как я упоминал ранее, основное тестирование сайтов происходит при помощи скринридера NVDA в Mozilla Firefox и основных браузерах, использующих для работы движок Chromium (например, Google Chrome, Microsoft Edge). С другими скринридерами мы проводим обзорную проверку, которая в большинстве случаев не пополняет сформированный ранее бэклог, и выполняется в качестве джастчекинга.

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

Отдел сейчас

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

Проводим тестирования компаний-первопроходцев в сферах ритейла, такси, банковских и телеком-услуг, продажи техники электроники и других.

0
Комментарии
Читать все 0 комментариев
null