Accesibilidad de PDFs en C# para el Real Decreto 1112/2018 y el sector público español

Real Decreto 1112/2018 y la Directiva (UE) 2016/2102

El Real Decreto 1112/2018, de 7 de septiembre, transpone al ordenamiento español la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público. El calendario de cumplimiento ya está plenamente vigente:

• 23 de septiembre de 2018: entrada en vigor del Real Decreto.
• 23 de septiembre de 2019: aplicable a sitios web del sector público publicados a partir de esa fecha.
• 23 de septiembre de 2020: aplicable a sitios web del sector público existentes.
• 23 de junio de 2021: aplicable a aplicaciones móviles del sector público.

El ámbito subjetivo cubre la Administración General del Estado, las Comunidades Autónomas, las Entidades Locales, las universidades públicas, los organismos autónomos y entidades del sector público estatal y autonómico, y cualquier entidad financiada mayoritariamente con fondos públicos. La obligación se extiende a todos los documentos PDF publicados en esos sitios — resoluciones, normativas, modelos, anexos, instrucciones técnicas, formularios. Un PDF inaccesible publicado en una sede electrónica del sector público es una infracción del Real Decreto.

UNE-EN 301 549 y WCAG 2.1 AA

El estándar técnico de referencia del Real Decreto 1112/2018 es la norma UNE-EN 301 549 — la versión armonizada europea del estándar ETSI EN 301 549 sobre requisitos de accesibilidad para productos y servicios de tecnologías de la información y las comunicaciones. La UNE-EN 301 549 incorpora por referencia el estándar internacional WCAG 2.1 (Web Content Accessibility Guidelines) del W3C, en su nivel de conformidad AA.

Para PDF específicamente, la norma de referencia es PDF/UA (ISO 14289) — el perfil ISO de PDF accesible. PDF/UA no es WCAG — es una norma específica para el formato PDF que define las condiciones que un documento debe cumplir para ser accesible: estructura etiquetada (Tagged PDF), orden de lectura lógico, idioma declarado, alt text en imágenes, encabezados de tabla correctos, marcadores y navegación, metadatos XMP completos.

La relación operativa para el desarrollador ibérico es: WCAG 2.1 AA define las propiedades de accesibilidad del contenido; PDF/UA define las propiedades de accesibilidad del formato PDF. Para que un PDF cumpla con el Real Decreto 1112/2018, debe cumplir ambos — el contenido debe satisfacer WCAG 2.1 AA y el formato debe ser PDF/UA conforme.

Observatorio de Accesibilidad Web (OAW)

El Observatorio de Accesibilidad Web (administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_Accesibilidad), dependiente del Ministerio de Asuntos Económicos y Transformación Digital, es el organismo encargado de auditar el cumplimiento del Real Decreto 1112/2018 por parte del sector público. Realiza dos tipos de auditoría:

• Auditorías simplificadas — automatizadas, ejecutadas periódicamente sobre una muestra de páginas y documentos publicados por cada organismo. Emiten un sello de accesibilidad clasificatorio (sin cumplimiento, parcialmente conforme, plenamente conforme).
• Auditorías en profundidad — manuales, ejecutadas con menor frecuencia pero con mayor rigor, contrastadas contra los 87 criterios de la UNE-EN 301 549 y los 50+ criterios de WCAG 2.1 AA.

Los resultados de las auditorías son públicos y se publican en el portal del OAW. El estado de cumplimiento de cada sitio del sector público es información transparente, y las quejas formales del ciudadano por inaccesibilidad pueden tramitarse a través de la Unidad responsable de accesibilidad que cada organismo está obligado a designar.

Ley 11/2023 y el European Accessibility Act

La Ley 11/2023, de 8 de mayo, de trasposición de Directivas de la Unión Europea — concretamente, la Directiva (UE) 2019/882 conocida como European Accessibility Act (EAA) — extiende las obligaciones de accesibilidad al sector privado para determinadas categorías de productos y servicios. La aplicación es desde el 28 de junio de 2025 para nuevos productos y servicios. Cubre, entre otros:

• Servicios de comercio electrónico
• Servicios bancarios al consumidor
• Servicios audiovisuales
• Servicios de transporte de pasajeros
• Servicios telefónicos y de comunicaciones electrónicas
• Libros electrónicos y software dedicado a su lectura

Para PDF en el sector privado cubierto por la Ley 11/2023 — facturas electrónicas B2C que circulan como PDF, contratos digitales con consumidores, documentación contractual de servicios financieros — la accesibilidad PDF/UA pasa a ser obligatoria. El impacto se solapa con Crea y Crece B2B (que requiere Facturae XML, no exige accesibilidad del PDF visualizable pero la mejora) y con los flujos sanitarios bajo Ley 41/2002 (donde el paciente con discapacidad tiene derecho a una historia clínica accesible).

Relación PDF/UA, PDF/A-3a y ENI

Para el sector público español, la elección técnica de versión PDF es habitualmente la combinación PDF/A-3a + PDF/UA: PDF/A-3 (ISO 19005-3) aporta el perfil archivable de larga vida con capacidad de embeber anexos arbitrarios (Facturae XML, justificantes de presentación, etc.); el sufijo a (accessible) añade el etiquetado estructural y los requisitos de mapeo Unicode que PDF/UA exige. El resultado es un documento que cumple simultáneamente con:

• El Esquema Nacional de Interoperabilidad (Real Decreto 4/2010) que impone PDF/A como formato preservable preferido para el sector público.
• El Real Decreto 1112/2018 y la UNE-EN 301 549 que exigen accesibilidad PDF/UA.
• La Norma Técnica de Interoperabilidad de Documento Electrónico bajo ENI, que establece la estructura de metadatos firmados para preservación a largo plazo.

Cuando el flujo del sector público requiere también firma electrónica cualificada (resoluciones administrativas, notificaciones electrónicas, expedientes archivables), se añade la capa PAdES-LTV con certificado FNMT-RCM del firmante. La pila completa para un expediente administrativo accesible y archivable es: HTML → IronPDF render → PDF/A-3a (accesible) → embebido de anexos → firma PAdES-LTV → archivado ENI.

Conversión HTML a PDF/UA con IronPDF

El método RenderHtmlAsPdfUA de IronPDF genera PDFs accesibles directamente desde HTML, aplicando el etiquetado estructural automático que PDF/UA exige:

:path=/static-assets/pdf/content-code-examples/tutorials/government-accessible-pdf/render-html-to-pdfua.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Para que el resultado pase la auditoría OAW, el HTML de entrada debe seguir las prácticas estándar de accesibilidad web: jerarquía coherente de encabezados (<h1> único, <h2> para secciones principales, sin saltos arbitrarios), <table> con <th> para encabezados de columna y fila, <img alt="..."> para todas las imágenes informativas (alt vacío alt="" para imágenes decorativas), enlaces con texto descriptivo (no "haga clic aquí"), formularios con <label for="..."> asociados a sus campos, y suficiente contraste de color (4.5:1 para texto normal, 3:1 para texto grande).

IronPDF aplica al PDF de salida las propiedades estructurales que PDF/UA exige a partir del HTML de entrada — pero las prácticas de accesibilidad del HTML origen son responsabilidad del autor del contenido. Un HTML que no respeta los estándares de accesibilidad producirá un PDF que tampoco los respeta, con independencia del método de renderizado usado.

Documentos castellanos y la directiva lang="es"

El HTML del documento debe declarar el idioma principal con el atributo lang en la etiqueta <html>. Para castellano:

<html lang="es">

<html lang="es">

Para territorios con lengua cooficial, los códigos correspondientes son:

• Catalán: lang="ca"
• Euskera (vasco): lang="eu"
• Gallego: lang="gl"
• Aranés (variedad del occitano hablada en el Valle de Arán): lang="oc"

Para variantes regionales específicas, los códigos extendidos BCP 47 admiten más detalle: lang="es-ES" para castellano europeo, lang="ca-ES-VALENCIA" para valenciano específicamente. Pero la mayoría de las auditorías OAW se conforman con el código de dos letras del idioma principal.

Catalán, euskera, gallego y la accesibilidad multilingüe

Los documentos del sector público en territorios con lengua cooficial deben publicarse habitualmente en castellano + lengua cooficial (la Constitución Española y los Estatutos de Autonomía correspondientes establecen la cooficialidad). Cuando un PDF contiene fragmentos en varias lenguas, cada fragmento debe declarar su idioma localmente con <span lang="ca">contingut català</span> o equivalente.

Para los lectores de pantalla (JAWS, NVDA, VoiceOver) la declaración correcta del idioma del fragmento es crítica: sin ella, el sintetizador de voz pronuncia el catalán con fonemas castellanos o viceversa, produciendo un audio prácticamente incomprensible para el usuario con discapacidad visual.

La ONCE (Organización Nacional de Ciegos Españoles) — la organización de referencia sobre accesibilidad para personas ciegas en España — mantiene guías técnicas detalladas sobre prácticas de accesibilidad documental para usuarios de lector de pantalla. Su sitio (once.es) incluye recomendaciones operativas para administraciones públicas españolas que publican documentación dirigida al colectivo. Para territorios con lengua cooficial, la CNSE (Confederación Estatal de Personas Sordas) y la Fundación CNSE publican directrices específicas para accesibilidad de personas sordas, incluyendo recomendaciones sobre subtitulado y lengua de signos española (LSE).

Estructura semántica para lectores de pantalla

Los lectores de pantalla navegan los PDFs accesibles mediante la estructura etiquetada (Tagged PDF). Esta estructura es una representación lógica del contenido — H1, H2, H3, párrafos, listas, tablas, imágenes con su descripción — separada del flujo visual del documento. El método RenderHtmlAsPdfUA de IronPDF construye automáticamente esta estructura a partir del HTML de entrada, traduciendo <h1> a <H1> en el árbol PDF/UA, <table> a <Table> con sub-elementos <TR> y <TH>/<TD>, etc.

:path=/static-assets/pdf/content-code-examples/tutorials/government-accessible-pdf/structured-tagged-pdf.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Para validar visualmente el árbol estructural del PDF de salida — útil durante el desarrollo —, abra el PDF en Adobe Acrobat Pro y muestre el panel Etiquetas (View → Show/Hide → Navigation Panes → Tags). Cada elemento estructural debería corresponderse con un nodo del árbol. La herramienta gratuita PAC 2024 (PDF Accessibility Checker) ofrece validación más detallada contra los criterios PDF/UA.

Tablas accesibles con encabezados correctos

Las tablas son el elemento más frecuentemente mal-implementado en PDFs del sector público español. Una tabla accesible requiere que cada celda de datos esté asociada lógicamente con sus encabezados de fila y columna, de modo que el lector de pantalla pueda anunciar "Modelo 303, ejercicio 2026, primer trimestre, base imponible al 21 %, 1.250,00 €" cuando el usuario navega a la celda correspondiente.

En HTML:

<table>
  <caption>Resumen Modelo 303 — primer trimestre 2026</caption>
  <thead>
    <tr>
      <th scope="col">Tipo IVA</th>
      <th scope="col">Base imponible</th>
      <th scope="col">Cuota</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">21 %</th>
      <td>1.250,00 €</td>
      <td>262,50 €</td>
    </tr>
    <tr>
      <th scope="row">10 %</th>
      <td>800,00 €</td>
      <td>80,00 €</td>
    </tr>
  </tbody>
</table>

<table>
  <caption>Resumen Modelo 303 — primer trimestre 2026</caption>
  <thead>
    <tr>
      <th scope="col">Tipo IVA</th>
      <th scope="col">Base imponible</th>
      <th scope="col">Cuota</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">21 %</th>
      <td>1.250,00 €</td>
      <td>262,50 €</td>
    </tr>
    <tr>
      <th scope="row">10 %</th>
      <td>800,00 €</td>
      <td>80,00 €</td>
    </tr>
  </tbody>
</table>

El atributo scope y el uso de <th> para los encabezados de fila (no sólo de columna) son clave. IronPDF traslada esta estructura al PDF/UA de salida — los lectores de pantalla podrán entonces anunciar correctamente cada celda.

Texto alternativo en imágenes (ONCE-aligned)

Toda imagen informativa debe llevar texto alternativo descriptivo. Las directrices de la ONCE recomiendan alt text concisos pero suficientes para transmitir la información visual:

<img src="organigrama-aeat.png" 
     alt="Organigrama de la Agencia Estatal de Administración Tributaria mostrando la dependencia de los Departamentos de Gestión, Inspección, Recaudación y Aduanas e Impuestos Especiales del Director General">

<img src="separador-decorativo.png" alt="">

<a href="presentacion-303.html"><img src="boton-presentar.png" alt="Presentar Modelo 303"></a>

<img src="organigrama-aeat.png" 
     alt="Organigrama de la Agencia Estatal de Administración Tributaria mostrando la dependencia de los Departamentos de Gestión, Inspección, Recaudación y Aduanas e Impuestos Especiales del Director General">

<img src="separador-decorativo.png" alt="">

<a href="presentacion-303.html"><img src="boton-presentar.png" alt="Presentar Modelo 303"></a>

Para imágenes complejas (gráficos, diagramas técnicos) donde el alt text breve no basta, la práctica WCAG es proporcionar una descripción larga separada — bien como texto cercano en el documento, bien con el atributo longdesc que apunta a una explicación detallada.

Modelos AEAT y formularios FACe con etiquetas semánticas

Cada campo del formulario debe tener una etiqueta semántica asociada que el lector de pantalla anuncie cuando el foco entra en el campo. En HTML, esto se logra con <label for="campo-id">:

<form>
  <label for="nif-emisor">NIF del emisor</label>
  <input type="text" id="nif-emisor" name="nif_emisor" 
         pattern="[0-9]{8}[A-HJ-NP-TV-Z]|[A-HJ-NP-SUVW][0-9]{7}[0-9A-J]|[XYZ][0-9]{7}[A-HJ-NP-TV-Z]"
         aria-describedby="nif-help">
  <span id="nif-help">Formato: 8 dígitos + letra (persona física), letra + 7 dígitos + control (entidad), o letra X/Y/Z + 7 dígitos + letra (NIE).</span>

  <label for="base-imponible">Base imponible (€)</label>
  <input type="number" id="base-imponible" name="base_imponible" step="0.01">
</form>

<form>
  <label for="nif-emisor">NIF del emisor</label>
  <input type="text" id="nif-emisor" name="nif_emisor" 
         pattern="[0-9]{8}[A-HJ-NP-TV-Z]|[A-HJ-NP-SUVW][0-9]{7}[0-9A-J]|[XYZ][0-9]{7}[A-HJ-NP-TV-Z]"
         aria-describedby="nif-help">
  <span id="nif-help">Formato: 8 dígitos + letra (persona física), letra + 7 dígitos + control (entidad), o letra X/Y/Z + 7 dígitos + letra (NIE).</span>

  <label for="base-imponible">Base imponible (€)</label>
  <input type="number" id="base-imponible" name="base_imponible" step="0.01">
</form>

El atributo aria-describedby enlaza el campo con una descripción adicional — útil para los formatos sensibles del NIF español, donde el lector de pantalla puede entonces anunciar "Campo NIF del emisor. Formato: ocho dígitos más letra..." sin que el usuario tenga que adivinar la convención.

:path=/static-assets/pdf/content-code-examples/tutorials/government-accessible-pdf/accessible-forms.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Marcadores y navegación documental

Para PDFs largos del sector público (memorias anuales, pliegos de cláusulas, instrucciones técnicas con múltiples anexos), los marcadores (bookmarks) son la herramienta de navegación accesible más importante. Permiten al usuario con discapacidad visual saltar directamente a la sección de interés sin tener que escuchar la lectura secuencial completa.

IronPDF genera marcadores automáticamente a partir de la jerarquía de encabezados HTML cuando se usa RenderHtmlAsPdfUA. La estructura es:

• <h1> → marcador de primer nivel
• <h2> → marcador anidado de segundo nivel
• <h3> → marcador anidado de tercer nivel
• ... y así sucesivamente

Un PDF accesible bien estructurado tiene un panel de marcadores que refleja el índice del documento — y los lectores de pantalla pueden anunciarlo como tal cuando el usuario abre el documento.

Conformidad PDF/UA en C

IronPDF aplica las transformaciones que PDF/UA exige durante el renderizado, pero la validación independiente del documento de salida es necesaria antes de su publicación. Tres herramientas son habituales en el ecosistema ibérico:

• veraPDF (verapdf.org) — validador open-source de referencia industrial para PDF/A y PDF/UA. Integrable en CI/CD vía línea de comandos.
• PAC 2024 (PDF Accessibility Checker, desarrollado por la fundación suiza Access for All) — gratuito, muy detallado para PDF/UA específicamente.
• Adobe Acrobat Pro Preflight — incluye perfiles de validación PDF/UA; útil cuando la organización ya tiene licencias Adobe.

Integrar veraPDF en el pipeline de generación PDF/UA es la práctica recomendada:

:path=/static-assets/pdf/content-code-examples/tutorials/government-accessible-pdf/verify-pdfua-compliance.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Auditoría OAW y sellos de accesibilidad

Cada organismo del sector público español está obligado a publicar en su sitio web una declaración de accesibilidad firmada (la Unidad responsable de accesibilidad del organismo es quien la mantiene actualizada). Esta declaración debe enumerar:

• El estado de cumplimiento (plenamente conforme, parcialmente conforme, no conforme).
• Los criterios UNE-EN 301 549 / WCAG 2.1 AA que no se satisfacen y la justificación (típicamente "carga desproporcionada" o "exclusión por antigüedad anterior al 23 de septiembre de 2018").
• El procedimiento para presentar quejas formales por inaccesibilidad.
• La fecha de elaboración y la fecha de última revisión.

Las auditorías OAW se cruzan contra esta declaración. Un sitio que se autoproclama "plenamente conforme" pero contiene PDFs con errores de accesibilidad detectables automáticamente recibirá una calificación reducida en la siguiente auditoría OAW, y la auditoría pública genera presión política y mediática para corregir el incumplimiento.

Las multas por incumplimiento del Real Decreto 1112/2018 oscilan entre 1.000 € (infracciones leves) y 1.000.000 € (infracciones muy graves), bajo el régimen sancionador específico establecido en la Ley General de derechos de las personas con discapacidad y de su inclusión social. La AEPD bajo LOPDGDD puede sancionar adicionalmente cuando la inaccesibilidad afecta a tratamientos con datos personales del ciudadano y constituye discriminación documentada.