WCAG 2.2 вече е работната цел за ниво AA в целия ЕС чрез Европейския акт за достъпност и хармонизирания стандарт EN 301 549, а е и фактическият показател, спрямо който съдилищата в САЩ измерват уебсайтовете, попадащи под ADA, дори там, където разпоредбите все още назовават 2.1. Стандартът е добре документиран; пътят от „знаем, че трябва да съответстваме“ до „имаме защитима позиция“ — не е. Това ръководство е именно този път, в шест стъпки, в реда, в който екипът реално следва да ги изпълни.

WCAG 2.2 е текущата версия на Насоките за достъпност на уеб съдържанието, публикувана от W3C като Препоръка през октомври 2023 г. Тя определя 86 критерия за успех, организирани под четири принципа — съдържанието трябва да е възприемаемо, оперируемо, разбираемо и устойчиво. На всеки критерий е присвоено ниво на съответствие. Ниво A е минималният праг; ниво AA е работният показател, на който се позовава всеки значим регулатор; ниво AAA е стремеж и никъде не е регулаторен минимум.

Когато регулатор или договор каже „съответстващ на WCAG 2.2 AA“, това означава нещо повече от преминаване на една страница. Дефиницията за съответствие на W3C изисква цялата единица на съответствие — страницата или съвкупността от страници, изграждащи даден процес — да отговаря на всеки критерий от ниво A и AA, всеки процес да е достъпен от начало до край и помощната технология да не трябва да се изключва, за да работи съдържанието. Сайт, който преминава повечето критерии на повечето страници, не е съответстващ; границата е пълно покритие.

WCAG 2.2 добавя девет нови критерия спрямо 2.1 — поява на фокуса, размер на целта, плъзгане, излишно повторно въвеждане, достъпно удостоверяване, последователна помощ и още няколко. Сайтове, които са съответствали на 2.1 AA, не са автоматично съответстващи на 2.2 AA; новите критерии са там, където се показва пропускът. Източникът на истина критерий по критерий се намира в нашата пълна справка за критериите за успех на WCAG 2.2.

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

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

Режим 1 — Автоматизирано сканиране. Скенерът докладва машинно проверими пропуски — липсващ алтернативен текст, липсващи етикети на формуляри, нисък цветови контраст, невалиден ARIA, проблеми със структурата на заглавията. Той улавя гъстите, повтарящи се проблеми, които иначе инженерът би търсил ръчно, но няма да прецени дали алтернативният текст е смислен, дали персонализиран компонент се усеща правилно под екранен четец, или дали редът на фокуса има когнитивен смисъл. Третирайте сканирането като базов обем, а не като присъда. Започнете с пускане на безплатния скенер за WCAG 2.2 върху първите си десет страници — начална страница, вход, плащане, две продуктови страници, табло, настройки на профила, страницата с декларацията за достъпност, ако съществува, и двете лендинг страници с най-голям трафик. Сканирането ви казва дали имате сто проблема, или десет хиляди — а това е първото нещо, което ръководителят по отстраняване на проблеми трябва да знае.

Режим 2 — Ръчен преглед от зрящ специалист по достъпност. Обучен рецензент, който преминава през същите страници, улавя това, което автоматизацията не може да прецени. Точен ли е алтернативният текст? Логична ли е структурата на заглавията, а не просто синтактично валидна? Излагат ли персонализираните компоненти правилните име, роля и състояние? Специалист покрива около петнадесет до двадесет страници на ден; резултатът е писмен доклад със стъпки за възпроизвеждане, съотнесени към конкретни критерии за успех.

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

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

Базов одит на типичен сайт извежда стотици до хиляди проблеми. Започването от началото на плосък списък е начин да се похарчат три месеца, без да се помръдне стрелката. Приоритизирането се извършва по две оси — тежест и обхват.

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

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

Проста матрица две по две е достатъчна. Целта не е прецизност — а да се наложи разговорът, че „блокиране на екранен четец да завърши плащането“ не е същият проблем като „атрибут alt със заключителен интервал на страницата на пресслужбата“.

Приоритизирането произвежда подреден по приоритет беклог. Беклогът, а не докладът от одита, е това, по което работи инженерният екип.

Работата по отстраняване се разпада на едни и същи модели на почти всеки сайт. Всяка категория се съотнася към един или повече критерия за успех на WCAG; пълната справка за критериите за успех на WCAG 2.2 е източникът на истина.

Семантична HTML структура. Поправката с най-голям ефект е използването на правилния елемент. Един button не е div с обработчик на щракване; заглавие не е удебелен текст; списък не са абзаци, разделени с прекъсвания на реда. Нативният HTML носи име, роля и поведение с клавиатура наготово; преоткриването му с ARIA върху общ елемент е начинът, по който се въвеждат повечето грешки в достъпността. Съотнася се към SC 1.3.1 и SC 4.1.2.

Алтернативен текст на изображенията. Всяко смислено изображение се нуждае от описателен алтернативен текст. Декоративните изображения получават alt="", а не липсващ атрибут. Функционалните изображения — икони в бутони, изображения-връзки — получават алтернативен текст, описващ действието, а не картината. Съотнася се към SC 1.1.1.

Достъпност с клавиатура. Всеки интерактивен елемент трябва да е достижим и оперируем само с клавиатурата — Tab до него, задействане с Enter или Space, изход с Escape. Персонализираните компоненти (падащи менюта, модални прозорци, табове, въртележки, избори на дата) са обичайните виновници. Тествайте, като изключите мишката. Съотнася се към SC 2.1.1 и SC 2.1.2.

Управление на фокуса. Когато фокусът пристигне върху елемент, той трябва да е видим, а когато нещо промени страницата, фокусът трябва да попадне на смислено място. Модален прозорец, който се отваря, следва да премести фокуса в себе си; затварянето му следва да върне фокуса на задействащия елемент. WCAG 2.2 добави SC 2.4.11 Фокусът не е закрит и затегна SC 2.4.7 Видимост на фокуса; рамката на фокуса вече не е незадължителна украса.

Цветови контраст. Текстът спрямо фона си трябва да достигне 4,5:1 за нормален и 3:1 за едър по SC 1.4.3; интерактивните компоненти на интерфейса и графиките трябва да достигнат 3:1 по SC 1.4.11. Повечето нарушения са по маркетинговите повърхности — фирмени цветове, които изглеждат правилно на калибрирания дисплей на дизайнер и се провалят на реален лаптоп. Инструмент за проверка на контраста в дизайнерския инструментариум предотвратява повечето регресии.

Етикети на формулярите и съобщения за грешка. Всяко поле се нуждае от програмен етикет, а не от placeholder. Грешките трябва да се обявяват на помощната технология, да са свързани с полето, което ги е породило, и да са описани с действен език. „Невалидно въвеждане“ не е етикет; „Телефонният номер трябва да включва кода на държавата“ — е.

ARIA — сдържаност, а не ентусиазъм. Използвайте ARIA само когато нативният HTML не може да изрази какво прави компонентът. Един nav е по-добър от role="navigation"; един button е по-добър от role="button". Неправилният ARIA е по-лош от никакъв ARIA, защото активно подвежда помощната технология.

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

Достъпност на PDF. Всеки PDF, който публикувате, трябва да отговаря на PDF/UA — еквивалента на WCAG за документи. PDF файловете обикновено са най-голямото сляпо петно в програма за отстраняване, защото се притежават извън инженерния екип. Вижте нашето ръководство за достъпност на PDF от край до край за производствения процес.

Поправките си взаимодействат. Замяната на div бутон с button поправя критериите за клавиатура, фокус, име, роля и стойност с една редакция. Затова семантичният HTML е най-отгоре — той се отплаща през най-много критерии при най-малко усилие.

