Nueva actualización del documento WCAG2ICT del W3C de aplicación de las WCAG a las TIC no web (documentos y software)

WCAG2ICT del W3C. Aplicación de las WCAG a las TIC no web como documentos o software

Hoy, 21 de agosto de 2025, el W3C ha actualizado el documento conocido como WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies).

Es importante saber que la nueva actualización de la guía WCAG2ICT se ha coordinado con el trabajo de actualización de la norma EN 301 549, actualmente en estado "final draft" y cuya publicación se espera próximamente.

Por ello, muchos de los cambios respecto a la versión anterior tienen que ver con la armonización de algunas notas explicativas donde había orientaciones diferentes entre la EN 301 549 y las WCAG2ICT.

Recordemos que la EN 301 549 es la norma de accesibilidad que deben cumplir en Europa los productos y servicios TIC. La EN 301 549 engloba los criterios de conformidad de las WCAG más otros criterios adicionales. Las WCAG 2 se desarrollaron para la web, no para las TIC no web, por ello, abordar plenamente la accesibilidad de los documentos y el software no web implica requisitos adicionales a los incluidos en las WCAG 2 o la guía WCAG2ICT.

La versión publicada hoy abarca las WCAG 2.2 en el nivel A y AA, es decir, no incluye los requisitos AAA.

¿Qué es la guía WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies)?

La WCAG2ICT se publicó por primera vez en 2013. Es la guía informativa, no normativa, que ofrece orientación sobre cómo aplicar las WCAG 2 a las TIC no web, como los documentos o el software (una app móvil, una aplicación de escritorio, el software de un cajero automático o de una máquina expendedora de billetes, etc.).

La WCAG2ICT ha sido un recurso clave para la inclusión de las WCAG en la legislación y los estándares de accesibilidad de las TIC a nivel mundial, como la Section 508 o la EN 301 549.

En este sentido, la WCAG2ICT ha dado lugar a algunas excepciones incluidas en estos estándares, donde algunos de los criterios de las WCAG no se requieren en contextos no web. Por ejemplo, el capítulo 10 de la EN 301 549 contiene los requisitos para los documentos y el capítulo 11 los relativos al software, en ambos capítulos, ciertos criterios de las WCAG 2 no se incluyen porque se considera que no aplican (consultar ejemplo concreto).

Artículo relacionado: Requisitos de accesibilidad de la EN 301 549 aplicables a las apps móviles nativas

Sin embargo, la WCAG2ICT no especifica qué criterios pueden o deben aplicarse, -como sí se hace en la EN 301 549-; más bien indica, si los criterios se aplicaran, cómo se aplicarían.

El grueso del documento es la inclusión de los criterios A y AA de las WCAG 2.2. En cada uno se añade una sección sobre su aplicación a documentos o software no web, siendo evidente, a menudo, las dificultades para aplicar algunos criterios de conformidad de las WCAG 2.

El documento también se preocupa en adaptar la terminología "web" que subyace en las WCAG, así como en proporcionar información sobre cuándo los criterios de las WCAG presuponen la presencia de un agente de usuario y una tecnología de apoyo.

Ten en cuenta que el software no web puede que no disponga de un agente de usuario, de un software de plataforma con una API o servicios de accesibilidad; o puede que no tenga, o no admita, tecnologías de apoyo capaces de interactuar con la información programática.

Recordemos que, por ello, la EN 301 549 distingue entre "funcionalidad abierta" y "funcionalidad cerrada" (que impide a los usuarios conectar, instalar o utilizar tecnología de asistencia). También en la WCAG2ICT encontramos esta terminología.

¿Qué aporta y que no la WCAG2ICT?

Si bien las WCAG 2 se diseñaron con neutralidad tecnológica, presuponen la presencia de un "agente de usuario", como un navegador, un reproductor multimedia o una tecnología de apoyo, que se utiliza para acceder al contenido web.

La aplicación de las WCAG 2 a documentos y software en contextos no web requiere interpretar cómo cumplir la intención de cada criterio en estos diferentes contextos. Por eso, la mayor parte del trabajo del Grupo de Trabajo WCAG2ICT se centró en evaluar cómo se aplicaría cada criterio de las WCAG 2 en el contexto de las TIC no web.

El Grupo de Trabajo WCAG2ICT concluyó que la mayoría de los criterios de las WCAG 2 pueden aplicarse a documentos y software no web sin cambios o con cambios mínimos. Dado que muchos de los criterios A y AA no incluyen términos web, se aplican directamente tal como están escritos y como se describen en la documentación "Understanding WCAG 2.2".

Por ello, se decidió proporcionar únicamente notas adicionales a cada criterio, según se considera necesario, para comprender mejor la aplicación de los criterios de conformidad de WCAG a documentos y software no web.

En resumen, la WCAG2ICT proporciona:

Contexto general para la aplicación de las WCAG 2 a documentos y software no web.
Orientación sobre la aplicación de los principios, pautas y criterios de conformidad de WCAG 2 (niveles A y AA) a documentos y software no web.
Términos clave relacionados con la aplicación de las WCAG 2 a documentos y software no web.
Comentarios sobre las definiciones del glosario de las WCAG 2.
Comentarios sobre la conformidad.
Información de fondo sobre algunos temas, como el comentado sobre la "funcionalidad cerrada".

Por el contrario, la WCAG2ICT:

No crea ni ayuda a los desarrolladores a determinar qué disposiciones de las WCAG 2 (principios, pautas o criterios de conformidad) no se deben aplicar a documentos y software no web en general, o a alguna tecnología o producto en particular.
No propone cambios a las WCAG 2 ni a sus documentos de apoyo, aunque hay que indicar que el Grupo de Trabajo WCAG2ICT solicitó aclaraciones sobre la intención de varios criterios de cumplimiento, lo que condujo a aclaraciones en el documento "Understanding WCAG 2.2".
No aborda ninguna brecha entre los criterios de las WCAG y los requisitos de accesibilidad necesarios para abordar aspectos de las plataformas que no forman parte de la interfaz de usuario, los componentes de la interfaz de usuario como elementos individuales o el software con "funcionalidad cerrada" (aquella que impide a los usuarios conectar, instalar o utilizar tecnología de asistencia).
No aborda el hardware porque las WCAG no se aplican al hardware. Recordemos que la EN 301 549 sí tiene un capítulo dedicado al hardware (el capítulo 8).
No proporciona técnicas para implementar las WCAG en ningún tipo de tecnología, ya sea web o no web.
No es un estándar y no describe cómo las TIC no web deben cumplir con las WCAG.
No incorpora ni interpreta ninguna de las guías complementarias de WCAG.

Por tanto, la WCAG2ICT tiene muchas limitaciones. Se echa en falta un mayor nivel de detalle, técnicas concretas, ejemplos, etc., como esperamos que incluyan las WCAG 3.

Por otra parte, este documento por sí solo no es suficiente para garantizar la accesibilidad en documentos y software no web, puesto que no aborda requisitos de accesibilidad más allá de los contemplados por las WCAG, como sí lo hace la EN 301 549.

Adaptación de la terminología

Algunos criterios de las WCAG 2 están redactados para aplicarlos a "un conjunto de páginas web" o "varias páginas web", y dependen de que todas las páginas del conjunto compartan alguna característica o comportamiento.

Dado que la unidad de conformidad en las WCAG 2 es una sola página web, el grupo de trabajo acordó que la unidad de conformidad equivalente para documentos no web es un solo documento. Por lo tanto, una unidad de evaluación equivalente para un "conjunto de páginas web" sería un "conjunto de documentos".

Puesto que no es posible dividir inequívocamente el software no web, una sola "página web" se equiparó a un "programa de software" y un "conjunto de páginas web" se equiparó a un "conjunto de programas de software".

