Miért hagyja ki az automatizált akadálymentességi tesztelés a problémák felét?

A kényelmetlen igazság az automatizált akadálymentességi tesztelésről

Az automatizált akadálymentességi tesztelés az egyik legjobb szokás, amelyet egy webes csapat kialakíthat. Megtalálja a hiányzó űrlapcímkéket, az alacsony kontrasztú szöveget, az érvénytelen ARIA-t, a duplikált ID-kat, az üres gombokat és más olyan hibákat, amelyeknek soha nem kellene éles környezetbe kerülniük.

Ugyanakkor rendszeresen félreértik.

Egy sikeres automatizált akadálymentességi jelentés nem jelenti azt, hogy az oldal akadálymentes. Azt jelenti, hogy az eszköz nem talált problémát abban a részhalmazban, amelyet képes felismerni. Ez a részhalmaz értékes, de korlátozott. Sok akadálymentességi hiba a jelentéstől, a sorrendtől, a szándéktól, a kontextustól és az emberi interakciótól függ. A szoftver képes megvizsgálni a jelölést. Azt azonban nem tudja megbízhatóan megérteni, hogy az élmény működik-e egy képernyőolvasót, billentyűzetet, nagyítást, hangvezérlést, feliratokat vagy kognitív támogatást használó személy számára.

Ezért nem cinikus az az állítás, hogy az automatizált tesztelés a problémák nagyjából felét kihagyja. Inkább nagyvonalú. Egyes problémakategóriák nagyon jól automatizálhatók. Mások alig automatizálhatók egyáltalán.

A gyakorlati válasz nem az, hogy elhagyjuk az automatizált eszközöket. Hanem az, hogy a megfelelő helyre tegyük őket: korán, gyakran és egy tágabb tesztelési munkafolyamat részeként.

Mire jók az automatizált tesztek

Az automatizált eszközök kiválóan megtalálják a determinisztikus hibákat. Ha egy szabály gépileg olvasható feltételként megfogalmazható, egy szkenner általában gyorsan és következetesen ellenőrizni tudja.

Gyakori példák:

• Hiányzó alt attribútummal rendelkező képek
• Társított címke nélküli űrlapmezők
• Akadálymentes név nélküli gombok
• Kontrasztküszöböt el nem érő szöveg
• Érvénytelen ARIA-attribútumok vagy szerepek
• Gyanús módon kihagyó címsorszintek
• Hiányzó vagy duplikált landmarkok
• Üres akadálymentes névvel rendelkező hivatkozások
• Alapvető struktúra nélküli táblázatok

Ezeket az ellenőrzéseket érdemes automatizálni, mert az emberek rosszak az ismétlődő vizsgálatokban. Senkinek sem kellene kézzel átnéznie minden oldalt hiányzó címkék után, ha egy eszköz ezredmásodpercek alatt megtalálja őket.

Az automatizált ellenőrzések az akadálymentességről szóló beszélgetést is könnyebbé teszik a mérnöki munkafolyamatokban. Egy sikertelen teszt a CI-ben konkrét. Egy figyelmeztetés egy pull requestben időszerű. A sablonokon átívelő trendvonal ad valamit a csapatnak, amin javíthat.

A probléma akkor kezdődik, amikor a csapatok ezeket az ellenőrzéseket az akadálymentesség bizonyítékának tekintik, nem pedig az alapvető rend bizonyítékának.

Hol omlik össze az automatizálás

Az akadálymentesség nem csak a kód tulajdonsága. A használaté is.

Egy eszköz meg tudja mondani, hogy egy képnek van-e alt szövege. Azt általában nem tudja megmondani, hogy az alt szöveg hasznos-e. Egy termékről készült képnek szüksége lehet részletes leírásra egy termékoldalon, semmilyen leírásra egy dekoratív hero szekcióban, és teljesen más leírásra egy súgócikkben. A helyes válasz a kontextustól függ. Ezért van szükségük a csapatoknak olyan szerkesztői iránymutatásra, mint egy pragmatikus megközelítés a képek alt szövegéhez, nem csak egy linter szabályra.

Ugyanez a probléma mindenhol megjelenik.

Egy szkenner megerősítheti, hogy minden gombnak van akadálymentes neve. Azt nem mindig tudja megmondani, hogy a név értelmes-e. Egy öt Küldés nevű gombot tartalmazó oldal átmehet egy alapszabályon, mégis kifejezetten kellemetlen lehet a képernyőolvasót használók számára. Egy modálnak lehetnek megfelelő ARIA-attribútumai, de helytelenül tarthatja csapdában a fókuszt. Egy egyedi legördülő menü megfelelhet statikus jelölésben, és abban a pillanatban elbukhat, amikor valaki billentyűzettel próbálja használni.

Az automatizálás nehezen birkózik meg az ilyen kérdésekkel:

• A fókuszsorrend megfelel a vizuális és logikai sorrendnek?
• Minden feladat elvégezhető kizárólag billentyűzettel?
• A hibaüzenetek konkrétak, időszerűek és a mezőkhöz vannak társítva?
• Az oldal továbbra is működik, ha a szöveget átméretezik vagy nagyítják?
• Az olvasási sorrend értelmes az asszisztív technológiák számára?
• Az utasítások érthetők színre vagy pozícióra támaszkodás nélkül?
• A feliratok, átiratok és címkék valóban közvetítik a tartalmat?
• Egy komponens kiszámíthatóan viselkedik a különböző állapotokban?

Ezek nem peremesetek. Az akadálymentesség központi részei.

A magas pontszám hamis megnyugvása

Az akadálymentességi pontszámok csábítóak, mert egy rendetlen témát egyetlen számmá sűrítenek. Egy dashboard 98-at mutat. Egy jelentés zöld pipákat jelez. A kiadás biztonságosabbnak érződik.

De a pontszám csak azt méri, amit az eszköz mér.

Ez hasonló a teljesítményteszteléshez. Egy Lighthouse-jelentés fontos problémákat tárhat fel, de nem ugyanaz, mint látni, ahogy egy valódi felhasználó egy középkategóriás telefonon küzd végig egy lassú fizetési folyamaton. Ha a csapatod már használ teljesítményauditokat, ugyanaz a gondolkodásmód érvényes: olvasd el figyelmesen a jelentést, majd priorizáld azokat a megállapításokat, amelyek valódi felhasználókat érintenek. Erről a különbségről írtunk a hogyan olvassunk Lighthouse-jelentést pánik nélkül című cikkben.

Az akadálymentességi jelentések ugyanilyen önmérsékletet igényelnek. Egy tiszta automatizált szkennelés kiindulópont. Nem tanúsítvány.

A kockázat különösen nagy, amikor a csapatok csak statikus oldalakon futtatnak szkenneléseket. A modern felületek állapottal rendelkeznek: menük nyílnak meg, fiókok csúsznak be, toast üzenetek jelennek meg, validációs üzenetek frissülnek, fülek váltanak panelek között, szűrők írják át a tartalmat, és a hitelesítés mindent megváltoztat. Sok súlyos akadálymentességi hiba ezekben az interakciókban él.

Ha a szkennered csak a kezdeti DOM-ot látja, akkor nem látja a terméket.

A leggyakrabban kihagyott kategóriák

1. Billentyűzet- és fókuszviselkedés

A billentyűzetes hozzáférés az egyik legtisztább példája annak, miért nem elegendő az automatizálás.

Egy eszköz felismerheti, hogy egy elem fókuszálható-e. Elkaphat pozitív tabindex értékeket vagy nyilvánvaló fókuszcsapdákat. Azt azonban nem tudja megbízhatóan megítélni, hogy a tabsorrend koherensnek érződik-e, hogy a fókusz egy művelet után a megfelelő helyre kerül-e, vagy hogy egy elvetett komponens visszaadja-e a fókuszt a kiváltó elemnek.

Emberre van szükség, aki végignyomja a Tab, Shift+Tab, Enter, Space, Escape és nyílbillentyűket a tényleges munkafolyamaton.

Ez különösen fontos az egyedi vezérlőknél. A natív HTML-elemek éveken át finomított akadálymentességi viselkedést adnak ingyen. Ha gombokat, selecteket, jelölőnégyzeteket, menüket és párbeszédablakokat div-ekkel építetek újra, akkor a csapatotok mostantól birtokolja ezt a viselkedést. Ha interaktív komponenseket vizsgáltok, kezdjétek egy rövid ellenőrzőlistával az akadálymentes webes gombokhoz, és ugyanezt a fegyelmet terjesszétek ki minden egyedi vezérlőre.

2. Jelentéssel bíró nevek és leírások

Az automatizált eszközök felismerik a hiányt. A minőség felismerésében sokkal gyengébbek.

Egy Tovább nevű hivatkozásnak technikailag lehet akadálymentes neve. Egy OK feliratú gomb lehet érvényes. Egy űrlapsúgó jelen lehet. De vajon ezek kontextusban értelmesek? Gyakran nem.

Az akadálymentes neveknek meg kell mondaniuk a felhasználóknak, mi fog történni, vagy mit képvisel az elem. Ehhez ítélőképesség kell. És a felülettel végzett tesztelés is, nem csak a kód vizsgálata.

3. Hibakezelés

Az űrlapok tele vannak olyan akadálymentességi hibákkal, amelyeket a szkennerek csak részben kapnak el.

Egy eszköz jelezhet egy címke nélküli mezőt. Lehet, hogy nem veszi észre, hogy a validációs üzenet túl későn jelenik meg, túl gyorsan eltűnik, a képernyőolvasók nem jelentik be, vagy azt mondja, hogy Érvénytelen bevitel, miközben azt kellene mondania, hogy A jelszónak legalább 12 karakter hosszúnak kell lennie.

A jó hibakezelés interakciótervezés. Kézi tesztelést igényel, és ideális esetben felhasználói tesztelést is.

4. Vizuális alkalmazkodás

A WCAG követelményeket tartalmaz a szöveg átméretezésére, az újratördelésre, a kontrasztra, a térközökre és arra, hogy ne támaszkodjunk egyetlen érzékszervi jelzésre. Ennek egy része automatikusan ellenőrizhető, de a valódi kérdés az, hogy a felület használható marad-e megváltozott feltételek mellett.

Próbáld ki a 200%-os nagyítást. Próbáld ki a böngésző szövegátméretezését. Próbáld ki a nagy kontrasztot vagy a kényszerített színek módját. Próbáld ki a keskeny viewport-szélességeket. Próbáld ki a csökkentett mozgást. Sok alapértelmezett beállítások mellett csiszoltnak tűnő webhely gyorsan szétesik, amikor a felhasználók érvényesítik a preferenciáikat.

5. Tartalmi érthetőség

Egyetlen automatizált akadálymentességi eszköz sem tudja teljes körűen felmérni, hogy a tartalom érthető-e.

Jelezhet hiányzó címsorokat vagy homályos hivatkozásszöveget. Nem tudhatja, hogy az oldal világosan magyaráz-e el egy folyamatot, hogy a címkék megfelelnek-e a felhasználói elvárásoknak, vagy hogy a sűrű szöveg elkerülhető kognitív terhelést okoz-e.

Az akadálymentesség nem csak az asszisztív technológiákkal való kompatibilitásról szól. Arról is, hogy csökkentsük a súrlódást azoknak, akik stressz alatt vannak, ismeretlen nyelvet használnak, figyelmi korlátokkal küzdenek, vagy összetett feladatokban navigálnak.

Jobb tesztelési munkafolyamat

A kiegyensúlyozott akadálymentességi munkafolyamat rétegekből áll.

Futtass automatizált ellenőrzéseket folyamatosan

Használj automatizált teszteket fejlesztés közben, pull requestekben, komponens-előnézetekben és CI-ben. Legyenek unalmasak, gyorsak és nem tárgyalhatók. Az új hiányzó címkék és érvénytelen ARIA miatt ne kelljen negyedéves auditot várni.

Kezeld ezeket a hibákat úgy, mint a linting hibákat. A cél nem a hősiesség, hanem a regressziók megelőzése.

Adj hozzá kézi billentyűzetes tesztelést

Minden érdemi felhasználói folyamatot tesztelj egér nélkül. Ide tartozik a navigáció, a keresés, a fióklétrehozás, a fizetés, a szűrés, a modálok, a menük és az űrlapküldés.

Minimum ellenőrizd:

• Minden interaktív elem elérhető
• A fókusz mindig látható
• A fókuszsorrend logikus
• A várt billentyűk működnek
• Az Escape bezárja a bezárható overlayeket
• A fókusz kezelve van a komponensek megnyitása és bezárása után
• Nincs billentyűzetcsapda

Ez az egyetlen szokás az automatizált szkennelések által kihagyott problémák nagy csoportját kapja el.

Tesztelj legalább egy képernyőolvasóval

Nem kell szakértő képernyőolvasó-felhasználóvá válnod ahhoz, hogy hasznos dolgokat tanulj. Alázatra viszont szükség van. A képernyőolvasós tesztelésnek van tanulási görbéje, és a kezdők félrediagnosztizálhatják a problémákat.

Ennek ellenére az alapvető tesztelés VoiceOverrel, NVDA-val vagy JAWS-zal feltárhat hibás neveket, zavaros olvasási sorrendet, be nem jelentett frissítéseket és landmark-problémákat, amelyeket egy szkenner nem biztos, hogy elkap.

Párosítsd ezt szemantikus HTML-lel. Minél több natív elemet használsz, annál kevésbé lesz törékeny az akadálymentesség.

Tekintsd át a tartalmat és az állapotokat

Ellenőrizd az üres állapotokat, betöltési állapotokat, hibaállapotokat, letiltott állapotokat, sikerüzeneteket és jogosultsági hibákat. Az akadálymentességi hibák gyakran a boldog útvonalon kívül rejtőznek.

Tekintsd át a tényleges szavakat is. A címkék, címsorok, utasítások és hibaüzenetek a felület részei.

Vond be a fogyatékossággal élő felhasználókat, ha nagy a tét

Kritikus folyamatoknál a kézi szakértői felülvizsgálat nem elég. A fogyatékossággal élő résztvevőkkel végzett felhasználói tesztelés olyan problémákat talál meg, amelyeket a csapatok nem látnak előre. Ez különösen fontos közszolgáltatások, egészségügy, pénzügy, oktatás és minden olyan folyamat esetében, ahol a kizárásnak súlyos következményei vannak.

Az automatizált tesztelés skálázódik. Az emberi tesztelés megérti.

Hogyan értelmezzük felelősen az automatizált eredményeket

Ne azt kérdezd: Átmentünk?

Tegyél fel jobb kérdéseket:

• Milyen problémakategóriákat tud ez az eszköz felismerni?
• Mely sablonokat és állapotokat szkennelte?
• Interakciók után is futott, vagy csak a kezdeti betöltéskor?
• A szabálysértések gyökérok szerint vannak csoportosítva, vagy ismételten vannak megszámolva?
• Mely hibák akadályozzák a felhasználókat a feladatok elvégzésében?
• Mi igényel még kézi felülvizsgálatot?

Ez a keretezés megváltoztatja a beszélgetést. Az automatizált eszközök bizonyítékká válnak, nem tekintéllyé.

A csapatoknak abban is segít, hogy elkerüljék a látszatmunkát. Egyetlen komponens javítása több száz ismétlődő szabálysértést tüntethet el. Ezzel szemben egy olyan oldal, amelyen csak egy jelentett probléma van, továbbra is tartalmazhat súlyos billentyűzetcsapdát. A darabszám nem hatás.

A gyakorlati mérce: automatizáld a nyilvánvalót, teszteld kézzel az élményt

A legjobb akadálymentességi csapatok nem eszközellenesek. Illúzióellenesek.

Automatizálják azt, amit a gépek megbízhatóan felismernek. Kézzel tesztelik azt, ami viselkedéstől és jelentéstől függ. A WCAG-hoz hasonló szabványokat közös alapként használják, nem a termék használatának helyettesítőjeként.

Ha a jelenlegi folyamatod csak egy automatizált szkennelés a bevezetés előtt, ebben a sorrendben javíts rajta:

1. Adj hozzá automatizált ellenőrzéseket korábban a fejlesztés során.
2. Teszteld kézzel, billentyűzettel az alapvető folyamatokat.
3. Tekintsd át a neveket, címkéket, hibákat és utasításokat.
4. Teszteld a gyakori komponenseket képernyőolvasóval.
5. Nagy kockázatú felhasználói utaknál vonj be szakértői és felhasználói tesztelést.

Ez nem tökéletes folyamat. Reális folyamat. És sokkal többet fog megtalálni, mint amennyit egy zöld akadálymentességi pontszám valaha is tudna.