Pdf.js: Incluir soporte para archivos PDF etiquetados

Se agregó la etiqueta [triaje necesario]. ¿Necesitamos una nueva etiqueta (4-tagged-pdf) para el desarrollo relacionado con los PDF etiquetados?

¿Tenemos PDF de ejemplo? Personalmente, nunca he visto tales archivos PDF. ¿Con qué frecuencia se utilizan en la práctica?

Sí, tenemos un par de esos:

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

Si necesita más, https://encrypted.google.com/search?q=filetype%3Apdf+ "% 2FMarkInfo" + "% 2FMarked + true"

¡Gracias! En ese caso, definitivamente es interesante investigar esto.

Creo que podría ser relativamente fácil implementar esto usando una combinación de atributos HTML y ARIA, no se requieren cambios en la representación, solo agregue algunos atributos nuevos.

La información de etiquetado de PDF se almacena en el árbol StructTreeRoot, que contiene elementos de estructura con información de accesibilidad como texto alternativo, idioma y tipo semántico (H1, TH, LI, etc.). Los elementos de la estructura contienen referencias a objetos en el flujo de contenido de la página. Hay un gráfico que muestra esto aquí:
https://stackoverflow.com/a/34047585

Creo que puede inyectar la información de etiquetado de PDF en _layoutText(textDiv) usando algo como esto:

1) Busque el elemento de estructura correspondiente en el árbol StructTreeRoot para el objeto PDF que se está renderizando
2) Agregue un atributo role al div si el elemento de estructura tiene un tipo de estructura como H1, H2, LI, etc.
3) Agregue un atributo aria-label al div si el elemento de estructura tiene una entrada / Alt
4) Agregue un atributo aria-level al div correspondiente al nivel de encabezado para los tipos de estructura H1-H6

Esto debería hacer que los títulos, las listas y las imágenes sean accesibles para un lector de pantalla. Las tablas pueden ser más complicadas de implementar.

Los tipos de estructura de PDF se enumeran en la sección 14.8.4.3. de
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Para un encabezado, la representación cambiaría de esto:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

a esto:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

Luego, un lector de pantalla lo leería como "7. Evaluación, nivel de encabezado 1" y, lo que es más importante, permite al usuario saltar de un encabezado a otro con la tecla "siguiente encabezado" (lo que hace que los documentos grandes sean mucho más fáciles de navegar).

He notado que se ha eliminado la etiqueta de pdf con 4 etiquetas. ¿Es esto todavía algo que se está persiguiendo?

El hecho de que el problema esté abierto indica que lo estamos considerando. Esta es una característica y las etiquetas se han reordenado un poco.

¡Wow eso es genial! ¿Esta característica que se está considerando incluye soporte para generar archivos PDF etiquetados? Podría facilitar la implementación de algo como un analizador / analizador para archivos PDF existentes, pero también brindaría soporte para generar archivos PDF 508c.

Funcionalidad básica necesaria para generar archivos PDF 508c:

• etiquetar el documento (con un idioma y un título, posiblemente otras etiquetas)
• etiquetar los objetos estructurales dentro del PDF (encabezado, tabla, th, td, listas, etc.)
• agregar texto alternativo a los medios visuales (imágenes, video, figuras, etc.)
• crear / mantener un orden de tabulación de elementos

Si existiera la funcionalidad principal para estas 4 cosas, entonces sería posible implementar la lógica en el proceso de generación de PDF que produciría archivos PDF 508c. Lo cual, para ser honesto, sería enorme, ya que todavía no he encontrado ninguna herramienta de JavaScript OpenSource con esta funcionalidad compatible.

Después de haber escrito esto, no estoy seguro de si esto calificaría como una solicitud de función separada o no ... Con mucho gusto crearía un nuevo problema si ese fuera el caso.

He estado trabajando con @cuhaller para proporcionar un mejor cumplimiento con SC 2.4.10 y 1.1.1 de WCAG 2.0 para casos de uso específicos de la aplicación en la que está trabajando su equipo.

Creo que los cambios deberían ser suficientes para un subconjunto de lo que este problema requiere. Tendré un PR en la próxima semana siguiendo las pautas de contribución . Actualizaré este hilo cuando lo envíe.

Tengo cambios en una bifurcación de 2.3.200 de PDF.js para proporcionar niveles de encabezado y texto de imagen alternativo (sin posicionamiento) ubicado en la rama encabezados-e-img-alt-text de este repositorio .

Dudo en abrir un PR ya que hay conflictos de fusión contra el maestro y actualmente no tengo tiempo para resolverlos.

Si alguien tiene disponibilidad para actualizar esta rama con master, ¡póngase en contacto!

Edge ha promocionado el soporte nativo para archivos PDF etiquetados. Chrome ahora también lo admite, y también ha promocionado su próxima capacidad para exportar archivos PDF etiquetados desde páginas web.

Hoy, Firefox no expone el etiquetado en archivos PDF al árbol de accesibilidad / API de accesibilidad. Sin embargo, este texto está en la lista de funciones de Firefox 80 :

Firefox ahora se puede configurar como el visor de PDF del sistema predeterminado.

Si un usuario que confía en AT hace esto, o un administrador del sistema que no conoce la composición de los usuarios lo hace, puede ser problemático para aquellos usuarios que de otra manera confiaban en Edge, Chrome o Adobe's Reader para analizar archivos PDF etiquetados para ellos. .

