Mostrando entradas con la etiqueta accesibilidad software. Mostrar todas las entradas
Mostrando entradas con la etiqueta accesibilidad software. Mostrar todas las entradas

viernes, 13 de febrero de 2026

Reseña de la herramienta Silktide para monitorizar la accesibilidad en sitios web

Captura de pantalla de la herramienta Silktide. Muestra la página Objetivos. El listado de objetivos tiene las columnas: Nombre, Objetivo, Valor, Fecha del objetivo, Tendencia, Progreso y Asignados.

El objetivo de este artículo es reseñar la herramienta Silktide. La reseña es imparcial e independiente, puesto que no he recibido ninguna compensación por realizarla.

Silktide es una herramienta de evaluación y gestión de calidad web que incluye, entre otros aspectos, pruebas de accesibilidad.

Ofrece:

  • Extensión de navegador con diversas herramientas gratuitas, como la validación de accesibilidad de la página que estás visitando. Para los usuarios de pago incluye otro tipo de validaciones adicionales como, por ejemplo, la revisión de la ortografía y la gramática de la página o la localización de sus enlaces rotos.
  • Plataforma SaaS de pago que permite monitorizar sitios completos.

Por tanto, es una herramienta similar a otras como SiteImprove, herramienta que reseñé hace años en Siteimprove, herramienta para el análisis programado de nuestro portal. El objetivo del artículo no es una comparativa de herramientas, por lo que me centraré en describir sus funcionalidades, sus puntos fuertes y su margen de mejora.

Índice

Silktide, extensión de Chrome y Edge

La extensión Silktide es gratuita, está disponible en inglés para los navegadores Chrome y Edge y permite revisar una página de forma inmediata.

Este tipo de herramientas no sustituyen a una auditoría manual de accesibilidad, pero pueden ser muy útiles durante las mismas y en las revisiones preliminares.

En este sentido, la extensión de navegador Silktide me parece que es una herramienta útil y completa, entre mis favoritas, con ANDI o ARC Toolkit.

La extensión se despliega en la zona derecha de la pantalla y tiene las herramientas que voy a explicar a continuación, comentando cuáles son sus puntos fuertes y su margen de mejora.

Código y tipo de visualización

La herramienta analiza el código fuente resultante tras ejecutar los scripts, es decir, el equivalente a "Inspeccionar". Permite visualizar este HTML y localizar los elementos referenciados, aunque no lo hace mediante la herramienta para desarrolladores, que en el trabajo diario de auditoría me resulta más cómoda. Aun así, nada impide tener ambas abiertas de forma simultánea.

Captura de pantalla de la extensión Silktide en el margen derecho de una página. Se resaltan las opciones para ver el código HTML y para visualizarla simulada con diferentes dispositivos móviles.

Extensión Silktide. Opciones de mostrar HTML y visualización en dispositivos móviles.

También tiene integrada la simulación de visualización en un dispositivo móvil, en concreto, ofrece las opciones: Desktop, MacBook Air, iPad Mini, iPad Air 4, iPad Pro 11, iPhone 5 e iPhone X.

Herramientas

La extensión presenta las siguientes herramientas:

Captura de pantalla de la extensión Silktide. Muestra el listado de herramientas que se enumeran y explican tras la imagen.

Extensión Silktide. Herramientas.

  • Color Contrast: la herramienta permite validar el contraste mediante la inclusión del código de color o mediante cuentagotas. Usa el algoritmo de las WCAG, pero no incluye como alternativa el Accessible Perceptual Contrast Algorithm (APCA).
  • Alt text: listado de todas las imágenes y su texto alternativo. Se puede filtrar por las imágenes con "alt", las imágenes decorativas (con "alt" vacío) o las imágenes sin "alt". Es una lástima que no tenga en cuenta los <svg>, que tendrás que buscarlos manualmente.
  • Screen reader: opción que no solemos encontrar en otros validadores. ANDI, por ejemplo, indica lo que anunciará el lector de pantalla, pero Silktide lo verbaliza, además de mostrarlo en formato texto. No sustituye, por supuesto, al acceso con un lector de pantalla, como NVDA, JAWS o VoiceOver, pero puede ser útil a muchas personas para una validación rápida.

    Puedes usarlo con la opción de página en negro, para acceder "a ciegas". También puedes elegir diferentes voces y velocidad de habla, y tienes disponibles varios atajos. La pega es que el anuncio de los elementos (no del texto) es en inglés. En cada verbalización te avisa de si ha encontrado un error, como un enlace sin un texto que pueda anunciar.

    Lector de pantalla de la herramienta Silktide. Tiene botones de siguiente, anterior, espacio y ESC. Se muestra la verbalización del lector indicando los errores encontrados, como imagen sin texto alternativo. Hay un botón de configuración.

    Extensión Silktide. Screen Reader integrado para validación.

  • Focus order: muestra el orden en el que los elementos recibirán el foco.
  • Landmark: para consultar las regiones en las que se estructura la página (navigation, search, main, etc.).
  • Links: listado de páginas a las que se enlaza desde esta.
  • Headings: jerarquía de encabezados.
  • Impaired vision: simulador de problemas de visión, como cataratas, miopía, visión doble, pérdida de visión periférica o pérdida de visión central.
  • Color blindness: simulador de diferentes problemas de ceguera al color.
  • Dyslexia: esta herramienta desordena y cambia las letras; no es así como percibe exactamente el texto una persona con dislexia, pero te ayuda a ponerte en su lugar.
  • Learn about accessibility: acceso a documentación sobre accesibilidad.
  • View full website report: acceso a la herramienta de monitorización para usuarios registrados.

Validaciones

La herramienta incluye diferentes tipos de validaciones. La validación de accesibilidad es gratuita, pero las demás solo están disponibles si eres usuario registrado de la plataforma SaaS de pago.

Captura de la extensión Silktide. Muestra el resumen de 5 tipos de revisiones: Content, Accessibility, Marketing, UX, Privacy.

Extensión Silktide. Tipos de validaciones.

La revisión de accesibilidad es una validación automática según los estándares WCAG 2.0, 2.1 y 2.2 en sus niveles A, AA y AAA. Los resultados se pueden filtrar por aquellos que la página pasa, falla o que necesitan una verificación manual.

Como todos los validadores automáticos, valida solo ciertos criterios y solo ciertas técnicas. Recuerda que siempre deben comprobarse manualmente los resultados, porque pueden darse falsos positivos o falsos negativos.

Por ejemplo, en esta herramienta he detectado falsos negativos en el criterio "2.4.11 Focus not obscured", que se da por pasado (no como pendiente de revisión manual) en páginas que, sin embargo, tienen un menú fijo que tapa el foco de teclado.

Los demás tipos de validaciones son:

  • Content: revisa, entre otras cosas:
    • faltas de ortografía y gramática;
    • número de palabras en la página;
    • enlaces rotos;
    • si se explica qué enlaces se abren en ventana nueva;
    • el meta description;
  • UX: analiza, entre otros aspectos:
    • si la página tiene desplazamiento horizontal en pantallas pequeñas;
    • si el texto se leerá de forma cómoda en pantallas pequeñas (el texto con un tamaño de fuente por debajo de 11px se marca como fallido);
    • imágenes que no se cargan;
    • errores o advertencias de JavaScript;
    • la presencia de un favicon.
  • Privacy: revisa, entre otros aspectos:
    • si se tiene aviso de cookies;
    • si se tiene política de privacidad;
    • las tecnologías utilizadas que pueden ver, controlar o comprometer la privacidad de los visitantes, para que se revise que están cubiertas por la política de privacidad.
  • Marketing: algunas validaciones son comunes a "Content" y otras específicas, como si hay un sitemap o si se está usando una herramienta de analítica.

Silktide, monitorización de sitios web

Silktide también dispone de una plataforma SaaS de pago que permite monitorizar sitios completos y que está disponible en español. A continuación, explico sus principales funcionalidades, así como sus puntos fuertes y su margen de mejora.

Pantalla principal y menú

En la pantalla principal de la aplicación tenemos el acceso a nuestros sitios web:

Captura de pantalla de la herramienta Silktide. Muestra la página Sitios web con el listado de sitios web. A continuación de la imagen se listan las opciones de menú disponibles.

Silktide. Pantalla principal de la aplicación.

Las opciones del menú principal son:

  • Sitios web, para volver a la página principal.
  • Inspeccionar, para validar una página o PDF concretos.
  • Tareas, acceso al listado de tareas con las personas asignadas y su prioridad; al listado de anotaciones y al listado de objetivos, de los que hablo más adelante.
  • Academia, con diversos recursos.
  • Notificaciones.
  • Perfil.

Página principal de un sitio web y menú

Cuando accedes a uno de tus sitios web, tienes un dashboard con información por defecto, pero también existe la posibilidad de crear dashboards personalizados.

Captura de pantalla de la herramienta Silktide. Muestra la página inicial de un sitio web con el resumen por tipo de validación y la tabla con la lista de comprobaciones.

Silktide. Pantalla principal de un sitio web.

En el menú tienes acceso a los diferentes tipos de validaciones que hemos visto en la extensión: contenido, accesibilidad, marketing, experiencia de usuario, privacidad y políticas. Además, tienes el acceso al listado de anotaciones, de objetivos y al inventario, que voy a explicar a continuación.

Inventario

El inventario incluye el listado de:

  • páginas
  • PDF
  • idiomas
  • enlaces
  • tecnologías
  • favicons del sitio

En el listado de páginas me resulta muy útil que se incluya la captura de pantalla de todas las páginas en escritorio y móvil. Sin embargo, echo en falta que no se listen también los archivos multimedia, JS y CSS.

Anotaciones, vista de página e integración de la validación manual

