Fix accessibility issues and verify the results.

Yes. We review the report, confirm the affected product version, and reproduce the findings before planning fixes. Useful evidence includes locations, steps, test conditions, and the applicable WCAG criteria. If important details are missing, we identify the additional evaluation needed. This avoids spending development time on ambiguous instructions or treating an old report as a complete picture of the current product.

Both arrangements can be considered during scoping. Direct implementation depends on the technology, access, and your development controls. Where your team owns the code changes, we can explain findings, review proposed solutions, and retest agreed fixes. The proposal identifies responsibilities and deliverables. Document remediation is separately scoped when PDFs or Office files also need work.

Start with barriers that prevent important tasks, then consider how many people and locations are affected and whether a shared component is responsible. A keyboard trap in account access may block the entire service. Fixing a shared control may resolve repeated problems, but its different uses still need checking. The remediation planning guide explains how to assign priorities without treating lower-priority findings as optional.

We assess the findings, their underlying causes, the technology, and the work needed to verify corrections. A defect repeated on many pages may have one shared fix; a single custom workflow may need substantial redesign. Developer availability, approvals, and third-party dependencies affect the schedule. We agree on responsibilities and milestones before committing to the implementation and retest plan.

Document the barrier, identify the vendor responsible, and ask for a correction or a usable alternative. Your team may be able to change configuration or replace the component, but it may not control the underlying code. We can help explain the technical finding and evaluate proposed changes within the engagement. Keep unresolved dependencies visible in the remediation plan and reporting.

We repeat the relevant test against the agreed criteria in the updated product and check related behavior where appropriate. The record identifies the build, result, and remaining limitations. A developer marking a ticket complete or a scanner returning fewer errors is not sufficient by itself. The retest report distinguishes verified corrections from open issues and items that could not be evaluated.

Only when report updates are included in the scope. Retest results provide evidence for changes to an ACR, but the ratings and remarks still need review against the report's product version and coverage. Keep the findings register and customer-facing report consistent. Our ACR reporting service can include updates based on the agreed evaluation.

Feed verified fixes into shared components, content templates, and release checks. Give each team practical acceptance criteria and examples relevant to its work. Automated checks can catch recurring detectable errors, while manual checks cover important interactions and new features. Accessibility training helps designers, developers, QA staff, and authors apply the lessons from the audit to their next release.