Noticias

Proyectos activos

Última actualización: 31 de octubre de 2026

En curso

v3: Un conjunto completo de herramientas de control de calidad

27 de septiembre de 2026

Presentación en DrupalCon Europe 2026

Principales novedades

• Núcleo de pruebas fusionado con Sa11y. El nuevo conjunto de reglas, desarrollado en colaboración, añade pruebas para desarrolladores, verificación de contraste y puntuación de legibilidad al conjunto principal de reglas para contenido.
• Compatibilidad con varios idiomas
• Constructor de reglas personalizadas
• Herramientas de mantenimiento del panel
• Una herramienta de rastreo del sitio para añadir nuevos resultados.
• Permite que determinadas pruebas (¿este PDF es accesible?) descarten alertas en todo el sitio para ciertos roles.
• Configuración dividida: pruebas y vistas de informes por rol, separadas para desarrolladores y para editores de contenido.

Y quizá lo más importante para el futuro del proyecto:

• Obtuvimos una subvención para poner en marcha esta organización patrocinadora, con el fin de dar soporte a los usuarios actuales y financiar el trabajo en futuras ideas para el proyecto.

v2: Descartes e informes

2 de marzo de 2023

Hace dos años presentamos el verificador de accesibilidad Editoria11y como un complemento para Drupal listo para usar, que ofrecía a los autores comentarios automáticos e instantáneos, con consejos útiles para mejorar su contenido.

Creíamos que esto cubriría una necesidad sin atender. Todas las opciones existentes exigían formación y un uso constante para resultar útiles, y la experiencia nos había demostrado que intentar formar y supervisar a miles de autores de contenido en una gran organización no era una forma eficiente de abordar el problema. Estábamos convencidos de que, para tener éxito, un programa necesitaba un alto grado de automatización y ofrecer a los autores de contenido una cortés “formación justo a tiempo” cuando detectara errores comunes.

Funcionó.

En Princeton, invirtió en gran medida el sentido de mis comunicaciones. En las plataformas donde estaba instalado, pasamos de enviar correos repetitivos a los autores de contenido pidiéndoles texto alternativo o mejoras en enlaces y encabezados, a recibir preguntas de esos mismos autores sobre cómo mejorar su redacción para que no se la señalara tanto.

Fuera de la universidad, la reacción fue de euforia:

Redactar consejos autónomos

En los consejos de la v1 optamos por un enfoque de “resumen y detalles”: una breve explicación del problema y un enlace para ver más detalles.

Esto ya mejoraba las herramientas escritas para desarrolladores: los consejos eran breves y claros. Pero decidir adónde enlazar siempre fue un problema. Varios usuarios de administraciones públicas y de educación superior sintieron la necesidad de modificar los consejos para quitar los enlaces a la documentación de Princeton, lo que les suponía trabajo adicional. Así que reescribimos los consejos predeterminados para que fueran autónomos, con ejemplos integrados.

La distinción entre alertas rojas (problemas seguros) y advertencias amarillas (posibles problemas) resultó confusa y, a veces, molesta.

Así que convertimos las advertencias amarillas en “verificaciones manuales” para aclarar su significado, y añadimos botones para que los autores pudieran descartar alertas. Las alertas “ignoradas” solo se ocultan para la persona que hace clic; las “marcadas como correctas” se ocultan para todos los editores del sitio. Los administradores del sitio pueden elegir quién tiene permiso para hacer cada cosa.

Crear un panel

Una queja habitual de los propietarios de sitios era que la herramienta hacía un gran trabajo encontrando problemas por todo el sitio, pero no había forma de ver un informe global.

La reescritura añade una opción para sincronizar los resultados con la base de datos del sitio. Ahora los propietarios de sitios pueden explorar los resultados por página o por problema, y revisar qué problemas se han ignorado o marcado como correctos, ¡y restaurarlos si no están de acuerdo!

Recorrido por el código de la v2 para desarrolladores

La v2 fue una reescritura casi completa. Algunas de las novedades son:

• Eliminar la dependencia de jQuery permite instalarlo en más plataformas y duplica el rendimiento.
• Ahora el verificador se puede configurar para que examine varias partes independientes de la página (por ejemplo, el contenido del artículo y el pie de página).
• Ahora el verificador puede probar elementos dentro del shadow DOM, que utilizan diversos componentes web y bibliotecas de JavaScript.
• Numerosos parámetros nuevos facilitan la integración con distintas plataformas, por ejemplo, ignorar automáticamente todos los problemas de determinadas páginas para determinados usuarios, si no son responsables del contenido de esa página pero quieren poder ver los resultados cuando lo necesiten.
• Ahora el verificador incluye varios temas base y parámetros para personalizar los colores.
• Las pruebas automatizadas ayudan a evitar regresiones en el código.

A11yTalks 2024

11 de junio de 2024

Drupal GovCon 2023

27 de octubre de 2023

DrupalCamp NJ 2023

28 de marzo de 2023

v1: Ayuda en línea

11 de marzo de 2021

Crear contenido web altamente accesible es complicado, y suele empezar con mucha formación.

Hay que desaconsejar prácticas habituales:

• No se deben usar tablas para crear columnas falsas
• El texto corrido no debe centrarse ni justificarse
• No se debe depender del formato puramente visual (grosor y tamaño de la fuente) para transmitir significado a los usuarios, que pueden estar escuchando el contenido o viéndolo en “modo de lectura”

Hay que fomentar prácticas nuevas:

• Las imágenes necesitan un texto alternativo que tenga sentido en su contexto
• Las páginas necesitan una estructura real
• Los enlaces deben tener títulos descriptivos

Sin duda, algunas de nuestras formaciones se imparten porque enseñamos conceptos nuevos, pero en algún momento hay que preguntarse: ¿cuánta de la necesidad de nuevas competencias se debe a que los conceptos son nuevos, y cuánta a que imponemos nuevas expectativas sin actualizar nuestras herramientas? Que algo sea nuevo no significa que no pueda ser intuitivo.

Lecciones de la historia de la ortografía

Fase 1: Culpar al autor

Desde los albores de la historia escrita hasta principios de los años 80, culpábamos al autor cuando escribía mal una palabra. Era responsabilidad del autor aprender a escribir bien.

¿Cómo podía alguien mejorar su ortografía? Esto le va a resultar familiar:

1. Recibía formación, con un tutor o en un aula
2. Le daban listas, normas y diccionarios para estudiar, una práctica que se remonta a los antiguos léxicos cuneiformes grabados en arcilla.

Fase 2: Culpar al diccionario

Pero algo cambió en los años 80: llamémoslo “fase 2 de la ortografía”. Los procesadores de texto más populares incorporaron el corrector ortográfico.

¿Y qué fue de la búsqueda de culpables? Casi de la noche a la mañana, la culpa pasó a la herramienta:

• ¿No sabes cómo se escribe una palabra? Intenta adivinarla y cruza los dedos para que encuentre una coincidencia. Si no la encuentra, échale la culpa al diccionario.
• ¿Usas una palabra real que el diccionario marca porque no la conoce? Refunfuña y decide si ignoras el subrayado o haces clic derecho y la añades al diccionario.

¿Arregló el corrector ortográfico toda nuestra ortografía? Desde luego que no. Pero ayudó. Y trasladó gran parte de la carga y la responsabilidad del autor a la máquina.

Pero esto no fue el final…

Fase 3: Culpar a la herramienta de autor

En los últimos años se ha dado otro paso adelante: las máquinas han empezado a escribir por nosotros:

• Los algoritmos predictivos intentan adivinar la siguiente palabra, la siguiente frase e incluso la respuesta completa a un mensaje de texto.
• Las herramientas de formato automático intentan convertir asteriscos, números y letras en listas, y códigos cortos en caracteres especiales y emojis, etc.
• Las herramientas de dictado intentan reconocer conceptos para elegir entre homófonos.

¿Y a quién se culpa cuando todo esto falla? ¡A la herramienta!

A los agregadores de redes sociales les encanta la bochornosa captura de pantalla de “¡Eso no es lo que quería decir!”.

Editoria11y es un paso hacia la fase 2

En nuestras formaciones hablamos mucho de pruebas y presentamos varias herramientas bastante buenas para realizarlas. Ninguna puede detectarlo todo: pautas como “evitar explicar conceptos mediante referencias cromáticas o espaciales” tiene que comprobarlas una persona, y las herramientas suelen detectar algo menos de la mitad de los problemas reales que puede tener un sitio. Pero se les da muy bien detectar muchos errores comunes en el contenido editorial.

Eso sí, hay tres problemas:

1. La mayoría son herramientas manuales. Al creador de contenido hay que haberle enseñado a usarlas, tiene que recordar que existen mientras escribe y tiene que acordarse de ejecutarlas cuando termina. Estos tres puntos de fallo se confabulan para que buena parte (¿la mayor parte?) del contenido quede sin revisar.
2. Señalan demasiado. No marcan solo los errores que el autor acaba de cometer, sino también los problemas de color que causó el diseñador, los problemas técnicos que causó el desarrollador, elementos estructurales con fines informativos, etc. Esto eleva el listón de la formación: los autores no solo tienen que entender la herramienta, también hay que enseñarles a ignorar una lista de falsos positivos o de problemas muy reales que hoy, mientras escriben este artículo concreto, no les corresponde corregir.
3. Las herramientas automatizadas suelen seguir el paradigma de rastrear el sitio y visitar el panel. De nuevo, esto da por sentado que se ha enseñado al autor a visitar el panel y que se acordará de hacerlo.

Así que Princeton se propuso crear algo nuevo: un verificador automático, integrado en el sitio web, que solo examinara los errores editoriales comunes.

Lo automático es… difícil.

