Technologia asystująca

Czym jednak jest technologia asystująca? Za definicją proponowaną przez WHO:

Assistive products help maintain or improve an individual’s functioning related to cognition, communication, hearing, mobility, self-care and vision, thus enabling their health, well-being, inclusion and participation.

[Produkty asystujące pomagają w utrzymaniu lub poprawie funkcjonowania osoby w zakresie funkcji poznawczych, komunikacji, słuchu, mobilności, samoopieki oraz wzroku, pozwalając tej osobie być zdrową fizycznie i psychicznie, włączoną w życie społeczne oraz uczestniczącą w nim.]

Ta definicja jest niezwykle szeroka i obejmuje tak naprawdę wszystkie sprzęty oraz oprogramowanie, które pomagają w codziennym funkcjonowaniu. Stąd można do niej zaliczyć np. wózek inwalidzki, czytniki ekranu, ale też choćby lupę. Swego czasu opisałem trochę przykładów takich technologii.

Systemowa technologia asystująca

Systemy operacyjne dostarczają osobom z nich korzystających wbudowanych technologii asystujących. Lista takich technologii będzie się różnić w zależności od systemu. Weźmy jako przykład macOS-a. Chyba najbardziej znaną technologią asystującą dostępną wraz z tym systemem jest czytnik ekranowy VoiceOver. Nie jest bynajmniej jedyną. Ustawienia systemu posiadają mocno rozbudowaną sekcję poświęconą dostępności:

Jak widać, macOS dzieli te ustawienia na poszczególne zmysły, które dane opcje mają wspierać. Stąd w kategorii wzroku mamy m.in. czytnik ekranu (VoiceOver), ale też ustawienia wyświetlacza czy animacji ruchowych, w słuchu – ustawienia dźwięku itd. Każda z tych opcji w menu posiada konkretne ustawienia, np. odnośnie animacji ruchowych:

System od Apple pozwala na dostosowanie większości aspektów systemu, np. wyłączając autoodtwarzanie ruchomych obrazków (GIF-ów). I choć na początku ogrom opcji może przytłaczać, to sam fakt ich istnienia jest jak najbardziej pozytywny. W końcu jedne z najbardziej dostępnych rozwiązań to te, które można najbardziej dostosować pod siebie!

Windows również posiada dość rozbudowane opcje dostępności. Podobnie jak macOS udostępnia czytnik ekranowy, Narratora. W przypadku jednak tego systemu nie zdobył on nigdy większej popularności. Od lat na tej platformie królują JAWS (płatny) oraz NVDA (darmowy). Oprócz czytnika Windows oferuje choćby lupę ekranową (do powiększania fragmentów ekranu) czy tryb wysokiego kontrastu.

Systemy mobilne także dostarczają technologii asystujących. Zarówno Android, jak i iOS, mają wbudowane czytniki ekranowe – odpowiednio TalkBack i VoiceOver. Mają także choćby opcję ograniczania animacji ruchowych. Także sporo linuksowych dystrybucji ma ustawienia dostępności, np. LInux Mint pozwala włączyć tryb wysokiego kontrastu i ma wbudowany czytnik ekranu (Orcę).

Innymi słowy: systemy operacyjne próbują dostarczyć niezbędnych narzędzi do tego, by mogło z nich korzystać jak najwięcej osób, w tym osoby z niepełnosprawnościami.

System a przeglądarka

Jak zatem taka systemowa technologia asystująca przekłada się na przeglądarkę? To zależy. Wraz z rozwojem technologii sieciowych, osoby tworzące strony WWW dostały możliwość dowiedzenia się nieco więcej o systemie operacyjnym, na którym uruchomiona jest przeglądarka. Najczęściej dzięki nowym media queries w CSS-ie. Wśród nich wymienić można:

• prefers-reduced-motion – informujące o ustawieniach dotyczących ograniczenia animacji ruchowych,
• forced-colors – informujące o trybie wymuszonych kolorów, czyli ograniczeniu palety dostępnych kolorów, jak w przypadku Windowsowego trybu wysokiego kontrastu,
• prefers-color-scheme – informujące o preferencjach osoby użytkowniczej co do doboru schematu kolorystycznego; inaczej mówiąc: czy woli jasny, czy ciemny motyw.

Część z systemowych ułatwień dostępu może być jednak “zakamuflowana”. Dobrym przykładem są tu różnego rodzaju powiększenia. Działają one trochę jak zmniejszenie rozdzielczości: poszczególne elementy robią się większe, przez co są bardziej czytelne. Równocześnie jednak ogranicza to liczbę elementów widocznych w danej chwili na ekranie. Przeglądarka często interpretuje to jako mniejszy viewport. Co też dobrze pokazuje, jak zawodne jest opieranie responsywności na założeniu mały ekran = urządzenie mobilne.

Jeszcze inne technologie asystujące są całkowicie przezroczyste dla przeglądarki, jak np. czytniki ekranu. Nie ma żadnego sposobu, aby dowiedzieć się, że osoba odwiedzająca stronę używa czytnika ekranu. I to akurat dobrze. Zwłaszcza, że stworzenie strony z zachowaniem standardów sieciowych i dobrych praktyk dostępności jest w większości przypadków wystarczające, by strona ta działała poprawnie we wszystkich popularnych czytnikach ekranu. Innymi słowy: wystarczy dobrze wykonywać swoją pracę – jakkolwiek brutalnie by to nie brzmiało.

Podsumowując: przeglądarka i system to para zaufanych przyjaciół, która niektóre sekrety zostawia wyłącznie dla siebie. Ale to, czym się jednak z nami dzielą, powinno wystarczyć do stworzenia dostępnej, przyjaznej strony WWW.

Powiadamianie o zmianach na stronie

Czasy całkowicie statycznych stron skończyły się eony temu. Obecnie bardzo często zachodzi potrzeba dynamicznej zmiany treści na stronie, np. w aktualizowanej na żywo relacji z meczu czy w odpowiedzi na akcję osoby użytkowniczej. Osoby, które nie korzystają z technologii asystującej, najczęściej są w stanie taką zmianę zauważyć (strona się wizualnie zmienia). Niemniej osobom korzystającym z technologii asystującej (a zwłaszcza czytników ekranu) taka zmiana może umknąć. Wypada więc w jakiś sposób je o niej poinformować.

Jednym ze sposobów są tzw. live regions (żywe regiony, regiony zmieniające się na żywo). Gdy oznaczy się element na stronie przy pomocy atrybutu [aria-live], wszelkie zmiay w jego zawartości będą odczytywane osobie korzystającej z czytnika ekranu. Dodatkowo, przy pomocy wartości tego atrybutu, możemy określić, czy czytanie ma być “uprzejme” (polite), czy “asertywne” (assertive). To pierwsze poczeka, aż osoba skończy wykonywać aktualną czynność (np. czytać akapit tekstu) i dopiero przeczyta komunikat. To drugie przerwie aktualną czynność i komunikat zostanie przeczytany natychmiast. Dodatkowo, przy pomocy atrybutu [aria-atomic] można określić, czy za każdym razem ma być odczytywana cała zawartość elementu z [aria-live], czy tylko jej zmieniona część.

Warto też zauważyć, że istnieją role, które odpowiadają wartościom atrybutu [aria-live]. Elementy z atrybutem [role=status] będą czytane uprzejmie, natomiast elementy z atrybutem [role=alert] – asertywnie.

Niemniej żywe regiony mają jedną, zasadniczą wadę: powiadamiają czytnik ekranu tylko, gdy ich zawartość się zmieni. Nie da się po prostu wstawić elementu z komunikatem na stronę. Trzeba najpierw wstawić pusty element, a dopiero potem dodać do niego treść komunikatu. To sprawia, że całe API zaczyna być mocno upierdliwe w użyciu. Zwykle kończy się na tym, że na stronie istnieje sobie pusty element z atrybutem [aria-live], a wokół niego istnieje całe API, którego zadaniem jest dodawać i usuwać komunikaty. A jeśli robimy większą aplikację, w której komunikatów może być sporo i mogą się pojawiać często, to de facto musimy zrobić cały mechanizm ich kolejkowania. Tak to działa np. w CKEditorze 5. Strasznie dużo roboty jak na coś, co powinno być proste.

Nowy, wygodniejszy sposób

