Akadálymentesség és AI: mit lehet rábízni, és mit nem?
Az európai akadálymentesítési irányelv már több mint egy éve alkalmazandó, a hatóságok viszont még nem tartanak ott, hogy ellenőrizni tudjanak, a fejlesztőcsapatok pedig közben egyre nagyobb részben AI-jal íratják a kódot – az AI viszont a mérések szerint éppen az akadálymentességben teljesít a legrosszabbul. Az Ergománia legutóbbi Product Design Talks eseményén először egy akadálymentesítési audit folyamatát követhettük végig, majd három szakértő beszélt arról, hol segít és hol tehet kárt akár a mesterséges intelligencia ebben a munkában.
Az est előadója Rozskova Olga, az Ergománia senior product designere és akadálymentesítési auditora volt. A panelbeszélgetés résztvevői Nagy Árpád, az OTP Bank lead UX designere és akadálymentesítési szakértője, Edelényi Zsolt, a Precognox webakadálymentesítési szakértője és Fábián András, a Graphisoft principal product designere voltak. A beszélgetést Dr. Rung András, az Ergománia alapítója és ügyvezetője moderálta.
Egy éve alkalmazandó, a piac mégis kivár
Olga rövid felvezetéssel kezdte: a 2019-es európai irányelv tavaly júniusban lépett hatályba, a piac pedig jelenleg azzal foglalkozik, hogy minél távolabbra tolja a megfelelést. A hatály viszont már nem korlátozódik a közszférára: néhány kivétellel – a legkisebb, alacsony bevételű cégekkel – gyakorlatilag minden B2C-szolgáltatás beleesik, az e-kereskedelemtől a közlekedésig. A hivatkozási alap a WCAG 2.2, amely kilenc új kritériummal bővült a 2.1-hez képest, és közben már a hármas verzió is készül.

A mostani előadás – az előzővel ellentétben – azonban nem magukról a követelményekről szólt, hanem arról, hogy a mesterséges intelligencia nem vette át a szakértő szerepét, csak a munkafolyamatát gyorsította fel. Olga három érvet hozott erre. Egyrészt több mint ezer szakember írta már alá azt az állásfoglalást, amely elutasítja az egy kattintással akadálymentességet ígérő beépülő widgeteket. Másrészt egy 2025-es kutatás szerint a vizsgált nyelvi modellek egyike sem tudott teljes megfelelést elérni. Harmadrészt az Európai Bizottság maga is megerősítette, hogy egyetlen automatikus eszköz sem fedi le az összes követelményt, és a kézi vizsgálat elkerülhetetlen.
Ahol az AI belép egy auditba
Olga bemutatta a saját auditfolyamatát is, megjelölve, hol emberi a munka, és hol tud besegíteni a nyelvi modell. A folyamat a brief tisztázásával indul, ami kizárólag emberi munka: valóban ez a teljes felhasználói út, amit vizsgálni kell, vannak-e benne harmadik féltől származó megoldások, például egy chat vagy egy foglalási modul? A scope véglegesítése előtt ő maga is végigjárja az oldalakat, mert egy háromlépésesnek tűnő folyamat gyakran jóval nagyobbnak bizonyul, és ettől függ az egész munka időbeosztása.
Maga az audit képernyőolvasós körrel kezdődik. Minden gyanús vagy biztosan hibás elemről képernyőkép készül, és bekerül egy Figma-fájlba, oldalak szerint szétválasztva, sok-sok annotációval. Ezt követi a rotor ellenőrzése – ez az a kisegítő nézet, amelyben a képernyőolvasót használó felhasználó külön listában futhatja végig az oldal linkjeit, címsorait és szakaszait. Itt derül ki, ha a címsorstruktúra összevissza van, vagy ha egymás után hét link szerepel „tovább” felirattal.
Jön a nagyítás, amiből kétféle van, és a kettőnél más-más a fontos: a 200 százalék a szövegről szól – elfér-e, nem csúszik-e egymásra –, a 400 százalék pedig a teljes tartalomról, ahol az a hiba, ha vízszintesen kell görgetni. A folyamat az átadással zárul: prezentáció vagy workshop, ahol designerek, marketingesek, jogászok, termékmenedzserek és fejlesztők ülnek egy asztalnál, és mindegyikükhöz a saját nyelvén kell beszélni.
Az AI két ponton kap nagyobb szerepet. Az egyik a határesetek megbeszélése: ő maga sem tud mindent, a modell viszont nem tud nála többet – egy bizonytalan kérdést könnyebb úgy végiggondolni, hogy közben van kit megkérdezni. A másik a végeredmény strukturálása. A promptja rögzíti a szerepet és a keretet – hogy manuális auditról van szó, automatikus vizsgálat nélkül –, a jogi hátteret, az alkalmazott módszertant, majd a célcsoportokat: a látássérülteken túl a mozgásukban korlátozott felhasználókat, akiknél a kattintható felület mérete a kérdés, a hallássérülteket, akiknél a feliratozás és az átirat, végül a kognitív érintettséget, ahol a visszaszámláló vagy a szövegben lévő kettős tagadás okoz gondot. Az utolsó rész a kimenet formája: egy Figmában szerkeszthető táblázat a képernyőképpel, a problémával, a hivatkozással, a javasolt megoldással és a súlyossággal.
Ahol az AI téved, és ami emberi marad
Olga két példát mutatott arra, amikor a modell mellélőtt. Az egyik a rotor volt: a képernyőolvasó listás nézetéről készült fotóból a modell mást olvasott ki, mint amit ő a saját szemével látott, és rákérdezésre elismerte a hibát. A másikban csak a kontrasztproblémát vette észre, miközben a valódi hiba az volt, hogy a kiválasztott állapotot egyedül a szín jelezte.

Mi az, ami nem delegálható? Az egyik a bizonyítékok összegyűjtése és az annotálás: a modell a folyamatot nem látja, egy statikus képernyőképen nem látszik, ha egy elemre kattintva elmarad a válasz. A másik a döntéshozók meggyőzése: ha az auditor az átadás után eltűnik, az eredmény nem épül be a működésbe. A harmadik a kisegítő technológiával végzett tesztelés, a negyedik pedig a szakmai felelősség: az auditor a saját nevét adja az eredményhez, a modellre utólag nem lehet hivatkozni.
Az előadás második felében Rozskova Olga egy banki ATM-projekt tanulságait foglalta össze. A hangos vezetés a gyakorlatban egy teljesen más logikájú, alternatív felületet jelent, közelebb a telefonos menürendszerekhez, mint egy képernyőhöz – ráadásul úgy, hogy közben összhangban maradjon a látható felülettel. Kiderült az is, hogy a biztonság és az akadálymentesség ütközhet: a hibajelzés akadálymentességi alapelv, egy ATM-nél viszont a hibás PIN-t végigviszi a rendszer a teljes folyamaton, és csak a végén jelez, mert fenyegetett helyzetben ez védi a felhasználót. Az összegzés szerint minden olyan javítás, ami az érintett felhasználóknak készült, mindenki számára jobbá tette a gépet.
Mi változott másfél év alatt
A panelbeszélgetés első kérdése az volt, mi változott azóta, hogy másfél éve egy hasonló beszélgetés zajlott ugyanerről a témáról. Edelényi Zsolt szerint az európai akadálymentesítési törvény hatálybalépése után elkezdett hullámozni a tenger, csak nem itthon. Franciaországban beperelték a Carrefour áruházláncot az akadálymentesség hiánya miatt: a cég a bíróságon azzal védekezett, hogy 71 százalékos megfelelése elegendő, a bíróság azonban ezt nem fogadta el, és kötelezte, hogy fél éven belül teljesen akadálymentesítse a webáruházát. Svédországban nagyon rövid idő alatt több mint száz bejelentés érkezett a hatóságokhoz, Németországban pedig hetven fős intézményt hoztak létre a bejelentések kezelésére. A másik változás maga az AI, amiről szerinte ma már sokkal többet tudunk – és az eddigi mérlege az, hogy több problémát okozott, mint amennyit megoldott.
Nagy Árpád az OTP oldaláról két dolgot említett: a nyilvánosan közzétett akadálymentesítési nyilatkozatot, és azt, hogy az utóbbi évben megsokszorozódtak az ügyfélbejelentések – ami részben jó hír, mert nem hatóságon keresztül, hanem közvetlenül érkeznek. A banknál technológiai váltás zajlik, sokkal több komponensalapú fejlesztéssel, és ezeknek egy része AI-jal készül. A tapasztalat vegyes: ami jó, az jó, ami viszont nem, azt nehéz javítani, mert a modell fekete dobozként működik. Összességében gyorsít, csak közben jóval több iterációt jelent.
Fábián András cégénél más a helyzet. Elmondása szerint a Graphisoftra néhány kivételtől eltekintve nem vonatkozik jogi megfelelési kényszer (az irányelv fogyasztói, B2C termékekre és szolgáltatásokra vonatkozik, egy professzionális tervezőszoftver nem esik ebbe a körbe), így az akadálymentesség náluk sokkal inkább használhatósági és üzleti kérdés. Az elmúlt másfél évben bevezettek két AI-funkciót, amitől a program akadálymentessége se nem javult, se nem romlott. Ami változott: a tervezésben és a fejlesztésben is használnak AI-t, és ebben komoly lehetőséget látnak.
Miért nem mozdul még a hazai piac
Mi áll a hazai csend mögött: a magyar néplélek, a hatóság lanyhasága vagy a kettő együtt? Edelényi Zsolt szerint ez csak késlekedés. A pénzügyi felügyeleti szervek évente egyeztetnek európai szinten, és a felügyeleti ellenőrzés összehangolása már elkezdődött. Ha egy nemzetközi banknál találnak hibát, azt ott vizsgálják ki, ahol a hatóság a leggyorsabban működik.
Nagy Árpád szerint a hatóságok egyelőre nincsenek felkészülve az ellenőrzésre: hiányzik hozzá a szakértelem és az emberi erőforrás. Cégoldalról ez megnyugtatónak tűnhet, hiszen ma a cégek többet tudnak a témáról, mint a hatóság. Egy mobilbank átnézése ráadásul komoly előkészületet kívánna: kell hozzá maga az alkalmazás, kellenek számlák és felhasználói fiókok. A banknál ettől függetlenül arra számítanak, hogy az ellenőrzés előbb-utóbb megérkezik, és készülnek rá. De egyelőre az érintettek sem tudják, hova fordulhatnak: neki magának is hónapokba telt kideríteni, melyik a hazai illetékes hatóság, és amikor felhívta őket, azt a választ kapta, hogy még nem tudnak a feladatról.

