Az akadálymentes webfejlesztés követelményei

Bizonyos web-akadálymentességi előírásoknak való megfelelésről a webfejlesztőknek kell gondoskodniuk: úgy kell felépíteniük a website szerkezetét és működését, hogy a végeredmény majd megfeleljen ezeknek az előírásoknak.

A törvényileg kötelezően akadálymentes weboldalaknak a WCAG szabvány A és AA szintjén kell megfelelniük minden követelménynek. 

Az alábbiakban a webfejlesztésre vonatkozó, A és AA szintű követelményeket vesszük sorra, hivatkozva a WCAG 2.1 szabvány megfelelő pontjára.

Tiszta és modern kódolás

Annak, hogy a weboldalainkat a lehető legtöbb jelenlegi és jövőbeli felhasználói programmal – köztük a kisegítő lehetőségeket kínáló programokkal – lehessen használni, a weboldalaknak megbízhatóan kell működniük.

A megbízható működés egyik alapfeltétele a gondos kódolás. Törekedni kell rá, hogy a kód ne tartalmazzon súlyos hibákat, legyen a lehető legtisztább és legmodernebb, hogy a képernyőolvasók és egyéb kisegítő programok gond nélkül tudják olvasni és értelmezni (4.1.1 Parsing).

Például alapvető, hogy minden HTML-címkének van nyitó- és zárótagja, a HTML-elemeket a rendeltetésüknek megfelelően használjuk, megfelelően vannak egymásba ágyazva és nincsenek bennük ismétlődések. 

Logikus felépítés

A tartalom vizuális megjelenítésével jelzett kapcsolatoknak és összefüggéseknek akkor is érthetőnek kell lenniük, ha a formázást kivesszük a képletből – vagyis ha a formázást, a stílusokat eltávolítjuk, akkor sem sérül a szerkezet (1.3.1 Info and Relationships). 

Erre legkézenfekvőbb mód a specifikációknak megfelelően, szemantikusan megírt HTML, amelyben rendeltetésszerűen használjuk a címkéket (például a gombokat <button> címkével, a választólistákat <select> címkével jelöljük meg).

A dinamikus weboldalakon, tartalmakban, a felhasználói felület nem HTML-elemei esetében is ugyanúgy meg kell határozni a kisegítő technológiák által értelmezhető nevet, szerepet és értéket (4.1.2 Name, Role, Value). Ebben segítenek az ARIA attribútumok.

Ha az elemek sorrendje fontos, akkor úgy kell megépíteni az oldalakat, hogy ne pusztán a formázás adja ki a sorrendet, hanem ha gép olvassa fel az oldal tartalmát, akkor is a szándékolt sorrendben olvassa fel (1.3.2 Meaningful Sequence). 

A navigáció következetessége az AA szint teljesítésének feltétele (3.2.3 Consistent Navigation). Ez azt jelenti, hogy a navigáció elemeinek (menüpontok, a tartalom bizonyos részeihez gördítő linkek, keresőmező) a website-on belül minden oldalon szerepelniük kell, mindig ugyanabban a sorrendben. 

Reszponzivitás

Ez egy reszponzív weboldal esetében már természetes, de AA szinten feltétel az is, hogy a tartalom megjelenítése ne legyen korlátozva a kijelző orientációja szerint, vagyis vízszintesen és függőlegesen is megtekinthető legyen (1.3.4 Orientation). Kivétel ez alól, amikor természeténél fogva függőleges vagy vízszintes megjelenítést kíván egy tartalom, pl. ha egy zongorabillentyűzetet használunk egy képernyőn.

Azok a weboldalak felelnek meg az AA szintnek, amelyek nem akadályozzák, hogy a böngészőkben 200%-ig fel lehessen nagyítani a szöveget anélkül, hogy a weboldal funkciói vagy a szöveg értelme sérülne (1.4.4 Resize text).

Az is feltétel, hogy (hacsak nem elkerülhetetlen, mint pl. táblázatoknál vagy térképeknél) a tartalmakat ne kelljen egyszerre függőlegesen és vízszintesen is görgetni valamilyen irányban az olvasáshoz, 400%-os nagyításnál se (1.4.10 Reflow). A jól megírt reszponzív weboldalak természetüknél fogva ezt is megoldják.

Navigálás billentyűzettel

