Să ne imaginăm, pentru un moment, că suntem nevoiți să navigăm pe platforma favorită cu ochii închiși sau vrem să urmărim un videoclip fără sunet. Pentru persoanele cu dizabilități, acest scenariu nu reprezintă un exercițiu, este modul prin care interacționează cu diferite produse, fie ele digitale sau fizice. Zilnic, numărul acestora este în jur de 1,3 miliarde la nivel global, adică aproximativ 16% din populație.
De-a lungul anilor, acest termen, accesibilitate, a devenit, mai mult sau mai puțin, un cuvânt la modă, nu doar în privința produselor digitale, prin introducerea de termeni precum: digital inclusion, universal design, inclusive design, WCAG compliant, accessibility ROI, digital equity, și altele. Pentru cititorii mai tech savvy, termenul de accesibilitate mai apare și sub abrevierea a11y. Introducerea atâtor termeni poate duce la confuzie și, de multe ori, chiar la diminuarea importanței și originii problemei inițiale.
Prin intermediul acestui articol, se va încerca evidențierea importanței subiectului accesibilității și de ce, chiar de anul acesta, 2025, nu va mai fi vorba doar de cuvinte la modă și termeni care să dea bine într-o prezentare. Totodată, informațiile prezentate vor ține cont de faptul că cititorul poate fi un om tehnic sau nu.
Când vorbim despre accesibilitate, fie că ne referim la un produs digital sau la produse fizice, acele lucruri sunt ușor de utilizat, ușor de înțeles, la îndemâna oricui, indiferent dacă dizabilitatea utilizatorului este permanentă, temporară sau situațională.
Exemple concrete pentru cele trei tipuri de dizabilități menționate anterior:
Situațională: într-un mediu cu lumină puternică, ecranul telefonului nu este suficient de puternic pentru a fi folosit;
Temporară: lipsa liftului la metrou face imposibilă ieșirea unei persoane cu membrele inferioare rupte;
Odată cu avansul tehnologic, este normal să ne imaginăm că eforturile de a elimina barierele accesului la diferite produse și servicii devine din ce în ce mai mare. Chiar dacă aceste eforturi au fost mici la început, acestea au ajuns a fi puse chiar și pe masa politicienilor pentru a fi implementate ca lege.
Eforturile de a face accesibile aplicațiile web sau produsele digitale în general au început încă din 1999. În aceste vremuri, mulți dintre noi nu aveau acces sau nici nu știam ce este acela un calculator și ce este internetul, după cum nu exista un standard bine definit cu privire la produse precum telefoane, televizoare, console de jocuri video etc.
Cei de la organizația World Wide Web Consortium, cunoscuți sub acronimul W3C, au fost pionierii accesibilității aplicațiilor web, aducând pe piață, în anul menționat în paragraful anterior, un set de reguli de urmat numit Web Content Accessibility Guidelines, cunoscute și sub acronimul WCAG. Acesta poate fi considerat chiar un efort de a standardiza lucrurile într-o eră haotică a tehnologiei și reprezintă documentul tehnic ce trebuie urmat în timpul implementării funcționalităților sau conceperii de noi platforme.
Eforturile acestui consorțiu nu s-au oprit acolo. Odată cu timpul și avansul tehnologic, acel set de reguli a trebuit adaptat la realitatea produselor disponibile pe piață. Mai jos se vor găsi câteva detalii despre fiecare iterație pentru WCAG:
Versiunea 1.0 din 1999
Avea un set de 14 reguli de urmat pentru prezentarea conținutului unei pagini web, raportat la limitările timpurilor;
Informația prezentată pe pagină trebuia afișată într-un mod coerent, adesea folosind tabele;
Recomandarea folosirii CSS;
Versiunea 2.0 din 2008
Cei 14 pași au fost condensați și reduși la doar patru principii de urmat: perceivable, operable, understandable, robust.
Se recomandă ca pagina să poată fi navigată folosind tastatura.
Videoclipurile ar trebui însoțite de subtitrări.
Versiunea 2.1 din 2018
Este o iterație a versiunii 2.0.
Navigarea pe pagină trebuie să fie coerentă.
Se recomandă folosirea mecanismelor de reautentificare fără interacțiunea utilizatorului.
Se descurajează forțarea utilizării unei singure metode de interacțiune cu pagina. Utilizatorul poate folosi ce dorește.
Versiunea 2.2 din 2023
Este o iterație a versiunii 2.1.
Un cititor atent poate recunoaște acele perioade ca anumite puncte cheie în care dezvoltarea aplicațiilor web a parcurs niște avansuri considerabile. Exemple: începutul și consolidarea JQuery în construirea paginilor web interactive, introducerea acelui set de breakpoints pentru diferite mărimi de ecrane și apariția Bootstrap, începutul dominanței telefoanelor mobile în interacțiunea de zi cu zi pe pagini web, introducerea HTML semantic, apariția tehnologiilor precum Angular și React etc.
Tot în spiritul standardizării, pe lângă setul de reguli menționat anterior, WCAG a introdus și trei criterii clare de clasificare pentru a stabili nivelul de accesibilitate al unei aplicații:
Nivel A. Exemple:
O aplicație web trebuie să fie utilizabilă și prin intermediul tastaturii;
Nivel AA. Exemple:
Contrastele de culori trebuie să respecte un minim de 4.5:1;
Elementul activ trebuie evidențiat;
Videoclipurile trebuie să aibă subtitrări;
Utilizarea elementelor semantice este obligatorie;
Nivel AAA. Exemple:
Un element nu trebuie să clipească mai mult de trei ori într-o secundă;
Videoclipurile nu pot fi întrerupte fără posibilitatea de a sări peste întrerupere;
Contrastul de culori este mai strict, adică 7:1;
Această inițiativă legislativă din partea Comisiei Europene reprezintă transpunerea în lege și, automat, obligativitatea respectării unor criterii clare pentru a nu îngrădi accesul diferitelor grupuri de persoane la diferite bunuri și servicii comercializate în spațiul European.
European Accessibility Act, cunoscut și sub acronimul EAA, nu este un document legislativ menit să ia companiile și diferite echipe de dezvoltare prin surprindere. A fost prezentat și pus în discuție, pentru prima dată, încă din 2015, urmând a fi semnat și adoptat abia în 2019. În introducere s-a menționat, succint, că devine obligatoriu din anul 2025, mai exact 28 iunie 2025. Asta înseamnă că a existat o perioadă de aproape șase ani în care diferitele produse și servicii să fie adaptate la noile constrângeri. Câteva exemple de produse și servicii vizate: servicii media, transport privat, servicii bancare, e-commerce, dispozitive electronice.
N.B. A nu se confunda cu Web Accessibility Directive, acesta fiind menit să introducă obligativitatea respectării unor criterii de accesibilitate de către sectorul public. EAA vizează produsele și serviciile comercializate, în spațiul european, de către mediul privat de afaceri. Aceste două acte pot fi considerate două fațete ale aceleiași monede, cu mențiunea că regulile sunt ceva mai stricte pentru sectorul privat. Nivelul minim de accesibilitate ce trebuie respectat este Nivelul AA, menționat în secțiunea anterioară.
Este evident că există și anumite excepții, care sunt scutite de respectarea acestor reguli, cum ar fi IMM-urile, însă, până și textul legislativ menționează că, totuși, recomandă respectarea criteriilor nu doar pentru a avea expunere la un public mai larg, ci și pentru evitarea eventualelor controale și amenzi în cazul evoluției și creșterii afacerii. Documentul legislativ, disponibil și în limba română, nu dă niște numere concrete în ceea ce ar însemna un IMM sau cifra lor de afaceri, din păcate.
Cel mai important lucru de avut în vedere în privința EAA este că acesta nu reprezintă un ghid tehnic de implementare al aplicațiilor. Doar descrie criteriile, excepțiile și cum ar trebui să se comporte un anumit produs pentru a fi considerat accesibil.
Probabil, cititorii cu cunoștințe tehnice se vor întreba: "încotro mă pot îndrepta pentru a ști exact ce să fac?". Răspunsul pentru această întrebare îl reprezintă un alt document, de data aceasta pur tehnic, numit EN 301 549. Pentru diferitele criterii de produse și servicii, se pot găsi pași clari și conciși ce trebuie urmați în implementare. Coincidență sau nu, acest document se folosește foarte mult de toate criteriile descrise în WCAG cât și de principiul POUR.
După cum vă puteți imagina, o situație de o asemenea complexitate nu este ușor de digerat, mai ales când unele companii sunt puse în fața faptului împlinit. La aceasta se adaugă și faptul că sunt implicate toate grupurile de persoane dintr-o companie: de la dezvoltatori, la UI/UX, până la management. Chiar dacă vorbim despre îmbunătățirea aplicațiilor existente, sau despre construirea unora noi, legile noi impuse pot aduce unele piedici.
În primul rând, timpul de dezvoltare va avea de suferit până când personalul se obișnuiește cu terminologia specifică și sunt urmărite toate criteriile, fie că este vorba despre personal tehnic sau non-tehnic. Este evident că vor exista și anumite bariere de comunicare în stadiile inițiale.
În al doilea rând, îmbunătățirile sau aplicațiile trebuie testate mai riguros. Asta implică timp adițional de muncă, termene mai lungi de livrare și poate chiar costuri adiționale din nevoia de procurare de licențe pentru unelte specifice. Cel mai răspândit program screen reader este JAWS, care se plătește. În timpul dezvoltării sau CI/CD se pot folosi uneltele din suita AXE, cum ar fi devtools, auditor și monitor, care implică costuri adiționale când vorbim de enterprise.
Nu în ultimul rând, poate chiar și cel mai important aspect este cel de comunicare între echipe pentru a ține sub vizor legislația și eventualele modificări ce pot fi aduse. Nu doar că lecturarea documentelor menționate anterior poate fi grea și de durată, dar nerespectarea legislației aduce după ea sancțiuni, care nu sunt tocmai binevenite. Acestor eforturi se mai pot adăuga și timpul petrecut, sau chiar și banii cheltuiți în plus, pentru traininguri sau certificări.
de Alex Popescu
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
