Jobb felhasználói élmény adaptív webes eszközökhöz

Az interakció eszközei

Azok számára, akik adaptív webes eszközökre támaszkodnak az interneten való navigáláshoz, a tartalom felépítésének és bemutatásának módja mindennél fontosabb. A világ legkifinomultabb segítő technológiája sem tud olyan tartalmat felolvasni, bejelenteni vagy működtetni, amely nem létezik akadálymentes formában. Egy gomb, amely valójában egy stílusozott <div>, egy szöveges alternatíva nélküli kép vagy egy billentyűzet-támogatás nélküli egyedi legördülő menü egyszerűen láthatatlan — vagy ami még rosszabb, zsákutca — azoknak az embereknek, akik nap mint nap ezekre az eszközökre támaszkodnak.

A QualiBooth segít két dolgot egyszerre megérteni: hogy a felhasználó eszközei valójában hogyan értelmezik a tartalmát, és hogy milyen tartalom vagy szerkezet hiányzik, sérült vagy kétértelmű. Éppen ez a kombináció különbözteti meg azt a weboldalt, amely technikailag betöltődik, attól, amely valóban mindenki számára működik.

Ez az útmutató végigveszi a segítő és adaptív technológia fő kategóriáit, hogy mindegyik hogyan várja el a weboldal viselkedését, valamint azokat a gyakorlati lépéseket, amelyekkel ezekkel az eszközökkel együtt építhet, nem pedig ellenük. Egyértelmű határvonalat is húz a valódi segítő technológia és az akadálymentességi overlay-ek között — mivel a kettőt gyakran összekeverik, és ennek az összetévesztésnek valós következményei vannak valós felhasználók számára.

Mit jelentenek valójában az “adaptív webes eszközök”

Az adaptív webes eszközök — gyakrabban segítő technológiának (AT) nevezve — olyan szoftverek és hardverek, amelyek megváltoztatják, ahogyan egy ember egy digitális felületet érzékel vagy működtet. Ezek nem a weboldalához hozzáadott kiegészítők; ezek a felhasználó saját környezete, az ő igényeihez konfigurálva, és gyakran napi órákon át használva több ezer oldalon.

A főbb kategóriák a következők:

Képernyőolvasók, amelyek a képernyőn lévő tartalmat szintetizált beszéddé vagy frissíthető Braille-írássá alakítják.
Képernyőnagyítás, amely a kijelző egy részét vagy egészét nagyítja és újrarendezi.
Kapcsolós hozzáférés azok számára, akik nem tudnak szabványos billentyűzetet vagy egeret használni.
Hangvezérlés, amely a felületet teljes egészében kimondott parancsokkal irányítja.
Beépített böngésző- és operációsrendszer-funkciók, mint a nagy kontrasztú módok, a csökkentett mozgás és az olvasási eszközök.
Olvasási és megértési segédeszközök, amelyek egyszerűsítik, felolvassák vagy átstrukturálják a szöveget.

Ezek mindegyike ugyanarra az alapra támaszkodik: egy jól strukturált, szemantikus, billentyűzettel működtethető oldalra, amely betartja a bevett szabványokat. Amikor a WCAG 2.2 szerint épít, azt a szerződést építi meg, amelyre ezeknek az eszközöknek mindegyike támaszkodik.

Képernyőolvasók: a szerkezet a felület

A képernyőolvasók a legismertebb segítő technológia, és sok csapat számára a legnehezebb, amire tervezni kell — éppen azért, mert a látott vizuális elrendezés szinte semmit nem árul el arról, amit egy képernyőolvasó bejelent.

A legszélesebb körben használt képernyőolvasók az NVDA és a JAWS Windowson, a VoiceOver macOS-en és iOS-en, valamint a TalkBack Androidon. Nem “látják” az oldalát; egy modellt építenek az akadálymentességi fából, amely a HTML-szemantikájából és az esetlegesen rátett ARIA-ból származik.