Minden funkciónak elérhetőnek és használhatónak kell lennie kizárólag billentyűzettel (2.1.1 Keyboard, 2.1.2 No Keyboard Trap) – pontosabban az olyan funkcióknak, amelyeknek nem éppen a szabad vonalon való navigáció a lényegük, mint pl. a szabadkézi rajzolás, amelynek az esetében szerepe van a mozgás sebességének és időtartamának. Viszont például a „drag and drop” funkciónak akadálymentes verzióban támogatnia kell a másolás-beillesztés funkciót is, éppúgy, ahogy egy akadálymentes rajzolóprogramban billentyűzettel is létre kell tudni hozni objektumokat, és meg kell tudni határozni a pozíciójukat, méretüket, alakjukat.

Tehát ha meglátogatunk egy akadálymentes oldalt, akkor csak a billentyűzettel (jellemzően a tab billentyűvel) végig tudunk lépkedni minden interaktív elemen: linken, űrlapmezőn, gombon – vagyis sorban rájuk tudjuk helyezni a fókuszt. 

Az AA szintnek megfelelő weboldalakon kell lehetőséget adni arra, hogy láthatóvá lehessen tenni, éppen melyik elemen van a fókusz (2.4.7 Focus Visible). Ennek a megfelelő megvalósítására a dizájnban is lehet instrukció.

Ha a fókuszálható tartalomelemek sorrendjének a tartalom értelmét befolyásoló szerepe van, akkor a fókuszálási sorrendnek (pl. amilyen sorrendben a billentyűzettel végig lehet lépkedni az egyes tartalmi elemeken) ennek megfelelőnek kell lennie (2.4.3 Focus Order).

Azoknak, akik képernyőolvasó programmal böngészik a weboldalt, lehetőséget kell adni a website több oldalán ismétlődő elemek (pl. navigáció, keresőmező, oldalsáv, szűrők egy webshopban…) átugrására (2.4.1 Bypass Blocks). Erre használhatók például ugrólinkek, mint az oldalak legtetején, esetleg a látható területen kívül elhelyezett, csak fókuszra megjelenő „Ugrás a tartalomra” link, ami a fő tartalomhoz viszi a fókuszt.

Ügyelni kell rá, hogy pusztán az, ha a fókusz egy bizonyos elemre kerül, nem aktiválhat funkcionalitást, pl. nem küldhet be űrlapot, nyithat meg felugró ablakot, nem irányíthat át (3.2.1 On Focus).

Ha pedig gyorsbillentyűket is lehet használni a tartalomban, amelyek nyomtatható karakterekből állnak (betűk, számok, szimbólumok, központozás), akkor kikapcsolhatóvá kell tenni a gyorsbillenytűs funkciót, vagy módosíthatóvá kell tenni úgy, hogy a karakter kombinálható legyen valamilyen nem nyomtatható karaktert előidéző billentyűvel (pl. Ctrl, Alt), és/vagy csak akkor aktiválódjon, ha az az elem van fókuszban (a felhasználó arra az elemre lépett pl. a tabulátorral), ami a gyorsbillentyűvel működtethető (2.1.4 Character Key Shortcuts). Ez azért fontos, hogy elkerülhető legyen a véletlen aktiválás. 

Űrlapok, címkék, rendszerüzenetek 

Az űrlapok működésének kiszámíthatónak kell lennie (3.2.2 On Input). A weboldal nem küldheti be az űrlapot automatikusan, nem változtathatja meg az egész oldal struktúráját valamelyik mező kitöltésekor, nem állíthatja át a fókuszt automatikusan egy mező kitöltése után – illetve ha mégis, erről a működésről egyértelműen előre tájékoztatnia kell a felhasználókat.

Természetesen minden funkció (pl. gombok, rádiógombok, jelölőnégyzetek, űrlapmezők) címkéjéhez (label) kell egyértelmű, szöveges információ az adott funkcionalitásról (3.3.2 Labels or Instructions).

A gombok feliratainak, a beviteli mezők címkéinek lehetőleg láthatónak, egyedinek kell lenniük, és beazonosíthatónak kell lennie, hogy melyik elemre vonatkozik a címke (2.5.3 Label in Name). Ha mindez megvalósul, akkor a címke akadálymentesnek tekinthető.

Előfordulhat, hogy a képernyőolvasó segítségével böngésző felhasználók dolgának megkönnyítésére a kódban egy akadálymentes nevet is adunk az adott elemhez. Ha így van, akkor ez a név lesz az, amit a hangvezérlő programmal dolgozó látogatóknak hangosan ki kell mondaniuk az elem aktiválásához, ezért a kódban hozzáadott névnek a látható címkével kell kezdődnie.

AA szinten az olyan űrlapmezőknél, amelyek a felhasználó adatainak bekérésére szolgálnak, nemcsak látható címkével, hanem a kódban, a gépek által egyértelműen azonosíthatóan is meg kell hogy legyen jelölve, pontosan milyen adat kerül az adott mezőbe (1.3.5 Identify Input Purpose).

