WCAG 1.3.5: Identificar a Finalidade da Entrada

O que Esta Regra Significa

WCAG 1.3.5 — Identify Input Purpose é um critério de Nível AA introduzido no WCAG 2.1 e mantido no WCAG 2.2. Ele exige que qualquer elemento <input>, <select> ou <textarea> que colete informações sobre a pessoa usuária tenha sua finalidade comunicada de forma programática, para que navegadores e tecnologias assistivas possam identificar e agir automaticamente com base nessa finalidade.

O mecanismo para atender a esse critério é o atributo autocomplete, combinado com o valor de token correto da lista oficial definida na especificação HTML. Quando um campo coleta nome, endereço de e-mail, número de telefone, endereço postal, número de cartão de crédito ou dados pessoais semelhantes da pessoa usuária, o atributo autocomplete deve conter um valor que descreva com precisão a finalidade daquele campo — por exemplo, autocomplete="given-name" para um campo de primeiro nome, ou autocomplete="email" para um campo de e-mail.

O critério se aplica especificamente a entradas que coletam informações sobre a própria pessoa usuária. Ele não se aplica a campos em que a pessoa usuária está inserindo dados sobre outra pessoa (por exemplo, um formulário de reserva de viagem que pede o nome do passageiro quando a pessoa usuária está reservando em nome de outra pessoa), nem se aplica a campos em que o preenchimento automático criaria um risco de segurança — como senhas de uso único ou desafios do tipo CAPTCHA, que podem legitimamente usar autocomplete="off" ou autocomplete="one-time-code".

Para passar, é necessário que: (1) todo campo de entrada dentro do escopo tenha um atributo autocomplete; e (2) o valor desse atributo seja um token válido e reconhecido pela especificação de preenchimento automático (autofill) do HTML — não uma string arbitrária, não um valor vazio quando um valor significativo é necessário e não um token escrito de forma incorreta. Há falha quando uma entrada dentro do escopo não tem atributo autocomplete, tem autocomplete="off" sem justificativa ou tem um token inválido como autocomplete="firstname" (o token correto é given-name) ou autocomplete="phone" (o token correto é tel).

A lista completa de tokens de autocomplete válidos é mantida pelo WHATWG HTML Living Standard e inclui valores para nomes (given-name, family-name, additional-name), endereços (street-address, address-line1, postal-code, country-name), informações de contato (email, tel, tel-national), credenciais (username, current-password, new-password), detalhes de pagamento (cc-name, cc-number, cc-exp, cc-csc) e outros. Tokens também podem ser prefixados com identificadores de seção (por exemplo, section-billing) e palavras-chave de envio ou cobrança para lidar com vários grupos de endereços em uma única página.

Por Que Isso Importa

Esse critério existe principalmente para beneficiar pessoas com deficiências cognitivas, incluindo pessoas com dislexia, comprometimentos de memória, condições de déficit de atenção e dificuldades de aprendizagem. Para essas pessoas, preencher corretamente um formulário de checkout complexo — com campos separados para primeiro nome, sobrenome, endereço, cidade, código postal, telefone e detalhes de pagamento — pode ser uma carga cognitiva significativa. Quando os tokens de autocomplete estão corretos, os navegadores podem pré-preencher campos a partir do perfil salvo da pessoa usuária com uma única interação, reduzindo drasticamente o atrito e o risco de erros.

Pessoas com deficiências motoras — incluindo pessoas com função limitada das mãos que usam acesso por varredura (switch), software de rastreamento ocular ou dispositivos de sopro e sucção — também se beneficiam igualmente. Digitar é lento, exige esforço e às vezes é doloroso para essas pessoas. Um preenchimento automático que funcione de forma confiável pode transformar um processo de dez minutos em uma tarefa quase instantânea. 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 significativa, e deficiências motoras que afetam o controle fino das mãos estão entre as mais comuns.