Mire van szükségük a képernyőolvasóknak Öntől

Valódi szemantikus elemekre. Használja a <button>, <a>, <nav>, <main>, <h1>–<h6> és <table> elemeket arra, amik. Egy címsornak címsornak kell lennie, hogy a felhasználók szakaszok között ugorhassanak; egy linknek linknek kell lennie, hogy megjelenjen a linkek listájában.
Értelmes szöveges alternatívákra. Minden informatív képnek szüksége van egy alt attribútumra, amely leírja a célját. A dekoratív képeknek üres alt="" értékkel kell rendelkezniük, hogy átugorják őket, ahelyett, hogy zajként bejelentenék.
Programozott címkékre a vezérlőkhöz. Az űrlapmezőknek társított <label> elemekre van szükségük; a csak ikont tartalmazó gomboknak akadálymentes névre van szükségük aria-label vagy vizuálisan elrejtett szöveg révén.
Logikus címsorhierarchiára. A címsorok az elsődleges módja annak, ahogyan a képernyőolvasó-felhasználók átfutják az oldalt. A szintek átugrása vagy a címsorok pusztán vizuális méret miatti használata megtöri ezt a navigációt.
Helyes ARIA-ra — és csak amikor szükséges. Az ARIA képes állapotokat (kibontva, kiválasztva, letiltva) és szerepeket közvetíteni az egyedi widgetekhez, de a rossz ARIA rosszabb, mint a semmi. Az ARIA első szabálya, hogy ahol lehet, natív HTML-t használjon helyette.

A zavar gyakori forrása a képernyőolvasó és a hagyományos szövegfelolvasás közötti különbség. Egy olvasási eszköz felolvassa a szöveget; egy képernyőolvasó feltárja és működteti a teljes felületet, beleértve a vezérlőket, állapotokat és a navigációt. Ezt a megkülönböztetést részletesen tárgyaljuk a szövegfelolvasás kontra képernyőolvasók cikkben.

Mivel az automatizált eszközök a képernyőolvasó-problémáknak csak töredékét képesek felismerni, az egyetlen megbízható módja annak, hogy megtudja, hogyan szól az oldala, ha úgy teszteli, ahogyan a felhasználók teszik. Képernyőolvasó-tesztelési útmutatónk végigvezeti a gyakorlati munkafolyamatot, egy dedikált képernyőolvasó-értékelés pedig a legfontosabb felhasználói útvonalakat futtatja végig ezen a folyamaton tapasztalt tesztelőkkel.

Képernyőnagyítás: tervezzen a felnagyított nézetre

A gyengénlátók gyakran 200%-tól 800%-ig vagy még tovább nagyítják a képernyőt, egyszerre csak az oldal egy kis szeletét látva. Egyesek az operációs rendszer nagyítóját használják; mások a böngésző nagyítására vagy speciális szoftverre támaszkodnak.

Nagy nagyítás esetén az elrendezéssel kapcsolatos döntések, amelyekre soha nem gondol, kritikussá válnak:

Újrarendezés (reflow). A tartalomnak egyetlen oszlopba kell újrarendeződnie 400%-os nagyításnál (WCAG 2.2 1.4.10 sikerkritérium), hogy a felhasználóknak ne kelljen két irányba görgetniük egy mondat elolvasásához.
A kapcsolódó elemek közelsége. Ha egy hibaüzenet messze jelenik meg az általa leírt mezőtől, egy nagyító felhasználó talán soha nem látja őket ugyanabban a nézetablakban. Tartsa a címkéket, beviteli mezőket és visszajelzéseket együtt.
Látható fókusz. Egy egyértelmű, nagy kontrasztú fókuszjelző lehetővé teszi a nagyító felhasználó számára, hogy megtalálja, hol van, miután a nézet ugrik.
Nincs tartalom- vagy funkcióvesztés. Semmit sem szabad levágni, átfedni vagy működésképtelenné tenni, amikor a szöveget akár 200%-ig nagyítják (1.4.4 sikerkritérium).

