Cum faci accesibil site-ul tău web: un ghid de pornire WCAG 2.2

Ca să faci accesibil un site web, construiește-l astfel încât oamenii să îl poată folosi cu tastatura, cu un cititor de ecran, cu zoom sau cu un dispozitiv de tip switch, nu doar cu mouse-ul: folosește elemente HTML reale pentru butoane, linkuri, titluri și etichete de formular, dă imaginilor un text alternativ semnificativ, menține un contrast ridicat al textului și fă focusul vizibil. Standardul de urmărit este WCAG 2.2 nivelul AA. Verificatoarele automate prind o parte din problemă; un test de zece minute cu tastatura și cu un cititor de ecran prinde o mare parte din restul.

Ce înseamnă „accesibil” în practică

Accesibilitatea ține de oameni: cineva care este nevăzător și folosește un cititor de ecran, cineva cu tremur care navighează cu tastatura, cineva cu vedere slabă care mărește la 200%, cineva care citește în lumina puternică a soarelui, cineva cu o mână ruptă temporar. O bună accesibilitate tinde să facă un site mai bun pentru toată lumea — structură mai clară, text ușor de citit, formulare care își explică erorile.

Standardul de referință sunt Web Content Accessibility Guidelines (WCAG) ale W3C. Din septembrie 2026, versiunea actuală este WCAG 2.2 (publicată în octombrie 2023, actualizată în decembrie 2024); WCAG 3 este o schiță timpurie. WCAG este organizat în jurul a patru principii — conținutul trebuie să fie perceptibil, operabil, ușor de înțeles și robust — și are trei niveluri de conformitate:

Legi din mai multe locuri fac referire la WCAG — de exemplu, Actul european privind accesibilitatea, care se aplică din iunie 2025 multor servicii digitale destinate consumatorilor din UE. Ce reguli se aplică ție depinde de unde operezi și ce vinzi; cere sfatul unui consultant dacă nu ești sigur. Acest ghid acoperă partea practică.

Opțiuni: cum ajungi acolo

Pentru majoritatea site-urilor mici, primele două sunt suficiente: spune AI-ului să construiască accesibil de la început, apoi auditează înainte de lansare.

Remedierile care contează cel mai mult

Folosește elementele HTML potrivite

Majoritatea accesibilității vine gratuit cu un HTML corect. Un <button> este focalizabil, funcționează cu Enter și cu Space și este anunțat ca buton. Un <div> cu un handler de click nu este niciuna dintre acestea. Codul generat de AI folosește uneori div-uri stilizate pentru orice; cere elemente semantice:

• <button> pentru acțiuni, <a href> pentru navigare
• Un singur <h1> pe pagină, apoi <h2>, <h3> în ordine — utilizatorii de cititoare de ecran sar între titluri
• Repere: <header>, <nav>, <main>, <footer>
• <label> conectat la fiecare câmp de formular
• Limba paginii în <html lang="ro">

Folosește atribute ARIA doar când niciun element nativ nu se potrivește — de exemplu, pentru un set de taburi personalizat sau un combobox. ARIA greșit este mai rău decât lipsa ei.

Acces prin tastatură și focus vizibil

Tot ce poți face cu mouse-ul trebuie să funcționeze doar cu tastatura (WCAG 2.1.1). Apasă Tab prin pagină: fiecare link, buton și câmp trebuie să fie accesibil într-o ordine logică și trebuie să vezi mereu unde este focusul (2.4.7 Focus Visible). WCAG 2.2 a adăugat că elementul focalizat nu trebuie să fie complet ascuns în spatele antetelor lipicioase sau al benzilor de cookie-uri (2.4.11, nivelul AA).

Eșecurile frecvente: meniuri care se deschid doar la hover, modale care nu rețin focusul sau nu se pot închide cu Escape și outline: none în CSS fără nimic care să îl înlocuiască.

Alternative textuale

Fiecare imagine semnificativă are nevoie de un text alternativ care spune ce arată în context („Bucătarul servind meniul degustare”, nu „image1.jpg”). Imaginile decorative primesc un alt="" gol, ca cititoarele de ecran să le sară. Butoanele cu doar pictogramă au nevoie de un nume accesibil („Închide”, „Caută”). Videoclipurile au nevoie de subtitrare; audio are nevoie de transcriere.

Culoare și contrast

WCAG 2.2 AA cere un raport de contrast de cel puțin 4,5:1 pentru text normal și 3:1 pentru text mare (1.4.3), și 3:1 pentru părțile de interfață, cum ar fi marginile câmpurilor de introducere și pictogramele importante (1.4.11). Textul gri-deschis din placeholder și butoanele palide sunt eșecurile obișnuite. De asemenea, nu folosi niciodată doar culoarea pentru a transmite sens — o margine roșie la un câmp invalid are nevoie și de un mesaj de eroare.

Redimensionare și reflow

Textul trebuie să rămână utilizabil când este mărit la 200% (1.4.4), iar conținutul trebuie să funcționeze la o lățime de 320 de pixeli CSS fără derulare laterală (1.4.10). O structură responsivă rezolvă cea mai mare parte din asta.

Ținte, formulare și erori

• Dimensiunea țintei: WCAG 2.2 AA cere ținte de indicator de cel puțin 24 pe 24 de pixeli CSS, sau spațiu suficient în jurul celor mai mici (2.5.8). Mai mare înseamnă mai prietenos pe telefoane.
• Formulare: etichete vizibile (nu doar placeholder), instrucțiuni clare și mesaje de eroare care spun ce nu este în regulă și cum se remediază, lângă câmp.
• Autentificare: nu cere oamenilor să rezolve un puzzle sau să transcrie un cod fără o alternativă; permite managerii de parole și lipirea (3.3.8 Accessible Authentication).

Prompturi care funcționează

Construiește acest site să respecte WCAG 2.2 nivelul AA: repere HTML semantice, un singur h1 pe pagină cu titluri în ordine, elemente reale de buton și link, etichete pentru fiecare câmp de formular, stiluri de focus vizibile, contrast de text de cel puțin 4,5:1, text alternativ pe imaginile semnificative și alt="" pe cele decorative și html lang setat.

Auditează paginile /signup și /checkout din punct de vedere al accesibilității. Verifică utilizarea doar cu tastatura, ordinea focusului, focusul vizibil, etichetele, mesajele de eroare, contrastul și numele pentru cititoarele de ecran ale butoanelor cu pictogramă. Listează fiecare problemă cu criteriul WCAG, apoi repar-le fără să schimbi designul vizual mai mult decât e necesar.

Meniul mobil nu poate fi folosit cu tastatura. Fă-l un buton cu aria-expanded, mută focusul în meniu când se deschide, închide-l cu Escape și readu focusul pe buton.

Pas cu pas

1. Rulează o verificare automată. Secțiunea Accessibility din Lighthouse, din DevTools-ul Chrome, sau extensia axe pentru browser, pe fiecare pagină principală. Repară tot ce raportează.
2. Scoate mouse-ul din discuție. Parcurge fiecare pagină cu Tab și finalizează fiecare sarcină importantă — înscriere, căutare, comandă. Notează orice nu poți ajunge, nu vezi focusul sau nu poți ieși din el.
3. Mărește la 200% și micșorează fereastra la lățimea telefonului. Nimic nu trebuie tăiat sau să necesite derulare laterală.
4. Încearcă un cititor de ecran zece minute: VoiceOver pe Mac și iPhone, TalkBack pe Android sau NVDA pe Windows (gratuit). Ascultă titlurile, linkurile și câmpurile de formular. „Buton” fără nume sau „link, apasă aici” înseamnă muncă de făcut.
5. Verifică contrastul pentru text, butoane și câmpuri cu un verificator de contrast.
6. Repară, apoi retestează aceleași sarcini.
7. Publică o declarație de accesibilitate care spune ce standard urmărești și cum poți fi raportată o problemă — și răspunde la aceste raportări.

Greșeli frecvente

• Să te bazezi pe un widget de tip overlay în loc să repari codul.
• Să elimini conturul de focus pentru că arată neîngrijit, fără nimic în loc.
• Textul din placeholder ca singură etichetă. Dispare când cineva începe să scrie și este adesea cu contrast slab.
• Linkuri „Apasă aici” și „Citește mai mult”. Scoase din context, utilizatorii de cititoare de ecran aud o listă de linkuri identice.
• Text alternativ plin de cuvinte cheie. Textul alternativ este pentru oameni; descrie imaginea.
• Testarea o singură dată. Fiecare funcție nouă poate strica accesul prin tastatură. Adaugă o trecere cu tastatura la testarea înainte de lansare.

Listă de verificare pentru accesibilitate

• Verificarea automată (Lighthouse sau axe) curată pe paginile principale
• Fiecare sarcină poate fi finalizată doar cu tastatura
• Focusul mereu vizibil și niciodată ascuns în spatele elementelor lipicioase
• Titluri, repere, butoane și linkuri semantice; lang setat
• Text alternativ semnificativ; imagini decorative cu alt=""; subtitrare la video
• Contrast text ≥ 4,5:1 (text mare ≥ 3:1); părțile de interfață ≥ 3:1
• Funcționează la zoom de 200% și la lățime de 320 px
• Fiecare câmp de formular are o etichetă vizibilă și mesaje de eroare clare
• Declarație de accesibilitate cu o cale de a raporta probleme

Pentru conceptele din spatele acestora, citește ce este accesibilitatea web. Designul accesibil și cel bun se suprapun mult; cum faci o aplicație cu design bun cu AI acoperă partea vizuală.

Accesibilitatea pe Mythex

Mythex construiește cu standardul pe care îl ceri, deci pune „WCAG 2.2 AA” în primul prompt și în cererile următoare. Poți folosi cadrul de previzualizare pentru dimensiunea telefonului din Preview (Preview și Cod), dar testele cu tastatura, zoom-ul și cititorul de ecran funcționează cel mai bine pe URL-ul publicat sau pe o previzualizare deschisă într-un tab separat. Cere agentului să auditeze o pagină, să repare ce găsește și apoi testează tu reparațiile — o trecere automată este un început, nu o aprobare finală.

Întrebări