Dostępność cyfrowa w zamówieniach: jak opisać wymagania dla wykonawcy

Po co w ogóle wpisywać dostępność cyfrową do zamówienia?

Jakiego efektu naprawdę oczekujesz od dostępności?

Zadaj sobie pytanie: czy Twoim celem jest tylko „zgodność z prawem”, czy realne ułatwienie życia ludziom, którzy korzystają z Twoich usług? Od odpowiedzi zależy sposób, w jaki opiszesz wymagania dostępności cyfrowej w zamówieniu. Jeśli ograniczysz się do hasła „zgodność z WCAG”, wykonawca najpewniej dostarczy Ci coś, co przejdzie powierzchowny test, ale niekoniecznie będzie wygodne dla użytkowników z niepełnosprawnościami.

Jeśli chcesz rzeczywistej poprawy, potrzebujesz dwóch poziomów wymagań: formalnego (odniesienie do ustawy o dostępności cyfrowej i WCAG) oraz praktycznego (konkretne scenariusze, które mają być możliwe do wykonania przez osoby z różnymi ograniczeniami). Oba te poziomy muszą znaleźć się w opisie przedmiotu zamówienia (OPZ), w kryteriach oceny ofert oraz w sposobie odbioru.

Warto zapytać samego siebie: kto w Twojej jednostce faktycznie korzysta z serwisu, BIP czy systemu? Czy masz użytkowników niewidomych, słabowidzących, głuchych, osoby starsze, pracowników korzystających z czytników ekranu? Ich potrzeby powinny być punktem wyjścia. Zamiast ogólnej formułki „ma być dostępne”, opisz, co te osoby mają być w stanie zrobić bez pomocy innych.

Deklarowana a realna dostępność – dwie zupełnie różne rzeczy

Wielu zamawiających ma już za sobą doświadczenie, w którym wykonawca dostarczył system „zgodny z WCAG”, a potem okazało się, że niewidomy użytkownik nie jest w stanie wysłać formularza, a osoba słabowidząca nie może przeczytać treści po powiększeniu. Powód? System był „zgodny” na papierze, ale nieprzetestowany na prawdziwych użytkownikach lub zweryfikowany jedynie automatycznymi narzędziami.

Różnica między deklarowaną a realną dostępnością wynika najczęściej z tego, jak zapisane są wymagania. Hasło „zgodność z WCAG 2.1 AA” bez doprecyzowania sposobu realizacji i weryfikacji prowadzi do sytuacji, w której:

• wykonawca stosuje jedynie minimalne poprawki „pod certyfikat” lub raport automatyczny,
• brakuje testów na realnych scenariuszach użytkowania,
• brakuje sankcji i konkretnych warunków odbioru za brak dostępności.

Dlatego opis wymagań dostępności w zamówieniu musi zawierać nie tylko standard, ale też sposób weryfikacji i przykłady użycia. Bez tego w praktyce kupujesz obietnicę, a nie działające rozwiązanie.

Co zmienia ustawa o dostępności cyfrowej i PZP?

Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych oraz przepisy Prawa zamówień publicznych wprost mówią o obowiązku uwzględniania dostępności w opisie przedmiotu zamówienia. To oznacza, że wymagania dostępności w zamówieniach publicznych nie są „opcją”, tylko obowiązkiem, jeśli przedmiot zamówienia wchodzi w zakres ustawy (np. serwisy WWW, BIP, aplikacje mobilne, dokumenty publikowane w sieci).

Konsekwencje są bardzo praktyczne:

• OPZ musi zawierać jasne zapisy dotyczące dostępności cyfrowej,
• kryteria oceny ofert oraz warunki realizacji mogą i powinny odnosić się do dostępności,
• umowa powinna opisywać obowiązek utrzymania dostępności w czasie trwania umowy,
• odbiór i testy muszą sprawdzać spełnienie wymagań dostępności – inaczej trudno będzie formalnie odmówić odbioru.

Jeśli teraz zastanawiasz się: „czy wystarczy wkleić do OPZ jedno zdanie o WCAG?”, odpowiedź brzmi: nie. Musisz pokazać, jak to jedno zdanie ma się przełożyć na konkretny wygląd, funkcjonowanie i sposób testowania systemu.

Skutki zignorowania dostępności w zamówieniu

Brak zapisów o dostępności w zamówieniu, albo ich szczątkowa forma, może mieć kilka konsekwencji. Czasem nie widać ich od razu, ale wracają po kilku miesiącach z dużo większą siłą. Jakie sytuacje pojawiają się w praktyce?

• Skargi użytkowników – osoba niewidoma nie może złożyć wniosku online, więc zgłasza sprawę do przełożonego, RPO lub mediów.
• Kosztowne poprawki – brak wymagań dostępności w OPZ utrudnia egzekwowanie poprawek od wykonawcy w ramach gwarancji. Efekt: poprawki trzeba zlecać w osobnym zamówieniu.
• Ryzyko naruszenia ustawy o dostępności cyfrowej – audyty, raporty i kontrole mogą wykazać brak zapewnienia dostępności, co rodzi obowiązek usunięcia naruszeń i negatywną ocenę instytucji.
• Utrata zaufania – jeśli instytucja publiczna deklaruje otwartość i równe traktowanie, a serwis jest nieużywalny dla części użytkowników, reputacja cierpi bardziej niż w przypadku „zwykłej” usterki technicznej.

