--- title: "Acessibilidade em apps móveis: guia prático | GoodBarber" description: "Não é possível comprovar que um app é acessível por meio de uma prévia ou de uma pontuação de contraste. No entanto, é possível remover uma quantidade surpreend" canonical_url: "https://pt.goodbarber.com/blog/acessibilidade-em-apps-moveis-como-tornar-seu-app-mais-acessivel-a1334/" lang: pt date: 2026-08-20 last_updated: 2026-08-20 --- # Acessibilidade em apps móveis: guia prático | GoodBarber [Voltar](/blog/make-it-r19/) # Acessibilidade em apps móveis: como tornar seu app mais acessível Escrito por [Marc Leonardi](https://pt.goodbarber.com/blog/author/marc-leonardi/) na Quinta-Feira 20 Agosto 2026 ## A acessibilidade em apps móveis ajuda pessoas com deficiências visuais, auditivas, motoras ou cognitivas a perceber o conteúdo, entender a interface e concluir as principais tarefas. Pioramos deliberadamente uma cópia do Lotus Yoga, um dos nossos apps de demonstração, para depois reconstruí-la no GoodBarber e testar o que a prévia pode — e não pode — comprovar. ## A acessibilidade móvel começa com um sistema ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053392.jpg?v=1787262323.7500894) Não é possível comprovar que um app é acessível por meio de uma prévia ou de uma pontuação de contraste. No entanto, é possível remover uma quantidade surpreendente de barreiras antes do início dos testes formais. A acessibilidade móvel vai muito além do contraste de cores. Tipografia, espaçamento, navegação, áreas de toque, rótulos, movimento, mídia e comportamento com tecnologias assistivas também determinam se uma pessoa consegue concluir uma tarefa. As WCAG foram escritas para conteúdo web. As orientações [WCAG2Mobile do W3C](https://www.w3.org/TR/wcag2mobile-22/) explicam como aplicar os critérios de nível A e AA das WCAG 2.2 a apps móveis nativos, web e híbridos. O documento é informativo, não uma norma móvel separada, e sozinho não basta para estabelecer que um app seja acessível. Esta checklist separa o que pode ser configurado de forma centralizada do que ainda precisa ser verificado no produto publicado: | Área de acessibilidade | Primeira verificação | O que configurar ou testar | | ------------------------ | ---------------------------------------------- | ------------------------------------------------------------------------- | | Contraste de cores | Textos, fundos, controles e estados | Definir as cores globais e verificar cada combinação de contraste | | Tipografia e espaçamento | Padrões legíveis, quebra de linha e ampliação | Configurar a hierarquia tipográfica e as margens globais | | Navegação | Destinos e rótulos claros | Configurar a estrutura, os rótulos e a navegação do app | | Áreas de toque | Controles fáceis de operar | Verificar o app gerado em dispositivos | | Leitores de tela | Nomes, funções, estados e ordem de foco | Testar os apps iOS e Android gerados | | Movimento | Efeitos úteis e opcionais | Configurar animações e resposta tátil e testar as preferências do sistema | | Mídia | Legendas, transcrições e alternativas em texto | Adicionar alternativas durante a criação e a revisão editorial | | Interação PWA | Teclado, zoom, foco e layouts responsivos | Testar a PWA publicada em navegadores | ## Lotus Yoga: bonito à primeira vista, frágil no uso ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053393.jpg?v=1787262325.7460995) Nada parecia obviamente quebrado nesta primeira tela. Esse era justamente o ponto útil do exercício: problemas de acessibilidade nem sempre são dramáticos; muitas vezes ficam escondidos em escolhas de design elegantes. Usamos texto claro sobre fundo claro, reduzimos o corpo do texto para 10 px, removemos as margens globais e mantivemos rótulos de navegação genéricos como “Videos” e “Podcasts”. O resultado ainda parecia tranquilo em uma apresentação. No celular, a hierarquia desmoronou: o texto secundário perdeu força, os cards ficaram próximos demais das bordas e a navegação inferior se tornou muito mais difícil de percorrer. A lição não é “nunca use tons pastéis” nem “deixe tudo grande”. As escolhas da marca precisam de um sistema legível por baixo. ## Etapa 1: corrigir o contraste como um sistema ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053394.jpg?v=1787262327.8421102) Começamos em **Meu App > Estilo do app > Cores** e atribuímos as cores de acordo com sua função. O fundo quente permaneceu. O que mudou foi a distância entre cada primeiro plano e seu fundo: | Elemento | Primeiro plano | Fundo | Proporção | | ------------------------ | -------------- | ------------- | --------- | | Texto principal | `#17332F` | Branco quente | 13,3:1 | | Texto secundário | `#4E6A65` | Branco quente | 5,8:1 | | Texto do botão principal | `#FFFFFF` | `#1F6D63` | 6,1:1 | | Título do header | `#17332F` | Verde-claro | 11,6:1 | As [WCAG 2.2 estabelecem uma proporção mínima de contraste](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) de 4,5:1 para texto normal e 3:1 para texto grande no nível AA. Deixamos deliberadamente uma margem maior no texto principal: uma combinação que passa no teste pode continuar fraca com uma fonte fina, um tamanho pequeno ou uma tela muito luminosa ao ar livre. O GoodBarber permite começar por um tema integrado, gerar uma paleta ou criar uma do zero. O benefício não está na quantidade de amostras, mas na reutilização. Textos do header e do corpo, separadores, botões e estados de navegação podem receber funções consistentes em todas as seções. A [documentação do Estilo do App](https://pt.goodbarber.com/help/shop/definir-a-identidade-visual-do-app-r87/estilo-do-app-configuracoes-de-design-essenciais-a317/) explica como essas escolhas globais são propagadas. Uma paleta legível é um ponto de partida forte, não um certificado de acessibilidade. Verifique cada combinação real de primeiro plano e fundo, incluindo estados selecionados, sobreposições, imagens e personalizações específicas de cada seção. ## Etapa 2: definir tipografia e espaçamento legíveis ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053395.jpg?v=1787262329.9981213) O contraste tornou as palavras visíveis. O tamanho e o espaçamento tornaram a leitura confortável. Selecionamos o tema de fontes Formateca, que combina Work Sans nos títulos com Manrope no corpo. Depois usamos o controle global de tipografia para reconstruir a hierarquia: o corpo do texto passou de 10 px para 16 px, o título principal chegou a 30 px e o conteúdo principal recuperou margens de 16 px. A escala tipográfica global do GoodBarber ajusta proporcionalmente oito níveis de texto. Isso facilita a manutenção de uma hierarquia consistente entre as telas, mas não garante um resultado acessível. Verifique os tamanhos, as quebras de linha e o espaçamento entre linhas no app gerado. As WCAG não determinam um tamanho mínimo universal para o corpo do texto. Os 16 px são o valor que escolhemos para esta interface, não um limite de conformidade. Um texto maior também precisa de mais espaço; caso contrário, os cards ficam apertados e os rótulos quebram de forma desconfortável. Por fim, teste o app com o tamanho de texto preferido pelo usuário. A [Apple recomenda oferecer ampliação de texto e Dynamic Type](https://developer.apple.com/design/human-interface-guidelines/accessibility), enquanto o conteúdo web deve continuar utilizável quando o texto é redimensionado. Uma prévia equilibrada no editor é apenas o primeiro estado a verificar. ## Etapa 3: fazer os rótulos da navegação descreverem o destino ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053396.jpg?v=1787262331.9621313) Nesta comparação de antes e depois, a TabBar original mostrava “Videos”, “Podcasts” e “Navigation”. Esses rótulos descreviam formatos ou mecanismos da interface, não o que uma pessoa da comunidade de yoga poderia fazer em seguida. Renomeamos para **Classes**, **Audio** e **More**. A estrutura não mudou, mas a decisão ficou mais simples: fazer uma aula, escolher uma sessão de áudio ou abrir as demais seções. As [orientações de acessibilidade do Android](https://developer.android.com/guide/topics/ui/accessibility/views/principles-views) recomendam rótulos úteis e descritivos para elementos interativos, pois serviços como o TalkBack podem anunciar seus nomes de acessibilidade. Alterar o título visível melhora a navegação visual; ainda é preciso verificar o que o componente gerado realmente expõe ao VoiceOver e ao TalkBack. Mantenha os rótulos curtos, únicos e orientados à tarefa. Combine ícones e texto quando houver espaço. Um teste simples: se os ícones desaparecessem, as palavras ainda indicariam o destino de cada toque? ## Etapa 4: tornar controles e conteúdo operáveis A acessibilidade falha quando o conteúdo pode ser visto, mas um controle é difícil de tocar, ou quando uma mídia essencial exclui um canal sensorial. Comece pelas áreas de toque. O [Android recomenda uma área focável de pelo menos 48 × 48 dp](https://developer.android.com/guide/topics/ui/accessibility/views/apps-views) para elementos interativos. Na PWA, o critério [Tamanho do alvo (mínimo)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) das WCAG 2.2 estabelece um mínimo de 24 × 24 pixels CSS no nível AA, sujeito às exceções definidas. O ícone visível pode ser menor que sua área operável, mas alvos vizinhos precisam continuar distintos. Em seguida, revise como o significado é comunicado. Erros, progresso e disponibilidade precisam de sinais que os usuários possam perceber. Imagens informativas necessitam de alternativas em texto; vídeos relevantes, de legendas; e conteúdo somente em áudio, de transcrição ou equivalente. Essas são decisões editoriais que um design consistente não pode automatizar por você. O GoodBarber centraliza a hierarquia, as cores e a forma dos botões por meio do Estilo do App. Use esses controles para reduzir inconsistências e depois verifique tamanho dos alvos, foco, rótulos e estados nas versões iOS, Android e PWA geradas. ## Etapa 5: usar movimento e resposta tátil com intenção O Lotus Yoga usava resposta tátil e uma animação de abertura. Em **Meu App > Estilo do app**, desativamos o efeito decorativo de abertura e mantivemos a resposta tátil nos apps nativos. O GoodBarber também oferece efeitos de rolagem na mesma área; as [opções de design adicionais do Estilo do App](https://pt.goodbarber.com/help/shop/definir-a-identidade-visual-do-app-r87/estilo-do-app-opcoes-adicionais-de-design-a511/) explicam onde esses controles ficam. Essa escolha não é uma regra universal de acessibilidade. O movimento pode explicar uma mudança de estado e a resposta tátil pode confirmar uma ação sem adicionar ruído visual. A questão é saber se o efeito transmite uma informação útil. Se não transmite, uma configuração mais calma é mais fácil de justificar. Não presuma que mudar a configuração no editor comprova suporte à redução de movimento. Teste o app publicado com as preferências de movimento do dispositivo ativadas e confirme que as tarefas completas continuam fazendo sentido sem o efeito. ## Etapa 6: testar jornadas completas nos apps nativos e na PWA ![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97759885-68053399.jpg?v=1787262333.9101412) Esta versão final é mais fácil de ler e navegar sem perder o caráter tranquilo da marca. Mais importante: as melhorias são sistêmicas. Uma única paleta, escala tipográfica e estrutura de espaçamento pode melhorar várias telas ao mesmo tempo. A prévia mostra cor, hierarquia, espaçamento, rótulos e estados visíveis. Ela não diz se cada anúncio do leitor de tela é útil, se o foco avança de forma lógica ou se uma jornada completa continua operável com um método de entrada alternativo. Antes da publicação: - Percorra os principais fluxos do iOS com VoiceOver e os do Android com TalkBack sem olhar para a tela. - Aumente o tamanho do texto do sistema e verifique cortes, sobreposições, controles ocultos e conteúdo perdido. - Confira se botões, links, formulários e menus possuem nomes, funções, estados e uma ordem de foco claros. - Teste a PWA com navegação por teclado, zoom do navegador e vários tamanhos de janela. As ferramentas automáticas detectam problemas importantes. Elas não entendem se um rótulo faz sentido, se uma instrução é cognitivamente clara ou se concluir uma tarefa é frustrante. Testes manuais — idealmente com pessoas com deficiência — continuam essenciais. ## Como o GoodBarber ajuda a criar uma base mais acessível A vantagem de um design system é seu efeito multiplicador. O GoodBarber constrói as telas a partir de fundamentos compartilhados e componentes reutilizáveis. Cor, tipografia, espaçamento, forma e navegação são regras reutilizadas em todo o app, não decorações isoladas. Você pode [conhecer o Design System do GoodBarber](https://pt.goodbarber.com/uxdesign/) para ver como essas camadas trabalham juntas. Esse efeito multiplicador também cria uma divisão clara de responsabilidades: | O GoodBarber ajuda a centralizar | Você ainda precisa verificar | | ----------------------------------------- | --------------------------------------------------------------- | | Funções globais de cor | Combinações reais de contraste e sinais que não dependam da cor | | Hierarquia tipográfica de oito níveis | Ampliação do texto, quebras de linha e cortes | | Margens, espaçamento e estilos de botões | Usabilidade das áreas de toque em dispositivos reais | | Estrutura de navegação e rótulos visíveis | Nomes de acessibilidade, funções, estados e ordem de foco | | Animações e resposta tátil nativa | Comportamento com as preferências de acessibilidade do sistema | | Saídas iOS, Android e PWA | Jornadas completas, conteúdo e integrações de terceiros | O Design System do GoodBarber elimina parte do trabalho repetitivo de acessibilidade ao aplicar regras compartilhadas de tipografia, cor, espaçamento e componentes em todo o app. Você ainda precisa validar a interface e o conteúdo resultantes em cada plataforma. ## FAQ **As WCAG se aplicam a apps móveis nativos?** As WCAG foram escritas para conteúdo web, mas seus princípios e critérios de sucesso são amplamente usados no trabalho de acessibilidade móvel. O rascunho WCAG2Mobile do W3C explica como aplicar os critérios de nível A e AA das WCAG 2.2 a apps móveis nativos, web e híbridos. As orientações são informativas: não constituem uma norma móvel separada nem garantem conformidade legal. **Um app builder pode criar automaticamente um app acessível?** Não. Componentes reutilizáveis, padrões legíveis e regras globais de design podem criar uma base mais sólida, mas a acessibilidade também depende da configuração, do conteúdo, dos recursos de terceiros e das jornadas completas. O app gerado ainda precisa ser testado. **O que devo testar primeiro em um app móvel existente?** Comece pelos caminhos que os usuários não podem evitar: abrir o app, navegar, entrar na conta, encontrar conteúdo e concluir a ação principal. Teste-os com leitor de tela, texto ampliado e movimento reduzido e depois confira áreas de toque, erros de formulário e alternativas de mídia. **Qual é o contraste mínimo de texto para um app móvel?** O nível AA das WCAG 2.2 estabelece uma proporção mínima de contraste de 4,5:1 para texto normal e 3:1 para texto grande. Esses limites também são usados com frequência ao avaliar interfaces móveis por meio das orientações WCAG2Mobile. Trate-os como um piso, não como um objetivo de design. **Onde altero essas configurações no GoodBarber?** Abra **Meu App > Estilo do app** para gerenciar cores globais, fontes, margens, botões, animações e resposta tátil. Os rótulos e layouts de navegação são configurados na estrutura do app. Acompanhe o resultado na prévia e depois teste as versões iOS, Android e PWA geradas antes de publicar. Um app acessível não é um estilo visual específico. É uma série de decisões que permite que mais pessoas percebam o conteúdo, entendam a interface e concluam a tarefa. [Crie seu app com o GoodBarber](https://pt.goodbarber.com/create), construa essa base uma vez e melhore-a com evidências de usuários reais. ![Marc Leonardi](https://blog.goodbarber.com/_public/profile/d4/d4a7d2d89eb08037d76fc10910f1f708ee738ec4-default.jpg) Sobre o autor[Marc Leonardi](https://pt.goodbarber.com/blog/author/marc-leonardi/)Backend & DevOps Engineer Sou engenheiro de Backend & DevOps na GoodBarber, onde trabalho nos sistemas e na infraestrutura que sustentam a nossa plataforma no-code de criação de aplicações. Desenvolvo e opero serviços backend, APIs e infraestrutura, com foco em fiabilidade, escalabilidade e automação. Escrevo sobre engenharia backend, DevOps, infraestrutura e os desafios técnicos de operar uma plataforma em grande escala. [Saiba mais](https://pt.goodbarber.com/blog/author/marc-leonardi/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/marc-leonardi-7bbab321b/)