Guía de accesibilidad de PDF y PDF/UA

Los PDF son el problema silencioso de accesibilidad dentro de casi todas las organizaciones. Los sitios web se auditan, se rediseñan y se prueban con lectores de pantalla, pero el informe anual, el documento de políticas, el estado de prestaciones y el formulario de solicitud que viven detrás de un enlace de descarga se publican demasiado a menudo exactamente como salieron del cuadro de diálogo de exportación. Para un lector con visión parecen pulidos. Para alguien que usa un lector de pantalla, un magnificador o navegación solo con teclado, ese mismo archivo puede ser un muro impenetrable: sin encabezados entre los que saltar, imágenes sin descripción, tablas que se leen como un flujo de números sin sentido y campos de formulario que no se pueden rellenar en absoluto.

Esta guía explica por qué los PDF son tan a menudo inaccesibles y qué hace realmente que uno sea utilizable por la tecnología de asistencia. Cubre los bloques estructurales — etiquetas, orden de lectura, texto alternativo, tablas, formularios y metadatos — y las normas que los rigen: WCAG 2.2 y PDF/UA, la especificación ISO 14289 para PDF etiquetados accesibles. A lo largo del texto, el objetivo es el que QualiBooth aplica a cada documento que tocamos: un archivo que funcione en la práctica, confirmado con tecnología de asistencia real, no solo bendecido por un verificador automático.

Por qué los PDF suelen ser inaccesibles

Un PDF es, en esencia, una descripción de cómo pintar marcas en una página. El formato se diseñó para preservar la fidelidad visual — para que un documento se vea idéntico en cualquier pantalla o impresora. Ese objetivo de diseño es exactamente lo que hace difícil la accesibilidad. La fidelidad visual no dice nada sobre el significado. Una línea de texto en negrita de 18 puntos parece un encabezado al ojo humano, pero a menos que el archivo registre explícitamente “esto es un encabezado”, la tecnología de asistencia no tiene forma de saber que es algo más que unos glifos más grandes.

La mayoría de los PDF en circulación están sin etiquetar. Contienen el contenido visual pero ninguna de las estructuras subyacentes — ninguna información sobre qué es un encabezado, un párrafo, una lista, una tabla o una imagen. Un lector de pantalla que se enfrenta a un PDF sin etiquetar o bien se niega a leerlo de forma significativa o recurre a las conjeturas, deduciendo un orden de lectura a partir de la posición de las marcas en la página. Los resultados van de incómodos a inutilizables: un boletín a dos columnas leído de lado a lado por ambas columnas, un pie de imagen leído antes del párrafo al que pertenece, o notas al pie que interrumpen mitad de una frase.

Varios hábitos habituales de producción empeoran las cosas:

Documentos escaneados. Un escaneo es solo una imagen de una página. Sin reconocimiento óptico de caracteres (OCR), no hay texto real en absoluto — nada que leer, buscar ni seleccionar.
Exportaciones que descartan la estructura. Muchas rutas de “Guardar como PDF” e “Imprimir a PDF” descartan la estructura de encabezados y listas que existía en el documento de origen.
Maquetaciones de herramientas de diseño. Los archivos creados en software de maquetación pueden tener páginas visualmente correctas cuyo orden de objetos subyacente no guarda ninguna relación con la secuencia de lectura prevista.
Adornos decorativos. Las imágenes de fondo, las líneas y los ornamentos quedan expuestos a la tecnología de asistencia y se anuncian como si transmitieran significado.

Nada de esto es visible en pantalla, que es precisamente por lo que el problema persiste. La solución consiste en añadir la capa estructural que el formato deja opcional — la labor de la remediación de PDF.

Etiquetas y estructura del documento

Las etiquetas son el fundamento de un PDF accesible. Un PDF etiquetado lleva una jerarquía oculta — el árbol de estructura — que se sitúa junto al contenido visual y describe qué es realmente cada parte de la página. Esto es directamente análogo al HTML semántico que hay detrás de una página web bien construida: donde el HTML usa <h1>, <p>, <ul> y <table>, un PDF etiquetado usa elementos de estructura como <H1>, <P>, <L> (lista) y <Table>.

