Web Design

Is Your Website Breaking the Law? A Plain-English Accessibility Checklist

If you've tried to find out whether your website is accessible, you've probably bounced off the same wall everyone does: the official standard, WCAG 2.1 AA, is a document of roughly 50 "success criteria" written in technical language for accessibility specialists, and reading it tells a non-technical founder almost nothing actionable. Meanwhile the stakes are concrete, over 4,000 US website accessibility lawsuits were filed in 2024, 67% of them against companies with under $25 million in revenue (1), and the EU's European Accessibility Act, in force since June 2025, makes WCAG 2.1 AA the operative benchmark for businesses serving Europe (2). You need to know where you stand, and the official document won't tell you in a way you can use. This is the plain-English version: the accessibility checks that matter most for a service website, what each means, why it matters, and how to test it without being technical. It is a triage tool, not a substitute for a full professional audit, but it will tell you whether you have obvious, common, lawsuit-attracting problems, and it covers the issues that account for the large majority of real-world accessibility failures. The standards are cited. This is general information, not legal advice.

Joshua Agonya Pi'Rwot

By Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator

Executive summary

WCAG 2.1 AA has 50 success criteria written for specialists. Here is the founder's version, the checks that matter most, in language you can actually act on.

Section 1

How to use this checklist

A full WCAG 2.1 AA audit is thorough and worth doing, but most accessibility failures cluster around a handful of common issues that a founder can check themselves. Work through the ten checks below; each is something you can test in minutes. A "no" on any of them is a real problem worth fixing, and the ones near the top are both the most common and the most likely to draw a complaint. Think of this as finding the open, obvious problems first, the equivalent of checking whether the doors are locked before commissioning a full security audit.

Section 2

The ten checks

1, Can you navigate the whole site with only a keyboard? Many people with motor or visual disabilities don't use a mouse. Put your mouse aside and try to reach and use everything, links, menus, forms, buttons, using only the Tab, Enter, and arrow keys. Why it matters: keyboard inaccessibility is one of the most common and serious failures. Test: if you get stuck or can't reach something, that's a violation. 2, Is there enough color contrast between text and background? Low-contrast text (light grey on white, thin colored text) is unreadable for many users with low vision. Why it matters: contrast is among the most-cited issues in lawsuits and the easiest to fix. Test: use a free contrast checker; WCAG 2.1 AA requires a ratio of at least 4.5:1 for normal text. (This is also a conversion win, your CTA contrast affects clicks.) 3, Does every meaningful image have alt text? Screen readers describe images to blind users via "alt text." Decorative images can be marked empty; informative ones need a description. Why it matters: missing alt text makes content invisible to screen-reader users, and good alt text helps SEO and AI search too. Test: check that your images have meaningful alt attributes. 4, Can forms be completed by everyone? Form fields need visible labels (not just placeholder text), clear error messages, and keyboard operability. Why it matters: an inaccessible contact or booking form blocks the exact conversion you want, for everyone. Test: tab through your form; is every field clearly labeled and usable? 5, Do videos have captions? Deaf and hard-of-hearing users need captions; auto-generated captions often aren't accurate enough. Why it matters: uncaptioned video excludes users and is a common complaint. Test: check that your videos have accurate captions. 6, Is your text resizable without breaking? Users with low vision zoom in. Text should reflow and remain usable at 200% zoom. Why it matters: a layout that breaks or hides content when zoomed fails low-vision users. Test: zoom your browser to 200% and confirm everything still works. 7, Are links and buttons descriptive? "Click here" and "read more" tell a screen-reader user nothing out of context. Why it matters: non-descriptive links make navigation confusing. Test: would your links make sense read aloud out of context? 8, Is the heading structure logical? Proper heading hierarchy (one H1, nested H2s/H3s) lets screen-reader users navigate. Why it matters: it aids assistive tech and, bonus, helps AI search cite you. Test: check that headings are real headings in logical order, not just big bold text. 9, Does the site work without relying on color alone? Information conveyed only by color (e.g., "required fields are red") excludes colorblind users. Why it matters: color-only cues fail a meaningful share of users. Test: would the meaning survive in greyscale? 10, Can a screen reader make sense of the page? The ultimate test. Why it matters: it's how blind users experience your whole site. Test: turn on your device's built-in screen reader (VoiceOver on Mac/iPhone, Narrator on Windows) and try to use a key page with your eyes closed.

