Какво е новото в WCAG 2.2? Деветте нови критерия на разбираем език

Човек, който ползва клавиатура, минава с Tab през страницата ви за плащане. Фокусът попада върху бутона „Плащане“, но върху него стои фиксиран банер за бисквитки и човекът не вижда къде се намира. По WCAG 2.1 тази страница все още можеше да мине. По WCAG 2.2 тя не отговаря на изискванията.

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

Какво е WCAG 2.2?

WCAG 2.2 е актуалната версия на Указанията за достъпност на уеб съдържанието (Web Content Accessibility Guidelines) – стандартът на W3C, към който препращат повечето закони и договори за достъпност. Тя стана препоръка на W3C на 5 октомври 2023 г. (отваря се в нов раздел), беше актуализирана на 12 декември 2024 г. (отваря се в нов раздел) и през октомври 2025 г. беше одобрена като ISO/IEC 40500:2025 (отваря се в нов раздел).

WCAG се състои от проверими твърдения, наречени критерии за успех, всеки със свое ниво: A (минимумът), AA (това, което законите обикновено изискват) или AAA (най-строгото). „Трябва ни WCAG 2.2 AA“ означава всички критерии от ниво A и AA във версия 2.2. Според спецификацията 2.2 „надгражда WCAG 2.1 и е обратно съвместима с нея“, тоест допълва 2.1, а не я заменя.

Какво се промени от WCAG 2.1 към 2.2?

WCAG 2.2 добавя девет критерия за успех и премахва един. Шест от новите са на ниво A или AA, така че влизат в обичайната цел AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 и 3.3.8. Останалите три са AAA. Премахнатият критерий е 4.1.1 Синтактичен анализ (Parsing), който W3C вече определя като остарял. Официален превод на WCAG 2.2 на български няма, затова в таблицата до нашия превод даваме и оригиналното име на критерия.

Критерий 4.1.1 проверяваше за грешки в маркировката, например повтарящи се ID. Често задаваните въпроси за WCAG 2 (отваря се в нов раздел) обясняват, че тези проблеми вече попадат под други критерии, например 4.1.2 Име, роля, стойност. Една уловка: ако договор все още изисква WCAG 2.0 или 2.1, може да се наложи „да продължите да тествате и да докладвате 4.1.1“.

Незакрит фокус и вид на фокуса: виждат ли потребителите на клавиатура къде се намират?

Тези критерии пазят елемента с фокус от клавиатурата видим. На ниво AA (2.4.11) връзка или бутон на фокус не бива да са изцяло скрити от съдържание, добавено от вас, например фиксирана горна лента, банер за бисквитки или балонче за чат. На ниво AAA нищо не бива да закрива която и да е част от тях (2.4.12), а очертанието на фокуса трябва да е голямо и ясно контрастно (2.4.13).

• На кого помага: на хора с нормално зрение, които ползват клавиатура вместо мишка, често заради двигателно увреждане. Ако не виждат фокуса, те налучкват.
• Бърза проверка: отворете дълга страница, на която едновременно се виждат банерът за бисквитки, фиксираната горна лента и чатът, и натискайте Tab многократно. Ако фокусът изчезне изцяло зад нещо, това е нарушение на 2.4.11.
• Обичайно решение: добавете в CSS отстъп при превъртане (scroll padding), равен на височината на фиксираната горна или долна лента, за да може браузърът да превърта елементите на фокус извън нея. W3C посочва това като достатъчна техника (отваря се в нов раздел). Банерът може да мине и ако е модален и трябва първо да бъде затворен.

Видът на фокуса (2.4.13) изисква индикатор, който е поне толкова голям, колкото очертание с дебелина 2 CSS пиксела около компонента, с контраст от поне 3:1 между състоянието на фокус и без фокус. Критерият е AAA, но плътно очертание от 2 пиксела в наситен цвят обикновено го покрива. Нашето ръководство за цветовия контраст обяснява как се измерва 3:1.

Движения с плъзгане и размер на целта: може ли сайтът ви да се ползва без точно посочване?

Тези два критерия от ниво AA помагат на хората, които трудно управляват показалеца прецизно. 2.5.7 казва, че всичко, което може да се направи с плъзгане, трябва да работи и с единични щраквания или докосвания. 2.5.8 казва, че целите трябва да са поне 24 на 24 CSS пиксела или да са разположени така, че кръг с диаметър 24 пиксела, центриран върху всяка от тях, да не докосва друга цел.

2.5.7 Движения с плъзгане

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

Бърза проверка: изпълнете всяко действие с плъзгане само с щраквания или докосвания. Обичайно решение: позволете щракване навсякъде по пътечката на плъзгача, добавете полета „мин.“ и „макс.“ до него или бутони „Нагоре“ и „Надолу“ в подредимите списъци. Самата поддръжка на клавиатура не е достатъчна: обяснителният документ (отваря се в нов раздел) на W3C казва, че еквивалентът с клавиатура „не изпълнява автоматично този критерий за успех“.

2.5.8 Размер на целта (минимум)

Обичайните нарушения са малки бутони „×“ на изскачащи прозорци, плътно наредени номера на страници, звезди за оценка и редици от икони на социални мрежи. Докосването на грешната цел дразни всеки, а за хората с ограничена сръчност е истинска бариера.

• Изключения: връзки в текста на изречение, цели, за които на страницата има равностоен елемент с достатъчен размер, елементи, чийто размер се определя от браузъра и които не сте стилизирали, както и случаи, в които конкретният размер е от съществено значение или се изисква по закон.
• Бърза проверка: на телефон докоснете всяка малка икона и бутон; за да измерите някой от тях, разгледайте го с инструментите за разработчици на браузъра.
• Обичайно решение: добавете вътрешен отстъп (padding). Площта за щракване расте, дори иконата да изглежда същата. И приемайте 24 пиксела като долна граница: по-старият критерий 2.5.5 от ниво AAA изисква 44 на 44.

Последователна помощ и излишно въвеждане: карате ли хората да търсят или да се повтарят?

И двата критерия са от ниво A. 3.2.6 Последователна помощ казва, че ако помощ, например данни за контакт, чат или връзка към често задавани въпроси, се появява на няколко страници, тя трябва всеки път да стои в един и същ ред спрямо останалата част от страницата. 3.3.7 Излишно въвеждане казва, че хората не бива да въвеждат отново данни, които вече са дали в същия процес.

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

Излишното въвеждане засяга формулярите с няколко стъпки. Формуляр за резервация, който иска имейла ви на стъпка 1 и отново на стъпка 3, не отговаря на критерия, както и страница за плащане, която ви кара да въведете отново същия адрес за фактуриране. Попълнете полето автоматично или позволете на хората да го изберат, например с отметка „Адресът за фактуриране съвпада с адреса за доставка“. Изключенията: повторното въвеждане е от съществено значение, необходимо е от съображения за сигурност или предишните данни вече не са валидни.

Достъпно удостоверяване: могат ли хората да влязат без тест за памет?

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

WCAG определя теста на когнитивните функции като „задача, която изисква от потребителя да запомни, обработи или препише информация“. Въвеждането на име, имейл адрес или телефонен номер не се брои, защото тези данни са лични и навсякъде са едни и същи. Стъпката за вход отговаря на ниво AA, ако предлага поне едно от следните:

• Алтернатива без когнитивен тест, например ключ за достъп (passkey) или връзка, изпратена по имейл.
• Механизъм, който помага, например поддръжка на мениджъри на пароли или копиране и поставяне, за да не се налага еднократният код да се преписва.
• Разпознаване на обекти, например „изберете снимките с велосипед“.
• Лично съдържание, например разпознаване на снимка, която сами сте качили.

Версията AAA, 3.3.9, премахва последните две възможности, така че CAPTCHA със снимки може да мине на ниво AA, но не и на AAA. Типични нарушения: полета за парола, които блокират поставянето или мениджърите на пароли, полета за еднократен код, които се „чупят“ при поставяне, и текстова CAPTCHA без алтернатива. Най-много печелят хората с дислексия или с нарушения на паметта, но проблемът е познат на всеки, който след дълъг ден е останал без достъп до профила си.

Задължителна ли е WCAG 2.2 по закон?

Зависи къде сте и кои сте. Законите рядко назовават пряко версия на WCAG, а много от тях все още препращат към WCAG 2.1 AA. Тъй като WCAG 2.2 е обратно съвместима, изпълнението на 2.2 AA означава и изпълнение на 2.1 AA, с изключение на премахнатия 4.1.1. Целта 2.2 покрива и двете. Ако в договор е посочена версия, следвайте договора.

• Европейски съюз: според Европейския акт за достъпност съответствието се презумира, когато изпълнявате хармонизирания стандарт EN 301 549. Според AccessibleEU (отваря се в нов раздел) версия 4.1.1, публикувана през септември 2026 г., възприема WCAG 2.2, но все още не е правно приложимата референция; докато не бъде цитирана в Официален вестник на ЕС, се прилага v3.2.1 (основана на WCAG 2.1 AA). Нашият наръчник за Европейския акт за достъпност обяснява за кого се прилага актът.
• Обединеното кралство: правителствените указания (отваря се в нов раздел) посочват, че уебсайтовете и приложенията на публичния сектор трябва да отговарят на WCAG 2.2 AA. Тези указания се отнасят за публичните органи, а не за частния бизнес.
• Съединените щати: правилото на Министерството на правосъдието за щатските и местните власти използва WCAG 2.1 AA, като сроковете за съответствие бяха изместени през април 2026 г. (отваря се в нов раздел) на 26 април 2027 г. и 26 април 2028 г. За частния бизнес указанията на министерството от 2022 г. (отваря се в нов раздел) посочват, че ADA се прилага за техните уебсайтове, но не определят конкретен технически стандарт.

А какво става с WCAG 3?

WCAG 3 е чернова, така че засега никой не може да ѝ съответства. W3C публикува актуализирани чернови през септември 2026 г. и посочва, че WCAG 3 не се очаква да стане завършен стандарт „още няколко години“. WCAG 2 няма да бъде обявена за остаряла още няколко години след това, така че 2.2 е версията, по която да работите сега.

Как да проверите новите критерии за 15 минути?

Повечето нарушения на шестте критерия от ниво A и AA можете да откриете за около 15 минути с клавиатура, телефон и собствената си страница за вход. Това няма да замени пълен одит или тестване с хора с увреждания, но ще ви покаже откъде да започнете и ще даде на разработчика конкретен списък за работа.

1. Минете с Tab през началната страница, една продуктова страница и страницата за плащане, докато всички банери се виждат. Винаги ли виждате фокуса? (2.4.11)
2. Използвайте всеки плъзгач и изпълнете всяко действие с плъзгане и пускане само с щраквания или докосвания. (2.5.7)
3. На телефон опитайте всеки бутон за затваряне, номер на страница и малка икона. (2.5.8)
4. Сравнете къде се появяват помощта и данните за контакт на три вида страници. (3.2.6)
5. Минете през покупка или резервация и отбележете всеки въпрос, на който отговаряте два пъти. (3.3.7)
6. Влезте с мениджър на пароли, след това поставете парола и еднократен код. Има ли алтернатива всяка CAPTCHA? (3.3.8)

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

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