5.14: Договір про доступність
- Page ID
- 11252
Припускаючи, що ви отримали пропозиції від постачальників, перевірили їх розуміння веб-доступності та готові перейти до договірної угоди про ліцензування або придбання програмного забезпечення або веб-програми у одного з них, важливо викласти вимоги до веб-доступності в оформленому договорі.
Нижче наведено два підходи до визначення вимог доступності: перший - це більш загальний підхід, який спирається на конкретний стандарт, на який можуть посилатися постачальники, а другий - більш детальний підхід, який спирається на стандарт, але також постачає конкретні вимоги, які повинні бути дотримані.
Розділ 508 Формулювання
Національний центр з питань інвалідності та доступу до освіти (NCDAE) надає певний стандартний текст контрактів, що робить доступність вимогою угоди. Цей текст буде актуальним для тих, хто закуповує відповідно до положень розділу 508:
Постачальники повинні гарантувати, що система управління курсами, що міститься в пропозиції, повністю відповідає Розділу 508 Закону про реабілітацію 1973 року з поправками, внесеними в 2017 році. (Інформацію про розділ 508 див. www.section508.gov.) Це включає в себе як студент, так і викладач, а також включає в себе всі інструменти взаємодії (наприклад, чати, дискусійні форуми), і доповнення (наприклад, функції оцінки). Постачальники повинні заявити, чи будь-яка частина розглянутої версії не повністю відповідає Розділу 508, а також способи, за допомогою яких запропонований продукт не відповідає вимогам.
Джерело: Національний центр з питань інвалідності та доступу до освіти
Хоча цей підхід може бути достатнім у деяких випадках, коли було підтверджено, що постачальник розуміє вимоги розділу 508, будуть випадки, коли постачальники не знають, відповідає їхній продукт чи ні. Щоб зменшити цю ймовірність, можна вказати деталі вимог розділу 508, щось на зразок вимог, викладених у розділі «Формулювання WCAG 2.0» нижче.
WCAG 2.0 Формулювання
Як і формулювання для RFP, введені раніше в цьому підрозділі, для контрактів важливо надати конкретні деталі, щоб уникнути потенційної плутанини для постачальників, які можуть не повністю усвідомлювати вимоги WCAG 2.0. Нижче наведено адаптовану версію редакції Розділу 508 вище, із запропонованою формулюванням, яка визначає узгоджений порядок дій, якщо проблеми доступності будуть виявлені після виконання контракту, а також конкретні вимоги до доступності закупівельної організації. Хоча вказано WCAG 2.0, ця мова буде придатною для тих, хто розробляє вимоги до веб-доступності, пов'язаних з Aoda.
Зразок 2: Контракти купівлі конкретних продуктів Постачальники повинні гарантувати, що система управління курсами, що міститься в пропозиції, повністю відповідає Керівництву доступності веб-контенту (WCAG 2.0), рівень AA, як опубліковано Ініціатива веб-доступності (WAI) W3C, узагальнені в список нижче (див. WCAG 2.0 для отримання додаткової інформації). Це включає в себе як студент, так і викладач, а також включає в себе всі інструменти взаємодії (наприклад, чати, дискусійні форуми), і доповнення (наприклад, функції оцінки). Постачальники повинні заявити, чи будь-яка частина розглянутої версії не повністю відповідає WCAG 2.0 Level AA, і описати способи, за допомогою яких запропонований продукт виходить з ладу. Продавці погоджуються, що їх продукт буде продовжувати відповідати цим вимогам, і в разі потенційних порушень є виявлено, організовує, щоб такі питання були вирішені, якщо інше не узгоджені винятки не зазначені в письмовій формі.
G1.1.1 (Рівень А)
Усі значущі зображення в інтерфейсі користувача (UI) включають альтернативний текст у вигляді альтернативного тексту, який точно описує значення або функцію, пов'язану з зображенням.
G1.2.2 (Рівень А)
Якщо відео надано, або в самому продукті, або в пов'язаній документації, змістовне діалогове вікно розмови у відео включає закриті підписи, створені особою, а не автоматизованою службою.
G 1.3.1 (Рівень А)
Вміст структурований з використанням належних заголовків розділів HTML (наприклад, h1, h2) і належних списків (тобто, ol, ul, li), а не форматування, що просто створює зовнішній вигляд заголовка або списку.
G 1.3.2 (Рівень А)
При навігації по елементам інтерфейсу користувача та вмісту за допомогою лише клавіші Tab курсор приймає логічний шлях, зліва направо і зверху вниз.
G 1.4.1 (Рівень А)
Коли колір використовується значущим чином, інший метод, крім кольору, використовується для представлення того ж значення.
G 1.4.3 (Рівень АА)
Коли текст відображається на кольоровому тлі, передбачається мінімальний контраст між двома з 4, 5:1 для тексту стандартного розміру та 3:1 для більшого тексту.
G 2.1.1 (Рівень А)
Всі елементи інтерфейсу користувача або вмісту, які функціонують клацанням миші, також функціонують за допомогою лише клавіатури.
G 2.4.1 (Рівень А)
Передбачені засоби, які дозволяють користувачам допоміжних технологій, або лише користувачам клавіатури, пропускати повз повторюваних елементів, таких як меню та навігаційні панелі, використовуючи або обхідні посилання, або орієнтири WAI-ARIA.
G 2.4.4 (Рівень А)
Весь текст посилання має сенс або самостійно, або в контексті інших суміжних посилань, точно описуючи призначення або функцію посилання.
Г 3.3.1 (Рівень А)
Повідомлення про помилки представлені таким чином, який можна споживати допоміжною технологією, не вимагаючи від користувача пошуку вмісту, щоб знайти їх, або послідовно представлені в одному місці на сторінці, або за допомогою ролі попередження ARIA.
Г 3.3.2 (Рівень А)
Форми форматуються таким чином, що явно пов'язує мітки з полями введення, і надаються достатні інструкції для опису очікуваного введення в кожному полі.
G 2.4.7 (Рівень АА)
Під час навігації по інтерфейсу користувача за допомогою лише клавіші вкладки положення фокусування легко відстежується візуально через елементи на екрані.
G 4.1.1 (Рівень А)
(Виняток: відповідає цій вимозі в тій мірі, в якій порушення розмітки не створюють бар'єрів, які впливають на доступ до допоміжних технологій.)
Розмітка інтерфейсу відповідає специфікаціям HTML5.