Akadálymentes weboldal: ellenőrzőlista kisvállalkozásoknak

Képzeljen el egy vásárlót, aki képernyőolvasót használ. Megtalálja a kiszemelt sportcipőt, kiválasztja a méretet, és megnyomja azt, amiről azt hiszi, hogy a kosár gombja. A képernyőolvasó annyit mond: „gomb”. Semmi többet. Három ilyen van az oldalon, és egyiknek sincs neve, ezért a vásárló továbbáll, Ön pedig soha nem tudja meg, miért.

A kisvállalkozások webhelyein a legtöbb akadálymentességi probléma ilyen: a tulajdonos nem látja, a vásárlónak viszont zsákutca. Ez az ellenőrzőlista azoknak szól, akik saját fejlesztő nélkül üzemeltetnek Shopify-, WooCommerce-, Wix- vagy Squarespace-webhelyet.

Akadálymentesnek kell lennie egy kisvállalkozás weboldalának?

Ha uniós fogyasztóknak értékesít, valószínűleg igen. Az európai akadálymentesítési irányelv (új lapon nyílik meg) 2025. június 28. óta kiterjed az e-kereskedelmi szolgáltatásokra. A fő kivétel a szolgáltatásokat nyújtó mikrovállalkozásoké: azoké a cégeké, amelyek 10 főnél kevesebb személyt foglalkoztatnak, és éves árbevételük vagy mérlegfőösszegük nem haladja meg a 2 millió eurót.

E-kereskedelmen itt a távolról, weboldalon vagy alkalmazáson keresztül történő értékesítést kell érteni, amely „a fogyasztó egyéni kérelmére, a fogyasztói szerződés megkötése céljából” történik (3. cikk 30. pont). Egy webáruház vagy egy foglalási rendszer ide tartozik. A mentesség csak a szolgáltatásokra vonatkozik: aki érintett termékeket, például e-könyv-olvasókat árul, annak továbbra is meg kell felelnie a termékekre vonatkozó szabályoknak (4. cikk (5) bekezdés). Az sem segít, ha a cég az EU-n kívül működik, mert egy franciaországi vásárlóknak értékesítő brit webáruház ezekre a vásárlókra nézve érintett (3. cikk 4. pont). Az európai akadálymentesítési irányelvről szóló útmutatónk a nemzeti jogszabályokat és a bírságokat is bemutatja.

Az Egyesült Királyság 2010-es Equality Actje (új lapon nyílik meg) észszerű alkalmazkodást ír elő a fogyatékossággal élők javára, de a weboldalakra nem határoz meg műszaki szabványt. Az Egyesült Államokban az igazságügyi minisztérium 2022. márciusi útmutatója (új lapon nyílik meg) szerint a nyilvánosság számára nyitva álló vállalkozásoknak akadálymentessé kell tenniük online kínálatukat, és az olyan szabványok, mint a WCAG, „hasznos iránymutatást adnak”. Bármit mond is a jog, az a vásárló, aki nem jut végig a pénztáron, nem vásárol.

Melyek a leggyakoribb akadálymentességi problémák a weboldalakon?

Hat hiba uralja a mezőnyt. A WebAIM Million 2026 (új lapon nyílik meg) (az egymillió legnépszerűbb kezdőlap 2026. februári automatikus vizsgálata) szerint az oldalak 95,9%-án volt kimutatható WCAG-hiba, oldalanként átlagosan 56,1. A leggyakoribb probléma a gyenge kontrasztú szöveg volt, a kezdőlapok 83,9%-án.

Ezek mögött az ellenőrzések mögött a WCAG, a webes tartalmak akadálymentességi irányelvei állnak; a legtöbb jogszabály az AA szintjére hivatkozik, a legújabb verziót pedig a WCAG 2.2-ről szóló útmutatónk mutatja be. Az alábbi ellenőrzések közül többet egyetlen automatikus eszköz sem tud megítélni.

Mindenki el tudja olvasni a szövegeit, és megérti a képeit?

