Sari la conținut
Toate articolele

Accesibilitatea unui site: teste de acceptare pe care le poți cere

Un set practic de probe pentru tastatură, formulare și afișarea la zoom, cu rezultate verificabile înainte de lansarea site-ului.

Înainte să accepți un site, încearcă să parcurgi drumul unui vizitator care vrea să trimită o solicitare folosind doar tastatura. Trebuie să poată găsi serviciul, deschide formularul, completa câmpurile și înțelege rezultatul. O problemă pe acest traseu merită documentată la fel ca un buton care nu funcționează cu mouse-ul.

Testele de mai jos formează un punct de pornire pentru recepția unui proiect. W3C precizează că verificările rapide oferă o imagine preliminară și nu pot demonstra accesibilitatea completă. Pentru o evaluare de conformitate, definește separat paginile, criteriile, nivelul urmărit și metoda de testare.

Alege trasee complete și stări diferite

Într-un exemplu ipotetic, un site de servicii are trei trasee de acceptare: găsirea unui serviciu, citirea unui articol și trimiterea unei cereri. Pentru fiecare, notează punctul de pornire și rezultatul așteptat. Include meniul mobil, mesajele de eroare și eventualele ferestre de dialog.

Folosește conținut apropiat de cel care va fi publicat. Titlurile lungi, numele compuse și un mesaj de câteva paragrafe pot scoate la iveală probleme pe care textele demonstrative scurte le ascund. În raport, păstrează adresa paginii, browserul, dimensiunea ferestrei și pașii de reproducere.

Parcurge site-ul cu tastatura

Folosește Tab și Shift+Tab pentru deplasare, apoi comenzile potrivite controlului pentru activare. Ordinea trebuie să poată fi urmărită vizual, iar meniurile și dialogurile să permită continuarea traseului. Observă unde ajunge focusul după deschiderea și închiderea unei componente.

Un antet fix sau un banner poate acoperi controlul selectat. Criteriul WCAG 2.2 privind focusul neascuns cere ca elementul care primește focus să nu fie ascuns în întregime de conținutul creat de autor. Pentru recepție, poți cere suplimentar ca elementul să rămână complet vizibil, dacă aceasta este cerința convenită a proiectului.

Scrie defectul concret: „După închiderea meniului, Tab ajunge la un link acoperit de antet”. Adaugă pașii și o captură. „Navigarea este dificilă” lasă echipei prea multe posibilități de interpretare și face reverificarea mai lentă.

Provoacă erorile din formular

Trimite formularul cu un câmp obligatoriu gol și cu o adresă de email invalidă, folosind date fictive. Verifică dacă utilizatorul află ce câmp trebuie corectat și ce informație este așteptată. Un contur roșu singur nu explică eroarea.

W3C, pentru criteriul Error Identification, cere identificarea elementului cu eroare și descrierea erorii în text atunci când aplicația o detectează automat. În testul proiectului, urmărește și asocierea mesajului cu acel câmp, păstrarea datelor valide și accesul la corectare prin tastatură.

Testează formularul și cu un cititor de ecran, împreună cu cineva care știe să îl folosească. Consemnează programul și browserul utilizate, numele anunțat al câmpului și mesajul perceput după trimitere. Dacă formularul doar deschide aplicația de email, textul interfeței trebuie să descrie acea acțiune; nu trebuie să anunțe că solicitarea a fost livrată.

Mărește conținutul și verifică rearanjarea

Deschide paginile la zoom și la o lățime redusă. Verifică dacă textul, controalele și mesajele rămân disponibile. Criteriul Reflow din WCAG urmărește afișarea conținutului fără pierderi și fără derulare în două direcții la dimensiunile definite, cu excepții pentru conținutul care are nevoie de o dispunere bidimensională.

Pentru conținutul care se derulează vertical, reperul criteriului este lățimea de 320 pixeli CSS. O probă uzuală este zoom 400% într-o fereastră de 1280 pixeli CSS. Verifică separat tabelele, navigarea și mesajele lungi; o pagină de prezentare care arată bine nu confirmă toate aceste stări.

Leagă recepția de dovezi

Păstrează o fișă pentru fiecare traseu, cu rezultatul, defectele și retestarea după corecții. Un scaner automat poate completa aceste probe, dar verificarea manuală rămâne necesară pentru experiența de folosire. Pentru proiectele cu public divers, include și sesiuni cu utilizatori cu dizabilități.

În cererea de web design, precizează traseele esențiale și solicită ca oferta să numească probele de accesibilitate incluse, dispozitivele folosite și modul în care se documentează remedierea defectelor.

Surse

Ce ar trebui să facă mai bine site-ul tău?

Primești o ofertă personalizată, fără niciun angajament.

Solicită ofertă