Webshop-akadálymentesítés: WCAG útmutató a kereséstől a pénztárig

01

Mit jelent az akadálymentes webshop a vásárló számára?

Az akadálymentesség a lényeges információk és funkciók hozzáférhetősége, nem pusztán nagy betű, felolvasógomb vagy külön felület.

Egy gyengénlátó vásárló nagyítva olvashatja az árat és a szállítási feltételeket. Egy mozgáskorlátozott vásárló billentyűzettel vagy kapcsolóval választhat méretet. Egy képernyőolvasót használó vásárló a vezérlők hozzáférhető neve és állapota alapján tájékozódik. Másnak az egyértelmű mezőcímke és a követhető hibaüzenet segít. A jól kialakított felület nem kényszeríti őket kerülőutakra.

A vizsgálat egysége a feladat, nem csak az URL. Ugyanaz a pénztároldal üresen, kitöltve, hibás adattal és feldolgozás közben más állapotot mutat. Egy dinamikus kosárpanel a főoldal megnyitása után még nem is létezik a látható felületen. Ha csak induló oldalakat vizsgál, a lényeges interakciók és a hibából való visszatérés kimaradhatnak.

A megfelelési cél és a vizsgálat terjedelme legyen előre meghatározott. Milyen oldalak, terméktípusok, eszközök, nyelvek és fizetési utak kerülnek sorra? A mintavétel hasznos, de nem jogosít fel arra, hogy a nem vizsgált tartalmakról biztos megfelelést állítson. A következő fejezetek a gyakorlati felmérést szervezik, a jogi hatályt a külön EAA útmutató tárgyalja.

02

WCAG 2.1 AA, WCAG 2.2 és EN 301 549: mi a szerepük?

A WCAG 2.1 AA az A és AA szintű sikerkritériumokra épülő webes mérce. Az EN 301 549 szélesebb informatikai követelményrendszer; egyik neve sem helyettesíti a tényleges vizsgálatot.

A WCAG négy alapelve webshopos nyelven: az információ érzékelhető, a felület kezelhető, a működés érthető, a tartalom pedig a böngészők és segítő technológiák számára robusztusan értelmezhető legyen. Például az alternatív szöveg az érzékelhetőséget, a billentyűzetes kosárkezelés a kezelhetőséget, a konkrét hibaüzenet az érthetőséget támogatja. A helyes szemantika mindezeket összeköti.

Az AA nem átlagpontszám. Egy megfelelőségi célhoz az alkalmazandó A és AA követelmények teljesítését kell értékelni, a teljes oldalak és folyamatok figyelembevételével. Egy kritikus billentyűzetes hiba nem válik elfogadhatóvá attól, hogy más elemek jól teljesítenek. A jelentésben ezért sikerkritérium, bizonyíték és felhasználói hatás szerepeljen egyetlen összesített szám helyett.

A WCAG 2.2 a 2.1-nél újabb W3C-ajánlás, további követelményekkel, például egyes fókusz-, célméret- és hitelesítési kérdésekben. Új fejlesztésnél érdemes ezeket is figyelembe venni, miközben az audit vállalt verzióját pontosan rögzíti. Az EN 301 549 webes része a szabvány adott kiadásában meghatározott WCAG-követelményekre hivatkozik. Az EAA-hoz kapcsolódó megfelelőségi vélelemhez az aktuális hivatalos hivatkozások ellenőrzése szükséges; ne keverje össze ezt egy technikai ellenőrzőlistával.

03

Fejléc, menü és keresés: a vásárlási út kezdete

A vásárló találja meg a tartalmat, érje el a menüt és a keresőt, és értse, hol jár. A fókusz ne tűnjön el a felületben.

A tartalomra ugró link segít átugrani az ismétlődő navigációt. Lehet alaphelyzetben rejtett, de billentyűzetes fókuszban jelenjen meg, és valóban a fő tartalomhoz vezessen. A menü ne csak egér rámutatására működjön. A megnyitás, a bezárás és az almenük elérése kövesse a választott interakciós mintát; a képernyőolvasó számára legyen érthető a vezérlő neve és nyitott állapota.

A keresőnek legyen programozottan kapcsolt címkéje. A nagyítóikon önmagában nem feltétlenül elég hozzáférhető név. Az automatikus javaslatoknál külön ellenőrizze a billentyűzetes kiválasztást, a találatokhoz való eljutást és a bezárást. A javaslatlista megjelenése ne vigye el önkényesen a fókuszt. Üres találatnál adjon érthető visszajelzést és használható továbblépést.

