ARIA — narzędzie pomocnicze, nie magiczny przycisk

ARIA brzmi poważnie. Dla wielu osób nawet trochę magicznie — bo kiedy pojawia się temat dostępności, łatwo dojść do wniosku, że skoro coś nie działa idealnie, wystarczy „dodać ARIA” i problem będzie załatwiony.

Tyle że bardzo często właśnie wtedy zaczyna się nowy problem. Bo ARIA potrafi pomóc, ale potrafi też tylko przykryć źle zbudowany HTML i stworzyć wrażenie, że wszystko zostało naprawione, chociaż fundament nadal jest słaby.

Czym właściwie jest ARIA

ARIA to zestaw atrybutów, które pomagają lepiej opisać elementy interfejsu dla technologii wspomagających — zwłaszcza wtedy, gdy sam HTML nie wystarcza albo gdy budujesz bardziej niestandardowe komponenty. Może opisać rolę elementu, wskazać jego stan, połączyć go z etykietą albo powiedzieć, czy coś jest aktualnie rozwinięte lub aktywne.

Najprościej: ARIA nie tworzy dostępności od zera. ARIA pomaga ją doprecyzować.

Najpierw HTML, potem ARIA

To punkt wyjścia do całego tematu.

Jeśli coś da się zrobić poprawnym, natywnym HTML-em, zwykle właśnie tak powinno się to zrobić — przycisk jako button, link jako a, pole formularza jako odpowiedni element formularza, nagłówek jako nagłówek. Natywne elementy mają już wbudowane znaczenie, zachowanie i logikę obsługi. Przeglądarka i technologie wspomagające rozumieją je od razu.

Jeśli zamiast tego bierzesz zwykły div i próbujesz „dopisać mu sens” przez ARIA, zwykle kończysz z gorszą wersją czegoś, co HTML już umiał zrobić dobrze.

Kiedy ARIA naprawdę pomaga, a kiedy tylko maskuje problem

ARIA ma sens, gdy budujesz bardziej złożony komponent i potrzebujesz doprecyzować stan interfejsu — na przykład gdy przycisk rozwija panel i trzeba zakomunikować, czy panel jest otwarty, gdy zakładki mają stan aktywny albo gdy dynamiczny komponent wymaga dodatkowego opisu. W takich sytuacjach ARIA działa najlepiej: nie jako zamiennik semantyki, tylko jako jej uzupełnienie.

Problem zaczyna się wtedy, gdy ktoś próbuje naprawić zły fundament bez ruszania fundamentu. div udający przycisk, spanudający link, formularz bez poprawnych etykiet „ratowany” dodatkowymi atrybutami — w takich przypadkach ARIA nie rozwiązuje głównego problemu. Ona tylko dopisuje warstwę opisową do czegoś, co od początku zostało zbudowane źle. Trochę jak podpisanie źle zaprojektowanych drzwi słowem „wyjście” — napis może pomóc, ale sam fakt, że drzwi są źle zrobione, nadal zostaje.

Klasyczny błąd: div role=”button”

To chyba najlepszy przykład. Ktoś bierze div, styluje go jak przycisk, dodaje role="button" i uznaje, że sprawa załatwiona. Tyle że natywny button już sam z siebie ma właściwą rolę, działa z klawiatury, ma przewidywalne zachowanie i jest rozumiany przez przeglądarkę i technologie wspomagające.

div z rolą przycisku to zwykle tylko próba dogonienia tego, co HTML już dawał gotowe — i bardzo często taka próba nadal czegoś nie domyka: obsługi klawiatury, stanów, fokusu, logiki interakcji. Zamiast ulepszyć interfejs, tworzysz jego bardziej kruchą wersję.

ARIA nie naprawia złej struktury

Jeśli strona ma złą hierarchię nagłówków, nieczytelne linki, źle zbudowane formularze albo elementy interaktywne zrobione z przypadkowych bloków — samo dodanie ARIA nie sprawi, że wszystko stanie się dobre. ARIA nie zastąpi semantycznego HTML, porządnej struktury ani logicznego interfejsu. Może coś dopowiedzieć. Nie powinna udawać fundamentu.

Gdzie ARIA bywa naprawdę potrzebna

Żeby nie popaść w drugą skrajność: ARIA nie jest zła. Po prostu trzeba używać jej tam, gdzie rzeczywiście ma sens — przy komponentach dynamicznych, rozwijanych sekcjach, zakładkach, modalach, tooltipach, statusach i komunikatach, bardziej złożonych interfejsach JavaScriptowych. Tam sam HTML często nie opisuje wystarczająco dobrze stanu i relacji między elementami, i wtedy ARIA robi dokładnie to, do czego została stworzona.

Najprostszy test

Jeśli nie wiesz, czy potrzebujesz ARIA, wystarczą trzy pytania:

Czy da się to zrobić natywnym HTML-em? Jeśli tak, zwykle to jest lepsza droga. Czy ARIA dodaje znaczenie, czy tylko łata zły wybór elementu? Jeśli łata — problem jest głębiej. Czy bez ARIA komponent traci ważną informację o stanie lub roli? Jeśli tak — wtedy ARIA może naprawdę pomóc.

Dlaczego to ważne w WordPressie i builderach

W WordPressie i builderach bardzo łatwo wejść w model „to wygląda dobrze, więc pewnie jest okej”. A potem okazuje się, że przyciski są tylko stylowanymi blokami, rozwijane sekcje nie komunikują stanu, a niestandardowe moduły udają elementy, którymi nie są.

W takich środowiskach pokusa „dopisania ARIA” jest duża. Ale właśnie tam szczególnie trzeba pilnować kolejności: najpierw dobra struktura i sensowne elementy, dopiero potem dodatkowa warstwa ARIA.

Podsumowanie

ARIA działa najlepiej, gdy fundament jest dobry, HTML ma sens, struktura jest poprawna, a ARIA tylko doprecyzowuje role, stany i relacje. Jeśli próbujesz odwrócić tę kolejność, łatwo dojść do sytuacji, w której interfejs wygląda na bardziej dostępny, niż jest w rzeczywistości.

Dlatego najprostsza zasada: jeśli HTML umie to zrobić sam, pozwól mu to zrobić. ARIA dodawaj wtedy, gdy naprawdę wnosi coś potrzebnego.