Bevezetés az akadálymentes webfejlesztésbe

Manapság a mindennapi életben egyre több helyen találkozhatunk olyan “akadálymentes” megoldásokkal, amelyek megkönnyítik a hátrányos helyzetű emberek mindennapjait. Ez a weben sincs másképp. Elsőre talán nem annyira szembetűnő, de egyre több akadálymentesített weboldal készül.

Az itt látható kis ikon arra szolgál, hogy megnyomásakor weboldal nagy kontrasztú módban jelenjen meg. Ez önmagában nem rossz elképzelés, azonban erre a legtöbb böngésző eleve ad natív kiegészítő megoldást, és ezzel a megoldással csak egy rétegen, a gyengénlátókon segítünk egy kicsit.

Emellett azonban más hátrányban szenvedő emberekre is gondolnunk kell. Ilyen például a vakság, süket-némaság, mozgáskorlátozottság vagy egyéb kognitív vagy szellemi visszamaradottság.

A HTML Akadálymentes!

Szerencsére a HTML5-ben rengeteg olyan elem található, ami szemantikailag is képes elkülöníteni bizonyos tartalmi egységeket, funkciókat és megfelel a WCAG 2.0 akadálymentességi útmutatónak. Amennyiben ezeket helyesen alkalmazzuk, már egy nagy lépést tettünk az akadálymentesség felé. Itt arra gondolok, hogyha van egy menünk, azt tegyünk <nav> elembe, a fő tartalmi rész kerüljön <main> elembe, illetve ha interakciót várunk a felhasználótól használjunk <button> elemet. Így a különböző felolvasó-szoftverek ezen elemeket feldolgozva tudják a felhasználót navigálni, illetve ilyen módon közlik vele, hogy milyen jellegű tartalmon áll jelenleg. Természetesen előfordulhatnak olyan esetek, mikor ez nem kivitelezhető, vagy éppen máshogy szeretnénk megoldani. Ezekre az esetekre ott a role attribútum, amelyben megmondhatjuk, hogy az adott elem miként is fog viselkedni. Egy keresőmezőt jó eséllyel text input ként fogunk megadni, így tehát szükség lesz egy role=”search” attribútumra.

A mai weboldalakon azonban nemcsak egyszerű szöveges tartalmat prezentálunk, hanem olyan tartalmakat, amelyek folyamatosan változnak, felbukkannak, eltűnnek, amit látóként könnyedén érzékelünk is, azonban azokat akik az előbb említett állapotokat, illetve azok változását nem látják, szükség van információval ellátni.

Ilyen esetekben aria (Accessible Rich Internet Applications) attribútumokat és egy kis javascriptet kell használnunk. Ezekkel az attribútumokkal tudjunk megmondani, hogy például egy adott lenyíló elem milyen állapotban van jelenleg (aria-expanded=”true”). Ha össze szeretnénk kötni egy gombot egy tartalmi résszel, akkor az aria-describedby attribútummal tehetjük meg. Az utóbbi esetben szükség van egy ID-ra, amivel összetudjuk kötni a két elemet. Egy másik nagyon előnyös attribútum az aria-live, amivel egy olyan régiót azonosíthatunk, amelyben AJAX segítségével történik meg a tartalom módosítása. Itt azonban figyelni kell arra, hogy mi az az érdemi tartalmi rész, amiről a felhasználónak tudnia kell, és ne olvastassunk fel túl sok felesleges információt újra és újra.

Role-okról és az ARIA-ról bővebben: https://www.w3.org/TR/html-aria/

Navigálás egér nélkül és mobilon

Az akadálymentesség egyik fő feltétele, hogy a felhasználó tudjon az egere nélkül is navigálni az oldalon. Erről rögtön mindenkinek a tabindex ugrik be. Ezzel az attribútummal tudjuk manipulálni az oldal tab sorrendjét, azaz, hogy melyik elem kerüljön előre, vagy éppen melyik elem az, amit ne is vegyen figyelembe a böngésző. Az utóbbi esetet egy negatív érték megadásával hozhatjuk létre, rendszerint -1 megadásával. Ha egy elemet pedig előre szeretnénk venni, akkor pozitív értékeket adjunk, ám ezt megoldást érdemes kerülni.

Azért is nagyon fontos a struktúra és a sorrendiség gondos kialakítása, mert a felhasználók nagy része mobilról vagy tabletről érkeznek, ugyanis iOS-en és Android-on egyaránt van natív felolvasó szoftver. Ezek a szoftverek (Voiceover, Talkback) amellett, hogy felolvassák a felhasználónak a tartalmat, módosítják a navigálást is. Swipe-olva tudunk előre és vissza lépkedni az oldalon, hasonlóan a desktop-on való tab-os navigáláshoz.

Így tehát ha nem nyúlúnk bele a tabindexbe, és jól felépítjük az oldalt, nem ütközhetünk különösebb problémákba. Vannak azonban olyan egyedi esetek, ahol szükséges a tabindex-et állítani, de azokban az esetekben is csak 0 és -1 érték között. Ilyen eset lehet egy modal. Ezt az elemet egy kvázi egy külön dokumentumként kell kezelni, és az oldal többi részét ki kell zárnunk a navigációból, amikor felnyitjuk modal-t, ilyenkor jöhet szóba a tabindex=”-1”.

Design és css

Manapság minden oldal különféle modern design segítségével készül. Ennek köszönhetően nagyon sok mindent css-ben oldunk meg. Arra azonban különös figyelmet kell fordítani, hogy az oldal úgy legyen felépítve, hogy css nélkül is értelmezhető legyen. Ezt egyrészt a korábban említett szemantikailag megfelelő elemek segítségével érhetjük el, másrészt pedig arra is figyelmet kell fordítani, hogy a css csak a formázásokért feleljen. Képeket, amik tartalommal is rendelkeznek <img> tag-be tegyük, ne css background-ként használjuk.

Hasznát is vehetjük azonban a css-nek több esetben is. Vannak esetek, amikor egy aria-label attribútummal nem tudjuk leírni egy adott elem működését, így egy külön elemben akarjuk ezt megtenni. Viszont ezt a külön elemet csak a felolvasó szoftverek számára szeretnénk láthatóvá tenni. Első ötlet, display: none, ez azonban nem lesz jó, ugyanis így a felolvasók elől is elrejtjük. Különböző hack-ek segítségével tudjuk eltüntetni az elemet, az egyik a lentebb látható, bootstrap által is használt megoldás.

Rengeteg dolgot valósítunk meg mindezek mellett css pseudo elemekkel, például ikon fontokat is ilyen módon jelenítünk meg. Ilyenkor az okozhat gondod, hogy bizonyos felolvasó szoftverek hajlamosak a css content property tartalmát is felolvasni. Érdemes külön dedikált elemet létrehozni az ikonok részére, amit aztán az aria-hidden attribútum segítségével elrejtünk.

Egyéb tudnivalók

Fontos, hogy az előbb említett a technikák, praktikák beépüljenek a fejlesztési szokásaink közé és folyamatában fordítsunk figyelmet az akadálymentességre is, így elkerülve, hogy a projekt végén kelljen meghatározó komponenseket átírni. Teszteljük folyamatosan az elkészült munkát lehetőség szerint minél több képernyőolvasón, mert tudnak azok is – ahogyan a böngészők is – eltérően viselkedni. Könnyedén tudunk online validációkat is futtatni (pl.: https://tenon.io/, vagy https://www.powermapper.com/), de ha node.js-es környezetben dolgozunk akár build-be is tudunk egyszerűen beépíteni tesztet. Ezek mellett pedig több hasznos böngésző kiegészítő is rendelkezésre áll, például a WAVE Evaluation Tool, ami beépül az oldalba és az adott hibás elemeknél jelzi, hogy mi a probléma, illetve azokra milyen megoldás a javasolt. Egy másik hasznos plugin pedig az aXe, amivel a devtool-ban tudunk auditot futtatni az oldalra és hasonlóan az előzőhöz, itt is visszakapjuk a hibát és a lehetséges megoldásokat.