Egy elérhető, reszponzív webhely nem ugyanaz, mint egy akadálymentesített alkalmazás – annak ellenére, hogy mindkettő "telefonon működik". Ez a cikk bemutatja a lényeges különbségeket a webhely elérhetővé tétele és a natív iOS- vagy Android-alkalmazások elérhetővé tétele között.
Röviden: miről szól ez a cikk
Eltérő technológia, hasonló szabályok
HTML-ből épül fel egy reszponzív webhely, amely már rendelkezik egy beépített akadálymentesítési réteggel (szemantikus címkék, ARIA), amelyet a böngészők és a képernyőolvasók tudják értelmezni. Ezzel szemben egy natív alkalmazás az operációs rendszer saját felhasználói felület-összetevőiből épül fel (UIKit/SwiftUI iOS-en, Jetpack Compose/Views Androidon) – és minden összetevőnek saját akadálymentesítési címkézésre van szüksége, külön a vizuális dizájntól. Az alapelvek hasonlítanak a WCAG-ra (kontraszt, érintési célméret, világosan hozzáférhető név), de a megvalósításukra szolgáló eszközök teljesen mások.
VoiceOver és TalkBack: nem ugyanaz a képernyőolvasó
A VoiceOver (iOS) és a TalkBack (Android) két különböző képernyőolvasó, különböző navigációs gesztusokkal és az egyéni összetevők eltérő támogatásával. Előfordulhat, hogy az iOS rendszeren tökéletesen megcímkézett összetevő nem működik megfelelően Androidon, ha a fejlesztők nem tesztelték külön mindkét platformot. Nem feltételezheti, hogy "iOS-en teszteltük, tehát Androidon is működnie kell."
💡 Fontos szempont
Mindkét platformon minden interaktív összetevőnek (gombnak, beviteli mezőnek, képnek) szüksége van: egyértelmű akadálymentesítési címkére, meghatározott akadálymentesítési szerepkörre/tulajdonságra, és néha egy akadálymentesítési tippre is, amely elmagyarázza, mi történik, ha megérinti.
Mi az egyedi a natív alkalmazásokban?
A natív alkalmazások olyan kihívásokkal is szembesülnek, amelyek nem léteznek a webhelyeken: egyéni érintési gesztusok (csúsztatással, csípéssel), amelyekhez elérhető alternatívára van szükség; navigáció a képernyők között, amelynek értelmesnek kell lennie a képernyőolvasón keresztül is; és push értesítések, amelyeknek akkor is elérhetőnek kell lenniük, ha magán az alkalmazáson kívül jelennek meg. Ezen túlmenően, az érintési célméreteknek meg kell felelniük a minimum 44x44 pixelnek az Apple irányelvei szerint, és a 48x48 dp-nek a Google irányelvei szerint – ez a követelmény nem mindig létezik ugyanabban a formában a webhelyeken.
Akadálymentes alkalmazás tesztelése
- Kapcsolja be a VoiceOver vagy a TalkBack funkciót, és próbálja meg végrehajtani az alkalmazás alapvető feladatait (regisztráció, vásárlás, keresés) csak ezek használatával.
- Ellenőrizze a kontrasztot és a szövegméretet bekapcsolt rendszer-kisegítő lehetőségek mellett (nagyobb szöveg, nagy kontraszt).
- Erősítse meg a dinamikus szövegméretezés (iOS rendszeren a dinamikus típus) támogatását az elrendezés „eltörése” nélkül.
- Tesztelje le mindkét platformot külön – csak az egyik tesztelése nem elég.
Vannak alkalmazását kísérő dokumentumok is?
Eszközünk beolvassa az alkalmazásához vagy webhelyéhez kapcsolódó PDF-fájlokat – használati feltételeket, útmutatókat, űrlapokat –, és pontosan megmutatja, melyek azok, amelyekre figyelni kell.
Ingyen átvizsgálja webhelyét ←A szkennelés után a talált dokumentumokat közvetlenül és ingyenesen is elérhetővé tehetiAccessiDoc.