Addaw, ir a inicio Donar

Lección 9 de 10 · 12 min de lectura · Revisado el 26/10/2026

PDF generados por sistemas: certificados, facturas y justificantes etiquetados

En una administración o una gran empresa, la mayoría de los PDF no los escribe una persona en Word: los genera un sistema. Justificantes de registro, certificados de empadronamiento, notificaciones, recibos, facturas, billetes electrónicos o extractos salen por miles cada día de un gestor de expedientes, un ERP o una plataforma de pago. Ninguno de ellos se puede remediar a mano. Esta lección explica cómo conseguir que nazcan etiquetados, qué rutas técnicas existen y cómo controlar su calidad a escala.

Por qué aquí no sirve remediar

La remediación en Acrobat que viste en este curso funciona para documentos que se publican una vez. Con los documentos generados fallan las tres premisas:

  • Volumen: un ayuntamiento mediano puede emitir decenas de miles de justificantes al año. Cada uno es un fichero distinto.
  • Tiempo real: el certificado se genera cuando la persona lo pide y se descarga en segundos. No hay un momento intermedio para corregirlo.
  • Firma electrónica: muchos de estos documentos se firman (habitualmente con firma PAdES, la firma avanzada propia de PDF) o llevan un sello de órgano. Modificar el fichero después de firmarlo invalida la firma.

La consecuencia es clara: la accesibilidad debe estar en la plantilla y en el motor de generación. Y como el generador suele ser un producto o un desarrollo contratado, el requisito debe estar en el pliego o en el contrato, tal como se trata en el curso de contratación pública accesible del nivel 5: «los documentos PDF generados por el sistema serán conformes con la EN 301 549 v3.2.1 (PDF, se abre en una ventana nueva) capítulo 10 y estarán etiquetados conforme a PDF/UA-1».

Punto clave

En documentos generados se valida la plantilla, no cada documento. Una plantilla bien construida produce miles de PDF accesibles; una plantilla defectuosa produce miles de PDF inaccesibles. Cada cambio de plantilla o de versión del motor exige repetir la validación.

Rutas técnicas para generar PDF etiquetado

No todos los motores de generación etiquetan, y los que lo hacen suelen necesitar que se active una opción. Las rutas más comunes:

RutaEjemplosQué vigilar
HTML y CSS a PDFChromium sin interfaz (Puppeteer y Playwright tienen opciones tagged y outline), WeasyPrint (variante PDF/UA), Prince (perfil PDF/UA-1)La calidad depende de la semántica del HTML; comprobar cómo se tratan cabeceras y pies
XSL-FOApache FOP, con su modo de accesibilidad y el perfil PDF/UA-1Hay que declarar roles y texto alternativo en la plantilla FO
Bibliotecas de programacióniText y otras con API de etiquetadoEl etiquetado se programa: si el código no lo pide, no existe
Generadores de informesJasperReports y similares con exportación etiquetadaSuele requerir propiedades por elemento; los valores por defecto no etiquetan
LaTeXProyecto de etiquetado de LaTeX, activable con \DocumentMetadataEn evolución; algunos paquetes aún no lo admiten

Las opciones concretas cambian entre versiones: consulta siempre la documentación de la versión que uses y, sobre todo, valida el resultado. Que un motor «soporte PDF/UA» significa que puede producirlo si la plantilla aporta la información necesaria; no que convierta en accesible cualquier entrada.

La plantilla semántica: el PDF hereda lo que le das

Con la ruta HTML a PDF, que es hoy la más extendida en desarrollos web, el principio es el mismo que con Word: el PDF hereda la estructura del origen. Un justificante construido con div y clases de estilo producirá un PDF sin encabezados ni tablas.

Error frecuente

Plantilla que se ve bien y genera un PDF sin estructura:

<html>
<head><title>plantilla_v2</title></head>
<body>
  <div class="titulo">Justificante de registro</div>
  <div class="fila"><span class="neg">N.º</span> 2026/018734</div>
  <img src="qr.png">
</body>
</html>

Ejemplo

La misma plantilla con semántica, idioma, título y alternativa del código QR:

<html lang="es">
<head><title>Justificante de registro 2026/018734</title></head>
<body>
  <h1>Justificante de registro</h1>
  <p><strong>Número de registro:</strong> 2026/018734</p>
  <h2>Documentos presentados</h2>
  <table>
    <thead><tr><th scope="col">Documento</th><th scope="col">Páginas</th></tr></thead>
    ...
  </table>
  <img src="qr.png" alt="Código QR para verificar este justificante en la sede electrónica">
  <p>Código seguro de verificación: 4XK2-P9QM-77TR</p>
</body>
</html>

La lista mínima para la plantilla: lang en el elemento raíz, un title descriptivo que incluya el dato variable que identifica el documento, encabezados reales, tablas de datos con th y scope, texto alternativo en imágenes informativas y nada de información transmitida solo con contenido generado por CSS (::before, ::after), que muchos motores no trasladan bien a la estructura.

Casos típicos de la administración electrónica

Código seguro de verificación y QR

Los documentos de las administraciones españolas suelen llevar un código seguro de verificación (CSV) y un código QR para comprobar su autenticidad en la sede electrónica. A menudo el CSV se imprime en vertical en el margen. Ese texto es contenido real (la persona lo necesita para verificar el documento), así que no debe ser un artefacto: debe estar etiquetado y colocado en el orden de lectura, normalmente al final. El QR es una figura con un alt que explique su función, acompañado de la dirección de verificación en texto.

Sellos, firmas y escudos

El escudo de la cabecera que se repite en cada página es un artefacto. La representación visual de la firma («Firmado por… el…») debe existir también como texto legible: una imagen de un sello sin texto no informa de quién firma ni cuándo.

Documentos bilingües

En comunidades con lengua cooficial es habitual el documento a dos columnas o a dos bloques, en castellano y en catalán, gallego, euskera o valenciano. Cada parte debe llevar su idioma (atributo lang en la plantilla, /Lang en el PDF) para cumplir 3.1.2 Idioma de las partes, y el orden de lectura debe recorrer un idioma completo antes del otro, no saltar línea a línea entre columnas.

Facturas y recibos

La tabla de conceptos de una factura es una tabla de datos: cabeceras de columna, importes con su unidad y totales identificados como tales. Recuerda que en la facturación electrónica al sector público el documento con valor fiscal es el fichero estructurado (Facturae, en XML); el PDF es una representación para personas, y es precisamente esa representación la que debe ser accesible.

Metadatos y orden del proceso

El motor debe producir, o un paso posterior debe añadir: título en XMP con DisplayDocTitle activado, idioma del documento, fuentes incrustadas con mapa Unicode e identificador pdfuaid:part solo si se valida la conformidad. El orden del proceso importa:

  1. Generar el PDF etiquetado desde la plantilla.
  2. Completar metadatos si el motor no lo hace.
  3. Validar (en pruebas, no en cada emisión).
  4. Firmar o sellar. Después de la firma, el documento ya no se toca.

Control de calidad a escala

La validación de plantillas encaja bien en la integración continua. Con veraPDF, que viste en la lección de validación, puedes comprobar por línea de comandos un lote de documentos de muestra cada vez que cambia la plantilla:

verapdf --flavour ua1 muestras/*.pdf

El lote de muestra debe incluir los casos extremos: nombres muy largos, una tabla que salta de página, un documento de una sola línea y otro de veinte páginas, caracteres especiales (ñ, tildes, «ç», «l·l») y, si procede, la versión bilingüe. Complementa la validación automática con una revisión manual y con lector de pantalla de cada plantilla, como viste en la lección sobre pruebas con tecnologías de apoyo. Ninguna herramienta detecta que el alt del QR dice «imagen» o que el CSV ha quedado como artefacto.

Pruébalo tú

Descarga un justificante o certificado de cualquier sede electrónica que hayas usado (registro, padrón, un pago de tasas). Ábrelo en PAC o en Acrobat y responde: ¿tiene etiquetas?, ¿qué título muestra?, ¿el CSV es texto etiquetado o artefacto?, ¿el QR tiene alt? En cinco minutos sabrás si esa plantilla se diseñó pensando en la accesibilidad.

Resumen

  • Los PDF generados por sistemas no se pueden remediar: volumen, tiempo real y firma obligan a hacerlos accesibles en la plantilla y el motor.
  • Existen motores que etiquetan (HTML a PDF, XSL-FO, bibliotecas, generadores de informes), pero casi siempre hay que activarlo y darles una plantilla semántica.
  • CSV, QR, firmas visibles y documentos bilingües son contenido que debe etiquetarse, describirse y ordenarse bien.
  • Primero se genera y valida, después se firma; tras la firma el fichero no se modifica.
  • Valida cada plantilla con un lote de muestras en integración continua (veraPDF) y con revisión humana en cada cambio.

Comprueba lo que has aprendido

Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.

Matricularme · nivel 6 (119 €)