A practical review of Arabic mobile layouts, mixed text, forms, and language switching, with an acceptance checklist you can share with your designer.
An Arabic page can look convincing on a designer’s monitor while reversing a phone number or hiding a booking button on a customer’s phone. A useful responsive layout keeps the task understandable as space changes. Before approving the design, choose three real tasks: find a service, understand its conditions, and send an enquiry. Complete them in Arabic first, then in the other supported languages. Record specific obstacles instead of relying on an overall visual impression.
Start with direction and realistic content
W3C guidance on text direction recommends setting right-to-left direction on the document when that is its overall direction. Ask the developer to declare the page language too. Right-aligning headings alone does not establish the document’s reading direction.
Prepare a long Arabic name, an email address, an international phone number, a price with currency, and a Latin product name inside an Arabic sentence. Check brackets, hyphens, and address order. Avoid automatically mirroring logos, photographs, or media controls. Review what each icon means and agree which navigation symbols should change with direction.
Protect reading comfort as the screen narrows
Start with one column for the main content and sufficient space between paragraphs and controls. Test the actual Arabic font with long headings and any diacritics your content uses. Review each language independently: appropriate line spacing may differ across Arabic, Turkish, and English.
web.dev’s responsive design guidance connects layout changes to the available viewport. Drag the browser width gradually, because problems can occur between familiar device sizes. Enlarge text and check that cards expand without clipping their final line or covering an action button.
Test forms and language switching as complete journeys
- Enter a compound Arabic name and realistic contact details. Check that a validation error preserves valid entries.
- Leave a required field empty. Its message should explain what to fix near the relevant input.
- Open the phone keyboard and confirm you can still reach the current field and submit action.
- Switch languages from an internal service page and check that its equivalent opens when available.
- Use the keyboard to open and close mobile navigation, keeping the focused control visible.
Consider a maintenance company receiving an Arabic address containing a building number and Latin letter. If staff repeatedly ask customers to clarify it, that issue deserves attention. Compare the submitted value with what arrives in the administration screen or email. A correct-looking form does not prove that the complete journey preserves its data.
Write acceptance conditions someone can reproduce
Record the device, language, page, steps, and expected result for each defect. For example: enlarging text on the booking page leaves the service title, full error message, and submit action accessible. Agree the main browser and device coverage before handover, then repeat the journey after repairs. This practical review is not a complete accessibility certification.
Add language requirements to your project brief and plan equivalent pages with the multilingual website guide. Address long waits using the mobile performance checklist. Compare designs in the template store using identical sample content so the comparison remains meaningful.