Ergonomia em Aplicações Multimédia

Documento de análise do projecto. – EAM – Nuno Regadas – 2007

Em termos de metodologia:
Analisar dois sistemas moodle em termos de acessibilidade. Se os resultados dos testes forem semelhantes, sigo somente um modelo de análise automática.
Já há algum trabalho realizado nesta matéria da acessibilidade do moodle. Contudo, ainda não há uma sistematização das alterações a serem feitas no moodle juntamente com a forma de as fazer. Esse seria um pouco o que eu pretendia fazer, sendo que não deverei ser capaz de implementar muitas das alterações pretendidas dentro dos limites de tempo impostos.

Neste momento a minha prioridade é perceber de que forma posso proceder às alterações no moodle a nível de php para chegar ao código html que é gerado automaticamente.
Uma questão é falar do que pode ser mudado, outra, diferente, é falar do que deve ser mudado tendo em consideração as várias vicissitudes da programação e aquilo que ela envolve.

Para tal vou-me basear, neste primeiro esboçar de artigo final, em textos retirados da Internet e do wiki de ergonomia. Para além destes vou ainda referir a necessidade de testes e análises futuras, uma vez que estes fazem parte do meu plano de trabalho.

Assim começamos pelas modificações de primeira prioridade que deveriam ser feitas ao moodle. Nesta fase posso referir a impossibilidade de neste momento proceder a alterações uma vez que não domino a programação necessária para levar a cabo as alterações.
Começamos logo pelos equivalentes textuais. As imagens, gráficos e pequenos gifs que são relevantes devem ter equivalentes textuais, pois caso o moodle seja visionado por um utilizador de programa de leitura de ecrã, não consegue “ver” a imagem em causa. No que a este ponto diz respeito, o moodle, por predefinição até apresenta a possibilidade de termos equivalentes textuais, mal introduzimos uma imagem na visualização. Contudo, no que às imagens que já estão por predefinição no moodle, não sei como alterar o seu atributo alt, uma vez que não nos é possível aceder a um código html comum, onde estas alterações normalmente são introduzidas.

Referentes textuais
Ainda assim, idealmente, todas as imagens que em si têm informação relevante devem possuir atributo alt. Não devemos confiar no título da imagem porque essa informação não é lida por pré-definição pelos programas de leitura de ecrã. Mas não devemos abusar e chegar ao extremo de por atributo alt em todas as imagens. Porque aquelas que não possuírem informação útil, deverão ter um atributo alt nulo, ou seja, atl=””. Contudo, esta simples alteração não me é possível fazer neste momento porque ainda não consigo aceder ao código base, pelo que preciso de mais investigação neste sentido.

No caso da utilização de animações flash para a apresentação da disciplina, estas introduções deverão também ter um equivalente textual para que alguém que utiliza um programa de leitura de ecrã. Aqui seria utilizado o atriubuto longdesc. Um exemplo seria: . Este atributo precisa de ser trabalhado para ver até que ponto ele funciona bem no sistema moodle.
Ao utilizar animações em flash devem ser também usadas construções alternativas para que os conteúdos sejam também acessíveis mesmo se não for possível aceder a esses conteúdos.

Cores
No que diz respeito à utilização de cores esta também é uma preocupação mais fácil de conseguir no que diz respeito a alterações possíveis no moodle. Para isso basta modificar a css que controla as cores, ainda que essa css possa ou não existir, dependendo de modelo para modelo. Ainda assim, é de assinalar a possibilidade de criar novas folhas de estilo podendo estas ser acrescentadas ao nosso moodle sem que para isso sejam necessárias grandes alterações ou complicações em termos de programação (basta fazer as folhas de estilo). É necessário desenvolver um layout que permita ter um grande contraste entre as cores de fundo e a forma. Havendo esse contraste deixa de haver problemas na percepção dos elementos por um certo grupo de pessoas com problemas visuais.
Em termos de ferramentas para analisar o contraste das cores temos várias ao nosso dispor, sendo que posso utilizar o (http://www.snook.ca/technical/colour_contrast/colour.html). Desta forma posso ter total certeza aquando da utilização de uma ou outra cor no meu layout em desenvolvimento.

Alterações na língua
Como estamos a falar de um produto que vai ter termos científicos, muitos deles em Inglês, poderá ser necessário acautelar o utilizador da alteração de língua durante o texto. Para isso deveria ser utilizado o seguinte código: “como bichinho comum o “Fly”. Assim temos em consideração este ponto de verificação de prioridade 1.

Tabelas de dados
O moodle é principalmente constituído por tabelas de dados, sendo que todas elas devem estar identificadas com cabeçalhos (colunas e linhas). Desta forma os dados são disponibilizados as pessoas de forma mais eficiente e de uma forma acessível.

Documento que seja acessível sem as folhas de estilo
O moodle, de origem, já vem preparado para ser visualizado sem as folhas de estilo pelo que este ponto de verificação não é um problema. Algo que ainda precisa de mais atenção é a construção de uma nova folha de estilos, sendo que algumas das alterações que lá fizer podem ser benéficas para melhorias da acessibilidade. De que forma posso melhorar a acessibilidade pela alteração de uma folha de estilos? Este ponto precisa de uma investigação posterior.

Navegação
Neste ponto importa referir algo que, apesar de não ser de prioridade um, tem grande influência na navegação. É o tab índex. Isto porque na avaliação manual em que usei o jaws e o opera, deu para ver que o tab deslocava o cursos imediatamente para os formulários. Ainda assim poderiam ser criadas zonas de interacção para que o tab se deslocasse para la e depois, pelo controlo dos links o utilizador chegasse onde queria.
Um dos pontos que referi na anterior avaliação e que poderia ser um ponto a favor era a navegação através do teclado alfanumérico. Contudo, também há quem defenda que não se deve utilizar este tipo de navegação. Ainda assim, se conseguir implementar estas questões gostaria de aprofundar um pouco mais o que pode, deve ou não deve ser feito. Este tópico precisa ainda de maior aprofundamento, sendo que a conversa com alunos com dificuldades de percepção visual, parcial ou total.

Formulários
A questão dos formulários preocupa-me pelo facto de não estarem identificados como tal, e por causa dos programas de leitura de ecrã não lerem esses campos em branco. Por formulários refiro-me principalmente aos formulários de log in. Ainda assim há a preocupação com os formulários desenvolvidos por empresas externas ao moodle como a área de edição de html.
Mas para modificar estas áreas seria necessário ter um nível de conhecimento mais profundo que eu não possuo.

Futuro:
Brevemente vão ser realizados testes de usabilidade com alunos do secundário, bem como, num futuro próximo, com utilizadores com dificuldades de percepção visual, parcial ou total.
Estes testes vão-me permitir tirar mais conclusões que vão levar à adopção ou não de novas maneiras de trabalhar o moodle.
Com base nestes testes e nos outros trabalhos levados a cabo por investigadores no campo da acessibilidade do moodle, tal como Nick freear.

O objectivo principal desta análise é ter dados concretos que me permitam, ao abordar especialistas e administradores do moodle, ter os conhecimentos necessários das falhas da plataforma. Um dos meus objectivos é poder escrever um artigo científico que aborde o tema da acessibilidade no moodle. Já tenho a decorrer nos fóruns do moodle da comunidade moodle internacional e portuguesa vários tópicos que espero que venham a dar boas rampas de lançamento para temas que pretendo abordar tanto para esta cadeira como para o meu estágio e a investigação que estou a levar a cabo.

Até ao próximo post,
Nuno Regadas