Summary

  • On 18 August 2026 W3C opened review of a proposed Browser Testing and Tools charter through 18 September and extended the active charter through 23 October.
  • The active charter lists AT Driver as a normative deliverable. The proposed successor explicitly drops it and says ARIA may adopt it when that group recharters.
  • ARIA's current charter runs to 1 January 2027 but does not list AT Driver. Issue 2826 remains open and asks the group to consider taking it on.
  • ARIA Editors recorded that the Editor's Draft can continue during the interval and that a Community Group report is a possible fallback. They also recorded that Working Group approval is needed before the relevant normative-reference move.
  • The 26 August AT Driver Editor's Draft still identifies BTT as its publishing group. That matches the active charter; it does not complete the future transfer.
  • A versioned transfer docket should join the outgoing charter, incoming charter, specification snapshot, decision authority, participation and patent-policy context without prejudging ARIA's decision.

One charter says “still here”; the next says “used to be”

AT Driver is a protocol for introspection and remote control of assistive-technology software. Its practical target includes screen readers: a test system can change settings, issue user actions and observe captured output through a bidirectional channel. The draft deliberately reuses concepts from WebDriver BiDi, but the controlled system is assistive technology rather than simply a browser.

That mixed inheritance explains its institutional journey. W3C added AT Driver to the Browser Testing and Tools Working Group's charter in 2024. The active charter still lists it beside WebDriver and WebDriver BiDi as a normative specification. On 18 August W3C extended that charter through 23 October while the next charter goes through review.

The proposed successor has only WebDriver and WebDriver BiDi in its normative-deliverable list. Its history table says plainly that AT Driver is dropped. Its coordination section then describes the specification as work that “used to be in scope” of BTT and that ARIA may adopt when it recharters.

Those verb tenses belong to different institutional states. “Used to be” describes the proposed future charter. “Still is” describes the active charter. The proposal is public for review through 18 September; it is not yet the mandate under which the group operates.

ARIA is the plausible destination, not yet the authorized one

The receiving logic is substantial. In a July ARIA Editors discussion, participants said AT Driver sits between browser and assistive-technology vendors. Its design draws from WebDriver BiDi, which made BTT review valuable. But an implementation by an assistive-technology vendor came from a company represented in ARIA rather than BTT. Participants also argued that ARIA interoperability testing cannot scale without automating the assistive-technology layer.

AT Driver is broader than the browser. A screen reader can run as a standalone application, and the protocol is written so it could apply outside a web page. That makes ARIA's accessibility expertise and vendor participation an understandable institutional home.

Plausibility is not adoption. ARIA's active charter runs through 1 January 2027 and lists a large portfolio of ARIA and accessibility-mapping specifications, but not AT Driver. Issue 2826 remains open and marked In Progress. It asks the group to consider including the specification in a future charter; the public issue shows no linked branch or pull request.

The July minutes described the next step as discussion among chairs and W3C staff, followed by a possible ARIA charter draft, first inside ARIA and then before the Advisory Committee. A joint deliverable had been suggested, the minutes say, but was not an option. None of that should be converted into a completed decision.

Work can continue while authority waits

The meeting directly considered the awkward interval: what happens if BTT removes AT Driver before ARIA's charter is ready? The answer was not that the specification must stop. AT Driver was still an Editor's Draft, not even a Working Draft. Participants said it could keep moving. If the ARIA route failed, the Community Group could pursue a Community Group report and try again later.

The harder boundary concerned the next formal use of the work. The minutes record that the Community Group side could not yet supply the relevant normative reference and that a Working Group would have to approve the specification first. Informal references and technical development are not the same institutional act as accepting a normative deliverable on the Recommendation track.

The current document makes the timing visible. The AT Driver Editor's Draft dated 26 August still says it was published by BTT and directs feedback to BTT's public list. It also carries the usual warning: an Editor's Draft does not imply endorsement by W3C or its Members. That is not a contradiction. BTT's active charter still includes the work. It is evidence that the future-tense coordination text has not yet replaced the present-tense publishing context.

The patent boundary follows groups, not repository momentum

Charters do more than allocate a mailing list. W3C's own charter repository guidance says scope identifies the outer boundary of permitted work and patent commitments. Its transition guide says an existing Working Group must be rechartered when incoming work is outside its scope. The target charter should identify transferred deliverables and explain the relationship with any originating Community Group.

This does not establish a patent emergency. W3C's Patent Policy makes obligations specific to the work of the particular Working Group a participant joins. Commitments that have attached do not simply evaporate when a participant leaves or a charter changes; the policy contains persistence rules for substantially similar later drafts. The public record reviewed here shows no infringement claim, exclusion or failed licensing commitment.

The operational point is narrower. Future edits, publication decisions and participant commitments need an identifiable institutional home. The implementers present in BTT and the assistive-technology vendors present in ARIA are overlapping but not identical communities. Moving a repository does not, by itself, record who accepted the scope, who may decide, what patent-policy version applies to new participation or how non-participant contributors remain covered.

Publish the transfer as one joined record

W3C does not need to freeze AT Driver while every governance document catches up. It needs a thin, versioned transfer docket that lets technical continuity coexist with institutional precision.

The outgoing side should identify the active BTT charter, its effective end date and the exact AT Driver snapshot under that mandate. The incoming side should link the ARIA charter draft when one exists, its internal decision, Advisory Committee review, approval or rejection, and Call for Participation. Between them, the docket should name the repository custodian and the group authorized to make each class of decision.

Decision class matters. An Editor's Draft update, a Community Group report, a Working Group resolution and a standards-track publication are not interchangeable. The record should label which one occurred, link objections and state what it supersedes.

The same page can provide a privacy-safe commitment map: applicable patent-policy version, receiving-group participation path and any non-participant commitment mechanism, without publishing confidential legal advice. It should say whether AT Driver is only an informative reference, an adopted Working Group deliverable or a normative dependency at each dated checkpoint.

Finally, the docket should show representation. Which browser implementers, screen-reader vendors, editors and test leads are participating in the body that now owns the decision? Headcount is not legitimacy by itself, but a hidden change in the eligible decision community should not be mistaken for technical consensus.

This is Heng Lu's distinction between presence and authority in a standards setting. A person can keep contributing to a repository without the repository deciding which institution can publish the result. The transfer record makes the conversion rule visible.

The review window is where the join can be required

The proposed BTT charter already acknowledges the destination and the conditional verb: ARIA “may” adopt AT Driver. Reviewers therefore do not need to oppose the technical transfer to ask for a better record. They can require the outgoing charter disposition to link to the receiving charter state and identify who owns decisions during the gap.

That approach respects all current evidence. BTT remains authorized today. ARIA is a plausible future home. The Editor's Draft can continue. A Community Group fallback exists. Working Group approval remains a separate gate.

A standards project is not orphaned merely because its next charter is unfinished. But a handoff is not complete merely because everyone knows where the repository is likely to go.

Sources

  1. W3C proposed-charter announcement
  2. Proposed Browser Testing and Tools charter
  3. Current Browser Testing and Tools charter
  4. ARIA issue 2826
  5. ARIA Editors minutes, 8 July 2026
  6. Current ARIA Working Group charter
  7. ARIA charter history
  8. AT Driver Editor's Draft
  9. W3C guide to Community Group–Working Group transitions
  10. W3C Patent Policy, 15 May 2025
  11. W3C Patent Policy FAQ
  12. Heng Lu, The Multi-Stakeholder Mirage