Você conhece mesmo o usuário? Ou pensa que conhece? Descubra o papel fundamental dos testes para um desenvolvimento acessível.

Everett N. McKay, em seu livro “Developing User Interface”, acredita que “os programadores são os responsáveis primários pela qualidade de software”. Já estamos carecas de saber que nem todas as empresas possuem ou contratam um processo de garantia de qualidade de software. Nas empresas públicas não é diferente. Independentemente de se ter quem teste e certifique seus produtos de tecnologia, de fato, se o desenvolvedor não se conscientizar de sua suma importância em conhecer e propor testes, não há equipe de teste de qualidade neste planeta e universo que melhorem o resultado final do seu produto ou tornem uma solução ruim em um produto bom!

Os programadores têm grande fatia de responsabilidade de entregar um bom código e verificar, por executar alguns testes apropriados, se o que é esperado será entregue. Se eles já têm essa preocupação (e se existe a possibilidade de se efetuar verificações e testes de várias maneiras, em alguns pontos do ciclo de desenvolvimento), isso só será um reforço e feedback para o futuro. Pessoal do desenvolvimento, não esmoreçam!

Evidente e humanamente, vestir o boné de programador e avaliador custa um esforço e responsabilidade extra. McKay defende que os programadores são plenamente capazes de construir ótimas e belas interfaces de usuário, mas “não foram incentivados, durante sua formação acadêmica”. De fato, não conheço uma disciplina sobre Design de interface de usuários no currículo das áreas de computação... Também, é mais freqüente que o programador delegue a função design para um designer. É bastante incomum também encontrar revistas para programadores com artigos sobre o tema. Certo, mas é fato que grande fatia dos problemas encontrados nos testes ainda vem das interfaces descuidadas, inacessíveis e confusas. Tanto as feitas por programadores quanto por designers.

Programadores são aliados fundamentais para, em parceria, adotarmos procedimentos de testes heurísticos de interface e testes de usabilidade. Podemos planejar em conjunto estratégias para a inclusão de algum tipo de verificação. Mas os programadores precisam aprender a mudar a perspectiva. Vestir o boné do usuário talvez seja também deixar sua cadeira confortável e seu desktop “ultra-high-top-level” para ir pilotar o sistema numa máquina que irá ser entregue para o usuário final. Também, talvez, usar o software ou website que o público-alvo irá usar no dia-a-dia – certamente um ambiente mais lento para execução de tarefas. A experiência com sistemas e websites é tão rica quanto a diversidade e opiniões das pessoas que com eles interagem.

USUÁRIOS INVENTADOS...”AMIGOS” IMAGINÁRIOS...

Nós, da “turma dos testes”, já nos deparamos com situação muito comum e bizarra: por exemplo, programadores e gerentes nos pedem para testar um complexo software ou website e nos fornecem o mesmo usuário “fake” e os mesmos dados “manjados” para entrarmos em um protótipo quase em fase de lançamento e muitas vezes já em uso. Essa situação francamente não refletirá nem de perto a realidade ideal do usuário, lamentavelmente.

É preciso assumir que há uma diferença enorme entre “se comportar como um usuário” e ser realmente um usuário... Quer ver um exemplo?

“CRIE DOCUMENTOS QUE VALIDEM GRAMÁTICAS FORMAIS PUBLICADAS”

Esta é uma regra de verificação do WAI-W3C que tem haver intrinsecamente com as tecnologias de apoio, uma vez que elas dependem e baseiam-se nas gramáticas formais publicadas para interagirem com os sistemas. Em outras palavras, quer dizer que é uma recomendação para acessibilidade digital que os programadores utilizem padrões comuns das linguagens e, enfim, utilizem padrões. Quando um programador inventa TAGs ou utiliza-se de funcionalidades para produzir algo novo mas que não é compatível com o que originalmente foi criado para aquela linguagem escolhida, ele pode incorrer em pecados que ferem princípios de design ou prejudicam a acessibilidade. Assim, testar com usuários reais com deficiências pode deixar claro se o que inventamos poderá ou não ser utilizado por todos. Por exemplo: seu website corporativo permite o aumento ou diminuição do tamanho da fonte?

Quando utilizamos unidades relativas, e não absolutas, nos valores dos atributos da linguagem de marcação e nos valores das propriedades das folhas de estilo, podemos favorecer pessoas com baixa visão que freqüentemente preferem fontes gigantes ou com cores mais contrastantes em seus computadores. Para facilitar o ajuste da preferência de tamanho e cor das fontes, no CSS, não use valores absolutos como "pt" ou "cm' e sim valores relativos como o "em" ou porcentagem (%).

Veja abaixo um fragmento de CSS.

Ao invés de usar:

.texto { font-size: 14pt; }


Passe a usar:
.texto { font-size: 1em; }    ou
.texto { font-size: 70%; }


Divida suas “angústias” com parceiros capacitados para te ajudar nesta tarefa de conhecer os usuários e tornar suas expectativas de satisfação cada vez mais presentes nas “interações do dia-a-dia”.

Referências:
McKay, Everett N. Developing user interfaces for Microsoft Windows. Microsoft Press; Bk&CD-Rom edition (April 1, 1999). ISBN 0-7356-0586-6, 1999

Autora: Aracy Gonçalves é Analista de Sistemas, designer multimídia e professora.
Fonte: Intranet Portal