Sugiero encarecidamente que se eliminen los consejos de las notas de la versión de 80 y que se aumente la prioridad de este error. Entiendo que Mozilla tiene recursos limitados ahora, pero la óptica para promover una función inaccesible que se sirve mejor en los navegadores de la competencia no es una buena imagen.

Nuestra organización busca implementar una solución PDF accesible para usuarios de tecnologías de asistencia. Llegamos a la conclusión de que no es posible obtener una vista previa de un PDF con PDF JS porque falta el marcado semántico. La falta de información semántica crea barreras para los usuarios que interactúan con el software de lectura de pantalla. Si bien el PDF se muestra en texto sin formato y anuncia anotaciones, no se proporciona marcado para encabezados, tablas, imágenes o enlaces.

El caso de uso que rodea las tablas es particularmente difícil para los usuarios de lectores de pantalla. Las tablas que carecen de marcado semántico no proporcionan contexto a los usuarios y es imposible para los usuarios de lectores de pantalla comprender completamente la información presentada en el PDF.

Los enlaces se anuncian como URL en lugar del texto del enlace específico, lo que dificulta la comprensión del propósito del enlace. Recomendamos que los enlaces utilicen el texto del enlace visible en lugar de la URL del enlace, para que los usuarios comprendan el enlace en contexto.

Sin este soporte, nos preocupa la implementación de PDF JS de manera amplia. ¿Existe alguna actualización o línea de tiempo sobre la compatibilidad con una función para proporcionar marcado semántico? Pedimos que este problema se considere de mayor prioridad ya que afecta la capacidad de los usuarios para percibir e interactuar con el contenido.

Hasta donde yo sé, las contribuciones son más que bienvenidas.

Gracias @trjohnst por tu trabajo en esto.

Comencé a rebasar manualmente la rama de @trjohnst en pdf.js master. Este enfoque funciona bien para etiquetas que solo necesitan un nivel; por ejemplo, títulos o imágenes con texto alternativo. Al recorrer el flujo de contenido, si encuentra una secuencia de contenido marcado, busca el elemento de estructura asociado y coloca el rol ARIA apropiado en el intervalo de texto en la salida HTML de la capa de texto pdf.js.

Desafortunadamente, esto no es suficiente para nada que necesite etiquetas anidadas; por ejemplo, listas o tablas. No creo que el enfoque pueda extenderse para cubrirlos, al menos no sin muchos casos complicados. Además, para admitir correctamente los enlaces y los campos de formulario (y tenga en cuenta que los campos de formulario no eran compatibles con pdf.js en el momento de la contribución de

En lugar de intentar hacer esto en la capa de texto, creo que tendremos que recorrer el árbol de la estructura y renderizar los nodos en base a eso, estableciendo las propiedades ARIA en los elementos que generamos. El árbol de estructura puede hacer referencia a datos tanto en el texto como en las capas de anotaciones. Podemos reordenar el texto y los nodos DOM de la capa de anotación en función del árbol de estructura (¿podría ser complicado sin romper la representación visual?) O usar aria-owns para reordenar solo el árbol a11y sin reordenar el DOM.

Desde el punto de vista arquitectónico, esto es complicado porque las capas de texto y anotaciones ya se renderizan por separado, y ahora necesitamos mirar una tercera capa (o al menos la fuente de la verdad), el árbol de estructura, que puede mover (o hacer referencia) nodos en ambos las otras capas. La forma más sencilla de hacer esto es probablemente adjuntar una identificación a cada secuencia de contenido marcado (en la capa de texto) y campo de enlace / formulario (en la capa de anotación). Veo que los campos de formulario ya tienen un atributo de datos que especifica una identificación. Si vamos a usar aria-owns, necesitamos establecer el atributo id de todos modos, por lo que esto podría alimentar a dos pájaros con un bollo. La identificación debería ser algo que podamos calcular desde fuera de las capas de texto y anotaciones, desde dentro de nuestra nueva capa de estructura. Cuando manejamos el árbol de estructura, luego damos salida a elementos para los elementos de estructura, moviendo / poseyendo elementos de las capas de texto / anotación en función de sus identificadores.

Yendo más allá del PDF etiquetado a la heurística, tendríamos que poder hacer cosas como: dado un enlace o una anotación de campo de formulario, ¿su rectángulo abarca algo en la capa de texto? si es así, la anotación debe estar asociada con su texto (aria-owns o DOM move). Nuevamente, eso es arquitectónicamente complicado porque las capas de texto y anotaciones (y sus entradas) están separadas y no creo que tengamos ningún estado en caché de esas capas que podamos usar. Sin embargo, potencialmente podemos mirar los límites de los nodos representados por el texto y las capas de anotaciones, aunque eso comienza a difuminar los límites arquitectónicos entre el contenido y el procesamiento de la presentación.

Si bien una implementación inicial de PDF etiquetado no necesariamente necesita ser compatible con la heurística, recomiendo encarecidamente que esto se considere parte del diseño arquitectónico. La realidad es que, desafortunadamente, los archivos PDF sin etiquetar son muy frecuentes y sería triste estar encerrado en una arquitectura que no permite que estos sean más accesibles. (Tenga en cuenta que Acrobat Reader y, en mucha menor medida, Chromium, utilizan la heurística para intentar que los archivos PDF sin etiquetar sean más accesibles).