StandWithUkraine
Accessibility — розробка та тестування доступності сайтів
Що таке Accessibility
Accessibility — одна з важливих частин тестування сайтів, яка допомагає переконатися, що люди з обмеженими можливостями мають доступ до WEB-контенту сайту. Коли сайти розроблені правильно, всі користувачі, мають рівний доступ до їхнього вмісту.
Навіщо підтримувати Accessibility? По-перше, для деяких країн підтримка доступності диктується на законодавчому рівні, порушення яких може спричинити судовий позов. По-друге, близько 20% людей мають обмежені можливості, і це лише офіційні дані, таким чином, підтримка Accessibility — збільшує кількість клієнтів більш ніж на 20%.
Специфікації, які допомагають у підтримці доступності, а також диктують правила, як саме має виглядати та працювати доступний сайт: Web Content Accessibility Guidelines (WCAG).
Щоб бути впевненим, що при розробці нової функціональності ми, як і раніше, отримаємо доступний продукт і не створимо нових помилок, рекомендується проводити низку перевірок на етапі розробки та тестування.
Етапи розробки
Залежно від функціональності, перевірку доступності можна розділити на наступні етапи:
1. Усі інтерактивні елементи мають бути доступні з клавіатури та мати візуальний фокус.
Під інтерактивними елементами ми розуміємо:
- кнопки та посилання
- елементи форми, такі як текстовий input, textarea, radio, checkbox, colorpicker, datepicker, range
- кнопки меню, акордеони, значки спливаючих підказок та інші
При тестуванні пристроїв важливо перевіряти паралельно кілька операційних систем, через те, що одна і та ж функціональність може поводитися інакше на різних системах, наприклад для Desktop перевіряється Mac OS і Windows, для Mobile: iPhone та Android. Ці 4 типи пристроїв іноді вимагають різних виправлень, але й дуже часто виправлення на одному з пристроїв виправляє проблеми й на інших.
2. Фокус на елементах повинен йти зверху донизу та зліва направо (для RTL-мов зправа наліво)
Це важливо пам’ятати і тоді, коли ми використовуємо FLEX. Якщо ми хочемо змінити порядок компонентів за допомогою CSS, елементи DOM не змінюють свого положення. Зміни CSS застосовуються лише візуально, але не впливають на модель DOM, ось чому фокус йтиме в неправильному порядку — в якому елементи розташовані в DOM, ігноруюючи позицію CSS.
Правило «Зверху донизу та зліва направо» не працюватиме, що заплутає користувача, оскільки фокус на елементах буде нечітким. Не рекомендується змінювати порядок розміщення Flex.
3. Всі повідомлення про помилки та глобальні інформаційні повідомлення повинні озвучуватись для користувача.
Якщо користувач вводить неправильне значення, з’являється повідомлення про помилку. Ця помилка буде показуватися на екрані, доки дані не будуть виправлені, тому його потрібно озвучувати щоразу, коли користувач фокусує поле з помилкою.
Перевірка інтерфейсу користувача в більшості випадків працює, коли користувач фокусується поза полем і коли натискає кнопку «Відправити / Зберегти».
Якщо користувач натискає кнопку «Надіслати» для форми, яка заповнена з помилками – ми програмно ставимо фокус на перше поле з помилкою, щоб вона була озвучена.
Глобальні повідомлення, які належати до всієї сторінки, повинні бути озвучені негайно, якщо вони з’являються інтерактивно, або по завантаженню сторінки, якщо вони вже існують в цей час.
4. Фокусування елементів у правильному порядку у випадках, коли елементи з’являються або зникають динамічно, наприклад Sidenav, Accordion, Dropdown.
Якщо акордеони закриті, нічого із прихованих елементів не повинно фокусуватися та озвучуватися. Після відкриття акордеона, раніше приховані елементи мають фокусуватися та озвучуватися саме в тому порядку, де вони розташовані візуально.
Окрім того, для деяких елементів існує додаткова навігація, наприклад, у випадку Dropdown, якщо ми робимо focusOut з випадаючого меню, воно має закриватися.
Під час імплементації специфічних елементів, рекомендую продивитися Accessibility вимоги по кожному з них.
5. Правильне озвучення елементів сторінки у випадку навігації з клавіатури та Swipe Navigation
Для навігації за допомогою клавіатури нам потрібно зафокусити та озвучити всі інтерактивні елементи та їхні стани. Як приклад для кнопок та посилань має бути озвучений текст і назва елемента, а для checkbox додатково важливо зазначити, чи він checked, чи ні.
У випадку компонентів форми, окрім значення і label, мають бути озвучені і загальні атрибути полів. У прикладі ми маємо обов’язкове поле з label EMAIL і введеним значенням.
Placeholder буде озвучений лише в разі порожнього значення. Додатково ми використовуємо атрибут data-required, щоб повідомити екрану, що це обов’язкове поле.
Aria-describedBy — спеціальний атрибут для програми зчитування з екрана. У цьому випадку ми використовуємо його для озвучування помилок.
Коли для навігації ми використовуємо Swipe на мобільних пристроях, фокус йде на всі елементи, які знаходяться на сторінці, а не лише на інтерактивні, як при роботі з клавіатурою. В такому випадку графічні елементи, наприклад іконки або hr, будуть озвучуватися як «unidentified characters». Щоб це виправити — використовуємо атрибут aria-hidden.
Також важливо перевірити, що на усіх пристроях при фокусі на інтерактивний елемент і натиску на Enter відбувається необхідна дія. Але варто зазначити, що для деяких компонентів потрібна спеціальна навігація за допомогою стрілок на клавіатурі. Як приклад, для перемикання між radio ми використовуємо стрілки вгору та вниз. Деякі бібліотеки підтримують таку поведінку з коробки, але іноді нам потрібні додаткові виправлення з нашого боку.
Семантика коду та WAI-ARIA
Семантичний HTML — це підхід до створення веб-сторінок, заснований на використанні тегів HTML відповідно до їх призначення. Більшість вмісту можна зробити доступним, просто використовуючи правильні елементи HTML.
Використовуючи семантичні теги HTML на наших сторінках, ми надаємо додаткову інформацію для програм зчитування з екрана, з яким елементом зараз працює користувач і як його правильно озвучувати. Крім того, ми допомагаємо пошуковим системам зрозуміти ролі та відносну важливість різних частин наших сторінок. Наприклад, div, span — не несуть жодної інформації про те, який вміст вони містять. В той самий час теги form, table і article — дають чітке розуміння, з яким контентом ми працюємо.
Виділення заголовків за допомогою відповідних тегів h1, h2, h3 важливе не лише для перегляду, але й для програм зчитування з екрана та пошукової оптимізації. Програма зчитування з екрана озвучує кожен заголовок, коли ви рухаєтеся, повідомляючи вам, що є заголовком, а що — абзацом, окрім того у багатьох програмах користувач може переходити до наступних чи попередніх заголовків.
Коли ми використовуємо таблиці, нам потрібно використовувати елементи заголовків таблиці, щоб допомогти програмі зчитування з екрана зв’язати рядки або стовпці в групу даних. Заголовки таблиць визначаються за допомогою елементів th; ви також можете вказати, чи є вони заголовками рядків, чи стовпців за допомогою атрибута scope.
Елемент caption і summary в таблицях виконують подібну роботу — вони надають додатковий текст опису для таблиці та озвучуються screen readers. Елемент caption зазвичай є кращим для вмісту, оскільки він видимий для всіх користувачів.
Але дуже часто ми маємо елементи зі складною навігацією, які неможливо відтворити лише правильним використанням тегів і від використання стилізованих div або span нам нікуди не подітися. Як же в такому випадку нам підтримувати accessibility?
WAI-ARIA — це специфікація, яка визначає набір додаткових атрибутів HTML, які можна застосовувати до елементів, щоб забезпечити додаткову семантику та покращити доступність там, де її немає.
WAI-ARIA має 2 типи атрибутів:
- РОЛІ — визначають, чим є або яку роль виконує елемент.
- ВЛАСТИВОСТІ — визначають властивості елементів, які можна використовувати для надання елементам додаткового значення або семантики
Якщо з ролями більш-менш зрозуміло, то з властивостями може бути дещо складніше. Розглянемо деякі часто використовувані властивості, щоб більше зрозуміти які можливості вони нам надають:
- aria-required=»true» — вказує, що введені дані форми мають бути заповнені, щоб бути валідними. Слід додати до всіх обов’язкових полів
- aria-label=»label text» — озвучується як label, але невидима для користувача
- aria-labelledby=»labelID» — дозволяє розмістити ідентифікатор елемента, а потім посилатися на нього як на label
- aria-describedBy=»elementID» — ідентифікує елемент, який містить додатковий опис поточного елемента
- aria-haspopup — вказує на інтерактивний спливаючий елемент, наприклад меню або діалогове вікно, який може бути викликаний елементом. Використовується, наприклад, для розкривних меню
- aria-invalid=»true» — означає, що введене значення недійсне. Використовується для полів.
- aria-live=»polite“ — означає, наскільки терміново нам потрібно озвучити змінену інформацію в цьому елементі. Assertive озвучать відразу, а polite — почекають, коли озвучать інші повідомлення.
- aria-expanded=“false” — встановлюється для елемента, щоб вказати, чи елемент розгорнутий чи згорнутий, а також чи відображаються його приховані дочірні елементи. Використовується на акордеонах, дропдаунах
- aria-controls=“elementId“ — ідентифікує елемент, вміст або присутність якого контролюється поточним елементом
- aria-atomic=»true» — визначає, яку частину зміненого вмісту слід озвучити. За замовчуванням значення false і означає, що озвучуватиметься лише змінений вміст. У разі істини — буде озвучено все речення
Accessibility tools
Щоб перевірити семантичний HTML, виправити фокус на всіх елементах інтерфейсу та озвучення, існує ряд інструментів, які можуть нам в цьому допомогти:
1. Розширення браузера WAVE. Його дуже легко встановити та використовувати. WAVE прийде в пригоді, коли потрібно буде перевірити семантику коду, контрастність сайту і створити повний звіт з наявними проблемами. Також до кожної проблеми він видає рекомендації, які допоможуть розробникам пофіксити дефект.
2. Screen Readers допоможуть нам перевірити правильний фокус на елементах і озвучку, коли елемент в фокусі.
Для Windows Desktop можна використовувати NVDA, Voice Over для пристроїв Apple і Talk Back для Android.
Одним із принципів уникнення помилок доступності є вибір правильної бібліотеки компонентів інтерфейсу користувача
Перед початком розробки рекомендується витратити деякий час на дослідження доступності обраної бібліотеки, так як заміна бібліотеки після впровадження або дописування необхідної доступності в ній займе набагато більше часу.