Zadaj sobie kolejne pytanie: co będzie tańsze i prostsze – porządne opisanie dostępności w zamówieniu, czy późniejsze „łatanie” systemu bez jasnych roszczeń wobec wykonawcy? Zwykle odpowiedź jest oczywista.

Kiedy włączać wymagania dostępności w proces zamówienia?

Wiele jednostek przypomina sobie o dostępności dopiero na etapie odbioru. Wtedy pojawia się zdanie: „przecież to miało być dostępne…”, a wykonawca odpowiada: „nie było tego w OPZ”. Aby tego uniknąć, wymagania dostępności cyfrowej trzeba włączyć już na etapie analizy potrzeb i planowania zamówienia.

W praktyce oznacza to, że przed przygotowaniem OPZ warto odpowiedzieć sobie na kilka pytań:

• Jakie typy użytkowników będą korzystać z rozwiązania (w tym osoby z niepełnosprawnościami)?
• Jakie kluczowe czynności muszą być dostępne (złożenie wniosku, odczytanie ogłoszenia, sprawdzenie statusu sprawy)?
• Czy masz wewnętrzne procedury lub osoby odpowiedzialne za dostępność cyfrową?
• Jak zamierzasz odbierać i testować dostępność – czy potrzebujesz zewnętrznego eksperta, czy wykorzystasz osoby z niepełnosprawnościami?

Im wcześniej postawisz te pytania, tym łatwiej będzie wpisać sensowne, mierzalne wymagania do opisu przedmiotu zamówienia, a potem rzetelnie je egzekwować.

Podstawa prawna i standardy – co jest obowiązkowe, a co „tylko” dobre

Najważniejsze akty i normy, które wpływają na zamówienia

Żeby świadomie opisać wymagania dostępności cyfrowej dla wykonawcy, potrzebujesz krótkiego porządkowania prawnego. Jakie regulacje mają dla Ciebie znaczenie?

• Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych – określa obowiązki podmiotów publicznych w zakresie dostępności cyfrowej serwisów WWW, BIP i aplikacji mobilnych.
• Prawo zamówień publicznych (PZP) – nakazuje uwzględnianie wymagań dostępności w opisie przedmiotu zamówienia, jeśli dotyczy to użytkowników, w tym osób z niepełnosprawnościami.
• Norma EN 301 549 – europejski standard dostępności ICT, do którego odwołują się przepisy i wytyczne; zawiera szczegółowe wymagania dla różnych typów produktów i usług cyfrowych.
• Wytyczne WCAG (Web Content Accessibility Guidelines) – najczęściej stosowany standard techniczny, który szczegółowo opisuje, jak zapewnić dostępność treści internetowych na poziomie A, AA i AAA.

Pytanie, które często pojawia się w głowie zamawiającego: czy musisz znać wszystkie te dokumenty na wylot? Nie. Potrzebujesz jednak wiedzieć, na co się powołać w zamówieniu i gdzie szukać pomocy przy doprecyzowaniu wymagań.

Co znaczy „zgodność z WCAG 2.1 AA” w praktyce

Określenie „zgodność z WCAG 2.1 na poziomie AA” jest powszechnie używane w zamówieniach na dostępność cyfrową BIP i WWW. Problem w tym, że bez dodatkowych wyjaśnień bywa rozumiane bardzo różnie. Tymczasem WCAG to zestaw kryteriów sukcesu, które mówią, co ma być możliwe dla użytkownika, a nie zawsze dokładnie jak to zrealizować technicznie.

W praktyce „zgodność z WCAG 2.1 AA” oznacza między innymi, że:

• treści są postrzegalne również dla osób korzystających z czytników ekranu (struktura nagłówków, opisy alternatywne, etykiety formularzy),
• interfejs jest obsługiwalny z klawiatury (nawigacja, focus, brak „pułapek klawiaturowych”),
• treść jest zrozumiała (jasny język, logiczna nawigacja, spójne etykiety, przewidywalne zachowanie),
• rozwiązanie jest solidne (poprawny kod, kompatybilność z technologiami asystującymi).

Sama deklaracja zgodności nie wystarczy. W opisie wymagań najlepiej połączyć powołanie na WCAG z listą kluczowych obszarów, które będą weryfikowane przy odbiorze. Dzięki temu wykonawca dokładniej wie, czego się spodziewasz, a Ty masz konkretną podstawę do oceny.

Gdzie szukać aktualnych wymagań i interpretacji

Przepisy i standardy bywają aktualizowane, a interpretacje – doprecyzowywane. Jeśli przygotowujesz większe zamówienie i masz wątpliwości, z kim możesz skonsultować wymagania?

