# Listă de verificare WCAG 2.2 AA pentru produse SaaS și aplicații web

<https://www.fixreports.com/ro/blog/wcag-2-2-checklist-saas-web-apps>

Actualizat la 2026-10-26

Un produs SaaS are două suprafețe de accesibilitate: site-ul de marketing care îl vinde și aplicația pe care oamenii o folosesc zilnic. Site-ul de marketing are aceleași erori ca orice site, cu contrast scăzut, text alternativ lipsă și formulare fără etichete. Aplicația adaugă propriile probleme: fluxuri de autentificare care blochează managerii de parole, dialoguri care captează focusul tastaturii, navigare single-page pe care cititoarele de ecran nu o observă, tabele de date și grafice fără text, drag and drop fără alternativă și sesiuni care expiră fără avertisment. Această listă de verificare parcurge nivelul AA din WCAG 2.2 pe părțile unui produs SaaS obișnuit.

**Puncte-cheie**

- WCAG 2.2 a devenit Recomandare W3C în octombrie 2023 și a adăugat nouă criterii de succes, dintre care șase de nivel A sau AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) înseamnă că o autentificare nu poate depinde de memorarea sau transcrierea unei parole, cu excepția cazului în care oamenii o pot lipi sau pot folosi un manager de parole ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Țintele interactive trebuie să aibă cel puțin 24 pe 24 de pixeli CSS sau suficient spațiu în jur (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Mesajele precum „Salvat” sau „3 rezultate” trebuie să ajungă la cititoarele de ecran fără să mute focusul (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Cumpărătorii din mediul de afaceri și din sectorul public cer adesea un Accessibility Conformance Report (ACR), redactat de obicei pe șablonul VPAT al Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## De ce contează accesibilitatea mai mult pentru un SaaS decât pentru un site de prezentare?

Oamenii folosesc un produs SaaS ore în șir, adesea pentru că angajatorul lor l-a ales. O barieră pe o pagină de marketing pierde un vizitator; o barieră în produs poate împiedica pe cineva să-și facă treaba. De aceea clienții mai mari, universitățile și instituțiile publice întreabă tot mai des despre accesibilitate înainte să cumpere și de aceea răspunsul trebuie să acopere aplicația, nu doar site-ul.

Contează și pentru că testele automate prind doar o parte din problemă. Instrumente precum axe-core găsesc erori în markup, cum ar fi etichete lipsă și contrast scăzut. Ele nu pot spune dacă un dialog readuce focusul în locul potrivit, dacă datele unui grafic sunt disponibile ca text sau dacă un flux de lucru poate fi parcurs cu tastatura. O aplicație are nevoie atât de verificări automate, cât și de testare manuală.

## Cum faceți accesibile înregistrarea și autentificarea?

Autentificarea este zona în care WCAG 2.2 a adăugat cea mai importantă cerință nouă pentru SaaS.

- **Permiteți lipirea și managerii de parole (3.3.8, AA).** Nu blocați lipirea în câmpurile de parolă sau de cod și folosiți `autocomplete="username"`, `autocomplete="current-password"` și `autocomplete="one-time-code"`, astfel încât browserele și managerii de parole să le poată completa.
- **Evitați puzzle-urile ca singură cale de acces.** Un CAPTCHA care cere transcrierea unui text distorsionat sau rezolvarea unui puzzle este un test al funcțiilor cognitive. Oferiți o alternativă și preferați verificări care nu necesită o acțiune din partea utilizatorului ([W3C](https://www.w3.org/TR/turingtest/)).
- **Etichetați fiecare câmp (1.3.1 și 3.3.2, A).** Folosiți un `<label>` vizibil, conectat la câmpul său; textul substituent dispare când cineva tastează și nu este o etichetă.
- **Identificați erorile prin text (3.3.1, A) și sugerați remedieri (3.3.3, AA).** „Parola trebuie să aibă cel puțin 12 caractere” ajută; o bordură roșie singură nu ajută.
- **Nu cereți de două ori (3.3.7, A).** Dacă o înregistrare în mai mulți pași a cerut deja numele companiei sau o adresă, completați-le automat sau permiteți selectarea lor în loc de retastare.
- **Păstrați ajutorul în același loc (3.2.6, A).** Dacă oferiți chat, un link de ajutor sau date de contact, puneți-le în aceeași poziție relativă pe fiecare pagină a fluxului.

## Ce modele de formulare și de erori provoacă cele mai multe probleme?

Formularele sunt locul unde se află majoritatea erorilor din aplicații. Analiza WebAIM din 2026 a unui milion de pagini principale a găsit etichete de formular lipsă pe 51% dintre ele ([WebAIM](https://webaim.org/projects/million/)), iar aplicațiile au mult mai multe formulare decât paginile principale.

- Dați fiecărui câmp un nume programatic și grupați controalele înrudite, cum ar fi butoanele radio, cu `<fieldset>` și `<legend>`.
- Anunțați erorile acolo unde oamenii le vor observa: mutați focusul pe un rezumat al erorilor din partea de sus a formularului sau pe primul câmp nevalid și legați fiecare element al rezumatului de câmpul său.
- Marcați câmpurile obligatorii prin text, nu doar prin culoare (1.4.1, A).
- Nu trimiteți formularul și nu schimbați contextul când cineva doar selectează o opțiune (3.2.2, A); așteptați o acțiune explicită.

## Cum trebuie să se comporte dialogurile, meniurile și popoverele?

Componentele personalizate sunt locul unde suportul pentru tastatură și cititoare de ecran se strică cel mai des. Ghidul ARIA Authoring Practices al W3C descrie comportamentul așteptat pentru fiecare model ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialoguri**: mutați focusul în dialog când se deschide, păstrați tasta Tab în interiorul lui cât timp este deschis, închideți-l cu Escape și readuceți focusul pe controlul care l-a deschis. Folosiți elementul nativ `<dialog>` sau `role="dialog"` cu `aria-modal="true"` și un nume.
- **Nicio capcană pentru tastatură (2.1.2, A)**: orice componentă trebuie să poată fi părăsită cu tastatura.
- **Focus vizibil (2.4.7, AA)**, care să nu fie ascuns în spatele anteturilor fixe, al bannerelor de cookie-uri sau al widgeturilor de chat (2.4.11, AA, nou în 2.2).
- **Tooltipuri și popovere (1.4.13, AA)** pe care oamenii le pot închide cu Escape, peste care pot trece cu cursorul fără să dispară și care rămân afișate până sunt închise.
- **Comenzi rapide dintr-o singură tastă (2.1.4, A)**: dacă apăsarea unei taste cu literă declanșează o acțiune, permiteți dezactivarea sau reatribuirea comenzilor rapide ori activați-le doar când componenta respectivă are focusul.

## Cum gestionați navigarea într-o aplicație single-page?

Într-o aplicație single-page, URL-ul se schimbă fără încărcarea unei pagini, așa că cititoarele de ecran s-ar putea să nu anunțe că s-a întâmplat ceva.

- Actualizați titlul documentului la fiecare schimbare de rută, astfel încât fiecare vizualizare să aibă un titlu descriptiv (2.4.2, A).
- Mutați focusul pe titlul principal al noii vizualizări sau anunțați schimbarea într-o regiune live de tip polite; frameworkuri precum Next.js includ în acest scop un route announcer.
- Păstrați o ordine logică a focusului (2.4.3, A): după ștergerea unui element, focusul trebuie să ajungă la un element vecin potrivit, nu înapoi în partea de sus a paginii.
- Oferiți o modalitate de a sări peste navigarea repetată (2.4.1, A), cum ar fi un skip link sau repere (landmarks).

## Cum faceți accesibile dashboardurile, tabelele de date și graficele?

- **Tabele**: folosiți un markup `<table>` real, cu `<th>` și `scope` pentru antete, și o legendă (1.3.1, A). Grilele construite din elemente `<div>` au nevoie de modelul complet de grilă ARIA, mult mai greu de realizat corect.
- **Grafice**: dați fiecărui grafic un text alternativ care spune ideea principală și oferiți datele într-un tabel (1.1.1, A). Nu vă bazați doar pe culoare pentru a deosebi seriile (1.4.1, A); adăugați etichete sau modele.
- **Contrast**: textul are nevoie de 4.5:1 (1.4.3, AA), iar liniile graficelor, pictogramele și bordurile câmpurilor au nevoie de 3:1 față de fundal (1.4.11, AA). Verificați separat modul întunecat. [Verificarea contrastului culorilor](/ro/color-contrast-checker) testează orice pereche de culori.
- **Mesaje de stare (4.1.3, AA)**: „Salvat”, „Încărcare finalizată” și numărul de rezultate trebuie să folosească `role="status"` sau o regiune live, astfel încât cititoarele de ecran să le audă fără să piardă poziția.

## Ce schimbă noile criterii WCAG 2.2 pentru aplicațiile web?

| Criteriu | Nivel | Ce înseamnă într-o aplicație |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Barele de instrumente fixe, bannerele și widgeturile de chat nu trebuie să acopere complet elementul focalizat |
| 2.5.7 Dragging Movements | AA | Orice acțiune făcută prin glisare, cum ar fi reordonarea unui panou kanban, are nevoie de o alternativă cu un singur indicator, de exemplu un meniu sau butoane sus și jos |
| 2.5.8 Target Size (Minimum) | AA | Butoane și linkuri de cel puțin 24 × 24 pixeli CSS sau distanțate astfel încât un cerc de 24 de pixeli în jurul fiecăruia să nu se suprapună cu altul |
| 3.2.6 Consistent Help | A | Linkurile de ajutor, chatul și datele de contact în aceeași poziție relativă pe fiecare pagină |
| 3.3.7 Redundant Entry | A | Informațiile introduse deja în același proces sunt completate automat sau pot fi selectate |
| 3.3.8 Accessible Authentication (Minimum) | AA | Autentificare fără memorare sau transcriere, cu excepția cazului în care sunt permise lipirea, managerii de parole sau o altă metodă |

WCAG 2.2 a eliminat și criteriul 4.1.1 Parsing, care nu mai are un efect practic asupra accesibilității ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Ce trebuie știut despre expirări, aspect și zoom?

- **Expirarea sesiunii (2.2.1, A)**: avertizați oamenii înainte să le expire sesiunea și permiteți-le să o prelungească printr-o acțiune simplă, cu excepția cazului în care limita de timp este esențială sau mai lungă de 20 de ore. Salvarea lucrului în curs evită cel mai rău deznodământ.
- **Reflow (1.4.10, AA)**: conținutul trebuie să funcționeze la 320 de pixeli CSS lățime (echivalentul unui zoom de 400% pe un ecran de 1280 de pixeli) fără derulare în două direcții; tabelele de date și conținutul similar sunt exceptate.
- **Spațierea textului (1.4.12, AA)**: mărirea înălțimii rândului și a spațierii literelor nu trebuie să taie textul, lucru pe care containerele cu înălțime fixă îl fac adesea.
- **Orientarea (1.3.4, AA)**: nu blocați aplicația în modul portret sau peisaj decât dacă este esențial.

## Ce este un ACR și aveți nevoie de unul?

Un Accessibility Conformance Report (ACR) documentează modul în care un produs îndeplinește fiecare criteriu de accesibilitate: acceptat, parțial acceptat sau neacceptat, cu observații. Majoritatea sunt redactate pe șablonul VPAT publicat de Information Technology Industry Council, care are ediții pentru WCAG, pentru standardele americane Section 508 și pentru standardul european EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Agențiile federale din SUA trebuie să cumpere tehnologie accesibilă în baza Section 508 ([Section508.gov](https://www.section508.gov/)), iar instituțiile publice din UE se raportează la EN 301 549, așa că produselor B2B vândute acestor clienți li se cere adesea un ACR în procesul de achiziție. Un ACR onest, cu lacunele cunoscute listate, este mai util cumpărătorilor decât unul care pretinde suport complet. El trebuie să se bazeze pe testarea produsului, inclusiv testare manuală; o scanare automată singură nu îl poate completa.

Dacă vindeți consumatorilor din UE, Actul european privind accesibilitatea se poate aplica și modului în care vindeți online; [ghidul nostru despre EAA](/ro/blog/european-accessibility-act-online-stores) explică domeniul său de aplicare. Aceasta nu este consultanță juridică.

## Cum ar trebui să testeze accesibilitatea o echipă SaaS?

1. **Automatizați elementele de bază.** Rulați axe-core sau un motor similar în testele end-to-end și pe site-ul de marketing și faceți ca buildurile să eșueze la încălcări noi. [Verificarea gratuită a accesibilității](/ro/website-accessibility-checker) rulează același motor pe orice pagină publică.
2. **Testați cu tastatura.** Parcurgeți fluxurile principale, cum ar fi înregistrarea, crearea unei înregistrări și modificarea setărilor, folosind doar Tab, Shift+Tab, Enter, Spațiu, Escape și tastele săgeți.
3. **Testați cu un cititor de ecran.** NVDA pe Windows și VoiceOver pe macOS și iOS sunt gratuite. Verificați că sunt anunțate numele, rolurile, stările și mesajele.
4. **Măriți și redimensionați.** Verificați zoomul textului la 200% și o fereastră lată de 320 de pixeli.
5. **Remediați în design system.** Majoritatea erorilor provin din componente comune; remedierea unui buton sau a unui dialog o singură dată îl remediază peste tot.

## Întrebări frecvente

### Se aplică WCAG părților unei aplicații web accesibile după autentificare?

WCAG se aplică oricărui conținut web, inclusiv paginilor protejate prin autentificare. Dacă o lege impune unui anumit produs să respecte WCAG depinde de jurisdicție și de client, dar cumpărătorii care întreabă despre accesibilitate se referă de obicei la întregul produs.

### Poate un overlay să facă accesibil un produs SaaS?

Nu. Overlay-urile nu modifică codul de bază al componentelor personalizate, iar acolo se află erorile aplicațiilor. Ghidul nostru despre [overlay-urile de accesibilitate](/ro/blog/accessibility-overlays-ftc-order) prezintă acțiunea FTC împotriva unui furnizor important de overlay-uri.

### Cât din WCAG pot verifica instrumentele automate?

Doar o parte. Regulile automate găsesc în mod fiabil nume și etichete lipsă și erori de contrast, dar multe criterii, cum ar fi o ordine a focusului cu sens, un text alternativ util și mesaje de eroare ușor de înțeles, au nevoie de judecata unei persoane.

### Ce versiune WCAG ar trebui să urmărim?

WCAG 2.2 nivelul AA este versiunea actuală. Multe legi și reguli de achiziție fac încă trimitere la WCAG 2.1 AA; respectarea WCAG 2.2 AA înseamnă și respectarea WCAG 2.1 AA, cu excepția criteriului Parsing, care a fost eliminat.

### Trebuie să atingem nivelul AAA?

W3C nu recomandă impunerea nivelului AAA pentru produse întregi, deoarece unele conținuturi nu pot îndeplini toate criteriile AAA. Nivelul AA este ținta obișnuită.

## Surse

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)