The RTL Testing Checklist for Arabic Interfaces
A complete, copy-ready checklist your product, QA, design, and engineering teams can run today — no vendor required. It covers everything we check when we test Arabic products, grouped so you can split it across roles.
Tip: run it once on your highest-revenue flow first. If that flow passes, most of the rest is polish; if it fails, nothing else matters yet.
1.Document direction and layout
- html has dir="rtl" and lang="ar" on Arabic routes (not just CSS text-align)
- Layout uses logical properties (margin-inline, padding-inline, inset-inline) — search the codebase for hardcoded left/right
- Scrollbars, sticky elements, and floating buttons appear on the expected side
- No horizontal overflow at 320px, 375px, and 768px in Arabic
2.Component mirroring and icons
- Drawers, sidebars, and menus open from the correct side
- Breadcrumbs, steppers, and progress indicators flow right-to-left
- Directional icons (back/forward arrows, chevrons) are mirrored — but universal symbols (play, refresh, checkmarks) are NOT
- Carousels and swipe components advance in the reading direction
3.Mixed-direction content (bidi)
- Product codes, emails, URLs, and brand names render intact inside Arabic sentences (use bdi or dir="ltr" spans)
- Parentheses and punctuation don't jump to the wrong end of mixed lines
- Numbers with units (5 GB, 100 IQD) keep value and unit in the right order
- User-generated content with mixed languages doesn't scramble neighboring text
4.Forms, phone, OTP, and email fields
- Labels and inputs align to the right; placeholder text is Arabic
- Phone, OTP, email, and code inputs are forced LTR inside the RTL form
- Validation messages appear on the correct side and in Arabic
- Cursor starts at the correct end; autofill doesn't inject LTR artifacts
- Required markers and helper text sit beside the right labels
5.Tables, dashboards, and charts
- Column order follows RTL reading; the first (identity) column is rightmost
- Numeric columns keep a consistent alignment decision (usually LTR digits, consistent edge)
- Sort arrows and pagination controls are mirrored
- Chart axes, legends, and tooltips are reviewed per library — most default to LTR
- CSV/Excel exports open readably for Arabic users
6.Dates, time, currency, and addresses
- Dates use locale-aware formatting (Intl.DateTimeFormat), with an explicit Gregorian/Hijri decision per market
- Currency symbols sit on the agreed side (IQD, SAR, AED, QAR, KWD differ from $ conventions)
- A deliberate decision exists for Arabic-Indic (٠١٢) vs Latin (012) digits — applied consistently
- Address forms match the market structure (governorate/district/landmark), not street-and-ZIP
7.Truncation and text expansion
- Buttons, tabs, and badges survive longer Arabic labels without overflow
- Ellipsis truncation cuts at the correct (left) end for RTL text
- Line-height fits Arabic ascenders/descenders — no clipped letters like ج or ى
8.Mobile and keyboard
- Navigation drawer, bottom bars, and gestures behave correctly in RTL
- The Arabic keyboard appears for text fields; numeric keyboards for phone/OTP
- Swipe-to-delete/archive directions match user expectation
- Safe-area insets and toasts appear on the correct side
9.PDF, email, and notifications
- Transactional emails render RTL in Gmail/Outlook clients (test, don't assume)
- Invoices and PDF exports lay out RTL with correct column order
- Push/SMS/WhatsApp templates read naturally with variables in position
10.SEO metadata and localization architecture
- Arabic pages have Arabic titles and meta descriptions (not reused English)
- Canonicals self-reference; hreflang pairs only real equivalents — and is reciprocal
- Locale routing has a clear URL strategy (path prefix) without duplicate-content leaks
- Structured data is in the page's language and matches visible content
11.Accessibility
- Screen readers announce Arabic content with the correct language (lang attributes on mixed fragments)
- Focus order follows the RTL visual order
- Contrast holds for Arabic type sizes (thin Latin fonts often pair badly with Arabic)
- Keyboard navigation works across mirrored components
12.Browser and device pass
- Chrome, Safari, and Firefox — Arabic rendering differs per engine
- iOS and Android real devices, not only emulators
- One full revenue flow (signup or checkout) executed end-to-end in Arabic before every release
Frequently asked questions
How long does a full RTL test pass take?
For a mid-sized product, a disciplined first pass over this checklist typically takes one to three days across desktop and mobile. Subsequent release passes are much faster if you keep the failing areas as regression cases.
Can we run this checklist without knowing Arabic?
Most of it, yes — direction, mirroring, forms, tables, and overflow are visual and structural. Terminology, tone, and ambiguity checks require an Arabic reader; mark those items for a native review.
What are the highest-priority items?
Anything inside a revenue or access flow: checkout forms, phone/OTP inputs, validation messages, and payment panels. A cosmetic mirroring bug is a polish item; a flipped OTP field blocks login for every user.