Las anotaciones se añaden desde la vista de página, donde tienes la opción de ir pasando por los diferentes problemas detectados en ella. Esta vista también dispone de otras funcionalidades:

  • simulaciones (dislexia, problemas de visión, motor de búsqueda)
  • ocultar partes de la página
  • consultar su información: orden del foco, enlaces, secciones, encabezados, cabeceras HTTP, etc.
  • reevaluar
  • aprobar la página
  • incluir comentarios

Me centro en las anotaciones, que me parecieron una buena idea, pensando en aquellas que realizas cuando revisas manualmente una página y reportas un error.

Cuando creas una anotación, le asignas una persona, le das una prioridad e indicas su estado.

Captura de pantalla de la herramienta Silktide. Muestra la página de análisis de una página web. Se está creando una anotación relativa a una zona de la página. A continuación de la imagen se listan las opciones de las que dispone.

Silktide. Alta de una anotación.

Sin embargo, las anotaciones no se integran en las tareas y el listado de comprobaciones, ni pueden asociarse a un criterio de las WCAG. Solo se visualizan desde el menú Anotaciones.

Por otro lado, tenemos el listado de Comprobaciones, por una parte el listado de comprobaciones automáticas y, por otra, el listado de las comprobaciones que necesita verificación manual (denominado "Controles asistidos"). Es otra manera de gestionar los errores que detectas en la revisión manual, pero estás limitada al listado que se muestra:

Captura de pantalla de la herramienta Silktide. Muestra la página Comprobaciones. Hay una pestaña para las comprobaciones automáticas y otra para los controles asistidos.

Silktide. Comprobaciones > Controles asistidos.

Puedes asignar una de las comprobaciones asistidas a una persona y poner comentarios a nivel de comprobación y de página.

En resumen, creo que la integración de los resultados detallados de una auditoría manual podría mejorarse mucho para resultar más práctico y flexible.

Objetivos

Los objetivos son bastante útiles. Los creas indicando el sitio web, la fecha en la que quieres alcanzar el objetivo, las personas asignadas y la métrica del objetivo, escogida de un listado muy extenso.

Captura de pantalla de la herramienta Silktide. Muestra la página Objetivos. El listado de objetivos tiene las columnas: Nombre, Objetivo, Valor, Fecha del objetivo, Tendencia, Progreso y Asignados.

Silktide. Objetivos

Listado de tareas

El listado de tareas se puede filtrar por sitio web, persona asignada, etiquetas o categoría. Por ejemplo, en accesibilidad se puede filtrar por nivel, tipo de discapacidad, PDF o accesibilidad móvil:

Captura de pantalla de la herramienta Silktide. Muestra la página Listado de tareas. El listado de tareas se puede filtrar por persona asignada, sitio web, categoría o etiquetas. Se muestra las opciones de filtro por la categoría accesibilidad, que incluye filtro por nivel, por tipo de discapacidad o por accesibilidad móvil.

Silktide. Tareas

Sería muy interesante que las tareas estuvieran categorizadas para permitir los siguientes filtros, que no están disponibles actualmente:

  • tipos de contenidos: formularios, enlaces, etc.
  • perfil profesional: diseñador, desarrollador, editor de contenido, etc.
  • pauta y criterio de las WCAG (ahora solo se puede usar para ello el buscador).

Página principal de accesibilidad

La página inicial de "Accesibilidad" muestra una visión global de las puntuaciones por nivel y a lo largo del tiempo, de los problemas comunes y de los problemas por tipo de discapacidad (visual, auditiva, motora y cognitiva).

Captura de pantalla de la herramienta Silktide. Muestra la página principal de Accesibilidad. El dashboard tiene los porcentajes por nivel; los errores por tipo de discapacidad; los tipos de problemas más habituales y otras estadísticas como el promedio de errores por página.

Silktide. Pantalla principal de Accesibilidad

Según el sitio, podría mostrarse también el "Benchmark", es decir, la puntuación comparada con webs del mismo sector. El "Silktide Index" es una tabla de clasificación que muestra cómo se comparan las organizaciones de diversas industrias en términos de accesibilidad. Puedes consultar más en "¿Qué es el índice Silktide?" o acceder a la web "Compare websites for accessibility" para probarlo.

Index Silktide de la web de la Universidad de Oxford. Muestra una comparativa con 125 páginas del mismo sector, con una puntuación de 76%. Incluye diferentes recomendaciones de mejora.

Página de resultado de Silktide Index

Las opciones de menú del apartado "Accesibilidad" son:

  • Listado de comprobaciones con acceso a las instancias.
  • Listado de páginas con su puntuación.
  • Listado de PDF y su puntuación.
  • Móvil, con el listado de páginas no responsivas.
  • Directrices, con el listado de criterios de las WCAG (no se incluyen los criterios específicos de la EN301549) y el número de errores asociados a cada uno.
    Captura de pantalla de la herramienta Silktide. Muestra la página Directrices con el listado de todos los criterios de las WCAG y el número de errores asociados a cada uno.

    Silktide. Directrices

    Aprovecho para recordar que no se puede usar este tipo de información para cumplimentar un informe IRA o un ACR (Accessibility Conformance Report), ya que es necesario para ello una evaluación manual experta de todos los criterios.

  • Auditorías manuales, para contratar una revisión manual.
  • Decisiones: para revisar o deshacer las decisiones tomadas, como qué problemas se ignoraron o se aprobaron.

Cada tipo de problema encontrado tiene su página, con la prioridad, el progreso, las personas asignadas, las estadísticas, el historial y la posibilidad de comentar o de ignorar la comprobación.

Captura de pantalla de la herramienta Silktide. Muestra la página de una comprobación, en concreto, la de páginas sin un título apropiado. Incluye una estadística con el número de incidencias a lo largo del tiempo. También un listado de páginas con este error, y el acceso a la discusión y al historial.

Silktide. Página de una comprobación

Otros tipos de validaciones

Además de la validación de accesibilidad, tenemos las validaciones que he comentado en la extensión:

  • Contenido: incluye el análisis de ortografía y gramática, disponible en español y catalán entre otros idiomas (idiomas soportados por Silktide); la legibilidad del texto (si es fácil de entender), pero solo disponible en inglés; el listado de enlaces rotos; la optimización de imágenes y comprobaciones relacionadas con el SEO.
  • Marketing: validaciones relacionadas con las palabras clave, los anuncios, la cantidad de información o la optimización.
  • Experiencia de usuario: validaciones relacionadas con el acceso móvil, el flujo de usuarios, los fallos de funcionalidad (imágenes o CSS que faltan, errores JS, etc.), detecta si el sitio está caído, o los Web Vitals de Google.

Hay dos tipos de validaciones adicionales que no están en la extensión.

  • Políticas, esto es, las validaciones adicionales aplicadas. En la configuración hay algunas políticas predefinidas que se pueden añadir a la revisión, por ejemplo, revisar el uso de mayúsculas o de palabras específicas. También se pueden crear políticas personalizadas.
  • Privacidad, con el inventario de elementos relacionados con la privacidad: números de teléfono y correos electrónicos incluidos en el portal, muy útil en sitios grandes gubernamentales; así como el listado de cookies, de tecnologías y de campos de formulario del portal.

Configuración

La herramienta se puede integrar con diferentes CMS (consultar lista completa), como Drupal, AEM, WordPress, Liferay, entre otros muchos. Además, permite integraciones personalizadas a través de API.

A nivel de configuración, se puede indicar cada cuántos días se reevalúa el sitio y hay reglas para personalizar qué páginas del sitio se incluyen o no.

También se pueden crear agrupaciones de páginas (secciones), que actúan como sitios web por sí mismas, esto es muy útil en sitios muy grandes.

Ayuda y soporte

La aplicación tiene soporte 24/7 ilimitado mediante un chat para hablar con un agente IA o con una persona real, y dispones de un teléfono y el correo electrónico de tu gestor asignado.

La herramienta dispone de ayuda relacionada con la propia herramienta y con la accesibilidad. En relación con la ayuda relativa a la accesibilidad, tienes diferentes recursos, pero también ayuda contextual:

  • En las comprobaciones hay explicaciones sobre el criterio evaluado, a veces acompañadas de un vídeo de apoyo.
  • En la página del error tienes la opción "Preguntar a la IA", que hoy en día es casi imprescindible:
Captura de pantalla de la herramienta Silktide. Muestra la página de un error con la ayuda IA desplegada. Hay tres niveles de explicación: no técnico, moderadamente técnico y desarrollador web.

Silktide. Página de un error con chat de ayuda

En las respuestas de la IA me ha gustado que tienes un desplegable para seleccionar que la explicación sea: no técnica, moderadamente técnica o para desarrolladores web; pero me ha parecido un poco lenta. Tal y como esperarías, te ofrece diferentes alternativas y se ofrece a darte el código que lo arregle.

Recuerda que siempre debes verificar si es un falso negativo o positivo y supervisar el código que te ofrece. Son una ayuda muy útil, no un sustituto.

Por ejemplo, en un error de dos enlaces con el mismo texto en los destacados de noticias (el típico "leer más"). Me ha explicado bien el error y las posibles soluciones: mejorar el texto de enlace; mejorar el texto de enlace, pero ocultar la parte añadida; o usar aria-label. También me ha advertido que usar el title para la aclaración no sería fiable.

Todo muy correcto, la explicación y el código. Pero no me ha ofrecido la opción de aria-labelledby, mucho más adecuada que la de aria-label en este contexto.

Informes

Uno de los aspectos más débiles de la herramienta es que no genera informes, solo se permite la exportación de las tablas en formato CSV.

Usabilidad y accesibilidad de la herramienta

La herramienta me ha resultado, personalmente y para mi perfil, intuitiva de usar.

No he realizado un análisis exhaustivo de accesibilidad de la herramienta, y esta tampoco dispone de una declaración de conformidad o ACR. Sí puedo decir que, en general, se nota que se ha tenido en cuenta, aunque no está exenta de problemas.

