RTL forms: the complete guide

An equipment-repair form has Arabic labels, yet its fault description starts from the wrong edge. A shared input style forces everything LTR. Removing that style fixes the description but leaves the email field inheriting RTL from the form. The two fields need different text directions inside the same Arabic layout.

Treat form direction, field content and interaction order as separate contracts. The interface can read right to left while an email address or asset code reads left to right. Validation must explain errors in Arabic, and the user must be able to correct them without losing the entered values or the intended field order.

This guide follows a repair request through description, equipment reference, contact details, choices and submission. Its examples are field fragments for that workflow, not a reason to apply one direction rule to every input in a component library.

Establish the Arabic form's direction in markup#

Set the Arabic document's language and direction independently:

<html lang="ar" dir="rtl">

A form embedded in a differently directed document can declare its own lang="ar" and dir="rtl". Labels, help text and ordinary Arabic controls then have the appropriate inherited context.

lang="ar" does not set direction. CSS direction: rtl can change rendering, but it is not interchangeable with the HTML direction declaration for every feature, including the :dir() selector. Put the content direction in markup before adjusting layout styles. MDN documents the dir attribute.

The browser behavior discussed here was measured in Chromium 151 on September 24, 2026. Firefox and Safari were not included in those measurements. Native controls and keyboard interaction still need testing in the browsers and operating systems your product supports.

Inspect inherited styles when the form remains wrong. A shared input rule can override the intended direction even when the document is correctly declared. Fix the rule's scope rather than adding increasingly broad RTL overrides around individual pages.

Choose direction from the field's content contract#

Build a direction policy before styling the repair form:

This is more precise than “all inputs on the Arabic route are RTL.” An email label and its editable value have different roles. Likewise, a multilingual note is not the same contract as a field whose instructions explicitly request Arabic prose.

In the measured behavior, email, URL, search, text, password and number inputs inherit direction unless it is declared otherwise. Telephone inputs default to LTR. Do not extrapolate that telephone default to email or URL controls; declare their known direction explicitly.

Input type, direction, keyboard hint and autocomplete also solve different problems. type="email" provides email-related behavior, while dir="ltr" describes text direction. inputmode hints at an input mechanism; it does not validate the field or establish its direction.

For codes, define the accepted character format. A serial-like identifier is text even when it contains many digits. Numeric inputs can be inappropriate where leading zeroes or separators are significant.

Let Arabic prose use its own reading direction#

A form-wide LTR input rule is too broad for the repair description:

Problem

<label for="fault-description">وصف العطل</label><textarea id="fault-description" name="description" dir="ltr"></textarea>

The declaration gives an Arabic prose field an LTR base direction. Right-aligning its text would change alignment without correcting that contract.

Arabic description field

<label for="fault-description">وصف العطل</label><textarea id="fault-description" name="description" dir="rtl"          aria-describedby="description-help"></textarea><p id="description-help">اشرح العطل والخطوات التي سبقت ظهوره.</p>

Test typing a complete sentence, including punctuation, then editing its beginning and middle. A field that looks acceptable while empty may still have the wrong text direction once content appears.

Do not reverse the entered string or insert directional marks into the stored description to compensate for the control. Keep content and display direction separate. If the same description appears later in a request summary, render it under a direction policy appropriate to that content.

For a field intended to accept either language, automatic direction can be appropriate instead. Make that choice from the field's purpose rather than guessing from whether the first test user happened to type Arabic.

Keep email and other machine-format values LTR#

An Arabic parent does not make an email address an Arabic text field:

Inherited direction

<div lang="ar" dir="rtl">  <label for="update-email">البريد الإلكتروني للتحديثات</label>  <input id="update-email" name="email" type="email"></div>

The email input inherits RTL in the measured behavior. Give the value its own direction while retaining Arabic labels and feedback:

<div lang="ar" dir="rtl">  <label for="update-email">البريد الإلكتروني للتحديثات (مطلوب)</label>  <input id="update-email" name="email" type="email" dir="ltr"         autocomplete="email" spellcheck="false" required         aria-describedby="email-help email-error">  <p id="email-help">سنرسل تحديثات الإصلاح إلى هذا العنوان.</p>  <p id="email-error"></p></div>

