Drzewo dostępności

Drzewo dostępności to struktura danych na poziomie systemu operacyjnego, którą faktycznie konsumują czytniki ekranu i inne technologie asystujące. Gdy otwierasz stronę w przeglądarce, przeglądarka buduje dwa drzewa: drzewo DOM (zwykłą hierarchię HTML) oraz drzewo dostępności — równoległą strukturę wywodzoną z DOM, lecz zawierającą metadane dostępności.

Zrozumienie drzewa dostępności wyjaśnia około 80% skądinąd mylącego zachowania ARIA, czytników ekranu i sesji debugowania „dlaczego to nie jest ogłaszane?”.

Co w nim jest

Każdy węzeł drzewa dostępności ma:

• Rolę — czym element jest: przyciskiem, linkiem, nagłówkiem, nawigacją, oknem dialogowym. Pochodzi z typu elementu HTML lub z jawnego atrybutu ARIA role="...".
• Nazwę — jak element się nazywa. Pochodzi z tekstu etykiety, atrybutu alt, aria-label, aria-labelledby lub obliczonej zawartości tekstowej.
• Opis — dodatkowy kontekst. Pochodzi z atrybutów aria-describedby lub title.
• Stan — aktualny stan: wciśnięty, rozwinięty, zaznaczony, zajęty. Pochodzi z atrybutów HTML (disabled, required) lub ARIA (aria-pressed, aria-expanded).
• Właściwości — relacje i metadane: aria-controls, aria-owns, aria-haspopup.

Czytniki ekranu przemierzają to drzewo i ogłaszają każdy węzeł na podstawie tych pól. Nawigacja klawiszami Tab i strzałkami odbywa się przez drzewo, nie przez DOM.

Dlaczego treść czysto wizualna znika

<div onclick="..."> ostylowany tak, aby wyglądał jak przycisk, nie ma roli w drzewie dostępności — przeglądarka widzi generyczny <div> i zapisuje go jako role="generic" (praktycznie niewidoczny dla technologii asystujących). Procedura obsługi onclick nie trafia do drzewa dostępności, ponieważ drzewo dostępności odzwierciedla jedynie to, czym przeglądarka wnioskuje, że element jest na podstawie swojej roli HTML.

Dlatego semantyczny HTML ma znaczenie na najbardziej fundamentalnym poziomie: nie ze względu na styl czy konwencję, ale dlatego, że semantyczne elementy HTML automatycznie wypełniają drzewo dostępności właściwymi rolami. Niesemanyczny znacznik tworzy drzewo z „zupą divów”, z której czytniki ekranu nie mogą nic wywnioskować.

Rola ARIA w drzewie

ARIA istnieje właśnie po to, aby wypełniać drzewo dostępności w przypadkach, gdy natywny HTML nie ma odpowiadającego elementu. role="combobox" mówi przeglądarce, aby umieściła węzeł combobox w drzewie dla elementu, który w przeciwnym razie pojawiłby się jako generyczny. aria-expanded="true" ustawia właściwość stanu na tym węźle.

ARIA NIE zmienia DOM. Zmienia to, co przeglądarka wpisuje do drzewa dostępności.

Jak je sprawdzić

Narzędzia deweloperskie przeglądarek udostępniają teraz drzewo dostępności bezpośrednio:

• Chrome / Edge DevTools — panel Elements → zakładka Accessibility (prawa kolumna) pokazuje obliczone właściwości dostępności dla wybranego węzła. Przełącznik „Full-page accessibility tree” (flaga Chrome w niektórych wersjach) wyświetla drzewo jako pasek boczny.
• Firefox DevTools — panel Accessibility (ikona na pasku narzędzi) pokazuje dedykowany widok drzewa dostępności, podobny do widoku Elements, ale renderowany w terminologii drzewa dostępności.
• Safari Web Inspector — zakładka Audit / Accessibility zapewnia porównywalne możliwości inspekcji.

Gdy widzisz drzewo dostępności, możesz empirycznie odpowiedzieć na pytanie „dlaczego to nie jest ogłaszane?”. Odpowiedź prawie zawsze brzmi: węzeł w drzewie dostępności ma inną rolę, niż sądziłeś, lub jego nazwa jest pusta, lub jego stan jest nieprawidłowy.

Dlaczego „drzewo dostępności” jest lepszym modelem mentalnym niż „ARIA”

Inżynierowie, którzy uczą się ARIA bez rozumienia drzewa dostępności, w końcu posypują atrybutami ARIA, mając nadzieję, że czytniki ekranu je wychwycą. Inżynierowie, którzy rozumieją drzewo dostępności, wiedzą, że zadaniem ARIA jest zapisywanie konkretnych pól do konkretnych węzłów drzewa i że bezpośrednia inspekcja drzewa jest szybsza niż zgadywanie.