Що означає доступність вебсайту
Доступність вебсайту, або доступність вебсайту що це на практиці, означає, що люди можуть користуватися сайтом без зайвих труднощів. Людина зі скрінрідером, відвідувач, який користується лише клавіатурою, користувач телефону на яскравому світлі та людина зі слабким зором бачать ту саму сторінку, але мають різні потреби — і сторінка все одно має працювати для кожного.
Звучить просто. Насправді — рідко.
Хороший підхід до доступності не починається лише з технологій. Він починається з одного запитання: чи може людина виконати завдання за 3 кліки, мишкою, лише клавіатурою або за допомогою допоміжного програмного забезпечення? Якщо хоча б один шлях не працює, сайт складніший, ніж має бути.
Доступність також допомагає звичайним користувачам у звичайних ситуаціях. Субтитри допомагають у шумному вокзалі чи потязі. Чіткі стани фокуса допомагають тому, хто втратив курсор із поля зору. Добре структуровані заголовки дозволяють швидко переглянути довгу сторінку за 20 секунд замість 2 хвилин.
Команди часто сприймають доступність як окрему функцію. Це хибний підхід. Вона має бути частиною структури, тексту, форм, медіа та навігації. Якщо ви вже працювали над корпоративним сайтом, то знаєте, що структура впливає на кожну сторінку; доступність просто робить цю структуру зручною для більшої кількості людей.
Що означає відповідність WCAG
WCAG — це скорочення від Web Content Accessibility Guidelines, тобто настанов із доступності вебконтенту. Якщо потрібне коротке пояснення для команди, WCAG українською найчастіше описують як набір правил і критеріїв, які допомагають зробити вебконтент доступнішим. Це оприлюднений стандарт для того, щоб вебконтент був доступнішим, і про відповідність WCAG часто говорять так, ніби це один перемикач. Але це не так.
Відповідність WCAG означає, що сайт відповідає релевантним критеріям успіху на визначеному рівні. Більшість команд орієнтуються на AA, бо це хороший баланс між практичними зусиллями та реальним ефектом. Сайт може бути частково відповідним, майже відповідним або повністю відповідним — залежно від того, що вже перевірили і що ще не проходить.
Також є різниця між дотриманням окремих настанов і дотриманням стандарту в цілому. Сторінка з alt-текстом для зображень, але зламаною навігацією клавіатурою, не є «достатньо доступною» лише тому, що один пункт виконано. Сайт із чудовим контрастом, але без підписів до полів форми, усе одно залишає людей без можливості діяти.
Думайте про відповідність WCAG як про дисципліну, а не як про відзнаку. Стандарт дає вам критерії, які можна перевірити, а ці критерії допомагають командам уникати розмитих обіцянок. Якщо в огляді згадується «як зробити сайт доступним і що означає відповідність WCAG», треба пов’язати обидві частини: одне — це практична робота, інше — стандарт, за яким її оцінюють.
Почніть з аудиту доступності
Аудит доступності сайту дає перший список проблем. Почніть із вибірки з 10–20 важливих сторінок, а не з усього сайту одразу, бо типові бар’єри зазвичай повторюються: відсутній alt-текст, низький контраст, пастки для клавіатури, безіменні форми та заголовки, що стрибають з H2 на H4 без причини.
Використовуйте і автоматичні перевірки, і ручний перегляд. Автоматизація швидко знаходить шаблонні помилки, але не скаже, чи логічний підпис кнопки в контексті та чи модальне вікно закривається коректно. Одна швидка ручна перевірка клавіатурою може виявити більше, ніж 50 автоматичних сповіщень.
Перевіряйте зображення по черзі. Декоративні зображення зазвичай варто ігнорувати для допоміжних технологій, а змістовним потрібен alt-текст, який передає суть. «Графік зростання продажів у 2024 році» краще, ніж «графік», а «Фото команди» краще, ніж «image123».
Форми потребують особливої уваги. Кожне поле має мати чітку мітку, а не лише текст-підказку, бо підказки зникають, коли людина починає вводити дані. Поле входу без мітки перетворюється на вгадування. Це помилка вже на першому кроці.
Перевіряйте заголовки за простою схемою. Заголовки не повинні використовуватися лише для стилізації, і користувач має мати змогу швидко переглянути структуру по порядку. Якщо структура хаотична, сторінка важча і для користувачів скрінрідера, і для всіх, хто хоче читати швидко.
Створюйте доступну структуру контенту
Доступна структура контенту починається з семантичних заголовків. Використовуйте H2 для основних розділів і H3 для підтем. Суть не в оформленні, а в навігації. Користувачі скрінрідерів переходять між заголовками, а чіткий план дозволяє рухатися сторінкою за секунди, а не читати кожен рядок.
Організація сторінки не менш важлива. Розміщуйте головне завдання ближче до початку, тримайте пов’язаний контент разом і не розкидайте ключові дії по п’яти несуміжних блоках. Один зрозумілий шлях кращий за три конкурентих. Хаотичне компонування може перетворити просту дію на головоломку.
Посилання мають пояснювати, куди ведуть. «Докладніше» саме по собі слабке. «Докладніше про підтримку сайту після запуску» одразу говорить користувачу, що він отримає, і це важливо, коли на сторінці є 12 посилань. Використовуйте описовий текст щоразу, коли напрямок неочевидний із навколишнього речення.
Для практичного прикладу порівняйте «завантажити» і «завантажити PDF-чеклист із доступності». Другий варіант довший, але ним можна користуватися. У списку посилань для скрінрідера зайві слова не є баластом; це карта.
Alt-текст має бути змістовним, а не театральним. Фотографії продукту може знадобитися назва продукту й одна відмінна деталь. Для скріншота може бути потрібне коротке пояснення стану інтерфейсу. Декоративний елемент може залишитися без опису. Таке розрізнення економить час користувачам, які слухають кожен опис зображення послідовно.
Читабельний текст також має значення. Короткі абзаци допомагають. Ще більше допомагає проста мова. Якщо одне речення виконує роботу цілого абзацу, розбийте його. Якщо в реченні три думки, зробіть із нього 2 речення. Скрінрідери справляються з довгим текстом, але людська увага має межі.
Сторінка, побудована так, також добре працює для контентно насичених проєктів, зокрема контентного порталу про інвестиції, де користувачам потрібні швидкий перегляд, чітке розбиття на розділи та терміни, які не змінюються від сторінки до сторінки.
Зробіть навігацію та елементи керування зручними для клавіатури
Доступ через клавіатуру — не опція, а необхідність. Меню, кнопки, діалоги та форми мають працювати без миші. Якщо людина може перейти до елемента клавішею Tab, але не може його активувати, цей елемент зламаний.
Спершу перевірте порядок переходу клавішею Tab. Натискайте Tab по сторінці й дивіться, чи фокус рухається логічно зверху вниз, зліва направо. Якщо фокус перескакує на прихований елемент або пропускає важливу кнопку, сторінку треба виправити. Видимість фокуса не менш важлива; якщо ви не бачите, де знаходиться клавіатура, ви лише здогадуєтеся.
Діалоги потребують клавіші Escape або іншої зрозумілої дії закриття. Фокус має переходити в діалог під час відкриття, а після закриття повертатися до елемента, який його відкрив. Без цього користувачі клавіатури можуть опинитися в пастці або загубитися. Ніхто не хоче натискати Tab 18 разів, щоб знайти вихід.
Меню мають відкриватися і закриватися передбачувано. Меню, яке працює лише при наведенні, — недостатнє. Випадний список, що залежить від курсора миші, може одночасно відрізати і користувачів клавіатури, і сенсорних пристроїв. Правило просте: якщо елемент існує, ним слід керувати більше ніж одним способом.
Форми заслуговують ще однієї перевірки. Повідомлення про помилки мають з’являтися біля поля, бути зрозумілими й бути пов’язаними саме з цим полем. Повідомлення, яке лише каже «недійсне введення», не допомагає нікому. Скажіть, що саме пішло не так. Скажіть, як це виправити. Два речення можуть зекономити звернення в підтримку.
Для масштабніших рішень корисно поєднувати роботу над доступністю із сайтом, який уже обробляє складні сценарії, наприклад приватну мережеву інфраструктуру, бо та сама дисципліна, що робить внутрішні системи передбачуваними, робить публічні інтерфейси зручними.
Покращуйте колір, контраст і доступність медіа
Контраст кольорів прямо впливає на читабельність. Текст, який зливається з фоном, може виглядати стильно в макеті, але провалюватися в повсякденному використанні. Перевірте контраст інструментом, а потім подивіться на реальних екранах.
Не покладайтеся лише на колір, щоб передавати зміст. Якщо обов’язкові поля позначені червоним, додайте також текст або іконку разом із текстом. Якщо на графіку використовуються червоний і зелений, додайте підписи або візерунки. Один кольоровий сигнал може бути недоступним для людей із порушенням сприйняття кольорів, але завдання все одно має бути зрозумілим.
Субтитри — це перший крок для відео. Вони допомагають людям, які не чують аудіо, і тим, хто вимикає звук у публічних місцях. Транскрипт допомагає ще більше, коли користувач хоче шукати, цитувати або пізніше переглядати деталі. Аудіоописи важливі для відео, де візуальна інформація не озвучується.
Зображення з текстом усередині потребують особливої уваги. Якщо текст є критично важливим, продублюйте його і в копії сторінки. Банер із написом «Зареєструйтеся до п’ятниці» не має змушувати людину розшифровувати скріншот, щоб дізнатися дедлайн. Невелике рішення, велика різниця.
Перевірку кольору та медіа також варто включати до оглядів безпеки сайту, бо сайт, який виглядає безпечним, але приховує важливий текст або має зламані медіа, часто викликає таку саму недовіру, як і технічна помилка. Якщо ви вже відстежуєте безпеку сайту, поєднайте перевірки доступності з цим самим циклом огляду.
Тестуйте, виправляйте й підтримуйте доступність у часі
Доступність — це не разове прибирання. Сайти змінюються щотижня, а інколи щодня. Новий банер, оновлення форми або перероблене меню можуть повернути старі проблеми всього за 30 хвилин.
Побудуйте простий процес. Спочатку запускайте автоматичні перевірки на змінених сторінках. Потім вручну тестуйте ключові сценарії користувача з клавіатурою та скрінрідером. Далі збирайте відгуки користувачів і фіксуйте проблему з URL сторінки, браузером і точним кроком, де вона виникає. Чотири поля в тікеті кращі за одну розмиту скаргу.
Підтримувати доступність легше, коли вона є частиною звичайного релізного процесу. Якщо розробники додають компоненти, ці компоненти мають отримати мітки, стани фокуса й поведінку для клавіатури ще до публікації. Якщо редактори завантажують зображення, у них має бути звичка додавати alt-текст. Якщо маркетинг додає промоблоки, треба перевіряти контраст і текст посилань.
По можливості використовуйте шаблони з версіонуванням. Фіксований хедер, стандартний блок форми та перевірений шаблон модального вікна зменшують кількість повторюваних помилок. Саме тому команди, які дбають про підтримку сайту після запуску, часто краще працюють із доступністю: ця робота вбудована в підтримку, а не латана після скарг.
Зворотний зв’язок від реальних користувачів — найточніша перевірка. Користувач клавіатури знайде пастку в меню з трьох пунктів швидше за будь-який інструмент аудиту. Користувач скрінрідера одразу почує, чи має кнопка змістовний підпис. Якщо 2 людини повідомляють про ту саму перешкоду, сприймайте це як закономірність, а не випадковість.
І ще одна звичка дуже допомагає: прив’язуйте перевірки доступності до кожного оновлення контенту. Якщо команда публікує нову сторінку без перевірки заголовків, міток і медіа, сайт поступово відкотиться назад. Список підтримки з 5 пунктів може зупинити цей відкат до того, як він пошириться на всі сторінки.
