Від універсальної до персоналізованої доступності: як еволюціонують інтерфейси

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Усім вітання! Я займаюсь Front-End розробкою в компанії Langate Software. Я дуже часто говорю на тему вебдоступності і на роботі, і поза нею. На жаль, іноді доводиться пояснювати, нащо задумуватись про доступність та застосовувати її при створенні інтерфейсів. Бо її сприймають як окремий напрям або набір вимог, які обов’язково «поламають» дизайн, після чого він буде вже «не таким гарним».

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

І от з роками, під час таких бесід та дискусій, я помітила, що підхід до доступності змінюється. Я більше не говорю лише про універсальні правила та відповідність WCAG чи іншому стандарту. Сучасні інтерфейси «вчаться» адаптовуватися: до системних налаштувань, до поведінки користувача, до конкретної сесії. І ось саме про ці зміни я б хотіла поговорити.

Універсальний vs персоналізований підхід: чому ж почалась «еволюція»

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

Це і зараз працює, причому доволі справно. Команди з розробки застосовують контрастність тексту, семантичні теги, alt-тексти, фокус-стани, ARIA-атрибути тощо — усе це дозволяє забезпечити базову зрозумілість та доступність для користувачів. Аудитори з доступності (Accessibility auditors) перевіряють та тестують проєкти саме за цими критеріями. Все працює як злагоджений механізм. То в чому ж тоді заковирка?

Навіть реалізувавши всі вимоги, ви охоплюєте лише «середньостатистичного» (якщо можна так сказати) користувача з порушеннями слуху, зору, моторики чи когнітивних функцій. І це нормально: розробник не може знати всі можливі порушення та особливості, які вимагають спеціалізованого користування інтерфейсом.

До прикладу, навіть додавши aria-label до кнопки, ви не можете гарантувати, що людина з когнітивними складнощами або специфічними сенсорними потребами сприйме її так само легко. Контрастність, що відповідає стандарту, може бути недостатньою для користувача із кольоровою сліпотою. Анімації на сторінці часто проходять перевірку на відповідність стандарту (їхня тривалість, частота оновлень, можливість зупинки), але без урахування того, що деякі користувачі можуть відчувати сенсорне або когнітивне навантаження. Тобто анімації все одно можуть створювати дискомфорт.

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

• Системні налаштування: CSS media features як prefers-reduced-motion, prefers-contrast або prefers-color-scheme та інші дозволяють змінювати поведінку компонентів залежно від налаштувань користувача в системі. Наприклад, якщо він активував режим зменшеної анімації в системі, на сайті автоматично вимикаються рухомі ефекти.
• Контейнерні запити та кастомні властивості: дозволяють компонуванню та стилям адаптуватися до конкретного розміру блоку, кольору або теми. Це дає змогу створювати гнучкі компоненти, які підлаштовуються під різні умови без порушення базових правил доступності.
• Персоналізація через віджети: користувач може сам підбирати комфортний шрифт, контраст, колірну схему або відключати анімації.

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

Практичні інструменти персоналізованого підходу

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

Fundamental Level — базові принципи доступності

Включає в себе: семантику HTML, ARIA-атрибути, контрастність кольорів, клавіатурну навігацію, ALT-тексти для зображень. В цілому він забезпечує базовий рівень доступності для всіх користувачів і є основою основ для всіх подальших кроків у напрямку покращення персоналізації. Відповідність цьому рівню означає дотримання правил доступності, які є у таких стандартах, як WCAG, RAAM, EN301 549, Section 508, ADA та інших (це найбільш популярні, з якими доводилось працювати особисто).

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

System Level

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

CSS як інструмент персоналізації

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

Розглянемо prefers-reduced-motion. Наприклад: на сайті є модалка, у модалки є анімація появи з масштабом і переміщенням, що створює рух на екрані. Якщо ми використаємо @media (prefers-reduced-motion: reduce), для користувачів із зменшеною анімацією ми прибираємо масштаб і рух, залишаємо лише opacity:

/* Звичайна анімація для всіх */
 .modal {
 	opacity: 0;
 	transform: translateY(-20px) scale(0.95);
 	transition: opacity 300ms ease, transform 300ms ease;
 }

 .modal[data-state="open"] {
 	opacity: 1;
 	transform: translateY(0) scale(1);
 }

 /* Адаптація для користувачів, які хочуть зменшити анімації */
 @media (prefers-reduced-motion: reduce) {
 	.modal {
     	transition: none; /* прибираємо плавність (за бажанням можна залишати щось мінімальне) */
 	}
 	.modal[data-state="open"] {
     	transform: none; /* прибираємо рух та масштаб */
 	}
 } 

