Короткий чекліст із чіткою позицією для доступних вебкнопок

Проблема з порадами щодо доступності кнопок

Більшість рекомендацій щодо доступності кнопок потрапляє в один із двох таборів: або це 40-сторінкове тлумачення WCAG, яке ніхто не читає, або розпливчаста порада «зробіть кнопки доступними» без конкретних кроків. Жоден варіант не допомагає, коли ви випускаєте функцію в четвер.

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

1. Використовуйте елемент button для кнопок

Якщо елемент поводиться як кнопка, це має бути елемент <button>. Не <div> з onclick, не <span> з role="button", не <a> з href="#" і preventDefault.

Елемент <button> без додаткових зусиль дає вам навігацію з клавіатури, керування фокусом і оголошення для скринрідерів. Коли ви використовуєте <div>, ви відбудовуєте все це з нуля — і ви зробите це неправильно.

Єдиний виняток: якщо дія веде на нову сторінку або змінює URL, використовуйте елемент <a>. Посилання і кнопки семантично різні. Користувачі скринрідерів навігують за типом елемента й очікують, що кнопки виконують дії, а посилання здійснюють навігацію.

2. Зробіть ціль натискання щонайменше 44×44 пікселі

WCAG 2.5.5 (Level AAA) вимагає, щоб інтерактивні елементи мали мінімальний розмір цілі 44×44 CSS-пікселі. Йдеться не про візуальний розмір — йдеться про клікабельну область.

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

Мобільні користувачі, люди з моторними порушеннями та будь-хто, хто користується пристроєм у русі, промахуватимуться по малих цілях. Кнопка-іконка 24×24 пікселі може виглядати охайно, але з погляду зручності це провал.

3. Забезпечте видимі стани фокуса, а не лише стандартні браузерні

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

Хороший індикатор фокуса має три якості:

• Високий контраст: щонайменше 3:1 щодо суміжних кольорів
• Видимий відступ: не прихований власною рамкою або фоном кнопки
• Послідовна форма: користувачі мають розпізнавати його як індикатор фокуса в усьому інтерфейсі

Не прибирайте outline: none, не замінивши його чимось кращим. І не робіть стани фокуса настільки непомітними, що лише ви можете побачити їх за ідеального освітлення.

4. Пишіть підписи кнопок, які зрозумілі поза контекстом

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

Кнопка з підписом «Дізнатися більше» у такому списку марна. Так само як «Натисніть тут» або «Надіслати». Підпис має описувати дію: «Завантажити чекліст доступності», «Підписатися на оновлення», «Видалити цей коментар».

Якщо ваш дизайн вимагає короткого візуального підпису, використовуйте aria-label, щоб надати описову альтернативу. Але краще рішення — писати підписи, які працюють для всіх.

Для кнопок лише з іконкою aria-label є обов’язковим. Кнопці лише з іконкою лупи потрібен aria-label="Search" або еквівалентний текст. Іконка недоступна для скринрідерів.

5. Забезпечте достатній контраст кольорів

WCAG 2.1 вимагає коефіцієнт контрасту щонайменше 4.5:1 для звичайного тексту і 3:1 для великого тексту (18pt або 14pt напівжирним). Підписи кнопок зазвичай є звичайним текстом.

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

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

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

Чого цей чекліст не охоплює

Цей список навмисно неповний. Він не охоплює семантику вимкненого стану, стани завантаження, обробку помилок або складні патерни кнопок на кшталт split buttons чи тригерів dropdown. Для таких патернів потрібні окремі рекомендації.

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

Натомість він охоплює найпростіші для виправлення речі: помилки, які з’являються майже в кожному code review, впливають на найбільшу кількість користувачів і найлегше виправляються під час розробки.

Як інтегрувати це у ваш робочий процес

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

У дизайні: додавайте стани фокуса й анотації цілей натискання до дизайн-файлів. Не залишайте це розробникам на здогад.

У code review: перевіряйте наявність елементів <button>, aria-label на кнопках-іконках і CSS для станів фокуса. Це легко помітити.

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

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

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

Ціна ігнорування цієї роботи

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

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

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

Ключові висновки

• Використовуйте елементи <button> для кнопок і елементи <a> для навігації — семантична різниця важлива для допоміжних технологій
• Забезпечте цілі натискання щонайменше 44×44 CSS-пікселі, щоб врахувати моторні порушення й потреби мобільних користувачів
• Надавайте видимі, висококонтрастні стани фокуса, які працюють у всій вашій дизайн-системі
• Пишіть підписи кнопок, які мають сенс під час читання ізольовано, і використовуйте aria-label для кнопок лише з іконкою
• Перевіряйте контраст кольорів під час дизайну, а не після запуску, щоб уникнути дорогих переробок

FAQ

Q: Чи можу я використати role="button" на <div>, якщо додам обробники клавіатури?

A: Можете, але не варто. Вам доведеться вручну обробляти Enter, Пробіл, керування фокусом і вимкнені стани — і ви неминуче щось пропустите. Елемент <button> робить усе це правильно за замовчуванням. Використовуйте його.

Q: А як щодо кнопок, які перемикають стан, наприклад кнопки play/pause?

A: Використовуйте aria-pressed="true" або aria-pressed="false", щоб вказати поточний стан. Підпис кнопки також має відображати дію, яка відбудеться після натискання ("Pause" під час відтворення, "Play" під час паузи), а не поточний стан. Користувачам скринрідерів потрібно знати, що зробить кнопка, а не в якому стані перебуває система.

Q: Чи мають вимкнені кнопки відповідати вимогам контрасту?

A: WCAG 2.1 звільняє вимкнені елементи керування від вимог контрасту (1.4.3), але це суперечливе питання. Вимкнені кнопки з поганим контрастом важко сприймати всім. Якщо ви показуєте вимкнену кнопку, зробіть її читабельною. А ще краще — приховайте її або поясніть, чому вона вимкнена.

Q: Як протестувати доступність кнопок без скринрідера?

A: Використовуйте клавіатуру. Пройдіться інтерфейсом за допомогою Tab і перевірте, що можете дістатися кожної кнопки, бачите, де фокус, і можете активувати кнопки Enter або Пробілом. Це виявляє більшість проблем. Для глибшого тестування використовуйте accessibility inspector у Chrome або Firefox DevTools, щоб перевірити обчислені role і label.

Q: У чому різниця між aria-label і aria-labelledby?

A: aria-label надає текстовий рядок безпосередньо. aria-labelledby посилається на ID іншого елемента, текстовий вміст якого стає підписом. Використовуйте aria-labelledby, коли текст підпису вже існує в іншому місці DOM. Використовуйте aria-label, коли потрібно надати підпис, який не видно на екрані.

Джерела

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM