Будь-яка стаття чи книга з дизайну скаже вам, що інклюзивність і доступність — це важливо, та їх треба тестувати. Але часто тестуванням нехтують через брак бюджету і часу, через нерозуміння, з чого почати, або хибне уявлення про те, хто буде у виграші від цього. Слава Шестопалов і Євген Шикірявий підготували відповіді на запитання, які допоможуть зробити перший крок та організувати сесію тестування за участю людини з інвалідністю.

Конспект лекції з інтенсиву «Інклюзивний вебдизайн» у школі Projector.

1. Як не заблукати в методології?

1.1. Аудит і тестування

Є два головні способи оцінювання доступності (англ. accessibility) цифрового продукту: аудит і тестування.

Аудит не залучає кінцевих користувачів, а полягає в порівнянні дизайну з вимогами стандартів чи законів. Аудит проводять як із живим продуктом, так і з дизайн-прототипом, але пам’ятайте: у прототипі можна перевірити лише візуальні засоби доступності, які не відіграють жодної ролі для зручності незрячого користувача, але мають сенс для людей з іншими порушеннями.

• Автоматизований аудит — це перевірка доступності за допомогою онлайн-сервісів (наприклад, WAVE), плагінів для браузерів (скажімо, ARC Toolkit) або плагінів для дизайн-програм (приміром, Color Blind чи A11y Color Contrast Checker для Figma). Інструменти працюють по-різному: одні підсвічують проблеми візуально, інші ж формують список помилок із порядковим номером рядка коду. Залежно від ситуації для розтлумачення результатів потрібно від декількох годин до кількох днів.

Аналіз інтерфейсу «Дії» за допомогою сервісу WAVE.

• Експертний аудит — це коли доступність перевіряє людина, яка орієнтується у стандартах (найвідоміший — WCAG) і законах у галузі доступності (наприклад, ADA в США). Експерт крок за кроком переглядає всі сторінки та функції сайту чи застосунку та порівнює їх із контрольним списком вимог. Зазвичай у продуктових командах за аудит відповідають дизайнери, UX-дослідники чи тестувальники програмного забезпечення (QA).

Тестування, на відміну від аудиту, засноване на роботі з кінцевими користувачами — людьми з інвалідністю — та передбачає серію фасилітованих сесій сам на сам. Фасилітатор ставить перед кожним користувачем певне реалістичне завдання, слідкує за тим, як людина його виконує, ставить додаткові запитання та документує результати.

Тестування сайту «Sinoptik.ua» під час інтенсиву «Інклюзивний вебдизайн». Користувач, який майже втратив зір, демонструє свій екран і намагається зрозуміти, яка буде погода найближчими днями. До сайту застосовано режим підвищеної контрастності.

Що ж ліпше: аудит чи тестування? Обидва! Кожен метод має переваги та недоліки, які компенсуються в поєднанні. Варто зазначити, що тестування зараз дуже недооцінене та його практикують значно рідше за аудит. Дизайнери й інші ІТ-фахівці соромляться запрошувати людей з інвалідністю, бояться їх образити в ході сесії або і взагалі не знають, де їх шукати.

Сила аудиту — в системності, бо він охоплює всі сторінки й функції, а не обмежується головним сценарієм. А тестування перевіряє цифровий продукт у природному середовищі: користувач самостійно вирішує, яким шляхом іти до мети, і часто обирає зовсім не той «ідеальний» шлях, який закладав у продукт дизайнер.

Аудит покладається на стандарти, які ніколи не бувають ідеальними, а тестування допомагає зрозуміти, як люди поводяться насправді. Формальна відповідність стандартам захищає компанію від судових позовів у країнах із жорстким законодавством, але не гарантує високої зручності користування для людей.

1.2. Тестування доступності та юзабіліті-тестування

Що ж, ми з’ясували відмінності між аудитом і тестуванням, але є ще один популярний метод, з яким плутають тестування доступності. Порівняймо ж їх.

• Тестування юзабіліті, як правило, відбувається на ранній стадії, коли цифровий продукт ще не втілено в коді та в розпорядженні команди є лише прототип (наприклад, в Invision, Figma чи Framer); хоча нерідко тестують і живий продукт. Але головна особливість юзабіліті-тестування полягає в тому, що туди запрошують користувачів за демографічними критеріями, притаманними для цільової аудиторії (вік, стать, професія, країна проживання тощо).

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

