WCAG 3.3.3: Sugestie poprawek błędów

Kryterium sukcesu WCAG 2.x 3.3.3, znane jako „Sugestie poprawek błędów”, dotyczy zapewnienia użytkownikom pomocnych wskazówek w przypadku wykrycia błędów w formularzach lub innych miejscach interakcji. Jeśli system automatycznie wykryje błąd we wprowadzonych danych i zna potencjalną poprawkę, musi ją przedstawić użytkownikowi w sposób jasny i zrozumiały, chyba że ujawnienie takiej sugestii zagroziłoby bezpieczeństwu, naruszyło cel działania systemu lub byłoby z innego powodu nieodpowiednie.

Czym jest kryterium sukcesu 3.3.3 (Sugestie poprawek błędów)?

To kryterium ma na celu ułatwienie użytkownikom poprawiania błędnie wprowadzonych danych, co jest szczególnie ważne w formularzach, gdzie pomyłki są częste. Zamiast ogólnego komunikatu typu „Wystąpił błąd”, system powinien oferować konkretne, użyteczne sugestie, które pomogą użytkownikowi zrozumieć, co poszło nie tak i jak to naprawić. Chodzi o to, aby proces poprawiania błędów był jak najmniej frustrujący i efektywny.

Dlaczego to jest ważne? (Wpływ na dostępność)

Implementacja kryterium 3.3.3 ma znaczący wpływ na dostępność i użyteczność stron internetowych, szczególnie dla następujących grup użytkowników:

• Osoby z zaburzeniami poznawczymi i dysleksją: Mogą mieć trudności z przetwarzaniem informacji, zapamiętywaniem wymagań formatowania lub rozumieniem niejasnych komunikatów o błędach. Konkretne sugestie znacznie ułatwiają im ukończenie zadań.
• Osoby z ograniczoną sprawnością ruchową: Mogą przypadkowo wprowadzić błędne dane z powodu trudności z precyzyjnym klikaniem lub wpisywaniem. Jasne wskazówki minimalizują liczbę prób i pomyłek.
• Osoby niewidome lub słabowidzące: Korzystające z czytników ekranu potrzebują jednoznacznych komunikatów. Ogólnikowe błędy są dla nich szczególnie trudne do zinterpretowania bez wizualnych wskazówek. Sugestia poprawki, prawidłowo oznaczona semantycznie, jest natychmiast przekazywana.
• Osoby starsze: Mogą być mniej zaznajomione z konwencjami internetowymi i potrzebować dodatkowego wsparcia w nawigacji i wypełnianiu formularzy.
• Wszyscy użytkownicy: Niezależnie od swoich zdolności, każdy użytkownik doceni jasne i pomocne komunikaty o błędach, które skracają czas potrzebny na ukończenie formularza i zmniejszają poziom frustracji.

Skuteczne sugestie poprawek błędów zwiększają współczynnik sukcesu w wypełnianiu formularzy, poprawiają satysfakcję użytkownika i budują zaufanie do witryny.

Wymagania kryterium sukcesu 3.3.3

Zgodnie z WCAG 3.3.3 (Poziom AA), podstawowym wymaganiem jest:

Jeśli błąd wprowadzania jest automatycznie wykrywany, a znane są sugestie dotyczące poprawki, to sugestie te są przedstawiane użytkownikowi, chyba że uniemożliwiłoby to cel zabezpieczenia lub byłoby nieodpowiednie dla tego celu.

Kluczowe aspekty tego wymagania to:

• Automatyczne wykrywanie: Błąd musi zostać wykryty przez system (np. walidacja formularza).
• Znane sugestie poprawek: Jeśli system jest w stanie określić, co jest nie tak i jak to naprawić, powinien tę informację przekazać.
• Prezentacja użytkownikowi: Sugestia musi być widoczna i dostępna dla użytkownika.
• Wyjątki: W niektórych przypadkach (np. pytanie zabezpieczające „imię panieńskie matki”, gdzie podanie poprawnej odpowiedzi byłoby sprzeczne z celem bezpieczeństwa) sugestia poprawki może zostać pominięta. Ważne jest, aby takie wyjątki były uzasadnione.

Praktyczne wytyczne dotyczące zgodności

