5.11: Питання доступності під час демонстрації продуктів

Last updated
Save as PDF

Page ID: 11312

Digital Education Strategies
The Chang School

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

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

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

Інструментарій: Див. Питання доступності для демонстрації продуктів для колекції питань, які можна задати під час опитування постачальників.

Ось список з 10 можливих питань і очікуваних відповідей:

1. Яким стандартам доступності відповідає ваш продукт? На якому рівні (якщо WCAG)?

Залежно від юрисдикції постачальника слід згадати місцевий стандарт доступності (наприклад, розділ 508 в США; AODA в Онтаріо) або згадати WCAG. Додані бали, якщо постачальник з іншої юрисдикції, і згадує вимоги вашої юрисдикції, якщо вони відрізняються від їх власної.

Як мінімум, де WCAG є орієнтиром вибору постачальника, слід згадати рівень А або поговорити про те, що ще потрібно вирішити, щоб задовольнити рівень А. Якщо згадано рівень АА, можуть бути надані додаткові бали. Якщо згадується рівень AAA, це попереджувальний знак, оскільки дуже мало, якщо будь-які складні системи будуть відповідати вимогам рівня AAA. Запитайте, які функції AAA були реалізовані в системі.

2. Чи доступний ваш продукт без миші? Продемонструйте, будь ласка.

Відповідь завжди повинна бути «Так». Постачальник повинен мати можливість продемонструвати за допомогою клавіші Tab для навігації по інтерфейсу користувача (UI). Усі функціональні елементи, такі як меню, посилання, кнопки та форми тощо, повинні мати можливість отримувати фокус, а користувачі повинні мати можливість переміщатися по меню та відкривати елементи, використовуючи лише клавіатуру. Слідкуйте за елементами, які можуть отримати фокус, але не працюють натисканням клавіші.

3. Ваш продукт був протестований за допомогою допоміжних технологій? Якщо так, то з якими з них?

Повинні відповісти «Так».

Слід згадати про програму читання з екрана як мінімум. Повинні бути в змозі визначити, які читачі з екрана, такі як ChromeVox, JAWS, NDVA тощо Додані пункти, якщо вони також згадують VoiceOver та/або Talkback для мобільних пристроїв.

4. Хто проводив тестування?

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

5. Якою була методика тестування? Якими були результати?

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

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

6. Як доступність вбудована в процес забезпечення якості (QA) вашої компанії?

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

7. Якщо ви розгортаєте оновлення після того, як ми придбаємо продукт, як ви можете запевнити нас, що оновлення не порушать доступність?

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

8. Чи використовує ваш продукт WAI-ARIA? Якщо це так, то як так?

Там, де продукт має досить складний інтерактивний інтерфейс, відповідь повинна бути «Так». Це вказує на те, що постачальник розуміє складні проблеми доступності, пов'язані з індивідуальною веб-інтерактивністю.

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

9. Чи адаптується ваш продукт відповідально до різних розмірів екрану? Продемонструйте, будь ласка.

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

10. Чи збільшує ваш продукт чисто, використовуючи лише функцію масштабування браузера? Продемонструйте, будь ласка.

Повинні відповісти «Так». Повинна мати можливість використовувати функцію z oom браузера, щоб збільшити розмір вмісту щонайменше до 200% без вмісту, що стікає з боку екрана або перекривається суміжним вмістом. Додані точки для розмірів масштабування більше 200%. Хороша адаптація масштабу вказує на те, що відносні заходи (em,%) були використані для розміру елементів, а не абсолютних вимірювань (px, pt), що також є вимогою для хороших адаптивних конструкцій.