Erori frecvente de accesibilitate de evitat

De ce apar mereu aceleași probleme de accesibilitate

Majoritatea barierelor de accesibilitate nu sunt exotice. An după an, auditurile automate și manuale scot la iveală aceeași listă scurtă de greșeli: text alternativ lipsă, contrast scăzut, câmpuri de formular fără etichetă, capcane de tastatură și structură deteriorată. Reapar pentru că sunt introduse în tăcere — un dezvoltator lansează o componentă nouă, un specialist în marketing încarcă o imagine, un designer alege o culoare de brand — și nimic din fluxul de lucru normal nu semnalează problema. Rezultatul vizual arată bine pentru cineva care folosește un mouse și are o vedere bună, așa că bariera ajunge în producție.

Acest catalog parcurge cele mai frecvente eșecuri WCAG 2.2 pe care le vedem în auditurile reale. Pentru fiecare vei găsi de ce contează, pe cine afectează, criteriul de succes relevant și o remediere concretă înainte/după. Împreună, aceste probleme reprezintă marea majoritate a barierelor care blochează utilizatorii cu dizabilități — și marea majoritate a plângerilor legale depuse în temeiul Actului European privind Accesibilitatea, al ADA și al Section 508.

Un lucru de clarificat înainte de listă: instrumentele automate nu pot găsi toate aceste probleme. Cercetările independente arată în mod constant că până și cele mai bune scanere detectează în mod fiabil doar 30–40% dintre problemele WCAG. Sunt excelente la depistarea atributelor alt lipsă, a eșecurilor de contrast programatice și a etichetelor de formular absente, dar nu pot judeca dacă textul alternativ este exact, dacă ordinea focalizării este logică sau dacă un widget personalizat chiar funcționează cu un cititor de ecran. De aceea, orice program credibil combină scanarea cu revizuirea manuală. Software-ul nostru de scanare a accesibilității se ocupă de stratul automatizabil; auditurile manuale și auditurile efectuate de persoane cu dizabilități acoperă restul.

O modalitate rapidă de a-ți găsi propriul punct de plecare înainte de a continua: vizualizează pagina cu imaginile dezactivate, citește fiecare cuvânt ca pe un singur paragraf nestructurat și încearcă să finalizezi fiecare sarcină folosind doar tastatura. Oriunde experiența se prăbușește, ai găsit o barieră.

Perceptibil: conținut pe care oamenii nu îl pot vedea sau citi

Text alternativ lipsă sau inexact pentru imagini

Pe cine afectează: persoanele nevăzătoare sau cu vedere slabă care folosesc cititoare de ecran; oricine are o conexiune lentă unde imaginile nu se încarcă.

Criteriu WCAG: 1.1.1 Conținut non-text (Nivel A).

Imaginile fără un atribut alt sunt invizibile pentru tehnologia asistivă — este posibil ca utilizatorul să nu știe nici măcar că imaginea există. Mai rău decât un atribut lipsă este unul inexact: nume de fișiere precum IMG_4821.jpg, cuvinte generice precum „imagine” sau șiruri îndesate cu cuvinte-cheie induc activ în eroare ascultătorul.

Regula este simplă, dar depinde de situație. Imaginile informative au nevoie de o descriere concisă a semnificației lor, nu a aspectului. Imaginile decorative care nu adaugă nimic trebuie să poarte un alt="" gol, astfel încât cititoarele de ecran să le omită. Imaginile funcționale — o pictogramă care acționează ca un buton — trebuie să descrie acțiunea, nu imaginea. Elementele vizuale complexe, precum graficele, au nevoie de un alt scurt plus un echivalent textual mai lung în apropiere.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Instrumentele automate detectează instantaneu absența textului alternativ. Nu îți pot spune dacă textul este corect — asta necesită un om care să citească pagina în context.

Contrast de culoare insuficient

Pe cine afectează: persoanele cu vedere slabă, daltonism sau pierdere a vederii legată de vârstă; oricine folosește un ecran în lumina puternică a soarelui.

Criteriu WCAG: 1.4.3 Contrast (minim), Nivel AA; plus 1.4.11 Contrast non-text pentru componente UI.

WCAG 2.2 necesită un raport de contrast de cel puțin 4.5:1 pentru text normal și 3:1 pentru text mare (aproximativ 18pt sau 14pt aldin). Componentele de interfață și graficele semnificative — marginile câmpurilor, indicatorii de focalizare, pictogramele care transmit o stare — trebuie să atingă 3:1 față de mediul lor. Eșecurile de contrast se numără printre cele mai frecvente probleme găsite în fiecare audit la scară largă și sunt aproape întotdeauna introduse în etapa de proiectare.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testează întreaga paletă, nu doar textul de bază: textul substituent (placeholder), stările dezactivate care trebuie totuși citite, mesajele de eroare și textul așezat peste fotografii sunt deseori vinovate. Nu te baza niciodată doar pe culoare pentru a transmite o semnificație (1.4.1) — o margine roșie pe un câmp invalid trebuie însoțită de text sau o pictogramă.

Conținut media și mișcare care pornesc automat

Pe cine afectează: persoanele cu tulburări vestibulare, cu dizabilități de atenție sau cognitive, utilizatorii de cititoare de ecran a căror ieșire audio este acoperită și oricine se află într-un spațiu comun liniștit.

Criterii WCAG: 1.4.2 Control audio (Nivel A), 2.2.2 Pauză, oprire, ascundere (Nivel A), 2.3.1 Trei licăriri (Nivel A) și 2.3.3 Animație din interacțiuni (Nivel AAA).

Conținutul audio sau video care pornește automat timp de peste trei secunde trebuie să ofere o modalitate evidentă de a-l pune pe pauză sau de a-l dezactiva. Conținutul în mișcare, care clipește sau se actualizează automat și care durează mai mult de cinci secunde — carusele, bannere animate, marquee-uri — are nevoie de un control de pauză accesibil. Conținutul care clipește de mai mult de trei ori pe secundă poate declanșa crize și trebuie evitat complet. Respectă setarea prefers-reduced-motion a utilizatorului pentru a atenua animația neesențială.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Operabil: lucruri pe care oamenii nu le pot folosi

Inaccesibilitate de la tastatură și capcane de tastatură

Pe cine afectează: persoanele cu dizabilități motorii care nu pot folosi un mouse, utilizatorii de cititoare de ecran (care navighează cu tastatura) și persoanele care folosesc dispozitive cu comutator sau control vocal.

Criterii WCAG: 2.1.1 Tastatură (Nivel A) și 2.1.2 Fără capcană de tastatură (Nivel A).

Fiecare interacțiune — linkuri, butoane, câmpuri de formular, meniuri, modale, selectoare de dată, glisare și fixare — trebuie să fie complet operabilă numai de la tastatură. Cea mai dăunătoare variantă este capcana de tastatură: focalizarea intră într-o componentă (deseori un modal sau un widget încorporat) și nu mai poate ieși, lăsând utilizatorul blocat pe pagină. Widgeturile create personalizat sunt de obicei vinovate, deoarece elementele native precum <button> și <a> sunt operabile de la tastatură în mod implicit, în timp ce imitațiile bazate pe <div> nu sunt.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Parcurge traseele tale cheie folosind doar Tab, Shift+Tab, tastele săgeți, Enter, Space și Escape. Confirmă că focalizarea poate întotdeauna avansa și ieși din fiecare componentă, că Escape închide suprapunerile și că nimic nu necesită un dispozitiv de indicare. Serviciul nostru de evaluare cu cititor de ecran testează exact aceste fluxuri așa cum le experimentează utilizatorii reali de tehnologie asistivă.

Indicatori de focalizare lipsă sau invizibili și ordine de focalizare ilogică

Pe cine afectează: utilizatorii de tastatură cu vedere, utilizatorii cu vedere slabă și oricine a pierdut din vedere unde se află pe pagină.

Criterii WCAG: 2.4.7 Focalizare vizibilă (Nivel A) și 2.4.3 Ordinea focalizării (Nivel A); 2.4.11 Focalizare neacoperită (Nivel AA) în WCAG 2.2.

O greșeală „ordonată” frecventă este eliminarea inelului de focalizare implicit al browserului cu outline: none și nereînlocuirea lui niciodată. Utilizatorii de tastatură rămân fără să știe ce element este activ. La fel de dăunătoare este o ordine de focalizare care nu urmează ordinea de citire vizuală și logică — cauzată de obicei de valori tabindex pozitive sau de o ordine DOM care diferă de aspectul randat.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 adaugă 2.4.11: când un element primește focalizarea, nu trebuie să fie complet ascuns în spatele antetelor fixe, al bannerelor de cookie-uri sau al widgeturilor de chat. Deschide un modal, parcurge-l cu Tab și confirmă că elementul focalizat nu este niciodată îngropat.

Linkuri și butoane nedescriptive

Pe cine afectează: utilizatorii de cititoare de ecran care afișează o listă cu toate linkurile pentru a scana o pagină și persoanele cu dizabilități cognitive.

Criterii WCAG: 2.4.4 Scopul linkului (în context), Nivel A; 2.5.3 Etichetă în nume, Nivel A.

Utilizatorii de cititoare de ecran navighează deseori sărind între linkuri în afara contextului. O pagină plină de linkuri „faceți clic aici”, „citiți mai mult” și „aflați mai multe” devine lipsită de sens când este citită ca o listă. Textul linkului trebuie să descrie destinația de unul singur. Același lucru este valabil pentru butoanele cu pictogramă, care au nevoie de un nume accesibil.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Navigare supraîncărcată și fără posibilitatea de a o omite

Pe cine afectează: utilizatorii de cititoare de ecran, utilizatorii de tastatură și persoanele cu dizabilități cognitive.

Criteriu WCAG: 2.4.1 Ocolirea blocurilor (Nivel A).

Un mega-meniu cu zeci de linkuri îi obligă pe utilizatorii de cititoare de ecran și de tastatură să parcurgă întreaga listă pe fiecare pagină înainte de a ajunge la conținut. Un link „Salt la conținutul principal” ca prim element focalizabil le permite să sară direct peste blocurile repetate. Grupează elementele asociate, păstrează meniurile suple și asigură-te că linkul de salt devine vizibil la focalizare.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

De înțeles: conținut care derutează

Câmpuri de formular fără etichetă sau asociate incorect

Pe cine afectează: utilizatorii de cititoare de ecran, persoanele cu dizabilități cognitive și utilizatorii de control vocal care se adresează câmpurilor după nume.

Criterii WCAG: 1.3.1 Informații și relații, 3.3.2 Etichete sau instrucțiuni și 4.1.2 Nume, rol, valoare (toate Nivel A).

Câmpurile de intrare fără o <label> asociată programatic sunt anunțate ca „editare text, gol” — utilizatorul nu are nicio idee ce să tasteze. Textul substituent (placeholder) nu este un înlocuitor: dispare la introducere și de obicei nu trece testul de contrast. Câmpurile obligatorii, regulile de formatare și erorile de validare trebuie, de asemenea, transmise prin text, nu doar prin culoare sau poziție.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Leagă mesajele de eroare de câmpul lor cu aria-describedby, marchează câmpurile invalide cu aria-invalid și asigură-te că trimiterea unui formular incomplet mută focalizarea pe prima eroare.

Limba paginii lipsă

Pe cine afectează: utilizatorii de cititoare de ecran — limba greșită face ca sintetizatorul să pronunțe totul greșit.

Criterii WCAG: 3.1.1 Limba paginii (Nivel A) și 3.1.2 Limba părților (Nivel AA).

Un singur atribut lipsă strică pronunția pentru o pagină întreagă. Declară limba principală pe elementul rădăcină și marchează pasajele inline într-o altă limbă cu propriul lor lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Ierarhie de titluri incorectă și repere lipsă

Pe cine afectează: utilizatorii de cititoare de ecran care navighează după titluri și regiuni și oricine se bazează pe structura documentului.

Criteriu WCAG: 1.3.1 Informații și relații (Nivel A).

Titlurile reprezintă schema paginii. Utilizatorii de cititoare de ecran sar de la titlu la titlu pentru a găsi rapid conținutul; când nivelurile sunt sărite, folosite pur și simplu pentru dimensiunea fontului sau lipsesc, această navigare se prăbușește. Fiecare pagină trebuie să aibă un singur <h1> și o secvență logică, neîntreruptă de <h2>, <h3> și așa mai departe. La fel de importante sunt regiunile reper — <header>, <nav>, <main>, <footer> — care le permit utilizatorilor să sară între zonele principale. O pagină construită în întregime din elemente <div> nu oferă o astfel de hartă.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robust: cod pe care tehnologia asistivă nu îl poate interpreta

Widgeturi personalizate inaccesibile și utilizare greșită a ARIA

Pe cine afectează: mai presus de toate utilizatorii de cititoare de ecran și orice tehnologie asistivă care se bazează pe un arbore de accesibilitate corect.

Criteriu WCAG: 4.1.2 Nume, rol, valoare (Nivel A).

Meniurile derulante, filele, acordeoanele, casetele combinate, modalele și sfaturile contextuale personalizate construite din <div> și <span> nu au niciun rol, stare sau comportament de tastatură inerent. Dezvoltatorii apelează la ARIA pentru a peteci acest lucru, dar ARIA doar descrie — nu adaugă comportament, iar un ARIA incorect este mai rău decât niciunul. Prima regulă a ARIA este să preferi un element HTML nativ ori de câte ori există unul. Când trebuie să construiești un widget personalizat, implementează interacțiunea completă de tastatură pe care o specifică modelele de creare ARIA și menține aria-expanded, aria-selected și stările similare sincronizate cu realitatea.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Acestea sunt exact problemele pe care scanerele automate le ratează cel mai des. Un scaner vede un atribut aria-expanded și îl trece; doar un om (sau un tester care folosește un cititor de ecran) poate confirma că valoarea chiar se schimbă când se deschide meniul. Consultă ghidul nostru de testare cu cititor de ecran pentru a vedea cum să verifici comportamentul unui widget de la cap la coadă.

O notă despre widgeturile de suprapunere (overlay)

Este tentant să instalezi un „widget de accesibilitate” sau o suprapunere de o singură linie care promite conformitate instantanee. Aceste instrumente nu remediază problemele de mai sus — textul alternativ încă lipsește în sursă, contrastul încă eșuează, widgetul personalizat încă nu funcționează. Suprapunerile nu pot remedia codul care provoacă barierele, deseori interferează cu propria tehnologie asistivă a utilizatorilor și au figurat într-un număr tot mai mare de procese privind accesibilitatea. Accesibilitatea digitală reală provine din remedierea HTML-ului, CSS-ului și a comportamentului subiacente, nu din mascarea lor.

Oprește revenirea acestor probleme

Remedierea unei liste de erori o singură dată este necesară, dar nu suficientă; aceleași probleme reapar la următoarea lansare, dacă nu schimbi modul în care lansezi lucrurile. Soluția durabilă este să integrezi accesibilitatea în fluxul de lucru:

Prinde devreme cele 30–40% automatizabile integrând scanările în pipeline-ul tău. Integrarea accesibilității CI/CD face ca build-ul să eșueze când este introdusă o regresie, înainte ca aceasta să ajungă în producție.
Acoperă restul cu oameni. Programează auditurile manuale de accesibilitate și auditurile efectuate de persoane cu dizabilități, care scot la iveală bariere pe care niciun instrument nu le poate detecta.
Oferă echipelor instrumentele potrivite. Setul de instrumente de accesibilitate QualiBooth și Agora îi ajută pe designeri și dezvoltatori să testeze în timp ce lucrează.
Transformă-l într-un proces, nu într-un proiect. Consultanța de accesibilitate continuă și îmbunătățirea procesului de accesibilitate înrădăcinează obiceiurile, astfel încât calitatea să se mențină în timp.

Pentru o foaie de parcurs de remediere pas cu pas, începe cu ghidul nostru despre cum să-ți faci site-ul conform cu WCAG.

De unde să începi astăzi

Cu peste 1,3 miliarde de oameni din întreaga lume care trăiesc cu o formă de dizabilitate, argumentul de afaceri pentru accesibilitate este clar — iar din iunie 2025, este la fel și argumentul legal în temeiul Actului European privind Accesibilitatea. Problemele din acest catalog sunt cele examinate primele în orice plângere sau audit.

Cea mai rapidă modalitate de a vedea unde te afli este să rulezi o scanare URL gratuită — fără configurare, fără obligație. Când ești gata să mergi dincolo de ceea ce poate atinge automatizarea, solicită o demonstrație și îți vom arăta cum un program combinat, automat plus manual, închide diferența rămasă.