Почему вы должны выбрать статью HTML5, а не раздел

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

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

Спецификация говорит:

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

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

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

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

Сочетание <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> s», и продолжил это доказывать. С ума сошел!

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

Результаты одинаковы в Chrome, производных Chromium, таких как бета-версия Edge для Mac и Safari на Mac.

Значит ли это, что мы все должны с радостью начать использовать <h1> в качестве нашего единственного элемента заголовка, вложив его в <section> s?

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

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

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

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

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

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

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

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

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

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

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

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

В большинстве программ чтения с экрана элемент <section> не объявляется, если у него нет доступного имени . В данном случае текст арии label. Теперь ее программа чтения с экрана объявила «Область краткой сводки», а после сводки «Конец области краткой сводки». Эта простая разметка также позволяет пользователю программы чтения с экрана при желании перескакивать через сводку.

Мы могли бы использовать простой <div> , но тогда, как пишет Marco Zehe,

«Как правило, если вы помечаете что-то с помощью aria-label или aria-labelledby, убедитесь, что у него есть надлежащая роль виджета или ориентира».

Таким образом, вместо того, чтобы использовать <div role=”region” aria-label=”quick summary”> , мы выбрали <section> , так как у него есть встроенная роль региона, и применим безошибочный закон ARIA Брюса: на. Большой.

Заключение

Надеюсь, вы ушли с этими выводами:

• Не используйте слишком много <h1> s. Сделайте <h1> основным заголовком вашей страницы, затем используйте <h2> , <h3> , <h4> и т. д. в правильной иерархии, не пропуская уровни.
• <section> можно использовать с aria-label, чтобы сообщить пользователю программы чтения с экрана, где начинается и заканчивается конкретная часть статьи. В противном случае забудьте об этом или используйте другой элемент, например <aside aria-label=”quick summary”> или <div role=”region” aria-label=”quick summary”> .
• <main> , <header> , <footer> и <nav> очень полезны для пользователей программ чтения с экрана и совершенно прозрачны для тех, кто не использует вспомогательные технологии. Так что используйте их.
• <article> предназначен не только для постов в блоге — он для любых автономных вещей. Это также помогает WatchOS правильно отображать ваш контент.

Я благодарен Леони Уотсон за помощь в написании этой статьи. Все ошибки полностью по ее вине.

Дальнейшее чтение

• «Заголовки и разделы», HTML 5.2 Рекомендация W3C (14 декабря 2017 г.) Обратите внимание на предупреждение: «В настоящее время нет известных собственных реализаций алгоритма структуры… Поэтому нельзя полагаться на алгоритм структуры для передачи структуры документа пользователям. Авторы должны использовать ранг заголовка (h1-h6) для передачи структуры документа».
• «Алгоритма структуры документа не существует», Адриан Роселли . Все кровавые подробности того, как изменилась спецификация алгоритма секционирования.
• «ARIA в HTML» , черновик редактора W3C (19 декабря 2019 г.) Правила, которым нужно следовать, если вы обнаружите, что добавляете роли и атрибуты ARIA в HTML.
• Практическая ценность семантического HTML», Брюс Лоусон . Моя собственная статья со ссылками на детали того, как WatchOS использует HTML5 и микроданные.