Aplikacja z dofinansowaniem UE — wymogi WCAG i raportowanie

Projekt informatyczny finansowany ze środków unijnych różni się od komercyjnego nie technologią, lecz obowiązkami wokół niej: dostępnością cyfrową, dokumentacją potwierdzającą kwalifikowalność wydatków, zasadą konkurencyjności przy wyborze wykonawcy i okresem trwałości po zakończeniu. Każdy z tych elementów pominięty na etapie planowania kosztuje przy rozliczeniu.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Dostępność cyfrowa — wymóg, nie zalecenie

W projektach finansowanych ze środków publicznych dostępność cyfrowa jest warunkiem, a nie dobrą praktyką. Odnosi się do wytycznych WCAG na poziomie AA i obejmuje zarówno aplikację, jak i materiały publikowane w jej ramach.

Doprowadzenie gotowego systemu do zgodności kosztuje wielokrotnie więcej niż uwzględnienie wymogów w projekcie. Powód jest prosty: część wymagań dotyczy struktury interfejsu i sposobu budowy komponentów, a nie warstwy wizualnej. Poprawa po fakcie oznacza przebudowę, nie korektę stylów.

• Kontrast co najmniej 4,5 do 1 dla tekstu podstawowego i 3 do 1 dla dużych napisów.
• Pełna obsługa klawiaturą — każda funkcja dostępna bez myszy, z widocznym wskaźnikiem aktywnego elementu.
• Poprawna struktura nagłówków i zastosowanie znaczników zgodnie z ich znaczeniem.
• Etykiety wszystkich pól formularza powiązane z polami, nie umieszczone wyłącznie jako podpowiedź w polu.
• Komunikaty o błędach opisujące, co poprawić, ogłaszane technologiom asystującym.
• Teksty alternatywne dla grafik niosących treść i puste dla dekoracyjnych.
• Napisy do materiałów wideo oraz transkrypcje nagrań dźwiękowych.
• Brak treści migających częściej niż trzy razy na sekundę.
• Deklaracja dostępności z danymi kontaktowymi i procedurą zgłaszania problemów.

Wybór wykonawcy i dokumentacja

Zasada konkurencyjności wymaga udokumentowania, że wykonawca został wybrany w sposób przejrzysty i równy dla wszystkich zainteresowanych. Szczegóły zależą od programu i wartości zamówienia, ale schemat jest powtarzalny.

• Opis przedmiotu zamówienia sformułowany bez wskazywania konkretnego rozwiązania, chyba że jest to obiektywnie uzasadnione.
• Publikacja zapytania we właściwym miejscu i przez wymagany okres.
• Kryteria oceny określone z góry, wraz z wagami i sposobem punktowania.
• Protokół z wyboru zawierający listę ofert i uzasadnienie decyzji.
• Umowa spójna z zapytaniem — rozbieżność zakresu bywa podstawą zakwestionowania wydatku.
• Dokumentacja odbioru potwierdzająca wykonanie zgodne z umową.

Najczęstszy błąd polega na sformułowaniu opisu przedmiotu zamówienia tak, że odpowiada wyłącznie jednemu wykonawcy — na przykład przez wymaganie konkretnej technologii bez uzasadnienia. To wystarcza, żeby zakwestionować całość wydatku, nawet jeśli aplikacja działa bez zarzutu.

Kwalifikowalność wydatków

Ostatni wiersz wymaga szczególnej uwagi przy planowaniu. Utrzymanie aplikacji przez okres trwałości jest obowiązkiem, ale nie jest finansowane. Ten koszt — hosting, aktualizacje bezpieczeństwa, wsparcie użytkowników — trzeba zabezpieczyć w budżecie własnym na kilka lat naprzód.

Okres trwałości — co realnie oznacza

Przez trzy lub pięć lat od zakończenia projektu rezultat musi być utrzymany. W praktyce oznacza to, że aplikacja ma działać, być dostępna dla użytkowników i zachować funkcje opisane we wniosku. Wyłączenie systemu albo istotne ograniczenie jego funkcjonalności może skutkować zwrotem dofinansowania.

Konsekwencje praktyczne dotyczą trzech obszarów. Po pierwsze, budżet: hosting, certyfikaty, aktualizacje i wsparcie przez kilka lat to kwota porównywalna z częścią kosztu wytworzenia. Po drugie, bezpieczeństwo: aplikacja bez aktualizacji staje się podatna sama z siebie, a incydent w okresie trwałości jest problemem także formalnym. Po trzecie, kompetencje: ktoś musi umieć ten system utrzymać, także po zmianie wykonawcy.

