Kinek kötelező az akadálymentes weboldal 2026-ban?

Az akadálymentes weboldal olyan online felület, amelyet eltérő képességekkel, eszközökkel és használati módokkal érkező emberek is ténylegesen tudnak kezelni. Nem elég, ha az oldal technikailag betöltődik. A tartalomnak érthetőnek kell maradnia képernyőolvasóval, a fontos funkciókat billentyűzettel is el kell érni, a szövegnek olvashatónak kell lennie, az űrlapoknak pedig egyértelműen jelezniük kell, mit várnak a felhasználótól.

Az akadálymentességet sokan még mindig egy kontrasztváltó gombbal vagy egy betűméret-növelő eszközzel azonosítják. Arról, hogy miért fontos az akadálymentes weboldal, egy korábbi cikkünkben részletesebben is írtunk. Ezek bizonyos helyzetekben hasznosak lehetnek, de önmagukban nem tesznek akadálymentessé egy rosszul felépített weboldalt.

A valódi munka mélyebben kezdődik: a tervezésnél, a HTML-struktúránál, a navigációnál, az űrlapoknál, a tartalomnál és az interakcióknál.

Kiknek segít egy akadálymentes weboldal?

A webes akadálymentességet nem érdemes kizárólag vak felhasználók szempontjából nézni. Sokféle helyzet okozhat nehézséget egy weboldal használatakor. Egy vak felhasználó például képernyőolvasóval járhatja be az oldalt. Egy gyengénlátó nagyít, erősebb kontrasztot igényelhet, vagy teljesen más méretben használja ugyanazt a felületet. Valaki egér helyett billentyűzettel navigál. Másnak a videó hangja nem hozzáférhető, ezért feliratra van szüksége.

A kognitív nehézségek szintén számítanak. Egy bonyolult űrlap, következetlen navigáció vagy félreérthető hibaüzenet sok felhasználónak problémát okozhat. Ezek egy része már túlmutat a szűken vett akadálymentességen, és általános felhasználói élmény (UX) szempontból is meghatározza, mennyire könnyen használható egy weboldal. Az akadálymentesebb tervezés olyan hétköznapi helyzetekben is jól jön, amelyeknek nincs közük tartós fogyatékossághoz. Ha valaki hang nélkül néz videót, erős napsütésben próbál olvasni egy mobilképernyőt, vagy átmenetileg csak egy kézzel tudja kezelni az eszközét, ugyanazokból a jó megoldásokból profitál.

Hogyan használ weboldalt egy vak felhasználó?

A képernyőolvasó a weboldal szerkezetéből dolgozik. Fel tudja olvasni többek között a címsorokat, linkeket, gombokat és űrlapelemeket, ha azok megfelelően vannak megadva. Ezért nem mindegy, hogy egy vizuálisan gombnak kinéző elem valóban gombként szerepel-e a HTML-ben. Ugyanez igaz a címsorokra. Ha egy szöveget csak nagyobb betűvel formázunk H2 elem helyett, attól vizuálisan címsornak látszik, de a dokumentum szerkezete nem feltétlenül tükrözi ezt.

A jó HTML-struktúra itt nem esztétikai kérdés.

Gyengénlátásnál a design döntései válnak láthatóvá

Halványszürke szöveg fehér háttéren elegánsnak tűnhet egy designterven. Használni már kevésbé kellemes. A kontraszt, az átméretezhető szöveg és az információk többféle jelölése mind olyan tervezési döntés, amelyet nem érdemes a fejlesztés végére hagyni. Ha például egy táblázatban kizárólag zöld és piros szín mutatja, melyik tétel rendben van és melyikkel van probléma, a jelentés bizonyos felhasználók számára elveszhet. Szöveges címke vagy ikon segíthet egyértelművé tenni az állapotot.

Az egér nem lehet az egyetlen út

Egy weboldal fő funkcióinak billentyűzettel is használhatónak kell lenniük ahhoz, hogy többféle felhasználói módot támogassanak. A WCAG külön követelményeket tartalmaz a billentyűzettel történő működtetésre és a fókusz kezelésére. A legegyszerűbb ellenőrzés meglepően praktikus: tegyük félre az egeret. Tabbal haladjunk végig az oldalon. Shift+Tabbal vissza. Próbáljuk megnyitni a menüt, elküldeni az űrlapot és bezárni a felugró ablakot. Ha valahol elakadunk, ott valószínűleg van mit javítani.

