Jedno zdanie, że strona internetowa, aplikacja albo system ma być zgodny z WCAG, nie zabezpiecza zamawiającego. Taki zapis brzmi poprawnie, ale w praktyce pozostawia zbyt wiele miejsca na interpretację. Nie wskazuje, jakie elementy podlegają ocenie, jak zostanie przeprowadzony odbiór ani co stanie się wtedy, gdy po uruchomieniu systemu ujawnią się bariery.
Dostępność powinna zostać opisana w taki sposób, aby można ją było sprawdzić, odebrać i egzekwować w trakcie realizacji umowy. Wymaga to połączenia wymagań technicznych z konkretnymi scenariuszami testowymi, odpowiedzialnością wykonawcy i procedurą usuwania błędów.
Dostępność w opisie przedmiotu zamówienia
Opis przedmiotu zamówienia powinien obejmować cały zakres rozwiązania, z którego będzie korzystał użytkownik. Nie wystarczy odnieść się wyłącznie do strony głównej albo podstawowego szablonu serwisu. Dostępność musi dotyczyć również wersji mobilnej, formularzy, wyszukiwarki, filtrów, dokumentów generowanych przez system, treści multimedialnych, komponentów zewnętrznych, panelu redakcyjnego oraz szablonów wykorzystywanych później przez pracowników.
Jeżeli zamawiany system obsługuje konkretny proces, wymagania powinny odnosić się do całej ścieżki użytkownika. Dostępny formularz nie rozwiązuje problemu, jeżeli kolejne etapy płatności, logowania, wyboru terminu albo pobrania potwierdzenia nie działają z klawiaturą lub czytnikiem ekranu. Podobnie dostępny serwis może prowadzić do zewnętrznego modułu, który uniemożliwia dokończenie sprawy.
Prawo zamówień publicznych pozwala określać wymagania jakościowe, funkcjonalne i odbiorowe. W obszarze dostępności powinny być one mierzalne i możliwe do zweryfikowania. Zamawiający powinien wiedzieć, co dokładnie będzie sprawdzane, na jakiej próbie i według jakich kryteriów. Ogólna deklaracja zgodności nie zastępuje precyzyjnego opisu oczekiwanego rezultatu.
Nie wystarczy oświadczenie wykonawcy
Wykonawca może zadeklarować, że przygotowane rozwiązanie spełnia wymagania dostępności, ale taka deklaracja nie powinna kończyć procesu odbioru. Twórca systemu ocenia własną pracę, dlatego może nie zauważyć błędów wynikających z przyjętej konstrukcji albo uznać za prawidłowe rozwiązania, które w praktyce są trudne do obsługi.
Zamawiający powinien określić, w jaki sposób zgodność zostanie zweryfikowana. Potrzebne są testy automatyczne, manualne, obsługa klawiaturą, kontrola widoków mobilnych, sprawdzenie powiększenia oraz analiza przykładowych procesów użytkownika. W zależności od systemu konieczne może być także badanie formularzy, dokumentów generowanych automatycznie, komunikatów dynamicznych, logowania, panelu użytkownika i integracji z usługami zewnętrznymi.
Najbezpieczniejszy jest odbiór przeprowadzony przez zamawiającego albo niezależnego audytora, który nie uczestniczył w tworzeniu rozwiązania. Pozwala to oddzielić wykonanie od oceny i ogranicza ryzyko przyjęcia systemu, który formalnie wygląda poprawnie, ale nadal zawiera bariery.
Testy powinny obejmować realne zadania
Dostępności nie należy sprawdzać wyłącznie przez analizę pojedynczych podstron. Użytkownik korzysta z serwisu po to, aby wykonać konkretne zadanie: znaleźć informację, wysłać formularz, pobrać dokument, dokonać płatności, zarezerwować termin albo zalogować się do systemu.
Odbiór powinien więc obejmować scenariusze odpowiadające rzeczywistemu sposobowi korzystania z rozwiązania. Pozwala to wykryć problemy, których nie pokaże automatyczny raport, takie jak nielogiczna kolejność fokusu, brak informacji o błędzie, utrata danych po nieudanym wysłaniu formularza albo niedostępny etap płatności.
Warto również sprawdzić system na urządzeniach mobilnych i przy zwiększonym rozmiarze tekstu. Część barier ujawnia się dopiero wtedy, gdy elementy zmieniają układ, pojawia się klawiatura ekranowa albo użytkownik korzysta z technologii wspomagającej.
Kryteria odbioru muszą być określone z góry
Zamawiający powinien przed rozpoczęciem realizacji ustalić, jakie błędy blokują odbiór, a jakie mogą zostać usunięte w uzgodnionym terminie po wdrożeniu. Bez takiego rozróżnienia każda niezgodność może stać się przedmiotem sporu.
Bariery uniemożliwiające wykonanie podstawowych czynności, obsługę klawiaturą, dostęp do formularzy, logowanie, płatność albo odczyt ważnych informacji powinny blokować odbiór. Drobniejsze problemy mogą zostać wpisane do protokołu z określonym terminem naprawy, jeżeli nie ograniczają użytkownikowi dostępu do usługi.
Kryteria powinny opisywać również sposób ponownego sprawdzenia. Nie wystarczy informacja, że wykonawca usunął błąd. Poprawka powinna zostać zweryfikowana w tym samym scenariuszu, w którym wcześniej wykryto problem, a przy komponentach powtarzalnych także w innych miejscach systemu.
Procedura naprawy błędów
Umowa powinna określać sposób zgłaszania niezgodności, terminy reakcji i naprawy oraz zasady ponownego odbioru. Warto rozróżnić błędy krytyczne, które blokują usługę, od problemów o mniejszym wpływie na użytkownika.
Wynagrodzenie końcowe można powiązać z usunięciem usterek blokujących odbiór. Takie rozwiązanie zwiększa motywację wykonawcy do rzeczywistego zakończenia prac, a nie tylko przekazania systemu w stanie pozwalającym na techniczne uruchomienie.
W umowie powinien znaleźć się również obowiązek usuwania barier ujawnionych w okresie gwarancji. Część problemów pojawia się dopiero podczas korzystania z systemu przez realnych użytkowników, po aktualizacji komponentu albo po dodaniu nowych treści. Dostępność nie może więc kończyć się w dniu podpisania protokołu odbioru.
Aktualizacje nie mogą przywracać usuniętych barier
System zgodny w dniu uruchomienia może stracić dostępność po kolejnej aktualizacji. Zmiana motywu, formularza, biblioteki JavaScript, mechanizmu logowania albo integracji z zewnętrzną usługą może ponownie wprowadzić problemy wcześniej usunięte.
Dlatego wymagania powinny obejmować także utrzymanie i rozwój systemu. Wykonawca powinien odpowiadać za testowanie zmian, dokumentowanie istotnych aktualizacji oraz usuwanie regresji dostępności. Zamawiający powinien mieć możliwość ponownego sprawdzenia rozwiązania po większych modyfikacjach.
Bez takich zapisów może dojść do sytuacji, w której poprawki wykonane podczas odbioru znikają kilka miesięcy później, a ich ponowne wdrożenie staje się odrębną, dodatkowo płatną usługą.
Odpowiedzialność za dostępność musi wynikać z umowy
Zamawiający odpowiada za usługę udostępnianą użytkownikom, ale wykonawca powinien odpowiadać za jakość rozwiązania, które dostarcza. Zakres tej odpowiedzialności musi wynikać z dokumentacji zamówienia i umowy.
Warto określić, kto przygotowuje testy, kto usuwa błędy, kto odbiera poprawki i kto odpowiada za komponenty dostarczane przez podwykonawców. Jeżeli wykonawca korzysta z gotowych bibliotek, wtyczek albo usług zewnętrznych, nie powinno to automatycznie zwalniać go z odpowiedzialności za końcowy efekt.
Dostępność cyfrowa w zamówieniu publicznym nie jest dodatkiem do projektu ani deklaracją składaną na zakończenie prac. Jest wymaganiem jakościowym, które musi zostać opisane, sprawdzone i utrzymane przez cały okres obowiązywania umowy.
Potrzebujesz wsparcia w tym obszarze?
Możemy ocenić opis przedmiotu zamówienia, projekt umowy i kryteria odbioru pod kątem dostępności cyfrowej oraz pomóc przygotować mierzalne wymagania dla wykonawcy.