Designing RTL Properly: A Practical Checklist for Arabic Product InterfacesDesigning RTL Properly: A Practical Checklist for Arabic Product Interfaces

Most Arabic interfaces start the same way: an existing product is translated, the root element gets dir="rtl", and the layout flips. That is the first step, not the finish line. The details that tell Arabic-speaking users a product was not made for them live elsewhere: an arrow pointing the wrong way, a phone number scrambled by bidirectional text, a cramped line of Arabic set in a typeface designed for Latin, a date in a calendar the user did not expect.

This is the checklist our designers and engineers work through when reviewing an Arabic or bilingual product. It applies equally to websites, web applications and mobile apps.

1. Foundations: direction is structure, not a theme

• Set both dir and lang on the root element and switch them with the locale; screen readers and font selection depend on lang.
• Use CSS logical properties everywhere: margin-inline-start, padding-inline-end, inset-inline-start and text-align: start. Physical left and right should be rare and deliberate.
• Let flexbox and grid do the work, since they follow the writing direction automatically. Avoid absolute positioning tied to left or right.
• In mobile frameworks, use start and end semantics (for example, EdgeInsetsDirectional in Flutter) rather than left and right.

2. Mirroring: what flips and what does not

Mirror these

• Navigation flow, back and forward arrows, chevrons, breadcrumbs and steppers.
• Side drawers, sliders and carousels, progress bars and pagination.
• Icons that imply direction, such as reply, “next”, or an indented list.
• Table column order, with the primary identifier on the reading-start side.

Do not mirror these

• Media playback controls, which follow an established convention rather than reading direction.
• Clocks, logos, check marks and icons that depict physical objects.
• Phone numbers, codes, URLs, email addresses and mathematical expressions, which remain left-to-right.
• Charts: decide deliberately whether time axes run right-to-left, document the decision, and apply it consistently across the product.

3. Bidirectional text: where most bugs live

Real Arabic content is full of Latin fragments: product names, model numbers, email addresses, URLs, amounts with currency codes. The Unicode bidirectional algorithm handles much of this, but punctuation and numbers at the edges of mixed runs frequently land in the wrong place.

• Wrap user-generated or mixed content in a bdi element, or set dir="auto", so its direction is determined by the content itself.
• Force dir="ltr" on email, URL, phone, IBAN and code inputs, even inside an Arabic interface, while keeping their labels aligned to the right.
• Watch trailing punctuation in strings that end with a Latin word; isolate the Latin segment instead of patching with spaces.
• Never build sentences by concatenating translated fragments, because word order differs between languages. Use complete message templates with placeholders.

4. Arabic typography

• Choose a typeface designed for Arabic, with a matched Latin companion, instead of relying on a system fallback.
• Arabic letterforms read smaller at the same point size and have taller ascenders and deeper descenders; plan for slightly larger sizes and more generous line-height in Arabic body text.
• Never apply letter-spacing to Arabic: it breaks the connections between letters.
• Arabic has no italics and no uppercase; use weight, color or size for emphasis instead.
• Design for length differences: Arabic strings may be shorter or longer than their English counterparts, and labels should wrap gracefully rather than truncate meaning.

5. Numbers, dates and calendars

• Decide whether the product uses Western or Arabic-Indic digits, and apply that choice consistently across the interface, documents and notifications.
• Where the business requires it, support both Hijri (Umm al-Qura) and Gregorian dates, and make clear which one is displayed.
• Be explicit with locale formatting. With JavaScript’s Intl API, a locale such as ar-SA may default to the Islamic calendar or Arabic-Indic digits depending on the environment, so set the calendar and numbering-system extensions intentionally, for example ar-SA-u-ca-gregory-nu-latn.
• Format currency, phone numbers and national address fields according to local conventions.

6. Forms, search and sorting

• Place labels, helper text and validation messages on the reading-start side, and make sure icons inside inputs move with the direction.
• Normalize Arabic search input (alef variants, taa marbuta, diacritics) so users find what they mean, not only what they typed letter for letter.
• Sort Arabic lists with a locale-aware collator, such as Intl.Collator with an Arabic locale, rather than raw code-point order.
• Accept input in both digit systems and normalize it before validation.

7. Test it the way a native user would

1. Review screens with real Arabic content, including long names and mixed Arabic–English strings, not placeholder text.
2. Run visual regression tests in both directions, so a layout change made in English cannot silently break Arabic.
3. Test with VoiceOver and TalkBack in Arabic to confirm reading order and labels.
4. Check everything the product produces off-screen: PDFs, invoices, emails, SMS and push notifications.
5. Ask native Arabic-speaking users to complete key tasks, and watch where they hesitate.

Arabic is not a translation layer added at the end. It is a first-class design constraint from the first wireframe.

Treating RTL as a design discipline rather than a localization task is what separates products that are usable in Arabic from products that feel native in it. Doing it from the start costs little; retrofitting it across a mature codebase does not.