Wszystkie 49 wymagań dostępności wyjaśnionych po ludzku
Załącznik do ustawy o dostępności cyfrowej oraz norma EN 301 549 wymieniają 49 wymagań. Brzmią jak spis techniczny, ale sprowadzają się do czterech pytań o Twój serwis. Poniżej odpowiadamy na każde z nich językiem, którego użyłby ktoś, kto tłumaczy to na spotkaniu, a nie cytuje dokument.
Grupa pierwsza. Czy da się to odebrać
Chodzi o to, żeby treść docierała do odbiorcy tym zmysłem, którym może ją odebrać.
Wszystko, co nie jest tekstem, musi mieć tekstowy odpowiednik. Obraz potrzebuje opisu, nagranie dźwiękowe transkrypcji, film napisów, a film przekazujący treść samym obrazem także audiodeskrypcji. Wykres bez opisu jest dla osoby niewidomej pustym miejscem.
Struktura treści musi siedzieć w kodzie, nie tylko w wyglądzie. Nagłówek ma być nagłówkiem, lista listą, a tabela mieć nagłówki kolumn. Pogrubiony akapit udający nagłówek wygląda dobrze i nie działa. Kolejność w kodzie ma odpowiadać kolejności na ekranie, bo czytnik czyta kod, nie układ graficzny.
Instrukcje nie mogą opierać się na wyglądzie. „Kliknij zielony przycisk po prawej” nie działa dla osoby niewidomej ani dla osoby nierozróżniającej kolorów. To samo dotyczy informacji przekazywanej samym kolorem: czerwona ramka wokół pola nie jest komunikatem o błędzie, dopóki nie towarzyszy jej tekst.
Treść musi dać się zobaczyć przy słabszym wzroku. Kontrast tekstu co najmniej 4,5 do 1, elementów interfejsu 3 do 1. Powiększenie do 200 procent bez utraty treści. Działanie na ekranie o szerokości 320 pikseli bez przewijania w bok. Czytelność po zwiększeniu odstępów między wierszami i literami. Tekst ma być tekstem, a nie napisem na obrazku, bo obrazek nie da się powiększyć bez rozmycia.
Wreszcie: dźwięk, który sam się włącza i gra dłużej niż trzy sekundy, musi dać się wyłączyć. Osoba korzystająca z czytnika ekranu słyszy wtedy dwie rzeczy naraz i nie rozumie żadnej.
Grupa druga. Czy da się tego użyć
Chodzi o to, żeby każdy mógł obsłużyć serwis, niezależnie od tego, czym się posługuje.
Fundament to klawiatura. Każda funkcja musi być dostępna bez myszy i z każdego miejsca trzeba dać się wydostać. Element z fokusem musi być widoczny, a kolejność przechodzenia logiczna. To jest test, który zajmuje dwie minuty: odłóż mysz i spróbuj złożyć zamówienie.
Użytkownik musi panować nad czasem i ruchem. Limity czasu do przedłużenia, animacje do zatrzymania, żadnego migotania częstszego niż trzy razy na sekundę. Skróty klawiszowe oparte na pojedynczej literze muszą dać się wyłączyć, bo przeszkadzają osobom sterującym głosem.
Nawigacja ma pozwalać się poruszać. Link pomijający powtarzalne menu, unikalne tytuły podstron, nagłówki opisujące sekcje, linki, z których wynika, dokąd prowadzą, i co najmniej dwie drogi dotarcia do każdej podstrony.
Ostatnia część dotyczy sposobów wskazywania. Funkcja oparta na geście wielopunktowym albo na potrząśnięciu telefonem musi mieć prostą alternatywę. Kliknięcie ma dać się anulować przez przesunięcie palca poza przycisk. A nazwa elementu odczytywana przez technologie ma zawierać to, co widać na ekranie, żeby sterowanie głosem rozumiało polecenie wypowiedziane zgodnie z napisem.
Grupa trzecia. Czy da się to zrozumieć
Chodzi o przewidywalność: użytkownik ma wiedzieć, co się stanie, zanim to zrobi.
Język strony musi być zadeklarowany w kodzie, a fragmenty obcojęzyczne oznaczone. Bez tego syntezator mowy czyta polski tekst po angielsku i wychodzi bełkot. To jedna linijka kodu.
Serwis ma zachowywać się przewidywalnie. Kliknięcie w pole nie może przenosić na inną stronę, zmiana ustawienia nie może samoczynnie wysyłać formularza, a menu ma wyglądać tak samo na każdej podstronie. Element o tej samej funkcji ma nazywać się wszędzie tak samo.
Formularze to miejsce, w którym najczęściej urywa się sprzedaż. Każde pole potrzebuje trwałej etykiety, a nie znikającego tekstu w środku. Błąd musi być opisany słowami, wskazywać konkretne pole i podpowiadać, jak go poprawić. W sprawach o skutkach finansowych albo prawnych użytkownik musi móc sprawdzić i poprawić dane przed zatwierdzeniem.
Grupa czwarta. Czy współpracuje z technologiami wspomagającymi
Najkrótsza grupa i najbardziej techniczna. Kod ma być poprawny składniowo, bez powtórzonych identyfikatorów i błędnie zagnieżdżonych znaczników, bo na nim opierają się czytniki ekranu.
Każdy element interfejsu musi przekazywać trzy rzeczy: czym jest, jak działa i w jakim jest stanie. Zwykły przycisk robi to sam. Element zbudowany z bloku i skryptu wymaga dopisania tego ręcznie i to tu powstaje większość błędów.
Komunikaty pojawiające się bez przeładowania strony, na przykład potwierdzenie dodania do koszyka, muszą być ogłaszane czytnikom ekranu. Inaczej osoba niewidoma klika i nie wie, czy cokolwiek się stało.
Jak z tego zrobić ocenę zgodności
Ustawa wymaga przeprowadzenia oceny, a nie odhaczenia listy. W praktyce oznacza to przejście przez wszystkie 49 wymagań, ustalenie, które są spełnione, które częściowo, a które nie, i zapisanie tego wraz z planem usunięcia barier.
Część odpowiedzi da się ustalić automatycznie, bo są mierzalne: kontrast, brakujące opisy obrazów, powtórzone identyfikatory, zachowanie przy zwiększonych odstępach. Reszta wymaga człowieka, bo dotyczy sensu, a nie liczb: czy opis obrazu faktycznie oddaje jego treść, czy kolejność fokusu ma sens, czy komunikat o błędzie da się zrozumieć. Dlatego nasz automatyczny audyt zawsze wymienia, czego nie sprawdził.
Jeżeli chcesz przejść przez to punkt po punkcie, kreator dokumentacji prowadzi przez wszystkie 49 wymagań w czterech krokach, po jednym na każdą z opisanych wyżej grup.