Чести грешки в достъпността, които да избягвате

Защо едни и същи проблеми с достъпността се появяват отново и отново

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

Този каталог преминава през най-честите нарушения на WCAG 2.2, които виждаме в реални одити. За всяко ще откриете защо има значение, кого засяга, съответния критерий за успех и конкретна корекция преди и след. Заедно тези проблеми представляват преобладаващата част от бариерите, които блокират хората с увреждания — и преобладаващата част от правните жалби, подадени по силата на European Accessibility Act, ADA и Section 508.

Едно нещо да изясним преди списъка: автоматичните инструменти не могат да открият всички тези проблеми. Независимите изследвания последователно показват, че дори най-добрите скенери надеждно откриват само 30–40 % от проблемите с WCAG. Те са отлични в улавянето на липсващи alt атрибути, програмни грешки в контраста и липсващи етикети на формуляри, но не могат да преценят дали алтернативният текст е точен, дали редът на фокуса е логичен или дали персонализиран компонент действително работи с екранен четец. Ето защо всяка надеждна програма съчетава сканирането с ръчен преглед. Нашият софтуер за сканиране на достъпността се грижи за автоматизируемия слой; ръчните одити и одитите, извършвани от хора с увреждания, покриват останалото.

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

Възприемаемост: съдържание, което хората не могат да видят или прочетат

Липсващ или неточен алтернативен текст за изображения

Кого засяга: хора, които са слепи или с ниско зрение и използват екранни четци; всеки с бавна връзка, при който изображенията не се зареждат.

Критерий по WCAG: 1.1.1 Нетекстово съдържание (Ниво A).

Изображения без alt атрибут са невидими за помощните технологии — потребителят може дори да не знае, че изображението съществува. По-лошо от липсващ атрибут е неточният: имена на файлове като IMG_4821.jpg, общи думи като „изображение” или низове, претъпкани с ключови думи, активно подвеждат слушателя.

Правилото е просто, но зависи от ситуацията. Информативните изображения се нуждаят от кратко описание на тяхното значение, а не на външния им вид. Декоративните изображения, които не добавят нищо, трябва да носят празно alt="", така че екранните четци да ги пропускат. Функционалните изображения — икона, която действа като бутон — трябва да описват действието, а не картината. Сложните визуални елементи като диаграми се нуждаят от кратък alt плюс по-дълъг текстов еквивалент наблизо.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

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

Недостатъчен цветови контраст

Кого засяга: хора с ниско зрение, далтонизъм или свързана с възрастта загуба на зрение; всеки, който използва екран на ярка слънчева светлина.

Критерий по WCAG: 1.4.3 Контраст (минимум), Ниво AA; плюс 1.4.11 Нетекстов контраст за компоненти на интерфейса.

WCAG 2.2 изисква съотношение на контраста от поне 4,5:1 за нормален текст и 3:1 за голям текст (приблизително 18 pt или 14 pt получер). Компонентите на интерфейса и значимата графика — рамки на полета за въвеждане, индикатори за фокус, икони, които предават състояние — трябва да достигат 3:1 спрямо заобикалящата ги среда. Грешките в контраста са сред най-честите проблеми, откривани във всеки мащабен одит, и почти винаги се въвеждат на етапа на проектиране.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Тествайте цялата палитра, не само основния текст: текстът на контейнера (placeholder), деактивираните състояния, които все пак трябва да се четат, съобщенията за грешка и текстът, поставен върху снимки, са чести нарушители. Никога не разчитайте само на цвета, за да предадете значение (1.4.1) — червена рамка на невалидно поле трябва да бъде придружена от текст или икона.

Автоматично възпроизвеждащи се медии и движение

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

Критерии по WCAG: 1.4.2 Контрол на звука (Ниво A), 2.2.2 Пауза, спиране, скриване (Ниво A), 2.3.1 Три проблясъка (Ниво A) и 2.3.3 Анимация от взаимодействия (Ниво AAA).

Аудио или видео, което се възпроизвежда автоматично за повече от три секунди, трябва да предлага очевиден начин за пауза или заглушаване. Движещо се, мигащо или автоматично обновяващо се съдържание, продължаващо повече от пет секунди — въртележки, анимирани банери, бягащи редове — се нуждае от достъпен контрол за пауза. Съдържание, което проблясва повече от три пъти в секунда, може да предизвика гърчове и трябва изцяло да се избягва. Зачитайте настройката prefers-reduced-motion на потребителя, за да намалите несъществената анимация.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Управляемост: неща, които хората не могат да използват

