Resumen
- El nuevo Working Draft de SVG Accessibility API Mappings se publicó el 27 de agosto de 2026. El propio texto identifica el 10 de mayo de 2018 como la publicación anterior: transcurrieron 3.031 días y hubo cambios técnicos sustantivos.
- En la revisión pública de la siguiente carta del SVG Working Group, un comentario del 4 de julio pidió un hito concreto y un compromiso de pruebas. El cambio incorporado sustituyó «indeterminado» por «con el objetivo de avanzar en las pruebas».
- La nueva expresión orienta el trabajo, pero no fija qué revisión se prueba, cuál es el inventario normativo, qué commit controla la suite, qué cobertura existe, qué implementaciones son independientes, quién responde o cuándo se revisará el estado.
- La carta propuesta ya exige pruebas abiertas, planes tempranos y dos implementaciones independientes e interoperables antes de superar Candidate Recommendation. Falta aplicar esos buenos criterios generales a SVG AAM.
- El Proceso de W3C pide fechas previstas «cuando estén disponibles». No hay base para llamar incumplimiento, abandono o mala fe a la ausencia de una fecha.
- Un recibo de hito, ligero y versionado, separaría publicación, cobertura, experiencia de implementación y decisión de madurez sin añadir un nuevo órgano ni un veto.
El borrador nuevo resuelve una ausencia, no toda la incertidumbre
Hay una lectura tentadora de la cronología: un documento quedó quieto durante ocho años y por fin volvió a moverse. El registro requiere más cuidado.
La carta SVG vigente, iniciada el 27 de junio de 2024 y con término el 30 de septiembre de 2026, enumera SVG Accessibility API Mappings como Working Draft adoptado el 10 de mayo de 2018. La fecha prevista de finalización figura como indeterminada. Esa línea demuestra el estado formal de la carta, no la inexistencia de trabajo en repositorios o borradores editoriales.
La revisión de la siguiente carta se siguió en el asunto estratégico 559. El 4 de julio, un comentario público relacionó expresamente el borrador de 2018 con la finalización indeterminada y solicitó un hito concreto y un compromiso de pruebas. El 18 de agosto, el contacto del equipo comunicó que la fase de revisión había terminado y que se habían incorporado sugerencias.
El commit 806338 muestra el alcance de esa incorporación. Cambió tres líneas. Corrigió un enlace, amplió una referencia a la coordinación con WHATWG y, para SVG AAM, sustituyó «undetermined» por «aiming at progressing on testing». La carta en esa revisión inmutable todavía apuntaba al borrador de 2018.
Nueve días después apareció el Working Draft del 27 de agosto de 2026. El documento nombra como anterior al Working Draft del 10 de mayo de 2018. La diferencia exacta es de 3.031 días.
La publicación tiene peso propio. El nuevo texto registra cambios en el cálculo del nombre accesible, los roles de SVG, el mapeo de elementos y atributos y el tratamiento de contenido oculto o meramente presentacional. Quienes revisan o implementan disponen ahora de una fotografía fechada y común.
Al mismo tiempo, la sección de estado recuerda que publicar un Working Draft no equivale al respaldo de W3C ni de sus miembros. Puede ser actualizado, sustituido o quedar obsoleto. Por tanto, la publicación acredita una versión disponible para revisión. No acredita por sí sola cobertura de pruebas, interoperabilidad independiente ni preparación para un escalón superior del Proceso.
«Avanzar» no define dónde termina el avance
La nueva frase no es vacía. Coloca las pruebas en el horizonte del grupo y evita fabricar una fecha que quizá no pueda sostenerse. En un trabajo sujeto a contribuciones voluntarias, prioridades de fabricantes y coordinación entre grupos, admitir la incertidumbre es preferible a vestirla de calendario.
El problema es que una intención carece de condición de cierre. No dice qué revisión constituye la base. No enumera las funciones normativas que han de probarse. No enlaza un commit reproducible de la suite. No distingue cobertura parcial de completa. No identifica las implementaciones ni la decisión que dependerá de sus resultados.
También oculta que «hacer pruebas» puede referirse a estados muy diferentes. Abrir un repositorio es una señal de capacidad. Escribir una aserción es una unidad de trabajo. Aprobar un plan de pruebas es una decisión. Asociar todas las exigencias normativas a aserciones crea una medida de cobertura. Ejecutar la suite en una combinación concreta produce evidencia de implementación. Comparar dos pilas independientes puede sustentar una conclusión de interoperabilidad. Reunirlo en un informe permite deliberar sobre madurez.
Todos esos pasos importan. Precisamente por eso no conviene fundirlos en una palabra. Mientras el hito no diga cuál debe alcanzarse, cualquier actividad puede contarse como progreso y ninguna permite cerrar la evaluación.
La arquitectura de éxito ya está escrita
La carta propuesta es más exigente de lo que su línea de SVG AAM deja ver. Incluye una suite de pruebas y un informe de implementación entre los entregables. Sus criterios generales piden pruebas públicas para todas las funciones, planes de prueba desde borradores tempranos y al menos dos implementaciones independientes e interoperables de cada función antes de avanzar más allá de Candidate Recommendation.
Son condiciones razonables y contradicen cualquier relato de indiferencia ante las pruebas. El Proceso de W3C sobre experiencia de implementación tampoco reduce el análisis a un número. Considera si las funciones están implementadas, si existe interoperabilidad, si los implementadores son independientes, si hay despliegue más allá de lo experimental, qué capas del ecosistema están cubiertas y qué problemas se han comunicado. Añade que planificar las pruebas pronto suele ser más eficaz.
Falta instanciar ese marco. Una obligación general de tener pruebas para cada función necesita un inventario concreto para ofrecer denominador. Dos implementaciones necesitan nombres, versiones y una explicación de su independencia. Una suite pública necesita una revisión fija si va a sostener una conclusión histórica.
El recuento bruto puede engañar. Cien casos adicionales sobre el mismo comportamiento aumentan el volumen sin reparar una función sin prueba. Un mapa de cobertura amplio puede descansar sobre un solo motor. Dos productos pueden arrojar resultados que nadie reproduce si no se documentan sistema operativo, capa de accesibilidad, tecnología asistiva y configuración.
El hito no debe reemplazar los criterios de la carta. Debe convertirlos en una dirección de evidencia para este entregable.
La ausencia de fecha no es una infracción
Las reglas del Proceso para las cartas de grupo piden alcance, criterios de éxito, duración, entregables y fechas previstas de hitos cuando estén disponibles. La condición importa tanto como el sustantivo. El registro estudiado no permite afirmar que la falta de fecha para SVG AAM vulnere el Proceso.
Hay buenas razones para esa flexibilidad. La normalización puede descubrir dependencias imprevistas. Un fabricante puede cambiar prioridades. Un resultado de prueba puede revelar que la redacción normativa necesita revisión. Una fecha impuesta para parecer diligente puede conducir a recortar el trabajo, declarar éxito demasiado pronto o producir otra promesa incumplida.
Sin embargo, no conocer el día de llegada no impide marcar la posición actual. El grupo puede decir qué texto controla, cómo se versiona el inventario, qué suite se ejecutó, qué combinaciones se observaron, qué falta y qué hecho abrirá la próxima revisión. Si no puede fijarse ni siquiera una fecha de examen, el recibo puede explicar el motivo y nombrar el desencadenante.
La respuesta adecuada no es obligar a poner un plazo. Es hacer que la incertidumbre sea específica: desconocemos cuándo, pero sabemos qué evidencia falta y quién puede cambiar ese estado.
Entre el documento y el sistema hay varias puertas
La reflexión de Lu Heng sobre la primacía del código en funcionamiento sirve como lente de gobernanza, no como fuente sobre SVG. Su utilidad consiste en no mezclar publicación, recomendación, implementación, validación y uso.
Ese orden impide dos injusticias. La primera sería negar valor al borrador de 2026 porque aún no demuestra interoperabilidad. Una publicación nueva fija texto, permite crítica y coordina trabajo. La segunda sería atribuirle automáticamente resultados en productos reales. El papel no ejecuta el mapeo semántico.
En SVG AAM, el camino de la semántica puede cruzar un motor de navegador, la interfaz de accesibilidad del sistema operativo y una tecnología de apoyo. Sus versiones y configuraciones pueden alterar lo observado. Este análisis no prescribe qué matriz debe aprobarse ni afirma que una combinación falle. Exige algo más modesto: que la evidencia que sostenga una decisión nombre el entorno del que procede.
La misma disciplina separa existencia y cobertura. Una prueba demuestra que se codificó una aserción. Su vínculo con una exigencia muestra qué pretende cubrir. Una ejecución describe un comportamiento de una implementación. Dos ejecuciones independientes y comparables pueden apoyar interoperabilidad. Un informe conserva el conjunto para una decisión. El hito debe impedir que el artefacto más visible, el Working Draft, represente por comodidad todos esos estados.
SVG y ARIA comparten el expediente público
La custodia observable está distribuida. La página de publicaciones de ARIA incluye el borrador del 27 de agosto y presenta a ARIA como grupo que lo entrega. La nueva carta SVG prevé desarrollar la especificación en colaboración con ARIA. En 2024, un commit del repositorio anterior trasladó el trabajo de especificación al monorepo de ARIA, mantuvo el repositorio histórico para incidencias y preservó la URL del Editor’s Draft. El directorio actual en ARIA confirma la ubicación editorial.
No hay aquí prueba de conflicto ni de una transferencia irregular. Colaborar y mover un repositorio es habitual. La consecuencia práctica es que el recibo debe declarar quién responde de cada siguiente acción. Un grupo puede custodiar la carta, otro editar el texto, un equipo conjunto revisar pruebas y varios fabricantes remitir resultados. Distribución no debería significar desorientación.
Diez campos para un hito reproducible
La solución puede ser una página versionada enlazada desde la fila del entregable. No hace falta crear un comité ni un sistema de aprobación paralelo.
El recibo debe identificar la URL y revisión inmutable de la especificación que controla el resultado; el inventario normativo y su versión; el repositorio y commit de la suite; y el mapa de cada función hacia sus pruebas, diferenciando cobertura completa, parcial, ausente, excluida o bloqueada.
Después debe nombrar implementaciones, versiones y entornos; enlazar resultados interoperables reproducibles; conservar fallos, exclusiones y asuntos pendientes; asignar cada próxima tarea a un grupo o responsable; fijar una revisión o explicar por qué la fecha no está disponible y cuál será su desencadenante; y declarar qué decisión de publicación o madurez puede apoyar el paquete.
Cada versión nueva debería conservar la anterior. Las pruebas cambian, las funciones se corrigen y las plataformas evolucionan. Sin historial, una pantalla verde de hoy puede borrar las condiciones bajo las que se tomó una decisión ayer.
El 27 de agosto cerró el vacío de publicación. Es un logro verificable y merece ser llamado así. El vacío de pruebas no se cierra con una frase más optimista. Se cierra cuando el público puede recorrer desde una exigencia hasta la prueba, desde la prueba hasta una ejecución independiente y desde esa ejecución hasta una decisión limitada y explicada.
Fuentes
- Directorio de SVG AAM en el repositorio ARIA
- Carta SVG propuesta en el commit 806338
- Commit 806338 de incorporación
- Asunto estratégico 559 de W3C
- Comentario que pide un hito de pruebas
- Comentario de cierre de la revisión
- Commit que trasladó SVG AAM al monorepo de ARIA
- Lu Heng, Running-Code Primacy
- Carta SVG activa de 2024
- Publicaciones del grupo ARIA
- Proceso de W3C: cartas de grupo
- Proceso de W3C: experiencia de implementación
- SVG Accessibility API Mappings, Working Draft de 10 de mayo de 2018
- SVG Accessibility API Mappings, Working Draft de 27 de agosto de 2026
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance