Why You Should Choose HTML5 article Over section

O autorze

Bruce pracuje nad dostępnością, standardami sieciowymi i przeglądarkami od 2001 roku. Dlatego właśnie wygląda tak źle. Możesz śledzić go pod adresem @brucel, lub przeczytać jego …Więcej oBruce↬

Kilka dni temu prowadziłem pogawędkę z kilkoma znajomymi, z których jeden zapytał mnie o różnicę między <article> a <section> w HTML. Jest to jedna z odwiecznych tajemnic tworzenia stron internetowych, wraz z „dlaczego jest white-space: nowrap, a nie white-space: no-wrap?” i „dlaczego CSS 'gray' jest ciemniejszym kolorem niż 'darkgray'?”.

Udzieliłem mojej zwykłej odpowiedzi: pomyśl o <article> nie tylko jako o artykule w gazecie, czy wpisie na blogu, ale jako o artykule odzieżowym – dyskretnej jednostce, która może być ponownie użyta w innym kontekście. Tak więc twoje spodnie są artykułem i możesz je nosić z innym strojem; twoja koszula jest artykułem i może być noszona z innymi spodniami; twoje sięgające kolan buty z lakierowanej skóry na szpilce są artykułem (nie nosiłbyś tylko jednego z nich, prawda?).

Specyfikacja mówi:

„Element article reprezentuje kompletną lub samodzielną kompozycję w dokumencie, stronie, aplikacji lub witrynie, która jest z zasady niezależnie dystrybuowana lub wielokrotnego użytku, np. w syndykacji. Może to być wpis na forum, artykuł w czasopiśmie lub gazecie, wpis na blogu, komentarz przesłany przez użytkownika, interaktywny widget lub gadżet, lub jakikolwiek inny niezależny element zawartości.”

Więc strona główna z listą wpisów na blogu byłaby elementem <main> zawijającym serię elementów <article>, po jednym dla każdego wpisu na blogu. Używałbyś tej samej struktury dla listy filmów (pomyśl o YouTube) z każdym filmem zawiniętym w <article>, listy produktów (pomyśl o Amazon) i tak dalej. Każdy z tych <article>s jest koncepcyjnie syndykatowy – każdy może stać samodzielnie na własnej dedykowanej stronie, w reklamie na innej stronie, jako wpis w kanale RSS, i tak dalej.

Apple’s WatchOS zawiera Reader, który używa elementu <article>s, aby poznać podstawową zawartość Twojej strony. Apple mówi:

„Wprowadziliśmy Readera do watchOS 5, gdzie automatycznie aktywuje się podczas podążania za linkami do stron internetowych o dużej zawartości tekstu. Ważne jest, aby Reader zwracał uwagę na kluczowe części strony internetowej, używając semantycznych znaczników, aby wzmocnić znaczenie i cel elementów w dokumencie. Prześledźmy przykład. Po pierwsze, wskazujemy, które części strony są najważniejsze poprzez zawinięcie ich w znacznik article.”

Połączenie <article> z mikrodanymi HTML5 pomaga Readerowi skonstruować optymalne wyświetlanie dla małych ekranów zegarka:

„W szczególności, zamknięcie tych elementów nagłówka wewnątrz artykułu zapewnia, że wszystkie one pojawią się w Readerze. Reader stylizuje również każdy element nagłówka inaczej, w zależności od wartości jego atrybutu itemprop. Używając itemprop, jesteśmy w stanie zapewnić, że autor, data publikacji, tytuł i podtytuł są wyraźnie wyróżnione.”

Co zatem z <section>?

Moja zwykła rada jest kontynuowana: nie zawracaj sobie głowy <section> lub martw się o to, jak różni się od <article>. Został on wymyślony jako ogólne opakowanie dla nagłówków, aby przeglądarka mogła określić kontur dokumentu HTML5.

Co? Algorytm obrysu dokumentu to sposób na użycie tylko jednego znacznika nagłówka – <h1> – i posiadanie go magicznie „stającego się” odpowiednim poziomem nagłówka (np. zamieniającego się w <h2><h3>, itd.), w zależności od tego, jak głęboko jest zagnieżdżony w elementach sekcji HTML5:<article><section>, i tak dalej.