Недостъпност чрез клавиатура и клавиатурни капани

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

Критерии по WCAG: 2.1.1 Клавиатура (Ниво A) и 2.1.2 Без клавиатурен капан (Ниво A).

Всяко взаимодействие — връзки, бутони, полета на формуляри, менюта, модални прозорци, селектори на дати, плъзгане и пускане — трябва да бъде напълно управляемо само с клавиатурата. Най-вредният вариант е клавиатурният капан: фокусът влиза в компонент (често модален прозорец или вграден компонент) и не може да излезе, оставяйки потребителя блокиран на страницата. Персонализираните компоненти са обичайните виновници, защото нативните елементи като <button> и <a> са управляеми с клавиатура по подразбиране, докато имитациите, базирани на <div>, не са.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Преминете през ключовите си пътеки, използвайки само Tab, Shift+Tab, клавишите със стрелки, Enter, Space и Escape. Потвърдете, че фокусът винаги може да се движи напред и да излиза от всеки компонент, че Escape затваря наслоените елементи и че нищо не изисква показалец. Нашата услуга за оценка с екранен четец тества точно тези потоци така, както ги изживяват реалните потребители на помощни технологии.

Липсващи или невидими индикатори за фокус и нелогичен ред на фокуса

Кого засяга: виждащи потребители на клавиатура, потребители с ниско зрение и всеки, който е загубил представа къде се намира на страницата.

Критерии по WCAG: 2.4.7 Видим фокус (Ниво A) и 2.4.3 Ред на фокуса (Ниво A); 2.4.11 Незакрит фокус (Ниво AA) във WCAG 2.2.

Честа „подреждаща” грешка е премахването на стандартния пръстен за фокус на браузъра с outline: none и никога да не бъде заменен. Потребителите на клавиатура нямат представа кой елемент е активен. Също толкова вреден е редът на фокуса, който не следва визуалния и логичния ред на четене — обикновено причинен от положителни стойности на tabindex или от ред в DOM, който се различава от изобразеното оформление.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 добавя 2.4.11: когато елемент получи фокус, той не трябва да бъде напълно скрит зад фиксирани заглавки, банери за бисквитки или чат компоненти. Отворете модален прозорец, преминете през него с Tab и потвърдете, че фокусираният елемент никога не е затрупан.

Неописателни връзки и бутони

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

Критерии по WCAG: 2.4.4 Цел на връзката (в контекст), Ниво A; 2.5.3 Етикет в името, Ниво A.

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

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Претоварена навигация и без начин за прескачането ѝ

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

Критерий по WCAG: 2.4.1 Заобикаляне на блокове (Ниво A).

Мега меню с десетки връзки принуждава потребителите на екранни четци и клавиатура да преминават през целия списък на всяка страница, преди да достигнат съдържанието. Връзка „Прескочи към основното съдържание” като първи фокусируем елемент им позволява да прескочат директно над повтарящите се блокове. Групирайте свързаните елементи, поддържайте менютата стегнати и се уверете, че връзката за прескачане става видима при фокус.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Разбираемост: съдържание, което обърква

Неозначени или неправилно свързани полета на формуляри

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

Критерии по WCAG: 1.3.1 Информация и взаимовръзки, 3.3.2 Етикети или инструкции и 4.1.2 Име, роля, стойност (всички Ниво A).

Полета за въвеждане без програмно свързан <label> се обявяват като „редактиране на текст, празно” — потребителят няма представа какво да въведе. Текстът на контейнера (placeholder) не е заместител: той изчезва при въвеждане и обикновено не отговаря на изискванията за контраст. Задължителните полета, правилата за форматиране и грешките при валидиране също трябва да се предават в текст, а не само чрез цвят или позиция.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Свържете съобщенията за грешка с тяхното поле чрез aria-describedby, маркирайте невалидните полета с aria-invalid и се уверете, че изпращането на непълен формуляр премества фокуса към първата грешка.

Липсващ език на страницата

Кого засяга: потребители на екранни четци — грешният език кара синтезатора да произнася всичко неправилно.

Критерии по WCAG: 3.1.1 Език на страницата (Ниво A) и 3.1.2 Език на части (Ниво AA).

