Коли має виконуватися тестування?

"Тестуйте рано, тестуйте часто" є старою приказкою програмування. Надія на тестування в кінці процесу розробки містить дві небезпеки:

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

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

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

Розуміння вимог

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

Зовнішні вимоги

Часто вимоги приходять із зовнішніх джерел, таких як:

• Уряд. Воно має звичайно або загального законодавства проти дискримінації людей з функціональними обмеженнями, а не вимоги певного стандарту або перерахування точних вимог відповідності. Важливим винятком є випадок, коли законодавство вимагає використовувати певний стандарт для публічного сектора. Наприклад, Section 508 (http://www.Section508.gov/) є частиною федерального законодавства США, яке вимагає, щоб Web-сайти, створювані для федеральних агентств відповідали як мінімум спеціальному безлічі певних вимог. Сторінка WAI про політиків, що відносяться до доступності Web (http://www.w3.org/WAI/Policy/) містить частковий список аналогічного законодавства. Але щоб отримати авторитетну думку про зобов'язання у ваших умовах, порадьтеся з юристом.

• Політика замовників. Наприклад, компанія Shell в даний час намагається реалізувати на своїх Web-сайтах вимоги відповідності рівню "Double-A" рекомендацій WCAG 1.0, тому при розробці Web-сайту для Shell ви повинні будете задовольнити (принаймні) тим же стандартом.

• Маркетингова корисність. Відповідність певному стандарту, такому як Section 508, може допомогти продажу проекту стурбованим доступністю клієнтам.

• Внутрішня політика доступності в організації. Наприклад, проекти, створювані в BBC, повинні відповідати Правилам доступності v1.3 компанії BBC.

Деталі відповідності

Важливо отримати як можна більш чітке уявлення про зовнішні вимогах. Деякі стандарти доступності мають більше одного можливого рівня або типу відповідності, тому особливо важливо визначити, що потрібно. Наприклад, WCAG 1.0 має три рівні відповідності:

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

2. Люди з деякими фізичними вадами "будуть відчувати труднощі при доступі до інформації" в документі, який не пройшов рівень "Double-A".

3. Люди з деякими фізичними вадами "будуть відчувати іноді труднощі при доступі до інформації" в документі, який не пройшов рівень "Triple-A".

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

Вимоги відповідності повинні грунтуватися на технології "підтримуючої доступність" контенту. Така технологія має:

• продемонструвати свою роботу з допоміжною технологією користувачів;

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

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

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