Mi az a WCAG?

A WCAG, vagyis Web Content Accessibility Guidelines a W3C Web Accessibility Initiative webes akadálymentességi irányelve. A jelenlegi WCAG 2.2 négy fő alapelv köré rendezi a követelményeket: a tartalom legyen észlelhető, működtethető, érthető és robusztus. A dokumentum 13 irányelvet és tesztelhető sikerkritériumokat tartalmaz.

A WCAG nem egy gyors ellenőrzőlista abból a szempontból, hogy „van alt szöveg, pipa; van kontraszt, pipa”. Több, egymással összefüggő követelményt fogalmaz meg.

Észlelhető: az információnak hozzáférhető formában kell megjelennie

Ha egy kép érdemi információt közvetít, annak megfelelő szöveges alternatívára lehet szüksége. Videónál a beszélt tartalomhoz felirat tartozhat. A szöveg és háttér közötti kontraszt sem pusztán vizuális ízlés kérdése. A lényeg, hogy a tartalom ne egyetlen érzékelési módhoz legyen kötve. Egy „pirossal jelzett mező hibás” üzenet például kevés. Ha a felhasználó nem érzékeli a színbeli különbséget, elveszíti az információt. Sokkal jobb, ha a hibás mező mellett szöveges magyarázat is megjelenik.

Működtethető: el is kell tudni érni a funkciókat

Egy webshop akadálymentessége nem áll meg ott, hogy a termékleírás olvasható. A felhasználónak el kell tudnia jutni a termékhez, kosárba kell tudnia tenni, meg kell tudnia nyitni a pénztárt és végig kell tudnia vinni a vásárlást. Ha egy lenyíló menü egér nélkül használhatatlan, akkor a mögötte lévő tartalom bizonyos felhasználóknak gyakorlatilag eltűnik. A WCAG 2.2 többek között a billentyűzetes használathoz, fókuszhoz, navigációhoz és mutatóeszközös interakciókhoz kapcsolódó sikerkritériumokat is meghatároz.

Érthető: ne kelljen kitalálni, mit akar az oldal

Az akadálymentességhez az érthetőség is hozzátartozik. Egy űrlapmező mellett legyen világos, milyen adatot kérünk. Ha hiba történik, derüljön ki, melyik mezővel van probléma és hogyan lehet javítani. A következetes navigáció szintén sokat számít. Ha ugyanaz a funkció egyik oldalon más néven és más helyen jelenik meg, mint egy másikon, fölöslegesen nehezítjük a használatot.

Robusztus: a technikai szerkezetnek is rendben kell lennie

Egy weboldalt nem kizárólag az aktuális böngésző vizuális megjelenítésére tervezünk. A HTML és a komponensek szerkezetének olyan információt kell adniuk, amelyet a különböző felhasználói eszközök és kisegítő technológiák is értelmezni tudnak. Ezért fontos a szemantikus HTML, és ezért kell óvatosan bánni az egyedi JavaScript-komponensekkel.

Mit jelent az A, AA és AAA WCAG-szint?

A WCAG három megfelelőségi szintet használ: A, AA és AAA. Az A az alapszint, az AA magában foglalja az A és AA követelményeket, az AAA pedig mindhárom szintet.

Szint - Röviden
A - Az alapvető akadálymentességi követelmények
AA - Az A mellett további, szigorúbb követelmények
AAA - A legmagasabb szint, az A és AA követelményekkel együtt

A szintekből azonban nem érdemes olyan következtetést levonni, hogy minden magyar weboldalra automatikusan ugyanaz a jogi követelmény vonatkozik. A kötelezettség attól függ, hogy milyen szervezet és milyen szolgáltatás oldaláról beszélünk. A jogi megfelelés és a WCAG technikai megfelelés kapcsolódik egymáshoz, de nem ugyanaz a kérdés.

Mitől lesz egy weboldal ténylegesen akadálymentes?

Az akadálymentesség sok apró döntésből áll össze. Néhány közülük már a designnál eldől, másokat a frontend kód határoz meg, és olyan is van, amit később a tartalomszerkesztő ronthat el.

A címsoroknak valódi szerkezetet kell adniuk

A H1, H2 és H3 elemek nem egyszerű betűméretek. Azt jelzik, hogyan épül fel a tartalom. Ha egy cikk címe H1, a fő fejezetek H2, azok részei pedig H3 elemek, a szerkezet vizuálisan és technikailag is értelmezhetőbb. Nem kell mindenáron minden címsorszintet használni. A hierarchia legyen logikus.

A képek alternatív szövege nem kulcsszómező

Az alt szöveg célja, hogy a kép által közvetített releváns információ szövegesen is hozzáférhető legyen.

Rossz alt szöveg: kép
Ugyanilyen rossz lehet egy kulcsszavakkal teletömött leírás, amelynek nincs köze ahhoz, mit mutat a kép. Ha például egy képernyőkép egy CRM ügyféladatlapját szemlélteti, megfelelő kontextusban hasznos lehet egy ilyen leírás: CRM ügyféladatlap az ügyfél alapadataival és nyitott ajánlataival
Dekoratív képnél más megoldás lehet helyes. Nem minden grafikai elemhez kell hosszú leírást írni.

Legyen látható, hol jár a billentyűzetes felhasználó

Tabbal navigálva mindig tudni kell, melyik interaktív elem aktív. A fókuszjelzés eltüntetése pusztán azért, mert „nem szép a keret”, rossz kompromisszum. A WCAG 2.2 külön foglalkozik a fókusz láthatóságával és azzal is, hogy a fókuszba kerülő elem ne legyen teljesen eltakarva más tartalom által.

Ne csak színnel mondjuk meg, mi történt

Vegyünk egy regisztrációs űrlapot. A felhasználó hibás e-mail-címet ad meg. A mező kerete piros lesz.
Ez vizuálisan jól észrevehető lehet, de önmagában kevés. Célszerű szövegben is megmondani, mi a gond:
„Az e-mail-cím formátuma hibás. Példa: nev@ceg.hu”
Ebből már lehet dolgozni.

Hogyan legyen akadálymentes a navigáció?

A jó navigációt nem kell újratanulni minden oldalon. A menüpontok elnevezése legyen érthető, az elrendezés pedig következetes. Billentyűzetes használatkor ugyanúgy el kell tudni jutni a menübe és az almenükbe, mint egérrel.
Itt jön elő egy kevésbé látványos, de hasznos megoldás: a skip link.

Mire jó az „Ugrás a tartalomra” link?

Képzeljük el, hogy egy oldal tetején húsz navigációs elem található. Egérrel egy pillanat alatt átugorjuk őket. Billentyűzettel viszont minden új oldalbetöltésnél végig kellene lépkedni rajtuk, mielőtt elérjük a fő tartalmat. Az „Ugrás a tartalomra” link ezt rövidíti le. A felhasználó át tudja ugrani az ismétlődő navigációs blokkot. Nem különösebben látványos funkció. Használat közben annál értékesebb.

Az akadálymentes űrlap nem csak szép mezőkből áll

Az űrlapoknál hamar kiderül, hogy mennyire átgondolt a felület. Vegyünk egy ilyen mezőt:
[ Írd ide az e-mail-címed ]
Ha a mező üres, a placeholder látható. Amint írni kezdünk, eltűnik.
Ha nincs külön címke, később már nem biztos, hogy egyértelmű, mi tartozik az adott mezőbe. A megfelelően kapcsolt label sokkal stabilabb megoldás. A kötelező mezőket is érthetően kell jelezni. Ha beküldéskor hiba van, ne csak annyi jelenjen meg, hogy „sikertelen”.
Mondjuk meg, mi történt.

„A telefonszám mező kötelező.”
„Az e-mail-cím formátuma nem megfelelő.”
„A jelszónak legalább az előírt követelményeket teljesítenie kell.”

Minél pontosabb a visszajelzés, annál könnyebb kijavítani a hibát.

Képek, videók és hanganyagok akadálymentesítése

A multimédiás tartalomnál azt kell megnézni, milyen információ veszne el, ha valaki nem látja a képet vagy nem hallja a hangot. Egy dekorációs háttérfotó egészen más kategória, mint egy grafikon, amelyből az egész fejezet fő következtetése kiolvasható. Utóbbinál a lényeges információnak más módon is hozzáférhetőnek kell lennie. Videónál ugyanez történik a hanggal.

Ha a lényegi tartalom kizárólag szóban hangzik el, a hallássérült felhasználó megfelelő alternatíva nélkül kimarad belőle. A WCAG a prerecorded multimédiás tartalmakhoz kapcsolódóan többek között feliratokra és alternatívákra vonatkozó követelményeket is tartalmaz. Az automatikusan induló hanggal pedig érdemes különösen óvatosnak lenni. Nemcsak zavaró lehet, hanem egy képernyőolvasót használó felhasználónak a felolvasott tartalom megértését is megnehezítheti.

Mobilon sem tűnik el az akadálymentesség

Az akadálymentességet könnyű asztali gépre szűkíteni, pedig ugyanazt az oldalt sokan érintőképernyőn használják. Mobilon előjön az interaktív elemek mérete, a nagyíthatóság, a képernyő elforgatása és az egymásra csúszó tartalmak kérdése. A WCAG 2.2 újabb sikerkritériumai között a húzó mozdulatok alternatívája és a célterületek minimális mérete is megjelent. Egy apró bezárógomb például egérrel még könnyen eltalálható lehet. Telefonon már sokkal kevésbé.

Hogyan ellenőrizhető egy weboldal akadálymentessége?

Egyetlen eszközzel nem lehet megbízhatóan eldönteni, hogy egy összetett weboldal megfelelően akadálymentes-e. Az automatikus ellenőrzés hasznos kezdés. A kézi teszt ugyanilyen fontos.

Automatikus eszközökkel gyorsan megtalálhatók bizonyos hibák

Használhatók például olyan ellenőrzők, mint a Lighthouse, axe vagy WAVE. Ezek képesek különféle technikai problémák jelzésére. Jó kiindulópontot adnak, főleg egy nagyobb oldal első átvizsgálásakor. De egy automata nem tud minden kérdésre válaszolni. Lehet például technikailag alt attribútuma egy képnek úgy, hogy a benne szereplő szöveg teljesen értelmetlen. A gép látja, hogy van alt. Azt már nem feltétlenül tudja eldönteni, hogy valóban hasznos-e.

Billentyűzettel öt perc alatt is találhatunk komoly problémát

Induljunk az oldal tetejéről, és használjuk csak a billentyűzetet.

• Elérhető a menü?

• Látjuk, hol van a fókusz?

• Megnyitható egy lenyíló rész?

• Be lehet zárni a felugró ablakot?

• Elküldhető az űrlap?

Néhány ilyen próba nagyon gyorsan megmutatja, ha a weboldal alapvető interakcióit csak egérhasználatra tervezték.

Képernyőolvasóval egészen más oldal rajzolódhat ki

A VoiceOver, NVDA és más képernyőolvasók segítségével meg lehet hallgatni, hogyan értelmezhető az oldal vizuális információ nélkül. Itt derülhet ki például, hogy öt egymást követő gomb mindössze annyit mond: „Tovább”. Vagy hogy egy modális ablak megnyílik ugyan, de a képernyőolvasó fókusza továbbra is a mögötte lévő oldalon marad.

A WCAG-t kézzel is végig kell gondolni

A W3C külön Quick Reference felületet tart fenn a WCAG 2.2 sikerkritériumainak és kapcsolódó technikáinak áttekintésére. Komolyabb ellenőrzésnél nem elég egy böngészőbővítmény zöld pontszáma. A releváns sikerkritériumokat egyenként kell értékelni.

Elég egy akadálymentességi plugin?

Röviden: nem.

Egy plugin tud adni betűméret-választót, kontrasztmódot vagy más kiegészítő vezérlőt. Ettől azonban egy billentyűzettel nem használható menü nem kezd automatikusan jól működni. A címke nélküli űrlap sem kap megfelelő szerkezetet pusztán egy látványos accessibility widgettől. Ugyanez igaz a hibás modal ablakokra, fókuszkezelésre és egyedi JavaScript-komponensekre.
Az akadálymentességet érdemes a rendszer részeként kezelni, nem utólag ráhelyezett rétegként.

