Streszczenie wykonawcze

Dostępność cyfrowa w zamówieniach publicznych przestała być „miłym dodatkiem” – w wielu postępowaniach jest to twardy wymóg prawny (zwłaszcza gdy przedmiot zamówienia dotyczy stron WWW, aplikacji mobilnych, e-usług, dokumentów elektronicznych, systemów dla obywateli lub pracowników), a dodatkowo kluczowy element jakości, który można i warto oceniać w kryteriach ofert. Ramy unijne wynikają m.in. z dyrektywy zamówieniowej 2014/24/UE (akcent na projektowanie z przeznaczeniem dla wszystkich i uwzględnianie potrzeb osób z niepełnosprawnościami w specyfikacjach), dyrektywy 2016/2102 o dostępności stron i aplikacji sektora publicznego oraz dyrektywy 2019/882 (Europejski akt w sprawie dostępności), stosowanej od 28 czerwca 2025 r. citeturn33search0turn33search11turn33search2turn33search6

W Polsce filarami są: (1) ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) wraz z trybem skargowym oraz karami pieniężnymi (do 10 000 zł oraz do 5 000 zł – zależnie od naruszenia), oraz (2) Prawo zamówień publicznych (Pzp) – w szczególności obowiązek uwzględniania wymagań dostępności dla osób z niepełnosprawnościami w opisie przedmiotu zamówienia (art. 100 Pzp), a także ogólne reguły opisu przedmiotu (art. 99 Pzp). citeturn35view0turn37search8turn37search0

Najważniejsza lekcja praktyczna: samo hasło „zgodnie z WCAG” w SWZ/OPZ nie wystarczy. W dokumentacji trzeba doprecyzować zakres, poziom, sposób weryfikacji, wyniki testów i odpowiedzialność po wdrożeniu (utrzymanie, regresje, treści redakcyjne, integracje, dokumenty). Orzecznictwo KIO pokazuje, że spory powstają zarówno wtedy, gdy wymagania dostępności są niedookreślone (ryzyko „testowania pod wykonawcę”), jak i wtedy, gdy zamawiający próbuje wymagać funkcji lub sposobu wykazania zgodności wykraczającego poza SWZ/WCAG. citeturn23view0turn18view0turn28view0

W tekście znajdziesz: mapę przepisów (UE/PL/standardy), przykładowe zapisy SWZ/umowy, punktowe kryteria oceny ofert (z inspiracją z realnego sporu dot. Praca.gov.pl), checklisty odbioru, typowe uchybienia i ich skutki, oraz zestawienie ryzyk i sankcji. Dodatkowo zamieszczam dwie tabele porównawcze – jeśli chcesz wersję edytowalną (np. Excel/Google Sheets) do użytku w Twojej organizacji, poproś w komentarzu pod wpisem.

Kontekst prawny

Dlaczego dostępność cyfrowa „wchodzi” do zamówień

Dostępność cyfrowa to zdolność stron, aplikacji i treści cyfrowych do bycia skutecznie używanymi przez możliwie najszerszą grupę użytkowników – w tym osoby z niepełnosprawnościami (np. niewidome, słabowidzące, Głuche, z ograniczeniami motorycznymi i poznawczymi). W ujęciu UE dostępność jest rozumiana jako zasady i techniki, które należy stosować przy projektowaniu, budowie, utrzymaniu i aktualizacji stron oraz aplikacji, aby były bardziej dostępne, szczególnie dla osób z niepełnosprawnościami. citeturn33search14turn33search11

Prawo UE

Dyrektywa 2014/24/UE (zamówieniowa) – w praktyce to „konstytucja” udzielania zamówień w UE. Jest istotna dla dostępności, bo akcentuje wykorzystywanie zamówień do celów społecznych i konieczność uwzględniania Konwencji ONZ o prawach osób niepełnosprawnych przy wdrażaniu dyrektywy (m.in. w obszarze specyfikacji technicznych i warunków realizacji). Tekst dyrektywy (PL): EUR-Lex: 32014L0024. citeturn33search0turn33search7

Dyrektywa (UE) 2016/2102 (26 października 2016 r.) – dotyczy dostępności stron internetowych i mobilnych aplikacji organów sektora publicznego. Wymusza standardyzację podejścia (monitoring, sprawozdawczość, deklaracja dostępności). Tekst (PL): EUR-Lex: 2016/2102. citeturn33search11turn33search8turn33search1

Decyzje wykonawcze Komisji są ważne, bo „spinają” prawo z konkretnym standardem technicznym. Decyzja 2018/2048 (później zmieniona) dotyczy normy zharmonizowanej dla dyrektywy 2016/2102; decyzja 2021/1339 z 11 sierpnia 2021 r. aktualizuje odniesienie do normy zharmonizowanej, odnosząc się m.in. do EN 301 549 v3.2.1 (2021-03). Tekst decyzji 2021/1339 (PL): EUR-Lex: 32021D1339. citeturn34search3turn34search15turn34search11

Dyrektywa (UE) 2019/882 (Europejski akt w sprawie dostępności – EAA) – obejmuje wymagania dostępności wybranych produktów i usług (m.in. część usług cyfrowych). Jest stosowana od 28 czerwca 2025 r. (z przepisami przejściowymi). Tekst (PL): EUR-Lex: 2019/882. citeturn33search2turn33search6turn33search18

Prawo polskie

Ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) wdraża dyrektywę 2016/2102 i określa m.in. zakres podmiotowy, wyjątki, zasady zapewniania dostępności, deklarację dostępności, monitoring oraz tryb skargowy. Tekst (PDF Dz.U.):
gov.pl: D2019000084801. citeturn35view0turn33search11

Ustawa przewiduje też kary pieniężne. Z przytoczonego tekstu wynika m.in., że maksymalna wysokość kary może wynosić do 10 000 zł (dla jednego z typów naruszeń) oraz do 5 000 zł (dla pozostałych wskazanych tam naruszeń, w tym związanych z deklaracją dostępności lub dostępnością BIP – zależnie od przesłanek). citeturn35view0

W praktyce przetargowej kluczowe jest, że dostępność cyfrowa – jako wymaganie prawne wobec podmiotów publicznych – powinna być „wbudowana” w cały cykl życia: od opisu potrzeb i OPZ/SWZ, przez weryfikację oferty, aż po odbiór i utrzymanie. Rządowy portal poświęcony dostępności cyfrowej zawiera zestaw praktycznych materiałów i odpowiedzi (w tym o deklaracjach i obowiązkach). gov.pl: Dostępność cyfrowa. citeturn14search22

Prawo zamówień publicznych (Pzp) z 11 września 2019 r. ma wejście w życie od 1 stycznia 2021 r. i posiada teksty ogłoszone oraz ujednolicone w oficjalnym standardzie ELI. Rekord ELI (z linkami do PDF/HTML):
eli.gov.pl: DU/2019/2019. citeturn37search0

Dla dostępności kluczowy jest art. 100 Pzp (uwzględnianie wymagań dostępności dla osób z niepełnosprawnościami i projektowania z przeznaczeniem dla wszystkich użytkowników w przypadku zamówień przeznaczonych do użytku osób fizycznych). Bardzo użyteczny jest także oficjalny komentarz UZP do art. 100 (w tym powiązania z innymi aktami).
eKomentarz UZP: art. 100 Pzp. citeturn37search8

Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731) jest polską implementacją EAA i – według informacji o wersji aktu – zaczyna obowiązywać w kluczowym zakresie od 28 czerwca 2025 r. (zgodnie z datą stosowania dyrektywy). Rekord ISAP/ELI:
ISAP: Dz.U. 2024 poz. 731. citeturn34search2turn34search10turn33search2

Standardy techniczne

WCAG 2.1 i WCAG 2.2 (W3C) – to najpowszechniej stosowane wytyczne dostępności treści WWW, publikowane jako rekomendacje W3C. WCAG 2.2 nie unieważnia WCAG 2.0/2.1, ale W3C rekomenduje stosowanie WCAG 2.2, aby „zabezpieczyć przyszłą stosowalność” działań dostępnościowych. Dokumenty W3C:
WCAG 2.1,
WCAG 2.2. citeturn34search0turn34search1

EN 301 549 – europejska norma dostępności dla produktów i usług ICT, wykorzystywana jako „język techniczny” w zamówieniach (zwłaszcza w IT). Decyzja 2021/1339 wiąże dyrektywę 2016/2102 z aktualizacją odniesienia do normy zharmonizowanej, a polskie instytucje (np. UKE) komunikują status EN 301 549 v3.2.1 (2021-03) oraz plany dalszych aktualizacji. citeturn34search3turn34search15turn5search2

Mapa wymagań: UE vs Polska vs standardy

Uwaga praktyczna: jeśli w Twoim postępowaniu „miesza się” sektor publiczny (2016/2102/ustawa z 2019 r.) oraz elementy EAA (2019/882/ustawa z 2024 r.), to warto robić matrycę zgodności: które elementy systemu/treści podpadają pod który reżim i jak to testujemy. W dalszej części wpisu pokazuję wzór takiej matrycy.

Wymagania i zapisy w zamówieniach publicznych

Od „hasła WCAG” do mierzalnych wymagań

Art. 100 Pzp wprowadza ogólną regułę, że w przypadku zamówień przeznaczonych do użytku osób fizycznych (w tym pracowników zamawiającego) opis przedmiotu zamówienia należy sporządzić z uwzględnieniem wymagań dostępności dla osób z niepełnosprawnościami i projektowania z przeznaczeniem dla wszystkich użytkowników. Jednocześnie Pzp nie daje jednego „checklistowego” przepisu – ciężar operacjonalizacji (co to znaczy w danym zamówieniu) spoczywa na zamawiającym. citeturn37search8turn37search16

Dlatego w praktyce rekomenduje się opis dwuwarstwowy:
(1) wymaganie normatywne (np. WCAG/EN 301 549, poziom, zakres), oraz
(2) wymagania testowalne (konkretne scenariusze użycia, kryteria akceptacji, definicje „usterki krytycznej”, wymagane raporty).
KIO wielokrotnie pokazuje, że spory rodzą się właśnie na styku „co było wymagane” vs „co i jak zamawiający sprawdził”. citeturn23view0turn18view0

Formułowanie SWZ/OPZ

Poniższe przykłady są uniwersalne (bez odniesienia do konkretnego zamówienia) i można je adaptować.
Dla przejrzystości używam roboczych nagłówków typu „OPZ”, „SWZ”, „Projekt umowy” – dostosuj do struktury dokumentacji w Twojej organizacji.

Przykład zapisu w OPZ: wymaganie dostępności (rdzeń)

<!-- OPZ: Dostępność cyfrowa (rdzeń) -->
Wykonawca zapewni, że wszystkie elementy przedmiotu zamówienia obejmujące interfejs użytkownika (WWW, aplikacja mobilna, moduły panelu administracyjnego dostępne dla użytkowników końcowych, formularze, komponenty UI, komunikaty błędów) będą spełniały wymagania dostępności cyfrowej:

a) co najmniej równoważne WCAG 2.1 na poziomie AA (w zakresie adekwatnym do funkcji),
b) zgodne z odpowiednimi wymaganiami normy EN 301 549 (w zakresie mającym zastosowanie),
c) z uwzględnieniem zasad percepcji, funkcjonalności, zrozumiałości i solidności (POUR).

Zakres wymagań dostępności obejmuje również: dokumenty elektroniczne publikowane w ramach rozwiązania (PDF/Office/HTML), treści multimedialne (napisy, audiodeskrypcja – jeśli dotyczy), oraz mechanizmy uwierzytelnienia i płatności/wniosków (jeśli dotyczy).

Dlaczego tak: WCAG to „język kryteriów sukcesu”, a EN 301 549 bywa bardziej „zamówieniowa” (szczególnie przy zakupach ICT) i jest powiązana z reżimem prawnym dyrektywy 2016/2102 poprzez decyzje Komisji aktualizujące normę zharmonizowaną. citeturn34search0turn34search3turn34search15

Przykład zapisu w SWZ: sposób weryfikacji

<!-- SWZ: Weryfikacja dostępności -->
Zamawiający uzna wymaganie dostępności za spełnione, jeżeli Wykonawca:
1) dostarczy raport z audytu dostępności (ekspercki + test klawiaturą + test czytnikiem ekranu) dla kluczowych ścieżek użytkownika,
2) dostarczy listę wykrytych niezgodności z klasyfikacją ważności (krytyczna/poważna/średnia/niska) oraz plan ich usunięcia,
3) usunie wszystkie niezgodności krytyczne i poważne przed odbiorem końcowym,
4) przedstawi wyniki testów regresji dostępności po poprawkach,
5) przekaże instrukcję redakcyjną dot. publikowania treści (w tym dostępnych PDF/załączników) oraz przeszkoli wskazanych redaktorów.

