Bine, mai bine, cel mai bun: Descurcarea lumii complexe a modelelor accesibile

Marc Benioff a declarat în mod memorabil că singura constantă din industria tehnologiei este schimbarea. După ce am lucrat în tehnologie de peste 15 ani, pot confirma acest lucru. Colegii dinozauri tehnologici pot atesta că modul în care a funcționat web-ul în primele zile este drastic diferit decât ne-am fi imaginat mulți dintre noi.

În timp ce această schimbare constantă în industria tehnologiei a condus la inovații și progrese pe care le vedem astăzi, a introdus și conceptul de alegere. În timp ce alegerea - la suprafață - poate părea un lucru inerent pozitiv, nu este întotdeauna egală cu curcubee și trandafiri. Afluxul schimbărilor tehnologice aduce, de asemenea, fragmentarea limbajelor de codare și aromele nesfârșite ale programării „fierbinte”. Uneori, această abundență de alegere se transformă într-o alegere excesivă - o deficiență cognitivă bine studiată în care oamenii întâmpină dificultăți în a lua o decizie, deoarece au prea multe opțiuni.

În acest articol, vom încerca să descurcăm lumea complexă a tiparelor accesibile - pas la un moment dat. Vom începe lucrurile prin revizuirea modelelor și bibliotecilor accesibile actuale, apoi vom lua în considerare nevoile noastre generale și potențialele restricții și, în sfârșit, vom parcurge o serie de exerciții de gândire critică pentru a învăța cum să evaluăm mai bine modelele pentru accesibilitate.

Ce Web încâlcit țesem

Overchoice s-a strecurat în toate aspectele tehnologiei, inclusiv în modelele și bibliotecile pe care le folosim pentru a ne construi creațiile digitale - de la caseta de selectare simplă la modal dinamic complex și tot ce se află între ele. Dar de unde știm care model sau bibliotecă este cea potrivită când există atât de multe opțiuni? Este mai bine să folosiți modele/biblioteci stabilite pe care utilizatorii le întâlnesc în fiecare zi? Sau este mai bine să creați modele noi pentru o experiență de utilizator mai încântătoare?

Cu multitudinea de opțiuni disponibile, putem deveni rapid paralizați de supraabundența de opțiuni. Dar dacă facem un pas înapoi și luăm în considerare de ce ne construim produsele digitale în primul rând (adică utilizatorul final) nu are sens să alegem modelul sau biblioteca care poate adăuga cea mai mare valoare pentru cel mai mare număr de oameni ?

Dacă ați crezut că alegerea unui model sau a unei biblioteci este un proces deja destul de descurajant, acesta ar putea fi punctul în care începeți să vă îngrijorați. Dar nu trebuie să vă supărați – alegerea unui model/bibliotecă accesibilă nu este știință rachetă. Ca orice altceva în tehnologie, această călătorie începe cu puține cunoștințe, o grămadă imensă de încercări și erori și înțelegerea faptului că nu există doar un model/biblioteca perfectă care se potrivește fiecărui utilizator, situație sau cadru.

De unde știu asta? Ei bine, mi-am petrecut ultimii cinci ani cercetând, construind și testând diferite tipuri de modele accesibile în timp ce lucram la Ghidul de stil A11y, Biblioteca de modele ARIA a lui Deque și evaluam modele SVG populare. Dar, de asemenea, am revizuit multe modele de clienți și biblioteci pe fiecare cadru/platformă imaginabilă. În acest moment, pot spune fără scrupule că există o ierarhie înnăscută pentru accesibilitatea tiparelor care începe să se dezvolte atunci când privești suficient de mult. Și deși există ocazional modele de evitat cu orice preț, nu este întotdeauna atât de clar. Când vine vorba de accesibilitate, aș spune că majoritatea tiparelor se încadrează în gradiente de bine, mai bun, cel mai bun. Partea dificilă este să știi ce tipar aparține cărei categorii.

Gândirea critică la modele

Deci, cum știm care modele sunt bune, mai bune, mai bune când vine vorba de accesibilitate? Depinde. Această expresie adesea invocată de comunitatea de accesibilitate digitală nu este o renunțare, ci este prescurtarea pentru „avem nevoie de mai mult context pentru a vă putea oferi cel mai bun răspuns”. Cu toate acestea, contextul nu este întotdeauna clar, așa că atunci când construiesc și evaluez accesibilitatea unui model, câteva întrebări fundamentale pe care le pun includ:

• Există deja un model accesibil stabilit pe care îl putem folosi?
• Ce browsere și dispozitive cu tehnologie de asistență (AT) acceptăm?
• Există limitări ale cadrului sau alți integrări/factori de luat în considerare?

Desigur, întrebările dvs. specifice pot diferi de ale mele, dar ideea este că trebuie să începeți să vă folosiți abilitățile de gândire critică atunci când evaluați tiparele. Puteți face acest lucru prin observarea, analizarea și apoi clasarea fiecărui model pentru accesibilitate înainte de a trece la o decizie finală. Dar înainte de a ajunge la asta, să ne adâncim mai întâi în întrebările inițiale.

Există deja un model accesibil stabilit?

De ce se pare că, cu fiecare cadru nou, obținem un set complet nou de modele? Această reinventare constantă a roții cu noi alegeri de modele poate deruta și frustra dezvoltatorii, mai ales că de obicei nu este necesar să facă acest lucru.

Nu mă crezi? Ei bine, gândiți-vă astfel: dacă ne abonam la sistemul de proiectare atomică, înțelegem că mai mulți „atomi” mici de cod se unesc pentru a crea un produs digital mai mare. Dar în lumea științifică, atomii nu sunt cea mai mică componentă a vieții. Fiecare atom este format din multe particule subatomice precum protoni, neutroni și electroni.

Aceeași logică poate fi aplicată tiparelor noastre. Dacă ne uităm mai profund în toate modelele disponibile în diferitele cadre care există, structura subatomică de bază este în esență aceeași, indiferent de limbajul de codificare real folosit. Acesta este motivul pentru care apreciez bibliotecile de codare simplificate cu modele accesibile pe care le putem construi pe baza nevoilor tehnologice și de design.

Notă : Unele surse excelente de renume includ Componente inclusive, Componente accesibile și Sistemul de design Gov.UK, în plus față de lista de modele accesibile Smashing Magazine publicată recent (plus o listă mai detaliată de modele și biblioteci la sfârșitul articolului) .

Ce browsere și dispozitive cu tehnologie de asistență (AT) acceptăm?

După ce am cercetat câteva modele de bază care ar putea funcționa, putem trece la problema suportului pentru browser și tehnologie de asistență (AT). Pe cont propriu, suportul pentru browser nu este o glumă. Când adăugați dispozitive AT și specificații ARIA la amestec, lucrurile încep să devină complicate... nu imposibil, doar mult mai mult timp, efort și proces de gândire implicat pentru a înțelege totul.

Dar nu toate sunt vești proaste. Există câteva resurse fabuloase, cum ar fi accesibilitatea HTML5 și asistența pentru accesibilitate, care ne ajută să înțelegem mai bine browserul actual + suportul pentru dispozitivele AT. Aceste site-uri web subliniază diferitele subelemente de model HTML și ARIA disponibile, includ teste de comunitate open source și oferă câteva exemple de modele - atât pentru browsere desktop, cât și pentru dispozitive mobile/AT.

Există limitări ale cadrului sau alți integrări/factori de luat în considerare?

Odată ce am ales câteva modele de bază accesibile și am luat în considerare suportul pentru browser/dispozitiv AT, putem trece la întrebări contextuale mai detaliate despre model și mediul său. De exemplu, dacă folosim un model într-un sistem de management al conținutului (CMS) sau avem considerații de cod moștenit, vor exista anumite limitări ale modelului. În acest caz, o mână de opțiuni de model pot fi reduse rapid la unul sau două. Pe de altă parte, unele cadre sunt mai îngăduitoare și mai deschise să accepte orice tipar, astfel încât să ne putem îngrijora mai puțin cu privire la restricțiile cadrului și să ne concentrăm mai mult pe alegerea celei mai accesibile modele pe care o putem face.

Pe lângă tot ceea ce am discutat până acum, există multe considerații suplimentare de cântărit atunci când alegeți un model, cum ar fi performanța, securitatea, optimizarea motoarelor de căutare, traducerea limbii, integrarea terților și multe altele. Acești factori vor juca, fără îndoială, în alegerea dvs. de model accesibil, dar ar trebui să vă gândiți și la oamenii care creează conținutul. Modelul accesibil pe care îl alegeți trebuie să fie construit într-un mod suficient de robust pentru a gestiona orice limitări potențiale legate de conținutul generat de editor și/sau de utilizatori.

Evaluarea modelelor pentru accesibilitate

Codul vorbește adesea mai tare decât cuvintele, dar înainte de a trece la toate acestea, o notă rapidă că următoarele exemple de modele nu sunt singurele modele disponibile pentru fiecare situație și nici cel considerat „cel mai bun” din grup nu este cea mai bună opțiune din întreaga lume a tiparelor accesibile.

Pentru demonstrațiile de modele de mai jos, ar trebui să ne imaginăm o situație ipotetică în care comparăm fiecare grup de modele cu ei înșiși. Deși aceasta nu este o situație realistă, parcurgerea acestor exerciții de gândire critică și evaluarea tiparelor pentru accesibilitate ar trebui să vă ajute să fiți mai pregătiți atunci când întâlniți alegerea modelului în lumea reală.

Modele de butoane accesibile

Primul grup de modele pe care le vom examina pentru accesibilitate sunt omniprezente pentru aproape fiecare site web sau aplicație: butoanele. Primul model de buton folosește rolul butonului ARIA pentru a imita un buton, în timp ce al doilea și al treilea model de buton folosesc elementul HTML <button> . Al treilea model adaugă, de asemenea, aria-describedby și CSS pentru a ascunde lucrurile vizual.

Bun: role="button"

 <a role="button" href="[link]">Sign up</a>

Mai bine: <button>

 <button type="button">Sign up</button>

Cel mai bun: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Deși primele modele par simple la prima vedere, ele evocă unele întrebări de accesibilitate. De exemplu, pe primul model de buton, vedem că ARIA role="button" este folosit pe modelul „bun” în loc de un element HTML <button> . Gândind în termeni de accesibilitate, din moment ce știm că elementul HTML <button> a fost introdus în HTML4, putem specula în mod rezonabil că este pe deplin acceptat de cele mai recente versiuni ale tuturor browserelor majore și se va juca frumos cu majoritatea dispozitivelor AT. Dar dacă săpăm mai profund și ne uităm la suportul de accesibilitate pentru ARIA role=“button” vedem un ușor avantaj din perspectiva tehnologiei de asistență, în timp ce elementului HTML <button> îi lipsesc unele zone de acoperire browser + AT, mai ales când luăm în considerare suport pentru controlul vocal.

Atunci de ce modelul ARIA nu este în categoria „mai bună”? Nu ARIA o face mai accesibilă? Nu. De fapt, în astfel de cazuri, profesioniștii în accesibilitate recită adesea prima regulă a ARIA - nu utilizați ARIA. Acesta este un mod de a spune că folosiți elemente HTML ori de câte ori este posibil. ARIA este într-adevăr puternică, dar în mâini greșite, poate face mai mult rău decât bine. De fapt, raportul WebAIM Million afirmă că „paginile cu ARIA prezent au înregistrat în medie cu 60% mai multe erori decât cele fără”. Ca atare, trebuie să știți ce faceți când utilizați ARIA.

Un alt atac împotriva utilizării ARIA în această situație este că funcționalitatea butonului de care avem nevoie ar trebui să fie construită pentru modelul role="button" , în timp ce această funcționalitate este deja pre-coaptă în elementul <button> . Având în vedere că elementul <button> are, de asemenea, suport 100% pentru browser și este un model ușor de implementat, se află ușor înainte în ierarhie atunci când se evaluează primele două modele. Sperăm că această comparație ajută la spargerea mitului potrivit căruia adăugarea ARIA face un model mai accesibil - de multe ori este adevărat opusul.

Al treilea model de buton arată elementul HTML <button> cuplat cu aria-describedby legat de un element ID care este ascuns vizual cu CSS. Deși acest model este puțin mai complex, adaugă mult în ceea ce privește contextul prin crearea unei relații între buton și scop. Când avem îndoieli, oricând putem adăuga mai mult context situației, cu atât mai bine, așa că putem presupune că dacă este codificat corect, este cel mai bun model atunci când comparăm doar aceste modele specifice de butoane.

Modele de linkuri contextuale accesibile

Al doilea grup de modele pe care îl vom analiza sunt legăturile contextuale. Aceste modele ajută la furnizarea de mai multe informații utilizatorilor AT decât ceea ce este vizibil pe ecran. Primul model de legătură utilizează CSS pentru a ascunde vizual informațiile contextuale suplimentare. În timp ce al doilea și al treilea model de link adaugă atribute ARIA în amestec: aria-labelledby și, respectiv, aria-label .

Bun: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Mai bine: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Cel mai bun: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

În timp ce toate cele trei modele de legături contextuale arată la fel, atunci când inspectăm codul sau le testăm cu dispozitive AT, există unele diferențe evidente. Primul model folosește o tehnică CSS pentru a ascunde vizual conținutul pentru utilizatorii văzători, dar totuși redă conținutul ascuns utilizatorilor AT nevăzători. Și în timp ce această tehnică ar trebui să funcționeze în cele mai multe cazuri, nu există o relație reală formată între legătură și informațiile suplimentare, astfel încât conexiunea este în cel mai bun caz tentativă. Ca atare, primul model de link este o alegere OK, dar nu cel mai robust model de link dintre cele trei.

Următoarele două modele de link-uri sunt puțin mai dificil de evaluat. Conform specificațiilor ARIA de la W3C „Scopul aria-label este același cu cel al aria-labelledby . Oferă utilizatorului un nume ușor de recunoscut al obiectului.” Deci, în teorie, ambele atribute ar trebui să aibă aceeași funcționalitate de bază.

Cu toate acestea, specificațiile subliniază, de asemenea, că agenții de utilizator acordă prioritate aria-labelledby față aria-label atunci când decid ce nume accesibil să-l transmită utilizatorului. Cercetările au arătat, de asemenea, probleme legate de traducerea automată și atributele aria-label. Deci asta înseamnă că ar trebui să folosim aria-labelledby , nu?

Ei bine, nu atât de repede. Aceleași specificații ARIA continuă să spună „Dacă interfața este de așa natură încât nu este posibil să existe o etichetă vizibilă pe ecran (sau dacă o etichetă vizibilă nu este experiența dorită de utilizator), autorii ar trebui să folosească aria-label și nu ar trebui să folosește aria-labelledby .” Vorbiți despre confuzie - deci ce model ar trebui să alegem?

Dacă am avea nevoi de traducere pe scară largă, am putea decide să schimbăm aspectul vizual și să scriem linkurile cu contextul complet afișat (de ex. „ Citiți mai multe despre acest lucru minunat ”) sau să decidem să folosim aria-labelledby . Cu toate acestea, să presupunem că nu aveam nevoi de traducere la scară largă sau că am putea răspunde acestor nevoi într-un mod rezonabil/accesibil și nu am vrut să schimbăm aspectul vizual - ce atunci?

Pe baza recomandărilor actuale ARIA 1.1 (cu promisiunea de a traduce aria-label în ARIA 1.2) plus faptul că aria-label este puțin mai ușor de implementat de către dezvoltatori față aria-labelledby , am putea decide să ponderăm aria-label peste aria-labelledby în evaluarea modelului nostru. Acesta este un exemplu clar de când contextul cântărește foarte mult în alegerea noastră de model accesibil.

Modele <svg> accesibile

Nu în ultimul rând, dar cu siguranță nu în ultimul rând, să investigăm un grup de modele de imagini SVG pentru accesibilitate. SVG-urile sunt o reprezentare vizuală a codului, dar codul totuși. Aceasta înseamnă că un dispozitiv AT ar putea sări peste o imagine SVG non-decorativă, cu excepția cazului în care role="img" este adăugat la model.

Presupunând că următoarele modele SVG sunt de natură informațională, a fost inclus un role="img" în fiecare. Primul model SVG folosește <title> și <text> împreună cu CSS pentru a ascunde vizual conținutul de la utilizatorii văzători. Următoarele două modele SVG implică elementele <title> și <desc> , dar cu un atribut aria-labelledby adăugat la ultimul model.

