Știri

Proiecte active

Ultima actualizare: 31 octombrie 2026

În desfășurare

v3: O suită completă de asigurare a calității

27 septembrie 2026

Prezentarea în premieră la DrupalCon Europe 2026

Principalele funcții noi

• Nucleu de testare comun cu Sa11y. Noul set de reguli, dezvoltat împreună, adaugă teste pentru dezvoltatori, verificarea contrastului și scorul de lizibilitate la setul de bază de teste pentru conținut.
• Suport pentru mai multe limbi
• Constructor de verificări personalizate
• Instrumente de întreținere a panoului de control
• Un instrument de crawling al site-ului, pentru adăugarea de rezultate noi.
• Permite respingerea alertelor la nivel de site pentru anumite teste (este accesibil acest PDF?) și pentru anumite roluri.
• Configurare split: testare și vizualizări de rapoarte în funcție de rol, separat pentru dezvoltatori și pentru editorii de conținut.

Și, poate cel mai important pentru viitorul proiectului:

• Am obținut un grant pentru a lansa această organizație de sponsorizare, care să sprijine utilizatorii existenți și să finanțeze lucrul la viitoarele idei de proiect.

v2: Respingeri și rapoarte

2 martie 2023

Acum doi ani am prezentat verificatorul de accesibilitate Editoria11y, un plugin de site gata de utilizare pentru Drupal, care le oferă autorilor feedback automat și instantaneu, cu sfaturi utile pentru îmbunătățirea conținutului.

Credeam că acoperă o nevoie reală, rămasă nesatisfăcută. Toate opțiunile existente cereau instruire și utilizare conștiincioasă ca să fie de folos, iar experiența ne arătase că încercarea de a instrui și de a monitoriza mii de autori de conținut dintr-o organizație mare nu era un mod eficient de a aborda problema. Ca un program să reușească, eram siguri că avea nevoie de un grad ridicat de automatizare, oferindu-le autorilor de conținut, politicos, „instruire exact la momentul potrivit” atunci când detecta greșeli frecvente.

A funcționat.

La Princeton, a inversat în mare măsură direcția comunicărilor mele. Pe platformele unde era instalat, am trecut de la trimiterea unor e-mailuri repetitive prin care le ceream autorilor de conținut text alt sau îmbunătățiri ale linkurilor și titlurilor, la primirea de întrebări din partea autorilor despre cum să-și îmbunătățească textele, ca să nu mai fie semnalate atât de des.

În exterior, reacția a fost de entuziasm:

Scrierea unor sfaturi de sine stătătoare

Pentru sfaturile din v1 am ales o abordare de tip „rezumat și detalii”: o scurtă explicație a problemei și un link către mai multe detalii.

A fost un progres față de instrumentele scrise pentru dezvoltatori: sfaturile erau scurte și clare. Însă decizia privind destinația linkurilor a rămas mereu o problemă. Mai mulți utilizatori din administrația publică și din învățământul superior au simțit nevoia să modifice sfaturile pentru a elimina linkurile către documentația Princeton, ceea ce însemna muncă în plus pentru ei. Așa că am rescris sfaturile implicite astfel încât să fie de sine stătătoare, cu exemple incluse direct în text.

Distincția dintre alertele roșii (probleme sigure) și avertismentele galbene (probleme posibile) s-a dovedit derutantă și, uneori, enervantă.

Așa că am transformat avertismentele galbene în „verificări manuale”, pentru a le clarifica sensul, și am adăugat butoane cu care autorii pot respinge alertele. Alertele „ignorate” sunt ascunse doar pentru persoana care a dat clic; cele „marcate ca OK” sunt ascunse pentru toți editorii site-ului. Administratorii de site pot alege cine are permisiunea pentru fiecare dintre aceste acțiuni.

Crearea unui panou de control

Proprietarii de site-uri se plângeau adesea că instrumentul găsea foarte bine problemele de pe tot site-ul, dar nu exista nicio modalitate de a vedea un raport la nivelul întregului site.

Rescrierea adaugă opțiunea de a sincroniza rezultatele cu baza de date a site-ului. Proprietarii de site-uri pot acum răsfoi rezultatele după pagină sau după problemă și pot vedea ce probleme au fost ignorate sau marcate ca OK – iar dacă nu sunt de acord, pot restaura problema!

Turul codului v2 pentru dezvoltatori

V2 a fost o rescriere aproape completă. Printre noile funcții se numără:

• Eliminarea dependenței de jQuery permite instalarea pe mai multe platforme și dublează performanța.
• Verificatorul poate fi acum configurat să analizeze mai multe părți independente ale paginii (de exemplu, conținutul articolului și subsolul paginii).
• Verificatorul poate testa acum elemente din interiorul shadow DOM, folosit de diverse componente Web și biblioteci JavaScript.
• Mulți parametri noi ușurează integrarea cu platformele, de exemplu ignorarea automată a tuturor problemelor de pe anumite pagini pentru anumiți utilizatori, dacă aceștia nu răspund de conținutul paginii respective, dar ar putea totuși să vrea să vadă rezultatele la cerere.
• Verificatorul include acum mai multe teme de bază și parametri pentru personalizarea culorilor.
• Testarea automată ajută la prevenirea regresiilor din cod.

A11yTalks 2024

11 iunie 2024

Drupal GovCon 2023

27 octombrie 2023

DrupalCamp NJ 2023

28 martie 2023

v1: Ajutor inline

11 martie 2021

Crearea unui conținut Web cu adevărat accesibil este complicată și începe, de obicei, cu multă instruire.

Practicile familiare trebuie descurajate:

• Tabelele nu ar trebui folosite pentru a crea coloane false
• Textul continuu nu ar trebui centrat sau aliniat la ambele margini
• Nu ar trebui să ne bazăm pe formatarea exclusiv vizuală (grosimea și dimensiunea fontului) pentru a transmite sens utilizatorilor, care ar putea asculta conținutul sau l-ar putea vedea în „modul de citire”

Practicile noi trebuie încurajate:

• Imaginile au nevoie de text alternativ cu sens în context
• Paginile au nevoie de o structură reală
• Linkurile ar trebui să aibă titluri cu sens

Desigur, unele dintre instruirile noastre există pentru că predăm concepte noi, dar la un moment dat trebuie pusă întrebarea: cât din nevoia de competențe noi vine din faptul că aceste concepte sunt noi și cât vine din faptul că introducem așteptări noi fără să ne actualizăm instrumentele? Faptul că ceva este nou nu înseamnă că nu poate fi intuitiv.

Lecții din istoria ortografiei

Faza 1: E vina autorului

Încă din zorii istoriei consemnate și până la începutul anilor 1980, când cineva scria greșit un cuvânt, vina era a autorului. Responsabilitatea de a învăța să scrie corect îi revenea lui.

Cum își îmbunătățea cineva ortografia? O să vi se pară cunoscut:

1. Mergea la cursuri, cu un meditator sau într-o sală de clasă
2. Primea de studiat liste, îndrumări și dicționare, o practică ce datează încă din vechile lexicoane cuneiforme gravate în lut.

Faza 2: E vina dicționarului

Dar în anii 1980 ceva s-a schimbat: să-i spunem „faza 2 a ortografiei”. Cele mai populare programe de procesare de text au introdus verificarea ortografică.

Și ce s-a întâmplat cu jocul de-a vinovații? Aproape peste noapte, vina a trecut asupra instrumentului:

• Nu știți cum se scrie un cuvânt? Încercați ceva la nimereală și sperați să se găsească o potrivire. Dacă nu se găsește, e vina dicționarului.
• Folosiți un cuvânt real, pe care dicționarul îl semnalează pentru că nu îl cunoaște? Bombăniți și decideți dacă ignorați sublinierea sau dați clic dreapta și adăugați cuvântul în dicționar.

A rezolvat verificarea ortografică toate problemele noastre de ortografie? Sigur că nu. Dar a ajutat. Și a mutat o mare parte din povară și din responsabilitate de la autor la mașină.

Totuși, nu acesta a fost sfârșitul…

Faza 3: E vina instrumentului de redactare

Ultimii ani au adus încă un pas înainte: computerele au început să scrie corect în locul nostru:

• Algoritmii predictivi încearcă să ghicească următorul cuvânt, următoarea expresie, poate chiar un întreg răspuns la un mesaj text.
• Instrumentele de formatare automată încearcă să transforme asteriscurile, numerele și literele în liste, codurile scurte în caractere speciale și emoji etc.
• Instrumentele de dictare încearcă să recunoască ideile din context pentru a alege între omonime.

Și cine e de vină când toate acestea dau greș? Instrumentul!

Agregatoarele de social media adoră capturile de ecran jenante de tip „Nu asta am vrut să spun!”.

Editoria11y este un pas spre faza 2

La instruirile noastre vorbim mult despre testare și prezentăm câteva instrumente de testare destul de bune. Niciunul nu poate detecta totul: lucruri precum „evitarea explicării conceptelor prin referințe cromatice sau spațiale” trebuie verificate de un om; de obicei, instrumentele detectează puțin sub jumătate din problemele reale pe care le-ar putea avea un site. Dar se descurcă foarte bine la detectarea multor greșeli frecvente din conținutul editorial.

Există însă trei probleme:

1. Cele mai multe sunt instrumente manuale. Creatorul de conținut trebuie să fi învățat să le folosească, trebuie să-și amintească de existența lor când scrie conținutul și trebuie să-și amintească să le ruleze când termină. Aceste trei puncte de eșec se unesc pentru a lăsa mult (cea mai mare parte?) din conținut neverificat.
2. Semnalează prea multe. Nu marchează doar greșelile pe care tocmai le-a făcut autorul, ci și problemele de culoare lăsate de designer, problemele tehnice lăsate de dezvoltator, elemente de structură, cu scop informativ etc. Astfel, instruirea devine mai dificilă: autorii nu trebuie doar să înțeleagă instrumentul, ci și să învețe să ignore o listă de rezultate fals pozitive sau de lucruri foarte reale pe care nu este de datoria lor să le repare azi, în timp ce scriu acest articol anume.
3. Instrumentele automate urmează de obicei modelul „crawlezi site-ul, vizitezi panoul de control”. Din nou: se presupune că autorul a fost instruit să viziteze panoul de control și că își va aminti să o facă.

Așa că Princeton și-a propus să creeze ceva nou: un verificator automat, integrat în site, care să se uite doar la greșelile editoriale frecvente.

Automat înseamnă… dificil.

1. Verificatoarele automate trebuie să fie subtile: dacă sunt prea insistente, îl întrerup și îl frustrează pe autor. Dacă sunt prea politicoase, pot deveni un zgomot de fundal ușor de ignorat.
2. Verificatoarele automate trebuie să fie foarte performante: dacă pagina tresare sau ezită în timp ce rulează, autorii le vor detesta prezența și le vor dezactiva.
3. Verificatoarele automate au nevoie de sfaturi pe înțelesul începătorilor. Pentru mulți autori, va fi prima dată când aud despre etichetarea, structura și limbajul care le vor face conținutul mai accesibil. Alertele trebuie scrise într-un limbaj simplu, netehnic, cu sfaturi practice pentru îmbunătățirea conținutului.

Așa că am pornit de la instrumentul cel mai apropiat de aceste obiective pe care l-am putut găsi: Sa11y, creat la Toronto Metropolitan University. Am preluat arhitectura lui de testare și abordarea sa ușor de folosit, cu panou de informații și indicii, și am petrecut o jumătate de an adaptând instrumentul astfel încât testele să ruleze întotdeauna automat, optimizându-i performanța, ajustând indiciile și creând o listă lungă de opțiuni de configurare cu care un dezvoltator îl poate adapta rapid la orice platformă.

Iată cum arată astăzi:

Când un autor este autentificat pe site-ul său, comutatorul Editoria11y indică numărul și tipul problemelor (fără probleme, verificări manuale necesare, probleme probabile găsite) de pe fiecare pagină. Cu un clic poate afișa evidențierile și sfaturile direct în pagină. Dacă eroarea este nouă, pentru că se uită la o pagină pe care tocmai a editat-o, panoul se deschide automat.

În martie 2021, asta înseamnă că peste 400 de site-uri Princeton verifică automat:

• O structură bună a documentului
  • Niveluri de titlu sărite
  • Titluri goale
  • Titluri foarte lungi
  • Citate suspect de scurte, care ar putea fi de fapt titluri.
• Alternative text
  • Imagini fără text alt
  • Imagini care au ca text alt un nume de fișier
  • Imagini cu text alt foarte lung
  • Text alt care conține formulări redundante, precum „imagine cu” sau „fotografie cu”
  • Imagini din linkuri al căror text alt pare să descrie imaginea, nu destinația linkului
  • Vizualizări încorporate care necesită de obicei o alternativă text
• Linkuri cu sens
  • Linkuri fără text
  • Linkuri care au ca titlu un nume de fișier
  • Linkuri care au ca titlu doar un text generic: „faceți clic aici”, „aflați mai multe”, „descărcare” etc.
  • Linkuri care se deschid într-o fereastră nouă, fără pictogramă de link extern
• Asigurarea generală a calității
  • Asigurarea că se folosește formatarea de listă, nu asteriscuri, numere și litere
  • CANTITĂȚI MARI DE TEXT SCRIS CU CAPS LOCK
  • Tabele fără antete și tabele cu titluri de document („Titlu 3”) în locul antetelor de tabel (<th>)
  • Linkuri către PDF-uri și alte documente, cu un memento pentru utilizator să testeze accesibilitatea fișierului descărcabil sau să ofere un format alternativ, accesibil
  • Videoclipuri încorporate, cu un memento pentru utilizator să adauge subtitrări
  • Fișiere audio încorporate, cu un memento pentru utilizator să ofere o transcriere
  • Conținut încorporat din social media, cu un memento pentru utilizator să ofere elemente alt

Am pus biblioteca JavaScript la dispoziția comunității, am creat o integrare Drupal gata de utilizare și am început lucrul la o integrare WordPress gata de utilizare.

Spre faza 3: Accesibil în mod implicit

În multe privințe, Editoria11y este o soluție provizorie. Cele mai multe dintre greșelile pe care le detectează au apărut pentru că le-am impus autorilor de conținut așteptări noi („etichetați-vă conținutul cu o structură bună”), dar le-am dat instrumente care încurajau exact opusul.

Calea de urmat este să facem crearea de conținut accesibil mai ușoară și cât mai automată posibil. Cum va arăta asta nu este încă evident, dar probabil include lucruri precum:

• Regândirea opțiunilor disponibile. De exemplu: dacă tot le spunem utilizatorilor să nu alinieze textul la ambele margini pe Web, n-a venit oare vremea să pensionăm butonul „aliniere stânga-dreapta”?
• Regândirea opțiunilor implicite. De exemplu: tabelul implicit din cele mai multe sisteme de gestionare a conținutului nu are antete. Utilizatorului îi revine sarcina de a ști că trebuie să dea clic pe „proprietăți” și să adauge funcțiile de accesibilitate; poate e timpul să inversăm lucrurile?
• Explorarea formatării predictive și a „indiciilor în timpul lucrului”. Dacă un utilizator pune un rând întreg cu aldine, îi putem sugera să-l transforme în titlu? Dacă un utilizator vrea să aleagă un titlu, putem ghici ce nivel ar dori, în loc să-i oferim șase opțiuni? Putem oferi instruire exact la momentul potrivit pentru conceptele dificile?