Na stronach internetowych instytucji publicznych często można znaleźć panel zawierający przyciski zmiany kontrastu, zwiększania i zmniejszania tekstu, podkreślania linków albo przełączania strony w tryb czarno-biały. Obecność takich kontrolek bywa traktowana jako podstawowy dowód dostępności cyfrowej.
W rzeczywistości standard WCAG nie wymaga umieszczania na stronie osobnych przycisków do powiększania tekstu lub zmiany kolorystyki. Wymaga natomiast, aby treść miała odpowiedni kontrast, mogła zostać powiększona za pomocą narzędzi użytkownika i nadal pozostawała czytelna oraz funkcjonalna.
To istotna różnica. Dostępność nie polega na dodaniu panelu, który próbuje zmieniać źle przygotowaną stronę. Powinna być cechą podstawowej wersji serwisu.
Jeżeli tekst ma prawidłowy kontrast, układ dostosowuje się do powiększenia, a strona respektuje ustawienia przeglądarki i systemu operacyjnego, dodatkowe kontrolki nie są potrzebne do spełnienia wymagań dostępności.
WCAG określa rezultat, a nie obowiązkowy zestaw przycisków
WCAG opisuje kryteria sukcesu, które powinny zostać spełnione przez treści i funkcje serwisu. Nie narzuca jednego wyglądu strony ani konkretnego zestawu narzędzi umieszczonych w nagłówku.
Wymagania dotyczą między innymi minimalnego kontrastu tekstu, możliwości powiększenia treści, poprawnego zawijania układu, widocznego fokusu oraz możliwości obsługi interaktywnych elementów klawiaturą.
Strona może spełniać te wymagania bez własnego panelu dostępności. Użytkownik powinien korzystać ze standardowych funkcji przeglądarki, systemu operacyjnego i technologii wspomagających.
W3C wyraźnie zaznacza również, że opublikowane techniki są przykładami sposobów spełniania WCAG, a nie obowiązkowymi rozwiązaniami. Serwis może spełniać wymagania inną metodą, jeżeli osiąga wymagany rezultat.
Nie można więc stwierdzić, że strona jest niedostępna tylko dlatego, że nie posiada ikon oznaczonych literami „A”, „A+” i „A++”.
Użytkownik ma już narzędzia do powiększania strony
Współczesne przeglądarki pozwalają powiększać całą stronę za pomocą menu, skrótów klawiaturowych lub gestów. Systemy operacyjne oferują powiększenie ekranu, zmianę wielkości tekstu i inne ustawienia związane z widzeniem.
Osoby słabowidzące mogą również korzystać ze specjalistycznego oprogramowania powiększającego. Narzędzia te działają nie tylko w jednym serwisie, lecz w całym środowisku użytkownika.
Kryterium WCAG dotyczące zmiany rozmiaru tekstu wymaga, aby treść można było powiększyć do 200 procent bez utraty informacji lub funkcjonalności. W3C wskazuje, że warunek może zostać spełniony przy użyciu mechanizmu skalowania obsługiwanego przez przeglądarkę.
Nie oznacza to konieczności tworzenia własnego mechanizmu po stronie strony internetowej. Obowiązkiem autora jest przygotowanie serwisu tak, aby standardowe powiększenie rzeczywiście działało.
Jeżeli po użyciu funkcji przeglądarki tekst znika, przyciski nachodzą na siebie albo menu przestaje być dostępne, dodatkowy przycisk „powiększ tekst” nie rozwiązuje źródła problemu.
Strona powinna działać po powiększeniu całego interfejsu
Panel zwiększający wyłącznie wielkość akapitów może stworzyć pozór spełnienia wymagań. Tymczasem użytkownik potrzebuje powiększenia całego interfejsu, łącznie z menu, formularzami, komunikatami i przyciskami.
Jeżeli własna kontrolka zmienia tylko treść artykułu, a etykiety formularza i nawigacja pozostają małe, nie zapewnia równoważnego dostępu.
Znaczenie ma również zachowanie układu. Po powiększeniu treść powinna dopasować się do dostępnej szerokości. Użytkownik nie powinien być zmuszony do przewijania każdego wiersza tekstu w lewo i w prawo.
Kryterium ponownego przepływu treści służy właśnie temu, aby powiększenie nie prowadziło do konieczności ciągłego przewijania w dwóch kierunkach. W3C wskazuje, że takie przewijanie zwiększa wysiłek fizyczny i poznawczy oraz utrudnia utrzymanie miejsca czytania.
Poprawnie przygotowany układ responsywny jest więc ważniejszy niż dodatkowy zestaw przycisków w nagłówku.
Odpowiedni kontrast powinien być zapewniony domyślnie
Podstawowa wersja strony powinna mieć kolory spełniające wymagania kontrastu. Dla zwykłego tekstu WCAG na poziomie AA wymaga co najmniej proporcji 4,5:1, a dla odpowiednio dużego tekstu co najmniej 3:1.
Nie należy projektować bladoszarego tekstu na białym tle, a następnie oczekiwać, że użytkownik sam uruchomi tryb wysokiego kontrastu.
Osoba odwiedzająca serwis może nie zauważyć przycisku, nie rozumieć jego oznaczenia albo nie być w stanie go obsłużyć. Może też korzystać z własnych ustawień kolorystycznych, z którymi mechanizm strony będzie kolidował.
Wymaganie kontrastu dotyczy podstawowej prezentacji treści. Panel może zaoferować dodatkowy wariant kolorystyczny, ale nie powinien służyć do naprawiania wersji domyślnej.
Strona, która ma zbyt niski kontrast bez włączenia dodatkowego trybu, nadal może nie spełniać WCAG.
Tryb wysokiego kontrastu może być dodatkiem, ale nie obowiązkiem
Możliwość przełączenia strony na inną paletę kolorów może być przydatna dla części odbiorców. Nie jest jednak uniwersalnym rozwiązaniem.
Jedna osoba może potrzebować białego tekstu na czarnym tle, inna czarnego tekstu na jasnym żółtym tle, a kolejna korzystać z kolorów ustawionych na poziomie systemu. Nie da się przygotować jednego specjalnego trybu odpowiadającego wszystkim potrzebom.
Własna wersja kontrastowa może też pominąć część elementów. Zmieni kolory tekstu, lecz pozostawi nieczytelne ikony, obramowania pól, wykresy lub przyciski.
Znacznie ważniejsze jest zapewnienie prawidłowego kontrastu domyślnego oraz niewprowadzanie ograniczeń, które uniemożliwiają użytkownikowi zastosowanie własnych ustawień.
Jeżeli organizacja decyduje się na dodatkowy tryb, powinien być on dostępny, przetestowany i traktowany jako opcja personalizacji, a nie jako warunek korzystania ze strony.
Strona nie powinna zmuszać użytkownika do konfigurowania każdego serwisu osobno
Osoba, która potrzebuje większego tekstu, zwykle chce korzystać z takiego ustawienia na wszystkich stronach. Nie powinna przy każdej wizycie wyszukiwać nowego panelu, wybierać odpowiedniego przycisku i ponownie dostosowywać widoku.
Ustawienia przeglądarki i systemu operacyjnego pozwalają zachować preferencje w wielu usługach. Poprawnie zaprojektowana strona powinna je respektować.
Tworzenie własnych mechanizmów może prowadzić do niespójności. W jednym serwisie przycisk z literą „A” zwiększa tekst, w innym resetuje ustawienia, a w kolejnym rozwija cały panel. Położenie i obsługa także różnią się pomiędzy stronami.
Dla części użytkowników osobny panel jest więc dodatkowym zadaniem poznawczym, a nie ułatwieniem.
Dostępność powinna ograniczać liczbę koniecznych czynności, a nie wymagać wcześniejszego dostosowania każdej odwiedzanej strony.
Kontrolki same muszą być dostępne
Dodatkowy panel zwiększa liczbę elementów interaktywnych na stronie. Każdy z nich trzeba prawidłowo nazwać, udostępnić klawiaturą i zapewnić mu widoczny fokus.
Jeżeli przyciski są opisane jedynie ikonami, użytkownik czytnika ekranu może nie wiedzieć, co robią. Jeżeli panel rozwija się po najechaniu myszą, osoba korzystająca z klawiatury lub ekranu dotykowego może mieć problem z jego obsługą.
Mechanizm może także zasłaniać treść, formularz, przycisk kontaktowy albo baner zgód. Na ekranie telefonu dodatkowy pływający element zajmuje szczególnie dużo miejsca.
Oznacza to, że wprowadzenie kontrolek nie tylko nie gwarantuje dostępności, lecz tworzy kolejne elementy, które mogą zawierać błędy.
Jeżeli nie odpowiadają one na konkretną potrzebę użytkowników, ich obecność może niepotrzebnie komplikować interfejs.
Dodatkowy panel nie zastępuje prawidłowego kodu
Przyciski powiększania tekstu nie poprawią struktury nagłówków. Zmiana kolorów nie doda etykiet do formularza. Podkreślenie linków nie naprawi ich niejednoznacznych nazw.
Panel nie rozwiąże także problemów z klawiaturą, kolejnością fokusu, komunikatami błędów, dokumentami PDF ani multimediami.
Dostępność jest wynikiem wielu wzajemnie powiązanych decyzji projektowych, technicznych i redakcyjnych. Nie można jej sprowadzić do trzech kontrolek umieszczonych przy logo.
Najważniejsza jest możliwość korzystania z podstawowej wersji serwisu przy użyciu standardowych narzędzi użytkownika.
Własne kontrolki mogą kolidować z ustawieniami użytkownika
Osoby z niepełnosprawnościami często posiadają już skonfigurowane środowisko pracy. Korzystają z własnego powiększenia, kolorów, arkuszy stylów, czcionek lub trybów wysokiego kontrastu.
Skrypt strony może nadpisać te ustawienia albo połączyć je w nieprzewidywalny sposób. Po włączeniu dodatkowego trybu tekst może stać się niewidoczny, elementy mogą utracić obramowania, a część ikon zmienić znaczenie.
Problem może wystąpić również podczas resetowania widoku. Przycisk „wersja standardowa” może przywracać ustawienia autora zamiast pozostawić preferencje systemowe użytkownika.
Strona powinna przede wszystkim nie przeszkadzać technologiom i ustawieniom wybranym przez odbiorcę.
Brak panelu nie powinien być błędem w audycie
W raportach dostępności czasami pojawia się rekomendacja dodania możliwości zmiany kontrastu lub wielkości tekstu jako obowiązkowego elementu.
Taka uwaga wymaga ostrożności. Audyt powinien badać, czy tekst można skutecznie powiększyć, czy układ zachowuje funkcjonalność i czy kontrast spełnia wymagania. Nie powinien automatycznie wymagać konkretnego panelu, jeśli te warunki są już spełnione.
Należy oddzielić niezgodność z WCAG od dobrowolnej rekomendacji użytecznościowej.
Dodanie kontrolki może być uzasadnione specyfiką odbiorców, wynikami badań albo założeniami danego serwisu. Nie oznacza to jednak, że każda strona bez takiej funkcji jest niedostępna.
Profesjonalny audyt powinien wskazać problem użytkownika i kryterium, którego dotyczy. Nie powinien narzucać rozwiązania tylko dlatego, że stało się ono popularnym elementem stron publicznych.
O dostępności decyduje działanie, nie widoczny symbol
Duże litery „A” w nagłówku są łatwo zauważalne podczas prezentacji serwisu. Mogą sprawiać wrażenie, że organizacja świadomie podchodzi do potrzeb osób słabowidzących.
Nie dają jednak odpowiedzi na pytanie, czy strona działa po użyciu powiększenia przeglądarki, przy szerokości odpowiadającej ekranowi telefonu i przy zwiększonych odstępach między znakami oraz wierszami.
Podobnie ikona kontrastu nie potwierdza, że domyślne kolory są prawidłowe.
Widoczny zestaw kontrolek jest łatwy do pokazania, dlatego bywa utożsamiany z dostępnością. Rzeczywista jakość ujawnia się dopiero podczas testów.
Kiedy dodatkowe funkcje mogą mieć sens
Brak obowiązku nie oznacza zakazu stosowania kontrolek.
Dodatkowa funkcja może być wartościowa, jeżeli odpowiada na rozpoznaną potrzebę odbiorców, została dobrze zaprojektowana i nie koliduje z podstawowym interfejsem.
Przykładem może być specjalny tryb uproszczonej prezentacji w serwisie zawierającym bardzo złożone dane albo możliwość zatrzymania intensywnych animacji. Nadal trzeba jednak upewnić się, że podstawowa wersja spełnia obowiązujące wymagania.
Decyzja powinna wynikać z analizy, a nie z przekonania, że każda strona dostępna musi mieć identyczny panel.
Dobrze przygotowana strona nie potrzebuje osobnego trybu „dla osób z niepełnosprawnościami”
Najlepszy model polega na tym, że użytkownik otwiera stronę i korzysta z niej w zwykły sposób. Nie musi włączać specjalnej wersji, szukać symbolu dostępności ani deklarować swoich potrzeb.
Tekst ma odpowiedni kontrast. Układ reaguje na powiększenie. Elementy mieszczą się na ekranie. Formularze, menu i przyciski nadal działają. Ustawienia przeglądarki oraz systemu nie są blokowane.
W tak przygotowanym serwisie brak przycisków zmiany kontrastu i wielkości tekstu nie jest brakiem dostępności. Może być wręcz oznaką dojrzalszego podejścia, w którym dostępność została wbudowana w stronę zamiast dołączona jako osobna warstwa.
Dodatkowy panel może pełnić funkcję pomocniczą, lecz nie jest wymaganym elementem zgodności. Wymagane jest to, aby użytkownik mógł skutecznie odczytać treść i obsłużyć stronę przy użyciu własnych narzędzi oraz preferencji.
Dostępność nie powinna zaczynać się po naciśnięciu specjalnego przycisku. Powinna działać od momentu otwarcia strony.