Strona internetowa może wyglądać poprawnie na dużym monitorze, a jednocześnie być bardzo trudna lub niemożliwa do obsługi na telefonie. Problemy ujawniają się po zmianie orientacji ekranu, zwiększeniu rozmiaru tekstu, otwarciu menu mobilnego albo podczas wypełniania formularza za pomocą klawiatury ekranowej. Dlatego dostępności serwisu nie można oceniać wyłącznie na podstawie widoku desktopowego.
W przypadku stron urzędowych ma to szczególne znaczenie. Telefon nie służy już tylko do szybkiego sprawdzania godzin pracy lub numeru kontaktowego. Użytkownicy szukają na nim dokumentów, zapisują się na wydarzenia, wysyłają formularze, rezerwują terminy i korzystają z elektronicznych usług. Jeżeli mobilna wersja strony utrudnia wykonanie takich czynności, problem dotyczy nie tylko wygody, lecz realnego dostępu do informacji i usług publicznych.
Responsywność nie oznacza automatycznie dostępności
Responsywna strona dopasowuje układ do szerokości ekranu. Kolumny ustawiają się jedna pod drugą, menu zmienia się w przycisk, a obrazy zmniejszają się wraz z dostępnym miejscem. Taki mechanizm może jednak działać poprawnie wizualnie, a mimo to tworzyć bariery.
Elementy mogą nachodzić na siebie, tekst może wychodzić poza ekran, przyciski mogą stać się zbyt małe, a kolejność treści może przestać odpowiadać jej logicznej strukturze. Czasami część informacji znika całkowicie, ponieważ projektant uznał ją za mniej ważną w wersji mobilnej.
Dostępna wersja mobilna nie polega więc tylko na zmniejszeniu strony. Musi zachować kompletność treści, logiczną kolejność, możliwość powiększenia i sprawną obsługę wszystkich funkcji.
Strona musi działać po powiększeniu tekstu
Użytkownik może zwiększyć rozmiar tekstu w przeglądarce lub w ustawieniach telefonu. Robią tak osoby słabowidzące, starsze, mające trudność z odczytywaniem drobnych znaków albo korzystające z urządzenia w niesprzyjających warunkach.
Po powiększeniu tekst nie powinien być ucinany, zasłaniany ani zastępowany wielokropkiem. Przyciski powinny zwiększyć wysokość, a zawartość kart, komunikatów i formularzy musi pozostać czytelna. Niedopuszczalna jest sytuacja, w której powiększony tekst wychodzi poza przycisk albo nakłada się na sąsiedni element.
Szczególnie podatne na błędy są sztywno ustawione wysokości sekcji. Jeżeli projektant określił, że karta ma zawsze 180 pikseli wysokości, większy tekst może się w niej nie zmieścić. Podobny problem występuje w przyciskach, nagłówkach, kafelkach aktualności i komunikatach pojawiających się nad stroną.
Testowanie powinno obejmować nie tylko powiększenie całego widoku, lecz także zwiększenie rozmiaru samego tekstu. Strona musi pozostawać funkcjonalna bez konieczności zmniejszania czcionki przez użytkownika.
Przewijanie w dwóch kierunkach utrudnia czytanie
Na małym ekranie użytkownik powinien zasadniczo przewijać stronę w jednym kierunku, z góry na dół. Jeżeli musi przesuwać widok także poziomo, aby przeczytać każde kolejne zdanie, korzystanie z treści staje się bardzo męczące.
Problem ten często pojawia się przy tabelach, osadzonych dokumentach, szerokich grafikach, mapach, formularzach i elementach z narzuconą minimalną szerokością. Czasami jeden niedopasowany komponent rozszerza całą stronę, przez co użytkownik musi przesuwać ekran na boki nawet podczas czytania zwykłych akapitów.
Nie oznacza to, że każdy element musi zawsze mieścić się na ekranie bez poziomego przewijania. Rozbudowana tabela może wymagać dodatkowego rozwiązania. Nie powinna jednak powodować przesuwania całego serwisu. Można umieścić ją w osobnym obszarze, podzielić na mniejsze zestawienia albo przedstawić najważniejsze informacje również w formie tekstowej.
Sama informacja, że „na telefonie tabelę można przewijać”, nie rozwiązuje problemu. Trzeba sprawdzić, czy użytkownik rozumie, że dostępne są dalsze kolumny, czy nagłówki pozostają czytelne i czy możliwe jest powiązanie danych z właściwymi kategoriami.
Menu mobilne musi być obsługiwane klawiaturą
Menu w wersji mobilnej jest zwykle ukryte pod przyciskiem przedstawianym jako trzy poziome linie. Taki przycisk musi mieć dostępną nazwę, być możliwy do obsługi klawiaturą oraz informować technologię wspomagającą, czy menu jest otwarte.
Po rozwinięciu nawigacji fokus powinien przejść w logiczne miejsce. Użytkownik nie może zostać przeniesiony do niewidocznej części strony ani zmuszony do wielokrotnego naciskania klawisza Tab, zanim dotrze do pierwszej pozycji menu.
Menu musi też dać się zamknąć bez użycia myszy. Przycisk zamykający powinien być widoczny i odpowiednio opisany. Po zamknięciu fokus powinien wrócić do elementu, który otworzył nawigację.
Częstym błędem jest pozostawienie aktywnych elementów strony pod otwartym menu. Użytkownik korzystający z klawiatury przechodzi wtedy do linków, których nie widzi, ponieważ są zasłonięte przez warstwę nawigacji. Podobny problem może dotyczyć czytnika ekranu, który nadal odczytuje treści znajdujące się pod menu.
Zmiana orientacji nie może blokować treści
Niektórzy użytkownicy korzystają z telefonu zamocowanego w uchwycie i nie mogą swobodnie obracać urządzenia. Inni używają orientacji poziomej, ponieważ daje ona większą szerokość tekstu albo lepiej współpracuje z powiększeniem.
Strona nie powinna wymuszać jednej orientacji ekranu, chyba że jest ona rzeczywiście niezbędna dla działania konkretnej funkcji. Typowy serwis urzędowy, formularz kontaktowy, strona wydarzenia lub BIP powinny działać zarówno pionowo, jak i poziomo.
Po obróceniu urządzenia trzeba sprawdzić menu, nagłówki, komunikaty, formularze oraz przyciski znajdujące się przy dolnej krawędzi ekranu. W orientacji poziomej dostępna wysokość jest znacznie mniejsza. Przyklejony nagłówek, pasek cookies i dolna belka mogą razem zasłonić większość treści.
Szczególnie niebezpieczne są okna modalne o stałej wysokości. Jeżeli nie mieszczą się na ekranie, użytkownik może nie dotrzeć do przycisku zamknięcia albo zatwierdzenia.
Małe przyciski są problemem nie tylko dla osób z niepełnosprawnościami
Na telefonie elementy interaktywne obsługuje się palcem, który jest znacznie mniej precyzyjny niż kursor myszy. Małe ikony, ciasno rozmieszczone linki i niewielkie przyciski zwiększają ryzyko przypadkowego uruchomienia sąsiedniej funkcji.
Dotyczy to między innymi przycisków zamykania komunikatów, ikon pobierania plików, strzałek w kalendarzu, przełączników kategorii, linków do mediów społecznościowych i numerów stron w paginacji.
Problemem jest nie tylko widoczny rozmiar ikony, lecz cały obszar aktywny. Symbol może być niewielki, jeżeli wokół niego pozostawiono wystarczająco dużo miejsca umożliwiającego bezpieczne dotknięcie. Jeżeli jednak kilka drobnych ikon znajduje się bezpośrednio obok siebie, użytkownik może mieć trudność z wybraniem właściwej.
Minimalny rozmiar nie powinien być celem projektowym. Najważniejsze działania, takie jak wysłanie formularza, potwierdzenie zapisu albo przejście do kolejnego kroku, powinny być wyraźne i łatwe do uruchomienia.
Klawiatura ekranowa może zasłaniać formularz
Podczas wpisywania danych klawiatura ekranowa zajmuje dużą część ekranu. Pole formularza, komunikat błędu lub przycisk przejścia dalej mogą zostać przez nią zasłonięte.
Dobrze zaprojektowany formularz automatycznie przewija stronę tak, aby aktywne pole pozostało widoczne. Użytkownik powinien jednocześnie widzieć etykietę, wpisywaną wartość oraz ewentualny komunikat o błędzie.
Nie należy stosować tekstu zastępczego wewnątrz pola jako jedynej etykiety. Po rozpoczęciu wpisywania znika on z widoku, a użytkownik może przestać wiedzieć, jakiej informacji oczekuje formularz. Problem jest szczególnie dotkliwy na telefonie, gdzie jednocześnie widoczna jest niewielka część strony.
Pola powinny również korzystać z odpowiedniego typu danych. Dla numeru telefonu można wyświetlić klawiaturę numeryczną, dla adresu e-mail klawiaturę zawierającą łatwo dostępny znak „@”, a dla daty prawidłowo opisany mechanizm jej wyboru. Takie rozwiązania ograniczają liczbę błędów i przyspieszają wypełnianie formularza.
Komunikat błędu musi być widoczny przy właściwym polu
Na komputerze użytkownik może objąć wzrokiem dużą część formularza. Na telefonie widzi zwykle jedno lub kilka pól. Jeżeli po wysłaniu formularza komunikat o błędzie pojawia się wyłącznie na górze strony, użytkownik może go nie zauważyć.
Błąd powinien zostać opisany tekstowo i powiązany z konkretnym polem. Formularz powinien przenieść uwagę do miejsca wymagającego poprawy albo przedstawić zrozumiałe podsumowanie problemów.
Samo czerwone obramowanie nie wystarcza. Kolor może być trudny do rozpoznania, a przy małym ekranie pole może znajdować się poza aktualnym widokiem. Potrzebna jest jasna informacja, na przykład „Wpisz adres e-mail w formacie [nazwa@domena.pl](mailto:nazwa@domena.pl)”.
Po poprawieniu błędu użytkownik nie powinien tracić wcześniej wpisanych danych. Konieczność ponownego wypełnienia całego formularza jest szczególnie uciążliwa na telefonie.
Przyklejone elementy mogą zasłonić większość strony
Stały nagłówek, pasek informacyjny, zgoda na pliki cookie, przycisk kontaktowy i dolna nawigacja mogą być użyteczne osobno. Razem potrafią jednak pozostawić użytkownikowi bardzo niewielki fragment ekranu.
Problem nasila się po powiększeniu tekstu oraz w orientacji poziomej. Komunikat, który na komputerze zajmuje niewielki pasek, na telefonie może rozrosnąć się do połowy ekranu. Jeżeli nie da się go łatwo zamknąć, użytkownik ma utrudniony dostęp do całej strony.
Przyklejone elementy nie mogą również zasłaniać fokusu. Osoba korzystająca z klawiatury lub zewnętrznego przełącznika musi widzieć aktualnie wybrany link, przycisk lub pole formularza.
Każdy stały element powinien mieć rzeczywiste uzasadnienie. Wiele interfejsów mobilnych jest przeładowanych funkcjami, które miały zwiększać wygodę, ale ostatecznie ograniczają dostęp do właściwej treści.
Kolejność wizualna musi odpowiadać kolejności odczytu
W wersji desktopowej treść może być rozmieszczona w kilku kolumnach. Po przejściu do widoku mobilnego elementy ustawiają się jeden pod drugim. Wtedy ujawnia się rzeczywista kolejność zapisana w kodzie strony.
Jeżeli kod został przygotowany głównie pod układ wizualny, na telefonie nagłówek może zostać oddzielony od swojej treści, przycisk może pojawić się przed opisem, a informacje dodatkowe mogą znaleźć się w przypadkowym miejscu.
Podobny problem dotyczy użytkowników czytników ekranu niezależnie od rozmiaru wyświetlacza. Technologia wspomagająca odczytuje strukturę dokumentu, a nie jego wizualne położenie. Dlatego logiczna kolejność powinna być prawidłowa już w kodzie, a arkusz stylów może jedynie zmieniać sposób prezentacji.
Szczególną uwagę trzeba zwrócić na karty usług, listy wydarzeń, wyniki wyszukiwania i wielokolumnowe sekcje strony głównej.
Treść nie może znikać tylko dlatego, że ekran jest mały
Projektanci czasami ukrywają w wersji mobilnej opisy, informacje dodatkowe, etykiety albo całe sekcje. Takie rozwiązanie ma uprościć widok, ale może pozbawić użytkownika ważnych informacji.
Ukrycie treści jest dopuszczalne, gdy użytkownik może ją łatwo rozwinąć i mechanizm jest prawidłowo opisany. Nie powinno jednak prowadzić do sytuacji, w której wersja mobilna zawiera mniej informacji niż desktopowa.
Na stronie urzędu szczególnie niebezpieczne jest ukrywanie danych kontaktowych, informacji o dostępności obiektu, terminów, warunków udziału, statusu dokumentu albo objaśnień pól formularza.
Telefon nie może być traktowany jako urządzenie przeznaczone do korzystania z uproszczonej, niepełnej wersji usługi. Użytkownik powinien mieć dostęp do tego samego zakresu informacji i funkcji.
Mobilny test wymaga prawdziwego urządzenia
Tryb responsywny w przeglądarce komputerowej jest przydatny, ale nie odtwarza wszystkich warunków korzystania z telefonu. Nie pokazuje dokładnie działania klawiatury ekranowej, gestów dotykowych, powiększenia systemowego ani wpływu ustawień dostępności urządzenia.
Test powinien zostać przeprowadzony przynajmniej na kilku rzeczywistych telefonach o różnych rozmiarach ekranu. Warto sprawdzić orientację pionową i poziomą, zwiększony rozmiar tekstu, powiększenie, obsługę dotykową i działanie formularzy.
Nie wystarczy obejrzeć stronę główną. Należy wykonać pełne zadania: odnaleźć dokument, otworzyć menu, przejść do podstrony, wypełnić formularz, wywołać błąd, pobrać plik i zamknąć pojawiające się komunikaty.
Testowanie mobilne powinno obejmować także najważniejsze systemy zewnętrzne. Jeżeli strona urzędu przekierowuje do platformy rezerwacyjnej, systemu płatności lub formularza obsługiwanego przez wykonawcę, użytkownik nadal postrzega cały proces jako jedną usługę.
Dostępność mobilna pokazuje jakość całego serwisu
Problemy widoczne na telefonie często nie są odrębnymi błędami wersji mobilnej. Ujawniają słabości całej architektury strony: sztywne wymiary, przypadkową kolejność kodu, źle opisane formularze, zbyt małe elementy i nadmierną liczbę przyklejonych komponentów.
Dobrze zaprojektowany serwis powinien elastycznie reagować na różne sposoby korzystania. Użytkownik nie może być zmuszany do obracania urządzenia, zmniejszania tekstu, zamykania klawiatury po każdym polu ani powiększania drobnych przycisków przed ich dotknięciem.
Dostępność mobilna nie jest dodatkiem do wersji desktopowej. Jest jednym z podstawowych warunków dostępności cyfrowej. Jeżeli mieszkaniec może znaleźć usługę na komputerze, ale nie jest w stanie ukończyć jej na telefonie, serwis nie zapewnia równoważnego dostępu.
Dlatego audyt strony powinien obejmować nie tylko to, jak wygląda ona na małym ekranie, lecz przede wszystkim to, czy użytkownik może samodzielnie przeczytać treść, odnaleźć potrzebną funkcję i zakończyć rozpoczętą sprawę.