Mi ellen indítanak pert: Útmutató a 6666 akadálymentességi panasz mögött álló felhasználói felületi mintákhoz

A fejléc minden oldalon az első interaktív felület, és a hamburger gomb gyakran az első elem, amelyhez a billentyűzetet használó felhasználó eljut. Amikor ez a gomb <div> ha egy elem CSS-háttérképpel rendelkezik, nincs hozzáférhető neve, vagy olyan menüt nyit meg, amely elvonja a fókuszát, illetve nem jelzi, hogy nyitott vagy zárt állapotban van, akkor a webhely egészét strukturálisan lehetetlenné válik a billentyűzetről kezelni, még mielőtt a felhasználó bármilyen tényleges tartalomhoz hozzáférne.

A „skip link” a társuló hiba. Egy működő "Skip to main content" Ez a link mindössze öt soros javítás, de egyben a leghatékonyabb módszer arra, hogy kiderüljön: szerepel-e egyáltalán az akadálymentesség a fejlesztőcsapat ellenőrzőlistáján. A panaszok gyakran említik mindkettőt ugyanabban a bekezdésben, mert a hiányzó vagy hibás ugróhivatkozás a figyelmeztető jel – ha a csapat nem épített be ugróhivatkozást, akkor szinte biztos, hogy az aria-expanded állapotokat sem.

A menüindítót valós <button> látható vagy kizárólag képernyőolvasóval olvasható szöveges címkével és egy kezelt aria-expanded attribútum. Adjon meg egy "Skip to main content" olyan link, amely a kurzor ráhelyezésekor láthatóvá válik, és a <main> megjelölés. Győződjön meg arról, hogy a fókusz a menü megnyitásakor a menübe kerüljön, bezárásakor pedig visszatérjen a kiváltó gombra, és hogy Esc bezárja a menüt.

A keresőfunkciót a legtöbb nagy webhelyen egyedi komponensként valósítják meg – ez egy visszacsapásmentes szövegbeviteli mező, amely minden billentyűleütéskor lekérdezést indít, és egy lebegő javaslatlistát jelenít meg egy abszolút pozícionált <div>. Maga a szövegbeviteli mező általában rendben van. A javaslatlista viszont szinte soha. A lista a beviteli mező DOM-kontextusán kívül jelenik meg, nincs role="listbox", nem aria-activedescendant, és az eredmények megjelenésekor nincs élő régióra vonatkozó bejelentés. A képernyőolvasó-használó begépel valamit, nem hall semmit, megnyomja az Enter billentyűt, és megkapja az eredményoldalt, amiről nem is tudta, hogy ott várja.

Ugyanez az architektúra-minta visszatér a facettás keresés szűrőpaneljeiben és magában az eredménylistában is: olyan elemek, amelyekre a billentyűzet fókuszát lehet helyezni, amelyek vizuálisan láthatók, de hangos jelzést soha nem kapnak. A kereséssel kapcsolatos panaszok ritkán a keresőmezőre vonatkoznak; inkább mindarra vonatkoznak, ami a felhasználó beírása után megjelenik.

Használja a bevált WAI-ARIA Combobox mintát: role="combobox" a bemeneten a aria-expanded, aria-controls, és aria-activedescendant csatlakoztatva egy role="listbox" javaslatok. Hozzon létre egy udvarias, élő területet, amely jelzi az eredmények számát. Gondoskodjon arról, hogy a javaslatok listája ne csak egérrel, hanem a lefelé nyíl gombbal is elérhető legyen.

A PLP-rács több rossz gyakorlatot is egyetlen képernyőn egyesít. Minden egyes elem általában egy kattintható kártya, amelyen három vagy négy interaktív alelem található – kép-link, cím-link, színminták, gyors hozzáadási gomb –, és mindezt egy újabb, a termékoldalra mutató link veszi körül. Ennek eredményeként egymásba ágyazott interaktív elemek keletkeznek (ami HTML-szabályszegésnek minősül), felesleges link szövegek jelennek meg („Hero Dash Three Graphic Image Link” négy alkalommal ismételve), valamint a színminták <div> olyan elemek, amelyek rendelkeznek kattintáskezelővel, de nincs szerepük és nevük.

A szűrőoldalsáv egy újabb hiba-kategóriát vezet be. A szűrőszűrők általában jelölőnégyzetekből álló listák, de valójában egyedi div- és span-elemekből épülnek fel, amelyek stílusukban jelölőnégyzeteknek tűnnek, míg a tényleges <input> a képernyőn kívülre rejtve. Amikor ez a rejtett beviteli mező elveszíti a kapcsolódását – akár egy CSS-szabály, akár egy szóköz-leütéseket elnyelő JavaScript-eseménykezelő, akár egy hiányzó for attribútum a látható címkén – a szűrő ekkor kizárólag egérrel használható.

Csempénként egy hivatkozást használjon leíró szöveggel, ne pedig három linket termékenként. A színmintákat valósághűen ábrázolja <button> elemek egy role="radiogroup". Szűrőelemek létrehozása a tényleges <input type="checkbox"> kapcsolódó elemek <label> címkék; a beviteli mezőket inkább láthatóan formázzuk, ne pedig elrejtve. A szűrőváltozásokat egy udvarias élő régióval jelenítsük meg.

A termékleírás oldalon a képernyőolvasó-felhasználónak több konkrét lépést is végre kell hajtania a megfelelő sorrendben: ki kell választania a színt, a méretet, meg kell adnia a mennyiséget, majd a kosárba kell helyeznie a terméket. A modern e-kereskedelmi rendszerekben ezek a lépések mindegyike egyedi widgetként van megvalósítva – általában egy vízszintes sorban <button>- alakú <div>A méretek tekintetében: CSS-sel formázott div-ekből összeállított színes csempék, valamint egy beviteli mezőt két oldalról körülvevő ikon gombokból álló numerikus lépcsőzetes szabályozó. A növelő és csökkentő gombok rendszerint hozzáférhetőségi név nélkül kerülnek forgalomba; a panaszok leírása szerint ezek „Gomb, gomb” néven hirdették anélkül, hogy kiderülne, mivel foglalkoznak.

A mérettáblázatok és méretútmutatók egy külön kategóriát képeznek a hibák között: szinte mindig egy „Mérettáblázat” link mögött találhatók, amely egy felugró ablakot nyit meg, és magának a linknek gyakran nincs felirata, a felugró ablaknak gyakran nincs megadott címe, a benne található táblázatnak pedig gyakran nincsenek sor- vagy oszlopfejlécei.

Használjon valódi űrlapvezérlőket. A színmintáknak és a méretválasztóknak role="radiogroup" a role="radio" gombok (vagy láthatatlanul megjelenített rádiógombok), amelyek mindegyike rendelkezik egy „Méret: Közepes” típusú, akadálymentes nevével. A mennyiség-beállító csúszkának egy címkével ellátott számbeviteli mezőnek kell lennie, amelyhez növelő és csökkentő gombok tartoznak, és amelyek akadálymentes neve tartalmazza a műveletet és az aktuális mennyiséget. Az egész kiválasztott blokkot egy felirattal ellátott fieldset-be kell ágyazni.

A „Kosárba” gomb megnyomása az e-kereskedelmi vásárlási folyamat leggyakrabban tesztelt pillanata, és egyben az egyik leggyakrabban hibásan működő lépés a segítő technológiákat használó felhasználók számára. A folyamat mechanikus: a látogató megnyomja a gombot, két-három másodpercre megjelenik egy kis megerősítő felugró ablak vagy egy mini kosár fiók, majd a fejlécben a kosár ikonján frissül a darabszám-jelölő. A látó felhasználók mindhárom jelzést látják. A képernyőolvasó-felhasználók általában egyet sem kapnak. Az ablak a megjelenítési területen kívül jelenik meg, a fiók fókuszkezelés nélkül jelenik meg, és a kosárban lévő termékek számának változása egyszerű DOM-módosításként történik, amit egyetlen képernyőolvasó sem jelenti be.

Az eredmény egy olyan gomb, amely a felhasználó szemszögéből nézve nem csinál semmit. Megnyomják, nem hallanak semmit, azt gondolják, hogy nem működött, és újra megnyomják. Néhány panaszban azt írják, hogy öt-hat alkalommal nyomták meg a gombot, mire rájöttek, hogy a kosárba csendben öt-hat termék került.

A kosár állapotát jelző területet zárjuk be aria-live="polite" és minden sikeres hozzáadás után frissítse a szövegét. Ha a felület megerősítő ablakot használ, az ablak megnyitásakor helyezze át a fókuszt az ablakra, bezárásakor pedig vissza az eredeti gombra. Frissítse a kosárban lévő termékek számát jelző jelölést egy kizárólag képernyőolvasóknak szóló bejelentéssel, például: „1 termék hozzáadva. Kosárban összesen: 3 termék.”

A kizárólag ikonokból álló vezérlőelemek előre látható módon nem működnek megfelelően: a látható tartalom egy SVG- vagy ikonbetűkészlet-szimbólum, az akadálymentes tartalom üres, a képernyőolvasó pedig az elem név nélküli szerkezeti szerepére korlátozza a kimenetet. A kosár ikon végül „link” vagy „összecsukott” néven kerül bejelentésre; a csevegőbuborék „gomb” néven; a láblécben található közösségi ikonok sora pedig „link, link, link, link, link” néven . A felhasználónak nincs módja megtudni , hogy ezek közül melyik mit csinál .

A kosárikonok építészeti okokból gyakrabban adnak hibát, mint más ikonok: számos megvalósításban a kosárban lévő termékek számát az ikon hozzáférhető nevében jelenítik meg (pl. az ikon belsejében „0” látható az SVG-ben), és a képernyőolvasó csak a számjegyet veszi fel. A panaszok szerint a kosárikon leírása „3, link” vagy „0, link” formában hangzik el, anélkül, hogy jelzés lenne arra, hogy a „3” a kosárban lévő termékek számát jelenti.

Minden kizárólag ikonból álló vezérlőelemnek rendelkeznie kell egy hozzáférhető névvel. Adjon hozzá egy aria-label a gombra, vagy helyezzen el benne egy láthatatlan szövegcímkét: "Shopping cart, 3 items". Kerülje el, hogy az ikon leíró nevében kontextus nélkül számjegyeket használjon. A látható szöveg mellett elhelyezett díszítő ikonok esetében használja a aria-hidden="true" kattintson az ikonra, és hagyja, hogy a szöveg viselje a címkét.

A fizetési oldal négyzetpixelenként több megfelelési kockázatot hordoz, mint egy e-kereskedelmi webhely bármely más oldala, és a hibalehetőségek sűrűn fordulnak elő. Az egyedi beállításként megjelenített címválasztó legördülő menük <div> olyan elemek, amelyek figyelmen kívül hagyják a szóköz billentyűt. A kötelező mezőket jelző jelölők csak piros csillagként jelennek meg, aria-required és nincs programozási kapcsolat. A mező alatt piros szöveggel megjelenő beépített hibaüzenetek, aria-describedby a mező és a hiba közötti kapcsolat hiánya, valamint az, hogy az érvényesítés sikertelensége esetén nem jelenik meg hibaüzenet. A felhasználó kitölti az űrlapot, rákattint a „Tovább” gombra, de a rendszer észrevétlenül visszaveti, és nincs módja megtudni, mely mezők nem feleltek meg, illetve miért.

Több száz esetben ugyanazok a panaszok ismétlődnek: a hibaüzenetek nem hangosítva, a hibaüzenetek homályosak, a fizetési adatok nem adhatók meg. Ezek nem elszigetelt hibák. Ezek a legtöbb olyan e-kereskedelmi fizetési komponens alapértelmezett viselkedése, amelyeket kifejezett akadálymentesítési fejlesztés nélkül szállítanak.

Használjon valódi <label> a bemenetekhez társított elemek for/id. A kötelező mezőket jelölje meg aria-required="true" és a kötelező mezőket ne csak színnel, hanem látható szöveggel is jelölje meg. Érvényesítés sikertelensége esetén a hibaüzenetet a beviteli mező aria-describedby cél, adja meg a hibás mezőt aria-invalid="true", és helyezze a billentyűzet fókuszát az első hibás mezőre. Az űrlap tetején jelenítsen meg egy összefoglaló hibaüzenetet, amelyben hivatkozásokkal jelölje meg az egyes hibás mezőket.

