p>Wyobraźmy sobie, że audyt szkolnej strony wykazał niedostępne podmenu. Administrator próbuje zmienić ustawienia generatora, ale nie znajduje opcji pozwalającej poprawić obsługę klawiaturą. Dyrektor dowiaduje się, że problem może wymagać zmiany kodu platformy.

Kto ma w takiej sytuacji zapewnić dostępność: szkoła, gmina, Librus czy producent EduPage? Odpowiedź wymaga oddzielenia obowiązku ustawowego od możliwości technicznych i zobowiązań wynikających z umowy.

Odpowiedzialność za dostępność nie jest tym samym co dostęp do kodu

Art. 5 ustawy o dostępności cyfrowej określa obowiązek podmiotu publicznego dotyczący jego stron i zarządzanych elementów. Korzystanie z zewnętrznego generatora nie przenosi automatycznie tego obowiązku na producenta. Jednocześnie to podmiot kontrolujący kod komponentu może mieć techniczną możliwość jego naprawy.

W praktyce publiczna szkoła powinna zarządzać dostępnością swojego serwisu, a gmina jako organ prowadzący może wspierać ją organizacyjnie, finansowo i przy zakupie usług. Konkretne obowiązki gminy, szkoły i dostawcy należy ustalić na podstawie ich ról oraz umowy. Nie należy automatycznie przypisywać dostawcy odpowiedzialności za każdy błąd opublikowanej treści.

Trzy rodzaje błędów dostępności na stronie EduPage

Błędy redakcyjne

Powstają podczas publikacji materiałów – na przykład gdy dokument rekrutacyjny jest wyłącznie skanem, zdjęcie przekazujące ważną informację nie ma opisu lub nagłówki artykułu są tworzone przez pogrubianie tekstu. Zazwyczaj można je usunąć w panelu lub poprawiając plik źródłowy.

Błędy konfiguracji i wyglądu

Mogą wynikać z doboru szablonu, kolorów, układu lub ustawień widżetu. Część da się usunąć poprzez konfigurację. Wersja PRO według dokumentacji oferuje również modyfikowanie CSS w trybie eksperta. Jeśli jednak źródło problemu znajduje się w mechanizmie generującym stronę, zmiana stylów może nie wystarczyć.

Błędy systemowe

Dotyczą sposobu, w jaki aplikacja tworzy interfejs i reaguje na działania użytkownika. Przykładem jest przycisk otwierający menu, którego stan nie jest przekazywany czytnikowi ekranu, albo komponent, którego nie da się uruchomić klawiaturą. Jeżeli administrator nie ma możliwości edycji danego komponentu, konieczne może być zaangażowanie dostawcy.

Kto może usunąć konkretną niezgodność?

Przykładowe bariery WCAG i prawdopodobna ścieżka naprawy

  • Brak opisu istotnego zdjęcia w aktualności: Kryterium WCAG 2.1: 1.1.1. Kto może naprawić: Redaktor.
  • Nagłówek artykułu imitowany pogrubieniem: Kryterium WCAG 2.1: 1.3.1. Kto może naprawić: Redaktor, jeśli edytor to umożliwia.
  • Niedostateczny kontrast tekstu: Kryterium WCAG 2.1: 1.4.3. Kto może naprawić: Administrator lub dostawca, zależnie od źródła.
  • Niedostępne klawiaturowo menu: Kryterium WCAG 2.1: 2.1.1. Kto może naprawić: Dostawca, jeśli wynika z zamkniętego komponentu.
  • Brak mechanizmu pomijania powtarzalnych bloków: Kryterium WCAG 2.1: 2.4.1. Kto może naprawić: Administrator lub dostawca.
  • Niewidoczny fokus klawiatury: Kryterium WCAG 2.1: 2.4.7. Kto może naprawić: Administrator lub dostawca.
  • Przycisk bez dostępnej nazwy lub właściwego stanu: Kryterium WCAG 2.1: 4.1.2. Kto może naprawić: Dostawca, jeśli generuje go silnik.

To przykłady diagnostyczne, a nie wyniki audytu EduPage. Ocena konkretnej niezgodności wymaga sprawdzenia kontekstu. Na przykład brak widocznego linku „Przejdź do treści” nie jest samodzielnym dowodem naruszenia kryterium 2.4.1, jeśli istnieje inny skuteczny mechanizm pomijania bloków.

Czy brak uprawnień do modyfikacji zwalnia szkołę z obowiązku?

Trzeba uwzględnić art. 3 ust. 2 pkt 5 lit. b ustawy, który przewiduje wyłączenie dla określonych treści wymagających modyfikacji, do której podmiot nie ma uprawnień. Nie oznacza to jednak ogólnego wyłączenia całej strony opartej na cudzym CMS. Należy ustalić, czy konkretny element mieści się w ustawowym wyjątku i czy dostępność można zapewnić w inny sposób.

Odrębną podstawą jest art. 8, dotyczący nadmiernych kosztów. Zastosowanie tego przepisu wymaga oceny ustawowych przesłanek i udokumentowania jej wyniku. Sam zakup podstawowej licencji, brak budżetu w bieżącym roku lub brak dostępu do repozytorium nie zastępuje takiej oceny.

W razie braku możliwości zapewnienia dostępności konkretnego elementu należy uwzględnić obowiązek alternatywnego dostępu z art. 7. Dobrze też odnotować niezgodność i jej rzeczywistą podstawę w deklaracji dostępności, zgodnie z wymaganiami dotyczącymi jej sporządzania.

Jak zgłosić błąd systemowy do dostawcy?

Zgłoszenie „strona nie spełnia WCAG” jest zbyt ogólne, aby programista mógł odtworzyć usterkę. Warto przekazać:

  • Dokładny adres strony i nazwę komponentu, szablon oraz wariant licencji, jeśli są znane.
  • Instrukcję odtworzenia problemu krok po kroku, z podaniem urządzenia, przeglądarki i technologii wspomagającej.
  • Opis rzeczywistego działania, oczekiwanego zachowania oraz skutku dla użytkownika.
  • Właściwe kryterium WCAG, dowody i proponowany kierunek naprawy.
  • Prośbę o ustalenie, kto może wprowadzić poprawkę, oraz o termin jej realizacji.

Jeśli licencję zakupiono przez Librus, można skorzystać z kanałów kontaktu wskazanych w pomocy Generatora WWW oraz w umowie. Nie znaleźliśmy w przywołanej dokumentacji publicznej gwarancji terminu naprawy wszystkich błędów WCAG ani potwierdzenia, że każdy rodzaj poprawki jest wliczony w każdą licencję. Trzeba to ustalić z dostawcą.

Co zrobić, gdy rodzic zgłosi problem z dostępnością?

Art. 18 ustawy przewiduje możliwość złożenia żądania zapewnienia dostępności. Co do zasady należy je zrealizować najpóźniej w ciągu 7 dni. Gdy jest to niemożliwe w tym terminie, podmiot informuje o przyczynach i wskazuje termin nie dłuższy niż dwa miesiące od otrzymania żądania. W razie braku możliwości zapewnienia dostępności zgodnie z żądaniem należy wskazać alternatywny sposób dostępu zgodnie z ustawą.

Terminy ustawowe dla podmiotu publicznego nie są automatycznie terminami umownymi dla dostawcy. Dlatego szkoła nie powinna ograniczać się do przekazania zgłoszenia do pomocy technicznej i oczekiwania bez zapewnienia obsługi sprawy użytkownika.

Co powinno znaleźć się w umowie z dostawcą szkolnej strony?

Przy zakupie lub odnowieniu usługi warto ustalić wymagania dostępności, zakres testów odbiorowych, procedurę naprawy błędów systemowych, terminy reakcji, warunki wprowadzania zmian i możliwość eksportu treści w przypadku zmiany platformy. Gmina może wykorzystać tę samą listę wymagań przy zamawianiu usług dla kilku placówek.

Najważniejsze jest, aby szkoła nie pozostawała z raportem audytowym, którego zaleceń nie ma jak wdrożyć. Każda niezgodność powinna mieć określoną ścieżkę rozwiązania, a po poprawce trzeba sprawdzić, czy bariera rzeczywiście zniknęła.

Przeczytaj również

Źródła

Źródło: Ustawa o dostępności cyfrowej – art. 3, 5, 7, 8 i 18 (dostęp: 15.11.2026).

Źródło: Ministerstwo Cyfryzacji – zakres obowiązku dostępności (dostęp: 15.11.2026).

Źródło: Ministerstwo Cyfryzacji – podział ról (dostęp: 15.11.2026).

Źródło: WCAG 2.1 – W3C (dostęp: 15.11.2026).

Źródło: EduPage – warianty licencyjne (dostęp: 15.11.2026).

Źródło: Librus – pomoc Generator WWW (dostęp: 15.11.2026).

Materiał ma charakter informacyjny. Nie przedstawia wyników audytu konkretnej strony EduPage i nie stanowi porady prawnej w indywidualnej sprawie.

Potrzebujesz wsparcia w dostępności strony szkoły?

Prześlij nam adres szkolnego serwisu lub listę stron placówek w gminie. Ustalimy, od czego warto zacząć i jakie działania można zaplanować.

Skontaktuj się z EAC w sprawie audytu dostępności