Code & dev

A practical WCAG checklist for template-based websites

25 May 2026 · 9 min read · By TM Team

TL;DR

For a typical small business marketing site, the WCAG criteria that matter most reduce to five testable buckets: color contrast (4.5:1 for normal text, 3:1 for large text and UI components), meaningful alt text on informative images, full keyboard operability with visible focus states, properly labeled form fields, and a logical heading structure. Each has a specific number or test you can check directly, not just a general principle.

General accessibility advice tends to stop at 'add alt text and use good contrast,' which is true but not actionable. WCAG (the Web Content Accessibility Guidelines) is a large, formal standard, but most of it doesn't apply to a simple marketing site — no video captions to worry about if you have no video, no complex data tables if you don't publish any. This is a checklist scoped to what actually shows up on a typical template-based small business site, with the specific numbers and tests behind each item.

Where the general 'accessibility basics' conversation covers why this matters and the broad principles, this is the version you actually run through page by page before launch.

1. Color contrast — the two ratios that matter

WCAG 2.1 Success Criterion 1.4.3 (Level AA) sets two specific contrast ratio thresholds against the background: 4.5:1 for normal body text, and 3:1 for large text (18pt/24px regular weight or larger, or 14pt/18.66px bold or larger) and for meaningful UI components and graphics like button borders and icons.

Contrast ratio checklist

Element	Minimum ratio	How to check
Body text on background	4.5:1	Browser DevTools color picker (shows ratio directly) or a contrast checker tool
Large text (24px+/18.66px bold+) on background	3:1	Same tools, using the large-text threshold
Button borders, form field borders, icons conveying meaning	3:1	Check the border/icon color against its immediate background
Placeholder text used as the only label	N/A — don't do this	Placeholder-only labeling fails independent of contrast; see form labels below

The common failure: light gray text on white

Light gray body text on a white or near-white background is one of the most frequent contrast failures on template-based sites, usually introduced when a designer favors a subtle, muted look. Check every gray-on-light or light-on-dark text combination on the site, not just the ones that look obviously low-contrast at a glance.

2. Alt text — what needs it and what doesn't

Success Criterion 1.1.1 (Level A) requires text alternatives for non-text content. In practice this splits into three cases that are handled differently, and getting this split wrong is more common than skipping alt text entirely.

