Najważniejsze wnioski
- ARIA przekazuje role, nazwy, stany i relacje do drzewa dostępności, ale sama nie tworzy zachowania komponentu.
- Jeżeli dostępny jest właściwy element HTML, zwykle należy użyć go zamiast elementu z ręcznie nadaną rolą ARIA.
- Przyciski rozwijające, dialogi, zakładki i comboboksy wymagają równocześnie poprawnej semantyki, obsługi klawiatury, zarządzania fokusem oraz aktualizacji stanu.
- Atrybuty takie jak aria-expanded, aria-selected czy aria-hidden muszą odpowiadać rzeczywistemu stanowi interfejsu.
- Widget może wspierać użytkownika dodatkowymi funkcjami dostępności, ale nie zastępuje naprawy błędnej semantyki, interakcji JavaScript ani testów komponentów.
Dla zarządzającego
ARIA jest ważna głównie tam, gdzie firma rozwija własne komponenty interfejsu: filtry, koszyk, menu, okna modalne lub panele konta. Najniższe ryzyko i koszt daje zasada „HTML przed ARIA”, uzupełniona testami krytycznych ścieżek zakupowych oraz audytem tam, gdzie komponenty są złożone.
Dla sprzedaży
W rozmowie o dostępności nie warto obiecywać, że samo dodanie atrybutów ARIA rozwiąże problem. Dobrą propozycją jest połączenie szybkiego wsparcia użytkownika, np. przez WCAGbot, z planem trwałych poprawek w formularzu, koszyku, płatności i nawigacji.
ARIA warto wdrażać wtedy, gdy sam HTML nie potrafi opisać niestandardowego komponentu użytkownikowi czytnika ekranu. Nie jest jednak zamiennikiem poprawnego HTML, obsługi klawiatury ani testów. Jeśli element jest przyciskiem, linkiem albo polem formularza, najczęściej najlepszym rozwiązaniem pozostaje użycie natywnego elementu HTML.
Ten poradnik wyjaśnia, jak podejmować decyzje dotyczące ARIA, które atrybuty mają praktyczne znaczenie oraz jak uniknąć błędów szczególnie kosztownych w e-commerce: niedziałających filtrów, modalnego koszyka, zakładek produktu i komunikatów błędów w formularzu.
Najważniejsze wnioski
- ARIA opisuje interfejs, ale go nie programuje.
- Natywny
buttonzwykle jest lepszy niżdiv role="button". - Stan przekazany w ARIA musi zawsze zgadzać się z tym, co faktycznie dzieje się na ekranie.
- Komponent interaktywny testuj klawiaturą oraz co najmniej jednym czytnikiem ekranu.
- Funkcje wspierające dostępność mogą pomóc użytkownikowi od razu, ale błędną semantykę i logikę komponentu trzeba poprawić w kodzie źródłowym.
Czym jest ARIA i co właściwie robi?
WAI-ARIA to zbiór ról, stanów i właściwości, które przekazują dodatkową informację do drzewa dostępności. Dzięki temu czytnik ekranu może rozpoznać na przykład, że kontrolka jest zakładką, przyciskiem rozwijającym albo oknem dialogowym.
W praktyce ARIA występuje w trzech głównych formach:
- role — określają funkcję elementu, np.
role="dialog",role="tab"lubrole="status"; - stany — opisują zmienny stan, np.
aria-expanded,aria-selectediaria-checked; - właściwości — budują nazwę, opis albo relację, np.
aria-label,aria-labelledby,aria-describedbyiaria-controls.
ARIA nie zmienia wyglądu elementu. Nie sprawia też, że element zacznie reagować na Enter, spację, Escape lub strzałki. Nie przenosi fokusu i nie zamyka okna modalnego. Za te zachowania nadal odpowiada HTML i JavaScript.
Dostępny komponent to nie zestaw atrybutów. To zgodna całość: znaczenie, działanie, fokus i informacja zwrotna dla użytkownika.
Dlaczego najpierw HTML, a dopiero potem ARIA?
Natywne elementy HTML mają wbudowaną semantykę oraz przewidywalne zachowania. Przycisk można objąć fokusem, uruchomić klawiaturą i rozpoznać w czytniku ekranu bez dodatkowego kodu. Link prowadzi do adresu URL. Pole input współpracuje z etykietą label.
Dlatego warto najpierw przeczytać poradnik HTML semantyczny: praktyczny poradnik wdrożenia. Semantyczna struktura dokumentu jest podstawą, której ARIA nie powinna imitować bez konieczności.
Przykład: przycisk bez zbędnej ARIA
Niepotrzebnie złożony wariant:
<div role="button" tabindex="0" onclick="openDialog()">
Otwórz ustawienia
</div>Lepszy wariant:
<button type="button" onclick="openDialog()">
Otwórz ustawienia
</button>W pierwszym przypadku zespół musi dopisać obsługę Enter i spacji, zadbać o fokus oraz odtworzyć oczekiwane zachowania. W drugim podstawową pracę wykonuje przeglądarka.
Podobnie nie należy dopisywać role="button" do elementu button ani role="link" do poprawnego linku. Taka ARIA jest redundantna i utrudnia późniejsze utrzymanie kodu.
WCAGbot Accessibility Path dla komponentu z ARIA
Kiedy ARIA jest uzasadniona?
ARIA przydaje się przede wszystkim wtedy, gdy interfejs zmienia się dynamicznie albo gdy budujesz komponent, dla którego HTML nie zapewnia pełnego opisu relacji i stanu. Typowe przykłady w sklepie internetowym to:
- przycisk rozwijający panel filtrów;
- okno dialogowe potwierdzające usunięcie produktu z koszyka;
- zakładki z opisem, parametrami i opiniami produktu;
- komunikat o wyniku dodania produktu do koszyka;
- niestandardowy wybór wariantu lub autouzupełnianie wyszukiwarki.
Nie oznacza to, że każdy taki komponent trzeba tworzyć od zera. Przed implementacją sprawdź odpowiedni wzorzec w ARIA Authoring Practices Guide W3C. Materiał pokazuje, jakie role, stany, skróty klawiszowe i zasady fokusu zwykle należą do danego wzorca.
Jak wdrożyć ARIA w praktyce?
Do uporządkowania prac przy własnych komponentach można wykorzystać WCAGbot Accessibility Path. To prosty schemat od decyzji projektowej do testu, a nie deklaracja zgodności ani zamiennik audytu.
- Opisz cel komponentu. Ustal, czy użytkownik przechodzi pod adres, wykonuje akcję, wybiera opcję czy otrzymuje komunikat.
- Znajdź element natywny. Użyj linku, przycisku, listy, pola formularza, nagłówka lub tabeli, jeśli odpowiadają zadaniu.
- Dodaj wyłącznie potrzebną ARIA. Nadaj nazwę, stan albo relację, której nie zapewnia HTML.
- Zaprogramuj zachowanie. Synchronizuj widok, DOM, fokus i wartości ARIA.
- Przetestuj ścieżkę użytkownika. Sprawdź klawiaturę, czytnik ekranu oraz zachowanie po błędzie i po zamknięciu komponentu.
- Włącz poprawki do procesu jakości. Nie traktuj testu jako jednorazowej czynności przed publikacją.
Przycisk rozwijający filtry
<button type="button"
aria-expanded="false"
aria-controls="filters-panel">
Filtry
</button>
<section id="filters-panel" hidden>
<!-- pola filtrów -->
</section>Po kliknięciu lub aktywacji klawiaturą skrypt powinien jednocześnie otworzyć panel, usunąć lub dodać hidden oraz zmienić aria-expanded na właściwą wartość. Samo aria-expanded="true" nie pokaże panelu.
W filtrach, menu i koszyku szczególne znaczenie ma kolejność fokusu. Przejdź całą ścieżkę według checklisty z artykułu Nawigacja klawiaturą: jak testować stronę zgodnie z WCAG.
Dialog potwierdzający operację
<div role="dialog"
aria-modal="true"
aria-labelledby="remove-title">
<h2 id="remove-title">Usunąć produkt z koszyka?</h2>
<button type="button">Anuluj</button>
<button type="button">Usuń produkt</button>
</div>To tylko struktura. Pełny dialog wymaga przeniesienia fokusu do okna po otwarciu, zachowania fokusu w aktywnym oknie, logicznego zamknięcia oraz zwrotu fokusu do elementu otwierającego. Trzeba też zdecydować, czy Escape zamyka dialog, zgodnie z funkcją i ryzykiem danej operacji.
Najczęstsze błędy ARIA, które tworzą bariery
| Błąd | Dlaczego jest problemem | Lepsze działanie |
|---|---|---|
div role="button" zamiast przycisku | Rola nie dodaje automatycznie obsługi klawiatury. | Użyj button albo wdroż pełne zachowanie komponentu. |
aria-expanded niezgodne z widokiem | Czytnik ekranu przekazuje błędny stan. | Aktualizuj stan ARIA razem z panelem. |
aria-hidden="true" na fokusowalnym elemencie | Użytkownik klawiatury może wejść na element niewidoczny dla czytnika. | Usuń element z interakcji albo nie ukrywaj go przed technologią asystującą. |
Dodatni tabindex | Tworzy sztuczną i trudną do utrzymania kolejność fokusu. | Oprzyj kolejność na DOM; stosuj -1 tylko do programowego fokusu. |
aria-label nadpisujący widoczny tekst | Nazwa dostępna może różnić się od etykiety widzianej przez użytkownika. | Użyj widocznej treści lub aria-labelledby, gdy to właściwe. |
HTML natywny a komponent z ARIA
Jak testować komponent z ARIA?
Automatyczne testy są przydatne, lecz nie ocenią całego zachowania dynamicznego interfejsu. W szczególności nie potwierdzą, czy fokus wraca we właściwe miejsce, czy interakcja strzałkami działa zgodnie ze wzorcem oraz czy komunikat jest zrozumiały.
Wykonaj co najmniej następujące kroki:
- przejdź komponent klawiszem Tab i Shift+Tab;
- sprawdź Enter, spację, Escape oraz strzałki, jeśli przewiduje je wzorzec;
- upewnij się, że wskaźnik fokusu jest widoczny;
- sprawdź, czy nazwa, rola i stan są komunikowane w czytniku ekranu;
- otwórz, zamknij i ponownie otwórz komponent;
- sprawdź błędy walidacji, komunikaty sukcesu i zmianę kontekstu.
Do testów lokalnych warto wykorzystać praktyczny poradnik testowania dostępności w NVDA. W przypadku formularzy sprawdź również relację etykiety, podpowiedzi, błędu i pola zgodnie z materiałem Dostępny formularz: jak projektować i testować zgodnie z WCAG.
Mini-scenariusz: filtry w sklepie z błędną ARIA
Scenariusz ilustracyjny, nie opis realnego wdrożenia klienta: sklep ma przycisk „Filtry” z aria-expanded="false". Po kliknięciu panel filtrów widocznie się otwiera, ale atrybut pozostaje bez zmian. Użytkownik czytnika ekranu otrzymuje informację, że panel jest zwinięty, mimo że może już zawierać aktywne pola.
Naprawa obejmuje trzy elementy: aktualizację aria-expanded, spójną zmianę widoczności panelu oraz test kolejności fokusu. Jeżeli otwarcie panelu na telefonie działa jak pełnoekranowy modal, potrzebne jest dodatkowo poprawne zarządzanie fokusem podobne do dialogu.
Taki problem może wystąpić zarówno w rozwiązaniu własnym, jak i w motywie platformy. Dlatego w sklepach warto osobno testować katalog, stronę produktu, koszyk i płatność. Więcej kontekstu znajdziesz w artykule WCAG dla e-commerce: jak ułatwić zakupy online.
Gdzie kończy się widget dostępności, a zaczyna naprawa źródłowa?
WCAGbot może być szybkim pierwszym krokiem do dostępności. Po dodaniu jednej linii kodu udostępnia użytkownikowi między innymi tryby kontrastu, zmianę wielkości tekstu, ustawienia odstępów, czytanie treści, większy kursor, funkcje skupienia i gotowe profile potrzeb. System może też automatycznie uzupełniać wybrane wykrywalne atrybuty ARIA, alt i title.
Nie należy jednak zakładać, że zewnętrzne narzędzie naprawi pełną logikę własnego dialogu, zakładek, procesu płatności lub niestandardowego formularza. Nie zastąpi ono poprawnego JavaScriptu, prawidłowej obsługi klawiatury, testów z czytnikiem ekranu ani audytu i naprawy źródłowej.
Dostępny przycisk filtrów w sklepie
Otwórz panel WCAGbot na własnej stronie, zwiększ tekst, przetestuj kontrast i sprawdź, czy kluczowe elementy interfejsu pozostają czytelne oraz łatwe do obsługi. Następnie zaplanuj poprawki w kodzie tam, gdzie komponenty przekazują błędną semantykę lub działają niepoprawnie.
Podsumowanie dla zarządzającego i zespołu sprzedaży
ARIA jest narzędziem technicznym, a nie etykietą jakości. Najlepszą decyzją biznesową jest ograniczanie własnych, złożonych komponentów do sytuacji, w których są naprawdę potrzebne, a następnie testowanie tych komponentów na krytycznych ścieżkach użytkownika.
Dla zespołu odpowiedzialnego za stronę oznacza to prostą kolejność: semantyczny HTML, minimalna potrzebna ARIA, poprawne zachowanie, test klawiaturą i czytnikiem, a potem stała kontrola w ramach planu audytu WCAG i wdrożenia poprawek. Widget może równolegle wspierać użytkownika, lecz nie powinien być przedstawiany jako alternatywa dla trwałego usuwania barier.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot.
FAQ: ARIA — najczęstsze pytania
Czy ARIA jest wymagana na każdej stronie?
Nie. Wiele stron można zbudować dostępnie przede wszystkim na natywnym HTML. ARIA jest potrzebna wtedy, gdy trzeba przekazać dodatkową semantykę lub stan, którego sam HTML nie zapewnia w danym interfejsie.
Czy role ARIA zastępują znaczniki HTML?
Nie. Rola może opisać funkcję elementu, ale nie odtwarza automatycznie zachowania natywnego elementu. Jeśli istnieje odpowiedni znacznik HTML, zwykle należy go wybrać.
Czy należy dodawać role do każdego przycisku i linku?
Nie. Element button ma już domyślną rolę przycisku, a poprawny element a z atrybutem href ma semantykę linku.
Kiedy stosować aria-label?
Przede wszystkim wtedy, gdy kontrolka potrzebuje dostępnej nazwy, ale nie ma odpowiedniego widocznego tekstu, np. przycisk zawierający tylko ikonę zamknięcia. Nie używaj go bez potrzeby do nadpisywania jasnej widocznej etykiety.
Czy aria-expanded samo otwiera panel?
Nie. Atrybut jedynie komunikuje stan. Kod musi dodatkowo otworzyć lub zamknąć panel oraz utrzymać zgodność wartości atrybutu z rzeczywistym widokiem.
Czy aria-hidden można dodać do ikony w przycisku?
Tak, gdy ikona jest wyłącznie dekoracyjna, a przycisk ma poprawną nazwę dostępną, na przykład widoczny tekst albo aria-label. Nie ukrywaj w ten sposób elementu, który użytkownik może objąć fokusem lub obsłużyć.
Czy dodatni tabindex poprawia nawigację klawiaturą?
Zwykle nie. Wartości dodatnie tworzą własną kolejność tabulacji i mogą zaburzyć naturalną kolejność dokumentu. Preferuj logiczny DOM oraz natywne kontrolki.
Jak testować ARIA bez specjalistycznego laboratorium?
Zacznij od przejścia klawiaturą przez funkcję, sprawdź widoczny fokus i zmiany stanu, a następnie wykonaj test w czytniku ekranu, np. NVDA. Dla ważnych procesów warto rozszerzyć ten zakres o audyt i testy z użytkownikami.
Czy WCAGbot naprawi błędną implementację dialogu ARIA?
Nie należy tego zakładać. WCAGbot wspiera dostępność funkcjami po stronie użytkownika i może uzupełniać wybrane wykrywalne atrybuty, ale nie zastępuje naprawy źródłowej złożonego zachowania, fokusu i obsługi klawiatury w dialogu.
