Elektroniczne zamówienia publiczne a dostępność cyfrowa dla wykonawców z niepełnosprawnościami

Krótka scena z życia wykonawcy: kiedy „elektroniczne” znaczy „niedostępne”

Niewidomy właściciel małej firmy IT siada wieczorem do komputera. Znalazł idealne zamówienie publiczne na usługi, które świadczy od lat. Otwiera platformę e-zamówień, włącza czytnik ekranu i… zatrzymuje się na ekranie logowania, bo program czyta mu jedynie: „przycisk, przycisk, pole edycji, nieoznaczone”. Czas do złożenia oferty leci, licznika czasu nie da się zatrzymać, a każdy kolejny krok to walka z interfejsem zamiast walka o kontrakt.

Tak wygląda codzienność wielu wykonawców z niepełnosprawnościami, którzy formalnie mają pełne prawo startować w postępowaniach, ale w praktyce blokuje ich źle zaprojektowana platforma, niedostępne pliki i brak reakcji zamawiającego na bariery cyfrowe. Zamówienia są „elektroniczne”, przepisy o komunikacji elektronicznej zostały wdrożone, ale dostępność cyfrowa w zamówieniach publicznych pozostaje tylko na papierze.

Główne blokady, które pojawiają się już na starcie, to przede wszystkim:

• Brak opisów przycisków i pól formularza – czytnik ekranu nie wie, co odczytać, więc użytkownik „słyszy” jedynie anonimowe elementy interfejsu.
• Źle przygotowane pliki – skany PDF bez tekstu, brak nagłówków, brak logicznej struktury, przez co przeanalizowanie dokumentacji przetargowej wymaga pomocy osoby trzeciej.
• Agresywne liczniki czasu – sesje wygasające po kilku minutach bez możliwości łatwego wznowienia, co dla osoby korzystającej z technologii asystujących jest szczególnie dotkliwe.
• Brak alternatywnych dróg komunikacji – brak dostępnego formularza kontaktowego, brak adresu e-mail do zgłaszania problemów z dostępnością, brak procedury zgłaszania barier.

Z perspektywy zamawiającego wszystko wygląda poprawnie: jest platforma, jest e-podpis, dokumenty są opublikowane, terminy dochowane. Jednak faktycznie część potencjalnych wykonawców została „wyłączona” z postępowania jeszcze przed złożeniem oferty. Rynek zostaje zubożony, konkurencja spada, a ryzyko zarzutów o dyskryminację i naruszenie przepisów wzrasta.

Elektroniczne zamówienia publiczne bez realnej dostępności cyfrowej nie spełniają ani wymogów prawa, ani podstawowych zasad efektywności ekonomicznej. Dostępność nie jest „dodatkiem”, tylko warunkiem, by elektroniczna forma była rzeczywiście równa dla wszystkich wykonawców.

Podstawowe ramy prawne: gdzie zaczyna się obowiązek dostępności cyfrowej

Prawo zamówień publicznych a dostępność e-usług

Prawo zamówień publicznych nie opisuje w szczegółach, jak ma wyglądać interfejs platformy e-zamówień, ale jasno wskazuje na obowiązek równego traktowania wykonawców i niedyskryminacji. Jeżeli komunikacja w postępowaniu odbywa się w postaci elektronicznej, a platforma jest technicznie niedostępna dla części wykonawców z niepełnosprawnościami, pojawia się realne ryzyko naruszenia tych zasad.

Platforma e-zamówień, system do składania ofert, moduł do zadawania pytań lub przesyłania wyjaśnień, a także repozytorium dokumentów przetargowych to nic innego jak usługa cyfrowa administracji publicznej. Z tego wynika obowiązek zapewnienia dostępności cyfrowej, analogiczny jak w przypadku stron internetowych urzędów, BIP czy aplikacji mobilnych.

W praktyce oznacza to, że:

• postępowania nie mogą być projektowane w sposób, który z definicji wyklucza część wykonawców z rynku ze względu na ich niepełnosprawność,
• narzędzia do komunikacji elektronicznej powinny być zgodne z minimalnymi standardami dostępności (co najmniej poziom WCAG 2.1 AA),
• trzeba brać pod uwagę zarówno dostępność samej platformy, jak i wszystkich załączanych plików i mechanizmów podpisu elektronicznego.

Ustawa o dostępności cyfrowej i inne akty powiązane

Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych precyzuje, że publiczne usługi cyfrowe muszą być dostępne dla osób z niepełnosprawnościami. Choć ustawa koncentruje się na stronach i aplikacjach, jej zakres obejmuje także portale, gdzie obywatel/wykonawca załatwia sprawę urzędową – a takim portalem jest platforma e-zamówień.

W tle pojawiają się również inne regulacje i wytyczne, takie jak:

• standard WCAG 2.1 jako wzorzec techniczny,
• krajowe wytyczne dotyczące dostępności serwisów publicznych,
• wewnętrzne polityki dostępności urzędów i instytucji publicznych.

Zamawiający, którzy korzystają z komercyjnych platform zakupowych, powinni w umowach z dostawcami oprogramowania uwzględniać jednoznaczny wymóg zgodności z tymi standardami. W przeciwnym razie odpowiedzialność za brak dostępności i tak spada na instytucję prowadzącą postępowanie.

Rola WCAG 2.1 jako praktycznego punktu odniesienia

WCAG 2.1 (Web Content Accessibility Guidelines) to międzynarodowy standard opisujący jak technicznie zapewnić dostępność stron i aplikacji. Dla elektronicznych zamówień publicznych ma on wymiar bardzo praktyczny: podpowiada, jak zaprojektować formularze ofertowe, jak budować tabele, jak oznaczać przyciski i jakie kontrasty stosować.

Z punktu widzenia zamawiającego kluczowe jest:

• umieć wymagać od dostawców IT zgodności z WCAG 2.1 AA,
• kontrolować, czy platforma faktycznie spełnia te standardy (audyt dostępności),
• uwzględniać dostępność także w bieżących modyfikacjach systemu, a nie tylko „na starcie projektu”.

Standard WCAG nie jest celem samym w sobie, lecz narzędziem. Pozwala przełożyć ogólne hasła o „dostępności” na konkretne wymagania techniczne, które da się sprawdzić testami i codziennym użytkowaniem.

Konsekwencje braku dostępności: od skarg do słabszej konkurencji

Ignorowanie dostępności cyfrowej na platformach e-zamówień niesie skutki nie tylko wizerunkowe. Dostępność stała się realnym kryterium kontroli instytucji publicznych, a także przedmiotem skarg i odwołań.

Potencjalne konsekwencje to m.in.:

• skargi do organów odpowiedzialnych za nadzór nad dostępnością cyfrową,
• zarzuty naruszenia zasady równego traktowania wykonawców,
• konieczność modyfikacji postępowania (np. przedłużenie terminu, zmiana platformy, dodatkowe formy komunikacji),
• ograniczenie konkurencji – mniej ofert, węższy wybór, gorsze warunki ekonomiczne.

Zamawiający, którzy traktują dostępność jako integralną część strategii e-zamówień, zyskują odwrotne efekty: więcej ofert, mniejsze ryzyko sporów i lepszy wizerunek instytucji nowoczesnej i odpowiedzialnej społecznie.

Kim są wykonawcy z niepełnosprawnościami i jak korzystają z e-zamówień

Różne rodzaje niepełnosprawności, różne potrzeby w e-zamówieniach

Wykonawcy z niepełnosprawnościami to nie tylko osoby na wózkach inwalidzkich. W kontekście elektronicznych zamówień publicznych kluczowe są szczególnie cztery grupy potrzeb:

• Osoby niewidome i słabowidzące – korzystają z czytników ekranu (np. NVDA, JAWS) lub programów powiększających, potrzebują poprawnych etykiet pól, nagłówków, logicznej kolejności nawigacji i odpowiednich kontrastów.
• Osoby z niepełnosprawnością słuchu – potrzebują treści pisemnych zamiast lub obok nagrań audio/wideo, jasnych komunikatów tekstowych o statusie i błędach, unikają rozwiązań wymagających kontaktu wyłącznie telefonicznego.
• Osoby z niepełnosprawnością ruchową, zwłaszcza dłoni – często operują klawiaturą, alternatywnymi myszami, przyciskami, programami rozpoznawania mowy; wymagają interfejsu, który da się obsłużyć bez precyzyjnych ruchów myszy i skomplikowanych gestów.
• Osoby z trudnościami poznawczymi lub intelektualnymi – potrzebują prostszego języka, czytelnego układu treści, przewidywalnych formularzy, unikania nadmiaru bodźców i zbędnych elementów wizualnych.

Wykonawca z niepełnosprawnością może być właścicielem jednoosobowej działalności, pracownikiem większej firmy, specjalistą ds. zamówień czy prawnikiem przygotowującym ofertę. W każdym scenariuszu kontakt z platformą e-zamówień to zestaw konkretnych kroków, które muszą być dostępne na każdym etapie.

Technologie asystujące w praktyce e-zamówień

Technologie asystujące to klucz do niezależnego korzystania z e-usług przez osoby z niepełnosprawnościami. W kontekście zamówień publicznych najczęściej pojawiają się:

• Czytniki ekranu – odczytują treści na głos, poruszają się po stronie za pomocą klawiatury i semantyki HTML. Brak etykiet pól, nieopisane przyciski, nieprawidłowo zagnieżdżone nagłówki skutecznie blokują możliwość złożenia oferty.
• Powiększalniki i narzędzia zmiany kontrastu – wymagają, by strona dobrze skalowała się przy powiększeniu, a tekst nie „rozpadał” się lub nie znikał.
• Klawiatury alternatywne i przełączniki – użytkownik przechodzi po elementach strony klawiszem Tab lub innymi przyciskami; wszelkie elementy dostępne tylko po najechaniu myszą stają się dla niego niewidoczne.
• Oprogramowanie do rozpoznawania mowy – wprowadza tekst i steruje interfejsem głosem, co wymaga prostych, jednoznacznych nazw elementów i przewidywalnego układu.

Jeżeli platforma e-zamówień jest zgodna z dobrymi praktykami dostępności, technologie asystujące „widzą” ją tak samo, jak użytkownik bez niepełnosprawności widzi ją na ekranie. Jeżeli jednak interfejs jest rozwijany bez udziału ekspertów od dostępności, większość funkcji pozostaje dla tych technologii niewidoczna.

Kroki w procesie zamówienia z perspektywy osoby z niepełnosprawnością

Cała ścieżka udziału w postępowaniu przetargowym to ciąg akcji, które muszą być dostępne. Przykładowo:

• Wyszukiwanie przetargu – filtrowanie po kryteriach, czytelne wyniki, możliwość zapisania ogłoszenia lub przejścia do szczegółów za pomocą klawiatury.
• Pobieranie dokumentacji – dostępne linki, pliki PDF z warstwą tekstową, opatrzone nagłówkami, z zakładkami, bez skanów bez OCR.
• Zadawanie pytań do zamawiającego – formularz kontaktowy obsługiwany przez czytniki ekranu, potwierdzenia wysyłki czytelne tekstowo, możliwość alternatywnego kontaktu (np. e-mail).
• Przygotowanie i wypełnienie formularza ofertowego – logiczne etapy, jasne komunikaty błędów, zapis roboczy oferty bez utraty danych, brak przymusu szybkiego działania z uwagi na krótki czas sesji.
• Podpis elektroniczny i wysyłka – dostępny kreator podpisu, przejrzyste komunikaty o ważności certyfikatu, brak nieczytelnych okien modalnych blokujących czytnik ekranu.

Jeżeli którakolwiek z tych faz jest niedostępna, cała dostępność elektronicznych zamówień publicznych staje się iluzoryczna. Nie wystarczy dostępny BIP – kluczowy jest pełny łańcuch od ogłoszenia po zawarcie umowy.

Bariery dostępności na platformach e-zamówień – katalog najczęstszych problemów

Niedostępne formularze i komunikaty błędów

Formularze to serce elektronicznego składania ofert. To w nich wykonawca wpisuje dane, wybiera opcje, załącza pliki, składa oświadczenia. Najczęstsze problemy w tym obszarze to:

• Brak powiązania etykiet z polami formularza – pole wygląda poprawnie wizualnie, ale nie ma atrybutu label for, więc czytnik ekranu nie wie, jak je nazwać.
• Walidacja wyłącznie wizualna – błędne pola są tylko podkreślone na czerwono lub oznaczone ikonką, bez tekstowego komunikatu, co uniemożliwia użytkownikowi z niepełnosprawnością wzroku zrozumienie, co trzeba poprawić.
• Brak informacji o postępie – wieloetapowe formularze bez czytelnego wskazania, na którym kroku użytkownik jest i ile zostało do końca, co dezorientuje zwłaszcza osoby korzystające z czytników ekranu i osoby z trudnościami poznawczymi.
• Automatyczne czyszczenie pól – formularz traci wprowadzone dane po błędzie lub wylogowaniu, co dla osób wypełniających dokumenty wolniej (np. z powodu niepełnosprawności ruchowej) może oznaczać konieczność powtarzania wielogodzinnej pracy.

Każda z tych barier da się usunąć na etapie projektowania lub modyfikacji systemu, a korzyść odczuwają nie tylko osoby z niepełnosprawnościami, lecz także wszyscy wykonawcy – bo lepiej zaprojektowany formularz to mniej pomyłek i mniej telefonów do zamawiającego.

Niedostępne pliki, skany PDF i załączniki ofertowe

Wyobraźmy sobie wykonawcę, który po kilku godzinach walki z platformą wreszcie pobiera specyfikację – a tam trzydzieści stron zeskanowanego PDF-a bez tekstu, jedynie obrazki. Dla osoby korzystającej z czytnika ekranu to ściana, nie dokument. Na tym etapie część wykonawców po prostu rezygnuje z udziału.

Najczęstsze problemy z załącznikami i dokumentacją przetargową wyglądają podobnie niezależnie od branży:

• Skanowane PDF-y bez warstwy tekstowej – dokument jest obrazem, a nie tekstem, przez co nie da się go przeszukać, powiększyć z zachowaniem jakości ani odczytać czytnikiem ekranu.
• Brak struktury dokumentu – długie pliki bez nagłówków, zakładek czy logicznego spisu treści, w których odszukanie jednego paragrafu zajmuje kilkukrotnie więcej czasu.
• Pliki w nietypowych formatach (np. rzadkie formaty edytorów tekstu czy arkuszy) – wymagają dodatkowego oprogramowania, które nie zawsze współpracuje z technologiami asystującymi.
• Niewłaściwe zabezpieczenia – dokumenty zaszyfrowane lub zablokowane tak, że nie da się ich odczytać przez czytnik ekranu albo skonwertować do bardziej dostępnej postaci.

Po stronie zamawiającego rozwiązanie rzadko wymaga rewolucji technologicznej. W większości przypadków wystarczy skanowanie dokumentów z OCR, stosowanie szablonów z poprawnie zdefiniowanymi nagłówkami oraz publikowanie plików w otwartych, powszechnie dostępnych formatach (np. DOCX, ODT, dostępne PDF). Dobrze przygotowany plik zmniejsza liczbę pytań od wszystkich wykonawców – nie tylko tych z niepełnosprawnościami.

Problemy z nawigacją, fokusem i obsługą klawiaturą

Wielu wykonawców przyzwyczaiło się, że „coś nie działa” i trzeba kliknąć kilka razy w różne miejsca. Dla osoby, która porusza się wyłącznie klawiaturą lub przyciskiem przełączającym fokus, taki chaos nawigacyjny oznacza realną barierę wejścia.

Najbardziej dokuczliwe błędy w obszarze nawigacji to m.in.:

• Brak pełnej obsługi klawiaturą – część funkcji (np. rozwijanie menu, dodawanie załączników, potwierdzanie komunikatów) działa tylko po użyciu myszy lub gładzika.
• Zagubiony lub niewidoczny fokus – użytkownik wciska Tab, ale nie widzi, który element jest zaznaczony; czytnik ekranu może też „przeskakiwać” w losowe miejsca.
• Pułapki klawiaturowe – np. okno modalne, z którego nie da się wyjść klawiaturą, albo element, który „zamyka” użytkownika, zmuszając do odświeżenia strony.
• Niedostępne menu rozwijane i listy – wybór z listy możliwy jedynie poprzez ruch myszy, brak możliwości wpisania pierwszych liter pozycji czy poruszania się strzałkami.

Jeżeli zespół IT na etapie testów bierze pod uwagę scenariusz „użytkownik korzysta tylko z klawiatury”, większość takich problemów wychodzi natychmiast. Prosty test – przejście całego procesu złożenia oferty bez dotykania myszy – często otwiera oczy bardziej niż kilkunastostronicowe raporty.

Niestabilność systemu i brak przewidywalności zachowania

Osoba, która korzysta z technologii asystujących, działa z reguły wolniej – musi odsłuchać komunikaty, dokładniej sprawdzić pola formularzy, częściej robi przerwy. Gdy platforma „wyrzuca” ją z sesji po kilkunastu minutach bez ostrzeżenia, praca nad ofertą zamienia się w loterię.

Na poziomie użyteczności najczęściej pojawiają się takie pułapki:

• Krótki czas sesji bez ostrzeżenia – użytkownik zostaje wylogowany i traci dane, nie mając szansy na ich zapisanie, bo jedynym komunikatem był drobny pasek na górze ekranu.
• Niespójne zachowanie elementów – ten sam przycisk w różnych miejscach działa inaczej (np. raz zapisuje roboczą wersję, innym razem od razu wysyła ofertę).
• Niespodziewane przeładowania strony – po wyborze opcji formularz ładuje się ponownie, a fokus wraca na samą górę, co dezorientuje użytkownika czytnika ekranu.
• Brak wyraźnych potwierdzeń akcji – niejasne komunikaty typu „Operacja zakończona” bez informacji, o jaką operację chodzi, i czy dana część oferty na pewno została zapisana.

Przewidywalność to jedna z podstawowych zasad dostępności, którą można zrealizować nawet w prostych systemach. Zamawiający, którzy testują swoje platformy na realnych scenariuszach (wysłanie pytań, aktualizacja oferty, dopisanie załącznika tuż przed terminem), szybciej wychwytują błędy projektowe uderzające w wszystkich użytkowników, nie tylko tych z niepełnosprawnościami.

Niewłaściwe użycie kolorów, kontrastu i elementów wizualnych

Dla osoby słabowidzącej lub z zaburzeniami rozpoznawania barw drobny, bladoniebieski link może być równoznaczny z jego brakiem. Podobnie małe, zbite czcionki przy dużej ilości tekstu potrafią skutecznie zniechęcić do analizy nawet stosunkowo prostego ogłoszenia.

Do najczęstszych błędów wizualnych należą:

• Zbyt niski kontrast tekstu do tła – jasnoszare litery na białym tle, cienkie fonty, przyciski oparte na pastelowych kolorach.
• Informacje oparte wyłącznie na kolorze – np. pole „na zielono” jest poprawne, a „na czerwono” błędne, bez dodatkowego komunikatu tekstowego.
• Małe, zbite bloki tekstu – brak odstępów, podziału na akapity i nagłówki, co utrudnia szybkie przeskanowanie treści.
• Ikony bez opisów – użytkownik widzi kilka zbliżonych symboli (np. strzałki, dyskietki), ale nie ma opisu tekstowego, który informowałby, co dokładnie się stanie po kliknięciu.

Najprostsze narzędzia do analizy kontrastu czy symulacji daltonizmu pozwalają wychwycić wiele z tych problemów przed wdrożeniem. Zastosowanie większych czcionek, wyraźnych tytułów sekcji i znanego kodu ikon (z opisem tekstowym) przynosi korzyści również na małych ekranach czy przy pracy w trudnych warunkach oświetleniowych.

Komunikacja jednostronna i brak alternatywnych kanałów kontaktu

Zdarza się, że wykonawca ma drobne pytanie techniczne – np. nie może odnaleźć przycisku „Dodaj załącznik” po ostatniej aktualizacji. Platforma przewiduje jednak wyłącznie infolinię telefoniczną, a osoba głucha lub słabosłysząca zostaje sama z problemem.

Ograniczenie komunikacji do jednego kanału bywa wygodne organizacyjnie, ale rodzi konkretne bariery:

• Wyłącznie kontakt telefoniczny – uniemożliwia skuteczne zgłaszanie problemów osobom z niepełnosprawnością słuchu albo tym, które komunikują się lepiej pisemnie.
• Brak opisanych procedur wsparcia – użytkownik nie wie, gdzie zgłosić problem dostępności, czy istnieje dedykowany adres e-mail, oraz jak długo może czekać na odpowiedź.
• Niedostępne infolinie – brak możliwości skorzystania z tłumacza PJM online lub komunikacji tekstowej (np. czatu, formularza kontaktowego).

Dodanie prostych rozwiązań – tak jak dedykowany adres e-mail do zgłoszeń problemów technicznych czy krótki formularz online – często znacząco zmniejsza obciążenie infolinii i jednocześnie otwiera drzwi przed wykonawcami, dla których rozmowa telefoniczna jest realną przeszkodą.

Standard WCAG 2.1 w realiach elektronicznych zamówień publicznych

WCAG jako kontrakt między zamawiającym, wykonawcą IT i użytkownikami

Gdy zamawiający wpisuje w wymaganiach „platforma musi być zgodna z WCAG 2.1 AA”, dla wielu projektantów i programistów to wciąż ogólne hasło. Tymczasem dla wykonawcy z niepełnosprawnością to różnica między „mogę złożyć ofertę” a „ktoś musi zrobić to za mnie”.

Standard WCAG 2.1 można traktować jak rodzaj wspólnego języka. Zamiast dyskutować abstrakcyjnie o „przyjaznym interfejsie”, strony posługują się konkretnymi kryteriami sukcesu, np.:

• 1.1.1 Treść nietekstowa – wszystkie przyciski, ikony i grafiki pełniące funkcję muszą mieć opisy alternatywne.
• 1.3.1 Informacje i relacje – struktura formularzy, tabel i nagłówków powinna być odzwierciedlona w kodzie, aby czytniki ekranu mogły ją poprawnie zinterpretować.
• 2.1.1 Klawiatura – każdą funkcję da się obsłużyć klawiaturą bez konieczności skomplikowanych skrótów czy gestów.
• 3.3.1 Identyfikacja błędu – użytkownik jasno dowiaduje się, co zrobił źle i w którym polu, a komunikat nie jest jedynie czerwonym podkreśleniem.

Czytając WCAG w oderwaniu od konkretnego procesu, łatwo zbagatelizować poszczególne kryteria. Dopiero gdy przełoży się je na kroki e-zamówień – wyszukiwanie ogłoszeń, zadawanie pytań, wysyłanie oferty – widać, że to nie „opcjonalne usprawnienia”, lecz warunek realnego dostępu do rynku.

Jak wybrać poziom zgodności i zakres wdrożenia

W zamówieniach publicznych minimalnym standardem stał się poziom WCAG 2.1 AA. Czasem jednak pojawia się pokusa, by „na wszelki wypadek” wpisać w dokumentacji AAA albo zupełnie nie doprecyzować oczekiwań. Oba skrajne podejścia rodzą problemy.

Przy ustalaniu poziomu zgodności przydaje się kilka prostych pytań:

• Czy platforma jest kluczowym kanałem udziału w postępowaniach przetargowych (tzn. brak sensownej alternatywy)?
• Czy system jest dedykowany masowemu użyciu, czy raczej wąskiej grupie użytkowników?
• Jak długo platforma ma być eksploatowana i jak kosztowne będą późniejsze poprawki?

W praktyce:

• Poziom AA powinien być standardem – obejmuje kluczowe wymagania zapewniające samodzielne korzystanie z serwisu przez większość osób z niepełnosprawnościami.
• Wybrane kryteria AAA można stosować tam, gdzie ryzyko wykluczenia jest największe (np. zapewnienie łatwiejszego języka w krytycznych komunikatach, lepszej kontroli czasu).

Jeżeli instytucja świadomie decyduje się na określony poziom i dokumentuje tę decyzję, łatwiej rozmawiać z dostawcą IT o kosztach, priorytetach i terminach realizacji, a w razie kontroli – wykazać, że dostępność była realnym elementem projektowania systemu.

Mapowanie WCAG na konkretne funkcje platformy e-zamówień

Dla zespołów wdrażających system najtrudniejszy bywa moment przełożenia kryteriów WCAG na konkretną listę zadań. Samo hasło „zróbmy dostępność” nie mówi programistom, co mają wpisać w backlog.

Praktycznym podejściem jest rozpisanie WCAG „po modułach” platformy, np.:

• Moduł wyszukiwania postępowań – kryteria związane z formularzami, nawigacją klawiaturą, czytelnością wyników (1.3.1, 2.1.1, 2.4.6).
• Moduł podglądu ogłoszenia i dokumentacji – kryteria dotyczące struktury treści, kontrastu, dostępnych załączników (1.3.2, 1.4.3, 1.4.10).
• Moduł zadawania pytań i komunikacji – kryteria dot. formularzy, komunikatów błędów, stanu systemu (3.3.1, 3.3.3, 4.1.3).
• Moduł składania oferty – kryteria związane z kontrolą czasu, zgłaszaniem błędów, możliwością zapisania wersji roboczych (2.2.1, 2.2.6, 3.3.4).

Taki „rozkład jazdy” upraszcza rozmowę z dostawcą: zamiast ogólnego sporu, czy system „spełnia WCAG”, łatwiej omówić, które funkcje wymagają dopracowania i jakie kryteria sukcesu muszą zostać spełnione, aby wykonawca z niepełnosprawnością faktycznie mógł przejść cały proces.

Testy z użytkownikami i audyty dostępności w toku życia systemu

Nawet najlepiej opisana specyfikacja nie zastąpi spotkania z realnym użytkownikiem. Wielu zamawiających przekonało się o tym, gdy po pierwszych skargach na brak dostępności zaprosili osoby niewidome lub z niepełnosprawnością ruchową do wspólnych testów platformy.

Skuteczny model pracy z dostępnością zwykle łączy trzy elementy:

• Automatyczne testy – narzędzia typu lintery, skanery WCAG, wtyczki do przeglądarek wyłapujące podstawowe błędy (kontrast, brak alt, nieprawidłowe nagłówki).

Testy z udziałem osób z niepełnosprawnościami

Podczas prezentacji nowej platformy wszyscy na sali potwierdzają, że „działa”. Dopiero gdy zaproszony wykonawca niewidomy próbuje samodzielnie złożyć ofertę, okazuje się, że nie może przejść dalej niż do pierwszego kroku formularza. Nagle z „gotowego wdrożenia” robi się projekt pilnie wymagający poprawek.

Testy z udziałem rzeczywistych użytkowników z niepełnosprawnościami odsłaniają problemy, których nie wychwyci ani automaty, ani testerzy bez doświadczenia w pracy z technologiami asystującymi. Przykładowo:

• Osoba korzystająca z czytnika ekranu wskaże, że kolejność fokusu „skacze”, a podpisy pól formularza są nieczytelne lub dublowane.
• Wykonawca z niepełnosprawnością ruchową pokaże, które elementy interfejsu są praktycznie nieosiągalne przy pracy wyłącznie klawiaturą lub przełącznikiem.
• Osoba głucha zauważy, że istotne informacje o zmianach w postępowaniu umieszczane są wyłącznie w nagraniu wideo bez napisów.

Przy organizacji takich testów przydaje się prosty scenariusz – od wyszukania postępowania, przez zadanie pytania, po złożenie oferty i sprawdzenie statusu. Zespół IT, zamawiający i ewentualny dostawca platformy mogą wspólnie obserwować, gdzie użytkownik się zatrzymuje i jakich „obejść” potrzebuje, by iść dalej.

Dobrym zwyczajem jest powtarzanie takich sesji nie tylko przy pierwszym uruchomieniu, ale także po większych aktualizacjach. Niewinna zmiana układu ekranu, z perspektywy projektanta „kosmetyczna”, dla osoby korzystającej z technologii asystujących bywa równoznaczna z koniecznością uczenia się systemu od nowa.

Stałe utrzymanie dostępności zamiast jednorazowego audytu

Nowa platforma przechodzi audyt, raport jest pozytywny, instytucja odetchnęła. Po pół roku wdrażanych jest kilkanaście zmian „dla wygody użytkowników”, o których nikt nie rozmawia z ekspertem od dostępności. Pierwsze skargi wracają szybciej, niż skończy się okres gwarancji.

Dostępność cyfrowa w systemach e-zamówień nie jest jednorazowym „odhaczeniem wymogu”, tylko procesem. System żyje, pojawiają się nowe funkcje, integracje, poprawki bezpieczeństwa – każda z nich może nieświadomie zniweczyć wcześniejszy wysiłek. Dlatego przydaje się jasny schemat utrzymania:

• Przeglądy cykliczne – krótsze audyty co kilka miesięcy, skoncentrowane na nowo wdrożonych funkcjach, nie zaś wyłącznie na „starej” części systemu.
• Definicja „zakończonego” zadania – dopóki funkcja nie przejdzie podstawowego zestawu testów dostępności (np. automaty + szybki test klawiaturą + sprawdzenie przez jedną osobę korzystającą z czytnika ekranu), nie trafia na produkcję.
• Monitorowanie zgłoszeń użytkowników – każda skarga na brak dostępności technicznej zapisywana jest w jednym systemie zgłoszeniowym i analizowana pod kątem powtarzalności problemu.

Taki model zmniejsza ryzyko sytuacji, w której zamawiający dopiero przy następnym, dużym audycie dowiaduje się, że formalnie „spełniona” dostępność rozjechała się z realnym doświadczeniem wykonawców.

Angażowanie wykonawców z niepełnosprawnościami w projektowanie zmian

Gdy zespół projektowy zamyka się w sali konferencyjnej i nanosi poprawki „dla osób z niepełnosprawnościami” bez ich udziału, efekty bywają przewrotne. Prosty przykład: powiększenie wszystkich czcionek i dodanie wielu kolorowych etykiet miało „ulepszyć czytelność”, a w praktyce zwiększyło chaos w czytniku ekranu.

Znacznie lepsze rezultaty daje stała współpraca z przedstawicielami różnych grup użytkowników. Nie musi to być duży, formalny panel – często wystarczy kilka równoległych kanałów:

• Konsultacje roboczych makiet z jedną–dwiema osobami niewidomymi czy słabowidzącymi, zanim rozpocznie się właściwe programowanie.
• Szybkie testy „na żywo” – krótkie spotkania online, podczas których wykonawca z niepełnosprawnością przechodzi wskazany fragment procesu, komentując na bieżąco.
• Zachęta do zgłaszania usprawnień – formularz lub adres e-mail, gdzie można podzielić się nie tylko problemem, ale też sugestią rozwiązania.

Takie podejście zmienia sposób myślenia o dostępności – z kosztownego obowiązku na element dialogu z rynkiem. Wykonawcy, którzy widzą, że ich uwagi faktycznie przekładają się na zmiany, chętniej korzystają z platformy, zamiast szukać sposobów obejścia systemu.

Dostępność cyfrowa jako kryterium jakości w zamówieniach na systemy IT

Podczas oceny ofert na budowę nowej platformy e-zamówień zazwyczaj skupia się na cenie, terminie i funkcjonalnościach. Dopiero po podpisaniu umowy pojawia się pytanie: „A jak z dostępnością?”. Wtedy większość kart jest już rozdana, a margines negocjacji – minimalny.

Jeżeli dostępność ma być realnym priorytetem, musi znaleźć odzwierciedlenie w kryteriach oceny ofert. Poza obligatoryjnym wymaganiem zgodności z WCAG 2.1 AA, można stosować miękkie, ale policzalne elementy:

• Doświadczenie zespołu wykonawcy – liczba i charakter wcześniejszych realizacji dostępnych systemów, udział specjalisty ds. dostępności w projekcie.
• Propozycja procesu zapewnienia dostępności – opis planowanych testów, narzędzi, udziału użytkowników z niepełnosprawnościami.
• Model utrzymania – sposób zapewnienia ciągłości dostępności przy aktualizacjach i rozwijaniu systemu.

Tak zdefiniowane kryteria premiują dostawców, którzy faktycznie mają kompetencje, a nie tylko dopiszą „WCAG” w jednym punkcie oferty. Z perspektywy wykonawców z niepełnosprawnościami oznacza to większą szansę, że końcowy system będzie stabilny i przewidywalny pod kątem obsługi.

Zapisy umowne i odbiór prac pod kątem dostępności

Przy podpisywaniu umowy na budowę lub modernizację platformy łatwo zgodzić się na ogólny zapis „system będzie zgodny z WCAG 2.1 AA”. Po roku, gdy zamawiający zgłasza problemy, wykonawca IT odpowiada, że „interpretacja kryteriów jest różna” i zaczyna się przeciągająca wymiana pism.

Ryzyko takich sporów można ograniczyć, precyzyjnie opisując w umowie sposób weryfikacji dostępności. Pomaga kilka prostych elementów:

• Lista kryteriów sukcesu – wskazanie, które punkty WCAG są kluczowe dla procesu e-zamówień (np. dotyczące formularzy, nawigacji, kontrastu, obsługi klawiaturą).
• Metoda testowania – odwołanie do audytu zewnętrznego lub określonego zestawu narzędzi i scenariuszy testowych.
• Warunki odbioru – jasne progi, przy których zamawiający może odmówić odbioru (np. krytyczne błędy uniemożliwiające złożenie oferty za pomocą klawiatury).
• Mechanizm poprawek – terminy i zasady usuwania usterek dostępności, w tym tych zgłoszonych przez użytkowników po uruchomieniu systemu.

Tak skonstruowane zapisy nie są „dodatkową biurokracją”, ale formą zabezpieczenia dla obu stron. Zamawiający zyskuje narzędzie egzekwowania jakości, a wykonawca IT – jasne kryteria, które może uwzględnić w wycenie i harmonogramie projektu.

Dostępne dokumenty i załączniki w procesie e-zamówień

Nawet najlepiej zaprojektowana platforma nie pomoże, jeśli kluczowe dokumenty postępowania są zeskanowanymi obrazami lub nieprawidłowo przygotowanymi plikami PDF. Wykonawca niewidomy może bez problemu przejść przez formularz, ale zatrzyma się na ogłoszeniu zapisanym jako „obraz w PDF-ie”, którego czytnik ekranu nie potrafi odczytać.

W praktyce wiele problemów wynika nie z samej technologii, lecz z nawyków pracy z dokumentami w instytucji. Typowe pułapki to:

• Skany bez warstwy tekstowej – dokumenty przygotowane na papierze i zeskanowane w formie obrazu, bez OCR.
• Brak struktury nagłówków – długie specyfikacje przygotowane „wizualnie”, ale bez użycia stylów, co utrudnia nawigację skrótami klawiaturowymi.
• Tabele bez nagłówków – zestawienia wymagań lub kryteriów ocen, w których czytnik ekranu nie potrafi powiązać komórek z odpowiednimi opisami.
• Nieopisane załączniki graficzne – wykresy, schematy i rysunki będące integralną częścią wymagań, pozbawione opisów tekstowych.

Rozwiązanie często leży w prostych standardach redakcyjnych: stosowaniu stylów nagłówków, opisów tabel, generowaniu dostępnych PDF-ów z edytora, a przy skanach – obligatoryjnym zastosowaniu OCR i weryfikacji, czy tekst jest odczytywalny. Niewielkie zmiany w codziennej pracy zamawiających znacząco wpływają na to, czy wykonawca z niepełnosprawnością będzie w stanie samodzielnie zapoznać się z dokumentacją.

Szkolenia dla pracowników instytucji i dostawców IT

Pracownik działu zamówień publicznych przygotowuje ogłoszenie, wrzuca kilkanaście załączników, klika „opublikuj” i przechodzi do kolejnych zadań. Nie ma złej woli – nikt mu po prostu nie pokazał, jak jego decyzje wpływają na dostępność dla konkretnych ludzi.

Bez podstawowej wiedzy o dostępności nawet najlepsze procedury pozostaną na papierze. Dlatego szkolenia powinny obejmować nie tylko informatyków, lecz także osoby tworzące treści i obsługujące postępowania. Praktyczny program może zawierać m.in.:

• Podstawy korzystania z technologii asystujących – krótkie ćwiczenia z czytnikiem ekranu czy obsługą klawiaturą, aby pracownicy zobaczyli, jak wygląda „świat po drugiej stronie ekranu”.
• Tworzenie dostępnych dokumentów – praca na realnych szablonach SIWZ, formularzy ofertowych, protokołów postępowań.
• Rozpoznawanie typowych błędów – szybkie checklisty dla osób publikujących ogłoszenia, np. czy załączniki mają tekst, czy film ma napisy.
• Rola dostępności w postępowaniach – jak prawidłowo opisać wymagania, oceniać oferty, rozmawiać z wykonawcą IT.

Dobrze prowadzone szkolenia przynoszą jeszcze jeden efekt uboczny: zmieniają optykę. Zamiast pytać „czy musimy to robić?”, coraz częściej pada pytanie „jak to zrobić sensownie, żeby nie komplikować pracy, a nie wykluczać wykonawców?”.

Proste praktyki, które od razu poprawiają dostępność platformy

Nie każda instytucja ma od razu budżet na duże prace programistyczne i szeroki audyt. Część barier można jednak zmniejszyć stosunkowo szybko, często przy użyciu już dostępnych narzędzi konfiguracyjnych.

Przykłady takich „szybkich wygranych” to m.in.:

• Dostosowanie kontrastu i wielkości czcionek – wybór ciemniejszych kolorów w motywie, zwiększenie domyślnego rozmiaru tekstu tam, gdzie platforma na to pozwala.
• Uzupełnienie etykiet pól – dopisanie brakujących opisów przy przyciskach i polach formularzy w warstwie tekstowej, nawet jeśli sam układ graficzny pozostaje bez zmian.
• Dodanie logicznej struktury treści – stosowanie nagłówków i list w opisach ogłoszeń, aby ułatwić nawigację czytnikiem ekranu.
• Udostępnienie alternatywnych kanałów kontaktu – dedykowana skrzynka e-mail do zgłoszeń problemów technicznych, prosty formularz kontaktowy, możliwość komunikacji tekstowej.
• Opisanie procedury zgłaszania barier – widoczny link „Zgłoś problem z dostępnością” prowadzący do krótkiego formularza, którego obsługą zajmuje się wyznaczona osoba.

Takie działania nie zastąpią pełnego dostosowania do WCAG, ale często decydują o tym, czy wykonawca z niepełnosprawnością będzie mógł w praktyce złożyć ofertę dziś, a nie za kilka lat – po zakończeniu dużego projektu modernizacyjnego.

Najczęściej zadawane pytania (FAQ)

Jakie są najczęstsze bariery na platformach e-zamówień dla osób z niepełnosprawnościami?

Wykonawca loguje się na platformę, zegar do końca składania ofert tyka, a czytnik ekranu „widzi” tylko anonimowe przyciski i nieopisane pola. W praktyce oznacza to, że ktoś technicznie dopuszczony do postępowania, realnie nie ma szans złożyć oferty bez pomocy innych.

Najczęściej pojawiają się bariery takie jak: brak etykiet przycisków i pól formularzy, skany PDF zamiast dostępnych plików, formularze nieobsługiwane z klawiatury, agresywne liczniki czasu z krótką sesją, brak informacji o błędach w sposób dostępny dla czytników ekranu oraz brak prostego kanału do zgłaszania problemów z dostępnością (np. adresu e-mail czy formularza). Każda z nich może zablokować udział w postępowaniu na którymś z etapów – od rejestracji po podpisanie oferty.

Czy prawo zamówień publicznych wymaga dostępności cyfrowej platform e-zamówień?

W przepisach nie znajdzie się katalogu: „przycisk ma mieć taką i taką etykietę”, ale pojawia się jasny obowiązek równego traktowania wykonawców i niedyskryminacji. Jeśli system do komunikacji elektronicznej jest niedostępny dla części wykonawców z niepełnosprawnościami, w praktyce łamana jest ta podstawowa zasada.

Platforma e-zamówień, moduł do zadawania pytań, repozytorium dokumentów czy system składania ofert to usługi cyfrowe podmiotu publicznego. Podlegają więc wymogom dostępności cyfrowej tak jak strony urzędów, BIP czy aplikacje mobilne. Brak dostępności może prowadzić do zarzutów naruszenia prawa zamówień publicznych oraz przepisów o dostępności cyfrowej.

Jakie przepisy regulują dostępność cyfrową w zamówieniach publicznych?

Często wygląda to tak: zamawiający ma „odhaczoną” platformę, terminy, publikacje – wszystko formalnie gra, dopóki ktoś nie wskaże, że nie mógł w ogóle wejść do „cyfrowego budynku”. Wtedy na stół trafiają nie tylko regulacje zamówieniowe, lecz także przepisy o dostępności.

