Accessibility

Wyrażenie A11y jest skrótem wyrażenia accessibility – liczba “11” oznacza liczbę znaków pomiędzy pierwszą (“a”) oraz ostatnią (“y”) literą. Takich skrótów w świecie frontend-u powstaje obecnie coraz więcej, więc jeżeli zauważysz w przyszłości coś podobnego, będziesz już wiedział skąd on się wziął 🙂

W poprzednich lekcjach tego kursu kilkukrotnie wspominaliśmy już sobie o użytkownikach, którzy mogą przeglądać naszą stronę i posiadać pewnego rodzaju ograniczenia lub być niepełnosprawni. Tworząc stronę, która będzie dostępna publicznie w Internecie, powinniśmy zadbać o to, aby była ona czytelna i łatwa w użyciu dla każdego odwiedzającego.

Podstawowe rodzaje niepełnosprawności, które może posiadać użytkownik naszej strony to np.:

• problemy z ruchem, operowaniem ręki, dłoni, palców,
• problemy psychiczne lub emocjonalne,
• problemy słuchowe i wzrokowe.

Poza tym warto pamiętać, iż niepełnosprawność niekoniecznie musi być trwała, jak np. utrata wzroku czy kończyny. Jeżeli stały bywalec naszej strony złamie rękę, to dobrze by było, aby mógł w dalszym ciągu odwiedzać naszą stronę i swobodnie nawigować po niej bez użycia myszki.

Przygotowanie “dostępnej” strony, poza oczywistymi korzyściami dla osób z ograniczeniami również dla nas, twórców stron, niesie wiele korzyści. Tak przygotowana strona będzie dużo bardziej czytelna, pozwoli nam utrzymać porządek w kodzie (wymuszenie semantyczności), może poprawić ranking strony w wyszukiwarkach oraz przyciągnąć więcej odwiedzających.

Czytniki stron

Najczęściej pojawiającą się technologią wspomagającą przeglądanie stron są czytniki ekranowe. Mają one za zadanie “opowiedzieć” użytkownikowi co znajduje się na stronie, jaką sekcję aktualnie czyta, gdzie zostanie przekierowany po kliknięciu w przycisk itp. Zanim przejdziemy do omawiania tego, w jaki sposób już konkretnie możemy dostosować kod strony pod osoby niepełnosprawne, sprawdźmy jakie najpopularniejsze czytniki obecnie są dostępne na rynku:

• NVDA – obecnie najpopularniejszy darmowy czytnik na systemy Windows,
• JAWS – kolejny popularny czytnik,
• VoiceOver – czytnik dla sprzętu Apple.

Najszybszym i chyba najłatwiejszym sposobem na przetestowanie czytnika na naszej stronie jest skorzystanie z rozszerzenia Chrome – nie musimy wtedy niczego instalować na systemie operacyjnym. Dość popularnym rozszerzeniem jest w tym przypadku Screen Reader. Po jego zainstalowaniu od razu będziemy mogli poczuć, jak wygląda przeglądanie stron przez osobę niewidomą.

Głównym oraz najlepszym sposobem na to, aby czytnik prawidłowo informował użytkownika strony o tym, w jakiej części strony się znajduje, co może przeczytać, gdzie może nawigować, jest stosowanie semantycznych tagów HTML. Za ich pomocą jesteśmy w stanie zagwarantować naprawdę dość dobre wsparcie dla osób niepełnosprawnych i jest to bardzo dobry punkt wyjścia dla dalszych prac, które będą miały za zadanie dalszą optymalizację naszych stron. Jeżeli posiadasz już zainstalowane rozszerzenie wymienione w powyższym przykładzie, spróbuj stworzyć samodzielnie nawigację złożoną tylko z tagów <div> oraz <a> a następnie zrób to samo korzystając z tagów <nav>, <ul>, <li> oraz <a>. Słychać różnicę?

Poza czytnikami stron możemy również spotkać się z innymi narzędziami asystującymi, takimi jak powiększanie ekranu, konwertowanie głosu na tekst, zwiększanie kontrastu strony itp.

Web Content Accessibility Guidelines (WCAG)

Wszystkie wymagania, które stawiane są stronom internetowym w kontekście dostępności zebrane są w jednym dokumencie o nazwie WCAG 2.1 (link prowadzi do polskiej wersji tego dokumentu). To tam znajdziemy wszystkie zalecenia wraz z przykładami dotyczącymi tego, co i w jaki sposób zmienić / wdrożyć na naszej stronie, aby stała się ona dostępna dla osób z ograniczeniami. Krótkie info na temat “dostępności cyfrowej” znajdziemy również na polskich stronach rządowych.

WCAG 2.1 definiuje trzy poziomy dostępności naszej strony. Każdy z tych poziomów określa poziom wsparcia, jakie otrzyma niepełnosprawny użytkownik w momencie, gdy wszystkie wymogi danego poziomu zostaną spełnione przez twórcę strony. Oczywiście im wyższy poziom, tym więcej czeka nas pracy podczas tworzenia strony, ale zdecydowanie warto systematycznie poprawiać ten poziom na naszej stronie.

Poziomy te przedstawiają się następująco:

• Poziom A – minimalny poziom zgodności, zagwarantowany m.in. poprzez odpowiednie używanie alternatywnych tekstów (atrybuty alt), stosowanie semantycznych znaczników HTML, możliwość nawigowania po stronie za pomocą klawiatury (najczęściej przy użyciu klawisza “Tab”) i określenie języka strony (atrybut lang na znaczniku <html>).
• Poziom AA – zalecany poziom zgodności, czyli wszystko to co w przypadku poziomu A, oraz dodatkowo stosowanie odpowiednio wysokiego kontrastu (czyli stosunek koloru tła do koloru tekstu, najczęściej wynoszący tutaj 4,5:1) oraz tworzenie wykorzystanie responsive web design (responsywność).
• Poziom AAA – optymalny (najwyższy) poziom zgodności, czyli zastosowanie wideo z mową migową, wyższy kontrast niż w przypadku poziomu AA oraz używanie bardzo prostych tekstów alternatywnych (zrozumiałych dla osób z edukacją podstawową).

Atrybuty ARIA

Mogą zdarzyć się sytuacje, gdzie nie zawsze będzie możliwość użycia w dobry sposób znaczników semantycznych bądź nie mamy obecnie czasu na to, żeby przepisywać całą stronę, bądź jej dużych fragmentów tylko po to, żeby zastosować tagi semantyczne. W takich sytuacjach może zostawić obecnie użyte tagi i jedynie dodać do nich nowe atrybuty, tzw. atrybuty ARIA. Dzięki tym atrybutom poprawimy semantykę oraz a11y naszej strony. Nic nie stoi na przeszkodzie, aby używać ich również na znacznikach semantycznych i tym samym jeszcze bardziej zwiększać ich czytelność. Atrybutu nie mają żadnego wpływu na wygląd strony.

Atrybuty ARIA dzielimy na te określające role (roles) oraz stan i właściwości (states and properties)

Role

Ta kategoria określa rolę danego elementu (znacznika HTML) w kontekście naszej strony. Tym samym, możemy jawnie określić, iż element jest nawigacją, przyciskiem, polem wyszukiwarki itp. Role ustawiamy za pomocą atrybutu role, np.

<div role="navigation">
  <!-- Elementy nawigacyjne, np. znacniki <a> -->
</div>
<span role="button">Click me</span>

Pełną listę dostępnych ról, których możemy użyć jako wartość atrybutu role, znajdziemy pod tym linkiem: ARIA roles.

States and properties

Stan oraz właściwości pozwalają nam dokładniej opisać to, w jaki sposób może zachować się i w jaki sposób zachował się wybrany element na stronie. Właściwościami w tym przypadku mogą być informacje o tym, że pole formularza jest wymagane bądź jakiś fragment tekstu jest etykietą dla pola tekstowego lub listy rozwijanej.

Z kolei stanem może być informacja o tym, że jakieś pole wyboru jest zaznaczone, wprowadzony tekst jest nieprawidłowy (np. zawiera niedozwolone znaki), bądź jakiś przycisk lub link jest nieaktywny (i stanie się aktywny dopiero w momencie, gdy wszystkie pola formularza zostaną wypełnione – zrealizowanie tego jednak wymaga delikatnej ilości JavaScript).

W tym przypadku mamy już do czynienia z wieloma różnymi atrybutami o różnych możliwych wartościach, a nie z jednym, jak to było w przypadku role:

<div aria-required="true"><!-- Dowolna zawartość --></div>
<div aria-label="Podaj imię"><!-- Dowolna zawartość --></div>
<div aria-disabled="true"><!-- Dowolna zawartość --></div>
<div aria-invalid="true"><!-- Dowolna zawartość --></div>
<div aria-checked="true"><!-- Dowolna zawartość --></div>

Listę dostępnych atrybutów oraz ich wartości znajdziemy na tej stronie: ARIA states and properties.

Atrybuty ARIA są bardzo pomocne przy zwiększaniu dostępności naszej strony, jednak w dalszym ciągu należy pamiętać o tym, aby w pierwszej kolejności korzystać z natywnych / semantycznych elementów, np. w przypadku przycisków unikamy stosowania role i po prostu używamy znacznika <button>:

<!-- Źle 😖 -->
<div role="button">Anuluj</div>

<!-- 🥰🥰🥰 W tym przypadku nie musimy już podawać "role". -->
<button>Anuluj</button>

I co dalej?

Temat dostępności stron jest dość często pomijany podczas tworzenia nowych projektów. Często tłumaczone jest to faktem, iż “z naszej strony na pewno nie będą korzystały osoby niepełnosprawne” bądź wynika z czystej niewiedzy programistów na ten temat. Jak widać z poprzednich rozdziałów, już samo korzystanie z semantycznych znaczników wsparte o podanie języka strony, stosowanie RWD (responsive web design) oraz używanie atrybutów ARIA pozwoli nam osiągnąć dość dobrą dostępność strony bez znacznych nakładów czasowych (wymienione wcześniej rzeczy i tak powinny być wykorzystywane na profesjonalnie tworzonych stronach).

Na temat a11y można by pisać jeszcze naprawdę dużo i podawać kolejne przykłady na to, w jaki sposób poprawiać dostępność. Zdaję sobie jednak sprawę, iż cały czas jesteśmy na etapie nauki tworzenia stron, więc dużą większą uwagę na pewno powinniśmy teraz poświęcić na zagadnienia związane z HTML i CSS, a w szczególności na semantykę oraz RWD. Gdy już będziemy czuli się z tymi tematami bardzo pewnie, możemy wrócić do tematów związanych z accessibility i jeszcze bardziej zgłębiać ten temat w celu tworzenia jeszcze bardziej profesjonalnych stron oraz aplikacji.

🔗 Dodatkowe materiały:

• Accessibility okiem Developera
• What is ARIA?
• A11y Checklist
• Accessibility resources