The Link

1. Hypertext before the web

The idea of a link is older than the web, older than the Internet, and older than the digital computer as most people picture it. Each of the systems below added something the web kept, and one of them insisted on something the web left out.

Bush's memex, 1945

In July 1945, Vannevar Bush, who had directed the United States' wartime research effort, published an essay in The Atlantic called As We May Think. His concern was that scientists were producing far more research than anyone could find or read, and that libraries organized everything by index, alphabetically or by subject, while the mind works by association. He imagined a desk-sized machine, the memex, that stored a person's books, papers and notes on microfilm and let them tie any two items together. A chain of such ties he called a trail, and a trail could be named, followed later, and given to a colleague.

The memex was never built, and its technology was mechanical, but the idea was the one that matters here: a reader can connect two documents, and anyone can follow the connection later. Bush's essay was widely read, and the people who built the first hypertext systems two decades later cited it as their starting point.

Nelson's hypertext and Xanadu

Ted Nelson coined the word hypertext. Its first publication is his paper for the Association for Computing Machinery's national conference in 1965, which defined it as written or pictorial material interconnected in a way too complex to present on paper. (Nelson has said he used the word earlier, from 1963, and a student newspaper reported a talk using it in early 1965; the ACM paper is the usual citation.) Nelson also coined hypermedia.

Nelson's own system, Project Xanadu, begun in 1960 and still unfinished, was far more ambitious than the web. In Xanadu every link would work in both directions, so a document would know about every document that linked to it. Quotations would be transcluded, included by reference to the original rather than copied, so a quotation could always be traced to its source and its author could be paid. And because the system tracked every link and every version, a link could not break. Nelson has been a critic of the web ever since it appeared, on exactly these grounds.

Engelbart's demonstration, 1968

On December 9, 1968, Douglas Engelbart and his team from the Stanford Research Institute gave a 90-minute live demonstration of their oN-Line System, NLS, at the Fall Joint Computer Conference in San Francisco. It is now called "the mother of all demos", because so much of later computing appeared in it at once: the mouse, windows, shared editing between two sites, video conferencing, and links. Engelbart moved through documents by selecting a link and jumping to what it pointed at, the interaction that every web page now offers. NLS was a working hypertext system more than twenty years before the web.

Hypertext in the 1980s

By the 1980s hypertext was an academic field with its own conferences, and a few products. Apple's HyperCard, released in 1987 and shipped free with every Macintosh, put linked "stacks" of cards in front of millions of people, most of whom never heard the word hypertext. These systems were mostly closed: links ran between documents on one computer, or inside one product's files, and an author could keep every link correct because the author controlled both ends.

2. The web's one-way link

Tim Berners-Lee, a software engineer at CERN, the European particle physics laboratory, had written a small hypertext program for himself in 1980 called ENQUIRE, to keep track of the people, programs and machines at the lab. In March 1989 he wrote a proposal for a larger system, titled Information Management: A Proposal, and in November 1990 he and Robert Cailliau proposed it formally as the WorldWideWeb project. By the end of 1990 the first web server and browser were running at CERN, on a NeXT computer, at info.cern.ch. In August 1991 Berners-Lee announced the software on Internet newsgroups, and anyone could set up a server of their own.

Very little of the web was new. Hypertext existed; the Internet existed; documents were already exchanged over networks. What Berners-Lee did was join them with three small standards, still the three on which this course rests: a way to name any document on any computer (the URL), a protocol to fetch it (HTTP), and a format for documents that contain links (HTML). The link was the part that joined the other two: an href holds a URL, and following it is an HTTP request.

Links that need no permission

The decisive choice was that a web link runs in one direction. A link is stored only in the document that contains it. The page it points at holds no record of it, is not told about it, and cannot refuse it. Anyone who can publish a page can link to any other page on any server in the world, and needs nobody's permission or cooperation to do it.

That is the reason the web grew as it did. A two-way system such as Xanadu has to keep both ends of every link in agreement, which means some shared database or protocol that every server joins, and a central point that everything depends on. The web needed none of that. Each server could be set up independently, by anyone, and be linked to the moment its address was known. Hypertext researchers at the time saw this as a weakness. When Berners-Lee and Cailliau submitted a paper on the web to the Hypertext '91 conference in San Antonio that December, it was turned down, and they showed the web as a demonstration instead.

The price: links that break

The same choice has a cost that every web user knows. Because the page at the other end does not know it is linked to, it can move, change or vanish, and nothing warns the pages that link to it. The link stays in the source page, pointing at nothing, and following it ends in a 404 Not Found. This is link rot, and it is not a bug in the web but the price of its design: a web where links cannot break would need every server to coordinate with every other, and would not have grown past a few institutions.

