RTL UI Design: A Practical Guide to Right-to-Left Interfaces
A right-to-left interface is not just a left-to-right screen with its columns reversed. Text direction affects punctuation, mixed-language strings, form input, table order, navigation, and the meaning of “start” and “end” in a layout. Treating RTL as a late CSS flip often creates confusing details that are expensive to repair.
The reliable approach is to let HTML describe the text direction and let your layout system respond to writing direction.
Declare language and direction separately
The document language and its base direction are different pieces of information. For an Arabic page, for example:
<html lang="ar" dir="rtl">
Use the correct lang value for the content and dir="rtl" for the base direction. W3C Internationalization guidance recommends setting the direction in markup rather than using CSS to establish the base direction. Direction influences how the browser applies the bidirectional algorithm to punctuation, numbers, and embedded text.
For content supplied dynamically by a user, set direction to auto where appropriate so the browser can determine the text direction from the content. Inline mixtures of scripts need separate care: isolate a variable, product name, or identifier when its direction should not affect surrounding text. The W3C guidance on inline bidirectional text explains when elements such as <bdi> are useful.
Use logical CSS in shared components
Physical properties encode assumptions about the screen: margin-left always targets the left edge, even when the start of the text flow is on the right. Logical properties describe the relationship to the writing direction:
.card {
padding-inline: 1.25rem;
border-inline-start: 0.25rem solid var(--accent);
text-align: start;
}
.card__icon {
margin-inline-end: 0.5rem;
}
inline-start and inline-end adapt when direction changes. In most horizontal-script interfaces, this means they map to left and right in LTR and reverse in RTL. Logical properties also support vertical writing modes, which is why they scale better than a set of right-to-left overrides.
Make logical properties the default in the design system. Reserve physical coordinates for cases that genuinely depend on the physical screen edge, such as a brand mark that must remain in a fixed corner. When you do use an exception, name and document it clearly.
Decide what should mirror and what should not
Text flow and reading order usually change with direction; the meaning of every icon does not. A back arrow often follows the user's reading flow, but play, pause, search, and universally recognized media controls should not be mechanically flipped.
Review these separately:
- Navigation order, breadcrumbs, progress indicators, and pagination.
- Directional icons, including back/forward and expand/collapse affordances.
- Tables, charts, and legends where column order or axis meaning matters.
- Form labels, inline validation, and mixed-script values such as email addresses.
- Motion transitions that imply entering from a particular direction.
The rule is to preserve meaning, not to apply a blanket transform to every element.
Test the language and the layout together
Test real localized strings, not just a mirrored English page. Longer translations, numbers, dates, punctuation, and product identifiers can expose issues that a layout-only review misses. Check keyboard navigation and focus order independently of visual alignment; CSS reordering should not create a mismatch between what people see and the sequence they encounter.
Include LTR snippets inside RTL content and RTL snippets inside LTR content. Verify input direction, text selection, validation messages, chart labels, and copy-and-paste behavior. Use component tests for layout-critical states and a manual review with native browser direction support.
If you are building a broader localization system, pair this guide with the internationalization design-systems guide. For dashboards that contain charts and tables, see accessible data visualization.