Reading Order Preview: Inspect the Simplified HTML Source Sequence

A screen reader reading order preview can help you inspect the sequence in which meaningful content appears in supplied HTML, but it cannot reproduce what a real screen reader will announce. Paste an HTML fragment, choose a maximum number of entries, and review the simplified sequence of headings, text, links, image alternatives, controls, and other selected elements. This Reading Order Preview parses markup without executing embedded scripts or rendering it as active page content. It reports selected positive tabindex and aria-flowto patterns that need manual review, and exports a text or JSON record of its findings. Use it to investigate structural ordering problems, then verify behavior with an actual browser, keyboard, accessibility tree, and assistive technology.

Reading Order Preview

Preparing workspace…

A screen reader reading order preview can help you inspect the sequence in which meaningful content appears in supplied HTML, but it cannot reproduce what a real screen reader will announce. Paste an HTML fragment, choose a maximum number of entries, and review the simplified sequence of headings, text, links, image alternatives, controls, and other selected elements. This Reading Order Preview parses markup without executing embedded scripts or rendering it as active page content. It reports selected positive tabindex and aria-flowto patterns that need manual review, and exports a text or JSON record of its findings. Use it to investigate structural ordering problems, then verify behavior with an actual browser, keyboard, accessibility tree, and assistive technology.

Screen Reader Reading Order Preview At a Glance

AspectDetails
InputPasted HTML interpreted as a detached document
OutputBounded static sequence of headings, text, images and selected controls
Review findingsPositive tabindex and aria-flowto source patterns
ExportOrdered text record and JSON
LimitNot a screen reader, live accessibility tree or focus order simulation

Source Order Is a Starting Point for Accessible Content

The sequence of elements in HTML establishes an important foundation for reading and interaction, particularly when visual layouts rearrange components into columns, cards, or responsive grids. In a straightforward document, a heading usually appears before the text it introduces, and a form label appears near its related control. CSS can reposition content visually while leaving the underlying DOM sequence unchanged. This can result in an experience where sighted visitors scan cards from left to right but a screen reader encounters the content in a confusing sequence. The tool exposes a simplified document order so a reviewer can see the source arrangement without being distracted by color or layout. The reported order is not a guarantee of spoken output because browsers and screen readers apply additional semantic rules.

Paste Realistic Markup Instead of a Decorative Mockup

A useful test contains the actual HTML structure for a navigation section, main article, form, product card, or dialogue. Include heading levels, links, buttons, images with alt attributes, and paragraphs in their intended order. A single h1 followed by one paragraph will rarely reveal a structural problem. Instead, test components where the visual layout differs substantially from source order, such as a sidebar that appears first on desktop but follows the main content on mobile. The tool parses the pasted fragment as an inert document using the browser DOM parser. It does not fetch linked URLs, run JavaScript, or interpret a complete application state. Test the delivered DOM separately if scripts insert controls or reorder elements after page load.

Understand Which Text the Preview Includes

The analyzer traverses element and text nodes in document order and records a bounded set of entries. It exposes headings as distinct records, includes links and selected interactive elements as units, and records image alternative text when an img element is encountered. Elements identified as hidden by explicit hidden, inert, aria-hidden, or simple inline display/visibility declarations are excluded from the simplified sequence. Those are intentionally narrow rules rather than a complete style-engine evaluation. Content hidden through a complex stylesheet, pseudo-element, template, or script may not be represented exactly as a screen reader experiences it. Every row in the report should therefore be described as a source-derived approximation, with manual confirmation required before treating it as an accessibility finding.

Distinguish Document Reading from Keyboard Navigation

Reading order and keyboard focus order overlap, but they are not the same concept. A screen reader may traverse a document in browse mode, while Tab moves among focusable controls according to browser behavior and tabindex rules. Text that appears in the reading sequence may never receive keyboard focus; conversely, interactive elements can be reachable by Tab in an order that surprises a sighted visitor. This preview calls out positive tabindex values because they can change tabbing order independently of the DOM sequence. For a focused walkthrough of intended Tab behavior, use a keyboard focus order planner and then test a real keyboard in the target browser. Neither static output is a substitute for observing focus movement, visual focus indicators, or dialog focus containment.

Heading Order Provides Valuable Structural Context

Headings communicate the organization of a page, not just its typographic hierarchy. An h3 that appears before the relevant h2 may cause confusion even when CSS makes both visually similar. The preview shows heading elements with their extracted text so you can inspect whether a section begins before its description, whether a warning has a meaningful heading, and whether repeated card headings form a coherent sequence. It does not declare every heading-level jump a universal failure: sometimes a complex document structure requires further contextual judgment. Use representative content rather than placeholders and make sure heading text accurately describes what follows. The best outcome is a structure that makes sense when read linearly without sacrificing the visual design.

Worked Example: Rearranged Product Details

Imagine a product page with a title, price, specification table, add-to-cart button, shipping note, and reviews. The desktop design places a large product image on the left and product details on the right. A mobile design stacks the content, but the DOM happens to position reviews before the product title. Paste the relevant HTML and examine the reported sequence. If reviews appear first, changing the CSS grid order alone will not correct the source sequence. You may need to adjust component markup or the way content is assembled. Confirm that the revised source order works at both breakpoints and that keyboard navigation follows a sensible route through the add-to-cart controls. The preview helps identify the question, while live testing answers it.

Accessible Names Can Differ from Visible Strings

An image may have alternative text that is essential to understanding its content, or it may be decorative and intentionally have an empty alt attribute. An input may receive its accessible name through a label, aria-labelledby, or another mechanism. This preview records only a limited approximation for such controls and does not implement the full accessible-name computation. A placeholder, in particular, is not a reliable substitute for a persistent form label even when the preview displays it as a recognizable clue. Use the form label inspector for selected markup relationships and verify final names in the browser accessibility panel and with assistive technology. A row in this tool should not be read as confirmation that a control has an adequate accessible name.

Why Visual CSS Ordering Can Create Conflicts

Developers often use flexbox order, grid areas, or absolute positioning to achieve visually pleasing arrangements without changing source markup. Such techniques are not inherently forbidden, but they can make reading and navigation sequences diverge. A sidebar can visually appear before the article while remaining after it in DOM order, which may be appropriate or confusing depending on the task. The tool does not load or compute stylesheets, so it cannot evaluate the final visual grid or detect every CSS ordering rule. When a design uses substantial visual reordering, compare the tool’s sequence against screenshots at different breakpoints and traverse the actual page with a keyboard. Any difference should be considered through the user task, not merely through whether two sequences are identical.

ARIA Relationships and Widget Behavior Need Live Testing

ARIA attributes can communicate role, name, state, and relationships that are not obvious from raw text alone. Certain custom widgets also manage focus programmatically and expose dynamic content in response to user actions. A pasted HTML fragment cannot represent all of these behaviors, and a static preview can miss shadow roots, content portals, virtualized lists, and announcements through live regions. The analyzer therefore records selected aria-flowto uses for review rather than attempting to simulate their speech order. If a widget uses aria-controls or aria-expanded, test those relationships in their interactive state. A separate ARIA attribute validator can identify some source-level attribute issues, but meaningful verification still requires the rendered application and assistive technology.

Export a Reproducible Structural Observation

The report lists numbered entries with their source tag and extracted text, plus warnings for selected patterns that can affect focus or semantic flow. Copy the text summary or download JSON when creating a developer issue, and include the original HTML sample in your local testing record if appropriate. The export provides an observation of supplied markup at a point in time; it is not a certified accessibility assessment. Keep the relevant viewport, browser, state, and user task alongside the report, because ordering defects often depend on a specific component configuration. Avoid reproducing sensitive data in bug reports when sample pages include account details or personally identifying text. Substitute representative values while preserving the DOM structure being tested.

Respect the Limits of the Static Sequence

The analyzer sets a maximum entry count to avoid overwhelming the interface with very large pasted documents. If the report reaches that limit, it marks the sequence as truncated; later content may be missing from the displayed analysis. It also shortens unusually long extracted text in each row for review. A blank result can mean the source was empty, consisted of excluded elements, or did not contain recognizable text, rather than indicating a good or bad reading order. Some elements with CSS-hidden content may appear because the stylesheet is not evaluated; some elements with ARIA-defined relationships may be omitted from this simplified view. These limits are deliberate reasons to check the actual user experience instead of assigning a pass/fail result from the export.

Frequently Asked Questions About Reading Order

Does this tool simulate a screen reader?

No. It produces a simplified traversal of pasted HTML and highlights selected structural concerns. Screen readers work with the browser accessibility tree, semantics, user settings, and dynamic interaction states. The preview cannot reproduce announcements, navigation shortcuts, focus management, or the effects of every CSS rule. Verify findings with a supported screen reader and keyboard before describing them as confirmed barriers.

Can a visually correct page have the wrong source order?

Yes. CSS can rearrange components without changing the sequence of elements in the DOM. A design can appear logical to a sighted visitor while creating confusing reading or focus behavior. The appropriate fix depends on the user task and the actual implementation; it often involves adjusting source markup rather than merely changing visual ordering.

Why are some elements omitted from the report?

The tool skips selected explicit hidden and inert content, scripts, styles, templates, and other markup that does not belong in a simple text sequence. It also stops when the configured entry limit is reached. CSS-driven hiding, generated content, ARIA naming, and dynamic controls may be represented imperfectly, so omissions or inclusions do not establish what a screen reader actually announces.

Is DOM order the same as Tab order?

Not always. Tab navigation targets interactive elements and may be influenced by tabindex, focus management, and component behavior. Static text usually does not receive Tab focus, even when it appears in the reading sequence. Use separate keyboard navigation testing to assess the order and visibility of focus on the actual page.

Can I use the JSON report in an accessibility issue?

Yes, as supporting evidence that documents what the static analyzer observed from a specific HTML sample. Include steps to reproduce, the rendered page state, and the impact on users, then verify the issue manually. The report alone is not evidence of a particular WCAG failure because its model does not cover the full accessible reading experience.