Trwa tłumaczenie tego artykułu.

Sieć się zmienia. Statyczne witryny oparte na stronach są coraz częściej zastępowane dynamicznymi aplikacjami internetowymi w stylu aplikacji pulpitowych, które intensywnie wykorzystują JavaScript i AJAX. Projektanci tworzą niesamowite nowe widżety i kontrolki całkowicie za pomocą kombinacji JavaScript, HTML i CSS. Ta zmiana może znacznie poprawić responsywność i użyteczność internetu, ale wielu użytkowników jest zagrożonych wykluczeniem z powodu luk w dostępności. JavaScript tradycyjnie cieszy się reputacją niedostępności dla użytkowników technologii pomocniczych, takich jak czytniki ekranu, ale istnieją teraz sposoby na tworzenie dynamicznych interfejsów internetowych, które są dostępne dla szerokiego grona użytkowników.

Problem

Większość zestawów narzędzi JavaScript oferuje bibliotekę widżetów po stronie klienta, które naśladują zachowanie znanych interfejsów pulpitu. Suwaki, paski menu, widoki list plików i wiele więcej można zbudować za pomocą kombinacji JavaScript, CSS i HTML. Ponieważ specyfikacja HTML 4 nie zapewnia wbudowanych znaczników, które semantycznie opisują tego rodzaju widżety, programiści zazwyczaj używają ogólnych elementów, takich jak <div> i <span>. Skutkuje to widżetem, który wygląda jak jego odpowiednik na pulpicie, jednak zwykle nie ma wystarczającej ilości znaczników semantycznych do wykorzystania przez technologię wspomagającą. Dynamiczne treści na stronie internetowej mogą być szczególnie problematyczne dla użytkowników, którzy z jakiegoś powodu nie są w stanie wyświetlić ekranu. Informacje giełdowe, aktualizacje kanałów live twitter, wskaźniki postępu i podobne treści modyfikują DOM w taki sposób, że technologia wspomagająca (AT) może nie być świadoma. Wtedy z pomocą wkracza ARIA.

Przykład 1: Znaczniki dla widżetów kart zbudowanych bez etykietowania ARIA. W znacznikach nie ma informacji opisujących formę i funkcję widżetu.

<!-- To jest widget zakładek. Jak możesz to rozpoznać, patrząc tylko na znaczniki? -->
<ol>
  <li id="ch1Tab">
    <a href="#cz1Panel">Część 1</a>
  </li>
  <li id="ch2Tab">
    <a href="#cz2Panel">Część 2</a>
  </li>
  <li id="quizTab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <div id="ch1Panel">Zawartość części nr 1 </div>
  <div id="ch2Panel">Zawartość częśći nr 2</div>
  <div id="quizPanel">Zawartość Quizu</div>
</div>

Przykład 2: Sposób wizualnego przedstawienia widżetów karty. Użytkownicy mogą rozpoznać to wizualnie, jednak nie ma semantyki do odczytu maszynowego dla technologii wspomagającej.
Screenshot of the tabs widget

ARIA

WAI-ARIA, Accessible Rich Internet Applications specyfikacja wywodząca się od W3C Web Accessibility Initiative, umożliwia dodanie brakującej semantyki potrzebnej w przypadku technologii pomocniczych, takich jak czytniki ekranu. ARIA umożliwia programiście bardziej szczegółowe opisywanie tych widżetów poprzez dodawanie specjalnych atrybutów do znaczników. Zaprojektowany, aby wypełnić lukę pomiędzy standardowymi znacznikami HTML a formantami w stylu pulpitu znajdującymi się w dynamicznych aplikacjach internetowych, ARIA udostępnia role i stany, które opisują zachowanie najbardziej znanych widgetów interfejsu użytkownika.

Specyfikacja ARIA jest podzielona na trzy różne typy atrybutów: role, stany i właściwości. Role opisują widżety, które nie są w inny sposób dostępne w HTML 4, takie jak suwaki, paski menu, karty i okna dialogowe. Właściwości opisują charakterystykę tych widgetów, na przykład, czy są one przeciągalne, mają wymagany element lub czy powiązane jest z nim wyskakujące okienko. Stany opisują bieżący stan interakcji elementu, informując technologię asystującą, jeśli jest zajęta, wyłączona, wybrana lub ukryta.

