Transcrição Episódio 14 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á, pessoal!
Eu sou Reinaldo Ferraz, especialista em acessibilidade digital do Ceweb.br. Sou um homem branco, de cabelo castanho-claro liso, olhos verdes, tenho a barba cerrada, que já está ficando branquinha, e estou usando uma camiseta preta com o logo do Ceweb.
Hoje estou aqui com a Cláudia e com o Sidney, que são especialistas em acessibilidade digital e participaram ativamente da construção da norma da ABNT.
Sejam muito bem-vindos a este episódio. Gostaria que vocês também se apresentassem antes de a gente começar.
________________________________________
[Cláudia]
Olá, muito obrigada! É um prazer estar aqui.
Eu sou Cláudia Martin Nascimento. Sou uma mulher de pele clara, tenho cabelos castanho-escuros, longos, um pouco abaixo dos ombros, olhos castanho-escuros, uso óculos e estou vestindo uma camiseta azul com um casaquinho preto por cima.
Me formei em Design e trabalho com acessibilidade há mais ou menos 13 anos. Hoje trabalho na Acesso para Todos, que é a minha empresa e tem como foco a acessibilidade digital.
________________________________________
[Sidney]
Olá, pessoas! Eu sou Sidney Tobias. Sou um homem pardo, de cabelos e olhos castanhos, nariz núbio, e estou vestindo uma camisa cinza.
Sou analista de sistemas da Prodam e consultor de acessibilidade digital e comunicacional da Secretaria Municipal da Pessoa com Deficiência.
Estou feliz de estar aqui com vocês.
________________________________________
[Reinaldo]
Legal. Hoje a gente vai falar sobre codificação e marcação semântica. Mais especificamente, sobre como a gente pode garantir que o código que desenvolve não tenha barreiras de acesso para pessoas com deficiência. A ideia aqui é aproveitar as dicas que a Cláudia e o Sidney têm para compartilhar sobre esse tema.
Só para fazer um contexto introdutório: quando um site não está bem codificado, ele pode apresentar uma série de barreiras para as pessoas com deficiência. Imagine uma situação em que você está navegando e encontra caracteres estranhos ou até um conteúdo em áudio em outro idioma. São situações que podem atrapalhar a navegação e a compreensão de pessoas com deficiência.
Então, a ideia aqui é abordar os tópicos que a norma aponta sobre marcação e codificação semântica, que ajudam a eliminar barreiras de acesso para as pessoas com deficiência.
Eu já queria começar perguntando para vocês: por que a codificação e a marcação semântica são tão importantes para a acessibilidade?
________________________________________
[Cláudia]
Bom, quando a gente constrói os comportamentos e as funcionalidades das nossas páginas com código de qualidade e com a marcação semântica correta, usando os elementos certos, isso traz uma compatibilidade muito maior com diferentes agentes de usuário, sejam navegadores ou tecnologias assistivas utilizadas por pessoas com deficiência.
Então, um código de qualidade é fundamental para que todas as pessoas consigam compreender as informações e acessar os conteúdos com autonomia, segurança, conforto e de forma previsível.
A ABNT NBR 17225 traz diversas recomendações e requisitos para ajudar na construção de um código de qualidade, como a criação de títulos descritivos para as páginas, a marcação e a declaração do idioma da página e dos conteúdos, além de permitir a ampliação da tela por meio, por exemplo, do zoom do navegador.
Temos diversas boas práticas e recomendações que ajudam a tornar esse código mais robusto e de qualidade, para que seja compatível com diferentes tecnologias.
________________________________________
[Sidney]
Quando a gente está na web, navegando por diversas páginas, acaba criando um padrão de navegação. Então, tudo se torna previsível, e você passa a esperar esse comportamento.
Quando um site não leva em consideração todos esses requisitos, ele foge desse padrão. A navegação fica confusa e desconfortável.
________________________________________
[Reinaldo]
Bom, então, já começando a falar sobre as barreiras relacionadas a esse tópico, queria começar pelos títulos de páginas e frames.
Para quem não precisa olhar o código para identificar, o título é aquilo que normalmente aparece na aba do navegador. É o título da página.
Agora imagine a barreira de ter diversas abas abertas e não saber em qual delas você estava, por exemplo, pagando uma conta ou procurando alguma informação importante. Ou então estar procurando a página de um evento, com várias abas abertas, e não conseguir identificar qual delas é a correta.
É a mesma coisa com os frames. Frames são conteúdos que a gente incorpora na página web, como um vídeo do YouTube ou um componente de outro site. Eles também precisam ter um título para serem identificados por pessoas com deficiência.
Queria que vocês comentassem um pouco sobre o impacto dessa questão relacionada aos títulos, tanto de página quanto de frame, e o que a gente pode fazer para que eles fiquem mais acessíveis.
________________________________________
[Cláudia]
Os títulos descritivos das páginas são fundamentais para a localização dos usuários, porque ajudam todas as pessoas a identificar o tipo de conteúdo de cada página.
É exatamente isso que você comentou. A gente está com várias abas abertas e quer saber onde está aquela em que precisava terminar um cadastro. Sem um título descritivo, fica muito mais difícil encontrar.
Para as pessoas com deficiência, isso é ainda mais crítico. O leitor de telas, por exemplo, anuncia primeiro o título da página. Se esse título é vago ou não é descritivo o suficiente, a pessoa precisa entrar na página para descobrir qual conteúdo existe ali e conseguir se localizar.
Por isso, os títulos devem ser curtos, descritivos, únicos e identificar tanto o assunto da página quanto o site ao qual ela pertence. Esse é o ideal.
O mesmo vale para títulos de iframes e frames. Também é importante utilizar títulos descritivos, porque eles ajudam os usuários a identificar que tipo de conteúdo existe ali. Sem esse título, por exemplo, uma pessoa que não enxerga a tela saberá apenas que existe um vídeo, mas não do que ele trata. Ela precisará dar play e assistir a um trecho para descobrir se aquele conteúdo é de seu interesse.
Com um título descritivo, ela consegue identificar isso imediatamente e decidir se quer assistir ao vídeo ou não.
Sidney, quer comentar?
________________________________________
[Sidney]
Quando entro em uma página, a primeira coisa que é lida é o título, ou o leitor de telas informa que não há um título. Quando isso acontece, preciso percorrer a página pelo contexto, pelo conteúdo que ela apresenta, para identificar de qual página se trata.
O mesmo acontece quando estou navegando entre abas abertas. O leitor de telas vai informando para onde fui, mas, se não há título, tudo fica mais difícil.
Por isso, é importantíssimo que as páginas tenham um título, assim como os conteúdos incorporados. Se você colocou um vídeo, por exemplo, ter um título para ele facilita a navegação e deixa tudo mais organizado. Isso é superimportante.
________________________________________
[Reinaldo]
É, e tecnicamente ele fica no topo do código HTML. O elemento “title” é o que aparece no topo do código.
Talvez o maior desafio seja criar um texto descritivo que represente bem o que o usuário vai encontrar naquela página, em vez de simplesmente replicar o mesmo título em todas as páginas, algo que ainda é muito comum acontecer.
________________________________________
[Cláudia]
Sim, o ideal é identificar primeiro o assunto da página e, depois, identificar em que contexto aquele conteúdo está inserido.
Por exemplo, eu estou na página "Trabalhe conosco", dentro do site da empresa “x”. Essas informações precisam estar presentes no título para que o usuário consiga identificar exatamente onde está.
________________________________________
[Reinaldo]
Legal. Agora, passando para a próxima barreira, muita gente não percebe, mas declarar o idioma é algo muito simples. É um atributo simples, mas que tem um impacto muito grande para a acessibilidade.
Queria que vocês comentassem um pouquinho sobre essa questão.
________________________________________
[Cláudia]
É, a declaração de idioma realmente é muito importante, porque é um recurso utilizado por outras tecnologias, como as tecnologias assistivas, para garantir, por exemplo, uma pronúncia correta ou permitir que um player de vídeo apresente as legendas com os caracteres corretos.
O próprio navegador também consegue processar melhor aquele texto e interpretar corretamente o código. Por isso, é muito importante declarar o idioma da página. Fazemos isso por meio do atributo “lang” no HTML.
Também é fundamental declarar trechos da página que estejam em um idioma diferente do idioma principal. Então, se a página está em português, mas existe um trecho em inglês, esse trecho também deve ser identificado com o atributo “lang”.
Quando fazemos isso, um leitor de telas consegue fazer a pronúncia correta da página e, ao chegar nesse trecho em inglês, muda automaticamente a pronúncia para o inglês. Assim, o conteúdo fica muito mais fácil de ser compreendido pelos usuários.
Mas gostaria de ouvir a experiência do Sidney.
________________________________________
[Sidney]
Então, é muito comum encontrar páginas em que o idioma não está definido corretamente. Muitas vezes, por exemplo, a página está marcada como inglês, mas o conteúdo está em português.
Nesses casos, o meu leitor de tela, que está configurado para o português, tenta ler o conteúdo como se estivesse em inglês. Imagine como isso fica: ele pronuncia as palavras com um sotaque completamente inadequado, porque entende que aquele texto está em outro idioma. Isso é bastante desconfortável.
No smartphone é pior ainda, porque a pronúncia fica muito ruim e bastante desconfortável de ouvir.
Por isso, é importante não apenas definir corretamente o idioma da página, mas também identificar trechos em outros idiomas. Como a Cláudia comentou, se existe uma citação ou qualquer outro texto em outro idioma, é preciso declarar esse idioma para que o leitor de tela consiga identificá-lo e fazer a pronúncia correta.
________________________________________
[Reinaldo]
É, isso que vocês pontuaram é muito importante, porque o atributo lang é um atributo global. Isso significa que ele pode ser utilizado em qualquer elemento do HTML. Então, em qualquer bloco de texto, podemos fazer uso desse atributo para declarar o idioma.
E eu acho isso muito interessante, Sidney, porque, na minha experiência usando o leitor de telas para fazer testes de acessibilidade — eu uso o NVDA —, quando essa configuração está correta, ele muda até a voz do sintetizador. Não é simplesmente uma mudança na pronúncia para o inglês; parece até que ele troca para outro perfil de voz.
Isso me ajuda bastante, porque facilita a percepção de que houve uma mudança de idioma. Então, eu fico mais atento ao tipo de conteúdo que será apresentado.
________________________________________
[Sidney]
Exato, é exatamente assim que acontece. O leitor de telas vai mudando a voz e isso faz com que você fique, de fato, mais atento à mudança de idioma e ao conteúdo que está sendo apresentado.
Quando essa configuração não está adequada, o problema fica ainda mais evidente. Por exemplo, quem utiliza o NVDA logo após a instalação, sem fazer nenhum ajuste, costuma ouvir uma voz mais robótica. Se o idioma estiver configurado de forma incorreta, ele passa a ler o português como se fosse inglês. Com essa voz robótica, a experiência fica bem, bem chata.
________________________________________
[Reinaldo]
Bom, passando para a próxima barreira, vamos falar sobre zoom e ampliação.
É muito comum — eu, principalmente, já estou em um ponto em que preciso dar zoom para conseguir enxergar determinados textos e aumentar o tamanho da fonte para ler melhor. Mas é bem frustrante quando fazemos isso e a página quebra: o texto desaparece, fica sobreposto por outros blocos de conteúdo ou surgem outros problemas relacionados à ampliação.
Além disso, o layout responsivo nem sempre funciona de forma adequada.
Queria que vocês comentassem um pouco sobre esse tópico.
________________________________________
[Cláudia]
Eu também já uso o zoom do navegador para enxergar melhor a tela, e isso realmente é uma questão problemática, principalmente para as pessoas com deficiência. Há pessoas com baixa visão que precisam ampliar a tela para conseguir enxergar.
Por isso, precisamos permitir, por meio de um código bem escrito, de boa qualidade e responsivo, que elas utilizem o zoom do navegador sem causar quebras de conteúdo. O conteúdo não pode ficar oculto por outro elemento da página. Às vezes acontece uma sobreposição, em que um elemento aparece por cima do outro, ou então o conteúdo desaparece dentro de um contêiner com posição fixa.
Existem algumas regras importantes para seguir nesses casos. Se uma pessoa ampliar a tela em até 200%, todo o conteúdo, as funcionalidades e os botões devem continuar funcionando, sem perda de informação. Já em uma ampliação de até 400%, não pode haver barra de rolagem em duas dimensões, horizontal e vertical ao mesmo tempo, porque há pessoas que realmente precisam visualizar a tela muito ampliada e têm dificuldade de ler enquanto precisam rolar o conteúdo nas duas direções.
Imagine alguém lendo uma linha de texto. Ela rola a página na vertical e, depois, precisa voltar na horizontal para continuar a leitura. Em seguida, precisa repetir esse movimento várias vezes. Isso torna a navegação muito cansativa.
Para evitar esse problema, usamos medidas relativas em vez de medidas absolutas para tamanhos de texto e de fonte. Isso é feito no CSS e também para os tamanhos dos contêineres de texto.
________________________________________
[Sidney]
A maior reclamação das pessoas com baixa visão é justamente a perda de conteúdo. Às vezes o conteúdo fica quebrado, parte do texto desaparece no final ou alguns botões deixam de aparecer. Tudo isso dificulta muito a navegação.
Imagine uma pessoa que sempre enxergou normalmente, mas que, com o passar da idade, passou a ter uma perda funcional da visão e agora precisa ampliar a tela. Ou então uma pessoa com baixa visão que enxerga apenas cerca de 20% e precisa ampliar bastante o conteúdo para conseguir acessá-lo. Quando existem barras de rolagem horizontal e vertical ao mesmo tempo, ou quando há perda de conteúdo, a navegação se torna muito mais difícil para essas pessoas.
________________________________________
[Reinaldo]
O que mais me irrita nessa questão do zoom é quando ele é bloqueado, inclusive no navegador do celular, e você não consegue fazer o movimento de pinça para aumentar o tamanho das fontes. Na verdade, não é possível ampliar a tela de forma alguma, e esse é um tipo de problema que ainda costuma acontecer.
________________________________________
[Cláudia]
Eu, particularmente, estou passando por uma situação durante os testes de um conjunto de cursos que são abertos em janelas menores. Essas janelas estão com o zoom bloqueado, então não é possível ampliar a tela. Há partes em que o texto é muito pequeno e não dá para enxergar. Como o zoom está bloqueado, também não é possível ampliar a visualização.
Nessas condições, o uso fica praticamente inviável para uma pessoa com dificuldade para enxergar. E, se o contraste ainda não estiver adequado, a situação fica pior ainda.
________________________________________
[Reinaldo]
Nossa! Bom, outra barreira está relacionada à ordem do conteúdo no código.
A gente costuma recomendar que o código seja desenvolvido pensando em uma leitura linear, normalmente de cima para baixo e da esquerda para a direita.
Mas, em alguns casos, principalmente durante a navegação com o leitor de telas, acontece de a pessoa estar em um bloco de conteúdo e, de repente, ser levada para outro bloco que não tem nenhuma relação com o que estava sendo lido anteriormente.
Isso é muito comum de acontecer e também representa uma barreira séria relacionada à codificação.
________________________________________
[Cláudia]
Sim, isso acontece com frequência porque hoje temos recursos muito simples no CSS para posicionar elementos na tela. Conseguimos, por exemplo, pegar um elemento que, no código, está à esquerda e exibi-lo visualmente à direita.
O problema surge quando essa ordem tem significado. Para quem está enxergando, aquele conteúdo faz sentido em uma determinada sequência. Se essa ordem é invertida apenas visualmente, a pessoa que navega com o leitor de telas continuará recebendo o conteúdo na ordem em que ele aparece no código e perderá esse contexto.
Por isso, o ideal é que a ordem em que o conteúdo aparece no código seja equivalente à ordem lógica em que ele é apresentado na tela.
Você quer comentar isso, Sidney?
________________________________________
[Sidney]
Eu já tive a oportunidade de navegar com outra pessoa durante uma compra. Eu estava usando o leitor de telas, enquanto ela acompanhava visualmente a página. O problema é que o que ela via não correspondia exatamente ao que eu estava percebendo pelo leitor de telas. Os conteúdos apareciam em ordens e locais diferentes, e isso gerava bastante confusão.
Às vezes a pessoa dizia: "Olha, está aqui do lado", mas, para mim, aquele conteúdo não estava na posição que ela estava indicando. Isso realmente dificulta a navegação.
________________________________________
[Reinaldo]
Falando agora sobre a próxima barreira, relacionada ao nome acessível diferente do texto visível, eu queria saber por que é tão importante garantir que o nome acessível de um botão, por exemplo, seja exatamente igual ao texto que está visível para o usuário.
Vocês podem comentar um pouco sobre isso?
________________________________________
[Cláudia]
Quando a gente coloca um texto visível em um botão e um nome acessível — que é aquele lido pelas tecnologias assistivas —, é importante que eles sejam iguais. Quando o texto exibido na tela é diferente do que a tecnologia assistiva anuncia, isso pode causar problemas, principalmente para pessoas com baixa visão que utilizam leitores de telas para navegar.
Essas pessoas acompanham a navegação ouvindo o que o leitor de telas anuncia para confirmar que estão no elemento correto antes de clicar. Se elas veem uma informação na tela e o leitor anuncia outra, fica mais difícil ter certeza de que estão no lugar certo e tomar uma decisão com segurança.
Por isso, a recomendação é que, sempre que houver um texto visível, ele seja igual ao nome acessível. Esse é o cenário ideal. Se isso não for possível, o texto visível deve estar contido no nome acessível, de preferência logo no início.
Por exemplo, imagine um botão com o texto "Prosseguir" em uma loja virtual. O leitor de telas poderia anunciar "Prosseguir para a compra". Assim, a pessoa com baixa visão vê o botão "Prosseguir", escuta "Prosseguir para a compra" e consegue relacionar facilmente as duas informações, tendo a certeza de que está no lugar correto para clicar.
________________________________________
[Sidney]
É superimportante que o nome acessível esteja bem definido, porque ele orienta a pessoa durante a navegação. Se eu precisar, por exemplo, preencher um formulário, o nome acessível me ajuda a entender o que deve ser feito e a preenchê-lo da forma correta.
________________________________________
[Reinaldo]
Legal. A próxima barreira está relacionada às mensagens de status.
São aquelas mensagens que aparecem, por exemplo, quando se preenche um formulário ou quando se executa alguma ação na web. Essas mensagens precisam ser acessíveis, ou seja, o usuário precisa saber que elas apareceram.
Ainda é comum encontrarmos modais ou pop-ups que não são anunciados pelos leitores de tela.
Vocês podem comentar um pouquinho sobre isso?
________________________________________
[Cláudia]
Sim. As mensagens de status normalmente são o retorno de alguma ação realizada pelo usuário.
Por exemplo, eu faço uma pesquisa, clico em "Buscar" e recebo uma mensagem como "Foram encontrados X resultados para sua busca" ou "Nenhum resultado foi encontrado".
Essas mensagens precisam ser anunciadas para quem não pode ver a tela, sem que a pessoa tenha que procurar manualmente pelo elemento onde elas aparecem, seja em uma janela modal ou no próprio conteúdo da página.
Para isso, é necessário implementar recursos semânticos no código, de forma que o leitor de telas anuncie automaticamente essa informação ao usuário, sem que ele precise sair procurando o que aconteceu.
Isso vale para mensagens de erro, mensagens de alerta e diversos outros tipos de retorno.
Você quer comentar, Sidney?
________________________________________
[Sidney]
Sim. Quando essa mensagem aparecer, o leitor de telas deve captá-la automaticamente e fazer a leitura. Caso contrário, eu preciso sair do ponto em que estou na página para procurar essa mensagem em algum lugar.
O que normalmente acontece é que eu clico em um botão, a mensagem aparece, mas ela não é anunciada. Aí fica a dúvida: avançou? Não avançou? A ação foi executada?
Essa incerteza prejudica bastante a experiência de uso.
________________________________________
[Cláudia]
O ideal é que a pessoa receba essa mensagem de status e que o foco do teclado seja direcionado para o conteúdo que foi alterado, certo?
________________________________________
[Sidney]
Exato. O foco deve ir para o conteúdo alterado para que a pessoa possa dar prosseguimento à ação ou fazer o que está sendo solicitado pela mensagem, como realizar uma correção, se for o caso.
________________________________________
[Reinaldo]
Bom, queria passar para a próxima barreira, que está relacionada ao propósito dos controles.
Nem sempre um texto ou o ícone de um controle é suficiente para que a gente compreenda o que ele faz. Às vezes, um ícone sem descrição, uma descrição pouco clara ou até um texto muito complexo podem dificultar a compreensão, especialmente para pessoas com deficiência.
Queria que vocês comentassem sobre isso.
________________________________________
[Cláudia]
Sim. Algumas pessoas têm mais dificuldade para compreender textos complexos, imagens, ícones utilizados em uma determinada aplicação ou até mesmo informações apresentadas na página, incluindo números.
Quando identificamos o que um ícone, uma região da página ou um controle representam, ajudamos a tecnologia a oferecer formas mais fáceis para que o usuário compreenda aquela informação.
Por exemplo, imagine que foi utilizado um ícone de casa, mas ele não é facilmente reconhecido como um atalho para a página inicial. Se esse elemento estiver identificado por meio de um rótulo ARIA informando que ele significa "Ir para a página inicial", a tecnologia pode apresentar um ícone mais familiar para aquele usuário.
O mesmo acontece quando não há um ícone e existe apenas um texto no controle. Se esse elemento possui um rótulo adequado, a tecnologia também pode oferecer uma representação mais familiar.
Isso também vale para números. Imagine uma pessoa que tenha dificuldade para interpretar informações numéricas e esteja consultando uma página com a temperatura local em graus Celsius. A tecnologia poderia adaptar essa informação ou complementá-la com uma representação visual simples, como a imagem de uma pessoa com frio quando a temperatura estiver baixa.
Quando indicamos o que cada ícone, controle ou região representa, estamos fazendo mais do que informar sua finalidade. Estamos oferecendo significado dentro daquele contexto, permitindo que as tecnologias adaptem a informação para diferentes modalidades de apresentação e tornem a experiência mais acessível.
________________________________________
[Reinaldo]
É uma forma de comunicação alternativa, não é, Cláudia?
________________________________________
[Cláudia]
Sim!
________________________________________
[Reinaldo]
Bom, agora vamos falar sobre o nome acessível em componentes sem rótulos visíveis.
A gente falou anteriormente sobre nome acessível em componentes que possuem um rótulo visível, mas nem todos os componentes têm esse tipo de identificação. Mesmo assim, precisamos garantir que eles tenham um nome acessível.
O que isso significa? O que a gente precisa fazer para que esses componentes sejam acessíveis?
________________________________________
[Cláudia]
O ideal é sempre ter um rótulo visível. Esse é o cenário ideal. Mas, quando isso não é possível, precisamos incluir um nome acessível.
Por exemplo, se existe um botão de fechar com o texto "Fechar", essa é a melhor solução. Mas, se o botão é representado apenas por um "X", criado com CSS e sem uma imagem, é necessário definir um nome acessível para que a pessoa saiba que se trata de um botão de fechar.
Nesse caso, podemos utilizar um “aria-label” com um texto como "Fechar janela de usuário" ou outra descrição que identifique claramente a ação que aquele botão executa.
________________________________________
[Sidney]
Então, esse nome acessível é muito importante para que todas as pessoas consigam compreender a função daquele botão.
Por exemplo, se estou preenchendo um formulário e os campos não possuem um nome acessível, preciso usar a seta direcional para procurar rótulos e identificar o que deve ser preenchido.
Quando existe um nome acessível, isso deixa de ser necessário. Mesmo que não haja um rótulo visível, para quem utiliza um leitor de telas essa informação é fundamental. Ao navegar pelo formulário, cada campo é anunciado corretamente, permitindo que a pessoa saiba exatamente o que precisa preencher, sem dúvidas.
________________________________________
[Reinaldo]
Bom, agora vamos falar sobre semântica em componentes customizados.
Esses componentes são, por exemplo, carrosséis, “tooltips”, janelas modais e outros elementos que aparecem na tela e oferecem algum tipo de interação. Normalmente, eles são trazidos de bibliotecas ou reutilizados de outros componentes.
Em alguns casos, porém, esses componentes apresentam comportamentos que o usuário não consegue compreender. Ele não sabe se um elemento vai abrir uma janela modal ou se precisa usar as setas direcionais para acessar determinado conteúdo.
Por isso, todos esses componentes devem seguir boas práticas de acessibilidade.
Queria que vocês comentassem sobre isso também.
________________________________________
[Cláudia]
Bom, como a gente já comentou várias vezes neste podcast, o ideal é sempre utilizar elementos nativos. Mas sabemos que existem funcionalidades que surgiram com a evolução da web e com a criação de recursos mais modernos que não possuem uma semântica nativa específica, como acontece com carrosséis, janelas modais ou conjuntos de guias que expandem e recolhem conteúdos.
Nesses casos, é necessário definir a semântica desses componentes e também seus estados por meio da especificação ARIA.
Um carrossel, por exemplo, precisa estar completamente definido. Tudo o que acontece nele deve ser comunicado ao usuário. Também deve ser totalmente acessível por teclado.
Os rótulos precisam ser claros, com descrições como "Ir para o slide anterior" e "Ir para o próximo slide". Além disso, o usuário deve ser informado sobre em qual slide está dentro do conjunto e deve existir um botão para pausar a reprodução, indicando claramente se o carrossel está pausado ou em execução.
Em resumo, é preciso definir corretamente os estados, os comportamentos e a semântica desses componentes para que o usuário consiga compreender como eles funcionam e navegar por eles de forma adequada.
________________________________________
[Sidney]
Também é importante verificar se os botões estão em português, e não em inglês. Às vezes encontramos carrosséis ou até mesmo players cujos botões permanecem em inglês, e isso também precisa ser considerado.
Quando todas essas recomendações que a Cláudia comentou são colocadas em prática, com rótulos claros e bem identificados, a navegação fica muito mais simples. Assim, por exemplo, a gente não se perde ao navegar por um carrossel.
________________________________________
[Reinaldo]
Bom, falamos aqui de vários tópicos e já chegamos ao final do nosso podcast.
A gente abordou uma série de questões técnicas de uma forma muito leve e simples. Dá para perceber que boa parte dos pontos que comentamos é relativamente simples de implementar no código HTML.
Basta pensar em ações como escrever um título adequado para uma página, declarar corretamente o idioma ou fazer a marcação semântica dos componentes. São questões tecnicamente simples, mas que têm um impacto muito grande na acessibilidade.
E, para encerrar, eu queria pedir uma palavrinha de vocês para fechar o episódio de hoje sobre codificação e marcação semântica.
________________________________________
[Cláudia]
Bom, eu defendo que um código de qualidade é a base para a criação de uma página inclusiva e acessível.
Por isso, é importante cuidar do nosso código, porque muitas barreiras de acessibilidade surgem de um código mal escrito, da falta de cuidado com rótulos e especificações, do não uso de elementos nativos e da troca da semântica dos componentes, como atribuir semântica de botão a um elemento que, na verdade, deveria ser um link.
A qualidade do código é fundamental para garantir uma boa acessibilidade.
________________________________________
[Sidney]
Na verdade, quando a acessibilidade passa a fazer parte da prática de todo desenvolvedor, ela deixa de ser algo que toma mais tempo.
No dia a dia, a pessoa já desenvolve soluções com mais qualidade, mais acessíveis e que não criam barreiras para ninguém. É uma questão de incorporar essas práticas ao processo de desenvolvimento.
A norma da ABNT veio justamente para ajudar nesse caminho. Então, é só colocá-la em prática e, no final, o resultado será um produto muito melhor.
________________________________________
[Reinaldo]
Bom, pessoal, chegamos ao fim deste episódio do podcast Todos na Web. Espero vocês no próximo episódio.
Até a próxima!