Acessibilidade… no back-end?

Você pode ler esse artigo em português aqui.

Quando se fala em acessibilidade digital, a maioria das pessoas pensa que as práticas desse assunto são realizadas apenas por desenvolvedores ou designers de front-end. Embora grande parte do trabalho seja de fato nessas áreas, os desenvolvedores de back-end não são descartados do tópico.

Mas eu, como backend, não desenvolvo nenhum layout de tela, apenas escrevo algumas linhas de HTML de vez em quando, como nesse cenário eu poderia estar ajudando em alguma coisa?

Bem, há sempre uma maneira. Neste post, trago algumas ideias de coisas que as pessoas de backend podem fazer na área de acessibilidade.

Desempenho

Há muito tempo ouvimos que é extremamente importante fazer otimizações de desempenho em nossas aplicações, e isso costuma ter dois motivos principais:

• O desempenho pode ser um fator chave para o usuário concluir uma compra , e a falta de desempenho em um site pode resultar na perda de clientes em potencial;
• O Google tem a pontuação de desempenho como fator de ranqueamento em seu buscador .

Leva em média 3 segundos para o usuário desistir de acessar uma página porque ela ainda não carregou . Mas vamos imaginar um cenário onde o usuário é persistente e quer passar “esse tempo todo” esperando: logo no início do fluxo ele já vai ter uma impressão ruim, e essa lentidão pode causar ansiedade ou raiva que pode (e provavelmente vai ) influenciam toda a experiência do usuário.

Internacionalização

Internacionalização tem tudo a ver com acessibilidade. Na prática, as duas técnicas têm um objetivo comum: tornar o conteúdo da tela compreensível para o usuário .

Este é um trabalho que varia entre diferentes sistemas para ser considerado um “backend job” ou “frontend job” (ou ambos), mas é um fato: quando algo que é projetado para ser multilíngue está sendo desenvolvido, um trabalho de internacionalização consistente deve ser feito. Você já entrou em um site “traduzido” para o inglês, mas notou vários textos em outro idioma? Sim, não siga esse exemplo.

Oh! Isso pode parecer tão simples que nem precisava ser mencionado, mas às vezes é bem fácil de esquecer: use o langatributo em seu HTML, esse atributo geralmente é usado no elemento raiz da página ( htmltag) mas também pode ser usado quando uma parte específica da página está em um idioma diferente do restante do site. Este atributo é muito importante para o navegador identificar o idioma que está sendo utilizado pela página e sugerir traduções automáticas com base no idioma do usuário.

Aprenda o básico

Mesmo que não necessariamente faça parte do seu trabalho diário, é recomendável saber o que é acessibilidade e como ela funciona no contexto de uma aplicação Web/Mobile. Muitas vezes, as pessoas de back-end escrevem algumas linhas de HTML e, quando isso acontece, as páginas geradas podem não ser estruturadas da maneira mais acessível possível.

Converse com pessoas de outras áreas

Se sua equipe já tem uma certa maturidade em acessibilidade em áreas como frontend e design, converse com pessoas dessas áreas para saber como é feito esse trabalho e como você pode ajudá-los. Talvez seja apenas uma questão de adicionar um campo de descrição da imagem para ser usado em uma imagem alt ou informação extra no detalhe do seu produto, e sim, esses detalhes podem parecer tão pequenos que podem parecer insignificantes, mas junto com outras melhorias acabam fazendo um grande diferença.

Limite o tempo para concluir as ações

O tempo não deve ser uma limitação que impeça o usuário de realizar uma atividade, ou seja, se o usuário precisar de 5 minutos ou 1 hora para enviar um formulário, que seja, o aplicativo precisa estar preparado para os dois cenários.

Claro, não podemos ignorar o fato de que várias limitações técnicas podem nos impedir de fornecer isso, mas é sempre bom evitar esse tipo de problema que só deixará o usuário frustrado. Além disso, como explica o W3C , existem algumas exceções a esta regra:

• Eventos em tempo real: deve haver um limite de tempo para a atividade, por exemplo em um leilão online.
• Atividades onde o tempo é essencial: o tempo é um fator essencial, e aumentar o tempo limite tornaria a ação inválida, por exemplo numa oferta disponível por tempo limitado numa loja online.
• Limite de 20 horas: embora seja improvável que uma tarefa demore mais de 20 horas seguidas para ser concluída, isso foi escolhido como limite pelo W3C, depois disso é permitido um limite de tempo.

Como recomenda o W3C , precisamos disponibilizar uma forma de mostrar o significado de uma abreviatura quando utilizada em uma página, para ajudar os usuários que:

• têm dificuldade em interpretar o que significa uma sigla;
• depende dos leitores de tela;
• ter memória limitada;
• têm dificuldade de usar o contexto onde estão para entender o significado da sigla.

Reautenticação

Imagine o seguinte cenário:

Minha banda favorita de todos os tempos vai estar perto de onde moro e tenho a rara chance de realizar esse sonho de vê-los. Sabendo que a concorrência para conseguir os ingressos será grande, crio minha conta no site e estou só esperando os ingressos ficarem disponíveis. Quando finalmente chega esse momento, pego meu tíquete, digito o número do cartão de crédito e tudo, mas… só quando clico para finalizar a compra sou desconectado. Nesse momento fico desesperado: tento rapidamente logar novamente, e quando tento efetuar a compra vejo a triste mensagem… ingressos esgotados.

Não é legal, certo? Sim.

Ok, isso é um problema, mas o que isso tem a ver com acessibilidade?

De fato, isso não é um problema apenas de acessibilidade, mas se essa situação causa frustração para usuários que não possuem nenhuma limitação, imagina como é para quem só pode usar o mouse ou depende de um leitor de tela para navegar?

É por isso que devemos ter cuidado ao implementar fluxos que requerem autenticação, o usuário deve poder continuar a atividade sem perder nenhum dado caso a sessão expire. Neste cenário de ticket existem algumas soluções que amenizam o problema:

• Estenda a duração da sessão periodicamente enquanto o usuário estiver ativo no site;
• Reserve o ticket e salve os dados do formulário à medida que o usuário for digitando, caso não consiga finalizar o preenchimento por algum motivo e queira continuar depois;
• Forneça uma opção para reautenticar sem sair da página atual e continue o fluxo após a reautenticação.

Nos casos em que é possível fazer buscas por texto para encontrar conteúdos, é interessante ter um mecanismo que sugira conteúdos com nomes parecidos, caso o sistema suspeite que o usuário errou alguma palavra na busca. Desta forma, evitamos que o usuário faça uma segunda busca, corrigindo o erro e só então encontrando o que deseja.

Como em muitas coisas quando se trata de acessibilidade, o corretor ortográfico ajuda todos os tipos de usuários, mas especialmente pessoas com baixo nível de escolaridade e pessoas com algum tipo de deficiência cognitiva, como dislexia.

Empacotando

Ok, mas e se nenhuma dessas dicas se aplicar ao meu trabalho diário de back-end? Ainda preciso ter conhecimentos de acessibilidade?

Bem, como a área de tecnologia está cada vez mais popular e inclusiva, e a entrada de novas pessoas (inclusive pessoas com deficiência) está aumentando também, um conhecimento básico do assunto pode ajudar não só o backend, mas todos em uma equipe, dessa forma podemos entender as necessidades não apenas dos usuários para quem desenvolvemos os sistemas, mas também de possíveis colegas de trabalho que possam ter tais necessidades.

Vale ressaltar também que acessibilidade não é responsabilidade apenas de quem trabalha com front-end, back-end, design e QA, mas todos que passam por qualquer etapa da concepção do software podem contribuir.

Referências

• Sim, a acessibilidade também é uma preocupação de back-end (Eric Bailey)
• Tempo Ajustável - Comportamentos exigidos por limites de tempo (W3C)
• Abreviaturas (W3C)