Acredito que por princípio e definição, ninguém discordará da importância da acessibilidade digital. Dos muitos anos em que trabalho em digital, embora acredite que o panorama da acessibilidade digital não seja bonito, nunca encontrei ninguém que de forma consciente dissesse “não quero que a minha aplicação seja acessível”. É certo que embora a frase não seja explicitamente dita, a verdade é que muitas das decisões que são tomadas nos projetos, é isto que querem dizer de forma prática.
Quase sempre baseado num conhecimento parco do tema, encontramos não raras vezes inúmeras razões que afastam a acessibilidade digital dos objetivos dos projetos. Questões relacionadas com o tempo acrescido ao projeto. Custos adicionais que o trabalho de acessibilidade pode trazer ao orçamento. Dificuldades ou simplificações extremas dos modelos de interação com os interfaces e que os tornam “menos interessantes ou inovadores”. Ou ainda, uma série de interpretações erradas que dão força à crença que um interface acessível não é “bonito”, são algumas das muitas “desculpas” que vemos repetidas vezes e vezes sem conta.
O termo “desculpas” não tem aqui um sentido pejorativo. Que fique bem claro. Qualquer equipa de projeto de transformação digital é composta por pessoas que acreditam, na grande esmagadora maioria das vezes, na importância daquilo que estão a fazer e dão o litro por isso. Mas o termo “acessibilidade digital”, levanta quase sempre muitos medos que podem vir a complicar ainda mais os projetos.
A bem da verdade, todos estes medos existem pela compreensão simplista do conceito de acessibilidade digital. A acessibilidade digital não é um bicho de sete cabeças. Não complica de forma nenhuma os projetos. Basta compreender o tema de forma estruturada, para perceber que é perfeitamente possível criar produtos e serviços acessíveis, dentro dos prazos e orçamentos estabelecidos para os projetos (quando definidos de forma sustentada).
Não são desculpas
A esta altura, muito provavelmente já pensaste numa ou outra ocasião que alguma daquelas “desculpas” surgiram num projeto. Se isso aconteceu, estarás com certeza a dizer qualquer coisa do género “não são desculpas”. A verdade é que são. Vamos por partes. Quando é lançado no mercado um novo produto ou serviço digital que não cumpre as mais elementares boas práticas de acessibilidade, interessa quase nada saber porque é que assim é. A verdade nua e crua é que aquele novo produto ou serviço, não é acessível. Podemos dizer isto ou aquilo. Culpar este ou aquele. Mas nada disso vai alterar o facto que aquilo que acabámos de lançar, novinho em folha, não ser acessível.
Os utilizadores que utilizam estratégias e tecnologias de apoio (e todos os outros), não vão visitar o nosso novo website e dizer “compreendo perfeitamente que este website não seja acessível, porque já não existia tempo ou orçamento”. Lamento. Isto não vai acontecer. O que vai acontecer muito provavelmente nestes casos é que aquele utilizador, vai ficar muito frustrado por não conseguir realizar uma ação muito básica. Isso levará seguramente a uma onda de indignação com aquela marca e a um testemunho muito negativo junto de amigos e familiares. Multiplica este efeito por milhares de utilizadores. Agora vê o estrago que a decisão de renegar a acessibilidade digital para segundo plano no projeto já causou, quase sem te aperceberes disso.
Não precisas de pedir licença
Muitas daquelas “desculpas” têm na base, para além de um conhecimento sumário do que é e não é acessibilidade digital, uma crença que é preciso que exista no projeto uma “autorização formal” para implementarmos boas práticas de acessibilidade em tudo aquilo que fazemos. Não precisamos. Não precisamos mesmo. E isto devia ser uma das coisas repetidas até a exaustão quando falamos de acessibilidade digital.
O essencial das boas práticas de acessibilidade digital, estão intimamente relacionadas com o básico de disciplinas como o design e o development. Por outras palavras, fazer um bom trabalho de design e development (aquilo que seguramente todos ambicionamos fazer no nosso dia a dia), é meio caminho andando para desenhar e desenvolver produtos e serviços digitais realmente acessíveis. Não acreditas? Vamos a exemplos práticos.
No development
Comecemos pelo lado do development, especialmente ao nível do Frontend. Quando falamos de acessibilidade digital, a boa semântica do código HTML desempenha um papel tão importante que é difícil descrever isso por palavras. O código HTML com uma boa semântica é um passo de gigante para uma solução acessível. É claro que só isso não chega. Mas o impacto que isso terá é esmagador.
Acontece que fazer um HTML semântico é fazer o básico do HTML. Quando num projeto se diz, “vamos fazer HTML”, está inerente que esse HTML tem que ser bem feito, cumprindo as regras básicas daquilo que é o HTML. Não precisamos nestes casos, pedir autorização a ninguém na equipa de projeto para fazer um bom HTML. Fazemos e pronto. O problema é que muitos dos problemas de acessibilidade, estão relacionados com problemas na semântica de HTML. Lá está, uma coisa básica que podíamos ter feito desde o inicio e para a qual não precísariamos de pedir “licença”.
No design
Também pelo lado do design, temos muitos aspectos básicos daquilo que é (ou deveria ser) a atividade dos designers e que são também, contributos fundamentais para a boa acessibilidade das soluções. Vamos a exemplos práticos. Não precisamos pedir licença a ninguém na equipa de projeto, para garantirmos que o contraste de cores entre os textos e os fundos e os tamanhos dos textos vão ser confortáveis à leitura. São dois aspectos fundamentais do design. Garantir uma boa leitura de todos os elementos no interface.
Mas a verdade é que mesmo sendo aspectos muito elementares, encontramos inúmeras soluções com problemas de contrastes de cor e legibilidade. Não acreditas? Basta consultar o estudo The WebAIM Million, para perceber que os contrastes de cor, são ainda um dos erros mais recorrentes de acessibilidade. Como vês, não precisamos pedir licença a ninguém para fazer um bom teste de cor, mas os erros continuam a aparecer. E estes são só dois exemplos. No que toca ao design, podíamos elencar um conjunto muito maior de coisas básicas da disciplina, que deveriam à partida ser garantidas e que todas juntas seriam também um contributo muito importante para a acessibilidade digital de qualquer solução.
Quanto tempo mais vais esperar?
Chegados aqui a pergunta é só uma “quanto tempo mais precisas para começar a fazer o básico de acessibilidade digital, que é também o básico do design e development?”. Podemos dizer que o projeto não tem enquadramento de acessibilidade. Que não existe tempo previsto para este trabalho. Que o orçamento é curto. Que o Project Manager ou o Product Owner não sabe o que é acessibilidade digital. A verdade é que existem muitas coisas, as mais básicas e com um impacto muito grande, que poderias estar a fazer e não estás. E isso quer dizer na prática, que os produtos e serviços digitais em que estás a trabalhar neste preciso momento, poderiam ser mais acessíveis daquilo que realmente serão.
Todos os profissionais têm um papel preponderante na acessibilidade digital. Para a construção e manutenção de produtos e serviços digitais realmente acessíveis é fundamental que todos estejam à mesa. Contudo, os designers e os developers podem ser excelentes embaixadores do tema nas equipas. Não só porque estão muito perto da prática, mas principalmente porque podem, mesmo em contextos com uma cultura de acessibilidade relativamente baixa, fazer a diferença. Este texto é um reflexo profundo e verdadeiro dessa crença. Uma manifestação poderosa que pequenas ações no dia a dia podem ajudar em muito a tornar a tecnologia um fator de inclusão, ao invés de contribuir para a exclusão.
Fotografia © Susan Q Yin (Unsplash)