CSS-live.ru

Нужен ли нам новый заголовочный элемент? Мы не знаем

Перевод статьи Do we need a new heading element? We don’t know с сайта jakearchibald.com, опубликовано на css-live.ru с разрешения автора — Джейка Арчибальда.

В спецификацию HTML предлагают добавить новый элемент <h>. Это решает довольно частую задачу. Возьмем такой пример HTML:

<div class="promo">
  <h2>Вы считаете, что «сюжет» в фильмах только отвлекает?</h2>
  <p>Если да, то вам стоит посмотреть «Джона Уика» — наверняка останетесь довольны!</p>
</div>

Это может быть веб-компонент или просто вставка. Проблема в том, что, ставя <h2>, мы предполагаем, что «родительский» заголовок — это <h1>. Если перенести этот фрагмент куда-нибудь в другое место DOM, это предположение может поломать структуру заголовков (так называемую «outline»).

Что если бы мы могли взамен написать так:

<section class="promo">
  <h>Вы считаете, что «сюжет» в фильмах только отвлекает?</h>
  <p>Если да, то вам стоит посмотреть «Джона Уика» — наверняка останетесь довольны!</p>
</section>

…где элемент <h> по контексту привязан к своему родительскому <section>. Теперь этот фрагмент можно перемещать куда угодно, ничего не ломая — заголовок всегда будет обозначать подраздел в своем родителе.

Разметка структуры документа может быть вложенной, и по большому счету HTML так и работает: вкладываем же мы <ol> в <li>, чтобы представить список внутри списка. Секции и заголовки должны работать так же.

Это давно не новость

Идее <h> не меньше 26 лет. Ее можно отыскать в старом письме в рассылке www-talk из далекого 1991-го (спасибо Джереми Киту за наводку). В 2004-м она добралась до спецификации XHTML2. Попала она и в (как ее тогда называли) спецификацию HTML5, но применительно к существующим заголовкам, ради какой-никакой обратной совместимости.

<h1>Заголовок 1 уровня</h1>
<section>
  <h1>Заголовок 2 уровня</h1>
  <h2>Заголовок 3 уровня</h2>
  <section>
    <h6>Заголовок 3 уровня</h6>
  </section>
</section>

По алгоритму структуры документа, как его определяла спецификация HTML, старая система нумерованных заголовков могла сосуществовать с контекстной системой на основе секций, и это ощутимый плюс при работе с существующим контентом. Кроме того, браузеры, не понимающие заголовков для секций, увидят хотя бы сами заголовки.

Что-то из этого браузеры реализовали. Они распознают элемент <section> и отображают заголовки <h1> внутри секций более мелким шрифтом. К сожалению, ни один браузер не реализовал алгоритм структуры применительно к дереву доступности, и это значит, что скринридеры всегда воспринимают <h1> как заголовок 1 уровня, независимо от того, во сколько секций он вложен.

И это паршиво. Ведь ради этой структуры в общем-то всё и затевалось.

<h> нам поможет?

Есть идея, что <h> может это исправить, когда браузеры его реализуют и сделают всё как надо по части дерева доступности.

Это всеобщая ошибка в обсуждении стандартов — я раньше тоже много раз ее допускал. Нельзя сравнивать текущее состояние дел, наблюдаемое в реальности, с утопической реализацией чего-то еще не существующего.

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

Нужны факты. И первый шаг — разобраться, что же пошло не так с прежними предложениями.

Почему браузеры не реализовали алгоритм структуры?

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

  • Доступности достался низкий приоритет и ни у кого так и не дошли руки до нее.
  • Алгоритм структуры сильно бьет по быстродействию.
  • Когда у браузеров дошли руки, разработчики использовали секции неправильно, и если бы они добавили структуру, это повредило бы пользователям.

Если причина в пофигизме или быстродействии, это же касается и <h>, а значит, <h> изрядно рискует наступить на все те же самые грабли.

Но подчеркиваю — я не знаю.

Нас сейчас затронула всеобщая проблема: уверенные утверждения без доказательств (или даже вопреки доказательствам обратного) ценятся выше, чем разумные сомнения знатока. С этим в веб-сообществе нужно бороться. Первый шаг — признать, чего же мы не знаем, затем восполнить этот пробел, и только потом двигаться куда-то дальше.

Чинить тот веб, что есть

С точки зрения того, как работают браузеры и стандарты, чтобы воплотить <h> в жизнь, нужно следующее:

  1. Написать спецификацию для нового элемента.
  2. Доработать алгоритм структуры.
  3. Реализовать новый элемент.
  4. Реализовать алгоритм структуры.

А чтобы заставить <h1> выполнять ту же функцию, достаточно вот этого:

  1. Реализовать алгоритм структуры.

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

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

Если <h> станет стандартом, то в течение какого-то срока его уже будут использовать, а поддержки в браузерах еще не будет. Если нет полифила, то для пользователей этих браузеров этот элемент ничем не лучше, чем <span>. Учитывая, что большинство пользователей скринридеров ориентируется на страницах по заголовкам, ограничиться существующими заголовочными элементами вполне может оказаться безопаснее. Если это возможно, лучше чинить имеющийся веб.

Если окажется, что реализация алгоритма структуры ломает больше сайтов, чем чинит, настолько, что это вообще не вариант, нельзя ли исправить этот алгоритм небольшими уточнениями? Если нет, можно ли сделать его опциональным, чтобы его можно было включать и выключать?

<body outline="sectioned">
  <h1>Заголовок 1 уровня</h1>
  <section>
    <h1>Заголовок 2 уровня</h1>
    <section outline="flat">
      <h4>Заголовок 4 уровня</h4>
    </section>
  </section>
</body>

…где структура может возникать в любом элементе из числа структурных элементов или структурных основ. Это предпочтительнее нового элемента, потому что уже имеет какое-то значение для существующих браузеров и сочетается с имеющимся контентом.

Если же проблема лишь в наплевательском отношении к доступности, можно сделать вычисляемый уровень заголовка доступным в DOM, а то и в CSS (как предложила Амелия Беллами-Ройдз):

:heading-level(1) {
  /* стили */
}
:heading-level(2) {
  /* стили */
}

Это вообще будет полезно, и может даже подвигнуть браузеры реализовать алгоритм структуры.

Но главное, что нужно признать — мы не знаем. И это, и большинство утверждений в этой дискуссии на Гитхабе — лишь гадание на гуще. Нам надо подходить к делу серьезнее.

Куда двигаться дальше

Прежде чем швырнуть на платформу новый элемент, который, возможно, ничего не решит, нужно найти ответы на следующие вопросы:

  • Почему браузеры не реализовали алгоритм структуры для заголовков в секциях?
  • Какая доля сайтов ухудшится/улучшится/останется без изменений, если реализовать алгоритм структуры HTML как есть?
  • Если что-то поломается, можно ли исправить это небольшими правками алгоритма?
  • Много ли пользователей выиграет, если сделать алгоритм дополнительной опцией?

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

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

Если хотите посмотреть на структуру существующих страниц, валидатор W3C показывает структуру заголовков и в плоском виде, и по секциям. Вот результаты для оригинала этой статьи.

Учитывая, что исходную проблему действительно решать надо, я очень надеюсь, что мы сможем это исправить.

Большое спасибо Стиву Фолкнеру за пару важных дополнений к этой заметке, и вообще за его многолетнюю работу над структурными алгоритмами HTML.

P.S. Это тоже может быть интересно:

5 комментариев

  1. А использование тега «header» без внутреннего h1-h6 некорректно? Если корректно, то никакой h и не нужен, он уже есть…

    1. <header> — не заголовок. У него другая роль. Писать так спецификация не запрещает, но толку для доступности от этого будет не больше, чем от обычного <div>. А хочется, чтоб разметка помогала пользователям тех же скринридеров, и не только…

    1. В теории-то да… Но на практике оказалось, что большая часть этих тегов не работает так, как задумывалось (по крайней мере, с точки зрения доступности). Отчего и возникла необходимость пересмотра всей их «механики».

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.