Ce face obiectul plângerilor: un ghid practic al modelelor de interfață utilizate în cele 6.666 de plângeri privind accesibilitatea

Antetul este prima zonă interactivă de pe fiecare pagină, iar butonul de tip „hamburger” este adesea primul element la care ajunge un utilizator care navighează cu ajutorul tastaturii. Atunci când acest buton este afișat ca un <div> dacă un element are o imagine de fundal CSS, nu are un nume accesibil sau deschide un meniu care blochează focalizarea sau nu indică starea sa de deschidere/închidere, întregul site devine practic inaccesibil de la tastatură înainte ca utilizatorul să fi interacționat cu vreun conținut propriu-zis.

Linkul de salt este defect. Unul funcțional "Skip to main content" Link-ul de salt este o soluție care se rezolvă în cinci pași, dar este și cel mai eficient indicator pentru a stabili dacă o echipă de dezvoltare a inclus deloc accesibilitatea pe lista sa de verificare. Reclamațiile menționează adesea ambele aspecte în același paragraf, deoarece un link de salt lipsă sau defect este un semnal de alarmă — dacă echipa nu a implementat un link de salt, este aproape sigur că nu a implementat nici stările „aria-expanded”.

Afișează elementul de meniu ca element real <button> cu o etichetă text vizibilă sau accesibilă doar prin cititorul de ecran și un element gestionat aria-expanded atribut. Introduceți un "Skip to main content" link care devine vizibil la selectare și se afișează în interiorul <main> punct de referință. Asigură-te că focalizarea se mută pe meniu la deschiderea acestuia, revine la elementul declanșator la închiderea acestuia și că Esc închide meniul.

Funcția de căutare este implementată ca o componentă personalizată pe majoritatea site-urilor mari — un câmp de introducere a textului cu debounce care trimite o solicitare la fiecare apăsare de tastă și afișează o listă flotantă de sugestii într-un element poziționat absolut <div>. Câmpul de introducere a textului în sine funcționează de obicei bine. Lista de sugestii, însă, aproape niciodată. Aceasta este afișată în afara contextului DOM al câmpului de introducere, nu are role="listbox", nu aria-activedescendantși nu apare nicio notificare în zona activă atunci când se afișează rezultatele. Un utilizator de cititor de ecran tastează, nu aude nimic, apasă Enter și primește o pagină cu rezultate despre care nu știa că îl așteaptă.

Același model arhitectural se regăsește atât în panourile de filtrare ale căutării pe facete, cât și în lista de rezultate propriu-zisă: elemente pe care se poate plasa focalizarea tastaturii, care sunt vizibile, dar nu sunt niciodată anunțate vocal. Plângerile legate de căutare se referă rareori la caseta de căutare; ele vizează tot ceea ce apare după ce utilizatorul tastează.

Folosiți modelul standard WAI-ARIA pentru casetele combinate: role="combobox" la intrare cu aria-expanded, aria-controlsși aria-activedescendant conectat la un role="listbox" de sugestii. Adăugați o zonă dinamică care să afișeze numărul de rezultate. Asigurați-vă că lista de sugestii poate fi accesată cu tasta săgeată în jos, nu doar cu mouse-ul.

Grila PLP concentrează mai multe anti-modele într-un singur ecran. Fiecare casetă este, de obicei, o carte pe care se poate da clic, conținând trei sau patru elemente interactive secundare — link către imagine, link către titlu, mostre de culori, buton de adăugare rapidă — încadrate într-un alt link către pagina produsului. Rezultatul constă în elemente interactive imbricate (o eroare HTML), text de link redundant („Hero Dash Three Graphic Image Link” repetat de patru ori) și mostre de culori create din <div> elemente care au proceduri de gestionare a clicurilor, dar nu au niciun rol și niciun nume.

