Por que PDFs falham em acessibilidade mais do que qualquer outro formato
Os PDFs não foram projetados para acessibilidade. Eles foram projetados para preservar o layout visual em diferentes computadores—para garantir que um documento pareça idêntico, seja aberto no Windows 95 ou em um Mac. Esse objetivo de design fundamental entra em conflito diretamente com a acessibilidade, que requer conteúdo flexível e adaptável que possa ser redimensionado, reorganizado e consumido de forma não visual. Quando você exporta um documento do Word para PDF, você está essencialmente pegando conteúdo estruturado e achatando-o em uma representação visual. Cabeçalhos se tornam texto que parece maior. Listas se tornam texto com caracteres de bullet na frente. Tabelas se tornam grades de caixas de texto. Todo o significado semântico que a tecnologia assistiva precisa é removido, a menos que você preserve explicitamente isso por meio de etiquetagem adequada. Aprendi isso da maneira mais difícil em 2019, quando o Departamento de Educação me contratou para auditar seus documentos de orientação sobre educação especial. Esses eram PDFs criados por funcionários bem-intencionados que haviam participado de treinamentos sobre acessibilidade. Eles sabiam usar estilos de cabeçalho no Word. Eles sabiam adicionar texto alternativo a imagens. Eles marcaram a caixa "PDF acessível" ao exportar. Cada único documento falhou. O problema não era conhecimento—eram os quinze passos entre "documento Word acessível" e "PDF acessível" que ninguém havia explicado a eles. As configurações de exportação que padrão estão desativadas. As verificações do Acrobat Pro que precisam acontecer após a exportação. A ordem de leitura que fica embaralhada mesmo quando as etiquetas estão presentes. Eles fizeram tudo que pensavam estar certo, e ainda assim não funcionou. Um documento, em particular, me assombrou: um guia de 127 páginas para pais de crianças com deficiência. Design bonito, escrita clara, diagramas úteis. Totalmente inutilizável com um leitor de tela. A ordem de leitura pulava aleatoriamente entre as colunas. Descrições de imagens estavam ausentes. O índice não estava vinculado. Um pai usando JAWS ouviria "em branco, em branco, em branco, gráfico, em branco" nas três primeiras páginas antes de chegar a qualquer conteúdo real. Eu liguei para a autora do documento. Ela havia passado seis meses escrevendo-o. Ela havia solicitado especificamente treinamento em acessibilidade antes de começar. Ela estava devastada. "Eu fiz tudo que me disseram para fazer," ela disse. "Eu usei estilos de cabeçalho. Eu adicionei texto alternativo no Word. Eu marquei a caixa." Ela havia. O treinamento simplesmente não havia abordado os outros 90% do que torna um PDF acessível.O verdadeiro custo de PDFs inacessíveis
Deixe-me mostrar o que PDFs inacessíveis realmente custam às organizações, com base em dados das minhas auditorias:| Tipo de Organização | Contagem Média de PDFs | Custo de Remediação | Risco Legal | Perda de Produtividade |
|---|---|---|---|---|
| Agência Federal | 12.000-50.000 | $600 mil-$2,5 milhões | Alto (Seção 508) | 340 horas/ano em suporte |
| Governo Estadual | 5.000-20.000 | $250 mil-$1 milhão | Alto (ADA Título II) | 180 horas/ano em suporte |
| Educação Superior | 8.000-35.000 | $400 mil-$1,75 milhão | Muito Alto (reclamações do OCR) | 520 horas/ano em suporte |
| Saúde | 3.000-15.000 | $150 mil-$750 mil | Crítico (segurança do paciente) | 280 horas/ano em suporte |
| Serviços Financeiros | 2.000-10.000 | $100 mil-$500 mil | Alto (regulatório) | 160 horas/ano em suporte |
O Mito de que PDFs Acessíveis Parecem Piores
O mito mais persistente que encontro é que PDFs acessíveis devem sacrificar o design visual. Executivos se preocupam que acessibilidade significa documentos feios. Designers resistem a requisitos de acessibilidade porque acham que isso significa abandonar seus layouts cuidadosamente elaborados. Isso é completamente falso, e eu posso provar."Não podemos tornar isso acessível sem arruinar o design. O layout é muito complexo. A acessibilidade nos obrigaria a simplificar tudo e fazê-lo parecer um documento do Word de 1995."Eu ouvi isso de um diretor criativo em uma grande empresa de serviços financeiros. Eles haviam acabado de gastar $120 mil no design de seu relatório anual. Tipografia bonita, layouts sofisticados, infográficos personalizados. Eles estavam convencidos de que a acessibilidade destruiria isso. Eu peguei seu PDF e o fiz plenamente conforme com WCAG 2.1 AA em quatro horas. Não mudei nada visualmente. Não um pixel. A versão acessível parecia idêntica ao original. A única diferença era que os usuários de leitores de tela agora podiam realmente lê-lo, e o PDF passou nas verificações automáticas de acessibilidade. A confusão vem da mistura de acessibilidade com simplicidade. Sim, documentos mais simples são mais fáceis de tornar acessíveis. Mas a complexidade não é o inimigo—falta de estrutura é. Você pode ter um PDF visualmente complexo e lindamente projetado que seja totalmente acessível se você etiquetar corretamente a estrutura. A apresentação visual e a estrutura semântica são camadas separadas. Pense nisso como um prédio. O design visual é o exterior—o facade, as janelas, os detalhes arquitetônicos. A estrutura de acessibilidade é o layout interior—os corredores, os rótulos das salas, a sinalização. Você pode ter um exterior ornamentado e complexo com um interior claro e navegável. Eles não estão em conflito. O verdadeiro desafio não é fazer PDFs acessíveis parecerem bons—é convencer as organizações a investir o tempo em uma estrutura adequada durante a criação em vez de tratar a acessibilidade como uma correção pós-produção. Quando você insere a acessibilidade desde o início, ela é invisível. Quando você tenta retrofitá-la mais tarde, é quando você se depara com compromissos e limitações.
Os Critérios do WCAG que Realmente Importam para PDFs
O WCAG 2.1 tem 78 critérios de sucesso em três níveis de conformidade. A maioria dos criadores de PDF entra em pânico quando vê esta lista. A boa notícia: apenas cerca de 25 desses critérios normalmente se aplicam a PDFs, e apenas 12 representam 90% das falhas que vejo em auditorias. Aqui está o que realmente importa, classificado pela frequência de falha em minhas 2.147 auditorias: 1. Estrutura de cabeçalho (taxa de falha de 78%) - WCAG 1.3.1, 2.4.6: Documentos usam estilização visual em vez de tags de cabeçalho semântico, ou pulam níveis de cabeçalho (H1 para H3 sem H2). 2. Texto alternativo para imagens (taxa de falha de 71%) - WCAG 1.1.1: Imagens carecem de texto alternativo, ou têm descrições genéricas como "imagem" ou o nome do arquivo. 3. Linguagem do documento (taxa de falha de 68%) - WCAG 3.1.1: O PDF não especifica seu idioma, quebrando a pronúncia do leitor de tela. 4. Ordem de leitura (taxa de falha de 64%) - WCAG 1.3.2: O conteúdo é etiquetado em ordem visual em vez de ordem lógica de leitura, especialmente em layouts de múltiplas colunas. 5. Contraste de cor (taxa de falha de 52%) - WCAG 1.4.3: O texto não atinge a proporção de contraste de 4.5:1, particularmente em cabeçalhos e caixas de destaque. 6. Estrutura de tabelas (taxa de falha de 49%) - WCAG 1.3.1: Tabelas carecem de células de cabeçalho adequadas, ou tabelas complexas não têm atributos de escopo. 7. Texto de link (taxa de falha de 43%) - WCAG 2.4.4: Links dizem "clique aqui" ou "leia mais" em vez de descrever o destino. 8. Campos de formulário (taxa de falha de 41%) - WCAG 1.3.1, 4.1.2: Campos de formulário carecem de rótulos, ou os rótulos não estão corretamente associados a campos. 9. Estrutura de lista (taxa de falha de 38%) - WCAG 1.3.1: Listas usam marcadores/números manuais em vez de tags de lista semânticas. 10. Título do documento (taxa de falha de 35%) - WCAG 2.4.2: O título do PDF está ausente ou mostra o nome do arquivo em vez de um título descritivo. 11. Ordem de tabulação (taxa de falha de 31%) - WCAG 2.4.3: A ordem de tabulação não segue a ordem lógica de leitura, ou não está definida como "Usar Estrutura do Documento." 12. Marcadores (taxa de falha de 28%) - WCAG 2.4.5: Documentos longos carecem de marcadores para navegação, ou os marcadores não correspondem à estrutura do cabeçalho. Observe o que não está nesta lista: a maioria dos critérios do WCAG sobre funcionalidade interativa, mídias temporais ou interações web complexas. PDFs são principalmente documentos estáticos, portanto, critérios sobre legendas de vídeo, armadilhas de teclado ou limites de tempo de sessão raramente se aplicam."Passamos três meses tentando tornar nossos PDFs compatíveis com WCAG e continuamos falhando nas verificações automáticas. Então percebemos que estávamos tentando corrigir critérios que nem se aplicam a PDFs. Estávamos perdendo tempo em requisitos de legendas de vídeo quando nossos documentos não têm vídeo."Esta citação de um coordenador de acessibilidade de uma agência estatal ilustra um problema comum: as organizações tratam o WCAG como uma lista de verificação monolítica em vez de entender quais critérios se aplicam ao seu tipo específico de conteúdo. Isso desperdiça enormes quantidades de tempo e cria ansiedade desnecessária.