Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПРАКТИЧНЕ ЗАНЯТТЯ WEB-0105.docx
Скачиваний:
3
Добавлен:
08.08.2019
Размер:
270 Кб
Скачать
☆

Зрозумілість

Оцінка зрозумілості ще більше суб'єктивна ніж тестування легкості читання. Якщо тільки оцінювач не є новою людиною у проекті, або не є професійним редактором, то він, ймовірно, є не кращим людиною для оцінки, чи буде основний вміст зрозуміло наскільки можливо. Можна, однак, скористатися інструментом Readability Test (http://juicystudio.com/services/readability.php) компанії Juicy Studio для отримання приблизного уявлення про те, наскільки простим є основний вміст сайту.

Проте деякі аспекти є цілком об'єктивно тестованими, такі як має контент метадані мови, які дозволяють (наприклад) зчитувачем екрану і голосовим браузерам читати контент з правильною вимовою. У HTML можна використовувати інспектор DOM для перевірки присутності для документа атрибута lang документа і кожної зміни мови.

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

Надійність

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

  • Валідатор WDG HTML з активованими попередженнями (http://htmlhelp.com/tools/validator/)

  • Валідатор W3C CSS (http://jigsaw.w3.org/css-validator/)

  • Лінтер JSLint JavaScript (http://www.jslint.com)

Потім можна досліджувати код вглиб, щоб перевірити, що його кошти використовуються правильно. Наприклад, можна перевірити, що використовуються власні елементи управління HTML, а не сумнівні елементи управління з безглуздими елементами і JavaScript, і що JavaScript використовує виявлення властивостей, а не використовує, де можливо, браузер (http://www.jibbering.com/faq / faq_notes / not_browser_detect.html). Потім можна протестувати в кількох агентів користувачів і допоміжних технологіях, перевіряючи, що сайт є більш прийнятною, взаємодіючим, і зрозумілим, яка б комбінація опублікованого CSS, JavaScript, і модулів не була активована, або деактивовано.

Найбільш поширеною проблемою є, ймовірно, настирливий JavaScript, як у випадку анкерів і кнопок, які знаходяться в розмітці сторінки без сценарію, але залежать від JavaScript, щоб реально щось зробити. Але існують більш тонкі проблеми, які виникають з занадто тісною связіJavaScript з іншими шарами в технологічному стеку. Наприклад, JavaScript може застосувати CSS display: none; щоб приховати контент, але що станеться, коли CSSіздателя непридатний?

Іншим прикладом є елементи управління мультимедіа, власний інтерфейс користувача модуля (плагіну) деактивується, а підключається модуль замість цього управляється віджетами HTML зі сценаріями. Коли контент модуля додається тільки через JavaScript після виявлення модуля на основі JavaScript, то все відмінно. Але іноді контент модуля включається в стан сторінки до сценарію. У таких випадках варто перевірити не тільки, що було повернення в початковий стан на випадок, якщо підключається модуль обробки недоступний, але також, що власний інтерфейс користувача модуля не відключений, якщо JavaScript недоступний. Якщо відсутній перше, то користувачі взагалі не побачать резервного контенту; якщо відсутній друге, то користувачі побачать підключається модуль, але не зможуть ним управляти.

Тестування користувачів

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

Набір тестувальників

Тестувальників можна знайти таким же чином, як ви шукайте зазвичай кандидатів для тестування юзабіліті (наприклад, за допомогою оголошень і рекрутингових агентств). Місцеві організації інвалідів могли б запропонувати відповідні форуми для набору підходящих кандидатів. Тестування є реальною роботою і повинно в ідеалі компенсуватися відповідним чином. Ставка в 70 USD за годину тестування є загальноприйнятою для тестування користувачів. Не кажучи вже про те, що ви можете знайти людей, які будуть тестувати менші проекти безкоштовно. Можна знайти людей з фізичними вадами серед друзів, родичів, і колег. Крім того, існують онлайнові дискусійні групи спеціально присвячені питанням доступності програмного забезпечення, такі як:

  • WebAIM Accessibility Discussion List. (Http://www.Webaim.org/discussion/)

  • Web Accessibility Initative Interest Group Mailing List (http://www.w3.org/WAI/IG/Overview.html): форум для обговорення питань, пов'язаних з доступністю Web.

  • British Computer Association of the Blind mailing list (http://www.bcab.org.uk/mailing-list.html): для обговорення Інформаційних технологій комунікації (ICT) для людей з вадами зору.

  • Magnifiers Yahoo! Group. (Http://tech.groups.yahoo.com/group/magnifiers/)

  • jfw@freelists.org (http://www.freelists.org/archives/jfw/): Список поштової розсилки для користувачів зчитувача екрану JAWS.

  • GW-Info (http://www.gwmicro.com/Support/Email_Lists/): Список поштової розсилки для користувачів зчитувача екрану GW Micro Window-Eyes.

  • Dolphin software users Yahoo! Group. (Http://tech.groups.yahoo.com/group/dolphinusers/)

  • Список поштової розсилки користувачів NVDA. (Http://www.freelists.org/list/nvda)

  • Список поштової розсилки користувачів Thunder. (Http://www.freelists.org/list/thunder)

  • discuss@macvisionaries.com (http://macvisionaries.com/mailman/listinfo/discuss_macvisionaries.com): Список поштової розсилки про використання OS X сліпими.

  • macvoiceover@freelists.org (http://www.freelists.org/list/macvoiceover): Користувачі Apple VoiceOver.

  • Blinux-список (https: / / www.redhat.com / mailman / listinfo / blinux-list): Список розсилки про використання Linux людьми з вадами зору.

  • Користувачі GNOME Orca. (Http://mail.gnome.org/mailman/listinfo/orca-list)

  • Ai Squared Forums (http://www.aisquared.com/forums/index.php): Включає користувачів популярної екранної лупи ZoomText.

  • Deaf-Macs Yahoo! Group (http://tech.groups.yahoo.com/group/Deaf-Macs/): Для глухих, плохослишащіх, і Usher або сліпоглухих користувачів Mac.

  • deaf-uk-technology Yahoo! Group (http://groups.yahoo.com/group/deaf-uk-technology/): Обговорення пов'язаних з глухотою технологій.

Такі групи зазвичай вітають питання від розробників Web про доступність їх сайтів або визначених методів.