Testing Arabic and RTL Apps: The Defects Teams Miss

Arabic-speaking users find RTL defects within the first hour of a release. A phone number that reads backwards. A national ID field that rejects the digits the Arabic keyboard just typed. A search that finds "احمد" but not "أحمد". A receipt PDF with disconnected letters. None of these break a build, and most pass every automated test the team owns.

This article is for heads of QA, engineering leads and product owners shipping Arabic-first or bilingual applications in Saudi Arabia, especially government and citizen-facing platforms where Arabic is the primary language, not a translation. It lists the defect classes that escape, the reason each one escapes, and the tests that catch it. The outcome to aim for: every release runs its full regression in Arabic as well as English, and Arabic defects found in production trend towards zero.

Why Arabic defects escape

• The product is built and tested in English first. Arabic arrives late, as strings in a file, and is checked by a reviewer reading a spreadsheet rather than the rendered screen.
• RTL is treated as a CSS flip. Mirroring the layout is the easy part. Text direction, numbers, dates, search and documents are where defects live.
• Automated tests assert on element IDs, not on what the user sees. A test confirms the label exists. It does not confirm the label reads in the right order.
• Test data is Latin. "John Smith" and "Test123" never trigger the defects that "عبدالرحمن بن عبدالعزيز آل سعود" and "٠٥٥١٢٣٤٥٦٧" do.

1. Direction declared in the wrong place

The W3C's guidance is specific: set the dir attribute to rtl on the html element for a right-to-left page, do not use CSS to apply base direction, and use dir set to auto for forms and content inserted at run time, where the direction is not known in advance. The same guidance warns that a language declaration does not set direction; both are needed.

Test: load every page in Arabic and confirm the base direction comes from markup. Turn off stylesheets and check the page still reads right to left. Enter Arabic and English into every free-text field and confirm each displays correctly in its own direction.

2. Mixed-direction text

Arabic screens are full of left-to-right runs: phone numbers, IBANs, order references, email addresses, product names in English. The Unicode Bidirectional Algorithm decides how these runs are ordered, and it handles most cases well. The defects come from the neutral characters between runs. The W3C explains that punctuation between opposite-direction runs takes the base direction, which is why an exclamation mark or a full stop jumps to the wrong end of a phrase, and why brackets appear to face the wrong way.

Common failures:

• "رقم الطلب: ORD-2026-0042" renders with the hyphenated parts reordered.
• An English product name at the end of an Arabic sentence pulls the full stop to the wrong side.
• A phone number with a plus sign or spaces displays with the country code at the wrong end.
• A user name in English inside an Arabic notification reorders the sentence around it.

Test: build a data set of mixed strings for every field type, and assert on the rendered visual order, not just the stored value. Isolate user-supplied and dynamic values so they cannot reorder the text around them.

3. Digits: Arabic-Indic and Western

Saudi users type both sets. An Arabic keyboard may produce Arabic-Indic digits (٠١٢٣٤٥٦٧٨٩); a pasted value may carry Western digits. The W3C's Arabic and Persian Layout Requirements describe the numeral families in use and note that Arabic-Indic digits belong to a different bidirectional category from European digits, so they can order differently inside right-to-left text.

Common failures:

• National ID, Iqama, phone and card fields reject Arabic-Indic digits as "invalid".
• Amounts entered in Arabic-Indic digits are stored as text, then fail calculation or reconciliation.
• One screen mixes both digit sets because some values are formatted by the server and others by the browser.
• Thousands and decimal separators are wrong for the chosen digit set.

Test: enter every numeric field in both digit sets and with mixed input. Confirm the value is normalised before validation and storage, and that display follows one rule per screen. The W3C notes that search may map numeric characters to ASCII digits; decide whether your search does.

4. Hijri and Gregorian dates

Saudi users and documents use both calendars, and official dates follow the Umm al-Qura calendar. Numeric dates are ambiguous even within one calendar; the W3C recommends spelling out the month and using a four-digit year where misreading is possible.

Common failures:

• Hijri dates converted with a different calendar rule show a one-day difference from the official date.
• A date picker opens in Gregorian when the form label asks for Hijri, or the reverse.
• Day and month swap places in numeric formats.
• Age, eligibility or expiry calculations treat a Hijri date as Gregorian.
• Month names appear in English on an Arabic screen.

Test: run date fields with Hijri and Gregorian input, month boundaries and the end of the Hijri year. Compare conversions against the official calendar, not against another library's output.

5. Name fields

The W3C's guidance on personal names around the world notes that Arabic names can contain connecting elements such as "ibn" and "bin", that names may be much longer than designers expect, and that forms should not force a family name or a first-and-last split.

Common failures:

• Length limits cut a full four-part name.
• "Family name" is mandatory and users enter a placeholder.
• The Latin-script name must match an official document exactly, but the field strips hyphens, apostrophes or spaces.
• Sorting and search ignore or mishandle the prefix "آل" or the article "ال".

Test: use a set of real-shaped Arabic names: long, multi-part, with "بن" and "آل", with and without a Latin transliteration.

6. Search normalisation

Arabic users spell the same word several ways, and they rarely type short vowels. The W3C notes that Arabic users generally do not enter short vowels, and that a search term without diacritics should by default match text that has them.

Decide and test the folding rules explicitly:

• Alef forms: أ إ آ and ا.
• Taa marbuta and haa: ة and ه at the end of a word.
• Alef maqsura and yaa: ى and ي.
• Hamza carriers: ؤ and ئ.
• Tatweel, the elongation character, inside a word.
• Diacritics present in the data but not in the query.

Test: for each rule, search with each variant and assert the same results. Then confirm the rules do not over-match in fields where the exact spelling matters, such as names on official records.

7. Mirroring and icons

A mirrored layout is necessary and not sufficient. Decide icon by icon. Arrows that mean back, forward or next follow the reading direction. Logos, check marks and clocks do not. Progress bars, steppers, sliders, carousels and swipe gestures must all agree on which way is "forward". Charts and timelines need a deliberate decision, made once and applied everywhere.

Test: compare Arabic and English screenshots of every screen side by side and review each directional element against the agreed rule.

8. Truncation, line height and spacing

The W3C notes that Arabic often needs more line height than Latin text and is hard to abbreviate, because words are built from compact roots. Ellipses appear on the wrong side, labels clip at the top and bottom, and fixed-width buttons cut words in half. Letter-spacing is a quiet offender: the CSS Text specification tells authors to avoid applying letter-spacing to cursive scripts such as Arabic.

Test: render the longest Arabic string for each component at every breakpoint, and check vertical clipping as well as horizontal.

9. PDFs, receipts, SMS and email

Generated documents fail more often than screens, because they bypass the browser. Look for disconnected letters, reversed words, missing glyphs shown as boxes, and numbers out of order on receipts and certificates. Plain-text channels need care too: where markup is unavailable, the W3C points to Unicode bidirectional control characters to fix the order of numbers and punctuation.

Test: generate every document type with Arabic and mixed content, open it in more than one reader, and copy the text out to confirm it is stored in logical order. Send every SMS and email template to real devices.

10. Screen readers

WCAG 2.2 success criterion 3.1.2, Language of Parts, exists so that screen readers can use the pronunciation rules of the language of each passage. An English phrase inside an Arabic page without a language declaration is read with Arabic rules.

Government platforms

For entities building government services, the Digital Government Authority publishes Platforms Code, its design system for government platforms. Treat it as part of the requirement set your tests check against, alongside the defect classes above. See how we approach government and smart city platforms.

Measures to track

• Arabic defects found in production per release.
• Share of the regression suite that runs in the Arabic locale.
• Time from commit to full regression result, in both languages.
• Number of open defects tagged RTL, bidi, digits, dates or documents.

How TQN tests it

Arabic and RTL support is built into our Quality Engineering practice. AI agents run every flow in Arabic and English, generate test data with real-shaped Arabic names, mixed digits, Hijri dates and mixed-direction strings, compare screens across both languages and attach video logs and root-cause analysis to every failure. When the interface changes, the agents repair the tests, so the Arabic suite stays current with the English one.

Start with a QA Readiness Review

The first step is free. Walk us through one application and its release process. We will run a short Arabic and RTL pass on the screens you choose, show you what we find, and outline what a fixed-scope pilot would cover. Book a QA Readiness Review.