Order IDs and reference numbers in RTL

A customer reads a commission reference from an Arabic confirmation page, types it into support's lookup form and gets no match. The stored reference can be correct while the page presents its groups in a different visual order. Copying the text may even retrieve the correct string, which makes a text-only test miss the problem.

Treat an identifier as one value with a defined reading order. Give its displayed element a direction boundary, keep the source string unchanged, and test the actions that consume it. Do not reverse the data or alter its format to make one Arabic screenshot look right.

The examples use a ceramics workshop's commission portal. Its reference 0937286-45190 includes a leading zero and two numeric groups. The customer needs to compare that exact reference across the confirmation, collection slip and support conversation.

Define what the customer should read back#

The workshop's reference has a fixed sequence: the first group is 0937286, followed by the hyphen and 45190. It is not a range that the reader should interpret from one endpoint to another.

Problem

<p dir="rtl">مرجع طلب الخزف: <span>0937286-45190</span></p>

After the Arabic label, the identifier displays from left to right as 45190-0937286. Each group remains internally intact, but their sequence is wrong for the identifier's contract. A customer reproducing that visual sequence supplies a different reference.

Better

<p dir="rtl">مرجع طلب الخزف: <span dir="ltr">0937286-45190</span></p>

The value now displays as 0937286-45190. The label stays in the Arabic paragraph, and the reference has its own explicit LTR boundary.

These concrete reorderings follow the supplied measurements in Chromium 151, last checked on 2026-09-24. Test supported Firefox and Safari versions separately; those engines were not part of the supplied measurements.

Do not equate this with every hyphenated numeric display. For a range, an Arabic reader may correctly encounter the starting endpoint first from the right. A reference has a different requirement: its groups must match the authoritative identifier. State that requirement before changing the presentation.

Test shapes that expose the missing boundary#

A fixture beginning with Latin letters can appear correct without isolation. That makes it a weak test of whether a shared reference component handles every supported format.

These are alternative fixture formats for comparison, not instructions to rename an existing commission. A real product may support one format, several legacy formats or references imported from a partner. Use its actual contracts when building the test set.

Do not add a Latin prefix solely to hide the defect. An identifier change has consequences for lookup, labels and external integrations. A rendering component should handle the identifier it receives rather than requiring the data format to compensate for missing markup.

Also test a reference alone in an RTL block. Space-separated groups still reorder there. Hyphenated numeric groups without preceding Arabic in the same paragraph can display as written, so the standalone fixture does not replace the full Arabic-label fixture.

Why a plain span or code style does not fix it#

The browser processes character direction and paragraph context; it does not know that the text is a commission reference. Western digits have weak bidi types, and the hyphen does not bind these groups into one independent LTR identifier after the Arabic label.

The Unicode Bidirectional Algorithm defines the relevant numeric and separator processing. The important consequence here is that group order can change visually without changing the stored character sequence.

A plain span adds no directional boundary. A monospace font may make characters easier to distinguish, but it does not change that scope. Nor does replacing span with code automatically express the reference's direction.

Right alignment is another separate operation. An identifier can sit neatly at the right edge of its card while still presenting the wrong group order. Avoid a fix that only changes the location of the same incorrectly processed text.

Use direction markup on the element that owns the reference. W3C's inline bidi guidance explains tightly wrapping inserted values and using an existing meaningful element where possible.

For the workshop's fixed ASCII format, explicit LTR communicates the requirement directly. An automatic bdi also resolves this numeric fixture to LTR, but the component already knows the intended direction. It need not guess from the current string.

Preserve the authoritative reference as a string#

The reference is an identifier, even though much of it looks numeric. Keep the leading zero, separators and case according to the source system's contract.

Do not pass it through Intl.NumberFormat, parse it as a number or rebuild it from numeric chunks. Converting a leading-zero group to a number discards information that staff need to read back. Adding grouping separators can create a string the lookup service does not recognize.

Keep one canonical value in the record:

const commission = {  reference: "0937286-45190"};

Direction belongs to the renderer, not to a modified version of commission.reference. Do not prepend invisible marks or store an already isolated string in that field just to simplify the Arabic confirmation page.

