An RTL-first design system treats direction, Arabic content, mixed scripts, and mirrored interaction as component requirements from the first draft. Setting dir="rtl" is necessary, but it does not decide which icon mirrors, how a phone number sits inside Arabic text, whether a table remains understandable, or how type metrics affect controls. The goal is one coherent system whose tokens and behavior are shared while layout direction and native copy adapt deliberately. That approach is more maintainable than a late RTL override layer.
Put language and direction at the document boundary
Set correct lang and dir values on the document or relevant isolated region. Keep locale URL-driven for public content so a link has a stable language. Do not infer direction from a user’s keyboard or a single string. Components should inherit direction unless they represent content with a known independent direction. The Arabic-first product story covers the product rationale, and the Flutter and Laravel guide shows why language also belongs in client-server contracts.
Use logical layout properties
Prefer inline and block concepts: margin-inline-start, padding-inline, inset-inline-end, border-start-start-radius, and text-align: start. Flex and grid direction should follow reading order unless the content has a fixed semantic sequence. Avoid a second stylesheet full of left/right overrides. Name design tokens by purpose rather than direction. Review transforms and absolute positioning, where physical assumptions often survive after spacing has been converted.
Define an icon mirroring policy
Directional arrows, previous and next chevrons, and progress movement commonly mirror. Brand marks, media controls, clocks, phone symbols, check marks, and many physical objects do not. Some icons depend on context rather than shape. Store the decision in icon metadata or component behavior, not scattered CSS. Pair important icons with text or an accessible name. Test that keyboard order and spoken labels match the visual direction after mirroring.
Isolate mixed-direction text
Arabic sentences often contain English product names, emails, URLs, codes, and numbers. Use semantic isolation such as <bdi> or appropriate dir values for user-generated runs. Do not insert Unicode control characters into stored data as a layout fix; they are hard to inspect and can leak into exports. Test punctuation and parentheses around mixed text. Inputs for phone numbers, email, and code may use LTR entry while their labels and surrounding layout remain RTL.
Design typography per script
Arabic and Latin fonts have different vertical metrics, perceived size, weight, and line-height needs. Define compatible font stacks and test actual glyph coverage, diacritics, numerals, and bold weights. Do not force identical pixel metrics if it clips Arabic marks or misaligns controls. Allow labels to wrap and buttons to grow. Test user zoom and operating-system font scaling. A screenshot with short labels does not validate a localized component.
Preserve source order and accessibility
Use DOM order that makes sense for reading and keyboard navigation, then let CSS direction handle visual flow. Avoid order and absolute positioning that create a different spoken sequence. In data tables, keep header associations explicit and test horizontal scrolling from the logical start. Error messages should be adjacent to their fields. Focus indicators, menus, dialogs, and carousels need both visual and keyboard behavior verified in RTL and LTR.
Treat content as a system dependency
Give writers complete messages and context rather than fragments assembled in code. Avoid concatenating a number and noun in an order fixed for English. Support plural and grammatical variation through localization tools. Provide character guidance only where the UI has a real constraint, and redesign when essential meaning does not fit. Native SEO titles and descriptions should differ by locale; translating a long heading into metadata creates poor search copy.
Test components, pages, and workflows
Component stories should render Arabic, English, long text, mixed strings, validation, loading, and empty states. Automated checks can catch physical CSS properties and missing direction attributes, but visual and assistive-technology review remains necessary. Test workflows such as form completion and pagination, not isolated cards only. Include real devices and browser zoom. Record intended mirroring behavior so a future redesign does not reintroduce guesses.
Handle charts, maps, and timelines by meaning
Not every visualization should reverse. A time series may follow the locale’s reading direction, while a geographic coordinate system should not mirror. Axes, legends, tooltips, and keyboard traversal need a documented decision. Progress steps often begin at the inline start; media timelines usually retain established behavior. Ask what the spatial direction represents before applying scaleX(-1), which can also mirror text and interaction unexpectedly.
Govern exceptions and migration
Create lint rules or review checks for new physical properties, but maintain an explicit exception list for legitimate cases. Migrate high-use components first and remove overrides as each component becomes direction-aware. Track defects by pattern—mixed text, icon, source order, clipping—so fixes improve the system rather than one page. Require Arabic and English evidence in component review. Direction quality is a release concern, not a localization team cleanup.
Conclusion: build direction into the contract
An RTL-first system is successful when teams can compose a new page without reopening left/right decisions, while native content and accessibility remain intact. Establish document direction, logical tokens, icon policy, bidi handling, typography, and dual-direction tests as shared contracts. To audit an existing library, request an RTL design-system review with representative forms, tables, navigation, mixed text, and keyboard flows.