Podcastben beszélgettem a web akadálymentességről

Örömmel tettem eleget a Shiwaforce meghívásának, hogy a DevTales című podcast csatornájukban a web akadálymentességről beszélgessünk.

A két részből álló műsor az alábbi linkeken vagy a népszerű podcast lejátszókban meghallgatható, illetve a szöveges átirata elolvasható:

• DevTales 52. adás (a beszélgetés első része)
• DevTales 54. adás (a beszélgetés második része)

A beszélgetés szöveges átirata

• Első rész
• Második rész

A szöveges átiratért hálás köszönettel tartozom Dr. Kosztyánné Dr. Mátrai Ritának, aki baráti szívességből, áldozatos munkával elkészítette nekem azt.

Első rész

[Bevezető zene szól.]

Edu: Sziasztok! Ez itt a DevTales 52. adása. Ma velünk van Róka, Tibi, Roli és sztárvendégünk, Szántai Karesz, aki nekünk ebben az adásban fog részletesebben mesélni arról, hogy mi is az pontosan, hogy akadálymentesség.

Tibi: Szóval Karesz, kicsit tudnál mesélni magadról, hogy hogy kerültél bele ebbe a szakmába, egyáltalán mit takar ez, mivel szoktál foglalkozni, magyarán a munkaköröd mit fed le ebben az értelemben?

Szántai Károly (Sz.K.): Sziasztok! Én is üdvözlök mindenkit. Köszönöm szépen a meghívást, nagyon megtisztelő! Valóban az akadálymentességgel foglalkozom, és akkor szerintem itt rögtön rendbe is lehet tenni ezt az accessibility, akadálymentesség kérdéskörét. Mert ha elkezdünk nyelvészkedni, akkor az accessibility azért magyar fordításban inkább hozzáférhetőséget jelent, csak hogyha valaki ezt a szót meghallja így, akkor nem feltétlenül arra koncentrál, vagy arra gondol, amire gondolni kéne, úgyhogy valahogy így nálunk az akadálymentesség terjedt el, de a szó eredeti értelme szerintem kifejezőbb: hogy valakinek joga van mindenféle információhoz az interneten hozzájutnia, és lehetőség szerint ez a hozzáférés számára akadálytalan legyen. Tehát inkább az akadálymentes hozzáférésről beszélhetünk. De mindenesetre valahogy ezt értjük az accessibility kifejezés alatt. Egyébként az is érdekesség, hogy épített környezetben egészen más angol szavak vannak az akadálymentességre: barrier-free-től elkezdve csomó minden más elnevezés van, de itt az IT-n belül ez a szó ragadt meg. De a másik pedig, amin szintén mindig lovagolok, és azt is most hadd mondjam el nektek, ez az akadálymentesség, meg az akadálymentesítés közötti különbséget, mert nagyon sokszor mindenki akadálymentesíteni akar, amiben – a szóban – benne van, hogy valami eleve rossz volt, és utólag fogja valaki a kalapácsot és a vésőt, és csinál belőle valami jót. Tehát magyarul van egy rossz kód, egy rossz honlap, és utána valaki jön, és mentesíti. Holott igazándiból az akadálymentességre kellene törekedni, hogy eleve nulláról építkezve elinduljon egy folyamat, ami eleve jót fog szülni magából. Tehát ez is egy kicsit nyelvészkedés, de szerintem fontos.
Én hogy kerültem ebbe a témába: sokan ugye azt feltételezhetik, hogy érintett vagyok, vagy esetleg a családomban valaki érintett, és ezért kezdtem el evvel a témával foglalkozni. Hála a jó Istennek, ez nem áll fönt. Egyszerűen annyi történt, hogy így kvázi mérnökként elkezdett az a dolog foglalkoztatni, hogy oké, hogy mi csinálunk weboldalakat, de vajon más mérnöki tudományhoz hasonlóan nem áll-e fönt az, hogy nem minden a külcsíny. Tehát hogy esetleg nézzünk már be a kódba belülre, hogy vannak-e olyan szabványok, vannak-e olyan specifikációk, vannak-e olyan követelmények, amit egy kódnak teljesítenie kell. Ti is mindnyájan tudjátok, hogy nagyon sokszor a munkánk nagy része, hogy a Ti munkátok abból áll, hogy megjön a layout, és akkor minden úgy nézzen ki, ahogy azt megtervezték a dizájnerek, és akkor ennek mindent vessünk alá. De mindig azt szoktam mondani, hogy egy épületnél sem feltétlenül te a homlokzatból fogsz kiindulni. Ha valaki akar vásárolni egy épületet vagy egy lakást, akkor hát a legnagyobb hülye lenne, ha elkezdené, hogy jaj, de szép a homlokzata, vagy de szép ez a festés, és nem kezd el mögé nézni, hogy jó, de mik az alapok, hogyan vannak a csövek, stb. stb. stb. Tehát engem ez a téma kezdett érdekelni. Minőségbiztosítás weben; mit jelent az, hogy valami minőségi. És akkor ennek vannak különböző ágai értelemszerűen: hogy mennyire tartja a specifikációt, esetleg belekerülhet más SEO is – bár én amikor a pályám elején voltam, akkor erről még nem nagyon beszéltünk –, és akkor elég hamar belefutottam ebbe a témába, hogy használhatóság, meg a használhatóságon belül az érintett, esetleg olyan csoportok számára használható-e a honlap, amire nem nagyon gondolunk. S ez nekem úgy megtetszett. S láttam, hogy evvel nem nagyon foglalkoznak itthon. Világszerte sem sokan, de azért elindult valami folyamat. Ez a 2000-es évek eleje-közepe egyébként, amiről most beszélünk. Akkor még UX-ről nem is nagyon beszéltek, akkor mindenki még csak használhatóságról beszélt. S akkor elkezdtem evvel foglalkozni, s úgy gondoltam, hogy ez izgalmas, szakmailag is izgalmas, jót is csinálok vele, hiszen sok embernek segítek, úgyhogy valahogy ez nekem így megtetszett, s akkor erre specifikáltam magam. Alapvetően kezdetben egy céget alapítottam rá egy barátommal közösen, és akkor ez egy darabig ment, de utána magánzó lettem, tehát abszolút szabadúszóként dolgozom. Titulusom mindig változik, de alapvetően web akadálymentességi szakértőként szoktam magam titulálni. Ezt most már meg is tehetem, hiszen jelenleg van egy olyan tanúsítványom, ami egy nemzetközi szintű tanúsítvány, amiből jelenleg úgy tudom, hogy egyedül vagyok, bár Roli mondta, hogy esetleg ő is pályázik majd erre a dologra [műsorvezetőkkel együtt mosolyognak], mindenesetre ez egy nemzetközi specifikáció, vagy egy nemzetközi tanúsítvány, amit mindenhol elismernek a világon, tehát ilyen szempontból most már ez nem egy odabiggyesztett szó, hanem valóban, ha tetszik, van erről papírom. Ennyi.
Alapvetően a munkám nagy része abból áll, hogy vizsgálok, auditálok. Az azt jelenti, hogy jön egy megrendelő, és azt mondja, hogy itt a kész honlap, mondjam meg, mi a rossz benne. Na ez az akadálymentesítés. Ezt utálom jobban, mert ugye sokkal nagyobb meló, és akkor mindig végig kell hallgatni a sirámokat, hogy akkor ez ú de mennyi munka, ú de nehéz, bla-bla-bla-bla-bla-bla. Sokkal jobban szeretem azt a munkát, amikor tanácsadóként vonnak be nulláról – ugye itt a Shiwánál ez már többször megtörtént –, amikor így munkakapcsolatba kerültünk. Ezek a jobb projektek, mert ilyenkor a nullán lehet már jobb irányba terelni a történetet. És akkor nyilvánvalóan az is felmerül – most ugye erről is beszélünk –, hogy szeptember 23-dika óta él egy törvény Magyarországon, ami ezt az akadálymentességet a közcélú honlapok esetében nagyon durván specifikálja. Tehát nagyon sokszor azt kérik, hogy tényleg adjak valami véleményt, szakmai véleményt arról, hogy ez a honlap jó-e, nem jó, és ha általában ha nem jó, akkor mi a rossz rajta. S még egy harmadik dolog van, ami előjön, az pedig a tanítás. Azt nagyon imádom, nagyon régóta csinálom, fejlesztőket nagyon sokszor mindenféle témára tanítottam már, web akadálymentességen túl is. Pont visszakanyarodva erre a szabványokra, amikor bejött a HTML5, meg még régebben hát nagyon sok minden ilyen téma volt, amit tanítottam, úgyhogy több száz embert tanítottam országszerte, ezt nagyon szeretem, nagyon kikapcsol, és picit úgy az embernek az agyát átváltja egy olyan témára, ami nem mindig a napi rutin, ami a megszokott rutin.

Tibi: És az egyébként jár valamilyen szintű felelősséggel is? Tehát ugye te auditálsz egy oldalt, vagy tanácsot adsz fejlesztőknek, hogy hogyan készítsék el azt az oldalt megfelelően, hogy az akadálymentes legyen, és nyilván miután leauditáltad, az azt jelenti, hogy az az oldal a megfelelő szabvány mentén akadálymentesnek mondható. De utána, tehát van még egy réteg, aki esetleg ezt visszaellenőrizheti, hogy mégsem teljesen akadálymentes ez az oldal? Vagy pedig csak szimplán a felhasználói oldalról ha esetleg jönnek reklamációk, hogy hát ez az oldal akadálymentesnek van mondva, de szerintem nem lehet teljesen jól használni abból a szempontból, ilyen azért így előfordulhat? Tehát megkereshetnek ilyennel kapcsolatban?

Sz.K.: Természetesen! Tehát tulajdonképpen az akadálymentesség – ezt szoktam mondani –, hogy nem olyan, mint a konnektor. Tehát ugye a konnektornál, fogja magát, jön az auditor, vagy hívjuk bármi másnak, bedugja a kis műszerét, megmutatja, hogy 230, érintésvédelem oké, rápecsétel, aláírom és oké. Nahát a weboldalaknál nem ez van. Tehát az akadálymentesség az egy állapot. Száz százalékosan akadálymentes honlap nincs. Nem is lesz. Ezt egy műszerként kell elképzelni, aminek vannak különböző sávjai: nyilván van egy piros sávja, amikor nagyon rossz, vagy egy sárga, ami közepes, egy zöld, amikor már egyre jobb, s akkor a kérdés, hogy a mutató mennyire leng ki. Amikor én egy vizsgálatot csinálok, akkor egy időpillanatot nézek. Október 18-án így nézett ki az oldal. Ez és ez volt rajta. S akkor én úgy ítélem meg, hogy ez jó. Ez is egy furcsa dolog, mert a „megítélem”-ben nem fekete-fehér igen-nem a dolog. Tehát ha leültetnénk egy másik – hozzám hasonló – kollegát, akár a világ másik feléről, lehet, hogy ő azt mondaná ugyanarra a dologra, hogy rossz. Tehát nem ennyire specifikált, mint a 230 a konnektorba. S akkor utána lehet, hogy másnap fölkerül egy másik anyag, már elkezdi tölteni, hiszen itt dinamikus dolgokról beszélünk, nem egy statikus honlapról, hanem általában ezek fejlődnek. Tehát igen, elképzelhető, hogy következő napon már megreccsen az oldal. És én is azt mondom, amit ugye említett Tibi, hogy fontos a visszajelzés, tehát mindig azt szoktam javasolni minden partnernek, hogy igen, mondjuk azt, hogy ez most jó, ez most átment, tehát a skála zöldben van, fogalmazzunk így, de biztosítsatok visszacsatolást arra, hogy az érintett userek tudjanak visszacsatolni, hogy igen, igen, szerintünk ez nem stimmel, vagy evvel még itt kéne valamit csinálni. S akkor ezt érdemes megfontolni, hogy ez megtörténjen. Biztos, hogy van egy ilyen típusú probléma evvel, s ez nekem is néha olyan szempontból – hogy mondjam – kellemetlen, hogy szakmailag is, amit említesz, hogy valaki azt mondja, hogy Erre ezt mondta ez az ember, hogy ez jó? Hát basszus, most látom, hogy ezen – nem tudom mi – nincs kitöltve. S ez furcsa is. Tehát igazándiból sokszor a webfejlesztő cégek szeretik kitenni a láblécbe, hogy ezt mi csináltuk, meg made by, meg nem tudom, micsoda. Nálam ez kevésbé működhet, mert tényleg szakmailag valóban furcsa lenne, hogy utólag valaki azt mondja, hogy hoppá, ez mégsem stimmel. Tehát ez egy időlenyomat. Adott pillanatban milyen az állapota. És mondom, nem feltétlenül fekete-fehér igen-nem. Persze rá kell mondani, mert a specifikáció rámondatja, hogy igen, jó; nem, nem jó; de ennek vannak azért szürke zónái. És hogyha egy kicsit azt nézzük, hogy ez az egész valahol mégiscsak a használhatóságról szól, szoktam úgy is fogalmazni, hogy „akadálymentes felhasználói élmény”. „Akadálymentes UX”. És onnantól kezdve már a UX nem fekete-fehér igen-nem, tehát ugyanolyan szürke zónák vannak. Tehát itt is az akadálymentességben vannak olyan szituációk, amikor nem lehet rámondani azt, hogy ez rossz, vagy jó, hanem lehetne jobbá tenni, lehetne rosszabbá stb.

Tibi: Szóval ez az egész egy kicsit relatív is. Talán arra lehet visszakanyarítani, hogy egyszer mesélted, hogy egy oldal nem volt auditálva, és nem is akadálymentesen készült el, viszont felhasználók, akik ugye mondjuk felolvasóval használták az oldalt, azt mondták, hogy igazából nem is olyan rossz, mert nagyjából tartották a szabványokat, szemantikát, és az alapján úgy félig-meddig lehetett már használni az oldalt, tehát valójában nem is feltétlen mindig kell, hogy az tökéletesen úgy készüljön, és ilyen szempontok mentén, ha szimplán csak jól használjuk a kódot, akkor az már eleve egy egész jó alapot tud adni.

Sz.K.: Igen. Két sztori is volt evvel kapcsolatban. Tulajdonképpen az egyik sztori az, hogy valóban egyértelműen megszokják, de ez lehet, hogy a rossz oldalaknál is. Tehát ott van egy gomb, amiről nem tudjuk, hogy mi van ráírva, de azt kell megnyomni ahhoz, hogy bejussak oda. És akkor ez így megszokódik. Tehát ez a lehetőség. A másik az viszont izgalmasabb – lehet, hogy erre gondolsz –, van olyan is, hogy például ha a képernyőolvasó szoftverek világáról beszélünk, akkor a képernyőolvasó szoftverekben van már bizonyos szintű – nem azt mondom, hogy mesterséges intelligencia, de elég régóta vannak benne – olyan heurisztikák, aminek segítségével megpróbálják a rossz kódot valamilyen módon korrigálni. És bizony nekem volt már olyan precedens, amikor megkérték, hogy nézzem meg az oldalt, én azt mondtam rá, hogy nem jó, majd az ügyfél ráengedett egy ott, a cégnél dolgozó látássérült kollegát, aki azt mondta, hogy hát ez egy baromság. Hát ez tökéletesen jól használható, nem is érti, hogy ki volt az, aki erre azt mondta, hogy rossz. És az illető nem volt informatikus, tehát nem tudta ennek a hátterét; ő csak bekapcsolta a saját kis felolvasószoftverét, és tök jól működött. Egy dolgot felejtett el: hogy az ő felolvasószoftverében működött ez a heurisztika, és ennek következtében – például egy űrlapnál – az űrlapmező ugye nem volt felcímkézve megfelelően, de mivel mellé volt valahogy téve, biggyesztve a címke, ezért a képernyőfelolvasó úgy döntött, hogy hát valószínűleg az a címke, és beolvasta neki. De ha ugyanarra az oldalra ráengedett egy másik gyártó által készített felolvasószoftvert, az meg meg se szólalt. Tehát rossz volt. Hibás volt egyértelműen. Itt most fekete-fehér igen-nemben rossz volt az a kód, de az illető mégis úgy tapasztalta, hogy jó. Tehát ez is egy veszélyes történet lehet, de benne van a pakliban.

