Când mesajele de eroare îți blochează utilizatorii

Momentul în care formularul se strică

Imaginează-ți: un utilizator nevăzător completează un formular de checkout, îl trimite și nu aude nimic util de la cititorul său de ecran. Niciun anunț. Nicio explicație. Pagina a semnalat vizual cinci erori de validare cu roșu, dar utilizatorul habar nu are. Apasă din nou pe trimitere. Și din nou. În cele din urmă, pleacă.

Acesta nu este un scenariu marginal. Gestionarea inaccesibilă a erorilor este una dintre cele mai frecvente bariere pe care le găsim în auditurile reale și este una care tinde să-i frustreze pe utilizatori în cel mai prost moment posibil — atunci când încearcă să finalizeze o tranzacție sau să trimită ceva important.

Vestea bună este că remedierea ține în mare parte de a ști cum arată „bine”. Eșecurile sunt aproape întotdeauna aceleași câteva tipare.

De ce sunt mesajele de eroare dificile pentru utilizatorii de tehnologii de asistare

Utilizatorii văzători care folosesc mouse-ul tind să observe erorile de validare imediat — chenarul roșu, pictograma de avertizare, textul care apare sub câmp. Dar utilizatorii care se bazează pe cititoare de ecran, navigare cu tastatura sau control vocal au parte de o experiență fundamental diferită.

Când un formular este trimis și apar erori:

• Utilizatorii de cititoare de ecran s-ar putea să nu audă nimic, decât dacă focalizarea se mută pe eroare sau o regiune live o anunță
• Utilizatorii de tastatură trebuie să poată ajunge la fiecare mesaj de eroare de la tastatură și să înțeleagă cărui câmp îi aparține
• Utilizatorii de control vocal trebuie să se adreseze câmpurilor printr-o etichetă vizibilă și corectă — dacă eticheta este greșită sau lipsește, sunt blocați

Nimic din toate acestea nu se întâmplă automat. Trebuie să le construiești.

Criteriile WCAG care se aplică

Patru criterii de succes din WCAG 2.2 acoperă direct gestionarea erorilor:

3.3.1 Identificarea erorilor (Nivel A) — Dacă o eroare este detectată automat, elementul eronat este identificat și descris utilizatorului în text. Nu poți transmite erorile doar prin culoare.

3.3.2 Etichete sau instrucțiuni (Nivel A) — Câmpurile care necesită un format specific trebuie să facă acea cerință clară înainte de sau în timpul introducerii datelor, nu doar după ce trimiterea eșuează.

3.3.3 Sugestii la erori (Nivel AA) — Dacă o eroare este detectată și sunt cunoscute sugestii de corectare, oferă-le. „Dată invalidă” nu este suficient. „Introdu data în formatul ZZ/LL/AAAA” este.

3.3.4 Prevenirea erorilor (Nivel AA) — Pentru trimiterile cu consecințe importante (tranzacții financiare, acorduri legale), oferă-le utilizatorilor posibilitatea de a revizui, corecta și confirma înainte ca acțiunea să devină permanentă.

Există și 4.1.3 Mesaje de stare (Nivel AA), care acoperă mesajele injectate dinamic ce nu primesc focalizarea — acestea trebuie anunțate de tehnologiile de asistare folosind role="status" sau role="alert".

De ce are nevoie de fapt un mesaj de eroare accesibil

Pentru a face mesajele de eroare corect este nevoie de atenție la patru straturi distincte:

1. Conexiunea programatică

Fiecare mesaj de eroare trebuie legat de câmpul său prin aria-describedby. Acest lucru le spune cititoarelor de ecran să anunțe textul erorii atunci când câmpul primește focalizarea.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Atributul aria-invalid="true" semnalează că respectivul câmp este în prezent invalid, lucru pe care majoritatea cititoarelor de ecran îl anunță atunci când focalizarea ajunge pe el.

2. Gestionarea focalizării după trimitere

Când un formular este trimis și există erori, focalizarea trebuie să se mute undeva util. Cele mai frecvente două modele:

• Mută focalizarea pe un rezumat al erorilor din partea de sus a formularului, care listează toate erorile cu linkuri către câmpurile relevante
• Mută focalizarea pe primul câmp eronat

Dacă focalizarea rămâne pe butonul de trimitere sau nicăieri, utilizatorii de cititoare de ecran trebuie să descopere singuri erorile navigând prin formular — asta dacă știu măcar că există erori.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Anunțuri prin regiuni live pentru erorile dinamice

Pentru erorile care apar pe măsură ce utilizatorul tastează (validare inline în timp real), folosește regiuni live ARIA, astfel încât mesajul să fie anunțat fără a fi nevoie ca focalizarea să se mute.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Folosește role="alert" / aria-live="assertive" pentru erorile care necesită atenție imediată. Folosește role="status" / aria-live="polite" pentru feedbackul mai puțin urgent, care poate aștepta până când utilizatorul face o pauză.

4. Mesajul de eroare în sine

Limbajul contează. Mesajele de eroare accesibile sunt:

• Specifice: spun ce anume este greșit, nu doar că ceva este greșit
• Acționabile: îi spun utilizatorului exact ce trebuie să facă pentru a remedia problema
• Politicoase: evită limbajul acuzator, precum „ai introdus o valoare invalidă”

Inaccesibil	Accesibil
„Date invalide”	„Adresa de e-mail trebuie să includă simbolul @, de exemplu nume@exemplu.com”
„Eroare”	„Data trebuie să fie în formatul ZZ/LL/AAAA”
„Câmp obligatoriu”	„Numele complet este obligatoriu”
„Parolă invalidă”	„Parola trebuie să aibă cel puțin 8 caractere și să includă o cifră”

Modele pentru diferite scenarii de eroare

Erori inline la nivel de câmp

Cel mai frecvent model. Un mesaj de eroare apare direct sub câmpul asociat. Funcționează bine pentru formularele simple. Necesită aria-describedby și aria-invalid pentru a fi anunțat corect.

Bannere cu rezumatul erorilor

Pentru formularele lungi cu mai multe erori, plasează în partea de sus un rezumat care listează toate problemele sub formă de linkuri ce sar la câmpul relevant. Mută focalizarea aici după o trimitere eșuată. Acesta este modelul folosit de GOV.UK și recomandat pe scară largă pentru formularele complexe.

Notificări toast

Mesajele de scurtă durată care apar la marginea ecranului se numără printre cele mai inaccesibile modele utilizate frecvent. Dispar înainte ca utilizatorii de cititoare de ecran să poată ajunge la ele, adesea nu sunt anunțate deloc și nu oferă nicio cale de recuperare. Evită folosirea notificărilor toast pentru erori. Dacă totuși le folosești, asociază-le cu o stare de eroare persistentă pe formularul propriu-zis.

Erori de sistem

Când ceva nu merge bine pe partea de server, spune-i utilizatorului într-un limbaj simplu ce s-a întâmplat și ce poate face în continuare. „Ceva nu a mers bine”, fără alte îndrumări, îi lasă pe utilizatori în aer.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Lista de verificare pentru testare

După implementarea gestionării erorilor, verifică manual următoarele — instrumentele automate nu vor detecta majoritatea:

• Trimiterea unui formular obligatoriu gol mută focalizarea pe un rezumat al erorilor sau pe primul câmp eronat
• Fiecare mesaj de eroare este legat de câmpul său prin aria-describedby
• Câmpurile eronate au aria-invalid="true"
• Mesajele de eroare sunt anunțate atunci când focalizarea ajunge pe câmpul afectat
• Validarea în timp real folosește regiuni live
• Mesajele de eroare folosesc un limbaj specific și acționabil — nu doar „invalid”
• Culoarea nu este singurul mod în care sunt indicate erorile (o pictogramă sau o etichetă text alături de roșu)
• Eroarea poate fi atinsă prin navigare cu Tab de la tastatură
• Ordinea focalizării după trimitere este logică și nu sare imprevizibil
• Mesajele toast sunt asociate cu o stare de eroare persistentă

De ce instrumentele automate ratează majoritatea acestor probleme

Un scaner automat poate verifica dacă aria-describedby indică un element existent și dacă aria-invalid este prezent. Nu poate verifica dacă focalizarea se mută corect după trimitere, dacă textul erorii este corect sau dacă o notificare toast dispare înainte de a putea fi citită. Auditurile noastre manuale de accesibilitate includ testare specifică pentru formulare cu tehnologii de asistare reale — singura modalitate fiabilă de a verifica dacă gestionarea erorilor chiar funcționează de la un capăt la altul.

Dacă nu ești sigur unde se situează formularele tale, rulează o scanare gratuită pentru a scoate la iveală mai întâi problemele automatizabile, apoi continuă de acolo.