Един-единствен липсващ атрибут разваля произношението на цяла страница. Декларирайте основния език на коренния елемент и маркирайте вградените пасажи на друг език със собствен lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Неправилна йерархия на заглавията и липсващи ориентири

Кого засяга: потребители на екранни четци, които навигират по заглавия и региони, и всеки, който разчита на структурата на документа.

Критерий по WCAG: 1.3.1 Информация и взаимовръзки (Ниво A).

Заглавията са структурата на страницата. Потребителите на екранни четци прескачат от заглавие на заглавие, за да намерят бързо съдържание; когато нивата се пропускат, използват се само за размер на шрифта или липсват, тази навигация се срива. Всяка страница трябва да има едно <h1> и логична, непрекъсната последователност от <h2>, <h3> и т.н. Също толкова важни са регионите-ориентири — <header>, <nav>, <main>, <footer> — които позволяват на потребителите да прескачат между основните области. Страница, изградена изцяло от <div> елементи, не предлага такава карта.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Устойчивост: код, който помощните технологии не могат да интерпретират

Недостъпни персонализирани компоненти и неправилно използван ARIA

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

Критерий по WCAG: 4.1.2 Име, роля, стойност (Ниво A).

Персонализирани падащи менюта, раздели, акордеони, комбинирани полета, модални прозорци и подсказки, изградени от <div> и <span>, нямат присъща роля, състояние или поведение при клавиатура. Разработчиците посягат към ARIA, за да закърпят това, но ARIA само описва — той не добавя поведение, а неправилният ARIA е по-лош от никакъв. Първото правило на ARIA е да се предпочита нативен HTML елемент винаги, когато съществува такъв. Когато трябва да изградите персонализиран компонент, реализирайте пълното клавиатурно взаимодействие, което определят шаблоните за разработка на ARIA, и поддържайте aria-expanded, aria-selected и подобни състояния в синхрон с реалността.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Това са точно проблемите, които автоматичните скенери пропускат най-често. Скенерът вижда атрибут aria-expanded и го одобрява; само човек (или тестващ, използващ екранен четец) може да потвърди, че стойността действително се променя, когато менюто се отвори. Вижте нашето ръководство за тестване с екранен четец за това как да проверите поведението на компонентите от край до край.

Бележка относно наслоените компоненти (overlay)

Изкушаващо е да инсталирате „компонент за достъпност” или наслояване на един ред, който обещава мигновено съответствие. Тези инструменти не отстраняват проблемите по-горе — алтернативният текст все още липсва в кода, контрастът все още е недостатъчен, персонализираният компонент все още не работи. Наслояванията не могат да поправят кода, който причинява бариерите, те често пречат на собствените помощни технологии на потребителите и са се появявали в нарастващ брой съдебни дела за достъпност. Истинската дигитална достъпност идва от поправянето на основния HTML, CSS и поведение, а не от маскирането им.

Спрете тези проблеми да се връщат

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

Уловете автоматизируемите 30–40 % рано, като свържете сканиранията към вашия конвейер. Интеграцията на достъпността в CI/CD проваля компилацията, когато бъде въведена регресия, преди тя да достигне продукция.
Покрийте останалото с хора. Планирайте ръчни одити на достъпността и одити от хора с увреждания, които изваждат наяве бариери, които никой инструмент не може да открие.
Дайте на екипите подходящите инструменти. Наборът инструменти за достъпност на QualiBooth и Agora помагат на дизайнери и разработчици да тестват, докато работят.
Превърнете го в процес, а не в проект. Постоянното консултиране по достъпност и подобряването на процеса за достъпност вграждат навиците, така че качеството да се запазва във времето.

За пътна карта за отстраняване стъпка по стъпка започнете с нашето ръководство за това как да направите уебсайта си съвместим с WCAG.

Откъде да започнете днес

С над 1,3 милиарда души по света, които живеят с някаква форма на увреждане, бизнес аргументите за достъпността са ясни — а от юни 2025 г. са ясни и правните аргументи съгласно European Accessibility Act. Проблемите в този каталог са онези, които се разглеждат първи при всяка жалба или одит.

Най-бързият начин да видите къде се намирате е да стартирате безплатно сканиране на URL — без настройка, без ангажимент. Когато сте готови да надхвърлите това, до което може да достигне автоматизацията, заявете демонстрация и ще ви покажем как комбинирана програма от автоматизация и ръчен преглед затваря оставащата празнина.