Szemantika, billentyűzet és képernyőolvasó

Célok

A lecke végére meg tudod mondani, miért jobb a natív HTML-elem egy ARIA-val feljavított div-nél, végig tudsz menni egy oldalon billentyűzettel és értékelni tudod a fókuszt, el tudod magyarázni, mit lát a képernyőolvasó, és értelmezni tudsz egy automatikus akadálymentességi ellenőrzés eredményét, annak korlátaival együtt.

Miért nem elég, ha „jól néz ki”?

A szemantikus HTML (3.2) az oldal elemeinek szerepét is leírja, nem csupán a kinézetét. A billentyűzettel navigáló és a képernyőolvasót használó ember számára különösen fontos, hogy a címsorok, linkek, gombok, űrlapok és visszajelzések értelmezhető szerkezetet alkossanak. Ha egy kattintható div ugyanúgy néz ki, mint egy gomb, a szemnek mindegy, a segítő technológiának azonban nem.

A szemantika: mit jelent egy elem?

Nézzünk két megoldást egy kattintható elemre. Az egyik egy div, amelyre kattintáskezelő került, a másik egy valódi button vagy a elem. A képernyőn mindkettő lehet kék, lekerekített téglalap. A böngésző és a segítő technológia számára azonban eltérnek: a link egy másik helyre vagy erőforráshoz navigál; a gomb műveletet indít, például elküld egy űrlapot.

A szemantikus HTML azt jelenti, hogy a dokumentum jelentéséhez illő elemet választjuk. A header, nav, main, article, aside és footer tájékozódási pontokat (landmark) ad. A h1–h6 címsorok hierarchiát fejeznek ki. A p bekezdés, az ul és ol lista, a table táblázatos adat, a label az űrlapmező megnevezése.

Ez a szerkezet több csatornán hasznos: a képernyőolvasó felhasználó címsorok szerint ugorhat; a keresőmotor jobban érti, mi a fő tartalom (9.5); a böngésző és a későbbi karbantartó számára is olvashatóbb a kód.

flowchart LR
    H[HTML szemantika] --> A[Akadálymentességi fa]
    A --> R[Képernyőolvasó]
    H --> B[Billentyűzetes fókusz]
    B --> U[Felhasználói művelet]

Címsorok: nem betűméretek

Gyakori hiba, hogy a címnek szánt felirat csak nagyobb, félkövér div vagy span. Ettől vizuálisan címszerű, de a dokumentumban nem címsor. Ugyanilyen hiba, ha a h1–h6 elemeket csak a méretük miatt választjuk. Egy oldalon általában van egy főcím (h1), annak témáit h2-k, azok részeit h3-ak tagolják. Képzeljük el az oldalt tartalomjegyzékként: ha abból nem érthető a gondolatmenet, a címsorszerkezeten javítani kell.

A billentyűzet nem másodlagos beviteli mód

Sokan egérrel használják a webet, de nem mindenki. A Tab billentyű jellemzően a következő fókuszálható elemre lép, a Shift+Tab visszafelé. Enterrel egy link vagy gomb aktiválható, a Space gyakran gombot, jelölőnégyzetet vagy kapcsolót működtet. A nyílbillentyűk szerepe a vezérlőtípustól függ (rádiógomb-csoport, menü).

A fókuszsorrend a tartalom logikus sorrendjét kövesse. A látvány CSS-sel átrendezhető, de a HTML sorrendje továbbra is meghatározza, hogyan halad a billentyűzet és a képernyőolvasó. Az ismétlődő, hosszú menü miatt érdemes „Ugrás a fő tartalomra” hivatkozást adni, amely általában rejtett, de fókuszba kerüléskor láthatóvá válik.

Hogyan „lát” a képernyőolvasó?

A képernyőolvasó olyan segítő technológia, amely beszéddel vagy Braille-kijelzőn közvetíti a digitális felületet. Nem a képernyő pixeleit értelmezi, hanem a böngésző által rendelkezésre bocsátott akadálymentességi fát: ebben szerepel az elem szerepe (role), neve (name), állapota (state) és értéke (value).

Egy jó gombnál a felhasználó azt hallhatja, hogy „Kosár megnyitása, gomb”. Egy hibás div esetén csak annyit, hogy „Kosár megnyitása”, vagy még azt sem. Egy beviteli mezőnél a label kapcsolja össze a mezőt a kérdésével: „E-mail-cím, szerkesztőmező”. A csak helykitöltőként megjelenő placeholder nem helyettesíti a címkét: gépeléskor eltűnik, kontrasztja gyenge lehet, és nem minden helyzetben ad megbízható nevet.

A képernyőolvasó felhasználó nem feltétlenül olvassa végig lineárisan az oldalt: listázhatja a címsorokat, a linkeket, az űrlapmezőket vagy a tájékozódási pontokat. Ezért zavaró a sok „Tovább” és „Kattints ide” link: egy listában egymás után csak azonos, jelentés nélküli címkék jelennek meg. A link szövege önmagában is mondja el a célját: „A felvételi határidők megnyitása”.

Űrlapok és hibák

Az űrlapokban a látható címke mellett a kapcsolat legyen gépileg is megfogalmazott: a label for attribútuma a mező id értékére mutat. Így a címkére kattintva is a mező aktiválódik, és a segítő technológia helyesen nevezi meg. Hiba esetén ne csak piros színt használjunk: a hibaüzenet mondja meg, melyik mezőről van szó, mi a gond, és lehetőleg a javítás módját is. Beküldés után a fókuszt érdemes az első hibás mezőre vagy a hibák összegzésére irányítani.

ARIA: fontos eszköz, de nem első választás

Az ARIA (Accessible Rich Internet Applications) attribútumok szerepeket, neveket és állapotokat adhatnak olyan összetett vezérlőkhöz, amelyekhez nincs natív HTML-megfelelő. Például egy saját készítésű, összecsukható panelnél az aria-expanded jelezheti, hogy a tartalom nyitott-e; egy ikonból álló gomb aria-label segítségével kaphat beszédes nevet.

Az alapelv: először natív HTML. A W3C ARIA-útmutatója szerint a „nincs ARIA jobb, mint a rossz ARIA”, mert az ARIA-szerepek nem adnak a böngészőnek billentyűzetes viselkedést vagy stílust: ha egy div-re role="button" kerül, a billentyűkezelést, a fókuszt és a letiltott állapotot nekünk kell megírni, és a szerep egy „ígéret”, amit be kell tartani. Az ARIA nem tesz működővé egy elemet, csak információt közöl róla. A button elem mindezt eleve tudja.

Mit mond az automatikus ellenőrzés? Egy kipróbált példa

Készítettünk két változatot egy kurzusoldalból: egy szándékosan hibás („rossz”) és egy javított („jó”) oldalt. A rossz oldalon nincs lang, title, main és alt, a szöveg halványszürke (#aaa, 2,32:1), a „gomb” egy div, a link szövege „Kattints ide”, a beviteli mező csak placeholder-t kapott. A jó oldal ezeket javítja (lang, title, main, alt, button, label, #444 szöveg).

Mindkettőt lefuttattuk a Lighthouse automatikus ellenőrző eszközzel (13.5.0-s verzió, Chrome 154 böngészőben, szimulált mobil környezetben). Az akadálymentességi pontszám:

Oldal	Akadálymentesség (0–100)	A Lighthouse által jelzett hibák
Rossz	52	nincs lang, nincs title, a képnek nincs alt, nincs main régió, elégtelen kontraszt
Jó	100	–

Fontos viszont, mit nem jelzett az eszköz a rossz oldalon:

• a div, amelyet kattintható „gombnak” szántunk (a „button-name” vizsgálat nem alkalmazható, mert nincs button elem);
• a „Kattints ide” link jelentés nélküli szövegét (a link-vizsgálat azt nézi, hogy van-e neve, azt nem, hogy beszédes-e);
• a helykitöltő-szöveggel „címkézett” mezőt, amelyet az eszköz átengedett;
• hogy a h3 van-e előbb, mint a h1 (a címsor-sorrendi vizsgálat nem jelzett hibát).

Az automatikus ellenőrző tehát hasznos előszűrő, de nem minősít: a 100 pontszám nem jelent hibátlan oldalt, és az 52 sem tárja fel az összes problémát. Az eszközök nem tudják megítélni, hogy egy alternatív szöveg értelmes-e, vagy hogy egy folyamat érthető-e. A teljes képhez kézi próba (billentyűzet, képernyőolvasó) is kell.

Végigvezetett példa: a Kurzuspont bejelentkezési ablaka

Egy „Bejelentkezés” gomb megnyit egy párbeszédablakot. Egérrel ez egyszerűnek tűnik, de billentyűzettel több kérdés merül fel: megnyitáskor a fókusz az ablak értelmes első elemére kerül (a címre vagy az e-mail mezőre); Tab-bal a fókusz az ablakon belül marad; Esc-pel bezárható, ha ez nem okoz adatvesztést; bezáráskor a fókusz visszatér arra a gombra, amelyik megnyitotta. Az ablaknak egyértelmű neve kell, hogy legyen. Egy jó fókuszkezelés egérrel és billentyűzettel egyaránt kiszámíthatóbbá teszi a felületet.

Egyszerű ellenőrzési rutin

Már fejlesztés közben sok hiba felfedezhető különleges eszköz nélkül. Tegyük félre az egeret, töltsük újra az oldalt, majd kizárólag Tab, Shift+Tab, Enter, Space és Esc segítségével próbáljuk elvégezni a fő feladatot. Látszik-e a fókusz minden pillanatban? Eljutunk-e minden lényeges vezérlőhöz? Nem ragadunk-e egy megnyitott komponensben? Érdemes a böngésző fejlesztői eszközével az akadálymentességi fát is megnézni: itt gyakran azonnal kiderül, ha egy ikonos gombnak nincs neve, vagy egy címsornak tűnő felirat valójában csak formázott szöveg. Ez nem helyettesíti a képernyőolvasóval végzett próbát, de gyors visszajelzés.

Gyakori tévhitek

Állítás	Pontosítás
„Ha rákattintható, akkor hozzáférhető.”	A kattinthatóság nem jelenti, hogy billentyűzettel elérhető, fókuszálható és helyesen bejelentett vezérlő.
„A tabindex rendbe teszi a sorrendet.”	A pozitív tabindex értékek gyakran kiszámíthatatlan sorrendet adnak; a helyes HTML-sorrend az alap.
„A placeholder a mező címkéje.”	Nem az: rövid segítség lehet, de az állandó, programból azonosítható címkét nem pótolja.
„Mindenhez ARIA kell.”	A túlzott vagy rossz ARIA ront; a natív HTML sok feladatot megold.
„A 100 pontos Lighthouse-eredmény = akadálymentes.”	Az eszköz csak a gépileg ellenőrizhető hibákat találja meg.

Röviden

• A szemantikus elem a szerepét közli a segítő technológiával, nem csak a kinézetét.
• A billentyűzetes használat alapvető: látható fókusz, logikus sorrend, kihagyó link.
• A képernyőolvasó az akadálymentességi fát olvassa (szerep, név, állapot, érték).
• Az ARIA csak a natív HTML hiányát pótolja; rossz ARIA rosszabb, mint a nincs ARIA.
• Az automatikus ellenőrző hasznos, de nem teljes: kézi próba is kell.

Ellenőrző kérdések

1. Mi a különbség egy button és egy div role="button" között?
2. Mi történik, ha eltüntetjük a fókusz körvonalát?
3. Miért nem pótolja a placeholder a label elemet?
4. Mit jelzett és mit nem jelzett a Lighthouse a hibás kurzusoldalon?

Tanulási források

• ARIA Authoring Practices: Read Me First (W3C) — a „nincs ARIA jobb, mint a rossz ARIA” elv, angolul.
• WCAG 2.2 (W3C) — a sikerkritériumok.