Dostępnik o Adapt, czyli jak strona może się sama dostosowywać

Magda Tofil znowu mnie zainspirowała podczas spotkania online. Wspomniałem o specyfikacji, która pozwala na wyświetlanie na stronie internetowej symbole zamiast słów. Zatem W3C-Adapt.

Wyobraź sobie, że odwiedzasz stronę banku i zamiast skomplikowanych numerów kont widzisz piktogramy, które rozumiesz. Albo że przycisk “Wyślij” wyświetla się z ikonką, którą znasz z programu do komunikacji wspomagającej, bo jej używasz od lat. Albo że strona sama upraszcza język, bo wie, że tego potrzebujesz — nie dlatego, że ktoś napisał dla ciebie osobną, “łatwą” wersję, ale dlatego że przeglądarka odczytała semantykę strony i zadziałała po cichu, w tle.

To jest właśnie obietnica WAI-Adapt.

Dostępność to nie personalizacja

WCAG mówi: zrób stronę tak, żeby każdy mógł z niej skorzystać. To ważne, ale ma pewien fundamentalny problem. Różni użytkownicy mają sprzeczne potrzeby.

Ktoś z dyskalkulią potrzebuje, żebyś zamienił liczby na słowa. Ktoś inny z autyzmem potrzebuje liczb — bo słowa są dla niego zbyt wieloznaczne. Osoba słabowidząca potrzebuje dużej czcionki, ale osoba z dysleksją może potrzebować konkretnego kroju, konkretnego odstępu między literami. Ktoś używa symboli AAC (alternatywnej i rozszerzonej komunikacji) ze swojego ulubionego zestawu, z którego korzystał przez lata.

Nie możesz zrobić jednej strony, która spełni te wymagania jednocześnie. Przynajmniej nie bez personalizacji po stronie użytkownika. I właśnie tu wchodzi WAI-Adapt.

Czym jest WAI-Adapt

WAI-Adapt to seria specyfikacji technicznych opracowywana przez W3C, która pozwala autorom stron dodawać do kodu HTML dodatkową semantykę. Niewidoczną dla użytkownika, ale czytelną dla narzędzi — rozszerzeń przeglądarki, technologii asystujących, aplikacji adaptacyjnych.

Idea jest prosta: autor strony oznacza elementy atrybutami mówiącymi, czym dany element jest z punktu widzenia użytkownika. A potem to oprogramowanie użytkownika — nie autor — decyduje, jak to wyświetlić.

Aktualnie WAI-Adapt składa się z czterech modułów:

· Content Module — atrybuty dla kontrolek, przycisków, linków i treści ogólnej (szkic roboczy)

· Symbols Module — mapowanie tekstu na symbole AAC (proponowana rekomendacja — najbardziej dojrzały)

· Help and Support Module — atrybuty dla elementów pomocy i wsparcia (szkic roboczy)

· Tools Module — atrybuty dla narzędzi i funkcji strony (szkic roboczy)

Dla kogo to jest ważne i dlaczego

Zanim przejdę do kodu, chwila o ludziach. Bo bez tego WAI-Adapt brzmi jak kolejna specyfikacja dla specyfikacji.

Użytkownicy AAC to osoby, które komunikują się nie słowami, ale symbolami graficznymi. Mówię o dzieciach i dorosłych z mózgowym porażeniem dziecięcym, z autyzmem, z afazją po udarze. Dla nich internet jest w zasadzie obcojęzyczny — pełen tekstu, który nie ma dla nich takiego znaczenia jak zestaw symboli, do którego byli latami trenowani.

Problem w tym, że istnieje kilkanaście konkurencyjnych zestawów symboli AAC: PCS, Widgit, BLISS, Arasaac i inne. Każdy użytkownik zna swój zestaw. Dodanie symboli na stronie przez autora nic nie daje, bo autor nie wie, którego zestawu używa konkretna osoba.

WAI-Adapt rozwiązuje to elegancko: autor oznacza element identyfikatorem konceptu z rejestru W3C. Rozszerzenie przeglądarki wie, jakiego zestawu symboli używa ten użytkownik, i podmienia tekst na odpowiedni symbol. Automatycznie, niezależnie od tego, jaką stronę odwiedzasz.

Osoby z dyskalkulią — trudnością w rozumieniu liczb — mogą potrzebować, żeby data “14 marca” nie wyświetlała się jako “14.03”, tylko jako słowa. Albo żeby cena produktu była przedstawiona inaczej niż ciąg cyfr.

Osoby z trudnościami poznawczymi mogą potrzebować uproszczonego języka, ukrycia zbędnych elementów strony, dodatkowych wyjaśnień przy skomplikowanych terminach.

Dla wszystkich tych grup dzisiejszy internet jest zaprojektowany w sposób, który ich wyklucza — nie ze złej woli, ale dlatego że autor strony po prostu nie może wiedzieć, czego potrzebuje każdy z nich z osobna.

Jak to wygląda w kodzie

WAI-Adapt dodaje nowe atrybuty HTML. Oto kilka przykładów, żeby to zobaczyć:

Moduł Symbols — mapowanie tekstu na koncepty z rejestru:

<label for=”home” adapt-symbol=”14885”>Twój adres zamieszkania</label>
<input type=”text” id=”home” autocomplete=”street-address”>

Liczba 14885 to identyfikator konceptu “Dom/Miejsce zamieszkania” w rejestrze W3C. Rozszerzenie użytkownika wie, że to “Dom” i może wyświetlić odpowiedni symbol z zestawu, którego używa ten konkretny człowiek.

Moduł Content — oznaczanie akcji przycisków i linków:

<button adapt-action=”send”>Wyślij wiadomość</button>
<a href=”/kontakt” adapt-destination=”contact”>Napisz do nas</a>

Atrybut adapt-action mówi, co przycisk robi (wysyła). adapt-destination mówi, dokąd prowadzi link (do kontaktu). Narzędzie użytkownika może dodać znane ikony, podmienić tekst na znany termin, albo wyróżnić “wyślij” czerwonym kolorem dla kogoś, kto chce być ostrzeżony przed nieodwracalnymi akcjami.

Moduł Help and Support — atrybuty pomocowe:

<p adapt-easylang=”Kliknij tutaj, żeby zapłacić”>
Zrealizuj transakcję płatniczą przy użyciu karty debetowej lub kredytowej
</p>

Wartość easylang zawiera uproszczoną wersję treści, którą rozszerzenie może pokazać zamiast oryginału, jeśli użytkownik tego potrzebuje.

Które przeglądarki to obsługują

Tutaj muszę być szczery. Żadna główna przeglądarka — Chrome, Firefox, Safari, Edge — nie obsługuje WAI-Adapt natywnie. Specyfikacja nie jest wbudowana w silniki przeglądarek i w najbliższej przyszłości raczej nie będzie.

Model działania, który zakłada WAI-Adapt, to rozszerzenia przeglądarki, a nie wsparcie wbudowane. I tu przykład z życia istnieje: projekt Easy Reading — rozszerzenie dla Firefox, które korzysta między innymi z założeń WAI-Adapt, by dostarczać spersonalizowane wsparcie dla użytkowników z trudnościami poznawczymi. Powstał jako projekt badawczy, ale pokazał, że koncepcja jest wykonalna.

W3C prezentowała demo na TPAC 2020: prosta wtyczka przeglądarkowa, która po pobraniu i skonfigurowaniu preferencji użytkownika (jakiego zestawu symboli używasz, jaki poziom uproszczenia języka preferujesz) automatycznie adaptowała strony zawierające atrybuty WAI-Adapt. Efekt — strona wyglądała zupełnie inaczej dla różnych użytkowników, mimo że serwer wysyłał dokładnie ten sam HTML.

Konstruktywna krytyka: co stoi na drodze

WAI-Adapt to naprawdę ciekawa koncepcja. I byłoby nieuczciwe z mojej strony, gdybym nie powiedział, dlaczego po ponad dziesięciu latach prac specyfikacja jest ciągle w fazie Working Draft.

Problem “jajko czy kura” — Deweloperzy nie dodają atrybutów WAI-Adapt, bo nie ma narzędzi, które by je czytały. A narzędzia nie powstają, bo strony nie mają tych atrybutów. To klasyczna pułapka ekosystemów: każda strona ze specyfikacji jest logicznie kompletna, ale razem nie domykają koła napędowego.

Brak nacisku prawnego — WCAG jest w przepisach. WAI-Adapt nie jest i prawdopodobnie długo nie będzie. Dla wielu organizacji to oznacza: “miłe marzenie, ale nie nasz priorytet”. Bez obowiązku prawnego lub wyraźnego nacisku rynkowego adopcja specyfikacji jest ślamazarna.

Złożoność rejestru — Moduł Symbols opiera się na rejestrze W3C z numerami konceptów. Ktoś musi ten rejestr utrzymywać, rozwijać, tłumaczyć na różne języki i konteksty kulturowe. To niebagatelna praca infrastrukturalna, która wymaga ciągłego finansowania i zaangażowania społeczności.

Nakład pracy autora — Żeby WAI-Adapt działał, autorzy stron muszą dodać nowe atrybuty. To dodatkowa praca przy każdym formularzu, każdym przycisku, każdym linku. Przy braku narzędzi automatyzujących ten proces (np. integracji z CMS-ami) to jest realna bariera.

Ale — i to ważne — te problemy nie dyskwalifikują specyfikacji. One tylko opisują wyzwania adopcji, z którymi borykają się prawie wszystkie standardy dostępności w początkowej fazie. WCAG też przez długi czas był “miłym pomysłem”, a różne kraje i korporacje tworzyły własne specyfikacje.

Że warto pracować nad WAI-Adapt, przekonuje mnie jeden argument: to jedyne podejście na poziomie standardów, które serio traktuje fakt, że użytkownicy z niepełnosprawnościami poznawczymi mają sprzeczne, głęboko zindywidualizowane potrzeby. Każde inne podejście — pisanie “wersji łatwej do czytania”, dodawanie symboli na stronie — jest z definicji niedoskonałe, bo zakłada z góry, którego użytkownika obsługujesz. WAI-Adapt zakłada, że tego nie wiesz, i daje to rozwiązać narzędziom użytkownika.

Co z tym robić już teraz

Jeśli budujesz strony lub aplikacje, WAI-Adapt nie jest jeszcze czymś, co musisz wdrożyć. Ale jest kilka rzeczy, które możesz już teraz zrobić:

· Śledź specyfikację — szczególnie Symbols Module, który jest najbliżej finalizacji jako Candidate Recommendation.

· Zadbaj o podstawy — semantyczny HTML, dobre etykiety formularzy, opisowe teksty przycisków to fundament, bez którego WAI-Adapt i tak nie zadziała.

· Zainteresuj się rejestrem konceptów W3C — jeśli budujesz rozbudowane formularze, już teraz możesz mapować ich pola na koncepty i dodawać atrybuty adapt-symbol jako “future-proofing”.

· Czytaj o projekcie Easy Reading — to najlepszy działający przykład, jak ta technologia może wyglądać w praktyce.

· Zacznij od małych kroków. Dodaj te atrybuty do powtarzalnych elementów, na przykład przycisków w formularzach, dat, informacji kontaktowych. Nie wszystko od razu, ale tak na spokojnie.

WAI-Adapt to nie rewolucja jutro. Ale może być ważnym elementem dostępności za kilka lat — jeśli ekosystem się domknie. Warto wiedzieć, że istnieje.

Jest jeszcze jedna ścieżka warta eksplorowania, czyli sztuczna inteligencja. Być może da się włączyć automatyzacje do procesu oznaczania elementów za pomocą atrybutów Adapt. Na poziomie projektów oraz na poziomie już wygenerowanych stron. No ale to temat na kiedyś.

Jeśli temat AI i dostępności Cię interesuje, zapraszam na mój blog: dostepnik.com.pl/post/ — piszę tam o tym, jak sztuczna inteligencja zmienia (i nie zmienia) świat dostępności cyfrowej.

Wieści o dostępności

Chcesz nauczyć się pisać dobry, semantyczny HTML? Wojtek Kutyla prowadzi kurs, który polecam bez zastrzeżeń. Solidna dawka wiedzy o tym, jak kod powinien wyglądać, żeby był dostępny od podstaw. Link afiliacyjny: Kurs semantycznego HTML – humanthing.works

☕ AutomaticA11y 2026 odbędzie się 21 maja 2026 roku w Szkole Głównej Handlowej w Warszawie. Pieniądze zebrane od 1 lutego do 30 kwietnia w całości przeznaczę na sfinansowanie tego wydarzenia. Jeśli chcesz wesprzeć konferencję — postaw mi kawę na buycoffee.to/dostepnik.

Przypominam też, że formularz zgłoszeniowy na AutomaticA11y 2026 będzie działał tylko do końca marca. Potem przejrzę zgłoszenia i otworzę go ponownie na początku maja, o ile będą jeszcze miejsca. Program dopiero powstaje, ale są już opisy prezentacji i stolików tematycznych. Mamy też pomysł na panel dyskusyjny, którego organizacją zajmuje się Ania Żórawska z Fundacji Kultury bez barier. Będzie transkrypcja na żywo i to robiona profesjonalnie, a nie po partyzancku, jak w zeszłym roku. Szczegóły organizacyjne będę przesyłał w połowie kwietnia do osób, które zgłosiły swój udział.

Uwaga: termin aktualizacji Deklaracji Dostępności upływa 31 marca. Jeśli prowadzisz stronę publiczną — sprawdź, czy twoja deklaracja jest aktualna. Ja jak zwykle polecam generator deklaracji dostępności, którego jestem współautorem. Czasu zostało naprawdę mało.

AI bez instrukcji nie dba o dostępność — Badanie opublikowane przez QualityLogic wykazało, że modele językowe domyślnie generują niedostępny kod. GPT 5.2 osiągnął 41% w testach dostępności bez żadnych wskazówek — i to był najlepszy wynik. Pozostałe modele uzyskały wyniki bliskie zeru. Ale jest dobra wiadomość: dodanie do promptu instrukcji “All output MUST be accessible” podniosło wyniki o 18 punktów procentowych. Morał: AI może pomagać w dostępności, ale samo z siebie nie będzie tego robić.

“Okiem niewidomego: To jak to jest z tym czatbotem?” — Niedawny wpis na kinaole.co bada, jak chatboty działają (albo nie działają) dla użytkowników czytników ekranu. Polecam, bo to jeden z tych tekstów, które dobrze pokazują przepaść między tym, co firmy komunikują o dostępności AI, a tym, co realnie przeżywają użytkownicy. Tu do przeczytania.

I to by było na tyle. Przed nami święta, więc moja i Twoja aktywność zapewne spadnie. Jednak świat idzie naprzód i trzeba trzymać rękę na pulsie. Na świecie dzieje się nadal wiele rzeczy, które mi się nie podobają. Zróbmy coś, żeby ten świat był lepszy, a przynajmniej dostępniejszy, niż teraz.