Контролен списък за достъпност за малък бизнес и онлайн магазини

Представете си клиент, който ползва екранен четец. Намира маратонките, които иска, избира размер и натиска това, което смята за бутона за количката. Екранният четец казва „бутон“. Нищо повече. На страницата има три такива бутона и нито един няма име, затова клиентът си тръгва, а вие никога не разбирате защо.

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

Трябва ли сайтът на малкия ми бизнес да е достъпен?

Ако продавате на потребители в ЕС, вероятно да. Европейският акт за достъпност (отваря се в нов раздел) обхваща услугите за електронна търговия от 28 юни 2025 г. Основното изключение е за микропредприятията, които предоставят услуги: фирми с по-малко от 10 служители и годишен оборот или общ годишен баланс до 2 милиона евро.

Електронна търговия тук означава продажба от разстояние, чрез уебсайт или приложение, „по индивидуално искане на потребител с цел сключване на потребителски договор“ (член 3, точка 30). Онлайн магазин или система за резервации отговарят на това. Изключението обхваща само услугите: продажбата на обхванати продукти, например електронни четци, пак води до прилагане на правилата за продуктите (член 4, параграф 5). Това, че сте извън ЕС, също не помага, защото магазин от Обединеното кралство, който продава на клиенти във Франция, е в обхвата за тях (член 3, точка 4). Нашето ръководство за Европейския акт за достъпност разглежда националните закони и глобите.

Британският Equality Act 2010 (отваря се в нов раздел) изисква разумни приспособления за хората с увреждания, но не определя технически стандарт за уебсайтове. В САЩ указанията на Министерството на правосъдието от март 2022 г. (отваря се в нов раздел) посочват, че фирмите, отворени за обществеността, трябва да направят достъпно това, което предлагат онлайн, и че стандарти като WCAG „дават полезни насоки“. Каквото и да казва законът, клиент, който не може да завърши поръчката, не купува.

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

Доминират шест нарушения. В WebAIM Million 2026 (отваря се в нов раздел), автоматизирано сканиране на началните страници на първия милион сайтове през февруари 2026 г., 95,9% от страниците имат открити нарушения на WCAG, средно по 56,1 грешки на страница. Най-честият проблем е текстът с нисък контраст, открит на 83,9% от началните страници.

WCAG (Указанията за достъпност на уеб съдържанието) е стандартът зад тези проверки; повечето закони препращат към ниво AA, а нашето ръководство за WCAG 2.2 обяснява последната версия. Някои от проверките по-долу не могат да бъдат преценени от нито един скенер.

Могат ли всички да прочетат текста ви и да разберат изображенията ви?

Започнете оттук, защото тези поправки са евтини и в повечето случаи можете да ги направите сами в редактора на сайта. Текстът се нуждае от достатъчен контраст, изображенията, които носят информация, се нуждаят от алтернативен текст, и нищо не бива да разчита само на цвета. Около 1 на 12 мъже и 1 на 200 жени имат нарушено цветно зрение според Colour Blind Awareness (отваря се в нов раздел).

• Контраст. Нормалният текст се нуждае от контрастно съотношение поне 4,5:1 (отваря се в нов раздел) спрямо фона си, а едрият текст – поне 3:1. Проверете цветовете си, включително текста върху снимките в банерите, с безплатен инструмент. Нашето ръководство за цветовия контраст показва поправки, които запазват марката ви.
• Алтернативен текст на продуктите. Опишете това, което купувачът трябва да знае: „Тъмносин вълнен пуловер с рипсена поло яка, изглед отпред“ е по-добре от „продуктово изображение 1“. Започнете с десетте си най-продавани продукта.
• Декоративни изображения. Фонова завъртулка трябва да има празен алтернативен текст, за да я пропускат екранните четци. Някои платформи попълват празното поле с името на файла, затова проверете своята.
• Само цвят. „Изчерпано“, показано само като посивяла мостра, или задължително поле, отбелязано само в червено, няма да стигне до всички. Разгледайте страницата с филтъра за сиви тонове на телефона си и добавете дума или икона навсякъде, където смисълът изчезва.
• Мащабиране. При мащаб 200% в браузъра текстът трябва да расте, без да се застъпва или изрязва, а менюто трябва да продължи да работи.
• Език на страницата. Всеки безплатен инструмент за проверка отбелязва липсващото обозначение на езика. Това е настройка на темата или промяна на един ред в шаблона.

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

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

