Transcrição Episódio 5 Podcast Todos na Web

[Reinaldo]
Olá, eu sou Reinaldo Ferraz, especialista em acessibilidade do Ceweb.br.
Eu sou um homem branco, com cabelos lisos castanho-claro e olhos verdes. Tenho uma barba cerrada, que já está quase toda branca, e estou usando uma camisa preta do Ceweb.br.
E hoje a gente vai falar sobre acessibilidade digital. Estou aqui com duas especialistas em acessibilidade, a Cláudia e a Sandyara, e eu gostaria que elas se apresentassem para a gente começar o nosso episódio. Sejam bem-vindas!
________________________________________
[Cláudia]
Olá, muito obrigada!
Eu sou a Cláudia Martin Nascimento, sou uma mulher de pele clara, tenho cabelos castanhos escuros, mais ou menos na altura dos ombros. Tenho olhos castanhos escuros, uso óculos e estou vestindo uma camiseta azul, com a manga em um azul um pouco mais escuro.
Eu sou designer por formação e trabalho com acessibilidade há mais ou menos 13 anos. Sempre trabalhei com web e acabei me especializando em acessibilidade. Hoje trabalho na minha empresa, a Acesso para Todos, focando em acessibilidade digital.
________________________________________
[Sandy]
Oi, pessoal, tudo bom?
Eu sou a Sandyara, mais conhecida como Sandy. Sou uma mulher de pele clara, com cabelos na altura dos ombros, com mechas desbotadas na lateral direita. Tenho sardas abaixo dos olhos e hoje estou vestindo uma camiseta preta de gola alta, com um colar de estrelas colorido.
Eu sou especialista em design com foco em acessibilidade, já atuando em diversas empresas do setor privado. Hoje atuo especialmente no setor financeiro e bancário.
________________________________________
[Reinaldo]
Bom, hoje o episódio é para falar sobre formulários e entrada de dados. Formulários são fundamentais para a web, são essenciais.

A gente utiliza formulários para fazer cadastro, usar redes sociais, fazer compras e várias outras coisas. Só que esses formulários precisam ser acessíveis para que todo mundo consiga preencher e realizar ações de forma simples usando esses formulários. É sobre isso que a gente vai conversar no episódio de hoje.
Então, só para trazer um contexto rápido, imagine uma situação em que você precisa preencher um cadastro, fazer alguma compra e precisa preencher um campo. De repente, você entra em um campo de formulário e ele não tem rótulo. Você não sabe o que precisa preencher naquele campo.
Ou então você tem formulários muito complexos, que talvez não sejam fáceis de utilizar, que exigem o uso do mouse, ou ainda formulários com formatações específicas, que exigem um formato de dado diferente.
Talvez isso pareça algo muito simples, mas pode causar várias barreiras para pessoas com deficiência.
Então, a gente precisa pensar em formulários bem estruturados, com rótulos claros e bem definidos. É isso que vamos abordar neste episódio.
Então, eu queria começar conversando com a Cláudia sobre como a norma trata essa questão de formulários e entrada de dados.
________________________________________
[Cláudia]
Os formulários realmente são muito importantes. Quando a gente cria formulários de forma adequada, com campos para o usuário inserir informações de forma intuitiva e clara, a gente ajuda todo mundo a realizar as principais atividades na web.
E a norma trata isso com muito cuidado. Temos um bloco específico sobre formulários e entrada de dados, com diversas boas práticas, requisitos e recomendações. Falamos sobre rótulos descritivos, instruções para o preenchimento, retorno após envio, uso de botões de envio e mensagens de erro claras.
Tudo isso para que as pessoas consigam compreender, navegar com segurança e ter autonomia ao usar formulários na web.
________________________________________
[Sandy]
Eu acho que não me surpreenderia se esse fosse um dos episódios mais longos, porque o formulário é todo um ecossistema complexo. A gente está falando de interação, compreensão e feedback — tudo junto e misturado.
________________________________________
[Reinaldo]
Então, já pega um café, se prepara, porque esse episódio pode ser um pouco mais longo, mas é muito importante. Formulários são essenciais, principalmente para obter informações dos usuários.
O usuário cria login, coloca dados pessoais, então é importante que a gente trate isso muito bem.
Então, pega lá o seu café, já prepara as suas coisas para ficar um tempinho aqui com a gente.
Eu queria começar com uma primeira barreira: formulários sem rótulos. Qual é o impacto disso para acessibilidade?
________________________________________
[Cláudia]
Bom, um formulário sem rótulos é difícil para todo mundo. Se você vai navegar por um formulário e ele não tem rótulos, como é que você vai saber o que precisa preencher?
Todo mundo já passou pela experiência de preencher algum formulário e ficar na dúvida: “o que eu tenho que preencher aqui?”. Às vezes, ao se candidatar a um emprego ou ao solicitar um documento importante, como um visto, você fica pensando: “poxa, se eu errar essa informação, o que vai acontecer?”, né?
Então, os rótulos precisam existir, precisam ser visíveis e precisam ser claros para que todo mundo consiga compreender. Mas eles são fundamentais para quem não enxerga a tela. E a gente tem que construir isso de forma semântica, porque, se você tiver um formulário que não tem um rótulo claro, o leitor de telas, para uma pessoa cega, vai anunciar “campo de edição”, “campo de edição”, e a pessoa não tem ideia do que precisa preencher ali.
Então, isso pode ser uma barreira muito grande, e a pessoa pode não conseguir avançar no formulário nem preencher as informações.
________________________________________
[Sandy]
Quando a gente tem um formulário, vamos usar o exemplo de emprego que a Cláudia trouxe, de “nome” e “sobrenome”. Se eu não tenho esses labels, esses rótulos vinculados a um campo de edição, o leitor de tela simplesmente vai ler “campo de edição”.
Se eu faço uma navegação sequencial, depois eu vou ter o “sobrenome”. Mas o campo onde eu estava anteriormente era “nome”. Pera lá, então o que eu tenho que preencher aqui? Isso acaba gerando uma experiência confusa.
E, nesses casos, visualmente também pode causar confusão, principalmente se o rótulo não está posicionado no lugar esperado ou próximo daquele campo. Isso é comum em alguns lugares. Eu já tive o desprazer de presenciar colocarem o rótulo lá na esquerda e o campo de edição à direita, fazendo uma navegação em zigue-zague, basicamente.
Então, para você lembrar daquilo que precisa preencher, tinha que voltar até a esquerda — isso se você se lembrasse. E, se a gente pegar outras tecnologias, como, por exemplo, o zoom, a ampliação, isso tornava a experiência muito mais cansativa, porque eu focava no campo, depois tinha que ir para o rótulo, gerando uma carga cognitiva totalmente desnecessária.
________________________________________
[Reinaldo]
Acho que, até pensando em dispositivos móveis, você ter um formulário complexo como esse para preencher utilizando o teclado do celular é terrível, né? Sim.
E aí, então, tecnicamente, o que a gente precisa fazer para que esses formulários sejam acessíveis?
________________________________________
[Cláudia]
A gente tem que colocar rótulos. Os rótulos, de preferência, precisam estar visíveis e posicionados de uma maneira previsível. Normalmente, a gente coloca os rótulos logo acima do campo ou logo à esquerda, mas nunca com um espaçamento muito grande, porque senão a pessoa não vai identificar.
Além disso, eles precisam estar vinculados aos campos de forma semântica, para que todo mundo consiga identificar, mesmo quem não está enxergando a tela. A gente faz isso no HTML com o elemento “label”. Então, temos aquele “label for”, que a gente utiliza como rótulo.
Ele aparece visualmente e, ao mesmo tempo, está vinculado ao campo. Quando uma pessoa que não enxerga a tela está usando um leitor de tela e foca em um campo de formulário, o leitor automaticamente lê aquele rótulo para ela. Assim, a pessoa sabe o que precisa preencher.
________________________________________
[Reinaldo]
E você acha que dá para utilizar outros recursos, por exemplo, um “aria-label” ou até outros atributos? Eu já vi algumas recomendações falando até de utilizar o “title”, mas o atributo “title” talvez não seja tão adequado nesse caso, né?
________________________________________
[Cláudia]
Também dá para usar o “aria-label”, mas a gente tem que lembrar que a especificação ARIA é exclusiva para a compreensão das tecnologias assistivas. Então, se a gente usa ARIA, quem vai receber essa informação é só quem usa essas tecnologias. Uma pessoa que não usa não vai receber essa informação.
Por isso, é sempre mais adequado utilizar um rótulo visível, para quem enxerga também. Se você quiser usar o “aria-label”, é importante garantir que esse rótulo também esteja visível e seja facilmente localizável.
________________________________________
[Sandy]
Acho que o maior desafio, quando a gente fala de formulários, é provocar uma experiência minimamente equivalente, que funcione bem tanto para quem enxerga quanto para quem ouve.

________________________________________
[Reinaldo]
Ou seja, mais um exemplo sobre usar a semântica adequada do HTML para garantir acessibilidade. Indo para uma outra barreira, não relacionada à questão técnica, mas à descrição dos campos de formulário, especialmente quando são muito vagas.
Então, não é simplesmente escrever um rótulo; a gente precisa fornecer informações adequadas para que o usuário consiga preencher o formulário. O que vocês têm para falar sobre essa barreira?
________________________________________
[Cláudia]
É, isso é muito importante. Colocar rótulos muito vagos traz essa dúvida sobre o que o usuário precisa preencher. Ele fica nessa incerteza, o que gera angústia e uma situação de desconforto. Talvez ele não consiga preencher de forma correta, né?
Então, é muito importante a gente usar rótulos descritivos e, quando possível, também fornecer textos de ajuda para que o usuário saiba o que precisa preencher e como deve preencher. E esses textos de ajuda também precisam estar posicionados próximos ao campo, para que a pessoa consiga identificar a qual campo aquele texto se refere.
________________________________________
[Sandy]
Vou seguir com o exemplo de candidatura que a gente comentou um pouco antes, como um campo de endereço. “Endereço” pode significar muita coisa: você quer o logradouro, quer o CEP? Afinal, o que exatamente deve ser preenchido?
Então, ter a orientação correta — se é logradouro, número ou tudo isso junto — ajuda a orientar a pessoa usuária. E os textos de ajuda são sempre bem-vindos, principalmente quando é para destacar essas especificidades. Por exemplo, no campo “estado”, é com ou sem abreviação? Nesse sentido.
E, claro, os textos de ajuda precisam estar vinculados corretamente aos campos, para não dar a impressão de que estão soltos e também para garantir que não apareçam em uma ordem fora do esperado.
________________________________________
[Reinaldo]
Ah, legal. Então, pelo que dá para entender, um bom texto, um bom rótulo, precisa ser bem descritivo. Você comentou sobre o endereço, sobre CEP, e acho que também é importante oferecer orientações sobre que tipo de dado pode ser utilizado nesse campo.
Por exemplo, o campo vai exigir somente números ou somente texto? Acho que existe uma questão importante sobre o que a gente vai exigir que o usuário insira neste campo.
________________________________________
[Sandy]
Um exemplo disso é o CPF. Tem gente que coloca só números, tem gente que coloca números com pontos e traços. Então, qual é a forma esperada para que o usuário consiga acertar logo de primeira, vamos dizer assim, e que a experiência seja menos frustrante?

________________________________________
[Reinaldo]
Bom, então, passando para uma próxima barreira, eu queria falar um pouco sobre agrupamento de campos de formulário. É muito comum a gente navegar por formulários extensos, um pouco mais longos, que têm blocos de informações que precisam ser preenchidos.
Só que, se esses campos não estão relacionados de forma adequada, isso pode se tornar uma barreira para pessoas com deficiência, principalmente para usuários de leitores de tela. Eu queria que vocês comentassem um pouquinho sobre essa questão, essa barreira.
________________________________________
[Cláudia]
Sim, visualmente falando, quando os campos estão agrupados, a gente consegue perceber isso de forma fácil, mas quem não enxerga a tela vai ter dificuldade, né? Em entender quais campos estão realmente agrupados, relacionados entre si ou fazem parte de um contexto específico.
Então, quando a gente tem campos relacionados, precisamos agrupá-los visualmente, mas também semanticamente. A gente faz isso com o elemento “fieldset” no HTML. Quando agrupamos campos dentro de um “fieldset”, eles ficam relacionados.
Por exemplo, se eu tenho campos para preencher dados pessoais — como nome, e-mail e endereço — ou dados de pagamento — como nome, cartão de crédito e bandeira —, a gente pode agrupar tudo isso dentro de um “fieldset”. E o “fieldset” vem com uma duplinha chamada “legend”, que funciona como um rótulo daquele agrupamento, um título.
Quando a gente define isso, por exemplo, como “dados pessoais”, conseguimos entender melhor o que representa aquele conjunto de campos. Assim, fica mais fácil tanto para quem enxerga quanto para quem navega com uma tecnologia assistiva.
________________________________________
[Sandy]
Eu tenho um exemplo de algo com que me deparei não tão recentemente, em um site que estava promovendo um evento. À esquerda, lembro bem que havia um formulário para fazer login no site e, do lado direito, havia outro formulário para fazer a inscrição nesse evento. E, por incrível que pareça, era o mesmo formulário.
Eles não estavam agrupados como dois formulários distintos. Até eu entender isso, fiquei refletindo depois: poxa, se eu não enxergasse e não percebesse que eles estavam separados visualmente, poderia entender que, para participar desse evento, eu teria que ter um login, fazer login, estar cadastrado naquela plataforma.
Isso pode acabar gerando a perda de um potencial usuário, de um potencial cliente. Foi bizarro.
________________________________________
[Reinaldo]E isso que a Cláudia comentou sobre a possibilidade de agrupar tecnicamente eu acho muito legal, porque, se alguém quiser fazer um teste utilizando esses elementos que ela mencionou, é bem interessante. Quando você navega com um leitor de tela e chega no primeiro campo, ele já lê “grupo: dados pessoais”, “campo: nome”. Ou seja, ele apresenta toda a informação de uma vez, o que facilita para o usuário entender, logo de cara, qual dado precisa preencher.
Eu acho isso muito legal e um teste interessante de fazer, justamente para entender o quanto esse agrupamento de campos de formulário é importante. São recursos da tecnologia que fazem uma diferença enorme no dia a dia das pessoas com deficiência.
E, sobre uma outra barreira que eu queria tratar aqui, é a finalidade de entrada desses campos de dados. Então, além de ter esse rótulo relacionado com o campo, como a gente comentou, o que mais a gente pode fazer para melhorar a experiência do usuário que vai preencher um formulário na web?
________________________________________
[Cláudia]
O que a gente pode fazer é identificar o tipo de dado esperado nos campos de formulário. Por exemplo, se você tem um campo para preencher números, pode indicar que apenas números devem ser inseridos ali. Essa é uma informação importante para a própria tecnologia.
No HTML, a gente tem um atributo chamado “autocomplete”, que traz justamente essa informação sobre o tipo de dado que deve ser inserido em cada campo. Quando você informa para a tecnologia que, em um determinado campo, deve ser preenchido um número — e de forma específica, como o “cc-number”, para cartão de crédito —, ela consegue entender exatamente o que deve ser inserido ali.
E o que acontece? Primeiro, se eu já preenchi esse número anteriormente, a tecnologia consegue reconhecer e sugerir essa informação, quase como um preenchimento automático, para que eu não precise digitar tudo novamente — posso apenas selecionar, e o campo é preenchido automaticamente.
Além disso, pode haver uma mudança na forma de entrada. Por exemplo, em dispositivos móveis, o teclado pode ser ajustado: em vez de um teclado padrão, pode aparecer diretamente o teclado numérico. Assim, a pessoa evita o esforço de ter que trocar manualmente o tipo de teclado.
Para quem tem dificuldade com digitação, isso ajuda bastante, porque já facilita o preenchimento. No caso de um e-mail, por exemplo, o teclado pode trazer atalhos como “.com” e o símbolo de arroba (@). Tudo isso facilita na hora de digitar.
Então, identificar corretamente o tipo de entrada de dados é muito importante para acessibilidade.
________________________________________
[Reinaldo]
É um baita ganho de usabilidade, né?

________________________________________
[Sandy]
Total. O tanto que eu já me estressei para colocar o número de celular, e o campo me trazia o teclado completo, com “Q, W”, essas coisas, com todas as letras e números, e eu ainda tinha que ir naquela opçãozinha para mudar para o teclado numérico, sem nenhuma necessidade.
E olha que, apesar de eu ter mobilidade reduzida, não é nos membros superiores. Imagina para quem tem nos membros superiores.
________________________________________
[Reinaldo]
E eu queria até trazer um outro ponto. A Cláudia comentou sobre o “autocomplete”, mas existe um atributo que também é utilizado para adicionar informações complementares e que eu já vi muita gente usando como rótulo, que é o “placeholder”.
O “placeholder” é aquele textinho em cinza que aparece no campo de formulário e, quando você interage com o campo, ele some. Ele é um texto complementar, mas muita gente acaba usando isso como rótulo, abandonando o uso dos rótulos e utilizando o “placeholder” como se fosse o rótulo do campo de formulário.
E, na verdade, não é para isso, né, Clau?
________________________________________
[Cláudia]
Não, isso não é uma boa prática. O “placeholder” não é indicado para acessibilidade. Primeiro, porque ele já vem, por padrão, com uma fonte bem clarinha. Então, pessoas com baixa visão, por exemplo, podem não conseguir enxergar aquele texto direito.
Além disso, tem a questão que você comentou: a pessoa clica no campo para digitar e o texto desaparece. Isso, para pessoas com deficiência cognitiva, pode ser bem confuso. Algumas podem até achar que aquele campo já está preenchido.
Então, assim, a norma até traz que, em casos de campos de formulário muito óbvios, visualmente falando, a gente pode ocultar o rótulo. É uma opção. Por exemplo, um campo de busca: ele é claro para todo mundo, geralmente vem com um ícone de lupa, então as pessoas já entendem que aquilo é um campo de busca.
Mas, mesmo nesses casos, não dá para confiar só no “placeholder”. A gente precisa adicionar um rótulo, como um “aria-label”, para indicar “pesquisar no site”, “pesquisar notícias”, ou algo nesse sentido, garantindo que todo mundo receba essa informação.
O “placeholder” é um complemento, na verdade. Ele funciona apenas como um exemplo do que pode ser preenchido. Então, em uma barra de pesquisa, você pode colocar algo como “pesquisar por notícias” ou “pesquisar por últimas tendências”.
________________________________________
[Sandy]
Eu tive um caso — gente, eu me lembro disso desde que eu era criança. Sabe aqueles concursos de “o que você faria se você ganhasse”? Eu lembro de me inscrever em um desses quando era pequena, e o campo tinha “placeholder”, e eu esquecia toda hora qual era a pergunta.
Então, eu tinha que apagar a minha mensagem para o “placeholder” aparecer de novo, e aí voltar para escrever. Horrível!
________________________________________
[Reinaldo]
É quase uma Olimpíada, né? É um teste de memória, né?
Bom, passando para uma outra barreira, eu queria falar um pouco sobre mensagens de erro e as barreiras de acessibilidade relacionadas a elas. As mensagens de erro estão presentes, fazem parte dos formulários. Às vezes, indicam que um campo não foi preenchido corretamente ou que você esqueceu de preencher um campo obrigatório.
Só que isso precisa ser apresentado também para usuários com deficiência. É muito comum a gente se deparar com mensagens de erro em que aparece apenas um botãozinho “X”, e a pessoa não sabe o que precisa fazer nem o que precisa preencher. Surge uma modal com um “X” para fechar, mas sem explicação, e a pessoa acaba tendo que voltar em todos os campos para descobrir o problema.
Eu queria que vocês comentassem um pouco sobre as mensagens de erro: o que dá para fazer para torná-las mais acessíveis, considerando que elas são fundamentais para a acessibilidade?
________________________________________
[Cláudia]
Bom, primeiro, a gente precisa evitar mensagens de erro muito genéricas. Se você coloca algo como “corrija os erros para prosseguir”, a pessoa não vai ter ideia de quais erros existem, quais erros ela cometeu e nem como corrigi-los.
Além disso, também precisamos tomar cuidado com o local onde esse erro aparece, porque ele pode surgir em um ponto em que a pessoa não consegue identificar qual campo está com problema.
Então, tem uma série de questões que a gente pode abordar sobre mensagens de erro para torná-las mais acessíveis, mas eu queria ouvir um pouquinho da Sandy também.
________________________________________
[Sandy]
Acho que, quando a gente fala de erro, é uma situação muito sensível, porque pode ser ali que a gente perca um potencial cliente e gere uma frustração totalmente desnecessária.
Então, é nesse momento que precisamos trabalhar com vários recursos, como cores e elementos iconográficos, além de garantir que a mensagem de erro apareça em um local adequado. Em alguns casos, ela pode estar vinculada diretamente ao campo, para facilitar a navegação com leitores de tela.
Ou seja, é importante trabalhar com uma série de mecanismos de forma simultânea, para que fique claro para a pessoa usuária o que precisa ser corrigido, por que aquilo é um erro e o que ela deve fazer para conseguir prosseguir na jornada.
________________________________________
[Reinaldo]
E como a gente deve fazer para tornar essas mensagens mais acessíveis para o usuário?
________________________________________
[Cláudia]
Bom, então a gente precisa especificar exatamente qual é o erro, e isso deve estar em formato de texto. Como vocês dois já falaram, se o retorno for apenas visual, por meio de um ícone ou de uma borda vermelha no campo com erro, nem todo mundo vai conseguir perceber que existe um problema ali.
Uma pessoa que não enxerga a tela ou uma pessoa daltônica, com deficiência cromática, por exemplo, pode não identificar esse erro. Então, a primeira coisa é: a gente precisa informar o erro em texto.
Além disso, é importante ser o mais específico possível. Vamos pegar um exemplo: se temos um formulário e a pessoa digitou o nome de uma cidade errado, e a tecnologia detectou que é um erro de ortografia, a mensagem pode ser algo como: “Esse nome de cidade não existe. Verifique a ortografia.”
Outra coisa muito importante, quando possível, é sugerir como corrigir esses erros. Nesse caso da cidade, por exemplo, se a tecnologia identificar um erro de ortografia, o campo pode trazer uma lista com nomes de cidades semelhantes ao que foi digitado, para que a pessoa apenas selecione e o valor correto já seja preenchido automaticamente.
Então, sempre que possível, a gente também deve sugerir como corrigir os erros.
________________________________________
[Sandy]
Eu acho que também vale a pena destacar que, na experiência não visual, principalmente com leitor de tela, pode ser muito cansativo ter que procurar qual é o campo que está com erro e o que precisa ser preenchido.
Então, veja se, no contexto, vale a pena atrelar a mensagem de erro ao campo que a pessoa precisa corrigir, por exemplo, usando um “aria-describedby”, já com a instrução necessária.
A ideia é minimizar o esforço do usuário para encontrar essas mensagens de erro.
________________________________________
[Reinaldo]
Uma coisa que eu queria comentar sobre esse ponto, e que eu percebo ser muito comum — principalmente em modais, onde aparecem mensagens de erro, mas também em outros tipos de modais — é a questão dos botões, como o botão de “fechar”. Em alguns casos, o rótulo está em inglês ou o botão aparece apenas como “botão”, porque esse rótulo não foi definido corretamente.
Muitas vezes isso acontece porque o componente veio de alguma biblioteca e não foi verificado o atributo específico para garantir a acessibilidade. Então, é importante ter esse cuidado também com os elementos da interface dentro das mensagens de erro.
Indo para outra barreira agora, que é sobre formulários sem a possibilidade de reverter uma ação: são aqueles formulários longos ou com múltiplas etapas, em que precisamos preencher vários dados. Às vezes você avança para uma etapa seguinte e precisa voltar para corrigir alguma informação, ou então são formulários que têm um tempo limitado para preenchimento e você pode acabar perdendo o conteúdo inserido.
Isso é muito delicado para pessoas com deficiência, porque envolve também o esforço necessário para preencher esses formulários. O que vocês recomendam sobre esse tipo de situação?
________________________________________
[Cláudia]
Eu não, né? A norma ABNT!
A norma ABNT 17225 traz exatamente essa questão, porque é fundamental permitir que as pessoas consigam visualizar o que estão enviando, para confirmar os dados e garantir que tudo seja submetido corretamente.
Então, qual é a recomendação? Que a gente permita que as pessoas revisem os dados que preencheram no formulário. Se perceberem algum erro, elas devem poder voltar, corrigir e, depois, confirmar essas informações antes de finalizar o envio.
Isso é especialmente importante em formulários críticos. E o que são formulários críticos? São aqueles que envolvem, por exemplo, transações financeiras, envio de dados sensíveis ou situações com responsabilidade jurídica, como a assinatura de um contrato.
Nesses casos, essa possibilidade de revisão e confirmação é ainda mais importante. Mas, de forma geral, o ideal é sempre permitir que as pessoas revisem os dados, façam correções quando necessário e confirmem tudo antes do envio, reduzindo a chance de erros.
________________________________________
[Sandy]
Eu estou rindo aqui por dentro, porque tenho um outro exemplo — esse é da semana passada, aconteceu comigo. Fui comprar uma cadeira nova para o meu escritório, me mudei de casa recentemente, e as informações do site onde eu já tinha comprado antes vieram todas pré-preenchidas.
Mas olha que interessante: os formulários de dados pessoais, dados de pagamento e endereço estavam agrupados em “accordions”, que eram recolhíveis. E, como veio tudo pré-preenchido, o “accordion” já estava recolhido e com os dados mascarados.
O último botão era “realizar pagamento”. E eu pensei: “Ah, já comprei aqui antes, chegou tudo certo, né?”. Imaginei que, ao finalizar o pagamento, eu teria a chance de revisar as informações, como o endereço e o cartão de crédito.
Pasmem: o endereço não estava atualizado. Não houve uma etapa de revisão. De fato, foram descontados R$1.000,00 da minha conta e eu não tive a oportunidade de revisar, até porque aparecia só uma prévia no “accordion”, com o endereço mascarado.
Eu não me mudei de cidade, então, para mim, aquilo não parecia fazer diferença, mesmo mascarado. No fim, deu tudo certo — entrei em contato com o SAC —, mas essa etapa de revisão é muito importante. Só isso já foi suficiente para me gerar uma crise de ansiedade, por exemplo.
________________________________________
[Reinaldo]
Tem uma técnica também, e eu gosto sempre de trazer esse exemplo, que é um recurso interessante relacionado aos botões no HTML. Porque, a princípio, um botão deve executar a ação quando você solta o dedo ou o mouse.
Eu sempre dou o exemplo de quando você vai mandar aquele e-mail para o chefe, aquele e-mail cabeludo, cheio de informações delicadas. Você escreve, revisa… comigo isso acontece com frequência. Aí eu vou lá, pressiono o botão “enviar” e penso: “espera, deixa eu dar mais uma olhadinha antes”.
Então, se eu percebo que preciso ajustar algo, simplesmente arrasto o dedo ou o mouse para fora do botão, e o e-mail não é enviado. Isso acontece porque o envio só é confirmado na ação de soltar o botão.
Uma das recomendações, que inclusive está na norma, é manter esse comportamento. Isso já é nativo do HTML — se a gente não mexer, tudo funciona bem. Mas é comum ver mudanças nesse comportamento, como executar a ação já no momento em que o botão é pressionado, e isso pode ser um problema.
Então, esse é um recurso que eu gosto de comentar porque, na prática, a gente não precisa fazer nada — só precisa tomar cuidado para não alterar esse padrão e acabar fazendo com que a ação seja executada imediatamente ao pressionar. Caso contrário, o e-mail vai para o chefe de qualquer jeito.
________________________________________
[Cláudia]
Isso é muito importante: deixar sempre o controle nas mãos do usuário e evitar que as coisas aconteçam de forma inesperada, como mudanças na tela ou nas funcionalidades sem que ele tenha controle.
Esse cuidado é fundamental para a acessibilidade.
________________________________________
[Reinaldo]
E isso de funcionalidades me fez lembrar de outra questão: muitas vezes, o ideal é deixar tudo o mais simples possível e usar a própria semântica do HTML para isso.
Lembrei disso porque passei por uma situação ao preencher formulários em que, obrigatoriamente, eu precisava usar um “picker” de data para selecionar datas. E aí o que acontece? Bom, pela minha barba branca, vocês já sabem que eu preciso voltar alguns bons anos para selecionar a data. Ou seja, a escolha dependia de muitos cliques.
Mas, se aquele campo permitisse que eu digitasse a data, já resolveria para mim. Eu não precisaria ter todo esse trabalho de ficar voltando ano a ano para conseguir preencher.
Então, acho que entra novamente aquilo que a gente vem falando: usar a boa e velha semântica base do HTML e dar essa opção para o usuário, mantendo o controle nas mãos dele. A semântica básica do HTML já permite muita coisa que a gente nem precisaria alterar, mas, ainda assim, a gente vai lá e modifica.
________________________________________
[Cláudia]
Exatamente.


________________________________________
[Sandy]
Eu acho que o uso correto da semântica, aplicado com diferentes alternativas, faz muita diferença. No caso do e-mail, por exemplo, além do comportamento do botão, ter uma etapa de revisão também ajuda.
Eu gosto muito de alguns serviços de e-mail que oferecem a opção de desfazer. Quando você envia uma mensagem, aparece um “snackbar” no canto da tela dizendo “foi enviado, você quer desfazer?”.
Acho que quanto mais opções desse tipo, melhor, porque pode ser que, naquele milissegundo, o usuário sinta alguma insegurança, e ter um recurso assim pode ajudar bastante.
________________________________________
[Cláudia]
Essa questão do botão de envio é muito importante, inclusive é uma das recomendações da norma. O botão de envio é essencial nos formulários, porque, quando ele não existe, as pessoas podem não saber como finalizar o preenchimento ou como enviar as informações.
Então, sempre que possível, é importante manter o botão de envio — o “submit” no HTML — para que o usuário tenha esse controle: “terminei o que estou fazendo, agora vou clicar em ‘enviar’ e pronto”.
Hoje, existem muitas funcionalidades, e é muito comum ver isso em lojas, por exemplo, em que você vai aplicando filtros e a página muda automaticamente. Isso pode ser um problema, porque as pessoas podem não perceber essas mudanças, especialmente se estiverem com a tela ampliada ou utilizando tecnologias assistivas.
Por isso, o ideal é que o usuário selecione os filtros que deseja, clique em “aplicar filtros” e só então a página seja atualizada. Assim, ele mantém o controle — inclusive para revisar ou remover filtros aplicados.
Então, deixar o controle sempre nas mãos do usuário é algo muito importante.
________________________________________
[Reinaldo]
Bom, e a próxima barreira — a gente já falou um pouquinho sobre instruções de campos de formulário —, mas eu queria olhar com vocês o que mais a gente pode fazer para orientar os usuários e eliminar barreiras no preenchimento, principalmente em formulários mais complexos.