Na całe szczęście, Edge zaproponował jakiś czas temu nowe API, ariaNotify(). To metoda, przypięta do elementów HTML, która pozwala na wysłanie komunikatu do czytnika ekranu:

document.ariaNotify( 'Jakiś komunikat' );

Dzięki drugiemu argumentowi można też określić priorytet komunikatu:

document.ariaNotify( 'Komunikat'. {
	priority: 'normal' // 1
} );

document.ariaNotify( 'Komunikat'. {
	priority: 'high' // 2
} );

Normalny priorytet (1) odpowiada czytaniu uprzejmemu, podczas gdy wysoki (2) – asertywnemu.

Nowe API rozwiązuje też problem kolejkowania komunikatów. Nie trzeba się już dłużej samemu tym zajmować, robi to za nas przeglądarka.

Gdzie jest więc haczyk? To wciąż mocno eksperymentalna technologia, która nawet nie ma specyfikacji. Na ten moment jest tylko propozycja ze strony Edge’a. Samo API na ten moment działa wyłącznie w Chrome i Edge – a i tam ma problemy poza Windowsem. Na razie zatem trzeba dalej męczyć się z żywymi regionami.

Bo dostępność nigdy nie może być za prosta, prawda?

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 standardzie WCAG. I to też jak najbardziej prawda. Problem polega na tym, że nie cała prawda.

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 wprowadzenie do tego standardu zaznacza, że

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.

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.

Cofnijmy się nieco i spójrzmy, jak w ogóle definiowana jest dostępność. Bardzo ładną definicję znaleźć można na angielskiej Wiki:

Web accessibility, or eAccessibility,[1] is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed.

[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.]

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 Sieć to nie tylko szerokopasmowe łącza. W chwili, gdy każdy bajt słono kosztuje, 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. Web Vitals).

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.

W praktyce zmienia to niewiele, bo o tym, że ten algorytm nie działa, wiedziano od bardzo dawna. 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 tworzenie odpowiedniej hierarchii.

Jedyna faktyczna zmiana względem najlepszych praktyk ustalonych lata temu to zmiana przeznaczenia elementu hgroup. 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 hgroup służy do grupowania nagłówków wraz z ich podtytułami lub tytułami alternatywnymi, np:

<hgroup>
	<h1>HTML</h1>
	<p>Living standard</p>
</hgroup>

Warto zwrócić uwagę, że nawet przy wykorzystaniu hgroup podtytuł jest akapitem.

I to w sumie tyle. 12 lat czekania na w dużej mierze formalną zmianę w specyfikacji.

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!): Accessibility, availability and Progressive Enhancement. Miłego czytania!

Animacja, czyli słoń w składzie porcelany

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 na poziomie systemu użytkownik ustawił ograniczenie ruchu. Strony internetowe mogą wykrywać tego typu ustawienie przy pomocy media query prefers-reduced-motion. To w połączeniu z funkcją matchMedia pozwala na choćby wczytanie alternatywnej, mniej wodotryskowej wersji witryny, gdy okaże się, ze użytkownik chce bardziej statyczną stronę.

Taka alternatywna wersja nie musi być jakoś mocno odmienna. Strona wciąż może wyglądać bardzo podobnie po usunięciu animacji. Weźmy taką stronę Active Theory. 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ę.

Ż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 porównywalnego doświadczenia (korzystania z takiej samej strony, tyle że bez animacji).

Accessible First

Niemniej myślę, że istnieje lepszy sposób, niż przygotowywanie alternatywnej, bardziej dostępnej wersji – podejście, które można by nazwać Accessible First (z ang. dostępność jako pierwsza). Tak, jak najczęściej zaleca się, by responsywność przygotowywać w podejściu [mobile/content first](mobile/content first), tak być może czas zalecać, by strony tak ogólnie tworzyło się w podejściu priorytetyzującym dostępność.

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 standardem WCAG. 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 poszczególne nowe elementy strony dodawane są w zależności od możliwości urządzenia użytkownika. A w obydwu przypadkach bardzo podobnie do Progressive Enhancement. Cebula w cebuli w cebuli. I z tego cebulowego gulaszu wychodzi pyszne danie. Warte w sumie swojej własnej książki kucharskiej.

