Dostępność cyfrowa (WCAG) w systemach Budżetu Obywatelskiego

Q: Czym jest dostępność cyfrowa (wcag) w systemach budżetu obywatelskiego?

Jak zapewnić dostępność systemu BO dla osób z niepełnosprawnościami? Wymagania WCAG 2.1 AA, obowiązki prawne, praktyczne wskazówki, audyt i checklist dla samorządów.

Dostępność cyfrowa to nie tylko wymóg prawny, ale przede wszystkim kwestia równego dostępu do demokracji. System Budżetu Obywatelskiego musi być użyteczny dla wszystkich mieszkańców — w tym osób niewidomych, słabowidzących, głuchych, z ograniczeniami motorycznymi i osób starszych. W Polsce żyje 4,7 mln osób z niepełnosprawnościami (GUS, 2024), a kolejne miliony doświadczają czasowych lub sytuacyjnych ograniczeń. Jeśli system BO ich wyklucza, to nie jest prawdziwa partycypacja.

Wymogi prawne — co mówi polskie prawo

Ustawa o dostępności cyfrowej (2019)

Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych nakłada obowiązek zapewnienia dostępności zgodnie z WCAG 2.1 na poziomie AA. Dotyczy to:

Stron internetowych (w tym systemów BO online)
Aplikacji mobilnych (natywnych i PWA)
Dokumentów publikowanych online (PDF, DOCX)
Materiałów multimedialnych (filmy, animacje)

Kto podlega: Wszystkie podmioty publiczne — gminy, miasta, starostwa. Jeśli system BO jest prowadzony przez gminę (bezpośrednio lub przez zewnętrznego dostawcę), musi spełniać wymogi ustawy.

Ustawa o zapewnianiu dostępności (2019)

Ustawa z dnia 19 lipca 2019 r. o zapewnianiu dostępności osobom ze szczególnymi potrzebami (tzw. “ustawa o dostępności”) rozszerza wymogi:

Art. 6 — podmioty publiczne muszą zapewnić dostępność cyfrową, architektoniczną i informacyjno-komunikacyjną
Art. 18 — każda osoba ze szczególnymi potrzebami może złożyć wniosek o zapewnienie dostępności
Art. 29 — skarga do Prezesa PFRON na brak dostępności (po bezskutecznym wniosku)

European Accessibility Act (2025)

Od 28 czerwca 2025 r. obowiązuje dyrektywa UE 2019/882 (European Accessibility Act), która rozszerza wymogi dostępności na podmioty prywatne świadczące usługi cyfrowe. Dla systemów BO oznacza to, że dostawcy zewnętrzni (firmy IT tworzące platformy BO) muszą zapewnić dostępność swoich produktów.

Sankcje za brak dostępności

Naruszenie	Procedura	Konsekwencje
Brak deklaracji dostępności	Skarga do MC	Kara pieniężna do 10 000 zł
Nieuzasadniona niedostępność	Wniosek → skarga do PFRON	Zobowiązanie do zapewnienia dostępności
Powtórne naruszenia	Postępowanie MC	Kara do 100 000 zł
Dyskryminacja	Pozew cywilny	Odszkodowanie + zadośćuczynienie

Przykład: W 2024 roku Rzecznik Praw Obywatelskich interweniował w sprawie systemu BO jednego z miast wojewódzkich, którego platforma głosowania nie była dostępna dla osób niewidomych (brak alt-text, brak obsługi klawiatury). Miasto musiało w ciągu 3 miesięcy naprawić system — kosztem 85 tys. zł.

WCAG 2.1 — co to oznacza w praktyce dla systemu BO

4 zasady dostępności (POUR)

Standard WCAG 2.1 opiera się na 4 zasadach, każda z konkretnymi wytycznymi:

1. Postrzegalność (Perceivable)

Treść musi być prezentowana w sposób dostępny dla zmysłów użytkownika — jeśli ktoś nie widzi, musi usłyszeć lub poczuć.

Co to oznacza w systemie BO:

Każdy obraz (zdjęcie projektu, mapa, infografika) musi mieć tekst alternatywny opisujący zawartość
Filmy promujące BO muszą mieć napisy (closed captions)
Kontrast kolorów tekstu do tła musi spełniać minimum (4.5:1 dla normalnego tekstu)
Informacja nie może być przekazywana wyłącznie kolorem (np. “zielony = dopuszczony, czerwony = odrzucony” — dodaj ikonę lub tekst)

2. Funkcjonalność (Operable)

Interfejs musi być używalny przez każdego — w tym osoby, które nie mogą korzystać z myszy.

Co to oznacza w systemie BO:

Cały proces — od przeglądania projektów, przez logowanie, po oddanie głosu — musi być możliwy wyłącznie klawiaturą
Fokus musi być widoczny (użytkownik klawiatury musi widzieć, gdzie jest)
Brak pułapek klawiatury (użytkownik nie może “utknąć” w elemencie)
Czas na oddanie głosu musi być wystarczający (lub z możliwością przedłużenia)
Animacje muszą mieć możliwość wyłączenia (ważne dla osób z epilepsją)

3. Zrozumiałość (Understandable)

Treść i obsługa muszą być zrozumiałe — język musi być prosty, interfejs przewidywalny.

Co to oznacza w systemie BO:

Język strony musi być określony w HTML (lang="pl") — czytniki ekranu muszą wiedzieć, w jakim języku czytać
Formularze muszą mieć czytelne etykiety i jasne komunikaty błędów (“Pole wymagane: numer PESEL” zamiast “Error 422”)
Nawigacja musi być spójna — menu w tym samym miejscu na każdej stronie
Instrukcje muszą być dostępne przed formularzem (nie po nim)

4. Solidność (Robust)

Treść musi działać z różnymi technologiami wspomagającymi — czytnikami ekranu, lupami, switch-ami.

Co to oznacza w systemie BO:

Poprawny, walidowalny HTML (semantyczne tagi: <nav>, <main>, <form>, <button>)
Atrybuty ARIA tam, gdzie semantyka HTML nie wystarcza
Testowanie z rzeczywistymi technologiami wspomagającymi (nie tylko automatycznymi narzędziami)

Praktyczne wymagania dla każdego elementu systemu BO

Strona główna BO i lista projektów

Nawigacja klawiaturą:

Tab przeskakuje między elementami interaktywnymi (linki, przyciski, formularze) w logicznej kolejności
Shift+Tab cofa się
Enter aktywuje element
Skip-link (“Przejdź do treści”) na początku strony — pozwala pominąć powtarzalne menu

Kontrast kolorów:

Element	Wymagany kontrast (AA)	Przykład poprawny	Przykład błędny
Tekst podstawowy (16px)	4.5:1	#1E293B na #FFFFFF (15.8:1)	#94A3B8 na #FFFFFF (3.1:1)
Nagłówki (24px+)	3:1	#334155 na #FFFFFF (9.7:1)	#CBD5E1 na #FFFFFF (1.5:1)
Przyciski (tekst na tle)	4.5:1	#FFFFFF na #1E40AF (8.6:1)	#FFFFFF na #93C5FD (1.6:1)
Linki (w tekście)	4.5:1 + wyróżnienie	#1E40AF podkreślony	#3B82F6 bez podkreślenia
Ikony statusu	3:1 + tekst/kształt	Zielony kółko + tekst “Dopuszczony”	Tylko zielony kółko

Listy projektów:

Karty projektów muszą być obsługiwalne klawiaturą (Tab → Enter)
Filtry (kategoria, dzielnica) muszą być dostępne jako <select> lub radio buttons z etykietami
Sortowanie musi informować czytnik ekranu o zmianie kolejności (aria-live="polite")
Paginacja: jasne etykiety (“Strona 2 z 15”, nie “2”)

Formularz zgłaszania projektów

Etykiety i powiązania:

Każde pole formularza musi mieć etykietę (<label for="field-id">)
Grupy pól (np. dane kontaktowe) pogrupowane w <fieldset> z <legend>
Pola wymagane oznaczone zarówno wizualnie (*), jak i semantycznie (aria-required="true")

Komunikaty błędów:

Komunikat błędu musi pojawić się przy polu, nie na górze strony
Treść komunikatu musi jasno mówić, co jest źle (“Numer PESEL musi mieć 11 cyfr”, nie “Nieprawidłowe dane”)
Komunikat musi być powiązany z polem (aria-describedby)
Po błędzie fokus automatycznie przenosi się na pierwsze pole z błędem

Wielokrokowy formularz:

Pasek postępu musi informować czytnik ekranu (“Krok 2 z 5: Lokalizacja projektu”)
Przycisk “Wstecz” musi zachować dane (nie kasować wypełnionych pól)
Autosave — formularz zapisuje postęp automatycznie (ważne dla osób, które potrzebują więcej czasu)

System głosowania

Karta projektu do głosowania:

Nazwa projektu jako nagłówek (<h2> lub <h3>)
Opis dostępny w rozwinięciu (nie ukryty w tooltip)
Przycisk “Głosuj” z czytelną etykietą (aria-label="Głosuj na projekt: Plac zabaw przy ul. Kwiatowej")
Potwierdzenie głosu: komunikat aria-live="assertive" (“Twój głos został oddany na projekt: Plac zabaw”)

Weryfikacja PESEL/SMS:

Pole PESEL z autoformatem (11 cyfr, bez myślników)
Czas na wpisanie kodu SMS: minimum 5 minut (z możliwością ponownego wysłania)
Jasny komunikat o wysłaniu SMS (“Wysłaliśmy kod na numer --789. Wpisz go poniżej.”)

Mapa interaktywna

Mapa to najtrudniejszy element do uczynienia dostępnym. Rozwiązanie: zapewnij równoważną alternatywę tekstową.

Podejście rekomendowane:

Mapa jako dodatkowe narzędzie, nie jedyny sposób przeglądania projektów
Lista projektów z adresami (dostępna zawsze, niezależnie od mapy)
Filtry po dzielnicy zastępują nawigację po mapie
Mapa z obsługą klawiatury: Tab przeskakuje między pinezkami, Enter otwiera kartę projektu

Dla osób niewidomych:

Tekst: “Projekt zlokalizowany na ul. Kwiatowej 12, dzielnica Wrzeszcz Górny, w odległości ok. 500 m od Twojej lokalizacji”
Przyciski filtów dzielnicy zamiast nawigacji po mapie

Dokumenty i multimedia

PDF (regulamin, raporty):

PDF musi być “tagged” (strukturalny) — nie skan papierowego dokumentu
Alternatywnie: wersja HTML regulaminu (lepsza od PDF)
Tabele w PDF z nagłówkami (<TH>)

Filmy (promocja BO, instrukcje):

Napisy zamknięte (closed captions) — obowiązkowe
Audiodeskrypcja dla osób niewidomych — opcjonalna, ale rekomendowana
Transkrypcja tekstowa — obowiązkowa (tekst pod filmem)

Testowanie dostępności — 3 poziomy

Poziom 1: Testy automatyczne (konieczne, ale niewystarczające)

Automatyczne narzędzia wykrywają ok. 30-40% problemów z dostępnością — głównie techniczne (brak alt-text, niski kontrast, brakujące etykiety).

Narzędzia:

Narzędzie	Typ	Koszt	Co testuje
WAVE (wave.webaim.org)	Rozszerzenie Chrome	Bezpłatne	Strukturę, kontrast, ARIA, linki
Lighthouse (Chrome DevTools)	Wbudowane w Chrome	Bezpłatne	Ogólna dostępność, performance
axe DevTools	Rozszerzenie Chrome	Bezpłatne / Pro	Szczegółowa analiza WCAG
Pa11y	CLI (automatyzacja)	Open source	CI/CD pipeline
SiteImprove	SaaS	Płatne (od 500€/mies.)	Monitoring ciągły, raporty