Un "documento" se define como un conjunto de contenido, como un archivo, un conjunto de archivos o contenido multimedia en streaming, que funciona como un único elemento en lugar de como una colección, que no forma parte de un software y que no incluye su propio agente de usuario. Y ponen como ejemplo un documento de tipo carta, una hoja de cálculo, un correo electrónico, un libro, una imagen, una presentación o una película.

Aclarado esto, hay dos términos que me parece relevante conocer: "accessibility services of platform software" y "closed functionality".

"accessibility services of platform software" son los servicios proporcionados por un sistema operativo, un agente de usuario u otro software de plataforma que permiten que los documentos o el software no web expongan información sobre la interfaz de usuario y sobre los eventos que ocurren a las tecnologías de apoyo (lectores de pantalla, acceso por voz, etc.) y a las funciones de accesibilidad del software.

Una nota aclara que estos servicios suelen proporcionarse en forma de API de accesibilidad y que proporcionan una comunicación bidireccional con las tecnologías de apoyo, incluida la exposición de la información sobre los objetos y eventos.

En cuanto a "closed functionality", tiene el mismo significado que en la EN 301 549, aquella que impide a los usuarios conectar, instalar o utilizar tecnología de asistencia, como puede ocurrir en los dispositivos IoT (Internet of Things), en un quiosco informativo o en una máquina expendedora de billetes.

Se pueden consultar todas las definiciones en el apartado de términos clave del documento.

Ejemplos concretos

Ejemplo: criterio 4.1.12 Espaciado del texto

Por ejemplo, veamos qué información se ofrece para el criterio "4.1.12 Espaciado del texto".

En primer lugar, se incluye literalmente el criterio 4.1.12 de las WCAG 2.2 con sus notas. A continuación, se añaden las notas adicionales para los documentos (1 nota) y el software no web (3 notas).

La nota relativa a los documentos indica que existen varios mecanismos que permiten a las personas modificar las propiedades de espaciado de texto de un documento implementado con un lenguaje de marcas.

Por ejemplo, una tecnología de libros electrónicos puede contar con un agente de usuario que permite anular los estilos de texto del documento. Cuando dicho mecanismo está disponible, el criterio exige que el contenido responda adecuadamente a él.

En las notas relativas al software no web se indica que:

Existen varios mecanismos que permiten a las personas modificar las propiedades de espaciado de texto del software implementado en un lenguaje de marcas. Por ejemplo, una aplicación de software puede proporcionar una función de "hoja de estilo personal" para modificar la apariencia de la interfaz de usuario.
Este criterio no implica que el software no web deba implementar sus propios mecanismos para que las personas puedan configurar el espaciado de texto; sin embargo, cuando dicho mecanismo está disponible, el criterio de éxito exige que el contenido responda adecuadamente a él.
El "contenido implementado mediante un lenguaje de marcas" incluye partes del software que utilizan el marcado internamente para definir una interfaz de usuario. Entre los ejemplos de lenguajes de marcas que se utilizan internamente para definir una interfaz de usuario se incluyen, entre otros: HTML (por ejemplo, en aplicaciones Electron o vistas web de aplicaciones iOS), XAML, XML (por ejemplo, en diseños de aplicaciones Android) y XUL.

Ejemplo: criterio 3.2.3 Navegación consistente

Se modifica la redacción del criterio "3.2.3 Navegación consistente" según los cambios terminológicos que hemos comentado:

"3.2.3 Navegación consistente: los mecanismos de navegación que se repiten en varios documentos no web dentro de un conjunto de documentos no web, o en varios programas de software dentro de un conjunto de programas de software, ocurren en el mismo orden relativo cada vez que se repiten, a menos que el usuario inicie un cambio."

En la nota 3 se indica que los conjuntos de software que cumplen con esta definición parecen ser extremadamente raros, por esa razón, añado yo, en la EN 301 549 se ha eliminado este criterio del capítulo 11 relativo al software.