Summary

  • W3C published a new SVG Accessibility API Mappings Working Draft on 27 August 2026. The draft itself identifies 10 May 2018 as the previous Working Draft, an interval of 3,031 days, and records substantive technical change.
  • During public refinement of the proposed SVG Working Group charter, a 4 July comment asked for a concrete milestone and testing commitment for SVG AAM. The incorporation patch replaced “undetermined” with “aiming at progressing on testing.”
  • That wording is an honest signal of direction, but not an auditable milestone. It identifies no controlling revision, feature inventory, test-suite commit, coverage state, implementation pair, owner or review point.
  • The proposed charter already contains sound general criteria: open tests, early test planning and two independent interoperable implementations before advancement beyond Candidate Recommendation. The missing step is to bind those criteria to this deliverable.
  • W3C Process asks for expected milestone dates only “where available.” The absence of a date is therefore not evidence of a process breach, abandonment or bad faith.
  • A thin testing-milestone receipt would let readers distinguish a new publication from test coverage, implementation experience and a maturity decision without creating a new approval gate.

The number that changed was not in the charter

For eight years, three months and seventeen days, the dated W3C publication record for SVG Accessibility API Mappings pointed to the same Working Draft. The 10 May 2018 edition remained the last published draft until W3C issued the 27 August 2026 edition. The new document states that history plainly. The interval is 3,031 days.

That count should not be used as a synonym for inactivity. Public repositories can move while a /TR snapshot remains old; editors can revise text without producing a new dated publication. The 2026 draft lists meaningful changes since 2018, including revisions to accessible-name computation, SVG roles, mappings for elements and attributes, and treatment of hidden and presentational content. The publication gives implementers and reviewers a new fixed reference. That is progress.

It is also a Working Draft. Its own status section warns that publication does not imply endorsement by W3C or its Members and that the document may be updated, replaced or made obsolete. A Working Draft can prove that a particular text was published for review. It cannot, by that fact alone, prove that its normative features have tests, that the tests cover those features, that independent products pass them or that the document is ready for a higher maturity stage.

Nine days before the publication, a different public record changed. The proposed SVG Working Group charter had gone through refinement in W3C Strategy issue 559. On 4 July, a public comment pointed to SVG AAM’s 2018 Working Draft and its “undetermined” expected completion, then asked for a concrete milestone and a commitment to testing. On 18 August, the SVG team contact said refinement was over and that suggestions had been incorporated.

The immutable incorporation commit is unusually legible. It changed three lines: one repaired a charter link, one expanded the statement about WHATWG coordination, and one replaced SVG AAM’s expected completion from “undetermined” to “aiming at progressing on testing.” The charter at that commit still names the 2018 draft as the adopted draft. The later Working Draft makes that reference stale, but the more important problem is semantic. A direction of travel replaced an unknown state. No measurable state replaced it.

An intention is useful, but it cannot close a review

“Aiming at progressing on testing” is not empty language. It tells members that testing is expected to receive attention. It avoids inventing a date that the group may not be able to keep. It may be the most candid statement available when contributors, implementation commitments or cross-group work are unsettled.

But the phrase cannot answer the questions for which a milestone exists. What draft is being tested? Which normative features are in scope? Where is the controlling test suite? How much of the feature inventory is mapped to tests? Which implementations count as independent? What result would justify a maturity transition? Who owns an unresolved action, and when will the evidence be reviewed again?

The distinction matters because “testing” can name several different activities. An editor can add one regression test. A contributor can open a test repository. A working group can adopt a test plan. A browser can pass a set of assertions. Two accessibility stacks can expose the same semantics under controlled conditions. Each is real work, but they are not interchangeable evidence states.

The active 2024 SVG charter, which runs through 30 September 2026, shows the earlier condition directly: it lists SVG AAM as a 10 May 2018 Working Draft and gives expected completion as undetermined. The proposed successor improves the signal by naming testing. Yet a reviewer comparing the two charters still cannot tell what observable event would convert the new words into “progress achieved.”

That is the governance gap. It is smaller than a missing programme and larger than a missing date. The group has a deliverable, a public draft, repositories and general success criteria. What it lacks in the charter-facing record is the binding layer between them.

The general success criteria are already strong

The proposed charter does not treat tests as an afterthought. Its deliverables include a test suite and an implementation report. Its general success criteria call for publicly available tests for every feature, encourage test planning from the earliest drafts, and require at least two independent interoperable implementations of each feature before a specification advances beyond Candidate Recommendation.

Those provisions are important counterevidence to any claim that testing has been ignored. They align with the W3C Process discussion of implementation experience, which treats adequacy as a contextual inquiry. The Process asks whether every feature is implemented, whether implementations interoperate, whether implementers are independent, whether the work is deployed beyond merely experimental settings, what levels of the ecosystem are covered and what problems have been reported. It also observes that test planning is often most effective when it begins early.

The weakness is not the absence of a general standard. It is that the standard is not yet instantiated for SVG AAM. A charter-wide sentence can tell every specification what eventual success should resemble. It does not identify the current SVG AAM feature inventory, the tests that correspond to it, or the implementation evidence available at a particular review.

Imagine a group reporting that its test count doubled. That can be encouraging while leaving coverage unchanged if the new tests cluster around already tested behaviour. Imagine a suite showing broad feature coverage. That still does not demonstrate interoperability if all results come from one engine or from products sharing an implementation. Imagine two independent products passing. The result may still be irreproducible if versions, operating environments, assistive-technology combinations and exclusions are not recorded.

The criteria therefore need an evidence index, not stronger adjectives. The proposed charter has already chosen the destination. A deliverable-specific milestone should show the public where SVG AAM is on that route.

“Where available” is a restraint, not a loophole

The W3C Process requirements for a Working Group charter require scope and success criteria, duration, deliverables and expected milestone dates where available. The qualification is decisive. The public record does not support an allegation that SVG AAM’s missing date is itself a breach of process.

That restraint should be preserved. Standards work depends on volunteer capacity, implementer priorities, technical dependencies and discoveries that can make a forecast misleading. A date adopted only to satisfy an appearance of control can encourage superficial completion, hide uncertainty or age into another unexplained missed promise.

But “date unavailable” and “milestone unavailable” are different propositions. A group can be unable to predict when two independent implementations will pass a feature set while still documenting which revision controls, how features are inventoried, what suite is used, what evidence exists today and when the question will next be reviewed. If even the review date cannot be fixed, it can record why and name the event that will trigger reconsideration.

This is why the remedy should not be “put a deadline in the charter.” A deadline would smuggle false precision into a technical programme. The more useful requirement is a receipt for the current evidence state, including an explicit reason whenever a date is unavailable.

Publication, coverage and interoperability are separate gates

Lu Heng’s Running-Code Primacy supplies a narrow discipline for reading this record: publication, recommendation, implementation, validation and actual use should remain distinguishable. It is a governance lens, not evidence about what the SVG or ARIA groups have done.

Applied here, the lens prevents two equal and opposite errors. The first is to dismiss the 2026 Working Draft because it is not yet proven in running systems. Publication freezes a reviewable technical claim and can coordinate implementation; that is valuable. The second is to let the new publication stand in for evidence that its mappings work consistently across independent accessibility stacks. A document does not execute itself.

The same separation is needed inside testing. A test’s existence proves that an assertion has been encoded. A feature-to-test mapping shows intended coverage. A recorded run shows how a particular implementation behaved in a stated environment. Independent comparable runs can support an interoperability claim. An implementation report aggregates that evidence for a maturity decision. Collapsing those steps allows the most visible artifact—the new Working Draft—to carry more authority than it has earned.

For SVG AAM the environments are particularly consequential. The specification maps SVG semantics into accessibility APIs. Evidence can involve a browser engine, operating-system accessibility layer and assistive technology, each with versions and configuration. A pass in one combination is not automatically a pass in another. This article does not claim which combinations are required or which currently work. It argues only that the milestone must identify the combinations on which a public conclusion relies.

Two groups appear in the record; that makes custody a field

The current record does not fit neatly inside one organisational label. The ARIA Working Group publications page lists the 27 August SVG AAM draft and names ARIA as the delivering group. The proposed SVG charter says the specification will be developed in collaboration with ARIA. In 2024, a repository commit moved specification work into the ARIA monorepo while leaving the earlier repository open for issue tracking and preserving its Editor’s Draft address. The current ARIA repository directory makes that editorial custody visible.

