Accessibility Vocabulary for Developers: WCAG, ARIA, and Inclusive Design Terms Explained (англійською)

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

Основні принципи

Кожна вимога доступності в Web Content Accessibility Guidelines (WCAG) відстежується до чотирьох основних принципів, відомих спільно як POUR: Сприйнятливість, Діяльність, Зрозумілість, і Надійність.

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

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

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

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

Як вони з’ являються в реальних розмовах про перегляд коду?

Це неможливо відчути — зображення не має атрибуту alt “Клавіатура в цьому модальному режимі не працює. Ви можете ввести табуляцію, але не можете вивести її» Повідомлення про помилку просто каже «Неправильний вхід» — це проблема для Understandable

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

Рівень відповідності WCAG

WCAG організовує свої критерії успіху в три рівні відповідності: A, AA і AAA.

** Рівень A ** представляє мінімум. Це критерії успіху, без яких сторінка буде практично неможливою для використання деякими користувачами. Недолік на рівні A є жорстким бар’ єром: вміст не може бути доступним взагалі.

** Рівень AA ** є стандартним призначенням для більшості комерційних продуктів і вимагає закону в багатьох юрисдикціях, включаючи ЄС за EN 301 549, і Сполучені Штати за розділом 508. Коли контракт або резюме посилається на «сумісність з WCAG 2.1», це майже завжди означає відповідність AA.

Уровень ААА - це прагнення. Деякі критерії AAA непрактичні для всього вмісту - вони зазвичай спрямовані на певні контексти, такі як програми для користувачів з когнітивними вадами.

У професійних коментарях щодо написання і звантаження запитів ви можете вказувати на певні ** критерії успіху (SC) **:

«SC 1.4.3 Контрастність (мінімум) вимагає співвідношення 4.5:1 для тексту на AA. Наш первинний текст на цьому фоні є 3.2:1.” «Цей компонент не відповідає SC 2.1.1 — всі функції повинні бути керовані через клавіатуру»

Формат SC [number] [Name] є стандартним шаблоном посилання. Навчися ним користуватися.

Ролі та атрибути ARIA

** ARIA ** (Accessible Rich Internet Applications) — це набір атрибутів HTML, які змінюють спосіб інтерпретації DOM допоміжними технологіями. Він існує для заповнення прогалин, де семантики HTML недостатньо — особливо для нетипових інтерактивних компонентів.

Відмінності ключових атрибутів:

• ** aria-label ** надає пряму мітку рядка для елемента. Використовувати, якщо не видно тексту мітки.
• ** aria-labelledby ** вказує на інший елемент за ідентифікатором, текстовий вміст якого слугує мітки. Перевагу над aria-label, коли видимий текст вже існує.
• ** aria-describedby ** містить довший опис, який доповнює мітку. Поширене у введенні даних у формах з текстом підказки.
• ** aria-live ** наказує програмам для читання з екрану оголошення змін динамічного вмісту. aria-live="polite" очікує, поки користувач не займе вільний час; aria-live="assertive" негайно перериває роботу.
• ** aria-expanded ** повідомляє про відкритий/ закритий стан згортання компонента.
• ** aria-hidden="true" ** повністю вилучає елемент з дерева доступності — корисно для декоративних піктограм.

Як обговорювати ці питання у коментарях до публікацій:

«Додати aria-expanded={isOpen} до цієї кнопки, щоб читачі екрану оголосили про зміну стану, коли відкриється спадне меню» «Використовуйте aria-live="polite" для цього повідомлення про стан — це не критично, тому ми не хочемо переривати користувача» «Ця іконка декоративна — додайте aria-hidden="true", щоб її не оголосили надмірно»

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

Система управління контентом

Навігація за допомогою клавіатури повністю залежить від правильного ** керування фокусом ** — керування тим, який елемент отримує фокус клавіатури і коли.

Ключеві терміни:

• ** Кільце фокусу **: видима контура, яка вказує на те, який елемент клавіатури має поточний фокус. Вилучення цього параметра без надання альтернативи є порушенням WCAG.
• ** Фокусна пастка **: шаблон, який зберігає фокус у певному контейнері — необхідний у модальних діалогових вікнах, але це помилка, якщо він з’ являється випадково і заважає користувачеві покинути діалогове вікно.
• ** Посилання на пропуск **: візуально приховано (але доступно за допомогою клавіатури) посилання у верхній частині сторінки, яке переносить вас безпосередньо до головного вмісту, обходячи навігацію.
• ** Порядок фокусування **: послідовність, у якій елементи отримують фокусування після натискання клавіші Tab. Порядок читання має збігатися з візуальним.

Фрази для опису проблем з фокусуванням:

«Порядок вкладок не відповідає візуальному порядку тут — він стрибає з заголовка в нижній колонтитул, пропускаючи головний вміст.» “Після закриття цього модального елемента, фокус повинен повертатися до елемента тригера, який його відкрив. Зараз він опускається до верхньої частини документа.» «Ми потребуємо skip link тут — зрячі користувачі клавіатури повинні переходити через всю навігацію на кожній сторінці.»

Доступність аудиту мови

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

** Автоматизовані інструменти тестування **, на які часто посилаються:

• ** axe ** (розширення переглядача і інтеграція CI): швидкий, низький рівень помилок
• ** Lighthouse ** (вбудований у Chrome DevTools): створює звіт про доступність з оцінками
• ** WAVE ** (додаток переглядача): візуальна анотація проблем на сторінці реальної роботи

Автоматизовані інструменти можуть виявити приблизно 30-40% проблем WCAG. Решта потребують вручну перегляду.

** Екранні зчитувачі **, які ви використовуватимете:

• NVDA (NonVisual Desktop Access) — Windows, безкоштовний
• VoiceOver — macOS і iOS, вбудований
• ** TalkBack ** — Android, вбудований
• ** JAWS ** — Windows, корпоративний рівень

** Записування звітів про вади доступності ** у стандартному форматі:

“Це не відповідає WCAG 2.1 SC 1.4.1 Використання кольору — колір є єдиним відмінним фактором між активним і неактивним станами. Додати іконку або підкреслити.» «Средняя тяжесть: поле формы для адресы электронной почты не имеет связанного <label>. Користувачі зчитувачів екрану не будуть знати, що вводити» «Автоматизований (ось) + ручний (NVDA + Chrome): модальний не захоплює фокус. Клавіша Tab виходить з модульного і пересувається за ним»

У добре написаному звіті про помилку доступності вказується назва WCAG SC, описується помилка простим мовою, вказується її ступінь тяжкості і зазначається, який метод виявив помилку.

---

Практичний словник доступності

Підсилити ці поняття практичними вправами:

• [Вправи з доступності] (/exercises/)
• Розробник комунікаційного фразника

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