1. Los verificadores automáticos tienen que ser sutiles: si son demasiado insistentes, interrumpen y frustran al autor. Si son demasiado discretos, pueden convertirse en un ruido de fondo fácil de ignorar.
2. Los verificadores automáticos tienen que ser muy eficientes: si la página se estremece o titubea mientras se ejecutan, los autores les tomarán manía y los desactivarán.
3. Los verificadores automáticos necesitan consejos aptos para principiantes. Para muchos autores, será la primera vez que oigan hablar del etiquetado, la estructura y el lenguaje que harán más accesible su contenido. Las alertas deben redactarse en un lenguaje sencillo y no técnico, con consejos prácticos para mejorar el contenido.

Así que empezamos por la herramienta más cercana a estos objetivos que pudimos encontrar: Sa11y, de la Toronto Metropolitan University. Tomamos su arquitectura de pruebas y su enfoque intuitivo de panel de información con información emergente, y dedicamos medio año a adaptar la herramienta para que las pruebas se ejecutaran siempre de forma automática, a optimizar su rendimiento, a ajustar la información emergente y a crear una larga lista de opciones de configuración con las que un desarrollador pudiera adaptarla rápidamente a cualquier plataforma.

Este es su aspecto actual:

Cuando un autor ha iniciado sesión en su sitio, el botón de Editoria11y indica el número y el tipo de problemas (sin problemas, verificaciones manuales necesarias, probables problemas detectados) de cada página. Puede hacer clic para mostrar el resaltado en línea y los consejos. Si el error es nuevo, porque está viendo una página que acaba de editar, el panel se abre automáticamente.

En marzo de 2021, esto significa que más de 400 sitios web de Princeton comprueban automáticamente:

• Un buen esquema del documento
  • Niveles de encabezado omitidos
  • Encabezados vacíos
  • Encabezados muy largos
  • Citas en bloque sospechosamente cortas que en realidad podrían ser encabezados.
• Alternativas textuales
  • Imágenes sin texto alternativo
  • Imágenes con un nombre de archivo como texto alternativo
  • Imágenes con un texto alternativo muy largo
  • Texto alternativo con texto redundante como “imagen de” o “foto de”
  • Imágenes en enlaces cuyo texto alternativo parece describir la imagen en lugar del destino del enlace
  • Visualizaciones incrustadas que suelen requerir una alternativa textual
• Enlaces descriptivos
  • Enlaces sin texto
  • Enlaces titulados con un nombre de archivo
  • Enlaces titulados solo con texto genérico: “haz clic aquí”, “más información”, “descargar”, etc.
  • Enlaces que se abren en una ventana nueva sin un icono de enlace externo
• Control de calidad general
  • Comprobar que se usa el formato de lista en lugar de asteriscos, números y letras
  • GRANDES CANTIDADES DE TEXTO EN MAYÚSCULAS
  • Tablas sin encabezados y tablas con encabezados de documento (“Encabezado 3”) en lugar de encabezados de tabla (<th>)
  • Enlaces a PDF y otros documentos, que recuerdan al usuario que debe comprobar la accesibilidad de la descarga o proporcionar un formato alternativo accesible
  • Videos incrustados, que recuerdan al usuario que debe añadir subtítulos opcionales
  • Audios incrustados, que recuerdan al usuario que debe proporcionar una transcripción
  • Publicaciones de redes sociales incrustadas, que recuerdan al usuario que debe proporcionar elementos alt

Hemos publicado la biblioteca de JavaScript para la comunidad, hemos creado una integración con Drupal lista para usar y hemos empezado a trabajar en otra para WordPress.

Hacia la fase 3: Accesible por defecto

En muchos sentidos, Editoria11y es una solución provisional. La mayoría de los errores que detecta se cometieron porque impusimos nuevas expectativas a los autores de contenido (“etiqueta tu contenido con una buena estructura”), pero les dimos herramientas que fomentaban lo contrario.

El camino a seguir es hacer que crear contenido accesible sea más fácil y lo más automático posible. Aún no está claro qué forma tomará esto, pero probablemente incluya cosas como:

• Replantearse qué opciones hay disponibles. Por ejemplo: si seguimos diciendo a los usuarios que no justifiquen el texto en la Web, ¿no será hora de retirar ese botón de “justificar texto”?
• Replantearse las opciones predeterminadas. Por ejemplo: la tabla predeterminada de la mayoría de los sistemas de gestión de contenidos no tiene encabezados. Es el usuario quien tiene que saber que debe hacer clic en “propiedades” y añadir las funciones de accesibilidad; ¿quizá sea hora de darle la vuelta a esto?
• Reflexionar sobre el formato predictivo y las “sugerencias mientras trabajas”. Si un usuario pone en negrita una línea entera, ¿podemos sugerirle que la convierta en un encabezado? Si un usuario va a seleccionar un encabezado, ¿podemos adivinar qué niveles de encabezado podría querer en lugar de darle seis opciones? ¿Podemos ofrecer formación justo a tiempo para los conceptos difíciles?