Як провести аудит навчального курсу за стандартами доступності WCAG

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

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

Відправною точкою можуть бути WCAG 2.2 та методика WCAG-EM 2.0. Це різні документи: критерії описують вимоги, а методика допомагає організувати оцінювання. Наведений нижче порядок є практичною адаптацією для навчального продукту; він не замінює професійної перевірки всіх застосовних вимог, коли потрібна формальна заява про відповідність.

Визначте об'єкт перевірки

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

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

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

Погодьте ціль і критерії

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

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

Погодьте формат звіту до початку. Для практичного виправлення потрібні місце, роль, кроки відтворення, фактичний результат, відповідний критерій і рекомендація. Якщо замовник очікує також заяву про відповідність, окремо узгодьте потрібну доказову основу й межі. Не обіцяйте формальний результат, який не підтримує обраний обсяг перевірки.

Побудуйте карту навчальних процесів

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

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

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

Сформуйте обґрунтовану вибірку

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

Збережіть пояснення відбору. Чому обрано саме ці уроки? Які шаблони повторюються? Які елементи унікальні? Якщо знайдено системну помилку, перевірте інші місця використання відповідного компонента. Одна недоступна кнопка в спільному шаблоні може впливати на десятки сторінок, тоді як проблема в окремому зображенні потребує локальної редактури.

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

Поєднайте автоматичні й ручні перевірки

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

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

Залучення людей із різними потребами дає цінну інформацію про реальний досвід. Проте невелике користувацьке тестування саме по собі не підтверджує всі критерії WCAG. Розділіть спостереження про зручність, знайдені бар'єри й формальний висновок. Це дозволить чесно використати кожен метод відповідно до того, що він справді показує.

Пройдіть курс клавіатурою

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

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

Знайдену проблему опишіть як конкретний збій сценарію. Наприклад, після відкриття вікна з умовою фокус лишається позаду й студент не знаходить кнопку закриття. Такий запис допомагає розробнику відтворити ситуацію. Загальна примітка покращити доступність інтерфейсу не дає ні критерію виконання, ні способу перевірити виправлення.

Перевірте структуру тексту й зображення

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

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

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

Форми перевіряйте разом із помилками

У кожного поля має бути зрозуміле призначення, а потрібні інструкції — доступні до введення. Перевірте обов'язковість, формат відповіді та повідомлення після невдалої спроби. Якщо помилку позначено лише кольором, частина студентів може не зрозуміти, що сталося. Пояснення має допомагати виправити дію, а не тільки повідомляти, що вона неправильна.

Для завантаження роботи перевірте допустимі формати, підтвердження надсилання й можливість знайти повернутий коментар. Якщо студент не впевнений, чи файл прийнято, він може повторювати дію або звертатися до підтримки. Тут доступність перетинається зі зрозумілістю процесу, але кожну знайдену проблему все одно варто пов'язати з конкретним спостереженням і відповідним критерієм оцінювання.

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

Медіа й документи включіть до переліку активів

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

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

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

Перетворіть знахідки на керовані задачі

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

Розділіть системні й локальні причини. Виправлення шаблону кнопки може допомогти багатьом урокам, але кожен значущий графік усе одно потребує змістового опису. Призначте відповідального й спосіб перевірки. Якщо проблема лежить у сторонньому сервісі, створіть маршрут звернення та перевірте доступну альтернативу для поточного студента.

Коли навчання організовано через LMS платформа WeStudy, оцінюйте реальний курс і підтверджені можливості його конфігурації. Не робіть висновок про відповідність усієї платформи на підставі перевірки одного авторського модуля. Так само не приписуйте постачальнику автоматичне усунення помилок, які виникли в завантаженій презентації або створеній школою інструкції.

Повторіть перевірку після виправлення

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

Збережіть історію результатів: що було знайдено, як змінено й коли перевірено. Це допоможе під час наступного оновлення, коли автор випадково поверне старий шаблон. Для повторюваних технічних перевірок корисні узгоджені процедури; W3C ACT є окремим орієнтиром для опису відтворюваних тестів, а не заміною всього аудиту.

Додайте доступність до звичайного приймання нових матеріалів. Редактор перевіряє структуру, автор — змістові альтернативи, технічна команда — компоненти й сценарії. Періодичний аудит тоді знаходить зміни й пропуски, а не щоразу починає відновлення базового порядку. Це зменшує обсяг дорогих переробок після запуску й дає учасникам стабільніший досвід.

Приклад однієї картки проблеми

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

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

Як планувати виправлення перед найближчим запуском

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

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

Розмова зі стороннім постачальником

Надсилайте постачальнику конкретний відтворюваний випадок, а не загальне питання, чи доступний його продукт. Укажіть компонент, роль, стан, середовище та вплив на дію. Попросіть пояснити, чи відома проблема, яке виправлення можливе й коли його можна повторно перевірити. Збережіть відповідь разом із карткою, щоб інша людина могла продовжити роботу без відновлення всього листування з початку.

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

Що підготувати для користувацької сесії

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

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

Підтримуйте доступність після редактури

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

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

Сформулюйте чесний висновок

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

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

Перед передаванням звіту перевірте доступність самого документа: послідовність заголовків, зрозумілі назви посилань і текстові пояснення до скриншотів. Команда має вміти користуватися результатами аудиту тими самими засобами, які вона підтримує для студентів. Доступний звіт також полегшує подальший пошук задач та незалежну перевірку висновків.

Джерела

1. W3C — WCAG 2.2.

2. W3C — WCAG Evaluation Methodology 2.0.

3. W3C WAI — Evaluating Web Accessibility.

4. W3C — Accessibility Conformance Testing.

5. W3C WAI — Easy Checks.