WCAG 4.1.2: Nome, Função, Valor

A WCAG 4.1.2 exige que todos os componentes da interface do usuário tenham um nome e um papel determináveis de forma programática, e que estados, propriedades e valores possam ser lidos e definidos por tecnologias assistivas. Isso garante que leitores de tela e outras ferramentas possam identificar, descrever e interagir com precisão com cada elemento na página.

O que Esta Regra Significa

WCAG 4.1.2 — Nome, Função, Valor é um critério de sucesso de Nível A sob o princípio de Robustez. Ele exige que, para cada componente de interface de usuário — incluindo elementos de formulário, botões, links, widgets personalizados, frames e controles interativos — as três condições a seguir sejam verdadeiras:

Nome: Cada componente deve ter um nome acessível que as tecnologias assistivas possam ler em voz alta ou expor em um display em braille. O nome pode vir do conteúdo do elemento (por exemplo, o texto dentro de um <button>), de um elemento label, de um atributo aria-label, de uma referência aria-labelledby ou de um atributo title.
Função (Role): Cada componente deve ter uma função que comunique seu propósito às tecnologias assistivas. Elementos HTML nativos carregam funções implícitas (um <button> tem a função button, um <input type='checkbox'> tem a função checkbox). Widgets personalizados construídos a partir de elementos genéricos como <div> ou <span> devem declarar explicitamente uma função usando o atributo ARIA role.
Valor (Estados e Propriedades): Qualquer estado ou valor atual que seja significativo para o usuário — se uma checkbox está marcada, se um widget de divulgação está expandido, se um campo é obrigatório — deve ser exposto programaticamente para que as tecnologias assistivas possam relatá-lo e para que os usuários possam alterá-lo quando aplicável.

Um componente atende a este critério quando seu nome acessível não está vazio, sua função é válida e semanticamente apropriada, e todos os estados relevantes (como aria-checked, aria-expanded ou aria-required) são aplicados corretamente e mantidos em sincronia com a interface visual. Um componente falha quando qualquer um desses três elementos está ausente, incorreto ou fora de sincronia — por exemplo, um botão de alternância personalizado que muda de cor visualmente, mas nunca atualiza seu estado aria-pressed.

A exceção oficial das WCAG abrange componentes que são intencionalmente não expostos às APIs de acessibilidade — por exemplo, elementos puramente decorativos ou conteúdo oculto com aria-hidden='true'. No entanto, ocultar conteúdo ativo ou focável com aria-hidden (por exemplo, aplicando-o ao elemento <body>) é, em si, uma violação, porque remove todo o conteúdo da página da árvore de acessibilidade.

Por Que Isso Importa

Aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, de acordo com a Organização Mundial da Saúde. Para pessoas cegas e com baixa visão que dependem de leitores de tela como JAWS, NVDA ou VoiceOver, o nome acessível e a função de cada componente interativo são o principal — e muitas vezes único — meio de entender o que um controle faz e como usá-lo. Se um botão não tem nome acessível, um usuário de leitor de tela ouve apenas "button", sem indicação de seu propósito. Se um dropdown personalizado não tem função, o usuário não consegue distingui-lo de texto estático.

Usuários com deficiência motora que operam software por meio de acesso por varredura, ferramentas de controle por voz como Dragon NaturallySpeaking ou navegação por teclado também dependem deste critério. O software de controle por voz mapeia comandos falados ("click Submit") para nomes acessíveis. Se o nome acessível de um botão não corresponde ao seu rótulo visível, os comandos de voz falham completamente.

A acessibilidade cognitiva é igualmente relevante. Rotulagem consistente e previsível reduz a carga cognitiva para usuários com dislexia, comprometimentos de memória ou deficiências relacionadas à atenção. Quando mudanças de estado — como a abertura de um modal ou um campo de formulário se tornando obrigatório — não são anunciadas pelas tecnologias assistivas, os usuários podem ficar desorientados e incapazes de concluir tarefas.

Considere um cenário concreto do mundo real: uma plataforma de e-commerce turca exibe um botão "Add to Cart" construído como um <div> com um manipulador de clique e um ícone de carrinho de compras. Visualmente, ele parece um botão. Mas, como não possui role='button', um nome acessível e tabindex='0', um usuário de leitor de tela navegando pelo teclado não encontra nada — o elemento é completamente invisível para sua tecnologia assistiva. Ele não consegue adicionar produtos ao carrinho, sendo efetivamente excluído de toda a experiência de compra.

Além da acessibilidade, componentes devidamente nomeados e estruturados melhoram o SEO porque rastreadores de mecanismos de busca dependem de marcação semântica para entender a estrutura da página e a intenção interativa. Eles também melhoram a testabilidade, já que frameworks de testes automatizados conseguem localizar e interagir de forma mais confiável com elementos que têm funções e rótulos significativos.

Regras Relacionadas do Axe-core

As seguintes regras do axe-core estão diretamente associadas à WCAG 4.1.2. Cada uma mira uma categoria específica de falha de nome, função ou valor:

aria-allowed-attr: Verifica se os atributos ARIA aplicados a um elemento são permitidos para a função desse elemento. Por exemplo, aplicar aria-checked a um elemento com role='link' é inválido e sinalizado, porque a função link não suporta aria-checked.
aria-command-name: Garante que elementos com funções de comando ARIA (link, button, menuitem) tenham um nome acessível não vazio. Um botão apenas com ícone, sem texto de rótulo e sem aria-label, seria sinalizado aqui.
aria-hidden-body: Sinaliza o caso específico em que aria-hidden='true' foi aplicado ao elemento <body>, o que remove toda a página da árvore de acessibilidade e torna todo o conteúdo invisível para leitores de tela.
aria-input-field-name: Verifica se elementos com funções de entrada ARIA (textbox, searchbox, spinbutton, slider, combobox) têm um nome acessível. Um campo de busca personalizado construído com role='textbox' mas sem rótulo seria sinalizado.
aria-meter-name: Verifica se elementos com role='meter' têm um nome acessível, para que usuários de leitores de tela entendam qual quantidade o medidor está medindo (por exemplo, uso de armazenamento ou nível de bateria).
aria-progressbar-name: Garante que elementos com role='progressbar' tenham um nome acessível, para que os usuários saibam qual processo ou operação está em andamento em vez de ouvir apenas "progress bar".
aria-required-attr: Verifica se elementos que usam uma determinada função ARIA incluem todos os atributos exigidos pela especificação ARIA para essa função. Por exemplo, role='slider' exige aria-valuenow, aria-valuemin e aria-valuemax; omitir qualquer um deles é sinalizado.
aria-roles: Valida se todos os valores atribuídos ao atributo role são funções ARIA válidas e não abstratas. Erros de digitação, funções inventadas ou funções abstratas (como role='widget') usadas diretamente em elementos são todas sinalizadas.
aria-tooltip-name: Verifica se elementos com role='tooltip' têm um nome acessível. Um elemento de tooltip vazio não oferece valor para usuários de leitores de tela e representa uma falha de rotulagem.
button-name: Verifica se elementos <button> e elementos com role='button' têm um nome acessível não vazio. Isso captura botões de ícone sem aria-label e botões vazios usados como gatilhos decorativos.
frame-title: Exige que elementos <iframe> e <frame> tenham um atributo title não vazio descrevendo o conteúdo do frame. Sem isso, usuários de leitores de tela não conseguem determinar o propósito do conteúdo incorporado e podem não saber se devem entrar ou ignorar o frame.
input-button-name: Verifica se elementos <input> dos tipos submit, reset, button e image têm um nome acessível — seja por meio de um atributo value ou, para inputs de imagem, de um atributo alt.

É importante observar que, embora ferramentas automatizadas detectem muitas falhas de nome, função e valor, algumas violações exigem testes manuais. Scanners automatizados não conseguem verificar se um nome acessível é significativo — um botão rotulado como "click here" tecnicamente passa na verificação automatizada por ter um nome, mas falha em comunicar seu propósito real. Da mesma forma, se mudanças de estado (como aria-expanded alternando quando um menu é aberto) são anunciadas corretamente durante a interação ao vivo só pode ser confirmado por meio de testes práticos com leitores de tela.

Como Testar

Varredura automatizada com axe DevTools ou Lighthouse: Instale a extensão de navegador axe DevTools (Chrome ou Firefox) ou execute uma auditoria Lighthouse no Chrome DevTools na aba Accessibility. Ative a varredura de página inteira e filtre os resultados pela tag WCAG 4.1.2. Procure especificamente por violações de button-name, frame-title, aria-required-attr, aria-roles e aria-input-field-name. Cada achado incluirá o elemento problemático, uma descrição da falha e uma correção sugerida. Exporte os resultados e priorize primeiro os itens com severidade Critical e Serious.
Teste de navegação por teclado: Desconecte o mouse e navegue por toda a página usando a tecla Tab. Confirme que cada elemento focável recebe foco visível, que o indicador de foco nativo do navegador (ou um personalizado) é claramente visível e que você consegue ativar todos os controles usando Enter ou Espaço. Qualquer elemento que você alcançar e não consiga identificar apenas pelo contexto — sem olhar para a tela — indica uma provável falha de nome acessível.
Teste com leitor de tela usando NVDA e Firefox: Abra o NVDA (Windows, gratuito), inicie o Firefox e navegue pela página usando Tab para percorrer elementos interativos e a Lista de Elementos do NVDA (Insert+F7) para navegar por todos os botões, links e campos de formulário. Para cada elemento interativo, ouça o que o NVDA anuncia. Ele deve ler o nome do elemento, sua função e qualquer estado relevante (por exemplo, "Subscribe, button" ou "Email address, required, edit text"). Sinalize qualquer elemento anunciado sem nome ou com função incorreta.
Teste com leitor de tela usando VoiceOver e Safari (macOS/iOS): Ative o VoiceOver (Command+F5 no macOS), abra o Safari e use VO+Seta para a direita para navegar pelos elementos. Use o Rotor do VoiceOver (VO+U) para listar todos os controles de formulário e botões. Verifique se os nomes são descritivos, se as funções são apropriadas e se os estados são atualizados dinamicamente quando você interage (por exemplo, alternar um acordeão personalizado deve fazer o VoiceOver anunciar "expanded" ou "collapsed").
Teste com leitor de tela usando JAWS e Chrome: Inicie o JAWS e abra o Chrome. Use a tecla Tab para navegar pelos elementos interativos e o Cursor Virtual do JAWS (Insert+F3 para uma lista de campos de formulário) para revisar os rótulos. Preste atenção especial a widgets personalizados construídos com ARIA — confirme que mudanças de estado acionadas pela interação via teclado são refletidas no que o JAWS anuncia em tempo real.
Verificação de estado em widgets personalizados: Para qualquer widget personalizado (acordeão, painel de abas, combobox, modal), interaja com ele completamente usando apenas o teclado. A cada etapa, verifique se o leitor de tela anuncia a atualização correta de estado — por exemplo, abrir um widget de divulgação deve disparar um anúncio de "expanded", e fechá-lo deve anunciar "collapsed". Se o estado visual muda, mas o leitor de tela permanece em silêncio, aria-expanded está ausente ou não está sendo alternado programaticamente.

Como Corrigir

Botão Apenas com Ícone Sem Nome Acessível — Incorreto

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Botão Apenas com Ícone Sem Nome Acessível — Correto

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Widget de Alternância Personalizado Sem Função ou Estado — Incorreto

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Widget de Alternância Personalizado Sem Função ou Estado — Correto

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

iframe Sem Rótulo — Incorreto

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

iframe Sem Rótulo — Correto

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Barra de Progresso Personalizada Sem Atributos ARIA Obrigatórios — Incorreto

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Barra de Progresso Personalizada Sem Atributos ARIA Obrigatórios — Correto

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Erros Comuns

Usar role='button' em um <div> sem adicionar tabindex='0' — o elemento passa a ser anunciado como botão por leitores de tela, mas continua inalcançável pela navegação com a tecla Tab, tornando-o inutilizável para usuários que dependem apenas do teclado.
Aplicar aria-label a um elemento não interativo — adicionar aria-label a um <div> ou <span> sem função não tem efeito; o rótulo é ignorado pela maioria dos navegadores porque o elemento não tem função para ser nomeada.
Deixar aria-expanded estático após implementar um widget de divulgação — definir aria-expanded='false' no HTML e nunca alterná-lo com JavaScript significa que o atributo está sempre errado após o primeiro clique, anunciando o estado oposto para usuários de leitores de tela.
Usar aria-hidden='true' em um contêiner que contém elementos focáveis — isso oculta o contêiner da árvore de acessibilidade, mas não do foco de teclado, de modo que usuários de leitores de tela podem navegar com Tab até elementos que não conseguem ouvir, causando extrema confusão.
Fornecer um placeholder como único rótulo para um <input> — o texto de placeholder desaparece ao digitar, não é anunciado de forma confiável como rótulo por todos os leitores de tela e não satisfaz o requisito de nome acessível para campos de formulário.
Usar uma função ARIA inválida ou abstrata, como role='widget' ou role='structure' — essas são funções base na especificação ARIA e não são destinadas ao uso direto; elas não fornecem informação semântica significativa e podem ser ignoradas ou causar erros em tecnologias assistivas.
Referenciar um ID de elemento inexistente em aria-labelledby — se o ID apontado por aria-labelledby não existir no DOM, o cálculo do nome acessível falha e o elemento fica sem nome.
Usar value em vez de aria-label para <input type='image'> — botões de input de imagem exigem um atributo alt para seu nome acessível; o atributo value é ignorado no cálculo de nome em inputs de imagem.
Omitir o atributo title em elementos <iframe> que carregam conteúdo de terceiros — desenvolvedores frequentemente presumem que embeds conhecidos (mapas, widgets de pagamento, players de vídeo) são autoexplicativos, mas usuários de leitores de tela precisam ser informados sobre o propósito do frame antes de decidir se devem entrar nele.
Esquecer de atualizar nomes acessíveis dinamicamente quando o conteúdo muda — se o rótulo de um botão muda visualmente de "Play" para "Pause", mas o aria-label permanece "Play", usuários de leitores de tela recebem informações incorretas sobre o estado e a ação atuais.

Relação com as Regulamentações 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 requisitos obrigatórios de acessibilidade digital alinhados com a WCAG 2.2. A WCAG 4.1.2 — Nome, Função, Valor é um critério de Nível A, o que significa que está no nível mais fundamental de conformidade. Sob a circular, a conformidade de Nível A não é opcional — é a base que todas as entidades abrangidas devem alcançar.

A circular se aplica a uma ampla gama de tipos de entidades que operam na Turquia. Instituições públicas — incluindo ministérios, prefeituras e agências estatais — devem alcançar conformidade em até um ano a partir da data de publicação da circular. Entidades do setor privado — incluindo plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de saúde privados, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE) — devem alcançar conformidade em até dois anos.

A WCAG 4.1.2 é particularmente consequente para organizações turcas porque muitos sites turcos modernos dependem de componentes interativos personalizados — carrosséis de produtos, FAQs em acordeão, fluxos de checkout passo a passo e dashboards bancários — que frequentemente são implementados sem funções ARIA adequadas, nomes ou gerenciamento de estado. Um botão de checkout personalizado que não tem nome acessível, ou um controle deslizante de calculadora de empréstimo que não possui aria-valuenow, não é apenas uma experiência de usuário ruim: sob a circular, constitui uma falha de conformidade legal.

Para bancos e plataformas de e-commerce sujeitas à circular, violações da WCAG 4.1.2 em fluxos críticos de transação — formulários de pagamento, modais de autenticação, dashboards de conta — são especialmente arriscadas. Um combobox personalizado estilizado visualmente para seleção de agência bancária que não possui marcação ARIA adequada pode impedir que um usuário de leitor de tela conclua uma transação, expondo a instituição tanto a ações regulatórias quanto a alegações de discriminação.

Organizações que utilizam o SDK de overlay da Accsible podem se beneficiar da detecção automatizada e da correção em tempo de execução de muitas violações de Nome, Função, Valor — incluindo a injeção de nomes acessíveis ausentes, a correção de funções ARIA inválidas em padrões de widgets conhecidos e a sincronização de atributos de estado em componentes interativos. No entanto, as organizações devem tratar o suporte automatizado de overlay como um complemento, e não como substituto, para o desenvolvimento adequado de HTML semântico, especialmente para widgets personalizados complexos em que o gerenciamento programático de estado precisa ser incorporado à lógica da aplicação desde o início.