Najważniejsze wnioski
- Poziom AA wymaga spełnienia wszystkich kryteriów WCAG na poziomie A i AA dla pełnych stron oraz istotnych procesów, takich jak rejestracja, zakup i płatność.
- Automatyczne testy pomagają wykrywać część błędów, ale nie potwierdzają samodzielnie zgodności z WCAG ani użyteczności strony dla użytkowników technologii asystujących.
- Największy efekt zwykle przynoszą poprawki podstaw: kontrastu, semantycznego HTML, opisów obrazów, etykiet formularzy, nazw przycisków, fokusu i komunikatów błędów.
- WCAGbot może wspierać użytkowników dodatkowymi funkcjami, takimi jak kontrast, powiększenie tekstu, czytanie treści czy większy kursor, ale nie zastępuje audytu ani naprawy kodu i treści.
- Dostępność należy utrzymywać po wdrożeniu: każda nowa funkcja, szablon, kampania i integracja zewnętrzna może wprowadzić nową barierę.
Dla zarządzającego
Poziom AA WCAG warto traktować jako proces ograniczania barier w obsłudze usług cyfrowych, a nie jako jednorazowy projekt techniczny. Najpierw należy ustalić zakres usług i ryzyko biznesowe, potem poprawić najważniejsze ścieżki użytkownika, a na końcu włączyć testy dostępności do stałego utrzymania produktu.
Dla sprzedaży
Dostępność może ułatwić klientowi wykonanie podstawowych działań: znalezienie produktu, wybór wariantu, wypełnienie formularza, logowanie i finalizację płatności. W rozmowie z klientem nie należy obiecywać pełnej zgodności po instalacji widgetu; warto jasno wyjaśnić, że WCAGbot wspiera użytkownika, a trwałe bariery wymagają audytu i poprawek źródłowych.
Poziom AA WCAG to nie lista kilku poprawek wizualnych. Oznacza spełnienie wszystkich kryteriów sukcesu na poziomie A i AA dla całej ocenianej strony, a w przypadku usług cyfrowych także dla istotnych procesów, takich jak rejestracja, logowanie, zakup czy płatność. Jeżeli użytkownik może przejść przez stronę główną, ale nie potrafi klawiaturą wybrać dostawy lub opłacić zamówienia, nie można uznać procesu za dostępny.
Najważniejsze wnioski:
- AA obejmuje podstawy techniczne, treść, interakcje i cały przebieg zadania użytkownika.
- Skaner jest przydatny do wykrywania części błędów, lecz nie zastępuje testów manualnych i testów z użytkownikami.
- W e-commerce priorytetem są wyszukiwarka, filtry, karta produktu, koszyk, formularze, logowanie i płatność.
- Widget dostępności wspiera użytkownika dodatkowymi ustawieniami, ale nie naprawia automatycznie wszystkich barier w kodzie ani treści.
Czym dokładnie jest poziom AA WCAG?
WCAG to wytyczne dostępności treści internetowych tworzone przez W3C. Kryteria sukcesu występują na trzech poziomach: A, AA i AAA. Poziom AA oznacza konieczność spełnienia zarówno kryteriów A, jak i AA. Nie jest to ocena pojedynczego banera, formularza albo strony głównej.
W3C wskazuje, że deklarowana zgodność dotyczy pełnych stron internetowych. Dotyczy to także ich wersji responsywnych i używanych technologii. W praktyce oznacza to, że ocena powinna obejmować wszystkie istotne szablony oraz kompletne ścieżki wykonania zadania, a nie wyłącznie wybrane widoki.
Aktualnym punktem odniesienia technicznego jest WCAG 2.2. Wśród kryteriów poziomu AA, które są szczególnie ważne dla sklepów i usług online, znajdują się między innymi: widoczny fokus, fokus niezasłonięty, alternatywa dla przeciągania, odpowiedni rozmiar celu interakcji oraz dostępne uwierzytelnianie.
Warto rozróżnić trzy pojęcia:
- WCAG to wytyczne techniczne opisujące kryteria dostępności.
- EN 301 549 to europejska norma dostępności ICT, która może odwoływać się do WCAG, ale obejmuje szerszy zakres wymagań niż sama strona WWW. Zobacz także poradnik EN 301 549 w e-commerce.
- Polski Akt o Dostępności (PAD) to ustawa dotycząca określonych produktów i usług. Zakres obowiązku zależy od rodzaju podmiotu oraz usługi, dlatego nie należy zakładać, że identycznie dotyczy każdej firmy.
Informacja prawna: opis PAD w tym artykule ma charakter informacyjny. Stan prawny wymaga potwierdzenia przed publikacją i przed zastosowaniem do konkretnej działalności. Więcej kontekstu dla sklepów zawiera tekst Polski Akt o Dostępności w e-commerce.
Poziom AA nie jest przyciskiem „gotowe”. To sposób projektowania i utrzymywania usługi tak, aby użytkownik nie musiał omijać barier podczas wykonywania ważnego zadania.
Dlaczego wdrożenie AA warto zacząć od podstaw?
Najczęściej powtarzają się problemy, które blokują podstawową obsługę strony: niski kontrast, brak opisów obrazów, brak etykiet formularzy, puste linki i nieopisane przyciski. W badaniu WebAIM Million 2025 niski kontrast wykryto na 79,1% analizowanych stron głównych, a brak etykiet pól formularzy na 48,2% stron.
To nie znaczy, że każdą barierę wykryje automat. Narzędzie może zauważyć brak atrybutu, ale nie oceni, czy tekst alternatywny rzeczywiście opisuje istotną informację. Nie rozstrzygnie też, czy komunikat „Błąd” pozwala użytkownikowi zrozumieć, co poprawić.
WCAGbot Accessibility Path: droga do poziomu AA
| Obszar | Co sprawdzać w praktyce | Typowa naprawa źródłowa | Czy widget może wspierać użytkownika? |
|---|---|---|---|
| Kontrast | Tekst, ikony, obramowania, stany hover i fokus | Zmiana kolorów w systemie projektowym i CSS | Tak, przez dodatkowe tryby kontrastu |
| Formularze | Etykiety, instrukcje, błędy, kolejność fokusu | Poprawny HTML, powiązania label, komunikaty błędów | Częściowo, np. przez powiększenie tekstu |
| Klawiatura | Dostęp do każdego elementu, fokus, brak pułapek | Poprawa komponentów, obsługi zdarzeń i kolejności DOM | Nie zastępuje naprawy mechanizmu |
| Obrazy i ikony | Alt, nazwy przycisków ikonowych, dekoracyjność | Opis alternatywny lub właściwe oznaczenie dekoracji | Może ukryć obrazy, nie oceni ich znaczenia |
| Treść i struktura | Hierarchia nagłówków, linki, zrozumiały język | Redakcja treści i semantyczny HTML | Tak, przez czytanie treści i narzędzia typograficzne |
Jak wdrożyć poziom AA krok po kroku?
1. Ustal realny zakres usługi
Nie zaczynaj od losowej listy podstron. Wypisz wszystkie miejsca, w których użytkownik wykonuje działanie lub otrzymuje ważną informację: katalog, wyszukiwarkę, filtry, kartę produktu, koszyk, dostawę, płatność, rejestrację, logowanie, kontakt, dokumenty i komunikaty po zakupie.
Jeżeli korzystasz z Shopify, WordPressa lub systemu własnego, uwzględnij również szablony, wtyczki, aplikacje, iframe’y oraz integracje zewnętrzne. Platforma nie przenosi odpowiedzialności za dostępność każdego elementu na jej dostawcę. Warto sprawdzić osobno praktyczne wdrożenie sklepu Shopify.
2. Zrób inwentaryzację komponentów
Spisz komponenty, które pojawiają się wielokrotnie: przyciski, linki, pola formularzy, modale, menu, akordeony, zakładki, karuzele, filtry, tabele, powiadomienia i elementy przeciągane. Jeden błędny komponent może powielać barierę na dziesiątkach ekranów.
Dla każdego komponentu odpowiedz na pytania: czy ma poprawną nazwę? Czy jego rola wynika z HTML? Czy można go obsłużyć klawiaturą? Czy fokus jest widoczny? Czy czytnik ekranu otrzymuje informację o stanie i zmianie?
3. Projektuj dostępność przed implementacją
Ustal zasady dla kolorów, fokusu, nagłówków, ikon, błędów i stanów komponentów, zanim powstanie kod. Szczególną uwagę poświęć formularzom: błąd powinien wskazywać konkretne pole oraz sposób poprawy, a nie polegać wyłącznie na czerwonym kolorze.
Przy nowych elementach WCAG 2.2 sprawdź, czy użytkownik nie musi przeciągać elementu, aby wykonać zadanie, czy cel dotykowy nie jest zbyt mały oraz czy pasek stałej nawigacji nie zasłania fokusu. Pomocne będą materiały o fokusie niezasłoniętym i wyglądzie fokusu.
4. Napraw semantykę przed użyciem ARIA
Użyj natywnego elementu HTML, jeśli odpowiada funkcji interfejsu. Przycisk powinien być przyciskiem, link powinien prowadzić do zasobu, a pole formularza powinno mieć widoczną lub programowo dostępną etykietę. Nie zamieniaj przycisku na element div tylko dlatego, że łatwiej go ostylować.
ARIA jest potrzebna w części złożonych interfejsów, lecz nie służy do ukrywania problemów z semantyką. Zasada praktyczna brzmi: najpierw poprawny HTML, potem ARIA tylko wtedy, gdy natywne HTML nie opisuje wystarczająco zachowania komponentu. Szczegóły omawia poradnik ARIA: wdrożenie i testowanie oraz materiał o semantycznym HTML.
Co wykrywa skaner, a co wymaga testu manualnego
5. Testuj trzema metodami
Test automatyczny pomaga znaleźć powtarzalne problemy, takie jak część brakujących etykiet, atrybutów alt czy błędów ARIA. Test manualny sprawdza klawiaturę, fokus, zoom, reflow, modale, formularze i kolejność treści. Test z użytkownikami pokazuje, czy proces jest rzeczywiście zrozumiały i możliwy do wykonania w realnych warunkach.
W teście klawiaturą przejdź od początku do końca ścieżki zakupowej tylko klawiszami Tab, Shift+Tab, Enter, Spacja i strzałkami tam, gdzie są potrzebne. Nie pomijaj stanu błędu, kodu rabatowego, wyboru dostawy oraz powrotu z bramki płatniczej. Zobacz też checklistę testów po wdrożeniu i poradnik testowania z NVDA.
WCAGbot Accessibility Path: gdzie w procesie jest widget?
WCAGbot Accessibility Path porządkuje działania w kolejności, która nie myli wsparcia użytkownika z pełnym wdrożeniem dostępności:
- Ustal zakres — określ strony, procesy i komponenty istotne dla użytkownika.
- Wykryj bariery — wykonaj audyt, test automatyczny i testy manualne.
- Dodaj wsparcie od razu — uruchom WCAGbot jedną linią kodu, aby udostępnić użytkownikom m.in. tryby kontrastu, powiększenie tekstu, czytanie treści, lupę, większy kursor i profile dostępności.
- Napraw źródło problemu — popraw kod, projekt, treści oraz integracje zewnętrzne.
- Potwierdź działanie — testuj po poprawkach, również na urządzeniach mobilnych.
- Utrzymuj standard — włącz kontrolę dostępności do procesu publikacji i QA.
WCAGbot może automatycznie uzupełniać wybrane wykrywalne atrybuty ARIA, alt i title, jednak mechanizm automatyczny nie zna pełnego kontekstu biznesowego grafiki, formularza ani procesu. Dlatego wynik trzeba kontrolować, a kluczowe bariery usuwać źródłowo.
Mini-scenariusz: koszyk działa myszą, ale nie klawiaturą
Scenariusz ilustracyjny: sklep internetowy ma wysuwaną szufladę koszyka. Po dodaniu produktu użytkownik widzi komunikat wizualny, ale fokus pozostaje na przycisku „Dodaj do koszyka” w tle. Osoba korzystająca z klawiatury naciska Tab i przechodzi do elementów znajdujących się pod otwartą szufladą. Nie ma jasnej informacji, że produkt został dodany, ani prostego sposobu przejścia do koszyka.
Naprawa: po otwarciu szuflady należy przenieść fokus do jej sensownego początku, ograniczyć tabulację do aktywnego modala lub panelu, zapewnić działający przycisk zamknięcia, przekazać komunikat statusu technologii asystującej oraz po zamknięciu przywrócić fokus w logiczne miejsce. Sam tryb wysokiego kontrastu lub większy kursor mogą ułatwić część obsługi, ale nie naprawią błędnego zarządzania fokusem.
Takie przypadki należy weryfikować również na etapie płatności. Przeczytaj poradnik o dostępności płatności online, ponieważ zewnętrzna bramka może być osobnym elementem ścieżki użytkownika.
Jakie błędy najczęściej zatrzymują wdrożenie AA?
- „Skaner nie znalazł błędów, więc wszystko jest dostępne”. Brak wykrytych problemów nie potwierdza zgodności ani użyteczności.
- „Wystarczy dodać ARIA”. ARIA nie zastępuje poprawnej struktury HTML, nazw komponentów ani obsługi klawiaturą.
- „Skupimy się na stronie głównej”. Użytkownik musi ukończyć cały proces, a nie tylko przeczytać pierwszy ekran.
- „Kontrast poprawimy później”. Kontrast dotyczy nie tylko tekstu, lecz także ikon, stanów fokusu i elementów formularzy.
- „Widget zapewnia zgodność”. Widget może wspierać użytkownika, ale nie gwarantuje pełnej zgodności z WCAG, EN 301 549 ani PAD.
- „Po audycie temat jest zamknięty”. Nowe kampanie, treści, wtyczki i zmiany w checkout mogą wprowadzić regresje.
Dostępny formularz zamówienia
Podsumowanie dla zarządzającego i sprzedaży
Poziom AA WCAG jest praktycznym celem organizacyjnym i technicznym, gdy firma chce ograniczać bariery w usłudze cyfrowej. Najrozsądniejsza kolejność to: ustalić zakres, naprawić podstawowe błędy o największym wpływie, przetestować pełne ścieżki użytkownika i zaplanować stałe utrzymanie.
WCAGbot może być szybkim pierwszym krokiem, ponieważ po instalacji jedną linią kodu udostępnia funkcje wspierające dostępność bez przebudowy strony. Nie zastępuje jednak audytu WCAG, testów z użytkownikami ani trwałego usuwania problemów w kodzie i treści.
Chcesz zacząć praktycznie? Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot na formularzu, koszyku lub stronie produktu. Następnie zaplanuj audyt oraz naprawy źródłowe dla wykrytych barier.
FAQ: poziom AA WCAG
Czy poziom AA obejmuje również kryteria poziomu A?
Tak. Zgodność na poziomie AA wymaga spełnienia wszystkich kryteriów sukcesu poziomu A oraz AA, które mają zastosowanie do ocenianej treści lub funkcji.
Czy WCAG 2.2 AA oznacza, że strona będzie wygodna dla każdej osoby?
Nie. WCAG pomaga usuwać określone bariery, ale nie gwarantuje idealnego doświadczenia dla każdej osoby, każdego urządzenia i każdej technologii asystującej. Dlatego potrzebne są także testy użyteczności z różnymi użytkownikami.
Czy automatyczny skaner potwierdza zgodność z WCAG AA?
Nie. Skaner wykrywa część problemów technicznych, ale nie oceni wielu kwestii wymagających kontekstu, takich jak jakość opisu alternatywnego, sens nagłówków, logika procesu czy zrozumiałość błędów.
Czy widget dostępności zapewnia poziom AA?
Nie. Widget dostępności może wspierać użytkowników funkcjami takimi jak kontrast, powiększenie tekstu czy czytanie treści. Nie zastępuje jednak audytu, testów ani naprawy kodu i treści wymaganej do oceny zgodności.
Czy trzeba testować całą stronę?
Ocena zgodności dotyczy pełnych stron i istotnych procesów. W praktyce warto badać reprezentatywne szablony oraz wszystkie kluczowe ścieżki, w tym zakup, rejestrację, logowanie, formularze i płatność.
Jak sprawdzić, czy formularz spełnia podstawowe wymagania AA?
Każde pole powinno mieć etykietę, instrukcje powinny być jasne, błędy muszą być przekazane tekstowo, a formularz powinien działać klawiaturą. Należy również sprawdzić, czy fokus prowadzi użytkownika w logicznej kolejności.
Czy ARIA jest wymagana do osiągnięcia AA?
Nie zawsze. W wielu przypadkach wystarczy semantyczny HTML. ARIA stosuje się wtedy, gdy natywne elementy HTML nie wystarczają do przekazania roli, stanu lub zachowania złożonego komponentu.
Czy kontrast dotyczy tylko zwykłego tekstu?
Nie. W zależności od kryterium i rodzaju elementu może dotyczyć także ikon, obramowań, wskaźników fokusu oraz elementów interfejsu niebędących tekstem. Osobno warto sprawdzić kontrast elementów nietekstowych.
Czy sklep internetowy powinien testować dostępność płatności?
Tak. Płatność jest częścią krytycznej ścieżki użytkownika. Należy sprawdzić przejście do bramki, obsługę błędów, powrót do sklepu oraz komunikat potwierdzający wynik transakcji.
Jak często powtarzać testy dostępności?
Po każdej istotnej zmianie interfejsu, formularza, systemu projektowego, checkoutu, integracji zewnętrznej lub publikacji nowego szablonu. Warto także wykonywać okresowe testy regresji dla najważniejszych procesów.
