How do you test an Arabic website for RTL problems?

Look at the rendered page, not the source, at more than one width: direction and mirroring, mixed Arabic and Latin text, Arabic typography, untranslated strings and overflow. A person who reads Arabic judges the writing; a deterministic scan measures the rendering and can repeat the measurement after every release.

Can an accessibility scanner check right-to-left layout?

Not really. A page laid out left to right is not an accessibility failure, so it is not reported as one, and mixed-direction text or missing Arabic font coverage passes structurally. Run one anyway, for accessibility.

Is a bilingual tester enough?

For judging the Arabic writing, yes, and nothing replaces it. For every page at every width after every release, it becomes hours, and a second pass is a second opinion rather than a diff.

Do we still need localization QA tooling?

Yes. Pipeline tooling catches missing keys and broken placeholders before a string ships; a rendered-page check sees what happens after it has. Catching a problem at the source is cheaper, so keep both.

Where should a team with no Arabic QA start?

With the free scan on the Arabic page that matters most. It takes about a minute and needs no account, and it tells you whether the rendering needs work before you decide whether to hire a tester, buy a plan or book an audit.

Compare approaches

Four ways to find Arabic defects

No products are named here, because the question a buyer actually has is which kind of check to run. Two of the four below are not alternatives to this one: run them as well.

Run a free scan See each approach

What each approach catches, by kind of Arabic defect
Defect	Bilingual tester	Accessibility scanner	Localization tooling	Ritla
Direction and mirrored layout	catches	misses	misses	catches
Numbers, emails and Latin inside Arabic text	partly	misses	misses	catches
CSS that will not mirror, named by selector	misses	misses	misses	catches
Arabic typography and font fallback	partly	misses	misses	catches
Untranslated strings on the page	catches	misses	partly	catches
Whether the Arabic reads well	catches	misses	misses	misses
Flows behind a login, payment or bot check	catches	not what it checks	not what it checks	misses
Contrast, labels and structure	misses	catches	misses	partly
A repeatable diff after every release	misses	catches	catches	catches

catches
partly
misses
not what it checks

The line

Mirroring is solved. Arabic isn't.

Logical properties and dir="rtl" are table stakes: every modern kit ships them. What still breaks is everything a flip does not touch.

What a mirrored interface gets right, and what an Arabic-native one also needs
What the reader gets	Mirrored	Arabic-native
The layout reads right to left	yes	yes
Margins, padding and icons flip with the direction	yes	yes
Arabic text is set in a font that has ArabicR050	no	yes
No letter-spacing or synthetic italic on a connected scriptR051 R054	no	yes
Phone numbers, emails and prices keep their orderR021	no	yes
One numeral system per viewR061	no	yes
Inputs type in the reader's direction; phone and email stay left to rightR023 R070	no	yes
The page says it is Arabic (`lang="ar"`), for screen readers and searchR002	no	yes

In detail

What each one catches, and what it misses

Including ours, with a misses list as long as anyone else's.

A bilingual tester, by hand

Somebody who reads Arabic opens the product and writes down what is wrong.

Catches

Tone, register and whether a translation is actually idiomatic
Anything that needs judgment about meaning
Defects in flows a crawler cannot reach, behind a login or a payment

Misses

Repeatability. A second pass is a second opinion, not a diff
Breadth. Every page, every width, every release is more hours
Mechanism. It finds that something looks wrong, rarely which rule and which selector

Best for: Judging whether Arabic copy is good. No tool decides that, and a scan that said otherwise would be lying.

A general accessibility scanner

An automated pass for contrast, labels, landmarks and structural accessibility.

Catches

Contrast, alternative text, form labeling, heading structure
Regressions in all of the above, on every build, for free

Misses

Direction. A page laid out left to right is not an accessibility failure and will not be reported as one
Bidirectional text. Mixed Arabic and Latin runs, neutral characters resolving the wrong way, numerals inside a right to left line
Arabic typography. A face with no Arabic coverage falls back silently and the page still passes
Untranslated strings, which are structurally perfect and semantically wrong

Best for: Accessibility, which is a different job. Run one. It is not in competition with this and every site should have both.

Localization QA tooling

Checks over the translation pipeline: missing keys, placeholder mismatches, string length budgets.

Catches

Untranslated and stale keys before they ship
Broken interpolation and plural forms
Strings that will overflow a known budget

Misses

Everything that happens after the string reaches the page: the CSS that positions it, the font that renders it, the direction it inherits
Text that is not in the pipeline at all, which is most of a third-party widget
Whether the rendered result is readable, as opposed to whether the input was complete

Best for: Catching translation problems at the source, which is earlier and cheaper than catching them on the page. Also not in competition with this.

Ritla

this is us

Deterministic checks on the rendered Arabic page, with a screenshot, a selector and a fix for each finding.

Catches

Direction and bidi defects in the rendered result, not in the source
Physical CSS that will not mirror, per property and per selector
Arabic typography: missing coverage, silent fallback, tracking applied to a connected script
Untranslated content on a page that is otherwise Arabic
Overflow and clipping per breakpoint, because Arabic runs longer
The same defects again after a release, with a diff rather than a second opinion

Misses

Whether the Arabic is any good. It checks the rendering, never the writing
Anything behind a login, a payment step or a bot check
Design intent. An asymmetry on purpose and an asymmetry by accident look identical to a rule, which is why the declines list exists

Best for: Proving an Arabic product renders correctly, repeatably, with evidence a client or a developer can act on without a meeting.

The short answer

Pick by the question you need answered

If you need to know whether the Arabic reads well→ A bilingual testerNo tool decides this.
If you need to know whether it renders correctly, on every page and width→ RitlaWith a screenshot, a selector and a fix per finding.
If you need to know whether translation is complete before it ships→ Localization QA toolingEarlier and cheaper, at the source.
If you need to know whether it is accessible→ An accessibility scannerA different job. Every site should run one.

Most teams shipping Arabic seriously need a person and a scan, and the scan is the cheaper half to start with because it costs nothing to try.

By team

Written for the person deciding

FAQ

Questions about testing Arabic

Start with the half that costs nothing

Scan the Arabic page that matters most. In about a minute you will know whether the rendering needs work.

Run a free scan See every check

Four ways to find Arabic defects

Mirroring is solved. Arabic isn't.

What each one catches, and what it misses

A bilingual tester, by hand

Catches

Misses

A general accessibility scanner

Catches

Misses

Localization QA tooling

Catches

Misses

Ritla

Catches

Misses

Pick by the question you need answered

Written for the person deciding

Find the Arabic defects that cost your storefront sales

Show clients Arabic work that is right, not just translated

When you want a person to review, fix or keep watching

Questions about testing Arabic

Start with the half that costs nothing