Someone using assistive technology cannot complete the task at all. A checkout that cannot be reached by keyboard, a form whose errors are never announced, a dialog that traps focus. This is the category that ends in a complaint.
The method
How the audit is carried out
Published in full, checklist included. If you want to run it yourself, you can. What you buy is someone running it who has run it before and knows what to look at when something does not fit the pattern.
37
checks
19
need a person
4
WCAG principles
WCAG 2.2 Level AA
Structure
How it is organised
The audit follows the four WCAG principles rather than a list Uxerfy invented. The deliverable has to map onto the standard your legal counsel, a procurement questionnaire or an external auditor will ask about.
- 01
Perceivable
Whether the information on the page reaches someone who cannot see it, cannot see it well, or cannot distinguish the colours it is drawn in. Content that exists only as a picture, a colour or a contrast too faint to resolve is content that some of your customers do not have.
- Does every image, icon and control carry a text alternative that says what it means, not what it looks like?
- Does the page still make sense in one column at 320px, and at 200% text size?
- Is any information carried by colour alone, or drawn below 4.5:1?
- 02
Operable
Whether the page can be used without a mouse. Keyboard access is the principle most often broken by modern component libraries, and the one automated tooling is worst at detecting — a custom dropdown that traps focus passes every scanner and fails every keyboard user.
- Can every action on the page be completed with the keyboard alone, in a sensible order?
- Is the focused element always visible — not hidden behind a sticky header or a cookie banner?
- Can someone reach the main content without tabbing through the whole navigation?
- 03
Understandable
Whether the page behaves predictably and tells people how to recover. Most of the cost here lands in forms: an error that is announced only in red, a field whose label disappears once it is filled, a session that expires without warning during a checkout.
- When a form is submitted wrong, is the error announced to assistive technology and does it say how to fix it?
- Does every field have a label that is programmatically associated with it, not just placed near it?
- Does anything change the page unexpectedly when it receives focus or input?
- 04
Robust
Whether assistive technology can tell what each control is, what state it is in, and when something on the page has changed. This is where custom components fail: a div styled as a button is a button to everyone except the person who cannot see it.
- Does every control expose a name, a role and its current state?
- When content updates without a page load, is the change announced?
- Does the ARIA on the page describe what is actually there, or what someone hoped was there?
Evidence
Automated and manual
18/37
Automated
Detected by tooling against the page source. Reproducible, fast, and blind to anything that depends on interaction, sequence or what a screen reader actually announces.
19/37
Manual
Found by a person operating the page with a keyboard and a screen reader. Slower, not reproducible by a script, and the only way most serious barriers are ever found.
Checklist
The full checklist
Each check states the question, what it costs when it fails, how to test it, and the success criterion it maps to.
Perceivable
The cheapest findings in an audit live here, and so do some of the most expensive. Alternative text is a fifteen-minute fix; a design system whose entire palette sits at 3.9:1 is a quarter of work.
The commonest failureThe commonest failure is alternative text that describes the file rather than the function — "icon-arrow-right.svg", or a product photo whose alt is the SKU. The attribute is present, the scanner passes, and the information is still missing.
-
01.01 Does every meaningful image carry alternative text that conveys what it means in context? Automatically detectable: Partly
- Why it matters
- The same photograph needs different alternative text on a product page and in a blog post. An empty alt on a meaningful image removes it entirely for a screen reader user; a filename as alt is read out character by character.
- How it is tested
- Turn off images in the browser. Read the page. Anything you no longer understand is an alt text problem.
- Criterion
- 1.1.1 Non-text Content · Level A
-
01.02 Are decorative images hidden from assistive technology rather than described? Automatically detectable: Partly
- Why it matters
- A decorative flourish announced as "image" interrupts the reading of the sentence it was meant to decorate.
- How it is tested
- Check that purely decorative images have alt="" and that CSS background images carry no information.
- Criterion
- 1.1.1 Non-text Content · Level A
-
01.03 Does the heading structure describe the page, with no skipped levels? Automatically detectable: Yes
- Why it matters
- Screen reader users navigate by heading before they read. A page with one h1 and then h4s is a page they have to read linearly, which most will not do.
- How it is tested
- List the headings in order. Read only that list. Does it read as an outline of the page?
- Criterion
- 1.3.1 Info and Relationships · Level A
-
01.04 Are lists, tables and groups marked up as what they are? Automatically detectable: Partly
- Why it matters
- A table of prices built from divs is a wall of unrelated numbers when the row and column headers are not associated.
- How it is tested
- Inspect the markup. A visual table needs th, scope and a caption; a visual list needs ul or ol.
- Criterion
- 1.3.1 Info and Relationships · Level A
-
01.05 Do form fields declare their purpose so a browser can fill them in? Automatically detectable: Yes
- Why it matters
- Autocomplete is an accessibility feature before it is a convenience: it removes the typing burden for people with motor or cognitive disabilities.
- How it is tested
- Check name, email, address and payment fields for the correct autocomplete token.
- Criterion
- 1.3.5 Identify Input Purpose · Level AA
-
01.06 Is any information conveyed by colour alone? Automatically detectable: No — needs a person
- Why it matters
- A required field marked only in red, a chart whose series are only distinguishable by hue, a link that differs from body text only in colour — none of these reach someone who cannot distinguish the colours.
- How it is tested
- View the page in greyscale. Anything you can no longer tell apart is a failure.
- Criterion
- 1.4.1 Use of Color · Level A
-
01.07 Does text meet 4.5:1, and large text 3:1, against its actual background? Automatically detectable: Partly
- Why it matters
- This is the single most common failure on the web, and the one most often introduced by a brand palette signed off without anyone measuring it.
- How it is tested
- Measure the computed colours, not the design file. Include text over images, over gradients, and in hover and disabled states.
- Criterion
- 1.4.3 Contrast (Minimum) · Level AA
-
01.08 Does the page reflow to one column at 320px without horizontal scrolling? Automatically detectable: No — needs a person
- Why it matters
- This is the criterion that covers someone zoomed to 400% on a desktop, not just someone on a phone. A fixed-width table or a sticky sidebar breaks it.
- How it is tested
- Set the browser to 1280px wide and zoom to 400%. Scroll in both directions.
- Criterion
- 1.4.10 Reflow · Level AA
-
01.09 Do interface controls and meaningful graphics meet 3:1 against their surroundings? Automatically detectable: Partly
- Why it matters
- An input border at 1.5:1 is invisible to a lot of people. The field is there; the fact that it is a field is not.
- How it is tested
- Measure input borders, toggle states, icon-only buttons, focus indicators and chart elements.
- Criterion
- 1.4.11 Non-text Contrast · Level AA
-
01.10 Does the layout survive increased text spacing? Automatically detectable: No — needs a person
- Why it matters
- People with dyslexia often apply a spacing stylesheet. If the page clips or overlaps, the content is lost.
- How it is tested
- Apply line-height 1.5, paragraph spacing 2em, letter spacing 0.12em, word spacing 0.16em. Nothing may be cut off.
- Criterion
- 1.4.12 Text Spacing · Level AA
-
01.11 Can content that appears on hover or focus be dismissed and hovered over? Automatically detectable: No — needs a person
- Why it matters
- A tooltip that vanishes when you move towards it is unreadable to anyone using magnification.
- How it is tested
- Hover a tooltip, then move the pointer onto it. Press Escape. Both must work.
- Criterion
- 1.4.13 Content on Hover or Focus · Level AA
Operable
This is the half of the audit that no scanner performs, and the half where the findings that end in complaints are found. Everything here is discovered by a person with their hands on a keyboard.
The commonest failureThe commonest failure is a custom component — a dropdown, a modal, a carousel — that works perfectly with a mouse and is unreachable, or inescapable, with a keyboard. It ships because it was only ever tested with a mouse.
-
02.01 Can every action be completed using the keyboard alone? Automatically detectable: No — needs a person
- Why it matters
- If a control cannot be reached or activated by keyboard, it does not exist for people who cannot use a pointer — and for many screen reader users, who operate by keyboard regardless of sight.
- How it is tested
- Unplug the mouse. Complete the primary task. Tab, Shift+Tab, Enter, Space, arrows, Escape.
- Criterion
- 2.1.1 Keyboard · Level A
-
02.02 Can focus always be moved away from a component? Automatically detectable: No — needs a person
- Why it matters
- A focus trap ends the session. Not the task — the session. The only way out is to close the tab.
- How it is tested
- Tab into every widget, especially modals, date pickers and embedded media, and tab back out.
- Criterion
- 2.1.2 No Keyboard Trap · Level A
-
02.03 Is there a way to skip repeated blocks of content? Automatically detectable: Partly
- Why it matters
- Without a skip link or proper landmarks, every page begins with the same forty tabs through the navigation.
- How it is tested
- Load the page and press Tab once. A skip link should appear and work.
- Criterion
- 2.4.1 Bypass Blocks · Level A
-
02.04 Does every page have a title that describes it? Automatically detectable: Yes
- Why it matters
- The title is the first thing announced and the only thing distinguishing twelve open tabs.
- How it is tested
- Read the titles across the site. Are they unique, and do they lead with the page rather than the brand?
- Criterion
- 2.4.2 Page Titled · Level A
-
02.05 Does focus move in an order that matches the visual layout and preserves meaning? Automatically detectable: No — needs a person
- Why it matters
- CSS can reorder content visually without reordering it in the DOM. The result is a tab sequence that jumps around the page.
- How it is tested
- Tab through and watch the focus indicator. Does it move where you expect?
- Criterion
- 2.4.3 Focus Order · Level A
-
02.06 Does every link say where it goes? Automatically detectable: Yes
- Why it matters
- Screen reader users list links out of context. A page of "read more" is a page of identical links.
- How it is tested
- Extract every link text into a list. Can you tell them apart?
- Criterion
- 2.4.4 Link Purpose (In Context) · Level A
-
02.07 Is the focused element always visible? Automatically detectable: Partly
- Why it matters
- A focus ring removed in CSS, or one drawn in a colour that disappears against a dark section, leaves keyboard users with no idea where they are.
- How it is tested
- Tab the whole page and never lose sight of the indicator.
- Criterion
- 2.4.7 Focus Visible · Level AA
-
02.08 Is the focused element ever hidden behind sticky content? Automatically detectable: No — needs a person
- Why it matters
- New in WCAG 2.2, and extremely common: a sticky header or a cookie banner covers the element that just received focus.
- How it is tested
- Tab down a long page with a sticky header. Watch for focus disappearing under it.
- Criterion
- 2.4.11 Focus Not Obscured (Minimum) · Level AA
-
02.09 Does the accessible name of a control include its visible label? Automatically detectable: Partly
- Why it matters
- Voice control users say what they see. If the button reads "Send" but its accessible name is "Submit form", saying "click Send" does nothing.
- How it is tested
- Compare each control's visible text with its accessible name in the accessibility tree.
- Criterion
- 2.5.3 Label in Name · Level A
-
02.10 Is there a single-pointer alternative to every drag action? Automatically detectable: No — needs a person
- Why it matters
- New in WCAG 2.2. Reordering, sliders and drag-to-upload exclude anyone who cannot hold and drag precisely.
- How it is tested
- For every drag interaction, find the click-only equivalent.
- Criterion
- 2.5.7 Dragging Movements · Level AA
-
02.11 Are targets at least 24 by 24 CSS pixels, or adequately spaced? Automatically detectable: Partly
- Why it matters
- New in WCAG 2.2. Icon-only buttons, close buttons and dense table actions are the usual failures.
- How it is tested
- Measure the smallest interactive targets, especially on mobile layouts.
- Criterion
- 2.5.8 Target Size (Minimum) · Level AA
-
02.12 Can moving, auto-updating or auto-playing content be paused? Automatically detectable: No — needs a person
- Why it matters
- A carousel that advances on a timer is unusable for anyone who reads slowly, and a distraction for people with attention or vestibular conditions.
- How it is tested
- Find every carousel, ticker and auto-playing video. Find the pause control.
- Criterion
- 2.2.2 Pause, Stop, Hide · Level A
Understandable
Forms are where this principle is won or lost, and forms are where the money is. A checkout that announces its errors properly converts better for everyone, not only for the people who need it to.
The commonest failureThe commonest failure is an error message that appears visually, in red, next to the field — and is never announced, never associated with the input, and never focused. The page looks like it is telling you; it is telling only some people.
-
03.01 Does the page declare its language? Automatically detectable: Yes
- Why it matters
- Without it, a screen reader reads English with a Spanish voice, or the reverse. The content becomes unintelligible rather than merely accented.
- How it is tested
- Check the lang attribute on html, and on any passage in another language.
- Criterion
- 3.1.1 Language of Page · Level A
-
03.02 Does anything change the context when an element receives focus or input? Automatically detectable: No — needs a person
- Why it matters
- A select that navigates on change, or a field that submits the form when it is filled, moves the page out from under someone who was only passing through.
- How it is tested
- Tab through every control without activating it. Nothing should navigate, submit or open.
- Criterion
- 3.2.1 On Focus / 3.2.2 On Input · Level A
-
03.03 Are navigation and repeated components consistent across pages? Automatically detectable: No — needs a person
- Why it matters
- Someone who has learned where the search is should not have to learn again on the next page.
- How it is tested
- Compare the order of navigation items and the naming of repeated controls across templates.
- Criterion
- 3.2.3 Consistent Navigation / 3.2.4 Consistent Identification · Level AA
-
03.04 Is help available in the same place on every page that offers it? Automatically detectable: No — needs a person
- Why it matters
- New in WCAG 2.2. A support link that moves between header, footer and a floating widget is a support link that cannot be relied on.
- How it is tested
- Check that contact and help mechanisms appear in a consistent order across the site.
- Criterion
- 3.2.6 Consistent Help · Level A
-
03.05 Does every field have a programmatically associated label? Automatically detectable: Yes
- Why it matters
- A placeholder is not a label: it disappears on typing, usually fails contrast, and is not reliably announced.
- How it is tested
- Check each input for a label element with a matching for, or an aria-label that says the same thing.
- Criterion
- 3.3.2 Labels or Instructions · Level A
-
03.06 Are errors identified in text, associated with their field, and announced? Automatically detectable: No — needs a person
- Why it matters
- Colour alone does not identify an error. Neither does a message that appears in the DOM without a live region or focus management.
- How it is tested
- Submit the form wrong with a screen reader running. Was the error announced? Could you find the field it refers to?
- Criterion
- 3.3.1 Error Identification · Level A
-
03.07 Does each error say how to fix it? Automatically detectable: No — needs a person
- Why it matters
- "Invalid input" states a condition. The user needs the remedy — the expected format, the allowed range, the reason it was rejected.
- How it is tested
- Submit every field wrong on purpose and read what comes back.
- Criterion
- 3.3.3 Error Suggestion · Level AA
-
03.08 Can a transaction be reviewed, corrected or reversed before it commits? Automatically detectable: No — needs a person
- Why it matters
- For anything financial, legal or data-destructive, a mistake made by someone using assistive technology must be as recoverable as anyone else's.
- How it is tested
- Walk the checkout. Is there a review step, a confirmation, or an undo?
- Criterion
- 3.3.4 Error Prevention (Legal, Financial, Data) · Level AA
-
03.09 Is information the user already entered ever asked for twice? Automatically detectable: No — needs a person
- Why it matters
- New in WCAG 2.2. Re-typing an address in a multi-step checkout is a real barrier for people with motor and cognitive disabilities.
- How it is tested
- Complete a multi-step flow. Note anything you are asked for a second time without it being pre-filled or selectable.
- Criterion
- 3.3.7 Redundant Entry · Level A
-
03.10 Does authentication require a cognitive function test with no alternative? Automatically detectable: No — needs a person
- Why it matters
- New in WCAG 2.2. Puzzles, transcription CAPTCHAs and "type the third character of your password" exclude people with cognitive disabilities. Pasting a password must not be blocked.
- How it is tested
- Attempt to sign in using a password manager, with paste. Look for an alternative to any puzzle.
- Criterion
- 3.3.8 Accessible Authentication (Minimum) · Level AA
Robust
Short list, high stakes. Almost everything here concerns custom components, and almost every failure is introduced by a framework or a component library rather than written deliberately.
The commonest failureThe commonest failure is ARIA applied as a decoration — aria-label on a div that is not focusable, role="button" without a keydown handler, aria-expanded that never changes. Incorrect ARIA is worse than none, because it makes a confident claim that turns out to be false.
-
04.01 Does every control expose a name, a role and its state? Automatically detectable: Partly
- Why it matters
- A div styled as a button is announced as nothing. A toggle with no aria-pressed is announced without saying whether it is on.
- How it is tested
- Open the accessibility tree and read every interactive element. Does each have a sensible name and role?
- Criterion
- 4.1.2 Name, Role, Value · Level A
-
04.02 Are icon-only buttons named? Automatically detectable: Yes
- Why it matters
- A close button with only an SVG inside is announced as "button", which tells someone nothing about what closes.
- How it is tested
- List every control containing no text. Check each for an accessible name.
- Criterion
- 4.1.2 Name, Role, Value · Level A
-
04.03 Are changes that happen without a page load announced? Automatically detectable: No — needs a person
- Why it matters
- A cart total that updates, a search result count, a "saved" confirmation — all silent without a live region, so the user does not know their action worked.
- How it is tested
- With a screen reader running, trigger every asynchronous update. Was anything said?
- Criterion
- 4.1.3 Status Messages · Level AA
-
04.04 Does the ARIA describe what is actually on the page? Automatically detectable: Partly
- Why it matters
- ARIA overrides native semantics. An incorrect role silently replaces a correct one, and the element becomes less accessible than the plain HTML it started as.
- How it is tested
- Check every role, aria-expanded, aria-selected and aria-controls against the behaviour they claim, in every state.
- Criterion
- 4.1.2 Name, Role, Value · Level A
Severity
How findings are ordered
Severity answers what a barrier costs the person who hits it, never how hard it is to fix. Mixing the two is how a one-line CSS change ends up above a checkout that cannot be completed by keyboard.
The task can be completed, but only with difficulty, guesswork or luck. An unlabelled field that can be inferred from position, a focus indicator that disappears against one background, a heading structure that makes the page hard to navigate by landmark.
A real barrier for some people in some conditions. Contrast that passes on desktop and fails on a phone in daylight, a link whose purpose needs its surrounding sentence, a target smaller than 24px.
Worth fixing while the file is open. Redundant alternative text, a decorative image that is not hidden, a language attribute missing from a quoted phrase.
Score
The score
Each principle starts at 25 points and loses points for each failing check, weighted by severity. The total is the sum. The arithmetic is published because a number the client cannot reproduce is a number they are being asked to take on faith, which is the opposite of what an audit is for.
A check that fails on many elements is one finding, not many. Past 10 instances it raises the severity by one level, but it never multiplies the deduction: a score that collapses on a single repeated failure stops describing the page.
This score is an internal Uxerfy assessment indicator based on the checks included in this review. It is not a legal certification or a statement of WCAG conformance.
What the score does not measure
-
Conformance. This is an internal Uxerfy assessment indicator based on the checks in this scan, not a statement of WCAG conformance and not a legal certification.
-
Everything WCAG covers. Around a third of WCAG 2.2 success criteria can be decided automatically at all; the rest require a person, and some require testing with disabled users.
-
Whether people with disabilities succeed on your site. That needs usability testing with those users, which is a different engagement from an audit.
-
Content quality — captions that exist but are wrong, alternative text that is present but inaccurate, transcripts that are auto-generated and unedited.
-
Anything behind a login, a paywall or a region block that Uxerfy was not given a way through.
-
Native mobile applications, PDFs and documents, unless explicitly included in the scope.
Get started
The method is public. The difference is who runs it on your site and what they find.
Sergio Gualda · Barcelona, Spain