El árbol de etiquetas es lo que da a la tecnología de asistencia algo por lo que navegar. Con él en su sitio, un lector de pantalla puede hacer las cosas de las que dependen sus usuarios:

Saltar por encabezado. Los usuarios recorren un documento largo de encabezado en encabezado en lugar de escuchar cada palabra en secuencia. Esto requiere etiquetas de encabezado reales (<H1> a <H6>) aplicadas en un orden lógico y anidado — nunca saltándose niveles, nunca fingiendo un encabezado poniendo en negrita un párrafo.
Entender las listas. Una etiqueta <L> con sus elementos <LI> le dice al lector de pantalla “esto es una lista de cinco elementos”, para que el usuario sepa dónde está y cuánto queda.
Distinguir el contenido de la decoración. El contenido genuino se etiqueta; las marcas puramente decorativas se designan como artefactos para que se omitan por completo.

Una estructura de encabezados correcta y lógicamente anidada es lo único de mayor impacto que se puede acertar en un PDF, porque transforma una experiencia de escucha lineal en una navegable. Hacerlo mal — u omitirlo — es uno de los problemas de accesibilidad habituales que aparecen una y otra vez en las auditorías de documentos.

Orden de lectura

Las etiquetas dicen qué es cada elemento. El orden de lectura dice en qué secuencia se presentan esos elementos a alguien que no puede ver la página. Ambos están relacionados pero son distintos, y el orden de lectura es donde fallan muchos PDF por lo demás bien etiquetados.

Un lector de pantalla anuncia el contenido en el orden definido por la estructura del documento, no en el orden en que las marcas resultan estar en el archivo. En un documento de una sola columna, ambos suelen coincidir. En cualquier cosa más compleja — maquetaciones a varias columnas, barras laterales, citas destacadas, pies de imagen, texto que rodea una imagen — divergen con frecuencia. El ojo con visión reordena el contenido sin esfuerzo; la tecnología de asistencia sigue el orden que se le da, y si ese orden es incorrecto, el significado se desmorona.

Un buen orden de lectura significa que el contenido se anuncia en la secuencia que un lector con visión seguiría de forma natural: el titular antes del cuerpo, la introducción antes de la barra lateral, un pie de imagen después de la figura que describe. Establecerlo correctamente es un juicio manual sobre cómo se supone que debe leerse el documento, razón por la cual las herramientas automáticas por sí solas no pueden garantizarlo. Es uno de los entregables centrales de la remediación de PDF profesional y una de las primeras cosas que comprueban los evaluadores con experiencia.

Texto alternativo para imágenes

Toda imagen que transmita información necesita un equivalente textual para que pueda describirse a personas que no pueden verla. Los principios son los mismos que para la web, aplicados a través de las etiquetas de PDF.

Imágenes informativas — gráficos, diagramas, fotografías que transmiten significado, infografías — necesitan un texto alternativo conciso y preciso que comunique la misma información que la imagen. Para un gráfico, eso a menudo significa resumir la conclusión (“Los ingresos crecieron un 12 % interanual”) en lugar de describir lo visual (“un gráfico de barras en azul”).
Imágenes complejas — un diagrama de proceso detallado o una figura con muchos datos — pueden necesitar tanto un texto alternativo breve como una descripción más larga, o los datos subyacentes presentados de forma accesible en otra parte del documento.
Imágenes decorativas — bordes, texturas de fondo, separadores ornamentales, un logotipo repetido en un pie de página — deben marcarse como artefactos para que la tecnología de asistencia las omita. Obligar a un lector de pantalla a anunciar “imagen, imagen, imagen” por decoración es en sí mismo un fallo de accesibilidad.
Texto dentro de imágenes — un gráfico de una cita, un membrete escaneado, la imagen de un botón con una etiqueta — debe tener ese texto capturado, ya sea como texto alternativo o, mejor aún, como texto real seleccionable.

Escribir un buen texto alternativo es una tarea de contenido, no técnica. Requiere entender para qué sirve la imagen en su contexto — la misma habilidad que aporta nuestro equipo de consultoría de accesibilidad al contenido web.

Tablas accesibles

