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 становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.
В этой карточке — как мы делаем веб-доступность 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 — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение 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 или на почту — ответим в течение часа.
