Strona urzędu lub instytucji może być poprawna technicznie, czytelna i zgodna z wymaganiami dostępności, a mimo to prowadzić użytkownika do niedostępnej usługi. Wystarczy, że rezerwacja wizyty, zakup biletu, płatność, formularz zgłoszeniowy albo transmisja są obsługiwane przez zewnętrzną platformę.
Dla użytkownika nie ma większego znaczenia, kto dostarczył system. Jeżeli rozpoczął załatwianie sprawy na stronie instytucji, traktuje kolejne etapy jako jeden proces. Gdy po kliknięciu przycisku trafia do niedostępnego kalendarza, formularza lub operatora płatności, cała usługa przestaje być skuteczna.
Podmiot publiczny nadal odpowiada za dostępność swoich stron i aplikacji, nawet jeśli rozwiązanie zostało wykonane przez zewnętrznego dostawcę. Oficjalne materiały dotyczące zarządzania dostępnością cyfrową wyraźnie wskazują, że zlecenie budowy systemu nie przenosi obowiązku prawnego na wykonawcę.
Użytkownik widzi jeden proces, nie kilka umów
Instytucja może oddzielać własny serwis od zewnętrznego systemu rezerwacji, płatności czy obsługi dokumentów. Z punktu widzenia organizacyjnego są to różne rozwiązania, utrzymywane przez inne podmioty i objęte odrębnymi umowami.
Użytkownik nie analizuje jednak architektury systemu ani podziału odpowiedzialności. Chce umówić wizytę, opłacić usługę, zapisać się na wydarzenie albo złożyć wniosek.
Jeżeli pierwszy etap działa poprawnie, ale kolejnego nie można obsłużyć bez myszy, odczytać czytnikiem ekranu albo ukończyć po powiększeniu tekstu, proces pozostaje niedostępny.
WCAG traktuje wieloetapowe działania jako pełne procesy. Jeżeli wykonanie zadania wymaga przejścia przez kilka stron, zgodność nie może dotyczyć wyłącznie wybranego początku procesu.
Największe problemy pojawiają się po przekierowaniu
Strona instytucji często zawiera prosty i dostępny przycisk „Zarezerwuj wizytę” albo „Kup bilet”. Dopiero po jego uruchomieniu zaczynają się właściwe bariery.
Zewnętrzny system może mieć niedostępny kalendarz, nieopisane pola, nieczytelne komunikaty błędów albo krótki limit czasu. Plan sali może wymagać precyzyjnego użycia myszy, a operator płatności może wyświetlać kod lub zabezpieczenie niemożliwe do obsłużenia technologią wspomagającą.
Część problemów pojawia się dopiero po zalogowaniu, wybraniu usługi albo wprowadzeniu nieprawidłowych danych. Dlatego samo obejrzenie pierwszego ekranu systemu nie daje wiarygodnej informacji o jego dostępności.
Profesjonalny audyt powinien objąć rzeczywisty przebieg zadania, a nie tylko stronę, z której użytkownik został przekierowany.
Informacja „to system zewnętrzny” nie usuwa bariery
Instytucje często wyjaśniają problemy dostępności tym, że nie mają dostępu do kodu dostawcy. Jest to istotne z punktu widzenia sposobu naprawy, ale nie zmienia sytuacji użytkownika.
Brak kontroli technicznej nie oznacza braku wpływu. Podmiot wybrał rozwiązanie, podpisał umowę, kieruje do niego odbiorców i wykorzystuje je do realizowania własnych zadań.
Jeżeli system nie spełnia wymagań, instytucja powinna uruchomić działania wobec dostawcy, określić plan poprawy i ocenić, czy potrzebna jest dostępna metoda alternatywna. Powinna też uwzględnić stan rozwiązania w swojej informacji o dostępności.
Nie wystarczy zamieścić komunikatu, że za platformę odpowiada inna firma. Taka informacja wyjaśnia strukturę usługi, ale nie zapewnia użytkownikowi możliwości jej wykonania.
Umowa powinna zabezpieczać interes instytucji
Dostępności nie powinno się dopisywać do projektu dopiero po wdrożeniu. Jeżeli nie została precyzyjnie opisana w zamówieniu i umowie, wykonawca może uznać, że zrealizował wszystkie wymagania, mimo że system zawiera poważne bariery.
Ogólne zdanie „system musi być zgodny z WCAG” jest zwykle zbyt słabe. Nie określa wersji standardu, poziomu zgodności, zakresu funkcji, metody odbioru ani odpowiedzialności za usuwanie błędów.
Ministerstwo Cyfryzacji zaleca, aby wymagania dostępności były wprost uwzględniane w umowach i zamówieniach. Niedostępne rozwiązanie może powodować nie tylko problemy prawne, ale również konieczność poniesienia dodatkowych kosztów naprawy.
Z punktu widzenia instytucji istotne są również zasady aktualizacji. System dostępny w dniu odbioru może utracić dostępność po zmianie komponentu, formularza albo sposobu logowania. Umowa powinna przewidywać kontrolę zmian i obowiązek usuwania regresji.
Deklaracja producenta nie zastępuje odbioru
Dostawcy często deklarują zgodność rozwiązania z WCAG lub normą EN 301 549. Taka deklaracja może być wartościową informacją, ale nie powinna być jedyną podstawą odbioru.
Nie wiadomo, jaki zakres został zbadany, w jakiej konfiguracji, z jakimi technologiami i przed którą aktualizacją. System demonstracyjny może działać inaczej niż wersja wdrożona u klienta.
Różnice mogą wynikać z ustawień, integracji, języka, dodatkowych modułów albo sposobu osadzenia rozwiązania na stronie. Dostępny komponent może zostać połączony z niedostępnym formularzem albo zasłonięty przez komunikat generowany przez inny skrypt.
Dlatego zgodność trzeba zweryfikować w rzeczywistym środowisku i na realnych scenariuszach użytkownika.
Odbiór nie powinien kończyć się na wyglądzie
Przy odbiorze zewnętrznego systemu sprawdza się zwykle zgodność z opisem funkcjonalnym, szybkość działania, poprawność danych i bezpieczeństwo.
Dostępność bywa sprowadzana do automatycznego raportu albo krótkiego przeglądu strony głównej.
Tymczasem najpoważniejsze problemy mogą występować dopiero przy wyborze terminu, poprawianiu błędu, dodawaniu załącznika, potwierdzaniu operacji lub płatności.
Audyt musi więc objąć różne stany systemu, w tym sytuacje błędne i nietypowe. Powinien także sprawdzić, jak zachowuje się platforma na telefonie, przy powiększeniu i bez użycia myszy.
Tylko wtedy można ocenić, czy użytkownik rzeczywiście jest w stanie zakończyć usługę.
Alternatywny sposób obsługi nie może być gorszą usługą
Jeżeli system pozostaje niedostępny, instytucja może zapewnić alternatywną metodę kontaktu lub realizacji sprawy. Nie powinna ona jednak prowadzić do obniżenia jakości obsługi.
Osoba korzystająca z alternatywy nie może być zmuszona do dłuższego oczekiwania, osobistej wizyty albo ujawniania większej ilości danych niż pozostali użytkownicy. Nie powinna też tracić możliwości wyboru terminu, miejsca lub formy płatności.
Alternatywa nie może również opierać się wyłącznie na telefonie. Dla osoby głuchej lub niemówiącej taki kanał może być równie niedostępny jak główny system.
Metoda zastępcza powinna ograniczać skutki bariery, ale nie może stać się usprawiedliwieniem dla utrzymywania niedostępnego rozwiązania przez kolejne lata.
Aktualizacja dostawcy może zmienić stan dostępności
Zewnętrzne systemy są rozwijane niezależnie od instytucji. Dostawca może zmienić interfejs, bibliotekę komponentów, sposób logowania albo operatora płatności.
Aktualizacja może poprawić funkcjonalność i jednocześnie wprowadzić regresję dostępności. Przycisk przestaje otrzymywać fokus, komunikat nie jest odczytywany, a kalendarz zmienia sposób obsługi.
Instytucja często dowiaduje się o problemie dopiero po zgłoszeniu użytkownika. Jest to skutek braku monitorowania zmian i testów kluczowych procesów.
Zewnętrzny system powinien więc podlegać okresowej kontroli, szczególnie po większych aktualizacjach. Im ważniejsza usługa, tym większe znaczenie ma szybkie wykrycie regresji.
Problem może dotyczyć jedynie fragmentu integracji
Nie każda bariera oznacza, że cały system trzeba od razu zastąpić. Czasami problem wynika ze sposobu połączenia go ze stroną instytucji.
Może to być nieopisany element osadzony w ramce, błędny przycisk uruchamiający usługę albo konflikt między platformą a banerem cookies. W innych przypadkach niedostępny jest tylko jeden etap, na przykład wybór daty lub potwierdzenie płatności.
Profesjonalna diagnoza pozwala ustalić źródło problemu i odpowiedzialny obszar. Bez niej instytucja może kierować ogólne reklamacje do dostawcy, który nie jest w stanie odtworzyć błędu, albo próbować poprawiać własną stronę, gdy bariera znajduje się wewnątrz platformy.
Odpowiedzialność musi być przypisana wewnątrz organizacji
Zewnętrzny system często nie ma wyraźnego właściciela po stronie instytucji. Dział merytoryczny korzysta z usługi, informatyk odpowiada za integrację, a zamówienie prowadziła jeszcze inna komórka.
W efekcie nie wiadomo, kto powinien zgłaszać błędy, kontrolować aktualizacje i kontaktować się z dostawcą.
Dostępność wymaga wyznaczenia osoby lub zespołu odpowiedzialnego za cały proces. Nie musi to być specjalista wykonujący samodzielnie wszystkie testy. Powinien jednak wiedzieć, kiedy uruchomić ocenę ekspercką, gdzie przekazać zgłoszenie i jak kontrolować realizację poprawek.
Bez takiego nadzoru niedostępność systemu zewnętrznego łatwo staje się problemem, za który formalnie odpowiadają wszyscy, a praktycznie nikt.
Audyt powinien badać odpowiedzialność, nie tylko kod
Ocena systemu zewnętrznego nie powinna kończyć się listą błędów technicznych.
Trzeba również ustalić, kto może je naprawić, jakie zapisy znajdują się w umowie, jak szybko dostawca reaguje na zgłoszenia i czy instytucja ma możliwość weryfikowania kolejnych wersji.
Wynik audytu powinien oddzielać błędy strony głównej, integracji, platformy dostawcy i dodatkowych usług, takich jak płatności lub uwierzytelnianie.
Takie rozróżnienie pozwala zaplanować rzeczywiste działania zamiast ograniczać się do wpisania ogólnej niezgodności w deklaracji dostępności.
Zlecenie usługi nie oznacza zlecenia odpowiedzialności
Instytucja może kupić technologię, wsparcie i utrzymanie systemu. Nie może jednak założyć, że wraz z umową przekazała wykonawcy całą odpowiedzialność za dostęp użytkowników do swojej usługi.
Dostawca odpowiada za wykonanie zobowiązań wynikających z kontraktu. Podmiot publiczny nadal odpowiada za to, czy wykorzystywane rozwiązanie pozwala realizować jego zadania w sposób dostępny.
Dlatego dostępność zewnętrznych systemów trzeba uwzględniać przy wyborze rozwiązania, odbiorze, bieżącym utrzymaniu i każdej większej aktualizacji.
Najpoważniejszym błędem jest sprawdzenie wyłącznie własnej strony i uznanie, że wszystko, co znajduje się po kliknięciu zewnętrznego linku, przestaje być częścią usługi. Dla użytkownika bariera na ostatnim ekranie ma dokładnie ten sam skutek jak bariera na pierwszym: nie może ukończyć zadania.