Bara laterală de filtrare introduce o a doua categorie de erori. Facetele de filtrare sunt de obicei liste de casete de selectare, dar sunt construite folosind elemente div și span personalizate, stilizate astfel încât să arate ca niște casete de selectare, cu elementul propriu-zis <input> ascuns în afara ecranului. Când acel element de introducere ascuns își pierde asocierea — fie printr-o regulă CSS, fie printr-un handler de evenimente JavaScript care ignoră apăsările tastei spațiu, fie din cauza lipsei for atributul de pe eticheta vizibilă — filtrul poate fi acționat doar cu mouse-ul.

Folosiți o singură ancoră pe fiecare imagine, însoțită de un text descriptiv, nu trei linkuri pentru fiecare produs. Prezentați mostrele cât mai realist posibil <button> elementele din interiorul unui role="radiogroup". Creați filtre pe baza datelor reale <input type="checkbox"> elemente asociate <label> etichete; stilizează câmpurile de introducere astfel încât să fie vizibile, în loc să le ascunzi. Anunță modificările filtrului printr-o zonă de vizualizare în timp real.

Pagina cu detalii despre produs este locul în care un utilizator de cititor de ecran trebuie să efectueze mai multe alegeri specifice, în ordinea corectă: să aleagă o culoare, să aleagă o mărime, să stabilească cantitatea, apoi să adauge produsul în coș. Fiecare dintre aceste alegeri este implementată în comerțul electronic modern sub forma unui widget personalizat — de obicei, un rând orizontal de <button>în formă de <div>În ceea ce privește dimensiunile, plăcile colorate sunt construite din elemente div stilizate cu CSS, iar butonul de selectare numerică este format din două butoane cu pictograme care flanchează un câmp de introducere. Butoanele de creștere și de scădere sunt livrate de obicei fără un nume accesibil; reclamațiile le descriu ca fiind anunțat sub numele de „button, button” fără nicio indicație cu privire la activitatea lor.

Ghidurile și tabelele de mărimi reprezintă o problemă separată: acestea se găsesc aproape întotdeauna în spatele unui link intitulat „Tabel de mărimi” care deschide o fereastră modală, iar linkul în sine nu are adesea nicio etichetă, fereastra modală nu are adesea un titlu afișat, iar tabelul din interior nu are adesea anteturi pentru rânduri sau coloane.

Folosiți elemente de control reale. Mostrele de culoare și selectorii de dimensiuni ar trebui să fie role="radiogroup" din role="radio" butoane (sau casete de selectare stilizate astfel încât să nu fie vizibile), fiecare având un nume accesibil, de exemplu „Dimensiune: Medie”. Cursorul pentru cantitate trebuie să fie o casetă de introducere a unui număr etichetată, însoțită de butoane de creștere/scădere, ale căror nume accesibile să includă acțiunea și cantitatea curentă. Încadrați întregul bloc selectat într-un element fieldset cu o legendă.

Funcția „Adaugă în coș” este cel mai testat moment din orice proces de cumpărare online și unul dintre cele mai frecvent defecte pentru utilizatorii de tehnologii de asistență. Schema este simplă: un vizitator apasă butonul, apare o fereastră mică de confirmare sau un meniu derulant pentru coș timp de două sau trei secunde, iar pictograma coșului actualizează numărul de articole din antet. Utilizatorii văzători văd toate cele trei semnale. Utilizatorii de cititoare de ecran nu primesc, de obicei, niciunul. Fereastra de confirmare se afișează în afara oricărei regiuni active, fereastra glisantă apare fără gestionarea focalizării, iar modificarea numărului din coș este livrată ca o simplă mutație DOM pe care niciun cititor de ecran nu o va anunța.

Rezultatul este un buton care, din perspectiva utilizatorului, nu face nimic. Apasă pe el, nu se aude nimic, presupun că nu a funcționat și apasă din nou. Unele reclamații menționează că utilizatorii au apăsat butonul de cinci sau șase ori înainte să-și dea seama că în coș s-au adăugat în tăcere cinci sau șase articole.

