“A Web igazi ereje az univerzalitásában mutatkozik meg.
Alapvető követelmény, hogy mindenki hozzáférjen, képességeitől függetlenül.”
Tim Berners-Lee, W3C Director and inventor of the World Wide Web
A web úgy lett kialakítva, hogy mindenki számára elérhető legyen függetlenül a használt hardvertől, szoftvertől, földrajzi helytől, vagy egyéni képességektől. Amint a web eléri ezt a kitűzött célt, úgy használható lesz bárki által, legyen szó bármilyen hallási, mozgási, látási, vagy kognitív hátránnyal rendelkező személyről.
Fejlesztőként a WCAG és ARIA szabványok átnézése után az első kérdés mindig az, hogy Oké, de mivel tudnánk ezt validálni? Megindul az eszeveszett keresés eszközök után, amelyek megmondják nekünk a tutit. A valóság az, hogy bár léteznek nagyon jó eszközök (és egyre több), amik segítenek nekünk a WCAG különböző szintjeinek betartásában, nem biztosítanak 100%-os coverage-et jelen pillanatban, és a manuális tesztelést semmiképp sem szabad elhanyagolni. Ez részben annak is köszönhető, hogy viszonylag sok tényezőt kell figyelembe venni,, illetve kontextus hiányában nem feltétlen tudja megállapítani az eszköz, hogy az adott elem vagy attribútum, szükséges-e annak ellenére, hogy szintaktikailag megfelelően van használva,.
Mindezek ellenére én azt javaslom minden fejlesztőnek, illetve csapatnak, hogy a soron következő eszközök valamelyikét mindenképp próbálják ki, építsék be a fejlesztői eszköztárba, napi rutinba, vagy éppen a CI pipeline-okba, hogy még release előtt meg tudják fogni az akadálymentességgel kapcsolatos bug-ok nagy százalékát, és nem utolsó sorban azért, hogy tanuljanak belőlük.
Az első részben a böngészőnkben elérhető eszközöket fogjuk átnézni, a másodikban pedig előveszünk egy-két browser extension-t és javascript library-t. Végül pedig, a harmadik részben a képernyőolvasók alapvető működését fogjuk áttekinteni.
Chrome Devtools
Senkinek sem kell bemutatni az egyik leggyakrabban használt fejlesztői eszközt. Nap mint nap kapcsolatba kerülünk vele, azonban a fejlesztők jelentős részének figyelme elsiklik az alábbi feature mellett.
Az accessibility tabon több hasznos információt is találunk. Az első és legfontosabb, az Accessibility Tree. Akik esetleg nincsenek tisztában azzal, hogy mi is ez az Accessibility Tree, ők a legegyszerűbben talán úgy érthetik meg, ha úgy gondolnak rá, mint egy lecsupaszított DOM-ra. Csak azok az elemek, értékek és állapotok tartoznak ide, amelyek különféle asszisztív technológiák, például felolvasó szoftverek felé hordoznak információt. Ebben a nézetben szinte kivétel nélkül ilyen elemekkel fogunk találkozni, illetve egy pár div-vel, amelyek adott esetben lenyíló csoportokat fognak össze. Ezeket GenericContainer-nek nevezi az eszköz. Ezen kívül láthatjuk, hogy az adott elemen milyen aria attribútumokat használunk, anélkül, hogy száz másik attribútum közül kellene őket kivadásznunk. Végül pedig a számolt értékeket tekinthetjük meg adott elemnél. Ahol is a legtöbbet a Name értékkel találkozhatunk. Ez az érték lesz az, amelyet a felolvasó szoftverek bemondanak abban az esetben, ha az adott elemhez érnek. Ahogyan a képen is látható, több lehetséges érték is szerepel, lentről a title elemtől indulva, a node tartalmán keresztül, egészen az aria-labelledby-ig. Ezzel a sorrendezéssel kapcsolatban azt is megtanulhatjuk, hogy a felolvasó szoftverek esetében melyek azok az értékek, amelyek a legmagasabb prioritással bírnak. A legalsó érték a leggyengébb, míg a legfelső a legerősebb. A computed properties résznél különböző állapotokat tudunk vizsgálni, mint például azt, hogy az elem fókuszálható-e, illetve, hogy jelenleg fókuszálva van-e, valamint beviteli mezők esetén megnézhetjük, hogy validálás során megfelelően állítottuk-e be az Invalid user entry mezőt.
Az Accessibility tab mellett, egy másik hasznos feature is belekerült a DevTools-ba, a Chrome 65-ös verziójában. A color pickert szintén számtalanszor használjuk fejlesztőként és most már azt is megtudhatjuk belőle, hogy az általunk használt színpaletta milyen kontraszt arányokkal bír, illetve hogy az a WCAG melyik szintjének felel meg. Az AA és AAA szintek teljesítéséhez két görbét is kirajzol a színskálába, amivel könnyen be tudjuk lőni a kívánt színeket. Természetesen egy kötött arculati szabályrendszer mellett nem tudjuk csak úgy módosítani a színeket, ezért ehhez érdemes biztosítani egy kapcsolót, ami átváltja az oldalt az előre definiált színpaletta egy kontrasztosabb verziójába.
Firefox Inspector
A Chrome-hoz hasonlóan a Firefox is rendelkezik egy, a fejlesztői eszközbe épített accessibility toollal. Ami azonban egy kicsit szimpatikusabb a Mozillás megközelítésben az az, hogy egy könnyebben “hozzáférhető”, látható helyre került. Miután először kattintunk a tab fülre és engedélyezzük a Firefox accessibility feature-eit, onnantól kezdve minden alkalommal, ha egy oldalon lenyitjuk a context menüt, lehetőségünk lesz az Inspect element menüpont alatt kiválasztani az Inspect Accessible Properties menüpontot is, ami azonnal ezt a tab fület fogja kinyitni.
A layout és kontrollok közel azonosak a két felületen, azonban a Firefox esetén magát a treet egy kicsit könnyebb átlátni és bejárni.
Lighthouse
Szintén semmiféle telepítést nem igényel, és rögtön a Chrome DevTools-ból elérhetőaz audits tab megnyitásával. Azért emeltem ki a Chrome DevTools rész alól, mert érdemes tudni, hogy a Lighthouse önálló entitásként is tud üzemelni. pen-source project, a forráskódját meg is tekinthetjük a Github-on, illetve beépíthető a projektünkbe is automata teszteléshez, ezt azonban a következő részben fogjuk részletesen megnézni.
A Lighthouse Accessibility emellett sok más auditot is el tud végezni, mi azonban most csak erre az egy feature-re fogunk koncentrálni. Amikor lefuttatunk egy auditot, az eszköz végigszkenneli az oldalunk forrását az általunk megadott paraméterekkel, majd a végén generál nekünk egy reportot, amiből láthatjuk, hogy accessibility szempontból hogyan teljesít az oldalunk a Lighthouse pontrendszere alapján.
Az audit futása előtt meg tudjuk adni, hogy milyen eszközön szeretnénk futtatni, ez lehet desktop vagy mobil. Kiválaszthatjuk a futtatandó auditokat (jelen esetben csak Accessibility). Network sebességet állíthatunk, valamit azt is megmondhatjuk, hogy ürítse az eddig felhalmozott adatokat.
Futás után aképen szereplő reportot láthatjuk, amelyet JSON formátumban le is tudunk tölteni és a Lighthouse viewer-be behúzva a DevTools-on kívül is meg tudjuk nézni.
Négy kategóriába sorolhatjuk az audit végeredményét. Sikertelen és sikeres auditok, nem releváns auditok, illetve manuálisan tesztelendő elemek. Sikeres auditoknál értelemszerűen láthatjuk, hogy mik azok a pontok, amelyeket sikeresen megugrottunk, azonban érdemes egy pillantást tekinteni ezekre is, abban az esetben, ha nem tudatosan készültek. A nem tesztelhető részek alatt azokat az eseteket értjük, amelyek az adott oldalon nincsenek jelen, azonban az eszköz képes őket ellenőrizni. Sikertelen auditoknál pedig láthatjuk, hogy milyen pontokon kell javítanunk az alkalmazásunkat. Érdemes ezekkel kezdeni a manuális tesztelés megkezdése előtt, hiszen amíg itt vannak hibáink, jó eséllyel ezek a manuális tesztelés során is ki fognak jönni.
Már a Lighthouse is elég jó vonalvezető a manuális teszteléshez, de a következő részben megnézünk egy olyan kiegészítőt is, ami egy teljes site audithoz ad nekünk step by step segítséget.
