A finding should lead to a useful next action. Telling a developer that an image lacks a text alternative is true and still leaves the work: what text, in this component, in this framework.
This service connects a finding with relevant guidance and a code-level suggestion, grounded in reference material, so a developer can understand the problem and review a correction in context.
The problem
Developers receive findings without a fix and generic AI suggestions with no source. A confident but wrong patch can introduce a new accessibility problem while appearing to fix the first.
What the system does
- An authenticated API that accepts a structured finding and safe surrounding context.
- Retrieval of relevant guidance, so explanations point to reference material.
- A suggested change shown as a review item, with a path to choose a direct-model route.
- Contract and validation tests that check the request and response shapes.
A representative journey
- Step 1: Receive a findingThe service gets the rule, the element and limited context, validated against a contract.
- Step 2: Retrieve guidanceRelevant reference passages are found for that rule and that kind of element.
- Step 3: Prepare an explanationA plain-language explanation is written from the retrieved guidance, with its source.
- Step 4: Suggest a changeA proposed code change is returned as a suggestion, marked as needing review.
- Step 5: Developer reviewsThe developer adapts the suggestion to the real component and its behaviour.
- Step 6: Re-run the checkThe relevant check runs again. A suggestion is not counted as resolved until it passes.
Finding in
SyntheticRule: image has no text alternative. Element: img.hero in a product card.
Reference guidance retrieved
- Guidance A · text alternatives for informative images
- Guidance B · when an image is decorative
Suggested change
Needs developer review- <img class="hero" src="/product.jpg"> + <img class="hero" src="/product.jpg" + alt="Blue ceramic mug on a wooden table">
Explanation cites Guidance A. State: suggested, not applied. Resolved only after review and a passing re-check.
Working prototypeUse a small working version of this on invented data, the way a person would.
Try the prototypeInspect the system
This anatomy is a proposed description of how such a system is put together. It is not an audit of a specific deployment.
Inspect the system
How Accessibility remediation with RAG is put together
- What it is
- Issue payload and contractA structured finding with limited context.
- What flows through it
- A rule, an element and snippet go in. A validated request comes out.
- The decision
- A fixed contract keeps requests small and testable.
Read the whole system as a list
- Issue payload and contract. A structured finding with limited context. Flow: A rule, an element and snippet go in. A validated request comes out. Decision: A fixed contract keeps requests small and testable.
- Context and permission checks. Authenticates the caller and limits what context is accepted. Flow: A request and credentials go in. An accepted or refused request comes out. Decision: Only the context needed is accepted.
- Retrieval and model route. Finds guidance and selects a model path. Flow: The finding goes in. Relevant reference passages and a model response come out. Decision: Explanations are grounded in retrieved guidance, with a selectable direct-model path.
- Explanation and patch suggestion. Writes the explanation and a proposed change. Flow: Guidance and the finding go in. An explanation with a cited source and a suggested change come out. Decision: The suggestion is labelled as needing review.
- Human review and re-check. A developer adapts the change and a check is re-run. Flow: A suggestion goes in. A reviewed change and a check result come out. Decision: A change counts as resolved only when the relevant check passes after review.
Key decisions
Retrieval before generation
Grounding explanations in reference guidance makes them checkable and reduces confident invention.
A suggestion is not a fix
Suggested code goes to a person and to a re-run of the check. Passing one check also does not prove the whole issue is gone.
Validate what goes in
Context is validated and limited, so the service does not receive more of a customer's code than it needs.
Outcomes and limits
We publish no measured outcomes for this project, because we have none we can evidence. The description above is of what the system does, not of results it has produced.
- No automatic repository edits, production deployment or support for every framework is claimed.
- Suggested code is not proof that an accessibility issue is fully resolved.
- This is anonymised professional experience. The service is not presented as a Nupgrade product.
Guardrail
A suggested change is a proposal. A developer reviews it and the relevant check is re-run before it counts as fixed.
Technical detail
Technology named in the portfolio for this kind of system. Which parts a given engagement used is not stated.
- Amazon Bedrock
- Retrieval index
- REST API
- Authentication
- Contract tests