Problem semantyki

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.

Nie istnieje coś takiego, jak elementy semantyczne. Każdy element w HTML-u jest semantyczny, bo ma określone znaczenie. Nawet ten nieszczęsny div jest semantyczny, bo specyfikacja opisuje jego znaczenie:

The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. It can also be used in a dl element, wrapping groups of dt and dd elements.

[Element div nie ma żadnego specjalnego znaczenia. Reprezentuje swoje dzieci. Może być użyty wraz z atrybutami class, lang i title, żeby przekazywać znaczenie (semantykę) typową dla grupy następujących po sobie elementów. Może być też użyty wewnątrz elementu dl, otaczając grupy elementów dt i dd.]

Widzimy tutaj, że definicja znaczenia (semantyki) diva składa się tak naprawdę z dwóch części:

• określenia samego znaczenia,
• zasugerowania sposobów rozszerzenia semantyki diva.

Jeśli chodzi o samo znaczenie, to… div 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 diva konkretnego znaczenia. I tutaj pojawia się kolejny problem: ta dodatkowa semantyka nie jest przeznaczona dla użytkowników.

Podsumowując: div 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.

Spróbujmy jednak połapać się w tym galimatiasie!

Definicja semantyki

Semantyka elementu to jego znaczenie.

I to w sumie tyle. Mówiąc o semantycznym HTML-u, mówimy o HTML-u, który znaczy to, co chcemy, żeby znaczył. Zatem dobieramy odpowiednie elementy. Jeśli coś jest nagłówkiem, używamy h1–h6, jeśli coś jest linkiem, używamy a, jeśli coś jest po prostu kontenerem na inne elementy, używamy div itd.

Dla celów praktycznych można jednak tę definicję nieco rozszerzyć: semantyka elementu to jego znaczenie opisane w specyfikacji. Innymi słowy: źródłem semantyki jest specyfikacja HTML. Zresztą jest to napisane w niej wprost:

Elements, attributes, and attribute values in HTML are defined (by this specification) to have certain meanings (semantics). For example, the ol element represents an ordered list, and the lang attribute represents the language of the content.

[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 ol reprezentuje listę uporządkowaną, a atrybut [lang] reprezentuje język treści.]

Specyfikacja też wyraźnie zaznacza, w którym miejscu znajduje się dokładny opis znaczenia konkretnego elementu:

This is then followed by a description of what the element represents, along with any additional normative conformance criteria that may apply to authors and implementations. Examples are sometimes also included.

[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.]

Te definicje elementów znajdują się w rozdziale 4. specyfikacji, The elements of HTML (Elementy HTML-a). Jak widać, w tym rozdziale mamy zarówno elementy o mocno określonym znaczeniu (nagłówki, data, details), jak i te, które specjalnie nic nie znaczą (div, span, template).

Stąd też div ma znaczenie – ponieważ jego opis znajduje się w specyfikacji HTML. Żeby wiedzieć, że div 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 nic nie robi. Dokładnie tak samo jest z divem.

Problemy językoznawcze

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. W angielskim semantyka oznacza zarówno naukę o znaczeniu slów, jak i samo ich znaczenie. W polskim semantyka oznacza już tylko naukę.

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 znaczenie 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ął…

Trzy poziomy semantyki

Rozprawiliśmy się już z pierwszą częścią definicji elementu div. Zostaje jednak jeszcze druga, w której to nic nieznaczący div zdobywa znaczenie, ale wciąż nic nie znaczy… Nielogiczne? Bynajmniej, ponieważ trzeba zauważyć, że elementy mają tak naprawdę trzy poziomy semantyki (znaczenia):

• formalny, opisany w specyfikacji i przeznaczony dla użytkowników,
• formalny, którego infrastruktura jest opisana w specyfikacjach, a który przeznaczony jest dla przeglądarek i innych programów,
• nieformalny, oparty na konwencjach częściowo opisanych w specyfikacji i przeznaczony dla webdeveloperów.

Dla użytkowników

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.

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. details. Znaczenie elementów jest wprost powiązane z tym, jak się zachowują i tym, jak użytkownicy oczekują, że dane elementy będą się zachowywać. Dlatego nie warto psuć tego, co Po Prostu Działa™.

