Audyt WCAG: audyt dostępności i poprawki w kodzie

W Centrum Komunikacji, aplikacji do komunikacji dla osób głuchych i niewidomych, VoiceOver mógł przejść z okna dialogowego z 4 kontrolkami na 25 kontrolek ukrytych za nim. Naprawiliśmy to w kodzie komponentu React Native. Tak wygląda u nas praca nad dostępnością: projektanci, frontend developerzy i QA, którzy audytują Twój produkt, potem sami zmieniają komponenty w React, React Native albo Django.

Testujemy strony internetowe i natywne aplikacje mobilne. Na iOS i Androidzie czytnik ekranu korzysta z natywnych widoków, więc poprawka często trafia do komponentu React Native, a nie do HTML-a.

Raport z listą błędów to dopiero początek, bo ktoś jeszcze musi je naprawić. Czym jest audyt i co zawiera raport, wyjaśniamy w haśle słownika audyt dostępności.

W październiku 2026 r. przeprowadziliśmy audyt naszej strony według WCAG 2.2 AA i wdrożyliśmy poprawki. Strona jest nadal częściowo zgodna, między innymi dlatego, że 7 z 10 naszych filmów na YouTube ma tylko automatyczne napisy.

Audyt WCAG zamawiają zwykle firmy objęte Europejskim aktem o dostępności, podmioty publiczne, wykonawcy w przetargach publicznych i zespoły produktowe, które muszą wykazać, że ich strona lub aplikacja spełnia WCAG. Te wymagania wynikają z przepisów:

• Europejski akt o dostępności, dyrektywa (UE) 2019/882, od 28 czerwca 2025 r. obejmuje wybrane produkty i usługi cyfrowe, m.in. bankowość, e-commerce i e-booki.
• W Polsce dyrektywę wdraża ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731).
• Podmioty publiczne obowiązuje ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (tekst jednolity Dz.U. 2023 poz. 1440). Wymaga ona dostępnych stron i aplikacji oraz opublikowanej deklaracji dostępności.
• Art. 100 Prawa zamówień publicznych wymaga, żeby opis przedmiotu zamówienia (OPZ) uwzględniał wymagania dostępności dla osób z niepełnosprawnościami, gdy z systemu będą korzystać ludzie. Dlatego WCAG trafia do OPZ i umów.

Czy Europejski akt o dostępności (EAA) obejmuje Twoją usługę, oceni prawnik. My sprawdzimy produkt pod kątem WCAG i poprawimy to, co nie spełnia wymagań.

Wdrożenie poprawek dostępności to zmiany w komponentach, etykietach, komunikatach i stylach, aż każde kryterium, które nie przeszło testu, zostanie spełnione. Oto poprawki z projektów naszych klientów:

• W aplikacji Centrum Komunikacji VoiceOver mógł przejść z okna dialogowego z 4 własnymi kontrolkami na 25 kontrolek ukrytych za nim. Przyczyną była właściwość accessibilityViewIsModal w React Native, która nie docierała do natywnego widoku. Zmieniliśmy styl prezentacji na fullScreen i usunęliśmy martwą właściwość z 3 komponentów (sierpień 2026). To problem z zarządzaniem fokusem, którego skaner stron nie zobaczy.
• Dla PSONI prowadzimy arkusz wszystkich etykiet ARIA w aplikacji webowej i mobilnej. Ten sam arkusz służy jako katalog komunikatów błędów i statusów.
• Aplikacja PSONI ma 3 rozmiary czcionki: 100%, 150% i 200%, co pokrywa powiększenie 200% z kryterium 1.4.4. Użytkownik wybiera też głos męski lub żeński i tempo czytania w module zamiany tekstu na mowę.
• Poprawiliśmy kontrast elementów, takich jak podkreślenie czytanego na głos słowa w module zamiany tekstu na mowę, i zrobiliśmy retest na stagingu.
• Gdy tekst przekraczał limit znaków, przycisk po prostu szarzał, bez żadnego wyjaśnienia. Dodaliśmy komunikat walidacji, a retest we wrześniu 2026 r. wypadł pomyślnie.

Dostępność zaczyna się też przed kodem. Specyfikacja PSONI wymaga widocznej etykiety tekstowej przy każdej ikonie, zgodnie z kryterium WCAG 1.1.1 i wytycznymi W3C dla osób z trudnościami poznawczymi. Takie wymaganie trzeba spełnić w projekcie interfejsu, zanim powstanie kod. To zadanie dla projektowania UX.

Testujemy dostępność w projektach dla ludzi, którzy na co dzień jej potrzebują.

Centrum Komunikacji: WCAG 2.1 AA, czytniki ekranu i monitory brajlowskie

Centrum Komunikacji to aplikacja mobilna i webowa dla osób głuchych, słabosłyszących, niewidomych i głuchoniewidomych. Wymaganiem była zgodność z WCAG 2.1 AA oraz z czytnikami ekranu i monitorami brajlowskimi. Testujemy z czytnikami ekranu przez cały projekt, od listopada 2025 r., a raport WCAG nasz zespół przygotował do odbioru etapu 2, zakończonego 27 kwietnia 2026 r.

We wrześniu 2026 r. niewidomy ekspert dostępności, który współpracuje z klientem, przetestował produkcyjną aplikację na iOS i Androidzie. Na kafelkach usług czytnik odczytywał tylko wspólny tekst przycisku, więc użytkownik nie mógł ich odróżnić. Zmieniliśmy etykiety i zrobiliśmy retest na obu platformach.

PSONI: Generator ETR według WCAG 2.2 AAA

Dla PSONI (Polskiego Stowarzyszenia na rzecz Osób z Niepełnosprawnością Intelektualną) budujemy Generator ETR, aplikację webową i mobilną, która przekształca dokumenty w tekst łatwy do czytania. Specyfikacja wymaga WCAG 2.2 na poziomie AAA.

Webowa runda testów z czytnikiem ekranu zakończyła się 6 października 2026 r., a jej wyniki trafiły do osobnego zadania z poprawkami. Runda mobilna z TalkBack i VoiceOver trwała w październiku 2026 r. Testy z czytnikiem wykryły komunikaty błędów, których czytnik nie odczytywał, licznik ponownego wysłania kodu odczytywany co 5 sekund i fokus przeskakujący na przycisk zamknięcia zamiast na treść dokumentu.

Kto prowadzi prace

Daria Gusieva jest Head of Design w Order Group od marca 2026 r. Prowadzi UX, UI i dostępność według WCAG w projektach klientów, a w naszym słowniku recenzuje hasła o WCAG 2.2, audycie dostępności, testach z czytnikiem ekranu i zarządzaniu fokusem.

10 października 2026 r. przeprowadziliśmy audyt ordergroup.co według WCAG 2.2 AA: 48 adresów EN i PL, 55 kryteriów, axe-core i testy ręczne.

Przed poprawkami skaner axe znalazł 6 naruszeń. Testy ręczne i skrypty wykryły problemy, których axe nie sprawdza: pomiar kontrastu piksel po pikselu wykazał 29 elementów tekstu na zdjęciach z kontrastem poniżej progu na 10 stronach, test odstępów tekstu 5 miejsc z uciętym tekstem, a test klawiatury 2 komponenty z niewidocznym fokusem.

Naprawiliśmy te problemy w kodzie i wdrożyliśmy poprawki na produkcji. Skaner axe nie zgłasza teraz żadnych naruszeń, a spośród 2140 zmierzonych elementów tekstu na zdjęciach żaden nie ma kontrastu poniżej progu.

Mimo to nasz wynik to nadal częściowa zgodność. Tylko automatyczne napisy ma 7 z 10 naszych filmów na YouTube (kryterium 1.2.2), a test z czytnikiem ekranu i ocena audiodeskrypcji wciąż przed nami. Napisy to treść, nie kod: na naszej stronie musimy je dodać sami, a na stronie klienta robi to właściciel treści.