Checklista prostego języka w audycie dostępności

Jak korzystać z checklisty?

Dla każdego obszaru odpowiedz na pytania:

• tak,
• częściowo,
• nie,
• nie dotyczy.

Jeżeli odpowiedź brzmi „częściowo” albo „nie”, opisz problem i zaproponuj poprawkę.

W audycie rozdziel:

• naruszenia konkretnych kryteriów WCAG,
• prawdopodobne problemy dostępności poznawczej,
• rekomendacje redakcyjne i użytecznościowe.

1. Czy użytkownik dostaje to, czego potrzebuje?

Ta część odpowiada pierwszej zasadzie ISO 24495-1: treść powinna odpowiadać na potrzeby odbiorcy.

Pytania kontrolne

• Czy wiadomo, dla kogo jest treść?
• Czy wiadomo, po co użytkownik ma ją przeczytać?
• Czy najważniejsza informacja jest na początku?
• Czy treść odpowiada na realne pytania użytkownika?
• Czy usunięto informacje, które nie pomagają wykonać zadania?
• Czy użytkownik wie, jakie warunki musi spełnić?
• Czy użytkownik wie, jakie dokumenty, dane albo decyzje są potrzebne?
• Czy tekst nie zaczyna się od podstaw prawnych, jeśli użytkownik najpierw potrzebuje instrukcji działania?

Spełnia

Treść spełnia założenie, gdy użytkownik szybko rozumie:

• czego dotyczy sprawa,
• czy temat go dotyczy,
• co ma przygotować,
• co ma zrobić dalej.

Nie spełnia

Treść jest problematyczna, gdy:

• zaczyna się od formalnego wstępu,
• ukrywa najważniejszą informację w środku tekstu,
• zawiera dużo treści organizacyjnej, ale mało instrukcji,
• odpowiada bardziej na potrzeby instytucji niż użytkownika.

Przykład poprawki

Słabiej:

W celu realizacji procedury konieczne jest przedłożenie wymaganych załączników zgodnie z obowiązującymi przepisami.

Lepiej:

Do wniosku dołącz:

• skan dokumentu tożsamości,
• potwierdzenie opłaty,
• podpisane oświadczenie.

2. Czy użytkownik może łatwo znaleźć informację?

Ta część odpowiada drugiej zasadzie ISO 24495-1: informacja powinna być łatwa do znalezienia.

Pytania kontrolne

• Czy strona ma jeden jasny nagłówek główny?
• Czy nagłówki opisują zawartość sekcji?
• Czy kolejność sekcji odpowiada kolejności działań użytkownika?
• Czy długie bloki tekstu są podzielone?
• Czy listy są stosowane tam, gdzie użytkownik musi sprawdzić warunki, kroki albo dokumenty?
• Czy tabela jest użyta wtedy, gdy pomaga porównać dane?
• Czy linki prowadzą do właściwych miejsc i mają konkretne nazwy?
• Czy użytkownik nie musi czytać całej strony, żeby znaleźć jedną informację?

Spełnia

Treść spełnia założenie, gdy użytkownik może przeskanować stronę i szybko przejść do właściwej sekcji.

Nie spełnia

Treść jest problematyczna, gdy:

• nagłówki są ogólne, na przykład „Informacje”, „Szczegóły”, „Ważne”,
• kilka sekcji ma podobne nazwy,
• ważne instrukcje są ukryte w długim akapicie,
• linki mają nazwy typu „więcej”, „tutaj”, „kliknij”.

Przykład poprawki linków

Słabiej:

• Więcej
• Sprawdź
• Pobierz

Lepiej:

• Przeczytaj więcej o audycie dostępności
• Sprawdź program szkolenia WCAG
• Pobierz checklistę prostego języka w PDF

3. Czy użytkownik może łatwo zrozumieć treść?

Ta część odpowiada trzeciej zasadzie ISO 24495-1: treść powinna być łatwa do zrozumienia.

Pytania kontrolne

• Czy tekst używa słów znanych odbiorcy?
• Czy trudne pojęcia są wyjaśnione przy pierwszym użyciu?
• Czy skróty są rozwinięte?
• Czy zdania są możliwie krótkie?
• Czy każde zdanie ma jasny podmiot?
• Czy ograniczono stronę bierną?
• Czy usunięto formalizmy i wielosłowie?
• Czy instrukcje są zapisane jako konkretne działania?
• Czy treść unika metafor, żartów i idiomów tam, gdzie mogą utrudnić zrozumienie?
• Czy długi albo trudny tekst ma podsumowanie?

Spełnia

Treść spełnia założenie, gdy użytkownik rozumie ją przy pierwszym czytaniu i nie musi szukać wyjaśnień poza stroną.

Nie spełnia

Treść jest problematyczna, gdy:

• używa żargonu bez wyjaśnienia,
• zawiera zdania wielokrotnie złożone,
• brzmi urzędowo, ale nie prowadzi do działania,
• ukrywa czasownik i wykonawcę czynności,
• wymaga wiedzy eksperckiej od masowego odbiorcy.

Przykład poprawki

Słabiej:

Celem dokonania skutecznej aktualizacji danych użytkownika konieczne jest uprzednie uzupełnienie wszystkich obligatoryjnych pól formularza oraz zatwierdzenie wprowadzonych informacji przy użyciu dedykowanego przycisku funkcyjnego.

Lepiej:

Uzupełnij wszystkie wymagane pola. Potem wybierz przycisk „Zapisz dane”.

4. Czy użytkownik może łatwo użyć informacji?

Ta część odpowiada czwartej zasadzie ISO 24495-1: użytkownik powinien móc użyć informacji w praktyce.

Pytania kontrolne

• Czy użytkownik wie, co zrobić po przeczytaniu treści?
• Czy przyciski jasno opisują działanie?
• Czy formularz mówi, jakie dane wpisać?
• Czy instrukcje są przy polach, których dotyczą?
• Czy komunikaty błędów wskazują problem i sposób poprawy?
• Czy użytkownik wie, jakie będą skutki wysłania formularza?
• Czy proces informuje, ile ma kroków?
• Czy użytkownik wie, czy może wrócić do wcześniejszego kroku?
• Czy dane nie znikają po błędzie?
• Czy użytkownik nie musi pamiętać informacji z poprzedniej strony?

Spełnia

Treść spełnia założenie, gdy użytkownik po jej przeczytaniu wie:

• co kliknąć,
• co wpisać,
• co przygotować,
• co poprawić,
• co stanie się dalej.

Nie spełnia

Treść jest problematyczna, gdy:

• kończy się bez jasnego następnego kroku,
• przyciski mają ogólne nazwy,
• komunikaty błędów są techniczne,
• instrukcje pojawiają się dopiero po nieudanej próbie,
• proces wymaga zapamiętywania danych z poprzednich kroków.

Przykład komunikatu błędu

Słabiej:

Nieprawidłowe dane.

Lepiej:

Wpisz numer sprawy w formacie ABC.123.2026. Numer znajdziesz w prawym górnym rogu pisma.

Formularze — szybka lista szczegółowa

Sprawdź:

• Czy każde pole ma widoczną etykietę?
• Czy etykieta mówi dokładnie, jakiej informacji dotyczy pole?
• Czy instrukcja jest powiązana z polem w kodzie, na przykład przez aria-describedby?
• Czy format danych jest podany przed wysłaniem formularza?
• Czy pola wymagane są oznaczone i wyjaśnione?
• Czy błąd jest widoczny, zrozumiały i dostępny dla czytnika ekranu?
• Czy użytkownik może poprawić dane bez utraty pozostałych informacji?

Przykład HTML

<label for="case-number">Numer sprawy</label>
<input id="case-number" name="case-number" type="text" aria-describedby="case-number-help case-number-error">

<p id="case-number-help">
  Wpisz numer sprawy z pisma, np. ABC.123.2026.
</p>

<p id="case-number-error">
  Numer sprawy powinien mieć format ABC.123.2026.
</p>

Uwaga: komunikat błędu powinien być widoczny tylko wtedy, gdy błąd faktycznie występuje. W kodzie produkcyjnym trzeba też zadbać o prawidłowe powiązanie stanu błędu z polem formularza.

Linki i przyciski — szybka lista szczegółowa

Sprawdź:

• Czy link mówi, dokąd prowadzi?
• Czy przycisk mówi, co wykona?
• Czy unikasz samych czasowników bez kontekstu?
• Czy identyczne linki prowadzą do tego samego miejsca?
• Czy różne linki nie mają identycznej nazwy, jeśli prowadzą do różnych miejsc?
• Czy użytkownik rozumie konsekwencję kliknięcia?

Przykłady

Komunikaty błędów — szybka lista szczegółowa

Sprawdź:

• Czy komunikat wskazuje konkretne pole?
• Czy mówi, co jest nie tak?
• Czy mówi, jak poprawić błąd?
• Czy nie używa żargonu technicznego?
• Czy nie obwinia użytkownika?
• Czy jest dostępny dla czytnika ekranu?
• Czy pojawia się w logicznym miejscu?
• Czy można przejść do błędnego pola klawiaturą?

Przykłady

Prosta skala oceny

Nadaj każdemu obszarowi ocenę od 0 do 3.

Obszary do oceny:

1. Potrzeba użytkownika.
2. Znajdowalność informacji.
3. Zrozumiałość treści.
4. Użyteczność informacji.
5. Formularze.
6. Linki i przyciski.
7. Komunikaty błędów.
8. Procesy wieloetapowe.

Kiedy zgłosić naruszenie WCAG, a kiedy rekomendację?

Zgłoś naruszenie WCAG, gdy problem da się przypisać do kryterium sukcesu

Przykłady:

• pole formularza nie ma etykiety — 3.3.2 Etykiety lub instrukcje,
• link nie ma zrozumiałego celu w kontekście — 2.4.4 Cel linku w kontekście,
• nagłówek nie opisuje tematu sekcji — 2.4.6 Nagłówki i etykiety,
• użytkownik dostaje błąd, ale bez informacji, jak go poprawić — 3.3.3 Sugestie korekty błędów.

Zgłoś rekomendację, gdy problem pogarsza zrozumiałość, ale nie daje się jednoznacznie przypisać do WCAG AA

Przykłady:

• tekst jest zbyt formalny,
• najważniejsza informacja jest za późno,
• proces jest opisany z perspektywy instytucji, a nie użytkownika,
• użytkownik musi czytać zbyt dużo, żeby znaleźć jedną rzecz,
• strona nie ma krótkiego podsumowania trudnej procedury.

Źródła

• ISO 24495-1:2023 — Plain language — Part 1: Governing principles and guidelines (otwiera się w nowym oknie)
• W3C/WAI — WCAG 2 Overview (otwiera się w nowym oknie)
• W3C — Making Content Usable for People with Cognitive and Learning Disabilities (otwiera się w nowym oknie)
• W3C/WAI — Making Content Usable announcement (otwiera się w nowym oknie)
• Gov.pl — Prosty język (otwiera się w nowym oknie)