A hozzáférhetőség felé

A hozzáférhetőség felé

Pénteken a munkanap vége. A rossz hír mindig a pénteki munkanap végén érkezik.

Éppen távozni készül az irodából, most érkezett postán egy új levél egy újabb átszervezésről.

Köszönöm xxxx, yyy mától zzzz-t fog jelenteni
...
Hugh csapata pedig gondoskodik arról, hogy termékeink elérhetőek legyenek a fogyatékkal élők számára is.

Óh ne! Miért érdemeltem ezt ki? Azt akarják, hogy elmenjek? Készítse fel magát hálátlan kemény munkára, és próbálja kijavítani mások hibáit. Ez határozottan kudarc...

Ez volt elérhető néhány évvel ezelőtt. Néhány szegény lélek azt a feladatot kapta, hogy "megtisztítsák" a felhasználói felületet, hogy megpróbálják hozzáférhetővé tenni a fogyatékkal élők számára.

Hogy ez valójában mit jelentett, az meglehetősen homályos volt – feltehetően ha látna egy fókuszjelzőt és egy tabulátort a mezőkön keresztül, lenne néhány alternatív szöveg és néhány mezőleírás, akkor az alkalmazás elérhetőnek tekinthető...

Ám hirtelen lavina sebességével szaporodni kezdtek a „bogarak”.

Különféle képernyőolvasók (Eng. Képernyőolvasók) és a böngészők teljesen eltérően viselkedtek.

A felhasználók panaszkodtak, hogy az alkalmazás használhatatlan.

Amint az egyik helyen kijavítottak egy hibát, egy másik helyen megjelent egy másik.

A felhasználói felület hibáinak egyszerű megváltoztatása és javítása pedig herkulesi erőfeszítéseket igényelt.

Ott voltam. Túléltem, de nem "sikerült" - technikailag rengeteget takarítottunk, sok terepleírást, szerepkört adtunk hozzá, és elértünk valamilyen szintű megfelelést, de senki sem volt boldog. A felhasználók továbbra is panaszkodtak, hogy nem tudnak navigálni az alkalmazásban. A menedzser továbbra is panaszkodott a folyamatos hibaáradat miatt. A mérnökök kifogásolták, hogy a problémát helytelenül vetették fel, és nincs egyértelműen meghatározott „helyes” megoldás, amely minden esetben működne.

Volt néhány határozottan felnyitó pillanat az akadálymentesítés megértéséhez vezető utam során.
Talán az első az volt, hogy felismerték, hogy a kisegítő lehetőségeket a késztermék mellé nehéz volt hozzáadni. És még nehezebb meggyőzni a vezetőket arról, hogy ez hihetetlenül nehéz! Nem, ez nem csak „adj hozzá néhány címkét”, és a felhasználói felület jól fog működni. Nem, ezt nem lehet három hét alatt befejezni, még három hónap sem lesz elég.
Az igazság következő pillanata akkor jött el, amikor első kézből láttam, hogyan használják a vak felhasználók az alkalmazásunkat. Ez NAGYON különbözik a hibaüzenetek nézésétől.

Újra és újra visszatérek erre, de szinte minden "feltevésünk" arról, hogy az emberek hogyan használták az alkalmazásunkat, tévesek voltak.

Navigálás egy összetett felhasználói felületen billentyűleütésekkel Tab/Shift+Tab - ez szar! Kell valami jobb. Billentyűparancsok, fejlécek.

A kezelőfelület megváltoztatásakor a fókusz elvesztése nem nagy probléma, igaz? Gondoljuk át még egyszer – ez hihetetlenül zavaró.

Folytattam, dolgoztam egy darabig különböző projekteken, majd elkezdtünk egy új projektet, összetett felhasználói felülettel és áttekinthető telepítéssel, hogy ezúttal végre megfelelő legyen az akadálymentesítés.

Tehát hátráltunk egy lépést, és megvizsgáltuk, hogyan tudnánk ezt másképp megvalósítani, és sikerülni, és kevésbé unalmassá tenni a folyamatot!

