Acessibilidade web – Hipsters #21 – Transcrição Essa é a transcrição do episódio 21, Acessibilidade Web, tentando tornar nosso conteúdo mais acessível na internet! Um agradecimento à equipe de transcritores da Alura. Paulo: Olá, ouvintes do Hipsters Ponto Tech! Eu sou Paulo Silveira. Sábado, dia 3 de dezembro, foi uma data muito especial… Foi o dia da luta internacional da pessoa com deficiência e por isso, o papo de hoje será sobre acessibilidade – tanto na Web quando em aplicativos móveis. Porque hoje não é só um ponto fundamental para trazer socialmente todas as pessoas juntas, para que elas tenham acesso ao seu site ou a sua app, como também é um ponto vital para dar sobrevivência para sua empresa, para que ela alcance um público maior, um público consumidor e muito importante. Vamos para o podcast. Hoje para conversar com a gente, tenho a presença do Reinaldo Ferraz, que é especialista em desenvolvimento web na W3C Brasil. Tudo bom com você, Reinaldo? Reinaldo: Oi, pessoal. Primeiramente é um prazer estar com você aqui, falar de um tema tão importante, próximo dessa data tão especial. Paulo: Junto com o Reinaldo, aqui presente no estúdio da Alura, tenho o Alexandre Costa que analista de desenvolvimento no Itaú. Tudo bom, Alexandre? Alexandre: Opa, Paulo! Beleza? Boa tarde, pessoal. Uma data bem importante mesmo que não poderia passar em branco e realizando um sonho de estar aqui gravando um Hipster. Paulo: [risos] Temos um fã aqui presente! Como essa conversa beira Web e mobile, a gente o nosso cohost, que você já conhece, que já tem sua própria musiquinha: o Sérgio Lopes. Tudo bom, Sérgio? Sérgio: Oba, pessoal! Tudo bom? Paulo: Eu queria começar o papo entendendo um pouco mais do que é acessibilidade. Pra não ficar muita indefinição, quero saber do Reinaldo, que trabalha nesse órgão que todo mundo já sonhou em trabalhar, o W3C, o que é acessibilidade na Web? Começando pela Web… Quais são os exemplos de um site que a gente pode dizer que é acessível, o que ele está resolvendo e pra quem? Reinaldo: Poderíamos resumir a acessibilidade na Web como garantir que as pessoas com deficiência tenham acesso ao conteúdo na Web. Normalmente quando a gente trabalha a questão de sites acessíveis, falamos muito sobre barreiras de acesso. Então, um site que tem uma barreira de acesso, ele tem um problema sério de acessibilidade. Por exemplo, um site que você não consegue aumentar o tamanho das fontes, um site que as imagens não tem descrições adequada em textos alternativos, um site que você não consegue fazer um navegação viia teclado, um site que tem um contraste ruim entre o texto e o tom de fundo… Tudo isso seria considerado barreiras de acesso para pessoas com deficiência. Neste ponto, se você tem algum tipo de dificuldade, mesmo não tendo algum tipo de deficiência, é bem provável que o seu site tenha alguma barreira séria de acessibilidade. Paulo: Alexandre, hoje esse é um ponto importante para que o seu público seja ainda maior. Alexandre: Com certeza. Se você pegar só no Brasil por exemplo, Paulo, são 6,5 milhões de pessoas com algum tipo de deficiência visual, só dentro do âmbito visual. Com todos os tipos de deficiência, chegamos a 45 milhões de pessoas, estamos falando de quase 1/5 da população brasileira. Não dá pra desperdiçar. Eu brinco muito que gostaria de fazer um app de $1 dólar para cada pessoa com deficiência. Já estava bom… Paulo: É uma empresa de 1 milhão de dólares… O Reinaldo citou alguns exemplos de situações que não são muito acessíveis para um Web site, eu queria saber, começando pela pessoa com deficiência visual que acho que um caso um pouco mais fácil para as pessoas conseguirem imaginar. Quais sãos a técnicas que a gente deve seguir, qual é o guia principal que a sua página Web precisa ter, que recursos precisa ter para que uma pessoa com deficiência visual consiga utilizá-la da maneira adequada para ela. Reinaldo: Acho até interessante pontuar esta questão, porque a pessoa com deficiência visual talvez seja uma que tenha um dos grandes impactos quando falamos de acesso à web… porque qualquer dispositivo, tanto computador, como o smartphone, ele é muito visual. Então, a gente se orienta pela visão. A deficiência visual costuma ser a mais utilizada para podermos verificar pontos específicos de acessibilidade com relação ao impacto. Existem diversas técnicas que estão disponíveis dentro da documentação do W3C, as WCAG, que acho que vale a pena deixar no comentários. Paulo: Já estão nos links [risos]. Reinaldo: Que rápido! Como vocês são rápidos. [risos] [risadas no estúdio] Reinaldo: Essa documentação diz como tornar o conteúdo acessível pra evitar que pessoas com deficiência tenham barreiras de acesso. Então, por exemplo, a descrição de imagens é importantíssima. Você declarar o atributo `alt` das suas imagens… Declarar o atributo `alt`funciona porque se uma pessoa estiver navegando com software leitor de tela, acho que o Alexandre pode explicar um pouco mais sobre a experiência dele, se a pessoa estiver navegando com o software e este atributo `alt`não estiver descrito, ele vai simplesmente ouvir o retorno do software sintetizador de voz como se ele fosse uma imagem. Sem uma descrição. E se essa imagem faz parte do contexto da página, ela deve conter uma descrição. A estrutura de cabeçalho da página é importantíssima, porque normalmente o usuário de tecnologia assistiva, que é como chamamos o usuário de leitor de tela ( o leitor de tela é um tipo de tecnologia assistiva), navega muito por atalho de teclado. Então, se eu pressionar a tecla H, eu navego por todos os cabeçalhos da minha página. Se eu pressionar a tecla 1, eu navego pelo cabeçalhos de nível 1. [Pressiono] 2, cabeçalho de nível 2, e por aí, vai… Então, se eu tiver estrutura de cabeçalho da minha página marcado de forma adequada, imagina que uma pessoa vai chegar na sua página, ela sabe que todos os tipos de notícia são cabeçalho de nível 2, então, é muito mais fácil para essa pessoa poder chegar nesse item da página. Paulo: Estamos falando exatamente do que? “h1”, “h2”, “header”, “/header”? Sérgio: Em HTML, são os famosos “h1”, “h2”, “h3”, a ideia é usar de uma maneira inteligente. Às vezes, quando o desenvolvedor vai fazer a página, muita gente pensa pega um design lá do Photoshop, por exemplo, que foi feito, e fala “isso aqui é um título, o título tem uma fonte grande, em negrito”. E às vezes, o cara implementa um “div” e implementa o título com o “div”, fica igualzinho o design, só que você perde o lado que o Reinaldo está falando, que é o lado semântico. É quando o leitor de tela vai olhar pra aquele código, ele não está interessado se o texto está grande ou está pequeno, do tamanho visual, a cor do texto, porque isso é totalmente irrelevante. O jeito dele saber que aquilo é um título, não é porque ele é uma fonte grande, é porque ele foi marcado como título e então são usadas essas tags que são super antigas (“h1”, “h2”) que existem no HTML há muito tempo, mas que muita gente usa errado. Ou deixa de usar. Reinaldo: O Sérgio tocou num ponto extremamente importante que é a marcação semântica, na verdade, utilizar os elementos semânticos do HTML. Isso é importantíssimo para acessibilidade porque, como estamos falando de deficiência visual, você tem esses leitores de tela que já conseguem identificar grande parte dos elementos semânticos do HTML5. Então você consegue ir para blocos de conteúdo, ir para navegação, ir para áreas específicas da página utilizando esses elementos semânticos – a marcação de “header”, “nav”, “section” e por aí, vai. Eu só queria aproveitar e fazer um comentário interessante e aproveitar que estamos falando em um podcast que tem uma boa repercussão, e acho que isso é um discussão legal para se abrir, é a questão de múltiplos “h1” na página. Isso é um ponto que tem problema ainda com a acessibilidade, porque quando você utiliza múltiplos “h1” (vamos dizer, “h1” principal e depois, “h1” dentro de “section”, outro dentro de outra “section”) para um software leitor de tela, ele não consegue fazer a verificação de hierarquia entre esses “h1″s. Então, ele não sabe qual é “h1” principal, qual é o secundário. Ele vai chamar todos eles por “h1”. Então pra acessibilidade ele ainda é muito delicado para utilizar múltiplos “h1″s numa página. Paulo: Vale lembrar que não só pra isso. Pra SEO, Google, o pessoal fala “se der, [use] um ‘h1’ só”. Alexandre: Na verdade, não só um “h1”, mas você também não pular os “h”s. É você colocar “h1” para o seu título principal da página e os títulos secundários você colocar “h3” porque o tamanho da fonte está mais adequado. É muito comum. Paulo: [risos] É a famosa preguiça do Front-End. Alexandre: Exatamente… Então, a página ser semântica ajuda muito, principalmente, até colocando um adendo, temos que lembrar que o deficiente visual é bem impactado, mas as outras deficiências também. Porque à vezes, para determinada tecnologia, ele vai renderizar a página de uma forma só. Pensa que o leitor de tela, o que ele faz com a sua página? Não importa se ele tem, por exemplo, três colunas. Ele vai colocar aquilo como uma coisa sequêncial. Tanto é quando você chega para o deficiente visual e fala “o ícone à direita” ele fica maluco, porque para ele a página é um formulário contínuo. [risos no estúdio] Alexandre: Outra coisa importantíssima também, é uma coisa muito comum, eu quero que os meus links, [por exemplo] o link “comprar” ele tenha a aparência de um link, ele tenha a aparência de um botão. Então, você liga para o suporte técnico e fala “cara, eu não estou conseguindo comprar aqui no site”. “Senhor, clique no botão ‘comprar'”. Então, você vai lá no teclado, aperta B – que é o atalho para próximo botão – e o leitor de tela fala “não tem botão nessa página”. Você insiste no B e a pessoa vai lá, [clica em] “control + U” para verificar o código-fonte e verifica que é um link que tem um style “.btn” lá do Bootstrap. [risos no estúdio] Alexandre: Porque além das tags semânticas, a gente tem que lembrar de alguns outros atributos que um elemento tem que ter que a tecnologia assistiva usa. O primeiro dele é realmente a tag. A tag vai falar “isso aqui é um link, um “a”, então, é um link”. Então, ela tem um comportamento de link e eu consigo sobrepor isso. É a role, é o papel que esse elemento tem dentro da página. Isso indica para o leitor de tela, outros recursos assistivos como os navegadores que a pessoa tetraplégica usa aquele canudinho na boca pra navegar e outras tecnologias. Então, a role é importante porque ela diz para o leitor o que é aquilo e como eu interajo com aquele elemento. A segunda coisa é o estado daquele elemento, ele está ativo, ele está inativo, eu consigo interagir, ele está marcado? É um checkbox ou radio-button, ele está marcado ou desmarcado? Por último, e não menos importante, o valor. A caixa de texto, ela está preenchida, qual é o valor da caixa de texto? Tem um discussão muito boa, não é mesmo Reinaldo, em relação ao placeholder in text. Muita gente se confunde com o placeholder, acha que o placeholder substitui um label. Imagine que estou preenchendo um formulário e tem um placeholder colocando “999.999.999-99”, automaticamente você pensa “opa, isso aqui é o campo CPF”. Só que o leitor de tela não lê essa informação. E quando o campo ganha foco, ele fala “em branco”. [risadas no estúdio] Alexandre: “Eu preencho aqui, o quê? Com o nome da mãe ou do dono do site. Paulo: Eu queria deixar claro, o Reinaldo deu um spoiler. A gente não falou lá na frente, mas o Alexandre fala com um certo conhecimento de causa. Ele é uma pessoa com deficiência visual, com cerca de 3% da visão. Está correto, Alexandre? Alexandre: Isso mesmo. O que clinicamente… eu sou cego. Ainda tenho um resquício de luz, eu consigo saber se é de dia ou se é de noite, então, eu não me perco nos horários. Praticamente eu não consigo ler nada, eu não consigo usar o monitor, então eu passo o dia tanto no computador, como no celular, usando a tecla Assist View (leitores de tela). Paulo: E se eu estou querendo desenvolver o meu site de forma acessível, pensando por enquanto na pessoa com deficiencia visual, qual é esse software mais comum, que tem essas tecnologias tanto para desktop, quanto para o dispositivo móvel. Alexandre: Cada plataforma tem a sua gama. A Apple é fechada no VoiceOver, que tem grandes vantagens, porque é um leitor de telas que ele já está embutido no kernel do sistema. Então, qualquer computador da Apple, qualquer Smartphone da Apple, Ipad e tudo mais tem o VoiceOver que lê pra mim. Ele me dá uma resposta audível de tudo que está acontecendo na tela. Quando eu vou pra Windows, eu tenho duas opções, tem mais, mas as principais são o Jaws, que é comercial, da Freedom Scientific, e não é nenhum pouco barato. Hoje no Brasil, uma licença de Jaws está custando em torno de R$ 8 mil reais. Paulo: Nenhum pouco acessível. [risos] Alexandre: Exatamente. Você tem também o NVDA, que é nonvisual desktop access, que um leitor de tela open source, escrito em Phyton, que foi desenvolvido por dois cegos, lá na Austrália. Eles cansados por não conseguir pagar por uma licença de Jaws, eles resolveram desenvolver um leitor de telas e hoje, ele é tão quanto o concorrente comercial dele. E quando você vai para o mundo do Linux, desktop Linux também no Gnome, você tem o Orca. Até uma brincadeirinha com o Jaws e é um leitor muito bom. O bacana, na verdade, é que a concorrencia traz vantagem para o usuário. Todos esses leitores nasceram com pricnipios diferentes, formas de interagir diferentes, mas que com o tempo, um foi copiando recursos dos outros. Isso trouxe pra gente uma facilidade muito bacana, um acesso bem interessante. Mas o que eu acho legal, por exemplo, de tre citado todos aqui, é que por o NVDA ser open source e gratuito, não tem desculpa para o desenvolvedor não utilizar para fazer teste de acessibilidade dos sites dele. Paulo: Então, a gente pode utilizar essas ferramentas e falar “pronto, isso aqui vai ser um experiência fidedigna ao que uma pessoa com experiência visual vai ter”. Alexandre: Exatamente. Sérgio: Eu só queria fazer o papel do advogado do diabo, assim… porque a gente tem contato com muitos desenvolvedores, sou desenvolvedor também, e muita gente fala que é difícil para quem naõ tem a deficiencia visual e não está acostumado a usar um NVDA, ou alguma coisa assim. Você abre ali a primeira vez, você fica perdido. Exige aprender, exige alguma coisa assim. Eu queria saber a opinião de vocês, qual é a dificuldade real mesmo para um desenvolvedor web, hoje, que já tem experiencia com HTML, CSS, JavaScript e ele está querendo deixar as suas páginas mais acessíveis, mas por exemplo nunca abriu o VoiceOver na vida. É difícil demais, como é que funciona? Reinaldo: Eu queria só fazer um comentário sobre isso, porque acho que é importante pontuar. Você falou sobre o desenvolvedor começar a usar o leitor de tela… Acho que antes até do desenvolvedor começar a usar o leitor de tela pra poder fazer os testes, é ele tentar fazer uma navegação via teclado no seu site, no sistema ou numa aplicação mesmo, e verificar se ele consegue atingir ou executar uma ação, uma task, no site utilizando só o teclado. Sem alguma referência visual, sem alguma outra forma que não seja uma navegação por Tab ou por setas. Isso facilita porque acho que ele já começa a se familiarizar com a navegação sem você ter um ponto de referência visual. Sem você ter um ponteiro para apontar e clicar em determinado link. Porque fazendo essa navegação via Tab, por exemplo, você já consegue identificar o problema que o Alexandre estava comentando sobre o botão que ele não encontra. Se ele [desenvolvedor] fizer essa navegação por teclado, tentar localizar os itens na página começando pelo teclado, ele já consegue identificar alguns pontos que ele não consegue fazer. Como por exemplo, submeter um formulário. Parece a coisa mais simples que tem clicar num botão, mas se esse botão estiver como um “span”, cheio de JavaScript, você não conseguir fazer ele com foco. Paulo: Ainda bem que isso nunca acontece, não é mesmo, Reinaldo. [risos no estúdio] Reinaldo: Não, imagina… Acho muito curioso, porque você tem elementos de botão e você tem elementos de âncora para fazer para fazer, como o “href”, conteúdo interativo, conteúdo clicável. Muitas vezes, prefere-se utilizar um “span”, então você coloca um “script”, você coloca o CSS pra costumizar, e você deixa um código muito maior do que você utilizar componentes que já estão prontos. Então, talvez até começando a responder talvez esta parte que o Sérgio comentou, acho que fazer um teste, mesmo com o monitor ligado e enxergando a página, executar tarefas dentro da sua página via teclado, acho que já é um grande começo antes de ligar o leitor de tela. Alexandre: Exatamente. E o legal, Reinaldo, dele fazer isso é que ele já vai estar preparando o site dele para tecnologias assistivas não para deficientes visuais, mas tecnologias motoras, os outros tipos de interação. E Sérgio, eu concordo com você. Ouvir o leitor de telas pela primeira vez, principalmente quando você pega o NVDA e o próprio Jaws que tem vozes mais robotizadas, é bem estranho. Só que assim, eu recomendo realmente, de verdade, o desenvolvedor entrar no manual desses leitores porque os comando são todos via teclado e são bem fáceis de memorizar. Porque todos esses leitores, eles têm o que chamam de tecla acionadora, então no Jaws e no NVDA, é o “insert” no teclado convencional, ou o “Caps Lock” quando você coloca ele pra modo notebook. É a combinação da tecla que ele chama de NVDA mais alguma tecla. Você lendo o manual, você vai ver que consegue configurar a velocidade de leitura. Por exemplo, eu trabalho com NVDA lendo na velocidade de 90. Uma pessoa que nunca ouviu um leitor de tela, só passa a entender ele ali por volta do 20, 30, no máximo. Eu trabalho no 90. [risos no estúdio] Alexandre: Então, a pessoa me ouvindo trabalhar, ela acha que eu sou maluco, mais do que o normal. [risos] Paulo: O bom é que você pode ouvir todas as notícias lá do Ego da Globo, pode ouvir todas as fofocas dos artistas, rapidinho. Não precisa gastar muito tempo. Alexandre: Não só rápido, eu posso ouvir e ninguém sabe que eu estou ouvindo, então eu disfarço totalmente. [muitas risadas no estúdio] Alexandre: Pra pessoa que não quer instalar o leitor de telas e quer saber a experiência de o que é ouvir leitor de telas mais rápido, pega o seu player de podcast agora e coloca em 3x. Está ouvindo, agora, a gente falando igual ao Tico e o Teco? Então, é mais ou menos isso. Voz de leitor de tela: Aqui tem vírgula. Paulo: O Alexandre já participou bastante aqui da Casa do Código, da Alura, e ele sempre falou “poxa, Paulo, vocês sempre fizeram muita coisa que já estava bem adaptada para as pessoas com deficiencia visual”. Mas vou fazer um mea culpa aqui, grande parte disso foi só quando pessoas com deficiencia visual falaram “Paulo, poxa, isso aqui no site da Alura não está funcionando muito bem para quem está estudando porque esse botão que era pra ser um botão, na verdade, é uma imagem com JavaScript. E a gente foi mudando assim… Mas é óbvio, aqui dentro, o nosso desenvolvimento está sempre muito embasado nisso do HTML semântico e tentando evitar essa mágica que todos vocês três citaram de ficar enfiando “script” em “span”, de ficar fazendo botão de formulário ser uma outra coisa, de usar os “h”s de forma errada. Se eu ficar pensando nessas regrinhas básicas de usar o “h1”, o “h6” de maneira correta, do nosso site ser responsivo, da fonte ser expansível, de botão ser botão, imagem [ser] imagem, link é link, eu já estou batendo 90% de que uma pessoa enfrentaria ou tem alguns outros detalhes que vocês consideram que “olha, se vocês não usarem uma dessas tecnologias assistivas, vocês não vão conseguir pegar”? Alexandre: Acho que como usuário, você já pega boa parte, sim. Acho que o Reinaldo vai poder complementar bem melhor. Mas a única coisa que eu acrescento do que você falou, Paulo, é a imagem ser imagem e realmente, como o Reinaldo colocou, ter o atributo “alt”. Não só o atributo “alt” com uma descrição do conteúdo da imagem, quando é importante, mas até o “alt” que, como eu mesmo fiquei sabendo depois, o “alt” vazio pra que… aquela imagem que é só a borda da tabela, não faz sentido o leitor de tela ficar lendo aquilo. O “alt” vazio faz com que o leitor de tela ignore aquilo, então torna a leitura pra gente mais agradável. Sérgio: Esse é um ponto importante, o “alt” vazio é diferente de sem “alt”. E pouca gente sabe disso. Sem “alt”, ele vê que tem uma imagem aqui e a pessoa fica perdida. Alexandre: Eu estou comprando um produto e ele lê para mim assim “1-2-3-5-9-a-c-3-9-.png”, então, eu penso “acho que é esse que eu quero”. Paulo: [risos] “Acho que era essa cor que eu queria…” Sérgio: Acho que outra coisa que é importante do “alt” é que não é fácil escrever um bom “alt” . Eu já vi muita gente… o cara coloca ali, coloca a imagem… Por exemplo, o logo do site, e o cara coloca “alt=’logo'”. Você fala “você não me ajudou, entende? O que está escrito nesse logo?”. [Escreve] “alt=foto”, está bem, mas o que é? É foto do que? É uma foto de um produto? “Essa aqui é uma blusa de frio, e tal..” Descrever. É claro, não dá pra você escrever uma redação ali no “alt”, mas é uma arte também. Eu percebo que muitos desenvolvedora pra quem a gente dá aula, para os alunos, encontram essa dificuldade de saber o que escrever no “alt” e como escrever. Reinaldo: Essa questão de usar o “alt”, eu gostei do termo que você usou “escrever o texto para o “alt” é uma arte” mesmo, porque eu já vi de tudo, cara. Eu já por exemplo, imagine um botão que tem um telefone, é uma imagem (o botão tem um telefone), e tem um telefone. “Entre em contato pelo número tal”. O “alt” está dizendo “botão com uma imagem de um telefone azul fora do gancho”. O cara quer fazer a ligação, o cara quer descobrir qual é o telefone. Sérgio: O cara escreve demais… [risos] Reinaldo: Então, a gente tem que ter um pouco de bom senso. Mas tem uma outra questão que acho que é muito bacana a gente estimular a escrita do “alt”, você descrever o “alt”, até porque o “alt” é indexado pelo Google. O conteúdo do atributo “alt” é indexado pelo Google, ele faz até referência dentro das imagens que são buscadas. Então, eu sempre defendo que não é só uma questão de acessibilidade. Mas você também consegue colocar conteúdo relevante relacionada àquela imagem, utilizando o atributo “alt”. Sérgio: Existe uma intersecção grande entre SEO e acessibilidade. Porque se você for pensar bem, as tecnologias são uma espécie de robôs lendo a sua página. Paulo: Perfeito! Boa analogia. Sérgio: Tanto o Google, quanto um deficiente visual, não vão enxergar do ponto de vista visual mesmo. Enxergar o código, vão olhar para o código… Existe um link grande entre essas duas áreas, é bom que com uma você acaba matando a outra. Reinaldo: Isso é verdade. Estou me envolvendo, agora, com uns estudos relacionados à acessibilidade e SEO que até é um argumento que a gente usa para poder defender isso nas empresas. Você vai falar sobre acessibilidade na empresa, o cara fala “eu estou com o prazo apertado, o orçamento é curto”, mas eu falo “acessibilidade também vai melhorar o seu SEO”. Então ele fala “opa, vamos colocar!”. Sérgio: “Espera! Vamos conversar…” [risos] Reinaldo: É. Então, eu já fiz essa pesquisa com “alt”, depois, eu até vou mandar os links pra vocês. Já estão os links! Paulo: Já estão aqui! [risos] Reinaldo: Eu fiz também um estudo sobre “svg” e acessibilidade. Alguns recursos de descrição de imagem dentro de “svg” embutido no HTML e como as ferramentas de busca indexam. E não só o Google, mas outras ferramentas também indexam os conteúdos que são lidos por tecnologia assistiva. Alexandre: Isso é bacana. E para os desenvolvedores de plantão, mentes vão explodir. Não só SEO, mas todas as ferramentas de automação de teste de interface se baseiam nos mesmo atributos que as tecnologias assistivas pra poder executar os seus testes. Por exemplo, se você usa um Selenium, e você manda ele procurar um botão e clicá-lo, ele nada mais está fazendo uso do que as APIs que os navegadores ou os aplicativos usam para encontrar esse controle e executar o comando. Então, quando você coloca o “span” cheio de JavaScript… Cara, acho que vão acabar com o “span” de HTML, de tanto que a gente está falando mal hoje. Não vão mais usar, vai virar uma tag proibida. [risos] Quando você faz um “span” cheio de JavaScript, até para você automatizar um teste de interface desse site, o trabalho de torna homérico porque você vai acabar tendo que fazer milhões de hacks no seu código, pra poder chamar o clique desse botão. Paulo: Vocês estão dando vários argumentos para mostrar o quão importante é a gente desenvolver o Front-End pensando na acessibilidade, mas só queria lembrar que tem dois [argumentos] que são matadores. O primeiro é social, que a gente já falou, que é a questão da inclusão. As pessoas poderem comprar, acessar, ler, usufruir do seu produto. O segundo é aquele número que o Alexandre soltou lá no começo – são 6,5 milhões de pessoas com deficiência visual, sem contar as outras pessoas com outras deficiências que vamos falar um pouco. Se você não consegue convencer o seu chefe com isso, eu não sei mais como convencê-lo… Reinaldo: Tem uma terceira forma de convencê-lo, agora é lei. Desde junho de 2015, a acessibilidade nas páginas Web de empresas com sede no Brasil, elas têm que ser acessíveis seguindo as diretrizes internacionais de acessibilidade. Então, tem um terceiro argumento para poder levar para o chefe. Paulo: Que também está com um link aqui, já apareceu pra você no post. Reinaldo: Nossa, que rápido! [risos] Voz de leitor de tela: Mudança de bloco. Paulo: Então, a gente falou um pouquinho da parte técnica de como implementar este Front-End mais acessível e eu queria saber de outras práticas que são importantes para tornar o nosso site acessível, seja uma pessoa com deficiência visual ou com alguma outra deficiência. Reinaldo: Acho que um ponto que é importante também comentar, a gente estava falando sobre as tags… sobre alguns elementos importantes, o Alexandre acabou comentando rapidamente sobre os formulários, da importância de relacionar o “label” com o “id” de um “input”, por exemplo. Isso tem um impacto enorme par aacessibilidade, porque você consegue relacionar o rótulo que é o que está dentro do “label” com o campo do “input”. O que eu acho mais legal disso é que você tem um ganho não só de acessibilidade, como usabilidade, quando você faz essa relação com “radio”, porque então você não precisa marcar no quadradinho ou na bolinha para poder acioná-lo. Se você clicar no texto que está do lado dele, você também aciona este campo. Tem uma outra questão que acho é legal comentar sobre o formulários que é agrupar os blocos de formulário. Então, aquela coisa que você tem que pedir dados pessoais e dados comerciais. Você separar por elementos de “fieldset” e colocar um elemento “legend” pra descrever cada um deles, porque quando o usuário de leitor de tela chegar no primeiro campo, ele vai ler que aquilo é um bloco de campo de formulário e vai ler qual grupo é aquele antes de começar a ler o conteúdo. Bom, até queria abordar outro aspecto que acho que tem relação como outros tipos de deficiência. Quando estamos falando em pessoas com deficiência visual, a gente não pode esquecer também que tem muitas pessoas com baixa visão, com daltonismo, que não consegue enxergar um determinado contraste de cor. Então é fundamental que a gente não use somente cor para transmitir informação. Aquela coisa de clicar no botão vermelho para cancelar, tabela de horários marcadas em verde [que] significam horários. Isso são tecnicas complicadas especialmente pra quem tem algum tipo ou grau de daltonismo. Alexandre: Outra coisa também, não é mesmo Reinaldo, que foi bem lembrado, é que você falou de navegação por teclado e é realmente o Tab Order, que é eu conseguir andar de uma forma bem precisa com o Tab pra não pular. Eu estou no campo “nome” dou um Tab, vou lá para o botão “Submeter”, que depois eu dou um Tab e vou para o campo “CPF”. Você deixa a pessoa bem maluca. E até um link interessante pra quem não ouviu o cast, e acho que tem tudo a ver com aqui, foi o cast do Hipster sobre UX. Aquelas heurísticas têm tudo a ver com acessibilidade, porque o “label” estando próximo do campo que é associado por “id” e até mensagem de erro. Cara, como eu sofro com mensagem… Paulo: Cada uma aparece com um JavaScript maluco, de uma forma diferente. Alexandre: Nossa! O Cara quer fazer aquele balãozinho com uma setinha que aponta… Pra quê? Paulo: Uma coisa que eu estou gostando muito desse episódio é que tudo que o Alexandre fala aqui e reclama com sendo uma pessoa com deficiência visual, a gente que não tem deficiência visual tem basicamente a mesma dificuldade, certo? Você dá Tab, você também fica louco da vida. Aquelas mensagens de erro com pop-up ou que dão refresh na tela e você não sabe direito do que está se referenciando, são coisas que também aparecem pra todas as outras pessoas de uma forma um pouco diferente. Ou mesmo… O Sérgio citou um caso das pessoas com deficiências motora uma vez, que os botões pequenos são difíceis, porque é difícil você mirar num botãozinho pequeno. Mas se você for ver, quem não tem deficiência motora, também é difícil de ir lá e clicar naqueles botões pequenos. Eu estou muito ambientado ao Mac, hoje em dia no Windows, eu vejo aquele “X” pequeno, pra eu acertá-lo, eu fico até um pouco “opa, passou!”. Sérgio: É o caso que o Reinaldo citou do “label” no “checkbox”, que você não precisa acertar o quadradinho do checkbox, na hora de clicar, você pode clicar no testo inteiro. Paulo: Perfeito. Sérgio: Isso ajuda em usabilidade, mas também alguém que tenha alguma limitação motora que precisa de uma área de clique maior, uma área de toque maior. Tem vários casos desses. Voz de leitor de tela: Aqui tem vírgula. Paulo: Alexandre, eu queria aproveitar para perguntar se tem mais alguma outra coisa que te irrita muito e que acontece com frequencia em todos os tipos de site. Alexandre: Full page banner! Bannerzinho de full page, acho que todo mundo adora… [risos no estúdio] Paulo: Estou falando que os problemas são os mesmos… Alexandre: Full page banner deixa a gente completamente maluco em relação a isso. Uma coisa, pra gente não perder aqui, é que eu fiz um curso recentemente online e gostei muito disso, que eu não tinha visto em lugar nenhum. É que a gente pensa em acessibilidade sempre na pessoa com alguma limitação – seja temporária, permanente, visual, auditiva ou intelectual -, mas a gente nunca lembra da pessoa em uma situação de emergência. Você precisa acessar o site pra pegar o telefone de um hospital. Você está passando mal, alguém da sua família está passando mal e você não consegue achar o maldito telefone porque ele está escondido no meio de 1 milhão de imagens e textos. Então deixar a informação mais importante, o mais fácil de ser acessada possível. Eu sempre brinco e o Paulo até brincou comigo também… Mas tente fazer compras em qualquer e-commerce somente usando o Tab. Você não consegue chegar nos produtos. Reinaldo: Se aventura aí? Paulo: Eu falei “já é difícil você fazer uma compra só com o mouse nos e-commerces, só com o Tab então, você está perdido!” Alexandre: Aliás, bem lembrado, e-commerce. Pra quê eu tenho que arrastar o produto para o meu carrinho? [risadas no estúdio] Sérgio: Em vez de clicar num link, num botãozinho. Alexandre: É! Você tem que clicar no produto e arrastar para o carrinho. Eu falei “Tá. Eu não sei onde está o produto, eu não sei onde está o carrinho”, e assim… eu tive baixa visão e sei o que é arrastar, mas muitos cegos não sabem o que é arrastar uma coisa para o carrinho. O pessoal tenta trazer uma experiência para o site que acho que não é para estar ali. Sérgio: Você falou de esse cenário de uma pessoa num cenário de emergência, isso acho que é importante lembrar. Às vezes, a gente divide o mundo entre as pessoas quem possuem alguma deficiência e as pessoas que não possuem. Às vezes, parece que estamos discutindo acessibilidade para incluir este outro mundo dentro do mundo das pessoas sem deficiência. Mas na verdade não é. Existe níveis e grau diferentes, como você [Alexandre] comentou, deficiência temporária… Então, você fala “eu não tenho deficiência visual”, mas por exemplo eu uso óculos e, hoje, quebrou o meu óculos. Você estava citando esse caso pra gente… Eventualmente, sem óculos, não enxergo nada. Então, eu preciso de um site mais acessível pra usar até meu óculos ficar pronto daqui dois dias. Ou acabei de sofrer um acidente e minha mão está temporariamente inabilitada e eu vou precisar usar através de outros meios. Então vou usar, alguma coisa que identifique minha voz. Todo mundo pode passar por situações que se assemelham à situações de quem tem um deficiência permanente. E claro, tem o caso de você com mais idade, todo mundo vai chegar lá um dia. A visão começa a ficar pior, o X do Windows começa a ficar menor, não sei por quê? Ele estava grande até ano passado, mas parece que diminui esse ano… [risadas no estúdio] Sérgio: E no ano que vem, o X vai estar menor… E só vai piorando. Então, a gente está construindo na verdade, para todo mundo. Reinaldo: Eu fico imaginando situações, por exemplo, que nem você comentou Sérgio de pessoas idosas, a gente que está desenvolvendo no dia a dia, a gente nos imaginar daqui a 20 ou 30 anos, e de repente tentar entrar numa página que a gente desenvolveu hoje. E de repente não conseguir acessar aquele conteúdo, você não conseguir ler aquele conteúdo porque você não tem contraste adequado, você não consegue aumentar o tamanho das fontes ou então, você tem baixa audição – pessoas idosas, geralmente, não tem uma acuidade auditiva também, vai diminuindo. Então, imagina, você publica um vídeo sem legendas e você mesmo daqui a 20 anos não consegue compreender o vídeo que você publicou numa página. Ou hoje em dia, até mesmo com um dispositivo móvel, vai procurar um endereço na rua com incidência de Sol na tela do celular. Se você não tiver um bom contraste, você se “estrepa” também. Você não consegue localizar um endereço no seu telefone celular. Mesmo enxergando muito bem. Paulo: A gente falou que você ouvinte pode instalar esses softwares de tecnologia assistiva pra trabalhar esse lado da acessibilidade no Front-end na Web. Mas como que eu posso, finalmente, verificar e falar OK, está pronto pra ir pra produção e uma pessoa com deficiência visual ou alguma outra deficiência vai poder utilizar o meu site? Reinaldo: Uma dica que eu queria deixar aqui pra esse podcast é a gente poder utilizar valiadores automáticos de acessibilidade. Então, da mesma forma que nós temos validador de Markup da W3C, existem alguns validadores de acessibilidade que também vão estar disponíveis no link – uma lista com alguns validadores que são legais de se utilizar. a vantagem deles é que eles conseguem identificar alguns problemas clássicos relacionado à acessibilidade. Por exemplo, se as imagens estão sem o atributo “alt”, se você declarou o idioma da página, se os seus formulários estão rotulados com o elemento “label”. Então, eles conseguem identificar diversas coisas. A vantagem é que ele consegue verificar grande parte dos problemas técnicos. O problema é que eles não conseguem garantir 100% da acessibilidade. É muito comum as pessoas perguntarem “eu passei um validador de acessibilidade, tirei 100%. Então, meu site está acessível”. Não, isto não significa que o meu site esteja 100% acessível. Porque, por exemplo, o validador de acessibilidade não consegue identificar se um site tem legenda, por exemplo. Então, algumas pessoas com algum tipo de deficiências específicas podem não conseguir acessar determinados conteúdos. Mas são ótimas ferramentas pra ajudar o desenvolvedor a tornar o seu site um pouco mais acessível. Paulo: Ótima dica, então, também está aqui o link, para os validadores que acho importantíssimo todo desenvolvedor ter no seu bookmark. Voz de leitor de tela: Aqui tem vírgula. Paulo: Eu queria terminar este podcast tirando uma curiosidade minha com o Alexandre. Eu acho curioso que na nossa área que envolve tecnologia, programação, internet e muito HTML, é relativamente comum encontramos pessoas com deficiência visual. Não é uma surpresa… Aqui na Caelum mesmo, nas aulas presenciais a gente já teve várias pessoas com deficiência visual. No curso online, nos livros, também encontramos empresas com equipes de desenvolvimento que possuem deficiência visual. Tem até o Lucas Radaelli, o cara famoso que esperamos que no próximo podcast ele possa estar aqui com a gente. Tem até estrelas pop nesse mundo. Como o Lucas, o demolidor da internet brasileira. Eu queria entender um pouco mais, Alexandre, por que acontece com essa frequência? Nós somos mais bonzinhos, é um pouco mais simples para entrar nesse mercado? Porque é muito legal ter você aqui conversando de tecnologia, conversando de igual para igual, sobre as mesmas coisas, inclusive sobre problemas que também nos atingem. Alexandre: Acho que tem algumas coisas que facilitam. Primeiro, acho que sim, nós de tecnologia nós temos a cabeça mais aberta. A gente aceita bem melhor a diversidade, principalmente porque a gente já vive a diversidade no dia a dia. Eu hoje trabalho, praticamente, com três sistemas operacionais o tempo todo. Eu estou lá com o meu Windows, com o meu Visual Studio, só que com uma máquina virtual rodando dentro do meu Mac, onde estou rodando um Docker, com alguns containers Linux. [risadas no estúdio] Alexandre: O nosso dia a dia já é diversificado pra caramba, então, aceitar o que é diferente pra gente é o normal. Mas eu acho que o que atrai a tecnologia pra pessoa com deficiência visual é que a gente depende muito dela pra fazer a nossa vida rolar. Se não fosse os leitores de tela, eu acho que não conseguiria fazer metade do que eu faço no meu dia a dia. Então, seja fazendo um curso da Alura, lendo um livro da Casa do Código, tudo isso a tecnologia assistiva ajuda muito. Mary Pat da IBM falou uma frase uma vez, e ela foi muito feliz, eu coloco isso como slide inicial de todas as minhas palestras “a tecnologia torna para as pessoas, as coisas mais fáceis. Para pessoa com deficiência, torna as coisas possíveis”. Agora, não é porque eu trabalho com tecnologia que é fácil. Por exemplo, vamos falar de codificação. Você está lá na sua IDs, no seu Eclipse, está no seu Visual Studio, analisando um método, pra ver se esse método é muito complexo ou não, para fazer um refactoring. Você consegue colocar o olho na tela e ver o método inteiro – e saber onde o “if” abre, onde ele fecha, onde tem um Swift ali dentro, ele chama outro método. Beleza. O leitor de tela, ele lê pra mim, linha a linha. Então eu não tenho essa visão global do código. O que nós deficientes visuais fazemos é a gente tem um stack na nossa cabeça. Tem toda a pilha de execução na nossa cabeça. Eu estou descendo lá, abriu o namespace, abriu a classe, abriu o método, abriu um “if”, então estou indo do “if”. Fechei o “if”, abriu outro “if”. Chamei um método aqui, fechei o ‘if”, fechei o método, fechei a classe, fechei o namespace. Porque é um inferno quando a gente esquece de fechar um chave, inclusive quando as ideias começaram a abrir e fechar parênteses, a abrir e fechar classes automaticamente, a chave salvou a gente porque era um inferno achar onde tinha esquecido de fechar uma chave. Ainda mais na pirâmide de DOM do JavaScript, ainda bem que criaram as promessas… Porque, cara, era callback do callback do callback. Eu falava “e qual desses que eu não fechei, meu deus do céu?!” Sérgio: Agora, a gente precisa fazer um podcast sobre código acessível. Como as pessoas não devem escrever… [risos no estúdio] Paulo: Com certeza de novo é o mesmo problema para as pessoas que não têm deficiência visual. Isso vai ajudar todo mundo. Alexandre: Eu trabalho com algumas pessoas e sempre xingo muito. É aquele negócio de… o cara pra deixar a leitura visual mais fácil do código, entre um método e outro, coloca cinco linhas em branco. E eu estou lá com o leitor “fecha chaves, em branco, em branco, em branco, em branco, em branco, public void” e eu [falo] filho da mãe… Ou então, você abre o arquivo e você dá um “Control + End” só pra sentir a dor de quanto vai ser mexer naquele arquivo. E tem lá 2 mil linhas, num arquivo .js . Você fala “esse daqui está ruim de mexer, 2 mil linhas num JavaScript está bem complicado”. Então, você vê lá, abre “function”, começa a fazer não sei o quê, fecha a “function”, abre comentário “um monte de código que não vai mais ser usado” e fecha comentário. Por que não apagou o comentário? Paulo: [risos] Muito bom, Alexandre! Muito boa a participação… Pra encerrar, eu queria deixar um recado do evento, Alexandre, que você realiza. Pode falar um pouquinho? Alexandre: Posso, sim. Aproveitando que sai na semana quando vai acontecer, essa edição vai acontecer em Porto Alegre, dia 10, sábado agora. Paulo: 10 de dezembro de 2016. Alexandre: Pra quem está vendo no futuro, que bom! Chegamos no futuro… É o Encontro Nacional de Profissionais de TI com deficiência visual, a sigla é ENTIDV. É um encontro que eu promovo pra fomentar a inclusão da pessoa com deficiência visual no mercado de TI. São palestras, são mesas de discussão, são papos bem interessantes, com gente que já está no mercado trabalhando, empresas que estão incluindo, pra fazer a ponte. Normalmente, ele acontecia aqui em São Paulo, é a primeira edição fora de São Paulo, e a gente vai ter outras. Então, mais informações [você encontrará] lá no nosso site, que é o www.entidv.com.br. Paulo: Está o link pra vocês também. E eu queria agradecer ao Reinaldo, muito obrigado Reinaldo pelo seu tempo. Reinaldo: Eu que agradeço pela oportunidade de poder falar. Eu só queria deixar um recado importante já que a gente está falando de desenvolvimento acessível, acho que a minha mensagem final seria que as pessoas pudesse colocar a acessibilidade na rotina de desenvolvimento. Que a gente não fizesse só um teste de acessibilidade depois do site pronto e rezar pra estar tudo funcionando. Que a gente possa colocar isso desde o principio, desde o desenho Wireframe, desde o desenho do layout até a gente começar a codificação, porque vai ficar tudo mais simples, muito mais barato e mais fácil de se fazer. E mais um vez, obrigado e parabéns pelo podcast que vocês estão promovendo. É fundamental ter essa discussão. Paulo: Queria agradecer também ao Alexandre, porque também veio dele a ideia lá num tuíte pra mim de vir aqui vir gravar com a gente. Obrigada, Alexandre. Alexandre: Eu que agradeço a oportunidade, é um cast que eu ouço, que traz informações relevantes e trazer essas mensagens para o público do Hipster é uma honra. E até complementando o que o Reinaldo colocou, o mais engraçado é que pra fazer algo acessível, é só fazer direito. É só você seguir o que o HTML diz pra você fazer, o que a W3C colocou que você tem que fazer e está certo. Então, quando você fala assim “deixar acessível vai ficar caro é que, amigo, olha que o seu problema está um pouco antes”. [risos no estúdio] Paulo: Queria agradecer ao Sérgio pela participação. Obrigado, Sérgio. Sérgio: Obrigada, pessoal. Paulo: E eu queria agradecer especialmente a você ouvinte que está ouvindo esse podcast em 3x, ficam aqui embaixo do Hispters Ponto Tech, os links. Um abraço especial aos ouvintes que são pessoas com deficiência visual e outras que estão muito próximas da gente, nós recebemos bastante mensagem. É um agradecimento muito especial. É muito bom ter vocês por perto e saber que estão participando de tecnologia. Um abraço e até a próxima ….
