0 / 24

Model 37 of 74 · Technology & Data

Accessibility (WCAG) Maturity Assessment

Evaluate how well digital accessibility is embedded in design, development, and testing.

Pillars & areas

Commit

Set policy & standards

  1. 01Accessibility Strategy & Governance
  2. 02Inclusive Design & UX

Deliver

Design, build & test

  1. 03Development & Implementation
  2. 04Testing & Assurance

Sustain

Embed across the org

  1. 05Content & Communication
  2. 06Training, Culture & Procurement

Levels

  1. 1RetrofittingFix when flagged
  2. 2IntegratedStandards & tooling in place
  3. 3Inclusive by DefaultEmbedded in every stage

01 Accessibility Strategy & Governance

Does the organisation have a clear mandate, ownership, and roadmap for digital accessibility?

0/4 answered

SG-1How does your organisation define its commitment to digital accessibility?

Think about whether there is a written policy, executive endorsement, or whether accessibility is simply assumed to be someone else's responsibility.

SG-2Who is accountable for accessibility outcomes in your organisation?

Consider whether there is a named person or team responsible, or whether accountability is diffused across the organisation.

SG-3How does your organisation prioritise accessibility remediation work?

Think about whether accessibility bugs sit in a separate backlog that never gets addressed, or are treated like any other defect.

SG-4How does your organisation track conformance against its accessibility targets?

Consider whether there is a dashboard, report, or audit cadence — or whether conformance is unknown until someone asks.

02 Inclusive Design & UX

Are products and services designed with diverse users in mind from the start?

0/4 answered

DU-1At what point in the design process is accessibility first considered?

Think about whether accessibility requirements appear in the original brief, or are raised for the first time during QA.

DU-2How does your organisation involve people with disabilities in the design process?

Consider whether actual users of assistive technology are consulted, or whether the team relies entirely on its own assumptions.

DU-3How does your design system or component library handle accessibility?

Think about whether shared components come with built-in accessibility, or whether every team has to figure it out independently.

DU-4How does your organisation handle accessibility when designing for emerging interaction patterns (e.g. modals, drag-and-drop, real-time updates)?

Consider whether complex interactions are designed with keyboard and screen-reader users in mind, or whether accessible alternatives are bolted on later.

03 Development & Implementation

Are accessible coding practices consistently applied in day-to-day development?

0/4 answered

DI-1How do developers ensure that semantic HTML and ARIA are used correctly?

Think about whether there are linting rules, code-review checklists, or whether correct markup depends entirely on individual knowledge.

DI-2How does your development process handle keyboard accessibility?

Consider whether every interactive element can be reached and operated by keyboard alone, including custom widgets.

DI-3How does your team handle accessibility in dynamic content (single-page apps, live updates, client-side routing)?

Think about whether screen-reader users are informed when content changes without a full page reload.

DI-4How does your organisation manage accessibility when integrating third-party components or platforms?

Consider whether vendor-supplied widgets, embedded content, and SaaS platforms are assessed for accessibility before adoption.

04 Testing & Assurance

Is accessibility tested rigorously and continuously, using methods that catch real-world barriers?

0/4 answered

TA-1What automated accessibility testing does your organisation run?

Think about whether automated checks run in CI, in the browser during development, or not at all.

TA-2How does your organisation perform manual accessibility testing?

Consider whether anyone regularly tests with a screen reader, keyboard-only navigation, or magnification — automated tools detect only a portion of real barriers, commonly estimated at well under half.

TA-3How does your organisation use external accessibility audits?

Think about whether an independent expert has ever tested your products, or whether all assurance is internal.

TA-4How does your organisation ensure accessibility is maintained during ongoing releases?

Consider whether a product that was once accessible stays accessible after six months of feature development.

05 Content & Communication

Is all published content — text, media, documents, and communications — accessible to diverse audiences?

0/4 answered

CC-1How does your organisation ensure that written content is accessible?

Think about reading level, heading structure, link text, and whether content authors follow any accessibility guidelines.

CC-2How does your organisation handle images, charts, and visual media?

Consider whether all meaningful images have alternative text, and whether complex visuals like charts are described for non-visual users.

CC-3How does your organisation handle video and audio content?

Think about captions, transcripts, and audio description — not just whether they exist, but whether they are accurate and synchronised.

CC-4How does your organisation ensure that downloadable documents (PDFs, spreadsheets, presentations) are accessible?

Consider whether documents use tagged structure, reading order, and alternative text — or whether they are flat, image-based files.

06 Training, Culture & Procurement

Does the organisation build accessibility knowledge, foster inclusive culture, and extend accessibility expectations to vendors?

0/4 answered

TC-1What accessibility training do team members receive?

Think about whether designers, developers, testers, and content authors each receive role-specific training, or whether accessibility knowledge is assumed.

TC-2How does your organisation's culture treat accessibility?

Consider whether accessibility is seen as a compliance burden, a specialist concern, or a shared quality standard that everyone owns.

TC-3How does your organisation handle accessibility in procurement and vendor selection?

Think about whether RFPs include accessibility requirements, and whether vendor responses are verified rather than taken at face value.

TC-4How does your organisation stay current with evolving accessibility standards and assistive technology?

Consider whether the team tracks updates to WCAG, ARIA, and screen-reader behaviour, or whether knowledge is based on a standard learned years ago.

Self-assessment report

Accessibility (WCAG)

Answer the questions above and your report builds here: an overall score, a score and target for each area, and the three changes that matter most.

About this model

About the Accessibility (WCAG) maturity model

Digital accessibility is not a compliance checkbox — it is a measure of how well an organisation includes people with disabilities in the design, delivery, and maintenance of its products and services. An accessible product works for people who are blind, deaf, have motor impairments, cognitive differences, or situational limitations. Genuine accessibility maturity means these considerations are woven into every decision, not bolted on at the end.

This model assesses how deeply accessibility practices are embedded across strategy, design, development, testing, content, and culture. It deliberately avoids mapping directly to WCAG success criteria — those are technical pass/fail requirements. Instead, it evaluates the organisational capability to consistently meet and sustain those requirements over time.

The Accessibility (WCAG) maturity model covers six areas that together determine whether an organisation can reliably produce and maintain accessible digital products. It spans from executive governance to daily development habits, from design research to vendor procurement. The model recognises that technical conformance without organisational capability is fragile — a product that passes an audit today will fail tomorrow if the team lacks the knowledge, processes, and culture to sustain it.

Each area contains four questions, for a total of 24. Responses are scored across three maturity levels that reflect observable, concrete behaviours rather than abstract aspirations.

Who this assessment is for

  • Product managers and product owners responsible for digital services
  • UX designers and researchers building user-facing products
  • Front-end and full-stack developers implementing interfaces
  • QA engineers and accessibility testers
  • Content authors, editors, and communications teams
  • Procurement and vendor management professionals
  • IT and digital leaders accountable for accessibility outcomes
  • Compliance and risk teams tracking regulatory obligations (e.g. EN 301 549, Section 508, ADA, EAA)

The three maturity levels

  • Level 1 — Retrofitting: Accessibility is addressed only when problems surface — a complaint is received, an audit fails, or a legal risk is raised. There is no consistent process, no assigned ownership, and no systematic testing. Individual contributors may care deeply, but the organisation does not support them with standards, tools, or time. Products may be partially accessible by accident, but conformance is unknown and unsustained.
  • Level 2 — Integrated: Accessibility has a recognised place in the delivery process. Policies exist, roles are defined, and standards are documented. Automated testing runs in CI, designers check contrast and focus order, and content authors follow guidelines. Training is available and third-party audits are conducted. The organisation can demonstrate conformance for its key products, though gaps remain in edge cases, legacy systems, and less-visible content.
  • Level 3 — Inclusive by Default: Accessibility is a core quality attribute on par with security and performance. It is embedded from the earliest design brief through to post-release monitoring. Users with disabilities participate in research and testing. The design system ships accessible components by default. Automated and manual testing covers all products continuously. Procurement contracts require vendor conformance. The organisation tracks conformance trends, fixes regressions quickly, and improves its practices based on evidence and user feedback.

The 6 areas assessed

1. Accessibility Strategy & Governance

Covers the organisational mandate for accessibility: whether a policy exists, who owns it, how conformance is tracked, and how remediation work is prioritised. Without governance, accessibility depends entirely on individual goodwill and is the first thing cut when deadlines tighten.

2. Inclusive Design & UX

Assesses whether accessibility is a design input, not just a development afterthought. This includes involving users with disabilities in research, building accessible patterns into the design system, planning keyboard and screen-reader interactions during wireframing, and treating accessibility as a constraint that improves design quality for everyone.

3. Development & Implementation

Examines day-to-day coding practices: semantic HTML, correct ARIA usage, keyboard operability, dynamic content announcements, and the handling of third-party components. The focus is on whether accessible implementation is enforced by tooling and process, or left to individual discretion.

4. Testing & Assurance

Evaluates the rigour and continuity of accessibility testing — automated scanning, manual testing with assistive technology, external audits, and regression protection. Automated tools catch roughly 30-40% of barriers; this area assesses whether the organisation covers the rest and maintains conformance over time.

5. Content & Communication

Covers non-code accessibility: written content (heading structure, link text, plain language), images and charts (alternative text, data tables), video and audio (captions, transcripts, audio description), and downloadable documents (tagged PDFs, accessible templates). Content is often the largest source of accessibility barriers in mature organisations.

6. Training, Culture & Procurement

Assesses whether the organisation builds lasting accessibility capability. This includes role-specific training, cultural attitudes toward accessibility, procurement practices that extend accessibility requirements to vendors, and whether the team stays current with evolving standards and assistive technology.

How this model relates to other frameworks

  • WCAG 2.1 / 2.2 (W3C) — The primary technical standard for web accessibility, defining success criteria at levels A, AA, and AAA.
  • EN 301 549 (EU) — European standard for ICT accessibility, incorporating WCAG and extending to non-web ICT including mobile apps, documents, and hardware.
  • Section 508 (US) — US federal accessibility requirements for information and communication technology, aligned with WCAG 2.0 Level AA.
  • WAI-ARIA (W3C) — Authoring practices for making dynamic web content and custom widgets accessible to assistive technology.
  • Authoring Tool Accessibility Guidelines (ATAG) 2.0 (W3C) — Guidelines for making content authoring tools both accessible to use and capable of producing accessible output.
  • ISO 30071-1 — International standard providing a process for embedding accessibility into ICT product and service development.
  • European Accessibility Act (EAA) — EU directive requiring accessibility of digital products and services across member states from June 2025.

Frequently asked questions

What is the Accessibility (WCAG) maturity model?

Evaluate how well digital accessibility is embedded in design, development, and testing. It is an original, simplified model with three maturity levels (Retrofitting, Integrated and Inclusive by Default), assessed through 24 questions across 6 areas: Accessibility Strategy & Governance, Inclusive Design & UX, Development & Implementation, Testing & Assurance, Content & Communication and Training, Culture & Procurement.

How long does the Accessibility (WCAG) assessment take?

Most people finish in 10–14 minutes. Each of the 24 questions has three concrete answer options. Your progress is saved in the page URL, so you can bookmark it and come back later.

How is the score calculated?

Each answer scores 1 (Retrofitting), 2 (Integrated) or 3 (Inclusive by Default). An area's score is the average of its answered questions, and the overall score is the average of the area scores, so every area counts equally. Scores run from 1.0 to 3.0.

Is my data stored or shared?

No. Your answers are never sent to a server. They are stored only in the page URL, which you control. Copy the link to share results with colleagues, or export a PDF or CSV report.

How should I use the results?

Start with "Where to focus" in your report. It lists the questions with the biggest gap to the target you set for each area, and shows what the next level looks like in practice. For a fuller picture, ask several people from different teams to complete the assessment and compare their links. Differences in perception are often as revealing as the scores themselves.