Юзабилити-тесты с людьми с инвалидностью

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

Кого пригласить на тестирование

• Тотально незрячих
• Людей с остротой зрения менее 30%
• Людей с нарушением моторики или без верхних конечностей

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

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

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

Где найти пользователей

Помните, что люди с инвалидностью заинтересованы в доступности и готовы вам помочь. Обратитесь:

• в местные общества людей с инвалидностью — ВОИ, ВОС и т.д.
• на форумы и сообщества в интернете, например, Доступная среда
• к экспертам с инвалидностью

Если у вас продукт, в котором перманентно выходит новый функционал, имеет смысл нанять тестировщика в штат, как мы сделали это в Сбербанке. Когда я искала такого человека, в первую очередь, смотрела на опыт в области IT. Ведь человек должен быть не только слепым, но и понимать в разработке, говорить на одном языке с айтишниками. Кроме того, он должен обладать еще одной особенностью — уметь вдохновить. Найти такого человека не просто, ведь подобной специальности не существует. Однако подбор такого специалиста — опыт интересный! Из 6 человек, выполнивших тестовое задание был, например, незрячий футболист, игравший за сборную России по футболу. Как я узнала во время интервью, в 2017 году наша сборная незрячих выиграла чемпионат Европы :)!

Как подготовиться к тестированию

До тестирования с пользователями стоит сделать автоматизированную проверку с помощью одной из программ: HTML CodeSniffer , aXe , Lighthouse Accessibility Audit или WAVE, Accessibility Inspector (IOS), Accessibility Scanner (Android). Они позволят вам сэкономить время и быстро, без участия пользователей, определить:

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

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

Порядок элементов на странице перепутан

Незрячие люди взаимодействуют с цифровой средой с помощью аудиоинтерфеса (скринридер) или брайлевского дисплея. Скринридер для тестирования стоит выбирать исходя из платформы. Для Windows самые распространенные — NVDA и JAWS. Тестировать стоит оба, так как оба одинаково популярны. На iOS платформе пользователи используют VoiceOver, на Android — TalkBack. Перед тестированием стоит уточнить на какой платформе работает пользователь. Еще лучше, если человек будет использовать его устройство, поскольку каждый подстраивает скринридер под себя — скорость произношения, будет или нет тот произносить знаки препинания и т.д.

Также перед тестом будет полезно пройти сценарий самостоятельно:

• с помощью скринридера
• без использования мышки, только с помощью клавиатуры

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

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

На что обратить внимание во время юзабилити-теста

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

Проверьте, что пользователи получают информацию о кнопках, ссылках, иконках, картинках, графиках, таблицах, капче!

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

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

• Убедитесь, что пользователи понимают, как избежать или исправить ошибки. Часто подсказки скрыты, а информация об ошибке выполнены графически — красной рамкой, например. Убедитесь, что пользователи видят и понимают ваши подсказки.
• Убедитесь, что из текста ссылки человек понимает, куда он попадет. Незрячий человек может перемещаться по ссылкам с помощью горячих клавиш, поэтому если они подписаны, как «здесь» или того хуже, как полный адрес, человек не поймет, куда он сейчас перейдет.
• Проверьте, что при управлении с помощью скринридера незрячий пользователь понимает, где он находится, а также логику, которую вы заложили. При открытии нового экрана фокус не должен оказываться посередине или внизу страницы. В этом случае незрячий человек либо пропустит важную информацию, либо ему придется просматривать ее по несколько раз. Переход фокуса также должен быть логичным и понятным.

Управляемость. У человека должна быть возможность не только воспринять и понять контент, но и взаимодействовать с ним.

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

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

Как эффективно передать результаты тестирования

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

Как учесть потребности людей с инвалидностью

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

• Международный стандарт по доступности WCAG 2.1
• Гайдлан по цифровой доступности

Больше по теме тестирования доступности:

• Testing for accessibility от Gov.uk
• Assistive Technologies I Test With
• How I do an accessibility check — A11ycasts #11
• The Designer’s Guide to Accessibility Research

Мой канал в телеграмме: Не исключение.