Como Criar Gráficos Acessíveis que Funcionam para Todos

O problema dos gráficos

Os gráficos e diagramas são objetos inerentemente visuais. Codificam informação através da forma, da posição e da cor — três canais que são irrelevantes ou distorcidos para uma parte significativa do seu público.

Cerca de 8% dos homens têm alguma forma de deficiência na visão das cores. Os utilizadores de leitores de ecrã não recebem qualquer informação significativa de um gráfico de barras em SVG, a menos que o programador a tenha fornecido explicitamente. E os utilizadores de teclado consideram frequentemente os gráficos interativos completamente inalcançáveis.

O resultado: a visualização de dados é provavelmente a área do design web onde o fosso entre o que os utilizadores com visão experienciam e o que todos os outros experienciam é mais amplo. E é um fosso que as organizações raramente notam, porque as auditorias de acessibilidade se concentram em formulários e navegação antes de chegarem aos gráficos da página de relatórios.

Este guia aborda o que a visualização de dados acessível realmente exige — não uma lista de verificação, mas uma compreensão de por que os gráficos falham e do que fazer a esse respeito.

Por que os gráficos são particularmente difíceis

A maioria dos elementos HTML tem uma função, um nome e um estado nativos que a tecnologia de apoio compreende. Um <button> é um botão. Uma <table> é uma tabela com linhas e colunas. Um campo de formulário tem uma etiqueta.

Um gráfico renderizado como SVG ou canvas não tem nada disto. É um desenho. Os leitores de ecrã veem uma imagem (com sorte) ou absolutamente nada. O programador tem de reconstruir a camada semântica de raiz.

Ao mesmo tempo, os gráficos são frequentemente o conteúdo mais importante de uma página. Um gráfico de barras com as receitas mensais, um gráfico de linhas que acompanha o crescimento de utilizadores, um gráfico circular que decompõe a distribuição por categorias — muitas vezes é por isto que o utilizador está na página. Excluí-los de uma parte significativa dos visitantes é um problema grave, não um pequeno inconveniente.

O problema da cor: nunca dependa apenas da cor

A falha de acessibilidade mais comum em gráficos é usar a cor como a única forma de distinguir séries de dados ou categorias.

Um gráfico de linhas com quatro linhas distinguidas apenas pela cor — vermelho, azul, verde, laranja — é ilegível para muitos utilizadores com deficiência na visão das cores e completamente sem significado para quem utiliza um modo de alto contraste ou um ecrã em tons de cinzento.

A solução é a codificação redundante: use a cor mais pelo menos uma outra propriedade visual.

Gráficos de linhas: use diferentes padrões de traço juntamente com as cores (contínuo, tracejado, pontilhado, traço-ponto)
Gráficos de barras: use texturas ou padrões juntamente com as cores, ou adicione etiquetas de dados diretamente nas barras
Gráficos de dispersão: use diferentes formas de marcador (círculo, quadrado, triângulo, losango) juntamente com as cores
Gráficos circulares: adicione etiquetas de texto dentro ou junto de cada fatia — nunca dependa apenas de uma legenda

Isto enquadra-se no critério 1.4.1 Utilização da Cor (Nível A) das WCAG 2.2: a cor não pode ser o único meio de transmitir informação.

Contraste em gráficos

Os elementos visuais não textuais, como barras de gráficos, traços de linhas e pontos de dados, devem cumprir um contraste de 3:1 em relação ao fundo, segundo o critério 1.4.11 Contraste Não Textual (Nível AA). Teste a paleta dos seus gráficos com um verificador de contraste — muitas paletas de marca que parecem adequadas em áreas grandes falham este requisito em tamanhos mais pequenos.

O texto dentro dos gráficos — etiquetas de eixos, etiquetas de dados, legendas — deve cumprir os mesmos requisitos de contraste que o texto do corpo: 4.5:1 para texto normal, 3:1 para texto grande, segundo o critério 1.4.3 Contraste Mínimo.

Fornecer alternativas em texto

Todos os gráficos precisam de uma alternativa em texto que transmita os dados que apresentam. A forma exata que esta assume depende da complexidade dos dados.

Gráficos simples: texto alternativo descritivo

Para um gráfico de barras com cinco valores, um atributo alt bem escrito pode resumir a conclusão principal:

<img
  src="monthly-revenue.png"
  alt="Monthly revenue Q1 2025: Jan £42k, Feb £38k, Mar £51k,
       Apr £49k, May £56k. Steady upward trend from February onwards."
>

O texto alternativo aqui faz duas coisas: enuncia os pontos de dados e resume a conclusão principal. Não se limite a descrever o gráfico visualmente (“um gráfico de barras com receitas”). Descreva o que o gráfico comunica.

Gráficos complexos: tabelas de dados complementares

Quando um gráfico contém mais dados do que cabem num atributo alt, forneça uma tabela de dados acessível nas proximidades. Isto também serve as pessoas que preferem dados tabulares a formatos visuais. A tabela pode estar oculta por predefinição, mas deve ser alcançável:

<figure>
  <figcaption>Revenue by region, Q1 2025</figcaption>
  <svg aria-labelledby="chart-title" aria-describedby="chart-desc" role="img">
    <title id="chart-title">Revenue by region, Q1 2025</title>
    <desc id="chart-desc">Bar chart showing UK leading with £180k,
    followed by DE at £124k, FR at £98k, and NL at £71k.</desc>
    <!-- chart content -->
  </svg>
  <details>
    <summary>View as table</summary>
    <table>
      <caption>Revenue by region, Q1 2025</caption>
      <thead><tr><th>Region</th><th>Revenue</th></tr></thead>
      <tbody>
        <tr><td>UK</td><td>£180,000</td></tr>
        <tr><td>DE</td><td>£124,000</td></tr>
        <tr><td>FR</td><td>£98,000</td></tr>
        <tr><td>NL</td><td>£71,000</td></tr>
      </tbody>
    </table>
  </details>
</figure>

Padrões específicos de SVG

Os gráficos SVG renderizados inline (em vez de como ficheiros de imagem) podem tornar-se diretamente acessíveis com ARIA. Padrões principais:

Adicione role="img" ao elemento <svg>
Forneça um <title> como primeiro filho do <svg> e ligue-o com aria-labelledby
Adicione um <desc> para descrições mais longas e ligue-o com aria-describedby
Marque os elementos decorativos (linhas de grelha, marcas de escala) com aria-hidden="true" para reduzir o ruído

Nos gráficos interativos em que os utilizadores podem selecionar pontos de dados, cada elemento interativo precisa de uma função, um nome e suporte de teclado adequados.

Navegação por teclado em gráficos interativos

Se os seus gráficos são interativos — dicas ao pairar, segmentos clicáveis, seleção e zoom — devem ser totalmente operáveis por teclado, segundo o critério 2.1.1 Teclado (Nível A).

Para gráficos com muitos pontos de dados, implemente um padrão de tabindex itinerante (roving): apenas um elemento do gráfico está na sequência de tabulação de cada vez, e as teclas de seta movem-se entre os pontos de dados dentro do gráfico.

<!-- Each bar is a button, navigable with arrow keys -->
<g role="group" aria-label="Monthly revenue bars">
  <rect
    role="button"
    tabindex="0"
    aria-label="January: £42,000"
    onkeydown="handleChartKey(event)"
    ...
  />
</g>

As dicas que só aparecem ao pairar com o rato devem também aparecer com o foco do teclado. Uma dica visível apenas para utilizadores de rato é uma falha de acessibilidade.

Escolher o tipo de gráfico certo

Alguns tipos de gráfico são inerentemente mais acessíveis do que outros. Quando tem escolha:

Tipo de gráfico	Acessibilidade	Notas
Gráfico de barras	Alta	Quantidades fáceis de codificar com etiquetas; bom suporte de teclado possível
Gráfico de linhas	Alta	Use diferentes padrões de traço; anote os pontos principais
Tabela	A mais alta	A mais fácil de tornar acessível; muitas vezes a escolha certa para dados
Gráfico de dispersão	Média	Exige uma diferenciação cuidadosa dos marcadores; navegação por teclado complexa
Mapa de calor	Baixa	Dependente da cor por natureza; forneça sempre uma tabela alternativa
Circular/anel	Baixa	Difícil comparar valores; evite com mais de 3-4 segmentos

Em caso de dúvida, uma tabela bem formatada é quase sempre mais acessível do que um gráfico — e muitas vezes mais fácil de ler, independentemente de qualquer deficiência. Não use um gráfico porque parece moderno; use-o quando ajuda genuinamente os utilizadores a compreender uma tendência ou comparação mais depressa do que os dados tabulares.

Testar os seus gráficos

Os verificadores automáticos de acessibilidade conseguem detetar atributos alt em falta e alguns padrões ARIA, mas não conseguem verificar se os dados do gráfico são significativos, se a navegação por teclado funciona corretamente ou se o gráfico faz sentido para um utilizador de leitor de ecrã. Teste com:

Um leitor de ecrã (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): navegue até ao gráfico e verifique o que é anunciado
Apenas o teclado: navegue com Tab até ao gráfico e confirme que todos os elementos interativos são alcançáveis e operáveis com o teclado
Simulação de daltonismo: use as Chrome DevTools (Rendering > Emulate vision deficiency) para ver como o gráfico aparece com diferentes tipos de deficiência na visão das cores
Zoom a 200%: verifique que as etiquetas e legendas não se sobrepõem nem ficam cortadas

O nosso serviço de avaliação com leitor de ecrã testa gráficos com utilizadores reais de tecnologia de apoio — a forma mais rápida de descobrir o que os seus utilizadores realmente experienciam.