________________________________________
[Cláudia]
A gente falou bastante sobre mensagens de erro, que são um retorno do que está sendo preenchido, e é muito importante também oferecer instruções claras de como preencher, uma ajuda contextual para que o usuário saiba exatamente o que precisa inserir em cada campo.
E, como a Sandy já comentou, é essencial vincular essas instruções aos campos de formulário, para que todo mundo receba essa informação de forma completa.
Outra coisa muito importante é evitar que as pessoas tenham que preencher dados de forma repetida. Isso acontece bastante em formulários com várias etapas, em que você já preencheu uma informação lá atrás e, de repente, o sistema pede novamente.
A norma traz essa preocupação justamente para ajudar pessoas que têm dificuldades com digitação, evitando que precisem repetir informações. Então, a gente deve reduzir isso ao máximo, oferecendo mecanismos que permitam, por exemplo, selecionar dados já preenchidos automaticamente.
Como a gente comentou sobre o “autocomplete”: se a pessoa já inseriu um dado anteriormente, ela pode apenas selecionar e o campo é preenchido automaticamente. Ou ainda permitir o preenchimento automático de informações.
Um exemplo bem comum em lojas virtuais é aquela opção “o endereço de cobrança é o mesmo de entrega”. Ao marcar um checkbox, os dados já são preenchidos automaticamente.
Evitar que as pessoas precisem preencher informações repetidamente ajuda quem tem dificuldades físicas, motoras e também cognitivas, já que a pessoa pode não lembrar exatamente como preencheu uma informação antes. Então, isso também é bem importante.
________________________________________
[Reinaldo]
E uma outra barreira que eu queria trazer aqui é a exigência de percepção ou de alguma capacidade específica do usuário.
Aqui a gente pode listar vários exemplos, desde o CAPTCHA, que exige uma percepção visual ou auditiva, até componentes que só funcionam por meio do mouse, em que você só consegue selecionar um item dessa forma.
Eu até dei o exemplo anterior do “picker” de data, em que eu precisava selecionar tudo usando o mouse.
Eu queria que vocês comentassem um pouco sobre o impacto disso na acessibilidade. Como as pessoas com deficiência são impactadas por esse tipo de barreira?
________________________________________
[Sandy]
Cláudia, se me permite fazer um pequeno manifesto: se eu pudesse me declarar a “hater” número um desses tipos de testes… desde os mais simples, como já vi em alguns sites, que pedem uma soma, uma equação matemática, até aqueles de identificar imagens ou ler algum texto.
Eu já vi até alguns em formato de quebra-cabeça, em que você precisa arrastar a peça para encaixar em uma imagem específica. Gente, isso é péssimo. Eu sinto que gera mais barreiras do que realmente facilita o acesso.
A gente entende o propósito por trás, mas temos falado muito neste episódio sobre a importância de oferecer alternativas. Quando a gente fala, por exemplo, de cálculo matemático, existem pessoas com discalculia — ou até alguém que está com uma simples dor de cabeça e não quer fazer uma conta de 11 + 9, e está tudo bem.
E, quando falamos desses recursos muito visuais, qual é a alternativa auditiva? Muitas vezes, ela nem existe.
Então, acho que a Cláudia pode comentar sobre como trazer outros recursos e alternativas a esses mecanismos, que acabam muito mais excluindo do que, de fato, incluindo, né?
________________________________________
[Cláudia]
Você falou uma palavrinha-chave para acessibilidade, que é oferecer alternativas. Porque, quando a gente exige que o usuário realize uma ação que depende de uma capacidade motora específica ou de uma percepção sensorial específica, a gente acaba excluindo pessoas — já que nem todo mundo consegue fazer aquilo.
Hoje, é muito comum encontrarmos testes mais difíceis de realizar. Por exemplo, aquelas senhas em que você precisa desenhar um caminho ou memorizar um padrão visual e reproduzi-lo depois. Quando a gente faz isso, como uma pessoa que não enxerga esse padrão visual vai conseguir passar por essa funcionalidade? Ou alguém que não tem destreza suficiente nas mãos para arrastar elementos na tela e conectar pontos?
Então, a recomendação é oferecer alternativas. Hoje, existem muitas opções mais acessíveis, que evitam esse tipo de esforço desnecessário, como a Sandy comentou.
Um exemplo é o envio de um link por e-mail, para que a pessoa clique e valide a própria identidade. Dessa forma, ela não precisa passar por um processo complicado, que exige uma capacidade específica, apenas para conseguir fazer login, por exemplo.
Ou seja, existem formas alternativas de resolver isso de maneira mais acessível.
________________________________________
[Reinaldo]
Eu ia até comentar também sobre o arrastar e soltar. E a ideia, como vocês pontuaram muito bem, não é proibir esse tipo de recurso, mas oferecer alternativas.
Então, se existe alguma funcionalidade que depende de arrastar e soltar, é importante ter uma outra forma de interação, que permita, por exemplo, que o usuário apenas toque no início e no final, ou algo nesse sentido.
Porque pode ser que o usuário simplesmente não consiga realizar esse movimento, seja por limitações motoras, fraqueza, dor ou uma série de outros fatores.
________________________________________
[Cláudia]
Ou ainda uma pessoa que navega por comandos de voz — como ela faria para arrastar um objeto na tela?

________________________________________
[Reinaldo]
Exatamente. E, trazendo ainda a questão do comando de voz, Clau, isso me lembrou de um ponto que muitas vezes a gente não aborda, que é a deficiência de fala.
Hoje temos assistentes pessoais que funcionam por comandos de voz. Mas, se em algum momento você estiver com a voz rouca — como a gente, depois de passar o dia inteiro gravando —, pode ser que o assistente nem reconheça o comando.
E existem pessoas que têm um volume de voz muito baixo ou até ausência de voz. Então, não se trata de eliminar esse tipo de recurso, mas de permitir que a pessoa consiga executar esses comandos por outros meios, como uma interface no celular, em uma página ou em outro tipo de interação.
________________________________________
[Cláudia]
Exatamente. Alternativas. Essa é a palavrinha.

________________________________________
[Reinaldo]
Bom, gente, estamos chegando ao final deste episódio. E, só para fazer uma rápida recapitulação de tudo o que a gente falou — e de uma forma muito leve, o que acho bem interessante —, abordamos temas tecnicamente mais complexos, mas de maneira acessível.
Falamos sobre a importância dos rótulos, não só do ponto de vista técnico, mas também de escrever rótulos claros, com textos fáceis de compreender, trazendo informações adequadas sobre o que o usuário precisa preencher. São vários pontos que nos levam a uma ideia central: a gente precisa sempre pensar no usuário.
O preenchimento de formulários precisa ser fácil. Esse é um momento em que, como a Sandy comentou, a gente pode perder um usuário simplesmente porque ele não consegue preencher um campo.
Então, minha mensagem final neste episódio é: vamos usar essas boas práticas para tornar os formulários mais simples para as pessoas que navegam.
E eu queria pedir uma mensagem final de vocês antes de a gente encerrar.
________________________________________
[Cláudia]
Bom, eu gostaria de dizer que, para nós, que não temos deficiência, existem coisas que parecem muito simples. Você escolhe um produto, coloca no carrinho… se eu preciso de um remédio e quero facilitar a minha vida, eu faço isso online: escolho o produto, coloco no carrinho e finalizo a compra.
Mas, para outra pessoa, todo esse processo pode ser muito difícil, e ela pode não conseguir finalizar a compra porque não encontrou, por exemplo, a forma de pagamento.
Os formulários são muito importantes e, hoje, com a vida cada vez mais digital, se tornam ainda mais essenciais. Oferecer esse recurso de forma acessível para pessoas com deficiência permite, por exemplo, que elas não precisem sair de casa para ir até uma farmácia e consigam comprar esse produto online.
Então, os cuidados com formulários estão entre os pontos mais críticos e importantes quando falamos de acessibilidade.
________________________________________
[Sandy]
Acho que a palavra-chave que resume este episódio é “alternativa”. Como a Clau comentou, se para você preencher um formulário — seja de compra ou de cadastro — já pode ser difícil mesmo sem ter uma deficiência, para mim, que tenho alguma deficiência, pode ser totalmente impossível, me excluindo desse processo.
Então, sempre que for construir um formulário, pense em alternativas. Alternativas ao indicar uma mensagem de erro: usar cor, ícone e texto. Alternativas ao aplicar algum tipo de verificação: oferecer autenticação em dois fatores, envio de link por e-mail.
Ou seja, nunca pensar em apenas uma forma. E, se mesmo assim ainda houver dúvidas, consulte o usuário.
________________________________________
[Reinaldo]
Perfeito! Muito obrigado, gente! Então, chegamos ao final de mais um episódio do podcast Todos na Web. Espero vocês no próximo episódio. Até breve!