Semântica e estrutura

O problema

Muita interface parece ótima na tela e péssima por baixo.

Você olha e encontra:

• div fingindo ser botão
• título fora de ordem só para acertar tamanho
• bloco importante sem main, nav ou qualquer significado estrutural

Visualmente pode até funcionar.

Mas, para quem navega pela estrutura da página, a experiência já começa quebrada.

E o pior é que isso costuma ser tratado como detalhe, quando na prática é fundação.

Modelo mental

Pensa assim:

semântica é a forma como o HTML explica a intenção da interface antes de qualquer maquiagem.

Se você tira o CSS e ainda consegue entender:

• o que é navegação
• o que é conteúdo principal
• o que é título
• o que é ação clicável

então a estrutura está saudável.

Se sem CSS tudo vira um monte de bloco neutro, a interface provavelmente está apoiada demais em aparência e de menos em significado.

Quebrando o problema

Elemento nativo carrega significado de graça

Essa é uma das maiores fontes de ruído em frontend.

Se a ação é clicar para executar algo, o ponto de partida natural é:

• <button>

Se a ação é navegar para outro lugar, o ponto de partida natural é:

• <a>

Trocar isso por div com clique manual cria trabalho extra e costuma quebrar comportamento esperado para teclado, foco e tecnologia assistiva.

Título não é só tipografia

Hierarquia de títulos não serve só para dizer tamanho visual.

Ela organiza leitura e navegação.

Quando você pula de h1 para h4 só porque gostou do estilo, a página continua “bonita”, mas a estrutura fica menos compreensível para quem depende dela.

Regiões ajudam a página a se explicar

Elementos como:

• <main>
• <nav>
• <header>
• <footer>
• <section>

ajudam a página a comunicar onde cada parte começa e termina.

Isso não substitui conteúdo claro.

Mas evita que a página vire um grande bloco indiferenciado.

CSS não deveria carregar o significado sozinho

Esse é um erro comum.

O time usa classes, espaçamento e cor para mostrar que algo “parece botão” ou “parece título”, mas o DOM não sustenta essa intenção.

Quando isso acontece, a semântica da interface depende demais da camada visual.

E isso normalmente cobra caro em acessibilidade e manutenção.

Exemplo simples

Imagina um card com a ação “Ver detalhes”.

Uma versão ruim fica assim:

<div onclick="openDetails()">
  Ver detalhes
</div>

Visualmente pode até parecer aceitável.

Estruturalmente, não comunica direito que aquilo é uma ação.

Uma versão melhor começa assim:

<button type="button" onClick={openDetails}>
  Ver detalhes
</button>

O ganho não é “obedecer regra de HTML”.

É fazer o navegador entender que aquilo é um botão de verdade, com comportamento e semântica coerentes desde a base.

Erros comuns

• Usar div para quase tudo por conveniência.
• Escolher heading pelo tamanho visual, não pela hierarquia.
• Deixar a estrutura da interface ser decidida só por CSS.
• Tentar “corrigir” semântica ruim mais tarde com remendo.
• Tratar HTML semântico como preciosismo em vez de arquitetura da UI.

Como um senior pensa

Quem tem mais experiência costuma olhar para a interface em camadas.

Antes de estado, animação ou design refinado, ele pergunta:

o DOM já está provando o que essa interface é?

Essa pergunta parece simples, mas muda bastante a qualidade da base.

Senioridade aqui aparece em construir UI que se explica melhor, exige menos remendo e conversa melhor com o navegador desde o início.

O que o entrevistador quer ver

Em entrevista de frontend, esse assunto mostra maturidade real.

O avaliador quer ver se você:

• trata o DOM como estrutura, não só como superfície para CSS
• escolhe elemento pelo papel funcional
• entende que acessibilidade começa cedo
• evita remendo quando o problema é de fundação

Uma resposta forte costuma soar assim:

Antes de pensar em ARIA ou ajuste fino, eu quero garantir que o HTML já representa a intenção correta da interface. Se é ação, uso elemento de ação. Se é navegação, uso elemento de navegação. Se a estrutura não se explica sem CSS, a base da acessibilidade já nasceu fraca.

Acessibilidade começa na estrutura, não no remendo.

HTML sem intenção clara vira custo escondido para todo o resto do frontend.