Jak redaktor może zepsuć dostępność strony zgodnej z WCAG? 8 najczęstszych błędów w CMS

Strona internetowa została zaprojektowana zgodnie z WCAG, przeszła audyt i nie wykryto na niej poważnych barier. Czy to oznacza, że pozostanie dostępna? Niekoniecznie. Każda kolejna aktualizacja treści może wprowadzić nowe problemy. Nieprawidłowo dodany nagłówek, grafika bez tekstu alternatywnego, skan dokumentu czy nieprawidłowo osadzony link wystarczą, aby utrudnić części użytkowników dostęp do informacji. Dlatego redaktor strony internetowej ma znacznie większy wpływ na dostępność cyfrową niż mogłoby się wydawać. Sprawdzamy 8 błędów, które najczęściej mogą pojawić się podczas pracy w CMS.

Wiedza w pigułce

• Strona zgodna z WCAG może utracić dostępność po aktualizacji treści. Nawet jeśli przeszła audyt, nowe artykuły, dokumenty, obrazy czy filmy mogą wprowadzać bariery dla użytkowników.
  
• Redaktor treści ma bezpośredni wpływ na dostępność cyfrową. Nieprawidłowa struktura nagłówków, błędnie przygotowane listy i tabele czy niejasne nazwy linków mogą utrudniać korzystanie z serwisu.
  
• Teksty alternatywne powinny przekazywać znaczenie obrazów, a nie tylko opisywać ich wygląd. Elementy czysto dekoracyjne nie wymagają opisów i powinny mieć pusty atrybut alt="".
  
• Istotne informacje nie powinny być przekazywane wyłącznie za pomocą obrazu lub koloru. Użytkownik powinien mieć możliwość ich odczytania i zrozumienia także bez dostępu do informacji wizualnych.
  
• Dokumenty i multimedia również podlegają wymaganiom dostępności. Skan PDF bez odpowiedniej warstwy tekstowej czy film pozbawiony wymaganych napisów lub alternatyw mogą wykluczać część odbiorców.
  
• Automatyczny WCAG checker pomaga wykrywać część błędów, np. brakujące atrybuty ALT czy niektóre problemy z kontrastem. Nie zastępuje jednak pełnego audytu i oceny treści przez człowieka.
  
• Utrzymanie dostępności wymaga odpowiednich kompetencji redaktorów i regularnej kontroli serwisu. Szkolenia WCAG oraz monitoring kolejnych zmian pomagają ograniczać ryzyko ponownego pojawiania się barier.
  

Dostępność cyfrowa nie kończy się wraz z uruchomieniem strony internetowej. Audyt przeprowadzony przed jej odbiorem pozwala ocenić stan serwisu w określonym momencie. Później pojawiają się jednak nowe aktualności, podstrony, dokumenty, zdjęcia, filmy i komunikaty.

Za dużą część tych materiałów odpowiada już nie wykonawca serwisu, lecz osoba, która na co dzień publikuje treści.

Dlatego przy utrzymywaniu dostępności trzeba rozróżnić dwa obszary:

• dostępność techniczną, związaną między innymi z kodem, nawigacją, formularzami czy działaniem komponentów,
• dostępność redakcyjną, która zależy od sposobu przygotowania i publikowania treści.

Poniższe błędy dotyczą przede wszystkim drugiego obszaru.

1. Nagłówki wybierane ze względu na wygląd

Jednym z częstszych błędów podczas publikowania treści jest traktowanie nagłówka jak sposobu na zmianę wielkości tekstu.

Redaktor wybiera H3 zamiast H2, ponieważ taki śródtytuł lepiej wygląda. Innym razem nie korzysta z nagłówka wcale – powiększa tekst i go pogrubia. Wizualnie efekt może być bardzo podobny. Dla technologii asystującej są to jednak zupełnie inne elementy.

