Choose a task whose sequence matters
Start with a real page containing ordered instructions, a form or a comparison whose labels depend on nearby values. Write down the intended sequence before opening developer tools. For example, a reader must understand a prerequisite before acting on a submission instruction. An arbitrary collection of independent cards may allow several sensible orders.
W3C’s Meaningful Sequence guidance requires a programmatically determinable correct sequence when order affects meaning. It does not require every visually adjacent item to have one uniquely correct position. Use the reader’s task to identify genuine sequencing defects instead of reporting every difference between a layout and its source as a failure.
Check base direction and the content structure
Inspect the document’s language and direction separately. W3C’s internationalization guidance shows lang="ar" and dir="rtl" on the HTML element for an Arabic page whose overall direction is right to left. Right-aligning text visually is not a substitute for setting its base direction. Review unexpected local overrides before adding more CSS.
Read the source or accessibility representation in sequence and compare it with the intended task. Then inspect the rendered mobile layout. Record whether a component was moved visually while its meaningful order stayed elsewhere. Do not reverse every list or row just because the language is Arabic; steps, names and values must still retain their relationships.
Test reading and operation as separate observations
On a narrow viewport, read the page from beginning to end and note detached labels, misplaced notices or steps displayed out of sequence. Repeat with enlarged text and inspect what happens when columns collapse. A screenshot can document visual order, but it cannot establish the sequence a screen reader announces.
Use a screen reader where available and record the device, browser and assistive technology tested. Check keyboard navigation separately for interactive controls; focus order and reading order are related observations, not interchangeable evidence. If a screen reader test was not performed, record that limitation instead of inferring a pass from a DOM inspection.
Illustrative example: a three-step Arabic process
Imagine a fictional mobile onboarding page with steps for preparing details, checking them and submitting. A desktop layout rule visually reverses the cards, and the mobile version displays submission first. The reviewer records the visible sequence and compares it with the source, where the preparation step still comes first.
The proposed fix removes the inappropriate reversal for that component and keeps the logical process intact. The reviewer repeats the visual, reading and interaction checks on the revised page rather than assuming the CSS change resolved all modes. This is a diagnostic scenario, not a claim that the example was tested on a customer device.
Capture mixed text and a precise defect report
Include at least one real pattern that mixes Arabic with an email address, product identifier or number. Compare the displayed value with its intended value, including punctuation. Do not manually reverse characters to imitate their desired appearance. If a directional problem is found, give the implementer the exact string and context for a targeted bidirectional-text fix.
For each defect, save the page address, viewport, starting state, expected sequence, observed sequence and evidence. After correction, repeat the affected case and a neighboring component to catch unintended changes. An audit can flag structural concerns, but a complete RTL review requires inspecting meaning and behavior; this small test is not a declaration of full accessibility conformance.