- A sablonban lévő akadálymentességi hiba minden aloldalon megismétlődik, a javítása viszont egyetlen helyen elég.
- Egy 100 pontos Lighthouse-eredmény nem jelenti, hogy a menü billentyűzettel kezelhető, vagy hogy látszik a fókusz.
- Először a billentyűzetcsapdát és az elérhetetlen funkciókat javítsd, utána a fókuszjelölést, a nyelvet és az űrlapcímkéket.
- A nyelv, a színek, az alt szövegek és a mezőcímkék a felületen is beállíthatók, a menü szkriptjéhez és a fókuszkezeléshez viszont jellemzően fejlesztő kell.
Egy weboldal akadálymentességének nagy része a sablon kódjában dől el. A fejléc, a menü, az űrlapok és a lábléc minden aloldalon ugyanaz, így ami ott jól van megírva, azt minden oldal örökli. Ami ott hibás, az minden oldalon hibás lesz, és ezen tartalomszerkesztéssel nem tudsz segíteni. Ebben a cikkben sorra vesszük a nyolc kódszinten ellenőrizhető alapot, adunk egy ellenőrzési lépéssort ingyenes eszközökkel és billentyűzetes bejárással, végül javítási sorrendet és munkamegosztást javaslunk.
A szövegben háromféle jelölést használunk. Hivatalosan igazolt, ami a W3C WCAG ajánlásában vagy más hivatalos dokumentációban szerepel. Saját tapasztalat, amit weboldalak átvizsgálásakor rendszeresen látunk. Szakmai feltételezés, amire jó okunk van, de mért vagy hivatalos bizonyítékunk nincs.
Miért a sablonnal érdemes kezdeni az akadálymentességi ellenőrzést?
Mert a sablonban lévő hiba minden oldalon megismétlődik, a javítása viszont egyetlen helyen elég. Egy WordPress-téma header.php fájlja vagy egy oldalépítő globális fejléce ugyanazt a menüt, keresőmezőt és logót teszi ki akár több száz aloldalra.
Hivatalosan igazolt. A mérce a W3C Web Content Accessibility Guidelines (WCAG) ajánlása, jelenleg a 2.2-es változat, amelyben a követelmények többsége A és AA szinten van megfogalmazva. Az Európai Akadálymentességi Irányelv (EU 2019/882) 2025. június 28-tól egyes termékekre és szolgáltatásokra, köztük az elektronikus kereskedelemre is kötelezettségeket ír elő. Hogy a te vállalkozásodra vonatkozik-e, az a mérettől és a tevékenységtől függ, ezt jogi szakemberrel érdemes tisztázni.
Saját tapasztalat. A billentyűzetes bejárás egy óra alatt több valós hibát hoz ki, mint bármelyik automata pontszám. Egy 100 pontos Lighthouse-eredmény annyit mond, hogy a gép által ellenőrizhető szabályok közül egyik sem bukott el. Arról semmit, hogy a legördülő menü kinyitható-e billentyűzettel, vagy hogy látod-e, hol jár éppen a fókusz.
Milyen nyolc alapot ellenőrizz a sablon kódjában?
A címsor-hierarchiát, a tájékozódási pontokat, az űrlapmezők címkéit, a fókuszjelölést, a menü billentyűzetes kezelését, a kontrasztarányt, a képek szöveges leírását és az oldal nyelvét. Mindegyik a WCAG 2.2 valamelyik A vagy AA szintű sikerkritériumához kötődik, és mindegyiket meg tudod nézni a böngésző fejlesztői eszközeiben.
1. Címsor-hierarchia
Oldalanként egy <h1> legyen, alatta <h2>, azon belül <h3>, szintugrás nélkül. A képernyőolvasót használók gyakran címsorról címsorra lépkedve térképezik fel az oldalt, számukra a címsorok jelentik a tartalomjegyzéket (WCAG 1.3.1, hivatalos).
Saját tapasztalatunk szerint két sablonhiba ismétlődik a leggyakrabban. A logó minden oldalon <h1>, így a valódi oldalcím a második helyre szorul. A lábléc „Kapcsolat” vagy „Hasznos linkek” felirata pedig <h4> vagy <h5>, mert a tervező a betűméret alapján választotta. A címsorszint a szerkezetet jelöli, a méretet CSS-ből állítsd.
2. Tájékozódási pontok
A fő régiókat HTML5 elemekkel jelöld, így a segítő technológia egy gombnyomással odaugorhat. A minimum ez a négy elem.
<header>a fejlécnek.<nav>a menünek. Ha több menü van,aria-labelkülönböztesse meg őket, például „Fő menü” és „Lábléc menü”.<main>a fő tartalomnak, oldalanként pontosan egyszer.<footer>a láblécnek.
Ide tartozik az ugrólink is. Az oldal első fókuszálható eleme egy „Ugrás a tartalomra” link legyen, amely a <main id="tartalom"> elemre visz. Alapból lehet vizuálisan rejtett, de fókuszra meg kell jelennie (WCAG 2.4.1, hivatalos).
3. Űrlapmezők címkéi
Minden mezőnek legyen programból kiolvasható címkéje. A helykitöltő szöveg (placeholder) erre nem elég, mert gépeléskor eltűnik, és sok segítő technológia nem kezeli címkeként. A helyes minta így néz ki.
<label for="email">E-mail-cím</label> <input id="email" type="email" autocomplete="email">
A sablonban két helyen érdemes különösen figyelni. A fejléc keresőmezője gyakran csak egy nagyítóikonból és helykitöltőből áll, a lábléc hírlevél-feliratkozása pedig ugyanígy. Az ikonos gombnak is kell hozzáférhető név, például <button type="submit" aria-label="Keresés">. A hibaüzenetet az aria-describedby attribútum köti a mezőhöz (WCAG 1.3.1, 3.3.2 és 4.1.2, hivatalos).
4. Fókuszjelölés
Billentyűzettel navigálva mindig látszania kell, melyik elemen áll a fókusz (WCAG 2.4.7, AA szint). A 2.2-es változat új kritériuma (2.4.11) azt is kéri, hogy a fókuszban lévő elemet ne takarja el teljesen más tartalom, például egy ragadós fejléc vagy süti-sáv.
A leggyakoribb ok egy régi CSS-reset, amely minden elemről leveszi a körvonalat (outline: none). A javítás pár sor a gyermektémában.
:focus-visible { outline: 3px solid #1a4fd6; outline-offset: 2px; }
A ragadós fejléc alá bukó elemekre a scroll-padding-top tulajdonság ad megoldást, a fejléc magasságával megegyező értékkel.
5. Billentyűzettel bejárható menü
Minden funkciónak elérhetőnek kell lennie billentyűzetről, és sehol nem ragadhat be a fókusz (WCAG 2.1.1 és 2.1.2, A szint, hivatalos). A menüknél ez bukik el a legtöbbször. A legördülő almenü csak egérráhúzásra nyílik, a mobilos hamburger ikon pedig egy kattintáseseménnyel ellátott <div>, amelyre Tabbal rá sem lehet lépni.
A helyes alap egy valódi gomb, amelynek állapotát a szkript frissíti.
<button aria-expanded="false" aria-controls="fomenu">Menü</button>
Nyitáskor az aria-expanded értéke true lesz, az Escape billentyű bezárja a menüt, és a fókusz visszatér a gombra. Ezt a W3C WAI-ARIA Authoring Practices Guide „disclosure” mintája írja le részletesen. Pozitív tabindex értéket ne használj, mert összekeveri a természetes bejárási sorrendet.
6. Kontrasztarány
A normál szöveg és a háttere között legalább 4,5:1 arány kell, a nagy szövegnél (legalább 18 pontos, vagy 14 pontos félkövér) 3:1 (WCAG 1.4.3, hivatalos). A felület elemeire, például a mezőkeretekre, az ikonokra és a fókuszjelölésre is 3:1 vonatkozik (WCAG 1.4.11).
Saját tapasztalatunk szerint a sablonokban három hely bukik rendszeresen. A halványszürke lábléc-szöveg, a fotóra írt fehér cím a nyitóképen, és a világosszürke helykitöltő vagy mezőkeret az űrlapokban.
7. Képek szöveges leírása
Minden tartalmat hordozó képnek legyen olyan alt szövege, amely a kép tartalmát vagy funkcióját adja vissza, a díszítő képnek pedig üres alt="" attribútuma (WCAG 1.1.1, hivatalos). A linkként működő képnél a cél a lényeg. A fejléc logója jellemzően a főoldalra visz, ezért az alt szövege a cégnév legyen.
A sablonban a lábléc közösségimédia-ikonjait érdemes megnézni. Gyakori, hogy alt szöveg helyett a fájlnév szerepel („fb-icon-white.png”), vagy semmi. Ha az ikon SVG, kapjon aria-hidden="true" attribútumot, a link pedig szöveges nevet, például „Facebook-oldalunk”.
8. Nyelv megadása
A <html> elemen szerepeljen a helyes nyelvkód, magyar oldalon <html lang="hu"> (WCAG 3.1.1, hivatalos). Enélkül a képernyőolvasó rossz kiejtési szabályokkal olvashatja fel a szöveget. Az idegen nyelvű részeket külön jelölheted, például <span lang="en"> (WCAG 3.1.2).
Saját tapasztalatunk szerint ez a hiba meglepően gyakori. Jellemzően lang="en-US" marad a kódban, mert telepítéskor angol maradt a rendszer nyelve. WordPressben a Beállítások, Általános menüpont Honlap nyelve mezője állítja.
Hogyan járd be az oldalt billentyűzettel egy óra alatt?
Válassz ki négy jellemző oldalt, és mindegyiken egér nélkül menj végig, csak a Tab, Shift+Tab, Enter, szóköz, Escape és a nyilak használatával. Egy oldalra nagyjából negyedóra elég. Jó választás a főoldal, egy szolgáltatásoldal, egy blogcikk és a kapcsolatoldal az űrlappal, webshopnál a termékoldal és a kosár.
- Kattints a böngésző címsorába, tedd félre az egeret, és nyomd meg a Tab billentyűt.
- Az első Tabra megjelenik-e az ugrólink, és Enterre valóban a tartalomra visz-e?
- Menj végig a fejlécen. Minden linken és gombon látod a fókuszt? Jegyezd fel, hol tűnik el.
- Nyisd ki a legördülő menüt Enterrel vagy szóközzel, majd zárd be Escape-pel. Szűkítsd le az ablakot mobil szélességre, és próbáld ki ugyanezt a hamburger menüvel.
- Figyeld a sorrendet. A fókusz a látható sorrendet követi, vagy össze-vissza ugrál?
- Töltsd ki és küldd el az űrlapot billentyűzettel, egyszer szándékosan hibás e-mail-címmel. Hová kerül a fókusz, és érthető-e a hibaüzenet?
- Nézd meg a felugró elemeket (süti-sáv, hírlevél-ablak, chat-widget). Elérhetők és bezárhatók, és bezárás után visszakerül-e a fókusz oda, ahol voltál?
- Végül menj visszafelé Shift+Tabbal is, mert a beragadás néha csak az egyik irányban jelentkezik.
Minden hibát egy sorban rögzíts az oldallal, az elemmel, a tünettel és a kapcsolódó WCAG-kritériummal. Saját tapasztalat, hogy a süti-sáv és a felugró hírlevél-ablak az a két elem, ahol a legtöbbször beragad vagy elvész a fókusz, pedig ezek szinte minden látogatónál megjelennek.
Milyen ingyenes eszközökkel ellenőrizz, és mire nem elegendők?
A billentyűzetes bejárás mellé érdemes egy-két automata eszközt is lefuttatni, mert a hiányzó alt szövegeket, címkéket és kontraszthibákat percek alatt összegyűjtik.
- Lighthouse a Chrome fejlesztői eszközeiben. Gyors áttekintést ad, az akadálymentességi vizsgálata az axe-core szabálykészletre épül.
- WAVE (WebAIM) böngészőbővítmény. Az oldalon jelöli a hibákat, és külön nézetben mutatja a címsor-szerkezetet és a tájékozódási pontokat.
- axe DevTools ingyenes bővítménye. Kritériumonként csoportosít, és javítási javaslatot ad.
- WebAIM Contrast Checker. Két színkódból kiszámolja az arányt, tervezéskor is hasznos.
- A Chrome fejlesztői eszközeinek Accessibility panele. Megmutatja, milyen nevet és szerepet lát egy elemből a segítő technológia.
- NVDA (Windowsra ingyenes) vagy a macOS-be épített VoiceOver. Öt perc hallgatás a főoldalon sokat elárul a címsorokról és a linkszövegekről.
Hivatalosan igazolt. A W3C WAI kiértékelő eszközökről szóló anyaga maga is jelzi, hogy az eszközök önmagukban nem tudják eldönteni, akadálymentes-e egy oldal, és sok ellenőrzéshez emberi mérlegelés kell. Az eszköz látja, hogy van alt szöveg, azt viszont nem tudja megítélni, hogy igaz-e. Látja, hogy van fókuszstílus, de azt nem, hogy a menü kinyitható-e.
Milyen sorrendben javíts fontosság szerint?
Először azt javítsd, ami valakit teljesen megállít, utána azt, ami nehezíti a használatot, végül a finomításokat. Az alábbi sorrend szakmai feltételezés, a hatás és a ráfordítás mérlegelésén alapul, egyedi helyzetben eltérhet.
- Billentyűzetcsapda és elérhetetlen funkció. Nem nyitható menü, nem küldhető űrlap, nem zárható süti-sáv.
- Hiányzó fókuszjelölés. Egyetlen CSS-szabály, az egész oldalon hat.
- Nyelv megadása. Néhány perc munka, minden oldal felolvasását javítja.
- Űrlapcímkék és ikongombok neve. Ezeken múlik az ajánlatkérés és a vásárlás.
- Képek szöveges leírása. Előbb a linkként működő képek és a logó, utána a termék- és tartalomképek.
- Kontraszt. Általában a téma színbeállításaiban javítható.
- Címsorok és tájékozódási pontok. Fontosak, de ritkán akadályozzák meg teljesen a használatot.
- Finomítások. Hibaüzenetek összekötése a mezőkkel,
autocomplete, idegen nyelvű részek jelölése.
Mi javítható a sablonban, és mihez kell fejlesztő?
A beállítások és a tartalom szintjén sokat meg tudsz csinálni magad, a sablon HTML-szerkezetéhez és a szkriptekhez viszont jellemzően fejlesztő kell. A határ témánként eltér, az alábbi felosztás saját tapasztalat.
Amit a felületen magad is beállíthatsz
- A honlap nyelvét a rendszerbeállításokban.
- A szöveg- és háttérszíneket a téma testreszabójában.
- Az alt szövegeket a médiatárban és az oldalépítő képmoduljaiban.
- A címsorszinteket a szerkesztőben és a widgetek beállításaiban.
- A látható mezőcímkéket az űrlapbővítmény beállításaiban, ami sok bővítményben egyetlen kapcsoló.
- A menük elnevezését és a süti-bővítmény megjelenési beállításait.
Amihez fejlesztő kell
- A fókuszstílus visszaállítása és a
scroll-padding-topbeállítása egy gyermektémában, hogy frissítéskor ne vesszen el. - Az ugrólink és a tájékozódási elemek beépítése a fejléc- és láblécsablonba.
- A menü szkriptjének átírása valódi gombokkal,
aria-expandedállapottal és Escape-kezeléssel. - A felugró ablakok fókuszkezelése nyitáskor és bezáráskor.
- Egyedi komponensek, például csúszkák, fülek és harmonikák billentyűzetes kezelése.
Szakmai feltételezés. Ha a bejárás a menüben, a felugró elemekben és az űrlapokban is sok hibát talál, egy akadálymentességre tervezett téma jó eséllyel kevesebb munkával jár, mint a meglévő átírása. Az oldalra tett akadálymentességi widgetek (overlay-ek) saját tapasztalatunk szerint a sablon kódján nem változtatnak, a fenti hibák mögöttük ugyanúgy megmaradnak.
Segíti-e az akadálymentes kód a keresőket és az AI-rendszereket?
Közvetlen rangsorolási előnyt nem garantál, de a jól jelölt szerkezetet a gépek is könnyebben értelmezik. Hivatalosan igazolt, hogy a Google Search Central a képekhez leíró alt szöveget ajánl, mert abból is érti meg a kép tartalmát. Az OpenAI a ChatGPT Atlas böngészőhöz kiadott dokumentációjában azt írja, hogy az ügynök az ARIA-jelölésekre is támaszkodik, amikor az oldal szerkezetét értelmezi. Szakmai feltételezés, hogy a tiszta címsor-hierarchia, a megcímkézett űrlap és a gombként jelölt gomb az AI-ügynököknek is segítheti az oldal használatát, erről azonban még kevés nyilvános mérés van.
Források és további olvasnivalók
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI, Easy Checks, A First Review of Web Accessibility
- W3C WAI, ARIA Authoring Practices Guide (APG)
- W3C WAI, Selecting Web Accessibility Evaluation Tools
- WebAIM, WAVE és Contrast Checker dokumentáció
- Chrome for Developers, Lighthouse akadálymentességi auditok
- Google Search Central, a képekre vonatkozó SEO-útmutató
- OpenAI, ChatGPT Atlas dokumentáció
- Az Európai Parlament és a Tanács (EU) 2019/882 irányelve
Gyakori kérdések
Mennyi idő egy alap akadálymentességi ellenőrzés a sablonon?
Négy jellemző oldal billentyűzetes bejárása nagyjából egy óra, oldalanként negyedóra. Mellé egy automata eszköz (Lighthouse vagy WAVE) futtatása oldalanként néhány perc.
Elég, ha a Lighthouse akadálymentességi pontszáma 100?
Nem elég. A pontszám csak a gép által ellenőrizhető szabályokat méri. Azt nem látja, hogy a menü kinyitható-e billentyűzettel, logikus-e a fókusz sorrendje, vagy igaz-e az alt szöveg, ezért a billentyűzetes bejárást nem váltja ki.
Miért nem elég a helykitöltő szöveg az űrlapmezőben?
Gépeléskor eltűnik, így a kitöltő elfelejtheti, mit kér a mező, és sok segítő technológia nem kezeli címkeként. Minden mezőhöz tartozzon egy label elem, amelyet a for attribútum köt a mező azonosítójához.
Megoldja a problémát egy akadálymentességi widget?
Saját tapasztalatunk szerint nem. Az overlay-ek a sablon kódján nem változtatnak, így a hiányzó címkék, a nem kezelhető menü és a beragadó felugró ablak mögöttük ugyanúgy megmarad.
Kötelező akadálymentessé tenni a vállalkozás weboldalát?
Az Európai Akadálymentességi Irányelv 2025. június 28-tól egyes szolgáltatásokra, köztük az elektronikus kereskedelemre is előír kötelezettségeket, a mikrovállalkozásokra vonatkozó kivételekkel. Hogy rád vonatkozik-e, azt jogi szakemberrel érdemes tisztázni.
Javítja az akadálymentesség a Google-helyezést?
Közvetlen helyezést nem garantál. A leíró alt szöveget a Google hivatalosan ajánlja, a tiszta szerkezetet pedig a keresők és az AI-ügynökök is jó eséllyel könnyebben értelmezik.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.