One of the problems with using the link element in our web documents, is that it currently has limited potential. Firstly, because there is no opportunity for supplying anything other than “global” scope for the link relationship (i.e., the link rel applies to the whole document – next, previous, help, glossary etc…), and secondly, because these link relationships aren’t very well exposed to users via their user agents.

Changing the user agents to expose the link relationship functionality to more users would be the responsibility of the browser makers, so we won’t deal with that here (although we do hope they would view what we are proposing as a good reason to do so…). Where we can perhaps make a difference is in applying scope to link relationships, and providing the metadata so that the browsers can successfully extract the relationships

It’s really just metadata

In discussing alternate formats on the Dublin Core Accessibility Working Group List, I found the following in the HTML 4 spec about using the link element for providing metadata:

Note. When a property specified by a META element takes a value that is a URI, some authors prefer to specify the meta data via the LINK element. Thus, the following meta data declaration:

<META name=”DC.identifier” content=”http://www.ietf.org/rfc/rfc1866.txt”>
might also be written:
<LINK rel=”DC.identifier” type=”text/plain” href=”http://www.ietf.org/rfc/rfc1866.txt”>

This sparked more thought about the use of Link relationships for providing more metadata to documents, and how it might be more useful.

Changing the Scope of the Link Relationship

Currently the link element has standard attributes that are allowed in HTML/XHTML. At this time, the relationship applies to the entire document in which the link rel is embedded.

In my Missing Link article, I hinted at ways to modify the scope of a link element by adding the for attribute. Please note that this is currently unsupported and is only one possible suggestion, however, I feel it would be a worthwhile addition to HTML. This would allow us to define a link relationship to an individual item within a document rather than the whole document itself. Essentially, this would mean that a link rel with no for attribute would have document level scope and a link rel with a for attribute would apply only to the element that has that id attribute.

In addition to examples of using the for attribute to provide autodiscovery of alternate content, and for providing context sensitive help for forms, there are a few other possible uses for link relationships, either with or without the added for attribute:

Link Rel as an Alternate to Skip Navigation links

Many sites use invisible skip navigation links, or visible skip navigation links to allow for users to quickly access the different content areas of their sites. We like the functionality behind this, but would love to see a more semantic means for indicating this relationship — after all, indicating the start of the content of a page, or any other sections, really is metadata isn’t it?

Many sites use link rel for navigation and it might be a suitable replacement for Skip Navigation links, or Jump to Content links.

The head section of a web site could contain:


<link rel="home" href="/" title="home" />
<link rel="copyright" href="/policies/" />
<link rel="bookmark" title="Site Wide Navigation" href="#main-nav" />
<link rel="bookmark" title="Section Navigation" href="#sec-nav" />
<link rel="bookmark" title="Page Content" href="#content" />


These items are available via Mozilla’s Site Navigation bar, as well as that of Opera. Unfortunately, this functionality isn’t readily exposed in Internet Explorer. The bookmark link definitions already exist, so this is possible today. The only problem with this, is that it is essentially “invisible” to users, as most don’t know that site navigation bars even exist, nor are they easy to access using keyboard navigation. (more on this later)

Further, with a standardized set of bookmarks to indicate navigation, content and other important sections of a document via the link element and by Allowing Keystroke access to Link Relationships, we would allow users quick keystroke access to these sections based on their own preferences, eliminating the need to provide visible or hidden skip navigation links.

Link Relationships for providing inline Glossary

The Glossary link relationship is already defined as a valid Link relationship type. Its use could be expanded to include the for attribute to provide more specificity:


<link rel="glossary" href="/terms.html" />
<link rel="glossary" for="tornado" href="/terms.html#tornado" />
<link rel="glossary" for="hurricane" href="/terms.html#hurricane" />


The first link would provide a glossary for all terms in that document, where the second would provide a definition for one specific item, corresponding to the following code in the document:

With the relationship properly defined, it should be possible for the user agent to provide access to the term in the glossary in a variety of ways:

• via a context-menu (right click, or Cmd click etc…)
• via direct import of the contents into a type of “tool tip”, but without having to populate the title attribute to create the tool tip
• via a DOM script that auto-appends a link to the node in which the term appears
• by reading the glossaries definition through a screen reader based on preferences
• by display of a Mozilla/Gecko sidebar displaying definitions for all terms associated with glossary entries via this method

The above example of a glossary only look at the existence of a static html version of the glossary. It isn’t that much of a stretch to see that the link relationships could point to a script that returns the definition for the term that is appended as part of the querystring by searching a database, or extracting the contents of a text node within an XML document, perhaps in RDF or other appropriate format.

Update, Dec 12: The above example using a felt a bit contrived from the beginning, however a recent thread on the WAI list, leads us to be believe that this technique might be easily applied to identifying further explanations for acronyms:


<link rel="glossary" href="/glossary.php" />
<link rel="glossary" for="wai" href="/glossary.php?wai" />
<link rel="glossary" for="w3c" href="/glossary.php?w3c" />


Corresponding to the following in the body of the document (markup for creating the hyperlinks removed for clarity):


<p>For further detail please refer to the Resources
section of the <acronym id="wai"
title="Web Accessibility Initiative">WAI</acronym> of the
<acronym id="w3c" title="World Wide Web Consortium">W3C</acronym></p>


In the above, glossary.php could parse through a well formed XML document to extract the appropriate data and present it to the user based on some arbitrary user agent preference.

One potential problem would exist with the expansion of all acronyms in a document, as we would only be able to have one instance of an acronym with the specific id as it must be unique. However, surely there would be other ways around this issue.

In general, HTML defined accesskeys are being used to provide the ability to quickly invoke the links in a site that go to specific destinations including such examples as a search page, a contact page or the home page of a site. In some cases they are being used to provide an alternative mechanism to “skip navigation” or “skip to content”. In principle, this functionality is a worthwhile end goal as it has the potential to make the web more usable for all.

Continue reading Accesskey Conflicts