How to QA Arabic without speaking Arabic

Use repeatable checks to find Arabic interface, RTL, format and workflow bugs, while routing language judgments to a fluent reviewer.

GuideSep 24, 202615 min read

You do not need to read Arabic to prove that an Arabic route lost its dir="rtl", a dialog clips its buttons, an order ID changed visual order, or an English error escaped translation. Those are observable failures with reproducible evidence.

You do need a fluent reviewer to decide whether a sentence is accurate, natural, appropriate for the market and consistent with product terminology. Treating those two kinds of work as one task causes trouble in both directions: non-speakers guess at language, while fluent reviewers spend time reporting CSS defects that engineering could have found earlier.

The workable approach is to divide Arabic QA by claim. Test structure, direction, geometry, formats, interaction and known strings with deterministic expectations. Reserve meaning, tone and linguistic correctness for someone qualified to judge them.

Separate observable checks from language judgments#

A non-speaker can test any requirement that has a visible, computed or data-level expected result. “The root has lang="ar" and dir="rtl"” is deterministic. “The ticket number 5093-22 displays in that order after its Arabic label” is deterministic. “This confirmation message sounds natural to a customer in Riyadh” is not.

Use this boundary when assigning work:

Requirement	Non-speaker can verify	Fluent Arabic reviewer required
Route and document setup	URL, locale persistence, `lang`, `dir`, metadata	Whether the selected locale is right for the audience
Translation coverage	Unexpected Latin text, missing strings, English attributes	Correctness, tone and terminology
Layout	Alignment, overflow, overlap, clipping, component order	Whether visual emphasis fits reading expectations
Mixed content	Exact phone, email, URL and ID display	Whether surrounding Arabic punctuation reads naturally
Forms	Field direction, labels present, error association, keyboard use	Whether labels and validation explain the right thing
Formats	Output matches a written digit, date, calendar and currency rule	Whether the rule itself suits the market
Typography	Rendered font, fallback, size, line height, clipping	Readability, typographic taste and ambiguous glyphs
Accessibility	Focus order, accessible names present, language attributes	Arabic screen-reader pronunciation and label quality

Do not turn fluent review into a final ceremonial check. Language can affect component size, argument order, plurals and navigation labels. Bring a reviewer into fixture design and terminology decisions early, then run the observable sweep before asking for the final linguistic pass.

Write the expected result before opening the page#

Testing an unfamiliar script by visual impression is unreliable. Build an evidence pack that lets the tester compare facts instead of guessing.

For each critical journey, record:

the Arabic URL and how locale should persist through sign-in, redirects and refresh;
the expected root lang and dir values;
approved screenshots or designs for a few stable states;
the exact source and expected display of IDs, phones, emails and prices;
the market's digit, currency, date, time and calendar decisions;
the minimum supported viewport and browser matrix;
translated test strings for success, empty, invalid, loading and failure states;
which observations require sign-off from a fluent reviewer.

Use hostile data, not short placeholders. Include a long navigation label, a multiline validation error, a Latin product name, a digit-leading ticket or order number, a local phone number, an email address, a negative price and a date with a day above 12. Add user content that begins with Arabic, Latin letters and digits.

Keep a small set of approved Arabic strings with stable IDs. The non-speaker does not need to understand them, but must know which string belongs in each state. If translation changes, update the fixture through the same review process as the product copy. Screenshots alone are weaker because they hide the underlying text and become stale after minor layout changes.

Verify the route and document before reading the screen#

Open a deep Arabic URL in a private session. Refresh it, follow a link, submit a form, sign in and sign out. The Arabic route should survive each transition according to the product's locale contract. A homepage language switch does not prove that a checkout or account route preserves locale.

Inspect the live document root:

html

<html lang="ar" dir="rtl">

The lang attribute identifies language for browsers and assistive technology. The dir attribute establishes base direction. They solve different problems.

In Chromium 151, measured on 2026-09-17, lang="ar" alone still laid the page out LTR. CSS direction: rtl changed rendering but did not make the element match :dir(rtl). Firefox and Safari were not measured for the behavior cited in this guide, so run the same checks in the supported matrix.

