I have spent most of my career in the uncomfortable middle seat between legal, engineering, and design, helping organizations select and implement the right enterprise accessibility platform. My job is convincing all three teams that digital inclusion is an ongoing operational standard rather than a one-time project. Every year, I watch the same pattern play out inside large companies: a team hires an outside firm, receives an audit snapshot, fixes the flagged items, and celebrates. Six months later, a new code release quietly reintroduces half of the exact same compliance violations.
If you lead digital strategy at a company with more than a handful of digital properties, this cycle probably sounds familiar.
WCAG 2.2 made this pattern harder to ignore. The updated Web Content Accessibility Guidelines added success criteria that touch elements developers ship every day—focus indicators, drag interactions, login forms, and touch target sizes. You cannot catch drift at scale with an annual audit and a spreadsheet.
You need a unified platform that monitors your code and live pages continuously, feeds findings into standard engineering workflows, and honestly flags what automation cannot see. This guide details how to approach continuous compliance once you stop treating accessibility as a static checklist.
What Actually Changed in WCAG 2.2
WCAG 2.2 became a formal W3C Recommendation in October 2023. It added nine new success criteria on top of 2.1. Most of them cluster around three themes that show up constantly in enterprise applications.
Focus Visibility
Success Criteria 2.4.11 and 2.4.12 are both named Focus Not Obscured. They require that a sticky header or a chat widget never fully hides an element when a user tabs to it. Anyone who has built a single page application with a persistent navigation bar knows how easily this breaks.
Input Flexibility
Success Criterion 2.5.7, Dragging Movements, says any drag interaction needs a single pointer alternative. That matters a lot for the kanban boards and sliders that fill enterprise dashboards. Success Criterion 2.5.8, Target Size, sets a minimum touch target of 24 by 24 CSS pixels for most interactive elements. This is a real problem for teams that built dense data tables and icon toolbars long before mobile accessibility was on anyone’s radar.
Authentication and Form Friction
Redundant Entry, Success Criterion 3.3.7, says users should not have to type the same information twice without a good reason. Accessible Authentication, covered by Success Criteria 3.3.8 and 3.3.9, restricts cognitive function tests like puzzle CAPTCHAs unless an alternative exists. Consistent Help, Success Criterion 3.2.6, requires that help mechanisms like a chat link or contact page appear in the same relative order across pages.
The guidelines also quietly retired Success Criterion 4.1.1, Parsing. Modern browsers handle malformed markup well enough that the old rule stopped serving a purpose. None of this is exotic. It is the everyday texture of enterprise software, and that is exactly why a platform approach beats a project approach here.
The Problem with Point in Time Audits
A traditional audit gives you a snapshot. Someone runs a scan, a specialist does manual testing with a screen reader, and you get a report with severity ratings. Your team works through a backlog. That process has real value, and I still use it for deep dives into complex components.
A snapshot cannot tell you what happens the week after the audit closes. Three teams might ship four releases. A marketing agency might drop in a new promotional banner without anyone from accessibility in the room.
I have sat through enough executive reviews to know the question that always comes up. Are we still compliant right now, today, not six months ago? Nobody can answer that from a PDF.
The only honest answer comes from continuous monitoring. It rescans production and staging on a schedule. It flags regressions the moment they appear, and it ties every finding back to a specific commit or deployment. That is the core promise of an enterprise accessibility platform. It is also the reason I stopped recommending audit only engagements to clients with more than a few dozen pages or components.
Why Automated Scanning Cannot Carry the Whole Program
I want to be direct here, because vendors are not always honest about this. The overselling undermines trust in the whole discipline. A widely cited analysis of the WCAG 2.2 AA success criteria found that only about 13 percent, seven out of fifty five criteria, can be reliably flagged by automated tools with a low false positive rate.
What Automation Actually Catches
Another 45 percent are only partially detectable. A scanner might catch part of a violation but miss the piece that actually determines whether a person with a disability can use the page. The remaining 42 percent require human judgment entirely, because they depend on meaning, context, or the quality of an experience.
No single WCAG success criterion can be fully and conclusively verified by automation alone. Scanners are excellent at color contrast ratios, missing form labels, missing document language, and empty links. They are useless for judging whether alternative text actually describes an image, or whether instructions make sense to someone using a screen reader for the first time.
What the Data Actually Shows
The WebAIM Million report evaluates the home pages of one million websites every year. It backs this up from a different angle. The most recent report found an average of 56.1 detectable errors per home page, up from 51 the year before. That is a 10.1 percent increase. Almost 96 percent of pages, 95.9 percent to be exact, had at least one detectable WCAG failure.
Six issue types made up 96 percent of all errors. Low contrast text appeared on 83.9 percent of pages. Missing alternative text showed up on 53.1 percent, and missing form labels appeared on 51 percent. Empty links showed up on 46.3 percent of pages, empty buttons on 30.6 percent, and missing document language on 13.5 percent.
Every one of those issues is something automation catches well. Yet the error count keeps climbing. The problem is not that automated tools are inadequate on their own terms. Most organizations run a scan once, fix what it finds, and stop. They rarely run it continuously or pair it with the manual review that catches everything else.
An enterprise accessibility platform earns its keep by doing both things honestly. It automates the 13 percent that automation does well, at a scale no manual team could sustain. It also routes the rest to trained testers, including people who actually use assistive technology, on a defined cadence rather than never.
Building Accessibility Into the DevOps Pipeline
This part of the job used to feel like a losing argument. It now feels like common sense to most engineering leaders I work with. If accessibility testing only happens after code ships, you are always fixing things retroactively. Retroactive fixes cost more, and they are more likely to get deprioritized behind the next sprint’s features. An enterprise accessibility platform turns that habit around by making the check automatic instead of optional.
Shifting Testing Left
The alternative is to treat accessibility checks the way you treat unit tests or security scans. Make it a gate inside the CI/CD pipeline that runs on every pull request. Section508.gov’s guidance on this is refreshingly practical. It recommends running automated tools like axe-core or Pa11y-ci on every commit. It also recommends integrating with whatever pipeline the team already uses, and setting clear failure criteria so a build fails when it introduces a critical violation.
A Layered Testing Setup
In practice, I push teams toward four layers working together. Code level linting catches issues while a developer is still writing a component. It uses accessibility plugins in the editor itself, which is the cheapest place to fix anything. Automated scans then run again in the CI pipeline against a built preview of the page.
Scheduled crawls run continuously against staging and production. Content management systems and third party scripts change pages outside the normal code review process, so this layer catches what the earlier ones miss. Manual and assistive technology testing runs on a set cadence, focused on new components and any workflow the automated layers flagged as only partially testable.
The goal here is not to block every release over a font color that is slightly too light. It is continuous visibility. Every finding should show up as a ticket with the specific success criterion it violates, plus a recommended fix. An engineer should be able to act on it without becoming an accessibility expert first. When that pipeline exists, WCAG 2.2 compliance stops being a quarterly fire drill. It becomes a property of how the team already works.
What an Enterprise Accessibility Platform Actually Does Differently
A lot of tools call themselves an enterprise accessibility platform without earning the label. It is worth being specific about what separates a genuine one from a browser extension with a dashboard bolted on.
Scale across properties matters first. Enterprises rarely have one website. They have a marketing site, a customer portal, an internal intranet, and often several product lines, each with its own front end. A real platform crawls and monitors all of them from one place. Role based access lets a product team see only its own findings while leadership sees the whole picture.
Developer native integration matters just as much. Findings need to live where developers already work, inside the pull request, the ticketing system, and the CI output. They should not be buried in a separate portal nobody opens after the initial rollout.
Historical trend data is the third piece. Leadership does not just want today’s error count. They want to know whether the trend line is going down, which teams are improving, and where regressions keep coming from. That is what justifies headcount and budget for the next fiscal year.
An honest split between automated and manual coverage matters too. Look for a visible workflow that routes what automation cannot verify to qualified human testers, including testers with disabilities. Any platform that implies a green checkmark means full WCAG 2.2 conformance is not being straight with you, and I say that to prospective vendors directly in every evaluation call.
Finally, mapping to legal and regulatory frameworks beyond WCAG itself matters for most enterprises. Many are managing exposure under the ADA, Section 508, and the European Accessibility Act all at once. Good reporting speaks to each without maintaining three separate spreadsheets.
A Practical Framework I Use With Clients
When I roll out an enterprise accessibility platform for a new client, I generally move through the same sequence.
I start with an inventory of every digital property that needs coverage, including subdomains and mobile apps. You cannot monitor what you have not listed. Then I set a baseline using both an automated crawl and a manual audit against the WCAG 2.2 AA criteria. This tells us honestly where things stand before adding any tooling.
Next, I connect the platform to the CI/CD pipeline. I configure failure thresholds with engineering leadership, so the gate reflects real severity rather than flagging everything equally. After that, I set a recurring manual testing cadence, usually quarterly for stable properties and monthly for anything under active development.
I build a reporting cadence for leadership that shows trend lines rather than a single snapshot. I also train developers and designers on the handful of success criteria that generate the most findings in their specific codebase. A generic WCAG overview does not stick the way a targeted one does. Finally, I revisit the whole program twice a year, because standards evolve and a process built for 50 engineers needs adjustment at 500.
That sequence is not glamorous. It moves an organization from reactive fixes to a program that holds up under a regulator’s questions or a plaintiff’s discovery request.
Measuring Progress the Way Leadership Actually Cares About
Accessibility teams lose credibility with executives when the only metric they report is a raw error count. That number moves for reasons that have nothing to do with program quality, like a new property being added to the crawl. A well configured enterprise accessibility platform should make better metrics available without extra manual work.
I report on trend per property over time and mean time to remediate a critical finding. I also track the percentage of new pull requests that pass the accessibility gate on the first try. Another useful number is the ratio of automated to manually verified findings closed each quarter, because that shows leadership the program is not just running scans and calling it done.
It also helps to connect the metrics to risk that leadership already tracks elsewhere. Website accessibility litigation is not a theoretical risk. Federal courts saw 3,117 website accessibility lawsuits filed in 2025. That is a 27 percent jump from 2,452 in 2024, reversing two years of decline.
Those cases grew from 28 percent to 36 percent of all federal ADA Title III litigation in that same period. That is an 8 percentage point increase in a single year. Putting that number next to our own trend line tends to focus a budget conversation fast, even though doing the right thing is the actual reason most of us are in this field.
Common Pitfalls I See Repeatedly
The most common mistake is treating an enterprise accessibility platform rollout itself as the finish line. Buying a tool and connecting it to a pipeline is maybe a quarter of the work. The rest is building the human process around it: who triages findings, who owns the backlog, and who has authority to block a release.
Over trusting automated pass rates is the second mistake. I have reviewed properties that scored well on every automated metric and still failed basic screen reader testing on the primary purchase flow. A scanner cannot judge whether a sequence of interactions actually makes sense out loud. Treat a clean automated scan as a floor, never a ceiling.
Skipping people with lived experience of disability is the third mistake. Guidance from Section508.gov and most serious accessibility practitioners agrees on this point. Automated tools plus sighted manual testers still miss things that a blind screen reader user or someone with a motor impairment catches immediately. Build that testing into your cadence as a recurring part of how you validate releases, not as an occasional research study.
Where This Leaves You
WCAG 2.2 did not reinvent accessibility. It sharpened the areas where enterprise software tends to be weakest: focus management, input flexibility, and authentication friction. None of that gets solved by a once a year audit. None of it gets solved by automation alone either.
The organizations I see succeed build accessibility into the same pipelines, dashboards, and review cycles they already trust for everything else. They pair automated coverage honestly with the manual and assistive technology testing that catches what a scanner never will. An enterprise accessibility platform is the infrastructure that makes that sustainable at scale. The discipline to actually use it that way is still on your team.
Frequently Asked Questions
What is the difference between an accessibility audit and an enterprise accessibility platform?
An audit is a one time or periodic assessment, usually delivered as a report. An enterprise accessibility platform provides ongoing monitoring, integrates with development workflows, and tracks compliance trends over time rather than capturing a single moment. The W3C’s WAI overview of WCAG is a useful starting reference for what any audit or platform should be measuring against.
Can automated scanning tools alone achieve WCAG 2.2 compliance?
No. Research summarized by Accessible.org found that only about 13 percent of WCAG success criteria can be reliably detected by automated scanners. The rest need partial or full manual verification. Automated tools are a necessary layer, not a complete solution.
Which WCAG 2.2 success criteria matter most for enterprise applications?
In my experience the highest impact criteria are Focus Not Obscured, Target Size, Dragging Movements, and Accessible Authentication. These map directly to patterns like sticky navigation, dense dashboards, drag and drop interfaces, and login flows common across enterprise software. The full list is documented on the W3C’s What’s New in WCAG 2.2 page.
How often should accessibility scans run in a CI/CD pipeline?
Ideally on every pull request or commit. Pair that with a separate scheduled crawl of live staging and production environments, since content changes happen outside the normal development process too. Section508.gov’s guidance on incorporating accessibility conformance into the development lifecycle covers this in more depth.
What business risk does non compliance actually create?
Litigation risk has grown substantially. Federal website accessibility lawsuits reached 3,117 filings in 2025, according to reporting from ADA Title III. That is a meaningful increase from the prior year. Beyond litigation, there is reputational risk and, for many enterprises, direct loss of customers who cannot complete a purchase or application.
Do enterprise accessibility platforms replace the need for manual testing?
No, and any vendor claiming otherwise should be questioned closely. The strongest programs use platforms to automate what can be automated reliably. They route everything else, including subjective judgments about usability and meaning, to trained human testers on a recurring schedule.
References
WebAIM. The WebAIM Million: The 2026 Report on the Accessibility of the Top 1,000,000 Home Pages. https://webaim.org/projects/million/
W3C Web Accessibility Initiative. What’s New in WCAG 2.2. https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
W3C Web Accessibility Initiative. WCAG 2 Overview. https://www.w3.org/WAI/standards-guidelines/wcag/
Accessible.org. Accessibility Scans Reliably Flag 13% of WCAG Criteria. https://accessible.org/automated-scans-wcag/
Deque Systems. CI/CD Integration for Accessible Development. https://www.deque.com/accessible-development/ci-cd/
Section508.gov. Effective Methods and Tools for Incorporating Accessibility Conformance Validation Within Development Processes. https://www.section508.gov/develop/incorporating-accessibility-conformance/
ADA Title III. Federal Court Website Accessibility Lawsuit Filings Bounce Back in 2025. https://www.adatitleiii.com/2026/03/federal-court-website-accessibility-lawsuit-filings-bounce-back-in-2025/
Level Access. Accessibility Testing in CI/CD: What It Is, How It Works, and Why It Matters. https://www.levelaccess.com/blog/accessibility-testing-in-ci-cd-what-it-is-how-it-works-and-why-it-matters/