A browser does not use a webpage as one unchanged document. It parses HTML into a Document Object Model (DOM), interprets styles, calculates layout, produces visible output, and exposes accessibility information through platform interfaces. These representations describe related aspects of the page, but they are not interchangeable.
A heading can be an element in the DOM, a styled box in the layout, an accessible heading, and visible text on the screen. Each representation preserves different information about it. Understanding those differences helps explain why a page can look correct while its reading order, accessible name, or underlying structure is wrong.
This article maps those relationships. It is not a fixed blueprint of browser internals: engines differ in how they organize their work, and a living page changes as resources load, scripts run, and people interact.
One webpage, several related representations
HTML supplies document structure and meaning, but it is only part of what a browser uses. CSS, JavaScript, images, fonts, browser defaults, viewport dimensions, and user settings can all influence the result.
The following distinctions provide a useful working map.
| Representation | What it describes | What it does not establish by itself |
|---|---|---|
| HTML source | The markup supplied to the browser, commonly in an HTML response. | The document’s current state after parsing and script-driven changes. |
| DOM | The current document as nodes, attributes, text, and relationships. | Exactly what is visible or exposed to assistive technology. |
| Style representations | CSS rules and the resulting styles that apply to elements and other styled parts. | The complete geometry or final appearance of the page. |
| Layout structures | Boxes, positions, dimensions, line wrapping, and related geometry. | The document’s full semantics or accessible names. |
| Accessibility tree and platform exposure | Accessible objects and their roles, names, states, and relationships. | The full visual presentation or everything a person experiences with assistive technology. |
| Rendered output | The visible result produced through painting, rasterization, and compositing. | The underlying structure, keyboard behavior, or accessibility information. |
These are useful conceptual distinctions, not a promise that every engine maintains one neatly separate tree for each row. Some representations are trees; others involve rules, boxes, fragments, drawing instructions, or layers.
Most importantly, the accessibility tree is not made by reading the finished pixels, and the rendered page is not simply the DOM drawn one node at a time.
HTML source and the live DOM
HTML source is markup. The DOM is the browser’s structured, programmable representation of the document.
During HTML parsing, the browser interprets tokens and builds document nodes according to parsing rules. This is more than copying tags into a tree. The parser can insert implied elements, close elements implicitly, and handle malformed markup in defined ways.
For example, an HTML table written without an explicit <tbody> can acquire a tbody element in the parsed DOM. Unexpected nesting in developer tools may therefore come from parsing behavior rather than JavaScript.
Scripts can also change the document during parsing or afterward. They may insert text, remove sections, update attributes, or construct much of an application interface. The live DOM reflects those changes; the original HTML response does not.
View Source and the Elements panel answer different questions
- View Source generally shows source markup rather than a serialization of the current live DOM.
- The Network panel can show the HTML response captured for a particular request.
- The Elements or Inspector panel shows the current document structure, including many changes made after the response arrived.
If a paragraph appears in the live document but not in the captured HTML response, JavaScript may have inserted it. If the structure differs before any application code runs, parsing rules may explain the difference. Inspecting both representations helps distinguish those causes.
Styles, layout, and visible output
The DOM supplies document structure, but structure alone does not determine appearance. The browser must also resolve styles and calculate how content occupies space.
CSS rules and computed styles
Styles can come from external stylesheets, embedded rules, inline declarations, browser defaults, and user styles. The CSS Object Model (CSSOM) provides interfaces for stylesheet rules and related CSS information; it is not a second copy of the HTML element tree.
The browser resolves applicable declarations through the cascade, inheritance, and other style rules. Developer tools can then expose computed styles for a selected element. A computed value helps explain the styling decision, but it does not always describe the final used geometry. A percentage width, for example, still depends on its layout context.
Layout structures do not match DOM nodes one for one
Layout determines positions, dimensions, and text wrapping. Its structures differ from the DOM because visual formatting has different needs:
- An element with
display: noneremains in the DOM but generates no layout box. - Inline content can occupy multiple line fragments.
- CSS pseudo-elements can generate visual content without corresponding ordinary DOM elements.
- Formatting can require anonymous boxes that do not correspond to authored elements.
Terms such as “render tree” can help introduce these ideas, but should not suggest a universal browser structure with a direct counterpart for every DOM node.
Geometry becomes visible output
After relevant style and layout work, the browser produces drawing information and ultimately the pixels displayed on screen. Painting, rasterization, and compositing contribute to that result. Their organization and scheduling depend on the engine and the change being processed.
The browser rendering pipeline explains this work in more detail. For the present distinction, the important point is that a screenshot records appearance—not the document relationships or interaction semantics behind it.
The accessibility representation
The accessibility tree represents information that assistive technologies can use, including roles, accessible names, states, values, and relationships. Browsers derive that information from document semantics, ARIA, text, rendering-related information, and other relevant properties.
A native <button>, for example, can expose a button role. Its text commonly supplies its accessible name. A disabled state can communicate that it is unavailable for activation.
This representation is selective. Not every DOM node needs a separate accessible object. Some containers may be omitted or flattened, while meaningful content and relationships remain exposed.
Visibility and accessibility exposure are different questions
Several common cases show why neither representation can stand in for the other:
display: none: content normally has neither layout boxes nor ordinary accessibility-tree exposure.aria-hidden="true": content can remain visible while being excluded from accessibility exposure.- Visually hidden text: suitable CSS can keep text available to assistive technology without displaying it in the ordinary visual layout.
opacity: 0: content can be transparent while retaining layout space, accessibility exposure, and potential interactivity.
There are further rules, including cases where hidden text referenced for an accessible name or description can still contribute to that computation. “Hidden” is therefore not one universal browser state.
ARIA also does not automatically change keyboard behavior. Applying aria-hidden="true" to a focusable control does not remove it from the tab sequence. That can leave a keyboard destination without the accessibility information needed to understand it.
The tree is not the whole assistive-technology experience
Browsers expose accessibility information through platform APIs, and assistive technologies interpret that information according to their own behavior and interaction modes. A developer-tools accessibility view is valuable evidence, but it is not a complete simulation of a screen reader session.
The relationship between semantic HTML and the accessibility tree provides a deeper explanation of how document choices affect this exposure.
Following one example across representations
Consider this small markup snapshot. It describes a route card; implementing its save action would require additional behavior.
<article class="route-card">
<h2>River Trail</h2>
<img src="river-trail.jpg" alt="">
<p>A three-mile walking route beside the river.</p>
<button type="button" aria-label="Save River Trail">
Save
</button>
<p hidden>This route has been saved.</p>
</article>Each representation answers a different question about this card:
- Source: the markup contains a heading, image, description, button, and hidden confirmation paragraph.
- DOM: those elements and their attributes exist as document nodes, including the hidden paragraph.
- Layout: CSS determines their dimensions and arrangement. Under normal hidden-attribute behavior, the confirmation paragraph has no displayed box.
- Accessibility: the heading carries heading semantics, and the button’s accessible name is “Save River Trail.” The empty image alternative indicates that the image is decorative in this context and is normally omitted from accessibility exposure.
- Visible output: the image can appear on screen, while the button displays only “Save.” The hidden confirmation is not displayed.
The empty alt value is appropriate only if the image adds no information the reader needs. If the image communicated essential route conditions, its alternative would need to preserve that meaning.
This example demonstrates why visible text and accessible names can differ legitimately. The button’s accessible name adds the route’s identity while retaining the visible word “Save.” It also shows that presence in the DOM does not imply presence on screen or in the accessibility tree.
How changes affect the page
Browser representations are maintained as the page changes. They are not produced once and then left untouched.
However, not every change requires the same work:
- Changing an accessible label may update accessibility information without visibly changing the control.
- Resizing the viewport can change wrapping and layout without changing the DOM.
- Changing text can affect the DOM, accessible information, geometry, and visible output.
- Loading a font can alter text measurements and appearance while leaving document structure unchanged.
- Revealing a hidden panel can affect layout and accessibility exposure, while also creating a need to review focus and interaction behavior.
Browsers schedule and batch work where possible. Some changes can avoid layout; others require broader recalculation. The specific dependencies matter more than the simplified idea that every update must rerun an identical sequence.
Visual order can also change without document order changing. CSS layout may move a card or control to a different screen position while leaving reading and keyboard sequences unchanged. Reviewing source order and visual order together helps identify when those differences become confusing.
Inspecting the right representation
When a webpage behaves unexpectedly, begin with the question you need to answer rather than treating one inspection panel as the whole page.
- What did the server send? Inspect the captured response and relevant resource requests.
- What document exists now? Inspect live elements, text, attributes, and nesting.
- Why does it occupy this space or look this way? Examine applicable CSS, computed styles, and layout information.
- What meaning is exposed? Inspect accessible roles, names, states, and relationships.
- Can someone complete the task? Test keyboard behavior, focus, zoom, and relevant assistive-technology interactions.
For example, a button that looks correctly labeled may still have an outdated aria-label. A missing paragraph may exist in the DOM but be hidden by CSS. A misplaced section may reflect a visual ordering rule rather than incorrect document nesting.
Browser developer tools help locate the cause across these layers. Testing complete tasks with assistive technology adds evidence that structural inspection alone cannot supply.
The durable principle is simple: inspect structure, presentation, accessibility information, and behavior as related but distinct parts of the same webpage. Agreement between them supports a coherent experience. Differences are not automatically errors, but they should be intentional and understandable.