Principais Causas da Falta de Acessibilidade

Foram recolhidas e analisadas as principais causas da falta de acessibilidade digital, enunciadas pelos entrevistados.

Categorias: Existem poucas ferramentas para testar a acessibilidade; A falta de formação na área é impeditiva; No software nativo é pior por haver menos gente a desenvolver; A acessibilidade falha sempre que há uma nova tecnologia ou atualização.

Como o mencionado por um dos entrevistados, docente no ensino superior com mais de 20 anos de experiência na área da acessibilidade digital, uma das possíveis causas é a falta de ferramentas para testar a acessibilidade (entrevista 10). No entanto, o autor acredita que mesmo as já existentes ficam obliteradas pela falta de conhecimento de quem faz desenvolvimento e de quem ensina a desenvolver. É um facto que os mais modernos ambientes de desenvolvimento, sejam para Android, iOS, MacOS e Windows, trazem,

68

nativamente, várias ferramentas que ajudam a validar o desenvolvimento com atenção à acessibilidade digital. Por exemplo, o Android Studio alerta para falhas de acessibilidade, a par de outros tipos de problemas, providenciando formas de ir para a zona problemática do código, ou, no XCode da Apple, O Accessibility Inspector permite testar opções como tamanhos do Dynamic Type, cores invertidas, etc. Este IDE permite, ainda, realizar uma auditoria onde são encontrados problemas comuns e são sugeridas soluções. Nos sistemas operativos onde se pretende correr a aplicação, com facilidade se ativam ferramentas de acessibilidade que permitem validar o código no dispositivo hospedeiro. Por exemplo, no Windows 10 ativa-se e desativa-se o leitor de ecrã nativo, o Narrator, simplesmente pressionando as teclas crlt+Windows+enter. Na Web, a W3C é a referência, e no seu site podem ser encontradas várias ferramentas de testes de acessibilidade. Na verdade, apesar de não se poder afirmar que sejam populares, as ferramentas para aferir a acessibilidade digital vicejam desde os ambientes de desenvolvimento, passando pelos sistemas operativos, incluindo, ainda, diversos agentes de utilizador – e.g. Chrome, Firefox.

Outro dos principais problemas sublinhados pelo mesmo entrevistado, mencionados por todos os outros, uns com mais e outros menos enfoque, é a falta de formação na área (Putnam et al., 2016). Aí, o entrevistado em causa levantou questões interessantes, que podem estar relacionadas. Foi dito que no software nativo a acessibilidade se apresenta pior do que na Web, uma vez que o desenvolvimento de software nativo implica uma maior complexidade no seu desenvolvimento – e.g. envolve compilação –, em contraste à Web, onde mais pessoas podem almejar o desenvolvimento, ou seja, é mais fácil desenvolver para a Web do que para ambientes nativos. Esta ideia, com a qual o autor concorda, pode ajudar a explicar o avanço em investigação na acessibilidade Web, contrariamente ao software nativo (Putnam et al., 2016), facto este com que o autor se tem confrontado, e publicado em artigos com revisão pelos pares no âmbito da presente investigação. O problema da falta de formação poderá ser difícil de mitigar, uma vez que as pessoas responsáveis terão de mudar as suas prioridades (Putnam et al., 2016), incluindo pessoas em posições estratégicas, como por exemplo, na A3ES – Agência de Avaliação e Acreditação do Ensino Superior.

69

“(…) se houver necessidade de usar uma nova tecnologia a acessibilidade pode ficar para trás porque é o que acontece com as novas tecnologias ficando versões antigas mais acessíveis que uma mais recente.”

Docente no ensino superior com mais de 20 anos de experiência na área da acessibilidade digital. Entrevista 10

O entrevistado em causa alertou para algo que quem necessita da acessibilidade sente volta-e-meia: o facto desta falhar quando surgem novas tecnologias. De facto, o autor, apesar da sua experiência, confessa ansiedade sempre que acontecem coisas simples, como uma atualização de software, uma vez que a acessibilidade pode falhar, situação também apontada por outros autores (Meddaugh, 2017; Shinoara et al., 2018), e, como consequência, um software importante, ou mesmo todo o dispositivo, pode ficar inutilizado até chegar a ajuda adequada. Nestas situações – e.g. atualizações, novas tecnologias –, o aumento da formação e o conhecimento das ferramentas existentes, podem mitigar vários dos constrangimentos causados por estas situações.

