Accessible by default: one design system for three campuses

Bozeman, Billings and Northern each needed to look like themselves, without three codebases and without relying on editors to remember the accessibility rules.

At a glance

The problem. The old CMS depended on editors, whose main job isn't web content, to remember their accessibility training, while letting them nest snippets, skip heading levels and, for some, edit source code, so published pages across three campuses were inconsistent and often inaccessible.

What I did. As the Design Engineer on MSU's web team, I researched the problem, designed the components in Figma, built the frontend, and shaped the editing experience so accessibility is built in instead of remembered.

Role: Design Engineer
Team: 7-person web team at MSU Web & Digital Communications, with stakeholders at Billings and Northern
Responsibilities: Research, Figma component design, CSS architecture, frontend build, editor experience
Scale: 3 campuses, 1,800 users, built to serve 800+ sites, research across 500+ university websites
Stack: Statamic, Laravel, Antlers, PHP, Figma, CSS custom properties
Timeline: 2024 to present. Core build largely complete, first pages live (including About and Student Life), migration not started.

The problem: accessibility depended on memory

Editors could nest snippets, such as an accordion inside an accordion, and break heading order, with nothing stopping them before they published. Some could also edit source code and change or delete the templates their sites relied on.

The safety net was accessibility training that editors had to remember, and that fades fast when your main job isn't web content. The system never helped editors fit inside the WCAG rules, and the visitors using those pages paid for it.

Three campuses added a second constraint. Bozeman, Billings and Northern each have their own colors, typography and priorities, and a seven-person team can't maintain three codebases.

Research: let evidence set the limits

I analyzed 500+ university websites and inventoried what was on the current MSU site, which shaped the system's strategy.

Analytics set specific limits. Microsoft Clarity showed accordion headlines near 200 characters with zero clicks in the past year, so the new accordion caps headlines at 80, with a live character counter and a validation rule that enforces it.

Microsoft Clarity click heatmap of an accordion on the old admissions page, where the longest question has no clicks — Clarity click heatmap of an old accordion. The longest question gets no clicks while the shorter ones around it do.

I also researched accessible HTML and CSS for every set, so each component meets WCAG 2.2 AA before an editor touches it.

The approach: make the rules hard to break

I built the rules into what editors can do instead of asking them to remember. The component library took about a year in Figma.

Constrained sets, not free-form snippets. Every option in the Add Set picker is a designed pattern with its own fields and limits. There is no custom HTML.
Structure decided up front. Each set supports a few intro layouts, and sets without h3 content skip the h2, so no page has a heading with nothing under it.
Limits from data. The accordion headline cap is the clearest case.
No source code access. Campuses configure their look through an override file and their content through sets, so there is no raw HTML and no template to delete.
Documented for adoption. I wrote documentation for components, usage standards, accessibility requirements and design tokens, in partnership with product, engineering and marketing.

The Add Set picker in the Statamic control panel, listing Content Block, Card Grid, Card List, Call to Action, Content Panel, Stats, Accordion and FAQ Grid — The Add Set picker. Every option is a designed pattern, and there is no custom HTML at the bottom of the list.

The architecture: identity in one file, structure in another

Every campus uses the same class names and the same variable names, all pointing back to a single base file. Campus A decides what its blue is. Campus B decides what its blue is. The system only knows there is a blue.

Diagram: an environment variable picks one of three campus CSS files (bozeman, billings, northern), each overriding values in a shared base stylesheet — Three campus files over one base.

Base styles load first, so a campus override changes values without ever editing the base. One environment variable picks the campus theme, with no code changes and no separate builds The same accordion, retinted by one value:

/* base/accordion.css, shared by every campus */
.accordion { border-color: var(--brand); }

/* campus/northern.css, Northern only */
:root { --brand: #7A2D3C; }

The same Accordion page on Bozeman, Billings and Northern: one set of components, three theme files.

I also set contrast at the token level using APCA, so the palette is accessible before an editor picks anything.

The editing experience is where accessibility is won

I led the editor experience inside Statamic's control panel: how each set presents, which fields appear, and what they're called. A confusing editing interface shows up as a worse published page.

Four cards in the old CMS meant a nested table of snippet rows with a custom class column. In the new system they are a Card Grid set with named fields and a character-counted description.

The old CMS card editor: a nested table of snippet rows with header, image, icon, content, link and custom class columns — Before: four cards in the old CMS, a nested table with a custom class column.

The new Card Grid set with named fields for icon, heading, heading link and a character-counted description — After: the same cards as a Card Grid set, with named fields and a character count.

When a heading breaks the rules, the editor says so in plain language and names the fix.

A Content Block in the editor with red warnings: an h4 needs an h3 above it, and nothing appears after an h3 — Heading order, flagged right where the editor is typing.

Where campuses need different options, PHP fieldset extenders handle it. The footer call to action is one component with a campus-aware selector, so each campus sees only the options that apply to it.

Accessibility, and how I measured it

I tested the new CMS with axe-core and ran WAVE on both sites. WAVE on the old montana.edu homepage reported 1 error, 17 contrast errors and 34 alerts, an AIM score of 6.1 out of 10. On the live About page of the new site it reports 0 errors, 0 contrast errors and 11 alerts, an AIM score of 9.8 out of 10.

WAVE summaries side by side. Old montana.edu homepage: 1 error, 17 contrast errors, 34 alerts, AIM score 6.1 out of 10. New About page: 0 errors, 0 contrast errors, 11 alerts, AIM score 9.8 out of 10. — WAVE summaries: the old montana.edu homepage (left) and the live About page on the new site (right).

The alerts on the new page are mostly long alt text. The alt text field has a character limit, but an image uploaded with its own metadata keeps that text, so long alt text still gets past the limit.

Automated tools can't judge whether alt text is meaningful or a page reads well aloud, so the editing constraints cover what a tool can't see.

Where it stands

Migration of the remaining sites hasn't started, so some of this is measured and some is what the system is built to do.

Measured today: accessibility results on the new CMS and live pages, and the Clarity data behind the accordion cap.
Built to do, not yet proven at scale: one-file campus rebrands, no breakable templates for Billings and Northern, and editors staying inside the accessibility rules across 800+ sites.

Once migration starts, the real test is whether editors with no accessibility training still publish accessible pages.

What I would do differently

I assumed one campus's workflow would scale to three, and the CSS architecture had to change when it didn't. Next time I would test theming against a second campus's real needs before building the whole frontend.

The other lesson is leverage. With a ten-year-old CMS and approval layers that aren't going away, the only lever was what the system makes easy, so I put the work there.

Glossary

CMS: Content management system: the software editors use to create and publish pages without code. The new platform runs on Statamic, built on Laravel (PHP).
Snippet: A reusable content block in the old CMS. Editors could nest them and style them with custom classes.
Set: A pre-designed page section an editor adds from a picker, such as an accordion or card grid, with fixed fields and limits.
Design token: A named design value, such as a brand color, that components reference instead of hard-coding it.
Override file: A small per-campus file that sets that campus's token values without editing the shared base styles.
Fieldset extender: PHP code that adds or removes fields in a set for a given campus.
WCAG 2.2 AA: The web accessibility standard, at the level most institutions target.
APCA: A model for predicting how readable text is against its background. It is more accurate than the older WCAG 2 contrast ratio, especially for light text and thin type.