Utólag is akadálymentesíthető egy meglévő weboldal?

Igen. Az viszont csak felmérés után derül ki, mekkora munka. Van olyan weboldal, ahol sok probléma kisebb javításból áll: hiányzó alternatív szövegek, gyenge kontraszt, rossz linkfeliratok, hiányos űrlapcímkék.

Máshol a gond mélyebben van. Ha a teljes navigáció egyedi JavaScriptre épül, billentyűzettel nem kezelhető, a HTML-szerkezet hibás, és a komponensek több ponton sem adják át megfelelően az állapotukat a kisegítő technológiáknak, már komolyabb fejlesztésre lehet szükség. Ilyenkor az akadálymentesítés könnyen összekapcsolódhat az egyedi weboldalfejlesztéssel vagy a meglévő frontend részleges újraépítésével.

Egy audit célja éppen az, hogy ezt szétválassza. Mi javítható gyorsan? Mi érinti a design systemet? Hol kell komponenst újraépíteni? Melyik hiba akadályoz meg ténylegesen egy fontos feladatot? A prioritás sem mindegy.

Kinek kötelező akadálymentes weboldalt működtetnie Magyarországon?

Itt óvatosan kell bánni az általánosításokkal. Nem igaz az az egyszerű állítás, hogy 2025-től minden magyar céges weboldalnak ugyanazokat az akadálymentességi követelményeket kell teljesítenie.
A szabályozás hatálya attól függ, milyen szervezetről és milyen szolgáltatásról van szó.

A közszférabeli honlapokra külön szabályozás vonatkozik

A 2018. évi LXXV. törvény a közszférabeli szervezetek honlapjain közzétett tartalmakra és az általuk készített mobilalkalmazásokra állapít meg akadálymentességi szabályokat. A törvényhez végrehajtási szabályok is kapcsolódnak, többek között az akadálymentesítési nyilatkozatra vonatkozóan.

2025. június 28-tól az Európai Akadálymentességi Irányelv alapján újabb szolgáltatások kerültek a szabályozás körébe

Az EU European Accessibility Act néven ismert 2019/882 irányelvének követelményeit 2025. június 28-tól kell alkalmazni az irányelv hatálya alá tartozó termékekre és szolgáltatásokra. A felsorolt területek között e-kereskedelmi szolgáltatások is szerepelnek. Magyarországon a termékekre és szolgáltatásokra vonatkozó akadálymentességi követelmények általános szabályait a 2022. évi XVII. törvény rendezi. Ebből azonban nem szabad azt levezetni, hogy minden vállalkozás minden weboldala automatikusan ugyanolyan kötelezettség alá esik. A törvény hatálya, a szolgáltatás típusa, illetve az esetleges kivételek külön vizsgálatot igényelnek.

Ha egy vállalkozás számára a kérdés jogi megfelelés miatt fontos, a saját szolgáltatására vonatkozó kötelezettséget érdemes az aktuális jogszabály és szükség esetén jogi szakértő alapján meghatározni.

Mi az akadálymentességi nyilatkozat?

A közszférabeli szervezeteknél az akadálymentesítési nyilatkozat szabályozott dokumentum. A magyar végrehajtási rendelet az uniós mintanyilatkozatra épülő forma alkalmazását írja elő. A nyilatkozat célja nem az, hogy az oldal egyszerűen kijelentse magáról: „akadálymentes”. A tényleges megfelelési állapotról, az esetleges nem akadálymentes tartalmakról és a kapcsolódó információkról ad tájékoztatást. Ez már jogi megfelelési terület, ezért üzleti weboldalnál nem érdemes automatikusan lemásolni egy közintézmény nyilatkozatát anélkül, hogy tudnánk, milyen szabály vonatkozik az adott szervezetre.

Az akadálymentesség és a SEO ugyanaz?

Nem. Van köztük átfedés, de a két terület célja más. A logikus címsorstruktúra, a jól felépített HTML, az érthető linkek és a megfelelő képleírások több szempontból is jó webes gyakorlatnak számítanak. Ettől még nem igaz, hogy egy SEO-szempontból jól optimalizált oldal automatikusan akadálymentes. Fordítva sem lehet biztos rangsorolási előnyt ígérni pusztán azért, mert egy oldal WCAG-megfelelő.

A keresőoptimalizálás és az akadálymentesség több helyen ugyanabba az irányba tereli a fejlesztést: világosabb szerkezet, értelmezhető tartalom és technikailag rendezettebb oldal felé.

Ennél erősebb rangsorolási ígéretet azonban nem lenne szakmailag indokolt tenni.

Gyakori akadálymentességi hibák weboldalakon

Sok probléma nem különleges technikai hiba. Egyszerűen olyan döntés, amelyet a fejlesztéskor senki nem próbált ki más használati móddal.

Tipikus eset például:

• halvány szöveg alacsony kontraszttal;

• billentyűzettel nem kezelhető menü;

• eltávolított fókuszjelzés;

• alt szöveg nélküli információt hordozó kép;

• kizárólag színnel jelzett állapot;

• címke nélküli űrlapmező;

• értelmetlen „Kattints ide” link;

• felirat nélküli, érdemi beszédet tartalmazó videó;

• nehezen vagy billentyűzettel egyáltalán nem bezárható popup;

• logikátlan címsorhierarchia.

Ezek egy része automatával is megtalálható. Másokhoz kézi teszt kell.

Az ARIA nem javít meg automatikusan egy rosszul felépített felületet

Az ARIA attribútumok arra szolgálnak, hogy bizonyos webes komponensekről és állapotokról megfelelő információt lehessen átadni a kisegítő technológiáknak. De nem érdemes ott bonyolítani a megoldást, ahol natív HTML-elemmel ugyanaz egyszerűbben és megfelelően megoldható. Egy valódi <button> elem eleve sok olyan viselkedést biztosít, amit egy kattintható <div> esetében külön kellene újra megvalósítani. Kevesebb varázslat, több jó alap.

Az akadálymentességet már a tervezésnél el lehet kezdeni

Ha a projekt végén kerül elő először a WCAG, a javítás jóval kellemetlenebb lehet. A UI/UX tervezés során már a komponensek kialakításakor megadhatók a fókuszállapotok, hibajelzések, megfelelő kontrasztok és azok a vizuális állapotok, amelyekre később a fejlesztés épül. A UX-tervezésnél ki lehet szűrni a túl bonyolult folyamatokat. Az érthető navigáció, az egyértelmű visszajelzések és a logikus folyamatok általánosságban is meghatározzák a felhasználói élmény minőségét. A frontend fejlesztő használhat megfelelő szemantikus HTML-t, kezelheti a billentyűzetes navigációt, és olyan dinamikus komponenseket építhet, amelyek állapota a kisegítő technológiák számára is értelmezhető.

Az akadálymentesség tehát egyike azoknak a szempontoknak, amelyeket már a tervezési döntéseknél figyelembe kell venni. A struktúráról, használhatóságról és további tervezési kérdésekről a webhelytervezés legfontosabb szempontjairól szóló cikkünkben írtunk részletesebben.

A tartalomszerkesztő szerepe sem ér véget a szöveg feltöltésével. Egy technikailag jól megépített oldalon is létrejöhet hibás címsorhierarchia. Feltölthető információt hordozó kép alt szöveg nélkül. Egy jó linkfelirat pedig lecserélhető tíz darab „Tovább” linkre. Az akadálymentesség emiatt inkább folyamat, mint egyszeri fejlesztési feladat.

Új projekt esetén ezért célszerű az akadálymentességi szempontokat már a weboldal tervezése során beépíteni a struktúrába és a komponensek működésébe, ahelyett hogy az elkészült oldalra próbálnánk utólag ráilleszteni őket.

Mennyi munka egy meglévő weboldal akadálymentesítése?

Erre audit nélkül nincs korrekt általános válasz. Egy kisebb, technikailag rendezett bemutatkozó oldal és egy több ezer termékes webshop egészen más feladat. A munka mennyiségét befolyásolhatja többek között a frontend jelenlegi állapota, az alkalmazott CMS, az egyedi komponensek, az űrlapok száma, a videós tartalom, a dokumentumok és az elvárt megfelelési szint.

A jó sorrend általában:
felmérés → hibák besorolása → prioritások → javítás → újratesztelés