These are alternative versions of the same field. Use the second version inside the actual repair form; do not duplicate its IDs. Test an address such as maintenance@bayworks.example by typing, pasting and editing it.

Apply the same value-level approach to a known-format equipment reference such as 845930-PUMP. The label stays Arabic; the control containing the reference declares LTR. Do not change the identifier's stored order or translate its letter segment.

Keep that declaration on the control. Moving dir="ltr" onto the entire field wrapper also changes the inherited direction of its Arabic label, help and error paragraphs. A reusable field component should allow the input's direction to differ from its surrounding text. Inspect the rendered input when a component accepts a direction property: a property attached only to an outer wrapper may affect more content than intended.

For phone-specific formatting and grouping, continue with phone numbers in RTL interfaces. The form-level requirement is explicit field direction, not a new phone-formatting algorithm.

Labels and placeholders should not compete#

Keep a persistent Arabic label associated with each control through for and id, or another supported labelling structure. A placeholder disappears during entry and cannot carry the field's identity or all its instructions. W3C's form-labelling guidance explains these relationships.

Use help text for format requirements, optionality and what the service needs. Connect that help to the control with aria-describedby where appropriate. Required status should be explained in the interface, not left to an unexplained decorative symbol.

For a known LTR field, prefer keeping the Arabic explanation outside the value area rather than forcing an Arabic placeholder into a different directional contract. An example placeholder can illustrate syntax, but it does not validate that syntax.

For an automatic-direction field, the measured empty state is LTR. An Arabic placeholder can therefore appear at the left edge until entered text establishes another direction. Do not interpret that empty appearance alone as proof of a broken Arabic input.

Check empty, focused, filled, invalid and restored states. Floating labels, optional instructions and error text can appear in different combinations. Their availability and association matter as much as their physical alignment.

Automatic direction needs editing tests#

The technician's note may contain either Arabic or English:

<label for="technician-note">ملاحظة إضافية للفني</label><textarea id="technician-note" name="note" dir="auto"></textarea>

Automatic direction uses strong directional characters in the entered text. Leading punctuation or digits alone do not identify the text's language. Test an Arabic note, an English note and a note that begins with an equipment name before continuing in Arabic.

Edit the first strong character, delete the content and paste a replacement in the other language. Watch the selection and caret as well as the resulting text. Avoid resetting direction from the current interface locale on every input event; that would fight the field's chosen automatic behavior.

If the application intentionally preserves an entered direction choice, HTML's dirname attribute can submit direction information alongside supported controls. That metadata is distinct from the submitted text and is not a language tag. Validate any stored direction value under the application's content policy before using it later.

Do not treat automatic direction as a fix for every machine-format field. A known LTR email or code has a defined contract and benefits from an explicit declaration. For more complex notes and previews, see how to handle dynamic text direction.

Keep alignment separate from text direction#

Use alignment to position content within its box and direction to describe its reading context. A right-aligned email can still be LTR; a right-aligned Arabic field can still have an incorrect LTR base direction.

A shared style using text-align: start follows each control's direction:

.repair-form input,.repair-form textarea,.repair-form select {  text-align: start;  max-inline-size: 100%;  box-sizing: border-box;}

Apply the class to the repair form. Arabic controls and explicitly LTR controls can then use different start edges under the same alignment rule. MDN documents logical alignment values.

Do not use padding, transforms or inserted spaces to simulate the desired start edge. Inspect the control's computed direction and alignment separately when a screenshot seems wrong. Text-align start versus right covers that distinction in more depth.

Test selects as controls, not just translated strings#

The repair priority uses Arabic options:

<label for="repair-priority">أولوية الطلب</label><select id="repair-priority" name="priority" dir="rtl">  <option value="routine">اعتيادية</option>  <option value="urgent">عاجلة</option></select>

Keep the visible labels Arabic while stable option values remain machine identifiers. Selecting an Arabic label should not require changing the API's enum spelling.

Check the collapsed control, expanded choice UI, keyboard navigation and selected value after a server response. Native presentation varies by browser and operating system; translating the option text does not establish how the expanded menu behaves. MDN's select reference describes the native control.

R072 reports <select> rendered LTR with Arabic options. Its description does not establish the expanded menu's placement or keyboard behavior, so test those interactions separately.

If a custom select replaces the native control, its focus, selection and accessible state need their own verification. Do not assume that applying RTL to its outer container supplies those interactions.

Group related choices without reversing their meaning#

A repair request can ask where the work should happen. Use a group label and associated option labels:

<fieldset dir="rtl">  <legend>مكان تنفيذ الإصلاح</legend>  <label><input type="radio" name="repairLocation" value="onsite"> في الموقع</label>  <label><input type="radio" name="repairLocation" value="workshop"> في الورشة</label></fieldset>

The shared name defines one selection group. The legend explains the question, while each label identifies a choice. W3C's guidance on grouping controls covers this structure.

Test clicking the whole label, moving through the group with the keyboard and restoring the chosen value after validation fails. A layout that appears mirrored can still submit the wrong option if labels and controls were associated incorrectly.

For checkboxes, state what checking the box means in Arabic. Do not use a visual switch's left or right position as the only explanation. Its checked state and label should remain understandable independently of the interface direction.

Keep machine values stable when translating labels. An Arabic route should not silently change the meaning of an existing saved preference.

Handle conditional and locked fields deliberately#

Choosing an on-site repair may reveal an Arabic access-instructions field. That new field needs the same direction, label and help relationships as fields present on initial load. Check the rendered state after changing the selection; inspecting only the initial markup misses conditional components.

Decide what happens to those instructions when the user switches to workshop repair. Retaining a draft for a possible switch back can help, but that does not mean irrelevant access instructions belong in the submitted request. Make the active choice determine which data the server accepts.

Visibility, editability and submission are separate decisions. A disabled control does not participate in native constraint validation or native form submission. MDN explains the disabled attribute. If application code builds its own payload from stored state, define equivalent inclusion rules there rather than assuming the DOM's disabled state filters that payload.

After an equipment lookup, a text input may become read-only while its reference remains part of the request. A supported read-only control remains focusable and is submitted, unlike a disabled control. MDN documents readonly. Neither state replaces the field's direction policy: a locked equipment reference still needs its LTR value context.

Test selecting each repair location, entering instructions, switching away and switching back. Then inspect the submitted data and any validation errors. A hidden inactive branch should not leave the user facing an error with no visible correction path.

Preserve DOM order while adapting layout#

Write controls in the sequence the user should complete them. Let RTL layout establish the appropriate inline starting edge. Do not reverse a row again through its flex direction, or assign positive tabindex values to repair a visually rearranged form.

Test the actual Tab sequence, including help buttons, custom selectors and submit actions. A two-column desktop arrangement and a one-column mobile arrangement should still follow a coherent task sequence. CSS positioning can make a screenshot look correct while keyboard focus follows a different path.

Keep labels, help and errors near the control they describe in the document structure. When an error expands, the next field should move rather than sit underneath absolutely positioned text.

For a field with an adjacent lookup action, decide whether the action belongs to the RTL field row or the LTR value area. Those boxes have different inline start and end edges. Place and space the action relative to the box whose meaning it follows, then test both language routes. CSS logical properties covers the layout primitives.

Icons need a meaning and a layout owner#

Do not mirror every form icon. A navigation arrow may express a sequence; an attachment symbol or status mark generally has a different role. Choose orientation from the action's meaning and verify any directional instruction against the interface's progression.

Avoid placing an icon over editable text without reserving space for it. In an RTL wrapper containing an LTR input, the wrapper's inline end is not the input's inline end. Decide which edge the design intends before selecting a logical inset or padding property.

An adjacent button can be clearer than an overlaid icon when it performs a distinct action such as looking up an equipment reference. Give that button an Arabic accessible name and an explicit type="button" so it does not accidentally submit the form.

Test the longest entered value, focus indicators and narrow widths. An icon that never overlaps an empty placeholder can still cover the end of an email address or equipment code. If the problem requires detailed positioning work, use absolute positioning in RTL layouts.

Translate validation and clear stale errors#

Declaring the page Arabic does not guarantee Arabic native validation messages. In the measured Chromium setup, an English browser still showed its English required-field message on a page with lang="ar".

