Інспекція структури

Багато інструменти інспекції створені для дослідження структури Web-контенту. Структура, кажучи просто, визначає які є компоненти Web-сайту, і як вони пов'язані один з одним. Наприклад, в об'єктній моделі документа (DOM) HTML текст може бути визначений як мітка поля форми за допомогою елемента label. Браузери перетворює код HTML в об'єктну модель документа. Браузер пов'язує різну поведінку з певними компонентами. Наприклад, якщо клацнути на мітці прапорця, то він буде зазвичай ініційований.

Настільні робочі середовища та програми підтримують інтерактивність з считивателямі екрану, програмним забезпеченням розпізнавання мовлення, та іншими допоміжними технологіями, надаючи аналогічну структуру, яка представляє контент і функції, доступні в візуальному представленні. У Windows основна структурна система називається Microsoft Active Accessibility (MSAA), або UI Automation в Vista (http://msdn.microsoft.com/en-us/library/ms788733.aspx). Наприклад, діалогове вікно має ряд пов'язаних нащадків, таких як заголовок, поля, кнопки, і мітки. Типова допоміжна технологія має справу переважно з поданням браузерів і модулів Web-контенту в термінах цих структурних систем, а не з обробкою об'єктних моделей Web-документів безпосередньо.

Існують засоби інспекції, як для структур рівня настільного комп'ютера, так і для об'єктних моделей рівня Web. Для настільного комп'ютера OS X поставляється з Accessibility Inspector (http://developer.apple.com/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTesting/chapter_5_Section_2.html) і Accessibility Verifier (http://developer.apple.com/documentation/ Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTesting/chapter_5_Section_3.html). Microsoft надає інструменти інспекції для Microsoft Active Accessibility 2.0 і Microsoft Active Accessibility 1.3. Accerciser (http://live.gnome.org/Accerciser) доступний для допоміжної технології GNOME - SPI API.

Інструментами для запису в об'єктну модель документа (X) HTML є DOM Inspectors, як видно в Opera Dragonfly (http://www.opera.com/products/dragonfly/) і Firebug (http://www.getfirebug.com) і пакети інструментів доступності, такі як Web Accessibility Toolbar для Internet Explorer і Opera (http://www.wat-c.org/tools/index.html) і ICITA Firefox Accessibility Toolbar (http://firefox.cita.uiuc.edu).

Інспектори DOM показує дерево елементів, атрибутів і текст, створений з серіалізациі (X) HTML, у той час як інспектори доступності Web абстрагують окремі компоненти або відносини і перераховують їх. Наприклад, вони можуть перерахувати всі поля з їх мітками або всі заголовки, або всі посилання.

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

Не весь контент може інспектуватися за допомогою DOM або інспекторів доступності Web. Інспекція того, що доступно для структур доступності рівня настільного комп'ютера важливо для перевірки, який контент модуля (медіа-плеєрів, контенту Flash, і аплетів Java) доступний допоміжної технології, яка використовує ці моделі доступності.

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

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

• Використання утримуваної ротом указки для натискання клавіш під час тестування доступності клавіатури.

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

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

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

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