R001 reports an Arabic page whose root direction is missing or LTR. R002 reports a missing, non-Arabic or contradictory root language. A failure here blocks meaningful layout review because every descendant starts from the wrong context.

For public pages, compare the Arabic title, description, social metadata, canonical and language alternatives with the route contract. R003, R004, R005 and R006 cover gaps in those surfaces. A non-speaker can compare approved strings and URL relationships without deciding whether the Arabic prose is good.

Find untranslated content without translating it yourself#

Unexpected Latin text on an Arabic page is a useful signal, not automatic proof of a bug. Brand names, email addresses, model numbers, URLs and user-generated content may be intentionally Latin. The test is whether each occurrence has a reason.

Sweep the complete journey for:

headings, body copy and navigation;
buttons, tabs, menus and footer links;
placeholders, image alternatives, tooltips and accessible names;
validation messages and help text;
empty, loading, permission, error and success states;
content rendered inside dialogs, toasts and popovers;
page titles and browser-visible metadata.

R010 reports visible Latin-script body text above thresholds on an Arabic page. R011 reports untranslated interactive labels. R012 reports untranslated attribute text such as placeholders, alternatives, titles, accessible labels and button values. Treat each report as a review queue. The tester should classify the text as approved foreign content, a missing translation, user data or an unresolved question.

Do not use browser translation as the oracle. It can produce Arabic-looking text and still hide a missing product string, wrong placeholder or English accessible name. It can also alter the page you are trying to inspect. Compare the rendered string to the approved localization resource or fixture instead.

A useful bug includes the source key if available, the observed string, the expected approved string, the state that exposed it and whether the text is visible or assistive-only. “Some English remains” is difficult to reproduce and easy to misclassify.

Test geometry without understanding the words#

Overflow, overlap and clipping do not require language fluency. Test them at the minimum supported width, intermediate breakpoints, wide desktop and 200 percent zoom. Wait for the Arabic font and API content to load, then open every dynamic surface.

Compare the English and Arabic versions by relationship, not by pixel reflection. A leading field icon should remain at logical start. A trailing action should remain at logical end. Drawers should enter from their defined edge. Physical content such as a map or product photo should not be flipped merely because the page is RTL.

Prefer CSS logical properties in shared components:

A toggle switch is a good object to practise on, because its correct behavior is visible without reading a word: the knob should start at the reading edge and travel toward the other.

Fragile

css

.switch-knob { left: 2px; }
.switch[aria-checked="true"] .switch-knob { left: 22px; }

Direction-aware

css

.switch-knob { inset-inline-start: 2px; }
.switch[aria-checked="true"] .switch-knob { inset-inline-start: 22px; }

With the fragile rules, the Arabic switch starts on the left and moves right, the opposite of every other control on the page.

R022 reports explicit left alignment on majority-Arabic text. R030, R031, R032 and R033 report physical properties, floats, directional shadow or indentation, and transforms that can fail under RTL.

Look beyond alignment. R040 reports document-level horizontal overflow, R041 reports visible text-bearing elements that overlap, R042 reports clipped text under specific overflow conditions, and R043 reports a fixed-pixel-width container whose Arabic text exceeds its space. Reproduce the defect with the same string and viewport, then include the element's bounding box and containing block in the issue.

Do not “fix” overflow by hiding it on the document. That removes the scrollbar without making covered content reachable. Find the child that extends beyond its intended boundary and correct the component constraint.

Use fixed mixed-direction values as test instruments#

Arabic interfaces regularly contain LTR values. The Unicode Bidirectional Algorithm lays out each run according to character types and surrounding context. A value can be stored correctly yet display in a misleading order.

Use exact fixtures whose expected visual order is known:

text

Ticket: 5093-22
Ticket, prefixed: TCK-5093-22
Phone: +962 79 123 4567
Email: qa@example.com
Product: Disney+

Place them at the beginning, middle and end of Arabic sentences and next to punctuation. In the measured Chromium version, an unisolated 5093-22 after Arabic displayed as 22-5093. The prefixed TCK-5093-22 stayed intact in that context. The unisolated phone displayed as 4567 123 79 962+, and Disney+ displayed as +Disney. None of that requires reading Arabic to notice: compare the Latin characters on screen with the fixture, character by character.

