A11Y: podstawowe pojęcia

Kiedy mówimy o dostępności stron internetowych, trafiamy na kilka istotnych skrótów. Każdy frontowy programista kojarzy pojęcia “WCAG”, “ARIA”, jednak nie zawsze potrafi je poprawnie rozszyfrować. W tym artykule chciałabym uporządkować znaczenia najważniejszych skrótów z dziedziny dostępności i pokazać ich miejsce w ekosystemie a11y.


DOSTĘPNOŚĆ

Zacznijmy od sedna tematu – czym jest dostępność stron internetowych? Najogólniej mówiąc to wiedza dotycząca tworzenia stron internetowych, która umożliwia korzystanie z nich przez jak największą grupę osób, niezależnie od wieku, niepełnosprawności, sprzętu, czy oprogramowania.

Kiedy myślimy o dostępnych stronach, często mamy w głowie obrazek osób niewidomych. Albo głuchych. I dobrze, jednak to zaledwie ułamek grupy ludzi, którzy mogą mieć problemy ze standardowym sposobem korzystania ze stron internetowych. Strona dostępna powinna być też użyteczna dla ludzi niedowidzących, z dysfunkcjami wzroku, dla ludzi słabosłyszących, z zaburzeniami widzenia barw, dyslektyków, ludzi z niepełnosprawnością fizyczną rąk lub niepełnosprawnością intelektualną. Mało tego! Zasady dostępności uwzględniają też osoby starsze lub korzystające ze starych typów komputerów, a także urządzeń mobilnych. Każda grupa ludzi, która potencjalnie może być narażona na tzw. wykluczenie cyfrowe – powinna zostać uwzględniona podczas projektowania oraz budowy dostępnych stron internetowych.


W3C

Konsorcjum W3C (World Wide Web Consortium) to organizacja ustanawiająca standardy pisania i przesyłu stron WWW. Została założona w 1994 r. przez Tima Berners-Lee – autora pierwszej przeglądarki internetowej i serwera WWW.

W konsorcjum działają grupy tematyczne zajmujące się różnymi zagadnieniami. Jedną z grup tematycznych jest WAI.


WAI

WAI (Web Accessibility Initiative) to wydzielona grupa tematyczna W3C, która przygotowuje wytyczne dotyczące szeroko pojętej dostępności. Najważniejsze wskazówki zawarte są w dokumentacjach określanych jako:

  • WCAG 2.0 (Web Content Accessibility Guidelines)
    zbiór zasad projektowania dostępnych stron, dla twórców, projektantów i redaktorów stron www
  • ATAG 2.0 (Authoring Tool Accessibility Guidelines)
    wytyczne dla twórców oprogramowania stron, narzędzi służących do tworzenia i publikacji treści na stronach www (np. edytory HTML, systemy CMS).
  • UAAG 2.0 (User Agent Accessibility Guidelines)
    zbiór reguł dla twórców aplikacji klienckich (np. przeglądarki internetowe, odtwarzacze multimedialne czy technologie asystujące).

Zapraszam na stronę internetową WAI, pełną dokumentacji, przewodników, wskazówek.

Nas, frontendowców, najbardziej interesuje pierwszy dokument – WCAG 2.0.


WCAG 

WCAG (Web Content Accesibility Guidelines) to dokument opisujący standard dostępności treści internetowych. Wersja angielska, polska.

Specyfikacja WCAG 2.0 ma ściśle określoną strukturę. Całość wytycznych została podzielona
na 4 główne zasady:

  • PERCEPCJA – dotyczy zapewnienia dostępu do informacji za pośrednictwem co najmniej
    jednego ze zmysłów użytkownika,
  • FUNKCJONALNOŚĆ – komponenty interfejsu (zwłaszcza nawigacja) muszą być funkcjonalne dla wszystkich użytkowników (powinny pozwalać na interakcję),
  • ZROZUMIAŁOŚĆ – wskazuje, że poza dostępną i funkcjonalną formą strony, również czytelność i zrozumiałość interfejsu oraz samej treści jest niezbędna,
  • RZETELNOŚĆ – treść musi być wystarczająco rzetelna, aby mogła być poprawnie interpretowana przez wielu różnych klientów użytkownika, włączając technologie asystujące.

Cała specyfikacja WCAG 2.0 została ponadto podzielona na trzy poziomy dostępności:

  • A – wymóg konieczny, minimalny,
  • AA – wymóg rekomendowany, średni,
  • AAA – wymóg możliwy, maksymalny.

Obowiązującą od 2008r. wersją WCAG jest wersja 2.0. Ale uwaga – dokumentacja (Techniques for WCAG 2.0 oraz Understanding WCAG 2.0) i tak jest aktualizowana mniej więcej raz do roku “w celu odzwierciedlenia zmian technologicznych”. Ustandaryzowanie wersji WCAG 2.1 planowane jest na rok 2018. Oczywiście WCAG 2.1 będzie wstecznie kompatybilne (strony spełniające wymagania wersji 2.1, będą jednocześnie spełniać wymagania wersji 2.0).

Nie będę opisywać tutaj wszystkich zasad dostępności. Nikomu nie chciałoby się czytać tak długiego tekstu. Może kiedyś opiszę w serii artykułów podstawowe wytyczne budowania dostępnych stron. Tymczasem zostawiam Was z trzema kluczowymi pozycjami dokumentacji WCAG 2.0:


WAI-ARIA

WAI-ARIA (WAI Accessible Rich Internet Applications) – dokumentacja stworzona przez WAI; zestaw konkretnych narzędzi, których stosowanie ma na celu poprawę dostępności aplikacji internetowych przez stworzenie dodatkowej warstwy niosącej informacje istotne dla technologii wspomagających.

WAI-ARIA definiuje zestaw atrybutów dodawanych do znaczników HTML, które wzbogacają go o semantykę i różnego rodzaju metadane, pozwalając na lepsze zrozumienie zawartości. Atrybuty ARIA nadają semantyczne znaczenie niesemantycznym elementom HTML, bądź też zmieniają semantyczne znaczenie elementów, które zostały “przerobione” przy użyciu JavaScript na komponenty służące do innych celów niż jest to opisane w dokumentacji HTML. Dzięki nim stosowne, dodatkowe informacje są przekazywane technologiom asystującym.

Od 2014 roku WAI-ARIA znajduje się w oficjalnej specyfikacji WCAG 2.0 jako jedna z technik wspierających dostępność.

Wsparcie dla WAI-ARIA jest zróżnicowane, ale obecnie ani przeglądarki, ani technologie wspomagające nie wspierają tej specyfikacji w 100%. Mimo to stosowanie atrybutów WAI-ARIA w kodzie jest zalecane. Jednocześnie, jeśli to możliwe, należy używać natywnych semantycznych znaczników HTML zamiast stosowania atrybutów ARIA.

Elementy WAI-ARIA dodane do kodu HTML nie powodują żadnych zmian w sposobie wyświetlania się strony. Te, których obsługa nie jest zaimplementowana, są ignorowane przez parser.

Atrybuty WAI-ARIA można podzielić na:

  • role – przekazują informacje do aplikacji asystujących, że opisany element jest czymś innym niż wynika to z jego znacznika. Generalnie, jeśli nie ma uzasadnionej potrzeby, nie należy zmieniać natywnego znaczenia znaczników HTML. Role stosujemy najczęściej, kiedy HTML nie posiada odpowiednika dla danej roli.
  • właściwości – określają cechy lub dodatkowe znaczenia danego elementu, które nie są dostępne w standardzie HTML. Posiadają prefix aria-, ich wartości są różne.
  • statusy – pozwalają określić jaki jest aktualny stan elementu. Posiadają prefix aria-, ich wartości to “true” albo “false”.

Pojęcia polecane przez Was! 

Samolubna dostępność (selfish accessibility)

od Comandeer

Tak jak Kolega wspomniał w komentarzu, to “projektowanie dla siebie z przyszłości, gdy już będziemy mniej sprawni niż obecnie”. Często nie czujemy potrzeby tworzenia dostępnych stron. Pewnie sami jesteśmy zdrowi. Pewnie nasze najbliższe otoczenie też nie ma problemu z poruszaniem się po Internecie. Nie rozumiemy, jak ważne są dostępne strony internetowe. Czasem jednak nadchodzi ten moment, kiedy uświadamiamy sobie, że problem dostępności może dotyczyć także nas – dziś, jutro, za rok, za 50 lat. Nieważne kiedy. Istotne, że to będzie NASZ problem. Jeśli to myślenie motywuje nas do projektowania strong zgodnych z WCAG – mamy do czynienia z samolubną dostępnością.

Adrian Roselli o selfish accessiblity. Więcej na temat samolubnej dostępności możesz także przeczytać u Comandeer.

Projektowanie inkluzywne (inclusive design)

od Comandeer

To pojęcie oznacza tworzenie treści użytecznych dla jak największej grupy osób, z naciskiem na etap projektowania tych treści. Termin projektowania inkluzywnego można analizować w kontekście stron internetowych, ale też np. architektury, czy wzornictwa.

Dla nas, ludzi tworzących Internet, ważny jest jeden wniosek – nie zostawiajmy kwestii WCAG developerom. O dostępności powinny myśleć wszystkie zespoły zaangażowane w tworzenie finalnego produktu: od projektantów, przez redaktorów, developerów, managerów, konsultantów, aż po testerów. I każdą jednostkę pomiędzy nimi. Idea projektowania inkluzywnego zaczyna się od ciekawości – jak widzą dany produkt użytkownicy inni niż ja? Jak z niego korzystają? Jak możliwości technologiczne, językowe, poznawcze, fizyczne pozwalają im na wygodne poruszanie się po stronie internetowej? Czy jest ona dla nich w pełni funkcjonalna?

Więcej na temat designu inkluzywnego możesz przeczytać u Comandeer.


To miał być krótki tekst na 3 minuty czytania. Chyba nie do końca to się udało. Temat dostępności jest złożonym zagadnieniem, z jakiejkolwiek strony by go nie ugryźć.

Kolejny post z tematu a11y najprawdopodobniej będzie dotyczył narzędzi, dzięki którym możemy testować dostępność stron internetowych.

 

Źródła: KLIK!KLIK!KLIK!KLIK!.

Wszelakie standardy oraz drafty dotyczące dostępności znajdziecie TUTAJ.

 

Artykuły, które mogą Ci się spodobać...

Wpisz hasło, którego szukasz i naciśnij ENTER, aby je wyszukać. Naciśnij ESC, aby anulować.

Dawaj na górę