Rövid, határozott ellenőrzőlista az akadálymentes webes gombokhoz

A gombok akadálymentességi tanácsaival kapcsolatos probléma

A legtöbb, gombok akadálymentességéről szóló útmutatás két táborba esik: vagy egy 40 oldalas WCAG-értelmezés, amelyet senki sem olvas el, vagy egy homályos javaslat, hogy "tedd akadálymentessé a gombokat", konkrét lépések nélkül. Egyik sem segít, amikor csütörtökön kell élesítened egy funkciót.

Ez az ellenőrzőlista azt az öt leggyakoribb gomb-akadálymentességi hibát fedi le, amelyet éles rendszerekben látunk. Nem tesz WCAG-szakértővé, de elkapja azokat a problémákat, amelyek ténylegesen érintik a felhasználókat.

1. Gombokhoz használd a button elemet

Ha gombként viselkedik, legyen <button> elem. Ne <div> onclick-kel, ne <span> role="button"-nal, és ne <a> href="#"-fel és preventDefaulttal.

A <button> elem alapból ad billentyűzetes navigációt, fókuszkezelést és képernyőolvasó-bejelentéseket. Amikor <div>-et használsz, mindezt nulláról építed újra — és el fogod rontani.

Az egyetlen kivétel: ha a művelet új oldalra navigál vagy módosítja az URL-t, használj <a> elemet. A linkek és a gombok szemantikailag különböznek. A képernyőolvasót használók elemtípus szerint navigálnak, és azt várják, hogy a gombok műveleteket hajtsanak végre, a linkek pedig navigáljanak.

2. A célterület legyen legalább 44×44 pixel

A WCAG 2.5.5 (Level AAA) megköveteli, hogy az interaktív elemek minimális célmérete 44×44 CSS pixel legyen. Ez nem a vizuális méretről szól — hanem a kattintható területről.

Lehet egy kicsi vizuális gombod megfelelő belső térközzel, vagy kiterjesztheted a célterületet egy pszeudoelemmel. Az számít, hogy a felhasználónak ne kelljen hajszálpontosan céloznia.

A mobilfelhasználók, a motoros nehézségekkel élők és bárki, aki mozgás közben használ egy eszközt, el fogja véteni a kis célpontokat. Egy 24×24 pixeles ikongomb letisztultnak tűnhet, de használhatósági hiba.

3. Adj látható fókuszállapotokat, amelyek nem csupán böngészőalapértelmezések

A böngésző alapértelmezett fókuszgyűrűje jobb, mint a semmi, de böngészőnként következetlen, és bizonyos háttereken gyakran láthatatlan. Olyan egyedi fókuszállapotra van szükséged, amely működik a design rendszeredben.

Egy jó fókuszjelzőnek három tulajdonsága van:

• Magas kontraszt: legalább 3:1 a szomszédos színekhez képest
• Látható eltolás: ne rejtse el a gomb saját kerete vagy háttere
• Következetes forma: a felhasználóknak az egész felületen fókuszjelzőként kell felismerniük

Ne távolítsd el az outline: none-t anélkül, hogy valami jobbal helyettesítenéd. És ne tedd a fókuszállapotokat annyira finommá, hogy csak te lásd őket tökéletes fényviszonyok között.

4. Írj olyan gombfeliratokat, amelyek kontextus nélkül is értelmesek

A képernyőolvasót használók gyakran gombok között ugrálva navigálnak. Ilyenkor a gombfeliratok listáját hallják, környező kontextus nélkül.

Egy "Tudj meg többet" feliratú gomb ebben a listában haszontalan. Ugyanígy a "Kattints ide" vagy a "Küldés" is. A feliratnak a műveletet kell leírnia: "Az akadálymentességi ellenőrzőlista letöltése", "Feliratkozás a frissítésekre", "Hozzászólás törlése".

Ha a design rövid vizuális feliratot követel meg, használj aria-label attribútumot leíró alternatíva megadásához. De a jobb megoldás az, ha olyan feliratokat írsz, amelyek mindenkinek működnek.

Csak ikonból álló gomboknál az aria-label kötelező. Egy kizárólag nagyítóikont tartalmazó gombnak aria-label="Search" vagy azzal egyenértékű szöveg kell. Az ikon nem hozzáférhető a képernyőolvasók számára.

5. Biztosíts megfelelő színkontrasztot

A WCAG 2.1 legalább 4.5:1 kontrasztarányt követel meg normál szöveghez és 3:1-et nagy szöveghez (18pt vagy 14pt félkövér). A gombfeliratok általában normál szövegnek számítanak.

A világosszürke szöveg fehér gombon megbukik. A halványkék világoskék háttéren megbukik. Ezek a kombinációk kifinomultnak tűnhetnek, de kizárják a gyengénlátó, színvak felhasználókat, illetve bárkit, aki erős napsütésben nézi a képernyőt.

Használj kontrasztellenőrzőt már a tervezés során, ne csak az élesítés után. Az éles rendszerben történő kontrasztjavítás drága, mert gyakran design rendszerszintű módosításokat igényel.

Ha képfeldolgozó eszközökkel dolgozol, a kliensoldali feldolgozás segíthet megőrizni a magánszférát akadálymentes vizuális elemek generálása közben — különösen színkombinációk tesztelésekor vagy előnézeti állapotok létrehozásakor.

Amit ez az ellenőrzőlista nem fed le

Ez a lista szándékosan hiányos. Nem tér ki a letiltott állapot szemantikájára, a betöltési állapotokra, a hibakezelésre vagy az összetett gombmintákra, például az osztott gombokra vagy a legördülő menüket nyitó vezérlőkre. Ezekhez a mintákhoz saját útmutatás szükséges.

Nem tárgyalja azt a tágabb kérdést sem, hogy mikor használj gombot más interaktív elemek helyett. Ehhez értened kell a szemantikus HTML-t és az akadálymentességi fát — olyan témák, amelyek saját cikkeket érdemelnek.

Amit viszont lefed, az a könnyen elérhető eredmény: azok a hibák, amelyek szinte minden code review során előkerülnek, a legtöbb felhasználót érintik, és fejlesztés közben a legkönnyebben javíthatók.

Hogyan építsd be ezt a munkafolyamatodba

Az akadálymentességi ellenőrzőlisták csak akkor működnek, ha a fejlesztési folyamat részei, nem pedig utólag rájuk csavarozott kiegészítések. Így érheted ezt el:

Designban: adj fókuszállapotokat és célterület-annotációkat a design fájljaidhoz. Ne hagyd, hogy ezeket a fejlesztőknek kelljen kitalálniuk.

Code review-ban: ellenőrizd a <button> elemeket, az ikongombokon lévő aria-label attribútumot és a fókuszállapot CSS-ét. Ezek gyorsan észrevehetők.

Tesztelésben: tabulátorral járd be a felületet billentyűzettel. Ha nem érsz el egy gombot, vagy nem látod, hol van a fókusz, akkor a felhasználóid sem fogják.

Dokumentációban: vedd fel a gombok akadálymentességi követelményeit a komponenskönyvtáradba. Legyen könnyebb a helyes dolgot tenni, mint a rosszat.

Ha éles környezeti problémákat hibakeresel, a HTTP fejlécek és átirányítások vizsgálatára szolgáló eszközök segíthetnek megérteni, hogyan értelmezik a kisegítő technológiák a jelölésedet — különösen navigáció utáni fókuszkezelési hibák feltárásakor.

A munka kihagyásának ára

Az akadálymentesítetlen gombok nemcsak a WCAG-megfelelésen buknak el — munkafolyamatokat törnek meg. Az a felhasználó, aki nem tud rákattintani egy beküldés gombra, nem tud kitölteni egy űrlapot. Az a felhasználó, aki nem látja a fókuszállapotokat, nem tud billentyűzettel navigálni. Az a felhasználó, aki nem tudja megkülönböztetni a gomb szövegét a háttértől, nem tudja elolvasni a feliratot.

