Um botão de orçamento fixo no rodapé pode facilitar o contato e ainda encobrir o último campo de um formulário. O problema aparece quando alguém navega pelo teclado, usa zoom ou abre o teclado virtual em uma tela pequena. Para reduzir o risco, trate cabeçalho, aviso e botão fixo como partes da mesma página. Teste as combinações antes de reservar um lugar permanente para cada barra.

O que significa um controle com foco encoberto?

É um controle que recebe foco, mas fica atrás de uma camada da própria interface. Por exemplo, a tecla Tab leva o foco ao botão de enviar e o navegador rola a página. Uma faixa de consentimento permanece na frente do botão, que a pessoa pode até acionar sem conseguir localizar visualmente. Em telas baixas, um cabeçalho fixo e um aviso inferior podem comprimir a região útil ao mesmo tempo.

O critério 2.4.11 das WCAG 2.2, explicado pelo W3C, trata do nível mínimo em que um componente com foco por teclado não deve ficar totalmente escondido por conteúdo criado pela página. Para uma experiência mais clara, busque preservar também a leitura do rótulo e do estado inteiro do controle. Um botão parcialmente visível pode exigir esforço extra para identificar o que será acionado.

O WebAIM Million de 2026 acompanha erros detectáveis automaticamente em uma grande amostra de páginas iniciais. Os resultados ajudam a dimensionar problemas de acessibilidade na web, mas a avaliação automática cobre apenas parte deles. O encobrimento merece um teste de percurso, porque depende da sequência de foco, do tamanho da janela e do estado das camadas.

Por que cada barra parece aceitável sozinha?

Projetos costumam aprovar o cabeçalho na tela de navegação, o aviso em um arquivo de consentimento e o botão de contato na página de serviço. Cada peça usa pouco espaço quando aparece isolada. Na primeira visita real, as três podem abrir juntas. Se a pessoa ampliar o texto, o aviso pode passar de uma linha para três, e um botão com rótulo longo pode crescer em altura.

Mapeie as camadas por estado. Anote o que aparece no carregamento, o que entra depois de uma rolagem e o que só surge após uma ação. Separe situações que realmente precisam coexistir das que podem se revezar. Em uma página de solicitação de orçamento, por exemplo, faz sentido discutir se o atalho comercial deve continuar fixo enquanto a própria pessoa preenche o formulário que ele oferece.

Registre no protótipo o que deve acontecer quando a altura fica curta. Uma opção é colocar o atalho de contato no fluxo normal em regiões com pouco espaço. Outra é mostrar o atalho em pontos específicos do conteúdo. Mantenha um caminho visível para chegar à tarefa, pois a mudança de posição precisa continuar compreensível para quem está acostumado a procurar a ação no rodapé.

Como coordenar as camadas durante o desenvolvimento?

Comece identificando qual elemento rola. Em alguns sites, é o documento inteiro. Em outros, uma gaveta tem rolagem própria. A área que efetivamente rola precisa levar em conta o espaço ocupado pelas camadas. Propriedades como scroll-padding-block-start e scroll-padding-block-end ajudam a definir margens úteis para operações de rolagem. Confirme o comportamento de foco em cada navegador que a equipe suporta.

Reserve espaço no fluxo quando uma barra inferior persistente puder cobrir o fim da página. Se a altura varia com texto e idioma, um número fixo exige cuidado. Uma faixa de consentimento que era baixa no protótipo pode crescer com o texto real. Considere também o recuo inferior dos dispositivos que reservam área para gestos. Teste a combinação com o teclado virtual aberto, que altera o espaço disponível em muitos aparelhos.

Diferencie avisos comuns de diálogos que realmente suspendem o restante da página. Um aviso integrado pode oferecer controles na ordem normal do documento. Se a tarefa exige um diálogo modal, o foco deve entrar nele e retornar a um ponto coerente quando fechar. Organizar essa sequência evita que a pessoa navegue atrás de uma camada opaca. O guia sobre foco visível em interfaces cobre como tornar perceptível o controle que recebeu o foco.

Como reproduzir o problema em uma auditoria?

Abra uma janela estreita e baixa, com o armazenamento limpo para reproduzir a primeira visita. Use Tab para ir do cabeçalho ao formulário. Depois volte com Shift e Tab, pois o sentido inverso pode revelar outros controles cobertos. Repita com o aviso fechado e em uma página interna onde o cabeçalho muda de altura. Anote em que momento a rolagem se ajusta.

Teste também os atalhos que movem o foco por ação direta. Um link para pular ao conteúdo pode terminar atrás do cabeçalho fixo. Um erro de preenchimento pode mover o foco a um campo escondido pela faixa inferior. Quando o projeto oferece navegação rápida, o guia sobre links para pular ao conteúdo ajuda a revisar o destino desse atalho.

Passe por um aparelho real. Amplie o conteúdo quando o navegador permitir, gire a tela e acione o teclado virtual em campos próximos do final. Experimente uma página com aviso longo e outra com texto mais curto. Capture a sequência completa da falha, incluindo a tecla ou a ação que moveu o foco. A imagem parada mostra a sobreposição, enquanto o percurso indica como reproduzi-la.

O que incluir no critério de aceite?

Para cada página importante, escreva um cenário com condição inicial, ação e resultado esperado. Em uma página de orçamento, o cenário pode começar com o banner de consentimento aberto e o zoom ampliado. Ao navegar até o botão de enviar, o botão e seu estado de foco devem ficar visíveis e a pessoa deve conseguir voltar aos campos anteriores. Registre a largura, a altura e o navegador usados.

Repita os cenários após mudanças em textos de consentimento, no cabeçalho e no formulário. Uma alteração pequena no tamanho de uma barra pode reintroduzir o erro em uma página distante da edição original. Se as camadas pertencem a equipes diferentes, guarde uma lista compartilhada de combinações para validar antes de lançar qualquer atualização.

Como decidir se uma ação merece ficar fixa?

Observe a frequência com que a ação é usada durante a leitura e quanto espaço ela ocupa nas condições mais restritas. Um sumário fixo pode valer o espaço em uma página longa quando ajuda a navegar. Em um formulário curto, o mesmo recurso pode reduzir a área útil sem trazer vantagem equivalente. Compare os percursos com e sem a fixação usando os mesmos textos e o mesmo tamanho de tela.

Comece pela página onde há mais camadas concorrentes e teste uma tarefa completa de teclado, do primeiro acesso até a confirmação. Uma barra fixa cumpre sua função quando torna uma ação fácil de encontrar e permite que a pessoa continue encontrando todas as outras.

Como testar uma correção em páginas com conteúdo variável?

Compare páginas com formulários de alturas diferentes e insira mensagens de validação em mais de um campo. Quando uma mensagem cresce, ela pode deslocar o próximo controle para perto da barra. Teste também páginas em que o aviso tem uma ação adicional, porque o segundo botão pode fazer a faixa ocupar outra linha.

Se a interface usa um cabeçalho que encolhe ao rolar, inicie o teste tanto no topo quanto no meio da página. Navegar para trás com o teclado pode expandir o cabeçalho justamente quando o foco retorna à parte superior. Use essa diferença para definir em que estados o espaço reservado deve mudar.