Testowanie technologii wspomagających osoby z niepełnosprawnością

W tym module omawiamy korzystanie z technologii wspomagających (AT) do testowania dostępności. Osoba niepełnosprawna może korzystać z AT, aby zwiększyć, utrzymać lub poprawić możliwości wykonywania danego zadania.

W przestrzeni cyfrowej AT mogą być:

• Niedozwolone lub o niskiej jakości: patyczki do ust i głowy, lupy ręczne, urządzenia z dużą liczbą przycisków
• Zaawansowane: urządzenia aktywowane głosem, urządzenia do śledzenia ruchów gałek ocznych, klawiatury i myszy adaptacyjne
• Sprzęt: przełączniki, ergonomiczne klawiatury, automatycznie odświeżające urządzenie brajlowskie
• Oprogramowanie: programy do zamiany tekstu na mowę, napisy na żywo, czytniki ekranu

Zachęcamy do korzystania z różnych typów testów automatycznych w całym procesie testowania.

Podstawy testowania czytników ekranu

W tym module skupiamy się na jednym z najpopularniejszych cyfrowych narzędzi wspomagających – czytnikach ekranu. Czytnik ekranu to oprogramowanie, które odczytuje kod źródłowy witryny lub aplikacji, a następnie przekształci te informacje w mowę lub brajlowski alfabet dla użytkownika.

Czytniki ekranu są niezbędne dla osób niewidomych i niedowidzących, ale mogą też być przydatne osobom słabowidzącym, z zaburzeniami czytania i niepełnosprawnością umysłową.

Zgodność z przeglądarką

Dostępnych jest kilka opcji czytników ekranu. Najpopularniejsze czytniki ekranu to JAWS, NVDA i VoiceOver na komputerach oraz VoiceOver i Talkback na urządzeniach mobilnych.

W zależności od systemu operacyjnego, ulubionej przeglądarki i urządzenia, którego używasz, jeden czytnik ekranu może być najlepszym wyborem. Większość czytników ekranu jest tworzona z myślą o konkretnym sprzęcie i przeglądarkach internetowych. Jeśli używasz czytnika ekranu z przeglądarką, która nie została skalibrowana, możesz napotkać więcej „błędów” lub nieoczekiwanych zachowań. Czytniki ekranu działają najlepiej w tych kombinacjach:

Polecenia czytnika ekranu

Po prawidłowej konfiguracji czytnika ekranu na komputerze lub urządzeniu mobilnym zapoznaj się z dokumentacją czytnika ekranu (link w poprzedniej tabeli) i wypróbuj kilka podstawowych poleceń, aby zapoznać się z tą technologią. Jeśli korzystasz już z czytnika ekranu, wypróbuj inny.

Gdy używasz czytnika ekranu do testowania dostępności, Twoim celem jest wykrycie problemów w kodzie, które utrudniają korzystanie z witryny lub aplikacji, a nie emulowanie działania czytnika ekranu. Dzięki temu możesz zrobić wiele, jeśli tylko masz podstawową wiedzę, znasz kilka poleceń czytnika ekranu i masz trochę (lub dużo) praktyki.

Jeśli chcesz lepiej poznać wrażenia użytkowników korzystających z czytników ekranu i innych narzędzi ułatwiających dostęp, możesz skontaktować się z wielu organizacjami i osobami, aby uzyskać cenne informacje. Pamiętaj, że korzystanie z AT do testowania kodu pod kątem zgodności z zestawem reguł i pytanie użytkowników o ich wrażenia często daje inne wyniki. Oba te aspekty są ważne, aby tworzyć w pełni wszechstronne usługi.

Polecenia klawiszy dla czytników ekranu na komputerach

Polecenia klawiszy dla czytników ekranu na urządzeniach mobilnych

Demo testowania czytnika ekranu

Aby przetestować nasz demonstracyjny film, użyliśmy przeglądarki Safari na laptopie z systemem macOS i nagrywaliśmy dźwięk. Możesz wykonać te czynności za pomocą dowolnego czytnika ekranu, ale sposób, w jaki napotkasz niektóre błędy, może się różnić od tego, jak jest to opisane w tym module.

Krok 1

