The W3C Accessibility Maturity Model: Dimensions, Levels and Assessment
WCAG tells you whether a page is accessible. A maturity model asks a harder question: can your organisation keep producing accessible pages, documents, products and services, year after year, without relying on a few determined people? The W3C Accessibility Maturity Model is the free, open framework for that question. This guide explains its status, its seven dimensions and four levels in plain terms, how to run an assessment that rests on evidence rather than opinion, how it relates to other models, the European Accessibility Act, procurement rules and ISO/IEC 30071-1, and how to turn the result into a roadmap.
Reviewed by Khushwant Parihar, CPACC
Free tool: Accessibility Maturity Assessment
Rate all 135 proof points across the seven dimensions as Inactive, Launch, Integrate or Optimize, with notes on your evidence. You get a level for each dimension, a chart, next steps for the weakest areas, and Excel and PDF exports. Your answers stay in your browser.
What an Accessibility Maturity Model Is
A maturity model describes the stages an organisation moves through as a capability becomes part of how it works, and the evidence that shows each stage. For accessibility, the capability is producing accessible products, content and services as a matter of routine. The W3C Note draws the line clearly: conformance testing tells you how accessible one product is at one moment, while maturity modelling looks at whether the organisation can deliver accessible work over the long term.
| Aspect | Conformance audit | Maturity assessment |
|---|---|---|
| Question | Does this product meet WCAG or EN 301 549 today? | Can the organisation keep producing accessible products? |
| What is examined | Pages, screens, documents, components | Policies, processes, people, budgets, contracts, support |
| Evidence | Test results against success criteria | Proof points: documents, records, results and working processes |
| Output | A list of failures, a conformance report or an ACR | A level for each dimension and a corrective action plan |
| Shelf life | Until the next release | Until the organisation changes, so reassess regularly |
Who it is for
The Note is written for executives, for the managers who are responsible for accessibility, and for the people who own policy and business processes. It is meant to work for any kind of organisation, public or private, from a one-person consultancy or a small charity to a government department or a multinational, and it covers internal activity such as HR as well as public-facing products and services.
Its appendix of sample use cases shows the situations it is built for: a software company answering a tender that asks it to prove it can keep its ACRs accurate and current, a government agency putting that question into its own tender, an employer facing complaints about disability inclusion in its hiring, a consultancy showing its own maturity, an organisation looking at a supplier of content or of tools and code libraries, and a multinational assessing a single business unit.
Status: A W3C Group Note, Not a Standard
The Accessibility Maturity Model was published as a W3C Group Note on 4 November 2025 by the Accessible Platform Architectures (APA) Working Group, which developed it through a dedicated task force. That status matters, and it is often misreported:
- It is not a W3C Recommendation. WCAG is a W3C Recommendation, the end point of the W3C’s standards track. A Group Note is endorsed by the working group that wrote it, not by W3C and its Members as a whole.
- There is nothing to conform to. No organisation can be “certified” against it, and any level you report is your own judgement unless someone independent has checked the evidence.
- It does not replace WCAG, EN 301 549 or the law. It describes the organisation that produces accessible work; those standards and laws describe the work itself.
- You may adapt it. The Note allows organisations to omit, rename or reword proof points, provided the dimensions, levels and progression stay the same and the changes are recorded.
The Note links to an assessment spreadsheet with one sheet per dimension, which its editors describe as an experimental prototype, with a more robust tool planned. Feedback goes to the W3C through issues on its GitHub repository. Our accessibility maturity assessment is an independent tool built on the 4 November 2025 version, with every proof point paraphrased in our own words.
The Seven Dimensions
The model divides an organisation into seven dimensions, the areas where better maturity leads to better conformance with accessibility standards and regulations. Each dimension has proof points: concrete deliverables, such as a policy, a template, a training record or a signed contract, that show which level it has reached. Each dimension also has its own goals and metrics, and almost every one includes a proof point for training that keeps the relevant skills current. The descriptions and examples below are our own summaries of the Note.
Communications
Section 3.1 of the Note
Everything the organisation tells people, inside and outside, formal or informal, whether staff or contractors produce it. The question is whether all of it can be used by as many people as possible and meets accessibility standards.
Example proof points
- Accessible templates for documents, slides, marketing material and Accessibility Conformance Reports (ACRs)
- Captions, transcripts and audio description for video and audio where needed
- Accessible meeting, webinar and chat tools
- An accessibility statement where one is needed, and a way to send accessibility questions or complaints
Usually owned by: Communications, marketing, legal and document owners
ICT Development Lifecycle
Section 3.2 of the Note
Whether accessibility is part of every stage of a digital product's life: research, design, development, testing, conformance reporting, maintenance and retirement.
Example proof points
- Disabled people take part in user research, with the adjustments they need
- Design reviews, accessible design system components and annotated handoffs to developers
- An accessibility category in the bug tracker and a defined way to triage defects
- Automated tests plus documented manual checks with assistive technology, and releases that cannot ship without passing them
Usually owned by: Product, design, engineering and quality assurance
Knowledge and Skills
Section 3.3 of the Note
Whether people at every level know enough about accessibility for their role and see how their work supports the organisation's goals. Skills that belong to a particular dimension are assessed in that dimension.
Example proof points
- Skills surveys that find the gaps
- Role-based training plans, tracked in the learning system
- Accessibility training for every new starter
- Accessibility responsibilities in job descriptions, and specialists placed around the organisation to coach colleagues
Usually owned by: Learning and development, HR and the accessibility lead
Oversight and Culture
Section 3.4 of the Note
Whether leadership, values, policy and governance make disability inclusion part of how the organisation runs, rather than a side project.
Example proof points
- A named executive sponsor and a public commitment from executives
- A financial plan for raising maturity, with money formally committed
- Accessibility written into strategy, values, the code of conduct and staff objectives
- A written exception process for any inaccessible asset, needing a reason, a time limit and executive approval
Usually owned by: The executive team, governance and finance
Personnel
Section 3.5 of the Note
Whether qualified disabled people work at every level and in every part of the organisation, so that lived experience informs its decisions.
Example proof points
- Goals and initiatives for recruiting disabled employees
- Hiring tools, job boards, the careers site and the application process audited for accessibility
- A disabled staff network with an executive sponsor that helps shape accessibility work
- Disabled employees in product focus groups, and a mentoring programme
Usually owned by: HR, talent acquisition and inclusion teams
Procurement
Section 3.6 of the Note
Whether accessibility is part of how the organisation finds, chooses and contracts for products and services. Most technology arrives this way, so this is where accessibility is often won or lost.
Example proof points
- A published procurement policy for digital accessibility
- Standard accessibility wording in tenders, bid templates and contracts
- A written method for evaluating and scoring bids for accessibility
- Vendors supply testing evidence, warranties and remediation plans, and complaints involving a vendor have a defined route
Usually owned by: Procurement, legal and vendor management
Support
Section 3.7 of the Note
Whether disabled employees and customers get the help they need with the organisation's digital products, from workplace adjustments to customer support.
Example proof points
- Accessibility help topics, and support and IT staff trained in assistive technology and disability etiquette
- A written policy for how employees request and receive adjustments to digital tools
- Accessible support channels in plain language
- Accessibility feedback that is collected, triaged and used to improve products
Usually owned by: Customer support, the IT helpdesk and HR
The Four Maturity Levels
Every dimension is judged on the same four levels. The middle column is our summary of what each level means across the model; the right-hand column shows how it plays out in one dimension, Procurement.
| Level | What it means | In Procurement, for example |
|---|---|---|
| Inactive | Little or no awareness that accessibility is needed, and almost nothing being done. | Tenders and contracts do not mention accessibility, apart from the odd one-off. |
| Launch | The need is recognised and planning has started, but the work is not yet organised. | Work has begun on adding accessibility to tenders, and some procurement training is planned. |
| Integrate | A roadmap exists and the approach is defined and organised. | Contract wording is complete and reviewed, vendors must supply accessibility documentation, accessibility is monitored through the contract, and training has started. |
| Optimize | Accessibility is part of how the whole organisation works, is checked consistently, and the results drive action. | The processes and wording are used across all purchasing and refined over time, and training is required and measured. |
The rules that sit behind the levels
- The levels are cumulative. A dimension can only reach a level by meeting the ones below it first.
- Optimize means complete. Proof points can be partly done at Launch and Integrate, but must be fully in place for Optimize.
- Not applicable is allowed. If something does not apply, such as a policy clause about native apps for an organisation that has none, mark it N/A rather than forcing a rating.
- Each dimension has its own level. An organisation can be at Integrate in Communications and Inactive in Personnel. The Note defines no overall score and no way of combining the seven.
- The names are borrowed. The four level names come from the Policy Driven Adoption for Accessibility (PDAA) model of NASCIO, the US National Association of State Chief Information Officers, which some US state and local agencies already use.
How to Run an Accessibility Maturity Assessment
The Note’s own advice comes down to a short sequence: form a cross-functional team, gather current evidence, validate the findings with experts and disabled people, write a corrective action plan, and reassess regularly. Here is how to put that into practice.
1. Decide the scope
The model covers the whole organisation, but you can apply it to one business unit, region or product line. If you do, the Note asks you to say so plainly in any report you give to a third party, such as a customer answering a tender. A first assessment of one unit is often a sensible pilot.
2. Assemble the team
No single person sees procurement, engineering, HR and customer support at once, so the Note recommends a cross-functional review team. Its appendix maps roles to dimensions: some, such as a chief accessibility officer, employees with disabilities and an accessibility consultant, contribute to all seven, while others touch only a few. It also suggests naming a lead for each dimension who has taken at least basic accessibility training. In practice that means one coordinator, seven dimension owners, and disabled colleagues involved from the start rather than consulted at the end.
3. Gather evidence, not intentions
The Note is explicit that evidence should describe what exists now, not what is planned. Useful evidence includes policies, procedures and templates; training plans and completion records; goals and metrics; ACRs; contract clauses and signed contracts; test and audit results; and feedback and tracking systems. Keep a simple log for each proof point so the next assessment can see exactly what you saw:
Dimension: Procurement
Proof point: Contracts for custom development include accessibility checkpoints
Rating: Launch
Evidence: 2 of the 9 development contracts signed this year include
a WCAG 2.2 AA clause (links to both contracts)
Gap: No clause in the standard contract template; no acceptance testing
Owner: Head of Procurement
Next step: Add the clause and an acceptance test to the template by March
Checked on: 2026-10-284. Rate the proof points, then the dimension
For each dimension the Note describes three steps: pick the proof points that apply, list the documentation that supports them, and decide which level that evidence supports. Because it defines no formula, the judgement is yours. Our assessment tool adds a transparent rule to help: a dimension sits at the level that at least half of its rated proof points have reached, it reaches Optimize only when every rated proof point is at Optimize, and a summary that rests on fewer than half of a dimension’s proof points is marked provisional.
5. Validate the findings
Before anything goes in a report, check the ratings with accessibility specialists and with disabled people, as the Note advises. Self-assessment tends to be generous: a policy can exist without being followed, and a training course can be available without anyone taking it.
6. Record any customisation
If a proof point does not fit your sector, you may drop, rename or reword it, but keep the seven dimensions, the four levels and the way they build on each other, and write down every change so a third party can map your results back to the Note.
7. Reassess on a cycle
The Note asks for regular reassessment to track progress and spot regressions, without fixing an interval. Once a year, timed to your planning and budget cycle, works for most organisations, plus a check after any major change such as a reorganisation, a new platform or a new legal duty. Keep every assessment so you can compare them.
Free tool: Accessibility Maturity Assessment
Work through the seven dimensions one at a time, record the evidence for each rating in the notes, and export to Excel or PDF to share with dimension owners and compare next year.
Turning Results into a Roadmap
The Note asks for a corrective action plan with goals, milestones, owners and timelines, managed inside the systems you already use. A few principles make that plan realistic:
- Aim for the next level, not Optimize. Moving one dimension up a single level is a solid goal for a year; trying to reach the top everywhere at once is how roadmaps stall.
- Start with the dimensions that unlock the rest. An executive sponsor, a policy and a budget (Oversight and Culture) make every other dimension easier. Procurement clauses stop new barriers arriving while you fix old ones.
- Tie every action to a proof point. If an action does not change a proof point, the next assessment will not see it.
- Put it where work is planned. Backlog items, objectives and budget lines get done; a separate spreadsheet does not.
Here is an illustrative first-year roadmap for an organisation whose assessment found most dimensions at Inactive or Launch:
| Quarter | Dimension and target | Actions | Evidence at the end |
|---|---|---|---|
| Q1 | Oversight and Culture: Inactive to Launch | Name an executive sponsor, approve an accessibility policy, agree a budget line | Signed policy, board minutes, budget entry |
| Q1 | Procurement: Inactive to Launch | Add a standard accessibility clause to the tender template; ask vendors of new software for an ACR | Updated template, first tenders using it |
| Q2 | ICT Development Lifecycle: Launch to Integrate | Automated checks in the build pipeline, an accessibility bug label with triage rules, a manual screen reader test script for releases | Pipeline configuration, triage document, test records |
| Q3 | Knowledge and Skills: Launch to Integrate | Role-based training plans for designers, developers and content authors; track completion | Curricula, learning system records |
| Q4 | Communications and Support: Launch to Integrate | Accessible document and slide templates, an accessibility statement with a contact route, a process for triaging feedback | Templates, statement URL, feedback log |
| Q4 | All seven | Reassess, compare with the baseline, plan year two | Second assessment export |
Useful building blocks for those actions: the guide to writing an accessibility statement and the statement generator, the VPAT and ACR guide for procurement, the website audit guide and automated versus manual testing for the lifecycle, and the accessibility ROI calculator for the budget conversation.
How It Compares with Other Maturity Models
The W3C model is not the only one, and its own appendix lists several others. They differ more in who publishes them and how you use them than in what they look at.
| Model | Published by | Structure | How it is used |
|---|---|---|---|
| W3C Accessibility Maturity Model | W3C APA Working Group, Group Note, 2025 | Seven dimensions, four levels, proof points | Free and open; self-assessment or independent review |
| Digital Accessibility Maturity Model (DAMM) | Level Access, an accessibility software and services company | Seven dimensions, five levels: Initial, Repeatable, Defined, Managed, Optimizing | A free short Quick Check, plus a programme-building tool and expert-led assessments as services |
| Accessibility Maturity Model (BDF) | Business Disability Forum, a UK membership organisation, through its Technology Taskforce | Self-assessment linked to BDF’s Accessible Technology Charter, covering areas such as IT governance and procurement | Offered through BDF; check the current version and access terms with BDF |
| Policy-Driven Adoption for Accessibility (PDAA) | NASCIO | A high-level, policy-led assessment; the source of the W3C level names | Used by some US state and local agencies; can be tuned for procurement |
| Accessibility Capability Maturity Model (CCC ACMM) | California Community Colleges | Five stages across governance, content creation, procurement and staff development | Built for decentralised higher education institutions |
| ISO/IEC 30071-1:2019 | ISO and IEC, international standard | A code of practice for accessible ICT, not a maturity scale | A paid standard describing the processes to follow |
Sources: the W3C Note’s appendix of related models; Level Access’s DAMM overview and DAMM maturity levels; the ILO Global Business and Disability Network’s listing of the BDF Accessibility Maturity Model.
The models overlap heavily: governance, communications, the development lifecycle, procurement, skills and support appear in almost all of them. The practical differences are openness, cost and comparability. The W3C model is free, can be adapted with a record of changes, and gives a shared vocabulary that a customer, a supplier and an auditor can all read. If you already use another model, there is no need to switch; you can map your results onto the W3C dimensions when a partner asks for them.
How It Relates to the EAA, Procurement Rules and ISO/IEC 30071-1
The European Accessibility Act
The European Accessibility Act (Directive (EU) 2019/882), which has applied since 28 June 2025, sets accessibility requirements for the products and services in its scope. It never mentions maturity models and does not require one. But several of its duties are about process, and those are exactly what the maturity model measures:
- Article 13(3): service providers must have procedures that keep their services conformant, taking account of changes to the service, to the requirements and to the standards. Article 7(4) asks the same of manufacturers for series production. That is the ICT Development Lifecycle dimension: release gates, regression testing and checks on changes between releases.
- Article 13(2) and Annex V: service providers must publish, in accessible formats, information explaining how their services meet the requirements, and keep it for as long as the service runs. That sits in Communications and Support.
- Article 13(4): when a service does not conform, the provider must correct it and inform the national authorities. Defect triage and feedback handling are proof points in the lifecycle and Support dimensions.
- Article 14: businesses relying on the disproportionate burden exception must document their assessment (microenterprises dealing in products are excused from the paperwork), and service providers must renew it when the service changes, when an authority asks, and in any case at least every five years. That needs the governance and record-keeping of Oversight and Culture.
A maturity assessment is not evidence that anything conforms. Conformance is about the products and services themselves, tested against the Act’s requirements and the standards that support them, such as EN 301 549. Use the EAA readiness checklist for the obligations themselves and the maturity model for the organisation that has to keep meeting them.
Public procurement
In the EU, Article 42(1) of the public procurement Directive 2014/24/EU says that technical specifications for anything people will use must, except in justified cases, take accessibility into account, and must refer to any mandatory accessibility requirements set by EU law. Article 24(1) of the EAA makes its Annex I requirements those mandatory requirements for the products and services it covers. In the United States, Section 508 requires federal agencies to make the technology they develop, buy, maintain or use accessible, and suppliers usually answer with an Accessibility Conformance Report, often built on the VPAT template.
The maturity model helps on both sides of a tender. For buyers, the Procurement dimension is a checklist for their own process: policy, standard clauses, evaluation and scoring, contract remedies and monitoring. For suppliers, an ACR describes a product on the day it was tested, and two of the Note’s sample use cases revolve around tenders that ask suppliers to show they can keep their ACRs accurate and current. Evidence from the ICT Development Lifecycle, Knowledge and Skills and Personnel dimensions is a credible answer.
ISO/IEC 30071-1
ISO/IEC 30071-1:2019, a code of practice for creating accessible ICT products and services, grew out of the UK standard BS 8878. It is about process rather than technical criteria: it asks organisations to adopt an accessibility policy, consider accessibility at every stage of a system’s life, document and justify their decisions, and publish an accessibility statement when a system launches, and it applies to any organisation and to technologies from websites and apps to connected devices. The W3C Note lists it among related models.
The two fit together well. ISO/IEC 30071-1 describes the processes to follow; the maturity model measures how far those processes have taken root. An organisational accessibility policy shows up in Oversight and Culture, lifecycle decisions and their justification in the ICT Development Lifecycle, procurement in Procurement, and the accessibility statement in Communications and Support.
Common Pitfalls and How to Avoid Them
| Pitfall | Why it hurts | Do this instead |
|---|---|---|
| Treating the result as a compliance certificate. | The Note separates maturity from conformance. A mature programme can still ship an inaccessible page. | Pair the assessment with audits and testing, and report both. |
| Rating plans as if they were practice. | Aspirational evidence inflates the levels and hides the gaps you most need to see. | Rate only what exists today, and record the evidence for each rating. |
| One person fills it in alone. | Nobody sees procurement, HR, engineering and support at once, so whole dimensions get guessed. | Use a cross-functional team with an owner for each dimension. |
| Averaging everything into one score. | The Note defines no overall score, and an average hides the dimension that is holding you back. | Report a level per dimension, with the spread of ratings behind it. |
| Aiming for Optimize everywhere at once. | A roadmap that tries to jump several levels in every dimension stalls in the first quarter. | Move each dimension up one level, in an order that follows dependencies. |
| Leaving disabled people out. | Personnel is a whole dimension, and the Note asks for findings to be validated with disabled people. | Involve disabled employees and users in rating, validation and planning. |
| Skipping procurement. | If you keep buying inaccessible tools, new barriers arrive faster than you remove the old ones. | Add standard clauses and a scoring method early; they are cheap and fast. |
| Editing the model quietly. | Partners, customers and auditors cannot compare or map results they do not know were changed. | Record every omission and rewording, and state the scope in any report you share. |
| Assessing once and filing it. | Maturity slips when people, priorities and platforms change. | Reassess on a set cycle and keep each export for comparison. |
Accessibility Maturity Assessment Checklist
- Scope agreed. Whole organisation or a named unit, written down, and stated in anything you share outside.
- Team assembled. A cross-functional group with an owner for each of the seven dimensions, including disabled colleagues.
- Evidence gathered. Current documents, records and results for each proof point, not plans or intentions.
- Every proof point rated. Inactive, Launch, Integrate or Optimize, with Not applicable where it genuinely does not apply.
- A level per dimension. Judged from the evidence, with no overall average; Optimize only where every proof point is complete.
- Findings validated. Checked with accessibility specialists and with disabled employees or users.
- Customisations recorded. Any omitted, renamed or reworded proof points listed, with the dimensions and levels unchanged.
- Corrective action plan written. Goals, milestones, owners and dates, each tied to a proof point, inside your normal planning tools.
- Conformance tested separately. Products and content still audited against WCAG 2.2 and, where it applies, EN 301 549.
- Next assessment booked. A date in the planning cycle, and this assessment exported so the next one can be compared.
Find Out Where Your Programme Stands
Rate your organisation against all seven dimensions, then test your products so you know both how mature you are and how accessible your work is today.
Frequently Asked Questions
What is an accessibility maturity model?
An accessibility maturity model is a framework for judging how well an organisation has built accessibility into the way it works: its leadership, policies, buying, design and development, training, hiring and support. Instead of testing one website against WCAG, it asks whether the organisation can keep producing accessible products and services over time. It describes levels of maturity and the evidence that shows each one, so you can see where you are, what the next level requires and what to work on first.
Is the W3C Accessibility Maturity Model a standard?
No. It is a W3C Group Note, published on 4 November 2025 by the Accessible Platform Architectures Working Group. A Group Note is endorsed by the working group that wrote it, not by W3C and its Members as a whole, and it is not a W3C Recommendation like WCAG. There is nothing to conform to and no certification. It is a free framework you can use and adapt, as long as you record your changes.
What are the four accessibility maturity levels?
The W3C model uses four levels. Inactive means little or no awareness and almost no activity. Launch means the need is recognised and planning has begun, but the work is not yet organised. Integrate means there is a roadmap and a defined, organised approach. Optimize means accessibility is part of how the whole organisation works, is checked consistently, and the results lead to action. The levels are cumulative, and each dimension is given its own level.
What are the seven dimensions of the W3C Accessibility Maturity Model?
Communications; ICT Development Lifecycle; Knowledge and Skills; Oversight and Culture; Personnel; Procurement; and Support. Together they cover what an organisation publishes, how it builds digital products, what its people know, how it is led and governed, whether disabled people work there and shape decisions, how it buys technology, and how it helps disabled employees and customers.
How do you carry out an accessibility maturity assessment?
Decide the scope, whole organisation or one unit. Form a cross-functional team with an owner for each dimension. For each proof point, gather the evidence that exists today, such as policies, training records, contract wording, test results and feedback logs, and rate the level it supports. Validate the ratings with accessibility specialists and disabled people, turn the gaps into a corrective action plan with owners and dates, and reassess on a regular cycle.
How often should you reassess accessibility maturity?
The W3C Note says to reassess regularly, to track progress and catch areas that slip back, but it does not set an interval. Once a year, timed to your planning and budget cycle, suits most organisations, with an extra check after a major change such as a reorganisation, a new platform or a new legal obligation. Keep each assessment so you can compare them.
Does the European Accessibility Act require an accessibility maturity model?
No. The European Accessibility Act sets accessibility requirements for the products and services in its scope and never mentions maturity models. It does, though, require service providers to have procedures that keep their services conformant as things change, to publish information on how services meet the requirements, and to document any disproportionate burden assessment. A maturity assessment is a practical way to see whether those processes exist. It is not evidence that a product or service conforms.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences