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

[Reinaldo]
Olá, pessoal! Eu sou o Reinaldo Ferraz, especialista em acessibilidade digital do Ceweb.br. Sou um homem branco, de cabelo castanho claro, liso, com uma barba cerrada, quase branquinha já, e estou usando uma camisa preta com o logo do Ceweb.
O meu sinal em Libras é a mão em formato de “C”. Eu toco os dedos no meu rosto e faço o movimento de descer da orelha até o queixo, acompanhando o desenho da barba.
Hoje eu vou conversar com dois especialistas em acessibilidade digital, a Cláudia e o Sidney. São duas pessoas que participaram de forma muito ativa na construção da norma e têm um conhecimento enorme sobre acessibilidade.
Primeiro, obrigado por estarem aqui, participando desta série de podcasts com a gente. Eu gostaria que vocês se apresentassem para a audiência.
________________________________________
[Cláudia]
Olá! Eu que agradeço, é muito bom estar aqui.
Eu sou uma mulher branca, de pele clara, com cabelos castanhos escuros na altura dos ombros. Tenho olhos castanhos escuros, uso óculos e estou vestindo uma malha preta, um casaquinho cinza e um colarzinho de pedrinhas coloridas.
Sou designer por formação. Trabalho com web desde o início da minha carreira e com acessibilidade há mais ou menos 13 anos. Hoje, esse é o meu foco de trabalho: acessibilidade digital na empresa Acesso para Todos.
________________________________________
[Sidney]
Olá, pessoas! Eu sou o Sidney Tobias. Sou um homem de cabelos e olhos castanhos, nariz núbio, lábios médios, e o meu sinal em Libras é este. Vou descrevê-lo.
É um soquinho para cima, com o polegar entre o dedo médio e o indicador. Depois, esse é o “S” em Libras; daí, o “Y” em Libras, que é o polegar para cima e também o dedo mínimo para cima. E daí eu subo a mão. É isso.
Sou analista de sistemas da Prodam e consultor de acessibilidade digital e comunicacional na Secretaria Municipal da Pessoa com Deficiência aqui da cidade de São Paulo, a SMPED.
________________________________________
[Reinaldo]
Maravilha! Obrigado por vocês estarem aqui. Hoje a gente vai falar sobre botões e controles.
Os botões e controles que a gente utiliza na web precisam ser acessíveis para que as pessoas consigam operar uma interface e consigam preencher um campo de formulário. Então, tudo isso é muito importante para garantir acessibilidade, para que todas as pessoas consigam utilizar. É isso que a gente vai conversar aqui no episódio de hoje.
Fazendo uma abertura rápida e contextualizando um pouco essa questão dos botões, acho que a pandemia deixou muito clara a importância da web, a importância de aplicações acessíveis. Mas eu vi muitos relatos de pessoas que tiveram problemas, principalmente para operar algumas interfaces.
Alguns sites e aplicações em que as pessoas iam comprar alguma coisa e, na hora de concluir o seu pedido, a sua compra, o botão não tinha rótulo, não estava definido de forma correta. A pessoa não sabia o que aquele botão fazia. Será que eu vou concluir a minha compra? Será que eu vou cancelar a minha compra? O que é que eu tenho que fazer com esse botão?
Então, especialmente para quem utiliza um leitor de tela, não ter uma referência do que o botão significa, não ter uma orientação adequada sobre qual é a função daquele botão, eu acho que isso é muito delicado.
Então, a gente vai abordar diversos aspectos relacionados a botões que a norma da ABNT contempla. E, até entrando nessa linha, Cláudia, queria perguntar um pouco para você sobre essa questão do uso de botões na norma da ABNT. Como ela, a norma, contempla essa questão?
________________________________________
[Cláudia]
Sim, realmente, quando botões e controles são criados de forma incorreta, isso pode impedir o acesso das pessoas com deficiência. Pode fazer com que as pessoas não consigam usar uma aplicação, não consigam preencher formulários ou não consigam prosseguir em um curso. Então, é muito importante.
Ao contrário, quando eles são criados de forma correta, isso permite que todo mundo consiga navegar e interagir com esses controles de forma clara, com segurança e com autonomia. Saber onde estão para dar um clique é muito importante.
Então, isso vale independentemente das capacidades que a pessoa tenha, esteja ela enxergando a tela ou não, usando ou não algum recurso específico de tecnologia assistiva.
Então, a norma ABNT 17225 traz requisitos e recomendações para o uso correto dos botões e controles, seja por meio de uma semântica adequada, de rótulos descritivos consistentes ou de uma área de clique suficiente, que também seja confortável para as pessoas.
Isso ajuda a garantir que elas consigam clicar sem atingir lugares errados, evitando ações acidentais. Tudo isso contribui para trazer mais autonomia e segurança na navegação.
________________________________________
[Sidney]
A gente utiliza, por exemplo, teclas de atalho para identificar os botões. Então, a tecla “B” navega entre eles.
Por isso, é importante que esses botões estejam, de fato, rotulados e que a gente tenha clareza sobre qual é a ação que será executada ao pressioná-los.
Quando um botão não está identificado corretamente, você fica na dúvida: “O que é isso? Para que serve esse botão?”. E acaba tendo que usar a seta direcional para subir ou descer e entender o contexto.
Com isso, a gente vai perdendo tempo. Por isso, é fundamental que os botões estejam bem identificados e rotulados, para facilitar a navegação de quem utiliza um software leitor de tela.
________________________________________
[Reinaldo]
Legal! E, começando a falar um pouco sobre algumas barreiras de acesso relacionadas à questão de botões, uma delas que eu queria trazer para a gente discutir é o uso incorreto da semântica na criação de botões.
Hoje em dia, é muito comum encontrar botões que não são marcados como botões e, muitas vezes, utilizam elementos genéricos do HTML, como “span” ou “div”.
Eu queria que vocês comentassem um pouco sobre qual é o impacto disso para a acessibilidade.
________________________________________
[Cláudia]
Então, tem muitos desenvolvedores que criam botões para coisas que não são botões. Por exemplo, um link de navegação que tem comportamento de navegação, mas é criado como botão, e aí o comportamento desses dois elementos fica confuso.
Também acontece de criar um botão que, visualmente, parece um botão, mas não tem semântica de botão. Então, quem não enxerga a tela e não está vendo aquela característica visual pode achar que aquilo não é um botão, porque não foi marcado como um botão.
Essa falta de semântica, ou o uso incorreto dela, pode causar muita confusão na navegação.
E qual é o certo? O certo é criar a semântica adequada para os botões, que é o “button” no HTML.
Sidney, você quer comentar como é a sua navegação quando os botões parecem botões, mas não estão marcados como botões?
________________________________________
[Sidney]
Então, olha só, é muito comum, por exemplo, quando eu estou buscando conhecer as imagens de uma tela, eu usar a tecla de atalho “G”, que é para “elemento gráfico”, e que faz o leitor pular de imagem em imagem.
Às vezes, o leitor encontra algo assim: “elemento gráfico sem descrição, botão”. Ou seja, usaram um elemento, um ícone qualquer, não colocaram um rótulo, não colocaram a devida identificação e colocaram esse ícone como um botão.
Isso causa confusão, porque eu penso: “Poxa, por que isso está aqui? Qual é a ação? Ele executa o quê?”. Então, é bem ruim.
E também tem isso que você já comentou, de a pessoa utilizar um botão como elemento para a navegação. Não é adequado.
________________________________________
[Reinaldo]
E acho que isso envolve até a questão da navegação por teclado. Se você não utiliza a semântica adequada do HTML para fazer com que esses botões se comportem corretamente nesse tipo de navegação, acaba precisando acrescentar outros atributos e recursos para que isso funcione.
Isso acontece porque, de forma nativa, os elementos de botão já têm essa atribuição. Eles já recebem foco na navegação por teclado. E, quando a gente não utiliza esses elementos semânticos, perde esse comportamento.
Com isso, muitas vezes, o funcionamento acaba ficando restrito ao uso do mouse.
________________________________________
[Cláudia]
Exatamente. No exemplo que você deu de criar um botão com uma "div", se ele for implementado dessa forma, por exemplo, com um script, ele não vai entrar na tabulação — simplesmente não consegue.
Uma pessoa que navega pela tecla "TAB", percorrendo os elementos interativos, não consegue acessar aquele botão. O Sidney também não vai conseguir acessá-lo com a tecla "B", usando o leitor de telas.
Por isso, seria necessário criar uma semântica de botão com ARIA e tornar esse elemento focável para que ele entre na ordem de tabulação. Ou seja, começamos a deixar esses componentes muito mais complexos.
Então, o ideal é sempre utilizar a semântica nativa e garantir essa identificação de comportamento. Não usar botão para link, nem link para botão, porque o link é para navegação e o botão é para acionar funcionalidades.
Por exemplo, imprimir uma página é uma funcionalidade, uma ação que será executada — nesse caso, o uso correto é o elemento "button".
________________________________________
[Reinado]
Legal. Quer comentar alguma coisa, Sidney?
________________________________________
[Sidney]
Então, é interessante também que, ao identificar um botão, a gente utilize uma descrição mais completa. Por exemplo, se está apenas “enviar”, fica a dúvida: enviar o quê?
Se eu estou navegando pela página utilizando teclas de atalho, posso me perguntar: é “enviar o e-mail”? “Enviar o formulário”? É a conclusão de um cadastro?
Por isso, é importante usar uma identificação mais clara e completa. Algo como “enviar formulário”, por exemplo, já facilita bastante — e é uma mudança simples de implementar.
________________________________________
[Cláudia]
Esses botões com rótulos muito vagos ficam muito difíceis de identificar, né, Sidney? Por isso, o ideal é realmente utilizar descrições mais completas, como “finalizar compra”, por exemplo, ou “finalizar cadastro”.
Fica muito mais claro do que um simples “ok” ou “enviar”. Enviar o quê? Prosseguir para onde? Então, quanto mais específicos a gente for, melhor.
________________________________________
[Sidney]
Na verdade, a gente precisa dar segurança para a pessoa que está navegando na página. Ela precisa ter clareza sobre o que está fazendo ao pressionar um botão.
Ou seja, precisa ter certeza: estou concluindo a minha compra? Estou colocando o produto no carrinho?
E, aliás, hoje, quando a gente vai a uma loja física, muitas vezes ela funciona como um showroom das coisas mais modernas. Alguns modelos você nem encontra mais ali e precisa comprar pela internet. Por isso, é fundamental que o site tenha esse cuidado de deixar clara a sua forma de navegação.
Os botões precisam ser bem definidos, sem misturar botão com link, para que a pessoa tenha uma boa experiência e consiga realizar ações — como uma compra em um site de e-commerce — com facilidade
________________________________________
[Reinaldo]
Eu estou até imaginando, Sidney: você comentou sobre a navegação por botões usando o leitor de tela. Ao pressionar a tecla "B", você navega diretamente entre os botões.
Então, fico pensando: se você estiver navegando dessa forma e encontrar um botão com o rótulo “Concluir a compra”, você já entende imediatamente o que ele faz.
Agora, imagine navegar por uma sequência de botões com rótulos como “ok”, “ok”, “próximo”. Realmente, não faz muito sentido e dificulta bastante a compreensão.
Isso é interessante para a gente refletir sobre como um botão, quando lido fora de contexto, pode causar problemas de compreensão naquele campo de formulário ou naquele controle.
________________________________________
[Sidney]
Certamente isso faz a pessoa perder tempo, porque surge a dúvida: “ok… ok o quê?”. Aí ela precisa usar a seta direcional para navegar pela página e ler o conteúdo ao redor, tentando entender a que aquele “ok” se refere.
________________________________________
[Cláudia]
Então, qual é a forma correta de fazer isso? O ideal é que a gente utilize texto visível. Por exemplo, se há um botão para “imprimir página”, o melhor cenário é que esse texto esteja explícito ali, visível para todos.
Se não houver texto visível e o botão for representado por uma imagem — como um ícone de impressora —, o ideal é incluir um texto alternativo que indique a função daquele botão, como “imprimir página”.
Agora, se não há nem texto nem imagem, apenas um ícone criado com CSS, como um “X” para fechar, é necessário definir um nome acessível. Isso pode ser feito com um atributo como "aria-label", por exemplo: “fechar janela” ou “fechar cadastro de usuário”.
Ou seja, para que a pessoa compreenda qual é a função do botão, é essencial ter pelo menos uma dessas alternativas: texto visível, nome acessível ou texto alternativo.
Outro ponto importante é a consistência desses rótulos entre as páginas. Se existem botões com funções semelhantes em diferentes partes de um site, os rótulos devem seguir um padrão.
Por exemplo, em uma loja onde é possível imprimir diferentes documentos, como boletos e recibos, os botões poderiam ter nomes como “imprimir boleto” e “imprimir recibo”. Dessa forma, mantém-se uma lógica consistente — “imprimir algo” —, ao mesmo tempo em que se especifica a função em cada contexto.
________________________________________
[Sidney]
Eu já vi situações em que havia um botão “voltar” no final de várias páginas e, em uma delas, o rótulo estava como “sair”, quando na verdade a ação era voltar.
Só que “sair” é uma coisa e “voltar” é outra. Por isso, é fundamental manter a consistência nos rótulos.
________________________________________
[Reinaldo]
Bom, agora eu queria passar para outra barreira, que é a área de toque reduzida dos botões e controles.
Isso é muito importante porque, se a gente pensar, antigamente, quando não existiam smartphones, não havia tanta preocupação com isso, já que os botões e controles tinham tamanhos mais padronizados.
Hoje, com os smartphones, lidamos com telas muito menores, onde qualquer toque pode acionar algo — inclusive de forma equivocada.
Por isso, vale refletir sobre a importância do tamanho dos botões e das áreas de toque, para que o usuário consiga interagir com eles sem encontrar barreiras de acesso.
________________________________________
[Sidney]
Hoje, o software leitor de tela dos smartphones facilita bastante nesse sentido, porque ele indica exatamente onde está o foco — então, basta clicar.
Mas, para pessoas com baixa visão, por exemplo, que utilizam o resíduo visual para interagir, áreas muito pequenas podem trazer dificuldades. O mesmo vale para pessoas que, por algum motivo, não têm precisão no toque.
Se a pessoa tiver tremores ou utilizar, por exemplo, um ponteiro de cabeça para pressionar um botão, áreas muito pequenas podem fazer com que ela clique em algo sem querer. Em vez de executar a ação desejada, acaba acionando outra.
E aí precisa voltar tudo, o que torna a experiência bem ruim.
________________________________________
[Cláudia]
Então, para evitar esse tipo de situação — especialmente cliques acidentais em pessoas que têm mais dificuldade de precisão — é importante considerar não só o uso em celulares, mas também em computadores. Muitas pessoas podem ter dificuldade com o mouse, por exemplo, para clicar em áreas muito pequenas.
Por isso, a norma da ABNT traz uma recomendação sobre o tamanho mínimo da área de clique, justamente para oferecer mais conforto na interação. Esse tamanho mínimo é de 24 pixels CSS de altura e largura para botões e controles.
Há uma exceção quando existe espaçamento ao redor do elemento, já que esse espaço também contribui para a área de interação. Ele ajuda a dar mais segurança no clique e cria um distanciamento entre os elementos próximos.
Nesse caso, o tamanho do elemento somado ao espaçamento ao redor deve totalizar, no mínimo, 24 pixels CSS.
Vale lembrar que esse é o valor mínimo recomendado. Quanto maior for a área de clique, melhor será a experiência — mais confortável e com menor chance de cliques acidentais.
________________________________________
[Reinaldo]
Inclusive, os 24 por 24 pixels fazem parte do requisito da norma da ABNT.
Se a gente quiser ir além e seguir também as recomendações, o valor seguinte já é de 48 por 48 pixels.
________________________________________
[Cláudia]
Os 48 pixels são voltados para celular, ou seja, fazem parte das orientações para dispositivos móveis.
Já na norma, o valor definido é de 44 por 44 pixels CSS de altura e largura.
________________________________________
[Reinaldo]
Está vendo como é bom estar com pessoas que trabalharam a fundo nessa norma? Assim, a gente não corre o risco de esquecer esses valores.
Uma outra barreira que eu queria trazer é a mudança de contexto inesperada. Pense, por exemplo, em uma situação em que você está navegando em uma página, preenchendo um formulário e, de repente, ao interagir com um botão, a página muda, recarrega ou executa alguma ação sem aviso.
Ou seja, o botão acaba alterando o contexto sem que o usuário tenha feito exatamente a ação que esperava.
Então, queria que vocês comentassem um pouco sobre essa barreira e como lidar com esse tipo de situação.
________________________________________
[Sidney]
O que acontece? Eu fico perdido.
Se eu estou preenchendo um formulário e, de repente, ocorre uma mudança repentina, a sensação é de desorientação: “Ué, o que aconteceu? Para onde foi? O que foi executado?”
Aí eu preciso me localizar novamente para conseguir dar continuidade.
E tem ainda o fato de que, às vezes, a página perde o que já foi digitado. Você está lá preenchendo um formulário — nome, data de nascimento, e-mail — e, por algum motivo, a página muda.
Nesse momento, você se perde e pode até perder as informações preenchidas. É uma experiência bem desconfortável.
________________________________________
[Cláudia]
Essas mudanças de contexto devem acontecer sempre a pedido do usuário — ou seja, precisam ser iniciadas por ele. A gente não deve provocar esse tipo de mudança automaticamente, porque muitas pessoas podem ficar desorientadas.
Isso é especialmente crítico quando a pessoa está interagindo com um elemento, como um campo de "checkbox" ou "radio", ou preenchendo informações em um formulário. Não pode acontecer nada de forma inesperada, como redirecionar para outra página, enviar dados automaticamente ou alterar completamente o conteúdo da tela.
Esse tipo de mudança pode não ser percebido e deixar o usuário confuso, levando até ao preenchimento de informações no lugar errado ou à perda de referência na navegação.
________________________________________
[Reinaldo]
Legal.
Agora eu queria passar para um outro tópico: o acionamento de botões. Pode parecer estranho o que a gente está falando, porque, em teoria, o botão seria acionado no momento em que pressionamos. Mas, na prática, se a gente observar bem, o comportamento padrão é diferente.
O botão só é acionado quando você solta — ou seja, quando tira o dedo da tela ou solta o botão do mouse.
A gente até comentou isso em outro episódio. Um exemplo simples é o envio de um e-mail: você pressiona o botão “enviar”, mas o e-mail só é realmente enviado quando você solta o clique.
E isso também está diretamente relacionado à acessibilidade. Então, queria que vocês comentassem um pouco sobre esse comportamento e como ele impacta pessoas com deficiência.
________________________________________
[Cláudia]
Exatamente. Quando a gente usa a semântica nativa, esse comportamento já vem correto por padrão. Mas, quando alteramos um componente, precisamos ficar atentos a isso.
As funcionalidades devem ser ativadas apenas no momento de soltar o dedo — e não no momento de pressionar, seja com o dedo ou com o cursor do mouse. Esses momentos são conhecidos como "down event" (pressionar) e "up event" (soltar).
Apesar de parecerem termos técnicos, o conceito é simples: se a ação for executada no momento em que você pressiona, não há como se recuperar. A ação já aconteceu — por exemplo, o e-mail já foi enviado.
Agora, se a ação só ocorre ao soltar, você ainda tem uma chance de corrigir. Se perceber que não era aquilo que queria fazer, pode mover o dedo ou o cursor para fora do botão e soltar fora dele.
Assim, a ação não é executada — e você evita um erro. Esse comportamento ajuda as pessoas a se recuperarem de interações indesejadas.
________________________________________
[Sidney]
Eu vou fazer uma analogia com o teclado QWERTY no smartphone.
Imagina se, toda vez que você tocasse em uma letra para encontrá-la, ela já fosse inserida automaticamente. Você não conseguiria escrever nada.
Por isso, existe a opção de deslizar o dedo pelo teclado e só inserir a letra quando você levanta o dedo. Então, encontrei o “S”, levantei o dedo — ficou “S”. Encontrei o “I”, levantei o dedo — ficou “I”. Isso faz toda a diferença.
Com botões, é a mesma lógica. Você precisa ter a possibilidade de encostar o dedo, perceber que não era aquilo e arrastar para fora antes de soltar. Assim, a ação não é executada. Caso contrário, pode dar problema.
________________________________________
[Reinaldo]
Eu acho que é importante a gente destacar também quem se beneficia desse tipo de recurso.
O Sidney comentou sobre o teclado, essa possibilidade de ter uma referência antes de confirmar a ação. Isso é especialmente importante para pessoas com mobilidade reduzida — pessoas que têm fraqueza, tremores ou menor destreza para pressionar um botão pequeno com precisão.
Se a pessoa clicar no botão errado, ela pode mover o dedo um pouco para o lado e cancelar a ação antes de soltar. Isso permite corrigir o erro e evita consequências indesejadas.
________________________________________
[Cláudia]
Esse tipo de comportamento também beneficia pessoas com deficiências cognitivas, que podem ter dificuldades de atenção ou concentração e acabar clicando sem querer. Ter essa possibilidade de cancelamento ajuda bastante.
________________________________________
[Reinaldo]
Bom, avançando, queria trazer uma próxima barreira: aplicações que exigem gestos complexos obrigatórios. São aquelas que pedem movimentos específicos, principalmente em smartphones, como usar dois dedos, fazer pinça ou outros gestos mais complexos.
Queria que vocês comentassem um pouco sobre essa barreira e como evitar esse tipo de situação.
________________________________________
[Cláudia]
Hoje é muito comum encontrarmos esse tipo de gesto — movimentos específicos e mais complexos, que exigem uma capacidade física ou motora mais precisa. É o caso, por exemplo, de arrastar um objeto na tela, o famoso "drag and drop", ou do gesto de pinça para ampliar mapas.
O problema é que nem todas as pessoas conseguem realizar esses movimentos. Isso pode acontecer por falta de precisão visual, como no caso de pessoas com baixa visão, que podem não conseguir enxergar exatamente para onde estão arrastando um elemento. Também pode ocorrer por questões motoras, como tremores, movimentos involuntários, falta de força ou de destreza para executar o gesto com precisão.
Além disso, há pessoas que utilizam ponteira de cabeça ou comando de voz, que simplesmente não conseguem executar esse tipo de interação.
Por isso, o ideal é sempre oferecer alternativas. As mesmas funcionalidades devem poder ser realizadas de outras formas, sem exigir gestos complexos. Um exemplo é permitir o uso de um único ponteiro — ou seja, possibilitar a ação por meio de um toque simples, clique, toque duplo ou clique duplo.
No caso de mapas, por exemplo, em vez de depender apenas do gesto de pinça, é possível oferecer botões de zoom, como “mais” e “menos”, permitindo que a pessoa amplie ou reduza a visualização com cliques. Isso garante que mais pessoas consigam utilizar a funcionalidade.
________________________________________
[Sidney]
Eu estava pensando exatamente no exemplo do mapa. Em vez de exigir aquele movimento de pinça — abrir e fechar os dedos para ampliar ou reduzir —, a pessoa pode simplesmente clicar em um botão de “mais zoom” ou “menos zoom”.
Isso facilita bastante para pessoas com baixa visão e também para quem tem dificuldades motoras, já que o movimento de pinça pode ser difícil ou até impossível de executar. Quando a interface obriga esse tipo de gesto, ela acaba criando uma barreira.
Por outro lado, quando você oferece uma alternativa simples, como botões de controle, tudo fica mais acessível. A pessoa consegue ampliar, reduzir ou interagir com o conteúdo de forma mais fácil, com mais autonomia e menos esforço.
________________________________________
[Cláudia]
Você já encontrou alguma situação em que só era possível resolver com o movimento de arrastar e soltar, por exemplo? Já se deparou com algo assim?
________________________________________
[Sidney]
Eu já peguei, sim, situações assim, em que você precisava fazer um movimento específico. Não vou me lembrar exatamente agora qual era o contexto, mas me chamou atenção.
Normalmente, quando você acessa sites ou aplicações, existe alguma alternativa para esse tipo de interação. Mas já encontrei casos em que era obrigatório realizar o movimento.
Se não me engano, era algo assim: você precisava movimentar o celular para conseguir executar a ação.
________________________________________
[Cláudia]
Eu já vi cursos online em que algumas atividades precisavam ser executadas com movimento de “drag and drop”. Então, você participava de uma atividade, recebia uma pergunta e precisava escolher a resposta entre algumas opções, pegar uma delas e arrastar e soltar em um campo específico para verificar se estava correta.
Esse tipo de interação acaba sendo uma barreira, porque muitas pessoas podem ficar de fora quando não conseguem realizar esse movimento.
________________________________________
[Reinado]
Sim, sim. E até pegando um ponto que o Sidney comentou de movimentar o dispositivo, isso também é uma outra barreira que está relacionada com acessibilidade. A norma da ABNT também contempla isso, que é você ter ações que envolvem o movimento do celular.
Então, você ter o seu smartphone, o seu dispositivo, e você, por exemplo, chacoalhar para fazer alguma coisa, ou você fazer um determinado movimento para acionar alguma coisa. Isso é um benefício, é legal você ter um atalho para esse tipo de coisa, só que a gente tem que pensar também que algumas pessoas podem não conseguir movimentar o celular, podem não conseguir segurá-lo, podem não conseguir fazer esses movimentos complexos.
O que vocês podem recomendar sobre o uso desse tipo de recurso?
________________________________________
[Cláudia]
Então, esse é mais um exemplo de como esse tipo de interação pode excluir muitas pessoas, porque há quem realmente não consiga realizar esses movimentos.
A gente vê isso em situações como o gesto de dar um “tchauzinho” para tirar uma foto, girar o celular para visualizar algo em 3D ou até chacoalhar o aparelho para acionar alguma função. Tudo isso pode parecer simples para algumas pessoas, mas não é acessível para todas.
A recomendação da ABNT é clara: sempre que houver esse tipo de interação baseada em movimento, é necessário oferecer uma alternativa na interface. Ou seja, a pessoa deve conseguir realizar a mesma ação por meio de um clique, de forma mais simples e direta.
Além disso, também é importante permitir que esses gestos sejam desativados. Isso evita que a pessoa acione alguma funcionalidade sem querer, especialmente em casos de movimentos involuntários.
________________________________________
[Sidney]
No fim, vale reforçar um princípio importante da acessibilidade: redundância é algo positivo. Se existe uma forma de interação por movimento, deve existir também uma alternativa equivalente — mais simples e acessível — para garantir que todas as pessoas consigam utilizar o recurso.
________________________________________
[Reinaldo]
Eu tive um celular que tinha esse tipo de funcionalidade: com um determinado movimento, quando eu chacoalhava o aparelho, ele acionava a lanterna, o flash.
Ele tinha essa opção, mas isso já me deu bastante problema.
________________________________________
[Cláudia]
Você está com ele na bolsa, no cinema, e, de repente, você senta, o celular chacoalha e a lanterna acende.
________________________________________
[Reinaldo]
Por isso, essa questão de poder desativar esse tipo de recurso quando quiser é tão importante. Esse celular tinha essa funcionalidade, eu podia desabilitar esses atalhos também. Mas ele também tinha o botão da lanterna — um dos itens do menu era justamente um botão para ligar o flash como lanterna.
Acho que esse é um bom exemplo para reforçar a importância de pensar em alternativas: como o usuário que não pode fazer esse movimento consegue utilizar a funcionalidade? É o mesmo raciocínio quando falamos de assistentes de voz. Você pode dar um comando por voz, mas, se a pessoa não consegue falar ou não pode falar naquele momento, ela precisa ter uma interface para acessar aquele recurso.
Então, é isso que o Sidney comentou: sempre pensar na redundância, sempre considerar que o usuário pode precisar de outras formas de realizar a mesma ação.
________________________________________
[Cláudia]
É o que a gente vem falando há vários episódios: a importância de fornecer alternativas, de oferecer opções para o usuário. Quanto mais alternativas a gente tiver, mais pessoas a gente consegue atender.
________________________________________
[Reinaldo]
E aí, falando sobre outra barreira, imagine uma situação em que você vai preencher um campo de formulário e, ao finalizar, em vez de uma página de agradecimento com informações claras, aparece apenas um ícone — como um dedo com “joinha” ou um sinal verde de “ok” — sem nenhuma descrição do que aconteceu.
Isso já indica, de imediato, um problema sério de acessibilidade, mas eu queria que vocês comentassem sobre isso também.
________________________________________
[Sidney]
Você preenche, por exemplo, um formulário e ele te dá um retorno apenas de forma visual. Ele indica que o campo está com erro — por exemplo, quando você não coloca o “@” no e-mail — e marca o campo em vermelho. Ok, ótimo.
Mas, além de marcar em vermelho, é fundamental informar também, de forma textual, que aquele campo está com erro. Assim, quem enxerga vai perceber o destaque visual e identificar o problema, mas quem não enxerga, utilizando um leitor de tela, vai ouvir a mensagem indicando que há um erro no campo.
________________________________________
[Cláudia]
Então, quando a gente faz alguma coisa na web, como preencher um formulário ou executar alguma funcionalidade que gera um retorno, esse retorno precisa ser perceptível para todas as pessoas.
Se a gente colocar um retorno que seja apenas visual, o Sidney não vai conseguir perceber. Se a gente colocar um retorno que é só sonoro, uma pessoa surda não vai conseguir perceber.
Então, o ideal é que a gente crie esses retornos, que a gente chama de “feedbacks”, de forma multissensorial, contemplando diferentes formas de percepção. Ele pode ser visual, mas também precisa ser sonoro. E tem que estar em texto, para que a tecnologia assistiva consiga anunciar.
Então, quando a gente oferece essas opções, essas alternativas, quanto mais possibilidades a gente trouxer, melhor, porque fica mais fácil das pessoas receberem esse retorno e, assim, todo mundo consegue ter acesso à informação.
________________________________________
[Reinaldo]
Bom, legal! A gente já está chegando ao final desse episódio. Imagina, um episódio longo só para falar sobre botões — e acho que isso mostra o quanto o uso de botões é importante.
Botões representam uma funcionalidade essencial da web. Então, pelo menos do meu ponto de vista, ficou muito claro que o botão precisa se parecer com um botão, precisa ter uma ação adequada, como um botão, e precisa estar rotulado de forma adequada, como um botão.
É muito bom ter esse tempo aqui para a gente conversar sobre a importância dos botões, porque eles são fundamentais para que as pessoas consigam fazer compras, reservar hotéis, carros, qualquer coisa que a gente utilize hoje na web. A gente depende dos controles e dos botões.
Então, acho que este foi um dos episódios mais importantes, na minha opinião, porque sem os botões a gente não consegue seguir adiante em praticamente nenhuma ação que realiza na web.
E aí, para encerrar, queria ouvir de vocês um feedback. Já que a gente falou aqui de retorno de controles, queria que vocês deixassem uma palavrinha sobre o episódio de hoje para a gente poder finalizar.
________________________________________
[Cláudia]
Eu concordo. Acho que os botões são fundamentais, porque, se a gente não os criar de forma adequada, seguindo essas boas práticas que a gente falou aqui hoje, muitas pessoas podem ficar simplesmente excluídas do processo.
Elas podem não conseguir finalizar uma compra, como o Reinaldo comentou, podem não conseguir trabalhar, podem não conseguir conversar na web com seus familiares.
Então, a gente está falando da vida das pessoas, do dia a dia delas. Por mais que a gente trate isso de uma forma mais técnica — falando de código, de página, de componente —, no fundo, estamos falando do impacto real na vida das pessoas, de quanto o que a gente faz ou deixa de fazer pode dificultar situações e causar transtornos.
Então, é uma responsabilidade de cada um de nós. Vamos cuidar dos nossos botões e controles.
________________________________________
[Sidney]
Exato. Lembre-se: toda vez que você entra no elevador, você sabe exatamente em que andar vai parar, porque o número está estampado no botão que você pressionou, né?
Assim deve ser também na web. Eu preciso pressionar um botão sabendo exatamente qual ação vai acontecer.
Então, se a gente levar em consideração tudo o que foi dito neste episódio, os botões estarão adequados para todo mundo.
________________________________________
[Reinaldo]
Bom, então chegamos ao fim deste episódio do podcast Todos na Web.
Obrigada pela companhia de vocês e até a próxima!