🥇Az elérhetőség felé

Péntek – a munkaidő vége. A rossz hírek mindig pénteken, a munkaidő végén érkeznek.

Készen áll a hivatal elhagyására, amikor a 'csengő' új üzenet érkezik a legújabb átszervezésről az emailre.

Köszönöm xxxx, yyy, a mai naptól ön jelentést tesz zzzz.
…
És a Hugh csapata biztosítja termékeink elérhetőségét a fogyatékkal élők számára.

Ó, nem! Miért érdemlem ezt? Azt akarják, hogy elmenjek? Felkészülni egy hálátlan, nehéz munkára és megpróbálni mások hibáit kijavítani. Ez biztosan kudarc lesz...

Így nézett ki az elérhetőség néhány évvel ezelőtt. Néhány szegény ember azt a feladatot kapta, hogy "takarítson" a felhasználói felületen, hogy próbálják elérhetővé tenni azt a fogyatékkal élők számára.

Amit ez valójában jelentett, meglehetősen homályos volt – valószínűleg ha látta a fókuszindikátort és a mezők között tabulálva tudott navigálni, volt valamilyen alternatív szöveg és néhány mező leírás, azt tekintették, hogy az alkalmazása elérhető...

De hirtelen a "hibák" lavinaszerűen kezdtek szaporodni.

Különböző képernyőolvasók (angol. Screen Readers) és böngészők teljesen eltérően viselkedtek.

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

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

És egyszerűen a felhasználói felület hibáinak javítása óriási erőfeszítéseket igényelt.

Ott voltam. Túléltem, de nem "sikerült" – technikailag sok mindent kitakarítottunk, számos mező leírást adtunk hozzá, szerepeket alakítottunk ki, és elértünk valamilyen szintű megfelelést, de senki sem volt elégedett. A felhasználók továbbra is panaszkodtak, hogy nem tudnak eligibilis módon navigálni az alkalmazásban. A menedzser továbbra is panaszkodott a folyamatos hibafolyamra. A mérnökök panaszkodtak a helytelen feladatmeghatározásra, egyértelműen meghatározott "helyes" megoldás nélkül, ami minden esetben működne.

Az elérhetőség megértésének útján egyértelműen akadtak nyilvánvaló pillanatok.
Talán az első lépés az volt, hogy megértettük, hogy a meglévő termék fölé akadálymentességi funkciókat hozzáadni nehéz. És még nehezebb meggyőzni a menedzsereket arról, hogy ez hihetetlenül bonyolult! Nem, ez nem csak annyit jelent, hogy "hozzáadtunk pár címkét", és a felhasználói felület jól fog működni. Nem, ezt három hét alatt nem lehet befejezni, még három hónap is kevés lesz.
A következő megérkezésem akkor jött el, amikor saját szememmel láttam, hogyan használják a vak felhasználók az alkalmazásunkat. Ez TOTÁLISAN eltér attól, hogy a hibabejegyzéseket nézzük.

Újra és újra visszatérni fogok ehhez, de szinte minden "feltételezésünk" arról, hogyan használták az emberek az alkalmazásunkat, tévesnek bizonyult.

Navigálás a bonyolult felhasználói felületen a billentyűkkel Tab/Shift+Tab – ez elég rossz! Valami jobb kellene. Billentyűkombinációk, címkék.

A fókuszvesztés a felhasználói felület megváltoztatásakor nem egy nagy probléma? Gondoljunk csak bele – ez őrülten zavaró.

Folytattam, eléggé különböző projekteken dolgoztam, majd elkezdtünk egy új projektet, bonyolult felhasználói felülettel és azzal a világos céllal, hogy végre most megfelelő akadálymentességet érjünk el.

Tehát hátraléptünk, és megnéztük, hogyan tudnánk ezt másképpen megvalósítani, hogy sikeresek legyünk, és hogy maga a munka folyamata ne legyen unalmas!

Elég gyorsan eljutottunk néhány következtetéshez:

Nem akartuk, hogy a felhasználói felületet fejlesztő emberek bajlódjanak az aria címkékkel/szerepekkel és természetesen a komponensek HTML struktúrájával. Olyan komponensekre volt szükségünk, amelyekből az akadálymentesség közvetlenül elérhető.
Akadálymentesség == Használhatóság – azaz nem csupán technikai feladat. Meg kellett változtatnunk az egész tervezési folyamatot, és biztosítani, hogy az akadálymentességet figyelembe vegyék és megbeszéljék a felhasználói felület tervezésének megkezdése előtt. Eleve átgondolandó, hogyan találják meg a felhasználók a funkciókat, hogyan fognak navigálni, és hogyan fog működni az "egér jobb gombja" billentyűzet használatával. Az akadálymentességnek a tervezési folyamat szerves részének kell lennie – egyes felhasználók számára ez sokkal többet jelent, mint egyszerűen az alkalmazás megjelenése.
Kezdetektől fogva szeretnénk visszajelzéseket kapni vakoktól és más mozgáskorlátozott felhasználóktól az alkalmazás használhatóságáról.
Valóban jó módszerekre volt szükségünk az akadálymentesség regressziójának észlelésére.

Nos, mérnöki szempontból az első rész meglehetősen szórakoztatónak hangzott – az architektúra fejlesztése és a komponenskönyvtár bevezetése. És valóban az is volt.

Hátra lépve és szemlélve az ARIA példákat és úgy tekintve erre, mint tervezési problémára, nem pedig „alkalmazkodási” problémára, bevezettünk néhány absztrakciót. A komponensnek van egy 'Struktúrája' (HTML elemekből áll) és „Viselkedése” (hogyan lép kapcsolatba a felhasználóval). Például az alábbi töredékekben egy egyszerű rendezetlen listát látunk. Amikor viselkedést adunk a listához, a megfelelő szerepeket adjuk hozzá, hogy úgy működjön, mint egy lista. Hasonlóan járunk el a menükkel is.

Valójában nemcsak szerepeket, hanem eseménykezelőket is hozzáadunk a billentyűzetes navigációhoz.

Ez már sokkal rendezettebbnek tűnik. Ha tiszta megkülönböztetést tudnánk kialakítani közöttük, akkor nem lenne fontos, hogy a struktúra hogyan készült, viselkedéseket (Behaviours) alkalmazhatnánk rá, és a megfelelő akadálymentességet biztosíthatnánk.

Ez a gyakorlatban a következő címen látható https://stardust-ui.github.io/react/ – UX könyvtár React, amelyet a kezdetektől fogva az akadálymentesség figyelembevételével terveznek és valósítanak meg.

A második rész – a dizájn körüli megközelítés és folyamatok megváltoztatása – kezdetben megijesztett: a szerény mérnökök, akik megpróbálnak szervezeti változásokat keresztülvinni, nem mindig zárulnak jól, de ez bizonyult az egyik legérdekesebb területnek, ahol jelentős hozzájárulásaink voltak a folyamatban. Egyszóval, a következő folyamatunk volt: az új funkciót egy csapat fejlesztette, majd csoportunk vezetői elemezték/iterálták a javaslatot, és után, általában, a dizájn átkerült az mérnökcsapathoz. Ebben az esetben a mérnökcsapat lényegében a akadálymentességi funkció „tulajdonosa” volt, mivel nekik kellett megoldaniuk a kapcsolódó problémákat.

Eleinte elég nehéz feladat volt elmagyarázni, hogy a hozzáférhetőség és a használhatóság elválaszthatatlanul összefonódik, és ezt már a tervezési szakaszban ki kell alakítani, különben jelentős változtatásokra és bizonyos szerepek újbóli meghatározására kerül sor. Ennek ellenére a vezetőség és a kulcsszereplők támogatásával sikerült eljuttatni ezt az elképzelést, és bevezetni, hogy a tervek hozzáférhetőségi és használhatósági ellenőrzésen essenek át, mielőtt bemutatnák a vezetőségnek.

Ezek a visszajelzések rendkívül értékesek voltak mindenki számára – fantasztikus volt tudásmegosztásként/az információk átadásaként, amely bemutatta, hogyan lépnek interakcióba a felhasználók a webalkalmazásokkal. Számos problémás területet határoztunk meg a felhasználói felületen, még azelőtt, hogy megépítették volna őket, a fejlesztői csapatok most sokkal jobb specifikációkkal rendelkeznek, nemcsak a vizuális, hanem a viselkedési területeken is. A tényleges megbeszélések szórakoztató, energikus, szenvedélyes vitákról szólnak a technikai aspektusokról és az interakciókról.

Még jobban végezhettük volna ezt a munkát, ha a találkozókon (vagy a későbbi találkozókon) vak felhasználók és fogyatékkal élő felhasználók is részt vettek volna – nehéz volt ezt megszervezni, de most valóban együttműködünk helyi vakokat segítő szervezetekkel és olyan cégekkel, amelyek külső tesztelési szolgáltatásokat nyújtanak a végrehajtási folyamat korai szakaszainak ellenőrzésére – mind a komponens, mind a végrehajtási folyamat szintjén.

Most a mérnökök meglehetősen részletes specifikációkkal rendelkeznek, elérhető komponensekkel, amelyeket felhasználhatnak az implementáláshoz, és módszerekkel a végrehajtási folyamat ellenőrzésére. Részben a tapasztalat megtanította nekünk, hogy mit mulasztottunk el folyamatosan – hogyan tudjuk megakadályozni a regressziót. Hasonlóképpen az emberek integrációs vagy végigjárási teszteket használhatnak a szükséges funkciók ellenőrzésére, amelyek segítenek az interakciók és végrehajtási folyamatok, mind vizuális, mind viselkedési szempontból bekövetkező változásainak észlelésében.

A vizuális regresszió meghatározása meglehetősen konkrét feladat, nagyon kevés dolog adható hozzá a folyamathoz, kivéve talán annak ellenőrzését, hogy látható-e a fókusz a billentyűzettel való navigáció során. Két viszonylag új technológia az elérhetőséggel kapcsolatban érdekesebb témának számít.

Accessibility Insights – ez egy olyan eszközkészlet, amely a böngészőben és a build/tesztsorozat keretében is futtatható a problémák azonosítására.
A képernyőolvasó szoftverek működésének tesztelése különösen nehéz feladat volt. Az Accessibility DOM, megvalósításával végre lehetőségünk van arra, hogy elérhetőségi szempontból készítsünk képet az alkalmazásról, nagyon hasonlóan ahhoz, ahogyan a vizuális teszteknél tesszük, és teszteljük azokat regresszióra.

Tehát a történet második részében áttértünk a HTML-kód szerkesztéséről egy magasabb absztrakciós szintre, megváltoztattuk a tervezési folyamatot, és bevezettük a gondos tesztelést. Az új folyamatok, új technológiák és új absztrakciós szintek teljesen megváltoztatták az elérhetőség fogalmát és azt, hogy mit is jelent e területen dolgozni.
De ez csak a kezdet.

A következő „megértés” az, hogy a vak felhasználók elősegítik a legmodernebb technológiák fejlődését – ők nemcsak az előttünk álló változások legnagyobb haszonélvezői, de az új megközelítések és ötletek is lehetővé válnak a ML/AI által. Például az Immersive Reader technológia lehetővé teszi a felhasználók számára, hogy a szöveget könnyebben és érthetőbben reprezentálják. Fel lehet olvasni, a mondatszerkezet grammatikailag elválik, és még a szavak jelentése is grafikus formában jelenik meg. Ez teljesen eltér az „elérhetővé tenni” régi felfogásától – ez egy használhatósági funkció, amely mindenki számára hasznos.

A ML/AI új módokat hoz létre az interakcióra és a munkavégzésre, és örömmel vagyunk a következő lépések részesei ezen a korszerű úton. Az innovációk a gondolkodásmód megváltozásából fakadnak – az emberiség évezredek óta létezik, a gépek több mint száz éve, a weboldalak néhány évtizede, míg az okostelefonok még kevésbé, a technológia az emberekhez kell, hogy alkalmazkodjon, nem fordítva.

P.S. A cikket az eredetitől némileg eltérő módon fordították le. Mint a cikk társszerzője, ezeket az eltéréseket Hugh-val egyeztettem.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.