344. [Noticias] Temas accesibles ¿para qué?

Nueva polémica estos días con respecto a los temas accesibles, en los que la comunidad WordPress ha tomado una posición muy clara.

Transcripción del programa

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 10 al 16 de agosto de 2026.

El equipo de Accesibilidad llevaba dos años actualizando, por primera vez en catorce años, los criterios de la etiqueta accessibility-ready para los temas del repositorio de WordPress, pasando de WCAG 2.0 a WCAG 2.1 nivel AA y revisando más de un centenar de temas del repositorio. El trabajo estaba previsto consolidarse antes del 30 de septiembre hasta que Matt Mullenweg intervino directamente para declarar la iniciativa «permanentemente aplazada» y añadió que cualquier committer puede anular las sugerencias del equipo de Accesibilidad. La respuesta de Joe Dolson, líder del equipo, fue inmediata: el programa es voluntario y seguirá adelante hasta la fecha prevista. Amber Hinds, que había liderado la reescritura, pidió a Mullenweg que aclarase si la intención es que cualquier tema pueda usar la etiqueta sin revisión, algo que ya ocurre técnicamente, precisamente por el problema que el equipo llevaba años intentando resolver. La pregunta sigue sin respuesta.

La ambigüedad de Mullenweg no es solo un asunto interno. La Directiva europea 2016/2102 obliga a las webs del sector público a cumplir WCAG 2.1 nivel AA, y WordPress alimenta una proporción enorme de esas webs en Europa. Si la etiqueta accessibility-ready deja de tener verificación, quien instale un tema marcado como tal en una web pública podría estar incumpliendo la legislación de su país. Ryan Boren, excommitter de peso, lo definió como una forma de zanjar una discusión sin argumentar. Eric Eggert, experto en accesibilidad con experiencia en la transposición de directivas europeas, cuestionó directamente el estilo de liderazgo y el trato a colaboradores voluntarios. Elena Brescacin, usuaria ciega y ponente habitual de WordCamp, recordó que la accesibilidad no es solo para personas con discapacidad permanente: cualquiera puede necesitar acceso por teclado, contraste alto o navegación por voz en cualquier momento de su vida.

El resultado es un impasse inhabitual: Dolson dice que el equipo continúa, Mullenweg dice que se acabó, y qué pasará el 1 de octubre con los temas que no hayan solicitado revisión sigue sin resolverse.

En paralelo, Anne McCarthy, release lead de la 7.1, propuso crear un plugin canónico de «Accessibility Labs», siguiendo el modelo de Performance Labs, como espacio para probar funcionalidades de accesibilidad antes de integrarlas en core. Dolson se ha mostrado favorable, con una condición: que exista un camino real hacia core. Sin esa garantía, el plugin podría convertirse en un almacén de funcionalidades que nunca se integran, que es precisamente lo que ha pasado con otras iniciativas de accesibilidad a lo largo de los años.

Ya está aquí la primera versión del WordPress Contributor Toolkit, la app de escritorio que nació en abril como el «Core Dev Environment Toolkit» y que resuelve el mayor obstáculo para dar el primer paso en el desarrollo de core: montar un entorno completo de wordpress-develop sin tener que instalar Git, Node ni Docker a mano. Disponible para Windows, macOS con Apple Silicon y Linux, esta versión da un salto respecto a la anterior: ya no solo deja el entorno listo, sino que acompaña durante toda la contribución, desde vincular un ticket de Trac hasta enviar el trabajo final.

Otra novedad práctica es que un mismo sitio ya puede albergar trabajo de varios tickets a la vez, cada uno en su propia rama, sin tener que repetir la instalación completa cada vez, y hay un botón para actualizar a la última versión de desarrollo sin perder el trabajo en curso. Esta versión llega justo a tiempo para el Contributor Day de WordCamp US, pensada explícitamente para que tanto quien contribuye por primera vez como quien facilita esas sesiones pueda centrarse en el ticket en sí y no en pelearse con la configuración del entorno.

Tercera ronda de parches de seguridad en poco más de un mes: WordPress 7.0.4 corrige una vulnerabilidad de ejecución remota de código para usuarios autenticados con rol de Author o superior, a través de una subida de archivo maliciosa en sitios que usan Imagick y Ghostscript para procesar imágenes. El fallo lo ha reportado, de nuevo, el equipo de pwn.ai, y tiene el CVE-2026-65640. Como viene siendo costumbre, los parches se están retroportando hasta la rama 4.7, y la RC3 de WordPress 7.1, publicada el mismo día, ya los incorpora.

