Content Governance
How the design system stays consistent and accessible across a decentralized university — guardrails, not guesswork.
Who can do what
Editor roles and responsibilities
Every content editor at Oakland is assigned a role. Permissions and guardrails are built into the CMS — the system enforces these rules so a well-intentioned edit cannot accidentally break accessibility or layout.
At Oakland's real scale, that means roughly 150 active content editors inside 250–300 total CMS accounts, spread across academic and administrative units. Publishing stays decentralized (every college and department keeps moving its own content) while governance stays centralized through role-based permissions, not a single bottlenecked web team.
Contributor: drafts and edits copy inside existing pages; cannot publish live.
Editor: publishes within one department, on governed templates.
Section Lead: publishes and approves component use across a college or division.
Administrator: manages the design system itself: components, tokens, and access.
Concept note: these four tiers illustrate the shape of Oakland's real role-based permission model, low access to high. In practice they take the specific, named forms in the table below, plus a lighter-touch tier that accounts for the gap between the ~150 active editors and the fuller 250–300 CMS user base.
| Role | Can do | Guardrail |
|---|---|---|
| Department Editor | Edit page text, update program descriptions, upload approved images, schedule announcements | Locked to pre-built components; cannot change layout, heading levels, or colors |
| College Web Lead | Manage all pages in a college; approve component instances; escalate design requests to Central Web Team | Cannot add new component types; cannot change the design system tokens |
| Central Web Team | Add new components to the system; audit accessibility; update design tokens and type scale | All changes run through automated Axe testing and WCAG 2.2 AA validation before merge |
| Accessibility Reviewer | Audit all content; flag missing alt text, low-contrast text, or accessibility issues; require fixes before publish | Can block publication; cannot edit or override flagged content directly |
This role model ensures that every editor contributes within their expertise, and the system prevents common mistakes before they happen.
Built-in rules
Formatting guardrails
Editors work within locked constraints that prevent inconsistency at the root. These are not suggestions — they are enforced by the TerminalFour CMS.
Rule: Headings follow strict logical order. No skipped levels (e.g., no jumping from H2 to H4).
Why: Screen reader users rely on heading hierarchy to navigate. Skipped levels create disorientation.
In TerminalFour: The CMS locks available heading styles per content zone. A Department Editor sees only "Page heading" (H1) + "Section heading" (H2) + "Subsection" (H3). Arbitrary levels are unavailable.
Rule: Only seven pre-defined font sizes and weights. No arbitrary sizing.
Sizes: Small label (12px), body text (16px), callout (18px), section head (26px), page head (33px), display (42px), hero (54px).
Families: Spectral (serif, headings only) and Libre Franklin (sans, body + UI).
In TerminalFour: Text styles are pre-built Shared Content. When an editor pastes copy and applies "Body text," the browser receives the locked font-family, size, and line-height automatically. No override possible.
Rule: Space between elements is locked to an eight-step scale: 4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px.
Why: Consistent rhythm makes the site feel coherent and professional, even across 275+ pages.
In TerminalFour: Components have fixed padding and margin in their CSS. Editors cannot add extra space or collapse margins. The layout always respects the scale.
Rule: Editors never see a color picker. They pick from a palette of eight named tokens.
Tokens: Carillon (dark), OU Gold (accent), Bright Gold (CTA), Parchment (light bg), Oak (secondary), Text (Ink), Soft text (Ink-soft), Neutral (Ink-muted).
Why: Ensures WCAG AA contrast compliance. All token pairs have been tested for readability.
In TerminalFour: A button's color option shows only "Primary CTA," "Secondary," "Ghost," or "Disabled" — never a hex input. The system applies the vetted token automatically.
Rule: Every image requires alt text before upload. The CMS will not save an image without it.
Quality gate: Alt text must be ≥ 10 characters and describe the image content (not "Image 1" or "Photo").
In TerminalFour: The asset uploader shows a required field. The save button is disabled until alt text is provided and passes basic length validation. An Accessibility Reviewer can audit flagged images on publish.
Rule: The publishing workflow runs a contrast check. Low-contrast text blocks publication.
Standard: WCAG 2.2 Level AA — 4.5:1 for normal text, 3:1 for large text (18px+).
In TerminalFour: Before a page can be published, an automated pre-flight scan checks all text-on-background pairs. If a violation is found, the system highlights the issue and blocks publish until corrected.
Scalability guardrails
Structural limits
These limits prevent common mistakes at scale — left-hand navigation bloat, component overload, and layout breakage.
Rule: A page can contain no more than 12 distinct component instances (cards, buttons, accordions, forms, etc.).
Why: More components = slower load, longer scroll, decision paralysis. Pages with 15+ components scatter the user's focus.
In TerminalFour: As an editor adds components to a page, a counter displays "5/12 components used." When the limit is reached, the add-component button disables and prompts a rethink of the page purpose.
Rule: Editors cannot break layout or accessibility by editing text. Text fields have character limits; rich-text areas auto-truncate overflows; link fields validate URL format.
Examples: A program-card title field is capped at 60 characters (enforced in the CMS). A button label maxes at 25 characters. A metadata field (e.g., "College name") is read-only once set.
In TerminalFour: Field types are configured with tight constraints. A Department Editor cannot paste a 200-word essay into a card title and watch the card break on mobile. The field rejects input past the limit with a helpful message.
Rule: Images are locked to specific aspect ratios per component. A hero image must be 16:9; an arched-photo frame must be 3:4; card thumbnails must be 1:1.
Why: Locked ratios prevent layout jank and ensure photos render consistently across all OU sites.
In TerminalFour: The image uploader crops and validates the ratio. If an editor tries to upload a 4:3 image to a 16:9 hero zone, the system auto-crops to the correct ratio and warns the editor before saving.
Getting thousands of pages here
How content moves
Oakland's site holds thousands of pages across academic and administrative units. Moving that much content into a governed system is not a single cutover. It follows a migration strategy and a playbook, then the people who know the content best do the moving, with support the whole way.
-
Strategy
The vendor sets a migration strategy and playbook built for university scale: a plan sized to thousands of pages across dozens of units, not a generic checklist.
-
Priority inventory
Every page is inventoried and ranked. High-value content (admissions, programs, top-traffic pages) moves first. Bulk archives follow on a longer runway, off the critical path.
-
Owners migrate, on governed templates
Content owners, working with their departments and University Communications and Marketing, migrate their own pages onto governed templates, with the vendor alongside for support, not standing in for them.
-
Review and rewrite where it earns it
Migration is not always copy-and-paste. Some pages are reviewed and rewritten along the way, so outdated content doesn't simply move house in its old form.
-
Governance keeps it strong
Once a page is live, the roles and guardrails on this page take over: the same system that gets content in also keeps it consistent and accessible for as long as it stands.
System-wide consistency
How a change propagates
The design system is the source of truth. When the Central Web Team updates a component or token once, every Oakland University site inherits the change automatically.
Example: Button color update
- The Central Web Team reviews the OU Gold token and decides to adjust it from #877148 to #8B7355 for warmer legibility.
- They update the token definition in the design system stylesheet — one line of code changed.
- The TerminalFour component library re-compiles.
- Within minutes, every page using the "OU Gold" token — buttons, links, borders, rules — displays the new color.
- No College Web Lead or Department Editor had to touch a single page. Consistency scales.
Example: Accessibility fix
- An audit discovers that the "Callout" component's line-height is too tight for dyslexic readers (1.4 instead of 1.6).
- The Central Web Team updates the component CSS. The fix is tested against Axe and WCAG 2.2 AA.
- The update is merged and published to the live design system.
- All 275+ pages with a Callout component instantly render with the improved spacing.
- Zero manual fixes needed. Accessibility improves across the university in one deploy.
This is why governance exists. Left alone, most university websites diminish over time; the design erodes page by page, edit by edit, unit by unit. A live design system runs the other way: every fix and every new component makes every page that uses it stronger, all at once. The site shouldn't decay as it grows. It should get stronger the longer it runs.
Learn more
Explore the live component library, tokens, and code snippets. Or see how Oakland's content governance keeps every page on standard.