Atrybuty ARIA mają być interpretowane automatycznie przez przeglądarkę i tłumaczone na natywne API systemu operacyjnego. Kiedy ARIA jest obecna, technologie asystujące są w stanie rozpoznać i sterować niestandardowymi kontrolkami JavaScript w taki sam sposób, jak robią to z odpowiednikami komputerów. Może to zapewnić znacznie bardziej spójny interfejs użytkownika, niż było to możliwe w poprzedniej generacji aplikacji internetowych, ponieważ użytkownicy technologii pomocniczych mogą wykorzystać całą swoją wiedzę na temat działania aplikacji komputerowych podczas korzystania z aplikacji internetowych.

Przykład 3: Znaczniki dla widżetów kart z dodanymi atrybutami ARIA.

<!-- Dodaliśmy atrybut "role" aby opisać listę kart i poszczególne karty. -->
<ol role="tablist">
  <li id="ch1Tab" role="tab">
    <a href="#ch1Panel">Część 1</a>
  </li>
  <li id="ch2Tab" role="tab">
    <a href="#ch2Panel">Część 2</a>
  </li>
  <li id="quizTab" role="tab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <!-- Zwróć uwagę na rolę i atrybuty "aria-labelledby", które dodaliśmy do opisu tych paneli. -->
  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">Zawartość części nr 1</div>
  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">Zawartość części nr 2</div>
  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">Zawartość Quizu</div>
</div>

ARIA jest obsługiwana w najnowszych wersjach wszystkich głównych przeglądarek, w tym Firefox, Safari, Opera, Chrome i Internet Explorer. Wiele technologii wspomagających, takich jak open source NVDA i czytniki ekranu Orca, również obsługuje ARIA. Coraz częściej biblioteki widgetów JavaScript, takie jak jQuery UI, YUI, Google Closure i Dojo Dijit, również zawierają znaczniki ARIA.

Zmiany prezentacyjne

Dynamiczne zmiany prezentacyjne obejmują używanie CSS do zmiany wyglądu treści (np. Czerwone obramowanie wokół nieprawidłowych danych lub zmiana koloru tła zaznaczonego pola wyboru), a także pokazywanie lub ukrywanie treści.

Zmiany stanu

ARIA udostępnia atrybuty do deklarowania bieżącego stanu widgetu interfejsu użytkownika. Przykłady obejmują (ale z pewnością nie są ograniczone do):

  • aria-checked: wskazuje stan pola wyboru lub przycisku opcji
  • aria-disabled: wskazuje, że element jest widoczny, ale nie można go edytować lub użyć w inny sposób
  • aria-grabbed: wskazuje stan "chwycony" obiektu w operacji przeciągania i upuszczania

(Pełna lista stanów: ARIA list of states and properties.)

Programiści powinni używać stanów ARIA do wskazania stanu elementów widgetu interfejsu użytkownika i używać selektorów atrybutów CSS do zmiany wyglądu wizualnego na podstawie zmian stanu (zamiast używania skryptu do zmiany nazwy klasy na elemencie).

Zmiany widoczności

Gdy zmieni się widoczność zawartości (tzn. Element jest ukryty lub pokazany), programiści powinni zmienić wartość właściwości aria-hidden. Opisane powyżej techniki powinny być używane do deklarowania CSS do wizualnego ukrywania elementu za pomocą display:none.

Przykład przedstawia prosty formularz internetowy z etykietami narzędzi zawierającymi instrukcje powiązane z polami wprowadzania.

Przykład kodu HTML z atrybutem aria-hidden ustawionym na wartość true.

<div class="text">
    <label id="tp1-label" for="first">Pierwsze imię:</label>
    <input type="text" id="first" name="first" size="20"
           aria-labelledby="tp1-label"
           aria-describedby="tp1"
           aria-required="false" />
    <div id="tp1" class="tooltip"
         role="tooltip"
         aria-hidden="true">Twoje pierwsze imię jest opcjonalne</div>
</div>

Poniżej kod CSS dla powyższego przykładu.
Zwróć uwagę na to że nie użyto typowego selektora klasy, lecz selektora atrybutu  aria-hidden ustawionego na wartość "true".

div.tooltip[aria-hidden="true"] {
  display: none;
}

Kod JavaScript dla powyższego przykładu, aktualizujący atrybut  aria-hidden.

var showTip = function(el) {
  el.setAttribute('aria-hidden', 'false');
}

Zmiany ról

W budowie

ARIA pozwala programistom zadeklarować rolę semantyczną dla elementu, który w przeciwnym razie oferuje niepoprawną lub brak semantyki. Na przykład, gdy do utworzenia menu jest używana lista nie numerowana <ul> powinien otrzymać atrybut role zdefiniowany jako menubar a każdy element listy <li> powinien otrzymać atrybut role o wartości menuitem.

Atrybut role nie powinien być zmieniany. Zamiast tego usuń oryginalny element i zastąp go elementem z nową wartością atrybutu role.