Uzasadnienie: praktyka KIO pokazuje, że sama deklaracja „zgodności z WCAG” bez klarownego sposobu wykazania zgodności może być niewystarczająca, a spór przesuwa się na interpretację (co dokładnie było wymagane, w jakiej formie i na jakiej próbce). citeturn23view0turn18view0

Kryteria oceny ofert: przykłady punktowe

Dostępność można uwzględnić w kryteriach jakościowych, o ile są związane z przedmiotem zamówienia i mierzalne. Dobrym wzorcem są kryteria oparte o: jakość planu zapewnienia dostępności, dojrzałość procesu testów, proponowane usprawnienia, oraz konkretne artefakty (np. próbka interfejsu lub raport z audytu podobnego rozwiązania).

W sprawie KIO 2493/24 (dot. prac rozwojowych przy Praca.gov.pl) w dokumentacji pojawiają się elementy kryterium punktowego, które wprost odnoszą się do usprawnień, w tym poprawy dostępności cyfrowej w odniesieniu do wytycznych WCAG 2.1 – jako jeden z typów usprawnień możliwych do zaproponowania. To dobry przykład, że WCAG może być osadzona w kryterium jakościowym (nie tylko jako wymóg „0/1”). citeturn29view0turn28view0

Przykład kryterium: „Plan zapewnienia dostępności” (max 20 pkt)

<!-- Kryterium jakościowe (przykład) -->
Kryterium K1: Plan zapewnienia dostępności (max 20 pkt)

Ocena wg skali:

0 pkt – brak planu / opis ogólnikowy („wdrożymy WCAG”).
5 pkt – plan zawiera listę standardów i ogólny opis testów (bez scenariuszy i ról).
10 pkt – plan zawiera: role (UX/dev/QA), narzędzia, minimalny zakres testów manualnych i automatycznych, harmonogram testów w sprincie.
15 pkt – jak wyżej + scenariusze testowe dla kluczowych ścieżek, definicje błędów krytycznych, procedura regresji dostępności.
20 pkt – jak wyżej + plan testów z użytkownikami ze szczególnymi potrzebami (min. 5 osób) lub równoważny proces walidacji, oraz polityka utrzymania dostępności po wdrożeniu (monitoring, governance treści).

Przykład kryterium: „Próbka / demo z testami dostępności” (max 10 pkt)

<!-- Kryterium jakościowe (przykład) -->
Kryterium K2: Demo kluczowego formularza (max 10 pkt)

Wykonawca przedstawia:
- działające demo formularza (np. wnioskowego) w środowisku testowym,
- krótką notatkę, jak osiągnięto: obsługę klawiaturą, focus, etykiety, walidację błędów, kontrast, skalowanie,
- wynik testu czytnikiem ekranu dla 2 scenariuszy (np. NVDA/JAWS + Chrome/Firefox).

Punktacja:
0 pkt – brak demo lub demo nie działa
5 pkt – demo działa, podstawowa obsługa klawiaturą i focus
10 pkt – demo działa + raport z testów + brak błędów krytycznych w scenariuszach

Ostrzeżenie: KIO 223/21 pokazuje typowy punkt zapalny: jeśli zamawiający weryfikuje WCAG przez „prezentację” i w praktyce żąda demonstracji funkcjonalności, której nie da się wywieść ani z WCAG, ani z SWZ, to ryzykuje spór co do prawidłowości oceny (w tej sprawie spór dotyczył interpretacji kryterium 1.4.12 i tego, co realnie powinno być wykazane). citeturn23view0

Klauzule dostępności w umowie

Sama SWZ nie wystarczy. Żeby dostępność przetrwała „po przecinku” (po wdrożeniu), warto uregulować ją jako:
(a) wymóg rezultatu (zgodność), (b) proces (testy, audyty, regresje), oraz (c) odpowiedzialność (SLA na poprawki dostępności, kary umowne, mechanizm odbioru).

Przykładowe postanowienia umowne

