Дек. 13

Веб-доступність. Що варто знати кожному 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 — це інвалідність, тому в цій статті я використовуватиму слово «неспроможність».

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

2,2 мільярда населення мають труднощі, пов’язані з зором;
15% населення живуть з різними видами неспроможностей або інвалідності;
Зокрема, у США 12,6% населення потерпають через неспроможність або інвалідність.

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

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

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

читаємо новини або відповідаємо на повідомлення, тримаючи в одній руці чашку із чаєм / пакет з продуктами / дитину / кота;
ховаємося влітку в затінку, щоб прочитати інформацію з екрана смартфона, бо інакше нічого не видно;
серфимо вебом з дивана на Smart TV;
увечері востаннє перед сном перевіряємо стрічку соцмереж, і яскраво-біле світло сліпить нас у темряві спальні.

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

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

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

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

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

Не ховайте outline. Outline — це сірий (або синій у Chrome) контур, який з’являється в разі натискання на елементи форм або навігації з клавіатури. І саме його так часто не люблять дизайнери. Проте саме outline — рятівне коло під час використання клавіатури, адже він відіграє роль курсора. Є навіть цілий ресурс про те, чому погано робити — a { outline: none; }.
Зберігайте порядок HTML-тегів відповідно до візуального подання сторінки. Браузери та скрінрідери не враховують змін порядку елементів за допомогою CSS (order: n; у flexbox або float) під час побудови accessibility tree, зчитуванні контенту й навігації з клавіатури.
Якщо все-таки треба змінити розташування елементів, використайте tabindex — HTML-атрибут, що вказує на порядок елементів під час навігації з клавіатури, додає чи забирає елемент з усього списку інтерактивних елементів на сторінці.
Додайте посилання Skip Navigation (див. приклад NYTimes.com), щоб користувачам не довелося проклацувати через усю навігацію, щоб дістатися до контенту.
Використовуйте focus traps у разі потреби, якщо, наприклад, у вас на сторінці є модальне вікно. Користувач може «рухатись» лише між елементами цього вікна, проте в нього обов’язково має бути можливість закрити це вікно за допомогою клавіатури.

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

Уникайте випадкових і шкідливих focus traps — ситуацій, у яких користувач «застрягає» між декількома елементами й не може повернутися до контенту. Таке часто трапляється, коли на сторінці з’являється рекламний pop-up, який неможливо закрити з клавіатури.
Якщо ви працюєте над реалізацію того чи іншого UI-патерну (модальне вікно, акордеон тощо), перевірте рекомендації з секції Design Patterns and Widgets WAI-ARIA Authoring Practices. Там описано десятки патернів і, зокрема, їхню правильну поведінку у відповідь на команди з клавіатури. Не варто винаходити велосипед — уже є стандарти.

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

Для того щоб відобразити сторінку, браузери парсять 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>

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

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

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

Атрибут name input-у неінформативний (name="f_n");
Input не має placeholder атрибута;
Текст First Name ліворуч від input-у — це <span>, і браузер не може знати, що він описує input (зовсім інша справа тег <label>).

Не варто очікувати, що людина, яка користується скрінрідером, заповнить цю форму. І це хороший приклад, чому специфікації, стандарти й валідність важливі. Невалідна розмітка — причина некоректного відтворювання контенту асистивними технологіями. Натомість 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 Landmarks — це не просто хіпстерські трюки, а спосіб полегшити життя користувачам асистивних технологій, пошукових систем і девелоперів. Як ви вже могли здогадатись, VoiceOver також виводить список усіх цих <nav>, <main>, <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 — це якась складна специфікація, і потрібно багато часу на її освоєння, але я користуюся простим алгоритмом:

Використовую нативні елементи й теги, де це можливо. Ще ніхто не придумав універсальної якісної альтернативи <select>, а правильно обробляти й реагувати на натиснення клавіш — ще те завдання.
Використовую HTML5 семантичні елементи (header, nav etc ) і додаю до них role="header" role="navigation" за потреби підтримувати застарілі браузери:

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

Шукаю схожий патерн ARIA, якщо я реалізовую елемент, який має свою назву — акордеон, карусель тощо.
Застосовую ARIA Live, якщо надсилаю дані асинхронно й змінюю сторінку без її перезавантаження. Це спосіб повідомити користувача, який має труднощі з зором, про те, що контент на сторінці оновився.

Стилі

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 і не приховую свого задоволення від того, що рік у рік слухачі розвиваються в темі доступності, доповнюють мій контент і діляться досвідом. Дедалі більше верстальників не просто роблять кольорові сторінки, а й перевіряють їх на доступність.

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

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

Udacity/Google Accessibility Course.
The A11Y Project — ресурс із інформацією про доступність і туторіалами та рецептами для різних компонентів.
Web Content Accessibility Guidelines (WCAG) 2.0.
Inclusive Components — автор реалізовує й пояснює рецепти доступних компонентів.
A11y Cast — YouTube.