Rozważmy przykład widgetu "edycji bezpośredniej": komponent który pozwala użytkownikom edytować fragment tekstu na miejscu, bez przełączania kontekstów . Ten komponent ma tryb "widok", gdzie tekst nie jest edytowalny, ale można go aktywować, oraz tryb "edycja", w którym tekst jest edytowalny. Deweloper może ulec pokusie, aby zaimplementować tryb "widok" używając elementu  <input> tylko do odczytu, i ustawić jego ARIA atrybut role na wartość button, następnie po przęłączeniu w tryb "edycja" uczynić element zapisywalnym i usunąć atrybut w tym trybie atrybut role (ponieważ element <input> ma własną semantykę ról).

Nie rób tego. Zaimplementuj tryb widoku przy użyciu zupełnie innego elementu, takiego jak <div> albo <span> z atrybutem role o wartości button, a tryb « edycja »  z użyciem elementu  <input>.

Asynchroniczna zmiana trści

W budowie. Zobacz też Live Regions

Nawigacja klawiaturą

Często programiści pomijają obsługę klawiatury podczas tworzenia niestandardowych widżetów. Aby być dostępnym dla wielu użytkowników, wszystkie funkcje aplikacji internetowej lub widżetu powinny być sterowane za pomocą klawiatury, bez potrzeby korzystania z myszy. W praktyce zwykle wiąże się to z konwencjami obsługiwanymi przez podobne widżety na pulpicie, w pełni korzystając z klawiszy Tab, Enter, Spacja i klawiszy strzałek.

Tradycyjnie nawigacja po klawiaturze w sieci została ograniczona do klawisza Tab. Użytkownik naciśnie klawisz Tab, aby skupić się na każdym łączu, przycisku lub formularzu na stronie w liniowej kolejności, używając Shift-Tab, aby nawigować wstecz. Jest to jednowymiarowa forma nawigacji do przodu i do tyłu, jeden element na raz. Na dość gęstych stronach użytkownik klawiatury często musi kilkakrotnie nacisnąć klawisz Tab przed uzyskaniem dostępu do potrzebnej sekcji. Wdrożenie konwencji klawiatury w stylu komputera w Internecie może znacząco przyspieszyć nawigację dla wielu użytkowników.

Oto podsumowanie, jak powinna działać nawigacja klawiaturowa w aplikacji internetowej obsługującej ARIA:

  • Klawisz Tab powinien skupić się na widżecie jako całości. Na przykład, przechodzenie do paska menu powinno skupiać się na pierwszym elemencie menu.
  • Klawisze strzałek powinny umożliwiać wybór lub nawigację w widgecie. Na przykład za pomocą klawiszy strzałek w lewo i w prawo należy ustawić wybór na poprzednie i następne pozycje menu.
  • Gdy widget nie znajduje się w formularzu, klawisze Enter i Spacja powinny wybrać lub aktywować kontrolkę.
  • W formularzu klawisz Spacji powinien wybrać lub aktywować kontrolkę, natomiast klawisz Enter powinien przesłać domyślną akcję formularza.
  • W razie wątpliwości naśladuj standardowe zachowanie pulpitu kontrolki, którą tworzysz.

Tak więc, dla przykładu widżetów zakładki powyżej, użytkownik powinien móc nawigować do kontenera widgetu (<ol> w naszym znaczniku) i wychodzić za pomocą klawiszy Tab i Shift-Tab. Po ustawieniu nawigacji klawiaturą w kontenerze klawisze strzałek powinny umożliwiać użytkownikowi nawigację między kartami (elementy <li>)Konwencje różnią się w zależności od platformy. W systemie Windows następna karta powinna być automatycznie aktywowana, gdy użytkownik naciśnie klawisze strzałek. W systemie Mac OS X użytkownik może nacisnąć klawisz Enter lub klawisz spacji, aby aktywować następną kartę. Szczegółowy samouczek do tworzenia Keyboard-navigable JavaScript widgets opisuje sposób implementacji tego zachowania za pomocą JavaScript.

Aby uzyskać więcej informacji na temat konwencji nawigacyjnych na klawiaturze w stylu komputerowym, należy zapoznać się z obszernym opisem DHTML style guideOpis zawiera przegląd nawigacji klawiaturowej dla każdego typu widżetu obsługiwanego przez ARIA. W3C oferuje również pomocne ARIA Best Practices dokument zawiera nawigację klawiaturową i konwencje skrótów dla różnych widżetów

Zobacz także

Autorzy i etykiety dokumentu

Autorzy tej strony: lukasz-otowski
Ostatnia aktualizacja: lukasz-otowski,