Інтерпретація результатів

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

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

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

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

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

Проблема зі зчитувачем екрану. Наприклад, розробники могли вкоротити довгі заголовки таблиці за допомогою атрибуту abbr, але зчитувач екрану може не надавати інтерфейс користувача для читання скороченій версії. Тут підходящим дією буде повідомлення про помилку в зчитувач екрану постачальнику або розробникам, і може бути пошук методу, який працює в зчитувач екрану, або відмітка про обмеження у документації та пропозиція альтернативного інструменту або навігаційної стратегії, які працюють. Повідомлення про результати тестування доступності. При повідомленні про результати оцінки доступності, точно зафіксуйте, що оцінювалося. Якщо ви тестували відповідність певному стандарту, будьте конкретні у точній вказівці, де відповідність було успішно, а де ні. При виявленні проблеми, постарайтеся уявити її в реальних, людських термінах, і поясніть, як проблема може негативно впливати на користувачів. Опишіть як відтворити проблему і протестувати її дозвіл. Запропонуйте практичні методи для досягнення узгодженості або поліпшення доступності.

Наприклад, ви могли б повідомити про проблему з Web-сайтом загального доступу до відео наступним чином. Проблема: Спадне меню не може бути відкрито без приміщення покажчика миші над верхніми пунктами меню, а фокус клавіатури зникає з екрану при використанні клавіші Tab для переміщення в меню. Як відтворити: Відкрийте сторінку в браузері і спробуйте дістатися до підпунктів меню за допомогою тільки клавіатури.

Пояснення: Навігація Web повинна бути незалежною від пристрою, щоб користувачі, що використовують пристрої відмінні від миші – такі як сліпі користувачі або користувачі з моторними вадами – могли отримати доступ до контенту і функцій. В даний час такі користувачі не можуть отримати доступ до позицій в підменю, а зрячі користувачі використовують клавіатуру можуть бути поставлені в глухий кут, коли індикатор фокусу зникає. Наслідки для відповідності: Взаємодія з клавіатурою є вимогою відповідності WCAG 1.0 і WCAG 2.0 Level "A" (див. WCAG 1.0 Guideline 9 і WCAG 2.0 Guideline 2.1).

Запропоновані рішення: Коли JavaScript недоступний, використовуйте простий список посилань на підсторінки для кожного підсписки навігації. На підсторінка, уявіть основну навігацію, за якою слідує подспісок. Коли JavaScript доступний, видаліть подспісок з DOM і додайте підсписки для кожного пункту меню при події клацання, яке можна активувати клавіатурою, мишею, пристроєм розпізнавання мовлення, і сенсорним екраном в рівній мірі.