Încadrează zona de stare a coșului între aria-live="polite" și actualizează textul acestuia la fiecare adăugare reușită. Dacă designul utilizează un meniu de confirmare, mută focalizarea pe meniu atunci când acesta se deschide și readuce focalizarea pe butonul inițial atunci când se închide. Actualizează insigna cu numărul de articole din coș cu un anunț destinat exclusiv cititoarelor de ecran, de genul „1 articol adăugat. Total coș: 3 articole.”

Elementele de control care conțin doar pictograme prezintă erori previzibile: conținutul vizibil este un fișier SVG sau un simbol din fontul de pictograme, conținutul accesibil este gol, iar cititorul de ecran redă doar rolul structural al elementului, fără a menționa un nume. Pictograma coșului de cumpărături este anunțată ca „link” sau „colapsat”; balonul de chat ca „buton”; rândul de pictograme sociale din subsol ca „link, link, link, link, link”. Utilizatorul nu are cum să știe ce face fiecare dintre ele.

Pictogramele coșului de cumpărături prezintă erori mai des decât alte pictograme dintr-un motiv de natură arhitecturală: în multe implementări, numărul de articole din coș este afișat în numele accesibil al pictogramei (de exemplu, pictograma afișează „0” în interiorul fișierului SVG), iar cititorul de ecran preia doar cifra. Reclamațiile menționează că pictograma coșului de cumpărături este anunțată ca „3, link” sau „0, link”, fără nicio indicație că „3” se referă la numărul de articole din coșul de cumpărături.

Fiecare element de control care conține doar pictograme trebuie să aibă un nume accesibil. Adăugați un aria-label pe buton sau încadrați în acesta o etichetă de text ascunsă vizual: "Shopping cart, 3 items". Evitați să includeți cifre de numărare în numele accesibil al pictogramei fără un context. Pentru pictogramele decorative care apar alături de text vizibil, utilizați aria-hidden="true" pe pictogramă și lăsați textul să servească drept etichetă.

Procesul de finalizare a comenzii prezintă un risc de neconformitate mai mare pe pixel pătrat decât orice altă pagină a unui site de comerț electronic, iar tiparele de eroare sunt frecvente. Listele derulante cu adrese afișate ca elemente personalizate <div> componente care ignoră tasta spațiu. Marcajele câmpurilor obligatorii sunt afișate doar sub forma unui asterisc roșu, fără aria-required și fără nicio asociere programatică. Mesajele de eroare afișate în text roșu sub câmp, fără aria-describedby câmpul nu este asociat cu eroarea și nu se afișează nicio notificare în zona activă atunci când validarea eșuează. Utilizatorul completează formularul, apasă pe „Continuă”, este redirecționat în tăcere și nu are cum să afle care câmpuri au generat erori sau de ce.

Aceleași nemulțumiri se regăsesc în sute de cazuri: mesajele de eroare nu sunt anunțate, mesajele de eroare sunt vagi, nu se pot introduce datele de facturare. Acestea nu sunt erori izolate. Ele reprezintă comportamentul implicit al majorității componentelor de finalizare a comenzii din magazinele online, livrate fără a fi fost luate măsuri explicite de accesibilitate.

Folosiți date reale <label> elemente asociate intrărilor prin for/id. Marcați câmpurile obligatorii cu aria-required="true" și indicați cerința prin text vizibil, nu doar prin culoare. În cazul unei validări eșuate, afișați mesajul de eroare în interiorul câmpului de introducere aria-describedby țintă, indică câmpul cu erori aria-invalid="true"și mutați focalizarea tastaturii pe primul câmp cu date incorecte. Afișați o zonă de rezumat a erorilor în partea de sus a formularului, cu linkuri către fiecare câmp cu date incorecte.

Blocul de plată este neobișnuit, deoarece este adesea afișat printr-un iframe încorporat al unei terțe părți — Stripe Elements, Braintree Hosted Fields sau un modul Adyen. În interiorul iframe-ului, formularul propriu al furnizorului de servicii de plată este de obicei etichetat corespunzător. Dar în momentul în care un site își creează propriul formular de captură a datelor cardului sau încorporează câmpurile într-un layout personalizat care înlocuiește etichetele cu marcaje vizuale, cele patru câmpuri — număr, data expirării, CVV, cod poștal — devin un rând de câmpuri goale pentru un cititor de ecran.

Câmpul CVV este cel mai des etichetat greșit, deoarece dezvoltatorii înlocuiesc de obicei eticheta acestuia cu o pictogramă sub formă de semn de întrebare care deschide o fereastră de informații explicând ce este un CVV. Fereastra de informații nu constituie eticheta; câmpul are în continuare nevoie de un nume programatic. Atunci când nu are unul, cititorul de ecran anunță întregul bloc de plată ca fiind „editare, editare, editare, editare”, iar tranzacția se oprește.

Dacă utilizați o integrare cu câmpuri găzduite de terți, urmați instrucțiunile de accesibilitate ale furnizorului — majoritatea oferă o metodă documentată de etichetare a câmpurilor din afara iframe-ului. Dacă creați un formular personalizat de captură a datelor, fiecare câmp de introducere trebuie să aibă un <label> element cu o etichetă text vizibilă, plus autocomplete="cc-number" / cc-exp" / cc-csc" atribute, astfel încât managerii de parole și tehnologiile de asistență să poată identifica câmpurile în funcție de scopul lor.

Pagina coșului de cumpărături repetă problema butonului de selectare a cantității de pe pagina de detalii a produsului (PDP), dar cu mize mai mari: un utilizator care folosește un cititor de ecran și nu poate acționa butonul respectiv nu poate finaliza comanda. Butonul „Eliminare” constituie un anti-model în sine — de obicei este o pictogramă mică sub forma unui × lângă fiecare articol, adesea fără text vizibil, fără aria-labelși nu se afișează nicio notificare atunci când rândul este șters. Utilizatorul apasă pe ceea ce speră să fie butonul de ștergere, rândul dispare, iar cititorul de ecran nu emite niciun sunet. Nu există nicio modalitate de a confirma că acțiunea a avut succes.

Mai multe reclamații semnalează o problemă similară: valoarea totală din coș se actualizează dinamic atunci când cantitățile se modifică sau articolele sunt eliminate, însă noua valoare totală este afișată ca text obișnuit în DOM, în afara oricărei zone interactive, astfel încât utilizatorul nu știe ce sumă va trebui să plătească.

Fiecare element ar trebui să afișeze un buton de ștergere etichetat (de exemplu, "Remove Blue T-Shirt, size M, from cart"). Câmpurile de selectare a cantității ar trebui să afișeze valoarea curentă ca parte a denumirii accesibile sau prin actualizări asociate ale regiunii active. Subtotalul coșului ar trebui să se afle în interiorul unui aria-live="polite" regiune, astfel încât modificările să fie anunțate. Confirmați eliminările folosind o opțiune de anulare.

Aceasta este cea mai mare categorie din setul de date, deoarece este problema cu cel mai mic cost de detectare și cu cel mai mare cost de ignorare. Un cititor de ecran parcurge DOM-ul, întâlnește un <input>și citește numele său accesibil — pe care îl calculează pornind, în ordine, de la: aria-labelledby, aria-label, o entitate asociată <label for>, title atributul sau elementul de substituție. Dacă niciunul dintre acestea nu există, cititorul de ecran anunță doar rolul: „casetă de editare” sau „editare, necompletată”. Această frază, aproape cuvânt cu cuvânt, apare în sute de înregistrări ale reclamațiilor.

Motivul pentru care această situație este atât de frecventă este de natură structurală. Sistemele moderne de design afișează adesea textul de substituție în câmpul de introducere ca înlocuitor al etichetei vizibile, iar dezvoltatorii presupun că textul de substituție îndeplinește rolul de etichetă. Nu este așa. Textul de substituție dispare atunci când utilizatorul începe să tasteze, nu lasă în urmă niciun nume programatic și face câmpul inutilizabil pentru oricine ajunge la el mai târziu în fluxul de lucru sau se întoarce la el după o eroare.

Fiecare element de control interactiv primește o etichetă vizibilă, asociată prin programare. <label for="email">Email</label><input id="email" type="email"> este modelul standard. Elementele de substituție sunt indicii suplimentare, nu înlocuitori. Pentru elementele de control în cazul cărora o etichetă vizibilă este cu adevărat nedorită (câmpuri de căutare, butoane cu pictograme), utilizați aria-label cu text descriptiv — niciodată cu elementul de substituție duplicat.

Expresia „nu este anunțat sau nu i se acordă focus” apare cuvânt cu cuvânt în peste 400 de înregistrări de reclamații și este una dintre cele mai frecvente fraze din întregul set de date. Aceasta descrie o problemă specifică: pe pagină apare o fereastră modală sau un dialog (adesea automat — înscriere la newsletter, verificare vârstă, confirmare locație), conținutul vizibil se modifică, dar cititorul de ecran nu primește niciun semnal că s-a schimbat ceva. Focusul rămâne pe pagina de bază. Utilizatorul continuă să navigheze cu tasta Tab prin ceea ce se afla sub fereastra modală, fără să-și dea seama că a apărut o fereastră de dialog care blochează accesul.

Acesta este un exemplu clasic de modalitate care eșuează pe toate planurile în același timp: nu role="dialog", nu aria-modal="true", fereastra nu comută automat la modul deschis, nu rămâne blocată în modul deschis, nu se închide la apăsarea tastei Esc și nu afișează titlul. Deoarece toate aceste erori apar simultan, remedierea uneia dintre ele, luată separat, nu rezolvă problema.

Folosiți un model de dialog standard (specificația „WAI-ARIA Authoring Practices” constituie referința). La deschidere: mutați focalizarea pe primul element care poate fi focalizat din interiorul ferestrei de dialog, setați aria-modal="true" și role="dialog", denumiți caseta de dialog cu aria-labelledby indicând titlul acestuia. Cât timp este deschis: mențineți focalizarea în interiorul ferestrei de dialog. La închidere: readuceți focalizarea asupra elementului care a declanșat-o. Respectați funcția tastei Esc. Dacă fereastra modală întrerupe un flux (de exemplu, redarea automată la încărcarea paginii), oferiți utilizatorului un singur mecanism pentru a o închide definitiv.

Indicatorii de focalizare sunt de obicei dezactivați în mod intenționat de către un programator sau un designer care a considerat conturul implicit al browserului ca fiind un element de distragere a atenției și a scris *:focus { outline: none; } într-o foaie de stil globală. Pagina arată acum mai ordonată pentru un utilizator văzător care folosește mouse-ul. Pentru un utilizator văzător care folosește tastatura — inclusiv majoritatea utilizatorilor cu vedere slabă, a celor cu dizabilități motorii și a celor care navighează fără mouse — pagina devine inutilizabilă. Utilizatorul poate apăsa tasta Tab, dar nu poate vedea unde se află.

Acesta este unul dintre puținele tipuri de erori care pot fi observate fără a apela la tehnologii de asistență. Un evaluator de asigurare a calității care parcurge pagina de start o singură dată, fără alte instrumente, o va remarca în mai puțin de un minut. Faptul că echipele de accesibilitate o identifică în mod constant pe site-urile care fac obiectul unor litigii, în timp ce evaluările interne au trecut-o cu vederea, este unul dintre cele mai fiabile indicii din setul de date că site-ul nu a trecut deloc testul de accesibilitate cu tastatura.

Nu dezactivați niciodată în mod general :focus contururi fără element de înlocuire. Asigurați un stil de evidențiere vizibil — de obicei un contur de 2-3 px cu un contrast suficient atât față de element, cât și față de fundalul acestuia — folosind :focus-visible astfel încât indicatorul să apară la navigarea cu tastatura, dar nu și la clicurile cu mouse-ul. Verificați acest lucru pentru fiecare componentă interactivă, inclusiv widget-urile personalizate, linkurile din cadrul cardurilor și elementele cu tabindex.

Logo-ul este cea mai vizualizată imagine de pe un site web și una dintre cele mai des defecte. De obicei, acesta se află într-un link care redirecționează către pagina principală, dar imaginea este încărcată fără alt, nu aria-label pe link, fără text în jur. Cititorul de ecran anunță doar „link”, fără nicio indicație despre unde duce. Înmulțiți cu fiecare pagină a site-ului.

Categoria mai largă — imaginile fără text alternativ — include bannere grafice, fotografii ale produselor, ilustrații principale, pictograme pentru rețelele sociale și vastul catalog de imagini de marketing pe care îl pune la dispoziție un site tipic de comerț electronic. Reclamațiile din această categorie menționează adesea nume specifice de fișiere imagine, ceea ce indică faptul că expertul reclamantului a efectuat o verificare automată care a identificat fiecare imagine a cărei alt atributul lipsea sau era gol, deși ar fi trebuit să fie descriptiv.

Logo-urile ar trebui să conțină un text alternativ care să descrie numele companiei și, în cazul în care logo-ul conține un link, destinația acestuia — alt="Acme Co. — homepage". Imaginile decorative primesc un atribut alt gol (alt=""), care le ascunde în mod intenționat de tehnologiile de asistență. Imaginile informative trebuie să aibă un text alternativ descriptiv. Evitați generarea automată a textului alternativ pe baza numelor de fișiere sau a subtitrării generate de IA fără o verificare umană; în registrele de reclamații se menționează în mod repetat cazuri în care instrumentele de suprapunere au subtitrat logo-ul unei companii ca fiind „un semn albastru și galben”.

Cititoarele de ecran afișează o vizualizare de tip „listă de linkuri”, folosită intens de utilizatorii experimentați pentru a parcurge o pagină în câteva secunde. Această vizualizare afișează doar textul linkului, separat de paragraful din care face parte. O pagină în care fiecare titlu de blog se termină cu „Citește mai mult” se afișează în acea vizualizare sub forma a cincisprezece intrări identice. O pagină cu cinci linkuri goale — <a href="..."></a>, situație frecventă atunci când pictogramele se află în elemente de tip link fără text de rezervă — afișează cinci spații goale.

Soluția este binecunoscută, la fel și problema, motiv pentru care acest tipar apare în mod repetat în reclamații — persistența sa indică un proces de dezvoltare care nu include un instrument automat de verificare a textului linkurilor și nici o verificare manuală pentru cititoarele de ecran.

Fiecare link trebuie să aibă un nume accesibil care să descrie destinația sau acțiunea sa. Înlocuiți expresiile generice cu unele descriptive — „Citește mai mult” devine „Află mai multe despre rezultatele financiare din trimestrul al treilea”. Pentru linkurile care conțin doar pictograme, adăugați text ascuns vizual sau un aria-label. Efectuați o verificare automată (Axe, Lighthouse etc.) pentru a depista elementele goale <a> elemente în timpul CI.

În reclamații, problemele legate de conținutul video se manifestă în două moduri. Primul este evident: un videoclip de marketing, o demonstrație de produs sau un videoclip explicativ este publicat fără subtitrări, transcriere sau orice altă alternativă text — iar un vizitator surd sau cu deficiențe de auz nu poate accesa conținutul. Al doilea este mai subtil: un videoclip principal care se redă automat la încărcarea paginii, ceea ce interferează cu ieșirea cititorului de ecran și încalcă comenzile de pauză/oprire prevăzute la nivelul WCAG 2.2 AA (conform SC 2.2.2 Pauză, Oprire, Ascundere pentru conținut în mișcare și SC 1.4.2 pentru orice conținut audio).

Unele reclamații din acest set de date susțin că „lipsa subtitrărilor pe videoclipurile de pe site-ul web constituie o încălcare a ADA”, afirmație prezentată ca o concluzie juridică. Validitatea acestei interpretări variază în funcție de jurisdicție și de circumstanțe; ceea ce este mai cert este faptul că aceste videoclipuri nu respectă în mod constant standardul WCAG 2.2 AA, standard pe care majoritatea instanțelor și acordurilor de soluționare îl consideră drept criteriul de referință operațional în materie de conformitate.

Asigurați subtitrări sincronizate pentru toate videoclipurile preînregistrate care conțin sunet. Furnizați și o transcriere text; transcrierile sunt utile pentru utilizatorii care au dispozitivele cu sunetul oprit, în medii cu lățime de bandă redusă, precum și pentru indexare. Evitați redarea automată; dacă redarea automată este necesară din motive de design, asigurați un buton de pauză/oprire accesibil imediat de la tastatură. Pentru conținutul exclusiv video (fără sunet), asigurați o descriere audio sau o alternativă text.

Autentificarea este punctul de acces pentru întreaga experiență de autentificare. Când formularul nu funcționează, toate paginile din spatele acestuia devin inaccesibile, iar utilizatorii percep adesea această reacție în lanț ca pe o singură barieră. Modelul este aceeași eroare de etichetare a formularului ca în cazul E·01, adesea combinată cu trei sub-erori specifice: un comutator „Afișează parola” implementat ca un buton doar cu pictogramă, fără nume și fără anunțarea schimbării de stare, un CAPTCHA care împiedică complet utilizarea cititorului de ecran și erori în linie („credențiale nevalide”) care sunt afișate pe ecran, dar nu sunt anunțate.

Caseta de selectare „Reține-mă” reprezintă o altă eroare secundară recurentă: afișată ca un element stilizat <div>, cu valoarea reală <input> ascunsă în afara ecranului, caseta de selectare poate fi activată cu mouse-ul, dar nu și cu tastatura sau cu un cititor de ecran. Utilizatorul nu are nicio posibilitate de a opta pentru o sesiune persistentă.

Folosiți date reale <input>, <label>și <button> elemente. Transformați comutatorul de afișare/ascundere a parolei într-un buton propriu-zis, cu un nume accesibil care se actualizează în funcție de starea acestuia ("Show password" / "Hide password") și anunță schimbarea prin aria-pressed. Asigurați o alternativă accesibilă la CAPTCHA-urile bazate pe imagini (CAPTCHA audio sau — de preferință — înlocuiți CAPTCHA cu autentificarea bazată pe risc sau cu variantele accesibile ale hCaptcha).

Cititoarele de ecran prezintă pagina prin trei moduri de navigare: după titluri, după repere și după linkuri. O pagină care nu include un <h1>, fără <main>, <nav>și <footer> repere, și fără un lang="en" atributul de pe <html> elementul a eliminat simultan toate cele trei moduri de navigare. Utilizatorii nu au nicio posibilitate de a parcurge conținutul, de a accesa direct conținutul și nici cititorul de ecran nu poate încărca motorul de pronunție corespunzător.

Este vorba despre o eroare neobișnuit de gravă: lipsa unui singur reper determină o serie de probleme în lanț, deoarece toate strategiile de navigare ale cititoarelor de ecran care se bazează pe acesta nu mai funcționează. Reclamațiile din această categorie menționează de obicei patru sau cinci probleme structurale specifice, prezentate ca dovadă a faptului că site-ul nu are o bază semantică.

