Acessibilidade na Web/Mobile - Guia de Estudo

Motivação

Em pleno 2022, ano da copa, e a Acessibilidade na Web que é um tópico importantíssimo não tem ganhado tanta atenção quanto deveria. Pois bem, após uma motivação pessoal e profissional, resolvi documentar alguns tópicos importantes que achei sobre o assunto e compartilhar com vocês!

Introdução e Barreiras de Acesso

A Acessibilidade na Web garante o direito de todos os usuários, independente de sua condição física de consumirem os mesmos conteúdos e que tenham uma boa experiência ao acessar a Web, por isso, é importante que nós, como desenvolvedores web e mobile nos preocupemos com a acessibilidade de nossos sites e aplicativos.

Para iniciar o estudo, devemos falar de barreiras de acesso, ou seja, um site que possui barreiras de acessibilidade, como:

• Sites em que não é possível aumentar o tamanho das fontes
• Sites em que as imagens não possuem descrições, ou textos informativos
• Sites em que não dão para navegar com o teclado
• Sites que não possuam um contraste suficiente entre o texto e o fundo

Ou seja, desde que o usuário tenha qualquer dificuldade de acesso e/ou navegação possuindo alguma deficiência ou não, significa que seu site possui algum tipo de barreira de acesso.

Público

Pode parecer que se preocupar com acessibilidade é um tópico que abrange uma parcela pequena da população, mas se engana quem pensa isso. Só no Brasil, cerca de 6,5 milhões de pessoas possuem algum grau de deficiência visual (fonte: IBGE), e somando com todos os outros tipos de deficiências, o número chega a 45 milhões de pessoas, o que significa cerca de 1/5 da população brasileira, então é um público massivo que não se pode ignorar.

Dentre esse público, as pessoas com deficiência visual podem ser as mais afetadas, não é fácil imaginar uma navegação, dado que quase tudo na web é visual. Por isso, a acessibilidade para deficiêntes visuais costuma ser a mais utilizada para verificar pontos específicos de acessibilidade com relação ao impacto.

Além disso, costumamos dividir o mundo em pessoas com e sem deficiências, mas pode haver situações em que uma pessoa sem deficiência passe por algum acontecimento e que se tornará temporariamente dependente de acessibilidade, como por exemplo, uma pessoa que quebrou o braço e não consegue usar o mouse, ou uma pessoa que está com dor de cabeça e não consegue ler o texto. Ou seja, a acessibilidade irá ajudar até as pessoas não deficientes, fazendo com que o número de usuários que se beneficiem com estas práticas só aumentem.

Tecnologia Assistiva

Existem diversos softwares de tecnologia assistiva, que são utilizados para auxiliar pessoas com deficiência, como por exemplo:

• Softwares Leitores de tela - Utilizados para pessoas com deficiência visual ouvirem o conteúdo da página
• Softwares de ampliação de tela - Utilizados para pessoas com perda parcial de visão ampliarem a tela e/ou fontes e imagens.
• Softwares de tradução - Utilizados para pessoas com deficiência auditiva ou com dificuldade de leitura, ou que não falam a língua do site.
• Softwares de controle de voz - Utilizados para pessoas com deficiência física que não conseguem utilizar o mouse ou teclado.
• Softwares de controle por movimento - Utilizados para pessoas com deficiência física agravada, que podem utilizar a máquina por meio da visão ou por objeto preso pela boca.

Softwares de Tecnologia Assistiva, costumam transformar o modelo da página por completo, transformando-a em uma espécie de formulário contínuo, portanto, não importa se sua página possui 3 colunas, o usuário irá navegar por ela como fosse uma página com apenas uma coluna. As dimensões também se perdem, por isso não adianta falar no telefone "aperta o botão à direita" pois o usuário não vai saber onde está já que a dimensão da página foi manipulada.

Exemplos de softwares de tecnologia assistiva:

• VoiceOver - Software de leitura de tela para Mac (já embutido no kernel do sistema)
• JAWS - Software de leitura de tela para Windows (pago)
• NVDA - Software de leitura de tela para Windows (gratuito, open source, desenvolvido em Python por 2 deficientes visuais)
• ChromeVox - Software de leitura de tela para Chrome
• Orca - Software de leitura de tela para Linux (gratuito)

O NVDA inclusive é bastante utilizado por desenvolvedores, para testar a acessibilidade de seus sites, pois ele é gratuito e open source, portanto, é aberto para diversas linguagens e frameworks, além de ter uma comunidade bastante ativa.

Técnicas

