Arabic RTL Design: 9 UX Mistakes That Cost Gulf Stores Sales

Arabic RTL design is the part of an e-commerce build that gets left until Thursday afternoon, and it shows. I have designed storefronts on Salla, Zid, WordPress, Shopify and OpenCart for merchants across Saudi Arabia and the Gulf, and the same nine problems come back on almost every store I inherit. They are small, fixable things that make an Arabic shopper feel like they are using somebody else's store in translation — and hesitation at checkout is expensive.

Why Arabic RTL Design Is Not a Mirror Image

Flipping a layout horizontally takes one second in Figma. That is the whole problem: it feels finished. But direction is not the only thing that changes when a page becomes Arabic — reading rhythm, word length, line height and the corner a shopper's eye lands in change with it. A mirrored English design is an English design wearing Arabic clothes, and everyone can tell.

Nine RTL UX Mistakes That Cost Gulf Stores Sales

1. Mirroring the layout but not the reading flow

   A blanket horizontal flip moves the boxes and takes everything with them: photography reverses, the logo reverses, a model's parting swaps sides. And nobody re-checks hierarchy. In Arabic the first fixation is the top-right corner — the most valuable space on the page — and after a naive flip it usually holds a search icon while the logo has drifted left.

   The fix: mirror the structure, never the content. Rebuild the composition instead of flipping the artboard, keep photographs and brand marks as drawn, then ask: what should an Arabic reader see first, and is it top-right?

2. Treating Arabic as a translation layer

   Design in English and pour Arabic in afterwards and the layout has no slack. Arabic usually needs fewer characters to say the same thing, so buttons look half empty; but it needs more vertical room, so the headline that had to be two lines becomes three and pushes the hero below the fold.

   The fix: design RTL first. I build the Arabic layout, settle the type scale and spacing there, and derive the English version from it. English is far more forgiving to adapt into, so you spend your tolerance where you need it.

3. A Latin display font with a bolted-on Arabic fallback

   The most common Arabic web typography failure I see. The stylesheet declares a beautiful Latin display face, then lets the browser fall back to whatever Arabic font the device ships. Your type scale evaporates: the fallback sits differently on the baseline, and the browser fakes a bold that smears beside your real weight.

   The fix: choose the Arabic typeface first and a Latin companion to match — ideally one family drawn with both scripts. Load real weights, set line height explicitly for Arabic (the 1.4 you use for Latin crowds the dots; I sit closer to 1.8), and preview on iOS, Android and Windows.

4. Letter-spacing applied to Arabic

   Arabic is cursive — the letters join. Tracking pushes joined glyphs apart and the word disintegrates into fragments. It arrives by inheritance: the design system sets letter-spacing on uppercase Latin headings, the Arabic build inherits it, and every heading looks broken to a native reader while looking merely airy to whoever shipped it.

   The fix: scope tracking to Latin only. Reset letter-spacing: normal at the Arabic root and re-apply it inside an explicit Latin wrapper. Word-spacing is safe; letter-spacing is not. And since uppercase does nothing in Arabic, hierarchy you were getting from caps must come from weight, size or colour.

5. Numbers, prices, phones and dates flipping inside Arabic text

   This one silently costs money. The Unicode bidirectional algorithm resolves neutral characters — plus signs, hyphens, slashes, brackets — from their surroundings. Drop a phone number into an Arabic paragraph and the plus can land at the wrong end; a hyphenated price range can render with its two figures swapped, so the low end shows where the high end should be. Shoppers then read the wrong price.

   The fix: isolate every Latin or numeric run. <bdi> is the cleanest tool; a span with unicode-bidi: isolate; direction: ltr; does the same. Wrap prices, phone numbers, order IDs, SKUs and email addresses. Then pick Western or Arabic-Indic digits once and hold that everywhere — mixing the two is what actually confuses people.

6. Mirroring icons that should never be mirrored

   Direction-carrying icons must flip: back and forward arrows, chevrons, breadcrumb separators, reply, undo and redo, and the arrow inside a checkout button. Icons showing a real object or a universal convention must not: the play button points right in every language, a clock runs clockwise, and a shopping bag, a credit card or a brand glyph stay exactly as drawn.

   The fix: keep an explicit mirror / do-not-mirror list in the design file and flip per icon class, e.g. [dir="rtl"] .cs_icon_arrow { transform: scaleX(-1); }. Never blanket-flip every svg — that is how you get a backwards play button and a reversed logo.

7. Forms, placeholders and validation left in LTR

   An Arabic checkout with left-aligned inputs is the fastest way to lose someone at the last step. The caret starts on the wrong edge, the placeholder hugs the wrong side, the checkbox sits on the wrong side of its text, and the error appears under a different edge from its field.

   The fix: let every control inherit direction from the document, then handle the two real exceptions. Phone and email fields need direction: ltr so characters stay in order, with text-align: right so they hug the same start edge as everything else. Write your own Arabic validation copy — the browser's native bubble speaks the browser's language, not the page's.

8. Sliders, carousels and progress bars still moving left to right

   Most JavaScript components read direction from their own config, not from your CSS. So you set dir="rtl", the text obeys, and the hero slider still starts on the left and puts next where previous belongs. Multi-step checkouts fill the progress bar from the left while the labels read right to left, which makes step 1 look like step 4.

   The fix: pass direction into the component explicitly — rtl: true for Slick, dir: 'rtl' for Swiper, the equivalent flag for your grid library — and re-initialise on language switch. Then test by hand: does slide one appear on the right, and does the bar fill from the right edge?

9. English UI labels scattered through an Arabic interface

   A SALE badge baked into a banner image. A breadcrumb reading Home / Products. A theme string nobody found in the admin, so the empty cart still says "Your cart is empty". To a Gulf shopper it reads as this store was not built for me — the wrong signal at the moment they decide to hand over a card number.

   The fix: sweep every string in the browser, on a phone, before launch, and open the states nobody demos: empty cart, out of stock, failed payment, no results. One honest exception — brand names, payment marks, size labels like XL and model numbers do live in Latin for Gulf shoppers. UI chrome does not.

“Right-to-left is not a setting you switch
on at the end. It is the layout you
start from.”

The technical layer: dir, logical properties and direction-aware JavaScript

Most of the nine problems above survive because someone assumed CSS would handle direction on its own. It handles some of it; be deliberate about the rest.

Put dir="rtl" on the root element

Set <html lang="ar" dir="rtl"> — not dir on a wrapper div, and not on body alone. Modals, tooltips and third-party widgets often render at the end of the document, outside your wrapper, and inherit from the root or from nothing. The root is also the base direction the bidi algorithm uses, which is what keeps mistake five in check.

Write logical properties instead of left and right

Physical properties force you to maintain two stylesheets that slowly drift apart. Logical ones let a single rule serve both directions:

• margin-left / margin-right → margin-inline-start / margin-inline-end

• padding-right → padding-inline-end, border-left → border-inline-start

• left / right → inset-inline-start / inset-inline-end, and text-align: left → text-align: start

Flex and grid already think logically. The exceptions bite after launch: transform: translateX(), box-shadow offsets, background-position and gradient angles are physical, not logical, and still need a [dir="rtl"] override with the sign reversed.

Tell your JavaScript which way the page runs

Anything that measures the DOM or animates a position needs telling explicitly: sliders, masonry grids, drag-and-drop, charts and sticky offsets. Read the direction once at boot — var isRTL = document.documentElement.getAttribute('dir') === 'rtl'; — and pass that flag into every component config. CSS gives you the layout; JavaScript gives you the behaviour, and only one of them reads your dir attribute.

How I build Arabic RTL design into every store

My process is the same whichever platform we land on. I design the Arabic layout first, in Arabic, with real product names and prices rather than Lorem Ipsum — placeholder Latin text hides every problem above. Once the Arabic version reads properly, the English build is a derivative, not a translation. If you are still choosing a platform, my comparison of Salla, Zid, Shopify and WordPress covers where each one helps and where it gets in the way.

On Salla most of the RTL groundwork is already there, and the mistakes creep in through custom sections, imported banners and third-party apps — I cover that in the Salla store design guide. These nine issues do the most damage on the product page, where a flipped price, an LTR quantity field and an English "Add to Cart" stack up in one viewport; the twelve elements that turn browsers into buyers are all direction-sensitive. You can see the finished layouts across my store and interface projects.

A short pre-launch RTL checklist

Run these on a phone, in Arabic, before you go live:

• Every price, phone number and order ID reads correctly inside Arabic sentences.

• No heading carries letter-spacing, and no weight is being faked by the browser.

• The hero slider starts on the right and swipes the way a shopper expects.

• Checkout fields, labels, checkboxes and errors all align to the same edge.

• No play button, logo or product photo has been accidentally mirrored.

None of this is difficult. It is work that happens at the start rather than the end, and it is the difference between a store that feels imported and one that feels native. Identity pulls the same way — I wrote about that in the brand identity guide for e-commerce, from logo to packaging.

If you want me to look at your own store, send me the link on WhatsApp and I will tell you which of these nine are on it and what I would change first — message me here, or use the contact page if you prefer a form.