Contentul (conținutul) web de astăzi este uimitor de bogat. Acesta variază de la standardul HTML la aplicațiile web complexe pline de medii, cum ar fi: animația, vizualizarea datelor, jocurile video, realitatea mixtă și VR. Un astfel de conținut este adesea inaccesibil sau slab accesibil, ceea ce înseamnă o încălcare a lucrului pentru utilizatorii care se bazează pe tehnologii de asistență pentru a interacționa cu site-urile web. Această experiență poate fi enervantă, în cel mai bun caz, pentru a goli paginile web. Uneori, autorii web oferă chiar și un conținut alternativ pentru acești utilizatori. Ce conținut alternativ pentru un joc video ar exista?
Site-urile web sunt inaccesibile nu numai datorită conținutului media bogat care este extrem de dinamic, ceea ce nu este deloc comod să-i descriem semantica, ci și pentru că nu există o tehnologie adecvată pe web pentru a exprima o astfel de semantică al contentului tehnologiilor assistive.
S-ar putea să vă întrebați de ce, cu toate tehnologiile de creare a conținutului web, nu avem una care să-l facă accesibil? Iată o explicație.
STANDARDE WEB
Cheia tehnologiei web pentru a face accesibilitatea conținutului este ARIA.
ARIA reprezintă o aplicație Rich Internet accesibilă. Acesta este un standard web, care definește o colecție de atribute pe care le puteți plasa pe un element DOM pentru a specifica rolul, proprietățile și starea. De exemplu, <div role = “button” aria-disabled> va transforma elementul HTML: div într-un buton dezactivat din punct de vedere semantic, ceea ce face ca utilizatorii tehnologiilor de asistență să perceapă elementul div ca un buton.
Este corect să spunem că ARIA este în general recunoscută ca un set complet de adnotări semantice disponibile pentru dezvoltatorii web. Cu alte cuvinte, ARIA formează vocabularul autorului web atunci când vine vorba de accesibilitate.
ARIA este într-adevăr o tehnologie remarcabilă și are o poveste bună de succes. Permite accesul unui număr mare de site-uri web. Este un moment important în această istorie: vocabularul ARIA clonează semantica HTML în mare parte. Cu siguranță, acesta oferă o grămadă de lucruri extraordinare, precum grilele sau controalele copacilor, dar nu vă permite să mergeți mult mai departe.
Deci, ce dacă aveți un caz de utilizare care cade HTML standard? În primul rând, puteți lucra la conținut alternativ care poate fi mapat în HTML. Puteți reuși sau nu, ceea ce depinde de complexitatea cazului dvs. În al doilea rând, puteți propune o extensie ARIA. Nu este așa de rău cum s-ar părea. Există precedente bune, de exemplu extensia ARIA-DPUB. Știu că este un proces lent, dar funcționează. Ar fi bine să ai o pondere bună în industrie, măcar pentru aceea ca să existe.
PLATFORM API: GLANCE LA ISTORIE
Vocabularul ARIA nu este singura problemă. Există o altă parte a puzzle-ului, interfața API nu este accesibilă și nu a fost vreodată proiectată pentru a expune un astfel de conținut nelimitat la tehnologiile de asistență.
Toate API-urile de accesibilitate își au rădăcini acum câteva decenii, când controalele JavaScript inaccesibile au fost o provocare unică de rezolvat. De-a lungul timpului, HTML-ul sa maturizat și a evoluat în HTML5, achiziționând o sumă mare de caracteristici noi. Acesta a cerut furnizorilor de acces API să ajusteze API-urile pentru a face accesibile noile caracteristici. De asemenea, s-au făcut eforturi pentru a face ca conținutul grafic să fie accesibil, cum ar fi desenele SVG și HTML. Cu toate acestea, majoritatea, dacă nu toate inițiativele, au fost pur și simplu inspirate de cazuri de utilizare asemănătoare HTML- codului.
În cazul conținutului non HTML, de exemplu, matematica, nu sa întâmplat nimic. Se pare că niciun furnizor de API nu a făcut mișcări decente pentru a aborda problema în general. Au existat câteva excepții notabile precum OS X API, care are proprietăți suplimentare pentru matematică, dar știi că excepția dovedește doar regula.
Poți să spui că se întâmplă totul pentru un motiv, cum ar fi faptul că nu există un mare interes pentru un conținut atât de redus – într-adevăr, este nevoie de un efort vicios pentru a împinge lucrurile înainte și există întotdeauna un pește mai mare pentru a-l prăji. Dar, faptul fapt ramâne: așteptările autorilor web nu au fost îndeplinite. În consecință, autorii web au încercat să reutilizeze cunoștințele existente pentru a expune conținutul de matematică, care se referea cel mai mult la generarea de adnotări citibile de om, ceva de genul “plus b împărțit la zero”. Ar fi exagerat să spun că este vorba de soluții greoaie, decât de soluții ordonate.
Desigur, s-au înregistrat progrese importante în ceea ce privește accesibilitatea web în ultimul deceniu. Cu toate acestea, tendința generală a fost aceea de a aduce expertiza existentă la noi platforme și tehnologii. Acesta a permis accesul la conținutul tradițional accesibil, însă a lăsat în cea mai mare parte neautorizate toate celelalte tipuri de conținut, atât celea de lungă durată, cât și celea noi, care au ieșit din urmă cu câțiva ani și s-au născut pe webul modern.
CONCEPTE DE ACCESIBILITATE
Toate API-urile de accesibilitate sunt construite în jurul unor concepte similar ( aceleași concept). Aceste concepte servesc pentru a permite autorilor să descrie și să identifice blocuri de conținut și să conecteze blocurile unul la celălalt. Browserul expune aceste blocuri la tehnologiile de asistență prin intermediul API-urilor de accesibilitate, iar tehnologiile de asistență le transformă într-un format pe care utilizatorii îl pot percepe, înțelege și opera.
Iată o scurtă trecere în revistă a conceptelor de accesibilitate din motive de furnizare a contextului. Puteți derula până la sfârșitul acestui capitol, dacă vă simțiți plictisit 🙂
Rolul este un concept de bază în descrierea semantică a unui bloc. Este o caracteristică primară a unui bloc și servește la identificarea tipului de bloc. De exemplu, acesta este un buton sau un paragraf. De asemenea, cuprinde un set de posibile proprietăți și stări și definește modele de comportament. De exemplu, acesta este un element de meniu selectat sau un câmp text care poate fi focalizat. Sau aceasta este o celulă de rețeaȘ are indici de rând și coloană, ceea ce ajută utilizatorul să navigheze în rețea. De asemenea, un bloc poate avea o etichetă care poate fi citită de om – primul lucru pe care utilizatorul îl va auzi, atunci când focalizarea se află pe bloc.
Un alt concept-cheie îl reprezintă relațiile care descriu conexiunile dintre blocuri, adică modul în care blocurile se leagă unul de celălalt. De exemplu, majoritatea blocurilor sunt conectate prin relațiile părinte-copil, cum ar fi grila și celulele rețelei. Sau un mesaj de eroare, afișat dacă utilizatorul a greșit o parolă, este conectat la un câmp de parolă. Relațiile permit utilizatorului să navigheze înainte și înapoi între blocuri în funcție de tipul de conținut și de starea sa la discreția utilizatorului.
Nu în ultimul rând, conceptul este o acțiune. Este un concept comportamental, folosit pentru a descrie interacțiunile pe care utilizatorul le poate lua asupra unui bloc. Dacă acesta este un buton, de exemplu, puteți să faceți clic pe el și așa mai departe.
Rezumativ, un bloc este descris de rol, stări și atribute, care permite utilizatorului să perceapă blocul. Acțiunile unui bloc permit utilizatorului să interacționeze cu conținutul, iar relațiile sunt pentru navigare.
De asemenea, conținutul web se poate schimba în timp, ceea ce înseamnă că blocurile pot fi create sau eliminate sau modificate, precum și relațiile dintre ele. Toate modificările sunt transmise tehnologiilor de asistență prin intermediul mecanismului de apariție a API-urilor de accesibilitate. Acesta nu este un concept de accesibilitate separat de 100%, dar este o parte integrantă care merită menționat pentru dragul unei conversații ulterioare.
LIMBĂ UNIVERSALĂ
S-ar părea surprinzător, dar aceste concepte sunt destul de universale pentru a descrie aproape orice fel de conținut, pe care îl puteți vedea astăzi pe web. Într-adevăr, atâta timp cât poți descrie conținutul prin cuvinte, poți potrivi aceste descrieri verbale în concepte de accesibilitate – tot ce ai nevoie este să numești obiecte, să le prezinți proprietățile, să definiți relațiile și să explicați cum să interacționați.
Aveți nevoie de un exemplu? Sigur. Spuneți că aveți o diagrama circulară- aceasta este ceva care scade standardul HTML, și de aceea, de obicei, trebuie să folosiți niște trucuri pentru a le face accesibile. Cu toate acestea, conceptele se potrivesc perfect aici. Într-adevăr, o diagram în sine este un rol, titlul său este o etichetă. O diagram este formată din sectoare, fiecare dintre ele are și un titlu, toate sectoarele fiind legate prin relații, definind care este următorul. Deci, utilizatorul poate citi o diagramă prin navigarea tuturor sectoarelor unul câte unul.
Sau, să luăm în considerare un joc video, unde un ursuleț de pluș vă învață niște dansuri. Ursul arată mișcări în dans. Camerele de supraveghere vă ține evidența poziției dvs. și evaluează cât de bine efectuați. Deci, în termeni de concepte, instrucțiunile ursului sunt blocuri cu un ciclu de viață limitat, cu etichete, care vă sunt relatate. Pozițiile membrelor reprezintă un alt set de blocuri care se caracterizează printr-o valoare scalară, cuprinsă între 0 și 100% și descriind cât de aproape ați fost într-o poziție dorită. Deci, așa cum dansează ursul, vi se spune “întoarceți călcâiul, trageți călcâiul” și când vă mișcați, veți auzi cât de perfectă a fost mișcarea voastră. De asemenea, puteți adăuga un factor de feedback aici, care va servi pentru a vă informa cum se pot îmbunătăți mișcările dvs., cum ar fi încercarea de a vă apleca mai departe data viitoare, etc.
Nu trebuie să vă limitați doar prin aceste exemple. Gândiți-vă să începeți crearea unui magazine online de foi de muzică? Veți avea nevoie să faceți muzică accesibilă, astfel încât utilizatorii de tehnologie asistivă să se poată bucura de ea. Aplicația dvs. web folosește formule de inele de chimie sau ecuații matematice sau orice altceva de la orice alt subiect despre care vă puteți gândi? Deci, puteți descrie cu siguranță toate simbolurile și formulele pentru prietenul dvs., astfel încât prietenul dvs. să le înțeleagă, nu? Astfel, ar trebui să puteți să le exprimați și în conceptele de accesibilitate. S-ar putea să doriți să le testați singuri pentru a vedea cum merge.
FORMA IDEIEI
Să ne întoarcem pe pământ.
Conceptele de accesibilitate au fost inventate cu ani în urmă, și în mod surprinzător sau nu, ele se potrivesc bine cu web-ul modern. Cu toate acestea, autorii web încă încearcă să facă aplicațiile web accesibile. Cum se întâmplă, vă întrebați ce bucată lipsește? Răspunsul este destul de simplu: autorii web nu au o tehnologie legală pentru a descrie conținutul web sau în termeni web, nu există nume și atribute adecvate pentru etichete JavaScript potrivite pentru a descrie semnificația conținutului. Deci, să presupunem că ați creat o aplicație web, care arată extraordinar și destul de utilă, dar creativitatea dvs. nu a fost limitată la standardul HTML. Sunt șanse ca mașina să nu aibă nicio idee despre ce este aplicația și, prin urmare, nu o poate transforma cu succes într-un format pe care tehnologia asistivă o poate digera.
Astfel, tehnologia cu care se confruntă web-ul pentru a descrie conținutul este o parte esențială, chiar dacă ați avut-o, ironia este că API-urile de accesibilitate nu au putut să o rezolve oricum, pentru că nu au fost proiectate să facă acest lucru.
Să rezumăm aceste două piese ale puzzlelui. Prima piesă este că autorul web are nevoie de un vocabular tehnic pentru a descrie sensul conținutului, iar al doilea, platformele ar trebui să aibă un mecanism de difuzare pentru a transmite aceste descrieri tehnologiilor de asistență.
Deci, cum ar arăta o tehnologie care să crawleze acest puzzle?
Să ne gândim cu voce tare. Spuneți că aveți o aplicație web grozavă sau că sunteți furnizor de conținut unic și cu siguranță că este special pentru a se încadra în standardul HTML. Apoi, desigur, puteți să-i explicați prietenilor, cum ar putea să-și folosească aplicația altfel? Apoi, ați introdus formularea în conceptele de accesibilitate de mai sus, ceea ce înseamnă, de asemenea, ruperea în blocuri într-un mod care poate fi procesat prin software.
Întregul punct în construirea de blocuri este că autorii web au nevoie de un control profund asupra lor – și acesta este exact ceea ce lipsește web-ul de astăzi. Desigur, dacă autorii creează conținut, atunci posibilitățile lor expresive de a explica conținutul nu ar trebui să fie restricționate prin tehnologii.
Să presupunem că autorii web obțin un adevărat instrument flexibil care le permite să jongleze blocurile de conținut așa cum doresc, atunci când autorul are sarcina de a defini noi roluri, stări, proprietăți și pentru a conecta blocurile unele cu altele prin orice relație. Apoi, toate acestea sunt transmise tehnologiilor de asistență prin API-urile de platformă (probabil că este singura cerință pentru API-uri de a putea transfera astfel de date). Și voilà, tot ce avem nevoie!
Furnizorul de conținut (un autor de web) cunoaște semnificația conținutului. Tehnologiile de asistență știu cum să prezinte conținutul utilizatorului și browserul știe cum să îl livreze tehnologiei de asistență.
În acest scenariu, browser-ul servește ca un pod care leagă autorul web și tehnologiile de asistență. Browserul nu trebuie neapărat să înțeleagă semantica conținutului care trece prin el. Browserul acționează ca un agent care face ca autorul și tehnologia de asistență să comunice direct.
Suna minunat? Da! Sună fantezist? Nu, dar furnizorii de browsere și API-uri ar trebui să depună eforturi pentru a face acest lucru.
Cred că webul are nevoie de o nouă tehnologie flexibilă și extensibilă pentru a da autorilor web controlul asupra conținutului pe care îl creează. Și aceasta va schimba web-ul pentru totdeauna!