Resumen

  • El 11 de agosto, AGWG comunicó un «consenso con una objeción» sobre separar la conformidad normativa de buena parte de la orientación informativa para reguladores y abrió cinco días laborables para objeciones adicionales.
  • El 18 de agosto continuó el debate sin resolución. La presidencia cerró esa parte con una consulta exploratoria, no con palabras definitivas.
  • El 25 de agosto se aprobaron tres resoluciones para actualizar las secciones 3, 3.1 y 3.2 con un Google Doc una vez resueltos los comentarios asociados.
  • La pull request 826 siguió cambiando después de la reunión y se fusionó el 26 de agosto. El historial acredita la ejecución posterior; no acredita por sí solo ni una desviación ni una nueva decisión.
  • Resolución de grupo, Editor’s Draft, merge, W3C Decision y Recommendation final son estados distintos. Un registro decisión-diff impediría que el último archivo absorbiera la autoridad de toda la cadena.

Lo que quedó abierto estaba escrito en la resolución

No hace falta interpretar un silencio para saber que el texto aún podía cambiar. Las minutas del 25 de agosto lo dicen tres veces. AGWG resolvió actualizar partes de la sección de conformidad según el texto de un Google Doc después de resolver los comentarios asociados en ese documento.

La frase combina dirección y condición. La dirección permitió a los editores modificar el Editor’s Draft en las secciones 3, 3.1 y 3.2. La condición reservó una labor de cierre sobre comentarios identificables. No era una aprobación carácter por carácter del archivo que existiría veinticuatro horas después, pero tampoco una conversación sin efecto.

Durante la reunión surgió la dificultad de archivo. Un participante preguntó si era apropiado decidir sobre un Google Doc cuyo texto no aparecía dentro del registro IRC. La respuesta fue que el material resultaba demasiado extenso para copiarlo allí. Esa explicación resuelve el problema operativo, no el de identidad documental. Un documento colaborativo puede cambiar sin que la URL cambie.

La gobernanza no exige recitar cientos de líneas en una llamada. Exige poder recuperar el objeto sobre el que se encontró consenso: una exportación fechada, una huella de contenido, las anclas afectadas y el conjunto limitado de comentarios que aún podían modificarlo.

La autoridad se formó durante varias reuniones

El 25 de agosto no fue una escena aislada. El 11 de agosto el grupo había anunciado «consenso con una objeción» sobre la arquitectura de la conformidad. El material normativo se centraría en la conformidad, incluida una declaración con alcance definido. La orientación para reguladores sobre contenido que un autor no controla plenamente pasaría principalmente a material informativo y, cuando procediera, a resultados concretos de WCAG.

La objeción registrada cuestionaba tomar una decisión grande antes de disponer de una definición acabada de conformidad. El mensaje público concedió cinco días laborables a quienes no habían estado presentes para sumar objeciones. Después, el grupo registraría el resultado o devolvería la cuestión a la agenda.

Un consenso con objeción no es unanimidad. Tampoco significa que cualquier objeción paralice el trabajo. El Proceso de W3C permite que la presidencia constate una decisión cuando, tras atender las preocupaciones legítimas hasta donde resulte razonable, aún persiste disenso. Una Formal Objection sostenida tiene su propio camino de revisión. Mezclar esos estados borra tanto el desacuerdo como la capacidad de decidir.

El 18 de agosto confirma que todavía no existía un texto cerrado. El grupo debatió páginas, recorridos, procesos, componentes, declaraciones de conformidad y reportes. Varias propuestas se reescribieron durante la llamada. Hacia el final, la presidencia dijo que no habría resolución ese día. Una consulta informal favoreció seguir explorando una sección más limitada, pero explorar una opción no equivale a adoptarla.

Las tres resoluciones de la semana siguiente fueron, por tanto, una transición institucional: de dirección general y deliberación a ejecución editorial. No fueron un plebiscito repentino ni una recomendación final.

Un +1 es evidencia de apoyo, no necesariamente un voto

Las minutas muestran +1, 0 y -1. Esos signos ayudan a la presidencia a percibir apoyo, reserva y oposición. Contarlos como si fueran automáticamente votos formales produciría una lectura falsa del proceso.

W3C distingue la construcción de consenso de una votación sustantiva. Votar es un último recurso cuando la discusión y el compromiso no permiten avanzar. Si ocurre, deben constar la decisión de votar, la regla aplicada, el resultado y las Formal Objections. El acta del 25 de agosto utiliza, en cambio, proyectos de resolución, señales de los participantes y resoluciones aceptadas.

La distinción preserva el límite de autoridad. Los participantes contribuyen conocimiento, necesidades de usuarios, argumentos y objeciones. La presidencia determina si existe una decisión de grupo según el proceso. El grupo puede dirigir su trabajo dentro de su carta. Ninguna de esas funciones convierte a quienes estaban conectados en soberanos de reguladores, tribunales, empresas o personas usuarias de la web.

También hay niveles internos distintos. El Process Document separa decisiones de presidencia, decisiones o resoluciones de grupo, Team Decisions y W3C Decisions. Llamar «resolución de AGWG» al acto le concede su peso exacto: más que conversación, menos que una Recommendation final o una obligación jurídica externa.

La pull request es un recibo de ejecución

