4. Validação da Proposta de Método
4.2. Alterações ao Método
4.2.5. Teste de Proposta de Método em Cenário Real
O teste da proposta de método em cenário real, apresentou-se como uma feliz oportunidade, tendo sido feita aliando os objetivos desta investigação com o do engenheiro que se ofereceu para efetuar o teste, a sua vontade de aprender novas tecnologias, manter- se a par das últimas novidades na engenharia de software, bem como o seu interesse na área da acessibilidade digital. Desta forma, o teste foi condicionado à disponibilidade do engenheiro voluntário. O teste foi iniciado durante Março de 2019, estendendo-se até a data da redação deste escrito, e consistiu na projeção e implementação de algumas funcionalidades para uma aplicação de gestão de stocks, em que existe uma consola Web de administração, e uma aplicação móvel compilada para vários SOs, para a gestão de stock propriamente dita.
Neste teste, o papel do especialista/consultor de acessibilidade foi o próprio autor. Dada a separação geográfica, a colaboração foi feita remotamente, através de vários meios de videochamada, bem como por controlo remoto de computadores. O autor testou as versões Web da consola de administração e as versões da aplicação móvel para iOS e UWP, ficando a os testes em Android a cargo do engenheiro voluntário. Detalhes sobre o teste, bem como sobre a aplicação, podem ser vistos nesta secção. Abaixo são apresentados os comentários do engenheiro voluntário (em itálico) a cada ponto do método.
112
4.2.5.1. Especificação
Existem quatro subatividades principais nesta fase:
1. Estudo de exequibilidade – de acordo com os dados de negócio, orçamentos, hardware e software disponível, esta é a altura em que tenta perceber-se se o projeto é fazível;
Dados de negócio / orçamentos:
• Disponibilidade da empresa em participar, sendo que nesta fase inicial não há necessidade de investimento financeiro;
• Necessidade de resolver um problema de gestão de stocks de consumíveis, onde atual aplicação de gestão/faturação não encaixa nas regras de negócio.
• Não há interesse em trocar de aplicação de gestão/faturação apesar de serem conhecidas as lacunas e bugs da mesma.
Hardware/Software:
• Existência de servidor Windows, smatphones e tablets Android e iPhone, bem como desktops Windows 10 e MAC OS.
• Existência de Desktop Windows 10 (core i7) com Visual Studio e plugin Xamarin para programação.
O projeto é fazível?
• Existe a possibilidade de criar uma solução para integração com o software existente;
• Existe a disponibilidade para desenvolver uma aplicação (pelo menos um protótipo);
• Os meios existem e não existe a necessidade de investimento financeiro inicial; • Há disponibilidade também dos colaboradores da empresa em participar.
2. Evocação de requisitos e análise – derivar os requisitos de sistema através de entrevistas com os potenciais utilizadores finais, bem como a observação de sistemas já existentes. Pode envolver o desenvolvimento de alguns protótipos;
113 Entrevistas com os potenciais utilizadores finais
• Falou-se com duas das colaboradoras da empresa, que são as responsáveis pela gestão de stocks;
• Nas várias entrevistas foi possível apurar a forma como é efetuada a gestão de stocks e o que será necessário para resolver o problema existente, de forma a ser criada uma solução que se integre com as aplicações já existentes;
• Estabeleceu-se um canal de comunicação via WhatsApp, que serve essencialmente para responder a “pequenas” dúvidas e questões.
Protótipos
• Ficou definido que seria desenvolvido um protótipo antes da versão final.
3. Especificação de requisitos – processar a informação recolhida na etapa anterior e traduzi-la para os vários tipos de requisitos – e.g. funcionais, não funcionais, de sistema;
REQUISITOS DE SISTEMA / NÃO FUNCIONAIS
Foram definidos os seguintes requisitos de sistema/não funcionais: • Servidor (core i3/4GB) Windows/Linux;
• SGBD SQL Server, com uma base de dados centralizada; • Serviço Web para gestão do sistema;
• Serviço Web para acesso à base de dados (via API);
• Aplicação nativa para ser executada em Android, iOS e Windows 10 (UWP); • Smartphones Android (> Lollipop 5.0);
• Desktop Windows 10; • Rede cablada e sem fios;
• Sistema acessível também via Internet;
• Sistema de backups ativo e também para passivos (ex: Dropbox ou envio de backups para locais externos à localização do servidor);
114
• Interface móvel acessível a utilizadores de leitor de ecrã, de acordo com a EN 301 549;
• Visual Studio / Xamarin / .NET Core 2.x / JQuery /Bootstrap; • SQL Server.
REQUISITOS FUNCIONAIS
Foram definidos os seguintes requisitos funcionais, que estão organizados por Consola Web de administração (Backoffice) e aplicação Nativa/Mobile (Frontoffice).
Consola Web (Administração) - em conformidade com WCAG 2.1 nível A (verificar correspondência com EN 301 549):
• Login / Logout (apenas para utilizadores que pertençam ao Role ‘Admin’); • (CRUD) Gestão de utilizadores;
• (CRUD) Roles - perfis de utilizador (permissões); • (CRUD) Gestão de utilizadores e roles;
• (RU) Gestão do Grupo; • (CRUD) Gestão de Empresas;
• (CRUD) Gestão de Cargos de funcionários (apenas uma descrição do que os utilizadores fazem);
Nota: CRUD é o acrónimo de Create, Read, Update and Delete
Nativo/Mobile:
• Login / Logout;
• Permitir que o utilizador redefina a empresa que pretende gerir (o que significa que o utilizador deve ter uma empresa por omissão);
• (CRU’D’) Gestão de produtos (do grupo empresarial); • (CRU’D’) Gestão de produtos (da empresa);
115
• (CRU’D’) Gestão de lotes (dos produtos das empresas); • (CRU’D’) Gestão de entradas (dos produtos das empresas); • (CRU’D’) Gestão de saídas (dos produtos das empresas); • (CRU’D’) Gestão de fornecedores (do grupo empresarial); • (CRU’D’) Gestão de inventário (das empresas);
Nota: ‘D’ significa que se pode apagar, ou caso não seja possível tem-se a possibilidade de ocultar e o registo mantém-se na base de dados.
CONFIGURAÇÃO DO AMBIENTE DE DESENVOLVIMENTO E TESTES
Windows 10 [Pro] (UWP e Android): Instalação do Visual Studio (com Xamarin). Para partilhar o código entre as máquinas de desenvolvimento foi utilizado um repositório GitHub e configurado o Visual Studio. Para o cenário de testes foi usado, para UWP o próprio Windows, com o leitor de ecrã Narrator e, em Android, foi usado um Huawei P8 Lite (Oreo) com leitor o de ecrã TalkBack, bem com um emulador com definições equivalentes de sistema operativo (sem Talkback).
No MAC OS [Mojave]: Instalação do X-Code, instalação do Visual Studio for Mac (com Xamarin). No X-Code configurou-se um Apple Id, com uma conta pessoal, de modo a poder testar aplicações num equipamento físico. Para partilhar o código entre as máquinas de desenvolvimento foi utilizado um repositório GitHub e configurado o Visual Studio for Mac. Para o cenário de testes foi utilizado um iPhone 8 com o leitor de ecrã VoiceOver, bem como um emulador com definições equivalentes (sem VoiceOver).
4. Validação de requisitos – são examinados os requisitos de forma a perceber se se coadunam com a realidade, a sua consistência e acuidade com o seu desígnio.
Aquando da especificação de requisitos, subactividade 3, é recomendável que fique explícito que a interface com o utilizador tem que ser acessível, em conformidade com o tipo de projeto – e.g. acessibilidade em conformidade com o sistema operativo a que se destina; acessibilidade em conformidade com as WCAG 2.0 em caso de interface Web, criação de
116
recursos de acessibilidade em caso de desenvolvimento de um sistema operativo, ou de uma Graphical User Interface (GUI) para um sistema operativo já existente – e, detalhando, que dificuldades funcionais se pretende mitigar – e.g. cegueira, baixa visão, problemas de motricidade, dificuldades de compreensão.
Aquando da validação de requisitos, subactividade 4, deve ser procurada e selecionada a documentação referente à acessibilidade, de acordo com o tipo de projeto, que será seguida durante a implementação do software e das dificuldades que tentam mitigar.
Ficou definido que o software deveria ser acessível para pessoas cegas através do uso de leitores de ecrã. Esta premissa é verdade para a Consola Web, respeitando as WCAG 2.0, e para UWP/Android/iOS. A compatibilidade com a acessibilidade digital para os sistemas operativos Windows, Android e iOS foi assegurada pelo uso do Xamarin, que invoca os componentes gráficos standard dos SOs.
Foi selecionada a documentação de acessibilidade relativa às plataformas utilizadas no projeto: Web, UWP, Android e iOS.
4.2.5.2. Desenho e Implementação
Nesta fase existem duas subactividades principais:
1. Definição da plataforma onde o sistema vai ser executado – é necessário decidir a melhor forma de fazer a integração nesse ambiente;
BACKEND:
• Sistema operativo: Windows Server 2019;
• Base de dados: SQL Server 2017 ou superior e ferramenta de gestão (SSMS); • Servidor Web: IIS (para correr aplicação .NET Core).
117
• Consola Web de administração do sistema;
• Aplicação UWP, Android e iPhone (uma vez que são os sistemas operativos existentes no local de trabalho).
ACESSIBILIDADE:
• Windows 10: Leitor de ecrã Narrator e NVDA; • iOS 12.3: Leitor de ecrã VoiceOver;
• Android Oreo: Leitor de ecrã TalkBack.
2. Desenho e implementação do software – é nesta fase que as especificações são implementadas e programado o software – e.g. modelos de dados, interfaces entre componentes.
DESENHO:
• Base de dados: Desenho e construção da base de dados com base na lista de requisitos funcionais;
TESTES INICIAIS: • Consola Web
o Dentro dos componentes passíveis de serem selecionados para a mesma ação foram escolhidos os mais acessíveis (standard HTML5), dos quais há a relatar o seguinte:
▪ input--date: muito acessível, apesar de variar de aspeto entre dispositivos (Chome Windows e Android) e depende do idioma definido nas configurações do browser;
118
▪ input--multi-select: funciona bem, mas tem reações diferentes com leitores de ecrã diferentes: NVDA não lê quando se passa pelo componente (mas consegue-se utilizar) e JAWS funciona de acordo com o esperado;
• Aplicação Mobile
o Foram realizados testes em UWP, Android e iPhone de modo a perceber se os componentes básicos do Xamarin Forms são ou não acessíveis. Destes testes ficou evidente que os componentes são acessíveis e apresentam algumas diferenças de comportamento entre os sistemas operativos. Por exemplo, a linha de código await Application.Current.MainPage.Navigation.PushAsync(new TestPage()); lança uma nova janela/ecrã com um botão de retroceder à janela/ecrã anterior. Este botão fica de acordo com o standard dos SOs anfitriões. o Foi definida como baseline a acessibilidade em iOS. Foram testados 4
tipos de menu, com o intuito de aferir as diferenças de acessibilidade entre eles:
▪ Menu 1: menu do tipo Master/Detail (“Hamburger”). Como se pode ver nas próximas imagens, o que os olhos veem é incoerente com o leitor de ecrã apresenta. Em algumas situações, o leitor de ecrã apresenta algumas opções que não estão visíveis aos olhos;
119
Figura 7. Menu 1 : menu do tipo Master/Detail (“Hamburger”).
▪ Menu 2: menu do tipo ListView (Lista de itens). Baseia-se apenas num ecrã e na exploração livre, com o dedo no ecrã, os conteúdos aparentam estar demasiado juntos. Através da varredura tudo está devidamente organizado e acessível;
Figura 8. Menu 2: menu do tipo ListView (Lista de itens).
▪ Menu 3: menu do tipo conjunto de botões (Button). Baseia-se apenas num ecrã onde estão presentes botões para desencadear
120
ações. Estes botões pode incorporar uma imagem. Não oferece nenhuma questão problemática de acessibilidade;
Figura 9. Menu 3: menu do menu do tipo conjunto de botões (Button).
▪ Menu 4: menu do tipo conjunto de imagens com a funcionalidade de um botão (ImageButton). Baseia-se apenas num ecrã onde estão presentes imagens que tem a mesma propriedade de botões. Este tipo de menu, quando os campos relativos à acessibilidade (AutomatioProperties) são preenchidos comporta-se de forma idêntica ao Menu 3, sendo que estas propriedades, nos outros menus, são importantes mas não fundamentais;
121
Figura 10. Menu 4: menu do menu do tipo do tipo conjunto de imagens com a funcionalidade de um botão (ImageButton).
▪ O Menu 4, porque não apresenta constrangimentos de acessibilidade, ao mesmo tempo que permite a personalização visual, que pode permitir a diferenciação que é apreciada por muitos utilizadores;
▪ Para todos os componentes que se pretendam acessíveis deve preencher-se as seguintes propriedades de “AutomationProperties” (apresentadas na Figura 11):
Figura 11. Propriedades de “AutomationProperties”.
▪ Para os que se pretende que não apareçam - e.g. uma imagem que não tenha informação relevante - de atribuir-se o valor
“false” ao
campo:automationProperties.IsInAccessibleTree="false". Desta forma o leitor de ecrã não passa neste campo, o que facilita a exploração de formulários por utilizadores cegos;
122
▪ Existem alguns componentes com constrangimentos de acessibilidade, dado que não tem um sinal sonoro que indique que algo apareceu no ecrã. É exemplo disto o “Activity Indicator”;
▪ Foi testado o PluginIn “Acr.AppDialogs” para tentar melhorar a questão de acessibilidade do componente “ActivityIndicator”. Este PlugIn resolveu esse problema, ou seja, a mensagem desencadeada pelo “ActivityIndicator” passa a ser lida automaticamente pelo leitor de ecrã sem a necessidade de intervenção do utilizador.
IMPLEMENTAÇÃO DOS REQUISITOS FUNCIONAIS:
Até à data da escrita deste documento, foram implementados os seguintes requisitos funcionais:
• Base dados:
o Criação da base de dados;
o Criação das tabelas segundo o modelo de dados; • Consola Web:
o Login / Logout (só para administradores); o Gestão do grupo empresarial (RU); o Gestão de empresas (CRUD);
o Gestão de cargos de funcionários (CRUD); o Visualização dos perfis de utilizador (R);
o Gestão de utilizadores (CRUD), onde não é possível eliminar o “super” administrador;
• Aplicação Mobile:
o Login / Logout (para todos os utilizadores ativos).
Nota: vamos fazer testes durante a implementação de cada funcionalidade (inicialmente testes unitários / usabilidade / acessibilidade – usando a aplicação).
123
Aquando do desenho do software a acessibilidade deve ser tida em conta, de acordo com o tipo de projeto:
• Em caso de desenvolvimento Web, a Graphical User Interface (GUI) deve ser pensada e desenhada de acordo com as recomendações referentes à acessibilidade plasmadas na documentação – e.g. WCAG. A implementação da UI previamente desenhada deve reger-se pelas mesmas normas utilizadas aquando do seu planeamento;
• Em caso de desenvolvimento de sistemas operativos, ou GUI para um sistema operativo já existente, e apesar da abordagem poder variar consoante os requisitos do software, dificilmente as interfaces com o utilizador não serão visadas. Assim, as interações referentes à acessibilidade devem ser pensadas e representadas para que, aquando da sua implementação, estejam sujeitas ao mesmo rigor aplicado a qualquer outra parcela do sistema;
• Em caso de desenvolvimento de software para executar em um sistema operativo já existente, as ações variam de acordo com a interface com o utilizador a ser implementada – i.e. componentes gráficos do sistema operativo previamente existentes; desenvolvimento de componentes gráficos exclusivos, desenvolvidos de raiz. No primeiro caso, devem ser seguidas as HIG do sistema e configurados os parâmetros de acessibilidade preexistentes nos componentes gráficos – estes componentes gráficos, tipicamente, já implementam a API de acessibilidade do sistema hospedeiro. No segundo caso, os componentes gráficos devem ser desenvolvidos incorporando as características de acessibilidade, via API de acessibilidade do sistema, respeitando o padrão de acessibilidade do sistema e, tanto quanto possível, mesmo considerando as idiossincrasias do projeto que levaram a que não fossem utilizados componentes gráficos preexistentes, as HIG do sistema operativo hospedeiro devem ser seguidas. Por fim, devem ser configurados os parâmetros referentes à acessibilidade, previamente implementados via API de acessibilidade do sistema.
124
4.2.5.3. Validação
Nesta atividade são realizados testes automáticos e que simulam o ambiente real a fim de verificar problemas no sistema e se as especificações estão a ser atingidas.
Quando esta fase se aproxima do fim, é realizado o teste de aceitação, ou teste alfa, onde o sistema é dado a um utilizador/cliente e, juntamente com a equipa de desenvolvimento, continua o teste até se concordar que a versão atual está em conformidade com os requisitos. De seguida, são realizados os testes beta, onde o sistema é entregue a um número maior de utilizadores/clientes finais. Os testers usam o sistema e, supostamente, descobrem problemas que são reportados à equipa de desenvolvimento que procede às correções e alterações necessárias.
Em caso de desenvolvimento Web, devem ser feitos testes automáticos com as ferramentas de avaliação de acessibilidade. Devem ser desenvolvidos guiões de teste, ajustados às deficiências que se pretendem mitigar, onde são declaradas explicitamente as funcionalidades a testar, bem como o resultado esperado.
O cuidado durante o desenvolvimento dos guiões assume uma importância vital na qualidade dos resultados dos testes, uma vez que uma pessoa deficiente pode não se aperceber que algo correu mal, caso desconheça o resultado esperado.
Na fase alfa é importante ter testers com deficiência, de forma a estarem representadas todas as deficiências que a acessibilidade implementada pretende mitigar, testers esses que devem executar os testes de acordo com um guião, bem como efetuar uma exploração livre.
Na fase beta, é importante que seja aumentado o número de testers com deficiência, em conformidade com base existente nos testes alfa.
Em caso de desenvolvimento de sistemas operativos, ou Graphical User Interface (GUI) para um sistema operativo já existente, os procedimentos não variam muito do caso anterior, com a ressalva de que não será possível utilizar as ferramentas de avaliação automáticas, a menos que sejam desenvolvidas para a situação em particular.
125
Em caso de desenvolvimento de software para executar em um sistema operativo já existente, os procedimentos são idênticos ao primeiro caso, com a ressalva de que as ferramentas de avaliação de acessibilidade são as específicas do sistema operativo hospedeiro.
TESTES ALFA:
• Consola Web:
o Foram feitos testes à consola Web de gestão da base de dados com sucesso;
o Houve um reparo no que diz respeito à falta de mensagens depois de ações de alteração à base de dados;
o Houve uma sugestão de usabilidade para que os botões de ação (criar, editar e eliminar), ficassem depois do formulário;
o Implementação da recomendação para colocação de mensagens no topo do formulário (de forma evidente), sempre que sejam efetuadas alterações à base de dados. Dos testes realizados ficou claro que as mensagens já auxiliam o utilizador a compreender os resultados das ações efetuadas;
o Com base nas recomendações e testes realizados até ao momento, foram implementadas mais funcionalidades (gestão de utilizadores); o Dos testes realizados sobre as novas funcionalidades foram feitas as
seguintes sugestões:
▪ Melhorar as descrições feitas com texto (exemplo: "Cargos" deve passar a ser "Cargos de funcionários ");
▪ Mensagens de informação de ações realizadas devem ter destaque de heading (meta-informação para o leitor de ecrã); ▪ Botões de ação devem ter uma ordem: primeiro devem aparecer
126
▪ Todas as ações (CRUD), que são baseadas em links, devem passar a ser botões (input type=”button” ou button), de forma à navegação por objetos do leitor de ecrã ser funcional;
▪ Quando algum campo, de valor não obrigatório, não tiver valor deve usar-se uma mensagem por omissão (exemplo: "{o campo %nome_campo% não foi preenchido}";
▪ Em relação aos campos de preenchimento obrigatório, que não estejam preenchidos, deve aparecer uma mensagem clara, destaque de heading, a avisar quais os campos que ainda faltam preencher. Esta sugestão não deve anular o destaque visual local, ou seja, junto aos campos.
o Depois de efetuadas as correções relativas às sugestões anteriores, foram realizados mais testes que serviram para verificar que as alterações ficaram corretamente implementadas. Estes testes demonstraram que as alterações foram devidamente implementadas e há apenas um problema no menu (visual) em ecrãs pequenos.
• Aplicação Mobile:
o Parcialmente realizada.
4.3. Peroração
Neste capítulo foi apresentada a validação da proposta de método desenvolvida, por meio de entrevistas a 31 profissionais da área, apresentada uma afinação do mesmo, bem como uma reavaliação da proposta com as alterações aplicadas. Foi apresentada uma Ferramenta de Apoio à Prática que faz correspondência entre os standards relativos à acessibilidade digital, considerados os mais relevantes, com o tipo de projeto de software a que mais se adequam. Foi exposta uma aplicação prática da proposta de método num projeto de software multiplataforma, que permitiu demonstrar e avaliar a sua exequibilidade. Este capítulo enquadra-se nas etapas 3, 4, 5 e 6 do DSR. O enquadramento na etapa 6 afigurou-se
127
uma agradável surpresa, quando durante as entrevistas inúmeros entrevistados mostraram surpresa e vontade de saber mais, tendo sido pedido o envio deste escrito aquando do seu término, assim como efetuados alguns contactos a posteriori entre o autor e alguns desses entrevistados. No próximo capítulo são apresentadas as conclusões finais, as principais limitações enfrentadas durante o trabalho realizado e apresentado o trabalho futuro.
128
129