<!-- Projekt umowy: Dostępność cyfrowa -->

1. Wykonawca oświadcza i gwarantuje, że dostarczone rozwiązanie będzie spełniać wymagania dostępności cyfrowej określone w OPZ/SWZ, w szczególności w zakresie WCAG 2.1 (AA) / EN 301 549 – w zakresie mającym zastosowanie do przedmiotu umowy.

2. Odbiór końcowy zostanie dokonany po spełnieniu łącznie warunków:
   a) brak niezgodności krytycznych i poważnych w raporcie audytu dostępności,
   b) przekazanie raportu z audytu oraz listy poprawek,
   c) pozytywny wynik testów regresji dostępności.

3. W okresie gwarancji/utrzymania Wykonawca usuwa niezgodności dostępnościowe w terminach:
   - krytyczne: do 5 dni roboczych,
   - poważne: do 10 dni roboczych,
   - pozostałe: w ramach najbliższego wydania, nie później niż 30 dni.

4. Za niedotrzymanie terminów usunięcia niezgodności krytycznych/poważnych Zamawiający może naliczyć karę umowną w wysokości ... zł za każdy dzień opóźnienia (lub ...% wynagrodzenia), niezależnie od innych uprawnień.

5. Wykonawca zapewni szkolenie redaktorów/administratorów z zasad tworzenia dostępnych treści (w tym dokumentów PDF/Office) i przekaże „Instrukcję redakcyjną dostępności”.

Uzupełnieniem są oficjalne (rządowe) materiały dotyczące tego, jak zadbać o dostępność cyfrową w umowach i zamówieniach publicznych – warto je cytować lub adaptować jako „wzorzec” argumentacji i struktury wymagań. citeturn4search8turn4search12

Praktyka i odbiór

Proces zamówienia z uwzględnieniem dostępności

Poniższy diagram (Mermaid) pokazuje, jak „wpleść” wymagania dostępności w klasyczny cykl zamówienia IT.
W WordPressie do renderowania diagramu może być potrzebna wtyczka obsługująca Mermaid.

flowchart TD
A[Analiza potrzeb i użytkowników] --> B[Matryca wymagań dostępności
WCAG/EN 301 549 + scenariusze]
B --> C[OPZ/SWZ: wymagania + sposób weryfikacji]
C --> D[Kryteria oceny: jakość planu dostępności / demo / testy]
D --> E[Realizacja: UX + dev + QA z testami dostępności w sprincie]
E --> F[Odbiór: audyt + regresja + poprawki]
F --> G[Wdrożenie: deklaracja/raport + szkolenie redaktorów]
G --> H[Utrzymanie: monitoring, zgłoszenia, SLA na poprawki]

Kluczowa zasada: jeśli dostępność nie zostanie „przypięta” do weryfikowalnych artefaktów (raport, demo, testy), to ryzyko rozlewa się na odbiór i spór umowny (bo dopiero wtedy wychodzą realne bariery). KIO 223/21 dobrze ilustruje problem „czy zamawiający wymagał tego, co sprawdził” w prezentacji zgodności z WCAG. citeturn23view0

Studia przypadków: dobre praktyki i typowe uchybienia

Dobra praktyka

Przypadek: kryterium jakościowe premiujące usprawnienia, w tym dostępność (WCAG 2.1). W dokumentacji zamówienia dla Praca.gov.pl (KIO 2493/24) pojawia się element punktowania, w którym proponowane usprawnienia mogą obejmować m.in. poprawę dostępności cyfrowej zgodnie z WCAG 2.1. To podejście ma dwie zalety: (1) dostępność przestaje być tylko „minimum formalnym”, (2) daje wykonawcom przestrzeń do zaproponowania wartości dodanej (o ile kryterium jest jasno opisane). citeturn29view0turn28view0

Typowe uchybienia

Uchybienie: nadinterpretacja wymagań WCAG / SWZ w prezentacji. W KIO 223/21 spór dotyczył tego, czy zamawiający zasadnie uznał, że wykonawca nie wykazał spełnienia kryterium 1.4.12 („Odstępy w tekście”) w WCAG 2.1 AA – wykonawca argumentował, że wymagana przez zamawiającego funkcjonalność nie wynika ani z WCAG, ani z SIWZ. Niezależnie od rozstrzygnięcia, to klasyczny „antywzorzec”: jeśli weryfikacja jest oparta o nieprecyzyjne oczekiwania, może prowadzić do zarzutów nierównego traktowania lub błędnej oceny. citeturn23view0

