Детальна інспекція

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

Проект WCAG 2.0 ділить свої критерії кращих методів з огляду на чотири принципам. Контент і функції повинні бути:

• таким, щоб його сприймали (наприклад, зображення повинні мати текстові еквіваленти).

• взаємодія (наприклад, повинно бути можлива взаємодія з Web-сайтом без миші і переміщення по ньому за допомогою зчитувача екрану).

• Зрозумілим (основний матеріал повинен бути не складнішим, ніж потрібно, а Web-сайт повинен діяти передбачуваним чином).

• Надійним (наприклад, Web-сайти повинні взаємодіяти з різними агентами користувачів, а навігація повинна бути узгодженою).

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

Сприймаємість

Одне з підмножин проблем сприйняття обертається навколо надання альтернативної інформаційного середовища різного типу. Можна перевірити текстові еквіваленти, відключаючи в браузері вивід зображень і мультимедіа і переглядаючи сторінку. Але потрібно приділити особливу увагу елементам img і input. Зазвичай рекомендується задавати для всіх чисто декоративних зображень порожні значення атрибуту alt (alt =""), щоб зчитувач екрану просто пропускав їх. Проте в наступних випадках:

• зображення, які є єдиним контентом посилань

• кнопок форми коли цим елементам задаються атрибути alt = "", зчитувачі екрану будуть зазвичай інтерпретувати зображення або кнопку, як якщо б атрибут alt = "" був відсутній, і спробують надати його значення (наприклад, читаючи URL зображення).

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

Інша група проблем сприйняття пов'язана зі стильовим оформленням сторінки. Тут є три області для дослідження:

Чи є запропоноване уявлення сторінки розумно доступним? Наприклад, чи є достатнім контраст кольорів? Чи є текст досить великим? Крім розгляду самої сторінки, можна використовувати такі інструменти як Juicy Studio CSSAnalyser (http://juicystudio.com/services/csstest.php) для перевірки комбінацій кольорів фону і переднього плану відповідно до формул, які призначені для вимірювання легкості читання.

Чи можна пропозиції видавця для подання безпечно змішувати зі звичайними перевагами користувачів, націленими на поліпшення легкості читання, такими як збільшення розміру шрифту, масштабування, і інші кольори за замовчуванням "? Спробуйте збільшити розмір тексту приблизно на 2 - 5 кроків, не турбуйтеся, якщо результати не будуть досконалі з точки зору пікселів, але турбуйтеся про те, що чи не буде компонування зруйнована так, що подання контенту буде важко прочитати. Спробуйте змінити колірні переваги і подивитися, що станеться. Якщо CSS видавця задає кольори, він повинен явно задавати фон і передній план разом, щоб гарантувати, що комбінація незвичайних уподобань і стилів видавця не приведуть до нечитаний або невидимому тексту. Популярні браузери дозволяють користувачам примусово ставити свої власні уподобання щодо кольору і відключити фонові зображення CSS. Коли ви спробуєте зробити це самостійно, можуть виявитися неправильно поняті методи заміни зображень CSS, які приховують текст за межами екрану, тому що зображення не завантажується, але текст тим не менше буде невидимим.

Якщо пропозиції видавця за поданням відкидаються, чи буде вся інформація, передана такими припущеннями, зберігатися в контенті Web для використання при стильовому оформленні за замовчуванням агента користувача або стильового оформлення користувача?

Спробуйте вимкнути CSSі проінспектувати об'єктну модель документа, щоб перевірити, що заголовки розмічені як заголовки, і таблиці використовуються для табличних даних, а не для перегляду.

Взаємодія

Здоров'я і безпека є критично важливою, хоча і рідко розглядається, частиною створення взаємодії Web-сайту. Але миготливий контент має ризик викликати напад світлочутливої епілепсії. Можна зробити знімок c екрана використовуваного Web-сайту і завантажити його в утиліту Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) для перевірки, чи не може миготливий контенту бути небезпечним для користувачів. Очевидно, що це особливо важлива турбота, якщо створюється Web-сайт для загального доступу до відео. На етапі проектування продукту, можна розглянути питання про включення автоматичного процесу скринінгу завантажуються відео-роликів. Крім цього гарним способом тестування взаємодії Web-сайтів буде просто спроба побачити, чи можна отримати доступ до всього істотного контенту і функцій за допомогою різних пристроїв:

• Спробуйте використовувати свій сайт тільки за допомогою клавіатури. Чи завжди чітко вказаний поточний фокус? Чи всі функції будуть доступні за допомогою клавіатури?

• Спробуйте використовувати свій сайт за допомогою сенсорного екрана.

• Спробуйте поперемещаться по своїй Web-сторінці за допомогою голосових команд, використовуючи браузер Opera для Windows і його додатковий модуль Voice, або Windows Vista Speech Recognition і браузер Internet Explorer. (Примітка: комерційна система розпізнавання мови якості диктування була представлена в Mac OS X у формі MacSpeech Dictate, але в даний час не існує еквівалентної розробки на безкоштовних платформах * nix.)

Зчитувачі екрану та інші допоміжні технології можуть використовувати семантичну структуру (X) HTML для правильної асоціації контенту та забезпечення навігації по контенту. Наприклад, зчитувачі екрану можуть дозволяти користувачам переміщатися до наступного входження елементу заголовка або елементу іншого типу, або можуть перерахувати всі входження певного типу. Правильне використання елементів label і legend дозволяє допоміжної технології зв'язати мітки з правильними полями форм; правильне використання елементів th і атрибутів header, scope, і axis дозволяє їй зв'язати заголовки таблиці з осередками даних таблиці. Семантичну структуру можна оцінити за допомогою інспектора об'єктної моделі документа (DOM), такого як в Opera Dragonfly. Інструменти інспекції доступності, такі як Firefox Accessibility Extension можуть зробити такі завдання легше, наприклад, перераховуючи заголовки на сторінці, або перераховуючи атрибути полів форми (швидко показуючи, які з них не та меют пов'язаних міток). Подивіться на Рис. 1 як на приклад.

Рис. 1. Знімок з екрану інформаційного вікна форм Firefox Accessibility Extension для нової домашньої сторінки BBC