Critérios de Sucesso WCAG · Level AA
WCAG 1.3.4: Orientação
A WCAG 1.3.4 Orientação exige que o conteúdo não restrinja sua visualização e operação a uma única orientação de tela, como retrato ou paisagem, a menos que uma orientação específica seja essencial. Esse critério garante que usuários que não podem girar fisicamente seus dispositivos — como aqueles com tablets fixados ou com deficiências motoras — ainda possam acessar todo o conteúdo.
O que Esta Regra Significa
WCAG 1.3.4 Orientação é um critério de Nível AA introduzido no WCAG 2.1 e mantido no WCAG 2.2. Ele estabelece que o conteúdo não deve se bloquear em uma única orientação de exibição — seja retrato (vertical) ou paisagem (horizontal) — a menos que essa orientação específica seja essencial para a função do conteúdo. Na prática, isso significa que páginas da web e aplicações baseadas na web devem responder corretamente e permanecer totalmente operáveis independentemente de o dispositivo do usuário estar sendo segurado na vertical ou na horizontal, ou se a orientação é controlada pelo sistema operacional do dispositivo ou pelas próprias preferências do usuário.
O critério tem como alvo situações em que desenvolvedores usam media queries de CSS, JavaScript ou APIs do dispositivo para restringir deliberadamente o conteúdo a uma única orientação. Uma violação comum é exibir uma mensagem como "Por favor, gire seu dispositivo para o modo paisagem" enquanto simultaneamente oculta ou desabilita todo o conteúdo interativo no modo retrato. Outra violação ocorre quando uma aplicação web aplica um transform de CSS ou gira forçadamente a viewport, substituindo a configuração de orientação do dispositivo do usuário.
O que conta como aprovação: O conteúdo é acessível tanto em orientação retrato quanto paisagem. Todo o texto, elementos interativos, formulários, navegação e mídia permanecem visíveis e operáveis independentemente de como o dispositivo está orientado. O layout pode se adaptar — usando técnicas de design responsivo como CSS Flexbox, CSS Grid ou media queries — mas nada é removido ou tornado inoperável com base apenas na orientação.
O que conta como reprovação: Conteúdo que oculta, desabilita ou bloqueia a interação em uma das orientações; mensagens instruindo usuários a girar o dispositivo sem fornecer uma alternativa funcional; JavaScript que escuta DeviceOrientationEvent ou screen.orientation e então bloqueia ou desabilita partes da interface; ou CSS que usa @media (orientation: portrait) para exibir uma sobreposição de bloqueio ou display: none em conteúdo crítico.
A exceção essencial: O WCAG reconhece que alguns conteúdos têm um propósito inerentemente específico de orientação. Um aplicativo de teclado de piano pode legitimamente exigir o modo paisagem porque um layout em retrato não consegue exibir teclas suficientes para ser musicalmente útil. Um recurso de depósito de cheque bancário que depende da câmera capturando um cheque horizontal pode exigir paisagem. Uma interface de headset de realidade virtual pode exigir uma orientação fixa para funcionar. No entanto, o nível para "essencial" é alto — mera conveniência do desenvolvedor ou preferência estética não se qualificam. A exceção deve ser justificada por um requisito fundamental do próprio conteúdo, não por uma escolha de design.
Por Que Isso Importa
Restrições de orientação afetam desproporcionalmente pessoas com deficiências físicas e motoras. Considere uma pessoa usuária de cadeira de rodas cujo tablet está montado em uma posição fixa em retrato no apoio de braço da cadeira. Ela não consegue inclinar fisicamente o dispositivo, então qualquer conteúdo que exija orientação paisagem se torna completamente inacessível para ela. Isso não é um caso extremo hipotético — montar dispositivos de tecnologia assistiva em orientações fixas é uma adaptação comum para pessoas com condições como paralisia cerebral, lesões na medula espinhal, ELA ou artrite grave.
Além de dispositivos montados, muitos usuários dependem do recurso de bloqueio de orientação do sistema operacional por motivos não relacionados à deficiência. Uma pessoa deitada na cama pode bloquear o telefone em retrato para evitar que a tela fique girando constantemente. Uma pessoa com distúrbio vestibular — uma condição que afeta o ouvido interno e o equilíbrio — pode achar mudanças bruscas de layout causadas por alterações de orientação desorientadoras ou fisicamente nauseantes. Forçar essas pessoas a desbloquear a orientação do dispositivo para acessar seu conteúdo cria uma barreira desnecessária e discriminatória.
A acessibilidade cognitiva também é um fator. Pessoas com deficiências cognitivas frequentemente se beneficiam de layouts consistentes e previsíveis. Uma aplicação que de repente bloqueia o conteúdo ou exibe uma mensagem semelhante a erro pedindo para girar o dispositivo pode ser confusa e alarmante, especialmente para usuários que podem não entender por que o dispositivo está mostrando um aviso em vez do conteúdo esperado.
Do ponto de vista de usabilidade e negócios, restrições de orientação prejudicam todos os usuários. Uma parcela significativa do tráfego web móvel ocorre em modo retrato, e restringir um site a paisagem pode resultar em abandono imediato. Motores de busca também consideram cada vez mais a compatibilidade com dispositivos móveis e os Core Web Vitals — incluindo comportamento de layout estável — em seus algoritmos de ranqueamento, o que significa que problemas relacionados à orientação podem ter um impacto negativo mensurável no desempenho de SEO e no tráfego orgânico.
Globalmente, aproximadamente 1,3 bilhão de pessoas vivem com algum tipo de deficiência, de acordo com a Organização Mundial da Saúde. Uma proporção significativa desse grupo usa dispositivos móveis como seu meio principal ou único de acesso à internet, tornando a acessibilidade de orientação em dispositivos móveis particularmente consequente.
Regras Relacionadas do Axe-core
WCAG 1.3.4 Orientação requer testes manuais. Não há nenhuma regra automatizada do axe-core que detecte de forma confiável restrições de orientação, porque a violação depende de comportamento em tempo de execução, lógica de renderização condicional e do estado físico de um dispositivo — nenhum dos quais a análise estática do DOM ou a varredura automatizada de página consegue avaliar. O seguinte explica por que a automação é insuficiente e o que testadores manuais devem observar:
- Nenhuma regra automatizada do axe-core (teste manual necessário): Varredores automatizados de acessibilidade como axe-core, Lighthouse ou IBM Equal Access Checker analisam o DOM e o CSSOM em um único ponto no tempo. Eles não conseguem simular um dispositivo sendo girado, avaliar o que acontece com o layout quando
screen.orientationmuda ou determinar se um bloco de CSS@media (orientation: landscape)está ocultando conteúdo crítico. Um scanner pode ver que todos os elementos estão presentes e tecnicamente visíveis na orientação testada, sem saber que metade deles desaparece na orientação alternativa. É por isso que o WCAG 1.3.4 é classificado como exigindo teste manual — nenhuma ferramenta pode substituir o ato de realmente girar um dispositivo real ou simular a rotação nas ferramentas de desenvolvedor do navegador. - Detecção de bloqueio de orientação em JavaScript: Scripts que chamam
screen.orientation.lock()ou escutamwindow.addEventListener('orientationchange', ...)para redirecionar ou desabilitar conteúdo não podem ser detectados por análise estática. Um linter poderia sinalizar o uso dessas APIs no código-fonte, mas não pode determinar se o comportamento resultante constitui uma violação do WCAG sem julgamento humano sobre se uma exceção essencial se aplica. - Sobreposições de bloqueio baseadas em CSS: Uma folha de estilo pode usar
@media (orientation: portrait) { .orientation-warning { display: block; } }para mostrar uma mensagem de bloqueio em tela cheia no modo retrato. O axe-core, ao escanear a página em paisagem, nunca encontraria esse elemento em estado visível e não relataria problema algum. Somente testar em modo retrato — ou inspecionar o CSS em busca de padrões de bloqueio condicionais à orientação — revela a violação.
Como Testar
- Execute uma varredura automatizada como linha de base: Abra a página no Chrome, Firefox ou Edge. Use a extensão de navegador axe DevTools ou execute uma auditoria de acessibilidade do Lighthouse para estabelecer uma linha de base. Embora essas ferramentas não detectem violações de orientação diretamente, elas podem sinalizar problemas relacionados a design responsivo, problemas na meta tag viewport ou ARIA ausente que agravam falhas de acessibilidade relacionadas à orientação. Observe que um relatório automatizado limpo não confirma conformidade com 1.3.4.
- Use a emulação de dispositivo das DevTools do navegador: No Chrome ou Edge, abra as DevTools (F12), clique no ícone da barra de ferramentas de dispositivo (Ctrl+Shift+M / Cmd+Shift+M) e selecione um dispositivo móvel como iPhone 14 ou Galaxy S21. Alterne entre as orientações retrato e paisagem usando o ícone de rotação na barra de ferramentas do dispositivo. Verifique sistematicamente se todo o conteúdo — navegação, cabeçalhos, texto do corpo, formulários, botões, imagens e mídia — permanece visível e operável em ambas as orientações. Procure por sobreposições de bloqueio, seções ocultas ou elementos interativos desabilitados que apareçam em uma orientação, mas não na outra.
- Teste em dispositivos reais: Conecte um dispositivo Android ou iOS e abra a página no navegador móvel. Gire fisicamente o dispositivo entre retrato e paisagem. Confirme que o bloqueio de orientação do sistema operacional (quando ativado) não faz com que o conteúdo quebre ou exiba um prompt de rotação. Teste com o bloqueio de orientação ligado e desligado.
- Teste com leitor de tela e simulação de orientação: No iOS com o VoiceOver ativado (clique triplo no botão lateral), navegue pela página em orientação retrato usando gestos de deslizar. Em seguida, gire para paisagem e verifique se a ordem de leitura do VoiceOver e os nomes acessíveis permanecem corretos. No Android com o TalkBack, realize o mesmo teste. Use o NVDA com Firefox no desktop e simule a orientação via DevTools para verificar se a árvore de acessibilidade é consistente entre as orientações.
- Inspecione o CSS e o JavaScript em busca de restrições de orientação: Nas DevTools, abra o painel Sources ou Elements e pesquise na folha de estilo por media queries
orientation: portraiteorientation: landscape. Revise o que cada bloco faz: ele oculta conteúdo comdisplay: none, aplica uma sobreposição de bloqueio ou apenas ajusta o layout? Pesquise nos arquivos JavaScript porscreen.orientation,orientationchangeescreen.orientation.lock. Avalie se algum padrão encontrado bloqueia a interface ou o conteúdo. - Verifique a exceção essencial: Se o site restringe intencionalmente a orientação, confirme que existe um caso de uso essencial documentado e justificado. A exceção deve ser orientada pelo conteúdo, não cosmética. Documente sua constatação com uma captura de tela e a justificativa específica.
Como Corrigir
Sobreposição de bloqueio em CSS no modo retrato — Incorreto
<!-- Uma sobreposição em tela cheia exibida apenas em retrato que bloqueia todo o conteúdo -->
<style>
.rotate-prompt {
display: none;
position: fixed;
inset: 0;
background: #fff;
z-index: 9999;
text-align: center;
padding: 2rem;
}
@media (orientation: portrait) {
.rotate-prompt {
display: flex; /* bloqueia todo o conteúdo subjacente */
}
}
</style>
<div class='rotate-prompt'>
<p>Por favor, gire seu dispositivo para o modo paisagem.</p>
</div>
<main id='app-content'>
<!-- Todo o conteúdo da aplicação aqui -->
</main>
Sobreposição de bloqueio em CSS no modo retrato — Correto
<!-- Remova completamente a sobreposição de bloqueio. Use CSS responsivo para adaptar o layout em vez disso. -->
<style>
/* Layout em retrato: empilhar elementos verticalmente */
@media (orientation: portrait) {
.dashboard-grid {
grid-template-columns: 1fr;
}
}
/* Layout em paisagem: colunas lado a lado */
@media (orientation: landscape) {
.dashboard-grid {
grid-template-columns: 1fr 1fr;
}
}
</style>
<main id='app-content'>
<div class='dashboard-grid'>
<!-- O conteúdo adapta o layout, mas está sempre acessível -->
</div>
</main>
Bloqueio de orientação em JavaScript — Incorreto
<script>
// Bloqueia a tela em paisagem e mostra um erro se falhar (por exemplo, no iOS)
screen.orientation.lock('landscape').catch(function() {
document.getElementById('orientation-error').style.display = 'block';
document.getElementById('main-content').style.display = 'none';
});
</script>
<div id='orientation-error' style='display:none'>
Esta aplicação só funciona em modo paisagem.
</div>
<div id='main-content'>
<!-- Conteúdo da aplicação -->
</div>
Bloqueio de orientação em JavaScript — Correto
<script>
/*
Não bloqueie a orientação via JavaScript.
Em vez disso, escute mudanças de orientação e adapte a interface
sem ocultar ou desabilitar conteúdo.
*/
window.addEventListener('orientationchange', function() {
var isPortrait = window.matchMedia('(orientation: portrait)').matches;
// Ajuste a classe de layout apenas para estilização — nunca oculte conteúdo
document.body.classList.toggle('portrait-layout', isPortrait);
document.body.classList.toggle('landscape-layout', !isPortrait);
});
</script>
<div id='main-content'>
<!-- Todo o conteúdo permanece visível e operável em ambas as orientações -->
</div>
Meta tag viewport impedindo mudança de orientação — Incorreto
<!-- Algumas implementações mais antigas tentavam corrigir a orientação via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
Embora 'user-scalable=no' não bloqueie diretamente a orientação,
combiná-lo com transforms de CSS que giram a viewport
é um anti-padrão conhecido que cria falhas de acessibilidade relacionadas à orientação.
-->
<style>
/* Anti-padrão: girar todo o body para simular paisagem em um dispositivo em retrato */
@media (orientation: portrait) {
body {
transform: rotate(90deg);
transform-origin: left top;
width: 100vh;
overflow-x: hidden;
}
}
</style>
Meta tag viewport impedindo mudança de orientação — Correto
<!-- Use uma meta tag viewport responsiva padrão. Nunca gire o body via transforms de CSS. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
Deixe o navegador e o sistema operacional lidarem com a orientação naturalmente.
Projete de forma responsiva para que o conteúdo funcione em todas as proporções de viewport.
Use CSS Grid e Flexbox para reorganizar o conteúdo, não transforms.
-->
Erros Comuns
- Usar
@media (orientation: portrait)para aplicardisplay: nonea menus de navegação, barras laterais ou áreas de conteúdo principal. Qualquer media query de orientação em CSS que remova conteúdo da visualização — em vez de simplesmente reposicioná-lo — é uma potencial violação. Audite todas as media queries de orientação na sua folha de estilo para garantir que elas apenas mudem o layout, não a disponibilidade do conteúdo. - Chamar
screen.orientation.lock()para aplicações não essenciais. Essa Web API é destinada a jogos e casos de uso específicos de mídia. Usá-la em uma aplicação web padrão ou site de e-commerce para "melhorar a estética" em modo paisagem não se qualifica como exceção essencial e cria uma violação direta do WCAG 1.3.4. - Exibir uma tela de "gire seu dispositivo" sem uma alternativa acessível. Mesmo que uma breve dica de orientação seja exibida, ela nunca deve bloquear o acesso ao conteúdo. Se for exibida, deve ser descartável, não cobrir o conteúdo principal e ser apresentada como sugestão, não como requisito.
- Presumir que usuários móveis sempre preferem paisagem para conteúdo de vídeo. Incorporar um player de vídeo que desabilita controles de reprodução ou o botão de play em modo retrato — forçando usuários a girar antes de poder interagir — viola 1.3.4, a menos que o formato de vídeo genuinamente não possa ser renderizado em retrato (o que quase nunca é verdade para vídeo padrão na web).
- Aplicar CSS
transform: rotate(90deg)ao<body>ou a um contêiner raiz em uma das orientações. Isso simula mudança de orientação em CSS em vez de permitir que o dispositivo a trate naturalmente, criando layouts quebrados, conteúdo fora da tela e confusão severa na árvore de acessibilidade para leitores de tela. - Deixar de testar o comportamento de orientação durante o QA porque as equipes só testam em navegadores desktop. A simulação de orientação nas DevTools de navegadores desktop nem sempre é usada durante ciclos padrão de QA. A orientação deve ser um item explícito nos planos de teste móvel, verificado em dispositivos reais iOS e Android.
- Substituir o comportamento de orientação dentro de iframes sem levar em conta o estado de orientação da página pai. Widgets de terceiros, mapas incorporados e iframes de pagamento podem bloquear a orientação de forma independente. Mesmo que sua página esteja em conformidade, hospedar um iframe bloqueado torna sua página não conforme, a menos que a exceção essencial do iframe esteja documentada.
- Usar detecção de user-agent no servidor para servir uma versão "apenas paisagem" de uma página para usuários móveis. Redirecionar usuários móveis para uma URL separada que só funciona em paisagem, sem fornecer uma alternativa compatível com retrato, é uma violação sistêmica que também cria um problema de SEO e de canonicalização de URL.
- Aplicar restrições de orientação apenas em builds de produção, tornando-as invisíveis durante testes de desenvolvimento. Feature flags ou frameworks de testes A/B às vezes ativam código de bloqueio de orientação apenas em ambientes específicos ou para segmentos específicos de usuários, fazendo com que a violação seja ignorada durante auditorias de acessibilidade pré-lançamento.
- Presumir que a exceção essencial se aplica porque um designer prefere o layout em paisagem. A exceção essencial é um padrão jurídico e ético elevado. Ela exige que a função principal do conteúdo seja fundamentalmente impossível na orientação alternativa — não apenas que pareça melhor ou que a equipe não tenha tido tempo de implementar um layout responsivo em retrato.
Relação com os Regulamentos de Acessibilidade da Turquia
A Circular Presidencial nº 2025/10 da Turquia, publicada no Diário Oficial (Resmî Gazete) nº 32933 em 21 de junho de 2025, estabelece um quadro nacional abrangente para acessibilidade digital. A Circular determina que as entidades abrangidas cumpram o WCAG 2.2 Nível AA, que inclui explicitamente o WCAG 1.3.4 Orientação. Isso significa que qualquer serviço digital ou site operado por uma entidade abrangida não deve restringir o conteúdo a uma única orientação, refletindo a intenção da Circular de garantir que todos os cidadãos — incluindo aqueles com deficiência — possam acessar serviços digitais independentemente de como interagem fisicamente com seus dispositivos.
As entidades abrangidas pela Circular e obrigadas a alcançar conformidade de Nível AA incluem: instituições e órgãos públicos (todos os órgãos governamentais que operam sites e serviços digitais), bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, plataformas de e-commerce, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Para essas entidades, restrições de orientação que violem 1.3.4 — como portais governamentais que exigem acesso apenas em paisagem ou aplicativos bancários que bloqueiam em modo retrato por motivos não essenciais — constituem não conformidade direta com regulamentação nacional obrigatória.
O Logotipo de Acessibilidade (Erişilebilirlik Logosu), emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı), é uma marca de certificação que sinaliza conformidade com o padrão nacional de acessibilidade. Alcançar conformidade de Nível AA é um pré-requisito para obter esse logotipo. Organizações que buscam o Erişilebilirlik Logosu devem demonstrar que suas propriedades digitais atendem a todos os critérios de Nível A e Nível AA, incluindo 1.3.4. Uma falha de restrição de orientação — mesmo em uma seção menor de um site — pode comprometer toda a certificação.
Como o WCAG 1.3.4 exige testes manuais e não pode ser confirmado apenas por varreduras automatizadas, as entidades abrangidas devem incorporar casos de teste específicos de orientação em seus processos formais de auditoria de acessibilidade. A documentação dos resultados de teste em orientações retrato e paisagem em dispositivos reais deve ser mantida como parte dos registros de conformidade de acessibilidade exigidos para cumprimento regulatório e certificação do logotipo. O SDK Accsible auxilia organizações a identificar e abordar barreiras relacionadas à orientação como parte de uma abordagem holística para atender às obrigações em evolução da Turquia em acessibilidade digital.
