Audyt Dostępności WCAG 2.2

Audyt dostępności WCAG 2.2 – na czym polega?

Audyt dostępności WCAG 2.2 to analiza strony internetowej lub aplikacji pod kątem zgodności z wytycznymi Web Content Accessibility Guidelines. WCAG określa zasady, które pomagają tworzyć produkty cyfrowe możliwe do obsługi przez osoby o różnych potrzebach, w tym użytkowników korzystających z technologii wspomagających.

Podczas audytu analizowane są konkretne elementy interfejsu oraz sposób ich działania. Problemy mogą dotyczyć między innymi kontrastu, nawigacji za pomocą klawiatury, formularzy, struktury nagłówków, opisów elementów, komunikatów, fokusów czy sposobu przekazywania informacji.

Celem audytu nie jest więc wyłącznie ogólna ocena tego, czy strona wygląda na dostępną. Poszczególne rozwiązania są analizowane w odniesieniu do określonych wymagań i kryteriów WCAG.

Czym jest WCAG 2.2?

WCAG, czyli Web Content Accessibility Guidelines, to międzynarodowy zestaw wytycznych dotyczących dostępności treści i interfejsów cyfrowych. Wersja WCAG 2.2 rozwija wcześniejsze standardy i zawiera kryteria pomagające projektantom, developerom oraz właścicielom serwisów tworzyć bardziej dostępne produkty.

Wytyczne zostały uporządkowane wokół czterech podstawowych zasad. Treści i interfejs powinny być postrzegalne, funkcjonalne, zrozumiałe i kompatybilne z różnymi sposobami korzystania z technologii.

W praktyce oznacza to znacznie więcej niż odpowiednio duży tekst czy kontrast kolorów. Dostępność dotyczy również struktury informacji, sposobu obsługi funkcjonalności, komunikowania błędów oraz możliwości korzystania z produktu bez używania standardowej myszy czy ekranu dotykowego.

Poziomy zgodności WCAG – A, AA i AAA

Kryteria WCAG zostały podzielone na trzy poziomy zgodności: A, AA oraz AAA. Poziom A obejmuje podstawowe wymagania dostępności, natomiast AA rozszerza je o kolejne kryteria mające istotne znaczenie dla praktycznego korzystania z produktu.

Poziom AAA zawiera najbardziej wymagające kryteria. Nie oznacza to jednak, że każda strona internetowa powinna spełniać wszystkie wymagania AAA. Zakres wymaganej zgodności zależy między innymi od rodzaju serwisu i obowiązujących go przepisów.

Dlatego przed wykonaniem audytu warto określić zakres analizy oraz oczekiwany poziom zgodności, zamiast traktować WCAG jako jedną prostą listę kontrolną identyczną dla każdego projektu.

Co sprawdza audyt WCAG 2.2?

Zakres audytu zależy od rodzaju produktu oraz liczby analizowanych ekranów i funkcjonalności. Inaczej wygląda analiza prostej strony usługowej, a inaczej rozbudowanego sklepu internetowego czy aplikacji posiadającej wiele procesów.

Sprawdzane mogą być między innymi nagłówki, linki, przyciski, formularze, menu, modalne okna, komunikaty, elementy graficzne, multimedia, tabele oraz komponenty interaktywne. Analizowany jest zarówno sposób prezentowania informacji, jak i możliwość korzystania z poszczególnych funkcji.

Istotne jest również sprawdzenie powtarzalnych komponentów. Jeżeli ten sam problem występuje w elemencie wykorzystywanym na wielu podstronach, jego poprawienie może mieć wpływ na dużą część całego serwisu.

Audyt dostępności strony internetowej

W przypadku strony internetowej analiza może obejmować zarówno jej strukturę, jak i konkretne szablony podstron. Nie zawsze konieczne jest analizowanie każdej podstrony osobno – część serwisu może korzystać z tych samych komponentów i schematów.

Warto jednak uwzględnić reprezentatywne widoki, takie jak strona główna, podstrona ofertowa, artykuł, formularz kontaktowy, wyniki wyszukiwania czy inne charakterystyczne dla danego serwisu elementy. Pozwala to sprawdzić różne rodzaje treści i interakcji.

Audyt może wykazać zarówno problemy wynikające z projektu UX/UI, jak i z późniejszego sposobu wdrożenia strony. Z tego powodu dostępność warto analizować nie tylko na poziomie wyglądu, ale również działania gotowego serwisu.

Audyt WCAG aplikacji

Audyt dostępności aplikacji może być bardziej rozbudowany, ponieważ użytkownik wykonuje w niej wiele różnych działań. Samo sprawdzenie kilku ekranów nie zawsze pozwala ocenić dostępność całego procesu.

Analiza może obejmować logowanie, rejestrację, formularze, dashboard, nawigację, wyszukiwanie, filtrowanie, ustawienia, komunikaty oraz inne kluczowe funkcjonalności. Szczególnego znaczenia nabierają elementy interaktywne i sposób informowania użytkownika o zmianach zachodzących w interfejsie.

Warto więc określić nie tylko listę ekranów, ale również najważniejsze ścieżki użytkownika. Dzięki temu audyt obejmuje rzeczywiste korzystanie z aplikacji, a nie wyłącznie statyczny wygląd poszczególnych widoków.

Kontrast kolorów a WCAG

Kontrast jest jednym z najbardziej rozpoznawalnych zagadnień związanych z WCAG, ale stanowi tylko część dostępności cyfrowej. Odpowiednia relacja pomiędzy kolorem tekstu i tła pomaga użytkownikom odczytywać treści w różnych warunkach.

Problem może dotyczyć nie tylko podstawowego tekstu. Analizy mogą wymagać również przyciski, linki, pola formularzy, ikony oraz inne elementy interfejsu, zależnie od ich funkcji i sposobu prezentacji.

Warto sprawdzać kontrast już na etapie projektowania UX/UI. Pozwala to uniknąć sytuacji, w której po wdrożeniu okazuje się, że istotna część identyfikacji kolorystycznej interfejsu wymaga przebudowy.

Obsługa strony za pomocą klawiatury

Nie każdy użytkownik korzysta ze strony za pomocą myszy. Dlatego jednym z ważnych obszarów dostępności jest możliwość poruszania się po interfejsie i korzystania z jego funkcjonalności przy użyciu klawiatury.

Użytkownik powinien mieć możliwość przechodzenia pomiędzy odpowiednimi elementami interaktywnymi oraz rozpoznania, który element posiada aktualnie fokus. Kolejność nawigacji powinna być logiczna i zgodna ze strukturą interfejsu.

Problemy mogą pojawiać się między innymi w niestandardowych menu, modalach, rozwijanych komponentach czy formularzach. Element, który działa prawidłowo po kliknięciu myszą, nie musi automatycznie działać równie dobrze podczas obsługi klawiaturą.

Formularze i dostępność WCAG

Formularze są jednym z miejsc, w których problemy z dostępnością mogą bezpośrednio utrudnić wykonanie zadania. Dotyczy to formularzy kontaktowych, rejestracji, logowania, procesu zakupowego oraz bardziej rozbudowanych formularzy występujących w aplikacjach.

Pola powinny być odpowiednio opisane, a użytkownik musi rozumieć, jakich informacji się od niego oczekuje oraz gdzie wystąpił ewentualny błąd. Samo zaznaczenie pola czerwonym kolorem może nie być wystarczającym sposobem komunikowania problemu.

Znaczenie ma również kolejność elementów, sposób prezentowania instrukcji oraz zachowanie formularza podczas korzystania z klawiatury i technologii wspomagających.

Nagłówki, treść i struktura strony

Dostępność dotyczy również sposobu organizowania treści. Nagłówki powinny tworzyć logiczną strukturę dokumentu i pomagać użytkownikowi zrozumieć relacje pomiędzy poszczególnymi sekcjami.

Nie powinny być traktowane wyłącznie jako narzędzie do uzyskania odpowiedniego rozmiaru tekstu. H1, H2, H3 i kolejne poziomy mają znaczenie semantyczne, a ich prawidłowe zastosowanie może ułatwiać korzystanie z treści przy pomocy technologii wspomagających.

Podobnie wygląda sytuacja z linkami. Ich treść powinna możliwie jasno wskazywać cel działania. Projektowanie dostępnego interfejsu obejmuje więc nie tylko warstwę graficzną, ale również sposób organizowania i opisywania informacji.

Grafiki, ikony i tekst alternatywny

Grafiki mogą przekazywać informacje, pełnić funkcję dekoracyjną albo być częścią elementu interaktywnego. Sposób ich przygotowania powinien wynikać z roli, jaką pełnią na stronie lub w aplikacji.

Jeżeli obraz przekazuje istotną informację, należy zadbać o możliwość uzyskania jej również przez użytkowników, którzy obrazu nie widzą. Jednym z wykorzystywanych rozwiązań są odpowiednio przygotowane teksty alternatywne, jednak nie każda grafika wymaga takiego samego opisu.

Elementy czysto dekoracyjne powinny być traktowane inaczej niż wykres, zdjęcie produktu czy ikona będąca przyciskiem. Audyt pomaga wychwycić sytuacje, w których sposób implementacji grafiki może utrudniać zrozumienie treści.

Audyt WCAG a projekt UX/UI w Figma

Część problemów dostępności można wykryć jeszcze przed rozpoczęciem programowania. Projekt UX/UI w Figma pozwala sprawdzić między innymi kolorystykę, kontrast, hierarchię informacji, wielkość elementów, sposób prezentowania formularzy oraz projekt stanów interfejsu.

Ma to znaczenie szczególnie przy nowych stronach i aplikacjach. Jeżeli dostępność zostanie uwzględniona dopiero po zakończeniu projektu i developmentu, poprawienie części problemów może wymagać zmian zarówno w designie, jak i kodzie.

Trzeba jednak pamiętać, że sama analiza Figmy nie zastępuje audytu wdrożonego produktu. Niektóre wymagania można prawidłowo zweryfikować dopiero w działającym interfejsie.

Audyt WCAG a audyt UX – czym się różnią?

Audyt UX i audyt WCAG mogą analizować część tych samych elementów, ale nie są tym samym rodzajem audytu. Audyt użyteczności koncentruje się przede wszystkim na tym, czy użytkownik rozumie produkt i może sprawnie realizować swoje cele.

Audyt WCAG odnosi się natomiast do konkretnych kryteriów dostępności. Problem może być istotny z punktu widzenia UX, mimo że nie stanowi naruszenia konkretnego kryterium WCAG. Możliwa jest również sytuacja odwrotna – interfejs może wydawać się wygodny dla części użytkowników, ale nadal zawierać bariery dostępności.

Połączenie obu perspektyw pozwala analizować produkt zarówno pod kątem ogólnej użyteczności, jak i potrzeb użytkowników korzystających z niego w różny sposób.

Audyt WCAG przed wdrożeniem czy po wdrożeniu?

Dostępność najlepiej uwzględniać już podczas projektowania produktu. Na etapie makiet można poprawić część problemów dotyczących kolorów, struktury informacji, formularzy czy sposobu prezentowania stanów komponentów.

Po wdrożeniu możliwe jest natomiast sprawdzenie elementów, których nie da się w pełni ocenić na podstawie samego projektu. Dotyczy to między innymi struktury kodu, obsługi klawiaturą, zachowania fokusu czy współpracy interfejsu z technologiami wspomagającymi.

Dlatego w większych projektach dostępność może być kontrolowana na kilku etapach: podczas projektowania UX/UI, w trakcie developmentu oraz po uruchomieniu produktu.

Co powinien zawierać raport z audytu dostępności?

Sam wykaz problemów ma ograniczoną wartość, jeżeli zespół nie wie, gdzie występują i w jaki sposób powinny zostać poprawione. Dlatego wyniki audytu powinny być przedstawione w sposób umożliwiający dalszą pracę projektantom i developerom.

Opis problemu może zawierać miejsce jego występowania, powiązane kryterium WCAG, wyjaśnienie problemu oraz rekomendację dotyczącą poprawy. W zależności od zakresu projektu można również określić priorytety poszczególnych zmian.

Raport staje się dzięki temu dokumentem roboczym, a nie wyłącznie oceną serwisu. Może być wykorzystany podczas planowania zmian i późniejszej ponownej weryfikacji produktu.

Kiedy warto wykonać audyt WCAG 2.2?

Audyt warto rozważyć zarówno przy istniejącym produkcie, jak i podczas projektowania nowego rozwiązania. Szczególne znaczenie ma w przypadku serwisów i aplikacji, dla których dostępność wynika z wymagań prawnych, umownych lub organizacyjnych.

Może być również przydatny przed większym redesignem. Zamiast przenosić istniejące problemy do nowej wersji produktu, można wcześniej określić obszary wymagające poprawy i uwzględnić je podczas projektowania.

Dostępność warto traktować jako element jakości produktu cyfrowego, a nie wyłącznie kontrolę wykonywaną na samym końcu projektu.

Audyt WCAG jako element rozwoju strony lub aplikacji

Audyt dostępności może być początkiem dalszych prac nad produktem. Po zidentyfikowaniu problemów część zmian może wymagać poprawy kodu, część modyfikacji treści, a inne przebudowy konkretnych elementów UX/UI.

W przypadku problemów projektowych można przygotować nowe warianty komponentów lub makiety poprawionych ekranów w Figma, a następnie przekazać je zespołowi developerskiemu do wdrożenia.

Proces może więc wyglądać następująco:

audyt WCAG → identyfikacja problemów → rekomendacje → poprawki UX/UI i developerskie → ponowna weryfikacja.

Dzięki temu audyt nie kończy się na samej liście błędów, ale może stanowić konkretny punkt wyjścia do poprawy dostępności strony internetowej lub aplikacji.