Summary

  • W3C published an updated ARIA in HTML Recommendation on 11 August 2026 and linked its public implementation report.
  • The report displays “Last updated 22 March 2026.” Git history shows that its first large 2026 update landed on 20 May and that the same file changed again on 27 May.
  • The May update added a selectedcontent row showing one checker at yes, one in progress and one not yet implemented. That is not proof of a Process breach; it is proof that evidence time and artifact-revision time need separate labels.

The Recommendation points to a moving evidence file

On 11 August, W3C issued an updated Recommendation for ARIA in HTML. The specification sets author-conformance rules for using WAI-ARIA and Digital Publishing ARIA attributes on HTML elements. Its stated primary audience is not browser engines or assistive technologies themselves, but conformance checkers used by web authors.

The Recommendation's front matter links an implementation report. That report names three checkers: the W3C HTML checker, ARC Toolkit and IBM Accessibility Checker. At the top it displays two closely related statements. The first says “Last updated 22 March 2026.” The second says that, as of 22 March, the listed features had been verified against the current specification and that none was at risk because of a lack of implementations.

A reader encountering those sentences from the Recommendation can reasonably treat 22 March as the report's freshness date. The repository tells a more precise story.

Commit 89f8e75e9d35 was recorded on 20 May. GitHub attributes 311 additions and 126 deletions in the report file to that change. The diff replaces an August 2021 date with 22 March 2026, rewrites the aggregate statement about features at risk and refreshes much of the table. It also adds the row for the HTML selectedcontent element.

The file changed again on 27 May in commit 7998c77749cf. That smaller edit replaces attribute-based descriptions of two select variants with the terms “drop-down box” and “list box,” aligning the report with a related specification change. The visible last-updated date remains 22 March. As of this article's cutoff, 27 May is the latest public commit touching the report file.

There is no necessary contradiction. Evidence can be collected on one date, assembled later and then edited for alignment. An accounts ledger may close in March and be published in May. The problem is not the delay. It is using one timestamp to describe both the state of the observations and the state of the document.

One row shows why the distinction matters

The selectedcontent row is useful because its provenance is unusually visible. It describes the ARIA allowances for that element when used inside or outside the intended customized-select context. The table links a test case and one issue for each checker.

For the W3C Validator, the cell says yes. Its linked issue opened in July 2025 and closed as completed on 17 March 2026. ARC Toolkit is recorded as in progress; its linked issue remained open at the cutoff. IBM Accessibility Checker is recorded as not yet implemented; that linked issue also remained open.

Those three cells should not be turned into a verdict that W3C lacked adequate implementation experience. The W3C Process deliberately supplies no universal arithmetic rule. When assessing implementation experience, the Team may consider per-feature implementation, independence, interoperability, public deployment, implementation by people other than specification authors, evidence across the ecosystem and reports of difficulty. The table may be only one part of that judgment.

Nor is this table a browser-support matrix. ARIA in HTML says conformance checkers claiming support must implement its rules, but checkers may use their own terminology and severity levels. A yes here is not a certificate that a customized select behaves identically in browsers and assistive technologies. An open checker issue is not proof that an unreleased build lacks work.

The narrower fact remains: the row entered the public report file in May under a page date of March. Without a separate revision clock, an outside reader cannot tell from the page alone whether March means observation cutoff, editorial review, table assembly, linked-issue check or publication.

The review window crossed the two dates

The chronology is especially relevant because W3C was reviewing amendments during this interval. On 7 April, the ARIA Working Group published proposed corrections and additions, including selectedcontent and customized-select allowances. The Last Call invited comments and implementation experience through 8 June.

The major report update on 20 May and the follow-up edit on 27 May both occurred inside that public review period. The final 11 August Recommendation no longer marks the additions as proposals; it incorporates them into the substantive-change history.

W3C Process says proposed amendments may be incorporated after comments are addressed, adequate implementation experience is shown and the other requirements of Recommendation text are met. The public pages establish the review window and final publication. They do not expose enough information to reconstruct which exact report revision, evidence cutoff and feature observations supported the update request. That missing join is not evidence that the decision was wrong. It is the reason a better provenance header would be valuable.

Give the report two clocks

A useful implementation report should state at least two dates. Report revision identifies the immutable file or commit a reader is seeing and when it changed. Evidence cutoff says how current the implementation observations are. Neither date should impersonate the other.

Each result row can then add only what is necessary: the checker version or build, exact test case, observed date, result vocabulary and linked issue. The report as a whole should name the specification snapshot against which those results were evaluated. If a Last Call, update request or other transition used the report, it should point to the evidence snapshot it relied on.

Later edits should be classified. A wording correction, a test replacement and a changed implementation result are different events. All may be legitimate after an evidence cutoff, but readers should not have to mine Git diffs to learn which kind occurred.

This is a thin record, not another approval gate. It leaves the judgment of adequate implementation experience where W3C Process places it. It simply lets a later reader reproduce the temporal inputs to that judgment.

Sources