Skip to content
ENالعربية

R050: Arabic text falling back past the declared font family (measured, declared, or a webfont that failed to load)

When no font in the stack carries Arabic, or the declared webfont fails to load, each device substitutes its own default and the Arabic looks different on Windows, iOS and Android.

The check

Id
R050
Category
Typography
Default severity
high

When it fires

  1. high

    The page declares a webfont with @font-face, the browser could not load it, and Arabic text is set in that family. The Arabic is drawn in whatever the device falls back to, and nothing about the stylesheet shows it.

    Fix: Check the @font-face src: a 404, a CORS header the font CDN is not sending, or a format the browser rejected. Until it loads, the declared family does nothing.

  2. high

    Arabic text is set in a family the page declares, and measuring the rendered text shows it is identical to the browser's fallback: the family named never shapes the Arabic.

    Fix: Add an Arabic-capable family to the stack (e.g. "IBM Plex Sans Arabic", "Noto Sans Arabic") ahead of the generic fallback.

  3. highmedium confidence

    Nothing could be measured, and the stack names no family known to carry Arabic and declares no @font-face whose range covers Arabic, so the Arabic falls to each device's default. Reported at medium confidence, since an uncatalogued Arabic font could still be in play.

    Fix: Name an Arabic face explicitly in the stack (e.g. "IBM Plex Sans Arabic", "Noto Sans Arabic") instead of letting it resolve to the system default.

What it leaves alone

Families known to carry Arabic, like Tahoma, Segoe UI, Noto Sans Arabic or IBM Plex Sans Arabic; a stack naming one of those system faces, which the scanner cannot measure because its own machine does not ship them; a stack declaring a webfont whose unicode-range covers Arabic; and generic-only stacks such as sans-serif. Up to four families per page.

Broken, then fixed

before.css
body {
  font-family: "Inter", sans-serif;
}
after.css
body {
  font-family: "Inter", "IBM Plex Sans Arabic", sans-serif;
}

Check it by hand

Select Arabic text, open the Computed pane and scroll to Rendered Fonts: it names the face actually drawing the glyphs. Run [...document.fonts].filter((f) => f.status === 'error').map((f) => f.family) in the DevTools console to list webfonts that failed to load.

What the report shows you

Each R050 finding carries the fields below that apply to it, so you can see why it fired without rerunning the scan.

family
The family the Arabic text is set in.
declaredStack
The whole font-family stack, as computed.
arabicElementCount
How many elements with Arabic text use this family.
declaredFaceReady
Whether the declared face had finished loading. This is load state, not coverage.
declaredFaceErrored
Whether the browser reported the declared face as failed.
rendersSameAsFallback
The measurement: whether the Arabic renders the same as the fallback font, or nothing when it could not be measured.
signal
Which outcome this is: face-errored, measured or declared.

Components that pass it by construction

These Ritla UI components satisfy R050 by how they are built. Used as documented, they do not bring this defect onto your page.

More typography checks

Does your page trip R050?

Paste a URL. Ritla renders the page on desktop, tablet and mobile, runs every check, and shows the top issues with screenshot evidence.

Scan a page freeBrowse the checks