Головна Послуги Чому ми Порівняння FAQ Процес Вакансії Блог Словник термінів Зв'язатись
Маскот LuloTech друкує на клавіатурі ноутбука, миші на столі немає — перевірка доступності сайту з клавіатури

⚡ Коротко
Доступність сайту — це чи зможе людина ним скористатись, коли в неї немає миші, слабкий зір або сторінку їй читає вголос програма. Перевірка займає десять хвилин: заберіть руку з миші й пройдіть сайт клавішею Tab. Ми так зробили зі своїм і знайшли перемикач мов, у якому людина з клавіатури застрягала намертво.

Заберіть руку з миші. Тепер пройдіть власний сайт: Tab, Tab, Enter. Дійдіть до форми, заповніть її, надішліть. Більшість власників роблять це вперше саме тоді, коли їм пропонують, і зупиняються десь на третьому екрані.

Ми пройшли так свій сайт минулого тижня. Знайшли одну поломку, зате показову, і саме про неї нижче.

Доступність сайту — це про кого

Побутує уявлення, що веб доступність стосується сайтів лікарень, банків і держустанов, а звичайний бізнес може не перейматись. Уявлення зручне і хибне.

Ось хто реально впирається в недоступний інтерфейс:

  • Людина з незрячістю або слабким зором. Сторінку їй читає скрінрідер, програма, яка озвучує вміст. Якщо кнопка записана в коді як звичайний прямокутник, скрінрідеру нема чого про неї сказати.
  • Той, у кого зламався тачпад. Тимчасово, але прямо зараз. Клавіатура лишається єдиним способом дійти до кнопки «Замовити».
  • Люди з тремором і обмеженою моторикою. Влучити курсором у дрібне посилання складно, Tab надійніший.
  • Ті, хто збільшує шрифт. Після сорока це половина аудиторії. На 200% масштабу багато сайтів роз'їжджається.
  • Клавіатурники за звичкою. Розробники, бухгалтери, будь-хто, для кого миша повільніша за руки.

Додайте сюди пошуковики. Робот Google ходить сайтом приблизно як скрінрідер: читає структуру, заголовки, підписи до зображень. Те, що робить сторінку зрозумілою для незрячої людини, заодно робить її зрозумілою для індексації. Рідкісний випадок, коли дві різні задачі розв'язуються одним рухом.

WCAG це що

WCAG розшифровується як Web Content Accessibility Guidelines, тобто рекомендації щодо доступності вебконтенту. Пишуть їх при W3C, тому самому консорціумі, що відповідає за стандарти вебу загалом. Якщо коротко відповідати на питання «WCAG це що» — це перелік конкретних вимог до сторінки, від контрасту тексту до поведінки форм, згрупованих за суворістю.

Рівнів три:

  • Рівень A. Мінімум, без якого сайт для частини людей просто не працює.
  • Рівень AA. Робочий орієнтир. Саме на нього посилається законодавство більшості країн.
  • Рівень AAA. Максимум. Повністю його витримують одиниці, і це нормально: частина вимог там несумісна з деякими типами контенту.

Для бізнесу в Європі це вже не добра воля. European Accessibility Act набув чинності влітку 2025 року й поширюється на інтернет-магазини, банківські сервіси, електронні книги, транспортні та бронювальні платформи. Малі компанії з обігом до двох мільйонів євро мають послаблення, але відмовка «нас це не стосується» працює дедалі гірше. Частина країн уже вимагає від сайтів окрему сторінку, декларацію доступності, де власник письмово звітує, чому сайт відповідає і що ще не виправлено.

Що ми знайшли у себе

У нас на сайті три мови, перемикаються прапорцем у шапці. Виглядало все правильно, мишею працювало бездоганно.

Прохід клавіатурою показав інше. Сама кнопка з прапорцем була в коді справжньою кнопкою, тому Tab на неї ставав і список відкривався. А три варіанти всередині списку лишались звичайними блоками розмітки без жодної ознаки того, що на них можна натиснути. Tab їх не бачив, Enter на них не діяв.

Виходила пастка. Людина відкривала список мов із клавіатури й не могла ні вибрати мову, ні зрозуміти, куди поділась навігація сайту: наступне натискання Tab відправляло її кудись далі по сторінці, повз відкритий список.

Полагодили за півгодини. Кожному варіанту дописали role="button" і tabindex="0" — це те, що робить блок доступним для клавіатури й зрозумілим для скрінрідера. Додали обробку Enter і пробілу, підпис із самоназвою мови (Українська, English, Español) і позначку поточної мови через aria-current, щоб озвучувалось не просто «кнопка», а «кнопка, вибрано».

