Am folosit Web-ul pentru o zi folosind un cititor de ecran

Acest articol face parte dintr-o serie în care încerc să folosesc web-ul sub diferite constrângeri, reprezentând un anumit demografic al utilizatorului. Sper să ridic profilul dificultăților cu care se confruntă oamenii reali, care pot fi evitate dacă proiectăm și dezvoltăm într-un mod care să fie simpatic cu nevoile lor. Ultima dată, am navigat pe web pentru o zi doar cu tastatura. De data aceasta, evit ecranul și folosesc web-ul cu un cititor de ecran.

Ce este un cititor de ecran?

Un cititor de ecran este o aplicație software care interpretează lucrurile de pe ecran (text, imagini, linkuri și așa mai departe) și le convertește într-un format pe care persoanele cu deficiențe de vedere sunt capabile să le consume și cu care să interacționeze. Două treimi dintre utilizatorii cititorului de ecran aleg vorbirea ca rezultat al cititorului de ecran, iar o treime dintre utilizatorii cititorului de ecran aleg braille.

Cititoarele de ecran pot fi utilizate cu programe precum procesoare de text, clienți de e-mail și browsere web. Acestea funcționează prin maparea conținutului și a interfeței aplicației la un arbore de accesibilitate care poate fi apoi citit de cititorul de ecran. Unele cititoare de ecran trebuie să mapeze manual anumite programe în arbore, în timp ce altele sunt mai generice și ar trebui să funcționeze cu majoritatea programelor.

Pe Windows, cel mai popular cititor de ecran este JAWS, cu aproape jumătate din piața totală a cititoarelor de ecran. Este un software comercial, care costă în jur de o mie de dolari pentru ediția acasă. O alternativă open-source pentru Windows este NVDA, care este folosit de puțin sub o treime din toți utilizatorii de cititoare de ecran de pe desktop.

Există și alte alternative, inclusiv Microsoft Narrator , System Access , Window-Eyes și ZoomText (nu un cititor pe tot ecranul, ci o lupă de ecran care are abilități de citire); suma combinată a acestora echivalează cu aproximativ 6% din utilizarea cititorului de ecran. Pe Linux, Orca este inclus în mod implicit pe o serie de distribuții.

Cititorul de ecran inclus în macOS, iOS și tvOS este VoiceOver . VoiceOver reprezintă 11,7% dintre utilizatorii de cititoare de ecran desktop și ajunge la 69% dintre utilizatorii de cititoare de ecran de pe dispozitive mobile. Celelalte cititoare de ecran majore din spațiul mobil sunt Talkback pe Android (29,5%) și Voice Assistant pe Samsung (5,2%), care se bazează în sine pe Talkback, dar cu gesturi suplimentare.

Am un MacBook și un iPhone, așa că voi folosi VoiceOver și Safari pentru acest articol. Safari este browserul recomandat pentru utilizare cu VoiceOver, deoarece ambele sunt întreținute de Apple și ar trebui să funcționeze bine împreună. Utilizarea VoiceOver cu un browser diferit poate duce la comportamente neașteptate.

Cum să activați și să utilizați cititorul de ecran

Instrucțiunile mele sunt pentru VoiceOver, dar ar trebui să existe comenzi echivalente pentru cititorul de ecran ales.

VoiceOver pe desktop

Dacă nu ați mai folosit niciodată un cititor de ecran, poate fi o experiență descurajantă. Este un șoc cultural major să mergi la o experiență doar auditivă, iar a nu ști cum să controlezi atacul zgomotului este deranjant. Din acest motiv, primul lucru pe care veți dori să învățați este cum să îl opriți.

Comanda rapidă pentru dezactivarea VoiceOver este aceeași cu cea pentru activarea acestuia: ⌘ + F5 ( ⌘ este cunoscută și ca tasta Cmd ). Pe Mac-urile mai noi cu o bară tactilă, comanda rapidă este să țineți apăsată tasta de comandă și să apăsați de trei ori butonul Touch ID. VoiceOver vorbește prea repede? Deschideți utilitarul VoiceOver, apăsați fila „Vorbire” și ajustați rata în consecință.

Odată ce ați învățat să-l porniți și să-l dezactivați, va trebui să învățați să utilizați „tasta VoiceOver” (care este de fapt două taste apăsate în același timp): Ctrl și ⌥ (cea din urmă tastă este cunoscută și ca „Opțiune”. ” sau tasta Alt ). Folosind tasta VO în combinație cu alte taste, puteți naviga pe web.

De exemplu, puteți folosi VO + A pentru a citi pagina web din poziția curentă; în practică, aceasta înseamnă menținerea Ctrl + ⌥ + A . Amintirea a ceea ce corespunde VO este confuză la început, dar notația VO este pentru concizie și consecvență. Este posibil să configurați tasta VO să fie altceva, așa că are sens să aveți o notație standard pe care toată lumea să o poată urma.

Puteți folosi VO și tastele săgeată ( VO + → și VO + ← ) pentru a parcurge fiecare element din DOM în secvență. Când întâlniți un link, puteți folosi VO + Space pentru a face clic pe el - veți folosi aceste taste și pentru a interacționa cu elementele formularului.

Huza! Acum știți suficient despre VoiceOver pentru a naviga pe web.

VoiceOver pe mobil

Comanda rapidă pentru mobil/tabletă pentru pornirea VoiceOver variază în funcție de dispozitiv, dar este, în general, un „triplu clic” pe butonul de pornire (după activarea comenzii rapide în setări).

Puteți citi totul din poziția curentă cu o comandă Two-Finger Swipe Down și puteți selecta fiecare element din DOM în succesiune cu o Swipe Right or Left .

Acum știi la fel de multe despre iOS VoiceOver ca și desktop!

Navigarea după tipul de conținut

Gândiți-vă la modul în care utilizați web-ul ca utilizator văzător. Citiți fiecare cuvânt cu atenție, în ordine, de sus în jos? Nu. Oamenii sunt leneși prin design și au învățat să „scaneze” paginile pentru informații interesante cât mai repede posibil.

Utilizatorii de cititoare de ecran au aceeași nevoie de eficiență, așa că cei mai mulți vor naviga pe pagină după tipul de conținut, de exemplu, titluri, linkuri sau comenzi de formulare. O modalitate de a face acest lucru este să deschideți meniul de comenzi rapide cu VO + U , să navigați la tipul de conținut dorit cu tastele săgeți ← și → , apoi să navigați prin acele elemente cu tastele ↑↓ .

O altă modalitate de a face acest lucru este să activați „Navigare rapidă” (ținând apăsat ← împreună cu → în același timp). Cu Quick Nav activat, puteți selecta tipul de conținut ținând apăsată săgeata ↑ lângă ← sau → . Pe iOS, faci acest lucru cu un gest Two-Finger Rotate .

După ce ați selectat tipul de conținut, puteți sări peste fiecare element rotor cu tastele ↑↓ (sau Swipe Up or Down pe iOS). Dacă se pare că sunt multe de reținut, merită să marcați această foaie de truc VoiceOver super utilă pentru referință.

O a treia modalitate de a naviga prin tipurile de conținut este utilizarea gesturilor trackpad-ului. Acest lucru aduce experiența mai aproape de modul în care ați putea folosi VoiceOver pe iOS pe un iPad/iPhone, ceea ce înseamnă că trebuie să vă amintiți doar un set de comenzi pentru cititorul de ecran!

Puteți exersa navigarea bazată pe gesturi și multe alte tehnici VoiceOver în programul de antrenament încorporat pe OSX. Îl puteți accesa prin Preferințe de sistem → Accesibilitate → VoiceOver → Deschide Training VoiceOver.

După ce am terminat tutorialul, eram nerăbdător să plec!

Studiu de caz 1: YouTube

Căutând pe YouTube

Am navigat la pagina de pornire YouTube din bara de instrumente Safari, pe care VoiceOver mi-a spus să „intervin” în conținutul web cu Ctrl + ⌥ + Shift + ↓ . În curând m-aș obișnui să intru în conținutul web, deoarece același mecanism se aplică pentru conținutul încorporat și unele comenzi de formulare.

Folosind Quick Nav, am putut naviga prin comenzile formularului pentru a trece cu ușurință la secțiunea de căutare din partea de sus a paginii.

Am căutat conținut de calitate:

Și am navigat la butonul de căutare:

Totuși, când am activat butonul cu VO + Space , nu s-a anunțat nimic.

Am deschis ochii și căutarea a avut loc și pagina se populase cu rezultate, dar nu aveam de unde să știu doar prin audio.

Nedumerit, mi-am reprodus acțiunile cu devtools deschise și am ținut un ochi pe fila de rețea.

După cum se bănuiește, YouTube folosește o tehnică de performanță numită „redare pe partea clientului”, ceea ce înseamnă că JavaScript interceptează trimiterea formularului și redă rezultatele căutării la locul lor, pentru a evita să fie nevoie să picteze întreaga pagină. Dacă rezultatele căutării s-ar fi încărcat într-o pagină nouă ca un link normal, VoiceOver ar fi anunțat noua pagină pentru ca eu să navighez.

Există articole întregi dedicate accesibilității pentru aplicațiile redate de client; în acest caz, aș recomanda YouTube să implementeze o aria-live care să anunțe când trimiterea căutării are succes.

Sfat #1: Folosiți regiunile aria-live pentru a anunța modificări la nivelul clientului la DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

Acum că am înșelat și știam că trebuie să văd rezultatele căutării, am închis ochii și am navigat la primul videoclip cu rezultate, trecând la modul „titluri” al Quick Nav și apoi parcurgând rezultatele de acolo.

Redarea videoclipului pe YouTube

De îndată ce încărcați o pagină video YouTube, videoclipul se redă automat. Acesta este ceva pe care îl prețuiesc în utilizarea de zi cu zi, dar aceasta a fost o experiență dureroasă când a fost amestecată cu VoiceOver vorbind despre asta. Nu am putut găsi o modalitate de a dezactiva redarea automată pentru videoclipurile ulterioare. Tot ce puteam face a fost să încarc următorul videoclip și să apăs rapid CTRL pentru a opri anunțurile cititorului de ecran.

Sfat #2: oferiți întotdeauna o modalitate de a suprima redarea automată și amintiți-vă de alegerea utilizatorului.

Videoclipul în sine este tratat ca un „grup” în care trebuie să pășești pentru a interacționa. Am putut naviga pe fiecare dintre opțiunile din playerul video, de care am fost plăcut surprins - mă îndoiesc că așa era în zilele Flash!

Cu toate acestea, am constatat că unele dintre comenzile din player nu aveau etichetă, așa că „Modul cinema” era pur și simplu citit ca „buton”.

Sfatul #3: etichetați întotdeauna controalele formularului.

În timp ce utilizatorii de cititoare de ecran sunt predominant nevăzători, aproximativ 20% sunt clasificați drept „viziune redusă”, așa că pot vedea o parte din pagină. Prin urmare, un utilizator de cititor de ecran poate aprecia în continuare posibilitatea de a activa „Modul cinema”.

Aceste sfaturi nu sunt enumerate în ordinea importanței, dar dacă ar fi, acesta ar fi numărul meu numărul unu:

Sfatul #4: Utilizatorii de cititoare de ecran ar trebui să aibă paritate funcțională cu utilizatorii văzători.

Neglijând să etichetăm opțiunea „modul cinema”, excludem utilizatorii de cititoare de ecran dintr-o funcție pe care ar putea-o utiliza altfel.

Acestea fiind spuse, există cazuri în care o caracteristică nu va fi aplicabilă unui cititor de ecran - de exemplu, o diagramă cu linii SVG detaliată, care s-ar citi ca o ghicitură de numere fără context. În astfel de cazuri, putem aplica elementului atributul special aria-hidden="true" astfel încât să fie ignorat de cititorii de ecran cu totul. Rețineți că ar trebui totuși să furnizăm un text alternativ în afara ecranului sau un tabel de date ca alternativă.

Sfat #5: Folosiți aria-hidden pentru a ascunde conținut care nu este aplicabil utilizatorilor cititorului de ecran.

Mi-a luat mult timp să-mi dau seama cum să ajustez poziția de redare, astfel încât să pot derula înapoi o parte din conținut. După ce ați „intrat” în glisor ( VO + Shift + ↓ ), țineți apăsat ⌥ + ↑↓ pentru a ajusta. Mi se pare neintuitiv, dar din nou nu este prima dată când Apple ia decizii controversate privind comenzile rapide de la tastatură.

Redare automată la sfârșitul videoclipului YouTube

La sfârșitul videoclipului, am fost redirecționat automat către un videoclip nou, ceea ce era confuz - nu a avut loc niciun anunț.

Am învățat curând să navighez la comenzile Redare automată și să le dezactivez:

Acest lucru nu împiedică redarea automată a unui videoclip atunci când încarc o pagină video, dar împiedică acea pagină video să redirecționeze automat la următorul videoclip.

Studiu de caz 2: BBC

Întrucât știrile sunt ceva consumat pasiv, mai degrabă decât prin căutarea ceva anume, am decis să navighez pe BBC News după titluri. Este demn de remarcat faptul că nu trebuie să utilizați Quick Nav pentru aceasta: VoiceOver oferă comenzi de căutare a elementelor care pot economisi timp pentru utilizatorul cu putere. În acest caz, aș putea naviga în titluri cu tastele VO + ⌘ + H.

Primul titlu era notificarea privind cookie-urile, iar al doilea titlu era un <h2> intitulat „Legături de accesibilitate”. Sub acel al doilea titlu, primul link a fost un link „Săriți la conținut”, care mi-a permis să trec peste toate celelalte navigații.

Linkurile „Sriți la conținut” sunt foarte utile și nu doar pentru utilizatorii de cititoare de ecran; vezi articolul meu anterior „Am folosit web-ul pentru o zi doar cu o tastatură”.

Sfat #6: Furnizați linkuri „săriți la conținut” pentru utilizatorii dvs. de tastatură și cititoare de ecran.

Navigarea după titluri a fost o abordare bună: fiecare știre are propriul său titlu, așa că am putut să aud titlul înainte de a decide dacă să citesc mai multe despre o anumită poveste. Și, deoarece titlul în sine a fost înfășurat într-o etichetă de ancorare, nici nu a trebuit să schimb modurile de navigare când am vrut să dau clic; Aș putea doar VO + Spațiu pentru a încărca alegerea mea actuală a articolului.

În timp ce comanda rapidă de salt la conținut din pagina de pornire a fost legată frumos de o ancoră #skip-to-content-link-target (care apoi a citit titlul știrilor de top), linkul de omitere a paginii articolului a fost întrerupt. S-a legat la un alt ID ( #page ) care m-a dus la group care înconjoară conținutul articolului, în loc să citesc titlul.

În acest moment, am apăsat VO + A pentru ca VoiceOver să-mi citească întregul articol.

S-a descurcat destul de bine până când a ajuns în încorporarea Twitter, unde a început să devină destul de verbos. La un moment dat, a citit inutil „Link: 1068987739478130688”.

Acest lucru pare să se datoreze unui marcaj ușor dus în porțiunea de încorporare video a tweet-ului:

Se pare că VoiceOver nu citește atributul alt al imaginii imbricate și nu există alt text în interiorul ancorei, așa că VoiceOver face cel mai util lucru pe care îl știe: să citească o porțiune a URL-ului în sine.

Alte cititoare de ecran pot funcționa bine cu acest marcaj - kilometrajul dvs. poate varia. Dar o implementare mai sigură ar fi eticheta de ancorare care are o aria-label , sau un text ascuns vizual în afara ecranului, pentru a transporta textul alternativ. În timp ce suntem aici, probabil că aș schimba „Videoclip încorporat” cu ceva mai util, de exemplu „Videoclip încorporat: faceți clic pentru a reda”).

Problemele legate de legături nu erau acolo:

Sub conținutul principal al tweet-ului, există un buton de „like” care funcționează ca un contor de „like”. Din punct de vedere vizual, are sens, dar din perspectiva cititorului de ecran, nu există nici un context aici. Această experiență cu cititorul de ecran este proastă din două motive:

1. Nu știu ce înseamnă „1.887”.
2. Nu știu că făcând clic pe link, îmi va plăcea tweetul.

Utilizatorilor de cititoare de ecran ar trebui să li se ofere mai mult context, de exemplu „1.887 de utilizatori au apreciat acest tweet. Click pentru a da like.” Acest lucru ar putea fi realizat cu un text atent în afara ecranului:

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

Sfat #7: Asigurați-vă că fiecare link are sens atunci când este citit izolat.

Am mai citit câteva articole pe BBC, inclusiv un articol „forma lungă”.

Citirea articolelor mai lungi

Priviți următoarea captură de ecran dintr-un alt articol BBC - câte imagini diferite puteți vedea și care ar trebui să fie atributele lor alt ?

În primul rând, să ne uităm la imaginea din prim-plan a Lacului Havasu din centrul imaginii. Dedesubt are o legendă: „Lacul Havasu a fost creat după finalizarea barajului Parker în 1938, care a oprit râul Colorado”.

Este cea mai bună practică să oferiți un atribut alt chiar dacă este furnizată o legendă. Textul alt ar trebui să descrie imaginea, în timp ce legenda ar trebui să furnizeze contextul. În acest caz, atributul alt ar putea fi ceva de genul „Vedere aeriană a Lacului Havasu într-o zi însorită”.

Rețineți că nu ar trebui să alt textul alternativ cu „Imagine:”, sau „Imagine din” sau ceva de genul acesta. Cititoarele de ecran oferă deja acest context anunțând cuvântul „imagine” înainte de textul nostru alt . De asemenea, păstrați textul alt scurt (sub 16 cuvinte). Dacă este nevoie de un alt text mai lung, de exemplu, o imagine are mult text pe ea care trebuie copiat, priviți atributul longdesc .

Sfat #8: Scrieți texte alt descriptive, dar eficiente.

Din punct de vedere semantic, exemplul de captură de ecran ar trebui să fie marcat cu elemente <figure> și <figcaption> :

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

Acum să ne uităm la imaginea de fundal din acea captură de ecran (cea care transmite diverse pahare și echipamente). Ca regulă generală, imaginile de fundal sau de prezentare ca acestea ar trebui să aibă un atribut alt gol ( alt="" ), astfel încât VoiceOver să i se spună în mod explicit că nu există text alternativ și să nu încerce să-l citească.

Rețineți că un alt="" gol NU este același lucru cu a nu avea un atribut alt , care este un mare nu-nu. Dacă lipsește un atribut alt , cititoarele de ecran vor citi în schimb numele fișierelor de imagine, care adesea nu sunt foarte utile!

Sfat #9: Nu vă fie teamă să utilizați atribute alt goale pentru conținutul de prezentare.

Studiu de caz 3: Facebook

Mă îndrept acum pe Facebook și aveam simptome de sevraj de mai devreme, așa că am căutat mai mulți Jokeri nepractici .

Facebook duce lucrurile cu un pas sau doi mai departe decât celelalte site-uri pe care le-am încercat până acum și, în loc de un link „Skip to content”, avem nu mai puțin de două meniuri derulante care leagă la pagini sau, respectiv, la secțiuni de pagini.

Facebook definește, de asemenea, un număr de taste ca taste de comandă rapidă care pot fi utilizate de oriunde în pagină:

M-am jucat cu acestea și funcționează destul de bine cu VoiceOver - odată ce știi că sunt acolo. Singura problemă pe care o văd este că sunt proprietare (nu mă pot aștepta ca aceleași comenzi rapide să funcționeze în afara Facebook), dar este bine că Facebook încearcă din greu aici.

În timp ce prima mea impresie despre accesibilitatea Facebook a fost una bună, în curând am observat mici ciudatenii care au făcut site-ul mai greu de navigat.

De exemplu, am fost foarte confuz când am încercat să navighez pe această pagină prin titluri:

Primul titlu din pagină este un titlu de nivel 3, ascuns în bara laterală. Acesta este urmat imediat de nivelul șase de titlu în coloana de conținut principal, care corespunde unei stări care a fost partajată de pagină.

Acest lucru poate fi vizualizat cu pluginul Web Developer pentru Chrome/Firefox.

Ca regulă generală, este o idee bună să aveți titluri secvențiale cu o diferență nu mai mare de 1. Nu este un deal-breaker dacă nu o faceți, dar cu siguranță este confuz să veniți la asta din perspectiva cititorului de ecran și să vă îngrijorați că" am sărit din greșeală câteva informații importante deoarece ați sărit de la un h1 la un h6 .

Sfat #10: Validați-vă structura titlurilor.

Acum, pe partea de sus a site-ului: postările. Facebook înseamnă să păstrezi legătura cu oamenii și să vezi ce fac. Dar trăim într-o lume în care textul alt este un concept necunoscut pentru majoritatea utilizatorilor, așa că cum traduce Facebook acele selfie-uri îngâmfate și imagini cu câini unui public cititor de ecran?

Facebook are un generator automat de text alternativ care utilizează tehnologia de recunoaștere a obiectelor pentru a analiza ce (sau cine) este într-o fotografie și pentru a genera o descriere textuală a acesteia. Deci, cât de bine funcționează?

Textul alt pentru această imagine a fost „Imaginea poate conține: cer, iarbă și exterior.” Este departe de a recunoaște „Catedrala din Cambridge la amurg”, dar este cu siguranță un pas în direcția cea bună.

Am fost incredibil de impresionat de acuratețea unor descrieri. O altă imagine pe care am încercat-o a apărut ca „Imaginea poate conține: 3 persoane, inclusiv John Smith, Jane Doe și Chris Ashton, oameni zâmbind, în prim-plan și în interior” – foarte descriptiv și absolut corect!

Dar mă deranjează faptul că memele și glumele care devin virale pe rețelele sociale sunt inerent inaccesibile; Facebook tratează următoarele drept „Imaginea poate conține: pasăre și text”, ceea ce, deși adevărat este foarte departe de reprezentarea adevărată!

Din fericire, utilizatorii își pot scrie propriul text alt dacă doresc.

Studiu de caz 4: Amazon

Ceva ce am observat pe Facebook, se întâmplă și pe Amazon. Butonul de căutare apare înaintea câmpului de introducere a căutării în DOM. Asta în ciuda faptului că butonul apare vizual după câmpul de introducere.

Site-ul dvs. este probabil să fie într-o ordine logică din punct de vedere vizual. Ce se întâmplă dacă cineva ar muta aleatoriu părți ale paginii dvs. web – ar continua să aibă sens?

Probabil ca nu. Asta se poate întâmpla cu experiența dvs. de citire de ecran dacă nu sunteți disciplinat în ceea ce privește menținerea structurii DOM în sincronizare cu designul dvs. vizual. Uneori este mai ușor să mutați conținut cu CSS, dar de obicei este mai bine să îl mutați în DOM.

Sfat #11: faceți ca ordinea DOM să se potrivească cu ordinea vizuală.

De ce aceste două site-uri de profil înalt aleg să nu adopte acest ghid de bune practici cu navigarea lor de căutare mă deranjează. Cu toate acestea, butonul și textul de introducere nu sunt atât de îndepărtate, încât comanda lor să provoace o mare problemă de accesibilitate.

Titluri pe Amazon

Din nou, ca și Facebook, Amazon are o comandă ciudată de titluri. Am căutat prin titluri și am fost cel mai confuz că primul titlu din pagină era un titlu de nivel 5 din secțiunea „Alți vânzători pe Amazon”:

Am crezut că trebuie să fie o eroare cu cititorul de ecran, așa că am căutat codul sursă al Amazon pentru a verifica:

H1-ul paginii apare cu aproape 10.000 de linii mai jos în codul sursă.

Nu numai că acest lucru este slab din punct de vedere semantic și slab pentru accesibilitate, dar este și pentru SEO. SEO slab înseamnă mai puține conversii (vânzări) - ceva la care m-aș aștepta ca Amazon să fie foarte în vârf!

Sfatul #12: Accesibilitatea și SEO sunt două fețe ale aceleiași monede.

Multe din ceea ce facem pentru a îmbunătăți experiența cititorului de ecran va îmbunătăți, de asemenea, SEO. Titlurile valide din punct de vedere semantic și textul alt detaliat sunt excelente pentru crawlerele motoarelor de căutare, ceea ce ar trebui să însemne că site-ul dvs. se clasează mai bine în căutare, ceea ce ar trebui să însemne că veți atrage un public mai larg.

Dacă vă străduiți vreodată să vă convingeți managerul de afaceri că crearea de site-uri accesibile este importantă, încercați un alt unghi și subliniați în schimb beneficiile SEO.

Diverse

Este greu să condensați o zi de navigare și experiențe într-un singur articol. Iată câteva momente importante și lumini slabe care au făcut decupajul.

Veți observa site-urile lente

Cititoarele de ecran nu pot analiza pagina și își pot crea arborele de accesibilitate până când DOM-ul nu se încarcă. Utilizatorii văzători pot scana o pagină în timp ce se încarcă, determinând rapid dacă merită și apăsând butonul Înapoi, dacă nu. Utilizatorii cititorului de ecran nu au de ales decât să aștepte ca 100% din pagină să se încarce.

Este interesant de remarcat că, în timp ce realizarea unui site web performant aduce beneficii tuturor, este benefic în special pentru utilizatorii de cititoare de ecran.

Sunt de acord cu ce?

Controalele de formular ca acesta de la NatWest pot fi foarte dependente de apropierea spațială pentru a denota relații. În terenul cititorului de ecran, nu există o apropiere spațială - doar frați și părinți - și este nevoie de presupuneri pentru a ști la ce bifați „da”.

Aș fi știut cu ce sunt de acord dacă declinarea răspunderii ar fi făcut parte din etichetă:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

Urmărirea codului este un coșmar

Am încercat să citesc un articol tehnic despre trucuri CSS folosind cititorul meu de ecran, dar sincer, am găsit experiența total imposibil de urmărit. Aceasta nu este vina site-ului CSS Tricks – cred că este incredibil de complex să explici ideile tehnice și mostrele de cod într-un mod complet auditiv. De câte ori ați încercat să depanați cu un partener și, în loc să le explicați exact sintaxa de care aveți nevoie, le oferiți ceva de copiat și lipit sau o completați singur?

Uitați-vă cât de ușor puteți citi acest exemplu de cod din articol:

Dar iată versiunea cititorului de ecran:

slash slash primim mai întâi înălțimea ferestrei de vizualizare și o multiplicăm cu unu [pauză] la sută pentru a obține o valoare pentru o unitate vh lăsați vh egal cu înălțimea interioară a ferestrei stea [pauză] zero zero o bară oblică apoi setăm valoarea în [pauză] ] vh proprietate personalizată la rădăcina documentului document document element stil set proprietate [pauză] vh dolar acolade stânga vh acoladă dreapta px

Este total ilizibil în peisajul sonor. Tindem să nu avem semne de punctuație în comentarii și, în acest caz, o linie curge fără probleme în următoarea în terenul cititorului de ecran. Textul camelCase este citit ca cuvinte separate, ca și cum ar fi fost scrise într-o propoziție. Perioade precum window.innerHeight sunt ignorate și tratate ca „înălțimea interioară a ferestrei”. Singurul „cod” citit sunt parantezele de la sfârșit.

Codul este marcat folosind elemente HTML standard <pre> și <code> , așa că nu știu cum ar putea fi îmbunătățit acest lucru pentru utilizatorii cititorului de ecran. Oricine perseverează cu codificarea are admirația mea totală.

Altfel, singura greșeală pe care am putut-o găsi a fost că logo-ul site-ului avea un link către pagina de pornire, dar fără alt text, așa că tot ce am auzit a fost „link: slash”. Numai în calitatea mea de dezvoltator web știu că dacă aveți un link cu un atribut href="/" atunci vă duce la pagina de pornire a site-ului, așa că mi-am dat seama pentru ce era linkul - dar „link: trucuri CSS homepage” ar fi fost mai bine!

VoiceOver pe iOS este mai complicat decât OSX

Folosirea VoiceOver pe telefonul meu a fost o experiență!

Mi-am dat provocarea de a naviga prin aplicația Twitter și de a scrie un Tweet, cu ecranul oprit și folosind tastatura mobilă. A fost mai greu decât mă așteptam și am făcut o serie de greșeli de ortografie.

Dacă aș fi un utilizator obișnuit de cititor de ecran, cred că ar trebui să mă alătur celor 41% dintre utilizatorii de cititoare de ecran mobile care folosesc o tastatură externă și să investească într-o tastatură Bluetooth. Clara Van Gerven a ajuns la aceeași concluzie când a folosit un cititor de ecran timp de patruzeci de zile în 2015.

A fost destul de grozav să activați modul Screen Curtain cu o triplă atingere folosind trei degete. Acest lucru a dezactivat ecranul, dar a păstrat telefonul deblocat, astfel încât să pot continua să-mi răsfoiesc telefonul fără ca nimeni să mă uite. Această caracteristică este esențială pentru utilizatorii nevăzători care altfel ar putea să-și dea fără să vrea parolele persoanei care veghează peste umărul lor, dar are și un avantaj secundar de a fi excelent pentru economisirea bateriei.

rezumat

Aceasta a fost o experiență interesantă și provocatoare și cel mai greu articol al seriei de scris până acum.

Am fost surprins de micile lucruri care sunt evidente atunci când te oprești și te gândești la ele. De exemplu, atunci când utilizați un cititor de ecran, este aproape imposibil să ascultați muzică în același timp cu navigarea pe web! Păstrarea contextului paginii poate fi, de asemenea, dificilă, mai ales dacă ești întrerupt de un apel telefonic sau ceva de genul; când te întorci la cititorul de ecran, ți-ai cam pierdut locul.

Cea mai mare concluzie a mea este că există un mare șoc cultural în a merge la o experiență doar audio. Este o modalitate total diferită de a naviga pe web și, deoarece există un astfel de contrast, este dificil să știi ce înseamnă o experiență de citire a ecranului „bună” sau „rea”. Poate fi destul de copleșitor și nu este de mirare că mulți dezvoltatori evită testarea lor.

Dar nu ar trebui să evităm să o facem doar pentru că este greu. După cum a spus Charlie Owen în discursul ei, Dragă dezvoltator, Web-ul nu este despre tine : asta. Este. Ta. Job . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.