Arabic QA checklist for product managers

An Arabic launch can pass translation review and still fail the task a customer came to complete. The sign-in redirect can return to English. A prescription identifier can appear in the wrong visual order. A rejected insurance state can contain approved Arabic copy but clip the action that lets the customer continue.

Product managers do not need to diagnose the CSS or the bidirectional algorithm. They do need to define what the Arabic product must do, make high-risk states reachable, assign each decision to the right reviewer and refuse sign-off without reproducible evidence.

This checklist is built around those responsibilities. It treats Arabic QA as product acceptance, not a late visual pass.

Define the Arabic launch contract#

Start with decisions, not screenshots. “Support Arabic” leaves engineering and QA to guess at behavior that should come from product.

Write a short contract that answers:

• Which Arabic locales and countries are in scope?
• Which web, mobile web or app surfaces are included?
• Does every Arabic URL use an RTL document, and where may LTR values appear?
• Which numbering system, calendar, date, time, currency and unit rules apply?
• Does the product translate user-generated content, or only interface copy?
• What happens when an Arabic translation is missing?
• Which browsers, devices and assistive technologies are supported?
• Which journeys must work for launch, and which are explicitly deferred?
• Who can approve language, legal wording, market formats and directional design?

Do not let runtime defaults answer market questions. A browser can format a date for a locale, but it does not know whether the product contract requires a particular calendar or digit system. A translation framework can fall back to English, but it does not know whether English is acceptable in a medical warning.

Keep the contract versioned with the release. If the team changes the currency rule or adds a supported viewport, the acceptance evidence must change too.

Prioritize complete journeys, not page counts#

A list of translated URLs is not launch scope. Customers cross routes, redirects, dialogs, emails and error states to finish a task.

For a prescription-refill product, a useful priority set could be:

1. Create an account, verify it and recover access.
2. Search for a medicine and read dosage or eligibility information.
3. Submit a refill using an existing prescription.
4. Upload a new prescription and recover from a rejected file.
5. Choose delivery or pickup and confirm the address or branch.
6. Handle an insurance rejection, an unavailable medicine and a pharmacist question.
7. Review the final summary, confirmation and later status updates.

Rank journeys by customer harm, business impact and likelihood of change in this release. Do not treat the home page as the highest priority because it is visible. A clipped recovery action inside an insurance rejection can block care even if the landing page is immaculate.

Each priority journey needs named states. “Prescription upload tested” should expand into initial, uploading, rejected by the client, rejected by the server, retrying and complete. A route that passes only with valid data has not covered its decision points.

Assign owners before defects arrive#

Arabic QA crosses product, engineering, design, QA, localization and accessibility. Shared responsibility without named decisions becomes unowned work.

Use an ownership table tied to acceptance:

The Arabic reviewer should not be expected to find missing root direction or debug a physical CSS property. The engineer should not approve wording they cannot read. Product owns the boundary between those roles and resolves conflicting requirements.

If the team has no Arabic speaker in engineering, define a review handoff instead of pretending structural QA can approve language. The guide to QA Arabic without speaking Arabic shows how to separate evidence engineers can verify from judgments that need a fluent reviewer.

Approve language and direction as separate facts#

Arabic language and RTL direction are related, but they are not the same setting. Ask engineering for evidence of both on the live document.

For each Arabic entry route, verify:

• the root lang value identifies Arabic and any required regional variant;
• the root dir value is rtl;
• both survive authentication, redirects, client-side navigation and error boundaries;
• the Arabic URL remains selected after refresh and sign-out where the contract requires it;
• the browser title and share metadata belong to the Arabic version;
• canonical and alternate-locale links point to the intended pages.

R001 reports document direction that is missing, contradicted or declared only in CSS. R002 reports a missing, non-Arabic or contradictory html[lang]. A page can fail one while passing the other, so “the Arabic tag is present” is not sufficient evidence.

The product manager does not need a code screenshot. Ask for the Arabic URL, the route transition being tested and the observed root attributes in the rendered build. The HTML dir="rtl" guide provides the implementation detail if the team disagrees about where direction belongs.

Prepare product-shaped Arabic data#

Short labels and ideal accounts make review quick but conceal the states that need judgment. Give QA fixtures that resemble the product's difficult content.

For the refill journey, prepare:

• a long Arabic medicine name and multi-line dosage instruction;
• an Arabic delivery address with apartment and landmark details;
• a digit-leading refill reference such as 7408-63-219;
• a Latin-leading medicine code such as MED-A7-940;
• a filename containing Arabic and Latin text;
• an unavailable item with a substitution message;
• an insurer rejection with an explanation and recovery action;
• a partial prescription where one item can proceed and another cannot;
• an expired session during upload;
• a customer account with no previous orders or saved address.

Every fixture should state why it exists. The long instruction tests wrapping and information hierarchy. The refill reference tests a mixed-direction identifier. The insurer rejection tests comprehension, focus recovery and action visibility. One fixture should not be described as covering all three.

Keep ordinary fixtures too. A suite made entirely of maximum-length content can distort the default design and create noisy screenshots. The goal is representative coverage with targeted stress states, not the longest possible string in every field.

Check copy where the customer encounters it#

A spreadsheet review confirms that a translation exists. It does not show whether the sentence is complete inside a narrow card, whether the same term changes between steps, or whether the recovery action matches the error.

Review Arabic copy in the rendered journey:

• navigation, buttons, tabs and menus;
• field labels, placeholders, help, validation and server errors;
• empty, loading, permission and offline states;
• confirmation dialogs and destructive actions;
• notifications, transactional emails and downloadable documents;
• image text, alt text, accessible names and tooltips;
• page titles, descriptions and social previews;
• legal, medical and consent wording in its final component.

R011 reports untranslated interactive labels such as buttons, links, menu items and tabs. R012 reports untranslated attribute text including placeholders, alt text, titles, accessible labels and button values. R071 reports untranslated form labels, validation or help text. These checks reveal missing translation coverage; a fluent reviewer must still approve meaning, tone and terminology.

Require a terminology list for high-stakes concepts. In the pharmacy example, “refill,” “substitution,” “active ingredient,” “coverage denied” and “pharmacist review” should not drift between screens. Record who approves a change and where it must be updated.

English fallback is not neutral. Decide which surfaces may show it, how the product labels intentional English content and which missing strings block release. A source-language medical instruction in an otherwise Arabic flow should not be accepted because the layout remains usable.

Check mixed-direction values by meaning#

Arabic interfaces contain values that should not be translated or mechanically reversed: emails, URLs, medicine codes, prescription references and customer-entered text. Their direction depends on what the value means, not merely the language of the page.

Ask QA to place realistic values next to Arabic labels and inside sentences, badges, dialogs and table cells. Test editing as well as display: move the caret, select a group, delete around punctuation, paste a value and copy it back.

A plain wrapper does not necessarily isolate a mixed-direction value. R021 reports unisolated bidi hazards such as phones, emails and Latin tokens inside Arabic text. Product managers do not need to choose the markup, but the acceptance rule should be clear: an immutable identifier must display in its authored group order and remain accurately copyable.

Do not classify every reordered range as a defect. A numeric range can appear reordered while remaining correct for Arabic reading order; an identifier with fixed groups is corrupted by the same visual change. The bidirectional text guide explains this distinction. The product decision is whether the value is language, a range or a machine identifier.

Phone, email and URL fields are another edge case. The surrounding form can be RTL while these values remain LTR. R070 reports tel, email or url inputs rendered RTL. Use the phone numbers in RTL interfaces guide when the journey includes phone entry and display.

Check layout at hostile widths and states#

An approved desktop screenshot says little about a validation message on a narrow device. Review every priority journey at the supported width extremes and at least one intermediate width where the layout changes.

For each named state, check:

• no document-level horizontal scroll appears;
• headings, labels, badges and actions do not overlap;
• long Arabic text wraps without hiding required content;
• sticky or fixed controls do not cover the active field or message;
• dialogs and menus stay inside the viewport;
• content at both ends of an intentional scroller remains reachable;
• loading, fallback-font and loaded-font states do not break the task;
• zoom or text enlargement does not remove access to an action.

R040 reports document-level horizontal overflow. R041 reports visible text-bearing elements that overlap. R042 reports clipped text when content exceeds a box with hidden overflow and no ellipsis. These findings are concrete release evidence, but a reviewer still decides whether an intentional inner scroller or truncation policy is acceptable.

Ask engineering to reproduce a layout defect with route, state, fixture and viewport. “Arabic text is broken” gives no usable boundary. “The insurance-rejection action is clipped at 390 pixels with the long denial fixture” can be assigned, fixed and retested.

Do not solve Arabic expansion by reducing type until the copy fits. Smaller text shifts the problem into readability. The component needs wrapping, flexible sizing, a revised hierarchy or approved truncation behavior.

Check directional design by purpose#

An RTL page is not a horizontally flipped screenshot. Some relationships follow reading direction, while other symbols represent physical objects or universal actions.

Review:

• back, next and previous controls in their actual sequence;
• progress indicators and timelines;
• carousels and pagination;
• arrows embedded in instructional copy;
• illustrations whose composition implies movement;
• media, clocks, charts, maps and brand marks that should stay fixed;
• asymmetric shadows, speech bubbles and anchored decorations.

Ask the designer to record the reason for each directional asset. Once the decision is explicit, engineering can automate the approved variant. R025 reports a directional icon pointing against the sequence its control advances. That check applies when the sequence is known; it cannot decide the intended meaning of an ambiguous symbol.

Avoid row-reverse as a blanket way to make a component look RTL. It can create a visual order that conflicts with DOM and keyboard order. R081 reports flex row-reverse used to fake RTL instead of document direction, where tab order fights visual order. The guide to what should be mirrored in RTL gives design and engineering a shared decision model.

Approve numbers, dates and market formats#

“Arabic numbers” is not a complete requirement. Markets, brands and document types can use different digit systems, calendars, currencies and fraction rules.

Write down the approved output for:

• prices, refunds, copayments and insurance coverage;
• dates, times, appointment windows and expiry dates;
• percentages, dosage units and quantities;
• decimal and grouping separators;
• prescription, account and confirmation identifiers;
• exported receipts, emails and PDFs;
• zero, one, two and larger quantity messages where plural wording changes.

Use fixtures with expected output rather than approving whatever the browser returns on one laptop. Formatter defaults can change with locale data and runtime updates. The market contract should determine the options and expected display.

R061 reports Arabic-Indic and Western digits mixed in the same context. A mixed result can be a defect even when each value is individually legible, because the product has failed to apply its approved convention consistently.

Check parity across channels. A confirmation page, email and PDF should not show different calendars or digit systems for the same refill. If a channel has a deliberate exception, document it in the contract rather than treating the inconsistency as an implementation detail.

Check forms as complete conversations#

A form is more than a set of labels. It includes instructions, entry, validation, server response, focus movement, correction and confirmation.

For every release-critical form:

• enter Arabic text into fields intended for names, addresses and notes;
• enter LTR values into email, URL, phone and code fields;
• test empty, malformed, duplicate and server-rejected input;
• confirm errors are associated with the correct field;
• verify focus moves somewhere useful after submission;
• correct the value and submit again without losing context;
• test select controls with Arabic options;
• use autofill where identity or contact data is expected;
• complete the flow with keyboard only;
• confirm values remain correct in the summary and receipt.

Do not approve a form from its empty state. An empty control can look aligned while typed content, a long validation message or the browser's built-in message uses a different direction or language.

The product manager should decide whether native browser validation is allowed. The page's Arabic language does not guarantee that every user's browser will present built-in validation in Arabic. Product-owned error text gives the team a reviewable message, but engineering must still implement focus and association correctly.

Check typography as functionality#

Arabic font choices affect character joining, line height, density and wrapping. A missing webfont can turn a layout review into a review of a fallback that customers were never meant to see.

Ask for evidence that:

• the approved Arabic webfont loads in the release environment;
• intended weights contain Arabic glyphs;
• fallback does not appear during or after loading in a way that breaks the task;
• body text remains readable at the supported sizes;
• line height leaves room for Arabic marks and multi-line labels;
• Latin display styles such as uppercase and tracking are not inherited by Arabic text;
• bold, emphasis, disabled and error states remain distinguishable.

R050 reports Arabic text falling back past the declared font family, whether measured, declared or caused by a webfont load failure. A screenshot alone can make fallback hard to identify. Ask engineering for the rendered font evidence as well as the image.

Typography defects can block release when they hide content or make instructions unreadable. Treating all font differences as visual polish understates their product impact.

Check keyboard and assistive technology#

