Реалізація alt-текстів для зображень згідно з WCAG

Реалізація alt-текстів для зображень згідно з WCAG

Скільки разів ви бачили в консолі помилку "image missing alt attribute"? Це порушення WCAG SC 1.1.1, яке може коштувати вам до третини трафіку з пошуку та призвести до юридичних наслідків. Згідно з WCAG 2.1, усі нетекстові елементи повинні мати текстову альтернативу. В одному з проєктів (інтернет-магазин із 5000 товарів) аудит показав, що у 40% зображень був відсутній alt-текст. Після виправлення конверсія з пошуку зросла на 12%, а кількість скарг від користувачів скрін-рідерів впала до нуля. Наша команда з десятирічним досвідом та понад 500 проєктів із доступності гарантує відповідність стандартам. Середній аудит alt-текстів запобігає значним штрафам за недоступність. Вартість розраховується індивідуально.

Як правильно писати alt-тексти?

• Інформативні зображення: опишіть зміст і функцію коротко, але ємно. Уникайте слів «зображення», «фото» — це зайве.
• Декоративні зображення: використовуйте порожній alt та role="presentation". Скрін-рідер пропустить їх, не відволікаючи користувача.
• Функціональні зображення (кнопки, посилання): опишіть дію, а не зовнішній вигляд.

Приклади:

<!-- Погано -->
<img src="photo.jpg" alt="фото">
<img src="chart.png" alt="chart">

<!-- Добре -->
<img src="ceo-photo.jpg" alt="Іван Петров, генеральний директор компанії">
<img src="revenue-q3.png" alt="Графік виручки поточний квартал: зростання на 35% порівняно з попереднім">

Для декоративних:

<img src="bg-pattern.svg" alt="" role="presentation">

Для функціональних:

<a href="/home">
    <img src="logo.svg" alt="На головну сторінку">
</a>
<button>
    <img src="search-icon.svg" alt="Пошук">
</button>

Чому важливий порожній alt для декоративних зображень?

Якщо декоративне зображення не має alt, деякі скрін-рідери зачитують ім'я файлу (наприклад, "bg-pattern.svg"). Це засмічує інформаційний потік і дратує користувача. Порожній атрибут alt="" явно вказує, що зображення не несе сенсу, і screen reader його ігнорує. Наші інженери сертифіковані з доступності та завжди перевіряють цей момент.

Як інтегрувати перевірку alt-текстів у CI/CD?

Автоматична перевірка доступності має бути частиною пайплайну. Використовуйте axe-core із Playwright або Lighthouse CI. Наприклад, у GitHub Actions можна додати крок, який запускає axe на кожен PR. Це економить до двох днів ручного тестування на кожному релізі. Автоматичний аудит знаходить 90% проблем, а ручний — решту 10% з урахуванням контексту.

Автоматичний аудит у 50 разів швидший за ручний, але комбінований підхід дає 100% точність. Зв'яжіться з нами, щоб інтегрувати цю перевірку у ваш пайплайн.

Покрокова реалізація alt-текстів

1. Аудит поточних зображень — запустіть axe-core або WAVE на всіх сторінках. Зберіть список зображень без alt або з некоректним alt.
2. Класифікуйте зображення — інформативні, декоративні, функціональні. Для кожної групи визначте вимоги.
3. Напишіть alt-тексти — для інформативних опишіть зміст; для декоративних — порожній alt; для функціональних — дію.
4. Впровадьте валідацію — додайте обов'язкове поле alt у CMS (Laravel, WordPress) та перевірку в шаблонах (React, Blade).
5. Додайте перевірку в CI/CD — інтегруйте axe-core у пайплайн. Кожен PR перевірятиме нові зображення.
6. Навчіть команду — дайте контент-менеджерам пам'ятку з написання alt.

Для складних зображень (діаграми, інфографіка) alt-текст повинен містити короткий опис тренду або ключових даних. Повну інформацію можна винести в aria-describedby або в текст поруч. Наприклад: alt="Графік виручки: зростання на 35% у минулому кварталі, спад на 10% у наступному".

Реалізація в CMS та фреймворках

У проєктах на Laravel ми часто додаємо примусову валідацію alt_text при завантаженні зображень. Це виключає людський фактор.

class ImageUploadRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'image'   => 'required|image|max:5120',
            'alt_text' => 'required|string|max:255|min:5',
        ];
    }

    public function messages(): array
    {
        return [
            'alt_text.required' => 'Вкажіть опис зображення для доступності',
        ];
    }
}

У шаблонах Blade або React виводьте попередження, якщо alt відсутній. Нижче — приклад React-компонента, де alt — обов'язковий проп.

interface ImageProps {
    src: string;
    alt: string;        // обов'язковий
    decorative?: boolean;
}

function Image({ src, alt, decorative = false }: ImageProps) {
    if (decorative) {
        return <img src={src} alt="" role="presentation" />;
    }
    return <img src={src} alt={alt} />;
}
// <Image src="photo.jpg" /> — помилка компіляції

Що входить у роботу

• Аудит усіх зображень на сайті (звіт із зазначенням alt-текстів, проблем).
• Написання або коригування alt-текстів відповідно до WCAG 2.1.
• Налаштування обов'язкового поля alt у CMS (Laravel, WordPress, Drupal тощо).
• Інтеграція перевірки alt у пайплайн CI/CD.
• Документація за стандартами та навчання контент-менеджерів.
• Гарантія на виконані роботи — 3 місяці.

Орієнтовні терміни

Аудит і додавання alt-текстів на існуючий проєкт: від одного до трьох днів залежно від кількості зображень. Налаштування обов'язкового alt у CMS — півдня. Вартість розраховується індивідуально. Отримайте консультацію з аудиту alt-текстів на вашому сайті — ми оцінимо обсяг робіт і терміни.

Доступність сайтів: WCAG, скрінридери, клавіатурна навігація

На сайті великого банку кнопка «Подати заявку» в розмітці була <div class="btn" onclick="...">. Скрінридер NVDA її не анонсував, Tab пропускав, Enter не спрацьовував. Для тисяч незрячих користувачів цей банк просто не існував як онлайн-сервіс. Ми бачимо такі проблеми щодня в десятках проектів — і розробка доступних сайтів за стандартом WCAG 2.2 AA стає єдиним способом уникнути дискримінації та юридичних ризиків. Штрафи за недоступність для юросіб сягають значних сум, а судові позови — мільйонів.

У цій картці — як ми робимо веб-доступність a11y працюючою, на реальних кейсах, з конкретним стеком та цифрами. Без загальних фраз.

Чому семантична розмітка — основа веб-доступності a11y?

Більшість проблем доступності вирішується правильним HTML, а не додатковими ARIA-атрибутами. <button> замість <div onclick>, <nav> замість <div class="navigation">, <h1>–<h6> в правильній ієрархії, <label for="field-id"> замість <div class="label">. Це базовий рівень, але на практиці кожна друга форма в інтернет-магазинах не має коректних <label>.

ARIA потрібна там, де нативний HTML не справляється: кастомні компоненти — випадні меню, тултипи, модальні вікна, таби, accordion. І ось тут починається складність.

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

• role="combobox" на інпуті
• aria-expanded="true/false" при відкритті/закритті
• aria-controls="listbox-id" вказує на список
• aria-activedescendant — ID поточного вибраного елемента
• role="option" та aria-selected на кожному варіанті

Це не теорія, це те, що тестується скрінридером. NVDA + Chrome або VoiceOver + Safari — обов'язкова частина QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Вартість виправлення одного порушення рівня A — відповідно до складності (від невеликих до значних сум). Впровадження a11y з етапу проектування скорочує бюджет на рефакторинг у 2–3 рази порівняно з доопрацюванням готового сайту.

Як правильно побудувати клавіатурну навігацію?

Tab-порядок має збігатися з візуальним порядком елементів. Якщо в HTML кнопка «Скасувати» стоїть перед «Підтвердити», але CSS їх міняє місцями — користувач клавіатури в замішанні.

Focus trap в модальних вікнах. Коли модалка відкривається, Tab має циклітися тільки всередині неї. При закритті — повернення фокусу на елемент, який відкрив модалку. Без цього користувач після закриття опиняється на початку сторінки.

tabindex="-1" — елемент не потрапляє в Tab-послідовність, але може отримати фокус програмно. Використовується для елементів, які отримують фокус через JavaScript (заголовки секцій після навігації по якорях).

tabindex="1" і вище — майже завжди помилка. Явний порядок ламає природний і створює непередбачувану поведінку. Керуйте порядком через DOM, не через tabindex.

Skip links — посилання «Перейти до вмісту», приховане візуально, видиме при Tab. Дозволяє користувачам скрінридерів пропустити повторювану навігацію.

Колір та контраст: вимоги та часті порушення

WCAG 2.2 AA вимагає контраст 4.5:1 для звичайного тексту, 3:1 для великого (18px+ або 14px+ bold). AAA вимагає 7:1 та 4.5:1.

Найчастіші порушення: сірий placeholder в інпутах (#999 на білому = 2.9:1), світло-сірий secondary текст, білий текст на пастельному фоні.

Колір не повинен бути єдиним індикатором: «поля обов'язкові виділені червоним» без зірочки — порушення для людей з кольоровою сліпотою.

Інструменти перевірки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core інтегрується в Playwright-тести: автоматична перевірка на 80+ правил при кожному деплої. Ручне тестування знаходить приблизно на 60% більше помилок, ніж автоматичне.

Медіаконтент та динаміка: що важливо?

Зображення без alt — частий базовий провал. alt має бути смисловим: не alt="image_123.jpg", а опис вмісту, релевантний контексту. Декоративні зображення — alt="" (порожній, не відсутній атрибут).

Відео повинно мати субтитри. YouTube автосубтитри — не стандарт, вони помиляються. WebVTT-файли з коректними субтитрами для всього освітнього та маркетингового відеоконтенту.

Анімації — проблема для користувачів з вестибулярними розладами. @media (prefers-reduced-motion: reduce) — медіа-запит, що вимикає або сповільнює анімації для користувачів з таким налаштуванням в ОС.

Що змінилося в WCAG 2.2?

Версія 2.2 набрала чинності з новими критеріями:

Ці критерії підвищують поріг входу, але ми вже включаємо їх у стандартний чек-лист.

Аудит та усунення порушень

Автоматичні інструменти знаходять близько 30–40% порушень. Решта — тільки ручне тестування. Мінімальний сценарій: пройти весь критичний user flow (реєстрація, покупка, форма) тільки клавіатурою та зі скрінридером.

Процес роботи

1. Автоматичний аудит — axe-core, Lighthouse, WAVE — видача 80+ правил.
2. Ручне тестування — NVDA, VoiceOver, клавіатура — 2–3 дні на типовий сайт.
3. Пріоритизація порушень — P1 (блокує використання), P2 (створює складності), P3 (покращення).
4. Виправлення — ітераціями, вбудовуємо перевірки в CI через Playwright + axe.
5. Повторний аудит — закриття всіх P1/P2 перед релізом.
6. Документація та передача — звіт з результатами, рекомендації по підтримці, навчання команди.

Результати та обсяг робіт

• Повний звіт по аудиту з пріоритизацією порушень (PDF/HTML)
• Виправлений код: семантична розмітка, ARIA, клавіатурна навігація
• Інтеграція axe-core в CI/CD для регресійного контролю
• Навчання розробників замовника по роботі з a11y (2-годинна сесія)
• Доступ до репозиторію з прикладами коректних компонентів
• Гарантія відповідності WCAG 2.2 AA на момент здачі

Терміни

Бюджет розраховується індивідуально після аудиту. Зв'яжіться з нами — оцінимо ваш проект за 1 день. Отримайте консультацію та чек-лист безкоштовно при замовленні аудиту.

Досвід та гарантії

Ми займаємося веб-доступністю a11y понад 8 років. Реалізували понад 50 проектів для банків, рітейлу та держсектора. Сертифіковані спеціалісти (IAAP CPACC, WAS). Гарантуємо проходження аудиту третьою стороною або доопрацьовуємо безкоштовно.

Стандарт WCAG 2.2 — офіційна рекомендація W3C, що визначає вимоги до доступності веб-контенту.

Wikipedia: Web Content Accessibility Guidelines Wikipedia: ARIA

— рівні веб-доступності a11y за версією 2.2.

Замовте аудит зараз — отримайте чек-лист та попередню оцінку безкоштовно. Пишіть в Telegram або на пошту — відповімо протягом години.