Checklista WCAG 2.2 AA dla produktów SaaS i aplikacji internetowych

Produkt SaaS ma dwa obszary, w których liczy się dostępność: witrynę marketingową, która go sprzedaje, i aplikację, z której ludzie korzystają na co dzień. Witryna marketingowa zawodzi w ten sam sposób co każda strona: niski kontrast, brak tekstów alternatywnych i formularze bez etykiet. Aplikacja dokłada własne problemy: logowanie, które blokuje menedżery haseł, okna dialogowe, które więżą fokus klawiatury, nawigację w aplikacji jednostronicowej, której czytniki ekranu nie zauważają, tabele danych i wykresy bez tekstu, przeciąganie i upuszczanie bez alternatywy oraz sesje, które wygasają bez ostrzeżenia. Ta checklista omawia WCAG 2.2 na poziomie AA według części typowego produktu SaaS.

Najważniejsze informacje

• WCAG 2.2 uzyskały status rekomendacji W3C w październiku 2023 roku i dodały dziewięć kryteriów sukcesu, z czego sześć na poziomie A lub AA (W3C (otwiera się w nowej karcie)).
• Kryterium Accessible Authentication (3.3.8, AA) oznacza, że logowanie nie może zależeć od zapamiętania lub przepisania hasła, chyba że można je wkleić lub użyć menedżera haseł (W3C (otwiera się w nowej karcie)).
• Interaktywne cele muszą mieć co najmniej 24 na 24 piksele CSS albo wystarczająco dużo wolnego miejsca wokół siebie (2.5.8, AA) (W3C (otwiera się w nowej karcie)).
• Komunikaty takie jak „Zapisano” czy „3 wyniki” muszą docierać do czytników ekranu bez przenoszenia fokusu (4.1.3, AA) (W3C (otwiera się w nowej karcie)).
• Klienci biznesowi i z sektora publicznego często proszą o raport zgodności dostępności (Accessibility Conformance Report, ACR), zwykle sporządzony na szablonie VPAT organizacji Information Technology Industry Council (ITI (otwiera się w nowej karcie)).

Dlaczego dostępność jest ważniejsza w SaaS niż na stronie wizytówce?

Z produktu SaaS ludzie korzystają godzinami, często dlatego, że wybrał go ich pracodawca. Bariera na stronie marketingowej kosztuje Cię jednego odwiedzającego; bariera w produkcie może uniemożliwić komuś wykonywanie pracy. Dlatego więksi klienci, uczelnie i instytucje publiczne coraz częściej pytają o dostępność przed zakupem i dlatego odpowiedź musi obejmować aplikację, a nie tylko stronę internetową.

Ma to znaczenie także dlatego, że testy automatyczne wychwytują tylko część problemu. Narzędzia takie jak axe-core znajdują błędy w kodzie, na przykład brakujące etykiety i niski kontrast. Nie powiedzą jednak, czy okno dialogowe zwraca fokus we właściwe miejsce, czy dane z wykresu są dostępne jako tekst ani czy dany proces da się przejść za pomocą klawiatury. Aplikacja potrzebuje zarówno testów automatycznych, jak i ręcznych.

Jak zapewnić dostępność rejestracji i logowania?

To w obszarze uwierzytelniania WCAG 2.2 dodały najważniejszy nowy wymóg dla SaaS.

• Pozwól na wklejanie i menedżery haseł (3.3.8, AA). Nie blokuj wklejania do pól hasła ani kodu i używaj autocomplete="username", autocomplete="current-password" oraz autocomplete="one-time-code", aby przeglądarki i menedżery haseł mogły je wypełniać.
• Nie stosuj łamigłówek jako jedynej drogi wejścia. CAPTCHA, która każe przepisać zniekształcony tekst lub rozwiązać łamigłówkę, jest testem funkcji poznawczych. Zapewnij alternatywę i wybieraj zabezpieczenia, które nie wymagają działania użytkownika (W3C (otwiera się w nowej karcie)).
• Opisz etykietą każde pole (1.3.1 i 3.3.2, A). Używaj widocznego elementu <label> powiązanego z polem; tekst zastępczy znika, gdy ktoś zaczyna pisać, i nie jest etykietą.
• Opisuj błędy tekstem (3.3.1, A) i podpowiadaj poprawki (3.3.3, AA). „Hasło musi mieć co najmniej 12 znaków” pomaga; sama czerwona ramka nie.
• Nie pytaj dwa razy (3.3.7, A). Jeśli wieloetapowa rejestracja już poprosiła o nazwę firmy lub adres, uzupełnij je automatycznie albo pozwól je wybrać zamiast wpisywać ponownie.
• Trzymaj pomoc w tym samym miejscu (3.2.6, A). Jeśli oferujesz czat, link do pomocy lub dane kontaktowe, umieść je w tym samym względnym położeniu na każdej stronie procesu.

Które wzorce formularzy i błędów powodują najwięcej problemów?

W formularzach kryje się większość błędów aplikacji. Badanie WebAIM z 2026 roku, obejmujące milion stron głównych, wykazało brak etykiet formularzy na 51% z nich (WebAIM (otwiera się w nowej karcie)), a aplikacje mają znacznie więcej formularzy niż strony główne.

• Nadaj każdemu polu nazwę dostępną programowo i grupuj powiązane elementy sterujące, takie jak przyciski radiowe, za pomocą <fieldset> i <legend>.
• Informuj o błędach tam, gdzie zostaną zauważone: przenieś fokus do podsumowania błędów na górze formularza lub do pierwszego nieprawidłowego pola i połącz każdą pozycję podsumowania z jej polem.
• Oznaczaj pola wymagane tekstem, a nie samym kolorem (1.4.1, A).
• Nie wysyłaj formularza ani nie zmieniaj kontekstu, gdy ktoś tylko wybierze opcję (3.2.2, A); poczekaj na wyraźne działanie użytkownika.

Jak powinny działać okna dialogowe, menu i wyskakujące panele?

W komponentach niestandardowych obsługa klawiatury i czytników ekranu psuje się najczęściej. Przewodnik WAI-ARIA Authoring Practices Guide opisuje oczekiwane zachowanie każdego wzorca (W3C (otwiera się w nowej karcie)).

• Okna dialogowe: po otwarciu przenieś fokus do okna, utrzymuj klawisz Tab wewnątrz niego, dopóki jest otwarte, zamykaj je klawiszem Escape i zwracaj fokus do elementu, który je otworzył. Używaj natywnego elementu <dialog> lub role="dialog" z aria-modal="true" i nazwą.
• Brak pułapek klawiaturowych (2.1.2, A): z każdego komponentu musi dać się wyjść za pomocą klawiatury.
• Widoczny fokus (2.4.7, AA), który nie jest ukryty za przyklejonymi nagłówkami, banerami cookie ani widżetami czatu (2.4.11, AA, nowość w wersji 2.2).
• Podpowiedzi i wyskakujące panele (1.4.13, AA), które można zamknąć klawiszem Escape, nad którymi można przesunąć kursor bez ich znikania i które pozostają widoczne do czasu zamknięcia.
• Skróty jednoklawiszowe (2.1.4, A): jeśli naciśnięcie klawisza litery uruchamia działanie, pozwól wyłączyć skróty lub zmienić ich przypisanie albo uaktywniaj je tylko wtedy, gdy fokus jest na odpowiednim komponencie.

Jak obsłużyć nawigację w aplikacji jednostronicowej?

W aplikacji jednostronicowej (SPA) adres URL zmienia się bez wczytania strony, więc czytniki ekranu mogą nie ogłosić, że cokolwiek się wydarzyło.

