Najdroższe błędy dostępności powstają przed podpisaniem umowy. Jeżeli analiza potrzeb pomija użytkowników z niepełnosprawnościami, opis przedmiotu zawiera tylko ogólne hasło, a odbiór opiera się na oświadczeniu wykonawcy, podmiot może zapłacić za rozwiązanie, którego nie potrafi skutecznie poprawić. Dostępność trzeba zaplanować od wymagań do utrzymania.
Analiza potrzeb i rynku
Przed opisem zamówienia należy wskazać użytkowników, kluczowe zadania, technologie, treści i integracje. Inny zakres ma prosta strona informacyjna, inny aplikacja mobilna, system rezerwacyjny, platforma szkoleniowa czy generator dokumentów. Warto sprawdzić, jakie rozwiązania rynkowe spełniają wymagania i gdzie konieczne będzie wykonanie własnych komponentów.
Badanie rynku nie powinno polegać tylko na pytaniu dostawców, czy produkt jest „zgodny z WCAG”. Trzeba prosić o raport, metodykę, datę badania, wersję produktu i znane ograniczenia. Certyfikat dotyczący wcześniejszej wersji lub strony demonstracyjnej nie potwierdza konfiguracji wdrażanej u zamawiającego.
Opis przedmiotu zamówienia
Wymagania powinny wskazywać obowiązującą podstawę prawną, oczekiwaną wersję WCAG i poziom, zakres stron, aplikacji, dokumentów, panelu administracyjnego i materiałów. Trzeba opisać procesy użytkownika, responsywność, współpracę z technologiami asystującymi oraz wymagania dla komponentów zewnętrznych.
Nie warto przepisywać samych numerów kryteriów bez kontekstu. Wykonawca musi wiedzieć, że dostępność dotyczy także treści startowych, szablonów dokumentów, komunikatów błędów, materiałów szkoleniowych i aktualizacji. Wymaganie powinno być testowalne i powiązane z kryterium odbioru.
Dowody i niezależność odbioru
Wykonawca może przedstawić oświadczenie oraz własny raport, ale zamawiający powinien zachować prawo do weryfikacji. Przy większym systemie warto rozdzielić wykonanie i niezależny audyt. Jeżeli jedna firma sama definiuje próbę, ocenia wynik i decyduje o zamknięciu błędów, powstaje konflikt interesów.
Raport odbiorowy powinien wskazywać wersję systemu, środowisko, próbę, metody, błędy i ograniczenia. Test obejmuje pełne procesy, nie tylko stronę główną. Zamawiający potrzebuje czasu na retest po poprawkach i nie powinien być zmuszony do odbioru warunkowego bez realnego mechanizmu egzekwowania.
Umowa, gwarancja i aktualizacje
Umowa powinna określać terminy usuwania błędów według wpływu, sposób zgłaszania, retest, odpowiedzialność za regresję i koszty poprawek. Dostępność musi obowiązywać przez okres utrzymania. Aktualizacja funkcji nie może obniżać wcześniej uzgodnionego poziomu.
Trzeba otrzymać kod lub prawa do jego modyfikacji w zakresie pozwalającym usuwać bariery, dokumentację komponentów, pliki źródłowe i instrukcje redakcyjne. Uzależnienie od dostawcy, który nie ma obowiązku reagować na błędy dostępności, może zablokować podmiot na lata.
Zakup treści i usług towarzyszących
Wymagania dotyczą nie tylko oprogramowania. Film powinien mieć napisy i, gdy jest potrzebna, audiodeskrypcję. Dokument musi mieć dostępną wersję źródłową i końcową. Projekt graficzny powinien przewidywać kontrast, powiększenie i responsywność. Organizator transmisji musi zapewnić dostępne elementy odtwarzacza oraz zaplanowane usługi dostępności.
Przy systemie biletowym lub płatniczym trzeba ustalić odpowiedzialność za całą ścieżkę, nawet gdy część obsługuje podwykonawca. Zamawiający nie powinien akceptować umowy, w której najważniejszy element usługi pozostaje poza wymaganiami i kontrolą.
Odbiór to początek utrzymania
Po odbiorze należy zapisać stan bazowy, listę znanych ograniczeń i zestaw testów regresji. Redakcja potrzebuje szkolenia z dostępnego używania systemu. Nowe szablony i moduły powinny przechodzić kontrolę przed publikacją. Dopiero takie połączenie umowy, badania i procesu daje trwały rezultat.
Powiązane materiały: Dostępność cyfrowa w zamówieniu publicznym, Odbiór strony od wykonawcy oraz Zewnętrzny system a odpowiedzialność.
Źródło: Jak dbać o dostępność cyfrową w umowach i zamówieniach publicznych.