This document describes an approach that content authors can use to provide improved ease of navigation to website visitors.
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—e.g. "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, an proof-of-concept UI for
enumerating a site's discoverable destinations is depicted 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 approch that would solve 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—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—e.g. 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.
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.
