Bio Link Page Builder

When a profile leaves room for only one address, the usual answer is a page whose only job is to hold more of them: a name, a line about who you are, and a short stack of buttons. It is one of the smallest useful pages there is, and that smallness is the point of this essay.

A page that small does not need a service behind it. It needs a heading, a list and a few rules about colour and size. Everything else that usually comes with it, the account, the dashboard, the click counter, the script that reports each visit, is optional, and most of it serves whoever runs the service rather than the person whose name is at the top.

What the page actually is

Strip the habit away and a link page is a document with a title, one heading and a list of hyperlinks. The HTML Standard has an element for each part. The heading is h1. The list is a ul inside a nav, which marks it as the page’s navigation. Each entry is an a element whose words say where it goes. That is the whole structure, and every browser already knows what to do with it.

Two attributes on the root element finish the job. The HTML Standard says the lang attribute takes a valid BCP 47 language tag, so a reader’s software can pick the right voice and the right hyphenation. The dir attribute has three states, left to right, right to left and auto, and auto lets each piece of typed text take its direction from its own first strong letter. A page written in Arabic with an English shop name in one button needs both, and both cost a few bytes.

Then there is the question of where the page lives. The IndieWeb community describes a practice it calls POSSE, publish on your own site, syndicate elsewhere. Its wiki lists the reasons plainly: less dependence on third parties, a direct chain of ownership that no outside terms of service can break, and addresses that stay on your own domain. A link page is the smallest possible case of that idea. If the page is a file you hold, moving it is copying it, and nothing about it depends on a company deciding to keep a feature.

That is why a single static file is enough. It has no database to back up, no login to lose and no software to update. You can keep it in the same folder as your tax return, put it on any web host that serves files, and replace it by uploading a new copy. The builder on this page makes that file and stops there. It does not host anything and it does not make a short link, because both would put a service back between you and your readers.

Who has to be able to use it

A page of buttons is only useful if every visitor can read the words, find the button and press it. The Web Content Accessibility Guidelines, version 2.2, turn each of those into a number or a test, and a link page is simple enough to meet all of them without effort.

Start with contrast. WCAG defines the relative luminance of a colour from its red, green and blue values, and the contrast ratio of two colours as the lighter luminance plus 0.05, divided by the darker plus 0.05. The ratio runs from 1:1 to 21:1: two identical colours score the first, black on white the second. Success criterion 1.4.3, at level AA, asks for at least 4.5:1 for ordinary text and 3:1 for large text. The explanation published with the criterion says why the number is 4.5: it compensates for the contrast loss that comes with vision of about 20/40, which it describes as commonly reported typical acuity for people of roughly 80.

Here is a worked example you can repeat in the tool. Choose your own two colours, white for the background and #777777 for the text. The tool computes 4.47:1 and refuses to save, because the pair sits just under the line. Change the text to #767676 and the ratio becomes 4.54:1, which passes. The tool uses the two colours the other way round for buttons and swaps them in dark mode, so one ratio covers every pair.

One step of grey separates a page some readers cannot read from one they can. You would never see the difference by eye, which is why the number is computed rather than judged.

The arithmetic is easy to check against published figures. The W3C test rule for minimum contrast gives #333 on white as 12.6:1 and plain black on white as 21:1, and the formula above gives the same values to the first decimal. When a check can be repeated from a public example, nobody has to take the tool on trust.

Size comes next. WCAG 2.2 has two criteria about the size of the thing you press. At level AA, a target must be at least 24 by 24 CSS pixels or keep enough space around it. At level AAA it asks for 44 by 44 CSS pixels, and the guidance gives the reason in one line: some people cannot tap small objects. A link page has no reason to aim lower than the stricter figure, so every button in the generated file is at least 52 pixels tall and as wide as the column.

Focus matters for anyone who moves through a page with a keyboard. Success criterion 2.4.7 asks that a keyboard operable interface has a mode where the focus indicator is visible, and the guidance puts the stakes bluntly: without it, sighted keyboard users cannot operate the page. The generated file draws a solid ring three pixels wide outside each button in the text colour, so the ring has the same contrast as the words.

A profile picture is the last piece. The W3C images tutorial says a picture that only decorates should carry an empty alt attribute, so screen readers skip it, and warns that leaving the attribute out entirely can make some screen readers read out the file name instead. A picture that tells the visitor something, such as a face they will recognise, needs a short text alternative. The builder asks for one or for a tick that says the picture is decorative, and will not save the file until one of the two is set.

Why the file carries no script

A link page has nothing to compute. Every behaviour it needs, following a link, switching between light and dark, honouring a request for less motion, is already built into the browser. Media Queries Level 5 defines a prefers-color-scheme feature that reflects whether the reader wants a light or a dark page, and a prefers-reduced-motion feature for readers who have asked their system to minimise non-essential motion. A style sheet can answer both. The generated page switches colours by itself and drops its one small hover movement when asked, without a line of script.

Leaving script out also makes the page easy to lock. Content Security Policy Level 3 lets a document deliver a policy through a meta element, and the generated file uses that to say: load nothing from anywhere, allow one style sheet identified by its SHA-256 digest, and allow pictures only from inside the file. The digest is the algorithm from the Secure Hash Standard, FIPS 180-4, applied to the exact text of the style element. The specification warns that a policy in a meta element does not apply to content that comes before it, so the policy sits directly after the character set declaration.

The same discipline applies to every address the visitor types. The URL Standard tells a browser to remove tabs and line breaks from an address before reading its scheme, which is how a string that looks broken on screen can still turn into a script address. The builder therefore strips those characters first, accepts only https, plain http with a warning, mailto and tel, and refuses everything else, javascript and data addresses included. Each address is rebuilt from checked parts and every piece of typed text is escaped, so a name with angle brackets in it stays a name.

New tabs are off unless you switch them on. The W3C technique on new windows says it is generally better not to open them, since they can disorient people. When the switch is on, each link also gets the noopener and noreferrer keywords, which the HTML Standard defines as giving the new page no handle on the one that opened it and sending no referrer.

Putting one file on the web

The profile picture is the only part that would normally be a second file, and it does not have to be. RFC 2397 defines the data address, which carries a small file inside the page itself, and it is honest about the limit: the scheme is only useful for short values. Base64, as RFC 4648 describes it, costs 4 characters per 3 bytes, because it writes each group of three bytes as four characters, so a 12,000 byte picture adds 16,000 characters to the page. The builder crops the picture square, encodes a fresh JPEG of 128, 192 or 256 pixels from the pixels alone, shows both sizes and warns above its own line of 50 KB of text.

What the method cannot do is just as plain. The builder never opens your links, so it cannot tell you whether an address works. It cannot test how any particular browser or app shows the page; the preview is this browser drawing the file. It checks contrast for colours, not for text placed over a photograph, because the page never puts text over the picture.

It cannot count visits either, and neither can the file it writes. That is the trade for a page with no tracker, and for most people it is the right one.

Hosting one file is the easy part. Any service or server that can deliver a static file will do, and so will a folder on a site you already run. The example in the tool uses names under example.org and example.net, which RFC 2606 reserves for documentation so they can never belong to anyone. Replace them with your own addresses, save the file, upload it, and the page is yours for as long as you keep a copy.