Az akadálymentes weboldal szemantikus kódot használ, billentyűzettel kezelhető, látható fókusszal, megfelelő kontraszttal, érthető űrlapokkal és szöveges alternatívákkal rendelkezik, és megfelel a manuális tesztnek. Az automatikus ellenőrzést kiegészíti a kritikus feladatok, a nagyítás és a segítő technológiák tesztelése, valamint egy elérhető csatorna az akadályok bejelentésére.
A webes akadálymentesség azt jelenti, hogy a tartalmat és a funkciókat különböző látási, hallási, mozgási vagy kognitív igényű emberek is használni tudják. Segít annak is, akinek sérült a keze, aki napfényben, kis kijelzőn vagy lassú kapcsolaton böngészik. Nem a projekt végén hozzáadott kiegészítő, hanem a tervezés, a kód és a tartalom tulajdonsága.
Az automatikus szkenner a problémák egy részét megtalálja, de nem ellenőrzi, hogy a fókuszsorrend logikus-e, az alternatív szöveg hasznos-e, vagy a hibaüzenet érthető-e. Ezért az eszközzel végzett ellenőrzést kézi teszteléssel és lehetőség szerint a segítő technológiákat használó emberek visszajelzésével kombinálják. A jogi kötelezettségek eltérőek; a konkrét megfelelést szakértőnek kell megítélnie.
Szemantikus struktúra és érthető tartalom
Használja a megfelelő elemeket a címsorokhoz, bekezdésekhez, listákhoz, gombokhoz, hivatkozásokhoz és az oldal régióihoz. A szemantika segít a képernyőolvasónak és a keresőmotornak is megérteni az összefüggéseket. A címsoroknak logikus vázlatot kell alkotniuk, szintek kihagyása nélkül pusztán a megjelenés kedvéért. A gomb műveletet hajt végre, a hivatkozás navigál; a vizuálisan utánzott elem gyakran nem viselkedik helyesen.
A szöveget írja tömören, konkrétan, és magyarázza el a szokatlan fogalmakat. Egy „további információ” típusú hivatkozás kontextusból kiemelve homályos; a szolgáltatás vagy a cél megnevezése hasznosabb. A hosszú tartalmat tagolja alcímekkel és listákkal. Az utasítások nem alapulhatnak kizárólag színen, elhelyezkedésen vagy formán, mint például „kattintson a jobb oldali zöld gombra”.
Billentyűzet, fókusz és interaktív elemek
Járja be a teljes weboldalt a Tab és a Shift+Tab billentyűkkel. A fókusznak láthatónak, a sorrendnek logikusnak kell lennie, és minden vezérlőelemnek egér nélkül is elérhetőnek kell lennie. A felhasználó nem ragadhat be a menübe, a modális ablakba vagy a beágyazott tartalomba. A fő tartalomra ugró hivatkozás felgyorsítja a navigációt az ismétlődő menüvel rendelkező oldalakon.
Az egyedi lenyíló elemeknek, füleknek és párbeszédablakoknak megfelelő billentyűzetes kezelésre és állapotjelzésre van szükségük. Előnyben részesítendők a natív HTML-elemek, amelyek már sok elvárt viselkedést magukban hordoznak. A párbeszédablak bezárása után adja vissza a fókuszt annak az elemnek, amely megnyitotta. Az automatikus fókuszáthelyezést csak egyértelmű indokkal alkalmazza.
- minden művelet egér nélkül is elérhető
- kontrasztos és folyamatosan látható fókusz
- logikus sorrend a tartalom alapján
- nincs billentyűzetcsapda a komponensben
Űrlapok, hibák és a bevitel ellenőrzése
Minden mezőnek tartós szöveges címkére van szüksége, amely programozottan kapcsolódik a vezérlőelemhez. A placeholder nem helyettesíti, mert gépeléskor eltűnik. A kötelező kitöltést és az elvárt formátumot előre jelezze. A választási csoportokat nevezze el, és az űrlapot elküldő gomb konkrét feliratot kapjon, például „Ajánlatkérés elküldése”.
Hiba esetén jelenítsen meg összesítést és a konkrét mező melletti üzenetet is, és pontosan magyarázza el a javítás módját. Őrizze meg a helyesen megadott adatokat. A képernyőolvasónak értesülnie kell az új állapotról, és a fókuszt megfelelően kell áthelyezni. Jelentős műveletnél tegye lehetővé az ellenőrzést vagy a javítást a végső megerősítés előtt.
Vizuális tartalom, kontraszt és média
A szövegnek és a vezérlőelemeknek minden állapotban megfelelő kontrasztra van szükségük. Az információt ne csak színnel közvetítse; a hibás mezőt egészítse ki ikonnal vagy szöveggel. A weboldalnak nagyítás és keskeny megjelenítés mellett is használhatónak kell maradnia, a folyó szöveg vízszintes görgetése nélkül. Tartsa tiszteletben a mozgáscsökkentési beállítást, és kerülje a villogást.
Az alternatív szöveg a kép célját írja le az adott kontextusban. A dekoratív képet a kisegítő technológia figyelmen kívül hagyhatja, egy grafikon viszont az adatok szöveges magyarázatát igényli. A videót lássa el felirattal, és a tartalomtól függően átirattal vagy hangalámondásos leírással. A hang automatikus lejátszása jelentősen zavarhatja a felhasználót, ezért az ő irányítása alatt kell lennie.
Tesztelés és akadálymentesség mint folyamat
Kezdje automatikus ellenőrzéssel, majd teszteljen billentyűzettel, különböző nagyítási szinteken, nagy kontraszttal, és legalább alapszinten képernyőolvasóval. Ellenőrizze a reprezentatív sablonokat és a kritikus folyamatokat, ne csak a kezdőlapot. A megállapításokat a hely, a hatás, a reprodukálás módja és a javasolt javítás megadásával rögzítse.
Építse be az akadálymentességi kritériumokat a tervezésbe, a komponenskönyvtárba, az átvételbe és a tartalmi képzésbe. Javítás után végezzen regressziós tesztet. Az akadálymentességi nyilatkozat feleljen meg a valós állapotnak, és tüntesse fel, hogyan lehet akadályt bejelenteni. A formális kötelezettségeket és a megfelelési szintet a szervezet és a hatályos szabályok alapján, képzett szakemberrel ellenőriztesse.
Akadálymentesség a beszerzésben és a beszállítók munkájában
Az akadálymentességi követelményt a megrendelésben a terjedelemmel, az ellenőrzés módjával és az elvárt kimenetekkel együtt adja meg. Az az általános mondat, hogy „a weboldal akadálymentes lesz”, nem határozza meg, mely sablonokat, dokumentumokat és külső komponenseket tesztelnek. Kérjen bemutatót a billentyűzetes kezelésről, az űrlapokról és a komponensekről, ne csupán szkenner-pontszámot vagy gyártói nyilatkozatot. Állapodjon meg a feltárt hibák javításáról és a teszteredmények átadásáról. Chat, foglalási rendszer vagy beágyazott widget beszerzésekor ellenőrizze annak akadálymentességét is, mert egy kulcsfontosságú külső szolgáltatás akadálya a teljes felhasználói utat rontja.
Ossza fel a felelősséget a tervezés, a fejlesztés, a tartalom és az üzemeltetés között. A tervező határozza meg a kontrasztot és az állapotokat, a fejlesztő a szemantikát és a kezelhetőséget, a szerkesztő a címsorokat és az alternatív szövegeket, a termékfelelős pedig az átvételt. A képzés az Önök valós komponenseit és publikációs rendszerét használja. Hozzon létre akadálymentes csatornát a problémák bejelentésére, és reagáljon anélkül, hogy a felhasználótól egészségi állapotának igazolását kérné. Jelentős akadály esetén kínáljon gyakorlati alternatívát, és ütemezze be a javítást. A szerződéses és jogi követelmények eltérőek lehetnek, ezért terjedelmüket és a hivatalos nyilatkozatokat képzett szakember értékelje. A javítás során a prioritást a súlyosság és a gyakoriság alapján határozza meg, de a szolgáltatás igénybevételét kritikusan ellehetetlenítő problémát ne egy nagy újratervezésig halogassa. A javított komponenst vegye fel a közös könyvtárba, hogy ugyanaz az akadály ne térjen vissza más oldalakon.
- mérhető kritériumok közvetlenül a megbízásban
- külső kritikus komponensek tesztelése
- szerepkörök között megosztott felelősség
- elérhető csatorna az akadályok bejelentésére
Gyakori kérdések
Elegendő az akadálymentességhez egy automatikus teszt?
Nem. Csak a technikai problémák egy részét észleli. A logikát, a billentyűzettel való használhatóságot, az alternatívák minőségét és az érthetőséget manuálisan kell ellenőrizni. Ráadásul az automatikus találatot a komponens kontextusában értelmezni kell. Kombinálja a szkennert, a billentyűzetes tesztet, a nagyítást, a képernyőolvasót és a kritikus feladatok tesztelését. Fontos szolgáltatásnál értékes azoknak az embereknek a visszajelzése is, akik rendszeresen használnak segítő technológiákat.
Rontja az akadálymentesség a vizuális dizájnt?
Nem. A jó korlátok olvashatóbb, következetesebb és kiszámíthatóbb dizájnhoz vezetnek. A kreativitás megmaradhat akadályok létrehozása nélkül.
Mikor foglalkozzunk az akadálymentességgel?
A kutatástól és a tervezéstől kezdve, a fejlesztés alatt és a tartalomkészítéskor is. A késői audit hasznos, de a javítások általában nehezebbek, mint a folyamatos tesztelés esetén.