Automatyczne testowanie ułatwień dostępu

W tym kursie poznaliście już indywidualne, biznesowe i prawne aspekty dostępności cyfrowej oraz podstawy zgodności z wymaganiami dotyczącymi dostępności cyfrowej. Poznałeś(-aś) konkretne tematy związane z projektowaniem i kodowaniem z uwzględnieniem zasad dostępności, m.in. kiedy używać ARIA zamiast HTML, jak mierzyć kontrast kolorów i kiedy JavaScript jest niezbędny.

W pozostałych modułach przejdziemy od projektowania i tworzenia do testowania pod kątem ułatwień dostępu. Opisujemy 3-etapowy proces testowania, który obejmuje automatyczne, ręczne i wspomagające narzędzia i techniki testowania. W tych modułach testowych będziemy używać tego samego przykładu, aby pokazać, jak krok po kroku poprawić dostępność strony internetowej.

Każdy test – automatyczny, ręczny i z użyciem technologii wspomagających – ma kluczowe znaczenie dla uzyskania produktu o jak największej dostępności. Nasze testy opierają się na poziomach zgodności A i AA wytycznych Web Content Accessibility Guidelines (WCAG) 2.1.

Pamiętaj, że to, których wytycznych należy przestrzegać i jakie poziomy osiągnąć, zależy od branży, typu produktu, lokalnych i krajowych przepisów i zasad oraz ogólnych celów związanych z dostępnością. Jeśli nie potrzebujesz konkretnego standardu dla swojego projektu, zalecamy stosowanie najnowszej wersji WCAG. Ogólne informacje o audytach dostępności, typach i poziomach zgodności, WCAG i POUR znajdziesz w sekcji „Jak mierzy się dostępność cyfrową?”.

Jak już wiesz, zgodność z wymaganiami dotyczącymi ułatwień dostępu to nie wszystko, co należy wziąć pod uwagę, jeśli chodzi o wspieranie osób z niepełnosprawnościami. Jest to jednak dobry punkt wyjścia, ponieważ dostarcza danych, które możesz wykorzystać w testach. Oprócz testów zgodności zachęcamy do podjęcia tych działań, które pomogą Ci tworzyć bardziej dostępne produkty:

• Przeprowadzaj testy użyteczności z udziałem osób z niepełnosprawnościami.
• zatrudniać w zespole osoby z niepełnosprawnościami;
• Skonsultuj się z osobą lub firmą, która ma doświadczenie w zakresie dostępności cyfrowej.

Podstawowe informacje o testach automatycznych

Automatyczne testowanie ułatwień dostępu wykorzystuje oprogramowanie do skanowania produktu cyfrowego pod kątem problemów z ułatwieniami dostępu w odniesieniu do predefiniowanych standardów zgodności z ułatwieniami dostępu.

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

• Szybko powtarzaj testy na różnych etapach cyklu życia produktu.
• Wystarczy wykonać kilka czynności, aby uruchomić test, a wyniki są dostępne bardzo szybko.
• Do przeprowadzania testów i interpretowania wyników nie jest wymagana duża wiedza na temat ułatwień dostępu.

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

• Narzędzia automatyczne nie wykrywają wszystkich błędów związanych z ułatwieniami dostępu w Twoim produkcie.
• Zgłoszone wyniki fałszywie pozytywne (zgłoszono problem, który nie jest prawdziwym naruszeniem WCAG)
• W przypadku różnych typów produktów i ról może być potrzebnych kilka narzędzi.

Testy automatyczne to świetny pierwszy krok w sprawdzaniu dostępności witryny lub aplikacji, ale nie wszystkie testy można zautomatyzować. Więcej informacji o sprawdzaniu dostępności elementów, których nie można zautomatyzować, znajdziesz w module Ręczne testowanie dostępności.

Rodzaje narzędzi automatycznych

Jedno z pierwszych internetowych narzędzi do automatycznego testowania dostępności zostało opracowane w 1996 r. przez Center for Applied Special Technology (CAST). Nosiło nazwę „The Bobby Report”. Obecnie możesz wybierać spośród ponad 100 zautomatyzowanych narzędzi do testowania.

Wdrożenie zautomatyzowanych narzędzi jest różne – od rozszerzeń przeglądarki ułatwiających dostępność po programy do sprawdzania kodu, aplikacje na komputery i urządzenia mobilne, panele online, a nawet interfejsy API typu open source, których możesz używać do tworzenia własnych zautomatyzowanych narzędzi.

To, którego narzędzia automatycznego użyjesz, może zależeć od wielu czynników, m.in.:

• Jakie standardy i poziomy zgodności są testowane? Może to obejmować WCAG 2.2, WCAG 2.1, sekcję 508 w Stanach Zjednoczonych lub zmodyfikowaną listę reguł dostępności.
• Jakiego typu produkt cyfrowy testujesz? Może to być witryna, aplikacja internetowa, natywna aplikacja mobilna, plik PDF, terminal informacyjny lub inna usługa.
• Na jakim etapie cyklu życia oprogramowania testujesz swój produkt?
• Ile czasu zajmuje skonfigurowanie i używanie narzędzia? dla osoby fizycznej, zespołu lub firmy?
• Kto przeprowadza test: projektanci, programiści, zespół ds. kontroli jakości czy ktoś inny?
• Jak często chcesz sprawdzać dostępność? Jakie szczegóły należy uwzględnić w raporcie? Czy problemy powinny być bezpośrednio powiązane z systemem zgłoszeń?
• Które narzędzia sprawdzają się najlepiej w Twoim środowisku? Dla Twojego zespołu?

Należy też wziąć pod uwagę wiele innych czynników. Więcej informacji o tym, jak wybrać najlepsze narzędzie dla siebie i swojego zespołu, znajdziesz w artykule WAI „Selecting Web Accessibility Evaluation Tools” (Wybieranie narzędzi do oceny dostępności stron internetowych).

Prezentacja: test automatyczny

W demonstracji automatycznego testowania dostępności użyjemy Lighthouse w Chrome. Lighthouse to zautomatyzowane narzędzie open source, które zostało stworzone, aby poprawiać jakość stron internetowych za pomocą różnych rodzajów audytów, takich jak wydajność, SEO i dostępność.

Nasza wersja demonstracyjna to witryna stworzona dla fikcyjnej organizacji Medical Mysteries Club. Ta witryna jest celowo niedostępna w wersji demonstracyjnej. Niektóre z tych problemów z dostępnością mogą być widoczne, a niektóre (ale nie wszystkie) zostaną wykryte w naszym teście automatycznym.

Krok 1

W przeglądarce Chrome zainstaluj rozszerzenie Lighthouse.

Istnieje wiele sposobów na zintegrowanie Lighthouse z procesem testowania. W tej wersji demonstracyjnej używamy rozszerzenia do Chrome.

Krok 2

Przygotowaliśmy demonstrację w CodePen. Wyświetl go w trybie debugowania, aby przejść do kolejnych testów. Jest to ważne, ponieważ usuwa <iframe> otaczające demonstracyjną stronę internetową, co może zakłócać działanie niektórych narzędzi testowych.

Dowiedz się więcej o trybie debugowania CodePen.

Krok 3

Otwórz Narzędzia deweloperskie w Chrome i przejdź do karty Lighthouse. Wyczyść wszystkie opcje kategorii z wyjątkiem „Ułatwienia dostępu”. Pozostaw domyślny tryb i wybierz typ urządzenia, na którym przeprowadzisz testy.

Krok 4

Kliknij Analizuj wczytanie strony i poczekaj, aż Lighthouse przeprowadzi testy.

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

Oprócz wyniku raport Lighthouse zawiera szczegółowe informacje o wykrytych problemach oraz linki do materiałów, które pomogą 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 przeanalizuj przykłady każdego wykrytego automatycznie problemu z dostępnością i popraw odpowiednie style oraz znaczniki.

Problem 1. Role ARIA

Pierwszy problem brzmi: „Elementy z atrybutem ARIA [role], których elementy podrzędne muszą zawierać określony atrybut [role], nie mają niektórych lub wszystkich tych wymaganych elementów podrzędnych. Niektóre role nadrzędne ARIA muszą zawierać określone role podrzędne, aby poprawnie realizować funkcje ułatwień dostępu”. Dowiedz się więcej o regułach dotyczących ról ARIA.

W naszej wersji demonstracyjnej przycisk subskrypcji newslettera nie działa:

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

Naprawmy to.

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

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

Problem 2. ARIA hidden

Elementy "[aria-hidden="true"] zawierają elementy podrzędne, które można zaznaczyć. Element [aria-hidden="true"] zawiera interaktywne elementy podrzędne z możliwością zaznaczenia, które są niedostępne dla użytkowników technologii wspomagających, takich jak czytniki ekranu. Więcej informacji o aria-hidden regułach

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

Naprawmy to.

Do pola wejściowego zastosowano atrybut aria-hidden="true". Dodanie tego atrybutu powoduje ukrycie elementu (i wszystkich elementów zagnieżdżonych w nim) przed technologiami 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 korzystającym z technologii wspomagających dostęp do pola formularza i wpisywanie w nim informacji.

Problem 3. Nazwa przycisku

Przyciski nie mają nazw dostępnych dla czytników ekranu. Gdy przycisk nie ma nazwy na potrzeby 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 dotyczących nazw przycisków

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

Naprawmy to.

Gdy usuniesz nieprawidłową rolę ARIA z elementu przycisku w problemie 1, słowo „Subskrybuj” stanie się dostępną nazwą przycisku. Ta funkcja jest wbudowana w semantyczny element przycisku HTML. W bardziej złożonych sytuacjach warto rozważyć dodatkowe opcje wzorców.

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

Problem 4. Atrybuty alt obrazów

Elementy graficzne nie mają atrybutów [alt]. Elementy informacyjne powinny mieć krótki, opisowy tekst zastępczy. Elementy dekoracyjne można zignorować, podając pusty atrybut alt. Więcej informacji o zasadach dotyczących tekstu alternatywnego obrazu

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

Naprawmy to.

Obraz logo jest też linkiem, więc z modułu obrazu wiesz, że jest to obraz z możliwością kliknięcia i wymaga alternatywnego tekstu opisującego jego przeznaczenie. Zwykle pierwszym obrazem na stronie jest logo, więc możesz założyć, że użytkownicy technologii wspomagających będą o tym wiedzieć. Możesz więc nie dodawać tych 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ących je nazw. Tekst linków (i tekst zastępczy obrazów używanych jako linki), który jest charakterystyczny, unikalny i możliwy do wybrania, ułatwia nawigację użytkownikom czytników ekranu. Więcej informacji o regułach dotyczących tekstu linku

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

Naprawmy to.

Wszystkie klikalne obrazy na stronie muszą zawierać informacje o tym, dokąd prowadzi link. Jednym ze sposobów rozwiązania tego problemu jest dodanie do obrazu tekstu alternatywnego opisującego jego przeznaczenie, tak jak w przypadku logo w przykładzie. Ta metoda świetnie sprawdza się w przypadku obrazu z tagiem <img>, ale nie można jej używać w przypadku tagów <svg>.

W przypadku ikon mediów społecznościowych, które używają tagów <svg>, możesz zastosować inny wzorzec opisu alternatywnego, który będzie kierowany na pliki SVG, dodać informacje między tagami <a> i <svg>, a następnie ukryć je wizualnie przed użytkownikami, dodać obsługiwany atrybut ARIA lub skorzystać z innych opcji. W zależności od środowiska i ograniczeń kodu jedna metoda może być lepsza od drugiej.

Użyj najprostszego wzorca z największym pokryciem technologii wspomagających, czyli dodaj atrybut role="img" do tagu <svg> i uwzględnij 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 mają niewystarczający współczynnik kontrastu. Wielu użytkowników ma problemy z czytaniem tekstu o niskim kontraście. Więcej informacji o regułach dotyczących kontrastu kolorów

Zgłoszono 2 przykłady.

Naprawmy to.

Na stronie wykryto wiele problemów z kontrastem kolorów. Jak już wiesz z modułu Kolor i kontrast, zwykły tekst (mniejszy niż 18 punktów / 24 piksele) musi mieć kontrast kolorów wynoszący 4,5:1, a duży tekst (co najmniej 18 punktów / 24 piksele lub 14 punktów / 18,5 piksela w przypadku pogrubienia) i ważne ikony muszą spełniać wymaganie 3:1.

W przypadku tytułu strony tekst w kolorze niebieskozielonym musi spełniać wymagania dotyczące kontrastu kolorów 3:1, ponieważ jest to tekst o dużym rozmiarze (24 piksele). Jednak przyciski w kolorze niebieskozielonym są traktowane jako tekst o standardowym rozmiarze (16 pikseli, pogrubiony), więc muszą spełniać wymaganie dotyczące kontrastu kolorów na poziomie 4,5:1.

W tym przypadku możemy znaleźć kolor turkusowy, który jest wystarczająco ciemny, aby spełnić wymagania dotyczące kontrastu 4,5:1, lub zwiększyć rozmiar tekstu na przycisku do 18,5 piksela i nieco zmienić wartość koloru turkusowego. Obie metody są zgodne z estetyką projektu.

Wszystkie szare teksty na białym tle również nie spełniają wymagań dotyczących kontrastu kolorów, z wyjątkiem 2 największych nagłówków na stronie. Ten tekst musi być ciemniejszy, aby spełniał wymagania dotyczące współczynnika kontrastu kolorów 4,5:1.

Problem 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 elementach nadrzędnych <ul> lub <ol>, aby czytniki ekranu mogły je poprawnie odczytać.

Więcej informacji o regułach list

<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, aby zasymulować listę nieuporządkowaną zamiast tagu <ul>. Gdy napisaliśmy ten kod nieprawidłowo, usunęliśmy wbudowane w ten tag semantyczne funkcje HTML. Zastępując klasę rzeczywistym tagiem <ul> i modyfikując powiązany kod CSS, rozwiązujemy ten problem z dostępnością.

<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>

Problem 8. tabindex

Niektóre elementy mają atrybut tabindex o wartości większej niż 0. Wartość większa niż 0 implikuje określoną wprost kolejność nawigacji. Chociaż takie rozwiązanie jest technicznie poprawne, często powoduje frustrację użytkowników technologii wspomagających. Więcej informacji o regułach tabindex

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

Naprawmy to.

Jeśli nie ma konkretnego powodu, aby zakłócać naturalną kolejność tabulacji na stronie internetowej, nie trzeba używać dodatniej liczby całkowitej w atrybucie tabindex. Aby zachować naturalną kolejność tabulacji, możemy zmienić wartość atrybutu tabindex na 0 lub całkowicie usunąć ten atrybut.

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

Krok 6

Po rozwiązaniu wszystkich problemów z automatyczną dostępnością otwórz nową stronę w trybie debugowania. Ponownie przeprowadź kontrolę ułatwień dostępu w Lighthouse. Twój wynik powinien być znacznie lepszy niż za pierwszym razem.

Wszystkie te automatyczne aktualizacje dotyczące ułatwień dostępu zostały zastosowane w nowym CodePen.

Następny krok

Dobra robota. Wiele już udało Ci się osiągnąć, ale to jeszcze nie koniec! Następnie przejdziemy do testów ręcznych, o których piszemy w module Ręczne testowanie dostępności.