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