A hibától az ellenőrzött javításig

Webshop-akadálymentesítés a gyakorlatban

Két szemléltető esettanulmány arról, hogyan lesz egy akadálymentességi problémából érthető fejlesztői feladat és dokumentált utóellenőrzés.

Jó platform, mégis ellenőrizendő webshop?

Igen. A platformok és sablonok tartalmazhatnak akadálymentességet támogató megoldásokat. A konkrét webáruház használhatóságát azonban a beállítások, feltöltött tartalmak, egyedi módosítások és külső bővítmények együtt alakítják. Egy platform neve önmagában sem hibát, sem megfelelőséget nem bizonyít.

Ha egy funkció már megfelelően működik, nincs javítási feladat: ezt az ellenőrzésben is így kell rögzíteni. A hibát az adott oldalon és állapotban reprodukálni kell, nem a webshopmotor hírnevéből következtetni rá.

Bizonyítható hiba
Célzott javítás
Megismételt ellenőrzés

Minta 01 · Shoprenter · szemléltető minta

Divatwebshop: amikor a tartalom és az arculat számít

Egy elképzelt, bérelhető rendszerben működő divatwebshop, egyedi arculati színekkel és rendszeresen feltöltött termékképekkel. A példában nem a Shoprenter alapműködését minősítjük, hanem a kereskedő által kezelt tartalmakat és módosításokat vizsgáljuk.

Lehetséges hibaforrás

Tartalomfeltöltés és egyedi megjelenés; csak konkrét vizsgálattal dönthető el, hogy egy tényleges webshop érintett-e.

A termékkép leírása csak a fájl neve

A „foto-123.jpg” nem mondja el, milyen a bemutatott cipő. Egy képet nem látó vásárló fontos termékinformációt veszíthet.

Javítási irány: Ahol a rendszer engedi, a kép szerepének megfelelő alternatív szöveg rögzítése. Például: „Fekete bokacsizma, oldalsó cipzárral”. A pusztán dekoratív képet külön kezeljük.
Mit ellenőrzünk újra?: A megjelenített oldal kódjában és képernyőolvasóval is ellenőrizzük a tényleges leírást; az adminmező kitöltése önmagában nem bizonyítja, hogy helyesen jelenik meg.
Kapcsolódó WCAG 2.1-kritérium: 1.1.1 – Nem szöveges tartalom

Az arculati színnel megjelenő ár nehezen olvasható

A világos színű akciós ár fehér háttéren gyengénlátó vásárlóknak nehézséget okozhat.

Javítási irány: A tényleges betűméret és háttér alapján megmérjük a kontrasztot. Szükség esetén módosítjuk az érintett színbeállítást vagy a célzott stílust, nem feltétlenül az egész arculatot.
Mit ellenőrzünk újra?: A megváltoztatott árakat és gombállapotokat újramérjük. Az ár, a kedvezmény és az eredeti ár jelentése szín nélkül is érthető maradjon.
Kapcsolódó WCAG 2.1-kritérium: 1.4.3 – Kontraszt (minimum)

Tanulság: Egy megfelelő sablon is igényel tudatos tartalomkezelést. A javítás ebben a mintában a képleírásokra és az arculati beállításokra összpontosít; a tényleges lehetőségek a sablontól és a hozzáférésektől függenek.

Ez a minta javítási és ellenőrzési irányokat mutat, nem lezárt vizsgálati eredményt vagy megfelelőségi igazolást.

Minta 02 · WooCommerce · szemléltető minta

Lakberendezési webshop: szűrők, minikosár és pénztár

Egy elképzelt WooCommerce-webshop külső szűrőbővítménnyel, egyedi minikosárral és módosított pénztármezőkkel. A példa ezek együttműködéséről szól, nem a WooCommerce alapértelmezett működésének hibajegyzéke.

Lehetséges hibaforrás

Külső bővítmény és egyedi fejlesztés kölcsönhatása; a sablon és a bővítmények verzióját is rögzíteni kellene egy valódi auditban.

A szűrés eredményét csak vizuálisan látni

A terméklista frissül, de a képernyőolvasót használó vásárló nem kap tájékoztatást az új találatokról.

Javítási irány: A találatszám változásához megfelelő státuszüzenetet adunk. Megőrizzük a kiszámítható fókuszkezelést; nem mozgatjuk indokolatlanul a fókuszt minden frissítéskor.
Mit ellenőrzünk újra?: Billentyűzettel végzett szűrés közben képernyőolvasóval ellenőrizzük a státusz bejelentését, az ismételt változásokat és a nulla találatos állapotot is.
Kapcsolódó WCAG 2.1-kritérium: 4.1.3 – Állapotüzenetek

A minikosár bezárása után elvész a fókusz

A vásárló nem tudja, hol folytathatja a billentyűzetes navigációt.

Javítási irány: A minikosár viselkedéséhez igazítjuk a fókuszkezelést. Ha modális párbeszédablak, belépéskor oda kerül a fókusz, bezáráskor pedig az azt megnyitó vezérlőre tér vissza.
Mit ellenőrzünk újra?: Megnyitás, Tab és Shift+Tab, bezárógomb és – ahol elvárt – Escape tesztelése. A fókusz láthatóságát és sorrendjét is ellenőrizzük.
Kapcsolódó WCAG 2.1-kritérium: 2.1.1 – Billentyűzet; 2.4.3 – Fókuszsorrend

Az egyedi pénztármező hibája nincs összekapcsolva a mezővel

A vásárló látja vagy hallja, hogy hiba történt, de nem tudja, melyik adatot javítsa.

Javítási irány: Látható címkét, konkrét hibaüzenetet és programozott kapcsolatot adunk az érintett mezőhöz. Megőrizzük a bevitt adatokat, ahol ez lehetséges.
Mit ellenőrzünk újra?: Szándékosan hibás kitöltéssel ellenőrizzük a hiba azonosítását és javíthatóságát, majd a sikeres továbblépést. Éles fizetést a teszt nem indít.
Kapcsolódó WCAG 2.1-kritérium: 3.3.1 – Hibaazonosítás; 3.3.2 – Címkék vagy utasítások

Tanulság: A jó alaprendszer nem helyettesíti a teljes vásárlási út ellenőrzését. Bővítménycsere vagy célzott kódjavítás is szóba jöhet, de a döntést mindig az adott hiba és környezet alapján kell meghozni.

Ez a minta javítási és ellenőrzési irányokat mutat, nem lezárt vizsgálati eredményt vagy megfelelőségi igazolást.

Azonos szerkezet, ellenőrizhető állítások

Esettanulmány-sablon valódi auditokhoz

Egy későbbi, anonimizált ügyféleset ebben a szerkezetben dokumentálható. A pontos hibaszám, határidő vagy utóellenőrzési eredmény csak mérési bizonyítékkal kerülhet bele.

Környezet és vizsgálati kör
Platform, sablon és bővítmények verziója; vizsgálat dátuma; ellenőrzött oldalak, állapotok és eszközök. Mi maradt ki, és miért?
Kiinduló állapot és bizonyíték
Hibaazonosító, reprodukálható lépések, érintett elem, WCAG-kritérium és felhasználói hatás. Képernyőkép vagy kódrészlet személyes adatok nélkül.
Javítás és felelősség
Az elvégzett módosítás, a megvalósítás helye és felelőse. Különítsük el a tartalom-, sablon-, bővítmény- és egyedi fejlesztési feladatokat.
Utóellenőrzés és nyitott kérdések
Azonos vizsgálati körben megismételt gépi és szükséges kézi tesztek. Javított, továbbra is hibás és nem ellenőrzött tételek külön felsorolva.
Eredmény és tanulság
Csak igazolt eredmények, a mérés határaival együtt. A közölhető adatokat és az anonimizálást az ügyféllel jóvá kell hagyatni; ismeretlen eredmény helyett ne írjunk becslést.

Mit bizonyít az utóellenőrzés?

Azt, hogy a kijelölt hibák az ellenőrzött környezetben és állapotokban javultak-e. A gépi teszt mellett a felhasználói folyamatokhoz szükséges kézi vizsgálatot is meg kell ismételni. A nulla gépi hiba nem jelenti automatikusan a teljes WCAG- vagy EAA-megfelelőséget.

A dokumentációban külön szerepelnek a vizsgált és nem vizsgált részek, a nyitott problémák és a korlátok. A nyilatkozattervezet az igazolt állapotot tükrözi; nem hatósági tanúsítvány. A jelentést kiküldés előtt ember hagyja jóvá, a kapcsolódó támogatás írásos.

Auditmódszertan Minta auditjelentés Javítási támogatás és retest

Hivatalos szakmai háttér

A példák saját magyarázatok. A vizsgálati kritériumok és a megismételhető értékelés háttere:

A saját webshopján mi az ellenőrizendő?

Ne egy platformról szóló általános állítás alapján döntsön. A saját tartalmak, beállítások és vásárlási folyamat vizsgálata ad használható feladattervet.

Gyorsaudit kérése Auditcsomagok és árak