Acessibilidade e semântica HTML: elementos nativos vs. WAI-ARIA
Gabarito: letra E. A melhor prática de HTML e WAI-ARIA é preferir elementos HTML nativos — como <button> para ações — e usar ARIA apenas para complementar a semântica quando o HTML não oferece um elemento adequado. Isso garante foco via teclado, comportamento consistente (Enter/Espaço), nome acessível e papel semântico correto por padrão, sem necessidade de reimplementar tudo em JavaScript.
O problema central da questão é a diferença entre semântica nativa e semântica simulada. Elementos HTML como <button>, <a>, <input> já trazem embutidos o papel, o estado, o suporte a teclado e a exposição correta à árvore de acessibilidade. Quando usamos <div> ou <span> com role e tabindex, estamos reimplementando comportamentos que o navegador já oferece de graça — e quase sempre de forma incompleta. A WAI-ARIA (Accessible Rich Internet Applications) foi criada exatamente para preencher lacunas quando não existe um elemento HTML adequado, não para substituir o que já funciona.
Na prática, um <button> nativo responde a Enter e Espaço, recebe foco com Tab, expõe o papel button para leitores de tela e permite nome acessível via conteúdo textual ou aria-label. Um <div role="button" tabindex="0"> exige que o desenvolvedor implemente manualmente os handlers de teclado, o gerenciamento de foco e a semântica — e qualquer esquecimento quebra a acessibilidade. Por isso, a regra de ouro é: use o elemento nativo sempre que existir; recorra ao ARIA apenas quando não houver alternativa HTML.
A pegadinha da banca está em apresentar soluções que parecem "funcionais" mas violam boas práticas: simular botão com div, simular link com span, remover rótulo visível, ou manipular tabindex para esconder elementos do fluxo de tabulação. Todas essas abordagens criam controles quebrados ou inacessíveis. A alternativa E é a única que segue o princípio fundamental da acessibilidade web: priorizar o HTML semântico nativo e usar ARIA como complemento, não como substituto.
Guarde este critério para analisar as alternativas: existe um elemento HTML nativo que representa o papel desejado? Se sim, use-o. Se não, aí sim o ARIA entra. É exatamente essa fronteira que separa a alternativa correta das demais.
Alternativa A — ❌ Incorreta
Manter <div role="button" tabindex="0"> com handlers de teclado para "simular" o nativo é uma prática desaconselhada. Embora seja possível fazer um div se comportar como botão, isso exige reimplementar manualmente o suporte a Enter/Espaço, o gerenciamento de foco e a exposição correta à árvore de acessibilidade. O <button> nativo já oferece tudo isso de graça, com menos código e menos risco de erro. A alternativa tenta justificar a manutenção do código legado como "sem custos de refatoração", mas ignora que a simulação nunca é totalmente equivalente ao nativo — por exemplo, o div não dispara o evento click com a tecla Espaço automaticamente, exigindo handlers extras.
Alternativa B — ❌ Incorreta
Substituir links de navegação por <span role="link"> é um erro grave. Links (<a href>) têm semântica nativa de navegação, suporte a teclado (Enter), e são anunciados como links pelos leitores de tela. Um <span role="link"> não tem comportamento de navegação nativo — o desenvolvedor precisaria implementar manualmente o clique, o Enter, o foco e ainda correr o risco de quebrar a experiência de usuários que dependem de atalhos do navegador (como abrir em nova aba). Além disso, "uniformizar o estilo" não justifica remover a semântica: CSS pode estilizar um <a> da mesma forma que um <span>, sem perder a acessibilidade.
Alternativa C — ❌ Incorreta
Remover o rótulo visível e confiar apenas em title ou aria-label para o nome acessível é uma má prática. O title não é um substituto confiável para o nome acessível — ele aparece apenas como tooltip e não é anunciado de forma consistente por todos os leitores de tela. O aria-label pode funcionar, mas a remoção do rótulo visível prejudica usuários que dependem de pistas visuais, além de violar o princípio de que o nome acessível deve, sempre que possível, ser derivado do conteúdo visível. A boa prática é manter um rótulo visível e, se necessário, complementar com aria-label ou aria-labelledby — não substituir um pelo outro.
Alternativa D — ❌ Incorreta
Configurar tabindex="-1" em elementos interativos para "evitar excesso de tab stops" é uma violação grave de acessibilidade. O tabindex="-1" remove o elemento do fluxo natural de tabulação, tornando-o inacessível por teclado — o que contradiz diretamente o requisito de "foco via teclado" do enunciado. Elementos interativos devem ser alcançáveis por Tab; escondê-los do fluxo de tabulação quebra a navegação para usuários de teclado. Se há excesso de tab stops, a solução é revisar a estrutura da página, não esconder elementos interativos.
Alternativa E — ✅ Correta ⟵ GABARITO
Preferir elementos HTML nativos para o papel e aplicar WAI-ARIA apenas para complementar a semântica quando o HTML não for suficiente é exatamente a recomendação das boas práticas de acessibilidade. O <button> nativo já fornece papel, estado, suporte a teclado e nome acessível por padrão. O ARIA deve ser usado apenas quando não existe um elemento HTML adequado — por exemplo, para criar um tablist, um dialog ou um menu que não têm equivalentes nativos. Essa abordagem garante compatibilidade com leitores de tela, automação de testes e comportamento consistente, como exige o enunciado.
Gabarito: letra E
Qual decisão de projeto semântico atende melhor às boas práticas de HTML e WAI-ARIA?