Адаптація сайту для слабозорих користувачів

За нашими спостереженнями, сегмент людей з порушенням зору — не «вузька група», а широкий спектр: від користувачів із дальтонією та пресбіопією до людей, що тимчасово працюють за умов низької освітленості. Вони частіше збільшують шрифти, використовують екранні лупи й віддають перевагу чітким контрастним інтерфейсам із передбачуваною навігацією. На сайтах e‑commerce і фінтеху цей сегмент демонструє високу готовність купувати, якщо інтерфейс доступний і кроки зрозумілі.

У кейсі одного фарм‑e‑commerce, де ми виправили контраст, фокус, alt і навігацію по клавіатурі, кількість відмов зменшилась на 12%, конверсія з картки товару зросла на 9,3% за незмінного рекламного бюджету.

Юридичний ризик і комплаенс теж важливі. Європейські директиви (EN 301 549, WAD), ADA та стандарт WCAG 2.1/2.2: орієнтири, до яких уже тяжіють українські компанії, особливо з експортом або філіями в ЄС. Публічна заява про доступність підвищує довіру й дисциплінує внутрішні процеси: ви фіксуєте рівень відповідності (A/AA), дорожню карту та контакт для зворотного зв’язку.

Економіка проєкту проста: CAPEX – разові доробки (аудит, ремедіація, впровадження патернів), OPEX – підтримка (регрес‑тести, моніторинг, навчання). ROI складається зі скорочення витоків трафіку (зростання завершення завдань і показника конверсії), зниження ризику судових претензій та зростання LTV за рахунок утримання. У проєктах BUSINESS SITE ми рахуємо ROMI на горизонті 3–6 місяців, і в e‑commerce часто бачимо окупність за 2–3 спринта.

Практика BUSINESS SITE підтверджує: швидкі перемоги дають контрастність, видимий фокус, alt‑тексти, коректні підписи і посилання для пропуску. Ці задачі займають тижні, а не місяці, і одразу впливають на поведінку користувача.

Чек‑ліст (бізнес‑блок)

• Визначте ринок: частка мобільного трафіку, частка користувачів, які збільшують шрифт (за подіями CSS prefers-reduced-motion та zoom).
• Затвердьте ціль: зростання конверсії на X%, зниження відмов на Y%.
• Призначте відповідальних: продукт, дизайн, розробка, QA, маркетинг.
• Прийміть стандарт відповідності: WCAG 2.2 AA як цільовий.
• Підготуйте заяву про доступність (рівень, дата, дорожня карта).

Приклади коду/сніппети

Інструменти/ресурси

• Огляд WCAG: https://www.w3.org/WAI/standards-guidelines/wcag/
• Коротко про EN 301 549: https://www.etsi.org
• Посібник зі складання заяв про доступність: https://www.w3.org/WAI/planning/statements/

Шаблон заявки щодо продукту

• Заголовок: Низька контрастність CTA на мобільному
• Проблема: Контраст кнопки «Купити» 2.8:1, нижче 4.5:1.
• Кроки: Відкрити картку товару → перевірити контраст у DevTools.
• Критичність: Висока (впливає на оплату).
• Пріоритет: P1
• Критерії приймання: контраст ≥ 4.5:1 у всіх станах, перевірено WAVE/axe.

WCAG: вимоги для людей з порушеннями зору

WCAG 2.1 і 2.2, набір перевірних критеріїв (Success Criteria, SC) на рівнях A/AA/AAA. Для комерційних сайтів доцільно орієнтуватися на рівень AA: він забезпечує доступний інтерфейс без надмірних витрат. Рівень AAA корисний для окремих сценаріїв, але як загальний стандарт занадто затратний.

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

Чек‑ліст (рівень AA)

• 1.4.3 Контраст тексту ≥ 4.5:1; великий текст ≥ 3:1.
• 2.1.1 Повна клавіатурна навігація; фокус помітний.
• 2.4.1 Посилання «Перейти до вмісту»; коректні landmark-елементи.
• 3.3.1/3.3.3 Чіткі помилки форм і підказки.
• 1.4.4 Текст збільшується до 200% без втрати вмісту.

Код/фрагмент коду

Пропустити до основного вмісту
...

.skip-link { position:absolute; left:-9999px; }
.skip-link:focus { left:16px; top:16px; background:#fff; padding:8px; }

Інструменти/ресурси

• WCAG 2.2 quickref: https://www.w3.org/WAI/WCAG22/quickref/
• WAVE: https://wave.webaim.org
• axe DevTools: https://www.deque.com/axe/

Шаблон продуктового тікета

• Заголовок: Додати skip link та landmarks
• Проблема: Користувач не може швидко перейти до контенту.
• Шаги: Відкрити головну сторінку, натиснути Tab, немає видимого «Пропустити».
• Критичность: Середня
• Приоритет: P2
• Критерии приемки: Працює в NVDA/VoiceOver, покрито SC 2.4.1.

Інклюзивний веб‑дизайн: контрастність

Контрастність, фундамент. Для звичайного тексту використовуйте мінімум 4.5:1, для великого тексту (≥18pt або 14pt bold), 3:1. Використовуйте інструменти перевірки контрасту кольорів на етапі дизайну та впроваджуйте палітри в дизайн‑систему, щоб уникнути ситуативних помилок.

Враховуйте колірну сліпоту: перевіряйте палітри на деутеранопію, протанопію, тританопію. У інтерфейсах з фінансовими транзакціями (онлайн‑банк) ми додатково вводили іконки та текстові підказки, щоб акцент не залежав лише від кольору.

Контрастність тексту і фону

Вимірюйте та фіксуйте контраст безпосередньо в макетах. У Figma допомагає плагін Stark, у браузері, DevTools і розширення axe. Збережіть набір затверджених кольорових токенів у дизайн‑системі і автоматизуйте перевірку під час збірки.

@media (prefers-reduced-motion: reduce) {
  * { animation-duration: 0.01ms; animation-iteration-count: 1; transition:none; }
}

Чек‑ліст

• Перевірити контраст усіх станів кнопок/посилань.
• Обмежити довжину рядка, налаштувати line-height.
• Використовувати rem/em для масштабування шрифту.
• Емулювати дальтонізм (Stark/Sim Daltonism).
• Увімкнути prefers-reduced-motion для анімацій.

Інструменти

• Stark (Figma): https://www.getstark.co
• TPGi CCA: https://www.tpgi.com/color-contrast-checker/

Шаблон заявки на продукт

• Заголовок: Неприйнятна контрастність вторинних посилань
• Проблема: Колір #8ea4c8 на білому дає ~2.7:1.
• Кроки: Перевірка через CCA на картці товару.
• Критичність: Висока
• Пріоритет: P1
• Критерії прийняття: Контраст ≥ 4.5:1, оновлені токени в дизайн‑системі.

Типографіка для людей із порушеннями зору

Рекомендації: базовий розмір шрифту не менше 16px, на десктопі 18–20px для основного тексту в B2C‑сценаріях; line-height 1.5; інтерлініяж та міжбуквений інтервал: для заголовків акуратно, без «сплющування». Масштабування шрифту до 200% не повинно ламати сітку та важливі CTA.

html { font-size: 100%; }
body { font-size: 1rem; line-height: 1.5; }
h1 { font-size: clamp(1.8rem, 2.5vw, 2.4rem); }

ARIA і семантичний HTML для доступності

Я завжди рекомендую: спочатку семантичний HTML, потім ARIA. Нативні елементи: кнопки, посилання, поля форм вже містять правильні ролі та поведінку. Якщо потрібен кастомний компонент, додавайте ARIA-ролі обережно і лише за потреби.

Semantic landmarks (header, nav, main, footer) та заголовки h1–h6 створюють логічну структуру для скрінрідерів NVDA, JAWS, VoiceOver і TalkBack. Це пришвидшує навігацію і знижує час виконання завдання.

Контрольний список

• Перевірити, де нативні елементи замінені div/span → повернути native.
• Для динаміки додати aria-live, описати поведінку.
• Додати landmarks і коректні заголовки.
• Задокументувати ARIA в бібліотеці компонентів.

Інструменти

• Практики ARIA: https://www.w3.org/WAI/ARIA/apg/
• Керівництво з орієнтирів: https://www.w3.org/WAI/tutorials/page-structure/

Шаблон продуктового тікета

• Заголовок: Додати aria-live для повідомлень «товар у кошику»
• Проблема: Скрінрідер мовчить під час додавання товару.
• Шаги: NVDA + Firefox, «Додати в кошик» → немає озвучення.
• Критичность: Середня
• Приоритет: P2
• Критерии приемки: Повідомлення читається NVDA/JAWS/VoiceOver.

Помилки ARIA та антипатерни

Поширені помилки: роль button на div без поведінки клавіатури; приховування фокусу; aria-hidden на активних елементах; надмірне використання aria‑* там, де достатньо вбудованих можливостей. Рекомендується замінювати role=”button” на , а якщо компонент кастомний, забезпечити підтримку Enter/Space та можливість фокусування.

Код/сніппет (анти‑патерн → виправлення):

Добре

Добре

Навігація, фокус, доступ з клавіатури

Клавіатурна навігація обов’язкова: порядок Tab логічний, фокус видимий і контрастний, інтерактивні елементи доступні через Enter/Space. Додавайте посилання «Пропустити» та керуйте фокусом у модалках і SPA‑сценаріях, щоб користувач не втратив контекст.

Перевірте сумісність з екранними лупами та збільшувачами: вікна повинні масштабуватися, підказки: не перекривати поля, таблиці: мати фіксований порядок табуляції та заголовки.

:focus { outline: 2px solid #0a84ff; outline-offset: 2px; }

Контрольний список

• Повна навігація клавіатурою, без пасток фокусу.
• Видимий фокус на всіх інтерактивних елементах.
• Керування фокусом при відкритті/закритті модальних вікон.
• Посилання-пропуски (skip links), логічний порядок натискання Tab.
• Тест у NVDA/VoiceOver, перевірка за допомогою екранної лупи.

Інструменти

• NVDA: https://www.nvaccess.org
• JAWS: https://www.freedomscientific.com
• Посібник VoiceOver: https://support.apple.com/guide/voiceover
• TalkBack: https://support.google.com/accessibility/android

Шаблон заявки на продукт

• Заголовок: Додати керування фокусом у модальному вікні оплати
• Проблема: Фокус зникає під шаром, з клавіатури складно завершити оплату.
• Кроки: Відкрити модалку, натиснути Tab → фокус виходить за межі.
• Критичність: Висока
• Пріоритет: P1
• Критерії прийняття: Фокус захоплюється при відкритті, повертається на тригер при закритті.

Кнопки та навігація для слабозорих

Проєктуйте клікабельні області 44×44px і більше, використовуйте зрозумілі підписи та явні стани наведення/активації. Посилання мають виглядати як посилання, кнопки: як кнопки; змішування стилів ускладнює сприйняття.

button, .btn, a.btn { min-width: 44px; min-height: 44px; }
a { text-decoration: underline; }
a:hover { text-decoration-thickness: 2px; }

альтернативний текст, аудіоопис і субтитри

Alt‑текст має передавати мету зображення в контексті. Декоративні зображення мають порожній alt=””. Інформаційні графіки й SVG, з ролями та описами; складні діаграми – з розгорнутим текстовим описом поруч або за посиланням.

Коректні alt‑атрибути допомагають пошуку: зображення товарів із релевантними підписами покращують видимість у image‑пошуку та картках.

Чекліст

• Alt за призначенням: інформативний, короткий, без «зображення».
• Порожній alt для декоративних картинок.
• Довгі описи для складних графіків.
• Субтитри/транскрипти для відео/аудіо.
• Перевірка озвучення в NVDA/JAWS.

Інструменти

• W3C дерево рішень для alt: https://www.w3.org/WAI/tutorials/images/decision-tree/
• Інструменти субтитрів YouTube, Amara: https://amara.org

Шаблон заявки на продукт

• Заголовок: Додати субтитри до відео «Оплата і доставка»
• Проблема: Немає субтитрів, втрата контексту.
• Кроки: Відкрити відео, вимкнути звук → інформація недоступна.
• Критичність: Середня
• Пріоритет: P2
• Критерії прийняття: Субтитри та транскрипт опубліковані, перевірені на синхронізацію.

Альтернативний текст для зображень

Правильно: alt=”Тонометр для зап’ястя, модель X200, акція -15%”. Неправильно: alt=”фото товару”. Якщо зображення: кнопка або посилання, alt/aria-label повинні описувати дію: alt=”Додати тонометр X200 до кошика”. Для колекцій продуктів використовуйте єдиний шаблон alt, щоб покращити послідовність.

Форми та валідація для слабозорих

Кожне поле: з label, пов’язаною через for/id, або з aria-label, якщо label візуально приховано. Помилки форм описуйте текстом, зв’язуйте через aria-describedby, озвучуйте через live region. Підказуйте формат введення заздалегідь, а не постфактум.

Електронна пошта

Ми надішлемо чек

Контрольний список

• Скрізь є мітки і підказки, пов’язані з полями.
• Помилки читаються скрінрідером, явно підсвічені.
• Фокус переходить до першої помилки.
• Альтернатива CAPTCHA без візуальних завдань.
• Дати/телефони: маски з підказками формату.

Інструменти

• Інклюзивні форми: https://www.w3.org/WAI/tutorials/forms/
• Шаблони GOV.UK Design System: https://design-system.service.gov.uk

Шаблон продуктового тікета

• Заголовок: Доступна валідація форми реєстрації
• Проблема: Помилки не озвучуються, відсутні aria-describedby.
• Кроки: Залишити поле порожнім → відправити → скрінрідер мовчить.
• Критичність: Висока
• Пріоритет: P1
• Критерії прийняття: Помилки видимі/озвучені, фокус на першій помилці.

Інструменти перевірки доступності

Автоінструменти виявляють до 30–40% проблем. axe‑core, Google Lighthouse, WAVE, Pa11y і Tenon.io виявляють явні порушення: контраст, відсутні alt, невірні ролі. Ручний аудит закриває сценарії: логіка навігації, управління фокусом, очікувана поведінка ARIA.

Контрольний список аудиту

• Запуск Lighthouse Accessibility ≥ 90.
• WAVE/axe без критичних помилок.
• Ручна перевірка за допомогою клавіатури (без миші).
• NVDA/VoiceOver: перевірка важливих сценаріїв.
• Звіт у вигляді remediation tickets.

pa11y https://example.com --threshold 0 --reporter json > pa11y.json

Інструменти

• Lighthouse: https://developers.google.com/web/tools/lighthouse
• axe-core: https://github.com/dequelabs/axe-core
• Pa11y: https://pa11y.org
• Tenon: https://tenon.io

Шаблон тікета продукту

• Заголовок: Виправити помилки axe на сторінці кошика
• Проблема: 6 порушень (контраст, aria-roles).
• Кроки: Запустити axe → зберегти звіт.
• Критичність: Висока
• Пріоритет: P1
• Критерії приймання: 0 критичних помилок, 0 серйозних попереджень.

Вибір інструментів аудиту доступності

Зверніть увагу на інтеграцію в CI, покриття SC, зручність звітів та підтримку. Для мультисайтів корисний headless‑режим та експорт у JSON/HTML. axe‑core CLI та Pa11y добре підходять для пайплайнів, WAVE — для швидких ручних перевірок, Lighthouse — для підсумкової оцінки.

Тестування при зниженому зорі

Рекрутинг учасників проводьте етично: компенсація часу, зрозумілі інструкції, підтримка під час тестів. Шукайте користувачів із дальтонізмом, низькою гостротою зору, тих, хто використовує скрінрідер NVDA/JAWS, VoiceOver або TalkBack.

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

Контрольний список

• Визначити профілі учасників і сценарії.
• Провести пілотну сесію, відкалібрувати сценарії.
• Тести з NVDA/VoiceOver/TalkBack і екранними лупами.
• Зібрати метрики та NPS, сформувати рекомендації.
• Конвертувати результати в тікети з пріоритетами.

Інструменти

• ZoomText/Лупа Windows
• Зчитувачі екрану (посилання вище)

Шаблон продуктового тікета

• Заголовок: Покращити навігацію в розділі «Акції»
• Проблема: Користувачі з лупою втрачають контекст навігації.
• Шаги: Тест з лупою 200% на мобільному, пошук «Акції».
• Критичность: Середня
• Приоритет: P2
• Критерии приемки: Час на виконання завдання ↓ на 20% у повторному тесті.

План впровадження, пріоритизація та бюджет

Стратегія впровадження: discovery (цілі, аудиторія), аудит (авто + ручний), швидкі перемоги (контраст, фокус, alt, labels, skip links), sprint‑ремедіація (компоненти, форми, модалки), регресійне тестування (CI). Пріоритизуйте remediation‑тікети за впливом на користувачів, складністю виправлення та юридичними ризиками.

Контрольний список

• Затвердити scope AA та список сторінок.
• Сформувати backlog та RICE‑оцінку тікетів.
• Виділити бюджет CAPEX (аудит + фікс) та OPEX (регресії).
• Призначити SLA на виправлення критичних регресій.
• Запланувати навчання команди.

:root { --focus-color: #0a84ff; --focus-width: 2px; }
:focus { outline: var(--focus-width) solid var(--focus-color); }

Інструменти

• RICE пріоритизація: фреймворк Intercom
• Jira/YouTrack шаблони тікетів

Шаблон заявки на продукт

• Заголовок: Увімкнути фокус‑токени на рівні дизайн‑системи
• Проблема: Неузгоджений фокус у компонентах.
• Шаги: Перевірити Button, Link, Input у Storybook.
• Критичность: Середня
• Приоритет: P2
• Критерии приемки: Єдиний фокус у компонентах, покриття Storybook.

План впровадження доступності для сайту

30 днів (малий сайт): аудит + швидкі перемоги + заява про доступність. 60 днів (середній): ремедіація компонентів, форми, навігація, автоматизація перевірок. 90 днів (великий): CI/CD, регресії, користувацькі тести, оновлення дизайн‑системи та документації.

CI/CD і моніторинг регресій

Інтегруйте тести доступності в pipeline: запуск Pa11y/axe-core CLI на ключових маршрутах, падіння збірки при критичних порушеннях. Додайте тестування регресій доступності: скриншоти та DOM‑знімки, щоб відстежувати контраст, атрибути, ролі.

- name: Pa11y audit
  run: pa11y-ci --config .pa11yci

Контрольний список

• Налаштувати CI з порогами помилок.
• Додати маршрути для аудиту (головна, пошук, кошик, оформлення).
• Увімкнути візуальні регрес‑тести ключових екранів.
• Оновити Definition of Done (WCAG AA).
• Вести публічний журнал змін доступності.

Інструменти

• pa11y-ci: https://github.com/pa11y/ci
• axe-core CLI: https://github.com/dequelabs/axe-core-npm

Шаблон тікета продукту

• Заголовок: Додати pa11y-ci в GitHub Actions
• Проблема: Немає автоматичної перевірки доступності.
• Кроки: Налаштувати конфіг, додати маршрути, пороги.
• Критичність: Середня
• Пріоритет: P2
• Критерії приймання: Пайплайн падає при критичних порушеннях.

KPI та метрики доступності для конверсії

Вимірюйте: виконання завдання, час на завдання, коефіцієнт конверсії, зменшення відмов, NPS. Зв’язуйте метрики з воронкою: картка товару → корзина → оплата (Нова Пошта + картка). Доступність підвищує передбачуваність сценаріїв і знижує когнітивне навантаження, що відображається на метриках.

Для звітності використовуйте дашборди: KPI щодо стану WCAG (кількість порушень), продуктові метрики, NPS для користувачів з асистивними технологіями. Це створює загальну картину для маркетингу та продукту.

Контрольний список

• Визначити базові метрики та цільові значення.
• Налаштувати події для assistive‑патернів (skip link click, zoom, prefers-reduced-motion).
• Завести дашборд з трендами по конверсії та відмовам.
• Планувати A/B на контраст/фокус/форми.
• Узгодити формат щомісячного звіту.

document.querySelector('.skip-link')
  ?.addEventListener('click', ()=>analytics.track('skip_link_used'));

Інструменти

• Amplitude/Mixpanel/ga4 події
• Looker/Data Studio для дашбордів

Шаблон заявки на продукт

• Заголовок: Додати відстеження подій доступності
• Проблема: Немає даних про використання skip link та zoom.
• Кроки: Налаштувати події, перевірити у звіті.
• Критичність: Низька
• Пріоритет: P3
• Критерії прийняття: Події у дашборді, сегменти порівнювані.

Шаблони та чек-листи для старту

Готові чеклісти

• Дизайн: контраст 4.5:1, довжина рядка, line-height, дальтонізм.
• Розробка: семантичний HTML, фокус, skip links, ARIA live.
• QA: перевірка клавіатурою, NVDA/VoiceOver, Lighthouse ≥ 90, WAVE/axe без критичних.

Ресурси

• WebAIM: https://webaim.org
• W3C WAI Посібники: https://www.w3.org/WAI/tutorials/

Контрольний список

• Вибрати 1 кейс‑метрику для швидкого покращення.
• Затвердити набір обов’язкових компонентів дизайн‑системи.
• Створити шаблони тікетів за категоріями проблем.
• Призначити відповідальних за напрямами.

  Популярне
  Новинки

...

Шаблон заявки на продукт

• Заголовок: Впровадити доступні вкладки в каталозі
• Проблема: Вкладки на div, навігація за клавішами відсутня.
• Кроки: Перевірити стрілки/Tab, скрінрідер не повідомляє контекст.
• Критичність: Середня
• Пріоритет: P2
• Критерії прийняття: ARIA ролі, клавіші стрілок/Enter, озвучення NVDA.

Висновок і заклик до дії

Я вважаю, що доступність — дисципліна ефективності. У підсумку ви отримуєте: ширше охоплення, передбачувану конверсію, стійку репутацію та комплаєнс. Практика BUSINESS SITE показує, що швидкі перемоги у контрасті, фокусі, формах і навігації призводять до вимірюваних результатів за один‑два спринта, а системний підхід через дизайн‑систему та CI/CD закріплює ефект.

Рекомендовані перші кроки: 1) провести комбінований аудит (axe/Lighthouse + ручний), 2) закрити швидкі перемоги у головних сценаріях (каталог → кошик → оплата), 3) зафіксувати AA як цільовий рівень і опублікувати заяву про доступність. Для маркетингу це прозоро: метрики і ROI, для розробки: зрозумілий беклог, для керівництва — керований ризик і зростання воронки.

Контрольний список завершення

• Затвердити рівень AA та roadmap.
• Запустити аудит та закрити швидкі перемоги.
• Налаштувати регрес‑тести в CI.
• Опублікувати заяву про доступність.
• Сформувати дашборд KPI.

Шаблон запиту щодо продукту

• Заголовок: Опублікувати публічну заяву про доступність
• Проблема: Відсутні публічне зобов’язання та контакт.
• Кроки: Підготувати текст, додати у футер, повідомити команду.
• Критичність: Низька
• Пріоритет: P3
• Критерії приймання: Сторінка доступна, містить рівень, дату та контакт.

Поширені питання

Контрольний список

• Використовувати Lighthouse/WAVE для первинного зрізу.
• Підключити axe‑core/Pa11y у CI.
• Узгодити пороги провалу пайплайну.
• Запланувати навчальний воркшоп для команди.
• Додати FAQ на внутрішній портал.

Шаблон заявки на продукт

• Заголовок: Підготувати воркшоп з доступності для команди
• Проблема: Брак компетенцій, ризик регресій.
• Кроки: Сформувати програму, зібрати приклади, призначити дату.
• Критичність: Низька
• Пріоритет: P3
• Критерії прийняття: Проведено навчання, матеріали доступні, питання зібрані.

P.S. За моїм досвідом, коли доступність стає частиною Definition of Done, маркетинг отримує стійке зростання ефективності, продукт — керовану воронку, а бренд — довіру. У BUSINESS SITE ми дотримуємося цієї практики в усіх проєктах: від фарм‑e‑commerce до фінтех‑сервісів і туристичних порталів.