This document describes an approach that content authors can use to provide improved ease of navigation to website visitors, particularly those facing accessibility barriers. It introduces the concept of "Discoverable Destinations", which are standardized machine readable names for common page types that User Agents can query to present navigation options in an accessible and consistent manner.
The approach uses HTML <link> elements with standardized rel attribute values to signpost common destinations such as help pages, accessibility statements, and login pages. This enables User Agents, assistive technologies, and AI agents to reliably discover and navigate to these destinations across different websites.
Introduction
Web sites can contain a huge array of varied and engaging content.
This content, and the means of navigating around it, can be presented in
almost any way, which makes for tailored and compelling experiences.
However, whilst there are several conventions when it comes to
navigation, this variability can pose challenges to certain people, and
user agents acting on their behalf.
This best practices document aims to address the challenge of making sites more
easily navigable for both people (particularly those facing
accessibility barriers) and machines. It does this by standardising
machine-readable names for common page types. User Agents can then query
as to which destinations are supported on a given site (or page of that
site), and present this information in an appropriate way for the
user.
The User Agent, or a User Agent extension, could provide an interface
to allow the user to: view supported common pages using a method, and
terminology, that is clear to them; and to request to visit common
destination pages directly.
Motivating Use Cases
Supporting people facing cognitive accessibility barriers in
navigating sites.
This includes mechanisms that can support clear signposting
within a User Agent to "standard" or "common" areas of sites that users
wish to visit, such as "log in", "products", or the site's accessibility
statement.
This also includes supporting users and accessibility auditors in
quickly discovering the accessibility statement for a site.
Allowing UAs, or other machines, acting on behalf of users to
also find common areas of sites.
Out of scope
Specifying the contents of well-known pages, nor the schema of
any data to be found in one of the common areas of the site, when they
are accessed by machines.
Specifying the way in which supported well-known pages are
displayed to the user.
Specifying the interface within the UA (or UA extension) by which
the user can navigate to supported well-known pages.
Though detailed UI design is out of scope, a proof of concept user interface for enumerating a site's discoverable destinations is shown below.
Example UI, via a browser extension running on a custom shopping site
products (for the site's main product section's
landing page)
search (intended for a dedicated search page; a search
landmark region would be used on any page that contains a search
form)
Technical requirements
Any approach that addresses these user needs must provide the
following.
A way to represent each discoverable destination proposed
above.
A mechanism for discovering all discoverable destinations supported
by a site. This mechanism is to be used when a UA first visits a site on behalf of the
user. In order to do this efficiently, it must be possible to make this
query in a single HTTP request. The results would be available to the
user via the UI of the UA.
A way to denote the scope of any particular site (or
sub-site).
A procedure for visiting a discoverable destination directly (when
the user activates the interface in the UA).
A mechanism by which a discoverable destination would be updated
(by the content author).
Means to identify when a link on a page takes the user to a
sub-page of a discoverable destination page. E.g. a link to the "help on
logging in" page (as opposed to the main "help" section landing page,
which is where the discoverable destination alone would take the
user).
Means to demarcate an element on the destination page that
provides the destination content.
A way to indicate the kind of content that the
destination provides. For example, people with cognitive disabilities may need to
get help from, or chat to, a human, over the phone, rather than a
chatbot, or sending an email.
The last of these requirements, indicating the kind of
content or support, is currently an open question, not addressed by the
proposed approach below, but may be addressed in a future iteration of
this approach, or by a future WAI-Adapt TF project.
The "discoverable destinations" approach
This involves using the <link> element, and custom
rel attribute values, to signpost discoverable destinations
on a site.
The discoverable destination namespace
All possible discoverable destinations will be registered as
rel attribute values.
accessibility-statement
change-password
help
log-in
products
search
Enumerating discoverable destinations
On the site's home page, the destinations supported by the site would
be indicated via <link> elements. For example:
This will provide an overview of the available destinations.
All destinations need to be repeated on all pages of the site.
(This is one reason why the URLs in the example begin with
/).
Defining a site
Because all destinations are repeated on all pages of a site, if we
move to a sub-site, the sub-site will expose all destinations on all of
its pages, and thus the UA/AT will be able to present the correct
destinations for the sub-site.
Visiting a discoverable destination directly
The user selects the discoverable destination in the UI of their
UA.
The corresponding URL is loaded.
Updating a discoverable destination
The content author would need to ensure that the
<link> elements sent are correct. In practice this
would most likely be managed by the CMS powering the site, which could
take the repetition out of the authoring process.
Expressing when a link points to part of a discoverable destination
When an in-page (anchor, <a>) link points to a
page that is a sub-page of a discoverable destination (such as the "help
on logging in" page, rather than the "help" home page), this can be
indicated by adding a rel value to the anchor.
Demarcating destination content
As discoverable destinations are normal links, they can make use of fragments to point to certain elements on the destination page.
The content/UA/AT can then use this information (and the knowledge that the navigation was via the Discoverable Destination UI) to render the destination page in an appropriate way for the user. This may involve:
Highlighting the specific relevant part of the page.
Removing other elements from the rendering of the page to reduce cognitive load.
Providing additional context or guidance based on the destination type.
Open Questions
The sub-sections here should be promoted, and match the numbers of the corresponding technical requirements above. Some requirements should be added to that list in order to provide the justification for those requirements being addressed in this section.
Indicating the kind of
content
As above, COGA need that we are not yet addressing.
Discoverability and
repetition
This is a work-in-progress
Demarcating sub-sites
This is a work-in-progress
Semantically
UI-wise
Agentic AI and Machine Navigation
Agentic AI systems are autonomous software agents that can plan, reason, and execute complex tasks on behalf of users. These systems represent a significant development in automation, capable of understanding natural language requests and breaking them down into actionable steps. For users with disabilities, these AI agents can serve as powerful assistive technologies, helping navigate digital environments and complete tasks that might otherwise be challenging.
From Human Accessibility to Machine Assisted Accessibility
Discoverable Destinations were designed to help humans with accessibility needs find important pages quickly. This same semantic approach also serves AI agents acting as assistive technologies. What helps humans with disabilities navigate also enables machines to provide consistent assistance.
The semantic identifiers provided by Discoverable Destinations work consistently across all compliant websites. Rather than AI agents searching for contact information using fragile selectors such as "find the element with class .contact-info", they can use semantic identifiers to navigate to the contact destination. This approach transforms brittle technical navigation into reliable semantic discovery.
Illustrative Use Cases
The following examples illustrate how AI agents might use Discoverable Destinations to assist users with disabilities:
An accessibility compliance assistant could help a disability rights advocate check accessibility statements across multiple partner websites. The AI agent would systematically discover and analyse accessibility-statement destinations across all sites, ensuring comprehensive accessibility monitoring without the need for manual navigation.
A cognitive support assistant could help a user with cognitive disabilities who is facing issues with multiple service providers. The AI agent would discover contact and help destinations across different platforms, presenting a comprehensive support landscape in a simplified, consistent format.
A motor accessibility aid could assist a user with motor impairments who wishes to update their profile information across platforms but finds repeated navigation challenging. The AI agent would navigate to relevant destinations on each site, then guide the user through the updates with full context and control, reducing the physical navigation burden.
These scenarios share a common pattern: AI agents handle the discovery and navigation complexity, while humans maintain control over sensitive decisions and actions.
Scope and Limitations
Discoverable Destinations are well suited for content discovery, such as finding specific types of pages including help, contact, and accessibility statements. They also support information extraction from destination pages and provide consistent navigation patterns across different websites.
However, certain tasks require additional solutions beyond Discoverable Destinations:
Complex actions involving workflows such as password changes, account modifications, or transaction processing may vary dramatically between sites. Discoverable Destinations can navigate to relevant areas, but the actual workflows may require additional tools or human involvement.
Authenticated operations requiring user specific authentication and authorisation need specialised protocols and often human involvement for security.
For complex scenarios, a layered approach works best: Discoverable Destinations provide navigation to relevant areas, APIs are used where available for sensitive operations, and human oversight is included for sensitive or complex tasks.
Integration Patterns
AI agents can integrate with Discoverable Destinations through various architectural patterns. Two primary models are relevant for deploying tools that leverage semantic destinations:
A server side model where tools run independently of the user's browser and make direct HTTP requests to target websites. This approach is suitable for public data retrieval but has no access to the user's browser session or authentication state.
A browser based model, such as WebMCP, where the web page itself can expose tools to AI agents. This approach operates within the user's existing session with full access to authentication state and page context, making it better suited for authenticated operations and personalised content.
The choice of integration pattern depends on the specific use case. For scenarios involving authenticated operations, personalised content, or complex user specific workflows, a browser based approach is recommended. For public data scenarios, a server side approach may be sufficient.
Requesting Additional Destination Types
This section is a placeholder. The process for requesting standardisation of additional destination types is to be defined.
The set of standardised destination types may evolve over time as new common navigation patterns emerge. Parties interested in proposing additional destination types should consider the following:
The proposed destination type should address a common navigation need that is shared across many websites.
The destination type should provide clear accessibility benefits, particularly for users facing cognitive accessibility barriers.
The destination type should be sufficiently general to apply across different industries and website types.
The formal governance process for proposing, reviewing, and adding new destination types to the standard is under development.
Privacy and Security Considerations
The Discoverable Destinations approach has been designed with privacy and security in mind.
Privacy Considerations
Discoverable Destinations use standard HTML <link> elements that are already part of web pages. No additional user data is collected or transmitted beyond normal web browsing. The approach does not introduce any new tracking mechanisms, as User Agents discover destinations by parsing existing page content. Users retain full control over when and how they navigate to discovered destinations through the User Agent interface.
Security Considerations
All navigation uses standard HTTP and HTTPS requests subject to normal browser security policies. Destinations are typically within the same origin, which reduces cross origin security concerns. Content authors are responsible for ensuring that the href values in their <link> elements point to legitimate, secure pages.
Considerations for AI Agent Integration
When AI agents use Discoverable Destinations on behalf of users, certain considerations apply. For sensitive operations such as authentication or account changes, human oversight should be maintained. Discoverable Destinations are designed for navigation and content discovery, not for executing complex authenticated operations. The primary approach for sensitive operations should be human in the loop, where AI agents navigate to relevant pages using semantic destinations, extract and present available options to users, then hand control to humans for actual execution.
