Set language and base direction deliberately, isolate mixed-direction content where needed, and review component meaning with a fluent reader instead of mirroring the whole page.
A right-to-left website is more than a left-to-right page with right-aligned paragraphs. It can contain prose that reads in one direction, email addresses and reference numbers that read in another, and controls whose meaning does not change with the surrounding language. Treat those as separate design decisions.
The goal is a page that people can read, navigate and copy from predictably. This guide proposes an RTL review workflow for a fictional translated website. It does not claim a language review or a browser test of an implemented locale.
Separate language, direction and alignment
W3C’s structural RTL guidance explains that language and base direction are independent. The HTML language identifies the language of content; dir establishes its base direction. Right alignment alone does not supply that direction.
For an Arabic-language document whose main reading direction is RTL, the opening element can deliberately declare both concepts. This fragment illustrates the attributes, not a complete page or proof that its translation is correct:
<html lang="ar" dir="rtl">Decide where the direction applies: the whole document, a translated content section or a small inserted expression. A multilingual page does not necessarily have one useful direction for every string. Avoid adding a page-wide override simply because an editor noticed one awkward reference number.
Our translation workflow covers the wider inventory of content and interface strings. Here the question is how those translated strings behave together in a real layout, including values that are not translated.
Inventory the mixed content before changing CSS
Take a representative page from the fictional website: an event description, a price, a booking reference, a contact address and a navigation menu. List which strings are editorial prose, which are entered by visitors and which are generated identifiers. Those categories need different decisions.
| Content | Question to resolve | Review example |
|---|---|---|
| Translated prose | What is its intended base direction? | A paragraph with punctuation and a quoted title |
| Email, URL or reference code | Does the complete expression remain recognizable? | A hyphenated code beside an RTL label |
| Visitor-supplied name | Can it behave independently of its surrounding sentence? | Names using different scripts in one list |
| Price or measurement | Which value and unit belong together? | A negative value with currency and parentheses |
| Navigation or step indicator | What is the intended sequence? | Next, Previous and a numbered process |
Use representative artificial values during development, with a fluent reader checking their meaning. Do not copy real customer details into a public issue or screenshot just to demonstrate a difficult punctuation case. Keep a small repeatable fixture set so a later component change can be reviewed against the same situations.
Isolate complete expressions instead of reversing characters
W3C’s inline bidi guidance describes why an opposite-direction expression needs an appropriate boundary. Preserve the intended logical character sequence in storage; do not manually reverse an identifier until it looks right on one screen.
The surrounding punctuation matters. Test the full sentence containing a code, not just the code displayed alone in an editor. Parentheses, separators and adjacent numbers can make an otherwise familiar value hard to interpret when the boundary is wrong.
The bdi element isolates inserted content from surrounding directional behavior. It is different from bdo, which overrides direction. For a known left-to-right reference inside an RTL context, a narrow illustrative fragment could be:
<bdi dir="ltr">AB-731</bdi>Choose the boundary around the whole meaningful expression. Isolating each letter or digit separately makes maintenance harder and can lose the relation between the value and its punctuation. After changing the markup, check selection and copying into a neutral text field, not only visual placement.
Use auto deliberately, not as language detection
MDN’s dir reference documents ltr, rtl and auto. The auto value uses the first strong directional character as a heuristic; it does not identify the language or decide a complete layout for it.
This distinction matters for names, comments and search fields whose contents vary. A string beginning with a reference code may not get the direction that someone expects from the language of a later sentence. Decide what the field represents, whether a known direction is appropriate and which mixed examples must be reviewed.
Keep the form’s label, help text, entered value and error message in the review. A readable value does not make a validation message or associated label correct. The right answer may be a localized label with a separately directed value, rather than an override covering the entire form.
Use logical spacing where the design follows reading
CSS logical properties express start and end along writing axes. They can help a design whose padding, margin or border belongs to the beginning or end of a component rather than a fixed physical side.
For example, agree whether the small gap between a label and its leading icon should follow reading direction. A shared component can then encode that intention consistently. Do not mechanically replace every left or right declaration: a map, diagram or deliberately physical position can have a different meaning.
A translated layout should still use the same spacing rhythm, readable measure and component boundaries as the rest of the site. RTL support is not a reason to let cards grow to unrelated heights or allow a long address to push a button outside its container. Test the narrow viewport with realistic content lengths.
Review icons, images and sequences individually
Do not flip an entire page with a transform. That also mirrors text, photographs and brand marks instead of designing the layout. Preserve official logos and meaningful images as their source assets require.
Review each directional icon by its job. An arrow representing progression through a localized step sequence may need a different treatment from an arrow inside a literal diagram. A close icon, company mark and photograph are not navigation instructions. Document the decision in the component rather than leaving it to an accidental inherited transform.
Check a breadcrumb from the first item to the current page. Then check a pagination control from its label to the actual destination. Do not accept a familiar-looking arrow while the action itself still leads to the wrong page. Where language versions map to equivalent pages, verify that mapping using the separate multilingual page checks.
Test reading and interaction as a complete journey
- Have a fluent reader review paragraphs containing names, numbers, punctuation and inserted identifiers.
- Navigate by keyboard and confirm that focus reaches controls in a useful sequence.
- Select and copy mixed-direction values, then compare their meaning outside the styled page.
- Review errors, empty results and long unbroken addresses, not just short happy-path text.
- Check mobile layout, zoom, menus, overlays and a return to the previous page.
- Inspect structured content such as a pricing table with the table review workflow, preserving the relationship between headers and values.
Record the page, component, language, direction, test value and observed problem. If the displayed order is wrong, first identify whether the fault lies in the stored content, markup boundary or layout. Reversing database strings to repair one screenshot can damage exports, search and later rendering.
Accept an RTL release when representative readers and supported interaction paths agree on the content’s meaning. Keep the mixed-content fixtures with the component review so the next translation or design update does not silently reintroduce the same defect.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- W3C Internationalization: Structural markup and right-to-left text in HTMLChecked Base direction through HTML dir, its independence from language and the difference between direction and alignment.
Limits: Historical browser notes are not used as a present-day compatibility matrix; this does not validate a particular locale design. - W3C Internationalization: Inline markup and bidirectional text in HTMLChecked Opposite-direction inline expressions can require deliberate isolation rather than reordered stored characters.
Limits: Each content boundary needs context; this does not justify blanket overrides or hidden direction characters throughout a database. - MDN: HTML dir global attributeChecked ltr, rtl and auto direction values, including the first-strong-direction heuristic of auto.
Limits: auto does not detect language or choose a complete culturally appropriate layout. - MDN: The bdi elementChecked Directional isolation for inserted content, distinct from a bdo direction override.
Limits: A small isolated fragment does not establish the correct direction of the entire page or guarantee a particular rendering result. - MDN: CSS logical properties and valuesChecked Logical start and end properties follow writing axes rather than fixed physical left and right.
Limits: Physical positioning can still be intentional; logical properties do not automatically fix content, reading order or every component.