Nowa strona może wyglądać nowocześnie, szybko się ładować i poprawnie wyświetlać na telefonie. Może również posiadać deklarację wykonawcy, że została przygotowana zgodnie z WCAG. Żaden z tych elementów nie potwierdza jednak, że serwis jest rzeczywiście dostępny.
Najwięcej błędów ujawnia się dopiero podczas wykonywania konkretnych zadań. Menu działa myszą, ale nie można go obsłużyć klawiaturą. Formularz wygląda poprawnie, lecz nie przekazuje informacji o błędach. Wyszukiwarka wyświetla wyniki, ale użytkownik czytnika ekranu nie otrzymuje komunikatu o ich pojawieniu się. System zakupiony jako dostępny traci poprawność po połączeniu z motywem, wtyczką lub zewnętrzną usługą.
Jeżeli takie problemy zostaną wykryte po podpisaniu protokołu i dokonaniu płatności, ich usunięcie staje się znacznie trudniejsze. Wykonawca może uznać, że zrealizował umowę, a każdą kolejną zmianę potraktować jako dodatkowo płatną usługę.
Dlatego dostępność powinna być jednym z warunków odbioru strony, a nie deklaracją weryfikowaną dopiero po jej uruchomieniu. Oficjalne zalecenia dotyczące zamówień wskazują, że pozytywny wynik testów dostępności może stanowić warunek odbioru, a umowa powinna zapewniać możliwość wdrożenia wynikających z nich poprawek.
Zapis „zgodna z WCAG” jest zbyt ogólny
W umowach często pojawia się jedno zdanie: „Strona zostanie wykonana zgodnie ze standardem WCAG”. Taki zapis brzmi prawidłowo, ale pozostawia wiele pytań.
Nie wiadomo, której wersji WCAG dotyczy, jaki poziom zgodności ma zostać osiągnięty, co dokładnie podlega ocenie i według jakiej metody zostanie przeprowadzony odbiór. Nie określono również, kto wykonuje testy, jak dokumentuje błędy i w jakim terminie wykonawca ma je usunąć.
Wykonawca może rozumieć zgodność jako pozytywny wynik automatycznego skanera. Zamawiający może oczekiwać pełnego audytu manualnego. Obie strony używają tego samego pojęcia, ale przypisują mu zupełnie inny zakres.
Wymagania powinny odnosić się do całego przedmiotu zamówienia: szablonów, komponentów, formularzy, dokumentów, multimediów oraz procesów realizowanych na stronie. Jeżeli częścią projektu jest system rezerwacji, płatności lub obsługi zgłoszeń, jego dostępność nie może zostać pominięta tylko dlatego, że technicznie działa pod innym adresem.
Deklaracja wykonawcy nie jest niezależnym potwierdzeniem
Wykonawca zna własny projekt i powinien przeprowadzać testy podczas wdrożenia. Jego oświadczenie jest jednak informacją pochodzącą od strony odpowiedzialnej za wykonanie umowy.
Może potwierdzać, że zespół uwzględniał dostępność, ale nie zastępuje niezależnej oceny rezultatu. Szczególnie wtedy, gdy wynagrodzenie i termin płatności zależą od uznania strony za gotową.
Problemem nie musi być celowe wprowadzenie zamawiającego w błąd. Firma może nie posiadać wystarczających kompetencji audytowych, opierać się na testach automatycznych albo badać wyłącznie własne komponenty. Może również nie zauważyć błędów powstałych podczas integracji z treściami i usługami dostarczonymi przez zamawiającego.
Niezależna weryfikacja ogranicza ten konflikt interesów. Pozwala oddzielić ocenę jakości od procesu produkcji oraz wskazać niezgodności w sposób możliwy do odtworzenia przez wykonawcę.
Automatyczny raport nie wystarcza do odbioru
Raport z popularnego narzędzia może wyglądać profesjonalnie. Zawiera liczbę błędów, ostrzeżenia i wynik punktowy. Nie oznacza jednak, że sprawdzono rzeczywiste działanie strony.
Ministerstwo Cyfryzacji wskazuje, że automatyczne testy wykrywają jedynie część problemów. Są użyteczne w pracy programistów i audytorów, ale nie zastępują oceny manualnej.
Skaner może wykryć brak opisu obrazu, ale nie oceni, czy opis przekazuje właściwe znaczenie. Może potwierdzić obecność etykiety pola, lecz nie ustali, czy formularz jest zrozumiały i czy po błędzie użytkownik potrafi go poprawić.
Nie sprawdzi wiarygodnie działania menu z klawiaturą, zarządzania fokusem w oknie modalnym ani pełnego procesu płatności. Nie oceni także jakości treści, logiki nagłówków i użyteczności komunikatów.
Pozytywny wynik automatyczny powinien być jednym z elementów kontroli technicznej. Nie może stanowić jedynego dowodu potrzebnego do podpisania protokołu odbioru.
Odbiera się cały proces, a nie tylko stronę główną
Strona główna jest zwykle najlepiej dopracowaną częścią serwisu. To na niej skupiają się projektanci, wykonawcy i osoby podejmujące decyzję o odbiorze.
Najpoważniejsze problemy mogą jednak występować gdzie indziej: w wyszukiwarce, formularzu, archiwum, tabeli, systemie logowania albo podczas płatności. Samo poprawne działanie strony głównej nie mówi nic o dostępności tych funkcji.
WCAG wymaga, aby w przypadku procesu składającego się z wielu kroków zgodność obejmowała cały jego przebieg. Nie można uznać procesu za zgodny, jeżeli jedna z koniecznych stron lub czynności pozostaje niedostępna.
W odbiorze należy więc uwzględnić realne scenariusze użytkownika. Dla urzędu może to być odnalezienie informacji i złożenie formularza. Dla instytucji kultury wybranie wydarzenia i zakup biletu. Dla sklepu odszukanie produktu, dodanie go do koszyka i zakończenie płatności.
Dopiero przejście pełnego procesu pokazuje, czy dostarczona strona realizuje swój cel.
Treści demonstracyjne mogą ukrywać problemy
Wykonawca często przekazuje serwis z niewielką liczbą przykładowych materiałów. Strona główna zawiera krótkie tytuły, idealnie dobrane zdjęcia i prostą tabelę. Prawdziwe treści są dodawane dopiero przed uruchomieniem albo już po odbiorze.
Wtedy pojawiają się długie nagłówki, wielostronicowe dokumenty, rozbudowane tabele, plakaty i nietypowe formaty. Komponent, który wyglądał poprawnie w wersji demonstracyjnej, zaczyna ucinać tekst, rozszerzać stronę albo zmieniać kolejność treści na telefonie.
Odbiór powinien więc odbywać się na serwisie wypełnionym reprezentatywnymi materiałami. Nie muszą to być wszystkie przyszłe treści, ale powinny odzwierciedlać ich rzeczywistą różnorodność.
W przeciwnym razie ocenia się projekt graficzny, a nie system przeznaczony do codziennego użytkowania.
Panel redakcyjny wpływa na utrzymanie dostępności
Odbiór strony nie powinien dotyczyć wyłącznie widoku publicznego. Znaczenie ma również to, jakie możliwości otrzymują redaktorzy.
System może pozwalać na tworzenie układów, które łatwo prowadzą do błędów. Redaktor może zmieniać kolory bez kontroli kontrastu, pomijać poziomy nagłówków, tworzyć przyciski o niejednoznacznych nazwach albo publikować plakat bez tekstowego opisu.
Nie każdy błąd da się zablokować technicznie. Panel powinien jednak wspierać poprawną publikację, a nie wymagać od każdego pracownika znajomości kodu HTML.
Istotne są również instrukcje i szkolenie. Jeżeli wykonawca przekazuje stronę wraz z rozbudowanym systemem komponentów, powinien wyjaśnić, jak ich używać bez naruszania dostępności.
Brak takich zasad sprawia, że dostępny w dniu odbioru serwis zaczyna tracić jakość przy pierwszych samodzielnych zmianach.
Weryfikacja poprawek jest częścią odbioru
Raport audytowy nie kończy procesu. Wskazuje problemy, które wykonawca powinien usunąć, a następnie poddać ponownej kontroli.
Samo oświadczenie, że wszystkie uwagi zostały wdrożone, nie wystarcza. Poprawka może usunąć jedną barierę i wprowadzić inną. Zmiana działania okna modalnego może naprawić fokus, ale uniemożliwić zamknięcie go klawiszem Escape. Korekta kolorów może poprawić kontrast tekstu, ale osłabić widoczność aktywnego elementu.
Weryfikacja powinna odnosić się do konkretnych ustaleń z raportu i sprawdzać rzeczywisty rezultat. Jeżeli wykonawca proponuje inne rozwiązanie niż rekomendowane, trzeba ocenić, czy usuwa ono problem użytkownika, a nie tylko zmienia kod.
Dopiero potwierdzenie skuteczności poprawek daje podstawę do zamknięcia odbioru w obszarze dostępności.
Umowa powinna przewidywać czas na poprawki
Audyt wykonany dzień przed planowanym uruchomieniem strony stawia zamawiającego w trudnej sytuacji. Może podpisać odbiór mimo błędów albo przesunąć publikację i wejść w spór z wykonawcą.
Dostępność trzeba uwzględnić w harmonogramie od początku. Pierwsze testy powinny odbywać się na etapie, na którym zmiany są jeszcze możliwe bez przebudowy całego rozwiązania. Pełny audyt powinien natomiast poprzedzać ostateczny odbiór na tyle wcześnie, aby wykonawca zdążył wdrożyć poprawki.
Umowa powinna określać terminy reakcji, usuwania niezgodności i ich ponownej weryfikacji. Warto również powiązać odbiór końcowy lub część płatności z pozytywnym wynikiem kontroli.
Bez takich zapisów raport może stać się jedynie listą rekomendacji, których realizacja zależy od dobrej woli wykonawcy.
Trzeba odróżnić błąd wykonawcy od nowego zlecenia
Podczas audytu mogą pojawić się problemy wynikające z niewłaściwej realizacji wymagań oraz propozycje rozwoju wykraczające poza pierwotny zakres.
Wykonawca nie powinien pobierać dodatkowego wynagrodzenia za usunięcie niezgodności, jeżeli umowa wymagała dostarczenia dostępnej strony. Z drugiej strony audyt nie powinien służyć do rozszerzania projektu o funkcje, których wcześniej nie zamówiono.
Dlatego raport i umowa muszą precyzyjnie rozdzielać błędy, wymagane poprawki oraz dodatkowe rekomendacje.
Brak takiego rozróżnienia prowadzi do sporów. Wykonawca twierdzi, że audytor zmienia zakres projektu, a zamawiający uznaje każdą sugestię za część gwarancji.
Ekspercka ocena powinna wskazywać, które ustalenia dotyczą zgodności, które użyteczności, a które stanowią zalecenia rozwojowe.
Gwarancja powinna obejmować regresję dostępności
Strona może działać poprawnie w dniu odbioru, a następnie utracić dostępność po aktualizacji wykonanej przez dostawcę.
Jeżeli firma odpowiada za utrzymanie systemu, umowa powinna regulować również skutki takich zmian. Aktualizacja bezpieczeństwa, motywu lub komponentu nie może automatycznie zwalniać wykonawcy z odpowiedzialności za zepsucie wcześniej poprawnego mechanizmu.
Szczególnego znaczenia nabierają menu, formularze, wyszukiwarki, systemy zgód i komponenty dynamiczne. To właśnie w nich regresja może zablokować najważniejsze procesy.
Zamawiający powinien mieć możliwość zgłoszenia problemu, uzyskania poprawki i zweryfikowania jej bez konieczności zamawiania kolejnego pełnego wdrożenia.
Deklarację dostępności przygotowuje się na podstawie rzeczywistej oceny
Nowa strona podmiotu publicznego powinna posiadać deklarację dostępności. Nie należy jednak publikować automatycznej informacji o pełnej zgodności tylko dlatego, że wykonawca wpisał taki status w szablonie.
Deklaracja musi odpowiadać rzeczywistemu stanowi serwisu. Jeżeli audyt wykazał niezgodności, powinny zostać usunięte albo rzetelnie opisane wraz z uzasadnieniem.
Deklaracja nie jest certyfikatem odbioru. Nie zastępuje raportu, testów i weryfikacji poprawek. Jest publiczną informacją dla użytkowników, dlatego nie może opierać się wyłącznie na marketingowej deklaracji dostawcy.
Dobry odbiór chroni także wykonawcę
Rzetelna procedura odbioru nie służy wyłącznie szukaniu podstaw do odmowy płatności. Chroni również wykonawcę przed późniejszymi, nieprecyzyjnymi roszczeniami.
Jeżeli zakres, metoda badania i kryteria akceptacji zostały określone wcześniej, obie strony wiedzą, czego oczekiwać. Raport wskazuje konkretne problemy, a ponowna weryfikacja potwierdza ich usunięcie.
Wykonawca otrzymuje jasne informacje techniczne, a zamawiający dowód, że serwis został sprawdzony według ustalonych zasad.
Najgorszy model polega na wpisaniu jednego zdania o WCAG, braku testów przed uruchomieniem i próbie dochodzenia poprawek wiele miesięcy później.
Stronę trzeba odbierać jako usługę, nie jako obraz na ekranie
Dostępność nie jest cechą makiety ani wyglądu strony głównej. Dotyczy sposobu działania całej usługi.
Profesjonalny odbiór powinien obejmować reprezentatywne podstrony, komponenty, treści, dokumenty i pełne procesy użytkownika. Musi łączyć testy automatyczne z manualnymi oraz zakończyć się weryfikacją wdrożonych poprawek.
Oświadczenie wykonawcy może być jednym z dokumentów odbiorowych, ale nie powinno być jedynym dowodem zgodności.
Najlepszy moment na wykrycie błędów przypada przed podpisaniem protokołu, kiedy zamawiający nadal posiada narzędzia pozwalające wyegzekwować poprawki. Po uruchomieniu niedostępnej strony problem nie znika. Zmienia się jedynie osoba, która musi ponieść koszt jego rozwiązania.