Nagłówki przekazują informację o strukturze dokumentu. Ich poziomy pokazują, które części treści są nadrzędne, a które stanowią ich rozwinięcie. Osoby korzystające z czytników ekranu mogą dodatkowo poruszać się między nagłówkami bez konieczności odczytywania całej strony. Również użytkownik widzący może dzięki nim szybko znaleźć interesującą sekcję.

Prawidłowy układ może wyglądać następująco:

• H1 – tytuł strony,
• H2 – główna część artykułu,
• H3 – zagadnienie należące do danej części,
• H2 – kolejna główna część.

Nie wybieraj poziomu nagłówka na podstawie jego wyglądu. Jeśli H2 jest wizualnie za duży, problem powinien zostać rozwiązany w stylach strony, a nie poprzez zmianę struktury tekstu.

2. Brak tekstu alternatywnego albo ALT, który nie przekazuje informacji

CMS-y, w tym WordPress, pozwalają uzupełnić tekst alternatywny podczas dodawania obrazu. Częste błędy to:

• pozostawienie pola pustego przy grafice przekazującej ważną informację,
• wpisanie nazwy pliku, np. „IMG_4582.jpg”,
• użycie opisu „grafika” albo „zdjęcie”,
• automatyczne skopiowanie tytułu obrazu,
• szczegółowe opisywanie elementu, który jest wyłącznie dekoracyjny.

Tekst alternatywny powinien przekazywać informację potrzebną użytkownikowi, który nie widzi danego obrazu. Jego treść zależy więc nie tylko od tego, co znajduje się na grafice, lecz także od kontekstu.

Jeżeli obraz pełni wyłącznie funkcję dekoracyjną, powinien zostać odpowiednio oznaczony jako dekoracyjny, a w HTML mieć pusty atrybut alt=””. Nie należy dodawać opisu tylko po to, aby „pole ALT nie było puste”.

Źle:
„Grafika przedstawiająca kobietę.”

Lepiej:
„Pracownica urzędu pomaga seniorowi wypełnić elektroniczny wniosek.”

Drugi opis może być właściwy, jeżeli właśnie ta informacja jest ważna dla kontekstu treści. W innym miejscu ten sam obraz może wymagać zupełnie innego opisu albo zostać uznany za dekoracyjny.

3. Linki typu „kliknij tutaj”, „więcej” i „zobacz”

Redaktor strony internetowej często tworzy link dopiero po napisaniu zdania:

• „Więcej informacji znajdziesz tutaj.”

Problem polega na tym, że samo słowo „tutaj” nie informuje o celu odnośnika. Podobnie jest z określeniami „więcej”, „czytaj” czy „zobacz”.

Użytkownicy technologii asystujących mogą przeglądać same linki występujące na stronie. Lista złożona z kilku pozycji nazwanych „więcej” nie daje im informacji, dokąd prowadzą poszczególne odnośniki.

Lepiej opisać link na podstawie jego celu.

Zamiast:
„Aby poznać szczegóły, kliknij tutaj.”

Lepiej:
„Sprawdź zasady przygotowania deklaracji dostępności.”

Opis linku powinien być możliwie jednoznaczny. W przypadku linku do dokumentu warto dodatkowo poinformować użytkownika o jego formacie, a w uzasadnionych przypadkach także o wielkości pliku.

4. Listy i tabele tworzone „na oko”

CMS daje możliwość utworzenia prawidłowej listy punktowanej lub numerowanej. Mimo to zdarza się, że redaktor wpisuje kolejne myślniki ręcznie, np.:

– pierwszy dokument,

– drugi dokument,

– trzeci dokument.

Wizualnie powstaje lista. W strukturze strony nadal są to jednak zwykłe akapity.

Podobny problem może wystąpić przy numerowaniu kolejnych kroków albo tworzeniu tabel.

Tabele powinny służyć przede wszystkim do prezentowania danych, które rzeczywiście mają strukturę tabelaryczną. Nie należy wykorzystywać ich jedynie po to, aby ustawić dwa fragmenty treści obok siebie lub uzyskać odpowiednie odstępy.