None of this proves a contested transfer of authority, and there is no need to manufacture one. Collaboration and repository custody are normal. But they make ownership fields more important. A person looking only at the SVG charter, only at the ARIA publications page or only at the old issue repository may form three different impressions of where to report a defect, propose a test or ask for a result.

A testing milestone should therefore name the responsible group or owner for each next action. One group may own charter delivery, another editorial changes, a joint task force test review, and implementers their result submissions. The receipt need not flatten those roles. It should make them navigable.

A ten-field receipt is enough

The missing instrument can remain thin. It need not become a new database, dashboard or approval committee. A versioned page or issue, linked from the deliverable row, could carry ten fields.

First, identify the controlling specification URL and immutable revision. A dated /TR publication is useful, but tests may target a later Editor’s Draft commit. The receipt should say which one governs the result.

Second, identify the normative feature inventory and its version. Without a finite inventory, a rising test count has no denominator.

Third, name the test-suite repository and controlling commit. A mutable default branch cannot reproduce an earlier claim unless its revision is recorded.

Fourth, publish the feature-to-test mapping and coverage state. The mapping should distinguish covered, partially covered, untested, excluded and blocked features rather than compress them into a percentage.

Fifth, record implementation identities, versions and relevant environments. “Two implementations” is not meaningful if the two results share the same engine or if the accessibility path differs in an unreported way.

Sixth, state the interoperability result and link reproducible evidence. This can be incomplete. An honest partial result is more useful than an unqualified progress label.

Seventh, list known exclusions, failures and unresolved issues. A milestone becomes misleading when only passing surfaces are counted.

Eighth, attach each next action to a responsible group or named owner. Responsibility can be distributed without becoming invisible.

Ninth, give a dated review point or an explicit reason that a date is unavailable, together with the event that will cause review. This preserves the Process qualification rather than evading it.

Tenth, name the maturity or publication decision the evidence may support. Tests gathered for an Editor’s Draft review, Candidate Recommendation transition or implementation report answer different questions.

The receipt should be append-only in the ordinary evidentiary sense: later states supersede earlier ones without deleting them. A failed test can become a pass; a feature can be removed; an implementation can withdraw. Keeping the sequence makes the decision intelligible and prevents a current green summary from erasing how it was achieved.

The 2026 draft deserves credit without borrowing tomorrow’s proof

Standards governance often fails through overstatement in both directions. A long publication gap becomes a story of abandonment even when work exists. A fresh draft becomes a story of completion even when implementation evidence remains open. SVG AAM now invites both errors because its publication record changed dramatically while its charter milestone changed only grammatically.

The fair reading is more precise. The 27 August draft is a meaningful public artifact. It replaces an eight-year-old review snapshot and exposes technical changes to scrutiny. The refinement patch is also a response: “undetermined” no longer stands alone. Testing is named as the intended direction.

Yet the phrase records aspiration, not attainment. It cannot tell an implementer which tests matter today, an accessibility specialist which platform combinations were observed, a charter reviewer what remains blocked, or a Member what evidence would support the next maturity step. Those questions do not require a guarantee of completion. They require a shared evidence address.

Publishing that address would not create a new veto over SVG AAM. It would not let a commentator command the group’s schedule. It would not convert incomplete tests into a failure judgment. It would simply stop publication, testing, coverage, implementation and maturity from occupying the same ambiguous status word.

The gap after 3,031 days has now closed at the publication layer. The next useful number is not another interval between documents. It is the versioned count of normative features whose test and independent implementation evidence can be inspected—and the explicit list of those that cannot yet be claimed.

Sources

  1. SVG AAM directory in the ARIA repository
  2. Proposed SVG Working Group charter at incorporation commit 806338
  3. Commit 806338: incorporate refinement suggestions
  4. W3C Strategy issue 559
  5. Public refinement comment requesting a testing milestone
  6. Team contact’s refinement-closure comment
  7. Commit moving SVG AAM work to the ARIA monorepo
  8. Lu Heng, Running-Code Primacy
  9. Active 2024 SVG Working Group charter
  10. ARIA Working Group publications
  11. W3C Process: Working Group and Interest Group charters
  12. W3C Process: implementation experience
  13. SVG Accessibility API Mappings Working Draft, 10 May 2018
  14. SVG Accessibility API Mappings Working Draft, 27 August 2026