Dostępność cyfrowa to dziś nie tylko kwestia zgodności z przepisami, ale przede wszystkim odpowiedzialne podejście do projektowania usług i produktów cyfrowych. Wraz z wejściem w życie nowych regulacji, organizacje muszą zadbać o to, by ich strony i aplikacje były dostępne dla jak najszerszego grona użytkowników – także tych z niepełnosprawnościami.
W tym procesie ogromną rolę odgrywają narzędzia wspierające testowanie dostępności. Tricentis Tosca, dzięki integracji z silnikiem axe-core, pozwala na szybkie wykrywanie wielu problemów już na wczesnym etapie tworzenia aplikacji, wspierając zespoły w budowaniu bardziej inkluzywnych rozwiązań.
Zmiany w przepisach dotyczących dostępności cyfrowej
Europejski Akt o Dostępności przyjęty do prawa unijnego w 2019 roku zakłada, że państwa członkowskie Unii Europejskiej wdrożą rozwiązania, które zapewnią większą dostępność usług cyfrowych. Przykładowo, w Polsce realizację tych przepisów reguluje Ustawa z dnia 26 kwietnia 2024 roku o zapewnieniu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Zgodnie z terminem wejścia w życie Ustawy, z dniem 28 czerwca 2025 roku większość produktów i usług cyfrowych musi zostać dostosowanych do potrzeb osób z niepełnosprawnościami.
W praktyce, poprzez dostosowanie rozumie się spełnienie kryteriów sukcesu opisanych w standardzie WCAG 2.1 na poziomie AA.
WCAG (Web Content Accessibility Guidelines) to zbiór wytycznych dotyczących dostępności stron internetowych i aplikacji. Standard opisuje, jakie zasady muszą zostać spełnione, aby strona/aplikacja była „przyjazna” osobom z niepełnosprawnościami i mogła nosić miano „dostępnej cyfrowo”.
WCAG skupia się na 4 filarach badania dostępności: postrzegalności, funkcjonalności, zrozumiałości i solidności.
- Postrzegalność – możliwość korzystania z aplikacji za pomocą dostępnych dla nas zmysłów. Realizowana w praktyce poprzez tworzenie np. alternatyw tekstowych dla treści nietekstowych, transkrypcję materiałów audio i wideo, logiczną strukturę treści, wyróżnienia nieopierające się jedynie na kolorze, możliwość korzystania ze strony przy powiększeniu 200% czy responsywność (automatyczne dostosowanie się widoku do rozmiaru ekranu).
- Funkcjonalność – przez którą rozumie się m.in. możliwość skorzystania ze wszystkich funkcjonalności przy korzystaniu jedynie z klawiatury, możliwość zatrzymania dynamicznych treści, linki pozwalające na szybkie przeskoczenie do wybranej treści, nagłówki jasno określające treść, widoczność fokusu na aktywnym elemencie czy unikanie złożonych gestów.
- Zrozumiałość – realizowana poprzez prosty język, wyjaśnienia skrótów i akronimów, określenie języka treści w kodzie strony, spójny wygląd i działanie elementów, widoczne i zrozumiałe etykiety oraz komunikaty.
- Solidność (kompatybilność) – sprawienie, aby treści i funkcje działały poprawnie na wielu różnych programach użytkowników np. przeglądarkach internetowych, czytnikach ekranu, czy innych technologiach asystujących.
Na podstawie tych czterech zasad określono 13 bardziej szczegółowych wytycznych, a dla każdej z wytycznych opracowano mierzalne kryteria sukcesu.
Na podmioty gospodarcze wymienione w Ustawie w przypadku niespełnienia powyższych wytycznych zostanie nałożona kara pieniężna w wysokości do dziesięciokrotności przeciętnego wynagrodzenia miesięcznego w gospodarce krajowej za rok poprzedzający, jednak nie większej niż 10% obrotu osiągniętego w roku obrotowym poprzedzającym rok nałożenia kary.
Bardziej dotkliwe niż kary pieniężne, będą dla przedsiębiorców straty wizerunkowe i utrata przychodu wynikająca z ograniczenia możliwości korzystania ze stron i aplikacji dla części klientów. Mowa tutaj o liczbach (w przypadku Polski) od 4 do nawet 7 mln użytkowników.
Światowa Organizacja Zdrowia (WHO) szacuje natomiast, że na całym świecie żyje ponad miliard osób z niepełnosprawnościami, co stanowi aż 15% globalnej populacji. Pomijając kwestie etyczne i moralne oraz odpowiedzialność społeczną osób decyzyjnych w procesie tworzenia aplikacji, warto zadać sobie pytanie: „Czy stać nas na taką stratę?” i czy warto ten temat marginalizować.
Testowanie dostępności
Kluczowe w testowaniu dostępności są testy manualne, ponieważ bez względu na użyte narzędzia wynik automatycznej analizy dostępności cyfrowej nie będzie kompletny.
Testy automatyczne, analizując pojedyncze elementy, nie są w stanie dobrze zrozumieć kontekstu, w związku z czym znajdują do ok. 50% wszystkich problemów związanych z dostępnością.
Najprostszym i dobrze działającym na wyobraźnię przykładem może być badanie tekstów alternatywnych dla zdjęć czy grafik. Automat będzie w stanie sprawdzić, czy tekst istnieje, ale nie będzie w stanie ocenić, czy tekst ma sens w kontekście znaczenia elementu na stronie lub w aplikacji. Automat nie odróżni również tzw. grafiki dekoracyjnej od grafiki skrywającej kluczowe dla działania aplikacji funkcjonalności.
50% to jednak pokaźny wynik, który może znacznie wpłynąć na wydajność analizy dostępności w naszym projekcie, szczególnie jeśli wyniki historyczne wykorzystamy jako punkt odniesienia podczas testowania regresji.
Jeśli chcemy przesunąć moment wykrywania problemów z dostępnością jak najbliżej procesu wytwarzania (developmentu) aplikacji, możemy postarać się wdrożyć automatyzację testów dostępności do naszych pipelineów, jeszcze zanim produkt trafi do testerów manualnych na gruntowną weryfikację dostępności.
Przykładem takiego rozwiązania może być użycie silnika axe-core pozwalającego na przeprowadzenie testów dostępności interfejsu użytkownika dla aplikacji bazujących na HTML-u. Axe-core zawiera implementację reguł od WCAG 2.0 wzwyż na poziomach A, AA i AAA oraz zbiór najlepszych praktyk związanych ze stosowaniem poprawnej semantyki kodu HTML i ARIA na stronach internetowych.
Automatyczna analiza dostępności w Tricentis Tosca
Potencjał silnika Axe-core dostrzegł również Tricentis, który zintegrował go z narzędziem Tosca (funkcjonalność dostępna od wersji 2023.1). Dzięki temu, wspomniane 50% problemów związanych z dostępnością może być wykrytych w bardzo szybki i prosty sposób.
Rodzaje testów dostępności zaimplementowane w Tricentis Tosca
Twórcy Tosca proponują nam 3 rodzaje analizy:
- „Specified Webpage” – analiza dostępności dla wybranej strony internetowej zdefiniowanej w parametrze Search Criteria modułu Check Webpage Accessibility.
- „Before Inputs” – wykonanie analizy dostępności przed wprowadzeniem danych w danym kroku testowym (dla ActionMode Input).
- „After Inputs” – wykonanie analizy dostępności po wprowadzeniu danych w danym kroku testowym (dla ActionMode Input).
Tworzenie analizy dostępności w Tricentis Tosca
Proces tworzenia testów jest intuicyjny i sprowadza się do kilku kroków:
- Stworzenia nowego, pustego TestCase’a.
- Dodania parametru Browser do Test Configuration Parameter (TCP).
- Podjęcia decyzji, jaki rodzaj analizy dostępności chcemy wykonać:
- Opcja 1: „Before/After Inputs” – należy dodać parametr RunAccessibilityAnalysis do TCP, a następnie przypisać mu wartość „After Inputs” lub „Before Inputs”.
- Opcja 2: „Specified Webpage” – do testu należy dodać Standard Module „Check Webpage Accessibility” i podać dane dla parametru „Search Criteria”.
- Uruchomienia TestCase’a z poziomu ExecutionList.
Raporty analizy dostępności w Tricentis Tosca
Po uruchomieniu testów z poziomu ExecutionList w Tosca w kolumnie Accessibility pojawią się wyniki podzielone na poziomy ważności.
Tricentis wyróżnił 4 poziomy ważności:
- Critical – problemy dotyczące najważniejszych funkcjonalności i podstawowych elementów, całkowicie blokujące interakcje użytkownika z aplikacją.
- Serious – błędy częściowo uniemożliwiają interakcję użytkownika z aplikacją, mogą jednak wywoływać frustrację i być poważną barierą użyteczności.
- Moderate – błędy są barierą użyteczności, ale nie dotyczą kluczowych funkcjonalności.
- Minor – problemy o niskim wpływie na użyteczność. Ich naprawa jest konieczna, aby aplikacja była zgodna ze standardem WCAG.
Szczegółowy opis problemów z dostępnością znajdziemy w raporcie, który możemy wygenerować poprzez kliknięcie prawym przyciskiem myszy na interesującej nas ExecutionLiście, a następnie wybraniu opcji „Export accessibility report”. Możliwe jest generowanie wyników w formacie PDF i JSON.
Raport obejmuje stronę podsumowującą wyniki oraz tabelę z analizą problemów zawierającą informacje o wadze błędu, kryterium sukcesu WCAG, które zostało naruszone, oraz proponowanych rozwiązaniach.
Przykładowy fragment (strona 1, 4) Accessibility Report znajduje się poniżej.
Podsumowanie
W kontekście rosnących wymagań prawnych, ale przede wszystkim oczekiwań społecznych, zapewnienie dostępności cyfrowej staje się nie tylko obowiązkiem, ale i świadomym wyborem dojrzałych organizacji. Tricentis Tosca, dzięki integracji z silnikiem axe-core, oferuje realne wsparcie w procesie automatyzacji testów dostępności, umożliwiając wczesne wykrywanie problemów, zwiększając wydajność testów regresyjnych i zmniejszając koszty potencjalnych poprawek.
Pamiętajmy jednak, że narzędzia takie jak Tosca nie zastąpią testów manualnych, a jedynie je uzupełnią. Kluczem do skutecznego zapewnienia dostępności jest połączenie technologii z empatią, czyli zrozumieniem realnych potrzeb użytkowników. Im szybciej uczynimy dostępność integralną częścią procesu wytwarzania oprogramowania, tym mniej będzie ona postrzegana jako obowiązek, a bardziej jako standard projektowania nowoczesnych, inkluzywnych produktów cyfrowych.
Źródła
- Dostępność cyfrowa
- Ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze
- Web Content Accessibility Guidelines (WCAG) 2.1
- Ile jest osób z niepełnosprawnościami w Polsce?
- axe-core Documentation
- Run web accessibility testing early in your development
- Web accessibility testing
Zostaw komentarz