Obraz nagłówkowy bloga z atrybutem alt to problem rozwiązany. Diagram STEM — nie. Trzy właściwości obrazów naukowych podważają założenia leżące u podstaw alt, aria-label i modelu mowy czytnika ekranu.

Po pierwsze, gęstość informacji jest na tyle wysoka, że jedno zdanie jej nie udźwignie. Pierścień benzenowy to sześć atomów węgla, sześć atomów wodoru, naprzemienne wiązania podwójne, zdelokalizowany układ pi, płaska geometria i długość wiązania wynosząca 1,39 angstremów. Konwencja tekstu alternatywnego wymaga „krótkiego zastępczego opisu tekstowego“; benzen potrzebuje akapitu. Ściśnięcie tego do jednego zdania albo powoduje utratę informacji strukturalnej („cząsteczka benzenu“), albo generuje nieczytelny ciąg słów, który czytnik ekranu musi przeliterować z prędkością 180 słów na minutę.

Po drugie, relacje między elementami niosą tyle samo znaczenia co same elementy. Na schemacie sił strzałka biegnąca od prostopadłościanu do ściany nie jest ozdobą — to reakcja normalna, a jej kąt względem wektora grawitacji jest odpowiedzią na zadanie. Płaski opis nie jest w stanie zakodować treści „kąt między tymi dwiema strzałkami wynosi 90 stopni i dlatego zadanie się rozwiązuje“, ponieważ płaski opis nie ma struktury. SVG, stosowany uważnie, tę strukturę posiada.

Po trzecie, studenci kierunków STEM muszą móc nawigować po diagramie, a nie tylko go wysłuchać. Osoba ucząca się przez wykres funkcji sześciennej nie chce słuchać tekstu alternatywnego od początku do końca — chce wylądować na lokalnym maksimum, zapytać „jakie jest tu nachylenie“, a następnie przejść do punktu przegięcia. To inny model interakcji niż ten, z którym domyślnie dostarczane są czytniki ekranu. Jego zbudowanie wymaga obsługi klawiatury na poszczególnych węzłach SVG, drzewa treści opisanego przez ARIA oraz mechanizmu zastępczego dla stosów technologii wspomagających, które nie nadążają.

Niemal każdy opublikowany podręcznik STEM wciąż dostarcza diagramy jako PNG lub JPG. Obraz rastrowy jest nieprzezroczystą siatką pikseli: ma jeden punkt wejścia dla technologii wspomagających — atrybut alt — oraz jeden mechanizm zastępczy w postaci atrybutu longdesc, którego obsługę przeglądarki od dekady cicho wycofują. Wewnątrz obrazu nie ma żadnej struktury, którą czytnik ekranu mógłby zaadresować. Diagram jest czarną skrzynką z etykietą z przodu.

SVG odwraca ten model. Każdy kształt w dokumencie SVG jest węzłem DOM — adresowalnym, możliwym do sfokusowania i opatrzenia etykietą. Pierścień benzenowy wyrenderowany jako SVG ma sześć elementów circle dla atomów węgla, sześć elementów line dla wiązań i obejmujący je element g nadający całości nazwę. Każdy z tych węzłów może mieć atrybuty role, aria-label, aria-labelledby, aria-describedby i tabindex. Czytnik ekranu widzi drzewo dostępności złożone z nazwanych regionów zamiast pojedynczego nieprzezroczystego obiektu.

Minimalnie wymagany dostępny SVG niesie trzy elementy na swoim głównym elemencie svg: role=“img”, aria-labelledby wskazujące na potomny element title oraz aria-describedby wskazujące na potomny element desc lub zewnętrzny akapit po jego identyfikatorze. Każdy z nich jest mały. Każdy wykonuje pracę, której pozostałe dwa nie mogą.

Ważne ostrzeżenie: role=“img” na głównym elemencie svg zmienia sposób, w jaki technologie wspomagające traktują elementy potomne. Gdy użyto role=“img”, NVDA i JAWS traktują cały SVG jako pojedynczy, opatrzony etykietą obraz i nie ujawniają wewnętrznych węzłów — nawet jeśli mają one atrybut tabindex. Aby uzyskać oba zachowania — etykietę podsumowującą na górze i adresowalne elementy potomne wewnątrz — należy pozostawić rolę elementu głównego nieustawioną (lub ustawić role=“graphics-document” z modułu W3C Graphics ARIA) i umieścić etykietę na potomnym elemencie g, a nie na elemencie głównym. Przeglądarki i czytniki ekranu obsługują tę kombinację w różny sposób. Macierz w sekcji 6 dokumentuje, co działa i gdzie.

Atrybut longdesc był pierwotną odpowiedzią na pytanie „atrybut alt to za mało“. Przeglądarki od lat stopniowo wycofują jego obsługę: Firefox usunął ją w wersji 90, Safari nigdy jej nie zaimplementowało, Chrome traktuje ją jako puste działanie. Ktoś, kto w 2026 roku nadal pisze longdesc=“benzene-desc.html”, dostarcza markup, którego nic nie odczytuje. Zastępstwo to nie pojedynczy atrybut, lecz trójwarstwowy wzorzec łączący opis śródliniowy, widoczny panel rozwijany i metadane w formacie maszynowym.

Warstwa pierwsza to śródliniowy element desc wewnątrz SVG. Dwa do czterech zdań. Odczytywane przez czytniki ekranu w chwili ogłoszenia elementu głównego SVG. To nowy odpowiednik longdesc — opis będący częścią dokumentu SVG i podróżujący z nim wszędzie, dokąd SVG trafi.

Warstwa druga to widoczny, rozwijany panel opisu umieszczony obok diagramu, dostępny dla każdego czytelnika — nie tylko użytkowników czytników ekranu. Wiersz podsumowujący wraz z przyciskiem ujawniającym, który otwiera dłuższe omówienie tekstowe — zazwyczaj od trzech do dziesięciu zdań dla cząsteczki chemicznej, dłuższe dla diagramu struktury komórki z dwudziestoma oznaczonymi organellami. Widoczny panel rozwiązuje problem, którego śródliniowy element desc nie rozwiązuje: długiego opisu potrzebują też studenci, którzy widzą diagram, ale nie są w stanie go rozszyfrować — osoby słabowidzące, dyslektycy, każdy, kto po raz pierwszy poznaje dany materiał. Umieszczenie go za przyciskiem nie ukrywa go przed czytnikami ekranu — czytnik wylicza element ujawniający, użytkownik go aktywuje, a opis zostaje wczytany do buforu.

Warstwa trzecia to metadane strukturalne w formacie JSON-LD. Obiekt CreativeWork, którego tablica accessibilityFeature wylicza, co diagram oferuje: longDescription, alternativeText, structuralNavigation, describedMath, tactileGraphic (jeśli dostępna jest drukowana wersja dotykowa). Metadane te są konsumowane przez wyszukiwarki, systemy rekomendacji treści i skanery zgodności z wymogami dostępności. Nic nie robią dla bezpośredniego doświadczenia czytnika ekranu, ale sprawiają, że diagram jest wykrywalny jako treść dostępna — co ma znaczenie, gdy osoba ucząca się wybiera spośród trzech podręczników, a jeden z nich publikuje informacje o funkcjach dostępności w formacie maszynowym.

Diagramy statyczne to łatwy przypadek. Trudnym przypadkiem jest diagram animowany — mitochondrium obracające się w trzech wymiarach, fala sinusoidalna kreślona wzdłuż osi x, reakcja chemiczna z rozrywającymi się i odtwarzającymi wiązaniami w ciągu czterech sekund. Konwencjonalną odpowiedzią jest plik wideo ze ścieżką audiodeskrypcji, ale takie rozwiązanie porzuca adresowalność SVG: w chwili gdy animacja zostaje wypieczona do wideo, każdy węzeł, który starannie opatrzono etykietą, przestaje być węzłem DOM i znowu staje się pikselem.

Dostępną alternatywą jest zachowanie animacji jako SVG (lub Canvas z drzewem dostępności poza ekranem) i emitowanie audiodeskrypcji w trakcie animacji, sterowane tymi samymi mutacjami DOM, które napędzają zmianę wizualną. Wzorzec: MutationObserver obserwuje SVG pod kątem zmian — nowy atrybut transform, pojawiające się wiązanie, obracający się wektor — i przy każdej istotnej zmianie zapisuje krótką aktualizację tekstową do globalnego regionu aria-live=“polite”. Animacja wizualna napędza narrację dźwiękową generowaną na bieżąco z tego samego źródła prawdy.

Implementacja ma trzy ruchome części. Pierwsza to sama animacja wyrażona jako sekwencja klatek kluczowych osi czasu — te same dane, które konsumuje renderer SVG. Druga to warstwa adnotacji: każda klatka kluczowa niesie krótki tekst opisujący, co się w niej zmienia („wiązanie tworzy się między C1 i C2“, „fala przecina zero od dołu“). Trzecia to sterownik audiodeskrypcji, który subskrybuje oś czasu, pobiera każdą opatrzoną adnotacją klatkę kluczową i zapisuje jej tekst do regionu live na kilkaset milisekund przed zaistnieniem zmiany wizualnej. Wyprzedzenie odpowiada temu, co profesjonalna audiodeskrypcja robi dla filmów: opis jest słyszany tuż przed zdarzeniem wizualnym, a nie po nim.

Warto wskazać trzy tryby awarii, które są na tyle powszechne, by je tu omówić. Po pierwsze, nagłe serie aktualizacji. Animacja generująca 60 mutacji na sekundę zagłusza syntezator czytnika ekranu — ogłoszenia kolejkują się, opóźniają animację i stają się niezrozumiałe. Należy opatrywać adnotacjami tylko semantycznie istotne klatki kluczowe, nie każdą klatkę, i ograniczyć tempo do approx. jednego ogłoszenia na 1500 ms. Po drugie, pominięcie startu. Region live, który nie istniał przed rozpoczęciem animacji, może nie ogłaszać pierwszej aktualizacji w sposób niezawodny (zob. artykuł o szkielecie aria-live dotyczący leżącego u podstaw problemu planisty). Region live należy zamontować pusty przy ładowaniu strony. Po trzecie, brak kontroli pauzy. Użytkownicy muszą mieć możliwość wstrzymania audiodeskrypcji, zwolnienia jej lub przechodzenia przez nią krok po kroku. Należy zbudować mały pasek sterowania — odtwarzaj, pauza, poprzednie zdarzenie, następne zdarzenie — i podłączyć jego przyciski do tego samego sterownika osi czasu.

Wykres funkcji matematycznej, po którym student widzący może przesuwać kursor, nie jest dostępny, dopóki student niewidzący nie będzie mógł przesuwać się po nim klawiaturą. Mechanizm jest dobrze znany i źle implementowany w praktyce: każdy istotny punkt danych na krzywej otrzymuje tabindex=“0”, aria-label opisujący jego współrzędne i ewentualną nazwaną cechę („lokalne maksimum przy x = -1, y = 4“) oraz procedurę obsługi klawiatury reagującą na klawisze strzałek umożliwiające drobnoziarniste przemieszczanie między sąsiednimi punktami.

Właściwa ziarnistość ma większe znaczenie, niż się powszechnie uważa. Przechodzenie tabulatorem przez każdy wykreślony piksel krzywej sześciennej jest uciążliwe — użytkownik słyszy tysiące ogłoszeń „x równa się 0,1, y równa się 0,001“, zanim dotrze do czegoś interesującego. Przechodzenie tabulatorem jedynie przez nazwane cechy (lokalne maksima, minima, punkty przegięcia, miejsca zerowe, wartości dla x = 0) jest zbyt rzadkie. Pragmatyczny kompromis: dwie warstwy nawigacji. Klawisz Tab przemieszcza się wyłącznie przez nazwane cechy — zazwyczaj od trzech do siedmiu na krzywej — a klawisze strzałek, po sfokusowaniu cechy, przesuwają wzdłuż krzywej w lewo i prawo z krokiem definiowanym przez uczącego się, ogłaszając współrzędne przy każdym kroku. Home i End skaczą do lewej i prawej granicy krzywej. Page Up i Page Down skaczą do kolejnej nazwanej cechy.

W przypadku wykresu z wieloma seriami — wykresu kinetyki chemicznej, wykresu oscylacji fizycznych z dwiema falami — należy dodać oś przełączania serii. Klawisze strzałek w górę i w dół przemieszczają między seriami przy bieżącej współrzędnej x; klawisze strzałek w lewo i w prawo przemieszczają wzdłuż bieżącej serii. Konwencja ta nawiązuje do sposobu, w jaki czytniki arkuszy kalkulacyjnych obsługują nawigację po wierszach i kolumnach, i ponownie wykorzystuje model mentalny znany wielu użytkownikom.

Jeden szczegół jest często pomijany: sfokusowany punkt danych musi mieć widoczny wskaźnik fokusa. Użytkownik niewidzący go nie potrzebuje, ale widzący użytkownik czytnika ekranu tak, podobnie jak instruktorzy obserwujący pracę studenta. Należy wyrenderować pierścień fokusa wokół sfokusowanego elementu SVG za pomocą stylizacji :focus-visible — tę samą konwencję co pierścienie fokusa przycisków, zastosowaną do węzłów SVG, których przeglądarka domyślnie nie stylizuje.

Najtrudniejsza prawda w tym artykule: stos dostępnego SVG nie działa tak samo we wszystkich przeglądarkach i czytnikach ekranu, a luki te nie są błędami w kodzie. NVDA z Firefox to najbardziej niezawodna kombinacja — jedyna, w której każdy wzorzec opisany w tym artykule zachowuje się tak, jak mówi mapowanie dostępności SVG W3C. Każda inna kombinacja ma co najmniej jedną znana lukę.

Safari na macOS z VoiceOver jest najbardziej problematycznym z głównych stosów. Drzewo dostępności SVG w WebKit ma udokumentowane luki w sposobie eksponowania wewnętrznych elementów g z etykietami ARIA: etykiety są obecne w DOM i możliwe do sprawdzenia w inspektorze dostępności, ale VoiceOver nie zawsze je odczytuje, gdy użytkownik nawiguje za pomocą VO-Strzałka w prawo. Zachowanie jest niespójne — niekiedy wewnętrzne etykiety są ogłaszane, niekiedy odczytywana jest tylko etykieta głównego SVG, bez żadnego wzorca widocznego po stronie klienta. Bugzilla WebKit zawiera otwarte zgłoszenia w tej sprawie sięgające 2020 roku. Praktyczna implikacja: jeśli diagram STEM działa na Macu, jest to warunek konieczny, nie wystarczający. Przed wdrożeniem należy przetestować na Windows z NVDA.

Chrome na Windows z JAWS to drugi najbardziej niezawodny stos — zbliżony do NVDA + Firefox, z jednym zastrzeżeniem: JAWS traktuje SVG role=“img” bardziej agresywnie niż NVDA i częściej zwija węzły wewnętrzne. Rozwiązaniem jest użycie role=“graphics-document” z modułu W3C Graphics ARIA na głównym elemencie svg, co JAWS obsługuje poprawnie. NVDA również obsługuje to poprawnie. Firefox i Chrome dostarczają niezbędne mapowania API platformy.

Mobile to oddzielny problem. iOS VoiceOver dziedziczy luki SVG WebKit; Android TalkBack na Chrome niezawodnie obsługuje węzły wewnętrzne, ale nie obsługuje jeszcze ról W3C Graphics ARIA, więc stosuje zachowanie zastępcze role=“img”. Dla wydawcy podręczników skierowanego zarówno do użytkowników komputerów stacjonarnych, jak i urządzeń mobilnych, bezpiecznym wyborem jest dostarczanie SVG w dwóch trybach: trybu z nawigacją strukturalną dla komputerów stacjonarnych i trybu „podsumowanie plus długi opis“, który wyłącza nawigację wewnętrzną na urządzeniach mobilnych. Przełączanie trybu jest sterowane przez user agent i preferencję użytkownika zachowaną między sesjami.

Jeden wniosek z macierzy: NVDA + Firefox powinno stanowić bazowy cel zgodności, Safari i TalkBack należy udokumentować jako mechanizmy zastępcze, a braku ogłoszenia węzła wewnętrznego na Macu nie należy nigdy traktować jako dowodu na niedostępność SVG. Diagram może być w pełni dostępny — platforma po prostu nie eksponuje zapisanych etykiet. Inspektor dostępności w Safari z menu Develop pokazuje, co jest w drzewie, nawet gdy VoiceOver nie odczytuje tego, i stanowi właściwe narzędzie do odróżnienia „uszkodzonego markup“ od „uszkodzonej platformy“.

Większość opublikowanych wskazówek dotyczących dostępności diagramów STEM zatrzymuje się na warstwie title-i-desc. To łatwe 30 procent. Pozostałe 70 procent — panel długiego opisu, oś czasu audiodeskrypcji sterowana mutacjami DOM, nawigacja klawiaturą w dwóch ziarnistościach, mechanizmy zastępcze właściwe dla poszczególnych platform — to projektowanie interakcji tak samo jak markup. Czytnik ekranu to jeden użytkownik; niewidząca osoba ucząca się, która używa czytnika ekranu do nawigacji po wykresie funkcji w tempie widzącego kolegi z klasy, to inny użytkownik, z innymi potrzebami.

Dywidenda jest duża i nierównomiernie rozłożona. Wydawca podręcznika, który dostarcza pełny stos we wszystkich approx. 600 diagramach podręcznika rachunku różniczkowego, obsługuje każdą niewidzącą osobę uczącą się z tego podręcznika, każdą słabowidzącą osobę doceniającą panel ujawniający, każdego dyslektyka, który może przeczytać długi opis, ale nie jest w stanie rozszyfrować reprezentacji wizualnej, każdą uczącą się po angielsku jako obcym języku, dla której ustrukturyzowany opis jest łatwiejszy niż wizualne konwencje danej dziedziny, i każdego widzącego instruktora tworzącego podsumowania dźwiękowe na potrzeby podcastów. Ten sam markup obsługuje pięć odrębnych grup odbiorców. Koszt to kilka godzin na diagram, amortyzowanych przez dekady użytkowania przez studentów.

Obecny stan sztuki jest nierówny, ponieważ implementacje drzewa dostępności różnią się między systemami operacyjnymi, z których korzystają studenci. NVDA i JAWS na Windows zamknęły większość luk SVG. Safari na macOS — nie. Do czasu konwergencji platform wzorzec produkcyjny polega na tworzeniu pod najbardziej rygorystyczny cel — NVDA + Firefox — i dokumentowaniu mechanizmów zastępczych dla platform ze znanymi lukami. To więcej pracy, niż wymagał kiedyś model tekstu alternatywnego. To jednocześnie jedyny sposób, by dostarczyć podręcznik STEM, który nie wyklucza czytelników, których ma uczyć.