Resumo

  • O W3C publicou em 27 de agosto de 2026 um novo Working Draft de SVG Accessibility API Mappings. O próprio documento aponta 10 de maio de 2018 como a publicação anterior: um intervalo de 3.031 dias, agora acompanhado por alterações técnicas substanciais.
  • Durante o refinamento público da próxima carta do SVG Working Group, um comentário de 4 de julho pediu um marco concreto e um compromisso com testes. A alteração incorporada substituiu “indeterminado” por “com o objetivo de avançar nos testes”.
  • A frase sinaliza prioridade, mas não identifica revisão controladora, inventário de recursos, commit da suíte, cobertura, implementações independentes, responsável nem ponto de revisão. Portanto, não permite verificar a conclusão do marco.
  • A carta proposta já contém bons critérios gerais: testes abertos, planejamento precoce e duas implementações independentes e interoperáveis antes de ultrapassar Candidate Recommendation. Falta vinculá-los ao caso de SVG AAM.
  • O W3C Process exige datas previstas de marcos apenas “quando disponíveis”. A ausência de uma data não prova violação, abandono ou má-fé.
  • Um registro enxuto e versionado do marco de testes separaria publicação, cobertura, experiência de implementação e decisão de maturidade sem criar uma nova instância de aprovação.

Uma lacuna de publicação foi fechada

O intervalo de 3.031 dias pede precisão. Ele mede o tempo entre duas publicações datadas, não a totalidade do trabalho feito nesse período. Um snapshot em /TR pode permanecer antigo enquanto rascunhos editoriais e repositórios continuam mudando.

A carta SVG vigente, de 2024, começou em 27 de junho de 2024 e termina em 30 de setembro de 2026. Ela lista SVG Accessibility API Mappings como Working Draft adotado em 10 de maio de 2018 e classifica a conclusão esperada como indeterminada. A linha comprova o estado da carta, mas não autoriza dizer que nenhuma atividade ocorreu desde 2018.

A próxima carta passou por refinamento no issue 559 da estratégia do W3C. Em 4 de julho, um comentário público relacionou o rascunho de 2018 ao término indeterminado e pediu um marco concreto e um compromisso com testes. Em 18 de agosto, o contato da equipe informou que o refinamento havia terminado e que sugestões tinham sido incorporadas.

O commit 806338 preserva exatamente o que mudou. Foram três linhas: a correção de um link, a ampliação do texto sobre coordenação com o WHATWG e a troca, em SVG AAM, de “undetermined” por “aiming at progressing on testing”. A carta congelada nesse commit ainda indicava a edição de 2018 como rascunho adotado.

Em 27 de agosto surgiu o novo Working Draft. O texto identifica como anterior o Working Draft de 10 de maio de 2018. A diferença entre as datas é de 3.031 dias.

A publicação é um avanço concreto. A edição nova enumera mudanças no cálculo de nomes acessíveis, nos papéis de SVG, no mapeamento de elementos e atributos e no tratamento de conteúdo oculto ou apenas apresentacional. Revisores e implementadores voltam a ter um ponto fixo comum.

O status do documento, porém, diz que um Working Draft não representa endosso do W3C nem de seus membros e pode ser atualizado, substituído ou se tornar obsoleto. O novo texto demonstra que existe uma revisão pública para exame. Não demonstra, por si só, cobertura de testes, interoperabilidade entre produtos independentes nem prontidão para um estágio superior.

É possível reconhecer o valor da publicação e manter aberta a questão probatória. A primeira lacuna foi fechada; a segunda exige instrumentos diferentes.

A intenção não informa quando o trabalho pode ser aceito

“Avançar nos testes” não é uma frase vazia. Ela torna pública uma prioridade e evita prometer uma data talvez insustentável diante de recursos voluntários, escolhas de fornecedores e dependências entre grupos.

Um marco, entretanto, precisa de condição de encerramento. Qual revisão está sob teste? Quais recursos normativos compõem o universo? Qual commit da suíte produziu o resultado? Que parcela está coberta? Quais implementações são independentes? Que evidência autoriza qual decisão? A linha da carta não responde.

O verbo testar esconde etapas distintas. Abrir um repositório é preparar infraestrutura. Adicionar uma asserção é uma contribuição. Aprovar um plano de testes é uma decisão de trabalho. Associar exigências normativas a casos cria um mapa de cobertura. Executar a suíte em um ambiente produz evidência sobre uma implementação. Obter resultados comparáveis em duas pilhas independentes pode sustentar interoperabilidade. Reunir tudo em relatório permite deliberar sobre maturidade.

Cada etapa conta, mas nenhuma substitui a seguinte. Cem testes novos podem se concentrar numa única função já coberta. Uma matriz ampla pode depender de um só motor. Dois produtos podem aparentar sucesso sem resultado reproduzível se versões, camada de acessibilidade do sistema e tecnologia assistiva não estiverem registradas.

O problema não é falta de movimento. É que a palavra “progresso” não determina qual movimento encerra a avaliação.

Os critérios gerais já apontam o caminho correto

A carta proposta não deixa testes para depois. Ela menciona uma suíte de testes e um relatório de implementação entre os produtos do grupo. Seus critérios gerais de êxito pedem testes públicos para todos os recursos, incentivam planejamento desde os primeiros rascunhos e exigem ao menos duas implementações independentes e interoperáveis de cada recurso antes de uma especificação avançar além de Candidate Recommendation.

Essas disposições são contraprova importante contra qualquer narrativa de abandono dos testes. Elas também combinam com a seção do W3C Process sobre experiência de implementação. O Process não reduz a avaliação a uma porcentagem. Considera implementação de recursos, interoperabilidade, independência dos implementadores, uso além do experimental, camadas do ecossistema cobertas e problemas relatados. Também observa que planejar testes cedo costuma ser mais eficaz.

O que falta é materializar o critério. “Todos os recursos” requer um inventário versionado de SVG AAM para servir de denominador. “Duas implementações” requer nomes, versões, ambientes e uma justificativa de independência. “Suíte aberta” requer um commit fixo se o resultado histórico tiver de ser reproduzido.

Não é preciso redigir uma ambição nova. É preciso criar, na linha do entregável, um caminho direto até as provas atuais e as lacunas reconhecidas.

“Quando disponíveis” impede precisão de fachada

As regras do W3C Process para cartas de grupos exigem escopo, critérios de sucesso, duração, entregáveis e datas esperadas de marcos quando disponíveis. A ressalva faz parte da regra. O material analisado não sustenta a acusação de que faltar uma data para SVG AAM seja, por si só, descumprimento do processo.

Há motivo técnico para essa flexibilidade. Um teste pode revelar texto normativo defeituoso. Um implementador pode mudar prioridades. A coordenação pode depender de contribuidores que não controlam o calendário. Uma data criada para preencher o formulário pode incentivar redução artificial do escopo ou uma declaração prematura de sucesso.

Não conhecer a chegada não impede registrar a posição atual. É possível declarar a revisão de referência, a versão do inventário, o commit de testes, os resultados existentes e os ausentes. Se nem uma data de revisão puder ser marcada, o registro pode explicar a razão e nomear o evento que reabrirá a análise — uma nova publicação, o resultado de uma implementação ou a solução de uma questão normativa.

A resposta, portanto, não é impor prazo. É impedir que uma incerteza legítima se torne um estado sem endereço probatório.

Documento, cobertura e execução ocupam camadas diferentes

O texto de Lu Heng sobre a primazia do código em funcionamento oferece aqui uma lente de governança, não fatos sobre SVG ou ARIA: publicação, recomendação, implementação, validação e uso devem continuar distinguíveis.

Essa disciplina evita dois excessos. Seria injusto minimizar o Working Draft de 2026 por ainda não ser um relatório de interoperabilidade; uma publicação fixa texto, organiza revisão e orienta implementação. Também seria incorreto fazer o documento valer como prova de comportamento em produtos. Um rascunho não executa a si mesmo.

Dentro dos testes, a existência de um caso prova que uma asserção foi codificada. Sua ligação a um requisito mostra cobertura pretendida. Uma execução registra o comportamento de uma implementação em ambiente declarado. Execuções independentes e comparáveis podem apoiar uma conclusão de interoperabilidade. O relatório então relaciona o conjunto à decisão de maturidade.

Em SVG AAM, o trajeto observado pode incluir o motor do navegador, a camada de acessibilidade do sistema operacional e uma tecnologia assistiva. Versões e configurações importam. Este artigo não define quais combinações são obrigatórias nem afirma que alguma falhe. Ele exige apenas que qualquer conclusão pública identifique as combinações que lhe dão suporte.

SVG e ARIA dividem uma custódia visível

O registro aparece em mais de um lugar institucional. A página de publicações do ARIA Working Group inclui o rascunho de 27 de agosto e apresenta ARIA como grupo responsável pela entrega. A carta SVG proposta prevê desenvolvimento em colaboração com ARIA. Em 2024, um commit no repositório anterior moveu o trabalho de especificação ao monorepo de ARIA, manteve o repositório antigo para issues e preservou o endereço do Editor’s Draft. O diretório atual de SVG AAM em ARIA mostra a localização editorial.

Nada disso demonstra disputa ou transferência imprópria de autoridade. Colaboração e mudança de repositório são normais. A consequência é operacional: o registro do marco deve nomear o grupo ou responsável por cada próxima ação. Supervisão da carta, edição, revisão de testes e entrega de resultados podem continuar distribuídas; não podem ficar impossíveis de localizar.

Um recibo de dez campos resolve a ligação

Não é necessário criar um comitê ou painel complexo. Uma página ou issue versionado, ligado à linha do entregável, pode cumprir a função.

O registro deve trazer URL e revisão imutável da especificação controladora; inventário normativo e sua versão; repositório e commit da suíte; mapa entre recursos e testes, distinguindo cobertura completa, parcial, ausente, excluída e bloqueada.

Deve ainda identificar implementações, versões e ambientes; ligar resultados interoperáveis reproduzíveis; manter falhas, exclusões e questões abertas; atribuir cada próxima ação a grupo ou pessoa; dar uma data de revisão ou razão explícita para sua indisponibilidade e o evento que provocará nova análise; e nomear a decisão editorial ou de maturidade que as provas podem sustentar.

Cada versão posterior deve preservar a anterior. Falhas viram aprovações, recursos podem sair, implementações podem ser retiradas. Sem sequência, um resumo verde de hoje apaga as condições de uma decisão de ontem.

O Working Draft de 27 de agosto merece crédito integral como retorno substancial ao registro de publicação. Não precisa tomar emprestada a prova de interoperabilidade futura. O marco de testes também não precisa fingir uma data. Precisa apenas mostrar, de modo durável, o que foi verificado, o que falta e qual decisão aguarda essas evidências.

Fontes

  1. Diretório de SVG AAM no repositório ARIA
  2. Carta SVG proposta no commit 806338
  3. Commit 806338 de incorporação das sugestões
  4. Issue 559 da estratégia do W3C
  5. Comentário que pede um marco de testes
  6. Comentário que encerra o refinamento
  7. Commit que moveu SVG AAM para o monorepo de ARIA
  8. Lu Heng, Running-Code Primacy
  9. Carta SVG vigente de 2024
  10. Publicações do ARIA Working Group
  11. W3C Process: cartas de grupos
  12. W3C Process: experiência de implementação
  13. SVG Accessibility API Mappings Working Draft de 10 de maio de 2018
  14. SVG Accessibility API Mappings Working Draft de 27 de agosto de 2026