Wskaźniki i raportowanie

We wniosku deklaruje się wskaźniki, których osiągnięcie trzeba wykazać. Bywają to liczba użytkowników, liczba obsłużonych spraw, liczba udostępnionych usług elektronicznych. Problem pojawia się wtedy, gdy aplikacja nie zbiera danych potrzebnych do ich udokumentowania.

• Zidentyfikuj wskaźniki przed rozpoczęciem prac i przekaż je wykonawcy jako wymaganie funkcjonalne.
• Zaplanuj raport w systemie generujący dane dokładnie w formie wymaganej przy rozliczeniu.
• Zapewnij możliwość eksportu danych za dowolny okres, także wstecz.
• Uwzględnij ochronę danych — statystyki nie powinny wymagać dostępu do danych osobowych.
• Testuj raport przed zakończeniem projektu, a nie w tygodniu składania wniosku o płatność.

Harmonogram — o czym pamiętać

Projekty dofinansowane mają sztywne terminy, a wydatek poniesiony po okresie kwalifikowalności przestaje być finansowany. Przy projektach informatycznych ryzyko koncentruje się w końcowej fazie, gdzie zwykle kumulują się opóźnienia.

• Zarezerwuj czas na audyt dostępności i poprawki — realnie od dwóch do czterech tygodni.
• Zaplanuj odbiór z wyprzedzeniem wobec końca okresu kwalifikowalności.
• Rozlicz etapy pośrednio, zamiast całość na końcu — ogranicza to ryzyko przy opóźnieniu.
• Uwzględnij czas na procedurę wyboru wykonawcy, która sama zajmuje kilka tygodni.

Kontrola projektu — na co patrzą kontrolerzy

Kontrola może nastąpić w trakcie realizacji, przy rozliczeniu końcowym albo w okresie trwałości. Zakres bywa różny, ale pytania powtarzają się na tyle, że warto przygotować odpowiedzi z wyprzedzeniem — a przede wszystkim zadbać o dokumentację w trakcie, a nie odtwarzać ją po fakcie.

• Dokumentacja wyboru wykonawcy — zapytanie, oferty, protokół, uzasadnienie decyzji.
• Zgodność zakresu umowy z zapytaniem ofertowym i z wnioskiem o dofinansowanie.
• Protokoły odbioru potwierdzające wykonanie zgodne z umową.
• Dowód działania rezultatu — aplikacja dostępna, funkcje zgodne z opisem we wniosku.
• Zgodność z wymogami dostępności — najczęściej weryfikowana przez audyt.
• Dane wskaźnikowe możliwe do wygenerowania z systemu.
• Oznaczenia informacyjne o źródle finansowania, jeśli są wymagane.

Najczęstsza przyczyna problemów

Nie jest nią jakość aplikacji, lecz rozjechanie się dokumentów. Zakres opisany we wniosku, zakres z zapytania ofertowego i zakres z umowy z wykonawcą powinny być spójne. W praktyce projekt ewoluuje, zakres się zmienia, a dokumentacja zostaje przy pierwotnej wersji.

Rozwiązaniem jest prowadzenie zmian formalnie — aneksami do umowy i, jeśli to konieczne, wnioskami o zmianę w projekcie. To praca administracyjna, którą łatwo odłożyć, a której brak potrafi zakwestionować wydatek na system działający bez zarzutu.

Podsumowanie

W projekcie dofinansowanym jakość aplikacji jest warunkiem koniecznym, ale niewystarczającym. O rozliczeniu decydują dostępność cyfrowa spełniająca wytyczne WCAG na poziomie AA, poprawnie udokumentowany wybór wykonawcy oraz zdolność do utrzymania rezultatu przez okres trwałości.

Trzy decyzje podjęte na starcie usuwają większość ryzyka: wpisanie wymogów dostępności do zapytania ofertowego, zastrzeżenie przekazania kodu wraz z dokumentacją i prawami do dalszego rozwoju oraz zabezpieczenie w budżecie własnym kosztu utrzymania na cały okres trwałości. Każda z nich kosztuje niewiele na etapie planowania i bardzo dużo, gdy trzeba ją nadrabiać przy kontroli.