WCAG 1.3.3: Características Sensoriais

O Que Esta Regra Significa

O Critério de Sucesso 1.3.3 das WCAG — Características Sensoriais (Nível A) estabelece que as instruções fornecidas para compreender e operar o conteúdo não devem depender exclusivamente de características sensoriais de componentes, como forma, tamanho, localização visual, orientação ou som. Em outras palavras, se a sua interface disser a um usuário para interagir com algo referindo-se apenas à aparência, à posição na tela ou ao som, essa instrução será sem sentido para usuários que não conseguem perceber essas propriedades sensoriais específicas.

A palavra-chave aqui é exclusivamente. O critério não proíbe o uso de referências sensoriais — ele proíbe que elas sejam o único meio de identificação. Uma instrução como "clique no botão redondo verde à esquerda" falha quando um usuário não consegue distinguir verde, não consegue ver a forma do botão ou não consegue determinar esquerda e direita devido a um layout em reflow. No entanto, "clique no botão Enviar (o botão redondo verde à esquerda)" passa, porque o rótulo de texto "Enviar" fornece um identificador não sensorial que funciona independentemente de cor, forma e posição.

As instruções afetadas por este critério incluem qualquer conteúdo em texto, áudio ou visual que direcione usuários a realizar uma ação ou localizar informações. Padrões comuns de falha incluem:

• "Clique no botão à direita para continuar" — depende exclusivamente da localização visual.
• "Selecione o ícone quadrado para abrir as configurações" — depende exclusivamente da forma.
• "Os campos obrigatórios são mostrados em vermelho" — depende exclusivamente da cor.
• "Quando você ouvir o sino, prossiga para a próxima etapa" — depende exclusivamente do som.
• "Toque no bloco grande para expandir a seção" — depende exclusivamente do tamanho.

Uma instrução em conformidade sempre inclui pelo menos um identificador não sensorial — tipicamente um rótulo de texto, um nome programático ou um cabeçalho — para que usuários que dependem de tecnologia assistiva ou que operam em condições em que pistas sensoriais não estão disponíveis ainda possam seguir as instruções. Observe que este critério cobre especificamente instruções; ele não exige que todo elemento de UI seja redesenhado, mas exige que qualquer orientação textual ou falada sobre esses elementos seja perceptível sem discriminação sensorial.

Não há exceções oficiais definidas no próprio 1.3.3, embora o documento Understanding esclareça que conteúdo que usa características sensoriais além de identificadores não sensoriais está totalmente em conformidade. O critério também complementa, mas é distinto de 1.4.1 (Uso de Cor), que trata especificamente apenas de cor; 1.3.3 tem um escopo mais amplo, cobrindo todas as modalidades sensoriais.

Por Que Isso Importa

Instruções apenas sensoriais criam barreiras significativas para uma ampla gama de usuários. Considere cada grupo afetado:

Pessoas cegas e com baixa visão dependem de leitores de tela ou softwares de ampliação. Quando uma instrução diz "clique no ícone no canto superior direito", um usuário de leitor de tela que navega pela ordem de tabulação ou pela estrutura de cabeçalhos não tem conceito de "canto superior direito" no layout visual. Da mesma forma, um usuário com baixa visão severa que deu zoom para 400% pode ver apenas uma pequena parte da tela por vez, tornando referências posicionais como "painel esquerdo" ou "seção inferior" completamente pouco confiáveis. De acordo com a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, tornando este um dos maiores grupos afetados.

Pessoas daltônicas — afetando aproximadamente 1 em cada 12 homens e 1 em cada 200 mulheres — não conseguem distinguir certos pares de cores. Uma instrução que diz "campos destacados em vermelho são obrigatórios" é invisível como pista distintiva para alguém com daltonismo vermelho-verde. Embora 1.4.1 trate disso para o próprio elemento de UI, 1.3.3 garante que o texto instrucional também forneça uma alternativa.

Pessoas surdas e com deficiência auditiva são impactadas por pistas apenas em áudio. Se uma plataforma de e-learning instrui usuários a "prosseguir quando ouvir o sino", usuários que não podem ouvir o sino são excluídos. Esse padrão aparece em apresentações interativas, tutoriais em vídeo e avaliações cronometradas.

Pessoas com deficiências cognitivas e de aprendizagem podem ter dificuldades com linguagem direcional, especialmente quando sua tecnologia assistiva renderiza o conteúdo em forma linearizada que remove o posicionamento visual. Uma pessoa usando um dispositivo de varredura (switch) ou sistema de rastreamento ocular também navega em sequências que podem não ter relação com o layout espacial bidimensional imaginado por um designer vidente.

Considere um cenário concreto do mundo real: um portal de e-serviços do governo turco instrui cidadãos a "preencher os campos contornados em azul e depois pressionar o botão triangular para enviar sua solicitação". Um usuário cego que navega pelos campos de formulário ouve os rótulos dos campos via leitor de tela, mas não tem como saber quais campos estão contornados em azul, nem pode identificar um botão pela sua forma triangular. O processo de solicitação fica efetivamente bloqueado. Adicionar os rótulos reais dos campos (por exemplo, "Nome, Número de ID e Data de Nascimento são obrigatórios") e o rótulo de texto do botão ("Enviar Solicitação") resolve instantaneamente a barreira.

Além da acessibilidade, remover instruções apenas sensoriais melhora a usabilidade para todos. Designs responsivos fazem o conteúdo fluir, de modo que referências posicionais se tornam imprecisas em dispositivos móveis. Modo escuro ou temas de alto contraste alteram a renderização de cores. Assistentes de voz que leem instruções da página em voz alta removem todo o contexto visual. Construir instruções em torno de rótulos programáticos estáveis, em vez de propriedades sensoriais transitórias, torna o conteúdo mais robusto em todos os dispositivos e contextos — também um benefício direto para SEO e manutenção.

Regras Relacionadas do Axe-core

WCAG 1.3.3 exige testes manuais porque ferramentas automatizadas não conseguem interpretar de forma confiável o significado ou a intenção de instruções em linguagem natural. Um mecanismo de análise estática pode detectar que um botão existe ou que uma cor é usada, mas não consegue ler um parágrafo de texto instrucional, entender que ele se refere a um botão e então determinar se essa referência é exclusivamente sensorial. Este é um julgamento semântico e contextual que exige revisão humana.

• Revisão manual obrigatória — não existe regra dedicada do axe-core para 1.3.3. Regras do axe-core como color-contrast e label podem revelar problemas relacionados (por exemplo, um botão sem nome acessível), mas tratam de critérios diferentes. Para 1.3.3, um testador humano deve ler cada frase instrucional na página, identificar quaisquer referências sensoriais (forma, cor, tamanho, localização, orientação, som) e verificar se pelo menos um identificador não sensorial acompanha cada referência. Ferramentas automatizadas não sinalizarão uma frase como "clique no botão verde abaixo" como violação porque analisar a intenção em linguagem natural está além da automação baseada em regras atual.
• Por que a automação falha aqui: Considere que "clique no botão grande" contém a palavra "botão", que uma ferramenta automatizada pode interpretar como referência a uma função acessível. Mas a instrução ainda depende exclusivamente do tamanho ("grande") para distinguir esse botão de outros. Ferramentas automatizadas não conseguem determinar se "grande" é a única característica distintiva ou se há apenas um botão na página (tornando "grande" redundante, mas não prejudicial). O julgamento humano é essencial para avaliar essas nuances em contexto.
• Regras complementares do axe para executar junto com a revisão manual: Executar verificações color-contrast, label, button-name e aria-label ajudará a garantir que os elementos de UI referenciados nas instruções realmente tenham nomes programáticos — um pré-requisito para escrever instruções não sensoriais. Se um botão não tiver nome acessível, nenhuma instrução poderá referenciá-lo de forma significativa sem recorrer a pistas sensoriais.

Como Testar

