Representative output
What a developer remediation plan looks like
This example shows the shape of a work item produced from an existing axe-core finding. It is illustrative—not a customer result—and demonstrates how scanner evidence stays separate from implementation guidance.
Work item: Resolve insufficient text contrast
Preserved source evidence
Target: .account-summary .balance-label
Failure summary: Element has insufficient color contrast
WCAG tags: wcag2aa, wcag143
Developer guidance
Adjust the foreground/background color combination for the affected text so it satisfies the contrast requirement identified by the source rule. Prefer updating the shared design token or component style when the same combination is reused, rather than patching only one occurrence.
Acceptance criteria
- The affected text remains readable in its normal, hover, focus, and disabled states where applicable.
- The relevant axe-core color-contrast rule no longer reports this affected target after the change.
- The visual change does not remove a required state distinction or other non-color cue.
Retest
Run the same axe-core check against the updated interface and confirm the original target is no longer reported. Review the changed component visually at relevant states and zoom levels. Use appropriate manual testing for behavior that automated contrast checks do not establish.
What a full order adds
A processed report can contain multiple findings. The service validates accepted input before checkout, preserves source facts, prioritizes findings, and adds bounded remediation guidance, acceptance criteria, and retest steps so the result is easier to move into engineering work.
Turn my axe-core JSON into a planScope
This sample is not an accessibility audit, WCAG conformance certification, ADA determination, legal opinion, or claim that automated testing detects every accessibility barrier. Manual and assistive-technology testing remain important parts of accessibility work.