Do tej pory w tym kursie dowiesz się o osobistych, biznesowych i prawnych aspektach ułatwień dla osób z niepełnosprawnościami oraz o podstawach zgodności z ułatwieniami dla osób z niepełnosprawnościami. Zapoznałeś/zapoznałaś się z określonymi tematami dotyczącymi projektowania i kodowania z uwzględnieniem wszystkich użytkowników, m.in. z tym, kiedy warto używać ARIA zamiast HTML, jak mierzyć kontrast kolorów oraz kiedy JavaScript jest niezbędny.
W pozostałych modułach przechodzimy od projektowania i tworzenia do testowania ułatwień dostępu. Wykorzystamy 3-etapowy proces testowania, który obejmuje narzędzia i techniki testowania automatycznego, ręcznego oraz za pomocą technologii wspomagających. 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 oparte są na wytycznych Web Content Accessibility Guidelines (WCAG) 2.1 poziom zgodności A i AA.
Pamiętaj, że to branża, typ produktu, lokalne przepisy i zasady oraz ogólne cele w zakresie ułatwień dostępu określają, jakie wytyczne należy stosować i jakie poziomy należy stosować. Jeśli nie potrzebujesz określonego standardu w projekcie, zalecamy stosowanie najnowszej wersji WCAG. Więcej informacji o kontroli ułatwień dostępu, typach i poziomach zgodności, WCAG i POUR znajdziesz w artykule Jak mierzona jest dostępność cyfrowa?.
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ą. To jednak dobry punkt wyjścia, bo zapewnia dane, na podstawie których można przeprowadzać testy. 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 automatycznego
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 powtarzanie testów na różnych etapach cyklu życia produktu.
- Wystarczy wykonać kilka czynności, aby uzyskać bardzo szybkie wyniki.
- Do przeprowadzenia testów i interpretowania ich wyników nie trzeba mieć dużej 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 i ról usług może być potrzebnych kilka narzędzi
Testowanie automatyczne to świetny pierwszy krok do sprawdzenia ułatwień dostępu w witrynie lub aplikacji, ale nie wszystkie testy 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 zautomatyzowanych narzędzi
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. Obecnie dostępnych jest ponad 100 narzędzi do testowania automatycznego.
Wdrożenie zautomatyzowanego narzędzia może obejmować rozszerzenia przeglądarki ułatwiające dostęp, narzędzia do sprawdzania kodu, aplikacje na komputery i urządzenia mobilne, panele internetowe, a nawet interfejsy API typu open source, których możesz używać do tworzenia własnych narzędzi zautomatyzowanych.
Wybór automatycznego narzędzia zależy od wielu czynników, w tym od:
- 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ę reguł dotyczących 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.
- Na którym etapie cyklu życia oprogramowania testujesz swój produkt?
- Ile czasu zajmuje skonfigurowanie i używanie narzędzia? Dla osoby fizycznej, zespołu czy firmy?
- Kto przeprowadza test: projektanci, programiści, kontrola jakości czy ktoś inny?
- Jak często chcesz sprawdzać dostępność? Jakie informacje powinny się znaleźć 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ę. Zapoznaj się z artykułem WAI „Selecting Web Accessibility Evaluation Tools” (Wybieranie narzędzi do oceny ułatwień dostępu w internecie), aby dowiedzieć się więcej o tym, jak wybrać narzędzie najlepsze dla Ciebie i Twojego zespołu.
Demo: test zautomatyzowany
W wersji demonstracyjnej automatycznego testowania ułatwień dostępu użyjemy Lighthouse w Chrome. 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 to witryna stworzona dla zmyślonej organizacji – Medical Mysteries Club. Ta witryna jest celowo niedostępna w ramach 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 usłudze CodePen.
Wyświetl go w trybie debugowania, aby przeprowadzić kolejne testy. 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 przejdź do karty Lighthouse. Usuń wszystkie opcje kategorii oprócz „Dostępność”. Pozostaw tryb domyślny i wybierz typ urządzenia, na którym chcesz przeprowadzać 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 mierzy dostępność testowanego produktu. Wynik Lighthouse jest obliczany na podstawie liczby i typów wykrytych problemów oraz ich 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 przejrzyj przykłady każdego z automatycznie wykrytych problemów z ułatwieniami dostępu i popraw odpowiednie style oraz znaczniki.
Problem 1. Role ARIA
Pierwszy problem dotyczy elementów z atrybutem ARIA [role], które wymagają elementów podrzędnych z 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 poprawnie realizować funkcje ułatwień dostępu. Więcej informacji o regułach dotyczących ról ARIA
W przykładzie wystąpił błąd przycisku subskrypcji newslettera:
<button role="list" type="submit" tabindex="1">Subscribe</button>
Przycisk „Zapisz” obok pola wejściowego 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ć. Elementy podrzędne z możliwością zaznaczenia 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>
Pole wejściowe ma zastosowany atrybut aria-hidden="true"
. Dodanie tego atrybutu ukrywa element (i wszystko zagnieżdżone w nim) przed asystycznymi technologiami.
<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 osoby z niepełnosprawnością dostęp do pola formularza i wpisywanie informacji w nim.
Problem 3. Nazwa przycisku
Przyciski nie mają nazwy na potrzeby ułatwień dostępu. 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 nazw przycisków.
<button role="list" type="submit" tabindex="1">Subscribe</button>
Gdy usuniesz nieprawidłową rolę ARIA z elementu przycisku w problemie 1, słowo „Subskrybuj” stanie się nazwą przycisku z dostępem. Ta funkcja jest wbudowana w semantyczny element HTML typu button. W bardziej skomplikowanych sytuacjach możesz skorzystać z dodatkowych opcji wzorów.
<button type="submit" tabindex="1">Subscribe</button>
Problem 4. Atrybuty alt obrazu
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 regułach dotyczących tekstu alternatywnego obrazu
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
Ponieważ obraz logo jest też linkiem, wiesz z modułu dotyczącego obrazów, że jest to obraz z działaniem i wymaga 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 linków (i tekst zastępczy obrazów jako linki), który jest wyróżniający się, unikalny i możliwy do zaznaczenia, ułatwia nawigację użytkownikom czytników ekranu. Więcej informacji o regułach dotyczących tekstu w linku
<a href="#!"><svg><path>...</path></svg></a>
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 do obrazu tekstu alternatywnego, który informuje o przeznaczeniu obrazu, tak jak na obrazie logo w przykładzie. Ta metoda działa świetnie w przypadku obrazu z tagiem <img>
, ale nie można jej stosować w przypadku tagów <svg>
.
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 od środowiska i ograniczeń kodu jedna z metod może być lepsza od drugiej.
Użyj najprostszej opcji wzoru z najszerszym zakresem obsługi technologii, czyli dodaj tag 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 kontrastu kolorów
Zarejestrowano 2 przykłady.
Na stronie internetowej wykryliśmy 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. Przyciski w kolorze morskim są traktowane jak tekst o zwykłym rozmiarze i mają pogrubienie 16 pikseli, dlatego muszą spełniać wymóg dotyczący kontrastu koloru 4, 5:1.
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. Zgodnie z bieżącą estetyką projektu.
Cały szary tekst na białym tle również nie spełnia wymagań kontrastu kolorów, z wyjątkiem 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>
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>
W tej demonstracji użyliśmy klasy CSS, aby zasymulować listę nieuporządkowaną zamiast używać tagu <ul>
. Podczas niewłaściwego pisania tego kodu usunęliśmy wbudowane w tag funkcje semantyczne HTML. Zastąpienie klasy prawdziwym tagiem <ul>
i modyfikowanie powiązanego ze sobą kodu CSS rozwiązuje 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ż takie rozwiązanie jest technicznie uzasadnione, często powoduje ono frustrację 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>
O ile nie ma konkretnego powodu, dla którego należy zakłócić naturalny porządek elementów w witrynie, nie ma potrzeby podawania dodatniej liczby całkowitej w atrybucie tabindex. Aby zachować naturalny porządek tabulacji, możemy zmienić tabindex na 0
lub całkowicie usunąć atrybut.
<button type="submit">Subscribe</button>
Krok 6
Po rozwiązaniu wszystkich problemów z automatycznymi ułatwieniami dostępu 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 automatyczne aktualizacje ułatwień dostępu w nowym formacie CodePen.
Następny krok
Dobra robota. Udało Ci się już wiele, ale to jeszcze nie koniec. Teraz przejdziemy do testów ręcznych, które zostały opisane w module ręcznego testowania ułatwień dostępu.
Sprawdź swoją wiedzę
Sprawdź swoją wiedzę na temat automatycznego testowania ułatwień dostępu
Jakich testów należy przeprowadzić, aby zapewnić dostępność witryny?
Jakie błędy są wykrywane podczas testów automatycznych?