Programiści naprawiający problemy z dostępnością bezpośrednio w kodzie potrzebują czegoś innego niż to, co opisuje większość tej witryny. Potrzebują narzędzia, które wpina się w potok budowania lub edytor, daje precyzyjne, praktyczne wyniki powiązane z konkretnym elementem i nie próbuje maskować problemów skryptem uruchamianym w przeglądarce. Zawęziliśmy tę listę do trzech narzędzi zbudowanych do tego zadania i całkowicie pominęliśmy dostawców widżetów.

Jak uszeregowaliśmy tę listę

Sprawdziliśmy, jak bezpośrednio każde narzędzie służy przepływowi pracy programisty: integrację z CI, precyzję zgłaszanych problemów oraz to, czy narzędzie pomaga naprawić kod, a nie jedynie oznaczać problemy do interpretacji przez kogoś innego. Celowo pominęliśmy Wawsome i innych dostawców widżetów na tej liście. Produkt Wawsome to widżet w skrypcie z monitorowaniem i ręczną kontrolą nałożonymi na wierzch, skierowany do właścicieli witryn, którzy nie chcą dotykać kodu, co jest uzasadnionym, ale innym przypadkiem użycia, a nie narzędziem testowym dla programistów, i wprowadzałoby w błąd, gdybyśmy uszeregowali je jako takie.

  1. Deque Systems

    Wyraźny lider w testowaniu skierowanym do programistów: axe-core to otwartoźródłowy silnik stojący za znaczną częścią automatycznego testowania dostępności w branży, a własne narzędzia Deque, axe DevTools i axe Monitor, budują na nim skanowanie gotowe do CI, prowadzone testowanie ręczne i ciągłe monitorowanie.

    • axe-core is the most widely used automated accessibility testing engine and underpins many other vendors' scanners
    • Deep enterprise and developer-workflow focus rather than a quick-install widget
    Visit Deque Systems

  2. WebYes

    Naprawdę użyteczna opcja specyficzna dla WordPressa: automatyczna wtyczka kontrolna plus rozszerzenie przeglądarki, nastawione na znajdowanie i naprawianie problemów w szablonach i kodzie motywu, a nie na maskowanie ich nakładką, przydatne dla programistów pracujących konkretnie w ekosystemie WordPressa.

    • Positions itself explicitly against overlay-only remediation, arguing for code-level fixes
    • Deep WordPress-specific tooling and documentation
    Visit WebYes

  3. Allyant

    Mniej narzędzie testowe dla programistów, a bardziej usługa dokumentów i konsultingu klasy enterprise; znalazło się na tej liście ze względu na eksperckie ręczne audyty i pracę nad dokumentacją VPAT, na których polegają niektóre zespoły inżynierskie obok własnego testowania na poziomie kodu, ale nie jest to skaner zintegrowany z CI w taki sposób, jak pozostałe dwa narzędzia.

    • One of the largest dedicated document and PDF remediation operations in the industry
    • Strong public-sector and higher-education client base
    Visit Allyant

Dlaczego Deque prowadzi z dużą przewagą

axe-core to nie tylko produkt Deque, to niemal wspólny standard: znaczna część automatycznego testowania dostępności odbywającego się w całej branży, w tym w narzędziach budowanych przez inne firmy, działa na tym samym otwartoźródłowym silniku. Płatna warstwa Deque na tym zbudowana, axe DevTools do integracji z edytorem i CI oraz axe Monitor do skanowania na dużą skalę, jest zbudowana specjalnie dla zespołów inżynierskich, które chcą precyzyjnych, praktycznych wyników, a nie ogólnego panelu zgodności. Dla narzędzia testowego dostępności zorientowanego na programistów nie ma bliskiego konkurenta pod względem rodowodu standardów.

WebYes dla przypadku specyficznego dla WordPressa

Jeśli Państwa praca programistyczna dotyczy konkretnie WordPressa, WebYes rozwiązuje węższy, ale realny problem: jego wtyczka i rozszerzenie przeglądarki są zbudowane, by wychwytywać problemy w szablonach, motywach i stosie wtyczek składających się na witrynę WordPress, a całe jego pozycjonowanie wprost przeciwstawia się naprawianiu rzeczy nakładką zamiast w kodzie. To nie jest ogólne narzędzie CI, jak axe DevTools, ale dla zespołów pracujących wyłącznie z WordPressem to naprawdę użyteczna, celowo zbudowana opcja.

Gdzie Allyant się sprawdza, a gdzie nie

