Accessibility Testing Services for Web & Apps

A complete scope can include WCAG audit work, automated scanning, keyboard testing, screen-reader testing, mobile and document checks, remediation guidance, retesting, and VPAT or ACR support. The statement of work should name every included product, journey, environment, method, artifact, and retest round.

No. Automated tools find only issues that their rules can determine. W3C states that tools cannot check every accessibility aspect and human judgment is required. Use scans for speed and repeatability, then validate scope, context, usability, and conformance with qualified reviewers.

Choose the version required by law, contract, procurement policy, or internal standard. W3C recommends WCAG 2.2 as the current conformance target, while some legal rules still name WCAG 2.1. Record the approved version and level before testing starts.

Start with high-value and high-risk tasks such as registration, authentication, search, forms, checkout, payment, account management, support, and document access. Add shared templates, navigation, design-system components, error states, responsive views, and third-party widgets that affect those tasks.

Provide product URLs or builds, user roles, test accounts, critical journeys, supported environments, release plans, design files, known issues, analytics where approved, and the required standard. Name product, engineering, design, content, compliance, security, procurement, and legal decision owners.

Select combinations that reflect supported users, platforms, procurement needs, and product risk. Typical coverage may include NVDA or JAWS on Windows, VoiceOver on Apple platforms, and TalkBack on Android. The contract should name exact operating system, browser, device, and version assumptions.

Timeline depends on product scope, templates, user roles, state complexity, devices, assistive technologies, access setup, report depth, and retest rounds. Discovery should produce a coverage model and estimate. A simple page count often understates dynamic states and shared component risk.

The main drivers are scope, platform count, supported environments, document volume, authentication, complex widgets, custom controls, procurement artifacts, user testing, remediation support, and retesting. Costs also rise when evidence must support several standards, products, languages, or release trains.

Each issue should include a stable ID, affected page or component, environment, requirement, user impact, severity, reproduction steps, evidence, expected behavior, repair guidance, owner, and retest result. The summary should state coverage, exclusions, unresolved risk, and decision owners.

Yes. Testing can supply evidence for the applicable VPAT edition and its resulting Accessibility Conformance Report. Product, compliance, legal, and procurement owners should review the scope, support levels, remarks, exceptions, tested version, and publication decision before release.

AI can assist with issue grouping, report drafting, code suggestions, test generation, and content review. It should not make an unreviewed conformance decision. Require source evidence, reproducible results, privacy controls, version records, and named human approval for findings and repair advice.

Buyers should expect more checks inside design systems, code review, component testing, and release pipelines. AI may accelerate triage and repair suggestions. Human judgment, assistive technology testing, disabled-user participation, governance, and traceable evidence will remain important for complex journeys and claims.