Menü vagy nem menü?

Webfejlesztési projekteknél akadálymentességi problémákhoz vezethet, ha a komponensekre alapvetően csak a vizuális megjelenésük, és nem a funkcionális szerepük szerint hivatkozunk. Vannak ugyanis olyan komponensek, amelyek funkcionális szerepüket és/vagy interakciós modelljüket tekintve nagyon eltérőek, vizuális megjelenésükben viszont megszólalásig hasonlítanak. Mivel ezt a funkcionális, illetve interakciós különbséget elsősorban az akadálymentességben leginkább érintett felhasználók érzékelik, így nekik nagyon nem mindegy, hogy mikor melyik komponenst használjuk.

Vegyük példának a menü komponest, és azt, hogy ki és mit ért „menü” alatt.

A menü fogalma

Hétköznapi, de nem informatikai értelemben a menü előre meghatározott fogásokból álló ételek sora, illetve régebben az étlapot is így nevezték.

Hétköznapi és informatikai értelemben a felhasználók általában menünek hívják azt a komponenst, amiben horizontálisan vagy vertikálisan elhelyezett menüpontokat látnak. Ebben az értelemben véve ezen ábrán egy menü szerepel:

Lorem     Ipsum     Dolor

A példában szándékosan használtam latin töltelékszöveggel írt menüpontokat, hogy most még csak a menü vizuális megjelenése, és ne a funkcionális szerepe legyen a hangsúlyos.

Ha értelmesebb szövegekre cseréljük a menüpontokat, de maradunk a fenti vizuális megjelenésnél, akkor vajon van-e valamilyen eltérés a következő két menü között?

Termékeink     Rólunk     Kapcsolat

Fájl     Szerkesztés     Nézet

Egy laikus felhasználó valószínűleg nem látna érdemi különbséget a kettő között, vagyis mindkettőt menünek hívná. Ellenben egy szakmabelinek érdemes észrevennie, hogy a vizuális hasonlóság ellenére funkcionálisan ez két különböző típusú menü.

Az első egy navigációs menü, mondjuk egy cég honlapján. Míg a második egy alkalmazás menü, mondjuk egy online szövegszerkesztő webalkalmazásban.

Nézzük meg egy kicsit részletesebben a kettő közötti különbséget.

Navigációs menü

Alapesetben a navigációs menü linkek listája, amelyek segítségével a felhasználók a webhely különböző részei (oldalai, szakaszai) között tudnak navigálni.

Termékeink     Rólunk     Kapcsolat

Mivel a hangsúly a navigációs funkción van, így a komponensre sokszor nem is menüként, hanem csak egyszerűen navigációként hivatkozunk.

Nem véletlen, hogy a komponens befoglaló jelölőeleme nem más, mint a <nav>. Ez jelzi a kisegítő technológiák felé, hogy a felhasználó itt találja meg a navigációt. Például a képernyőolvasó programokban a <nav> jellemzően navigációként, illetve navigálási régióként hangzik el, és nem menüként.

A <nav> elemen belül a linkeket jellemzően egy sorszámozatlan listába szoktuk szervezni, például így:

<nav>
  <ul>
    <li>
      <a href="/termekeink.html">​Termékeink​</a>
    </li>
    <li>
     <a href="/rolunk.html">​Rólunk​</a>
    <li>
    <li>
      <a href="/kapcsolat.html">​Kapcsolat​</a>
    </li>
  </ul>
</nav>

A képernyőolvasó programokban ez körülbelül így hangzik el:

navigálási régió, lista 3 elemű, hivatkozás, Termékeink, hivatkozás, Rólunk, hivatkozás, Kapcsolat

Kiemelném, hogy a navigációs menüben sem a <nav>, sem az <ul>, sem a <li>, sem az <a> jelölőelemhez nincs role attribútum társítva. Ezt azért hangsúlyozom, mert tapasztalatom szerint sok fejlesztőt megtéveszt, hogy az ARIA szabvány role="menu", role="menubar", és role="menuitem" szerepdefiníciókat is említ, azonban ezek a menüszerepek nem a navigációs, hanem az alkalmazás menüre lettek kitalálva. Navigációs menükben ne használjuk ezeket!

A navigációs menü billentyűzetes kezelése

