CMS accesible: fu­n­da­me­n­tos y ejemplos (Contao, Plone y papaya)

Desde que entró en vigor la Ley Europea de Ac­ce­si­bi­li­dad, crear páginas web ac­ce­si­bles con un CMS ya no es opcional, sino esencial. Si un sistema de gestión de co­n­te­ni­dos está equipado con las funciones adecuadas, puedes cumplir con los re­qui­si­tos legales de la UE, mejorar la ex­pe­rie­n­cia del usuario y optimizar el contenido para los motores de búsqueda.

¿Por qué un CMS debería ser accesible?

La ac­ce­si­bi­li­dad web no solo afecta a la in­frae­s­tru­c­tu­ra técnica de una página, sino también de forma muy especial a los co­n­te­ni­dos pu­bli­ca­dos. Para que la in­fo­r­ma­ción digital sea accesible a todos los usuarios, los co­n­te­ni­dos deben ela­bo­rar­se de manera que puedan ser in­te­r­pre­ta­dos también mediante lectores de pantalla, líneas Braille o na­ve­ga­ción por teclado.

El sistema de gestión de co­n­te­ni­dos (CMS) que se utilice desempeña aquí un papel clave. Aunque a menudo se habla de la ac­ce­si­bi­li­dad de la propia interfaz del CMS, es igual de im­po­r­ta­n­te analizar hasta qué punto facilita la creación editorial de co­n­te­ni­dos ac­ce­si­bles. Un CMS puede co­n­si­de­rar­se “accesible” si pro­po­r­cio­na a los editores ayudas, di­re­c­tri­ces de es­tru­c­tu­ra y he­rra­mie­n­tas de va­li­da­ción que permitan diseñar de forma sencilla páginas web ac­ce­si­bles. Ejemplos típicos son:

• Campos de entrada para textos al­te­r­na­ti­vos en imágenes
• Avisos cuando falta una jerarquía de en­ca­be­za­dos
• He­rra­mie­n­tas para crear tablas y fo­r­mu­la­rios ac­ce­si­bles
• Co­m­pro­ba­cio­nes au­to­má­ti­cas de contraste o errores se­má­n­ti­cos

Un CMS que fomenta la ac­ce­si­bi­li­dad reduce el riesgo de errores edi­to­ria­les y ayuda a las or­ga­ni­za­cio­nes a cumplir con los re­qui­si­tos legales, además de ofrecer in­fo­r­ma­ción en igualdad de co­n­di­cio­nes a todos los grupos de usuarios.

¿Qué no­r­ma­ti­vas definen la ac­ce­si­bi­li­dad web?

Los re­qui­si­tos para el contenido accesible en la UE están definidos por varias normas legales y técnicas. En virtud del Acta Europea de Ac­ce­si­bi­li­dad, muchas empresas —incluidas las compañías es­ta­dou­ni­de­n­ses que ofrecen bienes o servicios en la UE— deben ga­ra­n­ti­zar que sus páginas web y productos digitales cumplan con los re­qui­si­tos de ac­ce­si­bi­li­dad.

Estas no­r­ma­ti­vas se basan en las Pautas de Ac­ce­si­bi­li­dad para el Contenido Web (WCAG), de­sa­rro­lla­das por el World Wide Web Co­n­so­r­tium (W3C). Las WCAG 2.1 y 2.2 definen cuatro pri­n­ci­pios clave de ac­ce­si­bi­li­dad apli­ca­bles tanto a un CMS como a otros entornos digitales:

• Pe­r­ce­p­ti­ble: toda la in­fo­r­ma­ción debe pre­se­n­tar­se de forma que cualquier usuario pueda pe­r­ci­bi­r­la (p. ej., con textos al­te­r­na­ti­vos en imágenes y co­n­tra­s­tes adecuados).
• Operable: la interfaz debe poder uti­li­zar­se mediante distintos métodos de entrada (p. ej., teclado).
• Co­m­pre­n­si­ble: los co­n­te­ni­dos deben estar es­tru­c­tu­ra­dos de forma clara, ser legibles y escritos en un lenguaje sencillo.
• Robusto: los co­n­te­ni­dos deben ser co­m­pa­ti­bles con una amplia variedad de di­s­po­si­ti­vos y te­c­no­lo­gías de asi­s­te­n­cia.

Para editores y creadores de contenido esto implica, entre otras cosas, usar una jerarquía de en­ca­be­za­dos coherente (H1 a H6), añadir textos al­te­r­na­ti­vos y enlaces de­s­cri­p­ti­vos, emplear un lenguaje claro y ga­ra­n­ti­zar una na­ve­ga­ción lógica. Un CMS accesible ayuda a reducir errores edi­to­ria­les y asegura el cu­m­pli­mie­n­to de los es­tá­n­da­res legales vigentes.