1. Execute primeiro uma varredura automatizada (axe DevTools ou Lighthouse): Abra a página no Chrome, ative a extensão axe DevTools e execute uma varredura de página inteira. Embora nenhuma regra mapeie diretamente para 1.3.3, revise quaisquer problemas sinalizados nas categorias "color", "label" e "name". Esses resultados fornecem uma linha de base — se elementos de UI não tiverem nomes acessíveis, o texto instrucional que os referencia quase certamente está dependendo de pistas sensoriais. Exporte os resultados e anote todos os elementos interativos sem rótulos programáticos.
2. Identifique manualmente todo o texto instrucional: Leia cada frase na página que direcione um usuário a realizar uma ação ou localizar informações. Isso inclui textos de ajuda, dicas de formulário, tooltips, sobreposições de tutorial, mensagens de erro e fluxos de onboarding. Crie uma lista de cada instrução e destaque quaisquer referências sensoriais: palavras de cor (vermelho, azul, verde), palavras de forma (redondo, quadrado, triangular), palavras de tamanho (grande, pequeno), palavras posicionais (esquerda, direita, topo, fundo, acima, abaixo, canto), palavras de orientação (horizontal, vertical) e referências a som (sino, bip, som de alerta).
3. Avalie cada referência sensorial em busca de identificadores não sensoriais adicionais: Para cada referência sensorial encontrada, determine se um identificador não sensorial também está presente. Um identificador não sensorial inclui um rótulo de texto que corresponda ao rótulo visível ou ao nome acessível do elemento, um cabeçalho, uma etapa numerada, uma função programática exclusiva ou um rótulo ARIA. Se a única forma de identificar o elemento referenciado for por percepção sensorial, a instrução falha em 1.3.3.
4. Teste com um leitor de tela (NVDA + Firefox): Navegue pela página usando apenas o teclado e o NVDA. Percorra todos os elementos interativos com a tecla Tab e ouça como o NVDA anuncia cada um. Em seguida, leia o texto instrucional na página e pergunte: um usuário ouvindo apenas esses anúncios conseguiria seguir as instruções? Se uma instrução diz "clique no ícone à direita", mas o NVDA anuncia o elemento como "Configurações, botão", então a referência posicional é supérflua, mas o rótulo torna a instrução navegável. Se o NVDA anunciar o elemento como "botão" sem nome, a instrução que depende da posição visual falha completamente.
5. Teste com VoiceOver + Safari (macOS/iOS): Ative o VoiceOver e navegue pela página. Use o rotor para navegar por botões, links e controles de formulário. Verifique se cada elemento referenciado em uma instrução é alcançável e identificável apenas pelo nome anunciado, sem depender de sua posição no layout visual.
6. Teste com JAWS + Chrome: Abra a página no Chrome com o JAWS ativo. Use o Forms Mode para navegar pelos campos e ouça os anúncios dos campos. Faça a correlação com quaisquer instruções em nível de formulário que usem cor ou posição para indicar campos obrigatórios.
7. Teste em modos de alto contraste e escuro: Altere o sistema operacional para o modo de alto contraste e recarregue a página. Instruções codificadas por cor que se referem a cores específicas podem se tornar ambíguas ou invisíveis quando a renderização de cor muda. Isso ajuda a revelar dependências ocultas de cor como única pista sensorial.
8. Teste em uma visualização móvel com zoom ou reflow: Redimensione a janela do navegador para 320px de largura ou use um dispositivo móvel. Instruções que usam linguagem posicional como "barra lateral esquerda" ou "navegação superior" ainda devem fazer sentido quando o layout tiver sido reorganizado para uma única coluna.

Como Corrigir

Instruções de Campos de Formulário Apenas por Cor — Incorreto

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Instruções de Campos de Formulário Apenas por Cor — Correto

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Referência Posicional a Botão — Incorreto

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Referência Posicional a Botão — Correto

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Navegação por Ícone Apenas por Forma — Incorreto

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Navegação por Ícone Apenas por Forma — Correto

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Pista de Progresso Apenas em Áudio — Incorreto

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Pista de Progresso Apenas em Áudio — Correto

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Erros Comuns

