
- •Що таке доступність?
- •Чому важлива доступність?
- •Вимоги закону про доступність
- •Потенційні ринки
- •Системи пошуку
- •Етика та брендінг
- •Проектування з урахуванням доступності
- •Вимоги взаємодії
- •Альтернативний контент
- •Визначення взаємодії
- •Рекомендації по доступності контенту Web версія 2.0
- •Інші стандарти
- •Коли має виконуватися тестування?
- •Деталі відповідності
- •Перевищення очікувань
- •Важливість інтерфейсу користувача
- •Персона з функціональними обмеженнями
- •Вибір стандарту доступності
- •Зміст закону
- •Експертне тестування
- •Інспекція структури
- •Детальна інспекція
- •Сприймаємість
- •Зрозумілість
- •Практичні розгляди
- •Вибір завдань
- •Інтерпретація результатів
- •Висновки
Практичні розгляди
Пам'ятайте, що сама робоче середовище тестування повинна бути доступна. Наприклад, якщо ви готуєте письмові тестові матеріали, треба бути готовим запропонувати їх в альтернативних формах. Повторення робочого середовища користувача для перегляду Web у звичайному місці тестування може бути скрутна, тому може бути більш реалістично тестувати у користувача вдома. Якщо це неможливо, то навіть повністю віддалене тестування може бути цінно.
Одним приватним міркуванням, яке, ймовірно, ще більш важливо для користувачів з фізичними вадами, ніж для інших користувачів, буде те, з якими технологіями вони знайомі. Допоміжна технологія може додати багато шарів складності для їх досвіду роботи з комп'ютером, створюючи велику поділ між користувачами комп'ютерів новачками та досвідченими, і розділяючи користувачів на спільноти, які можуть бути дуже майстерні зі своєю власною налаштуванням, але вкрай дезорієнтовані незнайомій технологією. (Уявіть, як важко буває користувачам без фізичних вад, які впливають на їх можливості використання комп'ютерів, переключитися з комп'ютерів Mac на PC!). Якщо взяти досвідченого користувача зчитувача екрану Window-Eyes, посадити його перед незнайомою машиною з встановленим зчитувачем екрану JAWS, і попросити його протестувати Web-сайт, то буде дуже важко відрізнити його проблеми з JAWS від проблем, які створює Web-сайт.
Враховуючи значні відмінності між версіями і враховуючи, як часто користувачі модифікують свою налаштування, це може бути важко, навіть якщо надати користувачеві Window-Eyes! У зв'язку з цим, якщо тільки ви не спеціально тестуєте, як добре буде зберігатися доступність Web-сайту з незнайомими настройками (наприклад, в бібліотеці або на комп'ютері приятеля), то краще дозволити користувачам тестувати зі своєю власною налаштуванням або чим-то наскільки можливо близьким до неї.
Аналогічно, якщо тільки ви не хочете спеціально протестувати користувачів новачків або користувачів експертів, ви повинні намагатися вибрати користувачів, які мають близько року досвіду використання своєї поточної налаштування для доступу до Web. Як допоміжну технологію, так і угоди самої Web вивчити не просто. З користувачами новачками ви не дізнаєтеся, чи виникли проблеми у зв'язку з сайтом, або властиві самому процесу навчання, а експерти можуть мати свої власні прийоми, яких не мають інші.
Вибір завдань
Вкрай корисно навіть спостерігати за користувачами, які просто досліджують Web-сайт. Як і для будь-якого іншого тестування користувачів:
Спробуйте задати користувачам для виконання кілька спеціальних завдань.
Запитайте у них, що вони думають, і вислухайте, що вони скажуть.
Приділіть увагу тому, що вони роблять, так як це може відрізнятися від того, що вони говорять: затверджувані переваги є поганим керівництвом для продуктивності.
При проектуванні сайту необхідно зосередитися на трансакціях, які хочуть виконати користувачі на сайті, а не на конкретних елементах управління, які їм потрібно використовувати. Аналогічно при тестуванні доступності поставлені завдання мають (принаймні на початку) відображати реальні цілі відвідувача при використанні сайту, а не зосереджуватися на їх взаємодії з певними елементами управління. Ці транзакції будуть звичайно аналогічні для людей які мають фізичні вади і не мають. Наприклад, при тестуванні сайту загального доступу до відео на доступність не починайте з питання про те, чи можуть вони використати певні елементи управління ("Це регулятор гучності. Чи можете ви налаштувати гучність?"). Замість цього дайте їм сценарій і попросіть виконати ключові завдання користувачів. Наприклад:
Огляд наявних відео і вибір одного з них для відтворення.
Пошук відео.
Завантажити відео на сайт.
Зупинка відтворення відео, відтворення відео, відключення звуку відео, включення звуку відео, перемотування відео в зворотному напрямку і повторне відтворення.
Оцінка відео.
Поділитися відео з приятелем.
Таким чином ви, швидше за все, виявите безліч проблем, яких не чекали. Наприклад, користувачі зчитувача екрану не зможуть знайти поле пошуку або елементи керування для відео. І навпаки, користувачі можуть мати навігаційні стратегії для роботи з Web, про які ви навіть можете не здогадуватися.