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

Привіт. Мене звуть Дмитро Попов. Я є експертом з питань цифрової доступності в UNDP Ukraine та засновником Лабораторії цифрової доступності. Питаннями доступності займаюся вже близько 10 років. Крім того, я — незрячий, тому знаю про цифрову доступність, можна сказати, не з чуток.

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

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

Коротко почнемо з основного — що таке цифрова доступність, навіщо вона вам і які є критерії доступності.

Що таке цифрова доступність

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

Цифрову доступність ще називають цифровою безбар’єрністю. Це синоніми. Цифрова доступність містить зокрема поняття вебдоступності і мобільної доступності.

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

Чому вебдоступність важлива

По-перше, люди з сенсорними, руховими і когнітивними порушеннями — це значна частина населення, близько 15-20%. В Україні ж на сьогодні налічується майже 3 млн людей з інвалідністю. Це лише ті люди, які мають офіційно оформлений статус, не кажучи про те, що через війну, на жаль, їхня кількість буде лише зростати. Ігнорувати стільки людей не вигідно і не гуманно.

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

У ЄС вимоги наразі переважно застосовуються до державних сайтів і мобільних застосунків, однак з 2025 року вступає в дію Європейський акт про доступність, який стосується приватного бізнесу.

В Україні за останні два роки також значно оновили законодавство в цій сфері (зокрема за підтримки UNDP). У червні 2022 року вступив у дію новий державний стандарт з вебдоступності, який регламентує не лише сайти, а й мобільні застосунки. У липні 2023 року уряд ухвалив постанову, якою зобов`язав органи виконавчої влади дотримуватися вимог цього ДСТУ. Очевидно, що гармонізація українського законодавства з європейським продовжиться і незабаром вимоги доступності будуть встановлені і для приватного сектору.

Тож ким би ви не були — дизайнером, розробником, контент-менеджером чи власником бізнесу — питання впровадження цифрової доступності рано чи пізно вас торкнеться. І чим раніше ви почнете застосовувати вимоги вебдоступності, тим, як правило, буде вам дешевше. Значно ефективніше з самого початку розробити доступний продукт, аніж потім виправляти помилки.

І тут хочу згадати одну історію про втрату часу і грошей, яка, на жаль, є типовою, та яку часто спостерігаю.

Одна організація вирішила модернізувати сайт, щоб він відповідав вимогам цифрової доступності. Замовник вказав у ТЗ, що сайт повинен бути доступним для людей з інвалідністю, зокрема для незрячих людей. Розробники побачили в ТЗ цю додаткову задачу — яка в Україні все ще є екзотичною — і додали до вартості ще 10-15 відсотків. Коли проєкт майже готовий і розробники виправляли останні баги, замовник вирішує звернутися до нас як до незалежних консультантів з повною впевненістю, що сайт відповідає вимогам доступності.

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

Щоб такого не сталося з вами — незалежно від того, чи ви будете в ролі розробника, чи замовника — потрібно дотримуватися певних правил.

Які є критерії доступності

Основним документом, що визначає критерії доступності, є Настанови з доступності вебвмісту (WCAG). Новий український держстандарт наразі посилається на версію WCAG 2.1 (її, до речі, також вперше офіційно переклали українською мовою). Хоча у жовтні 2023 року було прийнято версію WCAG 2.2, яка має деякі додаткові критерії, український і міжнародні стандарти ще певний час посилатимуться на версію 2.1.

WCAG має чотири принципи, кожен з них містить настанови (guidelines), а кожна настанова надає критерії успішності, за якими перевіряють виконання відповідність вебсайту (або іншого ресурсу) настановам WCAG.

Відповідність WCAG має три рівні: A (найнижчий), AA (середній) та AAA (найвищий). Обов’язковим відповідно до законодавства України та більшості країн є рівень AA. Тоді як рівень AAА можна сприймати як рекомендації, які не завжди можливо виконати.

Далі детальніше розповім про основні вимоги WCAG — так, як їх слід розуміти.

Текстові альтернативи для графічних елементів

Незрячі люди не можуть побачити зображення, тому для них важливо створити текстовий опис — альтернативний текст.

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

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

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

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

Для зрячих користувачів ці іконки є інтуїтивно зрозумілими, тоді як незрячим користувачам скринрідер прочитає просто «кнопка» чи «посилання», і користувачі не дізнаються про призначення елементу. Щоб скринрідер прочитав назву елементу, він повинен мати доступне ім’я (accessible name). Якщо елемент має видиму мітку, вона й буде доступним ім’ям елементу, якщо вона не перезаписана іншими атрибутами. А якщо видимої мітки немає, необхідно додати цю мітку іншим способом.

Якщо іконка додається саме як зображення, тобто елемент <img>, додайте для цього зображення атрибут alt з міткою. В інших випадках використовуйте атрибут aria-label. При цьому використовувати атрибут title не бажано.

Мітка повинна бути короткою і чіткою — «Закрити», «Шукати», «Сторінка на Facebook» тощо. Не слід писати довгі мітки та вказувати тип елементу, наприклад, «Кнопка пошуку» чи «Посилання на Facebook». Тип (роль) елементу скринрідер і так прочитає.

Значення атрибутів alt та aria-label не відображається на екрані, а доступне лише користувачам скринрідерів. Щоб переконатися, що мітка працює, відкрийте інструменти розробника в браузері та перевірте доступне ім’я елементу.

Доступність керування з клавіатури

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

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

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

Тому, якщо ви використовуєте власні вебкомпоненти або бібліотеку, переконайтеся, що вони отримують фокус клавіатури і відгукуються на клавіатуру. Щоб працював фокус клавіатури коректно, елемент повинен бути доданий у порядок табуляції. Усі нативні інтерактивні елементи, як-от button, <a> з атрибутом href, input тощо, автоматично отримують фокус клавіатури. Якщо ж ви для кнопки використовуєте нейтральні теги <span> чи <div>, додайте для них tabindex=”0” — тоді елемент буде додано у порядок табуляції. Однак краще все ж використовуйте нативні елементи.

Також слід пам’ятати про індикатор фокусу клавіатури — він за замовчанням відображається, однак його часто навмисно приховують.

Усе вище сказане стосується HTML, однак в мобільній розробці принцип такий самий: слід використовувати нативні компоненти платформи або кастомні компоненти зі спеціальними атрибутами доступності.

Колір і контраст

Контрастність важлива передусім людям з порушенням зору, але корисна всім користувачам — наприклад, під час перегляду контенту під яскравим сонцем.

Відповідно до вимог WCAG щодо контрасту, текст повинен мати контраст відносно тла щонайменше 4,5:1, а нетекстові елементи — 3:1. Це мінімальні вимоги — можна й більше, але чорним по білому теж не добре.

Дотримання мінімальних вимог контрасту — це якраз завдання дизайнера. Переконайтеся, що будь-який текст, зокрема текст на неоднорідному тлі, як-от текст на зображенні, має коефіцієнт щонайменше 4.5:1. Винятками є лише кольори логотипу та неактивних елементів інтерфейсу — вони не повинні відповідати цим вимогам.

Колір як джерело інформації

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

Створюйте інтерфейс і контент так, щоб його можна було зрозуміти без сприйняття кольорів.

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

Збільшення тексту / масштабування

Контент повинен бути масштабованим. Користувач може захотіти збільшити текст сторінки, і сторінка повинна належно перекомпонуватися. Не обов’язково додавати на сайт панелі інструментів для налаштування розміру шрифту. Користувач може натиснути CTRL і + у браузері для збільшення тексту. Важливо, щоб частина контенту не зникла і не з’явився горизонтальний скрол.

Щоб дозволити користувачам комфортно змінювати текст:

• використовуйте відносні єдиниці розміру шрифту (em) або відсоткові значення;
• переконайтеся, що відсутні втрати вмісту або функціональності, коли текст змінюється, а текстові контейнери не змінюють свою ширину.

Семантика

Зрячі користувачі розрізняють елементи візуально — вони розуміють, де кнопка, де посилання, де заголовок, а де текст. Відповідно вони розуміють функції елементу — на посилання можна натиснути і перейти на сторінку, а після заголовка починається секція контенту.

Щоб незрячі користувачі також зрозуміли призначення елементів вебсторінки, необхідно використовувати теги за їхнім призначенням — тобто для заголовків використовувати h1, h2, h3, а не лише великий жирний шрифт; для таблиць — table, для списків — ul/ol тощо. Для користувачів скринрідерів це надзвичайно важливо, адже дозволяє їм краще орієнтуватися в контенті і використовувати клавіші швидких дій. Не варто також плутати кнопки і посилання, чекбокси і радіокнопки, заголовок і курсивний текст — це вводить в оману користувачів.

Повторно наголошую — надзвичайно важливо використовувати теги за їхнім призначенням. Однак якщо ви з певної причини не можете використовувати правильний тег, є альтернативний спосіб передати семантику — ARIA-ролі. Тобто, якщо ви не можете використовувати тег <button> , використовуйте <div role=”button”>.

Також важливо, щоб весь контент сторінки знаходився у семантичних регіонах — <header>, <main>, <footer> тощо. Це дозволить користувачам скрінрідерів швидше знаходити потрібний контент.

Форми

З мого досвіду, форми — це часті порушники правил доступності. Про них, напевно, варто було би написати окрему статтю, однак розповім про основні вимоги коротко.

Мітки

Поля та інші елементи форм повинні мати текстові мітки, програмно пов’язані з ними. Знаходження мітки біля поля є недостатнім. Необхідно пов’язати мітку з полем, наприклад неявно, розмістивши поле всередині <label>, або явно — за допомогою атрибута for. Якщо ці способи не підходять, можна використовувати aria-labelledby.

Інформація про помилку

Якщо користувач неправильно заповнив форму, інформація про помилки повинна надаватися у текстовому вигляді. Основний текст про те, що сталася помилка, повинен бути розміщений над формою і позначений як живий регіон — наприклад, за допомогою role="alert". Регіон з такою роллю скринрідер прочитає автоматично без фокусування на елементі.

Детальне пояснення помилки важливо розмістити поруч з полем і пов’язати його з полем за допомогою атрибуту aria-describedby.

Хорошою практикою також є перенесення фокусу на перше поле з помилкою.

Обов’язкові поля

Обов’язкові поля повинні бути належно позначені. Для цього можна використовувати атрибут required, однак, якщо ви не хочете, щоб валідація заповнення полів відбувалася на рівні браузера, використовуйте атрибут aria-required — він повідомить користувачам скрінрідера, що поле обов’язкове.

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

Інструкції та очікуваний формат даних

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

Шкідливі елементи дизайну

Контент не повинен мати шкідливих елементів, як-от часті спалахи, які можуть викликати судоми. До шкідливих елементів також належать аудіо, що стартує автоматично, анімації, якщо вони не пов’язані з демонстрацією певного процесу, які неможливо зупинити.

Кастомні елементи та складні компоненти інтерфейсу

Модальні вікна, панелі вкладок, слайдери та окремі їхні елементи повинні бути сумісними зі скринрідерами та клавіатурою. Коли користувач скринрідера фокусується на таких елементах, він повинен почути назву елементу, його роль та стан (наприклад, «Головна, вкладка, обрано»). Для цього в HTML потрібно використовувати спеціальну розмітку WAI ARIA, а на мобільних платформах — властивості доступності відповідної платформи.

Хочу наголосити, що WAI ARIA зазвичай потрібна тільки для створення кастомних елементів. Для стандартних HTML-елементів розмітка ARIA не потрібна. Для наочності наведу приклад. Припустимо, вам потрібно створити звичайний чекбокс на сторінці. Ви можете використовувати нативний елемент:

    <input type="checkbox">

У цей елемент уже вбудовані властивості доступності, тому він буде повністю доступним для клавіатури та скринрідера. Якщо ви створюєте власний (кастомний) чекбокс (або взяли кастомний чекбокс з бібліотеки), він повинен мати прописані ARIA-атрибути — атрибути доступності:

    <div class="myCheckbox" role="checkbox" aria-checked="false">

Без цих атрибутів скринрідер сприймає <div> як нейтральний елемент, що цілком логічно. За допомогою ARIA-ролей і атрибутів ми передаємо скринрідеру роль елементу (чекбокс) і поточний стан (не позначено).

У більш складних компонентів ARIA-розмітка відповідно буде складнішою. Розглянемо деякі з них.

Модальні вікна

Переконайтеся, що контейнер модального вікна має атрибути role="dialog" та aria-modal="true" — завдяки ним скринрідер буде поводитися з таким вікном як модальним — тобто дозволяти користувачам працювати лише з вмістом модального вікна та не виходити за його межі.

Також важливо забезпечити таку логіку під час взаємодії з модальним вікном:

• при відкритті вікна фокус переходить у вікно — на перший фокусований елемент всередині цього вікна;
• у вікні є кнопка для закриття вікна та / або працює закриття клавішею Esc;
• після закриття вікна фокус повертається до тригера — елементу, активація якого відкрила це вікно.

Важливо також належно приховувати контент вікна, поки воно не відкрито. Може трапитися таке, що вікно візуально відсутнє на екрані, однак користувачі скринрідера на нього потрапляють. Таке буває, якщо контент вікна для приховування просто виносять за межі видимої зони. Для надійного приховування контенту слід використовувати display:none.

Слайдери / каруселі

Це лідери з багів доступності. Однак я не буду відмовляти від їхнього використання, оскільки слайдери / каруселі теж можна зробити доступними.

Головні застереження щодо слайдерів:

• слайдер не повинен перемикатися автоматично, або повинна бути кнопка для зупинення автоматичного перемикання;
• неактивні елементи слайдера (слайди) повинні бути надійно приховані від скринрідера (як і в модальних вікнах, винесення за край контейнера не підходить);
• зміна слайдів повинна озвучуватися скрінрідером (для цього зазвичай створюють візуально прихований контейнер з aria-live="polite" з текстом виду «Слайд 2 з 5»);
• слайдер повинен мати кнопки для перемикання слайдів, і вони повинні містити текстові мітки (можна невізуальні — надані за допомогою aria-label).

Загальна навігація

Навігація повинна бути простою і передбачуваною:

• заголовки сторінок (title) мають бути унікальними і чіткими (наприклад, «Контакти — [Назва компанії]»);
• структура контенту має бути передана за допомогою заголовків від <h1> до <h6>: основний заголовок — <h1>, заголовки розділів — <h2>, підрозділів — <h3> тощо;
• меню сайту на різних сторінках має відображатися у тому ж місці;
• посилання, що ведуть на одну й ту ж сторінку, або кнопки, що виконують однотипну дію, повинні мати однакові назви;
• посилання з різним призначенням не можуть мати однакові назви. Наприклад, кілька посилань «читати далі» — це неправильно;
• рух фокусу клавіатури має бути передбачуваним (проблеми можуть виникати на складних компонентах, про що вже розповів вище, а також на контенті, що завантажується асинхронно — якщо такий вміст завантажується за запитом користувача, у такому випадку фокус має переміщуватися на початок нового контенту).

Альтернативні версії для мультимедіа

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

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

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

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

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

Загалом, є два способи тестування доступності — автоматичний і ручний. Для надійного тестування варто застосовувати обидва.

Автоматичний спосіб тестування

Для автоматичного тестування використовують спеціальні вебінструменти або плагіни для браузерів. Найбільш популярними інструментами є вебсервіс WAVE, та плагіни axe DevTools та Accessibility Insights. Я рекомендую останній як найбільш функціональний і простий для початківців.

Потрібно просто натиснути FastPass, і ви отримуєте результати сканування поточної сторінки. Результат можна зберегти в HTML-файлі.

Зауважу, що хоча автоматичне тестування — це дешево і швидко, однак автоматично можна виявити лише приблизно 30-50% проблем.

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

Тож автоматичне тестування має бути лише першим кроком. Для того, щоб переконатися, що ваш ресурс справді доступний і відповідає стандарту, необхідне ручне тестування.

Ручний спосіб тестування доступності

Ручне тестування — це перевірка вебсайту чи мобільного застосунку за всіма критеріями WCAG. Зрозуміти WCAG іноді непросто, тому початківцям я рекомендую застосовувати guided-тести — це коли інструмент чи методологія надає вам чіткі підказки, що саме потрібно перевірити, а ви приймаєте рішення, чи є проблема.

В Accessibility Insights теж є такий функціонал — режим Assessment. Вам надаються 24 групи тестів. Плагін вказує на ті проблеми, які можна виявити автоматично. В інших випадках плагін знаходить відповідний контент (наприклад, зображення), а вам потрібно прочитати їхній альтернативний текст і переконатися, що він правильно описує зображення.

Ще один інструмент, який працює як просунутий контрольний список, — Va11ydette від компанії Orange. Він надає дуже прості й лаконічні інструкції з тестування.

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

На мобільних ОС ви можете включити скринрідер безпосередньо у налаштуваннях:

• в iOS — Доступність -> Зір -> VoiceOver;
• в Android — Спеціальні можливості -> Talk Back.

А для Windows я рекомендую NVDA — це безкоштовний і найбільш поширений скринрідер.

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

Висновок

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

Де ще почитати про доступність

• Матеріали про цифрову безбар’єрність та вебдоступність на порталі Дія.Безбар’єрність — тут публікуємо матеріали українською про доступність, створені командою UNDP за підтримки Швеції та Японії. Зокрема, там можна знайти дослідження про стан вебдоступності в Україні і аналіз іноземного досвіду в цій сфері, відеозаписи наших тренінгів, а також короткий посібник із вебдоступності;
• Освітні серіали «Вебдоступність» та «Інклюзивний вебдизайн» на порталі Дія.Освіта — коротко і просто вони розповідають про основні поняття і принципи вебдоступності, які потрібно знати, щоб створювати безбар’єрний онлайн-контент;
• Інклюзивний цифровий простір — сайт з багатьма корисними матеріали про цифрову доступність від ГО «Інститут інноваційного врядування», як-то відеолекції з вебдоступності та інклюзивного дизайну, тематичні статті і блоги з рекомендаціями;
• Orange Accessibility — якісні матеріали про розробку і тестування веб- і мобільної доступності;
• Appt — технічні рекомендації з розробки доступних мобільних застосунків, методологія тестування доступності мобільних застосунків;
• Deque University — напевно, найкращі онлайн-курси з цифрової доступності.