Quais são as funções ARIA? Um guia prático para desenvolvedores
Quais são as funções ARIA? Os papéis ARIA são o vocabulário de 87 valores definidos (a partir de WAI-ARIA 1.2) que informam às tecnologias assistivas o que um elemento é e como ele deve se comportar independentemente de sua tag HTML. Uma função como button, navigation ou dialog atribui um <div> ou <span> genérico a um tipo de widget conhecido para que os leitores de tela o anunciem corretamente e exponham as interações corretas do teclado.
Por que existem funções ARIA
Para entender o que são funções ARIA, é preciso ver que eles resolvem um problema estrutural que o HTML sozinho não consegue resolver. Elementos HTML nativos possuem semântica implícita: um <button> se anuncia como um botão, pode ser focado, responde ao Enter e à barra de espaço e exibe um estado pressionado quando necessário.
Quando os desenvolvedores criam widgets personalizados (uma caixa de combinação, um painel de guias, uma visualização em árvore), eles geralmente usam <div> e <span>, que não contêm semântica. As funções ARIA fecham essa lacuna, permitindo que os autores declarem explicitamente o significado que falta.
A especificação WAI-ARIA é mantida pelo Accessible Rich Internet Applications Working Group do W3C. A primeira versão, ARIA 1.0, tornou-se uma recomendação do W3C em 2014; ARIA 1.1 foi lançada em 2017 e ARIA 1.2 alcançou o status de recomendação em 2023. Funções, estados e propriedades foram adicionados a cada revisão e cada um está vinculado a um documento de práticas de autoria que descreve o comportamento esperado do teclado.
Uma distinção importante separa as funções das outras duas categorias ARIA. Os funções respondem: “O que é isso?” Os estados e as propriedades respondem: “Em que condições se encontra?” e “A que está relacionado?” Uma role="checkbox" declara o tipo de widget; aria-checked="true" indica seu estado atual. Confundir os dois é uma das causas mais comuns de widgets personalizados quebrados.
As seis categorias de funções
Para entender o que são funções ARIA, é útil saber que a especificação ARIA agrupa funções em seis famílias. Compreender a família permite prever quais estados e propriedades uma função suporta e quais padrões de teclado se aplicam.
Relacionado: — com plano gratuito para começar hoje mesmo.
| Categoria | Finalidade | Funções representativas |
|---|---|---|
| Abstrata | Definições de superclasse, nunca usadas em marcação | widget, input, section |
| Widget | Controles interativos | button, checkbox, slider, tab |
| Estrutura do documento | Marcos e regiões da página | banner, main, navigation, region |
| Marco | Regiões de páginas navegáveis (subconjunto de estrutura) | banner, complementary, contentinfo, form |
| Região ativa | Anuncie mudanças de conteúdo dinâmico | alert, status, log, timer |
| Janela | Janelas do navegador ou aplicativo | dialog, alertdialog |
As funções abstratas são usadas apenas para organizar a taxonomia. Os autores nunca devem escrever role="widget" ou role="input" na marcação; isso resulta em comportamento indefinido e falha na validação. As cinco categorias restantes são aquelas que você realmente aplica.
Papéis implícitos e a primeira regra do ARIA
Cada elemento HTML possui uma função ARIA implícita (que explica o que são funções de ária) definida pela especificação HTML Accessibility API Mapping (AAM). Um elemento <nav> possui um role="navigation" implícito. Um <ul> tem um role="list" implícito. Um <h1> para <h6> tem role="heading". Uma <tabela> possui role="tabela".
A primeira regra do W3C sobre o uso de ARIA afirma claramente: Se um elemento ou atributo HTML nativo já transmite a semântica e o comportamento necessários, use-o em vez de reutilizar um elemento com ARIA. Adicionar role="button" a um <button> não é necessário. Pior ainda, se você adicionar role="button" a um <div>, você receberá o anúncio, mas nenhum comportamento: sem foco, sem ativação do teclado, sem envio de formulário.
Vale a pena dar uma olhada: — Acessibilidade gerenciada: automatização combinada com revisão humana.
A redundância nem sempre é inofensiva. Substituir uma função implícita pode perder a semântica da qual a tecnologia assistiva depende. Escrever role="presentation" em uma <table> elimina completamente a semântica da tabela, que às vezes é intencional com tabelas de layout, mas desastrosa com tabelas de dados.
Como as funções interagem com estados e propriedades
As funções atuam como contêineres para os estados e propriedades que suportam. A especificação define quais atributos são válidos para quais funções, e os navegadores expõem apenas combinações suportadas na árvore de acessibilidade.
Entender o que são funções ARIA ajuda a saber que um role="checkbox" suporta aria-checked com os valores true, false ou mixed. Um role="slider" suporta aria-valuenow, aria-valuemin, aria-valuemax e, opcionalmente, aria-valuetext. Uma role="combobox" suporta aria-expanded, aria-controls e aria-activedescendant. Aplicar aria-checked a um role="button" não tem sentido e será ignorado ou produzirá resultados confusos em alguns leitores de tela.
As propriedades necessárias também são importantes. Um role="checkbox" sem aria-checked é inválido; o estado é obrigatório e não opcional. Um role="slider" sem aria-valuenow deixa o usuário incapaz de determinar o valor atual. A especificação ARIA os rotula como “estados e propriedades obrigatórios”, e verificadores de conformidade como axe-core e IBM Equal Access Accessibility Checker apontam sua ausência.
Funções, a árvore de acessibilidade e o suporte do navegador
Os navegadores traduzem funções ARIA em APIs de acessibilidade de plataforma (UIA no Windows, AXAPI no macOS, ATK/AT-SPI no Linux) e os leitores de tela usam essas APIs. Uma função que nenhum navegador atribui corretamente é praticamente invisível para os usuários.
O suporte varia de acordo com o recurso e o navegador. Funções básicas como “Botão”, “Link”, “Cabeçalho”, “Lista” e “Navegação” são universalmente suportadas. Funções mais novas ou mais especializadas (“feed”, “math”, “doc-footnote” do módulo WAI-ARIA da Digital Publishing) têm suporte mais irregular. O role=“switch” é suportado em navegadores modernos, mas foi anunciado de forma inconsistente há uma década.
Relacionado: — A que acredita sua experiência e acessibilidade.
Testar as combinações reais que seu público usa continua essencial. Um widget que funciona no NVDA com Firefox pode se comportar de maneira diferente no VoiceOver com Safari, porque os dois leitores de tela consomem APIs de plataformas diferentes e aplicam heurísticas diferentes.
Funções de referência e estrutura da página
As funções de referência permitem que os usuários de leitores de tela acessem diretamente as áreas de uma página. As oito funções de referência são banner, complementar, contentinfo, form, main, navigation, region e search. O HTML moderno tem equivalentes nativos para a maioria: <header> torna-se banner, <footer> torna-se contentinfo, <main> torna-se main, <nav> torna-se navigation, <aside> torna-se complementary, <form> com um nome acessível torna-se form, e <section> com um nome acessível torna-se region.
Usar elementos nativos é preferível porque eles funcionam mesmo se CSS ou JavaScript falharem e porque reduzem o risco de conflitos de funções/atributos. O marco search não tem equivalente HTML nativo, então role="search" ainda é a escolha correta para a região de pesquisa.
Um erro comum é aplicar role="banner" a um <div> que está dentro de um <main> ou <article>. As funções de ponto de referência só criam pontos de referência se não estiverem aninhadas em outras funções; um banner dentro de main não será exibido como um ponto de referência. A localização no DOM é tão importante quanto o valor da função. Para aqueles que estão se perguntando quais são as funções ARIA, esses marcos são uma parte fundamental da especificação.
Funções da região ativa
Ao considerar o que são funções de ária, as funções regionais ao vivo anunciam mudanças de conteúdo sem alterar o foco. As quatro funções da região ativa são alert, status, log e timer, bem como a mais geral marquee. Cada um carrega um valor aria-live implicitamente: alert e log na prática implicam assertive e polite, respectivamente, enquanto status implica educado.
Escolher entre alerta e status é uma decisão de design com consequências reais. Um alerta interrompe tudo o que o leitor de tela está lendo, o que é apropriado para erros e notificações urgentes, mas prejudicial se usado excessivamente. Um status aguarda uma pausa, que coincide com mensagens de progresso e textos de confirmação.
As regiões ativas devem existir no DOM antes que o conteúdo seja alterado. Inserir um elemento role="alert" e seu texto ao mesmo tempo muitas vezes resulta em nenhum anúncio porque a região não existia no momento da mudança. O padrão confiável é renderizar uma região ativa vazia no carregamento da página e atualizar seu conteúdo de texto posteriormente.
Quando NÃO usar funções ARIA
A segunda regra para usar ARIA é que os autores não devem alterar a semântica nativa, a menos que seja realmente necessário. A quinta regra afirma que todo elemento interativo, independentemente de sua função, deve ser acessível e focalizável através do teclado.
Adicionar uma função não adiciona comportamento. role="button" em um <div> faz com que ele não consiga focar, não responda à entrada ou à barra de espaço e não envie o formulário. Você precisa adicionar tabindex="0", um manipulador de teclas para entrada e espaço, e muitas vezes gerenciamento de estado “apropriado à função”. Neste ponto, usar um “
Perguntas frequentes
Quais são as funções ARIA em termos simples?
As funções ARIA são rótulos que você anexa aos elementos HTML para informar à tecnologia assistiva o que o elemento representa. Um <div role='button'> é anunciado como um botão e não como um texto genérico. As funções fornecem o significado que a tag subjacente não fornece, mas não adicionam nenhum comportamento, manipulação de foco ou suporte de teclado por conta própria.
Qual é a diferença entre funções ARIA e atributos ARIA?
As funções descrevem o tipo de um elemento, enquanto os atributos descrevem seu estado, valor ou relacionamentos. role='slider' identifica um controle deslizante; aria-valuenow='50' reporta sua posição atual e aria-labelledby aponta para seu rótulo. Funções e atributos são usados juntos e cada função define quais atributos ela suporta.
Quantas funções ARIA existem?
WAI-ARIA 1.2 define 87 funções agrupadas em seis categorias: resumo, widget, estrutura do documento, ponto de referência, região ativa e janela. Papéis abstratos como widget e input existem apenas para a taxonomia interna da especificação e nunca devem ser escritos em HTML. O número cresce a cada revisão de especificação.
Devo usar funções ARIA em vez de HTML semântico?
Não. A primeira regra de uso do ARIA diz para preferir um elemento HTML nativo sempre que existir um com a semântica e o comportamento necessários. Use <button> em vez de <div role='button'> e <nav> em vez de <div role='navigation'>. As funções ARIA são uma alternativa para casos em que não existe nenhum elemento nativo adequado.
As funções ARIA funcionam em todos os navegadores e leitores de tela?
Funções básicas como botão, link, cabeçalho e navegação são suportadas de forma confiável por navegadores e leitores de tela modernos. Funções mais novas ou mais especializadas, incluindo aquelas no módulo Publicação Digital, fornecem suporte mais variável. Somente testando as combinações específicas de navegador e leitor de tela que seu público usa você pode ter certeza.
Adicionar uma função ARIA pode quebrar a acessibilidade?
Sim. Substituir uma função implícita pode perder semântica útil, como quando role='presentation' é aplicado a uma tabela de dados. A aplicação de role='application' pode bloquear usuários se o manuseio do teclado personalizado estiver incompleto. Papéis redundantes em elementos nativos criam ruído desnecessário e ocasionalmente levam a anúncios conflitantes.
Cumprir WCAG sem tocar no código?
Superposição de IA que promete cumprimento WCAG em 48 horas