Dla przeglądarek i innych programów

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. reader view (ang. tryb poprawionej czytelności), 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ść? Przy pomocy odpowiednich elementów, takich jak main czy article.

Niemniej czasami trzeba przekazać programom dodatkowe informacje. Można to zrobić przy pomocy atrybutów, takich jak [class], [data-*] czy [lang], elementów, takich jak link czy meta, albo całych dodatkowych mechanizmów, takich jak mikrodane, JSON-LD, RDFa, ARIA czy manifest aplikacji sieciowej. 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.

Dla webdeveloperów

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 ul.menu od razu mówi, do czego służy dany element, podczas gdy ul pozwala nam dowiedzieć się jedynie tego, że to jakaś 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.

Do tego poziomu semantyki zaliczyć też trzeba wszelkiego rodzaju metodyki, takie jak choćby BEM. Z perspektywy HTML-a warstwa BEM jest właśnie tym: dodatkowym znaczeniem, przeznaczonym dla webdeveloperów.

Rozszerzanie semantyki

Opis poszczególnych poziomów semantyki pokazuje, że podstawowe znaczenie każdego elementu można rozszerzać (a wręcz, do pewnego stopnia, zmienić) na wiele różnych sposobów, co daje wiele różnych rezultatów. Weźmy na tapet nagłówek h2:

<h2>Comandeer</h2>

Ot, zwykły nagłówek. Ale dodajmy do niego odpowiednią klasę, żeby zaznaczyć, że to nagłówek sekcji:

<h2 class="section__heading">Comandeer</h2>

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ę):

<section class="section" vocab="http://schema.org" typeof="Person">
	<h2 class="section__heading" property="name">Comandeer</h2>
</section>

Tym sposobem nasz nagłówek przekazuje informacje z wszystkich wymienionych wyżej poziomów semantyki:

• na najbardziej podstawowym poziomie to wciąż nagłówek, dzięki czemu użytkownik wie, że zaczyna się nowa sekcja,
• dzięki RDFa wyszukiwarki internetowe i inne programy wiedzą, że to sekcja o osobie, która nazywa się “Comandeer”,
• dzięki klasie webdeveloperzy wiedzą, że to nagłówek sekcji.

W podobny sposób można rozszerzać znaczenie praktycznie każdego elementu HTML.

Semantyka a dostępność

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 artykule o nagłówkach czy artykule o przyciskach w React Native.

W skrócie: każdy element HTML jest prezentowany w określony sposób w drzewku dostępności. To, jak dokładnie, wynika z jego domyślnej roli ARIA. Bardzo prosto to pokazać na przykładzie np. nagłówka i podrabianego nagłówka:

<style>
.heading {
    all: unset;
	display: block;
	font-size: 2em;
	line-height: 2;
	font-weight: bold;
}
</style>
<h1 class="heading">Nagłówek</h1>
<span class="heading">Nagłówek</span>

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:

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.

Teoretycznie można to naprawić nadając elementowi span odpowiednią rolę przy pomocy ARIA ([role=heading]), 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 span[role=heading] tak samo jak h1? Nie bez powodu pierwsza zasada ARIA brzmi: nie używaj ARIA, jeśli istnieje natywny element HTML robiący daną rzecz.

Semantyka a SEO

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:

Tego typu gwiazdki można dodać przy pomocy odpowiedniego typu danych Schema.org. 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 Web 3.0.

Mam nadzieję, że ten krótki 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 divów…

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.

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): Practical web accessibility guide oraz Web accessibility testing - DIY!. Myślę, że ten drugi jest nawet ciekawszy, bo jest luźno oparty na tym, w jaki sposób testuję strony na potrzeby WebKrytyka. Miłego czytania!

Both true:

1. Most devs should just use a <button>, not <a>, <div>, <span>, etc.

2. React Native Web’s div buttons are better buttons than <button>

• Still keyboard and AT accessible
• Better touch event handling
• Populate e.relatedTarget unlike <button>
• Easier to style

I think a lot of HTML/CSS experts are being overly critical of React because they see the output of the new https://twitter.com and think they know there are fundamental flaws when they see the div soup.
That div soup is accessible.

<h2/>
<div role="heading" aria-level="2"/>

<button/>
<div {...allTheRightAttributesAndEventHandlers}/>

These are identical as far as accessibility is concerned when implemented correctly.

If you’re critical of this, you don’t actually care about a11y, you care about your niche

So yeah … just use a button, or a RNW button, but not your own div button.

[Obydwa stwierdzenia są prawdziwe:

1. Większość devów powinna używać <button> zamiast <a>, <div>, <span> itd.
2. Przycisk z React Native Web oparty o div jest lepszy niż <button>:
3. Wciąż dostępny z poziomu klawiatury i technologii asystującej.
4. Lepsza obsługa dotyku.
5. Zawiera e.relatedTarget w przeciwieństwie do <button>.
6. Łatwiejszy do stylowania.

Myślę, że wielu ekspertów HTML/CSS jest zbytnio krytycznych względem Reacta, ponieważ widzą oni kod nowego Twittera i myślą, że wiedzą, żę są tam podstawowe błędy, gdy widzą divową zupę.

Ta divowa zupa jest dostępna.

<h2/>
<div role="heading" aria-level="2"/>

<button/>
<div {...allTheRightAttributesAndEventHandlers}/

Te kody są identyczne, jeśli bierzemy pod uwagę poprawnie zaimplementowaną dostępność.

Jeśli jesteś krytyczny wobec tego, tak naprawdę nie dbasz o dostępność, ale o własną niszę.

Więc tak… po prostu użyj przycisku albo przycisku z RNW, ale nie swojego własnego przycisku na div.]

Takie podejście jest nie tyle niewłaściwe, co szkodliwe. Postaram się pokrótce przybliżyć, czemu tak uważam.

Informacje o natywnym przycisku są niepełne

Przyciski po kliknięciu mają własność event.relatedTarget:

Jeśli ponawigujemy po przykładzie klawiaturą (Tab oraz Shift+Tab), zauważymy, że wyświetla się poprawny identyfikator pola, z którego przeszliśmy do przycisku. Co prawda Ryan uściśla następnie, że chodzi o Firefoksa i Safari, 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 – wbrew informacji na MDN . Być może zmienił się sposób obsługi focusowania na poziomie całego systemu. To równocześnie oznaczałoby, że problem nieprzekazywania event.relatedTarget przez przyciski jest już rozwiązany.

Inna rzecz, że po raz kolejny dostrzec tu można problem “makizacji” developmentu i zamykania go w bańce. 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, mający 61% rynku, 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 button 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.

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 własności all z wartością unset. A jeśli musimy wspierać IE i Edge’a lub natrafimy na (wciąż, niestety, istniejące) bugi z all: unset, istnieją tradycyjne sposoby.

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.

Mam także pewną wątpliwość co do źródła danych. Ryan przy omawianiu zgodności ARIA-owych zamienników z czytnikami ekranowymi powołuje się na statystyki obsługi ARIA przez czytniki ekranowe. 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.

Dostępność to nie tylko czytniki ekranowe

Gdy weźmie się pod uwagę wyłącznie czytniki ekranowe, można dojść do wniosku, że faktycznie – div[role=heading][aria-level=2] jest równoznaczne z h2. Niemniej dostępność nie kończy się na czytnikach ekranowych – dostępność dotyczy absolutnie każdego. 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 div.

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 własnych stylów CSS. Niestosowanie semantycznych znaczników lub używanie stylów inline (co zresztą RNW też robi, sądząc po demo) 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.

Problem ten dotyczy nie tylko niestandardowych arkuszy stylów użytkownika, ale także wbudowanego w Windows trybu wysokiego kontrastu. Usuwa on bowiem wszystkie style nadane elementom przez developera i na podstawie domyślnych arkuszy stylów przeglądarki oraz semantyki poszczególnych elementów wyświetla wszystkie elementy. W tym momencie przyciski oparte na div 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ć.

Przycisk na div przestaje być przyciskiem w chwili, gdy przestaje wyglądać. Z kolei button 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 div nigdy nie stanie się tym samym co button. W wielu przypadkach może się sprawdzić, ale w wielu – spektakularnie się wyglebi.

Dodatkowo fakt, że część stylów jest umieszczana bezpośrednio w znaczniku, w tym te dotyczące animacji, może sprawiać problemy, gdy pojawi się potrzeba wyłączenia animacji. W przypadku całkowitego rozdziału elementu od prezentacji taka zmiana jest bardzo prosta do wprowadzenia.

Divowy przycisk nie działa bez JS

I zanim ktoś zdąży powiedzieć, że “przecież nikt nie wyłącza dzisiaj JS”: JS może nie zadziałać. Ba, wystarczy zadyszka naszego CDN-a, żeby zachowanie dla naszego przycisku wczytało się kilka sekund za późno. 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 button i podejścia Progressive Enhancement można tak pokombinować z SSR, ż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 da się zrobić nowoczesną stronę WWW, która odpala się na pierwszej przeglądarce internetowej w historii, to da się naprawdę dużo.

Divowy przycisk łamie pierwszą zasadę ARIA

Pierwsza zasada ARIA 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.

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.

HTML to nie tylko dostępność

Stwierdzić, że div[role=button] to to samo co button, 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 HTML stał się formatem kompilacji. To samo w sobie nie jest złe, ale równocześnie pokazuje problem: współczesne aplikacje nie mają semantycznego HTML-a, bo ich twórcy nie muszą go znać. W końcu z punktu widzenia developera RNW przycisk to po prostu <Button />. Nikogo nie interesuje, że do przeglądarki trafia ostatecznie taki potwór:

<div role="button" data-focusable="true" tabindex="0" class="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" style="background-color: rgb(23, 191, 99);">
    <div dir="auto" class="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">Press me</div>
</div>

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, wycinając wszelkie niepotrzebne znaki z HTML-a, taka rozrzutność jest po prostu niezrozumiała.

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 HTML jest uniwersalnym językiem wymiany informacji – popularniejszym nawet od JSON. To język, na bazie którego zbudowano WWW. To język, na bazie którego powoli powstaje Semantyczna Sieć. 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 RDF, RDFa, mikrodanych, Schema.org, mikroformatów, JSON-LD 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 znaczącej treści jest niemal niemożliwa. A to oznacza, że z HTML-a pozostaje tylko T – tekst odarty z własnego znaczenia.

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.

Ale co się stało?

Dużo. Po pierwsze wspomniany w poprzednim wpisie PR został włączony do specyfikacji HTML LS. To zdecydowanie upodobniło definicję main w HTML LS do tej w HTML 5.x. Na tym się jednak nie skończyło. Anne van Kesteren przygotował bowiem drugi PR, który został zmerge’owany dzisiaj (23 stycznia 2018), a który to usuwał ostatnią poważną różnicę pomiędzy definicjami: możliwość używania więcej niż jednego widocznego elementu main. Tym samym słynne issue #100 zostało ostatecznie zamknięte. Obydwie definicje, choć brzmiały inaczej, mówiły już to samo. Ba, po zmianach poczynionych przez WHATWG wersja definicji main w HTML LS stała się wręcz lepsza od tej w HTML 5.x. Dlatego też niemal od razu W3C zdobyło się na gest i postanowiło zmienić swoją definicję na tą z HTML LS. I zrobiło to, raptem kilka godzin później.

Tym samym największa różnica pomiędzy HTML LS i HTML 5.x przestała istnieć.

Treść porozumienia

Główne zmiany w stosunku do starszej wersji z HTML 5.x to zamiana sformułowania main contents na dominant contents a także wprowadzenie pojęcia “hierarchicznie poprawnego elementu main” (ang. hierarchically correct main element).

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

Druga zmiana ogranicza kontekst występowania main. Wcześniej HTML 5.x pozwalało umieszczać main w wielu dziwnych miejscach, np. w section. Obecna wersja wymusza, żeby main było bezpośrednio w body, ewentualnie div, form bez dostępnej nazwy (z powodu wymogów ASP .NET) lub custom elemencie. Możliwe jest też umieszczenie main bezpośrednio w html, jeśli tworzona przez nas strona nie posiada ani head, ani body (co jest dozwolone przez specyfikację).

I co teraz?

Nic. Choć definicje w końcu 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 main. 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 prawie 3 lata.

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.