Biyernes ang pagtatapos ng araw ng trabaho. Palaging dumarating ang masamang balita sa pagtatapos ng araw ng trabaho sa Biyernes.
Aalis ka na sa opisina, isang bagong liham tungkol sa isa pang reorganisasyon ang dumating sa koreo.
Salamat xxxx, yyy simula ngayon magrereport ka na zzzz
...
At titiyakin ng koponan ni Hugh na ang aming mga produkto ay naa-access ng mga taong may mga kapansanan.
Oh hindi! Bakit karapatdapat ako nito? Gusto ba nila akong umalis? Itakda ang iyong sarili para sa walang pasasalamat na pagsusumikap at pagsisikap na itama ang mga pagkakamali ng ibang tao. Ito ay tiyak na isang kabiguan ...
Ito ang availability ilang taon na ang nakalipas. Ang ilang mahihirap na kaluluwa ay binigyan ng trabaho ng "paglilinis" ng UI upang subukan at gawin itong naa-access ng mga taong may mga kapansanan.
Kung ano talaga ang ibig sabihin nito ay medyo malabo - siguro kung makakakita ka ng focus indicator at tab sa pamamagitan ng mga field, magkaroon ng ilang alt text at ilang mga paglalarawan sa field, maituturing na ang iyong application ay naa-access ...
Ngunit biglang nagsimulang dumami ang "mga bug" sa bilis ng isang avalanche.
Iba't ibang screen reader (Eng. Mga Screen Reader) at mga browser ay ganap na naiibang kumilos.
Nagreklamo ang mga user na hindi magagamit ang app.
Sa sandaling ang isang error ay naitama sa isang lugar, isa pang lumitaw sa isa pa.
At ang simpleng pagbabago at pagwawasto ng mga error sa user interface ay nangangailangan ng mga pagsisikap ng Herculean.
nandoon ako. Nakaligtas ako, ngunit hindi kami "nagtagumpay" - sa teknikal na paraan, marami kaming nilinis, nagdagdag ng maraming paglalarawan sa field, mga tungkulin, at nakamit ang ilang antas ng pagsunod, ngunit walang natuwa. Nagreklamo pa rin ang mga user na hindi nila ma-navigate ang application. Nagreklamo pa rin ang manager tungkol sa patuloy na daloy ng mga pagkakamali. Ang mga inhinyero ay nagreklamo na ang problema ay naipakita nang hindi tama, na walang malinaw na tinukoy na "tama" na solusyon na gagana sa lahat ng mga kaso.
Mayroong ilang tiyak na mga sandali na nagbubukas ng mata sa aking paglalakbay upang maunawaan ang pagiging naa-access.
Marahil ang una ay ang pagkaunawa na ang pagdaragdag ng functionality ng pagiging naa-access sa itaas ng isang tapos na produkto ay mahirap. At mas mahirap kumbinsihin ang mga manager na napakahirap! Hindi, hindi lang ito "magdagdag ng ilang tag" at gagana nang maayos ang UI. Hindi, hindi ito makukumpleto sa loob ng tatlong linggo; kahit tatlong buwan ay hindi magiging sapat.
Ang aking susunod na sandali ng katotohanan ay dumating nang makita ko mismo kung paano aktwal na ginamit ng mga bulag na gumagamit ang aming app. Ibang-iba ito sa pagtingin sa mga mensahe ng error.
Babalik ako dito nang paulit-ulit, ngunit halos lahat ng aming "pagpapalagay" tungkol sa kung paano ginamit ng mga tao ang aming app ay mali.
Pag-navigate sa isang kumplikadong user interface gamit ang mga keystroke Tab/Shift+Tab - nakakainis! Kailangan natin ng mas maganda. Mga keyboard shortcut, mga header.
Ang pagkawala ng focus kapag binabago ang UI ay hindi isang malaking problema, hindi ba? Pag-isipan natin muli - ito ay hindi kapani-paniwalang nakakalito.
Nagpatuloy ako, nagtrabaho sa iba't ibang mga proyekto nang ilang sandali, at pagkatapos ay nagsimula kami ng isang bagong proyekto, na may isang kumplikadong interface ng gumagamit at isang malinaw na pag-install, upang sa wakas ay makakuha ng accessibility sa oras na ito.
Kaya, umatras kami ng isang hakbang at tiningnan kung paano namin ito maipapatupad sa ibang paraan at magtatagumpay, at gawing hindi nakakabagot ang proseso!
Mabilis na nakarating kami sa ilang mga konklusyon:
- Hindi namin nais na ang mga tao na bumubuo ng user interface ay magulo sa mga label/role ng aria at, siyempre, ang istruktura ng HTML ng mga bahagi. Kailangan naming bigyan sila ng mga tamang bahagi na bumuo ng accessibility mula mismo sa kahon.
- Accessibility == Dali ng paggamit - i.e. Ito ay hindi lamang isang teknikal na hamon. Kailangan naming baguhin ang buong proseso ng disenyo at tiyaking isinaalang-alang at tinalakay ang pagiging naa-access bago magsimula ang disenyo ng UI. Kailangan mong pag-isipan nang maaga kung paano matutuklasan ng mga user ang anumang functionality, kung paano sila mag-navigate, at kung paano gagana ang pag-right click mula sa keyboard. Ang pagiging naa-access ay dapat na isang mahalagang bahagi ng proseso ng disenyo - para sa ilang mga gumagamit ito ay higit pa sa hitsura ng application.
- Sa simula pa lang, gusto naming makakuha ng feedback mula sa mga bulag at iba pang may kapansanan na mga user tungkol sa kadalian ng paggamit ng application.
- Kailangan namin ng napakahusay na paraan para mahuli ang mga regression ng accessibility.
Buweno, mula sa isang pananaw sa engineering, ang unang bahagi ay medyo masaya - pagbuo ng isang arkitektura at pagpapatupad ng isang library ng mga bahagi. At totoo nga.
Paatras ng isang hakbang, nakatingin at sa pamamagitan ng pag-iisip na ito bilang isang problema sa disenyo sa halip na isang "angkop sa" problema, ipinakilala namin ang ilang abstraction. Ang isang bahagi ay may 'Istruktura' (binubuo ng mga elemento ng HTML) at isang 'Gawi' (kung paano ito nakikipag-ugnayan sa user). Halimbawa, sa mga snippet sa ibaba mayroon kaming isang simpleng hindi nakaayos na listahan. Sa pamamagitan ng pagdaragdag ng "mga pag-uugali" ang mga kaukulang tungkulin ay idinaragdag sa listahan upang gawin itong parang isang listahan. Ginagawa namin ang parehong para sa menu.
Sa katunayan, hindi lamang mga tungkulin ang idinagdag dito, kundi pati na rin ang mga tagapangasiwa ng kaganapan para sa pag-navigate sa keyboard.
Mukhang mas maayos ito. Kung makakakuha tayo ng malinis na paghihiwalay sa pagitan nila, hindi mahalaga kung paano ginawa ang istraktura, maaari nating ilapat ang Mga Pag-uugali dito at makuha ang tamang accessibility.
Makikita mo ito sa aksyon sa – UX library , na idinisenyo at ipinatupad nang nasa isip ang pagiging naa-access mula sa simula.
Ang ikalawang bahagi - ang pagbabago ng diskarte at mga proseso sa paligid ng disenyo ay unang natakot sa akin: ang mga mababang inhinyero na sinusubukang isulong ang pagbabago sa organisasyon ay hindi palaging nagtatapos nang maayos, ngunit ito ay naging isa sa mga pinaka-kagiliw-giliw na lugar kung saan kami ay gumawa ng makabuluhang kontribusyon sa proseso . Sa madaling sabi, ang aming proseso ay ang mga sumusunod: bagong functionality ay bubuo ng isang team, pagkatapos ay susuriin/uulitin ng aming leadership team ang panukala, at pagkatapos, kapag naaprubahan, ang disenyo ay karaniwang ibibigay sa engineering team. Sa kasong ito, epektibong "pagmamay-ari" ng engineering team ang functionality ng accessibility dahil responsibilidad nilang ayusin ang anumang isyung nauugnay dito.
Sa simula, medyo mahirap na trabaho na ipaliwanag na ang pagiging naa-access at kakayahang magamit ay hindi mapaghihiwalay na nauugnay at kailangan itong gawin sa yugto ng disenyo, kung hindi, hahantong ito sa malalaking pagbabago at muling pagtukoy ng ilang mga tungkulin. Gayunpaman, sa suporta ng pamamahala at mga pangunahing manlalaro, kinuha namin ang ideya at isinagawa ito upang ang mga disenyo ay masuri para sa pagiging naa-access at kakayahang magamit bago sila iharap sa pamamahala.
At ang feedback na ito ay lubhang mahalaga sa lahat - ito ay hindi kapani-paniwala bilang isang ehersisyo sa pagbabahagi ng kaalaman/komunikasyon tungkol sa kung paano nakikipag-ugnayan ang mga user sa mga web application, natukoy namin ang maraming lugar ng problema sa UI bago ang mga ito ay binuo, ang mga development team sa ngayon ay may mas mahusay na mga detalye ng hindi visual lamang, ngunit pati na rin ang mga aspeto ng pag-uugali ng disenyo. Ang mga tunay na talakayan ay masaya, masigla, madamdaming talakayan tungkol sa mga teknikal na aspeto at pakikipag-ugnayan.
Magagawa namin ito nang mas mahusay kung mayroon kaming mga bulag at may kapansanan na mga user sa mga (o kasunod na) pagpupulong na ito - mahirap itong ayusin, ngunit nakikipagtulungan na kami ngayon sa parehong mga lokal na organisasyong bulag at kumpanya , na nagbibigay ng panlabas na pagsubok upang ma-verify ang daloy ng pagpapatupad nang maaga sa pag-unlad—kapwa sa bahagi at antas ng daloy ng pagpapatupad.
Ang mga inhinyero ay mayroon na ngayong medyo detalyadong mga detalye, magagamit na mga bahagi na magagamit nila upang ipatupad, at isang paraan upang patunayan ang daloy ng pagpapatupad. Bahagi ng itinuro sa amin ng karanasan ay kung ano ang nawawala sa amin—kung paano namin mapipigilan ang regression. Gayundin, maaaring gumamit ang mga tao ng integration o end-to-end na mga pagsubok upang subukan ang functionality, na kailangan nating makita ang mga pagbabago sa mga pakikipag-ugnayan at daloy ng pagpapatupad—parehong visual at asal.
Ang pagtukoy sa visual regression ay isang medyo tinukoy na gawain, napakakaunti ang maaaring maidagdag sa proseso maliban sa pagsuri kung nakikita ang focus kapag nagna-navigate gamit ang keyboard. Mas kawili-wili ang dalawang medyo bagong teknolohiya para sa pagtatrabaho nang may accessibility.
- ay isang set ng mga tool na maaaring patakbuhin pareho sa browser at bilang bahagi ng build/test cycle upang matukoy ang mga problema.
- Ang pag-verify na gumagana nang tama ang mga screen reader ay isang partikular na mahirap na gawain. Sa pagpapakilala ng access sa Accessibility DOM, sa wakas ay nakakakuha na kami ng mga snapshot ng accessibility ng app, katulad ng ginagawa namin para sa mga visual na pagsubok, at nasubok ang mga ito para sa regression.
Kaya, sa ikalawang bahagi ng kuwento - lumipat kami mula sa pag-edit ng HTML code patungo sa pagtatrabaho sa mas mataas na antas ng abstraction, binago ang proseso ng pagbuo ng disenyo at ipinakilala ang masusing pagsubok. Ang mga bagong proseso, mga bagong teknolohiya, at mga bagong antas ng abstraction ay ganap na nagbago sa tanawin ng pagiging naa-access at kung ano ang ibig sabihin ng magtrabaho sa espasyong ito.
Ngunit ito ay simula pa lamang.
Ang susunod na "pag-unawa" ay ang mga bulag na gumagamit ay nagtutulak ng makabagong teknolohiya - sila ang higit na nakikinabang hindi lamang sa mga pagbabagong inilarawan namin kanina, kundi pati na rin na ang mga bagong diskarte at ideya ay ginawang posible ng ML/AI. Halimbawa, ang teknolohiya ng Immersive Reader ay nagbibigay-daan sa mga user na magpakita ng teksto nang mas madali at malinaw. Maaari itong basahin nang malakas, ang istraktura ng pangungusap ay pinaghiwa-hiwalay ayon sa gramatika, at maging ang mga kahulugan ng salita ay ipinapakita nang graphical. Hindi ito umaangkop sa lumang kaisipang "gawin itong naa-access" - isa itong tampok na kakayahang magamit na makakatulong sa lahat.
Pinapagana ng ML/AI ang mga ganap na bagong paraan ng pakikipag-ugnayan at pagtatrabaho, at nasasabik kaming maging bahagi ng mga susunod na yugto ng makabagong paglalakbay na ito. Ang pagbabago ay hinihimok ng isang pagbabago sa pag-iisip - ang sangkatauhan ay umiral sa loob ng millennia, mga makina sa daan-daang taon, mga website sa loob ng ilang dekada, at mas kaunti pa ang mga smartphone, ang teknolohiya ay dapat umangkop sa mga tao, at hindi ang kabaligtaran.
P.S. Ang artikulo ay isinalin na may maliliit na paglihis mula sa orihinal. Bilang isang co-author ng artikulong ito, sumang-ayon ako sa mga digression na ito kay Hugh.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Binibigyang-pansin mo ba ang pagiging naa-access ng iyong mga aplikasyon?
-
Oo
-
Hindi
-
Ito ang unang pagkakataon na narinig ko ang tungkol sa pagiging naa-access ng app.
17 user ang bumoto. 5 na user ang umiwas.
Pinagmulan: www.habr.com