> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/mais-topicos/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Uma introdução aos ficheiros PDF etiquetados: estruturas internas e os desafios da acessibilidade ## Atualização: janeiro de 2026 Consulte [as instruções do Overleaf sobre a criação de PDFs etiquetados](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). O [A equipa do LaTeX](https://latex-project.org/) lançou novas funcionalidades que permitem a etiquetagem automática de PDF, o requisito central para a acessibilidade de PDF. Estas novas funcionalidades estão disponíveis no Overleaf em [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), com atualizações mais recentes disponíveis na versão contínua do TeX Live disponível através de [Overleaf Labs](https://www.overleaf.com/labs/participate). Agora é possível produzir um PDF etiquetado a partir de código-fonte LaTeX em conformidade com o nível AA das WCAG 2.1 seguindo [a nossa documentação de utilizador](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) usando as versões do TeX Live disponíveis no Overleaf. O artigo abaixo, de 2020, embora não esteja atualizado com as informações mais recentes sobre a acessibilidade no LaTeX, pode continuar a ser lido por interesse e para informação de enquadramento sobre a etiquetagem de PDF. *** ## O que abrange este artigo? O objetivo deste artigo é fornecer uma introdução ao PDF etiquetado, juntamente com uma visão geral de alguns desafios técnicos enfrentados por software, incluindo motores TeX e LaTeX, que visam produzir ficheiros PDF etiquetados e acessíveis. A acessibilidade, em particular dos PDFs, é um tema amplo e complexo, que também apresenta desafios técnicos que nem sempre têm uma única solução universalmente aceite ou acordada — como representar matemática complexa em PDF de uma forma acessível: usando MathML ou código LaTeX? Embora não possamos aprofundar-nos em todos os tópicos e tenhamos de simplificar muitos pormenores, podemos espreitar o interior dos PDFs para mostrar o que a etiquetagem de um PDF realmente envolve. O Overleaf espera que este artigo sirva como uma introdução útil, fornecendo contexto suficiente para permitir aos leitores compreender melhor os desafios técnicos e apoiar a sua leitura e exploração adicionais de PDF etiquetado e acessibilidade. Os recursos deste artigo incluem: * [um vídeo de 8 minutos](#video-showing-the-logical-structure-of-a-tagged-pdf) explorando um PDF etiquetado produzido pelo LaTeX; * [um projeto Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) para explorar a utilização de caracteres de espaço no LuaTeX; * [gravações sonoras](#tagged-yes-but-the-reading-order-is-incorrect) demonstrando problemas de acessibilidade em PDF. ## Introdução Garantir a acessibilidade do conteúdo digital é, com razão, reconhecido como um aspeto importante da produção e divulgação de conteúdo. Além disso, governos, incluindo o [Reino Unido](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) e [Estados Unidos](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), estão a aprovar leis que exigem que o conteúdo produzido sob a sua jurisdição cumpra critérios de acessibilidade definidos. O cumprimento através da divulgação de conteúdo em HTML não é indevidamente oneroso, mas garantir o nível de acessibilidade necessário para documentos distribuídos em formato PDF pode ser um desafio técnico significativo — dependendo do software usado para criar conteúdo destinado a ser emitido como um ficheiro PDF. O PDF surgiu no início da década de 1990 como solução para problemas relacionados com a transferência fiável de documentos e a história mostrou que foi um êxito estrondoso. No entanto, o PDF é também um formato de ficheiro complexo que surgiu antes do amplo reconhecimento e aceitação da necessidade de facilitar a acessibilidade do conteúdo dos documentos. Ainda assim, ao longo do tempo, a especificação do PDF evoluiu para fornecer funcionalidades que permitem e apoiam a produção de documentos PDF acessíveis usando uma variante “estilizada” de PDF que a Adobe chama *PDF etiquetado*. Na prática, a produção de PDFs etiquetados —*e totalmente acessíveis*— impõe requisitos técnicos adicionais significativos ao software que gera PDF — e isso inclui motores TeX e o ecossistema LaTeX de macros e pacotes LaTeX adicionais. ## Génese do PDF como papel digital de forma final O [a génese do Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) remonta a uma época em que a transferência de documentos entre computadores estava repleta de dificuldades, muitas vezes causadas por conversões de ficheiros que resultavam em reflow das páginas e outras discrepâncias, agravadas por fontes e codificações de texto incompatíveis usadas em diferentes sistemas operativos (nomeadamente Windows e Macintosh). O autor deste documento trabalhava na área da edição nessa altura e tem memórias vívidas de lidar com esses desafios! O PDF foi concebido para resolver problemas de partilha de ficheiros através da introdução de um papel digital universal, de forma final (não editável), permitindo a transferência sem falhas de documentos autónomos que continham os tipos de letra necessários para os exibir. Os utilizadores podiam finalmente transferir todo o tipo de documentos com uma certeza razoável de que os destinatários, independentemente da plataforma informática, os podiam abrir e ler — a fidelidade do documento era preservada e os incómodos reflows de página e a compatibilidade/disponibilidade de tipos de letra eram coisa do passado. ### Papel digital: bom para todos os utilizadores? A ascendência do PDF, como forma de papel digital, assumia naturalmente o uso de números de página impressos, tipografia ou elementos de design como pistas para a navegação visual do seu conteúdo — no ecrã ou em papel. No entanto, essas pistas/mecanismos visuais são, naturalmente, irrelevantes para pessoas com deficiência visual grave. Hoje, a melhoria da acessibilidade do conteúdo digital é, com razão, reconhecida como um aspeto importante da produção e divulgação de conteúdo. O desafio para o PDF foi fornecer mecanismos que facilitem o acesso não visual ao conteúdo encerrado num “contentor” originalmente concebido para replicar o meio visual da página impressa. A primeira versão da especificação PDF (PDF 1.0) foi [lançada oficialmente em 15 de junho de 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) seguida por novas versões com atualizações que, em 2001 (PDF 1.4), incluíram a introdução do “PDF etiquetado”, que [“...permitiu aos utilizadores de tecnologias de apoio”](https://www.adobe.com/accessibility/pdf.html). As versões subsequentes da especificação PDF alargaram e melhoraram as funcionalidades do PDF, culminando na versão mais recente (PDF 2.0) que, com base em [relatórios](https://www.pdfa.org/tagged-pdf-2-0/), reformulou significativamente as funcionalidades de acessibilidade — embora o PDF 2.0 ainda não seja bem suportado pelos motores TeX. ## Conteúdo dentro de PDFs Para compreender os problemas envolvidos, vale a pena examinar como os ficheiros PDF representam efetivamente o conteúdo das páginas que contêm. No interior de um ficheiro PDF, o conteúdo de cada página reside no *fluxo de conteúdo*: uma sequência de operadores PDF (“comandos”) que colocam texto ou gráficos num local específico da página para renderização (apresentação) pelo software utilizado para *ver* o PDF. Na prática, o fluxo de conteúdo fornece uma descrição gráfica ou “receita” que diz às aplicações de visualização de PDF como “desenhar” cada página — definindo o que deve ser exibido na página e onde. Naturalmente, essa série de operadores inclui instruções para escolher tipos de letra específicos num tamanho determinado, selecionar cores, definir larguras de linha, desenhar linhas, curvas e assim por diante — tudo o que é necessário para fornecer uma descrição gráfica completa para a apresentação visual de uma página. Para reduzir o tamanho do ficheiro, os fluxos de conteúdo PDF são comprimidos e armazenados num formato binário compacto, mas, se tiver acesso a software adequado, como o Adobe Acrobat Pro DC, pode usá-lo para ver uma versão em texto simples “descomprimida” dos fluxos de conteúdo das páginas. Vamos considerar como os operadores PDF poderiam “desenhar” uma tabela: o fluxo de conteúdo PDF conteria uma sequência apropriada de operadores para produzir linhas horizontais/verticais, selecionar diferentes tipos de letra e apresentar texto colocado em várias localizações da página para produzir o conteúdo da tabela. Para demonstrar isto, consideremos um documento PDF muito simples, sem etiquetas, contendo apenas uma tabela básica com algum texto — criado no Microsoft Word por razões que se tornarão evidentes mais à frente no artigo. Aqui está uma captura de ecrã que mostra o nosso PDF simples: ![Uma tabela criada no Microsoft Word](/files/5b2f860d1afe46df81bd9bb2709643e3763a951c) Se extraímos o fluxo de conteúdo da página (descomprimido) para este ficheiro e colarmos as primeiras linhas num editor de texto, podemos resumir alguns dos operadores PDF para obter uma “ideia” de como os ficheiros PDF “descrevem” o conteúdo exibido nesta página. ![Imagem do fluxo de conteúdo num ficheiro PDF](/files/a81bdc183f279ed6314f556375af476d2b06cfbb) Se tiver acesso ao Adobe Acrobat Pro DC, pode usá-lo para listar os operadores contidos num fluxo de conteúdo de uma página PDF. Aqui está a vista de *estrutura interna do PDF* do mesmo PDF no Acrobat, que fornece uma descrição útil de uma linha de cada operador usado para “desenhar” a nossa única página contendo uma tabela básica — note que estas breves descrições são fornecidas pelo Adobe Acrobat Pro DC, não *contém* estão presentes no próprio ficheiro PDF: ![Imagem de um fluxo de conteúdo PDF visto no Adobe Acrobat Pro DC](/files/7cb2a6abec4de51e8d3b67c4e47174a4d74e7086) No entanto, observe que nenhuma dessas instruções de desenho (operadores) armazena qualquer “significado” ou “descrição” do que está efetivamente a produzir: são apenas um conjunto de operadores gráficos que resultam na construção do que um *observador com visão reconhece* como uma tabela. Claramente, para quem tem deficiência visual grave, apresentar a tabela que resulta desses operadores gráficos no fluxo de conteúdo do PDF não é um método viável para aceder a esse conteúdo. O que é necessário é um mecanismo para que os ficheiros PDF contenham uma descrição não visual adequada (legível por máquina) dessa tabela — e, claro, de todos os outros itens de conteúdo contidos nas páginas dentro de um ficheiro PDF. Para permitir o acesso não visual ao conteúdo, os ficheiros PDF precisam de conter dados adicionais que atribuam “significado” ou semântica a coleções ou grupos de operadores que estão a ser usados para “desenhar” uma determinada peça de conteúdo. Necessariamente, este princípio de atribuir ou fornecer “significado” tem de ser alargado a todas as formas de conteúdo contidas num PDF: esse mecanismo existe e chama-se *etiquetagem* o PDF para produzir uma “variante” de PDF chamada, sem surpresa, *PDF etiquetado*. ## Introdução ao PDF etiquetado PDF etiquetado é o nome dado a um tipo específico de ficheiro PDF que contém dados adicionais (e estruturas de dados) não presentes em ficheiros PDF sem etiquetas. Embora os princípios/ideias por trás do PDF etiquetado sejam adequados a uma descrição resumida, os detalhes completos são complexos e ocupam muitas páginas na especificação formal do PDF. A Adobe concebeu o PDF etiquetado para atingir vários objetivos, que incluíam tornar o conteúdo acessível a utilizadores com deficiências visuais, mas também abrange a seguinte lista retirada da Secção 10.7 da [especificação PDF 1.7 da Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * extração simples de texto e gráficos para colagem noutras aplicações; * refluxo automático de texto e gráficos associados para se ajustarem a uma página de tamanho diferente daquele assumido para a disposição original; * processamento de texto para fins como pesquisa, indexação e verificação ortográfica; * conversão para outros formatos de ficheiro comuns (como HTML, XML e RTF), preservando a estrutura do documento e informações básicas de estilo. Além disso, o PDF etiquetado também requer: * que o texto no conteúdo PDF seja representado de uma forma que possa ser convertida para Unicode; * as separações de palavras devem ser representadas explicitamente — note que os motores TeX não usam caracteres de espaço para separar palavras, usam o espaçamento flexível do TeX chamado glue (ver abaixo); * o conteúdo real (“verdadeiro”) é distinguido de artefactos de disposição e paginação. O PDF etiquetado assenta em dois conceitos-chave que iremos analisar: * definição da estrutura lógica do conteúdo num ficheiro PDF; * marcação (etiquetagem) do conteúdo PDF com um conjunto de tipos de conteúdo padrão. ## Estrutura lógica Em documentos mais longos, o conteúdo é normalmente repartido por uma sequência de itens de conteúdo mais pequenos; por exemplo, os livros são tipicamente divididos em capítulos que, por sua vez, são divididos em secções e subsecções contendo parágrafos, tabelas, figuras/gráficos, listas com marcadores ou numeradas, notas de rodapé e referências, e assim por diante. A estrutura e organização do conteúdo num livro desse tipo, ou em qualquer outro tipo de documento, é designada por *estrutura lógica*. A noção da estrutura lógica de um documento desempenha um papel importante na acessibilidade dos PDFs, mas, como conceito, a estrutura lógica pode parecer um pouco vaga e difícil de entender. A seguinte definição da [Enciclopédia de Sistemas de Bases de Dados](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) fornece uma visão útil: > “A estrutura lógica refere-se à forma como a informação num documento é organizada; define a hierarquia da informação e a relação entre as diferentes partes do documento. A estrutura lógica indica como um documento é construído, em vez do que um documento contém.” Note que esta definição de estrutura lógica não faz referência a precisamente *como* onde a informação estrutural é armazenada fisicamente; apenas que fornece uma representação da estrutura e organização de um documento. Os detalhes precisos de como a estrutura lógica de um documento é armazenada ou representada dependem da implementação: são uma função do software usado para a gerar e processar. ### Estrutura lógica em PDFs A especificação PDF fornece mecanismos através dos quais a estrutura lógica de um documento pode ser registada dentro de um ficheiro PDF — para uso por software que, por exemplo, possa querer exportar o conteúdo do PDF para outros formatos como XML, HTML ou Microsoft Word. Esses processos de exportação precisam de produzir um documento de texto corretamente estruturado que esteja em conformidade com as regras do formato de ficheiro de exportação de destino — algo que pode ser melhor conseguido quando o processamento de exportação é guiado pela informação da estrutura lógica fornecida no PDF. Além disso, a estrutura lógica de um ficheiro PDF é essencial para software de acessibilidade que, por exemplo, possa querer realizar operações de texto para fala, lendo o conteúdo em voz alta para alguém com deficiência visual. O processo de texto para fala precisa de garantir que o conteúdo seja lido em voz alta na ordem/sequência correta; caso contrário, produziria resultados sem sentido. Note também que o próprio conceito de uma página pode não fazer sentido para aplicações de acessibilidade que apenas se interessam pelo conteúdo e pela estrutura do documento em PDF, e não pela divisão visual e apresentação em blocos do tamanho de uma página. #### Nomear itens de conteúdo Registar (armazenar) a estrutura lógica de um documento PDF requer um conjunto de nomes significativos atribuídos aos vários *tipos* de item de conteúdo que provavelmente serão encontrados num documento PDF típico — identificando secções de conteúdo que representam títulos, parágrafos, tabelas, listas e assim por diante. Além disso, alguns itens de conteúdo, como índices, listas numeradas/com marcadores e material tabular, têm estruturas próprias bastante complexas, pelo que também é necessário algum tipo de orientação/regras para especificar como esses itens de conteúdo mais complexos são construídos — a sua subestrutura. Um requisito adicional é identificar claramente qualquer conteúdo PDF que deva ser ignorado pelo software de apoio que processa o PDF; por exemplo, cabeçalhos e rodapés de página são artefactos de paginação contendo texto supérfluo para pessoas com deficiência visual grave: esse conteúdo deve ser ignorado. Os mecanismos usados pelo PDF para definir a estrutura lógica de um documento foram concebidos para serem flexíveis, por isso, em princípio, diferentes aplicações que geram e processam ficheiros PDF poderiam usar nomes para tipos de conteúdo segundo qualquer convenção à sua escolha. No entanto, para maximizar a interoperabilidade de documentos, permitindo que diferentes aplicações de processamento de PDF produzam resultados consistentes, a Adobe definiu um conjunto de nomes padrão para tipos de itens de conteúdo que o software de geração de PDF deve seguir. Na especificação PDF, esses nomes padrão são referidos como etiquetas, dando origem à noção de *etiquetado* PDF. ### Marcação do conteúdo PDF: um olhar “por baixo do capô” Para tornar a discussão um pouco menos abstrata, faremos uma breve análise do interior dos ficheiros PDF etiquetados — embora não possamos cobrir todos os detalhes porque o PDF etiquetado é um tema tão vasto e complexo. #### Sequências de conteúdo marcado: blocos de construção para PDF etiquetado Ao nível mais baixo, o processo de registar o significado do conteúdo contido numa página PDF (ou seja, no seu fluxo de conteúdo) começa com *sequências de conteúdo marcado* que são usadas para identificar (dar “significado” a) grupos ou conjuntos de operadores PDF. Às sequências de conteúdo marcado é atribuído um identificador numérico chamado `MCID` (*identificador de conteúdo marcado*) que é um inteiro que varia de 0 até um máximo N em cada página. Esses `MCID` valores fornecem uma forma de identificar de forma única sequências de operadores contidas no fluxo de conteúdo de uma página específica. Para clarificar, em cada página os `MCID` identificadores começam em 0 e aumentam sequencialmente até um valor máximo que depende de quantas sequências de conteúdo marcado estão contidas no fluxo de conteúdo de uma determinada página. As sequências de conteúdo marcado são, na prática, “blocos de construção” fundamentais que são usados para montar estruturas de dados de nível superior chamadas *elementos de estrutura*. Esses elementos de estrutura contêm uma etiqueta, que é o nome usado para identificar que tipo de item de conteúdo representam. #### Exemplo de elementos de estrutura Aqui estamos a adiantar-nos um pouco, mas vale a pena rever um exemplo. Suponha que tem 3 pequenos fragmentos de texto do conteúdo da página e cada um é identificado no fluxo de conteúdo por uma sequência de conteúdo marcado diferente. Cada um desses 3 fragmentos de texto pode ser embalado no seu próprio elemento de estrutura, com uma etiqueta, e os três podem ser “ligados” entre si usando outro elemento de estrutura para representar um item de conteúdo de nível superior, como uma linha num índice. ![Imagem que explica elementos de estrutura e sequências de conteúdo marcado](/files/acd649cc1d97c7d62b0bb310a1d3abc9af06545f) Através de uma forma de relação de dados pai–filho, coleções de elementos de estrutura são combinadas para criar estruturas de dados ligadas que representam itens de dados mais complexos, como listas numeradas e com marcadores, tabelas, matemática e assim por diante. Em última análise, toda a coleção de elementos de estrutura contida no ficheiro PDF é posteriormente interligada e combinada para criar a estrutura lógica do documento PDF — voltaremos a isto mais à frente no artigo. ### O que é uma sequência de conteúdo marcado? Na discussão acima, usámos um documento PDF simples sem etiquetas contendo uma tabela (criada no Microsoft Word), mas se instruirmos o Word a criar um PDF etiquetado podemos ver que surgiu alguma marcação adicional no fluxo de conteúdo da página. Aqui, estamos apenas a considerar as primeiras linhas do fluxo de conteúdo (há centenas de linhas), mas observe a presença de operadores adicionais como `/P <> BDC` e `EMC` que são usados para identificar uma sequência de conteúdo marcado. Não iremos explorar a sintaxe completa das sequências de conteúdo marcado, mas remetemos o leitor para a página 862 da [especificação oficial PDF 1.7 da Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Imagem que mostra sequências de conteúdo marcado num fluxo de conteúdo de PDF etiquetado](/files/86c76b70f407734f146ae4e506cbce6b91db977d) Para fácil referência, mostramos novamente a versão sem etiquetas: ![Imagem que mostra o fluxo de conteúdo PDF](/files/a81bdc183f279ed6314f556375af476d2b06cfbb) No *sem etiquetas* PDF, operadores como `/P <> BDC` e `EMC` estão ausentes, mas os operadores restantes não se alteraram: o PDF sem etiquetas não tem a marcação adicional usada para identificar determinadas sequências/conjuntos de operadores. Mais uma vez, também podemos usar a funcionalidade *estrutura interna do PDF* do Adobe Acrobat para ver as sequências de conteúdo marcado dentro de um fluxo de conteúdo — aqui, destacámo-las usando um contorno verde: ![Imagem que mostra sequências de conteúdo marcado num fluxo de conteúdo de PDF etiquetado visualizado no Adobe Acrobat Pro DC](/files/a78b79b4f57989921dac537931a9efec78bec606) Note que algumas partes do conteúdo estão marcadas como `/Artifact` que identifica material na página PDF que deve ser *ignorado* pelas aplicações de software de apoio, tais como as que leem em voz alta para pessoas com deficiência visual. A captura de ecrã seguinte mostra uma vista expandida da primeira sequência de conteúdo marcado — a que tem `MCID` valor de `0`. O fim da sequência de conteúdo marcado é identificado pelo operador PDF `EMC`. ![Imagem que mostra detalhes dos operadores abrangidos por um fluxo de conteúdo marcado](/files/6c7216d9c30042d18587738f610bdb62e24bb88b) ### Armazenar a estrutura lógica Como já referido, para além de fornecer uma descrição de itens de conteúdo individuais (parágrafos, listas, tabelas, etc.), é necessário que os PDFs acessíveis contenham uma representação de todo o documento sob a forma da sua estrutura lógica. As peças individuais de conteúdo acessível devem ser ligadas entre si para criar um documento completo, navegável e acessível — semelhante à forma como um único documento HTML é construído a partir de parágrafos, gráficos e tabelas para criar uma página web. Além disso, é essencial que a estrutura lógica de um documento PDF garanta que todo o conteúdo possa ser navegado na *ordem de leitura*correta, independentemente da ordem em que o conteúdo da página foi escrito nos fluxos de conteúdo da página PDF. Exploraremos a ordem de leitura com mais detalhe abaixo. #### Estrutura lógica: uma “árvore” de elementos de estrutura Referimos que os PDFs usam algo chamado *elemento de estrutura* para representar itens de conteúdo individuais, e que um elemento de estrutura contém uma etiqueta para identificar que tipo de conteúdo representa. Para fornecer uma representação da estrutura lógica do documento, todos os elementos de estrutura são ligados entre si, usando relações pai—filho, e organizados numa “árvore de estrutura”. Internamente, os ficheiros PDF etiquetados contêm um objeto chamado `StructTreeRoot` que contém (aponta para) elementos de estrutura que atuam como o ponto de partida ou “raiz” da árvore da estrutura lógica do documento. Normalmente, a “raiz” da árvore de estrutura começa com um único elemento de estrutura etiquetado como `Document` que contém numerosos elementos de estrutura *filho* que, em conjunto, representam todo o conteúdo do documento. Qualquer software concebido para produzir PDFs acessíveis através de etiquetagem tem de construir esta estrutura de dados muito complexa (e outras!) — e isso inclui motores TeX e o LaTeX. Um exemplo dessa árvore de estrutura do documento (`StructTreeRoot`) é apresentado na seguinte captura de ecrã de um PDF etiquetado aberto no Adobe Acrobat Pro DC: ![Imagem que mostra o StructTreeRoot num PDF etiquetado](/files/0217f9523a9fa6cbabbb8f05b0fc74a053547080) Compare a estrutura acima com a versão sem etiquetas do PDF: ![Imagem que mostra a ausência de StructTreeRoot num PDF sem etiquetas](/files/89781fca9789ca5aafae6bdc86a459d5702c28fe) ### Explorar a estrutura lógica dos PDFs Começamos com alguns gráficos para resumir o que cobrimos e concluímos com um vídeo que usa o Adobe Acrobat Pro DC para mostrar mais detalhes da estrutura lógica de um ficheiro PDF etiquetado. Primeiro, começamos com um esquema para mostrar os princípios gerais: uma página PDF com o seu fluxo de conteúdo marcado com sequências de conteúdo marcado (MCS). ![Gráfico para mostrar o conceito de sequências de conteúdo marcado em páginas de documentos PDF](/files/5808d796edd6c3e20e66216ee64564e2e74fffb7) Essas MCS são subsequentemente combinadas em *elementos de estrutura* que formam a base para tipos de conteúdo maiores, que por sua vez são posteriormente ligados entre si para armazenar a estrutura lógica do PDF dentro de um objeto chamado `StructTreeRoot`. ![Gráfico para mostrar a estrutura lógica de um ficheiro PDF etiquetado](/files/5c7f953603040c534c3a13b5ff8ddb125c3954b6) #### Vídeo que mostra a estrutura lógica de um PDF etiquetado O vídeo seguinte (8 minutos) usa o Adobe Acrobat Pro DC para o levar numa “visita guiada” e explorar pormenores da estrutura lógica de um ficheiro PDF etiquetado produzido com LaTeX. O ficheiro PDF etiquetado usado no vídeo chama-se `tagpdf.pdf`, que é um excelente exemplo contendo documentação para o pacote experimental do LaTeX [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). O objetivo do `tagpdf` pacote é fornecer “ferramentas para experimentar a etiquetagem e acessibilidade usando pdfLaTeX e LuaTeX”. {% embed url="" %} ### Uma nota sobre etiquetagem e flexibilidade A especificação HTML fornece um grande número de etiquetas predefinidas para usar na construção de páginas web, mas também permite flexibilidade na forma como as combina para criar o documento HTML escolhido. De modo semelhante, a especificação PDF etiquetado da Adobe fornece um conjunto de nomes de etiquetas predefinidos, mas impõe muito poucas restrições sobre a forma como combina essas etiquetas para representar itens de conteúdo complexos num PDF — por design, existe um grande grau de flexibilidade. Além disso, com qualquer especificação tão grande e complexa como o PDF, é inevitável que algumas ambiguidades ou problemas de clareza se infiltrem na especificação escrita. Os programadores de software encarregados de implementar uma especificação tão complexa podem ter de fazer “juízos de valor” ao interpretá-la, porque se deparam com a necessidade de converter descrições escritas em código funcional. A flexibilidade inerente ao PDF etiquetado, juntamente com a interpretação de especificações (ou normas de acessibilidade), afeta naturalmente os programadores de aplicações de criação de documentos: que combinações de etiquetas devem ser usadas para representar o conteúdo criado pelo utilizador quando este é exportado para um ficheiro PDF etiquetado? Se juntar a isto a capacidade ilimitada dos utilizadores para construir todo o tipo de conteúdo utilizando as funcionalidades do software de criação de documentos, então percebe-se que a produção automática de PDFs etiquetados acessíveis é um verdadeiro desafio! Talvez refletindo as complexidades inevitáveis da produção de PDFs etiquetados que cumprem integralmente as normas de acessibilidade, a web está repleta de “como fazer”, “dicas” e conselhos de “boas práticas” sobre a criação de PDFs etiquetados através de software como o Adobe InDesign ou o Microsoft Word. Além disso, a PDF Association produziu um documento útil chamado [Guia de Boas Práticas para PDF Etiquetado](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) escrito para ajudar programadores que enfrentam os desafios de implementar PDF etiquetado e PDF/UA. ## Tem um PDF, mas será acessível? Para determinar se um determinado ficheiro PDF cumpre normas de acessibilidade exigidas, como PDF/A ou PDF/UA (ver abaixo), tem de ser *validado* usando um processo de validação ou ferramenta de software acordados. No entanto, a validação geralmente ocorre depois de o documento estar concluído, mas esse processo pode não ser realizado pelo autor do documento, e sim por especialistas em acessibilidade dentro da organização ou entidade que solicitou a conformidade. Se o PDF falhar na validação, pode ser necessária intervenção manual especializada através do Adobe Acrobat Pro DC para corrigir a etiquetagem (se possível). Em alternativa, pode até ter de voltar ao autor para alterar o documento original, possivelmente evitando o uso das funcionalidades do software de criação que causaram os problemas — o que pode ser extremamente difícil de alcançar porque pode estar fora do controlo do autor. ### Ordem de leitura e ordem do conteúdo Como já referido, a produção de PDFs verdadeiramente acessíveis impõe requisitos técnicos adicionais ao software de criação e, potencialmente, também aos autores de documentos, ao impor “disciplina de autoria” na forma como usam/aplicam as funcionalidades do software de criação. Embora o PDF etiquetado seja o mecanismo que *permite* a produção de PDFs totalmente acessíveis, o facto de um PDF estar etiquetado não *contém* significa automaticamente que seja totalmente acessível, como veremos num exemplo abaixo. Para produzir PDFs totalmente acessíveis, todos os itens de conteúdo no PDF devem ser etiquetados para criar uma estrutura lógica que garanta que o conteúdo possa ser acedido e lido na sequência correta — chamada *ordem de leitura*ordem de leitura *ordem de leitura* aparente de: 1. texto 2. table 3. gráfico Ao ser escrito para um PDF, o software que gera um fluxo de conteúdo para essa página poderia começar com operadores para desenhar a tabela, depois emitir operadores para produzir o gráfico, seguidos de operadores para o texto, o que, no fluxo de conteúdo, produziria uma *ordem do conteúdo* aparente de: 1. table 2. gráfico 3. texto Naturalmente, tudo ficará colocado na posição correta quando essa página for visualizada. Para um leitor com visão completa, a ordem em que esses itens são armazenados dentro do fluxo de conteúdo da página não tem interesse: a pessoa vê uma página renderizada completa com tudo no local correto. No entanto, se o software de apoio tivesse de depender da ordem dos itens num fluxo de conteúdo (a ordem do conteúdo), enfrentaria dificuldades se a ordem do conteúdo fosse diferente da ordem natural de leitura; por exemplo, as ferramentas de leitura em voz alta leriam o material na sequência errada. Felizmente, o software de apoio pode usar a ordem lógica (estrutura) de um PDF etiquetado, que deve ser organizada para refletir a sequência em que o conteúdo deve ser lido. É por estas razões que os dados que representam a estrutura lógica do documento são armazenados separadamente do conteúdo real apresentado nas páginas visíveis, para permitir > “... que a ordenação e o encaixe dos elementos de conteúdo lógico sejam inteiramente independentes da ordem e da localização dos objetos gráficos nas páginas do documento.” (página 856 de [The PDF Reference, sexta edição, novembro de 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) Na prática, garantir uma ordem lógica que preserve a ordem de leitura é muito mais difícil do que pode parecer, por isso vamos usar um exemplo simples, embora inventado, que dá uma indicação dos problemas envolvidos. #### Ordem de leitura incorreta: um exemplo usando Microsoft Word O autor de um documento pode usar as funcionalidades do software de criação escolhido para obter um efeito visual específico — como usar tabelas para criar uma disposição textual particular. Por exemplo, a captura de ecrã seguinte mostra o documento do Microsoft Word usado nos exemplos anteriores. Contém uma tabela que foi usada para criar um conjunto de parágrafos numerados lado a lado. Mas quando se trata de etiquetar este conteúdo, como deve ser tratado: como tabela ou como lista numerada? Ambos esses tipos de conteúdo requerem uma estrutura de etiquetagem complexa para os representar corretamente. Na imagem seguinte, note a ordem em que os parágrafos numerados se destinam a ser lidos: coluna a coluna, e não linha a linha. ![Imagem de uma tabela criada no Microsoft Word](/files/4d1c5e7262ea0842bbf467c83df946e9ec79f8a8) Se pedirmos ao Word para guardar este documento num PDF usando a sua exportação integrada — e não o plugin Acrobat PDFMaker — podemos instruí-lo a criar um PDF etiquetado: ![Caixa de diálogo de opções do processo de exportação do Microsoft Word](/files/134b36a3d505a64acce52813f0434d7a50712bb2) Então, como é que o Word etiqueta este layout? No vídeo muito curto a seguir (14 segundos) usamos o Adobe Acrobat Pro DC para inspecionar a estrutura de etiquetagem produzida pelo Microsoft Word. {% embed url="" %} Para este documento, o Word criou um documento PDF etiquetado que usa uma `Table` etiqueta contendo duas subetiquetas: `THead` para o grupo da linha de cabeçalho da tabela e e `TBody` para representar o grupo de linhas do corpo da tabela. `THead` e `TBody` ambos contêm `TR` etiquetas para representar linhas individuais de conteúdo. As `TR` etiquetas contêm ainda outras etiquetas para representar o item de lista numerado presente em cada célula. A imagem de ecrã seguinte mostra a estrutura de etiquetagem profundamente aninhada e a estrutura lógica correspondentemente complexa necessária para representar até mesmo este documento extremamente básico! ![Imagem que mostra uma estrutura de etiquetagem profundamente aninhada e a estrutura lógica de uma tabela simples criada no Microsoft Word](/files/763db2956ad04e672ed15a1a911433ce505e11ad) Em comparação com os PDFs gerados por TeX e LaTeX, este exemplo do Word é um documento extremamente simples, mas ainda assim exige uma estrutura lógica complexa para o representar. Imagine o nível de complexidade de etiquetagem necessário para representar PDFs gerados por LaTeX contendo matemática complexa e tabelas! #### Etiquetado, sim, mas a ordem de leitura está incorreta Apesar de o Word produzir um [PDF etiquetado](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) isso demonstra um dos desafios fundamentais enfrentados por qualquer aplicação que tente produzir PDFs totalmente acessíveis: representar corretamente a ordem de leitura pretendida do conteúdo. Durante a criação do PDF etiquetado, os processos internos do Word decidiram escrever o correspondente fluxo de conteúdo apresentando a tabela linha a linha, e não coluna a coluna. Para um leitor com visão completa que veja o PDF, estes detalhes de baixo nível não fazem diferença: a tabela é apresentada corretamente. No entanto, para pessoas com deficiência visual, a estrutura lógica do documento do Word produz o resultado errado porque a ordem de leitura desejada (coluna a coluna) não é preservada: o conteúdo é lido em voz alta pela ordem errada. A gravação áudio seguinte foi produzida usando a funcionalidade “Read Out Loud” do Adobe Reader DC. Como é evidente, o texto é lido na sequência errada: linha a linha, e não coluna a coluna: ![Uma tabela criada no Microsoft Word](/files/fdb3eb01f24ce0659bbe32bd63b0006973fd7403) Como referido acima, este exemplo é algo artificial, mas demonstra o quão fácil é aplicar combinações de funcionalidades de software que desencadeiam problemas de acessibilidade — mas como é que o autor do documento poderia saber isso antecipadamente? É provável que este problema só fosse detetado se o PDF resultante fosse submetido a testes práticos de utilização em acessibilidade — por exemplo, usando software de apoio. Potencialmente, tais documentos poderiam passar nos testes de conformidade/validação PDF/A, mas falhar na utilização “no mundo real”. Garantir a ordem de leitura correta de um ficheiro PDF como este exigiria intervenção manual especializada usando ferramentas avançadas de edição de PDF, como o Adobe Acrobat Pro DC: um processo demorado e caro. Em alternativa, o autor do documento poderia abster-se de usar esta forma particular de expressão de conteúdo ou de layout — mas apenas se soubesse que era problemática! ### Usar caracteres de espaço para separar palavras Ao introduzir texto em processadores de texto ou editores de texto, usa o caractere de espaço para marcar o fim de uma palavra e o início da seguinte. Se posteriormente criar um PDF a partir desse documento, os caracteres de espaço que introduziu serão naturalmente incluídos na saída e farão parte do texto armazenado no PDF. No entanto, os motores TeX não usam caracteres de espaço para separar palavras em texto composto; em vez disso, convertem os caracteres de espaço numa forma de espaçamento flexível chamada glue (ver este [artigo do Overleaf](/latex/overleaf-learn-latex-pt/artigos-aprofundados/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) para mais informações sobre caixas TeX e glue). No fluxo de conteúdo das páginas PDF criadas por motores TeX, a separação entre palavras individuais é conseguida movendo-se para uma posição diferente na página e iniciando o texto da palavra seguinte — em vez de produzir um caractere de espaço para obter esse espaçamento. Além disso, a quantidade de espaço entre palavras em parágrafos de texto composto por motores TeX varia de linha para linha devido ao algoritmo de quebra de linha do TeX. Essa variação reflete-se nos dados posicionais escritos no fluxo de conteúdo das páginas PDF. Este aspeto da composição tipográfica do TeX tem implicações para copiar/colar texto a partir dos seus PDFs e para software de apoio que tenta ler em voz alta o texto composto em PDFs produzidos por motores TeX. O software de apoio tem de analisar o fluxo de conteúdo de uma página PDF para extrair o texto que precisa de processar. Claramente, esse software precisa de algum mecanismo para detetar o início e o fim das palavras — a solução mais óbvia é usar um caractere de espaço. Com isso em mente, as normas de acessibilidade exigem que as palavras individuais sejam claramente terminadas (por exemplo, por caracteres de espaço), o que é problemático para os motores TeX devido ao seu uso de glue entre palavras. #### Mas nem tudo está perdido! Em 2014, o pdfTeX introduziu 2 novos primitivos para melhorar o suporte de acessibilidade, permitindo o uso de caracteres de espaço entre palavras nos PDFs que produz: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Estes comandos fazem uso de uma “fonte fictícia” contendo apenas um glifo de espaço. Os detalhes e um exemplo podem ser encontrados na página 29 do [Manual do Utilizador do pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Usar LuaTeX: Um exemplo na Galeria Overleaf O LuaTeX não suporta esses primitivos do pdfTeX, mas pode ser programado para obter resultados muito semelhantes aos do pdfTeX usando o chamado mecanismo de callbacks do LuaTeX. Um projeto Overleaf para converter glue em caracteres de espaço está disponível na Galeria Overleaf sob o título [Usar LuaTeX para converter glue entre palavras em espaços e kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Se compuser o seu código LaTeX usando LuaTeX (ou seja, a opção de compilador LuaLaTeX no Overleaf), então, usando código Lua, pode pós-processar um parágrafo composto para encontrar qualquer glue entre palavras e substituí-lo por um caractere de espaço mais um kern apropriado. O espaçamento fornecido pela largura do caractere de espaço pode ser acrescentado (ou reduzido) calculando um valor de kern adequado para preservar a quantidade de espaço fornecida pelo glue entre palavras, resultando em nenhuma diferença visual no resultado composto. Para compreender a diferença que isto faz para os utilizadores de software de acessibilidade, ouça esta gravação sonora capturada da funcionalidade *Read Out Loud* do Adobe Reader DC. Regista as duas linhas de texto desse projeto a serem lidas em voz alta, antes e depois de converter glue em espaços. Repare como a segunda leitura da linha, que usa espaços, é lida em voz alta de forma rápida e fluida em comparação com a linha que usa glue entre palavras. O projeto Overleaf é um ficheiro TeX simples compilado com LuaTeX e fornecido apenas para uso experimental; não se destina a ser uma solução completa e de qualidade de produção. Principalmente, foi concebido para ajudar a compreender questões técnicas relacionadas com PDFs acessíveis. O código Lua usado nesse projeto baseia-se em trabalho contido num artigo Overleaf muito mais antigo [Caixas e Cola: Uma Introdução Breve, mas Visual, Usando LuaTeX](/latex/overleaf-learn-latex-pt/artigos-aprofundados/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Nota: por simplicidade, o projeto usa o seu próprio carregador de fontes OpenType muito minimalista derivado deste código: . ### Outros problemas de acessibilidade e PDF etiquetado Embora a etiquetagem permita identificar itens de conteúdo presentes num PDF, alguns tipos de conteúdo, como gráficos ou matemática complexa, requerem dados ou informação adicionais se quiserem ser tornados acessíveis através de software concebido para apoiar pessoas com deficiência visual. Para fornecer e suportar acessibilidade para uma vasta gama de tipos de conteúdo, a especificação PDF oferece a possibilidade de anexar “Descrições Alternativas” ou “ActualText” a itens de conteúdo, fornecendo descrições textuais adequadas ou outras representações legíveis por máquina. Por exemplo, o MathML foi designado para este fim na especificação PDF 2.0. #### É “conteúdo real” ou apenas um artefacto? Para pessoas com deficiência visual, o processo de particionar e apresentar conteúdo em blocos retangulares do tamanho de páginas tem efeitos secundários indesejados, como a hifenização de palavras. Além disso, aspetos do design ou layout da página usados para melhorar a apresentação visual são praticamente sem significado para quem não os consegue ver. Por estas razões, a etiquetagem de conteúdo PDF tem de reconhecer que algum conteúdo dentro de um PDF deve ser tratado como um *artefacto* de apresentação visual ou paginação. Por exemplo, números de página, cabeçalhos e rodapés, fundos sombreados ou outras indicações de design precisam de ser identificados para que o software de acessibilidade que processa o conteúdo saiba ignorá-los. ## Visão geral das normas PDF/A Os pedidos para produzir PDFs acessíveis geralmente fazem referência a uma norma ISO chamada [ISO 19005](https://www.iso.org/standard/38920.html), mais comumente referida como PDF/A. No entanto, como PDF/A é uma *família* de normas, pedir simplesmente “conformidade PDF/A” pode não especificar totalmente os requisitos reais. Para ver porquê, comecemos com um breve resumo de PDF/A a partir do [sítio da PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (acessado em 21 de maio de 2020), que descreve a ISO 19005 (PDF/A) da seguinte forma: > “O objetivo principal da ISO 19005 é definir um formato de ficheiro baseado em PDF, conhecido como PDF/A, que fornece um mecanismo para representar documentos eletrónicos de uma forma que preserve a sua aparência visual estática ao longo do tempo, independentemente das ferramentas e sistemas usados para criar, armazenar ou renderizar os ficheiros. > > Um objetivo secundário da ISO 19005 é definir uma estrutura para representar a estrutura lógica e outras informações semânticas de documentos eletrónicos em ficheiros conformes. > > Outro objetivo da ISO 19005 é fornecer uma estrutura para registar o contexto e o historial dos documentos eletrónicos em metadados dentro de ficheiros conformes.” Claramente, o PDF/A tem vários objetivos centrais. ### Evolução e crescimento do PDF O [especificação PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) foi publicada em 1993 e continha apenas 230 páginas. No entanto, 13 anos mais tarde a especificação para [a versão 1.7 do PDF da Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) supera largamente 1000 páginas! Ao longo do tempo, o tamanho e a complexidade da especificação PDF cresceram com a adição de funcionalidades suportadas: abrangendo novas tecnologias e os requisitos de fluxos de trabalho e casos de utilização baseados em PDF cada vez mais sofisticados em diferentes mercados e comunidades. No entanto, é provável que nenhum utilizador, ou conjunto de utilizadores, faça uso de todas as possibilidades: o PDF tem de “cobrir todos os cenários” para garantir que consegue servir as necessidades do mercado mais amplo possível. Por exemplo, muitas funcionalidades do PDF concebidas para suportar impressão comercial de alto nível não são necessárias para a utilização diária típica em escritório como formato para armazenar ou partilhar documentação. ### PDF/A: “regresso ao básico” para PDF O objetivo central do PDF/A é garantir que os PDFs conformes são adequados para arquivo a longo prazo ou contêm conteúdo acessível a pessoas que usam várias tecnologias de apoio para “consumir” esses PDFs. Para atingir estes objetivos, o PDF/A restringe o conjunto de funcionalidades PDF permitidas em ficheiros PDF conformes, proibindo o uso de funcionalidades que possam comprometer a capacidade de arquivo ou a acessibilidade. Pode pensar no PDF/A como um conjunto de normas que especifica como os ficheiros PDF conformes usam uma *subconjunto* da especificação PDF completa para produzir ficheiros adequados para arquivo a longo prazo ou para garantir que o seu conteúdo é acessível. As restrições do PDF/A permitem que os PDFs sejam usados como um “papel digital de arquivo” independente da tecnologia de leitura de PDF e do ambiente computacional usados para aceder ao seu conteúdo. Os PDFs conformes não devem conter nada cujo comportamento seja “dependente da implementação” — ou seja, dependa do software ou dos sistemas operativos específicos usados para os visualizar ou processar. Os PDFs também devem ser *completos*: os recursos documentais essenciais têm de estar incorporados no ficheiro — como fontes ou perfis de cor. ### Versões PDF/A e níveis de conformidade Existem diferentes *versões* da norma PDF/A, cada uma refletindo uma versão específica da especificação formal do PDF (PDF 1.4, 1.7 e 2.0). Além disso, existem vários *níveis de conformidade* que especificam a que aspeto(s) da norma PDF/A um ficheiro PDF está em conformidade. Consequentemente, ao reivindicar ou exigir “conformidade PDF/A” deve pensar em ficheiros PDF que estejam em conformidade com **PDF/A-** Por exemplo * PDF/A-1a: significa PDF/A versão 1, nível de conformidade a * PDF/A-2b: significa PDF/A versão 2, nível de conformidade b Exploramos estes aspetos com um pouco mais de detalhe. #### Versões PDF/A A norma PDF/A está sob a égide da ISO, publicada como uma norma chamada ISO 19005. Como referido, a especificação PDF evoluiu ao longo do tempo e isso, por sua vez, exigiu atualizações da ISO 19005, resultando na tabela abaixo: | | | | | ---------------- | ---------------- | ------------------------- | | **Versão PDF/A** | **Norma ISO** | **Baseado na versão PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) | No momento da redação deste texto (abril/maio de 2020), um PDF/A-4 atualizado (ISO 19005-4) está [em preparação](https://www.iso.org/standard/71832.html). #### Níveis de conformidade PDF/A Além de três versões PDF/A (PDF/A-1, PDF/A-2 e PDF/A-3), existem três *níveis de conformidade*: * Nível A (acessível) para acessibilidade (inclui os requisitos de arquivo do Nível B) * Nível B (básico) para arquivo * Nível U (Unicode) (= arquivo mais uso de Unicode para texto) Eis uma breve descrição destes níveis de conformidade: * **Nível B (básico)** é o requisito mínimo para conformidade no âmbito do PDF/A. Define requisitos para garantir que os documentos PDF conformes são adequados para arquivo a longo prazo — que podem sempre ser vistos ou impressos de forma fiável, independentemente de software, ferramentas ou sistemas operativos específicos. * **Nível A (acessibilidade)** inclui os requisitos da conformidade de Nível B mas, além disso, exige o uso de PDF etiquetado para fornecer estrutura lógica e informação de ordem de leitura, juntamente com o uso de Unicode para permitir o acesso ao texto do documento. * **Nível U (Unicode)** a conformidade foi um nível acrescentado ao PDF/A-2 e baseia-se no Nível B, exigindo adicionalmente o uso de Unicode para o texto do documento, mas não vai tão longe como o Nível A ao exigir informação de estrutura. As versões e os níveis de conformidade PDF/A podem ser resumidos numa tabela: | | | | | | ------------------------- | ------------------------------ | -------- | -------- | | **Nível de conformidade** | **PDF/A-** | | | | Nível A (acessível) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Nível B (básico) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Nível U (Unicode) | N/A (não existia para PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (“Acessibilidade Universal”) Embora a conformidade de Nível A da norma PDF/A vá até certo ponto na definição de requisitos para PDFs acessíveis, outra norma ISO chamada [ISO 14289](https://www.iso.org/standard/64599.html), referida como PDF/UA, vai mais longe. O PDF/UA reforça os requisitos de acessibilidade e clarifica as orientações contidas nas normas PDF/A e tornou-se a norma preferida para PDFs acessíveis. #### Protocolo Matterhorn Os leitores com um interesse profundo em saber mais sobre a conformidade PDF/UA podem interessar-se pelo [Protocolo Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) que é “uma lista de todas as formas possíveis de falhar a conformidade PDF/UA”. ### Software de validação Para verificar se um ficheiro PDF está em conformidade com uma determinada norma, ele tem de ser *validado* usando software de conformidade que analisa o PDF para verificar se o seu conteúdo e estrutura estão em conformidade com os requisitos dessa norma — como PDF/UA ou PDF/A-*x*a (em que *x* = 1, 2 ou 3). Note que a validação de PDFs — processando-os com uma ferramenta de validação preferida — pode produzir mensagens de diagnóstico ou avisos que podem ser bastante enigmáticos para o utilizador não especialista — talvez devido a alguns dados (ou estrutura) de baixo nível do PDF que não cumprem a norma relevante. Para muitos autores, interpretar esses avisos e convertê-los numa correção acionável para o(s) seu(s) documento(s) pode ser um desafio considerável. #### Software de validação gratuito * [veraPDF](https://verapdf.org/) que, citando o seu sítio web (acessado em 28 de maio de 2020), é um “validador de formato de ficheiro open source, construído para esse fim, que cobre todas as partes e níveis de conformidade PDF/A”. * (apenas Windows) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) que é uma “...ferramenta gratuita de verificação de acessibilidade de PDF que tem sido testada e comprovada desde 2010”. #### Software de validação comercial * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) fornece um conjunto de testes de validação de PDF juntamente com ferramentas para editar e corrigir etiquetas em ficheiros PDF não conformes. ### PDF Association: uma excelente fonte de informação O [PDF Association](https://www.pdfa.org/) produz muitos *excelente* recursos sobre PDF/A, PDF/UA e muitos outros tópicos relacionados com PDF — incluindo vídeos no seu [canal do YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) juntamente com artigos e publicações técnicas gratuitas disponíveis no seu sítio web. Uma dessas publicações é [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) que fornece uma introdução inestimável à norma PDF/UA e aos seus requisitos. ## PDFs acessíveis a partir de motores TeX e LaTeX Esperemos que as discussões anteriores tenham indicado que a produção de ficheiros PDF totalmente acessíveis e corretamente etiquetados é um desafio técnico exigente. Além disso, até mesmo o simples exemplo do Microsoft Word demonstrou que os autores podem usar facilmente combinações de funcionalidades de software que resultam em documentos PDF etiquetados que falham critérios de acessibilidade. Como ferramenta de autoria, o LaTeX oferece aos autores uma flexibilidade quase ilimitada na gama e complexidade de documentos que podem criar — o que poderá ser precisamente a razão para o escolher em primeiro lugar. O LaTeX também suporta extensibilidade através de milhares de pacotes adicionais que os autores podem usar como parte dos seus documentos. Além disso, os autores têm a liberdade de escrever novas macros TeX ou LaTeX, ou redefinir as existentes, para obter efeitos específicos. No entanto, talvez esta liberdade e flexibilidade tenham um preço, porque o conteúdo produzido pelas inúmeras interações de todos esses pacotes e macros LaTeX “de alguma forma” precisa de ser orquestrado se o LaTeX tiver de gerar automaticamente saída PDF corretamente etiquetada e acessível. Na prática, a extensibilidade, o poder, a versatilidade e a “liberdade” de autoria proporcionados pelo LaTeX colocam desafios técnicos à produção fluida e transparente (“automática”) de documentos PDF totalmente acessíveis e etiquetados que estejam em conformidade com as normas PDF/UA ou PDF/A-{1|2|3}a. A comunidade mais ampla de TeX e LaTeX está a esforçar-se para enfrentar esses desafios e o TeX User Group (TUG) está a coordenar esforços de investigação e desenvolvimento através do PDF accessibility and PDF standards [grupo de trabalho](https://www.tug.org/twg/accessibility/). Existe uma [lista de discussão](https://tug.org/mailman/listinfo/accessibility) que fornece uma forma de as partes interessadas discutirem a produção de ficheiros PDF etiquetados usando TeX e LaTeX. Nestas discussões vale a pena lembrar que o LaTeX não é, na verdade, um programa executável de composição tipográfica; é uma grande coleção de macros sofisticadas (comandos) escritas numa linguagem de nível inferior chamada TeX. Entre o seu documento LaTeX cuidadosamente elaborado e o PDF final composto tipograficamente está um software chamado motor TeX, cujo trabalho é “executar” o conjunto de comandos LaTeX (isto é, macros) usados para escrever e construir o seu documento — convertendo-os na representação tipográfica do seu documento guardada como ficheiro PDF. Quem é novo no ecossistema TeX/LaTeX fica muitas vezes, e compreensivelmente, perplexo com a profusão de nomes de som enigmático usados para as ferramentas que encontra: TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX e LuaLaTeX. Se se identifica com isso, há ajuda no artigo do Overleaf [O Que Há num Nome: Um Guia para os Muitos Sabores de TeX](/latex/overleaf-learn-latex-pt/artigos-aprofundados/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) que explica a origem e o significado de todos esses termos. Motores TeX como pdfTeX, XeTeX ou LuaTeX são uma classe de software chamada *compiladores de documentos*: pegam no seu código LaTeX e compilam-no na sua forma composta tipograficamente, “convertendo” macros (comandos) LaTeX de volta para instruções da linguagem TeX de nível inferior, que são “executadas” para produzir o resultado tipográfico. Os sistemas de composição tipográfica baseados em TeX são capazes de produzir conteúdo excecionalmente complexo — incluindo matemática avançada, notação musical, estruturas químicas, gráficos e texto composto sofisticado em múltiplos idiomas. Para garantir que esses documentos complexos cumprem as normas e regulamentos de acessibilidade, os motores TeX, juntamente com a coleção de macros LaTeX e pacotes LaTeX, precisam de gerar ficheiros PDF apropriadamente etiquetados, incorporando uma grande quantidade de dados adicionais nos ficheiros PDF que geram. Embora os motores TeX possam gerar ficheiros PDF extremamente complexos, os seus processos internos, algoritmos e funções não têm *suporte* funcionalidades *concebidas especificamente* para apoiar a produção de PDFs etiquetados e acessíveis. Em vez disso, o suporte para etiquetagem e acessibilidade tem de ser obtido através de programação macro complexa que “injeta” dados adicionais nos PDFs gerados pelos motores TeX — criando as sequências de conteúdo marcado, elementos de estrutura e estruturas de dados de estrutura lógica armazenadas em `StructTreeRoot`. E é aqui que essa “orquestração” ganha um foco nítido: o código no núcleo (kernel) do LaTeX, juntamente com o código em milhares de pacotes e inúmeras macros criadas pelos autores, teria de cooperar muito cuidadosamente para garantir que a execução das macros produz a etiquetagem correta do conteúdo dos documentos resultantes. Essa “orquestração” teria de ser fiável — não importa como os autores escolham combinar e usar as funcionalidades, comandos e capacidades do LaTeX, o seu sistema de pacotes e o poder das macros TeX. ### As necessidades dos autores Para a maioria das pessoas, o LaTeX é apenas uma ferramenta que permite criar documentos lindamente compostos tipograficamente com a liberdade de escolher pacotes para o ajudar a conseguir isso. A grande maioria dos autores em LaTeX quer simplesmente que os seus documentos “funcionem”: que sejam compostos sem erro para poderem submeter a sua tese, artigo, relatório ou terminar aquele livro há muito aguardado. Não é irrazoável que os utilizadores do LaTeX esperem que a coleção escolhida de pacotes LaTeX coexista pacificamente, interagindo de forma fluida e transparente para fornecer os comandos e funcionalidades necessários para produzir os seus documentos. Esses mesmos desejos são provavelmente encontrados quando confrontados com a exigência de produzir PDF etiquetado a partir de LaTeX: deveria “simplesmente funcionar”, de forma transparente e com intervenção mínima do autor. Infelizmente, ainda estamos longe da experiência de “Eureka! a etiquetagem acontece simplesmente, não importa o que eu faça”. A ligação entre os requisitos técnicos da acessibilidade mais PDF etiquetado com o LaTeX e a liberdade de autoria é inerentemente complexa e, talvez, seja inevitável que seja necessária alguma forma de “disciplina do autor” se os desafios técnicos quiserem tornar-se suscetíveis de implementação e resolução práticas. Uma questão separada, mas relacionada, é que a etiquetagem incorreta pode não ter qualquer impacto visual no PDF final: visualmente, pode parecer perfeito e provavelmente também será impresso sem problemas, mas, desconhecido para o autor, a etiquetagem pode estar “quebrada”, sendo apenas descoberta através de falhas subsequentes nos testes de conformidade/validação PDF/A e/ou de testes práticos adicionais através de software de acessibilidade, como leitores de ecrã. ### Ficheiros PDF produzidos no Overleaf O Overleaf fornece à sua comunidade de utilizadores um editor LaTeX baseado em navegador, juntamente com ferramentas de gestão de projetos e documentos que facilitam a autoria colaborativa — tudo construído sobre uma instalação padrão do TeX Live. Na prática, o Overleaf permite aos utilizadores “executar o LaTeX à distância” através de um navegador web, fornecendo uma camada de proteção face às complexidades de gerir e manter um sistema TeX Live completo. Uma consequência da utilização, pelo Overleaf, de uma instalação padrão TeX/LaTeX é que os PDFs produzidos a partir de código LaTeX escrito no editor do Overleaf são criados usando exatamente as mesmas tecnologias presentes em qualquer outra instalação TeX Live da mesma versão — incluindo configurações que os utilizadores instalaram nos seus dispositivos locais. A única diferença é que os motores TeX que compilam e processam o código LaTeX do Overleaf são executados em servidores remotos, e não em máquinas locais. O Overleaf faz linearização do PDF gerado por TeX para download/visualização eficiente num navegador, mas esse processo não está relacionado com a acessibilidade do próprio conteúdo do PDF. A produção de PDFs acessíveis via Overleaf depende das capacidades e funcionalidades incorporadas nos motores TeX padrão, juntamente com a disponibilidade de pacotes macro LaTeX adequados que os utilizadores possam empregar como parte do seu documento. Os documentos LaTeX criados usando o Overleaf têm de permanecer compatíveis com outras instalações TeX e LaTeX, porque os utilizadores frequentemente precisam de exportar o seu projeto LaTeX do Overleaf para submissão a uma ampla gama de sistemas de revistas/editoras. Introduzir funcionalidades específicas do Overleaf nos seus documentos LaTeX, ou nos motores TeX subjacentes, inibiria seriamente a liberdade dos utilizadores de usar o seu trabalho noutro lugar. O Overleaf reconhece e apoia a necessidade de PDFs totalmente acessíveis gerados a partir de sistemas de autoria TeX/LaTeX: investimos tempo a investigar questões de acessibilidade, explorando os desenvolvimentos mais recentes nos motores TeX e nos pacotes experimentais LaTeX que suportam PDF etiquetado. Em última análise, no momento da redação deste texto, não existe uma solução “pronta a usar” que os autores em LaTeX possam utilizar (via `\usepackage`) para gerar, de forma fluida e transparente, PDFs totalmente acessíveis e em conformidade com PDF/UA a partir de documentos LaTeX genéricos. Quando essas soluções estiverem disponíveis através de atualizações do TeX Live, elas, naturalmente, ficarão disponíveis para a comunidade de utilizadores do Overleaf. ### Alguns pacotes LaTeX para explorar etiquetagem e acessibilidade Para muitas pessoas, [tex.stackexchage](https://tex.stackexchange.com/) é o primeiro porto de escala para obter ajuda com TeX, LaTeX ou ConTeXt. É um recurso incrível e tem muitas questões sobre o tema da [acessibilidade](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) e a produção de PDFs acessíveis via LaTeX. Se ler e navegar por estas questões, e pela consequente sequência de respostas e comentários, apenas uma conclusão é inevitável: no momento atual não existe uma solução completa, em nível de produção, para criar automaticamente PDFs totalmente acessíveis, em conformidade com as normas e etiquetados, a partir de todos os tipos de documentos LaTeX. No entanto, existem alguns pacotes que suportam etiquetagem — embora, talvez, dentro de uma gama restrita de casos de utilização e tipos de documentos. A lista seguinte é fornecida para leitores que desejem explorar a etiquetagem de PDF baseada em LaTeX: * [`tagpdf` pacote](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): pacote altamente capaz, concebido para experimentar a etiquetagem de PDF. Suporta pdfTeX e LuaTeX e fornece documentação extremamente útil e interessante que contém algumas notas excelentes sobre os desafios técnicos de criar PDFs etiquetados via motores TeX; é uma leitura altamente recomendada para quem estiver interessado em compreender melhor as questões envolvidas. O foco da direção futura será provavelmente o LuaTeX. * [`axessibility` pacote](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov e Universidade de Turim): fornece acesso a fórmulas em ficheiros PDF por tecnologias de apoio. * [`acessibilidade` pacote](https://ctan.org/pkg/accessibility) (Andy Clifton): cria ficheiros PDF etiquetados e estruturados. As notas CTAN indicam que este pacote é “destinado a utilizadores das classes de documento KOMA-Script”. * [`accsupp` pacote](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): pacote experimental para fornecer melhor suporte de acessibilidade para ficheiros PDF. Outra referência digna de nota é um artigo de 2018 [Implementing PDF standards for Mathematical Publishing](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) do Dr. Ross Moore, do Departamento de Matemática da Universidade Macquarie. Nesse artigo, o Dr. Moore inclui um breve resumo dos desafios da etiquetagem de PDFs em LaTeX: > “A principal fonte de dificuldade reside na forma como diferentes ambientes podem interagir entre si. Há muitas situações em LaTeX em que um ambiente ou estrutura não está realmente concluído até que o seguinte tenha começado. Portanto, não se trata apenas de colocar etiquetas de início e fim em volta de cada peça de conteúdo fornecida. Em vez disso, é necessário compreender as subtilezas de como diferentes ambientes e outras estruturas começam e terminam efetivamente, no contexto estabelecido pelo material circundante.” O Dr. Moore é também o atual mantenedor do [`pdfx`](https://ctan.org/pkg/pdfx) pacote e um especialista e pioneiro de PDF etiquetado usando TeX/LaTeX. O seu trabalho vale muito a pena procurar — incluindo este vídeo no YouTube, que fornece perspetivas interessantes: {% embed url="" %} #### Nota sobre o pacote pdfx O [`pdfx`](https://ctan.org/pkg/pdfx) pacote (Ross Moore et al.) fornece excelente suporte para PDF/A-1|2|3b (arquivo), e outras opções, mas ainda não produz PDF etiquetado. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/mais-topicos/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.