Oamenii nu ar trebui să fie nevoiți să descifreze interfața
Imaginați-vă un formular de solicitare pentru un proiect de site. Un vizitator descrie sarcina, adaugă un contact și apasă pe trimitere, dar vede doar un contur roșu. Lipsește un număr de telefon, a eșuat conexiunea sau solicitarea a fost deja trimisă? Această incertitudine este o problemă de design, nu o lipsă de atenție. O machetă utilă trebuie să acopere datele neterminate, erorile multiple, așteptarea și succesul, nu doar un formular completat perfect. Aceste mici stări determină dacă întregul parcurs are sens.
Explicați ce necesită câmpul
Fiecare câmp are nevoie de o etichetă inteligibilă; WAI recomandă asocierea ei cu elementul de control. Un exemplu de format nu înlocuiește eticheta. În brieful nostru imaginar, numărul de telefon ar putea fi marcat opțional când adresa de e-mail este suficientă. O adresă completă a firmei nu trebuie cerută doar din obișnuință, când nu are niciun scop în prima conversație. Înainte de a desena formularul, enumerați câmpurile și explicați de ce există fiecare. Dacă un câmp nu are un scop clar, reconsiderați-l. W3C WAI: Etichetarea comenzilor
Numiți problema reală
Erorile detectate au nevoie de o descriere textuală care identifică respectivul câmp; culoarea singură nu este suficientă. În locul unui mesaj vag despre date nevalide, un câmp de contact necompletat poate spune „Adăugați adresa de e-mail”. Pentru formularul nostru de solicitare, pregătiți formulări separate pentru un contact gol, o descriere incompletă și un serviciu indisponibil. Reunirea lor într-un singur banner roșu ascunde o distincție importantă: corectarea datelor și recuperarea după eșecul trimiterii necesită acțiuni diferite. W3C: Identificarea erorilor
Oferiți o cale de remediere
Când o corecție este cunoscută și poate fi sugerată în siguranță, explicați-o. Dacă un câmp are o limită specifică de lungime, descrieți acea limită în loc să cereți oamenilor să încerce din nou. Într-un formular mai lung, un rezumat al erorilor cu linkuri către câmpurile afectate poate completa îndrumările din apropiere. Evitați mesajele care acoperă textul introdus. Parcurgeți procesul cu tastatura: persoana trebuie să poată găsi problema, să o corecteze și să continue fără a rescrie întregul brief al proiectului. W3C: Sugestii pentru corectarea erorilor
Validarea nu înseamnă livrare
Validarea în browser nu înlocuiește validarea pe server. Nici o adresă formatată corect nu dovedește că un mesaj a fost livrat. Textul rezultatului trebuie să corespundă răspunsului real al sistemului. În exemplul nostru, salvarea unei solicitări este diferită de o trimitere nereușită. Nu promiteți un apel înapoi în cinci minute dacă acel proces nu există efectiv. Tratați clicurile repetate, conexiunea lentă și redeschiderea paginii ca situații separate, în loc să presupuneți că fiecare cerere urmează traseul ideal. MDN: Validarea formularelor pe partea clientului
Testați mai mult decât succesul
WAI recomandă feedback atât pentru trimiterile reușite, cât și pentru cele nereușite. Înainte de lansare, încercați un formular gol, un contact incorect, o descriere lungă, corectarea, succesul și o defecțiune a serviciului. Verificați textul mărit, telefonul și navigarea cu tastatura; accesibilitatea necesită și testare cu tehnologie asistivă. Această listă scurtă nu este o certificare. Este o modalitate practică de a descoperi dacă formularul îi ajută pe oameni să avanseze, în loc să-i lase să interpreteze un chenar roșu fără explicație. W3C WAI: Notificări pentru utilizatori