Which WCAG testing tools let a person confirm every result?

1. Why a person should confirm, not just read

Automated results are right most of the time on the things they can measure, and that is exactly why the wrong ones are dangerous: they look the same as the right ones. A contrast check can measure the wrong pair of colours when text sits on an image. A label check can miss a label that is there for a screen reader but not in the markup it looked at. A rule can apply to an element that, in context, is decorative.

None of this makes automated testing bad. It makes confirmation cheap and worth doing. A person with the evidence in front of them can confirm a result in a few seconds, and the confirmed result is one they can defend. The unconfirmed one is a tool’s opinion with a company’s name about to go on it.

2. The three kinds of result a person deals with

A review workflow has three jobs, and a tool should make each one obvious.

• Confirm or overturn a measured result. The tests found a failure or a pass. The person looks at the evidence and agrees, or disagrees and says why. Disagreement is recorded, not deleted.
• Decide an undecided result. The tests gathered evidence but could not settle the question: does this alt text describe this image. The person decides from the evidence. These results should be marked as undecided, never counted as passes, until that happens. Why ‘can’t tell’ is an honest answer explains the state.
• Sign. When every result has been confirmed or decided, the report stops being a draft because a named person said so.

A tool that only offers the first, or offers it as a comment box no one reads, has not built a review step. A tool that skips the third has produced a document nobody stands behind.

3. What a good review workflow looks like

The person’s time should go on deciding, not on looking. So each result should arrive with the evidence already gathered: the captured page with the element highlighted, the measurement, the criterion, and a suggested answer where one can be offered. A suggestion is not a result; it is a way of asking the question clearly. The person confirms, changes, or decides, and records a reason.

Decisions should be grouped by cause. If one shared header has the same problem on every page, the reviewer decides once and the decision covers every page it appears on. They should not have to decide forty times, and they should be able to see the forty pages if they want to.

Decisions should be kept. A decision made in October should still be visible in November when the page is re-run, so that the reviewer can see what changed rather than start again.

4. What product teams should look for

Product teams need something different from auditors doing a one-off engagement. They ship every week, they answer buyers more than once a year, and the people reviewing results are designers and developers, not accessibility specialists. For that team, an accessibility audit tool should:

• Find the site’s pages itself and check them together, so the scope is the product and not one page. Is there a WCAG 2.2 checker that covers a whole site? covers what that involves.
• Keep evidence for every result, so that a designer can decide an alt-text question without being an expert. Which accessibility audit software gives evidence for every finding? sets out what evidence means.
• Mark what it cannot settle, and never count it as a pass.
• Give a person a place to confirm, decide and say why, with decisions grouped by cause and kept between runs.
• Draft the conformance report from the evidence and the decisions, and leave the signature to a named person. How do you create a VPAT 2.5Rev without writing it by hand? explains what that drafting can and cannot do.
• Stay out of the site. A tool that adds a script to the page to “fix” problems is an overlay, and overlays do not make a site accessible; the fixes have to happen in the product’s own code.

Items that make the list shorter are worth having too: for example, sending a finding to the team’s issue tracker. Dreven plans to send findings to a GitHub repository as issues on the Team plan; it is not available yet.

5. What this does not mean

A person confirming every result is not a promise that the site conforms. It is a promise that every claim in the report was looked at by someone who is willing to be named. Conformance is still claimed page by page, for the pages in scope, on the date of the audit, and it ages as the product changes. A tool that lets a person confirm results makes the report defensible. The people who fix the product make it accessible.

6. The test to apply to any tool

Open a result the tool reports as a pass and ask: can I see what it measured, can I disagree, will my disagreement be recorded, and will the report say that I decided? Then open a result it could not settle and ask: is it counted as a pass anywhere? If the answers are yes, yes, yes, yes and no, the tool lets a person confirm every result. Most do not.

7. Questions people ask

Which WCAG testing tools let a human reviewer confirm results?

Look for a tool where every result arrives with its evidence, a reviewer can confirm or change any result and record why, results the software cannot settle are marked undecided rather than counted as passes, and the report is a draft until a named person signs. Dreven is built this way: the reviewer decides every result and signs the report; nothing is signed for them.

What are the best website accessibility audit tools for product teams?

For a team that ships often and answers buyers more than once a year, the best tools find the site’s pages and check them together against WCAG 2.2 (or the standard a buyer named), keep evidence for every result, mark what they cannot settle, give a person a place to decide and say why, and draft the conformance report for a named reviewer to sign. Avoid tools that promise compliance from a scan or add a script to the site.

Does a human review make an audit report more reliable than an automated scan?

Yes, on two counts. A person catches the measured results that are wrong in context, and a person is the only one who can decide the criteria that need judgement, such as whether alt text describes its image. A report where every result was confirmed or decided by a named person can be defended row by row; a scan result cannot.

Can a person override an automated accessibility result?

In a tool built for review, yes, and the override is recorded with the reason and the person’s name rather than replacing the evidence. The automated measurement stays visible beside the decision, so that a later reader can see both and judge for themselves.

8. Where Dreven fits

In Dreven, every result is one of four states, and every one waits for you. Results the tests could not settle are marked “can’t tell”, never counted as passes, and come to you with the captured page, the highlighted element and the measurement beside them. You confirm, change or decide, say why, and the decision is recorded under your name and applied to every page the same problem appears on. The report is drafted from the evidence and your decisions and stays a draft until you sign. See what a website accessibility audit covers.