Dostępne wzorce interfejsu: WCAG, WAI-ARIA i APG

Kto szuka „WCAG combobox” albo „WCAG tabs”, trafia do trzech różnych dokumentów W3C, które odpowiadają na różne pytania. Ta seria omawia każdy typowy wzorzec interfejsu sklepu internetowego: do czego służy, jakie kryteria WCAG go dotyczą, krótki poprawny przykład HTML, oczekiwaną obsługę klawiaturą oraz to, co kontrola automatyczna może, a czego nie może znaleźć. Ta strona wyjaśnia, jak dokumenty się uzupełniają, i zawiera listę wszystkich wzorców.

To wskazówki techniczne, a nie porada prawna.

WCAG, WAI-ARIA i ARIA Authoring Practices

WCAG nie wymienia z nazwy ani jednego widżetu. Mówi na przykład, że każda kontrolka musi udostępniać nazwę, rolę i stan (4.1.2), że wszystko musi działać z klawiatury (2.1.1), że fokus musi być widoczny (2.4.7) i że struktura musi być zapisana w kodzie, a nie tylko w układzie (1.3.1). Natywny HTML daje większość tego za darmo. Gdy budują Państwo coś, czego HTML nie ma – zakładki, combobox z podpowiedziami, karuzelę – WAI-ARIA pozwala to opisać, a APG mówi, jakiego zachowania oczekują użytkownicy technologii wspomagających.

W3C opisuje WAI-ARIA jako sposób na udostępnienie „dynamicznych treści i zaawansowanych kontrolek interfejsu”, a APG jako materiał towarzyszący, który „zaleca podejścia pomagające twórcom aplikacji internetowych” budować dostępne widżety. APG nie jest wymogiem zgodności: WCAG można spełnić innym, dobrze przetestowanym rozwiązaniem. Jego wstęp mówi wprost, że testy z technologiami wspomagającymi są „niezbędne przed użyciem kodu z tego przewodnika na produkcji”.

Najpierw natywny HTML

Nota W3C Using ARIA ujęła to jako pierwszą zasadę używania ARIA: jeśli można użyć natywnego elementu lub atrybutu HTML, który ma już wbudowaną potrzebną semantykę i zachowanie, należy go użyć zamiast przerabiać inny element i dodawać ARIA. Pozostałe zasady: nie zmieniać natywnej semantyki, chyba że to naprawdę konieczne; wszystkie interaktywne kontrolki ARIA muszą działać z klawiatury; nigdy nie dodawać role="presentation" ani aria-hidden="true" do elementu, który może otrzymać fokus. (Ta nota jest dziś opublikowana jako porzucony szkic i odsyła do APG po dalsze wskazówki, ale jej zasady pozostają wspólną podstawą).

APG mówi to samo własnymi słowami: „Brak ARIA jest lepszy niż zła ARIA” oraz „rola to obietnica”. Dodanie role="button" do div obiecuje przycisk, ale „role ARIA nie sprawiają, że przeglądarka zapewnia obsługę klawiatury czy wygląd” – trzeba samodzielnie sprawić, by element przyjmował fokus i reagował na Enter i Spację.

<!-- Natywnie: nazwa, rola, fokus i klawiatura za darmo -->
<button type="button">Dodaj do koszyka</button>

<!-- Odtworzone ręcznie: każdy element trzeba dodać samemu i często się o nim zapomina -->
<div role="button" tabindex="0" onclick="add()" onkeydown="addOnEnterOrSpace(event)">Dodaj do koszyka</div>

Wzorce w tej serii

Podstawowe kontrolki

• Przycisk czy link – przyciski coś robią, linki gdzieś prowadzą
• Linki otwierane w nowej karcie – kiedy tak robić i jak uprzedzić
• Nieaktywne przyciski – disabled a aria-disabled, kontrast i wyjaśnienia
• Przyciski opcji i pola wyboru – etykiety, grupy i własne style

Okna wyskakujące i nakładki

• Lista rozwijana, select i combobox – najpierw natywny select, potem combobox z APG
• Modalne okno dialogowe – fokus do środka, uwięziony w oknie, z powrotem
• Podpowiedź (tooltip) – WCAG 1.4.13 i dlaczego wzorzec APG to nadal szkic