A fizetési blokk azért szokatlan, mert gyakran egy beágyazott, harmadik féltől származó iframe – például a Stripe Elements, a Braintree Hosted Fields vagy az Adyen drop-in – jeleníti meg. Az iframe-en belül a fizetési szolgáltató saját űrlapja általában jól fel van címkézve. De abban a pillanatban, amikor egy webhely saját kártyaadat-beviteli mezőket hoz létre, vagy a beágyazott mezőket olyan egyedi elrendezésbe ágyazza, amely vizuális helyőrzőkkel felülírja a címkéket, a négy mező – szám, lejárati dátum, CVV, irányítószám – a képernyőolvasó számára üres beviteli mezők sorozatává válik.

A CVV mezőt jelölik meg a leggyakrabban helytelenül, mivel a fejlesztők gyakran kicserélik a címkéjét egy kérdőjel ikonra, amelyre kattintva megjelenik egy segítő szöveg, amely elmagyarázza, mi is az a CVV. A segítő szöveg azonban nem helyettesíti a címkét; a mezőnek továbbra is szüksége van egy programozási névre. Ha nincs ilyen neve, a képernyőolvasó a teljes fizetési blokkot „szerkesztés, szerkesztés, szerkesztés, szerkesztés” felirattal jelzi, és a tranzakció leáll.

Ha harmadik fél által üzemeltetett mezőintegrációt használ, kövesse a szolgáltató akadálymentességi útmutatásait – a legtöbbjük dokumentált módszert kínál a mezők iframe-en kívüli címkézésére. Ha egyedi kártyaolvasó modult fejleszt, minden beviteli mezőhöz valódi <label> elem látható szöveges címkével, valamint autocomplete="cc-number" / cc-exp" / cc-csc" attribútumokat, hogy a jelszókezelők és a segítő technológiák a mezőket rendeltetésük szerint azonosíthassák.

A kosár oldalon megismétlődik a termékoldalon tapasztalt mennyiségválasztó-hiba, csakhogy itt még nagyobb a tét: az a képernyőolvasó-felhasználó, aki nem tudja kezelni a mennyiségválasztót, nem tudja véglegesíteni a megrendelést. A „Törlés” gomb önmagában is egy rossz gyakorlat – általában egy kis × ikon az egyes tételek mellett, gyakran látható szöveg nélkül, nincs aria-label, és a sor eltávolításakor sem hallatszik semmilyen jelzés. A felhasználó megnyomja azt a gombot, amiről reméli, hogy az eltávolítás gombja, a sor eltűnik, a képernyőolvasó pedig hallgat. Nincs mód arra, hogy megerősítsük: a művelet sikeresen lezajlott-e.

Számos panasz egy ehhez kapcsolódó hibajelenséget ír le: a kosár aktuális összege dinamikusan frissül, amikor a mennyiségek változnak vagy termékeket távolítanak el, de az új összeg egyszerű DOM-szövegként jelenik meg, bármilyen élő régión kívül, így a felhasználó nem tudja, hogy mennyit kell fizetnie.

Minden sorban megjelenjen egy „Törlés” feliratú gomb (pl., "Remove Blue T-Shirt, size M, from cart"). A mennyiséget beállító csúszkáknak az aktuális értéküket az elérhető név részeként vagy párosított élő régió-frissítések révén kell jeleníteniük. A kosár részösszegének egy aria-live="polite" régióban, így a változásokról értesítést kap. A törléseket visszavonási lehetőséggel erősítse meg.

Ez az adatkészlet legnagyobb kategóriája, mivel ennek a problémának a felismerése a legkevésbé, figyelmen kívül hagyása pedig a legdrágább. A képernyőolvasó végigjárja a DOM-ot, és amikor egy <input>, és kiolvassa a hozzáférhető nevét – amelyet a következő sorrendben számol ki: aria-labelledby, aria-label, egy kapcsolódó <label for>, a title attribútumot vagy a helyőrzőt. Ha ezek közül egyik sem létezik, a képernyőolvasó csak a szerepkört jelenti be: „szerkesztőmező” vagy „szerkesztés, üres”. Ez a mondat szinte szó szerint több száz panaszbejegyzésben visszatér.

Ennek oka strukturális jellegű. A modern tervezési rendszerek gyakran helyettesítő szöveget jelenítenek meg a beviteli mezőben a látható címke helyett, és a fejlesztők azt feltételezik, hogy ez a helyettesítő szöveg látja el a címkézés feladatát. Pedig nem így van. A helyettesítő szöveg eltűnik, amikor a felhasználó beír valamit, nem hagy maga után programozási nevet, és így a mező használhatatlanná válik azok számára, akik a folyamat későbbi szakaszában érkeznek ide, vagy hiba után térnek vissza ide.

Minden interaktív vezérlőelemhez látható címke tartozik, amelyet programozással rendelnek hozzá. <label for="email">Email</label><input id="email" type="email"> ez a szabványos elrendezés. A helyőrzők kiegészítő jelzések, nem pedig helyettesítők. Azoknál az elemeknél, ahol a látható címke valóban nem kívánatos (keresőmezők, ikon gombok), használja a aria-label leíró szöveggel – soha nem a helyőrző ismétlésével.

A „nem jelzett vagy nem kapott fókuszt” kifejezés szó szerint több mint 400 panaszbejegyzésben szerepel, és az egész adathalmaz egyik leggyakrabban előforduló mondata. Egy konkrét hibajelenséget ír le: egy modális ablak vagy párbeszédablak jelenik meg az oldalon (gyakran automatikusan – hírlevél-feliratkozás, életkor-ellenőrzés, helymegerősítés), a látható tartalom eltolódik, de a képernyőolvasó nem kap jelzést arról, hogy bármi is megváltozott volna. A fókusz továbbra is az alatta lévő oldalon marad. A felhasználó továbbra is a modális ablak alatt lévő tartalmak között lapozgat, teljesen tudatában annak, hogy megjelenik egy blokkoló párbeszédablak.

Ez egy tipikus példa egy olyan modálra, amely minden szempontból egyszerre bukik meg: nincs role="dialog", nem aria-modal="true", nincs a program fókuszának átállása nyitott állapotban, nincs fókuszcsapda nyitott állapotban, nincs az Esc-gomb megnyomásával történő bezárás, nincs bejelentett cím. Mivel ezek a hibák mind együtt jelentkeznek, bármelyikük önmagában történő kijavítása nem javít a helyzeten.

Használjon bevált párbeszédablak-sablont (a WAI-ARIA Authoring Practices specifikáció szolgál erre referenciaként). Megnyitáskor: helyezze a fókuszt a párbeszédablak első fókuszálható elemére, állítsa be aria-modal="true" és role="dialog", nevezze el a párbeszédablakot aria-labelledby a fejlécére mutatva. Nyitott állapotban: a fókusz a párbeszédablakban maradjon. Bezáráskor: a fókusz térjen vissza az ablakot megnyitó elemre. Az Esc billentyű működését támogassa. Ha a modális ablak megszakítja a folyamatot (pl. az oldal betöltésekor automatikusan elinduló lejátszás), biztosítson a felhasználónak egy egyszerű lehetőséget az ablak végleges bezárására.

A fókuszjelzőket általában szándékosan szüntetik meg azok a fejlesztők vagy tervezők, akik az alapértelmezett böngészőkeretet vizuális zavaró tényezőnek tartják, és *:focus { outline: none; } egy globális stíluslapba. Az oldal így rendezettebbnek tűnik a látó, egeret használó felhasználók számára. A látó, billentyűzetet használó felhasználók – ideértve a legtöbb gyengén látó, mozgáskorlátozott és egeret nem használó felhasználót – számára azonban az oldal használhatatlanná válik. A felhasználó megnyomhatja a Tab gombot, de nem látja, hol tartózkodik.

Ez az egyik olyan ritka hiba, amely segítő technológia nélkül is észrevehető. Egy minőségbiztosítási ellenőr, aki egyetlen eszköz használata nélkül végiglapozza a kezdőlapot, kevesebb mint egy perc alatt észreveszi. Az a tény, hogy az akadálymentesítési csapatok a peres ügyek tárgyát képező webhelyeken rendszeresen rátalálnak erre a hibára, miközben a belső ellenőrzés elmulasztotta észrevenni, az adatállomány egyik legmegbízhatóbb jele annak, hogy a webhely egyáltalán nem felel meg a billentyűzetes tesztelés követelményeinek.