Uchybienie: „zgodność z ustawą/WCAG” jako gołe oświadczenie bez dowodów. W sprawie KIO 3295/20 (LMS dla UJ) w uzasadnieniu pojawiają się odwołania do standardów dostępności i do ustawy o dostępności cyfrowej jako podstawy wymagań; takie spory często pokazują, że oświadczenie wykonawcy powinno być „dociążone” dowodowo – np. raportem z audytu, opisem testów lub funkcjonalnym demo. citeturn18view0

Co sprawdzać w odbiorze

W odbiorze warto odróżnić: (1) usterki blokujące dostęp (krytyczne i poważne), (2) usterki „komfortu użycia” (średnie i niskie), oraz (3) ryzyka procesowe (brak dokumentacji, brak instrukcji redakcyjnej, brak regresji). Poniższa lista to praktyczne minimum.

flowchart TD
S[Start odbioru] --> P[Sprawdź: zakres odbioru i listę ścieżek krytycznych]
P --> A[Automaty: kontrast, nagłówki, etykiety formularzy, aria]
A --> M[Testy manualne: klawiatura, focus, widoczność, błędy]
M --> R[Testy czytnikiem ekranu: 2-3 kluczowe scenariusze]
R --> D[Dokumenty: PDF/Office/HTML, alternatywy tekstowe]
D --> V[Raport audytu + klasyfikacja usterek + plan poprawek]
V --> F[Poprawki + testy regresji]
F --> O{Brak usterek krytycznych/poważnych?}
O -->|Nie| F
O -->|Tak| K[Odbiór końcowy + instrukcja redakcyjna + szkolenie]
K --> E[End]

Jeśli chcesz wersję edytowalną powyższej tabeli (np. do wklejenia do Twojej procedury odbiorowej), poproś w komentarzu – przygotuję układ nadający się do Excela/Sheets.

Orzecznictwo i interpretacje

Poniżej zestawiam przykłady orzeczeń istotnych dla praktyki zamówień IT z komponentem dostępności. Koncentruję się na sprawach, w których pojawiają się: WCAG/standardy dostępności, sposób weryfikacji (prezentacje/dowody), oraz ocena kryteriów jakościowych.

Orzecznictwo KIO: dostępność jako wymóg lub punkt sporu

Orzecznictwo sądów administracyjnych: dostęp jako „realna możliwość skorzystania”

Orzecznictwo WSA/NSA dotyczące wprost ustawy o dostępności cyfrowej jest trudniejsze do systematycznego przywołania w otwartych bazach (część treści jest rozproszona), ale warto pamiętać o ogólnej linii w sprawach „dostępu” realizowanego środkami elektronicznymi: udostępnienie informacji publicznej ma następować w sposób i formie zgodnych z wnioskiem, chyba że ograniczają to możliwości techniczne. W kontekście dostępności cyfrowej to argument za zapewnianiem formatów, które są używalne (a nie wyłącznie formalnie opublikowane). citeturn32search22

Dodatkowo, sama ustawa o dostępności cyfrowej buduje tryb skargowy (wniosek o zapewnienie dostępności), wymagając m.in. reakcji i zapewnienia dostępności w określonych ramach czasowych, co wzmacnia praktyczną wykonalność praw użytkowników. citeturn8search16turn35view0

Checklisty i wzory zapisów

Checklisty dla zamawiających

Checklist: przygotowanie postępowania

• Określ, czy przedmiot zamówienia jest „dla osób fizycznych” (obywatele, pracownicy) – wtedy art. 100 Pzp będzie praktycznie zawsze relewantny. citeturn37search8
• Zdefiniuj krytyczne ścieżki użytkownika (np. logowanie, złożenie wniosku, płatność, pobranie decyzji, kontakt, wyszukiwarka).
• Stwórz matrycę wymagań: WCAG/EN 301 549 + scenariusze testowe + wymagane dowody (audyt/demonstracja/raport).
• Wpisz dostępność do umowy (odbiór, SLA na poprawki, regresje, szkolenia redaktorów).

