Acessibilidade em Apps Móveis: Requisitos WCAG 2.2 para iOS e Android

Mais de 72% dos adultos com deficiência possuem um smartphone e, de acordo com uma pesquisa, cerca de 86% dos usuários de leitores de tela dependem de um dispositivo móvel — uma parcela maior do que usuários de desktop ou laptop. Ainda assim, as mesmas organizações que auditam seus sites religiosamente muitas vezes têm apps móveis que nunca foram testados em relação a um único critério de acessibilidade. Essa lacuna está se fechando rapidamente, impulsionada por regulamentações em evolução, aumento de litígios e — mais importante — pela própria orientação do W3C que mapeia explicitamente a WCAG 2.2 para aplicativos nativos iOS e Android.

Por que a WCAG 2.2 se aplica ao seu app móvel

Existe um mito persistente de que a WCAG é um padrão apenas para web. Não é. O W3C não possui diretrizes separadas para acessibilidade móvel — em vez disso, a acessibilidade móvel é tratada dentro da estrutura existente da WCAG, e o Mobile Accessibility Task Force (MATF) do W3C produziu uma orientação dedicada intitulada Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile), que mapeia cada critério de sucesso de Nível A e AA para apps móveis nativos, web apps móveis e apps híbridos.

A implicação prática é significativa. Quando você lê um critério de sucesso da WCAG que se refere a uma "web page", o documento WCAG2Mobile substitui essa linguagem por "screen" ou "view". Quando um critério discute um "user agent", ele se refere ao sistema operacional móvel. Os quatro princípios POUR — Perceptível, Operável, Compreensível, Robusto — se traduzem diretamente em como um usuário interage com uma view em SwiftUI no iOS ou um layout em Jetpack Compose no Android.

Do ponto de vista jurídico, a pressão deixou de ser teórica. Sob o Título II da ADA, regulamentos atualizados do DOJ publicados em abril de 2024 exigem explicitamente que governos estaduais e locais tornem seus aplicativos móveis acessíveis em WCAG 2.1 AA. Organizações de saúde que aceitam Medicare ou Medicaid enfrentam exigências semelhantes sob regras do HHS finalizadas em maio de 2024. E embora ações judiciais sobre apps móveis no setor privado ainda sejam menos frequentes do que processos envolvendo sites, pelo menos um autor de alto volume já mirou especificamente aplicativos móveis por falta de acesso equitativo sob a ADA, com expectativa de aceleração dessa tendência à medida que os prazos de conformidade do Título II chegam em 2026.

O European Accessibility Act (EAA), que entrou em vigor em 28 de junho de 2025 e se baseia na EN 301 549 como seu padrão técnico presuntivo, também exige conformidade com a WCAG 2.2 para produtos e serviços digitais, incluindo apps móveis vendidos ou oferecidos em mercados da UE. Para qualquer organização com base de usuários global, WCAG 2.2 em mobile não é uma aspiração futura — é uma obrigação presente.

O que mudou na WCAG 2.2 que mais importa para mobile

A WCAG 2.2, publicada como Recomendação do W3C em outubro de 2023, adiciona nove novos critérios de sucesso e remove o agora obsoleto 4.1.1 Parsing. Ela é totalmente retrocompatível: conformidade com 2.2 implica conformidade com 2.1 e 2.0. Vários dos novos critérios foram escritos com padrões de interação móvel explicitamente em mente, e mesmo aqueles formulados em torno do uso de teclado têm análogos diretos em tecnologias assistivas para iOS e Android.

Vale entender a linhagem aqui. Após 2018, o Mobile Accessibility Task Force garantiu que considerações móveis moldassem tanto a WCAG 2.1 quanto a 2.2. Critérios como 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) e os novos 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) e 3.3.7 Redundant Entry (A) refletem padrões específicos de usabilidade móvel identificados por meio de testes em cenários reais com usuários com deficiência em smartphones e tablets.

Os nove novos critérios de sucesso introduzidos na WCAG 2.2 miram barreiras específicas que usuários reais enfrentam: fluxos de login que penalizam qualquer pessoa com problemas de memória, interfaces que exigem mãos firmes para toques precisos, recursos de ajuda enterrados em partes diferentes de cada tela e indicadores de foco que desaparecem atrás de barras de navegação fixas. Cada critério corrige uma lacuna concreta — e quase todos têm aplicação direta em mobile.

Os novos critérios da WCAG 2.2 e como se aplicam a iOS e Android

