Anatomia zapytania ofertowego uwzględniającego dostępność — pięć rzeczywistych sekcji dotyczących dostępności, klauzula po klauzuli

Zapytanie ofertowe stoi lub pada na sekcji dotyczącej dostępności — tak samo, jak umowa stoi lub pada na klauzuli odszkodowawczej. Pozyskano pięć rzeczywistych fragmentów RFP z publicznych archiwów przetargowych i korporacyjnych portali zamówień, zanonimizowano podmioty wystawiające i poddano każdy z nich szczegółowej analizie klauzula po klauzuli. Najsilniejsza sekcja — federalne zapytanie ze Stanów Zjednoczonych powołujące się na Section 508 z wyraźnym odniesieniem do WCAG 2.1 AA — liczyła 612 słów. Najsłabsza — boilerplate dużej korporacji z Fortune 1000, wymagający od dostawców „zgodności z obowiązującymi przepisami prawa“ — liczyła 31. W pięciu próbkach trzy luki prawne pojawiły się w czterech z pięciu dokumentów. Jeden przetarg państwa członkowskiego UE wymagał VPAT, ale nie zastrzegał, że musi on zostać wypełniony przez podmiot trzeci. Oto ta analiza.

Jak dobrano i zanonimizowano pięć RFP

Pięć dokumentów poddanych analizie pochodzi z trzech źródeł publicznych i dwóch korporacyjnych portali zamówień. Federalne zapytanie ofertowe pochodzi z ogłoszenia na SAM.gov zamkniętego w 2025 roku; stanowy RFP — z portalu zamówień publicznych jednego ze stanów środkowego zachodu, zamkniętego w 2024 roku; przetarg państwa członkowskiego UE — z TED (Tenders Electronic Daily); korporacyjny RFP Fortune 500 — z fragmentu udostępnionego przez respondenta objętego NDA z dostawcą, który zdecydował się pozostać anonimowy; boilerplate — z pakietu onboardingowego dostawcy Fortune 1000 dołączanego do każdej umowy z dostawcą w tej firmie.

Usunięto numery umów, nazwy agencji i wszelkie sformułowania jednoznacznie identyfikujące wystawcę. Treść nie została sparafrazowana. Każda cytowana poniżej klauzula pochodzi dosłownie ze źródła, a redakcja ogranicza się wyłącznie do usunięcia rzeczowników identyfikujących podmiot (“[Agencja]”, “[Departament Stanu]”, “[Państwo Członkowskie]”). Celem analizy jest język; język został zachowany.

Próbka A: federalne zapytanie ofertowe USA

Próbka federalna jest najsilniejszą z pięciu i wyznacza górny punkt odniesienia dla całego zbioru danych. Liczy 612 słów w dziewięciu ponumerowanych podklauzulach. Powołuje się na Section 508 ustawy Rehabilitation Act, odwołuje się do aktualizacji ICT z 2018 roku i włącza WCAG 2.0 AA przez odniesienie (zgodnie z aktualizacją), jednocześnie wyraźnie podnosząc minimalny poziom do WCAG 2.1 AA dla wszelkich produktów internetowych i mobilnych. Kryteria przyjęcia są konkretne: VPAT 2.5 ACR przygotowany lub niezależnie zweryfikowany przez podmiot legitymujący się kwalifikacjami w zakresie dostępności, testowanie z co najmniej jednym wymienionym z nazwy czytnikiem ekranu oraz zobowiązanie do naprawy usterek po udzieleniu zamówienia.

Ta klauzula jest mocna, ponieważ robi trzy rzeczy jednocześnie. Wskazuje produkt do dostarczenia (VPAT 2.5 ACR). Wskazuje wymagane kwalifikacje (CPACC, WAS lub równoważne). I wskazuje zakres testowania (jeden czytnik ekranu, jedno rozwiązanie głosowe, nawigacja wyłącznie klawiaturą). Klauzula nie pozostawia dostawcy możliwości złożenia ACR wypełnionego jak lista kontrolna i uznania sprawy za zamkniętą.

Jedyna słabość próbki A: harmonogram napraw. Federalna sekcja odwołuje się do „niezwłocznej naprawy“ i „w rozsądnym terminie“ — oba pojęcia są niezdefiniowane. Dostawca posiadający powiadomienie o usterce może w nieskończoność argumentować, co oznacza „rozsądny“. Modelowa sekcja na końcu tej analizy wypełnia tę lukę.

