Accessibility Maturity Model

Accessibility Maturity Model

W3C Group Draft Note

More details about this document
This version:
https://www.w3.org/TR/2024/DNOTE-maturity-model-20240618/
Latest published version:
https://www.w3.org/TR/maturity-model/
Latest editor's draft:
https://w3c.github.io/maturity-model/
History:
https://www.w3.org/standards/history/maturity-model/
Commit history
Editors:
David Fazio (Helix Opportunity)
Charles LaPierre (Benetech)
Janina Sajka (Invited Expert)
Feedback:
GitHub w3c/maturity-model (pull requests, new issue, open issues)

Abstract

Digital accessibility is a human right. Yet 1.3 billion people in the world living with disability experience accessibility barriers everyday. The cost of excluding people with disabilities is high. Not only from a civil rights standpoint but also from a business perspective. People with disabilities represent the largest minority worldwide with a discretionary income in the billions. Companies risk losing customers, revenue and top talent while also facing legal risk, as digital accessibility is required by law in many countries.

The W3C develops and provides free digital accessibility protocols and guidelines that ensure long-term growth for the digital world and equal access for all. These protocols and guidelines are considered to be the gold standard for digital accessibility around the world.

Whether your company is just starting its cultural transformation on disability inclusion or looking to improve existing processes, the Accessibility Maturity Model can help. It provides a framework for measuring and assessing accessibility maturity, linking teams toward common goals and objectives.

The model is designed to work for any size organization. From small consultancies and large enterprises, to nonprofit/NGOs and government agencies, it provides actionable guides for establishing or improving policies, employee-communication, training, and tools. It also includes a way to measure and document organizational, cultural and technical capabilities.

The Accessibility Maturity Model is intended to be independent of the requirements in relevant technical accessibility standards, such as WAI-ARIA and the Web Content Accessibility Guidelines (WCAG).

Digital accessibility is a journey. Humans have a wide range of needs and preferences when it comes to using digital products, so there’s no one-size-fits-all solution. This can make it challenging to address every individual requirement. However, with a solid maturity model organizations can make significant progress towards improving accessibility and creating inclusive experiences for as many people as possible, meeting your consumers and employees where they’re at.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Accessible Platform Architectures Working Group as a Group Draft Note using the Note track.

Group Draft Notes are not endorsed by W3C nor its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

1.1 About the Accessibility Maturity Model

Incorporating considerations for the accessibility of Information and Communications Technology (ICT) Accessibility into an organization’s workflow and quality governance can be a complex process. While some organizations have individuals or departments that support accessibility, many do not recognize the importance of ICT accessibility as a requirement, or the need for accessibility governance systems. This can limit their ability to produce accessible products and services, including training and documentation, which are essential for inclusive digital environments.

This challenge can be solved by encouraging organizations to establish and implement accessibility governance systems within their organizations. These systems integrate ICT accessibility criteria into policies, key business processes, organizational culture, and management structures in a consistent, repeatable, and measurable fashion. Only then can organizations address the complexities related to enabling ICT accessibility.

This proposed Accessibility Maturity Model describes an overall framework for establishing a robust ICT accessibility program and identifying areas for improvement. The Accessibility Maturity Model is a tool that:

Organizations know when they are doing well (or poorly) with product accessibility using audit reports and bug counts. However, these metrics don’t indicate how the organization is doing operationally to continue to produce accessible products without examining some key corporate processes. The Accessibility Maturity Model is a big part of a “shift-left” methodology of preventing problems from recurring, not fixing them after they have happened.

Most maturity models contain a number of levels with increasing levels of maturity. Each level contains a definition, controls, a list of processes, and proof points that can be produced for an organization to legitimately claim that they are at a particular level of maturity.

Accessibility maturity modeling is very different than accessibility conformance testing

1.2 Audience for the Accessibility Maturity Model

This document is intended to guide and evaluate the levels of organizational accessibility maturity that encompasses a public or private sector organization at any scale.

The primary audience for this maturity model is:

1.2.1 Scope

This document may also be used to measure the maturity level of parts of the organization, provided that the limited scope is clearly identified in any reports submitted to third-parties.

1.3 Existing Research and Standards

The Accessibility Maturity Model has been developed using research of existing maturity models and standards outside of WCAG. For example,

Editor's note

We intend to add other models the group has researched to this list.

1.4 Key terms

The following terms are used in this document:

accommodation

Modifications or adjustments that enable an individual with a disability to gain access and successfully complete tasks.

Accessibility Conformance Report (ACR)

A document that formally summarizes the extent to which an information and communications technology (ICT) product or service conforms to international accessibility guidelines and standards.

The report's format is based on the Voluntary Product Accessibility Template® (VPAT®). ACRs are used by buyers to understand how accessible a product is, and any potential deficiencies.

contract lifecycle

The steps and processes related to the procurement of an ICT product or service beginning with the initialization of the solicitation process, response evaluations, vendor selection for award, implementation of the contract requirements, monitoring over the life of the contract including renewals until the contract reaches its end date.

customer

External or internal users of an organization’s products or services, including but not limited to students, members of the public, employees, and contractors.

dimension

An aspect on which an organization measures its accessibility maturity.

Information and Communications Technology (ICT)

Information technology and other equipment, systems, technologies, or processes, for which the principal function is the creation, manipulation, storage, display, receipt, or transmission of electronic data and information, as well as any associated content.

Examples of ICT include, but are not limited to: computers and peripheral equipment; information kiosks and transaction machines; telecommunications equipment; customer premises equipment; multifunction office machines; software; applications; websites; videos; and electronic documents.

maturity stage

Granular stages used to signify the attainment or lack thereof of a specific maturity model dimension.

organization

Include, but are not limited to:

  • A government agency (Federal, state/province, county/city, municipality, etc.)
  • Any type of business entity (including a sole proprietorship, corporation, or LLC)
  • Learning institutions (university, college, district school system)
  • A nongovernmental organization (NGO) or non-profit
  • Subunit(s) of an organization where accessibility maturity is needed
proof point

Are criteria for accessibility maturity supported by evidence.

Voluntary Product Accessibility Template® (VPAT®)

A document template established by the Information Technology Industry (ITI) Council used by vendors to evaluate how well each accessibility requirement is met by a particular product.

Vendors use this template to respond to a potential customer’s Accessibility Conformance Report (ACR), which details how the product supports each criteria at one of four levels: Section 508, WCAG, EN 301 549 or international. VPATs, based on ACRs, are used by buyers to understand how accessible a product is, and any potential deficiencies.

2. Maturity Model Structure

The Accessibility Maturity Model is organized around seven essential dimensions of an organization where accessibility maturity can improve conformance with accessibility standards and regulations.

Dimensions have a unique descriptive name with a high-level, plain-language summary of what the dimension covers. Each dimension has two sub-sections:

2.1 Dimensions

The seven dimensions of organizational accessibility maturity are:

2.2 Proof Points

Each dimensional outcome has a range of suggested proof points, which includes any evidence or necessary measures that can be used to determine the maturity of each dimension. Progress towards achieving maturity is attained by creating the proof points described for each dimension.

For example, if a dimension requires a plan to identify ICT accessibility related skill levels and gaps, then the corresponding proof point would be a document containing the evaluation of ICT accessibility related skill levels and gaps.

2.3 Maturity Stages

Each stage is attained by meeting the defined outcomes for that specific dimension. The completed proof points demonstrate the efforts to achieve the outcomes for a maturity stage.

All relevant outcomes should be addressed but not all outcomes will apply to all organizations and situations. When an outcome does not apply, it is marked N/A (Not applicable). For example, an accessibility policy does not need to reference native applications if the organization has none.

Stages are cumulative, so stage advancement is achieved by first meeting the specific criteria of a lower level.

Note: The terms for the stages were adopted for consistency with the Policy-Driven Adoption for Accessibility maturity model, currently being used by some U.S. state and local government agencies.

Stages loosely correspond to the following criteria:

Stages Criteria
Inactive No awareness and recognition of need.
Launch Recognized need organization-wide. Planning initiated, but activities not well organized.
Integrate Roadmap in place, overall organizational approach defined and well organized.
Optimize Incorporated into the whole organization, consistently evaluated, and actions taken on assessment outcomes.

2.4 Assessment Template

Organizational ICT Accessibility Maturity is assessed using the Accessibility Maturity Model assessment template. The template contains worksheet tabs specific to each dimension. The dimension tabs are organized with the dimension definitions and outcomes for each of the four maturity stages and provides a list of the dimension’s proof points.

The blank cells below each maturity stage are to be completed by the organization and provide space to document evidence that the organization has reached that stage. The evidence can include progress on proof point completion, or other relevant information that can be used to claim that the outcomes for that stage have been met.

Proof points can span across multiple stages, work being initiated in one stage and completed in a more advanced stage.

2.4.1 Maturity Model Excel Spreadsheet

This is the latest Accessibility Maturity Model excel spreadsheet containing seven sheets one for each dimension as well as a cover sheet where a list of all changes made have been recorded.

We encourage you to make a copy of the assessment template worksheet to get started.

Editor's note

The Maturity Model assessment worksheet is intended as a high-fidelity prototype to measure organizational maturity and was developed in an Excel format. The final published format is to be determined, but is envisioned as HTML. It may also be made available in other downloadable, accessible formats.

Editor's note

This spreadsheet is experimental and is a work in progress. The proof point in this document may not be in sync with the supporting Excel spreadsheet template. The Excel spreadsheet template has the most up-to-date proof point.

3. Accessibility Maturity Per Dimension

3.1 Communications

Communications need to be accessible to the widest audience possible and meet the requirements in the accessibility standards. Accessible communications applies to all communications that are:

Accessible communications is an umbrella term for clear, direct, and easy-to-understand communications that are renderable in multiple formats so that all users have equivalent access. It considers barriers to accessing information and removes them or provides alternatives.

3.1.1 How to Evaluate Communications' Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's internal and external communication channels, such as email, video conferencing, or social media.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Communications” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.1.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • some plans are in place to make internal and external communications accessible (and compliant with accessibility regulations, where applicable), but those plans haven't materialized into a cohesive roadmap
  • plans are in place to provide training on accessible communications knowledge and skills relevant to each individual's position.

The level is Integrate when proof points demonstrate that:

  • an accessible communications roadmap has been developed
  • some accessible communications have been delivered across internal and external media and platforms
  • inaccessible communication tools are beginning to be replaced with accessible ones
  • an accessibility policy includes requirements for a feedback system for users and a formal process for handling accessibility complaints
  • training on accessible communications relevant to each individual's position has started.

The level is Optimize when proof points demonstrate that:

  • authoring, editing, and reviewing processes, procedures, and tools are in place, used consistently, and are regularly evaluated and refined to ensure that all internal and external communications are fully accessible
  • accessible communications training relevant to each individual's position is required, measured, and monitored for improvement.
3.1.1.1 Proof Points

Communications proof points may include but are not limited to:

3.1.1.1.1 Foundation for accessible communication
  • There are accessible corporate document templates (Microsoft Word, Microsoft PowerPoint, etc.).
  • There are documented HTML or PDF conversion procedures to support accessibility features.
  • Processes, procedures, and requirements for creating accessible communications are documented and available to employees.
  • Accessible collaboration tools are available (e.g., e-meeting, webinar, conferencing, chat).
3.1.1.1.2 Accessible Direct Communications
  • Consistent use of accessible templates for:
    • marketing and sales materials delivered in electronic formats
    • technical documents or position papers
    • Product Accessibility Conformance Reports (ACRs)
    • other accessibility documentation
    • presentations.
  • Internal and external websites:
    • are accessible per regional regulatory requirements (e.g. conforms to WCAG)
    • may have an accessibility statement (legal requirement for websites for public sector bodies in the European Union)
    • may contain a statement of commitment to accessibility.
  • Products and services: accessibility compliance documentation is available and delivered in an accessible format (on the website, by request, or through the procurement process)
    • accessibility conformance reports (ACR)
    • accessibility statement(a legal requirement for websites for public sector bodies in the European Union)
    • other accessibility-related documents, as identified.
  • multimedia, such as captions, transcripts, and described audio, if needed
  • social media and blog content
  • customer and vendor training
  • information on customer support
  • feedback mechanism for handling questions and accessibility complaints
  • legal documents, payment and billing
  • other communications, as identified.
3.1.1.1.3 Accessible Communications Training
  • Accessible communications training in place to build and maintain relevant skills in support of this dimension's proof points

3.2 Knowledge and Skills

Internal and external personnel at all levels of an organization should have accessibility knowledge and skills relevant to their organizational role. Accessibility knowledge and skills relevant to each individual's position help employees understand their part in achieving the organization's accessibility goals.

While this dimension includes proof points to be implemented at the organization level, knowledge and skills specific to each of the other dimensions should be included within their respective proof points, as appropriate.

3.2.1 How to Evaluate Knowledge and Skills Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current “Knowledge and Skills” efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Knowledge and Skills” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.2.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • there are plans in place or initiated, but activities aren't well organized
  • knowledge and skill areas are identified, and plans for organization-wide assessments to identify gaps are initiated but have not been completed
  • some ad hoc training is provided, but professional development is not required or monitored
  • requirements are defined for 3rd party learning tools and systems
  • role-based training plans are under development
  • accessibility training relevant to each individual's position has started.

The level is Integrate when proof points demonstrate that:

  • there's a workforce skills and training roadmap that includes:
    • accessibility objectives for knowledge and skills assessments
    • available training by role
    • current information on learning technologies, platforms, and tools
  • training is available to enhance knowledge and skills around ICT accessibility and disability inclusion
  • training metrics are established.

The level is Optimize when proof points demonstrate that:

  • all personnel position descriptions, hiring announcements, and project management consistently communicate the required and preferred accessibility knowledge and skills
  • the workforce is periodically evaluated to ensure knowledge and skills are current with the most up-to-date standards and accessibility practices
  • training is part of the onboarding process
  • periodic analysis has been used to identify gaps in knowledge as well as training materials
  • annual training (conferences, events, online, etc.) is provided to maintain skills current with ICT accessibility requirements and industry best practices
  • workforce inclusion training incorporates accessibility for persons with disabilities, and certification programs are available
  • tracking systems are in place and consistently used to maintain training inventory, measure skills, and track completion
  • training to enhance accessibility knowledge and skills relevant to each individual's position is required, measured, and monitored for improvement.

3.2.2 Proof Points

Knowledge and skills proof points may include but are not limited to:

3.2.2.1 Assessing Skills to Identify and Address Gaps