A nagyítás jutalmazza a tiszta, reszponzív elrendezéseket, és bünteti a rögzített pixeles terveket és a rámutatástól (hover) függő tartalmat.

Kapcsolós hozzáférés és billentyűzetes működtethetőség

A kapcsolós eszközök lehetővé teszik az emberek számára, hogy egy vagy két egyszerű bevitellel — egy gombbal, egy szívó-fúvó eszközzel vagy egy fejmozdulattal — működtessenek egy számítógépet, általában az interaktív elemek egyenkénti átpásztázásával. A kapcsolós hozzáférés a billentyűzet-támogatásra épül: ha az oldala teljesen működik billentyűzetről, akkor szinte biztosan működik kapcsolókkal is.

Ettől a teljes billentyűzetes működtethetőség lesz az egyik legnagyobb hatású dolog, amit jól csinálhat:

Minden elérhető. Minden interaktív elemnek fókuszálhatónak és működtethetőnek kell lennie egér nélkül — linkek, gombok, űrlapvezérlők, menük, modális ablakok, körhinták és egyedi widgetek egyaránt.
Látható, logikus fókuszsorrend. A fókusznak olyan sorrendben kell mozognia az oldalon, amely megfelel a vizuális és olvasási folyamnak, és a fókuszált elemet mindig egyértelműen jelezni kell.
Nincsenek billentyűzetcsapdák. A felhasználóknak képesnek kell lenniük a fókuszt kimozdítani bármely komponensből, beleértve a beágyazott médiát és a párbeszédablakokat.
Átugró linkek. Egy “ugrás a fő tartalomra” link lehetővé teszi az emberek számára, hogy megkerüljék az ismétlődő navigációt, ahelyett, hogy minden oldalon átfutnák azt.

Ha egy ügyfél kitölt egy űrlapot, végig tudja-e tabulálni minden mezőn, ki tud-e nyitni egy legördülő menüt, ki tud-e választani egy terméket és el tudja-e küldeni — mindezt anélkül, hogy hozzáérne az egérhez? Együttműködik-e a böngésző automatikus kitöltése a jelölésével? Ezek azok a kérdések, amelyekre a kapcsolós és billentyűzet-felhasználók megválaszolják az oldaláról, akár felteszi őket, akár nem.

Hangvezérlés: a nevek és a látható címkék számítanak

A hangvezérlő eszközök, mint a Dragon, a Voice Control és a Voice Access, lehetővé teszik a felhasználók számára, hogy olyan parancsokat mondjanak, mint “kattints a Küldés-re” vagy “görgess le”. Ahhoz, hogy ezek a parancsok működjenek, egy vezérlő látható címkéjének meg kell egyeznie az akadálymentes nevével. Ez a WCAG 2.2 2.5.3 sikerkritérium, a Label in Name alapja.

Gyakorlati útmutatás:

Az akadálymentes névnek tartalmaznia kell a látható szöveget. Ha egy gombon az áll, hogy “Üzenet küldése”, ne adjon neki “Űrlap beküldése” aria-label-t — a felhasználót, aki azt mondja, hogy “kattints az Üzenet küldése-re”, figyelmen kívül hagyják.
Kerülje a csak ikont tartalmazó, szöveg nélküli vezérlőket, vagy adjon nekik olyan akadálymentes nevet, amely megfelel egy valószínű kimondott parancsnak.
Tartsa a kattintható célpontokat elég nagynak a megbízható kiválasztáshoz, ami a WCAG 2.2 célpontméret-kritériumát is teljesíti.

Böngésző és operációs rendszer akadálymentességi funkciói

Nem minden adaptív eszköz külön termék. A modern böngészők és operációs rendszerek erőteljes beépített funkciókkal érkeznek, amelyeket a felhasználók rendszerszinten kapcsolnak be, és az oldalának automatikusan tiszteletben kell tartania ezeket:

Csökkentett mozgás. Tartsa tiszteletben a prefers-reduced-motion médialekérdezést, hogy letiltsa vagy enyhítse az animációkat azon felhasználók számára, akik hányingert vagy elterelődést tapasztalnak a mozgástól.
Sötét mód és nagy kontraszt. Támogassa a prefers-color-scheme-et és a Windows nagy kontraszt / Forced Colors módot, hogy a felülete olvasható maradjon anélkül, hogy a felhasználó beállításai ellen küzdene.
Szöveg-átméretezés és nagyítás. Használjon relatív egységeket, hogy a böngésző szövegskálázása működjön, ahelyett, hogy pixelekben rögzítené a méreteket.
Olvasási módok és olvasási eszközök. A böngésző olvasónézetei és az olyan eszközök, mint az Immersive Reader, az oldalt a lényegi tartalmára csupaszítják — ami sokkal jobban működik, ha a HTML-je szemantikus és mentes a rendezetlenségtől.

Ezek a funkciók nem kerülnek semmi többletbe a felhasználónak, és nagyon keveset Önnek, mégis drámaian javítják a kényelmet egy széles közönség számára, beleértve a diagnosztizált fogyatékosság nélküli embereket is.

Olvasási és megértési eszközök

Az olvasási eszközök a diszlexiával, ADHD-val, kognitív fogyatékossággal vagy az oldal nyelvén korlátozott írni-olvasni tudással rendelkező embereket szolgálják. Ide tartoznak a szövegfelolvasó programok, az olvasóvonalzók, a szókiemelés, az összefoglalók és a fordítóeszközök.

Hogy jól működjenek velük:

Írjon egyszerű, jól szervezett nyelven, leíró címsorokkal és rövid bekezdésekkel.
Jelölje meg az oldalt úgy, hogy a fő tartalom egyértelműen azonosítható legyen, és az olvasási sorrend helyes legyen.
Kerülje a jelentés pusztán színnel, elrendezéssel vagy képekkel való közvetítését — biztosítson szöveges megfelelőt.
Gondoskodjon arról, hogy a nyelve deklarálva legyen (lang attribútum), hogy a felolvasás és a fordítás a helyes kiejtést és szabályokat használja.

A jó tartalomszerkezet egyszerre segíti a cikk minden eszközét, mert mindegyik ugyanabból az alapul szolgáló jelölésből merít.

Valódi segítő technológia kontra akadálymentességi overlay-ek

Ez a legfontosabb megkülönböztetés, és itt téved sok szervezet.

A valódi segítő technológia — képernyőolvasók, nagyítók, kapcsolós hozzáférés, hangvezérlés — a felhasználó eszközén fut, a felhasználó irányítása alatt, és az Ön weboldalát működteti annak szemantikája és billentyűzet-támogatása révén. A felhasználó éveket töltött a konfigurálásával. Az Ön feladata egyszerűen az, hogy olyan oldalt építsen, amelyet ezek az eszközök megérthetnek.

Az akadálymentességi overlay-ek harmadik féltől származó szkriptek, amelyeket a saját oldalához ad hozzá, és amelyek azt ígérik, hogy automatikusan “akadálymentessé teszik”, általában egy lebegő widget révén. Nem helyettesítik a segítő technológiát, és nem javítják ki az akadálymentesség hiányát egy oldalon. Íme, miért:

Nem tudják kijavítani az alapul szolgáló kódot. Az overlay-ek az oldal tetején ülnek; nem tudnak megbízhatóan hiányzó alt szöveget kitalálni, sérült címsorszerkezeteket javítani, vagy egy <div>-et úgy viselkedtetni, mint egy valódi gombot minden képernyőolvasóban.
Gyakran ütköznek a valódi AT-vel. Sok képernyőolvasó-felhasználó jelzi, hogy az overlay-ek zavarják azokat az eszközöket, amelyekre már támaszkodnak, néha nehezebbé téve az oldalak használatát, nem könnyebbé.
A megfelelőség hamis érzetét keltik. Egy widget telepítése nem elégíti ki a WCAG 2.2, az EAA vagy az ADA követelményeit. Overlay-eket használó oldalak ellen éppen azért indítottak pereket, mert az alapul szolgáló akadályok megmaradtak.
Nem tükrözik a megélt tapasztalatot. Az akadálymentességet végső soron azok az emberek ítélik meg, akik nap mint nap AT-t használnak — ezért végzünk fogyatékossággal élő emberek által végzett auditokat, ahelyett, hogy egy szkript állításaira hagyatkoznánk.

A megbízható út az, hogy az akadálymentességet a kódban javítja ki, és mind automatizált, mind emberi teszteléssel validálja. Ezt a filozófiát részletesebben kifejtjük a mit jelent a valódi digitális akadálymentesség cikkben.

Gyakorlati munkafolyamat az adaptív eszközökkel való építéshez

A segítő technológiára való építés nem egyszeri projekt; ez egy folyamat, amely beleillik abba, ahogyan már szoftvert szállít. Egy fenntartható megközelítés általában négy dolgot kombinál:

Automatizált szkennelés, korán és gyakran. Az olyan eszközök, mint az akadálymentességi szkennelő szoftver, nagy mennyiségű kódszintű problémát fognak el — hiányzó címkéket, kontraszthibákat, sérült ARIA-t — még mielőtt elérnék az éles környezetet. Az automatizált ellenőrzések gyorsak és megismételhetők, de a teljes képnek csak egy részét fedik le.
Manuális és segítő technológiás tesztelés. Azok a problémák, amelyek a valós felhasználókat leginkább érintik — zavaró fókuszsorrend, nem világos bejelentések, használhatatlan egyedi widgetek — embert igényelnek. Manuális akadálymentességi auditok útmutatónk leírja, hogyan egészíti ez ki az automatizálást.
Az akadálymentesség beágyazása a csapatába. Az akadálymentesség folyamatos diszciplínaként való kezelése, amelyet az akadálymentességi folyamat fejlesztése támogat, megakadályozza a lassú visszacsúszást, amely akkor következik be, amikor a javítások egyszeriek.
A megfelelő eszközök a stackjéhez. A QualiBooth akadálymentességi eszközkészlete összehozza a szkennelést, a monitorozást és a jelentéskészítést, míg az Agora és a community kiadásunk belépési pontokat kínál a különböző érettségi szakaszban lévő csapatok számára.

Ha a cikkben szereplő terminológia új az Ön számára, az akadálymentességi szószedet hasznos társ, miközben ezeket a gyakorlatokat bevezeti.

Hol illeszkedik a QualiBooth

A QualiBooth azonosítja a problémákat a meglévő weboldalán, és az oldalakat azok élesítése előtt is be tudja szkennelni, így a bármilyen adaptív eszközt használó ügyfelek zökkenőmentes élményt kapnak, amely növeli a használhatóságot és a márkahűséget. Az automatizált felismerést tapasztalt tesztelők és fogyatékossággal élő emberek általi értékeléssel kombináljuk, majd segítünk a csapatának a megállapításokat tartós javításokká alakítani — soha nem olyan overlay-jé, amely elfedi a problémát.

A cél egyszerű: egy weboldal, amely együttműködik azokkal az eszközökkel, amelyekben a felhasználói már megbíznak, az ő feltételeik szerint, minden alkalommal, amikor ellátogatnak.

Készen áll arra, hogy lássa, hogyan teljesít az oldala a valódi segítő technológiával? Futtasson egy ingyenes akadálymentességi szkennelést, hogy gyors győzelmeket találjon, kérjen egy demót, hogy lássa a QualiBooth-ot működés közben, vagy beszéljen csapatunkkal egy testreszabott akadálymentességi tanácsadás megbízásról.