Arabic Form Design: How to Build Forms UAE Users Actually Complete

Designing forms for Arabic users in the UAE comes down to a handful of rules. Use one full-name field instead of first/last — Arabic names chain a father's and grandfather's names, and split fields force users to guess. Keep phone inputs left-to-right, accept every +971 format, and normalise before validating. Never require a ZIP code — the UAE has no postal codes; ask for emirate, area, building and flat, with PO Box and Makani optional. Default to Gregorian dates, put labels on the reading-start side, write every error in Arabic and English, and set inputmode so keyboards match each field.

Most forms were built on Western conventions and translated, not localised — which is why they break in the UAE. The field-by-field rules below are what our UI/UX design team in Dubai applies when building bilingual forms for the Emirates.

Why do "first name / last name" fields fail Arabic users?

Arabic naming does not follow the Western given-name/surname structure. A name can chain the given name with "ibn" (son of), the father's name, the grandfather's name and a tribal or family name — "Mohammed bin Rashid Al Maktoum" is a complete name with no clean "first/last" split. That's why users hesitate when your form asks which part is the "last name": the father's, the grandfather's, or the family's.

The fix, recommended by the W3C and confirmed by MENA usability research: stop splitting entirely.

• Use one "Full name" field — more inclusive for Arab users with multi-component names, and it removes the guessing game.
• Make it long enough: a maxlength of 100+ costs nothing and fits chained names.
• Never auto-split it. If your backend needs separate parts, split server-side with clear rules — or ask for them in a second, optional step.
• Set autocomplete="name", dir="auto" (correct rendering for Arabic or Latin input) and inputmode="text".
• UAE PASS, the UAE's digital identity, returns names in English and Arabic — prefill both when integrated.

If your form needs to address the user ("Dear …"), take the first token of the full name rather than inventing a "first name" field.

How should phone inputs handle UAE numbers?

UAE mobile numbers are nine digits after +971, starting with 5 — or ten digits with a leading 0 locally (050 123 4567). Common prefixes: 50, 52, 54, 55, 56, 58. Store in E.164 format — start with +971, no leading zero after it (+971548001234 is right; +971 0548001234 is wrong, per a UAE health-authority data standard).

1. Keep the field left-to-right in both languages: type="tel", dir="ltr", inputmode="tel". The same LTR treatment applies to emails, OTP codes and order numbers — isolate mixed content with <bdi> or dir="auto".
2. Accept every format users type — +971 50 123 4567, 971501234567, 0501234567, with spaces and dashes — then normalise: strip non-digits, convert Arabic-Indic (٠١٢٣) and Persian digits to 0–9, drop the trunk 0 after the country code, and validate (mobiles: nine digits starting with 5).
3. Validate with a maintained library, not a hand-rolled regex. Numbering rules change; libraries track them.
4. Store E.164 (+971501234567) without spaces or dashes so click-to-call, WhatsApp and SMS work.
5. Show a format hint ("+971 50 123 4567") under the label — it teaches more than a rejection message.

What address fields should a UAE form include?

The UAE has no postal codes — mail is delivered to PO Boxes — so never require a ZIP or postal code. Where a third-party system forces one, 00000 is the widely used placeholder; delivery still depends on the building, area and phone number.

• Emirate — dropdown with the seven emirates (Abu Dhabi, Dubai, Sharjah, Ajman, Ras Al Khaimah, Fujairah, Umm Al Quwain).
• Area / Community — free text (Marina, Al Barsha 1); dir="auto" for mixed Arabic/English.
• Building / Villa name or number — free text.
• Apartment / Flat — optional free text.
• PO Box — optional; needed only for actual mail.
• Makani number — optional 10-digit geo-identifier for buildings (findable via the Makani app or the building plaque), used for navigation rather than mail; validate digits only.
• Delivery instructions / landmark — optional free text; landmark-based addressing ("behind Mall of the Emirates") is still common.
• Map pin — a strong alternative to typed addresses for delivery and service apps.

Set inputmode="numeric" on Makani and PO Box fields, and use autocomplete tokens (address-level1, street-address) where they map sensibly.

Where do labels, placeholders and error messages go in RTL?

An Arabic page sets dir="rtl" (with lang="ar") on the html element, and the form follows: labels align to the reading-start side — the right in Arabic — while inputs take direction from their expected content.

• Labels stay visible and sit on the start side. Use real <label> elements — screen readers and autofill depend on the association.
• Placeholders are never the only instruction: they vanish when the user types, they're hard to read in Arabic script at small sizes, and they fail accessibility checks. Keep the label; use the placeholder for a format example.
• Errors appear inline, on the start side, associated with the field (aria-describedby) and announced with role="alert".
• Every error exists in both languages: Arabic and English strings for every message — never the browser's default English strings. Suppress native bubbles and render your own.
• Be plain and specific: "Enter a valid mobile number, e.g. +971 50 123 4567" / "أدخل رقم هاتف متحرك صالحًا، مثال: +971 50 123 4567".

The primary action button sits where the reading order ends — mirrored from the English layout. Test tab order with a keyboard: focus must follow the visual order, which dir handles automatically but flex-direction: row-reverse breaks.

Which input attributes make Arabic forms accessible?

Users switch between Arabic and English keyboards mid-form, so every field must declare what it expects:

• Autofill tokens (name, tel, email, address tokens) power browser autofill — which matters on mobile where typing Arabic on small keyboards is slow.
• Digits: in the UAE, Western digits (0–9) are the default even inside Arabic text. Pin the choice in code (ar-AE-u-nu-latn) and normalise Arabic-Indic and Persian digits to 0–9 before validation.
• Invisible text is translated too: aria-labels, hidden labels and alt text exist in both languages, and labels describe meaning, not direction — "Next", never "right arrow".

That's what separates a translated form from a localised one — the same directional discipline that bilingual Arabic and English websites need throughout.

Should date fields use the Gregorian or Hijri calendar?

The UAE runs on the Gregorian calendar for civil dates, so default to Gregorian:

• Show Hijri only where it matters (religious dates, Ramadan, official announcements); everywhere else, Gregorian.
• Never compute Hijri dates algorithmically: conversion algorithms disagree by up to two days, and UAE Islamic holidays follow moon sighting. Publish dates from the official announcement instead.
• Use the right locale: ar-AE writes October as أكتوبر; generic Arabic locales can render different month names (ar-SY uses تشرين الأول).

Prefer native date inputs (type="date"): the browser localises the picker, so you avoid building a widget that gets any of this wrong.

Field-by-field checklist

Forms do not sit in isolation: the same mirroring decisions run across the whole page, from navigation to checkout. Our Arabic RTL website checklist covers the wider layout checks that keep an Arabic interface consistent beyond the form fields.

Frequently asked questions

Should I split Arabic names into first and last name fields?

No. Use a single "Full name" field. Arabic names can include a given name, "ibn" (son of), the father's and grandfather's names and a family or tribal name, so split fields force users to guess which part goes where. The W3C recommends one full-name field, long enough for long names, with dir="auto" so Arabic or Latin input renders correctly.

What is the correct format for UAE phone numbers in forms?

UAE mobile numbers are nine digits after +971, starting with 5 (for example, +971 50 123 4567), or ten digits with a leading 0 locally (050 123 4567). Accept every format users type, normalise to digits, convert any Arabic-Indic digits, drop the trunk 0 after the country code, then validate — and store in E.164 format with no leading zero after +971.

Do I need a ZIP or postal code field for UAE addresses?

No. The UAE has no postal codes and mail is delivered to PO Boxes. Never make a postcode field required. Ask for emirate, area, building and flat instead, and keep PO Box and Makani number optional. If a third-party system forces a code, 00000 is the widely used placeholder — delivery still depends on the address details and phone number.

What is a Makani number, and should my form collect it?

A Makani number is a 10-digit geo-identifier assigned to buildings, used for navigation and deliveries rather than mail. Collecting it is optional but useful for delivery and service businesses in Dubai and the other emirates that use it. If you do, validate digits only, cap the field at 10 characters, and never make it required — most users won't know theirs.

Should error messages be in Arabic or English?

Both. Every validation message should exist as a bilingual pair — Arabic and English — and appear inline next to the field on the reading-start side. Never show the browser's default English validation strings on an Arabic form; suppress them and render your own messages that say what's wrong and show an example of the correct format.

Conclusion

Arabic form design in the UAE isn't about translating labels — it's about matching the data model to the country: one name field, LTR phone inputs, emirates and Makani instead of postcodes, Gregorian dates with the right locale, bilingual errors. Get the fields right and the form stops quietly rejecting your best users.

If you're building or rebuilding a bilingual product for the Emirates, talk to a web design company in Dubai that ships Arabic-first: the form patterns above, plus the multilingual website architecture they sit inside, are exactly what our team implements. Get a fixed-price quote and launch with forms your users can actually complete.