Ha ezeket a mezőket a kódban megjelöljük a megfelelő tokenekkel (pl. a keresztnév mezőt így: autocomplete="given-name"), akkor az automatikus kitöltés pontosan működik majd a böngészőkben, sőt bizonyos szoftverek az adott felhasználó speciális igényeinek megfelelő módon is akadálymentessé tudják tenni ezeket a mezőket (pl. meg tudnak jeleníteni az adott felhasználó számára a szövegnél könnyebben értelmezhető ikonokat). 

Egyértelműen és konkrétan tudatni kell a felhasználókkal azt is, ha valamilyen hiba történik az oldalon vagy az oldal használata során (3.3.1 Error Identification).  Ha például egy űrlapon egy mezőt rosszul vagy nem tölt ki a felhasználó, értesíteni kell róla, méghozzá szöveges formában (is) – vagyis nem elég pusztán a mező színét megváltoztatni, mondjuk, pirosra. Erre már a webdizájn készítése vagy dizájnsablon kiválasztásakor gondolhatunk.

AA szintű követelmény, hogy amikor a felhasználónak adatot kell bevinnie (tipikusan űrlapokon) egy weboldalon, akkor tájékoztatni kell a helyes kitöltés módjáról, illetve hibás adatbevitel után a hiba tényének közlése mellett segítséget is kell nyújtani a helyes kitöltéshez (3.3.3 Error Suggestion).

Például ha hónapot kell megadnia, de csak a hónap nevét fogadja el az űrlap, már a mezőnél odaírhatjuk: „Írja be a hónap nevét”. Ezzel kiküszöbölhető, hogy esetleg azt írja be: „12”.

Az olyan weboldalakon, ahol jogi, pénzügyi vagy adatvesztéssel járó hibák fordulhatnak elő, lehetőséget kell adni a törölt információ visszaállításra, vagy a bevitt adatokat a rendszernek ellenőriznie kell és felkínálni a lehetőséget a javításra, vagy lehetőséget kell adni a felhasználónak a beküldés vagy véglegesítés előtti ellenőrzésre (3.3.4 Error Prevention).

Arról is gondoskodni kell, hogy az olyan rendszerüzenetek, állapotüzenetek, amelyek a látók számára feltűnőek, de nem kerül rájuk a fókusz, se kerüljék el a képernyőolvasóval böngésző felhasználók figyelmét (4.1.3 Status Messages).

Ilyen állapotüzenetek például a kosárba tétel után a kosár mellett megjelenő „5 termék”, a Több megjelenítése gomb lenyomása után a töltődést jelző animáció, a hibásan kitöltött űrlapmező felett megjelenő „hibás adat” felirat, sikeres beküldés után a „sikeres beküldés” üzenet stb. 

Automatikus lejátszás

Ha egy weboldal automatikusan, 3 másodpercnél hosszabb hangot játszik le, akkor lehetővé kell tenni a hang leállítását, vagy a rendszer hangerejétől független, weboldalon belüli hangerőszabályozását (1.4.2 Audio Control). Ez azért fontos, mert a képernyőolvasót használó látogatók az automatikusan lejátszott hang miatt nem hallják a felolvasott tartalmat.

Hover

Lehetnek olyan tartalmi elemek a weboldalakon, amelyek akkor jelennek meg, ha egy bizonyos elem fölé mozgatjuk a kurzort, vagy a billentyűzetet használva egy elemre fókuszálunk. AA szinten az így megjelenő plusz tartalmi elemeknek eltüntethetőnek kell lenniük a kurzor vagy a fókusz elmozdítása nélkül, pl. az Esc gomb lenyomásával (hogy az általuk eltakart tartalmakat ismét látni lehessen), a kurzort a plusz tartalom fölé kell tudnunk mozgatni anélkül, hogy eltűnne a plusztartalom (hogy elolvasható legyen, ha úgy jelent meg, hogy a kurzor eltakarja egy részét), illetve nem tűnhet el a plusztartalom anélkül, hogy a kurzort elmozgatnánk vagy a fókuszt levennénk róla (hogy legyen idő elolvasni) (1.4.13 Content on Hover or Focus).

Időlimitek

Ha a tartalom elolvasására vagy a tartalommal való interakcióra egy bizonyos időtartam áll a felhasználó rendelkezésére, akkor lehetővé kell tenni, hogy a felhasználó kikapcsolhassa, legalább az alapbeállítottnak a tízszeresére módosíthassa az időlimitet, vagy legalább 20 másodperccel az időlimit lejárta előtt egyszerűen (pl. a szóköz billentyű lenyomásával) kitolhassa a határidőt az alapbeállított rendelkezésre álló időtartamnak szintén a tízszeresére (2.2.1 Timing Adjustable). 

Az automatikusan frissülő, legördülő, mozgó tartalmaknál vagy tartalmi elemeknél (pl. automatikusan frissülő időjárás-jelentési adatok), amelyeknél a tartalom bizonyos időközönként frissül, megváltozik vagy eltűnik, lehetővé kell tenni, hogy a felhasználó megállíthassa vagy elrejthesse a tartalmat (2.2.2 Pause, Stop, Hide). 

Ez azért kell, hogy annak is elegendő ideje legyen elolvasni a tartalmat, aki lassabban tudja feldolgozni.

Visszavonhatóság

Az egy pontra rámutatással (kiválasztásával, lenyomásával) működtethető funkcióknak megszakíthatóknak, visszavonhatóknak kell lenniük (2.5.2 Pointer Cancellation). Ez azért kell az akadálymentességhez, hogy azoknak, akiknek nehézségeik vannak pl. a pontos mozgással, legyen lehetőségük korrigálni a téves mozdulatokat.

Egy egyszerű linkkel nincs dolgunk, hiszen az alapból csak akkor aktiválódik, ha az egér gombját elengedjük vagy az ujjunkat felemeljük a képernyőről – ha a lenyomás után nyomva tartjuk és elmozgatjuk a képernyő más területére a kurzort vagy az ujjunkat, akkor a gomb elengedése vagy az ujjunk felemelése nem aktiválja a linket, amire rákattintottunk.

De például egy drag and drop funkció esetében lehetővé kell tenni, hogy ha a célmező előtt elengedi a felhasználó az elemet, amit felvett, akkor megszakítódjon a tevékenység (ahelyett, hogy pl. automatikusan beugrana az elem a célmezőbe).

Szöveges alternatívák

A nem szöveges tartalmakhoz szöveg alapú alternatívát kell készíteni (1.1 Text Alternatives), vagyis lehetővé kell tenni a tartalomszerkesztők számára, hogy a képekhez, amelyeket feltöltenek a HTML tartalomszerkesztőbe vagy a médiatárba, alternatív leírást tudjanak készíteni. Ha vannak képes elemek, amelyeket a honlap szerkesztői nem tudnak módosítani, akkor ezeknél már a fejlesztés során el kell készíteni az alternatív leírást. 

A szöveges alternatívára nemcsak a képek esetében kell gondolni, hanem olyan esetekben is, amikor például hangeffektus jelez valamit a felhasználónak. Például ha egy online kvízben hangeffektus jelzi a jó vagy a rossz választ, akkor egy akadálymentes weboldalon ilyenkor szövegesen is meg kell jeleníteni a válasz értékelését. 

Mivel nincs olyan CAPTCHA-típus, amit minden felhasználó meg tudna oldani, az a megegyezés született, hogy két különböző fajta CAPTCHA felkínálásával (pl. egy képes és egy szöveges alapú) eleget lehet tenni az akadálymentesség követelményének. Ha teljesen biztosra akarunk menni, akkor kerüljük a CAPTCHA-t, és keressünk más megoldást az űrlapok védelmére.

Az elemek funkcióját sem elég az elem alakjával, színével, az oldalon való elhelyezésével stb. jelölni, hanem szöveges formában is ki kell fejteni (1.3.3 Sensory Characteristics). Például egy többoldalas kérdőivben nem pusztán egy zöld nyíl jelzi a következő oldalra lapozási lehetőséget, hanem szöveges instrukciót is adunk hozzá. Ez lehet akár a weboldalon megjelenített szövegben kifejtett instrukció (pl. „Az utolsó kérdés alatt, jobb oldalon található, »Következő« feliratú zöld nyílra kattintva lapozhat a következő oldalra”).

Nyelvek

Akadálymentességi szempontból az érthetőséget segíti, ha az oldal nyelve meg van határozva a HTML-ben a lang címkével (pl. lang="hu") (3.1.1 Language of Page). Ennek köszönhetően ugyanis a képernyőolvasók biztosan a megfelelő kiejtéssel olvassák fel a szöveget, a böngészők helyesen jelenítik meg a karaktereket, a videók a megfelelő nyelvű feliratot jelenítik meg stb. 

AA szinten követelmény, hogy ha egy weboldalon belül több nyelvet használunk, ezeket az idegen nyelven írt szövegrészeket is külön-külön megjelöljük a megfelelő lang HTML címkével (3.1.2 Language of Parts).