Validarea accesibilă a formularelor și mesajele de eroare

Formularele de checkout și de înregistrare sunt locul în care magazinele pierd clienți, iar tratarea erorilor este locul în care formularele îi încurcă cel mai des pe cei care folosesc cititoare de ecran, mărire sau tastatura. Regula este simplă: spuneți ce este greșit, în text, lângă câmp, și asigurați-vă că tehnologia asistivă aude asta. Această pagină face parte din seria modele de interfață accesibile.

Criterii WCAG relevante

• 3.3.1 Identificarea erorilor (A): „elementul care conține eroarea este identificat, iar eroarea îi este descrisă utilizatorului în text”. W3C adaugă că se poate folosi culoarea, dar doar în plus față de text.
• 3.3.3 Sugestii pentru erori (AA): dacă o eroare este detectată automat și se cunoaște o corectură, sugerați-o, cu excepția cazului în care asta ar compromite securitatea sau scopul conținutului. „E-mailul nu este valid” îndeplinește 3.3.1; „Introduceți o adresă de e-mail în formatul [email protected]” îndeplinește și 3.3.3.
• 3.3.2 Etichete sau instrucțiuni (A): spuneți dinainte ce este obligatoriu și în ce format.
• 4.1.3 Mesaje de stare (AA): exemplul W3C este textul „5 erori pe pagină” adăugat într-un formular fără mutarea focusului — trebuie anunțat. Un mesaj care primește focusul este o schimbare de context, nu un mesaj de stare.
• 3.3.4 Prevenirea erorilor (juridice, financiare, date) (AA): comenzile trebuie să poată fi anulate, verificate sau confirmate înainte de a deveni definitive.
• 1.4.1 Utilizarea culorii (A), 1.4.3 Contrast (minim) (AA): textul roșu pe alb trebuie să atingă totuși 4,5:1.
• 3.3.7 Introducere redundantă (A): după o eroare, nu le cereți utilizatorilor să reintroducă date pe care le-au dat deja.

Exemplu de cod

<form novalidate>
  <div id="error-summary" tabindex="-1" aria-labelledby="error-summary-title" hidden>
    <h2 id="error-summary-title">2 erori în formular</h2>
    <ul>
      <li><a href="#email">E-mail: introduceți o adresă în formatul [email protected]</a></li>
      <li><a href="#postcode">Cod poștal: introduceți-l în formatul 010011</a></li>
    </ul>
  </div>

  <label for="email">E-mail</label>
  <input id="email" type="email" autocomplete="email"
         aria-invalid="true" aria-describedby="email-error">
  <p id="email-error" class="error">
    <span aria-hidden="true">⚠</span> Introduceți o adresă în formatul [email protected]
  </p>

  <label for="postcode">Cod poștal <span class="hint" id="postcode-hint">(de exemplu 010011)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Introduceți codul poștal în formatul 010011</p>

  <button type="submit">Continuați spre plată</button>
</form>

Cum funcționează:

• Text, lângă câmp. Fiecare mesaj este text vizibil, legat cu aria-describedby, astfel încât este citit împreună cu câmpul. aria-invalid="true" marchează câmpul ca invalid — tehnica W3C ARIA21 „Using aria-invalid to Indicate An Error Field”.
• Rezumatul erorilor la trimitere. Afișați sus un rezumat cu linkuri către câmpuri și mutați focusul pe el (are tabindex="-1", ca să poată primi focusul) sau mutați focusul pe primul câmp invalid. Dacă nu mutați focusul, anunțați în schimb erorile printr-o regiune live — tehnica W3C ARIA19, „Using ARIA role=alert or Live Regions to Identify Errors”. Nu le faceți pe amândouă, altfel mesajul este citit de două ori.
• Validarea inline în timpul tastării trebuie să fie discretă: validați când utilizatorul părăsește câmpul, nu la fiecare tastă, și eliminați eroarea imediat ce a fost corectată.
• Păstrați datele. După o trimitere eșuată, păstrați tot ce a introdus utilizatorul.
• Validarea nativă a browserului (required, type="email") funcționează și ea, dar mesajele și stilul diferă în funcție de browser și limbă; multe magazine folosesc novalidate și mesaje proprii în limba paginii.

Comportamentul tastaturii și al focusului

Greșeli frecvente în magazinele online

• Doar un chenar roșu în jurul câmpului invalid sau un asterisc roșu fără text.
• Erori afișate ca toast în partea de sus a ecranului, care dispare după trei secunde și nu este anunțat niciodată.
• Mesaje generice — „Date invalide”, „Eroare” — fără nicio indicație despre formatul așteptat.
• Placeholder ca singură etichetă și singur indiciu de format, care dispare imediat ce utilizatorul începe să scrie.
• Mesaje nelegate de câmpuri, așa că utilizatorii de cititoare de ecran aud eticheta și nimic altceva.
• Butonul de trimitere dezactivat până când formularul este valid, care ascunde problema în loc să o explice; vedeți butoane dezactivate.
• Iframe-uri ale procesatorului de plăți cu câmpuri proprii fără etichete și erori doar în engleză pe un magazin localizat.
• Formularul este golit după o eroare pe server, inclusiv adresa de livrare.

Ce găsesc verificările automate și ce rămâne pentru testarea manuală

Toate sunt carduri în biblioteca noastră de reguli. Verificarea automată vede formularul în starea inițială; nu îl trimite. Testați manual: trimiteți câmpuri goale și valori greșite, verificați că fiecare eroare este descrisă în text, legată de câmpul ei, anunțată de un cititor de ecran și lizibilă la zoom de 200 %. Cu extensia de browser puteți rula din nou regulile automate cât timp erorile sunt pe ecran. Pașii sunt în cum se testează WCAG.

Rulați verificarea gratuită a unei pagini pe pagina de checkout sau de contact. Este o verificare automată, nu un audit complet.

Întrebări frecvente

Ce cere WCAG pentru erorile din formulare?

3.3.1 Identificarea erorilor (A): câmpul cu eroare este identificat, iar eroarea este descrisă în text. 3.3.3 Sugestii pentru erori (AA): dacă se cunoaște o corectură, sugerați-o. 4.1.3 Mesaje de stare (AA): mesajele care apar fără mutarea focusului sunt anunțate de tehnologiile asistive.

Este suficient un chenar roșu pentru a arăta o eroare?

Nu. W3C spune că poate fi folosită și culoarea, dar eroarea trebuie identificată și în text. Doar un chenar roșu îi lasă fără informație pe cei care nu pot distinge culoarea și pe utilizatorii de cititoare de ecran.

Cum leg un mesaj de eroare de un câmp?

Dați mesajului un id, faceți trimitere la el din câmp cu aria-describedby și setați aria-invalid="true" pe câmp (tehnica W3C ARIA21). Cititorul de ecran citește apoi eticheta, starea invalidă și mesajul.

Trebuie mutat focusul pe prima eroare?

La trimitere, mutarea focusului pe un rezumat al erorilor sau pe primul câmp invalid este o abordare obișnuită și robustă. Dacă focusul nu se mută, un mesaj precum „3 erori în formular” trebuie să fie un mesaj de stare, ca să fie anunțat.

Poate o verificare automată să testeze erorile din formulare?

Verifică formularul în starea inițială: etichete, valori autocomplete, referințe ARIA valide și contrast. Nu trimite formulare, așa că dacă erorile apar, sunt descrise în text și sunt anunțate trebuie testat manual.

Surse

• W3C, Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• W3C, Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html
• W3C, Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html