The Unicode Bidirectional Algorithm (UAX #9) lays out mixed right-to-left and left-to-right text without changing the logical sequence of encoded characters. Accessibility is affected when authors attempt to repair the visual order by reversing stored text, misapply dir, or allow untrusted fragments to change the surrounding context. Correct markup supports both visual reading and useful speech output.
Logical sequence is the stable text representation
An Arabic phrase with embedded English initials and numbers is normally stored in logical reading order. UAX #9 resolves display levels and visual runs. Assistive technologies consume text and accessibility semantics rather than simply reading screen pixels from left to right.
Reversing code points so a screenshot appears ordered can make speech, copy/paste, search and keyboard navigation incorrect. Preserve logical text and use higher-level paragraph direction and isolation for display.
Paragraph direction is separate from alignment
HTML dir="rtl" sets an element's directionality behavior and can influence the bidi context. CSS text-align:right merely aligns text; it does not have equivalent effects on bidirectional layout or user agent direction semantics.
For meaningful RTL content, put direction information on the correct container instead of relying on right alignment. A page can have a right-aligned LTR search field and a left-aligned RTL paragraph; alignment alone is not a reliable indication of reading direction.
Language and direction are independent metadata
lang="ar" may help a screen reader select Arabic pronunciation, while dir="rtl" establishes a visual base direction. Neither one is a substitute for the other, and not every language using Arabic script is Arabic.
When inserting multilingual spans, set known language tags appropriately without overwriting the surrounding content's language. Direction auto-detection may be useful for unknown user input but should be evaluated with neutral and mixed-script text.
Bidi isolation contains foreign fragments
A Latin invoice ID embedded in Arabic prose can cause surrounding punctuation to reorder if left in an inappropriate bidi context. HTML <bdi> is designed to isolate text of potentially unknown direction. The dir="auto" value can be used where first-strong behavior fits the input.
Prefer semantic isolation over inserting invisible format controls directly into user names for web display. For plain-text exports where markup is unavailable, UAX #9 isolates may be appropriate, but they must be inserted deliberately and preserved during round trips.
Keyboard caret navigation is not pixel traversal
The caret position is bound to logical text boundaries and browser selection behavior, while the displayed glyph order can contain bidirectional runs. Left/right arrow keys can behave differently near LTR/RTL boundaries depending on platform and editing rules.
A custom editor must not derive the current text index by measuring horizontal distance from the start of the line. Use selection APIs, browser-native controls and grapheme-aware boundaries, then verify caret navigation with actual mixed-direction fixtures.
Bidi format controls require review in untrusted strings
U+202E RIGHT-TO-LEFT OVERRIDE changes display order and can hide critical filename or source-code context. Directional isolates such as U+2066 LRI and U+2069 PDI also affect layout, often legitimately. A user may not see these code points during ordinary reading.
Security-sensitive code reviewers should expose invisible directional controls explicitly. Accessibility testers should verify that diagnostic views do not accidentally inject the labels into the saved original string or render them as executable markup.
Screen reader utterances vary across product versions
A screen reader may change speech voice with language metadata and may pronounce digits or punctuation differently at a bidi boundary. Exact utterances are implementation- and locale-dependent; UAX #9 does not specify a universal spoken reading transcript.
Record assistive technology model, browser, OS language, selected voice and screen-reader verbosity. Test comprehension and navigation rather than asserting one fixed punctuation utterance across all environments.
DOM order and accessible reading order should agree
CSS visual reordering, absolute positioning and flexbox ordering can make the painted order differ from document reading order. For RTL navigation, using logical CSS properties and semantic DOM order often produces better results than building the markup in reversed sequence.
Make sure focus order, keyboard navigation, visible labels and accessible reading order remain coherent. A visually mirrored interface is not necessarily accessible if its DOM or tab sequence stays nonsensical.
Create a mixed-direction accessibility corpus
Build specimens with Arabic + ASCII identifiers, Hebrew + numbers, mixed punctuation, an email address, a URL and a paragraph wrapped across lines. Save logical scalar sequences and CSS/HTML direction settings.
Check copy/paste, focus order, selection, screen reader speech and the handling of invisible controls. Include both normal user prose and security-sensitive filenames, and separate layout defects from missing language metadata.
Reproducible example and interpretation
This example isolates one operation on actual Unicode strings or semantic markup. It does not substitute for a full standards conformance suite, an accessibility audit, or a cross-platform interop test. Inspect each input scalar, note the API or library version, and define whether the expected output must preserve exact data or a narrower interpretation.
<p lang="ar" dir="rtl">المعرّف <bdi>ABC-123</bdi> متاح.</p>
<p lang="en" dir="ltr">Ticket <bdi dir="auto">اسم-42</bdi> received.</p>
<!-- Keep logical Unicode text intact; isolation affects presentation. -->
<script>
const sample='مرحبا ABC-123';
console.log([...sample].map(c=>c.codePointAt(0).toString(16)));
</script>When a result differs, inspect the stage where it first changed: decoding, string operation, normalization, segmentation, serialization, layout or accessibility name computation. A perfectly rendered string can have different underlying scalars, and two scalarly identical strings can render differently.
Reference matrix and expected distinctions
| Scenario | Input/operation | Expected distinction |
|---|---|---|
| Base direction | dir=rtl | sets bidi paragraph context, not just alignment |
| Language | lang=ar | speech-language hint, independent from dir |
| Untrusted fragment | bdi | isolates embedded direction |
| Invisible control | U+202E | can reorder painted content |
| Caret | DOM Selection | logical positions distinct from visual x coordinates |
The observations above are interpreted under a declared Unicode or platform API version. If a task is language-sensitive, the locale and data version belong in the fixture; if it is semantic, accessible names and task comprehension require evidence beyond a Unicode code-point list.
Verification strategy and diagnostic controls
- Base direction. Preserve a fixture for
dir=rtland record its exact Unicode scalar values, environment settings and expected result. Interpretation: sets bidi paragraph context, not just alignment. Compare actual output by the metric relevant to this contract rather than by screenshot alone. - Language. Preserve a fixture for
lang=arand record its exact Unicode scalar values, environment settings and expected result. Interpretation: speech-language hint, independent from dir. Compare actual output by the metric relevant to this contract rather than by screenshot alone. - Untrusted fragment. Preserve a fixture for
bdiand record its exact Unicode scalar values, environment settings and expected result. Interpretation: isolates embedded direction. Compare actual output by the metric relevant to this contract rather than by screenshot alone. - Invisible control. Preserve a fixture for
U+202Eand record its exact Unicode scalar values, environment settings and expected result. Interpretation: can reorder painted content. Compare actual output by the metric relevant to this contract rather than by screenshot alone. - Caret. Preserve a fixture for
DOM Selectionand record its exact Unicode scalar values, environment settings and expected result. Interpretation: logical positions distinct from visual x coordinates. Compare actual output by the metric relevant to this contract rather than by screenshot alone.
Include both ordinary input and edge cases such as decomposed combining accents, UTF-16 surrogate pairs, emoji ZWJ sequences and bidirectional text where relevant. Store exact fixtures and expected outputs so later updates to Unicode, ICU and browser engines can be compared reliably.
How to interpret differences
Do not equate visually similar text with character identity or conflate character count with byte size. When a system deliberately transforms or presents data differently, record that as a product policy rather than silently applying it to all strings. Primary-source algorithms and application-level choices serve different purposes.
Primary standards and technical documentation
Consult the following standards and API documentation to verify feature support, normative wording and known limitations. Unicode data and browser behavior change between releases, while the user's source text should remain available for independent inspection.
- Unicode Bidirectional Algorithm UAX #9 — primary standard or technical data reference. Consult the applicable revision for normative terms, version-dependent behavior and the defined scope of interoperability claims.
- W3C Internationalization: Inline Bidi Markup — primary standard or technical data reference. Consult the applicable revision for normative terms, version-dependent behavior and the defined scope of interoperability claims.
- WHATWG HTML dir Attribute — primary standard or technical data reference. Consult the applicable revision for normative terms, version-dependent behavior and the defined scope of interoperability claims.
- W3C Accessibility Name and Description Computation — primary standard or technical data reference. Consult the applicable revision for normative terms, version-dependent behavior and the defined scope of interoperability claims.
- W3C WCAG 2.2 — primary standard or technical data reference. Consult the applicable revision for normative terms, version-dependent behavior and the defined scope of interoperability claims.
Related published research
This is part of the Text Accessibility virtual silo. The following already published articles provide detailed context on neighboring Unicode text-processing and interoperability operations.