Jakiś czas temu kolega będący programistą front-edu zapytał mnie, czemu w naszej firmie nie testujemy w ogóle frontu. Dlaczego nie testujemy dostępności albo wydajności z punktu widzenia usera (wpis o GTmetrix powstał z resztą po tej rozmowie). Odpowiedziałam mu zgodnie z prawdą: nie wiem czemu, ale się domyślam 🙂 Mój projekt jest w momencie, w którym i tak planowałam zwiększenie zakresu testów. Dlatego zaintrygowała mnie jednak wskazówka kolegi, zaczęłam sama poszukiwać informacji na temat testowania frontu, a zwłaszcza dostępności.

Googlując nieco trafiłam na artykuł “An introduction to frontend testing” na Creative Bloq. W punkcie 4 opisywane są właśnie między innymi testy dostępności z użyciem Pa11y (O samym Pa11y planuję również stworzyć wpis). Od razu zabrałam się do czytania dokumentacji, w której znalazłam link do Koa11y – narzędzia z bardzo przyjemnym i intuicyjnym GUI.

Zanim jednak przejdę do samego narzędzia, krótkie przypomnienie z czym mamy do czynienia:

Testowanie dostępności: Testowanie mające na celu określenie czy użytkownik będący osobą niepełnosprawną może używać modułu lub systemu [Słownik terminów związanych z testowaniem, wersja 2.3 (2014), SJSI ]

W tym miejscu chciałabym wam krótko wspomnieć na temat standardów WCAG oraz Sectio508. Rozwinięcie pierwszego skrótu, to Web Content Accessibility Guidelines, więc jak pewnie już się domyślacie, są to po prostu wskazówki rodem z W3C które pomogą uczynić stronę bardziej dostępną. Section508 to zestaw wymagań, które zgodnie z prawem musi spełniać strona każdej organizacji rządowej w USA. Warto jednak mieć na uwadze, że podobne przepisy istnieją również w innych krajach. Polecam również artykuł na guru99 o testowaniu dostępności, gdzie dowiecie się, dlaczego warto wykonywać testy dostępności.

A teraz do rzeczy, czyli Koa11y 🙂 Jeśli Was również zainteresował ten temat, to gorąco polecam właśnie to narzędzie do pierwszych testów. Możemy je pobrać ze strony programu, która automagicznie wykrywa system na jakim pracujemy. Po pobraniu wypakowujemy paczkę i… włączamy Koa11y.

Tak jak już wspomniałam interfejs jest bajecznie prosty i ładny (przynajmniej w moje gusta się wpisuje). Na poniższym screenie możecie również od razu zauważyć, że Koa11y pozwala generować raporty w całkiem dużej liczbie formatów (choć sama polecam HTML).

Wygenerujemy w ramach ćwiczenia pierwszy raport dla mojego bloga. Jedyne, co tak naprawdę musimy zrobić, to wpisać adres – nazwa raportu generuje się sama (domena strony, którą testujemy). Nic nie stoi jednak na przeszkodzie, by nazwę zmienić – niech będzie “raport_kotqa_pl”.

Jak wspomniałam, możemy zmienić format (domyślnie HTML) i miejsce zapisu (domyślnie pulpit). Te jednak mi jaknajbardziej odpowiadają. Możemy również wybrać standard, pod kątem którego zostanie wykonany test. Domyślnie ustawiony jest WCAG 2.0 AA. Mój blog zdecydowanie nie jest amerykańską stroną rządową, więc nie zmieniamy 😛

Klikamy “Run!” i czekamy, aż program poinforumuje nas, że wygenerował raport:

WIemy już, że Koa11y odnotował 19 błędów, 4 ostrzeżenia i 73 uwagi (notyfikacje?). Jak widać mam nad czym pracować 🙂 Po otworzeniu raport prezentuje nam szczegóły każdego z nich, klikając na ikony możemy filtrować, czy chcemy widzieć wszystko, czy np. Tylko błędy.

Narzędzie pozwala nam również na przetestowanie dostępności obrazów. Powtórzmy więc test korzystając z tej możliwości. W tym celu musimy kliknąć przycisk “Copy the console code”, przejść do przeglądarki z otwartą testowaną stroną, wkleić kod i kliknąć enter. Wygenerowany zostanie kod, który kopiujemy do okna tekstowego Koa11y.

Ponownie klikamy “Run!”. Tym razem otwiera nam się okno, w którym zaznaczamy, czy tekst pod obrazkami opisuje to, co na nich się znajduje. Kiedy to zrobimy, klikamy “Continue” i czekamy na nowy raport.

A ten niewiele różni się poprzedniego, dodana jest tylko formatka z informacją na temat testów obrazków:

I to byłoby wszystko, jeśli chodzi o testowanie dostępności z użyciem Koa11y. Tylko tyle, albo aż tyle. Narzędzie jest tak łatwe i intuicyjne w obsłudze, że moim zdaniem warto z nim spróbować przygodę z testami dostępności, żeby sprawdzić “z czym to się je”. Raport jest też na tyle szczegółowy, a same testy tak szybkie, że dla niektórych projektów może to być wszystko, czego potrzebujemy, aby zapewnić odpowiednią dostępność.

A co Wy myślicie na temat testów dostępności i samego Koa11y? Słyszeliście w ogóle o tym narzędziu? A może już wcześniej wykonywaliście testy na swoich projektach?

Zdjęcie wpisu: Designed by Freepik

Podobał Ci się wpis? Podziel się ze znajomymi:


Najnowsze wpisy

CzytanQA: Fakap

„Fakap, czyli moja przygoda z korpoświatem” – reportaż Dana Lyonsa, 50-latka po nagłym zwolnieniu z Newsweeka zmuszonego do podjęcia pracy w Start-upie

Just wanting it isn’t enough

Chciałam dzisiaj zrecenzować dla Was „Fakap”, ale po południu wybrałam się pobiegać i… zmieniłam zdanie. Dzisiejszy wpis będzie trochę o testowaniu, trochę o życiu.

Koa11y, czyli jak testować dostępność szybko i przyjemnie

Kolega zapytał mnie, dlaczego nie testujemy dostępności albo wydajności z punktu widzenia usera. Odpowiedziałam mu: nie wiem czemu, ale się domyślam 🙂

CzytanQA: Błądzą wszyscy (ale nie ja)

Czasem trzeba odłożyć techniczne sprawy na bok i zadbać o tzw. Softskille

Czy warto chodzić na nietesterkie meetupy?

W ubiegłą środę wybrałam się na katowicki meet.js – meetup dla front-endowców. Jeden z tematów był poświęcony frameworkowi do testów End-To-End.