•Informative images (product photos, team photos, diagrams): write alt text that conveys the same information a sighted user gets, concisely — not a generic filename, not 'image of...'
•Decorative images (background textures, spacer graphics, purely aesthetic flourishes): use an empty alt attribute (alt="") so screen readers skip them entirely, rather than reading out irrelevant descriptions
•Functional images (a logo that's also a home link, an icon-only button): alt text should describe the function, not the appearance — 'Home' or 'Search,' not 'magnifying glass icon'

3. Keyboard operability and focus states

Success Criterion 2.1.1 (Level A) requires that all functionality be operable through a keyboard alone, and 2.4.7 (Level AA) requires that keyboard focus is always visible. Test this directly: unplug your mouse (or just don't touch it) and tab through the entire page.

1
Tab through the whole page in order
Press Tab repeatedly from the top of the page. Every link, button, and form field should receive focus in a sensible order — usually matching the visual layout.
2
Confirm you can always see where focus is
A visible focus ring or outline should appear on whatever element is currently focused. If your CSS sets the outline to none without a replacement focus style, this is very likely broken.
3
Check that every interactive element is actually reachable
Custom-styled buttons built from a generic div instead of a real button element, and dropdown menus built with hover-only CSS, are common places keyboard users get stuck.
4
Test that menus and modals can be closed without a mouse
A mobile nav menu or a popup that only closes via a mouse click on a specific X icon traps keyboard users. Escape key support and a genuinely focusable close control are the fix.

Never remove the focus outline without replacing it

Setting every element's outline to none on focus is one of the single most common accessibility regressions in custom CSS, usually added to 'clean up' a visual style. If you don't like the default outline, replace it with a clearly visible custom focus style — don't remove it outright.

4. Form labels

Success Criterion 1.3.1 and 4.1.2 together require that every form field has a programmatically associated label, not just visible text nearby. A real label element connected to its input via matching for and id attributes (or wrapping the input directly) is what actually matters — a label that merely sits next to the input visually, with no code-level connection, doesn't count.

Form label checklist

Requirement	Check
Every input has an associated label element	Check that a real label is connected, not just nearby text
Placeholder text is not the only label	Placeholders disappear on input and often fail contrast — treat as a hint, never a substitute for a real label
Required fields are marked programmatically	Use the required attribute or an aria-required attribute, not just a visual asterisk
Error messages are associated with their field	Use an aria-describedby reference to connect an error message to the field it refers to
Grouped fields (like a set of radio buttons) have a group label	Use a fieldset and legend for the group as a whole

5. Heading structure

Success Criterion 1.3.1 also covers heading structure: headings should form a logical outline, not be chosen for their visual size. One main page heading, with subheadings nested underneath in order, no skipping levels purely for a font-size effect. Screen reader users frequently navigate by jumping between headings, so a broken structure genuinely breaks their ability to scan the page, not just the semantic 'correctness' of your markup.

Use your browser's accessibility tree to check headings fast

Chrome DevTools' Accessibility panel, or a free browser extension like a heading-outline viewer, will show you the actual heading structure of the page in seconds — much faster than manually inspecting every heading tag in the source.

6. Two more criteria worth checking on a marketing site

Two additional success criteria come up often enough on template-based sites to include here, even though they're slightly less universal than the five above. Success Criterion 1.4.4 requires that text remain readable and functional when resized up to 200 percent without loss of content or function — test this by zooming your browser to 200 percent and confirming nothing overlaps, gets cut off, or becomes unusable. Success Criterion 2.3.1 restricts flashing content to below a threshold that can trigger seizures — relevant if your template includes any auto-playing animation, video background, or carousel with fast, high-contrast transitions.

Two additional checks worth doing

Criterion	What to test
Text resize to 200 percent (1.4.4)	Zoom the browser to 200 percent; confirm no content is cut off, overlapping, or unreadable
No content flashes more than three times per second (2.3.1)	Review any auto-playing animation, video background, or fast carousel transition

Automated tools vs manual testing

Automated accessibility checkers are a genuinely useful first pass, and worth running before you do anything manual. Tools like axe DevTools (a free browser extension) and the accessibility audit built into Lighthouse will reliably flag missing alt attributes, several classes of contrast failures, and missing form labels in seconds. What they can't do is judge whether your alt text is actually meaningful, whether your reading order genuinely makes sense, or whether your keyboard navigation feels usable rather than merely technically possible. Treat automated results as a floor, not a ceiling — real coverage needs the manual checks in this list on top.

A passing automated scan is not the same as an accessible site

Automated tools typically catch somewhere in the range of a third of real WCAG issues, since so much of accessibility depends on judgment and context an algorithm can't evaluate — meaningful alt text, logical tab order, and genuinely usable keyboard interaction all require a human pass.

A five-minute pass before you publish

The quick pre-launch check

Contrast check→

Tab through page→

Alt text review→

Form label check→

Heading outline

Five checks, a few minutes each, catches the large majority of real-world issues on a typical marketing site.

✓4.5:1 contrast for normal text, 3:1 for large text and meaningful UI elements — check with a contrast tool, don't eyeball it.
✓Split alt text into informative (describe it), decorative (empty alt=""), and functional (describe the action).
✓Tab through every page; every interactive element needs a visible focus state and must be reachable.
✓Never remove the focus outline without a visible replacement.
✓Every form field needs a real, code-connected label — placeholder text alone doesn't qualify.
✓One main heading per page, nested subheadings in logical order, no skipped levels chosen for visual size.
✓Check 200 percent text resize and flashing-content limits if your template uses animation or video backgrounds.
✓Automated scanners catch a fraction of real issues — pair them with the manual checks in this list.

What WCAG level should a small business website aim for?

Level AA is the generally accepted practical target — it's what most accessibility laws and standards reference, and it covers the criteria in this checklist (contrast, labels, keyboard access, focus visibility). Level AAA exists but includes some criteria that are genuinely difficult to meet for ordinary content sites.

Do I need alt text on every single image?

Every image needs an alt attribute, but not every image needs descriptive text. Informative images need a real description; purely decorative images should use an empty alt="" so screen readers skip them rather than reading out irrelevant noise.

How do I actually test keyboard navigation without special tools?

Click once on the page to focus it, then use only the Tab, Shift+Tab, and Enter keys — no mouse. Every link, button, and form field should be reachable in a sensible order, with a visible focus indicator at every stop.

Is a browser extension accessibility checker enough on its own?

Automated checkers (like axe DevTools or Lighthouse's accessibility audit) reliably catch things like missing alt text and contrast failures, but they can't verify logical reading order, meaningful alt text quality, or genuine keyboard operability. Use one as a first pass, then do the manual checks in this list.

Does an animated hero or video background on my template create accessibility problems?

It can, if it flashes rapidly or auto-plays with no way to pause it. Check that any fast, high-contrast animation stays below the flashing threshold in Success Criterion 2.3.1, and provide a pause or stop control for any auto-playing motion.

wcag checklistwebsite accessibility checklistwcag success criteriaaccessible website testingwcag 2.1 small business