Checklist de acessibilidade para portais de notícias: 15 pontos para avaliar

A acessibilidade de um portal de notícias não depende de um único botão, plugin ou ferramenta. Ela resulta de decisões tomadas no desenvolvimento do site, na produção editorial, no design, nos conteúdos audiovisuais e nas formas oferecidas para o público consumir a informação. Um portal pode parecer simples para uma pessoa que utiliza mouse, tela e visão sem limitações e, ao mesmo tempo, apresentar barreiras significativas para quem navega pelo teclado, usa um leitor de tela, precisa ampliar o texto, não distingue determinadas cores ou necessita de legendas. O tema também faz parte das boas práticas do jornalismo brasileiro. A acessibilidade integra os Indicadores de Compromissos com o Público do Projor. Em seu Manual de Melhores Práticas, a organização recomenda que sites jornalísticos adotem recursos como compatibilidade com leitores de tela, navegação por teclado, descrição de imagens, legendas em vídeos, ajustes de contraste e modos de leitura simplificados. Além da referência setorial do Projor, portais podem utilizar as Diretrizes de Acessibilidade para Conteúdo Web, conhecidas como WCAG, e o Modelo de Acessibilidade em Governo Eletrônico, o eMAG, como bases para planejar, implementar e testar melhorias. Este checklist ajuda a realizar uma avaliação inicial. Ele não substitui uma auditoria especializada, testes com pessoas com deficiência ou uma análise jurídica. Seu objetivo é revelar problemas frequentes e organizar as próximas ações das equipes editorial, de produto, design e tecnologia.

O que é acessibilidade digital?

Acessibilidade digital é a criação de conteúdos, páginas, sistemas e serviços que possam ser percebidos, compreendidos, navegados e utilizados por pessoas com diferentes capacidades e formas de interação. Isso inclui pessoas cegas ou com baixa visão, surdas ou com deficiência auditiva, pessoas com limitações motoras, daltonismo, dificuldades cognitivas e outras condições permanentes ou temporárias. Também beneficia usuários idosos, pessoas com uma lesão momentânea, leitores em ambientes com muito ruído e quem utiliza um aparelho ou conexão com limitações. A WCAG organiza a acessibilidade em quatro princípios. O conteúdo precisa ser perceptível, operável, compreensível e robusto. Na prática, isso significa que a informação deve estar disponível por diferentes meios, que os controles devem funcionar para diferentes formas de navegação e que o código precisa ser interpretado adequadamente por tecnologias assistivas.

Por que a acessibilidade é importante para um portal de notícias?

Notícias e informações de interesse público precisam alcançar pessoas com diferentes necessidades. Quando uma matéria não pode ser lida por um leitor de tela, um vídeo não possui legenda ou um menu só funciona com o mouse, parte da audiência encontra uma barreira antes mesmo de chegar ao conteúdo. O Manual de Melhores Práticas do Projor relaciona a adoção de recursos de acessibilidade ao compromisso do veículo com o interesse público. O documento também destaca o potencial de ampliar a audiência e fortalecer a imagem e a reputação da organização jornalística. A Lei Brasileira de Inclusão determina a obrigatoriedade da acessibilidade nos sites mantidos por empresas com sede ou representação comercial no país e por órgãos de governo, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente. Acessibilidade, portanto, não deve ser tratada somente como um recurso adicional. Ela precisa participar das decisões sobre templates, CMS, componentes, publicidade, produção de textos, imagens, vídeos e novas funcionalidades.

Como utilizar este checklist?

O ideal é avaliar diferentes tipos de página do portal. Não teste apenas a página inicial. Inclua:

• Uma matéria comum.
• Uma reportagem longa.
• Uma página com vídeo.
• Uma galeria de imagens.
• Uma página com infográfico ou tabela.
• A busca do portal.
• O formulário de cadastro ou assinatura.
• Menus, rodapé e páginas institucionais.

Para cada item, registre se o portal atende, atende parcialmente, não atende ou ainda precisa ser avaliado. Também é importante identificar quem deve participar da correção: redação, produto, design, desenvolvimento, vídeo, publicidade ou fornecedores externos.

1. A página utiliza uma estrutura semântica e uma hierarquia clara?

Títulos, subtítulos, parágrafos, listas, tabelas e regiões da página precisam ser identificados corretamente no HTML. Essa estrutura ajuda navegadores e tecnologias assistivas a entenderem o papel de cada elemento. Em uma matéria, o título principal deve ser marcado como o título mais importante. Os subtítulos precisam seguir uma ordem coerente. Menus, conteúdo principal, informações complementares e rodapé também devem possuir funções reconhecíveis. Não basta fazer uma frase parecer um título aumentando o tamanho da fonte. Para um leitor de tela, a aparência visual não substitui a marcação semântica. Como testar:

• Verifique se existe apenas um título principal para a matéria.
• Confira se os subtítulos não saltam níveis sem necessidade.
• Analise se listas e tabelas utilizam elementos HTML apropriados.
• Teste se um leitor de tela consegue navegar pelos títulos e regiões.

Erro frequente: construir toda a página com elementos genéricos e depender apenas de classes visuais para indicar sua organização.

2. O título da página e o idioma estão identificados corretamente?

Cada página precisa ter um título descritivo no navegador. Em uma matéria, ele normalmente deve informar o assunto da notícia e o nome do portal. Títulos genéricos ou repetidos dificultam a orientação de quem navega entre várias abas ou utiliza uma tecnologia assistiva. O idioma principal também deve ser informado no HTML. Quando há uma passagem relevante em outro idioma, essa mudança pode ser marcada para que o leitor de tela utilize a pronúncia apropriada. Como testar:

• Abra diferentes matérias e verifique o texto exibido na aba do navegador.
• Confirme se cada página possui um título próprio e compreensível.
• Inspecione se o português do Brasil está definido como idioma principal.
• Teste a leitura de trechos em outros idiomas quando houver mudança de língua.

Erro frequente: utilizar apenas o nome do portal como título de todas as páginas.

3. Todas as funções podem ser utilizadas apenas com o teclado?

Algumas pessoas não utilizam mouse ou tela sensível ao toque. Elas navegam com Tab, Shift + Tab, Enter, Espaço, setas e outros comandos do teclado. Menus, busca, botões, formulários, galerias, controles de vídeo, player de áudio, janelas e avisos de consentimento precisam ser acessíveis dessa forma. Nenhuma função essencial deve exigir movimentos do mouse. Como testar:

• Desconecte o mouse ou evite utilizá-lo.
• Percorra toda a página pressionando Tab.
• Abra menus e acione botões usando o teclado.
• Verifique se é possível fechar janelas, anúncios e avisos.
• Confirme se a ordem de navegação acompanha a sequência lógica do conteúdo.

Erro frequente: um menu abre quando o ponteiro passa sobre ele, mas não pode ser aberto com o teclado.

4. O foco do teclado está sempre visível?

Ao navegar com Tab, o usuário precisa saber qual link, botão ou campo está selecionado. Essa indicação é chamada de foco visível. O foco deve apresentar contraste suficiente e permanecer claramente identificável sobre diferentes fundos. Remover o contorno padrão do navegador sem oferecer uma alternativa prejudica a navegação. Como testar:

• Pressione Tab e acompanhe visualmente o elemento selecionado.
• Verifique links do cabeçalho, matéria, compartilhamento e rodapé.
• Observe o foco sobre fundos claros, escuros e imagens.
• Confira se nenhum componente encobre o elemento selecionado.

Erro frequente: o usuário consegue avançar pelo teclado, mas não enxerga onde está.

5. As imagens possuem textos alternativos adequados?

O texto alternativo, normalmente inserido no atributo alt, comunica a função ou a informação relevante de uma imagem para quem não consegue vê-la. Em uma matéria jornalística, a descrição deve considerar o contexto. Uma fotografia pode exigir a identificação das pessoas, do local e do acontecimento que ela registra. Um gráfico precisa comunicar seu dado principal. Uma imagem meramente decorativa pode ter texto alternativo vazio para não gerar ruído na leitura. O texto alternativo não deve copiar automaticamente a legenda nem começar com expressões como “imagem de”, quando essa informação já é transmitida pela tecnologia assistiva. Como testar:

• Desative as imagens ou inspecione seus atributos alternativos.
• Verifique se a informação principal continua compreensível.
• Analise fotografias, gráficos, infográficos, ícones e imagens de capa.
• Confirme se imagens decorativas não são anunciadas desnecessariamente.

Erro frequente: preencher o texto alternativo com o nome do arquivo ou com uma sequência de palavras-chave para SEO.

6. Links e botões possuem nomes compreensíveis?

Um link deve indicar seu destino ou sua função mesmo quando é lido fora do parágrafo. Expressões repetidas como “clique aqui”, “saiba mais” e “veja” podem se tornar confusas para quem acessa uma lista de links pelo leitor de tela. Botões representados apenas por ícones também precisam de nomes acessíveis. Isso vale para compartilhar, salvar, fechar, abrir menu, iniciar vídeo, reproduzir áudio e alterar a velocidade. Como testar:

• Leia somente os textos dos links e verifique se fazem sentido isoladamente.
• Teste botões de ícone com um leitor de tela.
• Confirme se links com destinos diferentes não têm nomes idênticos e vagos.
• Verifique se o nome anunciado corresponde à ação executada.

Erro frequente: o leitor de tela anuncia apenas “botão” ou “link”, sem informar sua finalidade.

7. Textos e controles possuem contraste suficiente?

O contraste entre texto e fundo influencia a leitura por pessoas com baixa visão, daltonismo, sensibilidade visual ou que utilizam a tela sob iluminação intensa. A WCAG estabelece relações mínimas de contraste para textos e elementos de interface. Como referência geral, textos comuns devem alcançar uma relação de pelo menos 4,5 para 1. Textos grandes podem utilizar uma relação mínima de 3 para 1, conforme os critérios aplicáveis. Também é importante não depender somente da cor para comunicar uma informação. Links, estados de erro, resultados positivos e categorias precisam de outro elemento identificador. Como testar:

• Utilize um medidor de contraste para textos, links e botões.
• Confira informações apresentadas em gráficos e mapas.
• Simule diferentes formas de daltonismo.
• Verifique estados de foco, passagem do mouse e campos com erro.

Erro frequente: indicar um erro apenas mudando a borda do campo de cinza para vermelho.

8. O texto pode ser ampliado sem quebrar a página?

Usuários com baixa visão podem ampliar o navegador ou alterar o tamanho e o espaçamento do texto. A página deve continuar utilizável sem esconder conteúdo, sobrepor elementos ou exigir rolagem horizontal em blocos de leitura comuns. O design responsivo precisa considerar não apenas telas menores, mas também conteúdo ampliado. Cabeçalhos fixos, anúncios e botões flutuantes podem ocupar grande parte da tela e encobrir a matéria. Como testar:

• Aumente o zoom do navegador para 200%.
• Verifique título, corpo da matéria, imagens, tabelas e formulários.
• Teste a página em uma tela estreita.
• Altere espaçamento entre linhas, letras, palavras e parágrafos.
• Confira se elementos fixos não escondem o conteúdo.

Erro frequente: o texto aumenta, mas parte dos botões desaparece ou os parágrafos ficam cobertos por publicidade.

9. A busca e os formulários possuem rótulos e mensagens claras?

Campos de busca, newsletter, login, cadastro, comentários e assinatura precisam ser compreendidos sem depender apenas de um texto temporário dentro do campo. Cada campo deve ter um rótulo associado. Instruções e mensagens de erro precisam explicar o que aconteceu e como corrigir o problema. Quando há vários erros, o usuário deve conseguir encontrá-los sem percorrer todo o formulário novamente. Como testar:

• Navegue pelos campos com o teclado e com um leitor de tela.
• Envie o formulário com informações ausentes ou incorretas.
• Verifique se o erro é anunciado e descrito em texto.
• Confirme se o foco é direcionado para uma posição útil.
• Teste campos de senha, seleção, data e consentimento.

Erro frequente: destacar o campo em vermelho sem explicar qual informação precisa ser corrigida.

10. Vídeos possuem legendas, transcrição e alternativas adequadas?

Vídeos jornalísticos precisam oferecer acesso à informação transmitida pela fala e por elementos visuais relevantes. As legendas devem representar falas, identificação de locutores e sons importantes para a compreensão. Legendas automáticas podem ajudar na produção, mas precisam ser revisadas, especialmente em nomes próprios, locais, siglas e termos técnicos. Uma transcrição pode facilitar o acesso, a consulta e a indexação do conteúdo. Quando informações essenciais aparecem apenas visualmente, pode ser necessária uma descrição textual ou audiodescrição. Como testar:

• Assista ao vídeo sem som e verifique se a informação permanece compreensível.
• Ouça sem olhar para a tela e identifique se informações visuais importantes são perdidas.
• Revise nomes, números e termos presentes nas legendas automáticas.
• Confira se o player permite ativar e configurar as legendas pelo teclado.

Erro frequente: publicar a legenda automática sem qualquer revisão editorial.

11. Áudio, vídeo e animações respeitam o controle do usuário?

Conteúdos que começam automaticamente podem desorientar o usuário, competir com um leitor de tela e dificultar a compreensão da página. Movimentos intensos ou contínuos também podem causar desconforto e impedir a concentração. O usuário deve controlar o início, a pausa, o volume e a interrupção da reprodução. Carrosséis, animações e atualizações automáticas precisam oferecer mecanismos de pausa quando aplicável. Como testar:

• Abra a página e verifique se algum som começa sem solicitação.
• Confirme se vídeos, animações e carrosséis podem ser pausados.
• Teste os controles com teclado e leitor de tela.
• Analise alertas de notícias, placares e coberturas em tempo real.

Erro frequente: iniciar automaticamente um vídeo ou anúncio com som assim que a matéria é aberta.

12. O portal funciona corretamente com leitores de tela?

Leitores de tela interpretam a estrutura e os controles da página e apresentam essas informações por voz ou por uma linha Braille. Eles não analisam o site da mesma forma que uma pessoa que enxerga sua composição visual. Uma página precisa utilizar HTML semântico, nomes acessíveis, ordem lógica de leitura e estados corretamente comunicados. O uso de ARIA pode complementar componentes quando necessário, mas não corrige uma estrutura HTML inadequada por si só. Como testar:

• Abra uma matéria com um leitor de tela conhecido.
• Navegue por títulos, regiões, links, botões e formulários.
• Confirme se atualizações e janelas são anunciadas no momento correto.
• Verifique se a ordem falada corresponde à ordem lógica da página.
• Repita o teste em diferentes navegadores e dispositivos.

Erro frequente: considerar o site acessível porque o leitor de tela consegue ler os parágrafos, embora menus, anúncios, formulários e controles permaneçam inutilizáveis.

13. Existe uma experiência de leitura clara e sem barreiras desnecessárias?

Portais de notícias reúnem menus, recomendações, publicidade, alertas, vídeos, widgets e botões de compartilhamento. Esses elementos fazem parte do modelo editorial e comercial, mas não devem impedir o acesso ao conteúdo principal. Uma experiência de leitura simplificada pode reduzir distrações, organizar o texto e facilitar o consumo por pessoas com dificuldades visuais, cognitivas ou de concentração. Mesmo sem um modo separado, a página deve apresentar boa hierarquia, linhas de tamanho confortável, espaçamento adequado e distinção clara entre matéria, publicidade e conteúdos relacionados. Como testar:

• Identifique se o início e o fim da matéria são claros.
• Verifique se anúncios interrompem frases ou encobrem parágrafos.
• Analise o volume de elementos simultâneos na tela.
• Confira se conteúdos patrocinados estão claramente identificados.
• Teste a leitura em celular e com ampliação.

