Accesibilitate, Partea 5 Înțeles

Acesta este ultimul principiu la care ne uităm. În linii mari, afirmă că conținutul și navigarea site-ului trebuie să fie ușor de înțeles. Deși responsabilitatea de a implementa o mulțime de recomandări constă în "utilizatorul final" al pluginului sau al temei (sau cel care publică conținutul), există recomandări pe care dezvoltatorii acestor pluginuri și teme le pot implementa.

Citibil (3.1)

Prima orientare afirmă că conținutul trebuie să fie "lizibil și ușor de înțeles". O mulțime de recomandări se referă la nivelul de lectură al conținutului și la utilizarea cuvintelor, abrevierilor și acronimelor neobișnuite, care nu sunt relevante pentru dezvoltatori. 

O recomandare pe care o putem implementa este că limba umană a paginii web ar trebui să poată fi identificată programatic. Pentru a realiza acest lucru, limba trebuie specificată pe  element, prin intermediul lang atribut. În plus, dir atributul ar trebui să fie folosit pentru a indica dacă conținutul este de la dreapta la stânga.

WordPress face acest lucru ușor prin furnizarea language_attributes (), care imprimă atributele necesare. În header.php din tema ta:

>

 language_attributes () funcția stabilește limba site-ului și, dacă este necesar, direcția și filtrează ieșirea, permițând pluginurilor (de exemplu, pluginurile multilingve) să modifice atributul, după caz.

Predictabile (3.2)

Cea de-a doua orientare afirmă că un site web trebuie prezentat și comportat într-un mod previzibil. O mulțime de recomandări pot fi îndeplinite prin asigurarea faptului că marcajul HTML al temei este bine structurat și logic. Cuplați cu aceștia sunt numeroasele recomandări de a nu face modificări care să perturbe comportamentul natural și logic al unei pagini web.

Focus Behavior

Am menționat că nu folosim tabindex în al patrulea articol din această serie ("Operabil"). Această recomandare se bazează pe faptul că trebuie să se afirme că atunci când un element primește focalizare, acesta nu ar trebui considerat un declanșator al unei anumite schimbări a stării paginii.

De exemplu, un buton de formular care primește focalizare nu ar trebui să determine ca formularul să fie trimis, iar un focalizator de legătură nu ar trebui să determine ca acel link să fie activat. Aceasta este nu pentru a spune că instrucțiunile sau, în cazul meniurilor de navigare, submeniurile nu trebuie să apară atunci când elementul corespunzător primește focalizare. Aceste exemple nu constituie o schimbare de stat. Cu voce relaxat, puteți echivala ideile unui obiect care primește focalizare și un element care este suspendat.

Nu împiedicați focalizarea

Ar trebui să evitați îndepărtarea focalizării de la un element care o primește. De exemplu, nu trebuie să faceți niciodată ceva de genul:

$ ('a') pe ('focus', function () $ (this) .blur (););

Ajută utilizatorii când este necesar un input de utilizator (3.3)

Asigurați-vă că sunt identificate erori

În mod implicit, singurele forme care sunt relevante pentru dezvoltatorii de teme sunt formularele de conectare / înregistrare, căutare și comentarii. Dintre acestea, numai cele două din urmă sunt în mod obișnuit avute în vedere de dezvoltatorul temelor. Întrucât formularele de căutare nu duc vreodată la o "eroare", ne concentrăm în această secțiune pe formularele de comentarii.

WordPress face o treabă foarte bună de a notifica utilizatorii despre o eroare și de a le informa exact despre acea eroare. Cu toate acestea, face acest lucru, permițând utilizatorilor să părăsească pagina originală și prezentându-le o pagină de eroare "mort". 

Dacă utilizatorii revin la pagina originală, formularul va fi pierdut concentrarea și va trebui să-l găsească din nou. O soluție mai bună ar fi să împiedicați utilizatorii să trimită formularul până când au completat corect formularul. Cu toate acestea, atunci când faceți acest lucru, este esențial să transmiteți utilizatorilor că valoarea introdusă nu este validă, altfel veți fi prins în mod esențial.