Próbka B: stanowe zamówienie publiczne USA

Próbka stanowa jest kompetentna, ale cieńsza niż federalna. Liczy 287 słów w pięciu podklauzulach. Odwołuje się do Section 508, zakotwicza w WCAG 2.1 AA i wymaga VPAT — ale nie wymaga niezależnej weryfikacji VPAT. Nie wskazuje również żadnej technologii wspomagającej do testowania. Klauzula jest zakotwiczona we właściwych standardach, lecz nie egzekwuje dyscypliny dającej użyteczny artefakt.

„Może być przygotowany przez Dostawcę lub jego agentów“ to zdanie będące luką prawną. Stan zaakceptował na piśmie samopotwierdzenie dostawcy jako substytut niezależnie sporządzonego raportu zgodności. Stan zastrzegł sobie również prawo („może zażądać naprawy“) bez odpowiadającego mu obowiązku po stronie dostawcy („zobowiązany do naprawy w ciągu N dni“). Zastrzeżone prawa bez harmonogramów nie są wykonalnymi terminami.

Próbka C: przetarg państwa członkowskiego UE

Próbka państwa członkowskiego UE jest najciekawszą z pięciu. Powołuje się na EN 301 549 v3.2.1 — zharmonizowany europejski standard dostępności ICT — i odwołuje się do Dyrektywy (UE) 2019/882 (Europejski Akt o Dostępności) oraz Dyrektywy (UE) 2016/2102 (Dyrektywa w sprawie dostępności stron internetowych). Jest to również jedyny RFP w zbiorze danych, który powiązał kamień milowy płatności z produktem potwierdzającym zgodność.

Klauzula 9.5 to najsilniejsze pojedyncze zdanie w całym zbiorze danych. Mechanizm wstrzymania 15 procent płatności powiązany z niezależną weryfikacją zamienia pisemne kryterium przyjęcia w kryterium wykonalne. Dostawca nie może pobrać końcowej płatności do czasu złożenia i weryfikacji raportu. To wzorzec, który próbki federalna i stanowa powinny były zastosować.

Jedyna słabość próbki C: zakotwicza w EN 301 549 v3.2.1, który włącza WCAG 2.1, a nie 2.2. Kryteria sukcesu dodane w wersji 2.2 (wygląd fokusu, ruchy przeciągania, minimalny rozmiar celu) nie są zatem wymagane umownie nawet w przetargach datowanych na 2026 rok.

Próbka D: korporacyjny RFP Fortune 500

Korporacyjna próbka Fortune 500 jest drugą najsilniejszą w zbiorze danych i drugą pod względem długości. Liczy 421 słów. Wymaga VPAT 2.5 ACR, zakotwicza w WCAG 2.1 AA i odwołuje się do wewnętrznego „Standardu zamówień dostępnych“ firmy (zanonimizowanego). Nie wskazuje technologii wspomagających z nazwy produktu, ale wymaga „kompatybilności z powszechnie używanymi czytnikami ekranu i rozwiązaniami do wprowadzania głosowego“.

Sekcja korporacyjna jest interesująca ze względu na to, co dodaje i co pomija. Dodaje klauzulę odszkodowawczą: dostawca zabezpiecza firmę przed wszelkimi roszczeniami stron trzecich z tytułu dyskryminacji ze względu na dostępność wynikającymi z produktu dostarczonego przez dostawcę. Jest to przetargowy odpowiednik przeniesienia ryzyka stosowanego w umowach o przetwarzaniu danych. Pomija jednak jakikolwiek mechanizm wstrzymania płatności. Dźwignią jest odszkodowanie, nie kamień milowy.

Próbka E: boilerplate

Boilerplate to jedno zdanie. Cytujemy je w całości.

„Wszelkie obowiązujące przepisy“ to klauzula będąca wszędzie i nigdzie jednocześnie. Nie odwołuje się do żadnego standardu. Nie wskazuje żadnego produktu do dostarczenia. Nie przywołuje żadnego zakresu testowania. Jest to zastępczak, który zadowala dział prawny i nie wiąże dostawcy żadnymi konkretnym zobowiązaniem. Dostawca naruszający umowę może argumentować, że nie wskazano żadnego konkretnego obowiązku, a zespół przetargowy nie dysponuje żadnym mechanizmem gromadzenia dowodów.

