WCAG 3.2.5: Mudança mediante solicitação

O que Esta Regra Significa

WCAG 3.2.5 Change on Request é um critério de Nível AAA sob o princípio Compreensível. Ele estabelece que mudanças de contexto devem ser iniciadas apenas pelo usuário, não acionadas automaticamente pelo sistema. Uma "mudança de contexto" é definida nas WCAG como uma mudança importante no conteúdo da página da web que, sem o conhecimento do usuário, pode desorientar usuários que não conseguem visualizar a página inteira de uma vez. Isso inclui mudanças no user agent (navegador), na viewport, no foco ou no conteúdo que alterem significativamente o significado da página.

Especificamente, o critério proíbe qualquer mecanismo que cause uma mudança de contexto sem um pedido explícito do usuário. Isso estende os requisitos de 3.2.1 (On Focus) e 3.2.2 (On Input) ao abordar todos os cenários restantes em que mudanças automáticas de contexto podem ocorrer — incluindo, mas não se limitando a: páginas com atualização automática, carrosséis que avançam automaticamente e navegam para outro lugar, meta tags de redirecionamento com atrasos curtos, navegação acionada por JavaScript após o preenchimento de um campo de formulário e abertura de novas janelas ou abas sem instigação do usuário.

Para ser aprovado neste critério, é necessário que uma de duas condições seja atendida: ou as mudanças de contexto são acionadas apenas por uma ação explícita e deliberada do usuário (como ativar um botão ou link), ou é fornecido um mecanismo que permita ao usuário desativar mudanças automáticas de contexto antes que elas ocorram. Por exemplo, se uma página é atualizada automaticamente a cada 30 segundos e navega para um novo conteúdo, ela falha — a menos que exista um controle claramente rotulado para desativar esse comportamento antes que a primeira atualização aconteça. Simplesmente fornecer um aviso depois do fato não é suficiente.

O critério se aplica amplamente a todo conteúdo web interativo e dinâmico. Elementos e comportamentos comuns afetados incluem: redirecionamentos com <meta http-equiv='refresh'>, chamadas JavaScript a window.location ou history.pushState acionadas por temporizadores, manipuladores de evento onchange em elementos <select> que navegam para uma nova URL, formulários com envio automático, navegação acionada por foco e qualquer widget que role automaticamente, avance slides ou altere o conjunto de conteúdo visível sem entrada do usuário.

Uma exceção oficial importante: se a mudança de contexto é uma resposta a uma configuração que o usuário explicitamente e conscientemente definiu — por exemplo, um painel de preferências em que o usuário seleciona "atualizar automaticamente a cada minuto" — o comportamento automático é permitido porque o usuário o solicitou. A distinção fundamental é se o usuário fez uma escolha informada e deliberada para habilitar o comportamento automático, em vez de encontrá-lo inesperadamente.

Por Que Isso Importa

Mudanças de contexto inesperadas estão entre as experiências mais desorientadoras na web, e seu impacto varia significativamente entre diferentes grupos de usuários com deficiência.

Para usuários cegos que dependem de leitores de tela, uma navegação repentina de página ou atualização de conteúdo pode fazer o cursor de leitura saltar para uma posição completamente diferente na página — ou voltar ao topo — sem qualquer anúncio. Se um usuário estiver no meio de uma frase em um artigo longo e a página for redirecionada automaticamente para uma nova URL, ele perde completamente o seu lugar e pode não entender o que aconteceu ou como se recuperar. Leitores de tela como NVDA, JAWS e VoiceOver nem sempre anunciam eventos de navegação em nível de página de forma consistente ou oportuna, de modo que os usuários podem ficar confusos sobre onde estão e o que mudou.

Para usuários com deficiências motoras que navegam por teclado, ponteira de cabeça, dispositivo de varredura ou tecnologia de rastreamento ocular, mudanças de foco inesperadas podem ser catastróficas. Se o foco for movido programaticamente sem ação do usuário — por exemplo, quando um formulário avança automaticamente para o próximo campo ao completar o anterior — o usuário pode perder a noção de sua posição e ser forçado a re-navegar laboriosamente para encontrar onde o sistema o levou. Para usuários cujos dispositivos de entrada exigem esforço físico significativo por tecla pressionada, essa re-navegação representa uma barreira real de acessibilidade.

Usuários com deficiências cognitivas, incluindo aqueles com transtornos de déficit de atenção, comprometimentos de memória ou condições de ansiedade, são particularmente vulneráveis a mudanças inesperadas. Mudanças automáticas de página quebram seu modelo mental da interface. Um usuário que faz uma pausa para ler instruções e depois descobre que a página foi recarregada provavelmente se sentirá confuso ou angustiado. Essa interrupção pode tornar impossível concluir transações ou consumir informações de forma independente.

Para usuários com distúrbios vestibulares, mudanças visuais rápidas e inesperadas — como um carrossel que avança automaticamente e também aciona navegação — podem causar sintomas físicos, incluindo tontura e náusea. Mesmo usuários videntes sem deficiência diagnosticada se beneficiam de interfaces previsíveis: pesquisas mostram de forma consistente que navegações inesperadas aumentam as taxas de erro e de abandono de tarefas em todos os grupos de usuários.

Um cenário concreto do mundo real: um site de e-commerce turco envia automaticamente um formulário de filtro de produtos no momento em que o usuário seleciona um valor em um dropdown — navegando para uma nova URL de resultados de busca. Um usuário que utiliza apenas o teclado e está percorrendo os filtros com Tab para selecionar múltiplos critérios descobre que selecionar a primeira opção recarrega imediatamente a página e recolhe o painel de filtros. Ele precisa reabrir o painel, re-navegar até sua posição inicial e tentar novamente — potencialmente em um loop que torna o recurso completamente inutilizável. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência, e padrões como esse as excluem de forma desproporcional dos serviços digitais.

Do ponto de vista de usabilidade e SEO, páginas que redirecionam ou atualizam automaticamente também tendem a ter taxas de rejeição mais altas, já que usuários que encontram comportamentos inesperados frequentemente saem. Mecanismos de busca também podem penalizar redirecionamentos inesperados que diferem entre sessões do crawler e do usuário, tornando a conformidade com 3.2.5 alinhada com boas práticas de higiene técnica de SEO.

Regras Relacionadas do Axe-core

WCAG 3.2.5 exige testes manuais porque ferramentas automatizadas não conseguem detectar de forma confiável se uma mudança de contexto foi iniciada pelo usuário ou acionada automaticamente. A distinção depende de entender a intenção do usuário e o fluxo de interação, o que requer julgamento humano. Nenhuma regra do axe-core mapeia diretamente todo o escopo deste critério. No entanto, as seguintes considerações se aplicam a testes automatizados e semi-automatizados:

• Nenhuma regra direta do axe-core (teste manual necessário): Axe-core e Lighthouse não conseguem detectar navegações acionadas por JavaScript, páginas com atualização automática ou formulários com envio automático porque esses comportamentos dependem de condições de tempo de execução, temporização e estado de interação do usuário que varreduras estáticas ou roteirizadas não conseguem reproduzir. Um scanner que observa o DOM em um único ponto no tempo não consegue determinar se window.location.href está sendo definido em resposta a um temporizador ou a um clique do usuário.
• Detecção de meta refresh (automação parcial possível): Algumas ferramentas automatizadas, incluindo regras mais antigas do axe e extensões de navegador, podem sinalizar a presença de <meta http-equiv='refresh' content='0; url=...'> no head do documento. No entanto, o axe-core não possui uma regra de produção dedicada para isso na versão 4.10. A inspeção manual do código-fonte da página e dos cabeçalhos HTTP é necessária para verificar se nenhum redirecionamento automático está ocorrendo.
• Análise de event listeners (manual): Detectar manipuladores onchange em elementos <select> que acionam navegação requer uma revisão manual de código ou o uso das ferramentas de desenvolvedor do navegador para inspecionar event listeners anexados. Varreduras automatizadas observam o DOM renderizado, mas não as consequências comportamentais de interagir com cada elemento.
• Verificação de gerenciamento de foco (manual): Ver se o foco se move inesperadamente como resultado de uma mudança de contexto iniciada pelo sistema — em vez de uma ação do usuário — exige que um testador interaja de fato com a página e observe o comportamento do foco em tempo real, usando um teclado e, opcionalmente, um leitor de tela.

Como Testar

