🥇 В посока достъпност

Петък – краят на работния ден. Лошите новини винаги идват в петък, към края на работния ден.

Настоявате да напуснете офиса, и „дзинь“ ново писмо за поредната реорганизация току-що е пристигнало в пощата.

Благодаря ви xxxx, yyy от днес ще докладвате на zzzz.
…
И екипът на Хю ще осигури достъпността на нашите продукти за хора с увреждания.

О, не! За какво съм заслужил това? Искат ли да напусна? Да се подготвя за неблагодарна, трудна работа и да опитам да поправя грешките на други хора. Това със сигурност е провал...

Такова беше достъпността преди няколко години. Някои нещастници получаваха работа по „почистването“ на потребителския интерфейс, за да опитат да го направят достъпен за хора с увреждания.

Всъщност, това, което означаваше, беше доста размито – вероятно, ако можехте да видите индикатора за фокус и да преминавате през полетата с помощта на клавиша Tab, да имате някакъв алтернативен текст и няколко описания за полетата, това щеше да се счита за достъпно приложение...

Но внезапно „баговете“ започнаха да се множат с бързината на лавина.

Различните скрийн ридъри (англ. Screen Readers) и браузъри се държаха абсолютно различно.

Потребителите се оплакваха, че приложението не е удобно за използване.

Веднага щом грешката беше поправена на едно място, друга се появяваше на друго.

И просто да променяш и поправяш грешките на потребителския интерфейс изискваше титанични усилия.

Бях там. Оцелях, но не „успяхме“ – технически, много почистихме, добавихме много описания за полетата, роля и постигнахме някакво ниво на съответствие с изискванията, но никой не беше щастлив. Потребителите все още се оплакваха, че не могат да се ориентират в приложението. Мениджърът все пак се оплакваше от постоянния поток от грешки. Инженерите се оплакваха от неправилното формулиране на задачата, без ясно определено „правилно“ решение, което да работи във всички случаи.

По пътя ми към разбирането на достъпността се срещнах с някои явно откровени моменти.
Възможно е първото осъзнаване да беше, че добавянето на функции за достъпност към готов продукт е сложно. И още по-трудно е да убедиш управителите, че това е невероятно сложно! Не, не става просто като "добавя няколко тагове" и потребителският интерфейс ще работи отлично. Не, не е възможно да се завърши за три седмици, дори и три месеца ще са недостатъчни.
Моят следващ момент на истина настъпи, когато наистина видях как слепите потребители използват нашето приложение. Това е ТОЛКОВА различно от разглядането на съобщения за грешки.

Ще се връщам към това отново и отново, но почти всичките ни "предположения" за начина, по който хората използват нашето приложение, бяха грешни.

Навигацията в сложен потребителски интерфейс с клавиши Tab/Shift+Tab е ужасна! Нуждаем се от нещо по-добро. Комбинации от клавиши, заглавия.

Загубата на фокус при промяна на UI не е ли голям проблем? Нека помислим отново – това е възмутително объркващо.

Продължавах, работих по различни проекти, а след това започнахме нов проект, със сложен потребителски интерфейс и ясна цел, за да постигнем правилната достъпност този път.

Така че направихме крачка назад и разгледахме как можем да реализираме това по различен начин и да успеем, така че самият процес на работа да не бъде скучен!

Доста бързо стигнахме до някои заключения:

Не искахме разработчиците на потребителския интерфейс да манипулират aria надписи/ролите и, разбира се, HTML структурата на компонентите. Трябваше да им осигурим правилните компоненти, при които достъпността е внедрена направо от кутията.
Достъпността == Удобство за ползване – т.е. това не е само техническа задача. Трябваше да променим целия процес на проектиране и да се уверим, че достъпността се взема предвид и обсъжда преди началото на проектирането на потребителския интерфейс. Необходимо е първоначално да обмислим как потребителите могат да открият някоя функция, как ще навигират и как ще работи "дясното кликване" на мишката от клавиатурата. Достъпността трябва да бъде неразривна част от процеса на проектиране – за някои потребители тя е нещо много повече от просто външния вид на приложението.
От самото начало искахме да получим отзиви от слепи и други потребители с ограничения в достъпа относно леснотата на използването на приложението.
Нуждахме се от наистина добри начини да улавяме регресия на достъпността.

Е, от инженерна гледна точка, първата част звучеше доста забавно – разработка на архитектура и внедряване на библиотеката от компоненти. И наистина така беше.

Като направим крачка назад, разглеждайки примерите ARIA , и обмисляйки това като проблем на дизайна, а не като на проблем за "приспосабяне", въведохме някои абстракции. Компонентът има 'Структура' (състои се от HTML елементи) и 'Поведение' (как взаимодейства с потребителя). Например, в представените по-долу фрагменти имаме прост неупорядочен списък. При добавяне на 'поведение' към списъка се добавят съответните роли, за да действа като списък. По същия начин постъпваме и с менюто.

