Вебдоступність

Що це таке

Вебдоступність — це те, наскільки добре вебсайт, застосунок чи інструмент працює для людей з інвалідністю. Web Accessibility Initiative (WAI) консорціуму W3C визначає її через те, що люди можуть робити: сприймати, розуміти, орієнтуватися у вебі та взаємодіяти з ним, а також робити в нього свій внесок. Останнє дієслово важить чимало. Сайт, на якому незряча відвідувачка може прочитати кожну статтю, але не може залишити коментар, завантажити файл чи завершити реєстрацію, відповідає лише половині визначення. В англомовних текстах слово часто скорочують до a11y: число позначає одинадцять літер між a та y.

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

Під видимою сторінкою браузер будує другу структуру — для допоміжних технологій. Специфікація ARIA називає її деревом доступності: це дерево доступних об’єктів, у якому кожен вузол представляє елемент інтерфейсу, наприклад кнопку чи прапорець, і передається через API доступності платформи. Екранні читачі, голосове керування, пристрої з перемикачами й брайлівські дисплеї працюють із цим деревом, а не з пікселями. Кожен вузол має назву, роль і стан, а критерій WCAG 4.1.2 Name, Role, Value вимагає, щоб програмне забезпечення могло визначити їх для кожного компонента інтерфейсу. Нативні елементи керування HTML, як зазначає стандарт, уже відповідають 4.1.2, якщо їх використано так, як передбачає специфікація. Елемент div, що лише реагує на клік, потрапляє до дерева як звичайний текст, без ролі й без місця в порядку переходу клавіатурою.

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

Чому це важливо

Веб несе освіту, роботу, державні послуги, покупки й охорону здоров’я, і WAI нагадує, що Конвенція ООН про права осіб з інвалідністю визначає доступ до інформаційно-комунікаційних технологій, зокрема вебу, як базове право людини. У багатьох ситуаціях доступності вимагає й закон, а замовники перетворюють це на рядок у договорі, що називає WCAG 2.2 рівня AA. Цей рядок визначає, що постачальник має збудувати й довести.

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

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

З оцінюванням так само. Інструменти допомагають, але WAI прямо каже, що жоден інструмент сам не може визначити, чи відповідає сайт настановам із доступності, і що потрібна оцінка обізнаною людиною. Рушій правил читає те, що каже розмітка. Людина з клавіатурою та екранним читачем з’ясовує, що робить сторінка.

Як це виглядає на практиці

Сайт проходив власні автоматичні правила доступності, хоча в ньому ховалися одинадцять дефектів доступності, які браузер мав за справні. Кожен із них залежав від того, як сторінка рендериться, а не від того, що каже розмітка. У футері вісім посилань сховали властивістю, яка вимикає тільки реакцію на вказівник, тому клавіша Tab і далі зупинялася на них, хоча на екрані їх ніхто не бачив. Ще два дефекти знайшлися в самих перевірках. Перевірка розкладки відкривала кожне вікно заввишки 900 пікселів, тож телефон, повернутий горизонтально, з екраном 852 на 393 лишався поза її увагою, а саме там два елементи розділяли сім пікселів. Рушій правил тим часом виконував 70 правил зі 105 наявних. Сторінка виводить із цього чотири правила; серед них — що перевірка однієї осі захищає тільки цю вісь і що видимість доводять пікселями, а не документом. Перевірка розкладки, повернута до повного обсягу, зафіксувала 128 збоїв трьома мовами.

Сторінка про те, як кожному елементу керування з піктограмою дали назву для екранних читачів, переносить увагу з вебсайту на застосунок на SwiftUI. Системний символ, якому не задали мітки доступності, екранний читач називає службовою назвою, тож кнопка надсилання звучала як «arrow up circle, button». Решта елементів керування, позначених тільки піктограмою, поводилася подібно, і разом їх набралося сімнадцять: кожен розповідав, як виглядає, а не що робить. Тепер мітка кожного називає дію, а якщо зміст елемента залежить від стану, мітка оновлюється слідом за станом. Стежить за цим лінтер: від конструкції, яка створює елемент лише з піктограмою, до його мітки може бути щонайбільше вісім рядків. Поріг свідомо приблизний і підібраний вимірюванням, тож вісімнадцятий елемент потрапить у код лише разом із міткою. Межу правила сторінка теж називає: воно підтверджує, що мітка десь поруч, а чи влучна вона, з’ясовує тільки людина, яка її прослухає.

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

Де виникають проблеми

Саморобний випадний список працює з мишею й замикає всіх інших. Елемент div з обробником кліку не має ролі, не отримує фокуса з клавіатури й не повідомляє, відкритий він чи закритий, тож екранний читач озвучує звичайний текст, а клавіша Tab його оминає. Починайте з нативного елемента — select, button або details, — який приносить роль, фокус і стан із собою. Якщо дизайн справді потребує власного віджета, дотримуйтеся його шаблону з ARIA Authoring Practices Guide, а потім перевірте віджет клавіатурою та екранним читачем.

Альтернативний текст описує картинку, коли читачеві потрібна її роль. 1.1.1 Non-text Content вимагає текстової альтернативи, що слугує тій самій меті, а логотип-посилання з описом «синій шестикутний логотип» нічого не каже користувачеві екранного читача про те, куди веде посилання. Пишіть альтернативу відповідно до ролі зображення: пункт призначення для зображення-посилання, висновок для діаграми, самі слова для зображення тексту. Суто декоративним зображенням дайте порожній alt="", щоб допоміжні технології їх пропускали.

Після закриття діалогу фокус стрибає на початок сторінки. Коли діалог закривається або односторінковий застосунок змінює маршрут, елемент, що мав фокус, зникає. Фокус падає назад на body документа, і користувач клавіатури чи екранного читача губить місце. Поверніть фокус до елемента керування, який відкрив діалог. Після зміни маршруту на клієнті перенесіть фокус на головний заголовок нового подання, якому задано tabindex="-1", щоб він міг отримати фокус, і екранний читач оголосить, де опинився користувач.

Помилки показано лише червоною рамкою. 1.4.1 Use of Color вимагає, щоб колір не був єдиним візуальним засобом передавання інформації, а 3.3.1 Error Identification — щоб виявлену помилку введення було визначено й описано користувачеві текстом. Червона рамка не робить ні того, ні іншого для людини, яка не відрізняє червоного від сірого або взагалі не бачить поля. Розмістіть поруч із полем коротке повідомлення про те, що не так і як це виправити, пов’яжіть його через aria-describedby, щоб екранний читач прочитав їх разом, а колір залиште другим сигналом.

Що почитати далі

• Introduction to Web Accessibility — визначення WAI, хто отримує користь і чому оцінювання потребує людей, а не лише інструментів.
• How People with Disabilities Use the Web — історії користувачів, бар’єри, з якими вони стикаються, та інструменти й прийоми, на які вони спираються.
• The Business Case for Digital Accessibility — охоплення, інновації, бренд і юридичні ризики, викладені для тих, хто затверджує бюджети.
• Evaluating Web Accessibility Overview — від простих перевірок до повного оцінювання відповідності, з інструментами та звітуванням.
• ARIA Authoring Practices Guide — шаблони для власних віджетів із ролями, станами й поведінкою клавіатури, яких потребує кожен.