Kluczowe akty to: Prawo zamówień publicznych (zasada równego traktowania, niedyskryminacji), ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych oraz powiązane wytyczne krajowe. Technicznym punktem odniesienia jest standard WCAG 2.1 (co najmniej poziom AA), który przekłada ogólny obowiązek dostępności na konkretne wymagania wobec interfejsów, formularzy i dokumentów.

Jak zamawiający może sprawdzić, czy platforma e-zamówień jest dostępna dla osób z niepełnosprawnościami?

Często pierwszy sygnał to telefon albo wiadomość od wykonawcy: „nie mogę przejść ekranu logowania, bo nie wiem, gdzie jest pole hasła”. Zamiast czekać na takie alarmy, warto podejść do tematu jak do audytu bezpieczeństwa – tylko że dotyczącego dostępności.

Podstawowe kroki to: wpisanie w umowie z dostawcą oprogramowania wymogu zgodności z WCAG 2.1 AA, przeprowadzenie audytu dostępności (przez zewnętrznych specjalistów lub wewnętrzny zespół), przetestowanie kluczowych funkcji z użyciem czytnika ekranu i samej klawiatury oraz sprawdzenie jakości publikowanych dokumentów (np. czy PDF zawiera tekst, nagłówki, logiczną strukturę). Ważne, aby testy powtarzać przy każdej większej modyfikacji systemu.

Co zrobić, gdy jako wykonawca z niepełnosprawnością nie mogę złożyć oferty przez platformę?

Najczęściej wygląda to tak: czas leci, system „wyrzuca” z sesji, a formularz nie reaguje na klawiaturę. W takiej sytuacji liczy się szybka reakcja i udokumentowanie problemu, żeby zamawiający miał szansę zadziałać, a w razie sporu istniały konkretne dowody.

W pierwszej kolejności warto: zgłosić problem pisemnie do zamawiającego (e-mailem lub przez formularz – jeśli jest dostępny), opisać dokładnie barierę (co, gdzie, przy użyciu jakiego oprogramowania asystującego nie działa) oraz zażądać zapewnienia dostępnej formy komunikacji lub wydłużenia terminu. Jeśli reakcja jest niewystarczająca, możliwe są dalsze kroki: skarga do organów nadzoru nad dostępnością cyfrową, a w określonych sytuacjach – wykorzystanie środków ochrony prawnej w zamówieniach publicznych (np. odwołania).

Jak stosować WCAG 2.1 w praktyce przy platformach e-zamówień?

WCAG często brzmi dla urzędników jak „język programistów”, ale na końcu chodzi o bardzo przyziemne rzeczy: czy przycisk „Złóż ofertę” jest jednoznacznie opisany, czy można przejść cały formularz z klawiatury, czy kontrast tła i tekstu nie męczy wzroku.

Przy e-zamówieniach szczególnie ważne są wymagania dotyczące: formularzy (etykiety pól, komunikaty o błędach, logiczna kolejność przechodzenia tabulatorem), nawigacji klawiaturą, odpowiednich kontrastów, opisów przycisków i ikon, a także struktury dokumentów (nagłówki, listy, tekst alternatywny w plikach). Standard pomaga też w planowaniu – można wpisać do SIWZ lub umowy z dostawcą konkret: „zgodność z WCAG 2.1 na poziomie AA potwierdzona audytem”.

Jakie są konsekwencje braku dostępności cyfrowej w postępowaniach o udzielenie zamówienia publicznego?

Brak dostępności zwykle najpierw boli konkretnego przedsiębiorcę, który nie złoży oferty. Po chwili wraca rykoszetem do zamawiającego: mniej ofert, słabsza konkurencja, gorsze warunki cenowe i rosnące ryzyko skarg.

Konsekwencje mogą obejmować: skargi do organów nadzorujących dostępność cyfrową, zarzuty naruszenia zasady równego traktowania wykonawców, konieczność zmiany platformy lub narzędzi komunikacji w trakcie trwającego postępowania, a także przedłużanie terminów na składanie ofert, jeśli bariery były istotne. Instytucje, które poważnie traktują dostępność, zwykle unikają tych problemów i zyskują lepszy wizerunek oraz szerszy krąg potencjalnych wykonawców.

Najważniejsze punkty

• Elektroniczne zamówienia publiczne bez realnej dostępności cyfrowej w praktyce eliminują część wykonawców z niepełnosprawnościami już na etapie logowania, wypełniania formularzy czy analizy dokumentacji.
• Brak opisów przycisków i pól formularza, niedostępne pliki (np. skany PDF bez tekstu) oraz agresywne liczniki czasu zamieniają standardowe działania na platformie w barierę nie do pokonania dla użytkowników technologii asystujących.
• Platformy e-zamówień są publicznymi usługami cyfrowymi, więc podlegają nie tylko zasadom równego traktowania i niedyskryminacji z Prawa zamówień publicznych, lecz także obowiązkom z ustawy o dostępności cyfrowej.
• Brak dostępnych kanałów kontaktu (np. prostego e-maila do zgłaszania barier) i procedur reagowania na problemy sprawia, że wykonawca z niepełnosprawnością często nie ma jak skutecznie zasygnalizować trudności ani uzyskać wsparcia.
• Standard WCAG 2.1 na poziomie AA stanowi praktyczne minimum techniczne: daje konkretne wytyczne, jak projektować formularze, przyciski, kontrasty, strukturę dokumentów i powinien być wpisany w wymagania wobec dostawców IT.
• Instytucja prowadząca postępowanie odpowiada za dostępność wykorzystywanej platformy, nawet jeśli kupuje ją jako komercyjną usługę; brak wymogów dostępności w umowie z dostawcą nie zwalnia z tej odpowiedzialności.
• Ignorowanie dostępności cyfrowej uderza nie tylko w prawa osób z niepełnosprawnościami, lecz także w samych zamawiających – ogranicza konkurencję, zubaża rynek ofert i zwiększa ryzyko skarg oraz zarzutów dyskryminacji.