For application-controlled Arabic feedback, localize the messages and associate them with their fields. This example extends the improved email fragment above. Run it after that markup, inside a form that retains native constraint validation:

const updateEmail = document.getElementById("update-email");const emailError = document.getElementById("email-error");if (!updateEmail || !emailError) throw new Error("Email field is missing"); function syncEmailError() {  updateEmail.setCustomValidity("");  const message = updateEmail.validity.valueMissing    ? "أدخل البريد الإلكتروني للتحديثات."    : updateEmail.validity.typeMismatch      ? "أدخل عنوان بريد إلكتروني صالحاً." : "";   updateEmail.setCustomValidity(message);  emailError.textContent = message;  if (message) updateEmail.setAttribute("aria-invalid", "true");  else updateEmail.removeAttribute("aria-invalid");} updateEmail.addEventListener("invalid", syncEmailError);updateEmail.addEventListener("input", () => {  if (updateEmail.getAttribute("aria-invalid") === "true") syncEmailError();});

The custom message is cleared before evaluating the current value. Correcting the address therefore clears both the native custom error and the inline error state. The example handles this field's required and email-type constraints, not every possible form rule.

Translate server-originated errors too. Map stable error codes to reviewed Arabic messages rather than showing an English backend exception. Keep server validation authoritative for the submitted data. MDN's validation guide explains client-side constraints and custom validity.

If an error message includes the submitted email or code, isolate that value within the Arabic explanation. The control's LTR direction does not automatically carry into a separate error paragraph.

Make failed submission recoverable#

After a rejected submission, preserve the description, priority and other entered choices. Return the user to a useful correction path rather than clearing the form or leaving focus at an unrelated submit button.

For several errors, provide an Arabic summary that identifies the affected fields and links to them. Keep inline error details associated with the same controls. W3C's guidance on form notifications describes summaries, correction instructions and field-level feedback.

Check focus after the error state appears and after a field is corrected. Avoid an alert on every keystroke; users need enough feedback to fix the problem without the form repeatedly interrupting entry.

Test server rejection even when every client-side constraint passes. A request can fail because an equipment reference is unknown or a service option is unavailable. Those messages need Arabic copy and the correct field association too.

Success also needs a clear Arabic confirmation. Verify that a retry does not create duplicate requests under the application's submission policy, and that pending feedback does not erase the values the user may need to revise.

Review screens need their own text boundaries. A reference that was readable inside an LTR input does not retain that element's direction when inserted into an Arabic confirmation sentence. Render the reference as a separate LTR span or another appropriate isolation boundary, and insert dynamic values as text. Keep the Arabic sentence around that boundary in logical order. Test copying the reference from the confirmation as well as from the input, comparing the resulting characters with the submitted value. This catches a different failure from testing whether the request reached the server.

Add autocomplete where the field has a defined identity#

Use established autocomplete tokens for fields such as the update email or organization name when those meanings apply. Do not disable autocomplete across the whole repair form just because its interface is Arabic.

MDN lists the autocomplete tokens and their meanings. An equipment reference is not an email or personal-name field, so do not assign it an unrelated token to obtain a particular keyboard or autofill appearance.

R073 reports Identity fields missing autocomplete tokens. It does not establish that an autofilled value has the right direction or belongs in the right field. Inspect the populated form and submission data separately.

Test browser autofill and restored form state as well as manual typing. A previously saved Latin organization name can appear on the Arabic route, while a free-text description may remain Arabic. Direction should follow the field contract or its chosen automatic policy after population, not just while the control is empty.

Verify the completed task, not only the empty form#

Run the repair journey with Arabic prose, a Latin-format equipment reference, a pasted email address, an Arabic priority and a multilingual note. Inspect both the visible form and the resulting machine values.

Use keyboard-only and touch interaction where supported, and include native select menus and mobile keyboards in browser testing. A DOM assertion can establish a value or attribute, but cannot establish visible bidi order or usable editing behavior.

A free Ritla scan can report R070: tel/email/url inputs rendered RTL (these must stay LTR), and R071: Untranslated form labels / validation / help text. Editing, native-control interaction and successful correction still need the journey above. Continue with how to handle dynamic text direction for multilingual fields or RTL responsive design when errors and controls collide on smaller screens.