2.5.8 Target Size Minimum (Nível AA)

Este é, provavelmente, o novo critério de maior impacto para equipes de mobile. Ele exige que alvos interativos — botões, links, campos de formulário, checkboxes, toggles — tenham tamanho mínimo de 24 × 24 pixels CSS, ou que exista um espaçamento de 24 pixels entre alvos adjacentes se o alvo em si for menor. A justificativa é simples: usuários com tremores nas mãos, doença de Parkinson ou destreza limitada acham genuinamente impossível tocar com confiabilidade em um botão de ícone de 16 pixels, e mesmo usuários sem deficiência cometem significativamente mais erros em alvos pequenos.

Para desenvolvimento móvel nativo, o mínimo de 24 × 24 da WCAG 2.2 é na verdade um piso, não um teto. As Human Interface Guidelines da Apple recomendam um alvo de toque mínimo de 44 × 44 points em iOS e iPadOS. O Material Design do Google recomenda 48 × 48 pixels independentes de densidade (dp) no Android. Se o seu app atende às diretrizes de plataforma da Apple ou do Google, você já excede o mínimo da WCAG 2.2 — mas muitos apps não atendem. Aqueles botões minúsculos de fechar em modais, os checkboxes finíssimos em telas de configurações e as ações de toolbar apenas com ícone que medem 20 × 20 dp são todas falhas de conformidade esperando para serem expostas em uma auditoria.

Uma nota prática: a exigência da WCAG diz respeito à área interativa de toque, não ao tamanho visual do ícone. Um ícone de 16 points envolto em 14 points de padding em cada lado tem um alvo de toque efetivo de 44 × 44 points. Isso significa que desenvolvedores podem satisfazer o critério sem ampliar visualmente os elementos — mas precisam definir esse padding deliberadamente, e não confiar que o sistema fará isso automaticamente.

2.5.7 Dragging Movements (Nível AA)

Este critério exige que qualquer funcionalidade implementada por meio de gesto de arrastar — sliders, reordenação por drag-and-drop, pull-to-refresh, scrub de carrossel — também possa ser realizada por uma ação de único ponteiro que não exija arrastar. Em iOS e Android, as tecnologias assistivas da própria plataforma tratam certos gestos de forma diferente, mas o app em si deve expor alternativas sem arraste para qualquer comportamento de arraste personalizado que implemente.

Na prática, isso significa que uma lista com reordenação por arraste deve oferecer uma alternativa como um botão de incremento/decremento "para cima/para baixo". Um slider de faixa personalizado que responde apenas a gesto de arrastar também deve responder a toques em pontos específicos ou fornecer botões de incremento/decremento. O critério não se aplica se o sistema operacional subjacente ou a tecnologia assistiva fornecer a alternativa automaticamente, mas os desenvolvedores devem testar isso explicitamente em vez de presumir que sempre será tratado pela plataforma.

2.4.11 Focus Not Obscured — Minimum (Nível AA) e 2.4.12 (Enhanced, Nível AAA)

Esses critérios abordam um padrão extremamente comum em apps web e móveis nativos: o elemento em foco ficar parcial ou totalmente oculto por UI fixa — uma barra de navegação inferior persistente, um botão de ação flutuante, uma toolbar superior que se sobrepõe à área rolável. O critério mínimo (Nível AA) exige que, quando um componente recebe foco, pelo menos parte dele permaneça visível. A versão aprimorada (Nível AAA) exige que todo o componente em foco esteja visível.

Para mobile nativo, o "foco de teclado" é interpretado de forma ampla para incluir o anel de foco usado por Switch Control ou Switch Access, Full Keyboard Access (iOS 15+) e Voice Control/Access. Um app em que o elemento em foco desliza para baixo de uma barra de navegação inferior durante uma varredura do Switch Control falha nesse critério, mesmo que não haja teclado físico envolvido. A UI do app deve evitar ocultar controles em foco com overlays criados pelo autor, barras fixas ou superfícies transitórias.

2.4.13 Focus Appearance (Nível AA)

Este critério define requisitos mínimos para as características visuais do indicador de foco: ele deve ter uma área mínima equivalente ao perímetro do componente × 2 pixels CSS e uma taxa de contraste de pelo menos 3:1 em relação às cores adjacentes. Em plataformas móveis nativas, o anel de foco para VoiceOver e TalkBack é controlado pelo sistema operacional, e os desenvolvedores não podem alterar sua aparência — o que significa que, em geral, os desenvolvedores recebem uma exceção para este critério específico. No entanto, o estilo do app não deve reduzir ativamente a visibilidade do foco, por exemplo, sobrepondo um scrim translúcido sobre controles em foco.

3.3.8 Accessible Authentication — Minimum (Nível A)

Este critério representa um grande avanço para acessibilidade cognitiva. Ele exige que processos de autenticação não dependam exclusivamente de um teste de função cognitiva — ou seja, o usuário não deve ser obrigado a memorizar uma senha, resolver um quebra-cabeça ou transcrever um CAPTCHA — a menos que o app forneça uma alternativa acessível. Em iOS, isso significa oferecer suporte ao Keychain da Apple e ao Sign in with Apple para permitir que usuários se autentiquem sem memorizar credenciais. Em Android, significa oferecer suporte ao framework de Autofill do Google, autenticação biométrica e não bloquear o uso de gerenciadores de senhas de terceiros.

Mais concretamente: se o seu app bloqueia ações de colar em campos de senha, é provável que esteja em não conformidade com 3.3.8. Se o seu fluxo de autenticação em duas etapas exige que o usuário digite manualmente um código OTP a partir de uma notificação sem fornecer um mecanismo de copiar e colar, ele introduz uma carga cognitiva desnecessária. O app Mensagens do Android já fornece um botão "copiar código" em notificações de OTP exatamente por esse motivo — alinhando o comportamento da plataforma com a intenção do critério.

Insight-chave: Oferecer suporte à autenticação biométrica (Face ID, Touch ID, Android Biometric API) não é apenas uma melhoria de UX — é um mecanismo de conformidade com a WCAG 2.2 para usuários com deficiências cognitivas que não conseguem lembrar senhas de forma confiável.

3.3.7 Redundant Entry (Nível A)

Se um fluxo de múltiplas telas no seu app — checkout, onboarding, um formulário de admissão em saúde — pede ao usuário que insira a mesma informação mais de uma vez, você deve ou preencher automaticamente o valor inserido anteriormente ou oferecer uma forma de selecioná-lo a partir de entradas anteriores. Este critério é diretamente aplicável a apps móveis nativos. O caso clássico de falha é um formulário de endereço de entrega que depois pede um endereço de cobrança sem opção "igual ao endereço de entrega", forçando usuários com deficiências motoras ou cognitivas a digitar o mesmo texto várias vezes.

3.2.6 Consistent Help (Nível A)

Se o seu app oferece um mecanismo de ajuda — um botão de chat de suporte, um ícone de ajuda, um link "fale conosco" — ele deve aparecer em um local consistente em todas as telas do app. Usuários com deficiências cognitivas dependem de posicionamento previsível de mecanismos de navegação e suporte. Colocar o botão de ajuda no cabeçalho em algumas telas e na barra de abas em outras, ou escondê-lo dentro de um menu de configurações em certos fluxos, viola esse critério.

Critérios da WCAG 2.1 que continuam críticos para mobile

Os novos critérios da WCAG 2.2 recebem a maior parte da atenção, mas vários requisitos da WCAG 2.1 introduzidos especificamente com foco em mobile ainda são rotineiramente descumpridos em apps nativos, e responsáveis por conformidade não devem ignorá-los durante auditorias.

1.3.4 Orientation (AA) proíbe bloquear um app apenas em orientação retrato ou paisagem, a menos que essa orientação seja essencial para a função do conteúdo. Muitos apps travam em retrato durante fluxos de onboarding ou players de vídeo in-app sem justificativa. Isso afeta de forma desproporcional usuários com dispositivos montados em cadeiras de rodas que não podem ser girados. 1.4.10 Reflow (AA) exige que o conteúdo possa ser apresentado sem rolagem horizontal quando exibido a 320 pixels CSS de largura (equivalente a zoom de 400%), o que, em termos de mobile, significa oferecer suporte a Dynamic Type e escala de tamanho de texto do sistema sem quebrar o layout ou truncar conteúdo.

2.5.1 Pointer Gestures (A) exige que qualquer funcionalidade que use gestos multiponto ou baseados em trajetória — um pinch-to-zoom, um swipe com dois dedos — também tenha uma alternativa de único ponteiro. 2.5.4 Motion Actuation (A) exige que funcionalidades acionadas por sacudir ou inclinar o dispositivo também possam ser operadas por controles padrão de UI, e que usuários possam desativar disparos baseados em movimento para evitar ativações acidentais.

