HU

 

A és AA szintű akadálymentességi követelmények a weboldalakon

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. 

Ezek közül vannak a dizájnra vonatkozó előírások, tehát ezekről a webdizájnereknek kell gondoskodniuk – vagy olyan dizájnsablont kell választani, amely eleget tesz az akadálymentesség követelményeinek. 

Más akadálymentességi előírásoknak való megfelelésről a webfejlesztőknek kell gondoskodniuk, vagyis úgy kell felépíteniük a website-ot, annak szerkezetét és működését, hogy megfeleljen ezeknek az előírásoknak.

A weboldal tartalmának feltöltésekor, a tartalmak frissítésekor pedig a tartalomszerkesztőknek kell bizonyos szempontokat észben tartaniuk.

Az alábbiakban ezeket a követelményeket vesszük sorra, hivatkozva a WCAG 2.1 szabvány megfelelő pontjára.

""

Akadálymentes webdizájn

Színek

Az akadálymentes weboldalakon nincs olyan, hogy csak színekkel közvetítünk valamilyen információt, vagy csak különböző színek jelzik egyes elemek között a különbséget (1.4.1 Use of Color).

Egy űrlapon például nem elég csupán piros színnel jelölni a kötelező mezőket vagy épp a hibákat. Ehelyett az űrlap tetején kiírhatjuk, hogy a kötelező mezők pirosak, és ikon jelöli őket, vagy a mezőcímkékbe a tervezés során beleszámíthatjuk, hogy ki lesz írva betűkkel, hogy „kötelező”. A hibaüzenetek vizuális megjelenítését a tervezett akadálymentes működési szisztémának megfelelően szintén meg lehet tervezni.

A linkeket sem elég csupán eltérő színnel jelölni. Mivel az aláhúzás jelentése az interneten: „link”, aláhúzással nemigen jelölünk mást a neten, ez a mindenki számára – a többség számára is – teljesen egyértelmű és egyben a legbiztosabban akadálymentes linkjelölés.

Ha mindenképpen valamilyen más linkjelölést szeretnénk alkalmazni, megfelelő lehet a nagyobb kontraszt, a félkövér betű vagy egyéb formázás is.

Kontrasztok

Érdekes, hogy csak AA szinttől követelmény a webhelyeken a megfelelő kontraszt a szöveg és a háttér között (1.4.3 Contrast), pedig a túl alacsony kontraszt a többség számára is megnehezíti a befogadást.

Gyakran látni pl. bannerképen vizuálisan zavarosnak ható szöveget, vagy szürke-fehér, sárga-fehér, pasztell-fehér háttérszín-szövegszín párosítást, ami az egyébként jól látó felhasználóknak sem könnyíti meg a dolgát.

A kontraszt ellenőrzésére több online eszköz is a rendelkezésre áll, például a WebAIM Contrast Checker alkalmazása.

A nem szöveges funkcionális weboldalelemeknél, például gomboknál, űrlapmezőknél, jelölőnégyzeteknél, ikonoknál, kördiagramok szeleteinél is van színkontrasztbeli minimum követelmény a környezethez képest: legalább 3:1 arány (1.4.11 Non-text Contrast). 

Szövegformázás

AA szinten a weboldalak szövegein belüli térközöknek is van minimumuk (1.4.12 Text Spacing). A sormagasságnak legalább másfélszeresének kell lennie a betűméretének, a bekezdések közötti térköznek legalább duplájának kell lennie a betűméretének, a betűközöknek legalább 0,12-szeresének, a szavak közti térköznek pedig legalább 0,16-szorosának kell lennie a betűméretének.

Az utóbbi kettőt egy jól megtervezett, jól olvasható font választása megoldja, az első kettő pedig nem lehet probléma egy megfelelően megírt HTML és CSS alapú weboldal esetében. 

Navigálás

Az akadálymentes weboldal grafikai tervezője megtervezheti az interaktív komponensekhez a billentyűfókusz (2.4.7 Focus Visible) megfelelően kontrasztos és feltűnő jelzését (kiemelését, színét, bekeretezésének módját, háttérszínét stb.), amely mégis egységes a brand vagy a weboldal arculatával.

Ha egy funkciót egy bizonyos útvonalú egérmozgatással vagy ujjmozdulattal lehet használni, tervezni kell az oldalelemre egyéb működtetési lehetőséget is (2.5.1 Pointer Gestures).

Például térképen, ahol két ujjal lehet ráközelíteni vagy távolodni, általában hozzáadnak egy + és egy - gombot is, amelyekkel ugyanez végrehajtható egyszerű gombok nyomkodásával. A húzással lapozható slideshow-k, carouselek szintén kapnak egy vissza és egy előre gombot a dizájnban.

A készülék mozgatásával (pl. megdöntésével, rázásával) aktiválható funkciókhoz is fel kell kínálni, és így a webdizájnban is tervezni kell egy hagyományosabb működtetési módot (pl. megrázással bezárás mellé felkínálni egy bezárás gombot is) (2.5.4 Motion Actuation).

Animációk

Az automatikusan lejátszódó, 5 másodpercesnél hosszabb animációkhoz és az automatikusan frissülő oldalelemekhez kell tervezni olyan komponenst a felhasználói felületre, amellyel a látogató leállíthatja az animációt vagy a frissítést, illetve szabályozhatja a frissítés gyakoriságát (2.2.2 Pause, Stop, Hide). 

Vannak, akiknél bizonyos frekvenciájú villanások, gyors képváltakozások, ha hosszabbak néhány villanásnál, epilepsziás rohamot okozhatnak. Ezért egy akadálymentes weblapon csak olyan villódzó-vibráló elem lehet, amely egy egy másodperces időtartamon belül nem villan háromnál többet, vagy az egyszerre villódzó terület nem nagyobb, mint 10 foknyi látószögnek a 25%-a (2.3.1 Three Flashes or Below Threshold).

Az akadálymentes webdizájn szempontjairól a KIFÜ Web-akadálymentességi kisokosának is van egy összefoglaló videója:

Webfejlesztés akadálymentesen

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 szerepelnie 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).

Akadálymentességi szempontok a tartalomfeltöltéskor

A webhelyek akadálymentes dizájnja és fejlesztése csak fél siker: ha a tartalom feltöltése során a webhely kezelői, szerkesztői nem fordítanak figyelmet az akadálymentességre, a weboldalunk sem lesz akadálymentes.

A kép alapú tartalmak akadálymentesítését (1.1 Text Alternatives) említettük a webfejlesztéses részben, de ezzel igazi feladatuk a tartalomfeltöltőknek van. Ha olyan képeket (fotókat, infografikákat, ábrákat, grafikonokat, képbe ágyazott szövegeket, emotikonokat, ASCII-ábrákat stb.) töltünk fel, amelyeknek van információtartalmuk, nem csak díszítőelemek a weboldalon, akkor valamilyen szöveges alternatívát (alternatív leírást, képaláírást, külön oldalon elérhető szöveges változatot stb.) kell készíteni hozzájuk.

AA szinten, ahol csak lehet, a képbe ágyazott (képbe „égetett”) szöveget kerüljük, és helyette eleve úgy formázzuk meg a tartalmat, hogy a szöveges része gépek által is olvasható, feltérképezhető legyen (1.4.5 Images of Text): például tényleges szövegelem hátterét színezzük be.

Az előre felvett, csak hangot vagy csak videót tartalmazó médiához szintén szöveges alternatívát kell készíteni (1.2.1 Audio-only and Video-only, 1.2.2 Captions). Például egy hangfelvétel esetében a megnyitáskor azonnal látható linken közzétehetjük a hangfelvétel teljes szövegét. Egy hang nélküli videóhoz pedig vagy szintén szöveges leírást készíthetünk, vagy akár linkelhetünk egy hangfelvételt is, amelyen meghallgatható, mi történik a videón.

Ha a hang- vagy a videofelvétel egy szöveghez kiegészítő, alternatív média, vagyis a szöveg az elsődleges tartalom, annak alternatívája a hangfelvétel vagy videofelvétel, nem pedig fordítva, és a videó ugyanazt szemlélteti, ami a szövegben is le van írva, és ezt jelezzük is, akkor a fentiek nem szükségesek. Ilyenkor a videóhoz vagy hangfelvételhez elegendő egy olyan alternatív leírás, ami jelzi, hogy miről szól a felvétel, és hogy a teljes információ a szövegben található. 

Az olyan videókhoz, amelyek képet és hangot is tartalmaznak, feliratot vagy átiratot kell készíteni (1.2.3 Audio Description or Media Alternative). A feliratnak vagy átiratnak, akár egy forgatókönyvnek, tartalmaznia kell azokat az információkat is, amelyek csak vizuálisan jelennek meg, vagyis nem hangzanak el a narrációban vagy a szereplők szövegében, de az értelmezéshez fontosak. 

AA szinten az élő videókhoz is kell felirat, amelyben nemcsak a beszéd van írott szövegben megjelenítve, hanem a beszélő is azonosítva van, jelezve vannak a különféle hangeffektusok és más, jelentőséggel bíró hangelemek (1.2.4 Captions). 

