Tabela czytników ekranu:
Dlaczego każda kombinacja technologii wspomagających przedstawia inny obraz sytuacji

Gdy audyt dostępności wykazuje, że strona internetowa „współpracuje z czytnikami ekranu”, stwierdzenie to jest niemal bez znaczenia bez dodatkowych wyjaśnień. Czytniki ekranu nie stanowią jednolitej kategorii oprogramowania — są to złożone aplikacje, z których każda realizuje własną interpretację interfejsów API dostępności udostępnianych przez systemy operacyjne, nakładając tę interpretację na drzewo dostępności przeglądarki, które samo w sobie znacznie różni się w zależności od dostawcy.

W rezultacie powstaje wielowarstwowa struktura interpretacji. A role="dialog" Atrybut elementu modalnego będzie odczytywany inaczej w programie JAWS 2024 z przeglądarką Chrome w porównaniu z programem NVDA 2024.1 z przeglądarką Firefox 124 oraz funkcją VoiceOver w systemie macOS Sonoma z przeglądarką Safari 17. Nie są to drobne różnice w sformułowaniach — mogą one decydować o tym, czy użytkownik zrozumie, że znajduje się w oknie dialogowym typu modalnego, które blokuje fokus, czy też nie usłyszy nic.

The three-layer stack — operating system accessibility API → → screen reader engine — means that any change at any layer can produce an entirely different user experience. Browsers update their accessibility tree implementations. Screen readers update their virtual buffer strategies. OS APIs evolve. The combination testing requirement isn’t bureaucratic box-ticking; it’s a technical necessity rooted in genuine architectural divergence.

Rynek technologii wspomagających skonsolidował się wokół kilku dominujących narzędzi, ale każde z nich ma specyficzną architekturę, grupę użytkowników i preferencje dotyczące przeglądarek. Zrozumienie tych kwestii jest warunkiem koniecznym do racjonalnego ustalania priorytetów testów.

Poniższa tabela przedstawia zaobserwowane zachowanie typowych wzorców ARIA oraz semantyki HTML w najważniejszych kombinacjach technologii wspomagających i przeglądarek. Wyniki opierają się na testach przeprowadzonych przy użyciu wersji odpowiadających aktualnemu stanowi techniki na pierwszy kwartał 2025 roku.

Legenda: Zaliczone = komunikat przekazany poprawnie i w całości. Częściowo zaliczone = komunikat przekazany z brakami lub nieścisłościami. Niezaliczone = komunikat nieprzekazany, przekazany nieprawidłowo lub z zakłóceniami w nawigacji.

Zrozumienie, dlaczego kombinacje się różnią — a nie tylko samego faktu, że tak jest — ma zasadnicze znaczenie dla pisania kodu, który będzie niezawodny w całym macierzy. Różnice te można podzielić na kilka kategorii architektonicznych.

W dniu 15 czerwca 2022 r. przeglądarka Internet Explorer 11 przestała być obsługiwana. Firma Microsoft nie zapewnia już aktualizacji zabezpieczeń ani wsparcia technicznego, a program JAWS 2024 firmy Freedom Scientific nie obsługuje oficjalnie przeglądarki IE 11. WCAG 2.2 — opublikowane w październiku 2023 r. — zawierają kryteria sukcesu, takie jak 2.4.11 „Fokus nie jest zasłonięty”, które zależą od CSS i możliwości renderowania, których IE 11 nie jest w stanie obsługiwać. JAWS+IE nie jest prawidłową kombinacją docelową dla prac nad zgodnością z WCAG 2.2 AA.

Należy jednak pamiętać, że zespoły zajmujące się utrzymaniem starszych kodów powstałych przed 2022 r. lub obsługujące zamknięte środowiska korporacyjne, które nie zakończyły jeszcze migracji z przeglądarki IE do Edge, mogą być zmuszone do zapoznania się z dotychczasowym działaniem tej kombinacji. Kombinacja JAWS/IE korzystała z Microsoft Active Accessibility (MSAA) — starszej warstwy API o znacznie ograniczonej obsłudze ARIA w porównaniu z interfejsami IAccessible2 (IA2) i UI Automation (UIA), które udostępniają nowoczesne przeglądarki. Wiele wzorców ARIA 1.1 działało nieprawidłowo lub w ogóle nie reagowało w środowisku MSAA.

Jeśli należysz do nielicznych zespołów, które mają udokumentowany, wynikający z umowy obowiązek zapewnienia obsługi przeglądarki IE 11, traktuj ją jako dodatkowy cel z odrębnym zestawem testów — a nie jako część programu zapewnienia zgodności z WCAG 2.2. Najnowocześniejszym połączeniem w środowisku korporacyjnym jest JAWS + Edge (Chromium), które wykorzystuje interfejs UIA i zapewnia doskonałą obsługę ARIA.

Podejście firmy Apple do kwestii dostępności różni się zasadniczo od podejścia firmy Microsoft. Podczas gdy programy JAWS i NVDA tworzą kompletną wirtualną reprezentację dokumentu i umożliwiają użytkownikom poruszanie się po tej reprezentacji niezależnie od pozycji kursora, funkcja VoiceOver działa w sposób bardziej bezpośredni, korzystając z wygenerowanego drzewa dostępności, a często także z aktualnej pozycji kursora.

Oznacza to, że schematy działania oparte na niewidocznej manipulacji fokusem — czyli zmiany położenia fokusu, które następują w odpowiedzi na atrybuty ARIA, a nie na interakcję użytkownika — mogą zakłócać działanie VoiceOver w sposób, który wydaje się niewytłumaczalny, dopóki nie zrozumie się różnicy w architekturze. Użytkownicy VoiceOver w systemie macOS poruszają się za pomocą oddzielnego kursora VoiceOver, ale związek między pozycją kursora VoiceOver a fokusem klawiatury jest ściślej powiązany niż w modelu wirtualnego kursora JAWS.

Skorzystaj z tego kalkulatora, aby oszacować nakład pracy związany z testowaniem Twojego produktu na podstawie charakterystyki Twojej bazy użytkowników, docelowych wymagań zgodności oraz dostępnych kombinacji technologii wspomagających.

Żadna ekipa nie dysponuje nieograniczonymi zasobami testowymi. Celem strategii pokrycia testowego jest maksymalizacja prawdopodobieństwa wykrycia rzeczywistych awarii mających wpływ na prawdziwych użytkowników, w ramach ograniczeń czasowych i narzędziowych. Profesjonalnym podejściem jest wycena ryzyka — czyli rozdzielanie nakładu pracy na testy proporcjonalnie do wpływu na użytkowników i ryzyka architektonicznego.

Skuteczne testowanie kombinacyjne nie polega jedynie na uruchamianiu tego samego skryptu testowego ręcznie w różnych narzędziach. Każde narzędzie automatycznego testowania posiada własne skróty klawiszowe, modele nawigacji oraz ustawienia szczegółowości komunikatów. Profesjonalny proces uwzględnia te różnice i zapewnia powtarzalne, porównywalne wyniki.

Poniższa lista kontrolna odnosi się bezpośrednio do kryteriów sukcesu WCAG 2.2 AA, które są weryfikowane przede wszystkim poprzez testy z wykorzystaniem czytników ekranu. Każda pozycja musi zostać zaliczona we wszystkich konfiguracjach P1, zanim dana funkcja zostanie uznana za zgodną z WCAG 2.2 AA.

Testowanie z wykorzystaniem czytników ekranu nie jest jedynie formalnością mającą na celu potwierdzenie zgodności z wymogami dostępności. Jest to dziedzina zapewnienia jakości, która – gdy jest przeprowadzana prawidłowo w odpowiednich kombinacjach – pozwala wykryć błędy interfejsu dotyczące wszystkich użytkowników, a nie tylko osób niepełnosprawnych. Błędy w zarządzaniu fokusem, treści dynamiczne, które nie aktualizują się, oraz stany, które nie są przekazywane programowo, stanowią problemy z użytecznością, które można wykryć właśnie dzięki technologiom wspomagającym.

Sytuacja prawna stanowi dodatkowe poparcie dla argumentów technicznych. Dyrektywa UE w sprawie dostępności stron internetowych, zmienione normy sekcji 508 w USA, brytyjskie przepisy dotyczące dostępności dla organów sektora publicznego oraz nasilająca się fala sporów sądowych dotyczących ADA w sektorze prywatnym wskazują na WCAG 2.2 AA jako podstawowy standard. Ryzyko sporów sądowych jest największe w przypadku braku udokumentowanych testów — a przetestowanie jednej kombinacji często nie stanowi wystarczającego dowodu podjęcia działań w dobrej wierze w celu zapewnienia zgodności.

W AIOPSGROUP współpracujemy z organizacjami z branży usług finansowych, administracji publicznej, handlu detalicznego oraz oprogramowania dla przedsiębiorstw, tworząc programy testowania dostępności, które są zarówno rygorystyczne, jak i zrównoważone. Rygorystyczne oznacza uwzględnienie odpowiednich kombinacji dla właściwych grup użytkowników. Zrównoważone oznacza włączenie testów dostępności do procesów CI/CD, szkolenie zespołów programistycznych oraz tworzenie dynamicznych matryc testowych, które rozwijają się wraz z produktem.

Jeśli Twój zespół tworzy lub utrzymuje produkt cyfrowy przeznaczony dla jakiejkolwiek grupy odbiorców, nie chodzi o to, czy przeprowadzić testy z wykorzystaniem czytników ekranu w wielu kombinacjach, ale jak zrobić to skutecznie i na dużą skalę. Możemy pomóc w obu tych kwestiach.