Las tablas son donde la accesibilidad de PDF se vuelve genuinamente difícil, y donde las exportaciones automáticas fallan más a menudo. Una tabla de datos comunica significado mediante la relación entre una celda y sus encabezados de fila y columna. Los lectores con visión reconstruyen esas relaciones visualmente echando un vistazo hacia arriba y a la izquierda. Un usuario de lector de pantalla no puede — depende de que la tabla esté marcada de modo que las asociaciones de encabezados sean explícitas.

Una tabla PDF accesible necesita:

Una estructura <Table> adecuada que contenga <TR> (filas), <TH> (celdas de encabezado) y <TD> (celdas de datos), en lugar de una cuadrícula suelta de texto posicionado para parecer una tabla.
Celdas de encabezado correctamente identificadas, con alcance (fila o columna) donde la maquetación de la tabla lo requiera, de modo que, a medida que el usuario recorre los datos, los encabezados pertinentes se vuelvan a anunciar (“T3, Ingresos, 1,2 millones”).
Un manejo sensato de las celdas combinadas o que abarcan varias, que complican las relaciones de encabezados y a menudo confunden a las herramientas automáticas.

Un antipatrón habitual es la tabla de maquetación — una cuadrícula usada puramente para posicionar contenido visualmente, sin relaciones de datos reales. Las tablas de maquetación no deben etiquetarse como tablas en absoluto, porque hacerlo obliga a la tecnología de asistencia a anunciar filas y columnas fantasma. Distinguir una tabla de datos de un artefacto de maquetación, y luego codificar las relaciones correctas, es un trabajo manual detallado que se beneficia enormemente de la revisión por personas que realmente usan lectores de pantalla a diario.

Formularios PDF accesibles

Los formularios son los documentos de mayor importancia que publica una organización, porque son transaccionales: una solicitud, una reclamación, un consentimiento, un registro. Si un formulario PDF no se puede completar con tecnología de asistencia, la persona no solo sufre una molestia — queda excluida de un servicio.

Un formulario PDF accesible requiere:

Campos etiquetados. Cada campo — entrada de texto, casilla de verificación, botón de opción, lista desplegable — necesita un nombre accesible (en términos de PDF, una información sobre herramientas o etiqueta) para que un lector de pantalla anuncie para qué sirve el campo, no solo “editar texto”.
Orden de tabulación lógico. Los usuarios de teclado recorren los campos con el tabulador. El orden de tabulación debe seguir el flujo visual y lógico del formulario, no el orden en que se añadieron los campos en el editor.
Controles agrupados. Los botones de opción y casillas de verificación relacionados deben agruparse para que su pregunta compartida se anuncie una vez y las opciones se entiendan como un conjunto.
Campos obligatorios e instrucciones. Los campos obligatorios, los requisitos de formato y la orientación sobre errores deben transmitirse en texto, no solo mediante color o señales visuales.
Plena operabilidad con teclado. Todo campo debe ser alcanzable y operable sin ratón.

Los formularios se sitúan en la intersección de la estructura, la interacción y el contenido, lo que los convierte en la parte del trabajo con PDF donde más importa hacerlo correctamente. La misma disciplina se aplica a otros documentos transaccionales — está estrechamente relacionada con el cuidado necesario para el correo electrónico accesible, donde la estructura y el etiquetado determinan si un mensaje puede usarse realmente.

Idioma, título y metadatos

Algunas de las correcciones de PDF más impactantes son también las más pequeñas. Un puñado de propiedades a nivel de documento cambia materialmente cómo maneja un archivo la tecnología de asistencia.

Idioma del documento. El PDF debe declarar su idioma principal (por ejemplo, en-GB) para que un lector de pantalla use las reglas de pronunciación correctas. Un párrafo en francés leído con fonética inglesa, o viceversa, apenas es inteligible. Los pasajes en un idioma distinto del documento principal deben llevar sus propios marcadores de idioma.
Título del documento. Los metadatos del PDF deben incluir un título significativo, y el visor debe configurarse para mostrar ese título en lugar del nombre del archivo. “Informe anual de accesibilidad 2026” se anuncia y se muestra; “final_v3_FORWEB.pdf” no.
Navegación por tabulación y marcadores. Los marcadores (el esquema del documento) dan a todos los usuarios — y en especial a quienes navegan de forma no visual — una forma de saltar a las secciones principales de un documento largo.
Indicadores de PDF etiquetado y metadatos limpios. El archivo debe estar marcado como PDF etiquetado y llevar metadatos coherentes y precisos.

Estas propiedades tardan minutos en establecerse y son necesarias para la conformidad, pero se omiten en la inmensa mayoría de los PDF publicados.

WCAG 2.2 y PDF/UA (ISO 14289)

Dos normas rigen los PDF accesibles, y funcionan juntas en lugar de competir.

WCAG 2.2 es la base agnóstica respecto a la tecnología para la accesibilidad digital. Sus criterios de éxito — alternativas textuales, información y relaciones, secuencia significativa, contraste, operabilidad con teclado y el resto — se aplican a los PDF igual que se aplican a las páginas web. WCAG 2.2 es la norma a la que apuntan la mayoría de las leyes, y el W3C publica técnicas específicas para satisfacer WCAG con las funciones de PDF (etiquetar encabezados, proporcionar texto alternativo, definir el orden de lectura, etc.). Si está abordando la conformidad general, nuestra guía para hacer que el contenido cumpla con WCAG y la visión general de conformidad con WCAG se aplican ambas directamente a los documentos.

PDF/UA — formalmente ISO 14289 — es la especificación técnica para PDF accesible. Donde WCAG describe resultados (“proporcionar alternativas textuales”), PDF/UA prescribe exactamente cómo debe construirse un PDF para ser un documento accesible, correctamente etiquetado y legible por máquina: qué tipos de estructura usar, cómo debe formarse el árbol de etiquetas, cómo deben marcarse los artefactos y cómo deben codificarse los formularios y las tablas. Ambas son complementarias — el enfoque más robusto es remediar conforme a los requisitos técnicos de PDF/UA mientras se validan los resultados de cara al usuario conforme a WCAG 2.2.

La conformidad con estas normas es lo que sustenta las obligaciones legales en distintas jurisdicciones. Los PDF publicados por organizaciones cubiertas caen de lleno dentro de la European Accessibility Act, la ADA y la Section 508, todas las cuales tratan los documentos descargables como parte de la experiencia digital que debe ser accesible.

Remediar PDF existentes frente a crear PDF accesibles

Hay dos vías hacia los PDF accesibles, y la mayoría de las organizaciones necesitan ambas.

Remediar PDF existentes significa tomar un archivo terminado — un informe, un histórico de estados de cuenta, un formulario escaneado — y añadir o corregir la capa de accesibilidad: ejecutar OCR donde sea necesario, construir el árbol de etiquetas, establecer el orden de lectura, escribir texto alternativo, arreglar tablas y etiquetar campos de formulario. La remediación es esencial cuando los archivos de origen se han perdido, cuando los documentos los produjeron terceros, o cuando se tiene un archivo publicado que hay que poner en conformidad. Es crucial que la remediación cambia la estructura subyacente, no el diseño visual — el documento se ve idéntico y pasa a ser utilizable para todos. Este es el núcleo del servicio de remediación de PDF de QualiBooth, que delimita lotes por importancia y alcance y prioriza primero los documentos que más importan.

Crear PDF accesibles significa incorporar la accesibilidad al proceso de producción para que los documentos nazcan accesibles. Eso implica usar estilos de encabezado, estilos de lista y texto alternativo reales en la aplicación de origen; diseñar las tablas como tablas de datos; establecer idioma y título; y elegir una ruta de exportación que conserve el árbol de etiquetas. Crear de forma accesible es drásticamente más barato que reparar el mismo documento después, y es la única respuesta sostenible para las organizaciones que publican PDF de forma continua.

Los dos enfoques no son excluyentes. El patrón práctico es remediar los documentos que ya están circulando mientras se arregla el proceso anterior para que los nuevos documentos no recreen el problema. Integrar ese cambio es exactamente lo que aborda la mejora de procesos de accesibilidad — convertir la publicación accesible de un proyecto puntual en la forma predeterminada de trabajar de su equipo. Una visión más amplia de cómo encajan el trabajo de documentos y el de la web se expone en nuestra visión general de servicios de accesibilidad.

Validar con lectores de pantalla — y por qué los overlays no ayudan

Un PDF solo es accesible si funciona realmente para las personas que dependen de él. Por eso la validación no puede detenerse en un verificador automático. Las herramientas que escanean un PDF conforme a las reglas de PDF/UA son valiosas — detectan etiquetas faltantes, idiomas sin definir y errores estructurales a gran escala — pero verifican la presencia de la estructura, no su calidad. Una herramienta automática puede confirmar que una imagen tiene texto alternativo; no puede decirle que el texto alternativo es incorrecto. Puede confirmar que existe un encabezado; no puede decirle que está anidado en el nivel equivocado.

La validación real combina ambos:

Comprobación automática para detectar fallos estructurales y de metadatos de forma amplia y coherente. Software como la plataforma de escaneo de accesibilidad de QualiBooth destaca en señalar problemas detectables por máquina en grandes volúmenes.
Pruebas manuales con tecnología de asistencia — navegar por el documento con un lector de pantalla, moverse por encabezado, leer tablas, tabular por un formulario — para confirmar que la experiencia es coherente. Esta es la única forma de verificar el orden de lectura, la calidad del texto alternativo y la usabilidad del formulario. Nuestra metodología de auditoría manual explica por qué las pruebas humanas son irremplazables, y las auditorías realizadas por personas con discapacidad sacan a la luz problemas que ningún verificador ni evaluador con visión notaría jamás.

Una advertencia sobre los atajos. Los overlays de accesibilidad — scripts o widgets de terceros que afirman corregir la accesibilidad automáticamente — no resuelven la accesibilidad de PDF, y QualiBooth no los respalda. No pueden crear un árbol de etiquetas correcto, ni juzgar el orden de lectura, ni escribir texto alternativo significativo, porque esas tareas requieren entender el contenido y la intención del documento. No hay sustituto automático para una remediación adecuada. La accesibilidad de PDF genuina proviene de una estructura correcta más verificación humana — el enfoque que hay detrás de nuestro trabajo de remediación de PDF.

Preguntas frecuentes

¿Es aceptable alguna vez un PDF sin etiquetar? No. Un PDF sin etiquetar es inaccesible para la tecnología de asistencia por definición y no cumple ni con WCAG 2.2 ni con PDF/UA. Cualquier PDF que publique para el público o para empleados debe estar etiquetado.

¿Hacer accesible un PDF cambia su aspecto? No. La remediación añade y corrige la capa estructural oculta — etiquetas, orden de lectura, metadatos — sin alterar el diseño visual. La página se ve idéntica.

¿Debería ofrecer simplemente una versión HTML en lugar de un PDF accesible? Una alternativa HTML accesible suele ser la mejor experiencia y vale la pena ofrecerla. Pero si publica el PDF, el propio PDF debe ser accesible — una alternativa HTML no exime al documento de los requisitos de conformidad.

¿Pueden hacerse accesibles los documentos escaneados? Sí, pero antes hay que pasarles OCR para crear texto real, tras lo cual se aplican los pasos normales de remediación — etiquetado, orden de lectura, texto alternativo, tablas.

¿Cómo mantengo accesibles los PDF nuevos sin remediar cada uno? Arregle el proceso de creación: use estilos y texto alternativo reales en el origen, diseñe tablas de datos adecuadas, establezca idioma y título y exporte por una ruta que conserve las etiquetas. Combinar la remediación con la mejora de procesos hace que los documentos accesibles sean lo predeterminado.

Conclusión

La accesibilidad de PDF no es un paso opcional de pulido — es la diferencia entre un documento que todos pueden usar y uno que excluye silenciosamente a las personas que dependen de la tecnología de asistencia. El trabajo es concreto y bien entendido: etiquetar la estructura, establecer un orden de lectura correcto, describir las imágenes, codificar tablas y formularios adecuadamente, declarar idioma y título y validar el resultado conforme a WCAG 2.2 y PDF/UA con lectores de pantalla reales además de herramientas automáticas. Remedie los documentos que ya publica, arregle el proceso que produce los nuevos y evite los atajos de overlays que prometen accesibilidad sin entregarla.

Si sus informes, estados de cuenta, folletos o formularios nunca se han comprobado, ese es el punto por donde empezar. Puede comenzar con un escaneo de accesibilidad gratuito, solicitar una demo de la plataforma QualiBooth, o hablar con nuestro equipo sobre la remediación de PDF para un único documento crítico o todo un histórico.