Odwiedź zaktualizowaną wersję CodePen, w której zostały zastosowane wszystkie automatyczne i ręczne ułatwienia dostępu.

Aby przejść do kolejnych testów, wyświetl go w trybie debugowania. Jest to ważne, ponieważ usuwa element <iframe> otaczający stronę internetową demonstracyjną, który może zakłócać działanie niektórych narzędzi testowych. Dowiedz się więcej o trybie debugowania CodePen.

Krok 2

Włącz wybrany czytnik ekranu i otwórz stronę demonstracyjną. Zanim zaczniesz zajmować się konkretnymi problemami, możesz przejrzeć całą stronę od góry do dołu.

Na potrzeby każdego problemu nagraliśmy nasz czytnik ekranu przed zastosowaniem poprawek i po ich zastosowaniu. Zachęcamy do przetestowania wersji demonstracyjnej za pomocą czytnika ekranu.

Problem 1. Struktura treści

Nagłówki i punkty orientacyjne to jedne z głównych sposobów nawigacji za pomocą czytników ekranu. Jeśli ich nie ma, użytkownik czytnika ekranu musi przeczytać całą stronę, aby zrozumieć kontekst. Może to zająć dużo czasu i być frustrujące.

Jeśli spróbujesz się poruszać po stronie, korzystając z elementów demo, szybko zauważysz, że ich tam nie ma.

• Przykład punktu orientacyjnego: <div class="main">...</div>
• Przykład nagłówka: <p class="h1">Join the Club</p>

Jeśli wszystko zostało zaktualizowane prawidłowo, nie powinno być żadnych wizualnych zmian, ale czytnik ekranu powinien działać znacznie lepiej.

Napraw to.

Niektórych niedostępnych elementów nie można zauważyć, po prostu przeglądając witrynę. Z modułu Struktura treści możesz pamiętać, jak ważne są poziomy nagłówków i semantyczny HTML. Treść może wyglądać jak nagłówek, ale jest w rzeczywistości ujęta w stylizowany element <div>.

Aby rozwiązać problem z nagłówkami i punktami orientacyjnymi, musisz najpierw zidentyfikować każdy element, który powinien być oznaczony jako taki, i zaktualizować powiązany kod HTML. Pamiętaj, aby zaktualizować też powiązany plik CSS.

• Przykład punktu orientacyjnego: <main>...</main>
• Przykład nagłówka: <h1>Join the Club</h1>

Jeśli wszystko zostało zaktualizowane prawidłowo, nie powinno być żadnych zmian wizualnych, ale działanie czytnika ekranu powinno się znacznie poprawić.

Problem 2. Linkowanie kontekstu

Ważne jest, aby użytkownicy czytników ekranu mieli dostęp do informacji o celu linku i o tym, czy przekierowuje on do nowej lokalizacji poza witryną lub aplikacją.

W naszym pokazie użyliśmy większości linków, które zostały poprawione podczas aktualizacji tekstu alternatywnego aktywnego obrazu, ale jest też kilka dodatkowych linków dotyczących różnych rzadkich chorób, które mogłyby zyskać na dodatkowym kontekście, zwłaszcza że przekierowują one do nowej lokalizacji.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>

Napraw to.

Aby rozwiązać ten problem dla użytkowników czytników ekranu, zaktualizowaliśmy kod, aby dodać więcej informacji bez wpływu na elementy wizualne. Aby pomóc jeszcze większej liczbie osób, na przykład tym z zaburzeniami poznawczymi i czytania, możemy dodać dodatkowy tekst wizualny.

Istnieje wiele różnych wzorów, które możemy zastosować, aby dodać dodatkowe informacje. W naszym środowisku, które obsługuje tylko jeden język, etykieta ARIA jest w tej sytuacji prostą opcją. Możesz zauważyć, że etykieta ARIA zastępuje oryginalny tekst linku, dlatego pamiętaj, aby uwzględnić te informacje w aktualizacji.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
  aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
  Maple syrup urine disease (MSUD)
</a>

Problem 3. Obraz dekoracyjny

W naszym module testów automatycznych Lighthouse nie był w stanie wykryć wbudowanego pliku SVG, który pełni rolę głównego obrazu powitalnego na stronie demonstracyjnej. Czytnik ekranu znajdzie jednak ten tekst i ogłosi go jako „obraz” bez dodatkowych informacji. Dzieje się tak nawet wtedy, gdy nie dodasz atrybutu role="img" do pliku SVG.

