Pe scurt
O interfață vizuală leagă acțiunile utilizatorului de funcțiile unui program. Formularele conțin controale: câmpuri de text, butoane, liste, casete de bifare și etichete. Un eveniment este o acțiune detectată, precum apăsarea unui buton. Un formular bun spune ce date cere, marchează câmpurile obligatorii și explică erorile lângă câmp. Contrastul, mărimea textului și ordinea de parcurgere cu tastatura influențează accesibilitatea.
În detaliu
Proiectarea pornește de la sarcinile utilizatorului, nu de la numărul de efecte grafice. Un câmp de dată are etichetă și format clar; validarea verifică valoarea înainte de salvare. Mesajele de eroare descriu problema și soluția, fără a elimina datele deja introduse. Pentru controale fără text vizibil se oferă un nume accesibil. Testarea include ecran mic, mărirea textului și navigarea fără mouse.
Exemplu lucrat. Formularul unei biblioteci cere titlul cărții, codul ei și data returnării. Dacă lipsește codul, mesajul „Introduceți codul cărții” apare lângă câmp, iar titlul deja completat rămâne. Utilizatorul poate ajunge la butonul „Trimite” cu Tab și poate confirma cu Enter.
Evenimentul și rutina lui, pe pași. Interfața ascultă evenimente și, la fiecare, pornește o rutină. Pentru butonul „Trimite” din formularul bibliotecii, succesiunea este: utilizatorul apasă butonul sau Enter; programul primește evenimentul de apăsare; rutina citește cele trei câmpuri; verifică dacă fiecare are valoare și dacă data are forma cerută; dacă totul este corect, salvează împrumutul și afișează „Cartea a fost înregistrată”; dacă nu, oprește salvarea și afișează mesajul lângă câmpul greșit.
Exemplul 2 — contrastul dintre text și fundal. Contrastul se exprimă printr-un raport calculat din luminanța celor două culori. Recomandarea de accesibilitate WCAG 2.2, nivel AA, cere cel puțin 4,5:1 pentru textul obișnuit și 3:1 pentru textul mare. Pe fundal alb, textul negru are raportul 21:1, gri #595959 are 7:1, gri #767676 are 4,54:1 și trece la limită, iar gri #999999 are 2,85:1 și nu trece. Roșul pur #ff0000 pe alb are 4,00:1: nu este suficient pentru un mesaj de eroare scris cu litere mici, deși ar fi suficient pentru un titlu mare. De aceea o eroare se marchează cu o culoare mai închisă, cu un text și, la nevoie, cu o pictogramă, nu doar cu o nuanță.
Exemplul 3 — numele accesibil și ordinea tastaturii. Un buton care arată doar un coș de gunoi nu spune nimic unui cititor de ecran, dacă nu are un nume accesibil, de pildă „Șterge împrumutul”. Ordinea de parcurgere cu Tab trebuie să urmeze ordinea logică din formular: titlu, cod, dată, „Trimite”. Dacă un element este mutat vizual, dar rămâne la alt loc în ordinea paginii, cursorul va sări neașteptat. Ținta de atingere trebuie să fie suficient de mare: WCAG 2.2 cere cel puțin 24 pe 24 de pixeli pentru comenzile mici, pentru ca degetul să nu le atingă pe cele vecine.
Exemplul 4 — mesajul de eroare util. Compară „Eroare” cu „Data trebuie scrisă ca zz.ll.aaaa, de exemplu 05.11.2026”. Primul mesaj nu spune unde este problema și nici cum se repară; al doilea arată câmpul, regula și un model.
Greșeli frecvente
- Greșit: Placeholderul care dispare înlocuiește întotdeauna eticheta.Corect: eticheta rămâne disponibilă și clară.
- Greșit: Roșul singur este suficient pentru a semnala eroarea.Corect: adaugi și mesaj text.
- Greșit: Testarea doar cu mouse-ul dovedește accesibilitatea.Corect: verifici și tastatura.
Testează-te pe această lecție
Lecția o citești aici, fără cont. Testele pe lecții și capitole sunt în cont, cu grile originale Didaxis și explicația fiecăreia: gratuit 10 grile pe zi, fără limită cu Premium, 49 de lei pe lună pentru fiecare copil.
Înainte și după
Surse și referințe
Redactare proprie, conform programei:
Documente consultate
- OMEC 3716/2026, anexa 43, p. 10, pct. 2.1; rocnee.eu
Desene: Redactare proprie (desen original), conform OMEC 3716/2026, anexa 43, p. 10, pct. 2.1; rocnee.eu