• Aktualizuj tytuł dokumentu przy każdej zmianie trasy, aby każdy widok miał opisowy tytuł (2.4.2, A).
• Przenieś fokus na główny nagłówek nowego widoku albo ogłoś zmianę w regionie aktywnym typu polite; frameworki takie jak Next.js mają do tego wbudowany mechanizm ogłaszania zmian tras (route announcer).
• Zachowaj logiczną kolejność fokusu (2.4.3, A): po usunięciu pozycji fokus powinien trafić na sensowny sąsiedni element, a nie wrócić na początek strony.
• Zapewnij możliwość pominięcia powtarzającej się nawigacji (2.4.1, A), na przykład link pomijający lub regiony strony (landmarki).

Jak zapewnić dostępność pulpitów, tabel danych i wykresów?

• Tabele: używaj prawdziwego kodu <table> z <th> i scope dla nagłówków oraz podpisu tabeli (1.3.1, A). Siatki zbudowane z elementów <div> wymagają pełnego wzorca ARIA grid, który znacznie trudniej poprawnie wdrożyć.
• Wykresy: nadaj każdemu wykresowi alternatywę tekstową, która podaje główny wniosek, i udostępnij dane w postaci tabeli (1.1.1, A). Nie polegaj wyłącznie na kolorze przy rozróżnianiu serii danych (1.4.1, A); dodaj etykiety lub wzory.
• Kontrast: tekst wymaga 4.5:1 (1.4.3, AA), a linie wykresów, ikony i obramowania pól wymagają 3:1 względem tła (1.4.11, AA). Tryb ciemny sprawdź osobno. Nasz test kontrastu kolorów sprawdza dowolną parę kolorów.
• Komunikaty o stanie (4.1.3, AA): „Zapisano”, „Przesyłanie zakończone” i liczby wyników powinny używać role="status" lub regionu aktywnego, aby czytniki ekranu je ogłaszały, a użytkownik nie tracił miejsca, w którym jest.

Co nowe kryteria WCAG 2.2 zmieniają w aplikacjach internetowych?

WCAG 2.2 usunęły też kryterium 4.1.1 Parsing, które nie ma już praktycznego wpływu na dostępność (W3C (otwiera się w nowej karcie)).

A co z limitami czasu, układem i powiększaniem?

• Limity czasu sesji (2.2.1, A): ostrzegaj przed wygaśnięciem sesji i pozwól ją przedłużyć prostym działaniem, chyba że limit czasu jest niezbędny lub dłuższy niż 20 godzin. Zapisywanie postępów pracy chroni przed najgorszym scenariuszem.
• Dopasowanie do szerokości (1.4.10, AA): treść musi działać przy szerokości 320 pikseli CSS (co odpowiada powiększeniu do 400% na ekranie o szerokości 1280 pikseli) bez przewijania w dwóch kierunkach; tabele danych i podobne treści są z tego zwolnione.
• Odstępy w tekście (1.4.12, AA): zwiększenie interlinii i odstępów między literami nie powinno ucinać tekstu, co często zdarza się w kontenerach o stałej wysokości.
• Orientacja (1.3.4, AA): nie blokuj aplikacji w orientacji pionowej ani poziomej, chyba że jest to niezbędne.

Czym jest ACR i czy go potrzebujesz?

Raport zgodności dostępności (Accessibility Conformance Report, ACR) dokumentuje, jak produkt spełnia każde kryterium dostępności: obsługuje, częściowo obsługuje lub nie obsługuje, wraz z uwagami. Większość takich raportów powstaje na szablonie VPAT publikowanym przez Information Technology Industry Council, który ma wersje dla WCAG, amerykańskich standardów Section 508 i europejskiej normy EN 301 549 (ITI (otwiera się w nowej karcie)).

Federalne agencje USA muszą kupować dostępne technologie zgodnie z Section 508 (Section508.gov (otwiera się w nowej karcie)), a instytucje publiczne w UE odwołują się do normy EN 301 549, dlatego od produktów B2B sprzedawanych takim klientom często wymaga się ACR w procesie zakupowym. Rzetelny ACR, w którym wymieniono znane braki, jest dla kupujących bardziej użyteczny niż raport deklarujący pełną obsługę. Powinien opierać się na testach produktu, w tym ręcznych; sam automatyczny skan nie wystarczy, by go wypełnić.

Jeśli sprzedajesz konsumentom w UE, Europejski Akt o Dostępności może dotyczyć także sposobu, w jaki sprzedajesz online; nasz przewodnik po EAA wyjaśnia jego zakres. To nie jest porada prawna.

Jak zespół SaaS powinien testować dostępność?

1. Zautomatyzuj podstawy. Uruchamiaj axe-core lub podobny silnik w testach end-to-end i na witrynie marketingowej, a nowe naruszenia niech powodują niepowodzenie kompilacji. Nasz darmowy test dostępności uruchamia ten sam silnik na dowolnej publicznej stronie.
2. Testuj za pomocą klawiatury. Przejdź główne procesy, takie jak rejestracja, tworzenie rekordu i zmiana ustawień, używając wyłącznie klawiszy Tab, Shift+Tab, Enter, spacji, Escape i strzałek.
3. Testuj z czytnikiem ekranu. NVDA w systemie Windows oraz VoiceOver w systemach macOS i iOS są bezpłatne. Sprawdź, czy nazwy, role, stany i komunikaty są ogłaszane.
4. Powiększaj i zmieniaj rozmiar okna. Sprawdź powiększenie tekstu do 200% i okno o szerokości 320 pikseli.
5. Poprawiaj w systemie projektowym. Większość błędów pochodzi ze wspólnych komponentów; poprawka przycisku lub okna dialogowego w jednym miejscu naprawia go wszędzie.

Najczęściej zadawane pytania

Czy WCAG dotyczą części aplikacji internetowej dostępnych po zalogowaniu?

WCAG dotyczą wszelkich treści internetowych, w tym stron za logowaniem. To, czy prawo wymaga od konkretnego produktu ich spełnienia, zależy od jurysdykcji i klienta, ale kupujący, którzy pytają o dostępność, zwykle mają na myśli cały produkt.

Czy nakładka dostępności może sprawić, że produkt SaaS będzie dostępny?

Nie. Nakładki nie zmieniają kodu komponentów niestandardowych, a to w nich kryją się błędy aplikacji. Nasz przewodnik o nakładkach dostępności opisuje działania FTC wobec czołowego dostawcy nakładek.

Jaką część WCAG mogą sprawdzić narzędzia automatyczne?

Tylko część. Reguły automatyczne niezawodnie znajdują brakujące nazwy, etykiety i błędy kontrastu, ale wiele kryteriów, takich jak sensowna kolejność fokusu, przydatny tekst alternatywny i zrozumiałe komunikaty o błędach, wymaga oceny człowieka.

Którą wersję WCAG przyjąć za cel?

Aktualna wersja to WCAG 2.2 na poziomie AA. Wiele przepisów i zasad zamówień wciąż odwołuje się do WCAG 2.1 AA; spełnienie 2.2 AA oznacza też spełnienie 2.1 AA, z wyjątkiem usuniętego kryterium Parsing.

Czy musimy spełnić poziom AAA?

W3C nie zaleca wymagania poziomu AAA dla całych produktów, ponieważ niektóre treści nie mogą spełnić wszystkich kryteriów AAA. Typowym celem jest poziom AA.

Źródła

• W3C: What's new in WCAG 2.2 (otwiera się w nowej karcie)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (otwiera się w nowej karcie)
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum) (otwiera się w nowej karcie)
• W3C: Understanding 2.5.8 Target Size (Minimum) (otwiera się w nowej karcie)
• W3C: Understanding 4.1.3 Status Messages (otwiera się w nowej karcie)
• W3C: ARIA Authoring Practices Guide: Dialog (modal) pattern (otwiera się w nowej karcie)
• W3C: Inaccessibility of CAPTCHA (otwiera się w nowej karcie)
• ITI: Voluntary Product Accessibility Template (VPAT) (otwiera się w nowej karcie)
• GSA: Section508.gov (otwiera się w nowej karcie)
• WebAIM: The WebAIM Million (2026) (otwiera się w nowej karcie)