A lecke végére el tudod magyarázni, miért nem egy szűk csoport ügye az akadálymentesség, ismered a WCAG négy alapelvét (POUR) és szintjeit, ki tudod számolni egy szín–háttér páros kontrasztarányát, és tudod, hogyan kell egy képhez alternatív szöveget írni.
Miért beszélünk erről egy webes tárgyban?
Egy egyetemi tárgyfelvételi oldalt sokféle ember használ. Az egyik hallgató színtévesztő, ezért nem látja a piros hibaüzenetet. A másik kézsérülés miatt néhány hétig csak billentyűzettel dolgozik. Egy harmadik zajos vonaton nézi a videós tájékoztatót, ezért feliratot szeretne. A negyedik lassú, régi telefonon, erős napsütésben próbálja elolvasni az oldalt. A probléma nem az, hogy ezek az emberek „rendellenes” körülmények között használják a rendszert, hanem az, ha a rendszer csak egy elképzelt, egérrel dolgozó, jó látású, gyors hálózaton ülő felhasználóra készült.
A web eredeti ígérete az volt, hogy az információ eszköztől és helytől függetlenül elérhető (1.1). Az akadálymentesség (accessibility) ezt az ígéretet teszi komollyá: a tartalmat és a funkciókat a lehető legtöbb ember, a lehető legtöbb helyzetben tudja használni. Üzleti, jogi és etikai okai is vannak, de fejlesztői szemmel a legegyszerűbb indok az, hogy egy szolgáltatás csak akkor teljesíti a feladatát, ha a célközönség valóban használni tudja.
Az inkluzív tervezés azt hangsúlyozza, hogy ne a végén, egy szűk csoport számára próbáljuk kijavítani a rendszert, hanem már a tervezéskor kérdezzük: ki maradhat ki ebből a döntésből? Egy valódi gomb alapból fókuszálható és billentyűzettel aktiválható; egy kattintható div utólagos javítása sok elfelejtett részletet hoz magával (lásd 9.2).
Akadályok: nem csak fogyatékosságról van szó
Tartós: vak vagy gyengénlátó ember képernyőolvasót használ, siket felhasználónak felirat kell, a mozgáskorlátozott ember nem feltétlenül használ egeret.
Átmeneti: eltört kar, szemészeti beavatkozás, migrén, ideiglenes hallásprobléma.
Helyzeti: napsütésben gyenge a kijelző kontrasztja, a felhasználó babát tart a kezében, vagy a videó hangját nem kapcsolhatja be egy könyvtárban.
Ezért hasznos a „képességek spektruma” szerint gondolkodni. A felirat a siket felhasználónak nélkülözhetetlen, de nyelvtanuláskor vagy hang nélküli videónézéskor sok más embernek is segítség. A jó címsorszerkezet a képernyőolvasóval dolgozóknak navigációs eszköz, de mindenkinek áttekinthetőbb tartalmat ad.
flowchart LR
C[Tartalom] --> P[Észlelhetőség]
C --> K[Kezelhetőség]
C --> E[Érthetőség]
C --> M[Robusztusság]
A WCAG szemlélete: POUR
A WCAG (Web Content Accessibility Guidelines) a W3C (1.2) webes akadálymentességi irányelve. A W3C oldala szerint a jelenlegi verzió a WCAG 2.2: nem váltja fel a 2.1-et és a 2.0-t, hanem visszafelé kompatibilis, vagyis a 2.2-nek megfelelő tartalom a korábbiaknak is megfelel. A WCAG 2.2 egyetlen korábbi követelményt, a 4.1.1 Parsing-ot elavultnak minősítette. A WCAG 3 még korai tervezet. Az irányelv nem ellenőrzőlista-varázslat, hanem gondolkodási keret. Négy elve a POUR betűszóval jegyezhető meg:
Elv
Kérdés
Példa
Perceivable, észlelhető
A felhasználó fel tudja venni az információt?
Képhez alternatív szöveg, videóhoz felirat, elég kontraszt.
Operable, működtethető
Minden funkció kezelhető egér nélkül is?
Billentyűzetes elérés, látható fókusz, logikus sorrend.
Understandable, érthető
Érthető a nyelv és a viselkedés?
Címkézett mezők, a hibaüzenet megmondja, mi a baj és hogyan javítható.
Robust, robusztus
Különféle böngészőkben és segítő technológiákkal is értelmezhető?
Szabványos, szemantikus HTML (9.2).
A hibaüzenet-példa: „Hibás adat” nem segítség; „Az e-mail-címben hiányzik a @ jel” már igen.
Szintek
A WCAG a megfelelést A, AA és AAA szintekben fogalmazza meg. A gyakorlatban az AA szint gyakori cél. A lényeg azonban nem a „matrica”: egy formálisan megfelelő oldal is lehet nehezen használható, ha a valós felhasználói feladatokat nem próbáltuk ki.
A WCAG 2.2 AA szint néhány, a tananyagban is érintett követelménye:
Kontraszt (1.4.3): a normál szöveg és a háttér kontrasztaránya legalább 4,5:1, nagy szövegnél legalább 3:1.
Nem szöveges kontraszt (1.4.11): a felhasználói felület elemeinek és az információhoz szükséges grafikáknak legalább 3:1 a kontrasztjuk a szomszédos színekhez képest.
Célméret (2.5.8, új a 2.2-ben): a mutatóeszközzel (ujj, egér) érintett célpontok legalább 24×24 CSS pixelesek, a specifikációban felsorolt kivételekkel (például elegendő térköz vagy beágyazott szöveg).
Fókusz nem takarható ki (2.4.11, új a 2.2-ben): a billentyűzettel fókuszált elemet ne takarja el teljesen másik elem (például egy rögzített fejléc).
Kontraszt, szín és olvashatóság
A kontrasztarány azt fejezi ki, mennyire különül el a szöveg a háttértől: két szín relatív fényességének arányából számolják, 1:1 (azonos szín) és 21:1 (fekete–fehér) között. Ez nem ízléskérdés: gyenge kijelzőn, fáradt szemmel vagy erős fényben a jól látó felhasználó is elveszítheti az információt. A WCAG képlete szerint számolva, fehér háttéren:
Szövegszín
Kontrasztarány
4,5:1 (normál szöveg)
3:1 (nagy szöveg, felület elem)
#aaaaaa (halvány szürke)
2,32:1
nem felel meg
nem felel meg
#767676
4,54:1
megfelel (épp)
megfelel
#595959
7,00:1
megfelel
megfelel
#17365d (sötétkék)
12,19:1
megfelel
megfelel
#ff0000 (piros)
4,00:1
nem felel meg
megfelel
(Az értékeket a WCAG relatív fényesség-képletével Node.js-ben számoltuk ki.) A piros példája tanulságos: ugyanaz a szín nagy címsornak jó, a törzsszövegnek nem.
Alternatív szöveg: a kép jelentését írjuk le
Az alt attribútum nem a fájlnév ismétlésére való. A chart-final-v2.png képernyőolvasóval semmit sem mond. Az alternatív szöveg a kép adott kontextusban betöltött szerepét közvetíti.
Kép
Jó alternatív szöveg
Miért?
Termékkép egy katalógusban
alt="Kék hátizsák elülső nézetben"
Azt írja le, ami a képen lényeges.
A cikk szövegét kiegészítő grafikon
alt="A regisztrációk száma januártól júniusig folyamatosan nő"
A fő üzenetet összegzi; a részletek a szövegben.
Pusztán dekoratív kép
alt=""
Üres alt: a képernyőolvasó átugorja, nem terheli zajjal.
Bonyolult ábra
rövid alt + részletes leírás a szövegben
A rövid szöveg nem elég az összes adat átadására.
Hiányzó alt esetén a segítő technológia nem tudja, hogy a kép dekoratív-e, ezért a képet jelölve vagy a fájlnevet felolvasva zajt vihet a felolvasásba; az üres alt ezzel szemben egyértelmű jelzés: ez a kép nem hordoz információt. A következő leckében látni fogjuk, hogy az automatikus ellenőrző a hiányzó alt-ot észreveszi, azt viszont nem tudja megítélni, hogy az alt szövege értelmes-e.
Végigvezetett példa: egy javított eseményoldal a Kurzuspontban
A Kurzuspont egy kari előadásának oldalán az időpont egy apró naptárikon mellett szerepel, a jelentkezés egy „Kattints ide!” feliratú színes doboz, a helyszín egy beágyazott térképen látszik. Egy inkluzívabb változatban az oldal valódi címsorokkal tagolt; az időpont szövegként is olvasható; a jelentkezés valódi, egyértelmű feliratú gomb vagy hivatkozás („Jelentkezés a szeptember 18-i előadásra”); a térkép alatt szöveges cím és útvonal-információ van; a szöveg kontrasztja legalább 4,5:1.
Nem készítettünk külön „vakoknak való” oldalt. Ugyanazt az oldalt tettük érthetőbbé mindenkinek. Ez a jó akadálymentességi döntések tipikus mintája.
Hogyan kezdjünk hozzá a gyakorlatban?
Egy meglévő oldal javítását a legfontosabb felhasználói útvonalakkal érdemes kezdeni: megtalálható-e az információ, el lehet-e indítani a fő műveletet, el lehet-e küldeni az űrlapot? Egy egyszerű kézi próba: Tab-billentyűvel járjuk végig az oldalt, nagyítsuk fel a böngészőt, kapcsoljuk ki a hangot egy videónál, és nézzük meg, marad-e érthető a felület. Az automatizált ellenőrzők gyorsak, de a találataikat emberi mérlegeléssel kell értelmezni (9.2).
Az akadálymentesség ne egyetlen ellenőrzési nap legyen a projekt végén. Egy új komponens tervezésekor a csapat rögtön dönthet a megfelelő HTML-elemről, a fókuszállapotról, a hibaüzenetekről és a kis képernyős viselkedésről; így kevesebb utólagos javításra van szükség.
Gyakori tévhitek
Állítás
Pontosítás
„Az akadálymentesség csak a vak felhasználóknak fontos.”
Látás, hallás, mozgás, figyelem, nyelv, eszköz és környezet is befolyásolhatja a használatot.
„Egy automatikus ellenőrző eszköz mindent megmond.”
Nem tudja megítélni, hogy egy alternatív szöveg értelmes-e, vagy egy folyamat érthető-e.
„Az AA szint betartása elég a használhatósághoz.”
A szint a minimum; a valódi feladatokat ki kell próbálni.
„A hozzáférhetőség korlátozza a kreativitást.”
Keretet ad: a látvány akkor jó, ha közben világos, kezelhető és stabil.
„A halvány szürke elegáns.”
A 2,3:1 kontrasztú szöveg sok embernek olvashatatlan.
Röviden
Az akadálymentesség a tartalom és a funkciók használhatósága minél több ember és helyzet számára; az akadály lehet tartós, átmeneti vagy helyzeti.
A WCAG 2.2 négy elve: észlelhető, működtethető, érthető, robusztus (POUR); szintjei A, AA, AAA.
Normál szövegnél legalább 4,5:1 kontraszt kell; színnel önmagában nem közvetíthetünk jelentést.
Az alternatív szöveg a kép szerepét írja le; dekoratív képnél az alt üres.
Az akadálymentesség tervezési szempont, nem utólagos javítás.
Ellenőrző kérdések
Mit jelent a POUR, és melyik elvhez tartozik a billentyűzetes elérés?
Megfelel-e a #767676 szövegszín fehér háttéren a normál szöveg AA-követelményének? Miért?
Mikor helyes az üres alt=""?
Mondj példát átmeneti és helyzeti akadályra!
Tanulási források
WCAG 2.2 (W3C) — az irányelv szövege és a sikerkritériumok, angolul; haladó olvasmány.
Akadálymentesség és inkluzív tervezés
Célok
A lecke végére el tudod magyarázni, miért nem egy szűk csoport ügye az akadálymentesség, ismered a WCAG négy alapelvét (POUR) és szintjeit, ki tudod számolni egy szín–háttér páros kontrasztarányát, és tudod, hogyan kell egy képhez alternatív szöveget írni.
Miért beszélünk erről egy webes tárgyban?
Egy egyetemi tárgyfelvételi oldalt sokféle ember használ. Az egyik hallgató színtévesztő, ezért nem látja a piros hibaüzenetet. A másik kézsérülés miatt néhány hétig csak billentyűzettel dolgozik. Egy harmadik zajos vonaton nézi a videós tájékoztatót, ezért feliratot szeretne. A negyedik lassú, régi telefonon, erős napsütésben próbálja elolvasni az oldalt. A probléma nem az, hogy ezek az emberek „rendellenes” körülmények között használják a rendszert, hanem az, ha a rendszer csak egy elképzelt, egérrel dolgozó, jó látású, gyors hálózaton ülő felhasználóra készült.
A web eredeti ígérete az volt, hogy az információ eszköztől és helytől függetlenül elérhető (1.1). Az akadálymentesség (accessibility) ezt az ígéretet teszi komollyá: a tartalmat és a funkciókat a lehető legtöbb ember, a lehető legtöbb helyzetben tudja használni. Üzleti, jogi és etikai okai is vannak, de fejlesztői szemmel a legegyszerűbb indok az, hogy egy szolgáltatás csak akkor teljesíti a feladatát, ha a célközönség valóban használni tudja.
Az inkluzív tervezés azt hangsúlyozza, hogy ne a végén, egy szűk csoport számára próbáljuk kijavítani a rendszert, hanem már a tervezéskor kérdezzük: ki maradhat ki ebből a döntésből? Egy valódi gomb alapból fókuszálható és billentyűzettel aktiválható; egy kattintható
divutólagos javítása sok elfelejtett részletet hoz magával (lásd 9.2).Akadályok: nem csak fogyatékosságról van szó
Ezért hasznos a „képességek spektruma” szerint gondolkodni. A felirat a siket felhasználónak nélkülözhetetlen, de nyelvtanuláskor vagy hang nélküli videónézéskor sok más embernek is segítség. A jó címsorszerkezet a képernyőolvasóval dolgozóknak navigációs eszköz, de mindenkinek áttekinthetőbb tartalmat ad.
flowchart LR C[Tartalom] --> P[Észlelhetőség] C --> K[Kezelhetőség] C --> E[Érthetőség] C --> M[Robusztusság]A WCAG szemlélete: POUR
A WCAG (Web Content Accessibility Guidelines) a W3C (1.2) webes akadálymentességi irányelve. A W3C oldala szerint a jelenlegi verzió a WCAG 2.2: nem váltja fel a 2.1-et és a 2.0-t, hanem visszafelé kompatibilis, vagyis a 2.2-nek megfelelő tartalom a korábbiaknak is megfelel. A WCAG 2.2 egyetlen korábbi követelményt, a 4.1.1 Parsing-ot elavultnak minősítette. A WCAG 3 még korai tervezet. Az irányelv nem ellenőrzőlista-varázslat, hanem gondolkodási keret. Négy elve a POUR betűszóval jegyezhető meg:
A hibaüzenet-példa: „Hibás adat” nem segítség; „Az e-mail-címben hiányzik a @ jel” már igen.
Szintek
A WCAG a megfelelést A, AA és AAA szintekben fogalmazza meg. A gyakorlatban az AA szint gyakori cél. A lényeg azonban nem a „matrica”: egy formálisan megfelelő oldal is lehet nehezen használható, ha a valós felhasználói feladatokat nem próbáltuk ki.
A WCAG 2.2 AA szint néhány, a tananyagban is érintett követelménye:
Kontraszt, szín és olvashatóság
A kontrasztarány azt fejezi ki, mennyire különül el a szöveg a háttértől: két szín relatív fényességének arányából számolják, 1:1 (azonos szín) és 21:1 (fekete–fehér) között. Ez nem ízléskérdés: gyenge kijelzőn, fáradt szemmel vagy erős fényben a jól látó felhasználó is elveszítheti az információt. A WCAG képlete szerint számolva, fehér háttéren:
#aaaaaa(halvány szürke)#767676#595959#17365d(sötétkék)#ff0000(piros)(Az értékeket a WCAG relatív fényesség-képletével Node.js-ben számoltuk ki.) A piros példája tanulságos: ugyanaz a szín nagy címsornak jó, a törzsszövegnek nem.
Alternatív szöveg: a kép jelentését írjuk le
Az
altattribútum nem a fájlnév ismétlésére való. Achart-final-v2.pngképernyőolvasóval semmit sem mond. Az alternatív szöveg a kép adott kontextusban betöltött szerepét közvetíti.alt="Kék hátizsák elülső nézetben"alt="A regisztrációk száma januártól júniusig folyamatosan nő"alt=""alt+ részletes leírás a szövegbenHiányzó
altesetén a segítő technológia nem tudja, hogy a kép dekoratív-e, ezért a képet jelölve vagy a fájlnevet felolvasva zajt vihet a felolvasásba; az üresaltezzel szemben egyértelmű jelzés: ez a kép nem hordoz információt. A következő leckében látni fogjuk, hogy az automatikus ellenőrző a hiányzóalt-ot észreveszi, azt viszont nem tudja megítélni, hogy azaltszövege értelmes-e.Végigvezetett példa: egy javított eseményoldal a Kurzuspontban
A Kurzuspont egy kari előadásának oldalán az időpont egy apró naptárikon mellett szerepel, a jelentkezés egy „Kattints ide!” feliratú színes doboz, a helyszín egy beágyazott térképen látszik. Egy inkluzívabb változatban az oldal valódi címsorokkal tagolt; az időpont szövegként is olvasható; a jelentkezés valódi, egyértelmű feliratú gomb vagy hivatkozás („Jelentkezés a szeptember 18-i előadásra”); a térkép alatt szöveges cím és útvonal-információ van; a szöveg kontrasztja legalább 4,5:1.
Nem készítettünk külön „vakoknak való” oldalt. Ugyanazt az oldalt tettük érthetőbbé mindenkinek. Ez a jó akadálymentességi döntések tipikus mintája.
Hogyan kezdjünk hozzá a gyakorlatban?
Egy meglévő oldal javítását a legfontosabb felhasználói útvonalakkal érdemes kezdeni: megtalálható-e az információ, el lehet-e indítani a fő műveletet, el lehet-e küldeni az űrlapot? Egy egyszerű kézi próba: Tab-billentyűvel járjuk végig az oldalt, nagyítsuk fel a böngészőt, kapcsoljuk ki a hangot egy videónál, és nézzük meg, marad-e érthető a felület. Az automatizált ellenőrzők gyorsak, de a találataikat emberi mérlegeléssel kell értelmezni (9.2).
Az akadálymentesség ne egyetlen ellenőrzési nap legyen a projekt végén. Egy új komponens tervezésekor a csapat rögtön dönthet a megfelelő HTML-elemről, a fókuszállapotról, a hibaüzenetekről és a kis képernyős viselkedésről; így kevesebb utólagos javításra van szükség.
Gyakori tévhitek
Röviden
altüres.Ellenőrző kérdések
#767676szövegszín fehér háttéren a normál szöveg AA-követelményének? Miért?alt=""?Tanulási források