Define bounded authoring of the Web Accessibility Standard

[jamesreimer]

Purpose and authority

Define the bounded authoring action for Web Accessibility Standard, candidate ID web-accessibility, as the first earned companion of the Web Standards Suite.

Parent: #14. Governing planning decision: accepted research and narrowed scope. Supporting research and disposition.

Current authorization is issue creation and scope definition only. Stop before repository-file drafting, catalog expansion, branch creation, commit, or pull request. This issue is not itself permission to implement its proposed file scope. No umbrella or other companion authoring is authorized. Parent #14 remains open.

Reusable problem and normative boundary

Establish a concise, organization-neutral web-accessibility standard that selects a technical target, preserves external conformance semantics, and makes accessibility evidence and claims reviewable. The accepted target is WCAG 2.2 Level AA.

The template should govern web-accessibility outcomes and accessibility-specific verification. It is not a restatement of WCAG, a legal-compliance policy, or a broader inclusive-design standard. Inclusive-use considerations may appear only as clearly identified informative guidance, with no implied complete inclusive-design conformance.

The standard remains independently adoptable. Accessibility is a proposed core suite dependency, but this template must not depend on unfinished companions or umbrella conformance. Ordinary informative links do not create adoption requirements.

Exact proposed future file scope

If separately authorized, use the existing two-file template convention:

Path	Proposed change
templates/web-accessibility/standard.md	Add the normative Web Accessibility Standard
templates/web-accessibility/README.md	Add purpose, boundaries, informative subject-specific adoption review, and legitimate adaptation considerations
CATALOG.md	Add only this template's ID, exact title, durable subject, and boundaries, once the template actually exists
repository-structure.txt	Regenerate only the deterministic snapshot changes caused by the new directory and two files, using the existing script

All other paths remain excluded, including root README, ADOPTION, naming/maintenance/authoring guidance, tests, validator, automation, and all other templates. No new schema, evidence-file format, tooling, or dependency package. If authoring reveals a necessary change outside these four paths, report it and seek a scope decision instead of expanding implicitly.

Follow CONTRIBUTING.md, MAINTAINING.md, NAMING.md, AGENTS.md, the existing authoring standard, and adjacent README conventions. No repository classification or organizational authority is created by this planning issue.

Source and incorporation research

Anchor the source review to the 12 December 2024 WCAG 2.2 Recommendation and its conformance section.

Review the official errata before drafting and again before proposing publication. Record review date, affected criteria/definitions, source classification, applicability to the dated Recommendation, and the disposition of each relevant change. Identify exactly which source edition and corrections the candidate incorporates; no moving “latest” dependency.

The errata page inspected on 2 September 2026 distinguishes editorial and substantive corrections and says proposed substantive corrections are not normative until a revised Recommendation is published. Its current-publication list includes changes to hover/focus content and definitions. This discovery is not a completed clause-by-clause errata review. Preserve that distinction, and do not silently promote proposals into external requirements.

Incorporation/mapping decisions must:

• Reference external obligations precisely without copying WCAG or assigning new local numbers to its success criteria.
• Keep local requirement IDs separate from external identifiers. Pin local version/revision and source edition in evidence references.
• Distinguish incorporated external requirements from independently justified local requirements, informative Understanding/Techniques/APG guidance, and examples.
• Produce a reviewable completeness mapping covering the chosen target and conformance conditions, rather than a selected checklist masquerading as full coverage.
• Preserve source-defined alternatives and exceptions; do not omit inconvenient provisions or broaden exceptions.
• Recheck relevant HTML/ARIA sources when a local claim actually depends on them, without importing every statement from those sources.

Research mappings and disposition records stay in this issue or later authorized review records unless another artifact is separately justified.

Required authoring decisions

Define, without changing external meanings:

1. Scope and target: the assessed web experience, artifact/release, pages/routes, states and processes, declared technical target, material exclusions, and boundaries of any assessment.
2. External conformance: full-page and complete-process treatment, accessibility-supported technology use, non-interference, and applicable conforming-alternate-version provisions.
3. Claims: distinguish local-standard conformance, WCAG conformance, assessment progress, partial results, and undetermined results. No mandatory public badge or certification scheme. When a WCAG claim is made, preserve its applicable required contents.
4. Unknowns: missing, stale, inaccessible, or unperformed required checks remain unverified; an automated clean scan is not full conformance.
5. Exceptions and adaptations: distinguish source-defined exceptions from local waivers or deviations. Organizational permission to depart does not change WCAG's meaning or establish unchanged baseline conformance.
6. Alternative targets: preserve legitimate independent adoption and stronger obligations. Explain how a different edition/level or weaker local variant changes the claim and mapping; do not label it unchanged WCAG 2.2 AA or unchanged suite-baseline conformance.
7. Change effects: reassess affected evidence when implementation, scope, source edition, or local requirements change; no automatic downstream mutation.
8. Inclusive-use information: clearly mark additional considerations and research gaps as informative. Do not mix them into the incorporated WCAG set or imply all user needs are covered.

Calibrate local mandatory requirements, recommendations, and permissions against protected consequences under the authoring standard. Do not add process ceremony merely to make compliance look formal.

Verification responsibilities

Keep accessibility-specific test meaning and results with this standard. Future Quality/Verification may govern shared evidence integrity but must not own duplicate accessibility assertions or become an undeclared prerequisite.

• Automated: identify repeatable machine-checkable findings, covered rules, artifact/environment/tool versions, and false-positive or coverage limitations.
• Manual: review keyboard operation, focus behavior, zoom/reflow, state transitions, semantic meaning, alternatives, and source exceptions where human judgment is necessary.
• Assistive technology: define justified browser/technology combinations and relevant tasks; record actual observations and limitations, not assumed compatibility.
• Specialist review: identify when complex widgets, media, ambiguous mappings, or limited evaluator expertise require qualified review. Unavailable expertise produces a gap, not a pass.
• Implementation and review assistance: use the same evidence requirements; distinguish observed, tool-produced, and inferred findings. Neither screenshots nor generated reports prove unperformed interaction or user testing. No live-system/data access is granted.

Plan evidence identifying requirement/source, assessed revision and scope, method/environment, expected/observed result, evaluator/tool, date, and limitations. Avoid a universal storage schema or retention regime.

Pressure-test the candidate against reflow exceptions, pointer-only custom controls, modal focus, semantic relationships, third-party content, incomplete multi-step processes, absent manual evidence, legitimate alternate versions, and adapted targets. Distinguish desk tests from actual browser/assistive-technology tests and pilots.

Informative README adoption review

Reference the universal ADOPTION.md; do not duplicate it or create a separate contributor policy. Add bounded questions about:

• existing accessibility obligations, targets, authority, stronger protections, and conflicting terminology;
• covered pages/processes, embedded or third-party content, and legacy constraints;
• target/source-edition differences and their consequences for claims;
• migration effects, accessible alternatives, and preservation of existing protection;
• available automated, manual, assistive-technology, and specialist verification;
• unresolved evidence, local exceptions, and whether adoption adds durable value;
• separation of informative inclusive-use guidance from normative requirements.

Keep pre-adoption safety questions distinct from legitimate organization-specific adaptation choices.

Exclusions

No legal certification or legal interpretation; mandatory vendor/tool/framework; organization-specific approval workflow; broader inclusive-design conformance; umbrella or other companion requirements; brand/design-system rules; new records regime; automation; adopter implementation, adoption, synchronization, or mutation.

No catalog addition, repository drafting, branch, commit, or PR in the current issue-definition pass. Creating this issue does not approve eventual text or authorize publication.

Review gates before any drafting

• Exact title, ID, four-path proposed scope, and independent boundary confirmed.
• Dated source and relevant errata disposition reviewed; incorporation and mapping approach accepted.
• Local/external requirement boundaries and conformance/exception/alternative-target handling resolved.
• Verification responsibilities and unresolved coverage limitations documented.
• Informative inclusive-use and subject-specific adoption-review boundaries confirmed.
• A separate bounded drafting instruction is supplied before any repository-file work begins.

For later authorized drafting, run the existing unit tests and repository validator; regenerate the structure snapshot only for the authorized new paths; check Markdown links/anchors, UTF-8/LF, final newline, and git diff --check. Manually verify external claims and normative calibration. Mechanical validation does not establish accessibility conformance.

Current completion boundary: create and link this one child issue, report it, and stop. Keep #14 open; do not start drafting.

[jamesreimer]

I confirm the proposed authoring contract for the Web Accessibility Standard, candidate ID web-accessibility, subject to completion of the remaining dated-source and completeness-mapping gate.

Accepted planning decisions:

• exact title: Web Accessibility Standard;
• exact candidate ID: web-accessibility;
• independent adoption boundary;
• proposed four-path repository scope;
• WCAG 2.2 Level AA as the technical target;
• external WCAG identifiers retained without local renumbering;
• local requirements kept distinct from incorporated external criteria;
• WCAG conformance, local-standard conformance, partial assessment, nonconformance, and undetermined status kept distinct;
• accessibility-specific verification retained by this standard;
• informative inclusive-use guidance kept outside the normative WCAG target; and
• all exclusions and protected boundaries stated in this issue.

I authorize one bounded issue-only source-disposition and completeness-mapping pass on issue #17.

Use as the normative external anchor:

• Web Content Accessibility Guidelines (WCAG) 2.2
• W3C Recommendation dated 12 December 2024
• https://www.w3.org/TR/2024/REC-WCAG22-20241212/

Review the official errata as they exist on 2 September 2026:

• https://www.w3.org/WAI/WCAG22/errata/

The pass must:

1. Record the Recommendation identity, status, date, and immutable URL.
2. Enumerate every Level A and Level AA success-criterion identifier in the dated Recommendation without copying or locally renumbering the criteria.
3. Confirm that Level AA includes all applicable Level A and Level AA success criteria.
4. Map the complete WCAG 2.2 conformance model, including:
   • conformance level;
   • full pages;
   • complete processes;
   • only accessibility-supported ways of using technologies;
   • non-interference;
   • optional conformance claims and their required components when made;
   • third-party-content partial-conformance statements;
   • language partial-conformance statements; and
   • applicable conforming-alternate-version treatment.
5. Note that WCAG 2.2 removed Success Criterion 4.1.1 Parsing, while avoiding any claim that this automatically alters separate obligations tied to earlier WCAG editions.
6. Review every erratum listed since the 12 December 2024 publication and record:
   • date;
   • affected criterion, definition, example, or section;
   • W3C classification;
   • whether it affects normative text, an informative example, terminology, markup, presentation, or editorial clarity;
   • relevance to the proposed standard or mapping; and
   • explicit disposition.
7. Preserve the 12 December 2024 Recommendation as the normative dependency. Editorial errata may be acknowledged and used to avoid reproducing known wording or interpretation defects, but must not be represented as a different conformance level or independently authored local requirement.
8. Confirm whether the reviewed errata page contains any substantive correction. Any substantive correction must remain non-normative unless and until W3C publishes a revised Recommendation, consistent with W3C’s stated errata process.
9. Identify any unresolved ambiguity that would prevent accurate drafting, complete mapping, or truthful conformance claims.
10. State whether the source-and-mapping gate is satisfied and whether bounded repository drafting can be recommended.

Use official W3C sources for all load-bearing claims. Informative Understanding documents, Techniques, and APG materials must remain clearly identified as informative and must not be treated as normative WCAG text.

Record the results as a comment on issue #17. Do not create or modify repository files, the catalog, structure snapshot, tests, tooling, branches, commits, pull requests, child issues, adopters, or other standards. Keep parent issue #14 open.

Stop after the issue-only research comment for review. This authorization does not yet permit standard drafting or publication.

[jamesreimer]

Dated-source disposition and completeness mapping — 2 September 2026

Under the issue-only authorization, the source-and-mapping gate is satisfied at research level. Bounded drafting of Web Accessibility Standard (web-accessibility) can be recommended for separate authorization. This is not approval of unwritten text, proof of a website's conformance, or permission to begin drafting.

1. Normative dependency and inventory

Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 12 December 2024. Retain this immutable edition: REC-WCAG22-20241212. Do not substitute a moving editor's draft or an undated “latest” dependency.

The following inventory was extracted from that edition's success-criterion headings and level markers, then checked for unique identifiers and separation of levels. It contains 31 A + 24 AA = 55 criteria. The remaining 31 are AAA, outside the selected AA target. Only identifiers are reproduced; no local renumbering or criterion-text copies.

Principle	Level A identifiers	Level AA identifiers
1	1.1.1; 1.2.1; 1.2.2; 1.2.3; 1.3.1; 1.3.2; 1.3.3; 1.4.1; 1.4.2	1.2.4; 1.2.5; 1.3.4; 1.3.5; 1.4.3; 1.4.4; 1.4.5; 1.4.10; 1.4.11; 1.4.12; 1.4.13
2	2.1.1; 2.1.2; 2.1.4; 2.2.1; 2.2.2; 2.3.1; 2.4.1; 2.4.2; 2.4.3; 2.4.4; 2.5.1; 2.5.2; 2.5.3; 2.5.4	2.4.5; 2.4.6; 2.4.7; 2.4.11; 2.5.7; 2.5.8
3	3.1.1; 3.2.1; 3.2.2; 3.2.6; 3.3.1; 3.3.2; 3.3.7	3.1.2; 3.2.3; 3.2.4; 3.3.3; 3.3.4; 3.3.8
4	4.1.2	4.1.3

Level AA includes all applicable A and AA criteria, not AA alone; preserve the source's alternative-version provisions and other conformance conditions. §5.2.1

WCAG 2.2 removed 4.1.1 Parsing. This mapping does not alter separate obligations tied to earlier editions; those require their own source and obligation review.

A criterion with no applicable content is not the same as an unperformed check. Preserve that distinction in the local evidence model; absence needs a reason, not an empty test result. The Understanding explanation is informative support, not replacement normative text.

2. Complete conformance-model mapping

The source clauses, rather than this compact mapping, control. The intended local authoring destinations below are planning descriptions, not allocated requirement IDs or drafted clauses.

Dated source	Source condition / local mapping destination
§5.1	Separate normative content from notes, examples, and other informative material. Map to source interpretation.
§5.2.1	Map the declared AA target to the complete inventory above.
§5.2.2	Whole pages, including responsive variations. Map to scope and coverage, not selected components.
§5.2.3	Every page in a process meets the target or better. Map to process coverage.
§5.2.4	Reliance only on accessibility-supported uses; equivalent supported access otherwise. Map to technology-use evidence.
§5.2.5	Preserve access with non-relied-on technologies enabled, disabled, or unsupported; check 1.4.2, 2.1.2, 2.3.1, 2.2.2 throughout. Map to non-interference.
§5.3	Claims optional; when made: date, WCAG title/version/URI, level, page scope, relied-on technologies. Map to truthful reporting.
§5.4	Map both source-defined third-party-content routes, separately from ordinary local exceptions.
§5.5	Identify language-support limitations as partial-conformance statements, not full conformance.
§6 alternate-version definition	Map all definition conditions and relevant notes; do not substitute an arbitrary “accessible version” link.

Additional interpretation checks, supported by the informative W3C Understanding Conformance, and checked against the dated normative clauses:

• Accessibility support concerns particular uses and interoperability with assistive technology in the content's language, plus available supported user contributors—not blanket certification of a technology.
• Alternate versions need the target level, equivalent information/functionality in the same language, and currency. Access must follow one of the definition's three permitted routes: supported access from the original; original reachable only from its conforming version; or original reachable only from a conforming page also offering the alternate.
• Preserve relevant alternate-version notes: page-for-page matching is unnecessary; account for each offered language, equal availability, supported preference mechanisms, and the distinction from supplemental content. Non-interference still matters.
• Third-party partial statements identify genuinely uncontrolled parts and acknowledge nonconformance. They are not a generic exemption for purchased widgets or a renamed full claim.

The dated §5.4 also provides a monitoring/repair route with a two-business-day condition. The alternative statement route identifies uncontrolled parts whose removal would permit conformance. Drafting must preserve both routes and their actual conditions; this source-specific provision must not become a universal repair SLA.