Ejemplos de CMS ac­ce­si­bles: Contao, Plone y papaya CMS

No todos los CMS ofrecen las mismas co­n­di­cio­nes para crear co­n­te­ni­dos ac­ce­si­bles. Mientras que algunos sistemas destacan por la calidad de su salida en el frontend, otros ponen el énfasis en el control editorial o en la ri­gu­ro­si­dad semántica. Los tres CMS de código abierto Contao, Plone y papaya CMS se co­n­si­de­ran es­pe­cia­l­me­n­te adecuados para trabajar con ac­ce­si­bi­li­dad. Por ello, en los si­guie­n­tes apartados resumimos las funciones más im­po­r­ta­n­tes de estos sistemas en este contexto.

Contao

Contao es un CMS de­sa­rro­lla­do en Alemania que, desde el inicio, se diseñó para generar código accesible y se­má­n­ti­ca­me­n­te correcto. Para la creación de co­n­te­ni­dos ac­ce­si­bles y conformes a la normativa, la he­rra­mie­n­ta ofrece, entre otras, las si­guie­n­tes funciones:

• Pla­n­ti­llas ac­ce­si­bles: muchas pla­n­ti­llas cumplen con las WCAG y están diseñadas para ser ada­p­ta­ti­vas.
• Elementos de contenido es­tru­c­tu­ra­dos: los editores trabajan con módulos que ga­ra­n­ti­zan salidas claras y se­má­n­ti­ca­me­n­te correctas.
• Soporte para textos al­te­r­na­ti­vos: imágenes, vídeos y otros medios pueden co­m­ple­me­n­tar­se con al­te­r­na­ti­vas textuales.
• Módulos de fo­r­mu­la­rios: módulos listos para usar que incluyen ma­r­ca­do­res de campos obli­ga­to­rios, na­ve­ga­ción por teclado y gestión de errores.

Además, existen ex­te­n­sio­nes como Si­te­Co­c­k­pit, que integran en el CMS funciones como co­n­mu­ta­do­res de contraste de color, control del tamaño de la ti­po­gra­fía o informes de ac­ce­si­bi­li­dad. Por estas ca­ra­c­te­rí­s­ti­cas, Contao resulta es­pe­cia­l­me­n­te adecuado para or­ga­ni­s­mos públicos, in­s­ti­tu­cio­nes edu­ca­ti­vas u ONG.

Plone

Plone es un potente CMS basado en Python que desde hace muchos años cumple con altos es­tá­n­da­res de ac­ce­si­bi­li­dad. Lo utilizan en todo el mundo uni­ve­r­si­da­des, mi­ni­s­te­rios y or­ga­ni­za­cio­nes con elevados re­qui­si­tos de ac­ce­si­bi­li­dad. Plone cumple con las WCAG 2.1 en nivel de co­n­fo­r­mi­dad AA, por lo que muchos aspectos de ac­ce­si­bi­li­dad ya vienen in­te­gra­dos de serie. Para estas exi­ge­n­cias existe un documento VPAT (Voluntary Product Ac­ce­s­si­bi­li­ty Template, Plantilla Vo­lu­n­ta­ria de Ac­ce­si­bi­li­dad de Producto).

Entre las ventajas edi­to­ria­les de Plone en materia de ac­ce­si­bi­li­dad se incluyen:

• Es­tru­c­tu­ras se­má­n­ti­ca­me­n­te claras: la or­ga­ni­za­ción de los co­n­te­ni­dos sigue es­tri­c­ta­me­n­te los es­tá­n­da­res de HTML5.
• Gestión de flujos de trabajo: los co­n­te­ni­dos pueden revisarse en cuanto a co­n­fo­r­mi­dad antes de su pu­bli­ca­ción.
• Control de accesos: facilita el trabajo en equipo accesible con roles bien definidos.

Mediante plugins como el widget Plone All in One Ac­ce­s­si­bi­li­ty es posible integrar funciones adi­cio­na­les, como controles de tamaño de fuente, cambio de contraste o na­ve­ga­ción por teclado. De este modo, Plone resulta adecuado también para portales ac­ce­si­bles con procesos complejos.

papaya CMS

papaya CMS es un CMS modular, basado en XML y de­sa­rro­lla­do en Alemania, que se ca­ra­c­te­ri­za es­pe­cia­l­me­n­te por la clara se­pa­ra­ción entre contenido, diseño y lógica. Esta ar­qui­te­c­tu­ra permite controlar de forma granular salidas HTML se­má­n­ti­ca­me­n­te correctas y ac­ce­si­bles. papaya resulta es­pe­cia­l­me­n­te adecuado para proyectos complejos con altas exi­ge­n­cias edi­to­ria­les y canales de pu­bli­ca­ción cla­ra­me­n­te definidos.

