Resumo

  • Em 18 de agosto de 2026, o W3C abriu até 18 de setembro a revisão de um novo estatuto do BTT e prorrogou o estatuto vigente até 23 de outubro.
  • O texto atual inclui o AT Driver como especificação normativa; a proposta sucessora o retira e diz que a ARIA poderá adotá-lo quando renovar seu estatuto.
  • O estatuto vigente da ARIA vai até 1º de janeiro de 2027, mas não lista o AT Driver entre suas entregas normativas.
  • A issue 2826 da ARIA permanece aberta. A ata de julho descreve passos para uma possível recepção, não uma decisão concluída.
  • O Editor's Draft de 26 de agosto ainda identifica o BTT como grupo publicador. A edição pode continuar sem converter o texto em entrega da ARIA.
  • Um dossiê versionado deve ligar estatuto de saída, estatuto de entrada, versão da especificação, autoridade decisória, participação e contexto de patentes.

O presente e o futuro aparecem em documentos diferentes

O AT Driver define um protocolo para inspecionar e controlar remotamente softwares de tecnologia assistiva. Um sistema de testes pode iniciar uma sessão com um leitor de tela, alterar configurações, enviar ações e receber a saída falada. O desenho reaproveita conceitos do WebDriver BiDi, mas seu alcance não se limita ao navegador.

Foi essa natureza híbrida que levou o W3C a colocar o AT Driver no estatuto do Browser Testing and Tools em 2024. O estatuto ainda válido o apresenta ao lado de WebDriver e WebDriver BiDi como especificação normativa. Em 18 de agosto, o W3C estendeu esse mandato até 23 de outubro, enquanto o texto seguinte passa por revisão.

A proposta sucessora já fala de outro estado. Sua lista normativa guarda apenas WebDriver e WebDriver BiDi. O histórico registra expressamente que a entrega AT Driver foi retirada. Na coordenação com a ARIA, diz que a especificação “costumava” estar no escopo do BTT e poderá ser adotada pela ARIA quando esse grupo renovar o estatuto.

Os verbos não devem ser misturados. O estatuto atual define a autoridade de hoje. A proposta define o que valerá se for aprovada. O encerramento da consulta em 18 de setembro não produz automaticamente essa aprovação.

A ARIA faz sentido como casa técnica

A discussão de 8 de julho entre editores da ARIA explica o raciocínio. O AT Driver nasce de ideias do WebDriver BiDi e precisa de interlocução com navegadores. Ao mesmo tempo, controla leitores de tela e outras tecnologias assistivas, algumas delas fora do navegador. A experiência relevante está dividida entre fornecedores diferentes.

Segundo a ata, uma implementação feita diretamente por um fornecedor de tecnologia assistiva veio de uma empresa presente na ARIA, mas não no BTT. Os participantes também observaram que os testes de interoperabilidade da ARIA não ganham escala sem automação da camada assistiva. A capacidade de capturar fala, mudar modo e executar intenção do usuário pertence ao problema central, não à periferia.

Ainda assim, adequação não é mandato. O estatuto atual da ARIA abrange uma carteira extensa de WAI-ARIA e mapeamentos para APIs de acessibilidade, além de cooperação com ARIA-AT, mas não contém o AT Driver. A issue 2826, aberta em junho, continua como Open e In Progress, sem branch ou pull request vinculados em sua página pública.

A ata prevê conversa entre chairs e equipe do W3C, depois um possível rascunho de estatuto, análise dentro da ARIA e revisão pelo Advisory Committee. Também registra que uma entrega conjunta foi sugerida, mas não era uma opção. Esse roteiro conserva a liberdade institucional de aceitar, ajustar ou rejeitar.

A continuidade editorial não é adoção

O grupo perguntou o que ocorreria caso o BTT retirasse o AT Driver antes de a ARIA estar pronta. A resposta não foi paralisar. A especificação ainda era um Editor's Draft, nem sequer uma Working Draft. O trabalho poderia seguir. Se o caminho pela ARIA não prosperasse, o Community Group poderia produzir um relatório comunitário e tentar de novo mais tarde.

O limite apareceu na referência normativa. A ata afirma que o lado do Community Group ainda não poderia ser usado para a referência normativa em questão; seria preciso aguardar a aprovação de um Working Group. Alterar um rascunho, publicar um Community Group Report e aceitar uma entrega na Recommendation Track são atos diferentes.

O documento de 26 de agosto confirma o estado atual. Ele ainda se apresenta como publicado pelo BTT e direciona comentários à lista do BTT. Também esclarece que um Editor's Draft não implica endosso do W3C ou de seus membros. Como o mandato BTT vigente ainda inclui o AT Driver, isso é coerente. Não é recibo de transferência para a ARIA.

O perímetro de patentes acompanha o grupo

As orientações do próprio W3C dizem que o escopo do estatuto demarca o trabalho permitido e os compromissos de patentes. O guia de transição exige a renovação do estatuto quando o trabalho recebido está fora do escopo do grupo existente. O estatuto receptor deve nomear a entrega transferida e sua relação com o Community Group.

Nada disso demonstra um vazio de licenciamento. A Patent Policy vincula obrigações ao trabalho do grupo específico do qual alguém participa. Compromissos já efetivos não desaparecem por uma simples mudança de participação; existem regras de persistência para versões posteriores substancialmente semelhantes. As fontes não registram infração, exclusão ou falha de compromisso.

A pergunta operacional é para o futuro: qual grupo aprovará mudanças, quem participará do novo mandato, que versão da política regerá novas adesões e como contribuições externas serão cobertas? Commits não respondem sozinhos.

Um dossiê de transferência com os dois lados

O W3C pode manter o ritmo técnico e publicar um registro curto, versionado, da mudança institucional.

No lado de saída, o registro deve conter o estatuto BTT efetivamente válido, a data final e o snapshot exato do AT Driver sob essa autoridade. No lado de entrada, deve ligar o futuro rascunho ARIA, a decisão interna, a revisão consultiva, a aprovação ou recusa e a Call for Participation. Entre os dois, deve nomear o custodiante do repositório e quem pode tomar cada classe de decisão.

As classes precisam ser explícitas: edição de Editor's Draft, Community Group Report, resolução de Working Group, First Public Working Draft ou outra transição formal. Cada evento deve ter data, objeções, estado substituído e situação da referência normativa.

Um mapa enxuto pode informar a versão da Patent Policy e os caminhos de compromisso para participantes e não participantes, sem expor aconselhamento jurídico confidencial. Outro quadro deve mostrar se implementadores de navegador, fornecedores de leitores de tela, editores e líderes de testes estão no corpo que decide.

A distinção de Heng Lu ajuda: participar de um repositório não equivale a receber mandato. O dossiê mostra a regra pela qual contribuição se converte em decisão institucional válida.

A revisão ainda pode exigir a ligação

A proposta BTT usa o verbo correto: a ARIA “poderá” adotar. Os revisores podem aceitar a direção técnica e, mesmo assim, pedir que a saída aponte para o estado do estatuto receptor, defina autoridade no intervalo e marque a próxima verificação pública.

Isso não força a ARIA. Pelo contrário, impede que o investimento técnico seja confundido com consentimento antes da análise de escopo, carga, participação e política de patentes. Também preserva com clareza a autoridade atual do BTT.

Uma especificação não fica abandonada só porque seu próximo estatuto está incompleto. E uma transferência não termina só porque o destino parece provável.

Fontes

  1. Anúncio da revisão do estatuto BTT
  2. Proposta do estatuto BTT
  3. Estatuto BTT vigente
  4. Issue 2826 da ARIA
  5. Ata dos editores da ARIA, 8 de julho de 2026
  6. Estatuto vigente da ARIA
  7. Histórico de estatutos da ARIA
  8. Editor's Draft do AT Driver
  9. Guia do W3C para transição de Community Group a Working Group
  10. Patent Policy do W3C de 15 de maio de 2025
  11. Perguntas frequentes sobre a Patent Policy
  12. Heng Lu, The Multi-Stakeholder Mirage