Wprowadzenie
Wykonanie audytu dużej witryny złożonej z dziesiątków stron niewątpliwie wymaga wiedzy, doświadczenia, biegłości i sprawności w posługiwaniu się i dokumentacją, i narzędziami wspomagającymi audytora. Ale… Zanim zostaniesz doświadczonym audytorem dostępności, musisz najpierw przejść etap zdobywania i gromadzenia doświadczeń i przećwiczyć różne podejścia do oceny dostępności. Z czasem, w miarę zdobywania doświadczenia, opracujesz własną metodykę czy metodologię oceny. Odkryjesz również najlepsze dla siebie narzędzia i procedury. Ale zaczynaj od małych kroków.
Jednym z nich jest opanowanie umiejętności oceny pojedynczej strony.
Każdy, kto chce oceniać dostępność cyfrową, musi wypracować swoje własne procedury postępowania, swoją własną metodologię. Oczywiście, nie chodzi o to, aby wymyśleć od przysłowiowego zera wszystkie techniki postępowania. Chodzi o to, aby dobrać techniki najbardziej efektywne dla siebie i ująć je w przemyślany, odpowiednio ułożony, skuteczny plan działania.
Krok 1. Wstępny przegląd witryny i ocenianej strony
Zawsze zaczynaj od pobieżnego przeglądu strony, którą zamierzasz ocenić, aby się zorientować, co będziesz oceniać, i dostosować swoją procedurę oceniania do tej konkretnej strony.
Krok 1a. Poznaj miejsce strony w strukturze witryny
Wstępny ogląd strony poprzedzamy zazwyczaj eksploracją całej witryny, aby się zorientować, jakie jest miejsce ocenianej strony w witrynie:
- czy jest to strona główna, osadzona najwyżej w strukturze witryny, otwierająca witrynę, wspólna dla wszystkich stron witryny, przedstawiająca jej cel, treści, kierująca do różnych głównych obszarów witryny i do treści polecanych, na przykład najnowszych
- czy jest to strona docelowa, czyli strona osadzona najniżej w strukturze witryny, ale – wraz ze wszystkimi stronami docelowymi – prezentująca główne treści witryny, artykuł, formularz kontaktowy, itp.
- czy jest to strona przejściowa (nawigacyjna), osadzona w strukturze witryny między stroną główną (którą też można by zaliczyć do stron przejściowych), a stronami docelowymi – umożliwiająca użytkownikom orientację w treściach witryny i dotarcie do stron docelowych z danego obszaru witryny (kategorii, działu),
- czy jest to strona wspólna dla całej witryny innego rodzaju niż strona główna, na przykład strona z warunkami użytkowania, deklaracją dostępności czy strona z mapą witryny. Każdy z tych czterech typów stron jest specyficzny, bo każdemu z nich przyświeca inny ogólny cel, a ocena skuteczności spełniania przez stronę jej celu jest podstawowym aspektem oceny dostępności cyfrowej. Bo przecież w ocenie dostępności cyfrowej chodzi nam o to, by sprawdzić, czy każdy użytkownik, na dowolnym urządzeniu, na dowolnym programie użytkownika (przeglądarce), z dowolnego rodzaju połączenia, w każdych warunkach, niezależnie od swojej sprawności, uzyskał dostęp do wszystkich treści i do wszystkich funkcji na stronie, aby mógł wykonać wszystkie zadania, którym strona służy.
Krok 1b. „Wyodrębnij” do oceny kluczowe aspekty strony
Raczej rzadko się zdarza, aby audytor analizował na każdej stronie spełnienie wszystkich kryteriów sukcesu WCAG, aby badał dokładnie każdy aspekt strony. Raczej jest tak, że w oparciu o swoje doświadczenie, intuicję, wyczucie, wybiera do oceny aspekty istotne dla konkretnej strony. Można by rzec, że uruchamia swój siódmy zmysł, który mu podpowiada, czym się musi zająć, a co może pominąć. lm większe ma doświadczenie, tym „siódmy zmysł” jest sprawniejszy. Oczywiście, siódmego zmysłu nie ma, a to, że jego wybory są trafne, wynika po prostu z doświadczenia. Ot widzi szybciej, dostrzega więcej. Obejrzyj stronę, którą masz ocenić, i rozważ takie kwestie:
- Cel. Czy możesz określić, do czego służy ta strona? Czy jest to strona docelowa, przejściowa, główna, wspólna? Które elementy strony realizują jej główny cel?
- Struktura. Jaki jest układ treści? Jakie kluczowe obszary można wyróżnić na stronie? Które z tych obszarów powtarzają się na innych stronach? Które elementy są unikalne? Czy struktura strony służy realizacji głównego celu strony? Pomocne może być sporządzenie szkicu strony, schematu jej zawartości.
- Prezentacja. Czy wszystkie elementy na stronie są zauważalne? Widoczne? Czy istnieją ukryte treści i czy można je zobaczyć, odsłonić?
- Nawigacja. Jak mogę poruszać się po stronie? Czy mogę dostać się do wszystkiego na stronie?
- Interakcja. Co mogę zrobić na tej stronie? Jakie zadanie lub zadania mogę wykonać? Czy mogę je wykonać?
Krok 2. Określ zakres oceny
Zdecyduj, czy chcesz ocenić wszystkie, czy tylko wybrane elementy strony.
Zazwyczaj oceniamy dostępność kluczowego, głównego obszaru strony i elementów, które są z nim powiązane bezpośrednio. Jeśli zdecydujesz się ocenić tylko wybrane elementy strony, zdecyduj, które elementy będą oceniane.
Elementy, które pojawiają się standardowo na wszystkich lub wielu stronach, takie jak nagłówek, stopka, menu administratora, oceniamy osobno. Oczywiście wszystkie inne wykryte problemy z dostępnością można zgłosić w raporcie, ale należy skupić się na specyficznych cechach testowanej strony lub ocenie wybranego elementu interfejsu użytkownika.
Krok 2a. Wybierz elementy strony do oceny
Odpowiedz sobie na pytania:
- Co jest główną treścią strony? Które aspekty głównej treści strony wymagają oceny pod względem dostępności?
- Które elementy strony są unikalne (nie pojawiły się jeszcze na wcześniej badanych stronach)? Jakie aspekty tych elementów wymagają zbadania?
- Czy na stronie są stałe elementy (powtarzające się na innych stronach)? Które elementy strony powtarzają się na innych stronach tego samego typu bądź na wszystkich stronach witryny?
- Czy w elementach stałych widoczne są jakieś zmiany? Jeśli wcześniej tego typu elementy były już badane i oceniane, zauważenie zmian może sygnalizować potrzebę ich ponownej oceny.
Krok 2b. Zbadaj drzewo dostępności strony (opcjonalnie)
Spróbuj, nawet jeśli wydaje Ci się to skomplikowane czy zbyt techniczne. Drzewo dostępności to ukryty na stronie zbiór informacji niezwykle ważnych dla technologii wspomagających. Drzewo dostępności jest podobne do drzewa DOM (Obiektowego Modelu Dokumentu). Mówiąc precyzyjniej, drzewo dostępności jest podzbiorem DOM obejmującym tylko obiekty istotne dla dostępności strony. Słowo „drzewo” podkreśla hierarchiczną strukturę tego zbioru obiektów. Wszystkie obiekty wyrastają bezpośrednio lub pośrednio ze wspólnego pnia, który jest obiektem nadrzędnym, macierzystym, głównym węzłem. Ten węzeł to document.
Słowo „wyrastają” opisuje raczej wygląd drzewa dostępności niż rzeczywistą strukturę, którą można sobie wyobrazić jako podobną do ludowej zabawki rosyjskiej, matrioszce, złożonej z drewnianych, wydrążonych w środku lalek, włożonych jedna w drugą, z tym, że w matrioszce wewnątrz kolejnej babuszki znajduje się tylko jedna mniejsza, a w drzewie dostępności na każdym poziomie może znajdować się wiele równorzędnych obiektów zawierających kolejne.
A ponieważ w drzewie dostępności zawarte są wszystkie istotne dla dostępności informacje o każdym obiekcie strony, ważne jest, aby – nawet jeśli nie masz odpowiedniej wiedzy technicznej – od zaraz zaprzyjaźnić się z jego widokiem. Zwłaszcza, że od pewnego czasu jest to niezwykle łatwe. Wystarczy skorzystać z przeglądarki Firefox, która – pewno tylko na razie – jako jedyna oferuje podgląd drzewa dostępności i przeprowadzenia fundamentalnego dla oceny dostępności strony oglądu jej właściwości budujących dostępność.
- Zapoznaj się z poradnikiem Inspektor dostępności w przeglądarce Firefox, aby się dowiedzieć, jak możesz wykorzystać to narzędzie w ocenie dostępności strony.
- Korzystając z Inspektora dostępności, sprawdź:
- Czy na stronie występują problemy z obiektami bez nazw?
- Czy na stronie występują problemy dostępności związane z klawiaturą?
- Czy na stronie znajdują się elementy z niewystarczającym kontrastem?
Drzewo dostępności można filtrować, aby wyświetlać tylko obiekty, które nie mają odpowiednich nazw, albo mogą powodować problemy z klawiaturą, czy też nie mają odpowiedniego kontrastu.
Nazwa jest podstawowym źródłem informacji dla technologii wspomagających. Informuje użytkownika, co dany element robi. Na przykład etykieta przycisku Wyślij informuje technologię, a za jej pośrednictwem użytkownika, że po aktywacji przycisku nastąpi przesłanie formularza. Inspektor testuje wszystkie obiekty i sprawdza, czy posiadają nazwę określoną programowo.
Interpretacja wyników, jakich dostarcza Inspektor dostępności, może ci sprawić trochę kłopotów. Z czasem nabędziesz doświadczenia. Na początku po prostu odnotuj wszystko, co jest według ciebie warte odnotowania. Na przykład wszystkie problemy z obiektami bez nazw powinny zostać rozwiązane, a więc odnotowane w raporcie z oceny. Także problemy z niewystarczającym kontrastem warto wynotować, choć w tej mierze być może łatwiej ci będzie skorzystać z innego narzędzia.
Największy kłopot mogą sprawić wskazane przez Inspektora dostępności problemy z klawiaturą. Potraktuj je więc jako sygnały, które należy sprawdzić innym sposobem.
Uwaga: Badanie drzewa dostępności nie jest ani konieczne, ani niezbędne, by ocenić dostępność strony. Może jednak być bardzo pomocne. Z czasem nauczysz się odkrywać w drzewie dostępności źródła wielu początkowo niezrozumiałych problemów z dostępnością. Każdy obiekt w drzewie dostępności ma – a raczej powinien mieć zdefiniowane różne właściwości. Jeśli nie są one odpowiednio określone, są źródłem problemów dostępności. Na przykład, jeśli obiekt nie ma dostępnej nazwy, czytnik ekranu nie ogłosi użytkownikowi informacji o obiekcie. Jeśli stan pola wyboru albo istotny stan niektórych przycisków nie jest określony, niezbędnych informacji nie otrzyma użytkownik czytnika ekranu czy wyświetlacza brajlowskiego.
Krok 3. Wykonaj testy automatyczne i zweryfikuj ich wyniki
Nie trać cennego czasu na szukanie błędów, które mogą zostać wykryte przez testy automatyczne. Automatyczne testowanie zapewnia, że około 25% najlepszych praktyk w zakresie dostępności może być dokładnie przetestowane. Ponadto, testy automatyczne mogą wskazywać dalsze 35% problemów, które muszą być potwierdzone przez człowieka. Dlatego najlepiej jest zacząć od testów automatycznych.
Istnieje wiele bardzo dobrych narzędzi do testów automatycznych i powstają nowe. Narzędzia te pomagają zorganizować ocenę i mogą zapewnić wgląd w problemy, które nie są łatwo rozpoznawalne. Żadne narzędzie nie robi wszystkiego. Dlatego dobrym pomysłem jest zapoznanie się z różnymi dostępnymi narzędziami i skorzystanie z kilku wybranych. Oto kilka sugestii do rozważenia:
- WAVE: rozszerzenie przeglądarki oferowane przez WebAlM, które pozwala na ocenę dostępności stron internetowych bezpośrednio w Chrome i Firefox. Może również sprawdzać strony, do których dostęp jest chroniony hasłem.
- ARC Toolkit: ARC Toolkit jest rozszerzeniem dla przeglądarki Chrome. Szybko i skutecznie testuje pojedyncze strony pod kątem dostępności i wskazuje niezgodności z kryteriami sukcesu na poziomie A i AA wytycznych WCAG 2.1 bądź sytuacje, które wymagają dodatkowej weryfikacji przez człowieka. Oceniane reguły silnika ARC są zorganizowane w kategorie i podkategorie: Media (Obrazy, Obrazy tła, Bogate media), Struktura (Nagłówki, Punkty orientacyjne, Listy, Akapity, Treść generowana, Tabele, Formularze, Ramki, Tytuły, Wyróżnianie tekstu, Języki), Klawiatura (Łącza, Łącza wewnętrzne, Przyciski, Klawisze dostępu, Indeks tabulacji, Porządek tabulacji), ARIA (ARIA Ul, ARIA Live, ARIA Usage, ARIA Hidden), Kolor (Kontrast koloru), Identyfikatory. Nazwy kategorii i podkategorii są nagłówkami wierszy tabeli, prezentującej wyniki w sześciu kolumnach. Kolumny w tabeli wyników pokazują liczbę widocznych i niewidocznych wystąpień, w tym błędów i ostrzeżeń.
- Accessibility Insights for Web: rozszerzenie dla Chrome i Microsoft Edge Insider, które pomaga programistom znaleźć i naprawić problemy z dostępnością w aplikacjach i witrynach internetowych. Narzędzie obsługuje dwa podstawowe scenariusze: 1) FastPast dwuetapowy proces obejmujący około 20 testów i testy obsługi klawiatury oraz 2) Assessment – ocena wspomagana testami automatycznymi i kompletem wskazówek i instrukcji dla audytora.
- HTML CodeSniffer: skryptozakładka uruchamiana we wszystkich popularnych przeglądarkach, analizuje kod źródłowy przeglądanej strony i wykrywa możliwe naruszenia standardów kodowania i standardów dostępności. Nie tylko sprawdza wiele predefiniowanych reguł, ale może być rozszerzona o własne reguły. HTML_CodeSniffer bada zgodność ze standardami WCAG 2.0. Skrypt jest rozwijany i aktualizowany. Jest przetłumaczony na język polski (przełącza się na język polski automatycznie, jeżeli w znaczniku html określono poprawnie kod języka)
- ANDI (Accessible Name and Description Inspector): skryptozakładka uruchamiana w popularnych przeglądarkach. ANDI dzieli testy na moduły. Przy pierwszym ładowaniu uruchamiany jest moduł domyślny, który analizuje elementy interaktywne, kolejność tabulacji i występowanie klawiszy dostępu. Kolejne moduły umożliwiają analizę elementów graficznych, linków i przycisków, tabel, struktury (nagłówki, listy, punkty orientacyjne, atrybuty ARIA, atrybuty języka), kontrast i elementy ukryte. Wybierając moduł z listy rozwijanej wyboru modułu, możesz metodycznie przetestować różne obszary dostępności.
- totally – accessibility visualization toolkit: kolejna skryptozakładka z zestawem narzędzi do wizualizacji dostępności. Wskazuje błędy dostępności i sugeruje sposoby ich naprawienia. Wybór opcji w totally wyposaży Cię w niesamowite okulary, dzięki którym przetestujesz kilka istotnych aspektów na każdej badanej stronie. Zamiast skryptozakładki można też zainstalować dodatek do przeglądarki. Po uaktywnieniu skryptozakładki w lewym dolnym narożniku przeglądarki pojawi się ikona przedstawiająca wspomniane okulary. Wybranie ikony uaktywni listę opcji, wśród których są: Headings: wyróżnia i wyświetla nagłówki, w oknie wyskakującym wyświetla konspekt nagłówków, Contrast: oznacza etykietami elementy z niewystarczającym kontrastem, Link text: identyfikuje łącza, które mogą być mylące po odczytaniu przez czytnik ekranu, Labels: identyfikuje pola formularzy bez etykiet, Image – alt text: wykrywa obrazy bez tekstów alternatywnych, Landmarks: wyróżnia oznaczone w kodzie strony punkty orientacyjne, Screan Reader Wand: wyświetla ze wskazanego obszaru tekst widoczny dla czytnika ekranu.
- axe dla Chrome: rozszerzenie przeglądarki, mała, przenośna, lekka biblioteka JavaScript oferowana przez Deque University, która wykonuje automatyczne testy dostępności wewnątrz przeglądarki. Ponieważ działa w przeglądarce, możesz również użyć axe do sprawdzania stron chronionych hasłem.
Wszystkie te narzędzia nie tylko wykrywają i wskazują problemy związane z dostępnością, ale także wyjaśniają, czym są te problemy i sugerują, jak je rozwiązać.
Należy pamiętać, że niektóre z tych narzędzi pozwalają wybrać docelowy poziom zgodności ze standardami WCAG.
Warto przeczytać następujące artykuły w języku angielskim, aby poznać ograniczenia testów automatycznych:
- The problem with automated accessibility testing tools
- What we found when we tested tools on the world’s least-accessible webpage
- Automated Web Accessibility Testing Tools Are Not Judges
Krok 4. Wykonaj testy „ręczne”
Celem testów „ręcznych” jest ocena właściwości strony, których nie można sprawdzić automatycznie. Prawie wszystkie wymienione powyżej narzędzia wskazują, które z cech wymagają osądu człowieka, czyli „testów ręcznych”.
Aby sprawdzić dostępność elementów wymagających „testów ręcznych”, możesz:
- manipulować przeglądarką i akcesoriami (myszką, klawiaturą),
- użyć technologii wspomagających,
- badać kod źródłowy,
- badać właściwości obiektów w drzewie dostępności,
W przeprowadzeniu testów ręcznych pomoże Ci nasza baza testów podstawowych:
- Jednolita baza testów dostępności cyfrowej
- ICT Testing Baseline (Podstawowe testy TIK)
- Pomocnik adepta dostępności
W ostatniej części tego poradnika zamieszczamy również zestaw ułatwiających testowanie pytań uporządkowanych tematycznie.
Krok 5. Sprawdź stronę w warunkach specjalnych
Wiele problemów dostępności można szybciej i łatwiej odkryć w warunkach niecodziennych, specjalnych, szczególnych, w jakich przychodzi korzystać ze stron internetowych osobom ze specjalnymi potrzebami, niekoniecznie osobom z niepełnosprawnościami.
Typowymi sposobami oceny dostępności w szczególnych warunkach są:
- testy obsługi strony tylko za pomocą klawiatury
- sprawdzanie dostępności treści w technologii wspomagającej.
Krok 5a. Przetestuj obsługę strony klawiaturą
Testowanie obsługi strony tylko za pomocą klawiatury jest istotną częścią każdej oceny dostępności. Strona może zostać pomyślnie oceniona tylko wtedy, gdy spełnione są dwa warunki:
- Każda akcja na stronie może być wykonana tylko za pomocą klawiatury.
- Wszystkie interakcje z klawiaturą są przewidywalne.
Testowanie strony z klawiaturą nie wymaga żadnych specjalnych narzędzi ani umiejętności. Koniecznie należy odłączyć mysz i przykryć panel dotykowy, jeśli korzystasz z laptopa. Następnie poruszaj się po stronie za pomocą klawiatury i wykonuj możliwe zadania.
- Czy zawsze widzisz, gdzie jesteś?
- Czy masz dostęp do wszystkich funkcji?
- Czy możesz uruchomić wszystkie elementy sterujące?
- Czy nie ma gdzieś pułapki klawiatury?
Oto lista popularnych klawiszy używanych w obsłudze strony klawiaturą:
- Tab: przejście do następnych elementów interaktywnych (łącze, kontrolka formularza, przycisk)
- Shift + Tab: przejście do poprzednich elementów interaktywnych
- Klawisze strzałek: poruszanie się między przyciskami radiowymi, łączami menu, panelami kart i harmonijek, opcjami listy, suwakami, itp.
- Enter: aktywuje bieżące łącze lub przycisk, rozszerz menu, wybiera opcję menu.
- Spacja: zaznacza lub odznacza pole wyboru elementu formularza, aktywuje aktualny przycisk, rozszerza listę opcji.
- Esc: zamyka bieżące dialogowe okno modalne lub menu rozwijanego i przenosi fokus z powrotem do elementu, który wywołał okno modalne, rozwinął podmenu, itp.
Uwaga: Aby przełączyć dostępność klawiatury komputera Mac, naciśnij klawisze Control + F7. Aby aktywować klawisz Tab w Safari, przejdź do Preferencji > Zaawansowane > Dostępność i sprawdź zakładkę Naciśnij.
Krok 5b. Przetestuj obsługę strony czytnikiem ekranu
Sprawdzenie strony internetowej z czytnikiem ekranu jest nieocenionym sposobem upewnienia się, że strona jest funkcjonalnie dostępna. Możesz skorzystać z bezpłatnych czytników, takich jak:
- NVDA, przeznaczonego dla systemu Windows,
- Jaws – Job Access With Speech dla Windows (komercyjny),
- VoiceOver wbudowanego do komputerów Macintosh,
- Orca, stworzonego dla systemu Linux.
Wszystkie są bezpłatne i mają niską krzywą uczenia się.
W Windows możesz skorzystać również z systemowego Narratora. Ponadto istnieje dodatek Chromevox do przeglądarki Chrome, który wyposaża w funkcje czytnika ekranu przeglądarkę.
Więcej informacji można znaleźć w następujących artykułach:
- Korzystanie z NVDA do ewaluacji dostępności
- Using VoiceOver to Evaluate Web Accessibility
- Using JAWS to Evaluate Web Accessibility
Krok 6. Przedstaw wyniki oceny
Ocena dostępności powinna kończyć się raportem merytorycznym, aby projektanci, programiści, webmasterzy i autorzy treści mogli rozwiązać wykryte problemy.
Dobrym pomysłem jest zapisanie raportu w jednym dokumencie i użycie prostego szablonu:
- Tytuł raportu
- Proces oceny:
- Zakres oceny. Nazwa witryny i strony lub elementu interfejsu użytkownika
- Data oceny. Zakres dat, przeprowadzenia przeglądu
- Recenzenci. Nazwa oceniającego lub oceniających.
- Środowisko testowe. Krótka informacja o systemie operacyjnym, przeglądarce i jej wersji.
- Metoda i narzędzia. Opis zastosowanej metody oceny i narzędzi oraz ich wersje.
- Rezultaty i zalecane działania
- Streszczenie wyników. Stwierdzenie, czy strona spełnia/nie spełnia/ lub jest bliska spełnienia wymaganego poziomu dostępności (zwykle poziomu AA WCAG 2.1)
- Mocne strony. Wskazanie szczególnych walorów strony.
- Błędy i zalecenia
- Problem. Wymienić każdy zidentyfikowany problem
- Wyjaśnienie. Wyjaśnić, dlaczego jest to problem, jak może utrudnić użytkownikom dostęp. Opisać trudności w dostępie do obiektu i jego zawartości lub funkcjonalności.
- Odniesienia do standardów: Jeśli to możliwe, należy wskazać odniesienia do konkretnego kryterium sukcesu WCAG.
- Proponowane środki zaradcze. Zaproponowanie praktycznych technik w celu osiągnięcia zgodności lub poprawy dostępności. Możesz wskazać odpowiednie rozwiązania z dokumentu Techniki dla WCAG. Najlepiej szukać wskazówek na stronie Jak spełnić WCAG 2.1.