Together with Eric Velleman, I recently presented an inclusive design capability maturity framework at ICCHP 2026. The framework grew out of the Active Inclusive Design Learning Community, and one of its starting assumptions is deliberately uncomfortable: for inclusive design, a linear, compliance-driven maturity ladder is the wrong shape. Inclusion is not a level you reach. It is a capability you keep developing, in your own context, on purpose.
Let me explain what we mean, and why it changes how you should look at your own organisation.
What the Learning Community found
The Active Inclusive Design Learning Community brings together nine design agencies (including Keen Public) three knowledge institutions (Utrecht University of Applied Sciences, HAN University of Applied Sciences and Delft University of Technology), and a range of subject-related organisations such as Gebruiker Centraal, CLICKNL, BNO, Visio, Iederin and the Accessibility Foundation.
When this group looked honestly at professional design practice, three findings stood out, and none of them are about missing alt text:
-
Design organisations don't create the conditions that let designers with disabilities participate fully and meaningfully in professional practice.
-
People with lived experience are mostly involved as research participants or end-users, rather than as members of the design team itself.
-
The design processes, methods and tools we use every day are often not accessible to begin with.
Read those together and a pattern emerges. The barriers to inclusive design are not only in the products we ship.They are in how we are organised, who we hire, whose expertise counts, and which tools we treat as normal. That is not something a technical audit can see.
Capability is bigger than accessibility
This is why we talk about inclusive design capability rather than accessibility compliance. Compliance with accessibility standards is necessary, but it is not sufficient. It tells you whether a website can be used with a screen reader. It says nothing about whether your team can consistently produce inclusive work, project after project, when the client, the deadline and the subject matter all change.
Inclusive design capability, as we define it, has three ingredients:
-
the knowledge, skills and attitudes of designers and their organisations;
-
their access to, and effective use of, tools, methods and guidelines;
-
the presence of managerial and organisational support.
And it reaches well beyond technical craft. It includes leadership and vision, mental flexibility, stakeholder management, accessibility expertise, the ability to facilitate collaboration between very different participants, and the confidence to navigate organisational and societal complexity. In other words: inclusive design becomes structural only when the organisation and its professionals are equipped to embed it into everyday practice, not when a single specialist patches things at the end.
Maturity as reflection, not as a scoreboard
Here is where our framework parts ways with the classic maturity model. A conventional model is normative: there is a defined top, and higher is better for everyone. We think that framing does inclusion a disservice, for a simple reason; the "right" next step genuinely differs from one organisation to the next.
So we reframe maturity as a capability for reflection, learning and adaptation. The point of measuring yourself is not to earn a grade or to benchmark against a competitor. It is to see your own practice more clearly, decide where development matters most given your context, and act. A small agency, an in-house government team and a university research group can all be "mature" in inclusive design while looking almost nothing alike.
That means the honest answer to "what should we improve next?" is: it depends. It depends on your organisational structure, your project landscape, your clients' demands and the resources you actually have. A good framework should support that judgement, not overrule it with a generic roadmap.
Four quadrants to look through
To make reflection concrete without flattening it, the framework organises inclusive design capability into four connected areas:
-
Strategy — leadership, planning, priorities and guidelines. Does inclusion show up in how decisions get made?
-
Culture — knowledge, awareness, the growth of professionals, and diversity within the team itself. Is it safe to bring your own experience to the table?
-
Process — the systematic use of research and methods, and the genuine involvement of users. Is inclusion built into how you work, or bolted on?
-
Results — defining, measuring and validating inclusive goals. Do you actually know whether any of this made a difference?
Each quadrant unpacks into more specific themes — from psychological safety and role modelling under Culture, to testing with diversity and interdisciplinary collaboration under Process, to monitoring over time and continuous improvement under Results. The value isn't in the labels. It's that the four lenses stop a conversation from collapsing into "are we accessible, yes or no?" and open up the harder, more useful questions.
The five-minute version: a maturity scan you can feel
One thing we've learned is that a framework only lives if people can experience it, not just read it. So we built an "ultralight" maturity scan: a handful of statements per quadrant, answered not on a form but with your body.
It works like this. You stand in a room and, for each statement, you place yourself in the space. Close to the centre means we don't do this, or I don't recognise it. In the middle means now and then, neutral. Far from the centre means we do this all the time, I fully agree. Then you plot a dot in your own matrix and, crucially, talk about it.
The statements are deliberately close to home. "My manager considers diversity and inclusion in internal processes and in how we communicate about our products." "Inclusion is discussed in my team." "I can safely share my personal needs, experiences and opinions within my team." "My team uses inclusive research methods when creating products or services." "Inclusion determines the quality of our products." Read them slowly and you'll notice they span all four quadrants, strategy, culture, process and results, and that answering them out loud, in front of colleagues, surfaces disagreements a survey would hide.
That discomfort is the feature, not the bug. The scan isn't there to produce a tidy score. It's there to start a conversation about where you actually are and where you want to go next.
Why this matters for the public sector
If you design public services, you already know the stakes. A digital service that is technically accessible can still exclude people — and when it does, the consequences fall on those least able to absorb them. Building genuinely inclusive services is not a one-off project you complete and certify. It's a capability your organisation grows and sustains, through the people you develop, the processes you standardise and the culture you protect.
A maturity model that treats inclusion as a ladder encourages you to chase the next level. A maturity approach built on reflection encourages you to ask better questions: Who is missing from our team? Which of our own tools are inaccessible? Where would development make the biggest difference right now? Those questions don't have universal answers. That's exactly why they're worth asking.
Curious where your organisation stands, or want to run the maturity scan with your team? At Keen Public we help public-sector organisations build inclusion into how they design; structurally, not as an afterthought. Explore our inclusion services or get in touch.