This separation also prevents a visual repair from changing URLs, barcode payloads, exports or exact-match lookups. Each consumer should receive the representation its contract requires; the HTML display can supply its boundary independently.

If an external reference includes a different digit script or punctuation, do not silently normalize it as an RTL fix. Determine what the issuer considers equivalent. The system may permit a documented input convenience, but that is a data-validation policy rather than a consequence of page direction.

Treat unexpected control characters as something to investigate, not a reason to strip every non-ASCII character from every field. A known machine-reference grammar can be narrow while customer names and notes remain ordinary multilingual text.

Keep display and destination tied to the same value#

The reference can also be a link to the commission detail page. Put its boundary on that link and derive both text and destination from the same canonical reference:

<p dir="rtl">مرجع طلب الخزف: <a id="commission-reference" dir="ltr"></a></p>

// Run after the markup exists. This is a route in the workshop application.const commission = { reference: "0937286-45190" };const referenceLink = document.getElementById("commission-reference"); function renderReference(reference) {  if (typeof reference !== "string") {    throw new TypeError("A commission reference must be a string");  }  referenceLink.textContent = reference;  referenceLink.href = `/commissions/${encodeURIComponent(reference)}`;} renderReference(commission.reference);

The example inserts text safely and keeps the leading zero. MDN's textContent reference explains how the property reads and replaces text content. It does not itself establish bidi isolation; that requirement is carried by the link's markup.

If the clickable text is instead an Arabic action such as “View commission,” leave that action label in Arabic direction. The destination containing an LTR reference does not require the visible Arabic label to become LTR.

Test record changes without reloading. Updating only the text can leave the link pointing at the previous commission; updating only the link can leave staff reading a stale reference. That is a different failure from bidi reordering, but it affects the same read-back workflow.

Read-back and copy tests establish different things#

A copied reference can match the backend even when the screen presents its groups in the wrong visual sequence. The supplied browser checks preserve logical text order on copy. A successful clipboard assertion therefore cannot close a visual-order bug.

Test the customer's read-back task explicitly. Have a reviewer compare the reference shown in the Arabic confirmation with its authoritative sequence, then reproduce it in the lookup field. For identifiers with several groups, agree which group should be encountered first and verify the separators too.

For a dedicated copy-reference action, use the canonical reference. Do not scrape the full label-value sentence, a shortened visual label or an element containing extra explanatory text.

The Clipboard writeText documentation describes the browser API and its secure-context requirement. A copy action also needs tested success and failure feedback, but that feedback should stay outside the identifier text.

Keep literal controls out of the copied identifier unless the reference contract actually includes them. HTML dir attributes do not become extra reference characters, whereas controls inserted into a text node remain data in that node.

Manual selection is another path. Test it separately from a custom button and inspect the pasted result in the real lookup workflow. Neither clipboard path proves that the original visual sequence was clear to a person reading it aloud.

A lookup field should collect the reference, not a number#

The support lookup accepts the workshop's reference grammar. Use a text input with its own LTR direction:

<div dir="rtl">  <label for="commission-lookup">مرجع طلب الخزف</label>  <input    id="commission-lookup"    name="reference"    type="text"    dir="ltr"    pattern="[0-9]{7}-[0-9]{5}"    spellcheck="false"    autocapitalize="off"    aria-describedby="reference-help"    required  >  <p id="reference-help">أدخل المرجع كما يظهر في تأكيد الطلب، مع الشرطة الفاصلة.</p></div>

The pattern is specific to this fixture's seven-digit and five-digit groups. It is not a universal validator for order references. A product supporting legacy or partner formats must express those accepted formats instead.

type="number" is the wrong control for a value whose separators and leading zeros are part of its identity. A numeric keyboard hint is also not automatically helpful if customers need letters or a hyphen. Choose the input behavior for the actual grammar and test the relevant mobile keyboard.

MDN's text input reference covers text-control attributes. The direction attribute establishes the field's intended editing context; it does not perform backend lookup or decide equivalence rules.

Test typing, pasting, selecting a group, correcting a digit and resubmitting after failure. The empty, invalid and corrected states should retain the same direction policy. Do not seed the field with a hidden mark to make it look correctly aligned.

