Кратък, пристрастен чеклист за достъпни уеб бутони

Проблемът със съветите за достъпност на бутоните

Повечето насоки за достъпност на бутоните попадат в два лагера: или са 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 (ниво AAA) изисква интерактивните елементи да имат минимален размер на целта 44×44 CSS пиксела. Това не е за визуалния размер — става дума за кликаемата зона.

Можете да имате малък визуален бутон с достатъчен padding или да разширите зоната за натискане с псевдоелемент. Важното е потребителят да не трябва да се прицелва прецизно.

Мобилните потребители, хората с двигателни затруднения и всеки, който използва устройство в движение, ще пропускат малки цели. Икона бутон с размер 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 bold). Етикетите на бутоните обикновено са нормален текст.

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

Използвайте инструмент за проверка на контраста по време на дизайна, а не след пускането. Поправянето на проблеми с контраста в продукция е скъпо, защото често изисква промени в дизайн системата.

Ако работите с инструменти за обработка на изображения, обработката от страна на клиента може да помогне за запазване на поверителността при генериране на достъпни визуални ресурси — особено при тестване на цветови комбинации или генериране на preview състояния.

Какво не покрива този чеклист

Този списък умишлено е непълен. Той не покрива семантиката на disabled състоянията, състоянията на зареждане, обработката на грешки или сложни модели на бутони като split buttons или dropdown triggers. Тези модели се нуждаят от собствени насоки.

Той също не покрива по-широкия въпрос кога да се използва бутон вместо други интерактивни елементи. За това трябва да разбирате семантичен HTML и дървото за достъпност — теми, които заслужават собствени статии.

Това, което покрива, са лесните победи: грешките, които се появяват в почти всяко code review, засягат най-много потребители и са най-лесни за поправяне по време на разработка.

Как да интегрирате това в работния си процес

Чеклистите за достъпност работят само ако са част от процеса на разработка, а не добавени след това. Ето как да го постигнете:

В дизайна: добавете състояния на фокус и анотации за зоните за натискане във вашите дизайн файлове. Не оставяйте разработчиците да ги отгатват.

В code review: проверявайте за елементи <button>, aria-label при бутони с икони и CSS за състояния на фокус. Те се забелязват бързо.

В тестването: преминете през интерфейса с клавиатурата чрез Tab. Ако не можете да достигнете бутон или не виждате къде е фокусът, вашите потребители също няма да могат.

В документацията: включете изискванията за достъпност на бутоните във вашата библиотека с компоненти. Направете правилното действие по-лесно от грешното.

Ако отстранявате проблеми в продукция, инструментите за инспектиране на HTTP headers и redirects могат да ви помогнат да разберете как помощните технологии интерпретират вашия markup — особено при отстраняване на проблеми с управлението на фокуса след навигация.

Цената на пропускането на тази работа

Недостъпните бутони не просто не покриват WCAG — те чупят работни потоци. Потребител, който не може да кликне бутон за изпращане, не може да попълни формуляр. Потребител, който не може да види състоянията на фокус, не може да навигира с клавиатура. Потребител, който не може да различи текста на бутона от фона, не може да прочете етикета.

Това не са крайни случаи. Около 15% от глобалното население има някаква форма на увреждане, а временните затруднения (счупена мишка, ярка слънчева светлина, държане на бебе) в крайна сметка засягат всички.

Добрата новина е, че достъпността на бутоните е предимно решен проблем. Не е нужно да измисляте нови модели или да чакате поддръжка от браузърите. Просто трябва да използвате платформата правилно и да тествате работата си.

Основни изводи

• Използвайте елементи <button> за бутони и елементи <a> за навигация — семантичната разлика е важна за помощните технологии
• Уверете се, че зоните за натискане са поне 44×44 CSS пиксела, за да подпомогнете хората с двигателни затруднения и мобилните потребители
• Осигурете видими състояния на фокус с висок контраст, които работят в цялата ви дизайн система
• Пишете етикети на бутони, които имат смисъл, когато се четат самостоятелно, и използвайте aria-label за бутони само с икона
• Проверявайте цветовия контраст по време на дизайна, а не след пускането, за да избегнете скъпи корекции

FAQ

Q: Мога ли да използвам role="button" върху <div>, ако добавя keyboard handlers?

A: Можете, но не бива. Ще трябва ръчно да обработите Enter, Space, управлението на фокуса и disabled състоянията — и неизбежно ще пропуснете нещо. Елементът <button> прави всичко това правилно по подразбиране. Използвайте него.

Q: Какво да кажем за бутони, които превключват състояние, като бутон play/pause?

A: Използвайте aria-pressed="true" или aria-pressed="false", за да посочите текущото състояние. Етикетът на бутона също трябва да отразява действието, което ще се случи при клик („Пауза“ при възпроизвеждане, „Пускане“ при пауза), а не текущото състояние. Потребителите на екранни четци трябва да знаят какво ще направи бутонът, не в какво състояние е системата.

Q: Трябва ли disabled бутоните да покриват изискванията за контраст?

A: WCAG 2.1 освобождава disabled контролите от изискванията за контраст (1.4.3), но това е спорно. Disabled бутоните с лош контраст са трудни за възприемане от всички. Ако ще показвате disabled бутон, направете го четим. Още по-добре — скрийте го или обяснете защо е disabled.

Q: Как да тествам достъпността на бутоните без екранен четец?

A: Използвайте клавиатурата. Преминете през интерфейса с Tab и проверете дали можете да достигнете всеки бутон, да виждате къде е фокусът и да активирате бутоните с Enter или Space. Това улавя повечето проблеми. За по-задълбочено тестване използвайте accessibility inspector в Chrome или Firefox DevTools, за да проверите изчислените роля и етикет.

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