WCAG 1.3.6: Identificar a finalidade

O Que Esta Regra Significa

\n

WCAG 1.3.6 — Identificar Propósito é um critério de nível AAA sob o Princípio 1 (Perceptível) que estende os requisitos existentes de estrutura e semântica para um nível mais fino de granularidade. Especificamente, exige que o propósito de cada componente de interface do usuário, ícone, região e determinados campos de entrada possa ser determinado de forma programática — ou seja, que a informação semântica seja exposta de uma forma que navegadores, extensões de navegador e tecnologias assistivas possam ler e agir com base nela.

\n

O critério se baseia diretamente em 1.3.1 (Informações e Relacionamentos) e 1.3.5 (Identificar Propósito da Entrada). Enquanto 1.3.5 se concentra em campos de entrada de dados pessoais comuns (nome, e-mail, telefone etc.), 1.3.6 amplia o requisito para todas as regiões e componentes da interface do usuário, incluindo marcos de navegação, ícones, botões e widgets interativos. A ideia central é que um user agent ou ferramenta de personalização deve ser capaz de substituir a apresentação padrão — trocando rótulos de texto por símbolos, simplificando uma navegação poluída ou destacando os controles mais relevantes — com base em dados de propósito legíveis por máquina incorporados na marcação.

\n

Em termos práticos, uma página atende a 1.3.6 quando usa elementos de marco do HTML5 (como <header>, <nav>, <main>, <aside>, <footer> e <section>), aplica funções de marco ARIA apropriadas quando elementos de marco não são usados, expõe o propósito de ícones e outros componentes de UI não textuais por meio de nomes ou funções acessíveis e — quando aplicável — usa tokens de propósito padronizados, como os definidos na especificação W3C Personalization Semantics (anteriormente conhecida como proposta COGA Semantics), por exemplo por meio do vocabulário de atributos aui-.

\n

Uma página falha quando suas regiões são implementadas como contêineres genéricos <div> ou <span> sem função semântica, quando ícones carregam significado mas não têm nome acessível ou semântica de suporte, ou quando componentes interativos não fornecem nenhuma pista programática sobre sua função além de sua aparência visível. Aplica-se uma exceção oficial: o requisito só se aplica a conteúdo implementado usando tecnologias com suporte para identificar o significado esperado. Se não existir tecnologia ou especificação de suporte para um tipo de componente específico em uma determinada stack tecnológica, o critério não pode ser razoavelmente aplicado a esse componente.

\n\n

Por Que Isso Importa

\n

Os principais beneficiários da WCAG 1.3.6 são pessoas com deficiências cognitivas e de aprendizagem, incluindo dislexia, transtornos de déficit de atenção, condições do espectro autista, comprometimentos de memória e deficiências intelectuais. De acordo com a Organização Mundial da Saúde, aproximadamente 1 em cada 6 pessoas no mundo — mais de um bilhão de indivíduos — vive com algum tipo de deficiência significativa, e deficiências cognitivas representam um dos maiores e mais desassistidos grupos. Muitos desses usuários têm dificuldades com estruturas de navegação complexas, menus de texto densos e controles apenas com ícones que não fornecem nenhum ponto de referência semântico.

\n

Considere um cenário concreto: uma pessoa com dislexia severa depende de uma extensão de navegador que substitui rótulos de navegação padrão por conjuntos de símbolos pessoais — ícones baseados em imagens de um quadro de comunicação que ela usa no dia a dia. Para que essa substituição funcione, a extensão precisa ser capaz de determinar que um determinado <div> é na verdade um marco de navegação, que um ícone de estrela representa “adicionar aos favoritos” e que uma seta circular representa “atualizar”. Sem um propósito determinável de forma programática, a extensão não tem em que se apoiar e a substituição falha silenciosamente, deixando a pessoa com uma interface que ela não consegue interpretar.

\n

Pessoas com deficiência motora que dependem de ferramentas de acesso por varredura ou controle por voz também se beneficiam significativamente, porque ferramentas cientes de propósito podem gerar sobreposições de atalhos ou mapeamentos de comandos de voz apenas para controles cuja função é legível por máquina. Pessoas cegas que interagem por meio de leitores de tela se beneficiam de regiões de marco claramente rotuladas, o que lhes permite pular diretamente para o conteúdo de <main> ou ignorar navegação repetitiva. Pessoas com baixa visão que usam zoom do navegador ou folhas de estilo personalizadas se beneficiam da estrutura de marcos porque ela permite que o navegador reorganize o conteúdo de forma previsível.

\n

Além da acessibilidade, implementar as semânticas exigidas por 1.3.6 gera benefícios mensuráveis de SEO. Rastreadores de mecanismos de busca usam marcação de marcos e schema para entender a estrutura da página, indexar hierarquias de conteúdo e gerar rich results. Uma página bem estruturada, com regiões de marco significativas, tem mais probabilidade de obter featured snippets e pontuações de relevância mais altas. Há também um dividendo de usabilidade direto: páginas com estrutura semântica clara são mais fáceis de manter, testar e ampliar por equipes de desenvolvimento, reduzindo a dívida técnica de longo prazo.

\n\n

Regras Relacionadas do Axe-core

\n

WCAG 1.3.6 exige testes manuais além de quaisquer verificações automatizadas. Ferramentas automatizadas podem verificar a presença de marcação semântica, mas não podem determinar se essa marcação transmite de forma precisa e completa o propósito de cada componente como uma pessoa avaliadora faria. As seguintes regras do axe-core são estreitamente relacionadas e servem como proxies automatizados para aspectos deste critério:

\n

\n
• region — Verifica se todo o conteúdo da página está contido dentro de uma região de marco. Ela sinaliza conteúdo que fica fora de qualquer elemento de marco reconhecido ou função de marco ARIA. Embora essa regra não teste a precisão da identificação de propósito, ela garante que a base estrutural exigida por 1.3.6 esteja presente. Uma falha significa que conteúdo significativo está invisível para a navegação baseada em marcos.
\n
• landmark-one-main — Verifica se a página contém exatamente um elemento <main> ou elemento com role='main'. Isso é fundamental para 1.3.6 porque a área de conteúdo principal é uma das regiões mais críticas cujo propósito deve ser identificável. Múltiplos marcos <main> ou a ausência deles tornam impossível para ferramentas de personalização isolar o conteúdo principal.
\n
• landmark-complementary-is-top-level — Verifica se elementos <aside> ou regiões com role='complementary' não estão aninhados dentro da área de conteúdo principal de uma forma que deturpe seu propósito. Aninhamento incorreto induz tecnologias assistivas ao erro quanto ao relacionamento entre regiões.
\n
• aria-allowed-role e aria-valid-attr-value — Sinalizam atribuições de funções ARIA inválidas ou inadequadas. Como 1.3.6 depende de semântica de função precisa, usar uma função incorreta (por exemplo, role='navigation' em um grupo de botões) prejudica ativamente a identificação de propósito, e essas regras vão evidenciar tais incompatibilidades.
\n
• button-name e link-name — Verificam se controles interativos têm nomes acessíveis. Botões e links apenas com ícones, sem nomes acessíveis, são um modo de falha primário para 1.3.6, já que nenhum propósito pode ser determinado para um controle sem nome. Essas regras sinalizam a ausência de aria-label, aria-labelledby ou texto visível.
\n

\n

Testes manuais são necessários porque ferramentas automatizadas não conseguem avaliar se os tokens de propósito escolhidos ou as funções semânticas representam com precisão a função real do componente dentro do contexto da aplicação. Um botão pode ter um nome acessível e uma função ARIA válida, mas ainda assim falhar em 1.3.6 se o nome for enganoso ou se a função não refletir o que o controle realmente faz.

\n\n

Como Testar

\n

\n
1. Execute uma varredura automatizada com axe DevTools ou Lighthouse. Abra a página no Chrome, ative a extensão axe DevTools e execute uma varredura de página inteira. Filtre os resultados pelas regras listadas acima: region, landmark-one-main, button-name e link-name. Observe quaisquer violações e suas classificações de impacto. No Lighthouse, execute uma auditoria de Acessibilidade e revise as seções de marcos e ARIA. Documente todas as falhas como linha de base, mas entenda que elas representam apenas um subconjunto da conformidade com 1.3.6.
\n
2. Inspecione manualmente a estrutura de marcos usando as ferramentas de desenvolvedor do navegador. Abra o DevTools, navegue até o painel Accessibility Tree (Chrome) ou o Accessibility Inspector (Firefox) e verifique se a página expõe uma hierarquia de marcos coerente: um <header> no nível superior, um <main>, pelo menos um <nav> (com um rótulo distintivo se houver vários) e um <footer>. Confirme que nenhuma região de conteúdo significativa está envolvida apenas em um <div> ou <span> genérico.
\n
3. Teste com NVDA e Firefox. Inicie o NVDA, abra a página no Firefox e pressione D para percorrer os marcos. Verifique se cada marco é anunciado com uma função significativa e, quando existirem vários marcos do mesmo tipo, um rótulo exclusivo. Navegue até cada botão apenas com ícone usando a tecla Tab e confirme se o NVDA anuncia um nome acessível descritivo — não uma string vazia, nome de arquivo ou rótulo genérico como “button”.
\n
4. Teste com VoiceOver e Safari (macOS/iOS). Ative o VoiceOver (Cmd+F5 no macOS). Use o Rotor (Vo+U) para abrir a lista de Marcos e verifique se todas as regiões esperadas aparecem. Percorra os controles interativos com Tab e ouça descrições significativas. No iOS, use um gesto de deslizar com três dedos para navegar por títulos e marcos e confirme se o propósito de cada região é anunciado corretamente.
\n
5. Teste com JAWS e Chrome. Abra a página no Chrome com o JAWS em execução. Pressione R para navegar pelas regiões e confirme se a função e o rótulo de cada região são precisos. Use o Cursor Virtual do JAWS para ler os botões de ícone e verificar se seu propósito é transmitido. Use a Lista de Links do JAWS (Insert+F7) para auditar todos os nomes de links quanto à sua relevância.
\n
6. Teste as semânticas de personalização (se implementadas). Se sua página usa o vocabulário W3C Personalization Semantics (por exemplo, atributos data-purpose ou aui-), use a ferramenta de teste Personalization Semantics ou uma extensão de navegador compatível para verificar se os tokens de propósito são aplicados corretamente e legíveis por máquina por user agents que suportam a especificação.
\n
7. Conduza uma auditoria de propósito componente por componente. Para cada componente interativo e ícone na página, pergunte: é possível determinar o propósito deste componente sem contexto visual? Se remover todo o CSS e imagens ainda deixar o propósito do componente claro apenas a partir do DOM e dos atributos ARIA, ele passa. Se o propósito for transmitido apenas visualmente, ele falha.
\n

\n\n

Como Corrigir

\n\n

Regiões div genéricas sem marcos — Incorreto

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Regiões div genéricas sem marcos — Correto

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Botão apenas com ícone sem nome acessível — Incorreto

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Botão apenas com ícone sem nome acessível — Correto

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Múltiplos marcos de navegação sem rótulos distintivos — Incorreto

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)