Доступный Интерфейс Frontend-разработка и доступность

Как правильно использовать семантические теги HTML

Как правильно использовать семантические теги HTML

Семантическая разметка описывает назначение содержимого, поэтому вместо набора безликих div нужно выбирать теги по роли блока: main, article, nav и другие. Главный критерий прост: название элемента должно отвечать на вопрос, что находится внутри, а не как этот фрагмент выглядит.

Зачем странице семантическая структура?

Осмысленные теги помогают браузерам, поисковым системам и вспомогательным технологиям распознавать части документа. Они не заменяют качественный контент и корректную иерархию, но делают исходный код понятнее для машин и разработчиков.

Например, программа экранного доступа может использовать ориентиры nav и main для быстрого перехода к меню или основному содержимому. Разработчику такая структура тоже удобна: при чтении кода сразу видно, где статья, боковой материал и подвал.

Семантика не задаёт внешний вид. Тег article сам по себе не создаёт карточку с рамкой, а header не обязан находиться только наверху сайта. Оформлением управляет CSS, тогда как HTML передаёт смысл и порядок элементов.

Какие теги образуют каркас страницы?

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

Тег Когда использовать Типичный пример
header Для вводной части страницы или раздела Логотип, заголовок, краткое описание
nav Для основного блока навигационных ссылок Меню сайта, оглавление статьи
main Для главного уникального содержимого документа Каталог, статья, страница услуги
article Для самостоятельного материала Публикация, новость, отзыв пользователя
section Для тематического раздела, обычно с заголовком Описание функции, глава руководства
aside Для связанного, но второстепенного содержимого Справка, блок похожих материалов
footer Для завершающей информации страницы или раздела Автор, контакты, служебные ссылки

В документе обычно размещают один видимый main. Элементы header и footer, напротив, могут повторяться внутри отдельных публикаций или секций. Получается не жёсткий шаблон, а карта содержания с различимыми областями.

Как отличить article, section и div?

article подходит самостоятельному материалу, section — тематической части документа, а div остаётся нейтральным контейнером. Выбор зависит не от размера блока и не от его положения на экране, а от функции содержимого.

Новостная карточка, которую можно отдельно показать в ленте, часто оформляется как article. Раздел этой новости с заголовком «Причины изменений» логично поместить в section. Обёртка, нужная только для сетки или фоновой заливки, не получает нового смысла — здесь уместен div.

Не каждый фрагмент текста требует секции. Если внутри нет самостоятельной темы и подходящего заголовка, section часто оказывается лишним. Код от этого не становится семантичнее: множество тегов создаёт лишь плотную сетку, за которой труднее увидеть реальную структуру.

Как проверить разметку перед публикацией?

Проверку лучше начинать не со стилей, а с чтения структуры документа. Даже при отключённом CSS заголовки, ссылки, кнопки и смысловые области должны идти в понятном порядке и сохранять своё назначение.

  • Убедитесь, что на странице есть один основной заголовок h1, а уровни h2 и h3 отражают вложенность тем.
  • Используйте a для перехода по адресу, а button — для действия: открытия окна, отправки формы или переключения состояния.
  • Не помещайте всё меню в nav, если это случайная группа ссылок, а не навигационный блок.
  • Проверьте, можно ли понять роль контейнера без названий CSS-классов вроде blue-box или left-column.
  • Откройте инструменты разработчика и просмотрите дерево доступности: у ключевых областей должны быть распознаваемые роли и названия.

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

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