Редакция Romanov Lab · Опубликовано
У двух страниц может быть одинаковый скриншот и совершенно разное поведение. На одной «Подробнее» — ссылка, которую можно открыть в новой вкладке; на другой — блок с обработчиком щелчка. На одной заголовки образуют понятное оглавление; на другой их роль выполняют жирные абзацы. Семантическая разметка определяет назначение элементов, а CSS отвечает за внешний вид. Для разработчика это способ сохранить контракт интерфейса при изменении дизайна.
Начните с карты содержания
До написания компонентов перечислите области страницы: общая навигация, основное содержание, дополнительные материалы и подвал. Затем отдельно выпишите действия и переходы. Для перехода по адресу обычно нужна ссылка с href, для действия внутри интерфейса — button. Список однотипных предложений удобно описывать списком, сопоставление характеристик по строкам и столбцам — таблицей. div остаётся нормальным контейнером там, где дополнительного смысла нет.
Руководство W3C по структуре страницы связывает области и логические заголовки с навигацией по содержанию. Практический вывод: выбирать h2 ради размера шрифта нельзя. Уровень следует из вложенности темы; размер задаётся стилем. Несколько областей навигации стоит различать понятными названиями, например «Основная навигация» и «Разделы статьи».
Учебный пример: страница услуги ремонта
Представим вымышленную страницу с описанием услуги, этапами, ценами и вопросами. Её основной заголовок — название услуги. Этапы и цены являются соседними разделами второго уровня. Отдельная операция внутри раздела цен может иметь заголовок третьего уровня. Рекламная карточка в середине текста не получает высокий уровень только потому, что визуально крупнее.
Ссылка «Условия гарантии» ведёт на самостоятельную страницу. Кнопка «Показать расчёт» раскрывает результат на текущей. Если расчёт открывается в модальном окне, одного правильного тега мало: нужен отдельный сценарий фокуса и закрытия. Семантика даёт основу, но не реализует всю логику сложного виджета автоматически.
<main id="content">
<h1>Ремонт оборудования</h1>
<section aria-labelledby="steps-title">
<h2 id="steps-title">Этапы работ</h2>
<ol>
<li>Диагностика</li>
<li>Согласование сметы</li>
</ol>
</section>
<a href="/guarantee/">Условия гарантии</a>
<button type="button">Показать расчёт</button>
</main>Это фрагмент структуры, а не готовый калькулятор. В реальном шаблоне идентификаторы должны оставаться уникальными. Если компонент раздела повторяется, генерация одинакового steps-title свяжет области с неправильным заголовком. Проверку уникальности включают в тест страницы, а не только изолированного компонента.
Не превращайте каждый контейнер в область
section полезен для тематической части документа, article — для относительно самостоятельного материала. Замена всех div на section создаёт шум. Названные области должны помогать найти значимый фрагмент, а не перечислять каждую рамку и отступ. header внутри статьи и общая шапка страницы также имеют разный контекст; механическая замена тегов не гарантирует ожидаемое дерево доступности.
Нативный элемент предпочтительнее имитации: role="button" сообщает роль, но сам по себе не добавляет клавиатурное поведение кнопки. По определению семантики в MDN, смысл элемента не определяется его визуальным оформлением. Поэтому исправление имитации лучше начинать с замены основы, затем проверять CSS и обработчики, а не добавлять всё новые ARIA-атрибуты.
Как провести рефакторинг без неожиданностей
Сначала зафиксируйте действующие сценарии: переходы, отправку форм, аналитику, порядок фокуса. Меняйте один тип компонента за раз. У button внутри формы явно задайте type="button", если он не отправляет данные. После замены проверьте стандартные стили браузера: новый тег может изменить рамку, шрифт или вертикальное выравнивание. У ссылки убедитесь, что обработчик не запрещает обычное открытие в новой вкладке.
Не меняйте логический порядок DOM только ради мобильного макета. Если CSS визуально переставляет карточки, чтение и клавиатурное перемещение могут идти по другому маршруту. На учебной странице этапы должны оставаться в последовательности «диагностика — смета», даже когда сетка перестраивается.
Проверка результата
- Прочитайте страницу без стилей: порядок содержания и списков остаётся понятным.
- Просмотрите заголовки отдельно: они образуют логическую иерархию, а не набор рекламных фраз.
- Проверьте роли и доступные имена в дереве доступности браузера.
- Пройдите действия клавиатурой, включая Enter и пробел там, где это ожидается.
- Проверьте ссылки через контекстное меню и открытие в новой вкладке.
- Прогоните HTML-валидатор и проверьте отсутствие вложенных интерактивных элементов.
Приёмка завершается сравнением поведения до и после изменения. Семантика не обещает прироста поисковых позиций и не заменяет полный аудит доступности. Её самостоятельный результат — понятная структура и предсказуемые базовые элементы, на которых проще строить интерфейс.
Официальные источники
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
