Qué exige la normativa a un PDF y cuándo elegir otro formato

Antes de abrir Word o Acrobat conviene responder dos preguntas: qué requisitos legales y técnicos debe cumplir este PDF y si el PDF es, de verdad, el formato adecuado para ese contenido. En la lección anterior viste qué elementos técnicos hacen accesible un PDF; aquí verás cómo encajan con la EN 301 549 (PDF, se abre en una ventana nueva), el RD 1112/2018 (PDF, se abre en una ventana nueva) y la Ley 11/2023 (PDF, se abre en una ventana nueva), qué matices tiene aplicar las WCAG a un documento y con qué criterios decidir entre PDF, HTML o ambos.

Tres capas de requisitos que no conviene mezclar

Cuando alguien dice «el PDF tiene que ser accesible», puede estar hablando de tres cosas distintas que se apoyan unas en otras:

1. La obligación legal: el RD 1112/2018 (que transpone la Directiva (UE) 2016/2102 (PDF, se abre en una ventana nueva)) para el sector público, y la Ley 11/2023 (que transpone la Directiva (UE) 2019/882 (PDF, se abre en una ventana nueva)) para determinados productos y servicios del sector privado. La ley dice quién debe cumplir y qué contenidos están cubiertos.
2. La norma técnica de referencia: la EN 301 549 v3.2.1, cuyo capítulo 10 recoge los requisitos para documentos no web. Es la vara de medir en auditorías, declaraciones de accesibilidad y pliegos.
3. La norma de formato: PDF/UA (ISO 14289), que dice cómo debe construirse el fichero para que las tecnologías de apoyo puedan usarlo. Es el medio técnico más fiable para cumplir el capítulo 10 en un PDF, pero la ley no la cita directamente.

El capítulo 10 de la EN 301 549 aplicado al PDF

El capítulo 10 reproduce los criterios de conformidad de las WCAG adaptados a documentos que no son páginas web. Para interpretarlos, el W3C publica la nota WCAG2ICT, que explica cómo leer cada criterio cuando el «contenido» es un documento o un software. Tres matices que todo especialista en PDF debe tener presentes:

La base es WCAG 2.1, no 2.2

La EN 301 549 v3.2.1 se publicó en 2021 y toma como base las WCAG 2.1. Los criterios añadidos por WCAG 2.2, como 2.4.11 Foco no oculto (mínimo), 2.5.8 Tamaño del objetivo (mínimo), 3.3.7 Entrada redundante o 3.3.8 Autenticación accesible (mínimo), no forman parte del capítulo 10 de esa versión. Aplicarlos es buena práctica (un formulario PDF que obliga a repetir los mismos datos en tres páginas es igual de frustrante), pero en un informe de conformidad hay que distinguir lo exigido de lo recomendado.

Criterios sin requisito para documentos

Algunos criterios WCAG hablan de «conjuntos de páginas web» o de bloques que se repiten entre páginas. Al trasladarlos a un documento aislado no tienen un equivalente directo, y la EN 301 549 los deja sin requisito (en el texto de la norma aparecen como Void, vacíos) en el capítulo 10:

Que la norma no los exija no significa que no aporten: los marcadores siguen siendo una técnica WCAG documentada (PDF2) y una ayuda enorme en un documento de 80 páginas.

Criterios que el formato pone difíciles

Un PDF es un formato de maquetación fija. 1.4.10 Reajuste de los elementos y 1.4.12 Espaciado del texto dependen de que el visor pueda redistribuir el texto, lo que solo funciona razonablemente si el documento está bien etiquetado; 1.4.4 Cambio de tamaño del texto se resuelve con el zoom, pero obliga a desplazarse en horizontal. Lee las notas de la EN 301 549 sobre estos criterios antes de dar un veredicto. En la práctica, cuando el público va a leer sobre todo en el móvil, este es uno de los argumentos más sólidos a favor de ofrecer el contenido en HTML.

Sector público: qué documentos están cubiertos

El RD 1112/2018 se aplica a los sitios web y aplicaciones del sector público, y los documentos publicados en ellos forman parte del contenido que debe ser accesible. La Directiva (UE) 2016/2102 excluye los formatos de archivo ofimáticos publicados antes del 23 de septiembre de 2018, salvo que sean necesarios para procesos administrativos activos; el real decreto (art. 3.4) recoge la misma exclusión para los publicados antes de su entrada en vigor, el 20 de septiembre de 2018, salvo que sean necesarios para tareas administrativas activas. Además:

• La declaración de accesibilidad debe identificar los contenidos no accesibles, incluidos los PDF, y las alternativas disponibles.
• El mecanismo de comunicación permite a cualquier persona pedir la información en un formato accesible; la administración debe poder responder.
• La carga desproporcionada se puede invocar para contenidos concretos, pero debe justificarse y declararse; no sirve como exención general de «todos los PDF antiguos».

Sector privado: la Ley 11/2023

La Ley 11/2023 no regula «los PDF», sino servicios concretos: comercio electrónico, servicios bancarios para consumidores, transporte de viajeros, comunicaciones electrónicas, libros electrónicos, entre otros. Pero muchos de esos servicios se prestan con documentos: contratos y condiciones generales, extractos y recibos bancarios, billetes electrónicos, facturas o confirmaciones de pedido. Cuando esos documentos forman parte del servicio cubierto, la información que contienen debe ser perceptible, operable y comprensible para la persona usuaria. En los servicios bancarios, la Directiva pide además que la información sea comprensible sin superar el nivel B2 del Marco Común Europeo de Referencia para las Lenguas.

¿PDF, HTML o ambos?

La pregunta más rentable de todo el curso es esta: ¿hace falta que este contenido sea un PDF? El PDF tiene ventajas reales (impresión fiel, firma electrónica, archivo), pero el HTML se adapta a cualquier pantalla, lo interpretan mejor las tecnologías de apoyo y se actualiza sin regenerar ficheros.

Un patrón que funciona en administraciones y empresas es «HTML primero, PDF como descarga»: el contenido principal se publica como página web y el PDF se ofrece para quien quiera imprimirlo o archivarlo. El BOE es un buen ejemplo: cada disposición se puede leer en HTML y se ofrece además el PDF de la publicación oficial. Si ofreces dos versiones, ambas deben estar sincronizadas: una versión HTML desactualizada no es una alternativa equivalente. Las propias WCAG admiten una «versión alternativa conforme», pero exigen que ofrezca la misma información y funcionalidad y que se pueda llegar a ella de forma accesible.

El caso de los formularios

Un trámite en la sede electrónica con un formulario HTML bien construido es casi siempre más accesible que un PDF rellenable: valida los datos al momento y evita descargar, rellenar, guardar y volver a subir un fichero. Reserva el PDF rellenable para casos justificados (uso sin conexión, impresos normalizados) y, si lo mantienes, hazlo accesible como verás en la lección de remediación en Acrobat Pro.

El caso del archivo

Para conservación a largo plazo se usa PDF/A. Los niveles de conformidad «a» de PDF/A-1, PDF/A-2 y PDF/A-3 exigen documento etiquetado y texto con mapa Unicode; los niveles «b» no. Si tu organización archiva en PDF/A-2b, el documento puede ser perfectamente válido para archivo y completamente inaccesible. PDF/A y PDF/UA son compatibles: un mismo fichero puede declarar ambas conformidades.

Resumen

• Distingue tres capas: la ley (RD 1112/2018, Ley 11/2023), la norma técnica (EN 301 549 cap. 10) y la norma de formato (PDF/UA).
• La EN 301 549 v3.2.1 se basa en WCAG 2.1; los criterios nuevos de WCAG 2.2 son buena práctica en PDF, no requisito de esa versión.
• 2.4.1, 2.4.5, 3.2.3 y 3.2.4 quedan sin requisito para documentos, pero marcadores, índices y coherencia siguen aportando.
• Los documentos ofimáticos anteriores a septiembre de 2018 solo quedan excluidos si no son necesarios para procesos administrativos activos.
• Pregúntate siempre si el contenido debe ser PDF: «HTML primero, PDF como descarga» y trámites en la sede en lugar de formularios PDF.