Va­ló­di aka­dály­men­te­sí­tés

A gimnázium, ahol tanultam törvényi parancsszóra szép, alacsony dőlésszögű rámpát építtetett a főbejárat mellé. Amennyire emlékszem nem nagyon láttam kerekesszékes tanulót az iskolában, furcsálltam is az egészet. Később gyakran csak úgy szórakozásból a lépcső helyett a rámpát használtam reggelente és az egyik ilyen alkalommal - magam is elcsodálkoztam, hogy ez addig nem tűnt fel - rádöbbentem, hogy ahhoz, hogy a rámpához eljussak, egy széles, murvával mélyen feltöltött kavicságyáson kellett átgyalogolnom. Ha csak nem valami kerekesszék-traktorral akart volna valaki felmenni, bizonyosan elakadt volna a murvában. (Szerencsére az évek során letérkövezték a korábbi murvás szekciót, bízom benne, hogy azért, mert felismerték a problémát.)

A példa jól illusztrálja, hogyan állunk hozzá mi, akik nem vagyunk akadályoztatva a nehézségekkel élők életének megkönnyítéséhez: ha a törvény kimondja, hogy legyen számukra ilyen-olyan segítség, akkor kénytelen-kelletlen megcsináljuk, de csak szigorúan betű szerint. Tessék íme a rámpád, most már hagyjál békén! Nem jó? Mi nem kéne még? Nem is használod. Ja, hogy nem tudod? Nem is próbálod! Folyton követelőzöl, aztán meg csak kifogásokat keresel!

Egy weboldalt akadálymentesíteni éppolyan átgondolást igényel mint egy rámpát jól elhelyezni, és az analógia abban is megáll, hogy mindenki számára jobb lett volna az egész épületet úgy megépíteni, hogy eleve akadálymentes legyen. De ha egyszer már elkészült, akkor csak sok módosítással lehet elérni, hogy minél jobban használható legyen.

De az első lépés, hogy tényleg úgy álljunk hozzá, hogy használható legyen, ne csak a törvényi kötelezettségeinket akarjuk letudni. Amikor azt a feladatot kaptam, hogy akadálymentesítsem a Magyar Nemzeti Múzeum weboldalát (mivel törvény írja elő az állami fenntartású szervezetek weboldalának akadálymentességét), és első alkalommal felolvastattam a JAWS programmal, olyan érzés fogott el, mint amikor a murván átgyalogolva megértettem, hogy mennyire megközelíthetetlen a rámpa. A gép fahangon elkezdte végigdarálni az oldal tartalmát: a szememmel követve az elemeket természetesen értettem, hogy melyik felolvasott szövegrész mihez tartozik, de ha becsuktam a szemem akkor egy posztmodern költeményben találtam magam. Az információk struktúra nélkül ömlöttek, ami egy weboldal esetében kevésbé szerencsés.

Az elején kínkeservesen őrlődtem posztmodern világomban, ugyanis a hivatalos leírások elsőre csak jogi bikkfanyelvhez hasonló iránymutatással szolgálnak (https://www.w3.org/WAI/standards-guidelines/wcag/), másrészt sok már használhatóbb tippekkel szolgáló leírás vagy blog is nagyon általános eseteket sorol fel. De mit kezdjek én most itt konkrétan ezzel a menüvel? Az egész dizájnt nem lehet felrúgni és addig még világos a “Guideline”, hogy a menükre rá kell rakni a role=’navigation’-t, de nálunk egy nagy legördülő megamenü van, amibe ráadásul bele vannak ágyazva kis képes figyelemfelkeltő blokkok aktuális kiállításokkal. Hogyan lehet azon érthetően végiglépkedni úgy, hogy valaki ne kavarodjon össze?

A megoldás végül sok kisebb technológia ötvözéséből állt össze: a menü lenyitása az egérrel történő “hover”-ezés helyett egy rejtett, billentyűzettel kattintható linkkel történik, amit csak a felolvasó program érzékel, a kis képes ajánlók pedig külön - megint csak a felolvasóprogram számára “látható” - blokkokba lettek kiszervezve.

Az akadálymentes összkép - akárcsak az iskola esetében - sok kis rámpából és kavicságy eltüntetésből áll össze, a legfontosabb pedig, hogy próbáljuk elgondolni, hogy milyen technológia segítene, ha történetesen csak hallás alapján tudnánk egy oldalon navigálni. Ezekből a tippekből gyűjtöttem össze alább egy csokorra valót, azokat, amelyek nekem a legnagyobb fejtörést okozták, illetve, amiket a leghasznosabbnak találtam. A leghasznosabb információ-forrásaim voltak: W3ORG hivatalos dokumentációja, Leonie Watson blogja és Árpádházy-Godó Csaba, akinek ezúton is köszönöm a rám szánt idejét és értékes segítségét.

Indulás

Telepítsük fel a Magyarországon legelterjedtebb felolvasóprogramot a JAWS-t. Sajnos csak Windowsos verziója elérhető. De alapvető dolgok kipróbálására jó a Macen előre telepített Voice Over is. A programok kezelésének megtanulás igényelhet egy kis időbefektetést, de legalább a legalapvetőbb billentyűkombinációkat kénytelenek leszünk elsajátítani, hogy tesztelni tudjuk az akadálymentes navigációt.

Részletesebben ld.:

Voice Over: https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts 
JAWS: https://webaim.org/resources/shortcuts/jaws

Aria-label és role attribútumok

A legalapvetőbb technológiák egyike az oldal “aria-label”-ekkel történő ellátása. A lényeg, hogy a html optimális mennyiségű plusz meta-információval legyen ellátva. Ezeket főleg az aria és role attribútumok adják. Alapvetően azt a józan észből vett szabályt alkalmaztam, hogy ha valami nem értelmezhető felolvasva önmagában, akkor tegyünk rá aria-label = "ez a dolog ez és ez"  -t.  A szöveg bármi lehet, de érdemes megtalálni a túlmagyarázás és túl kevés információ közötti egyensúlyt.

Tipp: a linkekre (<a> tagekre) érdemes figyelni, mert ha nincs az <a> és </a> között szöveg (vagy valamilyen nagyon komplex <div>-ek találhatók közötte), akkor a href-et fogja felolvasni, ami elég komikusan hangzik. Ezt elkerülendő tegyünk az ilyen <a>-kra aria-label-t.

A role-ok előre definiáltak, ezekből lehet választani: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles

A role-ok speciális képessége, hogy html-elemeket a felolvasó számára át lehet alakítani más típusú elemekké. Pl. ha ‘role’ = ‘article’-t teszünk egy <div>-re, akkor olyan mintha <article> tag lenne. 

Hasznos lehet még a ‘heading’-gé alakítás, itt a szintet egy külön attribútummal kell megadni. Pl. <div role="heading" aria-level="1">Ez egy címsor</div>  olyan, mintha <h1>lenne.

Vizuális elrejtés

Sokszor szükség van arra, hogy valami ne látszódjon az oldalon, de azt szeretnénk, hogy a képernyőolvasó mégis felolvassa. Arra kell figyelni, hogy ne display:none-nal legyenek elrejtve, mert azt következetesen nem olvassa fel a program. (Lehetséges megoldások: font-size: 0 vagy position:absolute; left: -10000px;)

Szemantikai tag-ek

Érdemes használni a <navigation>, <article> tageket. A program belolvassa, hogy itt és itt egy navigációs blokk vagy article keződik, valamint azt is, amikor véget ér, ebből tudják a felhasználók, hogy ezek a dolgok egybe tartoznak. A <header>, <footer>, <aside> tagek is jó szolgálatot tesznek, segítenek értelmezni, hogy merre járunk az oldalon.

Headingek

Fontos a headingekkel való ellátás. Ezek segítségével gyorsan meg lehet találni az oldal kívánt részeit. Ha az oldal tagolása inkább vizuális vagy valamilyen más okból nincsenek <h> elemek, akkor érdemes láthatatlan h2-h3 elemeket beszúrni, vagy a fentebb említett módszerrel <h> elemmé alakítani más típusú elemeket.

Linkek elrejtése / linkké alakítás

Néha szükség van arra, hogy egy látható linket ne olvasson fel a program ilyenkor a következő attribútumokkal kell ellátni: tabIndex="-1" aria-hidden="true"

Ennek a fordítottja, hogy nem kattintható elemet linkszerű viselkedésre bírunk, azzal, hogy rátesszük a role=”link” tabindex=”0” attribútumokat. Ezeket akár JavaScriptből is manipulálhatjuk.

Mit csináljunk ha valami nagyon nem ott van ahol kellene? Aria-owns.

Például ha van egy menünk, aminek az almenüje nagyon messze található a DOM-ban, hogyan vegyük rá a felolvasót, hogy respektálja, hogy mi az almenüt  a főmenü elem után szeretnénk ha felolvasná? Tegyük az aria-owns attribútumot a főmenü elemre és olyan lesz, mintha az almenü a DOM-ban is gyermek eleme lenne.

<ul>
  <li aria-owns="child">Fruit</li>
  <li>Vegetables</li>
</ul>

<ul id="child">
  <li>Apples</li>
  <li>Bananas</li>
</ul>

Vagyis mintha így lenne a DOM-ban:

<ul>
  <li>Fruit
    <ul>
      <li>Apples</li>
      <li>Bananas</li>
    </ul>

  </li>
  <li>Vegetables</li>
</ul>

Chosen

Ha Chosen library-t használjuk a select mezők izgalmasabbá tételére, fejfájásra adhat okot, hogy elrejti az eredeti <select>-eket display:none-nal, holott a felolvasó programok azt kiválóan tudnák kezelni, a Chosen által betett elemekkel viszont nem boldogulnak. De semmi vész: csak css-ből a módosítsuk az elrejtést úgy, hogy display:none helyett csak vizuálisan legyen rejtve pl. 

.chosen-processed {
  display: block !important;
  width: 1px;
  height: 1px;
  color: transparent;
  background-color: transparent;
  border: 0;
  padding: 0;
}

Dinamikus menük

Dinamikus menüknél alapvetően ezt a technikát kell alkalmazni. Néhány gubanc azonban könnyen adódhat ha komplexebb a vizuális megjelenés.

• Arra figyelni kell, hogy a látássérült látogatók nem tudnak hoverezni. Nekik a billentyűzettel odanavigálva és a felolvasóprogram adott billentyűkombinációjával “klikkelve” kell kinyíljon egy menüpont. Ha az eredeti vizuális működés nem ilyen, akkor kompromisszumot kell találni, például hoverre és klikkre is nyíljon.
• Amikor elrejtjük az almenüket gyakran ennek ellenére továbbra is fel akarja majd olvasni őket a program. Pl. amikor nem display:none-nal vannak elrejtve, hanem valamilyen animációval a height:0 -ra van állítva. Ekkor segíthet a tabIndex="-1" aria-hidden="true"
• Az aktív menüelem jelölésére is van lehetőség: aria-current="page"-et kell rátenni az adott linkre. (Nekem ez egyik felolvasó programban sem eredményezett semmi egyéb beolvasott információt, de lehet, hogy csak én használom rosszul.)
• Néha a fókusz nem a megfelelő helyre helyeződik át. Például szeretnénk, ha az éppen lenyílt elem egy bizonyos pontján folytatódna a felolvasás. Ilyenkor focus() JavaScript függvénnyel kell a megfelelő helyre rakni.
• Sidebar menüknél előfordulhat, hogy egy kis <i> elemmel kell a kinyitást-becsukás végezni. Meg lehet oldani, hogy a felolvasóprogram ezeket is felolvassa, mintha link lenne, azzal, hogy role=”link” tabindex=”0” attribútumokkal látjuk el. (Az ilyen elemeknél is használjuk az aria-expanded attribútumokat)
• A menük bezárását célszerű az “esc” billentyű lenyomásra is triggerelni. Pl.

$(document).on('keyup', function (evt) {
  if (evt.keyCode === 27) {
    closeMegaMenu();
  }
}