The CMS

The editing experience was the part of this project I cared about most, because it's the part that affects the most people. Our team of seven is responsible for a system that over 1,200 content editors will use every year, many of them with limited web experience, some of them logging in once a year to update a page and not much else. The CMS couldn't assume expertise. It had to make the right thing the easy thing.

Statamic gave us the tools to do that. Blueprints, fieldsets, and a form-based content model meant we could control exactly what editors see, in what order, with what constraints. The visual design of the control panel connects directly to the output on the front end, so editors aren't guessing what a "content highlight" looks like. They can see it.

The accessibility architecture was the most technically interesting part of this. On the current website, an editor can create a heading hierarchy error, a broken link label, or an empty heading without any warning. The system doesn't stop them because the system doesn't know any better. We decided early on that the new system should know better.

My job was to research every WCAG violation that was realistically possible inside a rich text or bard field, then spec out what the system should catch and how it should communicate that to an editor. A developer built the actual checks, but the logic came from that research: heading order enforcement, meaningful link text validation, empty heading prevention. The goal was to make it structurally difficult to publish an inaccessible page, not just to document that you shouldn't.

The result is visible in the WAVE scores. Current MSU homepage: 14 contrast errors, 34 alerts, AIM score 6.7 out of 10. New system on a content-heavy showcase page: 0 errors, 0 contrast errors, 1 alert (being resolved before launch), AIM score 10 out of 10. That gap isn't from policing editors after the fact. It's from building a system where accessible output is the path of least resistance.