Найнеприємніше тут те, скільки ця поломка прожила. Сайт проходив перевірки, набирав бали в автоматичних інструментах, і жоден із них цього не показав. Клавіатурна пастка видна тільки живій людині, яка реально тисне Tab.

Як перевірити свій сайт за десять хвилин

Встановлювати нічого не треба, вистачить браузера.

  1. Прохід по Tab. Відкрийте головну й тисніть Tab, доки не обійдете сторінку. Питання по дорозі два: чи видно, де зараз фокус, і чи не застрягли ви десь. Те, що в англомовних інструментах позначається як wcag focus, зводиться саме до цього: видима рамка на активному елементі. Якщо в стилях стоїть outline: none без заміни, рамки немає, і людина пересувається наосліп.
  2. Меню й спливні вікна. Відкрийте кожне з клавіатури й спробуйте закрити клавішею Escape. Форма зворотного зв'язку, поп-ап із бонусом, мобільне меню ламаються частіше за звичайні посилання.
  3. Масштаб 200%. Ctrl і плюс чотири рази. Текст має лишитись читабельним, кнопки не мають наїжджати одна на одну.
  4. Контраст. Світло-сірий текст на білому виглядає стильно в макеті й не читається на телефоні під сонцем. Мінімум для звичайного тексту становить 4.5 до 1, і це перевіряється будь-яким онлайн-калькулятором контрасту.
  5. Підписи до зображень. Кожна змістовна картинка має атрибут alt з описом того, що на ній. Декоративні лишають із порожнім alt, щоб скрінрідер їх пропускав і не читав уголос назву файлу.
  6. Заголовки по порядку. Один H1 на сторінку, далі H2, усередині них H3. Перескакувати рівні не можна: скрінрідер будує по них зміст, і навігація сайту для незрячої людини відбувається саме цим списком.

Далі можна запустити Lighthouse, він убудований у Chrome, вкладка в інструментах розробника. Дасть оцінку і список зауважень. Тільки тримайте в голові поправку: автоматика ловить приблизно третину реальних проблем. Наш перемикач мов вона не зловила.

Хочете знати, чи коректно працює ваш сайт із клавіатури?

Надішліть адресу, і ми пройдемо сайт по Tab, перевіримо фокус, контраст та підписи й скажемо, що виправляти першим.

Отримати консультацію Telegram info@lulo.tech

Що видно тільки в коді

Частина речей не виявляється ні натисканням Tab, ні автоматичним інструментом.

  • Фокус, що втік за модальне вікно. Вікно відкрите, а Tab гуляє сторінкою під ним. Візуально нічого не помітно, бо вікно перекриває фон.
  • Порядок читання не збігається з візуальним. Колонки переставили стилями, а в коді вони лишились у старому порядку. Око бачить одне, скрінрідер читає інше.
  • Мовчазні повідомлення. Форма надіслалась, зелений напис з'явився, скрінрідер про це не сказав нічого. Лікується атрибутом, який позначає ділянку сторінки як живу.
  • Підписи полів форми. Підказка всередині поля зникає, щойно людина починає друкувати, і стає незрозуміло, що саме тут заповнюють.

Скільки це коштує виправити

На етапі розробки — нуль. Усе описане вище не є додатковою роботою, це звичайна акуратність: назвати кнопку кнопкою, лишити фокусну рамку, підписати картинку. Розробник, який робить так із самого початку, витрачає на це рівно стільки ж часу.

На готовому сайті ціна залежить від того, з чого він зібраний. Точкові правки на кшталт нашої займають кілька годин. Якщо сайт стоїть на конструкторі, де розмітка генерується автоматично і половина її вам не належить, можливості обмежені самою платформою.

Окремо про накладки-віджети, що обіцяють доступність сайту в один рядок коду. Вони додають поверх сторінки панель із кнопками збільшення шрифту й контрастної теми. Проблему це не розв'язує, бо код під панеллю лишається тим самим, а частина скрінрідерів від таких накладок плутається сильніше, ніж без них. У США за останні роки подали не одну сотню позовів проти сайтів, які саме таку панель і мали.

З чого почати

Якщо все це вперше, почніть із проходу по Tab. Десять хвилин, нуль інструментів, і ви одразу побачите, чи є проблема взагалі.

Якщо поломки знайшлись і незрозуміло, звідки вони — це вже аудит сайту, там про те, як перевіряти системно й у якому порядку виправляти. Такий самий розбір власного сайту ми робили раніше зі швидкістю завантаження, і причина там теж виявилась не тією, на яку думали спершу. А якщо доступність доведеться вбудовувати в сайт на шаблоні, спершу подивіться, де проходить межа можливостей конструктора: не все з цього списку там узагалі можна полагодити.

← Назад до блогу