Jump to content

Przewodnik po dostępności dla deweloperów

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 100% complete.
Languages:

Dostępność jest ważna dla naszych użytkowników i możemy ją poprawić, jeśli weźmiemy pod uwagę kilka podstawowych zasad i pomysłów. Dostępność jest trudna, ponieważ nie istnieją ustalone i powszechnie akceptowane standardy techniczne, które działałyby konsekwentnie i dla wszystkich użytkowników. Ta strona nie wymienia ani nie omawia konkretnych problemów z dostępnością w MediaWiki. Stara się skupić na wyborze technologii oraz na tym, co należy robić, a czego unikać, aby zapobiegać problemom z dostępnością.

Jeśli chodzi o rozwój, uważam, że to powinien być nasz zbiór zasad:

  • Staramy się umożliwić korzystanie wszystkim naszym użytkownikom (a to oznacza wszystkich).
  • Staramy się omijać problemy z dostępnością, jeśli to możliwe, ale nie za wszelką cenę.
  • Powinniśmy stosować podejście stopniowego wzmacniania zamiast łagodnego degradacji.
  • Wdrażaj rozwiązania, które są technologicznie solidne.

Jak zapewnić dostępność

Kilka ważnych pojęć, które warto mieć na uwadze.

Pomiar dostępności w różnych formach

Dostępność dotyczy wielu aspektów, proszę weź pod uwagę następujące kwestie:

  • Coś powinno być zrozumiałe: tekstowo, wizualnie, logicznie oraz pod względem stopnia skomplikowania.
  • Niektórzy użytkownicy potrzebują do interakcji czytnika ekranu, ale równie, jeśli nie bardziej powszechne są: lupa, wyższy kontrast, silnik tekstu na mowę, niestandardowe ustawienia CSS lub specjalny typ klawiatury/urządzenia wejściowego.
  • Musi być dostępne; pod względem szybkości reakcji, kosztów, lokalizacji, języka, sprzętu itd.

Podsumowując, dostępność to nie tylko dostępność klawiatury lub jedynie dostępność czytnika ekranu. Często skupiamy się na tych dwóch aspektach, ponieważ tradycyjnie bywają one łatwo pomijane. Jednak te problemy są również do rozwiązania i często stanowią podstawę dla wszelkich innych możliwych ulepszeń.

Niektóre problemy z dostępnością wynikają z projektowania produktu, wyborów strategicznych, grupy docelowej itp. Ponieważ te obszary są trudniejsze do ujęcia w uniwersalnych, pisemnych zasadach dotyczących ekosystemu MediaWiki, wykraczają poza zakres tego dokumentu.

Nawigacja za pomocą klawiatury

Nazywamy to nawigacją za pomocą klawiatury, ale w rzeczywistości oznacza to: nie polegaj na urządzeniu wskazującym (dotyk, mysz).

  • Nawigacja za pomocą klawiatury polega na manipulowaniu fokusem oraz wykonywaniu działań za pomocą klawiatury.
  • Elementy, które można uaktywnić klawiszem Tab, można też przełączyć na tryb fokusowania, ale nie wszystko, co można sfokusować, można uaktywnić klawiszem Tab.
  • Wszystko, co możesz zrobić za pomocą myszy, powinno być możliwe do wykonania przy użyciu klawiatury.
  • Informacje na temat nawigacji za pomocą klawiatury mogą być wykorzystywane przez czytniki ekranu w celu zwiększenia komfortu korzystania z urządzenia.

