A keresőmező akadálymentes keresése

Látó felhasználók számára általában nem okoz különösebb gondot a weboldalon elhelyezett keresőmező megtalálása. Ha felhasználóbarát a honlap, akkor elég egy gyors vizuális pásztázás, és a keresőmező jellegzetes megjelenése (például a nagyítót ábrázoló ikon) hamar észrevehető. Vak felhasználóknak azonban más módszerre van szükségük, hiszen esetükben a vizuális keresés kiesik. Ebben a cikkben bemutatok egy olyan egyszerű megoldást, amivel a keresőmező képernyőolvasóval történő megtalálását segíthetjük.

A „próba szerencse” módszer

A Magyarországi képernyőolvasók 2014-es felmérésén rákérdeztem, hogy az érintett felhasználók elsődlegesen milyen módszerrel próbálják megtalálni a weboldal keresőmezőjét. A válaszadók döntő többsége azt a bevált, ámbár „próba szerencse” módszert használja, hogy a képernyőolvasó által biztosított gyorsbillentyű segítségével odaugrik az oldal első szerkesztőmezőjére vagy az első űrlapjára.

Ez a módszer azért működik, mert a keresőmező többnyire valahol az oldal tetején helyezkedik el, így a HTML kódban is jellemzően ez az első szerkesztőmező. Ha viszont a sorrend nem így alakul, mert például egy hírlevélre történő feliratkozás, vagy egy nagyobb űrlap megelőzi, akkor ez a módszer nem vezet gyors eredményre. Zsákutcáról persze nem beszélhetünk, mert ilyen esetben tovább lehet lépkedni a következő mezőkre, bízva abban, hogy csak megkerül az a keresőmező. A felmérés válaszadóinak 13%-a eleve ezt a végiglépkedéses módszert alkalmazza.

Semmiképpen sem szabad azonban megfeledkezni arról, hogy ha a keresőmező nincs akadálymentesen lekódolva a HTML-ben, akkor a felhasználó könnyen zsákutcába kerülhet. Ugyanis a mezőre lépve csak arról értesül, hogy ez egy beviteli szerkesztőmező, de hogy pontosan mire szolgál, arról már nem. A helyes megoldás a mező akadálymentes címkézése egy olyan szöveggel, ami a keresésre utal.

A kérdés tehát az, hogy nincs-e valamilyen egzaktabb lehetőség a keresőmező egyértelmű beazonosítására.

Megoldás-e a search típusú űrlapmező?

Felmerülhet, hogy a keresés célját betöltő input szerkesztőmező type attribútumát - a HTML5-ben megjelent - search (kereső) értékre állítsuk, valahogy így:

<input type="search" name="kereso" id="kereso">

Azt gondolhatnánk, hogy a képernyőolvasó programok így már könnyen megkereshetik, és felkínálhatják a felhasználónak a search típusú keresőmezőt. Sajnos azonban az aktuális képernyőolvasók ezt még nem tudják megtenni. Szerintem kérdéses, hogy megteszik-e valaha. Egyébként a HTML5 szabvány szerint a search típusú mező tulajdonképpen egy hagyományos (text típusú) mező, legfeljebb bizonyos platformokon a natív keresőmezőre jobban hasonlító megjelenési stílust, illetve viselkedést mutat.

Vagyis a search típusú űrlapmező használata a cikk témája szempontjából nem jár különösebb előnnyel. Leszámítva talán azt, hogy létezik olyan képernyőolvasó (például a VoiceOver), amelyik a search típusú mezőbe belépve - kapcsolódó címke nélkül is - azt olvassa be, hogy a keresett szöveg mezője.

Használjuk a WAI-ARIA search ugrópontot!

A HTML5-ben natív támogatást élvező WAI-ARIA szabvány bevezette az úgynevezett ugrópont (angolul landmark, a WAI-ARIA magyar fordításában iránypont) szereppel rendelkező régiók használatát. Ez azt jelenti, hogy a weboldal jellegzetes régiói, területei, szakaszai egy olyan tulajdonsággal ruházhatók fel, amely tulajdonság az oldalon belüli navigáció szempontjából betöltött szerepüket írja le. Ezen tulajdonság alapján a képernyőolvasó program (vagy más kisegítő technológia) összegyűjtheti és felkínálhatja az oldal jellegzetes helyeit, hogy a felhasználó ezek közül bármelyikhez gyorsan odaugorhasson.

A WAI-ARIA 1.0 verziójában definiált nyolc ugrópont szerep közül az egyik a search, azaz kereső szerep. Ezzel a szereppel az a régió rendelkezhet, amelyik a weboldal keresőjét tartalmazza.

Az adott régiót leíró HTML jelölőelem kétféle módon kaphat meg egy ugrópont szerepet. Vagy a jelölőelem már eleve rendelkezik egy úgynevezett implicit szereppel, amit a HTML szabvány „gyárilag” definiál neki, vagy a role attribútum segítségével a fejlesztőtől kapja meg. Előbbire példa a nav jelölőelem, ami a weboldal navigációs régióját definiálja, és a fejlesztő beavatkozása nélkül, gyárilag a navigation ugrópont szereppel rendelkezik.

A HTML-ben azonban jelenleg nincs olyan natív jelölőelem, ami a weboldal keresőterületét definiálná, és a search szereppel már eleve rendelkezne. Nincs például külön <search> jelölőelem. Éppen ezért keresnünk kell egy létező jelölőelemet, ami az oldalunkon a keresési régiót definiálja, és a role attribútumon át megkaphatja a search ugrópontot.

Lehet-e a search ugrópont az input mezőnél?

Ismét felmerülhet, hogy közvetlenül a keresőmezőt definiáló input jelölőelemnek adjuk oda ezt a szerepet, mondjuk így:

<input role="search" type="search" name="kereso" id="kereso">

Ez azonban rossz megoldás.

A role attribútummal ugyanis nem csak ugrópont szerepeket lehet definiálni, hanem widget és dokumentumstruktúra szerepeket is. A példában szereplő input jelölőelemhez „gyárilag” a textbox (szövegdoboz) widget szerep társul, hiszen ennek a jelölőelemnek a szemantikája pontosan az, hogy ez egy szövegbevitelre szolgáló elem. A példában tulajdonképpen felüldefiniáljuk ezt a natív szemantikát, és így az input elem „identitászavarba” kerül. Többet nem tekinti magát szövegdoboznak. Ennek előre nem várt mellékhatásai lehetnek mondjuk a képernyőolvasós használat során.

Sajnos a WAI-ARIA szabvány jelenleg nem engedi meg, hogy a role attribútum többes értéket vegyen fel, vagyis egy elemhez ugrópont és widget szerepet is megadhassunk egyszerre.

És ha az űrlap kapja meg?

Valóban sokkal jobb megoldás, ha inkább a keresőmezőt tartalmazó űrlapnak (form jelölőelemnek) adjuk oda a search szerepet:

<form role="search">

Ez azért is lehet jó, mert a keresési régió - a kereső űrlapmezőn túl - egyéb elemeket, objektumokat is tartalmazhat, amelyek együttesen alkotják a keresőeszközt. Sőt, amikor a vak felhasználó a képernyőolvasójával megérkezik erre a területre, akkor plusz értesítést kap arról, hogy a keresési területre lépett.

A kérdés csak az, hogy ebben az esetben nem definiáljuk-e felül a form jelölőelem eredeti szerepét, szemantikáját?

De igen.

A form jelölőelem natív szerepe ugyanis a form elnevezésű szerep, ami egyébként szintén ugrópont szerep. Nemrégiben kisebb szakmai vita alakult ki a web akadálymentességgel foglalkozó nemzetközi szakemberek körében, hogy nincs-e valamilyen ellentmondás a WAI-ARIA ezen területén. Én is osztom azt vélekedést, hogy valami nem stimmel, hiszen a WAI-ARIA egyik alapszabálya pont az, hogy natív szemantikai szereppel rendelkező jelölőelemnek nem adunk eltérő szerepet. A WAI-ARIA 1.0 szabványban azonban jelenleg az alábbi mondat szerepel:

A keresőeszközöknél a szerkesztőknek az általános form szerep helyett a search szerepet KELL használniuk.

Ha viszont a form jelölőelem natív szerepét ilyen módon megváltoztatjuk, akkor potenciálisan fennállhat a veszély, hogy valamelyik képernyőolvasó programban ez kavarodást okoz. A WAI-ARIA szabványban a search és a form szerep között nincs alá- vagy fölérendeltségi kapcsolat, tehát nem mondhatjuk azt, hogy automatikusan minden search szereppel rendelkező jelölőelem egyben form is. Bízzunk benne, hogy egyszer talán tisztázódik ez a helyzet.

Frissítés (2016.június 15.): A helyzet tisztázódott. Úgy tűnik, hogy nem okoz akadálymentességi problémát, ha a form megkapja a search szerepet.

Semleges terepen

Amennyiben a honlapfejlesztés során úgy adódik, hogy például a vizuális megjelenés biztosítása miatt a keresőűrlapot egy div jelölőelembe burkoljuk, vagy esetleg közvetlenül a form jelölőelembe teszünk egy div elemet, akkor nyugodtan adjuk oda a search ugrópont szerepet ennek a div elemnek. Mondjuk így:

<div role="search">
   <form>

   </form>
</div>

Mivel a div jelölőelemnek gyárilag nincs semmilyen szemantikája (úgy is szoktuk mondani, hogy szemantika semleges), ezért nem áll fenn a veszélye annak, hogy a role attribútummal felüldefiniálnánk valamit. Sőt, tulajdonképpen virtuálisan létrehozzuk a search jelölőelemet.

Összegzés

A search ugrópont definiálásával megadjuk a lehetőségét annak, hogy egy vak felhasználó bármikor egzakt módon megtalálhassa a keresőmezőt, függetlenül attól, hogy a képernyőolvasója segítségével éppen az oldal melyik részénél tartózkodik.

Ráadásul most is ki kell hangsúlyoznom, hogy potenciálisan más felhasználói csoportok (például a mozgássérült felhasználók) is használhatnák a navigáció e gyors módját, ha a böngészőprogramok valamilyen billentyűre, vagy egyéb vezérlőbe kivezetnék az ugrópontok közötti lépkedést.