Към достъпността

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

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

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

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

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

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

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

Различни екранни четци (Инж. Екранни четци) и браузърите се държаха напълно различно.

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

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

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

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

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

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

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

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

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

И така, направихме крачка назад и разгледахме как можем да приложим това по различен начин и да успеем, и да направим процеса по-малко скучен!

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

1. Не искахме хората, разработващи потребителския интерфейс, да се забъркват с арийни етикети/роли и, разбира се, HTML структурата на компонентите. Трябваше да им предоставим точните компоненти, които изградиха достъпност още от кутията.
2. Достъпност == Лесна употреба – т.е. Това не е просто техническо предизвикателство. Трябваше да променим целия процес на проектиране и да гарантираме, че достъпността е взета предвид и обсъдена преди да започне дизайнът на потребителския интерфейс. Трябва да помислите отрано как потребителите ще открият всяка функционалност, как ще навигират и как ще работи щракването с десен бутон от клавиатурата. Достъпността трябва да бъде неразделна част от процеса на проектиране - за някои потребители това е много повече от външния вид на приложението.
3. От самото начало искахме да получим обратна връзка от незрящи потребители и потребители с други увреждания относно лекотата на използване на приложението.
4. Имахме нужда от наистина добри начини за улавяне на регресиите на достъпността.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обръщате ли внимание на достъпността на вашите приложения?

• Да

• Не

• За първи път чувам за достъпност на приложението.

17 потребители гласуваха. 5 потребители се въздържаха.

Източник: www.habr.com