Local mapping decisions: keep WCAG conformance, local-standard conformance, partial assessment, nonconformance, and undetermined status separate. Local adaptation cannot modify the meaning of an external claim. Source-defined alternatives are not local waivers. No claim requirement creates a mandated metadata format or public badge. §5.3.2's optional additions remain optional; §5.6–5.7 privacy/security discussion remains informative.

3. Errata census and disposition

Reviewed the complete official errata page as retrieved 2 September 2026; displayed last modification: 28 August 2026, 17:37:39.

The post-12-December-2024 section contains 17 entries: six dated 17 August 2026, six dated 28 October 2025, five dated 27 June 2025. All are classified Editorial by W3C. No substantive correction is listed anywhere on the reviewed page. Earlier-publication entries were inspected for chronology but are not counted again as post-anchor errata.

In the table, E = W3C Editorial. “Text affected” is this review's analytical classification, distinct from W3C's change classification. Linked W3C-owned change records clarify the affected text.

Disposition vocabulary:

• Clarity: acknowledge in research; use to avoid misleading explanatory wording, without replacing the normative edition.
• Presentation: acknowledge; avoid reproducing the defect; no criterion or evidence assertion added.
• Interpretation: retain an explicit interpretation note and preserve the dated obligation; do not treat corrected prose as a new local requirement.
• Informative: usable only in clearly informative guidance, never incorporated as an additional AA criterion.

Date	Affected location / change record	W3C	Text affected	Relevance and explicit disposition
2026-08-17	single-pointer spelling 5038	E	Terminology	Clarity; keep input terminology consistent, no new modality rule.
2026-08-17	process example 3538	E	Informative example	Informative; avoid implying the example exhausts process coverage.
2026-08-17	new-definition title attributes 4857	E	Markup/presentation	Presentation; no new definition or criterion.
2026-08-17	privacy/security grammar 4776	E	Informative editorial clarity	Informative; do not create privacy/security requirements here.
2026-08-17	criterion reference names 4947	E	Editorial clarity	Clarity; retain external IDs; reference readability is not renumbering.
2026-08-17	1.4.13 exception 4741	E	Normative wording and informative note	Interpretation; preserve the source exception's boundary; no locally expanded waiver.
2025-10-28	1.4.13 preamble 4469	E	Normative editorial clarity	Interpretation; do not read the enumerated conditions as an optional choice.
2025-10-28	email spelling 4385	E	Terminology	Clarity; no new authentication or contact requirement.
2025-10-28	§7 preamble 4458	E	Normative-section wording	Interpretation; apply 1.3.5's actual applicability, not a new blanket taxonomy mandate.
2025-10-28	abbreviation notes 4452	E	Informative-note markup	Presentation; no glossary obligation added.
2025-10-28	capitalization 4461	E	Terminology/editorial style	Clarity; no keyword-strength change.
2025-10-28	supporting-link boxes 4590	E	Presentation	Presentation; linked guidance stays informative.
2025-06-27	glossary ordering 4256	E	Presentation	Presentation; user-inactivity/user-interface-component placement does not change either definition.
2025-06-27	motion-animation explanation 4040	E	Informative example	Informative; do not perpetuate an overbroad blur exclusion or import AAA into AA.
2025-06-27	3.2.6 note spelling 4165	E	Informative terminology	Clarity; no new breakpoint or responsive-layout rule.
2025-06-27	introductory guidance link 2296	E	Informative navigation	Informative; linked supplemental material does not expand the target.
2025-06-27	perimeter/single-pointer punctuation 4359	E	Definition punctuation	Clarity; no geometry/input requirement added.

Important distinctions confirmed by inspecting W3C's patches:

• 4040 edits the example beneath the motion-animation definition, not its defining sentence.
• 3538 changes a process example, not the definition's controlling sentence.
• 4458 changes the §7 preamble's description of taxonomy purposes. Keep the anchor fixed and avoid independently restating that preamble as a stronger local requirement.
• 4741 affects both the exception and its note; 4469 clarifies the preamble. “Editorial” must not be misreported as “only visual formatting.”

The page's stated process keeps proposed substantive corrections non-normative until a revised Recommendation is published. Nothing reviewed activates that situation. Editorial acknowledgment here does not establish a different level, a new local criterion, or a mutable normative dependency. W3C errata process statement

4. Integrity checks, ambiguities, and gate decision

Retrieval evidence, computed in memory without creating files:

• Dated Recommendation retrieved HTML SHA-256: 6e3c5fe397257cae509a2fb4752b73062cf8cbeb92c2cec618989b17e4cf7057.
• Errata retrieved HTML SHA-256: 6cb459d4d49f83fdefbac8de27e9b26aff46e577791ccc0cdb864eba70ddd596.
• Inventory: 55 unique A/AA IDs; no AAA ID or removed 4.1.1 included.
• Post-anchor errata census: 17/17 dispositioned.

These are retrieval checksums, not new normative identifiers or a claim that the mutable errata URL is immutable.

No unresolved source ambiguity prevents accurate bounded drafting under the fixed-anchor approach. The potentially misleading points—editorial changes touching normative prose, example versus definition, a source-specific repair condition, optional claims versus mandatory contents when claimed, and partial statements versus actual conformance—are explicitly dispositioned above.

For later drafting, map each local assertion back to these source sections; verify that no local summary broadens an exception or drops a conformance condition. If a concrete contradiction cannot be resolved without choosing a new normative edition or changing the accepted target, return for a decision rather than patching WCAG locally.

Understanding documents were used only as informative interpretive support. Techniques and APG are not normative dependencies in this mapping. Inclusive-use guidance remains informative and separate. This inventory is not a completed per-criterion test implementation, live audit, or pilot.

Decision: source-and-completeness-mapping gate satisfied for the proposed authoring contract; bounded drafting is recommended, not authorized or begun. The user retains the review decision on this comment.

All 40 existing repository tests and the repository validator pass; git diff --check passes; working tree is clean. Those checks do not certify the source judgments or accessibility. No repository files, catalog, structure snapshot, tests, tooling, branches, commits, PRs, child issues, adopters, or other standards were created or changed. Parent #14 remains open. Stop here for review.

[jamesreimer]

I accept the dated-source disposition and completeness mapping recorded on issue #17.

The review establishes:

• WCAG 2.2, W3C Recommendation dated 12 December 2024, as the fixed normative external dependency;
• a complete inventory of 31 Level A and 24 Level AA success criteria;
• preservation of WCAG’s full-page, complete-process, accessibility-supported-technology, non-interference, claim, partial-conformance, and conforming-alternate-version conditions;
• exclusion of removed Success Criterion 4.1.1 from the WCAG 2.2 target without altering separate obligations tied to earlier editions;
• explicit disposition of all 17 errata listed after the dated Recommendation as of 2 September 2026;
• no substantive correction listed on the reviewed errata page;
• separation of normative WCAG material from informative Understanding, Techniques, APG, examples, and supplemental guidance; and
• no unresolved source ambiguity preventing bounded drafting.

I authorize bounded drafting of the Web Accessibility Standard, stable template ID web-accessibility, from canonical main revision:

91c696a045627e1caa6f2268e01cbf56ad02f55f

Authorized path scope is exactly:

• templates/web-accessibility/standard.md
• templates/web-accessibility/README.md
• CATALOG.md
• repository-structure.txt

No other path may change.

Normative standard

Create templates/web-accessibility/standard.md as an organization-neutral normative standard.

It must:

• use the exact human-facing title Web Accessibility Standard;
• identify WCAG 2.2 Level AA from the immutable 12 December 2024 Recommendation as its default technical target;
• use local requirement identifiers in the form WEB-A11Y-NNN, independent of section numbering;
• retain WCAG success-criterion identifiers as external identifiers without renumbering or copying the complete criterion text;
• distinguish external WCAG obligations from local requirements synthesized by this template;
• require a declared assessment scope identifying the evaluated web experience, artifact or release, covered pages or routes, relevant states and complete processes, and material exclusions;
• preserve all applicable WCAG conformance requirements rather than reducing Level AA to a selected checklist;
• distinguish local-standard conformance, WCAG conformance, partial assessment, nonconformance, source-defined partial-conformance statements, and undetermined status;
• preserve the optional nature and required contents of WCAG conformance claims;
• distinguish a source-defined exception or conforming alternate version from a local waiver or adaptation;
• prevent an automated clean scan, sampled page, unperformed manual test, inaccessible environment, stale result, or missing evidence from being represented as full conformance;
• require evidence proportionate to the applicable requirement and identify scope, assessed revision, method, environment, expected and observed result, evaluator or tool, date, limitations, and unresolved findings without creating a mandatory file format or retention system;
• distinguish automated, manual, assistive-technology, and specialist verification responsibilities;
• require reassessment of affected obligations when implementation, scope, target edition, local requirements, or relevant evidence changes;
• explain how stronger, different, or weaker adopted targets affect local and external claims without presenting an adapted target as unchanged WCAG 2.2 AA conformance;
• preserve the fixed dated Recommendation as the normative dependency while accurately acknowledging reviewed editorial errata;
• state clearly that the standard does not provide legal certification or determine applicable legal obligations;
• keep inclusive-use considerations informative and avoid claiming complete inclusive-design coverage;
• remain independently adoptable without requiring the unfinished umbrella or another companion standard; and
• keep intended publication wording truthful in both candidate and canonical contexts.

Calibrate every MUST, SHOULD, and MAY against the protected consequence under the existing authoring standard. Do not create approval roles, mandatory badges, universal audit ceremonies, prescribed vendors, fixed browser matrices, automatic downstream updates, or a new records regime.

Informative README

Create templates/web-accessibility/README.md using adjacent template conventions.

It must include:

• stable template ID and exact human-facing title;
• purpose and independently adoptable boundary;
• reference to root ADOPTION.md for the universal adoption review;
• a concise informative accessibility-specific adoption review;
• separate likely organization-specific adaptation choices;
• explanation of the fixed WCAG target and consequences of selecting another target;
• verification considerations and tool limitations;
• the distinction between normative accessibility requirements and informative inclusive-use guidance;
• conceptual boundaries with design, layout, interaction, content/semantics, quality/verification, legal compliance, and organizational approval authority; and
• primary-source references without copying WCAG.

It must not create a separate contributor policy, duplicate the universal adoption checklist, or imply that adopting the template itself establishes WCAG or legal conformance.

Catalog and structure snapshot

Update CATALOG.md only to add the completed web-accessibility template with its exact title, durable subject, and important boundaries.

Regenerate repository-structure.txt using the existing repository script. The snapshot change must contain only:

• templates/web-accessibility/
• templates/web-accessibility/README.md
• templates/web-accessibility/standard.md

Do not manually introduce unrelated snapshot changes.

Validation

Validate:

• exact four-path scope;
• title and stable template ID;
• uniqueness and sequential consistency of local WEB-A11Y-NNN identifiers;
• separation of local identifiers from WCAG identifiers;
• complete and accurate treatment of the selected target and WCAG conformance model;
• no copied or selectively rewritten WCAG checklist masquerading as full incorporation;
• normative/informative separation;
• requirement-strength calibration;
• candidate/publication truthfulness;
• all internal and external links;
• catalog and template-boundary consistency;
• deterministic structure-snapshot regeneration;
• UTF-8, LF, and one final newline;
• git diff --check;
• all existing unit tests; and
• repository validation.

Mechanical validation does not establish accessibility conformance. Manually recheck every load-bearing external claim against official W3C sources.

Create one draft, intentionally unmerged pull request. Record candidate-ready evidence on issue #17 including the branch, canonical base, exact head, all four resulting blob IDs, complete diff scope, requirement inventory, source treatment, validation results, and PR link.

Stop for exact content and normative-calibration review. Do not merge, publish, close issues #14 or #17, draft another companion, modify an adopter, synchronize downstream material, or create a work-log entry.

[jamesreimer]

Candidate ready — bounded Web Accessibility Standard draft

Prepared under the authenticated drafting authorization, following the accepted source-and-completeness mapping.

• Draft PR: docs: add web accessibility standard template #18
• Branch: codex/web-accessibility-standard
• Exact canonical preparation base: 91c696a045627e1caa6f2268e01cbf56ad02f55f
• Exact candidate head: 2e639d69699e984add3cba3c96249abe0cf27212
• Title: Web Accessibility Standard
• Stable template ID: web-accessibility

Exact four-path candidate

Path	Blob	Diff
templates/web-accessibility/standard.md	2bfa83a519dfcb8832f0b540f23abe9c6f6292b5	+111/−0, added
templates/web-accessibility/README.md	9d7df2df7ca41be85e302605f2eec86319062e25	+70/−0, added
CATALOG.md	d634be2af6c23845088c90d407c1e340ce164022	+13/−0
repository-structure.txt	e68102202bd902ac2cbdcaf1ab3ddaa5c2615933	+3/−0

Total: four files, +197/−0. The snapshot was generated with the existing script and adds only the directory and its two files. The catalog only adds the new template entry. Every other tracked artifact is unchanged.

Local requirement inventory

These are synthesized local requirements, not renumbered WCAG criteria.

ID	Subject	Calibration
WEB-A11Y-001	Declared assessment scope	Mandatory scope/claim integrity
WEB-A11Y-002	Complete target incorporation	Mandatory, subject to explicitly identified adopted target
WEB-A11Y-003	Complete coverage mapping	Mandatory evidence traceability
WEB-A11Y-004	Source conditions versus local waivers	Mandatory external-conformance integrity
WEB-A11Y-005	Technology and context	Mandatory support/non-interference evidence
WEB-A11Y-006	Reviewable evidence	Mandatory proportional evidence; shared context permitted
WEB-A11Y-007	Method coverage	Mandatory adequate methods; no clean-scan shortcut
WEB-A11Y-008	Actual manual/assistive-technology results	Mandatory observed or justified reusable evidence
WEB-A11Y-009	Competence limits	Mandatory uncertainty handling; specialist review permitted when useful
WEB-A11Y-010	Sampling limits	Sampling permitted; extrapolation requires justified coverage
WEB-A11Y-011	Evaluation timing	SHOULD; legitimate retrospective assessment remains possible
WEB-A11Y-012	Distinct outcomes	Mandatory separation of local/external conformance, coverage, failures, source statements, and uncertainty
WEB-A11Y-013	Unsupported completion claims	Mandatory truthful results and candidate/publication wording
WEB-A11Y-014	Optional WCAG claims	MAY claim; all required source components mandatory if claimed
WEB-A11Y-015	Partial-conformance statements	Mandatory source conditions and nonconforming meaning
WEB-A11Y-016	Affected-obligation reassessment	Mandatory after relevant change; justified unaffected evidence reuse permitted
WEB-A11Y-017	Explicit alternative targets	Governed alternatives permitted; mandatory truthful target/claim distinction
WEB-A11Y-018	Fixed-source integrity	Mandatory dependency integrity; editorial clarification permitted without silent replacement

Mandatory strength protects concrete target, evidence, or claim failures. No recommendation was strengthened merely for convenience or appearance of rigor. Permissions do not create approval authority or relax source-defined conditions.

Source treatment and manual review

The normative external dependency remains the WCAG 2.2 W3C Recommendation dated 12 December 2024, default Level AA. The complete conformance model and applicable definitions are incorporated by reference, not selectively copied. Local identifiers remain separate from unchanged external success-criterion identifiers.

Re-extracted the fixed source's inventory: 31 Level A and 24 Level AA success criteria; removed 4.1.1 is absent from the target without changing separate earlier-edition obligations. Rechecked full-page and complete-process treatment, accessibility-supported uses, non-interference, optional claims and required components, both source partial-conformance categories, the separate monitored third-party-content route, and qualifying alternate-version conditions.

Rechecked the official errata as of 2 September 2026: all 17 post-publication entries remain Editorial and no substantive correction is listed. The draft acknowledges that editorial corrections can touch normative wording without silently replacing the dated dependency. Proposed substantive corrections are not treated as normative before a revised Recommendation.

