Resumen

  • W3C abrió el 18 de agosto de 2026 la revisión de una nueva carta BTT hasta el 18 de septiembre y prorrogó la carta actual hasta el 23 de octubre.
  • El mandato vigente contiene AT Driver como especificación normativa; la propuesta siguiente lo elimina y dice que ARIA podría adoptarlo al renovar su carta.
  • La carta activa de ARIA llega al 1 de enero de 2027, pero AT Driver no figura en su catálogo de entregables.
  • El asunto 2826 de ARIA sigue abierto. Las actas de julio describen la ruta hacia una posible carta receptora, no una aceptación consumada.
  • El Editor's Draft del 26 de agosto todavía identifica a BTT como grupo publicador y puede seguir evolucionando durante la transición.
  • Un expediente de transferencia debe unir mandato saliente, mandato receptor, versión técnica, autoridad de decisión, participantes y contexto de patentes.

El cambio existe en futuro, no todavía en presente

AT Driver automatiza la interacción con tecnologías de asistencia. Puede iniciar sesiones, cambiar ajustes, enviar intenciones del usuario y observar la salida capturada de un lector de pantalla. Su diseño aprovecha WebDriver BiDi, pero el objeto gobernado no tiene por qué estar dentro de un navegador.

Por esa mezcla, el protocolo entró en 2024 en Browser Testing and Tools. La carta que sigue en vigor lo enumera junto con WebDriver y WebDriver BiDi. W3C extendió ese mandato hasta el 23 de octubre mientras se tramita la nueva carta.

La propuesta pública cuenta otra historia. Solo conserva WebDriver y WebDriver BiDi como especificaciones normativas. En el historial declara que AT Driver se elimina. Después, en coordinación, afirma que fue parte del alcance de BTT y que ARIA podrá adoptarlo cuando renueve su propia carta.

No es una contradicción documental; son dos momentos. La carta vigente dice quién tiene autoridad ahora. La propuesta dice qué ocurriría después de su aprobación. La revisión termina el 18 de septiembre, pero esa fecha por sí sola no aprueba nada.

La afinidad con ARIA es real

Las actas de los editores de ARIA explican por qué se plantea el traslado. AT Driver depende de ideas de WebDriver BiDi y necesita diálogo con navegadores, pero su implementación y sus casos de uso pertenecen también a fabricantes de tecnologías de asistencia. Un proveedor con una implementación estaba representado en ARIA, no en BTT.

La capacidad de automatizar lectores de pantalla afecta al núcleo de la interoperabilidad ARIA. Sin ella, muchas pruebas quedan manuales y no escalan. Además, el protocolo se escribió con suficiente amplitud para controlar tecnologías de asistencia fuera del contexto web. ARIA reúne, por tanto, una comunidad que puede evaluar mejor esa parte del sistema.

La afinidad no concede mandato. La carta actual de ARIA describe muchos estándares de roles, estados y mapeos de accesibilidad, además de trabajo con ARIA-AT, pero no incorpora AT Driver como entregable normativo. El asunto 2826 permanece abierto, marcado En curso y sin una rama o solicitud de cambios asociada en su ficha pública.

En julio se fijó una secuencia: conversación entre presidencias y personal de W3C, posible borrador de carta, deliberación en ARIA y revisión posterior por el Advisory Committee. También quedó anotado que se había sugerido un entregable conjunto, pero que no era una opción. La secuencia protege precisamente la diferencia entre proponer un hogar y autorizarlo.

Se puede editar sin haber transferido

Los participantes preguntaron qué ocurriría si BTT retiraba AT Driver antes de que ARIA estuviera preparada. La respuesta fue práctica: el texto era un Editor's Draft, ni siquiera una Working Draft, y el desarrollo podía continuar. Si no prosperaba la recepción por ARIA, el Community Group podía producir un informe y volver a intentar el paso institucional más adelante.

La limitación aparece al convertir ese trabajo en una pieza normativa de un Working Group. Las actas señalan que no se podía apuntar todavía al lado del Community Group como la referencia normativa pertinente; era necesario que un Working Group lo aprobara. Seguir editando y recibir autoridad para publicar en la Recommendation Track son actos distintos.

El borrador del 26 de agosto conserva a BTT como grupo que lo publica y mantiene su lista pública como canal de comentarios. También advierte que un Editor's Draft no expresa el respaldo de W3C o de sus miembros. Es coherente con la carta BTT aún activa. No demuestra que ARIA haya tomado control.

El perímetro jurídico también cambia por grupo

W3C explica que el alcance de una carta delimita el trabajo permitido y los compromisos de patentes. Su guía de transición exige renovar la carta de un grupo existente cuando el trabajo entrante queda fuera de alcance. La carta receptora debe identificar el entregable transferido y la relación futura con el Community Group.

No hay base para anunciar un vacío de patentes. La Patent Policy vincula los compromisos a la labor del grupo concreto al que se incorpora cada participante. Los compromisos ya efectivos pueden persistir sobre versiones posteriores sustancialmente similares. El expediente revisado no aporta ninguna exclusión, infracción ni fracaso de licencia.

Lo que sí requiere prueba es el estado hacia delante: quién se incorporó al grupo receptor, bajo qué versión de la política, quién acepta cambios sustantivos y qué mecanismo cubre a contribuyentes externos. Un historial de commits no muestra por sí solo ese mapa.

Un expediente que una salida y entrada

La solución no consiste en detener el protocolo. W3C puede publicar un expediente breve de transferencia que se actualice por versiones.

En el lado de salida constarían la carta BTT vigente, su fecha efectiva y la instantánea exacta de AT Driver. En el lado de entrada aparecerían el borrador de carta ARIA, la decisión interna, la revisión consultiva, la aprobación o rechazo y la convocatoria de participantes. El punto intermedio identificaría el custodio del repositorio y la autoridad para cada tipo de decisión.

El tipo importa. Una edición del borrador, un informe comunitario, una resolución del Working Group y una publicación formal no son equivalentes. Cada evento debería incluir fecha, objeciones, estado sustituido y condición de la referencia normativa.

También conviene registrar, sin revelar asesoramiento legal reservado, la versión de Patent Policy, la ruta de adhesión y los compromisos para no participantes. Un mapa de representación debería mostrar si navegadores, lectores de pantalla, editores y responsables de pruebas participan efectivamente en el órgano que decide.

La lección de Heng Lu es útil aquí: estar presente en una conversación o repositorio no equivale a recibir autoridad delegada. El expediente hace visible la regla que transforma el aporte técnico en una decisión institucional.

La revisión puede cerrar el hueco antes de abrirlo

La propuesta BTT ya reconoce que la recepción por ARIA es eventual. Quienes revisan la carta pueden pedir que la salida enlace el estado de la carta receptora, nombre la autoridad durante el intervalo y fije un próximo control público.

Eso no obliga a ARIA a aceptar. Le permite deliberar de verdad sobre alcance, carga, participación y política de patentes sin que la continuidad técnica sea presentada como consentimiento. Tampoco quita a BTT la autoridad que conserva hasta que cambie su mandato.

AT Driver puede seguir avanzando. La gobernanza debe conservar la capacidad de distinguir hacia dónde avanza, bajo quién y con qué clase de decisión.

Fuentes

  1. Anuncio de revisión de la carta BTT
  2. Carta BTT propuesta
  3. Carta BTT vigente
  4. Asunto ARIA 2826
  5. Actas de editores de ARIA, 8 de julio de 2026
  6. Carta vigente de ARIA
  7. Historial de cartas ARIA
  8. Editor's Draft de AT Driver
  9. Guía W3C para transiciones entre Community Group y Working Group
  10. Patent Policy de W3C, 15 de mayo de 2025
  11. Preguntas frecuentes sobre la Patent Policy
  12. Heng Lu, The Multi-Stakeholder Mirage