Section 3

The checklist, in one view

These ten won't make you fully WCAG 2.1 AA conformant on their own, that requires a complete audit against all the criteria, but they catch the common, obvious, high-risk failures that account for most real accessibility problems and most lawsuits. If you pass all ten, you're in far better shape than the average service site and have meaningfully reduced your exposure; if you fail several, you've found your priorities. Either way, you now know where you stand, which the official 50-criteria document never told you. (The selection and prioritization of these ten is my synthesis of the most common, highest-impact WCAG 2.1 AA issues; it is triage, not a certification.)

Section 4

Execute This With AI

Here is a workflow to run and act on this checklist with any capable AI model. Step 1, Do the manual tests. Run checks 1, 6, and 10 yourself (keyboard, zoom, screen reader), these require human testing. Note where you got stuck. Paste a key page's HTML or describe its structure for the rest. Step 2, Run the triage prompt: You are an accessibility specialist (not a lawyer) triaging my service website against ten plain-English WCAG 2.1 AA checks. For each, judge Pass / Fail / Can't-tell-need-manual-test, with the specific fix. The ten checks: 1) keyboard navigable, 2) contrast >=4.5:1, 3) alt text on images, 4) accessible labeled forms, 5) captioned video, 6) resizable text to 200%, 7) descriptive links, 8) logical heading hierarchy, 9) not color-alone, 10) screen-reader usable. My manual test results (keyboard/zoom/screen reader): [DESCRIBE] My page HTML or structure: """[PASTE or DESCRIBE]""" Do four things: 1. A table: Check | Pass/Fail/Manual | Evidence | Fix. 2. The 3 highest-risk failures to fix first (most common in lawsuits). 3. A simple remediation plan a non-developer can hand to a freelancer. 4. Tell me clearly which issues need a full professional audit beyond this triage. Be practical; this is triage, not certification. Step 3, Prioritize. "Rank my failures by lawsuit risk and by effort to fix, and tell me the single highest-impact fix I can make this week." Tools and expected output. Any frontier chat model, plus free tools (a contrast checker, your built-in screen reader). Expect a check-by-check triage, top-risk failures, a remediation plan, and a clear line on what needs a full audit. The QA discipline: the manual checks (keyboard, zoom, screen reader) cannot be delegated to the model, only you can experience whether the page actually works that way, and that experience is the truest test. Treat this as triage that finds obvious problems; genuine WCAG 2.1 AA conformance and legal safety require a full professional audit. The official accessibility standard is written for specialists, which is why most founders never find out whether their site is breaking it until a complaint arrives. These ten plain-English checks are the founder's version, run them in an afternoon and you'll know whether you have the common, obvious, high-risk problems that account for most lawsuits and exclude real users. It won't make you certified, but it will move you from "no idea" to "here are my priorities," which, given a litigation environment hitting companies your size, is exactly where you need to be.

Section 5

Keep reading

Keep reading in the Accessibility & the EAA cluster and across the library: [The Business Case for Accessibility (Beyond Compliance)](/blog/the-business-case-for-accessibility-beyond-compliance), [Accessibility as Conversion: Why Accessible Sites Book More Calls](/blog/accessibility-as-conversion-why-accessible-sites-book-more-calls), [Accessibility Overlays: Why the One-Line "Fix" Can Make Things Worse](/blog/accessibility-overlays-why-the-one-line-fix-can-make-things-worse). Also relevant: [The Motion Accessibility Mistake That Excludes Real Customers](/blog/the-motion-accessibility-mistake-that-excludes-real-customers), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [What Is Conversion-First Web Design? A Plain-English Guide for Founders](/blog/what-is-conversion-first-web-design-a-plain-english-guide-for-founders).

Joshua Agonya Pi'Rwot

Written by

Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator · Country Director, AVODA Group Uganda · EMBA

Joshua helps service-business operators turn scattered marketing into a clear path from first attention to booked call. He is Founder of Business Growth Accelerator and Country Director of AVODA Group Uganda.