Saltar para o conteúdo
Voltar aos guias
Guia Última verificação: outubro de 2026 7 min de leitura

PDF acessíveis: o que importa e quando usar HTML

Muitos sites disponibilizam ementas, tabelas de preços, formulários e brochuras em PDF. Para quem usa um leitor de ecrã, o zoom ou apenas o teclado, um PDF sem estrutura pode ser uma porta fechada. Vê aqui o que torna um PDF acessível, o que uma verificação consegue encontrar e quando uma página web é a melhor escolha.

Quando um PDF se torna uma barreira

Um PDF pode ter um aspeto perfeito e mesmo assim ser inutilizável. Um leitor de ecrã não vê o layout. Precisa de estrutura: que texto é um título, qual é uma lista, qual é uma tabela e por que ordem tudo é lido. Se essa informação faltar, o conteúdo sai como um longo fluxo de texto, na ordem errada, ou nem sai.

Problemas típicos: uma página digitalizada que é só uma imagem, um layout de duas colunas lido a direito através das duas colunas, uma tabela sem células de cabeçalho, um formulário cujos campos não têm nome e imagens sem alternativa em texto. O W3C descreve como evitar cada um destes problemas nas suas técnicas PDF para as WCAG. As técnicas são exemplos de como cumprir as WCAG, não um requisito em si.

O que torna um PDF acessível

  • Etiquetas (tags): um PDF etiquetado tem uma árvore de estrutura em que os títulos, parágrafos, listas e tabelas estão marcados como tal. Sem etiquetas, as tecnologias de apoio quase não têm com que trabalhar.
  • Ordem de leitura: a ordem das etiquetas decide o que é lido primeiro. Verifica-a sobretudo em colunas, caixas de texto e barras laterais. A ordem de tabulação das ligações e dos campos de formulário deve seguir a mesma lógica.
  • Título do documento: define um título com significado nas propriedades do documento e faz com que o visualizador o mostre em vez do nome do ficheiro.
  • Idioma do documento: define o idioma principal, para que o leitor de ecrã use a pronúncia certa. Marca à parte as passagens noutro idioma.
  • Texto alternativo para figuras: as imagens informativas recebem uma alternativa em texto na sua etiqueta de figura. As imagens puramente decorativas são marcadas como artefactos, para que os leitores de ecrã as ignorem.
  • Texto real em vez de digitalizações: uma página digitalizada é uma imagem de texto. Cria o PDF a partir do ficheiro de origem sempre que possível. Se não houver nenhum, o reconhecimento de texto (OCR) transforma a digitalização em texto real. Depois verifica se todo o texto está lá e na ordem certa.
  • Cabeçalhos de tabela: as tabelas de dados são construídas com células de tabela, linha, cabeçalho e dados. As células de cabeçalho têm de estar marcadas como cabeçalhos, não apenas apresentadas a negrito.
  • Marcadores: os documentos com mais de algumas páginas recebem marcadores, de preferência criados a partir dos títulos. Ajudam toda a gente a ter uma visão geral sem folhear o ficheiro inteiro.
  • Campos de formulário: cada campo tem um nome ligado a ele de forma programática, por exemplo através da descrição (tooltip) do campo. Uma etiqueta apenas impressa ao lado do campo não chega.
Começa no ficheiro de origem
A maior parte disto é mais fácil no programa em que escreves o documento. Usa lá títulos reais, listas e linhas de cabeçalho de tabela, acrescenta texto alternativo às imagens, define o título e o idioma e exporta um PDF etiquetado. Layouts complexos podem mesmo assim sair na ordem errada e precisar de ser corrigidos num editor de PDF.

O que uma verificação automática encontra e o que não encontra

Uma ferramenta consegue ler propriedades técnicas: há um título, um idioma, uma árvore de estrutura, as figuras têm uma entrada alt? São boas primeiras perguntas, e uma resposta em falta é um resultado claro.

Uma ferramenta não consegue avaliar se um texto alternativo diz o que deve, se a ordem de leitura faz sentido, se as células certas estão marcadas como cabeçalhos ou se o reconhecimento de texto acertou em todos os números. O W3C di-lo com clareza: as ferramentas de avaliação não conseguem determinar a acessibilidade, só podem ajudar, e é necessário o juízo humano. Quatro verificações manuais levam apenas alguns minutos:

  1. 1Abre o PDF. A janela mostra um título real em vez do nome do ficheiro?
  2. 2Ouve as primeiras páginas com um leitor de ecrã ou uma função de leitura em voz alta. Os títulos, as colunas e as tabelas são lidos numa ordem que faz sentido?
  3. 3Guarda o PDF como texto. Está lá todo o texto, na ordem certa, e os números estão corretos?
  4. 4Percorre as ligações e os campos de formulário com a tecla Tab. A ordem faz sentido e cada campo anuncia o seu nome?

Quando uma página HTML é a melhor escolha

Pergunta-te o que os visitantes querem fazer com o conteúdo. Horários de funcionamento, ementas, tabelas de preços, instruções curtas e tudo o que muda com frequência funcionam normalmente melhor como página web normal. Uma página adapta-se a ecrãs pequenos e ao zoom, pode ser encontrada e ligada diretamente, e há apenas uma versão para manter atualizada.

Um PDF continua a fazer sentido para documentos que as pessoas imprimem, assinam ou arquivam, ou que têm de manter um layout fixo. Se mantiveres o PDF, disponibiliza também o conteúdo principal como página web ou, pelo menos, garante que o PDF está etiquetado e verificado.

Trabalhar com o Do4U

A ferramenta Verificar a acessibilidade do PDF lê um PDF de até 2 MB e indica o título, o idioma, as etiquetas de estrutura e as figuras sem alternativa. A ordem de leitura é sempre marcada para revisão manual, porque uma ferramenta não a consegue avaliar.

Converter documentos em HTML cria um rascunho a partir de uma página de PDF ou de uma imagem de cada vez: HTML semântico com títulos, listas e tabelas, mais texto simples. Verifica cada palavra, número e tabela com o original e repete a tarefa para cada página, pela ordem de leitura.

As duas ferramentas dão-te resultados e rascunhos. Não substituem uma revisão feita por pessoas, de preferência incluindo alguém que use um leitor de ecrã. Volta a verificar após cada nova versão do documento.

Fontes