W tabelach z danymi trzeba dodatkowo prawidłowo oznaczyć komórki nagłówkowe oraz ich relacje z danymi.

5. Ważna informacja umieszczona wyłącznie na grafice

Plakat wydarzenia, harmonogram, godziny pracy, informacja o naborze czy komunikat o zamknięciu urzędu często trafiają na stronę jako plik JPG lub PNG.

Dla osoby widzącej wszystko może być czytelne. Użytkownik korzystający z czytnika ekranu otrzymuje jednak tylko informację o obecności obrazu – chyba że redaktor zapewni odpowiednią alternatywę.

Standard WCAG 2.1 zwraca uwagę zarówno na zapewnianie alternatyw tekstowych dla treści nietekstowych, jak i na unikanie obrazów tekstowych w sytuacjach, w których informację można przedstawić jako zwykły tekst. Wytyczne dotyczące dostępności zalecają unikanie tekstu zapisanego wyłącznie jako element grafiki.

Nie oznacza to, że nie można publikować plakatu. Jeżeli zawiera istotną informację, warto dodać ją również w treści strony.

Przykładowo zamiast publikować wyłącznie grafikę:

„Zmiana godzin pracy urzędu – 18 września 2026”

warto poniżej podać tekstowo nowe godziny otwarcia oraz inne informacje potrzebne użytkownikowi.

Długi tekst alternatywny nie powinien zastępować właściwej treści strony.

6. Kolor staje się jedynym sposobem przekazywania informacji

CMS pozwala redaktorowi samodzielnie zmienić kolor tekstu, jego tła albo innych elementów. Taka możliwość nie oznacza, że każda kombinacja będzie dostępna.

Problem występuje między innymi wtedy, gdy:

• ważna informacja jest oznaczona wyłącznie kolorem czerwonym,
• poprawne odpowiedzi zaznaczono na zielono, a błędne na czerwono,
• redaktor zmienia kolor tekstu na taki, który ma zbyt mały kontrast względem tła,
• link w akapicie różni się od zwykłego tekstu wyłącznie kolorem, którego część użytkowników może nie rozpoznać.

Przykład:

Źle:
„Pola zaznaczone na czerwono są obowiązkowe.”

Lepiej:
Pola obowiązkowe należy dodatkowo jednoznacznie oznaczyć tekstowo lub za pomocą symbolu, którego znaczenie zostało wyjaśnione.

Standard WCAG wymaga, aby kolor nie był jedynym sposobem przekazania informacji, wskazania działania lub wyróżnienia elementu. Dlatego redaktor powinien korzystać przede wszystkim ze stylów przewidzianych w projekcie strony, zamiast samodzielnie modyfikować wygląd każdego fragmentu.

7. Publikowanie niedostępnych dokumentów i skanów PDF

Jednym z poważniejszych błędów jest zamieszczenie na stronie zeskanowanego dokumentu i uznanie, że informacja została udostępniona cyfrowo.

Skan zapisany jako obraz może być całkowicie nieczytelny dla czytnika ekranu. Sam format PDF nie przesądza jednak o dostępności dokumentu. Prawidłowo przygotowany PDF może posiadać między innymi:

• warstwę tekstową,
• logiczną strukturę nagłówków,
• właściwą kolejność odczytu,
• teksty alternatywne,
• prawidłowo przygotowane tabele,
• opisowe linki.

Problem nie jest wyłącznie teoretyczny. W opisywanych przez nas wynikach kontroli NIK dotyczącej dostępności samorządów jednym z wykrywanych problemów było właśnie publikowanie dokumentów w formie skanów.

Przed dodaniem dokumentu do CMS warto więc odpowiedzieć na dwa pytania:

1. Czy ta informacja rzeczywiście musi być opublikowana jako plik?
2. Jeśli tak, czy dokument został przygotowany w sposób dostępny?

W wielu przypadkach krótką informację, regulamin, komunikat czy instrukcję lepiej opublikować bezpośrednio jako treść HTML strony, a dokument traktować jako materiał dodatkowy.

8. Film opublikowany bez odpowiednich alternatyw

Dodanie filmu z YouTube do artykułu zajmuje kilka chwil. Zapewnienie jego dostępności wymaga jednak dodatkowego przygotowania.

W zależności od charakteru materiału znaczenie mogą mieć między innymi:

• napisy,
• transkrypcja,
• opis informacji wizualnych,
• audiodeskrypcja,
• prawidłowo opisany i możliwy do obsługi odtwarzacz.

Nie należy również bez sprawdzenia zakładać, że automatycznie wygenerowane napisy rozwiązują problem. Mogą zawierać błędy w nazwach własnych, terminach specjalistycznych czy interpunkcji.

Najważniejsze pytanie przed publikacją brzmi:

Czy osoba, która nie słyszy albo nie widzi części materiału, otrzyma wszystkie informacje potrzebne do zrozumienia przekazu?

Poszczególne formy alternatyw pełnią różne funkcje i nie zawsze można stosować je zamiennie.

Czy WCAG checker wykryje błędy popełnione przez redaktora?

Pomocą w codziennej pracy redaktora mogą być automatyczne narzędzia do sprawdzania dostępności, określane często jako WCAG checker. Potrafią szybko wykryć część problemów technicznych, np. brak atrybutu ALT, niektóre nieprawidłowości związane z kontrastem czy strukturą kodu. Ich szczególna wartość pojawia się wtedy, gdy strona jest regularnie aktualizowana i trzeba kontrolować nie tylko jej stan w dniu audytu, ale również kolejne zmiany.

Tak działa m.in. SAT – Platforma Dostępności Cyfrowej. Rozwiązanie umożliwia stałe monitorowanie serwisów pod kątem dostępności. Po dodaniu nowych treści platforma może przeanalizować stronę, wskazać wykryte nieprawidłowości oraz przedstawić informacje pomocne w ich usunięciu. Dzięki temu zespół może szybciej wychwycić błędy pojawiające się podczas codziennej pracy w CMS, zamiast czekać na kolejny okresowy audyt.

Dostępny CMS to dopiero początek

Dobrze zaprojektowana strona może znacząco ograniczyć ryzyko powstawania błędów. CMS może udostępniać odpowiednie pola, gotowe komponenty i style. Nie podejmie jednak za redaktora wszystkich decyzji.

Dlatego dostępność serwisu wymaga nie tylko odpowiedniej technologii, lecz także kompetencji osób, które na co dzień nim zarządzają.

Szkolenia WCAG dla redaktorów treści pomagają przełożyć wymagania standardu na codzienną pracę w CMS. Redaktor nie musi być programistą ani znać wszystkich szczegółów specyfikacji. Powinien jednak wiedzieć, które jego decyzje mogą stworzyć barierę.

W Grupa WW GovTech prowadzimy szkolenia dla osób odpowiedzialnych za publikowanie treści oraz realizujemy audyty dostępności cyfrowej stron i aplikacji. Weryfikacja obecnego stanu serwisu, uzupełniona o rozwój kompetencji zespołu, pozwala nie tylko naprawić istniejące błędy, ale także ograniczyć ryzyko ich ponownego pojawienia się.

Dostępność cyfrowa nie jest bowiem jednorazowym zadaniem wykonywanym przy budowie strony. To proces, który trwa tak długo, jak długo serwis jest rozwijany i aktualizowany.

 

Źródła:

https://www.w3.org/TR/WCAG22/

https://www.w3.org/WAI/WCAG22/Understanding/

https://www.gov.pl/web/dostepnosc-cyfrowa/poradnik

https://www.gov.pl/web/dostepnosc-cyfrowa/naglowki

https://www.gov.pl/web/dostepnosc-cyfrowa/tresci-dostepne-cyfrowo

https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20190000848&