Róka: Említetted, hogy egy kicsit szürke zóna ez a terület, nem lehet ennyire megfogalmazni; mégis hogy fognád meg, hogy mennyire UX, és mennyire technikai a te munkád? Ez lenne az egyik kérdésem, és a másik pedig, ahogy említetted, más-más szoftverek vannak. Amikor azt mondod, hogy egy honlap – mondjuk egy statikus honlap – akadálymentes, és jönnek újabb verziók, akár böngészőkből, akár felolvasókból, akkor ezek tönkre tudják tenni ezt a minősítést?

Sz.K.: Az első kérdésre, hogy mennyiben technikai és mennyiben UX, azt szoktam mondani, hogy vannak olyan akadályok, amik tényleg átugorhatatlan akadályok. Ami azt jelenti, hogyha például te behívsz egy vak felhasználót, vagy behívsz egy mozgássérült felhasználót – mert ne abba a hibába essünk, hogy képernyőolvasó, képernyőolvasó, képernyőolvasó, mert nem erről szól a történet –; lehet, hogy inkább azt mondom, hogy kezdjünk egy mozgássérült felhasználóval, aki mondjuk nem tudja az egeret használni, s vagy egy más alternatív beviteli eszközt használ. S mondjuk ő lát egy gombot a képernyőn, és szeretné azt a gombot megnyomni. Szeretne ráállni arra a gomba, és szeretné azt megnyomni, és nem tudja. Ez nem UX, ez akadály. Ezt nem tudja áthidalni. Ez olyan, mint hogyha kint az utcán egy kerekesszékes nem tudna fölmenni a lépcsőn. Tehát ez egy klasszikus akadály. De onnantól kezdve már például, ha azt nézzük, hogy az illető mozog a képernyőn, lépked mondjuk a tabulátor billentyűvel vagy más eszközzel, és az elemek különböző sorrendben kerülnek a fókuszba; hogy először mondjuk elugrik a jobb oldalra, aztán vissza a bal oldalra, tehát van egy ilyen mozgás, akkor nem mondhatjuk igazándiból azt, hogy ez egy olyan akadály, ami áthidalhatatlan, de az illető számára biztos, hogy baromi kényelmetlen lesz, tehát a felhasználói élményt jelentősen ledegradálja. Ettől függetlenül mondjuk speciál ez a fókuszba kerülésnek a sorrendje a WCAG szabványban – ugye ami igazándiból a bibliája az akadálymentességnek – egy olyan követelmény, amelyik mégis azt mondja, hogy igen, egy honlap akkor jó, hogyha a fókusz értelmes sorrendben kerül lépkedésre. Tehát ezt mondanám, hogy igazándiból valóban szerintem azért nagyrészt UX kérdéskör, de vannak ilyen problémák. Megjegyzem egyébként, sokszor megkérdezik tőlem, hogy én épként – bár ez is furcsa, hogy mit jelent az, hogy ép –, de nem feltétlenül konkrétan érintettként meg tudom-e ítélni egy oldalról, hogy jó-e, vagy nem. És igen, ilyenkor előjöhet az, hogy például ha van egy olyan tesztelőd, aki mondjuk nem IT tudással rendelkezik, hanem egy átlagos ember, akkor ő például ezeket a hibákat valószínűleg észre sem veszi. Vagy pedig észre sem veszi, hogy ott van egy olyan elem, amit nem olvasott fel a felolvasószoftver. Tehát behívsz nyolc embert, és nyolc olyan értéket fogsz kapni, hogy nem kapsz értelmes visszajelzést, mert nem fogja észrevenni, hogy ott van egy gomb, amit meg lehetett volna nyomni. Ez más esetben megtörténhet.
A másik kérdésed ugye, hogy mennyire változnak ezek a technológiák, ahogyan változnak ezek a felolvasószoftverek, illetve böngészők: Itt annyit kell tudni, hogy itt mind a kettő szerepet játszik. A böngésző is, meg a felolvasószoftver is. Ugye a kettő között van egy egész érdekes kommunikáció – nem tudom, erről beszéltetek-e már a korábbi adásokban – ez az akadálymentességi fa, vagy accessibility tree névre hallgató dolog, ami tulajdonképpen egy olyan API-t jelent, hogy én böngészőprogram azt mondom, hogy szerintem ez az elem ez, ez egy gomb, ennek ez a neve, ez itt van, és akkor kedves felolvasószoftver, te meg ebből az információból dolgozol. Namost elképzelhető, hogy a böngészőprogram fejlődik, a böngészőprogram elkezd valamit támogatni, mondjuk egy új elemet, vagy egy új attribútumot vagy bármi mást, és akkor abban a pillanatban már a felolvasószoftver is átveszi ezt az információt, mert tételezzük fel, hogy erre föl van készítve. Tehát van egy ilyen típusú skálázás, hogy egyik jobban fejlődik, mint a másik. Az, hogy hibás legyen, az szerintem kevésbé jellemző. Tehát inkább az, hogy feature-ökbe jönnek-e, vagy sem; ezek bizony újdonságot jelenthetnek, akár – mondom – még egy operációs rendszer szinten is. A héten kijött a macOS-ből egy új verzió, az iOS-ből is, és számtalan újdonság van ezekben az operációs rendszerekben, ami eddig nem volt supportálva egy felolvasószoftver számára. De lehetséges, hogy ez a kettő összejátszik. És ugye nagyon fontos – és ezt mindig el szoktam mondani –, hogy elképzelhető, hogy te veszel egy operációs rendszert, fut rajta egy böngésző meg egy felolvasószoftver. És akkor ugyanazzal az operációs rendszerrel, ugyanavval a felolvasószoftverrel egy másik böngészővel más élményt fogsz kapni. Mert ott a böngésző nem támogatja azt a történetet. De lehet fordítva is, hogy minden böngésző támogatja, de még a felolvasószoftver nem támogatja. Ez biztos, hogy benne van a pakliban. Ezért nehéz. Talán még nehezebb belőni a baseline-t, mint mikor egy fejlesztésnél azt mondja az ember, hogy jó, akkor most lövünk az Explorerben 8-ra, meg a Chrome erre meg arra, mert itt azért több játékos van ebben a történetben.

Edu: Mondtad, hogy az auditot úgy szoktad csinálni, hogy az adott időpontban – mondjuk valamelyik nap, vagy hónap – és ugye az oldalak azok nem állnak egy állapotban, hanem mindig újabb és újabb verziók jönnek ki, és gondolom, hogy a cég számára, vagy az ügyfél számára ez nem biztos, hogy mindig jó egy ilyen fajta auditot csinálni, mert lehet, hogy pénzköltség is, vagy más okok is lehetnek. Ezt a részét lehet valahogy automatizálni? Tehát, hogy van erre valami eszköz, hogy mondjuk kijön egy újabb verzió, és valahogy megvizsgálni, hogy megfelelő-e annak az állapotnak, ami előtte volt – nem tudom, százalékban, vagy valamilyen arányban?

Sz.K.: Evvel kapcsolatban szerintem érdemes onnan kezdeni, hogy kétfajta módszertant ismer az akadálymentességi vizsgálatra a szakirodalom. Az egyik ugye a manuális tesztelés, a manuális vizsgálat, a másik pedig az automatikus. Most ne is auditról beszéljünk, mert auditról akkor szoktunk általában beszélni, ha van valami szabvány, specifikáció, aminek megfelel a történet, de mondjuk ha vizsgálatnak hívjuk, avval is jót mondunk. Namost azt kell tudnotok, hogy alapvetően a különböző felmérések és különböző tesztek alapján az automatikus ellenőrző rendszerek azok általában az akadálymentességi hibáknak körülbelül az egynegyedét találják meg. Ugye evvel kapcsolatban Rolinak majd lesz egy jó kis előadása október 21-én, amiben evvel a témával fog foglalkozni, hogy az automatikus teszteket hogyan lehet bevonni a munkába, amire biztos, hogy szükség van, és pont az a scenáriója, amit mondasz, hogy egy fejlesztő napi szinten mikor buildel egy új verziót, hogy akkor meg tudjon arról győződni, hogy jó irányba halad-e, nem követett-e el valami nagyon banális hibát. De mondom, ezek az automatikus rendszerek ezek nagyon kevés hibát találnak meg, és pont a UX-es, tehát pont azokat a kérdéseket, ami nem algoritmizálható, vagy nehezen algoritmizálható, ott lehetnek olyan problémák, amiket biztos, hogy emberi szemnek, emberi, humán vizsgálat alapján kell elvégezni. S valóban – ahogy említetted –, ezért a humán ellenőrzés az egy viszonylag költséges történet, hiszen elég komoly erőforrást kell beletenni, tehát valóban nem lehet azt csinálni, hogy minden egyes honlap minden egyes verzióját humán erőforrással vizsgálunk meg, vagy vizsgáltatnak meg, de ha valóban egy komoly minősítés kell róla, vagy valóban kell egy olyan állapotfelmérés, ami túlmutat ezen az automatizmuson, akkor azt mindenképpen meg szokták csináltatni. Nem is biztos, hogy a megrendelő egyébként; nagyon sokszor engem sem a megrendelő keres meg, hanem mondjuk egy pályázat van, vagy törvényi kötelezettség, vagy esetleg harmadik félként, független harmadik partnerként. Hiszen a fejlesztő azt mondja, hogy szerinte jó, a megrendelő meg most kinek higgyen? Elhiggye, hogy jó-e vagy nem jó, vagy azt mondja, hogy akkor keressünk egy harmadik felet, aki azt mondja rá, hogy nézzünk már meg, hogy működőképes-e vagy nem. De mondom, ezek az automatikus tesztek ezek jók lehetnek; ugye most már a Google-be is be van építve, a Chrome-ba is be van építve ilyen “auditor”, idézőjelben, ellenőrzőrendszer. Vicces, hiszen egy osztrák kollega csinált egy olyan honlapot, amibe beletette az összes létező hibát, amit el tudott képzelni akadálymentességi szempontból, és bebizonyította, hogy erre ráengedve a Google Chrome-ban lévő auditor rendszert, 100%-os zöldet kapsz, hogy tökéletesen jó az oldal. Tehát nagyon sok fals pozitív eredményt ad. Összefüggésekre elég nehezen tud rávilágítani egy ilyen rendszer. Megmondom, a UX-es kérdésekre általában – amikor valahogy azért kicsit gondolkozni kell, tehát végül is ez egy humán történet –, ott biztos, hogy ezek hibáznak. De a klasszikus egyszeregye az akadálymentességnek, “az alt attribútum legyen kitöltve” című történet – ami ugye általában nagyon sok fejlesztő fejében az az első, hogy ja, az akadálymentességgel valamit kell csinálni az alt attribútummal –, na ott is például ez elvileg algoritmizálható, mert tudsz rá írni egy algoritmust, hogy nézzük meg, hogy az alt attribútum ki van-e töltve. Ha nincs, akkor hiba, bla-bla-bla-bla-bla. De ez sem így van, mert először meg kell nézni, hogy mi az a kép, mit ábrázol, mi a szerepe, van-e funkciója, egyáltalán miről szól az a kép. És akkor lehet, hogy az lesz a jó megoldás, hogy az alt üresen marad. Mert például egy olyan kép esetén, aminek nincsen tartalmilag szerepe, mert csak jól néz ki, és odatették a designerek, ott például az a helyes megoldás, hogy az alt üresen marad. De erre egy rendszer azt fogja mondani, hogy ácsi, ácsi, hülye vagy, nem töltötted ki az alt attribútumot. Tehát ez benne van. De az is benne lehet, hogy ki van töltve az alt attribútum, azt mondja, hogy tök jó, és van a képen egy macska, az alt attribútumban meg az van, hogy papagáj, és ezt is el fogja fogadni a rendszer, mondván, hogy ez tök jól sikerült. Bár most hozzáteszem, már ezek a mesterséges intelligencia rendszerek vannak, már ebben is vannak előrelépések, mert akár a Microsoftnak a saját ilyen AI rendszere, a facebooknak a saját AI rendszere, ezeket már úgy megpróbálja kiszűrni, tehát hogy nagy hülyeséget nem tudsz csinálni, de azért biztos, hogy lehet benne ilyet hibát véteni. Ugye az automatizmus ilyen módon téved.

Edu: S ha mondjuk a képnek – mondtad, hogy az üres alt esetén – akkor ilyenkor mondjuk nem lehetne az a megoldás, hogy aria-hidden true-t is mondjuk rárakni?

Sz.K.: Na ez klasszikusan érdekes dolog, mert oda mozdul a téma, hogy az ARIA, mint szabvány, vagy mint lehetőség is sok front-end fejlesztő szemében is ott lebeg, mint valami csodafegyver. Tulajdonképpen erre azt kellene mondanom, hogy az üres alt az már évtizedek óta azt jelenti, hogy vedd tudomáson kívül ezt az elemet. Tehát a felolvasószoftver egy üres alt attribútummal rendelkező képet úgy vesz, hogy nincs is ott. Tehát hidden. Tehát igazándiból megcsinálhatod, hogy aria-hidden true, evvel ugyanazt fogod elérni, amit évtizedek óta elérünk az üres alttal. Egyetlenegy kivételt tudnék neked esetleg említeni, amikor össze kezdjük mosni mondjuk a keresőmarketinget, a SEO-t meg az akadálymentességet, mert lehet, hogy én azt mondom, hogy hohó, ez maradjon üresen, én mint akadálymentesítő. És akkor jön a SEO-s kollega, vagy a SEO-s szakember, és ő meg elkezd őrjöngeni, hogy de hát ez nem jó, mert ott az alt attribútum meg majd a Google akkor nem fogja megtalálni, na ott például elképzelhető egy ilyen megoldás, hogy ki van töltve az alt, SEO szempontból korrektül, és egyébként meg aria-hidden true-val el van rejtve a felolvasóprogram elől, mert azt mondjuk, hogy ez akkor sem érdekes felolvasáskor, hogy olvassa fel, hogy ott mit tudom én mi van a képen. Tehát ez így lehet. De én mindig azt tudom mondani – és az ARIA-nál ez egy klasszikus –, ARIA első szabály: Ne használj ARIA-t! Ez hülyén hangzik, de ez az igazság. Hogy nyúljunk vissza a jó öreg HTML-hez, és amit a HTML meg tud csinálni, avval oldjuk meg. És amit nem tud a HTML, na akkor nézzük meg, hogy mi is ez az egész ARIA történet? És akkor érdemes ezt bedobni fegyverként.

Róka: Ez az akadálymentesség ez csak front-end fejlesztőket érint? Vagy a back-endes kollégáknak is kell valamilyen szinten gondolkodni arról, hogy hogyan lesz majd a honlap akadálymentes?

Sz.K.: Hát, ez egy jó kérdés. Szerintem back-end oldalra én nem tudnék most mondani olyan scenariot, ahol ez előfordulhat, vagy érdekes lehet. Alapvetően a front-end oldal az, ami ebben a legfontosabb szerepet tölti be, de ha most kicsit kinyitjuk a kört, és azt mondjuk, hogy a front-end fejlesztőkön túl továbbnyitjuk a történetet, akkor ugye az első kapavágástól, az első UX-es wireframe tervezéskor ez a történet bejön. Tehát nagyon sok esetben engem is már – és ezt nagyon szeretem, ahogy az előbb említettem nektek – ha már korán bevonnak a történetbe, nagyon sokszor én először a UX-esekkel találkozom, és a UX-esekkel kezdek el dolgozni azon, hogy mi hogyan alakuljon, és akkor még front-endesekkel nem is beszéltünk. Őket akkor szoktuk elkezdeni bevonni, amikor elindul valami meredek történet, és akkor na, ezt meg tudjátok-e, fiúk, valósítani?. Tehát ilyen szempontból a UX nagyon fontos. Aztán ha továbbmegyünk, akkor a következő a UI, ahol ugye előjöhet szintén a történet, hiszen mondjuk egy grafikusnak, amikor már a végső arculatot tervezi, akkor például van egy-két olyan dolog, amire figyelnie kell. Klasszikusan ugye a színkontrasztok kérdése, ami nem front-end, meg nem UX kérdéskör, hanem UI, ott ez nyilvánvalóan előjöhet. Aztán utána lép be ugye nyilvánvalóan a front-end, és nagyon sokszor az ő felelősségük igazából valóban jól lekódolni. De itt mentségéül legyen szólva a front-endeseknek – és ezt mindenképpen szeretném hozzátenni –, hogy nagyon sokszor miért neki kéne kitalálnia. Tehát nagyon sokszor azt látom, hogy nem a front-endes kollégának kéne ott hirtelen kitalálnia, hogy na most akkor oda mit írjak, mi legyen az alt attribútum, mi legyen a sorrendje. Ez így nagyon nehéz, én azt látom, hogy nagyon-nagyon kevés cég van, ahol ez ilyen szépen, ilyen vízesésfolyam-szerűen végigmegy, hogy valóban az első kapavágástól végigvezetjük az akadálymentességet, mert ez már egy input kell, hogy legyen, a front-endesek fele, hogy fiúk, ezt így kell csinálni, vagy ez legyen a sorrend, vagy ez legyen a valami, amire még mindig mondhatja, hogy jó, ezt nem tudom megoldani, mert a keretrendszer nem támogatja, vagy nem tudom, de mindenesetre legyen egy jó bemenet, valaki tervezze meg. Valaki legyen ilyen szempontból benne. És akkor még egy dolgot, ami most így eszembe jutott: a content. Akik írják. Ugye klasszikusan hova tesszük, a UX-hez, vagy hova, de mondjuk egy tartalomírónál, egy szövegírónál is érdekes lehet, hogy milyen bikfanyelven fogalmaz, érthető-e, hiszen az akadálymentesség egyik része az érthetőség. Hogy érti-e a user majd, hogy mi van leírva. Most gondoljatok ugye a klasszikus, jó öreg közszolgálati honlapoknál, vagy önkormányzatoknál, vagy minisztériumoknál, ahol a felét nem érted, amikor te ügyet akarsz intézni, mert olyan bikfanyelven van megfogalmazva, ami borzasztó. Itt ez a könnyen érthető nyelvezet, amiben ugye nagyon sokszor szoktam javasolni, hogy – nem tudom, hogy ezt mondhatom-e itt, de – a világosbeszéd.hu nevű honlap, amelyik kifejezetten evvel foglalkozik, hogy hogyan kell közérthetően fogalmazni. Ez egy nagyon-nagyon fontos téma. Tehát azért mondom, hogy az akadálymentesség sok szakterületet átvon, nem feltétlenül a front-endet csak.

Róka: Back-end oldalról – bocs, hogy még egyszer így visszatérek rá – esetleg olyan szempontok, hogy mondjuk honlapnak a sebessége, tehát hogy mennyire gyorsan tölt be, ezt hogy lehet akadálymentes oldalról kezelni, meg ami még ide kapcsolódhat, a captcha, mint történet, hogy valahogy azonosítanom kell, hogy mégsem robotról van szó, illetve az SPA is ide kapcsolódik, mint modernebb dolog.

Sz.K.: Igen, ez így, ahogy mondod, a sebességnél az előbb így az eszembe jutott, hogy az esetleg közrejátszhat ebben a történetben. Valóban, hogyha visszakanyarodunk oda, hogy hozzáférhetőség, akkor mondhatjuk azt, hogy a user mennyi idő alatt fér hozzá ahhoz az információhoz. Hogy egy végletes példát mondjak nektek, igaz, hogy nem mai történet, viszonylag régebben, talán a mobilnak az őshajnalán volt, amikor még azért a sávszélesség nem úgy állt, ahogy most, és akkor bizony az történt, hogy én is fölmentem – nem is tudom, Balatonon voltunk, és meg akartam nézni a menetrendet, mert a fiam mondta, hogy akkor menjünk el hajókázni –, és akkor az ember elővette a jó öreg telefonját, és valamilyen eszement – nem tudom, hány, 1G – sebességgel nekiállt megnézni a menetrendeket. Most ilyenkor persze hullik az embernek a haja, hogy az a sok szemét – engem marhára nem érdekel, hogy hogy néz ki a Helka hajó, meg milyen a kapitánynak a bajsza –, engem az érdekel, hogy mi a menetrend. Mondják meg, hogy Siófokon ekkor indul. És bizony akkor előjöhet az, hogy mondjuk azt mondod, hogy ha nagyon rossz a sávszélesség, akkor kikapcsolom a képeket. Onnantól kezdve én kvázi látássérült felhasználó vagyok, vak felhasználó vagyok. És szeretném úgy használni, hogy gyorsítsam a dolgokat. Namost abban a pillanatban minden információ, ami csak a képen található, az tőled messze áll, ebben a pillanatban nem férek hozzá – lásd, hány olyan menetrend van, hány olyan honlap van a menetrendeken, jó kis beszkennelt jpg-ként vannak fent az oldalon. Tehát ebben a pillanatban ugyanoda visszakanyarodtunk, és kezdjük kitágítani azt a kört, hogy igenis az akadálymentességre ne úgy tekintsünk, hogy az a fogyatékos emberek számára történő funkció, hanem mindannyiunk számára ez egy hozzáférhetetlenségi probléma volt.
Captcha: hát ugye a captcha abból a szempontból ha belegondolsz, akkor a captcha az azt jelenti, hogy nincs mit auditálni, ott teszünk oda egy akadályt. Mert meg akarjuk szivatni a felhasználót. Erről szól a történet. Captcha; ugye eredetileg ennek ez volt a lényege: meg tudjam állapítani, hogy a túloldalon ember van, vagy gép. És oda valami olyan akadályt próbálok betenni, amivel megakadályozom a gépet, azaz nálunk egy picivel talán most már lassan fejlettebb intelligenciát, hogy átverjen. Namost evvel kapcsolatban rögtön átverem az illetőt is, az embert is, a humánt is. Tehát egyszerűen „akadálymentes captcha”, ez egy nonszensz fogalom. Lehet vele játszadozni, de hát hogyha akadálymentesítem a captcha-t, akkor miért tettem oda captcha-t? A kettő nem fér össze. Persze gondolhatnánk, hogy jó, hát akkor nem a krix-krax szöveget kell odaírni, hanem ott van a gomb, és nyomd meg, és akkor majd felolvassa, valami szövegben elhangzik a kód, dehát érdemes meghallgatni, hogy ezek milyen minőségűek, meg hát ugye manapság már a speech-to-text technológia olyan szinten van, hogy hát basszus, hogy ha odateszek egy telefont mellé, vagy bármit, és fölismeri azt a hangot, és akkor azt is eltorzítják, meg angolul beszél, meg háttérben őrjöngés van, tehát csomó-csomó olyan funkció, ami nem működőképes. Még talán a Google-nak ez a „Nem vagy robot” története állhat valamelyest legközelebb a történethez, hogy valóban csak egy checkboxot kelljen becsekkolgatnom, de hát ugye ott is azért vannak furcsa tapasztalatok. Tehát amikor miután megkapod a képeket, akkor már meghalt a történet, hogy akkor melyik képen van a víziló, tehát ez már nem fog működni.

Róka: Akkor mit lehet tenni a robotok ellen?

Sz.K.: Hát, még egyszer mondom: olyat, hogy a robot elé akadályt teszek, de a humán ember elé nem teszek akadályt, ez szerintem feloldhatatlan. Ez egy Gordiuszi csomó. Ezt nem lehet feloldani. El kell dönteni, hogy mit csinálok. Vagy el kell engedni és akkor valamilyen módon back-end oldalról kell captcha nélkül megoldani a történetet – ehhez értelemszerűen nem értek, de valószínűleg érdemes lenne inkább efelé elmozdulni, hogy efele menjen a tudomány –, vagy a másik, hogy ami még úgy az érintettek közül is sokan elfogadják, az még talán a logikai captcha. Ahogy én beszélek vak barátaimmal, azt mondják, hogy még talán az egyetlen elfogadható történet, amikor ugye kapsz egy kérdést. Nade hát megint ott tartunk, hogy arra a kérdésre most melyik az a rendszer, amelyik nem válaszol öt percen belül? Tehát ez megint egy olyan, hogy csak így átverjük magunkat. Valamelyest persze megakadályozhatjuk, de jó megoldást nem lesz belőle.
Harmadik dolog, amit említettél, vagy amire utaltál, az SPA-k kérdése. Hát az SPA valóban a mai világban elég trendi történet, és elég sokminden problémát felhoz. Itt ugye megint egyrészt a felolvasószoftverek felhasználói számára – tehát vak felhasználók, illetve azok, akik ugye nem feltétlenül csak vak felhasználók használnak felolvasószoftvert, azért ezt is tegyük tisztába, tehát elképzelhető, hogy valaki látóként használja a felolvasószoftvert –, de mindenesetre a felolvasószoftvert használók számára, akkor ugye a mozgássérült felhasználók számára, vagy akik nem tudnak mondjuk egeret használni, és billentyűzettel használják a rendszert, valóban komoly akadályok lehetnek, de ezeket nem tudom, mennyire back-endbe sorolnám. Szerintem itt is inkább több feladata lehet egy front-endesnek olyan tekintetben, hogy adott pillanatban mondjuk a megfelelő fókuszokat hova pakolgatják mondjuk egy akció után, amikor mondjuk átlépek az egyik screenről egy másik screenre ugye refresh nélkül, vagy egyáltalán hogyan jelzem egy felolvasószoftver számára, hogy történt valami, mert nyilvánvalóan amikor page refresh van, akkor azért mégiscsak van egy esemény, ami kiváltja azt, hogy most történt egy frissítés, és akkor a felolvasószoftver is elkezd egy algoritmuson végigfutni, hogy akkor most beolvasom, hogy milyen oldal jött be, azon hány link van, hány gomb stb. stb. SPA-nál ugye ez nincs meg. De szerintem ez is inkább egy előtervezés és front-endes kérdéskör, mintsem back-end, legalábbis ha hagyományos értelemben veszem, akkor biztosan.

Tibi: Említetted ezt a menetrendes képbeszúrós hátráltató tényezőt, hogy hogy is mondjam, illetve volt most a captcha, azon kívül amit még ilyen hasonló példát tudok felhozni – és lehet, hogy egyszer beszéltük –, hogy például az ülőhelyfoglalás megfelelő rendezvényekre. Ugye így nem tudom, háttérben valami flash-sel, vagy nem tudom, akármilyen technológiával – canvassal talán, nem tudom, mivel szokták ezeket megcsinálni –, tehát az a lényeg, hogy azzal van létrehozva, és nagyon nehéz ilyen szempontból kezelni, meg még talán ami nekem erről eszembe jut, tehát ilyen akadályozó tényező, az ilyen nagyon bonyolult táblázatok. Amikor már annyi adat van benne, hogy azt így lehet, hogy nem lenne érdemes egy helyre így betuszkolni mindet, mert úgyse tud egyszerűen komfortosan végigmenni rajta érthetően a felhasználó, de ezeken kívül van még valami tipikus példa, amit így nagyon el kellene kerülni a fejlesztés során? Tehát hogy azt hisszük róla, hogy ez hasznos a felhasználó számára, de közben meg ha akadálymentes szempontból nézzük, akkor majd pont, hogy gyakorlatilag megöli a folyamatot? Tehát például, hogy nem tudok ülőhelyet foglalni, mert nincsen lekezelve, és ott megáll a folyamat. Kész, nem tudom ezt egyedül elvégezni.

Sz.K.: Igen. Az ülőhelyes példa vagy az ülőhelyfoglalós példánál nekem mindig az jut az eszembe, amikor egyszer az egyik tanfolyamon az egyik hallgatóm mondta, hogy hát ő ugye színtévesztő, és ő egyedül képtelen moziba jegyet venni, mindig meg kell várnia a barátnőjét, csak ő tudja megvenni a jegyet, mert nem feltétlenül úgy van rosszul lekezelve, hogy nem használható, hogy nem lehet mondjuk egérrel használni, vagy nem lehet felolvasószoftverrel, hanem például a színtévesztők számára olyan színkódot alkalmaznak – márpedig legtöbbször ugye a piros jelzi a foglalt, zöld a szabad helyeket –, klasszikus két olyan szín, amit a színtévesztők közül a legnagyobb számban tévesztenek; úgynevezett piros-zöld színtévesztés. Namost ebben az esetben végül is a felelősség nem a front-endesé, ahogy ugye az előbb említettünk, hanem azé a UI tervezőé, aki ugye azt mondja, hogy akkor hahó, akkor nézzünk valami más színkombinációt, vagy használjuk ezt a színkombinációt, mert mégiscsak a piros-zöld ez valamelyest ez a szabad-nem szabad, jelzi; de tegyünk melléje valami más jelzést is. Ugye klasszikusan szoktuk azt mondani, hogy a szín mellett még hordozzon valami információt, akár lehet egy pötty, egy satírozási minta, vagy bármi, ami lehetővé teszi, hogy ezt meg tudják különböztetni. Tehát ez ebből a szempontból egy jó példa. Nyilván van persze ettől függetlenül egy problematikus dolog. A táblázatnál is ugyanez a szituáció, és ezzel teljesen egyetértek veled, hogy a táblázatokat is néha túl tudjuk bonyolítani, és néha már annak a feldolgozása marha nehéz, még akár látóként is. Azért gondoljatok bele, a táblázat az egy klasszikus vizuális műfaj. Nem is tudsz róla, de mikor te ránézel egy táblázatra, megnézel benne mondjuk egy árlistát, s megnézel benne egy árat, akkor abban a pillanatban végül is a szemed észrevétlenül csinál egy mozdulatot, és megnézni, hogy melyik sorban vagyok, meg melyik oszlopban vagyok. És akkor úgy tudod detektálni, hogy ez minek az ára. Tehát ilyen szempontból ez egy vizuális történet. Namost gondoljatok bele, ugyanezt kéne eljátszani ugye egy felolvasószoftver esetében, amire egyébként van is lehetőség, ha jól van lekódolva. De mindenesetre valóban, amit így klasszikusan fejlesztők el tudnak követni, és azt gondolják, hogy az jó, az valóban ezek a beágyazott képek, amikor az információ csak oda van rakva, és azt gondolják, hogy akkor azt majd a felhasználó látni fogja, de igazándiból néha én a galériáknál érzem ezt a történetet, ahol szintén nyakunkba veszünk egy csomó olyan dolgot, ami jó, persze lehet, hogy klassz, meg nagyon jó, de azért ha belegondoltok, akkor például mobil esetében [mosolyog] – én nagyon sokszor látok olyan mobil alkalmazást, vagy mobil weboldalt, ahol ott van a nagyítás funkció továbbra is –, de úgy hogy ugye pop-upban előjön, és néha az előjövő modulban, pop-upban kisebb a fotó, mint az eredeti képen volt, tehát ott igazából nem sok értelme volt, és akkor jön ez a mozdulat, hogy akkor hohó, akkor elkezdem nagyítani az ujjammal, és akkor bizony volt olyan korszak – ma már szerencsére ez nem nagyon van –, de korábban ugye volt olyan, hogy ez le volt tiltva. És akkor az ember még inkább verte a fejét a falba, hogy hát ki volt az, aki ezt letiltotta, hát szeretném megnézni közelről ezt a fotót. És akkor utána még nem is beszélek arról, hogy nyilvánvalóan egy ilyen modulnak mennyi velejárója van akadálymentességi szempontból, hogy akkor az működjön, az billentyűzetről működjön stb. stb. stb. És a negyedik az, ami nem is komponens, de szerintem azért fontos idehozni, és elkerülőnek mondanám, az az, amikor custom komponenseket kezdünk el gyártani. Amiről tudom, hogy néha van igény, és valamilyen más funkció hozza elő, megrendelői kívánalom, vagy egyéb más kívánalom, de nagyon sokszor amikor azt mondjuk, hogy van mondjuk egy gomb, HTML-ben, vagy van egy checkbox HTML-ben, és mi úgy döntünk, hogy nem azt használjuk, mert nem lehet formázni, mert nem jó, mert nem tudom, micsoda, tehát felsorolunk egy csomó információt, és úgy döntünk, hogy nekiállunk, és nulláról gyártunk egy checkboxot, nulláról gyártunk egy gombot. Na akkor veszünk a nyakunkba egy olyan hatalmas melót, amikor tulajdonképpen vagy nem törődünk az akadálymentességgel, és akkor átsiklunk rajta, és akkor ez fogja kihozni a különböző akadálymentességi hibákat, vagy azt mondjuk, hogy törődjünk vele, de akkor meg azért hullik a hajunk, hogy Jézus Mária, azért ebbe mennyi melót kell beletenni, és hány órát égettünk már el avval, hogy most az a szerencsétlen gomb működjön, de tudnunk kell azt, a kezdetkor, hogy ezt mi vállaltuk föl. Mi döntöttünk úgy, hogy nem a gyári jó akadálymentes checkboxot használjuk, ahol a Chrome meg a Microsoft meg a többiek megírták helyettünk annak az akadálymentességét, hanem úgy döntünk, hogy na, mi nulláról – egy span-ből – gyártunk itt egy checkboxot. Akkor vegyük tudomásul, hogy akkor azt nekünk meg kell hozzá írni mindent, ami azt akadálymentessé teszi. Ezt, ha lehet, akkor érdemes kerülni. De tudom, hogy sokszor erre nincs lehetőség, mert valami presszió van emögött.

Tibi: Sokszor üzleti igénnyel függ össze, tehát nyilván a natív elem nem tudja kielégíteni azt, ami a kérés.

Sz.K.: Igen, de szerintem azért érdemes hozzátenni, hogy nyilván ti is itt ebben a podcastben is sokszor foglalkoztok evvel, hogy azért érdemes kicsit egy utánkövetést végrehajtani. Tehát azt mondani, hogy nézzük már meg, hogy még mindig az van, hogy azt a gombot nem lehet formázni? Mert sokszor azért – valljuk be őszintén – a fejlesztőkben ilyen évekkel ezelőtti rossz tapasztalatok vannak, hogy ó, hát akkor nem lehetett formázni. Ha jól tudom, van egy baseline, aminek azt kell mondani, hogy működnie kell az ilyen és ilyen böngészőn. De azért érdemes néha utánanézni annak, hogy akkor na, akkor azt meg lehet-e már oldani? És akkor lehet, hogy már elkerüljük ezt a csapdát.

[Megszólal a műsor közeli végét jelző zene.]

Roli: Korábban említetted, hogy ugye október 21-én lesz a második Accessibility Meetup Pesten. Tudnál egy kicsit erről mesélni, hogy mi lesz most, és egyáltalán hogy jött az indíttatás a Meetup-ok szervezésére, és eddig milyen a tapasztalat?

Sz.K.: Igen, valóban, valamikor az év elején láttam, hogy esetleg erre a témára, erre az accessibility témára többen fogékonyak, és igazából nem tudtam elhelyezni. Többször előadtam például UX Meetup-on, ami ilyen szempontból ugye kvázi egy kistestvér, bár az Accessibility Meetup a kistestvére a UX-nek [nevet] – Budapesten a legnagyobb Meetup, úgy tudom –, hogy a nagyobbak között van, de mindenesetre többször volt ott előadásom, és nyilván oda olyan témákat tudtam vinni, amik UX-esek megközelítés szerint indítja az akadálymentességet. Ugye volt arról szó, hogy esetleg front-endeseknél is tartok, és akkor úgy gondoltam, hogy akkor talán jó lenne egy olyat, ami célzottan csak erről szól, és akkor idén volt az első alkalom, valamikor ugye tavasszal, és most a második alkalom ez ugye október 21-én lesz este fél 7-kor a NemAdomFel kávézóban, amiről annyit kell tudni, hogy autentikusan egy olyan hely ennek a rendezvénynek, tulajdonképpen házigazda szerepet, ahol megváltozott munkaképességűek a dolgozók is, tehát magát az egész kávézót, éttermet megváltozott munkaképességű emberek üzemeltetik, felszolgálástól kezdve a főzésen át mindenki ebbe a körbe tartozik. Szóval ott lesz maga a rendezvény. Alapvetően három előadásunk lesz. Az első előadásban pont a hallássérültek szemszögéből fogunk megnézni egy nagyon érdekes témát. A Siketek és Nagyothallók Országos Szövetségétől jönnek előadók. Elindult egy olyan kampányuk, ami arról szól, hogy hogyan lehet a hallássérültekkel pont így a jelnyelv kapcsán facebook-on, instragramon és egyéb ilyen közösségi médiában kommunikálni, mert szerintem ez egy nagyon fontos történet. Aztán utána jön Rolandnak az előadása, aki pont ugye az automatizált különböző tesztelésekről fog egy előadást tartani, amivel ugye pont azt feszegeti majd, hogy a buildek alatt hogyan lehet majd ezt az egész történetet megfogni, majd végül az utolsó előadást jómagam fogom tartani, amiben a kártyakomponensekről fogok beszélni, amit – azt tapasztaltam, hogy szinte nincs is olyan weboldal, ahol evvel ne találkoztam volna, ugye ami arról szól, hogy akár egy egyszerű híreknél – amikor van egy olyan oldal, hogy hírek –, és akkor alatta szépen látunk egymás mellett, egymás alatt dobozocskákat, ilyen kártyákat, amiben van valamilyen fotó, meg van hozzá valamilyen szöveg, esetleg valamilyen dátum, meg valami „tovább olvasom”, vagy „read more”, vagy bármi. S egy ilyen kis kártyának, egy ilyen kis dobozkának mennyi minden specifikációjának kell lennie ahhoz, hogy ez valóban akadálymentes legyen, tehát erről lesz a harmadik előadás. És előtte is, utána is nyilván van kötetlen hálózatépítés, meeting, meg egyéb beszélgetések lesznek, úgyhogy sok szeretettel várunk mindenkit, akit a téma érdekel. Most már eléggé fogynak a helyek, úgyhogy érdemes gyorsan lépni. Terveink szerint ugye ezt folytatnánk tovább, negyedévente körülbelül egy-egy előadássorozattal.

[Megszólal a műsor zárását jelző zene.]

Edu: Nagyon szépen köszönjük Karesznek, hogy bejött hozzánk, a podcastbe, és eléggé sokat tudott nekünk mesélni, viszont igazából eléggé sok infó van, és eléggé sokáig beszéltünk vele, úgyhogy ezt az adást, vagy ezt a témát fogjuk szétbontani két adásra, és majd legközelebb is, a következő adás is erről fog szólni, amelyről ti fogtok minket tovább hallgatni, amiről mi beszéltünk eléggé sokáig. Ennyi fért bele ebbe az adásba, ha van valami ötlet, kérdés vagy visszajelzés, akkor nyugodtan írjatok nekünk facebook-on, twitteren vagy akár e-mailben, és hallgassatok minket legközelebb is! Sziasztok!

[Befejező zene szól.]

Második rész

[Bevezető zene szól.]

Edu: Sziasztok! Ez itt a DevTales 54. adása. Velünk van Szántai Karesz, Tibi, Roland, Róka

Róka: és Edu. Ebben az adásban megnézzük, hogy mi a helyzet a reszponzív weboldalakkal, illetve mi a helyzet azokkal, akik nem kifejezetten látásukban sérültek, hanem esetleg mozgás, vagy a hallás okoz nekik nehézséget, illetve az animációkról is beszélünk egy picit.

Róka: A hosszú szövegekkel van valamilyen probléma? Tehát hogyha valahol egy ilyen nagyon hosszú nyomtatványforma, vagy valamilyen szerződési feltételek vannak.

Sz.K.: És ez a szöveg megjelenik a képernyőn, mint hosszú szöveg? Erre gondolsz?

Róka: Igen.

Sz.K.: Hát, igazándiból most így hirtelen nem nagyon tudnék. Önmagában az, hogy hosszú a szöveg, az értelmezhetőségén kívül – nyilván a jogi szövegnél ezt nem lehet rövidíteni [nevet], furcsa is lenne –, talán az jut eszembe, hogy a szövegeknél vagy a szövegelemeknél a rugalmasságot szoktam javasolni; arra érdemes odafigyelni. Mit értek ez alatt? Tulajdonképpen arra kell odafigyelni, hogy egy látó felhasználó számára elképzelhető, hogy az olvashatóság miatt ő valamilyen machinációt csinál a böngészőjében. Fölnagyítja a szöveget, esetleg átállítja a térközt, sorközt, vagy bármi más tipográfiával kapcsolatos funkciót bekapcsol. Még az is elképzelhető, hogy nagyon sok – például diszlexiás felhasználók vagy olvasási nehézséggel küzdő – felhasználók számára az adott betűtípus nem megfelelő, és akkor ilyenkor ő a böngészőben bekapcsol egy saját olyan betűtípust, ami számára jól olvasható. Ugye sokan röhögnek mondjuk a Comic Sans-en, de bizonyos felmérések alapján egészen jól olvasható, ha ezt a témát vesszük elő. De mindenesetre bekapcsol egy egyedi betűtípust, egy egyedi betűméretet, egy egyedi sortávolságot, na és akkor kérdés az, hogy mi történik evvel a szövegdobozzal, vagy ezzel a szövegelemmel. Hogy mennyire van ez befixálva. Sokszor tapasztalom ilyen vizsgálatok alapján, hogy például egy olyan divbe vagy olyan elembe van beletéve, amelyiknek meg van adva a fix mérete. 180-szor 415 pixel, pont. Ha abba nem fér bele, akkor kész. És akkor ilyenkor lehet overlapping, kinyúlik a szöveg, beletakar egy másik szövegbe, tehát nincs meg az a rugalmasság, hogy a user ezt állítgathassa. Én szoktam mindig mondani, hogy a reszponzivitás fogalmában, sokszor azt gondoljuk, hogy a reszponzív weboldal az azt jelenti, hogy működik mobilon. Meg működik táblagépen. De a reszponzivitás az én akadálymentességi felfogásom szerint azt jelenti, hogy az oldal alkalmazkodik a felhasználó egyedi igényeihez. Tehát legyen kellőképpen rugalmas – akár a méretezésében, akár a betűtípusában – ahhoz, hogy ha a user megváltoztat valamit egyedileg, akkor erre ne dobjon egy hátast a weboldal, és ne mondja azt, hogy ezt én nem tudom megtenni. Ugye nagyon sokszor van ez a kontrasztosság kérdése. Ez egy jó példa arra, hogy nagyon sokszor azon görcsölnek fejlesztők, hogy akkor most tegyünk bele oda valami gombot, ami kontrasztossá teszi, feketére, sárgára. Ugye azon kívül, hogy ez a fekete-sárgaság eleve egy teljesen fals történet, hiszen ez azt jelentené, hogy mintha a világon minden gyengénlátó embernek ez a fekete-sárga lenne a tuti,

Róka: [szavába vágva] Ez hogy terjedt el?

Sz.K.: Hát, igazándiból úgy terjedt el, hogy a gyengénlátók számára valóban probléma lehet az, hogy a világos háttér az idézőjelben „vakít”. Tehát a gyengénlátó felhasználó, akinek valamilyen maradék látása van, számára ugye sokkal könnyebb megtalálni egy sötét háttéren a világító elemeket, világító szövegeket, mint fordítva, mert akkor egyébként elvakítja a képernyő. Teszem hozzá zárójelben, most mekkora hype van a dark témák körül? Gondoljatok bele. Hát én magamban röhögök, hogy most olyan szintű energiákat nyomnak bele, hogy ú, dark, az én honlapomon tudja a dark mode-ot, és tulajdonképpen ha belegondoltok, most vitatkoznak fejlesztők, hogy ugye nekem kényelmesebb-e a fekete háttéren kódolnom, vagy nem, hát kérdezd meg akár itt a Shiwánál a kollegákat, hogy ki miben szeret kódolni. Na ugyanez a történet. Nincs két egyforma ember, két gyengénlátó ember sem egyforma, van, akinek a fekete jó háttérnek, valakinek kicsit egy sötétebb háttér, vagy kékebb háttér, változik. Az a lényeg, hogy nem tudsz neki egy tuti megoldást adni. Helyette sokkal jobb, hogy azt mondod, hogy nem tudom, hogy az illető milyen színt fog használni. Például a Windowsban be tudod ezt konfigurálni, mikor átkapcsolsz high contrast módra, akkor ott szépen a user be tudja konfigurálni, hogy nekem az ilyen színű háttér, ilyen színű betű, ilyen színű keretekkel, ez a jó, ezt tudom én elolvasni. Az a jó honlap, amelyik ezt tolerálja. Amelyik azt mondja, hogy oké, akkor az én oldalam így fog kinézni. És akkor így fogja használni. Ez a jó megközelítés. És mindenben – akár a betűméretállításban, akár a többi ilyen feature-ben – ez a legfontosabb, hogy ezt értjük reszponzivitás alatt. Nagyon fontos az is, hogy a klasszikus reszponzivitás – ez is úgy néha előjön – hogyha például egy user elkezdi ctrl plusszal növelni a betűméretet – ugye régebben a böngészők csak a betűméretet engedték növelni; ugye az Opera volt az első, amelyik megengedte a full zoomot, ma már ugye általában a full zoom van benne a böngészőkben, bár elő lehet csalogatni egyébként valamilyen control vagy más billentyűkombinációval azt, hogy újra csak a betűméret növelődjön –, de visszatérve, elkezdem növelni control plusz, control mínusszal, és ugye olyan a reszponzív oldal, amelyik egyszer csak úgy átvált a következő breakpointnál mondjuk egy táblagép nézetre, aztán még tovább nyomom, akkor átvált mobilra, és ebben a pillanatban tulajdonképpen az történik, hogy én a mobil nézetet látom desktopon. Ugyanazt a reszponzív oldalt. És akkor ilyenkor fontos, amikor mondjuk én megjegyzést teszek egy auditban, egy vizsgálatnál, hogy nem látszik a tabulátor fókusz a mobil nézetben. Na erre jönnek a fejlesztők, hogy miért kéne tabulátor fókuszt látni mobilon? Hát ott mindenki tapicskol. Nade hát erről beszélünk: itt egy olyan userről beszélünk, aki fölnagyítja a képernyőjét, a desktop képernyőjét nagyba, megjelenik a reszponzív oldal, és onnantól kezdve ugyanúgy használni fogja azt az oldalt, és ott neki szüksége lesz arra, hogy mondjuk látszódjon a fókusz, vagy működjön az egérkattintás, vagy ne minden swipe-ra legyen leprogramozva. Ez ilyen szempontból biztos, hogy fontos, arról nem is beszélve, hogy vannak olyan mozgássérült felhasználók, de még a látássérültek között is néhányan, akik bizony billentyűzettel, bluetooth-os billentyűzettel használják az android eszközt. Vagy az iOS eszközt. És abban a pillanatban ugyanannak a funkciónak működnie kell. Ugyanúgy látnom kell, mikor nyomogatom a tabot, hogy hol van a fókusz. Tehát nem lehet ilyen prekoncepcióból kiindulni, hogy akkor csak és kizárólag a mobil képernyőn az a mobil nézetben, a mobil eszközön fog megjelenni. Tehát szerintem a reszponzivitás mindenképpen fontos, hogy evvel így kalkuláljunk, hogy tudjak hozzá, a userhez alkalmazkodni. Ugye egyre több ilyen – bocsánat –, egyre több CSS media query van evvel kapcsolatosan, ha megnézitek, akkor számtalan jön elő akár így a dark mode kapcsán is, de most már ugye ott tartunk, hogy lassan a környezeti fényt tudja detektálni majd az eszköz, meg a high contrast az például nagyon hiányzik, hogy az bevezetődjön. Jelenleg ugye azt, hogy a user átkapcsolt-e high contrast módba, ezt jelenleg ugye egyedül csak a Microsoft Explorer és társai tudják. Az ms-high-contrast névre hallgató kis media query tudja ezt megtenni. De a többinél is nagyon-nagyon jó lenne, mert jelenleg csak mindenféle java scriptes kis detektáló scriptekkel lehet ezt eljátszani, hogy én akkor megtudjam, hogy a user átkapcsolt-e.