• komórka lub pełnomocnik ds. dostępności w Twojej instytucji, jeśli został powołany,
• krajowe instytucje odpowiedzialne za nadzór nad dostępnością cyfrową (np. wytyczne, publikacje, wzory zapisów),
• organizacje pozarządowe zajmujące się dostępnością cyfrową,
• zewnętrzni eksperci/audytorzy dostępności, którzy mogą pomóc sformułować i zweryfikować wymagania.

Warto też zadać sobie pytanie: czy masz w jednostce choć jedną osobę, która „trzyma” temat dostępności cyfrowej? Jeśli nie, dobrze rozważyć stałe wsparcie eksperta przy kluczowych zamówieniach – najlepiej jeszcze przed ogłoszeniem przetargu.

Kiedy można wymagać więcej niż minimum (np. AAA lub wymagania specjalne)

Ustawa o dostępności cyfrowej określa minimalny poziom, który musisz zapewnić. Jednak jako zamawiający możesz postawić wyższe wymagania, jeśli jest to uzasadnione potrzebami użytkowników lub specyfiką usługi. Przykładowe sytuacje:

• system jest przeznaczony w szczególności dla osób niewidomych lub niesłyszących – możesz wymagać rozwiązań wykraczających poza standard WCAG AA,
• aplikacja mobilna pełni kluczową rolę w komunikacji z obywatelami – rozsądne jest wymaganie wysokiej jakości dostępności również w aplikacjach natywnych,
• serwis będzie intensywnie używany na urządzeniach mobilnych przez osoby starsze – możesz dodać wymagania dotyczące rozmiaru interaktywnych elementów, kontrastu, trybu wysokiego kontrastu.

Jeśli zastanawiasz się, czy używać poziomu AAA, odpowiedź jest zwykle ostrożna: lepiej dobrze egzekwować AA, a wybrane elementy AAA wpisać jako dodatkowe wymagania funkcjonalne, niż zadeklarować pełne AAA i nie być w stanie tego skontrolować.

Czy musisz znać WCAG na pamięć?

Nie musisz znać na pamięć wszystkich kryteriów sukcesu WCAG. Jako zamawiający potrzebujesz czego innego: świadomości, jakie efekty chcesz osiągnąć i jak opisać je w języku zamówienia. Szczegóły techniczne może doprecyzować ekspert lub sam wykonawca, o ile jasno wskażesz wymagany standard i sposób odbioru.

Praktyczne podejście wygląda tak:

• na poziomie OPZ opisujesz, jakie działania ma móc wykonać użytkownik z niepełnosprawnością,
• odwołujesz się do WCAG 2.1 AA jako standardu technicznego,
• dodajesz wymagania dotyczące audytu i testów z użytkownikami,
• w umowie zapisujesz obowiązek usunięcia wykrytych niezgodności z WCAG w określonym czasie.

Pytanie do Ciebie: czy w Twojej instytucji ktoś już pracował z WCAG i ma doświadczenia z wcześniejszych zamówień? Jeśli tak, dobrze wykorzystać te doświadczenia – zarówno pozytywne, jak i te „bolesne”.

Jak przełożyć WCAG i ustawę na język opisu przedmiotu zamówienia (OPZ)

Jakie typy zamówień obejmuje ustawa o dostępności cyfrowej?

Zanim zaczniesz pisać OPZ, zrób krótką listę: co konkretnie kupujesz? Inne wymagania wpiszesz dla serwisu informacyjnego, inne dla wewnętrznego systemu kadrowego, a jeszcze inne dla aplikacji mobilnej czy usługi utrzymania treści.

Typowe zamówienia związane z dostępnością cyfrową to:

• nowa strona WWW urzędu lub jednostki,
• ulepszenie lub przebudowa Biuletynu Informacji Publicznej (BIP),
• systemy wewnętrzne (np. e-naboru, obiegu dokumentów, e-learning),
• aplikacje mobilne (np. informator miejski, aplikacja do zgłaszania usterek),

Jak uwzględnić usługi powiązane: utrzymanie, rozwój, treści

Przy wielu zamówieniach nie kupujesz tylko „produktu” (strony czy systemu), lecz również usługi: utrzymania, rozwoju, tworzenia treści. Każdy z tych elementów ma swoją część odpowiedzialności za dostępność. Masz to rozpisane w OPZ?

Przyjrzyj się najczęstszym usługom:

• utrzymanie i rozwój serwisu WWW/BIP – wykonywanie zmian technicznych, poprawek, nowych modułów,
• administracja i wsparcie redaktorów – nadawanie uprawnień, konsultacje, konfiguracja systemu,
• tworzenie i aktualizacja treści – artykuły, pliki PDF, grafiki, multimedia,
• szkolenia dla pracowników – obsługa systemu, w tym w kontekście dostępności.

Jeśli wykonawca będzie robił „wszystko”, dostępność musi przewijać się w każdej części zakresu. Jeżeli część zadań realizuje Twoja jednostka (np. redagowanie treści), zapisz to wprost – inaczej wykonawca może być niesłusznie rozliczany z nieprzygotowanych plików PDF czy skanów.

