An Arabic order interface can look tidy until a long name, Latin reference and English note appear together. A bracket may shift or a number's ending become confusing. Reviewing colours and alignment alone will not show whether an employee can identify the correct order and complete the task.
Before accepting Arabic design, agree a session using defined data and tasks. Test Arabic and English in their own contexts, then test switching between them. The aim is to expose misreading, lost work and behaviour that depends on the designer's verbal explanation, rather than collect cosmetic comments.
Start with a concrete task card
In a fictional spare-parts portal, an employee searches for reference PART-208 for a customer named «المؤسسة العربية للتجهيزات الصناعية», adds a note containing an English product name and submits the order for review. Request the whole journey rather than a list screen disconnected from details and the form.
The card identifies role, starting data, steps and the result the user should understand. Preserve the expected reference rather than manually reversing its letters or numbers to fix appearance. Direction handling belongs in design and implementation, not in asking users to enter unnatural data.
Small cases that expose significant problems
| Test case | Buyer observation | Expected result |
|---|---|---|
| Long Arabic name beside a Latin reference | Brackets, punctuation, wrapping and reference identification. | Readable name and an unambiguous reference order. |
| Arabic and English in a note field | Typing, editing, copying and punctuation placement. | Users can enter and review text without changing its meaning. |
| Empty value or long error message | Association with the field and preservation of input. | Users understand the correction without redoing everything. |
| Order table on a phone | Headings, row association, scrolling or an alternative. | The required information and action remain reachable. |
| Back, next and language changes | Current task, form state and button labels. | Context follows agreed behaviour rather than disappearing unexpectedly. |
Use fictional names and phrases with representative lengths; keep real customer data out of public design files. Include empty states, Latin characters and numbers instead of repeating a short placeholder everywhere. Handover should explain component behaviour as content varies.
Connect direction with meaning
W3C distinguishes page direction from handling mixed inline passages. Ask the supplier to demonstrate intentional language and direction settings and a reference that does not disrupt adjacent content. You can describe the right outcome without selecting HTML implementation details yourself.
Review icons according to meaning: back navigation in a journey differs from a logo or media-play symbol. Avoid a blanket instruction to reverse every icon. Agree which change direction and which retain their visual meaning, then test the journey with a user rather than judging symbols alone.
Test keyboard use in the implemented version
Move from search to a result and an action form without a mouse. Observe visible focus, navigation order, dialog closure and return location. WCAG's focus-order criterion concerns preserving meaning and operability where sequence affects them. Users should not have to infer a hidden sequence from attractive positioning.
In the parts example, focus should not jump to another order's action without clear context. Record the start, obstacle and expected outcome. Passing this task alone does not establish full accessibility conformance; comprehensive evaluation needs its own scope and evidence.
What does the design file establish?
An interactive prototype supports review of labels, sequences and screen states. It may simulate input or transitions without real typing and does not automatically establish browser text direction, keyboard order or screen-reader announcements. Distinguish simulated cases from tests after development.
A design phase can be accepted with known implementation questions if agreed, followed by content and behaviour tests in the implemented product. Avoid accepting behaviour you could not test or deferring all Arabic issues until development ends as though they were word translation alone.
A review record that supports action
- Identify screen, role, language, viewport and test data.
- Record a reproducing step instead of a vague request to improve Arabic.
- Describe the affected meaning or task and expected outcome.
- Record the decision, owner and stage: design, implementation or content.
- Repeat the task after correction and attach evidence and test limits.
The UI/UX proposal deliverables guide covers the wider process; this worksheet focuses on Arabic acceptance. When requesting user experience and interface design from Nextwave, include tasks, sample content and languages so their testing is explicitly scoped.
References used
W3C guidance on structural direction, mixed inline text and focus order was opened on 3 November 2026. The original task cards and worksheet are neither a conformance certificate nor a completed user study. The article was prepared with AI assistance and review of the content and sources.