Transcrição Episódio 8 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]
Oi, pessoal! Eu sou o Reinaldo Ferraz, especialista em acessibilidade digital do Ceweb.br.
Eu sou um homem branco, de cabelos castanho-claros e lisos, com uma barba que já está ficando branquinha, uma barbinha cerrada, e estou usando uma camiseta preta com o logo do Ceweb.
Hoje eu estou aqui com um time de peso de especialistas em acessibilidade digital, e queria que eles se apresentassem para a gente começar a nossa conversa.
________________________________________
[Cláudia]
Olá, eu sou a Cláudia Martin Nascimento.
Sou uma mulher de pele clara, tenho cabelos castanhos escuros na altura dos ombros, olhos castanhos escuros e uso óculos. Estou vestindo uma camiseta azul com um casaquinho preto.
Sou designer por formação e trabalho com acessibilidade há mais ou menos 13 anos, na empresa Acesso para Todos, da qual sou cofundadora.
________________________________________
[Sandy]
Oi, pessoal, tudo bom? Eu sou a Sandyara, mais conhecida como Sandy.
Sou uma mulher branca, de cabelos castanhos na altura do queixo, com mechas desbotadas na lateral direita. Tenho sardas abaixo dos olhos e hoje estou vestindo uma camiseta preta de gola alta com um colar colorido de estrelinhas.
Sou especialista em design de produto, atuando especificamente em acessibilidade, e venho trabalhando em empresas do setor privado, principalmente do setor financeiro e bancário.
________________________________________
[Sidney]
Bem, eu sou o Sidney Tobias de Souza. Sou um homem de 59 anos, de 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 a gente vai falar sobre interação por teclado. Esse é um tema muito importante para a acessibilidade, especialmente porque a navegação por teclado possibilita a navegação por toques, seja utilizando o próprio teclado, com a tecla TAB, ou por toques e gestos no smartphone.
Então, a gente vai falar bastante sobre isso e sobre os impactos que essa navegação pode trazer para a acessibilidade.
Bom, trazendo aqui um contexto introdutório e falando um pouco sobre a importância dessa navegação por teclado: hoje em dia é muito comum a gente ter várias formas de navegação, e aí você pode perguntar: “Mas por que necessariamente falar de teclado? Para que a gente vai usar um teclado, pensando que a maioria das pessoas usa smartphones e tem outros recursos para navegar?”
A navegação por teclado é muito importante porque ela possibilita justamente essa navegação por toques. A gente navega tanto pelas teclas do teclado quanto por toques e gestos de swipe no celular. Assim, vamos navegando pelos itens interativos, e essa navegação é muito importante para as tecnologias assistivas. Por isso, a gente reforça a importância do uso dessa técnica.
E aí eu já queria abrir a conversa para vocês, porque vocês participaram da construção dessa norma da ABNT. Queria perguntar como essa norma endereça as questões relacionadas à navegação por teclado e o que ela aborda especificamente.
________________________________________
[Cláudia]
Então, vamos lá. A interação por teclado, como você falou, Reinaldo, é um dos princípios fundamentais para a acessibilidade, porque existem muitas pessoas que não conseguem navegar utilizando dispositivos de ponteiro, como o mouse. Tem pessoas que não têm a destreza adequada nas mãos, ou pessoas com baixa visão que não conseguem enxergar onde está o cursor na tela.
Também existem pessoas que têm tremores ou que não possuem movimento nos braços e navegam utilizando um ponteiro de cabeça ou outros recursos.
E, além do toque, como você comentou, existem também os emuladores de teclado, que são sistemas que simulam um teclado. Por exemplo, há pessoas que navegam por comandos de voz ou utilizando um aparelho chamado “sip and puff”, em que, a partir de sopros, a pessoa executa comandos na tela.
Então, quando as funcionalidades estão adequadas para o teclado, elas também funcionam em todas essas ferramentas. Por isso isso é tão importante.
A norma ABNT NBR 17225 traz muitas recomendações e requisitos para garantir que todas as funcionalidades estejam acessíveis pelo teclado, desde a parte visual, com um foco bem definido nos elementos interativos, até o desenvolvimento de componentes customizados para que eles sejam compreensíveis e previsíveis durante a navegação por teclado.
________________________________________
[Sidney]
A gente tem um conjunto muito grande de boas práticas dentro desse bloco de informações para tornar a navegação realmente possível para todas as pessoas, permitindo que elas consigam realizar suas atividades com autonomia e segurança.
Eu, por exemplo, utilizo sempre o teclado para navegar, porque não uso o mouse. Como sou usuário de leitor de telas e uma pessoa cega, o teclado é fundamental para mim.
Então, vou navegando pela tecla TAB, usando também “Shift + TAB”, e caminhando pelos elementos clicáveis. Se isso não for possível, a minha navegação fica prejudicada. Se eu não conseguir, por exemplo, chegar aos elementos e componentes que estou buscando na tela utilizando apenas o teclado, isso dificulta bastante a experiência.
A pessoa com baixa visão também necessita desse recurso. Quando o foco se posiciona corretamente, ela consegue identificar onde está e qual ação vai executar.
________________________________________
[Sandy]
Eu, como mulher autista, utilizo muito o teclado para uma navegação mais dinâmica, a fim de entender quais são os itens interativos daquela página. É como se fosse um escaneamento visual, digamos assim, feito de forma muito mais rápida.
O teclado também me auxilia bastante no preenchimento de formulários, porque eu tenho mais agilidade na troca entre campos e em outras interações.
Então, não são apenas pessoas com deficiência visual, física ou motora que se beneficiam do uso do teclado. Na verdade, qualquer pessoa pode — e deveria — utilizar esse tipo de navegação.
________________________________________
[Reinaldo]
E, partindo dessa introdução de vocês, especialmente dessa última parte que a Sandy trouxe, eu queria falar sobre uma barreira muito comum na acessibilidade relacionada à navegação por teclado: a ausência de foco visível.
A princípio, a acessibilidade na navegação por teclado não beneficia apenas pessoas que utilizam leitores de tela. Na verdade, ela pode beneficiar um grupo ainda maior de pessoas.
Então, eu queria que vocês comentassem um pouco sobre essa barreira relacionada à ausência de foco visível quando a pessoa navega por teclado.
________________________________________
[Cláudia]
Então, quando a gente está navegando pelo teclado — seja para conhecer uma página, seja porque uma pessoa com baixa visão precisa utilizar o teclado para navegar, ou até porque estamos temporariamente sem conseguir usar o mouse — o foco visível passa a ser fundamental.
Vamos supor que eu esteja navegando por uma página, acompanhando visualmente onde o foco está enquanto passo pelos itens do menu. De repente, esse foco desaparece da tela. Nesse momento, eu fico perdida: “Onde eu estou agora?”. Como vou saber se realmente estou no lugar certo para clicar?
Ou então o foco simplesmente sai de onde eu estava e vai parar lá no rodapé, sem que eu perceba. Por isso, essa questão do foco é tão importante.
Existem vários aspectos relacionados a isso. O primeiro é a aparência do foco. Ele precisa estar claro para que qualquer pessoa consiga perceber onde ele está. E isso pode ser feito, por exemplo, colocando uma borda ao redor do elemento ou alterando a cor para algo bem contrastante.
Além disso, esse foco precisa permanecer visível. Ele não pode ficar obscurecido ou oculto por outro elemento da tela, como uma janela que aparece por cima e encobre o foco. Isso acontece muito, por exemplo, com aquelas janelas de cookies. A pessoa está navegando pelo teclado e simplesmente não consegue mais identificar onde o foco está, porque existe algum elemento cobrindo aquela informação.
Outro ponto importante é que a ordem do foco precisa ser coerente com o que a pessoa vê na tela. Se eu estou navegando pelo menu e, de repente, o foco pula para o rodapé, isso não faz sentido nenhum.
Eu queria até ouvir o Sidney: como é essa navegação para você?
________________________________________
[Sidney]
Já aconteceu comigo de estar navegando por uma página e, de repente, o foco simplesmente desaparecer. Estou em uma determinada seção da página e, sem aviso, o foco vai para outro lugar porque a navegação não seguiu a semântica correta.
Então, eu acabo me perdendo, porque não estou vendo a tela. O meu referencial é justamente onde o leitor de tela está posicionado.
Estou navegando com o teclado, por exemplo, percorrendo os itens de um menu, indo de item em item, e de repente o foco se perde. Nesse momento, eu realmente fico perdido.
________________________________________
[Sandy]
Eu acho que o foco permite que o usuário tenha segurança para entender por onde está navegando e com o que está interagindo.
A mesma coisa já aconteceu diversas vezes comigo. Estou no meio da página, com vários links interessantes, links de artigos, por exemplo, e a ordem do foco simplesmente me direciona direto para o rodapé.
Aí eu fico pressionando TAB várias vezes, esperando que, por algum bug ou comportamento inesperado, eu consiga voltar para o conteúdo. E, às vezes, nem isso acontece.
Isso acaba desestimulando totalmente a experiência como um todo.
________________________________________
[Sidney]
Isso já aconteceu algumas vezes comigo também: o foco me joga de volta para o topo da tela e eu preciso começar toda a navegação de novo.
Isso dá uma canseira enorme.
________________________________________
[Reinaldo]
Tudo isso que a gente está comentando envolve a ordem dos itens na navegação, e isso considerando ainda que existe uma referência visual.
Agora, imagina no caso de uma pessoa usuária de leitor de tela que está navegando e não encontra esse conteúdo. Quando você navega por teclado e consegue ver a tela, percebe que saiu do topo e foi parar no rodapé. Se o foco está visível, você consegue pensar: “Opa, espera aí, tem alguma coisa errada”.
Mas imagina quando não existe essa referência visual. A chance de se perder na navegação é muito maior.
E aí eu queria seguir para uma segunda barreira relacionada à navegação por teclado: situações em que determinados elementos recebem foco, mas não têm propósito ou não permitem interação.
Queria que vocês explicassem um pouco melhor essa barreira de estar navegando por teclado, encontrar um elemento que recebe foco e perceber que ele não tem nenhuma função prática ou não permite nenhuma interação.
________________________________________
[Cláudia]
Imagine uma pessoa que navega utilizando um leitor de telas e está percorrendo os elementos da página pelo teclado.
De repente, o leitor de tela posiciona o foco em algo que não representa nada: não é um botão, não é um link, não é um campo de formulário. A pessoa tenta clicar, pressiona “Enter”, e nada acontece.
Às vezes, o foco pode até ficar preso naquele elemento, o que torna a experiência ainda pior.
Esse problema acontece porque alguns desenvolvedores acabam colocando foco em elementos que não são, de fato, elementos de interação.
Sidney, você quer comentar um pouco sobre a sua experiência com isso?
________________________________________
[Sidney]
Sim, isso acontece com uma certa regularidade.
Estou navegando usando o teclado e, de repente, o foco para em um elemento que não representa nada. Às vezes é apenas um elemento gráfico que recebeu foco e aí eu fico na dúvida: “Opa, será que essa é a ação que eu estou procurando?”
Como o foco ficou parado ali e eu não tenho nenhuma identificação clara, começo a usar as setas direcionais para tentar entender, pelo contexto, o que é aquilo. Mas, normalmente, não é nada útil, e eu só acabo perdendo tempo.
Então, isso é bem frustrante.
________________________________________
[Sandy]
É preciso praticamente adivinhar para entender o que está naquele contexto. E isso quando a pessoa não precisa recorrer à ajuda de alguém, o que acaba sendo ainda mais frustrante.
________________________________________
[Sidney]
Pois é.
________________________________________
[Cláudia]
É preciso praticamente adivinhar para entender o que está naquele contexto. E isso quando a pessoa não precisa recorrer à ajuda de alguém, o que acaba sendo ainda mais frustrante.
Pois é. E por que isso acontece? Porque alguns desenvolvedores acreditam que, para o leitor de telas conseguir interpretar os componentes da tela, é necessário colocar foco em tudo. Então, acabam adicionando foco em elementos que não deveriam recebê-lo.
Só que os leitores de tela já possuem um sistema de navegação bastante sofisticado, não é, Sidney? Eles conseguem percorrer elementos como tabelas, listas e outras estruturas da página mesmo quando esses elementos não são interativos.
Por isso, a ideia é que o foco fique restrito apenas aos elementos que realmente permitem interação.
Sidney, você quer contar um pouco como funciona essa leitura com o leitor de telas?
________________________________________
[Sidney]
Sim. Então, por exemplo, eu estou navegando com o teclado e o primeiro elemento de interação que o leitor de tela encontra é um link. Nesse caso, ele informa o nome do link e também diz se aquilo é um link, um botão, uma caixa de seleção ou uma caixa combinada.
Ele vai fornecendo todas essas informações para mim, e eu vou selecionando aquilo que quero acessar. Assim, consigo navegar e descobrir o que existe na página.
Quando o leitor de tela, por conta do foco, se posiciona em um elemento que não é clicável e não representa um elemento de interação, aquilo não tem utilidade nenhuma para mim. Na prática, eu só perdi tempo ali.
________________________________________
[Sandy]
Eu vejo que isso também acontece com frequência em projetos de desenvolvimento. E, muitas vezes, não é nem por mal. Às vezes é simplesmente uma sujeira de código.
Existia alguma funcionalidade relacionada àquele bloco específico que, em determinado momento, deixou de existir, mas parte da estrutura acabou permanecendo ali e isso passou, infelizmente, pelo processo de qualidade.
Em outros casos, a equipe importa um template pronto de alguma biblioteca, um modelo inteiro, e acaba não havendo um cuidado maior ou um processo de validação para entender como aquela experiência realmente funciona na prática.
E isso acontece não apenas com elementos gráficos, mas também com aqueles elementos “fantasmas”, que recebem foco, mas não representam absolutamente nada.
Por isso, é muito importante que, independentemente de qualquer mudança no código ou da adoção de recursos de terceiros, como bibliotecas e componentes prontos, exista pelo menos um teste mínimo de qualidade para validar o que está sendo exibido na tela e verificar se aquilo faz sentido para quem utiliza leitor de telas.
________________________________________
[Reinaldo]
Vocês tocaram em um ponto interessante: a situação em que a pessoa está navegando e, de repente, passa por algo que nem aparece na tela e que, na prática, não tem nenhuma função.
Mas agora eu queria falar sobre uma outra questão que também costuma aparecer na navegação por teclado: quando existe algum elemento que bloqueia completamente a navegação.
A pessoa está navegando normalmente e, de repente, chega a um campo de formulário ou a algum componente específico em que simplesmente fica presa. Ela não consegue sair dali usando o teclado.
Queria que vocês comentassem um pouco sobre essa barreira e sobre o impacto que esse tipo de situação pode trazer para pessoas com deficiência.
________________________________________
[Cláudia]
Eu acho que o Sidney pode contar um pouco para a gente como é essa experiência.
Existe a questão do bloqueio, quando o foco do usuário fica preso em um determinado componente e a pessoa simplesmente não consegue sair dali usando o teclado.
Também existem situações em que a navegação é interrompida por algum comportamento específico da interface. Isso acontece muito quando funcionalidades são criadas pensando apenas em eventos de mouse.
Um exemplo clássico é aquele menu que só abre um submenu quando a pessoa passa o mouse por cima, ou um botão que expande determinado conteúdo apenas no mouse over.
Quem não utiliza mouse acaba não conseguindo acessar esse conteúdo e pode deixar de encontrar informações importantes simplesmente porque ficou impedido de chegar até elas.
________________________________________
[Sidney]
Às vezes, por exemplo, aparece um pop-up e o foco fica preso nele ou em algum outro elemento da tela. A pessoa tenta sair dali e simplesmente não consegue.
Isso acaba gerando um certo desespero. Você começa a pressionar TAB, depois ESC, e, no final das contas, acaba apelando para um “CTRL + Home” para voltar ao topo da página e tentar sair daquela situação.
Então, isso realmente é muito confuso, porque a navegação acaba sendo interrompida completamente. Você estava navegando tranquilamente pela página e, de repente, alguma parte fica bloqueada e impede a continuidade da interação.
________________________________________
[Reinaldo]
A Cláudia começou a falar sobre essa questão da interação baseada no uso do mouse e sobre conteúdos que aparecem apenas quando utilizamos esse recurso.
E eu queria trazer uma outra barreira relacionada a conteúdos adicionais exibidos com o passar do mouse.
Existem aplicações em que, tanto pelo foco do teclado quanto pelo mouse over, aparece algum conteúdo complementar, algum botão ou informação adicional. O problema é que, dependendo da velocidade com que a pessoa movimenta o mouse — ou da forma como realiza esse movimento — ela simplesmente não consegue acessar aquele conteúdo.
A mesma situação acontece na navegação por teclado. Alguns conteúdos aparecem quando recebem foco, mas, no momento em que a pessoa tenta acessá-los, ela acaba se perdendo ou o conteúdo desaparece.
E aí fica a pergunta: como a acessibilidade funciona em uma situação dessas?
________________________________________
[Cláudia]
Esse é um comportamento muito comum hoje em dia na web. A pessoa coloca foco em um elemento ou passa o mouse sobre ele e, então, abre um tooltip, uma pequena janela não modal com conteúdo adicional, ou até um menu em cascata.
O problema é que, muitas vezes, quando a pessoa tenta acessar esse conteúdo, ele simplesmente fecha. Aí ela precisa começar tudo de novo, tenta novamente, e o conteúdo fecha outra vez.
É uma experiência horrível.
A norma fala bastante sobre isso. O ideal é evitar esse tipo de comportamento, porque existem pessoas que simplesmente não vão conseguir acessar esse conteúdo adicional. Isso pode acontecer tanto com alguém que navega pelo celular, usando toques, quanto com uma pessoa que utiliza teclado.
Mas, caso esse tipo de conteúdo exista, alguns cuidados precisam ser tomados.
Por exemplo: se uma janela, tooltip ou conteúdo complementar for exibido, ele deve permanecer visível enquanto a pessoa estiver interagindo com ele. O conteúdo não pode desaparecer antes de a pessoa decidir sair dali ou retirar o foco.
Além disso, a interface deve permitir que o usuário feche esse conteúdo sem precisar perder o foco. Isso pode ser feito, por exemplo, com um botão de “fechar” ou utilizando a tecla ESC, de uma forma simples e acessível.
Queria ouvir a Sandy sobre a experiência dela com esse tipo de comportamento.
________________________________________
[Sandy]
Eu sou muito a favor da ideia de que, se existe uma informação — independentemente de ela ser complementar ou não — a pessoa precisa ter controle sobre quando quer acessá-la ou visualizá-la.
Acho que todo mundo já passou pela experiência de estar em um site ou aplicativo, alguma coisa desviar a atenção e, naquele milésimo de segundo, a informação desaparecer porque a pessoa esbarrou no mouse, tocou em outra área da tela ou simplesmente não estava em um bom momento.
Isso acontece muito. E, às vezes, é justamente essa informação complementar que a pessoa precisava para concluir uma jornada ou ter uma experiência realmente completa.
Então, eu fico muito ansiosa quando uma informação depende exclusivamente de um gesto específico, como um mouse over.
E isso sem contar situações em que eu simplesmente não quero navegar usando mouse. Às vezes estou com tendinite ou algum desconforto e prefiro navegar pelo teclado.
Nesses casos, é muito frustrante perceber que determinada informação só pode ser acessada daquela forma específica.
________________________________________
[Sidney]
E existe uma situação ainda pior: quando a pessoa nem consegue acionar aquele recurso e sequer sabe que existe uma informação disponível ali. Nesse caso, ela simplesmente perde aquela informação.
No meu caso, como eu não consigo ver se existe algo que expande ou revela conteúdo adicional, se eu não conseguir ativar aquele elemento, eu vou perder completamente aquela informação.
________________________________________
[Reinaldo]
E acho que existe ainda uma questão adicional: esse tipo de recurso simplesmente não funciona em telas de smartphone. No celular, você não tem o comportamento de “passar o mouse” sobre um elemento.
Então, isso acaba criando mais uma barreira para as pessoas usuárias e, na verdade, também vira um problema para o próprio desenvolvedor, porque ele vai precisar pensar em como adaptar aquele menu expansível ou aquele conteúdo adicional que aparece no computador para um contexto mobile.
Ele terá que repensar como esconder ou exibir esse conteúdo e, principalmente, como garantir que ele continue acessível para quem está utilizando a aplicação.
Ou seja, acaba sendo necessário criar outra hierarquia de informação e outro fluxo de interação. Por isso, muitas vezes, é melhor pensar corretamente nessa estrutura desde o início — ou até evitar esse tipo de comportamento.
Boa. E aí, uma outra barreira que a norma ABNT também aborda é a dos atalhos de teclado que utilizam tecla única. É um caso bem específico.
Cláudia, eu queria que você começasse explicando o que é esse tipo de atalho e qual é a barreira de acessibilidade envolvida nisso.
________________________________________
[Cláudia]
Quando a gente fala de atalhos de teclado, isso costuma ser algo positivo. Todo mundo provavelmente já acessou algum site que oferece atalhos para facilitar a navegação, e isso realmente ajuda bastante.
Mas é preciso tomar cuidado com o tipo de atalho criado.
Existe uma situação específica em que determinada funcionalidade é ativada por uma única tecla — por exemplo, apenas um número, uma letra ou um caractere especial. Nesse caso, basta pressionar aquela tecla para alguma ação acontecer: mudar algo na tela, excluir um item, enviar uma informação e assim por diante.
À primeira vista, isso pode parecer uma boa ideia, principalmente pensando em pessoas com dificuldades motoras, porque exigiria menos combinações de teclas. Só que essas mesmas pessoas podem ter dificuldade para pressionar exatamente a tecla desejada.
Às vezes a pessoa utiliza um ponteiro de cabeça, possui tremores nas mãos ou outra condição que faz com que ela pressione a tecla errada sem querer. E, nesse cenário, uma ação importante pode ser executada acidentalmente.
Por isso, a recomendação da ABNT é evitar atalhos de tecla única. E, caso esse tipo de atalho exista, a pessoa usuária deve poder desativá-lo ou remapeá-lo para uma combinação que funcione melhor para ela.
O ideal é que os atalhos utilizem teclas modificadoras, como ALT, Ctrl ou Shift. Um exemplo clássico é o atalho “Ir para o conteúdo”, que pode utilizar uma combinação como “ALT + 1”, dependendo do navegador.
Esse é o modelo mais seguro e recomendado.
________________________________________
[Sandy]
Nossa, imagina, por exemplo, definir um atalho na letra “S” e, enquanto eu preencho um formulário com o meu nome, acabar ativando essa função sem querer. É horrível.
________________________________________
[Sidney]
Outro problema acontece quando a tecla escolhida para um atalho da aplicação coincide com um atalho já utilizado pelo leitor de tela.
Nos leitores de tela existem várias teclas de navegação rápida. Por exemplo: a tecla “B” pode ser usada para navegar entre botões, “H” para navegar entre cabeçalhos, e assim por diante. Ou seja, são atalhos acionados por uma única tecla.
Então, se o desenvolvedor escolhe uma dessas mesmas teclas para executar alguma função da interface, isso pode gerar conflito com os comandos do leitor de tela e causar vários problemas durante a navegação.
Por isso, também é importante ter esse tipo de cuidado ao definir atalhos de teclado.
________________________________________
[Reinaldo]
E eu acho que a chance de isso acontecer é grande, né, Sidney? Porque existem muitos atalhos de teclado nos leitores de tela, não é?
________________________________________
[Sidney]
Sim, existem muitos. Há teclas de atalho para navegar por links, botões, tabelas, cabeçalhos, itens de lista, listas, caixas combinadas, caixas de seleção, botões de opção e campos editáveis.
Então, são muitos atalhos. Existem vários outros também, seria bastante coisa para listar aqui.
Por isso, a chance de escolher justamente uma tecla que já é utilizada pelo leitor de tela é muito grande. Então, o ideal é realmente utilizar uma tecla modificadora junto ao atalho.
________________________________________
[Reinaldo]
Acho que, considerando a quantidade de atalhos existentes, não sobram muitas opções de teclas disponíveis. E esse detalhe que a Sandy comentou eu nunca tinha parado para pensar: a questão de digitar o próprio nome.
Imagina estar preenchendo um formulário, pressionar uma tecla normalmente durante a digitação e, de repente, o sistema começar a executar uma ação simplesmente porque aquela tecla foi definida como atalho. Isso é muito interessante — e problemático também.
Outra barreira que eu queria trazer para a nossa discussão é a das funcionalidades que não podem ser acessadas por teclado.
Pensando em um exemplo clássico: você vai comprar uma passagem aérea ou uma passagem de ônibus e precisa escolher o assento. Só que essa funcionalidade não está disponível para navegação por teclado.
Você não consegue acessar os assentos usando TAB ou outros comandos de teclado. A interação depende exclusivamente do mouse.
E aí, naturalmente, as pessoas que navegam por teclado acabam não conseguindo utilizar esse recurso.
Então, queria que vocês comentassem um pouco sobre essa barreira também.
________________________________________
[Cláudia]
Como a gente comentou no começo, todas as funcionalidades precisam ser acessíveis pelo teclado, sem exceção.
A única exceção acontece quando existe uma funcionalidade que realmente não pode ser executada de outra forma além do uso de um dispositivo específico.
Um exemplo disso é um desenho à mão livre. Imagine um software ou aplicativo de pintura em que o movimento da mão, a pressão ou a velocidade do traço influenciam diretamente o resultado final. Nesse caso, não existe uma forma equivalente de reproduzir essa experiência apenas com o teclado. Aí, sim, o uso de uma caneta ou outro dispositivo específico se torna necessário.
Mas, fora situações assim, todas as funcionalidades devem funcionar pelo teclado. Isso é uma exigência tanto da norma ABNT quanto da WCAG. Tem que seguir.
________________________________________
[Sidney]
Se eu quero comprar uma passagem e existe um mapa de assentos que não pode ser acessado pelo teclado, eu passo a depender de outra pessoa para concluir a ação. E, nesse momento, já não existe mais autonomia — e, consequentemente, já não estamos falando de acessibilidade.
Por isso, é importante criar formas de permitir que a pessoa consiga selecionar elementos usando o teclado, seja em um mapa de assentos de teatro, avião, ônibus ou qualquer outro componente semelhante.
O importante é garantir que a pessoa consiga navegar até aquele elemento pelo teclado e selecionar exatamente aquilo que deseja.
________________________________________
[Sandy]
E, na maioria das vezes em que esse tipo de problema acontece, são situações que poderiam perfeitamente ser navegáveis por teclado.
Acho que isso passa muito por uma questão de abstração. No caso da compra de passagens, por exemplo, normalmente as empresas tentam criar algo muito visual, simulando o desenho de um avião ou de um ônibus.
Mas, às vezes, basta abstrair um pouco a interface, pensar na estrutura semântica, remover mentalmente a camada visual e refletir sobre como aquela interação deveria funcionar.
O que aqueles assentos representam, semanticamente? Seriam caixas de seleção? Botões de opção? Qual seria o equivalente mais adequado para aquela interação?
Quando a gente começa a pensar dessa forma, geralmente fica muito mais fácil construir uma experiência realmente acessível.
________________________________________
[Cláudia]
Outro ponto muito importante de considerar é que algumas pessoas têm mais dificuldade para digitar ou inserir informações utilizando determinados meios, como toque ou mouse.
Por isso, a ABNT também traz uma recomendação importante: permitir que a pessoa possa alternar entre diferentes dispositivos para inserir informações.
Há pessoas, por exemplo, que usam o celular, mas têm dificuldade com a navegação por toque. Nesses casos, elas conectam um teclado ao smartphone. E, quando isso acontece, a aplicação precisa continuar funcionando normalmente.
Ou seja, mesmo que a pessoa alterne entre dispositivos — usando toque em alguns momentos e teclado em outros — todas as funcionalidades devem permanecer acessíveis.
A gente não pode limitar a experiência a um único tipo de dispositivo ou forma de interação.
________________________________________
[Reinaldo]
Legal! Seguindo agora por um outro caminho, queria falar sobre componentes customizados — principalmente aqueles que não têm um comportamento previsível ou não oferecem instruções claras de uso.
Imagine a situação de acessar uma aplicação que possui um componente mais complexo implementado, como um mapa, um slider ou qualquer outro recurso mais elaborado.
Só que não existe uma referência visual clara, não existem instruções e a pessoa simplesmente não sabe como utilizar aquele componente.
Queria que vocês comentassem um pouco sobre esse tipo de comportamento e sobre como podemos tornar esses componentes mais acessíveis.
________________________________________
[Cláudia]
Então, sempre que possível, a gente deve utilizar a semântica nativa do HTML, como já comentamos anteriormente. Mas existem alguns componentes em que isso não é possível, justamente porque eles são customizados — e, em alguns casos, realmente precisam ser.
Nessas situações, é necessário criar a especificação correta para que a pessoa consiga compreender o que é cada elemento dentro daquele componente.
Por exemplo, uma janela de guias ou um carrossel. A pessoa precisa conseguir navegar por esse componente e entender o que está acontecendo ali.
Isso pode ser feito oferecendo instruções sobre como operar o componente, principalmente quando ele é mais complexo. Além disso, é importante utilizar atributos ARIA e rótulos descritivos, para que toda a interação se torne mais intuitiva e previsível dentro das funcionalidades daquele componente.
________________________________________
[Sidney]
Quando tudo isso que você comentou é levado em consideração — os rótulos, as descrições e toda essa estrutura — eu consigo, usando o leitor de tela, por exemplo, acessar um carrossel, navegar por ele e entender qual informação está disponível em cada item.
Quando isso não é feito, a experiência fica realmente confusa.
Você está tentando localizar uma informação dentro do carrossel e, de repente, ele muda automaticamente, a informação desaparece ou você perde o contexto do que estava lendo. Isso acaba sendo muito ruim para a navegação.
________________________________________
[Sandy]
Eu acho importante que, quando a gente fala de componentes customizados, exista sempre uma pesquisa prévia sobre padrões já utilizados pelo mercado e sobre como esses componentes vêm sendo adotados.
Também é importante realizar pesquisas com usuários para entender qual é a melhor forma de interação e quais comportamentos já são familiares para as pessoas usuárias.
Porque, muitas vezes, a acessibilidade também passa por previsibilidade e consistência na experiência.
________________________________________
[Reinaldo]
E acho interessante falar sobre esses componentes porque, muitas vezes, eles parecem algo simples. A pessoa pensa: “Ah, mas todo mundo está usando esse tipo de componente, existe até uma biblioteca pronta para isso”.
Só que, na prática, não é tão simples assim.
Às vezes, na primeira tentativa de implementação, a gente pode acabar criando um problema sério de acessibilidade. Por isso, é sempre importante existir orientação, documentação e informações claras sobre como aquele componente deve ser utilizado.
Essa talvez seja uma das partes mais importantes quando pensamos em elementos que serão adicionados às nossas aplicações e que podem alterar a navegação tradicional das pessoas usuárias.
Bom, a gente já está chegando ao final deste episódio. Tínhamos bastante coisa para conversar sobre interação por teclado. É um tema bastante amplo, mas acho que ficou muito claro que precisamos sempre priorizar o acesso da pessoa usuária.
Na navegação por teclado, a pessoa deve conseguir acessar todos os itens necessários para concluir sua navegação. Isso precisa ser claro, perceptível e previsível. Ela deve conseguir entender por onde está navegando e com quais elementos está interagindo.
Então, todas essas boas práticas que comentamos aqui — como foco visível, formas adequadas de fornecer informações em componentes customizados e os cuidados necessários para a navegação por teclado — são fundamentais para o desenvolvimento de aplicações mais acessíveis.
Como mensagem final, fica justamente o incentivo para que essas boas práticas sejam consideradas e aplicadas no dia a dia.
A gente falou sobre isso aqui de maneira mais introdutória, mas já existe bastante conteúdo publicado sobre a norma ABNT, inclusive com explicações técnicas mais detalhadas sobre como implementar esses recursos de forma acessível.
Então, lá na página do Todos na Web, vocês podem encontrar todos esses materiais disponíveis.
E, para encerrar, eu queria chamar cada um de vocês para fazer um comentário final sobre o episódio de hoje.
________________________________________
[Cláudia]
Acho importante lembrar sempre da importância de criar interfaces visualmente atraentes, bonitas e modernas, mas sem deixar de considerar o código e refletir: “Será que uma pessoa que não está enxergando a minha tela, ou que desativou todos esses estilos visuais, ainda vai conseguir compreender essa informação?”
É muito importante considerar que existem pessoas com necessidades, capacidades, recursos e dispositivos diferentes. E toda essa variedade pode acabar criando barreiras de acessibilidade se a gente não tomar cuidado com a forma como desenvolve os nossos códigos.
Por isso, precisamos sempre considerar essa diversidade de formas de interação e de acesso.
________________________________________
[Sandy]
O meu recado final é justamente fazer esse exercício de abstração.
Eu sei que, no dia a dia, a gente acaba ficando muito direcionado para a estética visual, para recursos chamativos ou para formas de navegação mais comuns, como mouse e toque.
Mas vale muito a pena parar alguns minutos e pensar: “E quem não utiliza esse tipo de recurso? E quem não vê? E quem não ouve? Qual é a melhor forma de essa pessoa interagir com o meu conteúdo?”
E, novamente, se você não souber, não conhecer ou tiver qualquer dúvida, consulte as pessoas usuárias.
________________________________________
[Sidney]
Exato. Todo o conteúdo que a gente coloca em um site e publica é pensado para alcançar a pessoa usuária final.
E é importante lembrar que, entre esse público, existem pessoas cegas, pessoas surdas e pessoas com diferentes formas de interação com a tecnologia.
Então, não impeça que essas pessoas tenham acesso à informação que você publicou ou consigam interagir com aquilo que foi disponibilizado no site.
Por isso, é importante ter esse cuidado de garantir que todos os elementos de interação possam ser acessados via teclado, que o foco esteja sempre bem definido e que a pessoa não se perca durante a navegação.
São boas práticas que tornam a experiência mais acessível sem excluir ninguém.
________________________________________
[Reinaldo]
Bom, pessoal, chegamos ao fim deste episódio do podcast Todos na Web.
Muito obrigado pela participação de vocês, pela conversa e pelas contribuições ao longo deste episódio.
E obrigado também a quem acompanhou a gente até aqui. Até a próxima!