Precisamente sobre esa RC3: la beta de la 7.1 sigue avanzando según calendario, con más de 90 correcciones desde la RC1, con 37 en el editor y 57 en core, y coincide con un hito importante del ciclo: la congelación total de cadenas de texto, así que a partir de ahora Polyglots ya puede traducir la versión final sin miedo a que cambien los textos. La fecha de lanzamiento sigue siendo el 19 de agosto.

Con la vista puesta más allá, arranca oficialmente la planificación de WordPress 7.2, con fecha propuesta de lanzamiento entre el 8 y el 10 de diciembre, coincidiendo con el State of the Word. El equipo de Core busca voluntarios para el Release Squad: Release Lead, coordinación, Tech Leads, Triage Lead y Test Lead, con plazo para presentarse hasta el 28 de agosto.

El equipo de Formación ha anunciado que ya están disponibles en Learn WordPress los kits de actividades prácticas: paquetes completos y listos para usar, pensados para cualquiera que quiera organizar una sesión formativa sobre WordPress sin preparar materiales desde cero. Cada kit incluye una guía para quien facilita la sesión y una presentación de diapositivas, todo pensado para funcionar sobre WordPress Playground sin necesidad de instalar nada ni crear cuentas, con una duración de entre 60 y 90 minutos y un resultado tangible al final de la sesión.

Hay once kits disponibles, con temas muy variados: desde primeros pasos para contribuir al proyecto o creación de contenido con bloques, hasta sesiones más técnicas como depuración para desarrolladores con herramientas como Query Monitor y Xdebug, o comercio electrónico con WooCommerce. Hay también dos kits centrados en inteligencia artificial, uno para gestionar un sitio local con Claude Desktop mediante lenguaje natural a través del adaptador MCP, y otro para usar el plugin de IA de WordPress directamente desde el escritorio, además de kits de accesibilidad, SEO, seguridad y el propio Playground.

WordPress Credits, el programa que lleva un año conectando estudiantes de todo el mundo con contribuciones reales a WordPress, estrena panel público, con datos que se actualizan semanalmente: estudiantes inscritos, instituciones participantes, contribuciones que van entrando al proyecto, sitios construidos y testimonios de quienes lo viven en primera persona.

En paralelo también se ha lanzado una propuesta para resolver un vacío evidente del programa: ahora mismo, cuando un estudiante se gradúa, no hay ningún paso siguiente definido, y todo el impulso construido se corta justo en el momento en que esa persona está más capacitada para seguir aportando. La propuesta plantea convertir WordPress Credits en el primer escalón de un recorrido más largo, con un itinerario claro hacia la certificación oficial de desarrollador de WordPress y hacia WordPress Jobs, además de proyectos de contribución concretos pensados específicamente para graduados que quieran volver, en colaboración con los propios equipos Make.

La pieza más interesante a nivel de ecosistema es un modelo que ya están explorando con empresas: que financien las plazas del examen de certificación para graduados, desbloqueables cuando el estudiante complete una contribución verificable tras graduarse, a cambio de acceso preferente a ese talento. El plan se ejecuta en tres fases: infraestructura básica primero, un piloto centrado en la vía de desarrollo después, y expansión a otras vías más adelante, con un objetivo de retención del 25% para ese piloto.

Ya está disponible la extensión oficial de navegador de WordPress, para Chrome y navegadores basados en Chromium a través de la Chrome Web Store, y para Safari en macOS desde la Mac App Store. Es un proyecto de código abierto que resuelve un problema muy conocido: la barra de administración de WordPress, siempre visible arriba de la pantalla cuando tienes sesión iniciada, estorba en sitios con cabeceras fijas o efectos de scroll, y desactivarla desde el perfil te hace perder también sus accesos rápidos. La extensión oculta esa barra pero mantiene los atajos más usados a un clic, en el propio icono de la barra del navegador, con la barra completa de vuelta en solo dos clics si la necesitas.

El icono de la extensión avisa, mientras se navega, si el sitio en el que se está corre WordPress y si hay sesión iniciada, sin resultar intrusivo. En un sitio que se administre, lleva directamente al escritorio o al editor de esa página, entrada, taxonomía o plantilla concreta que se está viendo, incluidas las plantillas de block themes, que abren directamente en el Editor del Sitio. Guarda localmente la lista de sitios en los que se tiene sesión, así que están disponibles aunque se esté navegando por otra web completamente distinta.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.