Guía Última comprobación: octubre de 2026 Lectura de 6 min

PDF accesibles: qué importa y cuándo usar HTML

Muchos sitios web ofrecen menús, listas de precios, formularios y folletos en PDF. Para quienes usan un lector de pantalla, el zoom o solo el teclado, un PDF sin estructura puede ser una puerta cerrada. Aquí verás qué hace accesible un PDF, qué puede detectar una revisión y cuándo una página web es la mejor opción.

Cuándo un PDF se convierte en una barrera

Un PDF puede verse perfecto y aun así no servir. Un lector de pantalla no ve el diseño. Necesita estructura: qué texto es un encabezado, cuál es una lista, cuál es una tabla y en qué orden se lee todo. Si falta esa información, el contenido sale como un largo flujo de texto, en el orden equivocado o directamente no sale.

Problemas típicos: una página escaneada que es solo una imagen, un diseño a dos columnas que se lee de lado a lado atravesando ambas, una tabla sin celdas de encabezado, un formulario cuyos campos no tienen nombre e imágenes sin alternativa textual. El W3C describe cómo evitar cada uno en sus técnicas PDF para las WCAG. Las técnicas son ejemplos de cómo cumplir las WCAG, no un requisito en sí mismas.

Qué hace accesible un PDF

Etiquetas: un PDF etiquetado tiene un árbol de estructura en el que los encabezados, párrafos, listas y tablas están marcados como tales. Sin etiquetas, las tecnologías de apoyo apenas tienen con qué trabajar.
Orden de lectura: el orden de las etiquetas decide qué se lee primero. Revísalo sobre todo en columnas, cuadros de texto y barras laterales. El orden de tabulación de enlaces y campos de formulario debe seguir la misma lógica.
Título del documento: pon un título con sentido en las propiedades del documento y haz que el visor lo muestre en lugar del nombre del archivo.
Idioma del documento: indica el idioma principal para que el lector de pantalla use la pronunciación correcta. Marca aparte los pasajes en otro idioma.
Texto alt para figuras: las imágenes informativas llevan una alternativa textual en su etiqueta Figure. Las imágenes puramente decorativas se marcan como artefactos, para que los lectores de pantalla las salten.
Texto real en lugar de escaneos: una página escaneada es una imagen de texto. Crea el PDF a partir del archivo de origen siempre que puedas. Si no lo hay, el reconocimiento de texto (OCR) convierte el escaneo en texto real. Después comprueba que todo el texto está ahí y en el orden correcto.
Encabezados de tabla: las tablas de datos se construyen con celdas de tabla, fila, encabezado y datos. Las celdas de encabezado deben estar marcadas como encabezados, no solo en negrita.
Marcadores: los documentos de más de unas pocas páginas llevan marcadores, a ser posible creados a partir de los encabezados. Ayudan a todos a tener una visión general sin hojear todo el archivo.
Campos de formulario: cada campo tiene un nombre vinculado a él de forma programática, por ejemplo mediante la información sobre herramientas del campo. Una etiqueta solo impresa junto al campo no basta.

Empieza en el archivo de origen

Casi todo esto es más fácil en el programa donde escribes el documento. Usa allí encabezados, listas y filas de encabezado de tabla reales, añade texto alt a las imágenes, pon título e idioma y exporta un PDF etiquetado. Los diseños complejos pueden salir aun así en el orden equivocado y entonces hay que repararlos en un editor de PDF.

Qué detecta una revisión automática y qué no

Una herramienta puede leer propiedades técnicas: ¿hay título, idioma, árbol de estructura? ¿Tienen las figuras una entrada alt? Son buenas primeras preguntas, y una respuesta que falta es un hallazgo claro.

Una herramienta no puede juzgar si un texto alt dice lo correcto, si el orden de lectura tiene sentido, si están marcadas como encabezado las celdas correctas o si el reconocimiento de texto ha acertado cada número. El W3C lo dice claramente: las herramientas de evaluación no pueden determinar la accesibilidad, solo pueden ayudar, y hace falta el juicio humano. Cuatro comprobaciones manuales llevan solo unos minutos:

1Abre el PDF. ¿Muestra la ventana un título real en lugar del nombre del archivo?
2Escucha las primeras páginas con un lector de pantalla o una función de lectura en voz alta. ¿Se leen los encabezados, las columnas y las tablas en un orden lógico?
3Guarda el PDF como texto. ¿Está todo el texto, en el orden correcto, y son correctos los números?
4Recorre los enlaces y campos de formulario con la tecla Tab. ¿Tiene sentido el orden y anuncia cada campo su nombre?

Cuándo es mejor una página HTML

Pregúntate qué quieren hacer los visitantes con el contenido. Horarios, menús, listas de precios, instrucciones breves y todo lo que cambia a menudo suelen funcionar mejor como página web normal. Una página se adapta a pantallas pequeñas y al zoom, se puede encontrar y enlazar directamente, y solo hay una versión que mantener al día.

Un PDF sigue teniendo sentido para documentos que la gente imprime, firma o archiva, o que deben mantener un diseño fijo. Si mantienes el PDF, ofrece también el contenido clave como página web o, como mínimo, asegúrate de que el PDF esté etiquetado y revisado.

Trabaja con Do4U

La herramienta Comprobar accesibilidad del PDF lee un PDF de hasta 2 MB e informa del título, el idioma, las etiquetas de estructura y las figuras sin alternativa. El orden de lectura siempre se marca para revisión manual, porque una herramienta no puede juzgarlo.

Convertir documentos en HTML crea un borrador a partir de una página de PDF o una imagen cada vez: HTML semántico con encabezados, listas y tablas, además de texto plano. Compara cada palabra, número y tabla con el original, y repite el trabajo para cada página en el orden de lectura.

Ambas herramientas te dan hallazgos y borradores. No sustituyen una revisión por personas, a ser posible con alguien que use un lector de pantalla. Vuelve a revisar tras cada nueva versión del documento.