A példában szereplő navigációs menü billentyűzetes kezelése teljesen szokványos, azaz nem igényel extra JavaScript fejlesztést. A „menüpontok", azaz a linkek a megszokott módon, vagyis a TAB és a Shift+TAB billentyűkkel, és persze a képernyőolvasó program saját billentyűkombinációival is elérhetőek lesznek. Az ENTER a kiválasztott link „megnyomását” jelenti.

Hangsúlyozni szeretném, hogy nincs olyan követelmény, miszerint a kurzormozgató billentyűkkel is lépkedni lehessen a navigációs menüben. Ez opcionálisan ugyan megvalósítható, de vannak hátrányai, és semmiképpen nem pótolhatja az alapértelmezett TAB és Shift+TAB billentyűs kezelést.

Mi a helyzet a többszintű navigációs menükkel?

A többszintű navigációs menü jellemzően csak annyiban tér el az egyszintűtől, hogy ennél egymásba ágyazott felsorolásokban vannak a linkek. A mélyebb szinteket, vagyis az „almenüket” a kapcsolódó menüpont gombjának segítségével tudja a felhasználó kinyitni, illetve becsukni.

Az alábbi példában a Termékeink menüponthoz egy olyan menü kapcsolódik, ami aktuálisan zárva van:

<nav>
  <ul>
    <li>
      <button
        type="button"
        aria-expanded="false"
        aria-controls="termekeink_menu">
      Termékeink
      </button>
      <ul id="termekeink_menu" hidden>
        <li>
          <a href="/noknek.html">​Nőknek​</a>
        </li>
        <li>
          <a href="/ferfiaknak.html">​Férfiaknak​</a>
        </li>
      </ul>
    </li>
    <li>
      <a href="/rolunk.html">​Rólunk​</a>
    <li>
    <li>
      <a href="/kapcsolat.html">​Kapcsolat​</a>
    </li>
  </ul>
</nav>

Fontos, hogy a többszintű navigációs menünél sem kell használni a role="menu" vagy a role="menuitem" definíciót.

És a billentyűzetes kezelés sem változik érdemben. Csak annyival egészül ki, hogy az almenüket az ENTER és a SPACE billentyűvel is kinyithatják a felhasználók. Plusz opcionálisan megvalósítható, hogy az ESC billentyű megnyomására bezáródjon a kinyitott almenü.

Alkalmazás menü

A Windows-os, macOS-es, vagy Linux-os asztali alkalmazások menürendszerében nem linkek, hanem az adott alkalmazásra jellemző műveletek vagy funkciók vannak.

Például egy szövegszerkesztő szoftverben szinte biztosan van egy Fájl menü, ami a dokumentumok kinyitására, illetve elmentésére szolgáló menüpontokat tartalmazza. Vagy egy olyan menü, amivel meghatározható, hogy a kijelölt szövegrész milyen formázással jelenjen meg.

Fájl     Szerkesztés     Nézet

Ma már teljesen természetes, hogy a webalkalmazásoknál is szükség van az ilyen jellegű menürendszerekre, mivel a webalkalmazások nagyon gyakran az asztali alkalmazások webes környezetre átültetett „hasonmásai”. De ez az átültetés magával hozta azt a felhasználói igényt is, hogy egy ilyen webalkalmazás menüje ugyanazt a képernyőolvasós élményt és billentyűzetes kezelést biztosítsa, mint az asztali alkalmazások menüi.

És ezen a ponton nyer igazán értelmet az ARIA szabvány, hiszen ezt a szabványt elsődlegesen a webalkalmazások megjelenése hívta életre. A fő probléma az volt, hogy a HTML jelölőelemeivel nem igazán lehet szemantikusan definiálni egy csomó olyan komponenst, ami a webalkalmazásokban jellemzően megtalálható.

Mivel a HTML-ben (jelenleg) nincsenek olyan natív jelölőelemek, amikkel az asztali alkalmazásokban használatos menüt tudnánk szemantikusan definiálni, így az ARIA-ban erre is specifikáltak szemantikai szerepeket.

Például a role="menubar" segítségével definiálhatjuk a webalkalmazás horizontálisan megjelenő menüsorát (menüsávját), amiben role="menuitem" segítségével definiált menüpontok (menüelemek) vannak.

Létezik még a role="menu" szerepdefiníció is, ami egy önálló menüt, vagy akár egy kinyitható almenüt is definiálhat. Értelemszerűen ez is role="menuitem" elemeket tartalmaz.

Ha feltételezzük, hogy az illusztrációként használt webalkalmazás menünkben az egyes menüpontok saját almenüt nyitnak, akkor például egy ilyen kódból indulhatnánk ki:

<div role="menubar">
  <div
    role="menuitem"
    aria-haspopup="menu"
    aria-expanded="false">​Fájl</div>
  <div
    role="menuitem"
    aria-haspopup="menu"
    aria-expanded="false">​Szerkesztés</div>
  <div
    role="menuitem"
    aria-haspopup="menu"
    aria-expanded="false">​Nézet</div>
</div>

A kódban az aria-haspopup="menu" definiálja, hogy a menüpont almenüt fog nyitni. Az aria-expanded pedig azt, hogy az almenü aktuálisan zárva (false) vagy nyitva (true) van-e.

Egy óriási különbség a navigációs és az alkalmazás menü között, hogy utóbbiban nincs link (<a href>) vagy gomb (<button>), hanem maga a menüpont (role="menuitem") az interaktív. Persze az interaktivitást nem kapjuk meg automatikusan, hiszen a role attribútummal csak a szemantikai szerepet definiáljuk. Minden mást JavaScript-ből kell leprogramoznunk.

Érdekességképpen megjegyzem, hogy a role="menuitem" szerepet a magyar nyelvű képernyőolvasó programok különbözőképpen olvassák fel. Például az előző mintakódban definiált Fájl menüpontot így:

Fájl menü, almenü, bezárt

menüelem, almenü, Fájl

Fájl, összecsukva, menüpont

Fájl, menüelem, előugró menü, összecsukva

összecsukva, Fájl, menüelem

Az alkalmazás menü billentyűzetes kezelése

A navigációs menühöz képest az alkalmazás menü billentyűzetes kezelése merőben eltérő, és komoly JavaScript fejlesztést igényel.

Lényeges, hogy a TAB és a Shift+TAB billentyűk szerepe minimális mértékű, mivel ezekkel csak be-, és kilépni lehet a menübe, illetve a menüből. Az alkalmazás menün belül kizárólag a ↓, ↑, →, ←, Home, és End billentyűkkel lehet mozogni. A menü kezelésében szerepet játszik még az ENTER, a SPACE, és az ESC billentyű.

Az alkalmazás menü billentyűzetes kezelésének részletes leírása a W3C egyik ajánlásában olvasható.

A kakukktojás a <menu> jelölőelem

A HTML szabványban szerepel egy <menu> nevű jelölőelem, amiről elsőre sokan azt feltételezhetik, hogy valamely említett menütípus (például az alkalmazás menü) definiálására szolgál. Kezdetben valóban ez lett volna a célja, de aztán visszavonták.

Jelenleg a <menu> jelölőelem az eszközsorban (toolbar) szereplő interaktív komponensek felsorolására szolgál, tehát egy speciális lista jelölőelemének tekinthető. Szemantikailag teljesen megegyezik az <ul> jelölőelemmel. Olyannyira, hogy a képernyőolvasó programokban is listaként hangzik el (már amelyikben elhangzik).

Érdekesség, hogy a HTML szabványban korábban felbukkant a <menuitem> jelölőelem is, de ezt később teljesen visszavonták.

Konklúzió

Egyértelműen kijelenthető, hogy a webfejlesztési projektek döntő többségében navigációs menüre és nem alkalmazás menüre van szükség. A hagyományos weboldalak, honlapok, hírportálok, webshopok esetén egészen biztosan, de még az SPA (Single Page Application) alapú rendszereknél (például az online banki felületeknél) is nagy valószínűséggel.

Alkalmazás menüben kizárólag akkor gondolkodjunk, ha olyan webalkalmazást fejlesztünk, ami egy böngészős környezetben futó „asztali” alkalmazásnak (például szövegszerkesztőnek, táblázatkezelőnek, grafikus szoftvernek, e-mail kliensnek, stb.) tekinthető.

Akadálymentességi szempontból ugyanis nagyon negatív felhasználói élményt lehet azzal okozni, ha egy hagyományos weboldalon alkalmazás menüt erőszakolunk rá a felhasználókra. Azzal meg végképp, ha a cikkben említett billentyűkezelési ajánlásokat, illetve ARIA szerepeket rosszul használjuk.