Case Study (2025)

Projektowanie dostępnych aplikacji, czyli praktyczne o WCAG 2.2

Choć WCAG kojarzone jest z ułatwieniami dla osób z ograniczeniami w rzeczywistości obejmuje znacznie szerszy kontekst. Dostępność cyfrowa to tworzenie treści w sposób uniwersalny i przewidywalny. W praktyce oznacza to tworzenie środowiska przyjaznego dla AI i LLM.

0 mc

Zakres czasu

0+

Znalezionych błędów

0%

Pokrycie

WCAG (Web Content Accessibility Guidelines) to zbiór wytycznych, które pomagają tworzyć strony i aplikacje dostępne dla szerokiego spektrum użytkowników. Oficjalnie dla osób z niepełnosprawnościami w rzeczywistości jest to tworzenie globlanie przyjaznego środowiska dla AI i LLM.

Współcześnie standard WCAG dotyczy to niemal wszystkich aplikacji podlegających walidacji jakości. Dobrą praktyką jest uwzglednienie dostepności cyfrowej juz na etapie projektowania wireframe'ów i makiet przez UX/UI Designera, a nastepnie dodanie WCAG do konwencji programistycznych (czyli zbioru ustaleń dotyczących stylu kodu, struktury plików i tak dalej) oraz zasad obowiązujących w projekcie, na których mogą oprzeć się testerzy odpowiedzialni za kontrole jakości. W rezultacie umożliwi to wcześniejsze wychwycenie błędów.

WCAG bez iluzji

Dobro najsłabszych czy infrastruktura dla maszyn?

Patrząc na te wszystkie dekady marginalizowania osób z niepełnosprawnością (rządy patrzą na niepełnosprawność jako wydatek, korporacje z kolei nie mają na szczycie listy konsumenta z niepełnosprawnością), można zadać sobie pytanie, co się zmieniło od 2018, że tyle miliardów zaczyna być pompowane w tzw. dostępność cyfrową?

Kiedy spoglądamy na liczby, napięcie rośnie. Z grubsza licząc, około 84% ludzi na świecie korzysta dziś z internetu. Wśród nich przeważają użytkownicy sprawni, około 81% całej populacji, a osoby z niepełnosprawnościami stanowią około 3% ogółu, które aktywnie z sieci korzystają. Około 16% populacji wciąż jest offline. Te proporcje prowokują pytanie: skoro odsetek osób, które wprost potrzebują czytników ekranu, alternatywnych nawigacji czy specjalnych kontrastów, jest tak niewielki, to skąd te astronomiczne budżety na dostępność, przepisy w sejmach, przekształcenia procesów i narzędzi w firmach na całym świecie? Łatwo byłoby odpowiedzieć: bo tak trzeba, bo wyrównujemy wielowiekowe zaniedbania, bo cyfrowa przestrzeń publiczna powinna być dla wszystkich. I to jest prawda, ale być może nie cała prawda.

Równolegle dzieje się coś innego: sieć staje się środowiskiem nie tylko dla ludzi, lecz także dla maszyn, dla IA inteligentnych asystentów, modeli, systemów, które czytają, parsują, łączą kropki i wykonują pracę, o jakiej jeszcze wczoraj myśleliśmy, że jest 'ludzka'. A co to znaczy 'dostępność' z perspektywy maszyny? To znaczy, że treść jest ustrukturyzowana, przewidywalna, semantyczna, opatrzona alternatywą tekstową, z logiczną kolejnością fokusu i odpowiednimi stanami interfejsu.

Jeśli obrazek ma alt-tekst, to zyskuje osoba niewidoma i jednocześnie zyskuje model, który bez wizji komputerowej potrafi wnioskować o treści. Jeśli formularz ma poprawną strukturę, kolejność i walidację, to lepiej radzi sobie użytkownik z klawiaturą i bot, który potrafi go wypełnić, przetestować, zautomatyzować. Jeśli nagłówki są semantyczne, to nawigacja skrótami działa szybciej i parser rozdziały rozumie bez zgadywania. Dostępność to nie tylko empatia zakodowana w stylach i atrybutach: to też protokół porozumienia między człowiekiem a maszyną.

