ACCESIBILITATE ≠ OVERLAY · 36
Tabele accesibile: datele au nevoie de context, nu de un overlay
📅 9 noiembrie 2026 · ⏱ 7 min de lectură
Un tabel poate părea ordonat și totuși poate rămâne neinteligibil pentru cineva care îl ascultă sau folosește mărirea. Accesibilitatea cere păstrarea relațiilor dintre fiecare valoare, rândul și coloana sa.
01. Un număr izolat explică prea puțin
Imaginați-vă că verificați programul unui serviciu și auziți doar „09:00, 10:00, 11:00, 12:00”. Fără să știți ziua și serviciul corespunzător fiecărei ore, nu puteți lua o decizie utilă. Bariera apare când contextul depinde exclusiv de privirea în sus sau spre stânga. Informațiile sunt vizibile, dar programele nu pot identifica relațiile necesare.
Același lucru se întâmplă într-un tabel cu prețuri. O sumă poate reprezenta un abonament lunar, un preț anual sau o taxă suplimentară. Dacă persoana trebuie să memoreze poziția tuturor coloanelor, consultarea devine un exercițiu de reconstruire a structurii. Obiectivul practic este obținerea independentă a unui răspuns la o întrebare concretă, fără a ghici semnificația valorilor.
02. Decideți dacă informațiile necesită un tabel
Un tabel este potrivit atunci când comparația dintre rânduri și coloane transmite sens: programe, tarife, caracteristici sau rezultate. Pentru o succesiune de instrucțiuni ori o descriere scurtă, o listă sau câteva paragrafe pot fi mai clare. Alegerea trebuie să pornească de la informații, nu de la aspectul atractiv al grilei oferite de editor.
Nu utilizați tabele nici pentru a așeza două blocuri independente unul lângă altul. CSS și componentele de machetare trebuie să gestioneze prezentarea. Amestecarea aspectului cu datele introduce o structură pe care tehnologiile asistive o pot anunța fără vreun beneficiu. Definiți comparația necesară și eliminați coloanele care nu contribuie la îndeplinirea sarcinii.
03. Antete care există și în cod
Textul îngroșat sau fundalul albastru nu transformă primul rând în antete reale. Celulele care identifică rânduri ori coloane trebuie să folosească th, iar datele obișnuite td. În tabele simple, scope="col" și scope="row" pot indica explicit direcția asocierilor relevante dintre celule.
De exemplu, „Serviciu”, „Luni” și „Marți” identifică niște coloane. „Consultații” și „Asistență” pot identifica rândurile. Pentru o oră contează atât serviciul, cât și ziua. Nu adăugați ARIA automat pentru a repeta semantica nativă. Verificați întâi HTML-ul componentei, apoi modul în care combinația folosită de browser și cititor de ecran prezintă relațiile la deplasarea între celule. Aspectul corect nu confirmă singur aceste legături.
| Serviciu | Luni | Marți |
|---|---|---|
| Consultații | 09:00 | 10:00 |
| Asistență | 11:00 | 12:00 |
04. Un titlu util și o orientare scurtă
Un caption ajută la identificarea tabelului. „Programul serviciilor” spune mai mult decât „Tabelul 1”. Titlul trebuie să permită diferențierea de alte tabele fără citirea tuturor paragrafelor precedente. Dacă perioada, moneda sau unitatea sunt esențiale, acestea trebuie să fie clare în tabel sau într-o explicație asociată.
Un tabel complex poate necesita și o descriere scurtă a organizării. Explicați, de exemplu, că fiecare grup de coloane reprezintă un trimestru. Această orientare nu înlocuiește antetele celulelor. Evitați descrierile lungi care repetă toate valorile: scopul este facilitarea consultării, nu obligarea persoanei să asculte aceleași informații de două ori înainte de a ajunge la răspunsul căutat.
05. Simplificați înainte de a uni celule
Celulele unite și antetele pe mai multe niveluri îngreunează înțelegerea și întreținerea. Înainte de a le introduce, analizați dacă informațiile pot fi împărțite în tabele mai mici cu titluri precise. Separarea a două perioade poate ajuta mai mult decât adăugarea unor atribute într-o grilă enormă. Claritatea începe astfel chiar din etapa editorială.
Când complexitatea este necesară, modelați explicit grupurile și asocierile. În funcție de structură, pot fi potrivite scope="colgroup", scope="rowgroup" sau relațiile dintre id și headers. Nu sunt rețete interschimbabile pentru orice tabel. Verificați relațiile reale și testați celule centrale, limite și grupuri diferite. Citirea corectă a primului rând nu demonstrează că întregul tabel este inteligibil.
06. Telefonul nu trebuie să elimine relațiile
Micșorarea textului până când întregul tabel încape pe telefon face informațiile greu de citit. Ascunderea coloanelor fără alt acces la conținut nu rezolvă problema. Designul adaptabil trebuie să păstreze informațiile necesare pentru comparație și decizie, inclusiv atunci când persoana folosește mărirea.
O regiune cu derulare orizontală poate fi rezonabilă pentru date care necesită două dimensiuni. Când este necesar, regiunea trebuie să poată fi utilizată cu tastatura și să indice clar existența altui conținut. Dacă rândurile devin carduri, păstrați etichetele și sensul în DOM. Verificați că transformarea vizuală nu elimină semantica și nu obligă vizitatorul să deducă ce etichetă aparține fiecărei valori.
07. Culori, abrevieri și celule goale
O celulă verde nu explică singură „disponibil”, iar roșul nu înseamnă neapărat „fără locuri”. Adăugați text sau un echivalent inteligibil și verificați contrastul textelor, controalelor și indicatorilor relevanți. Culorile alternante ale rândurilor pot ajuta la urmărirea datelor, dar nu trebuie să fie singurul indiciu pentru înțelegerea relațiilor.
Explicați abrevierile neobișnuite și utilizați consecvent unitățile. Diferențiați zero, informație necunoscută și serviciu indisponibil: sunt situații distincte. Celulele goale pot fi ambigue atât vizual, cât și la ascultare. O alegere editorială precum „Fără date” împiedică interpretarea tăcerii ca valoare numerică sau ca defecțiune a cititorului de ecran. Aplicați aceeași regulă în toate publicațiile.
08. Sortare și filtre utilizabile
Dacă un antet permite sortarea, oferiți acțiunea printr-un control cu nume clar, care funcționează cu tastatura. Comunicați programatic starea sortării atunci când este cazul; aria-sort poate exprima starea pe antetul potrivit. Un triunghi mic nu explică suficient ce coloană stabilește ordinea actuală a rezultatelor.
După filtrare, păstrați o focalizare previzibilă și comunicați rezultatele relevante fără anunțuri continue. Testați și lipsa rezultatelor, precum și resetarea filtrului. Nu transformați un tabel informativ într-o grilă interactivă cu navigare specială dacă sarcina nu necesită acest lucru. Fiecare comportament suplimentar trebuie proiectat și verificat cu grijă, nu considerat automat mai accesibil doar pentru că pare mai sofisticat.
09. Verificați sarcini, nu doar etichete
Alegeți o întrebare cu răspuns verificabil: „La ce oră este disponibilă asistența marți?”. Răspundeți întâi vizual, apoi cu un cititor de ecran și comenzile lui de navigare în tabele. Testul util nu este simpla anunțare a existenței tabelului, ci identificarea valorii corecte și a antetelor fără pierderea contextului.
Repetați sarcina cu mărire și o fereastră îngustă. Utilizați tastatura pentru butoane, filtre și regiunile derulabile care o necesită. Nu toate celulele unui tabel static trebuie să devină opriri pentru Tab. Documentați browserul, tehnologia asistivă, comportamentul observat și răspunsul corect pe care persoana ar trebui să îl obțină independent. Astfel puteți verifica precis și eficiența corecțiilor ulterioare.
10. Contribuția instrumentelor și a WCAG
Un instrument automat poate semnala anumite probleme structurale, dar nu decide dacă un antet descrie bine datele sau dacă împărțirea tabelului ar ușura comparația. Nu validează singur nici toate stările unui filtru. Combinați observațiile cu inspecția codului, revizuirea editorială și efectuarea manuală a sarcinilor.
În WCAG 2.2, criteriul 1.3.1, Informații și relații, este deosebit de relevant pentru structura tabelară. În funcție de componentă, contează și tastatura, contrastul, rearanjarea și mesajele de stare. Excepția de rearanjare pentru conținut care necesită două dimensiuni nu scutește întreaga pagină. Evaluați separat fiecare cerință aplicabilă, fără a prezenta o anumită soluție de cod ca garanție a conformității complete a site-ului.
11. Corectați WordPress și Divi la sursă
Examinați HTML-ul generat de modulul sau pluginul de tabele după salvare. Editorul poate evidenția primul rând și totuși publica doar celule td. Lipirea dintr-o foaie de calcul poate introduce stiluri și uniri inutile. Verificarea trebuie făcută asupra rezultatului real, nu doar în interfața constructorului.
Dacă același defect apare în multe articole, corectați componenta sau șablonul comun și documentați o regulă editorială. Un overlay nu poate deduce sigur dacă o cifră este preț, termen sau procent și nici ce comparație îi trebuie vizitatorului. Reglajele vizuale pot completa munca, dar relațiile dintre antete și date trebuie să existe în conținutul original. Verificați corecția comună și pe exemple mai vechi.
12. Informații inteligibile și mâine
Înainte de publicare, confirmați titlul, unitățile, antetele, asocierile și comportamentul pe ecrane înguste. Includeți o sarcină concretă în verificarea editorială și repetați-o când se schimbă datele sau pluginul. Un tabel corect se poate deteriora prin adăugarea unei coloane, unirea celulelor sau înlocuirea etichetelor descriptive cu pictograme.
Implicați, când este posibil, persoane care folosesc tehnologii asistive și luați în considerare dificultățile lor reale. Cel mai bun tabel nu acumulează cele mai multe atribute. Permite consultarea și comparația fără reconstruirea mentală a structurii. Accesibilitatea se demonstrează când persoana găsește valoarea corectă, îi înțelege semnificația și poate utiliza informația pentru a lua propria decizie în mod independent.