Assessments may include:

  • organizational surveys that identify current skill levels and gaps
  • tracking employee training for ICT accessibility skills
  • certification or competency reviews and programs
  • accessibility criteria integration into employee performance measurements.
3.2.2.2 Building and Maintaining Organizational Capacity

Organizational capacity may include:

  • implementation of role-based training plans and curricula
  • procuring external training resources as needed
  • incorporation of digital accessibility training curricula into organizational learning management, tracking, and auditing systems
  • accessibility training when onboarding all new employees
  • accessibility requirements included in position descriptions
  • subject matter experts (SMEs) positioned within the organization to provide training and support
  • organizing or attending digital accessibility events to increase awareness and knowledge
  • awareness campaigns (also pertinent to the Cultural dimension)
3.2.2.3 Dimension Integration
  • Training and learning programs should be integrated into proof points for each dimension

3.3 Support

Both internal employees and external customers with disabilities need support with regard to the organization's ICT. This includes reasonable accommodations for employees and customer support specific to users' ICT accessibility needs.

3.3.1 How to Evaluate Support Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current “Support” efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Support” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.3.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • Plans are in place to provide basic information about accessibility support to customers and employees, but there hasn't been any execution yet. This may include:
    • a written reasonable accommodation policy and process
    • relevant accessibility and accommodation support information.
  • Accessibility support training relevant to each individual's position is planned but hasn't been provided yet.

The level is Integrate when proof points demonstrate that:

  • the customer-facing website has a dedicated accessibility help section with frequently asked questions (FAQ) or help topics
  • tools and processes are in place to facilitate requests for employee accommodations
  • hiring managers have access to disability awareness training
  • accessibility support training relevant to each individual's position has started.

The level is Optimize when proof points demonstrate that:

  • fully trained customer support staff able to support users' accessibility questions
  • multiple ways to communicate with technical support that meets the needs of customers with disabilities are provided
  • ICT accessibility support is available for all internally and externally used ICT
  • training programs are in place for ICT support staff, and staff has been trained
  • continuous improvement plans are ongoing
  • accessibility support training relevant to each individual's position is required, measured, and monitored for improvement

3.3.2 Proof Points

Support proof points may include but are not limited to:

  • written policy on requesting and providing employee ICT-related accommodations
  • publicly available (and accessible) web accessibility statement with pointers to support mechanisms
  • support mechanisms are accessible
  • help topics or FAQs that are specific to accessibility
  • training for customer support agents (or internal ICT support staff) in accessibility, assistive technology, and disability etiquette and awareness
  • established disability-focused employee resource groups (ERG) with executive sponsorship
  • validation process in place to manage accessibility feedback
  • accessibility feedback is incorporated to facilitate continuous improvement of identified ICT
  • defined and documented methods to evaluate the effectiveness of accessibility support, actively in use.
3.3.2.1 Support Staff Training

Training is in place for support staff to build and maintain relevant skills in support of this dimension's proof points.

3.3.2.2 Support Metrics and Goals
  • Establish appropriate / meaningful goals and metrics for the support organizations, to measure and track progress towards achieving those goals.
  • Continuous improvement plans are ongoing.
  • Accessibility support training relevant to each individual’s position is required, measured, and monitored for improvement.

3.4 ICT Development Lifecycle

Accessible Information and communication technologies (ICT) serve as a critical enabler that allows persons with disabilities to realize full and effective opportunities to participate, on the basis of equality, in all aspects of society and development that involve technology. Accessibility should be considered throughout the entire ICT development lifecycle: from idea conception to design, development, testing, production of an ACR based on the VPAT, user research, maintenance, and obsolescence. Training programs must be established and ongoing to have the necessary skills for the ICT Development Lifecycle dimension.

3.4.1 How to Evaluate ICT Development Lifecycle Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current “ICT Development Lifecycle” efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “ICT Development Lifecycle” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.4.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • there is some awareness and recognition of the need for accessible ICT development, but it is inconsistently approached or decentralized
  • accessibility efforts are limited to new products, applications, and websites
  • plans are in place to provide accessibility ICT development lifecycle training, relevant to each individual's position.

The level is Integrate when proof points demonstrate that:

  • there are ongoing process improvement efforts for accessibility in the ICT development lifecycle per role or discipline
  • accessibility requirements are considered and practiced but not consistently applied during ICT design, development, and testing across the ICT portfolio
  • remediation of existing products, applications, and websites has started
  • training on ICT development lifecycle accessibility, relevant to each individual's position, has started.

The level is Optimize when proof points demonstrate that:

  • there's an ICT development accessibility thought leader at the organization who adheres to a structural, standardized, and reporting approach
  • design specifications include accessibility guidance, developers consistently create accessible User Interfaces (UI), manual and automated accessibility testing is performed during development, and automated accessibility testing is incorporated into Continuous Integration/Continuous Delivery (CI/CD) build pipelines
  • release management includes gates for accessibility quality
  • maintenance releases are re-inspected for accessibility
  • ACRs are updated and made available, as needed, for procurable ICT
  • research deliberately seeks out and evaluates input from users with disabilities
  • ICT development lifecycle accessibility training, relevant to each individual's position, is required, measured, and monitored for improvement.

3.4.2 Proof Points for ICT Development Lifecycle Dimension

ICT development lifecycle proof points may include but are not limited to:

3.4.2.1 User Research
  • user research includes disabilities
  • conduct user research focusing only on disabilities
  • research participants are provided with applicable accommodations, such as more time for the session, assistive technology, virtual options, and details about the physical location for in-person sessions and how they will be provided access
  • forms, releases, instructions, or other materials are accessible
  • archetypes, personas, journey maps, and other relevant synthesis and output from user research include people with disabilities
3.4.2.2 Design
  • designers have access to accessibility checklists, guidelines, annotation templates, etc.
  • accessibility reviews are part of the design process
  • design and content style guides include accessibility considerations
  • design systems components include accessibility considerations
  • design work delivered to developers includes accessibility information and annotations that meet relevant accessibility standards
  • consistent approach to designing accessibility features across products
  • user stories, jobs to be done (JTBD), etc., include persons with disabilities
3.4.2.3 Development
  • accessible developer implementation resources
    • team channels to discuss accessibility - direct messaging, office hours, email
    • information pages
  • developer's accessibility checklists
  • consistent approach to implementing accessibility features across products
  • documented way to triage and prioritize fixing accessibility issues and address customer-reported feedback on accessibility
  • accessibility requirements included in the definition of done
3.4.2.4 Quality Review Through Release
  • consistent approach to accessibility testing and releasing products
  • testing process documents steps for manual accessibility testing, utilizing assistive technology
  • testing process includes automated accessibility testing
  • schedule includes stakeholder activities focused on accessibility
  • bug-tracking system includes an accessibility category
  • prioritization and review system for accessibility defects
  • accessibility is identified as a product release gate
  • documented testing steps and cadence for agile delivery of changes without a full release cycle. Some examples are:
    • content review for website updates
    • content review for social media posts
  • accessibility Conformance Report ( ACR) authoring guide for commercial off-the-shelf (COTS) products used within the business, such as Google Workspace, Microsoft Office, or Jira
3.4.2.5 ICT Development Training
  • accessibility in the ICT lifecycle training is in place to build and maintain relevant role-based skills in support of this dimension's proof points

3.5 Personnel

Qualified individuals with disabilities should be employed throughout an organization's hierarchy (that is, all job types, all authority levels, and every department) so that their unique insights and lived experiences can better inform decision-making.

3.5.1 How to Evaluate Support Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current Personnel efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Personnel” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.5.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • including employees with disabilities in the workforce has been recognized
  • targeted recruiting of qualified candidates with disabilities has been initiated, but recruitment, retention, engagement, and activities related to disability inclusion are not well-organized
  • accessible hiring announcements that encourage applications from the disability community are posted
  • equal employment opportunities for people with disabilities is specifically stated in company diversity and inclusion policies and statements
  • a champion has been designated to facilitate and mature disability inclusion
  • plans are in place for providing disability inclusion training, relevant to each individual’s position.

The level is Integrate when proof points demonstrate that:

  • a disability inclusion roadmap that drives ICT accessibility is in place
  • the overall organizational approach to evaluating recruitment, retention, advancement, and engagement is defined
  • process integration for maturing disability inclusion efforts for ICT accessibility is in progress but not consistently implemented across the organization
  • the company has identified strategic positions to employ people with disabilities who will help audit and drive the development of accessible products and services
  • targeted recruiting of employees with disabilities with an accessible recruiting process
  • training on accessibility inclusion knowledge and skills relevant to each individual's position has started.

The level is Optimize when proof points demonstrate that:

  • employees with disabilities are leveraged throughout the organization to achieve full ICT accessibility maturity
  • organization-wide, disability inclusion staffing efforts are well-defined, evaluated, remediated, and integrated with ICT accessibility efforts and goals across the organization
  • employees with disabilities hold critical decision-making positions and are included in all areas of the organization to drive accessibility in every facet of the business
  • the disability employee resource group (ERG) is leveraged to inform accessibility decision-making
  • employees with disabilities are leveraged to audit accessibility
  • employees with disabilities are leveraged for product development
  • employees with disabilities are leveraged for the development of accessible services.

3.5.2 Proof Points

Personnel proof points may include but are not limited to:

3.5.2.1 Recruiting
  • established goals for recruiting employees with disabilities
  • hiring announcements with diversity statements encouraging and attracting applications from people with disabilities
  • a gap analysis or needs assessment to understand where the business is falling short of including applicants with disabilities
  • preferential hiring initiatives to recruit employees with disabilities, where not prohibited by law
3.5.2.2 Accessible Job Application Platform
  • hiring tools, job boards, etc., meet a specified level of accessibility
  • recruiting communications meet a specified level of accessibility
  • accessibility audit of jobs' website
  • accessibility audit of the application process
3.5.2.3 Strategic Engagement
  • established employee resource group (ERG), with an executive sponsor, for employees with disabilities to directly contribute first-hand knowledge and lived experience to accessibility efforts
  • product and project focus groups of employees with disabilities
  • mentoring program for employees with disabilities
  • employees are informed of and have access to a defined accommodation process
  • accessible employee evaluations take accessibility into consideration
  • accessible employee onboarding processes

3.6 Procurement

Procurement is a strategic process focused on finding and acquiring cost-effective products needed by an organization. Activities in procurement include sourcing, negotiation, and selection of goods and services.

The majority of an organization's ICT assets result from procurement transactions and contracts. When accessibility criteria are integrated into procurement processes and contract language, an organization can be more capable of providing accessible products, services, and workplaces.

3.6.1 How to Evaluate Procurement Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current "Procurement" efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Procurement” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.6.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • work has been initiated to identify and integrate accessibility into procurement processes and accessibility language into all ICT-related solicitation and contract documents and vendor responses throughout the procurement life cycle
  • some plans are in place for providing accessibility procurement knowledge and skills relevant to each individual's position.

The level is Integrate when proof points demonstrate that:

  • solicitation and contract language are complete, and responses have been analyzed by accessibility or trained procurement professionals
  • vendors are required to submit accessibility documentation to be evaluated as part of the overall vendor assessment
  • a communications mechanism has been put in place to inform vendors of accessibility requirements
  • accessibility is a monitored element of the procurement life cycle
  • accessibility criteria are included in contract renewal negotiations
  • training on accessibility procurement knowledge and skills relevant to each individual's position has started.

The level is Optimize when proof points demonstrate that:

  • full and consistent use of accessibility processes, criteria, contract language, and decision-making to procure and maintain accessible products and services throughout the procurement life cycles
  • procurement processes are regularly reviewed and refined as needed
  • training on accessibility procurement knowledge and skills relevant to each individual's position is required, and improvement is measured and monitored.

3.6.2 Proof Points

Procurement proof points may include but are not limited to:

3.6.2.1 Policy Documentation
  • published ICT accessibility policy that includes procurement or a separate procurement policy that includes accessibility
  • accessibility requirements and other information are communicated to vendors
3.6.2.2 Consistent Use of Standardized Procurement Language
  • standardized solicitation language that includes accessibility for ICT procurement
  • standardized solicitation language that includes accessibility in ICT contracts
  • accessibility-specific solicitation forms and templates for items like bids and proposals
3.6.2.3 Consistent Evaluation Process and Methods
  • proof of accessibility evaluations
  • documented evaluation methodology
  • submission scoring methodologies
3.6.2.4 Accessibility Contract Language
  • requirement that automated and/or manual accessibility testing has been performed on the product, service, or final deliverable
  • reviews of the development life cycle accessibility criteria integration and development
  • warranties and remedies sections in procurement contracts include accessibility
  • vendor corrective actions and remediation plans pre and post-deployment
  • executed contract examples with accessibility language
  • procurement-specific accessibility checkpoint requirements for custom development contracts.
3.6.2.5 Accessibility in Procurement Program Management
  • an accessibility audit to determine where the procurement program system is not meeting accessibility requirements has been conducted
  • lifecycle of procurement contracts has a defined, documented, and tracked lifecycle
  • procurement-related accessibility metrics are tracked and documented
  • a defined process for identifying and addressing complaints
3.6.2.6 Procurement Training
  • accessibility-related procurement training is in place for staff to build and maintain relevant skills in support of this dimension's proof points

3.7 Culture

Organizational culture consists of shared beliefs, values, policies, and processes established by leaders that ultimately shape employee perceptions, behaviors, and understanding.

To demonstrate cultural maturity in accessibility, all aspects of the organization's operation, processes, and skills should include considerations for disability inclusion. Every member of the organization should understand and be sensitive to the importance of ICT accessibility, including their personal role and responsibilities in meeting the organization’s accessibility goals. Accessibility should be an integral part of diversity and inclusion within the organization, with a clear recognition of the benefits of disability inclusion and the impact of ICT accessibility on people with disabilities to facilitate access to jobs, services, and other aspects of life.

3.7.1 How to Evaluate Culture Maturity Level

  1. Download the maturity model spreadsheet.
  2. List all the organization's current "Culture" efforts.
  3. Compare the list to the spreadsheet to decide which proof points will be used to assess your organization's “Culture” accessibility maturity. Not all proof points will be used for every business or organization. The proof points in section 3.7.2 are non-exhaustive examples of criteria.

The level is Inactive when proof points demonstrate that:

  • no effort has been made or only isolated efforts have been identified.

