RGAA 3.2017 – Uwagi techniczne

Obrazy

Kryterium 1.2 [A]

Jeśli obraz jest powiązany z legendą, uwaga techniczna WCAG zaleca podawanie alternatywy obrazu (zob. kryterium 1.10). W takim przypadku kryterium 1.2 nie ma zastosowania.

Atrybut WAI-ARIA role="presentation" nie może być użyty do zadeklarowania obrazu dekoracyjnego zgodnie z zaleceniami zawartymi w specyfikacji, dotyczącymi ograniczeń użytkowania ról WAI-ARIA.

Kryterium 1.3 [A] : atrybut title

Zasada WCAG zabrania używania atrybutu title zamiast atrybutu alt, jednak często przydatne jest użycie atrybutu title do wyświetlenia podpowiedzi ( tooltip) na szczególnie niejasnych obrazach. Jeśli atrybut title jest używany w w taki sposób, treść atrybutu title musi być identyczna z treścią atrybutu alt.

Kryterium 1.3 [A]: znacznik <title> w elementach SVG

Brak obsługi elementu <title> przez technologie wspomagające powoduje trudności w przypadku używania elementu <desc> w celu implementacji krótkiej alternatywy obrazu, jeśli obraz wymaga opisu szczegółowego. W takim przypadku, w celu utworzenia opisu szczegółowego zaleca się wykorzystanie tekstu przyległego lub linku przyległego.

Testy 1.3.9 i 1.3.12 są używane do sprawdzenia, czy implementacja alternatywy jest kompatybilna z dostępnością (na przykład z daną bazą referencyjną).

Kryterium 1.6 [A]

Brak obsługi elementu <title> przez technologie wspomagające powoduje trudności w przypadku używania elementu <desc> w celu implementacji krótkiej alternatywy obrazu, jeśli obraz wymaga opisu szczegółowego. W takim przypadku, w celu utworzenia opisu szczegółowego zaleca się wykorzystanie tekstu przyległego lub linku przyległego.

Jeśli element <desc> jest użyty do implementacji opisu szczegółowego, zaleca się użycie atrybutu aria-label do implementacji krótkiej alternatywy obrazu.

Użycie atrybutu aria-describedby nie jest możliwe do powiązania obrazu z jego opisem szczegółowym z powodu braku wsparcia przez technologie wspomagające.

Powiązany opis szczegółowy może być zaimplementowany przy pomocy znacznika <figcaption>, w tym przypadku kryterium 1.10 powinno być sprawdzone (zwłaszcza użycie <figure> i roli group).

Kryterium 1.8 [AA] i 1.9 [AAA]

Ponieważ tekst na obrazach wektorowych jest tekstem rzeczywistym, kryterium to nie ma zastosowania.

Kryterium 1.10 [A]

Implementacja role="group" dla elementu zagnieżdżonego figure pozwala rozwiązać kwestię braku wsparcia dla elementów figurew technologiach wspomagających. Mimo że zalecana, użycie elementu figcaption w elemencie figure jest opcjonalne. Natomiast użycie elementu figcaption w celu powiązania legendy z obrazem wymaga użycia elementu zagnieżdżonego figure. Odniesienie do powiązanej legendy może być wyrażeniem typu „image 1“ lub podobnym, jeśli to wyrażenie jest podane w legendzie.

Mimo, że jest to zalecane przez HTML5, zasady WCAG zakładają, że title nie może być używany do „etykietowania“ obrazu.

Atrybuty aria-labelledby i aria-describedby nie mogą być aktualnie używane ze względu na brak wsparcia przez technologie wspomagające.

Uwaga: obrazy z legendą muszą ponadto przestrzegać kryterium 1.3 związanego z obrazami przenoszącymi informacje.

Tabele

Kryterium 5.1 [A]

Specyfikacja proponuje wiele metod do powiązania podsumowania z tabelą (tabela powiązania z fragmentem tekstu przez aria-describedby, tabela pogrupowana przy pomocy figure z podsumowaniem w postaci tekstu powiązanego, tabela pogrupowana przez figure z podsumowaniem w elemencie figcaption, podsumowanie w elemencie details w elemencie caption).

Metody te nie mają aktualnie dostatecznego wsparcia.

Kryterium 5.7 [A]

Jeśli atrybut headers jest zaimplementowany w komórce już powiązanej z nagłówkiem (wiersza lub kolumny) przez atrybut scope (z wartością col lub row), technologie wspomagające odtwarzają nagłówki posiadające atrybut headers. Nagłówki powiązane z atrybutem scope są ignorowane.

Skrypty

Kryterium 7.1 [A]

Kryterium 7.1 implementuje pojęcie „kompatybilny z technologiami wspomagającymi” zgodnie z definicją WCAG, a także odwołuje się do API WAI-ARIA w celu udostępnienia komponentu lub funkcjonalności. Prawidłowe użycie API WAI-ARIA jest sprawdzane przy pomocy testów 7.1.3, 7.1.4, 7.1.5 i 7.1.6.

Ważna uwaga: w środowisku HTML5 wiele komponentów może do działania wymagać JavaScript, zatem dostarczenie alternatywy komponentu JavaScript, który nie będzie mógł zostać udostępniony powinno wykorzystywać specjalną dla tego elementu metodę umożliwiającą zastąpienie go dostępną alternatywą (i go uruchomić).

Oznacza to, że wyłączenie JavaScript dla zbioru stron nie jest akceptowalne, chyba, że nie wyklucza użycia innych komponentów.

Kryterium 7.3 [A]

ARIA definiuje, dla pewnej liczby ról przeznaczonych do programowania komponentów interfejsu, zestaw interakcji z klawiatury opartych na klawiszach Esc, Spacja, Tabulator i strzałki kierunkowe, do których można dodać inne interakcje oparte przykładowo na klawiszach page up/page down, home lub end. Dla zapewnienia stopniowego wdrożenia interakcji z klawiatury, specyfikacja ogranicza wymagania do podstawowych klawiszy (Esc, spacja, tabulacja, strzałki kierunkowe), jak zdefiniowano we wzorcach projektowych.

Struktura informacji

Kryterium 9.1 [A]

ARIA pozwala zdefiniować tytuły przy pomocy roli heading i właściwości aria-level (wskazanie poziomu tytułu). Chociaż preferowane jest użycie natywnych elementu tytułu w HTML <hx>, użycie roli WAI-ARIA heading jest kompatybilne z dostępnością.

Mimo, iż specyfikacja HTML5 dopuszcza użycie wyłącznie tytułów poziomu 1 (h1), brak wsparcia przez technologie wspomagające wymaga użycia bardziej adekwatnej hierarchii tytułów.

Kryterium 9.2 [A]

Struktura drzewiasta dokumentu (outline) jest tworzona przez użytkownika przy użyciu znaczników sekcyjnych <nav>, <article>, <section>, <aside>i domyślnych sekcji generowanych przez użycie znacznika <hx> (jeśli znacznik <hx> nie jest pierwszym elementem podrzędnym sekcji).

Znacznik sekcyjny pozwala zdefiniować strukturę i pogrupować treść, części treści lub zbiór treści, które mogą być traktowane jako niezależne od reszty dokumentu.

Obszar nawigacji na stronie lub w rubryce, spis treści lub obszar nawigacji zbioru stron (<nav>), „dodatkowa” treść w stosunku do treści głównej (<aside>), treść główna lub grupy wielu treści, takie jak artykuły (<article> lub <section>), treści poboczne takie jak komentarz, Twitter, strumień RSS (<article> lub <section>) to przykłady treści umieszczanych w sekcjach.

Jeśli chodzi o treści, w odróżnieniu od obszarów nawigacji (<nav>) lub obszarów treści dodatkowych (<aside>), sekcja powinna posiadać, jeśli to niezbędne, obszar nagłówka (<header>) i stopkę sekcji (<footer>).

Pierwszy tytuł <hx>w sekcji to „nazwa” sekcji, która zostanie umieszczona w strukturze dokumentu. Następne tytuły (<hx>) tworzą sekcje domyślne, które będą przedstawione jako struktura drzewiasta treści sekcji.

Ponieważ sekcja może być traktowana w sposób niezależny od reszty strony, struktura drzewiasta utworzona przez sekcje domyślne (<hx>) jest liczona od poziomu 1 przypisanego do pierwszego tytułu sekcji.

Jeśli jest używana, struktura drzewiasta dokumentu może się zatem różnić od struktury drzewiastej treści reprezentowanej przez zbiór tytułów <hx> strony, nawet jeśli obie struktury są podobne.

Drzewo to powinno być zatem reprezentacją struktury dokumentu i powinno być spójne ze strukturą treści wygenerowaną przez użycie znaczników <hx>. Ponieważ strukturę treści wygenerowaną przez znaczniki <hx> można teoretycznie wydedukować na podstawie drzewa dokumentu, specyfikacja HTML5 zaleca używanie wyłącznie tytułów <h1>. Takie użycie jest zabronione, a kryterium 9.1 wymaga użycia spójnej hierarchii tytułów (<hx>).

O ile drzewo dokumentu (pod warunkiem, że jest spójne) może zaproponować użytkownikowi funkcjonalności przeglądania i nawigacji dla niektórych technologii wspierających, wpływa ono na wygenerowaną hierarchię tytułów przez użycie znaczników <hx>, modyfikując wyświetlane tytuły.

Aby umożliwić stopniowe wdrażanie struktury drzewiastej dokumentu i biorąc pod uwagę fakt, że specyfikacja wymaga dysponowania w każdym przypadku, solidną i spójną strukturą treści (znaczniki <hx>), akceptuje się uznanie testu 9.2.2 za niemający zastosowania jeśli nie jest możliwe zapewnienie, że struktura drzewiasta dokumentu jest doskonale spójna. W takim przypadku niezgodność z testem powinna być podana w postaci prostego alertu.

Kryterium 9.3 [A]

Role WAI-ARIA list i listitem mogą wymagać użycia właściwości aria-setsize i aria-posinset w przypadku, gdy cała lista nie jest dostępna przy pomocy DOM wygenerowanego w momencie przeglądania.

Mimo że posiada rolę definition, używaną w kombinacji z właściwością aria-labelledby, WAI-ARIA nie proponuje roli równoważnej liście definicji HTML. Rola definition nie może być zatem użyta jako odpowiednik listy definicji HTML dl.

Role tree, tablist, menu, combobox i listbox i nie odpowiadają liście HTML ul lub ol.

Referencje: The Role Model, List Role oraz The role model - ARIA SETSIZE.

Prezentacja informacji

Kryterium 10.7 [A]

WCAG proponuje wiele technik mających na celu zwiększenie widoczności fokusa:

C15: Using CSS to change the presentation of a user interface component when it receives focus;

G195: Using an author-supplied, highly visible focus indicator;

SCR31: Using script to change the background color or border of the element with focus.

Mimo, że techniki te dają użytkownikowi wymierne korzyści, nie są obowiązkowo wymagane przez RGAA ze względu na ich silny wpływ na design i ewentualne interakcje z narzędziami podmiotów trzecich (wtyczka lub wskazanie przeglądarek). W każdym razie, powinny być one proponowane przez mechanizm personalizacji.

Ważna uwaga: nawet jeśli te techniki zostaną użyte, nie są w stanie zagwarantować, że wizualne wskazanie fokusa (właściwość outline) nie zostanie osłabione lub usunięte. W efekcie outline kontrolowany i stosowany przez przeglądarkę wydaje się być jedynym wystarczająco dobrym rozwiązaniem, ponieważ nie zależy od autora.

Kryterium 10.13 [A]

WAI-ARIA proponuje właściwość aria-hidden (true lub false), która pozwala zatrzymać odtwarzanie treści w technologiach wspomagających, bez wpływu na widoczność w aplikacjach klienckich: treść z aria-hidden="true" nie będzie wokalizowana, ale pozostanie widoczna.

Oprócz przypadków, gdy treść kontrolowana przez aria-hidden nie ma być odtwarzana przez technologie wspomagające, wartość atrybutu aria-hidden powinna być spójna z wyświetlonym lub ukrytym statusem treści na ekranie.

Specyfikacja HTML5 proponuje atrybut hidden, który uniemożliwia udostępnienie (gdy atrybut hidden jest obecny) treści w wygenerowanym DOM (w podobny sposób do type="hidden" dla kontroli formularza).

Możliwe są sytuacje, gdy treść kontrolowana przez hidden lub aria-hidden ma chwilowo status niezgodny ze statusem wyświetlonym lub ukrytym, na przykład gdy chce się udostępnić element, ale jego wyświetlanie na ekranie zależy od późniejszej czynności. W takim przypadku, należy uwzględnić stan końcowy treści.

Formularze

Kryterium 11.11 [AA]

Niektóre typy formularzy HTML5 proponują komunikaty wspomagające wprowadzanie automatyczne, na przykład url i email wyświetlają komunikat typu „proszę wprowadzić poprawny adres e-mail“ w przypadku, gdy wprowadzony adres e-mail nie odpowiada oczekiwanemu formatowi. Komunikaty można spersonalizować przy pomocy API Constraint Validation, które pozwala spersonalizować komunikaty błędów i zatwierdzić kryteria. Jednak wsparcie dla tego API nie jest jeszcze stabilne. Typ pattern, który pozwala przeprowadzić automatycznie kontrolę formatu (przy pomocy wyrażeń regularnych), wyświetla również komunikat o pomocy, który można spersonalizować przy pomocy atrybutu title, to narzędzie zatwierdza kryterium.

Referencja: WHATWG - 4.10.21.3 The constraint validation API.

Nawigacja

Kryterium 12.10 [A]

WAI-ARIA proponuje role pozwalające wskazać główne strefy (obszary) dokumentu. Role te są bardzo korzystne dla użytkowników czytników ekranowych, a także dla użytkowników wykonujących nawigację z klawiatury, którzy mogą w ten sposób korzystać z funkcji szybkiej nawigacji po strukturze dokumentu. O ile większość czytników ekranowych udostępnia swoje funkcjonalności, przeglądarki nie zaproponowały jeszcze funkcjonalności przeznaczonej dla użytkowników, którzy nie mogą używać myszy. Zastosowanie linków pomijających jest zatem wymagane.