ODS 10

Este ODS é muito importante para a sociedade num todo e, qualquer medida que possa ser tomada em sua contribuição, deverá ser. Num processo de desenvolvimento de software, devemos ter este ODS em mente, com a proposta de contribuir num microcenário para atingir o macro. Ufua et al. (2021) citam “[..] a marginalização de alguns stakeholders minoritários no processo, cujo interesse pode não ser devidamente considerado no processo de transformação digital e implementação dos ODSs” como motivo para “a resistência de certas partes interessadas que são afetadas ou envolvidas no processo de transformação digital”. De fato, se as necessidades de um usuário, por exemplo, não são contempladas no uso de um software, ele irá resistir à utilização deste. Swartz et al.  (2021) citam que as questões relacionadas às pessoas envolvidas num processo de implantação de software, características deles e suas relações são fatores mais desafiadores do que dificuldades de acesso a tecnologias, ainda Heijsters et al. (2023) afirma a importância de envolver a percepção dos usuários para permitir a adaptação do software a especificidades como idade, alfabetização ou deficiências. 

Os fatores listados na Meta 10.2 podem ser considerados como critérios de inclusão num software e a Meta 10.3 quando fala em garantias de oportunidades podemos entender que a oportunidade de usar um software qualquer deve ser dada a todos, conforme o objetivo do software, independente dos fatores listados na Meta 10.2.

Desde a concepção do sistema até a fase de testes deve ser considerada se a usabilidade abrange as necessidades de diferentes usuários. 

Nas fases iniciais do projeto de software, desde a concepção até a prototipação, por exemplo, deve-se considerar o uso do software por diferentes usuários em diferentes contextos. Através de pesquisas, consultas a especialistas ou com o envolvimento de usuários chave nessas etapas, considera-se que o software poderá ser utilizado por quaisquer pessoas independentemente de suas particularidades. Segundo Martínez et al. (2022), afirmam que “projetar e desenvolver uma ferramenta [..] e, depois de concluída, aplicar um novo ciclo de desenvolvimento para torná-la acessível, por exemplo, para pessoas com deficiência visual. Esta é uma maneira errada de apresentar a solução para o problema. Ao fazer isso, a adaptação do aplicativo final é afetada por decisões de design anteriores e ambos, os desenvolvedores e as empresas que financiarão o projeto, serão forçados a realizar dois desenvolvimentos: primeiro eles implementarão o aplicativo seguindo uma metodologia padrão, e então eles vão adaptá-lo para torná-lo acessível. Esta adaptação implica um aumento dos custos de desenvolvimento, o que significa, em muitos casos, que não é implementada para poupar custos” (MARTINEZ et al., 2022).

À luz do princípio da usabilidade, especialmente o item de acessibilidade da ISO 25010:2011, podem-se adotar medidas simples, por exemplo: no caso de uso de textos em tela usar fontes conhecidas como Times New Roman ou Georgia (fontes serifadas), ou Arial, Helvetica ou Verdana (fontes não-serifadas) que são facilmente reconhecidas e contribuem para a compreensão de usuários com baixa acuidade visual e dificuldades relacionadas à alfabetização, pois estas são fontes populares, antigas e de fácil compreensão. Por exemplo, Tarita-Nistor et al. (2013) trazem em seu estudo que os melhores resultados obtidos nos testes com um grupo que possuía degeneração macular relacionada à idade, foi utilizando a fonte Courier, que é serifada. Minakata et al. (2023) cita que a grande popularidade das fontes serifadas aumenta as chances de reconhecimento das letras e, por consequência, da leitura. Nos estudos citados também é falado sobre o tamanho das fontes, portanto opções de aumentar ou diminuir o tamanho da fonte no software também pode ser uma medida válida a ser adotada.

Ainda neste nicho da escrita, podemos dizer empiricamente, já que ainda não há conclusões acadêmicas e bibliografia suficiente sobre o uso de linguagem neutra, que é necessário ter cautela ao utilizar-se este tipo de recurso, pois testes com leitores de tela podem não reconhecer palavras quando escritas com “@” ou “x” no final, como “del@” ou “delx”, o uso do “u” ao final também pode levar a uma confusão no contexto, por uma geração de parônimos como “elu”. Portanto deve-se atentar aos usuários-alvo do software para não excluir um grupo em detrimento de outro.

A grande maioria da população possui a capacidade de comunicação oral, “considera-se a incidência de surdos pré-linguísticos na base de 1 a 4 a cada 1.000 habitantes” (SILVA et al. 2021 apud BUBBICO et al., 2007)¹, sendo que surdos pré-linguísticos são as pessoas que nasceram surdas ou adquiriram surdez antes de aprender uma linguagem oral. Existem ferramentas para tradução dos textos em tela para linguagem de sinais. No Brasil, por exemplo, temos o VLibras, disponibilizado pelo governo federal que traduz textos em português para a linguagem brasileira de sinais, utilizando um avatar, conforme Silva et al. (2022) e aponta que o VLibras “é importante como um projeto sem fins lucrativos com um modelo livre, aberto e colaborativo com amplos impactos positivos na comunidade surda” (SILVA et al., 2022). Nos estudos de Silva et al. (2021) são apontados problemas na tradução feita pelo VLibras, como textos grandes terem pausas durante a tradução, dificultando a tradução simultânea. Todavia é uma ferramenta válida que, apesar de precisar de aperfeiçoamento, auxilia na utilização de websites por pessoas surdas. 

Uma ferramenta interessante e amplamente difundida é a cartilha de acessibilidade da W3C (grupo de colaboração internacional para auxiliar no crescimento da web através de padrões), a WCAG 2.1, desenvolvida por um grupo de trabalho focada com acessibilidade na web, e a partir daí surgem também, diretrizes para acessibilidade em aplicativos móveis (CHICANELLI et al., 2018). Resumidamente, as diretrizes para acessibilidade da WCAG 2.1, segundo Todorov et al. (2022) são:

“- Perceptível - as informações e os componentes da interface do usuário devem ser apresentáveis aos usuários de forma que possam ser percebidos;

- Operável - Os componentes da interface do usuário e a navegação devem ser operáveis. A interface não pode exigir interação que um usuário não possa realizar;

- Compreensível - os usuários devem ser capazes de entender as informações, bem como a operação da interface do usuário;

- Robusto - o conteúdo deve ser robusto o suficiente para que possa ser interpretado de forma confiável por uma ampla variedade de agentes de usuário, incluindo tecnologias assistivas.” (TODOROV et al., 2022)

Em sua pesquisa Todorov et al. (2022) traz a avaliação de sites de museus na Bulgária, através de testes automatizados baseados na WCAG 2.1 e de testes manuais por usuários cegos ou com deficiência visual, concluindo que a maioria dos sites avaliados não atendem a média de critérios de acessibilidade. Sites que serão disponibilizados a toda população, como no exemplo, em que não se pode definir as particularidades de cada usuário, devem contar com o máximo de acessibilidade possível, podem ser utilizadas ferramentas que auxiliem nos testes, “o software de teste de acessibilidade da Web existente para sites é muito útil para desenvolvedores da Web e criadores de sites, bem como para instituições” (TODOROV et al., 2022), nestes casos de aplicações disponíveis para grandes públicos deve-se considerar estratégias como esta ferramenta de teste automatizado, já na concepção dos testes, sendo que a acessibilidade de usuário não pode ser negligenciada desde a concepção inicial do projeto.

Em sua pesquisa Todorov et al. (2022) trazem a avaliação de sites de museus na Bulgária, através de testes automatizados baseados na WCAG 2.1 e de testes manuais por usuários cegos ou com deficiência visual, concluindo que a maioria dos sites avaliados não atendem a média de critérios de acessibilidade. Sites que serão disponibilizados a toda população, como no exemplo, em que não se pode definir as particularidades de cada usuário, devem contar com o máximo de acessibilidade possível, podem ser utilizadas ferramentas que auxiliem nos testes, “o software de teste de acessibilidade da Web existente para sites é muito útil para desenvolvedores da Web e criadores de sites, bem como para instituições” (TODOROV et al., 2022), nestes casos de aplicações disponíveis para grandes públicos deve-se considerar estratégias como esta ferramenta de teste automatizado, já na concepção dos testes, sendo que a acessibilidade de usuário não pode ser negligenciada desde a concepção inicial do projeto.

O nicho de raça e etnia jamais pode ser negligenciado na construção de um software. Souza et al. (2021) demonstram em seu estudo o quanto algoritmos utilizados na justiça criminal americana são tendenciosos ao reconhecimento de culpados quando analisam pessoas negras ou com traços hispânicos, evidenciando o racismo enraizado na sociedade.  Sandvig et al. (2016) abordam o exemplo do algoritmo das câmeras de computadores HP, que na época, não detectaram a imagem de rostos negros, fato que foi rapidamente corrigido pela fabricante após a repercussão negativa do caso. Sandvig et al. (2016) afirmam, ainda, que provavelmente os desenvolvedores que trabalharam na solução assim como a empresa em si, não tinham a intenção de serem racistas nesse caso. Pode-se concluir que houve uma falha na inclusão de diferentes amostras de rostos para detecção do algoritmo nessa situação. Pensando nos tempos atuais e nos ODSs, tal falha seria inadmissível na construção de um software. No exemplo da HP, uma fabricante industrial, com produção massiva que não teria como inferir sobre todos os usuários de um produto, o que podemos fazer é ampliar ao máximo a visão holística sobre os possíveis usuários, para evitarmos este tipo de situação. Cabe a nós, como pesquisadores e desenvolvedores, atentar para que estas situações não aconteçam, inclusive em fatores simples como uso de avatares num software.

Nunes et al. (2023) abordam que a área de tecnologia da informação e comunicação (TIC) ainda possui formas de discriminação de gênero, sendo uma área ainda dominada por homens, ilustra que “as mulheres representam apenas 3% dos graduados em TIC em todo mundo” (NUNES et al., 2023 apud UNESCO, 2017)². Essa disparidade de gênero pode resultar em produtos com viés misógino e/ou machista, visto que a maioria das equipes são formadas apenas por homens, Nunes et al. (2023) citam a criação de tecnologias cor de rosas e simplistas quando voltadas a mulheres, como jogos digitais sobre moda, ou an utilização de elementos em tela representando o gênero masculino “que normalmente são considerados neutros, não apenas impactam negativamente o sentimento de pertencimento das usuárias, mas também a maioria dos usuários em potencial” (NUNES et al., 2023), podemos deduzir um exemplo de alguma imagem ou avatar de um homem branco num sistema, que não é representativo para mulheres, negros e pessoas LGBTQIA+. Pequenos cuidados no desenho das interfaces gráficas podem solucionar ou ao menos mitigar essa sensação de não representatividade.

Em sua pesquisa, Nunes et al. (2023) propõem requisitos para que o software não seja discriminatório, requisitos que podem ser integrados aos requisitos funcionais e não funcionais do projeto, colocando como um dos pontos chave a importância da análise das características dos usuários do sistema para avaliar quem está priorizado e negligenciado “para a construção de um sistema de software que beneficiará todos os seus usuários, independentemente das diferenças de gênero na vida e nas responsabilidades de trabalho dos atores humanos” (NUNES et al., 2023).

Outros fatores que podem ser considerados para a não exclusão de pessoas dos projetos estão descritos na seção sobre o ODS 9.