Веб-доступність. Що варто знати кожному Front-end розробнику і дизайнерові

Тема веб-доступності постійно привертає мою увагу. Оскільки працюю Front-end розробником, мені завжди було цікаво, як зробити інтерфейс максимально пробачимо і зрозумілим. Пам'ять пам'ятаю, ще студентом додавав event listeners на комбінації клавіш, щоб спростити й пришвидшити навігацію своїми першими веб-сторінками. Тому сфера доступності відгукнулася всередині мене, коли я дізнався, що саме означає це поняття. У цій статті хочу зібрати докупи й коротко описати, що таке доступність, чому та кому вона потрібна, а також поділитися своїм підходом до розробки і тестування доступних інтерфейсів. Матеріал буде корисний як Front-end розробникам, так і дизайнерам, а також усім, хто користується Інтернетом.

Для мене історія з веб-доступністю почалася шість років тому. Через свою неуважність я ледве не потрапив під колеса автобуса всього за 50 метрів від офісу, де на той час працював. Тепер розумію, що ця подія змінила моє життя й ставлення до звичних речей. Діставшись усе-таки до свого робочого місця й нарешті оговтавшись, я задумався про ті, яким би було моє життя, якби я зробив на крок більше або вийшов з дому на секунду раніше. Яким би було моє життя з інвалідністю, якби я вижив узагалі? Як бі я робив звичні речі? Як заробляв би на життя? Невже це був би кінець? Та пам'ятаючи про Стівена Гокінга, який більшу частину свого життя працював паралізованим, я вирішив дослідити, як люди з інвалідністю користуються комп'ютерною ютерами й Інтернетом.

Так я відкрив для себе новий світ асистивних технологій (assistive technologies) і підходів до проектування інтерфейсів, про які й хочу розповісти.

Асистивні технології







Коли я усвідомив, що з електронними пристроями можна ефективно взаємодіяти без екрана чи ведмедика, мій світ перевернувся. Адже я навіть не підозрював про розмаїття програмних засобів і пристроїв для вводу-виводу, окрім стандартних монітора, клавіатури та мишки. Вісь лише деякі з них:

Скрінрідери (screen reader) — найпоширеніша технологія, з якою й асоціюють веб-доступність. Перетворює текст з екрану аудіопотік синтезованої мови або набору звуків різної частоти. Крім того, скрінрідери дають змогу швидко вивести список елементів (заголовки, посилання, кнопки, секції тощо) і переходіті між ними, що значно спрощує життя. Найпопулярніші скрінрідери — VoiceOver (macOS, iOS), NVDA (Windows), Google TalkBack (Android).

Дисплей Брайля — пристрій, що перетворює візуальну інформацію на набір знаків, побудованих із шістьох точок, які можна відрізнити на дотик пальцями рук. Для роботи з ним потрібен спеціальний софт, що виводитиме інформацію на дисплей.

Розпізнавання мовлення й керування голосом . Цим зараз нікого не здивуєш, усі вміють «Ok, Google» і «Hey, Siri». Проте для людей з ушкодженнями опорно-рухового апарату розпізнавання голосу для роботи з пристроями завжди залишатиметься актуальним, зокрема зараз, коли якість розпізнавання надзвичайно висока. Проморолик від Apple показує, наскільки розпізнавання мовлення важливе.

Перемикачі — одна або кілька великих кнопок в одному корпусі, на які користувач може призначити різні дії, як-від скрол або вибір елемента. Його також використовують люди з ушкодженнями опорно-рухового апарату.

Пристрої вдих-видих (sip-and-puff (SNP), inhale—exhale) — пристрій у вигляді трубки, що реагує й передає інформацію у відповідь на вдих і видих. Сила потоку повітря та його напрямок змінює напрямок руху курсору на екрані.

З усіх названих технологій скрінрідери найпоширеніші й найдоступніші. Їх варто спробувати кожному для нового досвіду. Деякий час я використовував скрінрідер усюди: на ресурсах, які відвідував щодня, і на сторінках, які сам створював. І саме на моїх сторінках орієнтуватися було складно. Також я вирішив зібрати статистичні дані для кращого розуміння попиту на веб-доступність.

Доступність — це не тільки про хвороби

Шукаючи статистику в англійськомовних джерелах , я постійно натрапляв на терміни impairment і disability.

Impairment (укр. «ушкодження») — тимчасова або постійна втрата функцій або незвичне функціонування органів і систем організму. Простіше кажучи, це симптоми й ознаки, що щось із нашим організмом пішло не так.

Disability (укр. «інвалідність», «неспроможність») — обмеження або відсутність можливості у людини виконувати звичні дії за звичний для середньостатистичної особи годину. Неспроможність — це наслідок ушкодження.

Як на мене, то з термінологією в українській мові є певні труднощі, адже не завжди disability — це інвалідність, тому в цій статті я використовуватиму слово «неспроможність».

Отож, про статистику:

Доступність зазвичай асоціюють саме зі сліпотою, проте перелік ушкоджень, які потребують нашої уваги як розробників, набагато більший:

Проте доступність — це не лише про труднощі чи біль. Ми всі потребуємо якісніх і зручних інтерфейсів щодня, коли:

Отже, доступність (англ. accessibility, скорочено a11y) — це про комфорт користувачів. Це набір технік і практик, що дають змогу всім користувачам вашого інтерфейсу одержати контент і досягти бажаного результату за оптимальний час.

Чому варто інвестувати в доступність

Веб-доступність потребує знань і часу. І не завжди компанії та замовники готові витрачати кошти на те, що, на їхню думку, не дасть результату. Проте я зібрав кілька причин, які допомагають переконати, що веб-доступність потрібна, у разі важливих переговорів.

Розширення аудиторії. Згідно з попереднім розділом, 15% населення потребують доступних інтерфейсів. Звичайно, не всі 15% активно користуються Інтернетом, проте я впевнений, що багато з них точно захочуть скористатися вашим продуктом і, можливо, засмутяться, якщо форма оплати буде недоступною.

Найкращий UX для всіх. Як ми вже переконалися, доступність — це для всіх. Ваші користувачі напевне зрадіють зрозумілим і чітким інструкціям до форм, навігації з клавіатури та темного режиму для перегляду.

Нормативно-правові акти. Вже близько 40 країн рекомендують або вимагають дотримуватися стандартів доступності. Інколи закони стосуються лише державних порталів або проектів із сотнями тисяч користувачів чи організацій, які мають офлайн-представництва (магазини або офіси). Проте тенденція з року в рік посилюється, і варто не забувати про можливу відповідальність за дискримінацію користувачів. Саме за рішенням суду Netflix почали додавати субтитри до відеоконтенту. Список позовів щодо доступності в США.

Заробітна плата. Знання й досвід ще нікому не зашкодили. У ситуації з веб-доступністю смороду лише зроблять краще. На glassdoor.com на запит Front-end Developer одержуємо 53 231 результат і найвищу зарплатню — 287,8 тис. доларів США. Проте на запит Accessibility — 74 448 вакансій і найбільшу компенсацію — 416,8 тис. доларів США. Звичайно, запит Accessibility — це й про лікарів та архітекторів, проте розуміння принципів веб-доступності й досвід її вмілого використання додає вам балів на співбесіді.

Органічний трафік. Останніми роками пошукові системи, зокрема Google, частіше спираються на дані поведінки користувачів при видачі. Що більше годині користувачі проводять на сторінці й що більше сторінок переглядають, то вище сторінка просувається в результатах. А поведінка користувачів залежить як від контенту, так і від зручності інтерфейсів.

Стандарти й рекомендації щодо веб-доступності

Як визначити, що інтерфейс доступний? І наскільки він доступний? Чи можна зробити його ще доступнішим? Звичайно, кожна людина по-своєму розуміє якість, тому на допомогу приходять стандарти й специфікації.

