Design responsivo além do celular: como planejar interfaces adaptáveis

Responsividade não é desenhar três tamanhos de tela. É preservar conteúdo, ordem e interação quando o contexto muda.

O layout funcionava no celular, mas quebrou com zoom A equipe havia testado a página em três larguras: desktop; tablet; celular. Tudo parecia correto. Durante uma revisão de acessibilidade, alguém aumentou o zoom do navegador para 400%. A área útil ficou estreita, o menu cobriu o título e os botões de um cartão desapareceram fora da tela. O site era “mobile friendly”, mas não era realmente adaptável. Design responsivo não é produzir três layouts para categorias de dispositivo. É permitir que conteúdo e controles continuem utilizáveis quando mudam: largura; altura; resolução; zoom; tamanho de fonte; quantidade de conteúdo; idioma; orientação; método de entrada; preferências do usuário. A MDN define design responsivo como uma abordagem para fazer páginas funcionarem adequadamente em diferentes tamanhos e resoluções, preservando usabilidade. Laboratório: o cartão que depende de espaço demais Considere este componente: Uma implementação frágil poderia usar: Problemas: largura fixa; altura fixa; imagem que não encolhe; texto sujeito a corte; ações sem quebra; comportamento dependente do espaço ideal. Primeira correção: deixe o conteúdo definir a altura A remoção da altura fixa permite que textos maiores ocupem o espaço necessário. max width ou width: min() limita a expansão sem impedir redução. flex wrap preserva ações quando não cabem em uma linha. Regra útil Evite definir altura em componentes com texto variável, salvo quando o comportamento de excesso estiver explicitamente projetado. Conteúdo real pode crescer por: tradução; preferência de fonte; zoom; título mais longo; mensagem de erro; dados vindos de API; personalização. Segunda correção: escolha o breakpoint pelo componente Breakpoints não precisam corresponder a modelos de telefone. O cartão pode mudar quando o conteúdo deixa de caber: A unidade rem acompanha o tamanho de fonte raiz e pode ser mais adequada do que um valor fixo associado a um dispositivo. A documentação de media queries da MDN explica que condições podem considerar tamanho, mídia e outras características do ambiente. A pergunta correta não é “qual é o breakpoint de tablet?”. É “em qual espaço esta composição deixa de funcionar?”. Terceira correção: adapte se ao contêiner O cartão pode aparecer em uma página larga e também dentro de uma coluna estreita. Se ele responder apenas ao viewport, poderá assumir um layout horizontal mesmo sem espaço local. As container queries permitem consultar o tamanho do elemento que contém o componente. Isso melhora a portabilidade. O componente decide sua composição a partir do espaço recebido, não de uma suposição sobre a página inteira. Container queries não substituem todas as media queries. Use media queries para condições globais: viewport; impressão; orientação; preferências; entrada. Use container queries para composição local de componentes. Reflow: quando o zoom simula uma tela estreita O critério 1.4.10 da WCAG 2.2 trata de reflow , ou reorganização do conteúdo. A explicação do W3C sobre reflow descreve o objetivo de permitir leitura com zoom sem exigir rolagem simultânea em duas dimensões, exceto em conteúdos que realmente dependem de apresentação bidimensional, como determinados mapas, tabelas e diagramas. O teste prático mais conhecido usa uma janela equivalente a 1280 pixels de largura com zoom de 400%, resultando em área próxima a 320 pixels CSS. Teste: 1. abra a página em desktop; 2. aumente o zoom para 400%; 3. percorra o conteúdo; 4. verifique se textos e controles continuam disponíveis; 5. observe elementos fixos; 6. procure rolagem horizontal; 7. teste formulários e diálogos. Elementos position: fixed são fontes frequentes de obstrução. Um cabeçalho alto pode consumir quase todo o viewport após o zoom. A ordem visual não deve contradizer a ordem do documento CSS Grid e Flexbox permitem reorganizar elementos visualmente. Isso não altera necessariamente a sequência percorrida por teclado ou lida por tecnologias assistivas. Exemplo perigoso: A barra aparece antes visualmente, mas pode continuar depois no DOM. Uma pessoa que usa teclado poderá encontrar o foco em ordem diferente da interface visual. O guia de design responsivo acessível do web.dev recomenda cuidado para não desconectar a ordem visual da ordem do código. A sequência do HTML deve fazer sentido sem CSS. Hover não pode carregar informação essencial Menus e cartões frequentemente revelam conteúdo apenas quando o mouse passa sobre um elemento. Isso falha para: telas de toque; teclado; comando por voz; alguns dispositivos híbridos; pessoas que ampliam a interface. A media feature any hover verifica se algum mecanismo disponível consegue realizar hover de forma conveniente. A informação permanece disponível. O hover apenas adiciona ênfase. Nunca esconda uma ação indispensável exclusivamente atrás de hover. Toque, mouse e teclado precisam coexistir Um dispositivo com tela grande pode usar toque. Um celular pode ter teclado conectado. Um notebook pode combinar touchpad e touchscreen. Evite inferir método de entrada apenas pela largura. Controles devem: possuir área acionável adequada; apresentar foco visível; funcionar com Enter e Espaço quando apropriado; não depender de precisão excessiva; manter distância entre ações destrutivas; fornecer estado pressionado ou selecionado; continuar utilizáveis sem hover. Use elementos nativos: em vez de: O botão já possui semântica, foco e comportamento de teclado. Texto responsivo não significa texto proporcional à tela Esta regra pode gerar extremos: Em telas muito largas, o título cresce demais. Em espaços estreitos, pode ficar pequeno. Use limites: Também limite o comprimento das linhas: Não fixe o tamanho de texto do corpo em valores muito pequenos. Respeite preferências do navegador e teste aumento de texto. Imagens precisam responder ao contexto Uma imagem maior do que o necessário desperdiça transferência. Uma imagem cortada sem critério pode remover conteúdo importante. Base: Para imagens com diferentes resoluções: As dimensões ajudam a reservar espaço e reduzir mudanças de layout. O impacto de mídia no carregamento é aprofundado em performance web. Tabelas não viram cartões automaticamente Tabelas são adequadas para dados relacionais. Em espaços estreitos, existem opções: rolagem horizontal localizada; redução de colunas; visualização resumida; filtros; divisão da informação; layout alternativo cuidadosamente construído. Exemplo com rolagem localizada: O tabindex pode tornar a região rolável alcançável por teclado em determinados contextos, mas precisa ser testado com navegadores e tecnologias assistivas. Não aplique indiscriminadamente. Transformar cada linha em cartão pode destruir relações entre cabeçalhos e células. Preserve a semântica quando a informação for realmente tabular. Componentes que merecem testes específicos Navegação menu aberto e fechado; foco ao abrir; fechamento por teclado; conteúdo não encoberto; orientação e zoom. Diálogos largura e altura máximas; conteúdo rolável; foco confinado adequadamente; botão de fechamento visível; teclado virtual. Formulários rótulos; erros longos; campos lado a lado; preenchimento automático; teclado móvel; zoom. Cards título longo; ausência de imagem; múltiplas ações; preço grande; conteúdo traduzido. Dashboards filtros; tabelas; gráficos; painéis laterais; atualização dinâmica; alta densidade de dados. Matriz de testes responsivos Não teste apenas resoluções. Teste condições. Condição O que observar 320 pixels CSS reflow e rolagem horizontal 400% de zoom conteúdo encoberto e elementos fixos texto ampliado corte e sobreposição teclado ordem e foco toque tamanho e espaçamento de alvos sem hover informações e ações disponíveis conteúdo longo altura, quebra e alinhamento idioma diferente expansão de rótulos conexão lenta estados de carregamento orientação horizontal altura reduzida impressão conteúdo essencial e quebras tema escuro, quando houver contraste e estados O artigo sobre acessibilidade web no projeto amplia os testes de teclado, semântica e formulários. Responsividade começa no protótipo Quando o design entrega apenas uma tela larga e uma tela móvel, a implementação precisa inventar todos os estados intermediários. Durante o processo de desenvolvimento do site, registre: o que empilha; o que quebra linha; o que pode rolar; o que permanece fixo; o que muda de ordem; o que pode ser resumido; como estados vazios aparecem; como erros alteram o componente; como o foco se comporta; quais elementos dependem de entrada. O objetivo não é desenhar dezenas de telas. É documentar regras de adaptação. A pergunta final para cada componente Não pergunte apenas “funciona no celular?”. Pergunte: Este conteúdo continua compreensível e acionável quando recebe menos espaço, mais texto, outro método de entrada ou uma preferência diferente? Essa mudança de pergunta transforma responsividade de uma lista de resoluções em uma propriedade real da interface.