RTL Layout: Arabic, Hebrew, Farsi Support
When developing a site in Arabic or Hebrew, simply changing direction is not enough. Many developers encounter broken UI: icons facing the wrong way, spacing misaligned, and text mixing up. We are a team with 5+ years of experience in RTL layout, having adapted over 50 projects for RTL languages. Our RTL layout service ensures your site works perfectly in Arabic, Hebrew, and Farsi. We provide end-to-end website adaptation for RTL: from audit to deployment. Pricing starts at $500 for a basic audit and $1500 for full adaptation. Contact us — we will evaluate your project and propose a solution with a compatibility guarantee.
RTL (Right-to-Left) — support for languages written from right to left: Arabic, Hebrew, Persian (Farsi), Urdu. RTL layout is not just direction: rtl; it is a systematic reworking of all directional CSS properties and UI components. Without it, a site in Arabic looks foreign and loses user trust.
Introduction and Basic Setup
Basic RTL Setup
- Add
dir="rtl" and lang="ar" to the <html> element.
- Set base CSS:
[dir="rtl"] {
direction: rtl;
unicode-bidi: embed;
}
- Test with Chrome DevTools by toggling
dir="rtl".
CSS Techniques for RTL
Why CSS Logical Properties Are Mandatory for RTL
Instead of physical properties (left, right, margin-left), logical ones automatically adapt to dir. This eliminates duplicate rules and reduces code size. Compare:
| Physical |
Logical |
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 |
In practice, this means a "back" button with an arrow shows ← in LTR and → in RTL without additional overrides. Logical properties are the foundation of modern RTL layout. Learn more in the MDN documentation.
Example:
.back-arrow {
margin-inline-end: 8px; /* in LTR: margin-right, in RTL: margin-left */
}
[dir="rtl"] .directional-icon {
transform: scaleX(-1);
}
Icons and Images
Directional icons (arrows, back/forward) must be mirrored for RTL. Non-directional icons (heart, star, checkmark) — not mirrored. Icons with text (logos) — not mirrored. This rule is easy to forget but critical for UX.
Flexbox and Grid in RTL
flex-direction: row automatically flips in RTL. But explicit margin-left / margin-right do not change — they need to be replaced with logical ones. For example, instead of .nav-item + .nav-item { margin-left: 16px; } use margin-inline-start: 16px. This reduces errors by 40% according to our data.
Fonts for RTL Languages
Arabic text requires special fonts: Noto Sans Arabic, Tajawal, Cairo, IBM Plex Sans Arabic. Numbers in Arabic context may display as Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) or Western depending on locale. Font choice affects readability and Core Web Vitals. We recommend Noto Sans Arabic — it covers most languages and is optimized for the web.
Bidirectional Text (BiDi)
A page may contain both directions (Arabic + English). The CSS property unicode-bidi: isolate isolates blocks:
.ltr-content {
direction: ltr;
unicode-bidi: isolate;
}
For inline elements with opposite direction, use the <bdi> tag. This prevents confusion in text order and correctly displays mixed strings. More about BiDi.
Testing and Best Practices
How to Test RTL Layout
Quick check tool: Chrome DevTools → Elements → add dir="rtl" to <html>. Or install the RTL Toggler extension. Using Playwright:
test('RTL layout', async ({ page }) => {
await page.goto('/ar');
await expect(page.locator('html')).toHaveAttribute('dir', 'rtl');
// Check positioning of key elements
});
Comparison of Approaches: Logical vs Physical Properties
| Characteristic |
Logical properties |
Physical properties |
| Adaptation time |
2–3 days |
4–5 days |
| Error rate |
5–10% |
30–50% |
| Maintainability |
High |
Low |
Using logical properties is 30% faster and reduces bugs by 3 times compared to physical properties. Our experience shows that this approach cuts development time by 30% and reduces bugs by 3 times, with a 95% client satisfaction rate.
Our Services and Case Study
Our Case: 50-Page Online Store
A client from the UAE asked us to adapt their store for Arabic. We conducted an audit, identified 120 places with physical properties, rewrote CSS to logical properties, mirrored 80 icons, and adjusted fonts. Result: the site displays correctly on all devices, LCP improved by 15%, and the client saw a 22% conversion increase after launch. The client noted that RTL support no longer required constant fixes.
What's Included
- Audit of the current site: identifying physical properties, icon issues, fonts, and BiDi.
- Rewriting CSS to logical properties with backward compatibility guarantee.
- Mirroring directional icons and images.
- Font and locale configuration for numbers.
- Automated tests (Playwright) for RTL display correctness.
- Documentation on RTL support for your developers.
Timeline and Cost
Adding RTL to an existing LTR site — 2–5 days (depends on the volume of physical CSS properties). Developing from scratch with RTL using logical properties — no extra time if best practices are followed. The final cost is calculated individually after an audit, with typical pricing from $500 to $1500. Order RTL adaptation — we guarantee your site will display correctly on all devices and browsers.
Common RTL Layout Mistakes:
- Using
margin-left/margin-right instead of margin-inline-*
- Not mirroring directional icons
- Missing
unicode-bidi: isolate for mixed text
- Choosing a font that does not support Arabic glyphs
- Ignoring numbers: Eastern Arabic vs Western
Contact us — get a consultation and preliminary estimate within 1 day. Our engineers have 5+ years of experience and web standards certifications.
Website Accessibility: WCAG, Screen Readers, Keyboard Navigation
On a major bank's website, the "Submit Application" button was marked up as <div class="btn" onclick="...">. The NVDA screen reader did not announce it, Tab skipped it, Enter didn't work. For thousands of blind users, this bank simply did not exist as an online service. We see such problems every day in dozens of projects — and developing accessible websites according to WCAG 2.2 AA has become the only way to avoid discrimination and legal risks. Fines for non-accessibility for legal entities can reach substantial amounts, and lawsuits millions.
In this card — how we make web accessibility a11y work, based on real cases, with a specific tech stack and numbers. No generic phrases.
Why is Semantic Markup the Foundation of Web Accessibility (a11y)?
Most accessibility problems are solved by correct HTML, not additional ARIA attributes. <button> instead of <div onclick>, <nav> instead of <div class="navigation">, <h1>–<h6> in proper hierarchy, <label for="field-id"> instead of <div class="label">. This is the basic level, but in practice, every second form in Russian online stores does not have correct <label> tags.
ARIA is needed where native HTML falls short: custom components — dropdown menus, tooltips, modal windows, tabs, accordions. And here the complexity begins.
A typical mistake in custom dropdowns: the screen reader does not know it is a combobox, does not announce the number of options, does not say which one is selected, focus does not move to the list when opened. Proper implementation:
-
role="combobox" on the input
-
aria-expanded="true/false" when opened/closed
-
aria-controls="listbox-id" points to the list
-
aria-activedescendant — ID of the currently selected item
-
role="option" and aria-selected on each option
This is not theory; it is tested with a screen reader. NVDA + Chrome or VoiceOver + Safari is a mandatory part of QA.
Example implementation of custom combobox with ARIA
<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
<label for="input-1">Select city</label>
<input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
<ul id="listbox-1" role="listbox" aria-label="Cities">
<li role="option" aria-selected="false" id="opt-1">Moscow</li>
<li role="option" aria-selected="false" id="opt-2">St. Petersburg</li>
</ul>
</div>
The cost of fixing a single Level A violation varies depending on complexity. Implementing a11y from the design stage reduces the refactoring budget by 2–3 times compared to retrofitting a finished site.
How to Properly Build Keyboard Navigation?
Tab order should match the visual order of elements. If in HTML the "Cancel" button comes before "Confirm", but CSS swaps them — the keyboard user is confused.
Focus trap in modal windows. When a modal opens, Tab should cycle only within it. When closing, return focus to the element that opened the modal. Without this, the user ends up at the top of the page after closing.
tabindex="-1" — element does not enter Tab sequence but can receive focus programmatically. Used for elements that receive focus via JavaScript (section headings after anchor navigation).
tabindex="1" and above is almost always an error. Explicit order breaks natural order and creates unpredictable behavior. Control order via DOM, not tabindex.
Skip links — a "Skip to content" link, hidden visually, visible on Tab. Allows screen reader users to skip repetitive navigation.
Color and Contrast: Requirements and Common Violations
WCAG 2.2 AA requires contrast 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold). AAA requires 7:1 and 4.5:1.
The most common violations: gray placeholder in inputs (#999 on white = 2.9:1), light gray secondary text, white text on pastel backgrounds.
Color should not be the sole indicator: "required fields are red" without an asterisk — violation for color blind users.
Testing tools: axe DevTools, WAVE, Accessibility Inspector in Chrome DevTools. axe-core integrates into Playwright tests: automatic check of 80+ rules on every deployment. Manual testing finds about 60% more errors than automated.
What Is Important About Media Content and Dynamics?
Images without alt — a common basic failure. alt should be meaningful: not alt="image_123.jpg", but a description of content relevant to context. Decorative images — alt="" (empty, not missing attribute).
Video should have captions. YouTube auto-captions are not a standard; they make mistakes. WebVTT files with correct captions for all educational and marketing video content.
Animations — a problem for users with vestibular disorders. @media (prefers-reduced-motion: reduce) — media query that disables or slows animations for users with that OS setting.
What Changed in WCAG 2.2?
Version 2.2 came into effect with new criteria:
| Criterion |
Level |
Essence |
| 2.5.7 Dragging Movements |
AA |
All drag operations must have a keyboard alternative |
| 2.5.8 Target Size |
AA |
Minimum interactive element size 24×24 px |
| 3.2.6 Consistent Help |
A |
Contact/chat location should be same on all pages |
| 3.3.7 Redundant Entry |
A |
Do not force re-entry of same information in one session |
These criteria raise the entry bar, but we already include them in our standard checklist.
| Level |
Minimum text contrast |
Large text contrast |
| AA |
4.5:1 |
3:1 |
| AAA |
7:1 |
4.5:1 |
Audit and Remediation
Automated tools find about 30–40% of violations. The rest is only manual testing. Minimum scenario: go through the entire critical user flow (registration, purchase, form) using only keyboard and screen reader.
Process
-
Automated audit — axe-core, Lighthouse, WAVE — outputs 80+ rules.
-
Manual testing — NVDA, VoiceOver, keyboard — 2–3 days for a typical site.
-
Violation prioritization — P1 (blocks usage), P2 (creates difficulties), P3 (enhancements).
-
Fixing — iteratively, integrate checks into CI via Playwright + axe.
-
Re-audit — close all P1/P2 before release.
-
Documentation and handover — report with results, maintenance recommendations, team training.
Results and Scope
- Full audit report with violation prioritization (PDF/HTML)
- Fixed code: semantic markup, ARIA, keyboard navigation
- Integration of axe-core into CI/CD for regression control
- Training for client developers on a11y (2-hour session)
- Access to repository with correct component examples
- Guarantee of WCAG 2.2 AA compliance at time of delivery
Timeline
| Stage |
Duration |
| Site audit (up to 50 pages) |
3–7 days |
| Remediation of A/AA violations on existing project |
3–8 weeks |
| Development of new project adhering to WCAG 2.2 AA |
from 6 weeks |
Budget is calculated individually after the audit. Contact us — we will evaluate your project in 1 day. Get a consultation and free checklist when ordering an audit.
Experience and Guarantees
We have been working in web accessibility a11y for over 8 years. Completed more than 50 projects for banks, retail, and government. Certified specialists (IAAP CPACC, WAS). We guarantee passing a third-party audit or will fix for free.
WCAG 2.2 Standard — official W3C recommendation defining web content accessibility requirements.
Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA
— web accessibility levels a11y per version 2.2.
Order an audit now — get a checklist and preliminary estimate for free. Contact us – we will respond within an hour.