Bine: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Mai bine: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Cel mai bun: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Să ne uităm mai întâi la primul model folosind <title> și <text> și CSS ascuns vizual. Spre deosebire de textul anterior vizibil ascuns în modele, există o relație inerentă între elementele <title> și <text> , deoarece acestea sunt grupate sub aceeași umbrelă de element SVG. Cu toate acestea, această relație nu este foarte puternică. De fapt, dacă te uiți înapoi la cercetările mele despre modelele SVG, vedem că doar 3 din 8 combinații browser/AT au auzit mesajul complet. (Notă: modelul de porc #1 este echivalent cu modelul de bec #7.)

Acest lucru este adevărat, deși specificațiile W3C SVG de lucru definesc elementul <text> ca „un element grafic format din text... caracterele care trebuie desenate sunt exprimate ca date de caractere. Drept urmare, datele text din conținutul SVG sunt ușor accesibile persoanelor cu deficiențe de vedere.” Acest prim model este OK, dar putem face mai bine.

Al doilea model elimină elementul <text> și îl înlocuiește cu un element <desc> . Specificațiile W3C SVG afirmă:

„Elementul copil <title> reprezintă o alternativă de text scurtă pentru element... iar elementul <desc> reprezintă informații textuale mai detaliate pentru element, cum ar fi o descriere.”

Înseamnă că elementele <title> și <desc> din SVG-uri pot fi folosite în mod similar textului alternativ al imaginii și opțiunilor de descriere lungă găsite în mod tradițional în elementele <img> . După adăugarea elementului <desc> la al doilea SVG, vedem compatibilitate similară pentru browser/AT, cu 3 din 8 combinații care aud mesajul complet. (Notă: Modelul de porc #2 este echivalent cu modelul de bec #10.) În timp ce aceste rezultate ale testelor par să oglindească primul model, motivul pentru care acest model ajunge la categoria „mai bună” este că este puțin mai ușor de implementat codul. înțelept și afectează mai mulți utilizatori AT, deoarece a funcționat pe JAWS, desktop VoiceOver și VoiceOver mobil, în timp ce primul model a acceptat combinații browser/AT mai puțin populare.

Al treilea model folosește din nou elementele <title> și <desc> , dar acum are un ID aria-labelledby plus adăugat în amestec. Conform acelorași teste SVG, adăugarea acestei piese suplimentare de cod înseamnă că putem accepta pe deplin 7 din 8 combinații browser/AT. (Notă: modelul Pig #3 este echivalent cu modelul becului #11.) Dintre cele trei modele SVG, acesta al treilea este „cel mai bun”, deoarece acceptă cele mai multe dispozitive AT. Dar acest model are un dezavantaj în utilizarea unor combinații browser/AT; veți auzi conținut duplicat al imaginii titlu/descriere pentru acest model. Deși este potențial enervant pentru utilizatori, aș spune că în general este mai bine să auzi conținut duplicat decât deloc.

Gânduri de închidere

Deși cu siguranță prețuim cu toții alegerea în tehnologie, mă întreb dacă am ajuns la un moment în care supraabundența de opțiuni ne-a lăsat paralizați și confuzi cu privire la ce să facem în continuare? În ceea ce privește alegerea modelelor accesibile, putem pune întrebări simple cu privire la opțiunile de modele/bibliotecă, suport pentru browser/dispozitiv AT, limitări ale cadrului și multe altele.

Cu datele potrivite în mână, la aceste întrebări este suficient de ușor de răspuns. Cu toate acestea, devine puțin mai complicat când trecem dincolo de tipare și luăm în considerare cu adevărat oamenii care le folosesc. Atunci ne dăm seama de impactul pe care alegerile noastre îl au asupra capacității utilizatorilor noștri de a reuși. După cum afirmă elocvent prof. George Dei:

„Incluziunea nu aduce oamenii în ceea ce există deja, ci face un spațiu nou, un spațiu mai bun pentru toată lumea.”

Luând puțin mai mult timp pentru a ne gândi critic la modele și a le alege pe cele mai accesibile, vom crea, fără îndoială, un spațiu mai incluziv pentru a ajunge la mai mulți utilizatori - în condițiile lor.

Resurse conexe

Instrumente

• Suport pentru accesibilitate, Michael Fairchild, a11ysupport.io
• Accesibilitate HTML5, Steve Faulkner

Biblioteci de modele

• Proiect de accesibilitate
• Ghid de stil pentru accesibilitate
• Componente accesibile, Scott O'Hara
• Plugin drag-and-drop listelor accesibil, Harris Schneiderman
• Biblioteca de modele ARIA a lui Deque
• Biblioteca React accesibilă a lui Deque
• Sistemul de proiectare GOV.UK
• Componente inclusive, Heydon Pickering
• Sistemul de proiectare web din SUA (USWDS)
• Tutoriale de accesibilitate web