Fábián András a saját szektorából hozott egy paradoxont: a legtöbb versenytársuknál sincs nagy mozgás, mert a közbeszerzések kivételével őket sem nyomja a megfelelési kényszer. Miközben a fizikai világ egyre akadálymentesebb, az épített környezetet létrehozó eszközök viszont nem teljesen – ez az inkluzív tervezés felől nézve erős paradoxon.
Edelényi Zsolt ehhez hozzátette, hogy a felkészültség hiánya technológiai kérdés is: egy hatósági ellenőrzésnek objektívnek, kiszámíthatónak és reprodukálhatónak kell lennie, ezt pedig kizárólag kézi teszteléssel nem lehet megoldani. Egy akadálymentességi hiba javítása az éles rendszeren harmincszor annyiba kerül, mint a tervezéskor, a korai javítást pedig szerinte csak az amerikai Deque mérnöki pontosságú automatikus technológiájával lehet megvalósítani – egy közepes méretű szervezet ezzel évente több tízmillió forintot takarít meg. A bevezetése viszont időt, pénzt és szakértőket igényel.
A törvényen túl: mi mozdít meg egy céget
Mi motiválhat egy céget a jogszabályon kívül? Fábián András szerint náluk ez elsősorban jobb terméket jelent. Példaként azt hozta, hogy amikor egy grafikus felületet listás megoldásra cseréltek az Archicadben, nagy felzúdulás lett, mert a billentyűzettel dolgozó felhasználók megszokott fókuszsorrendje eltűnt – akkor még szó sem volt akadálymentességről, csak hatékonyságról. A korlátozottságot sokan egy szűk réteg ügyének tekintik, miközben spektrumról van szó: a felhasználóik között idősebbek is vannak, és egy éjszakán át rajzoló tervező elfáradt szeme vagy keze szintén korlátozottság.
Edelényi Zsolt szerint a mozdulatlanság oka az, hogy a téma egyszerűen még nem jutott el a döntéshozókhoz. Amikor elmondja a megtérülési, márkaépítési és piacnövelési érveket, és mutat egy esettanulmányt, kinyílik a szemük, és a megfelelési kockázatot is megértik – csak épp a legtöbb vezető, akivel beszél, egyikről sem hallott korábban.
Nagy Árpád ugyanezt látja a bankon belül is: vezetőtől vezetőig járva próbálja elmagyarázni a témát, és két dolgon múlik, hogy eljut-e valakihez. Vagy eleve nyitott rá az illető, vagy a jogi kockázaton keresztül érti meg – azt a nyelvet mindenki érti. A vezetők visszatérő kérdése az, hogy hány embert érint mindez: ilyenkor a bank saját becslését mondja el arról, hogy az ügyfélkör mekkora részéről van szó. Igazán nagyot viszont az lendítene a helyzeten, ha lenne egy-két hazai precedens, megbírságolt cég – ilyen eddig nem volt. Fábián András szerint a felső vezetésben élő tévhitet – hogy ez rétegkérdés – éppen az inkluzív tervezés felé nyitva lehet oldani: az Olga előadásában szereplő ATM-es kutatás kapcsán jegyezte meg viccesen, hogy egy ATM előtt állva ő maga is úgy érzi, egyszerre lép fel nála mozgásos, kognitív és látási probléma.
Az AI mint hibaforrás és mint eszköz
A kérdésre, hogy hol hasznos az AI, és hol okoz kárt, Edelényi Zsolt a rossz hírrel kezdte. A WebAIM (amerikai akadálymentesítési nonprofit szervezet) éves felmérése egymillió honlap nyitóoldalát vizsgálja automatikus akadálymentességi teszteléssel, és tavaly először mutatott növekedést a hibák számában. Ez szerinte arra vezethető vissza, hogy a fejlesztők egyre nagyobb részben AI-jal íratják a kódot. A GAAD Alapítvány és a ServiceNow által fejlesztett AIMAC kutatása szerint az AI-modellek 94,59 százaléka hibát generál, amikor HTML-kódot hoz létre, a Microsoft A11y LLM Eval nevű nyílt forráskódú projektjében pedig a tíz vizsgált modellből hat minden automatizált akadálymentességi teszten megbukott. Ezzel szemben a fejlesztési vezetők 88 százaléka meg van győződve arról, hogy az AI által generált kód akadálymentes – ez a szakadék a jelenlegi probléma gyökere. Az ok pedig egyszerű: a nyelvi modelleket nem akadálymentes kódon tanították, és a Microsoft-projekt célja épp az, hogy a nagy modellgyártókat erre rábírja.
Pozitív példaként a már említett Deque axe eszközkészletét hozta: ennek algoritmikus része az akadálymentességi hibáknak jóval több mint a felét megtalálja, egy emberi és AI-támogatású réteg pedig további közel húsz százalékot – így nagyjából a hibák nyolcvan százaléka lefedhető. A kulcs viszont az, hogy ez a rendszer nem sztochasztikus (azaz valószínűségszámításon alapuló, mint például az LLM-ek): megbízható forrásból veszi az adatokat, és nem hallucinál a szabványkérdésekre adott válaszaiban.
Nagy Árpád a napi munkából hozott példát: ha valaki egyszerűen weboldalt kér a modelltől, és nem fogalmazza meg, milyen megfelelést vár, akkor magától nem kap akadálymentes megoldást. Ezért is használják az AI-t akadálymentességi annotációk készítésére, hogy gyorsabban jussanak el a tervek átadásáig – miközben szerinte az igazi megoldás az lenne, ha a komponenseket definiálnák jól, és onnantól azokból építkeznének.

