Jak napisać SIWZ na stronę zgodną z WCAG — wzory zapisów i checklista

Poprawne przygotowanie SIWZ na stronę zgodną z WCAG i umowy dla strony projektu UE zmniejsza ryzyko odrzucenia wydatków, sporu z wykonawcą oraz problemów z użytecznością dla osób z niepełnosprawnościami. Ten przewodnik pokazuje, co wpisać do SIWZ na stronę zgodną z WCAG, jak skonstruować kryteria akceptacji, jakie klauzule umowne zastosować oraz zawiera gotowe fragmenty do wklejenia.

1. Dlaczego poprawne zamówienie strony projektu UE ma znaczenie — krótkie ryzyko i konsekwencje

Zamawiający projekt UE musi pogodzić kilka wymogów jednocześnie: rozliczenia z instytucją finansującą, jawność informacji o dofinansowaniu oraz dostępność zgodna z WCAG. Błędy w SIWZ na stronę zgodną z WCAG lub nieprecyzyjna umowa prowadzą najczęściej do trzech problemów:

• niekwalifikowalność wydatków i konieczność zwrotu części dofinansowania (konkretne przypadki w kontrolach wykazują zwykle brak dokumentacji testów dostępności),
• opóźnienia w odbiorze i uruchomieniu strony — co przekłada się na przesunięcie kamieni milowych projektu,
• konieczność kosztownych poprawek po odbiorze lub sporu prawnego z wykonawcą.

Dlatego warto precyzyjnie zdefiniować wymagania techniczne, kryteria odbioru i mechanizmy egzekwowania zapisów w umowie.

2. Co powinno znaleźć się w SIWZ: wymagania funkcjonalne i techniczne

Wymogi dostępności (WCAG)

W SIWZ umieść jasny zapis: konkretna wersja i poziom standardu (np. WCAG 2.1, poziom AA). Dodatkowo wymagaj dostarczenia dowodów, nie tylko deklaracji wykonawcy. Przykładowe zapisy i wymagania:

• zgodność z WCAG 2.1 AA potwierdzona raportem automatycznym i raportem z audytu manualnego,
• raporty generowane po kluczowych etapach: demo, wersja beta, wersja produkcyjna,
• manualne testy dostępności i testy z użytkownikami z niepełnosprawnościami (patrz sekcja o testach),
• dostępność treści multimedialnych: napisy do wszystkich materiałów wideo i audiodeskrypcja dla materiałów kluczowych,
• dostępne wersje dokumentów PDF zgodne z WCAG.

CMS, hosting, bezpieczeństwo

Wymagaj kryteriów, nie tylko nazw systemów. Przykład specyfikacji technicznej:

• CMS: możliwość obsługi semantycznej struktury nagłówków, przyjazne ARIA, mechanizmy tworzenia dostępnych formularzy; wymagaj kompatybilności z narzędziami do testów automatycznych,
• Hosting: SLA min. 99,5% dostępności miesięcznej, backup codzienny, RTO (czas przywrócenia) do 24 godzin, lokalizacja serwera zgodna z wymaganiami projektowymi,
• Bezpieczeństwo: obowiązek stosowania TLS, proces aktualizacji krytycznych bibliotek w 7 dni od publikacji łaty, skanowanie podatności co najmniej raz w miesiącu, procedury RODO dla formularzy i zgód.

Wielojęzyczność i materiały projektowe

Określ liczbę języków, sposób tłumaczeń (np. treści merytoryczne tłumaczone przez tłumacza przysięgłego lub agencję), wymóg meta-tagów hreflang i mapy URL przyjaznej SEO. Zapewnij integrację z narzędziami analitycznymi i mechanizmy publikacji komunikatów o dofinansowaniu.

3. Kryteria akceptacji i procedura testowania zgodności z WCAG

Precyzyjne kryteria akceptacji skracają procedurę odbioru i zmniejszają pole do sporów. Proponowana procedura:

• odbiór etapowy: demo funkcjonalne, wersja beta (testy integracyjne), odbiór końcowy po poprawkach,
• testy automatyczne: raporty z Axe, Lighthouse i WAVE dla stron kluczowych (np. strona główna, podstrona formularza, strona z materiałami do pobrania),
• audyt manualny: lista kontrolna dla elementów wymagających testów manualnych — nawigacja klawiaturowa, etykiety pól formularzy, atrybuty ALT, poprawna semantyka HTML, kontrast kolorów, fokus widoczny wizualnie),
• testy z użytkownikami: min. 3–5 osób z różnymi rodzajami niepełnosprawności; przygotuj protokoły obserwacji i krótkie nagrania sesji (jeśli zgoda uczestników),
• raport końcowy: zestawienie niezgodności z WCAG, przypisanie priorytetu napraw (P1/P2/P3), harmonogram poprawek oraz dowody ich wykonania (zrzuty ekranu, nagrania, nowe raporty automatyczne).

W kryteriach akceptacji określ tolerancję: przykład praktyczny — co najmniej 95% kryteriów automatycznych bez błędów i brak krytycznych błędów manualnych uniemożliwiających korzystanie z serwisu.

4. Wzory klauzul umownych do wklejenia

Poniżej proponowane, proste do wdrożenia klauzule. Dopasuj je do procedur wewnętrznych i regulacji instytucji finansującej.

Przeniesienie praw autorskich: Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do kodu źródłowego, grafiki i treści powstałych w związku z realizacją zamówienia, bez ograniczeń terytorialnych i czasowych, w pełnym zakresie eksploatacji.

SLA i gwarancja dostępności: Wykonawca zapewnia dostępność serwisu na poziomie minimum 99,5% miesięcznie. W przypadku niedotrzymania SLA Zamawiającemu przysługuje kara umowna 0,5% wartości umowy za każdy dzień niedostępności powyżej 8 godzin kumulatywnie.

Gwarancje dostępności WCAG: Wykonawca gwarantuje zgodność z WCAG 2.1 AA na etapie odbioru. Stwierdzone niezgodności usuwane są zgodnie z priorytetami: P1 — do 7 dni, P2 — do 14 dni, P3 — do 30 dni. Brak usunięcia uprawnia Zamawiającego do naliczenia kar umownych lub rozwiązania umowy.

Dodaj zapisy o obowiązku przekazania dokumentacji technicznej, szkoleniach dla zespołu Zamawiającego oraz procesu przekazania kodu i danych po zakończeniu projektu.

5. Jak oceniać oferty: wzór punktacji i wymagane załączniki

Propozycja systemu oceny ofert (100 punktów):

• cena — 40 pkt (najniższa cena uzyskuje maksymalną ilość punktów),
• doświadczenie i referencje — 20 pkt (realizacje stron zgodnych z WCAG, referencje od instytucji publicznych — np. przykłady stron z raportami audytów),
• rozwiązanie technologiczne — 15 pkt (propozycja CMS, polityka aktualizacji, zabezpieczenia),
• procedura testów dostępności i plan wdrożenia — 15 pkt (szczegółowo opisane testy automatyczne i manualne oraz testy z użytkownikami),
• gwarancje i SLA — 10 pkt (czas reakcji, czas naprawy, dostępność).

W załącznikach wymagaj konkretów: raporty z audytów dostępności z ostatnich 2–3 realizacji, kontakty do zamawiających jako referencje, certyfikaty kompetencji (np. szkolenia z WCAG) oraz wykaz komponentów i prototypów interfejsu.

6. Gotowa checklista do skopiowania dla beneficjenta

Poniższa checklista można wkleić do SIWZ i umowy jako załącznik. Dostosuj terminy do harmonogramu projektu.

• Wymóg: zgodność z WCAG 2.1 poziom AA — potwierdzona raportem automatycznym i audytem manualnym,
• Testy z co najmniej 3 użytkownikami z niepełnosprawnościami; raport z obserwacji,
• Przekazanie kodu źródłowego, instrukcji wdrożenia i pełnej dokumentacji technicznej,
• SLA: dostępność 99,5%, backup codzienny, odzyskiwanie danych do 24 h,
• Bezpieczeństwo: TLS, skan podatności co najmniej raz w miesiącu, dostęp do wyników skanów,
• Multimedia: napisy do wszystkich filmów; audiodeskrypcja do materiałów kluczowych,
• PDF: dostępne wersje PDF zgodne z WCAG i narzędzia do walidacji,
• Gwarancja poprawek: terminy P1/P2/P3 oraz kary umowne za przekroczenia.

Przykładowy zapis SIWZ do wklejenia: "Wykonawca zobowiązany jest dostarczyć stronę zgodną z WCAG 2.1 AA. Odbiór nastąpi po przedłożeniu: raportu z narzędzi automatycznych; raportu z audytu manualnego; protokołu testów z użytkownikami z niepełnosprawnościami; dowodu wykonania poprawek wykazanych w raportach."

Zakończenie i wezwanie do działania

SIWZ na stronę zgodną z WCAG to nie tylko zapis formalny — to narzędzie zarządzania ryzykiem. W praktyce rzetelnie przygotowany dokument skróci czas odbioru i ochroni budżet projektu. Jeśli potrzebujesz, przygotujemy kompletny SIWZ i wzór umowy dostosowany do wymogów Twojej instytucji finansującej oraz przeprowadzimy audyt ofert. Skontaktuj się, a ustalimy zakres i harmonogram konsultacji.

Wskazówka praktyczna: w dokumentacji zamieść przykładowe raporty z Axe/Lighthouse oraz listę testowanych stron (np. strona główna, strona z formularzem, podstrona z PDF). To skraca czas oceny ofert i ułatwia porównanie wykonawców.