Exemplos de funções ARIA: um guia completo

Os exemplos de funções ARIA mostram como os atributos de funções mapeiam elementos de interface para a árvore de acessibilidade, e a especificação WAI-ARIA 1.2 define 6 categorias de funções – widget, estrutura de documento, ponto de referência, região ativa, janela e resumo – cobrindo mais de 80 funções concretas. Este guia apresenta exemplos práticos prontos para serem copiados para cada categoria, bem como as regras que determinam quando uma função ajuda e quando prejudica ativamente.

Principais conclusões

• As funções ARIA informam à tecnologia assistiva o que é um item; elas nunca adicionam comportamento, foco ou suporte de teclado por conta própria.
• A primeira regra para usar ARIA é preferir elementos HTML nativos, que já carregam funções, estados e gerenciamento de teclado implícitos.
• As seis categorias de funções WAI-ARIA 1.2 são widget, estrutura de documento, ponto de referência, região ativa, janela e resumo — funções abstratas nunca devem aparecer em sua marcação.
• As funções de referência são as ARIAs mais econômicas e de menor risco que você pode adicionar a um site XHTML/CSS existente.
• As funções de widget quase sempre exigem mapeamento JavaScript para interação do teclado e manipulação de estado, ou criam uma experiência pior do que HTML simples.
• Validar cada função com leitor de tela e verificador automatizado; uma função válida na especificação ainda pode estar errada para o seu conteúdo.

O que as funções ARIA realmente fazem

As funções ARIA são tokens que você coloca no atributo role para substituir ou fornecer a identidade semântica de um elemento na árvore de acessibilidade. Um <div role="button"> diz a um leitor de tela para anunciar “botão”, mas o navegador ainda o trata como um contêiner genérico: não é focável, não responde a Enter ou Espaço e não possui um estado desabilitado.

Essa lacuna entre a semântica anunciada e o comportamento real é a fonte mais comum de falha do ARIA. Esses são exemplos comuns de funções ARIA de como a semântica pode divergir do comportamento.

A especificação WAI-ARIA, mantida pelo Accessible Rich Internet Applications Working Group do W3C, define funções, bem como estados e propriedades. As funções são a camada “o que é”; estados e propriedades como aria-expanded, aria-checked e aria-label são a camada “em que condição está”. Uma função sem seus estados obrigatórios está incompleto — role="checkbox" requer aria-checked, e role="combobox" requer aria-expanded mais uma caixa de listagem controlada.

Os elementos HTML nativos carregam funções implícitas. <button> corresponde à função do botão, <nav> à navegação, <h1> até <h6> ao cabeçalho e <input type="checkbox"> à caixa de seleção. Como o navegador fornece automaticamente a função, o comportamento do teclado e o estado, a primeira regra de uso do ARIA — documentada no ARIA Authoring Practices Guide do W3C — é usar a semântica nativa sempre que existir um elemento equivalente. Procure funções explícitas somente quando nenhum elemento nativo for adequado, como uma visualização em árvore personalizada ou um painel com guias construído a partir de <div>s.

As seis categorias de funções WAI-ARIA

WAI-ARIA 1.2 organiza funções em seis categorias, e saber a qual categoria uma função pertence informa quanto JavaScript você deve a ela. Aqui estão alguns exemplos comuns de funções ARIA:

Relacionado: UserWay — Widget de acessibilidade com plano gratuito para começar hoje mesmo.

Categoria	Finalidade	Funções de exemplo	JavaScript necessário?
Widget	Controles interativos	“button, checkbox, tab, slider, combobox`	Sim – teclado + estado
Estrutura do documento	Organização de conteúdo	“heading, list, listitem, table, article`	Não
Marco	Regiões de página para navegação	“banner, main, navigation, complementary`	Não
Região ativa	Anuncie atualizações dinâmicas	alert, status, log, timer	Normalmente — para acionar atualizações
Janela	Subjanelas e caixas de diálogo	“dialog, alertdialog`	Sim — gestão de foco
Abstrata	Papéis de superclasse, nunca criados	widget, “input, section, landmark`	N/A — não use

Papéis abstratos existem apenas para organizar a taxonomia. Escrever role="input" ou role="section" em seu HTML é um erro de validação e produz anúncios imprevisíveis porque essas funções não têm comportamento definido para tecnologia assistiva.

Exemplos de funções de referência

As funções de referência são os exemplos de funções ARIA mais seguros e impactantes que você pode adicionar a um site XHTML/CSS antigo porque não requerem JavaScript e mapeiam diretamente para regiões que você já possui. Um esqueleto de página típico:

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

Cada função de marcador corresponde a um elemento nativo - banner para <header> no nível superior, main para <main>, navigation para <nav>, complementary para <aside>, contentinfo para <footer>. Quando você usa o elemento nativo, a função fica implícita e você não deve repeti-la. O atributo role explícito ganha seu lugar apenas quando você está preso a uma marcação <div> que não pode ser modificada, o que é comum em modelos mais antigos e na saída do CMS.

Vale a pena dar uma olhada: AudioEye — Acessibilidade gerenciada: automatização combinada com revisão humana.

Duas advertências são necessárias aqui. Primeiro, banner, main e contentinfo devem aparecer uma vez por página; vários pontos de referência “principais” perturbam a navegação. Segundo, quando existem vários pontos de referência do mesmo tipo – digamos, três elementos <nav> – forneça a cada um um aria-label separado para que os usuários de leitores de tela possam distingui-los na lista de pontos de referência. Um nav sem rótulo é anunciado da mesma forma que seus irmãos, o que vai contra o propósito.

Exemplos de funções de widget

As funções de widget são onde o ARIA se torna poderoso e perigoso em igual medida. Cada função de widget tem um contrato implícito: teclas de teclado específicas, estados específicos e comportamento de foco específico. O Guia de Práticas de Autoria ARIA publica o padrão completo de cada um. Esses exemplos de papéis de ária ilustram a complexidade envolvida.

Um botão de alternância, por exemplo, precisa de aria-pressed para comunicar seu estado ligado/desligado:

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

O elemento <button> fornece a função, foco e manipulação de Enter/Space; JavaScript apenas alterna aria-pressed entre "false" e "true". Esta é a forma ideal de uso de ARIA – elemento nativo, ARIA mínimo, script pequeno.

Uma interface de aba personalizada construída a partir de <div>s é o caso oposto. Ele precisa de role="tablist" no contêiner, role="tab" em cada aba, role="tabpanel" em cada painel, aria-selected na aba ativa, aria-controls ligando a aba ao painel e navegação com teclas de seta entre as abas.

Se você perder alguma delas, o widget se anuncia como guias, mas se comporta como texto estático. O mesmo se aplica a role="slider" (requer aria-valuenow, aria-valuemin, aria-valuemax e teclas de seta), role="combobox" (requer aria-expanded e uma caixa de listagem controlada), e role="tree" (requer aria-expanded e travessia completa da tecla de seta).

Relacionado: IAAP CPACC / WAS Certification — A certificação profissional que acredita sua experiência e acessibilidade.

Uma regra de decisão útil: se houver um elemento nativo que faça o trabalho — <button>, <input type="checkbox">, <select>, <details> — use-o e ignore completamente a função do widget. Reserve funções de widget personalizadas para controles verdadeiramente novos e reserve o JavaScript para implementar o padrão de teclado completo antes do envio.

Exemplos de estrutura de documento e região ativa

As funções da estrutura do documento descrevem relacionamentos de conteúdo quando os elementos nativos não estão disponíveis. Esses exemplos de papéis de ária incluem role="heading" com aria-level, que é o resgate clássico para um estilo <div> agindo como um título:

<div role="heading" aria-level="2">Novedades do mês</div>

O atributo aria-level é obrigatório aqui — uma função de título sem nível é anunciada sem classificação, quebrando o contorno do documento. Da mesma forma, role="list" e role="listitem" restauram a semântica da lista quando CSS como list-style: none ou um flex container os remove em alguns navegadores, e role="table", role="row", role="columnheader" e role="cell" reconstroem uma tabela de dados a partir da marcação <div>. Na prática, a reestruturação em elementos reais <ul>, <ol> e <table> quase sempre requer menos trabalho do que manter um conjunto completo de funções de estrutura.

Se você estiver comprando: accessiBe — Superposição de IA que promete cumprimento WCAG em 48 horas.

As funções da região ativa anunciam a alteração do conteúdo sem recarregar a página. role="alert" interrompe imediatamente o leitor de tela e acomoda mensagens de erro e notificações urgentes; role="status" espera educadamente e aceita confirmações como “Guardado”; role="log" se ajusta aos feeds de bate-papo e atividades; role="timer" corresponde a contagens regressivas. O detalhe crítico é que o contêiner da região ativa deve existir no DOM antes do conteúdo ser alterado — injetar um novo elemento com role="alert" e seu texto ao mesmo tempo muitas vezes não produz nenhum anúncio, porque a região não estava presente para ser monitorada. Crie um <div role="status"> vazio no carregamento da página e atualize seu texto posteriormente.

Erros comuns de função ARIA

Funções redundantes estão no topo da lista. Esses exemplos de papéis de ária, como <button role="button"> e <nav role="navigation">, não acrescentam nada e desorganizam a marcação; o papel implícito já existe. A mesma redundância aparece quando os desenvolvedores adicionam role="heading" a um <h2>.

Os estados obrigatórios ausentes vêm em segundo lugar. role="checkbox" sem aria-checked, role="slider" sem aria-valuenow e role="combobox" sem aria-expanded produzem anúncios incompletos que enganam os usuários. A especificação lista os estados e propriedades necessários para cada função, e os verificadores automatizados sinalizam sua ausência.

O uso indevido de função no elemento errado é o terceiro. Colocar role="button" em um <a href> substitui a semântica do link e interrompe o comportamento esperado, como abrir em uma nova guia. Colocar role="presentation" ou role="none" em um elemento focável remove sua semântica enquanto o deixa na ordem de tabulação, criando um elemento focável sem identidade anunciada. E usar funções abstratas como role="widget" ou role="input" é sempre um erro.

Finalmente, as funções ARIA não podem consertar um DOM quebrado. Um role="tabpanel" aninhado em seu próprio role="tab" produz uma árvore sem sentido, não importa quantos atributos você adicione. Corrija a estrutura primeiro e depois coloque o ARIA por cima.

Como testar funções ARIA

Testar funções ARIA requer vários métodos, pois ferramentas automatizadas detectam erros de validade, mas não incompatibilidades semânticas. Comece com um verificador de acessibilidade - ax DevTools, WAVE ou Lighthouse - para detectar funções inválidas, atributos obrigatórios ausentes e funções abstratas em sua marcação. Essas ferramentas são rápidas e detectam erros mecânicos.

Siga com um passe de leitor de tela. NVDA com Firefox no Windows, JAWS com Chrome e VoiceOver com Safari no macOS expõem a árvore de acessibilidade de maneira diferente, e uma função que é anunciada corretamente em um pode não ser anunciada em outro. Navegue por ponto de referência e por título para confirmar se suas funções de estrutura produzem o contorno esperado e, em seguida, navegue por cada widget para verificar se a função anunciada, o estado e o comportamento do teclado correspondem.

Inspecione a árvore de acessibilidade diretamente no Chrome ou Firefox DevTools, onde o painel “Acessibilidade” exibe a função calculada e o nome de qualquer elemento. Isso revela a lacuna entre a função que você escreveu e a função que o navegador realmente expõe - a maneira mais rápida de detectar uma função que é substituída por um pai ou totalmente ignorada.

Fontes e leituras adicionais

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) é uma especificação técnica publicada pelo World Wide Web Consortium (W3C) que…

Perguntas frequentes

Quais são as funções ARIA e como funcionam?

As funções ARIA são valores no atributo role que definem a identidade de um elemento na árvore de acessibilidade, para que os leitores de tela o anunciem corretamente. Eles mudam apenas a semântica, não a aparência, o foco ou o comportamento do teclado. A especificação WAI-ARIA 1.2 define seis categorias de funções e mais de 80 funções concretas, cada uma com estados e propriedades necessários.

Quando devo usar funções ARIA em vez de HTML nativo?

Use funções ARIA somente quando nenhum elemento HTML nativo fornecer a semântica necessária. Elementos nativos como <button>, <nav> e <input type="checkbox"> carregam funções implícitas, além de suporte de teclado integrado e gerenciamento de estado. A primeira regra de uso do ARIA é preferir a semântica nativa e adicionar funções explícitas apenas para widgets personalizados ou marcação legada que você não pode reestruturar.

Qual é a diferença entre funções ARIA e atributos ARIA?

As funções ARIA respondem “o que é este item”, enquanto atributos ARIA como aria-expanded, aria-checked e aria-label respondem “em que estado ele está” ou “como é chamado”. Os papéis e seus atributos obrigatórios funcionam juntos: como exemplos de papéis de ária, role="checkbox" está incompleto sem aria-checked, e role="combobox" precisa de aria-expanded mais uma caixa de listagem controlada.

Posso usar funções ARIA em qualquer elemento HTML?

As funções ARIA podem ser aplicadas à maioria dos elementos, mas algumas combinações são inválidas ou prejudiciais. Papéis abstratos como widget e input nunca devem ser criados. Alterar a função de um link para role="button" quebra o comportamento esperado do link, e role="presentation" em um elemento focável remove sua semântica enquanto o deixa em ordem de tabulação.

As funções ARIA funcionam sem JavaScript?

A estrutura do documento e as funções de referência funcionam sem JavaScript porque apenas modificam a semântica. Funções de widget como tab, slider e combobox requerem JavaScript para implementar a interação do teclado e atualizar estados — sem ele, o elemento se anuncia como um controle, mas não se comporta como tal, o que é pior que o HTML simples.

Como posso verificar se minhas funções ARIA estão corretas?

Combine testes automatizados e manuais. Execute axe DevTools, WAVE ou Lighthouse para detectar funções inválidas e atributos obrigatórios ausentes e, em seguida, teste com NVDA, JAWS e VoiceOver para confirmar anúncios e comportamento do teclado. O painel Acessibilidade no Chrome e Firefox DevTools exibe a função computada, revelando quaisquer funções que o navegador substitui ou ignora.