Aby spełnić kryterium 3.3.3, należy wdrożyć następujące praktyki:

• Błędy formatowania: Jeśli oczekiwany jest konkretny format (np. daty, numeru telefonu), a użytkownik wprowadzi coś innego, zasugeruj prawidłowy format.
• Brakujące dane: Jeśli wymagane pole jest puste, jasno to wskaż i poinformuj, że pole musi zostać wypełnione.
• Błędy logiczne lub wartościowe: Jeśli wprowadzona wartość jest poza dopuszczalnym zakresem (np. wiek poniżej 0 lub powyżej 150), wyjaśnij, jaki jest prawidłowy zakres.
• Literówki w sugestiach: W przypadku typowych literówek (np. w adresie e-mail, nazwie miasta), system może zasugerować poprawioną pisownię, ale zawsze z opcją zaakceptowania lub odrzucenia przez użytkownika.
• Kontekstowe komunikaty: Komunikat o błędzie i sugestia poprawki powinny pojawiać się w bezpośrednim sąsiedztwie pola, którego dotyczą, aby ułatwić szybką korektę.
• Jasny i prosty język: Unikaj żargonu technicznego. Używaj języka, który jest zrozumiały dla szerokiego grona odbiorców.
• Dostępność dla technologii wspomagających: Zapewnij, że komunikaty o błędach i sugestie są prawidłowo oznaczane semantycznie (np. za pomocą aria-live="polite" lub aria-describedby), aby były odczytywane przez czytniki ekranu.

Przykłady implementacji

Poprawne implementacje

<label for="imie">Imię:<span class="required" aria-hidden="true">*</span></label>
<input type="text" id="imie" name="imie" aria-required="true" aria-invalid="true" aria-describedby="imie-error">
<span id="imie-error" class="error-message" role="alert"><strong>Błąd:</strong> Pole "Imię" jest wymagane. Proszę podać swoje imię, aby kontynuować.</span>

.error-message {
  color: #c00;
  font-weight: bold;
  display: block;
  margin-top: 5px;
}

input[aria-invalid="true"] {
  border: 2px solid #c00;
}

// Uproszczony przykład walidacji JavaScript
const nameInput = document.getElementById('imie');
const nameError = document.getElementById('imie-error');

function validateName() {
  if (nameInput.value.trim() === '') {
    nameInput.setAttribute('aria-invalid', 'true');
    nameError.textContent = 'Błąd: Pole "Imię" jest wymagane. Proszę podać swoje imię, aby kontynuować.';
    nameError.style.display = 'block';
    // Ustawia fokus na polu błędu dla lepszej nawigacji
    nameInput.focus();
    return false;
  } else {
    nameInput.removeAttribute('aria-invalid');
    nameError.textContent = '';
    nameError.style.display = 'none';
    return true;
  }
}

// Przykład użycia (np. przy próbie wysłania formularza)
// const form = document.querySelector('form');
// form.addEventListener('submit', function(event) {
//   if (!validateName()) {
//     event.preventDefault(); // Zatrzymuje wysłanie formularza
//   }
// });

<label for="data-urodzenia">Data urodzenia (DD-MM-RRRR):</label>
<input type="text" id="data-urodzenia" name="dataUrodzenia" aria-invalid="true" aria-describedby="data-urodzenia-error">
<span id="data-urodzenia-error" class="error-message" role="alert"><strong>Błąd formatu:</strong> Proszę użyć formatu DD-MM-RRRR, np. 31-12-2000.</span>

// Uproszczony przykład walidacji JavaScript
const dateInput = document.getElementById('data-urodzenia');
const dateError = document.getElementById('data-urodzenia-error');

function validateDate() {
  const datePattern = /^d{2}-d{2}-d{4}$/;
  if (!datePattern.test(dateInput.value)) {
    dateInput.setAttribute('aria-invalid', 'true');
    dateError.textContent = 'Błąd formatu: Proszę użyć formatu DD-MM-RRRR, np. 31-12-2000.';
    dateError.style.display = 'block';
    dateInput.focus();
    return false;
  } else {
    dateInput.removeAttribute('aria-invalid');
    dateError.textContent = '';
    dateError.style.display = 'none';
    return true;
  }
}

<label for="email">Adres e-mail:</label>
<input type="email" id="email" name="email" aria-invalid="true" aria-describedby="email-error">
<span id="email-error" class="error-message" role="alert"><strong>Błąd:</strong> Adres e-mail musi zawierać znak "@" i domenę (np. uzytkownik@example.com).</span>

Nieprawidłowe implementacje

<label for="nazwisko">Nazwisko:</label>
<input type="text" id="nazwisko" name="nazwisko">
<p class="error-message">Wystąpił błąd podczas przetwarzania formularza.</p>

<label for="telefon">Numer telefonu:</label>
<input type="tel" id="telefon" name="telefon">
<!-- Komunikat o błędzie pojawia się na górze strony, daleko od pola -->
<div role="alert" aria-live="assertive">
  <h3>Błędy w formularzu:</h3>
  <ul>
    <li>Numer telefonu jest nieprawidłowy.</li>
  </ul>
</div>

Najlepsze praktyki i często popełniane błędy

• Zawsze podawaj konkretne sugestie: Nie poprzestawaj na stwierdzeniu „Wystąpił błąd”. Zawsze wyjaśniaj, co poszło nie tak i jak to naprawić (np. „Wprowadź datę w formacie DD-MM-RRRR”).
• Kontekstowość komunikatu: Błędy i sugestie poprawek powinny być umieszczone jak najbliżej pola wejściowego, którego dotyczą, najlepiej bezpośrednio pod nim.
• Wizualne wyróżnienie błędów: Użyj stylizacji CSS (np. czerwonej ramki wokół pola, pogrubionego, czerwonego tekstu komunikatu), aby wizualnie wskazać błędy.
• Dostępność semantyczna (ARIA):
  • Użyj atrybutu aria-invalid="true" na polach, które zawierają błędy.
  • Połącz komunikat o błędzie z polem formularza za pomocą atrybutu aria-describedby. Zapewnia to, że czytniki ekranu odczytają komunikat o błędzie po fokusowaniu na polu.
  • Dla ogólnych podsumowań błędów na początku formularza, użyj role="alert" lub aria-live="assertive", aby czytniki ekranu natychmiast poinformowały użytkownika o błędach po przesłaniu formularza.
• Fokus na błędzie: Po przesłaniu formularza i wykryciu błędów, przenieś fokus klawiatury na pierwsze pole z błędem lub na podsumowanie błędów, aby użytkownik od razu wiedział, gdzie zacząć poprawki.
• Unikaj automatycznych poprawek bez zgody: Nie poprawiaj automatycznie danych wprowadzonych przez użytkownika, chyba że są to drobne, niezagrażające funkcjonalności literówki (np. automatyczne usunięcie nadmiarowych spacji). Zawsze daj użytkownikowi możliwość weryfikacji i zaakceptowania sugerowanej poprawki.
• Jasny i prosty język: Komunikaty powinny być łatwe do zrozumienia dla każdego. Unikaj branżowego żargonu.
• Testowanie: Regularnie testuj swoje formularze z różnymi technologiami wspomagającymi (np. czytnikami ekranu, powiększaniem ekranu), aby upewnić się, że sugestie poprawek błędów są skutecznie przekazywane i zrozumiałe.
• Pamiętaj o wyjątkach: W sytuacjach, gdzie ujawnienie poprawki mogłoby zagrozić bezpieczeństwu (np. odpowiedzi na pytania bezpieczeństwa, hasła), możesz pominąć konkretne sugestie. Należy to jednak robić z rozwagą i tylko, gdy jest to absolutnie konieczne i uzasadnione.

Podsumowanie

Zapewnienie skutecznych sugestii poprawek błędów (WCAG 3.3.3) jest kluczowe dla tworzenia dostępnych i użytecznych interfejsów. Poprawne wdrożenie tego kryterium nie tylko pomaga użytkownikom z niepełnosprawnościami w pomyślnym wypełnianiu zadań, ale także znacząco poprawia ogólne doświadczenie wszystkich użytkowników witryny. Pamiętaj, aby komunikaty były jasne, konkretne, kontekstowe i dostępne dla technologii wspomagających, zawsze oferując użytkownikowi realną pomoc w rozwiązywaniu problemów.