Szerepkör-alapú webes akadálymentességi tesztprogram kialakítása

Az akadálymentességi tesztprogram nem egy kiadás előtti szakértői audit, hanem előre kiosztott, visszakövethető bizonyítékok rendszere. Minden változásnál legyen világos, mely ellenőrzések alkalmazandók, mikor érdemes azokat elvégezni, ki hajtja végre és ki fogadja el az eredményt. A mátrix rögzítse a szükséges környezetet, a megőrzendő bizonyítékot, a kiadást blokkoló feltételt, valamint a javítás és az újratesztelés gazdáját. Így nem marad a kiadás végére gazdátlan billentyűzetes útvonal, értelmezhetetlen címke vagy ellenőrizetlen áttördelés.

Mitől lesz program az akadálymentességi tesztelés, nem pedig záró audit?

Attól lesz program, hogy egymástól különböző bizonyítékokat gyűjt a tervezés, a tartalomkészítés, a fejlesztés, a QA és a kiadási előkészítés során, miközben az elfogadás felelőse megnevezett marad. A W3C korai és folyamatos értékelést javasol, mert a feltárt probléma ilyenkor még befolyásolhatja a tervet és a megvalósítást. Az automatizált ellenőrzés ismételhető feltételeket talál; az emberi ellenőrzés a működést és a jelentést vizsgálja; a támogató technológiai teszt kompatibilitási bizonyítékot ad; a fogyatékossággal élő emberek bevonása használhatósági és kielégítetlen igényeket tárhat fel.

A négy bizonyítéktípus nem helyettesíti egymást. Egy hibamentes automatizált futás nem állapítja meg a szabvány teljesülését, mert számos döntéshez hozzáértő emberi megítélés kell. A tervező felel a hozzáférhető interakciós döntésekért, a szerkesztő a jelentést hordozó tartalomért, a fejlesztő a megvalósításért és a helyi ellenőrzésekért, a QA pedig a tervért és a független végrehajtásért. Az akadálymentességi szakértő a szabályzatot, a módszereket, a képzést és a nehéz értelmezéseket gondozza, nem válik minden ellenőrzés alapértelmezett végrehajtójává.

Hogyan igazodjon a tesztmélység a kiadás tartalmához?

A tesztmélység az érintett interakció, újrafelhasználás, újdonság, felhasználói hatás és üzletileg kritikus útvonal alapján növekedjen. A módszerek kiválasztása előtt leltározzuk az érintett feladatokat, komponenseket, sablonokat, tartalomtípusokat, dokumentumokat, médiát, vezérlőket és támogatott technológiákat. Ez a cikk négy, alakítható változási osztályt használ; ezek nem hivatalos kockázati szabványok, nem rögzített pontszámok, és nem adnak alapot arra, hogy egy nem vizsgált útvonalról megfelelőséget állítsunk.

• Csak tartalmi változás: emberi tartalmi felülvizsgálat és alkalmazható automatizált ellenőrzés; szerkezet, média, dokumentum, vezérlő vagy feladatjelentés módosulásakor további kézi teszt.
• Vizuális vagy elrendezési változás: tervezői felülvizsgálat, nagyítási és áttördelési ellenőrzés, interaktív felületnél pedig a fókusz vizsgálata.
• Komponens- vagy interakcióváltozás: előzetes elfogadási feltételek, fejlesztői helyi tesztek, független QA, releváns állapotok és feladatok, újrafelhasználásnál regressziós lefedettség.
• Új sablon, kritikus útvonal vagy nagy kiadás: minden alkalmazható réteg, képzett támogató technológiai teszt, reprezentatív lefedettség, mintavételes megfelelőségi értékelés és időben tervezett felhasználói kutatás.

A kisebb változás sem jelent bizonyíték nélküli kiadást. Egy rövid szövegjavításnál elegendő lehet a szerkesztői ellenőrzés és az alkalmazható automatizálás, de egy hivatkozás céljának, egy dokumentumnak vagy egy hibajelzés jelentésének változása már további vizsgálatot indokolhat. A nagyobb megfelelőségi értékelésnél a WCAG-EM logikája szerint előbb a célt és a hatókört kell rögzíteni, majd feltárni a lényeges nézeteket és funkciókat, indokolt mintát választani, értékelni és jelentést készíteni.

Mi kerüljön a teszttulajdonosi mátrixba, és ki felel az átadásokért?

A mátrix minden során szerepeljen a tesztréteg, a változást kiváltó feltétel és a hatókör, a legkorábbi hasznos szakasz, a végrehajtó és az eredményt elfogadó szerepkör, továbbá a szükséges tudás, környezet, bizonyíték, blokkolási szabály és újratesztelési felelős. Kis csapatban ugyanaz a személy több szerepet is betölthet, de a nyilvántartás nevezze meg, éppen melyik minőségében jár el. Magasabb kockázatnál őrizzünk meg független vagy képzett ellenőrzési pontot az alkotás, az ellenőrzés és a kockázatelfogadás között.

A szerepek határát a létrehozott munka alapján érdemes meghúzni. A tervező a döntéseit, a szerkesztő a címeket, címkéket és más jelentéshordozó tartalmat, a fejlesztő a kódot és a helyi ellenőrzést viszi tovább. A QA állítja össze és függetlenül hajtja végre a tervet, a felhasználói kutató etikusan szervezi a fogyatékossággal élő résztvevőkkel végzett vizsgálatot, az engedéllyel rendelkező termék- vagy kiadási felelős pedig a dokumentált bizonyíték alapján dönt a kiadásról.

Az akadálymentesség akkor szűnik meg másvalaki utolsó ellenőrzésének lenni, amikor minden változáshoz névvel vállalt bizonyíték és újratesztelési út tartozik.

Mit vizsgáljanak ténylegesen az alapvető akadálymentességi ellenőrzések?

Az alapellenőrzések reprezentatív feladatokat és értelmezhető eredményeket vizsgáljanak, ne pusztán eszközfuttatást dokumentáljanak. Az automatizálás keresse a programozottan felismerhető feltételeket a helyi munkafolyamatban és a releváns integrációs csatornában, de a jegyzőkönyv nevezze meg a hatókörét. A tartalmi felülvizsgálat emberi döntés arról, hogy az oldalcím, címsor, címke, hivatkozás, útmutatás, hibaüzenet, felirat, leirat és szöveges alternatíva valóban hasznos jelentést közvetít-e a saját környezetében.

• Billentyűzettel hajtsuk végre a teljes feladatot: működjön minden releváns vezérlő, legyen követhető a fókuszsorrend, maradjon látható és ne legyen teljesen eltakarva a fókusz, lehessen belépni és kilépni az összetett komponensekből.
• Figyeljük a nyitott, zárt, kijelölt, betöltési, sikeres és hibás állapotokat, az üzenetek és fókusz változását, valamint azt, hogy hiba után befejezhető-e a feladat.
• Nagyításnál és áttördelésnél ne a képpontazonosságot keressük, hanem az elvesző vagy takart információt, rejtett fókuszt, képernyőn kívülre kerülő változást, használhatatlan vezérlőt és nem megengedett görgetést.

A WCAG 2,2 szövegméretezési feltételét a megadott kivételekkel 200 százalékos méretnél, tartalom- és funkcióvesztés nélkül kell vizsgálni. Az áttördelés két feltételét ne mossuk össze: a 320 CSS-képpont szélességi egyenértéknél a vízszintes, a 256 CSS-képpont magassági egyenértéknél a függőleges görgetést kell elkerülni, kivéve, ha a kétdimenziós elrendezés a jelentéshez vagy a használathoz szükséges. A jegyzőkönyv rögzítse a beállítást, az érintett nézetet és a tényleges funkcionális hatást.

Mikor szükséges támogató technológiai, fogyatékossággal élő felhasználói és megfelelőségi értékelés?

Magasabb kockázatú változásnál, új interakciónál és kritikus feladatnál képzett támogató technológiai tesztelőre, fogyatékossággal élő résztvevőkkel végzett kutatásra, illetve szélesebb szabványalapú értékelésre lehet szükség. Ezek külön bizonyítékok: a képernyőolvasós teszt kompatibilitást vizsgál, nem szimulálja minden vak ember tapasztalatát és nem bizonyít önmagában megfelelőséget. A fogyatékossággal élő emberekkel végzett értékelés mélyebb használhatósági gondokat tárhat fel, de nem helyettesíti a szabvány szerinti vizsgálatot.

A böngésző, operációs rendszer és támogató technológia aktuális kombinációit a közönségről rendelkezésre álló bizonyíték, a termék technológiája, a vállalt támogatás és az ismert kockázat alapján válasszuk ki, ne más szervezet univerzálisnak vélt listájából. A megállapítás legyen reprodukálható: tartalmazza az érintett feladatot, a felhasználói hatást, az elvárt működést, a böngészőt, az operációs rendszert, a technológiát és verzióját, a bizonyítékot, a javítás gazdáját és az újrateszt eredményét.

A fogyatékossággal élő emberekkel végzett értékelést már prototípusnál vagy a kritikus útvonal kialakításakor tervezzük be, amikor a felismerés még változtathat a munkán. A jelentős, nyilvánvaló akadályokat a foglalkozás előtt célszerű kezelni, hogy az idő mélyebb problémákat is feltárhasson; ez nem jelenti a korai bevonás halasztását. Egy résztvevő tapasztalatából ne következtessünk egy teljes csoportra. A súlyos egyéni akadályt ugyanakkor vizsgáljuk ki, majd kapcsoljuk össze a megállapítást a megfelelőségi bizonyítékkal.

Hogyan szabályozza a bizonyíték a kiadást és a program fejlődését?

A kiadási döntést az adott változási osztályhoz előírt bizonyíték vezérelje, ne egyetlen összesített pontszám. A döntési csomag mutassa meg, hogy minden alkalmazható ellenőrzés elkészült, a blokkoló megállapításokat kijavították és újratesztelték, a fennmaradó tételek pedig rendelkeznek felelőssel és elbírálással. Minden eredményhez tartozzon hatókör, módszer, környezet, megállapítás, tulajdonos és újratesztelési állapot. A QA és az akadálymentességi szakértő biztosítja a független bizonyítékot; az engedélyezett termék- vagy kiadási felelős vállalja az elfogadási döntést.

Ha a szervezet szabályzata kivételt enged, a nyilvántartás nevezze meg az engedélyezett tulajdonost, az indoklást, az érintett felhasználókat, az átmeneti enyhítést, a lejáratot és a következő intézkedést. A kivétel nem módosítja az alapul szolgáló teszteredményt, és nem hoz létre megfelelőséget. A pontos blokkolási szabályt minden szervezetnek saját felhatalmazási és kockázati rendjében kell meghatároznia; a modell ezért nem ír elő univerzális súlyossági pontszámot, gyakoriságot vagy felmentési jogosultat.

1. Válasszunk ki egy kritikus felhasználói útvonalat, és készítsük teljessé annak teszt- és döntési nyomvonalát.
2. Nevezzük meg és képezzük ki a szerepkörök gazdáit, majd adjunk nekik egységes bizonyíték- és hibajegysablonokat.
3. Építsük be a megfelelő automatizálást, és valódi eredmények alapján kalibráljuk a blokkolási és újratesztelési szabályokat.
4. A visszatérő hibákat vezessük vissza a komponensekbe, sablonokba, képzésbe, regressziós ellenőrzésekbe és változási osztályokba.
5. Csak a pilot tanulságai után bővítsük a lefedettséget további útvonalakra, termékekre és csapatokra.

A kiadás utáni akadálybejelentés nem külön csatorna végpontja, hanem bemenet a következő fejlesztési körhöz. A program akkor javul, ha az ismétlődő hibaminták módosítják a mátrixot, a sablonokat, a képzést és a regressziós készletet. Összetett interakció, vitatott megállapítás, támogató technológiai működés vagy reprezentatív megfelelőségi lefedettség esetén vonjunk be képzett értékelőt; felhasználói vizsgálathoz tapasztalt kutatót, joghatósághoz kötött megfelelőségi értelmezéshez pedig megfelelően képzett jogi szakértőt.