Почему вам стоит выбрать элемент HTML5 article, а не section

От автора: визуальное отображение браузерами заголовков, вложенных в элементы section, создает впечатление, что они назначают логическую иерархию этим заголовкам. Однако это чисто визуальный эффект и не передается вспомогательным технологиям. Какой смысл в section и как авторы должны отмечать заголовки, которые чрезвычайно важны для пользователей AT?

Несколько дней назад я разговаривал с несколькими друзьями, один из которых спросил меня о разнице между article и section в HTML. Это одна из вечных загадок веб-разработки: «почему white-space: nowrap, а не white-space: no-wrap?» и «почему цвет CSS «gray» более темный, чем «darkgray»?».

Я дал свой обычный ответ: представьте себе article не просто как газетную статью или пост в блоге, но и как одежду — отдельный объект, который можно использовать в другом контексте. Ваши брюки — это article, и вы можете носить их с другим нарядом; ваша рубашка — это article, и ее можно носить с разными брюками; ваши сапоги из лакированной кожи — это article (вы не наденете их только одни без других предметов гардероба, не так ли?).

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

Таким образом, главная страница со списком записей в блоге будет элементом main, обертывающим ряд элементов article, по одному для каждой записи в блоге. Вы бы использовали ту же структуру для списка видео (например, YouTube) с каждым видео, обернутым в article, список товаров (например, Amazon) и так далее. Любой из этих пунктов article является концептуально синдицируемым — каждый может выделяться на отдельной выделенной странице, в объявлении на другой странице, в качестве записи в RSS-ленте и т. д.

Apple WatchOS содержит Reader, который использует элемент article, чтобы узнать основное содержание вашей страницы. Apple говорит:

«Мы перевели Reader на watchOS 5, где он автоматически активируется при переходе по ссылкам на веб-страницы с большим количеством текста. Важно убедиться, что Reader выделяет ключевые части веб-страницы, используя семантическую разметку для усиления значения и назначения элементов в документе. Давайте рассмотрим пример. Сначала мы указываем, какие части страницы являются наиболее важными, оборачивая их в тег article».

В сочетании article с микроданными HTML5 Reader создает оптимальное представление дисплея для небольших экранов смарт-часов:

«В частности, включение этих элементов заголовка в статью гарантирует, что все они отображаются в Reader. Reader также стилизует каждый элемент заголовка по-разному в зависимости от значения его атрибута itemprop. Используя itemprop, мы можем обеспечить, чтобы автор, дата публикации, заголовок и подзаголовок были заметны».

Так что насчет section?

Мой обычный совет таков: не беспокойтесь о section и не беспокойтесь о том, чем он отличается от article. Он был введен как универсальная оболочка для заголовков, чтобы браузер мог определять структуру документа HTML5.

Что? Алгоритм контура документа предполагает использование только одного тега заголовка — h1 — и он волшебным образом «становится» правильным уровнем заголовка (например, превращается в h2, h3 и т.д.), в зависимости от того, насколько глубоко он вложен в секционировании элементов HTML5: article, section и так далее.

Например, вот что вы ввели в CMS:

<h1>My Fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p>

Это прекрасно работает, когда отображается, как отдельная статья. Но как насчет главной страницы, которая является списком последних статей?

<h1>My latest posts</h1> <article> <h1>My fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p> </article> <article> <h1>Another magnum opus</h1> <p>Magnum solero paddle pop</p> </article>

В этом примере, в соответствии со спецификацией, h1 внутри элементов article «становятся» логическими h2, потому что article, как и section, является элементом секционирования.

Примечание: это не новая идея. Еще в 1991 году сэр Анкл Тимбо писал:

«Я бы на самом деле предпочел, вместо h1, h2 и т.д. для заголовков [те приходят из AAP DTD] иметь вложенности элементов <SECTION>…</SECTION>, и общие <H>…</H>, которые на любом уровне в секциях будут генерировать необходимый уровень заголовка.»

Однако, к сожалению, ни один браузер не реализует контуры HTML5, поэтому нет смысла использовать section. В какой-то момент программа чтения с экрана JAWS попыталась реализовать алгоритм контура документов (в IE, но не в Firefox), но это плохо получилось. Кажется, что разработчики браузеров просто не заинтересованы в этом (больше подробностей в разделе ссылок «Дополнительные материалы»).

«Но, — вставил другой собеседник, — теперь браузеры отображают различные размеры шрифта в зависимости от того, насколько глубоко h1 вложены в section», и продолжил доказывать это. Разрыв мозга!

Вот похожая демонстрация. В левом столбце показаны четыре h1, вложенных в section; в правом столбце показаны h1, h2, h3, h4, без вложенности. Снимок экрана из Firefox показывает, что для вложенных h1 по умолчанию используется тот же шрифт, что и для обычных тегов h1…h4:

Сравнение h1, вложенных в элементы section, и h1, h2, h3, h4>

Те же результаты будут в Chrome, производных Chromium, таких как Edge beta для Mac, и Safari для Mac. Значит ли это, что мы все должны с радостью начать использовать h1, в качестве единственного элемента заголовка, вложив его в section?

Нет. Потому что это только изменение визуального стиля h1. Если мы откроем инспектор специальных возможностей Firefox в инструментах разработчика, то увидим, что текст «level 2» оформлен стилем H2, но все еще установлен на «уровне 1» — дерево доступности не было изменено на уровень 2.

Инспектор доступности Firefox показывает, что вложенный элемент h1 визуально выглядит так же, как и h2, но для его aria-level неправильно установлено значение «1», а не «2»

Сравните это с реальным H2 в правом столбце:

Инспектор доступности Firefox показывает, что реальный h2 имеет вычисленный aria-level «2», что корректно

Это показывает, что дерево доступности было правильно проинформировано, что это заголовок уровня 2. Фактически, Mozilla действительно пыталась передать вычисленный уровень в дерево специальных возможностей:

«Мы немного поэкспериментировали с этим… но потом нам пришлось это отменить, потому что люди в нашей команде жаловались на слишком большое количество регрессий (случайное понижение уровней h1 и тому подобное)».

Для пользователей вспомогательных технологий жизненно важна правильная иерархия заголовков. Как показал восьмой опрос пользователей WebAIM:

«Полезность правильных структур заголовков очень высока: 86,1% респондентов считают уровни заголовков очень или в определенной степени полезными».

Поэтому вы должны продолжать использовать h1…h6 и игнорировать section.

Никогда не говори никогда

«Но…, — возможно, теперь возмутитесь вы, — на этой самой странице есть элемент section!». И вы будете правы, дорогой читатель. «Краткое содержание» заключено в section, по соображениям доступности. Когда пользователь программы чтения с экрана Леони Уотсон провела свой вебинар «Как пользователь программы чтения с экрана получает доступ в Интернет», она указала на область, в которой разметка журнала Smashing Magazine может быть изменена, чтобы улучшить ее восприятие.

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

«Краткое содержание» Smashing отделено от полной статьи горизонтальной линией

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

<section aria-label="quick summary"> Summary text </section>

В большинстве программ чтения с экрана элемент