Rekomendacja: WAVE + axe DevTools — bezpłatne, komplementarne, wystarczające do regularnych kontroli.

Poziom 2: Testy manualne (kluczowe)

Większość krytycznych problemów z dostępnością wymaga testowania manualnego:

Nawigacja klawiaturą (15-30 minut):

Odłóż mysz
Przejdź przez cały proces BO (przeglądanie → logowanie → głosowanie) używając TYLKO klawiatury
Sprawdź: Czy fokus jest widoczny? Czy można dotrzeć do każdego elementu? Czy nie ma pułapek?

Czytnik ekranowy (30-60 minut):

Włącz NVDA (Windows, bezpłatny) lub VoiceOver (macOS, wbudowany)
Zamknij oczy i spróbuj przejść przez proces BO wyłącznie słuchając
Sprawdź: Czy nagłówki tworzą logiczną hierarchię? Czy formularze mają etykiety? Czy komunikaty błędów są odczytywane?

Powiększenie 200% (5-10 minut):

Ctrl+Plus (lub Command+Plus) do 200% zoom
Sprawdź: Czy tekst nie jest obcinany? Czy layout się nie “psuje”? Czy wszystkie elementy są widoczne?

Tryb wysokiego kontrastu (5-10 minut):

Windows: Ustawienia → Dostępność → Kontrast. macOS: Ustawienia → Dostępność → Wyświetlacz
Sprawdź: Czy tekst jest czytelny? Czy przyciski są widoczne? Czy ikony nie znikają?

Poziom 3: Testy z użytkownikami z niepełnosprawnościami (najcenniejsze)

Kogo zaprosić do testów:

1-2 osoby niewidome (czytnik ekranu — NVDA, JAWS, VoiceOver)
1-2 osoby słabowidzące (lupa ekranowa, powiększenie)
1 osoba z ograniczeniami motorycznymi (klawiatura, switch, eye-tracking)
1-2 osoby starsze (65+, ograniczona sprawność cyfrowa)

Jak zorganizować:

Skontaktuj się z lokalną organizacją osób niepełnosprawnych (PZN, PZG, fundacje)
Sesja testowa: 60-90 minut, wynagrodzenie 200-400 zł/osobę
Scenariusz: “Znajdź projekt w swojej dzielnicy i oddaj na niego głos”
Moderator notuje problemy, nie pomaga (obserwacja, nie instruktaż)

Koszt: 2000-5000 zł za sesję z 5-8 testerami. Jednorazowo przed premierą, potem raz w roku.

Przykład z Wrocławia: Przed wdrożeniem systemu BO, miasto zorganizowało testy z 6 osobami z niepełnosprawnościami. Odkryto 14 problemów (3 krytyczne), w tym: brak obsługi klawiatury w filtrze dzielnic, nieczytelne etykiety pól formularza i brak informacji zwrotnej po oddaniu głosu. Naprawa kosztowała 12 tys. zł — vs. potencjalna interwencja RPO i kara.

Dostępność w praktyce — rozwiązania dla typowych problemów BO

Problem: Formularz wielokrokowy trudny do nawigacji

Rozwiązanie:

Pasek postępu jako <ol> z aria-current="step" na aktywnym kroku
Przycisk “Wstecz” widoczny i dostępny klawiaturą
Podsumowanie przed wysłaniem (użytkownik weryfikuje wszystkie dane)
Autosave co 30 sekund (ważne dla osób potrzebujących więcej czasu)

Problem: Mapa niedostępna dla czytników ekranu

Rozwiązanie:

Alternatywna nawigacja: dropdown z dzielnicami + lista projektów
Tekst pod mapą: “Mapa przedstawia [X] projektów w [Y] dzielnicach. Użyj filtrów powyżej, aby znaleźć projekty w swojej okolicy.”
Każda pinezka na mapie ma aria-label z nazwą projektu

Problem: Timeout sesji podczas głosowania

Rozwiązanie (kryterium WCAG 2.2.1):

Ostrzeżenie 2 minuty przed wygaśnięciem sesji
Przycisk “Przedłuż sesję” (dostępny klawiaturą)
Minimum 20 minut na proces głosowania (nie 10)
Zachowanie stanu (wybrane projekty) po ponownym zalogowaniu

Problem: Materiały wideo bez napisów

Rozwiązanie:

Automatyczne napisy (YouTube) jako punkt wyjścia
Korekta ręczna (automatyczne napisy mają ok. 85% dokładności)
Transkrypcja tekstowa pod filmem
Audiodeskrypcja dla filmów z wizualnymi treściami bez dialogu

Deklaracja dostępności — obowiązek prawny

Każdy podmiot publiczny musi opublikować deklarację dostępności swojej strony (w tym systemu BO). Deklaracja musi zawierać:

Status zgodności: Pełna / Częściowa / Niezgodna z WCAG 2.1 AA
Treści niedostępne i powody (z planem naprawy)
Data sporządzenia i metoda oceny (automatyczna, manualna, audyt)
Dane kontaktowe — koordynator ds. dostępności (email, telefon)
Procedura wniosku o zapewnienie dostępności
Informacja o dostępności architektonicznej (punkty stacjonarne BO)

Termin: Deklaracja musi być aktualizowana co roku do 31 marca.

Wzór: Ministerstwo Cyfryzacji udostępnia generator deklaracji dostępności: dostepnosc.gov.pl

Checklist WCAG 2.1 AA dla systemu BO

Poziom A (absolutne minimum)

Poziom AA (wymagany prawem)

Dostępność ARDVote: Platforma ARDVote spełnia wymogi WCAG 2.1 na poziomie AA — nawigacja klawiaturą, kompatybilność z czytnikami ekranu, odpowiedni kontrast i responsywny design to standard każdego wdrożenia. Sprawdź też zabezpieczenia platformy i pakiety cenowe.

Podsumowanie

Dostępność cyfrowa w systemie Budżetu Obywatelskiego to:

Obowiązek prawny — ustawa o dostępności cyfrowej, WCAG 2.1 AA, European Accessibility Act
Równy dostęp do demokracji — 4,7 mln osób z niepełnosprawnościami + miliony seniorów zasługują na uczestnictwo w BO
Lepsza użyteczność dla wszystkich — dostępny system to system przyjazny dla każdego użytkownika
Mierzalna jakość — testy automatyczne, manualne i z użytkownikami dają konkretne wyniki
Realne konsekwencje — kary finansowe, interwencje RPO, utrata zaufania mieszkańców

Sprawdź dostępność systemu ARDVote →

Wymogi prawne — co mówi polskie prawo

Ustawa o dostępności cyfrowej (2019)

Ustawa o zapewnianiu dostępności (2019)

European Accessibility Act (2025)

Sankcje za brak dostępności

WCAG 2.1 — co to oznacza w praktyce dla systemu BO

4 zasady dostępności (POUR)

1. Postrzegalność (Perceivable)

2. Funkcjonalność (Operable)

3. Zrozumiałość (Understandable)

4. Solidność (Robust)

Praktyczne wymagania dla każdego elementu systemu BO

Strona główna BO i lista projektów

Formularz zgłaszania projektów

System głosowania

Mapa interaktywna

Dokumenty i multimedia

Testowanie dostępności — 3 poziomy

Poziom 1: Testy automatyczne (konieczne, ale niewystarczające)

Poziom 2: Testy manualne (kluczowe)

Poziom 3: Testy z użytkownikami z niepełnosprawnościami (najcenniejsze)

Dostępność w praktyce — rozwiązania dla typowych problemów BO

Problem: Formularz wielokrokowy trudny do nawigacji

Problem: Mapa niedostępna dla czytników ekranu

Problem: Timeout sesji podczas głosowania

Problem: Materiały wideo bez napisów

Deklaracja dostępności — obowiązek prawny

Checklist WCAG 2.1 AA dla systemu BO

Poziom A (absolutne minimum)

Poziom AA (wymagany prawem)

Podsumowanie

Powiązane artykuły