Automatyczne testowanie ułatwień dostępu

W tym kursie omówiliśmy już kwestie indywidualne, biznesowe i biznesowe, aspekty prawne i podstawy cyfrowych ułatwień dostępu. zgodności. Zapoznałeś/zapoznałaś się z konkretnymi tematami dotyczącymi projektowania i kodowania z uwzględnieniem wszystkich użytkowników, m.in. z tym, kiedy warto używać ARIA, a kiedy HTML, jak mierzyć kontrast kolorów oraz kiedy JavaScript jest niezbędny.

W pozostałych modułach przechodzimy od projektowania i tworzenia do testowania pod kątem dostępności. Wykorzystamy 3-etapowy proces testowania, który obejmuje zautomatyzowanych, ręcznych i wspomagających narzędzia i technik do testowania technologii. W ramach tych modułów testowych będziemy używać tego samego demonstracyjnego dokumentu, aby przejść od strony niedostępnej do dostępnej.

Każdy test – automatyczny, manualny i zaawansowany – jest kluczowy dla zapewnienia jak największej dostępności produktu.

Nasze testy opierają się na wytycznych Web Content Accessibility Guidelines (WCAG) 2.1 poziom zgodności A i AA jako do standardów statystycznych. Pamiętaj, że obowiązujące w Twojej branży, typ produktu, przepisy lokalne i krajowe oraz lub ogólne cele w zakresie ułatwień dostępu określają, Obserwuj nas i osiągaj kolejne poziomy. Jeśli w przypadku projektu nie wymagasz stosowania określonego standardu, zalecamy stosowanie najnowszej wersji WCAG. Informacje ogólne o audytach ułatwień dostępu, typach i poziomach zgodności, WCAG oraz POUR znajdziesz w artykule „Jak mierzy się ułatwienia dostępu w internecie?”.

Jak już wiesz, zgodność z wymaganiami dotyczącymi ułatwień dostępu nie oznacza jeszcze, że aplikacja jest w pełni dostosowana do potrzeb osób z niepełnosprawnością. Ale to dobry początek bo dostarcza danych, które można sprawdzić. Zachęcamy do podjęcia dodatkowych działań poza testami zgodności z wymaganiami dotyczącymi dostępności, takich jak przeprowadzanie testów użyteczności z udziałem osób niepełnosprawnych, zatrudnianie osób niepełnosprawnych do pracy w Twoim zespole lub konsultowanie się z osobą lub firmą, które mają doświadczenie w zakresie dostępności cyfrowej, aby pomóc Ci w tworzeniu produktów bardziej przyjaznych osobom z różnymi potrzebami.

Podstawy testowania zautomatyzowanego

Automatyczne testowanie ułatwień dostępu polega na skanowaniu produktu cyfrowego za pomocą oprogramowania w celu wykrycia problemów z ułatwieniami dostępu na podstawie zdefiniowanych wcześniej standardów.

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

• Łatwe do powtórzenia testy na różnych etapach cyklu życia produktu.
• Wystarczy wykonać kilka czynności, aby uzyskać bardzo szybkie wyniki.
• Do przeprowadzenia testów lub zrozumienia wyników potrzeba niewielkiej wiedzy na temat ułatwień dostępu.

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

• Automatyczne narzędzia nie wykrywają wszystkich błędów ułatwień dostępu w Twoim produkcie
• Zgłoszone fałszywe trafienia (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 wiele narzędzi

Automatyczne testowanie to doskonały pierwszy krok do sprawdzenia, czy w witrynie lub aplikacji ułatwienia dostępu, ale nie wszystkie kontrole można zautomatyzować. W modułach testów ręcznych ułatwień dostępu omówimy szczegółowo sprawdzanie ułatwień dostępu w elementach, których nie można zautomatyzować.

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) i nazwane The Bobby Report. Dziś ponad 100 narzędzi do automatycznego testowania. od:

Implementacja automatycznych narzędzi różni się od rozszerzeń ułatwień dostępu w przeglądarce aplikacje na komputery i komórki, panele informacyjne online, interfejsów API typu open source, których możesz używać do tworzenia własnych automatycznych narzędzi.

Wybór narzędzia automatycznego zależy od wielu czynników, takich jak:

• Jakie standardy i poziomy zgodności są testowane? Może to obejmować wytyczne WCAG 2.1, WCAG 2.0, sekcję 508 w ustawach Stanów Zjednoczonych lub zmodyfikowaną listę zasad dostępności.
• Jakiego typu produkt cyfrowy testujesz? Może to być strona internetowa, aplikacja internetowa, natywna aplikacja mobilna, plik PDF, terminal informacyjny lub inna usługa.
• Jaką część cyklu tworzenia oprogramowania testujesz swój produkt?
• Ile czasu zajmuje skonfigurowanie i korzystanie z narzędzia? W przypadku osoby fizycznej zespołu czy firmy?
• Kto przeprowadza test: projektanci, programiści, zespół ds. kontroli jakości czy ktoś inny?
• Jak często mają być sprawdzane ułatwienia dostępu? Jakie szczegóły należy podać ujęte w raporcie? 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?

Jest też wiele dodatkowych czynników, które trzeba wziąć pod uwagę. Aby dowiedzieć się więcej o wybieraniu najlepszych narzędzi dla siebie i swojego zespołu, przeczytaj artykuł WAI o wybieraniu narzędzi do oceny dostępności witryn internetowych.

Prezentacja: test automatyczny

W wersji demonstracyjnej automatycznego testowania ułatwień dostępu użyjemy funkcji Lighthouse. Lighthouse to automatyczne narzędzie typu open source, które służy do poprawy jakości stron internetowych za pomocą różnych typów audytów, takich jak audyt wydajności, SEO czy ułatwień dostępu.

Nasza wersja demonstracyjna jest stroną stworzoną dla zmyślonej organizacji The Medical Mysteries Klub. Ta strona jest celowo niedostępna dla wersji demonstracyjnej. Niektóre z tych problemów z dostępnością mogą być widoczne, a część z nich (ale nie wszystkie) zostanie wykryta podczas automatycznego testu.

Krok 1

W przeglądarce Chrome zainstaluj Rozszerzenie Lighthouse.

Istnieje wiele sposobów na zintegrowanie Lighthouse z procesem testowania. W tym pokazie użyjemy rozszerzenia do Chrome.

Krok 2

Utworzyliśmy demonstrację w CodePen. Otwórz je w trybie debugowania, by kontynuować i kolejnych testów. Jest to ważne, ponieważ usuwa <iframe> otaczający stronę internetową demonstracyjną, 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 otwórz kartę Lighthouse. Usuń wszystkie opcje kategorii oprócz „Ułatwienia dostępu”. Pozostaw tryb domyślny i wybierz typ urządzenia które przeprowadzają testy.

Krok 4

Kliknij Analizuj wczytanie strony i daj Lighthouse na uruchomienie testów.

Po zakończeniu testów Lighthouse wyświetla wynik, który pokazuje, testowana usługa jest dostępna. Wynik Lighthouse Jest obliczany na podstawie liczby i typów problemów oraz wpływu wykryte problemy.

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, a także z listą dodatkowych elementów do sprawdzenia ręcznie.

Krok 5

Przyjrzyjmy się teraz przykładowi każdego zautomatyzowanego problemu z ułatwieniami dostępu. znajdować i poprawiać odpowiednie style i znaczniki.

Problem 1. Role ARIA

Pierwsza kwestia: „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. Więcej informacji o regułach ról ARIA

W przykładzie wystąpił błąd przycisku subskrypcji newslettera:

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

Naprawmy to.

Przycisk „Subskrybuj” przycisk 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: Ukryto system ARIA

Elementy "[aria-hidden="true"] zawierają elementy podrzędne, które można zaznaczyć. Można zaznaczyć elementy podrzędne w elemencie [aria-hidden="true"] uniemożliwiają te interakcje. elementów technologii wspomagających osoby z niepełnosprawnością, takich jak ekran. czytelników. 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.

Pole wejściowe ma zastosowany atrybut aria-hidden="true". Dodaję ten atrybut ukrywa element (i wszystkie zagnieżdżone w nim elementy) technologii wspomagających osoby z niepełnosprawnością.

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

W takim przypadku usuń ten atrybut z pola, aby umożliwić osobom korzystającym z technologii wspomagającej dostęp do pola formularza i wprowadzanie w nim informacji.

Problem 3. Nazwa przycisku

Przyciski nie mają nazwy na potrzeby ułatwień dostępu. Gdy przycisk nie ma nazwa ułatwień dostępu, czytniki ekranu wymawiają ją jako „przycisk”, przez co jest bezużyteczna dla korzystających z czytników ekranu.

Więcej informacji o regułach dotyczących nazw przycisków

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

Naprawmy to.

Jeśli usuniesz niedokładną rolę ARIA z elementu przycisku w numer 1, słowo „Subskrybuj” stanie się przyciskiem ułatwień dostępu imię i nazwisko. Ta funkcja jest wbudowana w semantyczny element przycisku HTML. OK to dodatkowe opcje wzoru, które warto rozważyć w bardziej złożonych sytuacjach.

<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 alternatywnym tekście z obrazu .

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

Naprawmy to.

Ponieważ obraz logo jest też linkiem, wiesz z modułu dotyczącego obrazów, że jest to obraz z działaniem i wymaga podania alternatywnego tekstu informującego o jego celu. Zazwyczaj pierwsze zdjęcie na stronie jest logo, więc możesz założyć, że użytkownicy AT to wiedzą. Możesz więc zdecydować się na nie dodawanie 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ą dobrze widocznych nazw. Tekst linku (i tekst zastępczy dla obrazów, używane jako linki), które są widoczne, niepowtarzalne i które można zaznaczyć, nawigacji użytkownikom czytników ekranu. Więcej informacji o regułach tekstu linku

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

Naprawmy to.

Wszystkie obrazy z możliwością działania na stronie muszą zawierać informacje o tym, dokąd prowadzi link. Jedną z metod rozwiązania tego problemu jest dodanie na obrazku o przeznaczeniu, tak jak na obrazie logo w przykład. Sprawdza się to w przypadku zdjęć z tagiem <img>, ale <svg> tagi 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 wzorca alternatywnego opisu kierowanego na pliki SVG, dodać informacje między tagami <a> i <svg>, a następnie ukryć je przed użytkownikami, dodać obsługiwany tag ARIA lub skorzystać z innych opcji. W zależności na Twoim środowisku i ograniczeniach kodu, jedna z metod może być lepsza innego użytkownika.

Używaj najprostszej opcji wzoru, która daje największy potencjał zasięgu technologii, czyli dodania role="img" do tagu <svg> oraz oraz 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 kontrastu kolorów

Zgłoszono 2 przykłady.

.

.

Naprawmy to.

Na stronie internetowej wykryto wiele problemów z kontrastem kolorów. Jak się dowiesz w module Kolory i kontrast, tekst w standardowym rozmiarze (mniejszy niż 18 punktów / 24 piksele) musi mieć kontrast kolorów 4,5:1, a tekst w dużym rozmiarze (co najmniej 18 punktów / 24 piksele lub 14 punktów / 18,5 piksele w pogrubieniu) i podstawowe ikony muszą spełniać wymóg kontrastu 3:1.

W przypadku tytułu strony tekst w kolorze turkusowym musi spełniać wymóg kontrastu kolorów 3:1, ponieważ jest to duży tekst o rozmiarze 24 piksele. Turkusowe przyciski są jednak są uznawane za tekst o zwykłym rozmiarze i pogrubienie 16 pikseli, dlatego kolory w proporcjach 4,5:1 muszą być takie same kontrastu.

W tym przypadku udało nam się znaleźć kolor turkusowy, który był wystarczająco ciemny, aby spełnić wymagania kontrastu 4,5:1. Mogliśmy też zwiększyć rozmiar tekstu przycisku do 18,5 piksela i nieznacznie zmienić wartość koloru turkusowego. Obie metody są zgodne z projektem. estetykę.

Nie udało się uzyskać kontrastu kolorów w przypadku całego szarego tekstu na białym tle, z wyjątkiem dla dwóch największych nagłówków na stronie. Tekst musi być ciemniejszy, aby spełniał wymagania dotyczące kontrastu kolorów (4,5:1).

.

Problem 7. Struktura listy

Elementy list (<li>) nie znajdują się wewnątrz elementów nadrzędnych <ul> ani <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 tym pokazie zamiast tagu <ul> użyliśmy klasy CSS, aby zasymulować nieuporządkowaną listę. Kiedy napisaliśmy go nieprawidłowo, usunęliśmy nieodłączny element funkcji semantycznych HTML wbudowanych w ten tag. Zastępując zajęcia prawdziwymi, <ul> i modyfikując powiązany element CSS. Rozwiążemy ten problem z ułatwieniami dostępu.

<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ż jest to technicznie prawidłowe, często są frustrujące dla użytkowników technologii wspomagających osoby z niepełnosprawnością. Więcej informacji o regułach indeksu karty

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

Naprawmy to.

Chyba że nie ma konkretnego powodu, który zakłóci porządek wyświetlania za pomocą tabulatora w internecie nie trzeba stosować dodatniej liczby całkowitej w atrybucie tabindex. Do zachować naturalną kolejność wprowadzania tabindexu, więc możemy zmienić indeks tabindex na 0 lub całkowicie usunąć atrybut.

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

Krok 6

Gdy wszystkie problemy z dostępnością zostały rozwiązane, otwórz nową stronę trybu debugowania. Ponownie uruchom kontrolę ułatwień dostępu w Lighthouse. Twój wynik powinien być znacznie lepszy niż przy pierwszym uruchomieniu.

Zastosowaliśmy wszystkie te automatyczne aktualizacje ułatwień dostępu w CodePen,

Następny krok

Dobra robota. Wiele już udało Ci się osiągnąć, ale to jeszcze nie koniec! Następnie przejdziemy do ręcznych kontroli, które omówimy w module ręcznego testowania dostępności.

Sprawdź swoją wiedzę

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