Ustawa o dostępności stron internetowych i aplikacji mobilnych z 4 kwietnia 2019 roku, jest czymś, co każda instytucja publiczna (teatr, muzeum, urząd itp.) musi wziąć pod uwagę, zlecając tworzenie własnej strony internetowej.
Natomiast co dokładnie się w niej zawiera i co to oznacza dla osób tworzących takie strony internetowe oraz aplikacje?
Dokładnie o tym dziś przeczytasz
Dlaczego powstał taki artykuł?
Jako Brave New, mieliśmy sporo okazji, aby tworzyć strony dla instytucji publicznych – świetnym przykładem jest tutaj witryna Archiwum Narodowego w Krakowie – i za każdym razem, spotykaliśmy się z wyzwaniem odwzorowania tego, co znajduje się w ustawie, o której tu rozmawiamy.
Wyzwaniem, które jest o tyle trudne, że wymogi dotyczące dostępności nie są czymś, co wprowadza się raz od linijki, a czymś podobnym do prawa – rzeczą, która ma być jak najbardziej uniwersalna i funkcjonalna dla każdej osoby, biorąc pod uwagę jej różnice względem innych. W przypadku dostępności – różnice poznawcze.
Dlatego wśród naszej firmowej wiedzy, pojawiła się luka do wypełnienia.
Wcześniej wypełniłem ją w ramach wiedzy wewnętrznej, a teraz postanowiłem opublikować w formie dokładnie tego artykułu, abyś Ty też mógł lub mogła z tego skorzystać.
Kilka potencjalnych pytań i odpowiedzi:
Dlaczego pewne punkty zostały pomięte?
Numerki są brane dokładnie ze specyfikacji WCAG, a sama ustawa ich po prostu nie zawiera – chcę, aby artykuł dotyczył jej stricte. Po wszystkie wytyczne WCAG 2.1 (oraz ostatniej, jeszcze nieupowszechnionej wersji 2.2) w dokładniejszej, opisowej formie i z przykładami, antyprzykładami i kryteriami sukcesu, odsyłam Cię do źródeł na końcu artykułu ✨
Co podaję w poszczególnych punktach?
Każdy opis, w skrócie powie Ci, co powinno zostać wdrożone, aby dane kryterium zostało spełnione. Poza tym, wszystkie punkty zostały podlinkowane do dokumentacji WCAG, gdzie znajdziesz wszystkie informacje, przykłady i rekomendacje. Przydadzą Ci się szczególnie, jeśli wdrażasz te rzeczy po raz pierwszy.
Nawet nie próbuję silić się na tak dobre opisywanie konkretnych technik, jak robi to dokumentacja, bo aby zrobić to równie dokładnie, musiałbym ją praktycznie skopiować. No i ten artykuł nie miałby 2 500 słów, a co najmniej 10 razy tyle.
Dlatego najwięcej dowiesz się właśnie w samej dokumentacji, podlinkowanej w źródłach na końcu.
Więc tak – co zawiera w sobie ustawa o dostępności stron internetowych i aplikacji mobilnych?
Poniżej przedstawiam Ci wszystkie zasady. Przeredagowane przeze mnie, aby jak najtreściwiej przekazywały sens konkretnych kryteriów.
Zasada 1: Postrzegalność
1.1: Alternatywa w postaci tekstu
1.1.1: Treść nietekstowa
Wszystkie treści nietekstowe (obrazki, filmy, elementy multimedialne, interaktywne itp.) powinny mieć swoją tekstową alternatywę, która opisuje ich:
- przeznaczenie;
- sposób działania;
- lub pełni dokładnie taką samą funkcję (w przypadku przycisków).
Przydadzą Ci się tutaj szczególnie atrybuty alt, title, aria, ale też same w sobie alternatywy dla multimediów, takie jak na przykład transkrypcje nagrań.
1.2: Dostępność mediów zmiennych w czasie
W skrócie – media oparte na zmysłach, nie mogą opierać się tylko na jednym z nich.
1.2.1: Tylko audio oraz tylko wideo (nagranie)
Elementy audio lub wideo, powinny mieć swoje tekstowe alternatywy lub audiodeskrypcję, przedstawiające dokładnie tę samą treść, co oryginalne multimedium.
1.2.2: Napisy rozszerzone (nagranie)
Wszystkie nagrania, które zawierają w sobie jednocześnie audio i wideo, powinny mieć napisy, zawierające wszystkie istotne dźwięki z konkretnego multimedium (odgłosy, dialogi, itp.).
1.2.3: Audiodeskrypcja lub alternatywa dla mediów (nagranie)
Każdy film, powinien zawierać swoją tekstową lub dźwiękową alternatywę, dostępną dla osoby odwiedzającej naszą stronę.
1.2.5: Audiodeskrypcja (nagranie)
Aby osoby niewidome, mogły w pełni skorzystać z nagrań wideo, te powinny mieć dźwiękową alternatywę, w której zostałyby zawarte słowa i opisy zdarzeń z ekranu.
1.3: Możliwość adaptacji ‑ odpowiednia (zrozumiała) prezentacja zawartości
Każda osoba, powinna się łatwo i intuicyjnie odnaleźć na tworzonej przez nas stronie.
1.3.1: Informacje i relacje
Wszystkie relacje, informacje o strukturze oraz sama treść strony, powinny być dostępne z poziomu czytnika ekranowego lub istnieć w postaci tekstu. Pomogą Ci tu przede wszystkim odpowiednio użyte tagi HTMLa (labele, przyciski, linki itp.) oraz atrybuty aria.
1.3.2: Zrozumiała kolejność
Kolejność elementów w każdych warunkach (np. z wyłączonym JSem lub/i CSSem) musi być zgodna z pierwotnym zamierzeniem.
Musisz uważać z kopiowaniem tych samych elementów oraz zmianą ich kolejności za pomocą CSSa lub JavaScriptu.
1.3.3: Właściwości zmysłowe
Wszystkie elementy, z których użytkownik lub użytkowniczka mogą skorzystać, muszą być zrozumiałe bez informacji o ich wyglądzie (kolorach, foncie, użytych ikonkach, rozmiarach itp.).
Sprowadza się to do zapewnienia zrozumiałego opisu, dostępnego z poziomu czytników ekranowych i innych programów wspierających.
1.3.4: Orientacja – wyświetlanie treści w układzie poziomym, jak i pionowym
Strona wyświetla się poprawnie w orientacji pionowej i poziomej (na telefonach, tabletach, jak i komputerach).
1.3.5: Określenie prawidłowej wartości
Dotyczy to pól formularzy. Powinny one mieć odpowiednio ustalone typy, jak i wartości atrybutu autocomplete=””, aby ich automatyczne wypełnianie zawsze działało prawidłowo.
1.4: Możliwość rozróżnienia ‑ Ułatwienie percepcji treści
Większość stron składa się głównie z tekstu. Dlatego zbrodnią byłoby robić go nieczytelnym!
1.4.1: Użycie koloru
Kolor nie może być jedynym nośnikiem danej informacji, a sama strona musi być zrozumiała bez wyświetlania kolorów.
Dla przykładu – samo czerwone obramowanie wokół błędnie wypełnionego pola w formularzu, nie spełniłoby tego zalecenia.
1.4.2: Kontrola odtwarzania dźwięku
Jeśli na stronie jest jakieś nagranie audio i włącza się automatycznie na dłużej niż 3 sekundy, to musi mieć kontrolki, pozwalające kontrolować głośność, zatrzymać lub wyłączyć nagranie.
1.4.3: Kontrast (minimalny)
Praktycznie wszystkie elementy na stronie muszą mieć kontrast co najmniej na poziomie 4.5:1. Nie dotyczy to dużych tekstów (gdzie minimalny kontrast wynosi 3:1), ozdobników oraz logotypu serwisu.
Aby sprawdzić, jaki kontrast mają elementy na tworzonej przez Ciebie stronie, możesz użyć narzędzi developerskich w Chromie (i przeglądarkach opartych na Chromium) oraz Firefoxie.
1.4.4: Zmiana rozmiaru tekstu
Teksty na stronie można zwiększyć do 200%, bez utraty czytelności i funkcjonalności.
1.4.5: Tekst w postaci grafiki
Użycie tekstu w formie grafii, zamiast prawdziwego tekstu, wpisanego w HTMLa, praktycznie nigdy nie powinno mieć miejsca. Wyjątkiem będzie tu logo oraz teksty, które muszą być w formie grafiki, aby zachować pierwotny sens.
1.4.10: Zawijanie tekstu
Zawartość strony w ramach domyślnej wielkości, jak i po powiększeniu do 400%, nie może przewijać się horyzontalnie (lub odwrotnie – wertykalnie, gdy domyślnym sposobem przewijania danego serwisu jest przewijanie horyzontalne).
1.4.11: Kontrast dla treści niebędących tekstem
Elementy interfejsu i grafiki, muszą zachowywać współczynnik kontrastu, co najmniej 3:1.
Powtórzę się w razie, gdybyś nie przeglądał/a konkretnych punktów po kolei ✨ Aby sprawdzić, jaki kontrast mają elementy na tworzonej przez Ciebie stronie, możesz użyć narzędzi developerskich w Chromie (i przeglądarkach opartych na Chromium) oraz Firefoxie.
1.4.12: Odstępy w tekście
Odstępy między literkami w tekście, przedstawiają się następująco:
- Wysokość linii – co najmniej 1,5 raza większa od rozmiaru fontu;
- Odstęp między akapitami – co najmniej 2 razy większy od rozmiaru fontu;
- Przerwa między literkami – co najmniej 0,12 wielkości fontu;
- Odstęp między wyrazami – co najmniej 0,16 rozmiaru fontu.
1.4.13: Treści spod kursora lub fokusa
Treści, pokazujące się po najechaniu na element lub nadaniu mu focusu (np. tooltipy lub rozwijane pozycje w nawigacji strony), muszą być:
- Możliwe do zamknięcia bez przesuwania kursora lub przenoszenia focusu na inny element (np. za pomocą przycisku esc na klawiaturze). Wyjątkiem będą tu komunikaty o błędach oraz takie treści, które nie przysłaniają innych treści;
- Widoczne po najechaniu na wywołującą je treść oraz po najechaniu na treść wywołaną. Na przykład, gdy najechanie na dane słowo pokazuje dodatkowy tooltip, to ten tooltip powinien on być widoczny też po najechaniu myszką na samego siebie;
- Widoczne cały czas, aż do usunięcia hoveru, zmiany focusu lub zamknięcia dodatkowej informacji w inny sposób (dany wg punktu pierwszego).
Zasada 2: Funkcjonalność
2.1: Dostępność z klawiatury
Korzystanie z klawiatury, powinno być równie proste i przyjemne, jak korzystanie z myszki.
2.1.1: Klawiatura
Cała strona, jest funkcjonalna z poziomu klawiatury, w takim samym stopniu, co z poziomu myszki, gładzika lub innego narzędzia wskazującego.
2.1.2: Brak pułapki na klawiaturę
Jeśli jesteśmy w stanie dostać się w dane miejsce za pomocą klawiatury, to musimy móc również z niego wyjść za pomocą klawiatury.
2.1.4: Jednoliterowe skróty klawiszowe
Jeśli na stronie istnieją skróty klawiszowe, które uruchamia się za pomocą pojedynczego przycisku na klawiaturze, to dany skrót można:
- wyłączyć;
- zmienić
- lub włączyć tylko wtedy, gdy komponent, którego skrót dotyczy, ma na sobie focus.
Jedno z tych trzech musi być prawdziwe.
2.2: Wystarczająca ilość czasu
Powinniśmy móc kontrolować animacje oraz elementy i podstrony wyświetlane z ograniczeniem czasowym.
2.2.1: Możliwość dostosowania czasu
Jeśli dana treść jest ograniczona czasowo i to ograniczenie nie jest istotne od strony funkcjonalności (bo jest to np. czas do końca oferty lub aukcji), to konkretne ograniczenie czasowe powinno być możliwe do wyłączenia, wydłużenia lub dostosowania.
Dodatkowym wyjątkiem są tu limity czasowe, przekraczające 20 godzin.
2.2.2: Wstrzymywanie (pauza), zatrzymywanie, ukrywanie
Wszystkie animacje na stronie (migotanie, przesuwanie lub pojawianie się elementów), które:
- dzieją się automatycznie;
- trwają powyżej 5 sekund;
- uruchamiają się obok innych elementów,
są możliwe do wyłączenia lub ukrycia. Wyjątkiem jest oczywiście sytuacja, gdy dana animacja jest niezbędna do zachowania sensu danej treści.
Podobnie jest z automatyczną aktualizacją elementów. Gdy włącza się automatycznie i dzieje się obok innych treści, użytkownik ma możliwość po prostu ją wyłączyć.
2.3: Ataki padaczki ‑ Migotanie
Dokładne informacje o tym, jak zadbać o osoby cierpiące na padaczkę, korzystające z danej strony.
2.3.1: Trzy błyski lub wartości poniżej progu
Nic na stronie internetowej nie może błyskać częściej, niż 3 razy w ciągu sekundy. Dotyczy to błysków dowolnych oraz czerwonych.
2.4: Możliwość nawigacji
Przenoszenie się między konkretnymi miejscami na stronie, powinno być proste, szybkie i jasne.
2.4.1: Możliwość pominięcia bloków
Na stronie powinny znajdować się tzw. skiplinki:
- Na początku każdej podstrony, prowadzące do głównej zawartości lub zawierające w sobie linki do wszystkich sekcji na stronie;
- Przy elementach powtarzalnych – prowadzące do końca konkretnego elementu.
Dodatkowo konkretne sekcje na stronie powinny być pogrupowane za pomocą na przykład:
- Atrybutów aria;
- Nagłówków na początku każdej z sekcji.
2.4.2: Tytuły stron
Wszystkie podstrony mają tytuły, które pokrótce opowiadają o ich celu i treści (chodzi tutaj o znacznik <title>).
2.4.3: Kolejność fokusu
Kolejność focusu (np. przy użyciu przycisku tab na klawiaturze) powinna odzwierciedlać logiczną kolejność treści na stronie internetowej.
Przyda Ci się tutaj atrybut tabindex, szczególnie w przypadku stron z bardziej zaawansowanym CSSem.
2.4.4: Cel linku (w kontekście)
W największym skrócie można powiedzieć, że tekst każdego linku na stronie, powinien opisywać to, co znajduje się pod danym łączem.
W przypadku gorzej opisanych lub niejasnych linków, na pewno przydadzą Ci się atrybuty aria, szczególnie aria-label i aria-labelledby oraz alty dla elementów nietekstowych.
2.4.5: Wiele sposobów na zlokalizowanie strony
Co najmniej 2 z poniższych sposobów, muszą zostać użyte w celu linkowania do innych miejsc serwisu:
- standardowe linki, użyte w kontekście danego elementu;
- spis treści;
- mapa witryny;
- wyszukiwarka;
- lista linków do innych stron internetowych;
- linki do wszystkich podstron na stronie głównej.
2.4.6: Nagłówki i etykiety
Nagłówki i etykiety (labele) muszą dobrze opisywać treści, których dotyczą.
2.4.7: Widoczny fokus
Focus elementów, podczas nawigacji za pomocą klawiatury, musi być zawsze widoczny.
Jeśli nie wiesz, jak stworzyć efekt focus, który pokazuje się tylko przy nawigacji klawiaturą, to możesz zajrzeć do artykułu na moim blogu: 3 sposoby na focus, widoczny tylko podczas nawigowania klawiaturą.
2.5: Sposoby wprowadzania danych
Trochę o alternatywnych sposobach wprowadzania danych i integracji ze stroną.
2.5.1: Gesty punktowe
Wszystkie elementy, obsługiwane za pomocą gestów (do których używamy kilku palców) lub wymagające przesunięcia palca w konkretny sposób, muszą oferować alternatywny sposób obsługi, do którego wystarczy proste kliknięcie.
Dla przykładu, mapka, którą możemy przybliżyć i oddalić “uszczypnięciem”, mus zawierać na przykład przyciski “+” i “-” pozwalające na zrobienie tego samego.
2.5.2: Anulowanie kliknięcia
Każda akcja, którą możemy wywołać za pomocą prostego, jednopunktowego dotyku, musi być możliwa do przerwania. A jeśli przerwanie nie jest możliwe (bo np. akcja dzieje się momentalnie), to domyślny stan elementu, której ta akcja dotyczyła, musi być możliwy do przywrócenia.
2.5.3: Etykieta w nazwie
Atrybuty, używane dla dostępnego opisywania elementów (np. aria-label i aria-labelledby) powinny zawierać w sobie teksty lub zachowywać sens tekstów, prezentowanych wizualnie (np. w labelach pól formularzy lub nagłówkach).
Dobrą praktyką jest używanie tych samych zdań, dla widocznych etykiet oraz zdań w atrybutach stricte związanych z dostępnością lub zaczynanie tych drugich, tymi pierwszymi. Na przykład wyszukiwarka, opisana labelem “Wyszukaj”, w atrybucie aria może zostać opisana zdaniem “Wyszukaj interesujące Cię treści”.
2.5.4: Aktywowanie ruchem
Jeśli konkretny komponent na stronie, domyślnie reaguje na ruch, to ta reakcja powinna być możliwa do wyłączenia, a sam element możliwy do obsługi też bez wykorzystania ruchu (chyba, że ruch jest zawsze niezbędny dla zachowania funkcjonalności).
Zasada 3: Zrozumiałość
3.1: Możliwość odczytania
Języki powinny być jasno zdefiniowane!
3.1.1: Język strony
Atrybut lang dla elementu <html> musi być poprawnie zdefiniowany, odpowiednio dla języka, w którym wyświetlane są główne treści na stronie.
Dla innych elementów, np. plików PDF, istnieją odpowiadające temu techniki, o których zawsze możesz przeczytać w linku z nagłówka ✨
3.1.2: Język części
Jeśli na stronie istnieją fragmenty w innych językach, niż język ustawiony dla całości, to również muszą zostać odpowiednio zaznaczone (np. atrybutem lang w HTMLu).
3.2: Przewidywalność
Najgorsze, co możemy zrobić użytkownikom i użytkowniczkom (szczególnie tym, których możliwości są ograniczone), to napisać stronę, która jest nieprzewidywalna.
3.2.1: Po oznaczeniu fokusem
Po sfocusowaniu elementu, nie może on się zachować nieoczekiwanie. Na przykład otworzyć nowej karty (bez ostrzeżenia), wysłać formularza lub zmienić zawartości strony.
3.2.2: Podczas wprowadzania danych
Wprowadzanie danych w formularzach nie powinno zmieniać kontekstu (na przykład wysyłać formularza) bez wyraźnego polecenia użytkownika lub użytkowniczki (chyba, że został/a poinformowany/a o tym co się stanie, przed rozpoczęciem korzystania z komponentu).
3.2.3: Konsekwentna nawigacja
Nawigacja nie powinna zmieniać się w obrębie strony (chyba, że użytkownik/czka ma możliwość jej zmiany własnoręcznie).
3.2.4: Konsekwentna identyfikacja
Jeśli na stronie istnieje kilka komponentów, które wykonują taką samą lub podobną akcję, to muszą one mieć spójne (nie oznacza to, że identyczne) nazwy, etykiety i teksty alternatywne.
3.3: Pomoc przy wprowadzaniu informacji
Trochę o formularzach i ich walidacji.
3.3.1: Identyfikacja błędu
Gdy użytkownik/czka błędnie wypełni pole formularza, otrzyma dokładną informację o błędzie oraz o tym, w którym polu znajdują się złe dane.
3.3.2: Etykiety lub instrukcje
Wszystkie formularze, jak i pola tych formularzy są odpowiednio opisane za pomocą instrukcji oraz etykiet.
3.3.3: Sugestie korekty błędów
Jeśli wiadomo, jak użytkownik lub użytkowniczka może poprawić błąd we wpisanych danych, to sugestia takiej poprawy powinna być wyświetlona.
3.3.4: Zapobieganie błędom (kontekst prawny, finansowy, związany z podawaniem danych)
Jeśli dane, które użytkownik/czka wprowadza na stronie, mają charakter prawny, finansowy lub modyfikują jego lub jej dane w konkretnym systemie, to musi istnieć możliwość przywrócenia poprzednich danych lub sprawdzenia ich przed wysłaniem.
Alternatywnie – system, do którego same dane są wprowadzane, może sprawdzić je automatycznie i pozwolić użytkownikowi lub użytkowniczce na poprawki.
Zasada 4: Kompatybilność
4.1: Kompatybilność
A na koniec, 3 ogólne zasady, które mają wymóc na nas pisanie dobrego HTMLa (i bardzo dobrze).
4.1.1: Parsowanie
Ta zasada mówi po prostu o tym, że HTML danej strony, musi być napisany poprawnie. Jego walidacja powinna przebiegać bez błędów, a wszystkie znaczniki mają zostać użyte wg ich przeznaczenia.
4.1.2: Nazwa, rola, wartość
Ogólny punkt, mówiący o tym, że wszystkie elementy interfejsu (przyciski, linki, pola formularzy itp.) powinny być poprawnie opisane za pomocą:
- labeli;
- atrybutów aria-label i aria-labelledby;
- tekstów alternatywnych;
- atrybutów title (np. dla elementów iframe).
4.1.3: Komunikaty o stanie
Jeśli stan aplikacji w jakiś sposób się zmieni (na przykład wypełniany przez użytkownika formularz wyrzuci błędy), to komunikaty o zmianie stanu powinny zostać zamknięte w elementach z atrybutami role. Dzięki temu, gdy dany element pojawi się na stronie, użytkownik korzystający np. z czytnika ekranowego od razu dostanie o nim informację.
Przydatne będą tu atrybuty role=”alert”, role=”log”, role=”status” i inne.
I to będzie już wszystko
Tak oto dotarliśmy do końca – wiesz już teraz, co dokładnie powinno znajdować się na stronie, która ma być dostosowana do ustawy o dostępności stron internetowych i aplikacji mobilnych
Jeśli ten artykuł był dla Ciebie wartościowy lub uważasz, że coś jeszcze powinno zostać w nim zawarte, to koniecznie daj o tym znać.
Źródła niepodlinkowane wcześniej:
- Tekst ustawy
- LepszyWeb.pl
- Web Content Accessibility Guidelines (WCAG) 2.2 – wersja angielska dokumentacji
- Wytyczne dla dostępności treści internetowych (WCAG) 2.1 – wersja polska dokumentacji