What the web offers instead of unbreakable links are conventions and tools. HTTP's redirects let a page that moves leave a forwarding address, so that old links still arrive; What a click does shows them. Berners-Lee's own advice, that good addresses should never change, is the subject of Cool URIs. Web archives keep copies of pages that would otherwise be lost. And the one-way link has another side effect that later became a business: since no page knows what links to it, finding out requires crawling the whole web, which is what search engines do. Counting the links that point at a page, as Google's PageRank did, turned out to be a good measure of what people found useful. Links you can trust returns to link rot and how to resist it.

The web's first interaction

For the web's first years, following a link was nearly the only thing a reader could do on a page. Early HTML had one other interactive element, <isindex>, a single search box. Forms arrived later, and became part of the standard with HTML 2.0 in 1995; scripting came after that. Each later interaction was built on the link's model. A form submission is a request for a URL, and a form using method="get" is a link whose query the reader fills in, as The form and its request shows. A single-page application that updates the page with script still has to pretend, through the address bar and the back button, that the reader is following links. When people say the web is a web of documents, the link is the reason.

3. The a element and href

A link in HTML is an <a> element with an href attribute. The name a stands for anchor, from the first versions of HTML, where the same element did two jobs: <a href> was the start of a link, and <a name> marked a place a link could point at. href stands for hypertext reference: the URL of the destination.

Everything in the element's content is the link: here, the words "schedule page". The browser draws that content in the link color, usually underlined, and makes it something a person can click, tap, focus and follow. The value of href can be any URL: absolute, relative to the page, a fragment of the page, or a scheme such as mailto:. How that value becomes a full address is the subject of Where a link goes.

An <a href> gets a great deal from the browser, none of which the author writes:

• It is focusable, in document order, with the Tab key, and shows a focus indicator.
• It is activated by a click, a tap, the Enter key, a screen reader's command, or a voice command.
• It has the role link in the accessibility tree, so a screen reader announces it as a link and lists it in its list of links.
• It joins the browser's link handling: open in a new tab with a middle click or Ctrl-click, copy the address, save the target, drag the link to the address bar or to another application.
• Its destination shows in the status bar when the pointer rests on it, before anyone commits to following it.
• It matches the CSS selectors :link, :visited and :any-link, so a page can style links, and visited links, as a group.
• Search engines and other crawlers follow it, which is how they find pages.
• Following it adds an entry to the tab's history, so the back button undoes it.

That list is the whole argument of section 5, in short: every item on it is missing from anything that is not a real link.

The other attributes

The a element has a handful of other attributes, each covered on the page where it matters. target, download, ping and referrerpolicy change what following the link does, and belong to What a click does. rel describes the relationship between this page and the destination, and hreflang and type describe the destination; those are in Links between documents. The old name attribute is obsolete: a link points at an element's id instead, as Where a link goes explains.

An a without href

An <a> with no href is valid HTML, but it is not a link. The HTML standard calls it a placeholder link: it represents a place where a link might otherwise have been, consisting of only its contents. It has none of the behavior listed above. It cannot be focused, it is not announced as a link, it does not match :link or :any-link, and clicking it does nothing. In the accessibility tree it is a generic element, like a <span>.

The placeholder has two honest uses. The first is a navigation menu that marks the current page: the menu keeps the same markup on every page, and on the current page the item simply has no href, since a link to the page you are on goes nowhere. The second is a link that is not available yet, such as a "Next" link on the last page of a list.

The aria-current="page" attribute tells a screen reader which item is the current page, which otherwise only the visual style would show. Some sites prefer to keep the current item a real link, with href and aria-current, so that it stays in the tab order and a person can still copy its address; both are reasonable. What is not reasonable is the opposite mistake: an <a> written without href by accident, or on purpose with a click handler, and styled to look like a link. It looks like one and does nothing for a keyboard or a screen reader. The CSS selector a:not([href]) finds every one on a page, which makes a useful check during development.

4. What may go inside a link

Every HTML element has a content model, a rule about which elements it may contain (Content models and validity teaches how to read one). A paragraph may contain only phrasing content, such as text, <em> and <img>; a list may contain only list items. The content model of <a> is unusual. The standard calls it transparent: a link may contain whatever its parent may contain, as if the link were not there. Inside a paragraph, a link may hold phrasing content. Inside a <section> or a list item, it may hold flow content: headings, paragraphs, images, whole blocks.

This was a change. In HTML 4 the a element was strictly inline, and a link around a heading and a paragraph was invalid, though browsers rendered it anyway. HTML5 made it transparent, and so made a pattern legal that sites already used everywhere: the block link, a card or a row in which everything is one click target.

Nothing interactive inside