Być może dlatego tak wiele państw przyjmuje przepisy, które 'przypadkiem' standaryzują internet na poziomie, jakiego nigdy nie wymusiły same rynkowe siły. Bo kiedy każesz tysiącom instytucji, urzędów i korporacji doprowadzić interfejsy do ładu według WCAG, to równocześnie karmisz IA treściami jakościowymi: przewidywalnymi, uczciwie opisanymi, możliwymi do przeszukiwania, przetwarzania i automatyzacji. Robiąc coś bezdyskusyjnie dobrego dla grup przez dekady marginalizowanych, budujesz też infrastrukturę, na której IA może stać się użyteczna nie w laboratorium, ale w codziennym życiu: w banku, w szpitalu, w szkole, w e-administracji.

W3C, z rodowodem CERN-MIT i wsparciem Komisji Europejskiej oraz DARPA, od zawsze grało w długą grę: zapisujemy zasady tak, by jutro dało się nimi zbudować coś, czego dziś jeszcze nie umiemy nazwać. Wielkie firmy chętnie tu zasiadają, bo lepiej negocjować przyszłość przy stole standardów, niż budować równoległe wszechświaty. A ustawodawcy chętnie cytują WCAG i kuzynów, bo to język, na który zgadza się przemysł i obywatele. Tak klika się mechanizm, w którym moralny nakaz inkluzywności spotyka się z ekonomią skali i marzeniem o automatyzacji. I jeśli ktoś pyta, z czego powstaje czerwny dywan, po którym wkroczy IA, odpowiedź brzmi: z drobnych, żmudnych decyzji o aria-label, kontrastach 4.5:1, logicznych nagłówkach i sensownych komunikatach błędów. Z pracy, która wygląda jak koszt dla 3%, a w praktyce otwiera drzwi dla 100%

Po latach marginalizacji, osobą z niepełnosprawnościami należy się internet, który działa bez kompromisów. Ale może właśnie w tym tkwi piękno tej historii, że naprawiając krzywdy, jednocześnie budujemy infrastrukturę przyszłości, która i tak jest nieunikniona.

Proces dostępności obejmuje testowanie, raportowanie błędów i wskazanie oczekiwanego zachowania. Audyt różni się tym, że dodatkowo zawiera rekomendacje naprawcze, ale również wymaga przeprowadzenia testów.

Lista narzędzi opiera się na doświadczeniu w audycie relizowanym w projekcie opartym na Angular. Dla innych frameworków mogą obowiązywać inne dobre praktyki, konfiguracje lub dedykowane narzędzia. Warto korzystać z dokumentacji odpowiedniej dla danego stosu technologicznego.

Warto już na etapie projektowania UX/UI zaplanować, które komponenty będą zgodne ze wzorcami dostępności (ARIA patterns). Wzorce dostępności to gotowe zalecenia struktury HTML, ról i atrybutów ARIA dla komponentów takich jak: modal, dialog, menu, akordeon, tabs i tak dalej. Są opisane w oficjalnej dokumentacji ARIA Authoring Practices Guide (APG), przygotowanej przez W3C.

W projekcie zasosowałem wzorzec Dialog (Modal) Pattern, który określa:

• jak zarządzać fokusem wewnątrz modala,
• jak ukrywać tło (aria-hidden lub aria-modal),
• jakie role i atrybuty powinien mieć modal (role="dialog" lub alertdialog).

Wzorzec korzysta z atrybutu aria-modal="true" (został wprowadzony w specyfikacji ARIA 1.1), który informuje czytniki ekranu, że poza modalem nie ma aktywnej treści. Dzięki temu nie trzeba ręcznie stosować aria-hidden="true" na tle. Warto zauważyć, ze nie wszystkie czytniki wspierają aria-modal dlatego w projektach wymagających pełnej zgodności można rozważyć dodatkowe zabezpieczenia np. ręczne ukrywanie tła za pomocą aria-hidden.

WCAG w HTML (przykłady wskazówek)

Treści graficzne

Każdy element graficzny powinien mieć alternatywny opis taki by użytkownicy korzystający z czytników ekranu mogli zrozumieć, co dana grafika przedstawia.

Klasyczne obrazy <img> użycie alt

<img src="assets/creditcards.png" alt="Logo reklamowe dla Credit Cards">

Zastosowanie role="img" i aria-label W przypadku złożonych elementów SVG, które są dekoracyjne lub ikonograficzne, należy:

• użyć role="img" - by czytnik wiedział, że to element graficzny,
• dodać aria-label - by zapewnić opis w drzewie dostępności.

<svg role="img" aria-label="Opis grafiki SVG">
  <!-- zawartość SVG -->
</svg>

Dzięki temu czytnik ekranu odczyta cały obrazek jako jeden spójny element, zamiast analizować każdy fragment SVG z osobna.

Jeśli grafika nie wnosi treści (czysto dekoracyjna).
Można użyć role="presentation" to usuwa grafikę z accessibility tree. Należy jednak stosować to świadomie, aby nie ograbiać uzytkowników z treści.

<img src="assets/just-a-graphic-line-without-content.png" role="presentation">

Rezultat testów

Zakres czasu: 3,5 miesiące
Technologia: Angular
Zakres testów: Zgodność z WCAG 2.2 na poziomie AA (dostępność komponentów Angular w tym DOM, routing, formularze, modale, role ARIA, kontrast kolorów oraz nawigację klawiaturą w kontekście komponentów interfejsu użytkownika)

Statystyki:

• Liczba zgłoszonych błędów: 750+
• Liczba komponentów przetestowanych: brak danych (stracić rachubę)
• Rodzaj testów: manualne, półautomatyczne (axe, Wave), lintersy, testy screen readerem (NVDA)

Przykładowe błędy:

Obserwacje ogólne:

W większości analizowanych aplikacji warstwa UI (kontrast kolorów, rozmiary czcionek, minimalna klikalna powierzchnia itp.) jest dziś na ogół zgodna z podstawowymi wymaganiami WCAG. Wynika to z rosnącej świadomości projektowej i angażowania doświadczonych zespołów UX/UI w SDLC. W efekcie liczba błędów widocznych na pierwszy rzut oka była stosunkowo niewielka.

Najwięcej problemów dostępnościowych wynikało z ukrytych elementów struktury HTML. Najczęściej powtarzające się to:

• brak semantycznych ról,
• nieprawidłowe wykorzystanie atrybutów ARIA,
• brak obsługi klawiatury,
• błędne zarządzanie fokusem,
• nieczytelne tytuły stron,
• dekoracyjne obrazy nieoznakowane prawidłowo.

To pokazuje, że prawdziwe wyzwania w zakresie dostępności rzadko widoczne są gołym okiem i właśnie dlatego testy dostępności pod kontem WCAG 2.2 stanowia wyzwanie.

Autor

Robert Kołcz

Test & Analysis Engineer

Inżynier ds. testów i analiz, specjalizujący się w zapewnieniu, że nowe technologie nie tylko otwierają drzwi do przyszłości, gdzie jakość oprogramowania bezpośrednio prz…więcej

“

Testowanie potrafi pochłaniać od 30 do 50% całkowitego wysiłku projektowego. Dlatego testy są dziś nie tylko pierwszą linią obrony przed błędami, ale także podejściem, które należy rozwijać w kontekście wspierania optymalizacji pracy dzięki wykorzystaniu najlepszych praktyk.

Extra references

• IMG – podstawowy element HTML
• Rola ARIA: img
• Rola ARIA: presentation