How to Read WCAG Check Results and Re-Test Fixes
Understand DevCheck findings, items needing manual review and untested scope. Use the affected element, task and rule to decide what to fix and re-test, without treating zero findings as WCAG conformance.
Start by separating what the results tell you
These examples refer to DevCheck’s axe-core page scan. Results describe the state scanned. Identify the kind of result before deciding whether to fix or investigate it; not every prompt is a confirmed error.
Confirmed findings: inspect the rule and element
For example, button-name identifies a button without an accessible name. Inspect the listed element and explanation, then confirm what the button does. This is a rule finding, not a conformance decision for the whole website.
Needs manual review: not a settled result
The tool requests review when it cannot settle a check, for example when a text background color cannot be determined. Inspect the page and relevant state. Do not count this automatically as either a pass or a confirmed failure.
Not listed does not mean tested
Unopened menus, other pages, unvisited error states and actual screen-reader announcements do not become passes because this scan has no findings. Record them as untested and plan interaction and assistive-technology checks.
Counts are not people or failed pages
One rule can list several elements, and one element can appear under several rules. Three unnamed buttons on one page are not three failed pages or three affected users. Check whether they share a component that can be fixed once.
Impact: prioritize with the actual task
Critical, Serious and other impact labels help prioritize review; they are not legal-risk scores. Check whether a finding blocks a main task, which states expose it and whether a shared-component fix applies, rather than only reducing totals.
Take one finding through a fix and re-test
Keep the page and interaction state consistent so the before-and-after results can be compared. Use a controlled test environment to avoid placing real orders or sending contact messages.
- Step 1
Record the page, browser, viewport, sign-in state and any expanded content.
- Step 2
Inspect the rule ID, element and explanation. If locating fails, restore the state and rescan; a locating failure does not mean the issue is gone.
- Step 3
Fix the code or content for the component’s purpose, for example by giving an unnamed button clear visible text.
- Step 4
Reload and scan the same state. Confirm that the original finding for that element is gone and check for new findings.
- Step 5
Repeat the relevant keyboard task and separately test announcements and clarity. Keep checks not performed marked as untested, then share a reviewed summary with the person responsible.
Automated checking is not a legal compliance guarantee
DevCheck helps people reviewing pages catch machine-detectable accessibility issues earlier, but no automated tool can fully certify WCAG, ADA, or legal compliance. Formal audits still require manual review, keyboard testing, assistive technology testing, and real-use judgment.
Who is this results guide for?
PMs and product people
Distinguish confirmed findings from untested scope, then discuss affected tasks, priorities and acceptance checks with the person making the fix.
QA
Record the screen and interaction state, re-test the same scenario after a fix, and keep unfinished keyboard and screen-reader checks marked as untested.
Designers and engineers
Connect each rule and element to its actual purpose. Check that the change removes the original barrier without breaking other interaction states.
Developers delivering client sites
When scan results or an audit report arrive, separate confirmed findings from items that still need judgment, then decide what to fix before handoff.
What would you like to check next?
Accesserty DevCheck
Explore the available checks, learn what stays on your device, and install DevCheck.
Web Accessibility Checker
Start with the page open in your browser, including local builds, staging sites, signed-in pages, and content revealed by interaction.
Automated Accessibility Checks Guide
Use this guide to understand what automated scans can find, what they miss, and when human confirmation is still required.
Frequently asked questions
Local scans, review lenses, simulations and PDF checks are free, with no DevCheck paid plan. Optional shared AI has daily and rate limits. Your own Gemini API key uses Google quotas, pricing and data terms; it is not unlimited or necessarily free.
No. DevCheck can detect many machine-testable issues, but full compliance still requires manual review, assistive technology testing, keyboard testing, and contextual judgment.
Level AA is the practical target commonly used in accessibility guidelines, policies, and procurement workflows to address many common barriers. DevCheck can help surface some A/AA-related clues, but it does not claim that a website has an official label or complete conformance proof.
No. DevCheck can support preliminary accessibility and regression checks, but it does not provide an ADA legal compliance decision and does not replace a formal audit or legal advice.
DevCheck uses axe-core for page scans and runs automated checks related to WCAG 2 A, WCAG 2 AA, and best-practice rules.
No. DevCheck is useful for cross-functional first checks and fast regression checks, but formal audits should still include manual review and assistive technology testing.
It supports PDF structure signal checks such as tagged pages, links, form fields, bookmarks and page-size consistency, not full PDF/UA certification. For now, check document language in a PDF reader or editor’s document properties; DevCheck’s “No language set” result does not confirm that language is missing.