У напрамку да даступнасці

У напрамку да даступнасці

Пятніца - канец працоўнага дня. Дрэнныя навіны заўсёды прыходзяць у пятніцу пад канец працоўнага дня.

Вы збіраецеся пакінуць офіс, «дзінь» новы ліст наконт чарговай рэарганізацыі толькі што прыйшоў на пошту.

Дзякуй xxxx, yyy з сённяшняга дня вы будзеце даваць справаздачу zzzz
...
І каманда Х'ю забяспечыць даступнасць нашых прадуктаў для людзей з абмежаванымі магчымасцямі.

О не! Завошта я заслужыў гэта? Яны жадаюць, каб я сышоў? Настроіцца на няўдзячную цяжкую працу і спрабаваць выправіць памылкі іншых людзей. Гэта напэўна правал…

Такой была даступнасць некалькі гадоў таму. Некаторыя небаракі атрымлівалі працу па "ачыстцы" карыстацкага інтэрфейсу, каб паспрабаваць зрабіць яго даступным для людзей з абмежаванымі магчымасцямі.

Тое, што гэта на самой справе азначала, было даволі расплывістае - верагодна, калі б вы маглі бачыць індыкатар фокусу і перамяшчацца па палях з дапамогай табуляцыі, мець нейкі альтэрнатыўны тэкст і парачку апісанняў да палёў, гэта б лічылася, што ваша прыкладанне даступна …

Але раптам «багі» пачалі размнажацца з хуткасцю лавіны.

Розныя экранныя счытвальныя прылады (англійская (Screen Readers) і браўзэры паводзілі сябе абсалютна па-рознаму.

Карыстальнікі скардзіліся, што прыкладанне не прыдатнае для выкарыстання.

Як толькі памылка выпраўлялася ў адным месцы, з'яўлялася іншая ў іншым.

І, проста мяняць і выпраўляць памылкі карыстацкага інтэрфейсу, патрабавала тытанічных намаганняў.

Я там быў. Я выжыў, але мы не атрымалі поспех - тэхнічна мы шмат ачысцілі, дадалі шмат апісанняў да палёў, роляў і дасягнулі нейкага ўзроўню адпаведнасці патрабаванням, але ніхто не быў шчаслівы. Карыстальнікі ўсё роўна скардзіліся, што не могуць арыентавацца ў дадатку. Мэнэджар усё роўна скардзіўся на пастаянны паток памылак. Інжынеры скардзіліся на няправільную пастаноўку задачы, без дакладна вызначанага "правільнага" рашэння, якое працавала б ва ўсіх выпадках.

На маім шляху да разумення даступнасці сустрэліся некаторыя яўна адкрытыя моманты.
Магчыма, першым было разуменне таго, што дадаваць функцыянальнасць даступнасці па-над гатовым прадуктам – гэта складана. І яшчэ складаней пераканаць мэнэджараў, што гэта неверагодна складана! Не, гэта не проста "дадаў некалькі тэгаў" і карыстацкі інтэрфейс будзе працаваць выдатна. Не, гэта немагчыма скончыць за тры тыдні, нават тры месяцы будзе мала.
Мой наступны момант ісціны наступіў, калі я на свае вочы ўбачыў, як сляпыя карыстальнікі на самай справе выкарыстоўваюць наша дадатак. Гэта ТАК адрозніваецца ад прагляду паведамленняў аб памылках.

Я буду вяртацца да гэтага зноў і зноў, але амаль усе нашыя «здагадкі» аб тым, як людзі выкарыстоўвалі наша дадатак, былі памылковымі.

Навігацыя па складаным карыстацкім інтэрфейсе пры дапамозе клавіш Tab/Shift+Tab - Гэта адстой! Трэба што-небудзь лепей. Спалучэнні клавіш, загалоўкі.

Страта фокусу пры змене UI гэта ж не вялікая праблема? Падумаем яшчэ раз - гэта вар'яцка збівае з панталыку.

Я працягваў, некаторы час працаваў над рознымі праектамі, а потым мы пачалі новы праект, са складаным карыстацкім інтэрфейсам і дакладнай устаноўкай, каб нарэшце ў гэты раз атрымаць правільную даступнасць.

Такім чынам, мы зрабілі крок назад і паглядзелі, як мы можам рэалізаваць гэта па-іншаму і атрымаць поспех, і каб сам працэс працы быў нянудным!

Даволі хутка мы прыйшлі да некаторых высноваў:

  1. Мы не жадалі, каб людзі, якія распрацоўваюць карыстацкі інтэрфейс, важдаліся з aria надпісамі/ролямі і, натуральна з HTML структурай кампанентаў. Нам трэба было забяспечыць іх правільнымі кампанентамі, у якіх даступнасць рэалізавана прама са скрынкі.
  2. Даступнасць == Выгода выкарыстання - г.зн. гэта не толькі тэхнічная задача. Нам трэба было змяніць увесь працэс праектавання і пераканацца, што даступнасць бярэцца да ўвагі і абмяркоўваецца да пачатку праектавання карыстацкага інтэрфейсу. Неабходна першапачаткова абдумваць, як карыстачы могуць выявіць якую-небудзь функцыянальнасць, як яны будуць перамяшчацца і як будзе працаваць "правы клік мышы" з клавіятуры. Даступнасць павінна быць неад'емнай часткай працэсу праектавання – для некаторых карыстальнікаў яна з'яўляецца чымсьці значна большым, чым проста вонкавы выгляд прыкладання.
  3. З самага пачатку мы хацелі атрымаць водгукі ад сляпых і іншых карыстальнікаў з абмежаванымі магчымасцямі аб прастаце выкарыстання прыкладання.
  4. Нам былі патрэбны сапраўды добрыя спосабы адлоўліваць рэгрэсію даступнасці.

Ну, з інжынернага пункта гледжання, першая частка гучала даволі весяла - распрацоўка архітэктуры і ўкараненне бібліятэкі кампанентаў. І сапраўды так яно і было.

Робячы крок назад, разглядаючы прыклады ARIA і задумваючыся аб гэтым як аб праблеме дызайну, а не аб праблеме "прыстасоўвацца", мы ўвялі некаторыя абстракцыі. Кампанент мае 'Структуру' (складаецца з HTML-элементаў) і 'Паводзіны' (як ён узаемадзейнічае з карыстачом). Напрыклад, у прыведзеных ніжэй фрагментах мы маем просты неўпарадкаваны спіс. Пры даданні "паводзін" да спісу дадаюцца адпаведныя ролі, каб ён дзейнічаў як спіс. Аналагічна які робіцца для меню.

У напрамку да даступнасці

Насамрэч, тут дадаюцца не толькі ролі, але і апрацоўшчыкі падзей для навігацыі пры дапамозе клавіятуры.

Гэта выглядае ўжо больш ахайна. Калі б мы маглі атрымаць чысты падзел паміж імі, было б усё роўна, як была створана структура, мы маглі б прымяніць да яе паводзін (Behaviours) і атрымаць правільную даступнасць.

У дзеянні гэта можна ўбачыць па адрасе https://stardust-ui.github.io/react/ – UX бібліятэцы Рэагаваць, якая праектуецца і рэалізуецца з улікам даступнасці з самага пачатку.

Другая частка – змена падыходу і працэсаў вакол дызайну першапачаткова мяне палохала: сціплыя інжынеры, якія спрабуюць праштурхнуць арганізацыйныя змены, гэта не заўсёды сканчаюцца добра, але гэта аказалася адной з самых цікавых абласцей, дзе мы ўнеслі значны ўклад у працэс. У двух словах, у нас быў наступны працэс: новы функцыянал распрацоўваўся адной камандай, пасля гэтага наша група кіраўнікоў аналізавала/ітэравала дадзеную прапанову, а затым, пасля зацвярджэння, як правіла дызайн перадаваўся камандзе інжынераў. У гэтым выпадку каманда інжынераў па факце "валодала" функцыянальнасцю даступнасці, паколькі яна павінна ўхіліць усе звязаныя з ёй праблемы.

Спачатку гэта была даволі цяжкая праца - тлумачыць, што даступнасць і зручнасць выкарыстання непарыўна звязаныя паміж сабой і што гэта неабходна зрабіць яшчэ на этапе праектавання, інакш гэта вяло да вялікіх змен і пераазначэння некаторых роляў. Тым не менш, пры падтрымцы кіраўніцтва і ключавых гульцоў, мы данеслі гэтую ідэю і пусцілі яе ў ход, каб дызайны праходзілі праверку на даступнасць і зручнасць выкарыстання, перш чым яны будуць прадстаўлены кіраўніцтву.

І гэтыя водгукі былі надзвычай каштоўныя для ўсіх – гэта было фантастычна, як практыкаванне па абмене ведамі/перадачы інфармацыі аб тым, як карыстальнікі ўзаемадзейнічаюць з вэб-прыкладаннямі, мы вызначалі шматлікія праблемныя вобласці карыстацкага інтэрфейсу да таго, як яны былі пабудаваны, каманды распрацоўшчыкаў у Цяпер маюць значна лепшыя спецыфікацыі не толькі візуальных, але і паводніцкіх аспектаў дызайну. Рэальныя абмеркаванні - гэта вясёлыя, энергічныя, гарачыя дыскусіі аб тэхнічных аспектах і ўзаемадзеяннях.

Мы маглі б зрабіць дадзеную працу яшчэ лепш, калі б на гэтых (ці наступных) сустрэчах з намі былі б сляпыя карыстальнікі і карыстальнікі з абмежаванымі магчымасцямі - гэта было складана арганізаваць, але цяпер мы сапраўды супрацоўнічаем як з мясцовымі арганізацыямі сляпых, так і з кампаніямі. , якія падаюць знешняе тэсціраванне для праверкі патоку выканання на ранніх стадыях распрацоўкі – як на ўзроўні кампанента, так і на ўзроўні патоку выканання.

Цяпер інжынеры маюць даволі падрабязныя спецыфікацыі, даступныя кампаненты, якія яны могуць выкарыстоўваць для ўкаранення, і спосаб праверкі патоку выканання. Часткова, досвед навучыў нас таму, што мы ўвесь час выпускалі – як мы можам спыніць рэгрэсію. Аналагічным чынам людзі могуць выкарыстоўваць інтэграцыйныя або скразныя тэсты для праверкі функцыянальнасці, якія нам патрэбны для выяўлення змен ва ўзаемадзеяннях і патоках выканання - як візуальных, так і паводніцкіх.

Вызначэнне візуальнай рэгрэсіі задача даволі вызначаная, вельмі мала можна дадаць да дадзенага працэсу, акрамя, магчыма, праверкі ці бачны фокус пры навігацыі з дапамогай клавіятуры. Цікавейшыя дзве адносна новыя тэхналогіі для працы з даступнасцю.

  1. Даступнасць Insights - гэта набор інструментаў, якія могуць выконвацца як у браўзэры, так і ў рамках цыклу зборкі/тэставанні, для выяўлення праблем.
  2. Праверка правільнасці працы праграм чытання з экрана была асабліва складанай задачай. З увядзеннем доступу да Accessibility DOM, мы нарэшце атрымалі магчымасць рабіць здымкі прыкладання з пункту гледжання даступнасці, вельмі падобныя на тое, як мы робім іх для візуальных тэстаў, і правяраем іх на рэгрэсію.

Такім чынам, у другой частцы гісторыі - мы перайшлі ад праўкі HTML-кода да працы на больш высокім узроўні абстракцыі, змянілі працэс распрацоўкі дызайну і ўвялі стараннае тэставанне. Новыя працэсы, новыя тэхналогіі і новыя ўзроўні абстракцыі цалкам змянілі ўяўленне аб даступнасці і аб тым, што значыць працаваць у гэтай сферы.
Але гэта толькі пачатак.

Наступнае "разуменне" складаецца ў тым, што сляпыя карыстачы прасоваюць перадавыя тэхналогіі – менавіта яны атрымліваюць найвялікую выгаду не толькі ад змен, апісаных намі раней, але і ў тым, што новыя падыходы і ідэі становяцца магчымымі з дапамогай ML/AI. Напрыклад, тэхналогія Immersive Reader дазваляе карыстальнікам прасцей і больш зразумела прадстаўляць тэкст. Яго можна прачытаць услых, структура сказа падзяляецца граматычна і нават значэнні слоў адлюстроўваюцца графічна. Гэта абсалютна не ўпісваецца ў старое разуменне "зрабіць яго даступным" - гэта функцыя зручнасці выкарыстання, якая дапаможа ўсім.

З ML/AI з'яўляюцца зусім новыя спосабы ўзаемадзеяння і працы, і мы радыя быць часткай наступных этапаў гэтага перадавога шляху. Інавацыі абумоўлены зменай мыслення - чалавецтва ўжо існуе тысячагоддзя, машыны - сотні гадоў, вэб-сайты некалькі дзясяткаў гадоў, а смартфоны і таго менш, тэхналогія павінна адаптавацца пад людзей, а не наадварот.

PS Артыкул перакладзены з невялікімі адступленнямі ад арыгінала. З'яўляючыся суаўтарам дадзенага артыкула я ўзгадніў гэтыя адступленні з Х'ю.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

А вы надаеце ўвагу даступнасці вашых прыкладанняў?

  • Так

  • Няма

  • Упершыню чую аб даступнасці прыкладанняў

Прагаласавалі 17 карыстальнікаў. Устрымаліся 5 карыстальнікаў.

Крыніца: habr.com

Дадаць каментар