This section needs some work.
-Our proposed "discoverable destinations" come from work done by the User research that the WAI-Adapt TF inherited from COGA.
An illustrative set of proposed discoverable destinations is as -follows...
+follows.accessibility-statement (for the site's accessibility
@@ -112,6 +109,25 @@ User research
form)
The following use cases illustrate the kinds of navigation challenges that Discoverable Destinations are intended to address.
+ +An accessibility auditor is reviewing a portfolio of websites on behalf of a disability rights organization. Each site structures its accessibility statement differently, some link to it from the footer, others from the main navigation, and others only from an internal policy page. The auditor spends considerable time on each site searching for the relevant page before the audit can begin.
+With Discoverable Destinations, a User Agent or assistive technology can immediately locate the accessibility-statement destination on any compliant site and present a direct link to the auditor, regardless of where the site has chosen to place it in its navigation structure.
A user with a cognitive disability wants to log in to their account on a retail website. The site's primary navigation does not label the login entry point in a way the user recognises, and the page layout makes it difficult to locate. The user's browser extension, which presents a simplified navigation panel, cannot automatically locate the login page because no standard signposting exists.
+With Discoverable Destinations, the browser extension can read the log-in destination from the page's <head> and present a clearly labelled button in its simplified interface, giving the user a direct and reliable path to the page they need.
A user with motor impairments uses an AI-powered assistive agent to help navigate websites and complete common tasks. The user asks the agent to "find the help page for my internet provider." Without semantic signposting, the agent must attempt to locate the help page by guessing at URL structures or parsing navigation HTML, which is brittle and may fail when the site is updated.
+With Discoverable Destinations, the agent can query the help destination directly from the site's page headers, retrieve the correct URL in a single step, and navigate the user there reliably, regardless of how the site has structured its navigation menus.
A password manager application wants to help users navigate directly to the password change page on any website, consistent with the Well-Known URL for Changing Passwords specification. On many sites, the password change page is buried several levels deep within account settings, and its location varies across sites.
+With Discoverable Destinations, the password manager can use the change-password destination to locate the correct page directly, without the need for site-specific integration or manual maintenance of URL mappings.
Any approach that addresses these user needs must provide the following.
@@ -228,27 +244,40 @@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.
-The current approach identifies where a destination is located but does not convey what kind of support or content it provides. This distinction is important for users with cognitive disabilities who may require a specific mode of interaction. For example, a user may need to speak to a human being over the phone rather than engage with a chatbot or submit a form by email.
+Several possible approaches are under consideration:
+Extending the rel value vocabulary to include more specific destination subtypes (for example, help-human or help-chat). This approach is specific and directly discoverable by User Agents, but risks becoming unwieldy as the number of content kinds grows.
Using an additional attribute or a companion <meta> element alongside the <link> element to annotate the kind of support offered, keeping the destination identifier stable.
Deferring this concern to the destination page itself, where structured data markup could describe the available support types. This places the burden on page authors and requires User Agents to fetch and parse the destination page before presenting options to the user.
As above, COGA need that we are not yet addressing.
+We still need to find reasonable resolution for above problem. We may also delay the resolution till next iteration
This is a work-in-progress
-The current approach requires all <link> destination elements to be repeated in the <head> of every page on the site. This has the advantage of simplicity, a User Agent can read the available destinations from the current page without making any additional HTTP requests. However, it introduces authoring overhead and requires every page to be updated whenever a destination URL changes.
The Task Force has agreed to adopt the <link> element approach for the first iteration of this specification. This decision reflects that the approach has a low entry barrier, as it builds on existing, well-understood HTML mechanisms that content authors and User Agents already support, requires no new infrastructure, and can be incrementally adopted. The per-page repetition, while an authoring overhead, can be managed in practice through CMS templates.
The following questions remain open for future iterations:
+Should there be a single canonical discovery endpoint, such as a well-known URI, that a User Agent can consult once per origin rather than reading destinations from each individual page? This would reduce per-page overhead but would require an additional HTTP request on first visit to a site.
If a centralized endpoint is provided, how should per-page and per-origin destination declarations be reconciled when they differ? For instance, a sub-site may legitimately need to override destinations declared at the root level.
What caching expectations should apply to destination declarations, both in the per-page <link> approach and in any centralized discovery document?
The Linksets format offers one possible path toward centralized discovery and may be revisited in a subsequent iteration.
+This is a work-in-progress
-A site hosted at a single origin may contain functionally distinct sub-sites. For example, a hotel website might host a main booking section, a restaurant section, and a gym section, each with its own set of relevant destinations.
+The <link> element approach handles this naturally. Because every page carries its own <link> declarations, each sub-site simply includes the destinations relevant to that sub-site on its pages. The User Agent always reads the destinations from the current page, so:
Semantically
UI-wise
Scope is implicit and automatic. When the user is on a restaurant sub-site page, that page's <link> elements define the applicable destinations. No boundary detection or URL prefix matching is required.
Overriding destinations is straightforward. A sub-site page that declares a different contact destination than the root site will naturally present the sub-site's destination to the User Agent, since the User Agent always uses the current page's declarations.
No additional authoring mechanism is needed. Content authors control sub-site scoping by controlling which <link> elements appear on each set of pages, typically managed through their CMS templates.
The Task Force considers sub-site demarcation to be resolved by the per-page <link> approach.
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 set of standardised destination types may evolve over time as new common navigation patterns emerge and as new user needs are identified. The current set of destinations reflects the priorities identified by the COGA TF at the time of publication, but it is not exhaustive.
+Parties interested in proposing additional destination types should consider the following criteria:
The proposed destination type should address a common navigation need that is shared across many websites.
The proposed destination type should address a common navigation need that is shared across many websites, not a need specific to a particular industry or platform.
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 destination type should be sufficiently general to apply across different industries and website types. Where a need is specific to a particular domain, it may be more appropriate to address it through domain-specific conventions rather than a standardised destination type.
The destination type should not duplicate an existing destination type or overlap significantly with one already in the standard.
The formal governance process for proposing, reviewing, and adding new destination types to the standard is under development.
+The formal governance process for proposing, reviewing, and adding new destination types to the standard is under development. Interested parties are encouraged to raise proposals as issues in the WAI-Adapt GitHub repository for discussion by the Task Force.
For agentic AI use cases specifically, additional destination types may be beneficial in contexts where AI agents need reliable access to common site areas that are not yet covered by the current set. For example, account settings pages and accessibility preference pages. Proposals for such additions should follow the criteria above and be raised with the Task Force for review.
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.
A User Agent that exposes a destination list to the user reveals which discoverable destinations a site supports. Since this information is already present in the page's <head> and therefore visible to any party that loads the page, no new information is disclosed by processing or presenting it.
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.
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 under their control.
User Agents and extensions that implement a discoverable destination interface should validate that destination URLs share the same origin as the page from which they were discovered. Where a cross-origin destination URL is present, User Agents should present the full URL to the user before navigating, to support informed decision-making.
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.
+When AI agents use Discoverable Destinations on behalf of users, the same privacy and security considerations apply as for human users. Additionally, agents should not aggregate or store destination metadata in ways that could be used to profile users' browsing patterns across sites. 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.