Resumo

  • Em 26 de agosto de 2026, o W3C abriu a issue 570 no Strategy Funnel para renovar a carta do Audio Working Group. O texto chama a possível adoção da Web Speech API de mudança substancial, mas informa que o refinamento ainda ocorre dentro do grupo, não está pronto para revisão horizontal e não tem data prevista de conclusão.
  • Uma conversa pública propõe conservar reconhecimento e síntese numa só especificação, publicar um First Public Working Draft no início de 2027 e buscar Candidate Recommendation em 2028. Apoio em comentários não é decisão do grupo.
  • A minuta pública continua excluindo reconhecimento e síntese de fala do escopo direto. Web Audio API 1.1 e Web MIDI API são os únicos entregáveis normativos listados.
  • A Web Speech está ativa e traz data de 10 de agosto, porém se identifica como Draft Community Group Report. Edição, testes e implementação não criam sozinhos um W3C Working Draft.
  • Um dossiê de transferência de escopo deve ligar a versão exata, o texto da carta, as revisões, a decisão do W3C, a adoção pelo Working Group, o FPWD e o estado dos compromissos de patentes.

A mudança foi anunciada antes de chegar ao texto

A sequência começa em 26 de agosto. A nova ficha no Strategy Funnel trata a incorporação da Web Speech API como uma alteração substantiva no mandato do Audio Working Group. A própria ficha evita antecipar o resultado: a proposta permanece sob análise do grupo, ainda não foi encaminhada às revisões horizontais e não há uma previsão para encerrar o refinement.

No repositório do Web Audio, outra issue lembra que a carta vigente termina em 8 de novembro. No dia 27, um participante sugeriu receber a Web Speech como uma especificação unificada de reconhecimento e síntese, manter a continuidade dos editores e apontar para FPWD no começo de 2027 e CR em 2028. Em 30 de agosto, outro participante do W3C concordou com a ampliação, embora tenha observado que estimativas de marcos raramente são precisas.

Essas manifestações dão forma ao plano. Elas não registram consenso do Working Group, revisão do Advisory Committee ou decisão do W3C. Uma contribuição pode iniciar e aperfeiçoar o pedido; não confere a competência que o pedido procura obter.

A minuta disponível preserva o arranjo anterior. O escopo cobre processamento de áudio PCM, acesso a dispositivos, informações de capacidade e cache e acesso a equipamentos MIDI. Na seção “Out of Scope”, afirma que funcionalidades específicas de reconhecimento e síntese de fala não serão tratadas diretamente. A lista normativa contém somente Web Audio API 1.1 e Web MIDI API. A Web Speech não aparece.

Há ainda marcas de elaboração: uma nota manda regenerar os entregáveis depois de uma Working Draft atualizada do Web Audio, e os campos de conclusão esperada mantêm marcadores de ano. Portanto, a exclusão atual não deve virar manchete de rejeição definitiva. Mas, enquanto ela continuar, também não se pode relatar a possível adoção como autoridade já concedida.

Trabalho técnico vivo e autoridade limitada podem coexistir

A Web Speech API não é um arquivo abandonado. O relatório de edição foi atualizado em 10 de agosto de 2026, identifica editor, issues públicas e testes em desenvolvimento. Define APIs de reconhecimento e síntese e aborda processamento local, pacotes de idiomas, permissões, indicação de gravação e privacidade.

O rótulo de status, contudo, permanece Draft Community Group Report. A página do Speech API Community Group informa que o grupo fechou em 27 de março de 2023 e ressalta que Community Groups são propostos e conduzidos pela comunidade, sem necessariamente representar os Membros ou a equipe do W3C. Outra página guarda os compromissos assumidos no Community Final Specification Agreement.

Não há contradição entre fechamento do grupo e manutenção do documento. Editores podem continuar o trabalho, navegadores podem oferecer recursos relacionados e testes podem avançar. Isso fornece experiência técnica, mas não substitui uma carta aprovada nem uma decisão do Working Group de adotar o texto.

Também não seria correto usar o rótulo Community Group para reduzir a relevância da especificação. Ele situa sua origem e o regime institucional atual. A notícia precisa preservar os dois fatos: o trabalho é ativo e seu estágio formal ainda é limitado.

Debate, carta e publicação são atos diferentes

O Process Document exige que uma carta declare missão, escopo, duração, entregáveis, critérios de êxito e marcos esperados quando disponíveis. Uma mudança substancial passa por revisão do Advisory Committee e decisão do W3C. A revisão dura pelo menos 28 dias e pode ser estendida para no mínimo 60 mediante solicitação. O Call for Review deve destacar mudanças importantes, justificá-las e mostrar como os comentários do refinement foram tratados.

Essa sequência dá à discussão pública a função correta. Participantes propõem; Chairs e Charter Facilitator convertem a ideia em texto verificável; grupos horizontais examinam acessibilidade, internacionalização, privacidade, segurança e arquitetura; representantes dos Membros avaliam uma versão determinada; o W3C decide.

Mesmo uma carta aprovada com Web Speech apenas autorizaria o trabalho. O grupo ainda precisaria decidir qual documento adotar e quando pedir publicação. Um FPWD é uma base pública para desenvolvimento; não implica consenso completo nem endosso do W3C. A Candidate Recommendation exige revisão e experiência de implementação posteriores.

As datas de 2027 e 2028 devem, por isso, conservar o rótulo de proposta. Uma separação entre reconhecimento e síntese, novas dependências reveladas pelas revisões ou atraso da carta podem alterar o calendário. A atualização do prazo não deve apagar o teor da proposta original.

Há dois históricos de compromissos, não um só

A mudança de lar institucional afeta o contexto de patentes. A página pública da Web Speech registra compromissos sob o Community Final Specification Agreement. Um futuro Audio Working Group funcionaria sob a Patent Policy de 15 de maio de 2025, que define obrigações de licenciamento para participantes e abre, com o FPWD, uma oportunidade de exclusão de 150 dias conforme suas regras.

Os históricos se relacionam, mas não se substituem automaticamente. A trajetória do Community Group acompanha a procedência do documento. Escopo da nova carta, participação no Working Group, versão adotada e período associado ao FPWD formam outro registro.

Nenhuma fonte examinada aponta reivindicação, exclusão planejada ou disputa de patente. Este artigo não presume nenhuma e não presta aconselhamento jurídico. A exigência é de custódia: indicar qual instrumento vale em cada etapa, sobre qual texto e para qual participante.

Como a especificação continua mudando, a revisão formal também precisa de uma versão fixa. “Web Speech API” não basta como identidade. É necessário indicar a imagem exata do documento, se reconhecimento e síntese continuam juntos e como os compromissos anteriores e o novo estado serão preservados.

Publicar um dossiê de transferência de escopo

O primeiro registro deve identificar o Draft Community Group Report, data, versão imutável, origem e página de compromissos. O segundo deve registrar a proposta: responsável, data, grupo receptor, razão e unidade do entregável.

A entrada da carta deve apontar para a primeira versão que realmente inclua Web Speech, mantendo a exclusão anterior no histórico. Pedidos de revisão horizontal, questões materiais e respostas públicas devem se ligar a esse texto. Período do Advisory Committee, eventual extensão e decisão do W3C são eventos separados.

Depois da entrada em vigor, ainda deve constar a decisão do Working Group de adotar o documento. A publicação do FPWD e sua janela na Patent Policy são um novo estado. Working Drafts posteriores, CR e Recommendation precisam de suas próprias evidências. Divisão, retirada, volta à incubação ou mudança de grupo receptor continuam sendo resultados válidos.

O dossiê não precisa abrir comentários confidenciais dos Membros, análises jurídicas privadas ou material de patente não público. Basta mostrar qual texto cada instância avaliou, quem possuía autoridade e quando o estado mudou.

O Policy Mirror de Heng Lu oferece aqui uma regra estreita: a carta pública deve refletir o trabalho autorizado, e a etiqueta de maturidade deve refletir a decisão alcançada. Manutenção, participação e implementação geram evidência, não título sobre a autoridade. O nome contextual IETF-W3C do diretório tampouco dá ao IETF qualquer poder nesta decisão do W3C.

Fontes

  1. Heng Lu, The Policy Mirror
  2. Issue 570 do W3C Strategy Funnel
  3. Minuta da carta Audio 2026
  4. Discussão de renovação do Audio Working Group
  5. Carta vigente do Audio Working Group
  6. Relatório de edição da Web Speech API
  7. Registro do Speech API Community Group
  8. W3C Process Document
  9. W3C Patent Policy
  10. Compromissos Community Final Specification Agreement da Web Speech