Для веб-доступності розробили Web Content Accessibility Guidelines (WCAG ) — документ, що описує набір рекомендацій для розробки доступних інтерфейсів. 2012 року версія 2.0 цього документа стала стандартом ISO.

Рекомендації групували за 4 принципами: сприйняття, керованість, зрозумілість і надійність. А також кожна рекомендація має свій рівень — A, AA, AAA, що й визначає доступність інтерфейсу. Що більше A, то краще. A < AA < AAA. Кажуть, що інтерфейс відповідає WCAG 2.1 AA, якщо в ньому реалізували всі рекомендації рівня AA.

Як зробити веб-інтерфейс доступним

Я вважаю, що створення доступних інтерфейсів має бути вибачимо та інтуїтивним, але є ятовувати всі рекомендацій WCAG не варто на перших етапах, тому я виокремив кроки, якими сам користуюся.

Якщо ви читаєте цю статтю, ви вже робите перший крок. Сьогодні індустрія вимагає від кожного розуміння основ доступності. 2012 року зрозумілої та простої інформації про А11у було дуже мало — здебільшого нудні та іноді абстрактні специфікації. Зараз же є безліч статей, блогів, YouTube-каналів і курсів. Мої улюблені — це A11y Casts , де автор у зручному форматі (до 15 хв) розказує про асистивні технології й принципи доступності; та курс Web Accessibility від Udacity ї Google, який дає 80% базового розуміння доступності.

Клавіатура й фокус

Якщо ви працюєте над веб-сайтом або вже маєте такий, спробуйте скористатись інтерфейсом лише за допомогою клавіатури. Відтепер клавіша Tab — ваш найкращий друг. Спробуйте також поекспериментувати й перевірити, як реагують доступні веб-ресурси на натискання Tab. До прикладу, The New York Times — посилання на сторінці стають активними по черзі з кожним натисненням; навколо посилання з'єднання являється контур (outline), нові елементи, як-від посилання Skip to Content, і взагалі можна прогортати всю сторінку, просто натискаючи Табуляції, «стрибаючи» за всіх елементів, здатних приймати фокус. А перейти за активним посиланням можна, натиснувши Enter. Зручно, чи не так?

Інтерфейс nytimes.com реагує на клавішу Tab

Добра новина — браузери самі вміють обробляти натискання на клавіші, а нам, як розробникам, варто просто їм не заважати. Вісь кілька порад про те, як застосувати вміння браузера на користь користувачам:

Focus trap. Автор — andreasbm.Webcomponents

Семантика й контент

Для того щоб відобразити сторінку, браузери парсять HTML, CSS, JS, будують DOM-, CSSOM-дерева, а також дерево Accessibility. A11y-дерево — це спрощене структуроване подання документа, яке використовують асистивні технології:

Accessibility tree built by browser. Зображення з Google Web Fundamentals

Під час побудови цих дерев браузери ігнорують помилки, невідповідності до специфікацій і намагаються вгадати, що все-таки мав на увазі автор. І це добре працює з HTML, проте це не варіант для асистивних технологій.

До прикладу, нехай у нас буде така форма:

<form>
 <p>Fill the form so we can get back to you</p>
 <span>First Name</span>
 <input name='fn' />
 <button type='submit'>Submit</button>
</form>

Якщо поглянути на форму, усе зрозуміло: я можу залишити ім'я, натиснути на кнопку, і зі мною зв'язку яжуться. Проте якщо у користувачів немає можливості побачити форму й вони хочуть її прослухати, то вони почують:

  1. Fill the form, so we can get back to you.
  2. Edit text.
  3. Submit button.

Не дуже інформативно. Ця форма — жах для користувачів асистивних технологій, тому що:

Не варто очікувати, що людина, яка користується скрінрідером, запам'ятати цю форму. І це хороший приклад, чому специфікації, стандарти й валідність важливі. Невалідна розмітка — причина некоректної відтворювання контенту асистивними технологіями. Натомість HTML, написаний відповідно до стандартів, гарантує вам базовий рівень доступності з коробки.

Вісь приклад, як зробити цю форму доступнішою, надаючи більше інформації скрінрідерам:

<form>
<fieldset>
 <legend>Fill the form so we can get back to you</legend>
 <label for="firstname">
 <input id="firstname" name="firstname" placeholder="First Name" />
</label>
 <button type='submit'>Submit</button>
</fieldset>
</form>

Також семантика стосується інших HTML-елементів.

Альтернативний текст зображень. Атрибут alt існує не просто так. Якщо зображення не завантажилося або користувач не може його побачити, то альтернативний текст — це єдиний спосіб передати зміст. Написання цього тексту — ціле мистецтво, таке саме, як і назви класів та змінних. Якщо ілюстративне зображення, опишіть його; якщо це комікс — опишіть діалог. Проте якщо це іконка або прев'ю в каруселі, то, може, варто взагалі його приховати? Вісь усі можливі комбінації зображення та alt тексту:

Скріншоти зWikipedia . Зліва направо: зображення завантажилося; зображення не завантажилося, альо є alt текст (Casey Stengel 1953.png); зображення не завантажилося і alt=«"; зображення без альтернативного тексту не завантажилося.

Правильне використання заголовків. Коли люди читають книги або документи, смороду годину від годині переглядають зміст — набір заголовків і підзаголовків з відповідною нумерацією сторінок. Заголовки в HTML витворили з такою самою метою — для структурування документа й спрощення навігації. Користувачі асистивних технологій використовують заголовки для швидкої навігації. Я часто зустрічаю заголовки, які насправді — просто текст із font-size 30, або навпаки, усі заголовки — це H2. Пропоную користуватися пробачимо правилом: теги H — для структури, CSS — для краси. І пам " ятати, навіщо заголовки користувачам скрінрідерів:

VoiceOver: Список заголовків для швидкої навігації

Посилання кнопки. Увесь веб живе завдяки посиланням. Без них це був би просто набір поодиноких сторінок, які відвідували б лише автори та їхні мами. Проте, як і з заголовками, є кілька правил для ефективного використання посилань. Якщо користувач знає, що він шукає саме посилання (до прикладу, це вікіпедія та статті про мандарин і апельсин точно мають посилання одна на одну), то він викличе окремий список посилань за допомогою скрінрідера. Тому, по-перше, посилання має містити зрозумілий текст, якщо його винести з контексту (до прикладу, «Читати більше» нічого не пояснює, а від «Читати більше про доступність» — відразу зрозуміло). І по-друге, посилання — це не кнопка. Посилання переносити нас зі сторінки на сторінку, а кнопка надсилає дані або змінює стан SPA-застосунку. І користувач скрінрідера точно не очікує href="#" чи href="javascript:void(0);" у списку посилань.

Список посилань у VoiceOver

HTML-орієнтири (landmark). Усе можна зверстати div-ами. Проте у W3C не гають часу й намагаються всім спростити життя. HTML5 Віхах — це не просто хіпстерські трюки, а спосіб полегшити життя користувачам асистивних технологій, пошукових систем і девелоперів. Як ви вже могли здогадатись, VoiceOver також виводить список усіх цих <nav>, <вулиця>, <footer>, <article>. Якщо користувач хоче перейти відразу до футера — три дії (виклик VoiceOver Rotor, вибір списком посилань, вибір конкретного посилання), і він вже там. Це стосується й інших тегів. Скрінрідер дає контекст і додаткову інформацію під час зчитування. До прикладу, зачитує <ul> і <ol> та каже, скільки всього елементів у списку, який номер елемента тощо.

ARIA

Технології не стояти на місці, і у нас вже є десятки HTML-тегів, проте багато звичних нам UI-патернів, таких як модальне вікно, дерево чи тултип, доводитися самим реалізовувати. І весь набір елементів, з яких ми будуємо ці патерни, потрібно представити користувачеві асистивних технологій. Саме для цього витворили WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications), набір атрибутів, що дають змогу авторові розмітки змінювати accessibility tree, щоб асистивні технології інакше відображали контент. Це ініціатива, призначений оживити веб для користувачів асистивних технологій — дати їм можливість не просто читати сторінки, а й користуватися веб-застосунками.

Основний атрибут у ARIA — role. За допомогою нього можна змінити тип елемента для асистивних технологій. До прикладу, якщо ви використовуєте іконковий шрифт і певний символ важливий у вашому контексті, то варто озвучити значення цього символу.

<span aria-role="img"
 aria-label="Asterisk icon"
 class="glyphicon glyphicon-asterisk">
</span>

Є велика кількість ролей, які можна переглянути тут .

Кожна роль може мати стани й властивості (states and properties), що описують стан елемента з тією чи іншою роллю. До прикладу, button може мати атрибут pressed="true".

Здається, що ARIA — це якась складна специфікація, і потрібно багато часу на її освоєння, але я користуюся пробачимо алгоритмом:

<nav role="navigation">...</nav>
<main role="main">...</main>

Стилі

CSS — є ємна частина доступності. Стилі — це не лише про дизайн і яскраві кольори. Якісне візуальне оформлення й зручність для користувачів дає свій результат, і вони частіше повертаються до зручних інтерфейсів.

Responsive styles. Нікого не здивувати responsive-стилями. Проте не варто забувати, що смороду стають у пригоді не лише для користувачів смартфонів, але й для користувачів з поганим зором. Набагато зручніше переглядати сторінку в одну колонку на 30-дюймовому моніторі, ніж «бігати» нею, використовуючи, окрім вертикального, ще й горизонтальний скрол. Не блокуйте зум і використовуйте більший font-size у media queries.

<!-- не робіть -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">
<!-- "minimum-scale=1.0, maximum-scale=1.0, user-scalable=no" is a major anti-pattern-->

<!-- краще зробіть -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

Outline. Як я вже згадував на початку, не всім подобається outline. Проте добра новина — його можна замінити. Тім самим зробите щасливими і дизайнерів, і користувачів:

/* кастомні стилі для outline */
a:focus {
 outline-width: 1px;
 outline-style: dashed;
 outline color: red;
}

/* або можна додати стилі для елементу у фокусі */
.my-button:focus {
 background-color: red;
 Text-decoration: underline;
}

Контраст. Згідно з WCAG 2.0 , текст і зображення зобов'язаннями зобов'язані мати контраст щонайменше 4.5:1 (детальніше про формулу можна прочитати тут ). На око визначити це складно, проте інструменти, про які докладніше йтиметься в наступному розділі, роблять це за вас. Також зверни досить контрастний колір можна в DevTools:

Вибір контрастних комбінацій у DevTools. Color-picker показує відповідність стандартам і додає лінії на палітру, що відділяють контрастні значення від менш контрастних

Не покладайтеся на колір. Коли я створював свої перші форми, питання валідації мене дуже турбувало — input { border-color: red; } — і готово. Проте деякий час я працював з колегою, у якого колірна сліпота. І коли він попросивши допомогти йому з кольором, я зрозумів, якої припускався помилки. Відтоді я став завжди додавати повідомлення з текстом помилки до моїх форм. Вісь добрий приклад валідації, який працює і для людей з ахроматопсією (людей, які не бачать кольорів):

Приклад дизайну для людей з колірною сліпотою. Спробуйте самі за допомогою плагіна NoCoffee

Як тестувати доступність

Звичайно, пам " ятати про всі нюанси доступності непросто. Проте розуміння основ і причин за цими принципами все спрощує. Із годиною ви просто починаєте створювати валідний HTML і додавати ARIA-атрибути. І пересвідчитись, що всі нікого правильно, допомагають вбудовані в браузери утиліти, зокрема Google Lighthouse і Firefox Accessibility Features.

Google Lighthouse — це open-source-проект для аудиту швидкодії, SEO, PWA та Web Accessibility. Його можна використовувати вбудованим у DevTools як сервіс і як CI tool. Для запуску потрібно відкрити DevTools, перейти на вкладку Audits і вибрати потрібний аудит. У нашій ситуації це Accessibility. За кілька секунд дістаємо результат — загальну оцінку в балах від 0 до 100 й рекомендації щодо поліпшень. Кожна рекомендація має конкретний селектор та інструкцію, що потрібно змінити. Крім того, Google Lighthouse — це й інструмент для навчання, оскільки кожна рекомендація має посилання на матеріали Deque University або Google Developers , що обґрунтовують потребу змін.

Результати Google Lighthouse Accessibility Audit для DOU.ua

Accessibility Audits у Google Lighthouse побудовані з використанням Axe — тулкіту для тестування доступності веб - та Android-проектів, який має зручний API та який можна вбудувати в CI pipeline.

Таким чином робота над доступністю перетворюється на гру з балами й ачівками — дуже складно зупинитися, коли досягаєш 93/100. Проте варто пам " ятати, що всі ці інструменти — лише купка if, які не намагаються зрозуміти ваш контент. Тому все-таки рекомендую користуватися вашими проектами й тестувати їх власноруч — заповнювати форми, слухати за допомогою скрінрідерів. Також, якщо дозволяє бюджет, можна скооперуватися з професійними групами людей з інвалідністю, які тестують і надають рекомендації не просто щодо відповідності стандартам, але й про зручність користування. До прикладу Inclusive IT (це не реклама — я жодного стосунку до проекту не маю, проте ця ідея соціального підприємництва мені справді подобається).

Веб-доступність в Україні

Переважно мій досвід упровадження доступності стосується закордонних проектів. Проте протягом останнього року я мав можливість працювати над проектом українською, що спонукало мене дізнатися більше про стан доступності в укрнеті.

На жаль, у нас не все так просто. Незважаючи на те, що 6,2% населення має інвалідність (2 635 600 осіб), 224 000 робочих днів на рік люди непрацездатні через виробничі травми, кількість побутових травм не визначена (не думаю, що вона нижча, ніж в інших країнах), а в країні триває війна й ми щодня дізнаємося про нові травми. Україна — порівняно малий ринок, і компаніям нецікаво вкладати в українську. Зокрема ні VoiceOver, ні Windows не мають підтримки українською. Здебільшого скрінрідери солов'я їною стають доступними завдяки ентузіастам ї open source, зокрема до NVDA розробили синтезатор українською . Радує те, що є якісний синтез української на Android (Google TalkBack).

Вісь короткі записи, як скрінрідери читають українську:

Веб-доступність критична для українців з вадами зору, оскільки дисплеї Брайля дорогі навіть у США, а для середньостатистичного українця сума $3500 — дуже велика.

Висновки

Веб-доступність — широка тема, яка однозначно потребує більше, ніж декількох сторінок. Проте в цій статті я намагався «заразити» читачів моїм захопленням асистивними технологіями й даті віру в ті, що життя може бути якісним навіть з травмами чи захворюваннями. Для цього нам, як розробникам, варто пам " ятати, для кого ми створюємо продукти.

Також вже два роки я презентую цю тему на LvivCSS та Uzhhorod Developer Meetup і не приховую свого задоволення від того, що рік у рік слухачі розвиваються в темі доступності, доповнюють мій контент і діляться досвідом. Дедалі більше верстальників не просто роблять кольорові сторінки, а й перевіряють їх на доступність.

Окрім власного залучення в тему доступності, варто не забувати нагадувати про це дизайнерам і бізнесу. Адже, крім зручнішого вебу для людей з інвалідністю, ми також створимо комфортні інтерфейси для себе й підвищимо свою цінність на ринку.

Корисні матеріали

Опубліковано: 12/12/19 @ 11:51
Розділ web дизайн Блоги

Рекомендуємо:

Шифрування в базах даних SQL з можливістю пошуку
ІТ-волонтери: як викладач створив додаток про втрачену архітектурній спадщині Харкова
QA дайджест #40: лайфхаки автоматизації, добірка книг для тестувальників
9 способів чистити пошукові запити в Key Collector
Безпека в інтернеті, або TrustedTypes як новий спосіб захисту від XSS