W3C evaluation guidance, Understanding, Techniques, and APG remain informative. Inclusive-use guidance does not create an inclusive-design conformance target. The README is informative, uses root ADOPTION.md for universal review, and separates subject-specific safety questions from adaptation choices.

Manual desk review covered clean scans, unperformed tests, missing or stale evidence, inaccessible environments, sampling, known failures during partial assessment, excluded process steps, source alternate versions versus waivers, source partial-conformance statements, retrospective evaluation, reassessment, and alternative targets. Candidate/publication language does not assert adoption, approval, effectiveness, or accessibility conformance that has not occurred.

Validation results

• All 40 existing unit tests passed.
• Existing repository validator passed: 6 templates, 20 Markdown files.
• Internal links and anchors, Markdown structure, title/ID consistency, and catalog boundaries passed.
• 14 distinct affected external URLs/fragments verified across 5 official W3C documents.
• WEB-A11Y-001–018 uniqueness and sequential consistency passed.
• UTF-8, LF, exactly one final newline, and git diff --check passed.
• Repeated structure generation was byte-identical; snapshot scope is exactly the three authorized lines.
• Complete committed diff reviewed: four paths, +197/−0, no unrelated edits.
• GitHub Repository validation passed, with zero annotations.
• Remote candidate matches the committed head; local worktree is clean.

Mechanical validation does not establish accessibility conformance. The manual preparation review does not substitute for the requested exact-content and normative-calibration approval.

Stopping boundary

PR #18 remains draft, open, and intentionally unmerged. Issues #14 and #17 remain open. Canonical main remains at the preparation base. No other companion, adopter, downstream artifact, synchronization, automation, or work-log entry was created or changed. No automatic consumer update is required or authorized.

Preparation is complete. Stopped for exact content and normative-calibration review.

[jamesreimer]

Corrected candidate ready — WCAG no-applicable-content treatment

Updated draft PR #18 with exactly the user-supplied WEB-A11Y-002 and WEB-A11Y-003 paragraphs and the specified sentence replacement within WEB-A11Y-013.

• Branch: codex/web-accessibility-standard
• Canonical base: 91c696a045627e1caa6f2268e01cbf56ad02f55f
• Prior candidate: 2e639d69699e984add3cba3c96249abe0cf27212
• New exact candidate head: efaaf0505ec9f8a7da0e7839273b6cc0a883fbf6

This head supersedes the prior candidate identity for renewed exact-content and normative-calibration review.

Exact resulting blobs

Path	Resulting blob	Change from prior candidate
templates/web-accessibility/standard.md	e68e41ba3000acf62d69d93032d97da2635e1273	Changed: exactly the three authorized replacements
templates/web-accessibility/README.md	9d7df2df7ca41be85e302605f2eec86319062e25	Byte-identical
CATALOG.md	d634be2af6c23845088c90d407c1e340ce164022	Byte-identical
repository-structure.txt	e68102202bd902ac2cbdcaf1ab3ddaa5c2615933	Byte-identical

Only the Standard blob changed. Incremental diff: one file, +3/−3, at existing lines 38, 40, and 75. An exact byte comparison reconstructed the requested replacements from the prior candidate and matched the complete resulting Standard; every other byte is unchanged. No formatting adjustment was necessary.

Cumulative PR scope remains exactly the original four paths, +197/−0: Standard +111, adjacent README +70, catalog +13, structure snapshot +3. Every other repository artifact remains unchanged.

Interpretation and source review

The fixed Recommendation's definition of satisfaction and W3C's informative Understanding Conformance explanation support the corrected distinction: established absence of applicable content yields a satisfied criterion, not an evidence gap. The criterion remains in the completeness mapping with its applicability basis. Unperformed, inaccessible, missing, stale, or unresolved evaluation is not interchangeable with that established basis.

Rechecked complete incorporation and interpretation: every Level A and AA success criterion is evaluated under its source-defined conditions; all five conformance requirements, claim conditions, partial-conformance treatment, and qualifying alternate-version conditions remain intact. The fixed dated Recommendation remains normative; Understanding remains informative. The source inventory remains 31 Level A and 24 Level AA, excluding removed 4.1.1.

The correction narrows the ambiguity without adding requirements outside the authorized replacements or weakening the prohibition on unsupported passing results. All other normative calibration and scope remain unchanged.

Validation

• All 40 existing tests passed.
• Repository validator passed: 6 templates, 20 Markdown files.
• Markdown structure and internal links/anchors passed.
• All 14 affected external URLs/fragments across 5 W3C documents passed.
• WEB-A11Y-001 through WEB-A11Y-018 remain unique, sequential requirement definitions; the new WEB-A11Y-003 reference is a cross-reference, not a duplicate definition.
• UTF-8, LF, exactly one final newline, and git diff --check passed.
• Deterministic structure rendering was checked twice in memory against the existing snapshot; the snapshot file was not rewritten.
• Exact replacement-only byte preservation, one-file incremental scope, and four-file cumulative scope passed.
• GitHub Repository validation CI passed for the new head.
• Local worktree is clean; the candidate branch is pushed.

Mechanical validation does not establish accessibility conformance.

PR #18 remains draft, open, and intentionally unmerged. Issues #14 and #17 remain open. No canonical publication, issue closure, adopter modification, downstream synchronization, additional repository change, or work-log entry occurred. Stopped for renewed exact-content and normative-calibration review.

[jamesreimer]

Canonical publication evidence — Web Accessibility Standard

PR #18 was published by expected-head-protected squash merge from exact approved head efaaf0505ec9f8a7da0e7839273b6cc0a883fbf6.

• Canonical merge commit and resulting main: 58bb22b96b4873011a4acc3bbb6ce0fa2ccb9159
• Prior canonical parent: 91c696a045627e1caa6f2268e01cbf56ad02f55f
• Exact candidate approval and separate publication authorization were both verified attributable to jamesreimer and identifying the unchanged head and blobs.

Published identities and scope

Path	Verified published blob	Diff from prior canonical main
templates/web-accessibility/standard.md	e68e41ba3000acf62d69d93032d97da2635e1273	+111/−0
templates/web-accessibility/README.md	9d7df2df7ca41be85e302605f2eec86319062e25	+70/−0
CATALOG.md	d634be2af6c23845088c90d407c1e340ce164022	+13/−0
repository-structure.txt	e68102202bd902ac2cbdcaf1ab3ddaa5c2615933	+3/−0

Exact published scope: four files, 197 additions, zero deletions. The entire published Git tree is identical to the approved candidate tree. No approved content was modified, finalized, or rebased before publication. Every other tracked artifact is unchanged.

The published Web Accessibility Standard contains the 18 unique, sequential requirement definitions WEB-A11Y-001 through WEB-A11Y-018. The exact reviewed fixed-dependency, complete-incorporation, no-applicable-content satisfaction, evidence, conformance, and normative/informative boundaries are preserved.

Validation

• All 40 existing unit tests passed, both before merge and on synchronized canonical main.
• Repository validator passed on the candidate and canonical result: 6 templates, 20 Markdown files.
• Markdown structure and internal links/anchors passed.
• All 14 affected external URLs/fragments across 5 W3C documents passed before publication; published bytes are identical.
• Deterministic structure rendering was verified against the snapshot without changing it.
• UTF-8, LF, exactly one final newline, identifier sequencing, exact scope/blob checks, and git diff --check passed.
• Authorized-head PR CI passed.
• Canonical main-branch CI passed with zero annotations.

Mechanical repository validation does not establish accessibility conformance of an adopter or web experience.

Completion boundary and local state

Issues #14 and #17 remain open for separate completion and next-step review. No downstream repository or adopter was changed, adopted, or synchronized. No additional standard or companion was started, and no work-log artifact was created or modified.

The isolated current checkout's main is clean and synchronized to 58bb22b96b4873011a4acc3bbb6ce0fa2ccb9159. The merged codex/web-accessibility-standard branch was deleted locally and remotely after verifying its exact approved head; remote deletion used an explicit expected-head lease, and the remote-tracking ref was pruned. No sibling workspace was touched.

The connector's ready-for-review action encountered an unsupported GraphQL field before any transition. GitHub CLI performed only that authorized transition; the merge then used the connector's expected-head-protected squash operation.

Canonical publication and bounded cleanup are complete. No issue closure or downstream adoption is implied.

[jamesreimer]

Final completion review — Web Accessibility Standard

Completion review passes following a read-only canonical recheck. PR #18 is merged at 58bb22b96b4873011a4acc3bbb6ce0fa2ccb9159, which remains canonical main. The four exact published blobs and four-file, +197/−0 scope match the publication evidence.

Confirmed acceptance outcomes:

• Exact title Web Accessibility Standard, stable ID web-accessibility, and independent-adoption boundary are satisfied.
• Scope is exactly templates/web-accessibility/standard.md, templates/web-accessibility/README.md, CATALOG.md, and repository-structure.txt; all other repository artifacts remain unchanged.
• The fixed WCAG 2.2 W3C Recommendation dated 12 December 2024, complete 31 Level A + 24 Level AA inventory, applicable conformance model, and dated errata disposition were reviewed through the accepted source-and-completeness mapping.
• All 18 local requirement definitions, WEB-A11Y-001 through WEB-A11Y-018, are published, unique, and sequential.
• External WCAG obligations, synthesized local requirements, and informative guidance remain distinct; WCAG identifiers are not locally renumbered.
• Established absence of applicable content yields a satisfied criterion with its documented applicability basis and retained completeness-map entry. It remains distinct from missing, stale, inaccessible, unresolved, or unperformed evaluation.
• Assessment scope, verification responsibilities, proportionate evidence, source-defined exceptions and alternate versions, alternative adopted targets, source maintenance, reassessment, and truthful claims are addressed.
• Broader inclusive-design conformance, legal certification, new organizational authority, mandatory tooling, and unfinished suite dependencies remain excluded. Informative adoption guidance refers to universal ADOPTION.md rather than creating a competing policy.
• All 40 tests, repository validation, Markdown/internal links and anchors, external-link checks, deterministic structure generation/verification, UTF-8/LF and final newlines, and git diff --check passed as recorded in the immutable publication evidence. Tests, repository validation, and diff checks also passed again during this read-only closeout.
• Authorized-head CI and canonical-main CI were independently rechecked and remain successful.
• No adopter or downstream repository was changed or synchronized. Mechanical validation does not establish adopter accessibility conformance.

The earlier issue-body planning gates were subsequently satisfied by the recorded source review, separate drafting authority, exact candidate approval, publication authorization, and verified publication; this comment records their final disposition without rewriting historical planning text.

All acceptance criteria for this bounded child action are satisfied, with no remaining authoring or publication work under #17. Close #17 as completed. Parent #14 remains open for remaining suite architecture and companion work. This closeout selects no next candidate and authorizes no further drafting, downstream adoption, repository change, or work-log entry.