Html5 семантика: как сделать разметку понятной браузеру, поиску и скринридерам

Q: Можно ли использовать несколько header и footer на странице?

Да. header и footer могут быть у страницы и у отдельных article/section, если это отражает структуру контента.

Q: Сколько nav допустимо и нужно ли всем задавать aria-label?

nav можно использовать несколько раз. Если навигаций больше одной, добавьте aria-label или aria-labelledby, чтобы скринридер различал их.

Q: Нужен ли h1 в каждом article внутри ленты?

Обычно нет: у страницы должен быть главный h1, а элементы списка получают заголовки уровней ниже (часто h2/h3) в зависимости от вложенности.

Чтобы HTML5-разметка была понятной браузеру, поиску и скринридерам, используйте семантические теги по назначению, стройте корректную иерархию заголовков, ограничьте количество landmark-областей, не дублируйте роли ARIA там, где хватает нативной семантики, и проверяйте результат автоматическими и ручными тестами доступности перед релизом.

Краткая сводка по семантике HTML5

Сначала задайте каркас страницы: header/nav/main/footer, а затем наполняйте его контентными блоками.
article - самостоятельная единица контента; section - логическая часть, обычно со своим заголовком.
Заголовки h1-h6 должны отражать структуру документа, а не визуальный размер.
ARIA добавляйте только там, где нативной семантики нет или она сломана кастомным UI.
Для медиа: осмысленный alt, подписи через figure/figcaption, адаптивность через picture.
Проверяйте: валидность DOM, дерево доступности (Accessibility Tree), навигацию клавиатурой и автоматические аудиты.

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

HTML5 семантические теги формируют "каркас смысла": браузер строит дерево документа, скринридер - дерево доступности, а поисковые системы - более предсказуемое понимание блоков и их приоритетов. Практически это снижает риск неправильной навигации, "прыжков" фокуса и ошибочной интерпретации контента.

Кому подходит: продуктовым и контентным сайтам, SPA/SSR, дизайн-системам, где важны доступность и устойчивость к изменениям верстки. Семантическая верстка HTML5 особенно полезна при масштабировании проекта и перед внедрением компонентов.

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

<!-- Антипаттерн: "всё div", смысл теряется -->
<div class="header">...</div>
<div class="nav">...</div>
<div class="content">...</div>

<!-- Лучше: нативные landmarks -->
<header>...</header>
<nav aria-label="Основная навигация">...</nav>
<main>...</main>

Правило на запоминание: "тег выбираю по смыслу, класс - по стилю".

Базовые семантические элементы: header, nav, main, aside, footer - когда и как

Для внедрения семантики обычно нужны: доступ к шаблонам/компонентам, понимание структуры страниц, базовая проверка в DevTools и право запускать аудит доступности. Если вы планируете оптимизация HTML5 семантики для SEO, согласуйте изменения с теми, кто отвечает за контент и шаблоны, чтобы не сломать заголовки и хлебные крошки.

Как применять landmarks без конфликтов

<header> - вводная часть страницы или раздела (может повторяться внутри article/section).
<nav> - блок навигационных ссылок. Если навигаций несколько, задавайте aria-label.
<main> - уникальная основная область страницы. На странице должен быть один main.
<aside> - второстепенный контент (сайдбар, "похожие", рекламный блок), логически отделимый от основного.
<footer> - подвал страницы или раздела (контакты, доп. ссылки, копирайт).

<body>
  <header>...</header>

  <nav aria-label="Основная навигация">
    <ul>...</ul>
  </nav>

  <main id="content">
    ...
  </main>

  <footer>...</footer>
</body>

Правило на запоминание: "один main на страницу; nav только там, где действительно навигация".

Структурирование контента: article, section и заголовки h1-h6 без ошибок

Разметьте "единицы контента" через article. Если блок можно читать/шарить отдельно (пост, новость, карточка статьи), используйте article. Это повышает предсказуемость структуры для ассистивных технологий.
- Антипаттерн: "лента" из div без заголовков, где каждую карточку невозможно быстро пропустить.
Используйте section для смысловых разделов с заголовком. section оправдан, когда у части страницы есть собственная тема и заголовок (видимый или доступный).
- Антипаттерн: оборачивать каждый визуальный отступ в section без заголовка.
Постройте иерархию h1-h6 по документу, а не по стилю. h1 - заголовок страницы/материала; дальше - вложенные уровни без "скачков" логики.
- Допустимо: пропуск уровня ради дизайна лучше решать CSS-классами, а не перескоком на h4.
Согласуйте повторяющиеся элементы в шаблонах. В карточках списка используйте заголовки разумного уровня (часто h2/h3), не создавая множество h1 в ленте.
Проверьте читаемость структуры без CSS. Временно отключите стили и убедитесь, что порядок чтения, заголовки и смысл блоков не "рассыпаются".

<main>
  <article>
    <header>
      <h1>Заголовок материала</h1>
    </header>

    <section>
      <h2>Раздел 1</h2>
      <p>...</p>
    </section>

    <section>
      <h2>Раздел 2</h2>
      <h3>Подраздел</h3>
      <p>...</p>
    </section>
  </article>
</main>

Быстрый режим

HTML5 семантика: как сделать разметку понятной браузеру, поиску и скринридерам - иллюстрация

Замените "шапку/меню/контент/подвал" на header/nav/main/footer.
Каждую самостоятельную публикацию оберните в article и дайте ей заголовок.
Крупные смысловые блоки оформите section с h2, подпункты - h3.
Проверьте навигацию клавиатурой и дерево доступности в DevTools.

Правило на запоминание: "нет заголовка - обычно нет и section".

ARIA и роли: когда хватает встроенной семантики, а когда нужны атрибуты

Не добавляйте role, если элемент уже семантический (например, nav не нуждается в role="navigation").
Добавляйте aria-label/aria-labelledby, когда на странице несколько одинаковых landmarks (например, два nav).
Для интерактивных кастом-компонентов (табы, модалки, раскрывашки) обеспечьте роли, состояния и управление с клавиатуры.
Следите за уникальностью id, используемых в aria-labelledby и aria-describedby.
Не скрывайте доступное имя: иконка-кнопка должна иметь текст через aria-label или видимый текст.
Проверьте, что фокус не уходит в "невидимые" области, а порядок таба логичен.
Если используете aria-hidden="true", убедитесь, что там нет фокусируемых элементов.
Не подменяйте заголовки ARIA-атрибутами: сначала семантика, потом ARIA.

<!-- Хорошо: несколько nav, но с понятными метками -->
<nav aria-label="Основная навигация">...</nav>
<nav aria-label="Навигация по разделу">...</nav>

<!-- Антипаттерн: дублирование роли -->
<nav role="navigation">...</nav>

Медиа и подписи: figure, figcaption, img@alt, picture и оптимизация загрузки

Пустой или шаблонный alt у информативных изображений (антипаттерн: alt="image").
Слишком "SEO-шный" alt, который не описывает изображение по делу (доступность важнее, чем набор ключей).
Отсутствие width/height у img, из-за чего скачет layout (лучше задавать размеры и управлять через CSS).
figure используется ради обводки, а не ради связи "медиа + подпись".
figcaption дублирует alt слово в слово: alt описывает изображение, подпись добавляет контекст.
Неправильное применение loading="lazy" для изображений в первом экране (может ухудшить ощущение скорости).
picture без реальной причины или без fallback img.

<figure>
  <img src="/img/team.jpg" width="1200" height="800" alt="Команда проекта за рабочим столом">
  <figcaption>Фото: стендап перед релизом</figcaption>
</figure>

<picture>
  <source type="image/avif" srcset="/img/hero.avif">
  <source type="image/webp" srcset="/img/hero.webp">
  <img src="/img/hero.jpg" width="1600" height="900" alt="Главный экран продукта">
</picture>

Правило на запоминание: "alt - что на картинке; figcaption - зачем это читателю".

Автоматическая проверка и тестирование доступности: инструменты и чек-лист

Альтернативы по глубине проверки (выбирайте под задачу и этап):

Браузерные DevTools - быстро посмотреть landmarks, имя/роль/состояние, порядок фокуса. Уместно на каждом PR.
Lighthouse (Accessibility/SEO) - быстрый автоскоринг и список типовых проблем. Уместно перед релизом и в CI как "сигнал", а не как единственный критерий.
axe DevTools / axe-core - более предметные правила и удобные отчеты. Уместно для регулярной проверки компонентной библиотеки.
Ручное тестирование скринридером (NVDA/VoiceOver) - проверка реального UX навигации. Уместно для ключевых сценариев (авторизация, корзина, формы).

Мини-чек-лист перед сдачей

На странице один main, навигации размечены nav и при необходимости различаются aria-label.
Заголовки идут логично, без "прыжков по смыслу"; визуальные размеры решены CSS.
Кликабельные элементы - это button/a, а не div с обработчиком.
Все изображения с осмысленным alt или с пустым alt="", если они декоративные.
Фокус видим, навигация с клавиатуры проходит все интерактивные элементы в правильном порядке.
ARIA не дублирует нативную семантику и не ломает доступные имена.

Если вы делаете внедрение "под ключ", то запросы вроде услуги по аудиту семантики HTML5 или заказать семантическую верстку сайта обычно означают, что нужно не только поправить теги, но и зафиксировать требования в компонентной библиотеке и чек-листах для команды.

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

Можно ли использовать несколько header и footer на странице?

Да. header и footer могут быть у страницы и у отдельных article/section, если это отражает структуру контента.

Сколько nav допустимо и нужно ли всем задавать aria-label?

nav можно использовать несколько раз. Если навигаций больше одной, добавьте aria-label или aria-labelledby, чтобы скринридер различал их.

Нужен ли h1 в каждом article внутри ленты?

Обычно нет: у страницы должен быть главный h1, а элементы списка получают заголовки уровней ниже (часто h2/h3) в зависимости от вложенности.

Когда section - ошибка?

Когда это просто контейнер для сетки/отступов и у блока нет собственного заголовка или темы. В таких местах чаще достаточно div.

Правда ли, что оптимизация HTML5 семантики для SEO - это только замена div на теги?

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

Нужно ли добавлять role к семантическим элементам?

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

Как понять, что пора привлекать услуги по аудиту семантики HTML5?

Когда на проекте много шаблонов/компонентов, регулярно возникают проблемы с фокусом и скринридерами, или вы не уверены в корректности landmarks и ARIA в критичных сценариях.