Guia de acessibilidade de PDF: etiquetas e PDF/UA

Os PDF são o problema silencioso de acessibilidade dentro de quase todas as organizações. Os sites são auditados, redesenhados e testados com leitores de ecrã — mas o relatório anual, o documento de política, o extrato de prestações e o formulário de candidatura que vivem por detrás de uma ligação de descarregamento são, demasiadas vezes, disponibilizados exatamente como saíram da caixa de diálogo de exportação. Para um leitor com visão, parecem cuidados. Para alguém que utiliza um leitor de ecrã, uma lupa ou navegação apenas por teclado, esse mesmo ficheiro pode ser um muro impenetrável: sem cabeçalhos entre os quais saltar, imagens sem descrição, tabelas que se leem como um fluxo de números sem sentido, e campos de formulário que não podem ser preenchidos de todo.

Este guia explica por que motivo os PDF são tão frequentemente inacessíveis e o que torna realmente um PDF utilizável pelas tecnologias de apoio. Aborda os blocos estruturais — etiquetas, ordem de leitura, texto alternativo, tabelas, formulários e metadados — e as normas que os regem: WCAG 2.2 e PDF/UA, a especificação ISO 14289 para PDF etiquetados e acessíveis. Ao longo de todo o texto, o objetivo é aquele que a QualiBooth aplica a cada documento em que trabalha: um ficheiro que funciona na prática, confirmado com tecnologia de apoio real, e não apenas abençoado por um verificador automático.

Por que motivo os PDF são tão frequentemente inacessíveis

Um PDF é, no fundo, uma descrição de como pintar marcas numa página. O formato foi concebido para preservar a fidelidade visual — para fazer com que um documento pareça idêntico em qualquer ecrã ou impressora. Esse objetivo de conceção é exatamente o que torna a acessibilidade difícil. A fidelidade visual nada diz sobre o significado. Uma linha de texto a negrito de 18 pontos parece um cabeçalho ao olho humano, mas a menos que o ficheiro registe explicitamente «isto é um cabeçalho», a tecnologia de apoio não tem forma de saber que se trata de algo mais do que glifos maiores.

A maioria dos PDF em circulação são não etiquetados. Contêm o conteúdo visual, mas nenhuma da estrutura subjacente — nenhuma informação sobre o que é um cabeçalho, um parágrafo, uma lista, uma tabela ou uma imagem. Um leitor de ecrã confrontado com um PDF não etiquetado ou se recusa a lê-lo de forma significativa ou recorre a suposições, inferindo uma ordem de leitura a partir da posição das marcas na página. Os resultados vão de desajeitados a inutilizáveis: um boletim informativo a duas colunas lido em linha reta através de ambas as colunas, uma legenda lida antes do parágrafo a que pertence, ou notas de rodapé a interromper o meio de uma frase.

Vários hábitos de produção comuns agravam as coisas:

Documentos digitalizados. Uma digitalização é apenas uma imagem de uma página. Sem reconhecimento ótico de carateres (OCR), não há de todo texto real — nada para ler, pesquisar ou selecionar.
Exportações que descartam a estrutura. Muitos caminhos «Guardar como PDF» e «Imprimir para PDF» descartam a estrutura de cabeçalhos e listas que existia no documento de origem.
Disposições de ferramentas de design. Os ficheiros criados em software de paginação podem ter páginas visualmente corretas cuja ordem dos objetos subjacentes não tem qualquer relação com a sequência de leitura pretendida.
Desordem decorativa. As imagens de fundo, os filetes e os ornamentos ficam expostos à tecnologia de apoio e são anunciados como se transportassem significado.

Nada disto é visível no ecrã, e é precisamente por isso que o problema persiste. A solução é acrescentar a camada estrutural que o formato deixa opcional — o trabalho de remediação de PDF.

Etiquetas e estrutura do documento

As etiquetas são o alicerce de um PDF acessível. Um PDF etiquetado transporta uma hierarquia oculta — a árvore de estrutura — que se situa ao lado do conteúdo visual e descreve o que cada parte da página é realmente. Isto é diretamente análogo ao HTML semântico por detrás de uma página web bem construída: onde o HTML utiliza <h1>, <p>, <ul> e <table>, um PDF etiquetado utiliza elementos de estrutura como <H1>, <P>, <L> (lista) e <Table>.

A árvore de etiquetas é o que dá à tecnologia de apoio algo para navegar. Com ela instalada, um leitor de ecrã consegue fazer aquilo de que os seus utilizadores dependem:

Saltar por cabeçalho. Os utilizadores percorrem um documento longo de cabeçalho em cabeçalho em vez de ouvir cada palavra em sequência. Isto requer etiquetas de cabeçalho reais (<H1> a <H6>) aplicadas numa ordem lógica e aninhada — nunca saltando níveis, nunca fingindo um cabeçalho ao colocar um parágrafo a negrito.
Compreender listas. Uma etiqueta <L> com os seus itens <LI> indica ao leitor de ecrã «isto é uma lista de cinco itens», para que o utilizador saiba onde está e quanto falta.
Distinguir o conteúdo da decoração. O conteúdo genuíno é etiquetado; as marcas puramente decorativas são designadas como artefactos para serem totalmente ignoradas.

Uma estrutura de cabeçalhos correta e logicamente aninhada é a coisa de maior impacto que pode acertar num PDF, porque transforma uma experiência de escuta linear numa experiência navegável. Errá-la — ou omiti-la — é um dos problemas de acessibilidade comuns que surge repetidamente nas auditorias de documentos.

Ordem de leitura

As etiquetas dizem o que é cada elemento. A ordem de leitura diz em que sequência esses elementos são apresentados a alguém que não consegue ver a página. As duas estão relacionadas mas são distintas, e a ordem de leitura é onde muitos PDF, por outro lado bem etiquetados, falham.

Um leitor de ecrã anuncia o conteúdo pela ordem definida pela estrutura do documento, e não pela ordem em que as marcas calham estar no ficheiro. Num documento de coluna única, as duas geralmente alinham-se. Em qualquer coisa mais complexa — disposições a várias colunas, barras laterais, citações em destaque, legendas, texto envolvido à volta de uma imagem — divergem com frequência. O olho com visão reorganiza o conteúdo sem esforço; a tecnologia de apoio segue a ordem que lhe é dada, e se essa ordem estiver errada o significado desmorona-se.

Uma boa ordem de leitura significa que o conteúdo é anunciado na sequência que um leitor com visão seguiria naturalmente: o título antes do corpo, a introdução antes da barra lateral, uma legenda depois da figura que descreve. Defini-la corretamente é um juízo manual sobre a forma como o documento deve ser lido, e é por isso que as ferramentas automáticas, por si só, não a conseguem garantir. É um dos resultados centrais da remediação de PDF profissional, e uma das primeiras coisas que os testadores experientes verificam.

Texto alternativo para imagens

Cada imagem que transporta informação precisa de um equivalente em texto para que possa ser descrita a pessoas que não a conseguem ver. Os princípios são os mesmos que para a web, aplicados através das etiquetas PDF.

Imagens informativas — gráficos, diagramas, fotografias que transmitem significado, infografias — precisam de texto alternativo conciso e exato que comunique a mesma informação que a imagem. Para um gráfico, isso significa muitas vezes resumir a conclusão («As receitas cresceram 12% em termos homólogos») em vez de descrever o visual («um gráfico de barras a azul»).
Imagens complexas — um diagrama de processo detalhado ou uma figura rica em dados — podem precisar tanto de um texto alternativo curto como de uma descrição mais longa, ou dos dados subjacentes apresentados numa forma acessível noutro local do documento.
Imagens decorativas — molduras, texturas de fundo, separadores ornamentais, um logótipo repetido num rodapé — devem ser marcadas como artefactos para que a tecnologia de apoio as ignore. Forçar um leitor de ecrã a anunciar «imagem, imagem, imagem» para decoração é, por si só, uma falha de acessibilidade.
Texto dentro de imagens — um gráfico de uma citação, um cabeçalho de carta digitalizado, a imagem de um botão com uma etiqueta — deve ter esse texto capturado, seja como texto alternativo ou, melhor ainda, como texto real selecionável.

Escrever bom texto alternativo é uma tarefa de conteúdo, não uma tarefa técnica. Exige compreender para que serve a imagem no seu contexto — a mesma competência que a nossa equipa de consultoria de acessibilidade traz ao conteúdo web.

Tabelas acessíveis

As tabelas são o ponto em que a acessibilidade de PDF se torna genuinamente difícil, e onde as exportações automáticas falham mais vezes. Uma tabela de dados comunica significado através da relação entre uma célula e os seus cabeçalhos de linha e de coluna. Os leitores com visão reconstroem essas relações visualmente, lançando um olhar para cima e para a esquerda. Um utilizador de leitor de ecrã não o consegue — depende de a tabela estar marcada de forma a que as associações de cabeçalhos sejam explícitas.

Uma tabela PDF acessível precisa de:

Uma estrutura <Table> adequada que contenha <TR> (linhas), <TH> (células de cabeçalho) e <TD> (células de dados), em vez de uma grelha solta de texto posicionado para parecer uma tabela.
Células de cabeçalho corretamente identificadas, com âmbito (linha ou coluna) onde a disposição da tabela o exija, de modo que, à medida que um utilizador percorre os dados, os cabeçalhos relevantes sejam reanunciados («T3, Receitas, 1,2 milhões»).
Um tratamento sensato das células fundidas ou expandidas, que complicam as relações de cabeçalho e confundem com frequência as ferramentas automáticas.

Um antipadrão comum é a tabela de disposição — uma grelha utilizada apenas para posicionar o conteúdo visualmente, sem relações de dados reais. As tabelas de disposição não devem de todo ser etiquetadas como tabelas, porque fazê-lo força a tecnologia de apoio a anunciar linhas e colunas fantasma. Distinguir uma tabela de dados de um artefacto de disposição, e depois codificar as relações corretas, é um trabalho manual minucioso que beneficia enormemente da revisão por pessoas que utilizam realmente leitores de ecrã todos os dias.

Formulários PDF acessíveis

Os formulários são os documentos de maior risco que uma organização publica, porque são transacionais: uma candidatura, uma reclamação, um consentimento, uma inscrição. Se um formulário PDF não puder ser preenchido com tecnologia de apoio, a pessoa não é meramente incomodada — fica excluída de um serviço.

Um formulário PDF acessível requer:

Campos rotulados. Cada campo — entrada de texto, caixa de verificação, botão de opção, lista pendente — precisa de um nome acessível (uma sugestão/etiqueta em termos PDF) para que um leitor de ecrã anuncie para que serve o campo, e não apenas «editar texto».
Ordem de tabulação lógica. Os utilizadores de teclado percorrem os campos com a tecla Tab. A ordem de tabulação deve seguir o fluxo visual e lógico do formulário, e não a ordem pela qual os campos foram adicionados no editor.
Controlos agrupados. Os botões de opção e as caixas de verificação relacionados devem ser agrupados para que a sua pergunta partilhada seja anunciada uma vez e as opções sejam compreendidas como um conjunto.
Campos obrigatórios e instruções. Os campos obrigatórios, os requisitos de formatação e as orientações de erro devem ser transmitidos em texto, e não apenas por cor ou pistas visuais.
Plena operabilidade por teclado. Cada campo deve ser alcançável e operável sem rato.

Os formulários situam-se na interseção da estrutura, da interação e do conteúdo, o que faz deles a parte do trabalho de PDF onde fazê-lo corretamente mais importa. A mesma disciplina aplica-se a outros documentos transacionais — está intimamente relacionada com o cuidado necessário para o e-mail acessível, onde a estrutura e a rotulagem determinam se uma mensagem pode realmente ser utilizada.

Idioma, título e metadados

Algumas das correções de PDF de maior impacto são também as mais pequenas. Um punhado de propriedades ao nível do documento alteram materialmente a forma como a tecnologia de apoio lida com um ficheiro.

Idioma do documento. O PDF deve declarar o seu idioma principal (por exemplo, pt-PT) para que um leitor de ecrã utilize as regras de pronúncia corretas. Um parágrafo em inglês lido com fonética portuguesa, ou vice-versa, é dificilmente inteligível. As passagens num idioma diferente do documento principal devem ter os seus próprios marcadores de idioma.
Título do documento. Os metadados do PDF devem incluir um título significativo, e o visualizador deve ser configurado para mostrar esse título em vez do nome do ficheiro. «Relatório anual de acessibilidade 2026» é anunciado e mostrado; «final_v3_PARAWEB.pdf» não é.
Navegação por separadores e marcadores. Os marcadores (o esquema do documento) dão a todos os utilizadores — e especialmente aos que navegam de forma não visual — uma forma de saltar para as secções principais de um documento longo.
Indicadores de PDF etiquetado e metadados limpos. O ficheiro deve estar marcado como um PDF etiquetado e transportar metadados coerentes e exatos.

Estas propriedades demoram minutos a definir e são exigidas para a conformidade, e no entanto são saltadas na grande maioria dos PDF publicados.

WCAG 2.2 e PDF/UA (ISO 14289)

Duas normas regem os PDF acessíveis, e trabalham em conjunto em vez de concorrerem entre si.

WCAG 2.2 é a base de referência independente da tecnologia para a acessibilidade digital. Os seus critérios de sucesso — alternativas em texto, informação e relações, sequência significativa, contraste, operabilidade por teclado, e os restantes — aplicam-se aos PDF tal como se aplicam às páginas web. WCAG 2.2 é a norma para a qual aponta a maioria das leis, e o W3C publica técnicas específicas para satisfazer as WCAG com as funcionalidades de PDF (etiquetar cabeçalhos, fornecer texto alternativo, definir a ordem de leitura, e assim por diante). Se está a trabalhar a conformidade geral, o nosso guia para tornar o conteúdo conforme às WCAG e a visão geral da conformidade WCAG aplicam-se ambos diretamente aos documentos.

PDF/UA — formalmente ISO 14289 — é a especificação técnica para o PDF acessível. Onde as WCAG descrevem resultados («fornecer alternativas em texto»), o PDF/UA prescreve exatamente como um PDF deve ser construído para ser um documento corretamente etiquetado, legível por máquina e acessível: que tipos de estrutura utilizar, como a árvore de etiquetas deve ser formada, como os artefactos devem ser marcados, e como os formulários e as tabelas devem ser codificados. Os dois são complementares — a abordagem mais robusta é remediar segundo os requisitos técnicos do PDF/UA enquanto se validam os resultados do lado do utilizador face às WCAG 2.2.

A conformidade com estas normas é o que sustenta as obrigações legais em todas as jurisdições. Os PDF publicados por organizações abrangidas inserem-se plenamente no European Accessibility Act, na ADA e na Section 508, que tratam todas os documentos descarregáveis como parte da experiência digital que deve ser acessível.

Remediar PDF existentes vs criar PDF acessíveis

Há dois caminhos para PDF acessíveis, e a maioria das organizações precisa de ambos.

Remediar PDF existentes significa pegar num ficheiro acabado — um relatório, um arquivo histórico de extratos, um formulário digitalizado — e acrescentar ou corrigir a camada de acessibilidade: executar OCR onde for necessário, construir a árvore de etiquetas, definir a ordem de leitura, escrever texto alternativo, corrigir tabelas e rotular campos de formulário. A remediação é essencial quando os ficheiros de origem desapareceram, quando os documentos foram produzidos por terceiros, ou quando se tem um arquivo publicado que precisa de ser posto em conformidade. De forma crucial, a remediação altera a estrutura subjacente, não o design visual — o documento parece idêntico e torna-se utilizável por todos. Este é o cerne do serviço de remediação de PDF da QualiBooth, que dimensiona lotes por importância e alcance e prioriza primeiro os documentos que mais importam.

Criar PDF acessíveis significa integrar a acessibilidade no processo de produção para que os documentos nasçam acessíveis. Isso envolve utilizar estilos de cabeçalho reais, estilos de lista e texto alternativo na aplicação de origem; conceber tabelas como tabelas de dados; definir o idioma e o título; e escolher um caminho de exportação que preserve a árvore de etiquetas. Criar de forma acessível é drasticamente mais barato do que reparar o mesmo documento mais tarde, e é a única resposta sustentável para organizações que publicam PDF continuamente.

As duas abordagens não são uma ou outra. O padrão prático é remediar os documentos já em circulação enquanto se corrige o processo a montante para que os novos documentos não recriem o problema. Enraizar essa mudança é exatamente o que a melhoria do processo de acessibilidade aborda — transformar a publicação acessível de um projeto pontual na forma predefinida de trabalhar da sua equipa. Uma visão mais ampla de como o trabalho de documentos e o trabalho web se articulam é apresentada na nossa visão geral dos serviços de acessibilidade.

Validar com leitores de ecrã — e por que motivo os overlays não ajudam

