Изграждане на достъпни уебсайтове

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

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

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

Разбиране на WCAG

Насоките за достъпност на уеб съдържанието (WCAG) предоставят рамка, която прави уеб съдържанието възприемаемо, работещо, разбираемо и надеждно. Четирите принципа — често съкращавани като POUR — са основата на всички стандарти за достъпност.

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

Нива и версии

На всеки критерий за успех е присвоено ниво: A, AA или AAA. Ниво AA е практическата цел за повечето организации и нивото, към което сочат повечето изисквания при обществени поръчки и политики за достъпност. AAA не е постижимо за всяко съдържание, затова го приемайте като амбициозна цел за конкретни страници.

WCAG 2.2 стана препоръка на W3C през октомври 2023 г. Версията надгражда 2.1, вместо да я замества, така че работата, свършена по по-старата версия, остава валидна. Един критерий, 4.1.1 Parsing, беше премахнат като остарял. Ако започвате нов проект, целете се в WCAG 2.2 AA.

Какво добави WCAG 2.2

Новите критерии си струва да знаете поименно, защото улавят проблеми, които по-старите контролни списъци пропускат:

• 2.4.11 Focus Not Obscured (Minimum), AA — фокусираният елемент не трябва да бъде напълно скрит от съдържание, създадено от автора, като залепнала заглавна лента или банер за бисквитки.
• 2.5.7 Dragging Movements, AA — всичко, което се прави чрез плъзгане, например пренареждане на списък или преместване на плъзгач, се нуждае от алтернатива с едно посочващо действие.
• 2.5.8 Target Size (Minimum), AA — целите за посочване трябва да са поне 24 на 24 CSS пиксела или да имат достатъчно пространство около себе си, с няколко изброени изключения.
• 3.2.6 Consistent Help, A — механизмите за помощ, които се повтарят на различни страници, се появяват в един и същ относителен ред.
• 3.3.7 Redundant Entry, A — не карайте хората да въвеждат отново информация, която вече са предоставили в същия процес.
• 3.3.8 Accessible Authentication (Minimum), AA — влизането не трябва да зависи от тест на когнитивна функция, като запомняне или преписване на код, освен ако не е налична алтернатива или помощ (например разрешено поставяне и мениджъри на пароли).

Останалите три нови критерия (2.4.12, 2.4.13 и 3.3.9) са на ниво AAA.

Често срещани модели за достъпност

Започнете със семантичен HTML. Правилната йерархия на заглавията, елементите за ориентири и етикетите на формите покриват значителна част от изискванията за достъпност. ARIA атрибутите трябва да допълват естествената семантика на HTML, а не да я заместват.

Предпочитайте естествените елементи

Елементът button може да получи фокус, активира се с Enter и Space, излага ролята на бутон и участва във формите. Елемент div с обработчик на кликване не прави нищо от това, докато не го изградите наново на ръка, а повечето ръчно изградени версии пропускат нещо.

<!-- Избягвайте: нужни са role, tabindex и обработчици на клавиши, за да се доближи до естествения бутон -->
<div class="btn" onclick="save()">Save</div>

<!-- Предпочитайте: клавиатура, фокус и семантика са включени -->
<button type="button" onclick="save()">Save</button>

Същото важи за връзките (a с href за навигация, button за действия), details и summary за разгъване и dialog за модални прозорци. Когато никой естествен елемент не е подходящ, следвайте WAI-ARIA Authoring Practices Guide, вместо да измисляте собствен модел за работа с клавиатура.

Ориентири и заглавия

Потребителите на екранни четци обикновено навигират по ориентири и заглавия, вместо да четат отгоре надолу. Дайте на всяка страница по един main, обвийте навигацията на сайта в nav и използвайте header и footer за банерите на ниво страница. Ако имате повече от един nav, дайте на всеки aria-label, за да могат да се различават.

Заглавията трябва да описват структурата на съдържанието, а не визуалния му размер. Не прескачайте от h2 към h4, защото по-малкият стил изглежда по-добре; вместо това променете стила.

Форми

Всяко поле за въвеждане се нуждае от програмно свързан етикет. Текстът в контейнера (placeholder) не е етикет: той изчезва при въвеждане и често не отговаря на изискванията за контраст. Групирайте свързаните контроли с fieldset и legend и свързвайте подсказките и грешките с техните полета:

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-hint email-error" aria-invalid="true">
<p id="email-hint">We will only use this to send your receipt.</p>
<p id="email-error">Enter an email address in the format name@example.com.</p>

Съобщенията за грешка трябва да казват какво се е объркало и как да се поправи. При изпращане преместете фокуса към обобщение на грешките или към първото невалидно поле, за да не се налага потребителите на клавиатура и екранни четци да гадаят. Атрибутът autocomplete също има значение: той удовлетворява критерий 1.3.5 Identify Input Purpose и намалява писането за всички.