A separate line or table cell can conceal the bug#

In a commission summary, the label and value might be separate definition-list entries:

<dl dir="rtl">  <dt>مرجع طلب الخزف</dt>  <dd><span dir="ltr">0937286-45190</span></dd></dl>

This keeps the summary's structure and the reference's boundary explicit. It does not depend on whether the current standalone block happens to display the hyphenated value correctly without isolation.

A compact mobile confirmation may later put the label and value back into one sentence. If the reference renderer lacked a boundary because the desktop block looked fine, that layout change can expose the original problem.

Tables have the same distinction. A bare cell containing only a hyphenated numeric value can behave differently from a cell that contains an Arabic label followed by the reference. Space-separated numeric groups can reorder even in the bare RTL cell. Test both shapes when the application supports them.

Do not force a whole table LTR to repair one identifier column. The Arabic headers, descriptions and column layout have their own direction requirements. Apply the value boundary at the reference element or a cell that owns only that reference.

The regression target should be the shared reference renderer across the summary, a list item and the mobile sentence. A screenshot of one spacious desktop cell cannot establish that every placement is fixed.

Label different reference systems before comparing their output#

The commission portal may show an internal order reference, a courier reference and a payment processor's reference. Different strings across those surfaces are not necessarily a direction defect. Establish which identifier each component is supposed to display before comparing their group order.

Give each value a clear Arabic label and its own directional boundary. Do not put several references into one isolated string separated only by punctuation and expect customers to infer which one support needs. The read-back task includes selecting the right field as well as reading its characters correctly.

Copy actions should name their target accordingly. A generic copy icon beside a card containing several identifiers can copy the wrong one even when every visible value is isolated. Keep the action's data source and feedback tied to the selected reference type.

Use the same distinction in issue reports. Record the source field, not just “order number,” if the product contains several reference systems. Otherwise an investigation can mistake a legitimate partner identifier for a reversed internal one, or repair a renderer that was showing the wrong data field altogether.

This is also a reason to avoid a universal reference formatter that rewrites punctuation or prefixes. A courier's format and the workshop's format may have different grammars. They can share an HTML boundary component while preserving their separate identity contracts.

Keep notification formats separate from stored identity#

The workshop may send an HTML confirmation and a plain-text alternative. The reference should retain its same source value in both, but the presentation mechanisms differ.

In HTML, use the same narrow direction boundary around the identifier:

<p dir="rtl">احتفظ بمرجع طلب الخزف: <span dir="ltr">0937286-45190</span>.</p>

Keep the sentence's final punctuation outside the value. Test the actual email template in the clients the product supports rather than assuming a browser preview establishes identical email rendering.

A plain-text message cannot carry a working span. A destination-specific isolate can be appropriate:

const reference = "0937286-45190";const LRI = "\u2066";const PDI = "\u2069";const message = `احتفظ بمرجع طلب الخزف: ${LRI}${reference}${PDI}.`;

This constructs one presentation string without changing reference. W3C's Unicode control guidance explains using paired isolates when markup is unavailable.

The helper needs a defined input contract. A controlled single-line identifier differs from arbitrary external text containing controls or paragraph breaks. Keep the pair intact after any shortening or message assembly, and test the final destination.

For a copy-reference action, return the canonical identifier rather than extracting it from the formatted notification. A plain-text message and a machine lookup key are different representations with different responsibilities.

Do not localize the reference as though it were a count#

The workshop can localize a quantity of ceramic pieces while preserving the commission reference's defined characters. The fact that both fields contain digits does not make both inputs to a number formatter.

Keep the ASCII identifier stable if that is the issuer's contract. Translating its separators, inserting grouping commas or converting its digit script can produce a representation that no longer matches a label or external lookup system.

Arabic-Indic reference formats need their own fixtures when supported. The supplied browser checks show that spaced Arabic-Indic digit groups can still reorder inside bdi or dir="ltr". Isolation removes external influence, but it does not force every character inside it into source order.

That is a limit to the fixed Western-digit examples, not a reason to apply an override to all references. If the product requires a particular mixed-script representation, document its expected display and test it with the actual characters and separators. Scope any specialized treatment to that contract.