Categorias: Público alvo reduzido por ser considerado apenas o constituído por pessoas com deficiência; Time to market; Desconhecimento das guidelines de usabilidade e acessibilidade por parte das equipas de desenvolvimento.

Outro entrevistado referiu como uma das principais causas impeditivas da implementação de acessibilidade digital, a ideia de que esta serve apenas pessoas deficientes (entrevista 11) (Savage, 2013). Lamentavelmente, o facto de a acessibilidade digital ter um impacto positivo na generalidade da usabilidade, característica bastante valorizada nos dias que correm, não estar a ser o suficiente para convencer os especialistas na área da User Experience (Couto, 2018; Nogueira et al., 2019), ou ainda as técnicas de Search Engine Optimization serem vicariantes às de acessibilidade digital (Leitner et al., 2016) – e.g. atributo alt de html bem aplicado –, não estarem a surtir efeito na área do Web Design, bem como a possibilidade de utilização de um mesmo website em ecrãs grandes e ecrãs pequenos, usando

70

técnicas sobreponíveis às de acessibilidade digital (Lee & Benbasat, 2004), pode indicar que a informação não é, ou está, patente, pelo menos de uma forma clara e, acredita o autor, demonstra que não está presente no subconsciente dos agentes, uma vez que estes não agem em conformidade com a informação disponível. A juntar a isto, é facto que a acessibilidade digital ajuda a população mais idosa a mitigar os efeitos nefastos da vetustez (Newell et al., 2011; Savage, 2013; Leitner et al., 2016; Putnam et al., 2016; Fang & Truong, 2018; Katerattanakul et al., 2018), o que talvez não esteja interiorizado por quem encomenda e por quem faz software para venda.

A questão dos benefícios económicos, que devia ser deixado para quem sabe discorrer sobre essa ciência social, pode ser abordada, leviana e modestamente, pelo autor, arriscando dizer que existe muito dinheiro envolvido no avultado número de pessoas com algum tipo de incapacidade (Lee & Benbasat, 2004; AbilityNet, 2008; Savage, 2013; Pascual et al., 2014; Leitner et al., 2016; Putnam et al., 2016; Katerattanakul et al., 2018; Song et al., 2018).

O time to market, outra das questões apontadas como possível causa da problemática em debate, sem querer arriscar indolência, nem querendo ser despiciente, porque afinal, é de dinheiro que se está a tratar, poderá ser aplacada, acredita o autor. Para tal, há que apostar na qualidade inerente a um produto acessível, destacando as vantagens adquiridas (Savage, 2013; Shinoara et al., 2018), que tornarão um produto “topo de gama”, tal como referiu uma entrevistada (entrevista 17). Esta aposta resultará em caso de estratégia de médio/longo prazo, com ganhos não imediatos mas progressivos e firmados, dado que poderá vir a ser um fator diferenciador positivo desse software (Katerattanakul et al., 2018), como referiu outro dos entrevistados (entrevista 26) . Sendo capaz de demonstrar exemplos concretos, pode almejar-se que um agente decisor tenha a capacidade para esperar tempo suficiente (Conway & Fitzpatrick, 2017) – período de recuperação do investimento –, e ver o seu investimento – e.g. investimento financeiro, investimento humano - chegar aos famígeros lucros (AbilityNet, 2008) que guiam a sociedade moderna, ao mesmo tempo que a qualidade de um produto acessível chame a atenção do mercado que, como disse um entrevistado, ditará a implementação de acessibilidade: "Isso só vai acontecer se o cliente vir valor acrescentado nessa capacidade. Se o mercado não exigir, pode estar escrito em todos os livros que nunca vai ser feito. " Gestor de projeto numa multinacional (entrevista 14).

71

