Questão de Engenharia de Software — W3C, WCAG e WAI — FUNDATEC 2025

Acessibilidade Web: HTML semântico e WAI-ARIA

Gabarito: letra E. A decisão de projeto semântico mais alinhada às boas práticas de HTML e WAI-ARIA é preferir elementos HTML nativos para o papel e aplicar WAI-ARIA apenas para complementar a semântica quando o HTML não for suficiente. Isso porque elementos nativos como <button> já fornecem, por padrão, foco via teclado, comportamento consistente (Enter/Espaço), nome acessível e papel semântico correto, sem necessidade de implementação manual — exatamente o que o enunciado exige.

O problema central da questão é o uso de um <div> com role="button" e tabindex="0" para simular um botão. Embora essa técnica funcione em parte, ela exige que o desenvolvedor reimplemente manualmente comportamentos que o HTML nativo já oferece gratuitamente. O <button> nativo, por exemplo, já é focável, já responde a Enter e Espaço, já possui o papel button na árvore de acessibilidade e já é compatível com leitores de tela e automação de testes. Ao usar um <div>, o desenvolvedor precisa adicionar tabindex, handlers de teclado, role e ainda corre o risco de esquecer algum detalhe — como o comportamento de Espaço, que só dispara quando o botão está focado, ou a questão do event.key === ' ' que pode não funcionar em todos os navegadores.

A WAI-ARIA (Accessible Rich Internet Applications) foi criada justamente para preencher lacunas quando o HTML não oferece um elemento nativo para o papel desejado — como em widgets complexos (menus, abas, sliders, autocomplete). Para um simples botão que dispara uma ação, o HTML já tem o elemento perfeito: <button>. Usar ARIA para "simular" um botão em um <div> é considerado uma prática ruim, pois duplica o esforço e aumenta a chance de inconsistências. A regra de ouro é: primeiro use o elemento nativo; só use ARIA quando não houver alternativa nativa.

Na prática, a diferença é enorme. Com <button>, o navegador cuida de tudo: o foco via Tab, a ativação com Enter e Espaço, o papel button no accessibility tree, e o nome acessível vindo do conteúdo textual. Com <div role="button">, o desenvolvedor precisa reimplementar cada um desses comportamentos manualmente, e qualquer esquecimento quebra a acessibilidade. Além disso, elementos nativos são mais compatíveis com automação de testes, pois os seletores e eventos são padronizados.

A pegadinha da banca está em fazer o candidato acreditar que a técnica do <div role="button"> é equivalente ao <button> nativo, quando na verdade ela é uma solução de contorno que deve ser evitada sempre que houver alternativa nativa. A alternativa A, por exemplo, tenta justificar a manutenção do código legado, mas ignora que a refatoração para <button> é simples e traz benefícios imediatos de acessibilidade e manutenibilidade.

Guarde o critério decisivo: elemento nativo primeiro, ARIA como complemento. É exatamente essa hierarquia que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Afirma que manter <div role="button" tabindex="0"> com handlers de teclado torna o controle equivalente a <button> sem custos de refatoração. Isso é falso: a técnica de simulação exige reimplementar manualmente comportamentos que o nativo já oferece, como o disparo de Espaço (que no <div> só funciona com o handler onkeydown), e ainda assim pode haver inconsistências entre navegadores. A refatoração para <button> é simples e elimina esses riscos. A banca tenta fazer o candidato acreditar que a manutenção do código legado é uma boa prática, quando na verdade a substituição pelo elemento nativo é a decisão correta.

Alternativa B — ❌ Incorreta

Propõe substituir links de navegação por <span role="link">, acionando com JavaScript e evitando o comportamento padrão do navegador. Isso é exatamente o oposto da boa prática: links devem ser <a href>, que já fornecem navegação nativa, foco via teclado e comportamento de Enter. Usar <span role="link"> exige reimplementar tudo manualmente e ainda perde funcionalidades como abrir em nova aba, copiar endereço e histórico. A banca inverte o princípio: em vez de usar o nativo, propõe substituir o nativo por uma simulação.

Alternativa C — ❌ Incorreta

Sugere remover o rótulo visível e ficar só com um ícone, confiando em title ou aria-label para o nome acessível. Isso viola as diretrizes de acessibilidade, que recomendam que o nome acessível seja visível sempre que possível. O title só aparece no hover do mouse, não é acessível por teclado, e o aria-label pode não ser anunciado corretamente em todos os leitores de tela. A boa prática é manter o texto visível ou usar aria-label apenas quando o rótulo visual não for possível, mas nunca remover o rótulo visível sem necessidade. A banca tenta fazer o candidato acreditar que reduzir "ruído visual" justifica sacrificar a acessibilidade.

Alternativa D — ❌ Incorreta

Propõe configurar tabindex="-1" em elementos interativos para "evitar excesso de tab stops", deixando o foco chegar apenas por JavaScript. Isso é uma péssima prática de acessibilidade: tabindex="-1" remove o elemento da ordem de tabulação, impedindo que usuários de teclado o alcancem naturalmente. O foco via JavaScript é imprevisível e não substitui a navegação padrão por Tab. Elementos interativos devem ser focáveis por teclado, e tabindex="0" é o valor correto para incluí-los na ordem natural. A banca tenta fazer o candidato acreditar que reduzir tab stops melhora a experiência, quando na verdade prejudica a acessibilidade.

Alternativa E — ✅ Correta ⟵ GABARITO

Esta é a decisão correta: preferir elementos HTML nativos para o papel e aplicar WAI-ARIA apenas para complementar a semântica quando o HTML não for suficiente. O <button> nativo já fornece foco via teclado, comportamento consistente (Enter/Espaço), nome acessível e papel semântico correto, sem necessidade de implementação manual. A WAI-ARIA deve ser usada apenas para preencher lacunas quando não há elemento nativo, como em widgets complexos. Essa é a regra de ouro da acessibilidade web, alinhada às recomendações do W3C e da WCAG.

Gabarito: letra E