Jak prowadzić testy dostępności?

Czym jest ACT Rules Format 1.1?

ACT Rules Format 1.1 to rekomendacja W3C opisująca format tworzenia reguł testowania dostępności. Nie jest to kolejny zestaw wymagań dostępności, jak WCAG, lecz ustandaryzowany sposób opisywania testów sprawdzających zgodność z tymi wytycznymi. Reguły ACT mogą być używane zarówno w narzędziach automatycznych, jak i w metodykach testowania manualnego. Celem dokumentu jest ujednolicenie sposobu dokumentowania procedur testowych, aby wyniki audytów i narzędzi były bardziej przejrzyste, porównywalne i powtarzalne. 

Wyjaśnienie

WCAG mówi: „Co ma być dostępne”, z kolei ACT Rules Format mówi: „Jak opisać test, który sprawdza dane wymaganie dostępności”.

ACT jest metapoziomem, ponieważ nie definiuje samej dostępności, lecz określa strukturę reguł testowych. Mogą one sprawdzać m.in. kryteria sukcesu WCAG, specyfikacje HTML, ARIA, EPUB czy inne standardy. Dokument wskazuje, że ACT Rules mogą odnosić się do WCAG 2.X i innych dokumentów wymagań dostępności, ale format jest pomyślany jako technologicznie neutralny i może być stosowany także poza klasycznym HTML/CSS/ARIA. 

Powstanie dokumentu

Różne narzędzia testowania dostępności potrafią dawać różne wyniki dla tego samego problemu. Jedno narzędzie wykryje defekt, drugie nie. Jeden audytor zinterpretuje warunek inaczej niż drugi. ACT Rules Format ma zmniejszać tę rozbieżność przez precyzyjne opisywanie:

• czego dotyczy test,
• kiedy reguła ma zastosowanie,
• co jest sprawdzane,
• jaki wynik otrzymaliśmy: „passed”, „failed” albo „inapplicable”,
• jak reguła mapuje się na WCAG lub inne wymagania,
• jakie są przykłady poprawnego i błędnego zachowania.

Dokument podkreśla, że opisanie procedur testowania w ustandaryzowany sposób ma zapewnić transparentność i reprodukowalność wyników testów dostępności. 

Dwa typy reguł ACT

Dokument wyróżnia dwa podstawowe typy reguł:

1. Reguły atomowe (atomic rules) opisują test jednej konkretnej sytuacji lub jednego konkretnego rozwiązania. Powinny być małe, precyzyjne i sprawdzać jeden określony warunek bez korzystania z wyników innych reguł.
2. Reguły złożone (composite rules) łączą wyniki kilku reguł atomowych, aby wyprowadzić jeden wynik dla danego obiektu testu. Przykład: film może spełnić wymaganie, jeśli ma transkrypcję, audiodeskrypcję albo odpowiednią ścieżkę opisu – każdą z tych opcji można sprawdzać osobną regułą atomową, a reguła złożona opisuje, jak połączyć wyniki. 

Składowe reguł ACT

Reguła ACT musi mieć określoną strukturę. Dokument wymienia m.in.:

• tytuł,
• unikalny identyfikator,
• opis reguły,
• typ reguły,
• mapowanie do wymagań dostępności,
• dane wejściowe,
• zakres zastosowania,
• oczekiwania,
• tło, założenia i informacje o wsparciu dostępności,
• przykłady,
• wersję reguły,
• wersję formatu ACT,
• glosariusz.

Reguły ACT mogą zawierać także elementy opcjonalne, np. lista problemów czy informacje o implementacjach. Ważne jest również to, że sama reguła musi być opublikowana w dostępnym dokumencie, zgodnym z WCAG lub porównywalnym standardem dostępności. 

Mapowanie do wymagań dostępności

Jedną z najważniejszych części formatu jest Accessibility Requirements Mapping, czyli wskazanie, z jakimi wymaganiami dostępności dana reguła jest powiązana. W ACT Rules Format 1.1 wprowadzono dwa typy wymagań:

1. Conformance Requirements – wymagania, które dana reguła faktycznie testuje pod kątem zgodności. Jeśli wynik jest „failed”, wymaganie nie jest spełnione dla danego przedmiotu testu.
2. Secondary Requirements – wymagania powiązane z regułą, ale niebędące głównym przedmiotem testu. Wynik reguły może mieć wpływ na ocenę takiego wymagania, ale nie przesądza samodzielnie o zgodności. Dokument pokazuje np. sytuacje, w których reguła jest mniej ścisła albo bardziej ścisła niż wymaganie WCAG. 

Zakres zastosowania

