Accessibility Audit: a beginner's guide
WCAG 2.1/2.2 accessibility analysis across 24 checks
Web accessibility: what WCAG actually requires (and why lawsuits are rising)
Web accessibility is the practice of building websites that work for everyone — including users with visual, hearing, motor, and cognitive disabilities. The international standard for web accessibility is the Web Content Accessibility Guidelines (WCAG), published by the W3C through the Web Accessibility Initiative (WAI). The current version is WCAG 2.2 (released October 2023), and it organizes accessibility requirements into three conformance levels: A (the basics, must-have), AA (the realistic floor for most public sites, and the level most laws require), and AAA (an aspirational level that is rarely achievable for entire sites). The four guiding principles of WCAG are summarized in the acronym POUR: Perceivable, Operable, Understandable, and Robust.
You should care because accessibility lawsuits against websites have been rising every year for nearly a decade, and the legal exposure for non-compliance is real and growing. In the United States, the Americans with Disabilities Act (ADA) has been interpreted by federal courts to apply to commercial websites, and there have been thousands of ADA-based web accessibility lawsuits filed annually for the last several years. The European Union's European Accessibility Act (EAA) went into effect in June 2025, requiring most public-facing commercial websites operating in the EU to meet WCAG 2.1 AA. Canada has the Accessible Canada Act (federal) and AODA (Ontario). Beyond the legal pressure, accessibility is also the right thing to do — roughly one in seven people on the planet has some form of disability that affects how they use the web.
The five things every accessibility audit looks at:
Color contrast. Text should have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Insufficient contrast is the single most common WCAG failure on the web.
Alt text on images. Every meaningful image must have descriptive alternative text so screen readers can read it aloud. Decorative images should have an empty `alt=""` attribute.
Keyboard navigation. Every interactive element on the page must be reachable and usable with the keyboard alone, no mouse required. Keyboard traps (where the focus gets stuck) are a critical failure.
Heading hierarchy. Headings (`<h1>` through `<h6>`) must be used in logical order, not skipped or used purely for visual styling. Screen readers use headings to navigate.
Form labels. Every form input must have an associated `<label>` so screen readers can announce what the field is for. Labels positioned visually next to inputs but not associated programmatically do not count.
Three questions an accessibility audit answers:
Is my website actually compliant with WCAG 2.2 AA right now?
Which specific failures would a real user with a disability hit on my site today?
For an audit response or a legal questionnaire, what is my current accessibility posture in concrete terms?
The cost of skipping accessibility is the slow accumulation of users who cannot use your site, plus the rapidly-growing risk of an accessibility lawsuit. The fix is rarely a single change — it is a sustained engineering and design discipline — but the highest-value fixes are usually low-effort: alt text, color contrast, and proper labels. The official WCAG specification lives at the W3C WAI.
The Accessibility Audit endpoint, in plain language
In one sentence: **WCAG (Web Content Accessibility Guidelines) 2.1/2.2 accessibility analysis across 24 checks**
Performs automated HTML-based accessibility analysis across 24 checks covering key WCAG (Web Content Accessibility Guidelines) 2.1 success criteria (also applicable to WCAG 2.2). Covers ARIA (Accessible Rich Internet Applications), meaningful HTML (HyperText Markup Language) tags (like <button> instead of a generic <div>), form labels, headings, images, language, navigation, viewport, media, tables, links, SVGs, and more. Automated checks cover approximately 63% of automatable WCAG 2.1 Level A/AA success criteria but cannot replace manual testing — areas like color contrast, keyboard navigation, and dynamic content require browser-based or manual evaluation. Returns a weighted score out of 100 with letter grade and actionable recommendations.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Analyzes the page across 24 accessibility checks: ARIA (Accessible Rich Internet Applications) attributes and landmarks, meaningful HTML (HyperText Markup Language) tags (like <button> instead of a generic <div>) elements, form input label associations (explicit, implicit, and aria-based), language attributes, heading hierarchy, image alt text (alternative text) presence and quality, skip navigation links, tab index misuse, generic link text, page title, viewport zoom restrictions, autoplay media, media captions, table accessibility, button accessible names, iframe titles, duplicate IDs, link accessible names, autocomplete attributes, meta refresh, SVG accessibility, fieldset/legend form groups, inline focus suppression, and object/embed/canvas alternatives.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Accessibility Audit tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Web accessibility is both a legal requirement (ADA (Americans with Disabilities Act), WCAG (Web Content Accessibility Guidelines)) and a business imperative — it expands your audience and improves usability for everyone. Automated audits catch common issues at scale that manual testing would miss.
Picture this in real life. Imagine an accessibility specialist. Here's the situation they're walking into: Audit pages against WCAG (Web Content Accessibility Guidelines) 2.1/2.2 Level A and AA criteria to identify compliance gaps across 24 automated checks. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Accessibility Audit tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Accessibility Audit tool is built for you:
Does my website meet the legal requirements (accessibility, privacy, international standards)?
If a regulator audited my site tomorrow, what would they find?
Where are the gaps I should fix before they become an expensive problem?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Legal and compliance teams, accessibility officers, data-protection officers, and product managers shipping into regulated markets. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you discover the violation when a regulator, a lawyer, or an angry customer finds it for you. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the developer plan. The technical details: `GET /v1/domain/accessibility`.
When would I actually use this?
If you're still on the fence about whether the Accessibility Audit tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an accessibility specialist, a frontend developer, and a compliance officer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: WCAG Compliance Check
Imagine you're an accessibility specialist. Audit pages against WCAG (Web Content Accessibility Guidelines) 2.1/2.2 Level A and AA criteria to identify compliance gaps across 24 automated checks.
Why it matters: Reduce legal risk and improve inclusivity for users with disabilities.
Story 2: Development QA
Imagine you're a frontend developer. Check new pages or components for accessibility regressions before deployment with detailed per-category scoring.
Why it matters: Catch a11y regressions early in the development cycle with actionable recommendations.
Story 3: Enterprise Compliance
Imagine you're a compliance officer. Monitor accessibility compliance across all public-facing web properties with consistent scoring methodology.
Why it matters: Track and report on accessibility progress across the organization with transparent, weighted scoring.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Accessibility Audit tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
Before launching into a new region (especially the EU, the UK, California, or Canada).
During a quarterly compliance review.
When a customer or partner sends you a security questionnaire.
In response to a complaint, audit notice, or legal threat.
If you can see yourself in even one of those bullets, the Accessibility Audit tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Accessibility Audit tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Accessibility Audit tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/accessibility?domain=example.com"What you need to provide
There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to audit accessibility for | example.com |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The audited domain |
aria | object | ARIA (Accessible Rich Internet Applications) attributes, landmarks, and issues found |
semanticHtml | object | Semantic element usage with score |
formLabels | object | Form input label coverage and issues |
language | object | Lang attribute presence and validity |
headings | object | Heading order validation and skipped levels |
images | object | Image alt text (alternative text) coverage, quality, and decorative detection |
skipNavigation | object | Skip navigation link detection |
tabIndex | object | Positive tabindex anti-pattern detection |
linkText | object | Generic link text detection |
pageTitle | object | Page title presence, emptiness, and generic title detection |
viewport | object | Viewport zoom restriction detection |
autoplayMedia | object | Unmuted autoplay media detection |
mediaCaptions | object | Video/audio caption and subtitle detection (WCAG (Web Content Accessibility Guidelines) 1.2.2) |
tables | object | Table caption, header, and scope usage |
buttons | object | Empty button accessible name detection |
iframes | object | Iframe title attribute coverage |
duplicateIds | object | Duplicate ID attribute detection |
linkAccessibility | object | Empty and image-only link detection |
autocomplete | object | Autocomplete attribute coverage on identifiable inputs |
metaRefresh | object | Meta refresh redirect detection |
svgs | object | SVG accessible name detection |
formGroups | object | Fieldset/legend usage for radio/checkbox groups |
focusSuppression | object | Inline outline suppression detection |
mediaAlternatives | object | Object, embed, canvas alternative text detection |
score | number | Accessibility score 0-100 |
grade | string | Letter grade (A+ to F) |
gradeDescription | string | Human-readable description of the grade (e.g., "Very Good - strong posture") |
breakdown | object | Per-category score breakdown with max weights |
recommendations | array | Actionable accessibility improvements |
supplementaryChecks | object | Informational WCAG (Web Content Accessibility Guidelines) checks not included in scoring: orientation lock (1.3.4), accesskeys (2.1.4), aria-live regions (4.1.3) |
wcagCoverage | object | WCAG (Web Content Accessibility Guidelines) 2.1 criteria coverage transparency: list of covered criteria and percentage |
confidence | object | Result confidence indicator: level (high/medium/low) and limitations list |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
WCAG (Web Content Accessibility Guidelines) — The international standard for making websites usable by people with disabilities. Required by law in many countries.
ARIA (Accessible Rich Internet Applications) — A set of HTML attributes that tell screen readers and other assistive technology how to interpret a web page. Important for making websites usable by people who can't see them.
HTML (HyperText Markup Language) — The basic language web pages are written in. The tags you see in the source code (<h1>, <p>, <a>) are HTML.
alt text (alternative text) — A short text description you add to every image on your website. Screen readers read it aloud to visitors who can't see the image, and it's also what shows up if the image fails to load.
ADA (Americans with Disabilities Act) — A US civil rights law that prohibits discrimination against people with disabilities. US courts have repeatedly ruled it applies to websites, which is why accessibility lawsuits exist.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.