WCAG 1.3.1 Інформація та взаємозв'язки

Критерій успіху 1.3.1 потрібен для того, щоб структура, яку бачать люди, — заголовки, списки, таблиці, мітки полів форми, групи варіантів — була й у коді. Програми зчитування з екрана, голосове керування та режими читання використовують цю структуру, щоб озвучувати сторінку й переміщатися нею. Це рівень A, і він входить до EN 301 549 (пункт 9.1.3.1; в Україні — ДСТУ EN 301 549:2022).

Що вимагає критерій

Інформація, структура та взаємозв'язки, передані оформленням, мають бути програмно визначуваними або доступними в тексті. У HTML це означає:

• заголовки використовують h1–h6, а не просто великий жирний текст;
• списки використовують ul, ol або dl, і пункти списку стоять безпосередньо всередині;
• таблиці з даними використовують th для заголовків (і scope чи headers для складних таблиць), а також підпис, якщо в таблиці є назва;
• поля форми мають мітки, пов'язані з ними в коді (label for), а пов'язані поля, як-от перемикачі, згруповані (fieldset і legend);
• інформація, передана форматуванням, — обов'язкове поле з червоною зірочкою, виділений поточний крок — доступна також у тексті чи коді.

Типові помилки в інтернет-магазині

• назви розділів на кшталт «Хіти продажу» чи «Опис» оформлені як заголовки, але в коді це div або жирний p;
• таблиці розмірів і характеристик зібрані з div або не мають комірок-заголовків;
• поля оформлення замовлення, видима мітка яких не пов'язана з полем у коді;
• варіанти оплати й доставки як перемикачі без мітки групи;
• обов'язковість поля показана лише червоною зірочкою, якої немає в мітці;
• ролі ARIA, як-от list чи menu, використані без обов'язкових дочірніх ролей.

Як перевірити

Автоматично: наш сканер знаходить багато структурних помилок: списки та списки визначень із неправильними дочірніми елементами, комірки даних без заголовків, жирні абзаци замість заголовків, фальшиві підписи таблиць, ролі ARIA без обов'язкових батьківських чи дочірніх ролей і aria-hidden на body (правила list, listitem, td has header, p as heading та пов'язані). Він не бачить, що щось лише виглядає як заголовок чи група, тож чисте сканування — не доказ.

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

Як виправити

• Використовуйте справжні елементи заголовків у темі й редакторі; дотримуйтеся логічного порядку (один h1, далі розділи h2).
• Будуйте таблиці характеристик із table, th і caption.
• Дайте кожному полю видимий label; групуйте набори перемикачів і прапорців за допомогою fieldset і legend.
• Вкажіть «обов'язкове» в тексті мітки або додайте aria-required і поясніть зірочку.
• Надавайте перевагу нативним елементам HTML перед ролями ARIA.

Пов'язані критерії

• 1.3.2 Значуща послідовність — порядок читання в коді.
• 1.3.5 Призначення полів уведення — автозаповнення для полів з особистими даними.
• Правила, які перевіряє наш сканер — усі автоматичні правила та їхні критерії.

Часті запитання

Чи вимагає WCAG 1.3.1 правильного порядку заголовків?

1.3.1 вимагає, щоб текст, який виглядає як заголовок, був розмічений як заголовок. Пропуск рівнів (з h2 одразу на h4) сам по собі не порушує 1.3.1, але логічний порядок значно полегшує навігацію сторінкою і є доброю практикою.

Як перевірити WCAG 1.3.1?

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

Чи достатньо тексту-заповнювача (placeholder) як мітки поля?

Це ненадійна мітка: вона зникає, коли користувач починає вводити, і її не завжди зачитують. Використовуйте видимий елемент label, пов'язаний із полем у коді; 3.3.2 «Маркування або інструкції» теж вимагає видимих міток.

Чи є таблиці для верстки порушенням?

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