• Тестування доступності передбачає, що у вас уже є робочий продукт, який залучає користувачів з інвалідністю і відрізняється критеріями вибору учасників. Тут важливо взяти до уваги, по-перше, органи чуття, важливі для роботи з вашим цифровим продуктом (наприклад, дотик і зір — для мобільного застосунку «Погода», очі та слух — для комп’ютерної гри), а по-друге, допоміжні технології, якими послуговуються користувачі з інвалідністю. Що цікаво, тестування за участю людей з інвалідністю виявляє не тільки проблеми з доступністю, але і з юзабіліті. Ви бачите, чи ваш продукт сумісний з допоміжною технологією, і те, де хибно складено текст або є якась нелогічна навігація.

Отже, ми з’ясували, що для тестування доступності треба залучати людей з інвалідністю. І хоча цей метод фокусує увагу на вебдоступності, це не заважає дослідникові знайти на додачу ще низку юзабіліті-проблем.

2. Як знайти користувачів?

2.1. Інвалідність і неспроможність

У світі існує низка типів неспроможностей, і, мабуть, саме так варто перекладати англійський термін «disability», хоча в українській літературі часто звучить слово «інвалідність». У деяких ситуаціях це справді те, що ми звемо інвалідністю, тобто постійний діагностований лікарем стан людини. Але згідно з ВООЗ, неспроможності також бувають тимчасові (наприклад, перелом вказівного пальця) та ситуативні (скажімо, отримані через гучну музику в приміщенні чи важкі сумки в обох руках). Залежно від впливу на органи чуття і системи організму неспроможності поділяють на візуальні, аудіальні, когнітивні, фізичні тощо.

2.2. Кого запрошувати?

Інтернет і цифрові технології — це переважно інформація на екранах, отже, сприйняття покладається передусім на зір. Звідси доходимо логічного висновку, що найвразливіша аудиторія для будь-якого цифрового продукту — це незрячі люди. Вивчення проблем незрячих користувачів допоможе виявити до 80% всіх можливих проблем із вебдоступністю.

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

• Незрячі люди користуються інтернетом за допомогою клавіатури й так званих «скрінрідерів» (англ. screen readers), іншими словами, екранних читачів. Це спеціальні програми, що трансформують текст на екрані в роботичне мовлення, що дає користувачам зрозуміти, на якому елементі інтерфейсу вони зараз перебувають, і що можуть зробити далі.
• Слабкозорі люди часто теж послуговуються екранними читачами, але інколи все ще дивляться на екран і можуть розрізнити контури головних елементів сайту та здогадатися, що білий прямокутник по центру — це, мабуть, модальне вікно. Якщо порушення зору не настільки серйозне, користувачі застосовують масштабування і, скажімо, переглядають сайт у розмірі 200% без скрінрідера.
• Люди з колірною сліпотою будуть особливо помічні, якщо ваш цифровий продукт покладається на колір та має розмаїту візуалізацію даних — графіки, мапи, діаграми, схеми або складні панелі керування (англ. dasboards). Якщо ж ви тестуєте сайт чи застосунок, де на колір не відіграє важливу роль, зосередьтеся на сесіях із двома типами учасників, описаними вище.

2.3. Де шукати?

Знайти людей з інвалідністю не так важко, як здається, і часто вони більш охоче погоджуються на сесію тестування, ніж люди без інвалідності. Є три джерела, де можна знайти потрібних користувачів.

• Спеціалізовані платформи для рекрутингу тестувальників (наприклад, Access Works і UserTesting). Насправді інструментів у світі багато (ось класний огляд), проте мало з них пропонують фільтр «користувачі з інвалідністю», не кажучи вже про конкретний тип інвалідності. Ці інструменти майже всі платні та недешеві, проте ви отримуєте доступ до аудиторії з усіх країн світу.
• Спільноти в соціальних мережах із ключовими словами «інклюзивний», «люди з інвалідністю», «робота для людей з інвалідністю» (англ. inclusive, people with disabilities, work opportunities for people with disabilities, PWD). Ви можете попросити адміністратора спільноти опублікувати ваш заклик до тестування, але треба подбати, щоб оголошення було доступним. Бо лиш уявіть іронію, коли ви шукаєте незрячих людей для дослідження за допомогою картинки, яку вони не здатні прочитати.
• Громадські організації та соціальні підприємства (наприклад, Inclusive IT в Україні або Social Enterprize UK у Великій Британії). У цих організаціях є не лише велика база аудиторії для тестування, але вони також допомагають своїм учасникам опановувати допоміжні технології, здобувати нові професії та повноцінно жити всупереч інвалідності.

Люди з інвалідністю, безперечно, зацікавлені в тому, щоб інтернет ставав зручнішим та інклюзивнішим, але вони витрачають на тестування свій час. У виняткових ситуаціях люди готові допомогти безплатно, але найчастіше участь треба оплатити. Якщо люди є учасниками соціального підприємства чи працюють через спеціалізовану платформу, там зазвичай діє стандартна погодинна ставка. Якщо ні — ви можете домовитися про справедливий гонорар індивідуально.

Куратори курсу «Інклюзивний вебдизайн» Слава Шестопалов і Женя Шикірявий залюбки сконтактують вас із потрібними людьми і проконсультують щодо тестування.

3. Що підготувати заздалегідь?

3.1. Онлайн чи офлайн?

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

Переваги онлайн-тестування:

• Природне робоче середовище. Тестувальники використовують своє звичне обладнання і тонко налаштовану допоміжну технологію, тобто те, як вони зазвичай роблять свої справи в інтернеті. Це дає точніші результати, ніж якби людині треба було призвичаїтися до обладнання, яке ви їй надасте. Часто для людей з інвалідністю мають значення клавіатурні скорочення, певний темп і голос екранного читача тощо, і це дуже індивідуально.
• Вартість і час. Очна сесія передбачає, що ви відшкодовуєте тестувальникам витрати або забезпечуєте самі подорож до вашого офісу і назад. Для цього часто потрібен спеціальний доступний транспорт або супровід іншої людини. А от приєднатися до сесії онлайн можна миттєво.
• Міжнародна аудиторія. Якщо ви працюєте з міжнародним продуктом, то більше шансів, що знайдете тестувальників за кордоном і зможете з ними попрацювати онлайн без потреби організовувати переліт кожного разу, коли треба перевірити доступність нової функції чи продукту.

Особливості офлайн-тестування

Офлайн-тестування допомагає бачити не лише екран людини, але і її емоційну реакцію на все, що відбувається. Крім того, ви витратите менше часу, щоб тестувальник налаштував демонстрацію екрану та відео. А ще офлайн-сесія навряд може буде зіпсована через низьку якість онлайн-зв’язку, коли хтось раптово «відвалиться» або чутиме аудіоперешкоди.

3.2. Оптимальні інструменти

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

Тестування доступності на курсі «Інклюзивний вебдизайн» в Українському католицькому університеті. Студентка проводить мініінтерв’ю з незрячим користувачем через Skype перед тим, як почати власне тестування цифрового продукту.

Проте можна проводити успішні сесії (особливо вперше) і за допомогою звичних програм для відеоконференцій: Skype, Zoom, Google Meet, Microsoft Teams. У них теж є функції демонстрації екрану та відеозапису, а для нотаток згодяться старі добрі блокнот і ручка. Але головна перевага цих неспеціалізованих програм у тому, що користувачі імовірно ними добре володіють і використовують для спілкування з колегами чи родичами. Отже, ви зекономите час на початку сесії, поки людина з інвалідністю зрозуміє, як увімкнути демонстрацію та відео. Тому серед усіх можливих інструментів краще надати перевагу не тому, який подобається дослідникові, а тому, яким найліпше володіє кожен тестувальник.

На відміну від юзабіліті-тестування, тестування доступності зазвичай потребує більше підготовки та довшої вступної частини. Наприклад, незрячі люди налаштовують відео довше, ніж зрячі користувачі, і це варто враховувати у тривалості сесії.

3.3. Формулювання завдань

На відміну від юзабіліті-тестування, тестування доступності передбачає, що ви маєте робочий продукт, а не лише макети чи дизайн-прототипи з перелінкованими картинками. У живому продукті необмежені функції та справжній контент, і ви зможете формулювати практичніші завдання для тестування.

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

Рекомендовано: широкі реалістичні завдання

• «Ви маєте купити подарункову картку для друга Івана Петренка, який проживе у Жмеринці Вінницької області. Будь ласка, скористайтеся цим інтернет-магазином електроніки та коментуйте все, що ви робите».
• «Вас попросили перевірити ризики у системі та підготувати звіт для керівництва компанії. Будь ласка, зробіть це за допомогою цього застосунку і коментуйте вголос, що вам треба зробити, щоб досягти мети».

Варто уникати: дрібні завдання з підказками

