Как да тествате достъпността на сайт: инструменти и ръчни проверки

Ето една история, която чуваме често. Някой пуска Lighthouse, получава зелено 100 за достъпност и продължава нататък. Седмица по-късно клиент пише, че не е успял да плати, защото до формуляра за картата не може да се стигне с клавиатура. И двете неща са верни. Автоматизираната проверка е минала, а сайтът пак е подвел реален човек.

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

Може ли автоматизиран инструмент да ми каже дали сайтът ми е достъпен?

Не. Автоматизираните инструменти бързо откриват някои проблеми, но много въпроси за достъпността изискват човек, който да им отговори. Когато Правителствената дигитална служба на Обединеното кралство (GDS) тества 10 инструмента върху страница със 143 известни нарушения, най-добрият открива 41%. W3C го казва ясно: инструментите за оценка „не могат да определят достъпността, те могат само да помогнат за това“.

Тестът на GDS (отваря се в нов раздел) е от февруари 2017 г., а неговите 41% (на Asqatasun) включват и подсказките на инструмента за ръчни проверки. Оттогава инструментите са се подобрили, но разликата има същата причина. Софтуерът може да разбере, че изображение няма алтернативен текст. Не може да разбере, че „червена рокля“ е грешно описание на снимка на син костюм, или дали редът на фокуса ви има смисъл.

Затова приемайте инструмента за проверка като пожароизвестител, а не като цялостно обследване на сградата. Все пак си струва да го пускате: WebAIM Million 2026 (отваря се в нов раздел) намира автоматично откриваеми нарушения на 95,9% от началните страници на първия милион сайтове, така че при повечето сайтове има лесни поправки с бърз ефект. Както казва ръководството на W3C за избор на инструменти (отваря се в нов раздел): „Нужна е човешка преценка.“

Кои безплатни инструменти за тестване на достъпността да използвам?

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

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

Доста неща. Easy Checks (отваря се в нов раздел) на W3C обхващат заглавията на страниците, алтернативния текст, заглавията в текста, контраста, връзките за прескачане, видимия фокус от клавиатурата, езика на страницата, мащабирането, субтитрите и етикетите на формулярите. Изберете една важна страница, например продуктова страница или формуляра за резервация, и отделете минута-две на всяка проверка. Ще откриете неща, за които нито един инструмент не съобщава.

W3C посочва, че тези проверки „обхващат само няколко въпроса на достъпността“, така че не са пълна оценка. Те все пак са най-добре прекараните четвърт час, които можете да отделите:

1. Заглавие на страницата (1 минута). Казва ли разделът в браузъра каква е страницата, например „Резервирайте маса | Кухнята на Роза“, вместо навсякъде „Начало“?
2. Изображения (2 минути). Покажете алтернативния текст с WAVE или подобен инструмент. Точен ли е? Пропуска ли се украсата?
3. Заглавия (2 минути). Изведете списък със заглавията и ги прочетете самостоятелно. Работят ли като съдържание?
4. Контраст (2 минути). Проверете основния текст, дребния сив текст, текста на бутоните и текста върху изображения.
5. Клавиатура (4 минути). Оставете мишката настрана и минете с Tab през страницата (вижте следващия раздел).
6. Мащабиране (2 минути). При 200%, а после при 400% можете ли все още да прочетете всичко и да ползвате менюто, без да превъртате настрани?
7. Формуляри и език (2 минути). Щракнете върху етикета на всяко поле; в добре изграден формуляр това поставя курсора в полето. Проверете отчета на инструмента за липсващ език на страницата.

Как да тествам с клавиатура?

Махнете мишката. Натискайте Tab, за да вървите напред, Shift+Tab, за да се върнете, Enter, за да следвате връзки, интервал или Enter, за да натискате бутони, и стрелките в менютата и радиобутоните. Всеки интерактивен елемент трябва да е достъпен, винаги трябва да виждате къде се намирате и никога не бива да заседнете.

На Mac Safari прескача връзките при натискане на Tab, докато не включите в разширените му настройки (Advanced) опцията „Press Tab to highlight each item on a webpage“ („Натиснете Tab, за да откроите всеки елемент на уеб страницата“). След това проверете:

• Винаги ли виждате къде се намирате? Ако очертанието на фокуса изчезне, потребителят на клавиатура се губи.
• Логичен ли е редът? Фокусът трябва да следва реда на четене.
• Закрито ли е нещо? Фиксирана горна лента или банер за бисквитки, който скрива елемента на фокус, нарушава критерия Фокусът не е закрит в WCAG 2.2.
• Можете ли да излезете обратно? Отворете всяко меню, изскачащ прозорец и избор на дата и опитайте да излезете. Escape трябва да затваря диалоговите прозорци.
• Работи ли целият процес? Добавете продукт, сменете количеството, приложете код за отстъпка и стигнете до плащането без мишката.

Записвайте всяко нарушение точно: „Изборът на размер на продуктовата страница не се отваря с Enter или интервал“ се поправя много по-бързо от „клавиатурата не работи“.

Как да тествам с екранен четец за първи път?

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

• Mac: Command+F5 включва и изключва VoiceOver; Control+Option+U отваря ротора, списък със заглавия, връзки и контроли на формулярите.
• Windows: в NVDA натиснете H, за да прескачате между заглавията, и Insert+F7, за да изведете списък с връзките и заглавията.
• Телефон: включете VoiceOver (iPhone) или TalkBack (Android) и плъзгайте надясно, за да минавате от елемент на елемент. Първо научете как се изключва.

Вслушайте се в най-важното. В проучването на WebAIM сред потребители на екранни четци от 2024 г. (отваря се в нов раздел) 71,6% от анкетираните казват, че първо се ориентират в дълга страница по заглавията ѝ, затова започнете оттам. После изведете списъка с връзки: пет връзки „Прочетете още“ не казват нищо на никого. „Добави в количката, тъмносин пуловер“ е полезен бутон; „бутон“ не е. Накрая попълнете формуляр и проверете дали всяко поле и всяка грешка се прочитат.

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

Как да проверя мащабирането, пренареждането и разредката на текста?

Увеличете мащаба на браузъра до 200% и проверете дали текстът расте, без да се изрязва или застъпва. После тествайте пренареждането: при мащаб 400% в прозорец, широк 1280 пиксела, съдържанието трябва да се побира без хоризонтално превъртане. Накрая увеличете разстоянието между буквите, думите, редовете и абзаците и проверете дали нищо не се разваля или изчезва.

Тези проверки съответстват на критериите на WCAG Преоразмеряване на текста (1.4.4), Пренареждане (1.4.10) (отваря се в нов раздел) и Разредка на текста (1.4.12) (отваря се в нов раздел). Пренареждането използва ширина 320 CSS пиксела, която според W3C „е равностойна на начална ширина на прозореца за преглед от 1280 CSS пиксела при мащаб 400%“. Разредката на текста изисква нищо да не се губи, когато читателят зададе разстояние между редовете 1,5 пъти размера на шрифта, разстояние между абзаците 2 пъти, разстояние между буквите 0,12 пъти и разстояние между думите 0,16 пъти.

Букмарклет за разредка на текста, малък скрипт, запазен като отметка, прилага и четирите стойности с едно щракване. Търсете текст, който излиза от бутоните, и етикети, изрязани в края. При мащаб 400% лаптопът показва приблизително това, което показва малък телефон, така че добре изграденият адаптивен сайт минава голяма част от тези проверки и без допълнителна работа.

Как да проверя формулярите, грешките и плащането?

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

• Грешки. „Невалидни данни“ в червено не е достатъчно. „Въведете датата на валидност във формат ММ/ГГ“ до полето е достатъчно. След изпращане фокусът трябва да отиде на обобщението на грешките или на първото поле с проблем.
• Вход и кодове. Съгласно критерия за достъпно удостоверяване (отваря се в нов раздел) в WCAG 2.2 блокирането на поставянето или на мениджърите на пароли е нарушение, освен ако няма друг начин за влизане.
• CAPTCHA и времеви ограничения. Потребителите на екранни четци поставят CAPTCHA на първо място сред най-проблемните неща в мрежата в проучването на WebAIM. Проверете дали има достъпна алтернатива и дали времевите ограничения могат да се удължат.

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

Какво включва професионалният одит за достъпност и кога ми трябва?

Одитът за достъпност е структуриран преглед от специалист спрямо посочен стандарт, обикновено WCAG 2.1 или 2.2, ниво AA. Той съчетава автоматизирано сканиране с ръчно тестване и тестване с помощни технологии на ключовите ви шаблони и процеси и завършва с доклад с приоритети. Трябва ви, когато законът се прилага за вас, преди голямо пускане или когато клиенти искат доказателства.

Преди да се договорите за цена, попитайте:

• Спрямо кой стандарт, версия и ниво ще тествате?
• Кои шаблони и процеси са в обхвата? За магазин: начална страница, категория, продукт, количка, плащане, страници на профила и формуляри.
• Тествате ли ръчно с екранни четци, клавиатура и мащабиране и на кои браузъри и устройства?
• Подрежда ли докладът проблемите по тежест, посочва ли къде се намират и предлага ли поправки?
• Включено ли е повторно тестване?

Цените варират силно според изпълнителя, държавата и обхвата, затова сравнявайте какво е включено. Ако Европейският акт за достъпност ви обхваща, одитът подкрепя и публичната ви декларация; нашето ръководство за акта обяснява кой е в обхвата.

Защо да тествате с потребители с увреждания?

Защото съответствието със стандарт и лекотата на ползване не са едно и също. Страница за плащане може да изпълнява всеки критерий на WCAG и пак да отнема двайсет минути на потребител на екранен четец. W3C посочва, че оценката с потребители с увреждания „разкрива проблеми с използваемостта, които не се откриват само с оценка на съответствието“, и показва на екипа ви как хората реално ползват сайта.

Не ви трябва лаборатория. Няколко сесии върху най-важната ви задача, например намиране на продукт и плащане, ще ви научат на повече от още един кръг сканирания. Намерете участници чрез организации на хора с увреждания, агенции за проучвания или сред собствените си клиенти и им платете за отделеното време. Оставете ги да ползват собствените си устройства и настройки. Ръководството на W3C за включване на потребители в оценката (отваря се в нов раздел) обхваща практическата страна.

Какво да правя с резултатите?

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

1. Определете приоритетите. Първо блокиращите проблеми в ключовите процеси (плащане, резервация, регистрация), после общите шаблони, после отделните страници.
2. Поправяйте при източника. Променете темата, компонента или съдържанието, а не само симптома.
3. Тествайте отново. Повторете същите проверки, както ръчно, така и с инструменти.
4. Документирайте. Изброете известните проблеми с дати в декларацията си за достъпност. Нашето ръководство за WCAG 2.2 обяснява по-новите критерии.
5. Повтаряйте. Добавете проверка с клавиатура и сканиране към всяка нова версия.

Ако ползвате уиджет за достъпност, включително нашия, тествайте със затворен уиджет. Панел като SiteAccessible дава на посетителите допълнителни начини да настроят страницата, но WCAG пита дали страницата работи в състоянието си по подразбиране. Някои схеми за одит не оценяват страници, на които работи overlay скрипт, затова първо попитайте одитора си.