Ezek nem szélsőséges esetek. A világ népességének nagyjából 15%-a él valamilyen fogyatékossággal, az átmeneti korlátozottságok pedig (elromlott egér, erős napsütés, karban tartott baba) végül mindenkit érintenek.

A jó hír az, hogy a gombok akadálymentessége többnyire megoldott problémákból áll. Nem kell új mintákat feltalálnod vagy böngészőtámogatásra várnod. Csak helyesen kell használnod a platformot, és tesztelned kell a munkádat.

Fő tanulságok

• Gombokhoz használj <button> elemeket, navigációhoz pedig <a> elemeket — a szemantikai különbség számít a kisegítő technológiák számára
• Biztosíts legalább 44×44 CSS pixeles célterületeket, hogy alkalmazkodj a motoros nehézségekhez és a mobilfelhasználókhoz
• Adj látható, magas kontrasztú fókuszállapotokat, amelyek működnek a design rendszereden keresztül
• Írj olyan gombfeliratokat, amelyek önmagukban olvasva is értelmesek, és használj aria-label attribútumot a csak ikonból álló gombokhoz
• Ellenőrizd a színkontrasztot már a tervezés során, ne az élesítés után, hogy elkerüld a drága utólagos átalakításokat

FAQ

Q: Használhatok role="button" attribútumot egy <div> elemen, ha hozzáadok billentyűzetkezelőket?

A: Használhatsz, de nem kellene. Kézzel kell kezelned az Entert, a Space-t, a fókuszkezelést és a letiltott állapotokat — és elkerülhetetlenül kihagysz valamit. A <button> elem mindezt alapértelmezés szerint helyesen kezeli. Használd azt.

Q: Mi a helyzet az állapotot váltó gombokkal, például egy lejátszás/szünet gombbal?

A: Használd az aria-pressed="true" vagy aria-pressed="false" értéket az aktuális állapot jelzésére. A gomb feliratának annak a műveletnek is meg kell felelnie, amely kattintásra történik ("Szünet", amikor lejátszás folyik, "Lejátszás", amikor szünetel), nem pedig az aktuális állapotnak. A képernyőolvasót használóknak azt kell tudniuk, mit fog tenni a gomb, nem azt, milyen állapotban van a rendszer.

Q: A letiltott gomboknak is meg kell felelniük a kontrasztkövetelményeknek?

A: A WCAG 2.1 mentesíti a letiltott vezérlőket a kontrasztkövetelmények alól (1.4.3), de ez vitatott. A gyenge kontrasztú letiltott gombokat mindenkinek nehéz észlelni. Ha letiltott gombot jelenítesz meg, legyen olvasható. Még jobb, ha elrejted, vagy elmagyarázod, miért van letiltva.

Q: Hogyan tesztelhetem a gombok akadálymentességét képernyőolvasó nélkül?

A: Használd a billentyűzetedet. Tabulátorral járd be a felületet, és ellenőrizd, hogy minden gombot elérsz-e, látod-e, hol van a fókusz, és aktiválhatók-e a gombok Enterrel vagy Space-szel. Ez a legtöbb problémát elkapja. Mélyebb teszteléshez használd a Chrome vagy Firefox DevTools akadálymentességi vizsgálóját a kiszámított szerep és címke ellenőrzéséhez.

Q: Mi a különbség az aria-label és az aria-labelledby között?

A: Az aria-label közvetlenül ad meg egy szöveges karakterláncot. Az aria-labelledby egy másik elem ID-jára hivatkozik, amelynek szöveges tartalma lesz a címke. Használd az aria-labelledby attribútumot, ha a címkeszöveg már létezik máshol a DOM-ban. Használd az aria-label attribútumot, ha olyan címkét kell megadnod, amely nem látható a képernyőn.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM