top of page

SysWisdom AI Quality Agent Delivers WCAG 2 2 Evidence Readiness with Playwright and axe core

  • Aaron
  • Jul 30
  • 7 min read

Fixing accessibility defects is only half the work now. The harder question in many procurement reviews is simple: can the organization prove what it checked, what it found, who owns the work, and how issues are tracked to closure?


SysWisdom.ai’s AI Quality Agent has reached a new milestone for WCAG 2.2 evidence readiness. The agent now combines Playwright, axe-core, and a governance evidence workflow to help teams scan, evaluate, document, and prove their WCAG 2.2 Level AA position across 56 success criteria, including 32 Level A and 24 Level AA criteria.


The key shift is the split between technical findings and governance evidence. A missing form label and an outdated accessibility statement are both important, but they are not the same kind of risk. SysWisdom keeps them separate from the start, which makes the final evidence package clearer, easier to review, and better aligned with procurement expectations.


Wide-angle view of a tablet mounted on an accessibility testing rig beside printed compliance checklists
Automated checks are useful when they feed a clear evidence trail.

Compliance now needs proof, not just cleaner code


For years, many teams treated accessibility work as a defect cleanup process. Run a scan, fix violations, rerun the scan, and report progress. That still matters, but it no longer answers the full set of questions buyers, auditors, and risk teams ask.


Procurement teams often ask for evidence such as:


  • A current VPAT or Accessibility Conformance Report

  • A named owner for the program

  • A public accessibility statement

  • A process for tracking reported issues

  • A record of recent testing

  • Proof that known issues are being fixed

  • Documentation that supports claims made in sales or security reviews


That is where Accessibility work becomes an evidence journey. The question is not only “Does this page pass a rule?” It is also “Can this organization show how it governs accessibility over time?”


SysWisdom’s milestone addresses both sides. It uses Playwright and axe-core for automated page testing, while its evidence evaluator reviews the governance materials that show whether the organization can support its claims.


The result is WCAG Accessibility Evidence that can be assembled, reviewed, and updated without forcing teams to rebuild the same packet by hand for every request.


The new milestone brings technical testing and governance review together


The AI Quality Agent is built around a simple idea: automated scans should feed an auditable record, not a loose spreadsheet.


Playwright handles browser automation. It opens the target page and runs checks in a real browser context. axe-core provides the accessibility rules engine. For this milestone, SysWisdom scans against the `wcag2a`, `wcag2aa`, and `wcag22aa` rule sets.


That covers a practical slice of WCAG 2.2 Level AA testing, while staying clear about the limits of automation. No automated scanner can confirm every WCAG requirement by itself. Some criteria require human judgment, content review, keyboard testing, assistive technology checks, or design review.


SysWisdom accounts for that by requiring human sign-off. The agent can collect evidence, flag problems, compare changes, and assemble the package. It does not pretend that an automated run equals a final legal or conformance decision.


That distinction matters. It keeps the process useful without overstating what software can prove.


The 8 steps of WCAG 2.2 evidence readiness


SysWisdom’s workflow is organized as an evidence journey. Each step produces structured output that can be audited later. Just as important, technical violations and governance gaps are never collapsed into a single score.


A single score might look tidy, but it hides the truth. Ten missing alt attributes are different from having no current accessibility statement. A broken keyboard path is different from a VPAT that cannot be traced to recent testing.


SysWisdom keeps those signals separate.


Close-up view of numbered evidence cards arranged in a shallow inspection tray
The evidence journey turns testing activity into reviewable records.

1. Discover scope


The journey starts by choosing the platform type and identifying available evidence sources. A public website, SaaS application, customer portal, documentation site, and embedded web view can all require different review paths.


The scope step answers basic but essential questions:


  • What is being assessed?

  • Which URLs or user flows matter?

  • What documents are available?

  • Which evidence sources can be reviewed?

  • Who owns the artifacts?


Good scope prevents evidence drift. It keeps the package tied to a defined product or experience rather than a vague claim.


2. Collect WCAG evidence


SysWisdom uses a WCAG MCP server to load the 56 WCAG 2.2 success criteria in scope for Level A and Level AA review. This gives the process a clear reference point before scanning begins.


That matters because evidence should map back to criteria. If a report says a product is being reviewed for WCAG 2.2 Level AA, the evaluation should show which criteria were considered and where the evidence came from.


The MCP server acts as the authoritative evaluation reference inside the journey. It keeps the remaining steps tied to the same standard.


3. Run an automated scan


The automated scan starts through `POST /accessibility/scan/launch`.


SysWisdom uses Playwright with axe-core to scan the target URL against these rule tags:


  • `wcag2a`

  • `wcag2aa`

  • `wcag22aa`


Playwright creates the browser context. axe-core checks the rendered page for known accessibility failures. The scan can identify issues such as missing accessible names, insufficient landmark structure, invalid ARIA patterns, and other detectable defects.


Automated testing is fast and repeatable. It works well for finding many common issues early. It also gives teams a baseline that can be compared over time.


But the scan remains one evidence source, not the whole assessment.


4. Evaluate evidence quality


The governance review is handled by `evidence_evaluator.py`.


Rather than treating documents as present or missing only, the evaluator scores governance evidence on four independent axes:


Evidence axis

What it checks

Completeness

Whether expected documents, owners, dates, and supporting records are present

Consistency

Whether claims align across statements, VPATs, reports, and issue records

Validity

Whether evidence appears current, relevant, and connected to the scoped product

Traceability

Whether findings can be traced to sources, criteria, dates, and owners


This makes the review more useful than a basic checklist. A VPAT may exist, but if it is old, inconsistent with the latest scan, or not linked to the product under review, it may not hold up well in procurement.


SysWisdom exposes those problems as governance gaps, not technical violations.


Gap reports stay honest by keeping issue types separate


The gap report is generated through `POST /accessibility/gap-report`.


This is one of the most important parts of the milestone. The report separates two kinds of evidence:


Technical violations

Governance gaps

Found through automated scan results

Found through document and process review

Tied to page behavior, markup, roles, labels, contrast, and related checks

Tied to ownership, documentation, validity, issue tracking, and traceability

Usually assigned to engineering, design, or content teams

Usually assigned to product, compliance, legal, support, or program owners

Verified through retesting and review

Verified through updated documents, process records, and sign-off


A clean scan does not prove good governance. Strong governance documents do not prove the interface works for users. Both matter, but they need different owners and different proof.


SysWisdom’s report structure makes that visible.


For example, a scan might find accessible name violations in a product settings flow. At the same time, the evidence review might find that the accessibility statement has not been updated since a major redesign. Those findings should not be averaged together. They should move through separate remediation paths.


Eye-level view of two labeled archive boxes for technical findings and governance records
Separate records make the final package easier to trust.

Recommendations map signals to remediation categories


Recommendations are requested through `GET /accessibility/recommendations`.


SysWisdom uses a signal-based rule table to map detected gaps into five remediation categories. Tools may be named as illustrative examples, but the point is not to push one tool or vendor. The point is to turn evidence signals into the right kind of next step.


A technical issue may call for code changes, design fixes, content edits, or test coverage. A governance issue may call for a current statement, a named owner, a review cadence, or a more traceable issue process.


This keeps the recommendations practical. Instead of handing teams a flat list of warnings, the agent helps sort the work by type.


That also makes ownership clearer. Engineering teams should not have to guess whether they are responsible for a missing VPAT update. Compliance owners should not have to interpret raw DOM violations. Each group gets the evidence it can act on.


Verification compares what changed


After remediation, teams need to prove movement. SysWisdom supports that through `POST /accessibility/verify`.


The verification step diffs two assessments and reports what changed across both tracks:


  • Violations resolved

  • Violations introduced

  • Governance gaps closed

  • Governance gaps still open

  • Evidence score delta


This is where the journey becomes more than a snapshot. A single scan can show the current state. A comparison can show whether the product and the program are improving.


That is valuable for release gates, procurement renewals, internal audits, and leadership updates. It also helps prevent backsliding. If a release fixes five issues but introduces three new ones, the evidence record should show both sides.


The final package is built for review


The journey ends with `POST /accessibility/generate-evidence-package`.


This step assembles an evidence package with eight sections. The exact contents can vary by scope, but the purpose is consistent: give reviewers a structured record of what was assessed, what evidence was found, what gaps remain, and what requires human approval.


A strong package should make these points clear:


  • The product or platform in scope

  • The WCAG 2.2 Level AA criteria reference

  • Automated scan inputs and results

  • Governance documents reviewed

  • Evidence quality scores

  • Technical violations

  • Governance gaps

  • Recommendations, verification results, and sign-off status


Human sign-off remains required. SysWisdom can prepare the evidence and make the review far easier, but it should not replace accountable review by qualified owners.


That is a strength, not a weakness. Real accessibility governance needs judgment. The agent’s job is to reduce manual evidence work and make the review trail harder to lose.


Overhead view of a sealed evidence folder with inspection tags and accessibility symbols
A complete package should be ready for review, not just stored for later.

Why this milestone matters for AI Quality


The phrase “AI Quality Agent” can sound broad, but this milestone is concrete. It connects automated testing, criteria mapping, governance review, gap reporting, recommendations, verification, and package generation into one repeatable flow.


That helps teams avoid common failure points:


  • Scans stored without context

  • VPATs that do not match current product behavior

  • Accessibility statements that go stale

  • Findings tracked in systems with no clear audit trail

  • Technical and governance problems mixed into a vague risk score

  • Manual evidence packets rebuilt for every buyer request


SysWisdom’s approach is useful because it treats accessibility as an operating practice. The end product is not just a list of defects. It is an evidence record that can support a real review.


For teams preparing for WCAG 2.2 Level AA expectations, that changes the shape of the work. The goal becomes a clear, repeatable evidence journey:


Scan. Evaluate. Document. Prove.


The milestone does not remove the need for skilled accessibility review. It makes that review better supported. It gives technical teams cleaner findings, governance owners clearer gaps, and procurement reviewers a package that shows the work behind the claim.


That is the real value of evidence readiness. It turns scattered activity into a record that can be trusted, challenged, improved, and signed off.


Comments


bottom of page