AA szinten minden előre felvett videóhoz rendelkezésre kell állnia hangos narrációnak is, hogy a látásukban korlátozott felhasználók is tudják követni a képernyőn zajló, de egyébként ki nem mondott eseményeket (1.2.5 Audio Description).

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), és a sorrend akkor is értelmes maradjon, ha gép olvassa fel az oldal tartalmát (1.3.2 Meaningful Sequence). 

Például a címsorokat nem elég pusztán nagyobb betűkkel megjeleníteni, a felsorolás elemeit gondolatjellel kezdeni, táblázatokat a szöveg függőleges és vízszintes irányban egymás alá-mellé rendezve megjeleníteni, vagy összetartozó elemeket pusztán azonos háttérszínnel jelölni.

Mindezeket és a hasonló, szerkezeti összefüggéseket a HTML tartalomszerkesztő megfelelő funkcióinak rendeltetésszerű  használatával lehet jelölni: például a címsorokhoz a megfelelő szintű címsor 1, címsor 2 stb. kiválasztásával, a felsorolás és számozott felsorolás gomb használatával, táblázatok létrehozásához és formázásához szóközök és félkövérítés helyett a táblázat beszúrása funkció használatával, és azon belül fejléc létrehozásával stb.

A SEO-ban (keresőoptimalizálásban) is gyakran szóba kerülő, jól megírt oldalcím (page title, a HTML <title> eleme) megléte is feltétele az akadálymentességnek (2.4.2 Page Titled). Az oldalcímet a tartalomkezelő rendszerekben könnyen tudja módosítani a webhely szerkesztője.

Az oldalcímnek rövidnek kell lennie, és kontextus nélkül is egyértelműen jeleznie kell, miről szól az oldal, hogy a felhasználók gyorsan megtalálják azt a tartalmat, amire szükségük van. Ezenkívül jó, ha az oldalcím egyedi a website-on belül, és jelzi, hogy melyik website oldalához tartozik. A tartalomkezelő rendszerekben sablont is beállíthatunk az oldalcímekhez, például hogy alapértelmezetten az oldal neve és a website neve legyen az oldalcím.

A jó, leíró linkszövegek, amelyek egyértelműen elárulják, mit tartalmaz az oldal, ahova a link mutat, értelemszerűen szintén segítik a hatékony navigációt (2.4.4  Link Purpose). Az ideális eset az, amikor a linkszöveg és a linkelt oldal címe (page title) megegyezik: ilyenkor megvan a folytonosság az értelmezésben. 

Ha például egy ikon és egy szövegrész is linkel ugyanarra a céloldalra, célszerű egyetlen linkbe kombinálni őket, hogy a képernyőolvasók ne olvassák fel ugyanazt a linket kétszer. A „Tovább” jellegű linkeknél a kontextus adja meg az információt a link céljáról (pl. hírlistában a tovább gombot megelőző rövid kivonatok, ízelítőszövegek).

AA szinten követelmény az is, hogy egy weboldalt többféle úton is el lehessen érni a website-on belül, hogy egy oldalhoz többféleképpen el lehessen navigálni – például a menüből, keresőmezővel, és/vagy szemantikus belső linkstruktúra, és/vagy oldaltérkép segítségével (2.4.5 Multiple Ways).

A szemantikus címsorszerkezet és űrlapmezőcímkék szintén feltételei az AA szint elérésének (2.4.6 Headings and Labels). A címsoroknak és a mezőcímkéknek röviden és érthetően le kell írniuk, miről szól az adott szövegrész, a címsoroknak együtt pedig értelmes, logikus, koherens oldalvázlatot kell kiadniuk. A mezőcímkéknek szintén röviden és egyértelműen kell jelezniük, milyen adatot kell beírni az adott mezőbe. 

Az azonos funkciójú elemeknek következetesen azonosíthatónak kell lenniük (3.2.4 Consistent Identification). Ha egy PDF ikon egy bizonyos dokumentum letöltését jelenti az egyik esetben, akkor az alternatív leírása például kezdődhet úgy, hogy „Töltsd le a [dokumentum rövid címe]-t”. A következő letölthető dokumentum alternatív leírása ugyanígy kezdődik majd. (A következetesség nem jelent azonosságot. Ha egy több oldalból álló tartalom egyik oldalán az első oldalra „1. oldal” linkszöveggel hivatkozunk, a 2. oldalára „2. oldal” linkszöveggel, akkor, bár a két linkszöveg nem azonos, mégis következetes.)

A tartalom akadálymentes megszerkesztéséről a KIFÜ Web-akadálymentességi kisokosában is van egy összefoglaló videó:

 

Árajánlatot kérek!