2024-03-08T00:36:43+01:00https://blog.comandeer.pl/a11yComandeer’s blogKategoria 'Dostępność'Dostępność w nieoczekiwanych miejscachComandeer2023-05-18T00:00:00+02:002023-05-18T00:00:00+02:00https://blog.comandeer.pl/dostepnosc-w-nieoczekiwanych-miejscach.htmlDzisiaj, 18 maja 2023, obchodzimy kolejny Światowy Dzień Świadomości Dostępności (ang. Global Accessibility Awareness Day). Z tej okazji naszła mnie krótka ref…<p>Dzisiaj, 18 maja 2023, obchodzimy kolejny <a href="https://accessibility.day/">Światowy Dzień Świadomości Dostępności (ang. <i lang="en">Global Accessibility Awareness Day</i>)</a>. Z tej okazji naszła mnie krótka refleksja o tym, jak postrzegana jest dostępność.</p>
<p>Gdyby zapytać przypadkową osobę webdeveloperską o to, czym jest dostępność, to jest duża szansa uzyskania odpowiedzi, że to dostosowanie strony tak, aby mogły z niej korzystać także osoby z niepełnosprawnościami. To prawda. Prawdopodobnie można by też usłyszeć o <a href="https://wcag21.lepszyweb.pl/">standardzie WCAG</a>. I to też jak najbardziej prawda. Problem polega na tym, że nie <em>cała</em> prawda.</p>
<p>Bo dostępność bardzo trudno zamknąć w obiektywnie weryfikowalny standard. Jasne, strona zgodna z WCAG ma zdecydowanie większe szanse być faktycznie dostępna, ale nawet <a href="https://wcag21.lepszyweb.pl/#background-on-wcag-2">wprowadzenie do tego standardu</a> zaznacza, że</p>
<blockquote>
<p>Chociaż wytyczne poruszają szereg zagadnień, nie jest możliwe, aby odpowiadały szczegółowo na potrzeby wszystkich możliwych rodzajów, stopni niepełnosprawności, czy też niepełnosprawności złożonych.</p>
</blockquote>
<p>WCAG to przede wszystkim zbiór dobrych, sprawdzonych w boju praktyk, których przestrzeganie pozwoli stworzyć podstawy dostępnego rozwiązania. Ale bardzo często, by stworzyć faktycznie dostępne rozwiązanie, trzeba pochylić się także nad innymi kwestiami – często takimi, które wcale nie są oczywiste.</p>
<p>Cofnijmy się nieco i spójrzmy, jak w ogóle definiowana jest dostępność. Bardzo ładną definicję znaleźć można na <a href="https://en.wikipedia.org/wiki/Web_accessibility">angielskiej Wiki</a>:</p>
<blockquote>
<p><strong>Web accessibility</strong>, or <strong>eAccessibility</strong>,[<a href="https://en.wikipedia.org/wiki/Web_accessibility#cite_note-sec1095-1">1]</a> is the <a href="https://en.wikipedia.org/wiki/Inclusion_(disability_rights)">inclusive practice</a> of ensuring there are no barriers that prevent interaction with, or access to, <a href="https://en.wikipedia.org/wiki/Website">websites</a> on the <a href="https://en.wikipedia.org/wiki/World_Wide_Web">World Wide Web</a> by people with physical <a href="https://en.wikipedia.org/wiki/Disabilities">disabilities</a>, situational disabilities, and socio-economic restrictions on bandwidth and speed.</p>
<p>[Dostępność stron WWW lub eDostępność to inkluzywna praktyka zapewniająca brak barier w dostępie i interakcji ze stronami WWW przez osoby z niepełnosprawnościami trwałymi i sytuacyjnymi oraz osoby z ograniczeniami socjo-ekonomicznymi dotyczącymi transferu i prędkości łącza.]</p>
</blockquote>
<p>W tej definicji pojawia się aspekt, którego zwykle nie łączy się z dostępnością: ograniczenia transferu i prędkości łącza. Innymi słowy – za dostępność uznać można także kwestie związane z wydajnością stron internetowych. Zwłaszcza, że <a href="https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/">Sieć to nie tylko szerokopasmowe łącza</a>. W chwili, gdy <a href="https://whatdoesmysitecost.com/">każdy bajt słono kosztuje</a>, rozmiar strony zaczyna ograniczać dostęp do niej w bardzo podobny sposób co niedostosowanie do osób z niepełnosprawnościami. I to wyłącznie od autora strony zależeć będzie, czy zapewni dostępność takim osobom, np. poprzez ograniczenie ilości wczytywanego JavaScriptu czy skorzystanie z dobrych praktyk (jak np. <a href="https://web.dev/vitals/">Web Vitals</a>).</p>
<p>Warto przy tym zauważyć, że WCAG nigdzie nie wspomina o wydajności. Stąd też ograniczenie się wyłącznie do spełniania wymogów standardu niekoniecznie uchroni nas przed odcięciem dostępu sporej liczbie użytkowników. I właśnie dlatego warto regularnie sprzątać pod metaforycznym łóżkiem naszej strony – bo możemy znaleźć problemy z dostępnością w naprawdę nieoczekiwanych miejscach.</p>
Nie żyją nagłówki, niech żyją nagłówki!Comandeer2022-07-01T18:03:00+02:002022-07-01T18:03:00+02:00https://blog.comandeer.pl/nie-zyja-naglowki-niech-zyja-naglowki.htmlStało się. Po ponad 12 latach przepychanek, w końcu algorytm outline’u został usunięty ze specyfikacji HTML.<p>Stało się. <a href="https://html5accessibility.com/stuff/2022/04/05/12-years-beyond-a-html-joke/">Po ponad <strong>12 latach</strong> przepychanek</a>, w końcu <a href="https://github.com/whatwg/html/commit/6682bdeee6fb08f5972bea92064fe250f1b4ec9c">algorytm outline’u został usunięty ze specyfikacji HTML</a>.</p>
<p>W praktyce zmienia to niewiele, bo o tym, że ten algorytm nie działa, <a href="https://www.tpgi.com/html5-document-outline/">wiedziano od bardzo dawna</a>. Jedynym miejscem, w którym próbowano ten fakt ignorować, była właśnie specyfikacja. To się jednak dzisiaj zmieniło i algorytm przestał istnieć. A zatem tak naprawdę jedynym prawidłowym sposobem wykorzystania nagłówków jest ten jeszcze z czasów HTML 4 – czyli <a href="https://blog.comandeer.pl/o-naglowkach-slow-kilka.html#znaczenie-nag%C5%82%C3%B3wk%C3%B3w">tworzenie odpowiedniej hierarchii</a>.</p>
<p>Jedyna faktyczna zmiana względem najlepszych praktyk ustalonych lata temu to zmiana przeznaczenia <a href="https://html.spec.whatwg.org/multipage/sections.html#the-hgroup-element">elementu <code class="language-plaintext highlighter-rouge">hgroup</code></a>. Tak po prawdzie, było to nieuniknione, bo ten element był stworzony z myślą o starym algorytmie outline’u i czekało go albo usunięcie, albo zmiana semantyki. Wybrano tę drugą opcję i obecnie <code class="language-plaintext highlighter-rouge">hgroup</code> służy do grupowania nagłówków wraz z ich podtytułami lub tytułami alternatywnymi, np:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><hgroup></span>
<span class="nt"><h1></span>HTML<span class="nt"></h1></span>
<span class="nt"><p></span>Living standard<span class="nt"></p></span>
<span class="nt"></hgroup></span>
</code></pre></div></div>
<p>Warto zwrócić uwagę, że nawet przy wykorzystaniu <code class="language-plaintext highlighter-rouge">hgroup</code> <a href="https://blog.comandeer.pl/o-naglowkach-slow-kilka.html#podtytu%C5%82y">podtytuł jest akapitem</a>.</p>
<p>I to w sumie tyle. 12 lat czekania na w dużej mierze formalną zmianę w specyfikacji.</p>
Światowy Dzień Świadomości Dostępności 2021Comandeer2021-05-20T16:53:00+02:002021-05-20T16:53:00+02:00https://blog.comandeer.pl/swiatowy-dzien-swiadomosci-dostepnosci-2021.htmlDzisiaj obchodzimy Światowy Dzień Świadomości Dostępności (Global Accessibility Awareness Day – GAAD)! W tym roku jest on jubileuszowy, bo już dziesiąty. Od ty…<p>Dzisiaj obchodzimy <a href="https://globalaccessibilityawarenessday.org/">Światowy Dzień Świadomości Dostępności (Global Accessibility Awareness Day – GAAD)</a>! W tym roku jest on jubileuszowy, bo już dziesiąty. Od tylu lat to wydarzenie pomaga w krzewieniu wiedzy na temat dostępności w kontekście technologii i oprogramowania.</p>
<p>W tym roku też świętuję, tworząc artykuły. Chociaż na tę edycję przygotowałem się nieco skromniej, bo tylko jednym artykułem – ale też po angielsku jak ostatnio (z polskim akcentem!): <a href="https://ckeditor.com/blog/accessibility-availability-and-progressive-enhancement/">Accessibility, availability and Progressive Enhancement</a>. Miłego czytania!</p>
Fałszywa dychotomia – estetyka a dostępnośćComandeer2021-02-27T23:33:00+01:002021-02-27T23:33:00+01:00https://blog.comandeer.pl/falszywa-dychotomia-estetyka-a-dostepnosc.htmlW webdevie pokutuje przekonanie, że strona może być albo ładna, albo dostępna. Myślą tak nawet laureaci Awwwards 2020. Problem w tym, że przekonanie to jest ca…<p>W webdevie pokutuje przekonanie, że strona może być albo ładna, albo dostępna. Myślą tak nawet <a href="https://twitter.com/ericwbailey/status/1351243179060768778">laureaci Awwwards 2020</a>. Problem w tym, że przekonanie to jest całkowicie błędne i często drobne zmiany mogą sprawić, że ładna strona stanie się także o wiele bardziej dostępna.</p>
<h2 id="animacja-czyli-słoń-w-składzie-porcelany">Animacja, czyli słoń w składzie porcelany</h2>
<p>Najczęściej pojawiającym się błędem jest nierespektowanie ustawień użytkownika w zakresie animacji – a dokładniej: animowanie elementów strony nawet wówczas, gdy <a href="https://support.apple.com/pl-pl/guide/mac-help/mchlc03f57a1/mac">na poziomie systemu użytkownik ustawił ograniczenie ruchu</a>. Strony internetowe mogą wykrywać tego typu ustawienie przy pomocy <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion">media query <code class="language-plaintext highlighter-rouge">prefers-reduced-motion</code></a>. To w połączeniu z <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia">funkcją <code class="language-plaintext highlighter-rouge">matchMedia</code></a> pozwala na choćby wczytanie alternatywnej, mniej wodotryskowej wersji witryny, gdy okaże się, ze użytkownik chce bardziej <em>statyczną</em> stronę.</p>
<p>Taka alternatywna wersja nie musi być jakoś mocno odmienna. Strona wciąż może wyglądać bardzo podobnie po usunięciu animacji. Weźmy taką <a href="https://activetheory.net/">stronę Active Theory</a>. W alternatywnej wersji na ekranie wyświetlałby się po prostu wybrany screen z projektu, najechanie myszką na przycisk nie powodowałoby efektu fali, a tło nie miałoby efektu paralaksy. I to w sumie tyle. Podbić jeszcze kontrast i dodać wyraźniejsze style dla focusu i mamy całkiem dostępną stronę.</p>
<p>Że niby traci się to specyficzne doświadczenie osiągnięte dzięki animacjom? Może – ale równocześnie niskim kosztem pozwalamy ze strony skorzystać o wiele większej liczbie osób, przy jednoczesnym zapewnieniu im <em>porównywalnego</em> doświadczenia (korzystania z takiej samej strony, tyle że bez animacji).</p>
<h2 id="accessible-first">Accessible First</h2>
<p>Niemniej myślę, że istnieje lepszy sposób, niż przygotowywanie alternatywnej, bardziej dostępnej wersji – podejście, które można by nazwać <i lang="en">Accessible First</i> (z ang. dostępność jako pierwsza). Tak, jak najczęściej zaleca się, by responsywność przygotowywać w podejściu <a href="mobile/content first">mobile/content first</a>, tak być może czas zalecać, by strony tak ogólnie tworzyło się w podejściu priorytetyzującym dostępność.</p>
<p>Założenie jest bardzo proste: zaczynamy od jak najprostszej wersji strony, która po prostu przekazuje treść w dostępny sposób (czyli tak naprawdę zaczynamy w tym samym miejscu, co w mobile/content first). Następnie dodajemy nowe funkcje, przez cały czas pozostając w zgodzie ze <a href="https://w3c.github.io/wcag/guidelines/22/">standardem WCAG</a>. Tego typu podejście sprawia, że sposób myślenia o stronie przez cały okres jej powstawania skupia się wokół jej dostępności, co pozwala w łatwiejszy sposób ominąć typowe problemy z nią związane. Przykładem mogą być animacje, które nie będą stanowić już niezbędnego elementu doświadczenia użytkownika, ale będą tylko opcjonalnym dodatkiem dla użytkowników, którzy sobie ich życzą. Znów: bardzo podobnie do mobile/content first, w którym <a href="https://www.webkrytyk.pl/2019/01/31/kurs-web-developer-od-podstaw-w-15-dni-od-samuraja-programowania/#dzien-13">poszczególne nowe elementy strony dodawane są w zależności od możliwości urządzenia użytkownika</a>. A w obydwu przypadkach bardzo podobnie do <a href="https://www.aaron-gustafson.com/notebook/insert-clickbait-headline-about-progressive-enhancement-here/">Progressive Enhancement</a>. Cebula w cebuli w cebuli. I z tego cebulowego gulaszu wychodzi <a href="https://responsibleweb.app/">pyszne danie</a>. Warte w sumie swojej własnej książki kucharskiej.</p>
O semantyce słów kilkaComandeer2020-05-31T18:26:00+02:002020-05-31T18:26:00+02:00https://blog.comandeer.pl/o-semantyce-slow-kilka.htmlW świecie webdevu semantyka to dość modne słowo. Tylko co to tak naprawdę jest i do czego służy?<p>W świecie webdevu semantyka to dość modne słowo. Tylko co to tak naprawdę jest i do czego służy?</p>
<h2 id="problem-semantyki">Problem semantyki</h2>
<p>Najczęściej słowo to przejawia się w sformułowaniu “znaczniki/elementy semantyczne” lub “nowe znaczniki/elementy semantyczne w HTML5”. Przyznaję, że sam niejednokrotnie używałem tych zwrotów (zwłaszcza pierwszego), niemniej ostatnio staram się ich wystrzegać. A to dlatego, że są mocno nieprecyzyjne.</p>
<p class="note">Warto zwrócić uwagę na różnicę między elementami a znacznikami. W potocznym języku często te dwie nazwy używa się zamiennie, ale nie są one w pełni równoważne. Element oznacza znacznik początkowy (otwierający), znacznik końcowy (zamykający) oraz treść pomiędzy nimi. Z kolei znaczniki są niejako "ogranicznikami" elementu. <a href="https://developer.mozilla.org/en-US/docs/Glossary/HTML#concept_and_syntax" rel="noreferrer noopener">Infografika na MDN-ie</a> dobrze tłumaczy tę różnicę.</p>
<p>Nie istnieje coś takiego, jak elementy semantyczne. <strong>Każdy element w HTML-u jest semantyczny, bo ma określone znaczenie</strong>. Nawet ten nieszczęsny <code class="language-plaintext highlighter-rouge">div</code> jest semantyczny, bo <a href="https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element"><em>specyfikacja opisuje jego znaczenie</em></a>:</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">div</code> element has no special meaning at all. It <a href="https://html.spec.whatwg.org/multipage/dom.html#represents">represents</a> its children. It can be used with the <code class="language-plaintext highlighter-rouge">class</code>, <code class="language-plaintext highlighter-rouge">lang</code>, and <code class="language-plaintext highlighter-rouge">title</code> attributes to mark up semantics common to a group of consecutive elements. It can also be used in a <code class="language-plaintext highlighter-rouge">dl</code> element, wrapping groups of <code class="language-plaintext highlighter-rouge">dt</code> and <code class="language-plaintext highlighter-rouge">dd</code> elements.</p>
<p>[Element <code class="language-plaintext highlighter-rouge">div</code> nie ma żadnego specjalnego znaczenia. Reprezentuje swoje dzieci. Może być użyty wraz z atrybutami <code class="language-plaintext highlighter-rouge">class</code>, <code class="language-plaintext highlighter-rouge">lang</code> i <code class="language-plaintext highlighter-rouge">title</code>, żeby przekazywać znaczenie (semantykę) typową dla grupy następujących po sobie elementów. Może być też użyty wewnątrz elementu <code class="language-plaintext highlighter-rouge">dl</code>, otaczając grupy elementów <code class="language-plaintext highlighter-rouge">dt</code> i <code class="language-plaintext highlighter-rouge">dd</code>.]</p>
</blockquote>
<p>Widzimy tutaj, że definicja znaczenia (semantyki) <code class="language-plaintext highlighter-rouge">div</code>a składa się tak naprawdę z dwóch części:</p>
<ul>
<li>określenia samego znaczenia,</li>
<li>zasugerowania sposobów <em>rozszerzenia</em> semantyki <code class="language-plaintext highlighter-rouge">div</code>a.</li>
</ul>
<p>Jeśli chodzi o samo znaczenie, to… <code class="language-plaintext highlighter-rouge">div</code> nic nie znaczy sam w sobie. Nie ukrywam, że nie jest to specjalnie intuicyjnie i zapewne to spowodowało powstanie sformułowania “znacznik semantyczny”. Ale równocześnie specyfikacja podaje sposób na dodanie do <code class="language-plaintext highlighter-rouge">div</code>a konkretnego znaczenia. I tutaj pojawia się kolejny problem: ta dodatkowa semantyka nie jest przeznaczona dla użytkowników.</p>
<p>Podsumowując: <code class="language-plaintext highlighter-rouge">div</code> jest elementem semantycznym, ponieważ ma znaczenie: nic nie znaczy, ale równocześnie może coś znaczyć, niemniej nie w sposób istotny dla użytkownika.</p>
<div style="max-width:100%;height:0;padding-bottom:119%;position:relative;"><iframe src="https://giphy.com/embed/HfFccPJv7a9k4" width="100%" height="100%" style="position:absolute" frameborder="0" class="giphy-embed" allowfullscreen=""></iframe></div>
<p><a href="https://giphy.com/gifs/HfFccPJv7a9k4">via GIPHY</a></p>
<p>Spróbujmy jednak połapać się w tym galimatiasie!</p>
<div class="note">
<p>Z "nowymi znacznikami semantycznymi w HTML5" istnieje jeszcze jeden problem: one nie są nowe. Można by wręcz powiedzieć, że jak na standardy Sieci są wręcz <em>antyczne</em>. Pierwsze wersje większości "nowych" elementów pojawiły się co najmniej w roku 2005, jeszcze w czasach, gdy HTML5 nawet się tak nie nazywał. Wówczas było to <a href="https://whatwg.org/specs/web-apps/2005-09-01/">Web Applications 1.0</a>. W tym standardzie można odnaleźć elementy takie jak <code>section</code>, <code>article</code>, <code>aside</code>, <code>header</code>, <code>footer</code>, <code>canvas</code>… Były też <a href="https://whatwg.org/specs/web-apps/2005-09-01/#other">inne elementy</a>, które nie przetrwały do dziś, np. <code>calendar</code>, <code>switch</code> czy <code>datagrid</code>. Ba, był już nawet <a href="https://whatwg.org/specs/web-apps/2005-09-01/#outlines">nieszczęsny algorytm outline'u</a>. Zatem "nowe" to dość odważne słowo w tym wypadku.</p>
<p>Zresztą część tych pomysłów jest jeszcze starsza i sięga wstecz co najmniej do 2002 roku, do czasów niesławnego XHTML 2.0 (dzięki któremu, nomen omen, powstało HTML5). Ta specyfikacja zawiera m.in. <a href="https://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.18.">element <code>section</code></a> czy… <a href="https://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.11.">algorytm outline'u</a>. Część z tych pomysłów przekopiowano następnie do nowego HTML-a oraz dodano nowe. Więc tak po prawdzie "nowe znaczniki semantyczne w HTML5" nie są ani nowe, ani niekoniecznie są z HTML5.</p>
</div>
<h2 id="definicja-semantyki">Definicja semantyki</h2>
<p><strong>Semantyka elementu to jego znaczenie</strong>.</p>
<p>I to w sumie tyle. Mówiąc o semantycznym HTML-u, mówimy o HTML-u, który znaczy <em>to, co chcemy, żeby znaczył</em>. Zatem dobieramy odpowiednie elementy. Jeśli coś jest nagłówkiem, używamy <code class="language-plaintext highlighter-rouge">h1</code>–<code class="language-plaintext highlighter-rouge">h6</code>, jeśli coś jest linkiem, używamy <code class="language-plaintext highlighter-rouge">a</code>, jeśli coś jest po prostu kontenerem na inne elementy, używamy <code class="language-plaintext highlighter-rouge">div</code> itd.</p>
<p>Dla celów praktycznych można jednak tę definicję nieco rozszerzyć: semantyka elementu to jego znaczenie <strong>opisane w specyfikacji</strong>. Innymi słowy: źródłem semantyki jest <a href="https://html.spec.whatwg.org/multipage/">specyfikacja HTML</a>. Zresztą jest to <a href="https://html.spec.whatwg.org/multipage/dom.html#semantics-2">napisane w niej wprost</a>:</p>
<blockquote>
<p>Elements, attributes, and attribute values in HTML are defined (by this specification) to have certain meanings (semantics). For example, the <code class="language-plaintext highlighter-rouge">ol</code> element represents an ordered list, and the <code class="language-plaintext highlighter-rouge">lang</code> attribute represents the language of the content.</p>
<p>[Elementy, atrybuty i wartości atrybutów w HTML-u są zdefiniowane (przez tę specyfikację) jako posiadające konkretne znaczenia (semantykę). Na przykład element <code class="language-plaintext highlighter-rouge">ol</code> reprezentuje listę uporządkowaną, a atrybut <code class="language-plaintext highlighter-rouge">[lang]</code> reprezentuje język treści.]</p>
</blockquote>
<p>Specyfikacja też <a href="https://html.spec.whatwg.org/multipage/dom.html#element-definitions">wyraźnie zaznacza, w którym miejscu znajduje się dokładny opis znaczenia konkretnego elementu</a>:</p>
<blockquote>
<p>This is then followed by a description of what the element <a href="https://html.spec.whatwg.org/multipage/dom.html#represents">represents</a>, along with any additional normative conformance criteria that may apply to authors and implementations. Examples are sometimes also included.</p>
<p>[Po tym [pozostałych częściach definicji elementu] następuje opis, co reprezentuje dany element, łącznie z dodatkowymi formalnymi wymogami zachowania zgodności z tą specyfikacją, które mogą dotyczyć autorów i implementacji. W niektórych przypadkach są również dostępne przykłady.]</p>
</blockquote>
<p>Te definicje elementów znajdują się w rozdziale 4. specyfikacji, <cite>The elements of HTML</cite> (Elementy HTML-a). Jak widać, w tym rozdziale mamy zarówno elementy o mocno określonym znaczeniu (<a href="https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements">nagłówki</a>, <a href="https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-data-element"><code class="language-plaintext highlighter-rouge">data</code></a>, <a href="https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element"><code class="language-plaintext highlighter-rouge">details</code></a>), jak i te, które <em>specjalnie</em> nic nie znaczą (<a href="https://html.spec.whatwg.org/multipage/grouping-content.html#the-div-element"><code class="language-plaintext highlighter-rouge">div</code></a>, <a href="https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-span-element"><code class="language-plaintext highlighter-rouge">span</code></a>, <a href="https://html.spec.whatwg.org/multipage/scripting.html#the-template-element"><code class="language-plaintext highlighter-rouge">template</code></a>).</p>
<p>Stąd też <code class="language-plaintext highlighter-rouge">div</code> ma znaczenie – ponieważ jego opis znajduje się w specyfikacji HTML. Żeby wiedzieć, że <code class="language-plaintext highlighter-rouge">div</code> nic nie znaczy, trzeba się tego dowiedzieć ze specyfikacji. Choć brzmi to pokrętnie, to osobiście dla mnie ta sytuacja jest bardzo podobna do tego, w jaki sposób funkcjonuje zero. To liczba, która oznacza… nic. Jak się doda 0 do dowolnego działania, wynik się nie zmieni. A mimo to zero bywa przydatne – właśnie dlatego, że <em>nic nie robi</em>. Dokładnie tak samo jest z <code class="language-plaintext highlighter-rouge">div</code>em.</p>
<h3 id="problemy-językoznawcze">Problemy językoznawcze</h3>
<p>Taka jeszcze dygresja na koniec definiowania semantyki. Za to, że po polsku słowa “semantyka” i “znaczenie” są traktowane całkowicie osobno, wprowadzając tym samym pewne nieścisłości terminologiczne, obwiniłbym różnice, jakie istnieją między językiem angielskim i polskim. <a href="https://www.oxfordlearnersdictionaries.com/definition/english/semantics">W angielskim</a> semantyka oznacza zarówno naukę o znaczeniu slów, jak i samo ich znaczenie. <a href="https://sjp.pwn.pl/sjp/semantyka;2575165.html">W polskim</a> semantyka oznacza już tylko naukę.</p>
<p>Niemniej nawet mimo tej różnicy (a może właśnie dzięki niej) sformułowania typu “znaczenie semantyczne” czy “znaczniki semantyczne” są tym bardziej niezrozumiałe. Dlatego uważam, że mówiąc o semantyce elementów, należy pamiętać, że chodzi nam o nic innego, jak o <em>znaczenie</em> elementów. Być może byłoby o wiele lepiej, gdybyśmy po polsku używali właśnie takiego sformułowania, zamiast hermetycznej semantyki. Ale ten okręt już odpłynął…</p>
<h2 id="trzy-poziomy-semantyki">Trzy poziomy semantyki</h2>
<p>Rozprawiliśmy się już z pierwszą częścią definicji elementu <code class="language-plaintext highlighter-rouge">div</code>. Zostaje jednak jeszcze druga, w której to nic nieznaczący <code class="language-plaintext highlighter-rouge">div</code> zdobywa znaczenie, ale wciąż nic nie znaczy… Nielogiczne? Bynajmniej, ponieważ trzeba zauważyć, że elementy mają tak naprawdę trzy poziomy semantyki (znaczenia):</p>
<ul>
<li>formalny, opisany w specyfikacji i przeznaczony <strong>dla użytkowników</strong>,</li>
<li>formalny, którego infrastruktura jest opisana w specyfikacjach, a który przeznaczony jest <strong>dla przeglądarek i innych programów</strong>,</li>
<li>nieformalny, oparty na konwencjach częściowo opisanych w specyfikacji i przeznaczony <strong>dla webdeveloperów</strong>.</li>
</ul>
<h3 id="dla-użytkowników">Dla użytkowników</h3>
<p>To najbardziej oczywisty poziom znaczenia elementów i ten, o którym dotąd najwięcej mówiliśmy. Dzięki doborze odpowiednich elementów mamy pewność, że każdy użytkownik Sieci zrozumie to, co chcemy przekazać – i to nawet, gdyby na naszej stronie nie zadziałał JS czy nawet CSS. Przeglądarki domyślnie prezentują określone elementy w konkretny sposób, np. nagłówki mają większy rozmiar i są pogrubione, linki są niebieskie i podkreślone, przyciski mają charakterystyczny kształt i kolor itd.</p>
<p>Co więcej, poszczególne elementy często powiązane są z konkretnymi, natywnymi zachowaniami. Weźmy znów taki przycisk: nie dość, że użytkownik bez problemu zrozumie, że ma do czynienia z przyciskiem, to dodatkowo będzie mógł go prosto obsłużyć z poziomu klawiatury. To samo dotyczy linków czy np. <code class="language-plaintext highlighter-rouge">details</code>. Znaczenie elementów jest wprost powiązane z tym, jak się zachowują i tym, jak użytkownicy <em>oczekują</em>, że dane elementy będą się zachowywać. Dlatego <a href="https://blog.comandeer.pl/czy-div-jest-dostepny.html">nie warto psuć tego, co Po Prostu Działa™</a>.</p>
<h3 id="dla-przeglądarek-i-innych-programów">Dla przeglądarek i innych programów</h3>
<p>Jednak z HTML-a korzystają nie tylko użytkownicy, ale także programy. Najprostszym przykładem może być przeglądarka, która może udostępnić użytkownikowi dodatkowe funkcje, dzięki temu, że strona jest stworzona przy pomocy poprawnie dobranych elementów. Jedną z takich funkcji jest tzw. <a href="https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages"><span lang="en">reader view</span> (ang. tryb poprawionej czytelności)</a>, który wycina wszystkie dodatkowe elementy strony i zostawia samą treść, ostylowaną w sposób ułatwiający czytanie. W jaki sposób przeglądarka odnajduje treść? <a href="https://www.brucelawson.co.uk/2018/the-practical-value-of-semantic-html/">Przy pomocy odpowiednich elementów</a>, takich jak <code class="language-plaintext highlighter-rouge">main</code> czy <code class="language-plaintext highlighter-rouge">article</code>.</p>
<p>Niemniej czasami trzeba przekazać programom dodatkowe informacje. Można to zrobić przy pomocy atrybutów, takich jak <a href="https://html.spec.whatwg.org/multipage/dom.html#global-attributes"><code class="language-plaintext highlighter-rouge">[class]</code></a>, <a href="https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes"><code class="language-plaintext highlighter-rouge">[data-*]</code></a> czy <a href="https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes"><code class="language-plaintext highlighter-rouge">[lang]</code></a>, elementów, takich jak <a href="https://html.spec.whatwg.org/multipage/semantics.html#the-link-element"><code class="language-plaintext highlighter-rouge">link</code></a> czy <a href="https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element"><code class="language-plaintext highlighter-rouge">meta</code></a>, albo całych dodatkowych mechanizmów, takich jak <a href="https://html.spec.whatwg.org/multipage/microdata.html#microdata">mikrodane</a>, <a href="https://w3c.github.io/json-ld-syntax/">JSON-LD</a>, <a href="https://www.w3.org/TR/rdfa-primer/">RDFa</a>, <a href="https://w3c.github.io/aria/">ARIA</a> czy <a href="https://w3c.github.io/manifest/">manifest aplikacji sieciowej</a>. Te wszystkie sposoby nie są do końca opisane w specyfikacjach. Specyfikacje zawierają jedynie opis, jak takie mechanizmy działają i jak je implementować, natomiast to, co mają przekazywać, zależy już w pełni od tego, jak zostaną użyte. Myślę, że dobrą analogią będzie książka kucharska. Przepis pokazuje nam, jak zrobić suflet, ale to, co z tego sufletu wyjdzie, zależy już wyłącznie od nas. I dokładnie tak jest w tym wypadku: specyfikacja jest przepisem, a to, jak tych rzeczy użyjemy, to nasz suflet.</p>
<h3 id="dla-webdeveloperów">Dla webdeveloperów</h3>
<p>No i HTML-a używają w końcu także i webdeveloperzy. W sumie to dość oczywiste: jak inaczej mieliby robić strony internetowe? Niemniej “czysty” HTML może być dość trudny do szybkiego ogarnięcia i utrzymania. Trzeba przyznać, że <code class="language-plaintext highlighter-rouge">ul.menu</code> od razu mówi, do czego służy dany element, podczas gdy <code class="language-plaintext highlighter-rouge">ul</code> pozwala nam dowiedzieć się jedynie tego, że to <em>jakaś</em> lista. I to jest właśnie ostatni poziom semantyki, oparty na konwencjach, które różnią się między poszczególnymi projektami i które znaczą coś tylko dla osób pracujących z kodem. To po prostu semantyka pozwalająca na organizację i utrzymanie kodu strony internetowej.</p>
<p>Do tego poziomu semantyki zaliczyć też trzeba wszelkiego rodzaju metodyki, takie jak choćby <a href="https://en.bem.info/">BEM</a>. Z perspektywy HTML-a warstwa BEM jest właśnie tym: dodatkowym znaczeniem, przeznaczonym dla webdeveloperów.</p>
<h2 id="rozszerzanie-semantyki">Rozszerzanie semantyki</h2>
<p>Opis poszczególnych poziomów semantyki pokazuje, że podstawowe znaczenie każdego elementu można rozszerzać (a wręcz, do pewnego stopnia, <em>zmienić</em>) na wiele różnych sposobów, co daje wiele różnych rezultatów. Weźmy na tapet nagłówek <code class="language-plaintext highlighter-rouge">h2</code>:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><h2></span>Comandeer<span class="nt"></h2></span>
</code></pre></div></div>
<p>Ot, zwykły nagłówek. Ale dodajmy do niego odpowiednią klasę, żeby zaznaczyć, że to nagłówek sekcji:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><h2</span> <span class="na">class=</span><span class="s">"section__heading"</span><span class="nt">></span>Comandeer<span class="nt"></h2></span>
</code></pre></div></div>
<p>Chcielibyśmy także poinformować cały świat, że ta konkretna sekcja jest o pewnej osobie, a nagłówek zawiera jej imię. W tym celu użyjemy RDFa (będziemy musieli także zmienić nieco samą sekcję):</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><section</span> <span class="na">class=</span><span class="s">"section"</span> <span class="na">vocab=</span><span class="s">"http://schema.org"</span> <span class="na">typeof=</span><span class="s">"Person"</span><span class="nt">></span>
<span class="nt"><h2</span> <span class="na">class=</span><span class="s">"section__heading"</span> <span class="na">property=</span><span class="s">"name"</span><span class="nt">></span>Comandeer<span class="nt"></h2></span>
<span class="nt"></section></span>
</code></pre></div></div>
<p>Tym sposobem nasz nagłówek przekazuje informacje z wszystkich wymienionych wyżej poziomów semantyki:</p>
<ul>
<li>na najbardziej podstawowym poziomie to wciąż nagłówek, dzięki czemu użytkownik wie, że zaczyna się nowa sekcja,</li>
<li>dzięki RDFa wyszukiwarki internetowe i inne programy wiedzą, że to sekcja o osobie, która nazywa się “Comandeer”,</li>
<li>dzięki klasie webdeveloperzy wiedzą, że to nagłówek sekcji.</li>
</ul>
<p>W podobny sposób można rozszerzać znaczenie praktycznie każdego elementu HTML.</p>
<h2 id="semantyka-a-dostępność">Semantyka a dostępność</h2>
<p>Ok, teoria teorią, ale czy ma to faktyczne przełożenie na cokolwiek? Jak najbardziej. Najprościej wykazać to, pokazując, jak semantyka wpływa na dostępność. Robiłem to już zresztą wcześniej, np. w <a href="https://blog.comandeer.pl/o-naglowkach-slow-kilka.html#nag%C5%82%C3%B3wki-a-dost%C4%99pno%C5%9B%C4%87">artykule o nagłówkach</a> czy <a href="https://blog.comandeer.pl/czy-div-jest-dostepny.html#dost%C4%99pno%C5%9B%C4%87-to-nie-tylko-czytniki-ekranowe">artykule o przyciskach w React Native</a>.</p>
<p>W skrócie: każdy element HTML jest prezentowany w określony sposób w <a href="https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree">drzewku dostępności</a>. To, jak dokładnie, wynika z jego <a href="https://w3c.github.io/html-aria/#docconformance">domyślnej roli ARIA</a>. Bardzo prosto to pokazać na przykładzie np. nagłówka i podrabianego nagłówka:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><style></span>
<span class="nc">.heading</span> <span class="p">{</span>
<span class="nl">all</span><span class="p">:</span> <span class="n">unset</span><span class="p">;</span>
<span class="nl">display</span><span class="p">:</span> <span class="nb">block</span><span class="p">;</span>
<span class="nl">font-size</span><span class="p">:</span> <span class="m">2em</span><span class="p">;</span>
<span class="nl">line-height</span><span class="p">:</span> <span class="m">2</span><span class="p">;</span>
<span class="nl">font-weight</span><span class="p">:</span> <span class="nb">bold</span><span class="p">;</span>
<span class="p">}</span>
<span class="nt"></style></span>
<span class="nt"><h1</span> <span class="na">class=</span><span class="s">"heading"</span><span class="nt">></span>Nagłówek<span class="nt"></h1></span>
<span class="nt"><span</span> <span class="na">class=</span><span class="s">"heading"</span><span class="nt">></span>Nagłówek<span class="nt"></span></span>
</code></pre></div></div>
<p>Z punktu widzenia użytkownika, który posługuje się wizualną przeglądarką, obydwa elementy wyglądają tak samo i mogą pełnić role nagłówka. Ale gdy z jakiegoś powodu nie doczyta się CSS (bo np. padnie CDN), drugi z elementów przestanie pełnić swoją rolę. Dodatkowo w drzewku dostępności te obydwa elementy są prezentowane zupełnie inaczej:</p>
<figure class="figure">
<a href="/assets/images/o-semantyce-slow-kilka/accessibility-tree.png" rel="noopener noreferrer" class="figure__link">
<img src="/assets/images/o-semantyce-slow-kilka/accessibility-tree.png" alt="Element h1 ma rolę heading, podczas gdy span – text container." class="figure__image" />
</a>
<figcaption class="figure__caption">Widok elementów w inspektorze dostępności Firefoksa</figcaption>
</figure>
<p>To oznacza, że np. użytkownicy czytników ekranowych nie będą w stanie wykorzystać drugiego z elementów do nawigacji po stronie, a przeglądarka lub inny program nie będzie w stanie wygenerować poprawnego spisu treści dla takiej strony.</p>
<p>Teoretycznie można to naprawić nadając elementowi <code class="language-plaintext highlighter-rouge">span</code> odpowiednią rolę przy pomocy ARIA (<code class="language-plaintext highlighter-rouge">[role=heading]</code>), ale to nie rozwiązuje wszystkich problemów. Pomijając już problem z CSS-em (który, faktycznie, nie jest najczęstszy), to jaką mamy pewność, że np. Google traktuje <code class="language-plaintext highlighter-rouge">span[role=heading]</code> tak samo jak <code class="language-plaintext highlighter-rouge">h1</code>? Nie bez powodu pierwsza zasada ARIA brzmi: <a href="https://w3c.github.io/using-aria/#rule1">nie używaj ARIA, jeśli istnieje natywny element HTML robiący daną rzecz</a>.</p>
<h2 id="semantyka-a-seo">Semantyka a SEO</h2>
<p>A jak już jesteśmy przy Google, to warto wspomnieć o tym, w jaki sposób wykorzystuje dodatkowe informacje semantyczne, przekazywane przy pomocy RDFa czy JSON-LD. Dzięki nim możemy do pewnego stopnia wpływać na to, jak prezentowana będzie nasza strona w wynikach wyszukiwania. Najprostszym przykładem może być dodanie gwiazdek z oceną przy wyszukiwaniu produktu:</p>
<figure class="figure">
<a href="/assets/images/o-semantyce-slow-kilka/google-schema.png" rel="noopener noreferrer" class="figure__link">
<img src="/assets/images/o-semantyce-slow-kilka/google-schema.png" alt="Moja książka w wynikach wyszukiwania ma ocenę 4.2/6 w Helionie oraz 6/10 w Lubimy czytać." class="figure__image" />
</a>
</figure>
<p>Tego typu gwiazdki można dodać przy pomocy <a href="https://schema.org/Review">odpowiedniego typu danych Schema.org</a>. Samo Schema.org to wspólna inicjatywa Google, Microsoftu (Binga), Yahoo i Yandexu, która dostarcza wspólnego dla tych wyszukiwarek sposobu oznaczania dodatkowej semantyki. Dzięki temu wyszukiwarki te mogą w prosty sposób odczytywać różne dodatkowe informacje, jak m.in. oceny produktów czy ich ceny. Ot, taka namiastka <a href="https://en.wikipedia.org/wiki/Semantic_Web#Web_3.0">Web 3.0</a>.</p>
<hr />
<p>Mam nadzieję, że ten <del>krótki</del> artykuł rozwiewa nieco wątpliwości, jakie przez lata narosły wokół semantyki, oraz pokazuje, dlaczego jest ona istotna – i to nie tylko ze względu na dostępność. A teraz przepraszam, bo widzę kilka źle użytych <code class="language-plaintext highlighter-rouge">div</code>ów…</p>
Światowy Dzień Świadomości DostępnościComandeer2019-05-16T18:10:00+02:002019-05-16T18:10:00+02:00https://blog.comandeer.pl/swiatowy-dzien-swiadomosci-dostepnosci.htmlDzisiaj obchodzimy Światowy Dzień Świadomości Dostępności (Global Accessibility Awareness Day – GAAD)!<p>Dzisiaj obchodzimy <a href="https://globalaccessibilityawarenessday.org/">Światowy Dzień Świadomości Dostępności (Global Accessibility Awareness Day – GAAD)</a>!</p>
<p>Jak sama nazwa wskazuje, dzień ten jest poświęcony krzewieniu wiedzy na temat problemu dostępności związanej z technologią i oprogramowaniem. Co prawda w ten dzień chyba najszerzej dyskutuje się o problemach związanych z dostępnością stron internetowych, ale poruszane są także inne aspekty dostępności cyfrowej, jak choćby ta związana z aplikacjami desktopowymi i mobilnymi.</p>
<p>Nie byłbym sobą, gdybym nie zdecydował się nieco uświetnić ten dzień. Dlatego też współstworzyłem 2 artykuły dotyczące dostępności stron internetowych (tym razem po angielsku): <a href="https://ckeditor.com/blog/Practical-web-accessibility-guide/">Practical web accessibility guide</a> oraz <a href="https://ckeditor.com/blog/Web-accessibility-testing-DIY/">Web accessibility testing - DIY!</a>. Myślę, że ten drugi jest nawet ciekawszy, bo jest luźno oparty na tym, w jaki sposób testuję strony na potrzeby <a href="https://www.webkrytyk.pl/">WebKrytyka</a>. Miłego czytania!</p>
Czy div jest dostępny?Comandeer2019-02-15T23:50:00+01:002019-02-15T23:50:00+01:00https://blog.comandeer.pl/czy-div-jest-dostepny.html14 lutego Ryan Florence napisał na Twitterze, że przyciski w React Native Web (RNW) są dostępne:<p>14 lutego <a href="https://twitter.com/ryanflorence/status/1095884090484518914">Ryan Florence napisał na Twitterze, że przyciski w React Native Web (RNW) są dostępne</a>:</p>
<blockquote>
<p>Both true:</p>
<ol>
<li>
<p>Most devs should just use a <code class="language-plaintext highlighter-rouge"><button></code>, not <code class="language-plaintext highlighter-rouge"><a></code>, <code class="language-plaintext highlighter-rouge"><div></code>, <code class="language-plaintext highlighter-rouge"><span></code>, etc.</p>
</li>
<li>
<p>React Native Web’s div buttons are better buttons than <code class="language-plaintext highlighter-rouge"><button></code></p>
<ul>
<li>Still keyboard and AT accessible</li>
<li>Better touch event handling</li>
<li>Populate <code class="language-plaintext highlighter-rouge">e.relatedTarget</code> unlike <code class="language-plaintext highlighter-rouge"><button></code></li>
<li>Easier to style</li>
</ul>
</li>
</ol>
<p>I think a lot of HTML/CSS experts are being overly critical of React because they see the output of the new <a href="https://t.co/ogT1tMANTm">https://twitter.com </a> and <em>think</em> they know there are fundamental flaws when they see the div soup.
That div soup is accessible.</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><h2/></span>
<span class="nt"><div</span> <span class="na">role=</span><span class="s">"heading"</span> <span class="na">aria-level=</span><span class="s">"2"</span><span class="nt">/></span>
<span class="nt"><button/></span>
<span class="nt"><div</span> <span class="err">{...</span><span class="na">allTheRightAttributesAndEventHandlers</span><span class="err">}</span><span class="nt">/></span>
</code></pre></div> </div>
<p>These are identical as far as accessibility is concerned when implemented correctly.</p>
<p>If you’re critical of this, you don’t actually care about a11y, you care about your niche</p>
<p>So yeah … just use a button, or a RNW button, but not your own div button.</p>
<p>[Obydwa stwierdzenia są prawdziwe:</p>
<ol>
<li>Większość devów powinna używać <code class="language-plaintext highlighter-rouge"><button></code> zamiast <code class="language-plaintext highlighter-rouge"><a></code>, <code class="language-plaintext highlighter-rouge"><div></code>, <code class="language-plaintext highlighter-rouge"><span></code> itd.</li>
<li>Przycisk z React Native Web oparty o div jest lepszy niż <code class="language-plaintext highlighter-rouge"><button></code>:
<ol>
<li>Wciąż dostępny z poziomu klawiatury i technologii asystującej.</li>
<li>Lepsza obsługa dotyku.</li>
<li>Zawiera <code class="language-plaintext highlighter-rouge">e.relatedTarget</code> w przeciwieństwie do <code class="language-plaintext highlighter-rouge"><button></code>.</li>
<li>Łatwiejszy do stylowania.</li>
</ol>
</li>
</ol>
<p>Myślę, że wielu ekspertów HTML/CSS jest zbytnio krytycznych względem Reacta, ponieważ widzą oni kod nowego <a href="https://twitter.com">Twittera</a> i <em>myślą</em>, że wiedzą, żę są tam podstawowe błędy, gdy widzą divową zupę.</p>
<p>Ta divowa zupa jest dostępna.</p>
<div class="language-javascript highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="o"><</span><span class="nx">h2</span><span class="o">/></span>
<span class="o"><</span><span class="nx">div</span> <span class="nx">role</span><span class="o">=</span><span class="dl">"</span><span class="s2">heading</span><span class="dl">"</span> <span class="nx">aria</span><span class="o">-</span><span class="nx">level</span><span class="o">=</span><span class="dl">"</span><span class="s2">2</span><span class="dl">"</span><span class="o">/></span>
<span class="o"><</span><span class="nx">button</span><span class="o">/></span>
<span class="o"><</span><span class="nx">div</span> <span class="p">{...</span><span class="nx">allTheRightAttributesAndEventHandlers</span><span class="p">}</span><span class="sr">/</span><span class="err">
</span></code></pre></div> </div>
<p>Te kody są identyczne, jeśli bierzemy pod uwagę poprawnie zaimplementowaną dostępność.</p>
<p>Jeśli jesteś krytyczny wobec tego, tak naprawdę nie dbasz o dostępność, ale o własną niszę.</p>
<p>Więc tak… po prostu użyj przycisku albo przycisku z RNW, ale nie swojego własnego przycisku na <code class="language-plaintext highlighter-rouge">div</code>.]</p>
</blockquote>
<p>Takie podejście jest nie tyle niewłaściwe, co szkodliwe. Postaram się pokrótce przybliżyć, czemu tak uważam.</p>
<h2 id="informacje-o-natywnym-przycisku-są-niepełne">Informacje o natywnym przycisku są niepełne</h2>
<p>Przyciski po kliknięciu <em>mają</em> własność <code class="language-plaintext highlighter-rouge">event.relatedTarget</code>:</p>
<iframe width="100%" height="300" src="//jsfiddle.net/Comandeer/Lmuwj7eb/embedded/" allowfullscreen="allowfullscreen" allowpaymentrequest="" frameborder="0"></iframe>
<p>Jeśli ponawigujemy po przykładzie klawiaturą (<kbd>Tab</kbd> oraz <kbd>Shift</kbd>+<kbd>Tab</kbd>), zauważymy, że wyświetla się poprawny identyfikator pola, z którego przeszliśmy do przycisku. Co prawda <a href="https://twitter.com/ryanflorence/status/1096067667570487297">Ryan uściśla następnie, że chodzi o Firefoksa i Safari</a>, ale wciąż nie pokrywa się to z moimi testami. Na moim macOS 10.14.3 zarówno w Firefoksie, jak i w Safari powyższy kod działa – <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus">wbrew informacji na MDN</a> . Być może zmienił się sposób obsługi focusowania na poziomie całego systemu. To równocześnie oznaczałoby, że problem nieprzekazywania <code class="language-plaintext highlighter-rouge">event.relatedTarget</code> przez przyciski jest już rozwiązany.</p>
<p>Inna rzecz, że po raz kolejny dostrzec tu można problem “makizacji” developmentu i <a href="https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/">zamykania go w bańce</a>. Fakt, że coś nie działa w dwóch przeglądarkach na macOS (lub inaczej: zachowuje się zgodnie z tym, jak zachowują się przyciski w tym systemie), nie oznacza równocześnie, że jest to problem globalny. Chrome, <a href="http://gs.statcounter.com/">mający 61% rynku</a>, tego problemu nie posiada, a sam jeden prezentuje już większość rynku. Oczywiście, użytkowników, którzy mogą natrafić na ten błąd, wciąż jest sporo, ale tutaj trzeba sobie zadać pytanie, czy warto jest rezygnować z natywnego <code class="language-plaintext highlighter-rouge">button</code> na rzecz własnego rozwiązania, by zadowolić ok. 15% użytkowników kosztem reszty? W tym wypadku wydaje mi się, że sensowniejszym pomysłem byłoby znalezienie alternatywnego sposobu rozwiązania problemu lub stworzenie jakiegoś obejścia dla przeglądarek na macOS.</p>
<p>Kolejną niepełną informacją jest ta, że przyciski w RNW są łatwiejsze do stylowania. Niemniej ta informacja nie wydaje się być aktualna. Obecnie usunięcie wszystkich stylów z przycisku sprowadza się do użycia w CSS <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/all">własności <code class="language-plaintext highlighter-rouge">all</code> z wartością <code class="language-plaintext highlighter-rouge">unset</code></a>. A jeśli musimy wspierać IE i Edge’a lub natrafimy na (wciąż, niestety, istniejące) bugi z <code class="language-plaintext highlighter-rouge">all: unset</code>, <a href="https://css-tricks.com/overriding-default-button-styles/">istnieją tradycyjne sposoby</a>.</p>
<p>Niepełna jest także informacja o lepszej obsłudze dotyku. Ryan nie podaje szczegółów i nie wiem do końca, o co chodzi. Zwłaszcza, że przecież natywne przyciski również działają normalnie ze zdarzeniami dotykowymi.</p>
<p>Mam także pewną wątpliwość co do źródła danych. <a href="https://twitter.com/ryanflorence/status/1095891544706473985">Ryan przy omawianiu zgodności ARIA-owych zamienników z czytnikami ekranowymi</a> powołuje się na <a href="https://www.powermapper.com/tests/screen-readers/headings/aria-role-heading/">statystyki obsługi ARIA przez czytniki ekranowe</a>. Widzę z nimi jeden podstawowy problem: nie ma w nich ani jednego czytnika głosowego dla Linuksa czy Androida. Być może okazałoby się wówczas, że wsparcie dla divowych nagłówków wcale nie jest takie świetne.</p>
<h2 id="dostępność-to-nie-tylko-czytniki-ekranowe">Dostępność to nie tylko czytniki ekranowe</h2>
<p>Gdy weźmie się pod uwagę wyłącznie czytniki ekranowe, można dojść do wniosku, że faktycznie – <code class="language-plaintext highlighter-rouge">div[role=heading][aria-level=2]</code> jest równoznaczne z <code class="language-plaintext highlighter-rouge">h2</code>. Niemniej dostępność nie kończy się na czytnikach ekranowych – <a href="https://blog.comandeer.pl/refleksje/a11y/2017/06/09/to-tylko-niepelnosprawni.html">dostępność dotyczy absolutnie każdego</a>. I tak jak błędem dostępności jest fakt, że czytnik ekranowy nie potraktuje naszego nagłówka jako nagłówka, tak samo błędem dostępności jest fakt, że dodatek do przeglądarki widomego użytkownika nie będzie mógł stworzyć dla niego spisu treści, bo zamiast nagłówków użyliśmy pełno <code class="language-plaintext highlighter-rouge">div</code>.</p>
<p>I choć dodatek do przeglądarki opierający się na znacznikach HTML, by budować spis treści, nie jest specjalnie popularnym przypadkiem, to o wiele częściej można znaleźć przypadki związane z doborem odpowiednich stylów dla osób niedowidzących. Chyba najprostszym przykładem może być wykorzystanie przez takich użytkowników <a href="http://people.ds.cam.ac.uk/ssb22/css/">własnych stylów CSS</a>. Niestosowanie semantycznych znaczników lub używanie stylów inline (co zresztą RNW też robi, sądząc po <a href="https://necolas.github.io/react-native-web/storybook/?selectedKind=Components&selectedStory=Button&full=0&addons=0&stories=1&panelRight=0">demo</a>) może znacząco wpłynąć na komfort przeglądania strony przez takich użytkowników, a w skrajnym wypadku im to uniemożliwić całkowicie.</p>
<p>Problem ten dotyczy nie tylko niestandardowych arkuszy stylów użytkownika, ale także <a href="https://www.scottohara.me/blog/2019/02/12/high-contrast-aria-and-images.html">wbudowanego w Windows trybu wysokiego kontrastu</a>. Usuwa on bowiem wszystkie style nadane elementom przez developera i na podstawie domyślnych arkuszy stylów przeglądarki oraz <em>semantyki</em> poszczególnych elementów wyświetla wszystkie elementy. W tym momencie przyciski oparte na <code class="language-plaintext highlighter-rouge">div</code> przestaną pełnić swoją funkcję. Dzieje się tak, ponieważ w ich przypadku dostępność jest ściśle połączona z ich prezentacją – tych dwóch aspektów nie da się rozdzielić.</p>
<figure class="figure">
<a href="/assets/images/czy-div-jest-dostepny/rnw-button-hc.png" rel="noopener noreferrer" class="figure__link">
<img src="/assets/images/czy-div-jest-dostepny/rnw-button-hc.png" alt="Brak ramki i innych wyznaczników, że jest to przycisk; został sam tekst." class="figure__image" />
</a>
<figcaption class="figure__caption">Przycisk z RNW w trybie wysokiego kontrastu</figcaption>
</figure>
<figure class="figure">
<a href="/assets/images/czy-div-jest-dostepny/native-button-hc.png" rel="noopener noreferrer" class="figure__link">
<img src="/assets/images/czy-div-jest-dostepny/native-button-hc.png" alt="Ramka wyraźnie wskazuje, w którym miejscu znajduje się przycisk." class="figure__image" />
</a>
<figcaption class="figure__caption">Natywny przycisk w trybie wysokiego kontrastu</figcaption>
</figure>
<p>Przycisk na <code class="language-plaintext highlighter-rouge">div</code> przestaje być przyciskiem w chwili, gdy przestaje wyglądać. Z kolei <code class="language-plaintext highlighter-rouge">button</code> ma przypisaną “przyciskowość” niejako do własnej tożsamości. Tak jak wilk przebrany za owcę nigdy nie stanie się prawdziwą owcą, tak przycisk na <code class="language-plaintext highlighter-rouge">div</code> nigdy nie stanie się tym samym co <code class="language-plaintext highlighter-rouge">button</code>. W wielu przypadkach może się sprawdzić, ale w wielu – spektakularnie się wyglebi.</p>
<p>Dodatkowo fakt, że część stylów jest umieszczana bezpośrednio w znaczniku, w tym te dotyczące animacji, może sprawiać problemy, gdy <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion">pojawi się potrzeba wyłączenia animacji</a>. W przypadku całkowitego rozdziału elementu od prezentacji taka zmiana jest bardzo prosta do wprowadzenia.</p>
<h2 id="divowy-przycisk-nie-działa-bez-js">Divowy przycisk nie działa bez JS</h2>
<p>I zanim ktoś zdąży powiedzieć, że “przecież nikt nie wyłącza dzisiaj JS”: <a href="https://kryogenix.org/code/browser/everyonehasjs.html">JS może nie zadziałać</a>. Ba, wystarczy zadyszka naszego CDN-a, żeby zachowanie dla naszego przycisku wczytało się kilka sekund <em>za późno</em>. Przez ten czas użytkownik będzie wrzucony do doliny dziwów i będzie się zastanawiał, czemu przyciski wyglądające jak przyciski nic nie robią. W przypadku zastosowania <code class="language-plaintext highlighter-rouge">button</code> i podejścia <a href="https://webroad.pl/inne/3722-progressive-enhancement-zapomniany-fundament">Progressive Enhancement</a> można tak pokombinować z <a href="https://medium.freecodecamp.org/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d">SSR</a>, żeby użytkownik dostał podstawową wersję produktu zanim JS się doczyta i był w stanie np. złożyć zamówienie w sklepie. A skoro <a href="https://adactio.com/notes/14815">da się zrobić nowoczesną stronę WWW, która odpala się na pierwszej przeglądarce internetowej w historii</a>, to da się <em>naprawdę dużo</em>.</p>
<h2 id="divowy-przycisk-łamie-pierwszą-zasadę-aria">Divowy przycisk łamie pierwszą zasadę ARIA</h2>
<p><a href="https://w3c.github.io/using-aria/#firstrule">Pierwsza zasada ARIA</a> brzmi: nie używaj ARIA, jeśli istnieje odpowiedni element HTML, którego możesz użyć. Ta zasada nie wzięła się znikąd i mam nadzieję, że powyższe punkty to pokazują. Nie ma sensu wymyślać na nowo koła – zwłaszcza, że jest to koło z napędem odrzutowym i silnikiem jądrowym, które, źle skonstruowane, grozi zniszczeniem całej planety. Skoro nikt nie wpadłby na pomysł budowania takiego cuda w garażu, skoro geniusze z NASA zrobili to w tajnym laboratorium 50 metrów pod ziemią, nie widzę powodu, dla którego ktoś miałby implementować od podstaw przycisk.</p>
<p>Fakt, że divowy przycisk działa dobrze w czytnikach ekranowych, oparty jest na założeniu, że implementacja jest prawidłowa. Problem polega na tym, że to jest ten typ błędów, który wychodzi dopiero w praniu. Przeglądarki miały na to kilkanaście lat, RNW – zdecydowanie mniej. Dodatkowo jest dość niszową technologią, co zmniejsza ryzyko wystąpienia błędów. Tym samym na divowy przycisk czaić się mogą najróżniejsze przypadki brzegowe i inne monstra. Albo po prostu zmieni się standard ARIA lub zachowanie przycisków w przeglądarkach i divowy przycisk przestanie przystawać do rzeczywistości. A źle działający przycisk jest w stanie czasami wyrządzić więcej szkody niż całkowicie niedziałający.</p>
<h2 id="html-to-nie-tylko-dostępność">HTML to nie tylko dostępność</h2>
<p>Stwierdzić, że <code class="language-plaintext highlighter-rouge">div[role=button]</code> to to samo co <code class="language-plaintext highlighter-rouge">button</code>, to jak stwierdzić, że w sumie Słowacki to to samo co Mickiewicz… No nie, po prostu nie. Jeśli na gruncie czytników ekranowych jest to to samo, tak na gruncie semantyki są to całkowicie różne elementy. Fakt, że obecnie coraz większa część Sieci jest divową zupą, wynika z faktu, że <a href="https://christianheilmann.com/2019/01/28/html-is-and-always-was-a-compilation-target-can-we-deal-with-that/">HTML stał się formatem kompilacji</a>. To samo w sobie nie jest złe, ale równocześnie pokazuje problem: <a href="https://marcysutton.com/links-vs-buttons-in-modern-web-applications">współczesne aplikacje nie mają semantycznego HTML-a</a>, bo ich twórcy <em>nie muszą go znać</em>. W końcu z punktu widzenia developera RNW przycisk to po prostu <code class="language-plaintext highlighter-rouge"><Button /></code>. Nikogo nie interesuje, że do przeglądarki trafia ostatecznie taki potwór:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><div</span> <span class="na">role=</span><span class="s">"button"</span> <span class="na">data-focusable=</span><span class="s">"true"</span> <span class="na">tabindex=</span><span class="s">"0"</span> <span class="na">class=</span><span class="s">"rn-1oszu61 rn-1iymjk7 rn-s2skl2 rn-l5bh9y rn-101sy47 rn-1efd50x rn-14skgim rn-rull8r rn-mm0ijv rn-13yce4e rn-fnigne rn-ndvcnb rn-gxnn5r rn-deolkf rn-1loqt21 rn-6koalj rn-1qe8dj5 rn-1mlwlqe rn-eqz5dr rn-1mnahxq rn-61z16t rn-p1pxzi rn-11wrixw rn-ifefl9 rn-bcqeeo rn-wk8lta rn-9aemit rn-1mdbw0j rn-gy4na3 rn-bnwqim rn-1otgn73 rn-eafdt9 rn-1i6wzkk rn-lrvibr rn-1lgpqti"</span> <span class="na">style=</span><span class="s">"background-color: rgb(23, 191, 99);"</span><span class="nt">></span>
<span class="nt"><div</span> <span class="na">dir=</span><span class="s">"auto"</span> <span class="na">class=</span><span class="s">"rn-13yce4e rn-fnigne rn-ndvcnb rn-gxnn5r rn-deolkf rn-jwli3a rn-1471scf rn-14xgk7a rn-1b43r93 rn-o11vmf rn-ebii48 rn-majxgm rn-t9a87b rn-1mnahxq rn-61z16t rn-p1pxzi rn-11wrixw rn-tskmnb rn-1pyaxff rn-xd6kpl rn-1m04atk rn-q4m81j rn-bauka4 rn-tsynxw rn-q42fyq rn-qvutc0"</span><span class="nt">></span>Press me<span class="nt"></div></span>
<span class="nt"></div></span>
</code></pre></div></div>
<p>Nikogo, oprócz użytkowników końcowych, którzy – oprócz wszelkich innych opisanych problemów – muszą najzwyczajniej w świecie ściągnąć ten nadmiarowy kod HTML (albo wygenerować u siebie w przeglądarce, co również nie należy do najwydajniejszych rzeczy pod słońcem). W świecie, w którym walczy się o każdy bajt, <a href="https://meiert.com/en/blog/html-performance/">wycinając wszelkie niepotrzebne znaki z HTML-a</a>, taka rozrzutność jest po prostu niezrozumiała.</p>
<p>Niemniej to tylko fragment problemu. Wspomniane już utrudnienia w audytowaniu takiego kodu również są tylko wycinkiem. Nie można bowiem zapomnieć, że w obecnym świecie <a href="https://medium.com/content-uneditable/a-standard-for-rich-text-data-4b3a507af552">HTML jest uniwersalnym językiem wymiany informacji</a> – popularniejszym nawet od JSON. To język, na bazie którego zbudowano WWW. To język, na bazie którego <a href="https://twobithistory.org/2018/05/27/semantic-web.html">powoli powstaje Semantyczna Sieć</a>. W końcu to język, który traktuje się po macoszemu i odrzuca w pełni jego semantykę… Przez lata wypracowano rozwiązania pokroju <a href="https://www.w3.org/RDF/">RDF</a>, <a href="https://rdfa.info/">RDFa</a>, <a href="https://html.spec.whatwg.org/multipage/microdata.html#microdata">mikrodanych</a>, <a href="https://schema.org/">Schema.org</a>, <a href="https://microformats.io/">mikroformatów</a>, <a href="https://json-ld.org/">JSON-LD</a> i wielu innych, by teraz porzucić to wszystko na rzecz divowej zupy, niemającej jakiejkolwiek semantycznej wartości. Parsowanie tego typu dokumentów i próba wyciągnięcia z niej <em>znaczącej</em> treści jest niemal niemożliwa. A to oznacza, że z HTML-a pozostaje tylko T – tekst odarty z własnego znaczenia.</p>
<p>I dlatego twierdzenie, że obrona semantycznego HTML-a jest obroną pewnej niszy, jest z gruntu fałszywe. Obrona semantycznego HTML-a to obrona podstawowych wartości, na jakich zbudowano Sieć. A niszą w tym zestawieniu pozostaje RNW.</p>
Zawieszenie broniComandeer2018-01-23T23:30:00+01:002018-01-23T23:30:00+01:00https://blog.comandeer.pl/zawieszenie-broni.htmlOstatnio pisałem o wieloletnim konflikcie pomiędzy WHATWG i W3C. Nie spodziewałem się jednak, że przynajmniej częściowo zostanie zażegnany – i to tak pokojowo.<p>Ostatnio pisałem o <a href="https://blog.comandeer.pl/refleksje/a11y/2018/01/05/pyrrusowe-zwyciestwo.html">wieloletnim konflikcie pomiędzy WHATWG i W3C</a>. Nie spodziewałem się jednak, że przynajmniej częściowo zostanie zażegnany – i to tak pokojowo.</p>
<h2 id="ale-co-się-stało">Ale co się stało?</h2>
<p>Dużo. Po pierwsze <a href="https://github.com/whatwg/html/pull/3326">wspomniany w poprzednim wpisie PR</a> został <a href="https://github.com/whatwg/html/pull/3326#event-1423841798">włączony do specyfikacji HTML LS</a>. To zdecydowanie upodobniło definicję <code class="language-plaintext highlighter-rouge">main</code> w HTML LS do tej w HTML 5.x. Na tym się jednak nie skończyło. Anne van Kesteren przygotował bowiem <a href="https://github.com/whatwg/html/pull/3354">drugi PR</a>, który <a href="https://github.com/whatwg/html/pull/3354#event-1436763140">został zmerge’owany dzisiaj (23 stycznia 2018)</a>, a który to usuwał ostatnią poważną różnicę pomiędzy definicjami: możliwość używania więcej niż jednego <em>widocznego</em> elementu <code class="language-plaintext highlighter-rouge">main</code>. Tym samym <a href="https://github.com/whatwg/html/issues/100#event-1436763021">słynne issue #100 zostało ostatecznie zamknięte</a>. Obydwie definicje, choć brzmiały inaczej, mówiły już to samo. Ba, po zmianach poczynionych przez WHATWG wersja definicji <code class="language-plaintext highlighter-rouge">main</code> w HTML LS stała się wręcz <em>lepsza</em> od tej w HTML 5.x. Dlatego też niemal od razu W3C zdobyło się na gest i <a href="https://github.com/w3c/html/issues/1153">postanowiło zmienić swoją definicję na tą z HTML LS</a>. I <a href="https://github.com/w3c/html/issues/1153#event-1437396048">zrobiło to</a>, raptem kilka godzin później.</p>
<p>Tym samym największa różnica pomiędzy HTML LS i HTML 5.x <strong>przestała istnieć</strong>.</p>
<h2 id="treść-porozumienia">Treść porozumienia</h2>
<p>Główne zmiany w stosunku do starszej wersji z HTML 5.x to zamiana sformułowania <q>main contents</q> na <q>dominant contents</q> a także wprowadzenie pojęcia “hierarchicznie poprawnego elementu <code class="language-plaintext highlighter-rouge">main</code>” (ang. <i lang="en">hierarchically correct <code class="language-plaintext highlighter-rouge">main</code> element</i>).</p>
<p>Pierwsza zmiana jest dość dyskusyjna. Główna treść a dominująca treść niby oznaczają to samo, niemniej pierwszy zwrot wydaje się bardziej jednoznaczny. No ale dobra, można to przeżyć.</p>
<p>Druga zmiana ogranicza kontekst występowania <code class="language-plaintext highlighter-rouge">main</code>. Wcześniej HTML 5.x pozwalało umieszczać <code class="language-plaintext highlighter-rouge">main</code> w wielu dziwnych miejscach, np. w <code class="language-plaintext highlighter-rouge">section</code>. Obecna wersja wymusza, żeby <code class="language-plaintext highlighter-rouge">main</code> było bezpośrednio w <code class="language-plaintext highlighter-rouge">body</code>, ewentualnie <code class="language-plaintext highlighter-rouge">div</code>, <code class="language-plaintext highlighter-rouge">form</code> bez dostępnej nazwy (z powodu <a href="https://github.com/whatwg/html/pull/3354#issuecomment-358898757">wymogów ASP .NET</a>) lub custom elemencie. Możliwe jest też umieszczenie <code class="language-plaintext highlighter-rouge">main</code> bezpośrednio w <code class="language-plaintext highlighter-rouge">html</code>, jeśli tworzona przez nas strona nie posiada ani <code class="language-plaintext highlighter-rouge">head</code>, ani <code class="language-plaintext highlighter-rouge">body</code> (co jest dozwolone przez specyfikację).</p>
<h2 id="i-co-teraz">I co teraz?</h2>
<p>Nic. Choć definicje <em>w końcu</em> są takie same, specyfikacja HTML 5.x wciąż zawiera o wiele więcej przykładów, a także dodatkowych, pomocnych uwag, które wyjaśniają najczęstsze problemy z używaniem <code class="language-plaintext highlighter-rouge">main</code>. Z tego też powodu zdania nie zmieniam i wciąż uważam, że W3C umie lepiej w dostępność i semantykę. I WHATWG też to zauważyło, chociaż zajęło im to <em>prawie 3 lata</em>.</p>
<p>Niemniej dla mnie osobiście cała sytuacja jest bezprecedensowa i daje nadzieję, że w końcu dostępność stanie się integralną częścią procesów standaryzacyjnych, co wszystkim nam wyjdzie na dobre.</p>
Pyrrusowe zwycięstwoComandeer2018-01-05T22:35:00+01:002018-01-05T22:35:00+01:00https://blog.comandeer.pl/pyrrusowe-zwyciestwo.htmlW Sieci toczy się obecnie spór na miarę tego pomiędzy Świętym Cesarstwem Rzymskim a papiestwem. Po jednej stronie mamy WHATWG, po drugiej – W3C.<p>W Sieci toczy się obecnie spór na miarę tego pomiędzy Świętym Cesarstwem Rzymskim a papiestwem. Po jednej stronie mamy WHATWG, po drugiej – W3C.</p>
<h2 id="wojna-pozycyjna">Wojna pozycyjna</h2>
<p>Od dość dawna mamy dwa standardy HTML: <a href="http://w3c.github.io/html/">jeden od W3C</a> i <a href="https://html.spec.whatwg.org/multipage/">jeden od WHATWG</a>. Choć obydwa standardy wyrosły z jednego pnia, wkrótce <a href="https://medium.com/content-uneditable/the-great-world-of-open-web-standards-64c1fe53063">zaczęły rozrastać się w dwie strony</a>. WHATWG zaczęło standaryzować albo całkowite nowości (niekoniecznie z jakimikolwiek implementacjami), albo <a href="https://github.com/whatwg/dom/issues/334">rzeczy, które powinny zostać zapomniane</a>. W3C natomiast skupiło się na <a href="http://www.brucelawson.co.uk/2017/editing-the-w3c-html5-spec/"><em>interoperacyjności</em> HTML-a i dostępności</a>. Może i HTML 5.x nie zawiera wszystkich najnowszych ficzerów, ale kładzie duży nacisk na to, by HTML działał dobrze dla wszystkich.</p>
<p>Niemniej WHATWG od dawna narzeka na to, że HTML 5.x w ogóle powstaje, uparcie we wszystkich możliwych sytuacjach <a href="https://annevankesteren.nl/2016/01/film-at-11">nazywając specyfikację od W3C forkiem</a>. Największym pragnieniem WHATWG zdaje się być <em>wyeliminowanie</em> z równania W3C – przynajmniej w zakresie rozwijania HTML-a. Stąd ostatnie <a href="https://blog.whatwg.org/working-mode-changes">powołanie do życia Steering Group</a> czy <a href="https://blog.whatwg.org/copyright-license-change">zmiana licencji standardu HTML na mniej liberalną</a>, co może <a href="https://twitter.com/stevefaulkner/status/940271868329824256">utrudnić dalszy rozwój HTML 5.x</a>.</p>
<p>Pomiędzy organizacjami standaryzującymi zdaje się toczyć wojna. WHATWG na własność chce zagarnąć jak najwięcej standardów – <a href="https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/">i to nie tylko od W3C</a>. I udaje im się to, z prostej przyczyny: WHATWG to organizacja reprezentująca interesy 4 korporacji, które tworzą największe przeglądarki na rynku – Google, Mozilla, Microsoft i Apple. Bez ich zgody W3C czy IETF i tak nie mają <em>jakiejkolwiek</em> mocy sprawczej. I tym sposobem mamy pat.</p>
<h2 id="światełko-w-tunelu">Światełko w tunelu…</h2>
<p>Jak już wspominałem, W3C skupia się w dużej mierze na dostępności. To w końcu ta organizacja rozwija <a href="https://w3c.github.io/wcag21/">WCAG</a> czy <a href="https://w3c.github.io/aria/">ARIA</a>. Nic zatem dziwnego, że w <a href="https://github.com/whatwg/html/issues/100">sporze o <code class="language-plaintext highlighter-rouge">main</code></a> to właśnie W3C reprezentuje tę stronę, która upiera się przy dostępnej wersji definicji tego elementu. WHATWG bardzo długo upierało się przy swoim, aż tu nagle… <a href="https://github.com/whatwg/html/pull/3326">chce zmienić definicję <code class="language-plaintext highlighter-rouge">main</code> na bardziej dostępną</a>. W propozycji pojawia się fragment:</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">main</code> element can be used as a container for the dominant contents of the document.</p>
</blockquote>
<p>To sprawia, że w końcu element <code class="language-plaintext highlighter-rouge">main</code> w wersji od WHATWG jest zgodny z definicją <a href="https://w3c.github.io/aria/#main">roli <code class="language-plaintext highlighter-rouge">main</code> z ARIA</a>. A to równocześnie przybliża nas zdecydowanie do rozwiązania sławetnego sporu pomiędzy WHATWG i W3C.</p>
<h2 id="które-szybko-zgasło">…które szybko zgasło</h2>
<p>Niemniej diabeł – i to dosłownie! – tkwi w szczegółach. Nowa propozycja wciąż nie usuwa bowiem najbardziej kontrowersyjnego fragmentu definicji od WHATWG – możliwości wstawiania kilku <code class="language-plaintext highlighter-rouge">main</code> w obrębie jednej strony:</p>
<blockquote>
<p>While there is no restriction as to the number of <code class="language-plaintext highlighter-rouge">main</code> elements in a document, web developers are encouraged to stick to a single element.</p>
</blockquote>
<p>Żeby było śmieszniej, tego typu ostrzeżenia Domenic Denicola, redaktor WHATWG, <a href="http://www.brucelawson.co.uk/2017/editing-the-w3c-html5-spec/#comment-3778437">krytykował w kontekście HTML 5.x</a>.</p>
<p>Zastanawia także podejście redaktorów WHATWG do całej sprawy. Jak można wyczytać z opisu pull requesta, powstał on tylko i wyłącznie dlatego, że AT nie chcą współpracować:</p>
<blockquote>
<p>there’s no reason to believe AT will change</p>
</blockquote>
<p>Jeszcze ciekawszy obraz sytuacji wyłania się z <a href="https://github.com/whatwg/html/issues/100#issuecomment-355543414">komentarza do słynnego issue #100</a>:</p>
<blockquote>
<p>I also agree that the dominant advice (unless we can get browsers/AT to change per above) should be to have a single <code class="language-plaintext highlighter-rouge"><main></code> per document.</p>
</blockquote>
<p>Można wręcz odnieść wrażenie, że redaktorzy WHATWG trwają w świętym przekonaniu, że poza specyfikacją HTML nie istnieje nic innego i jest ona jedynym źródłem prawdy. A w rzeczywistości zmiana implementacji <code class="language-plaintext highlighter-rouge">main</code> w przeglądarkach tak, by była ona zgodna z definicją w specyfikacji WHATWG pociągnęłaby także za sobą konieczność zmiany definicji roli <code class="language-plaintext highlighter-rouge">main</code> w ARIA czy opisu bindingów w accessibility tree.</p>
<p>Oczywiście nie mogło także zabraknąć uszczypliwości w kierunku W3C:</p>
<blockquote>
<p>It does seem like there may be a case for multiple <code class="language-plaintext highlighter-rouge"><main></code>s when combined with <code class="language-plaintext highlighter-rouge">hidden</code>, as W3C’s fork of HTML already acknowledges.</p>
</blockquote>
<p>Żeby było śmieszniej, od razu na nowo rozgorzała kłótnia o to, czy faktycznie definicję trzeba zmieniać, czy lepiej zmienić… implementacje w przeglądarkach i AT (sic!).</p>
<p>Oczywiście cała dyskusja zostałaby zakończona ponad 2 lata temu, gdyby WHATWG stwierdziło, że faktycznie definicja od W3C jest lepsza i “sforkowało” ją do swojej specyfikacji. Ale piekło jeszcze nie zamarzło, więc nie ma co na to liczyć.</p>
<h2 id="przesunięcie-frontu">Przesunięcie frontu</h2>
<p>Niemniej sam ruch ze strony WHATWG w kierunku poprawienia dostępności HTML LS jest wielkim skokiem dla całej otwartej Sieci. Pytanie tylko, czy nie jest to skok w przepaść i w jaką stronę to wszystko ostatecznie zacznie zmierzać.</p>
<p>Bo prawdę mówiąc wolałbym, żeby nad rozwojem Sieci czuwało kilkadziesiąt korporacji niż tylko cztery, które i tak już dawno podzieliły ten rynek między siebie…</p>
O nagłówkach słów kilkaComandeer2017-07-04T16:20:00+02:002017-07-04T16:20:00+02:00https://blog.comandeer.pl/o-naglowkach-slow-kilka.htmlMam już dość powtarzania wciąż na nowo i nowo bzdur odnośnie wykorzystania nagłówków w HTML5, co wręcz prowadzi do “poprawiania” dobrych materiałów w Sieci. Dl…<p>Mam już dość powtarzania wciąż na nowo i nowo bzdur odnośnie wykorzystania nagłówków w HTML5, co wręcz prowadzi do <a href="http://sowaprogramuje.pl/10-bledow-poczatkujacych-frontend-developerow-czesc-1/#comment-54">“poprawiania” dobrych materiałów w Sieci</a>. Dlatego dzisiaj słów kilka o nagłówkach.</p>
<p><small><strong>Aktualizacja 2022-10-30</strong>: w końcu poprawiłem linki do specyfikacji HTML i dodałem informacje o <code class="language-plaintext highlighter-rouge">hgroup</code> w sekcji o podtytułach.</small></p>
<h2 id="nagłówki--czyli-co">Nagłówki – czyli co?</h2>
<p>Na sam początek warto zastanowić się, czym są nagłówki. Jeśli ktoś o nich wspomina w kontekście SEO, to najlepiej go <em>nie</em> słuchać. Mit o tym, że mają większe znaczenie dla Google od “normalnych” tagów, wziął się z prawdziwej roli nagłówków.</p>
<p>Treść na stronie internetowej powinna być podzielona na sensowne części. Na najbardziej podstawowym poziomie będą to oczywiście akapity, niemniej taki podział jest najczęściej niewystarczający. Dlatego też poszczególne akapity grupuje się w <i>sekcje</i>. Wyznacznikiem sekcji jest właśnie nagłówek.</p>
<p>W jaki sposób poznać, czy strona jest poprawnie podzielona na sekcje, a tym samym – czy nagłówki są wykorzystane poprawnie? To proste: nagłówki powinny stworzyć <i>hierarchię treści</i> (ang. <i lang="en">outline</i>), czyli, mówiąc kolokwialnie, spis treści. Przykład takiego spisu treści można zobaczyć w moim <a href="http://tutorials.comandeer.pl/html5-blog.html">tutorialu o semantycznym HTML-u</a>. Co ciekawe, jest on <a href="https://github.com/Comandeer/comandeers-tutorials/blob/180978efbd9711666f7ac5f0c7c606fc3564abbc/build/bs/build.js#L42-L71">faktycznie generowany z nagłówków</a>.</p>
<h2 id="znaczenie-nagłówków">Znaczenie nagłówków</h2>
<p>Jeśli już wiemy, do czego nagłówki są wykorzystywane, zastanówmy się, jakie mają znaczenie w procesie tworzenia stron WWW. Jak już było to wspomniane, przedstawiają całą strukturę treści na stronie, a zatem: relacje i zależności pomiędzy poszczególnymi sekcjami na stronie. Tutaj na scenę wkracza tzw. <i>poziom nagłówka</i>, a zatem cyferka znajdująca się obok literki “h” w nazwie poszczególnych tagów.</p>
<p>Poziom nagłówka nie oznacza żadnej mocy ani innego dziwnego voodoo, o którym powtarza się w kontekście SEO. Poziom nagłówka oznacza tylko i wyłącznie jego relację w stosunku do innych elementów na stronie. Spójrzmy na przykład:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><h1></span>Gatunki kotów<span class="nt"></h1></span>
<span class="nt"><h2></span>Gatunki europejskie<span class="nt"></h2></span>
<span class="nt"><h3></span>Dachowiec angielski<span class="nt"></h3></span>
<span class="nt"><h3></span>Kanałowiec polski<span class="nt"></h3></span>
<span class="nt"><h2></span>Gatunki azjatyckie<span class="nt"></h2></span>
<span class="nt"><h3></span>Smok<span class="nt"></h3></span>
</code></pre></div></div>
<p>Z tego przykładu wiemy, że cała strona dotyczy gatunków kotów. Tak bowiem mówi nagłówek najwyższego poziomu (tag <code class="language-plaintext highlighter-rouge">h1</code>). Powinien on być tylko jeden na stronie i określać jej tematykę. Następnie dostrzegamy, że strona podzielona jest na 2 duże sekcje: gatunków europejskich i azjatyckich (tagi <code class="language-plaintext highlighter-rouge">h2</code>). Te sekcje zawierają podsekcje (tagi <code class="language-plaintext highlighter-rouge">h3</code>) poświęcone poszczególnym gatunkom kota. Oczywiście te podsekcje mogą mieć swoje podsekcje (tagi <code class="language-plaintext highlighter-rouge">h4</code>), które dalej dzieliłyby na części opisy poszczególnych gatunków (np. “Występowanie”, “Sposób pielęgnacji” itd.).</p>
<h2 id="nagłówki-a-dostępność">Nagłówki a dostępność</h2>
<p>Jak widać, taka struktura jest niezwykle przejrzysta i logiczna. I to już samo w sobie powinno stanowić odpowiedź na pytanie, czemu należy wykorzystywać poszczególne poziomy nagłówków zgodnie z przeznaczeniem. Niemniej jest ważniejszy powód: dostępność.</p>
<p>Niemal wszystkie czytniki ekranowe traktują nagłówki jako <i>punkty nawigacyjne</i>, pomiędzy którymi można przeskakiwać, wykorzystując odpowiedni skrót klawiszowy. To sprawia, że poprawne wykorzystanie nagłówków staje się jeszcze istotniejsze. Wprowadzenie więcej niż jednego nagłówka najwyższego poziomu może wprowadzić niepotrzebne zamieszanie u użytkownika (<a href="https://medium.com/content-uneditable/the-great-world-of-open-web-standards-64c1fe53063">przypadek podobny do wielokrotnego <code class="language-plaintext highlighter-rouge">main</code></a>). Tak samo takie zamieszanie może wprowadzić używanie niepoprawnych poziomów nagłówków czy pomijanie poziomów. Tylko prosta, czysta i sensowna struktura nagłówków na stronie ma <em>jakikolwiek</em> sens z pragmatycznego punktu widzenia.</p>
<p>I tutaj ważna uwaga: jak już wspominałem w <a href="https://blog.comandeer.pl/eksperymenty/a11y/2017/02/11/tworzymy-czytnik-ekranowy.html">artykule o tworzeniu czytnika ekranowego</a>, technologia asystująca wie tyle, ile powie jej przeglądarka. Jak poszczególne nagłówki są oznajmiane technologii asystującej, można zobaczyć np. w narzędziach programistycznych przeglądarki Chrome w zakładce “Accessibility”:</p>
<figure class="figure">
<img src="https://blog.comandeer.pl/assets/images/devtools-a11y.png" alt="Screenshot otwartych narzędzi programistycznych Chrome, w których podglądany w zakładce Accessibility jest tag h2" class="figure__image" />
</figure>
<p>Jak widać, nagłówek <code class="language-plaintext highlighter-rouge">h2</code> jest przedstawiany jako element o roli <code class="language-plaintext highlighter-rouge">heading</code> (nagłówek) i poziomie 2 – zatem wszystko się zgadza.</p>
<h2 id="nagłówki-a-html5">Nagłówki a HTML5</h2>
<p>HTML5 wprowadził nowe znaczniki dzielące stronę na sekcje (tzw. <i>znaczniki sekcjonujące</i>), m.in. <code class="language-plaintext highlighter-rouge">section</code> czy <code class="language-plaintext highlighter-rouge">article</code>. W specyfikacji HTML5 pojawił się także <a href="https://www.w3.org/TR/2014/REC-html5-20141028/sections.html#outlines">zarys nowego algorytmu definiującego hierarchię treści</a>. W skrócie: nieważny był poziom nagłówka, a jedynie poziom jego “zagłębienia”, czyli <code class="language-plaintext highlighter-rouge">body > h2</code> będzie wyżej niż <code class="language-plaintext highlighter-rouge">body > section > h1</code>.</p>
<p>Tak brzmiała teoria. Rzeczywistość okazała się brutalna, bo <a href="https://www.paciellogroup.com/blog/2013/10/html5-document-outline/">żadna przeglądarka nie dodała wsparcia dla tego algorytmu</a>. Algorytm stał się <strong>niebezpieczną fikcją</strong>, która powodowała problemy z dostępnością. Okazało się bowiem, że <code class="language-plaintext highlighter-rouge">body > h2</code> było nagłówkiem niższego rzędu niż <code class="language-plaintext highlighter-rouge">body > section > h1</code>. A z racji tego, że technologia asystująca nie wie o stronie nic ponad to, co dostarczy jej przeglądarka, <strong>nie powinno się korzystać z nowego sposobu definiowania nagłówków</strong></p>
<p>Łatwo to sprawdzić empirycznie. Gdyby nowy algorytm działał, <code class="language-plaintext highlighter-rouge">h1</code> w poniższym kodzie powinien być przedstawiony czytnikowi ekranowemu jako nagłówek drugiego poziomu:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><body></span>
<span class="nt"><section></span>
<span class="nt"><h1></span>Test<span class="nt"></h1></span>
<span class="nt"></section></span>
<span class="nt"></body></span>
</code></pre></div></div>
<p>Zobaczmy zatem, czy Chrome faktycznie tak przedstawia ten nagłówek technologii asystującej:</p>
<figure class="figure">
<img src="https://blog.comandeer.pl/assets/images/devtools-a11y-h1.png" alt="Screenshot otwartych narzędzi programistycznych Chrome, w których podglądany w zakładce Accessibility jest tag section > h1" class="figure__image" />
</figure>
<p>Jak widać, nagłówek wewnątrz sekcji wciąż jest przedstawiany jako nagłówek pierwszego stopnia. To oznacza, że wykorzystanie kilku nagłówków <code class="language-plaintext highlighter-rouge">h1</code> na stronie (mimo stosowania równolegle tagów sekcjonujących) tworzy <strong>płaską hierarchię treści</strong>. Tego typu hierarchia jest całkowicie nieprzydatna z punktu widzenia użytkownika – zwłaszcza takiego, który posługuje się dodatkowo technologią asystującą.</p>
<p>Prawda ta jest znana od zawsze i <a href="https://blog.comandeer.pl/nie-zyja-naglowki-niech-zyja-naglowki.html">w końcu ma odzwierciedlenie w specyfikacji HTML</a> – algorytm outline’u został usunięty i już oficjalnie jedynym poprawnym sposobem na tworzenie hierarchii treści jest <strong>wykorzystywanie wszystkich poziomów nagłówków</strong>.</p>
<p>W kontekście HTML5 powstaje zatem zasadne pytanie: czy jest sens stosować znaczniki sekcjonujące skoro i tak wypada stosować nagłówki po staremu? Uważam, że tak, bo tagi te sprawiają, że kod staje się przejrzystszy. Sekcje są oznaczone już nie tylko przez sam nagłówek, ale przez wyraźny tag <code class="language-plaintext highlighter-rouge">section</code> bądź <code class="language-plaintext highlighter-rouge">article</code>. Tym sposobem kod jest bardziej <i>semantyczny</i>.</p>
<h2 id="główny-nagłówek">Główny nagłówek</h2>
<p>Warto też przez chwilę zastanowić się nad określaniem głównego nagłówka strony. Jak już wiemy, powinno to być <code class="language-plaintext highlighter-rouge">h1</code>. Niemniej pytanie brzmi, co w tym <code class="language-plaintext highlighter-rouge">h1</code> powinno się zawierać?</p>
<h3 id="1--nagłówek-opisujący-podstronę">#1 – nagłówek opisujący podstronę</h3>
<p>Przez lata powtarzałem, że <a href="https://www.webkrytyk.pl/2013/08/18/lexy-com-pl/#naglowki">w przypadku większości stron głównym nagłówkiem strony powinno być logo</a>. Niestety, podgląd ten <a href="http://www.456bereastreet.com/archive/201104/html5_document_outline_revisited/">nie jest mocno popularny wśród użytkowników czytników ekranowych</a>. Większość z nich (ponad 50%) twierdzi, że <code class="language-plaintext highlighter-rouge">h1</code> powinno być tytułem danej podstrony. 30% użytkowników dopuszcza za to istnienie dwóch <code class="language-plaintext highlighter-rouge">h1</code>: dla tytułu całej witryny oraz dla tytułu danej podstrony. Jedynie około 12% uważa, że <code class="language-plaintext highlighter-rouge">h1</code> powinno oznaczać tytuł całej witryny.</p>
<p>Tego typu wyniki doprowadziły do stworzenia techniki, w której logo/nazwa witryny jest nagłówkiem <code class="language-plaintext highlighter-rouge">h1</code> wyłącznie na stronie głównej. Na poszczególnych podstronach logo stanowi już tylko link, natomiast w znaczniku <code class="language-plaintext highlighter-rouge">h1</code> znajduje się tytuł podstrony. Ta technika <del>jest</del> była wykorzystywana m.in. na stronie <a href="https://web.archive.org/web/20170201032956/http://internet-bez-barier.com/"><b>Internet Bez Barier</b></a>. Warto porównać kod <a href="https://web.archive.org/web/20170201032956/http://internet-bez-barier.com/">strony głównej</a> z kodem <a href="https://web.archive.org/web/20170912214540/http://internet-bez-barier.com/tabele-html">dowolnej podstrony</a>:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"><!-- strona główna nagłówek --></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"heading clearfix"</span><span class="nt">></span>
<span class="nt"><img</span> <span class="na">src=</span><span class="s">"http://internet-bez-barier.com/wp-content/themes/internet-bez-barier/images/globe3.png"</span> <span class="na">alt=</span><span class="s">""</span> <span class="nt">/></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"heading-inner"</span><span class="nt">></span>
<span class="nt"><h1</span> <span class="na">class=</span><span class="s">"site-title"</span><span class="nt">></span>Internet bez barier<span class="nt"></h1></span>
<span class="nt"><p</span> <span class="na">class=</span><span class="s">"site-description"</span><span class="nt">></span>blog na temat dostępności stron internetowych<span class="nt"></p></span>
<span class="nt"><a</span> <span class="na">class=</span><span class="s">"skip"</span> <span class="na">href=</span><span class="s">"#main"</span><span class="nt">></span>Przejdź do głównej treści<span class="nt"></a></span>
<span class="nt"></div></span>
<span class="nt"></div></span>
<span class="c"><!-- podstrona nagłówek --></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"heading clearfix"</span><span class="nt">></span>
<span class="nt"><img</span> <span class="na">src=</span><span class="s">"http://internet-bez-barier.com/wp-content/themes/internet-bez-barier/images/globe3.png"</span> <span class="na">alt=</span><span class="s">""</span> <span class="nt">/></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"heading-inner"</span><span class="nt">></span>
<span class="nt"><a</span> <span class="na">class=</span><span class="s">"home-link"</span> <span class="na">href=</span><span class="s">"http://internet-bez-barier.com/"</span> <span class="na">title=</span><span class="s">"strona główna"</span> <span class="na">rel=</span><span class="s">"home"</span><span class="nt">></span>
<span class="nt"><span</span> <span class="na">class=</span><span class="s">"site-title"</span><span class="nt">></span>Internet bez barier<span class="nt"></span></span>
<span class="nt"></a></span>
<span class="nt"><p</span> <span class="na">class=</span><span class="s">"site-description"</span><span class="nt">></span>blog na temat dostępności stron internetowych<span class="nt"></p></span>
<span class="nt"><a</span> <span class="na">class=</span><span class="s">"skip"</span> <span class="na">href=</span><span class="s">"#main"</span><span class="nt">></span>Przejdź do głównej treści<span class="nt"></a></span>
<span class="nt"></div></span>
<span class="nt"></div></span>
[…]
<span class="nt"><h1</span> <span class="na">class=</span><span class="s">"entry-title"</span><span class="nt">></span>Tabele HTML<span class="nt"></h1></span>
</code></pre></div></div>
<p>Jak widać, na stronie głównej nazwa witryny jest wewnątrz tagu <code class="language-plaintext highlighter-rouge">h1</code> i nie jest linkiem (bo znajdujemy się na stronie głównej). Na podstronie z kolei <code class="language-plaintext highlighter-rouge">h1</code> w nazwie witryny jest zastąpione przez link powrotny do strony głównej, a w <code class="language-plaintext highlighter-rouge">h1</code>umieszczono tytuł wpisu. Wydaje mi się, że tego typu podejście jest na chwile obecną najlepsze, niemniej brakuje jakichś większych badań na temat nawigowania przy pomocy nagłówków.</p>
<p>W przypadku stron typu <i lang="en">one-page</i> problemu nie ma. Tutaj w sumie jedynym sensownym wzorcem (moim zdaniem rzecz jasna) jest ten z logo/nazwą witryny w <code class="language-plaintext highlighter-rouge">h1</code>.</p>
<h3 id="2--nagłówek-poza-nawigacją">#2 – nagłówek poza nawigacją</h3>
<p>Istnieje jeszcze jeden wzorzec, o którym warto wspomnieć, a który proponuje np. <a href="http://www.heydonworks.com/">Heydon Pickering</a>: logo strony jest pierwszą pozycją menu nawigacyjnego strony:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><nav</span> <span class="na">role=</span><span class="s">"navigation"</span> <span class="na">aria-label=</span><span class="s">"site links"</span><span class="nt">></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"menu-menu-1-container"</span><span class="nt">></span>
<span class="nt"><ul</span> <span class="na">id=</span><span class="s">"menu-menu-1"</span> <span class="na">class=</span><span class="s">"menu"</span><span class="nt">></span>
<span class="nt"><li</span> <span class="na">id=</span><span class="s">"menu-item-4"</span> <span class="na">class=</span><span class="s">"menu-item menu-item-type-custom menu-item-object-custom current-menu-item current_page_item menu-item-home menu-item-4"</span><span class="nt">></span>
<span class="nt"><a</span> <span class="na">title=</span><span class="s">"HeydonWorks latest blog articles"</span> <span class="na">href=</span><span class="s">"http://www.heydonworks.com"</span><span class="nt">></span>HeydonWorks<span class="nt"></a></span>
<span class="nt"></li></span>
[…]
<span class="nt"></ul></span>
<span class="nt"></div></span>
<span class="nt"></nav></span>
</code></pre></div></div>
<p>W tym modelu nawigacja i nagłówek strony są osobnymi bytami. Trzeba przyznać, że jest to dość sensowne rozwiązanie i stosuje je m.in. <a href="https://www.smashingmagazine.com/">Smashing Magazine</a>. Wydaje mi się, że ten wzorzec najbardziej sprawdziłby się w przypadku aplikacji, w której nagłówki określałyby po prostu kolejne widgety/komponenty, lub na stronach reklamowych, gdzie występuje tzw. <a href="https://www.sitepoint.com/exploring-hero-section/"><i lang="en">hero section</i></a>.</p>
<h3 id="3--nagłówek-witryny">#3 – nagłówek witryny</h3>
<p>No i nie można zapomnieć o najstarszej technice, czyli <code class="language-plaintext highlighter-rouge">h1</code> jako tytule witryny. Choć nie jest to kardynalny błąd, może wprowadzać pewne zamieszanie dla użytkownika czytnika ekranowego. Istnieje wówczas rozbieżność pomiędzy nawigacją przy pomocy tzw. <i>landmarków</i> (<code class="language-plaintext highlighter-rouge">main, nav, article</code>) a nawigacją nagłówkami. Teoretycznie nawigowanie do <code class="language-plaintext highlighter-rouge">main</code> powinno dać ten sam rezultat, co nawigowanie do <code class="language-plaintext highlighter-rouge">h1</code>.</p>
<h2 id="nagłówki-kontekstualne">Nagłówki kontekstualne?</h2>
<p>Nowy algorytm nagłówków w HTML5 miał rozwiązać problem, który od dawna martwi osoby tworzące bardziej skomplikowane aplikacje internetowe: nie zawsze wiadomo, gdzie nasz komponent wyląduje. Wyobraźmy sobie, że robimy sobie w Reactcie komponent “Pogoda” (<code class="language-plaintext highlighter-rouge">Weather</code>), który ma taki kod HTML:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><section></span>
<span class="nt"><h2></span>Pogoda<span class="nt"></h2></span>
<span class="c"><!-- Tu pogoda wczytana skądś tam --></span>
<span class="nt"></section></span>
</code></pre></div></div>
<p>Ten komponent następnie ma trafić jako podsekcja sekcji “Inne wiadomości”:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><section></span>
<span class="nt"><h2></span>Inne wiadomości<span class="nt"></h2></span>
<span class="nt"><Weather</span> <span class="nt">/></span>
<span class="nt"></section></span>
</code></pre></div></div>
<p>I tu pojawia się problem: hierarchia treści pokaże komponent “Pogoda” jako osobną sekcję, sąsiadującą z sekcją “Inne wiadomości” (bo i tu, i tu mamy nagłówek drugiego stopnia). Gdyby algorytm hierarchii treści z HTML5 działał, wówczas nagłówek w “Pogodzie” byłby przedstawiany technologii asystującej jako nagłówek trzeciego poziomu lub niższego. Niemniej algorytm nie działa i jest problem…</p>
<p>Poziomy nagłówków w HTML-u są bowiem <em>globalne</em>. Nie zależą w żaden sposób od miejsca występowania tagu. <code class="language-plaintext highlighter-rouge">h2</code> zawsze będzie nagłówkiem drugiego poziomu, a <code class="language-plaintext highlighter-rouge">h6</code> – szóstego. W czasach, gdy HTML był językiem tworzenia <em>dokumentów hipertekstowych</em>, nie sprawiało to praktycznie żadnego problemu. W chwili, gdy HTML stał się językiem do tworzenia <em>aplikacji internetowych</em>, brak nagłówków <i>kontekstualnych</i> (zależnych od swojego miejsca występowania) staje się problemem. Zwłaszcza, gdy myślimy o całości aplikacji jako o zbiorze niezależnych komponentów. Wówczas często nie wiemy, gdzie dana rzecz ostatecznie się znajdzie, a co za tym idzie – nie jesteśmy w stanie dobrać sensownie poziomu nagłówka.</p>
<p>Na chwilę obecną problem ten najlepiej rozwiązać tworząc… <a href="https://github.com/ThePacielloGroup/html5-h">komponent nagłówka</a>, który za pomocą magii ARIA (<code class="language-plaintext highlighter-rouge">[aria-level]</code> czy <code class="language-plaintext highlighter-rouge">[role=heading]</code>) ustali swój faktyczny poziom. A <a href="https://github.com/whatwg/html/issues/7390">w przyszłości być może doczekamy się tego w HTML-u</a>, dzięki <a href="https://jonathantneal.github.io/h-element-spec/">elementowi <code class="language-plaintext highlighter-rouge">h</code></a>.</p>
<h2 id="podtytuły">Podtytuły</h2>
<p>Została ostatnia kwesia. Podtytytułów nie robi się na nagłówkach. Jest to bowiem dodatkowa informacja do już wstawionego nagłówka. Umieszczanie tego w nagłówku niepotrzebnie komplikowałoby hierarchię treści. Dodatkowo byłoby to utrudnieniem dla użytkowników czytników ekranowych, umieszczając dwa punkty nawigacyjne praktycznie w tym samym miejscu.</p>
<p>Na szczęście standard HTML dochrapał się ostatnio oficjalnego sposobu oznaczania nagłówków. Po usunięciu algorytmu outline’u trzeba było zrobić coś z elementem <code class="language-plaintext highlighter-rouge">hgroup</code>, który nie miał już dłużej sensu. No więc zmieniono jego znaczenie i teraz służy właśnie do <a href="https://html.spec.whatwg.org/multipage/sections.html#the-hgroup-element">grupowania nagłówka wraz z jego podtytułem</a>:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt"><hgroup></span>
<span class="nt"><h1></span>Pan Tadeusz<span class="nt"></h1></span>
<span class="nt"><p></span>czyli ostatni zajazd na Litwie<span class="nt"></p></span>
<span class="nt"></hgroup></span>
</code></pre></div></div>