Od czego zacząć z dostępnością, gdy wydaje się zbyt duża

Pierwsza rzecz do zrozumienia: nie musisz naprawić wszystkiego naraz

Gdy organizacje po raz pierwszy stykają się z WCAG 2.2, reakcją jest często mieszanka szczerego zaniepokojenia i przytłoczenia. Jest 78 kryteriów sukcesu na trzech poziomach zgodności. Dokumentacja technik wspierających jest ogromna. Automatyczne skanowania generują listy setek problemów. Wydaje się, że trzeba by wstrzymać wszystko i poświęcić miesiące czasu programistycznego, zanim można by w ogóle pomyśleć o nazwaniu swojej strony dostępną.

To uczucie jest zrozumiałe, ale mylące. Poprawa dostępności nie jest stanem binarnym — dostępny albo niedostępny. To spektrum, a znaczący postęp jest możliwy z miejsca, w którym jesteś teraz, nawet jeśli tym miejscem jest „wcześniej o tym nie myśleliśmy”.

Celem tego przewodnika jest pomóc Ci zacząć.

Dlaczego poczucie przytłoczenia jest normalne

Dostępność sieci wydaje się duża, ponieważ naprawdę jest duża. WCAG obejmuje prezentację wizualną (kontrast, rozmiar tekstu, odstępy), treść dźwiękową (napisy, transkrypcje), interakcję (nawigacja klawiaturą, czas, ruch), semantykę (strukturę, etykiety, role) oraz aspekty poznawcze (język, spójność, wyjście z błędu). Odnosi się do komputerów stacjonarnych, urządzeń mobilnych i technologii wspomagających. Dotyczy projektowania, treści, programowania i testowania.

Ale oto co zmienia obraz: większość błędów dostępności skupia się wokół niewielkiej liczby wzorców. Rok po roku raport WebAIM Million (który analizuje milion najczęściej odwiedzanych witryn) stwierdza, że te same sześć problemów odpowiada za przytłaczającą większość automatycznie wykrywalnych błędów WCAG:

Niski kontrast kolorów
Brak tekstu alternatywnego na obrazach
Brak etykiet pól formularza
Puste linki (linki bez tekstu)
Brak języka dokumentu
Puste przyciski (przyciski bez tekstu)

Te sześć wzorców występuje na ponad 95% testowanych stron głównych. Naprawienie ich na Twojej stronie nie czyni Cię w pełni dostępnym, ale usuwa bariery, które dotykają największą liczbę użytkowników z niepełnosprawnościami. To znaczący punkt wyjścia.

Krok 1: Poznaj swoją obecną pozycję

Zanim ustalisz priorytety napraw, musisz wiedzieć, gdzie stoisz. Bezpłatne automatyczne skanowanie daje Ci to w kilka minut.

Narzędzia automatyczne nie są kompletnym rozwiązaniem dostępności — niezawodnie wychwytują tylko 30–40% błędów WCAG, ponieważ większość barier wymaga do wykrycia ludzkiego osądu. Ale doskonale radzą sobie ze znajdowaniem wymienionych powyżej powszechnych, automatyzowalnych błędów: kontrastu, brakującego tekstu alternatywnego, nieoznaczonych pól i podobnych problemów strukturalnych.

Uruchom bezpłatne skanowanie swojej strony. Przyjrzyj się temu, co wróci. Zgłoszone problemy są prawdziwe — nie będą fałszywymi alarmami dla powszechnych wzorców — i stanowią konkretną listę na start.

Krok 2: Ustalaj priorytety według wpływu, a nie kompletności

Gdy masz już listę, pokusą jest zajęcie się każdą pozycją po kolei. Oprzyj się temu. Zamiast tego ustalaj priorytety według połączenia wpływu i częstotliwości:

Największy wpływ (napraw najpierw):

Wszelkie bariery w Twoim procesie zakupu, rejestracji lub głównej ścieżce konwersji — jeśli użytkownicy nie mogą sfinalizować transakcji, błąd dostępności kosztuje Cię biznes
Bariery logowania i uwierzytelniania — użytkownicy, którzy nie mogą się dostać do środka, nie mogą korzystać z niczego
Nawigacja — jeśli użytkownicy nie mogą znaleźć stron, dostępność na poziomie strony nie ma znaczenia

Duży wpływ (napraw w drugiej kolejności):

Główne strony z treścią: strony produktów, strony informacyjne, treść, po którą użytkownicy przychodzą specjalnie
Pola formularzy oraz ich etykiety i komunikaty o błędach — formularze to miejsce, gdzie zachodzi interakcja
Błędy kontrastu — dotykają one bardzo dużej populacji i zwykle są prostymi poprawkami

Ważne, ale mniej pilne (napraw później):

Treści archiwalne i starsze strony o niskim ruchu
Interakcje w sytuacjach brzegowych i kryteria WCAG dotykające mniejszych populacji
Wymogi poziomu AAA (które wykraczają poza standard prawny)

Nie musisz osiągnąć idealnych wyników, zanim Twoje strony o najwyższym ruchu i najwyższej konwersji będą dostępne. Zadbaj najpierw o te.

Krok 3: Dodaj testowanie ręczne dla tego, co automatyzacja pomija

