A lecke végére érted, hogy az akadálymentesség nem különleges felhasználók utólagos kedvezménye, hanem a jó digitális szolgáltatás alapfeltétele. Ismered a WCAG négy alapelvét (POUR), és fel tudod ismerni az alapvető kockázatokat szín, kontraszt, billentyűzet, szöveg és visszajelzés területén.
Miért nem „extra” az akadálymentesség?
Sokan úgy gondolnak az akadálymentességre, mint egy külön funkcióra, amelyet a végén, ha marad idő, hozzá lehet tenni. Ez két okból hibás. Először: nagyon sok ember érintett. Egy tartós látássérült felhasználó mellett ott van, akinek egyik keze nincs szabadon (mert gyereket tart), akinek a képernyőjét elnyeli a napfény, akinek lassú a szeme a fáradtságtól, vagy aki másodnyelven olvas. Másodszor: az akadálymentesség utólagos hozzáadása sokkal drágább, mint az eleve helyes építés. Aki a kezdetektől akadálymentesen tervez, kevesebbet javít.
Kinek tervezünk?
Az akadálymentesség (accessibility) annak biztosítása, hogy eltérő képességekkel és segítő technológiákkal is használható legyen a tartalom. Az inkluzív tervezés ennél tágabb szemlélet: nem azt kérdezi, hogyan készítsünk külön verziót valakinek, hanem azt, hogy ki maradhat ki a jelenlegi döntésből.
Egy közismert szemléltetés (a Microsoft inkluzív tervezési anyagaiból): ugyanaz a korlát lehet tartós (egy kar hiánya), átmeneti (eltört kar) és helyzeti (kisgyerek a karban). Ha az egyik helyzetre jól tervezünk, a másik kettőnek is jó lesz.
A WCAG POUR szemlélete
A WCAG (Web Content Accessibility Guidelines, vagyis webtartalom-akadálymentességi irányelvek) a webtartalom akadálymentességére vonatkozó nemzetközi irányelv-rendszer, amelyet a W3C (World Wide Web Consortium) ad ki. A legtöbb jogi és szakmai elvárás hivatkozási alapja. Négy alapelve a POUR: Perceivable, Operable, Understandable, Robust, vagyis észlelhető, működtethető, érthető és robusztus.
Észlelhető (perceivable): az információ valamilyen módon felvehető.
A képhez értelmes alternatív szöveg (a képet nem látó felhasználónak és a képernyőolvasónak), a videóhoz felirat vagy leirat kell.
A csak színnel jelzett állapothoz további jelzés szükséges.
A szövegnek kontrasztosnak és nagyíthatónak kell maradnia.
Működtethető (operable): minden lényeges funkció kezelhető.
Nem feltételezhetünk egeret, érintést vagy gyors reakciót.
A fókusz legyen látható, a billentyűzetes sorrend logikus.
A mozgás vagy időkorlát ne akadályozza a feladatot; legyen elég nagy az érintési felület.
Érthető (understandable): a szöveg, a viselkedés és a hibaüzenet világos.
A „Hibás adat” nem elég; az „Az e-mail-címben hiányzik a @ jel” segít javítani.
A váratlan állapotváltozás és a következetlen elnevezés is érthetőségi probléma.
Robusztus (robust): a felület szabványos, különféle böngészőkben és segítő technológiákkal is értelmezhető szerkezetre épül. A szemantikus elemek (valódi gomb, valódi lista, valódi címsor) és a helyesen használt címkék ezért fontosak. Az ARIA (Accessible Rich Internet Applications) egy kiegészítő jelölőrendszer, amely a komplex elemek szerepét tudja közölni a segítő technológiával; első választás mégis a megfelelő natív elem.
Megfelelőségi szintek
A WCAG három szinten (A, AA, AAA) fogalmaz meg követelményeket. Az AA szint az, amelyet a legtöbb jogszabály és szolgáltatás célként kitűz; a tananyag is erre vonatkozik. Az A a legalapvetőbb, az AAA a legszigorúbb, de nem minden tartalomra teljesíthető. A jelenlegi, széles körben hivatkozott változat a WCAG 2.2.
Kontraszt, szín és jelzés
A kontrasztarány előtér és háttér fényességkülönbségének mérőszáma. Az AA szint főbb elvárásai:
Elem
Minimális kontrasztarány
Normál méretű szöveg
4,5 : 1
Nagy szöveg (kb. 24 px, vagy 19 px félkövér)
3 : 1
Felületi elemek határa, ikonok, fókuszjelzés
3 : 1
Ezek nem dekorációs szabályok. Rossz kijelzőn, napfényben vagy fáradt szemmel a gyenge kontraszt mindenki számára problémát okozhat. A kontrasztot eszközzel mérheted (a Figmához is vannak bővítmények, és böngészős ellenőrzők is), de a döntés a tied.
A szín legyen kiegészítő jelzés, ne az egyetlen. Hibás, ha egy űrlapmező csak piros keretet kap. Jobb, ha a kerethez szöveges hibaüzenet, ikon és programozott kapcsolat is tartozik. Grafikonon a színek mellett felirat, minta vagy közvetlen címke segíthet. A színtévesztők (kb. minden tizenkettedik férfi) számára a piros–zöld különbségtétel megbízhatatlan.
Billentyűzet és fókusz
A fókusz a billentyűzet által éppen vezérelt interaktív elem állapota. Egy gyors kézi ellenőrzéshez tedd félre az egeret, és a Tab billentyűvel járd végig a felületet. Kérdések:
Látszik-e mindig, hol jársz? (Látható fókuszjelzés.)
Logikus-e a sorrend, amelyben haladsz?
Elérhető-e a menü, az űrlap és a bezárás?
Nem ragadsz-e be egy elembe?
Felugró ablaknál a fókusznak az ablakba kell kerülnie, a háttér elemei nem maradhatnak véletlenül bejárhatók, bezáráskor pedig ésszerű helyre kell visszatérnie. A fókusz jelzését más elem ne takarja el.
Érintési felület és szöveg
Mobilon az ujjal kezelhető elemek méretére külön szabály vonatkozik: a WCAG 2.2 AA szint legalább 24 × 24 CSS pixel méretet vár az érintési célfelületektől, de a kényelmes méret általában ennél nagyobb (a platformok irányelvei jellemzően 44–48 pontot javasolnak). Szöveg esetén fontos, hogy 200%-os nagyításnál se vesszen el tartalom és funkció; ez a reszponzív tervezésnek is feltétele.
Végigvezetett példa: a Mai program eseményoldala
Egy előadás oldalán az időpont csak naptárikonként, a helyszín csak térképen, a jelentkezés pedig „Kattints ide!” feliratú dobozként szerepel. A hozzáférhetőségi problémák:
az időpont ikon, szöveg nélkül (észlelhetőség);
a térkép képernyőolvasóval nem használható (észlelhetőség);
a „Kattints ide!” doboz valójában nem gomb (robusztusság, működtethetőség);
a felirat kontrasztja alacsony (észlelhetőség).
Inkluzívabb változatban a dátum és a cím szövegben is ott van; a jelentkezés valódi, egyértelmű feliratú gomb („Jelentkezés az eseményre”); a térképhez szöveges útvonalinformáció tartozik. Nem külön oldalt készítettünk egy csoportnak: ugyanazt a feladatot tettük érthetőbbé mindenki számára.
Gyakori tévhitek
Állítás
Pontosítás
„Az automatikus ellenőrző mindent megtalál.”
Eszköz jelezhet hiányzó címkét vagy kontrasztot, de nem tudja megítélni, hogy az alternatív szöveg vagy a feladatfolyam értelmes-e.
„Az ARIA megoldja a szemantikát.”
Az ARIA kiegészítő eszköz; első választás a megfelelő natív elem.
„Az akadálymentesség korlátozza a kreativitást.”
Inkább olyan keretet ad, amelyben a látvány egyben érthető és kezelhető marad.
„Az akadálymentesség a látássérültekről szól.”
Mozgáskorlátozott, hallássérült, kognitív különbségekkel élő és helyzeti korlátozott felhasználókat is érint.
Röviden
Az akadály lehet tartós, átmeneti vagy helyzeti; az inkluzív tervezés azt kérdezi, ki marad ki.
A WCAG négy alapelve: észlelhető, működtethető, érthető, robusztus (POUR); a cél az AA szint.
Szöveg kontrasztja legalább 4,5 : 1, nagy szövegé és a felületi elemeké 3 : 1.
A szín sosem lehet az egyetlen jelzés; a billentyűzetes és fókuszos használatot mindig ellenőrizd.
A kézi ellenőrzés (Tab, nagyítás) nélkülözhetetlen, az automatikus eszköz csak segít.
Ellenőrző kérdések
Mit jelent a POUR négy betűje?
Miért nem elég csak színnel jelölni egy hibát?
Mit figyelnél Tab-billentyűvel történő bejáráskor?
Melyik információ a projektedben jelenik meg kizárólag vizuálisan?
Milyen helyzeti korlátozást tudsz elképzelni a Mai program használatakor?
Inkluzív tervezés és WCAG
Célok
A lecke végére érted, hogy az akadálymentesség nem különleges felhasználók utólagos kedvezménye, hanem a jó digitális szolgáltatás alapfeltétele. Ismered a WCAG négy alapelvét (POUR), és fel tudod ismerni az alapvető kockázatokat szín, kontraszt, billentyűzet, szöveg és visszajelzés területén.
Miért nem „extra” az akadálymentesség?
Sokan úgy gondolnak az akadálymentességre, mint egy külön funkcióra, amelyet a végén, ha marad idő, hozzá lehet tenni. Ez két okból hibás. Először: nagyon sok ember érintett. Egy tartós látássérült felhasználó mellett ott van, akinek egyik keze nincs szabadon (mert gyereket tart), akinek a képernyőjét elnyeli a napfény, akinek lassú a szeme a fáradtságtól, vagy aki másodnyelven olvas. Másodszor: az akadálymentesség utólagos hozzáadása sokkal drágább, mint az eleve helyes építés. Aki a kezdetektől akadálymentesen tervez, kevesebbet javít.
Kinek tervezünk?
Az akadálymentesség (accessibility) annak biztosítása, hogy eltérő képességekkel és segítő technológiákkal is használható legyen a tartalom. Az inkluzív tervezés ennél tágabb szemlélet: nem azt kérdezi, hogyan készítsünk külön verziót valakinek, hanem azt, hogy ki maradhat ki a jelenlegi döntésből.
Egy közismert szemléltetés (a Microsoft inkluzív tervezési anyagaiból): ugyanaz a korlát lehet tartós (egy kar hiánya), átmeneti (eltört kar) és helyzeti (kisgyerek a karban). Ha az egyik helyzetre jól tervezünk, a másik kettőnek is jó lesz.
A WCAG POUR szemlélete
A WCAG (Web Content Accessibility Guidelines, vagyis webtartalom-akadálymentességi irányelvek) a webtartalom akadálymentességére vonatkozó nemzetközi irányelv-rendszer, amelyet a W3C (World Wide Web Consortium) ad ki. A legtöbb jogi és szakmai elvárás hivatkozási alapja. Négy alapelve a POUR: Perceivable, Operable, Understandable, Robust, vagyis észlelhető, működtethető, érthető és robusztus.
Észlelhető (perceivable): az információ valamilyen módon felvehető.
Működtethető (operable): minden lényeges funkció kezelhető.
Érthető (understandable): a szöveg, a viselkedés és a hibaüzenet világos.
Robusztus (robust): a felület szabványos, különféle böngészőkben és segítő technológiákkal is értelmezhető szerkezetre épül. A szemantikus elemek (valódi gomb, valódi lista, valódi címsor) és a helyesen használt címkék ezért fontosak. Az ARIA (Accessible Rich Internet Applications) egy kiegészítő jelölőrendszer, amely a komplex elemek szerepét tudja közölni a segítő technológiával; első választás mégis a megfelelő natív elem.
Megfelelőségi szintek
A WCAG három szinten (A, AA, AAA) fogalmaz meg követelményeket. Az AA szint az, amelyet a legtöbb jogszabály és szolgáltatás célként kitűz; a tananyag is erre vonatkozik. Az A a legalapvetőbb, az AAA a legszigorúbb, de nem minden tartalomra teljesíthető. A jelenlegi, széles körben hivatkozott változat a WCAG 2.2.
Kontraszt, szín és jelzés
A kontrasztarány előtér és háttér fényességkülönbségének mérőszáma. Az AA szint főbb elvárásai:
Ezek nem dekorációs szabályok. Rossz kijelzőn, napfényben vagy fáradt szemmel a gyenge kontraszt mindenki számára problémát okozhat. A kontrasztot eszközzel mérheted (a Figmához is vannak bővítmények, és böngészős ellenőrzők is), de a döntés a tied.
A szín legyen kiegészítő jelzés, ne az egyetlen. Hibás, ha egy űrlapmező csak piros keretet kap. Jobb, ha a kerethez szöveges hibaüzenet, ikon és programozott kapcsolat is tartozik. Grafikonon a színek mellett felirat, minta vagy közvetlen címke segíthet. A színtévesztők (kb. minden tizenkettedik férfi) számára a piros–zöld különbségtétel megbízhatatlan.
Billentyűzet és fókusz
A fókusz a billentyűzet által éppen vezérelt interaktív elem állapota. Egy gyors kézi ellenőrzéshez tedd félre az egeret, és a Tab billentyűvel járd végig a felületet. Kérdések:
Felugró ablaknál a fókusznak az ablakba kell kerülnie, a háttér elemei nem maradhatnak véletlenül bejárhatók, bezáráskor pedig ésszerű helyre kell visszatérnie. A fókusz jelzését más elem ne takarja el.
Érintési felület és szöveg
Mobilon az ujjal kezelhető elemek méretére külön szabály vonatkozik: a WCAG 2.2 AA szint legalább 24 × 24 CSS pixel méretet vár az érintési célfelületektől, de a kényelmes méret általában ennél nagyobb (a platformok irányelvei jellemzően 44–48 pontot javasolnak). Szöveg esetén fontos, hogy 200%-os nagyításnál se vesszen el tartalom és funkció; ez a reszponzív tervezésnek is feltétele.
Végigvezetett példa: a Mai program eseményoldala
Egy előadás oldalán az időpont csak naptárikonként, a helyszín csak térképen, a jelentkezés pedig „Kattints ide!” feliratú dobozként szerepel. A hozzáférhetőségi problémák:
Inkluzívabb változatban a dátum és a cím szövegben is ott van; a jelentkezés valódi, egyértelmű feliratú gomb („Jelentkezés az eseményre”); a térképhez szöveges útvonalinformáció tartozik. Nem külön oldalt készítettünk egy csoportnak: ugyanazt a feladatot tettük érthetőbbé mindenki számára.
Gyakori tévhitek
Röviden
Ellenőrző kérdések