Acessibilidade na prática: HTML semântico, foco e ARIA

Existe uma verdade sobre acessibilidade na web que muda a forma de encará-la: na maioria dos casos, ela não é uma camada extra que você adiciona no fim, mas uma consequência de construir as coisas do jeito certo desde o começo. Uma página feita com os elementos corretos, na ordem correta, com atenção a como as pessoas navegam por ela, já nasce em grande parte acessível. É quando construímos com atalhos — usando o elemento errado, ignorando quem não usa mouse, reinventando componentes que o navegador já oferece prontos — que a acessibilidade se perde e precisa ser reconstruída dolorosamente por cima.

O erro mais comum é imaginar que acessibilidade se resume a adicionar atributos especiais aqui e ali, colar rótulos técnicos em elementos, cumprir uma lista de conformidade. Na verdade, a base é muito mais fundamental e muito mais simples: usar o HTML pelo que ele significa, garantir que tudo seja alcançável e operável sem mouse, e recorrer a ferramentas de anotação apenas quando o HTML sozinho não dá conta. Fazer isso bem beneficia não só quem usa leitores de tela ou navega só pelo teclado, mas todo mundo, porque uma interface clara e bem estruturada é melhor para qualquer pessoa.

Neste artigo vamos percorrer os três pilares práticos da acessibilidade: o HTML semântico, que é a fundação; o gerenciamento do foco, que garante que a página seja navegável sem mouse; e o uso criterioso das anotações de acessibilidade, com a regra de ouro de que menos é mais. O objetivo é sair da ideia de acessibilidade como checklist e chegar ao entendimento de como ela nasce naturalmente de construir bem.

HTML semântico: a fundação de tudo#

O HTML tem elementos que carregam significado. Um <button> não é apenas uma caixa clicável; ele comunica ao navegador e às tecnologias assistivas que aquilo é um botão, que pode ser acionado, que responde ao teclado. Um <a> é um link que leva a algum lugar. Um <nav> é uma região de navegação; um <main> é o conteúdo principal; um <h1> até <h6> estabelecem uma hierarquia de títulos. Cada um desses elementos vem com comportamento e significado embutidos, e usá-los pelo que eles são é o ato mais impactante de acessibilidade que existe.

A tentação moderna é construir tudo com elementos genéricos — a <div> para tudo — e adicionar comportamento por cima com estilo e código. Uma <div> estilizada para parecer um botão e com um manipulador de clique visualmente funciona como botão, mas não é um. Ela não comunica que é um botão, não responde ao teclado, não aparece para quem navega por elementos interativos. Para um usuário de leitor de tela, ela é invisível como controle; para quem usa só o teclado, ela é inalcançável. Todo o comportamento que o <button> traz de graça precisa ser reconstruído manualmente, e quase sempre é reconstruído incompleto.

Por que o elemento certo poupa trabalho#

O argumento decisivo a favor do HTML semântico é que ele é menos trabalho, não mais. Ao usar um <button> de verdade, você ganha, sem escrever nada, o acionamento por teclado, o foco, o anúncio correto para tecnologias assistivas e a integração com todos os comportamentos que o usuário espera de um botão. Ao usar uma <div> fingindo ser botão, você precisa adicionar manualmente a possibilidade de receber foco, os manipuladores de teclado para as teclas de acionamento, a anotação que diz que é um botão, e ainda assim provavelmente esquecer algum detalhe. Construir com semântica é deixar o navegador fazer o trabalho pesado; construir com elementos genéricos é assumir esse trabalho todo e fazer pior. A escolha semântica é a preguiçosa no bom sentido: menos código, mais robustez.

Estrutura e hierarquia#

A semântica vai além dos controles individuais; ela organiza a página inteira. Os títulos de diferentes níveis criam um esboço do documento, uma estrutura hierárquica que quem usa leitor de tela navega diretamente, pulando de seção em seção como se usasse um índice. Se os níveis são usados corretamente — um título principal, subtítulos abaixo dele, sub-subtítulos abaixo desses —, a página ganha um mapa navegável. Se os títulos são escolhidos pela aparência em vez do significado, saltando níveis ou usando um título grande só porque fica bonito, esse mapa fica quebrado e a navegação por estrutura falha.

Da mesma forma, marcar as grandes regiões da página — a navegação, o conteúdo principal, o rodapé, as áreas complementares — com os elementos apropriados permite que o usuário salte direto para a parte que interessa, sem percorrer tudo linearmente. Esses marcos são especialmente valiosos porque uma pessoa que usa leitor de tela não vê a página de relance como quem enxerga; ela a percorre em sequência, e ter pontos de referência claros é o que lhe permite se orientar rápido. A estrutura semântica é, para quem não vê, o equivalente ao layout visual que orienta quem vê.

Foco: navegar sem mouse#

O segundo pilar é o foco. Muita gente navega na web sem mouse — usando o teclado, ou tecnologias que simulam o teclado — e para essas pessoas o conceito de foco é central. O foco é o elemento que está "ativo" no momento, o que receberá a próxima ação. Ao apertar a tecla de tabulação, o foco pula de um elemento interativo para o próximo, e é assim que se navega: link a link, campo a campo, botão a botão. Se o foco não funciona bem, a página inteira fica inacessível para quem depende dele.

Dois aspectos do foco são inegociáveis. O primeiro é que todo elemento interativo precisa ser alcançável pelo foco — precisa entrar na sequência de tabulação. Elementos semânticos entram automaticamente; controles fabricados com elementos genéricos, não, e é por isso que eles frequentemente ficam inalcançáveis. O segundo é que o foco precisa ser visível: precisa haver uma indicação clara de qual elemento está com o foco no momento, tipicamente um contorno. Remover essa indicação visual, algo que se faz às vezes por achá-la feia, cega quem navega por teclado — a pessoa perde a noção de onde está na página. A indicação de foco não é um detalhe estético descartável; é a bússola de quem não usa mouse.

A ordem do foco e o gerenciamento em interfaces dinâmicas#

A ordem em que o foco percorre a página deve seguir a ordem lógica do conteúdo, e isso normalmente acontece sozinho quando a marcação está na ordem certa. Problemas surgem quando a ordem visual, alterada por estilo, diverge da ordem da marcação: o foco pula de forma confusa, saltando pela tela de um jeito que não faz sentido. Manter a ordem da marcação coerente com a ordem visual resolve isso.

Em interfaces dinâmicas, o foco precisa de gerenciamento ativo. Quando uma janela sobreposta se abre, o foco deve ir para dentro dela, e enquanto ela estiver aberta o foco deve ficar contido ali, sem escapar para o conteúdo atrás — caso contrário, quem usa teclado navega para trás da janela sem perceber. Quando a janela fecha, o foco deve voltar para onde estava antes. Esse cuidado de mover o foco no momento certo é o que faz componentes dinâmicos serem tão utilizáveis por teclado quanto por mouse. É um trabalho que quem usa mouse nunca percebe, mas que é a diferença entre uma janela usável e uma armadilha para quem depende do foco.

ARIA: a regra de ouro é usar pouco#

O terceiro pilar são as anotações de acessibilidade, conhecidas pela sigla ARIA. Elas permitem adicionar informação semântica que o HTML sozinho não expressa — dizer que um elemento é de um tipo específico, descrever seu estado, rotular algo que não tem texto visível. São ferramentas poderosas para componentes complexos que o HTML não cobre nativamente.

E aqui vem a regra que mais gente ignora: a primeira regra do ARIA é não usar ARIA. Isso soa paradoxal, mas é o conselho mais importante do assunto. Sempre que existe um elemento HTML nativo que faz o trabalho, usá-lo é melhor do que fabricar um elemento genérico e anotá-lo com ARIA para simular o nativo. O ARIA não adiciona comportamento — ele só adiciona informação. Anotar uma <div> como sendo um botão faz o leitor de tela anunciá-la como botão, mas não a torna acionável por teclado nem focável; você teria que adicionar tudo isso manualmente. Usar um <button> de verdade traria comportamento e semântica de uma vez. Por isso, o ARIA é o último recurso, não o primeiro.

Quando o ARIA realmente ajuda#

O ARIA brilha exatamente onde o HTML não alcança. Componentes ricos que não têm equivalente nativo — um conjunto de abas, um menu sofisticado, uma região que se atualiza sozinha e precisa anunciar as mudanças — se beneficiam de anotações que descrevem sua estrutura e seu estado para as tecnologias assistivas. Rotular um controle que só tem um ícone, sem texto visível, para que ele seja anunciado com sentido, é outro uso legítimo. Anunciar que uma parte da página mudou dinamicamente, para que quem não vê saiba que algo aconteceu, também.

O perigo do ARIA é usá-lo errado, e ARIA errado é pior que ARIA nenhum. Uma anotação que descreve o estado de um componente mas não é atualizada quando o estado muda passa informação falsa ao usuário — anuncia como aberto o que já fechou. Uma anotação que contradiz a semântica nativa confunde. Por isso o uso do ARIA exige rigor: só quando necessário, sempre correto, sempre mantido em sincronia com o estado real. Menos ARIA, bem-feito, vale infinitamente mais que muito ARIA descuidado.

Fechando#

A acessibilidade prática se apoia em três pilares que, na verdade, são apenas boa construção. O HTML semântico é a fundação: usar cada elemento pelo que ele significa entrega, sem esforço extra, comportamento e significado que beneficiam todos. O gerenciamento do foco garante que a página seja navegável e operável sem mouse, com todo controle alcançável e a posição do foco sempre visível e sensata. E as anotações de acessibilidade entram apenas onde o HTML não alcança, com a disciplina de que usá-las pouco e certo é melhor do que usá-las muito e mal.

O que amarra tudo é a percepção de que acessibilidade não é um imposto pago no fim do projeto, e sim o resultado de construir com atenção. A maior parte do que torna uma página acessível são decisões que também a tornam mais clara, mais robusta e mais fácil de manter para todo mundo. Quando você escolhe o elemento certo, respeita a hierarquia, cuida do foco e recorre ao ARIA com parcimônia, você não está fazendo um favor a um grupo específico — está construindo bem, e construir bem inclui, por natureza, as pessoas que navegam de formas diferentes da sua. Essa é a mudança de mentalidade que transforma acessibilidade de obrigação chata em critério de qualidade.