Elementos nativos vêm com comportamento além de semântica: um button é focável, dispara com Enter e Espaço, participa de formulários e expõe o papel e o estado corretos de graça. Uma div com role button ganha o rótulo mas nenhum comportamento, então você adiciona tabindex, tratamento de teclas e estado desabilitado na mão, e cada um pode dar errado. A primeira regra do ARIA é não usar ARIA quando o HTML já resolve.
Por que os entrevistadores perguntam isso
Perguntas de acessibilidade separam quem rodou uma auditoria automática uma vez de quem realmente constrói componentes usáveis. O entrevistador quer ouvir que ARIA muda o que é anunciado mas nunca adiciona comportamento de teclado ou gestão de foco. Citar um caso real, como um botão falso inalcançável pelo teclado, prova que você testou com teclado ou leitor de tela em vez de confiar numa nota verde do Lighthouse.
Como estruturar sua resposta
- Enuncie a divisão: nativo dá semântica mais comportamento, ARIA só rerrotula.
- Liste o que você precisa reimplementar quando usa uma div.
- Cite a regra de não usar ARIA quando existe HTML.
- Dê um exemplo em que um elemento nativo economizou trabalho real.
Exemplo de resposta
ARIA só muda o que é exposto para a árvore de acessibilidade. Não torna nada focável, não adiciona tratamento de teclas e não gerencia foco. Então no momento em que escrevo uma div com role button eu assinei embaixo de tabindex zero, um handler de Enter e Espaço, um estado aria disabled que também preciso impor no handler, e ainda assim não ganho submissão de formulário. Um button de verdade me dá tudo isso e continua correto quando o navegador muda. Então meu padrão é nativo primeiro: button, a com href de verdade, input com label correspondente, dialog para modais, details para divulgação simples. Recorro a ARIA quando genuinamente não existe equivalente nativo, como um conjunto de abas ou um combobox, e aí sigo o padrão das authoring practices em vez de improvisar papéis. O bug que mais vejo é uma div clicável numa linha de tabela que um usuário de teclado simplesmente não alcança, e ela passa em toda checagem automática porque nada na marcação está tecnicamente errado.
Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.
Veja como funcionaPerguntas de acompanhamento que você pode esperar
- Como você tornaria um componente de abas customizado acessível pelo teclado?
- O que aria hidden faz, e quando ele causa dano?
- Como você testa isso além de rodar um scanner automático?
Mais perguntas para Desenvolvedor Frontend
Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.
Prever minhas perguntas