Există o mulțime de scripturi de validare din partea clientului și este foarte ușor să vă creați propriul script de validare. Ceea ce este important este:

  1. Mesajul de eroare care apare după ce utilizatorul părăsește un câmp cu o valoare nevalidă (sau încearcă să trimită formularul) ar trebui să transmită atât faptul că există o eroare, cât și unde este această eroare (adică să identifice câmpul).
  2. Mesajele de eroare ar trebui identificate ca alerte utilizând atributul ARIA: rol = „alertă“.
  3. Dacă este cazul, mesajele de eroare ar trebui să fie cât mai explicite posibil pentru a informa utilizatorul de ce nu a fost acceptată valoarea introdusă.

Iată un exemplu simplu, bazat pe propriul exemplu de validare a formularului WebAIM (pe care vă încurajez să îl citiți), care adaugă un mesaj de eroare dacă câmpul nume este gol.

 jQuery (document) .ready (functie ($) $ ('# author'). ($) ()) $ ('(# autor-eroare'))

') .insertAfter ($ (' # author ')) .text (' Eroare câmp de nume: Vă rugăm să furnizați un nume '); altceva în cazul în care ($ ('# autor-eroare') lungime> 0) $ ('# autor-eroare'). ); );

Exemplul WebAIM, de asemenea, împiedică utilizatorii să părăsească câmpul nevalid și le returnează în câmp pentru a corecta greșeala. Dacă faci asta, te-aș recomanda nu face întoarceți utilizatorul la câmp dacă valoarea este goală, în caz contrar, veți bloca utilizatorii care au dat accidental focalizarea pe teren, dar nu intenționează să trimită formularul.

Așa cum am menționat anterior în această serie, nu trebuie să vă bazați doar pe culoare sau poziția în sine pentru a transmite sensul. În acest context, mesajele de eroare ar trebui să fie în mod evident din text, precum și câmpurile la care se referă.

Furnizați etichete

Temele ar trebui să fie utilizate numai comment_form () pentru afișarea formularelor de comentarii, iar acest lucru gestionează etichetele într-un mod accesibil. În mod similar, formularul de căutare prestabilit nu are nevoie de altă muncă. Cu toate acestea, la personalizarea sau modelarea acestor formulare ar trebui:

Asigurați-vă că etichetele sunt vizibile întotdeauna

Etichetele trebuie să fie vizibile în orice moment. În mod specific, acest lucru înseamnă că substituenții nu constituie o etichetă și nu ar trebui folosiți ca căutare. Există mai multe motive pentru aceasta: 

  1. Există suport inconsistent pentru cititoarele de ecran.
  2. Suporturile sunt în mod obișnuit într-o culoare slabă și pot fi greu de citit.
  3. Deoarece substituentul dispare atunci când câmpul se concentrează, acesta poate crea probleme de uzabilitate pentru cei cu deficiențe cognitive.

Dacă este cazul, furnizați instrucțiuni suplimentare

Dacă un câmp de formular necesită instrucțiuni suplimentare, acestea pot fi furnizate după câmp, dar sunt legate în mod explicit cu acesta, utilizând Aria-describedby atribut. Conținutul elementului la care se referă acest atribut este citit după eticheta câmpului.

Ca exemplu de pe site-ul W3C:

Un pic de instrucțiuni pentru acest câmp legate de aria descrisă.

Cu toate acestea, trebuie să știți că există un suport inconsecvent pentru acest lucru printre cititorii de ecran.

Identificați câmpurile necesare

Câmpurile necesare sunt marcate ca atare cu Aria-necesară = "true" atribut. Formularul de comentariu WordPress implicit, produs de comment_form () deja se ocupă de acest lucru, deci nu vă acționează nevoie să luați aici. Cu toate acestea, ar trebui să știți acest lucru dacă alegeți să personalizați formularele de comentarii.

Concluzie

Acest articol concluzionează ghidul nostru dezvoltator de tematici brute la principiile accesibilității W3C și modul în care pot fi implementate. În ultimul articol din această serie vom analiza câteva modalități simple de a merge mai departe și de a încuraja și ajuta în mod activ utilizatorul final al temei (sau pluginului) să producă conținut accesibil.

Cod