Всъщност тук се добавят не само роли, но и обработчици на събития за навигация с клавиатура.

Това вече изглежда по-организирано. Ако можехме да постигнем чисто разделение между тях, нямаше да има значение как е създадена структурата, можехме да приложим поведения (Behaviours) към нея и да получим правилна достъпност.

В действителност това може да се види на адрес https://stardust-ui.github.io/react/ – UX библиотеката React, която е проектирана и внедрена с внимание към достъпността от самото начало.

Втората част – промяна на подхода и процесите около дизайна, първоначално ме плаши: скромни инженери, опитващи се да прокарат организационни промени, не винаги приключват добре, но това се оказа едно от най-интересните области, в които направихме значителен принос. С две думи, имахме следния процес: новата функционалност се разработваше от един екип, след което нашата група ръководители анализираше/итерираше предложението, а след одобрение, обикновено дизайнът се предаваше на инженерния екип. В този случай инженерният екип фактически „владеше“ функционалността на достъпността, тъй като той трябваше да реши всички свързани с нея проблеми.

Първоначално това беше доста трудна задача – да обясня, че достъпността и удобството на използване са неразривно свързани и че това трябва да се направи още на етапа на проектиране, в противен случай води до значителни промени и преопределения на някои роли. Въпреки това, с подкрепата на ръководството и ключовите играчи, успяхме да предадем тази идея и да я внедрим, така че дизайните да преминават проверка за достъпност и удобство на използване, преди да бъдат представени на ръководството.

Тези отзиви бяха изключително ценни за всички – беше фантастично, като упражнение за обмен на знания/предаване на информация относно това как потребителите взаимодействат с уеб приложенията, ние идентифицирахме многобройни проблемни области в потребителския интерфейс преди да бъдат изградени, а екипите за разработка в момента имат много по-добри спецификации не само за визуалните, но и за поведенческите аспекти на дизайна. Истинските дискусии – това са забавни, енергични и страстни разговори относно техническите аспекти и взаимодействията.

Можехме да направим тази работа още по-добра, ако на тези (или последващите) срещи с нас присъстваха слепи потребители и потребители с увреждания – това беше трудно за организиране, но в момента действително сътрудничим както с местни организации за слепи, така и с компании, които предоставят външно тестване за проверка на потока на изпълнение на ранните етапи на разработката – както на ниво компоненти, така и на ниво поток на изпълнение.

Сега инженерите разполагат с доста подробни спецификации, налични компоненти, които могат да използват за внедряване, и начин за проверка на потока на изпълнение. Отчасти опитът ни научи на това, което постоянно пропускахме – как можем да предотвратим регресия. По подобен начин хората могат да използват интеграционни или крайни тестове за проверка на функционалността, която ни е необходима за откритие на промени в взаимодействията и потоците на изпълнение – както визуални, така и поведенчески.

Определението на визуалната регресия е доста специфична задача; трудно е да се добави нещо към този процес, освен, може би, проверка дали фокусът е видим при навигация с клавиатура. По-интересни са две относително нови технологии за работа с достъпността.

Accessibility Insights е набор от инструменти, които могат да се изпълняват както в браузъра, така и в рамките на цикъла на изграждане/тестиране, за откриване на проблеми.
Проверяването на правилната работа на читалките за екрана е било особено сложно. С въвеждането на достъпа до Accessibility DOM, най-накрая получихме възможността да правим снимки на приложението от гледна точка на достъпността, много подобни на тези, които правим за визуални тестове, и да ги проверяваме за регресия.

Така, във втората част на историята – преминахме от редактиране на HTML код към работа на по-високо ниво на абстракция, променихме процеса на разработка на дизайна и въведохме внимателно тестване. Новите процеси, новите технологии и новите нива на абстракция напълно промениха разбирането за достъпността и какво означава работа в тази сфера.
Но това е само началото.

Следващото „разбиране“ е, че слепите потребители напредват в технологиите – именно те извлекат най-голяма полза не само от промените, които описахме по-рано, но също така и от новите подходи и идеи, които стават възможни благодарение на ML/AI. Например, технологията Immersive Reader позволява на потребителите по-лесно и по-разбираемо да представят текста. Може да се чете на глас, структурата на изречението се разделя граматически и дори значенията на думите се показват графично. Това абсолютно не се вписва в старото разбиране за „направете го достъпен“ – това е функция за удобство, която ще помогне на всички.

С ML/AI се откриват напълно нови начини за взаимодействие и работа, и ние сме радостни да бъдем част от следващите етапи на този авангарден път. Иновациите произтичат от промяна в мисленето – човечеството съществува от хиляди години, машините – стотици години, уеб сайтовете – няколко десетилетия, а смартфоните – още по-малко; технологията трябва да се адаптира към хората, а не обратното.

P.S. Статията е преведена с малки отклонения от оригинала. Като съавтор на тази статия, аз съгласих тези отклонения с Хю.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.