Simons Institute

A site that had grown for a decade without ever being restructured — and that was being asked to do seven jobs at once.

Event registration, a scientific archive, a media aggregator, a directory of visiting researchers, an application platform, a collaboration space, and a CMS the staff could actually run. None of those was optional, and no one of them could be allowed to define the whole interface. Underneath was the harder problem: the institute's audiences ranged from world-leading complexity theorists to a member of the public who has never heard the phrase "theory of computing". The same page had to be legible to both without patronising either.

Strip away the pages and what's left is time: programs containing workshops containing days containing talks containing people.

The old site made you hunt for a day's schedule and gave up entirely on finding a recording. So the front end had to make that hierarchy walkable in both directions — from a program down to a single talk, and from a talk back up to the program that produced it. The homepage's upcoming-events tabs and the interactive calendar are the two entry points. The calendar is a JS library rendering into someone else's markup, which is exactly the case where accessibility gets quietly lost: date cells that aren't buttons, filters that change results with no announcement, focus that vanishes when a month re-renders. Each of those had to be handled deliberately rather than trusted to the library.

A public university site is held to a standard, not an aspiration. I ran SortSite across the site and then tested by hand — and the hand pass is where the real findings are.

SortSite is good at the sweep: crawling thousands of pages, catching the mechanical failures at scale, and telling you which templates are repeat offenders rather than which single page is broken. On a site this size that's the only way to know whether a fix actually landed everywhere it needed to. Then keyboard and screen reader, by hand, on the components that matter: the calendar, the schedule tabs, the accordions, the application forms, the main menu. No crawler can tell you that a schedule is technically perfect and still impossible to follow by ear. The palette was part of it too. Brand colours were simplified and text colours darkened so that body copy cleared AA rather than nearly clearing it — a decision made in the design phase precisely so it wouldn't become a retrofit.

How I Tested

SortSite — full-site crawl, template-level patterns, proof a fix propagated

Keyboard only — calendar, tabs, accordions, forms, menu; watching where focus goes

Screen reader — the same flows by ear, especially collapsed and swapped content

Contrast checks — every text-on-colour pairing in the palette, before build

Zoom and reflow — 200% and 400%, where dense pages fall apart first

Automation finds the violations. Manual testing finds the experiences. You need both, and I don't trust one tool on its own.