Wrap a dynamic value at its own semantic boundary:

html

<p dir="rtl">
  رقم التذكرة <bdi>5093-22</bdi>
</p>

A plain span does not isolate anything. <bdi> or an element with a suitable dir keeps the value separate from surrounding text. R021 reports unisolated phones, emails and Latin tokens inside Arabic text. R024 reports punctuation at the wrong visual end of Arabic text.

Copying is not a sufficient test. The measured ID copied in authored order even while it displayed in the wrong order, and the accessibility tree retained the authored text. Compare the visible result with the fixture.

Exercise every form as a data-entry tool#

An Arabic form is not uniformly RTL. Names, addresses, searches and prose normally follow Arabic direction. Phone numbers, emails, URLs and codes normally remain LTR.

html

<form lang="ar" dir="rtl">
  <label for="city">المدينة</label>
  <input id="city" name="city" dir="rtl" autocomplete="address-level2">

  <label for="website">الموقع الإلكتروني</label>
  <input id="website" name="website" type="url" dir="ltr" autocomplete="url">
</form>

The URL field is the one to watch: its type does not make it left to right, so without dir="ltr" a typed https:// address edits from the right edge. A non-speaker sees that immediately, because every character in it is Latin.

Type and paste into each field. Move the caret across spaces and punctuation. Select part of the value, delete it, undo, submit invalid data and correct it. Repeat with empty, placeholder, focused, populated, disabled and error states.

In the measured browser, type="tel" was LTR by default. Email, URL, number, search and text controls inherited the page direction. An empty dir="auto" input resolved LTR, placing an Arabic placeholder at the left edge; entering the first Arabic letter changed it to RTL. That jump is observable without reading the placeholder.

R023 reports text inputs rendered LTR where Arabic input is expected. R070 reports telephone, email or URL inputs rendered RTL. R072 reports a select rendered LTR with Arabic options, and R073 reports identity fields missing autocomplete tokens.

Trigger every validation path. Chromium with an English browser interface showed an English built-in required-field message even on a page with lang="ar"; the page language did not translate the native bubble. R071 reports untranslated form labels, validation or help text. A fluent reviewer must judge whether custom Arabic errors explain the problem, but a non-speaker can prove that the approved error appears, is associated with the right field, fits its container and receives focus as designed.

Inspect Arabic typography as rendered software#

You should not judge the beauty or readability of Arabic type without the language and script knowledge to support that opinion. You can still inspect objective implementation failures.

In DevTools, check the font that actually rendered, not only the declared family. An intended Latin family may lack Arabic glyphs and fall through to a system font with different width, baseline and line height. Wait for web fonts, capture the rendered font, then compare layout before and after loading.

Check computed size, line height, style and letter spacing. Positive tracking can pull Arabic's connected letters apart. Latin display treatments such as uppercase plus tracking do not belong on Arabic text. Italic or oblique styling may be an unintended inherited style rather than a script-aware design choice.

R050 reports measured Arabic font fallback or a stack with no Arabic-capable family. R051, R052, R053, R054 and R055 cover positive letter spacing, cramped line height, undersized body text, italic or oblique styling and Latin display treatments applied to Arabic.

The fluent reviewer should still assess glyph quality, legibility, emphasis, line breaks and whether the selected typeface suits the content. The non-speaker's contribution is to provide computed evidence and reproducible states, not to declare the typography culturally correct.

Test formats against a written market contract#

Do not ask a non-speaker to decide whether Arabic-Indic or Western digits “look right.” Give the tester an approved rule: locale, numbering system, calendar, date pattern, currency, decimal separators and unit placement.

Then compare every surface that formats data: dashboard, filter, detail view, form, receipt, export, email and print. Use a date whose day is above 12 so a month/day swap cannot pass unnoticed. Include zero, negative, decimal and large amounts.

