A website accessibility audit is a structured review of your website that finds the specific places where people with disabilities get stuck or blocked, and documents them against a recognized standard, usually WCAG 2.2 Level AA. A real audit combines automated scanning with manual testing by a person, including keyboard-only testing and screen reader testing, because no single tool can tell you whether a website is actually accessible. The end result should be a report you can act on, not just a list of errors.
Here’s what that looks like in practice, what an audit checks, what you should expect to receive, and how it’s different from actually fixing the problems it finds.
What Is a Website Accessibility Audit?
A website accessibility audit is an evaluation of a website’s ability to be used by people with disabilities, measured against a defined standard rather than personal opinion. Most audits today use WCAG 2.2 Level AA as that standard, because it’s the version most regulators, courts, and accessibility professionals reference.
An audit doesn’t just run a scanner and print the results. The W3C’s Web Accessibility Initiative, the group that writes the accessibility standards most audits are measured against, states plainly that “no tool alone can determine if a site meets accessibility standards” and that knowledgeable human evaluation is required to determine whether a site is actually accessible. That’s the core idea behind a real audit: software identifies some things quickly, and a trained person checks the things software can’t judge.
Think of it like a home inspection. A moisture meter can tell you a wall is damp. It can’t tell you whether that’s from a leaking pipe, condensation, or a cracked foundation. You need someone who knows what they’re looking at to draw the right conclusion and tell you what to do about it.
Can Automated Tools Do a Full Accessibility Audit?
No. Automated tools are a useful starting point, but they can only reliably catch a portion of accessibility problems, and no accessibility organization considers a scanner report a complete audit on its own.
An automated accessibility checker works something like a spell-checker. A spell-checker can flag a misspelled word instantly and reliably. It cannot tell you whether a sentence actually makes sense, whether it answers the reader’s question, or whether the tone is appropriate. It’s fast and useful for what it does, but it has a ceiling.
Automated tools are good at catching things a computer can measure directly, such as:
- An image with no alt text attribute at all
- Text with color contrast below the required ratio
- A form field with no label connected to it in the code
- Duplicate ID attributes, which can confuse assistive technology
- Missing page titles or missing language attributes
What automated tools cannot reliably judge is anything that requires understanding meaning or experience, such as:
- Whether the alt text on an image actually describes the useful information in it, or just says “photo1234.jpg” is now “image”
- Whether the order you land on things when pressing Tab actually makes sense
- Whether a screen reader user can tell what a button does from the way it’s announced
- Whether an error message actually helps someone fix what went wrong
- Whether a custom dropdown menu or pop-up dialog can genuinely be operated without a mouse
Those questions require a person to sit down, turn on the same tools disabled users rely on, and try to actually use the site.
What Does Manual Testing Add?
Manual testing is where a person actively uses the website the way someone with a disability would, rather than reading a report about it. Two of the most important parts of manual testing are keyboard testing and screen reader testing.
Keyboard Testing
Keyboard testing means navigating the entire website without touching a mouse, using only keys like Tab, Shift+Tab, Enter, Space, the arrow keys, and Escape. This matters because a meaningful number of people can’t use a mouse reliably, whether from a motor disability, a temporary injury, or because they rely on a switch device that mimics keyboard input.
During keyboard testing, an auditor is checking things like:
- Can you reach every link, button, and form field using only the keyboard?
- Is keyboard focus visible? Keyboard focus is the outline or highlight that shows which element on the page is currently selected, so you know what will happen if you press Enter. If you can’t see it, you’re navigating blind.
- Does focus move in a logical order — generally left to right, top to bottom — instead of jumping around unpredictably?
- Can you actually operate things like dropdown menus, date pickers, and pop-up dialogs, or does the keyboard stop responding once they open?
- Does focus ever get trapped, where you enter a section of the page and can’t Tab or Escape your way back out?
A quick way to feel this yourself: unplug your mouse and try to fill out your own contact form using only the keyboard. If you get stuck, so will a real visitor.
Screen Reader Testing
A screen reader is software that reads a webpage’s content out loud, or sends it to a refreshable braille display, for someone who is blind or has low vision. Screen reader testing means actually listening to how a page sounds and behaves with tools like NVDA, JAWS, or VoiceOver, instead of assuming it works because the code looks fine.
An auditor doing screen reader testing is listening for things like:
- Do headings actually describe the section that follows them, so a screen reader user can jump straight to the part they need?
- Do links make sense out of context? A link that just says “click here” tells a screen reader user nothing when they’re scanning a list of links on the page.
- Do buttons announce what they do? A button that only announces “button” with no name is a dead end.
- Are form fields identified clearly, so the user knows what to type before they type it?
- When something goes wrong on a form, does the screen reader announce the actual error, or does the user only see a red border they can’t perceive?
- Is content that changes after the page loads — like a confirmation message or a cart update — actually announced, or does it change silently?
This is the part of an audit that most closely simulates what a real visitor with a disability experiences, which is why it can’t be skipped in favor of automated scanning alone.
What Does an Accessibility Audit Actually Check?
A thorough audit typically works through a website in categories rather than one long, unexplained checklist. The major categories usually include:
- Structure and navigation — whether headings, page titles, and landmarks are set up so a page can be understood and navigated in a logical order
- Keyboard access and focus — everything covered above
- Images and media — whether images have appropriate alt text, and whether video has captions and, where needed, audio description
- Links and buttons — whether interactive elements have names that make sense on their own
- Forms — labels, instructions, and error handling
- Color and contrast — whether text is readable against its background, and whether color is ever the only way information is conveyed
- Zoom and reflow — whether the page still works when text is enlarged or the browser window is narrowed
- Tables, menus, and dynamic components — whether more complex interface patterns behave the way assistive technology expects
Not every page on a large site gets checked line by line. A common and reasonable approach, reflected in W3C’s own WCAG-EM evaluation methodology, is to define a representative sample of page types and templates rather than auditing every single page individually, since most pages on a site share the same underlying templates and components.
What Is WCAG 2.2 AA and Why Does an Audit Use It?
WCAG 2.2 AA is the specific version and level of the Web Content Accessibility Guidelines that most audits test against, because it’s the benchmark referenced most often by regulators, courts, and accessibility professionals. WCAG itself is a technical standard published by the W3C. It is not a law, and an audit report measuring your site against WCAG is not the same thing as a legal determination.
Using a defined standard is what turns an audit from “someone’s opinion about your website” into something consistent and repeatable. Two different auditors evaluating the same page against the same WCAG criteria should reach broadly similar conclusions, because they’re checking against the same defined rules rather than personal taste.
What Should an Accessibility Audit Report Include?
Not every provider formats a report the same way, but a genuinely useful accessibility audit report should let you understand, for each issue found:
- Where it is — the specific page, template, or component
- What the problem is — described in plain language, not just a code snippet
- Who it affects — which kind of user runs into this barrier, and how
- Why it matters — what the person is actually unable to do because of it
- The relevant WCAG criterion, so the issue is tied to a recognized standard rather than a subjective judgment
- Severity or priority, so you know what to fix first
- An example, such as a screenshot, code snippet, or short description of what a screen reader announced
- A recommended direction for fixing it
A report that only says “47 errors found” without this context isn’t something a business owner can actually act on. A report built around these elements turns into a punch list your developer, or your remediation provider, can work through in order of impact.
Is an Accessibility Audit the Same as Fixing My Website?
No. An audit finds and documents the problems. Remediation is the separate work of actually fixing them in the website’s code.
This distinction trips up a lot of business owners, because it’s easy to assume that paying for an audit means the problems get solved. It’s closer to the relationship between a home inspection and the repair work that follows it. The inspector tells you the roof is leaking and the wiring is outdated. A contractor is who actually replaces the shingles and rewires the panel. Skipping straight to “we did an audit” without a remediation step means you have a very detailed list of everything still wrong with your site.
If your audit turns up real barriers, the next step is remediation — correcting the underlying code, labels, and structure so the barriers are actually gone, not just documented.
What Happens After the Audit?
Once you have the report, a sensible path forward looks like this:
- Prioritize. Fix the issues that block entire tasks — broken forms, unreachable navigation, unusable custom controls — before cosmetic issues that don’t stop someone from completing what they came to do.
- Remediate. Correct the underlying code rather than layering a script on top of the existing problems.
- Retest. Confirm the specific issues that were flagged are actually resolved, using the same methods that found them.
- Monitor. Websites change. A new page, a new plugin, or a content update can introduce a new barrier even after everything else has been fixed, so an audit is a snapshot, not a permanent guarantee.
If you’re not sure where your site currently stands, that’s exactly what an accessibility audit is for — and if you want to understand how audits fit into the broader legal picture first, our guide to ADA website compliance covers that separately.
Frequently Asked Questions
What is a website accessibility audit?
A website accessibility audit is a structured evaluation of a website’s usability for people with disabilities, measured against a defined standard such as WCAG 2.2 AA, using a combination of automated scanning and manual testing by a person.
Can automated tools perform a full accessibility audit on their own?
No. Automated tools reliably catch code-level issues like missing alt text or insufficient color contrast, but they cannot judge things that require human understanding, such as whether alt text is meaningful or whether a screen reader user can actually complete a task. The organization that writes the WCAG standard itself states that no tool alone can determine whether a site meets accessibility standards.
How long does an accessibility audit take?
This varies based on the size of the website and the number of unique templates and components it uses, since a thorough audit typically evaluates a representative sample of page types rather than every individual page.
Is an accessibility audit the same as remediation?
No. An audit identifies and documents accessibility barriers. Remediation is the separate process of fixing those barriers in the website’s actual code.
How often should a website be audited?
Since websites change through new pages, plugins, and content updates, a one-time audit only reflects the site at that moment. Many businesses pair an initial audit and remediation with ongoing monitoring, so new barriers are caught as the site evolves rather than discovered months later.
NexoBee’s audits combine automated scanning with manual keyboard testing and real screen-reader testing, evaluated against WCAG 2.2 Level AA, and our reports are built to tell you exactly what to fix and why. If you’d like a clear picture of where your website currently stands, get in touch.