3.7: Шаблон перевірки веб-аудиту WCAG

Last updated
Save as PDF

Page ID: 103770

\( \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}}\)

Тепер, коли ви розумієте WCAG, ми познайомимо вас із шаблоном аудиту доступності. Ви можете використовувати шаблон для запису проблем під час проведення аудиту, але він також діє як контрольний список, який допомагає закріпити вказівки до пам'яті. Наразі перегляньте макет та елементи шаблону перегляду веб-аудиту та додайте його до інструментарію аудиту доступності Інтернету.

Інструментарій: Завантажте шаблон огляду WCAG 2.1 [doc] і додайте його до свого інструментарію. Створіть папку з файлами «webaudits» на жорсткому диску та збережіть її там. Після завершення аудиту збережіть їх у вкладених теках, які ви створюєте тут, щоб упорядкувати звіти про аудит, які ви створюєте.

Елементи шаблону огляду

Назва: У цьому полі слід вказати тип рецензування, загальний, шаблонний або детальний (докладніше буде розглянуто у розділі Звітність про аудит доступності веб-сторінок) та рекомендації, на яких він базується.

Місцезнаходження: URL-адреса домашньої сторінки сайту, що розглядається.

Дата: дата завершення рецензування.

Рецензент: Ім'я особи, яка завершила рецензування.

Посилання на керівні принципи: Посилання на керівні принципи, на яких ґрунтується огляд.

Інструменти, що використовуються під час цього огляду: список інструментів, що використовуються в огляді, включаючи автоматичні шашки, браузери, плагіни браузера, інструмент перевірки читабельності, інструмент тестування кольорового контрасту, засоби читання екрана та будь-які інші використовувані інструменти. Обов'язково вкажіть номери версій, якщо це можливо.

Загальні коментарі: Огляд результатів WCAG 2.1 Review (нижче) з окресленням ключових питань, чому вони є проблемами, з короткою згадкою про потенційні рішення. Цей розділ написаний для широкої аудиторії, мінімізуючи використання технічної мови.

Огляд WCAG 2.1: Основний зміст огляду. Це список критеріїв успіху WCAG 2.1, рівень відповідності кожного з них (A, AA, AAA), отримана оцінка (Pass, Fail, Pass? , Провал? N/A), і коментарі, пов'язані з оцінками. Ці коментарі повинні визначити проблеми доступності, що стосуються керівних принципів, пояснити, чому проблема є бар'єром, і запропонувати потенційні рішення для вирішення проблем. Огляд повинен бути спрямований на веб-розробників, які вирішуватимуть виявлені проблеми та можуть містити технічну мову та зразок коду, який можна повторити. Скріншоти та іншу графіку можна використовувати для покращення пояснень, наведених у тексті коментарів.

Ймовірно, будуть випадки, коли будуть виявлені прикордонні проблеми, де можна стверджувати, що якийсь елемент може пройти або не відповідати відповідним критеріям успіху. У таких випадках «Пройти?» (зі знаком питання) використовується там, де аудитор схиляється до пропуску, але інші можуть стверджувати, що це не вдається. І, використовувати «Fail?» де аудитор схиляється до невдачі, хоча інші можуть стверджувати, що це проходить. Одним із прикладів може бути опис зображення, наданого в атрибуті alt, який не повністю описує значущу інформацію на зображенні. У таких випадках це часто суб'єктивне рішення аудитора, коментуючи автору альтернативного тексту переглянути текст, щоб визначити, чи «адекватно» він описує сенс, який слід відняти від зображення, якщо воно розглядалося. Сумнівний прохід або невдача більш детально описано в прикладі, пов'язаному в полі Toolkit нижче.

Зверніть увагу, що елементи AAA виділені сірим кольором, а також два критерії успіху AA (1.2.4, 1.2.5), які не потрібні AODA (це стосується учасників на базі Онтаріо). Якщо ви проводите аудит в юрисдикції, яка вимагає цих вказівок, ви можете змінити шаблон, вилучивши сірий колір для цих двох вказівок. В іншому випадку сірі елементи є необов'язковими, хоча при розгляді проблем із вмістом, пов'язаних із цими рекомендаціями, все одно можна зробити рекомендації щодо впровадження методів, пов'язаних із цими рекомендаціями, щоб покращити загальну зручність використання.

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

Додаток: Хоча не включені в шаблон, Додаток повинен містити список сторінок, відібраних з сайту, який був розглянутий.

Приклад завершеного рецензування

У 2012 загальний огляд Canvas був розміщений OCAD University в Торонто, який знаходився в процесі вибору нового LMS для університету. Огляд був опублікований публічно, тому він добре працює як приклад того, як може виглядати завершений огляд.

У цьому огляді розглядалася низка завдань, таких як читання поста на форумах і розміщення відповіді, перегляд результатів тестів і перевірок в заліковій книжці і так далі (ці сценарії були описані в додатках, відсутні в публічно розміщеному огляді). Результати цих сценаріїв були об'єднані в загальний огляд (див. розділ Web Accessibility Audit Reporting для опису різних типів рецензій). Прочитайте частини огляду, щоб отримати уявлення про типи інформації, яку він містить.

Інструментарій: Вивчіть Canvas Accessibility Review 2012 [doc] для прикладів типів інформації, які можна знайти в огляді веб-доступності. Додайте його до свого інструментарію як посилання.

Ви можете запитати, якщо є так багато проблем, чому ми використовували Canvas для доставки онлайн-версії вмісту тут? Після публікації огляду Canvas звернув увагу і доклав значних зусиль для покращення доступності своєї системи. У 2014 році доступність Canvas була значно покращена, хоча ще кілька областей, де можна було б вдосконалити. Порівняно з іншими системами управління навчанням, поточна версія Canvas добре тарифікується з точки зору доступності.