Lista de funções ARIA: melhores referências comparadas

A lista completa de funções ARIA contém 82 valores definidos na especificação WAI-ARIA 1.2 do W3C, organizados em seis categorias funcionais: funções de documento, de referência, de widget, de estrutura, de janela e de estado abstrato. Escolha a referência adequada para consultá-los dependendo se você precisar de uma tabela rápida, documentação com exemplos de código ou um guia de decisão sobre quando aplicar cada função.

Principais conclusões

• A especificação WAI-ARIA 1.2 define 82 funções, mas apenas um subconjunto reduzido é usado na prática diária de um site acessível por XHTML/CSS.
• A primeira regra de ARIA continua vigente: se existir um elemento HTML nativo com a semântica necessária, use-o em vez de adicionar uma função.
• Os papéis abstratos (como role="widget" ou role="input") nunca devem ser escritos no marcado; servem apenas como base taxonômica.
• Uma referência útil para front-end deve incluir o rol, seus atributos ARIA obrigatórios, os estados permitidos e um exemplo de marcação real.
• As funções de ponto de referência e widget concentram a maioria dos erros detectados por auditores automáticos, como axe-core ou Lighthouse.

O que é uma função ARIA e por que precisa de uma lista confiável

Um papel ARIA é um valor que é atribuído a um elemento por meio do atributo role para comunicar às tecnologias de assistência que tipo de componente representa. O navegador expõe essa função através da árvore de acessibilidade, e um leitor de tela como NVDA, JAWS ou VoiceOver traduz em um anúncio específico: “botão”, “aba”, “região”, “quadro de diálogo”.

A especificação WAI-ARIA, mantida pelo W3C dentro do grupo de trabalho ARIA, define cada função junto com seus atributos de estado e propriedade permitidos. A versão 1.2 é a recomendação atual estável, e ARIA 1.3 é encontrada em desenvolvimento. Para um desenvolvedor que trabalha com XHTML e CSS, a lista de funções não é um catálogo decorativo: cada valor mal aplicado gera um conflito entre a semântica nativa do elemento e a declarada, e os leitores de tela resolvem esse conflito de formas específicas dependendo do navegador.

A documentação oficial de funções de ARIA no MDN (Mozilla Developer Network) é a técnica de referência mais consultada em espanhol e inglês, mas não é a única. Existem folhas de referência, guias de padrões e ferramentas de validação que atendem a necessidades distintas. Comparar ajuda a escolher o que você precisa com seu fluxo de trabalho.

As seis categorias de papéis ARIA

A taxonomia oficial agrupa as funções de acordo com sua função. Conhecer as categorias evita procurar na lista equivocada.

Funções do documento. Descreve a estrutura de uma página ou seção: article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Muitos elementos HTML nativos são duplicados, por isso raramente são escritos à mão.

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

Funções de referência. Defina regiões navegáveis ​​da página: banner, complementary, contentinfo, form, main, navigation, region, search. É o que mais se utiliza em sites com semântica HTML incompleta.

Funções de widget. Representa controles interativos: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem. Requer foco e gerenciamento de teclado.

Funções de estrutura. Os widgets da organização incluem: application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

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

Funções de janela. Gerenciamento de conteúdo sobreposto ou modal: alertdialog, dialog.

Funções abstratas. Nenhum elemento é escrito na marcação: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Servem para que a especificação herdar propriedades entre funções.

Comparativa: as melhores referências de papéis ARIA

A tabela a seguir compara as referências mais usadas por desenvolvedores lusófonos de acordo com critérios práticos.

Referência	Tipo	Idiomas	Exemplos de código	Ideal para
Documentos Web MDN (Funções ARIA)	Documentação oficial	Multilingue (inclui espanhol)	Sim, por rol	Consulta técnica profunda
WAI-ARIA 1.2 (W3C)	Especificação normativa	Inglês	Não	Verifique o comportamento exato
Guia de práticas de autoria WAI-ARIA	Guia de Padrões	Inglês	Sim, patronos completos	Implementar widgets com teclado
Folha de referência tipo cheat sheet	Resumo da tabela	Inglês	Mínimos	Repaso rápido no editor
acessibilidade.build (referência ARIA)	Referência prática	Inglês	Sim	Aprenda com exemplos comentados
Auditores (axe-core, Lighthouse)	Ferramenta	Multilingue	Não	Detectar papéis inválidos

A eleição depende do momento. Durante a escritura marcada, uma folha de referência compacta ganha em velocidade. Ao limpar um widget que não é anunciado em seu estado, as especificações do W3C e o guia de padrões do WAI são as fontes que resolvem o problema.

Como decidir o que aplicar: critérios práticos

A decisão correta pode sempre ser iniciada descartando ARIA. Esses critérios, ordenados, evitam a maioria dos erros.