• Es­tru­c­tu­ra­ción estricta: gracias a la se­pa­ra­ción entre contenido, diseño y lógica se generan páginas web se­má­n­ti­ca­me­n­te correctas.
• Pla­n­ti­llas y módulos ac­ce­si­bles: numerosos diseños y co­m­po­ne­n­tes están orie­n­ta­dos a las WCAG.
• Co­n­te­ni­dos mu­l­ti­li­n­gües: la clara gestión de datos facilita también la pu­bli­ca­ción accesible en varios idiomas.

Sin embargo, papaya CMS no ofrece plugins ni au­to­ma­ti­za­cio­nes es­pe­cí­fi­cas de ac­ce­si­bi­li­dad: el cu­m­pli­mie­n­to de los re­qui­si­tos depende en gran medida del co­no­ci­mie­n­to del equipo de de­sa­rro­llo y del diseño de las pla­n­ti­llas.

¿Cómo comprobar si un CMS es accesible?

La creación de co­n­te­ni­dos ac­ce­si­bles no termina con su in­tro­du­c­ción en el CMS. Una ve­ri­fi­ca­ción continua es esencial para detectar y corregir las barreras de uso a tiempo. Para probar la ac­ce­si­bi­li­dad de una página web, puedes recurrir tanto a he­rra­mie­n­tas au­to­ma­ti­za­das como a métodos manuales.

He­rra­mie­n­tas au­to­ma­ti­za­das

• axe DevTools: una extensión de navegador co­n­so­li­da­da de Deque Systems que detecta errores de ac­ce­si­bi­li­dad según los criterios de las WCAG y ofrece in­di­ca­cio­nes precisas para re­so­l­ve­r­los.
• WAVE (Web Ac­ce­s­si­bi­li­ty Eva­lua­tion Tool): visualiza las barreras di­re­c­ta­me­n­te en el navegador; ideal para revisar aspectos edi­to­ria­les como textos al­te­r­na­ti­vos y jerarquía de en­ca­be­za­dos.
• Google Li­gh­thou­se: pro­po­r­cio­na pu­n­tua­cio­nes de ac­ce­si­bi­li­dad y re­co­me­n­da­cio­nes concretas sobre es­tru­c­tu­ra, colores, usa­bi­li­dad y más; puede eje­cu­tar­se desde Google PageSpeed Insights, en las DevTools de Chrome, por línea de comandos o como módulo de Node.js.
• Evinced: utiliza in­te­li­ge­n­cia ar­ti­fi­cial y apre­n­di­za­je au­to­má­ti­co para ide­n­ti­fi­car barreras complejas; ofrece informes de­ta­lla­dos para de­sa­rro­lla­do­res e in­te­gra­cio­nes en entornos DevOps.

Pruebas manuales

Las he­rra­mie­n­tas au­to­ma­ti­za­das no detectan todos los problemas de ac­ce­si­bi­li­dad. Por ello, los si­guie­n­tes métodos manuales son im­pre­s­ci­n­di­bles:

• Na­ve­ga­ción con teclado: comprobar si la na­ve­ga­ción y el uso de la página son posibles mediante las teclas Tab y Mayús.; los in­di­ca­do­res de foco deben ser visibles y co­n­si­s­te­n­tes.
• Pruebas con lectores de pantalla: puedes usar NVDA (Windows), VoiceOver (macOS/iOS) o JAWS para comprobar la re­pro­du­c­ción de los co­n­te­ni­dos con lectores de pantalla; debes verificar la co­rre­c­ción semántica, los avisos de foco y el orden lógico de lectura.
• Co­m­pro­ba­ción de co­n­tra­s­tes y si­mu­la­ción de colores: he­rra­mie­n­tas como WebAIM Contrast Checker o Color Oracle ayudan a verificar co­n­tra­s­tes de color y simular de­fi­cie­n­cias visuales.
• Revisión de fo­r­mu­la­rios: comprueba que las etiquetas estén co­rre­c­ta­me­n­te vi­n­cu­la­das, que los mensajes de error sean claros, que el foco se gestione de manera adecuada y que los campos de entrada sean ac­ce­si­bles.
• In­s­pe­c­ción visual y pruebas de zoom: verifica si el diseño funciona con un nivel de zoom elevado, si los co­n­te­ni­dos se adaptan y si se evitan barras de de­s­pla­za­mie­n­to ho­ri­zo­n­ta­les.

Además, es re­co­me­n­da­ble disponer de una guía editorial de ac­ce­si­bi­li­dad y realizar fo­r­ma­cio­nes pe­rió­di­cas para reforzar las co­m­pe­te­n­cias del equipo a largo plazo.