1. Varredura automatizada (linha de base): Execute axe DevTools ou Lighthouse na página para capturar quaisquer problemas sinalizados relacionados a redirecionamentos ou gerenciamento de foco. No Chrome DevTools, abra o painel Lighthouse e execute uma auditoria de Acessibilidade. Na extensão axe DevTools, clique em "Analyze" e revise os resultados. Observe que um resultado automatizado limpo não confirma conformidade com 3.2.5 — o teste manual é essencial.
2. Inspecione meta refresh: Abra a página em um navegador, clique com o botão direito e selecione "View Page Source", depois pesquise (Ctrl+F / Cmd+F) por http-equiv ou refresh. Qualquer tag <meta http-equiv='refresh'> com uma URL ou com um atraso de mais de 72 horas sem um mecanismo para desativá-la constitui uma falha.
3. Observe o comportamento da página ao longo do tempo: Carregue a página e espere sem interagir por 2–5 minutos. Observe quaisquer mudanças automáticas de conteúdo, recarregamentos de página, eventos de navegação ou abertura de novas janelas. Verifique se há mudanças na barra de endereços e no título da aba do navegador. Se algo ocorrer sem sua entrada, o critério provavelmente falha.
4. Teste controles de formulário e dropdowns: Usando apenas o teclado (Tab, teclas de seta, Enter, Espaço), navegue até cada <select>, grupo de botões de opção (radio) ou caixa de seleção. Altere valores e observe se uma navegação ou mudança importante de conteúdo ocorre imediatamente após a seleção — antes de você ativar um botão de envio. Se isso acontecer, é uma falha, a menos que um controle para desativar esse comportamento tenha sido fornecido antes de você chegar ao elemento.
5. Teste com NVDA + Firefox: Ative o NVDA (Insert+Space para o modo de navegação), navegue pela página usando as teclas de seta e Tab. Complete interações com formulários e observe se o foco ou a posição de leitura é relocada inesperadamente. Ouça anúncios de mudanças de página. Se o leitor de tela anunciar uma nova página ou o cursor virtual for redefinido sem sua ação explícita, isso indica uma mudança de contexto.
6. Teste com VoiceOver + Safari (macOS/iOS): Ative o VoiceOver (Cmd+F5 no Mac), navegue usando VO+seta. Interaja com controles e ouça anúncios inesperados de página ou redefinições de cursor. No iOS, deslize pelos elementos e observe quaisquer mudanças súbitas na estrutura da árvore de acessibilidade que você não tenha iniciado.
7. Teste com JAWS + Chrome: Ative o JAWS e navegue com Tab e teclas de seta. Envie formulários e interaja com widgets dinâmicos. Verifique se o foco e a posição do cursor virtual permanecem previsíveis e sob seu controle o tempo todo.
8. Revise o código-fonte JavaScript: No Chrome DevTools, use o painel Sources ou pesquise (Ctrl+Shift+F) por padrões como window.location, location.href, history.pushState, setTimeout combinado com chamadas de navegação e atributos onchange. Avalie se algum deles é acionado por temporizadores ou eventos do sistema em vez de ações explícitas do usuário.
9. Verifique carrosséis e sliders com avanço automático: Identifique quaisquer carrosséis, slideshows ou banners rotativos na página. Verifique se eles avançam automaticamente. Se avançarem, verifique se também acionam navegação (por exemplo, vinculando a novas páginas) ao avançar automaticamente. Carrosséis com avanço automático que apenas alteram o conteúdo visível podem ser abordados por 2.2.2, mas se também causam navegação, eles se enquadram em 3.2.5.

Como Corrigir

Redirecionamento com meta refresh — Incorreto

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Redirecionamento com meta refresh — Correto

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Elemento select que navega automaticamente ao mudar — Incorreto

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Elemento select que navega automaticamente ao mudar — Correto

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Carrossel com avanço automático que aciona navegação — Incorreto

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Carrossel com avanço automático que aciona navegação — Correto

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Erros Comuns

• Usar onchange em elementos <select> para acionar imediatamente navegação com window.location.href sem fornecer um botão de envio separado, forçando usuários de teclado a uma mudança imediata de página antes que possam confirmar sua seleção.
• Implementar <meta http-equiv='refresh' content='30; url=...'> para tratamento de expiração de sessão sem dar aos usuários um mecanismo para estender sua sessão ou desativar o redirecionamento automático antes que ele ocorra.
• Usar setTimeout ou setInterval para chamar location.replace() ou history.pushState() para recursos de "conveniência", como salvamento automático com atualização de URL, o que move os usuários inesperadamente para novos estados de histórico do navegador.
• Abrir novas janelas ou abas do navegador usando window.open() acionado por um temporizador ou processo automatizado em vez de por um gesto do usuário, como um clique ou pressionamento de tecla, o que muitos navegadores podem bloquear como popup e que sempre constitui uma mudança de contexto não solicitada.
• Enviar automaticamente um formulário de busca ou filtro usando form.submit() dentro de uma função debounce acionada por oninput em um campo de texto — mesmo com atraso — sem fornecer um botão de envio visível como mecanismo de controle alternativo.
• Fornecer um controle de "desativar avanço automático" que aparece apenas depois que a primeira navegação automática já ocorreu, em vez de antes. O mecanismo de opt-out deve estar disponível aos usuários antes que a primeira mudança de contexto aconteça.
• Confundir atualizações de conteúdo com mudanças de contexto: regiões dinâmicas (live regions) que atualizam texto no mesmo lugar (por exemplo, um ticker de ações) não são mudanças de contexto e são aceitáveis, mas substituir automaticamente toda a página visível ou navegar para uma nova URL é uma mudança de contexto e se enquadra neste critério.
• Presumir que fornecer uma caixa de diálogo de aviso antes da navegação automática satisfaz o critério quando a própria caixa de diálogo é acionada automaticamente e prende o foco do teclado. O usuário deve poder desativar o comportamento, não apenas ser avisado sobre ele.
• Usar manipuladores de evento onblur ou onfocusout para acionar validação de formulário e redirecionamento automático para uma página de erro ou uma etapa diferente em um formulário de múltiplas etapas, sem que o usuário solicite explicitamente prosseguir.
• Implantar roteamento de single-page application (SPA) que atualiza history.pushState com base na profundidade de rolagem ou no tempo gasto em uma seção — um padrão às vezes usado para análise — o que constitui uma mudança de contexto não iniciada e pode confundir usuários de leitores de tela cujo buffer virtual está vinculado ao estado da URL.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade web alinhados com WCAG 2.2 para uma ampla gama de entidades que operam na Turquia. A circular abrange instituições e órgãos públicos, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

A circular determina a conformidade com WCAG 2.2 Nível AA como padrão mínimo para as entidades abrangidas. WCAG 3.2.5 Change on Request é um critério de Nível AAA e, portanto, não é diretamente exigido pelo patamar legal mínimo da circular. No entanto, isso não significa que deva ser descartado como irrelevante no contexto turco.

Várias categorias de entidades abrangidas têm fortes razões práticas para buscar conformidade AAA com 3.2.5. Plataformas de e-commerce e agências de viagens com grandes bases de usuários frequentemente implementam filtragem dinâmica, navegação com auto-sugestão e carrosséis promocionais — precisamente os padrões mais propensos a violar esse critério. Bancos e prestadores de serviços financeiros, que lidam com transações sensíveis em que navegação inesperada pode causar erros ou problemas de segurança, se beneficiam substancialmente de garantir que todas as mudanças de contexto sejam explicitamente controladas pelo usuário. Portais de saúde, em que usuários podem estar em estados vulneráveis e precisam de interfaces previsíveis e tranquilas, representam outra categoria em que ir além da base AA com critérios AAA como 3.2.5 demonstra tanto compromisso ético quanto segurança prática para o usuário.

Instituições públicas sujeitas a requisitos de auditoria e relatórios sob a circular devem documentar seu nível de conformidade. Embora o Nível AAA não seja legalmente obrigatório, alcançá-lo — e documentá-lo — fornece um registro defensável de compromisso com acessibilidade de melhor nível. Para entidades que atendem usuários com deficiência como público primário ou significativo, como a autoridade de seguridade social (SGK) ou serviços de apoio à deficiência, buscar conformidade Nível AAA está especialmente alinhado com o espírito da regulamentação.

Organizações que voluntariamente atendem ao WCAG 3.2.5 também se posicionam favoravelmente no contexto de alinhamento de acessibilidade com a União Europeia, à medida que as relações de comércio digital da Turquia com Estados-membros da UE envolvem cada vez mais acessibilidade como critério de contratação e parceria. O European Accessibility Act (EAA), que entrou em vigor em junho de 2025, se aplica a produtos e serviços oferecidos em mercados da UE — incluindo aqueles fornecidos por empresas turcas a usuários europeus — e incentiva fortemente padrões de interação controlados pelo usuário consistentes com 3.2.5.

Na prática, equipes de desenvolvimento turcas que implementam o SDK de overlay da Accsible devem garantir que quaisquer widgets injetados dinamicamente, painéis de preferências ou controles assistivos não introduzam eles próprios mudanças de contexto não iniciadas. A barra de ferramentas e o painel de configurações do SDK devem abrir e fechar apenas em resposta a ações explícitas do usuário, e qualquer navegação ou atualização de conteúdo acionada pelo overlay deve ser iniciada pelo usuário. Isso garante que a própria solução de acessibilidade não crie as barreiras que foi projetada para remover.