Nawigacja i struktura

• Menu nawigacyjne – dlaczego APG zaleca dla stron nawigację typu disclosure, a nie menubar
• Okruszki (breadcrumbs) – opisany element nav i aria-current="page"
• Zakładki – tablist, strzałki i automatyczna aktywacja
• Akordeon – nagłówki z przyciskami albo details i summary
• Tabela danych – prawdziwe znaczniki table, nagłówki i podpis
• Karuzela – przycisk pauzy, opisane slajdy, bez niespodziewanego przewijania

Formularze

• Walidacja formularzy i komunikaty o błędach – błędy tekstem, powiązane z polem, odczytywane

Co kontrola automatyczna znajduje we wzorcach

Nasze kontrole uruchamiają axe-core w prawdziwej przeglądarce na stronie w stanie po załadowaniu. W przypadku wzorców oznacza to, że niezawodnie znajdują problemy strukturalne: przyciski i linki bez nazwy, pola formularzy bez etykiety, nieznane role, atrybuty ARIA niedozwolone dla danej roli lub wskazujące nieistniejący identyfikator, tab poza tablist, elementy przyjmujące fokus ukryte przez aria-hidden. Każde znalezisko prowadzi do swojej karty w bibliotece reguł.

Nie znajdują problemów behawioralnych: czy strzałki przenoszą między zakładkami, czy fokus wchodzi do okna dialogowego i potem wraca, czy aria-expanded zmienia się po otwarciu menu, czy karuzelę można wstrzymać. Treść ukryta po załadowaniu strony, np. zamknięte okno dialogowe, w ogóle nie jest testowana; rozszerzenie przeglądarki sprawdza stronę w stanie, który pokazuje Państwa przeglądarka, więc można najpierw otworzyć okno. Część z klawiaturą i czytnikiem ekranu warto zaplanować zgodnie z poradnikiem jak testować WCAG.

Proszę zacząć od darmowej kontroli jednej strony. To automatyczna kontrola, a nie pełny audyt.

Najczęstsze pytania

Czym różni się WCAG od WAI-ARIA?

WCAG mówi, jaki ma być wynik, np. że każda kontrolka udostępnia nazwę, rolę i stan (4.1.2). WAI-ARIA to specyfikacja W3C ról, stanów i właściwości, która jest jednym ze sposobów osiągnięcia tego wyniku, gdy natywny HTML nie wystarcza.

Czy WCAG wymaga ARIA?

Nie. WCAG jest neutralne technologicznie. Natywne elementy HTML, takie jak button, a, input, select i table, zwykle spełniają kryteria bez żadnej ARIA. ARIA jest potrzebna przy własnych widżetach, których HTML nie oferuje, np. zakładkach.

Co to jest ARIA Authoring Practices Guide (APG)?

Materiał W3C WAI opisujący, jak powinny działać typowe widżety: jakich ról i stanów używają i jakie klawisze obsługują. To wskazówki, a nie wymóg WCAG, a W3C prosi, by przed użyciem na produkcji przetestować przykłady z technologiami wspomagającymi.

Jaka jest pierwsza zasada ARIA?

Jeśli natywny element lub atrybut HTML ma już potrzebną semantykę i zachowanie, należy go użyć zamiast dodawać ARIA do innego elementu. Prawdziwy przycisk jest lepszy niż div z rolą button.

Czy kontrola automatyczna może przetestować wzorce interfejsu?

Częściowo. Znajduje brakujące nazwy, nieprawidłowe role i atrybuty ARIA oraz błędne role nadrzędne i podrzędne. Nie oceni, czy działają strzałki, czy fokus przesuwa się poprawnie i czy stany aktualizują się podczas korzystania z widżetu.

Źródła

• W3C WAI, WAI-ARIA overview: https://www.w3.org/WAI/standards-guidelines/aria/
• W3C WAI, ARIA Authoring Practices Guide, Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
• W3C WAI, APG patterns: https://www.w3.org/WAI/ARIA/apg/patterns/
• W3C, Using ARIA (discontinued draft, rules of ARIA use): https://www.w3.org/TR/using-aria/