> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/es/mas-temas/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Una introducción a los archivos PDF etiquetados: funcionamiento interno y los desafíos de la accesibilidad ## Actualización: enero de 2026 Consulte [las instrucciones de Overleaf para crear PDF etiquetados](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). El [El equipo de LaTeX](https://latex-project.org/) ha publicado nuevas funciones que permiten el etiquetado automático de PDF, el requisito central para la accesibilidad de PDF. Estas nuevas funciones están disponibles en Overleaf en [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), con actualizaciones más recientes disponibles en la versión continua de TeX Live disponible a través de [Overleaf Labs](https://www.overleaf.com/labs/participate). Ahora es posible producir un PDF etiquetado a partir del código fuente de LaTeX que cumple con el nivel AA de WCAG 2.1 siguiendo [nuestra documentación para usuarios](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) usando las versiones de TeX Live disponibles en Overleaf. El artículo que aparece a continuación, de 2020, aunque no está actualizado con la información más reciente sobre accesibilidad en LaTeX, puede seguir leyéndose por interés y como información de contexto sobre el etiquetado de PDF. *** ## ¿Qué cubre este artículo? El objetivo de este artículo es ofrecer una introducción al PDF etiquetado junto con una visión general de algunos de los desafíos técnicos a los que se enfrentan programas como los motores TeX y LaTeX, cuyo objetivo es producir archivos PDF etiquetados y accesibles. La accesibilidad, en particular la de los PDF, es un tema amplio y complejo, que también presenta desafíos técnicos que no siempre tienen una única solución universalmente acordada o aceptada, como por ejemplo cómo representar matemáticas complejas dentro de PDF de una manera accesible: ¿usando MathML o código LaTeX? Aunque no podemos profundizar en todos los temas y tenemos que simplificar muchos detalles, podemos echar un vistazo al interior de los PDF para mostrar qué implica realmente etiquetar un PDF. Overleaf espera que este artículo sirva como una introducción útil, proporcionando suficiente contexto para permitir a los lectores comprender mejor los desafíos técnicos y apoyar su lectura e investigación posteriores sobre el PDF etiquetado y la accesibilidad. Los recursos incluidos en este artículo son: * [un vídeo de 8 minutos](#video-showing-the-logical-structure-of-a-tagged-pdf) explorando un PDF etiquetado producido por LaTeX; * [un proyecto de Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) para explorar el uso de caracteres de espacio en LuaTeX; * [grabaciones de audio](#tagged-yes-but-the-reading-order-is-incorrect) que muestran problemas de accesibilidad en PDF. ## Introducción Garantizar la accesibilidad del contenido digital es acertadamente reconocido como un aspecto importante de la producción y difusión de contenido. Además, los gobiernos, incluido el [Reino Unido](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) y el [Estados Unidos](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), están aprobando leyes que exigen que el contenido producido bajo su jurisdicción cumpla criterios de accesibilidad definidos. Cumplir mediante la difusión de contenido en HTML no supone una carga excesiva, pero garantizar el nivel requerido de accesibilidad para los documentos distribuidos en formato PDF puede ser un desafío técnico significativo, dependiendo del software utilizado para redactar el contenido destinado a salir como archivo PDF. El PDF surgió a principios de la década de 1990 como solución a los problemas relacionados con la transferencia fiable de documentos, y la historia ha demostrado que ha tenido un éxito enorme. Sin embargo, PDF es también un formato de archivo complejo que apareció antes de que se reconociera y aceptara ampliamente la necesidad de facilitar la accesibilidad del contenido de los documentos. No obstante, con el tiempo, la especificación PDF ha evolucionado para ofrecer funciones que permiten y respaldan la producción de documentos PDF accesibles mediante una variante “estilizada” de PDF que Adobe llama *PDF etiquetado*. En la práctica, la producción de PDF etiquetados—*y plenamente accesibles*—impone importantes requisitos técnicos adicionales al software que genera PDF, y eso incluye a los motores TeX y al ecosistema de macros y paquetes LaTeX adicionales. ## Génesis del PDF como papel digital de forma final El [la génesis del Formato de Documento Portátil (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) se remonta a una época en la que la transferencia de documentos entre ordenadores estaba plagada de dificultades, a menudo causadas por conversiones de archivo que provocaban reorganización de páginas y otras discrepancias agravadas por fuentes y codificaciones de texto incompatibles utilizadas en distintos sistemas operativos (especialmente Windows y Macintosh). El autor de este documento trabajaba en el sector editorial en ese momento y tiene vívidos recuerdos de haber lidiado con esos desafíos. PDF fue diseñado para abordar los problemas de intercambio de archivos mediante la introducción de un papel digital universal, de forma final (no editable), que permite la transferencia fluida de documentos autocontenidos que incluían las fuentes necesarias para mostrarlos. Por fin los usuarios podían transferir todo tipo de documentos con una certeza razonable de que los destinatarios, independientemente de la plataforma informática, podrían abrirlos y leerlos: se preservaba la fidelidad del documento y la engorrosa reorganización de páginas y la compatibilidad/disponibilidad de fuentes pasaban a la historia. ### ¿Papel digital: bueno para todos los usuarios? La genealogía del PDF, como forma de papel digital, asumía naturalmente el uso de números de página impresos, la tipografía o elementos de diseño como indicios para la navegación visual de su contenido, en pantalla o en papel. Sin embargo, esos indicios/mecanismos visuales, por supuesto, carecen de significado para las personas con discapacidad visual grave. Hoy en día, la mejora de la accesibilidad del contenido digital es acertadamente reconocida como un aspecto importante de la producción y difusión de contenido. El desafío para PDF fue proporcionar mecanismos que faciliten el acceso no visual al contenido encerrado en un “contenedor” diseñado originalmente para reproducir el medio visual de la página impresa. La primera versión de la especificación PDF (PDF 1.0) fue [publicada oficialmente el 15 de junio de 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) seguida por nuevas versiones con actualizaciones que, en 2001 (PDF 1.4), incluyeron la introducción del “PDF etiquetado”, que [“...permitió a los usuarios de tecnologías de asistencia”](https://www.adobe.com/accessibility/pdf.html). Las versiones posteriores de la especificación PDF han ampliado y mejorado las funciones de PDF, culminando en la última versión (PDF 2.0) que, según [informes](https://www.pdfa.org/tagged-pdf-2-0/), ha reformado significativamente las funciones de accesibilidad, aunque PDF 2.0 todavía no cuenta con un buen soporte por parte de los motores TeX. ## Contenido dentro de los PDF Para apreciar los problemas implicados, vale la pena examinar cómo los archivos PDF representan realmente el contenido de la página que contienen. En lo profundo de un archivo PDF, el contenido de cada página reside en el *flujo de contenido*: una secuencia de operadores PDF (“comandos”) que colocan texto o gráficos en una ubicación determinada de la página para su renderizado (visualización) por el software utilizado para *ver* el PDF. En efecto, el flujo de contenido proporciona una descripción gráfica o “receta” que indica a las aplicaciones que visualizan PDF cómo “dibujar” cada página, definiendo qué debe mostrarse en la página y dónde. Naturalmente, esa serie de operadores incluye instrucciones para elegir fuentes concretas a un tamaño específico, seleccionar colores, definir anchos de línea, dibujar líneas, curvas y demás: todo lo necesario para proporcionar una descripción gráfica completa para la presentación visual de una página. Para reducir el tamaño del archivo, los flujos de contenido de PDF se comprimen y se almacenan en un formato binario compacto, pero si tiene acceso a software adecuado, como Adobe Acrobat Pro DC, puede utilizarlo para ver una versión en texto plano “descomprimida” de los flujos de contenido de las páginas. Consideremos cómo podrían los operadores PDF “dibujar” una tabla: el flujo de contenido del PDF contendría una secuencia apropiada de operadores para producir líneas horizontales/verticales, seleccionar distintas fuentes y mostrar texto colocado en varias ubicaciones de la página para producir el contenido de la tabla. Para demostrarlo, consideremos un documento PDF muy sencillo sin etiquetar que no contiene más que una tabla básica con algo de texto, creada en Microsoft Word por razones que se harán evidentes más adelante en el artículo. Aquí hay una captura de pantalla que muestra nuestro sencillo PDF: ![Una tabla creada en Microsoft Word](/files/6b94eb6803c56a7e9455b62840d894acf4822245) Si extraemos el flujo de contenido de la página (descomprimido) de este archivo y pegamos las primeras líneas en un editor de texto, podemos resumir algunos de los operadores PDF para obtener una “idea” de cómo los archivos PDF “describen” el contenido mostrado en esta página. ![Imagen del flujo de contenido en un archivo PDF](/files/e4327bbe461f33d2087581b9f79ab9475eda9019) Si tiene acceso a Adobe Acrobat Pro DC, puede utilizarlo para listar los operadores contenidos en el flujo de contenido de una página PDF. Aquí está la *estructura interna del PDF* vista del mismo PDF en Acrobat, que proporciona amablemente una descripción en una sola línea de cada operador utilizado para “dibujar” nuestra única página que contiene una tabla básica; observe que estas breves descripciones las proporciona Adobe Acrobat Pro DC, no *no* están presentes en el propio archivo PDF: ![Imagen de un flujo de contenido PDF visto en Adobe Acrobat Pro DC](/files/1568a120d178d4d7560f40358c34da090e26b518) Sin embargo, observe que ninguna de esas instrucciones de dibujo (operadores) almacena ningún “significado” o “descripción” de lo que realmente producen: son solo un conjunto de operadores gráficos que dan lugar a la construcción de lo que un *observador con vista reconoce* como una tabla. Evidentemente, para quienes tienen una discapacidad visual grave, mostrar la tabla que resulta de esos operadores gráficos en el flujo de contenido del PDF no es un método viable para acceder a ese contenido. Lo que se necesita es un mecanismo para que los archivos PDF contengan una descripción no visual adecuada (legible por máquina) de esa tabla y, por supuesto, de todos los demás elementos de contenido contenidos dentro de las páginas de un archivo PDF. Para permitir el acceso no visual al contenido, los archivos PDF necesitan contener datos adicionales que asignen “significado” o semántica a colecciones o grupos de operadores que se utilizan para “dibujar” una pieza concreta de contenido. Necesariamente, este principio de asignar o proporcionar “significado” debe extenderse a todas las formas de contenido contenidas en un PDF: ese mecanismo existe y se llama *etiquetado* el PDF para producir una “variante” de PDF llamada, como era de esperar, *PDF etiquetado*. ## Introducción al PDF etiquetado PDF etiquetado es el nombre que se da a un tipo específico de archivo PDF que contiene datos adicionales (y estructuras de datos) que no están presentes en los archivos PDF sin etiquetar. Aunque los principios/ideas detrás del PDF etiquetado se prestan a una descripción general, los detalles completos son complejos y ocupan muchas páginas en la especificación formal de PDF. Adobe diseñó el PDF etiquetado para lograr una serie de objetivos que incluían hacer el contenido accesible para usuarios con discapacidades visuales, pero también abarca la siguiente lista tomada de la Sección 10.7 de [la especificación PDF 1.7 de Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * la extracción sencilla de texto y gráficos para pegarlos en otras aplicaciones; * la reorganización automática del texto y los gráficos asociados para ajustarse a una página de un tamaño diferente del que se había supuesto para el diseño original; * el procesamiento del texto para fines como búsqueda, indexación y corrección ortográfica; * la conversión a otros formatos de archivo comunes (como HTML, XML y RTF) conservando la estructura del documento y la información básica de estilo. Además, el PDF etiquetado también requiere: * que el texto dentro del contenido PDF esté representado en una forma que pueda convertirse a Unicode; * los saltos de palabra deben representarse explícitamente; observe que los motores TeX no usan caracteres de espacio para separar palabras, sino el espaciado flexible de TeX llamado glue (véase más abajo); * el contenido real (“verdadero”) se distingue de los artefactos de diseño y paginación. Subyacen al PDF etiquetado dos conceptos clave que revisaremos: * definir la estructura lógica del contenido en un archivo PDF; * marcado (etiquetado) del contenido PDF con un conjunto de tipos de contenido estándar. ## Estructura lógica En documentos largos, el contenido suele dividirse en una secuencia de elementos de contenido más pequeños; por ejemplo, los libros suelen dividirse en capítulos que a su vez se dividen en secciones y subsecciones que contienen párrafos, tablas, figuras/gráficos, listas con viñetas o numeradas, notas al pie y referencias, etc. La estructura y organización del contenido en un libro así, o en cualquier otro tipo de documento, se denomina su *estructura lógica*. La noción de la estructura lógica de un documento desempeña un papel importante en la accesibilidad de los PDF, pero, como concepto, la estructura lógica puede parecer algo vaga y difícil de entender. La siguiente definición de la [Enciclopedia de sistemas de bases de datos](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) ofrece una visión útil: > “La estructura lógica se refiere a la forma en que se organiza la información en un documento; define la jerarquía de la información y la relación entre las distintas partes del documento. La estructura lógica indica cómo está construido un documento, a diferencia de lo que contiene.” Observe que esta definición de estructura lógica no hace referencia a con exactitud *cómo* dónde se almacena físicamente esa información estructural; solo que proporciona una representación de la estructura y organización de un documento. Los detalles precisos de cómo se almacena o representa la estructura lógica de un documento dependen de la implementación: una función del software utilizado para generarlo y procesarlo. ### Estructura lógica en los PDF La especificación PDF proporciona mecanismos mediante los cuales la estructura lógica de un documento puede registrarse dentro de un archivo PDF, para su uso por software que, por ejemplo, podría querer exportar el contenido del PDF a otros formatos como XML, HTML o Microsoft Word. Esos procesos de exportación deben producir un documento de texto correctamente estructurado que cumpla las reglas del formato de archivo de destino, y eso se logra mejor cuando el procesamiento de exportación se guía por la información de estructura lógica proporcionada dentro del PDF. Además, la estructura lógica de un archivo PDF es esencial para el software de accesibilidad que, por ejemplo, podría querer realizar operaciones de texto a voz, leyendo el contenido en voz alta a una persona con discapacidad visual. El proceso de texto a voz debe garantizar que el contenido se lea en el orden/secuencia correctos; de lo contrario, produciría resultados sin sentido. Téngase en cuenta también que el propio concepto de página puede no tener ningún sentido significativo para las aplicaciones de accesibilidad, que solo están interesadas en el contenido y la estructura del documento PDF, no en la partición y presentación visual en bloques del tamaño de una página. #### Nombrar los elementos de contenido Registrar (almacenar) la estructura lógica de un documento PDF requiere un conjunto de nombres significativos asignados a los distintos *tipos* de elementos de contenido que probablemente se encuentren en un documento PDF típico: identificando secciones de contenido que representan encabezados, párrafos, tablas, listas, etc. Además, algunos elementos de contenido, como tablas de contenido, listas numeradas/con viñetas y material tabular, tienen estructuras propias bastante complejas, por lo que también deben existir algunas guías/reglas para especificar cómo se construyen esos elementos de contenido más complejos: su subestructura. Otro requisito es identificar claramente cualquier contenido PDF que deba ser ignorado por el software de asistencia que procesa el PDF; por ejemplo, los encabezados y pies de página son artefactos de paginación que contienen texto superfluo para quienes tienen una discapacidad visual grave: ese contenido debe ignorarse. Los mecanismos utilizados por PDF para definir la estructura lógica de un documento están diseñados para ser flexibles, de modo que, en principio, distintas aplicaciones que generan y procesan archivos PDF podrían utilizar nombres para los tipos de contenido siguiendo cualquier convención que prefirieran. Sin embargo, para maximizar el intercambio de documentos y permitir que diferentes aplicaciones de procesamiento de PDF ofrezcan resultados coherentes, Adobe definió un conjunto de nombres estándar para los tipos de elementos de contenido que el software de generación de PDF debería respetar. Dentro de la especificación PDF esos nombres estándar se denominan etiquetas, dando lugar al concepto de *PDF* etiquetado. ### Marcado del contenido PDF: una mirada “bajo el capó” Para hacer la discusión un poco menos abstracta, echaremos un breve vistazo al funcionamiento interno de los archivos PDF etiquetados, aunque no podemos cubrir todos los detalles porque el PDF etiquetado es un tema muy amplio y complejo. #### Secuencias de contenido marcado: bloques de construcción del PDF etiquetado En el nivel más bajo, el proceso de registrar el significado del contenido contenido dentro de una página PDF (es decir, dentro de su flujo de contenido) comienza con *secuencias de contenido marcado* que se utilizan para identificar (dar “significado” a) grupos o conjuntos de operadores PDF. A las secuencias de contenido marcado se les asigna un identificador numérico llamado su `MCID` (*identificador de contenido marcado*) que es un entero que va de 0 a un máximo N en cada página. Esos `MCID` valores proporcionan una forma de identificar de manera única secuencias de operadores contenidas dentro del flujo de contenido de una página concreta. Para aclararlo, para cada página los `MCID` identificadores empiezan en 0 y aumentan secuencialmente hasta algún valor máximo que depende de cuántas secuencias de contenido marcado estén contenidas en el flujo de contenido de una página determinada. Las secuencias de contenido marcado son, en efecto, “bloques de construcción” fundamentales que se utilizan para ensamblar estructuras de datos de nivel superior llamadas *elementos de estructura*. Esos elementos de estructura contienen una etiqueta, que es el nombre utilizado para identificar qué tipo de elemento de contenido representan. #### Ejemplo de elementos de estructura Aquí estamos adelantándonos un poco, pero merece la pena revisar un ejemplo. Suponga que tiene 3 pequeños fragmentos de texto del contenido de una página y que cada uno está identificado en el flujo de contenido por una secuencia de contenido marcado diferente. Cada uno de esos 3 fragmentos de texto puede empaquetarse en su propio elemento de estructura, con una etiqueta, y los tres pueden “vincularse” mediante otro elemento de estructura para representar un elemento de contenido de nivel superior, como una línea de una tabla de contenido. ![Imagen que explica los elementos de estructura y las secuencias de contenido marcado](/files/a452a1db5a512dc27b1c27cd8204ba9b6dd454a0) Mediante una forma de relación de datos padre-hijo, colecciones de elementos de estructura se combinan para crear estructuras de datos vinculadas que representan elementos de datos más complejos, como listas numeradas y con viñetas, tablas, matemáticas, etc. En última instancia, toda la colección de elementos de estructura contenida en todo el archivo PDF se enlaza y combina para crear la estructura lógica del documento PDF; volveremos sobre esto más adelante en el artículo. ### ¿Qué es una secuencia de contenido marcado? En la discusión anterior utilizamos un documento PDF sencillo sin etiquetar que contenía una tabla (creada en Microsoft Word), pero si indicamos a Word que cree un PDF etiquetado podemos ver que ha aparecido marcado adicional en el flujo de contenido de la página. Aquí solo estamos considerando las primeras líneas del flujo de contenido (hay cientos de líneas), pero observe la presencia de operadores adicionales como `/P <> BDC` y `EMC` que se utilizan para identificar una secuencia de contenido marcado. No exploraremos la sintaxis completa de las secuencias de contenido marcado, pero remitimos al lector a la página 862 de [la especificación oficial PDF 1.7 de Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Imagen que muestra secuencias de contenido marcado en un flujo de contenido PDF etiquetado](/files/1bb639f96bd5f3cedd1f614ef0058cb0fc1b5061) Para facilitar la referencia, mostramos de nuevo la versión sin etiquetar: ![Imagen que muestra el flujo de contenido PDF](/files/e4327bbe461f33d2087581b9f79ab9475eda9019) En la *sin etiquetar* PDF, operadores como `/P <> BDC` y `EMC` están ausentes, pero los operadores restantes no cambian: el PDF sin etiquetar carece del marcado adicional utilizado para identificar ciertas secuencias/conjuntos de operadores. De nuevo, también podemos utilizar la *estructura interna del PDF* función de Acrobat para ver las secuencias de contenido marcado dentro de un flujo de contenido; aquí las hemos resaltado con un borde verde: ![Imagen que muestra secuencias de contenido marcado en un flujo de contenido PDF etiquetado visto en Adobe Acrobat Pro DC](/files/b2a29eb90095f48c6be77a84f47025dae55f6fd1) Observe que algunas piezas de contenido están marcadas como `/Artifact` lo que identifica material en la página PDF que debe ser *ignorados* ignorado por las aplicaciones de software de asistencia, como las que leen en voz alta a personas con discapacidad visual. La siguiente captura de pantalla muestra una vista ampliada de la primera secuencia de contenido marcado, la que tiene `MCID` un valor de `0`. El final de la secuencia de contenido marcado se identifica mediante el operador PDF `EMC`. ![Imagen que muestra detalles de los operadores abarcados por un flujo de contenido marcado](/files/f5634f2448ff80af527f28160a716a9cae9dc386) ### Almacenar la estructura lógica Como se ha señalado, además de proporcionar una descripción de elementos de contenido individuales (párrafos, listas, tablas, etc.), es necesario que los PDF accesibles contengan una representación de todo el documento en forma de su estructura lógica. Las piezas individuales de contenido accesible deben vincularse para crear un documento completo, navegable y accesible, de forma similar a cómo un único documento HTML se construye a partir de párrafos, gráficos y tablas para crear una página web. Además, es esencial que la estructura lógica de un documento PDF garantice que todo el contenido pueda navegarse en el *orden de lectura*correcto, independientemente del orden en que el contenido de la página se haya escrito en los flujos de contenido de la página PDF. Exploraremos el orden de lectura con más detalle a continuación. #### Estructura lógica: un “árbol” de elementos de estructura Hemos señalado que los PDF utilizan algo llamado *elemento de estructura* para representar elementos de contenido individuales, y que un elemento de estructura contiene una etiqueta para identificar qué tipo de contenido representa. Para proporcionar una representación de la estructura lógica del documento, todos los elementos de estructura se enlazan entre sí, mediante relaciones padre-hijo, y se organizan en un “árbol de estructura”. Internamente, los archivos PDF etiquetados contienen un objeto llamado `StructTreeRoot` que contiene (apunta a) elementos de estructura que actúan como punto de partida o “raíz” del árbol de estructura lógica del documento. Normalmente, la “raíz” del árbol de estructura comienza con un único elemento de estructura etiquetado como `Documento` que contiene numerosos *hijos* elementos de estructura que, en conjunto, representan todo el contenido del documento. Cualquier software diseñado para producir PDF accesibles mediante etiquetado tiene que construir esta estructura de datos tan compleja (¡y otras más!), y eso incluye a los motores TeX y LaTeX. Un ejemplo de un árbol de estructura de documento como este (`StructTreeRoot`) se muestra en la siguiente captura de pantalla de un PDF etiquetado abierto en Adobe Acrobat Pro DC: ![Imagen que muestra StructTreeRoot en un PDF etiquetado](/files/df4b0c87ef0a151422be87fe01e1ceb882518d17) Compare la estructura anterior con la versión del PDF sin etiquetar: ![Imagen que muestra la ausencia de StructTreeRoot en un PDF sin etiquetar](/files/9273a73940118770749d4bfed686435a628b52f1) ### Explorando la estructura lógica de los PDF Comenzamos con algunos gráficos para resumir lo que hemos tratado y terminamos con un vídeo que usa Adobe Acrobat Pro DC para mostrar más detalles de la estructura lógica de un archivo PDF etiquetado. Primero, empezamos con un esquema para mostrar los principios generales: una página PDF con su flujo de contenido marcado con secuencias de contenido marcado (MCS). ![Gráfico para mostrar el concepto de secuencias de contenido marcado en páginas de documentos PDF](/files/e0189811723c484d50d5f00e792dd946f0ff2488) Esas MCS se combinan posteriormente en *elementos de estructura* que constituyen la base de tipos de contenido más amplios que a su vez se enlazan entre sí para almacenar la estructura lógica del PDF dentro de un objeto llamado `StructTreeRoot`. ![Gráfico para mostrar la estructura lógica de un archivo PDF etiquetado](/files/7f32f195c3582ab2af7ab20b0ba46c002918fdd9) #### Vídeo que muestra la estructura lógica de un PDF etiquetado El siguiente vídeo (8 minutos) usa Adobe Acrobat Pro DC para hacerle una “visita guiada” por los detalles de la estructura lógica de un archivo PDF etiquetado producido con LaTeX. El archivo PDF etiquetado utilizado en el vídeo se llama `tagpdf.pdf`, que es un excelente ejemplo que contiene documentación para el paquete experimental de LaTeX [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). El objetivo del `tagpdf` paquete es proporcionar “herramientas para experimentar con el etiquetado y la accesibilidad usando pdfLaTeX y LuaTeX”. {% embed url="" %} ### Una nota sobre el etiquetado y la flexibilidad La especificación HTML proporciona una gran cantidad de etiquetas predefinidas para su uso en la construcción de páginas web, pero también permite flexibilidad en la forma de combinarlas para crear el documento HTML deseado. De manera similar, la especificación de PDF etiquetado de Adobe proporciona un conjunto de nombres de etiquetas predefinidos, pero impone muy pocas restricciones sobre cómo combinar esas etiquetas para representar elementos de contenido complejos dentro de un PDF; por diseño, existe una gran flexibilidad. Además, con cualquier especificación tan grande y compleja como PDF, es inevitable que se cuelen algunas ambigüedades o problemas de claridad en la especificación escrita. Los desarrolladores de software encargados de implementar una especificación tan compleja pueden tener que tomar “decisiones de criterio” al interpretarla porque se enfrentan a convertir descripciones escritas en código funcional. La flexibilidad inherente del PDF etiquetado, junto con la interpretación de las especificaciones (o normas de accesibilidad), afecta naturalmente a los desarrolladores de aplicaciones de creación de documentos: ¿qué combinaciones de etiquetas deben utilizarse para representar contenido creado por el usuario al exportarlo a un archivo PDF etiquetado? Si se tiene en cuenta la capacidad ilimitada de los usuarios para construir todo tipo de contenido utilizando las funciones del software de creación de documentos, entonces se puede ver que la producción automática de PDF etiquetados accesibles es todo un desafío. Quizá reflejando las inevitables complejidades de producir PDF etiquetados que cumplan plenamente con los estándares de accesibilidad, la web está repleta de “cómo hacerlo”, “consejos” y recomendaciones de “mejores prácticas” para crear PDF etiquetados mediante software como Adobe InDesign o Microsoft Word. Además, la PDF Association ha elaborado un documento útil llamado [Guía de mejores prácticas para PDF etiquetados](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) redactado para ayudar a los desarrolladores que se enfrentan a los desafíos de implementar PDF etiquetado y PDF/UA. ## ¿Tiene un PDF, pero es accesible? Para determinar si un determinado archivo PDF cumple con los estándares de accesibilidad requeridos, como PDF/A o PDF/UA (véase más abajo), debe ser *validado* mediante un proceso de validación acordado o una herramienta de software. Sin embargo, la validación suele llevarse a cabo una vez terminado el documento, pero ese proceso puede no ser realizado por el autor del documento, sino por especialistas en accesibilidad dentro de la organización o entidad que solicitó el cumplimiento. Si el PDF no supera la validación, puede requerir una intervención manual experta a través de Adobe Acrobat Pro DC para corregir el etiquetado (si es posible). Alternativamente, incluso podría tener que volver al autor para que modifique su documento original, posiblemente evitando el uso de las funciones del software de creación que causaron los problemas, lo cual podría ser extremadamente difícil de lograr porque puede estar fuera del control del autor. ### Orden de lectura y orden del contenido Como se ha señalado, la producción de PDF realmente accesibles impone requisitos técnicos adicionales al software de creación y, potencialmente, también a los autores de documentos al exigir “disciplina de autoría” en cómo utilizan/aplican las funciones del software de creación. Aunque el PDF etiquetado es el mecanismo que *permite* la producción de PDF totalmente accesibles, el hecho de que un PDF esté etiquetado no *no* significa automáticamente que sea completamente accesible, como veremos en un ejemplo más abajo. Para producir PDF totalmente accesibles, todos los elementos de contenido del PDF deben etiquetarse para crear una estructura lógica que garantice que el contenido pueda accederse y leerse en la secuencia correcta, llamada el *orden de lectura*orden de lectura *orden de lectura* de: 1. texto 2. table 3. gráfico Cuando se escribe en un PDF, el software que genera un flujo de contenido para esa página podría comenzar con operadores para dibujar la tabla, luego emitir operadores para producir el gráfico, seguidos de operadores para el texto, lo que en el flujo de contenido produciría un *orden del contenido* de: 1. table 2. gráfico 3. texto Por supuesto, todo se colocará en la posición correcta cuando se visualice esa página. Para un lector plenamente vidente, el orden en que esos elementos se almacenan dentro del flujo de contenido de la página no tiene interés: experimenta una página renderizada completa con todo en la ubicación correcta. Sin embargo, si el software de asistencia tuviera que depender del orden de los elementos en un flujo de contenido (el orden del contenido), se enfrentaría a dificultades si el orden del contenido fuera diferente del orden natural de lectura; por ejemplo, las herramientas de lectura en voz alta leerían el material en la secuencia incorrecta. Afortunadamente, el software de asistencia puede utilizar el orden lógico (estructura) de un PDF etiquetado, que debe organizarse para reflejar la secuencia en la que el contenido debe leerse. Es por estas razones que los datos que representan la estructura lógica del documento se almacenan por separado del contenido real mostrado en las páginas visibles, para permitir > “... que el orden y la anidación de los elementos de contenido lógico sean totalmente independientes del orden y la ubicación de los objetos gráficos en las páginas del documento.” (página 856 de [The PDF Reference, sexta edición, noviembre de 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) En la práctica, garantizar un orden lógico que preserve el orden de lectura es mucho más difícil de lo que podría parecer, así que usemos un ejemplo sencillo, aunque inventado, que dé una indicación de los problemas implicados. #### Orden de lectura incorrecto: un ejemplo usando Microsoft Word El autor de un documento podría utilizar las funciones del software de creación elegido para lograr un efecto visual específico, como usar tablas para crear un diseño de texto concreto. Por ejemplo, la siguiente captura de pantalla muestra el documento de Microsoft Word utilizado en ejemplos anteriores. Contiene una tabla que se ha utilizado para crear un conjunto de párrafos numerados lado a lado. Pero cuando se trata de etiquetar este contenido, ¿cómo debería tratarse: como una tabla o como una lista numerada? Ambos tipos de contenido requieren una estructura de etiquetado compleja para representarlos correctamente. En la imagen siguiente, observe el orden en que se pretende leer los párrafos numerados: columna por columna, no fila por fila. ![Imagen de una tabla creada en Microsoft Word](/files/687e3813c2dc1c49071eb89cd4661402b8b371cb) Si pedimos a Word que guarde este documento como PDF utilizando su exportación integrada, no el complemento Acrobat PDFMaker, podemos indicarle que cree un PDF etiquetado: ![Cuadro de diálogo de opciones del proceso de exportación de Microsoft Word](/files/4f9342668e833e0a79566102c8b926560bd5dfe5) Entonces, ¿cómo etiqueta Word este diseño? En el siguiente video muy corto (14 segundos) usamos Adobe Acrobat Pro DC para inspeccionar la estructura de etiquetado producida por Microsoft Word. {% embed url="" %} Para este documento, Word ha creado un documento PDF etiquetado que utiliza una `Tabla` etiqueta que contiene dos subetiquetas: `THead` para el grupo de filas del encabezado de la tabla y `TBody` para representar el grupo de filas del cuerpo de la tabla. `THead` y `TBody` ambas contienen `TR` etiquetas para representar filas individuales de contenido. Las `TR` etiquetas contienen otras etiquetas para representar el elemento de lista numerada presente en cada celda. La siguiente imagen de pantalla muestra la estructura de etiquetado profundamente anidada y la estructura lógica correspondientemente compleja necesaria para representar incluso este documento extremadamente básico! ![Imagen que muestra una estructura de etiquetado profundamente anidada y la estructura lógica de una tabla simple creada en Microsoft Word](/files/e328aba5c86cc9185f4db3b8a447b32681e9a432) En comparación con los PDF generados por TeX y LaTeX, este ejemplo de Word es un documento extremadamente simple, pero aun así requiere una estructura lógica compleja para representarlo. ¡Imagina el nivel de complejidad de etiquetado necesario para representar PDF generados con LaTeX que contienen matemáticas y tablas complejas! #### Etiquetado, sí, pero el orden de lectura es incorrecto Aunque Word sí produce un [PDF etiquetado](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) demuestra uno de los desafíos fundamentales a los que se enfrenta cualquier aplicación que intenta producir PDF totalmente accesibles: representar correctamente el orden de lectura previsto del contenido. Durante la creación del PDF etiquetado, los procesos internos de Word decidieron escribir el flujo de contenido correspondiente generando la tabla fila por fila, no columna por columna. Para un lector con visión completa que vea el PDF, estos detalles de bajo nivel no marcan ninguna diferencia: la tabla se muestra correctamente. Sin embargo, para las personas con discapacidad visual, la estructura lógica del documento de Word produce el resultado incorrecto porque no se conserva el orden de lectura deseado (columna por columna): el contenido se lee en voz alta en el orden equivocado. La siguiente grabación de audio se produjo utilizando la función “Leer en voz alta” de Adobe Reader DC. Como es evidente, el texto se lee en la secuencia incorrecta: fila por fila, no columna por columna: ![Una tabla creada en Microsoft Word](/files/4ccfa3da24c83252b59820891b869e82e6f0483c) Como se señaló anteriormente, este ejemplo es algo artificial, pero sí demuestra lo fácil que es aplicar combinaciones de funciones de software que provocan problemas de accesibilidad, ¿pero cómo se supone que el autor del documento debe saberlo de antemano? Es probable que este problema solo se detecte si el PDF resultante se somete a pruebas prácticas de uso de accesibilidad; por ejemplo, mediante software de apoyo. Potencialmente, estos documentos podrían pasar las pruebas de conformidad/validación de PDF/A pero fallar en el uso «real». Garantizar el orden de lectura correcto de un archivo PDF como este requeriría una intervención manual experta utilizando herramientas avanzadas de edición de PDF como Adobe Acrobat Pro DC: un proceso que consume mucho tiempo y es costoso. Alternativamente, el autor del documento podría abstenerse de usar esta forma particular de expresión o maquetación del contenido, ¡pero solo si supiera que es problemática! ### Uso de caracteres de espacio para separar palabras Cuando escribes texto en procesadores de texto o editores de texto, usas el carácter de espacio para marcar el final de una palabra y el inicio de la siguiente. Si posteriormente creas un PDF a partir de un documento así, los caracteres de espacio que escribiste, por supuesto, se incluirán en la salida y formarán parte del texto almacenado en el PDF. Sin embargo, los motores TeX no usan caracteres de espacio para separar palabras en el texto compuesto; en su lugar, convierten los caracteres de espacio en una forma de espaciado flexible llamada glue (véase este [artículo de Overleaf](/latex/es/articulos-en-profundidad/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) para más información sobre las cajas y el glue de TeX). Dentro del flujo de contenido de las páginas PDF creadas por motores TeX, la separación de las palabras individuales se logra moviéndose a una posición diferente en la página e iniciando el texto de la siguiente palabra, en lugar de emitir un carácter de espacio para conseguir ese espaciado. Además, la cantidad de espacio entre palabras en los párrafos de texto compuestos por motores TeX varía de una línea a otra debido al algoritmo de división de líneas de TeX. Esa variación se refleja en los datos posicionales escritos en el flujo de contenido de las páginas PDF. Este aspecto de la composición tipográfica de TeX tiene implicaciones para copiar/pegar texto desde sus PDF y para el software de apoyo que intenta leer en voz alta el texto compuesto en PDF producidos por motores TeX. El software de apoyo tiene que analizar el flujo de contenido de una página PDF para extraer el texto que necesita procesar. Claramente, ese software necesita algún mecanismo para detectar el inicio y el final de las palabras; la solución más obvia es usar un carácter de espacio. Con esto en mente, los estándares de accesibilidad exigen que las palabras individuales se terminen claramente (por ejemplo, con caracteres de espacio), lo que resulta problemático para los motores TeX debido a su uso del glue entre palabras. #### ¡Pero no todo está perdido! En 2014, pdfTeX introdujo 2 nuevos primitivos para mejorar el soporte de accesibilidad al permitir el uso de caracteres de espacio entre palabras en los PDF que genera: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Estos comandos hacen uso de una “fuente ficticia” que contiene solo un glifo de espacio. Los detalles y un ejemplo se pueden encontrar en la página 29 del [Manual de usuario de pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Uso de LuaTeX: un ejemplo en la Galería de Overleaf LuaTeX no admite esos primitivos de pdfTeX, pero puede programarse para lograr resultados muy similares a pdfTeX mediante el llamado mecanismo de callbacks de LuaTeX. En la Galería de Overleaf hay disponible un proyecto de Overleaf para convertir glue en caracteres de espacio bajo el título [Uso de LuaTeX para convertir el glue entre palabras en espacios y kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Si compilas tu código LaTeX usando LuaTeX (es decir, la opción del compilador LuaLaTeX en Overleaf), entonces, mediante código Lua, puedes posprocesar un párrafo compuesto para encontrar cualquier glue entre palabras y reemplazarlo por un carácter de espacio más un kern adecuado. El espaciado proporcionado por el ancho del carácter de espacio puede aumentarse (o reducirse) calculando un valor de kern apropiado para preservar la cantidad de espacio proporcionada por el glue entre palabras, sin que el resultado compuesto muestre ninguna diferencia visual. Para entender la diferencia que esto supone para los usuarios de software de accesibilidad, escucha esta grabación de audio capturada desde la función de Adobe Reader DC *Leer en voz alta* función. Registra las dos líneas de texto de ese proyecto leídas en voz alta, antes y después de convertir el glue en espacios. Observa cómo la segunda lectura de la línea, que usa espacios, se lee en voz alta rápida y fluidamente en comparación con la línea que usa glue entre palabras. El proyecto de Overleaf es un archivo TeX plano compilado con LuaTeX y se proporciona solo para uso experimental; no pretende ser una solución completa ni de calidad de producción. Principalmente, está diseñado para ayudar a comprender los problemas técnicos relacionados con los PDF accesibles. El código Lua utilizado en ese proyecto se basa en un trabajo incluido en un artículo anterior de Overleaf [Cajas y pegamento: una breve, pero visual, introducción usando LuaTeX](/latex/es/articulos-en-profundidad/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Nota: Por simplicidad, el proyecto utiliza su propio cargador de fuentes OpenType muy minimalista derivado de este código: . ### Otros problemas de accesibilidad y PDF etiquetado Aunque el etiquetado permite identificar los elementos de contenido presentes dentro de un PDF, algunos tipos de contenido, como los gráficos o las matemáticas complejas, requieren datos o información adicionales si se desea que sean accesibles mediante software diseñado para dar soporte a personas con discapacidad visual. Para proporcionar y respaldar la accesibilidad de una amplia gama de tipos de contenido, la especificación PDF ofrece la posibilidad de adjuntar “Descripciones alternativas” o “ActualText” a los elementos de contenido, proporcionando descripciones textuales adecuadas u otras representaciones legibles por máquina. Por ejemplo, MathML ha sido designado para este propósito dentro de la especificación PDF 2.0. #### ¿Es “contenido real” o solo un artefacto? Para las personas con discapacidad visual, el proceso de dividir y mostrar contenido en bloques rectangulares del tamaño de una página tiene efectos secundarios no deseados, como la separación de palabras con guiones. Además, aspectos del diseño o la maquetación de la página que se usan para mejorar la presentación visual carecen por completo de sentido para quienes no pueden verlos. Por estas razones, el etiquetado del contenido PDF tiene que reconocer que parte del contenido dentro de un PDF debe tratarse como un *artefacto* de presentación visual o paginación. Por ejemplo, los números de página, los encabezados y pies de página, los fondos sombreados u otras señales de diseño deben identificarse para que el software de accesibilidad que procese el contenido sepa ignorarlos. ## Resumen de los estándares PDF/A Las solicitudes para producir PDF accesibles suelen hacer referencia a una norma ISO llamada [ISO 19005](https://www.iso.org/standard/38920.html), más comúnmente denominada PDF/A. Sin embargo, debido a que PDF/A es una *familia* familia de normas, solicitar simplemente “conformidad con PDF/A” puede no especificar por completo los requisitos reales. Para ver por qué, empecemos con un breve esquema de PDF/A del [sitio web de la Asociación PDF](https://www.pdfa.org/resource/iso-19005-pdfa/) (consultado el 21 de mayo de 2020), que describe ISO 19005 (PDF/A) de la siguiente manera: > “El propósito principal de ISO 19005 es definir un formato de archivo basado en PDF, conocido como PDF/A, que proporciona un mecanismo para representar documentos electrónicos de una manera que preserve su apariencia visual estática con el paso del tiempo, independientemente de las herramientas y sistemas utilizados para crear, almacenar o renderizar los archivos. > > Un propósito secundario de ISO 19005 es definir un marco para representar la estructura lógica y otra información semántica de los documentos electrónicos dentro de archivos conformes. > > Otro propósito de ISO 19005 es proporcionar un marco para registrar el contexto y la historia de los documentos electrónicos en metadatos dentro de archivos conformes.” Está claro que PDF/A tiene varios objetivos principales. ### Evolución y crecimiento de PDF El [La especificación PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) se publicó en 1993 y contenía solo 230 páginas. Sin embargo, 13 años después, la especificación de [la versión 1.7 de PDF de Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) supera ampliamente las 1000 páginas. Con el tiempo, el tamaño y la complejidad de la especificación PDF han crecido al ampliarse el conjunto de funciones admitidas: abarcando nuevas tecnologías y los requisitos de flujos de trabajo y casos de uso basados en PDF cada vez más sofisticados en distintos mercados y comunidades. Sin embargo, es probable que ningún usuario, ni conjunto de usuarios, haga uso de todas las posibilidades: PDF tiene que “cubrir todos los frentes” para asegurarse de que puede atender las necesidades del mayor mercado posible. Por ejemplo, muchas funciones de PDF diseñadas para dar soporte a la impresión comercial de alta gama no son necesarias para el uso diario típico de oficina como formato para almacenar o compartir documentación. ### PDF/A: “volver a lo básico” para PDF El objetivo principal de PDF/A es garantizar que los PDF conformes sean adecuados para el archivado a largo plazo o contengan contenido accesible para personas que utilizan diversas tecnologías de apoyo para “consumir” esos PDF. Para lograr estos objetivos, PDF/A restringe el conjunto de funciones de PDF permitidas en los archivos PDF conformes, prohibiendo el uso de funciones que podrían comprometer la archivabilidad o la accesibilidad. Puedes pensar en PDF/A como un conjunto de normas que especifican cómo los archivos PDF conformes usan una *subconjunto* subconjunto *completos*: los recursos clave del documento deben estar incrustados en el archivo, como las fuentes o los perfiles de color. ### Versiones y niveles de conformidad PDF/A Hay diferentes *versiones* versiones del estándar PDF/A, cada una reflejando una versión particular de la especificación formal de PDF (PDF 1.4, 1.7 y 2.0). Además, hay varios *niveles de conformidad* que especifican a qué aspecto(s) del estándar PDF/A se ajusta un archivo PDF. En consecuencia, al afirmar o exigir “conformidad con PDF/A”, deberías pensar en archivos PDF que cumplen **PDF/A-** Por ejemplo * PDF/A-1a: significa la versión 1 de PDF/A, nivel de conformidad a * PDF/A-2b: significa la versión 2 de PDF/A, nivel de conformidad b Las exploramos con un poco más de detalle. #### Versiones de PDF/A El estándar PDF/A está bajo los auspicios de la ISO, publicado como una norma llamada ISO 19005. Como se señaló, la especificación PDF ha evolucionado con el tiempo y eso, a su vez, hizo necesarias actualizaciones de ISO 19005, dando como resultado la tabla siguiente: | | | | | -------------------- | ---------------- | ---------------------------- | | **Versión de PDF/A** | **Norma ISO** | **Basada en la versión PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | ISO 32000-1 (PDF 1.7) | En el momento de escribir esto (abril/mayo de 2020) un PDF/A-4 actualizado (ISO 19005-4) está [en preparación](https://www.iso.org/standard/71832.html). #### Niveles de conformidad PDF/A Además de las tres versiones de PDF/A (PDF/A-1, PDF/A-2 y PDF/A-3), hay tres *niveles de conformidad*: * Nivel A (accesible) para accesibilidad (incluye los requisitos de archivo del Nivel B) * Nivel B (básico) para archivo * Nivel U (Unicode) (= archivo más uso de Unicode para el texto) Aquí tienes una breve descripción de estos niveles de conformidad: * **Nivel B (básico)** es el requisito mínimo para la conformidad bajo PDF/A. Define requisitos para garantizar que los documentos PDF conformes sean adecuados para el archivado a largo plazo, es decir, que siempre puedan visualizarse o imprimirse de forma fiable independientemente de software, herramientas o sistemas operativos específicos. * **Nivel A (accesibilidad)** incluye los requisitos de la conformidad de Nivel B, pero además exige el uso de PDF etiquetado para proporcionar estructura lógica e información sobre el orden de lectura, junto con el uso de Unicode para permitir el acceso al texto del documento. * **Nivel U (Unicode)** la conformidad fue un nivel añadido a PDF/A-2 y se basa en el Nivel B al requerir además el uso de Unicode para el texto del documento, pero no llega tan lejos como el Nivel A al exigir información de estructura. Las versiones y los niveles de conformidad PDF/A se pueden resumir en una tabla: | | | | | | ------------------------ | ----------------------------- | -------- | -------- | | **Nivel de conformidad** | **PDF/A-** | | | | Nivel A (accesible) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Nivel B (básico) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Nivel U (Unicode) | N/A (no existía para PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Accesibilidad universal”) Aunque el cumplimiento del Nivel A del estándar PDF/A avanza en la definición de requisitos para PDF accesibles, otro estándar ISO llamado [ISO 14289](https://www.iso.org/standard/64599.html), denominado PDF/UA, va más allá. PDF/UA refuerza los requisitos de accesibilidad y aclara la orientación contenida en los estándares PDF/A y se ha convertido en el estándar preferido para los PDF accesibles. #### Protocolo Matterhorn A los lectores con un profundo interés en conocer más sobre la conformidad PDF/UA les puede interesar el [Protocolo Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) que es “una lista de todas las formas posibles de incumplir la conformidad con PDF/UA”. ### Software de validación Para comprobar si un archivo PDF se ajusta a un estándar concreto tiene que ser *validado* mediante software de conformidad que analiza el PDF para verificar si su contenido y estructura se ajustan a los requisitos de ese estándar, como PDF/UA o PDF/A-*x*a (donde *x* = 1, 2 o 3). Ten en cuenta que la validación de PDF —procesarlos con una herramienta de validación preferida— puede producir mensajes de diagnóstico o advertencias que pueden resultar bastante crípticos para el usuario no experto, tal vez debido a algún dato (o estructura) PDF de bajo nivel que no cumple con el estándar pertinente. Para muchos autores, interpretar esas advertencias y convertirlas en una solución práctica para su(s) documento(s) puede ser todo un reto. #### Software de validación gratuito * [veraPDF](https://verapdf.org/) que, para citar su sitio web (consultado el 28 de mayo de 2020), es un “validador de formato de archivo, de código abierto y diseñado específicamente, que cubre todas las partes y niveles de conformidad de PDF/A”. * (solo Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) que es una “...herramienta gratuita de comprobación de accesibilidad PDF que se ha probado y verificado desde 2010”. #### Software de validación comercial * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) proporciona una suite de pruebas de validación PDF junto con herramientas para editar y corregir etiquetas en archivos PDF no conformes. ### PDF Association: una gran fuente de información El [PDF Association](https://www.pdfa.org/) produce muchos *excelente* recursos sobre PDF/A, PDF/UA y muchos otros temas relacionados con PDF, incluidos videos en su [canal de YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) junto con artículos y publicaciones técnicas gratuitas disponibles en su sitio web. Una de esas publicaciones es [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) que ofrece una introducción inestimable al estándar PDF/UA y a sus requisitos. ## PDF accesibles a partir de motores TeX y LaTeX Ojalá las discusiones anteriores hayan indicado que producir archivos PDF totalmente accesibles y correctamente etiquetados es un desafío técnico exigente. Además, incluso el ejemplo sencillo de Microsoft Word demostró que los autores pueden usar muy fácilmente combinaciones de funciones de software que dan lugar a documentos PDF etiquetados que no cumplen los criterios de accesibilidad. Como herramienta de autoría, LaTeX proporciona a los autores una flexibilidad casi ilimitada en la gama y complejidad de documentos que pueden crear, lo que quizá sea precisamente la razón para elegirlo en primer lugar. LaTeX también admite extensibilidad mediante miles de paquetes complementarios que los autores pueden usar como parte de sus documentos. Además de todo eso, los autores tienen la libertad de escribir nuevas macros de TeX o LaTeX, o redefinir las existentes, para lograr efectos específicos. Sin embargo, quizá esta libertad y flexibilidad tenga un precio, porque el contenido producido por las innumerables interacciones de todos esos paquetes y macros de LaTeX “de algún modo” debe coordinarse si LaTeX ha de generar automáticamente una salida PDF correctamente etiquetada y accesible. En la práctica, la extensibilidad, potencia, versatilidad y “libertad” de autoría que ofrece LaTeX plantean desafíos técnicos para una producción fluida y transparente (“automática”) de documentos PDF etiquetados totalmente accesibles que cumplan los estándares PDF/UA o PDF/A-{1|2|3}a. La comunidad más amplia de TeX y LaTeX está trabajando arduamente para abordar esos desafíos y The TeX User Group (TUG) está coordinando esfuerzos de investigación y desarrollo a través del grupo de trabajo de accesibilidad PDF y estándares PDF [grupo de trabajo](https://www.tug.org/twg/accessibility/). Existe una [lista de discusión](https://tug.org/mailman/listinfo/accessibility) que ofrece una forma para que las partes interesadas debatan la producción de archivos PDF etiquetados utilizando TeX y LaTeX. En estas discusiones conviene recordar que LaTeX en realidad no es un programa de composición ejecutable; es una gran colección de macros sofisticadas (comandos) escritas en un lenguaje de nivel inferior llamado TeX. Entre tu documento LaTeX cuidadosamente elaborado y el PDF final compuesto hay una pieza de software llamada motor TeX, cuya tarea es “ejecutar” la colección de comandos LaTeX (es decir, macros) utilizada para escribir y construir tu documento, convirtiéndolos en la representación compuesta de tu documento guardada como un archivo PDF. Quienes se inician en el ecosistema TeX/LaTeX a menudo, y comprensiblemente, se sienten desconcertados por la multitud de nombres de sonido críptico que usan las herramientas con las que se encuentran: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX y LuaLaTeX. Si te pasa lo mismo, hay ayuda en el artículo de Overleaf [Qué hay en un nombre: Una guía de las muchas variantes de TeX](/latex/es/articulos-en-profundidad/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) que explica el origen y el significado de todos esos términos. Los motores TeX como pdfTeX, XeTeX o LuaTeX son una clase de software llamada *compiladores de documentos*: toman tu código LaTeX y lo compilan a su forma compuesta “convirtiendo” las macros (comandos) de LaTeX de nuevo en las instrucciones de su lenguaje TeX de nivel inferior, que se “ejecutan” para producir el resultado compuesto. Los sistemas de composición tipográfica basados en TeX son capaces de producir contenido excepcionalmente complejo, incluidas matemáticas avanzadas, notación musical, estructuras químicas, gráficos y texto compuesto multilingüe sofisticado. Para garantizar que esos documentos complejos cumplan las normas y regulaciones de accesibilidad, los motores TeX, junto con la colección de macros de LaTeX y los paquetes LaTeX, necesitan generar archivos PDF debidamente etiquetados incrustando una gran cantidad de datos adicionales en los archivos PDF que generan. Aunque los motores TeX pueden generar archivos PDF extremadamente complejos, sus procesos internos, algoritmos y funciones no tienen *incorporado* funciones *diseñadas específicamente* para apoyar la producción de PDF etiquetados y accesibles. En su lugar, el soporte para etiquetado y accesibilidad tiene que lograrse mediante una programación macro compleja que “inyecta” datos adicionales en los PDF generados por los motores TeX, creando las secuencias de contenido marcado, los elementos de estructura y las estructuras de datos de la estructura lógica almacenadas en `StructTreeRoot`. Y aquí es donde esa “coordinación” cobra especial importancia: el código dentro del núcleo (kernel) de LaTeX junto con el código de miles de paquetes e innumerables macros creadas por los autores tendría que cooperar con mucho cuidado para garantizar que la ejecución de macros produzca el etiquetado correcto del contenido de los documentos resultantes. Esa “coordinación” tendría que ser fiable, sin importar cómo los autores elijan combinar y usar las funciones, comandos y funcionalidades de LaTeX, su sistema de paquetes y el poder de las macros de TeX. ### Las necesidades de los autores Para la mayoría de las personas, LaTeX es solo una herramienta que permite crear documentos bellamente compuestos con la libertad de elegir paquetes para ayudarte a lograrlo. La gran mayoría de los autores de LaTeX simplemente quieren que sus documentos “funcionen”: que se compongan sin errores para poder presentar su tesis, artículo, informe o terminar ese libro largamente esperado. No sin razón, los usuarios de LaTeX esperan que su colección elegida de paquetes de LaTeX conviva en paz, interoperando de manera fluida y transparente para proporcionar los comandos y funciones necesarios para producir sus documentos. Es probable que esos mismos deseos aparezcan cuando se enfrenten al requisito de producir PDF etiquetados desde LaTeX: debería “simplemente funcionar”, de forma transparente y con una intervención mínima del autor. Desafortunadamente, aún estamos bastante lejos de la experiencia de “¡Abracadabra! el etiquetado simplemente ocurre sin importar las cosas raras que haga”. Vincular los requisitos técnicos de la accesibilidad más el PDF etiquetado con LaTeX y la libertad de autoría es intrínsecamente complejo y, quizá, sea inevitable que se requiera alguna forma de “disciplina del autor” si se quieren abordar los desafíos técnicos y resolverlos de manera práctica. Un problema aparte, pero relacionado, es que el etiquetado incorrecto puede no tener ningún impacto visual en el PDF final: visualmente, puede parecer perfecto y probablemente también se imprimirá sin problemas, pero, sin que el autor lo sepa, el etiquetado puede estar “roto”, y solo se descubrirá mediante el posterior fracaso de las comprobaciones de conformidad/validación de PDF/A y/o de pruebas prácticas adicionales mediante software de accesibilidad como los lectores de pantalla. ### Archivos PDF producidos en Overleaf Overleaf ofrece a su comunidad de usuarios un editor LaTeX basado en navegador junto con herramientas de gestión de proyectos y documentos que facilitan la autoría colaborativa, todo ello construido sobre una instalación estándar de TeX Live. En efecto, Overleaf permite a los usuarios “ejecutar LaTeX a distancia” mediante un navegador web, proporcionando una capa de aislamiento frente a las complejidades de gestionar y mantener un sistema completo de TeX Live. Una consecuencia del uso por parte de Overleaf de una instalación estándar de TeX/LaTeX es que los PDF producidos a partir de código LaTeX escrito en el editor de Overleaf se crean usando exactamente las mismas tecnologías presentes en cualquier otra instalación de TeX Live de la misma versión, incluidas las configuraciones que los usuarios tienen instaladas en sus dispositivos locales. La única diferencia es que los motores TeX que compilan y procesan el código LaTeX de Overleaf se ejecutan en servidores remotos, no en máquinas locales. Overleaf sí lineariza el PDF generado por TeX para una descarga/visualización eficiente en un navegador, pero ese proceso no está relacionado con la accesibilidad del contenido PDF en sí. La producción de PDF accesibles mediante Overleaf depende de las capacidades y funciones integradas en los motores TeX estándar, junto con la disponibilidad de paquetes de macros LaTeX adecuados que los usuarios puedan desplegar como parte de su documento. Los documentos LaTeX creados usando Overleaf tienen que seguir siendo compatibles con otras instalaciones de TeX y LaTeX porque los usuarios con frecuencia necesitan exportar su proyecto LaTeX desde Overleaf para enviarlo a una amplia variedad de sistemas de revistas editoriales. Introducir funciones específicas de Overleaf en sus documentos LaTeX, o en los motores TeX subyacentes, inhibiría seriamente la libertad de los usuarios para usar su trabajo en otros lugares. Overleaf reconoce y respalda la necesidad de PDF totalmente accesibles generados a partir de sistemas de autoría TeX/LaTeX: invertimos tiempo en investigar los problemas de accesibilidad, explorando los últimos avances en motores TeX y paquetes experimentales de LaTeX que admiten PDF etiquetado. En última instancia, en el momento de escribir esto, no existe una solución “lista para usar” que los autores de LaTeX puedan utilizar (vía `\usepackage`) para generar de manera fluida y transparente PDF totalmente accesibles y conformes con PDF/UA a partir de documentos LaTeX genéricos. Cuando esas soluciones estén disponibles a través de actualizaciones de TeX Live, por supuesto estarán disponibles para la comunidad de usuarios de Overleaf. ### Algunos paquetes de LaTeX para explorar el etiquetado y la accesibilidad Para muchas personas, [tex.stackexchange](https://tex.stackexchange.com/) es el primer lugar al que acudir en busca de ayuda con TeX, LaTeX o ConTeXt. Es un recurso asombroso y tiene muchas preguntas sobre el tema de [accesibilidad](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) y la producción de PDF accesibles mediante LaTeX. Si lees y navegas por estas preguntas, y la posterior corriente de respuestas y comentarios, solo una conclusión es inevitable: en el momento actual no existe una solución completa, de nivel de producción, para crear automáticamente PDF totalmente accesibles, conformes con los estándares y etiquetados, a partir de cada tipo de documento LaTeX. Sin embargo, hay algunos paquetes que admiten el etiquetado, aunque quizá dentro de un rango restringido de casos de uso y tipos de documento. La siguiente lista se proporciona para lectores que deseen explorar el etiquetado PDF basado en LaTeX: * [`tagpdf` paquete](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): paquete muy capaz diseñado para experimentar con el etiquetado PDF. Admite pdfTeX y LuaTeX y proporciona una documentación extremadamente útil e interesante que contiene algunas notas excelentes sobre los desafíos técnicos de crear PDF etiquetados mediante motores TeX; es una lectura muy recomendable para cualquiera que desee comprender mejor los problemas implicados. Es probable que el enfoque futuro sea LuaTeX. * [`axessibility` paquete](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov y Universidad de Turín): proporciona acceso a fórmulas en archivos PDF mediante tecnologías de apoyo. * [`accesibilidad` paquete](https://ctan.org/pkg/accessibility) (Andy Clifton): crea archivos PDF etiquetados y estructurados. Las notas de CTAN indican que este paquete está “orientado a usuarios de las clases de documento KOMA-Script”. * [`accsupp` paquete](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): paquete experimental para proporcionar mejor soporte de accesibilidad para archivos PDF. Otra referencia destacable es un artículo de 2018 [Implementación de estándares PDF para la publicación matemática](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) del Dr. Ross Moore, del Departamento de Matemáticas de la Universidad Macquarie. En ese artículo, el Dr. Moore incluye un breve esquema de los desafíos del etiquetado de PDF en LaTeX: > “La principal fuente de dificultad radica en la forma en que distintos entornos pueden interactuar entre sí. Hay muchas situaciones en LaTeX en las que un entorno o estructura realmente no se completa hasta que ha comenzado el siguiente. Así que no se trata simplemente de poner etiquetas de inicio y fin alrededor de cada pieza de contenido proporcionado. En su lugar, uno necesita entender los matices de cómo distintos entornos y otras estructuras realmente comienzan y terminan, dentro del contexto establecido por el material circundante.” El Dr. Moore también es el mantenedor actual del [`paquete pdfx`](https://ctan.org/pkg/pdfx) y un experto y pionero del PDF etiquetado usando TeX/LaTeX. Merece mucho la pena buscar su trabajo, incluido este video en YouTube que ofrece perspectivas interesantes: {% embed url="" %} #### Nota sobre el paquete pdfx El [`paquete pdfx`](https://ctan.org/pkg/pdfx) El paquete (Ross Moore et al.) proporciona un excelente soporte para PDF/A-1|2|3b (archivo), y otras opciones, pero todavía no produce PDF etiquetado. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/es/mas-temas/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.