Що відбувається:

• Для всіх користувачів (без prefers-reduced-motion) — модалка з’являється з плавним переміщенням та масштабом.
• Якщо користувач активував «зменшення анімацій» у системі, спрацьовує prefers-reduced-motion і користувач бачить відкриття модалки без руху і масштабу.

Виглядатиме це приблизно наступним чином:

Як приклад я взяла модалку, бо якраз останній мій досвід був саме з нативним елементом HTML — <dialog> і там можна було «погратись» із закриттям/відкриттям та іншими анімаціями та доступністю. Але насправді такий підхід можна застосовувати до будь-яких компонентів інтерфейсу, де є або потенційно можливі анімації.

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

:root {
 	--border: 1px solid rgba(0,0,0,0.15);
 	--focus-outline: 2px solid #2563eb;
 }

 /* Підлаштування під користувачів із високим контрастом у системі */
 @media (prefers-contrast: more) {
 	:root {
     	--border: 1px solid #000;
     	--focus-ring: 3px solid #000;
 	}
 }

 input:focus {
 	border: var(--border);
 	outline: var(--focus-outline);
 }  

Що тут буде відбуватись:

• Для звичайного режиму буде застосовуватись тонкий синій контур фокусу і ледь-помітний сірий бордер.
• Якщо користувач активував високий контраст у системі (prefers-contrast: more), контури та бордери стають чорними та товстішими.

Ще одне налаштування, яке стосується кольорів і, підозрюю, багато кому відоме з того моменту, коли набуло популярності перемикання теми на світлу/темну. @media (prefers-color-scheme: dark / light) — медіа‑запит спрацьовує, коли користувач у системі вибрав темну або світлу тему. Дуже просто, але дуже класно, оскільки інтерфейс уже буде «знати» яку тему вам ввімкнути:

 :root {
 	--bg-color: whitesmoke;
 	--text-color: #2e2e2e;
 	--link-color: #7c3aed;
 }

 /* Темна тема для користувачів із системною темою dark */
 @media (prefers-color-scheme: dark) {
 	:root {
     	--bg-color: #2e2e2e;
     	--text-color: whitesmoke;
     	--link-color: #8ab4f8;
 	}
 }

 body {
 	background-color: var(--bg-color);
 	color: var(--text-color);
 }

 a {
 	color: var(--link-color);
 }

Це не буде перемикання теми на світлу чи темну, наш код буде «дивитись» на системні налаштування і «розумітиме», які кольори йому включати. Не буде такого, що у користувача в системі обрана темна тема, а тут йому вмикається сайт зі світлою і екран починає світитись на півхати:

Іноді деякі користувачі застосовують висококонтрастні системні палітри. Тут на допомогу приходить forced-colors, який дає змогу підлаштовувати стилі елементів під ці системні кольори, щоб кнопки, текст і інші UI-компоненти залишалися читабельними і функціональними:

@media (forced-colors: active) {
		button {
    		background-color: ButtonFace; /* системний колір кнопки */
    		color: ButtonText; /* системний текст */
    		border: 2px solid ButtonText;
		}

	a {
    		color: LinkText;
		}
}

Що воно таке і який має принцип дії:

• Вмикається, коли користувач у системі або браузері активував режим високого контрасту.
• У цьому режимі ОС примусово змінює палітру елементів, і звичайні кольори CSS (які враховують дизайн), ігноруються.
• Ключові значення (ButtonFace, ButtonText, LinkText, Canvas, тощо) беруться з системної палітри.

Коли і для чого використовується:

• Гарантує, що кнопки, посилання та текст залишаться читабельними.
• Використання системних кольорів дозволяє не ламати UX у висококонтрастному режимі.
• Технічно можна застосовувати і свої кольори (не лише ButtonFace, ButtonText, LinkText тощо). Але у режимі forced-colors браузер може всеодно переписати ці кольори, якщо це не вимкнути за допомогою forced-color-adjust: none;.

Або є ще один варіант системного вибору режиму кольорів — інверсія. inverted-colors дозволяє контролювати, як виглядають зображення, відео та іконки, щоб інверсія не псувала сприйняття контенту:

 @media (inverted-colors: inverted) {
img, video {
    filter: invert(100%); /* дозволяємо інвертувати */
    filter: none; /* не дозволяємо, зберігаємо вигляд */
}
}

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

Особливо корисно для сайтів із великою кількістю медіаконтенту, де інверсія кольорів без корекції може зробити контент нерозбірливим.