Para apresentação visual, 1.4.3 Contrast Minimum (AA) exige uma taxa de pelo menos 4,5:1 para texto normal e 3:1 para texto grande. Muitos apps ainda falham aqui porque texto placeholder em campos de entrada, rótulos de botões desabilitados e texto sobre fundos fotográficos ficam abaixo do mínimo. Desenvolvedores devem garantir que todo o texto, controles e conteúdo funcionem com Dynamic Type, Bold Text, modo escuro e opções de contraste em nível de sistema tanto em iOS quanto em Android.

Orientações de implementação específicas de plataforma

iOS e SwiftUI / UIKit

A Apple oferece amplo suporte nativo à acessibilidade por meio da API UIAccessibility e, em SwiftUI, por meio de modificadores de acessibilidade. Para suporte ao VoiceOver, todo elemento interativo deve ter um rótulo (label), dica (hint) e valor (value) de acessibilidade significativos. Controles personalizados que não herdam de componentes padrão do UIKit devem adotar explicitamente um trait de acessibilidade apropriado — .isButton, .isHeader, .isLink — para que o VoiceOver os anuncie corretamente. O Accessibility Inspector do Xcode pode ajudar a identificar rótulos ausentes e incompatibilidades de traits durante o desenvolvimento.

Para Dynamic Type, as fontes de sistema UIFont.preferredFont(forTextStyle:) no UIKit e .font(.body) no SwiftUI escalam automaticamente com o tamanho de texto preferido do usuário. Tamanhos de fonte fixos em points que não usam scaledValue(for:) falharão no critério 1.4.4 Resize Text. Para tamanhos de alvo, você pode expandir a área de toque de um ícone pequeno usando contentEdgeInsets no UIKit ou o modificador .contentShape() no SwiftUI sem alterar a apresentação visual do elemento.

// SwiftUI: expandir área de toque sem mudar o tamanho visual
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android e Jetpack Compose / Views

A acessibilidade no Android é exposta por meio da API AccessibilityNodeInfo, que o TalkBack e o Switch Access consomem. Em Jetpack Compose, o bloco Modifier.semantics permite definir descrições de conteúdo, roles, descrições de estado e mesclar semânticas descendentes. Para UIs baseadas em View, ViewCompat.setAccessibilityDelegate() permite a manipulação programática de propriedades de acessibilidade em qualquer view.

Para dimensionamento de alvos de toque, a orientação do Material Design recomenda mínimo de 48 × 48 dp. Se um composable ou view for visualmente menor, você pode usar Modifier.minimumInteractiveComponentSize() no Compose (introduzido no Material3) para impor automaticamente um mínimo de 48 dp, ou envolver uma view pequena em um TouchDelegate para expandir sua área de toque no sistema legado de Views. Para escala de texto, garanta que todos os tamanhos de texto sejam especificados em sp (scale-independent pixels), não em dp, para respeitar as preferências de tamanho de fonte definidas pelo usuário nas configurações de Display do Android.

// Jetpack Compose: botão de ícone acessível com tamanho mínimo
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // impõe mínimo de 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // descrito pelo pai
    )
}

Testando seu app em relação à WCAG 2.2

Testar acessibilidade móvel exige uma combinação de ferramentas automatizadas e testes manuais com tecnologias assistivas reais. Ferramentas automatizadas — incluindo o axe DevTools Mobile da Deque, o Accessibility Scanner do Google para Android e o Accessibility Inspector da Apple no Xcode — podem detectar rótulos ausentes, contraste insuficiente e alvos de toque abaixo dos mínimos da plataforma. No entanto, ferramentas automatizadas capturam apenas uma fração dos problemas reais de acessibilidade. Testes manuais com VoiceOver em iOS e TalkBack em Android são essenciais para verificar ordem de leitura correta, rótulos significativos e gerenciamento lógico de foco em fluxos complexos.

Para critérios específicos da WCAG 2.2, testes manuais são especialmente importantes. Para testar 2.5.8 (Target Size), use seu dedo de verdade — não o cursor do mouse no iOS Simulator — para tentar interagir com controles pequenos. Para testar 3.3.8 (Accessible Authentication), verifique se o seu fluxo de login permite colar em campos de senha, oferece suporte a gerenciadores de senha (1Password, Bitwarden, keychain do sistema) e oferece suporte à autenticação biométrica. Para testar 2.4.11 (Focus Not Obscured), navegue pelo seu app inteiramente via Switch Control em iOS ou Switch Access em Android e confirme que nenhum elemento em foco desaparece atrás de uma barra de navegação, overlay modal ou botão flutuante.

Um plano abrangente de testes de acessibilidade deve incluir testes em pelo menos dois dispositivos físicos — um iPhone e um dispositivo Android — no tamanho de fonte padrão do usuário e no tamanho máximo de fonte do sistema, com VoiceOver e TalkBack ativados, respectivamente. Testes apenas em simulador deixarão passar diferenças reais de renderização e comportamento de tecnologias assistivas.

Considere incorporar verificações de acessibilidade no seu pipeline de CI/CD. Tanto o Espresso (Android) quanto o XCUITest (iOS) permitem escrever testes automatizados de UI que verificam propriedades de acessibilidade — descrições de conteúdo, traits e estados habilitados — para que regressões sejam detectadas antes da mesclagem de código, em vez de descobertas em uma auditoria em produção.

O caso jurídico e de negócios para agir agora

Além do imperativo moral de inclusão, o caso de negócios para acessibilidade móvel é concreto. Empresas que lideram em inclusão de pessoas com deficiência geram 1,6 vez mais receita e 2,6 vezes mais lucro líquido do que seus pares de setor. Pessoas com deficiência nos EUA detêm quase meio trilhão de dólares em renda disponível. E dado que 69% dos consumidores online com deficiência abandonam apps e sites que consideram difíceis de usar, cada barreira de acessibilidade é uma conversão que nunca acontece.

O risco jurídico está aumentando. Processos contra empresas com falhas de acessibilidade digital continuam crescendo ano após ano. A adoção da WCAG pelo DOJ como padrão técnico para conformidade com a ADA, os prazos de aplicação do Título II em 2026 e a entrada em vigor do EAA em junho de 2025 criam coletivamente uma exigência de conformidade multijurisdicional que agora abrange explicitamente aplicativos móveis nativos. Uma auditoria anterior em WCAG 2.1 não demonstra automaticamente conformidade com WCAG 2.2 — fluxos de autenticação, campos de formulário, componentes interativos e gerenciamento de foco precisam ser reavaliados em relação aos nove novos critérios de sucesso.

Crucialmente, acessibilidade em mobile não é um recurso que possa ser adaptado de forma barata após o lançamento. Corrigir falhas de WCAG em um app já publicado significa atualizar assets, reconstruir componentes, revisar layouts, retestar fluxos e, potencialmente, refatorar sistemas de autenticação. Equipes que incorporam conformidade com WCAG 2.2 em seus design systems e bibliotecas de componentes desde o início — impondo tamanhos mínimos de alvo de toque, tokens de contraste, roles semânticos e padrões de autenticação em nível de componente — pagam uma fração do custo em comparação com a remediação de um app inacessível pós-lançamento.

Principais pontos

• A WCAG 2.2 se aplica a apps nativos iOS e Android. A orientação WCAG2Mobile do W3C mapeia cada critério de sucesso de Nível A e AA para telas e views móveis, o que significa que seu app nativo está no escopo — não apenas seu site móvel.
• Tamanho de alvo de toque é a nova falha mais comum em auditorias de mobile. O mínimo de 24 × 24 da WCAG 2.2 é o piso; a Apple recomenda 44 × 44 pt e o Google recomenda 48 × 48 dp. Expanda áreas de toque com padding e APIs nativas de plataforma, não apenas ampliando ícones visualmente.
• Bloquear colar em campos de senha provavelmente viola 3.3.8 Accessible Authentication. Ofereça suporte a keychains do sistema, gerenciadores de senha, biometria e preenchimento automático de OTP para atender aos requisitos de acessibilidade cognitiva em fluxos de login em ambas as plataformas.
• Testes manuais com VoiceOver e TalkBack são inegociáveis. Ferramentas automatizadas capturam apenas uma fração dos problemas de acessibilidade. Teste em dispositivos físicos no tamanho máximo de fonte, com tecnologias assistivas ativadas, em todas as jornadas de usuário críticas.
• Incorpore acessibilidade no seu design system agora, não após o lançamento. Corrigir apps inacessíveis pós-lançamento é muito mais caro do que impor padrões de componentes acessíveis desde o primeiro dia. Com prazos de aplicação do DOJ, HHS e EAA chegando em 2025–2026, a janela para trabalho de conformidade de baixo custo está se fechando.