Bardzo ważnym pojęciem jest „applicability”, czyli warunek określający, do czego reguła ma zastosowanie. Przykładowo reguła może dotyczyć wszystkich elementów img, wszystkich elementów audio z autoplay albo wszystkich elementów stylizowanych jako nagłówki.

W wersji 1.1 dopuszczono tzw. „subjective applicability”, czyli przypadki, w których zakresu zastosowania nie da się opisać w pełni obiektywnie i wymaga ludzkiej oceny. Przykładem jest „element stylizowany jak nagłówek” – taka ocena może zależeć od kontekstu wizualnego strony. Dokument zaleca jednak unikanie subiektywności, gdy tylko można ją rozdzielić od obiektywnych części testu. 

Oczekiwania i wyniki testów

Każda reguła ACT musi definiować oczekiwania, czyli warunki, które muszą zostać spełnione przez testowany obiekt. Jeśli obiekt spełnia wszystkie oczekiwania, wynik to passed. Jeśli nie spełnia któregoś z oczekiwań, wynik to failed. Jeśli nie ma obiektów, do których reguła miałaby zastosowanie, wynik to inapplicable. 

Dokument definiuje pięć możliwych wyników reguły ACT:

• passed – testowany obiekt spełnia oczekiwania,
• failed – testowany obiekt ich nie spełnia,
• inapplicable – reguła nie ma zastosowania,
• cantTell – nie da się ustalić wyniku,
• untested – reguła nie została zweryfikowana.

To ważne rozróżnienie, bo w WCAG samo kryterium sukcesu nie jest formalnie „passed” albo „failed” – jest ono spełnione albo niespełnione. ACT wprowadza natomiast strukturę wyników dla konkretnych reguł testowych. 

Dokładność reguł i ryzyko błędnych wyników

Dokument uczciwie wskazuje, że nawet dobrze opisana reguła ACT nie gwarantuje idealnych wyników. Mogą wystąpić:

• false positives – reguła wskazuje defekt, choć wymaganie dostępności jest spełnione,
• false negatives – reguła wskazuje poprawność, choć wymaganie dostępności nie jest spełnione.

Powody mogą być różne, np. błędne założenia o testowanym obiekcie, nietypowe użycie technologii, zmiany technologiczne albo niewłaściwa interpretacja wymagania dostępności. Dlatego reguły ACT wymagają utrzymania, aktualizacji i walidacji. 

Harmonizacja narzędzi i audytów

ACT Rules Format nie wymusza, aby wszystkie narzędzia testujące dostępność miały te same reguły, ale ma sprzyjać harmonizacji. Harmonizacja oznacza, że grupa twórców narzędzi, audytorów albo organizacji uznaje określony zestaw reguł za wspólną podstawę. Przykładowo dana społeczność może wymagać, aby reguła była zaakceptowana przez kilka organizacji i miała niezależne implementacje.

JSON-LD i EARL

Dodatek do dokumentu wyjaśnia, jak można przedstawić wyniki reguł ACT przy użyciu JSON-LD i EARL. Chodzi o to, aby wyniki testów mogły być zapisywane maszynowo, wymieniane między narzędziami i agregowane, np. według konkretnego wymagania WCAG albo całego testowanego serwisu. 

Znaczenie dla audytorów i testerów dostępności

Dla audytora dostępności ACT Rules Format 1.1 oznacza większą dyscyplinę opisywania testów. Nie wystarczy powiedzieć „sprawdź alt text”. Trzeba określić:

• do których elementów test ma zastosowanie,
• jakie są oczekiwania,
• jak interpretować wynik,
• z jakim wymaganiem WCAG wynik jest powiązany,
• kiedy wymagane jest dalsze testowanie,
• jakie są przykłady poprawne, błędne i niejednoznaczne.

Dla producentów narzędzi oznacza to możliwość budowania testów, które łatwiej porównywać z innymi narzędziami i metodykami. Dla organizacji zamawiających audyty oznacza to większą przejrzystość: można łatwiej zrozumieć, co naprawdę zostało sprawdzone i dlaczego wynik jest taki, a nie inny.

Podsumowanie

ACT Rules Format 1.1 to standard opisywania reguł testowania dostępności. Jego celem jest to, aby testy WCAG i innych wymagań były bardziej jednoznaczne, powtarzalne, porównywalne i możliwe do implementacji w narzędziach. Dokument nie zastępuje WCAG, ale pomaga budować spójne reguły testowe dla audytów manualnych, półautomatycznych i automatycznych. Największe nowości wersji 1.1 to obsługa wymagań głównych i drugorzędnych, dopuszczenie kontrolowanej subiektywności oraz lepsze opisanie wyników i zgodności implementacji.