Załóżmy, że gmina prowadzi osiem szkół. Każda ma własną stronę EduPage, a na każdej publikowane są inne dokumenty, aktualności i informacje dla rodziców. Czy wystarczy sprawdzić jedną witrynę, wygenerować deklaracje dostępności i na tym zakończyć?
Nie. Wspólna platforma pozwala ograniczyć powielanie części pracy, ale dostępność każdej placówki zależy również od jej ustawień, zawartości i sposobu publikowania informacji. Dobry audyt powinien uwzględniać zarówno wspólny system, jak i indywidualne różnice.
Jak wygląda audyt dostępności strony szkoły na EduPage?
Audyt powinien odpowiadać na dwa pytania: które wymagania są niespełnione i co trzeba zrobić, aby użytkownik mógł skorzystać z serwisu. W przypadku generatora zewnętrznego potrzebne jest dodatkowe ustalenie, kto ma możliwość wykonania naprawy.
Badanie warto rozpocząć od inwentaryzacji serwisu: szablonu, modułów, nawigacji oraz typów publikowanych treści. Należy wybrać reprezentatywne podstrony i kluczowe procesy. Zakres trzeba ustalić jawnie, tak aby raport nie sugerował zbadania obszarów, których faktycznie nie testowano.
Przykładowy zakres audytu publicznej witryny szkoły
- Strona główna i nawigacja: Menu, podmenu, pomijanie bloków, kolejność fokusu, nazwy elementów.
- Aktualności i podstrony: Nagłówki, listy, opisy grafik, czytelność i sens linków.
- Plan lekcji i tabele: Relacje nagłówków z danymi, możliwość odczytu i obsługi elementów.
- Rekrutacja i dokumenty: Dostępność wybranych plików PDF i DOCX, formularze, terminy i instrukcje.
- Kontakt i wyszukiwarka: Etykiety pól, komunikaty, obsługa klawiaturą, dostępne wyniki.
- Deklaracja dostępności: Zgodność treści i struktury z wymaganiami, łatwość odnalezienia, aktualność.
- Widok mobilny i powiększenie: Czytelność, zmiana układu bez utraty informacji, obsługa elementów.
Jeśli zakres ma obejmować również e-dziennik, panel po zalogowaniu lub aplikację mobilną, należy zaplanować oddzielne testy i uzgodnić dostęp do środowiska. Wynik audytu publicznej strony WWW nie jest oceną całej platformy edukacyjnej.
Dlaczego automatyczny skaner WCAG nie wystarczy?
Automatyczne narzędzia pomagają szybko zlokalizować część usterek technicznych. Nie rozstrzygają jednak, czy opis zdjęcia przekazuje właściwą informację, czy użytkownik czytnika ekranu rozumie plan lekcji lub czy da się ukończyć konkretną czynność bez myszy.
Dlatego badanie powinno łączyć skanowanie automatyczne, analizę kodu i drzewa dostępności z testami manualnymi klawiaturą oraz technologiami wspomagającymi, np. NVDA lub VoiceOver. Warto również sprawdzić zachowanie strony przy powiększeniu tekstu i zmianie rozmiaru okna.
Jak powinien wyglądać raport, żeby dało się go wykorzystać?
Raport powinien przedstawiać błędy w sposób umożliwiający ich odtworzenie. Dla przykładowej niezgodności menu można wskazać adres podstrony, kroki testu, wersję przeglądarki, oczekiwane działanie, kryterium WCAG, wpływ na użytkownika i zakres potrzebnej poprawki.
W przypadku EduPage rekomendujemy dodatkowo klasyfikację według ścieżki naprawy:
- Błędy możliwe do usunięcia przez redaktora lub autora dokumentu.
- Błędy możliwe do usunięcia przez administratora w ramach dostępnych ustawień lub dozwolonych modyfikacji.
- Błędy wymagające współpracy z dostawcą platformy.
- Problemy wymagające dodatkowej analizy uprawnień, umowy albo alternatywnego rozwiązania.
Do każdej pozycji warto przypisać priorytet wynikający z wpływu bariery na użytkowników. Niedostępność informacji o rekrutacji lub brak możliwości skorzystania z nawigacji może wymagać szybszego działania niż drobna usterka mniej istotnego elementu.
Deklaracja dostępności EduPage: czy wystarczy gotowy generator?
Nie. Generator może pomóc przygotować strukturę HTML deklaracji, ale nie ustala samodzielnie faktycznego stanu dostępności. Treść deklaracji musi wynikać z rzeczywistej oceny strony i uwzględniać odpowiednie niezgodności oraz wyłączenia.
Dokumentacja EduPage opisuje utworzenie deklaracji jako modułu tekstowego i wstawianie HTML przez edytor. Przed publikacją należy porównać wygenerowany dokument z aktualnymi warunkami technicznymi Ministerstwa Cyfryzacji – wersja 2.0 obowiązuje w opisanym przez ministerstwo harmonogramie od 2024 r., a wcześniejsze deklaracje należało dostosować do końca marca 2025 r.
Każda placówka powinna mieć deklarację odnoszącą się do własnej strony. Zgodnie z art. 11 ustawy jej przegląd należy przeprowadzać do 31 marca każdego roku oraz niezwłocznie po zmianach mogących wpływać na dostępność. Przegląd nie powinien sprowadzać się do zmiany daty bez zweryfikowania stanu serwisu.
Jak gmina może zorganizować dostępność kilku szkół?
Przy wspólnej platformie warto stworzyć centralny rejestr witryn, licencji i administratorów. Następnie można grupować strony według szablonów i wspólnych komponentów, a wyniki sprawdzać na konkretnych wdrożeniach. Błędy powtarzalne warto skonsolidować w zgłoszeniach do dostawcy.
Równolegle każda szkoła potrzebuje zasad publikowania informacji, odpowiedzialnej osoby i weryfikacji własnych dokumentów. Gmina może zapewnić wspólne szkolenie redaktorów oraz harmonogram kontroli po zmianach szablonów i funkcji.
Naprawa EduPage, zmiana licencji czy migracja strony?
Nie każda niezgodność wymaga wymiany CMS. Jeśli bariera wynika z treści albo ustawień, często można ją usunąć bez zmiany platformy. Jeżeli problem wymaga modyfikacji kodu systemowego, warto najpierw ustalić możliwości dostawcy. Zakup PRO ma sens wtedy, gdy jego dodatkowe funkcje umożliwiają konkretną potrzebną poprawkę.
Dopiero gdy ograniczenia techniczne lub umowne uniemożliwiają usunięcie istotnych barier, można rozważyć wydzielenie publicznej witryny do innego CMS. Funkcje edukacyjne mogą pozostać w dotychczasowym systemie, o ile pozwalają na to umowa i integracje. Sama migracja nie zwalnia z oceny dostępności funkcji, które szkoła nadal wykorzystuje.
Audyt to początek procesu, nie jego koniec
Po wdrożeniu poprawek potrzebny jest retest, a przy kolejnych aktualizacjach i publikacjach – regularna kontrola. Największą wartość daje proces, w którym szkoła wie, jakie bariery usunięto, które pozostają po stronie dostawcy i jak zapewnić użytkownikom dostęp do potrzebnych informacji.
Jeżeli odpowiadasz za jedną szkołę lub grupę placówek, zacznij od adresów witryn i informacji o posiadanych licencjach. Na tej podstawie można zaplanować zakres badania, rozdzielić prace wspólne od indywidualnych i ustalić realny zakres napraw.
Przeczytaj również
- Czy EduPage spełnia WCAG? Dostępność cyfrowa strony internetowej szkoły
- Kto naprawia błędy WCAG w EduPage? Odpowiedzialność szkoły i dostawcy
- Kogo dotyczy dostępność cyfrowa i po co ją zapewniać?
Źródła
Źródło: Ustawa o dostępności cyfrowej (dostęp: 15.11.2026).
Źródło: W3C – WCAG 2.1 (dostęp: 15.11.2026).
Źródło: Ministerstwo Cyfryzacji – warunki techniczne deklaracji dostępności (dostęp: 15.11.2026).
Źródło: Ministerstwo Cyfryzacji – zarządzanie dostępnością (dostęp: 15.11.2026).
Źródło: EduPage – tworzenie deklaracji dostępności (dostęp: 15.11.2026).
Źródło: EduPage – Basic i PRO (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ć.