Visual right-to-left order does not prove that focus or reading order follows the task. Include keyboard and assistive-technology evidence for critical journeys.

Review:

• skip links, page titles and heading order;
• focus order through headers, forms, dialogs and repeated cards;
• visible focus at both narrow and wide widths;
• focus placement after validation and route changes;
• accessible names for icon-only controls;
• live announcements for uploads, availability and status changes;
• language changes for intentional foreign-language text;
• spoken order of mixed Arabic and machine identifiers;
• escape and return-focus behavior for overlays.

Automated accessibility checks can verify attributes and relationships. A person must still listen to language switching and mixed content, and decide whether the announced wording makes sense.

Do not accept a focus sequence merely because every control is reachable. The order should follow the intended task. If visual order and DOM order disagree, record which one should change rather than adding positive tabindex values as a patch.

Set Arabic release blockers in advance#

Severity debates become inconsistent when they begin after the defect appears. Define release rules while the team is calm.

Every accepted risk needs an owner, affected journey, user impact, workaround, decision maker and target release. “Known issue” without those fields is not a release decision.

Avoid severity based on visual size. A small arrow can send the customer backward. A single untranslated word can be the consent action. Task impact and meaning determine severity.

Ask engineering for evidence, not reassurance#

Before sign-off, ask questions that can produce a route, fixture, assertion or recording:

• Which Arabic URLs are opened directly in automated tests?
• Where are lang and dir asserted after redirects and client navigation?
• Which fixtures cover mixed-direction identifiers and long Arabic content?
• Which failure and permission states are generated deterministically?
• At which viewports is document overflow measured?
• How does the suite confirm the approved Arabic font loaded?
• Which controls intentionally remain LTR, and where is that contract tested?
• How are visual baselines stabilized and who approved the first Arabic version?
• Which formatter options are explicit rather than inherited from the runtime?
• Which manual findings were converted into regression tests?

Answers such as “RTL is handled by the framework” or “the English tests pass” do not address the product contract. Ask for the relevant Arabic build and named state.

Engineering evidence also has limits. A passing assertion can prove that the approved Arabic string rendered. It cannot prove that the string communicates the right instruction. Keep the language owner in the sign-off.

Run the release review in a useful order#

Sequence the work so specialist time is not spent rediscovering deterministic defects.

1. Freeze the candidate, scope and fixture set.
2. Run build-time catalog and locale-route validation.
3. Run rendered Arabic checks for direction, untranslated content, bidi, layout, typography and forms.
4. Fix or triage deterministic failures.
5. Run journey tests across the supported viewport and browser matrix.
6. Give the same candidate and fixtures to Arabic, design and accessibility reviewers.
7. Re-run affected checks after every fix.
8. Record remaining risks and the final release decision.
9. Run a focused smoke pass after deployment for routing, assets and configuration.

Do not let review happen across changing builds with no version label. A translation approved on Monday and a layout approved on Wednesday are not a combined sign-off if the candidate changed between them.

The evidence pack should contain the build identifier, scope, fixtures, automated results, reviewed journeys, open defects, accepted risks and approvers. Keep it small enough to read and specific enough to reproduce.

Keep the checklist alive after launch#

Arabic QA debt returns when the checklist is treated as a launch document rather than a product routine.

After release:

• convert reproducible defects into fixtures or automated assertions;
• add newly discovered states to the journey map;
• review changes to shared components for Arabic impact;
• include Arabic when upgrading fonts, formatters, routers or design tokens;
• retest deep links and redirects after authentication changes;
• audit fallback content when adding new notification channels;
• keep terminology and market decisions versioned;
• review accepted risks at the promised release.

Product should also watch support reports and analytics for journey failures, without treating absence of reports as proof of quality. A customer may abandon a broken flow without explaining why. Use post-launch signals to choose new test states, not to replace release evidence.

Make the release decision traceable#

The product manager's job is not to declare that Arabic “looks good.” It is to show which journeys were covered, what rules were approved, who made the language and market judgments, which defects block release and what evidence supports the final decision.

A Ritla scan can supply repeatable rendered-page findings before specialist review, so the release record starts with concrete defects instead of a broad confidence statement. Use the Arabic product QA guide to turn this checklist into an ongoing ownership model across product, engineering, localization and QA.