Outra das possíveis causas para a não implementação de acessibilidade digital alegadas por um entrevistado, é o desconhecimento dos standards de usabilidade e acessibilidade por parte das equipas de desenvolvimento (entrevista 11) e, acrescenta o autor, de quem as deveria ensinar. Nesta área, como o apontado por uma entrevistada, a enorme profusão de documentação é um problema (entrevista 3), bem como o apontado por outro: saber quais as maiores referências da área (entrevista 10). Estes problemas – i.e. desconhecimento das linhas orientadoras; excesso de documentação; maiores referências –, intentaram-se mitigar na “Ferramenta de Apoio à Prática”, publicada em artigos científicos com revisão pelos pares – que pode ser consultada na secção 4.2.2.do presente trabalho –, onde foram agregados, e discriminados, por tipo de projeto, os standards e guias considerados adequados, de acordo com as que foram consideradas as maiores referências. Esta ferramenta pode ser consultada na secção 4.2 – Alterações ao método.

Categorias: não fazer análise de utilizadores e tarefas com um utilizador que precise de acessibilidade; Não desenvolver testes específicos para utilizadores com deficiência; Falta de métricas para avaliar tarefas com acessibilidade; Os produtos têm curta duração de vida.

Outro entrevistado, docente no ensino superior e especialista em desenho de interação, apontou como uma das principais causas não fazer análise de utilizadores e tarefas com indivíduos que precisem de acessibilidade (entrevista 25). Este problema, aparentemente, é transversal a muito do desenvolvimento que é feito, e é, potencialmente, uma das principais causas pela usabilidade e acessibilidade claudicante numa miríade de projetos.

Relativamente à acessibilidade para mitigar carências funcionais – assunto o qual recebe o enfoque deste escrito – uma possibilidade é expor os programadores, durante a sua formação, a pessoas com deficiências, o que acrescentará benefícios inauditos e, mais-ou- menos, inescrutáveis (Ladner, 2015; Putnam et al., 2016; Shinoara et al., 2018), tanto de engenharia como sociais.

72

Outro dos principais problemas, apontados pelo entrevistado em questão, é a falta de testes específicos para pessoas com deficiência e o que isso pode implicar – e.g. métricas específicas para avaliar a acessibilidade de um projeto. Esta questão, será, eventualmente, visada em trabalho futuro.

No entanto, será oportuno citar, e desenvolver, o comentário de um entrevistado: "(…) há muito aquela teoria e na web isso é comum que é as pessoas, os developers ou os testers acharem que conseguem pegar num leitor de ecrã e fazer os testes como se fossem um cego ou sei lá, pegar numa daquelas interfaces de switch e fazer, usar o computador como se fosse uma pessoa com mobilidade reduzida. Isso não é assim. Como aquela coisa que o pessoal que fica vendado e vai andar pela rua fora a experimentar como é ser cego. Não é a mesma coisa. Porque não tem as mesmas ferramentas e o mesmo treino e a mesma proficiência no uso do leitor de ecrã que terá um cego.”

Engenheiro de software cego. Entrevista 31

É relevante ter pessoas com deficiência a testar as funcionalidades, bem como dar noções aos engenheiros de software de como as pessoas com a deficiência que se pretende mitigar utilizam o software a desenvolver. Neste campo, foi revelador o episódio ocorrido durante a validação da proposta de método e que não estava a avançar. Havia um bloqueio mental apenas porque o programador, que estava a fazer a validação, não concebia a forma de um cego interagir com um teclado num ecrã tátil de um iPhone. Após uma rápida e simples demonstração, a validação avançou sem problemas e com sucesso.

A curta duração de vida dos produtos foi um argumento apresentado por um dos entrevistados (entrevista 12) como outra possível causa da falta de acessibilidade digital. A afirmação ganha fundamento ao ter-se em conta o contexto profissional do entrevistado – gestor de projeto numa multinacional que desenvolve soluções à medida para a indústria –, facto que leva a considerar como solução viável a utilização e/ou desenvolvimento de elementos de interface com utilizador reutilizáveis e com características de acessibilidade. É motivador imaginar o avanço na inclusão social que esta possibilidade promoveria junto das

73

pessoas que beneficiam com a acessibilidade digital, ao permitir-lhes um acesso a mais postos de trabalho, ou a executarem as tarefas de uma forma mais eficiente.

As questões da formação e da sensibilidade, por terem sido mencionadas por todos os entrevistados, algumas mesmo várias vezes ao longo das entrevistas, merecem um texto à parte. De resto, as possíveis causas mencionadas pelos entrevistados foram todas abordadas nesta secção, uma vez que, como faz sentido, na opinião do autor, são concomitantes e vicariantes entre si.

No entanto, ficou absolutamente claro na cabeça do autor, que a principal causa da inexistência de níveis adequados de acessibilidade digital é a falta de noção do dinheiro que se pode ganhar e/ou como o fazer, através da acessibilidade digital. Portanto, o dinheiro é merecedor de um parágrafo dedicado, não por ser uma abstração benfazeja, talvez até mormente pestífera no contexto do assunto a ser tratado, mas tanto mais por ser o que governa o mundo onde vivemos, e ter sido mencionado por todos os entrevistados. “Lucro”, “Custos”, “Perder Dinheiro”, “Time to Market”, “O mercado não obriga”, foram expressões usadas que manifestam a relevância do dinheiro, sendo que seria um disparate, acredita o autor, enveredar pela moralidade, benevolência e compaixão. Apesar de se gostar de dizer que estes princípios distinguem os humanos e, acredita o autor, são o zénite da humanidade, são características existentes mas frequentemente soçobradas pelas mais simiescas, tornando as atitudes mais próximas do nadir, bastante afastadas dos discursos beatíficos. E, não só por isto mas também por isto, o autor não resiste, neste ponto, em inserir neste escrito uma citação de Aldous Huxley (1987), num dos seus ensaios de Regresso ao Admirável Mundo Novo: “Mas o indispensável não é indispensavelmente o desejável. O que é seguramente bom na esfera da economia, pode estar muito longe de ser bom para os homens e mulheres como eleitores ou até como seres humanos.”

4.1.1.3. Requisitos de Software

"(…) no início quando estamos a falar de programadores e pessoas que nunca fizeram. Que é uma novidade para elas. Na primeira vez que tentarem, vai demorar um pouquinho mais, não é? Mas é como tudo. É como estas APIs, é igual. É uma abordagem nova. Aprende-

74

se. Claramente que nos projetos seguintes, nas fases seguintes já não vai ser uma dificuldade. É mais uma coisa como outra qualquer.”

Gestor de Projeto numa multinacional. Entrevista 29

Relativamente à acessibilidade estar patente nos requisitos, ficou claro que é fundamental e tem que ser pedido pelo cliente, de que nunca deverá passar a mensagem que a acessibilidade digital deixou de ser importante. É ainda necessário que seja um requisito bem definido, portanto, detalhado.

A recolha de documentação relativa à acessibilidade é algo considerado importante, e potencialmente reciclável para projetos futuros – com as devidas atualizações –, sendo que em contextos excecionais pode ser contraproducente – e.g. investigação; invenção.

Foi de concordância comum a ideia de que a acessibilidade deve ser implementada desde o início de um projeto (Shinoara et al., 2018), sendo que alguns entrevistados elencaram vantagens interessantes – e.g. facilidade na uniformização do código; melhorias na comunicação entre membros da equipa de desenvolvimento –, e ainda a recuperação do tempo extra que é despendido no início do projeto nas fases posteriores (Savage, 2013). Por exemplo, o trabalho de especificação poderá mitigar o venturo esforço extra em futuros projetos, e essa mitigação será incremental, ou seja, à medida que os conceitos forem apreendidos, os futuros projetos serão mais fáceis (Conway & Fitzpatrick, 2017).

No âmbito de um mesmo projeto, um dos especialistas em acessibilidade entrevistados referiu que algumas das mitigações conseguidas com o trabalho executado nos passos iniciais podem materializar-se em testes bem definidos e, desta forma, evita-se testar a acessibilidade tardiamente.

75

4.1.1.4. Testes de Software

Relativamente a testes de utilização no software, os entrevistados, na sua maioria, mostraram-se conscientes de vários desafios, tanto aos testes propriamente ditos, como à sua documentação de apoio – i.e. guião de testes.