Erro frequente: inserir tantos elementos flutuantes e interrupções que o usuário perde a continuidade da matéria.

14. O portal oferece alternativas para consumir as matérias, como áudio?

Oferecer mais de uma forma de acesso ao conteúdo amplia as possibilidades de consumo. Uma versão em áudio pode beneficiar pessoas com baixa visão, dificuldades de leitura, dislexia, pessoas idosas e usuários que preferem ouvir enquanto realizam outra atividade. O player precisa ser acessível. Seus controles devem funcionar pelo teclado, apresentar nomes compreensíveis para leitores de tela e permitir ações como reproduzir, pausar e alterar a velocidade. O áudio não deve começar automaticamente. É importante compreender que um player de áudio não substitui o leitor de tela. O leitor de tela permite navegar por menus, links, formulários e diferentes regiões do site. O player transforma o conteúdo selecionado, como o texto de uma matéria, em uma experiência de escuta. Da mesma forma, a versão em áudio não substitui HTML semântico, textos alternativos, legendas, contraste adequado e as demais práticas deste checklist. Ela é um recurso complementar dentro de uma estratégia mais ampla. Como testar:

• Confirme se todos os controles do player funcionam pelo teclado.
• Verifique os nomes anunciados por leitores de tela.
• Analise se o usuário pode pausar e alterar a velocidade.
• Confira se menus, legendas, anúncios e textos alheios à matéria foram excluídos da leitura.
• Teste nomes próprios, siglas, números e palavras estrangeiras.

Para entender melhor essa diferença, leia também Áudio torna um site acessível? Benefícios e limites do leitor de texto. Erro frequente: instalar um botão de leitura e divulgar que o site se tornou totalmente acessível.

15. O portal testa, documenta e informa seus recursos de acessibilidade?

Uma página de acessibilidade ajuda o público a encontrar os recursos disponíveis, conhecer atalhos, entender limitações e informar problemas. O eMAG recomenda disponibilizar uma página com orientações sobre recursos como redimensionamento de texto, alto contraste, teclas de atalho e testes realizados. O portal pode publicar uma declaração de acessibilidade com linguagem clara, indicando o que já foi implementado, quais padrões orientam o trabalho, como as avaliações são feitas e qual canal recebe relatos de barreiras. A declaração precisa corresponder à realidade. Uma lista genérica copiada de outro site pode prometer recursos inexistentes e prejudicar a confiança do público. Como testar:

• Procure uma página de acessibilidade a partir do cabeçalho ou rodapé.
• Confirme se os recursos descritos realmente funcionam.
• Verifique se existe um canal acessível para comunicar problemas.
• Analise quando o portal foi testado e quais páginas participaram da avaliação.
• Inclua pessoas com deficiência nos testes sempre que possível.

Erro frequente: publicar uma declaração de conformidade sem testes suficientes ou sem informar limitações conhecidas.

Ferramentas automáticas são suficientes para avaliar a acessibilidade?

Não. Ferramentas automáticas ajudam a encontrar problemas de contraste, ausência de atributos, erros de estrutura e outras falhas detectáveis pelo código. Elas são importantes para verificações frequentes e podem participar do processo de desenvolvimento. Entretanto, diversos problemas dependem de contexto e julgamento humano. Uma ferramenta pode identificar que uma imagem possui texto alternativo, mas não consegue garantir que a descrição comunique a informação relevante. Também pode confirmar a existência de um título sem saber se ele representa adequadamente a matéria. Uma avaliação consistente combina:

• Testes automáticos.
• Navegação manual pelo teclado.
• Testes com leitores de tela.
• Revisão editorial de imagens, legendas e textos.
• Avaliação em celulares e diferentes navegadores.
• Participação de pessoas com deficiência.

Quem deve cuidar da acessibilidade no portal?

A acessibilidade não deve ficar restrita à equipe de tecnologia. Diferentes áreas controlam partes importantes da experiência.