Um PDF só é acessível se funcionar realmente para as pessoas que dele dependem. É por isso que a validação não se pode ficar por um verificador automático. As ferramentas que analisam um PDF face às regras do PDF/UA são valiosas — detetam etiquetas em falta, idiomas não definidos e erros estruturais em escala — mas verificam a presença de estrutura, não a sua qualidade. Uma ferramenta automática consegue confirmar que uma imagem tem texto alternativo; não lhe consegue dizer que o texto alternativo está errado. Consegue confirmar que um cabeçalho existe; não lhe consegue dizer que está aninhado no nível errado.

A validação real combina ambos:

Verificação automática para detetar falhas estruturais e de metadados de forma ampla e consistente. Software como a plataforma de análise de acessibilidade da QualiBooth destaca-se a sinalizar problemas detetáveis por máquina em grandes volumes.
Testes manuais com tecnologia de apoio — navegar pelo documento com um leitor de ecrã, mover-se por cabeçalho, ler tabelas, tabular através de um formulário — para confirmar que a experiência é coerente. Esta é a única forma de verificar a ordem de leitura, a qualidade do texto alternativo e a usabilidade dos formulários. A nossa metodologia de auditoria manual explica por que motivo os testes humanos são insubstituíveis, e as auditorias realizadas por pessoas com deficiência fazem emergir problemas que nenhum verificador e nenhum testador com visão alguma vez notaria.

Uma palavra de cautela sobre atalhos. Os overlays de acessibilidade — scripts ou widgets de terceiros que afirmam corrigir a acessibilidade automaticamente — não resolvem a acessibilidade de PDF, e a QualiBooth não os recomenda. Não conseguem criar uma árvore de etiquetas correta, julgar a ordem de leitura ou escrever texto alternativo significativo, porque essas tarefas exigem compreender o conteúdo e a intenção do documento. Não existe substituto automático para uma remediação adequada. A verdadeira acessibilidade de PDF resulta de uma estrutura correta mais verificação humana — a abordagem por detrás do nosso trabalho de remediação de PDF.

Perguntas frequentes

Um PDF não etiquetado é alguma vez aceitável? Não. Um PDF não etiquetado é, por definição, inacessível à tecnologia de apoio e falha tanto nas WCAG 2.2 como no PDF/UA. Qualquer PDF que publique para o público ou para colaboradores deve ser etiquetado.

Tornar um PDF acessível altera o seu aspeto? Não. A remediação acrescenta e corrige a camada estrutural oculta — etiquetas, ordem de leitura, metadados — sem alterar o design visual. A página parece idêntica.

Devo simplesmente fornecer uma versão HTML em vez de um PDF acessível? Uma alternativa em HTML acessível é muitas vezes a melhor experiência e vale a pena oferecê-la. Mas se publicar o PDF, o próprio PDF tem de ser acessível — uma alternativa em HTML não isenta o documento dos requisitos de conformidade.

Os documentos digitalizados podem ser tornados acessíveis? Sim, mas têm primeiro de passar por OCR para criar texto real, após o que se aplicam os passos normais de remediação — etiquetagem, ordem de leitura, texto alternativo, tabelas.

Como mantenho os novos PDF acessíveis sem remediar cada um deles? Corrija o processo de criação: utilize estilos reais e texto alternativo na origem, conceba tabelas de dados adequadas, defina o idioma e o título, e exporte através de um caminho que preserve as etiquetas. Combinar a remediação com a melhoria do processo torna os documentos acessíveis a predefinição.

Conclusão

A acessibilidade de PDF não é um passo opcional de polimento — é a diferença entre um documento que todos podem utilizar e um que exclui silenciosamente as pessoas que dependem da tecnologia de apoio. O trabalho é concreto e bem compreendido: etiquetar a estrutura, definir uma ordem de leitura correta, descrever imagens, codificar tabelas e formulários adequadamente, declarar o idioma e o título, e validar o resultado face às WCAG 2.2 e ao PDF/UA com leitores de ecrã reais, bem como com ferramentas automáticas. Remedeie os documentos que já publica, corrija o processo que produz novos, e evite os atalhos por overlay que prometem acessibilidade sem a entregar.

Se os seus relatórios, extratos, brochuras ou formulários nunca foram verificados, é por aí que deve começar. Pode começar com uma análise de acessibilidade gratuita, pedir uma demonstração da plataforma QualiBooth, ou falar com a nossa equipa sobre remediação de PDF para um único documento crítico ou um arquivo histórico inteiro.