Ręczne testowanie ułatwień dostępu

Podstawy testowania ręcznego

Ręczne testowanie ułatwień dostępu polega na używaniu testów klawiatury, testów wizualnych i testów poznawczych, narzędzi i technik do znajdowania problemów, których nie wykryją narzędzia automatyczne. Narzędzia automatyczne nie obejmują wszystkich kryteriów sukcesu określonych w WCAG, dlatego konieczne jest przeprowadzanie automatycznych testów ułatwień dostępu i dalsze testowanie.

Wraz z postępem technologicznym coraz więcej testów będzie można przeprowadzać za pomocą narzędzi automatycznych, ale obecnie do protokołów testowania trzeba dodać zarówno testy ręczne, jak i testy technologii wspomagającej osoby z niepełnosprawnością, aby obejmowały one wszystkie odpowiednie punkty kontrolne wytycznych WCAG.

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

  • Stosunkowo proste i szybkie do przeprowadzenia.
  • Pozwalają wykryć większy odsetek problemów niż same testy automatyczne.
  • Do osiągnięcia sukcesu nie jest potrzebna duża wiedza ani wiele narzędzi.

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

  • Bardziej złożone i czasochłonne niż testy automatyczne.
  • Mogą być trudne do powtórzenia na dużą skalę.
  • Do przeprowadzania testów i interpretowania wyników wymagają większej wiedzy na temat ułatwień dostępu.

Porównaj, jakie elementy i szczegóły dotyczące ułatwień dostępu mogą zostać wykryte przez narzędzie automatyczne, a jakie nie.

Można zautomatyzować Nie można zautomatyzować
Kontrast kolorów tekstu na jednolitym tle Kontrast kolorów tekstu na gradientach i obrazach
Istnieje tekst alternatywny obrazu Tekst alternatywny obrazu jest dokładny i prawidłowo przypisany
Istnieją nagłówki, listy i punkty orientacyjne Nagłówki, listy i punkty orientacyjne są prawidłowo oznaczone, a wszystkie elementy są uwzględnione
ARIA jest obecna ARIA jest używana prawidłowo i stosowana do odpowiednich elementów
Identyfikowanie elementów, na których można ustawić fokus za pomocą klawiatury Które elementy nie mają fokusu klawiatury, czy kolejność fokusu jest logiczna i czy wskaźnik fokusu jest widoczny
Wykrywanie tytułu iFrame iFrame, kolejność fokusu jest logiczna, a wskaźnik fokusu jest widoczny
Element wideo jest obecny Element wideo ma odpowiednie alternatywne media (np. napisy i transkrypcje)


Rodzaje testów ręcznych

Podczas sprawdzania dostępności cyfrowej strony internetowej lub aplikacji możesz korzystać z wielu narzędzi i technik ręcznych. 3 główne obszary, na których skupia się testowanie ręczne, to funkcjonalność klawiatury, sprawdzanie wizualne i ogólne sprawdzanie treści.

W tym module omawiamy każdy z tych tematów na wysokim poziomie, ale poniższe testy nie są wyczerpującą listą wszystkich testów ręcznych, które możesz lub powinnaś przeprowadzić. Zachęcamy Cię, aby zacząć od a listy kontrolnej ułatwień dostępu z wiarygodnego źródła i opracować własną listę kontrolną testów ręcznych , która będzie dostosowana do potrzeb Twojego zespołu i konkretnego produktu cyfrowego.

Testy klawiatury

Szacuje się, że około 25% wszystkich problemów z dostępnością cyfrową jest związanych z brakiem obsługi klawiatury. Jak dowiedzieliśmy się w module dotyczącym fokusu klawiatury, ma to wpływ na wszystkie typy użytkowników, w tym na osoby widzące, które używają tylko klawiatury, osoby niedowidzące lub niewidome korzystające z czytników ekranu oraz osoby korzystające z oprogramowania do rozpoznawania mowy, które używa technologii wymagającej, aby treści były dostępne za pomocą klawiatury.

Testy klawiatury odpowiadają na takie pytania jak:

  • Czy strona internetowa lub funkcja wymaga użycia myszy?
  • Czy kolejność tabulacji jest logiczna i intuicyjna?
  • Czy wskaźnik fokusu klawiatury jest zawsze widoczny?
  • Czy można utknąć w elemencie, który nie powinien blokować fokusu?
  • Czy można poruszać się za elementem, który powinien blokować fokus, lub wokół niego?
  • Czy po zamknięciu elementu, który otrzymał fokus, wskaźnik fokusu wrócił do logicznego miejsca?

Wpływ funkcjonalności klawiatury jest ogromny, ale procedura testowania jest dość prosta. Wystarczy odłożyć mysz lub zainstalować mały pakiet JavaScript i przetestować witrynę, używając tylko klawiatury. Do testowania klawiatury niezbędne są te polecenia:

Klucz Wynik
Tab Przechodzi do następnego aktywnego elementu
Shift + Tab Przechodzi do poprzedniego aktywnego elementu
Strzałki Przełączanie między powiązanymi elementami sterującymi
Spacja Przełącza stany i przewija stronę w dół
Shift + Spacja Przewija stronę w górę
Enter Uruchamia określone elementy sterujące
Escape Zamyka dynamicznie wyświetlane obiekty

Testy wizualne

Testy wizualne skupiają się na elementach wizualnych strony i wykorzystują narzędzia takie jak powiększenie ekranu lub powiększenie przeglądarki, aby sprawdzić dostępność witryny lub aplikacji.

Testy wizualne mogą Ci powiedzieć:

  • Czy występują problemy z kontrastem kolorów, których nie wykryło narzędzie automatyczne, np. tekst na gradientie lub obrazie?
  • Czy są jakieś elementy, które wyglądają jak nagłówki, listy i inne elementy strukturalne, ale nie są tak zakodowane?
  • Czy linki nawigacyjne i pola formularzy są spójne w całej witrynie lub aplikacji?
  • Czy występują migające, stroboskopowe lub animowane elementy, które przekraczają zalecenia?
  • Czy treści mają odpowiednie odstępy? Między literami, słowami, wierszami i akapitami?
  • Czy możesz zobaczyć całą zawartość za pomocą lupy ekranowej lub powiększenia przeglądarki?

Sprawdzanie treści

W przeciwieństwie do testów wizualnych, które skupiają się na układach, ruchu i kolorach, sprawdzanie treści skupia się na słowach na stronie. Warto nie tylko sprawdzić sam tekst, ale też kontekst, aby upewnić się, że jest on zrozumiały dla innych.

Sprawdzanie treści odpowiada na takie pytania jak:

  • Czy tytuły stron, nagłówki i etykiety formularzy są jasne i opisowe?
  • Czy alternatywne teksty obrazów są zwięzłe, dokładne i przydatne?
  • Czy kolor jest jedynym sposobem przekazywania znaczenia lub informacji?
  • Czy linki są opisowe, czy używasz ogólnego tekstu, takiego jak „więcej informacji” lub „kliknij tutaj”?
  • Czy na stronie występują zmiany języka?
  • Czy używany jest prosty język i czy wszystkie akronimy są rozwinięte przy pierwszym użyciu?

Niektóre testy treści można częściowo zautomatyzować. Możesz na przykład napisać narzędzie do sprawdzania kodu JavaScript, które będzie wyszukiwać frazę „Kliknij tutaj” i sugerować wprowadzenie zmiany. Jednak w przypadku tych niestandardowych rozwiązań często nadal trzeba, aby człowiek zmienił tekst na coś kontekstowego.

Prezentacja: test ręczny

Do tej pory przeprowadziliśmy automatyczne testy na naszej demonstracyjnej stronie internetowej i znaleźliśmy oraz naprawiliśmy 8 różnych typów problemów. Teraz możemy przeprowadzić testy ręczne, aby sprawdzić, czy uda nam się wykryć jeszcze więcej problemów z dostępnością.

Krok 1

Zaktualizowana wersja demonstracyjna CodePen zawiera wszystkie automatyczne aktualizacje ułatwień dostępu.

Aby przejść do następnych testów, wyświetl ją w trybie debugowania. Jest to ważne, ponieważ usuwa element <iframe>, który otacza demonstracyjną stronę internetową i może zakłócać działanie niektórych narzędzi testowych. Więcej informacji o trybie debugowania CodePen.

Krok 2

Rozpocznij proces testowania ręcznego, odkładając mysz lub touchpad i poruszając się w górę i w dół po DOM za pomocą klawiatury.

Problem 1. Widoczny wskaźnik fokusu

Pierwszy problem z klawiaturą powinien być widoczny od razu – a raczej nie powinien być widoczny – ponieważ widoczny wskaźnik fokusu został usunięty. Podczas skanowania CSS w wersji demonstracyjnej powinien zostać znaleziony niechciany kod „outline: none” dodany do bazy kodu.

  :focus {
    outline: none;
  }
Naprawmy to.

Jak dowiedzieliśmy się w module dotyczącym fokusu klawiatury, aby umożliwić przeglądarkom dodawanie widocznego fokusu dla użytkowników, musisz usunąć ten wiersz kodu. Możesz pójść o krok dalej i utworzyć wskaźnik fokusu, który będzie pasował do estetyki Twojego produktu cyfrowego.

:focus {
  outline: 3px dotted #008576;
}

Problem 2. Kolejność fokusu

Po zmodyfikowaniu wskaźnika fokusu i jego widoczności przejdź przez stronę za pomocą tabulatora. W trakcie tego procesu zauważysz, że pole do wprowadzania danych formularza używane do subskrybowania newslettera nie otrzymuje fokusu. Zostało ono usunięte z naturalnej kolejności fokusu przez ujemny indeks tabindex.

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

Ponieważ chcemy, aby użytkownicy mogli używać tego pola do subskrybowania naszego newslettera, wystarczy usunąć ujemny indeks tabindex lub ustawić go na zero, aby pole ponownie mogło otrzymywać fokus za pomocą klawiatury.

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

Krok 3

