Вимоги взаємодії

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

Там, де підтримка теоретично присутній, може вимагатися час, щоб допоміжні технології їй скористалися. Наприклад, нові зчитувачі екрану працюють значно краще з запускаються JavaScript оновленнями структур HTML, чим більш старі зчитувачі екрану. Навіть давно створена підтримка доступності може продовжувати відрізнятися на різних платформах. Наприклад, модуль Adobe Flash Player давно виводить інформацію в API доступності Windows, але не в еквівалентному API Apple або GNOME.

Існує також зазвичай деяка затримка між появою підтримує технології і її широким поширенням. У той час як браузери і компоненти Plug сьогодні зазвичай бувають безкоштовними, основні допоміжні технології можуть бути дуже дорогими. Наприклад, одним з найбільш популярних зчитувачів екрана є JAWS для Windows компанії Freedom Scientific. Нова версія виходить майже кожен рік. JAWS Professional стоїть в роздріб $ 1095, і навіть якщо ви витратили $ 200, щоб отримати Software Maintenance Agreement для двох наступних версій, оновлення буде, тим не менш, коштуватиме близько $ 500. Отже, хоча подальшим випуском є версія 9, можна зустріти безліч користувачів JAWS, які використовують старі версії.

Тому, коли ви збираєтеся створювати Web-сайти для публічної Web, необхідно приймати до уваги взаємодію із суттєво різними комбінаціями використовуваних користувачем технологій. Існує чотири підходи:

· Поступове вдосконалення Web-сайту, тестуючи підтримку в міру просування.

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

· Надання альтернативних версій з таким же контентом або функціями.

· Рекомендації клієнтам про те, які технології їм потрібні для підтримки та надання прикладів компаній, які підтримують ці технології.

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

Однак сумісність вперед і міжплатформена сумісність все ще є проблемами, тому відкриті, стандартні технології повинні бути кращі в порівнянні з патентованими, нестандартними технологіями.

Наприклад, ви можете розробляти навчальне додаток в мережі Інтранет для великої корпорації. Вони можуть просити зробити додаток доступним, але не визначити стандарт, якого необхідно дотримуватися. Після розмови з їх відділом ІТ ви дізналися, що кожен має саму останню версію Internet Explorer з активованою підтримкою JavaScript, встановленої і включеною технологією Flash, і будуть забезпечені сучасною допоміжної технологією, яка потрібна для підтримки цих позицій. Тепер, навіть якщо компанія перейде на платформу на основі Unix, будуть існувати допоміжні технології, які підтримують JavaScript, але текст Flash і елементи управління будуть доступні тільки в Windows. Можна безпечно зробити сценарії і Flash базовою вимогою програми. Але ви вирішили використовувати Flash тільки для відтворення відео, і створити безліч елементів управління для відео Flash за стандартами Web, оскільки елементи керування Flash доступні тільки допоміжної технології на платформі Windows. У цьому випадку додаток буде як і раніше є, навіть якщо компанія мігрує на Unix.

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