Soha ne tiltsd le általánosan :focus kontúrok pótlás nélkül. Adjon meg egy jól látható kiemelő stílust – általában egy 2–3 képpontos kontúrt, amely megfelelő kontrasztot biztosít mind az elemhez, mind a háttérhez képest – a :focus-visible így a jelző a billentyűzetes navigáció során megjelenik, de egérkattintáskor nem. Ellenőrizze ezt minden interaktív komponensen, beleértve az egyedi widgeteket, a kártyákon belüli linkeket és az olyan elemeket, amelyek tabindex.

A logó a weboldal leggyakrabban megtekintett képe, és egyben az egyik leggyakrabban meghibásodó elem is. Általában egy olyan linkben található, amely visszavezet a kezdőlapra, de a kép nem tartalmaz alt, nem aria-label a linkre, a környező szöveg nélkül. A képernyőolvasó csak a következőket mondja be: „link”, anélkül, hogy tudnánk, hová vezet. Szorozzuk meg a webhely minden oldalával.

Az átfogóbb kategória – az alternatív szöveg nélküli képek – magában foglalja a banner-grafikákat, a termékfotókat, a főoldali illusztrációkat, a közösségi média ikonjait, valamint a tipikus e-kereskedelmi webhelyeken megjelenő hatalmas marketingkép-kínálatot. Az ebben a kategóriában benyújtott panaszok gyakran konkrét képfájlneveket említenek, ami arra utal, hogy a felperes szakértője automatizált ellenőrzést futtatott, amely felsorolta mindazokat a képeket, amelyek alt az attribútum hiányzott vagy üres volt, pedig leíró jellegűnek kellett volna lennie.

A logóknak tartalmazniuk kell egy alternatív szöveget, amely leírja a cég nevét, és ha a logó valahova mutat, akkor a céloldalt is — alt="Acme Co. — homepage". A díszítő képek üres alt attribútumot kapnak (alt=""), amely szándékosan elrejti őket a segítő technológiák elől. Az információs célú képekhez leíró alternatív szöveget kell rendelni. Kerüljék az alternatív szövegek automatikus generálását fájlnevekből vagy AI-alapú feliratozásból emberi ellenőrzés nélkül; a panaszok között többször is felmerülnek olyan esetek, amikor az átfedő eszközök egy vállalati logót „kék-sárga jelként” jelöltek meg.

A képernyőolvasók egy „linkek listája” nézetet jelenítenek meg, amelyet a tapasztalt felhasználók gyakran használnak az oldalak másodpercek alatt történő áttekintésére. Ez a nézet csak a link szövegét jeleníti meg, elválasztva a környező bekezdéstől. Egy olyan oldal, ahol minden blogbejegyzés-előzetes a „Tovább” tizenöt azonos bejegyzésként jelenik meg abban a nézetben. Egy oldal öt üres hivatkozással — <a href="..."></a>, ami gyakran előfordul, ha az ikonok link-címkékben vannak, és nincs szöveges tartalék megoldás — öt üres karaktert jelenít meg.

A hiba kijavításának módja és maga a hiba is közismert, ezért bukkan fel ez a probléma újra és újra a panaszokban – ennek tartós fennállása arra utal, hogy a fejlesztési folyamat során nem alkalmaznak automatizált lintert a linkek szövegének ellenőrzésére, és nem végeznek kézi ellenőrzést képernyőolvasóval sem.

Minden linknek rendelkeznie kell egy olyan elérhető névvel, amely leírja a link célját vagy a vele végrehajtandó műveletet. Cserélje le az általános kifejezéseket leíró jellegűekre — „Tovább” lesz „További információk a harmadik negyedévi eredményekről”. A kizárólag ikonból álló linkek esetében adjon hozzá láthatatlan szöveget vagy egy aria-label. Futtasson automatikus ellenőrzést (axe, Lighthouse stb.) az üres <a> elemek a CI során.

A videók kétféle formában szerepelnek a panaszokban. Az első eset nyilvánvaló: egy marketingvideó, termékbemutató vagy magyarázó videó felirat, átírás vagy bármilyen szöveges alternatíva nélkül kerül közzétételre – így a siket vagy nagyothalló látogatók nem férhetnek hozzá a tartalomhoz. A második eset finomabb: egy fővideó, amely az oldal betöltésekor automatikusan elindul, ami zavarja a képernyőolvasó kimenetét, és megsérti a WCAG 2.2 AA szintjén elvárt szüneteltetési/leállítási vezérlőket (az SC 2.2.2 Szüneteltetés, leállítás, elrejtés mozgó tartalomra és az SC 1.4.2 bármilyen hangra vonatkozóan).

