Critérios de Sucesso WCAG · Level AAA

WCAG 3.1.4: Abreviações

WCAG 3.1.4 exige que esteja disponível um mecanismo para identificar a forma expandida ou o significado das abreviações usadas no conteúdo. Este critério garante que usuários que não estão familiarizados com abreviações, siglas ou acrônimos possam acessar seu significado completo, apoiando a compreensão de pessoas com deficiências cognitivas, falantes não nativos e usuários de leitores de tela.

O Que Esta Regra Significa

O Critério de Sucesso 3.1.4 das WCAG — Abreviações (Nível AAA) exige que sempre que uma abreviação, sigla ou acrônimo aparecer em conteúdo web, deve existir um mecanismo pelo qual as pessoas possam descobrir sua forma expandida ou significado. Uma abreviação, nos termos das WCAG, é uma forma abreviada de uma palavra, frase ou nome — isso inclui abreviações tradicionais (por exemplo, "aprox." para "aproximadamente"), acrônimos (por exemplo, "NASA" para "National Aeronautics and Space Administration") e siglas (por exemplo, "HTML" para "HyperText Markup Language").

O critério não prescreve uma técnica única obrigatória. Em vez disso, exige que exista algum mecanismo para que pessoas que encontrem uma forma abreviada desconhecida possam determinar o que ela significa. Mecanismos aceitáveis incluem expandir a abreviação no texto na primeira ocorrência (por exemplo, "HyperText Markup Language (HTML)"), usar o elemento HTML <abbr> com um atributo title que forneça a expansão, disponibilizar um glossário com link na página ou incluir a forma completa no contexto ao redor de modo que o significado seja inequívoco.

Há um acerto quando cada abreviação no conteúdo possui pelo menos um desses mecanismos: a forma completa aparece no texto ao lado ou imediatamente antes da abreviação na primeira ocorrência; o elemento <abbr> com um atributo title informativo envolve a abreviação; um glossário ou lista de definições acessível a partir da página define o termo; ou o contexto ao redor torna o significado totalmente claro, sem ambiguidade. Há uma falha quando uma abreviação aparece sem nenhum desses recursos — a pessoa vê uma forma abreviada como "MoNE" ou "SCR" sem qualquer indicação do que significa, sem tooltip, sem expansão prévia e sem glossário com link.

As WCAG incluem uma exceção restrita: se a abreviação for considerada parte da própria língua — isto é, for tão amplamente compreendida que funcione como uma palavra independente (por exemplo, "laser" ou "radar", que originalmente eram acrônimos) — então a expansão não é obrigatória. Da mesma forma, abreviações que são definidas pelos próprios termos definidos do conteúdo e usadas de forma consistente nesse contexto, com um glossário claramente acessível, são consideradas conformes. O teste-chave é sempre se uma pessoa que não conhece a abreviação consegue encontrar seu significado por meio dos mecanismos disponíveis no conteúdo.

Por Que Isso Importa

Abreviações são onipresentes em conteúdo web — portais governamentais, sistemas de saúde, plataformas de e-commerce e sites educacionais dependem fortemente de formas abreviadas. Embora familiares para especialistas de cada área, essas formas abreviadas representam barreiras significativas para vários grupos de pessoas usuárias.

Pessoas com deficiências cognitivas e de aprendizagem, como dislexia, deficiências intelectuais ou condições de déficit de atenção, podem ter dificuldade para decodificar abreviações desconhecidas, sendo obrigadas a sair da página para buscar significados ou desistindo completamente. Para pessoas com comprometimentos de memória, mesmo abreviações que já encontraram antes podem não ser retidas de forma confiável de uma sessão para outra, de modo que mecanismos na própria página fornecem um suporte contínuo fundamental.

Pessoas que usam leitores de tela — incluindo pessoas cegas ou com baixa visão severa — são diretamente afetadas porque leitores de tela podem pronunciar abreviações foneticamente de maneiras confusas ou sem sentido. Por exemplo, um leitor de tela pode pronunciar "SCR" como uma sequência de letras sem sentido em vez de "Sustainable Corporate Responsibility". Quando o elemento <abbr> é usado corretamente com um atributo title, certas configurações de leitores de tela podem falar a expansão completa em vez da sigla, melhorando dramaticamente a compreensão. De acordo com a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, uma grande proporção das quais depende de tecnologia assistiva para acessar conteúdo digital.

Pessoas que não são falantes nativas são outro grupo afetado. Uma pessoa usuária turca lendo um documento técnico em inglês — ou uma pessoa que fala inglês navegando em um portal governamental turco — pode ser proficiente no idioma e ainda assim ser totalmente desconhecedora de abreviações específicas de um domínio ou cultura. Fornecer expansões respeita a diversidade de origens e bases de conhecimento das pessoas usuárias.

Considere um cenário concreto: uma paciente que visita o portal online de um hospital lê seu relatório diagnóstico e encontra "KOAH" sem qualquer expansão. Uma pessoa médica turca reconhece imediatamente isso como "Kronik Obstrüktif Akciğer Hastalığı" (Chronic Obstructive Pulmonary Disease), mas uma paciente ou cuidadora sem familiaridade com terminologia médica fica sem entender o próprio diagnóstico. Fornecer a expansão — seja em linha na primeira ocorrência ou por meio de um elemento <abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr> — transforma um termo confuso em informação compreensível e apoia a tomada de decisões informadas.

Além da acessibilidade, há benefícios mensuráveis de usabilidade e SEO. Mecanismos de busca indexam as formas expandidas de abreviações, melhorando a encontrabilidade do conteúdo para pessoas que pesquisam usando termos completos. Linguagem clara e inequívoca também reduz solicitações de suporte, aumenta as taxas de conclusão de tarefas e fortalece a confiança de pessoas usuárias em diferentes níveis de letramento.

Regras Relacionadas do Axe-core

O critério 3.1.4 das WCAG exige testes manuais porque nenhuma ferramenta automatizada consegue determinar de forma confiável se uma determinada abreviação está adequadamente explicada no contexto de uma página. Varreduras automatizadas podem detectar a presença de elementos <abbr>, mas não podem julgar se todas as abreviações em uma página receberam uma expansão acessível. Abaixo está um resumo do contexto relevante do axe-core:

  • Teste manual obrigatório (sem regra dedicada no axe-core): O axe-core não inclui uma regra automatizada específica para a WCAG 3.1.4. Isso ocorre porque determinar quais sequências de texto constituem abreviações, se elas são adequadamente expandidas em algum lugar da página e se um glossário com link é acessível exige julgamento humano e leitura contextual. Uma ferramenta automatizada não consegue distinguir entre "IT" (Information Technology), "it" (o pronome) e "It" (um nome próprio) sem compreensão profunda de linguagem natural. Pessoas testadoras devem ler manualmente o conteúdo da página, identificar todas as abreviações, acrônimos e siglas e, em seguida, verificar se cada uma possui um mecanismo de expansão acessível.
  • Verificação relacionada — <abbr> sem title: Embora não seja uma regra independente do axe-core mapeada para 3.1.4, algumas ferramentas de lint de acessibilidade e extensões de navegador sinalizam elementos <abbr> que não possuem um atributo title como um aviso de boa prática. Se você usar <abbr> como seu mecanismo de expansão, o atributo title deve estar presente e conter a expansão completa; um title vazio ou ausente frustra o propósito do elemento e constituiria uma falha sob este critério.

Como Testar

  1. Base de varredura automatizada: Execute o axe DevTools ou o Lighthouse na página. Embora nenhuma das ferramentas tenha uma regra dedicada para 3.1.4, o axe DevTools pode exibir avisos de boas práticas sobre elementos <abbr> sem atributos title. Anote esses pontos de partida, mas entenda que eles não identificarão abreviações que não usam marcação <abbr> de forma alguma.
  2. Auditoria manual de conteúdo: Leia todo o conteúdo da página — incluindo cabeçalhos, corpo do texto, tabelas, rótulos de formulários, rótulos de botões, itens de navegação e texto do rodapé. Destaque cada palavra ou sequência de caracteres que possa ser uma abreviação, sigla ou acrônimo. Para cada uma, verifique se: (a) foi expandida anteriormente na mesma página; (b) está envolvida em um elemento <abbr> com um title não vazio; (c) a página contém um link para um glossário que a define; ou (d) o contexto ao redor torna seu significado inequívoco.
  3. Verificação com leitor de tela usando NVDA + Firefox: Abra a página no Firefox com o NVDA ativo. Navegue pelo conteúdo usando as teclas de seta. Quando o NVDA encontrar um elemento <abbr> com um title, ele deve anunciar o texto do title. Verifique se as expansões estão sendo apresentadas. Observe que o comportamento do NVDA com atributos title em elementos <abbr> pode variar conforme a versão e as configurações — teste primeiro com a configuração padrão do NVDA.
  4. Verificação com leitor de tela usando VoiceOver + Safari (macOS/iOS): Ative o VoiceOver e navegue pela página. O VoiceOver no macOS lê atributos title em elementos <abbr>. Use VO+A para ler a página de forma linear e ouça se as abreviações recebem suas expansões. No iOS, deslize pelo conteúdo e verifique o mesmo comportamento.
  5. Verificação com leitor de tela usando JAWS + Chrome: Com o JAWS ativo, navegue pela página usando as teclas de seta. O JAWS trata <abbr title='...'> anunciando o conteúdo do title. Teste se a expansão é lida corretamente em voz alta para cada abreviação marcada.
  6. Verificação visual e por teclado de tooltips de expansão: Se a implementação depender de padrões de tooltip em CSS ou tooltips acionados por JavaScript vinculados a estados de hover em <abbr>, use a tecla Tab para ir até o elemento (ou focalize-o programaticamente) e verifique se o tooltip aparece. As WCAG exigem que o mecanismo seja acessível, não apenas acessível por mouse — um tooltip que aparece apenas no hover falha para pessoas que usam teclado.
  7. Verificação de link para glossário: Se a página depender de um glossário com link, siga o link e confirme se cada abreviação usada no conteúdo de origem possui uma entrada correspondente com uma definição clara. Verifique se o link para o glossário está em posição de destaque e é acessível por teclado.

Como Corrigir

Abreviação não marcada na primeira ocorrência — Incorreto

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

Abreviação não marcada na primeira ocorrência — Correto

<!-- Expand on first use inline, then use abbr for subsequent references -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

Elemento abbr sem atributo title — Incorreto

<!-- abbr element present but title is missing — provides no expansion -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

Elemento abbr sem atributo title — Correto

<!-- title attribute supplies the full expansion for assistive technologies -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

Tooltip apenas em hover para abreviação — Incorreto

<!-- CSS tooltip only appears on mouse hover; keyboard users and touch users cannot access it -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

Tooltip apenas em hover para abreviação — Correto

<!-- Using abbr with title ensures the expansion is available to all users,
     including keyboard and screen reader users, without relying on hover -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

Abreviação em cabeçalho de tabela sem expansão — Incorreto

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

Abreviação em cabeçalho de tabela sem expansão — Correto

<!-- abbr with title inside th provides context for all users, including screen reader users -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

Erros Comuns

  • Usar <abbr> sem atributo title: Envolver texto em tags <abbr> por si só não fornece valor semântico nem expansão — o atributo title é obrigatório para que o elemento cumpra seu propósito de acessibilidade sob este critério.
  • Expandir uma abreviação apenas após sua primeira ocorrência: Se uma abreviação aparecer antes de sua expansão na ordem de leitura (por exemplo, em um cabeçalho antes do parágrafo de corpo que a expande), pessoas que encontrarem o cabeçalho primeiro não terão mecanismo para entendê-la naquele momento. Sempre expanda na primeira ocorrência ou antes dela.
  • Confiar exclusivamente em tooltips acionados por hover de mouse: Tooltips em CSS ou JavaScript que aparecem apenas em :hover são inacessíveis para pessoas que usam apenas teclado, pessoas em telas sensíveis ao toque e a maioria das configurações de leitores de tela. O padrão <abbr title> é preferível, ou os tooltips também devem ser acionados em :focus.
  • Fornecer um glossário com link, mas tornar o link difícil de encontrar: Se o seu mecanismo de expansão for um glossário, o link deve ser claramente rotulado, estar em posição de destaque e ser acessível por teclado. Esconder um link para glossário no rodapé em texto pequeno ou atrás de uma seção recolhida pode não satisfazer o requisito de um mecanismo utilizável.
  • Expandir abreviações de forma inconsistente — apenas algumas ocorrências marcadas: Se você usar <abbr title> para um acrônimo em uma seção, mas deixar ocorrências soltas em outras partes da mesma página, pessoas que navegam diretamente para essas seções via busca ou landmarks encontrarão formas abreviadas sem explicação.
  • Pressupor que todas as abreviações são universalmente compreendidas: Abreviações específicas de domínio que são óbvias para profissionais ("EBITDA" em finanças, "API" em desenvolvimento de software, "BKT" em contextos governamentais turcos) podem ser completamente opacas para pessoas fora desses domínios, incluindo pessoas que usam tecnologia assistiva ou que visitam a página pela primeira vez.
  • Colocar a expansão apenas no texto alternativo de imagens em vez de no texto: Se uma abreviação aparecer no texto alternativo de uma imagem como expansão, mas o texto visível mostrar apenas a abreviação, o mecanismo pode não ser acessível a todas as pessoas (por exemplo, quem usa modos de leitura do navegador). As expansões devem estar disponíveis no texto programático do próprio documento.
  • Usar valores de title incorretos ou abreviados: O atributo title de um elemento <abbr> deve conter a expansão completa, não outra abreviação ou uma explicação parcial. Escrever title='HTML lang' em vez de title='HyperText Markup Language' não satisfaz o critério.
  • Não considerar abreviações em conteúdo dinâmico: Conteúdo carregado via AJAX, rolagem infinita ou roteamento de aplicações de página única pode introduzir novas abreviações após o carregamento inicial da página. Qualquer conteúdo dinâmico injetado no DOM também deve estar em conformidade — abreviações em seções renderizadas dinamicamente precisam dos mesmos mecanismos de expansão que o conteúdo estático.
  • Tratar acrônimos que se tornaram palavras comuns como sempre isentos: A exceção para abreviações que funcionam como palavras ("laser", "radar") é restrita. Termos como "URL" ou "PDF" são muito conhecidos em contextos de pessoas com familiaridade tecnológica, mas ainda podem ser opacos para pessoas idosas, pessoas com deficiências cognitivas ou pessoas de diferentes contextos culturais. Em caso de dúvida, forneça a expansão — isso nunca prejudica quem já conhece o termo.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece obrigações obrigatórias de acessibilidade digital alinhadas às WCAG 2.2. A circular abrange uma ampla gama de tipos de entidades: instituições públicas e órgãos governamentais em todos os níveis, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens licenciadas, empresas de transporte privadas e escolas particulares autorizadas pelo Ministério da Educação Nacional (MoNE).

A circular determina conformidade principalmente no Nível AA das WCAG 2.2. O critério 3.1.4 das WCAG — Abreviações — é um critério de Nível AAA e, portanto, não é um requisito legal direto sob o texto atual da Circular Presidencial 2025/10. No entanto, a conformidade de Nível AAA não é apenas aspiracional — ela carrega peso prático e reputacional significativo no cenário digital turco.

Para entidades do setor público, hospitais e instituições educacionais que atendem populações diversas — muitas das quais podem ter familiaridade limitada com abreviações burocráticas ou médicas — implementar o 3.1.4 é uma questão de verdadeira qualidade de serviço. A linguagem administrativa e jurídica turca é rica em siglas ("SGK" para Sosyal Güvenlik Kurumu, "KDV" para Katma Değer Vergisi, "ÖTV" para Özel Tüketim Vergisi) que são naturais para funcionárias e funcionários, mas confusas para o público em geral, especialmente pessoas idosas, pessoas em áreas rurais ou visitantes de primeira viagem de um portal.

Bancos, operadoras de telecomunicações e plataformas de e-commerce sujeitas à circular fortaleceriam sua postura de acessibilidade — e a confiança em suas marcas — ao expandir abreviações usadas em descrições de produtos financeiros, resumos de contratos, tabelas de tarifas e termos de serviço. Documentos financeiros em particular são densos em abreviações que podem obscurecer informações críticas de consumidoras e consumidores que precisam tomar decisões informadas.

Organizações que buscam uma declaração formal de conformidade com as WCAG 2.2 AAA — seja para demonstrar liderança de mercado, atender a requisitos de contratação de parceiras e parceiros internacionais ou cumprir expectativas de contratos especializados em saúde pública ou educação — devem implementar o 3.1.4 como prática padrão. O SDK de overlay da Accsible apoia equipes na implementação e auditoria de padrões de expansão de abreviações e pode ser configurado para apresentar orientações durante fluxos de trabalho de autoria de conteúdo, ajudando organizações a manter conformidade em conteúdo atualizado dinamicamente em escala.