Navigarea din tastatură: cum verifici accesibilitatea unui site

Navigarea din tastatură e prima verificare de accesibilitate pe care o poate face oricine, pe orice site, fără niciun instrument. Un site poate arăta impecabil și poate fi, în același timp, imposibil de folosit fără mouse.

Nu vorbim despre un grup mic de oameni.

Persoanele nevăzătoare parcurg pagina cu un cititor de ecran și cu tastele de navigare. Persoanele cu deficiențe motorii nu pot ține un mouse. Utilizatorii de comenzi vocale și de dispozitive cu un singur buton simulează tasta Tab.

La fel lucrează și cine completează formulare toată ziua și nu vrea să ridice mâna de pe tastatură.

Testul de bază are două condiții separate, iar amândouă trebuie să fie îndeplinite.

Tasta Tab trebuie să ajungă la element.

și

Trebuie să se vadă unde a ajuns.

Multe site-uri trec primul test și cad la al doilea. Indicatorul de focus e ușor de șters din CSS și greu de observat că lipsește, atâta timp cât folosești mouse-ul.

Ce cere standardul, în cinci criterii

Fiecare problemă de navigare din tastatură încalcă un criteriu precis din standardul WCAG. Criteriile merită știute pe nume, pentru că un raport de audit le citează exact așa.

2.1.1 Keyboard, nivel A

Toate funcțiile paginii trebuie să poată fi acționate din tastatură.

Nu doar linkurile din meniu. Și galeria de imagini, și harta interactivă, și butonul de închidere al unei ferestre, și selectorul de dată.

Dacă o funcție există doar la clic sau doar la trecerea mouse-ului peste element, criteriul e încălcat.

2.1.2 No Keyboard Trap, nivel A

Dacă focusul poate intra într-un element, trebuie să poată și ieși, folosind numai tastatura.

Capcana clasică e o fereastră modală din care Tab plimbă focusul în cerc, fără cale de ieșire.

Un player video încorporat sau un widget de la un serviciu extern produce același efect, atunci când preia tastele și nu le mai eliberează.

2.4.3 Focus Order, nivel A

Ordinea în care elementele primesc focus trebuie să păstreze sensul paginii.

Când ordinea din cod nu corespunde ordinii vizuale, cineva care nu vede ecranul primește informația amestecată.

Se întâmplă mai ales la coloane rearanjate din CSS și la ferestre modale inserate la sfârșitul documentului.

2.4.7 Focus Visible, nivel AA

Trebuie să existe un indicator vizibil al elementului focalizat.

Aici cade cel mai des. E de ajuns o linie de CSS, pe un site construit corect în tot restul.

/* șterge indicatorul pe tot site-ul */
*:focus { outline: none; }

Regula de mai sus se scrie de obicei ca să scape de conturul implicit al browserului, considerat inestetic. Rezultatul e că nimeni nu mai vede unde se află.

Soluția nu e să renunți la aspect. Se înlocuiește indicatorul, nu se șterge.

:focus-visible {
  outline: 3px solid #7B3FA0;
  outline-offset: 2px;
}

2.4.11 Focus Not Obscured, nivel AA

Elementul focalizat nu are voie să fie acoperit complet de alt conținut adăugat de autor.

Criteriul a fost introdus în WCAG 2.2 și prinde o situație foarte concretă: un antet lipit sus sau o bară de cookie-uri lipită jos, care acoperă exact elementul la care a ajuns Tab.

Utilizatorul aude sau știe că a ajuns undeva, dar nu vede unde.

Cauzele obișnuite, în cod

Aproape toate problemele de navigare din tastatură vin dintr-un număr mic de decizii de implementare.

• div sau span folosit ca buton. Un element neinteractiv nu primește focus și nu răspunde la Enter sau la bara de spațiu.
• outline: none fără înlocuitor. Vezi criteriul 2.4.7 mai sus.
• tabindex cu valori pozitive. Scoate elementul din ordinea firească a documentului și rupe ordinea de focus pe restul paginii.
• Conținut ascuns care rămâne focalizabil. Un meniu închis prin opacity: 0 sau prin poziționare în afara ecranului primește în continuare focus, deci Tab dispare într-o zonă invizibilă.
• Fereastră modală fără gestiunea focusului. Focusul nu intră în ea la deschidere, nu e reținut în interior și nu se întoarce la elementul care a deschis-o.
• Interacțiuni doar la hover. Un submeniu care apare numai când mouse-ul trece peste el nu are echivalent din tastatură.
• Lipsa unui link de sărire. Fără el, cineva care navighează din tastatură trece prin tot meniul la fiecare pagină.

Prima cauză din listă e și cea mai ușor de evitat.

<!-- nu funcționează din tastatură -->
<div class="btn" onclick="trimite()">Trimite</div>

<!-- funcționează, fără nicio linie de JavaScript în plus -->
<button type="button" onclick="trimite()">Trimite</button>

Un button primește focus, apare în ordinea documentului, răspunde la Enter și la bara de spațiu și e anunțat ca buton de cititorul de ecran. Toate acestea vin din elementul HTML, nu din cod scris de tine.

Dacă un element neinteractiv trebuie totuși folosit, cele patru comportamente se scriu manual.

<div role="button" tabindex="0"
     onclick="trimite()"
     onkeydown="if (event.key === 'Enter' || event.key === ' ') trimite()">
  Trimite
</div>

Al doilea fragment face același lucru, cu mai mult cod și cu mai multe moduri de a greși.

Linkul de sărire, la rândul lui, e un element de câteva linii, ascuns până când primește focus.

<a class="skip-link" href="#continut">Sari la conținut</a>

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
}

Ascunderea prin poziționare în afara ecranului e corectă aici, tocmai pentru că elementul rămâne focalizabil. Un element ascuns care primește focus e, în acest singur caz, exact ce vrei.

Cum testezi, în zece minute

Nu ai nevoie de niciun instrument special. Ai nevoie de tastatură și de atenție.

Parcurge pagina numai cu Tab

Pune mâinile pe tastatură și nu atinge mouse-ul.

Apasă Tab de la începutul paginii până la sfârșit și urmărește dacă ajungi la fiecare link, buton și câmp de formular.

Verifică dacă vezi tot timpul unde te afli

Dacă la un moment dat nu mai vezi nimic selectat, ai găsit deja o problemă.

Focusul dispărut înseamnă sau un indicator șters din CSS, sau un element ascuns care rămâne în ordinea de tabulare.

Compară ordinea de focus cu ordinea vizuală

Focusul ar trebui să urmeze felul în care citești pagina.

Un salt de la primul element din stânga direct în josul paginii și înapoi arată o nepotrivire între cod și afișare.

Deschide și închide fiecare fereastră modală

Deschide-o din tastatură, verifică dacă focusul intră în ea și dacă rămâne în interior până o închizi.

Închide-o și verifică dacă focusul se întoarce la elementul care a deschis-o, nu la începutul paginii.

Apasă Enter și bara de spațiu pe fiecare control

Un link se acționează cu Enter. Un buton, cu Enter și cu bara de spațiu.

Dacă un element arată ca un buton, dar nu răspunde la bara de spațiu, probabil nu e un buton.

Ce nu vezi cu un instrument automat

Un verificator automat găsește linkurile și butoanele fără nume accesibil, adică o parte din problemele care afectează navigarea din tastatură.

Restul nu se poate verifica după reguli fixe. Cere un om care încearcă efectiv:

• dacă ordinea de focus are sens față de ordinea vizuală;
• dacă indicatorul se vede suficient pe fundalul real al paginii;
• dacă o fereastră modală poate fi închisă din tastatură;
• dacă fiecare interacțiune la hover are echivalent din tastatură.

Aceeași limită apare la problemele frecvente de accesibilitate, unde cifrele publicate acoperă doar erorile detectabile automat.

Din același motiv, un widget adăugat peste site nu rezolvă nimic aici: suprapunerile de accesibilitate nu rescriu ordinea de focus și nu transformă un div în buton.

Când navigarea din tastatură se rezolvă din start

Testarea găsește problemele. Nu le previne.

Un proiect în care fiecare control interactiv e un element HTML potrivit, iar indicatorul de focus face parte din sistemul de design, nu ajunge să aibă listă de reparații la final.

Asta e diferența dintre a construi accesibil și a corecta ulterior, cu efect direct în costul unui site accesibil.

Pentru cine comandă site-ul, miza nu e estetică. Funcționarea din tastatură e criteriu de nivel A, adică în minimul pe care îl verifică orice evaluare de conformitate.

Un site care nu trece testul cu Tab nu poate fi declarat conform, indiferent cât de bine arată. Obligația de accesibilitate vine, pentru instituțiile publice, din OUG 112/2018, iar pentru companii din Legea 232/2022.

Dacă ai un proiect web în lucru sau un site care nu trece testul cu Tab, Fundația TIFLO se ocupă de dezvoltare web accesibilă, de la primele componente până la testarea cu cititoare de ecran. Pentru un site deja lansat, punctul de pornire e un audit de accesibilitate.

Întrebări frecvente

Ce este navigarea din tastatură?

Folosirea unui site fără mouse, cu tasta Tab pentru a trece de la un element interactiv la altul, Enter și bara de spațiu pentru a le acționa, tastele săgeți pentru elemente compuse. Standardul WCAG cere ca toate funcțiile paginii să fie disponibile astfel.

Cum testez rapid dacă site-ul meu merge din tastatură?

Pune mouse-ul deoparte și apasă Tab de la începutul paginii. Urmărește trei lucruri: dacă ajungi la toate controalele, dacă vezi permanent unde te afli și dacă poți ieși din orice fereastră care se deschide. Testul de bază durează câteva minute pe o pagină.

De ce nu se mai vede conturul de focus pe site-ul meu?

Cel mai probabil există o regulă CSS de tipul outline: none, aplicată global ca să scape de conturul implicit al browserului. Soluția e să înlocuiești indicatorul cu unul propriu, definit pe :focus-visible, nu să îl elimini.

Ce este un link de sărire și de ce am nevoie de el?

Un link plasat primul în pagină, care duce direct la conținutul principal. Fără el, cine navighează din tastatură parcurge tot meniul la fiecare pagină. Corespunde criteriului WCAG 2.4.1, nivel A.

E greșit să folosesc tabindex cu valori pozitive?

În practică, da. Valorile pozitive creează o a doua ordine, care se suprapune peste cea a documentului, iar rezultatul e greu de urmărit chiar și pentru cine a scris codul. tabindex="0" include un element în ordinea firească, iar tabindex="-1" îl scoate din tabulare, dar permite focalizarea din cod.

Un div cu role="button" este suficient?

Poate fi corect, dar cere să scrii manual ce oferă un button din start: focalizarea, apariția în ordinea documentului, răspunsul la Enter și la bara de spațiu. Elementul nativ e mai scurt de scris și mai greu de greșit.

Navigarea din tastatură ajută și persoanele fără dizabilități?

Da. Aceleași corecturi ajută pe oricine completează formulare rapid, folosește un laptop fără mouse sau lucrează cu un touchpad defect. E unul dintre cazurile în care o cerință de accesibilitate se simte imediat de toată lumea.

Despre autor

Aurel Pătru este profesor, specialist în accesibilitate și fondatorul Fundației TIFLO. De peste 20 de ani activează în domeniul educației, iar de mai bine de 15 ani dezvoltă și implementează soluții de accesibilitate pentru persoanele cu deficiențe de vedere, de la documente și platforme digitale până la spații fizice și materiale Braille și tactile.