Proste pytanie kontrolne: kto fizycznie będzie klikał „opublikuj”? Ten ktoś musi wiedzieć, jak to robić w sposób dostępny – inaczej najlepszy system nie pomoże.

Konkretny zapis odwołujący się do WCAG i norm

Ogólny zapis typu „strona ma być dostępna” niczego nie załatwia. Potrzebny jest konkretny, jednoznaczny punkt odniesienia. Jak może brzmieć taki fragment OPZ?

Przykładowy szkielet zapisu:

• „Wykonawca zobowiązuje się zapewnić, że realizowany serwis internetowy będzie zgodny z wymaganiami ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych oraz z Wytycznymi dla dostępności treści internetowych (WCAG) w wersji 2.1 na poziomie co najmniej AA”.
• „W przypadku rozbieżności pomiędzy zapisami ustawy a normą EN 301 549 lub WCAG, za wiążące przyjmuje się wymagania wyższe (bardziej korzystne dla dostępności)”.
• „Wymagania dostępności dotyczą zarówno interfejsu użytkownika, jak i treści udostępnianych za pośrednictwem systemu (w tym plików do pobrania, formularzy elektronicznych, materiałów multimedialnych) w zakresie, w jakim są przygotowywane przez Wykonawcę”.

Możesz zadać sobie pytanie: czy ten zapis jest dla wykonawcy jasny bez dodatkowego komentarza? Jeśli nie, dodaj kolejne punkty precyzujące zakres i sposób weryfikacji.

Jak doprecyzować zakres: co dokładnie ma być „dostępne”

Spory przy odbiorze najczęściej biorą się z tego, że strony nie ustaliły, co wchodzi w zakres dostępności. Ty myślisz o całym serwisie, wykonawca – tylko o szablonie graficznym i kodzie. Jak tego uniknąć?

Przy każdym typie zamówienia zrób krótką listę obszarów, które mają spełniać wymagania dostępności. Na przykład:

• strona WWW/BIP:
  • szablony i komponenty interfejsu (nawigacja, menu, wyszukiwarka, formularze),
  • wdrożony system zarządzania treścią (CMS) wraz z panelami administracyjnymi, o ile będą wykorzystywane przez pracowników z niepełnosprawnościami,
  • przykładowe treści startowe przygotowane przez wykonawcę (np. 10–20 reprezentatywnych podstron),
  • moduły dodatkowe (np. mapy, kalendarze, rejestry).
• system wewnętrzny:
  • ekrany używane codziennie przez większość pracowników (dashboard, lista spraw, podgląd dokumentu),
  • formularze dodawania/edycji danych,
  • moduły raportowe, jeśli pracują na nich osoby z niepełnosprawnościami,
  • ekrany logowania, resetu hasła, powiadomienia.
• aplikacja mobilna:
  • ekrany nawigacyjne i menu,
  • ekrany krytyczne dla głównej usługi (np. zgłoszenie sprawy, płatność),
  • powiadomienia push i treści wyświetlane w trybie offline.

Im bardziej sprecyzujesz, tym mniejsza przestrzeń na „nieporozumienia interpretacyjne”. Zastanów się: czy wykonawca mógłby z Twojego opisu wyłączyć jakąś część systemu z wymagań dostępności? Jeżeli tak – dopisz ją wprost.

Opis efektu, nie tylko technologii

WCAG i normy są potrzebne, ale użytkownika nie interesuje, jakie kryterium sukcesu zostało spełnione, tylko czy może załatwić sprawę. Dlatego w OPZ obok odwołań do standardów dobrze umieścić opisy rezultatów w języku biznesowym.

Jak to zrobić? Sformułuj kilka kluczowych scenariuszy użytkownika, np.:

• „Osoba niewidoma, korzystająca z czytnika ekranu, może samodzielnie złożyć wniosek X od początku do końca, bez konieczności korzystania z pomocy osoby trzeciej”.
• „Osoba słabowidząca, korzystająca z powiększenia i wysokiego kontrastu, może przeczytać wszystkie informacje o świadczeniu Y oraz wypełnić formularz zgłoszeniowy”.
• „Osoba niesłysząca ma dostęp do treści nagrań wideo publikowanych w serwisie poprzez napisy oraz, w uzasadnionych przypadkach, tłumaczenie na PJM”.

Następnie połącz te scenariusze z konkretnymi wymaganiami technicznymi („spełnienie wymogów WCAG 2.1 AA w kryteriach…”) i sposobem odbioru. Dzięki temu wykonawca rozumie, po co wdraża dane wymaganie.

Minimalny zestaw wymagań dostępności dla różnych typów zamówień

Nowa strona WWW lub przebudowa BIP

Jeżeli przygotowujesz zamówienie na nową stronę WWW lub modernizację BIP, zatrzymaj się na chwilę i odpowiedz: czy chcesz mieć tylko „zgodny szablon”, czy realnie dostępny serwis z treściami?

Minimalny zestaw wymagań może obejmować:

• Standard dostępności:
  • zgodność z WCAG 2.1 AA lub nowszą, jeśli będzie obowiązująca w dacie realizacji,
  • stosowanie semantycznego HTML, prawidłowych nagłówków, list, tabel danych,
  • zapewnienie obsługi z klawiatury wszystkich funkcji serwisu.
• Projekt graficzny i UX:
  • kontrast tekstu i elementów interaktywnych zgodny z WCAG,
  • skalowalność treści co najmniej do 200% bez utraty funkcjonalności,
  • responsywność z zachowaniem wymogów dostępności na urządzeniach mobilnych.
• System zarządzania treścią (CMS):
  • formularze edycji treści dostępne dla osób korzystających z czytników ekranu,
  • możliwość dodawania tekstów alternatywnych do obrazów,
  • mechanizmy tworzenia nagłówków, list, tabel bez konieczności ingerencji w kod HTML.
• Treści startowe:
  • wykonanie reprezentatywnego zestawu podstron i modułów zgodnie z WCAG (np. aktualności, artykuły, formularze, tablice ogłoszeń),
  • przygotowanie przykładowego szablonu dostępnego pliku PDF lub innego dokumentu do pobrania.
• Polityka dostępności i deklaracja:
  • wdrożenie strony „Deklaracja dostępności” zgodnej z wymogami ustawy,
  • przekazanie instrukcji aktualizacji deklaracji przez Twoją jednostkę.

Sprawdź: czy Twój aktualny projekt OPZ pokrywa każdy z tych obszarów, czy skupia się wyłącznie na grafice i kodzie?

Systemy wewnętrzne i e-usługi (np. e-nabór, obieg dokumentów)

Przy systemach wewnętrznych pojawia się pokusa: „to tylko dla pracowników, nie trzeba dostępności”. Tymczasem także wśród pracowników są osoby z niepełnosprawnościami, a ustawa i PZP obejmują również te rozwiązania, jeśli wpływają na możliwość wykonywania obowiązków.

Minimalny zestaw wymagań dla tego typu zamówień może obejmować:

• Interfejs użytkownika:
  • pełna obsługa z klawiatury wszystkich kluczowych procesów (logowanie, wyszukiwanie, dodawanie/edycja danych, zatwierdzanie),
  • czytelne komunikaty o błędach i podpowiedzi kontekstowe,
  • zapewnienie odpowiedniego kontrastu i czytelności w tabelach, wykazach, zestawieniach.
• Architektura informacji:
  • logiczna struktura nagłówków i regionów (np. pasków bocznych, treści głównej),
  • spójne nazewnictwo przycisków, zakładek, filtrów.
• Dostępność w procesach krytycznych:
  • np. proces podpisywania dokumentu, wysłania wniosku, akceptacji wniosku urlopowego – opisany i przetestowany z perspektywy użytkownika z niepełnosprawnością,
  • brak etapów, które wymagają wyłącznie obsługi myszą (drag&drop bez alternatywy klawiaturowej).
• Szkolenie i dokumentacja:
  • instrukcja użytkownika przygotowana w formie dostępnej (np. dokumenty zgodne z WCAG, napisy do nagrań wideo),
  • opcjonalnie warsztat dla wybranych pracowników, jak korzystać z systemu z użyciem funkcji dostępności (np. skrótów klawiaturowych).

Zadaj sobie pytanie: kto w Twojej jednostce ma największe bariery w korzystaniu z obecnych systemów? Ich potrzeby warto ująć w wymaganiach.

Aplikacje mobilne

Aplikacje mobilne podlegają ustawie i mają swoje specyficzne wyzwania: gesty, mały ekran, różne platformy. Jeśli szykujesz takie zamówienie, doprecyzuj kilka kwestii.

Minimalny zestaw wymagań dla aplikacji może obejmować:

• Standardy i platformy:
  • zgodność z WCAG 2.1 AA w zakresie odnoszącym się do aplikacji mobilnych oraz właściwymi częściami EN 301 549,
  • współpraca z wbudowanymi technologiami asystującymi (TalkBack, VoiceOver, powiększanie, wysokie kontrasty).
• Nawigacja i gesty:
  • możliwość wykonania wszystkich czynności za pomocą standardowych gestów dostępności,
  • brak wymagań korzystania wyłącznie z gestów złożonych (np. potrząśnij, narysuj kształt) bez alternatywy.
• Treści i komunikaty:
  • czytelne komunikaty o błędach i statusie działania (np. „wysłano zgłoszenie”, „błąd połączenia”),
  • zapewnienie odpowiedniego kontrastu tekstu i ikon, wielkości stref klikalnych.
• Aktualizacje i regresje:
  • zapis, że każda aktualizacja aplikacji nie może pogorszyć poziomu dostępności (brak regresji),
  • obowiązek naprawy nowych niezgodności wykrytych po aktualizacjach w określonym czasie.

W praktyce przy aplikacjach mobilnych pojawia się pytanie: kto i jak będzie testował dostępność na różnych urządzeniach? Dobrze wpisać to wprost w OPZ i umowie.