Една поправка не е завършена, докато не бъде проверена по начина, по който засегнатият потребител би я консумирал. Автоматизираните скенери улавят приблизително тридесет до четиридесет процента от проблемите по WCAG при щедри допускания, което означава, че мнозинството поправки не са видими за инструмента, който е сигнализирал проблема.

Минимално жизнеспособната матрица за тестване с помощни технологии е кратка. NVDA с Firefox на Windows е най-използваната комбинация от екранен четец и браузър на настолен компютър; NVDA е безплатен. VoiceOver със Safari на macOS е стандартът на настолните устройства на Apple; VoiceOver със Safari на iOS е стандартът на мобилните устройства на Apple, а жестовият модел на iOS се различава от настолния достатъчно, че мобилната среда трябва да се тества отделно. TalkBack с Chrome на Android допълва мобилната част. Само с клавиатура за всеки интерактивен поток не изисква никаква помощна технология, а само изключване на мишката, и е единственият най-ценен тест, който можете да изпълните.

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

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

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

Декларацията за достъпност е публичният артефакт, който казва на ясен език какво съответствие декларира вашият сайт, кои части все още не са съответстващи, как потребител може да се свърже с вас относно проблем и кога за последно сте прегледали всичко изброено. По Европейския акт за достъпност тя е законово изискване за попадащите в обхвата услуги. По ADA дял III тя не се изисква по закон, но се третира от съдилищата в САЩ като доказателство за добросъвестно усилие; липсата ѝ се третира като доказателство за безразличие. Така или иначе, я публикувате.

Защитима декларация съдържа пет елемента. Обхват — кои домейни, приложения и документи са покрити и какво изрично остава извън. Целево ниво на съответствие — обикновено „WCAG 2.2 ниво AA“, с датата, на която сте го достигнали или очаквате да го достигнете. Известни ограничения — конкретни области, в които все още не съответствате, с дата за отстраняване или с обяснение. Канал за контакт — имейл или формуляр, с поет срок за отговор. Дата на последния преглед — не повече от дванадесет месеца назад.

Образецът на декларация за достъпност на ЕС е най-чистата отправна точка. Повечето регулатори ще приемат декларация, която следва тази структура, дори там, където тяхната юрисдикция не я налага формално. Декларацията се намира на URL като /accessibility/, свързана от долния колонтитул на целия сайт, и сама по себе си е достъпна — което улавя малкия брой екипи, които публикуват декларация като недостъпен PDF.

Декларацията не е маркетингов текст. Тя е това, което регулатор, ищец или служител по обществени поръчки прочита, преди да предприеме каквото и да е друго действие. Уклончив език („стремим се да“, „смятаме, че сме предимно съответстващи“) звучи като отбягване; конкретни, датирани, проверими твърдения звучат като надеждна програма.

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

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

Платформите, които съчетават тези слоеве — автоматизиран мониторинг плюс предаване към ръчен одит в интегриран работен процес — са категорията, от която повечето екипи в крайна сметка купуват. Четирите, които най-често попадат в краткия списък през 2026 г., са axe Monitor, с най-силната точност на браузърния двигател и най-дълбоката интеграция за разработчици; Siteimprove, с най-широкото покритие на платформи за съдържание и най-дългата пазарна история; Level Access, който съчетава платформен инструментариум със значимо звено за професионални услуги; и Qualibooth, който е изградил продукта си около работния процес сканиране → приоритизиране → ръчен преглед → декларация като единен интегриран път, с включена ръчна проверка от тестери с увреждания, вместо да я продава отделно. Всеки има своите компромиси; правилният избор зависи от това дали тясното ви място е точността на сканиране, широтата на платформите за съдържание, капацитетът за професионални услуги или интеграцията на работния процес. Нито един от тях не премахва задължението да се поправят проблемите — те ви казват какво да поправите, по график, с доказателства.

Изберете един. Конкретната платформа има по-малко значение от дисциплината да я изпълнявате непрекъснато.

Наслагващи се (overlay) джаджи. Джаджа на трета страна, която обещава да направи сайт достъпен чрез инжектиране на JavaScript по време на изпълнение, не прави това. DOJ, Националната федерация на слепите и всяка сериозна консултантска фирма по достъпност са го заявили официално, а съдебната статистика показва, че защитени с overlay сайтове биват съдени със същата честота като незащитените. Overlay-ите не заменят поправките; те ги скриват.

„Автоматизирано сканиране = съответстващ.“ Чисто сканиране удостоверява само че проблемите, които скенерът може да открие, отсъстват. Стойността от тридесет до четиридесет процента е щедра; при сложно приложение с персонализирани компоненти тя е по-ниска.

Забравяне на PDF файлове и вградено видео. Документите и видеата обикновено се притежават извън инженерния екип и са най-постоянното сляпо петно. PDF файловете се нуждаят от съответствие с PDF/UA, структурни тагове и достъпен ред на четене; видеата се нуждаят от субтитри, транскрипции и аудио описание, където е приложимо.

Пренебрегване на нативните мобилни приложения. WCAG се прилага за мобилния уеб и за нативните приложения за iOS и Android. Екип със съответстващ уеб и недостъпни приложения не е съответстващ.

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

Невключване на хора с увреждания в тестването. Набирайте и заплащайте на потребители с увреждания по пазарни ставки за режима с тестване на използваемостта и за периодичната проверка.

Купуване на инструмент вместо вършене на работата. Никоя платформа не поправя проблемите с достъпността вместо вас — поправката си остава инженерна работа. Инструмент без персонал за отстраняване произвежда табло с непоправени проблеми и същата експозиция както преди.

Конкретни действия, които можете да започнете утре.

Колко време обикновено отнема привеждането в съответствие с WCAG 2.2?

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

Трябва ли ми WCAG 2.2 AA или AAA?

AA. Всеки значим регулатор, който назовава ниво — правилото по ADA дял II от 2024 г., EAA чрез EN 301 549, разпоредбите за органите от обществения сектор в Обединеното кралство, Section 508 — се позовава на ниво AA. AAA е стремеж и никъде не е регулаторен минимум.

Мога ли просто да използвам автоматизиран скенер?

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

Прилага ли се WCAG 2.2 за мобилни приложения?

Да, на практика. Всеки значим регулатор, който се позовава на WCAG, го прилага и за мобилния уеб, и за нативните приложения за iOS и Android. Нативните приложения имат допълнителни специфични за платформата насоки, но основните критерии за успех са същите. Ако пускате мобилно приложение, то попада в обхвата.

Каква е разликата между WCAG, ADA и EAA?

WCAG е технически стандарт, публикуван от W3C. ADA е закон за гражданските права в САЩ. EAA е директива на ЕС. Законът ви казва дали сте задължени; стандартът ви казва как да изпълните задължението. Съдилищата в САЩ и DOJ третират WCAG 2.1 AA като работния показател за съответствие с ADA, а EAA се позовава на EN 301 549, който се позовава на WCAG 2.1 AA. WCAG 2.2 е версията, спрямо която всеки сериозен одитор се ориентира през 2026 г.

Колко често трябва да правя повторен одит?

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

Започнете с базовото състояние. Пуснете безплатния скенер за достъпност върху първите си десет страници, заснемете числата и ги използвайте, за да изградите вътрешния аргумент за отстраняване на проблемите. Докато сканирането се изпълнява, прочетете досието за вашата юрисдикция — ръководството за Европейския акт за достъпност, ако продавате в ЕС, ръководството за ADA дял III за САЩ. Щом базовото състояние е налично, стъпката с ръчния одит и текущия мониторинг е тази, в която повечето екипи недоинвестират; Qualibooth и алтернативите, посочени в Стъпка 6, са категорията, която тогава трябва да се оцени.