Webfejlesztés

Akadálymentes weboldal: WCAG ellenőrzőlista vállalkozásoknak

Tizenkét pont, amelyen a legtöbb weboldal elbukik, és amit ingyenes eszközökkel fél óra alatt magad is átnézhetsz. Mindegyiknél megmutatjuk, melyik WCAG-követelményről van szó, és hogyan ellenőrizd.

Akadálymentes weboldal ellenőrzőlista: alt szöveg, billentyűzetes menü, címkézett űrlapmezők, címsorrend, oldalnyelv és 4,5:1-es kontrasztarány

Az akadálymentes weboldal nem csak a látássérült látogatóknak szól. Egy idősebb ügyfél, aki nagyítva olvas, egy kolléga, aki egér helyett billentyűzettel dolgozik, vagy valaki, aki napsütésben a telefonján nézi a webshopodat, ugyanazokon a hibákon akad el. A WebAIM Million 2025-ös elemzése szerint a vizsgált egymillió kezdőlap közel 95%-án volt automatikusan kimutatható WCAG-hiba, és a hibák túlnyomó része néhány visszatérő típusba esik.

A jó hír: ezek a hibák jól ismertek, és a legtöbbjük egyszerűen javítható. Ez az ellenőrzőlista végigvezet a tizenkét leggyakoribb ponton, megmutatja, melyik WCAG-követelményről van szó, és hogy hogyan ellenőrizd magad, ingyenes eszközökkel.

Röviden

  • A cél a WCAG 2.2 AA szint, erre épít az európai EN 301 549 szabvány is.
  • A leggyakoribb hibák: gyenge kontraszt, hiányzó alt szöveg, címke nélküli űrlapmező, üres link vagy gomb, hiányzó oldalnyelv.
  • Az automata tesztek a hibák egy részét találják meg, ezért billentyűzettel és képernyőolvasóval is végig kell menni az oldalon.
  • Az akadálymentesítő widget nem javítja ki a kódot, a hibákat magában az oldalban kell rendbe tenni.

Ha nem magad csinálnád, a weboldal akadálymentesítés oldalon mutatjuk be, hogyan auditáljuk és javítjuk a meglévő oldalakat.

Mi a WCAG, és mit jelent az AA szint?

A WCAG (Web Content Accessibility Guidelines) a W3C nemzetközi irányelve arról, hogyan lesz egy weboldal mindenki számára használható. Három megfelelési szintje van: az A a minimum, az AA a gyakorlatban elvárt szint, az AAA pedig a legszigorúbb. Vállalkozásoknál és webshopoknál az AA a cél; erre épít az európai EN 301 549 szabvány is, amelyre az uniós akadálymentességi szabályozás hivatkozik.

A követelmények négy alapelv köré szerveződnek. Ha ezeket megérted, a konkrét pontok is logikusak lesznek:

A WCAG négy alapelve: észlelhető, működtethető, érthető és robusztus, példákkal
  • Észlelhető: a tartalmat mindenki érzékelni tudja, akkor is, ha nem lát vagy nem hall jól.
  • Működtethető: az oldal egér nélkül, billentyűzettel vagy segédeszközzel is használható.
  • Érthető: a működés kiszámítható, a szövegek és a hibaüzenetek világosak.
  • Robusztus: a kód olyan, hogy a képernyőolvasók és más segédtechnológiák is helyesen értelmezik.

A 2023 októberében kiadott WCAG 2.2 néhány új követelményt hozott, amelyek főleg a mobilos és a billentyűzetes használatot érintik: legalább 24×24 pixeles kattintási felületet, a fókuszban lévő elem eltakarásának tilalmát, és azt, hogy egy űrlapon ne kelljen ugyanazt az adatot kétszer megadni.

Akadálymentes weboldal: 12 pontos ellenőrzőlista

A pontok mellé zárójelben odaírtuk a WCAG-követelmény számát, hogy ha egy fejlesztővel beszélsz, pontosan tudjátok, miről van szó.

1. Elég erős a szövegkontraszt (1.4.3)

A normál szöveg és a háttér közötti kontrasztarány legalább 4,5:1, nagy (18 pontos vagy félkövér 14 pontos) szövegnél legalább 3:1 legyen. A világosszürke szöveg fehér háttéren a leggyakoribb hiba. Ellenőrzés: a WebAIM Contrast Checkerrel vagy a Chrome DevTools színválasztójával, amely mutatja az arányt.

2. Minden képnek van alternatív szövege (1.1.1)

A tartalmat hordozó képeknél az alt szöveg írja le, mit lát a látogató, a dekoratív képeknél pedig üres legyen (alt=""), hogy a képernyőolvasó átugorja. A „kép1.jpg” vagy a kulcsszavakkal teletömött alt szöveg hiba. Ellenőrzés: a WAVE bővítmény minden képet megjelöl, és jelzi a hiányzó alt szövegeket.

3. Logikus a címsorrend (1.3.1)

Oldalanként egy H1, alatta H2 és H3 szintek a tartalom logikája szerint, kihagyott szintek nélkül. A képernyőolvasót használók címsorok alapján ugrálnak az oldalon, ezért a címsor nem díszítőelem. Ellenőrzés: a WAVE „Structure” nézete kilistázza a címsorokat.

4. Meg van adva az oldal nyelve (3.1.1)

A HTML-ben szerepel a lang="hu", különben a képernyőolvasó angol kiejtéssel olvassa fel a magyar szöveget. Egysoros javítás, mégis a leggyakoribb hibák között van. Ellenőrzés: a Lighthouse akadálymentességi auditja jelzi, ha hiányzik.

5. Minden elérhető billentyűzettel (2.1.1, 2.1.2)

A menü, a lenyíló listák, a gombok, a csúszkák és a felugró ablakok Tab, Enter, Szóköz és Esc billentyűvel is működnek, és sehol nem ragad be a fókusz. Ellenőrzés: tedd el az egeret, és menj végig a főoldalon, egy szolgáltatásoldalon és az ajánlatkérő űrlapon csak billentyűzettel.

6. Látható a fókusz, és semmi nem takarja el (2.4.7, 2.4.11)

Mindig látszik, melyik elemen áll a billentyűzetes fókusz, és azt nem takarja el egy ragadós fejléc vagy egy sütisáv. Sok oldal a design kedvéért kikapcsolja a fókuszkeretet; ez az egyik legsúlyosabb hiba a billentyűzetes használóknak. Ellenőrzés: az 5. pont bejárása közben figyeld a fókuszt.

7. Az űrlapmezőknek van címkéjük, a hibák érthetők (3.3.1, 3.3.2)

Minden mezőnek látható, a mezőhöz kötött címkéje van (a placeholder nem címke), a kötelező mezők jelölve vannak, és a hibaüzenet megmondja, mi a hiba és hogyan javítható. Ellenőrzés: küldd el az űrlapot üresen és hibás e-mail címmel, és nézd meg, érthető-e a visszajelzés.

8. Beszédesek a linkek és a gombok (2.4.4, 4.1.2)

A „Tovább” vagy „Kattints ide” helyett a linkszöveg mondja meg, hová visz („Webshop árak 2026”), és minden gombnak van neve, az ikonos gomboknak is (például aria-label). Ellenőrzés: a WAVE jelzi az üres linkeket és gombokat.

9. Elég nagyok a kattintási felületek (2.5.8)

A WCAG 2.2 szerint a kattintható elemek legalább 24×24 pixelesek legyenek, vagy legyen körülöttük elég hely. Mobilon az egymáshoz zsúfolt kis ikonok és linkek a leggyakoribb problémák. Ellenőrzés: nézd meg az oldalt telefonon, és próbáld egy ujjal eltalálni a menüpontokat és a lábléc linkjeit.

10. A videóknak van felirata (1.2.2)

A beszédet tartalmazó videókhoz felirat, a hanganyagokhoz átirat tartozik. Az automatikusan generált felirat jó kiindulás, de ellenőrizni kell, különösen a magyar szakszavaknál. Ellenőrzés: kapcsold ki a hangot, és nézd meg, követhető-e a videó.

11. Nagyítva is használható az oldal (1.4.4, 1.4.10)

200%-os nagyításnál sem lóg ki és nem takarja egymást a tartalom, és keskeny képernyőn sem kell vízszintesen görgetni. Ellenőrzés: nagyíts rá a böngészőben (Ctrl és +) 200%-ra, és nézd végig a fő oldalakat.

12. Az animáció nem zavaró, és nincs villogás (2.2.2, 2.3.1)

Az automatikusan mozgó, öt másodpercnél tovább tartó tartalom (csúszka, futószöveg) megállítható, és semmi nem villog másodpercenként háromnál többször. Jó gyakorlat az is, hogy az oldal tiszteletben tartsa a rendszer „mozgás csökkentése” beállítását. Ellenőrzés: nézd meg, megállíthatók-e a csúszkák és a futó elemek.

Hogyan ellenőrizd 30 perc alatt, ingyen?

Teljes körű audithoz szakember kell, de egy első képet fél óra alatt magad is kaphatsz. Válaszd ki a három legfontosabb oldaladat (főoldal, a legfontosabb szolgáltatás- vagy termékoldal, ajánlatkérő vagy pénztár), és ezeken menj végig:

  1. Lighthouse (5 perc): Chrome-ban a DevTools → Lighthouse fülön futtasd az „Accessibility” auditot. Gyors pontszámot és hibalistát ad.
  2. WAVE (5 perc): a WebAIM ingyenes böngészőbővítménye a hibákat közvetlenül az oldalon jelöli: kontraszt, alt szövegek, címkék, üres linkek, címsorok.
  3. Billentyűzetteszt (10 perc): egér nélkül, Tab, Shift+Tab, Enter és Esc billentyűkkel menj végig a menün és az űrlapon. Látod mindig a fókuszt? El tudod küldeni az űrlapot?
  4. Kontraszt és nagyítás (5 perc): nézd meg a szürke szövegeket a kontrasztellenőrzővel, és nagyíts 200%-ra.
  5. Képernyőolvasó (5 perc): Windowson az ingyenes NVDA, Macen a beépített VoiceOver. Hallgasd meg, érthetően felolvassa-e a menüt, a gombokat és az űrlapot.

Az automata eszközök a hibáknak csak egy részét találják meg: azt nem tudják megítélni, hogy egy alt szöveg értelmes-e, vagy hogy logikus-e a bejárási sorrend. Ezért fontos a 3–5. lépés. Mi a saját fejlesztésű Friendlyuse.com szkennerünkkel és kézi ellenőrzéssel dolgozunk, és a talált hibákat a kódban javítjuk. A hatóságok tájékoztató anyagaihoz a Web akadálymentesítési kisokos is jó kiindulópont.

Miért nem elég egy akadálymentesítő widget?

Csábító megoldás egy plugin, amely egy ikont tesz az oldal sarkába, és betűméret- vagy kontrasztkapcsolót kínál. A gond az, hogy ezek a widgetek a látogató oldalán változtatnak a megjelenésen, de a kódban lévő hibákat nem javítják ki. A menü attól még nem lesz billentyűzettel bejárható, a képek nem kapnak értelmes alt szöveget, és az űrlapmezők sem kapnak címkét. A képernyőolvasót használó látogató pontosan ugyanott akad el, mint widget nélkül.

A megfeleléshez a hibákat magában az oldalban kell kijavítani: a sablonokban, a komponensekben és a tartalomban. A jó hír, hogy a hibák nagy része sablonszintű, ezért egy javítás egyszerre több tucat aloldalt tesz rendbe.

Meglévő weboldal: javítás vagy új oldal?

A legtöbb esetben a meglévő weboldal akadálymentesíthető, nem kell újat építeni. Ha a fejléc, a menü, a kártyák és az űrlapok sablonja javul, az összes érintett aloldal egyszerre lesz rendben, legyen szó WordPressről vagy egyedi fejlesztésről.

Új oldalt akkor érdemes választani, ha a weboldal egyébként is elavult: nem reszponzív, lassú, nehezen szerkeszthető, vagy a sablon miatt sok hiba csak átépítéssel szüntethető meg. Ilyenkor a weboldal felújítás és az akadálymentesítés együtt kevesebbe kerül, mint két külön projekt. Hogy kire vonatkozik az uniós szabályozás, és hogyan zajlik nálunk egy audit, azt a weboldal akadálymentesítés oldalon foglaltuk össze.

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

Mi az a WCAG, és melyik szintet kell teljesíteni?

A WCAG (Web Content Accessibility Guidelines) a W3C nemzetközi irányelve a webes akadálymentességről. Három szintje van: A, AA és AAA. Vállalkozásoknál a gyakorlati cél az AA szint, erre épít az európai EN 301 549 szabvány is. A legfrissebb változat a WCAG 2.2, amely néhány új követelményt hozott, például a legalább 24×24 pixeles kattintási felületet.

Kötelező a weboldalam akadálymentesítése?

Az uniós akadálymentesítési irányelv (EAA) 2025. június 28. óta elsősorban a fogyasztóknak szóló szolgáltatásokra vonatkozik, például webshopokra, online foglalásra, banki és közlekedési szolgáltatásokra. A szolgáltatást nyújtó mikrovállalkozások (10 főnél kevesebb foglalkoztatott, legfeljebb 2 millió eurós éves árbevétel vagy mérlegfőösszeg) mentesülhetnek, a közszféra honlapjaira külön szabályok vonatkoznak. Hogy a te oldaladra pontosan mi érvényes, azt érdemes jogásszal is ellenőriztetni.

Elég, ha lefuttatok egy automata tesztet?

Nem. Az automata eszközök (Lighthouse, WAVE, axe) gyorsan megtalálják a hiányzó alt szövegeket, a gyenge kontrasztot vagy a címke nélküli mezőket, de sok hibát nem látnak: például hogy az alt szöveg értelmes-e, hogy a billentyűzetes bejárás logikus-e, vagy hogy egy hibaüzenet érthető-e. Ezért kell kézi ellenőrzés is: billentyűzettel és képernyőolvasóval végigmenni a fő folyamatokon.

Megoldja az akadálymentességet egy widget vagy plugin?

Nem. Az oldalra rátett akadálymentesítő widgetek a látogató oldalán kínálnak beállításokat (betűméret, kontraszt), de nem javítják ki a kódban lévő hibákat. A megfeleléshez a hibákat magában a weboldalban kell kijavítani: a sablonokban, a komponensekben és a tartalomban.

Kell új weboldal az akadálymentességhez?

Általában nem. A meglévő weboldal akadálymentesíthető, mert a hibák nagy része sablonszintű, és egy javítás az összes érintett aloldalt rendbe teszi. Új oldalt akkor érdemes választani, ha az oldal egyébként is elavult, mert ilyenkor a felújítás és az akadálymentesítés együtt olcsóbb, mint két külön projekt.

Összefoglalás

Az akadálymentes weboldal nem különleges funkció, hanem gondos alapmunka: elég kontraszt, értelmes alt szövegek, logikus címsorok, billentyűzettel bejárható menü, címkézett űrlapok. A tizenkét pontból a legtöbb fél óra alatt ellenőrizhető, és a hibák nagy része egyszerűen javítható. Kezdd a három legfontosabb oldaladdal, és ha a lista hosszú lesz, kérj auditot, mielőtt egy widgetben keresnéd a megoldást.

Csipkay Péter – Remote Studio alapító

Csipkay Péter

Alapító · Remote Studio

Creative frontend developer és a Remote Studio alapítója. Egyedi weboldalakat, Three.js alapú 3D webes élményeket és AI automatizációs folyamatokat épít üzleti célból kiindulva, teljesítményre, SEO-ra, akadálymentességre és hosszú távú karbantarthatóságra figyelve.

Kezdjük el

Megnézzük, mennyire akadálymentes a weboldalad?

A Friendlyuse.com szkennerünkkel és kézi ellenőrzéssel feltárjuk a hibákat, és súlyosság szerint rangsorolt listát adunk a javításhoz.

Auditot kérek