Ustalenie, czy Twoja witryna lub aplikacja jest dostępna, może wydawać się przytłaczające. Jeśli dopiero zaczynasz zajmować się dostępnością, możesz mieć problem z tym, od czego zacząć. W końcu dostosowanie się do różnych potrzeb oznacza, że trzeba wziąć pod uwagę odpowiednio zróżnicowany zakres problemów.
W tym poście omówiliśmy te problemy w ramach logicznego, krok po kroku procesu sprawdzania dostępności istniejącej witryny.
Zacznij od klawiatury
Użytkownicy, którzy nie mogą lub nie chcą korzystać z myszy, mogą poruszać się po ekranie za pomocą klawiatury. Ta grupa odbiorców obejmuje użytkowników z niepełnosprawnością ruchową, np. z zespołem przeciążeniowym narządu ruchu (RSI) lub porażeniem, a także użytkowników czytników ekranu.
Aby zapewnić wygodę korzystania z klawiatury, zadbaj o logiczny porządek kart i jasne style fokusowania.
Zacznij od przewijania witryny za pomocą klawisza tabulacji. Kolejność elementów powinna być zgodna z kolejnością w DOM. Jeśli nie masz pewności, które elementy powinny być skupione, zapoznaj się z modułem w kursie z ułatwień dostępu dotyczącym skupienia uwagi. Sprawdzoną metodą jest zapewnienie, aby każdy element, z którym użytkownik może wchodzić w interakcję lub wprowadzać dane, był możliwy do skoncentrowania i wyświetlał wskaźnik skupienia (np. pierścień).
Niestandardowe elementy sterujące powinny być możliwe do wybrania. Jeśli użyjesz JavaScriptu, aby przekształcić
<div>w wybór rozwijany, nie zostanie on automatycznie wstawiony w kolejności kart. Aby umożliwić skupienie na elemencie sterowania niestandardowym, nadaj mu wartośćtabindex="0". Wartościtabindexwiększe niż 0 zmieniają kolejność kart i mogą być mylące dla użytkowników czytników ekranu.Dozwolić na skupianie uwagi tylko na interaktywnych treściach. Dodanie
tabindexdo elementów nieinteraktywnych, takich jak nagłówki, spowalnia działanie aplikacji dla użytkowników korzystających z klawiatury i widzących ekran, a nie pomaga użytkownikom czytników ekranu, ponieważ czytnik ekranu już wie, jak je ogłosić.Jeśli dodasz nowe treści do strony, najpierw skoncentruj uwagę użytkownika na tych treściach, aby mógł podjąć odpowiednie działania. Przykłady znajdziesz w artykule Zarządzanie punktem skupienia na poziomie strony.
Zaprojektuj stronę tak, aby użytkownik mógł w dowolnym momencie ustawić fokus na kolejnym elemencie. Uważaj na widżety autouzupełniania i inne konteksty, które mogą zablokować fokus klawiatury. Możesz tymczasowo zablokować fokus, gdy chcesz, aby użytkownik działał z oknem modalnym, a nie z resztą strony. Zawsze jednak musisz zapewnić możliwość wyjścia z okna modalnego za pomocą klawiatury. Przykłady znajdziesz w sekcji Przesuwane okienka i pułapki na klawiaturę.
Sprawdzanie, czy kontrola ostrości jest dostępna
Jeśli masz element sterujący niestandardowy, pozwól użytkownikom korzystać z wszystkich jego funkcji, używając tylko klawiatury. Aby dowiedzieć się, jak ułatwić dostęp do klawiatury, przeczytaj artykuł Zarządzanie punktem skupienia w komponentach.
Zarządzanie treściami poza ekranem
Wiele witryn zawiera treści poza ekranem, które są obecne w DOM, ale nie są widoczne, na przykład linki w menu w menu dostosowanym do urządzeń mobilnych lub przycisk w oknie modalnym, które nie zostało jeszcze wyświetlone. Pozostawienie tych elementów w DOM może powodować dezorientację podczas korzystania z klawiatury, zwłaszcza w przypadku czytników ekranu, które odczytują treści poza ekranem tak, jakby były częścią strony.
Wskazówki dotyczące obsługi tych elementów znajdziesz w sekcji Obsługa treści poza ekranem.
Testowanie za pomocą czytnika ekranu
Poprawa ogólnej obsługi klawiatury stanowi podstawę do wykonania następnego kroku, czyli sprawdzenia, czy na stronie są prawidłowe etykiety i semantyzacja oraz czy nie ma żadnych przeszkód utrudniających nawigację za pomocą czytnika ekranu.
Jeśli nie wiesz, jak znaczniki semantyczne są interpretowane przez technologię wspomagającą, przeczytaj artykuł Struktura treści.
- Sprawdź wszystkie obrazy pod kątem poprawnego tekstu
alt. Wyjątkiem jest sytuacja, gdy obrazy służą głównie do celów prezentacyjnych i nie są niezbędną częścią treści. Aby wskazać, że czytnik ekranu powinien pominąć obraz, ustaw wartość na pusty ciąg:alt="". - Sprawdź wszystkie opcje etykiety. W przypadku elementów sterujących niestandardowych może być konieczne użycie elementów
aria-labellubaria-labelledby. Przykłady znajdziesz w sekcji Etykiety i związki ARIA. - Sprawdź wszystkie elementy sterujące niestandardowe pod kątem odpowiedniego
rolei wymaganych atrybutów ARIA, które informują o ich stanie. Na przykład pole wyboru niestandardowe wymaga wartościrole="checkbox"iaria-checked="true|false", aby prawidłowo przekazywać stan. Ogólny przegląd tego, jak ARIA może zapewnić brakujące semantyczne informacje dla niestandardowych elementów sterujących, znajdziesz w artykule Wprowadzenie do ARIA. - Zadbaj o to, aby informacje na stronie były uporządkowane. Czytniki ekranu poruszają się po stronie w kolejności DOM, więc będą czytać wszystkie elementy, które zostały wizualnie przemieszczone za pomocą CSS, w niesensowny sposób. Jeśli chcesz, aby coś pojawiło się wcześniej na stronie, fizycznie przesuń je w DOM.
- Dopilnuj, aby wszystkie treści na stronie były dostępne za pomocą czytnika ekranu. Upewnij się, że żadne sekcje witryny nie są trwale ukryte ani zablokowane dla czytnika ekranu.
- Jeśli treści powinny być ukryte przed czytnikiem ekranu, na przykład jeśli są poza ekranem lub służą tylko do celów prezentacji, ustaw dla nich wartość
aria-hidden="true". Więcej informacji znajdziesz w artykule Ukrywanie treści.
- Jeśli treści powinny być ukryte przed czytnikiem ekranu, na przykład jeśli są poza ekranem lub służą tylko do celów prezentacji, ustaw dla nich wartość
Poznawanie czytników ekranu
Nauka obsługi czytnika ekranu może wydawać się trudna, ale w rzeczywistości jest ona całkiem przyjazna dla użytkownika. Większość deweloperów może się obejść kilkoma prostymi poleceniami.
Jeśli używasz Maca, obejrzyj film o VoiceOver, czytniku ekranu dołączonym do systemu Mac OS. Jeśli korzystasz z komputera, obejrzyj ten film o czytniku ekranu NVDA – bezpłatnym czytniku ekranu typu open source dla systemu Windows, który jest dostępny dzięki wpłatom darowitnym.
aria-hidden nie blokuje zaznaczenia klawiatury
Pamiętaj, że atrybuty ARIA mogą wpływać tylko na semantykę elementu. Nie mają wpływu na jego zachowanie. Możesz użyć atrybutu aria-hidden="true", aby ukryć element dla czytników ekranu, ale nie spowoduje to zmiany zachowania elementu w przypadku nawigacji za pomocą klawisza Tab. W przypadku interaktywnych treści poza ekranem użyj atrybutu inert, aby upewnić się, że zostały one usunięte z procesu klawiatury. W przypadku starszych przeglądarek połącz aria-hidden="true" z tabindex="-1".
Elementy interaktywne powinny wskazywać swój cel i stan.
Podawanie wizualnych wskazówek, czyli możliwości, jakie daje dany element sterujący, pomaga wielu użytkownikom na różnych urządzeniach korzystać z Twojej witryny i po niej nawigować.
- Elementy interaktywne, takie jak linki i przyciski, powinny być odróżnialne od elementów nieinterakcyjnych. Użytkownicy mają trudności z przemieszczaniem się po stronie lub aplikacji, gdy nie wiedzą, czy dany element można kliknąć. Istnieje wiele prawidłowych sposobów wskazywania elementów interaktywnych. Jednym z popularnych sposobów jest podkreślanie linków, aby odróżnić je od otaczającego je tekstu.
- Podobnie jak w przypadku wymagań dotyczących nakierowania, interaktywne elementy, takie jak linki i przyciski, wymagają stanu
hover, aby poinformować użytkowników o tym, że kursor znajduje się nad elementem, który można kliknąć. Jednak aby te elementy były dostępne dla innych metod wprowadzania, muszą być możliwe do odróżnienia bez stanuhover.
Korzystanie z nagłówków i punktów orientacyjnych
Nagłówki i elementy orientacyjne nadają stronie strukturę semantyczną i znacznie ułatwiają nawigację użytkownikom korzystającym z technologii wspomagających. Wielu użytkowników czytników ekranu twierdzi, że gdy po raz pierwszy trafiają na nieznaną stronę, zwykle próbują przemieszczać się po niej za pomocą nagłówków.
Podobnie czytniki ekranu umożliwiają przechodzenie do ważnych punktów orientacyjnych, takich jak <main> i <nav>. Z tego powodu ważne jest, aby zastanowić się, jak struktura strony może wpływać na wrażenia użytkownika.
- Użyj hierarchii
h1-h6. Tytuły możesz traktować jako narzędzia do tworzenia konspektu strony. Nie polegaj na wbudowanym stylowaniu nagłówków. Zamiast tego traktuj je tak, jakby miały ten sam rozmiar, i użyj odpowiedniego poziomu semantycznego dla treści pierwotnych, drugorzędnych i trzeciorzędnych. Następnie użyj CSS, aby dopasować nagłówki do projektu. - Używaj elementów i ról punktów orientacyjnych, aby użytkownicy mogli pomijać powtarzające się treści. Wiele technologii wspomagających udostępnia skróty do przechodzenia do określonych części strony, takich jak te zdefiniowane przez elementy
<main>lub<nav>. Te elementy mają domyślne role punktów orientacyjnych. Możesz też użyć atrybutu ARIArole, aby wyraźnie określić regiony na stronie, jak w przypadku<div role="search">. Więcej przykładów znajdziesz w artykule Semantyka i nawigacja po treściach. - Unikaj
role="application", chyba że masz doświadczenie w jego używaniu. Rola punktu orientacyjnegoapplicationinformuje technologię wspomagającą, aby wyłączyła skróty i przesłała wszystkie naciśnięcia klawiszy do strony. Oznacza to, że klawisze, których użytkownicy czytników ekranu zwykle używają do poruszania się po stronie, przestaną działać. Musisz samodzielnie zaimplementować wszystkie funkcje obsługi klawiatury.
Przeglądanie nagłówków i punktów orientacyjnych przy użyciu czytnika ekranu
Czytniki ekranu, takie jak VoiceOver i NVDA, mają menu kontekstowe, które umożliwia przechodzenie do ważnych obszarów na stronie. Podczas testowania dostępności możesz korzystać z tych menu, aby uzyskać ogólny widok strony i sprawdzić, czy poziomy nagłówków są odpowiednie oraz jakie punkty orientacyjne są używane.
Aby dowiedzieć się więcej, obejrzyj te filmy instruktażowe, które zawierają podstawowe informacje o VoiceOver i NVDA.
Automatyzacja procesu
Ręczne testowanie witryny pod kątem ułatwień dostępu może być żmudne i podatne na błędy. Warto automatyzować testowanie w jak największym stopniu. Możesz używać pakietów testów ułatwień dostępu w rozszerzeniach do przeglądarki i w wierszu poleceń.
- Czy strona przechodzi wszystkie testy rozszerzeń przeglądarki aXe lub WAVE? Istnieją też inne opcje, ale te rozszerzenia mogą być przydatnym dodatkiem do dowolnego procesu testowania ręcznego, ponieważ mogą wykrywać subtelne problemy, takie jak nieprawidłowe wartości współczynników kontrastu i brak atrybutów ARIA.
- Jeśli wolisz pracować w wierszu poleceń, axe-cli oferuje te same funkcje co rozszerzenie aXe do przeglądarki, ale można je uruchomić z terminala.
- Aby uniknąć regresji, zwłaszcza w środowisku ciągłej integracji, uwzględnij w swoim zestawie testów automatycznych bibliotekę, taką jak axe-core. axe-core to ten sam mechanizm, który obsługuje rozszerzenie aXe do Chrome, ale w postaci narzędzia wiersza poleceń.
- Czy używasz frameworka lub biblioteki, które zawierają własne narzędzia ułatwień dostępu? Na przykład protractor-accessibility-plugin w przypadku Angulara. W miarę możliwości korzystaj z dostępnych narzędzi.
Testowanie PWA za pomocą Lighthouse
Lighthouse to narzędzie, które mierzy wydajność progresywnej aplikacji internetowej (PWA). Do testów ułatwień dostępu używa biblioteki axe-core.
Jeśli korzystasz już z Lighthouse, sprawdź, czy w raporcie nie ma testów dostępności, które nie przeszły. Napraw błędy, aby poprawić ogólną wygodę korzystania z witryny.