Accessibility Audit Example: A Real WCAG 2.2 Report and What It Found

The report, exactly as the tool showed it

Audited page: https://aipageseo.com/, fetched by URL and loaded in Chrome after its scripts had run.

How to read the numbers

The score starts at 100 and loses 15 points for each error and 5 for each warning: 100 − (3 × 15) − (7 × 5) = 20. It is a measure of how much there is to fix, not of legal compliance. A page conforms to WCAG at Level AA only when it meets every Level A and AA success criterion, so even one error means it does not conform, whatever the score.

The coverage table at the end of the report is the most honest summary. Of the 55 WCAG 2.2 Level A and AA criteria, 3 failed, 4 had warnings, 26 showed no problems, 20 can only be judged by a person (such as whether alt text describes each image well), and 2 were not checked on this run. Nothing is left out, so "not tested" is never mistaken for "no problems".

The three errors, explained

1. 29 controls with a low-contrast edge (WCAG 1.4.11)

The text on the page passed: all 248 text elements measured met the 4.5:1 minimum. The controls did not. The "Ask ChatGPT", "Ask Claude", "Ask Perplexity" and "Ask Google AI" cards and the "See all pricing" button are outlined in a pale blue border (#dbeafe) on a pale blue or white background, which measures 1.1:1 to 1.22:1. WCAG asks for at least 3:1 where the edge is what shows a control is there, so people with low vision can see where to click.

How it is fixed: darken the border (or the fill) until the edge reaches 3:1 against what surrounds it. When many controls share one border colour, as these do, a single change in the stylesheet fixes them all.

2. Three focus outlines cut off by their box (WCAG 2.4.7)

The FAQ questions "What does Keyword Analysis check?", "What does the Schema Debugger verify?" and "Is Keyword Analysis free?" each sit inside a details box that uses overflow: hidden. When a keyboard user tabs to one of them, the browser draws a focus outline outside the question and the box clips it away, so nothing on screen shows where focus is.

How it is fixed: draw the outline inside the question with a negative offset, for example outline-offset: -3px, or remove overflow: hidden from the box. The audit names the box responsible (details.faq-item), so this is a one-rule fix for all three.

3. A name field without autocomplete (WCAG 1.3.5)

The comment form asks for "your name" but does not say so in code. Browsers cannot offer to fill it in, so people with memory, motor or reading difficulties have to type it every time.

How it is fixed: add autocomplete="name" to the field.

The seven warnings, explained

• Fields named only by placeholder text (3.3.2). "Your name" and "Add a comment or question…" have no label. A screen reader reads the placeholder as the name, so it is not a failure on its own, but the hint disappears as soon as someone types. The fix is a visible label, or an aria-label where there is no room for one.
• A video without captions (1.2.2). The audit cannot hear whether a video has speech, so it warns rather than fails. If the video has speech or meaningful sound, a WebVTT captions track is the fix; the coverage table still asks a person to check that captions are accurate.
• 21 SVG graphics with no accessible name. Icons that sit inside a link or button which already has a name are decoration, and aria-hidden="true" focusable="false" hides them from screen readers. An SVG that carries meaning needs a name of its own.
• 24 links opening a new tab without saying so. Adding "(opens in a new tab)" as visually hidden text tells screen reader and keyboard users before it happens.
• 2 link names not clear on their own (2.4.9, AAA). Two links are named only by an email address and a version number. AAA is not required by law, but the fix is quick: "Email us" and "Changelog", with the address and version shown next to them as plain text.
• 10 b and i tags used for emphasis. The fix is strong and em, which look the same but tell screen readers the text is meant to stand out.
• No site search or site map (2.4.5). Visitors need a second way to find pages besides the menu. A "Site map" link in the footer of every page meets this.

What the notes and the coverage table tell you

Notes are not scored, but they say what the audit could and could not see. On this run, 53 text elements sat over an image or gradient, where no automated tool can measure contrast reliably, so they are listed to be checked by eye. Keyboard focus was checked on the first 40 tab stops, and contrast was measured in the default colour scheme.

The AAA note is optional. Level AAA asks for 7:1 text contrast; UK and EU accessibility rules ask for Level AA, and W3C itself does not recommend requiring AAA for whole sites. The audit lists the 54 AAA contrast shortfalls so you can see them, but never lets them lower the score.

Two criteria, Consistent Navigation (3.2.3) and Consistent Help (3.2.6), are marked "Not checked this time". Both can only be judged by comparing pages of the same site, so they need more than one page to compare. Rather than guess, the audit says so, and they stay on the list to check.

What the audit checks

The page is loaded in headless Chrome and audited after its scripts have run, using the full axe-core rule set plus the audit's own checks for criteria axe-core has no rule for: keyboard access and keyboard traps, focus that is visible and not hidden behind sticky content, reflow at 320 pixels wide, 200% zoom, text spacing, contrast of text and of control edges, flashing, moving content, and consistent navigation and help across pages.