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

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

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.