O teste de acessibilidade é a coisa certa a se fazer. A internet com seus serviços eletrônicos é um local para as pessoas se sentirem e interagirem igualitariamente, portanto nosso software não deve excluir as pessoas, argumentou Martin Tiitmaa na TestCon Europe 2019.
No contexto do software, o teste de acessibilidade é um processo para avaliar a usabilidade do sistema por pessoas que enfrentam algum tipo de restrição que podem ser permanentes, como uma deficiência, temporárias, como um dedo quebrado ou situacionais, como usar a aplicação enquanto segura uma criança.
Tiitmaa mencionou que a determinação de realizar testes de acessibilidade veio do proprietário do produto. Como isto não é comum, forneceu três argumentos que podem convencer os proprietários sobre os testes de acessibilidade:
Primeiro, é a coisa certa a se fazer. Na política de qualquer empresa, deveria ser o único argumento necessário. A Internet e os serviços eletrônicos são ótimos lugares para as pessoas se sentirem e interagirem igualitariamente e, ao projetar e desenvolver o software, devemos ter isso em mente e não projetar coisas que podem excluir alguém. Isso deve fazer parte de todas as políticas da empresa de desenvolvimento.
Mas, se assim não for, realizar essas mudanças irá consumir um longo tempo das outras etapas de desenvolvimento, e as empresas temem que isso tenha altos custos, então minha pesquisa mostra que em termos de dinheiro essas mudanças não são caras, e já existem ótimos recursos que ensinam como fazer as alterações para tornar o código mais inclusivo. Dito isso, o segundo motivo é que essa mudança ajudará a organização a ganhar mais dinheiro.
E em terceiro lugar, se não fizermos isso hoje, teremos que fazer no futuro próximo. Nos EUA, a lei dos americanos com deficiências também inclui a Internet, e a Suprema Corte dos EUA concorda com essa ideia. Com base nos processos judiciais referentes a acessibilidade, tem-se exigido que as empresas obedeçam à norma WCAG 2.1 AA.
Na Europa, a Comissão Europeia tem uma legislação pronta para ser introduzida em 2021, ou talvez já seja colocada em prática em 2020, disse Tiitmaa. Portanto, dependendo de onde operamos, acessibilidade é, ou será, exigida em breve.
Tiitmaa explicou que em 2016 nos EUA, na faixa etária de 21 a 64 anos, 10,9% das pessoas foram afetadas por algum tipo de deficiência. "São 10% dos clientes que perdemos quando não fornecemos acessibilidade", argumentou. "Sermos inclusivos em relação aos concorrentes é ótimo para a nossa reputação, o que traz ainda mais clientes".
Podemos combinar testes modernos e de acessibilidade. Tiitmaa mencionou o princípio de teste moderno número um:
A prioridade dos testadores, é melhorar os negócios.
Ao aperfeiçoar constantemente a acessibilidade, criamos um produto melhor para todos. O uso de atalhos claros e rápidos no teclado torna as coisas mais fáceis para todos e, por padrão, também ajuda no SEO (por exemplo, atributos "title" e "alt" nos sites).
Tiitmaa afirmou que os testes modernos determinam que apenas o cliente pode julgar a qualidade, cabendo a nós, testar se a fornecemos corretamente, analisando os dados. A equipe de Tiitmaa está planejando usar mais dados para tomar as decisões, e parte deles indicaria se o usuário, por exemplo, usou um leitor de tela. "Isso nos ajudará a melhorar ainda mais nossas soluções de acessibilidade e fornecer um serviço melhor a todos", comentou.
O InfoQ entrevistou Martin Tiitmaa após a palestra no TestCon Europe 2019 sobre testes de acessibilidade.
InfoQ: Qual abordagem foi adotada no teste de acessibilidade?
Martin Tiitmaa: A mesma abordagem usada na maioria dos testes. Fizemos o trabalho em três fases: 1) Pesquisa, 2) Teste e 3) Fase de resultados. Nesse caso, foi especial a fase de pesquisa, que levou a maior parte do tempo.
O primeiro problema foi o que iríamos usar como oráculo. Em nossas pesquisas, descobrimos que as Diretrizes 2.1 da WCA (Web Content Accessibility) são reconhecidas pela indústria e também pelos legisladores. Por exemplo, nos EUA, houve decisões judiciais exigindo que uma página da web cumprisse o padrão WCAG 2.1 AA. Como existem quase 100 diretrizes diferentes a serem seguidas, reduzi-a aos quatro pontos principais que incluem: Perceptibilidade, Operabilidade, Compreensibilidade e Robustez.
Como próximo passo, analisamos que tipo de restrições de acessibilidade existem e que tipo de ferramentas ajudam a resolvê-las. As principais ferramentas usadas foram os leitores de tela, o software operacional apenas com o teclado e a visualização em alto contraste. Para os testes, usamos os três leitores de tela mais populares da época, executamos um ciclo de teste usando apenas o teclado e fizemos um ciclo de testes com uma visualização em alto contraste.
Para cobrir a maior parte de nosso produto, optamos por seguir o caminho principal de operações do usuário ou o ciclo de vida do usuário. Os fluxos que cobrimos nos testes foram a criação de uma conta, um depósito, uma retirada de dinheiro e o uso das ferramentas promocionais. Com base nos resultados dos testes, criamos uma análise de lacunas em comparação com os padrões das WCAG.
InfoQ: Como fizeram para analisar essas lacunas?
Tiitmaa: A análise de lacunas teve três categorias. Em primeiro lugar, as coisas que estavam bem, em segundo lugar, as que precisavam de pequenas mudanças ou onde atendemos ao padrão A, mas deveria passar para AA, e em terceiro, onde havia trabalho que necessitava de correção. Codificamos essas categorias com cores verde, amarelo e vermelho, e ao planejar os próximos sprints, tivemos uma visão geral de quanto uma ou várias correções levariam.
InfoQ: O que fizeram para apoiar os desenvolvedores na criação de produtos acessíveis?
Tiitmaa: Fizemos uma apresentação para toda a equipe de desenvolvimento, discutindo sobre o que é acessibilidade, o que encontramos nas pesquisas, o que é o WCAG e o que os clientes esperam de nós. Como existem quase 100 diretrizes diferentes, resumimos os principais pontos para os devs. Portanto, enquanto estamos solucionando os problemas que tivemos, não criamos novas funções sem acessibilidade no nosso software.
Por exemplo:
1) Sempre adicionar um elemento que descreva o recurso que estamos adicionando;
2) Verificar se o elemento adicionado é utilizável apenas pelo teclado;
3) Adicionar novos elementos em um caminho lógico em comparação com outros elementos de software;
4) Textos e imagens precisam ser legíveis com relação de contraste 3:1.
InfoQ: Se os leitores querem saber mais sobre os testes de acessibilidade, onde podem encontrar mais informações?
Tiitmaa: Mencionei as WCAG várias vezes. No começo, é muito difícil de entender, mas existem descrições do que é uma boa e uma má solução, e até algumas sugestões sobre como corrigi-las.
O design inclusivo da Microsoft é um ótimo recurso para entender melhor como tornar o software mais acessível.
A web accessibility in mind é um ótimo local para obter respostas a qualquer pergunta que possamos ter sobre software acessível. Lá, também existe uma pesquisa feita todos os anos, que mostra os leitores de tela mais populares em uso.