🥇Pe calea către accesibilitate

Vinerea este sfârșitul zilei de lucru. Veștile proaste vin întotdeauna vineri, aproape de finalul zilei de muncă.

Te pregătești să părăsești biroul când un nou e-mail cu privire la o nouă reorganizare tocmai a sosit.

Mulțumesc xxxx, yyy, începând de astăzi vei raporta la zzzz.
…
Și echipa lui Hugh va asigura accesibilitatea produselor noastre pentru persoanele cu dizabilități.

Oh, nu! Ce am făcut să merit asta? Vor ca eu să plec? Mă pregătesc pentru o muncă grea, nerecunoscută, încercând să corectez greșelile altora. Asta va fi cu siguranță un eșec...

Așa era accesibilitatea cu câțiva ani în urmă. Câțiva săraci au obținut un loc de muncă pentru a "curăța" interfața utilizatorului, încercând să o facă accesibilă persoanelor cu dizabilități.

Ceea ce aceasta însemna, de fapt, era destul de vag – probabil dacă puteai vedea indicatorul de focus și să navighezi prin câmpuri folosind tasta Tab, să ai un text alternativ și câteva descrieri pentru câmpuri, aceasta ar fi fost considerată accesibilitate pentru aplicația ta...

Dar, brusc, „bug-urile” au început să apară cu o viteză uluitoare.

Diferite cititoare de ecran (engleză. Screen Readers) și browsere se comportau complet diferit.

Utilizatorii s-au plâns că aplicația nu este utilizabilă.

De îndată ce o eroare era corectată într-un loc, apărea alta în altă parte.

Și a schimba și corecta erorile interfeței utilizatorului necesită eforturi titanice.

Am fost acolo. Am supraviețuit, dar nu am „înaintat” – din punct de vedere tehnic am curățat mult, am adăugat multe descrieri pentru câmpuri, roluri și am atins un anumit nivel de conformitate, dar nimeni nu a fost fericit. Utilizatorii se plângeau în continuare că nu se pot descurca în aplicație. Managerul se plângea de un flux constant de erori. Inginerii se plângeau de o sarcină de lucru neclară, fără o „soluție corectă” bine definită care să funcționeze în toate cazurile.

Pe drumul meu către înțelegerea accesibilității, am întâlnit momente evident revelatoare.
Poate că primul pas a fost înțelegerea că adăugarea funcționalității de accesibilitate peste un produs deja finalizat este complicată. Și este și mai greu să convingi managerii că este incredibil de dificile! Nu, nu este vorba doar de „adăugat câteva etichete” și interfața utilizatorului va funcționa perfect. Nu, nu se poate încheia în trei săptămâni, nici măcar trei luni nu sunt suficiente.
Următorul meu moment de adevăr a venit atunci când am văzut cu ochii mei cum utilizatorii nevăzători folosesc de fapt aplicația noastră. Este COMPLET diferit de a vizualiza mesajele de eroare.

Mă voi întoarce la asta din nou și din nou, dar aproape toate „presupunerile” noastre despre cum oamenii au folosit aplicația noastră au fost greșite.

Navigarea printr-o interfață complexă folosind tastele Tab/Shift+Tab – este o mizerie! Trebuie să existe ceva mai bun. Combinări de taste, titluri.

Pierderea focului atunci când se schimbă UI nu este o problemă mare, nu-i așa? Să ne gândim din nou – este extrem de confuz.

Am continuat, am lucrat o vreme la diferite proiecte și apoi am început un nou proiect, cu o interfață complexă și o sarcină clară de a obține în sfârșit accesibilitatea corectă.

Așadar, am făcut un pas înapoi și am privit cum putem realiza acest lucru diferit și cu succes, și cum procesul de lucru poate fi amuzant!

Destul de repede am ajuns la unele concluzii:

Nu ne-am dorit ca persoanele care dezvoltă interfața utilizatorului să se chinuie cu etichete aria/roluri și, desigur, cu structura HTML a componentelor. Trebuia să le asigurăm componente corecte, în care accesibilitatea era implementată din cutie.
Accesibilitate == Ușurința utilizării – adică nu este doar o sarcină tehnică. Trebuia să schimbăm întregul proces de proiectare și să ne asigurăm că accesibilitatea este luată în considerare și discutată înainte de a începe proiectarea interfeței utilizatorului. Trebuie să gândim din timp cum utilizatorii pot descoperi orice funcționalitate, cum se vor deplasa și cum va funcționa „clic dreapta” cu tastatura. Accesibilitatea trebuie să fie o parte integrantă a procesului de design – pentru unii utilizatori, este mult mai mult decât aspectul aplicației.
De la început, am dorit să obținem feedback de la persoanele nevăzătoare și alte persoane cu dizabilități cu privire la ușurința de utilizare a aplicației.
Aveam nevoie de metode cu adevărat bune pentru a detecta regresiile în accesibilitate.

Ei bine, din punct de vedere ingineresc, prima parte suna destul de distractiv – dezvoltarea arhitecturii și implementarea bibliotecii de componente. Și într-adevăr a fost.

Făcând un pas înapoi, examinând exemplele ARIA și având în vedere acest lucru ca o problemă de design, nu ca o problemă de 'adaptare', am introdus unele abstracții. Componenta are o 'Structură' (formată din elemente HTML) și un 'Comportament' (cum interacționează cu utilizatorul). De exemplu, în fragmentele de mai jos avem o listă simplă neordonată. Când adăugăm 'comportament' la listă, se adaugă rolurile corespunzătoare pentru a funcționa ca o listă. Facem similar și pentru meniuri.

De fapt, aici se adaugă nu doar roluri, ci și handleri de evenimente pentru navigarea prin tastatură.

Acum arată mult mai ordonat. Dacă am putea obține o separare clară între ele, nu ar mai conta cum a fost creată structura, am putea aplica comportamentele (Behaviours) și am obține accesibilitate corectă.

Aceasta poate fi văzută în acțiune la https://stardust-ui.github.io/react/ – biblioteca UX React, care este proiectată și implementată având în vedere accesibilitatea încă de la început.

A doua parte – schimbarea abordării și proceselor în jurul designului m-a speriat inițial: inginerii modesti care încearcă să impună schimbări organizaționale nu se termină întotdeauna bine, însă aceasta s-a dovedit a fi una dintre cele mai interesante domenii în care am avut un impact semnificativ asupra procesului. Pe scurt, aveam următorul proces: noua funcționalitate era dezvoltată de o echipă, ulterior grupul nostru de lideri analiza/itera propunerea, iar apoi, după aprobat, designul era de obicei transferat echipei de ingineri. În acest caz, echipa de ingineri 'deținea' de fapt funcționalitatea de accesibilitate, deoarece trebuia să rezolve toate problemele asociate.

La început, aceasta a fost o muncă destul de dificilă – să explicăm că accesibilitatea și utilizabilitatea sunt inseparabile și că acest lucru trebuie realizat încă din faza de proiectare, altfel conduce la modificări semnificative și redefinirea unor roluri. Cu toate acestea, cu sprijinul conducerii și al jucătorilor cheie, am transmis această idee și am pus-o în aplicare, astfel încât designurile să fie verificate pentru accesibilitate și utilizabilitate înainte de a fi prezentate conducerii.

Și aceste feedback-uri au fost extrem de valoroase pentru toți – a fost fantastic, ca un exercițiu de schimb de cunoștințe/informare despre modul în care utilizatorii interacționează cu aplicațiile web, am identificat numeroase zone problematice ale interfeței utilizatorului înainte de a fi construite, iar echipele de dezvoltare au acum specificații mult mai bune, nu doar vizuale, ci și comportamentale. Discuțiile reale sunt discuții vesele, energice și pasionate despre aspectele tehnice și interacțiuni.

Am putea face această muncă și mai bine, dacă în aceste (sau viitoarele) întâlniri cu noi ar fi utilizatori nevăzători și utilizatori cu dizabilități – a fost greu de organizat, dar acum colaborăm cu organizații locale de nevăzători, precum și cu companii care oferă testare externă pentru verificarea fluxului de execuție în stadiile timpurii de dezvoltare – atât la nivel de componentă, cât și la nivel de flux de execuție.

Acum, inginerii au specificații destul de detaliate, componente accesibile pe care le pot utiliza pentru implementare și o modalitate de a verifica fluxul de execuție. Parțial, experiența ne-a învățat ce am omis constant – cum putem opri regresia. În mod similar, oamenii pot folosi teste de integrare sau teste end-to-end pentru a verifica funcționalitățile de care avem nevoie pentru a detecta modificările în interacțiuni și fluxuri de execuție – atât vizuale, cât și comportamentale.

Definirea regresiei vizuale este o sarcină destul de specifică, foarte puțin se poate adăuga la acest proces, în afară de, poate, verificarea dacă este vizibilă centrarea în timpul navigării cu ajutorul tastaturii. Două tehnologii relativ noi pentru a lucra cu accesibilitatea sunt mai interesante.

Accessibility Insights este un set de instrumente care pot fi utilizate atât în browser, cât și în cadrul ciclului de construcție/testare, pentru a identifica problemele.
Verificarea funcționalității software-ului de citire a ecranului a fost o sarcină deosebit de dificilă. Odată cu introducerea accesului la Accessibility DOM, am obținut în sfârșit posibilitatea de a face capturi ale aplicației din punct de vedere al accesibilității, foarte asemănătoare cu modul în care le facem pentru testele vizuale, și de a le verifica pentru regresie.

Așadar, în a doua parte a povestirii – am trecut de la modificarea codului HTML la lucrul la un nivel de abstractizare mai înalt, am schimbat procesul de dezvoltare a designului și am implementat testarea riguroasă. Procese noi, tehnologii noi și noi niveluri de abstractizare au schimbat complet percepția despre accesibilitate și despre ce înseamnă să lucrezi în acest domeniu.
Dar acesta este doar începutul.

Următoarea "înțelegere" este că utilizatorii cu deficiențe de vedere promovează tehnologii de vârf – ei sunt cei care beneficiază cel mai mult nu doar de modificările descrise anterior, ci și de faptul că noi abordări și idei devin posibile cu ajutorul ML/AI. De exemplu, tehnologia Immersive Reader permite utilizatorilor să prezinte textul mai simplu și mai clar. Acesta poate fi citit cu voce tare, structura propoziției este împărțită gramatical, iar chiar și semnificațiile cuvintelor sunt afișate grafic. Aceasta nu se încadrează deloc în vechea înțelegere de "a-l face accesibil" – este o funcție de utilizare care va ajuta pe toată lumea.

Cu ML/AI apar modalități complet noi de interacționare și lucru, și suntem încântați să facem parte din etapele următoare ale acestui parcurs inovator. Inovațiile sunt dictate de schimbarea gândirii – umanitatea a existat de mii de ani, mașinile de sute de ani, site-urile web de câteva zeci de ani, iar smartphone-urile și mai puțin, tehnologia trebuie să se adapteze la oameni, nu invers.

P.S. Articolul a fost tradus cu unele abateri minore de la original. Fiind coautor al acestui articol, am convenit asupra acestor abateri cu Hugh.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.