Preocuparea tot mai frecventă a marilor companii de a face accesibile paginile lor web pentru cât mai mulți utilizatori, ne îndreaptă pașii către o categorie de utilizatori cu nevoi speciale. Oricare ar fi gradul de deficiență, permanentă sau temporară, proprietarii de website-uri își doresc ca informația livrată să fie accesibilă și acestora.
Astfel, o direcție în cadrul testării se orientează spre acest tip de utilizatori cu diferite deficiențe. Există o inițiativă internațională prin care se încearcă a se stabili un set de bune practici și recomandări, numită W.A.I. (Web Accessibility Initiative), lansată de W3C (World Wide Web Consortium).
Aceste reguli descrise ca bune practici ajută la standardizarea anumitor obiecte pentru ca softul specializat să poată interpreta aceste obiecte și să le expună oamenilor cu dizabilități într-un mod în care ei să le înțeleagă. De asemenea, respectând regulile, se va constata o îmbunătățire consistentă in S.E.O. (Search Engine Optimization)
De obicei, dacă nu se respectă aceste reguli, impactul nu este sesizabil pentru un utilizator obișnuit, o persoană fără dizabilități, de aceea, este destul de dificil ca problemele din punct de vedere al accesibilității să fie descoperite în procesul de testare.
Există mai multe standarde de conformitate. Cel mai frecvent cerut și reglementat este numit WCAG-2.0.
Pentru a deveni un bun tester specializat în Accessibility Testing, trebuie să pornești de la a înțelege conceptul, cui se adresează, să parcurgi aceste cerințe, să le înțelegi și apoi fiecare cerință să o testezi pe fiecare pagină în parte.
Pentru că efectul nu este sesizabil, trebuie să cunoști limbajul HTML, fiecare mark-up ce înseamnă, fiecare atribut la ce se referă și așa mai departe.
Deoarece Accessibility Testing este un proces anevoios, care ocupă destul de mult timp din perioada alocată testării, ne-am gândit să automatizăm acest proces.
Căutând printre toolurile existente de testare automată, specializate în Accessibility Testing, am identificat AChecker, un tool care, pe lângă faptul că expune o interfață utilizator, expune și un API.
Pretențiile clienților cresc din ce în ce mai mult și una dintre pretențiile expuse a fost ca orice cod scris pentru client să nu fie expus în niciun tool extern. Ca răspuns la această cerință, am implementat AChecker pe serverele interne ale companiei.
Testând cu AChecker am constatat că timpul de testare a scăzut. Neconformitățile erau descoperite destul de repede, dar totuși am întâmpinat câteva lucruri care făceau procesul nu chiar așa de confortabil. Le descriem mai jos:
Astfel, ne-am dorit să facem posibile aceste lucruri imposibil de livrat cu AChecker. Proiectul ARobot, are drept core-engine pe AChecker instalat pe serverele interne și vine cu toate aceste inconveniente rezolvate:
codul HTML nu este externalizat;
introduci o singură data URL-ul paginii web care să fie in mod automat testată;
poți testa pagini livrate prin HTTPS;
Pe lângă acestea, ARobot oferă o interfață extrem de simplă în care poți să înregistrezi proiectul și paginile care te interesează să fie testate, îți oferă un istoric atât al rulării cât și al bugurilor, precum și o pagină de prezentare creată în WordPress pentru a captura, într-o formă de blog, lucrurile interesante despre acest tool, cum funcționează, care este scopul, cum se poate utiliza, dar și pentru a face posibilă comunicarea între părțile implicate și cele interesate.
ARobot este gata și deja are în lista de task-uri validarea a peste 50 de linkuri de pagini web.
ARobot este accesibil doar in rețeaua Endava:
de Bálint Ákos
de Andrei Oneț
de Raul Boldea
de Ioana Varga