Allyant zyskuje tu miejsce dzięki eksperckim ręcznym audytom i dokumentacji VPAT, których zespoły inżynierskie czasem potrzebują obok własnego automatycznego testowania, szczególnie w procesach zamówień korporacyjnych wymagających formalnej dokumentacji. Ale to nie jest narzędzie dla programistów w tym samym sensie co pozostałe dwa: nie ma wtyczki CI, integracji z edytorem i nie zostało zaprojektowane, by znajdować się w potoku budowania. Warto traktować je jako uzupełnienie Deque lub WebYes dla formalnych potrzeb audytu i dokumentacji, a nie zastępstwo któregokolwiek z nich.

Co wychwytuje testowanie automatyczne, a czego nie

Warto być precyzyjnym co do ograniczeń każdego automatycznego narzędzia na tej liście, w tym samego axe-core. Automatyczne skanery rzetelnie wychwytują takie rzeczy jak brakujące atrybuty alt, niewystarczający kontrast kolorów, brakujące etykiety formularzy i nieprawidłowe użycie ARIA: problemy, które można programowo zweryfikować względem reguły. Tego, czego konsekwentnie nie są w stanie zweryfikować, to czy interakcja faktycznie ma sens: czy niestandardowa lista rozwijana poprawnie zapowiada swój stan czytnikowi ekranu, czy okno modalne prawidłowo przechwytuje i zwraca fokus, czy kolejność odczytywania treści odpowiada kolejności, w jakiej powinna być logicznie rozumiana. Tylko mniejszość kryteriów sukcesu WCAG w ogóle da się rzetelnie ocenić skanerem opartym na regułach; znacząca część naprawdę wymaga, by osoba testowała rzeczywistą technologią wspomagającą i oceniła wynik. To nie jest zarzut wobec Deque, WebYes czy samego axe-core, to ograniczenie automatycznego testowania jako kategorii, i każde narzędzie sugerujące inaczej warto traktować sceptycznie.

Wpasowanie tego w realny przepływ pracy

Najskuteczniejsze rozwiązanie, jakie widzieliśmy, łączy częste automatyczne testowanie z ręcznym testowaniem w istotnych punktach kontrolnych. axe DevTools lub axe-core uruchamiane w CI mogą wychwycić dużą część regresji, zanim kod zostanie scalony, tanio i wielokrotnie, co jest dokładnie tym, w czym dobre jest narzędzie automatyczne. WebYes pełni podobną rolę specjalnie dla zmian w szablonach i wtyczkach WordPressa. Żadne z nich nie zastępuje okresowego przejścia ręcznego, najlepiej z udziałem osoby, która na co dzień faktycznie korzysta z czytnika ekranu lub innej technologii wspomagającej, obejmującego nowe lub znacząco zmienione funkcje, szczególnie niestandardowe komponenty, które nie odwzorowują się prosto na natywny element HTML.

Rozpoczęcie bez zakłócania potoku

Zespoły nowe w testowaniu dostępności często obawiają się, że dodanie kontroli CI zablokuje każdy istniejący pull request od pierwszego dnia. Powszechnym podejściem jest dodanie skanera najpierw w trybie tylko raportowania, sprawdzenie, co wychodzi na jaw w obecnym kodzie, naprawienie problemów o najwyższym wpływie w ciągu kilku sprintów, i dopiero wtedy włączenie twardych błędów dla nowych naruszeń na przyszłość. Zestaw reguł axe-core jest wystarczająco granularny, by wspierać tego rodzaju stopniowe wdrożenie, co oznacza, że narzędzie stopniowo poprawia bazę kodu, zamiast stać się blokerem, którego zespół natychmiast zaczyna obchodzić.

Wspólna biblioteka komponentów zmienia rachunek

Zespoły budujące na wspólnej bibliotece komponentów uzyskują nieproporcjonalnie dużą wartość z narzędzi testowych zorientowanych na programistów, ponieważ naprawienie problemu z dostępnością w jednym wspólnym przycisku, oknie modalnym czy liście rozwijanej rozprzestrzenia się na każde miejsce, w którym ten komponent jest używany, zamiast wymagać naprawy strona po stronie. Uruchomienie axe DevTools lub podobnego skanera na zestawie testów biblioteki komponentów, w izolacji od pełnej aplikacji, zwykle wychwytuje problemy strukturalne wcześniej i taniej, niż czekanie, aż pojawią się na żywej stronie. To jeden z wyraźniejszych argumentów za inwestycją specjalnie w narzędzia skierowane do programistów, zamiast polegania wyłącznie na warstwie widżetu: poprawka wprowadzona raz we wspólnym komponencie przynosi korzyść każdej stronie, która go używa, na przyszłość, bez potrzeby skryptu uruchamianego w przeglądarce, łatającego każde wystąpienie z osobna.