<div class="section-right">
  <svg>...</svg>
</div>

Napraw to.

Aby rozwiązać ten problem, musimy najpierw określić, czy obraz jest informacyjny czy dekoracyjny. W związku z tym musimy dodać odpowiedni tekst alternatywny (obraz informacyjny) lub ukryć obraz przed użytkownikami czytników ekranu (obraz dekoracyjny).

Przeanalizowaliśmy zalety i wady różnych sposobów kategoryzowania obrazu i zawniosliśmy, że jest on ozdobny, co oznacza, że chcemy dodać lub zmodyfikować kod, aby go ukryć. Szybką metodą jest dodanie role="presentation" bezpośrednio do obrazu SVG. Czytnik ekranu otrzymuje sygnał, aby pominąć ten obraz i nie uwzględniać go w grupie obrazów.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>

Problem 4. Ozdoba na liście wypunktowanej

Być może zauważysz, że czytnik ekranu odczytuje obrazek z obrazem w ramce w sekcji dotyczącej rzadkich chorób. Chociaż nie jest to tradycyjny typ obrazu, o którym mówiliśmy w module Obrazy, należy go zmodyfikować, ponieważ zakłóca on płynność treści i może rozpraszać lub wprowadzać w błąd użytkownika czytnika ekranu.

<p class="bullet">...</p>

Napraw to.

Podobnie jak w przypadku obrazu ozdobnego, o którym była mowa wcześniej, możesz dodać do kodu HTML element role="presentation" z klasą symbolu, aby ukryć go przed czytnikiem ekranu. Podobnie działa role="none". Pamiętaj tylko, aby nie używać znaku aria-hidden: true, ponieważ w przeciwnym razie ukrywasz całą treść akapitu przed użytkownikami korzystającymi z czytników ekranu.

<p class="bullet" role="none">...</p>

Problem 5. Pole formularza

Z modułu Formularze dowiedzieliśmy się, że wszystkie pola formularza muszą mieć też etykietę wizualną i programową. Ta etykieta musi być widoczna przez cały czas.

W naszym pliku demonstracyjnym w polu e-maila do subskrypcji newslettera brakuje etykiety wizualnej i programowej. Jest element zastępczy z tekstem, ale nie zastępuje on etykiety, ponieważ nie jest widoczny stale i nie jest w pełni zgodny ze wszystkimi czytnikami ekranu.

<form>
  <div class="form-group">
    <input type="email" placeholder="Enter your e-mail address" required>
    <button type="submit">Subscribe</button>
  </div>
</form>

Napraw to.

Aby rozwiązać ten problem, zastąp element zastępczy tekstowy elementem etykiety o podobnej nazwie. Ten element etykiety jest połączony z polem formularza za pomocą kodu i został dodany za pomocą JavaScriptu, aby pozostawał widoczny nawet wtedy, gdy do pola zostanie dodana treść.

<form>
  <div class="form-group">
    <input type="email" required id="youremail" name="youremail" type="text">
    <label for="youremail">Enter your e-mail address</label>
    <button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
  </div>
</form>

Podsumowanie

Gratulacje! Użytkownik przeprowadził wszystkie testy dotyczące tego demo. Wszystkie te zmiany możesz zobaczyć w zaktualizowanym pliku Codepen dla tego demonstracyjnego kodu.

Teraz możesz wykorzystać zdobytą wiedzę, aby sprawdzić dostępność swoich witryn i aplikacji.

Celem wszystkich testów ułatwień dostępu jest rozwiązanie jak największej liczby problemów, z którymi użytkownik może się potencjalnie spotkać. Nie oznacza to jednak, że po zakończeniu procesu witryna lub aplikacja będzie w pełni dostępna. Najlepsze efekty osiągniesz, jeśli w trakcie całego procesu projektowania witryny lub aplikacji będziesz mieć na uwadze dostępność, a testy dostępności będziesz uwzględniać w ramach innych testów przed uruchomieniem.

Sprawdź swoją wiedzę

Sprawdź swoją wiedzę na temat automatycznego testowania dostępności.