Prosty język, ISO 24495 i WCAG 3

Najważniejsze rozróżnienie

WCAG 3 nie jest jeszcze obowiązującym standardem. Jest szkicem rozwijanym przez W3C.

ISO 24495 nie jest technicznym standardem dostępności cyfrowej. Jest standardem dotyczącym prostego języka.

W praktyce:

• WCAG pomaga oceniać dostępność cyfrową,
• COGA pomaga zrozumieć potrzeby osób z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się,
• ISO 24495 pomaga porządkować tworzenie prostych, zrozumiałych i użytecznych treści.

Dlaczego prosty język jest tematem dostępności?

Dostępność cyfrowa nie kończy się na tym, że użytkownik może wejść na stronę i obsłużyć ją technicznie.

Użytkownik musi jeszcze zrozumieć:

• gdzie jest,
• czego dotyczy treść,
• co ma zrobić,
• jakie dane ma podać,
• co oznacza komunikat,
• jak poprawić błąd,
• co stanie się po kliknięciu,
• jakie są konsekwencje decyzji.

To są problemy dostępności poznawczej. Nie zawsze da się je dobrze ocenić automatycznym skanerem.

Co daje ISO 24495?

ISO 24495-1:2023 opisuje zasady i wytyczne tworzenia dokumentów w prostym języku. Standard dotyczy przede wszystkim informacji drukowanych i cyfrowych, których główną formą jest tekst.

W kontekście serwisów internetowych najważniejsze są cztery zasady:

Co daje COGA?

Dokument W3C „Making Content Usable for People with Cognitive and Learning Disabilities” skupia się na potrzebach osób z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się.

W3C wskazuje, że tworzenie treści i aplikacji użytecznych dla tych osób wpływa na każdy etap projektowania i rozwoju: od badań, przez projektowanie, aż po testowanie.

W praktyce oznacza to, że prosty język trzeba projektować razem z:

• architekturą informacji,
• etykietami,
• instrukcjami,
• formularzami,
• komunikatami błędów,
• nawigacją,
• kolejnością kroków w procesie,
• testami z użytkownikami.

Co daje WCAG 3?

WCAG 3 ma objąć szerszy zakres potrzeb użytkowników niż dotychczasowe WCAG 2.x. W3C wskazuje, że projekt WCAG 3 zawiera potencjalne wytyczne i wymagania, które są nadal eksplorowane, a finalne wymagania będą inne niż w aktualnym szkicu.

W szkicu WCAG 3 pojawia się obszar Clear Language, czyli jasny język. Ten kierunek jest ważny, bo przesuwa rozmowę z samej technicznej zgodności w stronę realnej użyteczności dla osób o różnych potrzebach poznawczych.

ISO 24495 a WCAG 3

ISO 24495 i WCAG 3 odpowiadają na różne pytania.

Rodzina ISO 24495

Co można robić już teraz?

Nie trzeba czekać na WCAG 3, żeby poprawiać dostępność poznawczą treści.

Organizacja może już dziś:

1. Stworzyć standard prostego języka dla treści cyfrowych.
2. Wprowadzić przegląd treści przed publikacją.
3. Poprawić etykiety formularzy.
4. Przepisać komunikaty błędów.
5. Wyjaśnić skróty i trudne pojęcia.
6. Uporządkować długie instrukcje.
7. Testować formularze i procesy z użytkownikami.
8. Dodać krótkie podsumowania do trudnych tekstów.
9. Sprawdzać, czy użytkownik rozumie konsekwencje działania.
10. Traktować prosty język jako część projektowania usługi, a nie kosmetyczną korektę na końcu.

Przykład: komunikat błędu

Słaba wersja

Błąd walidacji. Nieprawidłowy format danych.

Problem:

• użytkownik nie wie, które pole jest błędne,
• nie wie, jaki format jest prawidłowy,
• komunikat brzmi technicznie,
• komunikat nie pomaga wykonać zadania.

Lepsza wersja

Wpisz numer telefonu w formacie 123 456 789. Nie używaj liter ani znaków specjalnych.

Dlaczego lepiej:

• wiadomo, czego dotyczy problem,
• podany jest prawidłowy format,
• użytkownik wie, jak poprawić błąd,
• komunikat prowadzi do działania.

Powiązane kryteria sukcesu WCAG 2.x: 3.3.1 Identyfikacja błędu, 3.3.2 Etykiety lub instrukcje, 3.3.3 Sugestie korekty błędów.

Jak audytować prosty język?

Nie wystarczy sprawdzić długości zdań.

Audytor powinien przejść przez realne zadania użytkownika:

1. Wejdź na stronę jako użytkownik, który nie zna organizacji.
2. Sprawdź, czy pierwszy ekran wyjaśnia temat i cel.
3. Przejdź przez formularz albo proces.
4. Zapisz miejsca, w których trzeba się domyślać.
5. Sprawdź, czy instrukcje są przy właściwych polach.
6. Wywołaj błędy i oceń komunikaty.
7. Sprawdź, czy nazwy linków i przycisków mówią, co się stanie.
8. Oceń, czy użytkownik musi pamiętać informacje z wcześniejszych kroków.
9. Zaznacz problemy jako:

• naruszenie kryterium WCAG,
• prawdopodobny problem dostępności,
• rekomendację użyteczności i dostępności poznawczej.

Kryteria oceny

Element spełnia założenia prostego języka, gdy:

• odpowiada na konkretną potrzebę użytkownika,
• jest łatwy do znalezienia,
• jest zrozumiały bez znajomości żargonu,
• prowadzi do działania,
• nie wymaga zgadywania,
• nie przerzuca pracy interpretacyjnej na użytkownika.

Element jest problematyczny, gdy:

• tekst jest formalny, ale nie pomaga,
• instrukcja pojawia się dopiero po błędzie,
• linki są ogólne,
• etykiety są wieloznaczne,
• komunikaty błędów są techniczne,
• użytkownik musi pamiętać dane z poprzedniego kroku,
• treść nie mówi, co zrobić dalej.

Źródła

• ISO 24495-1:2023 — Plain language — Part 1: Governing principles and guidelines (otwiera się w nowym oknie)
• ISO 24495-2:2025 — Plain language — Part 2: Legal communication (otwiera się w nowym oknie)
• ISO 24495-3:2026 — Plain language — Part 3: Science writing (otwiera się w nowym oknie)
• ISO/DIS 24495-4 — Plain language — Part 4: Requirements for implementing the plain language principles in organizations (otwiera się w nowym oknie)
• ISO/WD 24495-5 — Plain language — Part 5: Document design (otwiera się w nowym oknie)
• W3C/WAI — WCAG 3 Introduction (otwiera się w nowym oknie)
• W3C — W3C Accessibility Guidelines (WCAG) 3.0 Working Draft (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)