Usługi tworzenia treści (np. aktualności, pliki PDF, multimedia)

Część zamawiających zleca na zewnątrz przygotowanie treści: artykułów, broszur, materiałów wideo, prezentacji. Jeśli w takim zamówieniu nie pojawią się wymagania dostępności, nawet najlepsza dostępna strona zostanie szybko „zepsuta” nowymi, niedostępnymi materiałami.

Minimalny zestaw wymagań dla usług tworzenia treści może zawierać:

• Teksty:
  • stosowanie prostego, zrozumiałego języka lub przynajmniej unikanie zbędnego żargonu,
  • strukturę z nagłówkami, listami, wyraźnie oznaczonymi cytatami i tabelami danych.
• Dokumenty do pobrania:
  • przygotowanie dokumentów zgodnie z WCAG (m.in. znaczniki struktury, opisy alternatywne, logiczna kolejność odczytu),
  • wskazanie minimalnych formatów (np. dodatkowo DOCX/HTML zamiast wyłącznie skanów PDF).
• Grafiki i infografiki:
  • przygotowanie opisów alternatywnych lub tekstowych odpowiedników kluczowych treści,
  • Grafiki i infografiki:
    • przygotowanie opisów alternatywnych lub tekstowych odpowiedników kluczowych treści,
    • unikanie umieszczania tekstu jako część grafiki, jeśli nie jest to niezbędne (np. logotypy),
    • zapewnienie odpowiedniego kontrastu elementów w infografikach oraz możliwości ich odczytu przy powiększeniu.
  • Multimedia:
    • napisy do wszystkich materiałów wideo publikowanych online,
    • transkrypcje nagrań audio, podcastów, wywiadów,
    • w uzasadnionych przypadkach tłumaczenie na PJM lub IS, zwłaszcza dla materiałów o wysokim znaczeniu informacyjnym (np. komunikaty kryzysowe, zmiany w świadczeniach).
  • Kontrola jakości:
    • obowiązek przekazania przez wykonawcę próbek treści do weryfikacji dostępności przed rozpoczęciem produkcji „seryjnej”,
    • zapis o poprawie treści niespełniających wymagań dostępności w określonym czasie, bez dodatkowych kosztów.

  Zadaj sobie pytanie: kto u Ciebie publikuje treści na co dzień i czy ma wpływ na wymagania wobec zlecanych materiałów? Jeśli nie – włącz te osoby choćby na etapie konsultowania OPZ.

  Jak pisać wymagania, żeby wykonawca naprawdę zrozumiał oczekiwania

  Masz już świadomość, jakie elementy chcesz ująć. Kolejny krok: jak je opisać, żeby wykonawca nie „odhaczył” ogólnej formułki, tylko rzeczywiście zaprojektował dostępne rozwiązanie?

  Konkret zamiast ogólników

  Zamiast zdania „System ma być dostępny dla osób z niepełnosprawnościami” wprowadź kilka krótkich, precyzyjnych wymagań. Pomyśl: co dokładnie ma być możliwe, przez kogo i w jakich warunkach?

  Możesz na przykład zapisać:

  • „System spełnia wymagania WCAG 2.1 na poziomie AA (z wyłączeniem kryteriów X, Y – jeśli są rzetelnie uzasadnione) oraz odpowiednie wymagania normy EN 301 549 dla [typ zamówienia]”.
  • „Wszystkie funkcje systemu (w tym proces logowania, odzyskiwania hasła, składania wniosków, podpisywania dokumentów) są dostępne z użyciem samej klawiatury, bez konieczności wykonywania gestów przeciągania i upuszczania”.
  • „Wszystkie materiały wideo publikowane w ramach serwisu są opatrzone polskojęzycznymi napisami, a materiały o charakterze informacyjnym i instruktażowym – dodatkowo transkrypcją tekstową”.

  Zapytaj sam siebie: czy wykonawca, czytając obecny projekt OPZ, jest w stanie narysować sobie scenariusz działania systemu krok po kroku? Jeśli nie – doprecyzuj wymagania.

  Opis wymagań w kilku warstwach

  Dostępność da się opisać w trzech warstwach. Zastanów się, która jest dla Ciebie dziś najsłabsza:

  1. Warstwa biznesowa – po co to robimy? Jakie bariery chcemy usunąć?
  2. Warstwa wymagań użytkownika – co konkretnie ma być możliwe dla danej grupy osób?
  3. Warstwa techniczna – na jakich standardach i kryteriach opieramy ocenę?

  Przykładowy zapis łączący te trzy poziomy może wyglądać tak:

  • Cel biznesowy: „Serwis ma umożliwiać samodzielne złożenie wniosku o świadczenie X wszystkim osobom uprawnionym, w tym osobom niewidomym, słabowidzącym i niesłyszącym”.
  • Wymaganie użytkownika: „Osoba niewidoma może za pomocą czytnika ekranu wypełnić każdy etap formularza wniosku oraz otrzymać czytelne komunikaty o błędach”.
  • Wymaganie techniczne: „Formularz jest zbudowany zgodnie z kryteriami WCAG 2.1 AA dotyczącymi nawigacji klawiaturą, nazw i ról elementów interaktywnych, etykiet pól oraz komunikatów o błędach (m.in. 1.3.1, 2.1.1, 2.1.2, 3.3.1–3.3.3)”.

  Takie trójwarstwowe zapisy pomagają zarówno specjaliście IT, jak i osobie biznesowej oraz testerowi. Pytanie do Ciebie: czy w Twoich dotychczasowych zamówieniach była obecna choć jedna z tych warstw, czy wszystkie?

  Wymagania mierzalne i sprawdzalne

  Jeśli wykonawca ma coś spełnić, musi wiedzieć, jak to będzie mierzone. Zamiast „strona powinna być dostępna”, zapisz:

  • „Wykonawca przeprowadzi automatyczną i ręczną weryfikację zgodności z WCAG 2.1 AA i przedstawi raport zawierający: listę kryteriów sukcesu, status (spełnione / częściowo spełnione / niespełnione), sposób testowania, zrzuty ekranu, przykłady kodu”.
  • „W ramach odbioru zostanie wykonany audyt dostępności przez niezależnego eksperta wskazanego przez Zamawiającego (na koszt [do doprecyzowania w umowie])”.
  • „Dopuszczalny poziom niezgodności krytycznych (uniemożliwiających realizację głównych scenariuszy) wynosi 0 w momencie końcowego odbioru”.

  Tu dobrze się sprawdza proste pytanie kontrolne: czy z tego zapisu da się przygotować checklistę do odbioru? Jeśli nie – dopisz brakujące elementy.

  Język zrozumiały dla obu stron

  W OPZ często pojawiają się dwie skrajności: albo sam „techniczny żargon”, albo wyłącznie hasła ogólne. Dobry opis wymagań dostępności łączy oba te światy.

  Przykładowo zamiast jedynie: „Strona musi spełniać kryterium 2.4.7 WCAG 2.1” możesz zapisać:

  • „Fokus klawiatury jest zawsze widoczny (np. przez wyraźną obwódkę), aby użytkownik korzystający z klawiatury wiedział, który element jest aktualnie aktywny, co jest wymagane m.in. przez kryterium 2.4.7 WCAG 2.1”.

  Pomyśl, kto realnie będzie czytał OPZ po stronie wykonawcy: handlowiec, analityk, programista, grafik? Jeśli zależy Ci na wspólnym zrozumieniu, spróbuj zapisywać wymagania dwoma zdaniami: jedno „po ludzku”, drugie z odniesieniem do standardu.

  Rozdzielenie wymagań „twardych” i „opcjonalnych”

  Nie wszystkie oczekiwania muszą mieć ten sam priorytet. W praktyce dobrze działa wyraźne oznaczenie wymagań:

  • obowiązkowych (MUST) – bez ich spełnienia oferta podlega odrzuceniu lub nie ma możliwości odbioru,
  • pożądanych (SHOULD) – wpływają na ocenę jakości, ale nie są warunkiem minimum,
  • dodatkowych (MAY) – wskazują kierunek rozwoju, mogą być tematem rozmowy na etapie dialogu technicznego.

  Przykład:

  • MUST: „Interfejs użytkownika musi być w pełni obsługiwany z klawiatury”.
  • SHOULD: „Wykonawca zapewni tryb wysokiego kontrastu dostosowany do identyfikacji wizualnej Zamawiającego”.
  • MAY: „System może zawierać wbudowane podpowiedzi dla redaktorów na temat dostępności (np. ostrzeżenie przy braku tekstu alternatywnego)”.

  Zadaj sobie pytanie: z których wymagań naprawdę nie możesz zrezygnować, a które są „miłe, ale nie kluczowe”? Takie uporządkowanie ułatwi rozmowę i z wykonawcą, i z działem zamówień publicznych.

  Wymagania dotyczące procesu, nie tylko efektu

  Sama deklaracja „produkt końcowy ma być dostępny” to za mało. Wiele problemów z dostępnością wynika z tego, jak przebiega projekt. Do OPZ możesz wprowadzić wymagania związane z samym procesem wytwórczym.

  Rozważ dopisanie m.in. takich zapisów:

  • „Wykonawca wyznaczy osobę odpowiedzialną za obszar dostępności cyfrowej po stronie zespołu projektowego (rola koordynatora ds. dostępności)”.
  • „Na etapie projektowania makiet i prototypów graficznych wykonawca przeprowadzi wewnętrzną weryfikację dostępności (kontrast, skalowanie, nawigacja klawiaturą) i udokumentuje jej wyniki”.
  • „W ramach testów akceptacyjnych zostaną przeprowadzone testy z udziałem co najmniej n użytkowników z niepełnosprawnościami lub z wykorzystaniem technologii asystujących (czytnik ekranu, powiększenie, wysokie kontrasty)”.

  Możesz też doprecyzować formę współpracy:

  • „Wykonawca przedstawi Zamawiającemu do akceptacji sposób organizacji prac nad dostępnością (np. plan testów, narzędzia, osoby odpowiedzialne) w terminie X dni od podpisania umowy”.

  Pomyśl: na jakim etapie poprzednich projektów dowiadywałeś się o problemach z dostępnością – przy odbiorze, czy wcześniej? Im wcześniej uregulujesz proces, tym mniej ryzykujesz na końcu.

  Wymagania dotyczące dokumentacji i przekazania wiedzy

  Nawet najlepiej wykonany system będzie tracił na dostępności, jeśli zespół po Twojej stronie nie będzie wiedział, jak z niego korzystać i jak utrzymać standardy. W opisie wymagań zaplanuj, co musi zostać przekazane w ramach umowy.

  Przykładowe elementy, które można wpisać:

  • „Wykonawca opracuje krótką instrukcję dla redaktorów treści (maksymalnie 15–20 stron), opisującą dobre praktyki dostępnego publikowania w serwisie, w tym: dodawanie tekstów alternatywnych, poprawną strukturę nagłówków, zasady przygotowania dokumentów PDF”.
  • „Instrukcje użytkownika, instrukcje administratora oraz inne materiały szkoleniowe będą przygotowane w sposób dostępny: z semantyczną strukturą, możliwością odczytu przez czytniki ekranu, z odpowiednim kontrastem”.
  • „Wykonawca przeprowadzi co najmniej jedno szkolenie (stacjonarne lub online) dla redaktorów i administratorów, wprowadzające w zasady korzystania z systemu z zachowaniem dostępności”.

  Sprawdź sam: czy w Twoich obecnych umowach jest choć jedno zdanie o tym, jak utrzymać dostępność po zakończeniu projektu? Jeśli nie, to dobry moment, żeby to zmienić.

  Mechanizmy zgłaszania i usuwania niezgodności

  Nawet przy najlepszej specyfikacji po uruchomieniu wyjdą na jaw błędy – także w obszarze dostępności. Z góry ustal z wykonawcą, jak będzie wyglądać obsługa takich zgłoszeń.

  W OPZ lub w umowie możesz ująć na przykład:

  • „Zgłoszenia niezgodności z wymaganiami dostępności będą klasyfikowane co najmniej na trzy poziomy: krytyczne (uniemożliwiające korzystanie), istotne (znacznie utrudniające) oraz pozostałe”.
  • „Czas reakcji i usunięcia niezgodności dostępnościowych nie będzie dłuższy niż: X dni roboczych dla zgłoszeń krytycznych, Y dni roboczych dla zgłoszeń istotnych, Z dla pozostałych” – spójny z zapisami SLA.
  • „Wykonawca zobowiązuje się do zapewnienia, że poprawki wprowadzane w systemie nie pogorszą istniejącego poziomu dostępności (testy regresji)”.

  Zastanów się: kto u Ciebie będzie przyjmował takie zgłoszenia i weryfikował, czy problem został rzeczywiście usunięty? Dobrze, jeśli ta rola jest nazwana w dokumentach wewnętrznych.

  Uwzględnienie ograniczeń i kontekstu organizacji

  Nie wszystkie instytucje mają te same możliwości techniczne i ludzkie. Inne oczekiwania możesz mieć, jeśli dysponujesz zespołem IT na miejscu, a inne, jeśli wszystko zlecasz na zewnątrz.

  Zanim dopiszesz kolejne wymaganie, odpowiedz sobie na kilka pytań:

  • „Kto po naszej stronie będzie zarządzał treścią i strukturą systemu?”
  • „Czy mamy osoby, które potrafią podstawowo ocenić dostępność, czy potrzebujemy wsparcia z zewnątrz?”
  • „Jakie technologie są już obecne (np. podpis elektroniczny, profil zaufany, system obiegu dokumentów) i czy są w ogóle gotowe na integrację z dostępnością?”

  Na tej podstawie łatwiej ustalić, czy potrzebujesz bardziej rozbudowanego wsparcia wykonawcy (audyt, konsultacje, szkolenia), czy wystarczy precyzyjne opisanie wymagań i odbioru. Jeśli Twoja organizacja dopiero zaczyna przygodę z dostępnością, lepiej wprost poprosić o wsparcie w zbudowaniu minimalnych kompetencji po stronie zamawiającego.

  Dialog techniczny i wyjaśnienia w trakcie przetargu

  Jeśli masz wątpliwości, jak konkretnie opisać wymagania dostępności, rozważ przeprowadzenie dialogu technicznego przed wszczęciem postępowania. Dzięki temu dowiesz się, co na rynku jest standardem, a co będzie wymagać dodatkowych nakładów.

  Przy samym postępowaniu zadbaj o to, by:

  • pytania wykonawców dotyczące dostępności były traktowane równie poważnie, jak kwestie funkcjonalne czy bezpieczeństwa,
  • odpowiedzi zamawiającego nie osłabiały wymagań dostępności (np. poprzez „odpuszczanie” kluczowych kryteriów bez mocnego uzasadnienia),