Mobilapp akadálymentesítés: a részletek, amiken a használhatóság múlik
Tartalomjegyzék
A telefon ma az elsődleges kapu az internethez. Bankolás, ügyintézés, vásárlás, jegyvásárlás, orvosi időpont: mind egy alkalmazásban dől el. Ez pontosan az a pont, ahol a hozzáférhetőség már nem szép gesztus, hanem működési feltétel. Ha egy app csak a látó, biztos kezű, fiatal felhasználónak jó, akkor a felhasználók egy jelentős részét csendben kizárja.
A mobil akadálymentesítés más műfaj, mint a weboldalé. Kicsi a képernyő, ujjal navigálunk, a fény és a rezgés is beleszól, és a felhasználó gyakran mozgásban van. Ebben a cikkben azt nézzük meg, mely részletek döntik el, hogy egy alkalmazás valóban használható-e mindenki számára.
Az érintőfelületek mérete nem esztétikai kérdés
Az egyik leggyakoribb hiba a túl kicsi, egymáshoz túl közel helyezett gombok. Ha egy vezérlő pár milliméteres, akkor a remegő kézzel, mozgó buszon vagy egyszerűen nagyobb ujjal érintő felhasználó folyamatosan mellényúl. A méretnek van konkrét támpontja is. A WCAG AA szintű minimuma a legutóbbi, 2.2-es változatban 24x24 képpontos érintő-célpontot ír elő, a kényelmesebb 44x44 képpontos méret pedig a szigorúbb AAA szint ajánlása. A gyakorlatban érdemes a nagyobb felé húzni: minél nagyobb és minél távolabb esik egymástól két vezérlő, annál kevesebb a téves érintés.
Ez a szempont könnyen mérhető, és gyorsan javítható. A kényelmes érintőfelület nem csak a fogyatékkal élőnek segít: mindenki pontosabban és gyorsabban használja az appot, ami közvetlenül csökkenti az elhagyott folyamatok arányát.
A képernyőolvasó a legkeményebb próba
Az iOS VoiceOver és az Android TalkBack felolvassa a képernyő tartalmát a vak és gyengénlátó felhasználóknak. Egy app akkor állja ki ezt a próbát, ha minden gombnak, ikonnak és mezőnek van értelmes szöveges neve, ha a felolvasás sorrendje logikus, és ha a felhasználó tudja, éppen hol jár.
A gyakorlatban itt buknak el a legtöbben. A csak ikonból álló gomb “gomb”-ként hangzik el, cím nélkül. A dekoratív képet feleslegesen felolvassa a rendszer. A felugró ablak megjelenik, de a fókusz nem kerül rá, így a képernyőolvasót használó felhasználó nem is tud róla. Ezek a hibák szabad szemmel láthatatlanok, de a képernyőolvasóval azonnal kiderülnek, ezért a tesztelést valódi eszközön, valódi felolvasóval kell elvégezni.
Dinamikus betűméret és kontraszt
Sok felhasználó megnöveli a rendszerszintű betűméretet, mert így tudja kényelmesen olvasni a szöveget. Egy jól felépített app követi ezt a beállítást, és a szöveg nagyobb méretben sem csúszik ki a képernyőről, nem vágódik le és nem lóg egymásra. A merev, fix pontméretre tervezett felület ilyenkor széttörik.
A kontraszt hasonlóan konkrét szám. A normál méretű szöveg és a háttere között legalább 4,5:1 arányú kontrasztra van szükség, a nagyobb szövegnél ez 3:1-re csökkenhet. A halványszürke felirat világos háttéren jól mutathat a tervezői programban, de napfényben, olcsóbb kijelzőn vagy gyengébb látással olvashatatlanná válik. Ez az a fajta hiba, amit egy mérés pontosan kimutat, a szubjektív benyomás viszont elfed.
A hibaüzenet is akadály lehet
A regisztráció és a fizetés akkor gördülékeny, ha a felhasználó nem csak azt látja, hogy valamit elrontott, hanem azt is, hogy pontosan mit és hol. A puszta piros keret nem elég, mert a színvak felhasználó nem érzékeli, a képernyőolvasó pedig nem mondja ki. A jó megoldás szöveges, konkrét hibaüzenetet ad, amit a rendszer fel is olvas, és amely a hibás mezőre irányítja a figyelmet.
Ugyanígy fontos, hogy minden beviteli mezőnek legyen látható, tartós címkéje, ne csak halvány, beírás közben eltűnő segédszöveg. Ezek a részletek döntik el, hogy egy folyamat végigvihető-e, vagy a felhasználó a felénél feladja.
Beépíteni a folyamatba, nem ráaggatni a végén
A leggyakoribb hiba, hogy a csapat a fejlesztés legvégén, kiadás előtt kap észbe, és akkor próbálja utólag hozzáférhetővé tenni a kész terméket. Ez a legdrágább és a legfájdalmasabb út. Egy már felépített képernyőt szétszedni és újratervezni sokkal több munka, mint eleve jól megtervezni.
A jó gyakorlat az, hogy a hozzáférhetőség végigkíséri a folyamatot. A tervezésnél már meghatározott, elég erős kontrasztú színpaletta és a megfelelő méretű érintőfelületek beépülnek a közös komponensekbe, így minden új képernyő automatikusan örökli a helyes alapokat. A fejlesztő nem képernyőnként találgat, hanem egy egyszer jól megcsinált építőkészletből dolgozik.
Ehhez jön a rendszeres, kis léptékű ellenőrzés. Ha minden nagyobb funkció átesik egy gyors képernyőolvasós és billentyűzetes próbán még a kiadás előtt, a hibák akkor derülnek ki, amikor még olcsó javítani őket. Ez a szemlélet hosszú távon kevesebb munka, nem több, és sokkal kiszámíthatóbb eredményt ad.
Az akadálymentesítési nyilatkozat
Az akadálymentesítés nem csak a felület állapotáról szól, hanem arról is, hogy a fejlesztő nyíltan felvállalja, hol tart. Az európai gyakorlatban ezt szolgálja az akadálymentesítési nyilatkozat: egy jól elérhető oldal, amely leírja, milyen szabványnak felel meg a termék, mely részek hozzáférhetők már, hol vannak még ismert hiányosságok, és hogyan lehet segítséget vagy javítást kérni.
Egy mobilalkalmazásnál ez a nyilatkozat legtöbbször az alkalmazás adatlapján vagy a támogatói oldalon kap helyet, és tartalmaz egy elérhetőséget is, ahol a felhasználó jelezheti, ha valamibe beleütközött. Ez a visszajelzési csatorna nem formalitás: gyakran innen derülnek ki azok a valós akadályok, amelyeket a fejlesztői tesztelés nem fogott meg.
A nyilatkozat üzleti értéke, hogy őszinte. Nem azt állítja, hogy minden tökéletes, hanem azt mutatja, hogy a fejlesztő ismeri a saját termékét, és van terve a hiányosságok kezelésére. Egy megrendelőnek, egy partnernek vagy egy közbeszerzési kiírásnak ez pontosan az a fajta átláthatóság, amit elvár.
A tesztelés az egyetlen megbízható visszajelzés
Az akadálymentesség nem érzésre működik. Egy fejlesztő, aki jól lát és minden nap ugyanazt az appot használja, könnyen elhiszi, hogy minden rendben van. A valóság a bekapcsolt képernyőolvasónál, a megnövelt betűméretnél és a kizárólag érintéssel bejárt folyamatnál derül ki. Az automatikus ellenőrző eszközök hasznosak, de a hibák jelentős részét csak emberi, kézi tesztelés fogja meg.
Ezért éri meg időnként külső, szakértői szemmel átnézetni a terméket. Egy alapos mobilalkalmazás akadálymentességi auditja végigmegy a valós felhasználói utakon, konkrét kritériumokhoz méri a felületet, és rangsorolt listát ad arról, mit érdemes először javítani. Így a fejlesztői idő oda kerül, ahol a legtöbbet számít, az eredmény pedig egy olyan alkalmazás lesz, amit tényleg mindenki tud használni.
