Перейти к содержимому
Pandus

WCAG 1.3.1 Информация и взаимосвязи

Обновлено 14 октября 2026 г. · 4 мин чтения

Уровень
A · WCAG 2.0
EN 301 549
9.1.3.1
Официальный текст
Understanding 1.3.1 Info and Relationships (W3C, на английском)

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

Что требует критерий

Информация, структура и взаимосвязи, переданные оформлением, должны быть программно определяемыми или доступными в виде текста. В HTML это означает:

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

Типичные ошибки в интернет-магазине

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

Как проверить

Автоматически: наша проверка находит многие структурные ошибки: списки и списки определений с неправильными дочерними элементами, ячейки данных без заголовков, жирные абзацы вместо заголовков, поддельные подписи таблиц, роли ARIA без обязательных родительских или дочерних ролей и aria-hidden на body (правила список, элемент списка, ячейка с заголовком, абзац как заголовок и связанные). Она не видит, что что-то лишь выглядит как заголовок или группа, поэтому чистый результат сканирования ещё не доказательство.

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

Как исправить

  • Используйте настоящие элементы заголовков в теме и редакторе; соблюдайте логичный порядок (один h1, затем разделы h2).
  • Стройте таблицы характеристик с помощью table, th и caption.
  • Дайте каждому полю видимый label; группируйте наборы радиокнопок и флажков через fieldset и legend.
  • Пишите «обязательное» в тексте подписи или добавьте aria-required и объясните, что означает звёздочка.
  • Предпочитайте встроенные элементы HTML ролям ARIA.

Связанные критерии

Частые вопросы

Требует ли WCAG 1.3.1 правильного порядка заголовков?

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

Как проверить WCAG 1.3.1?

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

Достаточно ли текста-подсказки (placeholder) вместо подписи поля?

Это ненадёжная подпись: она исчезает, когда пользователь начинает вводить текст, и озвучивается не всегда. Используйте видимый элемент label, связанный с полем в коде; критерий 3.3.2 «Подписи или инструкции» тоже требует видимых подписей.

Являются ли нарушением таблицы для вёрстки?

Использовать таблицы для вёрстки не рекомендуется, но само по себе это не нарушение, если в них нет ячеек-заголовков, подписей (caption) или summary. А вот таблицам с данными нужны настоящие ячейки-заголовки.