The transparent model has an exception, and it is the important part. The standard's full rule is that an a element's content is transparent, "but there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified". A link may not contain another link, a button, a form field, a <details> element, an embedded frame, or anything made focusable with tabindex.

The reason is that a click or a key press has to mean one thing. If a button sits inside a link, a click on the button is also a click on the link, and the browser has no good answer to which one the person meant. Browsers differ on what they do, and screen readers differ on what they announce: some read the link's name with the button's text inside it, and some never reach the button at all. The pattern is common in the wild, typically a card that is a link with a "Save" or "Share" button inside it, and it is invalid and broken in the same way every time.

What the parser does with a nested link

A button inside a link is invalid, but the HTML parser builds it anyway, as written. A link inside a link is different: the parser refuses to build it. When it reaches an <a> start tag while another a element is still open, it reports an error, closes the open one, and continues. In the simplest case the result is two links side by side:

The words "after" were meant to be part of the first link and are now plain text. In a card, where the inner link sits inside a paragraph inside the outer link, the repair is stranger. The parser's rules for misnested formatting elements, which it applies to a, end the outer link before the paragraph and give the paragraph its own copy of the outer link to hold the text that came before the inner one.

The demo shows all three versions of a linked card side by side: the whole card as one link, a pattern that avoids the long name described next, and the invalid nested version, with what the browser built from it.

Block links and their names

A valid block link still has a problem, which the demo makes audible. A link's name, as section 6 explains, comes from its content, and a card link's content is everything in the card. A screen reader announces the first card in the demo as one link whose name is the heading, the description and "Linking 02 · Read more", run together. On a page of twenty cards, a person listening to the list of links hears twenty paragraphs.

The usual fix keeps the whole card clickable but makes only the heading a link, and stretches that link's clickable area over the card with a pseudo-element:

Now the link's name is the heading alone, the description is read as ordinary text, and a click anywhere on the card follows the link. The trade-off is that the pseudo-element sits on top of the card's text, so a person cannot select that text with the mouse to copy it. And the pattern has the same rule as a block link: nothing else in the card can be interactive, unless it is lifted above the stretched link with its own positioning. Use a block link when the card holds a few words; use the stretched heading link when it holds a description.

5. A link goes somewhere; a button does something

HTML has two elements that people activate: <a href> and <button>. They are not interchangeable, and the rule for choosing is short. A link goes somewhere: following it changes the URL, to another page, a part of this page, or another application. A button does something: it submits a form, opens a dialog, shows or hides content, plays a video, copies text, or changes data. If the address bar should change, it is a link. If it should not, it is a button.

The two look different by convention, links as underlined text and buttons as shaped controls, but the difference that matters is in behavior, and it is built into the browser:

The keys alone say something. People who use a keyboard learn that Space presses buttons and Enter follows links, and screen reader users hear "link" or "button" and expect each to behave as its name says. A link that opens a dialog, or a button that loads a new page, breaks an expectation the person formed on every other site.

The last row of the table matters for safety. As What a click does explains, following a link must never change anything, because browsers, crawlers and preview tools follow links without being asked. A "Delete" that is a link will eventually be followed by something that did not mean to. Anything that changes data is a button in a form that sends a POST.

Fake links and fake buttons

The common mistake is neither element: a <span> or <div> with a click handler, styled to look like one or the other. It works for the person who built it, testing with a mouse, and for nobody else. It cannot be reached with Tab, it ignores Enter and Space, it opens nothing in a new tab, it has no address to copy, and a screen reader reads it as plain text with no hint that it does anything. Making it work means adding a role, a tabindex, key handlers for the right keys, a focus style and, for a fake link, a way to open it in a new tab, which script cannot fully provide. All of that is what the real element already does.

The demo builds three actions with a real link, a real button and a fake. Try each with the keyboard and the mouse; the table at the end of the demo records what Chrome, Firefox and Safari do.

The demo's middle row has no button version, because a button cannot go somewhere without script. Its first row has one: a form with no fields and a submit button does navigate, but it cannot be opened in a new tab or copied, and it adds an empty query to the address. When the action is "go to that page", a link is the only element that does the whole job.

The javascript: anti-pattern

A link's href can hold a javascript: URL, which runs the code that follows instead of navigating. It was the way to put script behind a link in the 1990s, and it still appears in old code and copied snippets:

The first is a link with no destination. Middle-click it, or choose "Open in new tab", and nothing useful happens: depending on the browser, the click is ignored or a blank tab opens, since the code cannot run without the page it was written for. Copy its address and you copy a line of code. Screen readers announce it as a link, so the person expects to go somewhere, and some read the URL out. A site with a Content Security Policy that disallows inline script blocks javascript: URLs entirely, so the control does nothing at all; a policy like that is one of the strongest defenses against cross-site scripting, and javascript: URLs are one of the reasons sites cannot adopt it.

The href="#" anti-pattern

The second is the most common version today. href="#" is a link to the top of the current page. It makes the element focusable and gives it link styling, which is why people use it, and a click handler does the real work. When the handler forgets, or fails to load, or when its event.preventDefault() call is missing, a click scrolls the page to the top, adds # to the address and adds an entry to the history, so the back button now has to be pressed twice to leave. Opened in a new tab, it opens a second copy of the page. It is still announced as a link, and still does not answer to the Space key, which a person told it is a control will try.

Why not role="button" on a link

The third tries to fix the announcement. role="button" changes what the accessibility tree says, so a screen reader announces "button". The rules allow it, and it is still a bad trade. A role changes only the announcement, never the behavior. The element still does not respond to Space, so the author must add a key handler. It still offers "Open in new tab" and "Copy link address" in its context menu, for a URL that is #. It is still followed by crawlers and matched by link styles. It still shows the URL in the status bar. Everything the role promises, the author has to build, and everything the link brings that a button should not have, the author cannot remove.

The W3C's guidance on ARIA puts it as a first rule: if a native HTML element already has the meaning and behavior you need, use it, rather than repurposing another element and adding a role. Here the native element exists and has existed since the beginning:

It needs no href, no role, no tabindex and no key handling, and it looks however its CSS says. If it should look like a link, style it so; the reverse fix, making a link out of something that does not go anywhere, is the one that fails. The forms section covers the type attribute and a button's other jobs in The form and its request. And in the other direction, a "button" that only takes the person to another page, such as a large "Get started" on a home page, should be a link styled as a button: it goes somewhere, so people may want to open it in a new tab or copy its address.

6. Link text is the link's name

Every element that a person can operate has an accessible name: the words a screen reader speaks when it reaches the element, the words in its list of links, and the words a voice-control user says to activate it. For a link, the name comes from its content by default. The browser computes it by collecting the text inside the link, in order, along with the text alternatives of anything that is not text.

The last example is the most common failure. A link that holds only an image takes its whole name from the image's alt text, and when there is none, the link has no name. Screen readers then improvise, usually by reading the file name or the URL: "link, logo dot svg" or "link, slash". The rule for an image inside a link is that its alt describes where the link goes, not what the picture shows. A logo that links to the home page has alt="Course home", not alt="Logo with a blue shield". Images covers alternative text in general, and Links people can use covers image links.

Use aria-label sparingly

Two ARIA attributes replace the name computed from content. aria-label sets it to a string; aria-labelledby sets it to the text of other elements, named by their ids. Either one wins over the link's content completely, and the content is no longer part of the name at all.

That makes them tools for the few cases where a link has no visible text, such as an icon-only link in a toolbar, and dangerous everywhere else. A link that shows "Read more" with aria-label="Office hours article" is better for a screen reader than plain "Read more", but sighted people still see the vague version, and a voice-control user who says "click Read more" finds that nothing matches, because "Read more" is no longer part of the name. WCAG 2.5.3, Label in Name, requires that a control's name include the text it visibly shows, for exactly that reason; aria-label="Read more about office hours" would pass it, and still leaves sighted people with the vague version. And aria-label text is easy to forget when the visible text changes, and may be missed by automatic page translation. The better fix is almost always visible text that works on its own: "Office hours" instead of "Read more".

The last version keeps the visible text at the start of the name, so it still satisfies Label in Name, and keeps the extra words in the document, where translation and search find them. Whether link text makes sense on its own is the subject of Links people can use, which covers writing it well, why "click here" fails, and how to audit every link on a page out of context. The short version: since a link's text is its name, the text should name the destination.

7. What activating a link does

Everything so far has been about the element. The rest of this section is about what happens when someone uses it. In outline, when a link is activated, the browser:

1. Fires a click event, whatever the person actually did: clicked, tapped, pressed Enter or spoke a command. A script may cancel the rest.
2. Resolves the URL. The href as written, which may be relative, is combined with the document's address, or its <base>, to give one absolute URL. A fragment-only change scrolls the current page instead of loading a new one; a mailto: or tel: URL is handed to another application.
3. Makes a request. The browser sends an HTTP GET for that URL, with headers it writes itself, including where the person came from, and follows any redirects the server sends back.
4. Replaces the document with the response, in this tab or the one target names, and adds an entry to the history so the back button can return.

Each step has more to it than one line can hold. Where a link goes takes the second step: how relative URLs resolve, what <base> changes, how fragments and text fragments work, and what each scheme hands off to. What a click does takes the third and fourth: the request and its Referer header, the answers a server can give, redirects, new tabs, downloads and history. After those, Links between documents turns to links that nobody clicks, in the document's head.

8. Summary