Також, окрім розглянутих, існують й інші media features та CSS-властивості, які можуть персоналізувати та впливати на доступність і стабільність інтерфейсу.

Наприклад, prefers-reduced-data дозволяє зменшувати обсяг завантажуваних ресурсів для користувачів із обмеженим трафіком; video-dynamic-range — адаптувати відео під SDR або HDR-дисплеї; monochrome — враховувати екрани без кольору; update та scan — реагувати на тип оновлення дисплея; any-hover і any-pointer — визначати тип введення та доступність курсора; display-mode — адаптувати інтерфейс під PWA або fullscreen-середовище; scrollbar-gutter — резервувати місце під скролбар, зменшуючи небажані зсуви контенту. Щось перекриває потреби при когнітивних порушеннях, щось — при зорових чи інших.

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

HTML як інструмент персоналізації

Звісно, обмежуватись лише CSS-можливостями не варто, адже сучасний HTML за останні роки суттєво виріс: з’явилися нативні механізми, які раніше доводилось реалізовувати додатковою логікою у вигляді всласного коду чи сторонніх бібліотек.

Атрибут inert: його просто достатньо «повісити» на блок, який ви хочете зробити невидимим для assistive technologies:

<div class="hidden-content" inert>
		<!-- неактивна частина DOM -->
</div>

Що ж він робить:

• прибирає елемент з tab-order;
• блокує фокус;
• вимикає кліки та взаємодію;
• приховує його для assistive technologies.

Підходить для відкритих модалок, off-canvas меню, step-based форм, loading-станів.

На додачу до всім відомого autocomplete ще є inputmode та enterkeyhint:

<input
		type="email"
		autocomplete="email"
inputmode="email" /* відкриває відповідну клавіатуру на мобільному */
		enterkeyhint="next" /* змінює напис на кнопці Enter */
/>

І здавалось би це просто UX-покращення, та насправді не тільки. Загалом такі атрибути знижують когнітивне навантаження: менше помилок введення, менше перемикань клавіатур, менше непередбачуваної поведінки, що є дуже важливим для користувачів з моторними порушеннями та дислексією.

Окремо варто згадати й еволюцію самої семантики HTML. Поява та стабілізація таких нативних елементів як <dialog>, <details>, <summary>, <fieldset>, <legend> суттєво зменшує потребу в кастомних ARIA-рішеннях і складній JavaScript-логіці. Браузер бере на себе частину поведінки: керування фокусом, групування елементів, озвучування контексту для assistive technologies.
І це важливий момент: доступність дедалі частіше реалізується не через «надбудову» у вигляді атрибутів чи скриптів, а через правильний вибір нативних інструментів. Чим ближче ми до правильної семантики, тим стабільніший і передбачуваніший результат.

User-Control Level

Після системного рівня (prefers-*, forced-colors тощо) логічно виникає наступний рівень покращення персоналізації — свідомо наданий користувачу контроль.

І тут є два підходи:

1) Реалізувати персоналізоване керування як частину дизайн-системи.

2) Підключити готовий accessibility-віджет.

Обидва варіанти мають право на життя. Але вони різні за наслідками.

Власна реалізація: коли персоналізація — частина архітектури

У сучасних проєктах на фреймворках з інтегрованими UI-бібліотеками навряд пишуть окремий «віджет доступності».

Персоналізація інтегрується у:

• глобальні дизайн-токени;
• theme provider;
• layout state;
• user preferences store;
• feature flags.

Тобто це не окремий скрипт, а частина системи стилів і стану застосунку. Що в такому разі можна реалізувати самостійно:

• high contrast mode;
• збільшення базового розміру шрифту;
• перемикач reduced motion;
• зміна щільності інтерфейсу (compact / comfortable);
• спрощений режим (без ілюстрацій, без другорядних блоків);
• регулювання міжрядкового інтервалу;
• вибір шрифту на більш читабельний.

Плюсами такої реалізації буде повний контроль над UX, відсутність overlay-хаосу, узгодженість з дизайн-системою, ще й на додачу не буде зайвих сторонніх скриптів.

Але і без недоліків не обійтись: потрібно продумувати архітектуру, системно підтримувати ці налаштування, враховувати навантаження на систему та вплив на Performance.

Сторонні accessibility-віджети

Ви їх точно вже бачили хоча б на якомусь сайті. Зазвичай виглядає це наступним чином:

кнопка збоку екрану → панель із якоюсь кількістю перемикачів → збільшення шрифту, контраст, grayscale, underline links тощо.

Вони доволі зрозуміло виглядають, швидко інтегруються, часто мають сертифікацію, продаються як «WCAG compliance in one click». Але, як це завжди буває, є і свої нюанси:

• Overlay ≠ реальна доступність. Багато таких рішень просто накладають CSS поверх уже існуючого DOM. Якщо у вас немає семантики або порушена фокусна логіка — віджет це не виправить.
• Конфлікти з наявним дизайном. Такі віджети можуть «ламати» layout, змінювати контраст у спосіб, який не буде передбачений дизайн-системою, створювати неочікувані стани. Особливо таке може траплятись, коли для проєкту використовується стороння бібліотека UI компонентів.

• Performance. Тут все зрозуміло — додатковий JS, іноді доволі «важкий».
• Аудиторський момент. Під час WCAG-аудитів часто перевіряється базовий стан без віджета. І якщо без нього інтерфейс не відповідає вимогам — віджет не рятує.

Коли такий сторонній віджет був би доречним: сайт, який не має складної архітектури або проєкт без власної дизайн-системи, або в якості підтримки legacy-продукту.

Але якщо ви будуєте продукт, як великий довгострокий проєкт — краще інвестувати в системний підхід.

Також потрібно розуміти, що мета цього User-Control Level не дати всі можливі перемикачі в руки користувача і щоб він самостійно сидів і наклацував все. Тут потрібно враховувати, які режими були б реально корисними.

Я колись мала досвід консультації одного проєкту для поліклініки. У компанії, яка розробляла цей сайт, був власний віджет доступності, який також встановили. Цей віджет містив, здавалось, всі можливі зорові/слухові/моторні/когнітивні порушення. Я такого ніколи не бачила до і після цього випадку.

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

Behavioral Level

System і User-Control рівні базуються на явних сигналах:

• або система щось повідомила;
• або користувач сам щось увімкнув.

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

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

слухаємо keydown / mousedown → визначаємо interaction mode → зберігаємо його → додаємо data-атрибут / клас на <html>

І далі ми можемо відштовхуватись від data-атрибута чи класу і прописувати товстіший outline, робити більші відступи або більший target size (в залежності від потреб, які потрібно закрити).

Або адаптація під помилки взаємодії: випадкові кліки, користувач не може попасти по інтерактивному елементу чи подвійні натискання. З такими проблемами часто стикаються користувачі з тремором або іншими моторними порушеннями. Що в такому разі можна зробити:

• Збільшити інтерактивну зону: наприклад, чекбокс із підписом — клікабельним має бути і label, а не тільки маленький квадрат, і тут навіть не потрібна логіка у JS, це вирішується правильною розміткою.
• Адаптація під тип пристрою: наприклад, є у CSS такі медіа-запити, через які можна враховувати тип вказівника:

o pointer: coarse — палець (велика зона торкання);

o pointer: fine — мишка.

І для режиму coarse можна збільшити відступи між кнопками, зробити більший мінімальний розмір інтерактивних елементів, уникати hover-залежних сценаріїв.

• Обмеження швидких повторюваних дій: наприклад, подвійний клік по кнопці «Submit» — як наслідок, дублікати запиту. Блокуємо кнопку під час запиту або робимо візуальний стан «loading» і це одразу зменшує когнітивне та поведінкове навантаження.

Загалом суть цього етапу така, що ми не чекаємо, що «скаже» система, не чекаємо, що «увімкне/вимкне» користувач, інтерфейс сам аналізує поведінку та адаптується під неї.

Але без «але» тут не обійтись — все перелічене це підлаштовування за заздалегідь прописаними розробником умовами. І було б класно, якби така адаптація базувалась не лише на таких статичних правилах, а й на аналізі патернів поведінки. Що в принципі виглядає доволі реальним у перспективі завдяки розвитку машинного навчання та АІ, які можуть визначати закономірності взаємодії користувача і підлаштовувати інтерфейс більш гнучко.

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

Висновок

Універсальні правила та стандартні рекомендації залишаються основою, але сьогодні важливо враховувати системні налаштування, персональні переваги, поведінку та контекст користувача.

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

Водночас важливо пам’ятати: будь-яке налаштування, спрямоване на покращення вебдоступності, майже завжди позитивно впливає і на загальний користувацький досвід. Ми самі користуємося темними темами, зменшуємо анімацію в дорозі, збільшуємо текст або підвищуємо контраст у складних умовах освітлення. Тому вебдоступність ніколи не буває виключно про «окрему категорію користувачів». Це про всіх нас у різних життєвих ситуаціях.