Anchor Links and Fragment Identifiers: Accessible In-Page Navigation for Long Documents

How anchor links and URL fragments work

A basic in-page anchor link has two parts:

1. A link whose href contains a fragment identifier.
2. A target element with a matching id.

<a href="#aircraft-inspection">Aircraft inspection</a>

<h2 id="aircraft-inspection">Aircraft inspection</h2>

When the link is activated, the browser locates the element whose id is aircraft-inspection and brings that element into view. The address bar changes to include the fragment:

https://example.com/maintenance-guide/#aircraft-inspection

That complete URL can then be copied, bookmarked, or shared. A person following it can arrive near the relevant section instead of beginning at the top of the document.

The fragment is interpreted by the browser after the underlying resource has been loaded. In a conventional HTTP request, the fragment itself is not sent to the web server. It identifies a location or secondary resource within the returned document.

Same-page and cross-page fragment links

A link can target a section on the current page:

<a href="#maintenance-records">Maintenance records</a>

It can also target a section on another page:

<a href="/aircraft-maintenance-guide/#maintenance-records">
  Aircraft maintenance records
</a>

Both patterns depend on a stable, unique target ID.

Anchor links are part of document structure

Anchor links work best when they reflect the actual organization of a page. A table of contents should not impose an artificial structure on an otherwise disorganized document. Its links should expose the structure already expressed through headings and meaningful sections.

For most articles, the most useful fragment targets are heading elements:

<section aria-labelledby="roof-ventilation">
  <h2 id="roof-ventilation">Roof ventilation</h2>
  <p>...</p>
</section>

This pattern creates a clear relationship among:

• the visible section heading;
• the section’s semantic label;
• the fragment identifier in the URL; and
• the link that brings a reader to the section.

A sound heading hierarchy remains important. Anchor links can reveal and navigate that hierarchy, but they cannot repair headings that are missing, vague, or arranged out of order.

Use meaningful IDs

IDs should be concise enough to read and stable enough to preserve. A descriptive ID is usually more maintainable than one generated from a database record or visual position.

Prefer:

id="keyboard-navigation"
id="annual-inspection"
id="window-replacement-costs"

Avoid IDs such as:

id="section-7"
id="content-block-18492"
id="blue-box"

Numbered or presentation-based IDs become unclear when sections are rearranged or the visual design changes.

IDs must also be unique within the document. If the same ID appears more than once, browser behavior and programmatic relationships become unreliable. Unique IDs are part of maintaining a coherent Document Object Model.

Accessibility and user experience

In-page navigation is particularly useful in long articles, reference pages, policies, documentation, glossaries, and frequently asked question collections. It lets people choose a destination without moving through every preceding section.

This benefits many readers, including people who:

• navigate with a keyboard;
• use screen readers or other assistive technologies;
• magnify the page and can view only a small area at once;
• experience fatigue or difficulty with sustained scrolling;
• return to a document to locate one known section; or
• follow a shared link to a specific answer.

Use real links with descriptive text

An anchor link should normally be an HTML <a> element with an href. This provides native keyboard behavior, link semantics, browser history integration, and familiar interactions such as copying the link address.

Link text should describe the destination. “Keyboard navigation practices” is more informative than “jump here” or “learn more.” Additional ARIA labeling is generally unnecessary when the visible link text is already clear. This follows the broader principle of letting native HTML do the work.

Scrolling and keyboard focus are related but different

Moving a section into view does not always mean keyboard focus has moved to that section. Browser and assistive technology behavior can vary according to the target element and navigation method.

For an ordinary table of contents, targeting a well-structured heading is often appropriate without additional scripting. Avoid automatically forcing focus unless there is a clear accessibility reason and the resulting behavior has been tested.

Skip links are a related but more specific pattern. A “Skip to main content” link should move keyboard users beyond repeated navigation and into the primary content region:

<a class="skip-link" href="#main-content">Skip to main content</a>

<main id="main-content" tabindex="-1">
  ...
</main>

The tabindex="-1" allows the main region to receive programmatic focus without placing it into the normal tab sequence. Whether it is needed depends on the target, browser support requirements, and implementation. Skip-link behavior should be tested with a keyboard rather than assumed from markup alone.

Account for sticky headers

A fixed or sticky site header can cover the destination heading after a fragment link is followed. CSS scroll-margin-top can preserve space above the target:

h2[id],
h3[id] {
  scroll-margin-top: 6rem;
}

The value should reflect the actual header height and spacing of the site. Test it at multiple viewport sizes because mobile and desktop headers may occupy different amounts of space.

Keep focus and target states visible

Keyboard focus should remain visibly apparent. A subtle :target style can also help readers recognize the section selected by the URL:

:target {
  background-color: #fff8d6;
}

Target styling should support orientation without creating distracting animation or reducing text contrast.

Anchor links, passage retrieval, and search

Fragment identifiers provide explicit destinations within a page. They may help browsers, search systems, citation tools, and other interfaces refer to a particular section rather than only to the document as a whole.

This can be useful when a long page contains several distinct answers. A search result, internal link, documentation reference, or AI-assisted retrieval interface may be able to send a person directly to the passage most relevant to the question.

Anchor links do not guarantee passage ranking, enhanced search results, or direct links from a search result. Search systems can identify passages without author-created fragment links, and their display behavior changes over time. Fragment identifiers should therefore be treated as useful document infrastructure rather than a ranking mechanism.

The stronger retrieval signals still come from the page itself:

• clear and specific headings;
• focused passages that answer identifiable questions;
• semantic HTML that reflects document meaning;
• descriptive internal links;
• consistent terminology and entity references; and
• enough context for a passage to remain understandable when retrieved.

This aligns anchor navigation with passage clarity. The fragment creates a destination, while the heading and surrounding text make that destination understandable.

Anchor links as internal semantic pathways

An internal link can point to the exact section that supports its surrounding statement:

<a href="/accessibility-guide/#visible-focus">
  visible keyboard focus
</a>

This is often more useful than sending the reader to the top of a broad guide and expecting them to locate the relevant material independently. It also makes the relationship between the source passage and destination passage more explicit.

As with other forms of internal linking for retrieval, the link should exist because the destination helps the reader. A page does not need a jump link for every paragraph or minor detail.

Fragment identifiers and text fragments are not the same

Author-created element fragments usually point to an HTML id:

#annual-inspection

Some browsers and search interfaces also support text fragments, which can identify and highlight matching text through a URL pattern such as:

#:~:text=annual%20inspection

Text fragments do not require the page author to add a corresponding element ID. Their support and behavior differ from traditional fragment identifiers. Stable author-created IDs remain the more direct way to define durable in-document destinations under the publisher’s control.

Practical implementation patterns

A compact table of contents

A simple navigation region is often enough for a long article:

<nav aria-labelledby="contents-heading">
  <h2 id="contents-heading">On this page</h2>
  <ul>
    <li><a href="#planning">Planning</a></li>
    <li><a href="#materials">Materials</a></li>
    <li><a href="#installation">Installation</a></li>
  </ul>
</nav>

The navigation label tells assistive technologies what the group of links represents. If the visible heading already provides that label through aria-labelledby, an additional aria-label is not needed.

Links back to the table of contents

Very long documents may benefit from occasional return links:

<p><a href="#quick-navigation">Back to quick navigation</a></p>

These links should be used selectively. Repeating one after every short section can add noise, especially for screen reader and keyboard users.

Heading permalink pattern

Technical documentation sometimes places a permalink beside each heading so readers can copy a section-specific URL:

<h2 id="inspection-intervals">
  Inspection intervals
  <a href="#inspection-intervals" aria-label="Link to Inspection intervals">#</a>
</h2>

This can be useful when section sharing is common. The interface should provide a sufficiently large interactive target and should not make the heading difficult to read. A visible “Copy link” control may be clearer than an unexplained hash symbol, but it requires additional scripting and careful status feedback.

Not every article needs visible heading permalinks. A table of contents and stable heading IDs may provide enough navigation without adding interface controls.

Common anchor link problems

The target ID does not exist

If href="#cost" is present but no element has id="cost", the link cannot reach its intended destination. This commonly occurs after a heading or template has been edited.

Multiple elements use the same ID

An ID must be unique within the page. Duplicate IDs can cause ambiguous navigation and interfere with labels, scripts, styles, and accessibility relationships.

The CMS changes automatically generated IDs

Some publishing systems generate heading IDs from visible heading text. Editing the heading may then change the fragment URL and break previously shared links. Important destinations are more durable when their IDs can be assigned and preserved intentionally.

The destination is hidden behind a fixed header

Use appropriate spacing or scroll-margin-top, then test the page at common viewport sizes.

JavaScript replaces native link behavior

A clickable <div> or button controlled entirely by JavaScript does not automatically provide the semantics and browser behavior of an HTML link. Use an anchor element when the action navigates to a URL or document location.

Smooth scrolling ignores user preferences

Animated scrolling can help some people understand movement through the page, but it may be uncomfortable for others. If smooth scrolling is used, respect the user’s reduced-motion preference:

@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

Smooth scrolling is optional. Immediate navigation is a complete and often preferable default.

The table of contents is larger than the article needs

Anchor navigation should reduce effort, not add another layer of complexity. A short page with three compact sections may not need a table of contents. Add in-page navigation when the document’s length, complexity, or likely use makes it genuinely helpful.

Fragment changes are confused with separate pages

Traditional fragments generally identify locations within one resource rather than independent indexable pages. Section fragments ordinarily do not belong as separate entries in an XML sitemap, and they should not be treated as substitutes for separate pages when a topic requires its own complete document.

Applications that use hash-based client-side routing are a separate architectural case. In those systems, the fragment may control application state rather than identify a conventional document section.

Maintaining stable fragment identifiers

A useful fragment URL may be saved in bookmarks, cited in another article, included in documentation, or shared in email. Changing its target ID can quietly break those pathways even when the page itself still exists.

For durable anchor links:

• choose descriptive IDs rather than temporary labels;
• keep IDs unique and reasonably concise;
• avoid changing an established ID only because a heading was lightly edited;
• check incoming and internal links before removing an old target;
• test links after editing headings or moving content;
• verify keyboard behavior and visible focus states; and
• check that sticky headers do not conceal the destination.

If a section is renamed substantially, the old ID can sometimes be retained for continuity. When a section is moved to another page, there is no universal server-side redirect mechanism for a fragment alone because fragments are normally handled by the browser. Maintaining a small compatibility target or updating known links may be necessary.

This is one reason anchor links, jump links, and fragment identifiers belong within document engineering rather than being treated as decorative navigation. Their value comes from the relationship they preserve among structure, accessibility, retrieval, and long-term reference.