23. Esfuerzo
necesario para
introducir
accesibilidad en
un juego
Prueba de
concepto sobre
eAdventure
Casos de estudio
(juegos)
Análisis de
usabilidad
Análisis de
necesidades
Propuesta de
estrategias
1. Modelo
2.
Implementación
3.
Usabilidad
Análisis de coste
Desarrollo iterativo Evaluación
¡Buenas tardes! Antes de nada, agradeceros a todos vuestra asistencia, más si cabe teniendo en cuenta que es un viernes a las 3 de la tarde y que mañana es fiesta en algunas facultades.
Mi nombre es Javier Torrente y trabajo en el grupo de e-learning que dirige Baltasar Fernández en la Universidad Complutense de Madrid.
Quiero agradecer a la red eMadrid la oportunidad que hoy me brinda de compartir con todos vosotros parte del trabajo reciente que hemos realizado en serious games, un área en la que se ha centrado gran parte de nuestra actividad en los últimos años, abarcando tanto el desarrollo de juegos como su posterior evaluación en entornos educativos.
Y me gustaría empezar enseñándoos el último juego educativo que hemos desarrollado.
Decidme, como expertos y educadores, ¿cuánto pagaríais por un juego como este?
CONTAR HASTA 7
No sé vosotros, pero yo desde luego no pagaría ni un duro. ¡El juego está roto, no se ve nada!
Ahora imaginaos que no es que el juego esté roto, que de hecho funciona perfectamente para todos los que tenéis alrededor, sino que sois vosotros los únicos que lo veis borroso.
Frustrante, ¿verdad? Pues así es como se sienten los alumnos con discapacidad cuando llevamos un juego educativo a su aula, pues por el mero hecho de tener una discapacidad no podían jugar como el resto de sus compañeros.
De hecho, recuerdo el caso de un chico con ceguera que tuvo que pasarse toda la clase de una hora con los brazos cruzados mientras el resto de sus compañeros difrutaban del videojuego
Some of you may probably say this is not a relevant problem because it only affects a minority.
But in fact it affects much more people than we might think of. According to the latest statistics available from the World Health Organization, as much as a 15% of the population have some sort of disability, defined as an umbrella term for impairments, activity limitations and participation restrictions. This is a pretty big number. And in the near future this figure will make no other thing than rise, especially in ageing populations like the Western countries. So the message is clear: accessibility matters to us all, sooner or later.
But in fact it affects much more people than we might think of. According to the latest statistics available from the World Health Organization, as much as a 15% of the population have some sort of disability, defined as an umbrella term for impairments, activity limitations and participation restrictions. This is a pretty big number. And in the near future this figure will make no other thing than rise, especially in ageing populations like the Western countries. So the message is clear: accessibility matters to us all, sooner or later.
So we started by analyzing who has more problems to play eAdventure games, in collaboration with Technosite which is a company expert in accessibility of the ONCE group, the Spanish National Organization for the Blind.
And we found out that eAdventure games were especially cumbersome in terms of accessibility for people with three specific types of disabilities:
Blindness
Users with reduced mobility in hands
Users with low visión
Having each of these different problems. So we decided to focus on trying to improve the eAdventure experienece for these three user profiles.
Blind users have two problems. The first concerns the input. They cannot control eAdventure games because they are based on a point-and-click interface and they can’t use the mouse, which is a device that requires the use of the sight. The second concerns the output, which is mainly visual in eAdventure games.
Users with limited mobility have the same problem with the input, since obviously they cannot use the mouse.
Users with low vision have a completely different problem, which is that they cannot distinguish the interactive elements because these blur into the backgrounds. So they can’t find them to click on them.
It is good to remark that all these problems are not exclusive of the eAdventure platform; actually they are present in many games and game development software.
So when we saw these issues it’s when we said: “hey guys, it’s time to start working to improve the accessibility of serious games”.
And in our case it was easy to decide where to begin: eAdventure. eAdventure is our own game authoring platform. I’m pretty sure most of you have heard already about it, but for those who haven’t let me show you a very quick video
Once we have a clear idea of the problems we wanted to tackle, we started working on the solutions.
The first thing we did was to design a new way to interact with the game for blind people and people with reduced mobility. With this new interaction, users provide input using short commands in natural language, like “grab the notebook” or “talk to Sam”. The main difference is that the blind use a keyboard to introduce the commands and people with limited mobility use their own voice.
But to introduce a command you first need to know what you can do in the scene. Interactions are not obvious to the player because we wanted to introduce a discovery component, to make playing more enticing. The player iteratively introduces special commands that result in the game providing clues and hints on what there is in the scene. The blind player gets this feedback through audio (using text-to-speech software), and the player with limited mobility gets it through visuals.
But, since these concepts are a bit complex, the best way to understand them is to see an example, don’t you think?
Let’s suppose we have this scene and that we are a blind player.
We have 4 different interactive objects, which are overly marked each one with an arrow.
When we reach this scene for the first time, we get a brief description of what the scene looks like. It may be something like “You are at your desk, and all the objects on it at the reach of your hand.” And that’s it.
Then we would introduce a command like “objects” to find out more about these objects and we would get a brief description on how many objects are in the scene, and their names: “There is a telephone, a plant, a computer and your bag”.
And from there the player can try different interactions with these objects, for example “use the telephone”, “water the plant”, and so on. Some of these will work and others won’t depending on how the game was defined.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
Once we have a clear idea of the problems we wanted to tackle, we started working on the solutions.
The first thing we did was to design a new way to interact with the game for blind people and people with reduced mobility. With this new interaction, users provide input using short commands in natural language, like “grab the notebook” or “talk to Sam”. The main difference is that the blind use a keyboard to introduce the commands and people with limited mobility use their own voice.
But to introduce a command you first need to know what you can do in the scene. Interactions are not obvious to the player because we wanted to introduce a discovery component, to make playing more enticing. The player iteratively introduces special commands that result in the game providing clues and hints on what there is in the scene. The blind player gets this feedback through audio (using text-to-speech software), and the player with limited mobility gets it through visuals.
But, since these concepts are a bit complex, the best way to understand them is to see an example, don’t you think?
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
Generally speaking, results were satisfactory and encouraging, to the point of being awarded with the first prize of the ACM Student Research Competition celebrated in the ASSETS 2012 Conference. Well, that did not make us rich but we got a shinny medal that was very quickly confiscated by my little nephew, so it’s not bad!
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
And that’s all. Thanks a lot for your attention. If you have any questions, I’ll be happy to answer them now.
So to test these features, we started by making one of our serious games accessible. And the most relevant conclusión we drew was that making a game accesible is really effort consuming! It takes a lot of time for developers to introduce accessibility beacause they have to produce new functionality (e.g. tts), new content (e.g. captions), do more testing, etc. All these extra activities result in a Budget overhead. Perhaps that’s why most of the serious and leisure games are still not very accesible.
So we decided to make an effort to integrate all these features directly into the eAdventure game authoring platform, so other developers could use them for their own games, reducing in this sense the effort required to make a game accesible. In this sense what we did was passed from focusing on only one game to how to make accesible many games, making the approach scalable.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
Proponer un conjunto de características de accesibilidad que puedan integrarse en herramientas de creación de juegos para facilitar la introducción de características de accesibilidad en serious games tipo aventuras point-and-click (Modelo conceptual).
Implementar una prueba de concepto sobre una herramienta de creación de juegos concreta (Implementación).
Evaluar la adecuación del modelo propuesto (ver objetivo 1) mediante el desarrollo de casos de estudio y su posterior análisis de usabilidad incluyendo usuarios con discapacidad (Usabilidad).
Analizar el coste asociado a la introducción de las características de accesibilidad identificadas en un juego completo, a fin de valorar si el enfoque produce una reducción significativa de esfuerzo asociado a la accesibilidad en juegos digitales para el desarrollador del juego (Evaluación final).
So to test these features, we started by making one of our serious games accessible. And the most relevant conclusión we drew was that making a game accesible is really effort consuming! It takes a lot of time for developers to introduce accessibility beacause they have to produce new functionality (e.g. tts), new content (e.g. captions), do more testing, etc. All these extra activities result in a Budget overhead. Perhaps that’s why most of the serious and leisure games are still not very accesible.
So we decided to make an effort to integrate all these features directly into the eAdventure game authoring platform, so other developers could use them for their own games, reducing in this sense the effort required to make a game accesible. In this sense what we did was passed from focusing on only one game to how to make accesible many games, making the approach scalable.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
We also designed a high contrast mode for people with low vision. In this case the eAdventure game engine automatically applies some filters to the scene to make it easier to distinguish the interactive elements over the background.
Right now we are working on a brand new version of our game engine where we plan to introduce the accessibility features. The new engine allows running the games in the desktop using HTML 5 and also on mobile devices, which will allow us to use the accessibility tools included in these environments.
In this presentation we have tried to point out the need to start considering accessibility in serious games to prevent that the games become a potential source of digital divide in the school. But to achieve that we have to solve two main problems.
First, we have to reduce the effort that is required to make games accesible.
Second, we need to check that the solutions proposed are scalable so they can be applied not to a single game, but to many.
Our proposal to address both issues is to target directly the tools that developers actually use to produce the games, as we have shown through the eAdventure platform.