The system is built from named tokens, not a hex value per screen: il-blue and il-orange, plus il-altgeld, il-industrial, and il-storm as support. Accessibility and Themes on this page are both built from these tokens.

Marketing pushed hard for school colors: an early split near 40% Illini Orange, 40% Illini Blue, 20% everything else. This system's answer: il-blue and il-industrial carry text and links, il-orange stays reserved for fills and large accents, and il-altgeld and il-storm add the grays and neutrals that split didn't leave room for.

The Contrast Rule

Two Restricted Pairings

Il-orange on white is restricted: 3.05:1, fails normal text, passes large text and UI components. Never use it for body copy, captions, or small links. Il-altgeld on il-blue is excluded: 2.9:1, fails at every size, no exception rescues it the way large text rescues orange. The full story behind both, including the numbers, is in Case Notes.

The resolution: il-blue and il-industrial carry text and link duty; il-orange is reserved for fills, large headings, and hover/focus accents. Never use it for body text, captions, or small links, regardless of how on-brand it feels. White labels on filled-orange controls are bold and 19px, so they clear the 3:1 large-text threshold.

All Pairings, Quick Reference

How the tokens hold up on every page background in the system: a heading, body copy, link, and button on each, checked in context instead of a swatch grid.

Hover the links below, the color change is real and matches the current production token for each theme, confirmed against colors.css.

Six variants, each with a default, hover, focus, and disabled treatment, all built from the token rules in Color. "Button" describes how this looks, not what HTML element it is: most of what reads visually as a button on a university site actually navigates to a URL, which makes it a link. See Specs for the full element-choice rule.

All six, at a glance, with real hover and focus states. Try tabbing through them.

Anatomy

24px gap when two buttons sit side by side.

Element choice: <a> vs <button>

The current live toolkit ships this as two separate, deliberately distinct components: Global Button Styles (anchor) and Global Button Styles (button), rather than one component with a variant flag. <a class="ilw-button ilw-theme-blue-solid" href="/apply">Apply Now</a> and <button class="ilw-button ilw-theme-blue-solid">Submit</button> are two different components that happen to look identical.

Variants - Live States

States Reference

Hover, focus, and disabled here match the current production system, not a 2020-2023 guess. Why, and what changed, is in Case Notes.

Code, Actual Current Production Markup

Pulled directly from the live Web Toolkit Builder in July 2026.

<a href="/apply" class="ilw-button ilw-theme-blue-solid">Apply Now</a>

<button class="ilw-button ilw-theme-blue-solid">Submit</button>

// theme options: ilw-theme-blue, ilw-theme-orange, ilw-theme-blue-solid, ilw-theme-orange-solid,
//                 ilw-theme-blue-outline, ilw-theme-orange-outline, ilw-theme-blue-inverse, ilw-theme-orange-inverse
// size options:   ilw-button-small, ilw-button-large   // width (button only): ilw-width-full

• ✓Contrast: every default-state label meets 4.5:1, or is bold at 19px+ and meets the 3:1 large-text exception, as Solid Orange does.
• ✓Focus is never hover-only: the focus treatment renders on any :focus, not just :hover, so keyboard and switch-device users always see it, independent of where the pointer is.
• ✓Target size: 44px minimum height meets WCAG 2.5.5 AAA for touch and low-precision input.
• ✓Real disabled state: uses the native disabled attribute, not just a gray style, so screen readers announce it correctly.
• ✓Don't rely on color alone: hover and focus swap fill and text color and add an underline, not just a hue shift, for users with low color vision.
• ✓Element matches behavior: the <a> vs <button> choice in Specs isn't cosmetic; getting it wrong breaks right-click/open-in-new-tab or native browser history, depending on which way it's wrong.

Accessible Names, the Same Button, Many Times on One Page

Contrast and focus states cover a button standing alone. Academic sites rarely show just one button: a program-listing page repeats the same CTA on every card. Learn More, Learn More, Learn More. A sighted user tells them apart by which card they're inside. A screen reader user navigating by a buttons/links list hears the same word repeated with no card context at all.

<!-- repeated on every program card, identical accessible name -->
<a class="ilw-button" href="/programs/animal-sciences">Learn More</a>
<a class="ilw-button" href="/programs/agribusiness">Learn More</a>

<!-- visible label stays short; accessible name adds the program -->
<a class="ilw-button" href="/programs/animal-sciences">
  Learn More <span class="sr-only">about Animal Sciences</span>
</a>

WCAG 2.5.3 (Label in Name) requires the accessible name to start with or contain the visible label, which is why aria-label="Animal Sciences program details" alone would fix the screen-reader problem but break voice-control users. A real example of this exact pattern is in Case Notes.

When to Use Each Variant

• ✓Solid Blue: the one primary action on a page, like Apply Now or View Program.
• ✓Solid Orange: sparingly, for a secondary action that still needs the brand orange, like a callout inside a promotional banner.
• ✓Outline Blue: a secondary action next to a Solid Blue button, or anywhere a button needs to sit quietly instead of competing for attention.
• ✓Outline Orange: the same as Outline Blue, when the on-brand orange accent fits the page better than blue.
• ✓Outline White: dark banners or photo backgrounds, where a dark-text button would disappear.
• ✓Disabled: only when the action is temporarily unavailable and the person benefits from seeing why. If the action just doesn't apply, remove the button instead of disabling it.