• A redação organiza textos, títulos, links e descrições de imagens.
• A equipe de vídeo produz e revisa legendas, transcrições e descrições.
• Design define contraste, tipografia, foco e comportamento visual.
• Desenvolvimento implementa estrutura, controles e compatibilidade.
• Produto prioriza melhorias e acompanha a experiência.
• Publicidade evita formatos que bloqueiem ou desorganizem o conteúdo.
• Atendimento recebe e encaminha relatos de barreiras.

Criar responsabilidades claras evita que a acessibilidade apareça apenas no lançamento de um novo site e seja perdida em atualizações posteriores.

Como priorizar as correções encontradas?

Nem sempre será possível resolver todos os problemas ao mesmo tempo. A priorização deve considerar gravidade, frequência, alcance e importância da função afetada. Uma barreira que impede a leitura da matéria ou o uso da busca deve ter prioridade sobre um problema apenas estético. Componentes presentes em todas as páginas merecem atenção especial, pois uma única correção no template pode beneficiar milhares de conteúdos. Uma sequência possível é:

• Resolver bloqueios que impedem acesso, navegação ou conclusão de tarefas.
• Corrigir componentes compartilhados por todo o portal.
• Tratar páginas de maior audiência e serviços essenciais.
• Incorporar as melhorias ao design system e ao CMS.
• Criar orientações para que novos conteúdos já nasçam acessíveis.
• Estabelecer testes periódicos e acompanhar problemas relatados pelo público.

Checklist resumido de acessibilidade para portais de notícias

Utilize esta lista para uma verificação inicial:

• A página possui estrutura semântica e títulos organizados?
• O título da página e o idioma estão identificados?
• Todas as funções podem ser usadas somente com o teclado?
• O foco do teclado está sempre visível?
• Imagens possuem textos alternativos adequados?
• Links e botões têm nomes compreensíveis?
• Textos, controles e estados possuem contraste suficiente?
• O conteúdo continua utilizável quando ampliado?
• Busca e formulários possuem rótulos e mensagens claras?
• Vídeos oferecem legendas e alternativas para informações visuais?
• Áudios, vídeos e movimentos respeitam o controle do usuário?
• O portal funciona com leitores de tela?
• A experiência de leitura é clara e livre de barreiras desnecessárias?
• Existem alternativas de consumo, como uma versão em áudio?
• Os recursos são testados, documentados e informados ao público?

Como o ReadMe pode complementar a acessibilidade do conteúdo?

O ReadMe transforma automaticamente matérias de portais de notícias em áudio com vozes naturais em português brasileiro. A solução permite controlar quais partes da página devem ser lidas, acompanha as atualizações da matéria e oferece controles de reprodução e velocidade. Essa alternativa amplia as formas de acesso ao conteúdo sem criar uma nova tarefa para a redação. O áudio pode beneficiar usuários com diferentes preferências e necessidades, além de permitir que as notícias acompanhem o público em momentos nos quais a leitura da tela não é conveniente. O ReadMe deve fazer parte de uma estratégia que também considere leitores de tela, navegação por teclado, HTML semântico, textos alternativos, legendas, contraste e testes com usuários. Para conhecer o funcionamento da solução em operações editoriais, leia ReadMe: solução de áudio para portais de conteúdo e notícias. Se o seu portal deseja oferecer uma versão em áudio das matérias, solicite uma demonstração do ReadMe com um conteúdo real do próprio site. Fontes de referência Projor e Atlas da Notícia, Programa de Indicadores de Compromissos com o Público: https://atlas.jor.br/indicadores/ Projor, Manual de Melhores Práticas para os Indicadores de Compromissos com o Público: https://atlas.jor.br/content/files/2025/02/Manual-de-melhores-pra-ticas---Indicadores-do-Projor-1.pdf W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/ W3C, verificação inicial de acessibilidade: https://www.w3.org/WAI/test-evaluate/preliminary/ Governo Digital, Modelo de Acessibilidade em Governo Eletrônico: https://www.gov.br/governodigital/pt-br/acessibilidade-e-usuario/acessibilidade-digital/modelo-de-acessibilidade Lei Brasileira de Inclusão da Pessoa com Deficiência, Lei nº 13.146/2015: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm