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. Znasz już konkretne tematy związane z projektowaniem promującym integrację społeczną oraz między innymi kodowania ARIA, a także tego, kiedy używać ARIA, a kiedy HTML, jak mierzyć kontrast kolorów, gdy JavaScript jest kluczowy.

W pozostałych modułach przechodzimy od projektowania i tworzenia do testowania pod kątem ułatwień dostępu. Wykorzystamy 3-etapowy proces testowania, który obejmuje zautomatyzowanych, ręcznych i wspomagających narzędzia i technik do testowania technologii. Na W każdym module testowym użyj tej samej wersji demonstracyjnej, aby przejść z i niektórych z nich.

Każdy test – technologia zautomatyzowana, ręczna i wspomagająca – ma kluczowe znaczenie dla osiągnięcia z najbardziej przystępnym produktem.

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/krajowe oraz lub ogólne cele w zakresie ułatwień dostępu określają, które wytyczne Obserwuj nas i osiągaj kolejne poziomy. Jeśli nie wymagasz szczególnego standardu , zalecamy stosowanie najnowszej wersji WCAG. Wróć do sekcji „Jak mierzona jest dostępność cyfrowa?” ogólnych informacji o audytach dotyczących ułatwień dostępu, typach/poziomach zgodności. WCAG oraz PUR.

Wiesz już, że zgodność z ułatwieniami dostępu nie jest wyczerpującym. pomaga osobom z niepełnosprawnościami. Ale to dobry początek bo dostarcza danych, które można sprawdzić. Zachęcamy do dodatkowe działania poza testami zgodności ułatwień dostępu, takie jak: przeprowadzanie testów użyteczności dla osób z niepełnosprawnościami i zatrudnianie osób niepełnosprawność do pracy w zespole albo konsultacji z osobą lub firmą aby ułatwić tworzenie usług promujących integrację społeczną.

Podstawy testowania automatycznego

Zautomatyzowane testowanie ułatwień dostępu używa oprogramowania do skanowania produktu cyfrowego pod kątem problemy z ułatwieniami dostępu względem wstępnie zdefiniowanych standardów zgodności ułatwień dostępu.

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

• Łatwe powtarzanie testów na różnych etapach cyklu życia produktu
• Tylko kilka kroków i bardzo szybkie efekty
• Do przeprowadzenia testów lub zrozumienia wyników potrzeba niewielkiej wiedzy o ułatwieniach dostępu

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

• Automatyczne narzędzia nie wykrywają wszystkich błędów związanych z ułatwieniami dostępu w Twojej usłudze
• 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ć. Zajmiemy się nim bardziej szczegółowo, jak sprawdzić dostępność elementów, których nie można zautomatyzować w ręcznego testowania ułatwień dostępu.

Rodzaje zautomatyzowanych narzędzi

Jedno z pierwszych automatycznych narzędzi do testowania ułatwień dostępu online zostało opracowane w 1996 roku przez Center for Applied Special Technology (CAST) pod nazwą Center for Applied Special Technology (CAST) „The Bobby Report” (Raport dotyczący Bobby'ego). 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 automatycznego narzędzia zależy od wielu czynników, w tym od:

• Jakich standardów zgodności i poziomów testujesz? Może to spowodować obejmują WCAG 2.1, WCAG 2.0, U.S. Sekcja 508 lub zmodyfikowana lista reguł ułatwień dostępu.
• Jaki typ produktu cyfrowego testujesz? Może to być strona internetowa, aplikacji, natywnej aplikacji mobilnej, pliku PDF, kiosku lub innej usługi.
• W jakiej części 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 testy: projektanci, programiści, kontrolę jakości itp.?
• Jak często mają być sprawdzane ułatwienia dostępu? Jakie szczegóły należy podać ujęte w raporcie? Czy problemy muszą być bezpośrednio powiązane z biletami? system?
• 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ę. Zapoznaj się z artykułem WAI artykułu „Selecting Web Accessibility Evaluation Tools” (Wybieranie narzędzi do oceny ułatwień dostępu w internecie). .

Prezentacja: test automatyczny

W wersji demonstracyjnej automatycznego testowania ułatwień dostępu użyjemy funkcji Lighthouse. Lighthouse to zautomatyzowane narzędzie typu open source stworzone z myślą o poprawie jakości stron internetowych za pomocą różnego rodzaju audytów, np. wydajności, SEO ułatwienia 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 informacje o niedostępności mogą być dla Ciebie widoczne, a niektóre (ale nie wszystkie) zostaną przechwycone automatycznego testu.

Krok 1

W przeglądarce Chrome zainstaluj Rozszerzenie Lighthouse.

Istnieje wiele sposobów na integrację Lighthouse w proces testowania. W tej prezentacji użyjemy rozszerzenia do Chrome.

Krok 2

Utworzyliśmy wersję demonstracyjną w CodePen. Otwórz je w trybie debugowania, by kontynuować dla kolejnych testów. To ważne, ponieważ powoduje usunięcie elementu <iframe>, który otacza demonstracyjną, która może zakłócać działanie niektórych narzędzi testowych. Więcej informacji o Tryb debugowania w CodePen.

Krok 3

Otwórz Narzędzia deweloperskie w Chrome i otwórz kartę Lighthouse. Odznacz 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 przycisk „Analizuj wczytanie strony”. i poczekaj na uruchomienie testów Lighthouse.

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 też szczegółowe informacje o tym, wykryte problemy i linki do materiałów z informacjami o rozwiązywaniu problemów. . 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

Pierwszy problem dotyczy elementów z atrybutem ARIA [role], które wymagają, aby elementy podrzędne o określonej [roli] brakuje niektórych lub wszystkich wymaganych elementów podrzędnych. Niektóre role nadrzędne ARIA muszą zawierać określone role podrzędne, aby zamierzonych funkcji 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.

Do pola do wprowadzania danych zastosowano 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 musisz usunąć ten atrybut z danych wejściowych, aby umożliwić użytkownikom korzysta z technologii wspomagających osoby z niepełnosprawnością, aby uzyskiwać dostęp do informacji i wprowadzać je w tym polu.

Problem 3. Nazwa przycisku

Przyciski nie mają nazwy na potrzeby ułatwień dostępu. Gdy przycisk nie ma nazwy na ułatwienia 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 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. Funkcja ta 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 obrazu

W elementach graficznych brakuje atrybutów [alt]. Elementy informacyjne powinny mieć na celu czyli krótki, opisowy tekst zastępczy. Elementy dekoracyjne można zignorować: 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.

Obraz logo to także link, więc wiesz, [image_link], że moduł graficzny wymaga podania alternatywnego tekstu o przeznaczeniu obrazu. Normalnie pierwszy obraz na stronie to logo, możesz więc przypuszczać, użytkownicy sieci AT będą o tym wiedzieć, więc możesz nie dodawać kolejnych informacje kontekstowe 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 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 na stronie zachęcające do działania muszą zawierać informacje o tym, gdzie będzie odsyłać użytkowników. Jedną z metod rozwiązania tego problemu jest dodanie na obrazku o przeznaczeniu, tak jak na obrazie logo w powyżej. 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 korzystają z tagów <svg>, możesz użyć parametru inny alternatywny wzorzec opisu kierowania na pliki SVG, dodaj informację między tagami <a> i <svg>, a następnie ukryj ją przed użytkownikami, dodaj obsługiwaną właściwość ARIA lub skorzystaj z innych opcji. W zależności na Twoim środowisku i ograniczeniach kodu, jedna z metod może być lepsza innego użytkownika. Użyjmy najprostszej opcji wzorca, która daje największą pomoc zasięg technologii, czyli dodanie do tagu <svg> tagu role="img" 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

Zarejestrowano 2 przykłady.

.

.

. .

Poprawmy to.

Na stronie internetowej wykryto wiele problemów z kontrastem kolorów. Wiesz już, moduł kolorów i kontrastu, tekst o standardowym rozmiarze (mniej niż 18 pkt./24 piks.) wymaga kontrastu kolorów: 4,5:1, podczas gdy duży tekst (co najmniej 18 pkt / 24 piks.lub 14 pkt. / 18,5 piksela pogrubiona) oraz najważniejsze ikony muszą spełniać wymagania dotyczące formatu 3:1.

W przypadku tytułu strony tekst w kolorze morskim musi osiągnąć kontrast kolorów 3:1 wymagany, ponieważ jest to duży tekst o rozmiarze 24 pikseli. 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 znaleźliśmy odcień morski, który był na tyle ciemny, aby uzyskać współczynnik proporcji 4,5:1. możemy zwiększyć rozmiar tekstu przycisku do 18,5 pikseli pogrubioną czcionką i zmienić nieco koloru turkusowego. Obie metody będą 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. Ten tekst musi być zaciemniony, aby można było wymagania dotyczące kontrastu kolorów 4,5:1.

.

.

. .

7. Struktura listy

Elementy list (<li>) nie znajdują się wewnątrz elementów nadrzędnych <ul> ani <ol>. Czytniki ekranu wymagają, aby elementy list (<li>) były zawarte w elemencie nadrzędnym <ul> lub <ol> do prawidłowego ogłoszenia.

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 prezentacji użyliśmy klasy CSS, aby symulować listę nieuporządkowaną zamiast za pomocą tagu <ul>. 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 nr 8 – Tabindex

Niektóre elementy mają wartość [tabindex] większą niż 0. Wartość większa niż 0 oznacza wyraźne uporządkowanie nawigacji. Chociaż jest to technicznie prawidłowe, często są frustrujące dla użytkowników technologii wspomagających osoby z niepełnosprawnością. Dowiedz się więcej o regułach indeksowania Tab.

<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

Masz już za sobą wszystkie problemy z automatycznymi ułatwieniami dostępu na stronie trybu debugowania. Ponownie uruchom kontrolę ułatwień dostępu w Lighthouse. Twój wynik powinno być znacznie lepsze niż za pierwszym razem.

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 kontroli ręcznej, zgodnie z opisem ręcznego testowania ułatwień dostępu.

Sprawdź swoją wiedzę

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