Runtime locale defaults are not the product requirement. In the measured Chromium version, ar-SA and ar-EG used Arabic-Indic digits, while ar and ar-AE used Western digits; all four used the Gregorian calendar. Locale data can change between browser versions. Specify disputed choices when the output matters. A government-services product that shows Hijri dates alongside Gregorian ones, for example, has to name the calendar, because none of the four measured locales defaulted to it:

const hijri = new Intl.DateTimeFormat("ar-SA", {
  calendar: "islamic-umalqura",
  numberingSystem: "latn",
  dateStyle: "long",
});

Those options are one product's decision, not a claim about what Saudi products should choose. The tester needs the product's decision written down, and then only has to compare output with it.

R060 reports English month or day names and MM/DD/YYYY dates in Arabic text. R061 reports Arabic-Indic and Western digits mixed in the same context. R062, R063 and R064 cover foreign currency formatting in a Saudi or Emirati market context, percent or unit ordering inconsistencies, and Latin punctuation where the Arabic form belongs. Route questions about linguistic punctuation or market preference to the fluent reviewer.

Test focus and accessibility structure#

Complete the critical journey with a keyboard. Open menus and dialogs, submit invalid forms, dismiss overlays and confirm focus returns to the trigger. The WCAG focus order guidance requires an order that preserves meaning and operation, not a particular geometric direction.

In Chromium 151, a normal flex row under RTL placed its first item at the right edge. Adding row-reverse laid items out left to right in DOM order, and Tab moved left to right. R081 reports row-reverse used to imitate RTL when tab order fights visual order. Do not patch the mismatch with positive tabindex; fix source order and layout semantics.

Inspect the accessibility tree for names, roles, descriptions and language. A non-speaker can find an English aria-label on an otherwise Arabic button and verify that an intentional English product name carries an appropriate lang attribute. R080 reports intentional foreign-language runs missing language markup.

A fluent reviewer, ideally one who uses the relevant assistive technology, must judge pronunciation, understandable naming and whether the spoken sequence communicates the same task. Presence is testable; language quality is not reducible to presence.

Force states that localization usually misses#

The initial loaded screen is the least demanding state. Change timing, content and permissions until every conditional branch appears:

direct navigation, refresh and client-side route change;
loading, skeleton and slow response;
no results and first-use empty state;
invalid input and cross-field validation;
authorization failure, server failure and retry;
expired session and reauthentication;
long translated content and user-generated content;
locale switch without a full reload;
web-font fallback and loaded font;
minimum and maximum responsive widths.

Watch direction, string source, value order, font, geometry and focus before and after each transition. If English appears only after a failed request, the bug likely belongs to an error mapping or untranslated server response rather than the initial page catalog. If overflow begins after the font loads, record both rendered fonts and dimensions.

Keep defects narrow. Report the first transition that produces the wrong state, not only the final broken screenshot. That evidence helps engineering identify whether routing, content, component CSS, formatting or asynchronous state owns the problem.

Report the observable failure, not a guessed translation#

A non-speaker's bug report should be confident about what the evidence proves and neutral about what it does not. “The text is backwards” is risky because Arabic is expected to read from the right, and mixed-direction content can look unfamiliar while remaining correct. “The authored ticket number 5093-22 displays as 22-5093 after the Arabic label” identifies a precise mismatch.

Write the title around the failing contract:

“Arabic checkout loses dir="rtl" after payment retry”;
“Phone field renders RTL on the account form”;
“Approved Arabic validation key is replaced by English server text”;
“Dialog action is clipped at 390 px after the Arabic font loads.”

Avoid titles such as “Arabic looks wrong” or “bad translation” unless a fluent reviewer has made that judgment.

A useful report contains:

text

Route: /ar/checkout/payment
State: Card rejected, retry dialog open
Viewport: 390 x 844
Input: Ticket 5093-22
Expected: Arabic locale persists; ticket displays in authored order
Actual: Root dir changes to ltr; ticket displays as 22-5093
Evidence: Screenshot, DOM root attributes, reproduction recording
Language review needed: No

Separate multiple layers when necessary. An English error and an overflowing dialog may share a trigger, but they have different owners and acceptance criteria. Link the issues through the common state instead of forcing translation coverage and component geometry into one fix.

Use “language review needed” as a real workflow state. A tester may notice that two screens use different Arabic strings for the same English source without knowing which is right. Record both strings, their keys and contexts, then assign the decision to a fluent reviewer. Once approved, the chosen term becomes deterministic regression data for future non-speaker tests.

Severity follows user impact, not the tester's ability to read the content. A corrupted amount, inaccessible action, lost locale or untranslated payment failure can block release. A suspected tone problem waits for linguistic assessment before severity is set. This prevents uncertainty about language from downgrading a defect whose technical impact is already clear.

Know what only a fluent reviewer can approve#

Automated checks, visual comparison and source-key matching cannot establish that Arabic copy is good. A fluent reviewer is required for:

semantic accuracy and omitted meaning;
natural wording rather than literal translation;
product terminology and consistency;
grammar, gender, number and plural forms;
tone, politeness and regional suitability;
punctuation choices in full Arabic sentences;
truncation decisions that preserve meaning;
ambiguous calls to action and error recovery instructions;
spoken pronunciation and comprehension;
legal, financial, medical or safety-critical language.

Machine translation can help a non-speaker understand the rough subject of a bug, but it is not acceptance evidence. It may smooth over the exact error, change terminology or translate text that the product intentionally keeps in English.

Ask the reviewer focused questions. “Is this page good?” produces broad feedback. “Does this error state tell the user that payment was rejected and that no charge was made?” is tied to a product requirement. Provide the English source, Arabic string, screenshot, route, market, character limit and surrounding action.

When the reviewer reports a language issue, store the corrected string and reasoning in the terminology or localization system. Do not leave the decision only in a screenshot comment. Future testers need a stable expected result.

Use a two-pass release gate#

Run the observable pass first: routes, attributes, translation coverage, geometry, mixed values, fields, formats, typography implementation, states, keyboard and accessibility structure. Resolve or classify those failures before linguistic sign-off. This keeps the fluent reviewer focused on claims only they can judge.

Then run the language pass on complete journeys, including failure and recovery states. A list of isolated strings misses how labels, values and actions work together on screen.

Block release when a critical journey cannot complete, locale or direction is lost, a price or identifier changes meaning, required content is unreachable, or a language error changes the task. Record lower-risk defects with an owner, accepted impact and retest state. Do not turn readiness into a raw bug count.

A Ritla scan is a useful first pass for a tester who cannot read the page, because every finding names the element, the check and the measured evidence rather than an opinion about the Arabic. Run a free scan of the journey, work the observable pass from its findings, and keep the fluent reviewer for what no scan can settle.

For the division of labour this page assumes, what Arabic QA is sets out who owns which judgment. During release sweeps, use the RTL testing checklist to keep routes, states and viewports consistent across testers.

Checks in this guide

Show every check in this guideShow fewer

How to QA Arabic without speaking Arabic

Separate observable checks from language judgments#

Write the expected result before opening the page#

Verify the route and document before reading the screen#

Find untranslated content without translating it yourself#

Test geometry without understanding the words#

Use fixed mixed-direction values as test instruments#

Exercise every form as a data-entry tool#

Inspect Arabic typography as rendered software#

Test formats against a written market contract#

Test focus and accessibility structure#

Force states that localization usually misses#

Report the observable failure, not a guessed translation#

Know what only a fluent reviewer can approve#

Use a two-pass release gate#

Checks in this guide

How to know if your website is really RTL-ready

How to test an Arabic website before launch

Common RTL bugs in production websites

See what your Arabic pages are hiding

Separate observable checks from language judgments#

Write the expected result before opening the page#

Verify the route and document before reading the screen#

Find untranslated content without translating it yourself#

Test geometry without understanding the words#

Use fixed mixed-direction values as test instruments#

Exercise every form as a data-entry tool#

Inspect Arabic typography as rendered software#

Test formats against a written market contract#

Test focus and accessibility structure#

Force states that localization usually misses#

Report the observable failure, not a guessed translation#

Know what only a fluent reviewer can approve#

Use a two-pass release gate#

Checks in this guide

Keep reading

How to know if your website is really RTL-ready

How to test an Arabic website before launch

Common RTL bugs in production websites

See what your Arabic pages are hiding