WCAG 3.3.1 Identificarea erorilor

Criteriul de succes 3.3.1 asigură că oamenii observă când un formular nu a fost acceptat și știu care câmp este greșit. Utilizatorii nevăzători nu văd un chenar roșu, persoanele cu deficiențe de vedere a culorilor s-ar putea să nu îl observe, iar persoanele cu dizabilități cognitive s-ar putea să nu înțeleagă o pictogramă. Într-un magazin, de aici vine adesea diferența dintre o comandă finalizată și un coș abandonat. Este de nivelul A și apare în EN 301 549 drept clauza 9.3.3.1; Legea 232/2022 se bazează pe standardul armonizat EN 301 549.

Ce cere criteriul

Dacă o eroare de introducere este detectată automat, atunci:

1. elementul cu eroare este identificat și
2. eroarea este descrisă utilizatorului în text.

O eroare de introducere înseamnă informații furnizate de utilizator care nu sunt acceptate. Aici intră informațiile obligatorii omise și informațiile care nu respectă formatul sau valorile cerute. WCAG nu prescrie modul de afișare a erorilor. Explicarea modului de corectare a erorii este acoperită separat de 3.3.3 Sugestii pentru erori.

Greșeli tipice într-un magazin online

• un câmp invalid este semnalat doar printr-un chenar roșu sau o pictogramă roșie, fără text;
• pagina de finalizare a comenzii se reîncarcă după „Plasează comanda” fără niciun mesaj sau doar cu un mesaj generic „A apărut o eroare”;
• un mesaj apare în partea de sus a paginii, dar nu spune care câmp este afectat;
• erorile cardului din widgetul de plată sunt afișate ca imagine sau dispar după câteva secunde;
• textul erorii este prezent vizual, dar nu este legat de câmp, așa că un utilizator de cititor de ecran aflat pe câmp nu îl aude.

Cum se verifică

Automat: verificatorul nostru nu are nicio regulă pentru acest criteriu. O scanare automată nu trimite formularele dumneavoastră cu date greșite, așa că este nevoie de o verificare manuală.

Manual: pentru fiecare formular important — înregistrare, autentificare, newsletter, contact, finalizarea comenzii, agenda de adrese — trimiteți-l cu câmpurile obligatorii goale, apoi cu formate greșite (e-mail fără @, cod poștal prea scurt, dată de expirare trecută). Confirmați că fiecare eroare este afișată în text, numește câmpul sau trimite la el și este citită de un cititor de ecran când ajungeți pe câmp.

Cum se remediază

• Afișați un mesaj text lângă fiecare câmp invalid, de exemplu „Adresă de e-mail: introduceți o adresă de forma [email protected]”.
• Legați mesajul de câmp cu aria-describedby și setați aria-invalid="true" pe câmp.
• La formularele lungi, adăugați la început un rezumat al erorilor cu linkuri către câmpuri și mutați focusul pe el după trimitere.
• Păstrați mesajele vizibile până când eroarea este corectată; nu vă bazați doar pe culori sau pictograme.

Criterii conexe

• 3.3.3 Sugestii pentru erori — spuneți utilizatorilor cum să corecteze eroarea.
• 4.1.3 Mesaje de stare — anunțați erorile care apar fără ca focusul să se mute.
• 1.4.1 Utilizarea culorii — culoarea nu trebuie să fie singurul semnal.

Întrebări frecvente

Este suficient un chenar roșu pentru a semnala o eroare în formular?

Nu. WCAG 3.3.1 cere ca eroarea să fie descrisă în text. Doar culoarea încalcă și 1.4.1 Utilizarea culorii. Adăugați lângă câmp un mesaj precum „Introduceți codul poștal”.

Se aplică 3.3.1 câmpurilor obligatorii goale?

Da. Informațiile cerute de pagină, dar omise de utilizator, contează ca eroare de introducere, așa că un câmp obligatoriu gol trebuie identificat și descris în text.

Spune WCAG unde trebuie să apară mesajele de eroare?

Nu se cere un anumit mod de afișare. O bună practică obișnuită este un mesaj lângă câmp, legat de acesta cu aria-describedby, iar la formularele lungi un rezumat la începutul formularului.