WCAG 1.3.1: Informações e Relacionamentos

O que Esta Regra Significa

WCAG 1.3.1 — Informação e Relações é um critério de Nível A sob o princípio Perceptível. Sua exigência central é simples, mas de grande alcance: qualquer informação ou relação que seja comunicada visualmente também deve ser expressa de uma forma que as tecnologias assistivas possam detectar e transmitir aos usuários. Se o seu design usa pistas visuais — recuo para indicar uma lista, texto em negrito para marcar um campo obrigatório, cor para indicar um erro ou tamanho para denotar um cabeçalho — essas mesmas semânticas devem existir no código subjacente.

O critério se aplica a três categorias de significado que o conteúdo da web transmite regularmente por meio da apresentação:

• Informação — fatos ou dados comunicados na página, como quais campos de formulário são obrigatórios ou quais células de tabela compartilham uma relação.
• Estrutura — o esquema organizacional do conteúdo, como hierarquias de cabeçalhos, listas ordenadas ou não ordenadas e tabelas de dados.
• Relações — associações entre elementos, como um rótulo e seu campo de entrada, um cabeçalho de tabela e suas células de dados, ou um termo e sua definição.

Uma página atende ao critério 1.3.1 quando cada pedaço de informação estrutural ou relacional disponível para um usuário vidente está codificado em HTML semântico válido ou exposto por meio de uma função, propriedade ou estado ARIA correto que as tecnologias assistivas possam interpretar. Uma página falha quando a estrutura visual existe apenas em CSS ou imagens, ou quando a marcação ARIA contradiz ou está ausente da estrutura DOM apresentada.

As exceções oficiais são mínimas. O critério não exige que toda decoração visual tenha significado semântico — formatação puramente estética, como uma borda decorativa ou cor de fundo, não precisa de um equivalente programático. No entanto, qualquer formatação que um usuário razoavelmente interpretaria como portadora de significado (asteriscos de obrigatório, termos em negrito em um glossário, etapas numeradas) deve ter uma expressão programática correspondente.

Por Que Isso Importa

Informações e relações sustentam quase todas as interações que um usuário tem com uma página da web. Quando essa estrutura fica trancada apenas na apresentação visual, uma parte significativa da população é efetivamente excluída de compreender o conteúdo.

Usuários de leitores de tela — geralmente pessoas cegas ou com baixa visão — navegam pelas páginas consultando a árvore de acessibilidade, que é construída a partir de HTML semântico e ARIA. Quando um desenvolvedor usa uma <div> estilizada para parecer um cabeçalho em vez de um <h2> real, um usuário de leitor de tela que pula entre cabeçalhos com a tecla H irá ignorá-lo completamente. Essa pessoa pode nunca encontrar a seção que o cabeçalho introduz. De acordo com a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo vivem com algum tipo de deficiência visual, e dezenas de milhões dependem de leitores de tela diariamente.

Usuários com deficiências cognitivas se beneficiam igualmente de uma estrutura clara. Cabeçalhos devidamente aninhados, marcação de lista significativa e controles de formulário rotulados reduzem a carga cognitiva ao fornecer padrões previsíveis. Um leitor de tela anunciando "cabeçalho nível 2, Produtos" seguido de "cabeçalho nível 3, Laptops" fornece um mapa cognitivo da página. Uma parede plana de texto estilizado sem âncoras estruturais é desorientadora para todos, mas especialmente para usuários com desafios de atenção ou memória.

Usuários com deficiência motora que dependem de navegação por teclado, acesso por varredura ou software de controle por voz também dependem da estrutura programática. Softwares de controle por voz como Dragon NaturallySpeaking geram alvos clicáveis a partir de nomes acessíveis derivados de rótulos e funções — campos de formulário sem rótulos associados simplesmente não podem ser direcionados de forma confiável por comando de voz.

Considere um cenário concreto: o portal de pacientes de um hospital exibe uma tabela de consultas futuras. A tabela usa alinhamento visual e cor de fundo para associar datas a médicos, mas os elementos <th> não têm atributos scope e as células de dados não fazem referência aos cabeçalhos. Um usuário cego com um leitor de tela ouve valores de células isolados — "9:00 AM", "Dr. Ayşe Kaya", "Cardiology" — sem ter como saber qual valor pertence a qual coluna. Essa pessoa pode interpretar mal o horário da consulta ou aparecer no departamento errado. O uso correto de scope='col' nos cabeçalhos e de atributos headers nas células teria tornado as relações audíveis.

Além da acessibilidade, HTML estrutural traz valor significativo para SEO. Rastreadores de mecanismos de busca usam hierarquias de cabeçalhos para entender os tópicos da página, marcação de listas para identificar conteúdo enumerado e associações de rótulos para entender a finalidade de formulários. Uma página que atende ao critério 1.3.1 quase sempre é uma página que os mecanismos de busca conseguem analisar e classificar com mais precisão.

Regras Relacionadas do Axe-core

As seguintes regras do axe-core mapeiam diretamente para violações da WCAG 1.3.1. Cada regra aborda um aspecto específico da estrutura ou relação programática:

• aria-required-children — Verifica se elementos com determinadas funções ARIA contêm as funções filhas exigidas. Por exemplo, um role='list' deve conter filhos com role='listitem'. Sem a estrutura filha correta, a relação entre um contêiner e seus itens é quebrada para as tecnologias assistivas.
• aria-required-parent — O inverso da regra acima: verifica se elementos com funções que exigem um contexto de pai específico realmente têm esse pai. Um role='listitem' que não está dentro de um role='list' ou de um <ul>/<ol> é sinalizado porque o contexto relacional está ausente.
• aria-roles — Valida se todos os valores do atributo role são funções ARIA válidas. Uma função inválida ou escrita incorretamente (por exemplo, role='heading' em vez de usar um elemento de cabeçalho, ou uma função completamente inventada) significa que a tecnologia assistiva não recebe informação útil e pode ignorar o elemento completamente.
• definition-list — Verifica se elementos <dl> contêm apenas filhos permitidos: <dt>, <dd>, <div>, <script> e <template>. Inserir outros elementos como <p> diretamente dentro de um <dl> invalida a estrutura de relação termo-definição.
• dlitem — Verifica se elementos <dt> e <dd> são usados apenas dentro de elementos <dl>. Usar esses elementos fora de seu contexto de pai exigido destrói o significado semântico do par termo-definição.
• heading-order — Sinaliza níveis de cabeçalho que são pulados no esboço do documento (por exemplo, pular de <h2> para <h4>). Embora nem sempre seja uma falha estrita, pular níveis induz as tecnologias assistivas a erro quanto à estrutura hierárquica da página e confunde usuários que navegam por cabeçalhos.
• label — Verifica se todo campo de formulário tem um rótulo associado programaticamente, seja via <label for='...'>, aria-label, aria-labelledby ou um elemento <label> que o envolva. Um campo sem rótulo acessível nega a usuários cegos e usuários de controle por voz a informação de que precisam para entender o que inserir.
• list — Garante que elementos <ul> e <ol> contenham apenas elementos <li> como filhos diretos (além de <script> e <template>). Elementos filhos inválidos quebram a estrutura de lista que leitores de tela usam para anunciar contagens e posições de itens.
• listitem — Verifica se elementos <li> são usados apenas dentro de contêineres <ul>, <ol> ou role='list'. Itens de lista órfãos perdem completamente seu significado semântico.
• scope-attr-valid — Valida se o atributo scope em elementos <th> contém apenas os valores permitidos: col, row, colgroup ou rowgroup. Um valor de escopo inválido ou ausente em uma tabela de dados complexa significa que leitores de tela não podem anunciar de forma confiável qual cabeçalho se aplica a uma determinada célula de dados.
• td-headers-attr — Verifica se, quando células de dados usam o atributo headers, cada ID referenciado realmente existe na mesma tabela e pertence a uma célula de cabeçalho. Referências quebradas ou ausentes cortam a relação programática entre os dados e seu cabeçalho descritivo, deixando usuários de leitores de tela sem contexto.

Observe que ferramentas automatizadas como o axe-core não conseguem detectar todas as violações do critério 1.3.1. Por exemplo, um desenvolvedor pode usar uma <div> estilizada visualmente com role='list' e elementos filhos role='listitem' corretamente estruturados — o axe irá aprovar isso — mas um testador humano pode descobrir que o recuo visual implica uma sublista aninhada que não está representada na estrutura ARIA. Sempre que a hierarquia visual for complexa, inspeção manual e testes com leitores de tela são complementos essenciais à varredura automatizada.

Como Testar

1. Varredura automatizada com axe DevTools ou Lighthouse: Instale a extensão de navegador axe DevTools (Chrome ou Firefox). Abra a página em teste, abra o DevTools, navegue até a aba do axe e execute uma varredura de página inteira. Filtre os resultados pela tag wcag131 ou revise todos os problemas marcados em "Info and Relationships". Procure especificamente por violações das onze regras do axe listadas acima. No Lighthouse (painel Audits do Chrome DevTools), execute uma auditoria de acessibilidade e verifique a categoria "Accessibility" em busca de falhas relacionadas a ordem de cabeçalhos, rótulos e listas. Anote todos os elementos sinalizados e seus seletores DOM para correção.
2. Revisão manual da estrutura de cabeçalhos: Use a extensão de navegador HeadingsMap ou o painel "Headings" no axe DevTools para visualizar o esboço completo de cabeçalhos da página. Verifique se o esboço é lógico e hierárquico — ele deve se ler como um sumário bem estruturado. Confirme que nenhum nível de cabeçalho é pulado e que o texto dos cabeçalhos é significativo e não apenas estilização visual aplicada a elementos que não são cabeçalhos.
3. Verificação de rótulos de formulários: Navegue com a tecla Tab por cada elemento de formulário interativo na página. Para cada input, select e textarea, confirme que há um rótulo visível e que ele está associado programaticamente (verifique o elemento no DevTools e procure por um par for/id correspondente, ou um aria-label/aria-labelledby). Use a árvore de acessibilidade no Chrome DevTools (painel Elements → aba Accessibility) para confirmar o nome acessível calculado para cada controle.
4. Teste com leitor de tela usando NVDA + Firefox: Inicie o NVDA e abra a página no Firefox. Pressione H para percorrer os cabeçalhos e verifique se os níveis de cabeçalho anunciados correspondem à hierarquia visual. Pressione F para mover entre campos de formulário e confirme se o rótulo de cada campo é anunciado. Pressione T para navegar por tabelas e use as setas para percorrer as células, ouvindo os anúncios de cabeçalhos. Pressione L para percorrer listas e confirmar se as contagens de itens são anunciadas.
5. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (Cmd+F5 no macOS). Abra o Rotor (Ctrl+Option+U) e inspecione Cabeçalhos, Links, Controles de Formulário e Tabelas. Confirme se todos os elementos estruturais aparecem no Rotor e se seus nomes anunciados são significativos e precisos.
6. Teste com leitor de tela usando JAWS + Chrome: Abra o JAWS e a página no Chrome. Use a Lista de Cabeçalhos do JAWS (Insert+F6) para revisar a árvore de cabeçalhos. Use Insert+F5 para campos de formulário e verificar as associações de rótulos. Navegue por tabelas com as teclas de seta e confirme se o JAWS anuncia os cabeçalhos de coluna e linha para cada célula de dados.
7. Verificação das relações de cabeçalhos de tabela: Identifique todas as tabelas de dados na página. Para tabelas simples, verifique se os elementos <th> têm atributos scope apropriados. Para tabelas complexas com cabeçalhos em vários níveis, verifique se as células de dados usam o atributo headers referenciando os valores de id corretos. Trace visualmente cada célula até seus cabeçalhos lógicos de linha e coluna e, em seguida, confirme se o mesmo caminho está representado no código.

Como Corrigir

Cabeçalhos visuais implementados como divs estilizadas — Incorreto

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Cabeçalhos visuais implementados como divs estilizadas — Correto

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Campo de formulário sem rótulo associado — Incorreto

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Campo de formulário sem rótulo associado — Correto

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Tabela de dados sem atributos scope — Incorreto

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Tabela de dados sem atributos scope — Correto

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Itens de lista usados fora de um contêiner de lista — Incorreto

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Itens de lista usados fora de um contêiner de lista — Correto

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Erros Comuns

• Usar apenas CSS font-size e font-weight para criar a aparência visual de cabeçalhos em elementos <div> ou <span>, sem nunca adicionar role='heading' e aria-level ou converter em elementos reais <h1>–<h6> — leitores de tela não conseguem descobrir esses elementos como cabeçalhos navegáveis.
• Usar texto de placeholder como único rótulo para campos de formulário, o que faz com que o rótulo desapareça assim que o usuário começa a digitar, deixando o campo sem rótulo durante toda a entrada — sempre associe campos a um elemento <label> persistente.
• Marcar campos obrigatórios com um asterisco vermelho (*) que é explicado apenas em uma legenda visual no topo do formulário, sem adicionar aria-required='true' ou incluir "obrigatório" no rótulo programático, de modo que usuários de leitores de tela recebam a mesma informação.
• Aplicar list-style: none via CSS a um <ul> sem entender que alguns leitores de tela (particularmente Safari + VoiceOver) podem então parar de anunciar o elemento como uma lista — se a semântica de lista for significativa, adicione explicitamente role='list' para preservá-la.
• Pular níveis de cabeçalho — por exemplo, colocar um <h4> diretamente após um <h2> porque o designer queria um texto menor — em vez de usar o nível de cabeçalho correto e controlar a aparência visual por meio de CSS.
• Construir tabelas de dados complexas com células mescladas (colspan/rowspan) sem adicionar o atributo headers nas células de dados, deixando usuários de leitores de tela incapazes de determinar qual cabeçalho rege uma célula mesclada ambígua.
• Usar elementos <table> para fins de layout e depois adicionar role='presentation' de forma inconsistente — algumas células ainda contêm cabeçalhos que são anunciados fora de contexto, confundindo usuários que não podem ver que a tabela é puramente decorativa.
• Envolver um par <dt>/<dd> dentro de um <p> ou <div> que é filho direto de um <dl> sem entender que apenas wrappers <div> são permitidos dentro de <dl> em HTML5, e que misturar outros elementos de bloco destrói a estrutura da lista de definições.
• Adicionar aria-labelledby em um campo de entrada que referencia um ID que não existe no DOM, ou referenciar o ID de um elemento que não contém texto — o nome acessível calculado se torna vazio e o campo fica efetivamente sem rótulo para tecnologias assistivas.
• Presumir que, porque uma página parece correta visualmente e obtém uma pontuação acima de 90 no Lighthouse, ela está em conformidade com o critério 1.3.1 — ferramentas automatizadas não conseguem detectar todas as violações estruturais, como relações de aninhamento visual que não são refletidas na hierarquia de funções ARIA, exigindo verificação manual e com leitores de tela.

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 na web alinhadas com a WCAG 2.2 para uma ampla gama de entidades que operam na Turquia. A WCAG 1.3.1 é um critério de Nível A, o que significa que se encontra no nível fundamental de conformidade — o nível mínimo aceitável de acessibilidade — e, portanto, é totalmente obrigatório para todas as entidades abrangidas pela circular.

A circular define dois prazos de conformidade. Instituições públicas — incluindo órgãos do governo central, municípios, universidades públicas e hospitais públicos — devem alcançar conformidade total de Nível A dentro de um ano da entrada em vigor da circular. Entidades do setor privado abrangidas pela regulamentação têm um prazo de dois anos para se adequar. No entanto, a obrigação não é opcional para nenhum dos grupos: a não conformidade expõe as entidades abrangidas à fiscalização regulatória e a possíveis ações de execução.

As entidades do setor privado explicitamente abrangidas pela circular incluem plataformas de comércio eletrônico, bancos e instituições financeiras, hospitais privados 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 privadas que operam sob autorização do Ministério da Educação Nacional (MoNE). Qualquer uma dessas entidades que opere um site público ou aplicativo web móvel deve garantir que o critério 1.3.1 seja atendido em todas as suas propriedades digitais.

Para fins práticos de conformidade, o critério 1.3.1 é um dos mais impactantes entre os de Nível A porque rege a estrutura fundamental da página. Um site de comércio eletrônico turco cujas páginas de categoria de produtos usem elementos <div> estilizados para cabeçalhos, cujos campos de formulário de checkout não tenham associações de rótulos ou cujo resumo de pedido seja uma tabela não estruturada sem atributos scope falharia de forma abrangente no critério 1.3.1. A correção não é apenas uma obrigação legal — ela melhora diretamente a experiência para as estimadas 700.000 ou mais pessoas cegas e com baixa visão na Turquia que dependem de tecnologias assistivas para fazer compras, usar serviços bancários, acessar cuidados de saúde e interagir com serviços governamentais online.

Recomenda-se que organizações que buscam demonstrar conformidade realizem tanto varreduras automatizadas com axe-core quanto auditorias manuais com leitores de tela cobrindo toda a extensão de seu conteúdo digital. A acessibilidade estrutural — a base que o critério 1.3.1 impõe — deve ser incorporada em sistemas de design e bibliotecas de componentes para que a conformidade seja mantida à medida que o conteúdo é criado e atualizado, em vez de ser tratada como um exercício de correção pontual.