Tibi: High contrasthoz csak kiegészítés, ugye beszéltünk a színekről, meg az átszínezésről, tehát hogy beállíthatod, hogy abban az üzemmódban neked hogy néz ki az oldal, ott egyébként pluszban így tapasztalat alapján azért még elég sok mindenre kell figyelni, tehát olyan dolgokra, hogy adott esetben mondjuk egy box-shadow, vagy egy border, ami alapból nincs az elemen, de high contrast módban kell, hogy látsszon az elem, tehát hogy ilyen plusz dolgokat rá kell így pakolgatni elemekre, mert különben ahogy átkapcsoljuk a színeket, pont azért, mert mondjuk egy – nem tudom, egy világos sárga meg egy fehér elem volt egymáson, ami nyilván most így kontraszt szempontból nem jó, de tegyük fel, így volt alapból –, viszont ahogy átkapcsolunk high contrast módra, mind a kettő fekete lesz mondjuk, onnantól kezdve a kisebbik elem, ami benne van, az nem látszódik. És ezért úgymond ilyen rejtett bordereket kell belepakolgatni, amik alapból mondjuk transzparensek az elemek. Tehát ilyen plusz tapasztalatok azért előjöttek nálunk bőven, amikre így kellett pluszban odafigyelni.

Sz.K.: Igen, a high contrastnak ez egy ilyen története. Az alaptézis az az – és jó, hogyha mindenki tisztában van evvel –, hogy ugye a high contrastnak az egyik alaptörvénye, hogy a background image-ek eltűnnek. Tehát mindent, amit CSS background-image-ben definiáltál, az a high contrast módban kuka. Ahogy mondtad, Tibi, alapvetően az összes egyéb színezés is, a background-color-ok is eltűnnek. Valóban marad a szövegszín, meg esetleg az elemszín, és ott a borderekre korlátozva, valóban a bordereknek a különböző színeivel lehet játszani, és valóban erre úgy föl kell készülni. Tehát ez tényleg egy olyan folyamat, amit szerintem tényleg nagyon kevesen kezdenek el tervezni akár UI szinten is, hogy mi van, ha egy user átkapcsol. Evvel kapcsolatban hadd mondjak nektek egy érdekességet. Múlt héten hallottam – a Twitteren olvastam talán –, hivatalosan Microsoft forrás, hogy jelenleg a világon futó Windowsos gépeknek négy százaléka high contrast módba van kapcsolva. Azért az elég nagy történet, úgyhogy erre mindenképpen érdemes odafigyelni. Ugye annyit csinált most az Explorer – pontosabban régóta működik náluk az –, hogy be tudod kapcsolni, hogy kéred-e, hogy a background image-t mégiscsak mutassa. A többiek esetleg levágják így ámblokk, de ott van egy ilyen kapcsoló, a user által így preferenciaként bekapcsolható. De érdemes valóban odafigyelni arra, hogy ezek az elemek ilyenkor is jól működjenek, és meglegyen a keret, és megfeleljen az ilyen történet, tehát ebbe valóban bele kell tenni ilyen szempontból egy kis erőforrást.

Edu: És ugye említetted, hogy a fejlesztők általában nem úgy tesztelik a dolgokat, mármint fejlesztés közben nekik van valami flow, és mondjuk amit mondtad, hogy a fókuszra nem fog gondolni úgy a mobilon, hogy legyen fókusz, és erre van valami checklist, vagy valahol ezeket meg lehet tanulni? Tudsz adni valami tanácsot?

Sz.K.: Hát igen, ez egy nagyon érdekes dolog. Ugye sose felejtem el [nevet], mikor először szakmai kapcsolatba kerültem veletek, akkor is ugye ez volt rögtön az első kérdés, hogy oké, tudjuk, hogy van ez a WCAG történet, amibe belelapoztunk, két oldal után azt mondtuk, hogy köszönjük, ugye – nem tudom – szerintem kinyomtatva nem is tudom hány száz, vagy ezer oldal lenne, tehát ez oké, de szűkítsük le ezt egy checklistára, egy A4-es oldalra. Ez minden ügyfelemtől szinte, akivel kapcsolatba kerülök, előjön, hogy akkor ez oké, WCAG van, de csináljunk ebből valamit. Keringenek a neten egyébként ilyen teljesen favágó szintű alap történetek, hogy ezt nézd meg, ezt nézd meg, ezt csekkold ki, ezt csekkold ki, de az a probléma ezekkel, hogy nagyon sok elágazás van. Ha most visszatérünk erre az altra, akkor most mit írsz egy checklistára? Most azért, mert egyszer mondtad, hogy igen, legyen alt; de nem igaz, mert legyen alt, ha; ha meg nincs, akkor meg ez legyen. Tehát iszonyat folyamatábrákat kellene rajzolgatni talán, amitől ez jobb lehet. A másik ugye – most a high contrastra visszatérve –, nagyon furcsa dolog, de képzeljétek el, hogy alapvetően a high contrast módban való működtethetőség nincs benne a szabványban. Tehát amikor arról beszélünk, hogy audit, meg UX, akkor például nekem nem tudom – idézőjelben – „megreklamálni”, hogy akkor kérem szépen, ez azért nem akadálymentes, mert high contrast módban nem működik. De mégis beleteszem egy olyan pontként, olyan megjegyzésként, hogy viszont nagyon sok-sok embert érint, tehát javaslom megfontolásra, hogy UX szempontból igenis tessék megnézni, hogy működik-e high contrast módban, de így, ab ovo nincs benne checkpointként. Tehát mondhatja azt az ügyfél, hogy engem ez most ilyen szempontból nem érdekel. Ezért ezeket a checklistákat én igazándiból nem tudom jó szívvel ajánlani, hogy igen, a netről töltsél le egy akármilyen checklistát, hogy akkor ezen végigrohanj. Igazándiból a nagyon durva checklistákat ezek az automatikus rendszerek megcsinálják. Tehát ha például egy olyan flowban dolgozol, ahol be tudsz húzni egy olyan ellenőrzőrendszert, amelyik mondjuk egy ilyen build alatt, észrevétlenül a buildben megcsinálja neked és lefuttatja ezt a kétszázvalahány ilyen történetet, checklistaszerű algoritmizálható dolgot, akkor már előbbre vagy, az biztos, de nagyon-nagyon-nagy lenne azért ez a checklista, hogy akkor mobilon volt a fókusz, bla-bla-bla-bla, és akkor mindent egyesével végig kell nézni, én erre nem nagyon tudnék jó példát mondani. Amikor az ember elszörnyülködik a WCAG-nál, akkor mindig azt tudom mondani, hogy ne a WCAG-ból induljunk ki. A WCAG pontok önmagukban, ugye teljesítési feltételek vannak a WCAG-ban – ugye a teljesítési feltételek alatt azt értjük, hogy ha az adott oldal azt a feltételt teljesíti, akkor abban a pontban jó –, a WCAG-ban van egy olyan rész, amelyik ilyen technikákat. Egyrészt van benne egy olyan rész, amit úgy hívnak, hogy Understanding, ugye, hogy értsd meg, hogy ezt miért tettük oda bele. Mi annak a háttérsztorija. Miért lett az egyáltalán kitalálva. De ott vannak technikák. És én azt szoktam a fejlesztőknek javasolni, hogy inkább abban érdemes böngészni. Nagyon szépen le van bontva HTML-technikákra, CSS-technikákra, JavaScript-technikákra, jó, hát a Flash már nem érdekes, de Flash-technikák is vannak benne, meg Silverlight meg nem tudom, micsoda, mert abban vannak olyan pontok, amik akár checklistaszerűen azt megmutatja neked, hogy nézd meg a kódot, van-e benne ilyen elem. Ha van, akkor nézd meg, hogy ezt tudja-e, ha igen, akkor jó vagy. Ha nem, akkor nem. Tehát ez biztos, hogy jópofa dolog lehet. A harmadik, amit tudok ajánlani, ezt jó szívvel, azok általában, ugye ha most így beszélgetünk komponensekről, meg ugye mindenféle olyan módszertanokról, amelyik ugye ebből indul ki, hogy ilyen komponensekből építkezel, widget-ekből építkezel, akkor nagyon sok olyan forrásanyag van, ahol a komponensekről van egy jó kis leírás. Van a W3C-nek is – ugye amelyik a WCAG szabványnak ilyen szempontból a megalkotója –, nekik is van egy olyan tutorialjuk, olyan pattern gyűjtemény, amiben az összes ilyen klasszikus pattern a tabos interfésztől a carouselen át a – mittudomén – az accordionokon keresztül szépen leírja, hogy mit kell csinálni. És akkor azon ha egyszer végignyálazza magát valaki és így csinál arra egy pattern library-t, utána már csak azt húzogatja be, akkor igazándiból már nem kell azon agyalni, hogy akkor működik-e majd a fókusz vagy nem. És van egy másik – az is ilyen Inclusive Components, ugye az is egy nagyon jó gyűjtemény –, amelyik szintén különböző ilyen patternöket gyűjt össze. Tehát én azt mondom, hogy érdemes azokból forrást meríteni, és nem feltétlenül a WCAG szabvány felől kell ezt megközelíteni, hanem ezekből a patternök irányából.

Roli: Beszéltünk az előbb erről a high contrast módról, ugye hogy csak Edge-ben meg Explorerben érhető el, viszont ugye most már az Edge közelít ahhoz, hogy átáll a Chromiumra, és ugye fölröppentek olyan hírek is, hogy például a high contrast módot implementálják Chromiumos böngészőkben is, és hogy szerinted milyen irányba fogja vinni az egész WCAG-t vagy a webstandardeket ez a Chromium egyeduralom?

Sz.K.: Hát, ez egy érdekes kérdés, mert historikálisan nézve, bármilyen furcsa is, de mondjuk a felmérések alapján a vakok körében – és ez akár Magyarországot nézzük, akár világszerte – a vakok körében például nem a Chrome volt az elsődleges böngészőprogram. Ennek az oka egyszerű volt: a felolvasószoftverek, képernyőolvasó szoftverek egyszerűen nem voltak kompatibilisek a Chrome-mal, tehát hiába volt az, hogy az összes analitika azt adta, hogy a Chrome már toronymagasan a legismertebb meg leghasználtabb böngésző, bizony képernyőolvasós userek körében még akár az Explorer, vagy később – vagy párhuzamosan – a Firefox volt, ami előre tört. Ma már azért azt kell mondanom, hogy a Chrome egészen jól kezdi gatyába rázni magát. Tehát nekem is több ismerősöm – vak ismerősöm – már mondta, hogy igen, ő eddig Explorert használt, de most már kezd átállni Chrome-ra, és felejtős az Explorer, tehát egy idő után azért el fog tűnni, de a legfrissebb statisztikák alapján is azért még az Explorer ott van egészen magasan, jóval magasabban. Azt, hogy utána hogy most az Edge Chromium alapú lesz-e vagy nem, ennek biztos, hogy lesz előnye. Mert azért nagyon sok esetben azért a Chrome nagyon sokszor viszonylag modern feature-öket is elég hamar implementál, s a többiek meg kullognak utána, tehát ez szerintem pozitív változást fog hozni. Azt, hogy az érintettek körében egyébként az Edge-nek a népszerűsége megnövekszik-e vagy sem ettől függően, ezt nem tudom neked megmondani. Szerintem egyébként nem, de ez egy ilyen teljesen privát megérzés, privát vélemény. Tehát szerintem marad a Chrome-nak illetve a Firefoxnak a dominanciája. Illetve a Safarié, mert arról ne feledkezzünk el, hogy ha a mobilos világot nézzük, és mondjuk a felolvasószoftverek világát nézzük, akkor toronymagasan az iOS vezet, hiszen az iOS volt, amelyik nulláról, az első verzió kiadásakor már marhára akadálymentes volt, az Android nagyon kullogott utána, jóval utána, tehát ma a statisztikák alapján sokkal nagyobb a user bázisa ilyen szempontból az iOS-nek, legalábbis így látássérültek, vakok körében biztosan. De például most a mozgássérültek is ugye eléggé előre törnek olyan tekintetben, ami viszont – nem tudom, tudjátok-e – hogy pont így ebben a legújabb iOS-be, a MacOS-be bejött a hangvezérlés, mint lehetőség, amire ugye nagyon sokszor nem is gondolunk, hiszen sok mozgássérült felhasználó hanggal vezérli a gépet, vagy a böngészést. És akkor innentől kezdve előjön egy csomó olyan funkció, amire eddig nem is nagyon gondoltunk, pedig érdemes rágondolni, hogy mondjuk ott van egy gomb, a képernyőn, amin van egy ikon, és akkor meg kell szólítani. Tulajdonképpen neki azt kell mondani, hogy megnyomom a – és akkor milyen gombot? Mit mond ő? Azt, ami rajta van, azt az i-betűs gombot? Vagy azt az x-et? Nagy vita volt erről, hogy például a lezáró, egy modulnak a sarkán az most mi? Az x? Vagy micsoda? Mondja azt, hogy megnyomom az x-et? Vagy az most hogy van? Ugye nagyon furcsa, és ezért a WCAG-ban most már van is egy olyan, a WCAG 2.1-be bekerült egy olyan pont, ami arról szól, hogy ugye ha van egy interaktív elemed, és ha azon van egy szöveg – tételezzük fel, hogy nem egy ikon, hanem egy szöveg, mondjuk hogy rendben –, akkor ugye mindenképpen annak a gombnak az akadálymentes neve; ami az akadálymentes neve, vagy az a gombnak a felirata, vagy hogyha elővesszük az aria-label és társait, akkor ugye elképzelhető, hogy te mondjuk látsz egy gombot, aminek az a neve – ki van írva –, hogy „Mehet”, de a gombnak az aria-labeljében meg az van, hogy „Start”. Most egy nagyon durva példát mondok. Akkor ugye ez a látó user azt fogja mondani, hogy Megnyomom gomb Mehet. És nem történik semmi, mert a gombnak az akadálymentes neve az, hogy „Start”. Ugye ezért ez a WCAG-szabványban ez benne is van, hogy mindenképpen legyen az akadálymentes névben is benne az a szöveg, amit lát a user. Mert azt úgy fogja megszólítani az adott komponenset. Létezett egyébként ez a technológia már régebben is, tehát voltak ilyen third party megoldások, de evvel, hogy most a macOS, iOS behozta ezt így a köztudatba, ez nagyon klassz. Jó, persze, hozzáteszem, létezik olyan, hogy ha nem tudja már megszólítani, vagy több egyforma gomb van, akkor ez a rendszer, ez a Voice Control rendszer megszámozza a gombokat. Tehát odatesz minden egyes elemre egy számot, és akkor az illetőnek már azt kell csak mondania, hogy megnyomom a gombot, és akkor az 5-öst. Persze előjön megint az a kérdés – s amit ugye mindig elmondok –, hogy nem elég, ha valami annak látszik, annak is kell lennie. Tehát lehet, hogy a dizájnban, a látványban az egy gomb, szegény user azt fogja mondani, hogy megnyomom azt a gombot, és kiderül, hogy az nem egy gomb, az egy div, egy valami onclick-kel ellátott div, és akkor ő hiába magyarázza; akkor ez akármilyen hiper-szuper heurisztika van, nem fogja azt gombként érzékelni, nem fogja tudni a user megnyomni azt a gombot.

Tibi: Az ilyen típusú felhasználóknál, akik hangvezérléssel próbálnak böngészni, az nagyon elborult ötlet lenne – vagy igazából nem tudom, hogy hogy működnek az ilyen szoftverek, de – hogy ott akár nem működhetne az, mint a normál felhasználó esetében a tabozás? Tehát mondjuk azt mondanám, hogy tab, tab, tab, és akkor úgy lépkedek interaktív elemeken, és ha most odaírják valahova, látom, hogy hol a fókusz, és akkor azt mondom, hogy click? [együtt nevetnek] Most ez így eszembe jutott.

Sz.K.: Lehet, lehet, lehet, lehet. Nézd, az a nagy helyzet, hogy mivel ezek a rendszerek – és őszintén bevallom, nekem is viszonylag kevés ebben a tapasztalatom, egy marha egyszerű okból fogva, mert nem voltak ilyen rendszerek elérhetőek mondjuk magyar nyelven, tehát jellemzően ez azért angol nyelvterületeken működőképes ez a dolog. De persze, létezik ilyen, és most is van ilyen, ez az úgynevezett Switch Control, hiszen vannak olyan userek – szintén mozgássérült userekről beszélünk –, akik ugye úgy használják a számítógépet, hogy nem a tabot nyomkodják, hanem egy darab gombot. Az az egy darab gomb lehet, hogy a lábuknál van, lehet, hogy a hónaljuk alatt van beszorítva, lehet, hogy a fejükön van, vagy fejük mellett van a kerekesszéknek a hátán, vagy gondoljatok Stephen Hawkingra, vagy bármi, és akkor ebben az esetben ő egy diszkrét „megnyomom, megnyomom, megnyomom, megnyomom”, nem tudja megmondani, hogy tabot nyomok, vagy space-t, nyomok valamit, és akkor ezek az úgynevezett controllok úgy néznek ki, hogy megmutatják neked az opciókat, hogy végigmegy ilyen szekvenciálisan, és akkor fölvillan az az elem, na akkor nyomok még egyet ezen a gombon, és akkor az működőképes lesz. Ez be van építve nagyon klasszul a macOS-be, Androidba, iOS-be, ez már viszonylag régóta működő történet. Nagyon nehéz vele boldogulni úgy; hát nehéz... Minden relatív. Az illetőknek ez az életet hozza el. Nekünk épeknek, akik nem ilyen módon használjuk ezt, nyilvánvalóan nehéznek tűnik, de inkább legyen nehéz, mint a semmilyen. És akkor ebből kell kiindulni. De lehet.

Edu: Amit itt az Apple mutatott a saját prezentáción, ez a Voice Control úgy néz ki, hogy minden interaktív elemmel mellé megjelenik egy ilyen kis labelke, és akkor felhasználó tud elmondani, hogy most nekem ez a label alapján most nyomja ezt a gombot, vagy valami mást. És eléggé érdekes megoldás volt a térképnél, legalábbis itt amit a képen találtam, hogy a térképnél megjelenik egy ilyen feltérképezett...

Sz.K.: [szavába vágva] Egy grid.

Edu: Egy grid, igen, és akkor így ez alapján lehet mondani, hogy ennél a cellánál most szeretnék nagyítani, vagy...

Sz.K.: [szavába vágva] Bizony, bizony.

Tibi: [szavába vágva] Koordináta rendszer alapján...

Sz.K.: [szavába vágva] Igen, igen. Ha belegondoltok, akkor tulajdonképpen egy mozgássérült felhasználó számára a térkép az egy eléggé durva dolog, hiszen azért azt nem lehet föltabozni, vagy nagyon furcsa lenne, hogyha azt föltaboznánk. Ez mindig előjön, hogy a Google térkép az akadálymentes-e vagy nem, mert mit tud csinálni? Plusz-mínusszal tudja nagyítani-kicsinyíteni, de már eltologatni a képernyőn magát a térképet, nem egy egyszerű dolog, de ez a megoldás valóban olyan esetekben, amikor nem lehet mást bevetni, akkor rávetít egy ilyen gridet, és akkor az alapján tudja használni. Egyébként a Switch Controlban is van egy ilyen funkció – ezt is kevesen tudják, hogy ez is tök jól működik –, ott meg ugye az történik, hogy ott is lehet, hogyha te mondjuk a kurzort – az egérkurzort – át akarod vinni az A pontból a B pontba a képernyőn, és akkor az történik, hogy fogom magam, megnyomom ezt a gombot, ezt a Switchet – tételezzük fel mondjuk, hogy ez a fejem mögött van, tehát rányomom a fejemet – , és akkor tulajdonképpen elindul a képernyőn szintén egy ilyen csík, vagy egy sáv, szépen balról-jobbra lassan mozog, és amikor elérkezik az a sáv arra a területre, ahova én át akarom tenni a kurzort, akkor megint megnyomom a gombot. Akkor az befixálja, hogy na, akkor oké, vízszintes koordináta megvan. Elindít egy függőleges sávot, az lesz a függőleges koordináta, megint akkor kell megnyomnom a gombot, amikor odaértem, és miután megvan a vízszintes meg a függőleges sávnak a metszéspontja, akkor szépen a kurzort odaviszi az operációs rendszer, és máris ott tudok valamit machinálni. Tehát ez egy szenzációsan okosan kitalált sztori, nagyon hasonlít erre a grides megoldásra.

Róka: Említetted a térképet. Ott tök sokszor találkozunk olyannal, hogy például nagyításnál animálódik az egész. Weboldalon okozhat gondot az, amikor animálódik? Bármi, például egy label, meg a placeholder ugye felcserélődik, kiugrik a placeholder a label helyére?

Sz.K.: Hát alapvetően azt szoktuk mondani, hogy a diszkrét, finom animációkkal talán nincsen probléma. Itt a durva, hosszú ideig tartó, nagyon látványos, nagyon ilyen szembetűnőnek szánt animációkkal bizony van. Sőt, leginkább itt igazából olyan felhasználókról beszélünk, akire nem is gondolnánk, és nem is sorolnánk őket fogyatékos felhasználók kategóriába. Ugye itt beszéltünk a figyelemzavarról – amelyik egy eléggé elterjedt probléma felhasználók esetében, fiatalok körében, gyerekeknél is sokszor, de felnőtteknél is –, egyszerűen arról van szó, hogy a képernyőn ő lát valahol egy izgő-mozgó, jövő-menő elemet, akkor egyszerűn képtelen a figyelmét arra összpontosítani, amire ő szeretné. Mindig el fog menni a figyelme annak az elemnek az irányába. Tehát magyarul vagy azt kell csinálni, hogy le kell kapcsolni azokat az elemeket, amit ugye megint a böngészőben elvileg meg tud tenni, ha nagyon akarja, vagy pedig – és ez a legfontosabb – ezeket az elemeket leállíthatóvá kell tenni. Lásd carousel. Lásd heroképek. Ugye úgy szól a szabvány – és ez a WCAG-ban le van specifikálva, tehát ez egy igen fekete-fehér kérdés –, hogyha van a képernyőn egy ilyen nagy animáció, egy nagy carousel, vagy egy nagy herovideó mondjuk a háttérben, akkor igenis ott kell lennie olyan mechanizmusnak – legegyszerűbb esetben egy gombnak, egy play/pause gombnak – a képernyőn, az interfészen, amit megnyomhat a user, és leállíthatja ezt a mozgást, hogy kényelmesen el tudja olvasni a maradék szöveget. De van olyan felhasználó is, ahol – és erről a legutóbbi Budapest Accessibility Meetupon volt is egy előadásom, a youtube-on ez visszanézhető –, ugye ebben van egy olyan probléma, amikor az illetőknek tulajdonképpen az egyensúlyi rendszerben, a vesztibuláris rendszerükben van egy olyan elváltozás, amit ugye úgy szoktunk hívni, hogy mozgási betegség, ahol bizony nagyon durva, és bizonyos klasszikus mozgásokra az illető egyszerűen rosszul lesz. Tehát elkezd émelyegni, elkezd fájni a feje, és egyszerűen nem bírja hosszú ideig nézni. Ugye klasszikusan a parallax oldalakat szoktuk említeni erre, mikor ugye a képernyőn egy olyan típusú mozgás van, ami a mozgást imitálja – bizony ez is lehet probléma –, és itt is visszakanyarodunk arra a reszponzivitásra, hogy ma már van arra lehetőség, hogy a user a macOS-ben, a Windowsban becsekkolja azt, hogy én nem szeretnék ilyen típusú mozgásokat látni, és akkor erre a front-endes egy media query-vel azt tudja mondani, hogy jó, egyébként van egy animációnk a képernyőn, de ha be van ez csekkolva, akkor ezt nem használom, vagy ezt leállítom, vagy eltüntetem, vagy bármi. De mondom, a finom animációkkal nincsen probléma. De ne gondoljuk azt, hogy... Sokszor megkérdezik tőlem, hogy az akadálymentes weboldal az unalmas? Az mindenképpen csúnya lesz? Annak feketének kell lenni, abban nem lehet animáció, abban nem lehet kép, tehát jön mindenféle dolog. És ez nem igaz. Tehát egyszerűen lehet trendi, klassz dizájnt csinálni, csak oda kell ezekre a finomságokra figyelni, hogy mi van akkor, hogyha a usernek ez mégsem annyira működőképes.

Tibi: Még az animációkhoz tartozó téma, hogy régebben honlapfejlesztéskor volt egy olyan esetünk, hogy össze lehetett gyakorlatilag konfigurálni egy csomagot, amibe be tudtál tenni megfelelő funkciókat, és amikor te egy újabb funkciót tettél bele abba a csomagba, akkor a UI-on egy adott elemnél ugye kiírtuk, hogy na most hány elem van benne a csomagban, és ahogy bekerült egy újabb elem, a szám egyrészt változott, másrészt így a szám körül egy ilyen színes kör alakú valami így elkezdett, hát, pulzálni, vagy nem tudom, hogy hívjuk; ez például zavaró lehet ilyen szempontból?

Sz.K.: Igazándiból ami klasszikus akadálymentességi – hát nem zavaróság, hanem – hiba lehet, az a villogás bizonyos frekvencia fölött, és ott is jellemzően a piros szín, ami előjön, és az is nyilvánvalóan attól függ, hogy mekkora területét érinti a képernyőnek. Itt ugye arra gondoljatok, hogy hány olyan ember van, fiatalok, akik tizenvalahányévesen életében először elmegy koncertre, és az a pulzáló fény minden koncerten – mentős kollegák szokták nekem mesélni, több kapcsolatom is van mentősökkel, ők szokták mesélni –, hogy rendszeresen ilyenkor ki kell emelni ugye a tömegből a gyerekeket, mert életükben akkor találkoznak először stroboszkóppal, és nem is tudtak arról, hogy ők érzékenyek erre. Hogy a villogástól egyszerűen egy „epilepszia-szerű”, eldobják magukat. Ugye régebben volt valamelyik Pokemonban volt az – az egyik ilyen japán rajzfilmben –, akkor bemutatták az egyik részét, és abban volt egy robbanás, amit így piros pulzálással mutattak a képernyőn, s aznap több száz, vagy több ezer gyerek Japánban dobott hátast szinte, mert nem tudták a szülők sem, hogy a gyerek érzékeny erre. Tehát weboldalakon ilyen típusú nagyon durva villogást – főleg pirost –, bizonyos frekvencia fölötti villogást egyszerűen nem szabad. De ez ritka. Ma már. Régebben volt ilyen. De amit említettél, ez a pulzálás jó lehet, itt az a kérdés, hogy nem-e kontraproduktív. Ugye szokták mondani UX-esek – UX-ben van ez a fogalom, hogy változás-vakság –, hogy lehet, hogy pont az a lényeg, hogy kiemelődjön, és pont kontraproduktív lesz, hogy marhára nem fogják észrevenni. Ugye gondoljatok arra a klasszikus videóra, amikor ugye a kosárlabdázók vannak, és akkor dobálgatják a kosárlabdát, és akkor átmászik hátul a King-Kong, és akkor mi történt? S ha nem akkor koncentrálsz, akkor az biztos, hogy előjöhet. Önmagában persze ez nem biztos, hogy zavaró, tehát lehet ez egy jó kis effektus, amelyik ezt előhozza, de ti is tudjátok, nagyon sokszor van az, hogy az ügyfél mindent ki akar emelni. Tehát akkor emeljük ki ezt is, emeljük ki azt is, a végén minden ki van emelve, tehát semmi nincs kiemelve a képernyőn. Ellenben viszont jó, hogy mondtad ezt a villogást, meg ezt a kiemelést, mert például ugyanez a funkció egy vak felhasználó számára, amikor a felolvasószoftvert használ, na ez egy olyan dolog, amire neki biztos, hogy szüksége van, hogy amikor bekerült egy termék a kosárba, akkor te elkezded ott villogtatni a UI-on, mint látóként, de őneki fogalma se lesz erről, hogy bekerült ez a termék a kosárba. Tehát ilyenkor egy auditív visszajelzés is mindenképpen fontos. És arról se feledkezzünk meg, hogy ugye például gyengénlátó felhasználók, akik – ugye ebben az esetben nem vak felhasználókról beszélünk, hanem látó felhasználókról –, ők nagyon sokszor képernyőnagyító szoftvert használnak. Vagy átkapcsolják high contrastba a gépet, vagy nem, de az, hogy a képernyőnagyító is működik, ez biztos, hogy fontos lesz, tehát ő abban a pillanatban mondjuk egy gombbal áll interakcióban, megnyomja a gombot, és ő nem látja akkor a képernyőnek a bal sarkát, hiszen a kinagyított képernyő bele van zoomolva az oldalnak egy részébe, tehát semmilyen visszajelzés nincs arról, hogy a képernyő bal sarkában kigyulladt egy lámpa, és megjelent, hogy most három termék van. Ez is egy klasszikus UX kérdés, hogy lehetőség szerint az interakciókhoz közel is történjen valami látható változás, hiszen akkor a user arra koncentrál, avval a gombbal van kapcsolatban, és abban interaktál, tehát mondjuk egy hibaüzenetnél is marha jó, hogyha elküldök egy submittel egy formot, akkor ne 82 km-rel följebb jelenjen meg egy error arról, hogy valami baj van, hanem lehetőség szerint valami figyelemfelkeltő dolog legyen ott közvetlen a gomb környezetében is, hiszen ott tartózkodik a user, akkor abban van interakcióban. De önmagában – mondom, visszatérve erre a pulzálásra – marhára nem lesz ebből probléma, ha esetleg ez előjön.

Tibi: Felolvasó szempontból meg ilyenkor egy aria-live-ot kell erre rárakni, ha jól sejtem, s akkor az nyilván felolvastatja attól függően, hogy milyen típusát használjuk.

Sz.K.: Igen, igen, igen. Na ebben az esetben ez az aria-live ez egy előremutató történet, hiszen beszéljünk ugye arról, hogy az ARIA az az Accessible Rich Internet Applications, tehát nem weboldalakra találták ki az ARIA-t, hanem interakcióban gazdag alkalmazásokra. Alapvetően régen, 10 évvel ezelőtt egy sztenderd vállalati weboldalnál ki a fene akart live-t? Nem volt ilyen. Amióta applikációk vannak, és iszonyatos tempóban változik a képernyő, akkor bizony előjöhet ez a live, és akkor ez egy jó megoldás lehet, hogy minden olyan információ, ami ilyen státusz-üzenetként megjelenik, és ez is egyébként egy WCAG – a 2.1-es, az új WCAG-ban – ez egy checkpoint, egy teljesítési feltétel, hogyha van egy ilyen státusz-üzenet, márpedig ha státusz-üzenet, akkor annak nemcsak vizuálisan kell megjelennie, hanem hallhatóan is, és erre bizony az aria-live az egy nagyon jó megoldás lehet, amiről ugye azt kell tudni, hogy két része van, az úgynevezett polite, meg az assertive. Az egyik az udvarias, az olyan, mint mikor most valamelyikőtök nem szól közbe, hanem megvárja, amíg befejezem – ugye ez a polite –, de lehet, hogy valami akkora hülyeséget mondok, akkor mindenképpen megszakíttattok, az az assertive. Ugye itt is ez van, hogy a live-nál be lehet állítani, hogy ez mennyire legyen zavaró, tehát a user amíg használja a felolvasószoftverét. Rögtön kell ugye arról értesülni, hogy valami történt, vagy ráér-e egy 5 másodperc múlva, hogyha éppen szünet van.

Roli: Itt beszéltünk már a vakokról, színtévesztőkről és a mozgássérültekről, a hallássérültekkel mi a helyzet?

Sz.K.: Hát igen, a hallássérülteknél általában alapvetően azt szoktuk mondani – és itt is van két érdekes dolog –, talán a leginkább őket a multimédiás elemek érintik. Legyen ez audio, vagy videó. Abszolút ne kritikaként vegyétek, imádom ezt a podcastot, de hogyha most nagyon magunkba nézünk [műsorvezetők nevetnek], akkor tulajdonképpen ugye ebben az esetben ez egy hangfájl, amit ugye nem érnek el mások, hallássérültek például. Márpedig én tudok olyan Pesten működő webfejlesztő céget, akik kifejezetten hallássérült fejlesztőkkel dolgoznak. Mert a hallássérülteknek viszonylag elég nehéz elhelyezkedni a munkaerőpiacon, márpedig szerintem az IT az pont egy olyan szakma, most alapvetően nem kell hozzá. Az hogy hallássérült valaki, attól még profi bármilyen fejlesztő lehet,

?: [szavába vágva] Még lehet, hogy előny is... [nevet]

Sz.K.: Még abban a pillanatban lehet, akár az is benne lehet, de summa summarum, tehát ebben az esetben ezt a beszélgetést, az információértékéhez nem férnek hozzá, mert ugye ez csak egy auditív dolog. Ami azt jelenti, hogy ebből kellene csinálni egy átiratot. Ugye ilyenkor a beszélgetésünk után valakinek neki kéne állnia és le kéne pötyögnie, hogy miről beszélgettünk, ami tuti erőforrásigényes. Na ez egy olyan téma, amire azt kell mondanom, hogy – bár nagyon sokszor vitatkozom azon, hogy az akadálymentesség mennyire kerül, na itt biztos, hogy bele kell tolni erőforrást, vagy elő kell szedni valamilyen olyan eszközt, valamilyen speech-to-text eszközt, amivel ez megoldható, de akadálymentes akkor lesz a podcast, hogyha elérhető hozzá egy szöveges átirat. Ugye ez biztos, hogy így van. A másik ugye a videók kérdésköre, ahol meg ugye lát az illető egy videót, de fogalma sincs, hogy mi történik a videóban hangban. Lehet, hogy egy olyan videóról beszélünk, amin semmi szöveg nincsen, csak szép tájakat mutogatnak, hogy gyere ide kirándulni, akkor is az az információ, hogy nincs alatta hang. Nincs alatta szöveg. Az így fontos lehet. Tehát a feliratozás, mint olyan. Ugye a feliratozásnál sokan arra gondolnak, hogy ugyanaz a feliratozás, mint mikor én beülök egy moziba egy japán filmre, és feliratozzák nekem magyarul, de itt messze nem erről beszélünk, hiszen itt nem az az akadály (bár megjegyzem zárójelben, az is akadály, hogy nem tudok japánul, tehát egy website-on mikor nyelvválasztás van, az is akadálymentesség, hozzáférhetőség, hogy nem értem azt a nyelvet; zárójel bezárva), de hogyha a feliratozást nézem, akkor én alapvetően hallom, hogy hádzsime, hádzsime, meg ott őrjöngés van, tehát nekem nem kell az, hogy ott valaki éppen hörög, mert azt én hallom. De egy hallássérült számára bizony fontos, hogy az összes olyan információ azon kívül, hogy miről beszélnek a szereplők, ki legyen írva; hogy most hörgés van, kutyaugatás van, szirénázás van, bármi, vagy csönd van. Vagy zene van. Vagy léptek hallatszódnak. Tehát a feliratozásnál megkülönböztetünk bizony klasszikusan olyan feliratozást, amelyik azért van, mert nem ismerem azt a nyelvet, a másik pedig, amit a hallássérültek számára DVD-ken, netflixen, ha megnézitek, ez két külön opcióként is rendelkezésre állhat. Tehát amikor valaki föltesz egy videót, akkor tuti biztos, hogy kell arról gondoskodnia, hogy az feliratozva legyen, ami persze megint erőforrásigényes. Hozzáteszem, ez nagyon szemét munka egyébként, hiszen itt időzítésről beszélünk, meg szövegezésről. Bár a szövegezésnél szokott lenni egy olyan vita – és evvel átkanyarodnék egy olyan témára, amit viszont múltkor kaptam meg a nyakamba –, hogy a jelelés. Ugye az egyik – hogy fogalmazzak, nem akarok reklámot csinálni – az egyik sportüzletben – ugye nagyon sok üzletük van, a kék színű D betűs üzletről beszélünk [műsorvezetők nevetnek] –, megváltozott munkaképességű alkalmazottaik vannak, nagyon sok hallássérült alkalmazott van, és akár ha megnézitek, akkor a pénztárnál is ki van írva, hogy most ebben a pénztárban hallássérült dolgozik, tehát hogy tudjál róla, namost mindegy, lényeg az, hogy ők szintén kommunikálnak és kiadtak hírlevelet. És az egyik hírlevelüknek a végén volt egy videó. Hogy akkor ez a hírlevelünk jelnyelvi verziója. És én akkor azt mondom, hogy hú, ez marha jó, milyen előremutató történet, s ezt ki is írtam, azt hiszem a Twitteren. Aztán jött a nyakamba egy csomó olyan dolog, hogy ez mekkora baromság. Hogy aki ezt kitalálta, basszus, hát olvassa el! Hát oda van leírva! Nehogy már, hát nem tud olvasni? Mit kell itt jelelgetni, meg minden?! Na ez a probléma, hogy itt némi miszkoncepcióval vagyunk szemben, amiben ugye az történik, hogyha valaki hallássérültként születik, tehát magyarul ha születésétől fogva hallássérült, akkor neki nem a magyar lesz az anyanyelve. Tehát neki a magyar nyelvet ugyanúgy meg kell tanulnia később, hallás nélkül, adott pillanatban, mintha neked kéne most holnapután megtanulni japánul úgy, hogy nem hallottál életedben japán kiejtést. Ez egy nehéz dolog. Tehát alapvetően jelnyelven kezdenek el kommunikálni akár a szüleikkel, akár a tanárokkal, főleg, ha olyan iskolába kerülnek, tehát nekik a jelnyelv lesz az anyanyelvük. És abban biztosak. Abban tudnak jól kommunikálni. Tehát ezért a jelelés, mint kommunikáció, az nagyon fontos lesz számukra. És ezért elképzelhető, hogy bizonyos szavakat nem is tudnak, bizonyos kifejezéseket nem tudnak olyan módon megtanulni, soha nem is tanulták meg, ahogy azt mi gondolnánk. Nem azért, mert nem tudja elolvasni a betűket, hogy a-b-c-d-e, hanem nem érti. Ahogy te sem biztos, hogy értesz egy angol kifejezést. Hiába tudsz angolul. Ezért biztosabb, hogyha ebben az esetben valaminek megvan a jelnyelvi verziója is, hiszen a kommunikáció szempontjából az számukra sokkal könnyebb. És ezért előremutató ez a történet. Hozzáteszem azért, hogy a WCAG-szabvány szerint a jelnyelv, jelelés, mint videó, jelnyelvi videó az azért egy marha magas szinten – ugye a WCAG-nak több szintje van, egy alapszint, egy közepes meg egy extra magas; ugye a szimpla A, dupla A, tripla A szint –, a tripla A szinten van a jelnyelvi követelmény. Tehát ezt egy sztenderd oldalon nem szoktuk általában azért ezt ilyen szempontból kifogásolni, hogy miért nincsen jelelve a videó, feliratozni viszont kell. Az a minimum. Tehát ha nincs feliratozva, akkor nyilvánvalóan nem fog működni. De itt is hadd hozzam be azt a példát, és ez is nagyon érdekes, hogy egyes statisztikák szerint például a youtube-on nagyon sokan használják a feliratozás funkciót úgy, hogy nem hallássérültek. Beülnek egy meetingre, és tök jól nézegetik a filmet. Vagy az adott műsort. Tehát itt is van arra statisztika [nevet], hogy bizony mindegyikünk számára – és akkor visszakanyarodunk arra a dologra, hogy igen, az akadálymentesség, a hozzáférhetőség nem a fogyatékos emberekről szól, hanem mindannyiunkról, mert bármelyikünk kerülhet olyan szituációba, amikor mondjuk nem tudunk hallásunkra támaszkodni, nem tudunk a látásunkra támaszkodni, nem tudunk egeret használni, bármi lehet. Tehát kár ezt beskatulyázni. Ugye ez a bizonyos inkluzív dizájn erről is szól, hogy persze, csinálunk valamit a hallássérültek számára, de abból nem csak ők fognak profitálni, hanem a belefektetett melóból ők is, meg mindannyian profitálunk, mert ott lesz egy olyan feature, olyan funkció, ami utána jól működhet. Tehát ez egy kivonatnál, egy podcastos kivonatnál lehet, hogy valaki azt mondja, hogy gyorsan át akarom futni, belenézek. Nincs időm meghallgatni, hogy az 5 perc 82-dik másodpercben miről beszéltek, gyorsan megnézem. Vagy akár – keresőmarketing szempontból – Google rákeres, tehát vannak előnyei egyébként. A feliratozással is ez a helyzet. Ha nem ráégetett feliratozásról beszélünk, hanem mondjuk track elemről, HTML5 track elemnél, az például SEO szempontból baromi nagy előrelépés, hiszen a Google is pontosan tudja majd time code-ra, hogy melyik jelenetnél éppen miről beszélnek, vagy mi a téma, tehát SEO-sok is örülhetnek, hogyha feliratozva van rendesen; ugye itt a zárt meg a nyílt feliratozást ahogy meg tudjuk különböztetni.

Edu: Amúgy mikor terveztük a podcastet, akkor az egyik pont volt az, hogy pont csináljuk a szöveges verziót, viszont ezzel az a probléma volt, hogy kézzel írni a szöveget az csomó idő, és így próbáltunk keresni mindenféle eszközt, és sajnos nem találtunk pont olyat, ami magyart tud megérteni, sőt, az enyémet is [együtt nevetnek].

?: Még mi is gondban vagyunk [együtt nevetnek].

Sz.K.: Igen, ezt általában nagyon sokszor, külföldi podcastoknál tudom, hogy ez úgy működik, hogy egyszerűen önkéntesen. Tehát olyan hallgatói bázis van, hogy társadalmi munkában, önkéntesként valaki fogja magát, és elkezdi bepötyögni. Ez csak így működhet. Megjegyzem egyébként, van egy nagyon jó szoftver, ezt ajánlom mindenkinek a figyelmébe, Androidra létezik olyan, a Google-nak a saját szoftvere, „átirat” névre hallgat, ha jól emlékszem, ami nagyon jól tud már magyarul, fölismeri a környezeti hangokat, tehát ha elkezd a kutya ugatni, akkor kiírja, hogy kutyaugatás, a tapsra, a köhögésre, minden ilyenre megjegyzi, és az például real time nagyon jó átiratot tud, tehát az például egy előadásnál, vagy egy egyetemen, egy főiskolán, egy iskolában megoldható az, hogy a hallgató – egy hallássérült hallgató – szépen ül bent a padban, és kint a tanár magyaráz, és a hallgató tulajdonképpen élőben real time feliratozva látja az előadást. Egy hátránya van, és ebben nagyon kérem a segítségeteket is, vagy hogy ha a hallgatók közül erről valaki tud majd valamilyen információt adni, nem lehet belőle lementeni. Nem tudom, hogy ez szándékos, vagy nem szándékos, nincs benne Save as funkció. Megőrzi, azt hiszem, három napra visszamenőleg megőrzi magát a cuccot, de egyszerűen se copy paste-tel, semmivel nem lehet belőle kijönni. Én is próbáltam egyébként a Google-nek a speech API-ját, mert van ugye speech API, amivel fölküldöd így a kész anyagot, nem, nem. Annyira nem tud.

Edu: Igen, mi is próbáltuk, az így nem működött. Egy alkalmazásban, amit használunk podcast vágásra, ott van egy ilyen funkció, de ott nincs egy magyar nyelv, csak angol, francia meg még pár.

Sz.K.: Igen, igen, igen, igen.

Tibi: És nemzetközi szinten, tehát arról lehet tudni, hogy például a magyar oldalak hol állnak így nemzetközi szinten akadálymentesség szempontjából? Van ilyen felmérés, vagy nem tudom, egyes országok előrébb vannak ebben a témában, amit egyes országokon belüli szabályozás megköveteli-e, hogy minél több ilyen oldal készüljön? Meg tudom, hogy vannak EU-s szabványok, tehát hogy mindenféle ilyesmi van, de hogy esetleg azt lehet-e tudni, hogy mi magyarok hol tartunk ebből a szempontból?

Sz.K.: Elvileg léteznek ilyen felmérések, pont így az EU-s történet kapcsán, hiszen most már életben van egy web akadálymentességi irányelve az EU-nak, ami ugye minden tagállamra kötelezően előírja ezt a történetet. Alapvetően közcélú oldalak esetében, hiszen maga ez a törvény is erről szól, de ebben a felmérésben megpróbálnak ilyen típusú tesztet végrehajtani, de akkor visszakanyarodunk oda, hogy nade hogy tesztelték? És nagyrészt úgy tesztelik, hogy ráengednek 1200 oldalra egy robotot, amelyik elkezd kidobálni neked egy hibalistát, tehát visszakanyarodunk arra, hogy manuális kontra kézzel tesztelés, vagy automatikus tesztelés, és ebből kijöhet valami statisztika, de én úgy gondolom, hogy amennyi kollegának a hozzászólását én látom neten, külföldi kollegának, nem állnak jobban. Tehát itt most azt kell mondanom, hogy nem arról van szó, hogy mi most ebben elmaradottak lennénk, szerintem semmivel nem állunk rosszabbul vagy jobban. Hagyományosan egyébként a skandináv országok nagyon tolják ezt a témát, tehát ott azért viszonyleg előbbre állnak, például a napokban jelentették be, hogy Norvégiában – ugye amelyik nem EU-s tagállam – mégis átvette az EU-s direktívát, és mégis kiterjesztette a privát szektorra is ezt a törvényt; ugye nálunk ez nem érvényes ez a törvény a konkrét törvény a privát szférára, csak a közcélú oldalakra, de a norvégok kiterjesztették. Angliában szintén eléggé jól állnak ebben a témában. Hát Amerikában meg ugye jól tudjuk, ott pedig aztán a jó kis jogi procedúra. Most éppen valamelyik pizzázóláncot perelte be egy ügyfél, és nyakába engedett egy jó kis pert, meg aztán valamelyik – nem tudom hirtelen, Beyonce, vagy valamelyik; azt hiszem, Beyonce – honlapját is valaki ilyen szempontból. Ott Amerikában az ügyvédek utaznak inkább erre a történetre, tehát ott van egy ilyen bitófa-jellege a történetnek, nálunk talán ez még nincsen, bár volt már erre precedens. Tehát az egyik leghíresebb ilyen precedens ugye klasszikusan az egyik Telekom szolgáltatásnál jött elő, ahol ugye végül is ez problémát jelentett privát szférában is, nade hozzáteszem, vannak azért olyan törvények, amik alapján egy átlagos privát szektor honlapjának is akadálymentesnek kell lennie. Ha mondjuk őneki van egy ügyfélszolgálata, vagy ügyfelei vannak; ez különböző törvényekből levezethető. Az a törvény, ami most életbe lépett – ezt is talán fontos tudni, szeptember 23-tól él – jelen pillanatban úgy van a jogszabály, hogy mostantól kezdve minden új – amit 2018. szeptembere után adtak át, új – közcélú honlapot, annak már akadálymentesnek kell lennie mostantól. Tehát ez most már ellenőrizhető az erre kijelölt magyar hatóság. A régi honlapokra, a régi közcélú honlapokra, amelyek mondjuk három évvel ezelőtt készültek, vagy tízzel, nekik még egy év laufuk van, tehát nekik jövő szeptembertől van ez a történet, és talán ha jól emlékszem, akkor a rá következő évtől meg már a mobil alkalmazásoknál is ugyanez életbe lép, tehát most van egy ilyen típusú fenyegetettség, ilyen típusú bárd.

Edu: És ezt hogy vizsgálják meg, hogy melyik oldal tartozik erre a törvényre, vagy hogy kell...

Sz.K.: [szavába vágva] Igen,

Edu: [szavába vágva] Tehát hogy a domain zóna alapján, vagy...

Sz.K.: [szavába vágva] Nem, nem, nem, nem, nem, ezen ment a vita, hát itt jó kis politika indult el. Megpróbálták azt megnézni, hogy melyek azok az oldalak, amire egy átlagos állampolgárnak biztos, hogy szüksége van. Ilyen lehet mondjuk a közlekedés, az iskoláztatás, a házasságkötés, vagy bármi. Tehát amivel életedben szembesülhetsz, és abban mondjuk ügyet kell intézned. És akkor próbáltak egy ilyen kört kialakítani EU-s szinten. Aztán elindult egy lobbitevékenység, és szépen ezekből lefarigcsáltak, és a végén maradt egy olyan, aminek az lett a neve, hogy közszférabeli szervezet. És a közszférabeli szervezetnél a magyar jogszabályban nem volt korábban ilyen titulus, és azt mondták, hogy az számít közszférabeli szervezetnek, aki közbeszerzésre kötelezett. Ez egy ilyen jogi csűrcsavarás. Tehát mindenki olyan szervezetnél, akiknél ez fönnáll. Közbeszerzésre kötelezett. Tehát ez alapján történik, tehát itt igazándiból nem az ellenőrzéskor derül ki, hogy milyen domain, vagy mit kell vizsgálni, hanem az adott szervezetnek kell tudnia, hogy én ebbe beletartozom, nekem ebben van-e teendőm vagy nincsen. S egyébként érdekes módon ez a törvény előír egy nyilatkozatot is: adott szervezetnek nyilatkoznia kell arról – és ezt ki kell tenni a honlapjára, úgy mint a GDPR vagy ugye az adatvédelmi nyilatkozatot –, nyilatkozni kell arról, hogy az én honlapom ekkor és ekkor – és akkor visszakanyarodunk ehhez a témához – megfelelt a WCAG ilyen és ilyen dolognak, amit lehet két módon csinálni. Én, mint cég, azt mondom – vagy én mint szervezet –, hogy szerintem jó, mert a fejlesztők azt mondták, hogy jó, vagy azt lehet mondani, hogy a harmadik fél mondta rá, hogy jó, nem tesz különbséget egyébként a törvény, tök mindegy, ki mondja rá, és akkor jön az a visszacsatolás, amire Tibi mondta, hogy ugyanúgy meg kell jelölni egy kontaktot, hogyha mégis találsz rajta hibát, akkor hova forduljál, tehát szerintem azért ezt a törvényt nem szabad a törvény felől közelíteni, hanem ez a józan paraszti ész szerint működjön, és ha valami baj van, próbáljunk meg rajta javítani. Tehát nem ilyen akkor most megbüntetlek 8 millióra, mert csúnya voltál. Amerikában ez megy, nálunk talán még nem.

Tibi: Kicsit más téma, de persze akadálymentesség, hogy létezik olyan, hogy fullra akadálymentesítjük az oldalunkat?

Sz.K.: Létezik. [együtt nevetnek] Létezik. Létezik. Ezt még igazándiból a jobbik kategóriának ítélem meg, én legalábbis. Ennek a hátterében általában saját tapasztalatom az, hogy jó szándék és információhiány áll. De szerintem még talán ha megkérdeznénk az érintetteket, ők is azt mondanák, hogy ez legyen a legkisebb probléma. Mondok egy nagyon egyszerű dolgot. Nagyon sok esetben például nem tudják a fejlesztők azt – vagy valahogy nem olvastak utána –, hogy mondjuk egy adott elemnél, az elemnek a szerepe, hogy az micsoda, az implikálja azt, hogy azzal mit kell csinálni. Tehát ha van egy gomb, egy button elem egy honlapon, akkor nem kell oda szájba rágni, hogy nyomd meg, mert a vak ember nem hülye, tudni fogja, hogy a gombbal általában nyomást kell végrehajtani, mint interakciót. Tehát a túl akadálymentesítésnél az egyik, hogy ilyen szájbarágósan kezdjük mondani, tehát nagyon törődni akarunk velük, nagyon törődni akarunk avval, hogy ez jó legyen, és akkor ilyen nagyon hosszú ilyen help szövegeket kezdünk el megfogalmazni, ami tök egyszerűnek tűnik. Ráadásul ha valaki már hallott egy vak felhasználót felolvasószoftvert használni, hát ez ilyen iszonytató tempóban, hadar ugye maga a felolvasószoftver, és ugye ebben az esetben beszélhetünk egy olyan dologról, hogy túlterhelés, tehát hogy mennyi információt zúdítasz a nyakára a felhasználónak, és ez megint UX-kérdés néha, hogy egyszerű tőmondatok, vagy egyszerű funkcióknál ez tökre jól működik, nem kell elmagyarázni, hogy nyisd le, nyomd meg. Persze vannak olyan helpek, amiket muszáj beletenned, mert másképpen nem fog működni, de a túl akadálymentesítésnek az egyik megoldása. A másik, az meg akkor szokott lenni, mikor az alt attribútumról beszélünk. Ott is szoktam látni néha auditok során, ilyen nagyon túlmagyarázó dolgokat, ahol persze nyilvánvalóan megint nincsen azért fekete-fehér igen-nem, hogy mi legyen egy altban, mert az – ahogy beszéltünk róla –, ez egy fontos dolog, hogy ezt megkülönböztessük, de azért túl sem érdemes magyarázni, mert lehet, hogy azon a képen van egy olyan információ, ami rohadtul senkit nem érdekel. Nekem volt olyan, amikor egy vak ismerősöm mondta, hogy hát ugye nagyon sok vak ember számára mondjuk a színek irrelevánsak. Tehát hiába hangsúlyozod te az altban, hogy milyen szép piros rózsa van a képernyőn, nem feltétlenül fogja azt tudni, mi az, hogy piros. De persze valakinek meg ez fontos, hogy valamiért megkülönböztetni. Tehát nehéz, nehéz. Itt egy olyan mezsgyén vagyunk, ami már nem ennyire egyértelmű, de ott szoktam látni oda beírva olyat, hogy – nem tudom, ilyen – „dizájn fotó:”. Tehát valahol utalsz, hogy nem egy fontos dolog, de beleírta az alt-ba, hogy „dizájn fotó”, hogy tudja az illető. Tehát ez szokott lenni így túl-akadálymentesítés gyanánt.

Tibi: Egyébként ez lehet, hogy fejlesztő oldali jó szándék sokszor...

Sz.K.: [szavába vágva] Persze! Tehát le a kalappal előttük.

Tibi: [szavába vágva] Csak egy kicsi túltolja az ember...

Sz.K.: [szavába vágva] Én még mindig azt mondom, ez még mindig jobb, és mindig legalább az van, hogy az ember látja, hogy igen, ez ott van, tehát mindig ez a „rohadtul nem érdekel engem” című történettől egy fokkal előbbre van. Ennek mindenki örül szerintem, hogyha legalább ez megtörténik.

Tibi: S olyan volt már, hogy találkoztál olyan esettel, front-end oldali megvalósítással, ami ilyen nagyon praktikus volt, és még soha nem is találkoztál vele, vagy akár nincs benne az alap szabványban sem? Tehát egy ilyen speciálisabb elem, ami tényleg mondjuk nem szabvány szintű, hanem annál mondjuk összetettebb, és akkor kitalált arra valaki akár egy plusz magyarázó szöveget, akár egy plusz működést, akár ilyen praktikus módon használja az aria tageket, polite-ot, nem tudom. Tehát tényleg egy olyan megoldást, ami egyedi, és nagyon jól meg lett csinálva.

Sz.K.: Igazándiból, most így hirtelen, ahogy visszagondolok, alapvetően nem nagyon találkoztam ilyennel, vagy legalábbis ritka azért az a honlap, amelyiknél nagyon bonyolult komponensek vannak, kivéve persze azok a honlapok, ahol ilyen kalkulátorok, meg tudjuk jól, hogy ilyen kiválasztom-beleteszem meg ilyesmi, tehát ez viszonylag ritkább. Néha – őszintén megvallom nektek – meg szoktam nézegetni mondjuk nagyobb honlapokat, mondjuk a facebookba belenézegetek. És akkor megnézem a facebook kódban, mi a helyzet. És ahogy a facebook hogyan oldja meg. Ami persze nem jelent semmit, mert nyilvánvalóan ők sem feltétlenül törődnek mindig mindennel, de legalább azt feltételezik, hogy van ott olyan erőforrás, hogy rá tudnak állítani akár több fejlesztőt is a történetre, ott találkoztam talán olyan megoldásokkal, amikre azt mondtam, na, ez egy érdekes dolog. Legutóbb, ha jól emlékszem, egy poszt alatt a like-ok egymás mellett; most ugye front-endesként elkezdek gondolkozni, hogy akkor én ezt hogy oldanám meg? Akkor most az három link? Vagy három button? Vagy mi legyen a like, dislike, meg mittudomén, imádom történet? És akkor ott ők például egy toolbart dobtak oda be. A toolbar fogalom az ugye alapvetően nekünk úgy van meg, hogy szövegszerkesztő programnak a fölső sávjában van egy toolbar, ahol vastag/vékony/dőlt betűvel be tudom állítani, ez egy klasszikus toolbar pattern. Nekem sem feltétlenül jutott volna eszembe, hogy ott egy toolbart érdemes bedobni, mint eszközt, és akkor azt mondani, hogy na akkor ilyen amikor én dislike-olok vagy like-olok, akkor egy ilyen toolbaron gondolkozom. Ugye toolbarnak azt kell tudni, hogy az az marha egyik nagyon nagy előnye, hogy nem kell végigzakatolni az összes gombon. Tehát hogy az illető belép ebbe a toolbarba, akkor valamilyen módon – nem emlékszem rá, mi volt, hogy mit hall, hogy ez a reakció, vagy valami ilyesmi – és ha nem, akkor nem kell végiglépkednie mind az öt tetszik, nem tetszik, dislike, meg – mittudomén – utálom, hanem azt mondom, hogy belementem ebbe, nem érdekel, továbblépek. Ugye a pattern úgy néz ki, hogy tabbal belelépsz, és a következő tab már kivisz abból az elemből, és az öt gomb között ugye kurzor jobbra – kurzor balrával tudsz mozogni. Az a toolbarnak a specifikussága. Tehát ez például nekem ilyen izgalmas volt, és most is van egy olyan projekt, amiben így részt veszek, ahol szintén nagyon heavy meg ilyesmi gombok vannak a képernyőn, tehát szinte az egész ez, és ott ezen jár az agyunk, hogy iszonytató mennyiségű tabuláció kell ahhoz, hogy eljusson az ember A pontból B pontba, és próbáljuk redukálni ennek a tabulátor stopoknak a számát, és ott is például előjött ez, hogy akkor esetleg vessük be ezt a toolbar történetet, ami nem feltétlenül jutott volna eszünkbe. Mondom, a toolbar az inkább ez a pattern. Az ARIA-ban – és avval sokat találkozom egyébként, hogy a fejlesztők ugye fölcsapják az ARIA-t, ARIA-patternöket, és kinéznek ott valamilyen szimpatikus dolgot, de nem gondolnak bele, hogy az nem feltétlenül működőképes egy sztenderd weboldalon. Hanem az egy alkalmazásban. Egy példát, ha megengedtek: ugye a navigáció, mint minta – ezen rendszeresen megy a vita, szakmai vita, és a tanács, tőlem is kérdezik sokan –, hogy az ARIA-ban van egy menu pattern. De az az a menu pattern, ami egy alkalmazásnak a fölső sávja: a File, Edit, stb. Nem az a menü, amit a weboldalon mi menünek hívunk. Az nem menü. Az egy navigáció, amiben listaszerűen föl vannak sorolva akár több szinten is – ha egy dropdown menüről beszélünk –, az egy navigációs lista. Annak köze nincs ahhoz a menühöz, ami egy desktop alkalmazásban vagy egy webalkalmazásban van. Tehát az például szerintem egy komoly hiba, ha egy fejlesztő ezt úgy fölcsapja, és beépíti a Kutykurutty Kft weboldalának a tetejébe a menu patternt, mert az volt leírva. Az nem az. Az egy navigációs lista, nav jelölőelemmel megjelöljük, és általában listaelemet használunk benne több szinten, hogyha arról van szó. De ha valóban te meg akarod írni a Google-nak a következő verzióját, a Google Mailnek, bárminek, akkor valószínűleg ezt fogod használni, mert akkor az tényleg egy klasszikus menu pattern.

[Megszólal a műsor zárását jelző zene.]

Edu: Ennyi fért bele ebbe az adásba. Nagyon szépen köszönjük a Karesznek, hogy bejött hozzánk a podcastbe, és eléggé sokat tudott nekünk mesélni! Ha van valami ötlet, kérdés vagy visszajelzés, akkor nyugodtan írjatok nekünk Facebookon, Twitteren vagy akár e-mailben, és hallgassatok minket legközelebb is. Sziasztok!

Sz.K.: Sziasztok!

Többiek: Heló! Sziasztok!

[Befejező zene szól.]