Wprowadzenie do web-accessibility - część 3

Wprowadzenie do web-accessibility - część 3

Dostępność WebFront-end

Web-Accessibility - podstawy (Seria 3 części)

Zasada Zrozumiałości

Czytelność

Język Strony

Celem tej techniki jest identyfikacja domyślnego języka dokumentu poprzez dostarczenie atrybutu w elemencie HTML. Określenie języka dokumentu jest ważne z kilku powodów:

  • Pozwala oprogramowaniu do tłumaczenia alfabetu Braille'a na zastąpienie kodów kontrolnych znakami akcentowanymi i wstawienie kodów kontrolnych niezbędnych do zapobiegania nieprawidłowemu formowaniu skrótów Braille'a stopnia 2.
  • Wielojęzyczne syntezatory mowy mogą zorientować się i dostosować do wymowy i składni charakterystycznej dla języka strony, wymawiając tekst z odpowiednim akcentem i wymową.
  • Oznaczenie języka może przynieść korzyści dla przyszłego rozwoju technologii, na przykład użytkownicy, którzy nie mogą tłumaczyć między językami, będą mogli używać maszyn do tłumaczenia nieznanych języków.
  • Oznaczenie języka może również pomóc agentom użytkownika w tworzeniu definicji za pomocą słownika.

Fragmenty Językowe

Język ludzki każdego fragmentu lub frazy w treści może być programowo określony, z wyjątkiem nazw własnych, terminów technicznych, słów w nieokreślonym języku oraz słów lub fraz, które stały się częścią żargonu otaczającego tekstu.

Przewidywalność

Gdy dowolny komponent interfejsu użytkownika otrzymuje fokus, nie inicjuje on zmiany kontekstu. Celem tej techniki jest zapewnienie metody aktywacji, która jest przewidywalna dla użytkownika. Użytkownicy z niepełnosprawnościami poznawczymi oraz osoby korzystające z czytników ekranu lub lup ekranowych mogą być zdezorientowani przez nieoczekiwane zdarzenie, takie jak automatyczne wysłanie formularza lub aktywacja funkcji, która powoduje zmianę kontekstu. Dzięki tej technice wszystkie zmiany kontekstu byłyby wyzwalane tylko przez określone działanie użytkownika. Ponadto takie działanie zwykle powoduje zmiany kontekstu, takie jak kliknięcie linku lub naciśnięcie przycisku submit. Działania, które po prostu przenoszą fokus na element, nie powodowałyby zmiany kontekstu. Przykład:

  • Strona wyskakuje w nowym oknie tylko wtedy, gdy użytkownik kliknie przycisk (lub użyje spacji) na przycisku, zamiast używać do wyświetlenia nowego okna.
  • Przycisk submit jest używany do przejścia do następnego ekranu wprowadzania danych, zamiast automatycznego wyświetlania następnego ekranu, gdy użytkownik kliknie przycisk "gotowe".

Zmiana ustawienia dowolnego komponentu interfejsu użytkownika nie powoduje automatycznie zmiany kontekstu, chyba że użytkownik został poinformowany o zachowaniu przed użyciem komponentu. Przykład:

  • Przycisk submit jest używany dla każdego formularza, który powoduje zmianę kontekstu.

Mechanizmy nawigacyjne, które są powtarzane na wielu stronach internetowych w ramach zestawu stron internetowych, występują w tym samym względnym porządku za każdym razem, gdy są powtarzane, chyba że użytkownik zainicjuje zmianę. Przykład:

  • Menu nawigacyjne zawsze pojawia się w tej samej kolejności na różnych podstronach.

Komponenty, które mają tę samą funkcjonalność w ramach zestawu stron internetowych, są konsekwentnie identyfikowane. Przykłady:

  • Strona internetowa ma pole formularza na górze strony oznaczone jako "Szukaj". Na dole strony znajduje się inne pole formularza, które zapewnia tę samą funkcję. Jest ono również oznaczone jako "Szukaj".
  • Obraz znaku zapytania jest używany do kierowania użytkowników do sekcji strony, które zawierają dodatkowe informacje. Za każdym razem, gdy pojawia się obraz znaku zapytania, ma ten sam alternatywny tekst "więcej informacji".
  • Link do strony Kontakt na stronie internetowej zawiera tekst "Kontakt". Na dole strony znajduje się link, który również prowadzi do strony Kontakt. Ma on również tekst linku "Kontakt".

Spójna Pomoc (WCAG 2.2 - 3.2.6, Poziom A)

