Степен на приемане на WCAG 2.2: къде препоръката е и къде не е навлязла в правото, обществените поръчки и одитната практика — проучване за 2026 г.
W3C публикува WCAG 2.2 като препоръка на 5 октомври 2023 г. Две години и половина по-късно това е версията, спрямо която всеки реномиран одитор се отчита, и версията, която всяка голяма дизайн система поне отчасти е усвоила — но все още не е версията, която по-голямата част от правото за достъпност в света всъщност цитира. Забавянето се проявява на девет конкретни места: деветте нови критерия за успех. Този полеви справочник каталогизира всеки от тях.
Предходните части от тази поредица картографираха картината на правните референции отгоре надолу — юрисдикция по юрисдикция, закон по закон. Тази гледна точка е полезна за служителите по съответствие и ръководителите на обществени поръчки. Тя е по-малко полезна за разработчика, дизайнера или продуктовия мениджър, който трябва да достави реалната работа по отстраняване на проблеми. Този справочник възприема обратната гледна точка: той изхожда от критерия за успех навън.
Всяка от позициите по-долу е един от деветте нови критерия за успех на WCAG 2.2 — точните редакции, които работната група направи в предходната препоръка. За всеки от тях описваме какво изисква критерият на ясен език, колко често полето всъщност улавя провала в одитите от 2026 г., механизма на производствения сайт, който го задейства, и инженерната поправка. Всяка позиция следва една и съща анатомия, в един и същ ред, така че каталогът се чете отгоре надолу или чрез прескачане.
9 нови критерия за успех · подредени по честота на одитни провали за 2026 г.
| ID | Образец (КУ + наименование) | Ниво | Честота на одитни провали |
|---|---|---|---|
| E·01 | 2.4.13 Поява на фокуса | AAA | >70% |
| E·02 | 2.5.8 Размер на целта (минимум) | AA | Водещ провал на AA |
| E·03 | 3.3.8 Достъпна автентикация (мин.) | AA | AA с най-голямо въздействие |
| E·04 | 2.4.11 Фокусът не е закрит (мин.) | AA | Топ 5 на AA |
| E·05 | 2.5.7 Движения с влачене | AA | Тясна повърхност |
| E·06 | 3.3.7 Повтарящо се въвеждане | A | Поправка от страна на сървъра |
| E·07 | 3.2.6 Последователна помощ | A | Редакционна |
| E·08 | 2.4.12 Фокусът не е закрит (разш.) | AAA | По-строг роднина на E·04 |
| E·09 | 3.3.9 Достъпна автентикация (разш.) | AAA | По-строг роднина на E·03 |
Описателите на честотата на провалите са агрегирани от независими одиторски доклади, издадени до първото тримесечие на 2026 г.; методологиите варират между кантори, така че цифрите са по-скоро ориентировъчни, отколкото точни. Пет от деветте критерия са на ниво AA — регулаторно обвързващото ниво — и са редовете, с които клаузите за обществени поръчки трябва да се справят първи.
Къде всъщност се вижда забавянето
Правното включване на WCAG става чрез фиксиране на версия. Дадена нормативна уредба не казва „текущата WCAG“; тя казва WCAG 2.0 или WCAG 2.1, с ниво и дата. Актуализирането на фиксирането е акт на законово или регулаторно изменение. Към средата на 2026 г. големите регулации за достъпност в света все още са разпределени между три версии: американският Section 508 на 2.0; EU EN 301 549 V3.2.1 на 2.1; PSBAR на Обединеното кралство на 2.1 (с висяща приключила консултация от февруари 2026 г.). Прагматичният компромис от средата на десетилетието — „WCAG 2.1 AA като минимум, с отчитане по VPAT 2.5 спрямо 2.2, където отговорът на доставчика позволява“ — се превърна в рутинен език за обществени поръчки.
Обществените поръчки се движат по-бързо от правото. Шаблонът VPAT 2.5 / ACR на ITI, пуснат през януари 2025 г., добави колони за отчитане за всеки от деветте нови критерия; всеки VPAT, издаден след тази дата спрямо WCAG версията на шаблона, се отчита спрямо 2.2. Приемането от страна на дизайн системите на големите технологични компании се движи най-бързо от всичко — Microsoft, Apple HIG, Material 3, Adobe Spectrum и Meta всички се приведоха в съответствие с 2.2 през 2024–25 г. Каталогът, който следва, е инженерният аналог: деветте конкретни редакции, които работната група направи, и какво те всъщност улавят в продукцията.
Пет от деветте нови критерия за успех са AA — това са регулаторно обвързващите, редовете, които клауза за обществени поръчки от 2026 г. не може да избегне.
Индикаторите на фокуса бяха първата грижа на работната група в заданието за 2.2. Два критерия разглеждат дали пръстенът на фокуса някога е скрит от съдържание на автора; трети уточнява самия индикатор. Заедно те улавят най-пренебрегваната подповърхност на всяко клавиатурно пътуване.
Поява на фокуса — 2.4.13 AAA
Когато компонент на потребителския интерфейс получи клавиатурен фокус, индикаторът на фокуса трябва да отговаря на минимално съотношение на контраст 3:1 спрямо съседния цвят и да покрива поне периметъра на плътен контур от 2 CSS пиксела около фокусирания елемент или еквивалентна площ на индикатора. Критерият е едно от малкото допълнения към WCAG, които уточняват измерима геометрия, а не поведение.
Пръстените на фокуса по подразбиране на браузъра, които дизайнерите петнайсет години презаписваха по естетически причини, се провалят на това измерване при по-голямата част от одитираните производствени сайтове. Потребителските стилове на фокуса обикновено използват контури от 1px или нискоконтрастни акцентни цветове, които изглеждат правилно в дизайнерските инструменти, но получават резултат под 3:1 спрямо фона на реално фокусирания елемент.
Цифрата има значение, въпреки че критерият е AAA: тя показва какво би се случило, ако бъдещ регулатор фиксира на WCAG 2.2 ниво AAA или ако договор за обществена поръчка издигне точно този критерий.
Задайте контур от 2 CSS пиксела с цвят, получаващ поне 3:1 спрямо фона на елемента; проверете с инструмент за контраст, а не на око. Където дизайн системата презаписва фокуса на браузъра, изложете токен за стил на фокуса, който дизайнерите не могат случайно да понижат под прага на контраста.
Размер на целта (минимум) — 2.5.8 AA
Целта за докосване на всеки вход с показалец трябва да е поне 24 на 24 CSS пиксела, освен когато целта е вградена в изречение, когато е оразмерена от потребителския агент, когато е налична еквивалентна цел или когато функцията на целта е съществена. Критерият измерва целта за докосване, а не видимата икона.
Критерият улавя конкретен UI модел: плътни иконни ленти с инструменти, особено в редактори, табла за управление и заглавия на таблици с данни. Повечето библиотеки с иконни бутони по подразбиране имат визуални размери на иконите 16×16 или 20×20 в рамките на леко по-голяма цел за докосване. Където целта за докосване също е под 24×24, критерият се проваля — а дизайнерите на ленти с инструменти рутинно стесняват разстоянията, за да съберат повече икони в ограничено хоризонтално пространство.
Задайте токен за минимална цел за докосване от 24 на 24 CSS пиксела в дизайн системата, приложен чрез padding, а не чрез собствените размери на иконата. Където лентите с инструменти не могат да поберат пода, добавете достатъчно разстояние, така че съседните цели да не са в рамките на изключването за припокриване на критерия. Осигурете еквивалент на ниво настройки (по-голямо меню) за наистина претъпканите повърхности.
Достъпна автентикация (минимум) — 3.3.8 AA
Стъпката за автентикация на уебсайт или приложение не може да разчита на тест на когнитивна функция — решаване на пъзел, преписване на изкривено изображение, разпознаване на обекти в мрежа — освен ако не е осигурен алтернативен метод за автентикация, не е налично помощно средство или не се прилага изключение за разпознаване на обекти. Запаметяването на парола се счита за тест на когнитивна функция, поради което мениджърите на пароли са изрично допуснати.
Повечето базирани на изображения CAPTCHA се провалят по същество. Същото важи и за предизвикателствата „щракнете върху квадратите със светофари“, тестовете за преписване на изкривен текст и всеки поток, който поставя еднократен код в поле, но деактивира взаимодействието с поставяне. Моделът е концентриран в потоците за вход, нулиране на парола и създаване на акаунт — точно високорисковите точки, в които заключването навън има най-голяма цена.
Потоците за автентикация са и областта, в която ухапването на критерия е най-остро, защото провалът не влошава изживяването — той го прекратява.
Заменете CAPTCHA с когнитивна функция с некогнитивна алтернатива — атестация, базирана на устройство, магически връзки, ключове за достъп (passkeys) или невидимо оценяване на риска. Разрешете автоматичното попълване от мениджъра на пароли. Уверете се, че копирането и поставянето работи в полетата за еднократен код. Където CAPTCHA трябва да остане, осигурете аудио алтернатива, която сама по себе си не изисква преписване на изкривена реч.
Нивото AA е жицата под напрежение
Пет от деветте нови критерия са на ниво AA: 2.4.11 Фокусът не е закрит (мин.), 2.5.7 Движения с влачене, 2.5.8 Размер на целта (мин.), 3.3.8 Достъпна автентикация (мин.) и (сдвоена с 3.3.8 на AAA, 3.3.9). Това са критериите, които клауза за обществени поръчки не може да избегне, и редовете, в които разликата между съответствие с WCAG 2.1 AA и съответствие с WCAG 2.2 AA е най-измерима. Двете допълнения на ниво A (3.2.6 Последователна помощ, 3.3.7 Повтарящо се въвеждане) са по-лесни печалби. Двете допълнения на ниво AAA (2.4.12 и 3.3.9) са аспирационни затягания на двойките на ниво AA.
Фокусът не е закрит (минимум) — 2.4.11 AA
Когато компонент на потребителския интерфейс получи клавиатурен фокус, фокусираният елемент не трябва да бъде изцяло скрит от съдържание, създадено от автора. Частичното закриване е разрешено на това ниво (заглавна лента с фиксирана позиция, припокриваща горната половина на фокусирано поле, е допустима); пълното закриване не е.
Най-честият сблъсък е заглавна лента с фиксирана позиция — понякога банер за бисквитки или плаващ чат джаджа — която припокрива фокусираното поле на формуляра, когато потребител на клавиатура премине в него с табулатор. Производствени сайтове, които наслоиха заглавна лента с фиксирана позиция върху съществуващ формуляр по време на ерата на редизайните от 2020–22 г., рутинно пропускаха поведението на фокусиране и превъртане, защото оригиналният формуляр беше създаден, преди да съществуват елементи с фиксирана позиция.
Задайте scroll-margin-top (или scroll-padding-top на контейнера за превъртане) равен на височината на всяко наслагване с фиксирана позиция. Тествайте, че преминаването с табулатор през дълъг формуляр превърта фокусирания елемент изцяло във видимото поле под всяка заглавна лента. Съчетайте това с видими стилове на фокуса, така че потребителят да вижда къде фокусът всъщност е попаднал.
Заданието за моторна достъпност в WCAG 2.2 се сведе до два критерия, и двата на ниво AA. Единият улавя UI за пренареждане на списъци, които изискват продължително влачене; другият (E·02 по-горе) улавя плътни иконни ленти с инструменти. Те споделят обща причина — дизайн системи, които предполагат прецизен показалец.
Движения с влачене — 2.5.7 AA
Функционалност, която използва движение с влачене, трябва да е операбилна и чрез действие с единичен показалец — докосване, щракване или еквивалент, който не изисква продължително движение на показалеца. Взаимодействията с влачене и пускане не са забранени; те просто не могат да бъдат единственият наличен път до функцията.
UI за пренареждане на списъци и в канбан стил често се доставят с пренареждане само чрез влачене. Същото важи за контролите плъзгачи, реализирани като влачими бутончета без съответен спинбутон или текстов вход, и за UI за изрязване на изображения, които изискват влачене за задаване на границите. Критерият улавя тези всеки път.
За всяко взаимодействие с влачене доставете еквивалентна алтернатива с докосване/щракване — бутони „премести нагоре“ и „премести надолу“ до влачимите елементи на списъка, числов вход до плъзгач, режим за задаване на границите с щракване в инструмента за изрязване. Където алтернативата е скрита в контекстно меню, уверете се, че е достижима чрез клавиатура.
Останалите четири критерия попадат в две двойки: двете редакционни допълнения на ниво A (Повтарящо се въвеждане и Последователна помощ) и двете затягания на ниво AAA (Фокусът не е закрит — разширено, Достъпна автентикация — разширено). Заедно те закръгляват заданието на 2.2 за достъпност при когнитивно натоварване.
Повтарящо се въвеждане — 3.3.7 A
В рамките на един и същ автентикиран процес не изисквайте от потребителя да въвежда една и съща информация два пъти — освен ако повторното въвеждане не е съществено, предходният запис вече не е валиден или информацията не засяга сигурността (повторното въвеждане на парола при създаване на акаунт е каноничното изключение). Автоматичното попълване или избирането от предходно въведени стойности също удовлетворяват критерия.
Многостъпковите потоци за плащане, многостраничните формуляри за кандидатстване и заявленията за визи/разрешения рутинно искат един и същ адрес, име или данни за контакт в две отделни стъпки, защото стъпките са изградени от различни екипи и никога не са били съгласувани. Предходно въведените от потребителя стойности не се съхраняват в сесия, споделена между стъпките.
Съхранявайте въведените от потребителя стойности между стъпките на един процес; предварително попълвайте съвпадащите полета в следващите стъпки; или изложете контрол с едно щракване „използвай същия адрес“. Моделът обикновено изплува по време на картографиране на процеса, а не по време на одит на фронтенда, така че междуекипният преглед на потока е практическата стъпка за отстраняване.
Последователна помощ — 3.2.6 A
Ако е осигурен помощен механизъм — връзка за контакт, връзка за помощ, чат джаджа, телефонен номер за поддръжка, връзка за самопомощ — той трябва да се появява на едно и също относително място в страниците, в които е осигурен. Критерият не изисква помощта да присъства; само че там, където присъства, разположението ѝ е последователно.
Критерият е прост по принцип и улавя тесен набор от сайтове, които имат връзка „Свържете се с нас“ в заглавната част на едни страници, в долния колонтитул на други и вътре в плаваща чат джаджа на трети набор от страници — често резултат от множество секции на сайта, притежавани от различни екипи с отделни шаблони.
Одитирайте разположението на помощния механизъм в шаблоните; уеднаквете се на едно канонично място (заглавна част, постоянен долен колонтитул или плаваща джаджа) и съгласувайте всички отклонения. Поправката рядко е техническа; тя е стъпка на управление на съдържанието и шаблоните.
Фокусът не е закрит (разширено) — 2.4.12 AAA
AAA родственикът на 2.4.11: когато компонент на потребителския интерфейс получи клавиатурен фокус, фокусираният елемент не трябва да бъде закрит от съдържание, създадено от автора, изобщо. Частичното закриване е забранено на това ниво — заглавна лента с фиксирана позиция, която покрива каквато и да е част от фокусираното поле, се проваля.
Същите сблъсъци с наслагвания с фиксирана позиция, които движат провалите по 2.4.11, се запазват при 2.4.12. Сайтовете, които приеха scroll-margin-top, за да удовлетворят минималния критерий, все пак обикновено оставят няколко CSS пиксела припокриване при гранични височини на изгледа. На ниво AAA това припокриване е провалът.
Настройте scroll-margin-top така, че удобно да надхвърля височината на всяко наслагване, създадено от автора, включително динамичните (банери за бисквитки, които се появяват при първо посещение, чат джаджи, които се разгръщат при посочване). Добавете изрични регресионни тестове за поведението при преминаване с табулатор във формуляр при често срещаните размери на изгледа.
Достъпна автентикация (разширено) — 3.3.9 AAA
AAA родственикът на 3.3.8: автентикацията не може да разчита на тест на когнитивна функция, точка. Изключенията за разпознаване на обекти и лично съдържание, които се прилагат на ниво AA, не се прилагат тук. Тестовете за памет, тестовете за преписване и предизвикателствата за разпознаване на изображения всички се провалят на това ниво.
Дори сайтове, които замениха традиционните CAPTCHA с предизвикателства за разпознаване на обекти (изключението на AA), се провалят на 3.3.9. Критерият е сигналът на работната група за това накъде следва да отиде автентикацията: изцяло далеч от когнитивните предизвикателства и към атестация на устройството или биометрична проверка.
Приемете ключове за достъп (WebAuthn) като основен механизъм за автентикация; третирайте парола-плюс-ключ за достъп като преходно състояние, а не като крайна цел. Където разпознаването на изображения е запазено за оценяване на риска, изпълнявайте го от страна на сървъра от поведенчески сигнали, а не като обърнато към потребителя предизвикателство.
Допълненията на 2.2 не са там, където живеят повечето от най-трудните проблеми на достъпността. Те са там, където живеят най-честите, най-измеримите производствени провали — което е точно това, за което бяха избрани.
Какво общо имат деветте
Прочетени като каталог, деветте нови критерия споделят обща редакционна поза. Те не са нови режими на провал, които работната група е измислила; те са режимите на провал, които са се проявявали най-последователно в годините след публикуването на WCAG 2.1. Работната група ги третира като пропуски за затваряне: плътни ленти с инструменти (2.5.8), наслагвания с фиксирана позиция (2.4.11 / 2.4.12), автентикация в стил CAPTCHA (3.3.8 / 3.3.9), пръстени на фокуса по подразбиране (2.4.13), модели за плащане с повторно въвеждане на адреса (3.3.7), пренареждане на списъци само с влачене (2.5.7) и непоследователността в разположението на връзката за помощ, която разочароваше застъпниците на хората с когнитивни увреждания (3.2.6).
Картината на правните референции изостава, защото механизмът на фиксиране на версия е бавен. EN 301 549 V4 — единственото най-голямо предстоящо събитие — би каскадирал WCAG 2.2 в Директивата на ЕС за достъпността на уебсайтовете, в референцията за съответствие на Европейския акт за достъпност и във всеки национален закон за уеб достъпност, който сочи към хармонизирания европейски стандарт. Публикуване през 2026 г. е работното допускане в рамките на ETSI JTC HF; забавяне до 2027 г. е по-предпазливото. Изменението на PSBAR на Обединеното кралство, след приключилата консултация от февруари 2026 г., се очаква преди края на годината. Актуализацията на американския Section 508 остава най-бавно движещата се голяма част — дори актуализацията до 2.1 все още е висяща през 2026 г.; актуализация до 2.2 реалистично е инструмент от края на 2020-те.
За целите на планирането за 2026 г. WCAG 2.2 е стандартът, който ще се цитира в правото и обществените поръчки до края на десетилетието. WCAG 3 (Silver) остава работен проект и не е на път към препоръка в близко бъдеще; най-новият публичен проект от 2025 г. изясни, че публикуване на ниво препоръка не се очаква преди 2028 г. Практиката на фиксиране на версия в регулациите означава, че 2.2 ще остане цитирана години след публикуването на 3.0. Прагматичната клауза за обществени поръчки — изискване на WCAG 2.2 на ниво AA като цел за съответствие, изискване на VPAT 2.5 ACR с дата до последните 12 месеца, изискване доставчикът да идентифицира всеки от деветте нови критерия, при който съответствието още не е постигнато — работи при всяка юрисдикция, чието основно право все още фиксира на 2.0 или 2.1, защото нищо в тези закони не пречи на купувач да договори повече.
Вашият списък за готовност за 2.2
Език за обществени поръчки (направете това сега)
- Изисквайте WCAG 2.2 на ниво AA като цел за съответствие в новите договори
- Изисквайте VPAT 2.5 ACR с дата до последните 12 месеца от всеки доставчик
- Изисквайте от доставчиците да идентифицират всеки от деветте нови критерия, при който съответствието още не е постигнато, плюс документирана пътна карта за отстраняване
- Третирайте „WCAG 2.1 AA като минимум, с отчитане спрямо 2.2, където отговорът на доставчика позволява“ като под — не като таван
Инженерни регресионни тестове (уловете петте на AA, преди одитът да ги улови)
- Поведение при преминаване с табулатор във формуляр при често срещани размери на изгледа, с всяко наслагване отворено (2.4.11)
- Размери на целта за докосване в иконни ленти с инструменти, табла за управление и заглавия на таблици с данни (2.5.8)
- Алтернативи с единичен показалец за всяко взаимодействие с влачене — пренареждане на списъци, плъзгачи, инструменти за изрязване (2.5.7)
- Потоци за вход, регистрация и нулиране на парола без тестове на когнитивна функция; поставянето е разрешено в полетата за еднократен код (3.3.8)
- Постоянство между стъпките: никое поле не се иска два пъти в един и същ автентикиран процес (3.3.7)
Редакционен преглед / преглед на ИА (двете допълнения на ниво A)
- Единно канонично разположение на помощните механизми в шаблоните (3.2.6)
- Междуекипен преглед на потока за всеки многостъпков процес, притежаван от повече от един екип (3.3.7)
Точки за следене през 2026 г.
- Публикуване на EN 301 549 V4 — задейства WCAG 2.2 в правото на ЕС за уеб достъпност
- Изменение на PSBAR на Обединеното кралство — първата голяма англоезична юрисдикция, която фиксира на 2.2
- Актуализация на американския Section 508 за ИКТ — 2.1 все още е висяща; 2.2 е инструмент от края на 2020-те
- Честота на VPAT 2.5 — всеки ACR с дата 2025 г. или по-късно следва да се отчита спрямо 2.2
Преходът към WCAG 2.2 структурно е два прехода, протичащи на различни часовници. Правният преход е бавен, зависим от малък брой органи по стандартизация — ETSI JTC HF преди всичко — и ще продължи през 2026–27 г. Преходът в практиката е до голяма степен вече осъществен: одиторите се отчитат спрямо 2.2, дизайн системите се привеждат в съответствие с нея, доставчиците подават VPAT 2.5 ACR с отчитане спрямо нея, а деветте нови критерия вече са установеният речник на одитите на достъпността. Интересният аналитичен въпрос вече не е дали WCAG 2.2 е работният стандарт — той е такъв — а дали регулаторните референции ще наваксат, преди WCAG 3 да започне да тегли вниманието напред.
МетодологияОписателите на честотата на провалите са агрегирани от независими одиторски доклади, издадени до първото тримесечие на 2026 г. в одитни цикли за SaaS, електронна търговия и обществен сектор. Качествени описатели се използват там, където кантори публикуват подредбови, а не точни честоти.
ОбхватСамо деветте нови критерия за успех на WCAG 2.2. SC 4.1.1 Parsing, оттеглен в WCAG 2.2, е извън обхвата. Пренесените критерии от WCAG 2.1 са извън обхвата.
ИзточнициW3C, Web Content Accessibility Guidelines (WCAG) 2.2, препоръка от 5 октомври 2023 г. — w3.org/TR/WCAG22; W3C AG WG, What’s New in WCAG 2.2 — w3.org/WAI/standards-guidelines/wcag/new-in-22; ETSI, EN 301 549 V3.2.1 (2021 г.) и проекти на JTC HF V4; US Access Board ICT Standards (Section 508 Refresh, 2017 г.); US DOJ, Final Rule — Title II web accessibility, 28 C.F.R. Part 35 (април 2024 г.); UK Cabinet Office, PSBAR 2018 и консултация 2025–26 г.; ITI, VPAT 2.5 / ACR, януари 2025 г. — itic.org/policy/accessibility/vpat; директиви на ЕС 2016/2102 и 2019/882; W3C, WCAG 3.0 Working Draft — w3.org/TR/wcag-3.0. Прочетете повече за националната нормативна уредба за достъпност, набора от инструменти за практици, пълния справочник на критериите за успех на WCAG 2.2, обяснителния материал за привеждането в съответствие, съответствието и достъпността, наръчника за купувача на мониторинг, безплатно базово сканиране по WCAG 2.2 и по-широкия архив на отразяването за 2026 г.