SaaS accessibility follows a defined sequence: audit, remediation, validation, and ACR issued. That’s the path to WCAG conformance with the right documentation for EAA and ADA compliance.
Our SaaS clients have spiked in 2026. Digital accessibility is now a part of the procurement process. Here’s the full breakdown of the fairly simple digital accessibility process for SaaS companies in 2.5 minutes.
| Stage | What It Covers |
|---|---|
| WCAG Conformance | The technical standard your product is measured against |
| Accessibility Audit | Expert evaluation that identifies every conformance issue in your product |
| Remediation | Development work to fix the issues the audit identified |
| Validation | Confirming each fix was implemented correctly |
| VPAT / ACR | Documentation that reports your product’s conformance to buyers |
WCAG Conformance for SaaS
The Web Content Accessibility Guidelines (WCAG) are the technical standard for digital accessibility. For SaaS products, WCAG 2.1 AA is the conformance target. It covers the full range of accessibility requirements across visual, auditory, motor, and cognitive dimensions.
WCAG is organized around four principles: perceivable, operable, understandable, and robust. Within those principles are success criteria, which are specific, testable requirements your product either passes or does not pass. Meeting all of them at the AA level means your product is conformant.
WCAG 2.2 AA is the current version and is increasingly requested, particularly in the public sector. Most enterprise procurement still specifies 2.1 AA as the baseline. If your product is pursuing government contracts, build toward 2.2 AA from the start.
Automated scans such as WAVE or Axe can flag roughly 25% of WCAG issues. The remaining 75% require an accessibility audit by qualified experts. A passing scan score does not indicate conformance.
Accessibility Audit
An accessibility audit is a comprehensive evaluation of your SaaS product conducted by technical accessibility experts. The audit identifies every instance of non-conformance with WCAG success criteria and produces a detailed report.
For SaaS products, scope typically includes core user flows: login, onboarding, primary workflows, settings, and any reporting or dashboard views. Complex interactive components like modals, data tables, drag-and-drop interfaces, and custom form controls require close attention and are frequent sources of issues.
Third-party integrations such as embedded payment processors, chat widgets, mapping tools, and analytics overlays often introduce issues that fall outside the development team’s direct control. Remediating these can require vendor coordination or technical workarounds. Scoping them accurately up front keeps the project on track.
The audit report documents each issue by success criterion, affected component, severity, and recommended fix. This report becomes the foundation for remediation.
Audit scope and cost are driven by the number of pages or views in scope, the complexity of interactive elements, and the number of user roles tested. A SaaS product with multiple user roles may require separate audit passes for each role if the interface differs meaningfully.
Remediation
Remediation is the development phase where your team fixes the issues the audit identified. Issues are typically organized by severity and user impact so that the highest-risk items are addressed first.
Most SaaS teams distribute remediation across sprints. The audit report maps directly to this. Each issue is a discrete task with a clear acceptance criterion. Teams using our Accessibility Tracker platform can import audit issues directly and work through their remediation workflow with built-in Risk Factor and User Impact prioritization formulas and progress reporting.
Remediation timelines vary by product complexity and team capacity. A focused effort on a mid-complexity SaaS product typically runs four to eight weeks. Larger products with many unique interfaces extend beyond that.
Validation
Validation confirms that the fixes made during remediation were implemented correctly and that no new issues were introduced.
The original auditor re-tests each remediated issue against its WCAG success criterion. Issues that pass are marked resolved. Issues that need adjustment are returned to development with updated notes. This cycle continues until all issues are resolved.
Accessible.org recommends a 20-25% incremental approach to validation. Work through a batch of fixes, validate that batch, confirm the team is on the right track, then continue with the next. This prevents a misunderstanding about implementation from carrying through dozens of issues before anyone catches it.
Validation is not optional. Development teams can introduce new issues during remediation, particularly when fixing one component affects others. Skipping validation means going to market with unverified conformance.
Once validation is complete, the auditing organization can issue a conformance statement and provider certification confirming the product’s WCAG 2.1 AA status. This documentation is frequently requested during enterprise procurement.
VPAT and ACR
A VPAT (Voluntary Product Accessibility Template) is a standardized template published by the IT Industry Council. When completed, it becomes an Accessibility Conformance Report (ACR). The ACR is the document your sales team sends to enterprise and government buyers who require accessibility documentation before purchasing.
ACRs are required or strongly expected in federal government procurement, higher education contracts, healthcare procurement, and increasingly in corporate vendor reviews. If your SaaS product serves these markets, an ACR is a commercial necessity.
An ACR can only be completed after a thorough audit. It maps the audit findings to each WCAG success criterion and rates conformance as Supports, Partially Supports, Does Not Support, or Not Applicable.
Most SaaS companies use the WCAG edition of the VPAT. It covers the needs of most web apps, mobile apps, and software products. The Section 508 edition is required for U.S. federal sales. EN 301 549 aligns with European requirements, including the EAA. The INT edition combines all three for products sold across multiple markets. Your buyer’s requirements drive edition selection.
ACRs don’t have a formal expiration, though we recommend updating them when significant product changes are released. Buyers increasingly request dated ACRs and ask vendors to confirm the document reflects the current version of the product.
For more on the VPAT/ACR process, including edition selection and what procurement teams look for, Accessible.org covers it in detail.
Frequently Asked Questions
When does a SaaS company need to be WCAG conformant?
Any SaaS product selling to enterprise, government, healthcare, or higher education buyers faces accessibility requirements at some stage of procurement. Beyond sales, several state and federal laws create legal obligations for products in those markets. Building toward WCAG 2.1 AA conformance early is more efficient than remediating a mature product under deadline pressure.
How long does the full process take from audit through validation?
For a mid-complexity SaaS product, the full cycle from audit through validation typically runs two to four months. Products with complex interfaces, many user roles, or large backlogs of existing issues take longer. Starting the audit early in a development cycle rather than after launch reduces total remediation time.
Do we need an ACR if we don’t sell to the government?
Enterprise buyers outside the public sector increasingly request ACRs as part of security and vendor review processes. Healthcare, financial services, and large corporations often require them. Whether your product needs one depends on your customer base, but the trend is toward broader ACR requirements across industries.
Can our developers evaluate conformance instead of hiring a third party?
Internal review can surface some issues, but it rarely covers the full WCAG success criteria set and typically misses assistive technology evaluation that a qualified auditor conducts. Third-party audits carry more weight in procurement contexts than self-reported assessments.
What’s the difference between an accessibility scan and an accessibility audit?
A scan is automated. It checks your product against a subset of detectable criteria and flags roughly 25% of potential WCAG issues. An audit is a thorough evaluation by technical experts that covers the full WCAG success criteria set. An audit produces a complete picture of conformance; a scan produces a partial one.
Summary
Accessibility in a SaaS product is a build decision made incrementally over time. The process is defined and repeatable. Starting with a clear picture of where your product stands is the most direct path forward.
Contact Accessible.org to get started with an audit.
