5 pași pentru a proiecta aplicații având în vedere accesibilitatea tastaturii

Când ne gândim la utilizatorul „mediu”, avem tendința de a-i imagina folosind un mouse sau un trackpad atunci când sunt pe computerul lor. Dar, ce se întâmplă dacă opțiunea lor preferată sau singura ar fi să folosească o tastatură? V-ați gândit să vă proiectați aplicațiile ținând cont de accesibilitatea tastaturii?

Există multe motive pentru care cineva ar putea să nu vrea sau să nu poată opera un mouse sau un trackpad pentru a-și folosi computerul. Ei pot avea afecțiuni permanente, cronice sau temporare care le limitează dexteritatea sau controlul muscular, provocând sensibilitate la încheieturile mâinilor sau la mâini sau făcând dificilă urmărirea cursorului mouse-ului pe un ecran. Ar putea fi, de asemenea, „utilizatori puternici” care caută mai multe comenzi rapide pentru a-și eficientiza fluxurile de lucru. În oricare dintre aceste cazuri, tastaturile ar putea fi mijlocul preferat sau necesar al unei persoane de a interacționa cu tehnologia.

În acest articol, veți afla despre regulile de accesibilitate pentru tastatură, precum și despre cinci pași de care trebuie să aveți în vedere atunci când proiectați aplicații pentru a vă asigura că sunt accesibile de la tastatură.

Cum funcționează accesibilitatea tastaturii?

Dacă o aplicație este accesibilă de la tastatură, asta înseamnă că oamenii au opțiunea de a folosi doar o tastatură pentru a opera elementele de control . Elementele de control sunt orice componente interactive din pagină, cum ar fi butoanele, linkurile, intrările de formulare, videoclipurile și alt conținut interactiv.

Elementele de bază ale navigării cu tastatură

Iată câteva taste de bază utilizate pentru navigarea cu tastatura:

• Navigarea la următorul element de control: Tab (sau tasta săgeată la dreapta sau în jos pentru butoanele radio aferente și selectați opțiuni)
• Navigarea la elementul de control anterior: Shift + Tab (sau tasta săgeată la stânga sau în sus pentru butoanele radio aferente și selectați opțiuni)
• Făcând clic pe un element de control: Introduceți și/sau bara de spațiu
• Navigarea între butoanele radio aferente sau selectarea opțiunilor: Tastele săgeți

Ordinea focalizării

Secvența în care elementele de control pot răspunde la evenimentele de la tastatură este cunoscută ca ordine de focalizare . Când un element este focalizat, puteți interacționa cu el folosind anumite comenzi de la tastatură. Când un element își pierde focalizarea, devine neclar. Browserele redă stările de focalizare implicite pentru a ajuta utilizatorii să țină evidența elementului focalizat în prezent.

S-ar putea să vă placă și: Design universal: 11 sfaturi practice pentru a vă face site-urile și aplicațiile mai accesibile.

Accesibilitatea tastaturii și Ghidul de accesibilitate a conținutului web (WCAG)

Ghidurile privind accesibilitatea conținutului web (WCAG) subliniază trei niveluri de conformitate — Nivelul A, Nivelul AA și Nivelul AAA — care au fost adoptate ca standarde pentru legile regionale sau naționale privind accesibilitatea web din întreaga lume.

Accesibilitatea tastaturii este unul dintre criteriile de succes pentru conformitatea cu nivelul A. Criteriile de nivel A descriu funcțiile obligatorii pentru tot conținutul web. De asemenea, sunt considerate cele mai ușor de implementat.

„Accesibilitatea tastaturii este, de asemenea, ușor de greșit dacă nu suntem atenți.”

Acestea fiind spuse, accesibilitatea tastaturii este, de asemenea, ușor de greșit dacă nu suntem atenți. Iată exemple de probleme comune de accesibilitate la tastatură găsite pe web:

• Stări de focalizare imperceptibile
• Ordine de focalizare incorectă
• Elemente interactive care nu pot primi focalizare
• Componente complexe care nu preiau interacțiunile tastaturii

Din fericire, există o mulțime de tehnici pe care le putem folosi pentru a ține cont de utilizatorii de tastatură și pentru a evita să facem aceste greșeli în propriile noastre aplicații.

5 pași pentru crearea de aplicații accesibile de la tastatură

1. Proiectați interacțiuni intuitive

Atunci când redăm elemente de control simple fără comportamente personalizate, de obicei le putem folosi funcțiile de accesibilitate încorporate de la tastatură. Dar, dacă nu cunoaștem comportamentele standard ale tastaturii asociate butoanelor, linkurilor sau intrărilor, este posibil să creăm din neatenție experiențe confuze pentru utilizatorii de tastatură.

„Dacă nu cunoaștem comportamentele standard ale tastaturii asociate butoanelor, linkurilor sau intrărilor, este posibil să creăm din neatenție experiențe confuze pentru utilizatorii de tastatură.”

De exemplu, dezvoltatorii folosesc uneori CSS pentru a ascunde butoanele radio HTML native în favoarea unor imagini mai stilizate. Nu este evident că intrările sunt butoane radio din culise, așa că utilizatorii de tastatură ar putea să nu realizeze că ar trebui să folosească tastele săgeți – nu tasta Tab – pentru a schimba focalizarea între opțiunile aferente.

Pentru a evita această problemă, ar trebui să afișăm ceva care cel puțin seamănă cu elementul HTML nativ pentru a oferi indicii vizuale pentru oricine dorește sau are nevoie să interacționeze cu acesta folosind o tastatură.

2. Construiește-ți aplicația astfel încât o tastatură să poată face tot ce poate un mouse

Fiți conștienți de elementele care nu vin cu funcțiile de accesibilitate încorporate de la tastatură. Elementele de aspect, listele, tabelele, anteturile, paragrafele și etichetele HTML nesemantice nu acceptă în mod implicit comenzile rapide de la tastatură. Și totuși, ele sunt folosite frecvent pentru a construi componente mai complexe, cum ar fi file, liste cu drag și plasare sau modali.

JavaScript ne permite să adăugăm ascultători de evenimente care fac ca elementele necontrolate să răspundă la clicurile sau gesturile mouse-ului. În React, de exemplu, putem folosi prop onClick pentru a adăuga interactivitate la un element de listă.

Ori de câte ori adăugăm interactivitate elementelor care nu sunt de control, trebuie să setăm atributul lor tabIndex la 0 . Acest lucru va permite elementului să primească focalizarea în ordinea corectă de focalizare atunci când tasta Tab este apăsată. De asemenea, trebuie să implementăm gestionarea evenimentelor de apăsare a tastei sau de apăsare a tastei pentru a înregistra „clicuri” prin tasta Enter și/sau bara de spațiu (linkurile pot fi făcute clic folosind ambele, în timp ce butoanele acceptă doar tasta Enter).

Putem evita o parte din această muncă suplimentară utilizând în schimb controale precum etichete de ancorare sau elemente de buton. Putem folosi întotdeauna CSS pentru a suprascrie stilurile implicite de link și butoane și pentru a face ca elementul interactiv să se întinde pe întreaga lățime a părintelui său non-interactiv pentru a maximiza zona țintă.

Indiferent dacă folosim sau nu elemente de control pentru caracteristici non-native, este posibil să fie nevoie totuși să adăugăm ascultători de evenimente pentru tastele săgeți (pentru a naviga între file dintr-o componentă a filei) sau tasta Escape (pentru a închide o suprapunere) pentru a face componenta noastră 100. procent de tastatură accesibilă.

Dacă implementăm comportamente de tastatură non-standard pentru o componentă mai complexă, este util să oferim instrucțiuni vizibile care descriu controalele de la tastatură pe care oamenii le pot folosi pentru a interacționa cu componenta.

3. Faceți munca suplimentară când înlocuiți ordinea de focalizare implicită

Ordinea focalizării este o altă cerință WCAG care este strâns legată de accesibilitatea tastaturii. Pentru a îndeplini criteriile de nivel A, ordinea de focalizare ar trebui să fie în concordanță cu secvența vizuală a elementelor interactive de pe pagină. Utilizatorii tastaturii ar trebui să poată naviga prin elementele de control de pe ecran de sus în jos și în aceeași direcție orizontală ca și conținutul textului (de la stânga la dreapta sau de la dreapta la stânga).

Cel mai simplu mod de a îndeplini acest criteriu este să părăsești ordinea de focalizare implicită, care este determinată de secvența în care elementele sunt aranjate în marcajul , așa cum este. Riscăm să nu îndeplinim acest criteriu atunci când introducem discrepanțe între ordinea vizuală a elementelor de control și modul în care sunt așezate în codul sursă.

S-ar putea să-ți placă și: Construirea unei navigații Breadcrumb accesibile cu Liquid și Shopify.

Dacă folosim captura de ecran de mai sus ca exemplu, să presupunem că am vrut ca cardul „Actualizați etichetele” să schimbe pozițiile cu cardul „Actualizați descrierea” atunci când se stivuiesc pentru ferestre mai înguste. Dacă cardurile sunt redate ca elemente flexibile, am putea lua în considerare utilizarea proprietății CSS order pentru a le schimba secvența la un anumit punct de întrerupere.

În timp ce proprietatea de order afectează secvența vizuală a elementelor flexibile, nu actualizează aranjarea acestora în codul sursă. Ca urmare, atunci când un utilizator apasă tasta Tab pentru a naviga între fiecare buton, butonul „Actualizați etichetele” va primi în continuare focus înainte de „Actualizați descrierea”, chiar dacă sunt afișate în ordine inversă pe ecran. Acest lucru face ca focalizarea să se schimbe în mod neașteptat în sus și în jos pe pagină, creând o experiență dezorientatoare pentru utilizator.

O modalitate de a evita această problemă este să redați două versiuni ale cardurilor în marcaj: una în ordinea așteptată pentru lățimi mai largi ale ferestrelor de vizualizare și alta în ordinea dorită pentru lățimi mai înguste ale ferestrelor de vizualizare. Putem folosi proprietatea de display pentru a comuta între ele la anumite puncte de întrerupere.

Dacă nu dorim să menținem două versiuni în marcaj, va trebui să folosim JavaScript pentru a actualiza atributele tabIndex ale cardurilor pe măsură ce se stivuiesc pe pagină. În funcție de numărul de elemente de control pe care le redăm, această abordare ar putea fi mai dificil de corectat decât menținerea diferitelor versiuni ale cardurilor în marcaj.

4. Când personalizați stările de focalizare, proiectați pentru utilizatorii care au cel mai mult nevoie de ele

Browserele folosesc proprietatea outline CSS pentru a reda un fel de indicație vizuală că un element este focalizat. Stările de focalizare au scopul de a ajuta utilizatorii să identifice ce element va înregistra evenimentele de la tastatură în timp ce navighează pe pagină cu o tastatură.

Este foarte obișnuit ca designerii și dezvoltatorii să înlocuiască stările implicite de focalizare redate de browsere. Acest lucru ar putea implica actualizarea outline implicit sau eliminarea completă și înlocuirea lui cu o altă proprietate CSS, cum ar fi background , border , box-shadow , color sau transform .

S-ar putea să vă placă și: Crearea unei paginații accesibile cu Liquid.

Oricum decidem să redăm stări de focalizare personalizate în aplicațiile noastre, ar trebui să ne asigurăm că îndeplinesc următoarele cerințe de accesibilitate:

• Contrast suficient de culoare: ar trebui să existe un contrast suficient între starea noastră de focalizare și culorile din jurul acesteia, astfel încât utilizatorii cu deficiențe de vedere să poată urmări cu ușurință ce element este în prezent focalizat.
• Modificările de culoare sunt asociate cu alți indicatori vizuali: modificarea culorii chenarului, fontului sau fundalului unui element poate să nu fie observată de utilizatorii cu daltonism. Ar trebui să fie asociat cu alte modificări vizuale care nu necesită ca utilizatorii să poată distinge culorile. Acest lucru se aplică și stărilor de trecere cu mouse-ul și de eroare care implică modificări de culoare.
• Vizibil în temele cu contrast ridicat: unele proprietăți CSS, inclusiv background și box-shadow , sunt ignorate atunci când modul de contrast ridicat este activat pe dispozitivele Windows. Este posibil să nu fie înregistrate nici modificările de culoare, motiv pentru care este de două ori important să ne bazăm pe indicatori suplimentari perceptibili de persoanele care au nevoie de mai mult contrast între culorile de fundal și de prim plan.

Deși este acceptabil să suprascrieți proprietatea de outline implicită, nu eliminați niciodată stările de focalizare implicite fără a furniza o înlocuire.

5. Furnizați comenzi rapide pentru utilizatorii de tastatură

Dacă cineva folosește un mouse pentru a naviga într-o pagină web, poate derula prin conținutul antet străin atunci când pagina se încarcă pentru a ajunge la informațiile pe care le caută. Procesul nu este la fel de simplificat pentru utilizatorii de tastatură, care ar putea avea nevoie să parcurgă mai multe link-uri de navigare sau orice alte elemente de control care apar înaintea conținutului principal al paginii.

În calitate de dezvoltatori, putem oferi un „link de ignorare” în partea de sus a fiecărei pagini din aplicația noastră pentru a permite utilizatorilor tastaturii să ocolească elementele de control care preced conținutul principal al paginii. Linkul de ignorare este de obicei ascuns din vedere până când primește focalizare. Nu este vizibil pentru persoanele care folosesc un mouse pentru a interacționa cu aplicația dvs., dar va fi primul element care va primi atenție pentru cei care folosesc o tastatură.

Când se face clic pe link, focusul se mută către containerul de conținut principal, iar utilizatorii de tastatură pot începe imediat să treacă prin file prin elementele de control principale dintr-o pagină.

Omite link-urile sunt mai mult decât scurtături convenabile. Sunt un exemplu de blocuri de ocolire, care sunt necesare pentru a îndeplini standardele WCAG de nivel A.

Testați-vă aplicația des devenind singur utilizator de tastatură

Testarea accesibilității tastaturii are o curbă de învățare relativ mai scăzută pentru persoanele care nu sunt obișnuite să folosească tehnologii sau dispozitive de asistență. Tot ce aveți nevoie este accesul la o tastatură, familiaritatea cu comportamentele standard ale tastaturii și accesul la modul Windows cu contrast ridicat (fie prin achiziționarea unui dispozitiv Windows, fie prin instalarea unei mașini virtuale).

Iată câteva întrebări de reținut când testăm aplicația noastră pentru accesibilitatea tastaturii:

• Pot să-mi folosesc tastatura pentru a interacționa cu orice răspuns la clicurile și gesturile mouse-ului?
• Va ști cineva cum să interacționeze cu acest element atunci când primește focus?
• Ordinea de focalizare se potrivește cu secvența vizuală a elementelor interactive de pe pagină?
• Pot urmări ce element este în prezent focalizat, chiar dacă am nevoie de un contrast mai mare între culori?
• Pot ajunge cu ușurință la conținutul principal al paginii?

Răspunsul „da” la toate aceste întrebări nu necesită mult efort și poate avea efecte pozitive pentru utilizatori în orice circumstanță: indiferent dacă au o dizabilitate fizică, caută modalități de a economisi timp sau trebuie să folosească computerul lor cu o singură mână.

Testarea accesibilității este o componentă crucială a dezvoltării aplicației. Mai exact, accesibilitatea tastaturii este la fel de importantă ca oferirea de text alternativ pentru persoanele care folosesc cititoare de ecran sau subtitrări pentru persoanele care nu pot auzi conținut audio. La sfârșitul zilei, capacitatea de a folosi un mouse nu ar trebui să fie necesară pentru a utiliza o aplicație dacă doriți ca aplicația dvs. să fie complet accesibilă.