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

A transcrição foi levemente editada para melhorar a fluidez e a leitura, mantendo o sentido e a intenção das falas originais.

[Reinaldo]
Olá, eu sou o Reinaldo Ferraz, especialista em acessibilidade digital do Ceweb.br. Eu sou um homem branco, de cabelos lisos, castanho-claros e olhos verdes. Tenho uma barba cerrada, quase branquinha já, e estou usando uma camisa preta do Ceweb.
Estou aqui hoje com três especialistas em acessibilidade digital: a Cláudia, o Sidney e a Sandyara. E eu gostaria de pedir para eles se apresentarem antes de a gente começar aqui o nosso episódio. Sejam bem-vindos, pessoal!
________________________________________
[Cláudia]
Obrigada! Muito bom estar aqui.
Eu sou a Cláudia Martin Nascimento. Sou uma mulher de pele clara, tenho cabelos castanhos escuros na altura dos ombros, mais ou menos, um pouco abaixo deles. Tenho olhos castanhos escuros também e uso óculos. Estou vestindo uma camiseta azul e um casaquinho preto por cima.
Eu sou designer por formação. Trabalho com acessibilidade há mais ou menos 13 anos e atuo na minha empresa, a Acesso para Todos.
________________________________________
[Sandy]
Oi, pessoal! Tudo bom?
Eu sou a Sandyara, mais conhecida como Sandy. Eu sou uma mulher branca, de cabelos escuros na altura dos ombros, com mechas desbotadas na lateral direita. Tenho sardas abaixo dos olhos e estou vestindo uma blusa de gola alta preta, com um colar colorido de estrelinhas.
Sou especialista em design de produto com foco em acessibilidade. Já atuei em diversas empresas do setor privado e, atualmente, atuo no setor financeiro bancário.
________________________________________
[Sidney]
Olá, pessoas!
Bem, eu sou o Sidney Tobias de Souza. Sou um homem de 59 anos, cabelos e olhos castanhos, nariz núbio. Sou analista de sistemas da Prodam e consultor de acessibilidade digital da Secretaria Municipal da Pessoa com Deficiência.
Meu sinal em Libras é esse: o “S”, o “Y” e sobe
________________________________________
[Reinaldo]
Muito bem. Hoje nós vamos falar sobre itens problemáticos para a acessibilidade. A gente vai falar sobre coisas específicas que estão presentes nos sites hoje, no dia a dia, e que podem causar barreiras de acesso para pessoas com deficiência.
Então, a ideia hoje aqui é descobrir com vocês quais são essas barreiras e entender o que a gente pode fazer para torná-las mais acessíveis para pessoas com deficiência.
Bom, só para a gente começar, eu queria trazer um contexto geral, porque a web é uma grande plataforma para o desenvolvimento de aplicações e permitiu uma série de possibilidades. Se a gente for pensar em e-commerce, redes sociais e uma série de serviços, todos começaram na web.
Mas, muitas vezes, esses recursos são criados e, algumas vezes, são acrescentados outros recursos que podem criar barreiras de acesso para pessoas com deficiência. E são itens amplamente utilizados, que muitas vezes você simplesmente não pode remover, não pode tirar do uso no dia a dia.
Então, a ideia do episódio de hoje é a gente conversar sobre esses itens problemáticos apontados pela norma da ABNT e orientar sobre o que a gente pode fazer para que essas barreiras de acesso não sejam tão grandes, para que a gente possa minimizar, pelo menos, as barreiras de acesso que esses itens podem causar.
Cláudia, você quer comentar um pouquinho sobre como isso é tratado na norma?
________________________________________
[Cláudia]
Bom, a acessibilidade na web depende de como o código é estruturado e de como os componentes são implementados. Existem muitos componentes e funcionalidades na web que realmente trazem problemas de acessibilidade. Por isso, têm o uso desencorajado, mas, como são muito utilizados e muito comuns, não é possível simplesmente proibir seu uso.
Então, a norma ABNT 17225 traz todos esses itens agrupados em um bloco, explicando algumas ações que a gente pode fazer e alguns cuidados que a gente precisa ter para tornar esses componentes mais acessíveis para mais pessoas.
A gente tem, por exemplo, funcionalidades de CAPTCHA, reconhecimento facial, conteúdo que aparece somente quando se passa o mouse por cima ou quando se foca um elemento na tela, erros de marcação semântica HTML e componentes customizados.
Então, são vários itens sobre os quais a gente vai conversar aqui hoje, um pouquinho sobre cada um deles, e ver o que a gente pode fazer para que eles tenham menos barreiras e mais pessoas possam acessá-los.
________________________________________
[Sidney]
Há componentes que realmente acabam sendo impeditivos para uma boa navegação, e eu gostaria de começar falando sobre CAPTCHA.
No meu caso, como pessoa cega, eu não consigo, por exemplo, selecionar imagens para dar continuidade ao que estou fazendo se um CAPTCHA exigir isso de mim: seleção de imagens. Alguns nem trazem a informação se você tem que digitar letras, números, nada disso. Então, isso é impeditivo de uma boa navegação.
E eu não sou robô, eu preciso continuar na página. Então, a gente não consegue implementar algo diferente para validar se a pessoa é ou não um robô e permitir que ela continue?
Acho que isso é algo em que a gente deve sempre pensar: “Olha, eu não posso criar uma barreira aqui para o usuário.”
________________________________________
[Sandy]
E acho muito importante reforçar essa questão de que são ferramentas amplamente difundidas hoje. A gente não pode chegar e falar: “Parem as máquinas, parem de usar”, né?
Mas a gente também precisa reconhecer o histórico de que entendemos a necessidade, no caso do CAPTCHA, de provar que não é um robô e, no caso do reconhecimento facial, de ter a prova de vida para evitar uma possível fraude.
Mas foram problemas que, com certeza, se houvesse pessoas com deficiência lá no início, durante a construção dessas ferramentas, talvez nem sequer existissem hoje.
Então, hoje estamos em um patamar em que a gente reconhece a intenção de uso dessas ferramentas, mas também reconhece os problemas de acessibilidade presentes. Cabe agora a nós decidir se vamos querer perpetuar esses problemas ou se vamos tentar mitigar essas barreiras.
________________________________________
[Reinaldo]
Então, o que a gente pode fazer para deixar esses CAPTCHAS um pouco mais acessíveis ou com menos barreiras?
________________________________________
[Cláudia]
Bom, existem diversas dificuldades que os CAPTCHAs trazem para diversos públicos. Uma das recomendações é evitar o uso dessas letrinhas distorcidas, desfocadas, muito clarinhas, porque pessoas com baixa visão têm muita dificuldade e não conseguem passar por esse tipo de CAPTCHA.
Além disso, uma das recomendações é a gente fornecer mais de uma modalidade de CAPTCHA para atender a diferentes necessidades. Se você usa o reconhecimento de imagens, que o Sidney não consegue utilizar, você pode fornecer, por exemplo, uma alternativa em áudio, com um player que faz uma pergunta, e o Sidney pode ouvir e responder essa pergunta.
Quanto mais alternativas a gente tiver, melhor. O uso de CAPTCHAs não é recomendado, mas, se houver, é preciso ter esses cuidados.
Além disso, a gente tem que instruir o usuário, informando o que ele vai encontrar, que tipo de desafio ele vai encontrar, que ele vai passar por um CAPTCHA e terá que resolver um tipo de desafio específico.
Outra coisa que a gente precisa garantir é que esses desafios possam ser feitos sempre pelo teclado. Todas as funcionalidades do desafio precisam funcionar pelo teclado.
Além disso, é preciso exigir o mínimo de esforço cognitivo possível, não exigir tempo limite. Tem um monte de questõezinhas que a gente pode cuidar para tornar esse processo mais inclusivo.
________________________________________
[Sidney]
Lembrando que, como a gente sempre costuma dizer, em acessibilidade, redundância é sempre bem-vinda.
Então, se a gente disponibiliza um CAPTCHA de áudio, eu, como pessoa cega que utiliza leitor de tela, vou conseguir ouvir e digitar aquele desafio. Mas notem: tem pessoas que não ouvem, né?
Então, a gente também precisa ter um CAPTCHA baseado em imagem para que pessoas surdas também consigam resolver o desafio proposto e seguir na navegação.
________________________________________
[Sandy]
Eu concordo plenamente com o que o Sidney falou. Hoje, existem até outros tipos de CAPTCHAs, como o de “drag and drop”, clique e arraste, encaixar peças específicas ou reconhecer certos padrões.
Quanto mais alternativas que combinem estímulos visuais, auditivos e físicos, deixando que o próprio usuário decida com o que ele se sente mais confortável, melhor. Esse sempre vai ser o cenário ideal.
Eu só queria complementar aqui que, em momento algum, a gente está desconsiderando a questão da segurança. Não é porque a gente está falando que o CAPTCHA tem barreiras de acessibilidade que a gente vai começar a desconsiderar a segurança e, principalmente, a segurança das pessoas com deficiência.
Então, a ideia aqui é promover uma forma de a pessoa com deficiência conseguir utilizar esses recursos, mas também preservar sua segurança na navegação.
________________________________________
[Reinaldo]
E só mais um ponto: quando a gente fala de CAPTCHA de áudio, tem a questão do uso das imagens. Se a gente não consegue usar imagens, a gente vai para o áudio. E a gente precisa tomar cuidado porque, em algumas situações, já encontrei áudios em outro idioma, e isso também pode ser uma barreira para algumas pessoas.
Não conseguir compreender um determinado idioma pode dificultar o preenchimento daquele CAPTCHA de áudio.
________________________________________
[Cláudia]
Ou áudios com muito ruído de fundo também, podem dificultar para pessoas com deficiência auditiva.
________________________________________
[Sidney]
E eu já encontrei CAPTCHA em inglês e com ruído de fundo. Então, realmente dificulta bastante.
________________________________________
[Sandy]
Isso daí é só para quem tem a proficiência Cambridge, né?
________________________________________
[Reinaldo]
E o curioso é que os CAPTCHAs tentam ser cada vez mais criativos e cada vez mais elaborados na forma de resolver. Eu cheguei a ver um CAPTCHA, há um tempo, que era um simulador do jogo Doom.
Era quase como você ter que jogar um jogo para poder passar pelo CAPTCHA. Tudo bem, ele estava só em formato de teste, mas era um tipo de CAPTCHA para você resolver.
________________________________________
[Cláudia]
Como se a gente tivesse todo esse tempo do mundo.
________________________________________
[Sandy]
E eu gosto de Doom, mas acho que nesse contexto...
________________________________________
[Reinaldo]
Pois é! Imagina você querendo finalizar sua compra em um e-commerce e aí você tem que jogar Doom. Dependendo do chefão, a gente nem consegue terminar a compra.
Bom, eu queria passar agora para o próximo item que está na lista da norma da ABNT, que trata da questão do reconhecimento facial. Então, apesar de ser muito utilizado, ele tem algumas barreiras de acesso para as pessoas com deficiência, e alguns cuidados precisam ser tomados para que as pessoas com deficiência não enfrentem essas dificuldades ou sejam impedidas de realizar o reconhecimento facial.
Queria que vocês comentassem um pouquinho sobre esse tópico.
________________________________________
[Sidney]
Imagina eu precisar colocar meu rosto exatamente no espaço predeterminado: nem para a direita, nem para a esquerda, nem para cima, nem para baixo. E eu não consigo ver esse espaço predeterminado para que meu rosto fique. E não tenho um feedback em áudio me orientando.
O leitor de tela não vai me ajudar nessa questão, então é super difícil conseguir fazer isso. É uma exigência que não facilita a vida de quem utiliza um software leitor de tela para fazer um “Face ID” usando um espaço reduzido, sem auxílio em áudio ou algo parecido.
________________________________________
[Sandy]
Ou até mesmo o próprio algoritmo dessas ferramentas. Geralmente, essas ferramentas funcionam de duas formas: ou utilizam a posição da pupila para realizar o reconhecimento, ou tentam fazer um escaneamento 3D do rosto.
Mas, se você não consegue manter os olhos abertos, tem olhos muito pequenos ou se a pálpebra cobre um pouquinho o seu olho, isso já é o suficiente. Mesmo que você não utilize leitor de telas, isso já é suficiente para que a máquina não reconheça você corretamente.
________________________________________
[Cláudia]
Ou uma pessoa que não tem os olhos, né?
E uma pessoa que tem, por exemplo, Parkinson e tem que ficar em uma posição imóvel
na frente da câmera. Como ela faz?
Então, o reconhecimento facial traz muitos desafios para diversos públicos.
________________________________________
[Reinaldo]
Então, qual seria a orientação, com base na norma ABNT para tentar deixar um pouco mais acessíveis esses recursos?
________________________________________
[Cláudia]
Então, a ideia é evitar esse tipo de ferramenta, mas a gente sabe que hoje, por segurança, as instituições são muito resistentes em retirar o reconhecimento facial. O recomendado é que a gente forneça alternativas.
Alternativas. Esse é o termo-chave para acessibilidade. Então, se você utiliza o reconhecimento facial, permita que a pessoa possa fazer essa identificação por outro método.
Por exemplo, com uma validação em dois fatores, por meio de um link enviado para o e-mail da pessoa, para que ela possa confirmar a identidade de outra maneira.
Ainda não temos uma solução específica, mas precisamos encontrar alternativas ao reconhecimento facial que não exijam que a pessoa faça a identificação apenas por esse método.
________________________________________
[Sandy]
Acho que, sobre essa questão, vale muito também a gente estar atento ao mercado, à indústria e à academia para acompanhar os avanços, porque a gente entende que, mesmo com recursos como a autenticação em dois fatores, em alguns setores e nichos é exigida a chamada prova de vida, para confirmar que é uma pessoa que está utilizando aquele dispositivo, né?
Eu me deparei recentemente com um tipo de biometria em que você apoia o celular na mesa e tenta encaixar o dedo para mapear sua digital, como alternativa ao reconhecimento facial. Ainda está em teste e tudo mais, mas pode ser que seja uma segunda alternativa e a gente possa ir combinando.
Mas, se isso não for possível, acho que é sempre muito bem-vindo avaliar se não vale a pena um atendimento humano, uma intervenção humana, para que o usuário não fique refém de uma tecnologia, mas tenha uma assistência caso seja recusado ou tenha alguma frustração.
________________________________________
[Cláudia]
Também é importante implementar o feedback acessível, como o Sidney falou, para tecnologias assistivas. Então, não deixar a informação apenas visual — “Aproxime seu rosto, vire para a esquerda, para a direita” —, mas fazer com que o leitor de telas, por exemplo, consiga anunciar esse feedback e orientar o Sidney para ele saber o que precisa fazer.
Então, existem formas de tornar esse processo um pouquinho mais acessível.
________________________________________
[Reinaldo]
Legal. Agora, passando para o próximo item, que é sobre conteúdos exibidos ao passar o mouse.
É muito comum encontrar menus e submenus exibidos ao passar o mouse ou mesmo “tooltips” que aparecem quando passamos o mouse sobre eles. Se a gente pensar hoje até em relação a dispositivos móveis, esse conteúdo pode acabar sendo ignorado nesses dispositivos.
Mas eu queria ouvir de vocês: em relação à acessibilidade, qual é o impacto disso para pessoas com deficiência?
________________________________________
[Cláudia]
Esse tipo de conteúdo é muito indesejado. O ideal é evitar esse uso, porque pode trazer barreiras. Tem pessoas que acionam esse conteúdo adicional sem querer. Elas não tiveram essa intenção, mas focaram um elemento e o conteúdo aparece.
Ou então, por exemplo, o Sidney pode focar um elemento e não perceber que apareceu um conteúdo adicional ali. Pessoas que navegam pelo celular também podem não conseguir ter acesso a esse conteúdo. Então, a gente deve evitar esse tipo de conteúdo.
Se ele existir, aí a gente tem que garantir que todo mundo consiga acessá-lo. Um exemplo são aqueles “tooltips” que aparecem quando usamos o atributo “title” no HTML, mas nem todo mundo consegue acessar, né?
Então, a gente precisa garantir que todo mundo consiga acessar esse conteúdo caso ele exista na nossa página.
________________________________________
[Sidney]
Eu utilizo o teclado para navegar, então, quando algo exige o uso do mouse, isso começa a complicar minha vida.
Então, seria importante que houvesse outra alternativa para acessar essas informações que estão sendo disponibilizadas.
________________________________________
[Sandy]
Ou até mesmo uma pessoa que não utiliza o leitor de tela, mas utiliza o teclado, seja por conforto ou por alguma necessidade, ser obrigada a alternar a navegação para acessar uma informação que, apesar de complementar, é direito do usuário acessar, é completamente frustrante.
________________________________________
[Cláudia]
Pode ser uma informação importante também, e a pessoa nem sabe que apareceu ali.
________________________________________
[Reinaldo]
Sim.
Eu queria até perguntar para o Sidney, porque a Cláudia comentou sobre o atributo “title”, que é aquele atributo que exibe um “tooltip” quando você passa o mouse. O leitor de tela lê, por padrão, o atributo “title” ou isso pode ser habilitado e desabilitado?
Porque, muitas vezes, o “title” está apenas repetindo o texto que já está no link. Isso pode gerar conteúdo redundante, né?
________________________________________
[Sidney]
Eu já entrei em sites em que ele leu por padrão e em outros em que parece que não leu. Então, não sei se isso é padrão.
________________________________________
[Reinaldo]
Bom, então é melhor não usar, porque, se ele não lê por padrão ou se lê em um site e não em outro, é melhor não usar. Então, ele está bem colocado na lista de itens problemáticos para a acessibilidade.
Bom, passando para o próximo tópico, outro item que costuma causar problemas de acessibilidade é o conteúdo inserido por CSS.
Antes, só para fazer um breve parêntese e explicar o que é CSS: CSS são as folhas de estilo que controlam a apresentação da página. Então, ele controla o posicionamento dos elementos, além de tamanho e cor. Tudo o que está relacionado à formatação visual está dentro dessa folha de estilo.
Normalmente, o leitor de tela não tem acesso a essas informações. Então, o leitor de tela não identifica, por exemplo, se o texto está em tamanho dez ou se o texto está em cinza.
A questão aqui é que existem algumas pseudoclasses de CSS que permitem acrescentar alguns elementos. Normalmente, o pessoal coloca ícones, “bullets” ou alguma coisa específica antes ou depois de um item.
Mas o problema é quando inserimos conteúdo lá dentro, um conteúdo inserido por CSS e não na estrutura da página. Eu queria que vocês comentassem um pouquinho sobre isso.
________________________________________
[Cláudia]
Informações importantes não devem ser inseridas via CSS nas páginas porque, mesmo para pessoas sem deficiência, se você desativou o CSS, por exemplo, para carregar um conteúdo mais rápido porque está em um contexto específico, ou se o CSS falhou por algum motivo, você pode perder essa informação importante, porque ela não será carregada.
Então, o ideal é não inserir conteúdo por CSS nas páginas. Para pessoas com deficiência, há algumas que desativam o CSS para navegar e, assim, podem perder essas informações.
O ideal é que, em vez de usar CSS para inserir informações, a gente use JavaScript junto com atributos ARIA para inserir essas informações na página. Dessa forma, a informação fica no HTML. Então, mesmo que a gente desligue o CSS da página, ou seja, os estilos visuais, ainda assim a informação permanecerá lá.
________________________________________
[Sandy]
Eu nem vou muito longe. Mesmo sem leitores de tela, por exemplo, quando eu tenho que ler textos muito densos, adoro usar extensões que invertem cores.
Às vezes, é um site muito claro e, para leitura, eu prefiro um tema escuro, nesse sentido. E, quando o conteúdo, principalmente se for importante, está no CSS, a inversão de cores não funciona corretamente. Muito desse conteúdo se perde.
________________________________________
[Reinaldo]
Bom, e o próximo tópico é sobre conteúdo de terceiros ou fontes externas, ou seja, algum conteúdo que está em outra página ou em outra aplicação e que a gente vai embutir na nossa página.
Talvez o exemplo mais comum que eu possa dar aqui sejam vídeos do YouTube. A gente pode embutir esses vídeos. Estamos chamando de fonte externa um vídeo não só do YouTube, mas de qualquer canal de vídeo que a gente possa embutir no nosso site.
Então, a questão delicada aqui é: imagina você assistir a esses podcasts aqui, a essa série de episódios, cuidar da acessibilidade bonitinho, deixar o seu site redondinho, mas pegar um vídeo do YouTube que não tem recursos de acessibilidade, não tem os cuidados com a acessibilidade. Aí, você acaba trazendo para a sua aplicação um recurso com barreiras de acesso.
E a norma aborda esse aspecto de trazer conteúdos de fontes externas. Eu queria que vocês comentassem sobre isso.
________________________________________
[Cláudia]
Quando a gente traz conteúdos de uma fonte externa para dentro do nosso conteúdo, e esse conteúdo vem com barreiras de acessibilidade, a gente está trazendo as barreiras para o nosso conteúdo também, lembrando que ele passa a fazer parte da nossa página web.
E não é só o caso de um vídeo do YouTube. Hoje é muito comum as empresas contratarem plataformas terceiras, por exemplo, para mostrar indicadores em gráficos, para disponibilizar documentos. E esses arquivos, quando vêm com problemas de acessibilidade, problemas na marcação de código, falta de cabeçalhos ou falta de descrição de imagens, trazem essas barreiras para dentro.
Então, a recomendação é procurar melhores fornecedores, procurar fornecedores que sigam padrões de acessibilidade quando formos incorporar isso ao nosso conteúdo.
Se não for possível, se você tem aquele conteúdo e não consegue ajustá-lo nem trocá-lo nesse momento, então você precisa, pelo menos, avisar o usuário de que ele vai encontrar um conteúdo de uma fonte externa e que ele pode conter barreiras.
________________________________________
[Sidney]
É fundamental avisar o usuário que você está trazendo para o seu site um conteúdo externo, seja uma página externa, até com outra identidade visual e, muitas vezes, sem acessibilidade, seja um vídeo do YouTube ou qualquer outro conteúdo externo.
Porque, de fato, você não pode garantir que esse conteúdo terá a mesma preocupação com acessibilidade, que tiveram essa mesma preocupação durante sua criação e que continuarão tendo, na manutenção, o mesmo cuidado que você está tendo em deixar todo o seu conteúdo acessível.
________________________________________
[Sandy]
E acho que, nesse caso, também cabe avaliar se não é possível negociar com o fornecedor para tornar o conteúdo acessível, atendendo ao padrão de acessibilidade que você está querendo alcançar, e entender se há como encontrar algumas soluções paliativas a curto prazo.
De repente, disponibilizar aquele mesmo conteúdo de uma forma um pouco mais acessível, para tentar incluir o máximo de pessoas, mesmo não sendo ainda a experiência ideal.
________________________________________
[Reinaldo]
Legal. Outro ponto em que podemos encontrar problemas de acessibilidade é em componentes customizados, principalmente aqueles que não têm um comportamento esperado ou uma descrição adequada.
Então, aquela situação, por exemplo, em que você abre um “pop-up”, um carrossel ou um modal e não sabe como lidar com isso, porque talvez o componente não tenha a semântica adequada ou não esteja marcado de forma adequada.
Então, quais são os impactos disso para as pessoas com deficiência?
________________________________________
[Cláudia]
Então, componentes customizados podem realmente trazer muitas barreiras. Sempre que possível, devemos usar elementos nativos do HTML, mas a gente sabe que existem alguns componentes que não têm uma semântica nativa para construir determinados tipos de comportamento.
Então, se a gente tiver que usar um componente customizado, precisamos realmente cuidar, informar qual é o papel desse componente, qual é a função dele e incluir as especificações. Por meio da especificação ARIA, a gente consegue adicionar atributos, como rótulos e outras informações, para que o usuário saiba, mesmo dinamicamente, o que está acontecendo, inclusive os estados desses componentes.
Mudou: agora ele está aberto ou fechado, está expandido ou oculto. Então, a gente tem que trazer essa especificação e essa semântica de outra maneira.
________________________________________
[Sidney]
E, normalmente, quando existe um componente, por exemplo, um carrossel, e ele está mudando o conteúdo dinamicamente, o leitor de tela também pode se perder. Então, estou buscando uma informação, esse conteúdo muda, pisca na tela e o leitor de tela tenta anunciar isso. Isso pode ficar confuso.
Fora o fato de que, quando eu quero, de fato, saber o conteúdo de um carrossel, se ele não estiver rotulado, fica confuso entender o que está sendo mostrado: qual é o primeiro item, o segundo ou o terceiro do carrossel.
“Pop-ups”. Às vezes, eu já fiquei preso em “pop-ups”, então é importante ter esse cuidado também. Aparece um “pop-up” com uma mensagem, uma mensagem de erro ou uma exigência que está sendo feita, e eu preciso conseguir sair dali com a tecla Esc. Tem que existir uma forma de continuar a navegação.
________________________________________
[Sandy]
Isso não vale só para componentes complexos, mas para qualquer componente em que a pessoa tenha alguma dificuldade. Seja ela desenvolvedora ou designer, faça pesquisas, aprofunde-se na documentação técnica, realize testes e, se for o caso, inclua também a pessoa usuária nesse processo para entender qual seria a experiência ideal para ela.
________________________________________
[Reinaldo]
Um cuidado que eu acrescentaria ao que vocês comentaram é, principalmente, com conteúdos que a gente implementa vindos de bibliotecas e frameworks já desenvolvidos e consolidados.
Tenho percebido muito, por exemplo, carrosséis com botões em inglês. Você tem um site em português, aí encontra lá “previous button” ou, então, o botão de fechar, “close button”. Isso quando está rotulado. Em alguns casos, você só tem o botão de fechar rotulado como “botão”.
Então, acho que um cuidado importante é sempre verificar os rótulos desses componentes interativos que esses itens trazem.
________________________________________
[Cláudia]
É, isso é bem comum.
________________________________________
[Reinaldo]
Outro ponto para a gente conversar aqui, que a norma aborda, são arquivos para download que não são acessíveis.
Então, por mais que a gente esteja falando de conteúdo e páginas web, a gente sabe que a web está recheada de outros conteúdos que não necessariamente fazem parte da web. Tem PDF, documentos em Word e arquivos em formato de imagem.
Mas a gente também tem que garantir que esses documentos sejam acessíveis. Precisamos garantir que esses arquivos para download possibilitem que as pessoas com deficiência também consigam acessá-los.
Eu queria ouvir um pouquinho de vocês sobre esse item.
________________________________________
[Cláudia]
Os documentos também têm esse requisito de serem acessíveis. Se colocamos um documento para download na nossa página, esse documento também precisa estar em conformidade.
Então, é muito importante fazer verificações e testes de acessibilidade. Dependendo do tipo de arquivo, pode haver uma documentação específica, um validador específico, e não apenas validações automáticas. Precisamos cuidar do arquivo e seguir boas práticas em todos os aspectos.
Se você tem um documento, por exemplo, em Word, que será gerado em PDF, vamos cuidar dos links para que eles sejam descritivos, adicionar descrição às imagens, observar o texto, se está escrito corretamente e com linguagem simples, se ele tem um alinhamento adequado.
Então, precisamos observar todas as boas práticas para documentos também. Sidney, você quer comentar?
________________________________________
[Sidney]
Sim. Tudo aquilo que a gente consegue fazer no site também pode fazer nos documentos. Então, fazer a descrição das imagens. Se tiver tabelas, incluir a descrição dessas tabelas, um texto alternativo para elas.
Se o documento tem um sumário, é importante “hiperlinkar” esse sumário para que eu possa ir direto ao assunto que eu quero ler no documento.
Então, é importantíssimo ter esse cuidado, porque, às vezes, a gente coloca um link para fazer o download do arquivo e teve a preocupação de informar o tamanho dele, para a pessoa decidir se baixa agora ou quando chegar em um lugar com Wi-Fi, informou qual é a extensão, mas, quando a pessoa abre o arquivo, ele não é acessível, e todo esse trabalho se perde.
Então, é importante verificar, de fato, a acessibilidade do documento em si.
________________________________________
[Sandy]
No fim das contas, quando a gente fala de acessibilidade, a experiência é de ponta a ponta: na autenticação, com o reconhecimento facial que a gente comentou, né? Na navegação e na interação com o conteúdo da página, mas também com todos esses documentos.
Imagina que você vai contratar um serviço, como um empréstimo, baixa o contrato e ele não está acessível. Que segurança isso passa para o cliente, né?
Então, se você está, de fato, comprometido com a acessibilidade, é importante lembrar que esses pequenos detalhes, no fim do dia, importam e impactam diretamente a experiência.
________________________________________
[Reinaldo]
Legal. Agora, o próximo item é sobre o uso de tabelas para design. A gente já abordou esse tópico no episódio sobre listas e tabelas porque, por mais estranho que isso pareça, ainda é comum a gente encontrar o uso de tabelas para posicionamento de componentes e elementos na página, e não para apresentar dados tabulares.
Eu sei que a gente já comentou sobre isso nesse episódio, mas acho importante reforçarmos aqui, porque esse é realmente um item problemático para a acessibilidade. Eu queria que vocês comentassem sobre ele.[C
________________________________________
[Cláudia]
Sim, o uso de tabelas para a criação de layouts é totalmente desencorajado. Ele não é proibido, mas é desencorajado porque pode realmente trazer barreiras.
Navegar por tabelas já não é um processo muito fácil quando se usa um leitor de telas ou outra tecnologia assistiva, principalmente se elas tiverem semântica, porque as tecnologias vão começar a relacionar os itens dentro dessas tabelas. Isso pode ficar muito confuso para o usuário compreender as informações, e ele pode não conseguir.
Então, a recomendação da ABNT é que, embora o ideal seja não usar essas tabelas para o layout, se usarmos, precisamos retirar toda a semântica dessa tabela. Então, remover os cabeçalhos para evitar esse relacionamento entre os dados, remover o “caption” e não deixar nenhum título associado à tabela.
Quando fazemos isso, a gente melhora um pouquinho essa situação.
________________________________________
[Sidney]
Quando estou utilizando o leitor de tela e encontro uma tabela, o leitor de tela já está esperando que ali existam linhas e colunas. Então, eu vou dando Tab, e ele vai navegando pelas linhas e pelas colunas. Por quê? Porque ele está entendendo que aquilo são dados tabulares, dados que podem ser analisados por linha ou por coluna.
Agora, se a tabela foi utilizada como layout, por exemplo, para “colunar” texto, para ficar bonitinho, aí fica difícil, porque não é isso que está sendo esperado na navegação com o leitor de tela quando há uma tabela.
________________________________________
[Sandy]
E tem um problema maior ainda quando a gente fala de responsividade. Porque, quando a gente utiliza tabelas, aquele conteúdo não vai conseguir se adaptar em telas menores.
Hoje, já conseguimos utilizar o próprio CSS para trabalhar melhor essa questão e adaptar o conteúdo: se ele vai esticar, se não vai esticar, se vai empilhar ou não.
E, quando eu trabalho com um layout totalmente em tabelas, fico com um layout muito enrijecido, que eu não tenho possibilidade de flexibilizar.
________________________________________
[Reinaldo]
Nossa, já arrumei um ótimo argumento para desencorajar ainda mais o uso de tabelas em sites.
E o último item que a gente tem dentro dessa norma da ABNT é a questão de páginas web com erros de marcação em HTML.
Então, a versão mais recente das diretrizes de acessibilidade internacionais, a WCAG 2.2, já não exige mais que as páginas estejam livres de erros de marcação de código. Aquela questão de um elemento aberto que não foi fechado, alguns atributos equivocados que normalmente são inseridos e que as ferramentas de verificação apontam como erro já não são mais um requisito de acessibilidade com base na norma internacional e também na norma da ABNT.
Mas esse é um ponto interessante porque, em alguns casos, esses erros de marcação podem causar problemas de acessibilidade. E aí eu queria ouvir um pouquinho de vocês sobre esse ponto, esse item problemático apontado na norma.
________________________________________
[Cláudia]
Eu fico pensando nos identificadores, nos IDs que a gente coloca para identificar componentes e elementos na tela. Se você tem um ID repetido em dois componentes, como o leitor de telas vai se comportar em relação a isso?
Eu acredito que erros de HTML podem, sim, trazer barreiras de acessibilidade, e isso aparece nesse item de itens problemáticos da norma justamente porque a recomendação é que não existam erros de HTML.
O ideal é a gente corrigir regularmente esses erros de HTML nas páginas, deixar tudo zerado mesmo e usar, de preferência, validadores oficiais, como o validador do W3C.
Quando a gente faz isso, a gente garante que não vamos criar barreiras por problemas de marcação. Além disso, a gente ganha mais compatibilidade com os navegadores e outros agentes de usuário. Então, é muito importante mantermos as nossas páginas livres de erros.
________________________________________
[Sidney]
Erros de marcação podem até não ser barreiras, mas causam ruídos. Então, eu costumo dizer que, para quem abre o site e enxerga, a navegação visual é bem direta, a pessoa localiza rapidamente o que quer.
Quando a gente está utilizando o leitor de tela, para chegar a uma informação, nós passamos por várias áreas do site, ouvindo todas essas informações. Então, se houver erros de marcação também, isso gera um ruído desconfortável para nós.
________________________________________
[Sandy]
Acima de tudo, eu diria que isso é muito mais um aspecto de qualidade de código e da qualidade do seu trabalho enquanto uma pessoa desenvolvedora, que impacta em acessibilidade e usabilidade quando a gente pensa em compatibilidade com diferentes navegadores e tudo mais.
Então, acima de tudo, se você preza pela qualidade do seu trabalho, acho que temos muitas ferramentas hoje que automatizam esse processo e fornecem esses feedbacks. Então, não tem por que dizer não, né, gente?
________________________________________
[Reinaldo]
Bom, a gente já está caminhando aqui para o final do nosso episódio. Esse foi um episódio um pouco diferente dos demais, porque ele aborda temas e itens específicos de uso na web.
Mas eu acho interessante que, por mais que tenhamos falado sobre os cuidados que a gente precisa ter com CAPTCHA, reconhecimento facial, conteúdos inseridos por CSS e componentes customizados, isso também se aplica a outras situações que não foram contempladas nessa norma.
Podem surgir outros tipos de tecnologia e outros recursos que talvez tragam barreiras para as pessoas com deficiência e que a gente também vai precisar considerar. E eu acho que a grande mensagem deste episódio foi sempre considerar o usuário em primeiro lugar.
Eu acho que a experiência do usuário, de conseguir acessar o conteúdo e receber feedback, é muito importante. O usuário também precisa ter opções e alternativas caso certos recursos não estejam disponíveis para ele.
Então, eu acho que esse episódio foi especialmente interessante porque expande essa questão da web para outros componentes. A gente está falando hoje de outros cenários e tecnologias, inteligência artificial e vários recursos que ainda podem surgir pela frente. Mas tudo isso precisa considerar o usuário em primeiro lugar.
E aí, para a gente encerrar, a mensagem final que eu deixo é: evitar esses itens que a gente comentou aqui ou, se for utilizá-los, tomar os cuidados que foram apontados na norma e aqui neste episódio.
E aí, eu queria uma mensagem final de vocês para o episódio de hoje.
________________________________________
[Cláudia]
Eu queria lembrar que esses itens problemáticos são problemáticos para todo mundo, não só para as pessoas com deficiência. A gente trata esses itens de forma separada na norma porque eles são críticos para as pessoas com deficiência.
Mas pessoas que têm mais idade ou pouca experiência com a web, e até pessoas que já estão acostumadas com ela, podem ter — e têm, a gente sabe disso — muitas dificuldades, experiências frustrantes e várias tentativas e erros, por exemplo, com reconhecimento facial.
Então, se formos utilizar um componente desse tipo, uma funcionalidade desse tipo nas nossas páginas, como o Reinaldo comentou, vamos pensar primeiro no usuário e entender como ele se comporta. Ele realmente está satisfeito em usar essa ferramenta? Ou está enfrentando muitas dificuldades?
Porque, no fim das contas, é isso: a gente está levando dificuldades para o nosso público, para o nosso cliente final.
________________________________________
[Sandy]
No fim do dia, acho que as palavras-chave deste episódio, para mim, são “escuta ativa”. Ouvir atentamente o usuário, seja por feedback, seja por entrevistas ou por testes.
E lembrar que acessibilidade é a jornada como um todo: é o físico, o digital e o conteúdo. É a autenticação, é o atendimento.
Então, nada adianta você ter um site ok se todos os recursos de terceiros presentes nele, seja um documento, seja um recurso de autenticação, como comentamos aqui, acabam sendo barreiras para o seu público-alvo.
________________________________________
[Sidney]
E, na verdade, a gente quer proporcionar ao usuário uma boa experiência e uma sensação agradável depois de passar pelo nosso site: “Opa, busquei o que eu queria, fiz o que eu precisava e está tudo certinho.”
Se a experiência é prejudicada por falta de acessibilidade ou por causa desses elementos críticos, então ela não será tão agradável assim. E, certamente, entre o nosso site e outro com o mesmo conteúdo, o usuário pode preferir acessar esse outro site, que proporciona o mesmo conteúdo, mas com uma experiência mais agradável.
________________________________________
[Reinaldo]
Bom, esse foi o último episódio da nossa série de videocasts sobre os requisitos e recomendações da norma ABNT 17225.
Você pode revisar esse conteúdo quando quiser, desde os episódios deste podcast até os cursos e tutoriais que temos disponíveis online.
E peço também que você compartilhe para que a gente possa atingir um público muito maior e realmente transformar a acessibilidade na web no Brasil.
Obrigado, gente!