1. ¿Existe um elemento HTML nativo? Um <button> já tem a função implícita de um button. Adicionar role="button" é redundante e pode introduzir conflitos.
2. ¿Role requer atributos obrigatórios? role="checkbox" requer aria-checked. role="slider" requer aria-valuenow, aria-valuemin e aria-valuemax. Se você não consegue manter esses estados, o papel prejudica mais do que ajuda.
3. ¿A função envolve gerenciamento do teclado? As funções do widget requerem navegação com setas, Home, End e Esc dependendo do padrão. Uma role="tablist" sem manipulação de setas é pior do que não tê-la.
4. ¿El rol es abstracto? Se estiver na lista de papéis abstratos, não deve ser escrito.
5. ¿A função está obsoleta ou em desuso? Alguns valores foram alterados entre ARIA 1.0 e 1.2. Consulte sempre a versão atual.

A primeira regra para utilização de ARIA, reconhecida no guia de técnicas do W3C, é o princípio: utilizar HTML nativo sempre que possível. ARIA é um patch para quando o HTML não é suficiente, não um substituto.

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

Erros frequentes ao consultar e aplicar a lista de funções

Um erro habitual consiste em copiar uma lista de uma folha de referência sem comprovar seus atributos exigidos. role="combobox" no ARIA 1.2 mudou em relação ao 1.0 e agora espera aria-expanded e uma relação com um listbox através de aria-controls. Aplique a versão antiga rompe o anúncio nos leitores atualizados.

Também é comum usar role="presentation" ou role="none" para “limpar” a semântica sem entender que isso elimina o elemento da árvore de acessibilidade, incluindo seus filhos em alguns casos. Isso também aparece com a frequência role="application", que transfere todo o controle do teclado para o widget e desativa os atalhos do leitor de tela; está reservado para aplicações web complexas, não para formulários.

As funções de referência duplicadas geraram confusão: dos role="main" na mesma página, ou um role="banner" dentro de um <article>, produzido uma navegação por regiões incoerentes. A validação com axe-core ou com as ferramentas de acessibilidade do navegador detecta vários desses casos, embora nenhuma ferramenta substitua automaticamente a verificação pelo leitor de tela real.

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

Ferramentas para validar funções no seu marcador

A verificação de funções combina inspeção manual e automação. Las DevTools do Chrome e Firefox incluem um painel de acessibilidade que mostra a árvore tal como recebe o sistema operacional, com a função de cálculo de cada nó. É a forma mais direta de ver se um papel declarado sobreviveu ou é sobrescrito pela semântica nativa.

axe-core, integrado no Lighthouse e disponível como extensão, marca funções inválidas, atributos obrigatórios ausentes e combinações contraditórias. A extensão Accessibility Insights for Web, baseada nas regras do eixo, adicionou testes guiados. Para testes com usuários reais, NVDA no Windows e VoiceOver no macOS oferecem a verificação definitiva: nenhum validador detecta se o anúncio resulta compreensível no contexto.

A documentação de acessibilidade do MDN e o guia de padrões WAI-ARIA do W3C são as duas fontes que convêm ter abertas durante o desenvolvimento. A primeira explicação de cada rolo; a segunda mostra como se combina em componentes completos.

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

Quantos papéis ARIA existem?

A especificação W3C WAI-ARIA 1.2 define 82 funções no total, divididas entre documento, ponto de referência, widget, estrutura, janela e funções abstratas. Neste contexto, apenas uma fração é usada no desenvolvimento normal: papéis abstratos nunca são escritos e muitos papéis de documentos duplicam elementos HTML nativos.

Qual é a diferença entre um papel ARIA e um atributo ARIA?

Um papel ARIA descreve que é um elemento, enquanto os atributos ARIA descrevem seu estado ou propriedades. Por exemplo, role="checkbox" identifica o componente e aria-checked="true" comunica se estiver marcado. Os papéis são atribuídos com o atributo role; os estados e propriedades usam o prefixo aria-.

Você deve usar ARIA se usar HTML semântico?

Na maioria dos casos, não. O HTML semântico já expõe papéis implícitos: <nav> é equivalente a role="navigation" e <main> é equivalente a role="main". Adicionar a função explicitamente é redundante e pode criar conflitos. ARIA é reservada para componentes que o HTML não cobre, como abas, árvores ou menus complexos.

Quais papéis ARIA nunca devem ser escritos no marcado?

Papéis abstratos nunca devem aparecer: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget e window. Eles existem apenas para a especificação definir a herança de propriedades entre funções. Escrevê-los produz uma função inválida que os validadores sinalizam.

Como verificar se um rol ARIA funciona corretamente?

A verificação combina três etapas: inspecionar a árvore de acessibilidade no DevTools do navegador para confirmar a função calculada, passar um validador como axe-core para detectar atributos obrigatórios ausentes e testar com um leitor de tela real como NVDA ou VoiceOver. Apenas a última etapa confirma que o anúncio é compreensível para a pessoa.

As funções ARIA mudam entre versões da especificação?

Si. ARIA 1.1 adicionou funções como feed e switch, e ARIA 1.2 modificou o comportamento de combobox e consolidou outros valores. ARIA 1.3 está sendo desenvolvido. Consultar sempre a versão vigente da especificação evita aplicar padrões obsoletos que os leitores de tela modernos interpretam de forma distinta.