Dos testes que efectuei com o VoiceOver e com o VisioVoice que o complementa, verifiquei que na leitura de documentos em HTML existem algumas dificuldades, as quais se agravam quanto mais os designers seguem as Directrizes de Acessibilidade para o Conteúdo da Web (WCAG) 1.0 do World Wide Web Consortium (W3C).
Uma das regras de prioridade 1 das WCAG prende-se com o facto de termos de marcar todas as mudanças de idioma que ocorrem ao longo de um texto. Este mesmo post segue essas mesmas regras. No meu entender para além de visualmente o texto ficar com um aspecto mais cuidado, são várias as possibilidades de leitura e pesquisa que estes mesmos elementos acrescentam ao documento, não apenas para os agentes de utilizador actuais (nos quais se incluem as ajudas técnicas) mas para os que ainda se irão inventar.
Por exemplo, a frase que se segue:
No próximo dia 27 Setembro de 2006 Joe Clark vem a Portugal dar uma conferência sobre "Web Accessibility: From 0 to 100 in a single day".
tem o seguinte código:
<p>No próximo dia 27 Setembro de 2006 <span lang="en">Joe Clark</span> vem a Portugal dar uma conferência sobre "<span lang="en">Web Accessibility: From 0 to 100 in a single day</span>".</p>Existem inúmeros outros exemplos de marcação inline (em linha) que constituem directrizes de acessibilidade para o W3C. Por exemplo, os acrónimos e as abreviaturas são mais dois dos exemplos a adicionar à lista.
É compreensível e lógico que o VoiceOver faça uma leitura por elementos de HTML, mas na verdade essa lógica torna a leitura aborrecida para as pessoas cegas e constitui uma barreira para as pessoas com baixa visão que usam a janela de ampliação do VisioVoice.
No caso das mudanças de idioma, como deveria ler o VoiceOver?
Ao adquirir a capacidade de multilingue com a adição do VisioVoice, o VoiceOver deveria naquele pequeno excerto que se apresentou ler:"No próximo dia 27 Setembro de 2006" com um sintetizador de fala em português, e depois ir buscar o sintetizador em inglês para ler "Joe Clark", e logo de seguida ir de novo buscar o sintetizador de fala em português e continuar "vem a Portugal dar uma conferência sobre" e de novo trocar o sintetizador português pelo inglês e ler "Web Accessibility: From 0 to 100 in a single day".
Difícil? Sim, de facto! Agora imaginem com mais do que dois idiomas. É lindo e bem mais claro, para quem está a ouvir. Em Windows, onde o leitor de ecrã JAWS é líder de mercado, ele faz exactamente isso, quando o utilizador dispõe de um sintetizador multilingue, como é o caso do Eloquence. E se a Apple nos trouxesse isto com o Leopard? Fica a sugestão ou o desejo de que seja mesmo verdade, sabendo que mais tarde ou mais cedo isso vai acontecer.
E como lê o VoiceOver actualmente?
No excerto anterior a dupla VoiceOver+VisioVoice pára em cada um daqueles pequenos segmentos, esperando que o utilizador lhe dê a instrução para avançar em cada um deles. É uma chatice! Para além de parar constantemente, principalmente em código HTML bem marcado de acordo com as WCAG, não troca o idioma do sintetizador. Curiosamente isto sucede igualmente com a janela de ampliação do VisioVoice. Ao posicionarmos o cursor no principio do parágrafo, na janela ampliada apenas nos aparece o pequeno segmento de texto que constitui o elemento em vez da totalidade do parágrafo. Se na voz é chato, já com a ampliação é impossível ao utilizador com baixa visão controlar este procedimento.Um pedido: do monolingue do Tiger para o multilingue do Leopard
Seria fantástico que o novo sistema operativo Mac OS X Leopard fosse dotado da função de identificação das mudanças de idioma no código HTML e buscasse, no rol de sintetizadores de fala instalados no sistema operativo, o mais apropriado para efectuar a leitura de um determinado elemento.
