Recently, the Web Accessibility Initiative posted on LinkedIn asking for feedback on their Accessibility Maturity Model. While we will be submitting answers to the specific questions in their post, we’d like to also comment on a bigger question: Why does this Accessibility Maturity Model even exist, in the first place? There are strong sentiments that an accessibility maturity model makes no sense and that, instead, organizations should simply use a more mainstream framework like Six Sigma or CMMI.
This question speaks to a broader tension in organizational development: when is it worth building a domain-specific framework, and when should we rely on established general models? Accessibility makes this debate especially interesting because it carries a mix of technical, cultural, and legal imperatives that don’t sit neatly inside traditional process improvement systems.
Why Accessibility Might Warrant Its Own Model
One of the strongest arguments for a distinct accessibility maturity model is that accessibility requires a level of domain-specific expertise that general frameworks were never designed to capture. Six Sigma is about reducing defects through statistical control, and CMMI is about standardizing and optimizing processes. Neither speaks directly to the work of ensuring compatibility with assistive technologies, managing alternative formats for media, or embedding inclusive design into product development lifecycles. Accessibility teams must know international standards such as WCAG, Section 508 in the United States, and EN 301 549 in the EU. They must also understand testing methodologies that are unique to accessibility: keyboard navigation, high contrast modes, and compatibility with diverse assistive technologies.
Accessibility also involves stakeholders that general models overlook. Employees and customers with disabilities, assistive technology vendors, advocacy groups, and accessibility specialists are not peripheral actors – they are central to how an organization demonstrates maturity in this area. Where most frameworks think in terms of business units, processes, or roles, accessibility requires engaging communities whose lived experience of disability directly shapes the effectiveness of products and services.
The metrics for success are also different. Six Sigma tracks defects per million opportunities. CMMI asks whether processes are predictable and repeatable. Accessibility, by contrast, measures things like the degree of WCAG conformance, the speed of issue remediation, the adoption of inclusive design practices, and, most importantly, whether people with disabilities can actually use the product with independence and dignity. In some cases, cultural markers, such as whether disability inclusion is reflected in corporate communications or decision-making structures, are as important as technical indicators.
Finally, accessibility has a profound cultural and social dimension. It is not simply a technical matter; it is also a civil rights issue. Organizations progress not only by embedding technical practices, but by cultivating a culture where accessibility is seen as everyone’s responsibility and where people with disabilities are present in leadership and decision-making. General process frameworks rarely reach this level of cultural transformation.
The Case Against a Separate Model
Still, there are strong counter-arguments. Many organizations are already saturated with frameworks and methodologies. They use ISO standards for design, ITIL for service management, Six Sigma for quality, CMMI for software maturity. Adding another model risks what some call “framework fatigue,” where resources are consumed by documenting compliance with models rather than delivering meaningful results. Accessibility leaders could spend time filling out assessment spreadsheets when that time might be better spent fixing accessibility bugs or training designers.
A separate model also risks reinforcing the very silo it aims to dismantle. Accessibility should be woven into procurement, training, communications, and the development lifecycle. If it sits in its own parallel maturity model, organizations may treat it as a specialized add-on rather than a core part of business processes. Integration into existing models may encourage accessibility to be taken seriously at the enterprise level, rather than confined to specialist teams.
There is also the question of redundancy. CMMI already covers process standardization, repeatability, and continuous improvement. Six Sigma already teaches organizations how to measure and reduce defects. These frameworks could be extended with accessibility-specific criteria, avoiding the need to create a wholly new model. For smaller organizations, which often have limited bandwidth and budgets, layering multiple models can be especially difficult to sustain. There’s also the ever-looming reality that an organization which lacks overall maturity in other areas will never really achieve maturity in accessibility, further begging the question as to why accessibility maturity should be separate.
A Pragmatic Middle Ground
The most sensible approach may be a hybrid. Existing frameworks such as CMMI can provide the structural backbone, while accessibility additions can supply the domain-specific proof points. In other words, accessibility models should not reinvent the wheel but adapt its structure for their own purposes.
This context-dependent approach allows for flexibility. Large enterprises with mature process systems can integrate accessibility into their existing governance. Smaller organizations, by contrast, might find value in starting with a dedicated accessibility model, which provides a clear roadmap even in the absence of broader process discipline. Highly regulated sectors like finance, education, government may require accessibility maturity frameworks that align closely with compliance requirements, providing defensible evidence for auditors and regulators.
Above all, maturity models should be treated as guides rather than rigid checklists. The goal is not to achieve a high maturity score for its own sake but to make measurable improvements in the accessibility of products and services. Maturity levels should be a means to an end, not the end itself.
The W3C Accessibility Maturity Model
The W3C Accessibility Maturity Model (AMM) reflects this hybrid thinking. It borrows the familiar logic of maturity levels but fills them with accessibility-specific content. It organizes its assessment into seven dimensions—covering communications, culture, the ICT development lifecycle, procurement, training, personnel, and support—and ties each to “proof points” that organizations can use as evidence. Importantly, it allows assessors to mark outcomes as “not applicable” and emphasizes that maturity levels are cumulative: you must meet the lower levels before advancing upward.
Where CMMI defines five levels (Initial, Managed, Defined, Quantitatively Managed, Optimizing), the AMM defines four (Inactive, Launch, Integrate, Optimize). The correspondence is close. The AMM’s “Inactive” level resembles CMMI’s Initial: processes are ad hoc or nonexistent. “Launch” maps to CMMI’s Managed: there is a recognized need, with planning underway. “Integrate” mirrors CMMI’s Defined: processes are documented, standardized, and coordinated across teams. Finally, “Optimize” combines elements of CMMI’s last two levels. In CMMI, “quantitatively managed” and “optimizing” are distinct: one emphasizes statistical control and the other continuous innovation. The AMM collapses both into a single stage, recognizing that accessibility is less about statistical process control and more about continuous evaluation, cultural embedding, and proactive improvement.
This mapping shows that the AMM is not in competition with CMMI but rather a specialized adaptation. It speaks in the language of accessibility – proof points, inclusive practices, assistive technology testing -while still offering a framework familiar to executives accustomed to process maturity models. This gives accessibility professionals concrete tools while ensuring organizational leaders can situate accessibility maturity within broader enterprise governance.
Conclusion
So does accessibility deserve its own maturity model? On balance, the answer is yes, but with caveats. A specialized model is justified because accessibility has distinct knowledge domains, stakeholders, metrics, and cultural dimensions that general frameworks do not capture. But the model should be positioned as a complement to, not a competitor with, existing systems. Its value lies in providing actionable guidance and relatable proof points while remaining flexible enough to integrate with broader organizational frameworks.
The W3C Accessibility Maturity Model shows real promise in this role. It is structured yet adaptable, detailed yet not prescriptive, and it acknowledges the wide variation in organizational size and context. Where it could go further is in offering clearer examples of evidence, stronger tools for aggregation, and explicit guidance on integration with existing frameworks like CMMI.
Ultimately, the purpose of any maturity model is not to accumulate scores but to drive outcomes. Accessibility maturity models should be judged by whether they lead to more inclusive products, better experiences for people with disabilities, and stronger organizational cultures of inclusion. If the W3C model, or others like it, can achieve that, then their existence is not fragmentation but progress.