Czytnik ekranu

  • Czytnik ekranu używa innego „kursora”, który zwykle porusza się po logicznej strukturze DOM.
  • Fokus (aktywne zaznaczenie interfejsu) zwykle podąża za kursorem czytnika ekranu i odwrotnie, ale nie są to tożsame elementy
    • Możesz śledzić wybrany element, ustawiając wyrażenie na żywo w Chrome [1]
  • Czytnik ekranu korzysta z interfejsów API „dostępności”, które można uważać za „widok” wejścia/wyjścia nałożony na normalny DOM.
  • ARIA to adnotacje DOM, które wzbogacają lub manipulują sposobem, w jaki logika DOM jest przekształcana w interfejsy API ułatwień dostępu. Nie jest to alternatywa dla pisania poprawnego kodu HTML i JavaScript. Nawigacja za pomocą klawiatury jest realizowana w prosty sposób poprzez logiczną kolejność DOMǃ Więcej informacji na temat ARIA znajdziesz w wyjaśnieniu w3.org i wyjaśnieniu MDN.
  • Czytnik ekranu nie musi ograniczać się do nawigacji zgodnie z logiczną strukturą DOM, jest to po prostu nawigacja domyślna.
    • Czytnik ekranu może na przykład odczytać to, co znajduje się pod wskaźnikiem myszy
    • VoiceOver na iOS korzysta z kursora ekranowego, którym można sterować za pomocą położenia kciuka i gestów wykonywanych na ekranie dotykowym.
    • Większość programów dla czytników ekranu ma dodatkowe tryby nawigacji, w których można wyświetlać i poruszać się według punktów orientacyjnych, automatycznie generowanego Spisu Treści lub nawet zdefiniowanych przez użytkownika „zakładek” na stronie.
  • Z powyższego punktu widzenia, jeśli chodzi o wiele metod nawigacji, wynika, że: Jest początek i koniec, ale jest też lewa i prawa strona, góra i dół. Nie powinieneś zbytnio polegać na nich w swojej komunikacji, ale nie powinieneś też całkowicie negować ich istnienia. Nie należy mylić zdolności wizualnych użytkownika ze świadomością przestrzenną, którą czytnik ekranu może przekazać użytkownikowi. Przykład:
    1. długie zdanie [obraz] powyższy obraz przedstawia... Still acceptable
    2. długie zdanie [obraz][obraz] lewy obraz przedstawia, prawy obraz przedstawia... Still acceptable
    3. długie zdanie [obraz][obraz] prawy obraz przedstawia, lewy obraz przedstawia... Not acceptable
    4. długie zdanie [obraz][obraz] powyższy obraz przedstawia... Not acceptable
    5. długie zdanie [obraz][obraz][obraz] lewy obraz przedstawia, prawy obraz przedstawia... Not acceptable
    6. długie zdanie [obraz][obraz] coś całkowicie innego. lewy obraz przedstawia, prawy obraz przedstawia... Definitely not acceptable

Zasady rozwoju

Istnieje wiele standardów dotyczących dostępności i szczerze mówiąc, niemal wszystkie z nich, mimo że dobrze identyfikują problemy, wciąż mają poważne braki w zakresie rozwiązań technicznych (mają wysoki współczynnik „brzydkich obejść”). Było to przyczyną wielu kontrowersji w społecznościach. W związku z tym powinniśmy wskazać rzeczy, które nie budzą kontrowersji i które po prostu zawsze (albo nigdy) powinniśmy robić i dlaczego. O wiele łatwiej będzie nam osiągnąć określone cele, jeśli oddzielimy rzeczy niekontrowersyjne od kontrowersyjnych.

Zawsze używaj lub zapewniaj

Właściwy semantyczny element HTML
Używaj elementów HTML zgodnie z ich przeznaczeniem. Na przykład:
  • Użyj ‎<button>, a nie ‎<div>, ‎<span> lub ‎<a> z programem do obsługi kliknięć
  • Jeśli czujesz potrzebę pogrubienia czegoś, zastanów się, czy nie lepiej użyć nagłówka lub elementu strong
Logiczna struktura nagłówków
Wszystkie strony powinny mieć logiczną i spójną strukturę nagłówków. Nagłówki stanowią jedno z podstawowych narzędzi nawigacyjnych wykorzystywanych przez użytkowników czytników ekranu.
  1. Nie powinno być żadnych przerw w zagnieżdżaniu poziomów nagłówków. (Więc nie H2->H4.)
  2. Nagłówki powinny być opisowe
  3. Nagłówki powinny być unikalne w obrębie swojego poziomu. (Nie powinno być dwóch nagłówków H3 o tej samej treści w tej samej sekcji H2)
  4. Powinno być rozdzielenie między nawigacją a treścią
Atrybut alt dla obrazów o znaczących wartościach
Jeśli obraz ma charakter dekoracyjny, użyj jawnie pustej wartości atrybutu alt; jeszcze lepszym rozwiązaniem jest przekształcenie go w obraz tła CSS.
Atrybut alt obrazu zwykle ma pierwszeństwo przed atrybutem title obrazów, a nawet nad atrybutem title linków otaczających obraz.
Atrybut title dla linków
Są one zazwyczaj wyświetlane jako podpowiedzi
Tytułów należy używać tylko wtedy, gdy różnią się od tekstu linku.
Większość tytułów linków nie jest w rzeczywistości odczytywana przez czytniki ekranu, chyba że czytnik został w ten sposób wyraźnie skonfigurowany.
Atrybuty lang, dir i hreflang
Użycie lang i hreflang umożliwia wybór odpowiedniego głosu w czytnikach ekranu, dobranie odpowiedniej korekty pisowni w przeglądarkach itd.
Wystarczający kontrast
Zawsze sprawdzaj, czy kolory mają wystarczający kontrast. W przypadku tekstu o mniejszej wielkości wymagany jest większy kontrast (ze względu na wygładzanie krawędzi).
Zachowanie fokusu przy nawigacji klawiaturą
Nie wykonuj polecenia not remove outline w elementach, do których można uzyskać fokus, chyba że zdefiniujesz własny kontur dla stanu :focus.
  • W przeciwnym razie nie używaj outline: 0.
  • Jeśli zdefiniujesz jakąkolwiek pseudoklasę, np. :hover lub :active, zdefiniuj także styl :focus.
Nawigacja klawiaturą
Interaktywne elementy strony powinny umożliwiać nawigację za pomocą klawiatury. Upewnij się, że w Twojej przeglądarce włączona jest nawigacja za pomocą klawisza Tab, która umożliwi sterowanie poszczególnymi elementami interaktywnymi bez korzystania z urządzenia wskazującego.
  1. Użyj tabIndex: 0, aby udostępnić z klawiatury elementy, które domyślnie nie są dostępne z klawiatury (wszystko oprócz ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. W tym przypadku należy dodać także obsługę klawisza (keydown) reagującą na Enter (keyCode 13) i spację (keyCode 32).
  2. Użyj tabindex: -1, aby usunąć elementy z listy dostępności. (użyj tego na przykład w przypadku linków, które są etykietami akcji wewnątrz ‎<li>...‎</li>)
  3. Elementy, do których dostęp jest domyślnie możliwy z klawiatury, przekażą klawisz Enter/spacja do programu obsługującego kliknięcie
Dialogi itp.

Jeśli nie zadba się o dostępność, okna dialogowe staną się jednymi z najtrudniejszych do uzyskania dostępu przez użytkowników czytników ekranu i klawiatur. Poświęć temu trochę czasu.

  • Element otwierający okno dialogowe powinien zawierać aria-haspopup
  • Samo okno dialogowe powinno zawierać role=[dialog | alertdialog | tooltip]
  • Okno dialogowe powinno być wstawiane w kolejności DOM, [1] lub aria owns/controls musi określić tę relację między elementem otwierającym a oknem dialogowym
  • Podczas otwierania okna dialogowego zapamiętaj ostatni wybrany element i przesuń fokus na pierwszy możliwy do fokusowania element w oknie dialogowym
  • Gdy okno dialogowe jest modalne, uniemożliwij interakcję z resztą strony
    • Przechwytuj kliknięcia poza oknem dialogowym i ignoruj ​​je lub pozwól im zamknąć okno dialogowe
    • Upewnij się, że nie możesz przejść do linków lub elementów wejściowych poza oknem dialogowym za pomocą klawisza Tab
    • Uczyń elementy poza oknem dialogowym niedostępne dla czytnika ekranu, używając aria-hidden
  • Upewnij się, że dostępny jest tryb zamykania (klawisz Esc i przycisk zamykania z opisowym tytułem)
  • Zamknięcie powinno przywrócić fokus (klawiatury) do oryginalnego punktu fokusu, który zapisałeś podczas otwierania okna dialogowego. Aby czytniki ekranu powracały do ​​tego samego punktu, pamiętaj o podaniu prawidłowego właściciela okna dialogowego, jeśli nie wstawiłeś okna dialogowego zgodnie z kolejnością DOM.
  • Przeczytaj: Aria modalne, modalne dialogi Aria, niemodalne dialogi ARIA, podpowiedzi ARIA.
WCAG 2.1 zasady
Przestrzegaj tych zasad gdziekolwiek to możliwe
A także towarzyszące mu dokumenty:

Czego nie robić

  • Często zaleca się użycie left: -1000px do wypchnięcia czegoś (często etykiet ikon przycisków) poza obszar widoku dla użytkowników wizualnych, przy jednoczesnym zachowaniu dostępności DOM. text-indent: -9999px jest odmianą tego. To jest ZŁA rada.
    • Utrudnia to renderowanie RTL w wielu przeglądarkach. Szczególnie w trybie RTL tworzy duże płótno po lewej stronie okna widoku i pasków przewijania, podobnie jak +1000px w trybie LTR. (W razie potrzeby, aby tego uniknąć, preferowany jest top: -1000px zamiast left: -1000px.).
    • Funkcja VoiceOver na urządzeniach mobilnych nie może używać tego tekstu jako rozwiązania awaryjnego, ponieważ jest „pozycyjnym” czytnikiem ekranu. Nie możesz przesuwać palca po tym tekście, więc nie zostanie on odczytany. (aria-label często jest lepszym wyborem).
    • Wreszcie, zwiększa to powierzchnię renderowania potrzebną do obliczenia ostatecznej strony internetowej, co może mieć wpływ na wydajność [2] na urządzeniach mobilnych.
    • Wnikliwy przegląd sztuczek pozwalających ukryć tekst poza ekranem przedstawił Jonathan Snook.
  • Nie należy często powtarzać tych samych elementów. Jeśli na stronie znajduje się 100 linków, które mogą otwierać okna dialogowe, nie dodawaj do tych 100 etykiet informujących użytkownika, że ​​można za ich pomocą otworzyć okno dialogowe. Mówienie użytkownikowi, jak używać interfejsu i co z nim robić, to dobra rzecz, ale ciągłe powtarzanie tego jest po prostu irytujące. Znajdź inny sposób, aby wyjaśnić to raz (w tym przypadku pomysłem może być aria-live=polite?).
  • <a href="#">Hide</a> z obsługą onclick. VO odczytuje taki JS jako „ukryj link wewnętrzny”. Użyj odpowiedniego przycisku, czyli <a role="button" tabindex="0">Hide</a>, z klawiszami „Space” i „Enter” w onclick. Ale bez atrybutu href.
  • Nie należy umieszczać funkcji interaktywnych wewnątrz innych elementów interaktywnych (linków lub przycisków wewnątrz linków). To wprowadza w błąd czytniki ekranu.

Unikać

Symbole Unicode
Większość technologii wspomagających nie radzi sobie dobrze z symbolami. Dlatego staraj się unikać znaków takich jak ↑, →‎ lub bardziej złożonych znaków, ponieważ wiele czytników ekranu ich nie rozpoznaje. Jeśli są wymagane, spróbuj ująć je w element span z atrybutem title, tak aby atrybut title mógł przekazać czytelnikowi ukryte znaczenie w kontekście.
Małe czcionki
Czytelność jest preferowana. Jeśli coś jest tak małe, że trudno to przeczytać, czy w ogóle jest to potrzebne? Należy również unikać małych czcionek o niskim lub przeciętnym kontraście (nawet jeśli spełniają one wytyczne WCAG, małe rozmiary wymagają wyraźniejszego kontrastu niż duże rozmiary, szczególnie po włączeniu wygładzania krawędzi).
Niezwykle duże czcionki
Jeśli tekst będzie znacznie większy niż zwykle, może stać się trudny do odczytania (chyba że będzie bardzo krótki). Dotyczy to głównie tekstu body i wszelkich treści, które zajmują więcej niż kilka wierszy. Ale im większy tekst, tym więcej wierszy zajmie.
tabIndex > 0
Jeśli to możliwe, preferowana jest kolejność DOM. Kolejność DOM zapewnia kontekst dla działań.
Obejście problemu
Tradycyjnie, osiągnięcie „pełnej” dostępności wymagało wielu obejść w samym kodzie HTML, przeglądarkach, a nawet konkretnym oprogramowaniu do odczytu ekranu. Jednak te obejścia często wiążą się z efektami ubocznymi, wykorzystują błędy lub nieokreślone zachowania i nieuchronnie generują dług techniczny.
MediaWiki, ze względu na liczbę użytkowników, którym chce służyć, ilość kodu, (brak) finansowania itp., preferuje kod odporny na zmiany w przyszłości, a nie taki, który łatwo ulega awarii. W związku z tym zazwyczaj unika obejść, nawet jeśli czasami ogranicza to dostępność, jaką możemy zapewnić. Decyzje w tej sprawie często zależą od względnej grupy odbiorców danej funkcji w MediaWiki. Jeśli coś jest powszechne dla wszystkich użytkowników, obejście problemu jest bardziej uzasadnione niż w przypadku, gdy z danej funkcji korzysta tylko niewielka część odbiorców (na przykład do czytania strony zamiast modyfikowania konfiguracji instalacji).

Rozważyć

  • Role ARIA
    • Jeśli div lub span zachowuje się jak prawdziwy przycisk, użyj role="button", a także role="dialog" i role="alert"
    • Uważaj na role. Na przykład nie dodawaj role="button" do elementu ‎<th>, ponieważ element ‎<th> ma niejawny element role="columnheader", który zostanie nadpisany. Zamiast tego, użyj elementów zagnieżdżonych. Podobnie jest w przypadku 1$, który ma niejawne 2$
    • Jeśli przycisk tworzy dialog w popupie, użyj aria-haspopup.
    • Użyj aria-labelled-by w kontekstach, w których samo w sobie nie jest to logiczne (czyli wszędzie, z wyjątkiem etykiet w formularzach i nagłówków w tabelach).
  • Unikaj tabel ze względu na układ strony i testuj na mniejszych szerokościach ekranu.
  • ukryj rzeczy: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • pomiń/przeskocz do linków

Zobacz też

Przypisy

  1. ↑ Zobacz kolejność DOM na w3.org i Właściwość order w CSS na w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/pl&oldid=7840340"