Pdf.js: Inclui suporte para PDFs marcados

Adicionado rótulo [triage-needed]. Precisamos de um novo rótulo (4-tagged-pdf) para desenvolvimento relacionado a PDFs com tags?

Temos PDFs de exemplo? Eu, pessoalmente, nunca vi esses PDFs. Com que frequência são usados ​​na prática?

Sim, temos alguns deles:

$ 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

Se precisar de mais, https://encrypted.google.com/search?q=filetype%3Apdf+ "% 2FMarkInfo" + "% 2FMarked + true"

Obrigado! Nesse caso, é definitivamente interessante examinar isso.

Acho que pode ser relativamente fácil implementar isso usando uma combinação de atributos HTML e ARIA - sem alterações na renderização necessária - basta adicionar alguns novos atributos.

As informações de marcação de PDF são armazenadas na árvore StructTreeRoot, que contém elementos de estrutura com informações de acessibilidade como texto alternativo, idioma e tipo semântico (H1, TH, LI, etc). Os elementos de estrutura contêm referências a objetos no fluxo de conteúdo da página. Há um gráfico mostrando isso aqui:
https://stackoverflow.com/a/34047585

Acho que você pode injetar as informações de marcação de PDF em _layoutText(textDiv) usando algo assim:

1) Procure o elemento de estrutura correspondente na árvore StructTreeRoot para o objeto PDF sendo renderizado
2) Adicione um atributo role ao div se o elemento de estrutura tiver um tipo de estrutura como H1, H2, LI etc.
3) Adicione um atributo aria-label ao div se o elemento de estrutura tiver uma entrada / Alt
4) Adicione um atributo aria-level ao div correspondente ao nível de título para os tipos de estrutura H1-H6

Isso deve tornar os títulos, listas e imagens acessíveis para um leitor de tela. As tabelas podem ser mais complicadas de implementar.

Os tipos de estrutura do PDF estão listados na seção 14.8.4.3. do
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Para um título, a renderização mudaria a partir deste:

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

para isso:

<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>

Isso seria lido por um leitor de tela como "7. Avaliação, título nível 1" e, mais importante, permite que o usuário pule entre os títulos usando a tecla 'próximo título' (o que torna documentos grandes muito mais fáceis de navegar)

Notei que o rótulo 4-tagged-pdf foi removido. Isso ainda é algo que está sendo perseguido?

O problema em aberto indica que estamos considerando isso. Este é um recurso e os rótulos foram um pouco reordenados.

Wow isso é ótimo! Este recurso que está sendo considerado inclui suporte para geração de PDFs marcados? Isso poderia facilitar a implementação de algo como um analisador / analisador para PDFs existentes, mas também forneceria suporte para gerar PDFs 508c.

Funcionalidade central necessária para gerar PDFs 508c:

• marcar o documento (com um idioma e um título, possivelmente outras marcas)
• marque os objetos estruturais dentro do PDF (cabeçalho, tabela, th, td, listas, etc.)
• adicionar texto alternativo à mídia visual (imagens, vídeo, figuras, etc.)
• criar / manter uma ordem de tabulação de elementos

Se a funcionalidade principal existisse para essas 4 coisas, seria possível implementar a lógica no processo de geração de PDF que produziria PDFs 508c. O que, para ser honesto, seria enorme, já que ainda não encontrei nenhuma ferramenta javascript OpenSource compatível com essa funcionalidade.

Depois de escrever isso, não tenho certeza se isso se qualificaria como uma solicitação de recurso separada ou não ... Eu ficaria feliz em criar um novo problema se for esse o caso.

Tenho trabalhado com @cuhaller para fornecer melhor conformidade com SC 2.4.10 e 1.1.1 das WCAG 2.0 para casos de uso específicos para o aplicativo em que sua equipe está trabalhando.

Acredito que as mudanças devem ser suficientes para um subconjunto do que esse problema está exigindo que seja feito. Terei um PR na próxima semana ou assim, seguindo as diretrizes de contribuição . Vou atualizar este tópico quando enviar.

Eu tenho alterações em um fork de 2.3.200 de PDF.js para fornecer níveis de título e texto de imagem alternativo (sem posicionamento) localizado no branch headings -and-img-alt-text deste repositório .

Hesito em abrir um PR, pois há conflitos de mesclagem contra o master e atualmente não tenho tempo para resolvê-los.

Se alguém tiver disponibilidade para atualizar esse branch com o master vamos entrar em contato!

O Edge elogiou o suporte nativo para PDFs marcados. O Chrome agora também oferece suporte e também elogiou sua capacidade futura de exportar PDFs marcados de páginas da web.

Hoje, o Firefox não expõe a marcação em PDFs para a árvore de acessibilidade / APIs de acessibilidade. No entanto, este texto está na lista de recursos do Firefox 80 :

O Firefox agora pode ser definido como o visualizador de PDF do sistema padrão.

Se um usuário que confia no AT fizer isso, ou um administrador de sistema que não conhece a composição dos usuários fizer isso, pode ser problemático para os usuários que confiam no Edge, Chrome ou Adobe's Reader analisar PDFs marcados para eles .

Eu sugiro fortemente que o conselho seja retirado das notas de lançamento do 80, e que a prioridade do bug seja aumentada. Eu entendo que o Mozilla tem recursos limitados agora, mas a ótica de promover um recurso inacessível que é melhor servido em navegadores concorrentes não é uma boa aparência.

Nossa organização está procurando implementar uma solução PDF acessível para usuários de tecnologias assistivas. Chegamos à conclusão de que a visualização de um PDF com PDF JS não é acessível, pois a marcação semântica está ausente. A falta de informações semânticas cria barreiras para os usuários que interagem com o software leitor de tela. Embora o PDF seja exibido em texto simples e anuncie anotações, a marcação não é fornecida para títulos, tabelas, imagens ou links.

O caso de uso em torno das tabelas é particularmente difícil para usuários de leitores de tela. As tabelas sem marcação semântica não fornecem contexto para os usuários e impossibilitam os usuários de leitores de tela de compreender totalmente as informações apresentadas no PDF.

Os links são anunciados como URLs em vez do texto específico do link, o que dificulta a compreensão do propósito do link. Recomendamos que os links usem o texto do link visível em vez do URL do link, para que os usuários entendam o link no contexto.

Sem esse suporte, temos preocupações sobre a implementação ampla do PDF JS. Existe alguma atualização ou cronograma em torno do suporte a um recurso para fornecer marcação semântica? Pedimos que esse problema seja considerado de maior prioridade, pois afeta a capacidade dos usuários de perceber e interagir com o conteúdo.

Pelo que eu sei, contribuições são mais que bem-vindas

Obrigado @trjohnst por seu trabalho nisso.

Comecei a rebasear manualmente o branch de @trjohnst no pdf.js master. Essa abordagem funciona bem para tags que precisam apenas de um único nível; por exemplo, títulos ou imagens com texto alternativo. Ao percorrer o fluxo de conteúdo, se encontrar uma sequência de conteúdo marcada, ele procura o elemento de estrutura associado e coloca a função ARIA apropriada na extensão de texto na saída HTML pela camada de texto pdf.js.

Infelizmente, isso não é suficiente para nada que precise de tags aninhadas; por exemplo, listas ou tabelas. Não acho que a abordagem pode ser estendida para cobrir esses, pelo menos não sem muitos casos extremos complicados. Além disso, para oferecer suporte adequado a links e campos de formulário (e observe que os campos de formulário não eram suportados pelo pdf.js no momento da contribuição de

Em vez de tentar fazer isso na camada de texto, acho que precisaremos percorrer a árvore da estrutura e renderizar os nós com base nisso, definindo propriedades ARIA nos elementos que geramos. A árvore de estrutura pode fazer referência a dados nas camadas de texto e de anotação. Podemos reordenar o texto e os nós DOM da camada de anotação com base na árvore de estrutura (pode ser complicado sem quebrar a renderização visual?) Ou usar aria-owns para reordenar apenas a árvore a11y sem reordenar o DOM.

Arquitetonicamente, isso é complicado porque as camadas de texto e anotação já foram renderizadas separadamente, e agora precisamos olhar para uma terceira camada (ou pelo menos a fonte da verdade), a árvore de estrutura, que pode mover (ou fazer referência) nós em ambos as outras camadas. A maneira mais simples de fazer isso é provavelmente anexar um id a cada sequência de conteúdo marcado (na camada de texto) e campo de link / formulário (na camada de anotação). Vejo que os campos do formulário já têm um atributo de dados especificando um id. Se vamos usar aria-owns, precisamos definir o atributo id de qualquer maneira, então isso pode alimentar dois pássaros com um bolinho. O id precisa ser algo que possamos calcular de fora das camadas de texto e anotação, de dentro de nossa nova camada de estrutura. Quando estamos lidando com a árvore de estrutura, nós produzimos elementos para os elementos de estrutura, movendo / possuindo elementos das camadas de texto / anotação com base em seus ids.

Indo além do PDF marcado para heurísticas, precisaríamos ser capazes de fazer coisas como: dado um link ou uma anotação de campo de formulário, seu retângulo abrange algo na camada de texto? em caso afirmativo, a anotação deve ser associada ao seu texto (aria-owns ou DOM move). Novamente, isso é arquitetonicamente complicado porque as camadas de texto e anotação (e suas entradas) são separadas e não acho que tenhamos nenhum estado em cache dessas camadas que possamos usar. No entanto, podemos potencialmente olhar para os limites dos nós renderizados pelas camadas de texto e anotação, embora isso comece a confundir os limites arquitetônicos entre o conteúdo e o processamento da apresentação.

Embora uma implementação inicial de PDF marcado não precise necessariamente oferecer suporte a heurísticas, eu recomendo fortemente que isso seja considerado como parte do projeto de arquitetura. A realidade é que PDFs não marcados infelizmente são muito comuns e seria triste estar preso a uma arquitetura que não permite que eles sejam mais acessíveis. (Observe que o Acrobat Reader e, em muito menor grau, o Chromium, usam heurísticas para tentar tornar os PDFs não marcados mais acessíveis.)