Stan prawny na: 02.11.2026
Portal, w którym mieszkańcy rezerwują salę albo zapisują dziecko na zajęcia, to usługa cyfrowa jednostki. Korzystają z niego osoby niewidome z czytnikiem ekranu, osoby, które nie używają myszy, seniorzy z powiększonym tekstem i osoby, które rezerwują na telefonie w słońcu. Jeśli formularz rezerwacji nie działa z klawiatury, część mieszkańców po prostu nie zarezerwuje sali. Wróci do telefonu, a jednostka straci to, po co wdrażała system.
Dostępność cyfrowa jest też obowiązkiem prawnym. W tym artykule opisujemy, jakie wymagania dotyczą portalu rezerwacji, jak podzielić odpowiedzialność z dostawcą i co sprawdzić przed zakupem.
Jakie przepisy dotyczą portalu rezerwacji
Podstawowym aktem jest ustawa o dostępności cyfrowej (t.j. Dz.U. 2023 poz. 1440). Obejmuje ona strony internetowe podmiotów publicznych, w tym jednostek samorządu terytorialnego i ich jednostek organizacyjnych. Wymagania techniczne określa załącznik do ustawy, który odpowiada standardowi WCAG 2.1 na poziomie AA.
Portal rezerwacji prowadzony przez dostawcę w imieniu jednostki jest serwisem tej jednostki. To, że kod napisał ktoś inny, a serwer stoi u dostawcy, nie zdejmuje z jednostki obowiązku zapewnienia dostępności. Dlatego wymagania dostępności powinny trafić do opisu przedmiotu zamówienia i do umowy z dostawcą.
Ustawa przewiduje też deklarację dostępności, procedurę, w której każdy może zażądać zapewnienia dostępności, oraz nadzór nad przestrzeganiem przepisów.
WCAG 2.1 w praktyce systemu rezerwacji
WCAG to zbiór kryteriów pogrupowanych w cztery zasady: postrzegalność, funkcjonalność, zrozumiałość i solidność. Dla portalu rezerwacji najważniejsze są miejsca, w których mieszkaniec coś robi, a nie tylko czyta.
| Element portalu | Na co patrzeć | Przykładowe kryteria WCAG 2.1 |
|---|---|---|
| Kalendarz wolnych terminów | Czy da się wybrać termin klawiaturą? Czy czytnik ekranu odczyta datę i status? Czy status nie jest przekazany wyłącznie kolorem? | 2.1.1 Klawiatura, 1.4.1 Użycie koloru, 4.1.2 Nazwa, rola, wartość |
| Formularz rezerwacji | Czy pola mają etykiety? Czy błędy są opisane tekstem i wskazują pole? | 1.3.1 Informacje i relacje, 3.3.1 Identyfikacja błędu, 3.3.2 Etykiety lub instrukcje |
| Limit czasu na potwierdzenie | Czy mieszkaniec wie, ile ma czasu, i czy może go wydłużyć? | 2.2.1 Dostosowanie czasu |
| Przyciski i linki | Czy kontrast jest wystarczający? Czy fokus jest widoczny? | 1.4.3 Kontrast (minimum), 2.4.7 Widoczny fokus |
| Widok na telefonie | Czy strona działa przy powiększeniu i w orientacji pionowej? | 1.4.4 Zmiana rozmiaru tekstu, 1.4.10 Dopasowanie do ekranu |
| Zabezpieczenie przed botami | Czy nie wymaga rozwiązania zagadki wizualnej bez alternatywy? | 1.1.1 Treść nietekstowa |
| Dokumenty do pobrania | Czy regulamin w PDF ma warstwę tekstową? | 1.1.1, 1.3.1 (dla treści dokumentu) |
Numery i nazwy kryteriów pochodzą ze standardu WCAG 2.1. Tabela nie jest pełną listą; audyt obejmuje wszystkie kryteria poziomów A i AA.
Szczególnie warto przyjrzeć się limitowi czasu. Wiele systemów rezerwacji blokuje termin na kilka lub kilkanaście minut, żeby dwie osoby nie zarezerwowały tej samej godziny. To rozsądne zabezpieczenie, ale osoba korzystająca z czytnika ekranu wypełnia formularz dłużej. Kryterium 2.2.1 wymaga, żeby użytkownik mógł limit wyłączyć, dostosować albo wydłużyć, chyba że zachodzi jeden z wyjątków opisanych w standardzie. Jak dostawca rozwiązuje ten problem, to dobre pytanie na prezentacji.
Kod dostawcy, treści gminy
Przy portalu w modelu abonamentowym odpowiedzialność za dostępność dzieli się na dwie części:
Dostawca odpowiada za kod portalu: strukturę stron, nawigację, formularze, kalendarz, komunikaty błędów, kontrasty w szablonie, działanie z klawiaturą i czytnikiem ekranu. Jednostka nie może tego zmienić, więc musi wymagać tego w umowie.
Jednostka odpowiada za treści, które sama dodaje: opisy obiektów, zdjęcia, pliki PDF z regulaminami, nazwy kategorii, kolor główny portalu. Zeskanowany regulamin bez warstwy tekstowej jest niedostępny niezależnie od jakości portalu.
Dlatego deklaracja dostępności portalu powinna opisywać obie części. Niezgodności w kodzie podaje dostawca na podstawie audytu, niezgodności w treściach - jednostka.
Deklaracja dostępności
Deklaracja dostępności to dokument publikowany w serwisie, który mówi, w jakim stopniu serwis spełnia wymagania, które treści są niedostępne i dlaczego, oraz jak zgłosić problem. Zawiera między innymi:
- dane podmiotu i adres serwisu;
- datę publikacji serwisu i datę ostatniej istotnej aktualizacji;
- status zgodności: zgodny, częściowo zgodny albo niezgodny;
- listę treści niedostępnych z uzasadnieniem;
- datę sporządzenia deklaracji i sposób jej przygotowania (samoocena albo audyt zewnętrzny);
- dane kontaktowe osoby odpowiedzialnej;
- opis procedury żądania zapewnienia dostępności i skargi;
- opcjonalnie informacje o dostępności architektonicznej obiektów.
Portal rezerwacji powinien mieć własną deklarację. Odesłanie do deklaracji strony jednostki nie wystarczy, bo to inny serwis. W ZAJMIJ.TO szablon deklaracji dostępności portalu jest w kreatorze uruchomienia: część dotyczącą systemu wypełnia dostawca, a jednostka uzupełnia swoje dane i treści.
Uwaga na jeden szczegół: portal rezerwacji opisuje obiekty jednostki. Mieszkaniec z niepełnosprawnością ruchową, który zarezerwuje salę online, i tak nie wejdzie do świetlicy po schodach. Dlatego w opisie obiektu warto podać informacje o dostępności architektonicznej: wejście, toaleta, parking. W ZAJMIJ.TO obiekt można oznaczyć między innymi udogodnieniami „schody”, „winda”, „udogodnienia dla osób z niepełnosprawnościami” i „parking”, a mieszkaniec może filtrować obiekty według udogodnień. Punktem wyjścia do własnego dokumentu może być wzór deklaracji dostępności portalu rezerwacji.
Co sprawdzić u dostawcy przed zakupem
- Czy jest aktualny audyt dostępności? Kto go przeprowadził, kiedy, jaką metodą (automat i test ręczny)?
- Czy jest lista znanych niezgodności z terminami usunięcia?
- Czy dostawca przygotowuje treść deklaracji w części dotyczącej kodu?
- Jak wygląda limit czasu na potwierdzenie rezerwacji i czy można go wydłużyć?
- Czy portal działa z klawiatury i czytnikiem ekranu? Warto poprosić o pokazanie rezerwacji bez użycia myszy.
- Czy umowa zobowiązuje dostawcę do usuwania niezgodności i w jakim terminie?
- Jak dostawca informuje o zmianach, które mogą wpłynąć na dostępność?
- Czy system pomaga jednostce dodawać dostępne treści, na przykład pilnuje kontrastu koloru?
Deklaracji „spełniamy WCAG” bez audytu i bez listy niezgodności nie warto przyjmować na słowo. Rzetelna deklaracja często mówi „częściowo zgodny” i podaje, czego to dotyczy.
Jak to wygląda w ZAJMIJ.TO
Piszemy wprost: system projektujemy zgodnie z WCAG 2.1 AA, a 2 listopada 2026 r. zakończyliśmy samoocenę dostępności (WCAG 2.1 AA) bez stwierdzonych niezgodności. To ocena dostawcy, nie zewnętrzny audyt. Portal dla mieszkańców sprawdziliśmy testem automatycznym i ręcznym (klawiatura, powiększenie, drzewo dostępności), panel pracowników urzędu lub jednostki testem automatycznym. Szczegóły zawiera deklaracja dostępności. Kreator uruchamiania konta jednostki ma szablon deklaracji dostępności portalu z wynikiem tej oceny.
System pomaga też jednostce w części, za którą odpowiada sama: kolor główny jednostki, ustawiany w panelu, musi mieć kontrast co najmniej 4,5:1 z białym tekstem przycisków. Panel nie przyjmie koloru, na którym tekst byłby nieczytelny. Portal działa w przeglądarce, także na telefonie, w wersji polskiej, angielskiej i ukraińskiej.
Źródła
- Ustawa o dostępności cyfrowej (Dz.U. 2019 poz. 848, t.j. Dz.U. 2023 poz. 1440).
- Web Content Accessibility Guidelines (WCAG) 2.1, rekomendacja W3C (autoryzowane tłumaczenie na język polski).
- Wytyczne dotyczące deklaracji dostępności publikowane przez ministra właściwego do spraw informatyzacji (gov.pl, „Dostępność cyfrowa”).