Acessibilidade digital e os testes de usabilidade

Quem trabalha algum tempo com acessibilidade e usabilidade reconhecerá facilmente a importância dos testes de usabilidade, em qualquer processo de construção e manutenção de experiências realmente centradas nos utilizadores. Os benefícios são demasiado evidentes. O retorno de investimento e a capacidade que esta ferramenta nos dá, para evitarmos investir dinheiro (muito) a desenvolver coisas inúteis ou difíceis de utilizar é gigantesco. Na disciplina de UX, este é quase um não tema. Se queremos fazer um bom trabalho, temos que testar as soluções com os utilizadores.

Mas, nem sempre a realização de testes de usabilidade cíclicos é uma realidade nas empresas. Se este é o caso na empresa em que estás a trabalhar neste momento, seria uma altura importante para parar e refletir profundamente sobre isto. Nenhuma empresa vai dizer que não quer fazer experiências centradas no utilizador. Contudo, como é que isto pode acontecer se nunca testamos as soluções que criamos com utilizadores reais? E as equipas de projecto não contam como utilizadores. Na prática, se nunca testarmos as soluções que definimos, desenhamos e desenvolvemos com utilizadores não estamos a criar coisa nenhuma centrada nesses utilizadores. Não existe user-centred se não existir “users” no processo.

Testar com todos

Se a relevância dos testes de usabilidade é incontestável na esmagadora maioria dos contextos, quando falamos de realidades onde o trabalho de acessibilidade digital é uma preocupação, isto torna-se ainda mais relevante. Os testes de usabilidade permitem-nos fazer muitas coisas. Uma delas, é conhecer com detalhe o contexto e modelo de utilização das soluções por parte dos utilizadores. Em acessibilidade isto é extraordinariamente importante.

Os modelos de interação dos utilizadores podem ser bastante díspares. Seja em que tipo de dispositivo for, diferentes características significam diferentes modelos de utilização. É certo que isto será sempre um desafio bastante grande para as equipas de projecto, mas é também algo fantástico conseguirmos criar soluções que possam ser utilizadas pelo maior número de pessoas. Soluções que podem ser utilizadas, mesmo quando o seu modelo de utilização possa não ser aquele que temos recorrentemente em mente.

As pessoas podem aceder às aplicações utilizando diferentes tipos de estratégias ou tecnologias de apoio. Desde a utilização de leitor de ecrã, navegação através de teclado, apontadores, configuração de contrastes de cor ou tamanhos de letra, audiodescrições de conteúdos multimédia, teclado de braille, entre muitas outras alternativas. Tudo isto são modelos de utilização que num caso ou noutro podem ser utilizados pelas pessoas que beneficiam das aplicações que criamos e que nos importa conhecer, salvaguardar e claro, testar até à exaustão.

Mas, será que testar soluções com pessoas que utilizem algumas destas estratégias ou tecnologias de apoio, tem alguma diferença dos testes de usabilidade com outro tipo de utilizadores? Deverá existir alguma diferença no protocolo de testes? Deveremos realizar ciclos de testes à parte? A resposta a quase todas estas questões, é não. Uma coisa importante a ter em mente com a realização de testes de usabilidade com pessoas que utilizem alguma estratégia ou tecnologia de apoio, é que estes testes não são diferentes de qualquer outro teste. Não devem ter um protocolo à parte. Não devem ser um ciclo de testes diferenciado. Não são “outra coisa” para além dos testes que realizaríamos com qualquer outro tipo de utilizadores.

Caso prático

Tentemos contextualizar um pouco algumas destas premissas com um caso prático. Imaginemos um contexto, onde vamos realizar um ciclo de testes de usabilidade a uma nova funcionalidade do produto digital em que estamos a trabalhar e com pessoas que têm o mesmo perfil de utilizador. A ideia de perfil de utilizador é importante, porque neste ciclo vamos realizar testes, com por exemplo, 7 pessoas diferentes, mas que têm todas mais ou menos as mesmas necessidades (independentemente dos seus traços socio-demográficos).

Vamos tomar como referência um grupo de 7 pessoas, partindo das conclusões de um estudo da Nielsen Norman Group e incluindo no grupo, 2 pessoas que tenham como modelo de interação a utilização de leitor de ecrã e teclado em conjunto. A preparação dos testes de usabilidade vai seguir o processo normal que seguiria em qualquer outro caso, sem nenhum tipo de especificidade aparente.

Durante a realização das sessões de testes, com os 2 utilizadores que utilizam leitor de ecrã e teclado, vamos só ter em conta algumas premissas de detalhe, mas que em nada afetam aquilo que é o protocolo global dos testes.

As tarefas a testar deverão ser exatatamente as mesmas para todos os utilizadores (só existem diferenças de tarefas por perfis de utilizadores, não por modelos de interação).
Eventualmente, em alguns casos de teste com modelos de interação diferentes, poderá ser útil reduzir o número de tarefas a testar (mas nunca testar tarefas diferentes).
É importante realizar os testes no contexto em que a pessoa está habituada a utilizar este tipo de aplicações (para que possa utilizar o setup de ferramentas que está habituada a utilizar no dia a dia).
Para tornar o teste mais fluído, pode ser interessante minimizar ao máximo a alternância entre diferentes tabs de browser ou ferramentas informáticas (quanto maior for o tempo do teste utilizado na realização de tarefas, menos tempo demorará e mais vamos aproveitar a pesquisa).

No caso dos testes serem realizados em remote, com todos os utilizadores ou só com as pessoas que utilizam leitor de ecrã e teclado, convém ter em atenção também alguns tópicos específicos.

É importante garantir que a ferramenta de video-chamada utilizada (Microsoft Teams, Zoom, etc.) seja ela própria acessível (se não, isso pode influenciar alguns dos resultados dos testes).
Não esquecer de manter a video-chamada com câmara ligada mesmo que não exista contacto visual entre o moderador e o participante (existe muita informação não verbal que a pessoa irá transmitir e que nos interessa analisar da mesma forma).

Repara em alguns “detalhes”

Durante a realização dos testes de usabilidade com as pessoas que utilizam leitor de ecrã e teclado para interagirem com a solução, és capaz de encontrar algumas “surpresas”. Na prática não são bem surpresas, mas mais algumas realidades que poderíamos nunca ter imaginado antes de assistir em primeira mão a este tipo de experiências. Por isso mesmo, não te surpreendas se alguma destas coisas acontecer.

Em muitos casos a pessoa não está a ver nada do que está acontecer no ecrã e está a navegar exclusivamente através das informações sonoras que o sistema transmite (é mais uma navegação sonora e interativa do que visual).
A velocidade de leitura do leitor de ecrã pode ser quase imperceptível para alguém que não utilize este instrumento todos os dias (mas a pessoa com quem estamos a testar compreende mesmo o que é lido).
Em alguns casos a realização de tarefas pode ser mais rápida do que com pessoas que utilizam modelos de interação mais convencionais (o que não deixa de ser bastante curioso e interessante de analisar).
Os modelos de navegação podem ser bastante diferentes daqueles que estamos habituados (o utilizador pode por exemplo, através do leitor de ecrã procurar de forma automática títulos ou ligações na página sem ter que percorrer em scroll toda a página).

Não penses demasiado

Podes pensar que esta é uma visão simplista do tema. No final do dia, tal e qual como os próprios testes de usabilidade não há como experimentar. Nunca realizas-te um teste deste género? Atira-te de cabeça! Não penses em demasia no tema e não tenhas medo de errar. Os primeiros testes podem não correr tão bem como gostarias, mas não tem problema nenhum.

O processo de aprendizagem é mesmo assim. Aprendemos fazendo e a experiência ajudar-nos-á a melhorar. Quantos mais fizermos, melhor. Se nunca começarmos, nunca vamos fazer melhor, o que neste caso quer dizer, que estamos cada vez mais longe de construir soluções realmente acessíveis para o maior número de pessoas.