Accessible Animated Timeline Component

The brief

A designer had put together a timeline graphic tracing the company’s history — six milestones, each a date, a heading and a line of body copy, strung along a gradient rail. “Add this to the page” was the whole brief.

From pixels to a semantic list

The graphic on its own is a paragraph’s worth of dates, headings and body copy flattened into pixels: none of it selectable, searchable, or readable by a screen reader, and on a phone it would simply shrink until it stopped being legible. Since the only real fix was re-typing the copy anyway, that happened first and alone, before any visual styling — a plain <ul> of milestones, each a heading with its date and a line of body text. No layout decisions yet, just structure a browser, a screen reader and a search engine could all parse correctly.

That decision up front did double duty: it’s what made the page accessible, and it’s what made everything that follows possible. Once each milestone is its own element in the DOM, CSS and JavaScript can address it individually in ways a single image never allows.

Rebuilding the design in CSS

With the structure in place, the original graphic became a spec to rebuild rather than an image to embed. CSS Grid lays each milestone into date / connector / content areas; pseudo-elements draw the little arrows pointing from each date to its text, and the circular date marker itself. A single modifier class flips alternating entries to the other side of the rail, reproducing the graphic’s zig-zag layout with no extra markup.

The color progression carried over too: a CSS custom property defaults to orange and gets overridden to red, then pink, on the later entries — so the markers and connectors shift color down the line exactly as they did in the original gradient rail, driven by two class names instead of hand-picked pixel colors.

An animation falls out of it

This is where having real elements instead of flat pixels started paying off in a way that wasn’t part of the brief. Because each milestone was now its own list item, it could be targeted and transitioned independently — something no raster image could ever do. A small script reveals the milestones one at a time as the page loads, each one un-collapsing a beat after the last. The effect reads as the timeline drawing itself in — a detail that fell out of the markup decision almost for free, not something storyboarded up front.

What the image couldn’t do

The original graphic’s biggest weakness only shows up on a phone: a wide horizontal timeline, scaled to fit a narrow screen, stops being readable long before it stops being visible. An image has exactly one layout; shrink it and the text goes with it.

Real markup doesn’t have that limit. Two breakpoints change the timeline’s structure, not just its size: on the smallest screens it’s a plain stacked list; in the middle range (shown above) it’s a stacked list with the date centered in a circle; only at wide, desktop widths does it become the full left-to-right rail. The content stays legible at every size because the layout actually changes to fit it.

Why it ended up a block

The site this lives on is built on the WordPress block editor, so a chunk of static content wrapped around a page template doesn’t belong the way a real block does — this became a custom Gutenberg block with its own styles and script, insertable like any other.

That also solved a problem that had nothing to do with WordPress: extensibility. The original graphic lived in a design file somewhere, and adding a seventh milestone down the road would have meant tracking that file down and re-exporting a new image. As HTML, the timeline just takes another list item.