Funkcje pomocy, które są wyświetlane na wielu stronach internetowych, są dostępne zawsze w tym samym miejscu w obrębie zestawu stron internetowych. Dotyczy to elementów takich jak:

  • Linki do instrukcji
  • Kontakt z działem wsparcia
  • Mechanizmy pomocy kontekstowej
  • Chatboty pomocnicze

Przykłady implementacji:

  • Link "Pomoc" znajduje się w tym samym miejscu na każdej podstronie serwisu
  • Ikona chatbota jest zawsze umieszczona w prawym dolnym rogu ekranu
  • Formularz kontaktu z działem wsparcia jest dostępny w tej samej lokalizacji w menu na każdej podstronie

Pomoc Przy Wprowadzaniu

Jeśli wykryty zostanie błąd, użytkownik jest informowany o nim tekstowo. Celem tej techniki jest powiadomienie użytkownika, gdy wymagane pole nie zostało wypełnione. Gdy użytkownicy nie dostarczają danych wejściowych dla dowolnych wymaganych pól w formularzu, informacje są podawane w tekście, aby użytkownicy mogli określić, które pola zostały pominięte. Jednym z podejść jest użycie walidacji po stronie klienta i dostarczenie okna dialogowego z ostrzeżeniem identyfikującym pominięte wymagane pola. Innym podejściem, wykorzystującym walidację po stronie serwera, jest ponowne wyświetlenie formularza (w tym wcześniej wprowadzone dane) z tekstowym opisem w miejscu pominiętego wymaganego pola lub tekstowym opisem identyfikującym pominięte wymagane pola. Najlepszą praktyką jest dołączenie wiadomości lub alertu, ponieważ niektórzy użytkownicy mogą nie być świadomi błędu i mogą założyć, że formularz nie działa poprawnie. Najlepszą praktyką jest również umieszczenie powiadomienia o błędzie w tytule strony (element title), ponieważ użytkownik czytnika ekranu prawdopodobnie założy, że strona została poprawnie przesłana i będzie kontynuował nawigację do innej strony, gdy tylko nowa strona zostanie zwrócona, zamiast ponownie czytać główny obszar treści strony. Więcej technik dostarczonych przez W3C. Przykłady:

  • Używanie , , w wymaganych polach:
  • Używanie do identyfikacji błędów. Celem tej techniki jest ostrzeżenie ludzi o wystąpieniu błędu wprowadzania. Użycie tworzy powiadomienie. To powiadomienie powinno być modalne z następującymi cechami:
    • Atrybut lub nadaje oknu dialogowemu alertu dostępną nazwę.
    • zapewnia odniesienie do tekstu ostrzeżenia.
    • Okno dialogowe alertu zawiera co najmniej jedną kontrolkę, którą można ustawić, a fokus powinien przejść do tej kontrolki, gdy okno dialogowe alertu się otworzy.
    • Kolejność tabulacji jest ograniczona do okna dialogowego alertu, gdy jest ono otwarte.
    • Gdy okno dialogowe jest zamknięte, fokus wraca do pozycji, którą miał przed otwarciem okna dialogowego, jeśli to możliwe.

Należy zauważyć, że okno dialogowe alertu nie powinno być obecne w sposób, który czyni je dostępnym dla AT, dopóki nie jest potrzebne. Jednym ze sposobów jest nieuwzględnianie go w statycznym kodzie HTML i zamiast tego wstawianie go do DOM za pomocą skryptu, gdy warunek błędu zostanie wyzwolony. Wstawienie odpowiadałoby następującemu przykładowi HTML.

  • Zapewnienie opisowych etykiet (etykiet) - metody W3C:
    • Używanie właściwości do zapewnienia opisowej etykiety dla kontrolek interfejsu użytkownika (więcej przykładów ) (przykład kodu online):
  • Właściwość może być używana do etykietowania wszystkich obiektów wizualnych. Dla inputów właściwość może być używana do etykietowania natywnych inputów. Szczególnym zastosowaniem jest dla wprowadzania tekstu w sytuacjach, gdy znacząca etykieta powinna składać się z więcej niż jednego ciągu etykiety.
  • Używanie ról grupowania do identyfikacji powiązanych kontrolek formularza:

Celem tej techniki jest pomoc użytkownikowi w uniknięciu błędów wprowadzania, informując ich o ograniczeniach formatu dla danych, które muszą wprowadzić. Można to zrobić, opisując cechy formatu lub dostarczając przykładowy format danych. Na przykład informowanie w etykiecie o formacie do wprowadzenia:

Celem tej techniki jest pomoc użytkownikowi w uniknięciu błędów wprowadzania, informując ich z wyprzedzeniem o ograniczeniach formatu dla danych, które muszą wprowadzić. Instrukcje dotyczące takich ograniczeń są umieszczane na górze formularzy. Ta technika działa najlepiej dla formularzy z małą liczbą pól lub tych, gdzie wiele pól formularza wymaga danych w tym samym formacie. W takich przypadkach bardziej efektywne jest opisanie formatu raz w instrukcjach na górze formularza niż powtarzanie tych samych informacji dla każdego pola, które ma te same wymagania formatu.

Zapobieganie Redundantnemu Wprowadzaniu (WCAG 2.2 - 3.3.7, Poziom A)

Informacje, które zostały wcześniej wprowadzone przez użytkownika lub dostarczone przez system i wymagane są ponownie w tym samym procesie, są albo:

  1. Automatycznie wypełniane, lub
  2. Dostępne dla użytkownika do wyboru

Wyjątki stanowią:

  • Ponowne wprowadzenie informacji jest niezbędne ze względów bezpieczeństwa
  • Informacja nie jest już aktualna
  • Użytkownik musi potwierdzić poprzednio wprowadzone dane

Przykłady implementacji:

  • Formularz rejestracyjny automatycznie wypełnia pola adresu na podstawie kodu pocztowego
  • System zapamiętuje adres dostawy z poprzedniego zamówienia i oferuje go do wyboru
  • Formularz kontaktowy wypełnia dane z profilu użytkownika

Dostępne Uwierzytelnianie (WCAG 2.2 - 3.3.8, Poziom AA)

Dla każdego kroku w procesie uwierzytelniania, który polega na teście poznawczym (wymagającym zapamiętania, przepisania lub rozpoznania czegoś), przynajmniej jedna alternatywna metoda musi być dostępna, która nie opiera się na teście poznawczym, lub obejmuje wsparcie pozwalające ukończyć test poznawczy.

Przykłady implementacji:

  • Oferowanie logowania przez hasło wraz z alternatywą w postaci klucza sprzętowego
  • Umożliwienie użycia menedżera haseł zamiast ręcznego wprowadzania hasła
  • Zapewnienie możliwości logowania przez odcisk palca lub rozpoznawanie twarzy jako alternatywy dla CAPTCHA

Dostępne Uwierzytelnianie (Rozszerzone) (WCAG 2.2 - 3.3.9, Poziom AAA)

Dla każdego kroku w procesie uwierzytelniania, który opiera się na teście poznawczym, przynajmniej jedna alternatywna metoda uwierzytelniania, która nie opiera się na teście poznawczym, musi być dostępna.

W przeciwieństwie do poziomu AA, ten poziom wymaga pełnej alternatywy bez testów poznawczych, zamiast tylko wsparcia w ich ukończeniu.

Przykłady implementacji:

  • Oferowanie uwierzytelniania dwuskładnikowego, gdzie drugi składnik może być realizowany przez urządzenie fizyczne zamiast kodu
  • Udostępnienie możliwości logowania przez klucze biometryczne jako pełną alternatywę dla metod wymagających zapamiętania

Wskazywanie Wymaganych Kontrolek Za Pomocą Etykiety lub Legendy

  • Używanie tekstu do wskazania wymaganego statusu:
  • Używanie gwiazdki do wskazania wymaganego statusu:
  • Wskazywanie wymaganego statusu dla grup przycisków radio lub pól wyboru. Przyciski radio i pola wyboru są traktowane inaczej niż inne interaktywne kontrolki, ponieważ poszczególne przyciski radio i pola wyboru nie są wymagane, ale odpowiedź jest wymagana dla grupy. Metody zastosowane w przykładach mają zastosowanie do przycisków radio i pól wyboru, ale wskazanie wymaganego statusu powinno być umieszczone w elemencie legend zamiast w elemencie label.
  • Używanie elementów label do kojarzenia etykiet tekstowych z kontrolkami formularzy. Celem tej techniki jest użycie elementu label do jawnego powiązania kontrolki formularza z etykietą. Etykieta jest dołączana do konkretnej kontrolki formularza za pomocą atrybutu . Wartość atrybutu musi być taka sama jak wartość atrybutu kontrolki formularza.
  • Używanie automatycznego etykietowania do kojarzenia etykiet tekstowych z kontrolkami formularzy.

Zapobieganie Błędom

  • Zapewnienie użytkownikowi możliwości przeglądu i poprawy odpowiedzi przed wysłaniem.
  • Prośba o potwierdzenie kontynuowania wybranego działania.
  • Zapewnienie możliwości odzyskania usuniętych informacji
DI

Damian Idczak LinkedIn - Damian Idczak

Senior Software Engineer @ Sopra Steria