Więc, na przykład, oto co wpisałeś w swoim CMS:

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

To działa genialnie, gdy jest wyświetlane jako samodzielny artykuł. Ale co z twoją stroną główną, która jest listą twoich najnowszych artykułów?

<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>

W tym przykładzie, zgodnie ze specyfikacją, <h1>s wewnątrz elementów <article>s „stają się” logicznymi <h2>s, ponieważ <article>, podobnie jak <section>, jest elementem sekcjonującym.

Uwaga: To nie jest nowy pomysł. Way back in 1991, Sir Uncle Timbo wrote:

„I would in fact prefer, instead of <h1><h2>, etc. aby nagłówki miały zagnieżdżalny element <SECTION></SECTION>, oraz generyczny <H></H> które na dowolnym poziomie w obrębie sekcji dałyby wymagany poziom Nagłówka.”

Niestety jednak żadna przeglądarka nie implementuje HTML5 outlining, więc nie ma sensu używać <section>. W pewnym momencie czytnik ekranu JAWS próbował zaimplementować algorytm obrysowywania dokumentu (w IE, ale nie w Firefoksie), ale zaimplementował go błędnie. Wygląda na to, że twórcy przeglądarek po prostu nie są zainteresowani (więcej nikczemnych szczegółów w sekcji Further Reading dla prawdziwych anoraków).

„Ale”, wtrącił inny przyjaciel w rozmowie, „teraz przeglądarki wyświetlają różne rozmiary czcionek w zależności od tego, jak głęboko <h1> jest zagnieżdżony w <section>s”, i przystąpił do udowadniania tego. Mind blown!

Tutaj jest podobne demo. Lewa kolumna pokazuje cztery <h1>s, zagnieżdżone w sekcjach; prawa kolumna pokazuje a, <h1><h2><h3><h4> bez zagnieżdżania. Zrzut ekranu Firefoksa pokazuje, że zagnieżdżone <h1>s domyślnie mają taką samą czcionkę jak tradycyjne znaczniki <h1><h4>:

Wyniki są takie same w Chrome, pochodnych Chromium, takich jak Edge beta dla Maca, oraz Safari na Macu.

Czy to oznacza, że wszyscy powinniśmy zacząć używać <h1> jako jedynego elementu nagłówka, zagnieżdżając go w <section>s?

Nie. Ponieważ jest to tylko zmiana w wizualnej stylizacji h1s. Jeśli otworzymy inspektor dostępności Firefoksa w devtools, możemy zobaczyć, że tekst „poziom 2” jest stylizowany na H2, ale nadal jest ustawiony na „poziom 1” – drzewo dostępności nie zostało zmienione na poziom 2.

Porównaj to z Prawdziwym H2 w prawej kolumnie:

To pokazuje, że drzewo dostępności zostało poprawnie poinformowane, że jest to nagłówek poziomu 2. W rzeczywistości Mozilla próbowała przekazać informację o obliczonym poziomie do drzewa dostępności:

„Eksperymentowaliśmy trochę z tym…. ale musieliśmy to przerobić, ponieważ ludzie z naszego zespołu a11y skarżyli się na zbyt wiele regresji (przypadkowe obniżanie <h1> poziomów i takie tam).”

Dla użytkowników technologii wspomagających odpowiednia hierarchia nagłówków jest kluczowa. Jak pokazuje ósme badanie użytkowników czytników ekranu WebAIM,

„Przydatność właściwej struktury nagłówków jest bardzo wysoka, 86,1% respondentów uważa poziomy nagłówków za bardzo lub nieco przydatne.”

W związku z tym powinieneś nadal używać <h1> aż do <h6>, i zignorować section.

Never Say Never

