Os seus PDF fazem parte da acessibilidade do seu site
Última atualização:
Toda a organização que nunca publicaria uma página web inacessível publica rotineiramente PDF inacessíveis: o relatório anual, o manual do produto, o formulário de candidatura, a lista de preços. Para o visitante que os descarrega, não há diferença — um documento que não consegue ler é um serviço que não consegue usar. Este artigo trata os PDF publicados como aquilo que são, parte da superfície de acessibilidade do site, e percorre os seis sinais estruturais que decidem se a tecnologia de apoio consegue trabalhar com um documento: etiquetagem, idioma, título, estrutura e títulos, texto alternativo das imagens e marcadores. Também traça a linha com honestidade: uma verificação estrutural leve é um teste rápido, não uma validação PDF/UA, e saber quando precisa da validação completa faz parte de fazer isto bem.
Os documentos fazem parte do site
O trabalho de acessibilidade tende a parar na fronteira do HTML. O site recebe uma auditoria, os modelos são corrigidos, o contraste é verificado — e depois a secção de “documentos” continua silenciosamente a servir formulários digitalizados, exportações sem etiquetas e manuais cujo texto inteiro é uma imagem incorporada. No entanto, do lado do utilizador do ecrã, o PDF é o site: é onde vive o formulário de pensão, onde vivem as instruções de segurança, onde vive a lista de preços detalhada. Um utilizador de leitor de ecrã que atravessa as suas páginas acessíveis e embate num relatório de 90 páginas sem etiquetas não experienciou um serviço acessível; experienciou um átrio acessível e uma sala trancada.
A boa notícia é que a acessibilidade dos documentos falha de formas previsíveis e verificáveis. Ao contrário dos juízos de valor na acessibilidade web — este padrão de interação é compreensível?, aquela ordem de foco é lógica? — as falhas mais comuns em PDF são factos estruturais que uma máquina pode verificar: as etiquetas estão lá ou não estão, o idioma está declarado ou não está. É exatamente isso que o verificador de acessibilidade de PDF deste site lê, localmente no navegador, e combina naturalmente com a verificação de saúde do site: uma cobre as páginas, a outra cobre os ficheiros que as páginas entregam.
A Lei Europeia de Acessibilidade mudou o que está em jogo
Desde 28 de junho de 2025, a Lei Europeia de Acessibilidade aplica-se a uma vasta gama de produtos e serviços oferecidos a consumidores na UE — incluindo comércio eletrónico, banca, livros eletrónicos, bilhética e grande parte do negócio digital quotidiano. Os seus requisitos são habitualmente cumpridos em conformidade com a norma harmonizada EN 301 549, que por sua vez remete para as WCAG — e as WCAG aplicam-se tanto a documentos não web como a páginas web. Em termos claros: para os serviços abrangidos, um PDF inacessível de que um cliente precisa já não é apenas um problema de qualidade ou ético; é uma questão de conformidade, e as autoridades de fiscalização do mercado podem agir sobre ela.
Vale a pena enunciar dois limites com clareza, porque o direito da acessibilidade é muitas vezes exagerado e subestimado. A Lei não abrange todas as organizações nem todos os documentos — há isenções (as microempresas que prestam serviços, por exemplo) e disposições transitórias, e os detalhes diferem por Estado-Membro. E nenhuma verificação automatizada, incluindo a deste site, estabelece a conformidade legal; a conformidade é uma propriedade de todo o serviço tal como os utilizadores o experienciam, avaliado devidamente. O que a Lei muda para a maioria das equipas é mais simples: os documentos estão agora inequivocamente dentro do âmbito da conversa sobre acessibilidade, pelo que “depois corrigimos os PDF” deixou de ser uma frase segura.
As seis verificações, uma a uma
1. PDF etiquetado. A etiquetagem é a árvore de estrutura oculta que marca títulos, parágrafos, listas, figuras e células de tabela, e regista a ordem de leitura. É a base: sem etiquetas, um leitor de ecrã recebe um fluxo de conteúdo por ordem de armazenamento, que em esquemas de várias colunas e relatórios exportados pode aproximar-se de uma salada de palavras. O que a verificação não lhe pode dizer: se as etiquetas estão corretas — um documento pode estar etiquetado e mesmo assim ter títulos marcados como parágrafos. Etiquetado é necessário, não suficiente.
2. Idioma do documento. A entrada /Lang do catálogo diz à síntese de voz em que idioma pronunciar. Sem ela, um leitor de ecrã em inglês lerá alegremente um relatório em alemão com fonética inglesa, o que vai do cómico ao incompreensível. A verificação é binária — um idioma está declarado ou não está — e não lhe pode dizer se o idioma declarado é o correto, nem se as passagens noutros idiomas estão marcadas individualmente, como exige a boa prática.
3. Título do documento. O título nas propriedades do documento (ou nos metadados XMP) é a primeira coisa que a tecnologia de apoio anuncia, o que o separador do navegador mostra e o que uma pasta de transferências deveria mostrar — em vez de “export_final_v3.pdf”. A preferência do visualizador relacionada, DisplayDocTitle, decide se os leitores de PDF mostram esse título em vez do nome do ficheiro; o verificador comunica-a separadamente porque um título presente mas oculto é uma correção a meio. O que a verificação não pode julgar é a qualidade do título: “Relatório” passa, e não ajuda ninguém.
4. Árvore de estrutura e títulos. Uma árvore de estrutura com elementos de título reais (H, H1–H6) é a forma como os leitores não visuais folheiam: a navegação por títulos é a estratégia mais usada para encontrar informação em documentos longos. A verificação conta os elementos de título quando a árvore pode ser recuperada. Não lhe pode dizer se os níveis de título estão numa ordem sensata nem se os títulos descrevem as suas secções — uma árvore cheia de títulos “Sem título” passa na contagem e falha ao leitor.
5. Texto alternativo das imagens. O verificador conta os XObjects de imagem nas páginas face aos elementos de estrutura /Figure com um /Alt não vazio, e rotula o resultado como uma aproximação — porque uma figura pode envolver várias imagens, as imagens decorativas têm corretamente um alternativo vazio, e a correspondência entre imagens desenhadas e elementos de estrutura não é de um para um. Trate-o como um alarme de fumo de cobertura, não como uma auditoria. E nunca pode julgar o próprio texto alternativo: “imagem123.jpg” é um texto alternativo não vazio, e não vale nada.
6. Marcadores. O contorno do documento é o corrimão dos documentos longos: um manual de 200 páginas com marcadores é navegável; sem eles é uma rolagem. A verificação lê a contagem declarada do contorno. Não lhe pode dizer se os marcadores estão rotulados de forma útil nem se apontam para as páginas certas — apenas que a navegação existe. Para documentos curtos, isto é o menos importante dos seis; para relatórios e manuais, é a diferença entre uma referência e um palheiro.
Um teste rápido não é uma validação PDF/UA
PDF/UA (ISO 14289) é a norma completa para PDF acessíveis: estrutura etiquetada, ordem de leitura correta, cabeçalhos de tabela, anotações de ligações, rótulos de campos de formulário, contraste e mais, verificado por validadores e por testes humanos. O validador de referência gratuito e de código aberto veraPDF é uma ferramenta de ambiente de trabalho que verifica um ficheiro em profundidade face às regras de PDF/UA verificáveis por máquina. Uma verificação no navegador de seis sinais não compete com isso, e a ferramenta deste artigo diz isso na sua própria página: é o teste rápido que executa sobre toda uma biblioteca de documentos numa tarde, para descobrir a que ficheiros faltam os básicos, não a certificação que cita.
Precisa da validação completa quando o documento é essencial (um formulário que um cliente tem de preencher, informação legal, um exame), quando um processo de aquisição ou de conformidade pede provas, quando o documento é longo e estrutural (manuais, relatórios anuais), ou sempre que os “não foi possível determinar” e as aproximações da verificação leve não bastam para a decisão que está a tomar. A correção profissional — corrigir a ordem de leitura, as tabelas e os formulários numa ferramenta dedicada, e depois validar — é uma disciplina real com um custo real, e é exatamente por isso que o teste rápido e barato ganha primeiro o seu lugar: diz-lhe para onde esse dinheiro tem realmente de ir.
Uma ordem pragmática de correções
Corrija por esta ordem, na origem sempre que possível. Primeiro, a cadeia de produção: ative a exportação de PDF etiquetado no Word, InDesign ou na sua ferramenta de relatórios, e defina o idioma e o título do documento nas propriedades do modelo — a maioria das bibliotecas de PDF falha as mesmas três verificações porque partilha um modelo avariado, por isso uma correção ao modelo volta a publicar ficheiros limpos para sempre. Segundo, os títulos: use estilos de título reais na origem e regenere os marcadores a partir deles; isto corrige as verificações 4 e 6 de uma vez. Terceiro, as imagens: escreva o texto alternativo na origem para as imagens informativas e marque as decorativas como decorativas — não preencha o alternativo em lote com nomes de ficheiros. Quarto, o atraso: faça a triagem da biblioteca existente por transferências e importância, faça o teste rápido a tudo com o verificador, corrija devidamente os documentos essenciais, e substitua ou retire a cauda longa que já não defende.
Por fim, mantenha os documentos dentro da rotina que mantém as páginas honestas. Quando um PDF novo for publicado, execute as mesmas seis verificações antes de ele ir para o ar — demora menos de um minuto — e volte a executar a verificação de saúde do site na página que o liga. As regressões de acessibilidade raramente chegam como redesenhos dramáticos; chegam como uma exportação sem etiquetas, carregada numa sexta-feira, que ninguém verificou. Os documentos fazem parte do site. Verifique-os como tal.