O que o 1.3.5 exige
A finalidade de cada campo de entrada que coleta informações sobre o usuário pode ser determinada programaticamente quando:
- O campo de entrada atende à finalidade identificada na seção Finalidades de Entrada para Componentes de Interface de Usuário; e
- O conteúdo é implementado por meio do uso de tecnologias com suporte para identificar o significado esperado para os dados de entrada do formulário.
Texto original, em inglês (WCAG 2.1)
The purpose of each input field collecting information about the user can be programmatically determined when:
- The input field serves a purpose identified in the Input Purposes for user interface components section; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
Digitar o mesmo nome, endereço e telefone em todo formulário é difícil para pessoas com deficiências de memória, de linguagem ou motoras. Quando o campo diz no código que quer o telefone de quem preenche, o navegador pode oferecer o preenchimento, e a tecnologia assistiva pode mostrar um símbolo conhecido ao lado. O Understanding 1.3.5 (em inglês) dá o exemplo de um bolo de aniversário na frente de um campo com autocomplete="bday".
Ele vale só para campos que coletam informações sobre o usuário, e só para as 53 finalidades que a WCAG lista, de name e email a cc-number e bday. O endereço de quem recebe um presente ou um cupom de desconto ficam de fora. O atributo type não basta: type="email" diz que o valor é um e-mail, não de quem. Um campo que aceita dois tipos de dado, como “e-mail ou usuário”, pode ter um token ou nenhum.
No HTML, o token no autocomplete é a técnica suficiente (H98), e um token errado é a falha F107 da WCAG. Desligar o preenchimento automático não tira a exigência: o documento Understanding indica jeitos de desligá-lo no formulário inteiro mantendo o token de cada campo.
Falhas comuns
Abaixo de cada exemplo: o que o axe-core e o Rampa relataram sobre a marcação de antes da correção, numa execução com o Gemma 4 12B em 9 de outubro de 2026.
Um campo do checkout sem token
O rótulo diz o que o campo quer, mas nada no código diz que é o telefone de quem compra, então o navegador não oferece o preenchimento. A regra do axe-core só lê o autocomplete quando o atributo existe.
Antes, reprova no 1.3.5
<label for="telefone">Telefone</label>
<input id="telefone" type="tel" name="telefone">Depois, aprova
<label for="telefone">Telefone</label>
<input id="telefone" type="tel" name="telefone"
autocomplete="tel">- axe-core
Aprova: sem o atributo, a
autocomplete-validnão tem o que conferir.- Rampa
O Rampa aprovou este campo na execução gravada em português: o modelo respondeu que o telefone era de outra pessoa, um falso negativo. Na execução em inglês, ele reprovou o mesmo campo e propôs
autocomplete="tel".
Um token copiado do campo de cima
O campo de sobrenome foi copiado do campo de nome e ficou com o token dele, então o navegador preenche o nome duas vezes. Um token válido que nomeia o dado errado é a falha F107 da WCAG, e nenhuma regra enxerga isso: given-name é um token válido num campo de texto.
Antes, reprova no 1.3.5
<label for="sobrenome">Sobrenome</label>
<input id="sobrenome" name="sobrenome"
autocomplete="given-name">Depois, aprova
<label for="sobrenome">Sobrenome</label>
<input id="sobrenome" name="sobrenome"
autocomplete="family-name">- axe-core
Aprova:
given-nameé um token válido para um campo de texto.- Rampa
✗ #sobrenome O campo "Sobrenome" pede o sobrenome de quem preenche, mas autocomplete="given-name" indica o primeiro nome. Evidência: "Sobrenome" Patch: - <input id="sobrenome" name="sobrenome" autocomplete="given-name"> + <input id="sobrenome" name="sobrenome" autocomplete="family-name"> confiança alta · 1/1 rodadas · evidência verificada · id 0907a996b6cc
Data de nascimento sem token
Um clube do café pede a data de nascimento para mandar um presente. Com autocomplete="bday", o navegador pode preencher, e a tecnologia assistiva pode marcar o campo com um símbolo que a pessoa já conhece.
Antes, reprova no 1.3.5
<label for="nascimento">Data de nascimento</label>
<input id="nascimento" type="date" name="nascimento">Depois, aprova
<label for="nascimento">Data de nascimento</label>
<input id="nascimento" type="date" name="nascimento"
autocomplete="bday">- axe-core
Aprova: não há
autocompletepara conferir.- Rampa
✗ #nascimento O campo "Data de nascimento" pede a data de nascimento de quem preenche, mas não identifica essa finalidade: falta autocomplete="bday". Evidência: "Data de nascimento" Patch: - <input id="nascimento" type="date" name="nascimento"> + <input id="nascimento" type="date" name="nascimento" autocomplete="bday"> confiança alta · 1/1 rodadas · evidência verificada · id c9b1c94451b9
O que o axe-core verifica
O axe-core 4.14.0 mapeia uma regra para o 1.3.5. A autocomplete-valid reprova um valor de autocomplete que não é um token válido, ou um token que o tipo do campo não aceita; a regra ACT 73f2c2 testa a mesma coisa. O Rampa relata as falhas dela como estão, e um campo reprovado pela autocomplete-valid nunca vai para o modelo.
| Regra | O que verifica | Mapeada para | Numa execução do Rampa |
|---|---|---|---|
autocomplete-valid, página da regra na Deque University, em inglês | Atributo 'autocomplete' deve ser usado corretamente | 1.3.5 | roda |
Ela só vale para campos que têm o atributo, e não lê o rótulo. Um campo sem autocomplete passa, e um token válido que nomeia outro dado também, como given-name num campo de sobrenome. De quem é o dado que o campo coleta, nenhuma regra consegue dizer.
Cada regra leva à página dela na Deque University, a empresa que mantém o axe-core (em inglês).
O que o Rampa julga, e como
O que vai para o modelo
Todo campo visível que recebe texto ou uma escolha e que a autocomplete-valid não reprovou: campos input dos tipos text, email, tel, url, password, number, date e month, select e textarea. Caixas de busca, botões, caixas de seleção, botões de opção e campos ocultos, desabilitados ou só de leitura ficam de fora, assim como um campo sem nome e sem placeholder, que é assunto da regra label do axe-core.
O que o modelo vê
- O rótulo, ou o placeholder quando não há rótulo.
- O tipo do campo, os atributos
nameeide as primeiras opções de umselect. - O que o
autocompleteatual diz: ausente, um valor que não nomeia finalidade, comooff, ou o dado que o token nomeia. - O cabeçalho visível acima do campo e a legenda do fieldset ou o grupo em que ele está.
- Os rótulos dos outros campos do mesmo formulário e os botões dele: um “Nome” ao lado de “Número do cartão” é o nome no cartão.
- Cada token com o significado, escrito no prompt, porque modelos locais não leem o schema JSON.
O que ele precisa responder
Primeiro, o que o campo pede, em poucas palavras; depois de quem é a informação (de quem preenche, de outra pessoa ou de ninguém), o token dessa finalidade ou nenhum, um veredito, o rótulo copiado como evidência e um grau de confiança.
O que derruba uma alegação
- A evidência não é o rótulo nem o placeholder.
- Uma reprovação fala de um dado que não é de quem preenche, ou não nomeia finalidade.
- A finalidade não está na lista da WCAG, como
one-time-code, ou é valor ou moeda de uma transação, que o documento Understanding diz raramente serem sobre o usuário. - O token é um que a própria tabela do axe-core não aceita naquele campo, então o patch poderia quebrar a regra do motor.
- O token atual já nomeia essa finalidade ou uma próxima, como
teletel-national,emaileusername, ounew-passwordecurrent-password. - O campo é um seletor de idioma ou país sem nenhum outro campo por perto: ele troca a página, não coleta dados.
O patch
Acrescenta o autocomplete com o token, ou troca o valor atual, mantendo o prefixo section-* e billing ou shipping.
Em todo critério
- O conteúdo da página chega ao modelo marcado como dado, e o prompt manda ignorar qualquer instrução que esteja nele.
- As respostas ficam em cache por um hash do prompt, da imagem, do modelo e das configurações, então a mesma entrada nunca chama um modelo duas vezes.
- Com
--runs 3, o Rampa pergunta três vezes e fica com a maioria; quando as rodadas discordam, a confiança cai. Achados abaixo de--min-confidence(média por padrão) ficam ocultos, e o--verboselista todos. - Alegações derrubadas pela verificação são contadas em todo relatório, nunca mostradas como achados.
Como o Rampa foi medido nele
| Conjunto | Testa | Casos | axe-core, precisão / recall | Rampa, precisão / recall / F1 |
|---|---|---|---|---|
| 1.3.5, autocomplete é válido (ACT 73f2c2) | sintaxe | 30 | 1,00 / 1,00 | 0,83 / 1,00 / 0,91 |
Pares corrompidos: o Rampa separou 8 de 9 (autocomplete removido) e 6 de 7 (autocomplete trocado por outro dado), o axe-core 0. Um par é uma página de teste que passa e uma cópia quebrada de propósito; quem dá o mesmo veredito às duas não está julgando.
Rodada em 9 de outubro de 2026: axe-core 4.14.0, Gemma 4 12B numa GPU local, raciocínio desligado, uma rodada, casos de teste ACT a9a1483e. Amostras pequenas e uma rodada só: leia os números como um pipeline que funciona, não como resultado.
Leia com estas ressalvas
- A regra ACT 73f2c2 mede o motor: se o token é válido. Com o julgamento ligado, a precisão cai para 0,83, porque dois casos que ela considera não aplicáveis, um campo “Username” com
autocomplete="", são falhas do 1.3.5 que o Rampa aponta. - Nenhuma regra ACT julga token ausente ou errado, então o julgamento é medido com pares feitos das páginas que passam no 73f2c2, com o token removido ou trocado por um token válido de outro dado. O único erro de cada tipo é “Partner’s email address”, dado de outra pessoa, em que aprovar é o certo.
- O prompt e o contexto foram revisados depois de ler os erros de rodadas anteriores nesses casos, sem copiar as páginas de teste para o prompt. Leia os números como um pipeline que funciona, não como resultado.
Limitações
- Na execução gravada para esta página, o Gemma aprovou com razão o e-mail de quem recebe um presente, em português e em inglês. Em português, também aprovou “Telefone”, respondendo que o telefone era de outra pessoa: um falso negativo.
- Se o dado é sobre quem preenche é decisão do modelo, e quem recebe um presente, um cônjuge ou um filho podem ser confundidos nos dois sentidos.
- Um campo que junta duas finalidades, como “e-mail ou usuário”, passa sem token, como o documento Understanding permite.
- Lê só o atributo
autocompletedo HTML, em páginas web. Outros jeitos de expor a finalidade, como o módulo de símbolos do WAI-Adapt, não são lidos. - Em páginas reais, achou campos de newsletter e de login sem token em mozilla.org, kabum.com.br, saucedemo.com e wordpress.org, e aprovou o login do GitHub. Um estudo de falsos positivos em páginas reais está no roadmap.
Perguntas sobre o 1.3.5
autocomplete="off" reprova no WCAG 1.3.5?
Num campo com dados da própria pessoa, sim: off não nomeia finalidade, e o documento Understanding diz que a finalidade precisa continuar determinável programaticamente quando o autor impede o preenchimento automático. Ele indica jeitos de desligar o preenchimento no formulário inteiro mantendo o token de cada campo. O Rampa aponta off num campo assim como finalidade não identificada.
O 1.3.5 vale para todo campo de formulário?
Não. Só para campos que coletam informações sobre o usuário, numa das 53 finalidades que a WCAG lista. Caixa de busca, quantidade, cupom de desconto ou endereço de quem recebe um presente não precisam de token. O documento Understanding observa que algumas finalidades da lista, como transaction-amount, raramente são sobre o usuário.
type="email" basta?
Não. O documento Understanding explica que type="email" diz que o valor é um e-mail, não se é de quem preenche ou de outra pessoa. O autocomplete="email" diz que é de quem preenche.
O axe-core verifica o 1.3.5?
Em parte. A autocomplete-valid confere se o valor do autocomplete é um token válido que serve para o campo. Ela não olha campos sem o atributo, nem se o token nomeia o dado que o rótulo pede.
Verifique suas páginas
O Rampa ainda não está no npm. Clone e rode a partir do código, com Node.js 22.12 ou mais novo e Chrome ou Edge. O --criteria 1.3.5 julga só este critério; sem ele, rodam os oito que rodam por padrão.
Com o Ollama rodando, o Rampa escolhe um modelo local sozinho; o node dist/cli.mjs doctor diz o que falta.
git clone https://github.com/guilhermebsantiago/rampa-cli.git
cd rampa-cli
pnpm install && pnpm build
node dist/cli.mjs check https://example.com --criteria 1.3.5Conferido com o rampa-cli (commit 0459809) e as fontes do W3C em 9 de outubro de 2026.