Az adatbázisban szereplő panaszok egy része azt állítja, hogy „a weboldalon található videók feliratozásának hiánya az ADA megsértését jelenti”, és ezt jogi következtetésként fogalmazza meg. Hogy ez a megközelítés helytálló-e, az a joghatóságtól és a körülményektől függ; viszont az a tény, hogy ezek a videók következetesen nem felelnek meg a WCAG 2.2 AA követelményeknek – amely szabványt a legtöbb bíróság és peren kívüli egyezség a meghatározó megfelelési mércének tekinti –, sokkal tartósabb megállapítás.

Minden hanggal ellátott, előre rögzített videóhoz biztosítson szinkronizált feliratot. Készítsen szöveges átiratot is; az átiratok hasznosak azoknak a felhasználóknak, akik hangtompított eszközöket használnak, alacsony sávszélességű környezetben tartózkodnak, valamint az indexeléshez is. Kerülje az automatikus lejátszást; ha tervezési okokból elkerülhetetlen az automatikus lejátszás, biztosítson olyan szüneteltetési/leállítási vezérlőt, amely billentyűzetről azonnal elérhető. A kizárólag videóból álló tartalmak (hang nélkül) esetében biztosítson hangos leírást vagy szöveges alternatívát.

A bejelentkezés az egész hitelesített felhasználói élmény kapuőre. Ha az űrlap meghibásodik, az azt követő összes oldal elérhetetlenné válik, és a panaszok gyakran ezt a láncreakciót egyetlen akadályként kezelik. A minta ugyanaz, mint az E·01-es űrlapcímkézési hiba, gyakran három konkrét alhibával kombinálva: egy „Jelszó megjelenítése” kapcsoló, amely csak ikonként jelenik meg, név és állapotváltozásról szóló bejelentés nélkül; egy CAPTCHA, amely teljesen ellehetetleníti a képernyőolvasó használatát; valamint beágyazott hibák („érvénytelen hitelesítő adatok”), amelyek megjelennek a képernyőn, de nem kerülnek bejelentésre.

A „Jelszó megőrzése” jelölőnégyzet egy további, gyakran előforduló részleges hiba: stílusos <div>, a tényleges <input> Mivel a jelölőnégyzet a képernyőn kívülre van elrejtve, egérrel ugyan működtethető, de billentyűzettel vagy képernyőolvasóval nem. A felhasználónak nincs lehetősége az állandó munkamenet bekapcsolására.

Használjon valódi <input>, <label>, és <button> elemek. A jelszó megjelenítése/elrejtése kapcsolót alakítsuk valódi gombbá, amelynek elérhető neve az állapot változásával frissül ("Show password" / "Hide password") és a változást a következőképpen hirdessük meg: aria-pressed. Biztosítsanak akadálymentes alternatívát a képalapú CAPTCHA-k helyett (hangalapú CAPTCHA, vagy – lehetőleg – cseréljék le a CAPTCHA-t kockázatalapú hitelesítésre vagy a hCaptcha akadálymentes változataira).

A képernyőolvasók három navigációs módban jelenítik meg az oldalt: címsorok, tájékozódási pontok és linkek szerint. Egy olyan oldal, amely nem tartalmaz <h1>, anélkül, hogy <main>, <nav>, és <footer> nevezetességek, és anélkül, hogy lang="en" attribútum a <html> elem egyidejűleg mindhárom navigációs módot eltávolította. A felhasználóknak nincs lehetőségük a tartalom áttekintésére, a tartalomra való ugrásra, és a képernyőolvasó sem tudja betölteni a megfelelő kiejtési modult.

Ez egy szokatlanul súlyos hiba: egyetlen hiányzó tájékozódási pont is panaszok egész sorát vonja maga után, mivel minden olyan képernyőolvasó-navigációs stratégia, amely erre támaszkodik, meghiúsul. Az ebbe a kategóriába tartozó panaszok általában négy-öt konkrét szerkezeti problémát sorolnak fel egyszerre, amelyek bizonyítékként szolgálnak arra, hogy a webhelynek nincs szemantikai alapja.