Gdy masz już pod kontrolą problemy wykryte automatycznie, kolejną warstwą jest testowanie ręczne. To tutaj znajdziesz:

Błędy nawigacji klawiaturą — czy użytkownicy mogą przejść tabulatorem przez całą Twoją stronę bez myszy?
Problemy z zarządzaniem fokusem — po otwarciu okna modalnego czy fokus przenosi się do niego? Po jego zamknięciu czy powraca?
Zachowanie czytnika ekranu — czy Twoja niestandardowa lista rozwijana ogłasza swój stan? Czy Twoja karuzela komunikuje, który slajd jest aktywny?
Logiczna kolejność odczytu — jeśli usuniesz CSS, czy strona nadal ma sens?

Najszybszy sposób, aby zacząć testowanie ręczne, to:

Odłącz mysz i spróbuj przejść przez główną ścieżkę użytkownika swojej strony, używając wyłącznie klawiatury (Tab, Shift+Tab, Enter, Spacja, Escape, klawisze strzałek). Odnotuj wszystko, co się psuje.
Pobierz bezpłatny czytnik ekranu (NVDA dla Windows jest bezpłatny; VoiceOver jest wbudowany w Mac i iOS). Poruszaj się po swoich najważniejszych stronach. Wsłuchaj się w to, co jest ogłaszane. Czy jest spójne?
Użyj narzędzi dostępności przeglądarki — zarówno Chrome, jak i Firefox mają inspektory dostępności, które pokazują drzewo dostępności, role ARIA i obliczone dostępne nazwy dla każdego elementu.

Nauka tych testów zajmuje czas, ale nic nie kosztują, a znajdą problemy, których nie wykryje żadne narzędzie automatyczne.

Krok 4: Wbuduj to w swój sposób pracy

Najdroższym sposobem podejścia do dostępności jest traktowanie jej jako ćwiczenia naprawczego — napraw stronę, ogłoś zwycięstwo, a potem patrz, jak nowe bariery narastają z każdym nowym wydaniem funkcji.

Zrównoważona dostępność oznacza zmianę sposobu, w jaki pracujesz:

Przegląd projektu — czy projekt spełnia wymogi kontrastu? Czy stany interaktywne są widoczne?
Programowanie — czy natywne elementy HTML są używane tam, gdzie to możliwe? Czy pola formularza są oznaczone? Czy niestandardowe komponenty mają poprawne ARIA?
Treść — czy każdy obraz ma odpowiedni tekst alternatywny? Czy linki są opisowe?
Testowanie — czy CI blokuje regresje dostępności? Czy przed dużymi wydaniami jest etap testowania ręcznego?

Nasz przewodnik na temat dostępności w cyklu życia oprogramowania zagłębia się w to, jak to wygląda w praktyce. Nasza usługa integracji CI/CD czyni warstwę automatyczną częścią każdej kompilacji.

Ustalanie realistycznych oczekiwań

Dla witryny, która nigdy nie była poddana przeglądowi dostępności, osiągnięcie zgodności z WCAG 2.1 na poziomie AA na każdej stronie jest zwykle wielomiesięcznym projektem — dłuższym w przypadku dużych, złożonych witryn ze znaczną ilością starszego kodu.

Nie oznacza to, że nie możesz osiągnąć znaczącego postępu w ciągu najbliższych dwóch tygodni. Naprawienie sześciu najczęstszych problemów, które wymieniłem powyżej, czyni Twoją stronę istotnie bardziej dostępną dla znacznej populacji, nawet jeśli nie czyni Cię zgodnym z prawem.

Rama, którą uważam za najbardziej użyteczną: dąż do ciągłego doskonalenia, a nie do zgodności-jako-celu. W każdym cyklu sprintu rozwiązuj zestaw zidentyfikowanych problemów. Uruchamiaj automatyczne kontrole nowych funkcji, zanim trafią na produkcję. Planuj testowanie ręczne kwartalnie. Zbuduj deklarację dostępności, która uczciwie odzwierciedla Twój obecny stan i Twoją mapę drogową.

Organizacje, które podchodzą do tego w ten sposób, zwykle robią szybszy ogólny postęp niż te, które czekają, aż będą mogły zapewnić zasoby na kompletny projekt naprawczy.

Od czego zacząć dzisiaj

Jeśli jeszcze nic nie zrobiłeś: uruchom bezpłatne skanowanie. W dwie minuty będziesz mieć prawdziwą listę prawdziwych problemów, uszeregowanych według wagi. To jest Twój punkt wyjścia.

Jeśli uruchomiłeś skanowania, ale nie przeszedłeś do testowania ręcznego: wypróbuj dziś test wyłącznie z klawiaturą na swojej ścieżce zakupowej. Jeśli znajdziesz bariery, znalazłeś swój kolejny priorytet.

Jeśli robisz testowanie ręczne, ale nie zintegrowałeś go ze swoim sposobem pracy: przeczytaj nasz przewodnik na temat dostępności w procesie programistycznym i wskaż jeden punkt w swoim obecnym sposobie pracy, w którym można by dodać kontrolę dostępności.

Postęp bije doskonałość. Zacznij od czegoś.