Пятніца - канец працоўнага дня. Дрэнныя навіны заўсёды прыходзяць у пятніцу пад канец працоўнага дня.
Вы збіраецеся пакінуць офіс, «дзінь» новы ліст наконт чарговай рэарганізацыі толькі што прыйшоў на пошту.
Дзякуй xxxx, yyy з сённяшняга дня вы будзеце даваць справаздачу zzzz
...
І каманда Х'ю забяспечыць даступнасць нашых прадуктаў для людзей з абмежаванымі магчымасцямі.
О не! Завошта я заслужыў гэта? Яны жадаюць, каб я сышоў? Настроіцца на няўдзячную цяжкую працу і спрабаваць выправіць памылкі іншых людзей. Гэта напэўна правал…
Такой была даступнасць некалькі гадоў таму. Некаторыя небаракі атрымлівалі працу па "ачыстцы" карыстацкага інтэрфейсу, каб паспрабаваць зрабіць яго даступным для людзей з абмежаванымі магчымасцямі.
Тое, што гэта на самой справе азначала, было даволі расплывістае - верагодна, калі б вы маглі бачыць індыкатар фокусу і перамяшчацца па палях з дапамогай табуляцыі, мець нейкі альтэрнатыўны тэкст і парачку апісанняў да палёў, гэта б лічылася, што ваша прыкладанне даступна …
Але раптам «багі» пачалі размнажацца з хуткасцю лавіны.
Розныя экранныя счытвальныя прылады (англійская (Screen Readers) і браўзэры паводзілі сябе абсалютна па-рознаму.
Карыстальнікі скардзіліся, што прыкладанне не прыдатнае для выкарыстання.
Як толькі памылка выпраўлялася ў адным месцы, з'яўлялася іншая ў іншым.
І, проста мяняць і выпраўляць памылкі карыстацкага інтэрфейсу, патрабавала тытанічных намаганняў.
Я там быў. Я выжыў, але мы не атрымалі поспех - тэхнічна мы шмат ачысцілі, дадалі шмат апісанняў да палёў, роляў і дасягнулі нейкага ўзроўню адпаведнасці патрабаванням, але ніхто не быў шчаслівы. Карыстальнікі ўсё роўна скардзіліся, што не могуць арыентавацца ў дадатку. Мэнэджар усё роўна скардзіўся на пастаянны паток памылак. Інжынеры скардзіліся на няправільную пастаноўку задачы, без дакладна вызначанага "правільнага" рашэння, якое працавала б ва ўсіх выпадках.
На маім шляху да разумення даступнасці сустрэліся некаторыя яўна адкрытыя моманты.
Магчыма, першым было разуменне таго, што дадаваць функцыянальнасць даступнасці па-над гатовым прадуктам – гэта складана. І яшчэ складаней пераканаць мэнэджараў, што гэта неверагодна складана! Не, гэта не проста "дадаў некалькі тэгаў" і карыстацкі інтэрфейс будзе працаваць выдатна. Не, гэта немагчыма скончыць за тры тыдні, нават тры месяцы будзе мала.
Мой наступны момант ісціны наступіў, калі я на свае вочы ўбачыў, як сляпыя карыстальнікі на самай справе выкарыстоўваюць наша дадатак. Гэта ТАК адрозніваецца ад прагляду паведамленняў аб памылках.
Я буду вяртацца да гэтага зноў і зноў, але амаль усе нашыя «здагадкі» аб тым, як людзі выкарыстоўвалі наша дадатак, былі памылковымі.
Навігацыя па складаным карыстацкім інтэрфейсе пры дапамозе клавіш Tab/Shift+Tab - Гэта адстой! Трэба што-небудзь лепей. Спалучэнні клавіш, загалоўкі.
Страта фокусу пры змене UI гэта ж не вялікая праблема? Падумаем яшчэ раз - гэта вар'яцка збівае з панталыку.
Я працягваў, некаторы час працаваў над рознымі праектамі, а потым мы пачалі новы праект, са складаным карыстацкім інтэрфейсам і дакладнай устаноўкай, каб нарэшце ў гэты раз атрымаць правільную даступнасць.
Такім чынам, мы зрабілі крок назад і паглядзелі, як мы можам рэалізаваць гэта па-іншаму і атрымаць поспех, і каб сам працэс працы быў нянудным!
Даволі хутка мы прыйшлі да некаторых высноваў:
Мы не жадалі, каб людзі, якія распрацоўваюць карыстацкі інтэрфейс, важдаліся з aria надпісамі/ролямі і, натуральна з HTML структурай кампанентаў. Нам трэба было забяспечыць іх правільнымі кампанентамі, у якіх даступнасць рэалізавана прама са скрынкі.
Даступнасць == Выгода выкарыстання - г.зн. гэта не толькі тэхнічная задача. Нам трэба было змяніць увесь працэс праектавання і пераканацца, што даступнасць бярэцца да ўвагі і абмяркоўваецца да пачатку праектавання карыстацкага інтэрфейсу. Неабходна першапачаткова абдумваць, як карыстачы могуць выявіць якую-небудзь функцыянальнасць, як яны будуць перамяшчацца і як будзе працаваць "правы клік мышы" з клавіятуры. Даступнасць павінна быць неад'емнай часткай працэсу праектавання – для некаторых карыстальнікаў яна з'яўляецца чымсьці значна большым, чым проста вонкавы выгляд прыкладання.
З самага пачатку мы хацелі атрымаць водгукі ад сляпых і іншых карыстальнікаў з абмежаванымі магчымасцямі аб прастаце выкарыстання прыкладання.
Нам былі патрэбны сапраўды добрыя спосабы адлоўліваць рэгрэсію даступнасці.
Ну, з інжынернага пункта гледжання, першая частка гучала даволі весяла - распрацоўка архітэктуры і ўкараненне бібліятэкі кампанентаў. І сапраўды так яно і было.
Робячы крок назад, разглядаючы прыклады ARIA і задумваючыся аб гэтым як аб праблеме дызайну, а не аб праблеме "прыстасоўвацца", мы ўвялі некаторыя абстракцыі. Кампанент мае 'Структуру' (складаецца з HTML-элементаў) і 'Паводзіны' (як ён узаемадзейнічае з карыстачом). Напрыклад, у прыведзеных ніжэй фрагментах мы маем просты неўпарадкаваны спіс. Пры даданні "паводзін" да спісу дадаюцца адпаведныя ролі, каб ён дзейнічаў як спіс. Аналагічна які робіцца для меню.
Насамрэч, тут дадаюцца не толькі ролі, але і апрацоўшчыкі падзей для навігацыі пры дапамозе клавіятуры.
Гэта выглядае ўжо больш ахайна. Калі б мы маглі атрымаць чысты падзел паміж імі, было б усё роўна, як была створана структура, мы маглі б прымяніць да яе паводзін (Behaviours) і атрымаць правільную даступнасць.
Другая частка – змена падыходу і працэсаў вакол дызайну першапачаткова мяне палохала: сціплыя інжынеры, якія спрабуюць праштурхнуць арганізацыйныя змены, гэта не заўсёды сканчаюцца добра, але гэта аказалася адной з самых цікавых абласцей, дзе мы ўнеслі значны ўклад у працэс. У двух словах, у нас быў наступны працэс: новы функцыянал распрацоўваўся адной камандай, пасля гэтага наша група кіраўнікоў аналізавала/ітэравала дадзеную прапанову, а затым, пасля зацвярджэння, як правіла дызайн перадаваўся камандзе інжынераў. У гэтым выпадку каманда інжынераў па факце "валодала" функцыянальнасцю даступнасці, паколькі яна павінна ўхіліць усе звязаныя з ёй праблемы.
Спачатку гэта была даволі цяжкая праца - тлумачыць, што даступнасць і зручнасць выкарыстання непарыўна звязаныя паміж сабой і што гэта неабходна зрабіць яшчэ на этапе праектавання, інакш гэта вяло да вялікіх змен і пераазначэння некаторых роляў. Тым не менш, пры падтрымцы кіраўніцтва і ключавых гульцоў, мы данеслі гэтую ідэю і пусцілі яе ў ход, каб дызайны праходзілі праверку на даступнасць і зручнасць выкарыстання, перш чым яны будуць прадстаўлены кіраўніцтву.
І гэтыя водгукі былі надзвычай каштоўныя для ўсіх – гэта было фантастычна, як практыкаванне па абмене ведамі/перадачы інфармацыі аб тым, як карыстальнікі ўзаемадзейнічаюць з вэб-прыкладаннямі, мы вызначалі шматлікія праблемныя вобласці карыстацкага інтэрфейсу да таго, як яны былі пабудаваны, каманды распрацоўшчыкаў у Цяпер маюць значна лепшыя спецыфікацыі не толькі візуальных, але і паводніцкіх аспектаў дызайну. Рэальныя абмеркаванні - гэта вясёлыя, энергічныя, гарачыя дыскусіі аб тэхнічных аспектах і ўзаемадзеяннях.
Мы маглі б зрабіць дадзеную працу яшчэ лепш, калі б на гэтых (ці наступных) сустрэчах з намі былі б сляпыя карыстальнікі і карыстальнікі з абмежаванымі магчымасцямі - гэта было складана арганізаваць, але цяпер мы сапраўды супрацоўнічаем як з мясцовымі арганізацыямі сляпых, так і з кампаніямі. , якія падаюць знешняе тэсціраванне для праверкі патоку выканання на ранніх стадыях распрацоўкі – як на ўзроўні кампанента, так і на ўзроўні патоку выканання.
Цяпер інжынеры маюць даволі падрабязныя спецыфікацыі, даступныя кампаненты, якія яны могуць выкарыстоўваць для ўкаранення, і спосаб праверкі патоку выканання. Часткова, досвед навучыў нас таму, што мы ўвесь час выпускалі – як мы можам спыніць рэгрэсію. Аналагічным чынам людзі могуць выкарыстоўваць інтэграцыйныя або скразныя тэсты для праверкі функцыянальнасці, якія нам патрэбны для выяўлення змен ва ўзаемадзеяннях і патоках выканання - як візуальных, так і паводніцкіх.
Вызначэнне візуальнай рэгрэсіі задача даволі вызначаная, вельмі мала можна дадаць да дадзенага працэсу, акрамя, магчыма, праверкі ці бачны фокус пры навігацыі з дапамогай клавіятуры. Цікавейшыя дзве адносна новыя тэхналогіі для працы з даступнасцю.
Даступнасць Insights - гэта набор інструментаў, якія могуць выконвацца як у браўзэры, так і ў рамках цыклу зборкі/тэставанні, для выяўлення праблем.
Праверка правільнасці працы праграм чытання з экрана была асабліва складанай задачай. З увядзеннем доступу да Accessibility DOM, мы нарэшце атрымалі магчымасць рабіць здымкі прыкладання з пункту гледжання даступнасці, вельмі падобныя на тое, як мы робім іх для візуальных тэстаў, і правяраем іх на рэгрэсію.
Такім чынам, у другой частцы гісторыі - мы перайшлі ад праўкі HTML-кода да працы на больш высокім узроўні абстракцыі, змянілі працэс распрацоўкі дызайну і ўвялі стараннае тэставанне. Новыя працэсы, новыя тэхналогіі і новыя ўзроўні абстракцыі цалкам змянілі ўяўленне аб даступнасці і аб тым, што значыць працаваць у гэтай сферы.
Але гэта толькі пачатак.
Наступнае "разуменне" складаецца ў тым, што сляпыя карыстачы прасоваюць перадавыя тэхналогіі – менавіта яны атрымліваюць найвялікую выгаду не толькі ад змен, апісаных намі раней, але і ў тым, што новыя падыходы і ідэі становяцца магчымымі з дапамогай ML/AI. Напрыклад, тэхналогія Immersive Reader дазваляе карыстальнікам прасцей і больш зразумела прадстаўляць тэкст. Яго можна прачытаць услых, структура сказа падзяляецца граматычна і нават значэнні слоў адлюстроўваюцца графічна. Гэта абсалютна не ўпісваецца ў старое разуменне "зрабіць яго даступным" - гэта функцыя зручнасці выкарыстання, якая дапаможа ўсім.
З ML/AI з'яўляюцца зусім новыя спосабы ўзаемадзеяння і працы, і мы радыя быць часткай наступных этапаў гэтага перадавога шляху. Інавацыі абумоўлены зменай мыслення - чалавецтва ўжо існуе тысячагоддзя, машыны - сотні гадоў, вэб-сайты некалькі дзясяткаў гадоў, а смартфоны і таго менш, тэхналогія павінна адаптавацца пад людзей, а не наадварот.
PS Артыкул перакладзены з невялікімі адступленнямі ад арыгінала. З'яўляючыся суаўтарам дадзенага артыкула я ўзгадніў гэтыя адступленні з Х'ю.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.
А вы надаеце ўвагу даступнасці вашых прыкладанняў?