La pull request 826 de w3c/wcag3 había sido abierta antes de la reunión. Se titulaba «Update conformance section» y se fusionó el 26 de agosto a las 23:57 UTC. Su rama final y el commit de merge ofrecen identidades que un revisor puede volver a consultar.

Entre apertura y fusión hubo múltiples pasos. Los mensajes públicos mencionan quitar la sección 4, ajustes editoriales, integrar contenido de conformidad posterior a la reunión, refactorizar, modificar el resumen en lenguaje claro, actualizar la nota introductoria del editor, incorporar revisiones específicas y atender feedback.

Nada de ello demuestra que los editores se apartaran del mandato. La propia resolución contemplaba cerrar comentarios. Un mensaje de commit no revela por sí solo la naturaleza normativa de cada diferencia. Tampoco sabemos, solo por la cantidad de commits, qué cambio ya estaba cubierto por la encuesta o la deliberación.

Sí sabemos algo más limitado: las palabras finalmente fusionadas se terminaron de producir durante la fase de ejecución. Git registra con precisión autores, fechas y bytes. No registra de manera automática qué parte de una resolución daba cobertura a cada cambio. La base de datos no es un trono y el botón de merge no crea la autoridad que ejecuta.

El Editor’s Draft declara su propia provisionalidad

La versión pública del 28 de agosto advierte que publicar un Editor’s Draft no supone respaldo del W3C ni de sus Miembros. Puede actualizarse, reemplazarse o quedar obsoleta. No debe citarse como algo distinto de un trabajo en curso.

La sección de conformidad aparece como Developing. Ese rótulo expresa acuerdo general sobre el tema y detalles todavía incompletos. No contradice que hubiera una resolución válida el 25 de agosto. Describe el estado al que esa resolución condujo.

Conviene separar, además, el Editor’s Draft reciente del último WCAG 3 Working Draft formal. El primero ofrece visibilidad continua del trabajo. El segundo es un hito publicado mediante otro procedimiento. Una futura Recommendation supondrá una transición adicional. Y si una institución incorpora WCAG a una norma, compra pública, contrato o sentencia, la fuerza vinculante vendrá de esa institución.

Confundir estos estados genera dos errores opuestos. Uno niega cualquier autoridad a la resolución porque el texto no es final. El otro atribuye al borrador provisional una fuerza que su propia portada niega. El registro debe permitir sostener al mismo tiempo que la decisión fue real y que el producto seguía en desarrollo.

Cómo sería una concordancia entre decisión y diferencia

El registro necesario puede ser pequeño. No requiere convertir cada edición en un debate constitucional.

Primero, conservaría el identificador de la cuestión, el texto literal de la resolución, el tipo de decisión, el grupo habilitado, la ventana de participación y la hora en que la presidencia declaró el resultado.

Segundo, fijaría la versión examinada. Si nació en el repositorio, bastaría un commit y las anclas pertinentes. Si nació en un documento colaborativo, harían falta una exportación versionada y una huella. El enlace vivo podría mantenerse como comodidad, no como única prueba.

Tercero, enumeraría el conjunto de comentarios que la decisión dejó para resolución posterior y quién podía cerrarlos. No es necesario publicar datos personales o anotaciones reservadas; sí delimitar la tarea.

Cuarto, clasificaría cada cambio posterior como implementación directa, cierre de un comentario nombrado, corrección editorial, reparación técnica o modificación de alcance. La etiqueta no decide si el cambio es correcto. Hace visible dónde revisar su fundamento.

Quinto, uniría el head final, el merge commit y el estado de publicación con cualquier Call for Consensus, reapertura, Formal Objection o decisión sustitutiva posterior. Un diff reproducible entre snapshot y merge cerraría el circuito.

El índice público va detrás del acto

La página de decisiones de AGWG mostraba, al realizar esta investigación, una última edición del 17 de agosto. Por razón de fechas no incluía aún las resoluciones del día 25. Esa ausencia no prueba ocultamiento, invalidez ni olvido.

Lo que muestra es que un índice es una proyección de estado y puede retrasarse respecto de la decisión. Las minutas documentan el acto; el índice ayuda a encontrarlo; la pull request registra su ejecución; el Editor’s Draft presenta el resultado actual; la publicación formal representa otro estado. Pedir a cualquiera de ellos que sustituya a los demás crea una falsa fuente única de autoridad.

La corrección es reconciliar las superficies. El índice actualizado debería enlazar el texto resuelto, el snapshot revisado y el merge. Las minutas y la pull request deberían apuntarse entre sí. Así se evita que una fecha de actualización termine interpretándose como una fecha de existencia.

Fuentes

  1. AGWG — Minutas y resolución del 11 de agosto de 2026
  2. Minutas de AGWG del 11 de agosto de 2026
  3. Minutas de AGWG del 18 de agosto de 2026
  4. Minutas de AGWG del 25 de agosto de 2026
  5. Política de decisión de AGWG
  6. Process Document de W3C
  7. Página de decisiones de AGWG
  8. Pull request 826 de w3c/wcag3
  9. Historial de commits de la pull request 826
  10. Editor’s Draft de WCAG 3
  11. Último WCAG 3 Working Draft publicado formalmente
  12. W3C — Actualización de 2025 del Process Document