Olvasom, hogy a miskolci önkormányzat oldala teljesen akadálymentes lett: link
Szerintetek lehet olyan automatizált teszteket írni, amik megmondják, hogy egy oldal mennyire akadálymentes?
Gondolom e2e tesztekre van szükség, de érdekes, hogy azon felül vajon még mire? Lehet, hogy egy felolvasót össze kellene kötni az e2e teszt engine-jével valahogy? Egyelőre Chrome-ban csináltam olyan engine-t, ami megnyitja Karma-val az adott böngészőt, és az egész folyamat javascripttel megy le. Nem tudom meddig engedi ezt a Chrome, mert cross-origin & cross-frame communication kell ablakok között, de egyelőre még megvan. Gondolom ebbe kellene bekötni valahogy egy felolvasó programot, vagy valami olyasmit, ami hasonló elven butítja le az egészet, tehát a DOM-ot átkonvertálja valamivé, amit egy vak hallana, és az alapján dönt a navigációról. Gondolom ez Seleniummal is ugyanúgy működhet. Vajon létezik ilyen projekt?
Szia, ha majd lesz fejlemény leírod? A téma iránt többször is érdeklődtem, de aztán valahogy mindig megálltam, mert nem tudtam megítélni, hogy a megoldásaim mennyire valós problémát oldanak meg...
Én az utóbbi kb. 1 évben leginkább csak akadálymentesítéssel foglalkozok egy projekt kapcsán, de igazából jó automata eszközt nem igazán találtam még erre. Amiket használni szoktam:
JAWS
NVDA
axe böngésző plugin
pa11y
Egyébként ezek az eszközök elég sok hibát találnak a fenti oldallal kapcsolatban, és egy részük elég súlyos.
Axe-ról én is olvastam, legtöbben azt használják szerintem. Tudnál egy kicsit többet írni arról, hogy milyen koncepciók mentén lehet elindulni a témában, esetleg hogy látod az esélyét az ellenőrzés legalább részleges automatizálásának?
Amiben én gondolkodtam, hogy külön GUI vagy E2E teszteket írok az akadálymentes használatra, de nem teljesen világos, hogy miben vagy hogyan más egy böngészés egy felolvasó programmal, és hogy vajon normál böngészőben emulálni lehet e azt a környezetet. Arra gondoltam, hogy a DOM-ot át lehetne konvertálni valamire, amit a felolvasó program lát, aztán a kimenetre lehetne alkalmazni olyan szabályokat, mint hogy ne olvasson fel egy tucatnál több menüpontot egyszerre, stb. Szerinted ilyen módon el lehet indulni, vagy túl naív gondolat?
Én nagyon rég foglalkoztam a témával, így az ismereteim nem naprakészek. Annak idején a nulladik tanács az volt, hogy el kell olvasni Mark Pilgrim - Dive Into Accessibility című ingyenes e-könyvét. Mert az ellenőrző programok csak a végeredményt kritizálják, de az odafigyelés már a tervezéstől kell kezdődjön.
Ami a miskolc.hu oldalt illeti, ha kikapcsolod a CSS-t (esetleg Lynx-el látogatod meg), akkor egyből feltűnik, hogy minden lap tetején ugyanaz a ~100 hivatkozásnyi menü áll. Ha egy program DOM sorrendben felolvassa a tartalmat, akkor szerencsétlen vak minden lap elején végig kell hallgassa, mielőtt a tartalomhoz érnek.
Találomra az Álláslehetőség lapra léptem be. Ott a látó ilyen tartalommal találkozik:
Állás 2019. április 01.
Pályázati kiírás társadalmi felzárkóztatási ügyintéző munkakör betöltésére
Állás 2019. március 20. • Hamarosan lejár
Pályázati kiírás belső ellenőr munkakör betöltésére
Állás 2019. január 17. • Lejárt
Pályázati kiírás építéshatósági ügyintéző munkakör betöltésére
Most kapcsoljuk ki a CSS-t és lássuk mit olvashatna fel onnan egy program a vaknak:
Állás 2019. április 01. • Friss • Hamarosan lejár • Lejárt
Pályázati kiírás társadalmi felzárkóztatási ügyintéző munkakör betöltésére
Állás 2019. március 20. • Friss • Hamarosan lejár • Lejárt
Pályázati kiírás belső ellenőr munkakör betöltésére
Állás 2019. január 17. • Friss • Hamarosan lejár • Lejárt
Pályázati kiírás építéshatósági ügyintéző munkakör betöltésére
Vagyis így már az összes egyszerre „Friss”, „Hamarosan lejár” és „Lejárt”.
A szerény véleményem megírásával inkább nem vesződőm, mert még a saját moderálásomat sem élné túl.
Ez „az ismereteim nem naprakészek” alá tartozik. Annak idején mérvadónak számított az oldal Lynx-el való használhatósága, mert képességeiben közel állt a felolvasó programokhoz.
Bármi amit elérsz a témában engem is érdekelne, sajnos segíteni nem tudok különösebben.
Szerintem lehet rá tesztet írni, de kérdéses, hogy mennyivel éri meg jobban / gyorsabb, mint hús-vér nem látó userrel teszteltetni.
Ugyanakkor ha már van ilyen teszt, akkor nyilván lényegesen gyorsabb, odáig eljutni viszont nem egyszerű.
Ha eljutsz valameddig, szerintem érdemes összehasonlítani az emberi teszteléssel is, hogy le tudd mérni, mennyire jó az automata teszt. Ha az segítség, valószínűleg tudok nem látó számítógép-használókhoz kapcsolatot.
Nem prioritás most, csak érdekel. Olvasgatok majd. Ha találok valami érdekeset, akkor szólok. Az érdekel, hogy a hús vér ember mit csinál, és mi az, ami gondot okoz neki. Pl ilyen lehet, ha 20 menüponton át kell rágnia magát minden oldal betöltéskor mire eljut a tartalomig. Jó eséllyel automatizálható az ilyen hibák, vagy inkább kellemetlenségek kiszűrése, de ahhoz ismerni kell a szabályrendszert. Arra gondoltam első körben, hogy konvertálom a weboldalt pl markdown-ra vagy valami hasonló egyszerűbb formátumra, ami kb. azt tükrözi, hogy egy felolvasó programmal mi az, ami érzékelhető. Utána erre lehet írni egyedi tesztet vagy általános ellenőrzést. De egyelőre megnézem a már meglévő eszközöket. Gondolom azért jóval többet agyaltak ennél a fejlesztésükkor.
Nagyon úgy tűnik, hogy ez meghaladja most a kapacitásomat. Nem csak arról van szó, hogy valaki vak, hanem van egy csomó másféle korlátozottság, amire tesztelni kellene. link Valaki pl nem teljesen vak, csak homályosan lát, és felolvasó program helyett neki jobb, ha kontrasztosabb a szöveg. Van olyan is, akinek olvasási nehézségei vannak, és szimbólumokkal jobban tud tájékozódni, meg olyan is, aki nem tud mozogni, vagy nincs keze, stb. Mindegyiknek mások az igényei, és sokkal szélesebb ez a témakör, mint elsőre gondoltam. Nézegetek Pa11y tutorialokat, szerintem kezdésnek maradok annál, aztán majd ha több időm lesz rá, akkor foglalkozok behatóbban is a témával.
Igen, elég sokféle lehet az akadályoztatás, mondjuk mindegyikre szerintem nem fogsz tudni automata tesztet írni, hiszen bármikor adódhat egy újabb felhasználó, akiről nem is gondolnánk, hogy használ számítógépet...
Persze a másik oldalon az is ott van, hogy pl aki a kezét nem tudja (számítógépkezelésre) használni, valószínűleg rendszer szinten használ valami beszédfelismerőt.
Ugyanakkor van egy barátom, akinek emellett a beszéd is gond, ő egy fejpánttal rögzített pálcával használ számítógépet. Ha gondolod, privátban összehozlak vele, jó srác. ;)
Lehet, hogy már futólag találkoztam vele. Volt valaki, aki java-t akart tanulni, és megpróbáltak összehozni vele online. Jól lecsesztem, hogy egy hét után se válaszolt a leveleimre, és nem is túl motivált, aztán kiderült, hogy aki összehozott vele az elfelejtette említeni azt az apróságot, hogy nem tudja használni se a kezét, se a lábát, és a fején van valami, amivel érintkezik a géppel. Elég gáz szitu volt, meg is sértődött szegény.
Én is úgy gondolom, hogy az axe, pa11y és hasonló teljesen automata rendszerek nem elegek. Szerintem ugyanúgy e2e teszteket kéne írni egy-egy feature-re, mint ahogy a látóknak csinálod úgy, hogy figyelembe veszed náluk a korlátozottságból adódó eltéréseket, tehát nem veszed alapvetőnek azt, hogy ami benne van a DOM-ban, azt ténylegesen érzékeli az illető. És ha mondjuk 10-es a betűméret egy gyengén látónál vagy alacsony a kontraszt, akkor a teszt elhasal a11y hibával, mert nem tudja elolvasni. Ezt részben bele lehet építeni e2e tesztekbe is, de nem vagyok benne biztos, hogy teljes egészében le lehet fedni mindent olyan tesztek nélkül, amik erre specifikusak. Idén már nem hiszem, hogy lesz időm mélyebben beleásni magam a témába, annyi mindent kell befejeznem mielőtt újraindulok a vállalkozással, de hosszú távon jótékonyságból szívesen foglalkoznék vele a szabadidőmben, hátha tudok valamit javítani ezeknek az embereknek a helyzetén.
Ha az oldalon végig tudsz navigálni csak billentyűzettel, akkor a legtöbb dolgot egy korlátozással élő és el tudja majd érni. Betűméretet minden böngészőben lehet állítani, így az kisebb mértékben korlátoz.
Gondolom e2e tesztekre van
Úgy nézem a fogalom
+1
Megpróbálhatom, de szerintem
Tesztelés
Egyébként ezek az eszközök elég sok hibát találnak a fenti oldallal kapcsolatban, és egy részük elég súlyos.
Tudnál egy kicsit többet írni
Amiben én gondolkodtam, hogy külön GUI vagy E2E teszteket írok az akadálymentes használatra, de nem teljesen világos, hogy miben vagy hogyan más egy böngészés egy felolvasó programmal, és hogy vajon normál böngészőben emulálni lehet e azt a környezetet. Arra gondoltam, hogy a DOM-ot át lehetne konvertálni valamire, amit a felolvasó program lát, aztán a kimenetre lehetne alkalmazni olyan szabályokat, mint hogy ne olvasson fel egy tucatnál több menüpontot egyszerre, stb. Szerinted ilyen módon el lehet indulni, vagy túl naív gondolat?
Én nagyon rég foglalkoztam a
Ami a miskolc.hu oldalt illeti, ha kikapcsolod a CSS-t (esetleg Lynx-el látogatod meg), akkor egyből feltűnik, hogy minden lap tetején ugyanaz a ~100 hivatkozásnyi menü áll. Ha egy program DOM sorrendben felolvassa a tartalmat, akkor szerencsétlen vak minden lap elején végig kell hallgassa, mielőtt a tartalomhoz érnek.
Találomra az Álláslehetőség lapra léptem be. Ott a látó ilyen tartalommal találkozik:
Pályázati kiírás társadalmi felzárkóztatási ügyintéző munkakör betöltésére
Állás 2019. március 20. • Hamarosan lejár
Pályázati kiírás belső ellenőr munkakör betöltésére
Állás 2019. január 17. • Lejárt
Pályázati kiírás építéshatósági ügyintéző munkakör betöltésére
Most kapcsoljuk ki a CSS-t és lássuk mit olvashatna fel onnan egy program a vaknak:
Pályázati kiírás társadalmi felzárkóztatási ügyintéző munkakör betöltésére
Állás 2019. március 20. • Friss • Hamarosan lejár • Lejárt
Pályázati kiírás belső ellenőr munkakör betöltésére
Állás 2019. január 17. • Friss • Hamarosan lejár • Lejárt
Pályázati kiírás építéshatósági ügyintéző munkakör betöltésére
Vagyis így már az összes egyszerre „Friss”, „Hamarosan lejár” és „Lejárt”.
A szerény véleményem megírásával inkább nem vesződőm, mert még a saját moderálásomat sem élné túl.
CSS
Ez „az ismereteim nem
+1 szintén
Szerintem lehet rá tesztet írni, de kérdéses, hogy mennyivel éri meg jobban / gyorsabb, mint hús-vér nem látó userrel teszteltetni.
Ugyanakkor ha már van ilyen teszt, akkor nyilván lényegesen gyorsabb, odáig eljutni viszont nem egyszerű.
Ha eljutsz valameddig, szerintem érdemes összehasonlítani az emberi teszteléssel is, hogy le tudd mérni, mennyire jó az automata teszt. Ha az segítség, valószínűleg tudok nem látó számítógép-használókhoz kapcsolatot.
Nem prioritás most, csak
Nagyon úgy tűnik, hogy ez
+1 ismét
Persze a másik oldalon az is ott van, hogy pl aki a kezét nem tudja (számítógépkezelésre) használni, valószínűleg rendszer szinten használ valami beszédfelismerőt.
Ugyanakkor van egy barátom, akinek emellett a beszéd is gond, ő egy fejpánttal rögzített pálcával használ számítógépet. Ha gondolod, privátban összehozlak vele, jó srác. ;)
Lehet, hogy már futólag
Én is úgy gondolom, hogy az axe, pa11y és hasonló teljesen automata rendszerek nem elegek. Szerintem ugyanúgy e2e teszteket kéne írni egy-egy feature-re, mint ahogy a látóknak csinálod úgy, hogy figyelembe veszed náluk a korlátozottságból adódó eltéréseket, tehát nem veszed alapvetőnek azt, hogy ami benne van a DOM-ban, azt ténylegesen érzékeli az illető. És ha mondjuk 10-es a betűméret egy gyengén látónál vagy alacsony a kontraszt, akkor a teszt elhasal a11y hibával, mert nem tudja elolvasni. Ezt részben bele lehet építeni e2e tesztekbe is, de nem vagyok benne biztos, hogy teljes egészében le lehet fedni mindent olyan tesztek nélkül, amik erre specifikusak. Idén már nem hiszem, hogy lesz időm mélyebben beleásni magam a témába, annyi mindent kell befejeznem mielőtt újraindulok a vállalkozással, de hosszú távon jótékonyságból szívesen foglalkoznék vele a szabadidőmben, hátha tudok valamit javítani ezeknek az embereknek a helyzetén.
Billentyűzet
AOM