Folha de referências de papéis ARIA: melhores escolhas comparadas

Por Niquelao Resource Desk · Atualizado em 28 de setembro de 2026

Uma aria roles cheat sheet é uma referência que atribui cada papel (role) ARIA ao seu elemento HTML nativo equivalente, sua categoria (widget, landmark, estrutura, live region ou janela) e as propriedades e estados que o acompanham. O WAI-ARIA 1.2 define 82 papéis, e a maioria dos projetos precisa de apenas 15 a 20 de forma recorrente. Este comparativo reúne as melhores folhas de referência disponíveis em 2026 e explica qual conviene segundo o seu fluxo de trabalho.

Por que uma cheat sheet de papéis ARIA continua sendo necessária

Especificações como WAI-ARIA 1.2 e sua sucessora WAI-ARIA 1.3 são documentos densos, pensados para implementadores de navegadores e tecnologias de assistência, não para quem monta um formulário em uma terça-feira à tarde. A primeira regra do ARIA — usar HTML nativo sempre que existir — resolve a maioria dos casos, mas há padrões que não têm equivalente nativo: abas (tabs), árvores, grids interativos, comboboxes com autocompletar, menus com submenus. É aí que uma folha de referência economiza tempo e, sobretudo, evita erros.

O erro mais comum não é esquecer um papel, mas adicionar um desnecessário. Um <button> com role="button" não agrega nada e pode quebrar o comportamento nativo em alguns leitores de tela. Uma cheat sheet bem feita marca explicitamente quais papéis são redundantes em elementos nativos, quais papéis exigem gestão de foco via JavaScript e quais atributos são obrigatórios versus opcionais.

A segunda razão é a verificação. Os papéis têm relações de propriedade: aria-labelledby aponta para um id, aria-activedescendant exige que o elemento referenciado exista e seja visível, aria-owns só se justifica quando a ordem do DOM não coincide com a ordem visual. Uma tabela que cruze o papel, atributos requeridos e atributos proibidos detecta falhas antes que cheguem a uma auditoria.

O que deve incluir uma boa cheat sheet de papéis ARIA

Uma folha de referência útil para desenvolvimento front-end cumpre cinco critérios. Eu os listo porque são exatamente os que usei para avaliar as opções deste comparativo.

Cobertura de todas as cinco categorias de papéis. O WAI-ARIA agrupa papéis em summaries, widgets, estrutura de documento, landmarks e live regions. Summaries (roletype, widget, input) não são usados no framework; uma boa referência deve apontar para dados de formas visíveis.
Equivalente HTML nativo para o papel. Sem esta coluna, a referência induz ao uso de ARIA onde não é necessário.
Atributos obrigatórios, suportados e proibidos. role="checkbox" requer aria-checked; role="heading" requer aria-level; role="presentation" não é permitido.
Padrão de teclado associado. Um papel sem gestão de teclado é uma promessa não cumprida. role="tablist" implica setas esquerda/direita, Home e End.
Formato pesquisável. Buscador, filtro por categoria, versão da especificação e capacidade de copiar o fragmento de código.

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

A tabela a seguir resume as opções mais sólidas. Nenhuma é paga; todas se mantêm ativas e citam a versão da especificação que cobrem.

Relacionado: — com plano gratuito para começar hoje mesmo.

Recurso	Enfoque	Categorias cobertas	Equivalente nativo	Padrão de teclado	Ideal para
WAI-ARIA Authoring Practices Guide (APG), W3C	Padrões completos com exemplos	Widgets, landmarks, estrutura, live regions	Sim, em cada padrão	Sim, detalhado	Implementar um widget concreto
MDN Web Docs, referência de papéis ARIA	Ficha por papel	Todas, incluindo abstratos	Sim	Parcial	Consultar um papel pontual
ARIA Authoring Practices, índice de papéis	Tabela papel $\to$ atributos	Widgets e estrutura	Parcial	Não	Verificar atributos requeridos
Deque University, ARIA reference	Fichas com notas de suporte	Widgets e landmarks	Sim	Parcial	Conhecer suporte real por leitor
A11Y Project Checklist	Lista de verificação	Transversal	Não se aplica	Não	Auditar antes de publicar
HTML-ARIA (W3C), tabela de equivalências	Papel permitido por elemento	Todas	Sim, é seu propósito	Não	Decidir se ARIA é necessário

WAI-ARIA Authoring Practices Guide (APG)

O APG do W3C é a referência canônica para padrões. Cada padrão inclui estrutura HTML, papéis, estados, interação de teclado e um exemplo funcional. Seu ponto forte é que não se limita a listar papéis: explica o comportamento esperado. Seu ponto fraco é que não é uma tabela rápida; para consultar “quais atributos o role="slider" possui”, é preciso navegar até o padrão correspondente.

O APG agrupa os widgets mais comuns: accordion, alert, breadcrumb, button, checkbox, combo box, dialog, disclosure, feed, grid, link, list box, menu, menu bar, radio group, slider, rotary knob, switch, table, tab list, toolbar, tooltip, grid tree e tree view. Se o seu projeto usa um destes, procure aqui.

MDN Web Docs: a referência por papel

O MDN mantém uma página para cada papel ARIA, com a descrição, atributos obrigatórios, atributos permitidos, problemas de acessibilidade associados e links para a especificação. Esta é a opção mais rápida quando você sabe o que está fazendo. Sua cobertura inclui papéis abstratos e papéis em uso, embora muitos lembretes sejam omitidos.

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

Um detalhe prático: o MDN marca quais papéis estão obsoletos ou em risco de eliminação em futuras versões da especificação. Consultar essa marca evita adotar um papel que desaparecerá.

HTML-ARIA: a tabela que evita ARIA desnecessário

A especificação HTML-ARIA do W3C define, para cada elemento HTML, quais papéis ARIA podem ser aplicados e quais são redundantes. É a ferramenta decisiva quando você hesita entre usar um elemento nativo ou um div com papel. Se o papel que você quer aplicar aparece como redundante para aquele elemento, a resposta é não adicioná-lo.

A Deque University oferece fichas de papel com notas sobre suporte real em leitores de tela, algo que a especificação não cobre porque não é seu propósito. O A11Y Project Checklist não é uma cheat sheet de papéis, mas funciona como uma lista de verificação prévia à publicação e complementa bem as anteriores.

Como escolher segundo o seu caso

A decisão depende de três perguntas. Primeiro, você já sabe qual papel precisa? Se a resposta for sim, o MDN é o caminho mais curto. Segundo, está construindo um widget com interação complexa? Então você precisa do APG, porque o papel por si só não descreve o comportamento do teclado. Terceiro, tem dúvida entre HTML nativo e ARIA? Consulte o HTML-ARIA antes de qualquer outra fonte.

Para equipes que trabalham com XHTML e CSS sem frameworks, a combinação mais eficiente costuma ser: HTML-ARIA para decidir, APG para implementar e MDN para verificar atributos. Uma cheat sheet de uma única página serve como memória de curto prazo, mas não substitui essas três fontes quando surge um caso limite.

Um critério adicional que conviene aplicar: se o papel requer JavaScript para funcionar corretamente (gestão de foco, atualização de aria-expanded, sincronização de aria-selected), trate-o como uma decisão de arquitetura, não como um atributo decorativo. Papéis de widget sem a lógica associada geram mais barreiras do que a ausência de papel.

Relacionado: — A que acredita sua experiência e acessibilidade.

Erros frequentes que nenhuma cheat sheet evita por si só

Papéis de landmark duplicados confundem a navegação por regiões. Um role="main" sobre um <main> é redundante; dois role="navigation" sem etiqueta distintiva são ambíguos. A solução é aria-label ou aria-labelledby em cada landmark repetido.

