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.
| 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.1 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.1 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.
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.1 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 the power of a live design system: consistency and accessibility at scale.
Learn more
Explore the live component library, tokens, and code snippets. Or see how Oakland's content governance meets the RFP requirements.