WayneUI

The design system for Wayne State University applications built by C&IT and DSOE. One set of brand tokens, one set of components, and four ways to consume them without any of the four drifting from the others.

Version 2.0 is a hard break from 1.x. There is no compatibility shim, and the two cannot run side by side. If you are upgrading, start at Upgrading from 1.x.

Pick the path you are already on

All four render the same class names, the same ARIA and the same data attributes. Which one you use is a question about your build pipeline, not about what you get. Vue is one of the four either way; which guide you want depends on whether Laravel is already wiring the chrome's data for you.

You are building	Start here
A static site, no build step	Static HTML
PHP with no framework	Raw PHP
Laravel with Blade	Laravel and Blade
Laravel with Inertia and Vue	Laravel, Inertia and Vue
Vue with no Laravel	Vue, no Laravel

The reason they match is not that four teams remembered to keep them matching. The two static templates in apps/examples/static-html/ are extracted into contract/markup-contract.json, and every package tests against that file. A template change that is not carried across every path fails the build, and so does a code sample on this site that uses a class name nothing defines.

Two templates

Both are application templates. The difference is who can reach them, and therefore how much university identity they carry.

What differs	Internal	Publicly reachable
Chrome	One compact bar, shield only	Official wayne.edu masthead and footer
Width	Full bleed	1200px
Application search	Inline field in the bar	Expanding, because the masthead has its own
Stylesheet	wayne-ui.css	wayne-ui-official.css

The official masthead and footer are @waynestate/wsuheader and @waynestate/wsufooter, consumed as npm dependencies. They are the same components wayne.edu renders and they are not ours to fork or restyle.

Two component libraries, one set of tokens

WayneUI does not ship a copy of its components per framework. WSU components sit on one layer of semantic --wsu-* custom properties, and daisyUI and shadcn-vue are thin adapters over that layer:

primitives   --wsu-green-*, --wsu-gold-*, --wsu-neutral-*
semantics    --wsu-brand, --wsu-surface, --wsu-text, --wsu-focus-ring
adapters     daisyUI @plugin theme   |   shadcn-vue :root and .dark

So <button class="btn btn-primary"> and <Button> come out the same green from the same source. Use daisyUI if you want Tailwind without a JavaScript pipeline, shadcn-vue if you already have Vite. Neither is required: the WSU chrome works against wayne-ui.css alone. See Theming.

The accessibility bar

WCAG 2.2 Level AA is the floor and AAA wherever the brand palette reaches it. It is a build gate rather than a goal. Nothing in the pipeline is allow_failure:

• Every declared color pairing is contrast tested in both themes, and the measured ratios are on the Tokens page
• axe-core runs over every component and both example applications, at three viewport widths, in both themes
• Reflow at 320px, 200% and 400% zoom, and a text-spacing override are all tested
• Lighthouse accessibility has to score 100

Accessibility says what each gate checks and what to do when one of them stops you.

What is where

packages/tokens     brand tokens, emitted as CSS, SCSS, JS and JSON
packages/css        semantic layer, daisyUI and shadcn adapters, the Lucide
                    sprite and the WSU marks, prebuilt bundles
packages/vue        Vue 3 components
packages/registry   shadcn-vue registry, served from /r
php/src             Laravel provider, Blade components, breadcrumbs, Inertia
apps/docs           this site
apps/examples       one working page per consumer path

Color and type come from the WSU Identity Style Guide. Primary green is PMS 561c #0C5449 and primary gold is PMS 1225c #FFCC33. If the guide changes, change the tokens, never a component.