Elég gyorsan levontuk a következtetéseket:

  1. Nem akartuk, hogy a felhasználói felületet fejlesztők az aria címkékkel/szerepekkel és természetesen a komponensek HTML-struktúrájával vacakoljanak. Megfelelő összetevőket kellett biztosítanunk számukra, amelyek a kisegítő lehetőségeket már a dobozból kiépítették.
  2. Hozzáférhetőség == Könnyű használhatóság – i.e. Ez nem csupán technikai kihívás. Meg kellett változtatnunk a teljes tervezési folyamatot, és gondoskodnunk kellett arról, hogy az akadálymentesítést figyelembe vegyék és megvitassák a felhasználói felület tervezésének megkezdése előtt. Korán át kell gondolnia, hogy a felhasználók hogyan fedeznek fel bármilyen funkciót, hogyan navigálnak, és hogyan működik a jobb gombbal történő kattintás a billentyűzetről. Az akadálymentesítésnek a tervezési folyamat szerves részét kell képeznie – egyes felhasználók számára ez sokkal több, mint az alkalmazás megjelenése.
  3. A kezdetektől fogva szerettünk volna visszajelzést kapni vak és más mozgássérült felhasználóktól az alkalmazás egyszerű használatáról.
  4. Nagyon jó módszerekre volt szükségünk az akadálymentesítési regressziók feltárására.

Nos, mérnöki szempontból az első rész elég szórakoztatónak hangzott - architektúra fejlesztése és komponensek könyvtárának megvalósítása. És valóban így volt.

Hátrál egy lépést, nézel ARIA példák és azáltal, hogy ezt inkább tervezési, mint "beilleszkedési" problémaként gondoltuk, bevezettünk néhány absztrakciót. Egy összetevőnek van egy „Struktúrája” (HTML elemekből áll) és egy „Viselkedése” (hogyan működik együtt a felhasználóval). Például az alábbi töredékekben van egy egyszerű, rendezetlen listánk. A „viselkedések” hozzáadásával a megfelelő szerepkörök hozzáadódnak a listához, hogy az listaként működjön. Ugyanezt tesszük a menüvel is.

A hozzáférhetőség felé

Valójában nem csak szerepkörök vannak hozzáadva, hanem eseménykezelők is a billentyűzetes navigációhoz.

Ez ügyesebben néz ki. Ha tiszta elválasztást kapnánk közöttük, akkor mindegy lenne, hogy a struktúrát hogyan hozták létre, alkalmazhatnánk a Behaviors-t, és megfelelő hozzáférést biztosíthatnánk.

Ezt működés közben láthatja a címen https://stardust-ui.github.io/react/ – UX könyvtár Reagál, amelyet kezdettől fogva az akadálymentesítést szem előtt tartva terveztek és valósítottak meg.

A második rész – a tervezéssel kapcsolatos szemlélet és folyamatok megváltoztatása – kezdetben megijesztett: a szervezeti változásokat átvinni próbáló alacsony mérnököknek nem mindig van jó vége, de ez az egyik legérdekesebb területnek bizonyult, ahol jelentős mértékben hozzájárultunk a folyamathoz. . Dióhéjban a folyamatunk a következő volt: az új funkcionalitást egy csapat fejleszti, majd vezetői csapatunk átnézi/iterálja a javaslatot, majd jóváhagyás után a tervet jellemzően átadjuk a mérnöki csapatnak. Ebben az esetben a mérnöki csapat gyakorlatilag „tulajdonosa” volt a kisegítő lehetőségeknek, mivel az ő felelősségük volt az ezzel kapcsolatos problémák kijavítása.

Kezdetben elég nehéz volt elmagyarázni, hogy a hozzáférhetőség és a használhatóság elválaszthatatlanul összefügg, és ezt már a tervezési szakaszban meg kell tenni, különben nagy változásokhoz, egyes szerepek újradefiniálásához vezetne. A vezetőség és a kulcsszereplők támogatásával azonban megfogadtuk az ötletet, és mozgásba hoztuk, így a tervek hozzáférhetőségét és használhatóságát tesztelték, mielőtt bemutatták volna őket a vezetőségnek.

És ez a visszajelzés rendkívül értékes volt mindenki számára – fantasztikus volt a tudásmegosztás/kommunikáció gyakorlata arról, hogy a felhasználók hogyan kommunikálnak a webalkalmazásokkal, számos UI-problémás területet azonosítottunk azok kiépítése előtt, és a fejlesztőcsapatok most sokkal jobb specifikációkkal rendelkeznek a tervezésnek csak vizuális, de viselkedési vonatkozásai is. Az igazi megbeszélések szórakoztató, energikus, szenvedélyes viták a technikai szempontokról és interakciókról.

Ezt még jobban megtehetnénk, ha vak és fogyatékkal élő felhasználók jelennének meg ezeken (vagy az azt követő) találkozókon – ezt nehéz volt megszervezni, de ma már együttműködünk helyi vak szervezetekkel és vállalatokkal is, amelyek külső tesztelést biztosítanak a végrehajtási folyamat korai szakaszában történő ellenőrzésére. fejlesztés – mind a komponens, mind a végrehajtási folyamat szintjén.

A mérnökök már meglehetősen részletes specifikációkkal, a megvalósításhoz felhasználható összetevőkkel és a végrehajtási folyamat érvényesítésének módjával rendelkeznek. A tapasztalatok egy része az, amit mindvégig hiányoltunk – hogyan állíthatjuk meg a regressziót. Hasonlóképpen, az emberek integrációt vagy végpontok közötti teszteket használhatnak a funkcionalitás tesztelésére, amelyre szükségünk van az interakciók és a végrehajtási folyamatok változásainak észleléséhez – mind a vizuális, mind a viselkedésbeli.

A vizuális regresszió meghatározása meglehetősen definiált feladat, nagyon keveset lehet hozzátenni a folyamathoz azon kívül, hogy esetleg ellenőrizni kell, hogy a billentyűzettel navigálva látható-e a fókusz. Érdekesebb két viszonylag új technológia a kisegítő lehetőségek kezelésére.

  1. Hozzáférhetőségi betekintések egy olyan eszközkészlet, amely a böngészőben és a build/tesztciklus részeként is futtatható a problémák azonosítására.
  2. A képernyőolvasók megfelelő működésének ellenőrzése különösen nagy kihívást jelentett. A hozzáférés bevezetésével Kisegítő lehetőségek DOM, végre készíthetünk kisegítő lehetőségekről pillanatfelvételeket az alkalmazásról, hasonlóan a vizuális tesztekhez, és tesztelhetjük őket a regresszió szempontjából.

Így a történet második részében a HTML kód szerkesztéséről áttértünk az absztrakció magasabb szintjére, megváltoztattuk a tervezési folyamatot, és alapos tesztelést vezettünk be. Az új folyamatok, az új technológiák és az absztrakció új szintjei teljesen megváltoztatták az akadálymentesítés környezetét és azt, hogy mit jelent ezen a téren dolgozni.
De ez még csak a kezdet.

A következő „megértés” az, hogy a vak felhasználók élvonalbeli technológiát vezetnek – ők azok, akik nem csak a korábban leírt változásokból profitálnak a legtöbbet, hanem abból is, hogy az ML/AI új megközelítéseket és ötleteket tesz lehetővé. Például az Immersive Reader technológia lehetővé teszi a felhasználók számára a szöveg egyszerűbb és érthetőbb bemutatását. Hangosan felolvasható, nyelvtanilag bontható a mondatszerkezet, sőt grafikusan megjeleníti a szavak jelentését is. Ez egyáltalán nem illik a régi „hozzáférhetővé” mentalitásba – ez egy olyan használhatósági funkció, amely mindenkinek a segítségére lesz.

Az ML/AI teljesen új interakciós és munkamódszereket tesz lehetővé, és izgatottak vagyunk, hogy részesei lehetünk ennek az élvonalbeli utazásnak a következő szakaszában. Az innovációt a gondolkodás megváltozása vezérli - az emberiség évezredek óta létezik, a gépek több száz éve, a weboldalak több évtizede, az okostelefonok pedig még kevésbé, a technológiának alkalmazkodnia kell az emberekhez, és nem fordítva.

P.S. A cikk az eredetitől kisebb eltérésekkel lett lefordítva. A cikk társszerzőjeként egyetértettem Hugh-val ezekben a kitérőkben.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Odafigyel alkalmazásai akadálymentesítésére?

  • Igen

  • Nincs

  • Ez az első alkalom, hogy hallok az alkalmazások kisegítő lehetőségeiről.

17 felhasználó szavazott. 5 felhasználó tartózkodott.

Forrás: will.com

Hozzászólás