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

<https://www.fixreports.com/pl/blog/wcag-2-2-checklist-saas-web-apps>

Zaktualizowano 2026-10-26

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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- 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](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- 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](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Komunikaty takie jak „Zapisano” czy „3 wyniki” muszą docierać do czytników ekranu bez przenoszenia fokusu (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- 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](https://www.itic.org/policy/accessibility/vpat)).

## 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](https://www.w3.org/TR/turingtest/)).
- **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](https://webaim.org/projects/million/)), 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](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **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](/pl/color-contrast-checker) 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?

| Kryterium | Poziom | Co oznacza w aplikacji |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Przyklejone paski narzędzi, banery i widżety czatu nie mogą całkowicie zasłaniać elementu z fokusem |
| 2.5.7 Dragging Movements | AA | Wszystko, co wykonuje się przeciąganiem, na przykład zmiana kolejności na tablicy kanban, wymaga alternatywy obsługiwanej pojedynczym wskaźnikiem, na przykład menu lub przycisków w górę i w dół |
| 2.5.8 Target Size (Minimum) | AA | Przyciski i linki mają co najmniej 24 × 24 piksele CSS albo są rozmieszczone tak, że okrąg o średnicy 24 pikseli wokół każdego z nich nie nachodzi na inny |
| 3.2.6 Consistent Help | A | Linki do pomocy, czat i dane kontaktowe znajdują się w tym samym względnym miejscu na każdej stronie |
| 3.3.7 Redundant Entry | A | Informacje wpisane już w tym samym procesie są uzupełniane automatycznie lub dostępne do wyboru |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logowanie bez zapamiętywania i przepisywania, chyba że dozwolone jest wklejanie, menedżery haseł lub inna metoda |

WCAG 2.2 usunęły też kryterium 4.1.1 Parsing, które nie ma już praktycznego wpływu na dostępność ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## 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](https://www.itic.org/policy/accessibility/vpat)).

Federalne agencje USA muszą kupować dostępne technologie zgodnie z Section 508 ([Section508.gov](https://www.section508.gov/)), 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](/pl/blog/european-accessibility-act-online-stores) 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](/pl/website-accessibility-checker) 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](/pl/blog/accessibility-overlays-ftc-order) 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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)