Please note: This site provides general educational information only. Insurance is regulated by state and rates vary widely. Consult a licensed professional or insurer for advice specific to your situation. Data is based on publicly available averages and may not reflect current individual rates.

Internal Reference

Design system

A living style guide for Plain Policies: the color palette, typography, reusable components, and accessibility commitments that every page on this site is built from. Everything shown below is rendered using the site's actual stylesheet — not a mockup.

1. Logo & brand

The Plain Policies mark, wordmark, and tagline, plus the rules for using them consistently across the site.

Full lockup (mark + wordmark + tagline)
Plain Policies logo: a document-and-checkmark mark next to the wordmark "Plain Policies" and the tagline "Insurance, explained plainly."
Icon mark alone (used in the header, and as the basis for the favicon)
Document + checkmark: a policy, made clear.
Wordmark and tagline

Plain Policies
Insurance, explained plainly.

Usage notes

The mark uses the primary blue (#0A4D8C) for the document outline and the teal accent (#0F766E) for the checkmark, matching the site's color tokens. Keep clear space around the mark roughly equal to the height of the checkmark stroke. Don't recolor the mark, stretch it, or place it on a background that drops its contrast below WCAG AA.

2. Color palette

Trustworthy blue as the primary color, a soft teal accent, and neutral cool grays for text and structure. Every text/background pairing listed here meets WCAG 2.1 AA (4.5:1 for normal text, 3:1 for large text and UI components).

Primary / Trustworthy Blue
#0A4D8C
Links, primary buttons, nav highlight — 8.6:1 on white
Primary Dark
#062F57
Headings, footer background, hover states — 13.5:1 on white
Primary Light
#E1EBF6
Info callouts, hero background tint, badges
Accent / Soft Teal
#0F766E
Card icons, links inside cards, “lowers rate” indicator — 5.5:1 on white
Accent Light
#E1F3F0
Tag backgrounds, teal callout fill
Text
#1A2027
Body copy, headings — 16.4:1 on white
Text Muted
#4B5563
Secondary copy, captions — 7.6:1 on white
Border
#DCE1E7
Card & table dividers (decorative, not a functional boundary)
Border Strong
#8B96A3
Input outlines, functional UI boundaries — 3.0:1 on white
Background
#F7F9FB
Page background
Warning / Disclaimer Border
#c98a12
Sticky disclaimer bar, data-source callouts
Focus Ring
#B45309
Keyboard focus outline on every interactive element — 5.0:1 on white

3. Typography

Body font is Inter (loaded from Google Fonts, weights 400–800), falling back to the system UI font stack if unavailable. Base body size is 1.0625rem (~17px) for comfortable reading at an 8th-grade level.

Heading 1 — page titles

clamp(1.9rem, 4vw, 2.6rem) · weight 700

Heading 2 — section titles

clamp(1.4rem, 3vw, 1.85rem) · weight 700

Heading 3 — component & card titles

1.2rem (component titles may set 0.95–1.05rem) · weight 700

Body text — used for all paragraph copy across the site, written at an 8th-grade reading level.

1.0625rem · weight 400 · line-height 1.6

Muted / secondary text — captions, table notes, disclaimers.

inherits body size · color: text-muted

Heading hierarchy rule

Section titles are always H2. The first sub-heading inside any component (a card, step, or stepper item) is H3 — never H4 — so heading levels never skip for screen reader navigation. Footer navigation headings (H4) are scoped inside the page's <footer> landmark and are treated as their own sectioning context.

4. Components

Buttons

Primary & secondary
Primary button Secondary button

Expandable accordion / FAQ

Native <details>/<summary> — keyboard and screen-reader accessible with no JavaScript required
What is this component for?

Used for coverage explanations, rate factors, and myths vs. facts throughout the site. Built on native HTML so it works even if JavaScript fails to load.

Is it keyboard accessible?

Yes — Tab to focus, Enter or Space to expand/collapse, no custom ARIA required since <details> handles this natively.

Data table

Used for cost comparisons and rating-factor breakdowns
Example comparison table
PlanTypical cost
Option A$120/yr
Option B$240/yr

Definition card (glossary)

Searchable, filterable term definitions
Example Term
A short, plain-English definition goes here, matching the tone used across the glossary.

Progress-style claim stepper

Numbered, icon-led steps — used for claims and underwriting walkthroughs
1

Notify

Report the loss to your insurer.

What you usually need to provide:
  • Date and description of what happened
2

Resolution

The claim is reviewed and settled.

What you usually need to provide:
  • Any documents your insurer requests

Sticky disclaimer

Live on this page right now — pinned to the bottom of the viewport, dismissible per browser session

The real, functioning sticky disclaimer bar is currently visible at the bottom of your screen. It uses position: sticky, includes a dismiss button with an aria-label, and reappears on every new page since dismissal is scoped to sessionStorage, not permanent.

Mobile navigation

Collapses below 880px viewport width

The hamburger toggle button includes aria-expanded and aria-controls, and the nav list becomes a full-width vertical menu. Try resizing your browser or viewing this page on a phone to see it in action.

Chips & tags

Compact visual labels for rating factors
AgeLocationCredit-based score

Raise / lower rate list

Two-column visual comparison

Tends to raise rates

  • Example factor

Tends to lower rates

  • Example factor

Callouts

Default (teal) and info (blue) variants

Default callout

Used for tips, definitions, and supporting context.

Info callout

Used for neutral, important framing notes.

Data-source disclaimer: used specifically when citing public rate data, distinct from the general educational disclaimer.

5. Accessibility commitments

Target: WCAG 2.1 Level AA across every page.

Keyboard navigation

Every interactive element — nav links, the mobile menu toggle, accordions, the glossary search and A–Z filter, and the disclaimer dismiss button — is reachable and operable with Tab, Shift+Tab, Enter, and Space alone. Accordions use native <details> rather than custom JavaScript widgets specifically so keyboard and screen-reader support comes for free.

ARIA labels & roles

The mobile nav toggle uses aria-expanded and aria-controls. The disclaimer dismiss button has an explicit aria-label. Search inputs have associated <label> elements (visually hidden where a visible label would be redundant). The glossary's letter filters use aria-pressed to reflect selection state.

Icons & “alt text”

All icons are inline SVG, not <img> tags, so there's no literal alt attribute — the equivalent treatment applies instead: every icon sits next to a visible text label and is marked aria-hidden="true" so assistive tech doesn't announce it redundantly. No icon is ever used alone as the only label for a control.

Color contrast

Every text/background color pairing in the palette above meets or exceeds 4.5:1 for normal text and 3:1 for large text and functional UI boundaries (see Section 1 for exact ratios).

Focus visibility

A high-contrast focus ring (5.0:1 against white) appears on every link, button, and form control when navigating by keyboard, using :focus-visible so it doesn't appear on mouse clicks.

Heading structure

Headings follow a strict, non-skipping order within the main content of every page (see Section 2), so screen reader users can navigate by heading level reliably.

6. Tech stack

Current implementation: static HTML, hand-written CSS (this stylesheet), and a small vanilla JavaScript file for the mobile menu, glossary search/filter, and disclaimer dismissal. No build step, no client-side framework, no analytics or tracking scripts, and no lead-generation forms anywhere on the site.

Why not a framework, by default

For a mostly-static, content-first educational site like this one, plain HTML/CSS loads faster than any JavaScript framework: there's no runtime to download, parse, or hydrate, and accordions work via native <details> with zero JavaScript required. A framework's benefits — easier large-scale maintenance, component reuse, routing — matter more as a site grows past a handful of pages or needs dynamic data.

If this site is later rebuilt on Next.js + Tailwind + shadcn/ui

The component set above maps cleanly onto shadcn/ui primitives, so a future migration wouldn't require redesigning anything — just re-implementing these same components:

Component mapping for a future migration
Current componentshadcn/ui / Radix equivalent
Accordion (native <details>)Accordion
Data tablesTable
Definition / glossary cardsCard
Claim stepper / mini-stepperCustom component on Progress + Card primitives
Sticky disclaimer barCustom component (Radix has no direct equivalent; similar pattern to a persistent Toast)
Mobile navigationSheet or NavigationMenu
Chips / tagsBadge
Trade-off to weigh: Next.js + Tailwind + shadcn/ui (built on Radix UI) adds the React runtime and hydration cost, plus JavaScript for each interactive component. Even with static export, expect meaningfully more shipped JavaScript than the current zero-framework build. Worth it if the site grows substantially or needs dynamic/CMS-driven content; not necessary for a site this size focused purely on fast-loading education.