Por ejemplo, me resultó cómodo acceder con el teclado, pero tuve algún problema con el lector de pantalla. Hay un error muy sencillo de solucionar, pero muy molesto con el lector, y es que la definición del idioma a nivel de página es el inglés y, por tanto, el lector me lee por defecto el texto español con fonética inglesa.

También tuve problemas con las notificaciones toast, que no están etiquetadas como mensajes de estado con ARIA.

Precio

La extensión es gratuita, pero las validaciones adicionales son solo para los usuarios registrados de la plataforma SaaS, de pago.

El precio de la plataforma de monitorización depende de diferentes factores, no puedo dar cifras concretas porque no son públicas, es necesario solicitar un presupuesto, pero son similares al de otras herramientas disponibles en el mercado.

Conclusiones

Extensión de navegador

Los puntos fuertes de la herramienta, a mi parecer, son:

  • Interfaz clara y cómoda.
  • Útil para revisiones rápidas, apoyo en auditorías manuales y formación.
  • Conjunto amplio de herramientas y simuladores de discapacidad, que incluye un lector de pantalla, poco habitual en estas herramientas.
  • Versión gratuita de la herramienta.
  • Validaciones complementarias útiles, como la revisión de ortografía, el número de palabras en la página o los enlaces rotos, aunque recuerdo que estas son opciones de pago.

Los puntos a mejorar según mi criterio serían:

  • Disponer de una versión en español, incluida la simulación del lector de pantalla, que actualmente anuncia los elementos en inglés.
  • Incluir los SVG en la validación de las imágenes.
  • Revisión de los falsos negativos (extensión y plataforma de monitorización) en criterios que se dan por validados.

Sería muy interesante, desde mi punto de vista:

  • Que se incluyera el algoritmo APCA como una opción en el validador de contraste.
  • Usar la herramienta para desarrolladores para mostrar el código HTML, en vez de una ventana independiente.
  • Herramienta para listar determinadas etiquetas HTML usadas en la página, a elegir de un listado (br, table, ul, svg, etc.) Esta opción la tiene ARC Toolkit y es muy útil.

Plataforma de monitorización

Los puntos fuertes de la herramienta, a mi parecer, son:

  • Monitorización continua de sitios completos, con visión global y evolución en el tiempo.
  • Más allá de la monitorización de accesibilidad, opciones de gestión de calidad útiles y complementarias a la accesibilidad y las auditorías, como la revisión ortográfica, los inventarios o el listado de capturas de pantalla.
  • Soporte de gestión de tareas, objetivos y seguimiento.
  • Integración con el CMS y opciones de configuración de secciones para sitios grandes.
  • Creación de políticas personalizadas.
  • El soporte y la ayuda IA integrada de calidad, con respuesta personalizada según perfil.

Los puntos críticos a mejorar según mi criterio serían:

  • Incluir la generación y personalización de informes.
  • Corregir la accesibilidad de la herramienta y tener disponible un ACR actualizado.
  • Mejorar la gestión de anotaciones y controles asistidos para hacer más efectiva la gestión de la validación manual, que al final es imprescindible y más importante en la práctica que la automática.

Sería muy interesante, desde mi punto de vista:

  • Disponer de más tipos de categorización y filtro de los problemas y tareas, como tipo de contenidos (formularios, enlaces, etc.), perfil profesional (diseñador, desarrollador, editor de contenido), filtro concreto por principio, pauta y criterio.
  • Incluir en los inventarios el contenido multimedia, CSS y JS.
  • Añadir los requisitos adicionales de la EN 301 549, que es el estándar a cumplir en Europa.

Agradecimientos

La reseña es imparcial e independiente, puesto que no he recibido ninguna compensación por realizarla, pero agradezco a Silktide la resolución por su parte de todas las dudas que me han surgido mientras trabajaba con la herramienta para poder elaborar esta reseña.

Este artículo se ha elaborado y redactado sin el uso de herramientas IA, solo se han usado para la revisión final de la ortografía.

Artículos relacionados

jueves, 21 de agosto de 2025

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.

Índice

¿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 las 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 las 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, como sí hace la EN 301 549.
  • 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 plantea 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), como sí hace la EN 301 549.
  • 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 las 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.

Relación entre la WCAG2ICT y la WCAG2Mobile (Guidance on Applying WCAG 2.2 to Mobile Applications) del W3C

El 6 de mayo de 2025 se publicó el primer borrador de la nota del W3C "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)", que actualmente está en estado borrador.

La WCAG2Mobile describe cómo aplicar las WCAG 2.2 específicamente a las aplicaciones móviles. El grupo de trabajo lo contempla como una evolución del documento "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile" de 2015 (aunque con un borrador de 2018).

La WCAG2ICT y la WCAG2Mobile son documentos informativos, no normativos, tienen una estructura similar y las elaboran grupos de trabajo diferentes.

En la guía WCAG2Mobile (borrador mayo 2025) se incluye el criterio WCAG, la interpretación WCAG2ICT y las notas propias:

En la WCAG2Mobile (borrador mayo 2025) se incluye el criterio WCAG, la interpretación WCAG2ICT y las notas propias

Captura del criterio 2.4.3 de la WCAG2Mobile (borrador mayo 2025)

En cuanto al alcance, las dos guías abordan las WCAG 2.2 (nivel A y AA), pero la WCAG2ICT aclara cuándo y cómo se pueden aplicar los criterios de conformidad de las WCAG a documentos y software no web (donde se incluyen las aplicaciones móviles); mientras que la WCAG2Mobile limita el alcance solo a las aplicaciones móviles. Esto puede hacer que colisionen en algunos aspectos.

Por ejemplo, la WCAG2Mobile (borrador mayo 2025) indica que, 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 aplicaciones móviles sería una sola pantalla dentro de la aplicación. Por consiguiente, una unidad de evaluación equivalente para un "conjunto de páginas web" sería un "conjunto de pantallas", no un "conjunto de software", que es lo que interpreta la WCAG2ICT (consultar apartado "Adaptación de la terminología" de este documento).

“Contenido” y “agente de usuario” son términos del glosario WCAG2ICT que deben interpretarse de manera significativamente diferente cuando se aplican a aplicaciones móviles.

Los términos del glosario «documento» y «software» en WCAG2ICT se sustituyen por los términos definidos «pantalla» y «vista». Los términos del glosario «conjunto de páginas web», «conjunto de documentos» y «conjunto de programas de software» se sustituyen por el término definido «conjunto de pantallas».

El término «servicios de accesibilidad del software de plataforma», introducido por WCAG2ICT, se ha modificado para reflejar su uso diferenciado en aplicaciones móviles. Además, «funcionalidad cerrada» tiene un significado diferente en el contexto de las aplicaciones móviles.

WCAG2Mobile (borrador mayo 2025)

La WCAG2Mobile está en estado borrador, por lo que todo esto podría cambiar. Cuando se publique la versión final haré un artículo específico sobre ella.

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.

Enlaces relevantes

Artículos relacionados

Artículo redactado manualmente sin herramientas IA, salvo para la revisión ortográfica

Imagen inicial generada con ChatGPT.

martes, 23 de junio de 2020

Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Validaciones y fiabilidad (Parte II)

Resultado del validador de accesibilidad OAW. La página tiene errores en todas las validaciones.

Este artículo es la continuación de Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Presentación, Instalación y uso, Metodología e Informes (Parte I). En esta segunda parte me voy a centrar en las validaciones concretas que realiza el validador y su fiabilidad.

Os recomiendo que leáis la primera parte del artículo, donde explico la función que hace el Rastreador OAW en la monitorización y evaluación de los portales del sector público en España; cómo instalarlo y usarlo, ahora que ya no es de uso exclusivo para la Administración Pública; la metodología que utiliza, que salió a debate público; y el tipo de informes que genera.

Estructura del artículo

Como vimos, la validación del Rastreador OAW se articula en:

  • 14 indicadores de nivel A
  • 6 indicadores de nivel AA

Este artículo se estructura en un apartado para cada indicador, donde enumero:

  • El criterio o criterios de las WCAG 2.1 / EN 301 549:2019 con los que se corresponde.
  • Las validaciones que realiza en cada indicador.
  • La fiabilidad de estas validaciones:
    • falsos positivos
    • falsos negativos
    • otros aspectos a tener en cuenta, por ejemplo, si sus validaciones son más estrictas o específicas que las de las WCAG 2.1.

Hay que tener en cuenta que un mismo criterio de las WCAG 2.1 / EN 301 549:2019 puede implicar una o varias comprobaciones, y que un mismo criterio se puede cumplir con diferentes técnicas, pero no todas pueden evaluarse automáticamente.

Por ello, no hay que sorprenderse si señalo que diferentes indicadores se corresponden con un mismo criterio de las WCAG 2.1 / EN 301 549:2019. Por ejemplo, hay varios indicadores diferentes que se corresponden con distintas validaciones que hay que hacer en el criterio 1.3.1 de las WCAG 2.1.

Por la misma razón, que un indicador se asocie a un criterio no quiere decir que abarque todas las comprobaciones que deben hacerse en dicho criterio. Por ejemplo, que un indicador esté asociado al criterio 2.4.4, no significa que se realicen todas comprobaciones asociadas a este criterio, puesto que puede haber algunas que no sea posible realizar automáticamente.

Por último, que el validador evalúe un criterio, tampoco implica que se esté evaluando en base a todas las técnicas permitidas, por ejemplo, el criterio 2.4.5 Múltiples vías (AA) puede cumplirse con la combinación de diferentes técnicas, pero el validador solo comprueba dos de ellas.

Estas observaciones aplican a cualquier validador automático. No hay que olvidar que son meras herramientas de ayuda y que no pueden sustituir a una evaluación manual, sino que solo reportan un número reducido de las barreras de accesibilidad de la página, que no tienen por qué ser las más importantes.

