La decisión que condiciona todos los pasos posteriores es el entorno de autoría. Un PDF generado a partir de un documento InDesign correctamente estructurado con la acción Convertir en accesible aplicada lleva el 80 por ciento de sus metadatos de accesibilidad antes de que nadie abra Acrobat. Un PDF exportado desde un documento Word en el que los títulos se simularon con texto en negrita y de mayor tamaño no lleva casi ninguno, y ninguna cantidad de corrección posterior podrá rescatarlo completamente. La elección de la herramienta de autoría, en otras palabras, no es estética. Es estructural.

En 2026 dominan tres flujos de producción en la publicación institucional. Adobe InDesign con la acción Convertir en accesible es el estándar para documentos compuestos tipográficamente — informes anuales, libros de texto, expedientes regulatorios — donde la maquetación es fija y el archivo sale del equipo de diseño una sola vez. Microsoft Word con Guardar como PDF accesible es la opción habitual para documentos de oficina — políticas, contratos, cartas — donde la fuente se edita de forma continua y el PDF es una representación, no un destino. LibreOffice con el traspaso al Comprobador de Accesibilidad de PDF es la vía de código abierto utilizada por gobiernos y universidades que tienen razones de política para evitar los ecosistemas de Microsoft y Adobe.

Bajo todo PDF accesible existe una estructura lógica paralela — la estructura de etiquetas — que no tiene nada que ver con la maquetación visual. El PDF visible es un conjunto de instrucciones de representación con coordenadas. La estructura de etiquetas es un modelo de objetos de documento jerárquico separado que indica esta operación de representación es el primer encabezado, aquella es la tercera viñeta de la segunda lista, esta imagen es decorativa, aquella otra tiene el texto alternativo «Ingresos trimestrales por segmento, EF24». Un lector de pantalla lee la estructura de etiquetas, no la representación visual.

Seis categorías de etiquetas concentran la mayor parte del significado en los documentos del mundo real: los encabezados (H1 a H6) forman el esquema navegable; los párrafos (P) son las secuencias de prosa; las listas (L, LI, Lbl, LBody) son las enumeraciones ordenadas o no ordenadas; las tablas (Table, TR, TH, TD) son las cuadrículas de datos con encabezados de columna y fila expuestos mediante el atributo Scope; las figuras (Figure) llevan el texto alternativo en su atributo Alt o ActualText; y el orden de lectura, que es el recorrido en profundidad primero del árbol, dicta la secuencia en que un lector de pantalla habla el documento. Una página que visualmente tiene dos columnas puede leerse en el orden equivocado si la estructura de etiquetas sitúa la columna derecha antes que la izquierda.

Otros dos atributos importan en cada etiqueta de un archivo correctamente producido. El atributo de idioma (Lang) indica al lector de pantalla qué diccionario de pronunciación utilizar — el francés citado dentro de un párrafo en español necesita su propio atributo Lang en una etiqueta Span, o se leerá con fonemas españoles. Y el marcador de artefacto distingue el contenido decorativo del estructural; los encabezados, pies de página, números de página y reglas decorativas deben marcarse como artefactos para que el lector de pantalla los omita.

PDF/UA es la norma internacional para los PDF accesibles, publicada como ISO 14289-1 en 2014 y actualizada en 2024. Donde WCAG es neutral respecto a la tecnología y la plataforma, PDF/UA es específica del PDF — es el contrato entre el software productor de documentos, el software consumidor de documentos y la tecnología de apoyo que establece que la estructura de etiquetas, los metadatos y la estructura de este archivo se ajustan a un conjunto verificable de condiciones, de modo que un lector conforme puede fiarse de ellos.

La norma se operacionaliza a través del Protocolo Matterhorn, mantenido por la PDF Association, que descompone PDF/UA en 31 condiciones de fallo numeradas con variantes verificables tanto por máquina como por persona. Los fallos verificables por máquina incluyen la ausencia de un título de documento en los metadatos, la presencia de figuras sin Alt o ActualText, listas estructuradas fuera de etiquetas L/LI y atributos de idioma ausentes en el documento o en secuencias con cambio de idioma. Los fallos verificables por personas cubren lo que el software no puede verificar por sí solo — si el texto alternativo de una Figure realmente describe la figura, si el orden de lectura coincide con la secuencia lógica, si los encabezados están anidados de forma lógica en lugar de saltarse niveles.

La actualización de 2024 alineó PDF/UA con los criterios de conformidad de WCAG 2.2 y aclaró el tratamiento de las firmas digitales y los formularios — los formularios PDF accesibles deben exponer etiquetas de campo, información sobre herramientas del campo y orden de tabulación, y los PDF firmados no deben bloquear el acceso del lector de pantalla a la estructura de etiquetas subyacente después de la firma.

Cuando llega un PDF sin una estructura de etiquetas utilizable — y la mayoría de los PDF heredados llegan así — la elección del ingeniero se reduce a cuatro entornos de corrección. Cada uno tiene una combinación diferente de puntos fuertes en la edición de la estructura de etiquetas, el reconocimiento óptico de caracteres para originales escaneados, el procesamiento por lotes y la generación de informes de PDF/UA. La siguiente matriz relaciona la capacidad con la herramienta.

Un PDF correctamente etiquetado es solo la mitad de la cadena correspondiente al productor. La otra mitad es el lector de pantalla, y los cuatro lectores que la mayoría de los usuarios utiliza realmente tratan el mismo archivo de formas sutilmente diferentes. Las diferencias importan porque un documento que se lee limpiamente en JAWS puede fallar en NVDA, y un archivo que funciona en VoiceOver en macOS puede comportarse de forma diferente cuando el mismo archivo es abierto por ChromeVox en el visor de PDF integrado de Chrome.

JAWS tiene la compatibilidad con PDF más profunda y antigua de cualquier lector de pantalla comercial. Su modo PDF renderiza los PDF etiquetados a través de Acrobat o Acrobat Reader y expone la estructura de etiquetas directamente — lista de encabezados (Insert+F6), lista de formularios (Insert+F5), navegación por celdas de tabla con las teclas estándar de tabla de JAWS. Cuando un PDF carece de etiquetas, JAWS ofrecerá inferir la estructura, pero el resultado inferido no es fiable; los ingenieros no deben validar contra lecturas inferidas por JAWS.

NVDA también lee los PDF etiquetados a través de Acrobat o Acrobat Reader, con navegación en modo exploración que refleja su modelo de página web — H para saltar encabezados, K para saltar enlaces, T para saltar tablas. La compatibilidad de NVDA con PDF ha mejorado notablemente desde 2022, pero sigue por detrás de JAWS en tablas complejas y campos de formulario. NVDA ofrece una respuesta más honesta ante documentos con etiquetas mal formadas: donde JAWS puede continuar, NVDA tiende a quedarse en silencio, lo que resulta útil como diagnóstico.

VoiceOver en macOS lee los PDF a través de Preview y Safari con navegación por rotor (VO + U) sobre encabezados, enlaces, tablas y campos de formulario. VoiceOver es el más indulgente de los cuatro — reconstruirá un orden de lectura incluso para archivos mal etiquetados — pero su indulgencia puede ocultar fallos reales. Un documento que se lee de forma aceptable en VoiceOver debe verificarse igualmente con JAWS o NVDA, no al revés.

ChromeVox en ChromeOS, y el comportamiento general de cualquier lector de pantalla que interactúa con el visor de PDF integrado de Chrome, pertenece a una categoría diferente. El visor de PDF de Chrome rasteriza y re-extrae el texto en lugar de renderizar la estructura de etiquetas original, de modo que un PDF con una estructura de etiquetas limpia puede perder gran parte de su estructura cuando se abre directamente en Chrome. La solución alternativa para contextos críticos de accesibilidad es forzar la descarga del archivo y abrirlo en Acrobat Reader, o bien proporcionar una versión HTML alternativa.

Uniendo la cadena: un único PDF accesible pasa por seis pasos concretos. Son secuenciales — omitir cualquiera de ellos produce un archivo que fallará en uno de los pasos posteriores o en manos del usuario.

Los equipos que tratan la accesibilidad del PDF como un problema de corrección en el último pase acaban pagando la factura dos veces — una para corregir un archivo producido sin intención estructural, y otra cada vez que ese archivo se actualiza. Los equipos que lo tratan como un problema de autoría construyen la estructura de etiquetas en la fuente, la regeneran limpiamente con cada revisión y utilizan PAC y un lector de pantalla como verificación, no como reparación. La diferencia de coste entre ambas posturas es grande; la diferencia de accesibilidad es mayor.

La cadena documentada anteriormente es deliberadamente agnóstica respecto a las herramientas en cada eslabón. Independientemente de si el origen es InDesign o LibreOffice, el editor es Acrobat o Foxit, el verificador es PAC y el lector de pantalla es JAWS o NVDA, la lógica estructural es la misma: los estilos de párrafo se asignan a etiquetas, las etiquetas se ajustan a PDF/UA, PDF/UA lo verifica PAC y los lectores de pantalla leen el resultado. Las herramientas cambian; la cadena no.

Para los equipos de contratación y cumplimiento, la implicación operativa es que las declaraciones de accesibilidad sobre PDF deben hacer referencia a la cadena de producción — la herramienta de autoría, la acción de exportación, el verificador — y no solo al resultado de un comprobador de Acrobat. Para los equipos de ingeniería, la implicación es que la estructura de etiquetas es la fuente de verdad, y se construye antes del PDF que el usuario vea. Para un recorrido práctico de producción que complemente esta guía, véase el manual paso a paso de accesibilidad en PDF.