RTL-верстка сайту: підтримка арабської, івриту, фарсі
При розробці сайту арабською або івритом недостатньо просто змінити direction. Багато розробників стикаються з тим, що UI ламається: іконки дивляться не туди, відступи роз'їжджаються, а текст змішується. Ми, як команда з 5-річним досвідом у RTL-верстці, адаптували понад 50 проєктів під RTL-мови. Наша послуга — адаптація сайтів під RTL-мови під ключ: від аудиту до деплою. Зв'яжіться з нами — ми оцінимо проєкт і запропонуємо рішення з гарантією сумісності.
RTL (Right-to-Left) — підтримка мов з написанням справа наліво: арабська, іврит, перська (фарсі), урду. RTL-верстка — не просто direction: rtl, це системна переробка всіх directional CSS-властивостей і UI-компонентів. Без неї сайт арабською виглядає чужим і втрачає довіру користувачів.
Базова настройка RTL
<html dir="rtl" lang="ar">
[dir="rtl"] {
direction: rtl;
unicode-bidi: embed;
}
Чому CSS Logical Properties обов'язкові для RTL?
Замість фізичних властивостей (left, right, margin-left) використовуються логічні, які автоматично адаптуються до dir. Це позбавляє від дублювання правил і скорочує об'єм коду. Порівняйте:
| Фізичне |
Логічне |
margin-left |
margin-inline-start |
margin-right |
margin-inline-end |
padding-left |
padding-inline-start |
border-left |
border-inline-start |
left: 0 |
inset-inline-start: 0 |
text-align: left |
text-align: start |
float: left |
float: inline-start |
На практиці це означає, що кнопка «назад» зі стрілкою в LTR показує ←, а в RTL — →, без додаткових перевизначень. Logical properties — база сучасної RTL-верстки. Детальніше читайте в документації MDN.
Приклад:
.back-arrow {
margin-inline-end: 8px; /* в LTR: margin-right, в RTL: margin-left */
}
[dir="rtl"] .directional-icon {
transform: scaleX(-1);
}
Іконки та зображення
Іконки зі смисловим напрямком (стрілки, back/forward) повинні дзеркалюватися для RTL. Іконки без напрямку (серце, зірка, галочка) — не дзеркалюються. Іконки з текстом (логотипи) — не дзеркалюються. Це правило легко забути, але воно критичне для UX.
Flexbox і Grid в RTL
flex-direction: row в RTL автоматично розвертається. Але явні margin-left / margin-right не змінюються — потрібно замінити на логічні. Наприклад, замість .nav-item + .nav-item { margin-left: 16px; } використовуйте margin-inline-start: 16px. Це скорочує кількість помилок на 40% за нашими даними.
Шрифти для RTL-мов
Арабський текст потребує спеціальних шрифтів: Noto Sans Arabic, Tajawal, Cairo, IBM Plex Sans Arabic. Числа в арабському контексті можуть відображатися східноарабськими цифрами (٠١٢٣٤٥٦٧٨٩) або західними — залежить від locale. Вибір шрифту впливає на читабельність і Core Web Vitals. Ми рекомендуємо Noto Sans Arabic — він покриває більшість мов і оптимізований для вебу.
Двоспрямований текст (BiDi)
Сторінка може містити обидва напрямки (арабська + англійська). CSS властивість unicode-bidi: isolate ізолює блоки:
.ltr-content {
direction: ltr;
unicode-bidi: isolate;
}
Для інлайнових елементів з протилежним напрямком — тег <bdi>. Це запобігає плутанині в порядку тексту та коректно відображає змішані рядки. Детальніше про BiDi.
Як тестувати RTL-верстку?
Інструмент для швидкої перевірки: Chrome DevTools → Elements → додати dir="rtl" до <html>. Або розширення RTL Toggler. Playwright тест:
test('RTL layout', async ({ page }) => {
await page.goto('/ar');
await expect(page.locator('html')).toHaveAttribute('dir', 'rtl');
// Перевіряємо позиціонування ключових елементів
});
Порівняння підходів: logical properties vs фізичні
| Характеристика |
Logical properties |
Фізичні властивості |
| Час на адаптацію |
2–3 дні |
4–5 днів |
| Кількість помилок |
5–10% |
30–50% |
| Підтримуваність |
Висока |
Низька |
Наш досвід показує, що використання logical properties скорочує час розробки на 30% і знижує кількість багів у 3 рази.
Наш кейс: інтернет-магазин на 50 сторінок
Клієнт з ОАЕ попросив адаптувати магазин під арабську мову. Ми провели аудит, виявили 120 місць з фізичними властивостями, переписали CSS на logical properties, дзеркалювали 80 іконок і налаштували шрифти. Результат: сайт коректно відображається на всіх пристроях, LCP покращився на 15%, а клієнт отримав зростання конверсії на 22% після запуску. Замовник відзначив, що підтримка RTL більше не потребує постійних правок.
Що входить у роботу?
- Аудит поточного сайту: виявлення фізичних властивостей, проблем з іконками, шрифтами та BiDi.
- Переписування CSS на logical properties з гарантією зворотної сумісності.
- Дзеркалювання іконок і зображень з напрямком.
- Налаштування шрифтів і локалі для чисел.
- Автоматизовані тести (Playwright) на коректність RTL-відображення.
- Документація з підтримки RTL для ваших розробників.
Терміни та вартість
Додавання RTL до готового LTR-сайту — 2–5 днів (залежить від обсягу використання фізичних CSS-властивостей). Розробка з RTL з нуля з використанням logical properties — без додаткового часу при правильній практиці. Підсумкова вартість розраховується індивідуально після аудиту. Замовте RTL-адаптацію — ми гарантуємо, що сайт коректно відобразиться на всіх пристроях і браузерах.
Чек-лист типових помилок при RTL-верстці
- Використання `margin-left`/`margin-right` замість `margin-inline-*`
- Недзеркалення іконок з напрямком
- Відсутність `unicode-bidi: isolate` для змішаного тексту
- Неправильний вибір шрифту (не підтримує арабські гліфи)
- Ігнорування чисел: східноарабські vs західні
Зв'яжіться з нами — отримайте консультацію та попередню оцінку за 1 день. Наші інженери мають 5+ років досвіду та сертифікати з веб-стандартів.
Доступність сайтів: 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.
Приклад реалізації кастомного комбобокса з ARIA
<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 набрала чинності з новими критеріями:
| Критерій |
Рівень |
Суть |
| 2.5.7 Dragging Movements |
AA |
Всі drag-операції повинні мати клавіатурну альтернативу |
| 2.5.8 Target Size |
AA |
Мінімальний розмір інтерактивного елемента 24×24 px |
| 3.2.6 Consistent Help |
A |
Розташування контакту/чату має бути однаковим на всіх сторінках |
| 3.3.7 Redundant Entry |
A |
Не змушувати вводити одну інформацію двічі в одній сесії |
Ці критерії підвищують поріг входу, але ми вже включаємо їх у стандартний чек-лист.
| Рівень |
Мінімальний контраст тексту |
Контраст великого тексту |
| AA |
4.5:1 |
3:1 |
| AAA |
7:1 |
4.5:1 |
Аудит та усунення порушень
Автоматичні інструменти знаходять близько 30–40% порушень. Решта — тільки ручне тестування. Мінімальний сценарій: пройти весь критичний user flow (реєстрація, покупка, форма) тільки клавіатурою та зі скрінридером.
Процес роботи
-
Автоматичний аудит — axe-core, Lighthouse, WAVE — видача 80+ правил.
-
Ручне тестування — NVDA, VoiceOver, клавіатура — 2–3 дні на типовий сайт.
-
Пріоритизація порушень — P1 (блокує використання), P2 (створює складності), P3 (покращення).
-
Виправлення — ітераціями, вбудовуємо перевірки в CI через Playwright + axe.
-
Повторний аудит — закриття всіх P1/P2 перед релізом.
-
Документація та передача — звіт з результатами, рекомендації по підтримці, навчання команди.
Результати та обсяг робіт
- Повний звіт по аудиту з пріоритизацією порушень (PDF/HTML)
- Виправлений код: семантична розмітка, ARIA, клавіатурна навігація
- Інтеграція axe-core в CI/CD для регресійного контролю
- Навчання розробників замовника по роботі з a11y (2-годинна сесія)
- Доступ до репозиторію з прикладами коректних компонентів
- Гарантія відповідності WCAG 2.2 AA на момент здачі
Терміни
| Етап |
Тривалість |
| Аудит сайту (до 50 сторінок) |
3–7 днів |
| Усунення порушень A/AA на існуючому проекті |
3–8 тижнів |
| Розробка нового проекту з дотриманням WCAG 2.2 AA |
від 6 тижнів |
Бюджет розраховується індивідуально після аудиту. Зв'яжіться з нами — оцінимо ваш проект за 1 день. Отримайте консультацію та чек-лист безкоштовно при замовленні аудиту.
Досвід та гарантії
Ми займаємося веб-доступністю a11y понад 8 років. Реалізували понад 50 проектів для банків, рітейлу та держсектора. Сертифіковані спеціалісти (IAAP CPACC, WAS). Гарантуємо проходження аудиту третьою стороною або доопрацьовуємо безкоштовно.
Стандарт WCAG 2.2 — офіційна рекомендація W3C, що визначає вимоги до доступності веб-контенту.
Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA
— рівні веб-доступності a11y за версією 2.2.
Замовте аудит зараз — отримайте чек-лист та попередню оцінку безкоштовно. Пишіть в Telegram або на пошту — відповімо протягом години.
