Automated accessibility testing is good at the things machines are good at. Is there an alt attribute? Does this input have a label? Is the contrast ratio between these two colors below 4.5:1? A checker answers those in milliseconds, across thousands of pages, without getting tired.
Then it hits something it can't be sure about.
Picture white text sitting on a hero photo. To check the contrast, Axe needs two colors: the text, and whatever is directly behind it. The text color is easy. The background isn't. It's a photograph, lighter in one corner and darker in another, different behind every letter. Axe won't invent a number it can't measure, so it doesn't call it a violation, and it doesn't pass the element either. It sets the result aside and says, in effect: a person needs to look at this one.
Axe calls these results incomplete. Until now we kept the confirmed violations and dropped the incomplete ones on the floor. Starting today, you can keep them.
Turn it on when you start a report
When you create a report with accessibility checks enabled, there's a new checkbox: Store Manual Review Checks. Tick it, and the incomplete Axe results get saved alongside your violations instead of being thrown away.
It's off by default and sits right next to the other check options, so you decide per report whether you want the manual-review list. You can switch it on for a schedule too, so every scheduled run keeps its manual-review items fresh. It's available on Lite plans and up, and it only applies when accessibility checks are on, since these results come from Axe Core.
What actually needs a human
Color contrast over an image is the classic case, but it isn't the only one. A few others you'll find in the Manual review list:
- Text over a gradient, a semi-transparent overlay, or a video background. Same problem as the photo: there's no single background color to measure.
- Links inside a block of text. Axe can see that a link is a different color from the words around it, but WCAG wants a second cue that doesn't rely on color alone — an underline, a border, a change on hover and focus. Whether that cue is really there is a judgment call.
- Frames Axe couldn't reach into. If an iframe doesn't run the Axe script, the checker can't see what's inside, so it flags the frame as untested rather than pretending it's clean.
- Tap targets that might be too small. Whether a control is comfortable to tap can depend on spacing and context that a checker can't fully weigh up.
None of these mean "your site is broken." They mean "a machine got this far, and now it's your turn."
Kept apart from your confirmed violations
Manual-review items never get mixed into your confirmed issues. They live in their own Manual review tab in the report, next to Common Axe issues, grouped by severity just like the rest.
That separation is the whole point. Your violation counts should mean what they say: things that genuinely failed. If we folded every "please double-check" into the same list, the numbers would drift upward with maybes and you'd stop trusting them. Keeping the two apart leaves you with a clean list of confirmed problems and, beside it, a to-do list of the calls only a person can make.
Try it on your next report
If you run accessibility checks here, the next report you start already has the checkbox waiting. Turn it on, let the scan run, and open the Manual review tab to see what Axe wanted a second opinion on. Fix the confirmed violations first, then walk the manual list with your own eyes — that's the part no checker can do for you.
