Disciplines 01 · Websites

Websites

The web is where design and code meet most directly for me. I use complete concept projects to explore structure, typography, responsive behaviour, accessibility and interaction as one system.

Shape: One page, or five to eight sections. Same method either way.
Approach: Scoped before it starts, iterated as it goes, finished rather than abandoned.
Revisions: Iterated in real rounds, because a first draft is rarely the last word.
Accessibility: Built to WCAG 2.1 AA practice from the first commit, not as a pass at the end.
Source: Every build is three readable files — open, run, and inspect any of them.

01 · What this is

A website, and what that word covers here

A finished, complete site of my own design, written by hand. No template bought from a marketplace, no page builder — every one of the ten is a project I set for myself, worked through end to end.

Most of the ten builds on this site started from the same question: what would this look like done properly? A restaurant, a clinic, a SaaS product — each one a chance to work through a real problem end to end, self-set rather than assigned.

structure

Semantic HTML, read before it is seen

Information hierarchy and content that remains understandable without visual effects. Structure, design and behaviour, in that order of importance.

layout

Composition that adapts, not just shrinks

CSS Grid, Flexbox, fluid type. The columns collapse in an order I decided, and the narrowest version is designed rather than survived.

performance

The page is usable before the extras arrive

Keeping unnecessary dependencies out, loading media carefully, and understanding what the browser is actually doing.

accessibility

Every control reachable without a mouse

Focus behaviour, contrast, semantic markup, ARIA where necessary — interfaces that do not depend on animation. Walked by hand, key by key.

interaction

Navigation, forms and motion that stay usable

Accordions, galleries and forms designed to remain operable with a keyboard and with reduced-motion preferences honoured.

experimentation

Vanilla JS, and modern tooling where it earns its place

Most of the ten are hand-written HTML, CSS and JavaScript. Elsewhere on this site I also work in React, Next.js and Vue — the tool follows the question, not the other way round.

02 · What a build consists of

Three files. That is the whole delivery.

Not a metaphor and not a simplification. Every one of the ten builds in the portfolio is these three files plus its self-hosted fonts — open any of them and read the source, which is the only reason this paragraph is worth anything.

index.html structure

script.js behaviour

index.html — the content and its order. Headings that descend one level at a time, landmarks that mean what they are called, every control a real button or a real link. This is the file a screen reader reads and a search engine indexes, which is why nothing decorative is allowed to live in it.
styles.css — colour, type, spacing and easing declared once at the top as named values, then used everywhere. Change eight of them and the whole site changes mood. Where a contrast pairing is close, the measured ratio is written in the comment beside it.
script.js — written so a missing element is a no-op rather than a thrown error, and so every animation asks first whether you have told your device you want less of it. The page works with any part of this file removed.

That is the point of the number three: the next person to touch it does not need to have met me, and does not need to know a framework I happened to choose.

03 · What I test for

What's part of the build, and what I leave for another project

Both columns are the same size on purpose. Knowing where a build's edges are is as much a design decision as anything inside them.

Part of the build

Art direction made for the project, not chosen from a set of five.
Copy written to fit the design, not dropped in afterward as filler.
Every page operable from the keyboard alone, and tested that way by hand.
Motion that stops when the visitor's device says it should.
A performance budget set at the start and measured again at the end.
Forms with real labels, and errors announced rather than only coloured red.
Structure ready for a second language, even where none exists yet.
Full source, readable end to end.
Real iteration, not a first draft called final.

Outside this exploration

Original photography — where a build needs it, it's sourced or licensed separately.
Full copywriting from scratch, as opposed to structuring and fitting existing text.
Translation into another language.
Third-party integrations — a booking system, a CRM, a payment provider — each its own exploration.
Ongoing content changes once a build is finished.
Search optimisation as a discipline of its own.
Domain and hosting costs, and any paid font or API.
Any claim about rankings, traffic or conversion. These are concept builds, not measured campaigns.

04 · The questions

Answered rather than dodged

Can a site like this be edited without touching code?

Not by default, and I'd rather say that plainly than dodge it. A hand-built site ships as files, so changing a sentence means editing a file.

There's a real answer worth exploring: an editing layer over the same static build, so named parts of a site become editable in a browser without touching code. It's its own small system — an editor, a login, a deploy step — three more moving parts worth understanding on their own terms.

Why hand-write three files instead of using a framework?

Because the constraint is the point. Plain HTML, CSS and JavaScript force every decision to be visible — there's no abstraction hiding what a page actually does.

It also means anyone, including a future version of me, can open the files and read exactly what they say. No dependency to update, no build step to break, nothing standing between the source and the browser reading it.

How do you know a build is actually accessible?

By checking, which takes about ninety seconds and needs no special tooling. Put the mouse down, press Tab, and watch where the outline goes.

The standard here is built to WCAG 2.1 AA practice — a description of how the work is done, not a badge, because a badge isn't an audit. What I can offer instead is a measurement of this site, with its date and method attached, so it's checkable rather than taken on faith.

Measured on this site, 10 August 2026
axe‑core: 0 violations across 23 routes × 2 viewports
keyboard: 0 of 1,526 tab stops with no visible focus indicator
Every stop walked with real key presses, the active element read back after each.

05 · The work

Three of the ten, picked for range

All ten are self-initiated, all ten are live, and every one has a write-up saying what it set out to do and what fought back. These three are here because they look nothing like each other. If one happens to be your industry, that is a coincidence rather than the reason it is on this page.