Existem diversas técnicas para se fazer um site acessível, e a maioria delas são simples de serem implementadas mas fazem muita diferença para os usuários de tecnologia assistiva.

Descrição de Imagens e uso de alt

Muitas pessoas não sabem, mas o atributo alt="" é diferente de não ter o atributo alt no elemento. Quando um software de tecnologia assistiva encontra um alt="" ele irá ler, e não surtirá efeito na leitura do usuário, ou seja, um alt="" é recomendado para coisas que não surtirá efeito para o usuário - imagem de borda da página, por exemplo. Já quando não existe alt no elemento, o software de tecnologia assistiva irá ler o nome do arquivo da imagem, o que pode ser um problema, pois o nome do arquivo pode não ter significado algum para o usuário, além da leitura da extensão do artigo (.png, .gif, etc). Portanto, é importantíssimo atribuir o parâmetro alt nas imagens, mesmo que ele esteja vazio

Outra dica é utilizar textos sugestivos, e não apenas "imagem", ou "logo", pois o usuário não fará ideia de como é a logo, ou imagem, e não saberá o que ela representa. Mas também tome cuidado para não escrever uma redação, o usuário só precisa saber o que for relevante na imagem.

Bônus: O conteúdo do atributo alt é lido e utilizado para indexação pelo Google, ou seja, além de uma questão de acessibilidade, isso pode ser utilizado para SEO.

Estrutura de Cabeçalhos

É importante seguir uma boa hierarquia de cabeçalhos (os famosos h1, h2, h3...). Imagine um usuário de tecnologia assistiva que pressiona a tecla h para navegar por todos os cabeçalhos da página, pressiona a tecla 1 e navega pelos de nível 1, tecla 2 e navega pelos de nível 2, e assim por diante. Percebemos que se o site não possuir uma estrutura de cabeçalhos definida, o usuário não conseguirá navegar por ele de forma coerente.

Por outro lado, se o usuário já conhece sua aplicação e sabe que todos os títulos de notícia são de nível 2, ele pode pressionar a tecla 2 e navegar por todos os títulos de notícia, sem precisar passar por todos os cabeçalhos da página.

Um erro comum é utilizar outras tags para definir títulos, como span ou div e as estilizar, aumentando a fonte, por exemplo. Porém, essas tags não possuem significado semântico, ou seja, não possuem significado para o navegador, e por isso, não são consideradas como cabeçalhos, e devem ser evitadas.

Para evitar essa barreira de acesso, é importante seguir uma boa estrutura semântica de cabeçalhos, e não apenas se preocupar com o visual, pois um deficiente visual não estará preocupado se o título está em negrito ou vermelho, já que a forma dele saber que aquilo é um título é porque ele foi marcado como um título.

Outro problema é a utilização de múltiplos h1 na página. O software de tecnologia assistiva não saberá qual deles é o principal e qual é o secundário. Por isso, é importante utilizar apenas um h1 por página, e utilizar os demais de acordo com a hierarquia. Outro detalhe, é de não pular a ordem de cabeçalhos, por exemplo, fez um h1 e no próximo h3, esse é um erro bem comum e que deve ser evitado.

vale ressaltar ainda que além da tecnologia assistiva, o SEO, buscadores e outras aplicações também serão beneficiados por sua página utilizar um único h1 por página

Atributos

Além de definir as tags, é importante discutirmos o uso correto de atributos que um elemento pode ter, e que tecnologias assistivas irão utilizar.

1 - A role: a própria tag, ela informar o que é determinado elemento, por exemplo, h1 é um cabeçalho de nível 1, p é um parágrafo, img é uma imagem, a é um link, input é um campo de entrada, button é um botão, etc. E para cada um deles, é esperado que o navegador saiba como renderizar e interpretar da forma correta.

2 - O estado: é o estado atual do elemento, por exemplo, se um botão está habilitado ou desabilitado, se um campo de entrada está com foco ou não, se um link está ativo ou não, se o input é um radio ou buttom. etc.

3 - O valor: é o valor atual do elemento, por exemplo, se um campo de entrada está com o valor "João", se um botão está com o texto "Clique aqui", se um link está com o texto "Acesse o site", etc.

Há uma discussão sobre o placeholder substituir ou não um label. Imagina um formulário onde há o placeholder 99.999-999, um usuário que ver isso irá entender que é um campo de entrada de CEP, porém, um usuário de tecnologia assistiva não irá entender isso, pois algumas tecnologias assistivas nem sequer lêem placeholders. Por isso, é importante utilizar um label para informar o que se espera em um campo de entrada.

Ainda nessa relação de label com o input, é importante que eles estejam setados com o mesmo id e for, pois assim, o usuário de tecnologia assistiva saberá que aquele label é para aquele input. E isso se torna uma boa prática até para quem não é deficiente, pois em caso de input de tipo radio ou checkbox, o usuário poderá ativar ou desativar clicando diretamente no texto invés da caixinha minúscula.

Links

É importante definir links com ancoragem <a>link</a> e botões como <button>link</button>. Por mais que pareça óbvio, é comum encontrarmos links <a> com uma classe de estilo de botão, e isso pode ser um problema para usuários de tecnologia assistiva, pois eles não saberão que aquele elemento é um link, e não um botão.

Ex: O usuário liga para o suporte buscando saber onde concluir a compra, o suporte fala "é só apertar no botão comprar", o usuário então aperta a tecla b para navegar entre os botões e não acontece nada, pois o “botão” de comprar na verdade era um link <a>.

Outro exemplo é um link ser uma tag <span> cheia de estilização, isso causará ainda mais problema, principalmente pela perda de focus, pois mesmo que o usuário saiba que ali existe um botão de submissão, ao apertar a tecla tab para mudar o foco, a página nunca selecionará um <span>.

Porquê seguir essas recomendações?

• Acessibilidade: é importante que todos os usuários tenham acesso a sua aplicação, independente de sua deficiência, e isso serve não só para quem depende de tecnologia assistiva, mas também para usuários comuns, pois apertar um botão de checkbox pequeno, também é uma dificuldade mesmo para quem não tem problema motor, navegar no formulário pelo tab e ficar perdido, também. Então esse tipo de prática é importante para todos os usuários.
• SEO: Softwares de tecnologia assistiva nada mais são que robôs que lêem o código, e advinha, os buscadores e indexadores nada mais são que isso também, ou seja, seguir boas recomendações de acessibilidade também melhora a performance e alcance da sua aplicação.
• Testes: Tecnologias de testes como o Selenium utilizam esses mesmos processos para automatizar testes. Exemplo, se você utiliza uma tag <span> cheia de javascript para criar um botão, você terá muito mais trabalho para testar e até o Selenium terá de fazer vários arrodeios para testar também, o que seria resolvido facilmente com o uso correto da tag <button> neste caso.
• Lei: A partir de Junho de 2015, foi aprovada a lei nº 13.146, conhecida como Lei de Acessibilidade. Esta lei determina que todos os sites e aplicativos de empresas com sede no Brasil devem ser acessíveis para pessoas com deficiência, seguindo normas internacionais.

Dicas Finais

• É recomendado evitar o uso de recursos como "clicar e arrastar" para mover elementos, pois pessoas com problemas motores podem ter dificuldades em realizar tal movimento, e pessoas com deficiência visual não saberão onde está o elemento e muito menos para onde arrastá-lo (além de ser uma experiência que muito usuário nem saiba o que significa esse "arrastar").
• A utilização de cores é um assunto bem polêmico, pois muitos acham que cores são apenas para dar um toque de design, mas devemos ter cuidado para não utilizar cores para transmitir informações. Algo como clicar no botão vermelho para cancelar pode ser um problema para um usuário daltoniano, pois ele não saberá as cores corretas.

Testando a acessibilidade

Uma forma inicial e manual de testar a acessibilidade do site, é tentar navegar por ele utilizando apenas o teclado, sem utilizar o mouse, a tecla tab e setas. Isso pois o usuário de tecnologia assistiva não irá utilizar o mouse, e sim o teclado para navegar pelo site, e sem saber se determinada informação está acima ou ao lado de algo.

Outra forma é tentar instalar um software de tecnologia assistiva, e ver como ele se comporta em formulários e páginas, para tentar encontrar inconsistências e problemas de acessibilidade, além da navegação.

Existem ainda, validadores automáticos de acessibilidade, como o WAVE, que irá te mostrar os problemas de acessibilidade que o seu site possui, e até mesmo o W3C que irá te mostrar se o seu código está correto ou não. Estes validadores irão te mostrar os problemas clássicos, como imagens sem o atributo alt e links sem o atributo title, mas não irão te mostrar problemas mais complexos, como a falta de um focus em um elemento, ou a falta de um label para um input, portanto não podem ser utilizados como forma única de testar a acessibilidade.

[BÔNUS] Programação Acessível

E por mais incrível que possa parecer, alguns nobres cavalheiros se aventuram na terra da programação mesmo tendo perda parcial ou total da visão. Com isso, vale citar algumas dicas extras para caso você trabalhe com alguém com tal condição em seu ambiente de trabalho ou acadêmico.

• Evitar muitas linhas em branco entre trechos de código. (Deixará o dev confuso)
• Evitar criar arquivos com muitas linhas (Normalmente, os devs com tal condição aprendem a organizar todo o código na cabeça, então se o arquivo for muito grande, ele não será capaz de lembrar de tudo)
• Evitar deixar pedaços de código comentados (Além de confundir o dev, ele será obrigado a ouvir o assitente recitar todo o código que não é utilizado)

Conclusão

Costumam dizer que a comunidade de tecnologia é a comunidade mais diversificada, nossos dia-a-dias já são diversificados, trabalhamos em equipes diversas e em projetos e com tecnologias variadas, então ”aceitar o diferente, para nós é normal”. Isso faz com que mais e mais gente se interesse em mergulhar na tecnologia. Portanto, como disse Mary Pat Rabanaugh: A tecnologia torna as coisas para as pessoas mais fáceis. Para as pessoas com deficiência, a tecnologia torna as coisas possíveis, e como tecnologistas, é nosso dever tornar essas coisas factíveis!

Referências

Brasil. Decreto no 5.296, de 2 de dezembro de 2004. Regulamenta as Leis no 10.048, de 8 de novembro de 2000, que dá prioridade de atendimento às pessoas que especifica, e a no 10.098, de 19 de dezembro de 2000, que estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida, e dá outras providências. Disponível em: http:// www.planalto.gov.br/ccivil_03/_Ato2004-2006/2004/Decreto/D5296.htm.
Brasil. Decreto no 6.949, de 25 de agosto de 2009. Promulga a Convenção Internacional sobre os Direitos das Pessoas com Deficiência e seu Protocolo Facultativo, assinados em Nova York, em 30 de março de 2007. Disponível em: http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2009/Decreto/D6949.htm.
ABNT. Norma Brasileira ABNT NBR 9050:2004. Acessibilidade a edificações, mobiliário, espaços e equipamentos urbanos. Disponível em: http://www.pessoacomdeficiencia.gov.br/app/sites/default/files/ arquivos/%5Bfield_generico_imagens-filefield-description%5D_24.pdf.
W3C. Acessibilidade para o WAI. Disponível em: .
Web Accessibility Initiative (WAI). Home page. Disponível em: http://www.w3.org/WAI/.
W3C. Getting Started with Web Accessibility – Web Accessibility initiative – W3C. http://www.w3.org/standards/webdesign/accessibility.
Fernandes J, Godinho F. Acessibilidade aos sítios Web da AP para cidadãos com necessidades especiais, maio 2003. Disponível em: http://www.acessibilidade.gov.pt/manuais/manualv2.doc.
W3C. Introduction to Web Accessibility – Web Accessibility Initiative. Disponível em: http://www.w3.org/WAI/intro/accessibility.php#i-what.
W3C. Essential Components of Web Accessibility. Disponível em: http://www.w3.org/WAI/intro/components.php.
RENAPI. Acessibilidade Virtual – Informação ao alcance de todos. Disponível em: http://acessibilidade.bento. ifrs.edu.br/acessibilidade-web.php.
Nascimento C. Frase vencedora do concurso “Jornadas de Conhecimento sobre Acessibilidade na Web”, 2007.
The Center for Universal Design: The Principles of Universal Design, Version 2.0. Raleigh, NC: North Carolina State University. Disponível em: http://www.ncsu.edu/ncsu/design/cud/about_ud/udprinciplestext.htm.
Derivado de W3C Web Content Accessibility Guidelines 1.0 1999; Accessible Environnements: Toward Universal Design por Ronald L. Mace, Graeme J. Hardie e Jaine P. Place, Centro de Design Universal da Faculdade Estadual da Carolina do Norte, EUA, 1996. Disponível em: http://www.w3.org/TR/WCAG10/ e http:// www.ncsu.edu/ncsu/design/cud/pubs_p/docs/ACC Environments.pdf.
W3C. WAI (Web Accessibility Initiative): Developing a Web Accessibility Business Case for Your Organization: Overview. Disponível em: http://www.w3.org/WAI/bcase/#intro.
W3C. WAI: Stories of Web Users. Disponível em: http://www.w3.org/WAI/intro/people-use-web/stories.
WCAG 1.0. Recomendações de Acessibilidade para Conteúdo Web (em português de Portugal – traduzido pela Universidade de Trás-os-Montes e Alto Douro). Disponível em: http://www.utad.pt/wai/wai-pageauth.html.