Po sprawdzeniu fokusu klawiatury przechodzimy do testów wizualnych i testów treści.

Podczas testów klawiatury, w których przechodziliśmy w górę i w dół po stronie demonstracyjnej za pomocą tabulatora, prawdopodobnie zauważyliśmy, że fokus klawiatury jest ustawiony na 3 ukrytych wizualnie linkach w akapitach dotyczących różnych schorzeń.

Aby nasza strona była dostępna, linki muszą wyróżniać się na tle otaczającego tekstu i zawierać zmianę stylu inną niż kolor po najechaniu myszą i ustawieniu fokusu za pomocą klawiatury.

Naprawmy to.

Szybkim rozwiązaniem jest dodanie podkreślenia do linków w akapitach, aby je wyróżnić. Rozwiąże to problem z dostępnością, ale może nie pasować do ogólnej estetyki projektu, którą chcesz osiągnąć.

Jeśli nie chcesz dodawać podkreślenia, musisz zmodyfikować kolory w taki sposób, aby spełniały wymagania zarówno dotyczące tła, jak i tekstu.

Podczas sprawdzania wersji demonstracyjnej za pomocą narzędzia do sprawdzania kontrastu linków, zobaczysz, że kolor linku spełnia wymaganie dotyczące kontrastu kolorów 4,5:1 między tekstem o standardowym rozmiarze a tłem. Jednak linki bez podkreślenia muszą też spełniać wymaganie dotyczące kontrastu kolorów 3:1 w stosunku do otaczającego tekstu.

Jedną z opcji jest zmiana koloru linku tak, aby pasował do innych elementów na stronie. Jeśli jednak zmienisz kolor linku na zielony, musisz też zmodyfikować tekst główny, aby spełniał ogólne wymagania dotyczące kontrastu kolorów między wszystkimi 3 elementami: linkami, tłem i otaczającym tekstem.

Zrzut ekranu z WebAIM dla tekstu linku pokazujący, że link do tekstu głównego nie spełnia wymagań WCAG na poziomie A.
Jeśli link i tekst główny są takie same, test się nie powiedzie.
Zrzut ekranu z WebAIM pokazuje, że wszystkie testy są zaliczone, gdy kolor linku jest zielony.
Jeśli link i tekst główny są różne, test się powiedzie.

Problem 4. Kontrast kolorów ikon

Kolejnym pominiętym problemem z kontrastem kolorów są ikony mediów społecznościowych. W module dotyczącym kolorów i kontrastu dowiedzieliśmy się, że podstawowe ikony muszą mieć kontrast kolorów 3:1 w stosunku do tła. W wersji demonstracyjnej ikony mediów społecznościowych mają jednak współczynnik kontrastu 1,3:1.

Naprawmy to.

Aby spełnić wymagania dotyczące kontrastu kolorów 3:1, ikony mediów społecznościowych zostały zmienione na ciemniejszy odcień szarości.

Zrzut ekranu wersji demonstracyjnej z analizatorem kolorów, który pokazuje nieprawidłowy kontrast kolorów ikony.

Problem 5. Układ treści

Jeśli przyjrzysz się układowi treści akapitu, zobaczysz, że tekst jest w pełni wyjustowany. Jak dowiedzieliśmy się w module dotyczącym typografii, tworzy to „rzeki przestrzeni”, które mogą utrudniać czytanie tekstu niektórym użytkownikom.

p.bullet {
   text-align: justify;
}
Naprawmy to.

Aby zresetować wyrównanie tekstu w wersji demonstracyjnej, możesz zaktualizować kod do text-align: left; lub całkowicie usunąć ten wiersz z CSS, ponieważ lewe wyrównanie jest domyślnym wyrównaniem w przeglądarkach. Pamiętaj, aby przetestować kod, ponieważ inne dziedziczone style mogą usuwać domyślne wyrównanie tekstu.

p.bullet {
   text-align: left;
}

Krok 4

Zrzut ekranu przedstawiający witrynę demonstracyjną Medical Mysteries Club.
Jak widać na tym obrazie, wszystkie problemy ręczne zostały już rozwiązane w wersji demonstracyjnej.

Po zidentyfikowaniu i naprawieniu wszystkich problemów z dostępnością, które zostały opisane w poprzednich krokach, Twoja strona powinna wyglądać podobnie jak na naszym zrzucie ekranu.

Podczas testów ręcznych możesz znaleźć więcej problemów z dostępnością niż te, które omówiliśmy w tym module. Wiele z tych problemów odkryjemy w następnym module.

Następny krok

Doskonale! Ukończono moduły dotyczące testowania automatycznego i ręcznego. Możesz wyświetlić naszą zaktualizowaną wersję CodePen, która zawiera wszystkie poprawki dotyczące automatycznych i ręcznych ułatwień dostępu.

Teraz przejdź do ostatniego modułu testowania, który skupia się na testowaniu technologii wspomagającej osoby z niepełnosprawnością.

Wstecz
Automatyczne testowanie ułatwień dostępu
Dalej
Testowanie technologii wspomagających osoby z niepełnosprawnością