Formulare accesibile: etichete, indicații, mesaje de eroare

Șase criterii de succes pentru formulare

WCAG 2.2 este recomandarea W3C actuală pentru conținut web accesibil. Pentru textele unui formular contează cel mai mult șase dintre criteriile sale de succes:

• 1.3.1 Info and Relationships (nivel A): ce arată aspectul vizual, de exemplu ce etichetă aparține cărui câmp, este disponibil și în cod sau în text.
• 1.3.5 Identify Input Purpose (nivel AA): câmpurile care cer informații despre utilizator, precum numele sau adresa de e-mail, își declară scopul în cod.
• 3.3.1 Error Identification (nivel A): dacă o eroare de introducere este detectată automat, câmpul este numit și eroarea este descrisă în text.
• 3.3.2 Labels or Instructions (nivel A): există etichete sau instrucțiuni atunci când conținutul cere date de la utilizator.
• 3.3.3 Error Suggestion (nivel AA): dacă o eroare este detectată și corectura este cunoscută, aceasta este sugerată, cu excepția cazului în care ar pune în pericol securitatea sau scopul conținutului.
• 4.1.2 Name, Role, Value (nivel A): fiecare element de control are un nume și un rol pe care software-ul le poate citi.

Fiecare câmp are nevoie de o etichetă vizibilă

O etichetă spune ce se scrie în câmp și rămâne vizibilă cât timp utilizatorul tastează. În HTML, leagă elementul label de câmp: atributul for al etichetei are exact aceeași valoare ca id-ul câmpului. Cititoarele de ecran citesc atunci eticheta împreună cu câmpul, iar un clic pe etichetă pune cursorul în câmp. Un buton își ia eticheta din textul său, iar „Trimite mesajul” spune mai mult decât „Trimite”. Etichetele stau de obicei în dreapta butoanelor radio și a casetelor de bifare și în stânga sau deasupra celorlalte câmpuri; etichetele de deasupra câmpurilor ocupă mai puțin spațiu pe lățime.

Un placeholder nu este o etichetă

Textul gri dintr-un câmp gol arată ca o etichetă, dar nu este. W3C numește problemele:

• Dispare imediat ce cineva tastează, așa că datele introduse se verifică mai greu înainte de trimitere.
• Browserele îl afișează adesea într-o culoare deschisă, cu prea puțin contrast.
• Cititoarele de ecran nu îl tratează ca etichetă, iar suportul diferă.

Folosește un placeholder cel mult pentru un exemplu și pune tot ce este important în etichetă sau într-o indicație.

Indicații și câmpuri obligatorii

• Pune regulile într-o indicație: formatul datei, lungimea unui număr de client, ce trebuie să conțină o parolă. În HTML poți lega indicația cu aria-describedby, astfel încât cititoarele de ecran o citesc după etichetă.
• Spune ce câmpuri sunt obligatorii și care sunt opționale. Dacă folosești un asterisc, explică-l o dată la începutul formularului.
• Pune instrucțiunile pentru întregul formular înaintea formularului, de exemplu despre o limită de timp.
• Păstrează indicațiile scurte. Prea multe instrucțiuni fac un formular mai greu, nu mai ușor.

Grupează câmpurile înrudite

Butoanele radio și casetele de bifare care țin împreună se grupează cu elementul fieldset, iar elementul legend numește grupul, de exemplu „Cum să te contactăm?”. W3C spune că grupurile de butoane radio ar trebui grupate întotdeauna așa. Păstrează legenda scurtă, pentru că unele cititoare de ecran o citesc la fiecare câmp. Grupurile ajută și la câmpurile cu aceeași etichetă, de exemplu strada din adresa de livrare și din adresa de facturare.

autocomplete: lasă browserul să ajute

Pentru câmpurile care cer informații despre utilizator, 1.3.5 cere ca scopul lor să poată fi determinat în cod. WCAG 2.2 are o listă cu aceste scopuri, bazată pe secțiunea despre completarea automată din specificația HTML, de exemplu name, given-name, family-name, email, tel, street-address și postal-code. În HTML le setezi cu atributul autocomplete, de exemplu autocomplete="email". Browserele pot completa atunci valorile salvate, ceea ce scutește tastarea. Câmpurile care nu se referă la utilizator nu au nevoie de un scop.

Mesaje de eroare care ajută

Un mesaj de eroare are trei sarcini: numește câmpul, spune ce este greșit și spune cum se corectează. 3.3.1 le cere pe primele două, în text, deci un chenar roșu sau o pictogramă nu sunt suficiente singure. 3.3.3 cere corectura acolo unde este cunoscută.

• Afișează mesajul lângă câmp și leagă-l cu aria-describedby, astfel încât cititoarele de ecran îl citesc împreună cu câmpul.
• După trimitere, afișează sus, înaintea formularului, o listă cu toate erorile, sub un titlu clar. Fiecare intrare numește câmpul, problema și corectura și trimite printr-un link la câmp.
• Actualizează și titlul paginii, de exemplu „2 erori – Formular de contact”, și mută focusul pe primul câmp cu eroare.
• Păstrează ce a introdus deja utilizatorul. Acesta este sfatul nostru, nu o regulă WCAG: să tastezi totul din nou după o singură greșeală îi face pe oameni să renunțe.

Verifică-ți formularul cu Do4U

Instrumentul Textele formularelor verifică textele unui formular web. Lipești HTML-ul formularului sau dai adresa paginii și poți adăuga mesajele de eroare pe care le afișează formularul tău. Codul citește fiecare câmp: eticheta și de unde provine ea, indicațiile, placeholderele, câmpurile obligatorii, valorile autocomplete și grupurile de butoane radio sau casete de bifare. Găsește probleme precum un câmp fără etichetă, un placeholder ca singură etichetă, câmpuri obligatorii pe care textul nu le menționează, valori autocomplete lipsă și mesaje de eroare vagi, fiecare cu criteriul său de succes. AI-ul propune o etichetă clară, o indicație scurtă și un mesaj de eroare care numește câmpul și spune cum se corectează datele. Codul verifică fiecare propunere și creează din formularul tău o ciornă HTML îmbunătățită.

Do4U găsește indicii și creează o ciornă, tu verifici și decizi. Instrumentul verifică marcajul, nu stilurile, scripturile sau folosirea cu tastatura, și nu îți spune dacă formularul tău este accesibil. Testează formularul îmbunătățit cu tastatura și cu un cititor de ecran.