Além do preenchimento automático, tokens de autocomplete corretos permitem que navegadores e tecnologias assistivas apresentem ícones personalizados, rótulos ou interfaces de entrada aumentadas — por exemplo, exibindo automaticamente um teclado numérico de telefone para um campo tel em um dispositivo móvel, ou mostrando um gráfico de cartão de crédito para um campo cc-number. Gerenciadores de senhas, que são ferramentas de acessibilidade essenciais para pessoas com comprometimentos de memória, também dependem desses tokens para identificar e preencher corretamente campos de credenciais.

Considere um cenário do mundo real: uma pessoa com paralisia cerebral está preenchendo um formulário de solicitação de benefícios governamentais. O formulário tem doze campos cobrindo nome, endereço, documento nacional de identidade e dados de contato. Sem valores de autocomplete corretos, cada campo precisa ser digitado manualmente. Um único token escrito de forma incorreta — por exemplo, autocomplete="surname" em vez de autocomplete="family-name" — é suficiente para impedir que o navegador reconheça o campo, deixando a pessoa usuária digitar o sobrenome caractere por caractere. Com tokens corretos, o formulário inteiro pode ser preenchido automaticamente em segundos, reduzindo tanto o esforço quanto as taxas de erro.

Também há benefícios de usabilidade e de taxa de conversão para as organizações: pesquisas mostram de forma consistente que formulários compatíveis com preenchimento automático têm menores taxas de abandono e maiores taxas de conclusão, o que significa que corrigir tokens de autocomplete não é apenas uma melhoria de acessibilidade, mas também uma melhoria direta para o negócio.

Regras Relacionadas do Axe-core

• autocomplete-valid — Esta é a principal regra do axe-core para WCAG 1.3.5. Ela inspeciona todo elemento <input>, <select> e <textarea> que tenha um atributo autocomplete e verifica se o valor do atributo é um token válido e reconhecido pela especificação de preenchimento automático do HTML. A regra sinaliza elementos em que o token está escrito de forma incorreta (por exemplo, given name com um espaço em vez de hífen), em que foi usado um valor proprietário não padronizado (por exemplo, autocomplete="first-name") ou em que a ordem dos tokens em um valor com vários tokens está incorreta (por exemplo, colocando o nome do campo antes de um prefixo de seção obrigatório). A regra não sinaliza campos que estão totalmente sem atributo autocomplete — essa situação exige revisão manual — porque o axe-core não consegue determinar de forma programática se um determinado campo está no escopo do critério (isto é, se ele coleta informações sobre a pessoa usuária).
• Por que também é necessário teste manual — Ferramentas automatizadas como o axe-core só conseguem validar se um valor de autocomplete presente é sintaticamente correto; elas não conseguem determinar se o token escolhido descreve com precisão a finalidade do campo. Por exemplo, um campo de telefone de cobrança com autocomplete="email" passaria na regra automatizada (já que email é um token válido), mas falharia no critério porque o token não corresponde à finalidade real do campo. Da mesma forma, ferramentas automatizadas não conseguem identificar campos que estão sem atributo autocomplete mas deveriam tê-lo, porque determinar se um campo coleta informações pessoais sobre a pessoa usuária exige julgamento humano com base no contexto. A revisão manual de todo campo de formulário que coleta dados específicos da pessoa usuária é, portanto, essencial para a conformidade completa com 1.3.5.

Como Testar

1. Execute uma varredura automatizada com axe DevTools ou Lighthouse. Abra a página que contém o formulário no Chrome ou Firefox. No axe DevTools, clique em "Analyze" e filtre os resultados pelo ID de regra autocomplete-valid. No Lighthouse, execute uma auditoria de acessibilidade e procure violações que façam referência a autocomplete. Anote cada elemento sinalizado e registre os valores de token inválidos relatados. Corrija cada elemento sinalizado e execute a varredura novamente para confirmar a correção.
2. Identifique manualmente todos os campos de entrada dentro do escopo. Revise o formulário e liste todos os campos que coletam informações sobre a pessoa usuária atual — campos de nome, campos de endereço, e-mail, telefone, detalhes de pagamento, credenciais. Para cada campo, verifique se há um atributo autocomplete presente e se o token corresponde à finalidade real do campo de acordo com a lista de tokens de preenchimento automático do HTML. Campos que coletam informações sobre outras pessoas estão fora do escopo e podem ser excluídos.
3. Teste o comportamento de preenchimento automático do navegador. No Chrome ou Firefox, verifique se o navegador tem um perfil salvo (Configurações > Autofill). Navegue até a página do formulário e clique no primeiro campo de informações pessoais. Confirme se o navegador apresenta uma sugestão de preenchimento automático e se, ao selecioná-la, os campos corretos são preenchidos com os valores corretos. Repita para campos de endereço, campos de pagamento e campos de credenciais. Se o preenchimento automático não sugerir valores ou preencher campos errados, é provável que os tokens de autocomplete estejam incorretos.
4. Teste com uma combinação de leitor de tela e navegador. Com NVDA e Firefox, navegue até cada campo do formulário usando a tecla Tab. O NVDA deve anunciar o rótulo e a finalidade do campo; algumas combinações de leitor de tela e navegador também anunciarão a finalidade de autocomplete. Com o VoiceOver no macOS (Safari), navegue pelos campos usando Tab e ouça o VoiceOver anunciar a disponibilidade de preenchimento automático. Com JAWS e Chrome, da mesma forma, percorra os campos com Tab e confirme se o JAWS anuncia o contexto esperado do campo. Embora leitores de tela nem sempre anunciem explicitamente tokens de autocomplete, confirmar que o preenchimento automático funciona corretamente em combinação com a navegação por teclado valida que a finalidade programática está exposta.
5. Inspecione os atributos de autocomplete nas DevTools do navegador. Clique com o botão direito em cada campo do formulário e selecione "Inspect". No painel Elements, confirme se o atributo autocomplete está presente e se seu valor corresponde exatamente a um token válido. Preste atenção especial a valores com vários tokens — por exemplo, autocomplete="shipping street-address" — e confirme se a ordem dos tokens segue a especificação (nome da seção, depois "shipping" ou "billing", depois o nome do campo).

Como Corrigir

Campos de nome — Incorreto

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Campos de nome — Correto

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Formulário de endereço com seções de cobrança e envio — Incorreto

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Formulário de endereço com seções de cobrança e envio — Correto

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Campo de telefone — Incorreto

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Campo de telefone — Correto

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Credenciais de login — Incorreto

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Credenciais de login — Correto

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Erros Comuns

• Usar autocomplete="firstname" ou autocomplete="first-name" em vez do token correto given-name". Esses valores não padronizados não são reconhecidos por navegadores ou tecnologias assistivas, mesmo parecendo lógicos. Sempre use os tokens exatos da especificação de preenchimento automático do HTML.
• Usar autocomplete="phone" em vez de autocomplete="tel". A palavra "phone" não é um token válido. A especificação usa tel para um número de telefone completo e tel-national, tel-area-code, tel-local para subpartes de um número de telefone.
• Definir autocomplete="off" em campos de credenciais como uma medida equivocada de segurança. Navegadores modernos e a especificação WCAG reconhecem que impedir o preenchimento automático em formulários de login cria barreiras reais para pessoas com deficiência e não melhora a segurança de forma significativa. Use autocomplete="username" e autocomplete="current-password" em vez disso.
• Omitir completamente o atributo autocomplete em campos de dados pessoais, presumindo que o navegador inferirá a finalidade a partir do nome ou rótulo do campo. Navegadores usam heurísticas para adivinhar a finalidade do campo, mas elas são pouco confiáveis e inconsistentes entre navegadores. Tokens explícitos são necessários para uma experiência garantida e acessível.
• Usar autocomplete="address" em vez dos sub-tokens específicos de endereço. Não existe token address na especificação. É necessário usar street-address, address-line1, address-line2, address-level1 (estado/província), address-level2 (cidade) e postal-code individualmente.
• Colocar palavras-chave de envio ou cobrança na ordem errada em valores com vários tokens. A ordem correta é: prefixo de seção opcional (por exemplo, section-billing), depois a palavra-chave opcional shipping/billing, depois o token do nome do campo. Escrever autocomplete="street-address billing" é inválido; a forma correta é autocomplete="billing street-address".
• Aplicar autocomplete apenas a campos visíveis e ignorar campos ocultos ou revelados dinamicamente. Campos que estão inicialmente ocultos, mas são revelados por meio de interação da pessoa usuária (como linhas adicionais de endereço ou campos opcionais) também devem ter tokens de autocomplete corretos quando se tornam ativos.
• Usar JavaScript para remover ou sobrescrever dinamicamente o atributo autocomplete após o carregamento da página. Algumas bibliotecas de formulários ou frameworks de UI redefinem atributos de entrada quando componentes são montados ou renderizados novamente, removendo inadvertidamente tokens de autocomplete. Sempre verifique se o atributo permanece no DOM em tempo de execução depois que todo o JavaScript tiver sido executado.
• Presumir que type="email" ou type="tel" em um input é suficiente para comunicar a finalidade sem autocomplete. Embora type forneça alguma informação, o atributo autocomplete é um sinal separado e explícito exigido pelo WCAG 1.3.5 e usado de forma diferente por navegadores e tecnologias assistivas.
• Usar o mesmo token de autocomplete em dois campos diferentes que coletam dados distintos. Por exemplo, rotular tanto um campo de e-mail profissional quanto um campo de e-mail pessoal com autocomplete="email" confunde os navegadores e pode resultar em preenchimento automático incorreto. Use prefixos de seção (por exemplo, section-work email vs. section-personal email) para desambiguar.

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 para uma ampla gama de organizações que operam na Turquia. A Circular determina a conformidade com o WCAG 2.2 em Nível AA como padrão básico para serviços digitais, o que inclui diretamente o WCAG 1.3.5 — Identify Input Purpose.

Os tipos de entidades abrangidos pela Circular são bastante amplos. Instituições públicas e órgãos governamentais são obrigados a atender a esses padrões para todos os serviços digitais voltados à cidadania. As organizações do setor privado abrangidas incluem plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e prestadores de serviços de saúde, operadoras de telecomunicações com 200.000 ou mais assinantes, agências de viagens licenciadas, empresas privadas de transporte de passageiros e instituições de ensino privadas autorizadas pelo Ministério da Educação Nacional (MoNE). A implicação prática é que praticamente todo produto digital de grande porte voltado ao consumidor na Turquia — de aplicativos bancários a checkouts de varejo online e portais de agendamento de serviços de saúde — deve ter tokens de autocomplete corretamente implementados em todos os campos de entrada de dados pessoais.

Especificamente para o WCAG 1.3.5, isso significa que qualquer formulário de checkout de e-commerce turco, formulário de abertura de conta bancária, formulário de registro de paciente em hospital ou formulário de assinatura de telecom que colete informações da pessoa usuária, como nome, endereço, número de telefone ou detalhes de pagamento, deve incluir valores válidos de atributo autocomplete em cada campo de entrada relevante. Deixar de fazê-lo constitui uma não conformidade de Nível AA e pode impedir que uma organização obtenha ou mantenha o Accessibility Logo (Erişilebilirlik Logosu), a marca oficial emitida pelo Ministério da Família e Serviços Sociais que certifica que os serviços digitais de uma organização atendem aos padrões de acessibilidade.

O Accessibility Logo tem peso reputacional e regulatório, e organizações em mercados de consumo competitivos — como e-commerce e bancos — têm fortes incentivos para alcançá-lo e mantê-lo. Como o WCAG 1.3.5 é simples de implementar (adicionar ou corrigir valores de atributo autocomplete não exige mudanças de arquitetura) e ainda assim oferece benefícios significativos para pessoas com deficiências cognitivas e motoras, ele representa uma das melhorias de acessibilidade de maior valor e menor esforço que uma organização pode fazer na busca pela conformidade completa em Nível AA sob a Circular 2025/10.

As organizações devem auditar todos os formulários em suas propriedades digitais — incluindo interfaces web móveis e layouts responsivos — e estabelecer uma política de desenvolvimento que exija tokens de autocomplete corretos como parte padrão de qualquer implementação de formulário. Isso deve ser aplicado por meio de testes automatizados em pipelines de CI/CD usando ferramentas como o axe-core, para que regressões sejam detectadas antes de chegarem à produção.