We review a lot of Arabic forms. Most of them are built in tools designed for English and then “translated” with a language toggle and a dir=rtl flip. That mechanical approach gets you 80% of the way to a usable form and then misses the five things that actually hurt completion rate. Here’s what they are and how to fix them.
1. Mixing LTR and RTL in a single question
A phone-number field with a country prefix (+966) rendered inside an RTL container usually renders the prefix on the wrong side, or worse, in reverse order (966+ instead of +966). URL fields have the same problem.
Fix: wrap numeric and URL inputs in dir="ltr" even inside an RTL form. The label goes RTL, the input content goes LTR. Sahl/form does this automatically; in other tools you may need to override the CSS.
2. Western icon metaphors that don’t translate
A thumbs-up to indicate “approved,” an envelope for email, an arrow pointing right for “next” — these read fluently in English because they’re baked into the culture. In an RTL form, the next-arrow pointing right means “back,” not “forward.”
Fix: mirror all directional icons in RTL. For the rest, prefer icons that are directional-agnostic (a circled check, a bell) or drop the icon and rely on the label. The label you already translated.
3. Punctuation drift
Arabic uses specific punctuation: the comma is ،, the question mark ؟, the semicolon ؛. Most form builders type-check for Latin punctuation only. Respondents who type naturally in Arabic get “invalid input” errors on their own commas.
Fix: validators need to accept both Latin and Arabic punctuation as equivalent. If you’re regex-validating text, normalise first.
4. Auto-advance timing tuned for English reading speed
Conversational forms auto-advance after a short pause (commonly 300–400ms). Arabic readers parse a question in ~15% more time on average because of the higher character density and the script’s connective shapes. A 300ms delay works in English and flashes past too fast in Arabic.
Fix: set auto-advance to 500ms for Arabic forms. Sahl/form has this as a per-language default. Test it: if respondents say the form feels rushed, the delay is too short.
5. Hijri vs Gregorian date defaults
Date pickers default to Gregorian in almost every form builder. For many KSA forms — especially government, education, healthcare — Hijri is either the primary calendar or a parallel one the respondent expects to be able to choose.
Fix: offer a toggle between Hijri and Gregorian in the date picker. If the form is attached to a religious date (Ramadan bookings, Hajj registration), default to Hijri.
The quick audit
For any Arabic form you’re about to publish, spend five minutes testing these five things on a real mobile phone:
- Phone and URL fields display correctly.
- Next/back arrows point the right way.
- Arabic punctuation doesn’t fail validation.
- Auto-advance feels relaxed, not rushed.
- Hijri is at least available as an option where dates matter.
If all five pass, you’re already in the top 20% of Arabic forms online.