Itt kezdje, mert ezek a javítások olcsók, és nagyrészt Ön is elvégezheti őket a webhelyszerkesztőben. A szövegnek elég kontrasztosnak kell lennie, az információt hordozó képeknek helyettesítő szöveg kell, és semmi sem múlhat kizárólag a színen. A Colour Blind Awareness (új lapon nyílik meg) szerint nagyjából minden 12. férfi és minden 200. nő színlátási zavarral él.

• Kontraszt. A normál szövegnek legalább 4,5:1 arányú kontraszt (új lapon nyílik meg) kell a hátteréhez képest, a nagy szövegnek legalább 3:1. Ellenőrizze a színeit egy ingyenes kontrasztellenőrzővel, a bannerfotókra írt szöveget is. A színkontrasztról szóló útmutatónk olyan javításokat mutat, amelyek megőrzik a márka arculatát.
• Helyettesítő szöveg a termékképeken. Írja le, amit a vásárlónak tudnia kell: a „Sötétkék gyapjúpulóver bordázott garbónyakkal, elölnézet” jobb, mint a „termékkép 1”. Kezdje a tíz legkelendőbb termékével.
• Díszítő képek. Egy háttérben kanyargó mintának üres helyettesítő szöveg kell, hogy a képernyőolvasók átugorják. Egyes platformok az üres alt mezőt a fájlnévvel töltik ki, ezért ellenőrizze a sajátját.
• Csak a szín. Az „Elfogyott” jelzés, ha csak egy kiszürkített színminta mutatja, vagy a kötelező mező, ha csak piros szín jelöli, nem jut el mindenkihez. Nézze meg az oldalt a telefonja szürkeárnyalatos szűrőjével, és tegyen ki egy szót vagy ikont, ahol eltűnik a jelentés.
• Nagyítás. 200%-os böngészőnagyításnál a szövegnek nőnie kell anélkül, hogy egymásra csúszna vagy levágódna, a menünek pedig továbbra is működnie kell.
• Az oldal nyelve. A hiányzó nyelvi deklarációt bármely ingyenes ellenőrző jelzi. Ez egy témabeállítás vagy egysoros sablonmódosítás.

Használható a webhelye billentyűzettel?

Sokan böngésznek egér nélkül: a képernyőolvasót használók, a remegő vagy korlátozottan mozgó kezű emberek, és bárki, akinek éppen most adta meg magát az érintőpadja. Tegye félre az egeret, és nyomja meg a Tab billentyűt. Minden linket, gombot és űrlapmezőt értelmes sorrendben kell elérnie, mindig látnia kell, hol tart, és sehol sem szabad elakadnia.

• Látható fókusz. Egy körvonalnak mutatnia kell, melyik elem aktív, és ezt nem takarhatja el rögzített fejléc vagy csevegőbuborék (a WCAG 2.2 2.4.11-es, Nem takart fókusz kritériuma). Sok téma a látvány kedvéért eltávolítja a körvonalat; egy fejlesztő vissza tudja állítani.
• Nincs csapda. Nyissa meg billentyűzettel a menüt, a méretválasztót, a felugró ablakokat és a képgalériát, válasszon ki valamit, majd próbáljon kilépni. Az Escape-nek be kell zárnia a felugró ablakokat.
• Név az ikonoknak. Minden ikonlinknek és ikongombnak olyan név kell, amelyet a képernyőolvasó fel tud olvasni, például „Kosár, 2 termék”. A „Kattintson ide” helyett olyan szavakat használjon, amelyek megmondják, hová vezet a link.
• Átugró link és címsorok. Az első Tab-lenyomásnak ideális esetben egy „Ugrás a tartalomhoz” linket kell megjelenítenie. A WebAIM 2024-es képernyőolvasós felmérésében (új lapon nyílik meg) a válaszadók 71,6%-a mondta, hogy egy hosszú oldalon először a címsorok mentén navigál, ezért használjon valódi címsorszinteket, ne félkövér szöveget.
• Koppintási célterületek. A WCAG 2.2 legalább 24 × 24 CSS-képpontos célterületeket kér, vagy elég helyet körülöttük (2.5.8-as sikerkritérium (új lapon nyílik meg)).

Mindenki végigjut az űrlapjain, a kosáron és a pénztáron?

A pénztárban kerülnek közvetlenül pénzbe az akadálymentességi problémák, ezért tesztelje az elejétől a végéig, azt is, mi történik, ha valami hibás. Minden mezőnek látható címke kell, a hibaüzeneteknek szavakkal kell elmagyarázniuk a problémát, a bejelentkezés pedig nem múlhat memóriateszten vagy rejtvényen. A fizetési szolgáltató oldalai is ide számítanak.

• Címkék, nem helyőrzők. A helyőrző szöveg eltűnik, amint valaki gépelni kezd, és gyakran túl halvány ahhoz, hogy olvasható legyen. Minden mezőnek olyan címke kell, amely látható marad.
• Hibaüzenetek. Küldje be üresen az űrlapot. Minden hibát szavakkal kell leírni („Adja meg az irányítószámot, például 1052”), a mező mellett kell megjelennie, és a képernyőolvasónak fel kell olvasnia, nem elég, ha egy keret pirosra vált.
• Ne kérdezzen kétszer. Kínálja fel „A számlázási cím megegyezik a szállítási címmel” lehetőséget, ahelyett, hogy újra begépeltetné a címet. A WCAG 2.2 ezt A szintű követelménnyé tette: 3.3.7 Ismételt adatbevitel.
• Bejelentkezés. Engedje a jelszavak és az egyszer használatos kódok beillesztését és a jelszókezelők használatát. A beillesztés tiltása sérti a WCAG 2.2 akadálymentes hitelesítésről szóló kritériumát (új lapon nyílik meg), hacsak nem kínál más belépési módot.
• CAPTCHA. A WebAIM 2024-es felmérésében a képernyőolvasót használók a CAPTCHA-t tartották a web legproblémásabb elemének. Ha védekeznie kell a botok ellen, kerülje a vizuális rejtvényeket, és mindig kínáljon nem vizuális alternatívát.
• Időkorlátok. Ha egy kosár vagy egy foglalás lejár, figyelmeztesse a felhasználót, és engedje meghosszabbítani.

Ha a pénztár egyes részei a platformhoz vagy a fizetési szolgáltatóhoz tartoznak, azokat is tesztelje, jelezze a problémákat, és sorolja fel őket ismert hibaként.

Mi a helyzet a sütisávokkal, a felugró ablakokkal és a csevegő widgetekkel?

A vásárlói számára a külső szkriptek is a weboldala részei. Egy billentyűzettel be nem zárható sütisáv minden oldalt blokkol, egy pénztár közben a fókuszt magához rántó hírlevél-ablak pedig meghiúsíthat egy eladást. Teszteljen minden szkriptet, amelyet hozzáadott, és új eszköz telepítése előtt kérdezze meg a szolgáltatót az akadálymentességről.

• Sütisáv. Eléri Tab billentyűvel az elfogadás és az elutasítás gombját, el tudja olvasni őket 200%-os nagyításnál, és utána ott folytathatja, ahol abbahagyta?
• Felugró ablakok. A fókusznak a felugró ablakba kell kerülnie, ott kell maradnia a bezárásig, majd vissza kell térnie. Az Escape-nek be kell zárnia az ablakot.
• Csevegő widgetek. A gombnak név kell, az ablaknak billentyűzettel kell nyílnia és záródnia, telefonon pedig nem takarhatja el a „Fizetés” gombot.
• Karusszelek (képváltók). Mindennek, ami öt másodpercnél tovább automatikusan mozog, szüneteltethetőnek, leállíthatónak vagy elrejthetőnek kell lennie (WCAG 2.2 (új lapon nyílik meg), 2.2.2-es sikerkritérium).
• Beágyazott elemek. Az értékelés-widgetek, a térképek és a foglalási eszközök is az Ön oldalán vannak. A hibákat jelezze a szolgáltatónak.

Mindenkinek működnek a videói, a PDF-jei és az étlapjai?

A videóhoz felirat kell, a hanganyaghoz átirat, és fontos információ nem lehet kizárólag PDF-ben vagy képen. Az az étterem, amelynek étlapja egy beszkennelt PDF, vagy az a bolt, amelynek mérettáblázata egy táblázatról készült fotó, kizárja a képernyőolvasót használókat és mindenkit, akinek telefonon nagyítania kell.

• Feliratok és átiratok. Közzététel előtt javítsa ki az automatikus feliratokat. A podcastokhoz szöveges változat kell.
• Szöveget ábrázoló képek. Az étlapokat, árlistákat, mérettáblázatokat és nyitvatartási időket tegye egy hagyományos weboldalra. Ha mindenképp PDF kell, a szövegszerkesztőből exportálja címsorokkal és címkékkel, ne egy kinyomtatott lapot szkenneljen be.
• Régebbi fájlok. Az EAA nem írja elő a 2025. június 28. előtt közzétett irodai fájlok, előre rögzített hang- és videoanyagok, illetve a már nem frissített archívumok javítását (2. cikk (4) bekezdés). Az új fájlokra viszont vonatkozik.

Mit javíthatok magam, és mikor kell fejlesztő vagy audit?

A legtöbb tartalmi problémát maga is kijavíthatja a tartalomkezelőben: a helyettesítő szöveget, a címsorokat, a linkszövegeket, a színeket, a feliratokat és sok űrlapcímkét. A téma szintjén jelentkező problémákhoz, például a hiányzó fókuszstílusokhoz, a billentyűzetcsapdákhoz és az egyedi legördülő menükhöz fejlesztő kell. Auditot akkor érdemes rendelni, amikor az alapok már rendben vannak, vagy egy újratervezés élesítése előtt.

Hol a helye egy olyan widgetnek, mint a miénk? Egy, a látogatók által kezelt panel, mint a SiteAccessible, lehetővé teszi, hogy a látogatók növeljék a kontrasztot, nagyítsák a szöveget, vagy bekapcsoljanak egy olvasásvezetőt. Ez egyes látogatóknak segít, de ebből a listából semmit sem pipál ki: a név nélküli gomb név nélküli marad, a billentyűzetcsapda pedig csapda marad. Előbb a webhelyet javítsa, a widgetet pedig tekintse kiegészítésnek.

Hogyan dokumentáljam, amit elvégeztem?

Vezessen egyszerű naplót arról, mit tesztelt, mikor, mit javított ki, és mi hibás még, majd tegyen közzé egy őszinte összefoglalót egy akadálymentesítési nyilatkozatban. Ha az EAA vonatkozik Önre, azt is közzé kell tennie, hogyan felel meg szolgáltatása az akadálymentességi követelményeknek, általában az általános szerződési feltételekben vagy egy azzal egyenértékű dokumentumban.

Ez a második kötelezettség az irányelv V. mellékletéből ered; a formáját a nemzeti jog határozza meg. Az akadálymentesítési nyilatkozat megírásáról szóló útmutatónkban átírható sablont talál. Utána pedig tartsa fenn a rutint:

1. Futtassa le az ellenőrzőlistát a három kulcsoldalon, és minden hibáról készítsen képernyőképet.
2. A tartalmi tételeket még ezen a héten javítsa ki saját maga.
3. A témát és a pénztárat érintő tételeket adja át egy fejlesztőnek, a legsúlyosabbal kezdve.
4. Minden javítást teszteljen újra billentyűzettel is, ne csak ellenőrzőprogrammal.
5. Tegye közzé vagy frissítse a nyilatkozatát, dátummal.
6. Ismételje meg, valahányszor új alkalmazást telepít, témát vált, vagy új céloldalt indít.