У матеріалі Рубена Феррейри Дуарте розбирається конкретна задача: як дизайн-команді перевірити, що інтерфейси залишаються придатними до використання, коли користувач збільшує системний розмір шрифту до 200%. Автор пропонує практичний процес тестування у Figma на базі variables, text styles та auto layout, щоб інтегрувати ці перевірки в звичайний дизайн-процес, а не робити їх «раз на проєкт».
Чому масштабування шрифту не можна ігнорувати
Автор нагадує: користувачі активно застосовують допоміжні технології і стратегії, навіть якщо команда спеціально нічого «для доступності» не включала. Частина цих стратегій:
- екранні читачі;
- зміна кольорів і контрасту;
- збільшення розміру шрифту на рівні ОС або браузера.
За даними APPT, 26% користувачів Android та iOS (дані на лютий 2026) піднімають системний розмір шрифту вище стандартного. Це приблизно кожен четвертий користувач смартфона. Тож сценарій масштабування тексту не крайній випадок, а масовий.
Водночас критерій 1.4.4 WCAG 2.2 «Resizing Text» вимагає, щоб текст (окрім субтитрів та зображень тексту) можна було збільшити без допоміжних технологій до 200% без втрати контенту чи функціональності. Це критерій рівня AA.
Звідси кілька практичних наслідків, на яких наголошує автор:
- користувач має право ламати ваш «ідеальний піксельний» макет своїми налаштуваннями — це норма, а не помилка;
- проблема виникає не тоді, коли текст «виглядає занадто великим», а тоді, коли щось перестає бути доступним: текст обрізаний, елементи недосяжні, контроль неможливо натиснути;
- блокувати або обмежувати системні функції масштабування — погана стратегія і з точки зору етики, і з точки зору відповідності стандартам.
Ще один важливий момент: інтерфейс не зобов'язаний сам містити контрол «A- / A+». ОС і браузер вже мають стандартні механізми, а користувачі, яким це потрібно, зазвичай ними користуються глобально. Дублювати ці налаштування в кожному продукті немає сенсу, якщо немає якоїсь специфічної причини.
Де користувач змінює розмір шрифту
Автор коротко показує, як це виглядає в реальних середовищах, щоб дизайнери усвідомлювали, що тестувати потрібно поведінку при системному масштабуванні, а не лише макет у Figma.
На iPhone
Збільшення шрифту в iOS вбудоване в систему. Шлях налаштувань для користувача:
- «Settings» → «Accessibility»;
- група «Vision» → «Text Size and Display»;
- встановлення бажаного збільшення.
У Google Chrome
У Chrome системи контролю також є за замовчуванням:
- «Settings» → блок «Appearance»;
- опція «Font size» з варіантами на кшталт «Medium — Recommended» або «Very large».
Подібні механізми є і в інших браузерах, тож перевіряти інтерфейс при зміні розміру шрифту — базове завдання, а не «спецефект».
Завдання в Figma: перемикати масштаб тексту як режим
Мета процесу, який описує автор: зробити так, щоб у Figma можна було одним перемикачем змінювати масштаб усіх текстових стилів між кількома наперед визначеними рівнями, наприклад:
- 100% (базовий макет);
- 120%;
- 140%;
- 160%;
- 180%;
- 200%.
Ідея схожа на перемикання light / dark mode за допомогою variables: для кожного «режиму масштабу» є свій набір числових значень font-size та line-height. Перемикаєте режим — і весь текст на екрані змінюється у відповідній пропорції, показуючи, як житиме інтерфейс при системному масштабуванні.
Для такого підходу, за словами автора, необхідно впевнено працювати з:
Якщо одна з цих базових функцій ще не освоєна, автор радить спочатку закріпити саме її, а вже потім переходити до тесту масштабування.
Покроковий процес тестування масштабування шрифтів у Figma
Крок 1 — спочатку просто спроєктувати екрани
Початок процесу — звичайний дизайн інтерфейсів, які ви будете тестувати пізніше. На цьому етапі не потрібно одразу закладати всі сценарії збільшення шрифту, але базові рекомендації з доступності (контраст, мінімальні розміри, зрозумілі стани) мають діяти вже тут.
Крок 2 — послідовно застосувати auto layout
Далі автор акцентує: без акуратно налаштованого auto layout по всій структурі екрану масштабування шрифту «ламає» макет. Завдання на цьому кроці:
- обгорнути в auto layout усі логічні блоки;
- налаштувати відступи, вирівнювання, поведінку при зміні розміру;
- переконатися, що текстові блоки можуть рости по висоті, а контейнер адекватно підлаштовується.
Якщо цей етап пропустити або зробити «для галочки», при збільшенні тексту, за словами автора, компоненти «розсиплються як слон у посудній крамниці».
Крок 3 — структурувати та застосувати text styles
Наступна вимога — жодного «голого» тексту без стилю. Потрібно:
- створити набір text styles для всіх типів тексту (заголовки, підзаголовки, body, підписи, label тощо);
- застосувати стилі до кожного текстового елемента;
- уникати локальних оверрайдів розміру, які не оформлені як частина стилю.
Це критично, тому що подальші кроки працюють через прив'язку variables саме до параметрів text styles.
Крок 4 — завести змінні для масштабу 100%
Тепер потрібно описати базовий стан типографіки через Figma variables типу number. Основна ідея:
- для кожного text style створити змінні для font-size та line-height (мінімальний набір);
- значення цих змінних відповідають чинному дизайну, тобто масштабу 100%;
- логічно групувати змінні за типами стилів (наприклад, prefix для H1, Body, Caption).
Це створює основу для інших масштабів, які будуть обчислюватися від 100%.
Крок 5 — підключити змінні до text styles
Далі змінні потрібно реально використати:
- відкрити кожен text style;
- замість фіксованого числа для font-size і line-height підставити відповідні variables;
- переконатися, що всі екземпляри в макеті справді використовують оновлені стилі.
З цього моменту зміна значення variables (навіть у рамках одного режиму) автоматично змінює всю типографіку, пов'язану з цими стилями.
Крок 6 — порахувати змінні для масштабів 120-200%
Коли базовий набір 100% заведений, автор пропонує створити змінні для інших масштабів. Схема проста:
- обрати потрібні коефіцієнти (наприклад, 1.2, 1.4, 1.6, 1.8, 2.0);
- для кожного font-size: нове значення = базове значення × коефіцієнт;
- для кожного line-height — така ж операція.
Приклад з тексту: якщо font-size = 16px, для 120% (1.2) новий розмір = 16 × 1.2 = 19.2. Автор зазначає, що можна застосовувати округлення — це все ж таки наближений тест, і невеликі відхилення не зіпсують результат.
Крок 7 — застосувати різні набори змінних до копій екранів
Коли всі змінні для масштабів готові, настав «момент істини». Авторський підхід:
- скопіювати оригінальні екрани, створивши по одному варіанту під кожен масштаб (наприклад, 120, 140, 160, 180, 200%);
- для кожної копії застосувати відповідний набір variables шрифту;
- переконатися, що стилі переключилися коректно, а інші властивості залишилися незмінними.
Автор радить хоча б завжди мати пари 100% і 200% (відповідність WCAG), а решту масштабів обирати залежно від ресурсів і потреб.
Крок 8 — знайти проблемні місця
На цьому етапі починається власне аналіз доступності. Дивлячись на екрани з різним масштабом, варто перевіряти:
- Чи весь текст читається. Якщо текст обрізаний або прихований, це проблема доступності, незалежно від того, наскільки «гарно» це виглядає.
- Чи зберігається можливість взаємодії. Якщо збільшення шрифту робить неможливим натискання кнопок, доступ до посилань або заповнення полів — це критичний дефект.
- Чи не стають окремі великі елементи абсурдно великими. Деякі заголовки вже досить великі; збільшувати їх разом зі всім текстом може бути недоцільно і займати надто багато простору без вигоди для читабельності.
- Як поводиться auto layout. Якщо елементи «вилітають» за межі, перекривають один одного чи екран, перше, що варто перевірити — налаштування auto layout, пакування, поведінка при переповненні.
- Чи не ламається типографічна ієрархія. Навіть при масштабуванні має бути зрозуміло, що є H1, що — підзаголовок, що — body. Якщо розміри зближуються або міняються місцями за візуальною вагою, потрібно коригувати шкалу стилів.
- Що не можна виправити лише дизайном. Частина проблем виявиться такими, що потребують змін в коді (логіка брейкпоінтів, умовне відображення, поведінка компонентів). Їх варто зафіксувати окремо для розробників.
Крок 9 — внести правки в дизайн і задокументувати задачі для розробки
Після аналізу команда коригує:
- власне макети — через зміну layout, уточнення розмірів, відступів, поведінки компонентів;
- типографічну шкалу — наприклад, якщо якісь стилі надто агресивно або недостатньо масштабуються;
- дизайн-систему — щоб виправлення не обмежувалися одиничним екраном.
Для проблем, які розв'язуються тільки в коді, автор радить чітко задокументувати очікувану поведінку (які масштаби перевірені, як повинні поводитися компоненти) і передати це розробникам.
Крок 10 — повторювати цикл протягом проєкту
У підході автора це не одноразова перевірка «перед релізом», а циклічна практика, вбудована у роботу над продуктом. З часом деякі кроки можуть скоротитися завдяки зрілій дизайн-системі, але регулярне повернення до тесту масштабування допомагає тримати доступність у робочому процесі, а не в теорії.
Як дизайн-система спрощує тест масштабування
Рубен Феррейра Дуарте окремо виносить роль дизайн-систем. Якщо команда вже має хоча б базову бібліотеку компонентів і стилів, більшість описаних кроків стають значно простішими:
- auto layout і text styles вже уніфіковані і поширюються через компоненти;
- типографіка описана централізовано, тож змінні для масштабів можна завести один раз;
- якщо є variables для темізації (light / dark), принцип масштабування шрифтів повторює знайомий підхід.
На думку автора, міф про те, що дизайн-системи «вбивають креативність», не відповідає реальності. Вони забирають рутину і дають більше часу на складні задачі, зокрема на системну роботу з доступністю.
Перевірка макета у Figma допомагає знайти проблеми компонування, але не підтверджує доступність готового продукту. Поведінку масштабування потрібно також перевірити в реалізованому інтерфейсі.
Приклад Figma-файлу від автора
Автор публікує відкритий Figma file з прикладом усього процесу: від налаштування змінних до аналізу екранів на різних масштабах шрифту. Це один з можливих варіантів реалізації, а не «єдино правильна» модель, тому автор підкреслює, що її слід адаптувати до контексту конкретної команди, її процесів та зрілості дизайн-системи.
Ключова порада автора — не копіювати чужу схему автоматично. Важливо розуміти, які саме обмеження і задачі у вашого продукту, та калібрувати процес тестування під них. Навіть невелике, але регулярне тестування масштабування шрифту в макетах — вже відчутний крок вперед у практичній доступності продукту.
Джерело: Ruben Ferreira Duarte – Smashing Magazine. Дата оригіналу: 2026-03-24.