Los menús en las aventuras conversacionales, presentes a veces para enriquecer la interfaz facilitando, por ejemplo, el cambio de configuraciones o la carga de partidas guardadas, carece entre los distintos intérpretes de una forma estándar de presentación. Ello ocasiona importantes diferencias en la accesibilidad de los mismos, según el intérprete y el lector de pantalla utilizado.

A modo de comentario, hace no mucho ha surgido el interrogante de si son accesibles en las aventuras de texto los menús en que el jugador debe seleccionar una opción con las teclas de cursor y activarla con Enter. El uso de los mismos por personas ciegas, como es mi caso, no es imposible; pero dado que hay importantes aspectos que podrían mejorarse en pro de una mayor libertad a la hora de elegir qué software de lectura de pantalla utilizar, me dispongo a exponer algunas de las dificultades que se pueden presentar en el manejo de los mismos con los intérpretes de máquina Z y Glulx en Windows, formatos muy utilizados por su portabilidad.

Tales dificultades no se presentan por ejemplo en Quest, que dado lo estándar del diálogo que contiene un cuadro de lista con las opciones y botones Aceptar y Cancelar, cualquier lector de pantalla puede, por más que sea tan básico como lo es por ahora el Narrador de Windows, interactuar sin problemas en este sentido.

Como primer problema, los intérpretes tienen notorias diferencias técnicas en su interfaz de e/s. Ni siquiera los dos productos estrella de David Kinder (Windows Frotz y Windows Glulxe) están exentos de esta ¿falla?, cuando supuestamente al estar ambos basados en GLK deberían tener implementada la misma interfaz. Además, como si esto fuera poco, la forma en que la función de leer texto mediante SAPI 5 en los intérpretes de D. Kinder trata el caso de los citados menús difiere sustancialmente entre un intérprete y otro.

Veamos, pues, los casos concretos de tres intérpretes.

Windows Glulxe

La interfaz de entrada/salida está muy bien para el texto, ya que usando características de revisión plana apenas presenta problemas. Además, para mayor comodidad, tiene una opción para leer la salida textual a través de motores de texto a voz SAPI 5 que estén instalados en el sistema.

Lo mismo se aplica al uso de los menús de los juegos con las teclas de cursor cuando se utiliza JAWS, ya que este lector lee perfectamente la opción que tiene el foco cuando se pulsa INSERT+Flecha arriba, comando para leer la línea actual. No obstante hay un problema en este caso con la opción de leer el texto propia del intérprete, ya que no lee en absoluto los elementos de estos menús cuando se navega por ellos con las flechas.

Con el lector de pantalla NVDA las cosas no están tan bien. Este lector, que al no modificar la cadena de controladores de video se vale de información recibida de APIs de Windows como MSAA o UIAutomation, no es capaz de indicar de ninguna manera qué opción tiene realmente el foco. Se pueden leer las opciones con el cursor de revisión plana o el navegador de objetos (características ambas para interactuar con objetos a los que con métodos normales no se puede llevar el foco del sistema), pero al no poderse activar estos elementos con clics del mouse y al no reconocerlos NVDA como botones u opciones de menú, no es posible activarlos con la certeza de haber ido al deseado.

Windows Frotz

De los tres vistos, es sin duda este el peor intérprete en relación al tema que aquí nos ocupa. Hasta a JAWS for Windows con sus características de revisión de la pantalla le cuesta horrores mostrar bien el texto plano de los juegos; y ni hablar los menús, en los que el comando INSERT+Flecha Arriba no hace sino confundir al jugador leyéndole cosas que nada que ver con la opción que tiene el foco.

Este intérprete tiene desde sus últimas versiones, al igual que el arriba observado, una opción para leer texto con voces SAPI 5 que el usuario tenga instaladas. Mientras que para el texto normal de las obras es perfecto, con los menús de opciones se comporta incluso peor que Windows Glulxe. Si bien las opciones de los menús las lee, no resulta precisamente orientador teniendo en cuenta que cada vez que uno se desplaza a una opción lee todo el menú de principio a fin, no quedándole al jugador otra alternativa que ir contando las pulsaciones de flechas para no perder tiempo activando opciones equivocadas.

Con NVDA ocurre lo mismo que en Windows Glulxe, por idénticos motivos.

WinFrotz y WinFrotzE

Este programa es bastante antiguo y podría decirse que quedó obsoleto. Sin embargo recuerdo mi experiencia con él y no creo que esté de más comentarla.

No dispone de opciones propias para leer el texto, algo natural considerando que en su época no existía ni siquiera el viejo estándar SAPI 4, pero su interfaz es muy accesible para leer el texto de forma manual. La lectura de menús de los relatos con JAWS se comporta, por fortuna, igual que con Windows Glulxe.

Cuando usaba este intérprete no lo probé con NVDA, pero estoy seguro de que debe suceder lo mismo que en los casos anteriores, ya que difícilmente este intérprete utilice el MSAA teniendo en cuenta que en su época las APIs de Microsoft Active Accessibility (MSAA) eran muy recientes y sólo se limitaban a Office 97.

Conclusión

Usando JAWS casi no hay barreras en la utilización de estos menús, siendo las que hay fácilmente franqueables. Dada la naturaleza de NVDA de no invadir el sistema con controladores de video y permitir hasta ejecuciones completamente portables, está en los desarrolladores de intérpretes efectuar las codificaciones correspondientes para enviar a librerías del sistema operativo información de las que lectores de pantalla como éste se puedan beneficiar.

Y en cuanto a las funciones de lectura en voz alta propias de los intérpretes, podrían explotarse más. No dudo, asimismo, que si notificamos estas incidencias no será raro verlas resueltas en versiones nuevas.