• Видим фокус. Очертание трябва да показва кой елемент е активен, а фиксирана горна лента или балонче за чат не бива да го закриват (критерият 2.4.11 Фокусът не е закрит в WCAG 2.2). Много теми махат очертанието заради външния вид; разработчик може да го върне.
• Без капани. Отворете от клавиатурата менюто, избора на размер, изскачащите прозорци и галерията със снимки, изберете нещо и опитайте да излезете. Escape трябва да затваря изскачащите прозорци.
• Имена на иконите. Всяка връзка и бутон с икона се нуждае от име, което екранният четец може да прочете, например „Количка, 2 артикула“. Заменете „Щракнете тук“ с думи, които казват къде води връзката.
• Връзка за прескачане и заглавия. Първото натискане на Tab в идеалния случай трябва да показва връзка „Към съдържанието“. В проучването на WebAIM сред потребители на екранни четци от 2024 г. (отваря се в нов раздел) 71,6% от анкетираните казват, че първо се ориентират в дълга страница по заглавията ѝ, затова използвайте истински нива на заглавия, а не удебелен текст.
• Цели за докосване. WCAG 2.2 изисква цели от поне 24 на 24 CSS пиксела или достатъчно свободно място около тях (критерий за успех 2.5.8 (отваря се в нов раздел)).

Могат ли всички да минат през формулярите, количката и плащането?

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

• Етикети, а не текст в полето. Текстът в полето изчезва веднага щом човек започне да пише и често е твърде блед, за да се прочете. Всяко поле се нуждае от етикет, който остава видим.
• Съобщения за грешки. Изпратете формуляра празен. Всяка грешка трябва да е написана с думи („Въведете пощенски код, например 1000“), да стои до своето поле и да се прочита от екранния четец, а не само да оцветява рамката в червено.
• Не питайте два пъти. Предложете „Адресът за фактуриране е същият“, вместо да карате хората да въвеждат отново адреса за доставка. WCAG 2.2 превърна това в изискване от ниво A, 3.3.7 Излишно въвеждане.
• Влизане в профил. Позволете на хората да поставят пароли и еднократни кодове и да ползват мениджъри на пароли. Блокирането на поставянето нарушава критерия за достъпно удостоверяване (отваря се в нов раздел) в WCAG 2.2, освен ако не предлагате друг начин за влизане.
• CAPTCHA. В проучването на WebAIM от 2024 г. потребителите на екранни четци поставиха CAPTCHA на първо място сред най-проблемните неща в мрежата. Ако имате нужда от защита срещу ботове, избягвайте визуални пъзели и винаги предлагайте невизуална алтернатива.
• Срокове. Ако количката или резервацията изтичат, предупредете хората и им позволете да удължат срока.

Ако части от плащането принадлежат на платформата ви или на доставчика на плащания, тествайте ги въпреки това, съобщете за проблемите и ги посочете като известни проблеми.

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

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

• Банер за бисквитки. Можете ли да стигнете до „Приемам“ и „Отказвам“ с Tab, да ги прочетете при мащаб 200% и след това да продължите оттам, където сте били?
• Изскачащи прозорци. Фокусът трябва да влезе в изскачащия прозорец, да остане там, докато той се затвори, и след това да се върне. Escape трябва да го затваря.
• Чат уиджети. Бутонът се нуждае от име, прозорецът трябва да се отваря и затваря от клавиатурата, а на телефон не бива да стои върху „Плащане“.
• Въртележки. Всичко, което се движи автоматично повече от пет секунди, се нуждае от начин да бъде поставено на пауза, спряно или скрито (WCAG 2.2 (отваря се в нов раздел), критерий за успех 2.2.2).
• Вградено съдържание. Уиджетите за отзиви, картите и инструментите за резервации също стоят на вашата страница. Съобщавайте за нарушенията на доставчика.

Работят ли видеоклиповете, PDF файловете и менютата ви за всички?

Видеото се нуждае от субтитри, аудиото от препис, а важната информация не бива да е само в PDF файл или изображение. Ресторант, чието меню е сканиран PDF, или магазин, чиято таблица с размери е снимка, изключва потребителите на екранни четци и всеки, който има нужда да увеличи текста на телефона си.

• Субтитри и преписи. Коригирайте автоматичните субтитри преди публикуване. Подкастите се нуждаят от текстова версия.
• Текст в снимки. Поставете менютата, ценоразписите, таблиците с размери и работното време на обикновена уеб страница. Ако трябва да ползвате PDF, експортирайте го със заглавия и етикети от текстообработващата програма, вместо да сканирате разпечатка.
• По-стари файлове. Актът не ви задължава да поправяте офис файлове или предварително записани аудио и видео, публикувани преди 28 юни 2025 г., нито архиви, които вече не актуализирате (член 2, параграф 4). Новите файлове са в обхвата.

Какво мога да поправя сам и кога ми трябва разработчик или одит?

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

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

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

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

Второто задължение идва от приложение V към директивата; формата се определя от националния закон. Нашето ръководство за писане на декларация за достъпност съдържа шаблон, който можете да адаптирате. След това поддържайте рутината:

1. Приложете контролния списък върху трите си ключови страници и направете екранна снимка на всяко нарушение.
2. Поправете точките за съдържанието сами още тази седмица.
3. Възложете на разработчик точките за темата и плащането, като започнете от най-тежките.
4. Тествайте всяка поправка отново с клавиатура, а не само с инструмент за проверка.
5. Публикувайте или актуализирайте декларацията си с дата.
6. Повтаряйте всеки път, когато добавите приложение, смените темата или пуснете нова целева страница.