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.

Accessibility Performance States Forms Security Responsive UX AI enforcement
1 Understand the standard

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.

WCAG
Accessibility
Design systems
Visual consistency
Frameworks
Implementation
The Web HIG
Behavioral contract

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.

The Web HIG
Scope
L0
Governance
L1–L9
UX IA Tokens State
Accessibility
Performance
AI enforcement
QA
Security
0 Scope
1 UX
2 IA
3 Tokens
4 State
5 A11y
6 Perf
7 AI
8 QA
9 Sec
View all 10 layers in detail
0

Applicability & Scope

Archetype matrix — mandatory vs optional rules per page type

Decide what's required before you build — a blog post doesn't need checkout rules.

1

UX Principles

Motion, micro-animations, spatial ergonomics, reduced motion

Functional feedback on click; no decorative animation; respect "reduce motion."

2

Information Architecture

Document fundamentals, navigation, forms, states, search, i18n

Page titles, error messages, empty states, URL-as-state, form validation.

3

Visual & Design Tokens

Three-tier tokens, container queries, data density

Named design values; components adapt to container size, not just screen width.

4

Interaction & State

Server rendering, mutations, optimistic UI, offline, data protection

How save/delete works; undo for destructive actions; loading during server calls.

5

Accessibility

WCAG 2.2 AA, keyboard patterns, focus, target sizes

Works for keyboard, screen readers, and touch — always required.

6

Performance

Core Web Vitals — LCP, INP, CLS; lab vs field metrics

Fast load, responsive interactions, no layout jumping.

7

AI & Agent Enforcement

Rule IDs, severity, YAML guardrails for coding agents

Machine-readable rules agents and linters can enforce.

8

Quality Assurance

Blocking / warning / observation CI gates

Automated checks that fail the build on critical violations.

9

Security & Privacy

CSP, XSS/CSRF, PII, auth UX, secure cookies

Login flows, data masking, content security policy — always required.

2 Adopt it

Start here

Pick the path that matches how you work.

Try it in one afternoon

Add the HIG to an existing project without reading the entire specification.

  1. Pin the contract — copy HIG-QUICK, HIG-LITE, HIG.md, rules/, and VERSION into your repo (e.g. docs/hig/) ~10 minutes
  2. Map your pages — create docs/hig-scope.md with routes and page archetypes (Content, Commerce, Application, or Auth) Example → · ~15 minutes
  3. Wire your tools — add agent rules for Cursor, Copilot, or Claude Code Templates → · ~5 minutes
  4. Review and automate — use the Quick Reference in PRs; add ESLint/CI gates when ready Full integration guide →
3 Use it with AI

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."

  1. Developer
  2. HIG
  3. AI agent
  4. Code
  5. Validation
  6. 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
  1. Resolve archetype
  2. HIG-QUICK
  3. HIG-LITE + pack
  4. Topic module
  5. 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
4 Go deeper

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-*AccessibilityHIG-A11Y-003 — native HTML over ARIA
HIG-TOK-*Design tokensHIG-TOK-001 — no raw hex outside token files
HIG-MOT-*MotionHIG-MOT-001 — no transition: all
HIG-CQ-*Container queriesHIG-CQ-001 — component layout via @container
HIG-SSR-*Server renderingHIG-SSR-001 — default to server rendering
HIG-MUT-*MutationsHIG-MUT-001 — no optimistic destructive confirmation
HIG-SEC-*SecurityHIG-SEC-002 — CSP configured
HIG-SIM-001SimplicityPrefer simplest compliant implementation

Full registry: rules/INDEX.md

Integration into your product

Adopt gradually — most teams start in one afternoon.

  1. Pin the contract — copy HIG-QUICK, HIG-LITE, HIG.md, VERSION, rules/, framework/ into docs/hig/ ~10 minutes
  2. Map your routes — create docs/hig-scope.md with page types per route Example → · ~15 minutes
  3. Add agent rules — copy templates for Cursor, Claude Code, or Copilot Templates → · ~5 minutes
  4. PR checklist — use essential rules for human review until linters exist ~10 minutes
  5. Lint & CI — automate Layer 7 rules and Layer 8 gates when ready Hours — see INTEGRATION.md

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.

DocumentPurpose
RATIONALE.mdWhy the standard exists; goals and non-goals
SPECIFICATION.mdIndex to normative layers and modules
PROFILES.mdQuick Reference vs Practical vs Full conformance
VERSIONING.mdSemver and pinning in product repos
CHANGELOG.mdKeep a Changelog release history
ROADMAP.mdContract and tooling direction
MACHINE_READABLE.mdManifest, registry roadmap, linters
ADOPTERS.mdProjects pinning the contract

All documents

Document Purpose
HIG-QUICK.mdQuick Reference — read first (~5 min, 98 rules)
HIG-LITE.mdPractical guide with rule IDs and checklists (Layer 2)
HIG.mdComplete normative specification
HIG-CORE.mdPhilosophy, vocabulary, archetypes
INTEGRATION.mdProduct repo adoption guide
examples/Scope templates, agent rules, adoption walkthrough
rules/INDEX.mdTopic index & rule ID registry
RELEASE_NOTES.mdAdoption-focused release notes
CONTRIBUTING.mdProposing spec changes

Glossary

TermMeaning
ArchetypePage category (marketing, shop, app, login) that determines required rules
Design tokenNamed design value (e.g. --color-primary) instead of hard-coded values
HIG-QUICK98-rule Quick Reference — default context for daily work and AI agents
HIG-LITEPractical guide with rule IDs — Layer 2 documentation
Rule IDStable code like HIG-A11Y-003 identifying one specific requirement
WCAG 2.2 AAInternational accessibility standard — our compliance target
Core Web VitalsGoogle metrics: load speed (LCP), responsiveness (INP), stability (CLS)
Progressive loadingOpening 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.