A címsorok és a dokumentum fő régiói támogassák a gyors tájékozódást. Egy vizuálisan nagynak látszó szöveg nem lesz automatikusan címsor. Az oldalcím és a főcím segítsen megkülönböztetni a kategóriát, terméket és pénztárt. A rögzített fejlécet, sütikezelőt és más takaró felületeket is próbálja ki nagyítás mellett: ne rejtsék el az éppen használt vezérlőt.

04

Kategóriák, szűrők és dinamikusan frissülő találatok

A szűrő legyen felismerhető és kezelhető, a találatok változása pedig érthető. A rendezés után a vásárló ne veszítse el a helyét.

A szűrésnél ellenőrizze a kategóriaválasztót, az árhatárokat, a jelölőnégyzeteket és a kiválasztott feltételek törlését. Egy kizárólag húzással működő ársávhoz használható alternatíva szükséges, például megfelelően címkézett minimum- és maximummező. A kiválasztott állapot ne csak halvány színváltozásból derüljön ki. A szűrők neve a termékkínálat ismerete nélkül is legyen érthető.

AJAX-os frissítésnél az URL változatlan maradhat, miközben a találati lista teljesen átalakul. A fontos állapotváltozást megfelelően kialakított státuszüzenet jelezheti, például a találatok számát. Ne olvastassa fel minden frissítéskor a teljes listát, és ne küldje a fókuszt automatikusan a dokumentum elejére. A cél a tájékozódás támogatása, nem a képernyőolvasó túlterhelése.

A lapozás és a további termékek betöltése külön tesztállapot. Legyen elérhető a következő lépés, és a vásárló értse, hogy új elemek kerültek a listába. A termékkártyákban a név, ár, elérhetőség és link logikus kapcsolatban jelenjen meg. Ne alakítson ki feleslegesen sok ismételt fókuszpontot ugyanahhoz a termékhez, de a valóban külön műveletek maradjanak külön használhatók.

05

Termékoldal: képek, árak és változatválasztás

A vásárlási döntéshez szükséges információ legyen szövegesen is hozzáférhető. A változatválasztó és a kosárgomb neve, állapota és működése legyen egyértelmű.

A termékfotó alternatívája a kép szerepétől függ. Egy részletfotó fontos tulajdonságot közvetíthet, míg egy dekorációhoz üres alt érték lehet megfelelő. Ne találjon ki anyagot, funkciót vagy színt a leírás kedvéért. A képen megjelenő mérettáblázat vagy lényeges szerelési útmutató részletes szöveges megfelelőjét is biztosítsa; egy rövid alt mondat erre nem mindig elegendő.

A méret- és színválasztó ne csak vizuálisan legyen érthető. A színmintának legyen megkülönböztethető neve, a választott változat állapota legyen lekérdezhető, és a nem rendelhető lehetőségek kezelése se vezessen zsákutcába. Mennyiségválasztónál a növelő és csökkentő művelet neve mondja meg, mit változtat. A készlethiányhoz és a változat nélküli kosárba helyezéshez tartozzon konkrét visszajelzés.

WCAG 2.1 AA szinten normál szövegnél legalább 4,5:1, nagy szövegnél legalább 3:1 a kontrasztkövetelmény, a szabvány kivételeinek figyelembevételével. A vezérlő felismeréséhez szükséges vizuális információnál a nem szöveges kontrasztot is vizsgálja. Az akciós és eredeti ár, az elérhetőség, a fókusz és a kiválasztott állapot külön színpár lehet; ne csak a fő kosárgombot mérje meg.

06

Kosár és kosárpanel: fókusz, műveletek, visszajelzés

A kosár változásáról érzékelhető visszajelzés kell, de nem minden változás indokol fókuszváltást. A panel működését annak valódi szerepe alapján alakítsa ki.

Kosárba helyezés után a vásárló tudja meg, hogy a művelet sikerült-e. Egy képernyőolvasóval érzékelhető státuszüzenet sok esetben megfelelő, anélkül hogy elmozdítaná a fókuszt. Ha új panel nyílik, döntse el, valóban modális párbeszédablakról van-e szó. Egy nem modális oldalsávra nem helyes gondolkodás nélkül ráerőltetni a modális ablak fókuszszabályait.

Valódi modális ablaknál a fókusz az ablakba kerül, a háttér interakciója korlátozott, és legyen megfelelő bezárási lehetőség. A Tab ablakon belüli körbejárása ebben a helyzetben nem önmagában hiba. A probléma akkor keletkezik, ha nem lehet kilépni, a bezáró gomb nem elérhető, vagy bezárás után a fókusz elveszik. A visszaadásnál az eredeti vezérlő vagy egy másik logikus cél szükséges.

A kosároldalon a mennyiségmódosítás, törlés és kuponhiba is legyen tesztelhető. A gombok neve különböztesse meg, melyik termékre vonatkoznak. A végösszeg frissülése legyen követhető, a törölt termék után pedig maradjon értelmes helyen a fókusz. Próbálja ki az utolsó termék törlését is: az üres kosár új állapot, nem csak a korábbi lista kevesebb sorral.

07

Pénztár, azonosítás és fizetés: a kritikus szakasz

A mezők címkéje, az érthető hibajelzés, a használható hitelesítés és a fizetés utáni állapot együtt határozza meg, végigvihető-e a rendelés.

Minden mező kapjon tartós, látható és programozottan hozzákapcsolt címkét. A placeholder nem pótolja ezt, mert gépeléskor eltűnik. A kötelező adatok és az elvárt formátum legyen előre érthető. A megfelelő beviteli típus és autocomplete érték megkönnyítheti a kitöltést, de ne kérjen olyan adatot, amely a rendeléshez nem szükséges. A szállítási és fizetési lehetőségek logikusan csoportosított vezérlők legyenek.

A hibát ne kizárólag piros szín vagy ikon jelezze. Mondja meg az érintett mezőt, a problémát és ahol lehet, a javítás módját. A hiba szövege legyen a mezőhöz kapcsolva; több hiba esetén használható összesítő is segíthet. Sikertelen beküldés után őrizze meg a helyesen kitöltött adatokat. A fókuszkezelés legyen következetes, és a vásárló billentyűzettel is térjen vissza a javítandó pontra.

Az ügyfélfiók, jelszó-visszaállítás, ellenőrzőkód, banki hitelesítés és külső fizetési oldal is része lehet az útnak. Használjon tesztkörnyezetet vagy előre egyeztetett eljárást; ne indítson véletlen valódi rendelést. Vizsgálja a sikeres és elutasított fizetésből való visszatérést. Hálózati hiba esetén ne közöljön biztos sikert vagy sikertelenséget addig, amíg a rendelési rendszer állapota nem tisztázott.

<label for="email">E-mail-cím</label>
<input id="email" type="email" autocomplete="email"
  aria-invalid="true" aria-describedby="email-hiba">
<p id="email-hiba">Adjon meg egy érvényes e-mail-címet.</p>
<!-- A hibajelzés csak tényleges hibás állapotban legyen jelen. -->

08

Gépi, billentyűzetes és képernyőolvasós vizsgálat

A három funkcionális vizsgálati réteget vizuális és tartalmi ellenőrzés egészíti ki. Nincs minden oldalra érvényes, megbízható „automatizálható százalék”.

A gépi eszköz gyorsan jelezhet bizonyos hiányzó címkéket, hibás ARIA-használatot, nyelvi jelölési vagy kontrasztproblémákat. A találatot értelmezni kell: egy alt attribútum létezése nem bizonyítja, hogy a leírás jó, és egy dinamikus vezérlő induló állapota nem mutatja a teljes működését. A program által felvetett, kézi értékelést igénylő tételeket külön kezelje a biztosan azonosított hibáktól.

Billentyűzettel vizsgálja a teljes út elérhetőségét, a sorrendet, a fókuszjelzést és a kilépési lehetőségeket. Képernyőolvasóval ellenőrizze a nevet, szerepet, állapotot, a dokumentum szerkezetét és a változások bejelentését. Az NVDA egy használható Windows-környezetű eszköz; a vizsgálatban a böngésző és az eszköz verzióját is rögzítse. Egyetlen kombináció sikeres próbája nem jelent minden segítő technológiára szóló garanciát.

A vizuális és tartalmi rétegben a nagyítást, a keskeny nézetre való áttördelést, a szövegtávolságot, a mozgó tartalmat és a magyarázatok érthetőségét is nézze meg. Ezek nem maradhatnak ki azért, mert a három funkcionális próba sikerült. Az auditmódszertan ezért négy egymást kiegészítő réteget nevez meg: gépi, billentyűzetes, képernyőolvasós, valamint vizuális és kognitív ellenőrzést.

09

Shoprenter, UNAS, WooCommerce és Shopify: ki mit tud javítani?

Nem a platform neve dönti el az akadálymentességet. Először a konkrét hibát reprodukálja, majd azonosítsa a tartalom, sablon, bővítmény és platform felelősségi határát.

Bérelt rendszernél a kereskedő jellemzően a rendelkezésére álló beállításokat, tartalmakat és engedélyezett sablonmódosításokat tudja kezelni. Shoprenter- vagy UNAS-webshopnál ezért először ellenőrizze, hogy az adott csomagban és sablonban mi módosítható. A platform által kezelt pénztár vagy központi funkció javításához a szolgáltató közreműködése lehet szükséges. Ez nem állítás arról, hogy a platform hibás: egy konkrét, bizonyított tétel megoldási útja.

WooCommerce-nél a WordPress, a téma, a bővítmények és az egyedi fejlesztés együtt alkotja a felületet. Sok rész módosítható, de ettől még a változtatás szakértelmet és regresszióvizsgálatot igényel. Egy megfelelőnek kialakított alapkomponenst is megváltoztathat egy bővítmény. Frissítéskor ellenőrizze újra a szűrőt, mini-kosarat, mezővalidációt és más lényeges interakciókat.

Shopify esetén a téma, az alkalmazások és az adott csomagban elérhető pénztármódosítási lehetőségek határozzák meg a mozgásteret. Ne más webshop tapasztalatából következtessen a sajátjára. Minden rendszernél kérjen pontos környezetet, induló állapotot, lépéssort és elvárt eredményt tartalmazó hibajegyet. A szolgáltató így vizsgálható problémát kap, nem általános megfelelőségi követelést.

10

Reprodukálható hibajegy, javítás és retest

A jó hibajegy megismételhető. A javítás akkor ellenőrzött, ha ugyanazt a feladatot az eredeti környezet és a kapcsolódó állapotok figyelembevételével újra tesztelték.

A hibajegy tartalmazza az érintett URL-t, a környezetet, a kezdőállapotot, a pontos lépéseket, a tényleges és elvárt eredményt, valamint az érintett követelményt. A felhasználói hatásból derüljön ki, miért fontos a javítás. A „rossz ARIA” megjegyzés kevésbé használható, mint annak leírása, hogy a szűrő kiválasztott állapota nem jut el a képernyőolvasóhoz.

Prioritásnál a rendelést blokkoló hiba, a gyakran használt funkció és az érintett felhasználók akadálya legyen a döntés alapja. A közös komponensben javítható probléma sok oldalon megszüntethet azonos hibát, de ezt ellenőrizni kell. A feladattervben különítse el a tartalmi javítást, a fejlesztési módosítást és a külső szolgáltatóra váró tételt. Utóbbinak is legyen felelőse és következő lépése.

Retestnél ne csak a módosított kódsort nézze meg. Ismételje az eredeti hibát előidéző utat, majd ellenőrizze a szomszédos állapotokat. Egy kijavított kosárpanel ne törje el a termékoldal fókuszsorrendjét. A hibastátusz legyen pontos: javítva és ellenőrizve, továbbra is fennáll, vagy még nem ellenőrizhető. A célzott retest nem egyenlő a teljes webshop új auditjával; a terjedelmét külön rögzítse.

• URL, környezet és induló állapot
• Megismételhető lépések és tényleges eredmény
• Elvárt működés és kapcsolódó követelmény
• Felhasználói hatás, felelős és javítási irány
• Utóellenőrzés ideje, módszere, terjedelme és eredménye

11

Fenntartás: mit ellenőrizzen frissítés és tartalomfeltöltés után?

Az akadálymentesség nem egyszeri állapot. A sablonfrissítés, új alkalmazás vagy terméktartalom visszahozhat korábbi akadályokat.

Építsen rövid ellenőrzési kaput a kiadás elé. A keresés, változatválasztás, kosár és pénztár alapútja legyen újra bejárva, különösen ha ezeket érintette a változás. A kritikus hibákhoz tartozzon regressziós próba, az automatizálható tételekhez gépi ellenőrzés. A manuális feladatot ne jelölje elvégzettnek azért, mert a program nem adott hibát.

A tartalomfeltöltők kapjanak egyszerű szabályokat a képleírásról, címsorokról, linknevekről és táblázatokról. A reklámgrafikába égetett akciós feltétel vagy a képként feltöltött mérettáblázat később is akadályt teremthet. A termékleltár és a dokumentáció frissítése éppúgy része a fenntartásnak, mint a kód karbantartása. A vásárlói visszajelzések kerüljenek vissza a hibakezelésbe.

Üzletileg a könnyebben használható folyamat szélesebb körnek lehet hozzáférhető, és csökkentheti a segítségkérés szükségességét. A szemantikus szerkezet a tartalom értelmezését is segíti, de az akadálymentesítés nem garantál Google-helyezést, AI-ajánlást vagy meghatározott konverziónövekedést. A saját eredményt feladatsikerrel, felhasználói próbával és megfelelően értelmezett analitikával mérje. Az első lépés egy reális terjedelmű, dokumentált felmérés.