• «Введіть запит “цілозерновий хліб” у поле пошуку. Додайте перший пункт з результатів пошуку до кошика покупок. Оберіть варіант “Visa/Mastercard” для оплати».
• «Перейдіть до головної сторінки. Подивіться на блакитний модуль у правому нижньому кутку. Застосуйте фільтр за датою і скажіть мені, який рядок списку опинився вгорі.»

Коли ви даєте простір для вибору, то бачите, як людина мислить насправді і чи дизайн, який очевидний для вас, так само зрозумілий для неї. Часта помилка під час тестування — це дрібні завдання. Може, користувач не помітив би чогось без підказки і пішов би іншим шляхом, але ви цього вже не дізнаєтеся.

Типові помилки у формулюваннях

• Мова реклами: «Спробуйте нашу нову смартфункцію, яка створює звіт за допомогою натискання лиш однієї кнопки!»
• Підказки: «Відкрийте секцію “Мапа” і знайдіть найближче відділення до вашого поточного місця перебування».
• Примітивні завдання: «Будь ласка, знайдіть свій профіль».
• Жартівливі завдання: «Видаліть Віктора Федоровича Януковича з переліку адміністраторів системи».
• Складна термінологія: «Знайдіть логарифмічну візуалізацію даних на цьому дашборді».

Коректно складені завдання та запитання забезпечують половину успіху сесії. Якщо ви надто сильно вплинете на поведінку людини, це спотворить результати і, скажімо, ви переконаєтеся, що якась функція працює добре, хоча насправді самі людину до неї підштовхнули.

Між іншим, ось тут описано 12 хибних типів запитань, що зашкодять вашому дослідженню, а також як їх переформулювати (англійською мовою).

3.4. Загальний план сесії

У розділі 1.2 було посилання на шаблони для юзабіліті-тестування, які з мінімальними змінами пасують також і до тестування доступності. Можете переглянути їх детально пізніше, а поки розглянемо загальну схему.

1. Привітання і «правила гри». Фасилітатор (тобто ведучий сесії) пояснює, в чому полягає мета роботи. Він заспокоює людину та пояснює, що об’єкт тестування — це сайт чи застосунок, а не здібності тестувальника, а також просить дозвіл на відеозапис.
2. Інтерв’ю. Мета цього етапу — дізнатися більше про тип інвалідності та комп’ютерні звички користувача, а також з’ясувати його попередній досвід у темі (наприклад, чи людина часто купує товари онлайн, чи колись орендувала готель за кордоном тощо). Інформація з інтерв’ю допоможе сформулювати більш реалістичне завдання. Наприклад, якщо ви тестуєте інтернет-магазин, попросіть користувача зібрати свій типовий кошик покупок. Якщо об’єкт дослідження — це туристичний сервіс, дізнайтеся, як людина подорожує і куди мріє полетіти наступного разу.
3. Виконання завдання. Практична частина сесії завжди містить імпровізацію. Як казав Двайт Айзенгавер: «Плани марні, але планування незамінне». Тому варто ретельно готувати сценарій, однак це не значить, що треба його неухильно та дослівно дотримуватися. Фасилітаторам треба завжди мати про запас запитання у стилі: «Ви щойно вибрали пункт “Переглянути деталі”. Поясніть, будь ласка, що ви там хотіли дізнатися». Або ось таке: «Я помітив, що ви щось шукаєте на сторінці. Прокоментуйте, будь ласка, свої дії». Якщо людина висловлює якесь судження чи пропозицію, треба обов’язково перепитати, чому вона так думає і чи була якась реальна ситуація в минулому, яка змусила так вважати.
4. Підсумки і подяка. Наостанок фасилітатор дякує тестувальникові, згадує найбільш корисні знахідки й оголошує наступні кроки (якщо сесія матиме продовження).

3.5. Як називати учасників?

Немає жодного особливого способу звертатися до учасників тестування. Найліпше кликати їх на ім’я, як і будь-яких інших співрозмовників. Перш за все, перед вами людина: Дмитро, Ганна, Василь чи, наприклад, Вікторія. Інвалідність суттєво впливає на життя, але аж ніяк не визначає характер того, хто перед вами.

Якщо потрібно описати людей з інвалідністю в документації, вживайте слова, які чітко описують стан здоров’я, але не принижують гідності та не пришпилюють ярлики. Не потрібно вигадувати, «на якій козі під’їхати» до людини чи який евфемізм вжити, щоби завуалювати правду життя.

Образливо:

• інвалід;
• людина з обмеженими можливостями;
• людина з інклюзивністю;
• людина з особливими потребами.

Рекомендовано:

• людина з інвалідністю;
• людина з порушенням зору;
• людина з синдромом Дауна;
• людина на візку;
• незрячий користувач;
• слабозора людина.

4. Що врахувати під час тестування?

Вебдоступність — ціла наука, в якій люди практикуються та вчаться роками, але почати можна з двох найважливіших тем: як працюють екранні читачі та навігація за допомогою клавіатури. Без їхнього розуміння ви ризикуєте провести сесію з незрячою людиною недолуго та малоефективно.

4.1. Екранні читачі

Екранні читачі — це програми, які конвертують інформацію, що показана на екрані, у мовлення, яке незряча чи слабозора людина чує через навушники або динаміки. Екранний читач бере інформацію з вихідного коду сайту та орієнтується на структуру HTML, ігноруючи код, який описує декоративні елементи, наприклад, тінь, заливку фону чи контури блоків. Якщо код сайту написано коректно, то скрінрідер буде впізнавати тип інтерактивних елементів і додавати корисні підказки.

Руслан, незрячий програміст і просвітник у сфері інклюзивного дизайну, демонструє роботу екранного читача NVDA. Ліворуч — сайт, а праворуч — текст, який йому зачитує допоміжна технологія.

Наприклад, якщо на сайті є кнопка «Купити», зрячий користувач упізнає її за прямокутною формою та яскравим кольором і здогадається, що її треба натиснути, щоби придбати товар. А для незрячої людини слова «Купити» забракне. Бо це може бути і кнопка, і заголовок сторінки, і назва розділу, і частина рекламного банера. Але якщо в HTML-коді кнопку оформлено за допомогою відповідного тегу <button>, екранний читач озвучить не лише слово «Купити», але і дасть підказку на зразок: «Кнопка, натисніть Enter, щоб активувати». Подібні підказки будуть і до чекбоксів, і радіокнопок (перемикачі — ред.), і полів введення тексту, і випадайок. Елементи, які зряча людина розрізняє візуально, незрячим людям треба озвучувати.

Проблема багатьох сайтів — недбало написаний код; у такому разі незряча людина має здогадуватися, що який напис означає, а деякі елементи не помітить узагалі. Якщо дизайнер і веброзробник не подбали про зручну структуру HTML, коректні теги для елементів, а також спеціальні підказки для екранних читачів (ARIA), сайт стає недоступним для частини аудиторії.

Зразок шкідливої дизайн-практики — це ставити посилання «Читати більше…» (англ. «Read more…»). Для незрячої людини фраза «Читати більше…» буде відірваною від заголовка, і буде незрозуміло, яка саме стаття відкриється після натискання.

Перед тестуванням потрібно обов’язково ознайомитися з принципом роботи скрінрідера, а також спробувати його на своєму пристрої (оптимально, на смартфоні). Звісно, це лише віддалено подібне до того, як екранним читачем послуговуються люди з інвалідністю, але дасть яскравіше уявлення, ніж якщо почитати про це у статті.

Стандартні вбудовані читачі, які є в усіх відомих операційних системах, і які можна увімкнути в налаштуваннях у розділі «Доступність» (англ. Accessibility):

• VoiceOver (Mac та iOS);
• Narrator (Windows);
• TalkBack (Android).

Сторонні професійні читачі, які треба встановлювати на пристрій і налаштовувати окремо. Незрячі люди часто мають портативну версію свого скрінрідера на флешці та не витрачають час на налаштування програми з нуля на чужому комп’ютері. Ось два найпопулярніші екранні читачі для Windows:

• NVDA (безплатний);
• JAWS (платний).

Трапляються курйозні випадки, коли незряча людина сидить біля під’їзду і переписується з друзями на смартфоні, слухаючи через навушники голос екранного читача. А сусіди, які проходять повз, інколи думають, що людина несповна розуму, бо тицяє пальцем у вимкнений екран. А ви ж тепер розумієте, що насправді відбувається?

4.2. Особливості навігації

Ми вже з’ясували, що екранні читачі покладаються на HTML-розмітку сторінки і не зачитують те ж саме, що бачать на екрані зрячі користувачі. Крім того, люди із зором у межах медичної норми можуть швидко просканувати сторінку поглядом і перескочити з одного місця на інше за допомогою мишки. А от люди з порушеннями зору зосереджені лише на одному елементі одночасно — кнопці, текстовому полі чи заголовку — і не можуть просто пропустити шматок контенту.

Відповідно, коли виникає потреба щось пояснити користувачеві скрінрідера, деякі поняття просто не мають сенсу. От ви, наприклад, почали фасилітувати сесію через Skype, а хтось із тестувальників не може знайти, як увімкнути демонстрацію екрану. Поради на зразок «там унизу по центру є кругла кнопка з іконкою комп’ютера» допоможуть як мертвому кадило.

Недоречні підказки

• «Вгорі екрану».
• «Прогорніть сторінку донизу».
• «Погляньте на кнопку в кутку».
• «Натисніть на іконку “Закрити”».

Корисні підказки

• «Будь ласка, перейдіть до попереднього/наступного елемента».
• «Перейдіть до останнього заголовка на сторінці».
• «Перейдіть до першого елемента зі списку».
• «Будь ласка, закрийте це модальне вікно».

Коли людина не бачить екран, то існує лише чотири варіанти руху — вперед, назад, на рівень вище за ієрархією та на рівень нижче за ієрархією. Також, багато скрінрідерів мають клавіатурні скорочення, аби, наприклад, швидко перемикатися між всіма кнопками на сторінці чи перестрибнути до навігації. Але це працює за умови коректно скомпонованого сайту чи застосунку.

5. Як опрацьовувати результати?

Коли сесії відбулися, треба якнайшвидше впорядкувати і розтлумачити зібрану інформацію, поки вона свіжа, і ось як це зробити.

Відфільтрувати «сигнал» від «шуму»

Не все, що каже вам користувач, варто сприймати за чисту монету. Люди інколи говорять неправду з добрих міркувань, наприклад, щоб не образити вас як творця дизайну. Або інколи вони вмикають «режим художника» і висловлюють забаганки, які їм суб’єктивно здаються корисними, але в реальному житті не знадобляться.

Аби відсіяти ненадійну інформацію, уважно спостерігайте за діями. Якщо людина не може знайти щось на сайті вже третю хвилину, це вагоміший аргумент, ніж коли людина швидко все знайшла і каже: «Мені здається, що ця кнопка далеко розміщена». Обіцянки у стилі «я би користувався чимось» менш точні, ніж розповідь людини про справжню ситуацію в минулому, коли подібна функція допомогла досягти мети.

Об’єднати подібне

Коли ви випишете в документ усі відфільтровані проблеми, радше за все виявиться, що їх так багато, що команда все не виправить одним махом. Крім того, після сесій буває складно визначити, на чому сконцентруватися спочатку, а що відкласти на потім. Тож варто об’єднати або позначити тегами схожі скарги та ідеї користувачів. Чи є проблеми, які стосуються того самого модуля чи функції? Скільки проблем зачіпають один і той же аспект доступності (наприклад, альтернативний текст до картинок, загальна навігація)? Може, є знахідки, які стосуються того самого сценарію (приміром, купівлі, фільтрації, режиму порівняння)

Пріоритезувати

Як зрозуміти, що якісь проблеми більш серйозні за інші? Не так складно, як здається. Ось дві майже безпрограшні ознаки.

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

І порада наостанок: у тестуванні доступності необхідно звертати увагу на ширший контекст, ніж цифровий продукт. На загальний успіх сервісу впливає не лише сайт чи застосунок, а й бізнес-модель і бізнес-процеси. Наприклад, якщо не передбачено жодних альтернатив скануванню QR-коду для підтвердження реєстрації, сервіс буде дискримінувати незрячих людей. Або якщо єдиний спосіб підтвердити замовлення — це телефонний дзвінок оператора, сервіс виявиться недоступним для клієнтів із порушенням слуху.

Висновки

1. Тестування доступності — недооцінений метод, завдяки якому ви можете виявити проблеми в галузі як доступності, так і юзабіліті. Тестування найкраще працює в поєднанні з аудитом.
2. Для тестування доступності цифрових продуктів можна легко знайти тестувальників через тематичні спільноти та громадські організації. Варто пам’ятати, що час тестувальника у більшості випадків має бути оплаченим.
3. Серед практиків вебдоступності поширена думка, що залучення незрячих користувачів — найбільш вразливої категорії — до тестування допоможе виявити до 80% усіх можливих проблем з доступністю.
4. Сценарій тестування треба складати максимально реалістично і без зайвих підказок, щоб спостерігати за природним способом мисленням і діями людини, а не схиляти її до висновків, які потішать самолюбство дизайнера і команди.
5. Люди з інвалідністю послуговуються допоміжними технологіями та сприймають веб дещо в інший спосіб. Щоб уникнути прикрих непорозумінь, вивчіть основи роботи екранних читачів і толерантну термінологію.