Checklist: ocena ofert

• Sprawdź kompletność dowodów: czy wykonawca dostarcza mierzalne artefakty (demo/raport/plan testów), a nie tylko oświadczenia. citeturn18view0turn23view0
• Jeśli kryterium dotyczy koncepcji/usprawnień, upewnij się, że zasady oceny są jednoznaczne i nie premiują wyłącznie wykonawcy „historycznego” (ryzyko zarzutów o nieproporcjonalność i niejednoznaczność opisu). citeturn28view0turn31view0
• Unikaj weryfikacji „dopowiadanej w trakcie” – w KIO 223/21 widać, że spór często dotyczy tego, czy zamawiający ocenił to, co opisał w SWZ. citeturn23view0

Wzory zapisów do wklejenia

Wzór: „Definicje błędów dostępności”

<!-- Definicje do SWZ/umowy -->
Niezgodność krytyczna – wada dostępności, która uniemożliwia użytkownikowi wykonanie kluczowej czynności (np. złożenie wniosku) bez alternatywnego sposobu, szczególnie przy użyciu klawiatury lub czytnika ekranu.

Niezgodność poważna – wada znacząco utrudniająca wykonanie czynności lub powodująca istotne ryzyko błędnego działania (np. brak powiązania etykiety z polem formularza, nieczytelne komunikaty błędów, brak widocznego fokusu).

Niezgodność średnia/niska – wada wpływająca na komfort lub poprawę jakości (np. drobne niespójności nagłówków, brak ujednoliconych skrótów, pojedyncze braki alternatyw tekstowych w dekoracjach).

Wzór: „Warunek odbioru”

<!-- Odbiór (model) -->
Odbiór końcowy nastąpi po:
1) usunięciu wszystkich niezgodności krytycznych i poważnych wskazanych w raporcie audytu,
2) potwierdzeniu w teście regresji dostępności, że poprawki nie spowodowały nowych barier,
3) przekazaniu Zamawiającemu zestawu zaleceń redakcyjnych i przeszkoleniu redaktorów.

Wzór: „Zobowiązanie do utrzymania dostępności”

<!-- Utrzymanie (SLA) -->
Wykonawca zobowiązuje się do utrzymania poziomu dostępności rozwiązania w trakcie trwania umowy utrzymaniowej, w tym do:
- wykonywania testów regresji dostępności przy każdej zmianie interfejsu,
- usuwania błędów dostępności w terminach SLA,
- konsultowania zmian wpływających na dostępność z Zamawiającym.

Jeśli potrzebujesz „paczek” gotowych zapisów w formie pliku (DOCX) dla SWZ/OPZ/umowy, da się to przygotować na bazie powyższych wzorów – bez potrzeby doprecyzowania danych konkretnego zamówienia.

Ryzyka, sankcje i rekomendacje

Ryzyka dla zamawiających

Ryzyko odwołań (KIO) i opóźnień – im bardziej dostępność jest weryfikowana „uznaniowo” (prezentacja bez jasno opisanych kryteriów), tym większe ryzyko sporu o prawidłowość oceny, co widać m.in. w KIO 223/21. citeturn23view0

Ryzyko „vendor lock-in” przez dokumentację – jeżeli kryteria jakościowe wymagają wiedzy o istniejącym systemie lub zbyt szczegółowych informacji, których realnie nie da się uzyskać bez bycia dotychczasowym wykonawcą, rośnie ryzyko zarzutu nieproporcjonalności/niejednoznaczności (motyw widoczny w sporach wokół koncepcji i jej oceny w KIO 2493/24 i KIO 3698/24). citeturn28view0turn31view0

Ryzyko naruszeń ustawy o dostępności cyfrowej – brak poprawy dostępności może uruchomić konsekwencje monitoringu i sporów w trybie skargowym. Ustawa przewiduje również kary pieniężne, których maksymalne wartości (do 10 000 zł oraz do 5 000 zł – zależnie od typu naruszenia) wynikają wprost z jej treści. citeturn35view0

Ryzyka dla wykonawców

Ryzyko niedoszacowania – jeśli SWZ mówi „WCAG 2.1 AA”, ale nie precyzuje zakresu lub weryfikacji, wykonawca powinien w ofercie przyjąć konserwatywne założenia (audyt, poprawki, regresja, szkolenia). W przeciwnym razie grożą spory w odbiorze i kary umowne (jeżeli zostaną wprowadzone). Orzeczenia pokazują, że temat WCAG bywa wprost przywoływany jako obszar iteracyjnych weryfikacji. citeturn23view0turn18view0turn21search0

Sankcje i tryb skargowy w dostępności cyfrowej

Ustawa o dostępności cyfrowej przewiduje procedurę wniosku o zapewnienie dostępności cyfrowej. Z opisu tej procedury w materiałach rządowych wynika m.in., że podmiot publiczny powinien zrealizować żądanie bez zbędnej zwłoki, nie później niż w ciągu 7 dni, a jeśli to niemożliwe – wskazać termin realizacji, nie dłuższy niż 2 miesiące, oraz (gdy nie może zapewnić dostępności) zaproponować alternatywny sposób dostępu. citeturn8search16turn35view0

W tle jest też standardyzacja unijna: decyzje Komisji wiążą reżim dostępności sektora publicznego z normą zharmonizowaną (EN 301 549), co ułatwia budowanie testowalnych wymagań w SWZ/OPZ. citeturn34search3turn34search15

Rekomendacje końcowe

Dla zamawiających: buduj wymagania dostępności jak wymagania bezpieczeństwa – jako „system” (standard + testy + odbiór + utrzymanie), a nie jako jedno zdanie w OPZ. W kryteriach jakościowych premiuj dojrzały proces zapewnienia dostępności i realne usprawnienia, ale unikaj kryteriów, które wymagają wiedzy dostępnej wyłącznie incumbentowi. citeturn37search8turn28view0turn31view0

Dla wykonawców: nie ograniczaj się do deklaracji „zgodne z WCAG”. Włącz do oferty: plan testów dostępności, przykładowe scenariusze, opis narzędzi, oraz (jeśli to możliwe) dowody z wcześniejszych projektów (raport audytu, metodyka). W3C rekomenduje stosowanie aktualnej wersji WCAG (dziś: 2.2) jako bardziej przyszłościowej, co można potraktować jako przewagę jakościową, nawet jeśli prawo bazowe odwołuje się do starszego poziomu. citeturn34search1turn34search9turn34search0

Bibliografia i przydatne linki

Bibliografia i źródła

• Dyrektywa 2014/24/UE – EUR-Lex: 32014L0024. citeturn33search0turn33search7
• Dyrektywa (UE) 2016/2102 – EUR-Lex. citeturn33search8turn33search11
• Decyzja wykonawcza Komisji (UE) 2021/1339 – EUR-Lex: 32021D1339. citeturn34search3turn34search15
• Dyrektywa (UE) 2019/882 (EAA) – EUR-Lex. citeturn33search2turn33search6
• Ustawa z 4.04.2019 r. o dostępności cyfrowej… (Dz.U. 2019 poz. 848) – PDF Dz.U.. citeturn35view0
• Prawo zamówień publicznych (Pzp) – rekord ELI: eli.gov.pl. citeturn37search0
• UZP eKomentarz do art. 100 Pzp – ekomentarzpzp.uzp.gov.pl. citeturn37search8
• Ustawa z 26.04.2024 r. o zapewnianiu spełniania wymagań dostępności… (Dz.U. 2024 poz. 731) – ISAP. citeturn34search2turn34search10
• WCAG 2.1 – W3C. citeturn34search0
• WCAG 2.2 – W3C. citeturn34search1turn34search9
• Orzeczenia KIO: KIO 223/21, KIO 3295/20, KIO 2493/24, KIO 3698/24 – baza orzeczeń UZP. citeturn23view0turn18view0turn28view0turn31view0

Przydatne linki

• Portal rządowy o dostępności cyfrowej: gov.pl/web/dostepnosc-cyfrowa. citeturn14search22
• Wniosek o zapewnienie dostępności cyfrowej (opis procedury): gov.pl (procedura). citeturn8search16
• Wyszukiwarka orzeczeń (KIO/SO) UZP: orzeczenia.uzp.gov.pl. citeturn16search0
• W3C – standardy i zalecenia dostępności: w3.org/WAI. citeturn34search13
• EUR-Lex – akty prawne UE: eur-lex.europa.eu. citeturn33search12