Minden oldalnak pontosan egy van <h1>, alcímekkel (<h2>, <h3>) logikailag egymásba ágyazva. A régiókat HTML5-ös landmark-elemekbe kell ágyazni: <header>, <nav>, <main>, <aside>, <footer>. Beállítás lang a gyökérkönyvtárban <html> elem. Ellenőrizze egy vázlatellenőrzővel, vagy futtassa document.querySelectorAll('h1').length === 1 a CI-ben végzett füsttesztként

Az akadálymentességi minőségbiztosítás nagy része asztali böngészőkön történik, NVDA vagy JAWS használatával. A mobil segítő technológiák – az iOS-en a VoiceOver, az Androidon a TalkBack – ugyanazon DOM-ot másképp jelenítik meg, gyakran eltérő hibákkal. A panaszokban gyakran használják a „mobile SRU” (mobil képernyőolvasó-felhasználó) rövidítést a mobil nézetre jellemző hibák jelzésére: egy hamburger menü, amely asztali számítógépen az NVDA-val működik, de a VoiceOver alatt nem ad visszajelzést; egy Apple Pay gomb, amely laptopon elérhető, de az oldal iPhone-on megjelenő változatán nem; hibaüzenetek, amelyek asztali számítógépen megjelennek, de mobilon nem.

Az adatok arra utalnak, hogy azokat a vádlottakat, akiknek asztali eszközökön való hozzáférhetősége egyébként kifogástalan, továbbra is mobil eszközökre jellemző problémák miatt perelik be. A mobil eszközökkel való egyenértékűség önmagában is egy ellenőrzési kritérium.

Legalább az iOS Safari VoiceOver és az Android Chrome TalkBack funkcióival tesztelje le ugyanazokat a folyamatokat, amelyeket a számítógépes minőségbiztosítás is lefed. Fordítson különös figyelmet a gesztusalapú interakciókra, a natív fizetési gombokra, valamint az űrlapmezők fókuszba kerülésekor történő bejelentésére. Ha létezik natív alkalmazás, azt is végezze el ugyanazon ellenőrzésen – a panaszok ugyanis gyakran egyazon ügy keretében érintik mind a webes felületet, mind az alkalmazást.

Az akadálymentesítési overlay az egyetlen példa ebben a katalógusban, ahol a hiba egyáltalán nem az alapul szolgáló webhelyen található – hanem éppen azon a javító rétegen, amelyet a hiba kijavítására hoztak létre. Az ebbe a kategóriába tartozó panaszok két különböző problémát írnak le. Az első az, hogy az overlayek valójában nem szüntetik meg az alapul szolgáló akadályokat, így a felhasználó ugyanazokkal a hibásan működő modális ablakokkal, rosszul címkézett űrlapokkal és bejelentés nélküli hibákkal szembesül, függetlenül attól, hogy az overlay jelen van-e vagy sem. A második még élesebb: az átfedések néha új hibákat okoznak azzal, hogy helytelen címkéket adnak hozzá, rosszul alkalmazzák az ARIA szerepeket, vagy zavarják a felhasználó saját segítő technológiai beállításait.

Egy figyelemre méltó részlet: a 2024-ben és 2025-ben benyújtott panaszokban egyre gyakrabban nevezik meg név szerint az overlay-szolgáltatót. Két konkrét panaszrészlet egyértelműen megnevezi a UserWay-t és az AccessiBe-t, és az FTC legutóbbi intézkedései miatt felmerült annak a kockázata, hogy maga az overlay használata is bizonyítékul szolgálhat arra, hogy nem végeztek tényleges javító intézkedéseket – ahelyett, hogy védelmet nyújtana a peres eljárásokkal szemben.

Az átfedő rétegeket tekintsük inkább jelzőként, ne pedig végleges megoldásként. Ha jelenleg ilyen réteg van használatban, dolgozzunk ki egy valódi javítási tervet, amely a probléma gyökerét kezeli, ahelyett, hogy elfedné azt. A bevált módszer a következő elemek kombinációja: a folyamatos integrációba (CI) beépített automatizált ellenőrző eszköz, a WCAG 2.2 AA szabványnak megfelelő emberi ellenőrzés, legalább egy képernyőolvasóval és kizárólag billentyűzetes navigációval végzett kézi tesztelés, valamint a tervezési és fejlesztési folyamatba beépített folyamatos akadálymentességi minőségbiztosítás.