Do not infer the language of an identifier from its Latin letters, and do not translate a partner prefix simply because the page is Arabic. Localize the label explaining the reference, while preserving the data the customer must quote.

Normalize pasted input only under a documented lookup policy#

A reference copied from a document can contain a hyphen-like character that differs from the ASCII hyphen used by the workshop. A screenshot may not make the difference obvious. Changing direction will not make those strings equal.

For this fixture, the defined separator is U+002D. If support wants to accept a nonbreaking hyphen or another pasted separator as an input convenience, specify that mapping explicitly. Keep the resulting canonical reference distinguishable from the original submitted text when diagnosing a mismatch.

Do not remove every separator or invisible character and then try a lookup without understanding the identifier's grammar. That transformation can collapse distinct submitted values into the same candidate or hide an upstream data problem. A visual repair should not silently broaden the service's equivalence rules.

If a scanner appends a terminator or a paste includes surrounding whitespace, handle that input boundary according to the product's agreed policy. Do not apply an indiscriminate transformation to the middle of the reference. Test accepted conveniences and intentionally rejected values separately.

The displayed confirmation should then use the authoritative reference returned by the lookup, with its usual direction boundary. Echoing a loosely normalized user string as though it were the confirmed identifier can leave the customer reading a value the system never actually issued.

Highlighting and truncation must preserve a complete value#

A support search result may highlight the group that matched the customer's query. Keep the boundary around the complete reference, with highlight markup inside it:

<p dir="rtl">  المرجع المطابق:  <span dir="ltr">0937286-<mark>45190</mark></span></p>

The highlight is decoration, not a separate identifier. Do not add independent direction rules to every fragment generated by the search highlighter. Test the highlighted and unhighlighted renderings in the same Arabic sentence.

Long references need layout handling too. Where wrapping is allowed, CSS such as overflow-wrap: anywhere can provide break opportunities without inserting characters into the stored value. A flex or grid item may also need room to shrink. MDN's overflow-wrap reference describes that behavior.

If the customer must read the reference aloud, avoid a design that exposes only its suffix and ellipsis. Provide the complete value in the task's primary view or through an explicit reveal action. A correct copy button does not make an unreadable reference adequate for read-back.

Never build the link destination or copy payload from truncated text. Keep visual shortening separate from identity, and verify the full value after layout changes. A mobile line wrap is not permission to reorder groups or treat them as independent fields.

Debug visual order and logical data independently#

Select the reference element in DevTools and inspect its boundary:

const referenceElement = $0; // Select the displayed reference element.const style = getComputedStyle(referenceElement);console.table({  text: referenceElement.textContent,  dir: referenceElement.getAttribute("dir"),  direction: style.direction,  unicodeBidi: style.unicodeBidi});

A plain inline span with computed LTR is not sufficient evidence of isolation. Inspect the actual markup and bidi mode, along with any ancestor override or reset rule. MDN's dir documentation describes the attribute's role.

Compare the API value with the DOM text before changing either. If both contain the canonical reference but the screenshot differs, investigate visual processing. If the API has already lost a leading zero, the data path needs a repair that no wrapper can supply.

If the value looks identical but lookup still fails, inspect code points for different separators, spaces or hidden controls. Do not silently delete arbitrary characters until the field matches. Identify where the unexpected representation entered and apply the reference system's validation policy.

Keep browser screenshots and logical strings together in the issue report. Neither one is sufficient alone to describe this class of failure.

Verify the reference across the customer's task#

Use the digit-first fixture as well as the letter-prefixed fixture. The latter should continue to work, but it cannot prove the former is isolated.

Repeat after switching language, changing records and saving lookup corrections. Check the actual email clients and browsers the product supports. Keep one fixture that demonstrably fails without the boundary so the regression test cannot pass merely because its example starts with Latin letters.

A free Ritla scan can report R021, unisolated bidi hazards: phones, emails, Latin tokens inside Arabic text. Pair that finding with manual read-back of the numeric references above, then read nested LTR content inside an RTL page for boundary choices or how browsers render mixed RTL and LTR text for the surrounding processing.