Metodología

El objetivo de este artículo es que sirva de guía rápida de consulta. Para más detalles os remito a la metodología de evaluación de la herramienta, que es pública: Metodología para el seguimiento simplificado del Observatorio de accesibilidad (PDF, 1.62 MB)

Aunque hace tiempo que estoy familiarizada con sus validaciones e informes, la posibilidad de instalarlo en local me ha permitido poner a prueba de una manera más sistemática todas sus validaciones.

Para evaluar la fiabilidad de las validaciones:

  • He creado una página de prueba con todos los posibles errores que valida la herramienta.
  • He validado la página con el validador instalado en local (versión instalada el 30 de mayo de 2020).
  • No he realizado ningún cambio en el validador que afecte a las validaciones. Solo he modificado que guarde el informe en local, en vez de enviarlo por correo.
  • He validado la página por código y después por URL.
  • He validado con la opción "Conforme a la metodología del Observatorio de Accesibilidad, basada en la UNE-EN 301549:2019".

Pongo a vuestra disposición la página de prueba y los informes del validador (ZIP, 467 KB) por si queréis contrastar resultados. Este zip contiene:

  • Página de prueba. Ten en cuenta que no es una página preparada para ser visualizada, sino para poner a prueba el validador. He añadido múltiples comentarios en el código con el resultado del validador para cada elemento.
  • Informe resultante al validar la página por código.
  • Informe resultante al validar la página por URL. Aunque la página validada es la misma, hay un error que detecta en este informe, pero no en el anterior.

Podéis dejar en los comentarios del artículo cualquier observación.

Índice de indicadores

1.1 Existencia de alternativas textuales (A)

Criterio de las WCAG 2.1: 1.1.1 (A)

Validaciones

  • Los elementos AREA deben tener un texto alternativo con alt, aria-label o aria-labelledby.
  • Los INPUT de tipo image deben tener un texto alternativo con alt, aria-label o aria-labelledby.
  • Los elementos APPLET deben tener un texto alternativo con alt junto con contenido textual dentro de las etiquetas de apertura y de cierre del elemento APPLET; o bien mediante aria-label o aria-labelledby.
  • El texto alternativo de las imágenes no puede tener el nombre de la imagen (*.jpg, *.jpeg, *.gif, *.png, *.bmp.) o un texto de relleno ("imagen", "foto"... ; o patrones similares en la misma página como “Pic1”, “Pic2”, “0001”, “0002”). 
  • Todas las imágenes deben tener atributo alt o atributo aria-label o aria-labelledby, a no ser que tengan asignado el rol ARIA role="presentation".
  • Si el alt está vacío, las imágenes no pueden tener aria-label, aria-labelledby, title (a no ser que esté vacío); y si tienen un rol será role="presentation".
  • Se comprueba que las imágenes con un alto y/o ancho igual o inferior a 2px están marcadas como imágenes decorativas, es decir, tienen el texto alternativo vacío; no tienen atributo title (o está vacío); y carecen de atributo role (o bien es role="presentation" si no tiene atributo alt).
  • Si la imagen tiene longdesc debe ser a una página válida.
  • Las imágenes no pueden tener alternativas textuales (en los atributos alt, aria-label o aria-labelledby) cuyo contenido textual sea superior a 150 caracteres pues, en ese caso, lo que requieren son descripciones detalladas (por ejemplo, con los atributos longdesc o aria-describedby).
  • El valor de los atributos aria-describedby deben ser identificadores reales de otros elementos existentes en la página que tengan contenido textual. Como en el atributo aria-describedby se pueden indicar varios identificadores (id), es suficiente con que solo uno de ellos exista y tenga contenido.

Falsos negativos

  • Si tenemos un MAP con un AREA activa, y esta tiene alt="", el validador da error. Sin embargo, si el AREA activa no tiene alt, no da error, esto sería un falso negativo.
  • Aunque la metodología dice que se validan los input type="image", si incluyes uno sin alt o con alt vacío, el validador no da error, esto sería un falso negativo.
  • Aunque la metodología dice que se validan los applet, si incluyes un applet, un object o un embed sin alternativa y sin texto entre sus etiquetas de apertura y cierre, el validador no da error, esto sería un falso negativo.
  • El validador reconoce que un texto alternativo como <img src="hola.jpg" alt="hola.jpg" /> es incorrecto y da error. Sin embargo, si tenemos varias imágenes con un texto alternativo que sigue el siguiente patrón: <img src="hola.jpg" alt="imagen1" /> <img src="hola.jpg" alt="imagen2" />, el validador no reconoce el patrón y no da error, lo cual sería un falso negativo.
  • He usado una imagen con el atributo aria-describedby="desc1". A pesar de que el id "desc1" no existe en la página, el validador no ha dado error, lo cual sería un falso negativo.

Falso positivo

  • Una de las novedades de WAI-ARIA 1.1 (recomendación desde 2017) es el rol role="none". Este rol es equivalente a role="presentation", al que viene a sustituir. Puedes consultar mi artículo: Novedades WAI-ARIA 1.1.

    El validador no da error con el código <img src="icono.jpg" alt="" role="presentation"/>, porque reconoce de manera adecuada que es una imagen decorativa. Sin embargo, sí da error con el código <img src="icono.jpg" alt="" role="none" />, porque no reconoce el rol role="none". Esto es un falso positivo.

    En general, el validador da error en todas las validaciones que incluyen role="presentation si se usa en su lugar role="none", rol que ya está suportado por JAWS y NVDA. En ocasiones, para mayor compatibilidad, los desarrolladores usan role="none presentation".

El validador da error en una imagen con alt vacío y role=none

Ten en cuenta:

  • Como he indicado, el tamaño máximo que permite el validador para el atributo alt es de 150 caracteres. Deberías limitarlo en el gestor de contenidos o, al menos, avisar del número de caracteres incluidos, para evitar este error a los publicadores.

1.2 Uso de encabezados (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

  • Se deben usar etiquetas de encabezado o su correspondiente rol ARIA (role="heading" con aria-level).
  • Los encabezados no pueden estar vacíos.
  • No puede haber dos encabezados del mismo nivel o superior (por ejemplo: H2H2 o H2H1) sin contenido entre ellos.
  • Los encabezados no pueden saltarse niveles.
  • Si la página tiene 15 o más párrafos P con al menos 80 caracteres, se verifica que la página no tenga un único encabezado. Si esta verificación se incumple, se daría 0.5 puntos en vez de 1, pero la página tendría el valor "pasa" (en vez de "falla").
  • La página debe tener un H1 (o su equivalente rol ARIA). Si la página tiene encabezados, la ausencia de H1 dará 0.5 puntos en vez de 1, y la página tendrá el valor "pasa" (en vez de "falla").

Ten en cuenta

  • Aunque la página "pase" sin tener H1, recuerda que es importante para muchos usuarios que las páginas tengan H1. Un auditor u otros validadores de accesibilidad lo remitirán como un error que es necesario corregir.
  • Recuerda que los encabezados deben ser concisos y significativos. Eso implica que:
    • no debe haber dos encabezados con el mismo texto en la página;
    • no deben ser muy extensos, igual que no deben serlo ni los enlaces (el validador fija para ellos, como veremos, una longitud máxima de 250 caracteres) ni las alternativas de las imágenes (el validador fija para ellas una longitud máxima de 150 caracteres)

    Aunque este validador no incluya estas verificaciones en su metodología, otros sí lo hacen, y un auditor remitiría estos errores en una validación manual.

1.3 Uso de listas (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

  • Las listas deben estar bien formadas, bien anidadas y los elementos LI deben tener como padre directo un OL o UL.
  • No puede haber listas OL o UL sin hijos LI.
  • No se deben simular las listas mediante párrafos o tablas de una columna, para ello se verifica que:
    • No haya 3 o más elementos P seguidos que empiecen por “-“ o “- “ o “*”.
    • No haya 3 o más elementos BR seguidos que empiecen por “-“ o “- “ o “*”.
    • No haya 3 o más elementos P seguidos que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos.
    • No haya 3 o más elementos BR seguidos que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos. Solo se consideran aquellas secuencias que empiezan por la unidad (1, 1º, 1ª, a, A, i, I).
    • No haya 3 o más elementos LI de lista desordenada UL que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos. Solo se consideran aquellas secuencias que empiezan por la unidad (1, 1º, 1ª, a, A, i, I).
    • No haya 3 o más párrafos seguidos que empiecen por una imagen cuyas dimensiones sean iguales o inferiores a 10x10 píxeles.
    • No haya 3 o más líneas separadas por BR que empiecen por una imagen cuyas dimensiones sean iguales o inferiores a 10x10 píxeles.
    • No haya tablas formadas por una única columna y 3 o más filas en la que el contenido textual de cada celda no supere los 150 caracteres.

Falso negativo

  • A pesar de lo que se indica en la metodología, no han dado error las listas simuladas con párrafos precedidos de * o de letras (a. b. c.), lo cual sería un falso negativo. Tampoco ha dado error probando con la validación de acuerdo a la UNE 139803:2012.

Ten en cuenta

  • Si se tienen tablas de una sola columna, con 3 o más filas, y contenido de menos de 150 caracteres, se entiende que se está simulando una lista y el validador da error. Tenlo en cuenta para evitar, si es posible, que los editores de contenido puedan crear tablas de una sola columna.
  • Muchas veces los publicadores simulan las listas porque el editor de contenidos no les ofrece la posibilidad de crear listas de tipo "2, 2.1, 2.1.1" o "a. b. c.". Por ejemplo, CKEditor sí permite, con el botón derecho, modificar las propiedades de la lista para que sea de tipo "a. b. c." o "I. II. III.", pero hay que informar a los publicadores de esta opción que, de lo contrario, puede pasarles desapercibida.
  • Los listados de enlaces deben estar maquetados como una lista. Aunque el validador no incluye esta validación, tenlo en cuenta, otros validadores sí pueden detectarlo y un auditor lo reportará como error.
  • Es habitual encontrar listas vacías en bloques como "Tus últimas visitas", cuando es la primera vez que accedes. La lista no debe estar vacía en el código, sino crearse junto con el primer LI.

1.4 Tablas de datos (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

Si es una tabla de datos (1)

  • Debe tener al menos una celda de encabezado (TH) en las filas o columnas exteriores.
  • Si la tabla es sencilla: debe tener encabezados (todos los elementos son encabezados TH) en la primera fila o en la primera columna, salvo para celdas con texto vacío. Es decir, falla si no hay ningún encabezado (TH) en la primera fila ni en la primera columna, o si en ellas hay al menos una celda de encabezado (TH) y al menos una de datos con texto (TD).
  • Si la tabla tiene más de un nivel encabezados (si hay elementos TH en dos filas o en dos columnas):
    • Da error si no existen atributos id en los elementos TH y headers en los elementos TD.
    • En aquellas tablas con la celda superior izquierda vacía y marcada por tanto como TD, se verifica que el resto de celdas con texto de la fila sean encabezados (TH) y que todas las celdas de la primera columna (que tengan texto) sean encabezados TH, en caso contrario falla.
    • Es decir, la siguiente tabla es correcta porque, aunque la celda superior izquierda de la fila de encabezados está vacía, el resto de celdas con texto de la fila son TH, y las celdas con contenido de su columna también son encabezados TH:

      TD vacío TH TH TH
      TH
      TH
      TH
      TH
    • Si la tabla tiene scope, headers o axis el valor debe ser válido.
  • No se puede simular el título (caption) de la página.
    • Si la primera fila de una tabla tiene una única celda que ocupa todo el ancho de la tabla, dará error porque se considera que se está simulando de forma incorrecta el título de la tabla, que debería marcarse con CAPTION.

      Es decir, la siguiente tabla da error porque tiene una primera fila de celdas unidas con colspan y se entiende que está simulando el título, cuando debería usarse para ello el atributo CAPTION:

      Error: celdas unidas en vez de CAPTION
      TH TH TH TH
      X X X X
      X X X X
      X X X X
    • Si una tabla no tiene título (CAPTION), dará error si es el único contenido de la sección correspondiente a un encabezado (H1, H2, H3...), considerando que dicho encabezado es en realidad el título de la tabla, y que este debería haberse incluido con CAPTION. Es decir, si tenemos un encabezado seguido de una tabla (por ejemplo, <h2>Título</h2> <table>...) dará error, haya o no más contenido tras la tabla.
  • Las tablas deben tener un resumen:
    • Se comprueba que las tablas complejas tienen un atributo summary con contenido. El validador considera que una tabla es compleja si tiene encabezados tanto de fila como de columna y, además, tiene dos o más filas o columnas de encabezados.
    • Aunque no se indica en la metodología, si la descripción se incluye con aria-describedby (alternativa a summary en HTML 5), la tabla pasa la validación. Puedes consultar el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
  • El título (CAPTION) y el resumen (summary) no pueden ser iguales.

(1) Se considera tabla de datos si:

  • No contiene a ninguna otra tabla.
  • No contiene ninguna celda con más de 150 caracteres mostrados por pantalla.
  • No se trata de una tabla con una sola celda.
  • No se trata de una tabla con una sola fila.
  • No se trata de una tabla con una sola columna.
  • Al menos el 70% de las celdas de la tabla contienen texto. Para contabilizar el texto se tendrá en cuenta el contenido de los atributos alt, title o aria-label, así como la presencia de un atributo aria-labelledby o aria-describedby que hagan referencia a algún elemento con contenido.

Falsos negativos

  • El validador da error cuando el summary y el caption son iguales, pero no da error cuando la descripción asociada por aria-describedby (alternativa a summary en HTML 5) es igual al caption, esto es un falso negativo (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
  • A pesar de lo que indica la metodología, la inclusión de una tabla compleja sin summary, o con summary vacío, no ha dado error, de modo que sería un falso negativo. Para probar esta validación, he validado la página tanto con el DOCTYPE de HTML5, como con el de HTML4, con el que en realidad debería dar error de tabla sin summary, pero no ha dado error en ninguno de los casos. Como ya he comentado, en el caso de DOCTYPE de HTML5, la descripción debería incluirse con aria-describedby y dar error si no la tiene.
  • A pesar de lo que indica la metodología, la definición de un headers con un valor erróneo no ha provocado error en la página de prueba, de modo que sería un falso negativo.

Ten en cuenta

  • Ten en cuenta que, si tienes una tabla con varios niveles de encabezado, si relacionas las celdas con scope, solo pasará el validador si la tabla tiene una fila y una columna de encabezados. Para otros tipos de tablas complejas (con varias filas o columnas de encabezados), deberás usar headers/id, algo que no permiten la mayoría de los editores, así que intenta siempre evitar las tablas complejas. Recomiendo leer: "Table concepts de WAI/W3C".
  • Como he señalado, si utilizas colspan para unir la primera fila, el validador dará error por simular el caption. Puesto que además siempre es mala idea unir celdas, y es mejor, por ejemplo, repetir el dato en cada celda, plantéate eliminar la posibilidad de que los publicadores puedan unir celdas en el editor.
  • También hemos comentado que, si tienes un encabezado (H1, H2, H3...) justo antes de una tabla, dará error porque presupone que está simulando un caption. Puesto que summary está obsoleto en HTML5 y lo recomendable en HTML5 es una descripción asociada con aria-describedby, esta descripción, en un párrafo antes de la tabla, impedirá siempre el error, porque nunca habrá una tabla inmediatamente después de un encabezado. Plantéatelo como solución estándar en el gestor de contenidos (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
  • Es recomendable que todas las celdas de una tabla de datos tengan contenido, aunque sea "0" o "sin datos", porque son más fáciles de comprender, especialmente con el lector de pantalla. Teniendo en cuenta que el validador considera una tabla como tabla de datos si al menos el 70% de sus celdas contienen texto, también evitarás errores en el validador si intentas no dejar celdas vacías.

1.5 Agrupación estructural (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

  • No se debe usar el elemento DIV para incluir directamente el contenido sin usar a su vez etiquetas semánticas. El validador solo dará error si hay algún elemento DIV cuyo contenido directo sea un texto de más de 150 caracteres, obviando las etiquetas en línea.
  • No se deben usar las etiquetas BR, salvo en ADDRESS. Pero el validador solo dará error si:
    • Hay elementos P con más de 150 caracteres de texto (obviando el marcado de las etiquetas en línea) que contengan secuencias de 2 o más BR seguidos, ignorando aquellas secuencias de BR que estén al principio y final del párrafo.
    • Se están empleando más de 10 elementos BR en la página, considerando que un abuso del elemento BR implica que se están empleando saltos de línea para simular párrafos.

Ten en cuenta

  • Aunque el validador solo dé error en los DIV sin etiquetas semánticas con textos mayores de 150 caracteres, no debe usarse tampoco en textos de menor longitud, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
  • Aunque el validador es relativamente permisivo con el uso de etiquetas BR, no debe usarse esta etiqueta salvo en ADDRESS, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
  • El validador no da error si utilizas varios elementos semánticos iguales para estructurar la página (por ejemplo, varios nav) y no los diferencias con una etiqueta aria-label o aria-labelledby. Esto es un error y es fácil de identificar automáticamente, por lo que sí que lo detectan otros validadores.

1.6 Separación de contenido y presentación (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

  • Si hay tablas de maquetación (2) no pueden tener: CAPTION, TH, THEAD, TBODY, TFOOT o los atributos summary, title, scope, headers o axis.
  • No pueden usarse los siguientes elementos de presentación desaconsejados (deprecated): FONT, BASEFONT, CENTER, S, STRIKE y U.
  • No puede incluirse contenido desde las CSS con :before o :after y la propiedad content, cuyo valor sea un texto de más de un carácter alfanumérico (las entidades HTML y los caracteres Unicode se contabilizan como un único carácter).

(2) Se considera tabla de maquetación si:

  • Contiene a otra tabla o
  • Tienen el atributo role="presentation".
  • Contiene alguna celda con más de 150 caracteres mostrados por pantalla.
  • Se trata de una tabla con una sola celda.
  • Se trata de una tabla con una sola fila.
  • Se trata de una tabla con una sola columna.
  • Menos del 70% de las celdas de la tabla contienen texto. Para contabilizar el texto se tendrá en cuenta el contenido de los atributos alt, title o aria-label, así como la presencia de un atributo aria-labelledby o aria-describedby que haga referencia a algún elemento con contenido.

Falsos positivos

  • La validación de la inclusión de contenido con content desde la CSS puede llevar a falsos positivos, porque el validador no comprueba si esos estilos de la CSS se están usando realmente en la página. Este problema lo hemos tenido en CSS propias de gestores de contenido como Liferay, que son complicadas de modificar o sobrescribir.
  • Si la tabla tiene role=none en vez de role=presentation, el validador no entiende que es una tabla de presentación y da error de tabla de datos sin caption y sin th. El role=none viene a sustituir al role=presentation en WAI-ARIA 1.1, puedes consultar mi artículo Novedades WAI-ARIA 1.1
  • El validador considerará la siguiente tabla como una tabla de maquetación en vez de una tabla de datos, porque tiene celdas con más de 150 caracteres. Por tanto, dará error porque tiene caption y th. Sin embargo, no puede considerarse que esta tabla sea de maquetación:

Ejemplo de tabla de datos que el validador considera tabla de maquetación.

Criterios de las WCAG 2.1
Criterio Normativa Nivel Título Descripción
1.4.1 WCAG 2.1 A Use of Color Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. NOTE: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
1.2.7 WCAG 2.1 AAA Extended Audio Description (Prerecorded) Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.

Ten en cuenta

  • El validador solo da error en etiquetas de presentación obsoletas, pero hay otras que no se deben usar, y que una auditoría manual u otros validadores reportarán como error:
    • <b>: si quieres definir el grosor de la fuente usa estilos para ello, si quieres dar énfasis a unas palabras importantes usa strong, pero en cualquiera de los casos recuerda no abusar de la negrita.
    • <i>: si quieres definir el estilo con itálica usa estilos para ello, pero recuerda que mucho texto en itálica es más difícil de leer. Si quieres enfatizar el texto para reflejar un carácter particular del mismo, como un extranjerismo, usa <em> o ponlo entre comillas. No uses la <i> con background-image para incluir iconos.
  • El validador dará error con a::before {content: "&nbsp;";}

1.7 Identificación del idioma principal (A)

Criterio de las WCAG 2.1: 3.1.1 (A)

Validaciones

  • La etiqueta HTML debe tener el atributo lang, y debe definir el idioma correcto del documento. La identificación del idioma de una página se realiza mediante la técnica de detección de trigrams (n-gramas de tres caracteres).

1.8 Navegación con JavaScript accesible y Control de Usuario (A)

Criterios de las WCAG 2.1: 2.1.1 (A), 4.1.2 (A), 2.2.1 (A), 2.3.1 (A)

Validaciones

  • Todos los eventos dependientes de dispositivo (salvo onclick) deben tener a su vez un evento lógico independiente o un evento para otro dispositivo de entrada (onmousedown con onkeydown; onmouseover con onfocus...)
  • Los elementos que tienen onclick o onkeypress deben ser elementos estándar de interacción, en caso contrario deben tener tabindex y un role relativo a widgets (alert, button, link...)
  • No se debe usar blink o marquee o el estilo text-decoration: blink.
  • La página no debe actualizarse o redirigirse automáticamente con el elemento META y el atributo http-equiv (con un tiempo mayor de 0 segundos)

Falsos negativos

  • El código <a href="" onmousedown="mover()">Aviso legal</a> sí da error.

    Sin embargo, si el evento está asignado con javascript no intrusivo, no da error: 

    <a href="" id="enlaceprueba">Aviso legal</a>

    <script>document.getElementById('enlaceprueba').onmousedown = function() {    alert('prueba');}</script>

    lo cual es un falso negativo.

  • Lo mismo ocurre con la validación del evento onclick o onkeypress. Si se aplica el evento directamente en un elemento no estándar de interacción, sin un rol adecuado y sin tabindex, da error; pero en la misma situación, si el onclick está asociado por javascript no intrusivo, el validador no da error.

1.9 Formularios y etiquetas (A)

Criterios de las WCAG 2.1: 1.3.1 (A), 3.3.2 (A), 4.1.2 (A), 2.5.3 (A)

Validaciones

  • Los campos de formulario deben tener una etiqueta (label, aria-label, aria-labelledby, title) correctamente asociada y no vacía. En caso de usar label, su for debe tener el id de algún control de formulario usado en la página.
  • Si el campo solo tiene una etiqueta incluida con label, esta no puede estar oculta con display: none o visibility: hidden.
  • Si el formulario tiene más de 5 campos (los grupos de radios o de checks contabilizan como uno) el validador busca términos como “obligatorio” u “opcional”, en varios idiomas, en el texto, las alternativas textuales o los títulos del formulario y su elemento contenedor. Si no las encuentra da error.
  • Si un elemento tiene un nombre accesible con aria-label o aria-labelledby, este debe coincidir o contener la etiqueta visible del campo para facilitar el acceso por voz (consultar el artículo "WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre") . No es aplicable cuando el contenido accesible o el contenido visible sólo contiene caracteres Unicode, de puntuación (:, ;, ., /, \, |,…) , o emojis.

Falsos positivos

  • En el análisis de un portal, he encontrado que el validador da error porque la etiqueta del campo "Buscar" está oculta, a pesar de que solo lo está visualmente y no para el lector de pantalla. En concreto está oculta con tamaño de 1 píxel y posicionamiento fuera de pantalla.

Falsos negativos

  • La página de prueba tiene campos con una única etiqueta incluida con label, la cual está oculta visualmente y para los lectores de pantalla con display:none en unos casos, y visibility:hidden en otros. Los estilos que ocultan las etiquetas están definidos en un STYLE ubicado en el HEAD. El validador ha dado error al validar la página por URL, pero no ha dado error al validar la página por código, en cuyo caso es un falso negativo.
  • Los input con un aria-label que no es igual o no contiene su etiqueta sí que dan error, tal y como es de esperar. Todos estos casos dan error: <input aria-label="Cerrar" value="X">; <input aria-label="Cerrar" value="-X-">; <input aria-label="Cerrar" value="Close">

    Sin embargo, los button con un aria-label que no es igual o no contiene su etiqueta, NO dan error. Por tanto, no dan error y son falsos negativos casos como: <button aria-label="Cerrar">X</button>; <button aria-label="Cerrar">-X-</button>; <button aria-label="Cerrar">Close</button> 

  • Es necesario indicar siempre los campos obligatorios, aunque el validador solo lo compruebe en formularios de más de 5 campos. Por tanto, si tienes un formulario con 4 campos obligatorios y no indicas que lo son, el validador no dará error. Esto será un falso negativo respecto a las WCAG 2.1 / EN 301 549:2019, porque en este caso el validador es menos estricto que la normativa.

Ten en cuenta

  • El label debe estar asociado al campo por el id, no por el name. Si incluyes dentro del for el nombre del campo, en vez de su id, dará error. Recuerda también, como hemos indicado, que no puedes ocultar el label al lector de pantalla. Sin embargo, no da error si lo ocultas solo visualmente, por ejemplo, con text-indent:-999em.
  • Puedes indicar los campos obligatorios con un asterisco. En este caso, recuerda que deberás indicar el significado del asterisco al principio del formulario "* campos obligatorios". También podrías indicar "Todos los campos son opcionales", porque el validador busca tanto la palabra "obligatorio" como "opcional" (o equivalentes: exigido, preciso, requerido...).
  • Que el validador encuentre la palabra "Obligatorio" en el formulario no significa que estés indicando de forma correcta los campos obligatorios. Por ejemplo, si diferencias los campos obligatorios solo por su color de fondo, e incluyes un mensaje como "Todos los campos amarillos son obligatorios", el validador no dará error. Sin embargo, es un error, porque transmites información solo por el color y das instrucciones basadas en aspectos visuales que no todos los usuarios pueden detectar.

1.10 Formularios y estructura (A)

Criterios de las WCAG 2.1: 1.3.1 (A), 4.1.2 (A)

Validaciones

  • En formularios extensos, los campos deben estar agrupados con fieldset. El validador hace las siguientes comprobaciones:
    • Si hay grupos de dos o más radio o de cinco o más checks (con el mismo name) entonces cada uno de ellos debe estar agrupado bajo un FIELDSET o un rol de ARIA equivalente (“group” para los checks y “radiogroup” para los radio). 
    • Se comprueba que existan elementos FIELDSET, o elementos que tengan role="group", en aquellos formularios que contengan 8 o más campos de introducción de datos. Si hay 8 o más campos, pero menos de 12 sin haber un elemento FIELDSET, entonces la comprobación se evalúa con 0.5 puntos en vez de 1 y la modalidad "pasa". Si hay 12 o más campos entonces se le asigna el valor 0 puntos y la modalidad "falla".
  • Si existen dos o más elementos de encabezado (H1, H2, H3...) dentro de un elemento FORM, da error porque entiende que hacen la función que deberían estar haciendo los elementos fieldset.
  • El elemento fieldset debe tener como primer hijo un legend con contenido.
  • Se comprueba que todo elemento con role="group" o role="radiogroup" tenga un atributo aria-label, o un atributo aria-labelledby que haga referencia a algún elemento de la página con contenido.
  • Los select con muchos elementos deben estar agrupados con optgroup:
    • Se comprueba que, si una SELECT tiene más de 24 opciones, estén agrupadas con algún elemento OPTGROUP. Este límite se amplía hasta 100 en el caso de que las opciones sean números consecutivos.
    • Se comprueba que no existan elementos SELECT con opciones que comiencen por sucesiones de 3 o más caracteres repetidos no alfanuméricos (por ejemplo: “----”, “----texto”, “___”, “***”, “......”, etc.)
    • Se comprueba que los elementos OPTGROUP disponen de una etiqueta que identifique su contenido en forma de atributo label con texto.

Falsos negativos

  • A pesar de que en la metodología se dice que se comprueba que todo elemento con role=group da error si no tiene etiqueta, el validador no ha dado este error en la página de prueba, ni teniendo varios role=group sin etiqueta. Esto es un falso negativo.
  • En la página de prueba se tiene una select con 25 opciones textuales sin optgroup, pero el validador no ha dado error, es un falso negativo respecto a su metodología. 

Ten en cuenta

  • No incluyas encabezados dentro del form, usa en su lugar fieldset.
  • Las WCAG no indican un número exacto de elementos a partir de los cuales es obligatorio usar fieldset en el formulario o optgroup en las select, así que guíate por las pautas definidas por el validador.

1.11 Título de página y de marcos (A)

Criterios de las WCAG 2.1: 2.4.1 (A), 2.4.2 (A), 4.1.2 (A)

Validaciones

  • La página tiene que tener un title en el head que sea válido (se verifica que no sean títulos que se hayan podido añadir por defecto: “Título del documento”, “Title”, “Untitled document”…)
  • Cuando se analiza una muestra de más de 10 páginas, el validador dará error si son todos los títulos iguales. 
  • Los frames e iframes deben tener title y no puede estar vacío.

Falso negativo

  • Si en una muestra hay dos páginas con el mismo título, esto es un error, aunque el validador solo esté programado para dar error si todas las páginas de la muestra tienen el mismo título.

1.12 Enlaces descriptivos (A)

Criterio de las WCAG 2.1: 2.4.4 (A)

Validaciones

  • El validador detecta el uso de enlaces poco descriptivos similares a “pincha aquí” o “pulse aquí”.
  • No puede haber enlaces sin texto de enlace y/o imágenes sin alternativas textuales.
  • Los enlaces no pueden tener mas de 250 caracteres a menos que empiecen por Decreto, Orden, Ley, R.D., ...
  • La alternativa textual de una imagen incluida dentro de un enlace no puede ser igual que el resto del contenido textual del enlace.
  • Todo elemento con role="link" o role="button" debe tener un contenido textual; o bien un atributo aria-label, o aria-labelledby que haga referencia a algún elemento de la página con contenido.

Falso positivo

  • El siguiente código da error:

    <a href="http://www.usableyaccesible.com" aria-label="Accesibilidad"><img src="icono.png" alt=""/></a>

    También da error el código:

    <a href="http://www.usableyaccesible.com"><img src="icono.png" alt="" aria-label="Accesibilidad"/></a>

    Si bien el enlace está vacío, visualmente hay un icono y el lector de pantalla anuncia el enlace porque, en el primer caso tiene una etiqueta incluida con el atributo aria-label (técnica ARIA8: Using aria-label for link purpose), y en el segundo es la propia imagen la que tiene un texto alternativo incluido con aria-label (técnica ARIA6: Using aria-label to provide labels for objects).

    Dicho esto, es cierto que lo más adecuado sería que, en este tipo de casos, el texto alternativo estuviera en la imagen y concretamente en su atributo ALT, para asegurar que sin imágenes cargadas se muestre el texto alternativo de la imagen. De hecho, el primer caso dará error en el indicador 1.1 (criterio 1.1.1 de las WCAG), pero eso no implica que debiera dar error en el indicador 1.12 (criterio 2.4.4 de las WCAG). El segundo caso, que no da error en el criterio 1.1, como debe ser, no tiene sentido que sí dé error en este indicador 1.12.

Falsos negativos

  • En las pruebas se han incluido elementos con role="link" tanto sin etiqueta, como con etiqueta mediante aria-labelledby pero referenciando a un id que no existe, y en ambos casos el validador no ha dado error. Serían falsos negativos.
  • Tampoco han dado error los enlaces con un aria-label con texto que no es igual o no incluye su texto de enlace, como <a href="http://www.usableyaccesible.com" aria-label="Olga Carreras">Usable y accesible</a>. Este enlace debería reportar un error, tal y como se hace en los input para esta misma situación (se ha visto en 1.9 Formularios y etiquetas (A)).

Ten en cuenta

  • El validador no da error si encuentra dos enlaces iguales en la misma pagina que apuntan a una URL diferente, ni viceversa. Este es un error que sí encuentran otros validadores y que también reportará un auditor en una evaluación manual.
  • Aunque las WCAG 2.1 no indican el tamaño máximo de caracteres que deben tener los enlaces, el validador lo fija en 250 caracteres. Para evitar errores a los publicadores, si es posible, se puede limitar en el editor el tamaño máximo de los enlaces, o al menos informar de su longitud.

    Aunque los enlaces que comienza por "Orden", "Real Decreto", etc. son una excepción, ten en cuenta que un enlace de más de 250 caracteres como "la Orden de 27 de mayo de 1958 [...]" sí dará error, porque el enlace comienza en realidad por el artículo "la", no por "Orden".

    También he probado con "&nbsp; Orden del 27 de mayo de 1958 [...]" y da error porque tiene un espacio antes de la palabra "Orden".

    Ten esto en mente a la hora de seleccionar las palabras que incluirás dentro del texto del enlace.

1.13 Cambios de contexto (A)

Criterios de las WCAG 2.1: 3.2.1 (A), 3.2.2 (A)

Validaciones

  • Se valida que no provoquen un cambio de contexto (abrir una nueva página, ventana, pestaña o aplicación; o que cambie el foco) mediante el uso de window.location, window.history, window.open, window.focus:
    • ni los eventos onfocus / onblur de los elementos de la página
    • ni el evento onload de la página 
    • ni el evento onchange de una select

Falso negativo

  • En las pruebas realizadas, el validador solo detecta el error si incluyo directamente, por ejemplo, un window.open, en el onload, onchange o onfocus del elemento correspondiente, pero no ha funcionando llamando a una función que lo hiciera (<body onload="cargar();">).

1.14 Compatibilidad (A)

Criterio de las WCAG 2.1: 4.1.1 (A)

Validaciones

  • La página debe tener un DTD válido.
  • El código de la página no puede tener los siguientes errores de validación: etiquetas mal cerradas o anidadas; atributos repetidos en el mismo elemento; atributos con valores sin entrecomillar; atributos que deben tener valores únicos (id, accesskey) repetidos.
  • Las CSS no pueden tener errores de sintaxis. Se admiten propiedades experimentales o propietarias siempre que la sintaxis de las CSS sea correcta.

Falso negativo

  • En la página de prueba hay un código con errores de sintaxis que sí detecta el validador del W3C, pero que no detecta el validador del Observatorio, a pesar de ser un error que sí debería detectar. Concretamente no da error: <p style="" style="" id=51 id="51"><span accesskey="s"><div accesskey="s"></div></span></div></p>

2.1 Identificación de los cambios de idioma (AA)

Criterio de las WCAG 2.1: 3.1.2 (AA)

Validaciones

  • Si se usa el atributo lang, se verifica que define un código de idioma que existe.
  • Se buscan palabras concretas habituales en otros idiomas (“bienvenido”, “welcome”, “castellano”, “english”, …) para comprobar que tienen el atributo lang correspondiente. Detecta, por ejemplo, sin marcar, las palabras "english", "français", "català", "galego" o "euskera", pero no "deutsch".
  • Se verifica que los cambios en inglés (textos, títulos y alternativas textuales) se marcan con lang. Para identificar textos en inglés se buscan al menos 4 palabras en un listado de las palabras más usadas del inglés que no existen en las lenguas cooficiales de España. No se tienen en cuenta aquellas que están en abreviaturas o acrónimos (ABBR o ACRONYM).

Falso negativo

  • Si indicas que la página está en castellano, encuentra los cambios de idioma al inglés sin marcar. Sin embargo, si indicas que la página está en inglés, no detecta los cambios al castellano sin marcar.

2.2 Legibilidad y contraste (AA)

Criterios de las WCAG 2.1: 1.4.3 (AA), 1.4.12 (AA)

Validaciones

  • Se comprueba que las combinaciones de color de primer plano (color) y de color de fondo (background-color o background), en una misma regla de las hojas de estilo, tiene el contraste suficiente. Se tienen en cuenta los diferentes umbrales según el tamaño del texto. Si no se conoce el tamaño de texto, se emplea el umbral más permisivo de 3:1.
  • Se comprueba que no se usen las propiedades 'line-height', 'letter-spacing', 'word-spacing' fijadas mediante la clave !important.

2.3 Maquetación adaptable (AA)

Criterio de las WCAG 2.1: 1.4.10 (AA)

Validaciones

Ten en cuenta

  • No se valida que el texto pueda crecer. Recuerda que este es un requisito diferente del requisito que hace referencia al zoom, pero igual de importante o más. El texto debe poder crecer con las opciones del navegador porque se usan medidas relativas, o bien, y de forma no excluyente, porque se incluyen controles específicos para aumentar o disminuir el tamaño de letra (A+ A-).

2.4 Múltiples vías de navegación (AA)

Criterio de las WCAG 2.1: 2.4.5 (AA)

Validaciones

  • La página debe tener mapa del sitio o una función de búsqueda.
    • Se buscan palabras como "mapa" (en distintos idiomas), en los textos de enlace o en su title. Si no las encuentra, las busca en el title de la página, por si estamos en la página de mapa web. 
    • Se buscan palabras como "buscar", "buscador", "búsqueda"... (en distintos idiomas) en elementos de formulario.

Falso positivo

  • El criterio de conformidad 2.4.5 (AA) de las WCAG 2.1 / EN 301 549 indica que se deben proporcionar dos o más de los siguientes mecanismos:
    • enlaces para navegar a páginas web relacionadas
    • una tabla de contenidos
    • un mapa del sitio
    • un buscador
    • una lista de enlaces a todas las páginas del sitio en la página de inicio
    • una lista de enlaces a todas las páginas del sitio en todas las páginas del sitio

    Por tanto, el validador es más estricto que las WCAG 2.1 / EN 301 549. Dará un falso positivo si el portal está cumpliendo este requisito mediante otras técnicas. Esto no quita para que sea verdad que en los portales extensos y complejos lo más adecuado sea tener al menos mapa web y buscador, pero estrictamente no se incumple la normativa si se opta por otras técnicas, por ejemplo, en portales pequeños y sencillos.

  • Sí detecta que la página tiene mapa web si el enlace se incluye así:

    <a href="http://www.usableyaccesible.com/mapa_web.html"><img src="icono.png" alt="Mapa web"/></a>

    pero no lo detecta si se incluye de la siguiente manera:

    <div role="link" aria-label="Mapa web" tabindex="0"></div> 

    que es válida, como él mismo reconoce en sus validaciones relativas a los enlaces, por tanto, sería un falso positivo.

2.5 Independencia de dispositivo (AA)

Criterios de las WCAG 2.1: 1.3.4 (AA), 2.4.3 (A), 2.4.7 (AA), 1.3.5 (AA)

Validaciones

  • Los elementos de interacción no pueden tener atributos outline:0/none, a menos que se use en ellos también :focus para definir un borde o color de fondo.
  • No debe usarse tabindex con valores mayores de 0. El validador admite que se incluyan 3 tabindex con un valor mayor que 0; de 4-10 tabindex con un valor mayor que 0 dará 0.5 puntos (en vez de 1 punto) pero pasará.
  • No se debe bloquear la orientación de pantalla. El validador comprueba que no existan reglas CSS tipo @media que definan la propiedad orientation que a su vez incluyan sentencias transform con valores 90degr o 270deg.
  • Se debe usar autocomplete en ciertos campos de formulario. El validador solo comprueba que los campos de formulario con atributo autocomplete tengan un valor de los descritos en HTML 5.2.

Falsos negativos

  • No da error:
    • input {outline:0;} 
    • button {outline:none;} 
    • a {outline:0;} 
  • Sí da error si se incluye en el focus:

    • input:focus {outline:0;}
    • button:focus {outline:none;}
    • a:focus {outline:none;}

    Debería dar error en ambos casos.

  • Si la inclusión de outline:0/none se hace en línea (<a style="outline:0"...) el validador no da error.

Falso positivo

  • La validación del uso de outline:0/none en la CSS puede llevar a falsos positivos, porque el validador no comprueba si esos estilos de la CSS se están usando realmente en la página.

2.6 Navegación consistente (AA)

Criterio de las WCAG 2.1: 3.2.3 (AA)

Validaciones

  • La página no debería tener enlaces rotos:
    • con 1 enlace externo roto pasa; 
    • con 1 enlace roto dentro del dominio o, más de 1 y menos de 4 enlaces externos rotos, tendrá 0.5 puntos (en vez de 1) pero "pasa".
  • No se permiten dos enlaces adyacentes (separados por un carácter y/o conjunto de espacios en blanco o por alguna etiqueta que no pertenezca al grupo de etiquetas en línea) que apunten al mismo destino, salvo que el destino sea "#".

Ten en cuenta

  • En el informe no se incluye el listado de enlaces rotos (aunque se indique en las opciones de validación que los evalúe), pero se pueden consultar en el log.

Resumen: Ten en cuenta

En este apartado se recopilan los "ten en cuenta" que se han ido nombrando a lo largo del artículo. No se recopilan los falsos negativos o positivos, estos deben consultarse en cada indicador.

  • Imágenes:
    • El número máximo de caracteres en el atributo alt de las imágenes debe ser 150 caracteres. Deberías limitarlo en el gestor de contenidos o, al menos, avisar del número de caracteres incluidos, para evitar este error a los publicadores.
  • Encabezados:
    • Aunque la página "pase" sin tener H1, recuerda que es muy importante para muchos usuarios que todas las páginas tengan H1.
    • Aunque este validador no lo evalúe, recuerda que los encabezados deben ser significativos, eso significa que no debe haber dos encabezados con el mismo texto en la página, y que su número de caracteres no debe ser muy extenso. 
  • Listas:
    • Si se tienen tablas de una sola columna, con 3 o más filas, y contenido de menos de 150 caracteres, se entiende que se está simulando una lista y el validador da error. Tenlo en cuenta para evitar, si es posible, que los editores de contenido puedan crear tablas de una sola columna.
    • Muchas veces los publicadores simulan las listas porque el editor de contenidos no les ofrece la posibilidad de crear listas de tipo "2, 2.1, 2.1.1" o "a. b. c.". Por ejemplo, CKEditor sí permite, con el botón derecho, modificar las propiedades de la lista para que sea de tipo "a. b. c." o "I. II. III.", pero hay que informar a los publicadores de esta opción que, de lo contrario, puede pasarles desapercibida.
    • Aunque este validador no lo evalúe, los listados de enlaces deben estar maquetados como una lista. 
    • Es habitual encontrar listas vacías en bloques como "Tus últimas visitas", cuando es la primera vez que accedes. La lista no debe estar vacía en el código, sino crearse junto con el primer LI.
  • Tablas:
    • Ten en cuenta que, si tienes una tabla con varios niveles de encabezado, si relacionas las celdas con scope, solo pasará el validador si la tabla tiene una fila y una columna de encabezados. Para otros tipos de tablas complejas (con varias filas o columnas de encabezados), deberás usar headers/id, algo que no permiten la mayoría de los editores, así que intenta siempre evitar las tablas complejas. Recomiendo leer: "Table concepts de WAI/W3C".
    • Si utilizas colspan para unir la primera fila, el validador dará error por simular el caption. Puesto que además siempre es mala idea unir celdas, y es mejor, por ejemplo, repetir el dato en cada celda, plantéate eliminar la posibilidad de que los publicadores puedan unir celdas en el editor.
    • Si tienes un encabezado (H1H2H3...) justo antes de una tabla, dará error porque presupone que está simulando un caption. Puesto que summary está obsoleto en HTML5 y lo recomendable en HTML5 es una descripción asociada con aria-describedby, esta descripción, en un párrafo antes de la tabla, impedirá siempre el error, porque nunca habrá una tabla inmediatamente después de un encabezado. Plantéatelo como solución estándar en el gestor de contenidos (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
    • Es recomendable que todas las celdas de una tabla de datos tengan contenido, aunque sea "0" o "sin datos", porque son más fáciles de comprender, especialmente con el lector de pantalla. Teniendo en cuenta que el validador considera una tabla como tabla de datos si al menos el 70% de sus celdas contienen texto, también evitarás errores en el validador si intentas no dejar celdas vacías.
  • Agrupación estructural:
    • Aunque el validador solo dé error en los DIV sin etiquetas semánticas (por ejemplo, <div>texto</div>) si los textos son mayores de 150 caracteres, no debe usarse tampoco DIV para incluir textos de menor longitud.
    • Aunque el validador es relativamente permisivo con el uso de BR, no debe usarse esta etiqueta salvo en ADDRESS, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
    • El validador no da error si utilizas varios elementos semánticos iguales para estructurar la página (por ejemplo, varios nav) y no los diferencias con una etiqueta aria-label o aria-labelledby. Esto es un error y es fácil de identificar automáticamente, por lo que sí que lo detectan otros validadores.
  • Separación de contenido y presentación:
    • El validador solo da error en etiquetas de presentación obsoletas, pero hay otras que no se deben usar, y que una auditoría manual u otros validadores reportarán como error:
      • <b>: si quieres definir el grosor de la fuente usa estilos para ello, si quieres dar énfasis a unas palabras importantes usa strong, pero en cualquiera de los casos recuerda no abusar de la negrita.
      • <i>: si quieres definir el estilo con itálica usa estilos para ello, pero recuerda que mucho texto en itálica es más difícil de leer. Si quieres enfatizar el texto para reflejar un carácter particular del mismo, como un extranjerismo, usa <em> o ponlo entre comillas. No uses la <i> con background-image para incluir iconos.
    • Ten en cuenta que el validador dará error con a::before {content: "&nbsp;";}
  • Formularios:
    • El LABEL debe estar asociado al campo por el id, no por el name. Si incluyes dentro del for el nombre del campo en vez de su id dará error. 
    • Recuerda que no puedes ocultar el LABEL, si es la única etiqueta del campo, al lector de pantalla. Sin embargo, no da error si lo ocultas solo visualmente, por ejemplo, con text-indent:-999em.
    • Puedes indicar los campos obligatorios con un asterisco. En este caso, recuerda que deberás indicar el significado del asterisco al principio del formulario "* campos obligatorios". También podrías indicar "Todos los campos son opcionales", porque el validador busca tanto la palabra "obligatorio" como "opcional" (o equivalentes: exigido, preciso, requerido...).
    • Que el validador encuentre la palabra "Obligatorio" en el formulario no significa que estés indicando de forma correcta los campos obligatorios. Por ejemplo, si diferencias los campos obligatorios solo por su color de fondo, e incluyes un mensaje como "Todos los campos amarillos son obligatorios", el validador no dará error. Sin embargo, es un error, porque transmites información solo por el color y das instrucciones basadas en aspectos visuales que no todos los usuarios pueden detectar.
    • No incluyas encabezados dentro del FORM, usa en su lugar FIELDSET.
    • Las WCAG no indican un número exacto de elementos a partir de los cuales es obligatorio usar FIELDSET en el formulario o OPTGROUP en las SELECT, así que guíate por las pautas definidas por el validador. Asegúrate de que los publicadores, si pueden incluir formularios, pueden añadir elementos FIELDSET y OPTGROUP.
  • Enlaces:
    • El validador no da error si encuentra dos enlaces iguales en la misma pagina que apuntan a una URL diferente, ni viceversa. Este es un error que sí encuentran otros validadores y que también reportará un auditor en una evaluación manual.
    • Aunque las WCAG 2.1 no indican el tamaño máximo de caracteres que deben tener los enlaces, el validador lo fija en 250 caracteres. Para evitar errores a los publicadores, si es posible, se puede limitar en el editor el tamaño máximo de los enlaces, o al menos informar de su longitud.
    • Aunque los enlaces que comienza por "Orden", "Real Decreto", etc. son una excepción, ten en cuenta que un enlace de más de 250 caracteres como "la Orden de 27 de mayo de 1958 [...]" o "&nbsp; Orden del 27 de mayo de 1958 [...]" sí darán error. Tenlo en mente a la hora de seleccionar las palabras que incluirás dentro del texto del enlace.
  • Maquetación aceptable:
    • No se valida que el texto pueda crecer. Recuerda que este es un requisito diferente del requisito que hace referencia al zoom, pero igual de importante o más. El texto debe poder crecer con las opciones del navegador porque se usan medidas relativas, o bien, y de forma no excluyente, porque se incluyen controles específicos para aumentar o disminuir el tamaño de letra (A+ A-).
  • Navegación consistente:
    • En el informe no se incluye el listado de enlaces rotos (aunque se indique en las opciones de validación que los evalúe), pero se pueden consultar en el log.

Artículos relacionados: