# How to Read WCAG Check Results and Re-Test Fixes

Read DevCheck’s WCAG-related scan results, decide what needs fixing or further review, and re-test the same page state. Zero findings is not a whole-site conformance decision.

## Purpose

Use the rule, affected element and task to decide what needs fixing or further review, then re-test the same state.

## Interpret the results

- Confirmed findings: inspect the rule and listed element. A button-name finding calls for a meaningful name matching the button’s purpose.
- Needs manual review: inspect the page and state, for example when a background color cannot be determined. Do not count it automatically as a pass or failure.
- Untested scope: unopened dialogs, other pages, complete keyboard flows and actual announcements need their own checks. They do not become passes when absent from the results.
- Counts: several elements can fail one rule, and one element can appear under several rules. Three unnamed buttons are not three failed pages or three affected users.
- Impact: use task importance and shared-component scope alongside impact labels. These labels are not legal-risk scores.

## Fix and re-test

Record the page, browser, viewport and interaction state. Inspect the rule and element, make a purpose-appropriate correction, reload and scan the same state, then repeat the related keyboard task and separately test announcements. A locating failure does not mean the finding disappeared. Keep unperformed checks marked as untested. Use a controlled test environment to avoid real orders or messages.

## 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.

## Is it free?

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.

## Limitations

DevCheck helps people reviewing pages catch machine-detectable issues and some semantic-quality risks earlier, but it is not an ADA compliance checker and cannot guarantee full WCAG, ADA, or legal compliance. Formal audits still require manual review, keyboard testing, assistive technology testing, and real-use judgment.

## Current Entry Points

- Understand WCAG check results: https://accesserty.com/en/wcag-compliance-tool/
- DevCheck product page: https://accesserty.com/en/devcheck/
- Web accessibility checker: https://accesserty.com/en/web-accessibility-checker/
- Automated accessibility checks guide: https://accesserty.com/en/guides/automated-accessibility-checks-limits/
- WCAG testing checklist: https://accesserty.com/en/guides/wcag-testing-checklist/
- PDF accessibility checker: https://accesserty.com/en/pdf-accessibility-checker/
- Chrome Web Store: https://chromewebstore.google.com/detail/accesserty-devcheck/ompbhahmipenipgiiiehbkiibkonoeec
- Firefox Add-ons: https://addons.mozilla.org/firefox/addon/accesserty-devcheck/