Blog Post
Website QA Checklist: 15 Essential Checks
Last updated: May 20, 2026
A 15-point website QA checklist covering layout, typography, color, interactive states, responsive behavior, and accessibility. Built for the gap between functional testing and visual quality — so design bugs get caught before users see them.
Why Most QA Checklists Miss Visual Bugs
Functional QA has decades of tooling: unit tests, Cypress, Playwright. Visual QA has almost none. Teams ship features that work but do not look right because there is no structured process, no side-by-side comparison against the design spec, and no clear ownership of visual quality. According to CISQ, poor software quality cost US organizations $2.41 trillion in 2022, with a significant share tracing back to defects caught too late. Zeplin research found that teams waste 4 to 8 hours per employee per week on design-dev handoff issues that a structured checklist prevents.
The 15-Point Website QA Checklist
Layout & Spacing (Checks 1-3)
- Margins and padding match the design spec — especially vertical rhythm between sections
- Content alignment is consistent — headings, body text, and images share the same grid
- No content overflow or clipping at any viewport width
Typography (Checks 4-6)
As Oliver Reichenstein of iA wrote, 95% of the information on the web is written language, making typography the foundation of web design.
- Font families and weights match the spec — check fallback rendering
- Font sizes follow the design system type scale from h1 through labels
- Line-height and letter-spacing are correct — design tools and CSS calculate these differently
Color & Visual Consistency (Checks 7-9)
- Brand colors match design tokens — inspect hover and focus states, not just defaults
- Backgrounds, borders, and shadows are consistent across similar components
- Images and icons render correctly — check SVG fills, image aspect ratios, and alt text
Interactive States (Checks 10-11)
- Hover, focus, active, and disabled states all exist and match the spec
- Form states show correct visual feedback — error, success, empty, and loading
Responsive Behavior (Checks 12-13)
- Layout matches the design at each breakpoint — desktop, tablet, and mobile
- No horizontal scroll at any viewport width from 320px to 1920px
Accessibility (Checks 14-15)
The WebAIM Million 2026 report found that 95.9% of the top one million homepages had detectable WCAG failures, averaging 56.1 errors per page.
- Color contrast meets WCAG AA — 4.5:1 for body text, 3:1 for large text
- All interactive elements are keyboard-accessible with visible focus indicators
How to Run This Checklist
Run the checklist after a feature is deployed to staging and before merging to production. The designer who owns the spec should compare the staging URL against the design file, working through each category. For every failed check, file an issue with a screenshot, expected value from the design, and actual value from the browser.
Common Mistakes That Break Website QA
The SmartBear 2024 State of Software Quality report found that 48% of teams release code with known defects due to time pressure, which means the checklist process itself needs to be fast and frictionless or it gets skipped.
- Reviewing without the design spec open — comparing from memory misses spacing and color differences
- Only checking at one viewport — pages that look correct at 1440px can break at 768px
- Skipping interactive states — hover, focus, and disabled states account for many visual bugs
- Filing vague issues — include what is wrong, where, what it should be, and a screenshot
- Running QA too late — run the checklist while the feature is still in an open pull request
Automating Your Website QA Checklist
OverlayQA handles multiple checklist categories in a single workflow: capture a screenshot of your staging page, compare it against the Figma design, and export any issues with CSS values, element metadata, and screenshots directly to Jira or Linear. The accessibility audit workflow runs automated WCAG checks on the same page.
| Check Category | Manual Approach | Tool-Assisted Approach |
|---|---|---|
| Layout & spacing | Eyeball comparison with design file | Visual comparison tool that compares the design against the live page |
| Typography | DevTools inspection of each element | CSS extraction that captures font-family, size, weight, and line-height automatically |
| Color | Color picker against design tokens | Automated token diff that flags mismatches |
| Interactive states | Click/tab through every element | State capture that documents hover, focus, and disabled screenshots |
| Responsive | Resize browser to each breakpoint | Multi-viewport capture for side-by-side comparison |
| Accessibility | Manual contrast checks and keyboard nav | Automated WCAG scan with issue reporting |
Frequently Asked Questions
What should a website QA checklist include?
A comprehensive website QA checklist should cover six categories: layout and spacing, typography, color and visual consistency, interactive states, responsive behavior, and accessibility. This goes beyond functional testing to catch visual bugs that break the user experience.
When should you run a website QA checklist?
Run it after the feature is deployed to staging and before the pull request is merged to production. This gives enough context to compare against the design spec and enough time to fix issues before they reach users.
Who should run the website QA checklist?
The designer who owns the spec is ideal, since they know what the implementation should look like. On smaller teams where QA staff wear multiple hats, assign design QA ownership explicitly to prevent the checklist from being skipped.
What is the difference between functional QA and visual QA?
Functional QA checks whether features work correctly. Visual QA checks whether the implementation matches the design spec — correct spacing, typography, colors, and interactive states. A page can pass every functional test while still having visual bugs.
How long does a website QA check take?
A full 15-point visual QA check on a single page takes 10 to 15 minutes when done manually with the design spec open. With tool-assisted comparison (overlaying the design on the live page), most teams complete the check in under 5 minutes per page. The time investment pays for itself by preventing rework cycles that IBM research estimates cost 100 times more to fix in production than during development.
What is website QA testing?
Website QA testing is the process of systematically checking a website for bugs, usability issues, and visual defects before launch. It includes functional testing, visual testing (comparing the build against design specs), cross-browser testing, and accessibility testing. Visual QA is the most commonly skipped category.
What are the best website QA tools?
For visual QA, OverlayQA compares Figma designs against live builds. For functional testing, Playwright and Cypress automate browser interactions. For accessibility, axe-core and WAVE scan for WCAG violations. For cross-browser testing, BrowserStack and LambdaTest cover device combinations. Most teams combine multiple tools.
How do you QA a website before launch?
Deploy to staging, run functional tests, compare the build against design specs at each breakpoint, test interactive states, check accessibility, and verify no horizontal scroll at any viewport. File issues with screenshots and CSS values.