A hangvezérlés – vagyis a weboldal hangparancsokkal történő irányítása – egyre fontosabbá válik az akadálymentes webfejlesztésben. Hangalapú vezérléssel azok a felhasználók tudják használni az oldalt, akik valamilyen okból nem vagy nehezen tudnak egeret és billentyűzetet használni. Ide tartoznak például a mozgássérült felhasználók, vagy bárki, aki inkább beszéddel navigálna.
Napjaink operációs rendszerei már beépítve kínálnak hangvezérlési lehetőségeket (például macOS Voice Control, Windows Voice Access), és léteznek fejlett harmadik féltől származó alkalmazások is, mint a Dragon NaturallySpeaking. Ebben az összefoglalóban áttekintjük, hogyan lehet HTML, JavaScript és ARIA eszközökkel olyan weboldalt fejleszteni, amely hatékonyan támogatja a hangvezérlést.
(Fontos megjegyzés: a cikk a webes megoldásokra koncentrál, nem tér ki natív mobilalkalmazások vagy operációs rendszer szintű integrációk részleteire.)
Hogyan működik a hangvezérlés a weben?
A hangvezérlő szoftverek lényege, hogy a felhasználó beszédét parancsokká alakítják, így lehetővé téve a böngésző és a weboldal kezelését hanggal. A felhasználó tipikusan kimond egy műveletet (pl. „click” – kattintás) és egy cél elem nevét (pl. „Keresés”). A hangfelismerő rendszer ilyenkor megkeresi a weboldalon azt az interaktív elemet, amelynek programozott neve (accessible name) egyezik a kimondott szöveggel. Ha megtalálja, akkor végrehajtja a kért műveletet, például rákattint a gombra vagy hivatkozásra.
A legtöbb hangvezérlő rendszer (pl. Dragon, Apple Voice Control, Windows Speech Recognition) az alábbi típusú vezérlőelemeket tudja közvetlenül kezelni a nevük kimondásával:
- Linkek (hivatkozások): pl. „Open Home link” – egy „Home” feliratú link megnyitása.
- Gombok: pl. „Click Login” – egy „Login” (Bejelentkezés) gomb aktiválása.
- Űrlapmezők: pl. „Click Search field” – fókusz egy „Search” (Keresés) feliratú beviteli mezőre.
- Jelölőnégyzetek, rádiógombok: pl. „Click Yes” – bejelöl egy „Yes” (Igen) feliratú opciót.
- Ikonok vagy képek, ha interaktívak: ezekhez a hozzáférhető nevet az
altattribútum vagy ARIA címke adja. - Legördülő listák, listboxok – általában a címkéjük alapján.
A hangparancsoknak nem mindig kell a teljes feliratot tartalmazniuk: a Dragon NaturallySpeaking például már az egyedi részleges egyezésre is aktivál (pl. egy „Keresés indítása” feliratú gombra elég azt mondani: „click Keresés„). Ha egy parancsszó több elemhez is illeszkedik (pl. több „Tovább” link van az oldalon), a szoftver sorszámokkal jelöli meg ezeket, és a felhasználó egy szám bemondásával pontosíthatja, melyiket szeretné aktiválni.
Ezenkívül léteznek általános parancsok is, például a Tab billentyű mozgatására („press Tab” a következő fókuszálható elemhez), az oldalsó görgetésre, vagy akár a vágólap műveletekre. A fejlett rendszerek utolsó mentsvárként egy kurzor-rácsot is biztosítanak: a felhasználó kimondja, hogy „mouse grid”, mire a képernyő fölé egy számozott rács vetül. Ezzel a módszerrel a képernyő egy adott pontjára lehet navigálni több lépésben, majd egy „click” parancs kiadásával ott kattintani.
Mindezek alapján egy fontos következtetés: a weboldal akkor kezelhető jól hangvezérléssel, ha a felületelemek megfelelően vannak felcímkézve és programozva. Azok a weboldalak, amelyek akadálymentesek billentyűzettel és képernyőolvasóval, általában jól használhatók hangvezérléssel is. A következő szakaszokban részletesen áttekintjük, milyen fejlesztői megoldások segítik, és mely hibák gátolják a hatékony hangvezérlést.
Látható címkék vs. aria-label: miért fontos a felirat?
A hangvezérlés szempontjából kritikus a feliratok helyes kezelése. Gyakori kérdés fejlesztők körében, hogy vajon elegendő-e pusztán az elemekhez adott rejtett ARIA címke (aria-label), vagy szükség van vizuálisan is látható feliratra. A válasz: a felhasználók számára látható szöveges címke rendkívül fontos, mert a hangparancsokat jellemzően a látott szöveg alapján adják ki.
A hangfelismerő szoftver ugyan technikailag az accessible name (programozott név) alapján keres – melyet előállíthat a aria-label is –, de ha ez a név nem egyezik a vizuális felirattal, a felhasználó könnyen elakad.
Képzeljünk el egy keresőikonos gombot, amelynek nincs látható szövege, csak aria-label="Keresés". Ilyenkor a gomb programozott neve „Keresés”, tehát ha a felhasználó ezt sejti és kimondja, működhet a vezérlés. De mi van, ha a felhasználó nem tudja, pontosan mit kell mondania? Lehet, hogy csak egy nagyítót lát, és nem egyértelmű számára, hogy azt „Keresés” gombként kellene aktiválnia.
Általános szabály, hogy a látható felirat szövegét foglaljuk bele az elem accessible name értékébe (vagyis a programozott név tartalmazza a vizuális szöveget). Ezt nevezi a WCAG szabvány „Label in Name” elvnek, és éppen a hangvezérlés támogatása miatt került be a hivatalos követelmények közé.
Ha egy vezérlőnek van látható szövege, akkor annak teljes egészében meg kell jelennie a programozott névben is – ellenkező esetben a beszédfelismerés nem talál egyezést, és a hangparancs sikertelen lesz.
Másképp fogalmazva: nem elegendő önmagában egy rejtett aria-label egy elem megnevezésére, ha egyáltalán lehetséges vizuális címkét is adni neki. A legjobb, ha az elem látható szövege és a programozott neve pontosan megegyezik.
Ha a design miatt mindenképp csak ikont használunk (pl. egy kuka ikon a „Törlés” művelethez), akkor legalább gondoskodjunk arról, hogy a felhasználó számára egyértelmű legyen a funkció (pl. címsorban jelenjen meg a művelet szövege, vagy fókuszra jelenjen meg tooltip formájában). Emellett az aria-label-t úgy adjuk meg, hogy tartalmazza a közismert kulcsszót (jelen példában a „Törlés” szót) – így ha a felhasználó bemondja, működni fog a vezérlés.
Haladó technika lehet a vizuális címke kiegészítése rejtett szöveggel: például egy „Küldés” feliratú gomb esetén az accessible name bővíthető „Küldés üzenet” értékre úgy, hogy a „üzenet” szó csak képernyőolvasóval hallható (rejtett <span> elem). Fontos azonban, hogy a látható „Küldés” szó ebben az esetben is változatlan formában szerepeljen a programozott név elején.
Összefoglalva: ahol csak lehetséges, használjunk vizuális szöveges címkéket a vezérlőelemekhez. Az aria-label hasznos kiegészítő vagy szükségmegoldás, de sose írjuk vele felül a látható feliratot úgy, hogy az kimaradjon az accessible name-ből. Ezzel nem csak a képernyőolvasót használókat segítjük, hanem a hangvezérlést is – hiszen a felhasználó által látott és kimondott szó egyezik azzal, amit a rendszer keres.
Konkrét fejlesztési technikák hangvezérléshez
Ebben a részben áttekintünk néhány gyakorlati példát és ajánlást arra, hogyan használjuk a HTML, JavaScript és ARIA eszköztárat a hangvezérlés támogatására. A fő cél, hogy minden interaktív elem hozzáférhető, egyértelműen megnevezett és billentyűzetről is működtethető legyen – ezek ugyanis a hangvezérlés alapfeltételei is.
Gombok és linkek használata
Használjunk valódi HTML gombokat (<button>) és linkeket (<a>): Ne kezeljünk kattintható elemként egy sima <div> vagy <span> tageket (JS eseménykezelővel), hacsak nem adunk meg megfelelő ARIA szerepet és nevét. A natív HTML gombok és hivatkozások eleve fókuszálhatók, aktiválhatók billentyűzetről (Enter vagy Space), és a segédeszközök – így a hangvezérlők is – automatikusan ismerik őket.
Például egy <button>Mentés</button> elemet a felhasználó egyszerűen a „Mentés” szó kimondásával aktiválhat. Ezzel szemben egy <div class="button">Mentés</div> nem lesz „látható” a hangvezérlés számára, hacsak nem egészítjük ki pl. role="button" attribútummal és kezeljük a billentyűeseményeket is.
Adjunk egyedi és beszédes szöveget a linkeknek/gomboknak: Kerüljük a túl általános feliratokat, mint az „Kattints ide” vagy „Bővebben”, főleg ha több ilyen is van az oldalon. A hangvezérlő ilyenkor több azonos nevű elemet talál, és a felhasználónak számozás vagy egyéb kerülő út segítségével kell választania közülük. Jobb megoldás, ha a link szövege kontextusfüggően pontos (pl. „Bővebben a szolgáltatásainkról”).
Ha mégis ismétlődő linkszöveget használunk, ARIA-val kiegészíthetjük a hozzáférhető nevet (például aria-label="Bővebben a X témáról") – de ügyeljünk arra, hogy az eredeti „Bővebben” szó benne maradjon a névben.
Ikonos gombok megfelelő címkézése: Ha egy gombon csak ikon van (például ❤, ✕ stb.), mindig adjunk hozzá látható feliratot is, hogy a látó felhasználók – különösen a hangvezérlés használói – pontosan tudják, mit kell bemondaniuk. Emellett gondoskodjunk hozzáférhető névről a képernyőolvasó-felhasználók számára is, például aria-label attribútummal vagy egy vizuálisan rejtett szöveggel.
Például:
<!-- Ikon + látható felirat -->
<button aria-label="Kedvencekhez adás">
<svg aria-hidden="true" focusable="false">...</svg>
<span>Kedvencek</span>
</button>A fenti kódban a gombon látható a „Kedvencek” szöveg, amelyet a látó felhasználó be tud mondani, a képernyőolvasó pedig az aria-label alapján olvassa fel a pontos funkciót („Kedvencekhez adás”). Alternatív megoldásként, ha a vizuális felületbe nem fér el a teljes szöveg, a felirat lehet rövidebb (pl. „Kedvencek”), míg az aria-label tartalmazhat részletesebb leírást.
Űrlapok és űrlapelemek
Minden űrlapmezőhöz társítsunk <label> elemet: A szöveges beviteli mezők, legördülő listák, dátumválasztók stb. mellett mindig legyen egy látható szöveges címke. Ezt legkönnyebben a <label for="mezoId">Felirat:</label> szintaxissal érhetjük el. Így a mező programozott neve megegyezik a látható felirattal, és a felhasználó például a „Felirat” szó kimondásával a mezőre fókuszálhat.
Ha vizuális okokból nem akarunk külön feliratot, legalább az aria-label vagy aria-labelledby használatával adjunk nevet a mezőnek – de ismét, ha a mezőnek van placeholder szövege, azt mindenképp vegyük bele a programozott névbe. Ne hagyatkozzunk kizárólag a placeholderre címkeként, mert egyrészt nem minden segédeszköz kezeli azt teljes értékű címkeként, másrészt ha a mezőbe beírnak, a placeholder eltűnik. (Ráadásul a WCAG szerint a placeholder nem megfelelő helyettesítője a rendes címkének, és csak végső esetben tekinthető címkének, ha semmi más nincs.)
Csoportosítsunk és címkézzünk opciókat: Több kapcsolódó mező (pl. rádiógomb csoport vagy jelölőnégyzet lista) esetén használjunk csoportcímkéket is. Például egy fieldset-legend párossal keretezzük a csoportot, vagy használjunk aria-labelledby egy közös címkére. A rádiógombok és checkboxok közvetlen melletti szövegét tekintsük az egyedi címkéjüknek, és ezt kódoljuk le <label> elem használatával.
Ne próbáljuk meg az összes környező szöveget egyetlen névbe összevonni – a túl hosszú vagy összetett név rontja a hangvezérlés pontosságát és feleslegesen sokat olvastat a képernyőolvasóval. Inkább a közeli, egyértelmű szót vagy kifejezést adjuk meg címkének. Például:
<fieldset>
<legend>Érdeklődési kör</legend>
<label><input type="checkbox" name="topic" value="tech"> Technológia</label>
<label><input type="checkbox" name="topic" value="art"> Művészet</label>
</fieldset>A fenti példában a checkboxok látható címkéi („Technológia”, „Művészet”) lesznek a kimondandó parancs-szavak. A csoport legendje kontextust ad ugyan, de nem szükséges azt is bemondani a kijelöléshez – sőt, ha ezt is belesűrítenénk az egyes checkboxok nevébe, az megnehezítené a vezérlést. A hangfelismerő az egyszerű, egyértelmű címkékkel dolgozik a legjobban.
Űrlapvalidáció és üzenetek: Ha egy űrlap kitöltésekor hibaüzenet jelenik meg, érdemes azt is akadálymentesen kezelni (aria-live régiókkal vagy megfelelő hibajelöléssel), hogy a hangvezérlést használó felhasználó értesüljön róla. Bár ez inkább a képernyőolvasós felhasználóknak fontos, a hangvezérlést használó felhasználó is lehet látássérült, ill. a diktált szöveg után hasznos, ha a rendszer felolvassa a hibaokokat.
WCAG követelmények a hangvezérlés támogatására
A Web Akadálymentesítési Útmutató (WCAG) 2.1 és 2.2 közvetlenül is foglalkozik a beszéddel történő vezérlés kérdésével. A legfontosabb ide vágó kritérium a 2.5.3 – Label in Name, amely kimondja: „Ha egy felhasználói felület komponensnek van szövegesen megjelenített címkéje, akkor annak a szövegnek a programozott névben is szerepelnie kell.”
Ennek célja éppen az, hogy a hangvezérlést használó felhasználó a látott címkét bemondva működtethesse az adott elemet. A fejlesztők számára ez azt jelenti, hogy a korábban tárgyalt elvet kötelező érvényű szabályként kell kezelniük: a vizuális felirat és az accessible name egyezzen meg vagy az utóbbi tartalmazza előbbit.
A WCAG 2.5.3 teljesítéséhez több ajánlott technika is tartozik – például a W3C G208 és G211 sorszámú technikái pont azt mutatják be, hogyan kell a látható címkét beépíteni a programozott névbe. Gyakori hiba például, ha egy gomb ikonja mellett a fejlesztő aria-label-lel ad egy hosszabb leírást, de abban nem szerepel az ikon melletti szöveg. Ezt a WCAG egyértelműen hibának (failure) minősíti.
Ezen túlmenően a WCAG más sikerkritériumai is közvetetten támogatják a hangvezérlést. A 2.1.1 Billentyűzet hozzáférhetőség előírja, hogy minden funkciónak elérhetőnek kell lennie billentyűzettel is – ahogy már említettük, ez alapfeltétel a beszéddel vezérléshez is.
A 4.1.2 Név, Szerep, Érték pedig megköveteli, hogy minden interaktív elemnek legyen neve és szerepe; enélkül nemcsak a képernyőolvasó, de a hangvezérlő sem fog tudni az elemre hivatkozni vagy azt aktiválni.
Továbbá a 3.3.2 Címkék vagy utasítások kimondja, hogy űrlapmezők mellett legyenek egyértelmű instrukciók/címkék – ami, ahogy láttuk, a hangvezérlésnél is kritikus.
Összefoglalás
A hangvezérlés támogatása a weboldalakon nem különálló, titokzatos tudomány, hanem az általános akadálymentesítési gyakorlatok szerves része. A szemantikus HTML, a helyes ARIA használat, a látható és programozott címkék egyezése, valamint a billentyűzettel történő működtethetőség mind hozzájárulnak ahhoz, hogy egy weboldal hangparancsokkal is könnyen kezelhető legyen.
Fejlesztőként érdemes már a tervezés korai szakaszában gondolni ezekre: egy jól strukturált, szabványos kód nagyban megkönnyíti a hangalapú navigációt.
A modern hangvezérlő eszközök – legyenek beépítve a rendszerbe vagy külön alkalmazásként – a webes szabványokra támaszkodnak: az általunk definiált accessible name-ekre, szerepekre és eseményekre. Ha ezeket következetesen és tudatosan alakítjuk ki, a hangvezérlésű felhasználók is magabiztosan fognak tudni navigálni és műveleteket végezni az oldalunkon.
Összhangban a WCAG előírásaival és a bevált iparági gyakorlatokkal, a hangvezérlés támogatása végső soron minden felhasználó javát szolgálja – hiszen egy jobban strukturált, egyértelmű felület mindenkinek előnyös.
Vélemény, hozzászólás?