Ułatwienia dostępu dla programistów stron internetowych

Ułatwienia dostępu sprawiają, że z Twojej strony mogą korzystać wszyscy.

Addy Osmani
Addy Osmani

Ważne jest, aby tworzyć witryny, które są przyjazne dla wszystkich i są dostępne dla wszystkich. Wybierz co najmniej 6 głównych obszarów niepełnosprawności, pod kątem których możesz optymalizować: wizualny, słuch, mobilność, rozpoznawanie, mowa i neuronową. Pomogą Ci tu różne narzędzia i zasoby, nawet jeśli nie masz doświadczenia z ułatwieniami dostępu w internecie.

Ponad miliard osób żyje z jakąś formą niepełnosprawności.

Aby strony były dostępne, muszą działać na wielu urządzeniach z różnymi rozmiarami ekranów i z różnymi rodzajami danych, np. z czytnikami ekranu. Ponadto witryny powinny być dostępne dla jak najszerszej grupy użytkowników, w tym osób niepełnosprawnych.

Oto niektóre rodzaje niepełnosprawności, z którymi mogą mieć do czynienia użytkownicy:

Przetwarzanie obrazu Słuch Sprawność
  • Słaby wzrok
  • Niewidomi
  • Daltonizm
  • Katarakty
  • Odblask słońca
  • Niedosłyszący
  • Niesłyszący
  • Szum
  • Infekcja ucha
  • Uraz rdzenia kręgowego
  • Ograniczona sprawność ruchowa
  • Ręce zajęte
Funkcje poznawcze Mowa Neuronowe
  • Trudności w nauce
  • Senność lub rozproszenie uwagi
  • Migrena
  • Autyzm
  • Konfiskata
  • Odgłosy otoczenia
  • Ból gardła
  • Zaburzenia mowy
  • Nie można mówić
  • Depresja
  • PTSD
  • Zaburzenie afektywne dwubiegunowe
  • Niepokój

Problemy ze wzrokiem to na przykład niezdolność do rozróżniania kolorów lub utrata wzroku.

  • Zadbaj o to, aby tekst spełniał minimalny próg kontrastu.
  • Unikaj przekazywania informacji przy użyciu wyłącznie koloru i upewnij się, że można resizable.
  • Zadbaj o to, aby wszystkie komponenty interfejsu użytkownika mogły być używane z technologiami wspomagającymi osoby z niepełnosprawnością, takimi jak czytniki ekranu, lupy i monitory brajlowskie. Oznacza to upewnienie się, że komponenty UI są oznaczone w taki sposób, aby interfejsy API ułatwień dostępu mogły programowo określić rolę, stan, wartość i tytuł dowolnego elementu.

Zrzut ekranu pokazujący etykietkę elementu inspekcji Narzędzi deweloperskich w Chrome.

Mam wadę wzroku i często przybliżam strony, narzędzia dla programistów i terminal. Choć obsługa powiększenia prawie nigdy nie jest na pierwszym miejscu listy zadań deweloperów, może ona znacznie pomóc użytkownikom takim jak ja.

Problemy ze słuchem oznaczają, że użytkownik może mieć problemy ze słuchem emitowanym ze strony.

Zrzut ekranu pokazujący czytnik ekranu ChromeVox czyta stronę internetową.

Problemy z mobilnością mogą obejmować niemożność obsługi myszy, klawiatury lub ekranu dotykowego.

  • Zadbaj o to, aby zawartość komponentów UI była dostępna z poziomu klawiatury w celu wykonania wszystkich czynności, do których normalnie potrzebny byłby mysz.
  • Upewnij się, że strony są prawidłowo oznaczone pod kątem technologii wspomagających – w tym czytników ekranu, oprogramowania do sterowania głosem i fizycznych przełączników – które zwykle korzystają z tych samych interfejsów API.

Zaburzenia poznawcze oznaczają, że użytkownik może wymagać technologii wspomagających, aby łatwiej czytać tekst. Dlatego ważne jest, aby zadbać o odpowiednie teksty alternatywne.

  • Zachowaj ostrożność podczas korzystania z animacji. Unikaj filmów i animacji, które powtarzają się lub migają, co może powodować problemy u niektórych użytkowników.

    Zapytanie o media CSS prefers-reduced-motion pozwala ograniczyć animacje i autoodtwarzane filmy użytkownikom, którzy wolą zmniejszony ruch:

    /*
    If the user expresses a preference for reduced motion, don't use animations on buttons.
    */
    @media (prefers-reduced-motion: reduce) {
      button {
        animation: none;
      }
    }
    
  • Unikaj interakcji, które są zależne od czasu.

Może się wydawać, że to dużo podstaw, ale omówimy teraz proces oceny i ulepszania ułatwień dostępu komponentów UI.

Aby uzyskać dodatkową pomoc wizualną, zespół GOV.UK ds. ułatwień dostępu przygotował serię cyfrowych plakatów pokazujących, co robić, a czego unikać. Możesz ich użyć, by podzielić się sprawdzonymi metodami ze swoim zespołem.

Cyfrowe plakaty pokazujące, co robić, a czego unikać.
6 plakatów ze sprawdzonymi metodami ułatwień dostępu. Przeczytaj cały tekst.

Pomiar dostępności komponentu UI

Kontrolując elementy interfejsu użytkownika pod kątem ułatwień dostępu, zadaj sobie te pytania:

  • Czy elementu interfejsu można używać tylko za pomocą klawiatury?

    Czy komponent zarządza ostrością i unika pułapek ostrości? Czy może reagować na odpowiednie zdarzenia klawiatury?

  • Czy można używać komponentu UI z czytnikiem ekranu?

    Czy masz dostępne tekstowe alternatywy do jakichkolwiek informacji przedstawionych w formie wizualnej? Czy za pomocą ARIA zostały dodane informacje semantyczne?

  • Czy komponent UI może działać bez dźwięku?

    Wyłącz głośniki i omów przykłady użycia.

  • Czy komponent UI może działać bez koloru?

    Upewnij się, że z Twojego komponentu UI mogą korzystać osoby, które nie widzą kolorów. Przydatnym narzędziem do symulacji tego problemu jest rozszerzenie do Chrome o nazwie Colorblindly. Wypróbuj wszystkie cztery dostępne formy symulacji daltonizmu. Może Cię również zainteresować rozszerzenie Daltonize, które jest podobnie przydatne.

  • Czy komponent UI może działać z włączonym trybem wysokiego kontrastu?

    Wszystkie nowoczesne systemy operacyjne obsługują tryb wysokiego kontrastu. Wysoki kontrast to rozszerzenie do Chrome, które może w tym pomóc.

Ujednolicone elementy sterujące (np. <button> i <select>) mają wbudowane ułatwienia dostępu w przeglądarce. Można je zaznaczyć za pomocą klawisza Tab. Reagują na zdarzenia z klawiatury (takie jak Enter, Space i klawisze strzałek) oraz mają semantyczne role, stany i właściwości używane przez narzędzia ułatwień dostępu. Domyślny styl powinien również spełniać wymienione wymagania ułatwień dostępu.

Niestandardowe komponenty interfejsu (z wyjątkiem komponentów rozszerzających elementy standardowe, np. <button>) nie mają żadnych wbudowanych funkcji, w tym ułatwień dostępu, dlatego musisz je podać. Przy wdrażaniu ułatwień dostępu najlepiej jest porównać swój komponent z analogicznym elementem standardowym (lub z kombinacją kilku elementów standardowych w zależności od jego złożoności).

Większość narzędzi dla programistów przeglądarek obsługuje sprawdzanie drzewa ułatwień dostępu na stronie. W Narzędziach deweloperskich w Chrome znajdziesz je na karcie Ułatwienia dostępu w panelu Elementy.

Zrzut ekranu przedstawiający widok drzewa ułatwień dostępu w Narzędziach deweloperskich w Chrome.

Firefox ma też panel Ułatwienia dostępu.

Zrzut ekranu przedstawiający widok drzewa ułatwień dostępu w Narzędziach deweloperskich w FireFox.

Safari wyświetla informacje o ułatwieniach dostępu na karcie Węzeł panelu Elementy.

Poniżej znajdziesz listę pytań, które możesz sobie zadać, próbując zwiększyć dostępność komponentów interfejsu.

Popraw fokus klawiatury

Najlepiej, aby wszystkie funkcje interfejsu użytkownika były dostępne za pomocą klawiatury. Podczas projektowania wygody użytkownika zastanów się, jak używać danego elementu z samą klawiaturą, i opracuj spójny zestaw interakcji z klawiaturą.

Po pierwsze, upewnij się, że każdy komponent ma sensowny cel. Na przykład złożony komponent, taki jak menu, może być jednym z głównych elementów na stronie, ale powinien zarządzać nim tak, aby aktywny element menu zawsze był obecny.

Zrzut ekranu menu i podmenu, które wymagają zarządzania fokusem.
Zarządzanie koncentracją w przypadku złożonego elementu.

Użyj indeksu tabulacji

Za pomocą atrybutu tabindex możesz dodać zaznaczenie za pomocą klawiatury do elementów i komponentów interfejsu. Użytkownicy korzystający wyłącznie z klawiatury i technologii wspomagającej osoby z niepełnosprawnością muszą mieć możliwość uaktywnienia klawiatury na elementach, aby mogli z nich korzystać.

Wbudowane elementy interaktywne (takie jak <button>) można łatwo zaznaczyć, więc nie wymagają atrybutu tabindex, chyba że trzeba zmienić ich położenie w kolejności kart.

Istnieją 3 typy wartości parametru tabindex:

  • tabindex="0" jest najpopularniejszym elementem i umieszcza element w naturalnej kolejności kart (zdefiniowanej w kolejności DOM).
  • Wartość tabindex większa niż 0 powoduje, że element jest ręcznie umieszczony w kolejności tabulacji. Wszystkie elementy strony z dodatnią wartością tabindex są odwiedzane w kolejności numerycznej przed elementami w naturalnej kolejności tabulacji.
  • Jeśli wartość tabindex jest równa -1, element można automatycznie zaznaczyć, ale nie ma go w kolejności tabulacji.

W przypadku niestandardowych komponentów UI zawsze używaj wartości tabindex o wartości 0 lub -1, ponieważ nie można z wyprzedzeniem określić kolejności elementów na danej stronie. Wartość tabindex wynosząca -1 jest szczególnie przydatna do zarządzania koncentracją w złożonych komponentach.

Zadbaj o to, aby zaznaczenie było zawsze widoczne, zarówno przy użyciu domyślnego stylu pierścienia ostrości, jak i stosowania wyraźnego niestandardowego stylu fokusu. Pamiętaj, aby nie zatrzymywać użytkowników klawiatury – powinni oni mieć możliwość odsunięcia zaznaczenia od elementu przy użyciu samej klawiatury.

Używanie autofokusa

Atrybut autofokusa HTML pozwala autorowi określić, że po wczytaniu strony dany element powinien automatycznie być aktywny. Interfejs autofocus jest już obsługiwany we wszystkich elementach sterujących formularzy internetowych, w tym w przyciskach. Aby automatycznie zaznaczyć elementy we własnych niestandardowych komponentach interfejsu, wywołaj metodę focus() obsługiwaną przez wszystkie elementy HTML, które można zaznaczyć (np. document.querySelector('myButton').focus()).

Dodaj interakcję z klawiaturą

Gdy komponent interfejsu użytkownika można zaznaczyć, utwórz ciekawy scenariusz interakcji z klawiaturą, gdy jest on aktywny przez obsługę odpowiednich zdarzeń klawiatury. Możesz na przykład zezwolić użytkownikowi na używanie klawiszy strzałek do wybierania opcji menu oraz do aktywowania przycisków Space i Enter. Wskazówki znajdziesz w przewodniku po wzorcach projektowania ARIA.

Upewnij się też, że skróty klawiszowe są wykrywalne. Powszechną praktyką jest stosowanie legendy skrótów klawiszowych (tekstu na ekranie), która informuje użytkownika o istnieniu skrótów. Na przykład „Naciśnij ? skrótów klawiszowych”. Można też wykorzystać wskazówkę, aby poinformować użytkownika o skrótie.

Znaczenie zarządzania koncentracją jest niemożliwe. Ważnym przykładem jest panel nawigacji. Jeśli dodasz do strony komponent interfejsu, musisz skupić się na konkretnym elemencie, który się w niej znajduje. W przeciwnym razie, aby przejść do treści, konieczne może być przeciągnięcie całej strony klawiszem Tab. Może to być frustrujące, dlatego pamiętaj, aby przetestować wszystkie elementy strony, z których można nawigować za pomocą klawiatury.

Test przełączania stanu WalkMe.
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Zadbaj o prawidłowe korzystanie z czytnika ekranu

Około 1%–2% osób korzysta z czytnika ekranu. Czy rozumiesz wszystkie ważne informacje i korzystasz z komponentu osobno, używając czytnika ekranu i klawiatury?

Poniższe pytania pomogą Ci rozwiązać problemy z ułatwieniami dostępu w czytniku ekranu.

Czy wszystkie komponenty i obrazy mają znaczące alternatywne wersje tekstowe?

Zawsze, gdy informacje o nazwie lub przeznaczeniu komponentu interaktywnego są przedstawione w formie wizualnej, zadbaj o dostępną alternatywę tekstową.

Jeśli na przykład komponent interfejsu <fancy-menu> wyświetla tylko ikonę koła zębatego, która wskazuje, że jest to menu ustawień, wymagany jest dostępny alternatywny tekst, taki jak „ustawienia”, który przekazuje te same informacje. W zależności od kontekstu możesz podać alternatywny tekst za pomocą atrybutu alt, aria-label, aria-labelledby lub zwykłego tekstu w modelu Shadow DOM. Ogólne wskazówki techniczne znajdziesz w krótkim poradniku WebAIM.

Każdy komponent UI, który wyświetla obraz, powinien udostępniać mechanizm dostarczania alternatywnego tekstu do obrazu, podobnie jak w przypadku atrybutu alt.

Czy Twoje komponenty zapewniają informacje semantyczne?

Technologia wspomagająca przekazuje informacje semantyczne, które w inny sposób są wyrażone dla osób widzących, za pomocą wizualnych wskazówek, takich jak formatowanie, styl kursora czy położenie. W przypadku elementów standardowych te informacje semantyczne są wbudowane przez przeglądarkę, ale w przypadku komponentów niestandardowych musisz je dodać za pomocą funkcji ARIA.

Ogólnie każdy komponent, który nasłuchuje zdarzeń kliknięcia lub najechania kursorem, powinien mieć jakiś rodzaj detektora zdarzeń klawiatury oraz rolę ARIA, ewentualnie stany i atrybuty ARIA.

Na przykład niestandardowy komponent interfejsu <fancy-slider> może przyjąć rolę ARIA suwaka, który ma powiązane atrybuty ARIA: aria-valuenow, aria-valuemin i aria-valuemax. Powiązując te atrybuty z odpowiednimi właściwościami komponentu niestandardowego, możesz umożliwić użytkownikom technologii wspomagających interakcję z elementem, zmianę jego wartości, a nawet zmianę jego wyglądu.

Zrzut ekranu przedstawiający suwak.
Komponent z suwakiem zakresu.
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

Czy użytkownicy rozumieją wszystko bez polegania na kolorze?

Kolor nie powinien być używany jako jedyny sposób przekazywania informacji, np. wskazanie stanu, zachęcenie użytkownika do udzielenia odpowiedzi czy wizualizację danych. Jeśli np. masz wykres kołowy, podaj etykiety i wartości każdego wycinka, aby użytkownicy z wadą wzroku mogli zrozumieć informacje, nawet jeśli nie widzą, gdzie wycinki zaczynają i kończą:

Wykres kołowy z etykietami i wartościami zapewniający dostępność.
Dostępny wykres kołowy. (Z inicjatywy W3C Web Accessibility Initiative).

Czy kontrast jest wystarczający?

Wszelkie treści tekstowe wyświetlane w komponencie powinny spełniać minimalne wymagania dotyczące kontrastu na poziomie WCAG AA. Rozważ udostępnienie motywu o wysokim kontraście, który spełnia wyższy próg AAA, i zastosuj arkusze stylów klienta użytkownika, jeśli użytkownicy potrzebują niestandardowego kontrastu lub różnych kolorów. Podczas projektowania komponentu możesz użyć narzędzia do sprawdzania kontrastu kolorów.

Czy treści, które się poruszają lub migają, da się zatrzymać i są bezpieczne?

Użytkownicy powinni mieć możliwość wstrzymywania, zatrzymywania i ukrywania treści, które przesuwają się, przewijają lub migają przez ponad 5 sekund. Ogólnie rzecz biorąc, treści nie powinny być migające.

Jeśli coś musi migać, upewnij się, że nie może migać więcej niż 3 razy na sekundę.

Narzędzia ułatwień dostępu i testowanie

Dostępnych jest ponad 100 narzędzi do oceny ułatwień dostępu w Twojej witrynie i jej komponentach. Niektóre narzędzia są zautomatyzowane, a inne wymagają testów ręcznych.

Oto kilka kwestii, które warto wziąć pod uwagę:

  • Axe umożliwia automatyczne testowanie ułatwień dostępu w wybranej platformie lub przeglądarce. Aplikacja Axe Puppeteer może służyć do pisania zautomatyzowanych testów ułatwień dostępu.
  • Audyt ułatwień dostępu w Lighthouse dostarcza przydatnych informacji pozwalających wykryć typowe problemy z ułatwieniami dostępu. Wynik ułatwień dostępu to średnia ważona ze wszystkich audytów ułatwień dostępu opartych na ocenach wpływu użytkowników na komponenty osi czasu. Informacje o monitorowaniu dostępności przy użyciu ciągłej integracji znajdziesz w artykule Lighthouse CI.

    Zrzut ekranu z kontroli ułatwień dostępu w Lighthouse.

  • Strona Tenon.io pozwala testować typowe problemy z ułatwieniami dostępu. Tenon dobrze integruje się z narzędziami do tworzenia kompilacji, w przeglądarkach (za pomocą rozszerzeń), a nawet w edytorach tekstu.

  • Jest wiele narzędzi związanych z biblioteką i platformą, które służą do informowania o problemach z ułatwieniami dostępu w komponentach. Na przykład użyj kodu eslint-plugin-jsx-a11y, by wyróżnić problemy z ułatwieniami dostępu w komponentach React w edytorze.

    Zrzut ekranu edytora kodu z problemem z ułatwieniami dostępu zgłoszonym przez eslint-plugin-jsx-a11y.

    Jeśli używasz Angular, codelyzer udostępnia też w edytorze audyty ułatwień dostępu:

    Zrzut ekranu przedstawiający edytor kodu z problemem z ułatwieniami dostępu oznaczonym przez Codelyzer.

Praca z technologiami wspomagającymi osoby z niepełnosprawnością

  • Aby sprawdzić, w jaki sposób technologie wspomagające osoby z niepełnosprawnością odczytują treści internetowe, użyj narzędzia Accessibility Inspector (Mac) lub narzędzi do testowania interfejsu Windows Automation API i AccProbe (Windows). Aby zobaczyć pełne drzewo ułatwień dostępu utworzone przez Chrome, wejdź na about://accessibility.
  • Najlepszym sposobem na przetestowanie obsługi czytnika ekranu na Macu jest użycie narzędzia VoiceOver. Użyj ⌘F5, by włączyć lub wyłączyć tę funkcję, Ctrl+Option ←→ – przechodź po stronie, a Ctrl+Shift+Option + ↑↓ – w górę i w dół drzewa ułatwień dostępu. Szczegółowe instrukcje znajdziesz na pełnej liście poleceń VoiceOver i na liście poleceń internetowych VoiceOver.
  • W systemie Windows NVDA to bezpłatny czytnik ekranu typu open source. Jednak dla osób dobrze widzących wiąże się to z trudnościami w nauce.

    Zrzut ekranu przedstawiający obiektyw ChromeLens.

  • ChromeOS ma wbudowany czytnik ekranu.

Przed nami jeszcze długa droga do ulepszenia ułatwień dostępu w internecie. Zgodnie z Web Almanac:

  • 4 na 5 witryn mają tekst, który wtapia się w tło, co sprawia, że jest nieczytelny.
  • 49,91% stron nadal nie podaje atrybutów alt w przypadku niektórych obrazów.
  • Tylko 24% stron zawierających przyciski lub linki zawiera etykiety.
  • Tylko 22,33% stron zapewnia etykiety dla wszystkich danych wejściowych w formularzu.

Możemy zrobić wiele rzeczy, które będą bardziej przystępne dla wszystkich.