En pocas palabras: WordPress 7.0 y 7.1 sumaron 127 correcciones de accesibilidad en Core y Gutenberg: foco de teclado estandarizado en 2px, mejor soporte para lectores de pantalla, más contraste y modo alto contraste, y nuevas interfaces como Visual Revisions y el lightbox de Gallery revisadas contra WCAG 2.2 AA antes del lanzamiento, mientras que los bloques Tabs y Playlist llegaron con 7.1.
Según detalla WordPress VIP, nada de esto salió en los titulares de lanzamiento, pero si te toca cumplir con WCAG, ADA o Section 508, es la parte que más te interesa.
La accesibilidad en WordPress es el conjunto de prácticas y ajustes técnicos que permiten que personas con discapacidad visual, motriz o cognitiva usen un sitio sin barreras, incluyendo compatibilidad con lectores de pantalla, navegación por teclado y contraste adecuado. En WordPress, esto abarca tanto el admin como el contenido publicado, y Core más Gutenberg se ocupan de una parte, no de toda.
En este artículo:
- En 30 segundos
- ¿Qué plazo legal enfrentan los sitios públicos para cumplir con WCAG 2.1 AA?
- ¿Cuáles son los 127 cambios de accesibilidad que suman WordPress 7.0 y 7.1?
- ¿Qué retrocedió en accesibilidad con el scroll infinito de la biblioteca de medios?
- ¿Qué sigue siendo responsabilidad del sitio y no de WordPress Core?
- ¿Cómo aprovechar estas mejoras si administrás muchos sitios en WordPress?
- Errores comunes al encarar accesibilidad en WordPress
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- WordPress 7.0 y 7.1 sumaron 127 correcciones de accesibilidad en Core y Gutenberg, según el análisis de WordPress VIP.
- Las entidades públicas que sirven a 50.000 personas o más deben cumplir WCAG 2.1 AA antes del 26 de abril de 2027, por la regla ADA Title II del Departamento de Justicia de EE.UU.
- 7.1 activó scroll infinito por defecto en la biblioteca de medios, un patrón que WordPress VIP describe como inaccesible.
- El tema, los plugins y el contenido publicado siguen siendo responsabilidad del sitio, no de WordPress Core.
- 7.1 suma 44 mejoras de accesibilidad en Core y 43 en el editor, según el changelog oficial de Make WordPress.
¿Qué plazo legal enfrentan los sitios públicos para cumplir con WCAG 2.1 AA?
El 26 de abril de 2027 es la fecha que cualquier organismo estatal, gobierno municipal o universidad pública en EE.UU. que sirva a 50.000 personas o más tiene marcada en el calendario para cumplir con WCAG 2.1 AA, según la regla ADA Title II del Departamento de Justicia citada por WordPress VIP. Las entidades que sirven a menos población tienen hasta abril de 2028.
Ojo con esto: la fecha límite ya se movió una vez antes. Planificar con la expectativa de que se vuelva a correr es una apuesta, no una estrategia. Section 508, Section 504 y ADA Title III corren en paralelo, con orígenes legales distintos pero el mismo punto de referencia: WCAG AA. Title III no tiene un estándar escrito propio, pero las demandas y acuerdos extrajudiciales suelen citar WCAG AA como el criterio de remediación esperado.
¿Y qué pasa si tu organización no entra en ninguna de estas categorías? Igual te conviene mirar WCAG 2.2, porque cada versión del estándar incluye los requisitos de la anterior. Cumplir con la más nueva te deja cubierto para las que vienen.
¿Cuáles son los 127 cambios de accesibilidad que suman WordPress 7.0 y 7.1?
WordPress 7.0 y 7.1 distribuyen esas 127 correcciones en cinco frentes: teclado y foco, lectores de pantalla, contraste, medios y alt text, y nuevas interfaces. El changelog de accesibilidad de 7.1 detalla 44 mejoras en Core y 43 en el editor, mientras que la field guide de 7.1 suma otras 46 específicas de accesibilidad entre más de 310 tickets totales.
- Teclado y foco: los indicadores de foco en el admin se estandarizaron en mínimo 2 píxeles CSS (7.1), se corrigieron focus traps causados por ciertas propiedades de display en componentes del editor (7.1), y los indicadores de foco en la biblioteca de medios quedan completamente visibles (7.1).
- Lectores de pantalla: el editor ahora usa la función
speak()de WordPress en lugar de regiones live separadas, lo que da feedback más consistente (7.1). Los encabezados de pantallas del admin pasan a H1 por defecto (7.1), y los ítems sin título en la grilla de medios reciben etiquetas precisas. - Contraste y modos de visualización: se corrigieron problemas de contraste en todo el admin (7.0), se mejoró el contraste en los esquemas de color del admin (7.1), y los estados activos de botones y pestañas ahora se ven en Windows High Contrast Mode (7.1).
- Medios y alt text: la biblioteca de medios soporta control por voz (7.0), el texto alternativo guardado en metadatos IPTC se puede importar al subir una imagen (7.0), y el bloque de imagen tiene un toggle nuevo para marcarla como decorativa (7.1).
- Nuevas interfaces: Visual Revisions, el lightbox de Gallery y Connectors se revisaron contra WCAG 2.2 AA antes de salir (7.0). Los bloques Tabs y Playlist llegaron con 7.1, aunque Tabs es un patrón de diseño fácil de romper en accesibilidad.
¿Por qué importa esto si vos no gestionás un sitio público? Porque estas correcciones bajan a nivel de markup y admin, así que cualquier sitio corriendo WordPress se vuelve más accesible apenas actualiza, sin que el equipo toque una línea de código. Lo cubrimos en detalle en la comunidad de WordPress que impulsa estas mejoras.
¿Qué retrocedió en accesibilidad con el scroll infinito de la biblioteca de medios?
WordPress 7.1 activó el scroll infinito por defecto en la grilla de la biblioteca de medios. La field guide oficial de 7.1 describe el cambio en términos neutrales, como una función activada por defecto con opción de desactivarla, pero WordPress VIP lo señala como un patrón de diseño inaccesible.
La buena noticia es que hay dos formas de revertirlo. Cada usuario puede desactivarlo desde su perfil y volver a la paginación de siempre. Si administrás el sitio y querés que sea el comportamiento por defecto para todos, el filtro media_library_infinite_scrolling devolviendo false hace el trabajo.
¿Vale la pena tocarlo? Si tu organización está en medio de una auditoría WCAG, sí. Es un ajuste de una línea que elimina un hallazgo predecible.
¿Qué sigue siendo responsabilidad del sitio y no de WordPress Core?
El tema, los bloques personalizados, los plugins, el contenido publicado, los PDFs y los embeds de terceros siguen bajo responsabilidad de tu equipo, no de WordPress Core. Las mejoras de la plataforma sacan de tu lista la accesibilidad del admin y el markup de los bloques nativos, pero no tocan nada de lo que vos construiste encima.
El nuevo indicador de foco de 2px que trajo 7.1 no sirve de nada si tu tema fue diseñado para eliminar los outlines de foco (un patrón más común de lo que debería). Tampoco el toggle de imagen decorativa reemplaza la tarea de escribir alt text real para las imágenes que sí necesitan descripción. Más contexto en nuestra nota sobre cómo crear una landing page accesible en WordPress.
Una auditoría expone brechas de accesibilidad sin aclarar qué sistema es responsable de cada una. Las correcciones de plataforma benefician a los visitantes y también a tu equipo de contenido que usa tecnología asistiva, lo cual conecta directo con los requisitos de Section 508 para herramientas de uso interno en agencias federales.
¿Cómo aprovechar estas mejoras si administrás muchos sitios en WordPress?
El primer paso es chequear qué versión corre cada sitio: si todavía estás en una release 6.x, no tenés ninguna de las 127 mejoras de 7.0 y 7.1. A partir de ahí, la lista de tareas es corta pero concreta.
- Verificá la versión actual: un sitio en 6.x no se beneficia de nada de lo que listamos arriba hasta que actualice.
- Desactivá el scroll infinito si ya estás en 7.1: hacelo por default para todos en vez de esperar que cada usuario lo encuentre en su perfil.
- Reprobá temas y bloques personalizados: los nuevos estándares de foco y contraste pueden eliminar workarounds que usabas en versiones viejas, o pueden chocar con estilos propios.
- Testeá Tabs y Playlist en staging: antes de ponerlos en producción, confirmá que no introducen problemas nuevos de accesibilidad en tu sitio.
Si gestionás un portfolio de cientos de sitios con dueños y ciclos de release distintos, mantener todo actualizado es un proyecto en sí mismo. Para un sitio único, no hace falta tanta orquestación: alcanza con tener buenas prácticas de actualización y un hosting WordPress que no te complique el proceso, como el hosting WordPress de Donweb.
| Área | WordPress 7.0 | WordPress 7.1 |
|---|---|---|
| Foco y teclado | Fixes de navegación por teclado en el editor | Indicador estandarizado de 2px, focus traps corregidos |
| Lectores de pantalla | Comportamiento más predecible en admin | Función speak(), H1 por defecto, etiquetas en media grid |
| Contraste | Correcciones en todo el admin, forced-colors mode | Mayor contraste en esquemas de color, soporte Windows High Contrast |
| Medios | Control por voz, import de alt text desde IPTC | Toggle de imagen decorativa, scroll infinito (con opt-out) |
| Bloques nuevos | Visual Revisions, Gallery lightbox, Connectors | Tabs, Playlist |
Errores comunes al encarar accesibilidad en WordPress
Actualizar y asumir que ya está resuelto. Subir a 7.1 te da las 127 correcciones de plataforma, pero si tu tema sigue sin contraste adecuado o tu plugin de formularios no etiqueta los campos, la auditoría te va a encontrar igual.
Dejar el scroll infinito activado sin revisarlo. Es el único retroceso documentado de esta release, y corregirlo toma un filtro de una línea. No tiene sentido arrastrarlo. Sobre eso hablamos en probar estos cambios en un entorno de staging.
Usar el bloque Tabs sin testearlo primero. Según WordPress VIP, es un patrón fácil de implementar mal desde el punto de vista de accesibilidad. Probalo en staging antes de ponerlo en una página que ya recibe tráfico real.
Confundir «cumplir WCAG 2.1» con «estar a salvo para siempre». La fecha de abril 2027 es para WCAG 2.1 AA, pero 2.2 ya existe y suma requisitos. Apuntar directo a la versión más nueva te ahorra una vuelta.
Preguntas Frecuentes
¿Qué novedades de accesibilidad trae WordPress 7.0 y 7.1?
WordPress 7.0 y 7.1 suman 127 correcciones de accesibilidad combinadas entre Core y Gutenberg, cubriendo foco y teclado, lectores de pantalla, contraste, manejo de medios y revisión WCAG 2.2 AA en interfaces nuevas como Visual Revisions y Gallery lightbox.
¿WordPress cumple con WCAG 2.1 AA?
WordPress Core y el editor de bloques mejoran de forma activa su conformidad con WCAG en cada release, pero el cumplimiento final depende también del tema, los plugins y el contenido que publiques, que no están cubiertos automáticamente por las mejoras del core. En mantener los enlaces de tu sitio sin errores profundizamos sobre esto.
¿Qué plazo tienen las entidades públicas para cumplir con la ADA Title II?
Las entidades públicas que sirven a 50.000 personas o más tienen hasta el 26 de abril de 2027 para cumplir con WCAG 2.1 AA; las que sirven a menos población tienen hasta abril de 2028, según la regla del Departamento de Justicia de EE.UU. Cobertura relacionada: la vulnerabilidad crítica hallada en Contact Manager.
¿Cómo desactivar el scroll infinito en la biblioteca de medios de WordPress?
Cada usuario puede desactivarlo desde su perfil individual, o el administrador del sitio puede desactivarlo para todos usando el filtro media_library_infinite_scrolling y haciendo que devuelva false.
¿Qué sigue siendo responsabilidad del sitio y no de WordPress Core en materia de accesibilidad?
El tema, los bloques personalizados, los plugins, el contenido publicado, los archivos PDF y los embeds de terceros siguen siendo responsabilidad exclusiva del equipo que administra el sitio, no de WordPress Core ni del editor de bloques.
Conclusión
WordPress 7.0 y 7.1 movieron 127 piezas de accesibilidad sin que casi nadie lo notara, porque las novedades de IA y medios se llevaron los titulares. Para cualquiera con obligaciones de WCAG, ADA o Section 508 encima, esa es justo la parte que conviene revisar antes de que llegue abril de 2027.
Lo concreto: actualizá a 7.1, desactivá el scroll infinito por defecto, y reprobá tu tema contra los nuevos estándares de foco y contraste. Lo que la plataforma no resuelve (tema, plugins, contenido) sigue siendo tarea tuya, y ninguna actualización de Core te va a sacar esa responsabilidad de encima.
