Poate oricine să folosească aplicația ta construită cu AI? Un ghid simplu despre accesibilitate

Când construiești o aplicație cu AI, o testezi așa cum o folosești tu: pe ecranul tău, cu ochii tăi, cu priza ta sigură din două mâini pe laptop. Problema este că o parte reală dintre oamenii care îți vor deschide aplicația nu o folosesc așa. Cineva mărește textul telefonului la dublul dimensiunii normale. Cineva nu poate deosebi mesajul tău de eroare roșu de textul negru din jur. Cineva ține un bebeluș în brațe și apasă cu un singur deget mare. Accesibilitatea unei aplicații înseamnă pur și simplu dacă acești oameni pot totuși să treacă mai departe — și este o întrebare pe care majoritatea aplicațiilor construite cu AI nu și-o pun niciodată.

Nu ai nevoie de o diplomă sau de o echipă de conformitate ca să te ocupi de asta. Ai nevoie să știi cele patru sau cinci locuri unde aplicațiile îi exclud de obicei pe oameni și cum să-i ceri constructorului tău să le repare. Hai să-ți arăt cazurile obișnuite cu povești, fiindcă sunt mai ușor de recunoscut odată ce le-ai văzut.

De ce se strică layout-ul aplicației mele când cineva dă zoom?

Pentru că majoritatea aplicațiilor construite cu AI sunt gândite pentru o singură dimensiune fixă a textului, așa că atunci când cineva mărește textul pe telefon sau în browser — lucru pe care mulți oameni îl fac, mai ales cei peste șaizeci de ani — butoanele se suprapun, coloanele se prăbușesc într-o stivă amestecată, iar comenzile alunecă unele sub altele.

O creatoare pe care o cunosc a construit o aplicație ordonată de programări pentru salonul de coafură al mamei sale. Arăta grozav. Apoi mama ei a deschis-o și primul lucru pe care l-a făcut — la fel ca mulți oameni peste șaizeci de ani — a fost să apropie degetele pentru a mări textul. Layout-ul s-a destrămat. Butoanele se suprapuneau, butonul „Rezervă” aluneca sub meniu, iar o coloană de ore s-a transformat într-o stivă amestecată, imposibil de citit.

Aceasta este cea mai frecventă problemă de accesibilitate din aplicațiile construite cu AI și este invizibilă până când cineva dă zoom. Cere-i constructorului tău: „Asigură-te că layout-ul funcționează în continuare când textul este mărit la 200%. Nimic nu ar trebui să se suprapună sau să fie tăiat.” Apoi testează chiar tu — pe telefonul tău, mărește dimensiunea fontului din sistem la maximum și deschide aplicația. Dacă se destramă, acesta e primul lucru de reparat.

De ce nu ar trebui ca aplicația mea să folosească doar culoarea pentru a arăta starea?

Pentru că aproximativ unul din doisprezece bărbați percepe culorile diferit, cel mai frecvent roșu și verde — așa că o stare arătată doar printr-un punct roșu față de unul verde arată la fel pentru ei, și pur și simplu nu pot deosebi „plătit” de „restant”.

Un freelancer a construit un sistem de urmărire a facturilor care arăta starea doar prin culoare — punct verde, punct roșu. Unul dintre clienții săi, care se întâmpla să fie daltonist roșu-verde, tot plătea facturi deja achitate pentru că cele două puncte arătau identic pentru el. Informația exista. Doar că nu exista pentru el.

Rezolvarea este un obicei, nu o funcționalitate: nu folosi niciodată culoarea ca singurul mod de a comunica ceva. Adaugă un cuvânt, o iconiță sau o formă alături. „Restant” lângă roșu. O bifă lângă verde. Un asterisc și cuvântul „obligatoriu”, nu doar un contur roșu. Culoarea poate rămâne — doar că nu poate purta mesajul de una singură.

De ce cititoarele de ecran spun doar „buton” în loc să-l numească?

Pentru că un buton cu iconiță fără etichetă — un coș de gunoi, un creion, o lupă fără niciun cuvânt — nu are text pe care cititorul de ecran (programul folosit de persoanele nevăzătoare și cu deficiențe de vedere pentru a li se citi ecranul cu voce tare) să-l anunțe, așa că citește, literalmente, „buton”. Nu „șterge”. Nu „editează”. Doar „buton”.

Constructorii AI adoră butoanele curate cu iconițe pentru că arată modern. Dar imaginează-ți că folosești o aplicație în care fiecare comandă e numită „buton” și trebuie să ghicești. Nu trebuie să adaugi text vizibil la fiecare iconiță — trebuie să te asiguri că fiecare comandă are un nume dedesubt, chiar și unul invizibil pe care cititorul de ecran să-l poată anunța. Cere-i constructorului tău: „Dă fiecărui buton cu iconiță o etichetă accesibilă — o iconiță de coș de gunoi ar trebui anunțată ca «Șterge», un creion ca «Editează».” E o schimbare mică și face diferența dintre o aplicație pe care un utilizator nevăzător o poate naviga și una care e un zid de butoane anonime.

Cât de mari ar trebui să fie zonele de apăsare pe o aplicație mobilă?

Regula aproximativă folosită de designeri este că orice poate fi apăsat ar trebui să aibă în jur de 44 de pixeli — cam cât dimensiunea unui vârf de deget — cu spațiere reală, astfel încât două elemente apăsabile să nu fie înghesuite margine la margine.

Urmărește pe cineva folosind aplicația ta cu o singură mână, în autobuz. Degetele mari sunt late și imprecise, autobuzul se mișcă, iar „X”-ul tău pentru a închide e un punct de 16 pixeli în colț. Îl ratează de două ori, apasă din greșeală lucrul din spatele lui o dată și renunță. Zonele de apăsare mici și înghesuite sunt o problemă de accesibilitate, nu doar o supărare — lovesc cel mai tare oamenii cu tremurături, cu degete mai mari sau într-un mediu în mișcare. Cere-i constructorului tău: „Fă zonele de apăsare de cel puțin 44 de pixeli și adaugă spațiere între ele, ca oamenii să nu apese din greșeală pe altceva.” Apoi testează: deschide aplicația pe telefon și încearcă acțiunea principală cu o singură mână, mergând pe stradă. Dacă tot apeși greșit, la fel va face oricine altcineva.

Cum îmi testez aplicația pentru accesibilitate în cinci minute?

Poți descoperi majoritatea acestor probleme singur, fără niciun instrument, cu trei verificări rapide pe ecranul cel mai folosit:

1. Dă zoom. Mărește textul telefonului sau browserului la cea mai mare setare și deschide ecranul principal. Se suprapune ceva, dispare sau este tăiat?
2. Scoate culoarea. Uită-te la fiecare loc unde aplicația ta folosește culoarea pentru a însemna ceva — stare, erori, câmpuri obligatorii. Dacă îți imaginezi totul în gri, poți încă să-ți dai seama ce se întâmplă? Dacă nu, adaugă un cuvânt sau o iconiță.
3. Pornește cititorul de ecran timp de două minute. Atât iPhone (VoiceOver), cât și Android (TalkBack) au unul integrat. Pornește-l, închide ochii și încearcă să faci lucrul principal pentru care există aplicația ta. Vei auzi instant care butoane nu au nume.

Nimic din toate astea nu îți cere să fii dezvoltator. Îți cere să nu mai testezi ca tine timp de cinci minute și să testezi ca cineva ale cărui mâini, ochi sau ecran nu se potrivesc cu ale tale.

Nu trebuie să repari totul dintr-odată. Alege ecranul cel mai folosit — formularul de rezervare, înscrierea, lista principală — și fă-l să funcționeze bine când e mărit, fără culoare și citit cu voce tare. Acel singur ecran, făcut cum trebuie, acoperă mai mulți oameni decât un audit complet de accesibilitate al colțurilor pe care nimeni nu le vizitează. Începe de acolo, iar următoarea persoană care îți deschide aplicația cu un singur deget mare și ecranul mărit va putea fi un utilizator, nu doar cineva care renunță imediat.