Headings, lists, and code blocks carry the scan anchors

What it is

Semantic scan anchors in documentation use structural types to express content relationships for both visual and assistive-technology navigation. Headings name topics and hierarchy; ordered lists express sequence; unordered lists express peers; code blocks mark executable, copyable, or otherwise literal content; tables align fields that need comparison. Anchors are not merely high-contrast styling, and scannability does not require turning every paragraph into bullets. Prose remains the right carrier for conditions, causation, and argument.

Search targets and deep links are part of the anchor system. A jump should arrive at a named semantic node so visual position, keyboard focus, and screen-reader context all make the destination evident.

Why it happens

Scanning relies on predictable distinctions. A heading helps match a question or task, a list exposes order or parallelism, a code block separates literal values from explanation, and a table supports row-and-column comparison. When structure matches the relationship, readers can choose where to attend without parsing every sentence first. Styling bold text as a heading leaves it out of a screen reader's heading list; splitting a conditional branch into unrelated bullets can erase its logic; using code formatting for emphasis falsely invites copying.

Anchors also provide machine-readable structure. Search can target a section, a table of contents can be generated from the heading tree, a deep link can reference a stable node, and assistive technology can navigate by type. If displayed wording, document semantics, anchor identifiers, and the search index drift apart, a page that looks orderly can still land on the wrong passage or be announced without context.

Studying it

Sample real queries and tasks, then send participants from search results or deep links to find a procedure, parameter, comparison, or explanation. Compare prose-only, visually styled but nonsemantic, and semantic versions on first correct landing, heading or control navigation, answer accuracy, mistaken copying, backtracking, and completion time. Include material that requires continuous reasoning so the study can detect damage from over-listing rather than rewarding fact lookup alone.

On narrow screens, inspect table overflow, code wrapping, and heading hierarchy. With keyboard and screen reader, test heading lists, list counts, header associations, code reading, copy-control names, and focus after a deep-link jump. Automated accessibility checks can flag missing headings or headers; they cannot establish that a heading is informative, a list type is correct, or a table suits the relationship, so task-based review remains necessary.

Where it stops holding

Paragraphs are not failed anchors. Explanations of cause, interacting conditions, and sustained arguments are usually more accurate as connected prose. A list item containing several paragraphs or complex branches may need subheadings, a table, or prose. Tables suit consistent comparison dimensions; when mobile layout or screen-reader navigation makes the relationship harder, use an item-by-item structure or an equivalent alternative.

Code blocks should contain code, commands, configuration, or content whose literal formatting matters, with prerequisites, environment, and consequences explained outside. Not every heading needs question syntax: a precise, distinguishable noun or task label can also match user vocabulary. Visual salience can support scanning but cannot replace correct hierarchy and programmatic semantics.

Applying it

• Mark the information relationship before choosing a form: ordered lists for steps, unordered lists for peers, suitable pair structures for terms and definitions, headed tables for comparable fields, language-labelled code blocks for commands and code, and prose or explicit substructure for causal and conditional reasoning.
• Build an unskipped heading tree with distinct names using real heading elements or equivalent platform semantics rather than bold imitation. Give tables a caption or explanation and associated row or column headers. Name code-copy controls accurately, and make overflow, wrapping, and focus usable on narrow screens.
• Assign every searchable section a unique, stable anchor. Search snippets should quote that section's actual content. On deep-link entry, expose the target heading, required prerequisites, and version, then place keyboard focus or screen-reader reading position at a sensible start.
• Review the structure view, mobile rendering, and screen-reader task together. Hierarchy and relationships should survive removal of decorative styling. A “masked prose” check may reveal buried information, but it must not demand that anchors replace the full answer.

Related

• Same group: T3.01.1 Users scan documentation, they don't read it · T3.01.3 One section answers one question
• Adjacent: T2.02.1 Headings must accurately preview page content · T1.06.1 Heading capitalization rules must be consistent
• Search terms: semantic headings · accessible documentation structure · scan anchors