• Escrever "o botão vermelho" ou "o campo verde" como único identificador em instruções de formulário ou texto de ajuda, sem também fornecer o rótulo visível do botão ou o nome do campo — isso falha tanto em 1.3.3 quanto em 1.4.1.
• Usar frases posicionais como "o menu à esquerda" ou "o painel no topo" em documentação de ajuda ou fluxos de onboarding sem nomear o menu ou painel, tornando as instruções inúteis depois que o reflow responsivo colapsa o layout em uma única coluna.
• Descrever ícones apenas pela forma ("clique no botão triangular de play") em vez de usar o nome ou rótulo acessível do ícone, que um usuário de leitor de tela poderia realmente localizar por navegação via teclado.
• Indicar campos de formulário obrigatórios exclusivamente por cor de borda ou cor de fundo em instruções inline ("campos laranja devem ser preenchidos") sem um símbolo, sufixo de rótulo ou atributo aria-required='true' para transmitir a mesma informação de forma programática.
• Colocar feedback apenas em áudio para processos interativos (envio de arquivos, envio de formulários, expiração de temporizadores) sem uma atualização de status em texto visível correspondente usando role='status' ou aria-live='polite'.
• Usar tamanho como única pista distintiva — instruções como "clique no cartão grande para expandir" falham quando o usuário dá zoom, quando os cartões são renderizados com tamanhos idênticos em viewports menores ou quando um usuário de leitor de tela não tem conceito de tamanhos relativos de cartões no DOM.
• Depender de pistas de orientação como "deslize horizontalmente para navegar" sem fornecer um método de interação alternativo e um rótulo não baseado em orientação para o carrossel ou slider descrito.
• Esquecer que mensagens de erro também são instruções — um erro que diz "os campos destacados abaixo contêm erros" depende de destaque visual e proximidade posicional, e será inútil para um usuário de leitor de tela, a menos que cada campo com erro também seja nomeado explicitamente na mensagem de erro.
• Presumir que adicionar texto alternativo ao ícone corrige a instrução — se o texto instrucional ainda disser apenas "clique no ícone circular", o fato de o ícone ter texto alternativo no elemento de imagem não torna a instrução em conformidade; o próprio texto instrucional deve incluir um identificador não sensorial.
• Negligenciar instruções injetadas dinamicamente em aplicações de página única — tooltips, modais e etapas de assistentes (wizards) injetados via JavaScript frequentemente contêm orientações apenas sensoriais que escapam à revisão de QA porque não estão visíveis em uma auditoria de página estática.

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 na web para uma ampla gama de entidades públicas e privadas que operam na Turquia. A circular exige conformidade com as WCAG 2.1 Nível AA como padrão de base, e a WCAG 1.3.3 — como critério de Nível A — é, portanto, totalmente obrigatória para todas as entidades abrangidas.

As entidades abrangidas pela circular incluem instituições e agências públicas, 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). Instituições públicas devem alcançar conformidade total dentro de um ano a partir da data de publicação da circular, enquanto entidades do setor privado têm um prazo de dois anos.

A WCAG 1.3.3 é particularmente relevante para serviços digitais turcos, dada a ampla utilização de orientações de formulário codificadas por cor e padrões de navegação apenas por ícone em portais de governo eletrônico, aplicações bancárias e fluxos de checkout de e-commerce na Turquia. Por exemplo, um formulário de solicitação online de uma instituição pública que instrua cidadãos a "preencher os campos marcados em vermelho" e enviar "pressionando o botão no canto inferior direito" estaria em violação direta de 1.3.3 e constituiria falha em cumprir a Circular Presidencial. Da mesma forma, uma interface web móvel de um banco que guie usuários por transações em múltiplas etapas usando apenas pistas de posição e cor precisaria ser revisada antes do prazo de dois anos para o setor privado.

A não conformidade acarreta riscos reputacionais e legais à medida que o ambiente regulatório da Turquia em torno da acessibilidade digital amadurece. Entidades abrangidas devem tratar a conformidade com 1.3.3 não como um pequeno ajuste editorial, mas como uma revisão sistêmica de todo o conteúdo instrucional — incluindo textos de ajuda, mensagens de erro, fluxos de onboarding e documentação de suporte — para garantir que referências sensoriais sejam sempre acompanhadas por identificadores estáveis, programáticos e baseados em texto. O SDK de overlay da Accsible pode ajudar a identificar e remediar muitos problemas relacionados, embora a revisão manual de conteúdo exigida por 1.3.3 deva, em última instância, ser realizada por um auditor humano qualificado trabalhando em conjunto com ferramentas automatizadas.