Papéis de widget sobre elementos não focáveis quebram a interação. role="button" sobre um <div> exige tabindex="0" e manejo de Enter e Espaço. Sem isso, o papel anuncia um botão que não pode ser ativado via teclado.

Estados dessincronizados são a causa mais comum de falhas de acessibilidade. Um aria-expanded que não muda ao abrir um acordeão, um aria-selected que não atualiza quando a aba muda ou um aria-checked em um role="switch" que permanece fixo. Nenhuma tabela detecta isso: é preciso testar com teclado e com um leitor de tela real.

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

Papéis abstratos no código são um erro de princípio. role="widget", role="input" ou role="section" não devem aparecer no HTML; existem apenas para a hierarquia da especificação.

Key Takeaways

O WAI-ARIA 1.2 define 82 papéis, mas a maioria dos projetos usa apenas entre 15 e 20 de forma recorrente.
A primeira regra do ARIA — usar HTML nativo quando existir — torna a tabela HTML-ARIA do W3C a referência mais importante antes de escrever qualquer papel.
O APG do W3C é insuperável para padrões de widget porque inclui interação de teclado; o MDN é mais rápido para consultar um papel concreto.
Um papel sem gestão de foco e sem atualização de estados gera mais barreiras de acessibilidade do que não usar ARIA.
Nenhuma cheat sheet substitui o teste com teclado e com leitor de tela: estados dessincronizados só são detectados no uso real.

Perguntas frequentes

Quantos papéis ARIA existem?

O WAI-ARIA 1.2 define 82 papéis, divididos em cinco categorias: abstratos, widgets, estrutura de documento, landmarks e live regions. Os papéis abstratos nunca são aplicados na marcação; servem para organizar a hierarquia da especificação. Na prática, um projeto típico utiliza entre 15 e 20 papéis distintos.

Qual é a melhor cheat sheet de papéis ARIA?

Depende do uso. Para implementar um widget com teclado, o WAI-ARIA Authoring Practices Guide do W3C é a referência mais completa. Para consultar os atributos de um papel concreto, o MDN Web Docs é mais rápido. Para decidir se um papel é necessário sobre um elemento HTML, a tabela HTML-ARIA do W3C é a fonte decisiva.

Devo usar ARIA se existe um elemento HTML nativo?

Não. A primeira regra do ARIA estabelece que, se existe um elemento HTML com a semântica e o comportamento que você precisa, deve-se usar esse elemento em vez de um div com papel. Adicionar role="button" a um <button> é redundante e pode alterar o comportamento nativo em alguns leitores de tela.

Os papéis de widget descrevem controles interativos — button, checkbox, slider, tablist — e requerem gestão de foco e teclado. Os papéis de landmark descrevem regiões da página — main, navigation, banner, contentinfo — e servem para a navegação por regiões. Um mesmo elemento não deveria cumprir ambas as funções.

Os papéis ARIA mudam entre versões da especificação?

Sim. O WAI-ARIA 1.2 adicionou papéis como blockquote, caption, code, deletion, emphasis, insertion, meter, paragraph, strong, subscript e superscript. Alguns papéis tornaram-se obsoletos em versões posteriores. Convém verificar no MDN ou na própria especificação se um papel continua vigente antes de adotá-lo.

Uma cheat sheet de papéis ARIA basta para cumprir a WCAG?

Não. Os papéis ARIA são parte do critério 4.1.2 Nome, Papel e Valor, mas a WCAG 2.2 inclui muitos outros requisitos: contraste, foco visível, tamanho do alvo, texto alternativo, estrutura de cabeçalhos. Uma cheat sheet ajuda a implementar papéis corretamente, não a cumprir todo o conjunto de critérios de conformidade.

Sources & Further Reading

Cheat sheet — Wikipedia: A cheat sheet (also cheatsheet) or crib sheet or job aid is a concise set of notes used for quick reference. Cheat sheets were historically used by students without…

Cumprir WCAG sem tocar no código?

Superposição de IA que promete cumprimento WCAG em 48 horas