Klauzula boilerplate jest wszechobecna, ponieważ jej napisanie nic nie kosztuje i jej negocjowanie nie rodzi żadnego oporu. Jej wartość jest w przybliżeniu równa zeru.

Trzy luki pojawiające się w czterech z pięciu dokumentów

W pięciu próbkach powtórzyły się trzy wzorce. Po pierwsze: akceptacja samopotwierdzonego VPAT (4 z 5). Po drugie: brak harmonogramu napraw (5 z 5). Po trzecie: milczenie lub brak precyzji w kwestii testowania z technologiami wspomagającymi (4 z 5; jedynie próbka federalna wskazuje AT z nazwy produktu). Te trzy luki to otwory, przez które niezgodny produkt może przejść do produkcji.

Modelowa sekcja RFP uwzględniająca dostępność

Połączenie najsilniejszych klauzul z pięciu próbek daje sekcję, której żaden dokument w zbiorze danych faktycznie nie zawiera. Liczy około 350 słów i zamyka trzy luki zidentyfikowane powyżej.

Ta klauzula modelowa robi pięć rzeczy, z których najsilniejsza pojedyncza próbka w zbiorze danych — federalna — robi tylko trzy. Zakotwicza w WCAG 2.2 (nie 2.1). Wskazuje technologie wspomagające z nazwy produktu. Wymaga niezależnej weryfikacji VPAT. Określa harmonogram napraw powiązany z wagą usterki, z mnożnikiem kary umownej za opóźnienie. I uzależnia wypłatę ostatniej transzy płatności od zweryfikowanej zgodności. Zespoły przetargowe adaptujące tę sekcję do swojej jurysdykcji powinny zamieniać WCAG 2.2 na WCAG 2.1 wyłącznie wtedy, gdy ich standard zarządzający nie został jeszcze zaktualizowany; w przeciwnym razie zakotwiczenie w wersji 2.2 jest właściwe.

Podsumowanie: co zbiór danych podpowiada zespołom przetargowym

Główny wniosek z tej analizy jest niepochlebny i operacyjnie użyteczny. Na pięć rzeczywistych RFP obejmujących cztery kategorie jurysdykcyjne: tylko jeden dokument powiązał dowód z płatnością, tylko jeden wymagał niezależnej weryfikacji VPAT i żaden nie określił harmonogramu napraw uwzględniającego wagę usterki. Standardy istnieją. Język umów pozwalający je egzekwować — nie.

Dla zespołów przetargowych piszących następny RFP uwzględniający dostępność zbiór danych sugeruje trzy konkretne poprawki i jedną strategiczną zmianę. Poprawki: wskazać kwalifikacje wymagane przy weryfikacji VPAT, wskazać technologie wspomagające do testowania, powiązać kamień milowy płatności ze zweryfikowanym raportem zgodności. Zmiana: przestać powielać standard. Zakotwiczenie w WCAG 2.2 AA jest właściwe już teraz; weryfikację pod kątem WCAG 3.0 warto przeprowadzić, gdy wyjdzie pierwsza formalna Rekomendacja.

Zdanie boilerplate — „zgodny ze wszystkimi obowiązującymi przepisami“ — nie ma miejsca w RFP uwzględniającym dostępność. To zastępczak, po który sięgają zespoły przetargowe, gdy sekcja wydaje się zbyt ryzykowna do właściwego napisania. Powyższa analiza jest — bardziej niż cokolwiek innego — argumentem za tym, że właściwe napisanie jej nie jest tak trudne, jak wygląda. Pięć klauzul, trzy luki zamknięte, jedna dźwignia płatnicza dołączona. Na tym polega ta praca.

Zespoły przetargowe adaptujące ten język: zakotwicz odniesienie do standardu w pełnym indeksie kryteriów sukcesu WCAG 2.2, poproś dostawców o przeprowadzenie bezpłatnego skanowania WCAG 2.2 na demonstracyjnym URL przywołanym w odpowiedzi, wymagaj ręcznego audytu przez testerów z niepełnosprawnościami jako weryfikacji zgodności i traktuj bieżącą zgodność po udzieleniu zamówienia jako ciągły obowiązek objęty przewodnikiem dla kupujących narzędzia monitorujące.