Chamar de «WebView» esconde a quem ela falha. As pessoas que dependem de tecnologias assistivas —VoiceOver, TalkBack, controle por botões, texto ampliado, alto contraste— são exatamente as que uma tela WebView deixa para trás em silêncio. A página renderiza. Os botões são tocáveis para usuários videntes. Mas a árvore de acessibilidade que um usuário cego navega é incompleta, e essa falha é invisível para quem não usa um leitor de tela.
A mesma marcação, um resultado diferente
Uma página web no Safari mobile e a mesma página numa WKWebView compartilham o mesmo DOM e o mesmo WebKit — mas os anúncios não são iguais. Como documentaram engenheiros de acessibilidade em 2026, o iOS WKWebView não respeita a cortesia do aria-live como o Safari: uma região urgente que interrompe a fala atual numa aba do Safari é rebaixada a uma mensagem cortês adiada dentro de uma WKWebView. O usuário ouve «Conexão perdida — tentando novamente» só depois de já ter digitado no formulário quebrado. A única solução confiável multiplataforma é tirar os anúncios do DOM e enviá-los ao app host por uma ponte JavaScript, e dali devolvê-los via UIAccessibility.post no iOS ou announceForAccessibility() no Android. Um usuário de leitor de tela dentro de uma WebView não pode confiar que a página falará com ele.
Configurações que a página ignora
O app nativo host passou anos respeitando os ajustes de acessibilidade do sistema: aumento de fonte Dynamic Type, negrito, maior contraste, redução de movimento, modo escuro. O conteúdo web dentro de uma WebView não herda nenhum automaticamente. prefers-color-scheme só é respeitado se a página o escuta; o tema escuro do app e a página clara da WebView ficam lado a lado. O aumento de fonte que o sistema aplica às etiquetas nativas não chega ao texto web. Quando o host desenha sua própria barra ou botão flutuante sobre a WebView, a ordem de leitura fica não determinística entre versões do iOS. Um guia de apps híbridas diz claro: mesmo com o alt perfeito, um usuário pode ser incapaz de tocar um botão, ouvir uma mudança de estado ou rolar a página.
O foco escapa pela fresta
O gerenciamento de foco do leitor de tela quebra na fronteira nativa. Dentro de uma WebView, document.activeElement frequentemente retorna body ou null — sobretudo após o teclado aparecer — então o código de rastreamento de foco falha. Mover o foco manualmente com element.focus() pode disparar o scroll forçado do iOS WKWebView, que esconde o campo atrás do teclado. O resultado é um formulário que um usuário cego não consegue completar, numa tela que a equipe nunca testou com VoiceOver porque a QA visual passou.
Uma lacuna jurídica, não só de UX
Antes era um risco reputacional. Agora é regulatório. A Lei de Acessibilidade da UE (Diretiva (UE) 2019/882) é aplicável nos 27 Estados-membros desde 28 de junho de 2025 e se alinha com a EN 301 549, que incorpora WCAG 2.1 Nível AA como base para apps móveis. Ela cobre apps de e-commerce, bancos, transporte e ticketing, e os reguladores podem retirar de distribuição os apps não conformes. Em junho de 2026, um tribunal francês ordenou ao Carrefour que tornasse acessíveis seu site e seu app móvel em seis meses ou pagasse 500 € por dia — a primeira decisão sob uma lei de transposição da EAA que cobre explicitamente o app. Nos EUA, a linha de casos Domino's v. Robles já estabeleceu que os apps devem ser acessíveis sob a ADA. Para um app de tráfego cujas centenas de telas de lojistas são HTML de terceiros, cada uma dessas páginas está no escopo.
A solução do runtime
Um runtime próprio do host não envia o HTML do lojista e espera que os serviços de acessibilidade da plataforma se virem. Ele constrói a ponte da árvore de acessibilidade: expõe uma ponte autorizada para que os anúncios urgentes cheguem à pilha assistiva do sistema com confiabilidade em cada motor, mapeia o aumento de fonte e o modo escuro do app host para o contexto web para que a página os respeite, e impõe uma única ordem de foco e leitura determinística na fronteira nativo/WebView. A acessibilidade vira uma propriedade que o runtime garante, testada com execuções reais de VoiceOver e TalkBack, em vez de um jogo de azar por página de lojista.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Anúncios em regiões live | Urgente rebaixado a cortês na WKWebView | A ponte entrega com confiabilidade à pilha a11y |
| Ajustes do sistema | Aumento / modo escuro / contraste ignorados | Mapeados para o contexto web |
| Foco e ordem de leitura | Perdidos na fronteira nativa; não determinístico | Ordem única determinística imposta |
| Conformidade | Cada página por conta própria; exposição EAA/ADA | Auditado e testado por programa |
| Quem testa | QA visual passa; SR não testado | VoiceOver + TalkBack no CI |
O fio condutor desta série é o controle. Uma WebView deixa a página de um lojista subir no seu app, mas entrega sua acessibilidade — e agora seu cumprimento legal — ao acaso. Um runtime faz você ser dono disso. Para um catálogo de páginas alheias, essa titularidade é a diferença entre um app inclusivo e um processo.
Fontes
- Lei de Acessibilidade da UE — aplicável desde 28/06/2025; alinhada com EN 301 549 / WCAG 2.1 AA — cobre apps móveis; reguladores podem retirá-los; decisão Carrefour (500 €/dia) de junho 2026 cobre explicitamente o app.
- EN 301 549 e WCAG 2.1 AA como referência de acessibilidade da UE — padrão harmonizado que incorpora WCAG 2.1 AA para web e móvel.
- API de acessibilidade nativa móvel: WKWebView descarta anúncios aria-live urgentes — mesmo DOM, canalização de anúncios diferente; única solução confiável é ponte JS ao app host.
- Acessibilidade HTML em apps híbridas: foco e aria-live falham dentro da WebView — document.activeElement pouco confiável; foco manual pode esconder o campo; ordem de leitura quebrada.
- ADA e acessibilidade web/app (precedente Domino's v. Robles) — precedente nos EUA de que os apps devem ser acessíveis.