Fábián András a gyártói oldalról három lehetőséget látott. Egy: a fókuszsorrendhez hasonló hibáknál tudják a problémát, de a javítás rengeteg programozói munka, ami egy funkciókra kihegyezett világban az első dolog, amit lefaragnak, mert nehéz dollárra fordítani – AI-jal viszont ez a munka hatékonyabban elvégezhető. Kettő: a guideline-okba, a promptokba és a designrendszerbe be lehet építeni a követelményeket, és ezzel jobb alapállapotból indul a tervezés. Három: egy zárt szoftvernél az automatikus tesztelés elhasal, mert nincs kiolvasható adatszerkezet, csak egy üres vászon – az adat viszont megvan, hiszen a BIM-modell – az épület digitális mása, amelyben minden elem a hozzá tartozó adatokkal együtt szerepel – jól strukturált, szemantikus adat.
Nem az adat a rossz, hanem az interakciós réteg, és éppen ezen segít az MCP, vagyis az a protokoll, amelyen keresztül egy zárt program funkciói és adatai külső ágens számára is olvashatóvá és értelmezhetővé válnak. Szerinte ez pontosan az, amire egy képernyőolvasónak is szüksége lenne: ugyanazzal a fejlesztéssel, amivel egy zászlóshajó-funkciót építenek, inkluzívabbá is tehetik a terméket.
Edelényi Zsolt ehhez azt tette hozzá, hogy meg kell tanulni az AI-t, mert a legtöbb probléma abból ered, hogy nem arra és nem úgy használjuk, amire való. Arra, hogy a jól használt AI megbízható lehet, a Deque online képzési platformjába, a Deque Universitybe épített Axe Assistantet hozta példának: ez száz százalékban megbízható akadálymentességi példákon tanult, és úgy állították be, hogy minden kérdésre megbízható választ adjon.
Ami emberi marad
Mi az, ami öt év múlva sem lesz az AI-é? Fábián András szerint a döntés: annak meghatározása, mi a minőségi kritérium, és több megoldás közül melyik a jó. Adatot és riportot kérhetünk a modelltől, a választást viszont nem.
Nagy Árpád ebben szkeptikusabb volt, mert szerinte hajlamosak vagyunk energiát minimalizálni. Jó brieffel jó megoldás jön ki – de csak akkor, ha a briefet és az eredményt is meg tudjuk ítélni, itt pedig az a kockázat, hogy egyre kevesebbet értünk a részletekből. A kutatás és a riportolás területén viszont nagy lehetőségeket lát. Hozzátette azt is, hogy szerinte a terméken dolgozó csapat létszáma erősen össze fog szűkülni – a designer maga adja majd a promptot a kisebb változtatásokhoz, a fejlesztők pedig a komplexebb feladatokkal foglalkoznak.
Edelényi Zsolt a szoftverfejlesztés felől érvelt: ma a fejlesztő kezében van a végső döntés, de amint megbízhatóan kódoló rendszerek lesznek, az ember kikerül abból a gyárból, ahol a kód készül. Fábián András ehhez a fejlesztőktől hallott aggodalmat tette hozzá: minél jobban kódol egy modell, annál kevésbé átlátható a kód, ez pedig sokkal nagyobb bizalmat követel meg. A kód ránézésre jó minőségűnek tűnik, a hatékonyság kedvéért így egyre több döntést engednek át a modellnek, és a fejlesztők már nem ismerik olyan mélységben a kódot, mint korábban. Saját tapasztalatként elmondta, hogy amikor egyszerre túl sok információt adott be, olyan terveket kapott, amiket már nem tudott átlátni – jónak tűntek, mégis inkább újrakezdte lépésenként. Az AI nem egy személyiség, aki eldönti, hogy ő tervez, mi pedig végrehajtunk.
Nem projekt, hanem kultúra
A zárókörben Edelényi Zsolt a saját cégéből indult ki: a Precognox akadálymentesítés mellett AI-integrációval is foglalkozik, így nála a két terület nem válik külön. Ebből jött az üzenete is: az akadálymentességet be kell építeni az AI-vezérelt fejlesztési folyamatba – ezt mondja házon belül is, és szerinte minél hamarabb lépik meg ezt a cégek, annál jobb helyzetben lesznek.
Nagy Árpád szerint az akadálymentességi tesztelésben és riportolásban lesz a legnagyobb szerepe az AI-nak: a mobilbankból és az internetbankból sűrűn jönnek ki az újabb verziók, egy teljes átvizsgálás viszont tizenkét embernek négy hét munkája – ezzel a tempóval kézi erővel nem lehet lépést tartani. Feszegetni kell tehát a határokat: meg kell nézni, mit lehet rábízni, és utána vissza kell ellenőrizni. A rutinlépéseket nyugodtan rá lehet bízni: azt például megbízhatóan jelzi, ha hiányzik az alt szöveg egy képről, azt viszont nem tudja eldönteni, mi legyen benne, vagy hogy egyáltalán kell-e oda. Hozzátette, hogy az akadálymentesség nem egyszeri projekt: ha egyszer megcsinálják és utána nem tartják fenn, romlani kezd, ezért a céges kultúra részévé kell válnia.
Fábián András a saját döntéshozóinak azt üzente, hogy az MCP és az AI soha nem látott lehetőséget ad arra, hogy gazdaságosan törlesszenek egy komoly adósságból – de attól még nem lesz akadálymentes a termék, csak sokkal hatékonyabban tudják azzá tenni. Hogy miért érdemes belevágni, arra az ő érve az, hogy nem akadálymentes terméket akarnak csinálni, hanem jó terméket – és a jó termék akadálymentes. Ahogy a jó épület, a jó kórház és a jó közlekedés is az. Így nézve ez nem jótékonyság, hanem üzlet és inklúzió: minél több ember tudja használni a terméket, annál jobb a cégnek.
ajánlott
cikkek
Tudj meg többet a témáról
Oszd meg velünk véleményed