The level is Launch when proof points demonstrate that:

  • there's a recognized need for organization-wide cultural programs on accessibility and disability inclusion, and planning has been initiated, but with limited activity
  • work has been initiated for:
    • integrating ICT accessibility into organizational processes and governance, including policies and practices that impact employees and external audiences
    • identifying leadership for the initiative
    • formulating cultural programs
  • plans are in place for providing accessibility culture knowledge and skills relevant to each individual’s position.

The level is Integrate when proof points demonstrate that:

  • cultural programs have been created and initially deployed
  • metrics have been established, and hiring practices have been implemented
  • policies are in place with partial execution
  • diversity and inclusion are promoted, but no action plan has been developed
  • communities of practice have been established
  • training on accessibility culture knowledge and skills relevant to each individual’s position has started.

The level is Optimize when proof points demonstrate that:

  • there's a strong cultural awareness, appreciation, sensitivity, and support for all aspects of ICT accessibility and people with disabilities
  • policies, processes, and practices are in place, used consistently, and regularly reviewed and refined as needed
  • all employees understand and are sensitive to the importance of ICT accessibility and how it fits within their roles and responsibilities. They also appreciate the value of a diverse population within and outside the organization
  • training on accessibility culture knowledge and skills relevant to each individual's position is required, measured, and monitored for improvement

3.7.2 Proof Points

Culture proof points may include but are not limited to:

3.7.2.1 Organizational Culture of Disability Inclusion
  • executive sponsor in place for digital accessibility
  • executive-level digital accessibility program leadership
  • executive statement of the organization's commitment to digital accessibility
  • IT accessibility policy in place and implemented
  • a proactive approach to digital accessibility included in business strategy
  • digital accessibility promotion as a market differentiator included in business strategy
  • core values incorporate digital accessibility as a necessity for disability inclusion
  • code of conduct includes digital accessibility
  • diversity, equity, and inclusion activities include a disability focus
  • communities of practice include a digital accessibility focus
  • ICT accessibility criteria are integrated into employee/officer performance plans (if relevant)
  • mandated and monitored employee support for digital accessibility and disability inclusion
  • monitoring and improvement of digital accessibility program
  • accessibility and disability inclusion-specific questions included in regular employee satisfaction surveys
  • defined and documented process for employee feedback on accessibility and disability-inclusion efforts
3.7.2.2 General Training
  • accessibility-related training to build and maintain relevant skills in support of this dimension's proof points

4. Appendix

4.1 Internal resources needed to implement the maturity model at your organization

Implementing the maturity model is a group effort. We know that every company is set up differently and will have different titles/roles, so we compiled a sample list to help you get started and identify who will be helping you on the proof points and the dimensions.

Role Communications Knowledge and Skills Support ICT Dev Life Cycle Procurement Personnel Culture
Accessibility consultant/advisor Y Y Y Y Y Y Y
Accessibility/Disability/Inclusion influencer Y N Y Y N N Y
Accessibility specialist/helper/org Y N Y Y Y Y Y
AT developer N N N N N N N
Authoring tool developer N N N Y N N N
Call center representative Y N Y N N N N
Chief Accessibility Officer Y Y Y Y Y Y Y
Content provider/producer Y N N Y N N Y
Designer Y N N Y N N Y
Developer Y N N Y N N N
Disability organization member Y N Y N N Y Y
Evaluation tool developer N N N Y N N N
Government policy regulator or specialist N N N N Y N N
Instructor/trainer N Y Y N N Y Y
IT manager N N Y Y Y N N
Lawyer Y Y N N Y Y Y
Organizational policy-maker N N N Y Y Y Y
Platform developer (HW, OS, Browser) N N N Y N N N
Product manager Y N Y Y Y N N
Professional/Industry Org/Assoc N Y N N N Y Y
Project manager Y Y Y Y Y N N
QA specialist Y N N Y Y N N
Researcher N N N Y N N Y
Standards developer N N N Y N N N
Teaching resource developer N Y Y N N N N
Technology innovator N N N Y N N N
W3C Accessibility Guidelines Working Group N N N N N N N
Employees with Disabilities Y Y Y Y Y Y Y
User Experience (UX) Team Y N N Y Y N Y
Diversity and Inclusion Officer Y Y Y N Y Y Y
Public Relations/Communications Y N N N N N Y
Procurement Team Y Y Y Y Y Y N

4.2 Sample use cases for identifying internal resources

To help you get started, we’ve curated eight sample use cases that an organization might encounter and identified what dimensions and roles could be involved to help complete the task. Refer to the roles table in the appendix for more details.

4.2.1 Use case one

A software company is responding to an RFP. They’ve been asked to demonstrate that they can retain the accuracy and timeliness of their VPATs and refresh them as needed.

Dimensions:
Knowledge and Skills, ICT Dev Lifecycle, and Personnel are the critical dimensions.

Roles that could be involved in use case one:

  • Accessibility consultant/advisor
  • Accessibility/Disability/Inclusion Influencer
  • Accessibility specialist/helper/org
  • Authoring tool developer
  • Chief Accessibility Officer
  • Content provider/producer
  • Designer
  • Developer
  • Disability organization member
  • Evaluation tool developer
  • Instructor/trainer
  • IT manager
  • Lawyer
  • Organizational policy-maker
  • Platform developer
  • Product Manager
  • Professional/industry org/associate
  • Project manager
  • QA Specialist
  • Researcher
  • Standards developer
  • Teaching resource developer
  • Technology innovator
  • Employees with disabilities
  • User experience team
  • Diversity and Inclusion Officer

4.2.2 Use case two

A government agency is issuing an RFP. They want to ask potential respondents to demonstrate that they can retain the accuracy and timeliness of their VPATs and refresh them as needed.

Dimensions:
Knowledge and Skills, ICT Dev Lifecycle, and Personnel are the critical dimensions.

Roles that could be involved in use case two:

  • Accessibility consultant/advisor
  • Accessibility/Disability/Inclusion Influencer
  • Accessibility specialist/helper/org
  • Authoring tool developer
  • Chief Accessibility Officer
  • Content provider/producer
  • Designer
  • Developer
  • Disability organization member
  • Evaluation tool developer
  • Instructor/trainer
  • IT manager
  • Lawyer
  • Organizational policy-maker
  • Platform developer
  • Product Manager
  • Professional/industry org/associate
  • Project manager
  • QA Specialist
  • Researcher
  • Standards developer
  • Teaching resource developer
  • Technology innovator
  • Employees with disabilities
  • User experience team
  • Diversity and Inclusion Officer

4.2.3 Use case three

A private sector organization has received multiple complaints from prospective employees about disability inclusion in the hiring process.

Dimensions:
Communications, Support, Personnel, and Culture are the critical dimensions.

Roles that could be involved in use case three:

  • Accessibility consultant/advisor
  • Accessibility/Disability/Inclusion Influencer
  • Accessibility specialist/helper/org
  • Call center representative
  • Chief Accessibility Officer
  • Content provider/producer
  • Designer
  • Disability organization member
  • Instructor/trainer
  • IT manager
  • Lawyer
  • Organizational policy-maker
  • Professional/industry org/associate
  • Project manager
  • Researcher
  • Teaching resource developer
  • Employees with disabilities
  • Diversity and Inclusion Officer
  • Public relations/communications
  • Procurement team

4.2.4 Use case four

An accessibility consulting company wants to show potential customers that their entire organization is optimized for accessibility.

Dimensions:
Because this use case covers the entire organization, all dimensions must be reviewed.

Roles that could be involved in use case four:
All roles across the organization

4.2.5 Use case five

An NGO wants to determine which areas it should address to improve internal disability inclusion in the next fiscal year.

Dimensions:
Communications, Support, Personnel, and Culture are the critical dimensions.

Roles that could be involved in use case five:

  • Accessibility consultant/advisor
  • Accessibility/Disability/Inclusion Influencer
  • Accessibility specialist/helper/org
  • Call center representative
  • Chief Accessibility Officer
  • Content provider/producer
  • Designer
  • Disability organization member
  • Instructor/trainer
  • IT manager
  • Lawyer
  • Organizational policy-maker
  • Professional/industry org/associate
  • Project manager
  • Researcher
  • Teaching resource developer
  • Employees with disabilities
  • Diversity and Inclusion Officer
  • Public relations/communications
  • Procurement team

4.2.6 Use case six

An organization wants to review the accessibility of a second organization that provides third-party digital content that it will include in its solutions.

Dimensions:
Communications, Knowledge and Skills, and Procurement are the critical dimensions.

Roles that could be involved in use case six:

  • Accessibility consultant/advisor
  • Accessibility/Disability/Inclusion Influencer
  • Accessibility specialist/helper/org
  • Call center representative
  • Chief Accessibility Officer
  • Content provider/producer
  • Designer
  • Developer
  • Disability organization member
  • Government policy regulator or specialist
  • Instructor/trainer
  • IT manager
  • Lawyer
  • Organizational policy-maker
  • Product Manager
  • Professional/industry org/associate
  • Project manager
  • QA Specialist
  • Teaching resource developer
  • Employees with disabilities
  • User experience team
  • Diversity and Inclusion Officer
  • Public relations/communications
  • Procurement team

4.2.7 Use case seven

An organization wants to review the accessibility of a second organization that provides tools and libraries.

Dimensions:
The second organization should be responsible for reviewing the critical Knowledge and Skills, ICT Dev Lifecycle, and Personnel for its tools and libraries.

Roles that could be involved in use case seven:
All roles across the organization

4.2.8 Use case eight

A large multination corporation wants to assess the accessibility maturity of a single business unit.

Dimensions:
Review all dimensions in the context of that specific business unit.

Roles that could be involved in use case eight:
All roles across the specific business unit

5. Acknowledgements

5.1 Key contributors, section editors and participants active in the Maturity Model Subgroup at the time of publication