Phone inputs in Arabic forms

A furniture-collection form asks for a callback number in Arabic. Its phone component forces every input RTL, so a pasted international number shows its digit groups in the wrong sequence and its plus sign at the far end. The submitted string may still be correct. The customer needs to read and edit the number before submitting it, not discover later that the screen and stored value told different stories.

Phone entry has several separate contracts: the field's direction, which country gives a national number meaning, accepted digit scripts, formatting during editing and the validation performed before saving. A correct LTR field can still reject Arabic-Indic digits or duplicate a country code supplied through autofill.

This guide follows the collection callback field through those decisions. The examples use +44 1632 960857, from Ofcom's reserved range for fictional numbers. It is a rendering and normalization fixture, not a reachable number or a fixture that every numbering-plan validator should accept.

Preserve the native telephone direction#

HTML gives telephone inputs an LTR default. The HTML directionality rules distinguish that behavior from ordinary text inputs. An Arabic page does not require overriding it.

An explicit attribute can undo the default:

Problem

<label for="collection-phone">رقم الهاتف لتنسيق الاستلام</label><input id="collection-phone" name="phone" type="tel" dir="rtl"       value="+44 1632 960857">

In the browser behavior supplied for this guide, the Western-digit groups in that RTL value appear as 960857 1632 44+. Spaces separate the groups, and the leading plus sign moves to the other end. This is a display failure for a telephone number whose group order must remain fixed.

Keep the phone value LTR

<div class="callback-field" lang="ar" dir="rtl">  <label for="collection-phone">رقم الهاتف لتنسيق الاستلام</label>  <input id="collection-phone" name="phone" type="tel" dir="ltr"         autocomplete="tel" required aria-describedby="collection-phone-help"         value="+44 1632 960857">  <p id="collection-phone-help">أدخل رقماً يمكن لفريق الاستلام الاتصال بك عليه.</p></div>

These are alternative versions of the same field. The populated fixture is for demonstration; a production form should populate the customer's own value or start empty. Keep the Arabic label and help outside the LTR value boundary.

The measured rendering behavior comes from Chromium 151 on September 24, 2026. Firefox and Safari were not included. Inspect the actual control's computed direction in supported browsers, especially when a custom component or author CSS can contradict its markup.

Use a telephone control without treating it as a validator#

Use type="tel" for a phone number. Do not choose type="number" because the value contains digits. A phone is an identifier with meaningful prefixes, not a quantity to increment or parse as an integer.

The MDN telephone-input reference explains that the type does not impose one universal phone format. required can establish that an answer is needed, but it does not establish that the answer belongs to a valid numbering range or can receive the callback.

Telephone entry can also give mobile users a more suitable keyboard. inputmode is a keyboard hint, not a country parser, digit converter or direction declaration. Test the real keyboard rather than assuming an attribute guarantees every symbol the form accepts.

Right alignment is separate. If the design deliberately right-aligns the number, keep LTR direction and test the editing experience. Otherwise text-align: start gives this LTR control a left starting edge. MDN documents logical alignment.

An Arabic placeholder is not a reason to turn the value RTL. Put the Arabic instruction in visible help when it conflicts with the presentation of a machine-format example.

Choose one model for country information#

Decide whether the field accepts a complete international number or a national number paired with a region selector. Both can serve an Arabic interface, but they must not leave the customer guessing which part to enter.

For a single international field, explain that the country calling code belongs in the number. For a split design, label the region selector and explain whether the number field expects the domestic form, including any national prefix accepted by the parser.

Interface language is not that context. Choosing Arabic does not establish which country's number the customer owns. Delivery address and phone region can differ too. A default based on a service market should remain visible and changeable where international contacts are supported.

Treat a region identifier and a calling code as different data. Some calling codes serve more than one region, so a parser's region option should not be an arbitrary code string relabelled as a country.

Define what happens when an international number is pasted while another region is selected. Parse the explicit prefix and reconcile the selection, or explain the conflict. Do not quietly prepend the selected calling code to a value that already contains one.

Keep the country selector and number understandable together#

A split component can remain an RTL group while its number entry stays LTR. Give the group a purpose and each control its own label. W3C's grouping guidance describes fieldsets and legends for related controls.

Use Arabic country or region names that customers can recognize. Keep the parser's stable region values separate from translated labels. A flag alone does not explain the selection, and the calling code alone may not identify the intended region.

Check the collapsed selector, expanded options, keyboard navigation and focus order. If a custom searchable selector replaces the native control, test its search field and announcements too. Applying RTL to its wrapper does not implement its selection behavior.

Choose the visual arrangement from the relationship between the controls. An RTL row's starting edge and an LTR phone value's starting edge are different. Avoid reversing the DOM merely to put a selector beside the desired physical edge; preserve an understandable keyboard sequence.

Changing the selected region can change how a national value is interpreted. Preserve the entered text while rechecking it, and show the resulting interpretation before submission. Do not present the same digits as the same destination after silently changing their country context.

Accept digit scripts before applying phone rules#

An Arabic keyboard can supply Arabic-Indic digits. If the service promises to accept them, perform that conversion before an ASCII-only parser or regular expression rejects or removes them.

JavaScript's \d matches ASCII digits. Consequently, value.replace(/\D/g, "") is not a digit-normalization function: it discards Arabic-Indic digits, and also removes the international plus sign. MDN's character-class escape reference documents those classes.

For this callback form, suppose the accepted scripts are Western, Arabic-Indic and Eastern Arabic-Indic digits. This helper maps the latter two to ASCII without deleting other characters:

function normalizePhoneDigits(value) {  return value.replace(/[\u0660-\u0669\u06F0-\u06F9]/g, character => {    const code = character.charCodeAt(0);    const zero = code >= 0x06F0 ? 0x06F0 : 0x0660;    return String(code - zero);  });}

Pass a string, such as the input's current value. Applied to +٤٤ ١٦٣٢ ٩٦٠٨٥٧, it produces +44 1632 960857. It preserves spaces, the plus sign and any unexpected characters for the next stage to handle deliberately. It does not validate a phone number, remove a national prefix or convert a domestic number into an international one.

Use the same accepted-script policy on the server. Otherwise a value can pass the client and fail after submission, or an alternative submission path can bypass the promised normalization.

Do not let native constraints reject promised input first#

An ASCII-only HTML pattern can prevent the normalization path from running. For example, pattern="[0-9+ ]+" excludes Arabic-Indic digits even when the application intends to convert them later. It is also not a complete phone validator: it permits plus signs wherever they occur.

Check when normalization happens. Native constraint validation can block submission before the form's submit event, as MDN's submit-event reference explains. A conversion helper called only inside that event handler cannot rescue a value already rejected by the browser's pattern check.

For this field, avoid a conflicting raw-input pattern and validate the normalized interpretation through the application's phone rules. Alternatively, design compatible raw constraints and an earlier conversion path, then test both together. Removing one unsuitable pattern does not require disabling native validation for the entire form.

Review length limits too. A displayed international number can include a plus sign and formatting separators that are absent from the canonical representation. Do not copy the saved representation's digit limit directly into a maxlength attribute without accounting for the editing string. MDN describes maxlength as a constraint on the control's text length.

Do not confuse digit conversion with bidi repair#

Setting LTR does not change Arabic-Indic characters into Western digits. Direction and digit script are independent, and the visual behavior of spaced Arabic-Indic groups needs particular care.

In the supplied browser measurements, spaces between Arabic-Indic digit groups resolved RTL even inside an LTR boundary. Do not promise that adding dir="ltr" alone preserves the visible group sequence for every script and spacing pattern.

Test both the original Arabic-Indic entry and the normalized ASCII representation. For a product that accepts several scripts but displays formatted phone values using Western digits, make that display policy deliberate and explain it through the resulting field behavior. Do not claim that the page's Arabic locale automatically selects the right representation.

Choose when the editing string changes. Converting a value for parsing need not rewrite the field on every keystroke. A normalized display after a committed edit can avoid some live-formatting work, but users still need a readable value while entering it. Test that interval instead of only the final formatted result.

If a product must preserve Arabic-Indic display throughout entry, test its specific control and formatting strategy across supported browsers. A general bidi override is not a substitute for designing and verifying that editor.

Separate entry, parsing and saved representation#

Keep track of what each stage means:

Do not parse the phone as a JavaScript number. That loses the distinction between text and quantity and can discard leading zeroes that were part of the national input. Let a numbering-plan parser decide which prefixes are meaningful.

Where the backend expects an international E.164 representation, obtain it from the parsed result rather than concatenating a selected code and a stripped string. ITU's E.164 recommendation defines the international numbering plan; it is not an instruction to remove every leading zero from every country's input.

Keep an extension separate if the callback workflow supports one. Do not append extension digits to the saved subscriber number as though they formed one destination. If extensions are unsupported, explain that constraint instead of silently discarding them.

Inspect the submitted payload and reopen the saved contact. The value used by the callback service should agree with the number the customer reviewed, even when the display includes spaces that the canonical representation omits.

Format during typing only if editing still works#

An as-you-type formatter must handle incomplete numbers, not only produce a spaced string from a finished value. Use a numbering-aware formatter rather than a fixed grouping mask for all supported regions. Google's libphonenumber project documents an as-you-type formatter alongside parsing and formatting facilities.

Test typing from the beginning, inserting a digit in the middle, replacing a selection and deleting beside a separator. A formatter that pushes the caret to the end after each change makes correction harder even when its final string looks right.

If code restores the selection, map the old selection to the transformed value. Reusing an old character offset after adding or removing separators may select a different part of the number. setSelectionRange() supports telephone inputs, but the API does not calculate that mapping for the component.

Include keyboard composition and suggestions. compositionend identifies the completion or cancellation of a composition session. Do not assume that every Arabic keyboard produces the same sequence of events or that rewriting the value during composition is harmless.

Formatting on blur or after an explicit confirmation can be a simpler choice when live formatting does not preserve editing. Keep the uncommitted string available until the application can explain any rejected interpretation.

Make paste and autofill follow the same contract#

Keep paste available. Customers may copy numbers containing spaces, parentheses or a complete international prefix. Define how the parser treats those forms and test the resulting interpretation, rather than making manual typing the only path that works.

For a single complete phone field, use autocomplete="tel", as in the callback example. For genuinely split components, the appropriate tokens can include tel-country-code and tel-national. MDN defines the telephone autocomplete tokens.

Use the token that matches the value requested. A full-number token on a field that expects only a national part can produce a prefix the component later prepends again. A country-region selector is not automatically a calling-code input merely because the two are adjacent.

Autofill, saved-contact selection and programmatic restoration need the same parsing policy as typing. Do not base correctness on one key event handler having run. Inspect the current value and region after population, then inspect what would be submitted.

Clear the field and populate it again with a different region's number. Check that old masks, prefixes and error messages do not survive into the new value. Test browser Back and a server-rejected form too, because either can restore a partially completed contact component.

Validate format, service policy and reachability separately#

A phone parser can distinguish some numbering-plan failures without proving that a person can answer the number. Google's libphonenumber FAQ explicitly separates numbering-range validity from assignment and reachability.

Keep these questions separate in the form:

A voice callback does not automatically require a mobile-only number. If the product actually requires SMS delivery, state that requirement and test that flow instead of relabelling every failure as an invalid phone number.

Do not reject a number solely because its region differs from the customer's address or interface language. Apply any destination restrictions as explicit service rules. Keep parser metadata maintained, and record the version when diagnosing a number newly accepted by one environment but rejected by another.

The fictional number in this guide is suitable for display and conversion tests. Use separate documented parser fixtures and controlled delivery tests for the acceptance and contact paths. A successful normalization assertion is not evidence of a successful call.

Compare client and server interpretations#

A client and server can both accept a national number while interpreting it differently. The client may use the region selected by the customer, while the server falls back to the service's market. A green field and a successful response would then conceal a changed destination.

Carry the context required by the chosen entry model through the request. Let the server parse and validate under the same documented policy, and compare the resulting destination with what the interface presented for confirmation. Do not treat a hidden client-generated canonical field as a substitute for server validation.

Use shared fixtures that cover both accepted digit scripts, national prefixes, explicit international prefixes and conflicting region selections. Compare interpreted destinations, not just whether both implementations returned success. Record any deliberate difference in supported regions or number types.

When the server corrects or rejects an interpretation, return enough structured information to show Arabic feedback beside the number and region selector. Preserve the customer's editing string until the correction path is clear. Replacing it silently with a different destination is not a formatting improvement.

Give Arabic errors a correction path#

Distinguish a missing answer, a missing region, an unparseable number and a destination the callback service does not support. Those are different problems and can require changing different controls.

For a missing region, a message such as اختر بلد رقم الهاتف لتفسيره بالصيغة المحلية. explains why the selector matters. For unsupported destinations, لا تتوفر خدمة الاتصال بهذا البلد. أدخل رقماً من بلد تدعمه الخدمة. describes a service limit rather than claiming the number cannot exist.

Do not show an incomplete number as invalid before the customer has had a chance to finish it. Once an error is displayed, update it when the relevant number or region changes. Preserve the entered string so the customer can correct it instead of starting again.

Associate feedback with the affected control and include the country selector when its context is needed. W3C's notification guidance covers field feedback and correction instructions. A combined component should not leave an error attached only to an outer decorative box.

Translate server-originated errors too. A parser exception or telephony-provider message should not appear as an unexplained English sentence inside the Arabic form. Map known conditions to reviewed Arabic messages, and keep temporary provider failures distinct from errors in the customer's number.

Verify the number outside the input too#

After submission, the callback number can appear inside an Arabic request summary. The input's LTR declaration does not travel with its string into that paragraph:

<p lang="ar" dir="rtl">  رقم الاتصال لتنسيق الاستلام:  <bdi dir="ltr">+44 1632 960857</bdi></p>

Keep the number in its own boundary. Do not include the Arabic label inside the same automatic boundary and expect the label to leave the value's direction unaffected. For the rendering details, use phone numbers in RTL interfaces.

Inspect the visible number, then copy it and compare its logical content with the saved destination. These are separate checks: copying can return the intended order even when a display has reordered its groups.

Test the edit action from that summary. The reopened input should recover the destination and region context without adding a second prefix or resetting the phone to RTL. A readable confirmation is not enough if returning to correct one digit changes the interpreted contact.

Test the complete callback field#

Build a fixture set around the supported entry models and scripts. Use the reserved example for visual behavior and digit conversion; keep validity and delivery fixtures separate.

Run mobile tests with the keyboards customers use. Inspect the DOM direction, visible number, editing behavior and request payload as different evidence. One passing screenshot or server assertion cannot establish all of them.

A free Ritla scan can report R070: tel/email/url inputs rendered RTL (these must stay LTR), and R073: Identity fields missing autocomplete tokens. Digit conversion, parser policy and correction behavior need the field tests above; continue with phone numbers in RTL interfaces for display outside controls or RTL elements overlapping on mobile when the country selector and feedback compete for space.