Fiecare pagină primește una și numai una <h1>, cu subtitluri (<h2>, <h3>) grupate logic. Încadrați regiunile în elemente de reper HTML5: <header>, <nav>, <main>, <aside>, <footer>. Set lang la rădăcină <html> element. Verificați cu un instrument de verificare a structurii sau rulați document.querySelectorAll('h1').length === 1 ca test de funcționalitate în CI.

Cea mai mare parte a procesului de asigurare a calității în materie de accesibilitate se desfășoară pe browserele pentru desktop, folosind NVDA sau JAWS. Tehnologiile asistive pentru dispozitive mobile — VoiceOver pe iOS, TalkBack pe Android — prezintă o redare diferită a aceluiași DOM, adesea cu erori distincte. Reclamațiile folosesc în mod repetat abrevierea „mobile SRU” (utilizator de cititor de ecran mobil) pentru a semnala erori specifice vizualizării mobile: un meniu hamburger care funcționează cu NVDA pe desktop, dar nu reacționează sub VoiceOver, un buton Apple Pay accesibil pe un laptop, dar nu și pe echivalentul paginii pentru iPhone, mesaje de eroare afișate pe desktop, dar nu și pe mobil.

Datele sugerează că părțile pârâte, a căror accesibilitate pe desktop este, în general, satisfăcătoare, sunt totuși date în judecată din cauza unor probleme specifice dispozitivelor mobile. Conformitatea cu standardele de accesibilitate pe dispozitive mobile constituie un criteriu de evaluare în sine.

Testați cel puțin cu VoiceOver în Safari pe iOS și cu TalkBack în Chrome pe Android, folosind aceleași fluxuri de lucru acoperite de testarea calității pe desktop. Acordați o atenție deosebită interacțiunilor bazate pe gesturi, butoanelor native de plată și anunțurilor privind câmpurile formularelor la focalizare. Dacă există o aplicație nativă, supuneți-o aceluiași proces de verificare — reclamațiile vizează adesea atât versiunea web, cât și aplicația, în cadrul aceluiași caz.

Suprapunerea de accesibilitate este singurul exemplu din acest catalog în care problema nu se află deloc în site-ul de bază — ci în stratul de remediere care a fost adăugat tocmai pentru a o rezolva. Plângerile din această categorie descriu două tipuri distincte de probleme. Prima este că suprapunerile nu elimină de fapt barierele existente, astfel încât utilizatorul se confruntă cu aceleași ferestre modale defecte, formulare etichetate greșit și erori neanunțate, indiferent dacă widgetul este prezent sau nu. Al doilea este mai precis: suprapunerile introduc uneori noi defecțiuni prin inserarea de etichete incorecte, aplicarea greșită a rolurilor ARIA sau interferarea cu propria configurație a tehnologiei de asistență a utilizatorului.

Un detaliu demn de remarcat: plângerile din 2024 și 2025 menționează din ce în ce mai des numele furnizorului de soluții de tip overlay. Două pasaje specifice din plângeri identifică în mod clar companiile UserWay și AccessiBe, iar măsurile recente luate de FTC au creat riscul explicit ca adăugarea unei soluții de tip overlay să constituie în sine o dovadă a eșecului în realizarea unor măsuri concrete de remediere — și nu o apărare împotriva unui proces.

Tratați suprapunerile ca pe un indicator, nu ca pe o soluție definitivă. Dacă în prezent este implementată o astfel de suprapunere, elaborați un plan de remediere real care să abordeze codul de bază, în loc să-l mascheze. Calea verificată în practică constă într-o combinație dintre: un scaner automat integrat în CI, o verificare manuală conform standardului WCAG 2.2 AA, testarea manuală cu cel puțin un cititor de ecran și navigare exclusiv prin tastatură, precum și asigurarea continuă a calității accesibilității în cadrul procesului de proiectare și dezvoltare.