„Ale…” możesz teraz chlipać z oburzeniem, „na tej właśnie stronie jest element <section>!”. I miałbyś rację, drogi czytelniku. Ze względów dostępności „szybkie podsumowanie” jest zawinięte w element <section>. Kiedy użytkownik czytnika ekranu Léonie Watson poprowadziła webinar „How A Screen Reader User Accesses The Web”, wskazała obszar, w którym znaczniki Smashing Magazine mogłyby zostać poprawione, aby jej doświadczenia były lepsze.

Jak widać na zrzucie ekranu, artykuły Smashing są poprzedzone szybkim streszczeniem, po którym następuje pozioma linia oddzielająca streszczenie od właściwego artykułu.

Ale separator jest czysto dekoracyjny, więc Léonie nie mogła stwierdzić, gdzie kończy się podsumowanie, a zaczyna artykuł. Zaproponowała poprawkę: zawinęliśmy streszczenie w element <section>:

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

W większości czytników ekranu element <section> nie jest ogłaszany, chyba że ma dostępną nazwę. W tym przypadku jest to tekst etykiety aria. Teraz, jej czytnik ekranu ogłosił „Szybkie podsumowanie regionu”, a po podsumowaniu „Szybkie podsumowanie regionu koniec”. Ten prosty znacznik umożliwia również użytkownikowi czytnika ekranu przeskoczenie nad podsumowaniem, jeśli chce.

Mogliśmy użyć prostego <div> ale wtedy, jak pisze Marco Zehe,

„Jako zasada kciuka, jeśli etykietujesz coś poprzez aria-label lub aria-labelledby, upewnij się, że ma to odpowiedni widget lub rolę landmarka.”

Więc zamiast używać <div role=”region” aria-label=”quick summary”>, wybraliśmy <section>, ponieważ ma to wbudowaną rolę regionu, a nieomylne prawo Bruce’a ARIA™ ma zastosowanie: wbudowane pokonuje bolt-on. Bigly.

Podsumowanie

Mam nadzieję, że wyniosłeś z tego następujące wnioski:

• Nie używaj mnóstwa <h1>s. Uczyń <h1> głównym nagłówkiem swojej strony, następnie użyj <h2><h3><h4>, itd. w odpowiedniej hierarchii bez pomijania poziomów.
• <section> może być użyty z aria-label, aby zasygnalizować użytkownikowi czytnika ekranu, gdzie dana podczęść artykułu zaczyna się i kończy. W przeciwnym razie należy o nim zapomnieć lub użyć innego elementu, takiego jak <aside aria-label=”quick summary”> lub <div role=”region” aria-label=”quick summary”>.
• <main><header><footer> i <nav> są bardzo przydatne dla użytkowników czytników ekranu i całkowicie przejrzyste dla tych, którzy nie korzystają z technologii wspomagającej. Więc używaj ich.
• <article> nie jest tylko dla postów na blogu – jest dla każdej samodzielnej rzeczy. Pomaga on również WatchOS prawidłowo wyświetlać Twoje treści.

Wdzięcznie dziękuję Léonie Watson za pomoc w napisaniu tego artykułu. Wszelkie błędy są całkowicie jej winą.

Dalsza lektura

• „Headings And Sections,” HTML 5.2W3C Recommendation (14 Dec. ’17)Zwróć uwagę na jego ostrzeżenie: „Obecnie nie są znane natywne implementacje algorytmu konspektu … Dlatego nie można polegać na algorytmie konspektu w celu przekazania struktury dokumentu użytkownikom. Autorzy powinni używać rang nagłówków (h1-h6), aby przekazać strukturę dokumentu.”
• „There Is No Document Outline Algorithm,” Adrian RoselliWszystkie krwawe szczegóły tego, jak zmieniła się specyfikacja algorytmu podziału na sekcje.
• „ARIA w HTML,” W3C Editor’s Draft (19 Dec. ’19)Zasady, według których należy żyć, jeśli chcesz dodać role i atrybuty ARIA do HTML.
• „The Practical Value Of Semantic HTML”, Bruce LawsonMój własny artykuł, łączący się ze szczegółami tego, jak WatchOS używa HTML5 i mikrodanych.

(ra, il)