Automatyczne testowanie ułatwień dostępu

W ramach tego kursu omówiliśmy kwestie indywidualne, biznesowe i prawne związane z dostępnością cyfrową, a także podstawowe informacje na temat jej zgodności z przepisami. Zgłębiliśmy konkretne tematy związane z projektowaniem i kodowaniem promującym integrację społeczną, w tym m.in. kiedy używać ARIA, a HTML, jak mierzyć kontrast kolorów i czy JavaScript jest istotny.

W pozostałych modułach przechodzimy od projektowania i tworzenia aplikacji do testowania ułatwień dostępu. Wykorzystamy 3-etapowy proces testowania, który obejmuje automatyczne, ręczne i wspomagające narzędzia i techniki do testowania technologii. W tych modułach testowych będziemy korzystać z tej samej wersji demonstracyjnej, aby zmieniać stan strony internetowej z niedostępnej w dostępną.

Każdy test – zautomatyzowany, ręczny i technologia wspomagający – ma kluczowe znaczenie dla osiągnięcia jak największej dostępności usługi.

Nasze testy opierają się na wytycznych dotyczących dostępności treści internetowych (WCAG) 2.1 i poziomach zgodności A i AA. Pamiętaj, że to, jakich wytycznych należy przestrzegać, i poziomy, jakie należy spełnić, zależy od branży, typu produktu, przepisów i zasad lokalnych/krajowych oraz ogólnych celów związanych z ułatwieniami dostępu. Jeśli nie potrzebujesz konkretnego standardu w przypadku swojego projektu, zalecamy korzystanie z najnowszej wersji WCAG. Więcej informacji o kontroli ułatwień dostępu, typach/poziomach zgodności, WCAG i PUR znajdziesz w artykule „Jak mierzona jest dostępność cyfrowa?”.

Jak wiesz, dostosowanie się do ułatwień dostępu nie o to chodziło w przypadku osób z niepełnosprawnościami. To jednak dobry punkt wyjścia, ponieważ zawiera on dane, które można przetestować. Zachęcamy do podjęcia dodatkowych działań poza testowaniem zgodności z ułatwieniami dostępu, na przykład do przeprowadzenia testów z zakresu ułatwień dostępu z udziałem osób z niepełnosprawnościami, zatrudnienia osób z niepełnosprawnościami do pracy w zespole albo konsultacji z osobą lub firmą posiadającą wiedzę w zakresie ułatwień dostępu, która pomoże w tworzeniu usług silniej promujących integrację społeczną.

Podstawy testowania automatycznego

Automatyczne testowanie ułatwień dostępu wykorzystuje oprogramowanie do skanowania produktu cyfrowego pod kątem problemów z ułatwieniami dostępu i zgodności ze wstępnie zdefiniowanymi standardami zgodności z ułatwieniami dostępu.

Zalety automatycznych testów ułatwień dostępu:

• łatwe do powtórzenia testów na różnych etapach cyklu życia produktu.
• Jeszcze tylko kilka kroków i uzyskasz bardzo szybkie wyniki
• Do przeprowadzania testów i interpretowania wyników wymagana jest niewielka wiedza o ułatwieniach dostępu

Wady automatycznych testów ułatwień dostępu:

• Automatyczne narzędzia nie wychwytują wszystkich błędów związanych z ułatwieniami dostępu w Twojej usłudze
• Zgłoszone przypadki fałszywych trafień (zgłoszono problem, który nie jest rzeczywistym naruszeniem zasad WCAG)
• W przypadku różnych typów usług i ról może być potrzebnych wiele narzędzi

Testy automatyczne to świetny pierwszy krok do sprawdzenia ułatwień dostępu w witrynie lub aplikacji. Pamiętaj jednak, że nie wszystkie testy można zautomatyzować. Sposób sprawdzania ułatwień dostępu w elementach, których nie można zautomatyzować, omówimy bardziej szczegółowo w module ręcznego testowania ułatwień dostępu.

Rodzaje zautomatyzowanych narzędzi

Jedno z pierwszych automatycznych narzędzi online do testowania ułatwień dostępu zostało opracowane w 1996 roku przez Center for Applied Special Technology (CAST) i nazywa się The Bobby Report (Raport o nich). Obecnie masz do wyboru ponad 100 automatycznych narzędzi testowych.

Automatyczne wdrażanie narzędzi różni się od rozszerzeń w przeglądarce z ułatwieniami dostępu przez sieci z kodu, aplikacji komputerowych i mobilnych, paneli online, a nawet interfejsów API typu open source, których można używać do tworzenia własnych zautomatyzowanych narzędzi.

Wybór zautomatyzowanego narzędzia zależy od wielu czynników, w tym:

• Jakie standardy zgodności i poziomy zgodności przeprowadzasz z klientem? Zasada ta może obejmować WCAG 2.1, WCAG 2.0, U.S. Article 508 lub zmodyfikowaną listę reguł ułatwień dostępu.
• Jakiego rodzaju produkt cyfrowy testujesz? Może to być witryna, aplikacja internetowa, natywna aplikacja mobilna, plik PDF, kiosk lub inna usługa.
• Na którym etapie cyklu tworzenia oprogramowania testujesz swój produkt?
• Ile czasu zajmuje konfiguracja i używanie narzędzia? Dla osoby fizycznej, zespołu lub firmy?
• Kto przeprowadza test: projektanci, programiści, kontrola jakości itp.?
• Jak często dostępność ma być sprawdzana? Jakie szczegóły powinny zawierać raport? Czy problemy powinny być bezpośrednio powiązane z systemem sprzedaży biletów?
• Które narzędzia sprawdzają się najlepiej w Twoim środowisku? Dla Twojego zespołu?

Należy też wziąć pod uwagę wiele dodatkowych czynników. Przeczytaj artykuł WAI na temat „Selecting Web Accessibility Evaluation Tools” (Wybieranie narzędzi do oceny ułatwień dostępu w internecie), aby dowiedzieć się, jak wybrać najlepsze narzędzie dla siebie i Twojego zespołu.

Prezentacja: automatyczny test

Do automatycznego testowania ułatwień dostępu będziemy używać narzędzia Lighthouse w Chrome. Lighthouse to zautomatyzowane narzędzie open source opracowane z myślą o poprawie jakości stron internetowych na podstawie różnego rodzaju audytów, np. pod kątem wydajności, SEO i ułatwień dostępu.

Nasza demonstracja to strona internetowa stworzona dla zmyślonej organizacji – Medical Mysteries Club. Ta strona została celowo niedostępna dla tej wersji demonstracyjnej. Niektóre z nich możesz widzieć, ale nie wszystkie – zostaną wykryte przez nasz automatyczny test.

Krok 1

Zainstaluj rozszerzenie Lighthouse w przeglądarce Chrome.

Można zintegrować Lighthouse z procesem testowania na wiele sposobów. W tej wersji demonstracyjnej użyjemy rozszerzenia do Chrome.

Krok 2

Przygotowaliśmy wersję demonstracyjną w CodePen. Aby kontynuować kolejne testy, wyświetl go w trybie debugowania. To ważne, ponieważ usuwa element <iframe> otaczający demonstracyjną stronę internetową, co może zakłócać działanie niektórych narzędzi testowych. Dowiedz się więcej o trybie debugowania w CodePen.

Krok 3

Otwórz Narzędzia deweloperskie w Chrome i przejdź na kartę Lighthouse. Odznacz wszystkie opcje kategorii oprócz „Ułatwienia dostępu”. Pozostaw tryb domyślny i wybierz typ urządzenia, na którym przeprowadzasz testy.

Krok 4

Kliknij przycisk „Analizuj wczytanie strony” i poczekaj na uruchomienie testów narzędzia Lighthouse.

Po zakończeniu testów Lighthouse wyświetla wynik, który określa dostępność testowanego produktu. Wynik Lighthouse jest obliczany na podstawie liczby i rodzajów problemów oraz ich wpływu na użytkowników.

Oprócz oceny raport Lighthouse zawiera szczegółowe informacje o wykrytych problemach oraz linki do zasobów, z których dowiesz się, jak je rozwiązać. Raport zawiera też testy, które zostały zaliczone lub nie mają zastosowania, oraz listę dodatkowych elementów do sprawdzenia ręcznie.

Krok 5

Teraz przyjrzymy się przykładom każdego wykrytego automatycznie problemu z ułatwieniami dostępu, a potem naprawmy odpowiednie style i znaczniki.

Problem 1. Role ARIA

Pierwszy problem brzmi: „W elementach z atrybutem [role] ARIA, które wymagają, aby elementy podrzędne zawierały określoną rolę [role], brakuje niektórych lub wszystkich wymaganych elementów podrzędnych. Niektóre role nadrzędne ARIA muszą zawierać określone role podrzędne, aby realizować założone funkcje ułatwień dostępu. Więcej informacji o regułach ról ARIA

W naszej wersji demonstracyjnej działanie przycisku subskrypcji newslettera nie działa:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Naprawmy to.

Przycisk „Subskrybuj” obok pola do wprowadzania danych ma przypisaną nieprawidłową rolę ARIA. W takim przypadku można całkowicie usunąć tę rolę.

<button type="submit" tabindex="1">Subscribe</button>

Problem 2. Ukryto funkcję ARIA

Elementy "[aria-hidden="true"] zawierają elementy podrzędne, które można zaznaczyć. Możliwe do zaznaczenia elementy podrzędne w elemencie [aria-hidden="true"] nie są dostępne dla użytkowników technologii wspomagających, takich jak czytniki ekranu. Więcej informacji o regułach aria-hidden

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Naprawmy to.

Do pola do wprowadzania danych zastosowano atrybut aria-hidden="true". Dodanie tego atrybutu ukrywa element (i wszystko pod nim) przed elementami wspomagającymi.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

W takim przypadku usuń ten atrybut z danych wejściowych, aby umożliwić osobom używającym technologii wspomagających dostęp do danych i wpisanie informacji w polu formularza.

Problem 3: Nazwa przycisku

Przyciski nie mają nazwy na potrzeby ułatwień dostępu. Gdy przycisk nie ma nazwy ułatwień dostępu, czytniki ekranu określają go jako „przycisk”, przez co jest on bezużyteczny dla ich użytkowników. Więcej informacji o regułach nazw przycisków

<button role="list" type="submit" tabindex="1">Subscribe</button>

Naprawmy to.

Jeśli w problemie 1 usuniesz nieprawidłową rolę ARIA z elementu przycisku, nazwa przycisku „Subskrybuj” stanie się dostępna. Ta funkcja jest wbudowana w semantyczny element przycisku HTML. W bardziej złożonych sytuacjach warto rozważyć dodatkowe typy wzorców.

<button type="submit" tabindex="1">Subscribe</button>

Problem 4. Atrybuty alternatywne obrazu

W elementach graficznych brakuje atrybutów [alt]. Elementy informacyjne powinny mieć krótki, opisowy tekst zastępczy. Elementy dekoracyjne można zignorować, tworząc pusty atrybut alt. Więcej informacji o regułach dotyczących tekstu alternatywnego obrazu

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Naprawmy to.

Obraz logo również jest linkiem, więc z modułu obrazu wiesz, że jest to obraz zachęcający do działania i wymaga podania alternatywnych informacji tekstowych o przeznaczeniu obrazu. Normalnie pierwszy obraz na stronie to logo, więc można założyć, że użytkownicy sieci AT będą o tym wiedzieć i zdecydować się nie dodawać dodatkowych informacji kontekstowych do opisu obrazu.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problem 5. Tekst linku

Linki nie mają wyróżniającej ich nazwy. Tekst linków (i tekst zastępczy obrazów używanych jako linki), który jest wyraźny, unikalny i możliwy do wybrania, ułatwia nawigację użytkownikom czytników ekranu. Więcej informacji o regułach tekstu linku

<a href="#!"><svg><path>...</path></svg></a>

Naprawmy to.

Wszystkie obrazy na stronie muszą zawierać informacje o tym, dokąd link przekieruje użytkowników. Jednym ze sposobów rozwiązania tego problemu jest dodanie do obrazu tekstu alternatywnego, tak jak w przypadku obrazu logo w przykładzie powyżej. Sprawdza się to w przypadku obrazów z tagiem <img>, ale tagi <svg> nie mogą korzystać z tej metody.

W przypadku ikon mediów społecznościowych, które używają tagów <svg>, możesz użyć innego alternatywnego wzorca opisu kierowania na pliki SVG, dodać informacje między tagami <a> i <svg>, a następnie ukryć je przed użytkownikami, dodać obsługiwaną ARIA lub skorzystać z innych opcji. W zależności od środowiska i ograniczeń dotyczących kodu jedna metoda może być preferowana zamiast drugiej. Użyjmy najprostszego wzorca obejmującego najbardziej przydatne technologie, czyli dodajmy element role="img" do tagu <svg> i element <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problem 6. Kontrast kolorów

Kolory tła i pierwszego planu nie mają wystarczającego współczynnika kontrastu. Wielu użytkowników ma problemy z czytaniem tekstu o niskim kontraście. Więcej informacji o regułach kontrastu kolorów

Zgłoszono 2 przykłady.

Naprawmy to.

Na stronie internetowej wykryto wiele problemów z kontrastem kolorów. Jak dowiedzieliśmy się z modułu kolorów i kontrastu, wymagania dotyczące kontrastu kolorów w standardowym rozmiarze (mniej niż 18 punktów / 24 piksele) muszą być zgodne, a duży tekst (co najmniej 18 punktów / 24 piksele lub pogrubiony 14 punktów / 18,5 pikseli) i podstawowe ikony – z wymaganiami dotyczącymi kontrastu kolorów 3:1.

W przypadku tytułu strony tekst w kolorze morskim musi spełniać wymagania dotyczące kontrastu kolorów 3:1, ponieważ jest to tekst o dużym rozmiarze, czyli 24 piksele. Z kolei przyciski w kolorze morskim mają standardowy rozmiar i pogrubiono 16 pikseli, a więc ich kontrast musi wynosić 4, 5:1.

W tym przypadku moglibyśmy znaleźć kolor morski, który był wystarczająco ciemny, by osiągnąć proporcje 4,5:1, lub zwiększyć rozmiar tekstu przycisku do 18,5 piksela pogrubiony i nieco zmienić wartość koloru turkusowego. Każda z tych metod będzie pasować do estetyki projektu.

Cały szary tekst na białym tle nie ma też wpływu na kontrast kolorów. Wyjątkiem są 2 największe nagłówki na stronie. Tekst musi być przyciemniony, aby zachować zgodność z wymaganiami dotyczącymi kontrastu kolorów 4,5:1.

7. Struktura listy

Elementy list (<li>) nie znajdują się wewnątrz elementów nadrzędnych <ul> lub <ol>. Elementy list (<li>) muszą być zawarte w elemencie nadrzędnym <ul> lub <ol>, aby czytniki ekranu mogły je prawidłowo odczytać.

Więcej informacji o regułach listy

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Naprawmy to.

W tej wersji demonstracyjnej użyliśmy klasy CSS do symulowania listy nieuporządkowanej zamiast tagu <ul>. Usunęliśmy z niego wbudowane semantyczne funkcje HTML, które zostały zapisane w nieprawidłowym kodzie. Problem z ułatwieniami dostępu można rozwiązać, zastępując klasę prawdziwym tagiem <ul> i modyfikując powiązany kod CSS.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

8. indeks tabulacji

Niektóre elementy mają wartość [tabindex] większą niż 0. Wartość większa niż 0 sugeruje bezpośrednią kolejność nawigacji. Chociaż jest to logiczne rozwiązanie, często jest to frustrujące u użytkowników technologii wspomagających osoby z niepełnosprawnością. Więcej informacji o regułach indeksu tabulacji

<button type="submit" tabindex="1">Subscribe</button>

Naprawmy to.

O ile nie ma konkretnego powodu do zakłócenia naturalnego porządku wyświetlania tabulatorów na stronie internetowej, nie ma potrzeby używania dodatniej liczby całkowitej w atrybucie tabindex. Aby zachować naturalną kolejność znaków tabulacji, możemy zmienić indeks tabulacji na 0 lub całkowicie usunąć dany atrybut.

<button type="submit">Subscribe</button>

Krok 6

Skoro wszystkie problemy z automatycznymi ułatwieniami dostępu zostały już rozwiązane, otwórz nową stronę trybu debugowania. Ponownie uruchom kontrolę ułatwień dostępu w Lighthouse. Twój wynik powinien być dużo lepszy niż za pierwszym razem.

Wszystkie automatyczne aktualizacje ułatwień dostępu zastosowaliśmy w nowym CodePen.

Następny krok

Dobra robota. Udało Ci się wiele osiągnąć, ale to jeszcze nie koniec! Następnie przejdziemy do ręcznego sprawdzania ułatwień dostępu, zgodnie z opisem w module ręcznego testowania ułatwień dostępu.

Sprawdź swoją wiedzę

Sprawdź swoją wiedzę na temat automatycznego testowania ułatwień dostępu