A súlyosságot is érdemes nézni. Egy apró vizuális eltérés és egy olyan hiba, amely miatt valaki egyáltalán nem tudja elküldeni a megrendelést, nem kerülhet ugyanarra a prioritási szintre.

Gyakori kérdések az akadálymentes weboldalakról

Mit jelent az akadálymentes weboldal?

Olyan weboldalt jelent, amelynek tartalma és fő funkciói különböző képességekkel és kisegítő technológiákkal is hozzáférhetők. Ide tartozik például a billentyűzetes használhatóság, a megfelelő kontraszt, az érthető űrlapok és a képernyőolvasók számára értelmezhető szerkezet.

Mi az a WCAG?

A WCAG a Web Content Accessibility Guidelines rövidítése. A W3C Web Accessibility Initiative által gondozott webes akadálymentességi irányelv, amely tesztelhető sikerkritériumokat határoz meg. A jelenlegi WCAG 2.2 négy alapelvre épül: észlelhetőség, működtethetőség, érthetőség és robusztusság.

Mit jelent a WCAG AA?

A WCAG három megfelelőségi szintet különböztet meg: A, AA és AAA. AA megfelelőség esetén az alkalmazandó A és AA szintű sikerkritériumokat is teljesíteni kell.

Kötelező minden weboldalnak akadálymentesnek lennie?

Nem lehet ilyen általánosan kijelenteni. Magyarországon a közszférabeli honlapokra külön törvény vonatkozik, az EU European Accessibility Act alapján pedig 2025. június 28-tól meghatározott termékekre és szolgáltatásokra – köztük bizonyos e-kereskedelmi szolgáltatásokra – további akadálymentességi követelmények alkalmazandók. Az adott weboldal jogi helyzetét a szolgáltatás és a szervezet alapján kell vizsgálni.

Lehet egy WordPress-weboldal akadálymentes?

Igen. A CMS önmagában nem dönti el az eredményt. A használt sablon, bővítmények, egyedi fejlesztések, szerkesztett tartalom és a teljes frontend együtt határozza meg, hogyan használható az oldal.

Elég egy akadálymentességi plugin?

Nem. Egy kiegészítő vezérlő nem képes automatikusan kijavítani minden szerkezeti, navigációs, űrlap- vagy fókuszkezelési problémát.

Automatikusan ellenőrizhető a WCAG-megfelelőség?

Csak részben. Automatikus eszközökkel sok technikai hiba megtalálható, de számos sikerkritérium és használhatósági kérdés kézi vizsgálatot igényel. A W3C a WCAG kritériumaihoz részletes ellenőrzési és értelmezési segédanyagokat is biztosít.

Utólag is akadálymentesíthető egy weboldal?

Igen. A szükséges munka viszont az oldal jelenlegi technikai állapotától függ. Egy audit segít eldönteni, hogy kisebb tartalmi és UI-javításokról van szó, vagy mélyebb frontend-átalakítás szükséges.

Javítja az akadálymentesség a SEO-t?

Nem érdemes közvetlen rangsorolási előnyt ígérni. Sok jó akadálymentességi gyakorlat – például a logikus szerkezet és az értelmes tartalom – egy jól felépített weboldalnak is része, de a WCAG-megfelelőség önmagában nem jelent garantált jobb Google-helyezést.

Az akadálymentesség nem egy kapcsoló a weboldal sarkában

Egy weboldal nem attól lesz akadálymentes, hogy kap egy ikont, amely megnyit egy accessibility menüt. Az igazi kérdés sokkal egyszerűbb:
A felhasználó hozzáfér a tartalomhoz, és végre tudja hajtani azt a feladatot, amiért az oldalra érkezett?
Ha webshopról van szó, tud vásárolni. Ha szolgáltatói oldalról, tud ajánlatot kérni. Egy ügyfélportálon el tudja intézni az ügyét. Egy közintézményi oldalon hozzáfér a szükséges információhoz.
Ehhez a designnak, a tartalomnak és a fejlesztésnek együtt kell működnie.
A jó hír az, hogy sok akadálymentességi döntés egyszerűbbé és következetesebbé teszi a felületet mindenki számára. Nem külön weboldalt építünk egy másik felhasználói csoportnak.
Ugyanazt az oldalt tervezzük úgy, hogy kevesebb ember előtt legyen akadály.