viernes, 5 de junio de 2026

Verificar el cumplimiento del estándar PDF/UA (solo sintaxis) en Adobe Acrobat Profesional. Cómo cumplir con la accesibilidad del PDF.

El objetivo de este artículo no es hablar del estandar PDF/UA, del que ya he hablado en el pasado (artículos sobre accesibilidad en PDF) sino dar una anotación muy concreta sobre Adobe Acrobat Profesional para dar paso, después, a una reflexión sobre la validación de accesibilidad de los PDF.

Adobe Acrobat Profesional tiene un validador de accesibilidad, pero lo que mucha gente no ha encontrado, es que también tiene un comprobador de estándares. Dentro de él, se encuentra la comprobación de sintaxis respecto al estándar PDF/UA, que no es lo mismo que el validador de accesibilidad, aunque sí que tienen, claro está, muchos aspectos en común.

Esta opción está en la herramienta "Produccción de impresión", porque originalmente incluía solo la comprobación de otros estándares, como PDF/X y PDF/A.

Opción de Acrobat Comprobaciones PDF/UA e la herramienta Producción de impresión.

Opción de Acrobat Comprobaciones. PDF/UA.

Detalle de la ventana de edición del perfil de Acrobat Comprobaciones PDF/UA. Tiene distintos apartados como Documento, Páginas, Imágenes, Colores, Fuentes, Representación, etc.

Opción de Acrobat Comprobaciones. PDF/UA. Editar perfil.

Resultados de Acrobat Comprobaciones PDF/UA: enlace sin entrada Contents, Tabla no uniforme, Nota sin ID, Falta de identificador PDF/UA, etc.

Ejemplo de resultados.

Ni pasar el validador de accesibilidad de Acrobat ni pasar la herramienta de comprobación de sintáxis del estándar PDF/UA asegura un PDF accesible. De hecho, hay muchos PDF que tienen graves problemas y pasan los validadores.

Solo son validadores de sintaxis. Puede ser un PDF muy inaccesible, con todo el contenido en el idioma incorrecto, con las imágenes informativas como decorativas, con el orden de lectura caótico, con un etiquetado no semántico, pero con una sintaxis correcta, y pasar los validadores.

Por otra parte, hay PDF comprobados manualmente y escuchados de forma íntegra con el lector de pantalla que son PDF accesibles y, que sin embargo, dan algún error en el estándar PDF/UA, pero que no está afectando a la accesibilidad comprobada y real con personas usuarias.

De hecho, la inmensa mayoría los errores que me da el validador de accesibilidad (el de la herramienta de Accesibilidad) de Acrobat, que también incluye validación de sintaxis, se corresponden con errores reales que detecto en las pruebas manuales o en el acceso con el lector.

Sin embargo, corregidos estos, algunos de los que persiten en el validador de PDF/UA no están afectando a la accesibilidad. Me parece una pérdida de tiempo dedicar esfuerzo a ellos en vez de a otros aspectos del PDF que sí mejorarían sustancialmente la accesibilidad:

  • texto alternativos a abreviaturas o acrónimos (si están sin expandir);
  • texto alternativo a las llamadas a las notas (si no viene así desde el origen) ;
  • texto alternativo a textos cortos en mayúsculas que el lector está deletreando;
  • textos ocultos para mejorar la comprensión con el lector;
  • mejorar el acceso semántico a las gráficas o esquemas;
  • etc.

Las WCAG 2.2 ya han quitado el criterio 4.1.1 de comprobación de sintaxis, alegando precisamente que si ese error supone un problema de accesibilidad, ya lo vas a detectar en el resto de criterios.

Mi recomendación después de 20 años especializada en la conversión de PDF en PDF accesibles y de convertir cientos de PDF es, para conseguir PDF accesibles para las personas reales, que es lo que buscamos, debemos:

  1. Trabajar y analizar la accesibilidad del PDF manualmente:
    • Previo: revisión de diseño, maquetación, idioma, redacción, exportación a una página o planificación de texto oculto para el lector, todo ello a trabajar en el documento original.
    • Título, visualización del mismo en la cabecera, otros metadatos y opciones de apertura.
    • Idioma: general y del contenido (a nivel de etiquetas y contenido).
    • Orden de lectura.
    • Orden del etiquetado.
    • Etiquetado correcto de cada elemento (encabezados, listas, índices, citas, notas, etc.) sin elementos vacíos.
    • Descripción de imágenes (decorativas, informativas, con descripciones extensas).
    • Tratamiento de gráficas e infografías adecuado (semántico o como imagen, según el caso).
    • Orden de tabulación y funcionamiento de los elementos interactivos.
    • Trabajo específico con tablas (títulos, descripciones, encabezados, estructura).
    • Enlaces y botones interactivos correctos.
    • Otros textos alternativos necesarios adicionales a los de las imágenes.
    • Trabajo específico con formularios.
    • Índice de marcadores adecuado.
    • Páginación consistente.
  2. Escuchar el PDF de forma íntegra con un lector de pantalla como NVDA (no vale la herramienta "Leer en voz alta" de Adobe, que eso es otra cosa)
  3. Pasarle los validadores para revisar si alguno de los errores está afectando a la accesibilidad del PDF: los del validador de Accesibilidad de Acrobat, según mi experiencia, deberás corregirlos porque es prácticamente seguro que sí que afectan.

Los validadores están al servicio de los profesionales de la accesibilidad, no al revés...

Artículos relacionados:

miércoles, 3 de junio de 2026

Entrevista en el podcast "Despacho 42: Accesibilidad web con Olga Carreras" de la UOC (Universitat Oberta de Catalunya)

En el mes de abril tuve el placer de participar como invitada en el podcast "Despacho 42" de la UOC (Universitat Oberta de Catalunya).

Os comparto el episodio: "Despacho 42: Accesibilidad web con Olga Carreras" (en Spotify). En él hablamos sobre accesibilidad entendida como una manera de ver el mundo, como una manera de pensar.

Al reproducir el episodio se cargarán contenidos de Spotify y podrán instalarse cookies de terceros.

Acceso a la versión del podcast "Despacho 42: Accesibilidad web con Olga Carreras" en YouTube con transcripción.

Otras entrevistas

lunes, 20 de abril de 2026

Ejemplos prácticos de cómo cumplir con el criterio "2.5.7 Movimiento de arrastre"

Este año se publicará la nueva versión de la EN 301 549 que obligará al cumplimiento de los criterios añadidos en la versión 2.2 de las WCAG, los cuales ya he explicado anteriormente en otros artículos y webinars (consultar apartado referencias sobre las WCAG 2.2). Uno de los nuevos criterios es el 2.5.7 Movimiento de arrastre.

El criterio 2.5.7 AA indica que toda funcionalidad que implique un movimiento de arrastre se tiene que poder realizar mediante un puntero sencillo sin arrastrar. Por ejemplo, mediante un solo clic o un solo toque.

El objetivo de este artículo es ilustrar un incumplimiento concreto del criterio 2.5.7 y mostrar varias alternativas de solución.

Ejemplo incorrecto

El ejemplo incorrecto que propongo es el siguiente:

Captura de una aplicación móvil que permite modificar la claridad de una imagen. Esta función se realiza mediante un deslizador que no tiene botones en los extremos.

Esta pantalla tiene un deslizador para aumentar o disminuir la claridad de la imagen. Para mover este deslizador debes pulsar, arrastrar y soltar, de tal manera que en el evento de bajada hay un elemento que sigue al puntero hasta el evento de subida.

Hay personas que no van a poder realizar este gesto o les va a resultar complicado, por eso, es necesario ofrecer una alternativa con un solo puntero.

Opciones de solución

A continuación indico tres posibles soluciones. Os adelanto que la solución ideal es aquella que tiene en cuenta las tres.

Incluir botones

El deslizador muestra botones a los lados con el símbolo de más y de menos.

En esta solución se ha incluido un botón a cada lado del control con la etiqueta visible "Más" y "Menos". Estos botones permiten mover el deslizador. De esta manera, no se depende solo del gesto de arrastrar, sino que se ofrece la alternativa de usar un puntero sencillo.

Pulsar en la barra para avanzar

El deslizador muestra botones a los lados con el símbolo de más y de menos. Además, se indica que se puede pulsar en cualquier punto del deslizador para moverlo.

En esta solución se permite que la persona pueda pulsar en cualquier parte del deslizador para moverlo. Esta opción es mucho menos precisa que los botones, por lo que se recomienda que sea una opción adicional a la de los botones.

Poder introducir el dato concreto

El deslizador muestra botones a los lados e indica que se puede pulsar en cualquier punto del deslizador para moverlo. Además, incluye un campo de formulario Porcentaje de luminosidad y un botón Cambiar.

En esta solución se incluye un campo para indicar directamente el porcentaje de luminosidad que se desea. Esta opción proporciona una forma de incluir de manera sencilla y rápida el valor exacto de luminosidad que se desea, sin depender además del gesto de arrastre.

¿Cuál es la solución ideal?

La solución ideal es implementar las tres.

  • Los botones facilitan un ajuste fino y controlado.
  • Deslizarlo con toques permite un ajuste rápido, útil para comparar de forma ágil cambios drásticos de luminosidad.
  • El campo numérico asegura una precisión absoluta y fácil de replicar. Desde mi punto de vista, es la más cómoda en el acceso por voz y, seguramente, la más útil si accedes con un lector de pantalla.

Estaremos no solo cumpliendo con un criterio de accesibilidad que permite la interacción a muchas personas con discapacidad, sino que, además, mejoraremos la experiencia de usuario para todas las personas, ofreciendo un control que se adapta a sus necesidades y preferencias.

No es lo mismo "deslizar" que "arrastrar"

Por último, recuerdo que "arrastrar" no es lo mismo que "deslizar". En el criterio 2.5.7 revisamos el movimiento de arrastre, mientras que en el criterio "2.5.1 Gestos del puntero (A)" revisamos el gesto de deslizar, que también se tiene que poder realizar mediante un solo puntero.

En la siguiente captura se observa un carrusel.

Captura de una aplicación móvil con un carrusel. El carrusel se puede desplazar con el gesto de deslizar. El carrusel tiene botones de flecha para desplazar el carrusel con un solo puntero. También dispone de botones de punto bajo el carrusel, de un tamaño muy pequeño, para saltar a un elemento concreto.

Para consultar los diferentes elementos del carrusel se utiliza el gesto de deslizar, es decir, desplazas el dedo en una dirección determinada.

El carrusel de esta captura cumple el criterio "2.5.1 Gestos del puntero" porque permite deslizarlo mediante un puntero simple a través de los botones de flecha o los botones de punto bajo el carrusel.

Referencias sobre las novedades de las WCAG 2.2

Webinar Olga Carreras "Novedades de las WCAG 2.2"

Enlace al vídeo en YouTube

Enlace a la presentación: Explorando las novedades de la WCAG 2.2. Olga Carreras Montoto.

Nota. El artículo ha sido desarrollado y escrito por Olga Carreras sin herramientas IA salvo para la corrección ortográfica. Las capturas han sido tomadas por Olga Carreras con su móvil, pero la modificación de las capturas para ilustrar las soluciones sí se ha realizado mediante una aplicación IA.