Manual WCAG Accessibility Audits for Websites and Digital Products

A manual audit identifies accessibility barriers in the pages, components, and tasks included in the evaluation. We document where each issue occurs, how to reproduce it, its effect on users, and the relevant WCAG success criterion. Your team receives findings and recommendations it can use to plan fixes. The report also identifies what was tested and any exclusions; it does not imply that untested areas were evaluated.

We review the site's templates, interactive features, user roles, and essential tasks to agree on representative coverage. A checkout, for example, includes the cart, address fields, errors, payment steps, and confirmation. Testing one page from that process would leave important gaps. Our audit preparation guide explains what to share so the scope reflects how people actually use your product.

The price depends on the testing required, not simply the number of URLs. Shared templates, custom controls, authenticated roles, mobile coverage, and complete workflows all affect the effort. Reporting, an ACR, and follow-up retesting also affect the quote when requested. We review your website and requirements before specifying the scope, deliverables, exclusions, and price.

Allow time for testing, a findings review, implementation, and retesting before the date when you need verified results. The audit itself is only part of that schedule. Share your release or buyer deadline, available test environment, and development capacity at the start. We can then confirm a delivery plan and identify dependencies such as account access or an unfinished checkout integration.

Use the version and level specified by your customer, applicable requirements, or organizational policy. WCAG 2.2 adds criteria addressing issues such as obscured keyboard focus, dragging alternatives, target size, and accessible authentication. It does not automatically replace the version named in a contract or regulation. We can identify the requested target and any additional testing needed for a newer version before preparing the proposal.

No. A scan can find certain errors, but it cannot establish that a person can complete every task or that all applicable WCAG criteria are satisfied. A form may have labels and still fail when its errors are not announced or its submit button cannot be reached. Our manual and automated testing guide explains how the methods work together.

They are included when the proposal expressly identifies them. Mobile web testing needs defined devices and browsers; authenticated areas need test accounts for each relevant role. PDFs and third-party services may require separate access or specialist evaluation. Native mobile apps also need their own scope. Identifying these areas before kickoff helps prevent an important part of the customer journey from being overlooked.

Yes. If your customer needs an ACR, include that requirement when requesting the audit. We need to confirm the product version, reporting edition, standards, and coverage before testing. The findings report explains individual barriers; the ACR records conformance against the selected reporting criteria. See our VPAT and ACR service for the documentation and procurement support available.

The proposal identifies who will implement changes and whether follow-up testing is included. Your developers and content owners can use the findings to make corrections, with CompliCorp providing guidance where agreed. Remediation and retesting then check the affected functionality and record which findings are resolved, remain open, or could not be verified.

No. An audit provides technical findings within a defined scope; it cannot guarantee a legal outcome or prevent a complaint. Correcting barriers and verifying the changes can improve access and support your accessibility efforts. The evaluation should be followed by a plan for maintenance, since new content, software releases, and third-party updates can introduce further issues.