Петък – краят на работния ден. Лошите новини винаги идват в петък, в края на работния ден.
Вие се каните да напуснете офиса, когато получавате ново писмо за поредната реорганизация.
Благодаря xxxx, yyy от днешния ден ще отчитате пред zzzz
…
И екипът на Хю ще осигури достъпността на нашите продукти за хора с увреждания.
О, не! За какво съм заслужил това? Искат ли да си тръгна? Да се настроя за неблагодарна и трудна работа, опитвайки се да поправя грешките на другите. Това със сигурност ще бъде провал...
Такава беше достъпността преди няколко години. Някои бедняци получаваха работа по "почистването" на потребителския интерфейс, опитвайки се да го направят достъпен за хора с увреждания.
Това, което всъщност означаваше, беше доста размито – вероятно, ако можете да виждате индикатора на фокуса и да се движите между полетата с помощта на табулация, да имате някакъв алтернативен текст и две-три описания на полетата, това щеше да се счита, че вашето приложение е достъпно...
Но внезапно "бугите" започнаха да се задълбочават с бързината на лавина.
Различни четци на екрана (англ. Screen Readers) и браузъри реагираха абсолютно различно.
Потребителите се оплакваха, че приложението не е удобно за ползване.
След като една грешка беше поправена на едно място, се появяваше друга на друго.
И просто да сменя и поправя грешките в потребителския интерфейс изискваше титанични усилия.
Бях там. Оцелях, но не "успяхме" – технически почистихме много, добавихме много описания на полетата, роли и достигнахме известен нивo на съответствие с изискванията, но никой не беше щастлив. Потребителите все пак се оплакваха, че не могат да се ориентират в приложението. Мениджърът все пак се оплакваше от постоянния поток от грешки. Инженерите се оплакваха от неправилно формулираните задачи, без ясно определено "правилно" решение, което да работи при всички случаи.
По пътя си към разбирането на достъпността срещнах някои явно откровени моменти.
Вероятно, първото беше осъзнанието, че добавянето на функцията за достъпност върху готов продукт е трудно. И още по-трудно е да убедиш мениджърите колко невероятно сложно е това! Не, не е просто "добави няколко тагове" и потребителският интерфейс ще работи отлично. Не, не е възможно да се завърши за три седмици, дори и трите месеца ще са малко.
Следващият ми момент на истина настъпи, когато наистина видях как слепите потребители използват нашето приложение. Това е ТАКА различно от преглеждането на съобщения за грешки.
Ще се върна към това отново и отново, но почти всички наши "предположения" за начина, по който хората използват нашето приложение, бяха погрешни.
Навигация през сложен потребителски интерфейс с помощта на клавиши Tab/Shift+Tab – е ужасно! Нуждаем се от нещо по-добро. Комбинации от клавиши, заглавия.
Загубата на фокус при смяна на UI, нали не е голям проблем? Нека помислим отново – това е ужасно объркващо.
Продължавах и работих известно време по различни проекти, а след това започнахме нов проект, със сложен потребителски интерфейс и ясна цел да постигнем правилната достъпност този път.
Така че направихме крачка назад и погледнахме как можем да реализираме това по различен начин и да успеем, и за да е самият работен процес интересен!
Доста бързо стигнахме до някои изводи:
- Не искахме хората, които разработват потребителски интерфейс, да се занимават с aria надписи/роля и, разбира се, с HTML структурата на компонентите. Трябваше да им осигурим правилни компоненти, в които достъпността е реализирана от самото начало.
- Достъпност == Удобство за използване – т.е. това не е само техническа задача. Трябваше да променим целия процес на проектиране и да се уверим, че достъпността се взема предвид и обсъжда преди да започне проектирането на потребителския интерфейс. Необходимо е да се обмисли как потребителите могат да открият всяка функционалност, как ще се движат и как ще работи "десният клик" с клавиатурата. Достъпността трябва да бъде неразделна част от процеса на проектиране – за някои потребители това е нещо много повече от просто визията на приложението.
- От самото начало искахме да получим отзиви от слепи и други потребители с ограничени възможности относно леснотата на използване на приложението.
- Наистина се нуждаехме от добри начини за улавяне на регресията на достъпността.
И така, от инженерна гледна точка, първата част звучеше доста забавно – разработване на архитектура и внедряване на библиотека от компоненти. И наистина беше така.
Ако погледнем назад, разглеждайки и като мислим за това като проблем на дизайна, а не просто за проблем "да се адаптираме", въведохме някои абстракции. Компонентът има 'Структура' (състои се от HTML елементи) и 'Поведение' (как взаимодейства с потребителя). Например, в предоставените по-долу фрагменти имаме прост неупорядочен списък. При добавяне на "поведение" на списъка се добавят съответните роли, за да действа като списък. Правим същото и за менюта.
Всъщност, тук се добавят не само роли, но и обработчици на събития за навигация с клавиатура.
Това изглежда вече по-организирано. Ако можехме да постигнем чисто разделение между тях, нямаше значение как е създадена структурата, щяхме да можем да прилагаме поведения (Behaviours) и да получим правилна достъпност.
В действие това може да се види на адрес – библиотеката UX , която се проектира и реализира с оглед на достъпността от самото начало.
Втората част – промяната на подхода и процесите около дизайна първоначално ме плаши: скромни инженери, които се опитват да прокарат организационни промени, не винаги завършват добре, но се оказа, че това е една от най-интригуващите области, в които направихме значителен принос в процеса. С една дума, нашият процес изглеждаше така: новата функционалност се разработваше от един екип, след това нашата група ръководители анализираше/итерираше предложението, а след одобрението, обикновено, дизайнът се предаваше на екипа инженери. В този случай екипът инженери по същество "притежаваше" функционалността на достъпността, тъй като трябваше да разреши всички свързани с нея проблеми.
В началото това беше доста трудна работа – да обясня, че достъпността и удобството на използване са неразривно свързани помежду си и че е необходимо да се направи това още на етапа на проектиране, в противен случай това водеше до значителни промени и преосмисляне на някои роли. Въпреки това, с подкрепата на ръководството и ключовите играчи, успяхме да предадем тази идея и да я приложим, за да могат дизайните да преминат проверка за достъпност и удобство на използване, преди да бъдат представени на ръководството.
И тези отзиви бяха изключително ценни за всички – беше фантастично, като упражнение по обмен на знания/передаване на информация за начина, по който потребителите взаимодействат с уеб приложенията, определяхме многобройни проблемни области в потребителския интерфейс, преди да бъдат изградени, а екипите на разработчиците в момента имат много по-добри спецификации не само на визуални, но и на поведенчески аспекти на дизайна. Истинските дискусии – това са весели, енергични, страстни дебати за техническите аспекти и взаимодействията.
Можехме да направим тази работа още по-добра, ако на тези (или следващите) срещи с нас биха били слепи потребители и потребители с ограничени възможности – това беше трудно за организиране, но в момента наистина си сътрудничим както с местни организации на слепи, така и с компании, които предоставят външно тестване за проверка на потока на изпълнение в ранните етапи на разработка – както на ниво компонент, така и на ниво поток на изпълнение.
Сега инженерите разполагат с доста подробни спецификации, достъпни компоненти, които могат да използват за внедряване, и начин за проверка на потока на изпълнение. Частично, опитът ни научи, че постоянно пропускаме – как можем да спрем регресията. По подобен начин хората могат да използват интеграционни или крайни тестове за проверка на функционалността, от която имаме нужда, за да открием изменения в взаимодействията и потоците на изпълнение – както визуални, така и поведенчески.
Определението за визуална регресия е доста специфична задача, за която може да се добави малко, освен евентуално да се провери дали фокусът е видим при навигация с клавиатура. По-интересни са две относително нови технологии за работа с достъпността.
- е набор от инструменти, които могат да се изпълняват както в браузъра, така и в рамките на цикъла на събиране/тестване, за откриване на проблеми.
- Контролът на правилната работа на програмите за четене на екрана беше особено сложна задача. С въвеждането на достъпа до Accessibility DOM, най-накрая получихме възможност да правим снимки на приложението от гледна точка на достъпност, много подобни на начините, по които ги правим за визуални тестове и да проверяваме за регресия.
Така след втория етап в историята – преминахме от редактиране на HTML код към работа на по-високо ниво на абстракция, променихме процеса на разработка на дизайна и въведохме стриктно тестване. Новите процеси, новите технологии и новите нива на абстракция напълно промениха представата за достъпност и за това какво означава да работиш в тази сфера.
Но това е само началото.
Следващото "разбиране" е, че слепите потребители насърчават иновационни технологии – именно те получават най-голяма полза не само от промените, които описахме по-рано, но и от новите подходи и идеи, които стават възможни чрез ML/AI. Например, технологията Immersive Reader позволява на потребителите да представят текста по-лесно и по-разбираемо. Може да бъде прочетен на глас, структурата на изречението да се разделя граматически и дори значението на думите да се показва графично. Това абсолютно не попада в старото разбиране за "направи го достъпен" – това е функция на удобството, която помага на всички.
С ML/AI се появяват напълно нови начини за взаимодействие и работа, и ние сме радостни, че сме част от следващите етапи на този напреднал път. Иновациите са свързани с промяната във възприятието – човечеството съществува от хиляди години, машините – стотици, уебсайтовете от няколко десетилетия, а смартфоните още по-малко, технологията трябва да се адаптира към хората, а не обратното.
P.S. Статията е преведена с малки отклонения от оригинала. Като съавтор на тази статия, аз се съгласих с тези отклонения с Хю.
Само регистрирани потребители могат да участват в анкетата. , моля.
Обърнете ли внимание на достъпността на вашите приложения?
Да
Не
За пръв път чувам за достъпността на приложенията.
Гласували са 17 потребители. Въздържали са се 5 потребители.
Източник: habr.com
