Vineri este sfârșitul zilei de lucru. Veștile proaste vin întotdeauna la sfârșitul zilei de lucru de vineri.
Sunteți pe cale să părăsiți biroul, tocmai a sosit prin poștă o nouă scrisoare despre o altă reorganizare.
Mulțumesc xxxx, yyy de astăzi vei raporta zzzz
...
Și echipa lui Hugh se va asigura că produsele noastre sunt accesibile persoanelor cu dizabilități.
Oh nu! De ce am meritat asta? Vor ei să plec? Pregătește-te pentru o muncă grea ingrată și să încerci să corectezi greșelile altora. Acesta este cu siguranță un eșec...
Aceasta a fost disponibilitatea acum câțiva ani. Unor suflete sărace au primit sarcina de a „curăța” interfața de utilizare pentru a încerca să o facă accesibilă persoanelor cu dizabilități.
Ceea ce însemna acest lucru de fapt a fost destul de vag - probabil că dacă ați putea vedea un indicator de focalizare și ați putea fila prin câmpuri, ați avea un text alternativ și câteva descrieri de câmp, s-ar considera că aplicația dvs. este accesibilă...
Dar dintr-o dată „buburile” au început să se înmulțească cu viteza unei avalanșe.
Diverse cititoare de ecran (Ing.. Cititoarele de ecran) și browserele s-au comportat complet diferit.
Utilizatorii s-au plâns că aplicația este inutilizabilă.
De îndată ce o eroare a fost corectată într-un loc, a apărut alta în altul.
Și simpla schimbare și corectare a erorilor de interfață cu utilizatorul a necesitat eforturi herculeene.
Am fost acolo. Am supraviețuit, dar nu am „reușit” - din punct de vedere tehnic am curățat mult, am adăugat multe descrieri de câmpuri, roluri și am atins un anumit nivel de conformitate, dar nimeni nu a fost mulțumit. Utilizatorii s-au plâns în continuare că nu pot naviga în aplicație. Managerul încă s-a plâns de fluxul constant de erori. Inginerii s-au plâns că problema a fost pusă incorect, fără o soluție „corectă” clar definită care să funcționeze în toate cazurile.
Au fost câteva momente hotărât de deschidere a ochilor de-a lungul călătoriei mele spre înțelegerea accesibilității.
Poate că prima a fost realizarea faptului că adăugarea funcționalității de accesibilitate peste un produs finit a fost dificilă. Și este și mai greu să-i convingi pe manageri că este incredibil de dificil! Nu, nu este doar „adăugați câteva etichete”, iar interfața de utilizare va funcționa bine. Nu, acest lucru nu poate fi finalizat în trei săptămâni, nici măcar trei luni nu vor fi suficiente.
Următorul meu moment al adevărului a venit când am văzut direct cum utilizatorii orbi au folosit aplicația noastră. Acest lucru este atât de diferit de a privi mesajele de eroare.
Voi reveni la asta din nou și din nou, dar aproape toate „ipotezele” noastre despre modul în care oamenii au folosit aplicația noastră au fost greșite.
Navigarea într-o interfață de utilizator complexă folosind apăsarea tastelor Tab/Shift+Tab – asta e nasol! Avem nevoie de ceva mai bun. Comenzi rapide de la tastatură, anteturi.
Pierderea concentrării la schimbarea interfeței de utilizare nu este o problemă mare, nu-i așa? Să ne gândim din nou - acest lucru este incredibil de confuz.
Am continuat, am lucrat la diferite proiecte o vreme, apoi am început un nou proiect, cu o interfață de utilizator complexă și o instalare clară, pentru a obține în sfârșit accesibilitatea corectă de data aceasta.
Așadar, am făcut un pas înapoi și am analizat cum am putea implementa acest lucru diferit și să reușim și să facem procesul mai puțin plictisitor!
Destul de repede am ajuns la câteva concluzii:
- Nu am vrut ca oamenii care dezvoltă interfața cu utilizatorul să se încurce cu etichetele/rolurile ariei și, bineînțeles, cu structura HTML a componentelor. Trebuia să le furnizăm componentele potrivite care au creat accesibilitatea imediat din cutie.
- Accesibilitate == Ușurință în utilizare – de exemplu Aceasta nu este doar o provocare tehnică. Trebuia să schimbăm întregul proces de proiectare și să ne asigurăm că accesibilitatea a fost luată în considerare și discutată înainte de a începe proiectarea UI. Trebuie să vă gândiți din timp la modul în care utilizatorii vor descoperi orice funcționalitate, cum vor naviga și cum va funcționa făcând clic dreapta de pe tastatură. Accesibilitatea ar trebui să fie o parte integrantă a procesului de proiectare - pentru unii utilizatori, este mult mai mult decât aspectul aplicației.
- De la bun început, am dorit să obținem feedback de la utilizatori nevăzători și alți utilizatori cu dizabilități despre ușurința de utilizare a aplicației.
- Aveam nevoie de modalități foarte bune de a surprinde regresiile de accesibilitate.
Ei bine, din punct de vedere ingineresc, prima parte a sunat destul de distractiv - dezvoltarea unei arhitecturi și implementarea unei biblioteci de componente. Și într-adevăr așa a fost.
Făcând un pas înapoi, privind și gândindu-ne la aceasta ca o problemă de proiectare mai degrabă decât o problemă de „potrivire”, am introdus câteva abstractizări. O componentă are o „Structură” (constă din elemente HTML) și un „Comportament” (cum interacționează cu utilizatorul). De exemplu, în fragmentele de mai jos avem o listă simplă neordonată. Adăugând „comportamente”, rolurile corespunzătoare sunt adăugate la listă pentru a face ca aceasta să acționeze ca o listă. Facem același lucru pentru meniu.
De fapt, aici nu sunt adăugate doar roluri, ci și handlere de evenimente pentru navigarea cu tastatură.
Asta pare mai îngrijit. Dacă am putea obține o separare clară între ele, nu ar conta cum a fost creată structura, am putea aplica Comportamente și să obținem accesibilitatea corectă.
Puteți vedea acest lucru în acțiune la – Biblioteca UX , care este conceput și implementat având în vedere accesibilitatea încă de la început.
A doua parte - schimbarea abordării și a proceselor în jurul designului m-a speriat inițial: inginerii modesti care încearcă să treacă prin schimbarea organizațională nu se termină întotdeauna bine, dar s-a dovedit a fi unul dintre cele mai interesante domenii în care am adus contribuții semnificative la proces. . Pe scurt, procesul nostru a fost după cum urmează: o nouă funcționalitate va fi dezvoltată de o echipă, apoi echipa noastră de conducere va revizui/itera propunerea și apoi, odată aprobată, proiectul va fi de obicei predat echipei de ingineri. În acest caz, echipa de ingineri „deținea” efectiv funcționalitatea de accesibilitate, deoarece era responsabilitatea lor să remedieze orice probleme asociate cu aceasta.
La început, a fost o muncă destul de dificilă de explicat că accesibilitatea și uzbilitatea sunt indisolubil legate și că acest lucru trebuia făcut în faza de proiectare, altfel ar duce la schimbări mari și redefiniri ale unor roluri. Cu toate acestea, cu sprijinul managementului și al jucătorilor cheie, am luat ideea și am pus-o în mișcare, astfel încât design-urile să fie testate pentru accesibilitate și utilizare înainte de a fi prezentate conducerii.
Și acest feedback a fost extrem de valoros pentru toată lumea - a fost fantastic ca exercițiu de partajare a cunoștințelor/comunicare despre modul în care utilizatorii interacționează cu aplicațiile web, am identificat numeroase zone cu probleme ale UI înainte de a fi construite, echipele de dezvoltare au acum specificații mult mai bune pentru a nu doar aspecte vizuale, dar și comportamentale ale designului. Discuțiile adevărate sunt discuții distractive, energice, pasionale despre aspecte tehnice și interacțiuni.
Am putea face acest lucru și mai bine dacă am avea utilizatori nevăzători și cu dizabilități la aceste întâlniri (sau ulterioare) - acest lucru a fost dificil de organizat, dar acum lucrăm atât cu organizații locale de nevăzători, cât și cu companii, care oferă teste externe pentru a verifica fluxul de execuție la începutul anului. dezvoltare — atât la nivel de componentă, cât și la nivelul fluxului de execuție.
Inginerii au acum specificații destul de detaliate, componente disponibile pe care le pot folosi pentru a le implementa și o modalitate de a valida fluxul de execuție. O parte din ceea ce ne-a învățat experiența este ceea ce ne-a lipsit de-a lungul timpului – cum putem opri regresia. De asemenea, oamenii pot folosi teste de integrare sau end-to-end pentru a testa funcționalitatea, de care avem nevoie pentru a detecta schimbări în interacțiuni și fluxuri de execuție – atât vizuale, cât și comportamentale.
Determinarea regresiei vizuale este o sarcină destul de definită, există foarte puține lucruri care pot fi adăugate procesului, în afară de verificarea dacă focalizarea este vizibilă atunci când navigați cu tastatura. Mai interesante sunt două tehnologii relativ noi pentru lucrul cu accesibilitatea.
- este un set de instrumente care pot fi rulate atât în browser, cât și ca parte a ciclului de construire/test pentru a identifica problemele.
- Verificarea faptului că cititoarele de ecran funcționează corect a fost o sarcină deosebit de dificilă. Odată cu introducerea accesului la Accesibilitate DOM, suntem în sfârșit capabili să facem instantanee de accesibilitate ale aplicației, la fel cum facem pentru testele vizuale, și să le testăm pentru regresie.
Deci, în a doua parte a poveștii, am trecut de la editarea codului HTML la lucrul la un nivel superior de abstractizare, am schimbat procesul de dezvoltare a designului și am introdus testarea amănunțită. Noile procese, noile tehnologii și noile niveluri de abstractizare au schimbat complet peisajul accesibilității și ce înseamnă să lucrezi în acest spațiu.
Dar acesta este doar începutul.
Următoarea „înțelegere” este că utilizatorii nevăzători conduc tehnologia de ultimă oră – ei sunt cei care beneficiază cel mai mult nu numai de pe urma schimbărilor pe care le-am descris mai devreme, ci și că noi abordări și idei sunt posibile prin ML/AI. De exemplu, tehnologia Immersive Reader permite utilizatorilor să prezinte textul mai ușor și mai clar. Poate fi citit cu voce tare, structura propoziției este defalcată din punct de vedere gramatical și chiar și semnificațiile cuvintelor sunt afișate grafic. Acest lucru nu se încadrează deloc în vechea mentalitate „fa-l accesibil” - este o caracteristică de utilizare care va ajuta pe toată lumea.
ML/AI permite modalități complet noi de interacțiune și lucru și suntem încântați să facem parte din următoarele etape ale acestei călătorii de ultimă oră. Inovația este condusă de o schimbare de gândire - umanitatea există de milenii, mașinile de sute de ani, site-urile web de câteva decenii și cu atât mai puțin smartphone-urile, tehnologia trebuie să se adapteze oamenilor și nu invers.
PS Articolul a fost tradus cu mici abateri de la original. În calitate de coautor al acestui articol, am fost de acord cu Hugh asupra acestor digresiuni.
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Acordați atenție accesibilității aplicațiilor dvs.?
-
Da
-
Nu
-
Este prima dată când aud despre accesibilitatea aplicațiilor.
Au votat 17 utilizatori. 5 utilizatori s-au abținut.
Sursa: www.habr.com