Управление на фокуса

Управлението на фокуса е от решаващо значение за едностраничните приложения. Когато съдържанието се променя динамично, погрижете се фокусът да се премества предвидимо, така че потребителите на екранни четци да разбират какво се е променило. Използвайте области aria-live, за да обявявате динамичните актуализации.

Няколко правила покриват повечето случаи:

• След смяна на маршрута от страна на клиента преместете фокуса към основното заглавие или основната област на новата страница и обновете заглавието на документа.
• Когато се отвори модален прозорец, преместете фокуса в него и го задръжте там; когато се затвори, върнете фокуса към контролата, която го е отворила. Естественият елемент dialog, отворен с showModal(), се грижи за голяма част от това вместо вас.
• Никога не премахвайте индикатора за фокус, без да го замените. Използвайте :focus-visible, за да показвате ясен пръстен за потребителите на клавиатура, без той да се появява при всяко кликване с мишката.
• Областите на живо трябва да съществуват в DOM, преди съдържанието им да се промени, иначе много екранни четци няма да обявят актуализацията. Използвайте aria-live="polite" за съобщения за състояние и запазете assertive за наистина спешните.

Цвят и контраст

Обикновеният текст се нуждае от съотношение на контраста поне 4.5:1 спрямо фона, а едрият текст (приблизително 18pt или 14pt удебелен) — 3:1 (1.4.3). Компонентите на потребителския интерфейс и смисловите графики, като рамките на полетата, пръстените на фокуса и линиите на графиките, се нуждаят от 3:1 спрямо съседните цветове (1.4.11). Проверявайте както светлата, така и тъмната тема; палитра, която минава в едната, често се проваля в другата.

Цветът никога не трябва да бъде единственият начин за предаване на информация (1.4.1). Червената рамка около невалидно поле трябва да бъде придружена от икона или текст; серия в графика трябва да се различава по етикет, шарка или позиция, а не само по оттенък.

Движение и увеличение

Уважавайте предпочитанията на потребителя относно движението. Големите паралакс ефекти и автоматично стартиращите анимации могат да причинят реален дискомфорт на хора с вестибуларни нарушения.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Съдържанието също така трябва да се пренарежда без хоризонтално превъртане при ширина от 320 CSS пиксела (1.4.10) — толкова е широк прозорец от 1280 пиксела при увеличение 400%. Използвайте относителни единици за текста, избягвайте фиксирани височини на текстовите контейнери и никога не забранявайте увеличаването с щипване в мета тага viewport.

Тестване на вашата работа

Автоматизираните инструменти като axe-core и Lighthouse улавят само част от проблемите с достъпността. Те са отлични при обективни проверки като липсващи етикети, невалидни ARIA атрибути и недостатъчен контраст, но не могат да ви кажат дали алтернативният текст е смислен, дали редът на фокуса е логичен или дали едно взаимодействие е разбираемо. Ръчното тестване с навигация от клавиатура и екранни четци (VoiceOver, NVDA, JAWS) е от съществено значение за улавянето на останалото. Включвайте хора с увреждания в потребителските си проучвания за най-точна обратна връзка.

Рутина, която се вписва в разработката

1. Линтер и модулни тестове. Използвайте линтер за достъпност за вашия фреймуърк и добавете автоматизирани проверки с axe към тестовете на компонентите и end-to-end тестовете, така че регресиите да провалят компилирането.
2. Проверка с клавиатура. Изключете мишката. Преминете през страницата с Tab: можете ли да достигнете и да използвате всяка контрола, винаги ли е видим индикаторът за фокус и логичен ли е редът?
3. Увеличение и пренареждане. Увеличете до 200% и 400%. Нищо не трябва да се припокрива, да се отрязва или да изисква превъртане в две посоки.
4. Бърза проверка с екранен четец. Изберете критичния път — регистрация, плащане, основното табло — и го преминете с екранен четец. Слушайте за бутони без етикети, необявени грешки и объркващ ред на четене.
5. Проверка на предпочитанията. Включете намаленото движение, принудителните цветове (Windows High Contrast) и тъмния режим и се уверете, че нищо важно не изчезва.

Как да го направите трайно

Достъпността обикновено се проваля постепенно: функционалност, добавена месеци по-късно, тихомълком разваля задържането на фокуса в модален прозорец. Няколко навика предотвратяват това:

• Включвайте критерии за приемане по отношение на достъпността в задачите, а не в отделен backlog за одити.
• Вградете моделите в общите компоненти, така че продуктовите екипи да получават правилно поведение по подразбиране.
• Публикувайте декларация за достъпност, в която се посочва на какво съответствате, кои известни проблеми остават и как хората могат да съобщават за проблеми.

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