The Web HIG
AI-native behavioral standard for the modern web.
An open, vendor-neutral standard for how web interfaces should behave — for your team, your design system, and your AI coding tools.
A behavioral standard that works alongside your existing design system.
- Not another Bootstrap
- Not another design system
- Not another WCAG wrapper
It is a rulebook and engineering contract — not a component library.
Design systems define what your UI looks like.
The Web HIG defines how it behaves.
AI-native means the standard is human-readable, machine-readable, selectively loadable, referenceable by rule ID, and enforceable by AI agents and CI — not that your site must be AI-generated. The HIG works fully without AI.
Why another standard?
The web already has HTML standards, WCAG guidelines, CSS conventions, and design systems — but there is no widely adopted, vendor-neutral behavioral contract that brings these concerns together for modern web applications and AI-assisted development.
Where this fits
| Existing approach | What it gives you | What it misses |
|---|---|---|
| Component libraries MUI, Bootstrap, shadcn/ui |
Pre-built widgets | No shared rules for error recovery, delete flows, or token discipline |
| Platform HIGs Apple, Material Design |
Polished vendor guidance | Portability across web stacks and AI tooling |
| Style guides | Colors, typography, brand | Behavior, states, performance targets, security UX |
| WCAG | Accessibility compliance | Performance, mutations, CI enforcement, AI agent rules |
The Web HIG fills that gap: a versioned, lintable standard that teams and AI coding agents can pin in any product repo — without replacing your stack.
Essential rules
Universal requirements — every page type, every feature.
- Mobile-first & responsive — layouts adapt; components use container queries
- Keyboard accessible — tab navigation works; focus is always visible
- WCAG 2.2 AA — semantic HTML, accessible names, sufficient contrast, touch targets
- Real UI states — loading, empty, error, and success are designed, not bolted on
- Design tokens — no raw hex colors outside token files
- Reduced motion — animations are functional, never required to understand the UI
- Performance — protect Core Web Vitals; avoid unnecessary JavaScript
- Security basics — no secrets in client code; PII masked; CSP configured
Full Quick Reference (98 rules): HIG-QUICK.md
One standard. Three levels.
Progressive disclosure — load only what you need. Pin HIG-QUICK instead of the 20,000-token full document.
10 governance layers
Layer 0 defines which rules apply. Layers 1–9 define the rules themselves.
Start here
Pick the path that matches how you work.
I'm a developer
Read the 98-rule Quick Reference (~5 min), then pin it in your repo.
Open HIG-QUICK.md →I'm a designer
Start with essential rules for states, tokens, accessibility, and motion.
View essential rules →I'm building with AI
Copy agent rule templates for Cursor, Copilot, or Claude Code.
Agent templates →I want to adopt the standard
Pin the contract, map your routes, wire your tools — one afternoon.
Integration guide →Try it in one afternoon
Add the HIG to an existing project without reading the entire specification.
-
Pin the contract — copy HIG-QUICK, HIG-LITE, HIG.md, rules/, and VERSION into your repo (e.g.
docs/hig/) -
Map your pages — create
docs/hig-scope.mdwith routes and page archetypes (Content, Commerce, Application, or Auth) - Wire your tools — add agent rules for Cursor, Copilot, or Claude Code
- Review and automate — use the Quick Reference in PRs; add ESLint/CI gates when ready
Built for humans and AI agents
Do not paste the entire HIG into every prompt. Pin HIG-QUICK and say: "Follow The Web HIG Quick Reference."
- Developer
- HIG
- AI agent
- Code
- Validation
- CI
For developers & designers
Shared standards for UX, accessibility, tokens, and performance. Written for humans first — AI sections are optional extras.
For AI coding agents
Token-efficient three-layer model. Stable rule IDs agents can cite. YAML guardrails for Cursor, Copilot, and Claude Code.
Architecture
Tell an AI: "Follow The Web HIG Quick Reference." — pin HIG-QUICK instead of the 20,000-token full document.
THE WEB HIG
│
┌──────────────────┼──────────────────┐
│ │ │
HIG-QUICK.md HIG-LITE.md HIG.md
Layer 1 Layer 2 Layer 3
~5 minutes Practical Full
98 rules documentation specification
│ │
│ rules/ + framework/
│ archetype packs
└──────────────────┴──► All rules map to HIG.md
- Resolve archetype
- HIG-QUICK
- HIG-LITE + pack
- Topic module
- HIG.md (if needed)
Topic loading: rules/manifest.yaml · Session preamble: HIG-CORE.md
Repository structure
web-hig/
├── HIG-QUICK.md Layer 1 — Quick Reference (98 rules, ~5 min)
├── HIG-LITE.md Layer 2 — practical guide with rule IDs
├── HIG-CORE.md Session preamble — philosophy + archetypes
├── HIG.md Layer 3 — complete specification
├── VERSION Single version pin
├── rules/
│ ├── manifest.yaml Machine-readable load triggers
│ ├── INDEX.md Rule ID registry
│ ├── applicability.md Layer 0 matrix
│ ├── accessibility.md … 16 topic modules
│ └── archetypes/ content, commerce, application, auth
├── framework/ React, Next, Vue, Nuxt, Astro
├── examples/agent-rules/ Cursor, Claude, Copilot templates
├── scripts/validate-hig.mjs Contract validation
└── INTEGRATION.md Product repo adoption guide
Page archetypes
Identify your page type first. Each archetype pack lists which topic modules to preload. Accessibility, tokens, performance, and security are universal — never optional.
| Archetype | Examples | Default modules | Pack |
|---|---|---|---|
| Content / Marketing | Landing pages, blogs, docs | 7 | content.md |
| Commerce | Product pages, cart, checkout | 13 | commerce.md |
| Application | Dashboards, admin tools, workflows | 15 | application.md |
| Auth / Account | Login, signup, settings | 12 | auth.md |
16 topic modules · 4 archetypes · Framework adapters: React, Next.js, Vue, Nuxt, Astro — framework/
Rule ID system
Every enforceable requirement has a stable ID for code review, AI citations, and future lint rules.
| Prefix | Domain | Example |
|---|---|---|
HIG-A11Y-* | Accessibility | HIG-A11Y-003 — native HTML over ARIA |
HIG-TOK-* | Design tokens | HIG-TOK-001 — no raw hex outside token files |
HIG-MOT-* | Motion | HIG-MOT-001 — no transition: all |
HIG-CQ-* | Container queries | HIG-CQ-001 — component layout via @container |
HIG-SSR-* | Server rendering | HIG-SSR-001 — default to server rendering |
HIG-MUT-* | Mutations | HIG-MUT-001 — no optimistic destructive confirmation |
HIG-SEC-* | Security | HIG-SEC-002 — CSP configured |
HIG-SIM-001 | Simplicity | Prefer simplest compliant implementation |
Full registry: rules/INDEX.md
Integration into your product
Adopt gradually — most teams start in one afternoon.
-
Pin the contract — copy HIG-QUICK, HIG-LITE, HIG.md, VERSION, rules/, framework/ into
docs/hig/ -
Map your routes — create
docs/hig-scope.mdwith page types per route - Add agent rules — copy templates for Cursor, Claude Code, or Copilot
- PR checklist — use essential rules for human review until linters exist
- Lint & CI — automate Layer 7 rules and Layer 8 gates when ready
Full guide: INTEGRATION.md
Validation & CI
Keep VERSION, manifest, and modules synchronized when upgrading pins.
npm run validate
# or: node scripts/validate-hig.mjs
Validates version sync, file references, archetype packs, and rule ID consistency. Runs automatically on every PR via GitHub Actions.
Governance & specification
The Web HIG is published as an open standard: rationale, semver, changelog, conformance profiles, and a path to machine-readable rules.
| Document | Purpose |
|---|---|
| RATIONALE.md | Why the standard exists; goals and non-goals |
| SPECIFICATION.md | Index to normative layers and modules |
| PROFILES.md | Quick Reference vs Practical vs Full conformance |
| VERSIONING.md | Semver and pinning in product repos |
| CHANGELOG.md | Keep a Changelog release history |
| ROADMAP.md | Contract and tooling direction |
| MACHINE_READABLE.md | Manifest, registry roadmap, linters |
| ADOPTERS.md | Projects pinning the contract |
All documents
| Document | Purpose |
|---|---|
| HIG-QUICK.md | Quick Reference — read first (~5 min, 98 rules) |
| HIG-LITE.md | Practical guide with rule IDs and checklists (Layer 2) |
| HIG.md | Complete normative specification |
| HIG-CORE.md | Philosophy, vocabulary, archetypes |
| INTEGRATION.md | Product repo adoption guide |
| examples/ | Scope templates, agent rules, adoption walkthrough |
| rules/INDEX.md | Topic index & rule ID registry |
| RELEASE_NOTES.md | Adoption-focused release notes |
| CONTRIBUTING.md | Proposing spec changes |
Glossary
| Term | Meaning |
|---|---|
| Archetype | Page category (marketing, shop, app, login) that determines required rules |
| Design token | Named design value (e.g. --color-primary) instead of hard-coded values |
| HIG-QUICK | 98-rule Quick Reference — default context for daily work and AI agents |
| HIG-LITE | Practical guide with rule IDs — Layer 2 documentation |
| Rule ID | Stable code like HIG-A11Y-003 identifying one specific requirement |
| WCAG 2.2 AA | International accessibility standard — our compliance target |
| Core Web Vitals | Google metrics: load speed (LCP), responsiveness (INP), stability (CLS) |
| Progressive loading | Opening only the docs needed for the current task |
FAQ
Is this a component library?
No. It is a rulebook and engineering contract, not a component library. You keep your design system, framework, and components; the HIG defines how they should work together.
Do I need to follow every rule?
Follow rules for your page type and feature. Accessibility, tokens, performance, and security are always required. Use archetype packs to see what's mandatory for your case.
I'm not using AI — is this still for me?
Yes. The HIG is written for human developers and designers first. AI-related sections are optional extras for teams using Cursor, Copilot, or Claude Code.
How is this different from a style guide?
A style guide covers look and feel. This also covers behavior: error handling, delete flows, performance targets, accessibility compliance, and security requirements.
Can I customize rules for my product?
Documented exceptions are allowed with justification. Security, accessibility, and data-protection rules cannot be skipped.