GitHub 328 & 334: Abstract & About Section Definitions for AMM meeting

Hi everyone,

Mark and I met today on the Abstract and Introduction section, which relate to GitHub issues 328 and 334. We worked from the idea of what Mark said in the meeting two weeks ago that we should define what we want in each of the sections before we make further revisions to the text.

Below is what we've come up with, along with Claude. We're sending it along now so people can have the opportunity to read in advance of the meeting if they'd like.

Thanks
Jeff

----

Section purpose definitions — Abstract and Introduction
Drafted: 2026-05-13 Method: Mark's "define the section first, then make the content fit" applied to the Abstract and all Introduction subsections.
Each definition has three parts: a one-line purpose statement, the scope of what belongs in the section, and an explicit notes on what does not belong (so content has a clear home and overlaps are visible).
The heading for §1.1 is left as an open question — "About" matches W3C convention, "Understanding" matches Janina's framing in the meeting and Jeff's Notion comment. The purpose is the same either way; the choice is editorial.
"Status of This Document "is omitted from this exercise — it is standard W3C template content (process stage, working group, patent policy, comment deadlines) filled with specifics. It carries its own conventions and isn't being considered within this revision.
________________________________
Abstract
Purpose. Summarizes the document — what the AMM is, what it does at a high level, how it's organized, and what the reader will find inside. Reader-facing scope statement, document-focused per Mark's Abstract/About chart.
Scope.

  *   A one- to two-sentence statement of what the AMM is and what it measures (the "what" of the document).
  *   A brief, non-enumerated mention of how the model is organized — seven dimensions, four maturity levels — without listing the dimension or level names.
  *   A short note on how the framework operates at a high level (evaluation of current capabilities, identification of gaps, planning for improvement).
  *   A line on scalability and adaptability — that it applies to organizations of any size and may be tailored to industry and operational context, with adaptable and extensible dimensions and proof points.
  *   A closing line on what the document contains (dimensions, levels, sample proof points, the experimental assessment spreadsheet).

Out of scope.

  *   The “what’s in it for me” (WIIFM) beat — what an organization gains from maturity assessment beyond conformance. That's §1.1 About-territory.
  *   The conformance-vs-maturity contrast — also §1.1 About-territory. This avoids looking at what the AMM is not
  *   Enumeration of dimension names or level names — those are §2 territory.
  *   How to actually run an assessment (workflow, steps) — that's §1.2 How to Use.
  *   The mechanics of customization — that's §1.3 Customizing. The Abstract can note that customization is possible; the how lives elsewhere.
  *   Anything creator-focused (task force, mission, authorship) — that's carried by the front-matter editors list and Status of This Document, not by the Abstract.

Approximate length target. 150–200 words. Aligns with both Mark's Abstract chart (150–250) and the a11yedge precedent (~170 words). The current revised draft is ~155 words and sits comfortably in this range.
Tone. Objective, concise, descriptive. The document's job is what's being described; the reader's motivation is not (that's About).
________________________________
§1 Introduction
Purpose. Orient the reader to the AMM as a concept and as a working document — what it is, why an organization would use it, who it's for, how to apply it, and how to adapt it.
Scope. Brief framing prose at the §1 level (if any), then four subsections that each carry one of the orienting jobs.
Out of scope. The mechanics of the model (dimensions, levels, proof points) — those live in §2 Maturity Model Structure.
________________________________
§1.1 About the Accessibility Maturity Model
(Alternative heading possibility: "Understanding the Accessibility Maturity Model")
Purpose. Establishes the conceptual foundation — what accessibility maturity is, how it complements (rather than replaces) accessibility conformance testing, and what an organization gains from measuring it.
Scope.

  *   What "accessibility maturity" means as a concept, separate from any specific framework.
  *   The complementary relationship between maturity assessment and conformance testing — what each describes, when each is the right tool, why an organization committed to accessibility benefits from both.
  *   A "what an organization gains" beat — addressing Sheri's WIIFM concern: an organization that already produces accessible products gains sustainability of that accessibility over time and visibility into where their practice will or won't hold up under change.
  *   Brief positioning of this specific model: that it's organized around seven dimensions and four maturity levels (named at high level, not enumerated).

Out of scope.

  *   The detailed procedure for running an assessment (that's §1.2 How to Use).
  *   The taxonomy of dimensions and proof points (that's §2).
  *   Customization mechanics (that's §1.3).
  *   Identifying who should read this (that's §1.4).
  *   Anything about the W3C process, document status, or the task force (that's the existing Status of This Document section).

Approximate length target. 200–300 words. About the same length as the Abstract or slightly longer; it's the section that does the most conceptual work in the Introduction.
________________________________
§1.2 How to Use the Accessibility Maturity Model
Purpose. Provides a workflow for applying the AMM — from scoping an assessment through recording findings — and points readers to the parts of the document they'll use at each step.
Scope.

  *   A short document map orienting the reader to what's in §2, §3, and §2.4 (the assessment spreadsheet).
  *   An assessment workflow (scope → identify proof points → gather evidence → determine maturity level → record and act).
  *   Operational rules pulled forward from §2 that apply during use: cumulative levels, Optimize-requires-full-completion, N/A handling.
  *   A worked example (Communications dimension at Launch level).
  *   Recommended practices (cross-functional review team, engaging people with disabilities, reassessing on a cadence).

Out of scope.

  *   Definitions of dimensions, proof points, and maturity levels (those are in §2, referenced from here).
  *   The conceptual contrast with conformance testing — that's About-territory and belongs in §1.1.
  *   Customization mechanics (those are §1.3).
  *   Any "why use this model" framing — that's About-territory.

Approximate length target. 400–600 words. Longer than About because it's the procedural reference section.
________________________________
§1.3 Customizing the Accessibility Maturity Model
Purpose. Describes how organizations may adapt the AMM's dimensions, proof points, and terminology to fit their industry and operational context, while preserving the model's underlying framework.
Scope.

  *   What's customizable (terminology, individual proof points, dimension wording).
  *   What's extensible (adding proof points or sub-criteria where the organization's context requires them).
  *   What must stay intact (the framework itself: seven dimensions, four maturity levels, progression logic).
  *   A practical recommendation to keep a record of customizations for third-party sharing or auditability.

Out of scope.

  *   The workflow for using the model (that's §1.2).
  *   Definitions of what dimensions and proof points are (those are §2).

Approximate length target. 150–250 words.
________________________________
§1.4 Audience for the Accessibility Maturity Model
Purpose. Identifies the organizational roles that benefit from the AMM and signals to readers whether the document is relevant to their work.
Scope.

  *   Executive leadership (decision-making, resourcing).
  *   Other levels of management responsible for accessibility maturity (program owners, governance roles).
  *   Policy and business process subject-matter experts (the people who put plans, metrics, and governance in place).
  *   A line on how a reader at each level uses the document differently, if it adds value without padding.

Out of scope.

  *   The maturity content itself.
  *   Any "and people with disabilities" framing — they're part of the assessment process (engaged for credibility), not the primary audience for the document. That belongs in §1.2 Recommended Practices.

Approximate length target. 100–150 words.






Jeff Adams (he/him)

Vice President – Accessibility Operations


[UsableNet]



jeff.adams@usablenet.com<mailto:chris.werely@usablenet.com>

[Certified Professional in Accessibility Core Competencies (CPACC)]