Как да направите сайта си съвместим с WCAG 2.2

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

Стъпка 1: Разберете какво всъщност изисква WCAG 2.2

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

Perceivable (Възприемаемо) — потребителите трябва да могат да възприемат съдържанието. Помислете за текстови алтернативи на изображенията, надписи и транскрипции за медиите и достатъчен цветови контраст.
Operable (Управляемо) — всяка функция трябва да работи без мишка. Пълната управляемост с клавиатура, видимите индикатори на фокуса и липсата на клавиатурни капани са основни изисквания.
Understandable (Разбираемо) — съдържанието и поведението трябва да са предвидими. Ясните етикети, последователната навигация, полезните съобщения за грешки и четимият език са тук.
Robust (Стабилно) — маркъпът трябва да може да се обработва от текущата и бъдещата помощна технология, което на практика означава валиден HTML и правилно използване на ARIA имена, роли и стойности.

Всеки принцип се разбива на проверими критерии за успех, като на всеки критерий е присвоено ниво на съответствие: A (съществено), AA (правната и практическата база, която повечето организации си поставят за цел) и AAA (разширено). Когато се каже „WCAG 2.2 AA”, се има предвид съответствие с всеки критерий за успех от ниво A и ниво AA. WCAG 2.2 добавя девет нови критерия спрямо 2.1 — включително Незакрит фокус, Движения с плъзгане, Размер на целта (минимален) и Достъпно удостоверяване — повечето от които подобряват изживяването за потребители с клавиатура, с ниско зрение и с двигателни увреждания.

Полезно е да знаете защо това е целта. Съответствието AA е посочено в законите и разпоредбите, които най-вероятно се отнасят за вас: запознайте се със съответствието с WCAG като технически стандарт, после вижте как се съотнася към European Accessibility Act, ADA за частни и публични субекти в САЩ и Section 508 за федералните агенции на САЩ и техните доставчици. Ако терминологията ви затрудни по пътя, дръжте нашия речник на достъпността отворен в раздел.

Още две понятия оформят всяко честно твърдение за съответствие. Първото е обхватът на съответствието: съответствието с WCAG се прилага за цели страници, а не за изолирани компоненти, и за цялостни процеси (напр. целия процес на плащане) — не можете да твърдите, че дадена страница е съответстваща, ако една стъпка от многоетапна задача се проваля. Второто е технология с поддръжка на достъпността: можете да разчитате само на начини за използване на дадена функция, които действително се поддържат от помощната технология на потребителите ви. На практика това означава тестване с актуални екранни четци и браузъри, вместо да се приема, че самият валиден маркъп гарантира използваем резултат. Имайте предвид и двете, когато определяте обхвата на работата си в стъпките по-долу; те определят какво можете обосновано да твърдите, че сте постигнали.

Стъпка 2: Изпълнете автоматично базово сканиране

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

Инструменти, изградени върху отворения двигател axe-core — включително софтуера за сканиране на достъпност на QualiBooth — изготвят приоритизиран списък с проблеми за минути. Ако просто искате бърза оценка на текущото си състояние, започнете с безплатно сканиране на достъпност на няколко ключови страници.

Няколко правила, за да остане базовата ви линия честна:

Сканирайте представителни шаблони, а не целия си сайт. Тествайте началната си страница, шаблон за съдържание/статия, продуктова или категорийна страница, формуляр (регистрация, плащане, контакт) и всяко удостоверено табло. Поправянето на един шаблон обикновено поправя стотици страници.
Тествайте реални състояния, а не само първоначалното зареждане. Отваряйте менюта, разгъвайте акордеони, задействайте модални прозорци и изпращайте формуляри с грешки. Много нарушения се появяват само в интерактивни състояния.
Записвайте числата. Заснемете броя на проблемите по тежест и по критерий за успех. Това е вашият бенчмарк преди/след и основата на вашия списък със задачи за отстраняване.

Бъдете честни относно тавана: автоматизираните инструменти надеждно откриват само 30–40 % от проблемите с WCAG. Чистото автоматично сканиране е необходимо, но никога не е достатъчно за реално твърдение за съответствие.

Стъпка 3: Допълнете автоматизацията с ръчен одит

Останалите 60–70 % от критериите на WCAG изискват човешка преценка. Този алтернативен текст наистина ли предава значението на изображението, или просто описва пиксели? Логичен ли е редът на четене и на фокуса? Съобщенията за грешки казват ли на потребителя как да се възстанови? Правилно ли се обявява персонализиран падащ списък и можете ли да го достигнете и да го управлявате само с клавиатура? Нито един двигател не може да отговори надеждно на тези въпроси.

Един структуриран ръчен одит обикновено обхваща:

Работа само с клавиатура — преминете с tab през всеки интерактивен елемент; потвърдете видим индикатор на фокуса, логичен ред, липса на капани и че всичко, което можете да направите с мишка, можете да направите и без нея.
Семантична структура — заглавия в смислена йерархия, ориентири (landmarks), списъци, маркирани като списъци, таблици с правилни заглавия.
Формуляри — програмни етикети, групирани полета, ясно обозначаване на задължителните полета и съобщения за грешки, свързани с входните полета, които описват.
Динамично съдържание — модални прозорци, които улавят и възстановяват фокуса правилно, „живи” области (live regions), които обявяват актуализациите, и ARIA, използван само там, където нативният HTML не може да свърши работата.
Качество на съдържанието — смислен текст на връзките, достатъчен контраст в реални контексти и съдържание, което не разчита само на цвят или форма.

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

Стъпка 4: Приоритизирайте и отстранявайте

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

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

Когато отстранявате, поправяйте източника, а не симптома. Предпочитайте нативни HTML елементи пред закърпени с ARIA <div>-ове; коригирайте компонента от дизайн системата, а не всяка страница, която го използва; и адресирайте първопричините в шаблоните и споделените компоненти, за да се мащабира поправката. Сканирайте отново след всяка партида, за да виждате как числата падат и да избегнете въвеждането на регресии. Това е и подходящият момент да вградите достъпността в дизайн токените си — задайте като стойности по подразбиране безопасни за контраста цветове, минимален размер на целта 24×24 px и видими стилове на фокуса, така че новата работа да започва съответстваща.

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

Използвайте платформата. Нативните <button>, <a href>, <input>, <select> и <dialog> идват безплатно с поведение от клавиатура, управление на фокуса и правилно достъпно име. Прибягвайте до ARIA само за да запълните истински празнини — и помнете първото правило на ARIA: не използвайте ARIA, ако нативен елемент върши работа.
Назовавайте нещата програмно. Всеки контрол се нуждае от достъпно име от <label>, aria-label или aria-labelledby — не само от близкия визуален текст. Бутоните само с икона са най-честият нарушител.
Управлявайте фокуса целенасочено. Когато се отвори модален прозорец, преместете фокуса в него, задръжте го там, докато е отворен, и го върнете на задействащия елемент при затваряне. Когато съдържанието се актуализира без навигация, използвайте „жива” област, за да чуят потребителите на екранни четци какво се е променило.
Не кодирайте значение само чрез цвят или форма. Съчетавайте цвета с текст, икони или шарки, за да оцелее информацията за потребители с далтонизъм и ниско зрение.

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

Стъпка 5: Тествайте с помощна технология и с хора с увреждания

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

Тестване с екранен четец. Проверете поправките си спрямо помощната технология, която хората действително използват: NVDA или JAWS с Chrome/Firefox в Windows и VoiceOver със Safari в macOS и iOS. Вслушвайте се за точни имена, правилни роли, обявявани промени на състоянието и разумен ред на четене. Оценка с екранен четец ви дава професионално преминаване през основните комбинации, ако на екипа ви липсва опит.

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

Стъпка 6: Документирайте съответствието (декларация и VPAT/ACR)

След като отстраните и валидирате, заснемете резултата. Документацията е това, което превръща „опитахме” в защитимо, съобщимо твърдение.

Декларация за достъпност. Публична страница, която посочва целта ви за съответствие (напр. WCAG 2.2 AA), описва какво сте направили, изброява всички известни ограничения и дава на потребителите начин да докладват проблеми. Много разпоредби, включително EAA, очакват такава.
VPAT / Accessibility Conformance Report. Попълнен Voluntary Product Accessibility Template се превръща в ACR — стандартния артефакт, който екипите по доставки и корпоративните купувачи изискват като доказателство. Нашето ръководство какво е VPAT/ACR обяснява документа, а услугата VPAT отчети изготвя точен, подкрепен от одит отчет, който можете да предадете на клиенти и правни екипи.

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

Стъпка 7: Поддържайте съответствието във времето

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

Вградете достъпността в жизнения цикъл на софтуера си:

Shift left. Добавете автоматизирани проверки към пайплайна си с интеграция на достъпността в CI/CD, така че нарушенията да се улавят при pull request-и, преди да бъдат пуснати — възможно най-евтиното място за поправянето им.
Наблюдавайте продукцията. Планирайте повтарящи се одити на достъпността, за да улавяте регресии и отклонения в съдържанието, които проверките преди пускане няма да видят.
Овластете екипа си. Снабдете дизайнери, разработчици и автори на съдържание с инструментариум за достъпност и споделени стандарти, така че достъпността да е стандарт за всички, а не последваща мисъл на специалист.
Управлявайте в мащаб. За големи или мултисайт организации платформа като Agora централизира проследяването, отчитането и отстраняването между екипите.

Грешки, които провалят усилията за съответствие

Екипите, които засядат, обикновено го правят по предвидими причини. Внимавайте за тези:

Доверяване само на автоматизацията. Зелен автоматизиран отчет покрива само една трета от критериите. Третирането му като доказателство за съответствие е най-честата — и най-рискована от правна гледна точка — грешка.
Купуване на overlay. Overlay решенията и „джаджите за достъпност” обещават мигновено съответствие чрез инжектиране на JavaScript, който заменя страницата. Те не поправят основния код, често пречат на собствената помощна технология на потребителите и са посочвани в нарастващ брой жалби. Те са пряк път към риска, а не към съответствието.
Поправяне на страници вместо на системи. Отстраняването на отделни страници, докато дизайн системата остава счупена, означава, че всяка нова страница въвежда отново същите дефекти. Поправете първо споделените компоненти и шаблони.
Третиране като еднократен проект. Без CI/CD проверки и повтарящи се одити един съответстващ сайт се отклонява от съответствието в рамките на няколко цикъла на издаване.
Прескачане на реалните потребители. Техническото съответствие без тестване на използваемостта все пак може да остави потребителите с увреждания неспособни да изпълнят основни задачи.

Избягването на тези грешки предпазва инвестицията ви от изтичане в момента, в който проектът „бъде пуснат”.

Да съберем всичко заедно

Реалистичният път към WCAG 2.2 AA изглежда така: научете принципите POUR и целта AA, изпълнете автоматично базово сканиране, надградете с ръчен одит, отстранявайте по въздействие и обхват, валидирайте с екранни четци и потребители с увреждания, документирайте съответствието си в декларация и VPAT, а след това го поддържайте здраво с CI/CD проверки и повтарящи се одити. Всяка стъпка надгражда предишната — и нищо от това не зависи от overlay, който замазва реалния код.

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