Pioneros I

Pioneros y hacedores.
Fundamentos y Casos de Diseño de interacción

con estándares de Accesibilidad y Usabilidad
Lorena Paz (Compiladora) y Víctor Malumián (Editor)
Ediciones Godot
Crearon este eBook accesible:
Julio Incarbone (Coordinador de DIEAU y Co-fundador de IAcoop) con el

asesoramiento de Olga Carreras Montoto y Carlos Benavidez.
Notas legales sobre esta edición Epub.
Paz, Lorena (Comp) Pioneros y hacedores: fundamentos y casos de diseño
de interacción con estándares de accesibilidad y usabilidad . - 1a ed. -
Ciudad Autónoma de Buenos Aires: EGodot Argentina, 2013. 290 p.;
20x13 cm. ISBN 978-987-1489-72-5 1. Informática. 2. Gestión Informática.
3. Sitios Web. I. Título CDD 005.3
Pioneros y Hacedores.Fundamentos y Casos de Diseño de Interacción con
estándares de Accesibilidad y Usabilidad. Lorena Paz (Comp.) y Víctor
Malumián (ed.)
Corrección: Hernán López Winne
Traducciones: Sebastián Betti y Mariana Inés Calcagno
Diseño de tapa e interiores: Víctor Malumián
Editorial: Ediciones Godot
Mail editorial: Enviar mail
Facebook editorial: Ingresar a Facebook
Twitter editorial: Ingresar a Twitter
Lugar y año de creación: Buenos Aires, Argentina, 2013
Índice de contenidos
Introducción
Capítulo 1: El botón de los $300 millones.
Capítulo 2: Cómo usamos la web realmente.
Capítulo 3: Mobile Site vs. Full Site.
Capítulo 4: ¿Qué se mueve?
Capítulo 5: Diseño de interacción, prácticas de investigación y diseño
en materiales digitales.
Capítulo 6: Diseño participativo para la inclusión digital.
Capítulo 7: Introducción a la Interacción Persona-Computadora.
Capítulo 8: Entre la Arquitectura y la Información.
Capítulo 9: Accesibilidad Web y SEO.
Capítulo 10: Desarrollo de un videojuego accesible.
Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad
y usabilidad.
Capítulo 12: Ergonomía física y cognitiva.
Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking.
Capítulo 14: Accesibilidad de un recurso educativo.
Capítulo 15: Elaboración de una Normativa de Usabilidad y
Accesibilidad Web.
Capítulo 16: Internacionalización Web.
Capítulo 17: Prácticas participativas en el Diseño de Interacción.
Capítulo 18: Diseño y desarrollo de un editor de texto accesible open-
source.
Capítulo 19: Las métricas de accesibilidad desde una perspectiva
práctica.
Glosario
Introducción, por Lorena Paz
Mini biografía del autor
Socióloga especializada en Tecnologías de la Información y la
Comunicación. Dirige la Especialización en Diseño de Interacción con
estándares de accesibilidad y usabilidad en la Universidad Tecnológica
Nacional DIEAU . Miembro de la Asociación Civil: Laboratorio de Ideas
Cooperativas LabID.org . Co-fundadora de "Interacción Accesible”
Cooperativa de Trabajo Tecnológico IAcoop.
Más información:
Ingresar al sitio web del autor
Twitter: @lorenapaz
Notas Introductorias
“...es necesario aceptar que existen múltiples órdenes de la
verdad, múltiples modos de existencia, cuyas condiciones de
felicidad o infelicidad deberán ser establecidas, con sumo
cuidado, por el investigador.” Bruno Latour
Esta selección de textos surge marcada por una presencia casi invisible pero
abarcativa: la sociología, el campo de estudio por excelencia de las
interacciones sociales. Pioneros y Hacedores es material de reflexión para la
investigación contemporánea de los procesos del comportamiento humano
en la interacción. El asunto es de larga data: pionero y hacedor fue el primer
Homo habilis que creó una herramienta para interactuar con él mismo, con
sus pares y con su medio. Lo hizo seguramente haciendo diseño centrado en
él, en el usuario... Pero el foco aquí está dado por el tipo particular de
interacción y de comportamiento que provoca el ambiente digital con la
presencia de interfaces, pantallas, consolas, computadoras, cajeros,
videojuegos, móviles, controles remotos, etc. Las nuevas disciplinas que
emergen al ritmo de los transistores y de los microchips no pueden ser
completamente mensurables; sin embargo, ejercen conocimiento científico:
describen, prueban, cuantifican. Y producen innovación semántica con la
aparición de nuevos términos como: “hipervínculo”, “usabilidad”,
“narración transmedia”. Tienen su propio método, uno cíclico, iterativo, que
como una espiral pretende descubrir la complejidad más absoluta: los
comportamientos, los motivos de las personas. Todo un gran esfuerzo para
dilucidar, a veces, un click en una interfaz gráfica…
El origen de esta selección de textos nace como una necesidad académica:
contar con material bibliográfico para formar en diseño de interacción con
estándares de accesibilidad y usabilidad. Por lo tanto, el trabajo editorial se
justifica por la ausencia o falta de sistematización de fundamentos y casos
de experiencias de investigación, diseño y desarrollo de diseño de
Interacción en nuestro idioma. Colateralmente, al estar las Tecnologías de la
Información y el Conocimiento (TIC) presentes en casi todos los ámbitos de
la existencia humana, se torna ineludible el estudio de su impacto, y
representa un aporte al campo de la Etnografía Digital.
En esta primera edición se publican trabajos oriundos de Centroamérica,
Sudamérica, Norteamérica, Australia y Europa de algunos pioneros y
hacedores en Arquitectura de la Información, Diseño Centrado en el
Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño
participativo y Co-desarrollo.
Los capítulos, mediante casos o fundamentos, tratan temas que pretendimos
amplios, y que van desde ergonomía física y cognitiva, al desarrollo de un
videojuego y de un recurso educativo accesible, de métodos y dispositivos
para evaluar la interacción con la nueva televisión interactiva a las técnicas
de inspección e indagación heurística, a la Internacionalización de la web y
las normativas gubernamentales para hacer web accesibles y usables. Se
presentan así casos de diseño participativo y co-desarrollo tanto con niños
como con excluidos de la Sociedad de la Información y el Conocimiento,
como lo son algunos Pueblos Originarios o los adultos mayores. Con la
compilación de Pioneros y Hacedores se buscó brindar material para poder
comprender accesibilidad sin saber de programación y a su vez profundizar
en lenguajes y codificación. Iniciarse en Human Computer Interaction y en
Investigación de Usuarios, conocer el origen del diseño de interacción,
tanto como debatir su futuro. Pero también, y desde el oficio sociológico de
develar, se busca poner sombra al resplandor de las TIC ya que estas
muchas veces no informan ni comunican, no producen interacción, y por lo
tanto no propician la generación de conocimiento. Hoy, que estamos
insertos en un contexto de multiplataformas y se nos incita a creer en el
sueño dorado de vidas interactivas, pero en los hechos, la actual sociedad
que se auto proclama de ser de la información y el conocimiento, info-
intoxica e info-excluye. Comparto la idea de Jorge Arango cuando dice que
“(...) las personas que diseñamos artefactos digitales tenemos un
compromiso ético de lograr que la información que publicamos sea fácil de
encontrar y entender”. No queda duda acerca de que la accesibilidad web es
un derecho humano que permite la equidad ante el fenómeno del uso
masivo de dispositivos digitales. Asumiendo que la inclusión social hoy
requiere de inclusión digital, ¿no tendrán los ingenieros de sistemas y los
diseñadores una responsabilidad social mayor? ¿Y no tendrán los centros
educativos la responsabilidad de profundizar conocimiento en el
procesamiento humano de la información? Claramente, como lo apuntan
Yusef Hassan Montero y Sergio Ortega Santamaría en su capítulo
introductorio a la Interacción Persona Computadora, este campo se nutre de
una gran variedad de teorías y evidencias empíricas tomadas de diferentes
disciplinas, como la sociología, la antropología y el corpus teórico de la
psicología cognitiva fusionadas con la informática. Si la conducta humana
siempre ha sido un enigma y un desafío, las interfaces se nos presentan
como un constructo metodológico que, a la par que devela, oculta. Para
poder iluminar es necesario profundizar en métodos formales de
investigación en diseño de interacción, como lo hace Jonas Löwgren. Y,
asumiendo que los aspectos técnicos como poder comprender código y
estándares de la WC3 (World Wide Web Consortium) presentan tanto gran
complejidad como simpleza, hay una doble apuesta en este libro: asumir la
necesidad de profundizar conocimiento complejo y a la vez reconocer,
como lo señala Emmanuelle Gutiérrez y Restrepo que “no hacen falta
conocimientos que no sean aplicables a otros órdenes de nuestra vida, y sus
requisitos son todos de puro sentido común para dar la oportunidad a todos
los humanos de participar en la Sociedad de la Información y del
Conocimiento de manera equitativa”. Pero, cuando el respeto por los
Derechos Humanos no convoca, ni la obligación legal constriñe, se incita a
los hacedores de negocios en la web al respeto por los estándares de
accesibilidad como una ventaja; a tal fin, Olga Carreras Montoto describe
las buenas prácticas que pueden realizar los profesionales SEO (Search
Engine Optimization) para lograr posicionamiento en motores de búsqueda.
En el núcleo de pensamiento de este proyecto editorial está presente el
Diseño Universal, una apuesta política y económica porque materializa la
unión natural entre el Diseño Centrado en el Usuario y la sostenibilidad. Por
eso, la compilación de Fundamentos y Casos de Diseño de Interacción con
estándares de accesibilidad y usabilidad es material de lectura para personas
interesadas en diseño centrado en el usuario en particular y también para
personas comprometidas con el impacto de las tecnologías de la
información y la comunicación en general. Finalmente, en el kernel de estos
textos sobre tecnología está la emoción y la rigurosidad, porque estuvieron
presentes en quienes aunaron la casuística necesaria para crear un método y
difundirlo: Don Norman, Jakob Nielsen, Steve Krug, y Jared Spool. Un
legado de los pioneros que es buena expectativa para que las interacciones
mediadas por artefactos vehiculicen la interacción entre humanos.
Lorena Paz, octubre 2013
Agradecimientos
A los autores que han cedido sus derechos, reescrito y escrito especialmente
para este libro.
Hernán Thomas por introducirme en la sociología de la tecnología.

Julio Incarbone, por infalible compañero de ruta en DIEAU .
Sebastian Betti por el compromiso con el proyecto desde sus inicios.
Lilibeth Valdés Payo por su colaboración en la corrección entre pares.
Martín Szyszlican, por compañero de aventuras tecno-etnográficas.
Al Equipo de Investigación-Acción Sinapsis , un espacio abierto en
construcción.
todas las personas comprometidas en los usos sociales de las TIC para
el Desarrollo Humano.
Victor Malumían, de Ediciones Godot , que un día en un taxi cuando
le conté que quería hacer este libro, exclamó entusiasta: ¡yo lo edito! y
lo hizo.
Capítulo 1: El botón de los $300 millones, por Jared M. Spool
Desarrollador y programador y experto en técnicas de prototipado de baja
fidelidad. Es un miembro histórico del Special Interest Group on
COMPUTER-HUMAN INTERACTION (SIGCHI). Profesor en la Escuela
de Ingeniería de lnstituto Gordon de la Universidad de Tufts. Es
considerado un referente en estas disciplinas por haber fundado en los años
ochenta la consultora líder en investigación y desarrollo de productos web
“User Interface Engineering” y por haber escrito este famosísimo artículo.
Más información:
Twitter: @jmspool
Publicado originalmente el 14 de enero de 2009
Traducción: Mariana Inés Calcagno
Texto original: Ingresar al texto original del capítulo.
El botón de los $300 millones

Cuando Luke Wrableski estaba escribiendo su famoso libro Web Form
Design: Filling the blanks (Diseño Web de Formularios: Llenando los
espacios en blanco) me preguntó si podía pensar un ejemplo en el que un
cambio en el diseño de un formulario pudiera lograr una diferencia
importante en los resultados de un negocio. “¿Quieres decir algo así como
300 millones en nuevas ganancias?”, respondí. “Sí, algo así”, dijo Luke.
Entonces fue cuando escribí este artículo, que luego publicó en su libro.
Es difícil pensar en un formulario que sea más simple que éste: dos campos,
dos botones y un link. Sin embargo, resulta que este formulario estaba
impidiendo a los clientes hacer compras en un importante sitio de E-
commerce, con una ganancia calculada en $300.000.000 al año. Y lo que
era peor: los diseñadores del sitio no tenían ni idea de que esto estuviera
pasando. El formulario era simple. Los campos eran “Dirección de correo
electrónico” y “Contraseña”. Se trataba del ingreso al sitio, un tipo de
formulario que los usuarios llenan todo el tiempo. Los botones eran
“Ingresar” y “Registrarse”; el link, “¿Olvidó su contraseña?” ¿Cómo
podrían tener problemas con él?
El problema no estaba tanto en la disposición de los elementos del
formulario (layout) sino en el lugar en el que se ubicaba. Los usuarios lo
encontraban luego de haber llenado su carrito de compras y después de
haber presionado el botón “Comprar” (Checkout button), pero antes de
ingresar la información para pagar. El equipo vio que este formulario les
impedía a los usuarios frecuentes comprar más rápido. A los clientes que
compraban por primera vez no les importaría tomarse algo de tiempo extra
para registrarse porque, después de todo, volverían en otra ocasión y
apreciarían la rapidez en las compras subsiguientes. Todos ganaban, ¿no es
cierto?
“No estoy acá para iniciar una relación”

Realizamos pruebas de usabilidad con usuarios que necesitaran comprar
productos del sitio. Les pedimos que trajeran sus listas de compras y les
dimos el dinero para realizarlas. Lo único que debían hacer era completar la
transacción.
Estábamos equivocados acerca de los clientes que compraban por primera
vez. Sí les importaba la registración. En general, no les gustaba tener que
hacerlo. Como nos dijo uno de ellos, “No estoy aquí para empezar una
relación. Sólo quiero comprar algo”.
Algunos de ellos no podían recordar si era realmente la primera vez que
compraban, molestándose cada vez que las distintas combinaciones de
correo y contraseña que ingresaban fallaban. Nos sorprendió tal resistencia
al registro. Sin saber incluso lo que implicaba el proceso de registro, todos
los usuarios que clickeaban el botón lo hacían con un gesto negativo.
Algunos expresaban verbalmente cómo los comerciantes sólo querían los
datos para infectarles las casillas con spam que no querían. Algunos
imaginaban otros nefastos propósitos de la evidente intención de invadirles
la privacidad. (En realidad, el sitio no pedía ningún dato que no fuera
necesario para la compra: nombre, dirección de envío, domicilio fiscal y
modo de pago.)
No tan bueno para usuarios frecuentes tampoco

Los usuarios frecuentes no estaban mucho más contentos tampoco. Salvo
por algunos que recordaban la información de registro, la mayoría dudaba
frente al formulario. No podían recordar la dirección de correo que usaban o
la contraseña. Olvidar la dirección de correo correspondiente era
problemático, muchos tenían varias casillas o las habían cambiado a lo
largo de los años.
Cuando un comprador no podía recordar la dirección o contraseña,
ingresaba diferentes opciones varias veces. Estos intentos rara vez
funcionaban. Algunos le pedían al sitio que les enviara la contraseña por
correo electrónico, lo cual es un problema en el caso de no recordar la
dirección ingresada inicialmente el registro.
(Más tarde hicimos un análisis en la base de datos, y resultó que el 45% de
todos los clientes se había registrado más de una vez en el sistema, algunos
hasta 10 veces. También analizamos cuánta gente había solicitado la
contraseña por correo, para descubrir que el número llegaba hasta
aproximadamente a 160.000 por día. El 75% de estas personas nunca había
tratado de completar la compra que habían comenzado.)
El formulario, diseñado para favorecer el proceso de compra, terminaba por
ayudar sólo a un pequeño porcentaje de clientes. (Incluso muchos de ellos
tampoco eran ayudados, ya que les tomaba el mismo esfuerzo actualizar
cualquier dato incorrecto, como cambiar las direcciones o ingresar nuevas
tarjetas de crédito). Contrario a su intención inicial, el formulario impedía
ventas, muchas ventas.
La solución de los $300 millones

Los diseñadores resolvieron el problema de una manera muy simple:
sacaron el botón “Registrarse”. En su lugar, pusieron un botón nuevo:
“Continuar”, con un simple mensaje. “No es necesario crear una cuenta
para hacer una compra en este sitio. Cliquee “Continuar” para terminar su
compra. Para acelerar el proceso de sus futuras compras, puede crear una
cuenta durante el proceso”.
Los resultados: el número de clientes que concretaba las compras subió un
45%. El primer mes se produjeron unos 15 millones de ganancia adicional.
El primer año, el sitio produjo un extra de 300 millones.
En mi contestador automático está el mensaje que recibí del CEO del
vendedor de los 25 billones, la primera semana en la que vieron los
números de las ventas luego del rediseño. Es un mensaje muy simple:
“¡Spool, sos el mejor!”. No necesitaba un mensaje más complejo. Lo único
que hicimos fue cambiar un botón.
Capítulo 2: Cómo usamos la web realmente, por Steve Krug
Steve Krug es especialista en Experiencia de Usuarios, ha pasado más de
veinte años haciendo test de usabilidad. Ha escrito los dos libros más
referenciados en este campo: Don’t Make Me Think: A Common Sense
Approach to Web Usability y Rocket Surgery Made Easy: The Do-It-
Yourself Guide to Finding and Fixing Usability Problems. Es mundialmente
famoso por las charlas y workshops que tres veces al año dicta, muchas
veces en compañía del famoso Arquitecto de la Información Lou Rosenfeld.
Más información:
Título Original del libro: Don’t Make Me Think
Ver libro en Amazon.
Cómo usamos la Web realmente

¿Por qué las cosas están en el último lugar en
el que buscamos? Porque cuando las
encontramos dejamos de buscarlas. Adivinanza
infantil
En los últimos cinco años he pasado mucho tiempo observando a la gente
usar la Web, y lo que más me ha sorprendido es la diferencia que existe
entre el modo en que creemos que la gente usa los sitios y la manera en la
que realmente sucede.
Cuando creamos sitios, actuamos como si los usuarios fueran a estudiar
atentamente cada página, leyendo minuciosamente el texto que construimos
con detalle, descubriendo la forma en la que organizamos la información y
evaluando las opciones antes de decidir qué botón apretar.
Lo que en realidad suelen hacer los usuarios la mayoría de las veces (si
tenemos suerte) es echar un vistazo general a cada nueva página, ojear o
“escanear” rápidamente partes del texto y cliquear en el primer enlace que
capte su interés o se parezca vagamente a lo que están buscando. Incluso
hay grandes sectores de la página que ni se miran.
Pensamos “literatura de calidad” (o al menos “folleto de producto”), cuando
la realidad del usuario está mucho más cercana a “cartel publicitario que
pasa a 100 kilómetros por hora”.
Como se podrán imaginar, es un poco más complicado que esto, y depende
del tipo de página, lo que el usuario pretenda hacer, cuán apurado esté,
etcétera. Pero esta visión simplificada es mucho más cercana a la realidad
de lo que podemos suponer.
Es lógico que visualicemos un usuario más racional y atento al diseñar
nuestros sitios. Resulta natural asumir que todo el mundo usa la web del
mismo que nosotros lo hacemos, y –al igual que todos- tendemos a pensar
que nuestro comportamiento es mucho más ordenado y sensato de lo que
realmente es.
Sin embargo, si lo que quieren es diseñar páginas efectivas, deberán
aprender a lidiar con estos tres hechos sobre el uso real de la web.
Hecho de la realidad #1 Las páginas no se leen,

se hojean.
Uno de los pocos hechos bien documentados de la web es que los usuarios
suelen dedicar muy poco tiempo a la lectura en la mayoría de los sitios 1.
En lugar de ello, se tiende a “escanear” o leer por encima, buscando
palabras o frases que llamen la atención.
La excepción, por supuesto, son las páginas que contienen noticias,
informes, o descripciones de productos. Pero incluso en esos casos, si el
documento tiene más de unos pocos párrafos, es posible que sean impresos,
dado que es más fácil y rápido leer desde papel que desde la pantalla. ¿Por
qué hojeamos?
Normalmente estamos apurados. Gran parte de nuestro uso de la Web está
motivado por un deseo de ahorrar tiempo. Como consecuencia de esto, los
usuarios suelen actuar como tiburones: necesitan estar en movimiento, o se
mueren. Simplemente no cuentan con el tiempo para leer más de lo
necesario.
Sabemos que no necesitamos leer todo. En la mayoría de las páginas,
estamos interesados únicamente en una porción de lo que hay en ella. Sólo
buscamos las partes que se ajustan a nuestros intereses o a la tarea que
tenemos entre manos; el resto es simplemente, irrelevante. Hojeando es
como encontramos las porciones relevantes.
Somos buenos haciéndolo. Hemos estado hojeando diarios, revistas y libros
toda la vida para encontrar las cosas que nos interesan, y sabemos que
funciona.
El efecto red es muy similar al clásico dibujo de Gary Larson, Far Side,
sobre las diferencias entre lo que suele decirse a los perros y lo que ellos
realmente oyen. En la historieta, el perro (llamado Ginger) parece estar
escuchando atentamente a su amo mientras este le da una charla seria sobre
no hurgar más en la basura. Pero desde el punto de vista del perro, lo único
que el dueño dice es “bla bla GINGER, bla bla bla GINGER bla bla bla”.
Lo que vemos cuando miramos una página web depende de lo que
tengamos en mente, que usualmente implica una pequeña porción de lo hay
en ella.
Al igual que Ginger, tendemos a focalizar en las palabras y las frases que
parecen ajustarse a) a la tarea que tenemos que realizar, b) nuestros
intereses del momento o de las circunstancias, y, desde luego c) las palabras
clave disparadoras de reacciones, programadas ya en nuestro sistema
nervioso, como “gratis”, “liquidación” y “sexy”.
Hecho de la realidad #2 No tomamos óptimas

decisiones. Nos conformamos con lo suficiente.
Al diseñar nuestros sitios, solemos asumir que los usuarios van a echar un
vistazo general, considerar todas las opciones disponibles y optar por la
mejor.
Sin embargo, lo que en realidad sucede la mayoría de las veces es que no se
elige la mejor opción, sino la primera opción razonable, una estrategia
conocida como “satisficing” 2. En cuanto encontramos un enlace que en
apariencia puede llevarnos hacia lo que buscamos, hay una gran chance de
que lo hagamos click sobre él.
Había notado este comportamiento durante años, pero su significado no me
resultó del todo claro hasta que leí el libro de Gary Klein, Sources of power:
How People Make Decisions [Fuentes de Poder: cómo la gente toma sus
decisiones] 3. Klein pasó quince años estudiando la forma natural de toma
de decisiones: el modo en que bomberos, pilotos, maestros del ajedrez u
operadores de plantas de energía nuclear toman importantes decisiones en
situaciones reales, presionados por el tiempo, sin objetivos precisos, con
información limitada y condiciones cambiantes.
El equipo de observadores de Klein trabajaron en el primer estudio (con
comandantes del cuerpo de bomberos en escenas reales de incendios) desde
el modelo generalmente aceptado sobre la toma racional de decisiones:
frente a un determinado problema, las personas suelen reunir la información
necesaria, identifican posibles soluciones y eligen la más adecuada.
Partieron de la hipótesis de que debido al alto nivel de riesgo y la extrema
presión del tiempo, los capitanes serían capaces de comparar sólo dos
opciones, una presunción que consideraban prudente. Finalmente, sucedió
que los comandantes no compararon ninguna opción. Tomaron el primer
plan razonable que se les vino a la mente y evaluaron rápidamente los
problemas. Si no encontraban ninguno, ya tenían resuelto su plan de acción.
Entonces, ¿por qué los usuarios de la Web no buscan la mejor opción
posible?
Normalmente estamos apurados. Y como plantea Klein “la optimización es
difícil y lleva tiempo. Satisficing (tomar la primera decisión razonable) es
más eficiente”.
No hay consecuencias graves en caso de error. A diferencia de lo que deben
enfrentar los bomberos, las consecuencias de tomar decisiones equivocadas
en la web se solucionan presionando una o dos veces el botón de “volver”,
haciendo del satisficing una estrategia efectiva. Asumimos, claro, que la
página carga rápidamente; si esto no fuera así, deberemos decidir con más
cuidado, una de las tantas razones por las que a la mayoría de los usuarios
web no les gustan las páginas que tardan en cargar.
Evaluar las opciones no siempre implica una mejora de las oportunidades.
En los sitios mal diseñados, esforzarse en tomar la decisión correcta no
ayuda demasiado. Normalmente resulta mejor seguir el primer instinto y
recurrir al botón “Volver” si no funciona.
Adivinar es más divertido. Implica menos trabajo que evaluar las opciones,
y si la suposición es correcta, resulta muy rápida. Además le otorga un
elemento de suerte –la posibilidad placentera de encontrarse con algo bueno
y sorprendente.
Sin embargo, esto no significa que no haya usuarios que evalúen y
comparen las opciones antes de hacer click. Depende de factores como su
estado de ánimo, cuan apurados estén, y el nivel de confianza que le tengan
al sitio.
Hecho de la realidad #3 No nos interesa

averiguar el funcionamiento de las cosas. Nos
las arreglamos.
Una de las cosas que resultan más evidentes al hacer cualquier prueba de
usabilidad, ya sea que se estén testeando sitios web, software o
electrodomésticos, es el grado en el que la gente hace uso de las cosas todo
el tiempo sin entender cómo funcionan, o con ideas incorrectas acerca de
ello.
Frente a cualquier tipo de tecnología, muy pocas personas se toman el
tiempo de leer las instrucciones. En lugar de eso, seguimos adelante y nos
las arreglamos, inventando historias propias y vagamente verosímiles de lo
que estamos haciendo y por qué funcionan.
Normalmente me recuerda a la escena final de “El príncipe y el mendigo”,
cuando el verdadero príncipe descubre que su doble ha estado usando el
Sello Real de Inglaterra como un cascanueces durante su ausencia. (Es
lógico: para él, el sello es sólo un grande y pesado pedazo de metal.)
Y el hecho es que, esta es el modo en que hacemos las cosas. He visto a
mucha gente usar software y sitios web de manera eficiente en formas que
no se parecen en nada a lo que los diseñadores pensaron.
Mi ejemplo favorito es la gente (y he visto docenas de ellos yo mismo) que
escribe la URL completa de un sitio en el buscador de Yahoo, no para
buscar el sitio por primera vez, sino cada vez que quieren visitarlo, incluso
varias veces por día en algunos casos. Si se les pregunta, resulta evidente
que para muchos de ellos, Yahoo es Internet, y que esa es la forma correcta
de usarla. 4
Lo interesante es que esta estrategia de “arreglárselas sobre la marcha” no
es exclusiva de los principiantes. Incluso los usuarios con conocimiento
técnico tienen a veces huecos inesperados en su comprensión sobre el
funcionamiento de las cosas. (No me sorprendería saber que el mismísimo
Bill Gates manejara algún aparato tecnológico utilizando este recurso.) ¿Y
por qué ocurre esto?
No nos parece importante. A la mayoría de nosotros no nos importa
entender cómo funcionan las cosas siempre y cuando las podamos usar. No
es por falta de inteligencia, sino por falta de interés. En nuestro esquema de
prioridades, simplemente no es importante. 5
Si encontramos un método que funciona, nos quedamos con él. Cuando
encontramos una estrategia que funciona -no importa si bien o mal- no
solemos buscar otra mejor. Usaríamos un mejor método si nos trabáramos
con algo, pero casi nunca nos dedicamos a buscarlo.
Siempre resulta interesante ver a los diseñadores y desarrolladores web
mientras observan su primera prueba de usabilidad. Se sorprenden la
primera vez que ven a un usuario cliquear sobre algo completamente
inapropiado. (Por ejemplo, cuando ignoran un botón precioso, grande y
gordo que dice “Software” en el menú, que dice al algo así como “Bueno,
estoy buscando software, entonces me parece que voy a cliquear en ‘cosas
baratas’ porque lo barato siempre es una buena opción”). El usuario podrá
encontrar, eventualmente, lo que está buscando pero entonces los
observadores no van a saber si deberían estar satisfechos o no.
La segunda vez que pasa, se lo verá gritando: “¡Sólo haga click en
‘software’! La tercera, pensarán: ¿para qué hacemos esto? Y es una
pregunta: si la gente logra arreglárselas tan bien, ¿importa realmente si lo
“entendieron”? La respuesta es que sí importa, y mucho, porque aunque
arreglárselas funcione a veces, tiende a ser ineficaz y propenso a errores.
Por otro lado, si los usuarios “entienden”: Hay muchas más chances que
encuentren lo que están buscando, lo que es bueno para ellos y para
nosotros. Hay una mayor posibilidad de que comprendan todo lo que el sitio
tiene para ofrecer y no sólo las partes con las que se tropiezan en el camino.
Se aumenta la oportunidad de guiar a los usuarios hacia las partes que más
queremos que vean.
Se sentirán mejor y más seguros usando el sitio, lo que los hará regresar.
Podemos convencerlos con un sitio en el que puedan arreglárselas hasta que
alguien desarrolle otro que logre hacerlos sentir bien y confiados Si la vida
te da limones…
A esta altura deben estar pensando (dada esta pálida imagen de los usuarios
de la web): “¿Por qué no me dedico a vender detrás de un mostrador todo el
día? Al menos mis esfuerzos serían reconocidos.” ¿Entonces qué
deberíamos hacer?
La respuesta es que si su público se comporta como si le estuvieran
diseñando carteles de ruta, entonces diseñen geniales carteles de ruta.
Referencias
1. Consultar Nielsen, Jakob, “How users read on the web”, octubre, 1997,
disponible en www.useit.com.
2. El economista Herbert Simon acuñó el término (una fusión entre
“satisfacer” y “ser suficiente”) en Models of Man: Social and Rational
Wiley, 1957.
3. En el MIT Press, 1998.
4. De la misma manera, he conocido a muchos usuarios de AOL que
piensan que AOL es Internet. Buenas noticias para Yahoo y AOL.
5. A los desarrolladores web les cuesta normalmente entender, incluso
creer, que la gente sienta esto, porque generalmente son personas
particularmente interesadas en saber el funcionamiento de las cosas.
Capítulo 3: Mobile Site vs. Full Site, por Jakob Nielsen
Ingeniero de interfaces, se doctoró en diseño de interfaces de usuario y
ciencias de la computación en la Universidad Técnica de Dinamarca. Ha
trabajado en usabilidad para Bellcore, IBM y Sun Microsystems. Ha escrito
numerosos libros en la materia, entre los que se destacan: Hypertext and
Hypermedia, Usability Engineering, Designing Web Usability, E-
Commerce User Experience, Homepage Usability: 50 Websites
Deconstructed, Prioritizing Web Usability, Mobile Usability.
Jakob Nielsen es mundialmente reconocido por autodenominarse el padre
de la palabra usabilidad y por seguir escribiendo este tipo de textos cortos,
simples y efectivos en la materia.
Más información:
Ver capítulo original.
Corrección Técnica: Sebastián Betti
Mobile Site vs. Full Site 1

Basados en pruebas de usabilidad realizadas en cientos de sitios, quedan
claras las siguientes pautas para realizar sus versiones mobile:
"Si cuenta con el presupuesto necesario para hacerlo, construya la versión
mobile de su sitio por separado. Cuando los usuarios acceden a los sitios en
sus dispositivos móviles, el nivel de usabilidad medido es mucho más alto
que para las versiones web."
Una aplicación mobile puede resultar aún mejor – al menos por ahora.
Si un usuario móvil llega a la URL de la versión web de su sitio,
redirecciónelo automáticamente a la versión mobile. Lamentablemente,
algunos buscadores no rankean los sitios mobile lo suficientemente alto, por
lo que a menudo los usuarios son guiados hacia las versiones web, que
ofrecen una experiencia de usuario altamente superior.
Ofrezca un enlace claro que lleve a los usuarios de la versión web a la
versión mobile, además del redireccionamiento mencionado.
Ofrezca un enlace claro de la versión mobile a la versión web para aquellos
(pocos) usuarios que necesiten acceder a funciones especiales que sólo se
encuentren en la versión completa.
Hemos realizado pruebas en cientos de sitios en sus versiones mobile y web
en todas las plataformas actualmente populares (incluyendo iPhone,
Android, Windows Phone y Blackberry). Los resultados encontrados fueron
los mismos para todos los tipos de teléfonos, por lo que no hablaremos de
dispositivos en particular.
Las pautas son diferentes para las tablets grandes (10 pulgadas, como la
Apple iPad, Lenovo IdeaPad, Samsung Galaxy, etc.), en las que las
versiones web funcionan razonablemente bien. Para las tabletas pequeñas
(de 7 pulgadas, como la Amazon Kindle Fire) lo ideal sería crear un tercer
diseño para dispositivos de tamaño mediano, aunque las mayorías de las
compañías pueden arreglárselas haciendo que el servidor les entregue la
versión mobile a los usuarios del Kindle Fire.
Sitios Mobile
Para exponer por completo las pautas para la realización de sitios mobile
necesitaríamos 300 páginas, por lo que es imposible abarcarlas aquí. Las
ideas básicas son:
Cortar funcionalidades, para eliminar aquellos elementos que no sean
fundamentales en el uso del dispositivo móvil.
Cortar contenido, para reducir el conteo de palabras y derivar la
información secundaria hacia páginas secundarias; y
Agrandar los elementos de la interfaz, para resolver el problema del
“dedo gordo”
El desafío es eliminar funciones y reducir la cantidad de palabras sin limitar
la selección de productos. Un sitio mobile debería tener menos información
sobre cada producto y menos cosas que los usuarios pueden hacer con ellos,
pero el rango de items debería permanecer igual al de la versión web. Si los
usuarios no pueden encontrar un producto en un sitio mobile, asumen que la
compañía no lo vende y lo buscan en otro lado.
Entonces, por ejemplo, el sitio mobile de una empresa inmobiliaria debería
mostrar todas las casas en venta de un barrio determinado, no sólo las que
despiertan mayor interés. (Aunque podría ofrecer como atajo una pequeña
lista de las propiedades más populares para que los usuarios puedan acceder
de un solo click.). Pero el sitio mobile podría eliminar funcionalidades
“esotéricas” – como el historial de venta de propiedades– y ofrecer a los
usuarios que quieran acceder a esa información un enlace al sitio web en su
versión completa.
¿Por qué las versiones web de los sitios no

sirven para el uso de dispositivos móviles?
Es común hoy en día escuchar a la gente sostener lo siguiente: los usuarios
mobile tienen cada vez mayores expectativas respecto de lo que deberían
poder hacer con sus dispositivos, por lo tanto, la eliminación de cierto
contenido o funcionalidades inevitablemente desilusionará a algunos. De
esta manera, continúa (erróneamente) el argumento, es mejor entregarles el
sitio en su versión completa a todos, incluso a los usuarios mobile.
Este análisis es erróneo porque asume que la elección está entre la versión
completa del sitio web y la versión mobile recortada. Sin embargo,
cualquier sitio mobile que cumpla con las pautas de usabilidad
proporcionará los enlaces hacia el sitio web donde sea necesario, de modo
que los usuarios tengan acceso a todo el contenido y las funcionalidades en
caso de que lo requieran.
El desafío del diseño es hacer los recortes de tal manera que el sitio mobile
satisfaga casi todas las necesidades de los usuarios. Si se cumple esta meta,
el esfuerzo adicional de interacción de clickear en el enlace al sitio web,
ocurrirá muy raramente.
Es cierto, hemos visto algunos sitios mobile diseñados pobremente que
difícilmente podrían satisfacer las necesidades mobile de cualquiera. Pero
un mal diseño no es razón suficiente para tirar todo por la borda y
abandonar una pauta correctamente documentada. (De hecho, si malas
interfaces fueran razones suficientes para rechazar una categoría de diseño
entera, no tendríamos Internet en absoluto. Hay montones de sitios poco
usables dando vueltas por ahí. Pero esto no significa que no podamos
diseñar buenos sitios siguiendo las normas que los malos sitios violan)
El correcto análisis sería el siguiente:
Para la gran mayoría de la tareas, los usuarios mobile obtendrán una mejor
experiencia de usuario a través de un sitio mobile bien diseñado que de su
versión web.
Para una pequeña cantidad de tareas, los usuarios mobile serán apenas
retrasados al clickear sobre el enlace a la versión web.
Una gran ganancia que se experimenta frecuentemente compensará
cómodamente a un pequeño esfuerzo adicional que ocurre raramente.
Un segundo argumento en contra de los sitios mobile es que se podría
simplemente optimizar el sitio web para su uso mobile en primer lugar. Por
lo tanto, darles a los usuarios la versión completa no debería causarles
ninguna molestia. Aunque es cierto, este análisis no tiene en cuenta la
sanción impuesta a los usuarios web cuando se les da un diseño que es
menos óptimo para pantallas más grandes y mejores dispositivos de entrada.
Si los usuarios web fueran una pequeña minoría sería aceptable, pero casi
todas los sitios web reciben sustancialmente más tráfico (y más
transacciones) de sus usuarios web que de los usuarios mobile. Por lo tanto,
aunque queramos atender las necesidades de estos últimos, no podemos
dejar de lado a los usuarios “de escritorio”, quienes, después de todo, pagan
la mayor parte de nuestros salarios.
¿Lo básico? La interfaz de la plataforma de los usuarios de escritorio difiere
de la interfaz de la plataforma de los usuarios mobile en muchos aspectos,
incluídos las técnicas de interacción, cómo la gente lee, el contexto de uso y
el número de cosas que pueden ser captadas a simple vista. La desigualdad
es simétrica: los usuarios mobile necesitan un diseño diferente al de los de
escritorio. De la misma manera, estos últimos necesitan un diseño diferente
al de los primeros.
Referencias
1. Llamamos Mobile Site a la versión de un sitio web diseñada para ser
vista en dispositivos móviles y Full Site a su versión web o “de pantalla
completa”.
Capítulo 4: ¿Qué se mueve?, por Don Norman
Donald A. Norman es profesor emérito de ciencia cognitiva en la
Universidad de California y profesor en Northwestern y en Stanford.
Trabaja desde la ciencia cognitiva a la ingeniería de la usabilidad. Es
mundialmente reconocido como un referente en usabilidad, ha escrito
numerosos libros en la materia, entre los que se destacan: Direct
manipulation interfaces, User Centered System Design, New Perspectives
on Human-Computer Interaction, The Design of Everyday Things, The
Psychology of Everyday Things, Emotional Design, The Design of Future
Things. Cofundó el Nielsen Norman Group.
Más información:
Ver capítulo original.
¿Qué se mueve?
Estaba en Asia, dando una charla. Me habían dado un control remoto para
pasar mis diapositivas. El aparato tenía dos botones, uno arriba del otro. No
me gustan las presentaciones tradicionales con porciones largas de texto que
el orador lee a la audiencia, así que tengo una sola regla: “Sin palabras”. La
mayoría de mis diapositivas son fotografías. Estaba todo listo para la
primera imagen, pero cuando apreté el botón de arriba para avanzar, fui
engañado: en lugar de ir hacia adelante en la presentación, retrocedí.
¿Cómo pudo pasar esto?, me pregunté. “Arriba” siempre significa “hacia
adelante” y “abajo”, “hacia atrás”. El mapping es claro y evidente. Si los
botones hubieran estado uno al lado del otro, entonces sí el control habría
sido ambiguo: ¿qué viene primero, derecha o izquierda? No queda claro.
Pero este control estaba usando el mapping correcto de arriba y abajo. ¿Por
qué estaba mal diseñado?
Decidí utilizar la situación como ejemplo para la audiencia. Les mostré el
aparato y pregunté: “¿qué botón debería apretar para ir a mi próxima
diapositiva?, ¿el de arriba o el de abajo?” Para mi gran sorpresa, las
respuestas estaban muy divididas. Algunos pensaban que debía ser el de
arriba, al igual que yo. Pero un gran número de personas opinaba lo
contrario.
¿Cuál era la respuesta correcta? Al hacer esta pregunta alrededor del mundo
descubrí que algunas personas defendían firmemente su postura sobre el
botón de arriba, tan firmemente como lo hacían los que pensaban que la
respuesta estaba en el de abajo. Todos se sorprenden al ver que otro pueda
pensar diferente. ¿Quién tiene razón? Todos.
Al principio estaba desconcertado pero después me di cuenta de que se
trataba de un problema de punto de vista: ¿es la persona la que avanza hacia
la próxima diapositiva (botón de arriba) o son las diapositivas las que se
mueven hacia el lector (botón de abajo)? Recordé que diferentes culturas
perciben el tiempo de diferente manera: en algunas culturas, el tiempo es
representado mentalmente como una especie de “estiramiento” de la
persona hacia adelante mientras avanza a lo largo de la línea de tiempo. En
otras culturas existe una representación similar, solo que en estos casos es la
persona quien permanece fija, mientras es el tiempo el que se mueve: un
evento futuro retrocede en dirección a la persona. La metáfora determina
una percepción del mundo, y para los diseñadores, determina qué botón
debería seleccionar la diapositiva siguiente: el de arriba si el lector es el que
avanza, el de abajo si las diapositivas se mueven hacia él.
Resulta que la vida es un poco más compleja. Algunas culturas (como la
China Mandarina, por ejemplo) a menudo representan la línea de tiempo
verticalmente. Otras poseen una visión bastante diferente. Por ejemplo, ¿el
futuro se encuentra hacia adelante o hacia atrás? Para la mayoría de
nosotros esta pregunta no tiene sentido: obviamente, el futuro está adelante
y el pasado detrás. Todos los que pensamos de esta manera debatimos sobre
la llegada del futuro y nos alegramos de que ciertos eventos desafortunados
del pasado hayan “quedado atrás”.
¿Pero por qué no podría el pasado estar delante nuestro y el futuro detrás?
Consideren lo siguiente: podemos ver lo que está delante, pero no lo que
está detrás nuestro, del mismo modo que podemos recordar lo que pasó,
pero no podemos “recordar el futuro”. No solo eso, sino que además
podemos recordar mucho mejor eventos recientes que aquellos que
sucedieron largo tiempo atrás, capturados claramente por la metáfora visual
en la que el pasado se alinea antes que nosotros, los eventos más recientes,
ubicados más cerca, por lo que se pueden percibir (recordar) con mayor
claridad, mientras que los sucesos anteriores se ubican más lejos,
recordados y percibidos con mayor dificultad.
Si el tiempo se dispusiera en una línea horizontal, ¿iría de izquierda a
derecha o de derecha a izquierda? Cualquiera de las dos opciones es
correcta porque la elección es arbitraria, igual de arbitraria que la elección
de si un texto debe escribirse en una página de izquierda a derecha o de
derecha a izquierda. Sucede, sin embargo, que la elección de la dirección de
un texto también se corresponde con su concepción del tiempo. Las
personas cuyas lenguas nativas son árabe o hebreo suelen creer que el
tiempo fluye de izquierda a derecha (estando el futuro hacia la derecha).
Escoger una alternativa de la metáfora o la otra va a determinar el diseño
adecuado para la interacción. Cuestiones similares aparecen en otros
dominios. Consideremos, por ejemplo, el problema típico del scrolling en
una ventana. ¿El control del scrolling debería mover el texto o la ventana?
Esto constituyó un debate casi religioso en los primeros años de display
terminals, mucho tiempo antes del desarrollo delas computadoras
modernas. Eventualmente, hubo un mutuo acuerdo en que el cursor arrow
keys – y más adelante, el modo en el que el mouse movería las window
scroll bars- seguirían el modelo de la ventana en movimiento. Al leer un
texto, cuando el ojo alcanzaba el final de la pantalla, uno movía la ventana
hacia abajo para continuar leyendo, pero como, de hecho, la ventana estaba
firmemente fijada por el hardware, el display respondía moviendo el texto
hacia arriba: la mano se movía hacia abajo, el texto hacia arriba.
En los casos donde la metáfora era “agarrar” la imagen visual, el
movimiento era el contrario: “tome la imagen y muévala en la dirección que
usted desee”. En este caso, para ver más texto por debajo de lo que se podía
ver en la pantalla, había que agarrar el texto y moverlo hacia arriba. Uno
mueve la mano hacia arriba para visualizar lo que está más abajo.
Los usuarios aceptaron estas convenciones casi naturalmente, razón por la
cual se mantuvieron como tales por más de una década. Pero ahora estamos
cambiando de nuevo, ahora que ya no movemos scroll bars pero usamos
“gestos” para mover el texto.
Cuestionamientos similares surgieron en relación con las forma de
exhibición de los aviones: ¿deberíamos mostrar las diferentes partes del
avión como una aeronave que se mueve hacia un horizonte fijo o una
aeronave fija que se traslada hacia un horizonte en movimiento? La primera
opción es correcta si interpretamos la metáfora mirando el avión desde
atrás, donde el horizonte se mantiene fijo mientras se traslada la aeronave, o
desde el punto de vista del piloto, donde el avión se mantiene fijo siendo el
horizonte el que se mueve.
En todos los casos, todos los puntos de vista son correctos. Todo depende
de qué es lo que consideremos en movimiento. Pero esperen, que todavía no
terminé. En algunas sociedades aborígenes australianas, la orientación por
puntos cardinales aún es dominante, basándose en la dirección en la que
sale y se pone el sol. Si le damos a alguien de estas comunidades un grupo
de fotografías estructurado temporalmente (por ejemplo, imágenes de un
hombre envejeciendo o un niño comiendo) y les pedimos que las ordenen,
mientras una persona común de occidente las ordenaría de izquierda a
derecha (la más nueva hacia la derecha), un miembro de estas comunidades
aborígenes lo haría de este a oeste, ubicando la más nueva en el oeste. Si la
persona estuviera mirando hacia el sur, colocaría la imagen de izquierda a
derecha. Si, en cambio, mirara hacia el norte, lo haría de derecha a
izquierda. Finalmente, si estuviera enfrentado al oeste, las ordenaría en una
línea vertical extendida desde su cuerpo hacia afuera, siendo la más reciente
la que esté más lejos de su cuerpo. Por lo tanto, ubicaría pegada a su cuerpo
la más reciente si enfrentara el este. ¿Pero qué significa todo esto para el
diseño? Buena pregunta.
Agradecimientos
Estoy en deuda con Lera Boroditsky, por su investigación sobre la
concepción del tiempo (y por su voluntad de discutirla conmigo).
Capítulo 5: Diseño de interacción, prácticas de investigación y diseño
en materiales digitales, por Jonas Löwgren
Creador de una de las maestrías en Diseño de Interacción en Europa y co-
fundador de School of Arts and Communication. Es reconocido
mundialmente por escribir textos clave en esta disciplina, que representan
un aporte a la definición y a los métodos del Diseño de Interacción.
Actualmente profundiza sobre cross-media y visualización interactiva. Es
profesor de Diseño de Interacción en Malmö University, en Suecia.
Más información:
Traducción: Sebastián Betti
Diseño de interacción, prácticas de

investigación y diseño en materiales digitales
En este ensayo presento el diseño de interacción, examino la naturaleza de
la investigación actual en diseño de interacción y sus dilemas. Finalmente,
desarrollo lo que podría (y quizá debería) ser el diseño de interacción.
Considero al diseño de interacción como el acto de dar forma a los
productos y servicios digitales, lo que se considera como trabajo de diseño.
La segunda parte de la frase es significativa dado que los productos y
servicios digitales se han desarrollado durante muchos años en varios
campos de la academia y la industria, pero en general en base a otros
fundamentos.
En mi opinión, los diseñadores de interacción no están muy emparentados
con los ingenieros y desarrolladores de sistemas, sino más bien con los
diseñadores industriales y los arquitectos.
A diferencia de los diseñadores industriales y de los arquitectos, los
diseñadores de interacción se especializan en materiales de diseño digital:
software, electrónica y telecomunicaciones. Un diseñador de interacción
podría trabajar por ejemplo en sitios web, teléfonos celulares, productos de
comunicación, información distribuida en espacios públicos, comercio
electrónico, instalaciones de arte interactivas, tecnología de rehabilitación y
sistemas empresariales. Por lo tanto, debemos preguntarnos qué significa
tener en cuenta los esfuerzos propios en áreas como el trabajo de diseño.
El trabajo de diseño se caracteriza por los siguientes aspectos:
Explorar posibles futuros, partiendo de una situación concreta.

Tratar de cambiar la situación para mejor mediante el desarrollo y la
introducción de algún tipo de producto o servicio, es decir, del
resultado concreto del proceso de diseño.
Tener en cuenta la práctica y la técnica, así como la estética y las
cualidades éticas.
Llegar a comprender la tarea —el objetivo del trabajo de diseño— y a
la vez el espacio de las posibles “soluciones”.
Pensar bocetando, construir modelos, y expresar ideas potenciales en
otras formas tangibles.
Las diferencias más significativas entre el diseño de interacción y otras

disciplinas que desarrollan productos y servicios digitales reside en los
últimos elementos: el interés por las cualidades estéticas y éticas, el
conocimiento creciente del objetivo durante todo el proceso, en lugar de
congelarlo en una especificación temprana, y la importancia de explicitar
las ideas. El diseño se ve generalmente como una relación de servicio, en la
que el diseñador crea un artefacto —un producto o un servicio— para uno o
más clientes.
Hay una cultura del diseño emergente en el campo digital, donde empresas
como Apple y Meta Creations de Kai Krause jugaron importantes papeles
formativos desde el principio en la difusión de los servicios móviles y de
los videojuegos y en los últimos años ha contribuido a la creación de una
clase de consumidores en busca de calidad de diseño.
Del mismo modo, hay una cultura de la investigación cada vez mayor en el
diseño de interacción, con raíces que se remontan a las disciplinas
académicas de la informática y de la interacción persona-computadora, y un
interés central en la relación entre el diseño y la investigación.
Mi propósito aquí es analizar la forma en que puede verse el diseño como
construcción de conocimiento, o más específicamente, la manera en que el
diseño de interacción puede conducir al conocimiento científico de los
materiales digitales. Otra forma de parafrasear mi preocupación es
preguntando: ¿Qué significa investigar mediante el diseño de interacción?
En primer lugar, cabe señalar que el diseño con frecuencia conduce a nuevo
conocimiento de interés para otros diseñadores y para situaciones de
proyecto futuras, a veces estrechamente relacionadas con la situación de
partida y, otras veces, conectadas más remotamente. Un ejemplo clásico del
campo de software es la hoja de cálculo, presentada por primera vez en
1979 por Dan Bricklin y Bob Frankston en el producto VisiCalc como una
forma de resumir las columnas de números en las cuentas financieras.
Imágen 1: VisiCalc y Excel:La idea básica de una hoja de cálculo tiene gran potencial.
Imágen 2: La Imac original de Apple y el cuenta pasos PE316FM de Oregon Scientific de

una fecha posterior
El diseño y la construcción de los detalles de VisiCalc pueden no haber sido

muy influyentes, pero la idea central de una hoja de cálculo dinámico ha
demostrado ser un conocimiento viable y valioso usado con ulterioridad no
solo en otros programas contables, sino también en otras áreas donde se
supone que los usuarios construyen sus propios modelos de cálculo.
Otro ejemplo de conocimiento en el diseño (¿un meme de diseño?) es el
lenguaje formal orgánico y translúcido desarrollado por Jonathan Ive para la
iMac de Apple en 1998, que ha inspirado una amplia gama de proyectos de
estilo para todo tipo de productos de consumo.
La hoja de cálculo y el estilo Bondi Blue son ejemplos bastante diferentes
en muchos sentidos, pero ambos muestran cómo el diseño puede conducir a
nuevos conocimientos sobre la función y la forma, que puede aplicarse a
otros diseñadores y otras situaciones de diseño. Esto no es nada nuevo para
los lectores familiarizados con la enseñanza del diseño, donde los ejemplos
de diseño siempre han jugado un papel central.
Un profesor de diseño presenta un nuevo campo mediante ejemplos de
diseño de ese campo, los estudiantes pasan horas estudiando los ejemplos
canónicos de su campo, examinan proyectos de otros estudiantes y el
trabajo se presenta a todo el grupo, añadiendo así un nuevo ejemplo.
Pasando del uso cotidiano de los ejemplos de la cultura de diseño a
perspectivas más teóricas, encontramos evidencia significativa de la teoría
del diseño para indicar que uno de los elementos más importantes de la
capacidad de diseño es un repertorio de ejemplos abstractos como medio
para generar ideas en nuevas situaciones de diseño.
A nivel general, parece fácil decir que el diseño puede generar
conocimiento de valor para otros diseñadores. Por otra parte, se deduce que
los diseñadores y otros actores en el campo del diseño, junto con su
comunicación y los artefactos del campo, pueden verse como una
comunidad para la construcción colaborativa de conocimiento. Cuando un
diseñador desarrolla una nueva idea y la presenta a la comunidad como una
posible contribución al conocimiento, está haciendo una declaración en un
debate en curso.
Algunas declaraciones reciben muchísima atención, muchos colegas se
apropian de la idea para probarla en nuevas situaciones de diseño o la
elaboran de diferentes maneras, mientras que otras declaraciones pasan sin
pena ni gloria.
Lo que la comunidad encuentra correcto y verdadero cambia con el tiempo,
a veces poco a poco y otras veces de manera más abrupta, conforme se
desarrolla el corpus de conocimiento mantenido en forma cooperativa.
Las comunidades de diseño usan varios canales de comunicación, desde los
lugares tradicionales, como las revistas, las exposiciones y los premios
hasta las expresiones sub culturales que cuestionan los ideales dominantes.
Cabe mencionar también el papel de la crítica en relación a la noción de
comunidades de conocimiento de diseño. Los críticos y la crítica de un
campo del diseño contribuyen al crecimiento colaborativo del conocimiento
poniendo los ejemplos de diseño en contextos históricos, culturales y
sociales más amplios, analizando ideas desde perspectivas distintas a las de
los diseñadores, planteando preguntas inesperadas, señalando
consecuencias inesperadas. Los críticos y los diseñadores son actores
complementarios en la comunidad de conocimiento de un campo del
diseño.
El segundo paso del argumento está más específicamente relacionado con el
diseño que la construcción del conocimiento científico. Cada disciplina
científica tiene su comunidad, dedicada a la construcción colaborativa del
conocimiento. Un rasgo particular de las comunidades de conocimiento
científico es que dedican buena parte de sus esfuerzos de colaboración a la
cuestión de qué significa “científico”, es decir, qué contribuciones se
consideran conocimientos aceptables.
Los criterios varían entre las disciplinas científicas y yo, obviamente, no
puedo arrogarme un conocimiento completo de las prácticas de todas las
comunidades científicas.
Sin embargo, he pasado muchos años como investigador, participando en
una serie de diferentes comunidades científicas, y creo que he desarrollado
un cierto sentido de las normas científicas. A nivel general, yo diría que los
criterios científicos tienen que ver con la novedad, la relevancia, la
fundamentación y la criticabilidad.
Una contribución al conocimiento científico —una declaración en la

construcción del conocimiento actual de la comunidad científica—
debe ser nueva en el sentido de que la idea, afirmación o concepto
propuesto no sea ya una parte del corpus de conocimiento de la
comunidad.
Una contribución al conocimiento científico debe ser relevante —debe
ser singular, interesante y tener sentido. Si la contribución es de interés
para la comunidad científica, es posible que la llamemos relevante
internamente, mientras que si se trata de una aportación de interés para
el mundo fuera de la academia será extremadamente relevante. Las
contribuciones pueden ser relevantes, por supuesto, tanto a nivel
interno como externo, pero a veces solo son relevantes internamente.
Una contribución al conocimiento científico debe basarse en algo que
la comunidad considere aceptable. Las opciones más comunes son de
base empírica (una declaración se basa en observaciones), base teórica
(una declaración se basa en una teoría que es parte del corpus de
conocimiento de la comunidad o de una teoría que la comunidad
considera como una extensión aceptable del corpus de conocimiento) y
base analítica (una declaración se basa en el razonamiento que la
comunidad considera aceptable).
Una contribución al conocimiento científico debe ser criticable para
permitirle a otros miembros de la comunidad examinar los
fundamentos, las fuentes y los argumentos en los que se basa la
contribución. El principio es que otro investigador debe poder evaluar
la contribución científica identificando y criticando cada paso de la
construcción conceptual en la que se basa la contribución.
Si aceptamos la idea de que el diseño puede conducir al conocimiento,

entonces no hay nada en los cuatro criterios científicos generales que
impida que el diseño conduzca al conocimiento científico. En principio,
sería posible construir por diseño conocimiento nuevo, relevante, bien
fundamentado y criticable. Esta es, de hecho, la idea principal que deseo
plantear, y dedicaré el resto del texto a elaborar un poco el concepto.
Pero primero, tengo que hacer una digresión histórica. El concepto de
diseño de interacción está medianamente establecido —se ha mencionado
en ocasiones a partir de la década de 1980, pero en realidad no se extendió
hasta mediados de los años 1990— aunque ya está razonablemente bien
establecido .
Muchas empresas de las TIC, las telecomunicaciones y los medios de
comunicación tienen empleados con el título de Diseñador de Interacción
(aunque también es común el uso de términos como Arquitecto de
Interacción y Diseñador de Experiencia de Usuario para referirse a
descripciones de puesto similares). Muchas universidades se dedican a la
enseñanza y la investigación en el diseño de interacción a veces con ese
nombre y otras bajo el paraguas de la informática, el diseño industrial o las
ciencias de la computación.
Para simplificar las cosas un poco, podríamos decir que hay tres principales
tradiciones intelectuales que definen las condiciones para el diseño de
interacción en la actualidad. El campo de la informática ha alimentado un
interés por la ciencia del diseño desde la década de 1970, con énfasis en la
metodología de diseño y participación de los usuarios.
El campo académico de la interacción persona-computadora (HCI, por sus
siglas en inglés) surgió en la década de 1980 como una combinación de la
psicología aplicada y las ciencias de la computación, y se caracteriza por un
enfoque en el uso individual de los productos y servicios digitales con fines
instrumentales. Conceptos como usabilidad, utilidad y relevancia son
centrales en la HCI y el contexto tradicional es el uso de las TIC en
configuraciones de entornos de trabajo. La tercera tradición principal, y la
más reciente, es el diseño industrial. Solo en los últimos diez años el diseño
industrial ha demostrado interés en los materiales digitales, así como en la
creciente importancia de la integración de la forma física y los “contenidos”
digitales a la computación móvil y portátil.
En Suecia, y quizá en algunos otros países, también se ha dado el caso de
que el diseño industrial ha trabajado históricamente en el ámbito de las artes
aplicadas y solo recientemente se ha visto obligado a empezar a orientarse
hacia entornos de investigación académica.
Por lo menos dos áreas de las tres que forman el linaje intelectual del diseño
de interacción —la informática y la HCI— son campos académicos
relativamente bien establecidos con fuertes tradiciones científicas. De modo
que la nueva práctica de la investigación en diseño de interacción tiende a
adoptar las formas de normas originarias de la informática y la
investigación en HCI.
Estos son algunos ejemplos de tales normas:
Una tesis doctoral es un texto argumentativo, que empieza con una

introducción y una pregunta de investigación, sigue con la elección del
método de investigación y los resultados de la aplicación de los
métodos elegidos y termina con una respuesta tentativa a la pregunta
de investigación.
Una tesis doctoral es un libro de unas 200 páginas con mucho texto y
algunas fotos.
Una idea innovadora para un nuevo producto digital o servicio debe
ser probada con los usuarios antes de que su valor pueda ser evaluado.
Una contribución científica ideal es de validez universal, por ende es
cierta en todos los contextos y situaciones conocidos hasta el
momento.
Los lectores con experiencia en investigación son proclives a reconocer
estas normas. Todas están más o menos institucionalizadas en las
disciplinas científicas que dan forma a las condiciones para la investigación
del diseño de interacción en la actualidad. Sin embargo, si las comparamos
con los cuatro criterios generales anteriores (nuevo, relevante,
fundamentado, criticable), nos encontramos con que las normas son más
restrictivas que lo necesario.
Por ejemplo, imaginemos si un artefacto pudiera ser parte de la estructura
argumentativa de un aporte de conocimiento científico (en lugar de
limitarse a ser representado en un poco de texto y algunas fotos).
O, ¿qué tal si una tesis doctoral pudiera consistir en un producto digital más
una capa de fundamentación escrita y una capa de reflexión y abstracción
en texto?
¿Qué tal si una idea innovadora para un nuevo producto digital o servicio se
criticara mediante una base analítica en lugar de hacerlo mediante una base
empírica?
¿Qué tal si una contribución al conocimiento científico se encuadrara como
una semiabstracción? Eso significaría proponer una contribución con la
intención de que otros pudieran apropiarse de ella para otras situaciones
diferentes al diseño original, pero sin pretensiones de universalidad. Más
importante aún, se entendería que la apropiación exigiría una cierta cantidad
de trabajo, a pesar de que es tarea del contribuyente facilitar el trabajo de
apropiación informando las bases, las fuentes y el razonamiento, es decir,
haciendo que la contribución sea criticable. Por otra parte, el contribuyente
puede ayudar al apropiador discutiendo el alcance de la contribución y
delineando los tipos de situaciones en las que es más probable que tenga
sentido apropiarse de la contribución.
Todas estas situaciones hipotéticas y muchas otras, que se pueden prever
fácilmente, cumplen los cuatro criterios científicos generales, al tiempo que
infringen las normas institucionalizadas de diferentes maneras.
En otras palabras, la investigación de diseño de interacción parece estar
atrapada en la tensión entre las normas científicas de la informática/HCI y
el objetivo de hacer del diseño una parte del proceso de construcción de
conocimiento bajo criterios científicos más generales.
En esta sección, esbozo cinco estrategias perceptibles empleadas por los
investigadores para manejar esa tensión.
Diseñar prototipos para la evaluación empírica y estudiar las cualidades de
las nuevas ideas de diseño en uso. Esta es la estrategia dominante en HCI y
se basa a su vez en muchos años de ingeniería y prácticas de psicología
experimental. Algunos prototipos se construyen para demostrar la
viabilidad técnica de la idea (tales prototipos son llamados, de manera muy
reveladora, prototipos de prueba de concepto), mientras que otros sirven
como vehículos para la prueba de hipótesis en una metodología
experimental más o menos rigurosa. Los aportes de conocimiento derivados
de esta estrategia pueden ser supuestamente universales o semiabstractos,
en función de la perspectiva en la que se base la obra, y de los métodos
empíricos empleados.
Explorar las posibilidades de un material determinado de diseño, ideal de
diseño o tecnología. En esta estrategia, el trabajo de diseño se realiza como
una manera de explorar el espacio de posibles nuevos artefactos. Los
aportes de conocimiento son generalmente semiabstractos. Un ejemplo útil
de esta estrategia es la tesis doctoral de Tomas Sokoler 1, donde una
contribución al conocimiento criticable se compone de cinco ciclos de
diseño y reflexión sobre el diseño ideal de la computación ubicua. Como ha
señalado Krippendorff, el fundamento analítico de una contribución al
conocimiento en el contexto de la investigación de diseño puede incluir la
presentación de varios nuevos posibles artefactos (varias alternativas de
diseño) y una argumentación coherente en torno a sus cualidades como
forma de motivar la elección de una de las alternativas. Tales
aproximaciones de fundamentación deben ser de gran importancia en esta
estrategia.
Explorar futuros posibles bastante lejanos a las situaciones actuales. Aquí,
el trabajo normalmente implica diseñar artefactos centrales y su uso en un
futuro posible, y el examen de ese futuro a través de una combinación de
reflexión analítica y evaluación cuasi-empírica mediante modelos de visión
y dramatizaciones. Los aportes de conocimiento consisten en
semiabstracciones que abordan las posibles propiedades y cualidades de los
objetos propuestos. Un ejemplo de esta estrategia podría ser las notas de
trabajo post-hoc 2, un proyecto que dirigí hace unos años sobre el tema del
trabajo de oficina en un posible futuro en el que todas las reuniones,
documentos y otra información relacionada con el trabajo se almacenaran
en archivos multimedia. El trabajo de diseño consistió en modelar
herramientas para el acceso y la gestión de grandes volúmenes de
información y en hacerlos accesibles imaginándolos en una película que
mostrara el uso potencial de las herramientas en gestión de conocimiento en
una agencia de publicidad.
Diseñar artefactos para instanciar una teoría más general de un material
específico de diseño y evaluar los resultados. Las contribuciones de
conocimiento normalmente son semiabstracciones, aunque pueden resultar
contribuciones universales en caso de que el trabajo de diseño ofrezca razón
para modificar la teoría general subyacente. Un ejemplo ilustrativo es la
disertación doctoral de Andreas Lund 3 que combina una teoría universal de
la ciencia cognitiva en esquemas de imágenes y proyección metafórica con
el diseño y la evaluación de nuevos recursos digitales.
Realizar un proceso de diseño participativo, donde los futuros usuarios
actúen como expertos en su campo de práctica y no como objetos de estudio
o participantes en sesiones de evaluación. El diseñador/investigador
normalmente asume el doble papel de experto en el diseño de materiales del
que se trate y facilitador del proceso de diseño. Las contribuciones de
conocimiento son semiabstracciones relativas a la práctica en la que se lleva
a cabo el proceso de diseño y a las repercusiones de las intervenciones
socio-técnicas. Las maneras de actuar y razonar del diseñador/investigador
a menudo están estrechamente relacionadas con las de la investigación de
acción.
El proyecto Kliv es un ejemplo claro y reciente de esta estrategia, producto
de las contribuciones de conocimiento en los ideales de diseño de
interacción personificado y en la producción de medios de comunicación
locales, así como en prácticas sociales de gestión del conocimiento en
salud.
Más o menos todos los ejemplos de investigación disponibles en diseño de
interacción parecen considerar las publicaciones escritas y los resultados
reales —un proceso de diseño realmente no es investigación hasta que se
escribe un artículo o tesis sobre él.
El procedimiento estándar consiste en describir las ideas y los argumentos
en forma de texto y agregar algunas fotos de un prototipo o un modelo. La
norma “Mucho texto y algunas fotos” parece fuertemente arraigada y toda
la infraestructura de la comunicación científica se construye alrededor de
los textos escritos. Estas estructuras, por supuesto, no es algo fácil de
cambiar aunque algunas conferencias académicas experimentan un poco
con exposiciones y otros formatos.
Sin embargo, las normas existentes crean un problema general para la
investigación del diseño de interacción ya que los materiales digitales son
tanto temporales como espaciales. En otras palabras, las cualidades de un
producto digital o servicio dependen no solamente de su forma en dos o tres
dimensiones, sino de igual manera de la forma en que se comporta el uso
durante períodos más cortos o más largos de tiempo.
Un producto digital tiene una cierta sensación en uso. Algunos productos
pueden percibirse como incómodos y rígidos, otros más maleables y
fluidos. Por ejemplo, es posible hablar de la flexibilidad de una
visualización interactiva con referencia a la sensación del usuario de
modelar los datos presentados como un material táctil y receptivo,
fomentando la exploración y los descubrimientos fortuitos. Algunos
productos digitales demuestran todo su ámbito de aplicación en un breve
resumen en el primer contacto, otros aluden a grados de complejidad cuya
comprensión requiere tiempo y esfuerzo. Algunos productos se perciben
como poderosos, otros como débiles y suaves. La interacción tiene un ritmo
que puede ser lento o agitado, vacilante o insistente.
La flexibilidad y las cualidades similares son resultados del diseño de
interacción y por lo general no son visibles en la forma del producto.
Aparecen solo con el uso. Es bastante obvio que una presentación basada en
una gran cantidad de texto y algunas imágenes no puede transmitir esas
cualidades temporales. A diferencia del diseñador de sillas y de otros
objetos materiales, tenemos la posibilidad, en principio, de incluir una copia
de nuestro producto en la argumentación que construimos y difundimos en
la comunicación científica, por ejemplo, mediante la construcción de una
tesis doctoral en torno a un artefacto digital con una capa de texto de
fundamentación y otra capa de texto de reflexión y abstracción.
Imágen 3: Las sillas SUPERLEGGERA y TULIP son de uso muy diferente. Uno puede
sentirlo en el cuerpo con solo mirar las fotos.
Imágen 4: Los videojuegos SIMS 2 y GRAND THEFT AUTO también son muy diferentes al
uso. Eso no se nota demasiado en las imágenes.
Si bien podemos esperar la publicación de nuevas normas sobre la

investigación en diseño de interacción, también es interesante tener en
cuenta qué prestaciones permite la regla general “Mucho texto y algunas
imágenes” en materia de construcción de contribuciones de conocimiento.
Una posibilidad es la formulación de semiabstracciones en forma de
cualidades de experiencia, es decir, de conceptos que identifican
propiedades deseables en los géneros de productos, de manera tal que otros
diseñadores puedan apropiarse de los conceptos y los usen para diseñar
nuevos productos con las mismas cualidades. El concepto de flexibilidad
que he mencionado anteriormente es un ejemplo de la calidad de la
experiencia.
Otra idea que ha despertado un poco de atención recientemente es la
formulación de modelos, que refieren a ideas centrales del diseño que
aparecen en varios productos y pueden ser semi-abstraídas para su uso en
nuevas situaciones de diseño. El fundamento teórico para la formulación de
patrones es la idea de que el trabajo de diseño se guía por un repertorio de
ejemplos que se comparan con nuevas situaciones de diseño; la idea es que
un diseñador puede desarrollar su repertorio y por lo tanto extender su
capacidad de diseño mediante la apropiación de patrones formulados y
comunicados por otra persona.
La idea de los patrones procede de la obra de Christopher Alexander sobre
la planificación urbana en la década de 1970 y se ha empleado en el diseño
de interacción, principalmente como forma de captar soluciones estándar
probadas a problemas recurrentes (denominadas mejores prácticas). Sin
embargo, es perfectamente factible también para resumir las experiencias de
la exploración de espacios de diseño previamente desconocidas en lo que
podríamos llamar los patrones de inspiración, cuyo objetivo es proporcionar
material para que otros diseñadores desarrollen su conocimiento.
En este punto, he argumentado más ampliamente que el diseño puede dar
lugar al conocimiento y, específicamente, que el diseño de interacción
puede conducir al conocimiento científico. Para mí, la investigación de
diseño de interacción parece ser una posibilidad interesante y apasionante.
Deben abordarse otras dos preguntas. En primer lugar, ¿qué se requiere de
un diseñador/investigador en el ámbito académico? En segundo lugar,
¿cómo sería la investigación en diseño de interacción?
La primera pregunta se refiere esencialmente a la capacidad de diseño. Si el
objetivo es la construcción de conocimiento científico, ¿es necesario
entonces ser un buen diseñador de interacción?
La historia de la disciplina sugiere que la capacidad de diseño no es
esencial. Un argumento recurrente desde el campo de la investigación
experimental en HCI (estrategia 1, arriba) señala que un diseño que se ha
probado empíricamente con los usuarios puede ser incompleto y deficiente
en muchas formas, siempre y cuando las partes pertinentes a la pregunta de
investigación se hayan realizado de manera aceptable.
Este argumento me parece cuestionable, ya que supongo que los usuarios
que participan en un experimento se ven afectados por la situación,
incluyendo el prototipo incompleto y en parte inadmisible, a pesar de que el
propósito es solo probar, por ejemplo, una nueva forma de navegar ciertas
estructuras de información.
Por otra parte, probar una parte aislada de un producto en una situación que
no es muy similar a la situación de uso previsto parece una forma poco
fiable de obtener información sobre las cualidades del producto en el uso
real. En las estrategias 2 a 4 anteriores, los artefactos diseñados son por sí
mismos partes esenciales de las contribuciones de conocimiento. Parece
obvio que tienen que ser de calidad de diseño aceptable. La quinta
estrategia, donde el diseñador/investigador facilita un proceso de diseño
participativo, requiere normalmente que este proporcione conocimientos
especializados sobre las propiedades de los objetos digitales, así como un
rico repertorio de ejemplos de diseño de relevancia para la situación de
proyecto del que se trate.
Al parecer, la capacidad de diseño es un activo del diseñador/investigador y
un requisito para algunas de las estrategias identificadas anteriormente. En
términos más generales, la tarea de evaluar la calidad del diseño recaería
sobre la comunidad científica, así como la evaluación de otros aspectos de
la contribución de conocimiento.
Pero, ¿esto no implica una situación del huevo y la gallina? El diseño no es
una parte establecida de la comunidad científica y los conocimientos
necesarios para evaluar la calidad del diseño no están muy bien
representados en el corpus de conocimiento de la comunidad. Sin embargo,
esto no implica que los conocimientos necesarios para la evaluación sean
inexistentes. En el diseño de interacción, así como en otras disciplinas del
diseño, la capacidad de evaluación está muy relacionada con los
diseñadores experimentados y su papel en la comunidad. El diseño de
interacción es un campo muy joven sin mucho arraigo manifiesto, y con un
fuerte interés mutuo en aproximar la cultura del diseño a la cultura
científica.
Creo que hay algunas posibilidades para lograr que la calidad del diseño sea
uno de los criterios de evaluación de uso habitual para las contribuciones de
conocimientos relacionadas con el diseño. Por otro lado, una medida tal
podría ser controvertida ya que implicaría ciertas modificaciones en las
estructuras de poder prevalentes en la comunidad científica.
La segunda pregunta se refiere a cómo podría ser la investigación de diseño
de interacción y ya he abordado parte de eso en una respuesta preliminar.
Las cinco estrategias mencionadas anteriormente son ejemplos de
investigación en diseño de interacción, en la que el trabajo de diseño
desempeña un papel más o menos destacado en la construcción del
conocimiento real. Pero todavía veo gran potencial para seguir
desarrollando nuestros instrumentos científicos y nuestras prácticas de
investigación.
Más concretamente, parece que hay cuatro elementos principales en la
agenda de construcción de una comunidad más fuerte para la investigación
en diseño de interacción. Debe establecerse el concepto de contribuciones
de conocimiento semiabstractas junto a una práctica adecuada de
triangulación de las bases empírica, teórica y analítica. Tales nociones
resultan ya muy familiares a los investigadores con experiencia en
metodologías de investigación cualitativa, donde los conceptos de
fundamentación y criticabilidad forman parte del discurso científico
cotidiano.
Es necesario elaborar las posibles funciones de los artefactos en la
argumentación científica y la práctica de publicación. Esta muy
probablemente sea una preocupación en la investigación de diseño en
general, pero me resulta particularmente urgente para el diseño de
interacción, y esto se debe a que los artefactos digitales son particularmente
difíciles de representar en “mucho texto y algunas imágenes” debido al
carácter temporal de los mismos.
Los artefactos que se presentan como parte de las contribuciones de
conocimiento deben ser evaluados de manera integral en términos de la
calidad de su diseño. El peligro de aislar una pregunta de investigación y
tratar de responderla mediante un trabajo de diseño incompleto es que el
artefacto, que puede ser insuficiente respecto a los aspectos ajenos a la
pregunta de investigación, se difunda como una contribución conjunta de
conocimiento (dado que los ejemplos de diseño son de fácil apropiación
como un todo) y por lo tanto lleve un bagaje inferior de conocimiento.
Por último, tenemos que aprender de la función de la crítica en las
disciplinas de diseño más maduro, y específicamente de la interacción entre
la práctica creativa y la crítica en campos como la arquitectura. Con algunas
excepciones, el diseño de interacción carece de una disciplina de la crítica y
yo diría que buena parte de la evaluación que se realiza actualmente
mediante comprobación empírica de hipótesis aisladas funcionaría mejor en
una comunidad que incluya la crítica de diseño de interacción y su
evaluación analítica de perspectivas múltiples.
Estas son solo algunas sugerencias sin ningún tipo de pretensiones de
exhaustividad. Sin embargo, para mí en la actualidad representan las
medidas más urgentes para la práctica de la investigación en diseño de
interacción que contribuirían a un conocimiento aún más valioso para la
sociedad sobre las propiedades y posibilidades de los materiales digitales.
Sokoler desarrolla una perspectiva de diseño de la computación ubicua, con
énfasis en las habilidades y capacidades humanas, donde argumenta que la
tecnología digital debe colocarse a la par de otros recursos físicos y sociales
para una acción humana calificada. Este ideal de diseño se expresa a través
de un texto reflexivo que analiza cinco proyectos de diseño en el ámbito de
la mediación periférica de conciencia de situación, una herramienta para
navegar por el espacio físico mediante retroalimentación táctil, un
dispositivo de información personal para operadores de plantas de aguas
residuales, tarjetas de papel para controlar la reproducción de video en
entornos de colaboración creativa y un teléfono móvil para “hablar en
silencio”.
El proyecto notas de trabajo post-hoc partió de la suposición de que los
trabajadores del conocimiento en un futuro más o menos lejano tendrían
acceso a una infraestructura en la cual las reuniones y otras comunicaciones
cara a cara se almacenarán como grabaciones de video, junto a los
documentos, correo electrónico y otras comunicaciones asíncronas. Aparte
de los problemas de seguridad e integridad, también hay una cuestión
fundamental relativa a cómo acceder a esa masa potencialmente enorme de
material, de ser necesario. Contamos una historia de esa situación de uso
mediante el diseño de un conjunto de herramientas de gestión de
información y de acceso a la misma y las colocamos en una visión de
trabajo prevista que presentamos en forma de película. Las contribuciones
de conocimiento consistían en una nueva forma de combinar la búsqueda de
imágenes, de texto, en el análisis semántico de la información y la
visualización de información, así como en conclusiones sobre la
importancia de los metadatos y las formas de extraer metadatos de gestión
de la información manual sin sobrecarga.
La contribución al conocimiento de la disertación de Lund aborda el ideal
de diseño llamado masificación, lo que conlleva a nuevas formas de
visualización de información para expresar sus contenidos de información,
basado en la teoría general de la ciencia cognitiva de proyección metafórica
y esquemas de imagen. Dos proyectos de diseño forman parte de la
argumentación: una realidad virtual de visualización de colecciones de
páginas web, y un intento de visualización de datos temporales a través de
la espacialización. Las relaciones entre las bases teóricas generales y las
decisiones específicas de diseño se presentan en un nivel muy detallado, y
los dos proyectos de diseño se evalúan empíricamente, formando así una
triangulación teórico-empírica para fundamentar la contribución de
conocimiento.
La versión original de este capítulo no tenía referencias bibliográficas. Para
que esta versión funcione como un documento independiente, me gustaría
enumerar algunas referencias clave usadas en este artículo.
Referencias
1. Sokoler, T., Más allá de la computadora de escritorio con actitud, 2004.
2. Andersson, O., Cacciatore, E., Löwgren, J., Lundin, T., Notas de trabajo
Post-Hoc, 2002.
3. Lund, A., Masificación de lo intangible: Una investigación sobre el
sentido y la visualización de la información, 2003.
Bibliografía
Andersson, O., Cacciatore, E., Löwgren, J., Lundin, T., Post-hoc
worknotes: A concept demonstration of video content management.
Proc. 10th ACM Int. Conf. Multimedia (MM ’02), pp.670-671, Nueva
York, ACM Press, 2002.
Brandt, E., Björgvinsson, E., y Hillgren, P. A., Self-produced video to
augment peer-to-peer learning. Proc. Mlearn 2003: Learning with
mobile devices, pp. 27-34, London, Learning and Skills development
agency, 2004. [Una introducción bastante directa al proyecto Kliv]
Krippendorff, K., The semantic turn: A new foundation for design,
Boca Raton, fl: CRC Press. [Analiza, entre otras cosas, la idea de
validar el diseño mediante exploración y evaluación de alternativas],
2006.
Lund, A., Massification of the intangible: An investigation into
embodied meaning and information visualization, tesis doctoral,
Universidad de Umea, 2003. Disponible en www.diva-portal.org.
Löwgren, J., y Stoterman, E., Thoughtful interaction design: A design
perspective on information technology, Cambridge, Mass., MIT Press,
2004.
Nelson, H., y Stoterman, E., The design way: Intentional change in an
unpredictable world, Educational Technology Publishing. [De aquí
viene la noción de diseño como servicio]
Sokoler, T., Going beyond the desktop computer with an attitude, Tesis
doctoral, Universidad Técnica Blekinge, 2004. Disponible en The
Electronic Research Archive [Ver en línea].
Capítulo 6: Diseño participativo para la inclusión digital, por Stephen
Grant, Laurel Evelyn Dyson y Toni Robertson
Mini biografía de los autores
Trabajaron juntos creando el proyecto de investigación-acción “Programa
de Participación Indígena en Tecnologías de la Información” (IPIT) para
fomentar la inclusión digital de aborígenes australianos con foco en
propiciar la creación de la asignatura de tecnologías de la información
dictada para y por aborígenes tal cual se describe en este capítulo. Los tres
son docentes e investigadores de la Facultad de Ingeniería y Tecnología
Informática de la Universidad Tecnológica de Sydney .
Más información:
Diseño participativo para la inclusión digital: El

caso de los aborígenes australianos
Introducción
A principios de la década del ‘70 el gobierno australiano admitió que el
bajo nivel de participación de los aborígenes en todos los niveles educativos
era un gran problema. Por ejemplo, en 1972, un poco menos de 100
aborígenes australianos y habitantes de las islas del Estrecho de Torres se
habían inscripto en estudios terciarios (Gale, 1995). En ese momento, se
presentaron novedosas medidas orientadas a la igualdad de acceso, que
luego fueron modificándose durante las dos décadas subsiguientes. Estas
incluían asistencia financiera a los estudiantes indígenas, planes de ingreso
especiales, programas de apoyo y tutorías personalizadas. Sin embargo,
aunque se mejoró significativamente el número de inscripciones, la
finalización de los estudios seguía siendo un desafío. A finales de los ‘90, el
gobierno resumía la situación de la siguiente manera: “La tasa de acceso de
los indígenas a la educación superior, en el 1,5 % de los estudiantes que
ingresan, es ahora apenas menor que el de su grupo de población de 1,7 %.
Sin embargo, su éxito académico y permanencia dentro de la educación
superior sigue siendo muy baja. La alta deserción significa que, en general,
la participación de los indígenas en la educación superior es también baja,
al 65 % de lo que se esperaba de esta porción de la población general”.
(Detya, 1999, p. 3).
Los factores que contribuyen al éxito o fracaso de los aborígenes en la
universidad incluyen el nivel de apoyo a los estudiantes, las actitudes del
personal, el disfrute de la vida universitaria, estudiar a distancia versus el
modo presencial, la situación familiar, género, finanzas, vivienda, y el grado
de preparación previa de los estudiantes para los estudios universitarios.
(Bourke y Burden, 1996). Por otro lado, diferentes encuestas a estudiantes
aborígenes demostraron “su preocupación y resentimiento por el hecho de
que de acuerdo con las expectativas del sistema universitario estuviera en
peligro su identidad cultural”. (Bourke y Burden, 1996, capítulo 4).
Algunos investigadores identificaron a la educación universitaria en
Australia como fundamentalmente eurocéntrica e integradora. (Anderson,
Singh, Stehbens y Ryerson, 1998; Gale, 1995).
A pesar de estas tendencias, las carreras de grado en Educación, Derecho,
Enfermería, Medicina y Community Management han logrado un éxito
creciente atrayendo estudiantes aborígenes que terminan graduándose desde
el comienzo de los ‘80 en adelante. Esto fue posible mediante el desarrollo
de un conjunto de cursos diseñados específicamente para satisfacer los
requerimientos de los estudiantes aborígenes (incluyendo contenido cultural
adecuado y modelos de entrega), apoyo social y cultural, lugares
“amigables para aborígenes”, y por sobre todas las cosas, la presencia de
personal aborigen en el ámbito académico y los espacios de apoyo.
(Robertson, Dyson, Norman y Buckley, 2002a).
Sin embargo, las disciplinas que no pertenecían a las áreas de prioridad
inmediata para la comunidad aborigen permanecían excluidas de dichos
procesos. La Tecnología de la Información (IT) fue una de ellas. Había muy
pocos profesionales IT de origen indígena que pudieran funcionar como
modelos a seguir. La comunidad aborigen no tenía mucha consciencia de
las opciones de trabajo disponibles en la industria IT y tampoco se incluía
esta disciplina en las charlas de orientación vocacional a los estudiantes
secundarios por parte de sus tutores, maestros y otros líderes de la
comunidad. En general, los tutores no conocían ni entendían los tipos de
trabajos disponibles en la industria o en qué consistía la capacitación de los
profesionales IT. Parecía no haber percepción de la distinción entre
conocimiento de computación y habilidades profesionales de IT que se
requieren para diseñar, construir y mantener los sistemas. Por otro lado, el
éxito de los aborígenes en las áreas tradicionales y de necesidad inmediata
probablemente estaba filtrando a los estudiantes desertores directamente
hacia campos como el derecho, la educación y la enfermería, mientras que
otras opciones no estaban siendo consideradas seriamente (Robertson,
Dyson, Norman y Buckley, 2002b). Como consecuencia de esto, la cantidad
de indígenas inscriptos en los programas educativos de IT permaneció muy
baja.
En octubre de 2001, la Universidad Tecnológica de Sydney (UTS) comenzó
un proyecto de investigación cuyo objetivo era encontrar el modo de
aumentar el nivel de participación de aborígenes en los estudios IT. Las
estadísticas obtenidas en ese momento por el Departamento de Educación,
Ciencia y Capacitación confirmaron que el bajo grado de inscripciones era
consistente en todo Australia, con incluso varias universidades líderes sin
un solo graduado aborigen en el área de IT (Robertson et al., 2002a). La
consecuencia de la baja inscripción en los cursos de IT implicaba que había
muy pocos aborígenes trabajando como profesionales IT. Esto fue así pese a
una creciente toma de conciencia por los aborígenes australianos de los
beneficios que IT podría aportarle a sus comunidades (ATSIC, 2002).
Como consecuencia de nuestra investigación inicial se decidió lanzar un
proyecto de 3 años para aumentar la participación de los estudiantes
aborígenes en los cursos IT. Este fue formulado sobre la base de una
participación activa de los aborígenes, trabajando en colaboración con los
miembros de la Facultad. En ese momento, había dos puntos de conexión
con los enfoques de Diseño Participativo. El primero era que la falta de
participación de los aborígenes australianos en el diseño e implementación
de políticas y procesos que los afectaran directamente era cada vez más
reconocida como una gran fuente de fracasos. La segunda era que, sin
aborígenes profesionales de IT capacitados, su participación en el desarrollo
de Tecnologías de la Información y Comunicación (TICs) estaría limitada a
una participación acordada como usuarios o partes interesadas. No podrían
participar completamente en todos los aspectos del desarrollo de sus propias
tecnologías y sistemas (Robertson, Dyson, Norman y Buckley, 2002b). Se
vería una falta de participación informada de los aborígenes en las
decisiones nacionales respecto de las iniciativas TIC de gran importancia,
tales como la Red Nacional de Banda Ancha y las mejoras en la cobertura
móvil. Continuaría existiendo el bajo nivel de participación indígena en la
toma de decisiones que afectan el acceso e implementación de TIC en las
comunidades aborígenes. Como consecuencia, se mantendría n intactos el
contacto aleatorio y la escasa provisión de TIC en las comunidades,
incluyendo sistemas culturalmente apropiados, apoyo y capacitación.
Este capítulo tiene como objetivo proveer un panorama general del
desarrollo histórico del Proyecto y el modo en el que, gracias a su éxito, fue
evolucionando hasta llegar a ser un programa permanente en la Facultad, el
Programa de Participación Indígena en IT (IPIT por sus siglas en inglés). El
término “Indígena” fue elegido en ese momento para no excluir a los
habitantes de las islas del Estrecho Torres, del norte de Australia1, aunque
por razones prácticas todos nuestros estudiantes de licenciatura y post-grado
han sido aborígenes australianos debido al lugar en que está situada la
Universidad. Además, tiene como propósito mantener al tanto a la
comunidad CDP del estado del desarrollo del Proyecto, presentado por
primera vez en la Conferencia de Diseño Participativo en 2002 (Robertson
et al., 2002b).Como se informó entonces, el proyecto se desarrolló usando
los conceptos del Diseño Participativo para darle forma a sus dos enfoques,
su diseño y su desarrollo en curso. Fue un proyecto destinado al diseño
participativo del acceso y la participación de los aborígenes australianos en
IT.
Desarrollo del proyecto IPIT con la participación

de los aborígenes.
El proyecto estaba centrado en la Facultad de IT pero concebido como una
colaboración entre la Facultad y la gente aborigen. Una colaboración que
operaba en tres niveles principales: la conducción de la investigación
inicial, la implementación de estrategias de reclutamiento y el manejo del
Proyecto.
La Casa de Estudios Indígenas Jumbunna (el centro indígena de apoyo e
investigación para la Universidad) trabajó junto a los miembros de la
Facultad desde el momento inicial de la investigación y durante todo el
proceso, como proveedor de servicios tales como reclutamiento estudiantil,
provisión de cursos básicos de comunicación y matemática y la
organización de instrucción complementaria.
Como parte del proceso inicial de la investigación, la Facultad trabajó con
escuelas y universidades locales con un nivel significativo de inscripciones
aborígenes, y visitó algunas instituciones que tuvieron éxito con la
educación de aborígenes pero en otras disciplinas. Cada uno de los sitios era
visitado por miembros del Proyecto y, a su vez, algunos miembros de las
dichas instituciones visitaban la Facultad.
Se emplearon varias estrategias para aumentar el conocimiento de IT entro
los aborígenes australianos y atraerlos hacia cursos sobre el tema
(Robertson et al., 2002b). Aparte de las visitas a las facultades, se diseñaron
nuevos folletos informativos que se distribuyeron en las ferias de empleo,
se lanzó un sitio web y se desarrolló un curso de preparación terciaria en IT,
el Programa Indígena de Pre-IT, como vehículo de reclutamiento.
Publicidad en el diario Koori Mail (un gran distribuidor de noticias
aborígenes) ayudó a reclutar estudiantes para el curso de preparación y le
dio al programa un perfil nacional. Todas estas actividades se llevaron a
cabo por miembros del personal aborigen y no-aborigen de la facultad
trabajando y tomando decisiones a la par.
Una parte esencial de la estrategia del proyecto fue emplear gente aborigen
de la facultad por primera vez. Se contrató un Project manager aborigen y
se creó un puesto académico. Estos dos miembros del personal jugaron un
papel clave en la gestión del proyecto, tomando las decisiones importantes,
reclutando, ofreciendo a los estudiantes apoyo y desarrollando sus
curriculums. No lo hicieron solos, fueron asistidos por miembros ya
existentes de la Facultad.
La estructura de gestión del proyecto fue crucial para lograr esto. El cuerpo
principal de la dirección era el Grupo de Trabajo del Programa IPIT. Este
grupo realizaba un encuentro mensual para discutir el avance, tomar
decisiones en conjunto y diseñar nuevas estrategias para los demás
objetivos del proyecto. El Grupo de Trabajo consistía de los dos nuevos
miembros aborígenes del personal (El Project Manager y el Académico
Aborigen), integrantes no-aborígenes de la Facultad (tanto académicos
como de apoyo), un aborigen graduado en IT y personal aborigen de otras
unidades de la Universidad. Por ejemplo, un informe interno
correspondiente al período que va entre septiembre de 2002 a mayo del
2003 muestra 7 aborígenes trabajando junto a 15 no-indígenas. Además de
este grupo, había tres subgrupos para: Becas de Financiamiento y Pasantías;
Promoción, Reclutamiento y apoyo; Desarrollo del curso. Y de nuevo,
todos estos subgrupos incluían la participación de miembros indígenas y no
indígenas.
Problemas con el Programa IPIT en los

primeros años
A pesar de la planificación cuidadosa, el trabajo dedicado al Proyecto, y la
estrecha relación laboral que se había dado entre los miembros del staff,
tuvieron que lidiar con importantes problemas. Después de todo, el
Proyecto se estaba dirigiendo hacia un área de estudio no tradicional, y a su
vez a un camino laboral no tradicional para gente aborigen.
Con respecto al reclutamiento de estudiantes aborígenes, la Facultad tuvo
más éxito que con el número de graduados. Las inscripciones habían
aumentado de 2 estudiantes antes del comienzo del Proyecto IPIT a 8 (7
estudiantes y un graduado) en 2005, la fecha del final del proyecto. Sin
embargo, la mayoría de ellos no llegaría a terminar. Para el 2005, la
Facultad había tenido sólo dos graduados aborígenes en IT, uno de los
cuales era anterior al comienzo del Programa. (Dyson y Robertson, 2006).
En esta etapa, la Facultad todavía estaba tratando de encontrar un mejor
modo de reclutar estudiantes y, una vez logrado este objetivo, cómo
apoyarlos a completar sus estudios. Por ejemplo, en el 2005, se adoptó una
política de admisión más relajada, mediante la cual podrían admitirse
estudiantes con pobres antecedentes académicos, y la mayoría de ellos
fracasaron en las primeras etapas de su estadía en la Facultad.
Lo que más éxito tuvo en términos de finalización de los estudios fue le
Programa Indígena de Pre-IT, un curso sin título de preparación terciaria.
El programa indígena de PRE-IT

El Programa Indígena de Pre-IT era un curso full-time de dos semanas,
ofrecido durante 4 años por la Facultad para los Aborígenes Australianos.
Fue el primer curso IT de su tipo en Australia, permitiendo a los estudiantes
aprender los conceptos y herramientas IT de primer año de licenciatura,
mucho más allá del conocimiento básico de informática. (Grant, Hendriks y
Dyson, 2007).
El curso fue el resultado de un trabajo en colaboración de académicos con
una amplia gama de experiencia en IT. Se encontraban semanalmente, y con
el aporte de todos, se creó un programa extraordinario. En el curso los
alumnos adquirían un entendimiento sobre las tecnologías subyacentes y
varias aplicaciones de la Tecnología de la Información en el lugar de trabajo
moderno. Se cubrían algunos temas de programación, Internet, Diseño Web,
reglas básicas de la Informática y Desarrollo de Sistemas de Información.
Todos los estudiantes completaban un proyecto que integraba las
habilidades y el conocimiento de las cinco áreas de estudio. Los dos
principales objetivos del Pre-IT eran:
Promover IT como una opción viable de estudio y plan de carrera para los
aborígenes australianos y funcionar como un programa introductorio para
entrar a los cursos universitarios de IT.
Desarrollar habilidades y conocimiento en IT en la comunidad a través de
estudiantes que fueran capaces de pasar esas habilidades a otros y también
usar el conocimiento IT en su trabajo comunitario.
Hubo un máximo de 16 alumnos matriculados en cada ocasión en que el
programa estuvo en curso, con estudiantes que venían de Sydney, New
South Wales y algunos pocos de comunidades más lejanas como el
Northern Territory, Cape York y las islas del Estrecho Torres. Un gran logro
del Pre-IT fue el número de estudiantes que continuaron sus estudios en el
área: uno está actualmente completando sus estudios part-time de
licenciatura en la UTS mientras cumple con su trabajo como Analista
Comercial, posición que consiguió como resultado de sus estudios IT; cinco
completaron los cursos de Educación Técnica Profesional (TAFE ) 2,
(Diploma en Administración de Sistemas, Certificado III en IT y
Certificado III en Diseño Web); y uno completó la Certificación de
Microsoft de Ingeniería en Sistemas (MCSE) 3. Además, tres estudiantes
fueron inspirados a volver a la universidad para terminar sus últimos años
por su éxito en el curso Pre-IT. Un estudiante ganó la confianza suficiente
del curso Pre-IT para inscribirse y completar su Licenciatura en Educación
(Educación Adulta) en la UTS.
Su testimonio al respecto: Este curso me dio una visión de las diferentes
áreas de IT que no hubieran estado disponibles para mí de otra manera. Me
ha abierto realmente los ojos y me ha alentado a impulsar mi formación. La
universidad no era una opción para mí – o al menos eso era lo que pensaba.
Pero ahora estoy muy interesada en seguir un curso en la universidad
gracias a este maravilloso curso y a la Facultad de IT que nos proporcionó
contenido académico excelente, paciencia y apoyo.
Con respecto a la difusión de las habilidades IT adquiridas en el curso
dentro de sus comunidades de origen, un graduado trabajó en una base de
datos de gestión cultural en el Parque Nacional Uluru-Kata Tjuta,
catalogando y organizando importantes obras de arte aborigen para
colaborar con su preservación y protección. Este graduado ha co-fundado
una compañía que desarrolla sistemas de información para la gestión de la
herencia cultural aborigen. Otros dos estudiantes abrieron juntos un Cyber-
café en su pueblo natal. Algunos otros graduados usaron sus nuevos
conocimientos y habilidades en una variedad de aplicaciones no técnicas.
Algunos ejemplos son dos docentes que aplicaron su conocimiento IT en su
forma de enseñar en la universidad y la Educación Técnica Profesional, un
estudiante utilizó sus habilidades informáticas para colaborar en la
promoción y conducción de campamentos para jóvenes de la comunidad
Gandangara en Sydney, y dos miembros del staff del consejo municipal de
áreas remotas usaron sus herramientas IT en el trabajo administrativo. Otros
estudiantes han expresado una mayor productividad en sus prácticas de
trabajo y una mejor comprensión de la infraestructura IT en sus
comunidades. Como explicaba uno de ellos:
“Para mí, se trataba de enfrentar mis miedos respecto a los temas de IT.
¡Logré esto y mucho más! No puedo hablar mejor de este curso para darle a
los indígenas la oportunidad de ‘probar’ IT”.
Después de cuatro años, el curso Pre-IT dejó de darse. Se creía que había
cumplido su propósito. Para ese momento, la Facultad tenía un flujo
pequeño pero estable de estudiantes inscribiéndose en sus programas de
licenciatura y había decidido concentrar sus esfuerzos en este aspecto del
Proyecto IPIT. Como reconocimiento de la destacable contribución
realizada a la promoción de la igualdad en educación para la gente
aborigen, los académicos que habían participado en el desarrollo y la
realización del curso fueron premiados con el Premio de la UTS a la
Igualdad y Diversidad 2007.
De proyecto a programa
Desde su nacimiento, el Proyecto ha madurado para convertirse en un
programa fijo dentro de la Facultad y está produciendo resultados sólidos y
sostenibles. El Programa tiene en este momento 11 estudiantes inscriptos (7
de licenciatura y 4 de post-grados). Todos los alumnos actualmente
cursando están avanzando correctamente y se espera que completen sus
estudios. Además, la Facultad ha tenido cuatro estudiantes más graduados
del programa de licenciatura, logrando un total de 6 aborígenes graduados
en IT desde el 2002. (Tabla 1). Aunque estos números parezcan bajos, es un
logro excepcional comparado con la mayoría del resto de las universidades
en Australia.
Inscripciones y Finalización de Estudios
de estudiantes aborígenes en los
Programas IT de Grado en la UTS 2000 –
2013
Año Grado Post total Grado Post total
2000 1 0 1 0 0 0
2001 2 0 2 1 0 1
2002 3 1 4 0 0 0
2003 3 2 5 0 0 0
2004 3 1 4 1 0 1
2005 7 1 8 0 0 0
2006 4 1 5 0 0 0
2007 4 1 5 0 0 0
2008 4 0 4 0 0 0
2009 4 0 4 1 0 1
2010 5 1 6 1 0 1
Año Grado Post total Grado Post total
2011 7 8 1 1 0 1
2012 7 2 9 1 0 1
2013* 7 4 11 - - -
Total Finalización de Estudios: 6 0 6
Inscripciones incluye tanto a los nuevos inscriptos como a estudiantes en
curso; cada estudiante se cuenta como un nuevo inscripto cada año que
cursa el programa.
* Las inscripciones y finalizaciones de estudios del 2013 están hasta ahora
incompletas.
De las cifras de la Tabla 1, se desprenden algunas tendencias:
Aparte de la política de admisión relajada probada en 2005, ha habido

un crecimiento estable en el número de estudiantes aborígenes
inscriptos en nuestros programas de licenciatura.
Desde el 2009, se ha registrado un nivel estable de éxito en las
finalizaciones de curso en los estudiantes aborígenes (una por año).
Dado el aumento de las inscripciones y las mejoras en los espacios de
apoyo ahora implementados, esperamos que esta cifra vaya creciendo
pronto.
El Programa IPIT ha empezado a atraer a estudiantes de post-grado
pero hasta ahora ha fallado en lograr que terminen sus estudios, ya sea
de nuestros programas de investigación como de nuestros cursos
presenciales de post-grado. Sin embargo, esta situación podrá mejorar
en el 2013 con un estudiante que viene progresando muy bien en el
curso de certificación para Project Manager.
Algunos rasgos significativos del diseño del Programa para tener en cuenta:
Los procedimientos estándar de reclutamiento de estudiantes fueron

rediseñados específicamente para IT por el subgrupo que trabaja con el
Desarrollo del Curso, un trabajo en colaboración de académicos
aborígenes y no-aborígenes.
El apoyo a los estudiantes, antes provisto únicamente por el centro
indígena de apoyo de la Universidad (Jumbunna) fue reformado para
que fuera ofrecido por un trabajo conjunto entre académicos
aborígenes y no-aborígenes de la Facultad de IT y los miembros del
staff del Jumbunna. Se enfatizó especialmente en la asistencia
personalizada.
Dentro de la Facultad se “naturalizó” la presencia del Programa IPIT y
esto se evidencia por el hecho de que el Programa ya no necesita un
Project Manager, el académico aborigen ha sido promovido a Profesor
y está involucrado en la enseñanza de los cursos principales de IT y se
ha contratado por primera vez a un administrativo aborigen para cubrir
un puesto no designado especialmente para programas aborígenes.
Los siguientes testimonios nos permiten conocer el Programa IPIT desde el

punto de vista de los participantes:
Stephen Grant, Profesor
“En el 2002 comencé a trabajar en el Proyecto IPIT como profesor en la
Facultad de Tecnología de la Información. Trabajé en el Proyecto junto a
los Project Managers, que me dieron la oportunidad de crecer, me alentaron
y me mostraron que valía la pena seguir una carrera en el área de IT. El
proyecto me permitió explicarle a la gente aborigen que IT es mucho más
que estar sentado en frente a la pantalla de una computadora escribiendo
código. Pude enseñarles que incluye áreas como arte digital, medios
interactivos, desarrollo de sitios web, entre otras. La Facultad de IT me dio
la oportunidad de trabajar como docente, lo que me posibilitó emprender el
desafío de compartir mis conocimientos y habilidades IT a los estudiantes.
La docencia me incita a seguir aprendiendo sobre herramientas de
enseñanza y aprendizaje en Educación Superior. El Programa IPIT fue una
movida audaz de la Facultad para involucrarse en la promoción y el
desarrollo de la idea de IT como una carrera, un entrenamiento y educación
para la gente aborigen.”
El primer graduado aborigen en IT
Muchos en nuestra comunidad no ven ni comprenden a la Tecnología de la
Información como una opción, pero sé que hay un montón de potencial sin
explotar allí afuera. El curso me enseñó que debemos intentarlo. IT ofrece
un mundo enorme de oportunidades”.
Estudiante Aborigen de Primer Año de Licenciatura
“LA UTS se ubica en el corazón de la ciudad, a pocos minutos caminando
del puerto y el centro para un lado y de los alborotados y bohemios
suburbios para el otro. Su fantástica estructura de clases abiertas que
perfectamente se ajustaron a mi necesidad de una experiencia de
aprendizaje diversa, y su promesa de un ambiente multicultural lleno de
gente de diferentes orígenes y perspectivas sobre la vida, todo esto
combinado hizo de esta universidad mi primera y única elección. Es una
maravillosa sensación saber que encajas entre esta increíble diversidad, sin
importar de dónde vienes.”
Colaboración con la comunidad aborigen local

Como su antecesor el Programa Indígena Pre-IT, que ha tenido muchos
efectos en la comunidad, el Programa IPIT continúa extendiéndose más allá
de la universidad para trabajar con las comunidades locales, ofreciendo
capacitación profesional en IT a los Aborígenes Australianos. La Facultad,
en colaboración con la Cisco Networking Academy y el National Centre of
Indigenous Excellence (NCIE) establecieron un programa en el 2012 en los
suburbios marginales de Redfern, que muchos consideran el centro de la
Sydney Aborigen, por su histórica cantidad de habitantes indígenas, grupos
comunitarios y servicios. Dos días a la semana durante diez semanas
Stephen Grant enseñó IT Básica a un grupo de estudiantes aborígenes. El
curso estaba insertado en una estrategia con orientación al trabajo que
incluía herramientas para la búsqueda laboral, escritura de CV, manejo de
entrevistas de trabajo, etc. La consultora de trabajo que daba la capacitación
laboral luego encontró posibles empleadores para los participantes y al
menos dos de ellos se encuentran trabajando full-time como profesionales
IT.
Este programa se extendió en el 2013 al Centro Eora, una escuela técnica
(TAFE) que se especializa en educación para aborígenes. El objetivo era
“capacitar al capacitador”, es decir, ofrecer entrenamiento en IT a los
profesores calificados como Instructores en la Cisco Academy. El curso
también tuvo lugar en el Complejo NCIE y dos instructores lo terminaron
con éxito. El objetivo de este programa es ofrecer a los aborígenes la
capacidad de ofrecer programas profesionales de IT a su gente, sin tener
que recurrir a nadie de afuera. Estas colaboraciones demuestran la
capacidad de compartir acciones comunes para lograr resultados concretos.
Conclusiones
El Programa IPIT nunca tuvo la intención de ser un “Proyecto Grande”.
Uno de sus propósitos era hacer posible un cambio en el modo de percibir
la Tecnología de la Información, su accesibilidad y utilidad a la comunidad
aborigen. Otro era lograr un cambio en las prácticas de IT en la Facultad de
la UTS para asegurarse de que a los estudiantes aborígenes se les ofrecería
un ambiente comprensivo y acogedor para seguir sus estudios. Estamos
llegando a eso. Una de nuestras primeras metas era que tuviéramos que
necesitar “dos manos” para contar la cantidad de estudiantes aborígenes
inscriptos en nuestros cursos, y en el 2013 superamos ese objetivo por
primera vez. Esperamos que pronto necesitemos dos manos para contar el
número de graduados. Sigue siendo nuestro objetivo a largo plazo que no
resulte especial que los estudiantes aborígenes estén estudiando IT y
participando por su cuenta en todos los aspectos del diseño, desarrollo,
implementación y uso de IT.
Mientras la iniciativa IPIT estuvo viva, los desarrollos con TICs se han
hecho más accesibles para la gente aborigen y más flexibles en sus usos. Se
ha producido un fuerte crecimiento de las empresas digitales dirigidas por
aborígenes en el transcurso de esos años, generando espacios en los que las
habilidades IT son necesitadas, respetadas, incluyendo puestos de trabajo
con algunas de las más remotas comunidades. Estos desarrollos han
ayudado enormemente al crecimiento del programa, en particular en el
cambio de percepción de los aborígenes sobre el papel que podrían cumplir
las TIC en sus vidas. Esto hizo que el reclutamiento de gente aborigen que
quisiera participar en el programa fuera más fácil. Hasta donde sabemos, la
situación respecto de las inscripciones y finalización de estudios de
estudiantes aborígenes de IT es extraordinaria en comparación con la
mayoría de las demás universidades. Creemos que el Programa IPIT y su
enfoque participativo y colaborativo ha contribuido significativamente ha
dicho resultado.
Referencias
1. N. del T: “aborigen” es un término que remite al nombre de la comunidad
indígena principal de Australia. “Indígena” es un término apropiado para
incluir a todas las comunidades de los pueblos originarios.
2. [N. del T.] Por las siglas en ingles, Technical and Further Education .
3. [N. del T.] Por las siglas en inglés, Microsoft Systems Engineer
Certification.
Agradecimientos
Los autores agradecen sinceramente a los estudiantes que brindaron los
testimonios incluidos en el artículo y que han contribuido tanto a la vida de
la Facultad mediante su participación en nuestros programas educativos.
También agradecemos la participación de los miembros aborígenes del staff
con quienes trabajamos durante estos años y sin los cuales no se habría
obtenido el éxito reportado. Finalmente agradecemos a los Gadigal, de la
Nación Eora, en cuyo territorio se sitúa nuestra Facultad.
Bibliografía
Anderson, L., Singh, M., Stehbens, C. and Ryerson, L. Equity Issues:
Every University’s Concern, Whose Business? An Exploration of
Universities’ Inclusion of Indigenous Peoples’ Rights and Interests,
Department of Employment, Education, Training and Youth Affairs
Canberra, June 1998.
ATSIC (Aboriginal and Torres Islander Commission). New Solutions
to Old Problems: Remote Indigenous Communications as Community
Economic Development, Commonwealth of Australia: Canberra, 2002.
Bourke, C. J. and Burden, J. K. with Moore, S. Factors Affecting
Performance of Aboriginal and Torres Strait Islander Students at
Australian Universities: A Case Study for DETYA, Department of
Education, Training and Youth Affairs, Canberra, Australia, 1996.
DETYA (Department of Education, Training and Youth Affairs).
Equity in Higher Education. Canberra, 1999.
Dyson, L. E. and Robertson, T. Indigenous Participation in Information
Technology Project: Achievements and Challenges of the First Three
Years, The Australian Journal of Indigenous Education, Vol. 35, pp.
11-20, 2006.
Gale, P. “A Fair Chance for All? Indigenous Rights and Tertiary
Education in Australia”. Prospects, Vol. 25, No. 4, pp. 609-621, 1995.
Grant, S., Hendriks, M. and Dyson, L. E. “The Indigenous Pre-IT
Program”, in L.E. Dyson, M. Hendriks, & S. Grant (eds.), Information
Technology and Indigenous People (pp. 126-131), Information Science
Publishing, Hershey, USA, 2007.
Robertson, T., Dyson, L. E., Norman, H. and Buckley, B. Increasing
the Participation of Indigenous Australians in the Information
Technology Industry, Technical Report 2002.2, Faculty of Information
Technology, Technical Report Series. University of Technology
Sydney 2002a.
Robertson, T., Dyson, L., Norman, H. and Buckley, B. ‘Increasing the
Participation of Indigenous Australians in the Information Technology
Industries’, PDC ‘02, Malmö, 23-25 June, pp. 288-294, 2002b.
Capítulo 7: Introducción a la Interacción Persona-Computadora, por
Yusef Hassan Montero
Trabaja en el sector de la experiencia de usuario y la visualización de
información desde hace 10 años, primero como investigador en la
Universidad de Granada, donde obtuvo el título de Doctor en
Documentación, y actualmente como consultor y diseñador de interacción,
colaborando con Scimago Lab. Actualmente compagina su labor de
consultoría con la docencia en posgrados de experiencia de usuario, en
instituciones como la Universitat Oberta de Catalunya, Universitat Pompeu
Fabra, Universidad de Murcia o el Instituto Superior de Ciências da
Informação e da Administração, entre otras. Es fundador de la revista No
Solo Usabilidad (nosolousabilidad.com), coautor del Informe APEI sobre
Usabilidad y miembro de la organización de UX Spain (uxspain.com).
Más información:
Twitter: @yusef
Mini biografía de Sergio Ortega Santamaría

Es Diplomado en Educación Social, Licenciado en Comunicación
Audiovisual, Doctor en Psicopedagogía, y profesor e investigador en el
Instituto Superior de Ciências da Informação e da Administração (ISCIA)
de Aveiro, Portugal. Ha trabajado como profesor e investigador en la
Facultad de Comunicación de la Universidad Pontificia de Salamanca,
formando parte del Laboratorio de Comunicación Multimedia de esta
Facultad y participando en proyectos relacionados con las tecnologías de la
información y la comunicación. Desarrolla propuestas de comunicación
digital interactiva, diseño y usabilidad web e innovación tecnológica en
comunicación. Es autor del libro Multimedia, hipermedia y
aprendizaje.Construcción de espacios interactivos, coautor del Informe
APEI sobre Usabilidad, y miembro del consejo asesor de No Solo
Usabilidad Journal.
Más información:
Twitter: @sortega
Introducción a la Interacción Persona-
Computadora 1
En el presente capítulo se introducen y describen brevemente algunos de los
conceptos y aspectos más relevantes -desde la perspectiva de los autores-
del estudio de la interacción entre personas y computadoras. Más allá del
propio contenido y explicaciones, consideramos que la verdadera utilidad
de este trabajo para nuevos profesionales e investigadores en el área reside
en la selección bibliográfica ofrecida, que incluye algunos de los trabajos
académicos más significativos, a través de los que el lector podrá ampliar y
profundizar su conocimiento sobre la disciplina.
1. Introducción
Conforme la tecnología ha ido invadiendo progresivamente todos los
aspectos de nuestras vidas, se ha hecho cada vez más evidente la
importancia crucial que tiene estudiar la forma en la que se relacionan las
personas y los productos tecnológicos, y cómo el diseño media en esta
relación. De esta importancia toma conciencia la comunidad académica de
forma temprana, dando origen a una nueva área de estudio multidisciplinar,
que recibe el nombre de Human-Computer Interaction o Interacción
Persona-Computadora. Tal y como la definen Myers, Hollan y Cruz (1996),
la Interacción Persona-Computadora es el estudio de cómo las personas
diseñan, implementan y usan sistemas informáticos interactivos; y de cómo
las computadoras influyen en las personas, las organizaciones y la sociedad.
Aunque la incubación de la disciplina se produce años atrás (Licklider;
1960), podemos considera 1969 una fecha clave, ya que se celebra el primer
encuentro internacional y se publica la primera revista especializada
(Sackel; 1997). Podemos decir que la disciplina surge de la inevitable
confluencia de dos disciplinas asentadas, la informática y la ergonomía.
Esta última, también conocida como “Factores Humanos” en EE.UU., es la
disciplina que tradicionalmente ha estudiado la relación interactiva entre las
personas, artefactos y entornos de trabajo, con especial atención a los
factores humanos psicológicos, sociales y físicos que condicionan esta
interacción.
No es hasta los años noventa cuando se produce una tangible
profesionalización de la disciplina, conocida como Ingeniería de la
Usabilidad (Usability Engineering) (Nielsen; 1994). A diferencia de la
disciplina académica, la Ingeniería de la Usabilidad presta mucha menos
atención a la investigación básica o al método científico, adoptando un
enfoque más pragmático, orientado al retorno de inversión, la obtención de
resultados y la relación coste-beneficio de los métodos de diseño y
evaluación (Dumas; 2007).
Mientras que la Ingeniería de la Usabilidad nace de un entorno profesional
y empresarial fundamentalmente tecnológico, de forma paralela, pero esta
vez en el seno de empresas y firmas de diseño como IDEO, otra vertiente
profesional, conocida como Diseño de Interacción, da sus primeros pasos
(Saffer; 2010). Aunque con raíces y enfoques diferentes, el paso de los años
ha diluido las fronteras entre Ingeniería de la Usabilidad y Diseño de
Interacción, e incluso hay autores como Kaptelinin y Nardi (2006) que
creen conveniente sustituir directamente la denominación académica de
Interacción Persona-Computadora por la de Diseño de Interacción.
De forma más reciente, y con una clara influencia del área del Marketing,
hacen aparición los conceptos de Experiencia de Usuario y Diseño de
Experiencias de Usuario, como un intento de superar las limitaciones de las
disciplinas académicas y profesionales tradicionales, afrontando la relación
entre personas y tecnología desde una perspectiva aún más global, inclusiva
e interdisciplinaria (Hassan-Montero; Martín-Fernández; 2005) (Hassan-
Montero; Ortega-Santamaría; 2009).
Al margen de la evolución que han sufrido las diferentes vertientes
académicas y profesionales, creemos que resulta imprescindible, tanto para
nuevos investigadores como profesionales, conocer los conceptos centrales
que fundamentan el estudio de la Interacción Persona-Computadora. En el
presente capítulo se abordarán tres de los aspectos clave: Interacción, Factor
Humano y Tecnología de la interacción.
2. Interacción
El objeto central de estudio de la Interacción Persona-Computadora es,
como su propio nombre indica, la interacción. Este intercambio de
información a veces es denominado “diálogo”, pero la realidad es que se
trata de una denominación poco acertada, ya que la comunicación entre
persona y computadora poco tiene que ver con la comunicación
interpersonal. Las personas comparten entre sí conocimientos y
experiencias muy alejadas de las capacidades de los computadoras, y su
comunicación es por tanto mucho más compleja. Como explica Norman
(2007), en todo caso podríamos hablar de dos monólogos, en los que a
veces el sistema debe obedecer nuestras órdenes, y en otras ocasiones
nosotros debemos obedecer las suyas.
Siguiendo el modelo propuesto por Norman (1988) podemos considerar la
interacción como un proceso iterativo y cíclico, divisible en 3 etapas
principales. En la primera etapa el usuario formularía su objetivo,
decidiendo qué quiere lograr. La segunda etapa sería de ejecución; el
usuario hace explícita su intención, especificando y ejecutando la acción.
Por último la etapa de evaluación, en la que el usuario compara qué ha
ocurrido con qué esperaba que ocurriera tras su acción, evaluando e
interpretando el estado del sistema.
Lo interesante de este modelo es que nos permite identificar los problemas
de uso de un sistema, que básicamente pueden ser de dos tipos: brecha en la
ejecución y brecha en la evaluación. La brecha en la ejecución se produce
cuando no somos capaces de relacionar qué pretendemos lograr y cómo
llevar a cabo la acción con las opciones que nos ofrece el sistema. La
brecha en la evaluación, en cambio, se produce cuando no somos capaces
de interpretar la respuesta del sistema ante nuestra acción, o cuando esta
respuesta no se corresponde con la que esperábamos.
Un concepto íntimamente relacionado con la interacción es el conocido
como estilos de interacción, es decir, los diferentes modos o formas en las
que el usuario puede interactuar con el sistema (Preece et al.; 1994)
(Shneiderman; 1997).
El estilo de interacción con más historia es el conocido como de línea de
comandos. En este modo de interactuar el usuario introduce instrucciones o
comandos a través de un prompt, y el sistema ejecuta esas instrucciones o,
en caso contrario, devuelve un mensaje de error. Este estilo de interacción
requiere que el usuario posea un conocimiento previo acerca de qué
instrucciones son posibles y qué resultado provocará cada una. Es un estilo
de interacción, por tanto, problemático para usuarios no expertos (brecha de
ejecución), pero por otro lado resulta muy eficiente para usuarios expertos,
lo que explica por qué aún podemos encontrar numerosos sistemas basados
en líneas de comandos.
Otro estilo de interacción, presente en la inmensa mayoría de dispositivos
que utilizamos cotidianamente, es el basado en menús de selección o
navegación. En este caso el sistema ofrece una serie de opciones posibles al
usuario, y éste solo tiene que elegir la que mejor responda a sus objetivos o
necesidades. Se trata de un estilo de interacción mucho más sencillo para
usuarios no expertos, ya que no exige un conocimiento sintáctico previo.
Aún así es un estilo que puede resultar complejo de usar cuando las
opciones que se presentan son de difícil interpretación para el usuario.
Los formularios representan otro estilo de interacción ampliamente
extendido. Por analogía a los formularios clásicos en papel, el sistema
presenta una serie de campos que el usuario debe completar. Entre los
campos del formulario algunos pueden utilizar un modelo de menú de
selección, como las listas desplegables.
Otro estilo de interacción es el conocido como diálogo en lenguaje natural,
un modo de interactuar en el que los usuarios dan instrucciones, escritas o
habladas, utilizando el lenguaje natural, es decir, sin someterse a reglas y
vocabularios rígidos y predefinidos. Aunque es un estilo de interacción
sobre el que se lleva muchos años investigando, sus aplicaciones prácticas
aún son limitadas. Algunas aproximaciones, a modo de ejemplo, son los
buscadores de Internet o los asistentes personales como Siri (Apple).
Por último no podemos olvidar el estilo de interacción predominante en la
mayoría de sistemas operativos; el conocido como manipulación directa. Se
trata de un modo de interacción que permite al usuario manipular y
controlar físicamente los elementos presentes en la interfaz, incluyendo la
posibilidad de seleccionar, arrastrar o mover objetos, así como la de
deshacer las acciones realizadas. Con la reciente proliferación de los
dispositivos táctiles, esta manipulación podemos decir que se ha vuelto aún
más directa, ya que no está mediada por dispositivos apuntadores como el
ratón.
3. El factor humano
El estudio de la Interacción Persona-Computadora nos exige comprender el
funcionamiento y comportamiento de los diferentes elementos que
intervienen en la interacción: tecnología y factor humano, pero
particularmente este último, el más complejo y enigmático de todos.
Para ello la disciplina se nutre de una gran variedad de teorías y evidencias
empíricas tomadas de diferentes disciplinas, como sociología, psicología,
antropología, etc. De entre todas, sin ninguna duda, el corpus teórico que
más peso ha tenido en el desarrollo de la Interacción Persona-Computadora
hasta la fecha ha sido la psicología cognitiva, en especial el modelo de
Procesamiento Humano de Información (Broadbent; 1958) (Card, Moran,
Newell; 1983) y todas las micro-teorías a las que da cabida.
El Sistema de Procesamiento Humano de Información caracteriza a las
personas como procesadores activos de información, utilizando la metáfora
computacional. Es decir, el procesamiento de información en las personas
se concibe por analogía a como éste se produce en los computadoras. Los
humanos adquieren información a través de la percepción, poseen un
procesador central que se encarga de razonar y tomar decisiones, almacenan
información (memoria), y la materializan a través de acciones motoras.
Aunque por razones obvias la explicación detallada de este modelo y sus
teorías relacionadas superan los objetivos del presente trabajo, sí creemos
necesario introducir algunos de sus aspectos clave, y su repercusión en el
estudio y práctica de la interacción entre personas y computadoras.
Por un lado debemos destacar que la atención de los humanos es selectiva.
Esto quiere decir que concentramos nuestro entendimiento en una parte de
la realidad, mientras desatendemos el resto. Como indica Cowan (1988), la
atención selectiva requiere que ciertos análisis perceptuales tengan lugar de
forma automática, en forma de habituación a los estímulos desatendidos. Es
decir, no es que desconectemos canales sensoriales o rechacemos
completamente los estímulos desatendidos, sino que nos habituamos a ellos.
Sólo cuando se produce un cambio de gran significación en estos estímulos
desatendidos, superan la barrera de la habituación y se ubican en el foco de
nuestra atención. Desde la perspectiva del estudio de la Interacción
Persona-Computadora la naturaleza selectiva de la atención humana sugiere
que un producto interactivo fácil de usar será aquel que no sature ni
interrumpa innecesariamente nuestra atención.
Por otro lado, gracias a la investigación en psicología cognitiva, sabemos
que si bien la capacidad de nuestra memoria a largo plazo no tiene límite
(conocido), nuestra memoria operativa – aquella que utilizamos para
almacenar temporalmente información para el razonamiento y la toma de
decisiones conscientes – sí tiene una capacidad muy limitada (Miller; 1956)
(Cowan; 2001). Esto implica que cualquier tarea interactiva que requiera
retener en la memoria operativa al mismo tiempo un número excesivo de
datos, resultará muy compleja de ejecutar para el usuario.
La forma en la que las personas procesamos información y tomamos
decisiones resulta también de una importancia vital en el estudio de la
interacción. Como describe Kahneman (2003), podemos diferenciar entre
dos modos genéricos de función cognitiva: razonamiento e intuición.
Nuestro sistema racional es el que nos permite tomar decisiones meditadas;
una forma de procesar información lenta, basada en reglas lógicas y que
requiere esfuerzo. Por otro lado, el sistema intuitivo es rápido, automático,
eficiente, emocional, asociativo y se alimenta de la experiencia. Si
consideramos que la mayor parte de nuestro comportamiento diario lo rige
nuestra intuición, este hecho implica que el diseño de productos interactivos
usables será aquel que, parafraseando el título del famoso libro de Steve
Krug, no nos haga pensar. Un diseño que permita un uso eficiente e
intuitivo, y que prevenga que el usuario cometa errores, producto de esta
forma automática y no meditada de tomar decisiones durante la interacción.
Por último, y no menos importante, un producto interactivo no sólo debe
adaptarse a nuestras limitaciones y capacidades cognitivas, también debe
hacerlo a nuestras limitaciones motrices. En este sentido, seguramente la
norma más importante es la conocida como ley de Fitts (Fitts; 1954) (Fitts,
Peterson; 1964), que señala que la dificultad para alcanzar un objeto está
directamente relacionada con el tamaño del mismo y su distancia respecto
al punto de partida. Como se puede deducir, es una ley con evidentes
implicaciones en el diseño de interfaces de usuario.
4. Tecnología de la interacción
La interfaz de usuario es el elemento y lugar de contacto entre usuario y
computadora, englobando todos aquellos componentes, tanto software
como hardware, destinados a posibilitar el intercambio de información entre
persona y computadora.
El desarrollo de la disciplina ha transcurrido de forma paralela a la
evolución de las tecnologías que conforman estas interfaces. La aparición
de las interfaces gráficas de usuario y del modelo WIMP (Window, Icon,
Menu, Pointing device), así como de nuevos dispositivos y formas de
interacción, ha modificado y ampliado las posibilidades y modos en los que
se han relacionado personas y computadoras durante todos estos años. Al
mismo tiempo, la investigación académica en la disciplina, ha propiciado y
anticipado el propio desarrollo comercial de estas tecnologías.
Entre los dispositivos que forman parte de la interfaz de usuario se suele
distinguir entre dispositivos de entrada y de salida, en función de si están
destinados a la transmisión de información del usuario hacia el
computadora o viceversa, si bien existen también dispositivos que cumplen
al mismo tiempo ambas funciones. Entre los avances más destacados en
interfaces de salida podemos señalar el incesante aumento de la resolución
y calidad de imagen de las pantallas, su cada vez menor grosor, o la
irrupción en el mercado de la tecnología 3D. Por otro lado, los dispositivos
de entrada tradicionales, como el teclado o el ratón, se ven desplazados en
más contextos a favor de nuevas interfaces gestuales (Saffer; 2008), como
las pantallas multi-táctiles, el uso de acelerómetros en mandos de
videoconsolas y dispositivos móviles para detectar su movimiento, o el uso
combinado de cámaras y sensores de profundidad para identificar gestos del
usuario sin necesidad de contacto físico alguno. A estos dispositivos hay
que añadir los avances de interfaces no gestuales como las basadas en
reconocimiento de voz o en el seguimiento de la mirada (eye-tracking).
Todos estos avances expanden las posibilidades de interacción y facilitan el
uso. Por ejemplo, las interfaces táctiles requieren menos esfuerzo de
aprendizaje que aquellas basadas en dispositivos apuntadores como el
mouse. Mientras que aprender a usar un mouse exige vincular mentalmente
lo que hacemos sobre una superficie y lo que ocurre en otra (pantalla), las
interfaces táctiles ofrecen un modo de interactuar más directo e intuitivo.
No obstante tampoco debemos obviar que, como advierten Norman (2010),
Norman y Nielsen (2010), el uso de las interfaces gestuales no es tan
“natural” como puede parecer, y que descuidar principios fundamentales de
interacción puede provocar problemas de usabilidad.
Referencias
1. Pensando en los lectores latinoamericanos, con anuencia de los autores,
hemos suplantado: computadora por ordenador y ratón por mouse.
Bibliografía
Broadbent, D.E., Perception and communication, Londres, Pergamon
Press, 1958, p. 338.
Card, S.K., Moran, T., Newell, A., The psychology of human-
computer interaction, Hillsdale, NJ: Erlbaum, 1983.
Cowan, N., “Evolving Conceptions of Memory Storage, Selective
Attention, and Their Mutual Constraints Within The Human
Information-Processing System”, en: Psychological Bulletin, vol.104,
n. 2, pp. 163-191, 1988.
Cowan, N., “The magical number 4 in short-term memory: A
reconsideration of mental storage capacity”, en: Behavioral and Brain
Sciences, n° 24, pp. 87-114, Cambridge University Press.
Dumas, J., “The great leap forward: The birth of the usability
profession (1988-1993)”, En: Journal of Usability Studies, 2 (2),
febrero, 2007, pp. 54-60.
Fitts, P.M., “The information capacity of the human motor system in
controlling the amplitude of movement”, en: Journal of Experimental
Psychology, vol. 47, n° 6, pp. 381-391, 1954.
Fitts, P.M., Peterson, J.R., “Information capacity of discrete motor
responses”, en: Journal of Experimental Psychology, vol. 67, n° 2,
pp.103-112, 1964.
Hassan-Montero, Y., Martín-Fernández, F.J., “La Experiencia del
Usuario”, en: No Solo Usabilidad, nº4, 2005. Disponible en: [Ver en
línea] .
Hassan-Montero, Y., Ortega-Santamaría, S., Informe APEI de
usabilidad, Gijón, Asociación Profesional de Especialistas en
Información, 2009. Disponible en: nosolousabilidad.com
Kahneman, D., “A Perspective on Judgment and Choice”, American
Psychologist, Vol. 58, n° 9, pp. 697-720, 2003.
Kaptelinin, V., Nardi, B.A., Acting with technology: activity theory
and interaction design, Cambridge, MA, MIT Press, 2006.
Licklider, J.C.R., Man-Computer Symbiosis. IRE Transactions on
Human Factors in Electronics, vol. HFE-1, pp 4-11, marzo, 1960.
Miller, G. A. “The magical number seven, plus or minus two: Some
limits on our capacity for processing information” Psychological
Review 63 (2), pp. 81-97, 1956.
Myers, B.A., Hollan, J., Cruz, I. (Eds.), “Strategic Directions in
Human Computer Interaction”, en: ACM Computing Surveys, Vol. 28,
n. 4, diciembre, 1996.
Nielsen, J., Usability Engineering, Morgan Kaufmann, San Francisco,
1994.
Norman, D.A., The Psychology of Everyday Things, Basic Books,
1988.
Norman, D. A., “Cautious Cars and Cantankerous Kitchens: How
Machines Take Control”, en: The Design of Future Things, New York,
Basic Books, 2007.
Norman, D.A., “Natural user interfaces are not natural”, en:
Interactions, Vol. 17, Issue 3, pp. 6-10, 2010.
Norman, D.A., Nielsen, J., “Gestural interfaces: a step backward in
usability”, en: Interactions, Vol. 17, Issue 5, pp. 46-49, 2010.
Preece, J. J., Rogers, Y., Sharp, H., Benyon, D., Human-Computer
Interaction, Essex, UK, Addison Wesley Publishing, 1994.
Sackel, B. (1997). Human-Computer Interaction-Whence and
whither?, Journal of the American Society for Information Science, 48
(11), pp. 970-986, 1997.
Saffer, D., Designing Gestural Interfaces, O’Reilly Media, Inc., 2008.
Saffer, D., Designing for Interaction: Creating Innovative Applications
and Devices, 2ª Edición, New Riders, Berkeley, 2010.
Shneiderman, B,Designing the user interface, Addison-Wesley
Publishing Company, 1997.
Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango
Es un arquitecto de información con más de 18 años de experiencia en el
diseño y producción de experiencias digitales. En su formación académica
obtuvo un BA Arquitectura en la University of Arkansas, EE.UU. Es
fundador y director de BootStudio, una de las primeras agencias de diseño
de experiencias de usuario en América Central. Ha escrito, presentado, y
organizado conferencias sobre temas relacionados al diseño de experiencias
de usuario en varios países. Ha sido Presidente y Director del Instituto para
la Arquitectura de la Información y jefe de redacción de la revista Boxes
and Arrows.
Más información:
Twitter: @jarango
Entre la Arquitectura y la Información

Introducción
La popularización de Internet ha causado cambios importantes en la forma
en que los seres humanos accedemos a la información y cómo nos
relacionamos los unos con los otros. Actualmente tenemos acceso a mayor
información que nunca antes. Aunque esto es sin duda positivo, esta
explosión informática también trae un reto considerable: mientras más
información tenemos, más difícil se hace encontrar y entender lo que
estamos buscando. Como resultado, los diseñadores digitales tenemos un
compromiso ético de lograr que la información sea fácil de encontrar y
entender. La arquitectura de la información es el área de práctica que está
enfocada en lograr que la información sea fácil de encontrar y de entender.
La “arquitectura” en esta frase es más que una metáfora: existe evidencia
que las personas experimentan los artefactos que diseñamos como “espacios
informáticos”, análogos digitales a los espacios físicos que habitamos. La
arquitectura ofrece lecciones valiosas que pueden ayudar a que estos
espacios informáticos satisfagan mejor las necesidades de los seres
humanos que los usan.
Un nuevo tipo de entorno
Actualmente contamos con mejor acceso a más información que nunca
antes. La revolución digital ha tocado todos los rincones del planeta,
trayendo con sí la promesa de más formación y entendimiento entre las
personas. Sin embargo, el incremento en la cantidad de información
también trae con sí el potencial de confusión: mientras más información
hay, más difícil se hace encontrar y entender lo que uno está buscando.
Ventajas de la proliferación de espacios

informáticos
De acuerdo al CIA World Factbook, en el 2010 más de dos mil millones de
personas tenían acceso a Internet. Ese segmento de la población del planeta
goza de la colección de contenido más grande que ha existido, y que crece a
un paso vertiginoso: cada minuto enviamos 204 millones de mensajes por
correo electrónico, publicamos 3,000 imágenes nuevas en Flickr, escribimos
6 artículos nuevos en Wikipedia, y subimos 30 horas de video a YouTube 1.
Esta información representa una oportunidad sin precedentes para que las
personas de todo nivel social y ubicación geográfica puedan aprender y
compartir. Entre 1970 y el 2005, la tasa global de analfabetismo se redujo a
la mitad 2; actualmente casi 89% de las personas mayores de 15 años
pueden leer y escribir 3. Los medios digitales, en especial el Internet, hacen
que sea factible llevar más información a lugares remotos. Aunque todavía
existe una brecha digital entre el nivel de acceso per capita que gozan los
países desarrollados versus aquellos en vías de desarrollo, desde el 2003 las
Naciones Unidas cuenta con un plan para ayudar a cerrar la brecha 4. El
progreso ha sido lento, pero definitivo.
Esta información no se publica de forma centralizada, como sucede en los
medios tradicionales. Todos los usuarios de Internet tienen a su disposición
mecanismos baratos (y hasta gratuitos) para expresar sus opiniones y
publicar sus ideas. Con la proliferación de “teléfonos inteligentes” como el
iPhone o los dispositivos Android, más de mil millones de personas 5 tienen
en sus bolsillos computadoras extremadamente poderosas que les permiten
acceder a Internet y publicar contenido de forma inmediata utilizando un
conjunto sin precedentes de sensores y dispositivos de captura: cámaras de
fotografía y vídeo, micrófonos, giroscopios, geo-localización global (GPS),
etc. El resultado inevitable es un cambio en el equilibrio de fuerzas entre las
instituciones, los gobiernos, y los seres humanos que interactuamos con
ellos.
La proliferación de los espacios informáticos también está cambiando la
gobernación de los países. La disponibilidad de canales digitales como
Twitter y Facebook ha sido uno de los causantes de la onda de revoluciones
que ha tumbado varios gobiernos totalitarios en el Medio Oriente 6. En las
democracias, proyectos como data.gov.uk —un portal del gobierno del
Reino Unido que hace asequible la información del estado— están
cambiando la relación entre gobernantes y gobernados, con la promesa de
incrementar la transparencia en los quehaceres públicos.
La aguja en el pajar
El principal reto que trae con sí la explosión informática es que al tener
tanta información disponible, se hace muy difícil encontrar exactamente lo
que uno está buscando. Una búsqueda sencilla en Google genera cientos de
miles (y en algunos casos, millones) de resultados. Además, no todas estas
fuentes son igual de confiables. Un artículo publicado en el New York
Times tiene mayor credibilidad que uno publicado en el blog personal de un
aficionado a la astrología. Dado que los usuarios acceden a todos estos
sitios usando los mismos mecanismos (navegadores web, interfaces de
usuario y estructuras similares, etc.), existe un efecto nivelador que hace
que los usuarios confíen por igual en canales de trayectorias muy diferentes.
El mover nuestras actividades a espacios informáticos también nos obliga a
manejar el reto del colapso contextual. En el mundo físico es obvio cuando
estamos interactuando en un espacio privado versus un espacio público, y
nos comportamos de forma diferente en cada uno. En Internet estas
diferencias no son tan obvias. Como ha resaltado el arquitecto de
información Andrew Hinton, una usuaria de Twitter puede asumir que está
“susurrando” en un espacio privado con un amigo, pero al equivocarse por
un símbolo (“@“ en vez de “d”) puede en vez anunciar su secreto a miles
de personas instantáneamente 7.
El colapso de entornos no es el único riesgo a nuestra privacidad que
encontramos en Internet. El crecimiento de las redes sociales está causando
que muchas personas compartan más información privada que antes,
intencionalmente o de forma inadvertida. El diseño de algunos de estos
sitios hace que configurar estos detalles sea complicado, y muchas personas
no entienden que pueden estar poniendo en juego la privacidad de sus
amigos y familiares al subir contenido a estos sitios. Como resultado, es
más difícil tomar decisiones al compartir nuestra información.
Cómo hemos enfrentado estos retos hasta

ahora
Muchos de estos retos son nuevos para los diseñadores, por lo que no
tenemos buenos mecanismos para enfrentarlos. Cuando han aparecido
nuevos medios en el pasado, los primeros artefactos en el nuevo medio se
han asemejado a los de los medios anteriores. Por ejemplo, las primeras
cintas cinematográficas se rodaban con la cámara fija en el centro de un
escenario, utilizando el mismo punto de vista inmóvil que vería el miembro
de la audiencia, como si se tratara de una obra teatral. Eventualmente,
directores como Sergei Eisenstein comenzaron a explorar la gramática del
medio, variando la posición de la cámara, haciendo uso creativo del proceso
de edición, etc.
Lo mismo ha ocurrido con el web. Durante la primera década de existencia
de éste nuevo medio, las metáforas que regían la creación del contenido
venían del mundo de las publicaciones. Los primeros sitios web eran
considerados un tipo de panfleto electrónico, y todavía hoy podemos ver
vestigios de éste fenómeno cuando hablamos de “diagramar” “páginas”
web. Un alto porcentaje de los documentos publicados actualmente en línea
todavía emplean diagramados fijos y rígidos, y los diseñadores intentan
imponer el mismo nivel de control sobre los tratamientos tipográficos,
tamaños, y relaciones de los elementos visuales que utilizan cuando diseñan
para medios impresos.
Pensar en estos artefactos como publicaciones fue útil en estas primeras
fases del web, antes de que hubiéramos podido identificar las estructuras
gramaticales y semánticas del nuevo medio. Sin embargo, como metáfora
para nuestro trabajo es cada vez menos útil. Por un lado, el contenido que se
publica en el web está cada vez menos atado a la forma en que el usuario lo
consume. El diseño para publicaciones impresas siempre ha sido inflexible:
el diseñador sabía de antemano las dimensiones y características del
producto terminado, y producía un diseño definitivo para que fuera
plasmado sobre papel. Ahora contamos con una diversidad de tamaños de
pantallas y modalidades de interacción (ej. Interfaces táctiles, punteros y
ratones, interfaces de voz, etc.) por lo que ya no existe una versión
definitiva del diseño de un artefacto digital. La experiencia de leer un
documento en una pantalla táctil de 8.9 centímetros es muy diferente que
hacerlo en una pantalla de 68.6 centímetros con un ratón; y la
popularización de técnicas como el diseño responsivo —un esquema que
permite variar la presentación del contenido en base al tamaño de las
pantallas de los dispositivos— está forzando que muchos diseñadores
tengan que adoptar estrategias de diseño menos rígidas.
Las publicaciones tradicionales también han tenido estructuras
relativamente inflexibles. Por ejemplo, las revistas ofrecen índices que
relacionan los títulos de los artículos particulares a las páginas en que
aparecen. Al igual que las revistas, las primeras páginas web, que eran
creadas “a mano”, también contaban con estructuras jerárquicas sencillas e
inflexibles. Sin embargo, la popularización de sistemas de gestión de
contenido (ej. Wordpress, Drupal, etc.), hace que sea cada vez más factible
producir esquemas de navegación dinámicas.
Pero las diferencias no solo están limitadas a la interacción que ocurre en
las computadoras tradicionales. Los usuarios también pueden acceder a la
información por otros canales completamente ajenos al web. Por ejemplo,
es común que las organizaciones provean servicios de respuesta de voz
interactiva (IVR, por sus siglas en inglés) por teléfono. Mucha de esta
información es similar a la que publican en el web, pero normalmente no
pensamos en el sistema de IVR como una “publicación”. Otro ejemplo son
los apps para los teléfonos inteligentes: en muchos casos proveen
información similar a la que ofrecen los sitios web, pero lo hacen usando
mecanismos de interacción diferentes.
Otra dificultad que enfrentamos al pensar en los sitios web como
publicaciones es que el web es un medio fundamentalmente social, pero la
metáfora de la publicación no acomoda los usos sociales. La forma de las
revistas, libros, y otras publicaciones impresas evolucionó con un solo
lector simultáneo en mente; es posible leer una revista junto a dos o tres
personas, pero no es práctico hacerlo con 900 personas. Un sitio web puede
ser visto fácilmente por 900 personas simultáneamente; de hecho, en
algunos casos, el valor del sitio es precisamente que permite la interacción
de muchas personas simultáneamente. El pensar en estos canales como
publicaciones limita nuestro vocabulario y por ende las posibilidades de
diseño que estamos dispuestos a considerar.
¿Publicación o lugar? Ambos

Dado que la metáfora de la publicación se queda corta, ¿Hay alguna otra
que podamos usar para informar lo que hacemos? Si analizamos el lenguaje
que usamos para describir nuestro trabajo, encontraremos parte de la
respuesta: muchas de las metáforas que usamos sugieren que pensamos
sobre estos artefactos como lugares. Hablamos de “visitar” “sitios” web y
de “encontrarnos” con nuestros amigos en Facebook. Los periódicos erigen
“muros” de pago, e “ingresamos” a la banca en línea para revisar nuestras
cuentas. Un estudio realizado en 1998 por investigadores de IBM y la
Universidad de California, Santa Cruz sugiere que las personas piensan en
el web como un tipo de espacio físico en el que se pueden mover, basado en
el lenguaje que usan para describir sus interacciones en el medio 8. Los
arquitectos de la información Andrea Resmini y Luca Rosati explican la
conexión en su libro Pervasive Information Architecture: los mecanismos
mentales que usamos para orientarnos y navegar en los espacios
informáticos son similares a los que empleamos para orientarnos y navegar
en el mundo físico 9.
Mi principal argumento en este artículo es que los espacios informáticos
que diseñamos y utilizamos a diario son una experiencia nueva para los
seres humanos: los experimentamos como un nuevo tipo de “publicación
espacial” que cae en medio de una gama que tiene en un extremo a los
lugares físicos, como los edificios, y en el otro a las publicaciones
tradicionales como los libros y revistas. En qué parte de la gama podemos
ubicarlos exactamente depende del tipo de artefacto del que estamos
discutiendo: el sitio web de una revista puede ser visto como una
publicación tradicional, mientras que una red social puede ser
experimentada de forma más parecida a un lugar. Siempre y cuando se trate
de un artefacto interactivo (no-linear), el usuario lo va a experimentar entre
uno de estos dos extremos. Los espacios informáticos combinan algunas
características de las publicaciones (“páginas”, “contenido”, etc.) y algunas
características de los lugares (“navegar”, “ingresar”, “sitio”, etc.).
La implicación es que el diseño de estos espacios puede estar informado por
dos campos: la literatura (y por extensión, las ciencias de la información), y
la arquitectura. La conjunción de estos campos es donde se encuentra la
arquitectura de la información (AI), y las raíces de la AI están
fundamentadas en ambos campos, como veremos a continuación. Sin
embargo, hasta ahora, la atención de los arquitectos de la información ha
estado enfocada casi exclusivamente en las lecciones provenientes de las
ciencias de la información. Mi intención es que comencemos a tomar en
serio la arquitectura como fuente que informe la creación de los entornos
informáticos. Para hacerlo, primero debemos ver cuáles son las raíces de la
arquitectura de la información.
La Arquitectura de la Información
La arquitectura de la información es el área de práctica profesional que
busca traer orden y coherencia a estos nuevos entornos para lograr que la
información sea más fácil de encontrar y entender a través de múltiples
canales y dispositivos. La AI define las estructuras semánticas que usan las
personas para encontrar y entender la información. Los productos de la AI
pueden experimentarse de diversas formas: en los esquemas de navegación
de un sitio, en la forma en que está organizada la ilustración de una
explicación médica, o en el rotulado en los pasillos de un hospital que le
muestran a los pacientes dónde están ubicados los diversos espacios del
edificio. Lo que tienen en común es la organización de un conjunto de
elementos discretos de significado en relaciones entre sí de forma que
comuniquen claramente.
Morville y Rosenfeld
La mayoría de los profesionales de diseño que conocen sobre la arquitectura
de la información llegaron a este campo por medio de un libro: Arquitectura
de la Información para el World Wide Web, de Peter Morville y Louis
Rosenfeld 10. El “libro del oso polar”, como se le conoce en la industria, ha
sido el texto estándar de referencia sobre AI desde su primera edición en
1998. Ha sido un libro muy influyente en la industria, y ha ayudado a
definir la forma en que muchos los profesionales en el campo entienden el
tema.
Los principios de diseño propuestos en este libro buscan resolver problemas
de organización de la información, específicamente para sitios web, desde
el punto de vista de las ciencias de la información. Morville y Rosenfeld
son bibliotecarios, y su libro refleja su experiencia en este campo: está
enfocado en la creación de esquemas taxonómicos, definición de
componentes de búsqueda, etiquetado, y organización general de los sitios
web. Morville y Rosenfeld hacen explícita la diferencia entre los aspectos
estructurales de los sitios web y otros aspectos que tienen un impacto
importante sobre la experiencia del usuario de los sitios, como el diseño de
la información (el diagramado de las páginas que componen el sitio), y
aspectos del diseño visual como los tratamientos tipográficos, imágenes,
colores, etc.
El libro de Morville y Rosenfeld divide los problemas (el programa) del
diseño de una arquitectura informática en tres partes: el entorno, el
contenido, y los usuarios. El entorno consiste en aspectos contextuales del
proyecto: objetivos de la organización, aspectos políticos y culturales,
requisitos tecnológicos, recursos disponibles, etc. El contenido incluye los
tipos de documentos, objetos de contenido, metadata, estructuras existentes,
y más. Los usuarios son las audiencias que van a interactuar con el
producto: el esquema propone analizar sus necesidades y objetivos, tareas
que deben realizar, perfiles/experiencia, y más.
Wurman
Aunque el libro del oso polar es extremadamente popular, Morville y
Rosenfeld no son los primeros en haber utilizado el título “arquitectura de
la información”. El arquitecto Richard Saul Wurman originó el término en
los la década de 1960, y lo utilizó explícitamente como título conferencia
anual del Instituto Americano de Arquitectos (AIA) en 1976. Wurman trae
a la arquitectura de la información una clara sensibilidad arquitectónica. La
diferencia entre la arquitectura y el diseño, según Wurman, es que la
arquitectura busca definir el “¿Qué?” de los proyectos — qué problemas
buscan resolver — versus el “¿Cómo?”, que es lo que hacen los
diseñadores. Su obra ha estado enfocada en utilizar técnicas arquitectónicas
para entender una variedad de temas de interés general, desde mapas de
autopistas hasta manuales sobre salud. La mayoría de esta obra consiste en
lo que llamamos actualmente diseño de información; un ejemplo es su mapa
del metro de Tokio 11, que busca hacer entendible un conjunto de ideas
complejas por medio de una gráfica sencilla, impactante, y con una
estructura clara.
En 1996 (dos años antes que el libro de Morville y Rosenfeld) Wurman
publicó Information Architects, libro que incluye la siguiente definición del
término:
Arquitecto de la Información [L infotectus] 1) el individuo que organiza los
patrones inherentes en la data, haciendo que lo complejo sea claro. 2) una
persona que crea la estructura o mapa de la información que permite que
otros encuentren sus propios caminos hacia el conocimiento. 3) la práctica
profesional emergente del siglo XXI que responde a las necesidades de la
época enfocada en la claridad, el entendimiento humano, y la ciencia de la
organización de la información 12.(Énfasis en el original)
Esta definición resume claramente el reto que busca resolver la arquitectura
de la información, y hace énfasis en los objetivos humanistas del campo.
Morville y Rosenfeld habían comenzado a usar el término “arquitectura de
la información” antes de conocer la obra de Wurman. Según Morville,
cuando leyó el libro Information Architects por primera vez (en 1996), su
reacción fue pensar “esto no es arquitectura de la información del todo, esto
es diseño de información” 13. Sin embargo, claramente ambos precedentes
comparten el mismo objetivo: lograr que la información sea fácil de
encontrar y entender por medio de estructuras informáticas que sirvan las
necesidades de los seres humanos que las van a utilizar.
En fin, la arquitectura de la información contemporánea tiene raíces en las
ciencias de la información, por medio de Rosenfeld y Morville, y en la
arquitectura tradicional, por medio de Wurman. Mucho del discurso en el
campo durante la última década ha estado enfocado en la primera a
exclusión de la segunda.
Vínculos, Nodos, y Orden
Aunque los retos que presentan los espacios informáticos son nuevos, los
seres humanos tenemos amplia experiencia diseñando espacios físicos: el
campo de la arquitectura tradicional —el diseño de los edificios y espacios
urbanos que habitamos— cuenta con un rico historial de prácticas que
pueden ayudarnos a generar espacios informáticos coherentes y
comprensibles. En conjunto con técnicas aprendidas de otros campos
relacionados como el diseño de la información y las ciencias de la
información, podemos comenzar a desarrollar un área de práctica altamente
enfocada en resolver los problemas que enfrentamos al diseñar esto
espacios informáticos.
Qué hacen los arquitectos tradicionales

El producto de los arquitectos tradicionales son las instrucciones necesarias
para que otros puedan construir edificios: composiciones intencionales de
formas y espacios que proveen entornos que podemos habitar. Estos son los
lugares donde vivimos, trabajamos, aprendemos, y más. Decimos que los
edificios son composiciones intencionales porque han sido diseñadas para el
propósito explícito de ser habitadas. (Hay muchos otros entornos habitables
en el mundo que no han sido creados intencionalmente: nuestros
antecesores lejanos buscaban refugio donde pudieran.)
Enfoquémonos en los dos elementos que mencioné arriba: formas y
espacios. Las formas son el componente físico de los edificios. Son los
elementos tangibles que componen un edifico: sus muros, ventanas,
columnas, techo, jardines, etc. Las formas pueden contener otras formas:
por ejemplo, una pared puede contener una ventana. Los espacios son los
vacíos que separan las formas que componen el edificio. Son definidas por
(y definen) la relación entre estas formas. Los espacios no son “reales” en el
mismo sentido que las formas: solamente las experimentamos
temporalmente cuando estamos en el edificio. Los espacios no tienen
existencia propia más allá de esta experiencia individual, pero son críticos
para el funcionamiento de lo que entendemos como “arquitectura”. Las
formas y los espacios no pueden existir independientemente los unos de los
otros: están profundamente relacionados entre sí. Son el yin y el yang de la
arquitectura.
Qué hacen los arquitectos de la información

La arquitectura de la información tiene muchas cosas en común con la
arquitectura, pero hay una diferencia importante: el objetivo de la AI no es
la producción de espacios para habitar, sino espacios para comprender.
Mientras que la arquitectura produce entornos para habitar por medio de la
organización de espacios y formas, la arquitectura de la información
produce entornos para comprensión mediante la organización de nodos y
vínculos. Al pensar en los nodos y vínculos como elementos análogos a las
formas y espacios que emplea la arquitectura tradicional, podemos emplear
metodologías devengadas de este campo centenario para informar el diseño
de los espacios informáticos. Veamos estos elementos más de cerca.
Los nodos son unidades individuales de significado. Son los elementos de
contenido —los textos, imágenes, videos, etc. —que en conjunto
comunican un concepto o idea. Un nodo puede ser tan sencillo como una
palabra, o puede ser infinitamente complejo. Al igual que las formas de un
edificio, los nodos pueden contener otros nodos: Una página web es un
nodo, pero también lo son las oraciones, imágenes, y otros elementos que la
componen. Un “sitio web” puede ser considerado un nodo en un conjunto
más grande (el grupo de sitios que comprenden la presencia digital de una
organización, o el web en general.) Una de las responsabilidades más
importantes de un arquitecto de la información es definir los límites de un
nodo para que comunique significado de la manera más óptima.
Hablemos ahora sobre el segundo elemento con que trabajamos los
arquitectos de la información: los vínculos. Los vínculos son los elementos
definen (y son definidos) las relaciones que existen entre dos o más nodos;
son el equivalente de los espacios en la arquitectura tradicional. Estas
relaciones vienen de muchos tipos diferentes. Para aquellos que trabajamos
en el web, el ejemplo más obvio son los hipervínculos, en los que un nodo
(una palabra o un grupo de palabras) apunta a otro nodo (una página o una
sección de una página, por ejemplo) de forma que haciendo clic con un
puntero en el primer nodo causa que la pantalla del usuario cargue y
muestre el segundo nodo.
Sin embargo, existen muchos otros tipos de relaciones que pueden
establecerse entre nodos. Algunas obvias:
Secuenciales: un nodo sigue a otro en una secuencia predefinida. Por
ejemplo, múltiples palabras pueden unirse para formar oraciones, que en sí
puede unirse para formar párrafos, secciones, capítulos, etc.
Espaciales: relaciones definidas por la posición geométrica entre dos nodos.
Por ejemplo, dos imágenes pueden ser comparadas al ubicarlas una al lado
de la otra.
Jerárquicas: cuando un nodo contiene a otro nodo. Por ejemplo, como
mencionamos arriba, las páginas contienen colecciones de nodos que las
definen.
Conceptuales: un nodo dispara en la mente del usuario asociaciones
conceptuales con un segundo nodo, aún cuando este no está presente. Por
ejemplo, podemos presentar una fotografía al usuario, y luego utilizar otra
fotografía que utilice los mismos componentes en una composición
diferente. La memoria de la primera imagen ayuda a crear un vínculo entre
los dos nodos en la mente del usuario.
Tomando en cuenta estos conceptos, podemos definir la arquitectura de la
información como la composición intencional de nodos y vínculos como
estructuras organizadas que facilitan el entendimiento. Esta definición es
intencionalmente amplia, e incluye muchos otros artefactos culturales
dentro del alcance de la arquitectura de la información: libros, mapas,
catedrales Góticas, y más. El producto final de la arquitectura de la
información puede tomar muchas formas: un sitio web, una película (ej.
Powers of 10 de Charles y Ray Eames 14), un libro (ej. cualquiera de la
serie Understanding de Wurman), la organización de los pasillos en un
supermercado, y más.
Estas composiciones coherentes de elementos se logran mediante el
ordenamiento de los nodos y vínculos de forma tal que puedan producir
estructuras espacio-semánticas que comuniquen significado claramente.
Existen diversas metodologías que pueden ser empleadas para lograr estos
ordenamientos: por ejemplo, Wurman propone el esquema LATCH, que
sugiere que existen cinco formas de organizar la información: en torno a su
ubicación, en orden alfabético, en orden cronológico, por categorías, y por
jerarquía. (LATCH es un acrónimo en inglés de estos cinco conceptos:
location, alphabet, time, category, y hierarchy.) El campo de la arquitectura
tradicional también cuenta con una amplia literatura que propone diferentes
metodologías para realizar análisis programáticos de los requisitos de
diseño, incluyendo requisitos contextuales, para luego producir soluciones
sintéticas (ej. diseños) que puedan ser ejecutadas como conjuntos de formas
y espacios (“estructuras”) que satisfagan esos requisitos. La obra de
Christopher Alexander, en particular su libro Notes on the Synthesis of
Form 15, viene a mente. Estos precedentes arquitectónicos son una fuente
inagotable de recursos para los diseñadores de espacios informáticos.
Conclusión
La revolución informática ha traído con sí algunos cambios fundamentales
a la experiencia de las personas que usamos los medios digitales. Muchas
de nuestras actividades diarias se han movido a los espacios informáticos, y
muchas más lo hacen cada año. El crear estos espacios con fines
humanistas, para que la información sea fácil de encontrar, navegar, y
entender, es un reto nuevo para los diseñadores. Sin embargo, es un reto que
puede ser abarcado por medio de una combinación de técnicas,
provenientes de las ciencias de la información y de la arquitectura. La
arquitectura de la información es donde convergen estos campos, por lo que
es un área de práctica crítica para lograr espacios informáticos mejor
adecuados a las necesidades de los seres humanos que los habitan.
Referencias
1. What Happens in an Internet Minute? [Ver en línea la referencia 1]
2. Literacy [Ver en línea la referencia 2]
3. The World Factbook [Ver en línea la referencia 3]
4. Global digital divide [Ver en línea la referencia 4]
5. CBS NEWS [Ver en línea la referencia 5]
6. How an Egyptian Revolution Began on Facebook [Ver en línea la
referencia 6] .
7. Hinton, Andrew, “The Machineries of Context: New Architectures for a
New Dimension”, Journal of Information Architecture, Volume 1, Issue 1,
2009, p 37.
8. P. Maglio, Paul, Matlock, Teenie, “Metaphors We Surf the Web By”,
1998.
9. Resmini, Andrea y Rosati, Luca, “Pervasive Information Architecture:
Designing Cross-Channel User Experiences”, Morgan Kaufman, Capítulo
4.
10. Rosenfeld, Louis, Morville, Peter, Information Architecture for the
World Wide Web, O’Reilly, 1998.
11. Wurman, Richard Saul, “Tokio Access”, Access Press, 1984.
12. Wurman, Richard Saul, Information Architects, Graphis Press, 1996.
13. P. Morville, “A brief history of information architecture”, en: Gilchrist;
Mahon (eds.), Information architecture: Designing information
environments for purpose, Neal-Schuman Publishers, p. xiii, 2004.
14.The Memphis Plenary [Ver en línea la referencia 14]
15. peterme.com [Ver en línea la referencia 15]
Bibliografía
What Happens in an Internet Minute? [Ver en línea]
Hinton, Andrew, “The Machineries of Context: New Architectures for
a New Dimension”, Journal of Information Architecture, Volume 1,
Issue 1, 2009, p 37.
P. Maglio, Paul, Matlock, Teenie, “Metaphors We Surf the Web By”,
1998.
Resmini, Andrea y Rosati, Luca, “Pervasive Information Architecture:
Designing Cross-Channel User Experiences”, Morgan Kaufman,
Capítulo 4.
Rosenfeld, Louis, Morville, Peter, “Information Architecture for the
World Wide Web”, O’Reilly, 1998.
Wurman, Richard Saul. “Tokio Access”, Access Press, 1984.
Wurman, Richard Saul, “Information Architects”, Graphis Press, 1996.
P. Morville, “A brief history of information architecture”, en: Gilchrist;
Mahon (eds.), Information architecture: Designing information
environments for purpose, Neal-Schuman Publishers, p. xiii, 2004.
Eames, R. & Eames, R. (1968). Power of 10. Disponible en YouTube.
[Ver video en Youtube]
Alexander, Christopher, “Notes on the Synthesis of Form”, Harvard
University Press, 1964.
Capítulo 9: Accesibilidad Web y SEO, por Olga Carreras Montoto
Filóloga y lingüista, con un máster en Dirección Técnica en Sistemas
Multimedia y Diseño Asistido por Ordenador de la empresa Autodesk.
Cuenta con más de 12 años de experiencia en el desarrollo de proyectos
web y fue durante 7 años responsable del Departamento de Diseño,
Usabilidad y Accesibilidad de la empresa TB-Solutions. Actualmente
trabaja como consultora independiente especializada en accesibilidad,
usabilidad y arquitectura de información. En 2012 fue incluida como una de
las 40 mujeres más influyentes de internet/nuevas tecnologías en España
por el blog “Mujeres Consejeras”. Es autora del blog “Usable y accesible”,
referente para la comunidad hispana, algunos de cuyos artículos han sido
incluidos en diferentes libros.
Más información:
Twitter: @olgacarreras
Accesibilidad Web y SEO

¿Qué es la accesibilidad web?
La accesibilidad web es el arte de garantizar que un sitio o servicio web
puede ser visitado y utilizado de forma satisfactoria por el mayor número
posible de personas, independientemente de las limitaciones personales que
tengan o de aquellas limitaciones que sean derivadas de su entorno.
Muchas veces se identifica accesibilidad web con accesibilidad para
personas con discapacidad, pero hablar de accesibilidad web “es hablar de
un acceso universal a la web, independientemente del tipo de hardware,
software, infraestructura de red, idioma, cultura, localización geográfica y
capacidades de los usuarios” [W3C, 1994]
Las limitaciones personales no implican siempre una discapacidad (visual,
auditiva, motriz, neurológicas, cognitiva o del lenguaje). Pueden ser
derivadas de la edad, de la inexperiencia tecnológica o de una incapacidad
transitoria; asimismo pueden depender del idioma y cultura del usuario, de
su nivel educativo, o de su localización geográfica.
Las limitaciones tecnológicas o las derivadas de su entorno pueden ser muy
dispares: conexión lenta de acceso a Internet, ambiente ruidoso, escasas
condiciones de visibilidad, acceso desde diferentes dispositivos o
navegadores, etc.
¿Cómo se hace el contenido web accesible?

Las “Pautas de Accesibilidad para el Contenido Web 2.0” (WCAG 2.0)
[W3C, 2008] han sido desarrolladas por la Web Accessibility Initiative
(WAI), organismo dependiente del W3C, y definen cómo crear contenido
web accesible.
Las WCAG 2.0 están estructuradas en torno a los cuatro principios que
conforman los fundamentos de la accesibilidad web: perceptible, operable,
comprensible y robusto.
Cada uno de estos principios tiene asociado un determinado número de
pautas, 12 en total, que proporcionan el marco y los objetivos generales a
cumplir.
Cada una de estas pautas cuenta con una serie de criterios de conformidad,
61 en total, que son los requisitos verificables y tienen asociados un nivel
de conformidad: A (el más bajo), AA, AAA.
Por cada criterio de conformidad se documentan una serie de técnicas
suficientes, otras recomendables y los errores conocidos más frecuentes.
¿Qué es SEO?
SEO (Search Engine Optimization) o Posicionamiento Orgánico en
Buscadores es el conjunto de técnicas para mejorar la visibilidad de un sitio
web en los diferentes motores de búsqueda como Google, Yahoo! o Bing.
El objetivo principal es aparecer en las primeras posiciones de la página de
resultados (denominada SERP) para determinados términos de búsqueda, lo
cual aumentará las probabilidades de que sea visitada por el usuario que
está realizado esa búsqueda concreta.
¿Cómo se mejora el posicionamiento en

buscadores?
El robot de búsqueda de Google (Googlebot) rastrea contenido en Internet
de forma continua y automática para el índice de Google, siguiendo los
enlaces de las páginas e indexando de esta manera miles de millones de
páginas.
El algoritmo que aplica Google para determinar la relevancia de nuestra
página para unos términos de búsqueda concretos, y en base al cual
posicionar nuestra página en los resultados de búsqueda, es modificado con
frecuencia y no se conoce con exactitud, pero son más de 200 factores los
que se tienen en cuenta [Cutts, 2010].
Las técnicas SEO para mejorar el posicionamiento de las páginas se centran
en:
Facilitar el rastreo y la indexación de las páginas por parte de los

robots de los motores de búsqueda, y que esta se realice por los
términos de búsqueda relevantes para esa página.
Conseguir que Google considere nuestra página relevante. Aunque el
algoritmo de Google no se conoce, sí se sabe de ciertos factores que
influyen, como por ejemplo: el número, autoridad o temática de las
páginas que enlazan con la nuestra, la velocidad de carga del sitio 1 o
que otorga prioridad a las páginas con contenido propio, actualizado y
de interés para los visitantes.
Hablamos de black hat SEO para referirnos a las malas prácticas SEO, a las
técnicas para conseguir un posicionamiento poco lícito de las páginas y que
están penalizadas por Google.
Nosotros haremos referencia a las buenas prácticas (white hat SEO) que
llevan a cabo los verdaderos profesionales SEO y que en muchos casos son
similares a las técnicas de accesibilidad web.
Un enfoque conciliador
Difícilmente puedes usar lo que no puedes encontrar. Esta es la primera
reflexión que debemos hacernos para tender puentes entre ambas
disciplinas. Las dos son importantes en un proyecto web, pues no tiene
mucho sentido hacer un sitio accesible si nadie puede encontrarlo. Y a la
inversa, no tiene mucho sentido que nuestro sitio aparezca en el primer
lugar de los resultados de búsqueda si luego el usuario encuentra barreras
insalvables para acceder a su contenido.
El usuario ciego más rico del mundo

Uno de los visitantes más fieles de nuestro sitio web es un usuario con
discapacidad. Es ciego, -no ve las imágenes (al menos de momento), ni los
videos, ni admira la belleza de nuestras animaciones-, es sordo, navega sin
plugins instalados, sin applets y sin javascript activo, por lo tanto le es
imposible seguir los enlaces que dependen de javascript.
Jakob Nielsen le llama el “usuario ciego más rico del mundo” [Nielsen,
2012]. Este usuario es Googlebot, el robot de búsqueda de Google.
Los problemas que suele tener para acceder, interpretar e indexar el
contenido no difieren mucho de los que tratamos en la accesibilidad web.
Esta es la razón por la cual muchas de las técnicas que aplicamos para hacer
nuestra web más accesible repercuten directa y positivamente en su
indexación y posicionamiento.
Foco en el usuario
La accesibilidad web pone su foco en los usuarios, y por el contrario, el
SEO parece poner su foco en máquinas. Sin embargo, los motores de
búsqueda quieren encontrar lo mismo que nuestros visitantes: información
actualizada, pertinente y de calidad. Por ello las últimas modificaciones en
el algoritmo de Google van encaminadas a reconocer la calidad de cada
sitio y a basarse en criterios de usabilidad y accesibilidad.
El buen SEO se centra también en los usuarios, en el interés que generan los
contenidos o en que estos respondan a las expectativas que tenían los
usuarios al realizar la búsqueda y seleccionar nuestro sitio.
Accesibilidad web y SEO: técnicas comunes
En este apartado vamos a repasar las requisitos de accesibilidad web
(haciendo referencia a las WCAG 2.0 [W3C, 2008]) que coinciden con
buenas prácticas SEO ([Google, 2011], [Google, 2012]) y que por tanto
repercuten directamente en la indexación y posicionamiento de nuestra
páginas 2.
Alternativas textuales para elementos no

textuales
Uno de los requisitos de accesibilidad más conocidos es que las imágenes
deben tener un texto alternativo que proporcione la misma información que
pretende transmitir la imagen.
Para el contenido tempodependiente, como videos o audios, se aplican
requisitos adicionales, por ejemplo proporcionar subtítulos, transcripciones
textuales o audiodescripciones al contenido.
Desde el punto de vista de la accesibilidad web
Las alternativas textuales permiten a las personas que no pueden percibir el

contenido visual, por una discapacidad visual o por su contexto de uso, leer
en pantalla, en braille o mediante un lector de pantalla la información que
transmiten.
Las personas sordas podrán leer la información textual alternativa al
contenido sonoro, o esta podrá ser traducida automáticamente a la lengua de
signos.
Desde el punto de vista de SEO
Teniendo en cuenta que los buscadores solo entienden texto, podrán

interpretar y clasificar los contenidos no textuales (imágenes, videos,
audios, object, applet, etc.) gracias a sus alternativas textuales.
Esta información podrá ser indexada y recuperada por los motores de
búsqueda, por ejemplo para mejorar la información que se ofrece para la
búsqueda por imágenes o por videos de Google.
Si además estas imágenes son relevantes en relación con el contenido de la
página, las alternativas textuales que incluyas tendrán palabras claves que
ayudarán también al posicionamiento.
Título e idioma de las páginas

El criterio de conformidad 2.4.2 (nivel A) indica que las páginas deben
tener un título que describa su temática o propósito.
Se especifica que el título debe identificar claramente el contenido de la
página web, tener sentido fuera de su contexto y ser corto. Se recomienda
además que identifique el sitio y que sea único para cada página del mismo.
El criterio de conformidad 3.1.1 (nivel A) señala que se debe indicar el
idioma de la página y en el criterio de conformidad 3.1.2 (nivel AA) que
también han de marcarse los cambios de idioma en el contenido.
El título de las páginas beneficia a todos los usuarios, que así pueden
identificarlas con rapidez y facilidad: en las pestañas del navegador, al
incluirla en Favoritos, al compartirla en redes sociales, etc.
Favorece especialmente a las personas que usan un lector de pantalla, pues
de este modo pueden diferenciar varias páginas abiertas.
Indicar el idioma del sitio y los cambios de idioma del contenido permite
que los agentes de usuario puedan presentar el texto de forma correcta. Por
ejemplo, los lectores de pantalla podrán usar el acento y la pronunciación
adecuados al idioma definido.
Desde el punto de vista SEO

El título de la página indica a los motores de búsqueda sobre qué trata la
página y es un factor muy importante a la hora de indexarla.
Además, la primera línea que se muestra en cada resultado de la SERP
suele ser el TITLE de la página, y este será un elemento decisivo para que
los usuarios decidan si la página es de su interés.
[Google, 2011] da recomendaciones muy similares a las que veíamos en las
WCAG 2.0: incluir el nombre de la web o negocio; usar títulos descriptivos
breves; indicar claramente el tema de la página sin ser demasiado genéricos;
o usar títulos únicos para cada página.
Por otra parte, especificar el idioma de un documento o una parte del
mismo proporciona metainformación relevante a los motores de búsqueda
para su indexación.
Enlaces
El criterio de conformidad 2.4.4 (nivel A) y 2.4.9 (AAA) tratan sobre cómo
clarificar el propósito de los enlaces, especialmente a través del texto de los
mismos. Por ejemplo, un enlace cuyo propósito no está claro sería un enlace
con el texto “Pulse aquí”.
Los enlaces con el mismo destino deben tener la misma descripción. Por el
contrario, no debería haber enlaces con la misma descripción y destinos
diferentes.
La “mejora progresiva” (progressive enhancement) aplicada a la
programación javascript implica implementar las páginas como si no fueran
a soportar javascript y sobre ellas añadir una capa de programación
javascript no intrusivo como mejora. Esto permite que no haya enlaces que
dependan de javascript.
Beneficia a todos los usuarios, que así pueden comprenden el propósito del
enlace y decidir si seguirlo o no. Beneficia especialmente a las personas con
discapacidad cognitiva y a las personas que utilizan un lector de pantalla,
que pueden explorar los enlaces y saltar aquellos en los que no están
interesados.
Es imprescindible que el robot de los motores de búsqueda pueda rastrear

nuestros enlaces. El uso de la “mejora progresiva” y de javascript no
intrusivo, además de hacer páginas más ligeras y con un código más claro y
sencillo, permite evitar enlaces que dependen de javascript y que los robots
no podrán seguir.
Además, los textos de los enlaces son un factor muy relevante para los
algoritmos de búsqueda, puesto que etiquetan el contenido de destino de la
página. Cuanto más significativo y claro sea el texto del enlace o su
información adicional, más fácil le será a Google entender la temática de la
página a la que enlaza e indexar y posicionarla por las palabras claves que
la definen.
Encabezados y marcado semántico

En el criterio de conformidad 1.3.1 (nivel A) se aborda la necesidad de
separar el contenido de la presentación y usar un marcado estructural y
semántico adecuado para cada contenido: <h1>-<h6> para los encabezados;
 para los párrafos; <ol>, <ul>, <dl> para las listas; y 
para enfatizar el texto; etc.
No se deben utilizar determinados elementos para conseguir un efecto
visual. Por ejemplo, no se debe usar H1 para aumentar el tamaño de letra de
un texto sino para marcarlo como un encabezado de primer nivel.
Asimismo, tampoco se deben simular elementos mediante estilos. Por
ejemplo, no se debe utilizar un elemento P con estilo de texto grande y en
negrita para simular un encabezado, sino que se debe utilizar un elemento
H1.
El criterio de conformidad 2.4.1 (nivel A) hace referencia a la importancia
de la estructuración del contenido mediante encabezados y a la agrupación
de los enlaces en listas. Los encabezados se deben usar de forma coherente
según su importancia y jerarquía, sin saltarse niveles y encabezando
siempre contenido.
En el criterio de conformidad 2.4.6 (nivel AA) se indica que los
encabezados deben ser claros, breves e identificar la sección de contenido
que encabezan.
El correcto marcado semántico de las páginas, la estructuración del
contenido mediante encabezados y la agrupación de los enlaces en listas,
permiten reconocer la estructura y la semántica del contenido
independientemente del contexto de uso.
Por ejemplo, los usuarios de lectores de pantalla podrán buscar diferentes
tipos de contenidos, obtener un listado de enlaces o encabezados, u “ojear”
el documento saltando de un encabezado a otro, sin necesidad de una
lectura lineal completa.
Si los títulos son claros y descriptivos, los usuarios pueden encontrar más
fácilmente la información y comprender las relaciones entre las diferentes
partes del contenido.
El marcado semántico y el uso correcto de los encabezados de la página

hacen más evidente la estructura del contenido y la relevancia de cada uno
de sus elementos, lo cual ayuda a interpretar la página e indexarla
correctamente.
También hay que tener en cuenta que Google no solo tiene en cuenta la
frecuencia de las palabras sino también su relevancia, y esta es mayor en
función de dónde se encuentran: si están en un encabezado, el nivel de
encabezado que las contiene, si están marcadas como relevantes (con
“strong” o “em”), etc.
Estándares y separación entre contenido y

presentación
El criterio de conformidad 4.1.1 hace referencia al uso del lenguaje de
marcado utilizado de acuerdo a su especificación, y una técnica para
lograrlo es la validación del código mediante el validador automático del
W3C <http://validator.w3.org/>
Otros criterios de conformidad ya vistos (como 1.3.1 explicado en el
apartado anterior) hacen referencia a la separación entre el contenido y la
presentación. En el criterio de conformidad 1.1.1 (nivel A) se indica además
que las imágenes decorativas se deberían incluir preferentemente en las
CSS para separar el contenido de la presentación; y por el mismo motivo,
las WCAG 2.0 desaconsejan las tablas para maquetar.
En el criterio de conformidad 1.4.5 (nivel AA) se indica que debe utilizarse
texto en vez de imágenes de texto.
Un código válido y de acuerdo a la especificación asegura que los agentes

de usuario y productos de apoyo podrán interpretar correctamente la página
y su contenido.
Separar el contenido de la presentación permite modificar la presentación
basándose en la estructura, por ejemplo permite al usuario utilizar una CSS
alternativa: de alto contraste, con el texto más grande, etc.
Usar texto en vez de imágenes de texto asegura que los usuarios puedan
modificar el texto para adecuarlo a sus necesidades.
La separación entre el contenido y la presentación genera páginas más

ligeras y disminuye el tiempo de carga, que es un factor relevante para el
posicionamiento. Además las páginas tienen un código más claro y sencillo,
con una buena relación entre contenido y código, que sumado a un marcado
válido y de acuerdo a la especificación, las hace más fáciles de interpretar e
indexar.
Mapa web y navegabilidad

El criterio de conformidad 2.4.5 (nivel AA) indica que se debe proporcionar
más de un camino para localizar una página web en el conjunto del sitio. Se
pueden usar diferentes técnicas: enlaces a páginas relacionadas, una tabla de
contenidos o un mapa web.
Por su parte, el criterio 2.4.8 (nivel AAA) trata sobre proporcionar
información al usuario acerca de su ubicación en el conjunto del sitio. Las
técnicas aplicables pueden ser, por ejemplo, el uso de migas de pan, un
mapa web o incluir una barra de navegación semántica mediante el
elemento LINK.
En las WCAG 2.0 también se hace referencia a que las redirecciones
deberían ser transparentes para el usuario (criterio 2.2.1 y técnica SVR1)
usando por ejemplo redirecciones de servidor 301 para las páginas movidas
permanentemente.
Los requisitos para mejorar la navegabilidad nos benefician a todos, pero

especialmente a las personas con discapacidad visual, con problemas
cognitivos o con déficit de atención.
El robot del motor de búsqueda debe ser capaz de llegar a todas las páginas
de nuestra web. Incluir un mapa del sitio, migas de pan o enlaces
relacionados ayuda a evidenciar su estructura y nos asegura que se pueda
acceder a todas sus páginas.
La inclusión de metainformación en una barra de navegación semántica
ofrece al buscador información sobre su relación con otras páginas o el tipo
de contenido que incluyen. [Google, 2011] también recomienda el uso de
migas de pan y de un mapa web. Además, las redirecciones 301 para las
páginas movidas permanentemente nos permitirán mantener los enlaces
entrantes backlinks y el PageRank.
Legibilidad
El criterio de conformidad 3.1.5 (nivel AAA) trata sobre adecuar el nivel de
lectura del texto y su legibilidad para todos los usuarios.
El criterio de conformidad 3.1.3 (nivel AAA) indica que se debe clarificar
el significado de las palabras inusuales o de jerga mediante por ejemplo una
definición en línea o con un glosario de definiciones.
El criterio 3.1.4 (nivel AAA) señala que también se debe explicar el
significado de acrónimos o abreviaturas, por ejemplo en el propio texto,
mediante el atributo TITLE de los elementos <abbr> y <acronym> o con un
glosario.
Beneficia a todos los usuarios, especialmente a las personas con una
discapacidad cognitiva o del lenguaje, con problemas de aprendizaje o
memoria, a las personas de una cultura diferente o con un nivel educativo
menor al requerido por la página.
Es más sencillo inferir la temática de un contenido textual claro, conciso y

correcto, y sin duda es más fácil de rastrear e indexar correctamente.
Si la página contiene el lenguaje más apropiado, claro y simple para el
contenido del sitio será probable que estemos más cerca de los posibles
términos de búsqueda de nuestros visitantes. Las alternativas a siglas,
palabras de jerga, tecnicismos, etc. permiten abarcar también más variedad
de posibles búsquedas.
El uso de un resumen al comienzo del contenido, -que presumiblemente
tendrá las palabras clave para la página-, responde al modelo de pirámide
invertida: lo más importante arriba, y cuanto más arriba más relevancia le
da Google.
Para ello debe estar realmente situado “arriba” en el código, para que sea,
dentro del contenido, lo primero que lean los lectores de pantalla pero
también los buscadores; las técnicas de las WCAG 2.0 relativas al correcto
orden lectura nos apoyarán en este sentido.
Otras consideraciones
Google indexa también archivos PDF [Google, 2011b] y SWF Flash

[Google, 2012b]. Las WCAG 2.0 se aplican también a este tipo de archivos
(de hecho incluyen técnicas específicas para ellos), que si son inaccesibles
de forma nativa serán no sólo inaccesibles para muchos usuarios sino
también para Google.
Por otro lado, tanto las WCAG 2.0 (técnica H70, técnica H64) como
Google [Google, 2012b], [Google, 2012c] desaconsejan el uso de frames e
iframes, y en el caso de usarlos ofrecen las mismas recomendaciones.
Conclusiones
“Vender” accesibilidad web es a menudo complicado. Esta dificultad es
debida en gran medida al desconocimiento de qué es realmente la
accesibilidad web y de todos beneficios que reporta, así como a la
simplificación de que la accesibilidad web es accesibilidad solo para
personas con discapacidad.
Por el contrario, “vender” SEO suele ser más sencillo, quizás porque los
resultados son más fáciles de medir y los beneficios económicos más
evidentes.
Conocer y ser conscientes de que:
muchas de las acciones que llevamos a cabo para hacer nuestras páginas
web más accesible repercuten directa y positivamente en su
posicionamiento en los buscadores;
ambas disciplinas tienen muchos puntos de encuentro y utilizan técnicas
similares; quizás ayude a que efectivamente la accesibilidad web y el SEO
caminen de la mano, no se miren con desconfianza y llegue el día en que se
ofrezcan habitualmente de forma conjunta e integrada.
Y quizás también, de esta manera, muchas más empresas y organismos
decidan hacer sus sitios web accesibles.
Referencias
1. En abril de 2010 Google confirmó la velocidad de carga de las páginas
como un factor relevante de posicionamiento [Google, 2010]
2. Hay otros requisitos de accesibilidad que no tienen relación directa con el
posicionamiento en buscadores, y a la inversa, acciones SEO que no tienen
una correspondencia directa con requisitos de accesibilidad.
Bibliografía
Carreras, Olga, “Tabla resumen de los requisitos de accesibilidad para
los medios tempodependientes según las WCAG 2.0”, en: blog Usable
y accesible: [Ver Blog en línea] , 28 de agosto de 2012 [Consulta: 27
de noviembre de 2012]
Cutts, Matt. “How Search Works” [Archivo de vídeo], en: canal de
YouTube de Google [Ver video en Youtube] , 4 de abril de 2010
[Consulta: 27 de noviembre de 2012]
“Using site speed in web search ranking”, en: Google Webmaster
Central Blog: [Ver en línea sitio de Google] 9 de abril de 2010
Guía para principiantes sobre optimización para motores de búsqueda:
[Ver en línea guía para principiantes] , 2011 [Consulta: el 23 de
noviembre de 2012]
“Archivos PDF en los resultados de búsqueda de Google”, en: El Blog
para Webmasters: [Ver en línea blog para Webmasters] , 24 de
septiembre de 2011 [Consulta: el 23 de noviembre de 2012]
“Directrices para webmasters Prácticas recomendadas para ayudar a
Google a encontrar, rastrear e indexar tu sitio”, en: Herramientas para
webmasters de Google: [Ver en línea las directrices] , 16 de octubre de
2012 [Consulta: el 27 de noviembre de 2012]
Google. “Flash y otros archivos multimedia”, en: Herramientas para
webmasters de Google.: [Ver en línea recomendaciones para Flash] ,
16 de octubre de 2012 [Consulta: el 27 de noviembre de 2012]
Google. “Marcos”, en: Herramientas para webmasters de Google.: [Ver
en línea macros] , 16 de octubre de 2012 [Consulta: el 27 de
noviembre de 2012]
Morville, Peter. “User Experience Design”, en: Semantic Studios: [Ver
en línea UXD] , 21 de Junio de 2004. [Consulta: 24 de noviembre de
2012]
Nielsen, Jakob. SEO and Usability: [Ver en línea SEO y Usabilidad] ,
12 de Agosto de 2012. [Consulta: el 23 de noviembre de 2012]
World Wide Web Consortium (W3C) Oficina Española. “Accesibilidad
web”, en: El W3C de la A a la Z: [Ver en línea Accesibilidad Web] ,
1994. [Consulta: 27 de noviembre de 2012]
W3C. Web Accessibility Initiative (WAI). Web Content Accessibility
Guidelines 2.0.
W3C Recommendation, 11 de diciembre de 2008.: [Ver en línea las
recomendaciones en Inglés].Traducida al español en: SIDAR. [Ver en
línea las recomendaciones en Español] , 15 de diciembre de 2009.
W3C. Web Accessibility Initiative (WAI). Techniques for WCAG 2.0:
[Ver en línea las técnicas WAI] , 3 de junio de 2012. [Consulta: 27 de
noviembre de 2012]
W3C. Web Accessibility Initiative (WAI). Understanding WCAG 2.0:
[Ver en línea las WAI] , 3 de junio de 2012. [Consulta: 27 de
noviembre de 2012]
Capítulo 10: Desarrollo de un videojuego accesible, análisis del proceso
de trabajo: El Caso Slalom, por Javier Mairena
Técnico Superior en Desarrollo de Aplicaciones Informáticas y ha
complementado su formación de forma autodidacta como desarrollador de
videojuegos especializado en accesibilidad. Actualmente trabaja en
AccessAble Games como responsable y experto en accesibilidad en
videojuegos desarrollando productos propios y ayudando a otros
desarrolladores a crear juegos más accesibles.
Más información:
Twitter: @javimairena
Mini biografía de Daniel Márquez

Ingeniero en Informática, posee un máster en Lógica, Computación e
Inteligencia Artificial por la Universidad de Sevilla. Ha completado su
formación con el desarrollo de videojuegos. Actualmente trabaja en The
Game Kitchen como Lead Programmer donde también trata investigar
avances en todo lo referido a la inteligencia artificial en videojuegos.
Más información:
Ingresar al sitio web de Daniel Márquez
Correo electrónico: Enviar mail al autor.
Desarrollo de un videojuego accesible, análisis

del proceso de trabajo: El Caso Slalom
Accesibilidad siempre presente
Lo más importante a la hora de desarrollar un videojuego accesible es tener
siempre la accesibilidad presente, desde el inicio del diseño del juego hasta
su publicación. En los primeros diseños de concepto de lo que será el juego
(objetivos, mecánicas, elementos, control...) resulta sencillo incluir
modificaciones que hagan que el juego vaya a ser más accesible,
comparado con incluir esas modificaciones una vez el juego ya está en
desarrollo o terminado. Durante el desarrollo es importante que todos los
perfiles que forman parte en la realización del videojuego (diseñador de
juego, diseñador gráfico, programador, diseñador de niveles, técnico de
sonido...) tengan siempre en mente la accesibilidad, ya que cada uno de
ellos puede realizar pequeñas modificaciones en su trabajo que hagan que el
juego sea más accesible. Por ejemplo, un diseñador gráfico puede crear
distintas formas para cada identificar elementos distintos dentro del juego,
en vez de intentar diferenciarlos sólo asignándoles colores diferentes (lo
que supondría un problema para personas con daltonismo). O puede crear
los gráficos teniendo en cuenta que es posible que se pueda añadir una
opción en el juego de alto contraste. Un programador que tenga siempre en
mente la accesibilidad puede crear también código en el que sea más fácil
implementar ciertas características de accesibilidad. También puede avisar
al resto del equipo de opciones de accesibilidad que considere poco
costosas de implementar, a nivel de programación, debido al tipo de juego
que se esté haciendo y la tecnología con la que se esté trabajando. Estos son
solo algunos ejemplos para mostrar que es importante que todos los perfiles
tengan conocimientos básicos de accesibilidad en videojuegos para que el
juego acabe siendo lo más accesible posible, dentro de las posibilidades y
recursos del proyecto.
Conceptos básicos:
Es ilusorio pensar que el hecho de hacer un buen diseño de juego antes de
comenzar el desarrollo del juego nos asegure que el videojuego vaya a ser
más accesible, porque durante el desarrollo siempre se acaban produciendo
cambios en el diseño del juego por motivos muy variados: tras comprobar
que ciertas cosas resultan distintas una vez están el juego, o por falta de
recursos o tiempo, o al descubrir la necesidad de ciertos cambios tras las
fases de pruebas de calidad con jugadores. Incluso a la hora de la
publicación del juego es importante informar sobre el nivel de accesibilidad
del juego para que los posibles jugadores tengan claro si van a poder
disfrutar del juego o no antes de comprarlo.
Todavía no existe ningún estándar sobre la forma de identificar la
accesibilidad de un videojuego, pero sí una iniciativa por parte de Special
Effect de utilizar un ícono que indique que el juego ha sido diseñado para
ser más accesible en alguno de sus aspectos.
Este ícono debería aparecer en alguna parte visible de la portada del juego,
parte trasera o cualquier otro tipo de situación a la que pueda tener acceso el
jugador antes de su compra.
Debería también ir acompañado de una información algo más detallada de
su accesibilidad o de un enlace a esa información. Una información más
detallada podría ser: detalle de las capacidades necesarias del jugador para
poder disfrutarlo, cuando el juego está configurado en su modo más
accesible; o detalle de los pasos a seguir y/o características incluidas para
eliminar las barreras cognitivas, auditivas, visuales y de control.
Más información sobre la iniciativa de esta identificación: [Ver en línea la
iniciativa]
También, a la hora de su distribución por tiendas digitales de videojuegos,
sería importante indicar a la tienda estas características, ya que algunas de
ellas ya cuentan con una clasificación de estas que son visibles para los
compradores.
En Steam [Ver en línea Steaam] por ejemplo, una de las características que
destacan de los juegos es que tengan Closed Captions (subtitulado completo
de sonidos).
IndieCity [Ver en línea IndieCity] es la tienda digital que actualmente tiene
la mayor clasificación de características de accesibilidad en sus juegos.
Dispone de indicadores de accesibilidad para:
Daltónicos
Auditivo
Controles personalizables
Soluciones de accesibilidad
Aunque todavía no existe un estándar en accesibilidad en videojuegos, sí
existen algunas recomendaciones publicadas por distintas entidades que
pueden servir como guías para crear videojuegos más accesibles. En
castellano podemos encontrar un documento muy extenso, una recopilación
llevada a cabo por el CEAPAT [Ver en línea CEAPAT] de artículos de
varios autores que recoge experiencias reales y recomendaciones:
“Buenas prácticas de accesibilidad en videojuegos”, CEAPAT. 2012.
Descargar PDF CEAPAT 2012. Y un pequeño documento que resume
algunos de los conceptos más básicos: “Videojuegos accesibles, por qué y
cómo hacerlos”, Mairena García de la Torre, Javier. 2009.Descargar PDF de
Videojuegos accesibles
En inglés destacan dos guías creadas recientemente. Una de ellas sólo se
puede consultar por web: “Game Accessiblity Guidelines”, varios autores.
2012. [Ver en línea la guía, en inglés]
Y otra dispone en formato documento: “Includification, a practical guide to
game accessibility”, varios autores. 2012. Descargar PDF
Mayores dificultades de documentación y

experiencias previas
La mayor dificultad a la hora de desarrollar un videojuego accesible
seguramente puede ser la falta de experiencias previas en accesibilidad
dentro de la industria del videojuego. Desgraciadamente, los
desarrolladores de videojuegos no han llegado a considerar la accesibilidad
como algo importante todavía y hoy en día sólo son algunos los que están
empezando a considerarla como algo necesario. Debido a esto existe una
importante carencia en cuanto a documentación, estandarización y
experiencias previas sobre las que aprender y basarse para desarrollar un
videojuego más accesible. Las guías y recomendaciones públicas que
existen pueden resultar vagas a la hora de la implementación de esas
características en un videojuego. Cada característica de accesibilidad se
podría implementar de muchas formas, pero por la experiencia todavía no
se conoce bien cuál es la mejor para cada una de ellas.
Tecnología para videojuegos no preparada para

la accesibilidad
Otro gran impedimento es que la tecnología utilizada para crear los
videojuegos no está pensada para crear videojuegos más accesibles, con lo
que en la mayoría de los casos cualquier nueva característica básica de
accesibilidad tiene que ser creada desde cero.
En otras industrias de nuevas tecnologías ha habido grandes cambios en los
estándares tecnológicos y de diseño en pro de la accesibilidad, y las
herramientas para la creación de contenidos se han actualizado para que
añadir más accesibilidad al producto sea una tarea menos costosa. Falta
todavía un poco más de tiempo para que los videojuegos creen una base de
diseño y tecnológica que facilite la creación de juegos más accesibles.
Caso práctico: Slalom, el Videojuego

Concepto
Slalom, el Videojuego, es un simulador del deporte “Slalom en Silla de
Ruedas”, practicado por personas con parálisis cerebral. El objetivo de la
creación de este simulador es que las personas que practican o quieren
empezar a practicar este deporte puedan conocer mejor sus reglas, tipos de
pruebas y recorridos, e incluso mejorar sus tiempos practicando estrategias
distintas de movimientos.
El juego no pretende ser un sustituto de la práctica real, pero sí una gran
ayuda para mejorar y conocer más este deporte sin las necesidades de
espacio, tiempo y personal que requiere la práctica real de este deporte.
Slalom, el Videojuego, es un proyecto del Ministerio de Sanidad, Servicios
Sociales e Igualdad de España (http://www.mspsi.gob.es) y del Centro de
Referencia Estatal Discapacidad y Dependencia de León
(http://www.crediscapacidadydependencia.es/); desarrollado por The Game
Kitchen (http://www.thegamekitchen.com/) junto a AccessAble Games
(http://www.accessablegames.com/).
Se puede descargar de forma gratuita para PC Windows aquí: Descargar
aquí
Accesibilidad prioritaria: movilidad

Ya que es un juego sobre un deporte practicado por personas con parálisis
cerebral y que el principal usuario objetivo son personas también con
parálisis cerebral, la accesibilidad en este proyecto se ha centrado
principalmente en la movilidad.
Se han tenido también en cuenta otros aspectos a nivel cognitivo, visual y
auditivo que, por las características concretas de este juego, resultaban poco
costosas de implementar. El proyecto fue desarrollado utilizando la
metodología SCRUM, con lo que para cada uno de los seis sprints de los
que se compuso el proyecto se priorizaron las distintas características de
accesibilidad se iban a implementar en el juego.
Accesibilidad implementada en el juego:

Estas son las características de accesibilidad que se implementaron en el
juego.
Movilidad
Configuración de la velocidad general del juego. Se puede modificar la
velocidad del juego, ralentizando o acelerando todo lo que sucede en el
juego. Exceptuando algunas cosas que no son momentos realmente de
juego, como las secuencias introductorias a las pruebas.
Modo de control con joystick o teclado. El juego está principalmente
diseñado para ser controlado con un joystick tradicional por su semejanza
con los joystick de las sillas motorizadas, a los que muchos de los usuarios
objetivo puede que ya estén acostumbrados a manejar. Además resulta un
dispositivo sencillo de controlar por su tamaño y forma para personas con
parálisis cerebral, comparado con otros dispositivos de control. Pero
también puede ser controlado con gamepad o teclado, lo que lo hace
compatible también con pulsadores grandes externos si se configuran como
las teclas cursores.
Modo de control con ratón (para trackballs y ratones faciales también). En
este modo se puede controlar el juego tan sólo moviendo el cursor del ratón,
sin necesidad de pulsar ningún botón. El cursor del ratón funciona como un
joystick virtual en pantalla: si está situado en el centro de la pantalla no hará
nada, si lo movemos a la parte superior de la pantalla es como si
empujáramos el joystick hacia delante, si lo situamos en la parte inferior es
como si moviéramos el joystick hacia nosotros, y del mismo modo si
movemos el cursor hacia los lados es como si moviéramos el joystick hacia
los lados.
Este modo se introdujo pensando sobre todo en las personas que ya
controlan el PC con un ratón facial, para las que es importante que no sea
necesario tener que pulsar una tecla o botón por comodidad de uso. Además
también resultaba más accesible para los que utilizaran ratón o trackballs,
de los que hay versiones especiales muy grandes pensados para la
accesibilidad.
Modo de control con un botón (para pulsadores). Pensado para personas
que utilizan grandes pulsadores conectados al ordenador. En este modo al
pulsar alguna de las teclas o el pulsador, el juego se detiene por completo y
en pantalla aparece en pantalla un círculo con una flecha. La flecha gira
automáticamente sobre el círculo y al pulsar de nuevo la tecla o el pulsador
el juego volverá de la pausa y se comportará como si estuviéramos
empujando un joystick en la dirección en la que estaba la flecha cuando
volvimos a pulsar la tecla. En las opciones del juego se puede configurar a
la velocidad a la que queramos que se mueva la fecha en este modo, por si
necesitamos ponerlo a una velocidad muy lenta o nos vale con una algo más
rápida.
Configuración de la sensibilidad de los controles. Se puede modificar la
sensibilidad de los controles para que personas que, por ejemplo, no puedan
realizar pequeños movimientos con el joystick y lo hagan siempre al
máximo del rango del joystick, no produzcan en el juego siempre un
movimiento a máxima velocidad si no más pequeño.
Del mismo modo para los que sólo pueden mover el joystick en un rango
muy pequeño, se puede configurar para que ese leve movimiento se
traduzca en el juego en el movimiento máximo que se podría hacer con el
joystick.
Cognitiva
Tutoriales. El juego dispone de un tutorial para cada tipo de prueba y
obstáculo donde se explica paso a paso las reglas del juego. Se puede
reproducir a la velocidad que se desee, incluso retroceder hacia atrás para
repetir ciertas partes y también pausarlo totalmente.
Líneas de ayuda para guiar entre obstáculo y obstáculo. Se puede activar
unas flechas indicatorias que muestran el camino hacia el siguiente
obstáculo, algo muy importante cuando todavía estás aprendiendo las reglas
del juego y no recuerdas cual es el orden de ellos. Esta opción resulta de
gran ayuda sobre todo en el modo de recorrido variable, donde ciertos
obstáculos cambian de posición.
Dos idiomas: Castellano e Inglés. El juego se encuentra en dos idiomas:
Castellano e Inglés. Automáticamente al iniciarlo comprueba el idioma del
sistema operativo, si es Castellano el juego se iniciará en Castellano, en
cualquier otro caso lo hará en Inglés. El idioma se puede cambiar también
manualmente en las opciones.
Auditiva
Configuración del volumen de la música y sonidos por separado. Útil para
personas con problemas de audición, se puede configurar los volúmenes de
música y sonidos por separado. La música en el juego no se utiliza como
ningún tipo de indicador, pero los sonidos sí pueden ayudar a saber cuando
has tirado un pivote al suelo, por ejemplo.
Subtitulado de sonidos (closed captions). El juego dispone de subtitulado
completo de sonidos, con el que la mayoría de los sonidos son indicados
visualmente mediante una breve descripción cada vez que suenan.
Visual
Ajuste de brillo y contraste con gran libertad. Se puede configurar el brillo
y contraste del juego, pero con una libertad mucho mayor la habitual en la
mayoría de los videojuegos, pudiendo llegar a esquemas de colores
parecidos al negativo.
Mayores complicaciones en la implementación
de la accesibilidad:
Configuración de la velocidad general del juego

Para que el jugador pudiera configurar la velocidad general del juego, al
principio se pensó que bastaba con dejar que el usuario modificara
directamente un parámetro de velocidad del juego que influye en todo los
elementos móviles y que dependen del tiempo; algo que suelen tener todos
los videojuegos para poder implementar la pausa o una cámara lenta para
ciertos momentos, por ejemplo.
Pero se vio que realmente hacía falta otra velocidad más, una “velocidad de
accesibilidad” que influyera como multiplicador sólo en ciertas cosas en las
que realmente se querían que cambiasen al modificar esta velocidad.
La necesidad de este parámetro por separado saltó a la vista con situaciones
como cuando el jugador ponía la velocidad del juego muy lenta y las
secuencias introductorias a las pruebas (una cámara que vuela recorriendo
el escenario antes de empezar) se reproducían también de una forma
extremadamente lenta. Al no ser realmente un momento de juego no se vio
la necesidad de que cada vez que empezaras a jugar una prueba nueva
tuvieras que esperar tanto en una secuencia introductoria.
Fue una necesidad que se descubrió algo tarde durante el desarrollo, pero
que fue fácil de solucionar.
Multijugador
El juego, como el deporte real, dispone de una prueba tipo eliminatoria en
la que pueden jugar dos personas a la vez. El ganador es el primero en
llegar a la meta después de haber superado ciertos obstáculos.
El primer problema surge al pensar que pasa cuando juegan dos personas
utilizando perfiles distintos en los que la configuración de la velocidad del
juego no es la misma. En este caso se decidió que la mejor opción era
aplicar a los dos jugadores la velocidad más lenta que tuviera uno de ellos.
En la mayoría de los casos obligar a uno de ellos a jugar a una velocidad
más lenta de la que tenía configurada no supondrá un problema, en cambio
obligar a que juegue a una más rápida sí sería un problema.
El segundo problema surgió en el caso en el que uno de ellos quisiera usar
el modo de control con un botón, en el que jugando de forma individual el
juego se detiene por completo al pulsarlo. En este caso lo que se hizo es
modificar el comportamiento del control de un botón para que en vez de
detener el juego por completo detuviera sólo el movimiento de la silla de
este jugador, así al pulsar el botón no detiene también el movimiento del
otro jugador.
Accesibilidad en los menús

En la lista de características que se querían tener en el juego se añadió la
opción de poder navegar en los menús utilizando sólo un botón o con el
joystick, además de la navegación por defecto que ya existía con el ratón.
El problema fue que no se le dio la suficiente importancia a este tema y se
añadió demasiado tarde a la lista de características del juego y con poca
prioridad, pensando que su implementación no iba a ser demasiado costosa
o por no darle realmente la importancia que se merecía.
El resultado fue que al final del proyecto se vio que no daba tiempo porque
era más costoso de implementar de lo que parecía por culpa principalmente
de la tecnología. El juego se desarrolló con Unity 3D, donde el sistema de
interfaces y menús era muy deficiente y costoso de implementar. En las
nuevas versiones de Unity 3D se ha mejorado mucho eso, pero por aquel
entonces el desarrollo de los menús tan sólo con navegación con ratón se
llevó mucho más tiempo del esperado y añadir opción de navegación con
un botón y joystick ya se salía del tiempo de desarrollo establecido.
El resultado es que una persona que sólo pueda jugar con el joystick o con
un botón necesita la ayuda de otra persona para navegar por los menús del
juego. Se hizo un cambio al final para solventar mínimamente este
problema haciendo que al menos, al terminar de jugar una prueba (por
llegar al final o por resultar eliminados por penalizaciones), en el menú de
finalización si no hay ningún movimiento en el ratón aparece una cuenta
atrás de 7 segundos en botón de empezar de nuevo, cuando llega a cero es
como si se hubiera pulsado ese botón y la prueba se reinicia. Con esto al
menos el jugador que utiliza joystick o un botón sólo necesita ayuda al
iniciar el juego hasta llegar a la prueba que quiere jugar, una vez en ella
puede reintentarla toda las veces que quiera sin la necesidad de otra
persona.
Accesibilidad planteada pero no llegada a

implementar:
Movilidad
Menús navegables con joystick o con un botón. Hubiera sido la siguiente
característica implementada si se hubiera tenido más tiempo de desarrollo,
para dar total autonomía para navegar por los menús a los jugadores que
utilizan joystick o un botón.
No se añadió porque su implementación era más costosa de lo que se había
pensado en un principio y no se le dio la prioridad que realmente
necesitaba.
Visual
Modo alto contraste. Aunque el juego da total libertad de cambiar el
contraste y el brillo, hubiera estado bien añadir un modo especialmente
diseñado de alto contraste para personas con baja visión.
Modo gráficos simplificados. También se pensó en un modo de gráficos
simplificados en el que se eliminarían elementos gráficos que realmente no
son necesarios, como las gradas del estadio y paredes, para dejar sólo los
elementos importantes del juego.
Además también que se hubieran simplificado ciertas texturas para tuvieran
menos detalles pensando en que contrastaran más unos elementos del juego
de otros.
Locuciones. Añadir locuciones en Inglés y Castellano hubiera ayudado a
personas con baja visión y también a personas que tienen problemas de
lectura a nivel cognitivo, pero era algo que se salía del presupuesto del
juego.
Cognitiva
Indicadores de ayuda mientras juegas. Aunque el juego tiene la opción de
añadir unas guías que te dicen por donde tienes que ir al siguiente
obstáculo, se pensó en la idea de dar más indicaciones al jugador incluso
mientras estaba dentro de un obstáculo, diciéndole paso a paso lo que tenía
que hacer en cada momento.
Mapa durante el juego. Antes de iniciar una prueba de recorrido variable, en
el menú de juego se puede ver un mapa de la prueba seleccionada, con el
dibujo del recorrido y la situación de cada tipo de obstáculo. Entre las
posibles características se pensó también añadir ese mapa mientras estabas
jugando la prueba, y en el que además hubiera un ícono que identifica tu
posición actual en el mapa y hacia dónde estás mirando. Esto hubiera
ayudado mucho a saber tu situación dentro del circuito y cuál es la siguiente
prueba que te toca. Perdió importancia porque con la opción de las guías en
el suelo que indican como ir al siguiente obstáculo ya estaba solucionado
este problema.
Íconos para los perfiles de jugadores. Cada jugador puede crear un perfil
personal en donde se guarda su configuración del juego y al que le pone un
nombre personalizado. Lo ideal hubiera sido también poder asignar un
ícono, avatar o fotografía a ese perfil; pensando en personas con
dificultades de lectura.
Conclusiones
Aunque se cometieron algunos fallos en las decisiones de prioridad de las
características de accesibilidad, en general, el Centro de Referencia Estatal
Discapacidad y Dependencia de León quedó muy satisfecho del resultado
del proyecto y del nivel de accesibilidad alcanzado.
El equipo de desarrollo aprendió que a nivel de programación habría que
plantear mejor ciertas cosas desde el principio, desde que se conocen cuáles
son las características de accesibilidad más importantes para este juego y
que seguramente acaben implementándose, para que finalmente se puedan
añadir sin que sea una labor demasiado costosa.También hubiera estado
bien analizar mejor el coste de la implementación de ciertas opciones de
accesibilidad pensando en las limitaciones de la tecnología que se estaba
usando.
Más sobre Slalom, el Videojuego. Slalom, el Videojuego se puede descargar
de forma gratuita para PC Windows aquí: [Descargar el juego aquí]
Y se puede encontrar más información, capturas de pantalla y videos sobre
el juego y su desarrollo aquí: [Ver online]
Para más información sobre el deporte de Slalom en silla de ruedas y su
reglamento, puedes visitar la página web de la Federación Española de
Deportes de Personas con Parálisis Cerebral y Lesión Cerebral:
http://www.fedpc.org/
Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y
usabilidad, por Emmanuelle Gutiérrez y Restrepo
Es Experta en Accesibilidad en el Grupo de Investigación aDeNu, del
Departamento de Inteligencia Artificial de la Universidad Nacional de
Educación a Distancia (UNED), es Licenciada en Ciencias de la
Comunicación (Rama de Cine, Radio y Televisión), Master en
Comunicación en Sociedad y Problemas Sociales, Experto en
Comunicación e Imagen Corporativas; por la Universidad Complutense de
Madrid. Patrono y Directora General de la Fundación Sidar – Acceso
Universal, es activista de la accesibilidad informática desde 1995, y en
especial de la accesibilidad en Internet. Ponente invitado en congresos
nacionales e internacionales. Ha impartido numerosos cursos y seminarios
sobre accesibilidad en Argentina, Colombia, Chile, El Salvador, España,
México, Perú, Portugal, y Puerto Rico, entre otros países. Es Experto
Invitado en el Grupo de Trabajo Education & Outreach y en el de
Evaluation and Repair Tools del W3C-WAI, participó en el Grupo de
Trabajo para la redacción de las WCAG 1.0 y de la versión 2.0, y participa
activamente en otros grupos de interés relacionados con la web semántica.
Lo que desconocemos que conocemos sobre

accesibilidad y usabilidad
Introducción
El presente artículo se fundamenta en el estudio que fue la base para la
conferencia que impartí en el Congreso Internacional CAVA 2010 [CAVA
2010, 2010], que se celebró en Cartagena de Indias, del 1 al 3 de septiembre
de 2010. Mediante la comparación con las técnicas y prácticas habituales en
la creación de documentos de texto, y siguiendo los tipos de contenido que
suelen encontrarse en la mayoría de los sitios web hoy en día,
especialmente aquellos que han sido creados mediante un gestor de
contenidos, se analizan los criterios de conformidad que tienen su
equivalente en dichas prácticas habituales y que, por tanto, todo
desarrollador y diseñador conoce de antemano. De esta manera, veremos
cómo todos tenemos un conocimiento de la accesibilidad y la usabilidad,
que no sabíamos que teníamos.
El lector no ha de asustarse por las referencias y términos ciertamente
especializados del campo de la accesibilidad web, puesto que en definitiva
el resultado de la lectura de este artículo no hará más que proporcionarle
confianza y, quizás, algún conocimiento nuevo sobre la forma correcta de
estructurar y definir la presentación de un contenido que puede estar
destinado a la comunicación general o a la enseñanza, tanto por medios
“tradicionales” como los documentos en Word o PDF, como en formato
HTML para ser empaquetados como objetos de aprendizaje. Todo el estudio
se hace sobre los textos de las Pautas de Accesibilidad para el Contenido
Web 2.0 [WCAG 2.0] [W3C-WAI, 2009], teniendo en cuenta el documento
“How to meet WCAG 2.0” [W3C-WAI, 2008], el “Understanding WCAG
2.0” [W3C-WAI, 2008], y el extenso documento de “Techniques for
WCAG 2.0” [W3C-WAI, 2008b]; pero en este artículo nos limitaremos a
citar los números de los criterios, para que sólo aquellos más directamente
relacionados con la creación web y la revisión de su accesibilidad consulten
el texto original del estudio [Gutiérrez y Restrepo, 2010].
Los documentos anteriormente citados, pueden resultar realmente
complejos en un principio, pero su objetivo último es facilitar la
comprensión de aquello que hay que tener en cuenta a la hora de crear un
contenido web de manera que resulte fácil su utilización, comprensible su
contenido y satisfactoria su interacción; por parte de cualquier persona,
incluyendo a las personas mayores y con discapacidad, entre otros grupos
de usuarios que pueden encontrarse con ciertas limitaciones personales o
tecnológicas.
Utilizaremos para guiarnos una maqueta o “mockup” de un sitio web
ficticio, en la que hemos destacado cada uno de los tipos de contenido y
secciones que constituirán la web final.
Encabezado
En el encabezado encontramos una serie de elementos que no suelen
percibir la mayoría de los usuarios, pero sí lo hace uno de nuestros usuarios
preferidos y al que prestamos especial atención: Google y los demás robots
de búsqueda. Son elementos especialmente importantes para la indización y
localización de nuestros contenidos.
Idioma de la página
Cuando creamos un texto en un editor de textos como por ejemplo Word u
Office Writer, una de las primeras cosas que nos interesa hacer es definir en
qué idioma vamos a escribir, para que el editor pueda echarnos una mano
con avisos sobre posibles errores ortográficos o debidos al intento de
escribir rápidamente.
De igual manera, aunque no con el mismo propósito, al crear una página
web debemos indicar en qué idioma estarán los contenidos. Esto se hace en
el elemento <html> mediante el atributo lang. Hoy en día los Gestores de
Contenidos o CMS [Content Management System, por sus siglas en inglés]
facilitan esta tarea y, por tanto, es menos habitual encontrar páginas que no
tengan una indicación de idioma principal de la página.
La indicación de idioma principal es fundamental para que los robots de
búsqueda puedan indizar correctamente la página, los navegadores puedan
servir al usuario los contenidos en el idioma que haya indicado como
favorito [cuando el sitio ofrece los contenidos en varios idiomas y utiliza la
negociación de contenidos] y para que los usuarios de lectores de pantalla
obtengan una lectura con una pronunciación correcta.
Al indicar el idioma principal de la página estamos cumpliendo con el
criterio de conformidad 3.1.1 Idioma de la página.
Título
El título de cualquier obra es un elemento distintivo al que todo autor
dedica especial atención. En un contenido o recurso web es igualmente
importante pues permitirá identificar y distinguir el recurso y cada uno de
sus contenidos. Hace algún tiempo era bastante habitual encontrar páginas
cuyo título era: “place title here” o alguna expresión parecida que ponía
automáticamente el editor de HTML en el elemento <title> para que el
autor la reemplazara por el título adecuado para cada página. Hoy en día es
menos común gracias al uso de los CMS, pero por otro lado se está
extendiendo el mal hábito de que todas las páginas que constituyen un sitio
o recurso lleven exactamente el mismo título, el nombre del sitio o empresa
que lo publica, que incluye automáticamente el CMS.
El título de cada página o contenido ha de ser distintivo y, si bien conviene
que haga referencia al propietario del sitio, ha de ser distinto en cada una de
ellas refiriéndose concretamente a lo que el usuario encontrará en esa
página en especial. De esta manera será más fácil para el usuario encontrar
una determina sección o contenido en nuestra web.
Indicando un título adecuado para cada una de nuestras páginas, estaremos
cumpliendo con el criterio de conformidad 2.4.2 Titulado de páginas.
Elementos meta
Los elementos <meta> nos permiten transmitir información sobre la
información contenida en cada una de nuestras páginas. Por tanto, aunque
algunos de ellos puedan y deban contener exactamente la misma
información en todas las páginas, no es conveniente que todos esos
elementos sean exactamente igual en todas las páginas.
Al igual que cuando creamos un documento en un editor de textos
indicamos quién es el autor, de qué trata el documento y con qué palabras
clave está relacionado, desde las propiedades del documento; igualmente
debemos hacer al crear una página web utilizando los elementos <meta>.
La meta información que nos permite transmitir este elemento es muy
variada, va desde la indicación de tipo de caracteres que se utilizan en los
contenidos, hasta cada cuánto tiempo deben repasar la página los robots de
búsqueda para indizar nuevos contenidos en ella, pasando por quién o qué
entidad es la responsable de la página, qué palabras clave se asocian con sus
contenidos y una breve descripción de éstos.
El uso de los CMS ha facilitado que los autores incluyan en mayor medida
algunas de estas meta-informaciones. Aunque lamentablemente
encontramos habitualmente sitios en los que la descripción y las palabras
clave son las mismas en todas las páginas. Esto limita las posibilidades de
localización e indización de los contenidos.
Elementos link
Algunos desarrolladores o autores Web conocen bien el elemento <link> en
cuanto les permite indicar a los robots que no indexen determinada página,
y a los navegadores dónde se encuentra la o las hojas de estilo, pero poco
más. Muchos lo han descubierto al empezar a usar la sindicación o
adentrarse en el mundo de los cuadernos de bitácora [blogs], pues en ellos
se usa para identificar la relación entre entradas, los archivos, los temas, etc.
[Atom, 2005].
No vamos a pretender aquí que los desarrolladores realmente usan de forma
generalizada el elemento <link> en toda su capacidad y potencia para
incrementar la accesibilidad, como sería el caso si se usase para definir la
relación entre la página actual y el resto de páginas del sitio [Gutiérrez y
Restrepo, 2005]. Cumplirían con ello con algunas de las técnicas del criterio
de conformidad 2.4.8 Ubicación con el 3.1.3 Palabras inusuales y con el
3.1.4 Abreviaturas. Además se considera técnica recomendable para el
cumplimiento del criterio 2.4.5 Múltiples vías.
Pero al menos sí que se ha generalizado el uso de este elemento para indicar
la localización de la hoja de estilos y de los JavaScript, separando de esta
manera el contenido de los efectos de presentación visual y
comportamiento, lo que incrementa la accesibilidad de manera muy eficaz.
Estamos entonces cumpliendo con el criterio 1.3.1 Información y
relaciones.
Cabecera visual
En la cabecera de una página web se suelen colocar contenidos distintivos
como el logo y nombre del sitio, institución o empresa, enlaces de ayuda al
usuario, como al mapa del sitio, a la página de contacto, etc.; y algún lema o
slogan y el buscador. Estos contenidos tienen su equivalente en un
documento de texto, por ejemplo el mapa con el índice o tabla de
contenidos para todo el sitio, y el logo, nombre de la empresa o institución
y lema suelen crearse también en la cabecera del documento de texto.
Pero en las páginas web que pretenden ser accesibles se añade un elemento
que no existe en un documento de texto: Un enlace que permite saltar todos
los elementos comunes entre las páginas del sitio e ir directamente al
contenido principal de cada una. Esta práctica viene siendo ya habitual en
muchos sitios, en parte por el efecto emulador de diseñadores de renombre
y en parte porque lo facilitan los CMS de hoy en día. Al incluir dicho
enlace estamos cumpliendo con el criterio de conformidad 2.4.1 Evitar
bloques.
Dicho enlace suele formar parte de lo que podríamos llamar “menú de
navegación global”, del que hacen parte también los enlaces al mapa del
sitio, forma de contacto e información sobre accesibilidad.
Menú de navegación global

Con el menú de navegación global, incluido ya en la mayoría de los
“themes” o plantillas de los CMS, y fácilmente configurable por parte de
los autores, estaríamos cumpliendo con varios criterios de conformidad: El
3.2.3 Navegación coherente y también puede ser que con el criterio 3.2.4
Identificación coherente; por ejemplo, en el caso de un manual o de un
objeto de aprendizaje que ofrece unos enlaces para ir a la página anterior y
la siguiente, siempre localizados en el mismo sitio y consistentes. En un
documento en formato texto, esta funcionalidad de navegación entre
páginas la ofrece la propia aplicación.
Mapa del sitio, contacto y ayuda

Como hemos dicho, el mapa del sitio sería el equivalente al índice o tabla
de contenidos de un documento de texto, y es importante ofrecerlo pues
incrementa la usabilidad y la accesibilidad. Cada vez son más los sitios web
que ofrecen un mapa del sitio, con lo cual se cumple con el criterio de
conformidad 2.4.5 Múltiples vías y del 2.4.8 Ubicación así como con el
3.1.3 Palabras inusuales. Otra cosa es cómo se crea y presenta ese mapa del
sitio, pero eso lo trataremos más adelante.
En todo documento se ofrecen unos datos de contacto más o menos
extensos y variados dependiendo del tipo de documento que se trate. De
igual forma, en un sitio web hemos de ofrecer distintos modos de contactar
con los responsables del sitio y en especial con el webmaster. De este modo
estaremos facilitando al usuario la posibilidad de solicitar formatos
alternativos de la información presentada y de avisar al webmaster sobre
cualquier dificultad que encontremos en el sitio. Estaremos entonces
aplicando una de las técnicas recomendadas para el cumplimiento de la
Pauta 3.1 Legible.
En un documento de texto se suele incluir un apartado de introducción en el
que se describe la conformación general del documento, indicando la
localización de determinados apartados o elementos especiales. En un sitio
web se suele ofrecer una página de ayuda al usuario, enlazada desde este
menú de navegación global, en la que se suele hacer eso mismo. Al
proporcionar instrucciones al usuario, ya sea en esta página de ayuda o en
cualquier otro apartado de la web, es fundamental que no sea necesario
depender de la percepción de características sensoriales para poder
comprender las instrucciones. Esto es, las instrucciones han de cumplir con
el criterio de conformidad 1.3.3 Características sensoriales.
Logo y nombre del sitio

Al igual que en los documentos que se presentan en papel membrete de una
compañía o institución, en las páginas web se suele colocar el nombre y el
logo del responsable del sitio o recurso. Con el uso de los CMS se ha
generalizado un poco más el cumplimiento de un requisito de accesibilidad
básico como es el de indicar mediante una alternativa textual qué significa
cada imagen. Si bien es verdad que no siempre se cumple el criterio
satisfactoriamente. Pero vamos a suponer que el desarrollador conoce y ha
entendido el criterio de conformidad 1.1.1 Contenido no textual.
Pero siempre será recomendable, no sólo por accesibilidad sino por razones
de posicionamiento, que el nombre del sitio lo incluyamos mediante texto y
no mediante una imagen. Cosa que se facilita mucho hoy en día gracias a la
progresiva implementación de CSS3 [W3C, 2010] en los navegadores, lo
que nos permite incluir distintas fuentes y fuentes especiales en nuestras
web con variados efectos de presentación, incluso. Y en un futuro cada vez
más próximo tendremos la posibilidad de usar SVG [W3C, 2010b] para
conseguir el efecto que queremos de manera accesible.
Buscador
En un documento de texto, el buscador lo proporciona la aplicación
mediante la cual examinamos el documento, pero en un sitio web debe ser
el autor el que proporcione mecanismos de búsqueda. Y esos mecanismos
de búsqueda deben ser ajustables a las necesidades y preferencias del
usuario. Si así lo hacemos, estaremos cumpliendo con una de las técnicas de
aplicación del criterio de conformidad 2.4.5 Múltiples vías, que ya hemos
mencionado antes. Proporcionar un mecanismo de búsqueda incrementará
la usabilidad y la accesibilidad de nuestro sitio, siempre y cuando el listado
de resultados se ofrezca también de manera accesible, es decir, bien
estructurado.
Puesto que la interfaz para la búsqueda es un campo de formulario, se ven
aquí implicados todos los criterios relacionados con este tipo de elementos,
y habremos de aplicar la Pauta 3.3 Entrada de datos asistida: Ayudar a los
usuarios a evitar y corregir los errores, en sus distintos grados de
accesibilidad según sea el caso.
Además, habremos de aplicar las técnicas suficientes para cumplir con el
criterio de conformidad 1.3.1 Información y relaciones, el 2.4.3 Orden del
foco, el 2.4.7 Foco visible, y el 4.1.2 Nombre, función, valor.
Contenido principal
Llegamos por fin al contenido principal del recurso o página, y en él
encontraremos una serie de elementos comunes y no comunes a un
documento de texto. Por ejemplo, las “migas” no son un elemento común a
los documentos de texto ya sean comerciales o científicos, pero los
encabezados o títulos y subtítulos, las listas, las citas, las imágenes y
gráficas, y las tablas; sí son comunes a muchos tipos de documentos de
texto. Veamos pues todos ellos:
Las migas
Otro elemento funcional que favorece la accesibilidad y que se ha
generalizado ampliamente gracias al uso de CMS es la inclusión de las
llamadas “migas de pan” o rastro que indica al usuario dónde se encuentra
respecto al árbol de navegación del sitio.
Proporcionar esta “migas” es una de las técnicas suficientes para el
cumplimiento del ya mencionado criterio de conformidad 2.4.8 Ubicación.
Y al crear esas migas mediante una lista, estaremos también dando
cumplimiento a una de las técnicas suficientes para el cumplimiento del
criterio 1.3.1 Información y relaciones.
Encabezados de sección
Nuestro documento, sea del tipo que sea, habrá de estructurar la
información de manera que sea más fácil comprender su contenido. Para
ello, crearemos tantas secciones como sea conveniente, y cada una de ellas
llevará un título y, posiblemente, uno o varios subtítulos.
Al estructurar el documento de esta manera, estaremos cumpliendo con
varios criterios de conformidad. Aunque hay que decir, que realmente no se
ve una aplicación correcta de los mismos de manera generalizada. Sobre
todo es muy habitual encontrar fallos en cuanto al orden correcto de
anidación de los elementos de encabezado y a la función que han de
cumplir. Y lamentablemente esto ocurre sobre todo con el elemento de
encabezado de primer nivel, que en muchos “themes” o plantillas se genera
en todas las páginas para indicar el nombre del sitio en la cabecera.
También es muy habitual no encontrar el título del contenido principal
marcado con un elemento de encabezado de primer nivel.
Si lo hacemos correctamente estaremos cumpliendo con los siguientes
criterios: El ya mencionado 1.3.1 Información y relaciones, el 2.4.6
Encabezados y etiquetas, y con el 2.4.10 Encabezados de sección.
Nivel de lectura
Tanto para los encabezados o títulos, como para el contenido en general es
importante tener en cuenta el nivel de lectura necesario para comprender el
texto. Dependiendo de cuál sea el público o audiencia del sitio, el nivel de
lectura habrá de ajustarse llegando incluso, para el caso de sitios o
contenidos dirigidos a personas que puedan tener ciertas deficiencias
cognitivas o de aprendizaje, a requerir que se ofrezcan alternativas que
apliquen las “pautas para la lectura fácil” [ILSMH, 1998]. Para aquellos
dirigidos a la ciudadanía en general y en general para todos los sitios que
pretendan conseguir el más alto grado de accesibilidad, se ha de cumplir
con el criterio de conformidad 3.1.5 Nivel de lectura: Cuando un texto
requiere un nivel de lectura más avanzado que el nivel mínimo de
educación secundaria, se proporciona un contenido suplementario o una
versión que no requiere un nivel de lectura mayor a ese grado de educación.
[Nivel AAA].
Pero existen también una serie de técnicas recomendadas, que
probablemente los autores pondrán en práctica sin saber que se tratan de
técnicas para el cumplimiento de la Pauta 3.1 Legible: Hacer que los
contenidos textuales resulten legibles y comprensibles, como son: no
justificando completamente los textos, justificándolos a la izquierda
[cuando el idioma usado se lee de izquierda a derecha], limitando el ancho
de las columnas, limitando el uso de estilos a unos pocos y realmente
necesarios, haciendo que los enlaces se distingan claramente del resto de
textos, proporcionando ilustraciones del texto mediante gráficas, videos,
versión hablada o símbolos [por ejemplo cuando usamos íconos asociados a
cada elemento de un menú], no usando el blanco absoluto como fondo para
el texto negro, respetando la ortografía y la ortotipografía del idioma en que
se escribe; entre otros. Todos ellos generalmente sugeridos desde la
usabilidad.
Es práctica habitual y regla ortotipográfica que cuando incluimos términos
o frases en un idioma distinto al general del documento, los marquemos e
indiquemos claramente mediante el uso de la cursiva. También, es
importante marcar esos textos con el cambio de idioma pertinente, para que
el revisor ortográfico de la aplicación pueda hacer bien el trabajo y no nos
llame la atención sobre un texto creyendo que está en el idioma general del
contenido, cuando está en otro. En un recurso web no es suficiente con
modificar la forma de presentación del texto sino que contamos con un
medio para indicar a cualquier aplicación el idioma en el que está ese
término frase. Esto contribuye de manera fundamental a la accesibilidad [en
este caso a la comprensión] por parte de varios grupos de usuarios y a la vez
mejorará la indización de nuestros contenidos. Estaríamos cumpliendo con
el criterio de conformidad 3.1.2 Idioma de las partes.
También con el uso de los CMS podemos esperar, en cierta medida, que nos
ayuden a cumplir con el criterio de conformidad 1.4.8 Presentación visual:
En la presentación visual de bloques de texto, se proporciona algún
mecanismo para lograr lo siguiente: [Nivel AAA]
Los colores de fondo y primer plano pueden ser elegidos por el usuario.
El ancho no es mayor de 80 caracteres o signos [40 si es CJK].
El texto no está justificado [alineado a los márgenes izquierdo y derecho a
la vez].
El espacio entre líneas [interlineado] es de, al menos, un espacio y medio
dentro de los párrafos y el espacio entre párrafos es, al menos, 1.5 veces
mayor que el espacio entre líneas.
El texto se ajusta sin ayudas técnicas hasta un 200 por ciento de modo tal
que no requiere un desplazamiento horizontal para leer una línea de texto en
una ventana a pantalla completa.].
Los puntos 1 y 5 se consiguen con la separación entre contenido y
presentación, y el uso de unidades relativas en vez de fijas para la
indicación de tamaños de texto y bloques contenedores o capas. Y el resto
son fácilmente alcanzables mediante la definición de estilos y son de
aplicación común en la creación de documentos de texto de tipo
divulgativo. Todos ellos contribuyen a la legibilidad del contenido y son
generalmente solicitados desde la perspectiva de la usabilidad.
Párrafos, listas, negritas, cursivas, secuencia de

lectura, etc.
Los editores de texto ofrecen a los autores la posibilidad de marcar
apropiadamente tanto los párrafos, como los elementos de una lista, como
los textos destacados que se representarán en negrita o cursiva, etc. Aunque
la mayoría de los usuarios utilizan las opciones de formato directo que
aparecen como botones en vez de los estilos definidos para la plantilla que
estén usando; lo cual crea serios problemas de accesibilidad. De la misma
manera, en la creación de un documento web, lamentablemente
encontramos muchos sitios en los que los textos aparecen sin marcar
apropiadamente, muchas veces puestos directamente dentro de una capa y
tan sólo, separados por el elemento que no transmite suficiente
información sobre dónde empieza un párrafo y termina otro. Los elementos
para destacar palabras o frases que se representan visualmente en los
navegadores con texto en negrita o cursiva, también se utilizan
espuriamente y no para destacar textos que realmente merezcan tener un
énfasis o énfasis fuerte. Pero los autores de documentos de texto que ya
estén acostumbrados a crear documentos “comme il faut” tienen ya
integrada en sus hábitos de trabajo la costumbre de marcar apropiadamente
cada tipo de texto.
Cumplirán entonces con el criterio ya citado 1.3.1 información y relaciones,
y con varias de sus técnicas suficientes, y en algunos casos será necesario
también cumplir con el requisito de conformidad 1.3.2 Secuencia
significativa.
Citas y textos citados

También en los documentos en general son de uso común las citas y
bloques de texto citado, por lo que los autores estarán más o menos
familiarizados con la importancia de destacar tanto visual como
estructuralmente este tipo de contenidos. En un recurso o documento web,
contamos con la posibilidad y el deber de hacerlo también de manera muy
precisa. Deberemos cumplir con el ya citado criterio de conformidad 1.3.1
Información y relaciones, pero en este caso aplicaremos la Técnica General
115, que nos indica que debemos utilizar elementos de marcado
significativos para identificar la estructura, y la técnica de HTML que nos
pide utilizar marcado significativo para indicar el texto especial o que deba
enfatizarse. Hoy en día aún algunas plantillas de los CMS cometen el error
de utilizar el marcado de bloques de texto de manera espuria.
Abreviaturas y palabras inusuales

De todos es conocido que al crear un documento cualquiera la primera vez
que se utiliza una forma abreviada [abreviatura o acrónimo] de indicarse su
significado en su forma expandida, y de la misma manera debe hacerse en
un recurso o documento web, pero también contamos con mecanismos para
identificarlas cada vez que aparecen, y ofrecer a los usuarios un modo de
recordar su significado. Haciendo esto estamos cumpliendo con el criterio
3.1.4 Abreviaturas.
Cuando en un documento se utiliza un término de manera poco usual o que
tiene un significado distinto según el contexto del documento al que pueda
tener en otros contextos, generalmente se proporciona una explicación
sobre este extremo ya sea mediante un glosario o mediante una nota a pie
de página. Si queremos conseguir el más alto grado de accesibilidad en un
recurso web, hemos de cumplir con el criterio 3.1.3 Palabras inusuales: Se
proporciona un mecanismo para identificar las definiciones específicas de
palabras o frases usadas de modo inusual o restringido, incluyendo
expresiones idiomáticas y jerga. [Nivel AAA]. Este criterio nos ofrece
varias técnicas que podemos utilizar y, aunque no me atrevo a afirmar que
sea una práctica generalizada, al menos sí que es conocida como principio
general en la creación de cualquier documento.
Enlaces o hipervínculos
En un documento de texto extenso pueden utilizarse marcadores para
identificar puntos o secciones con las cuales se va a enlazar otro contenido
al citarlas. En una web los enlaces o hipervínculos son elementos esenciales
y, por tanto, habremos de tener especial atención con ellos. Como principio
general han de ser distinguibles del resto de contenidos, lo que es un
principio básico de usabilidad, y con ello cumpliremos con el criterio 1.4.1
Uso del color, pero también ha de poderse deducir claramente su propósito
u objetivo ya sea que formen parte de un contexto o que se encuentren
aislados. Cumpliremos entonces con los criterios 2.4.4 Propósito de los
enlaces (en contexto y con el 2.4.9 Propósito de los enlaces solo enlaces).
Las técnicas suficientes para cumplir con estos criterios de conformidad no
están tan ampliamente generalizadas como sería de esperar, pero dado que
la primera ley de Internet “copiaos los unos a los otros” se sigue a rajatabla,
su generalización se hará seguramente de manera exponencial en cuanto los
diseñadores implemente de forma masiva las WCAG 2.0.
Tablas
En bastantes tipos de documentos de texto es habitual tener que incluir
tablas de datos, y tanto al crear un documento de este tipo como al crear una
página o recurso web es fundamental dar el formato apropiado a cada uno
de los tipos de datos que se incluyan en la tabla, especialmente es
importante establecer las relaciones entre los datos y los encabezados a los
que pertenecen. Los editores de texto facilitan esta tarea, aunque no es muy
habitual ver tablas bien marcadas, de lo que se deduce que los usuarios no
suelen tener un conocimiento muy profundo de las opciones de
configuración de documentos que les ofrece su editor.
Aquellos que sí aprovechan todas las posibilidades de estructuración de
contenidos de su editor, tienen muy fácil comprender y cumplir con el
criterio de cumplimiento, ya mencionado, 1.3.1 Información y relaciones,
para el que hay una serie de técnicas suficientes directamente relacionadas
con la creación de tablas, como el uso del atributo “caption”, para asociar la
tabla con su título, el atributo “summary”, para dar una visión general de la
disposición de su contenido, y los atributos “scope”, “id” y “headers” para
asociar los datos en celdas con las celdas de encabezado.
Sintaxis
Una cuestión esencial en la creación de todo documento es revisar la
gramática y ortografía del mismo. Hemos hablado ya de la importancia de
revisar la ortografía y la ortotipografía, pero también la gramática es
fundamental. De igual manera, en la creación de un recurso o página web es
muy importante revisar la sintaxis del código fuente. Cumplimos así con el
criterio de conformidad 4.1.1 Procesamiento.
Conclusiones
Con los conocimientos básicos para crear un documento de texto, bien
formateado, legible y comprensible para nuestros destinatarios,
conseguimos cumplir con 32 de los 61 criterios de conformidad de las
WCAG 2.0. Es decir, cumplimos con el 52% de las pautas de accesibilidad
para el contenido web.
De los 25 criterios de conformidad de nivel A, cumplimos con 15, lo que
significa cumplir con el 60% de ellos.
De los 13 criterios de conformidad con nivel Doble A, cumplimos con 8, lo
que significa cumplir con el 61,5% de ellos.
De los 23 criterios de conformidad de nivel Triple A, cumplimos con 9, lo
que significa cumplir con 39% de ellos.
Pero lo más importante a tener en cuenta es que si nuestra página o recurso
web es sencillo, no contiene elementos multimedia, contenidos dinámicos,
ni exige la entrada de datos por parte del usuario que supongan información
sensible de tipo legal o bancaria, con estas simples prácticas ya conocidas
por todos y tan sólo prestando atención al contraste de color, tendremos una
web con un muy alto grado de accesibilidad, pues los puntos que están
recogidos aquí se refieren todos ellos a esos tipos de elementos y
funcionalidades.
En definitiva, como hemos visto, la accesibilidad web no exige que
hagamos nada extraño, no hacen falta conocimientos que no sean aplicables
a otros órdenes de nuestra vida, y sus requisitos son todos de puro sentido
común para dar la oportunidad a todos los humanos de participar en la
Sociedad de la Información y del Conocimiento de manera equitativa.
Además, cumplir con los criterios de conformidad no mencionados en este
documentos no es difícil y está al alcance de todo desarrollador y diseñador
actual, cualquiera que sea la tecnología que haya decidido utilizar para crear
su documento o recurso web.
Referencias
Atom, 08/07/2005. Link Tag Meaning, Recuperado el 08/08/2010, de
Intertwingly: [Ver en línea Link Tag Meaning]
CAVA 2010, Página principal de CAVA 2010, Recuperado el
03/03/2011, de CAVA 2010: [Ver en línea CAVA 2010]
ILSMH, 06/1998, Pautas de estilo: Sidar. Recuperado el 08/08/2010,
de Sidar: [Descargar PDF]
W3C, 19/07/2010, Cascading Style Sheets. Current Work. Recuperado
el 08/08/2010, de W3C: [Ver en línea CSS]
W3C. 2010, Scalable Vectors Graphic. Recuperado el 08/08/2010, de
W3C: [Ver en línea W3C Vector]
W3C-WAI, 01/12/2008, How to meet WCAG 2.0. Recuperado el
10/08/2010, de W3C: [Ver en línea W3C-WAI]
W3C-WAI, 11/12/2008, Techniques for WCAG 2.0. Recuperado el
10/08/2010, de W3C: [Ver en línea W3C-WAI técnicas]
W3C-WAI, 11/12/2008, Understanding WCAG 2.0. Recuperado el
10/08/2010, de W3C: [Ver en línea W3C-WAI Understanding]
W3C-WAI, 15/12/2009, Traducción WCAG 2.0. Recuperado el
10/08/2010, de SIDAR: [Ver en línea traducción W3C - SIDAR]
Capítulo 12: Ergonomía física y cognitiva: los sistemas sensoriales
humanos y la evaluación ergonómica de interfaces, por Sebastián Betti
Ingeniero de sistemas, comenzó su carrera en la industria de las
aplicaciones de telefonía y en la actualidad lidera el desarrollo de portales
web en Petrobras Argentina. Es profesor asistente de la Especialización en
Usabilidad y Accesibilidad de la Universidad Tecnológica Nacional y
coordinador de español en el proyecto interlingüístico del sitio
www.ted.com.
Más información:
Twitter: @se6as
Ergonomía física y cognitiva: los sistemas

sensoriales humanos y la evaluación
ergonómica de interfaces
Introducción
La medida del grado en que las personas podemos aplicar una herramienta
de manera exitosa en la consecución de un propósito pretendido, nos ha
acompañado desde tiempos inmemoriales. Primero fue el homo habilis que
con su herramienta precaria, la piedra, perseguía su idea de fuego. Luego,
hace más de dos milenios fue Vitruvio 1 en su tratado “De Architectura”
quien afirmó que la arquitectura descansa en tres pilares: la Firmeza
(firmitas), la Belleza (venustas) y la Utilidad (utilitas). Y, salvando las
distancias, incluso los programas informáticos pueden ser analizados desde
esta tríada vitruviana. [Betti, 2008]. Otros enfoques del diseño más
contemporáneos se centran en el estudio de una suerte de homo
ergonomicus [Keller y Stappers, 2005], poseedor de unas características
físicas condicionantes del mismo. Y, en este sentido, probablemente la
imagen más famosa del estudio de las proporciones del cuerpo humano sea
el Hombre de Vitruvio 2 [Wakeford, 2004] de Leonardo da Vinci. De
hecho, ese fue el ideal de la pintura occidental durante varios siglos, y fue la
base expresiva de medidas ergonómicas como el “modulor” de Le
Corbusier [Le Corbusier, 1961]; una formalización del hombre ideal con la
intención primaria de derivar todo el diseño del mundo a partir de la escala
humana.
Dentro de la psicología, la ergonomía cognitiva es la disciplina que estudia
los aspectos conductuales y cognitivos de la relación entre el hombre y los
elementos físicos y sociales del ambiente, cuando esta relación está
mediada por el uso de artefactos. [Cañas y Waern, 2001]
A nivel sensorio-motor, fue el neurólogo canadiense Wilder Penfield quien
publicó en 1950 una representación del esquema corporal humano
construido según la cantidad de estímulos que recibe el córtex cerebral.
[Dawkins, 2008] El homúnculo sensorial de Penfield es un breve resumen
visual de las habilidades sensoriales humanas y, en particular, de las de la
mano. De allí la importancia de estas investigaciones para aplicar los
resultados en evaluaciones hápticas de interfaces y en el diseño de
aplicaciones, productos y servicios que aprovechen la motricidad y
sensibilidad de la mano en las interacciones, como el móvil Braille de
Sumit Dagar 3 o las haptografías de Katherine Kuchenbecker 4.
Otro caso interesante es el guante móvil Lorm ideado en Berlín por el
equipo de investigadores del Design Research Lab 5. Se trata de un
dispositivo de comunicación y traducción para sordos-ciegos. Traduce del
alfabeto táctil Lorm 6 a texto digital y viceversa. Este proyecto es un
ejemplo de patrones de retroalimentación vibrotáctil que permiten al
usuario percibir los mensajes de texto entrantes, en el dorso de la mano. Y
por la misma vía generar mensajes en Lorm, desde la palma de la mano,
que se traducen en textos salientes.
Evaluación ergonómica de interfaces

Existe una serie de criterios para la evaluación ergonómica de interfaces,
que minimiza las ambigüedades en la identificación y clasificación de las
cualidades y problemas relacionados con la ergonomía de sistemas
interactivos. Para profundizar en este tipo de evaluaciones, analizaré el
trabajo de la dupla de investigadores franceses Christian Bastien y
Dominique Scapin [Bastien y Scapin, 1993] que en 1993 propusieron un
conjunto de 8 criterios ergonómicos principales que, a su vez, se subdividen
en 18 subcriterios y criterios elementales.
El objetivo de los estudios ergonómicos centrados en el individuo consiste
en reducir la carga del esfuerzo mental, visual y físico: 1) reduciendo
entradas innecesarias; 2) ofreciendo valores default; 3) exhibiendo mensajes
de error de fácil comprensión; 4) proveyendo atajos de ayuda de fácil
acceso; 5) brindando feedback inmediato de las acciones realizadas en la
computadora, hayan sido concluidas o no; 6) adecuando elementos de
acuerdo con su funcionalidad o 7) siguiendo algún criterio lógico
(intuitividad) por ubicación o por formas y colores, de acuerdo a su
legibilidad, etc.
La siguiente tabla resume los criterios de conformidad para la evaluación
ergonómica de interfaces humano-computadora.
Detalle y razón de ser de los criterios

1. Guía del usuario
La guía del usuario se refiere a los medios disponibles para aconsejar,
orientar, instruir y guiar a los usuarios en sus interacciones con la
computadora (mensajes, alarmas, etiquetas, etc.) desde un punto de vista
léxico.
Una buena guía facilita el aprendizaje y el uso de un sistema permitiéndole
a los usuarios: 1) saber en cada momento dónde están en una secuencia de
interacciones, o en la consecución de una tarea; 2) saber cuáles son las
posibles acciones y sus consecuencias; y 3) obtener información adicional
(posiblemente a pedido).
Una buena guía es un excelente catalizador del modelo de la articulación de
preferencias [Chernev, 2003] que sostiene que cuando uno sabe
exactamente lo que busca, más opciones es mejor porque hay más
probabilidades de encontrar exactamente lo que se busca. Luego elegir es
fácil. Si no se tiene esto en claro, muchas opciones producen parálisis.
La facilidad de aprender y la facilidad de uso, producto de una buena guía,
lleva a mejores rendimientos y menos errores. Tanto es así que el aspecto
más importante a tener en cuenta si se quiere facilitar el aprendizaje
exploratorio es diseñar la interfaz de tal manera que los objetos que el
usuario encuentre en ella puedan ser relacionados fácilmente con la tarea
que se quiere aprender a realizar. De la similitud semántica entre la tarea
que el usuario quiere realizar y la etiqueta que aparece en la interfaz,
depende el tiempo necesario para aprender a realizar dicha tarea. [Soto,
1999]
1.1 Prompting (articulación de acciones)
Se refiere a los medios disponibles para guiar a los usuarios hacia acciones
específicas o para ayudarles a conocer las alternativas cuando hay varias
acciones posibles dependiendo del contexto. También tiene que ver con la
información de estado, es decir, información actual del estado o contexto
del sistema, así como con la información de ayuda y de su accesibilidad.
Una buena articulación de acciones guía al usuario y le evita, por ejemplo,
tener que aprender una serie de comandos. Le permite conocer exactamente
el modo actual, si está en un diálogo, y también las acciones disponibles en
ese contexto. En definitiva, le ayuda a navegar la aplicación o sistema y a
reducir los errores.
1.2 Agrupamiento/Distinción de elementos
Este criterio está relacionado con la organización visual de los componentes
de información entre sí. Tiene en cuenta la topología (ubicación) y algunas
características gráficas (formato) para indicar las relaciones entre varios
elementos mostrados, para indicar si pertenecen a una clase o para indicar
diferencias entre clases. Este criterio también tiene que ver con la
organización de elementos dentro de una clase.
El agrupamiento se subdivide en dos subcriterios: agrupamiento por
ubicación y agrupamiento por formato.
1.2.1 Agrupamiento por ubicación
El agrupamiento por ubicación tiene en cuenta la ubicación relativa de los
elementos para indicar si éstos pertenecen a una clase determinada, o para
indicar las diferencias entre clases. También está emparentado con la
ubicación relativa de los elementos dentro de una clase.
Los usuarios detectarán los distintos elementos con más facilidad si éstos se
presentan en forma organizada (por ejemplo, en orden alfabético, por
frecuencia de uso, etc.) Además, esto mejorará el aprendizaje y hará más
fácil recordar los elementos.
1.2.2 Agrupamiento por formato
El agrupamiento por formato se relaciona con los aspectos gráficos
(formato, color, etc.) que indican si los elementos pertenecen a una clase
dada, o que indican distinciones entre diferentes clases, o de distintos
elementos dentro de una clase dada.
Será más fácil para el usuario conocer las relaciones entre elementos o
clases de elementos si se ilustran sus similitudes o diferencias con distintos
formatos. Esto mejorará el aprendizaje y hará más fácil recordar los
elementos.
1.3 Feedback inmediato
Este subcriterio está relacionado con las respuestas a las acciones del
usuario. Estas acciones pueden ser entradas simples o transacciones más
complejas como comandos en lote. En cualquier caso el sistema debe
brindar una respuesta rápida, en tiempo y forma, para las distintas
transacciones. Esta respuesta debe, además, proveer información sobre la
transacción requerida y su resultado.
La calidad y la velocidad de respuesta son dos factores importantes para
forjar la confianza y la satisfacción del usuario así como para la
comprensión del diálogo. Estos factores le permiten al usuario entender
mejor el funcionamiento del sistema.
La ausencia de feedback o la demora en el mismo puede desconcertar al
usuario. Y si éste sospecha que ha ocurrido una falla en el sistema, podría
emprender acciones potencialmente perjudiciales para los procesos en
curso.
1.4 Legibilidad
La legibilidad hace alusión a las características léxicas de la información
presentada en pantalla que puede dificultar o facilitar la lectura de esta
información (brillo de la letra, contraste entre los caracteres y el fondo,
tamaño de la letra, espaciado, interlineado, sangrías, etc.)
2. Carga de trabajo
La carga de trabajo se relaciona con los elementos de la interfaz que
desempeñan un papel en la reducción de la carga cognitiva, mental o
perceptual del usuario, y en el aumento de la eficiencia del diálogo. Se
utiliza el término carga mental para referirse a la porción de recursos de
procesamiento que una persona necesita para realizar una tarea [Norman y
Bobrow, 1975; O’Donnell, 1986].
Cuanto más alta es la carga de trabajo, más alta la probabilidad de cometer
errores. Y, a su vez, cuanto menos distracciones experimente el usuario,
producto de información innecesaria, más posibilidades tendrá de terminar
su tarea con eficiencia. [Krug, 2005] Por otra parte, cuanto más cortas sean
las acciones, más rápida serán las interacciones.
2.1 Brevedad
El criterio de brevedad se refiere a la carga cognitiva o perceptual tanto de
las entradas como de las salidas y de los conjuntos de entradas (por
ejemplo, el conjunto de acciones necesarias para lograr un objetivo o tarea).
Tiene que ver con el objetivo de limitar la lectura, la carga de entrada y la
cantidad de pasos de una acción.
El criterio de brevedad tiene dos subcriterios: concisión y acciones
mínimas.
2.1.1 Concisión
El criterio de concisión tiene que ver con la carga cognitiva y perceptual
referente a las entradas y salidas. Y dado que la memoria de corto plazo es
limitada, cuando se almacena una unidad de información en dicha memoria,
si no se hace nada con ella, desaparece después de un intervalo de
aproximadamente 20 segundos. [Peterson y Peterson, 1959]
Por otro lado, Huguenard y colaboradores [Huguenard, 1997] demostraron
que, debido a las limitaciones en capacidad y procesamiento de la memoria
de corto plazo, se cometen frecuentemente dos tipos de errores: 1) errores
por pérdida de información, cuando el usuario olvida la información sobre
lo que debe hacer; 2) errores de elección, cuando el usuario elige una
opción incorrecta. En consecuencia, cuanto más cortas las entradas, menor
es la probabilidad de cometer errores. Además, cuanto más sucintos son los
elementos, más cortos son los tiempos de lectura.
2.1.2 Acciones mínimas
El subcriterio de acciones mínimas está relacionado con la carga de trabajo
respecto de la cantidad de acciones necesarias para lograr un objetivo o una
tarea. Se trata de limitar tanto como sea posible los pasos que deben realizar
los usuarios.
Cuanto más numerosas y complejas sean las acciones necesarias para
alcanzar un objetivo, mayor será la carga de trabajo y, en consecuencia,
mayor el riesgo de cometer errores.
Hay otro factor que interviene en este subcriterio y es que existe un límite a
la cantidad de información que puede retenerse en la memoria de corto
plazo. Se estima que esta cantidad es de entre 4 y 7 unidades de
información. [Miller, 1956; Cowan, 2001]
2.2 Densidad de información
La densidad de información se refiere a la carga de trabajo del usuario
desde una perspectiva perceptual o cognitiva en referencia al conjunto de la
información presentada al usuario en vez de a cada elemento en particular.
La mayoría de las veces, el rendimiento del usuario se ve perjudicado si la
densidad de información es demasiado alta o demasiado baja: en estos
casos, los errores se vuelven más probables. Entonces, los elementos que no
tienen relación con la tarea deberían eliminarse. Las buenas prácticas
establecen que puestos a elegir entre dos soluciones, siempre debe elegirse
la solución más sencilla. Es lo que se conoce como lex parsimoniae, o
principio de parsimonia.
Debe minimizarse la carga mental sobre el usuario. Debe evitarse la
memorización de largas listas de datos o procedimientos complicados. Los
usuarios no deberían realizar actividades cognitivas complejas si la tarea en
cuestión no lo requiere.
3. Control explícito
El control explícito tiene que ver tanto con el procesamiento de las acciones
explícitas del usuario como con el control que los usuarios tienen del
procesamiento de sus acciones en el sistema.
En ocasiones el usuario puede delegar el control en un agente que gestiona
la tarea en su nombre si esto reduce su carga cognitiva y da el resultado
esperado. Es el modelo principal-agente [Keys y Schwartz, 2007], en el
cual el principal (usuario) delega la tarea en el agente (interfaz) y disfruta
del proceso mientras el agente realiza la tarea para el principal.
Pero puede ocurrir que el resultado no sea el esperado y la delegación del
control produzca un desamparo aprendido [Seligman, Miller y Kurlander,
1975] Este modelo sostiene que gran parte de la frustración de los usuarios
surge de un sentimiento de desamparo ocasionada por eventos negativos
sobre los cuales la persona no tiene control. En esos casos, si los usuarios
definen explícitamente sus entradas y si estas entradas están bajo su control,
se minimiza la cantidad de errores, así como las ambigüedades y el nivel de
frustración. Es más, el sistema será más aceptado por el usuario si éste tiene
el control sobre el diálogo.
El control explícito se divide en dos subcriterios: acción explícita de usuario
y control de usuario.
3.1 Acción explícita de usuario
El criterio de acción explícita de usuario estudia la relación entre lo que la
computadora procesa y las acciones del usuario. Esta relación debe ser
explícita. Es decir, la computadora debe procesar sólo aquellas acciones
requeridas por el usuario y sólo cuando éste lo requiere.
Cuando lo que la computadora procesa es producto de acciones explícitas
del usuario, éste aprende y entiende mejor el funcionamiento de la
aplicación y se observan menos errores.
3.2 Control de usuario
El control de usuario se refiere al hecho de que el usuario siempre debería
tener el control del procesamiento del sistema (por ejemplo, interrumpir,
cancelar, pausar y continuar). Cada posible acción de usuario debería ser
predecible y deberían mostrarse las opciones adecuadas.
El control sobre las interacciones favorece el aprendizaje y, por ende,
disminuye la probabilidad de cometer errores. En consecuencia, la
computadora se vuelve más predecible.
Nótese que la acción explícita de usuario se diferencia del control de
usuario en que la primera se refiere al carácter explícito de las acciones
requeridas por los usuarios, mientras que el segundo se refiere a la
capacidad de control que el usuario debería tener sobre el proceso en curso.
4. Adaptabilidad
La adaptabilidad de un sistema se refiere a su capacidad de comportarse de
manera contextual y de acuerdo a las necesidades y preferencias del
usuario.
Cuanto más diversas las maneras de lograr una tarea dada, más probable es
que cada usuario particular encuentre una forma que le resulte apropiada,
una forma que aprenderá a dominar en el transcurso del aprendizaje. De
esto se desprende que para lograr un objetivo dado deben proporcionarse
procedimientos, opciones y comandos.
Además, una interfaz determinada puede no ser adecuada para todos sus
usuarios potenciales. Para evitar efectos negativos en los usuarios, la
interfaz debe adaptarse a ellos.
La adaptabilidad tiene dos subcriterios: flexibilidad y habilidad del usuario.
4. 1 Flexibilidad
La flexibilidad está relacionada con los medios disponibles para que el
usuario personalice la interfaz con el objeto de tener en cuenta sus
estrategias de trabajo o sus hábitos y los requerimientos de la tarea.
La flexibilidad se refleja en la cantidad de posibles maneras de lograr un
objetivo dado. En otras palabras, es la capacidad de la interfaz para
adaptarse a las necesidades particulares del usuario.
Cuanto más diversos sean los medios disponibles para realizar una tarea
dada, más probable es que los usuarios elijan uno de ellos y lleguen a
dominarlo en el transcurso del aprendizaje.
4.2 Habilidad del usuario
La habilidad del usuario tiene que ver con el grado de conocimiento de la
interfaz por parte del usuario. Los usuarios expertos e inexpertos tienen
distintas necesidades de información. Sería deseable brindarles a los
usuarios sin experiencia un modo guiado que les permita realizar tareas
paso a paso.
Para los usuarios experimentados, los diálogos con la computadora podrían
resultar aburridos y percibidos como que hacen más lentas las
interacciones; los atajos podrían permitir entonces un acceso más rápido a
las funciones del sistema.
Los diferentes niveles de interacción deberían tener en cuenta las
habilidades del usuario, pues con el correr del tiempo los usuarios pueden
tornarse expertos a medida que ganan experiencia de uso, o volverse menos
expertos luego de largos períodos de no usar la herramienta. Entonces, la
interfaz debería acomodarse a las variaciones en el grado de conocimiento
que el usuario tenga del sistema.
5 Manejo de errores
El manejo de errores se refiere a los medios disponibles para prevenir o
reducir los errores y para recuperarse ante la ocurrencia de los mismos. Los
errores se definen en este contexto como entrada inválida de datos, sintaxis
incorrecta de comandos, etc.
Las interrupciones provocadas por errores del usuario tienen consecuencias
negativas en las actividades del mismo. En general, este tipo de
interrupciones aumenta la cantidad de interacciones y perturba la
organización y la realización de la tarea. Al limitar la cantidad de errores, la
cantidad de interrupciones también se ve limitada. Por ende, el rendimiento
es mejor.
El manejo de errores tiene dos subcriterios: protección ante errores y
calidad de los mensajes de error.
5.1 Protección ante errores
La protección ante errores tiene que ver con los medios disponibles para
detectar y prevenir errores en el ingreso de datos, errores de comandos o
acciones con consecuencias destructivas.
Es preferible detectar errores antes de la validación que después dado que la
detección es menos perturbadora para el usuario.
5.2 Calidad de los mensajes de error
La calidad de los mensajes de error se refiere a la redacción y al contenido
de los mismos, es decir: su relevancia, legibilidad, la especificidad de la
naturaleza del error (sintaxis, formato, etc.) y las acciones necesarias para
corregirlo.
La calidad de los mensajes promueve el aprendizaje de los sistemas por
parte de los usuarios, indicándole al usuario las razones de sus errores, la
naturaleza de los mismos, y persigue el fin didáctico de enseñarle maneras
de prevenirlos o resolverlos.
5.3 Corrección de errores
La corrección está relacionada a los medios disponibles para que los
usuarios enmienden sus errores. Los errores son menos traumáticos si se los
puede corregir fácilmente y de inmediato.
6. Consistencia
La consistencia se refiere a la forma en que se mantienen las elecciones del
diseño de la interfaz (códigos, nomenclatura, formatos, procedimientos,
etc.) en contextos similares, y se diferencian al aplicarlos a contextos
diferentes.
Los procedimientos, etiquetas, comandos, etc. se recordarán con más
facilidad, serán mejor ubicados, reconocidos y usados si su formato,
ubicación y sintaxis son estables de una pantalla a otra, de una sesión a la
siguiente. En estas condiciones el sistema informático es más predecible, se
facilita su aprendizaje y la generalización, y se reduce la ocurrencia de
errores.
La falta de consistencia puede incrementar el tiempo de búsqueda de
manera considerable y es una razón importante para el rechazo por parte del
usuario.
7. Significado de los códigos
El significado de los códigos es un calificador de la relación entre un
término y/o signo y su referencia. Los códigos y los nombres son
significativos para los usuarios cuando hay una relación semántica fuerte
entre tales códigos y los elementos o acciones a los que refieren.
Cuando los códigos son representativos, recordarlos e identificarlos se hace
más fácil. Además, los códigos o nombres no significativos pueden
conducir a operaciones de usuario no apropiadas y, por lo tanto, a errores.
8. Compatibilidad
La compatibilidad hace referencia a la concordancia entre las características
del usuario (memoria, percepción, costumbres, habilidades, edad,
expectativas, etc.) y las características de la tarea por un lado y la
organización de la entrada, de la salida, y del diálogo para una aplicación
dada, por otro lado.
La compatibilidad también está relacionada con la coherencia entre
entornos y entre aplicaciones. La transferencia de información de un
contexto a otro es más rápida y más eficiente si el volumen de información
que requieren los usuarios para recodificarla es limitado.
Aumenta la eficiencia cuando: los procedimientos diseñados para realizar
una tarea son compatibles con las características psicológicas del usuario;
los procedimientos y las tareas se organizan respecto a las expectativas y
prácticas del usuario; cuando se reduce la cantidad de traducciones,
interpretaciones o referencias a la documentación.
Además, se observa una mejora en el rendimiento cuando la información se
presenta en forma usable de manera directa.
Conclusiones
En este capítulo he presentado brevemente un marco conceptual y algunos
trabajos realizados —principalmente en ergonomía cognitiva— en los
últimos cincuenta años. Analicé algunas características de los sistemas
sensoriales humanos y enumeré criterios ergonómicos necesarios para
realizar estudios ergonómicos centrados en el individuo. Dichos estudios
tienen como objetivo reducir la carga del esfuerzo mental, visual y físico de
las interfaces para, de ese modo, adaptarse mejor a las capacidades
humanas.
Presenté además proyectos como el móvil Braille de Sumit Dagar, el guante
Lorm de Gesche Joost o las haptografías de Katherine Kuchenbecker, por
citar solo algunos casos que muestran otras posibilidades de interacción.
Como afirma el futurista Vito di Bari, es momento de pasar de la era de las
tecnologías inteligentes a la era de las tecnologías sensibles: tecnologías
que se adapten a nuestros sentidos y se comporten en consecuencia. El
diseño de una buena herramienta debe satisfacer las necesidades del hombre
y al mismo tiempo amplificar las capacidades humanas, nuestras
potencialidades sensoriales y cognitivas, para convertir lo que podemos
hacer en lo que queremos hacer.
La revolución tecnológica que permita el cambio de paradigma en la visión
de futuro del IxD no se producirá por generación espontánea, sino que será
fruto de una larga experimentación de la que podemos ser parte. La
ergonomía, por ejemplo, mediante evaluaciones hápticas o evaluaciones
ergonómicas de interfaces, puede contribuir grandemente al diseño centrado
en el individuo.¿Cómo? Teniendo en cuenta tempranamente en el proceso
de diseño las características físicas y cognitivas del usuario. Eso permite
ampliar la recepción de feedback que ofrecen los objetos del mundo
exterior y esto redunda en herramientas más adaptadas al ser humano y, por
lo tanto, más usables.
Referencias
1. Marcus Vitruvius Pollio, arquitecto e ingeniero romano, siglo I a.C
2. Homo quadratus, Leonardo da Vinci (1485-1490), Venecia, Galería de la
Academia.
3. Móvil multitáctil para discapacitados visuales [ Ver video de móvil
multitáctil ].
4. Digitalizando el sentido del tacto [ Ver video en Youtube ]
5. Mobile Lorm Glove [ Ir al sitio Web ]
6. Una forma común de comunicación utilizada por personas con
discapacidad auditiva y visual.
Bibliografía
Bastien, Christian J.M., Scapin, Dominique L., Critères ergonomiques
pour l’évaluation d’interfaces utilisateurs, INRIA Rocquencourt, mayo
de 1993.
Betti, Sebastián, Homo habilis a la conquista del mundo: factores no
computacionales que inciden en la calidad del software, Congreso
Internacional de Información, La Habana, abril de 2008.
Cañas, J.J. y Waerns, Y., Ergonomía cognitiva. Aspectos psicológicos
de la interacción de las personas con la tecnología de la información,
Médica Panamericana, Madrid, 2001.
Chernev, Alexander, “Product Assortment and Individual Decision
Processes”, Journal of Personality and Social Psychology, junio de
1985. En: Monitor on Psychology, junio de 2003. [último acceso: 28
de diciembre de 2012].
Cowan, N., “The Magical Number 4 in Short-term Memory: A
Reconsideration of Mental Storage Capacity”. En: Behavioral and
Brain Sciences, 24, pp. 87-114, Cambridge University Press, 2001.
Dawkins, Richard, El cuento del antepasado. Un viaje a los albores de
la evolución, Antoni Bosch Editor, Barcelona, 2008.
Huguenard, B. R., Lerch, F. J., Junker, B. W., Patz, R. J., Kass, R. E.,
Working Memory Failure in Phone-based Interaction. ACM
Transactions on Computer–Human Interaction, 4, pp. 67–102, 1997.
Keys, Daniel J.; Schwartz, Barry, “Leaky Rationality: How Research
on Behavioral Decision Making Challenges Normative Standards of
Rationality”, en: Perspectives on Psychological Science, 2007.
Keller, A.I., Stappers, P.J.; Creating People for Products: Humorous
Homunculi in the Service of Design Communication. Designing
Pleasurable Products and Interfaces, pp. 490-491, 2005.
Krug, Steve, Don’t Make Me Think. A Common Sense Approach to
Web Usability, New Riders, Berkeley, California, 2005.
Le Corbusier, El modulor. Ensayo sobre una medida armónica a la
escala humana aplicable universalmente a la arquitectura y a la
mecánica, Editorial Poseidón, Buenos Aires, 1961.
Miller, G.A. “The Magical Number Seven Plus or Minus Two: Some
Limits on our Capacity for Processing Information”, Psychological
Review, 63, pp. 81-97, 1956.
Norman, D. A., y Bobrow, D. G., “Data Limited and Resource Limited
Processes”, Cognitive Psychology, 7, pp. 44-64, 1975.
O’Donnell, R.D. y Eggemeier, F.T., “Workload assessment
methodology”. En: K.R. Boff, L. Kaufman, and J. Thomas (Eds.),
Handbook of Perception and Human Performance: Volume II
Cognitive Processes and Performance, pp. 42-1-41-49, John Wiley,
Nueva York, 1986.
Penfield, W., Rasmussen, T., The Cerebral Cortex of Man. A Clinical
Study of Localization of Function, The Macmillan Comp, Nueva York,
1950.
Peterson, L.R., Peterson, M.J., Short-term Retention of Individual
Verbal Items, Journal of Experimental Psychology, 58, pp. 193-198,
1959.
Seligman, M. E., Miller, W. R., Kurlander, H. M., Learned
Helplessness, Depression and Anxiety, Journal of Nervous and Mental
Disease, 161(5), pp. 347-357, 1975.
Soto, Rodolfo; Learning and Performing by Exploration: Label Quality
Measured by Latent Semantic Analysis, University of Colorado, CHI
99, 15-20 de mayo de 1999.
Wakeford, N.; Innovation through People-Centered Design, Lessons
from the USA. DTI Global Watch Mission Report, octubre de 2004.
Wickens, C. D., Engineering Psychology and Human Performance
(2da Ed.). Harper Collins, Nueva York, 1992.
Ziegler, J. E., Vossen, P. H., Hoppe, H. U., “Cognitive Complexity of
Human-Computer Interfaces: An Application and Evaluation of
Cognitive Complexity Theory for Research on Direct Manipulation-
style Interaction”, en: Falzon, P. (Ed.), Cognitive Ergonomics:
Understanding, Learning, and Designing Human-Computer
Interaction, pp. 27–38, Academic Press, San Diego, California, 1990.
Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking:
El Caso de la TV conectada, por Mari Carmen Marcos
Profesora e investigadora del Departamento de Comunicación de la
Universitat Pompeu Fabra de Barcelona. Licenciada en Documentación
(1996) y Doctora en Documentación (2002). Experta en Interacción
Persona-Ordenador y Recuperación de Información. Estudia el
comportamiento de las personas en los procesos de búsqueda de
información en la web. Autora de más de 70 trabajos. Subdirectora del
Máster Online en Documentación Digital (IDEC-UPF), co-directora del
Máster Online en Buscadores (IDEC-UPF) y Coordinadora del Máster en
Gestión de Contenidos Digitales (UB-UPF).
Más información:
Twitter: @mcmarcos
Verónica Mansilla
Periodista y Licenciada en Comunicación Social por la Universidad Andrés
Bello en Chile (2005). Titulada en el Máster en Gestión de Contenidos
Digitales por la Universitat de Barcelona y la Universitat Pompeu Fabra
(2012). Actualmente estudiante de doctorado. Su línea de investigación es
la interacción de las personas con sistemas de televisión en distintos
dispositivos. Desde 2003 ha trabajado en medios de comunicación online y
sitios web como Web Content Manager.
Más información:
Ingresar al LinkedIn autor
Twitter: @verito_mansilla
Evaluación de la usabilidad con tecnología eye

tracking: El Caso de la TV conectada
1. Introducción
De entre las distintas técnicas de evaluación de la usabilidad, los tests con
usuarios son una de las más usadas ya que proporcionan información de
primera mano sobre los problemas que presenta una interfaz a los usuarios
finales (Barnum 2011; Dumas y Redish 1999). Sin embargo, no todos los
problemas se explican observando al usuario o con una entrevista final, en
ocasiones se requiere “ver con sus ojos” para entender el problema. Para
esos casos, disponer de un eye tracker (ET) es de suma utilidad.
El ET es un dispositivo de seguimiento y grabación de la mirada que
incorpora luz infrarroja y cámara de vídeo. Cuando está activado, ilumina al
usuario con dos proyecciones de rayos infrarrojos que generan un reflejo en
las córneas del los ojos, concretamente en la fóvea, que es una pequeña
zona de la retina donde registramos la visión más nítida (no se registra por
tanto la visión parafoveal ni la periférica). Una cámara de vídeo integrada
en el equipo de ET recoge esos reflejos junto con la posición del usuario y,
mediante procesamiento digital de la imagen, extrae la ubicación de las
pupilas. La posición de las pupilas se mapean con la ubicación de la mirada
en la pantalla; de esa forma se registran las fijaciones y las sacadas. Las
sacadas son los movimientos que hacemos con los ojos al cambiar el foco
de atención, son muy rápidos -¡hasta 500 movimientos por segundo!-
(Duchowski 2009). Cuando mantenemos la mirada fija en un lugar durante
varios milisegundos se produce una fijación (Figura 1).
El ET puede ir situado en un dispositivo que se coloca en la cabeza del
usuario, por ejemplo en unas gafas, o bien grabar desde enfrente al usuario,
por ejemplo incorporado en un monitor (figura 2).
La tecnología de eye tracking ha despertado interés en las áreas más
diversas: Psicología Cognitiva, Diseño, Publicidad… e Interacción Persona-
Ordenador, donde ha demostrado ser una herramienta que complementa al
test de usuarios para estudiar la usabilidad y la user experience (Bojko
2012; Hassan y Herrero 2007; Jacob y Karn 2003; Nielsen y Pernice 2009;
Nielsen y Pernice 2010; Pernice y Nielsen 2009; Poole y Ball 2004). En los
últimos años se han publicado estudios sobre temas muy variados, por
ejemplo en la Universitat Pompeu Fabra hemos llevado a cabo
investigaciones sobre la interacción en los procesos de búsqueda en Google
(Marcos, Nettleton y Sáez 2012) sobre diferencias culturales en esa
interacción con el buscador ((Marcos, García-Gavilanes, Bataineh y Pasarín
2013), y sobre personalización de texto en pantalla para mejorar el
rendimiento en la lectura (Rello y Marcos 2012; Rello, Pielot; Marcos;
Carlini 2013).
2. La incorporación del eye tracker en un test de

usuarios
Realizar un test de usuarios con tecnología ET no es muy diferente de un
test sin este dispositivo, en realidad las etapas son las mismas, la forma de
preparar el test también, y los errores que podemos cometer no difieren
mucho (Marcos 2013), es más, ¡se amplía la lista! pero se han de considerar
una serie de aspectos que ahora presentamos.
¿Realmente necesitamos testear con un eye tracker? Si se opta por realizar
un test de usuarios con un ET debe ser porque interesa conocer cómo miran
los usuarios una interfaz cuando realizan determinada tarea. Para cualquier
otro dato que pretenda obtenerse durante el test, habrá que utilizar las
técnicas y metodologías que se aplican en un test con usuarios
convencional.
¿Nos lo podemos permitir? Antes de lanzarse a un estudio con ET, se debe
hacer un cálculo realista de la inversión necesaria y contemplar el precio del
eye tracker (sea de alquiler o de compra) y de la licencia del software de
testeo y análisis.
¿Cuánta muestra necesitamos? Al igual que en un test de usuarios, si se va a
realizar un estudio cualitativo, una muestra pequeña (por ejemplo 10
usuarios) será suficiente. En cambio si se van a realizar estudios
cuantitativos el tamaño de la muestra dependerá de cuántas variables entren
en juego, como orientación podemos decir que al menos se necesitarán 30
personas, posiblemente más.
¿Los usuarios deben cumplir algún requisito en cuanto a la visión? Para
obtener datos fidedignos, los usuarios deberán tener una buena visión en
ambos ojos, o ésta deberá estar corregida con gafas o lentes de contacto. El
uso de gafas no es un impedimento, salvo que tengan una graduación muy
alta y cristales gruesos, en tal caso no se registrarán bien las fijaciones y
sacadas.
¿Qué métricas se obtienen de un test de usuarios con ET? Además de las
métricas habituales de los estudios de usuarios (Sauro; Tullis y Albert
2008), los estudios con ET incluyen medidas propias de esta tecnología. Las
más usadas en los estudios de usabilidad tienen relación con los niveles de
performance de las tareas (eficacia y eficiencia); son las siguientes:
Porcentaje de participantes que han fijado su atención en una zona.
Tiempo que ha pasado desde que se ha presentado la interfaz hasta que los
usuarios han fijado la vista por primera vez en una zona determinada. Mide
la atracción de cierta zona de la interfaz.
Número de fijaciones de los usuarios en una interfaz o en una zona de una
interfaz. Una mayor número indica mayor interés, o en ocasiones dificultad
para comprender.
Duración de las fijaciones en una interfaz o en una zona de ésta. Una mayor
duración indica mayor interés, o en ocasiones dificultad para comprender.
Camino recorrido por cada usuario, del que se puede obtener tanto su
longitud como su complejidad.
Tiempo que ha pasado desde que los usuarios han visto una zona hasta que
la seleccionan (con un clic si es una página web, con una pulsación si es un
teléfono, con una pulsación si hay un control remoto de TV, etc.) . Mide la
capacidad que tiene un elemento para dar a entender que es ahí donde hay
que clicar (el call to action).
La ratio de parpadeos (si es alta indica estrés).
El diámetro de la pupila durante ciertos momentos de la navegación. La
dilatación es un indicador de estrés.
¿Cómo debe ser la sala de testeo? Es importante contar con una iluminación
que evite los focos de luz directos al usuario o a la pantalla, pues los
reflejos interfieren en la grabación. De hecho, es preferible que haya luz
artificial de tipo fluorescente y que se mantenga constante durante todas las
sesiones de grabación.
La sala debe contar con el número de enchufes necesarios para poder
conectar el ordenador, el ET, y otros dispositivos que se vayan a utilizar de
forma paralela. En caso de necesitar conexión a internet, preferiblemente
será vía cable para que sea más estable, evitando la conexión inalámbrica.
En caso de usar un ET remoto, la silla que donde se sienten los usuarios
durante el test no debe tener ruedas para evitar que el usuario se desplace,
ya que podría acercarse o alejarse de los sensores más de lo que el ET
puede registrar. Una distancia de 60 cm es la óptima.
¿Hay que configurar el ET para cada usuario? El primer paso que se realiza
en un test con eye tracker es la llamada calibración. Se trata de un proceso
que apenas tarda unos segundos, y que consiste en que el usuario siga con
su mirada un dibujo que se mueve en la pantalla, o en caso del modelo
montado sobre gafas, unas piezas que el moderador mueve en la pared. La
calibración permite que el ET registre la distancia a la que estará
haciéndose la grabación y la distancia entre las pupilas del usuario.
¿Para qué contratiempos debemos estar preparados? Como en cualquier test
en el que se usa tecnología, pueden darse problemas técnicos, como errores
en el funcionamiento del ET, del software de grabación, del sistema
operativo del ordenador o del propio PC que se esté usando, problemas de
conexión a internet (en caso de ser necesario estar conectado), problemas de
electricidad como un corte de energía en el edificio o en el barrio, etc. Si
alguno de estos imprevistos ocurre durante la grabación, en la mayoría de
los casos el test se invalidará y lamentablemente habremos perdido una
grabación para nuestra muestra.
En otras ocasiones la grabación se habrá realizado aparentemente sin
problemas, en cambio al revisarla podemos observar que no se grabó bien.
Puede ser porque el usuario movió la silla hasta un lugar donde no alcanzó
a grabarse su mirada, o se reclinó mucho hacia delante, o porque sus gafas
han reflejado mal los infrarrojos, o simplemente porque hay personas en las
que por motivos aun desconocidos no se graba bien su mirada con un ET. Si
algún usuario no ha quedado grabado con un mínimo de completitud, será
mejor desechar el test.
3. Análisis de los datos obtenidos con un eye

tracker
Una vez realizados los tests comienza la etapa de análisis. Los resultados
que se pueden obtener con un dispositivo de este tipo, como ya
adelantábamos, pueden ser cualitativos y cuantitativos, en función del
objetivo del test.
3.1. Análisis cualitativo

Cuando el objetivo del test es entender cómo navegan los usuarios, el
análisis cualitativo puede ser una buena opción, ya que no precisa análisis
estadístico, y por tanto con una muestra pequeña (por ejemplo de 10
usuarios) se obtiene la información necesaria. El storytelling y el
liveviewing son dos técnicas de utilidad para este tipo de tests.
El storytelling consiste en narrar mediante palabras, capturas de pantalla y
videos de partes de la sesión lo que ha sucedido durante los tests. La
“historia” la puede contar el moderador, o bien o se le puede pedir al
usuario que lo haga en voz alta mientras ve el vídeo que se ha grabado de su
test; en este último caso se trata de un Restrospective Think Aloud (RTA) 1,
y el usuario comenta qué pensaba mientras navegaba, cuál era su intención
en cada momento, por qué decidió clicar en un lugar, qué problemas le
presentó cada interfaz, etc.
La otra técnica, el liveviewing, consiste en “ver a través de los ojos del
usuario”. Su objetivo es saber qué ve el usuario, nada más. No se realiza un
análisis de datos, sólo se trata de entender cómo se ha producido la
navegación y por qué el usuario ha tomado ciertas decisiones. La forma de
llevar a cabo este tipo de análisis consiste en grabar la sesión con el ET y
reproducirlo para ver las distintas interfaces con las fijaciones superpuestas,
y de ahí se seleccionan los fragmentos más interesantes. También en este
caso se puede realizar un RTA para que el propio usuario comente su
navegación. Se trata de una técnica rápida, ya que se hace en el momento.
Las técnicas cualitativas presentadas resultan especialmente útiles para
testear interfaces con contenido dinámico, por ejemplo páginas web con
menús desplegables o con banners o videos en Flash, ya que por la forma en
la que se recoge la información con el ET no siempre se pueden obtener
datos cuantitativos de estas partes cambiantes de la interfaz. En estos casos,
los videos son la mejor forma de analizar lo que ha ocurrido porque
muestran las fijaciones y sacadas sobre la interfaz.
3.2. Análisis cuantitativo
Datos numéricos
Cuando hablamos de obtener resultados cuantitativos estamos hablando de
números, de estadísticas, en definitiva de métricas. En el caso del ET, estas
métricas vienen dadas por la propia forma de funcionamiento de este
dispositivo y del software que le acompaña. El interés de obtener métricas
reside en que permite comparar varias interfaces -o una misma en dos
momentos distintos-.
El análisis cuantitativo implica dos dificultades en sí mismo: por un lado,
requiere un número de participantes mayor del que necesita un estudio
cualitativo. Si se van a realizar cálculos estadísticos, recomendamos trabajar
con muestras de al menos 30 usuarios de un mismo target. En caso de
querer comparar los resultados entre diversos targets, esta cifra se
multiplica, ya que se necesita tener una muestra de cada uno de ellos, lo que
hace que el test sea más costoso tanto en dinero como en tiempo.
Como es de esperar, para la obtención de datos cuantitativos quedan
totalmente excluidos los Concurrent Think Aloud (CTA), ya que si el
usuario habla mientras realiza las tareas se ralentizan sus acciones y por lo
tanto se introduce un sesgo en las mediciones. Sí se puede utilizar la técnica
RTA, pero supone un tiempo y un trabajo adicional importantes, por lo que
su aplicación debe valorarse.
Dado que la intención es obtener resultados cuantitativos, es muy común
aplicar un análisis estadístico a los datos recogidos del eye tracker. Algunos
los proporciona el propio software del ET, por ejemplo el promedio de
fijaciones por zona, la duración de éstas o el tiempo que transcurre hasta la
primera fijación en un área. Pero si se quieren calcular otras medidas
estadísticas será necesario exportar los datos a programas específicos de
estadística y realizar en ellos las operaciones necesarias. El software
proporciona también algunos gráficos a partir de las estadísticas
mencionadas.
Mapas
Los programas de análisis de datos de ET suelen contar con una
presentación en forma de mapas en los que se muestran las fijaciones de
cada usuario o bien de un grupo de usuarios. Estos mapas superponen a la
interfaz un gráfico que muestra el comportamiento visual de las personas
grabadas con el ET.
Como ya mencionábamos, hay un problema para obtener datos de interfaces
que cambian de forma dinámica, como sucede cuando se ejecuta un
programa de JavaScript –por ejemplo para generar menús desplegables-, o
con una presentación en Flash. Esto afecta a la obtención de mapas, dado
que la captura de pantalla de la interfaz sobre la que se muestran las
fijaciones no puede captar todas las variantes. Es más, en caso de que se
ejecute un programa en JavaScript, sólo se guardará captura de pantalla de
la página al abrirse, antes de que se ejecute el programa; y en el caso de
Flash, la zona de la animación aparecerá en blanco en la captura de pantalla.
Si se van a usar mapas en situaciones así, habrá que interpretarlos con la
ayuda de los videos.
Hay tres tipos de mapas: de calor o heatmaps, de opacidad o gaze opacity, y
de recorrido o gaze plot (figura 4).
Los mapas de calor y los de opacidad reflejan uno de estas tres datos: el
número de fijaciones, la duración total de las fijaciones, o el tiempo que
cada persona destina a mirar una determinada área en relación con el
tiempo que dedica a toda la página. Los mapas de calor representan esta
información usando distintas intensidades de color: rojo indica un valor
alto, verde uno medio y amarillo uno bajo. Las zonas que no han registrado
fijaciones aparecen sin superponer en ellas ningún color. Los mapas de
opacidad lo hacen de una manera similar pero cubriendo con una capa
negra aquellas zonas que no han recibido fijaciones, dejando entrever con
cierta transparencia las que han registrado cierta intensidad de miradas, y de
forma nítida las zonas que registran mayor actividad visual.
Los mapas de recorrido, a diferencia de los anteriores, muestran el
movimiento de los ojos de cada usuario. Las fijaciones se muestran con
círculos y las sacadas con líneas que unen las fijaciones. El tamaño del
círculo es un indicador de la duración de cada fijación (a mayor tamaño
mayor tiempo dedicado). Cada círculo lleva un número secuencial que
permite seguir la dirección de la mirada de una fijación a la siguiente. Dado
que el mapa representa las miradas de cada usuario -no el promedio de un
grupo-, no se puede visualizar bien a muchos usuarios al mismo tiempo, por
lo que suelen ofrecerse mapas con pocos usuarios.
Hasta aquí se ha explicado en qué consiste la tecnología eye tracking y
cómo se aplica en un test de usuarios. A continuación se presenta un test de
usuarios realizado para medir la usabilidad de varias interfaces de
televisión.
4. Caso de estudio: eye tracking y usabilidad en

TV conectada
La televisión conectada es una tecnología que utiliza dos canales para
recibir información: por un lado la señal de televisión digital terrestre (TDT
o DVB-t, digital video broadcasting-terrestrial) para recibir contenidos
televisivos y por otro lado datos de Internet, lo que hace posible disponer en
el televisor de servicios que proceden de la Red, por ejemplo televisión a la
carta (video on demand, VoD), redes sociales, Youtube , navegador web,
etc. Al tratarse de una tecnología reciente, no hay un consenso en el diseño
de las interfaces de sus menús, así que cada fabricante y cada cadena llegan
a una solución, y por ahora con poca coincidencia entre sí.
Un estudio de usabilidad realizado por la Universitat Pompeu Fabra
(Mansilla y Marcos 2013; Marcos y Mansilla 2013) aplicó la tecnología de
ET a cuatro modelos de televisión conectada: un televisor Sony Bravia, una
caja TDT Engel que utiliza el sistema HBB-TV, hoy un estándar de TV
conectada en Europa, una caja TDT Blu:sens, y una consola PlayStation3.
Los cuatro dispositivos permiten acceder al servicio de televisión a la carta,
y todos, salvo la consola, cuentan con señal de televisión.
En este estudio, que ahora resumimos, participaron 70 personas. En primer
lugar se realizó un test de usuarios con 50 personas; en este test no se aplicó
la tecnología de ET y se usó el CTA. En él se detectaron errores de
usabilidad en las interfaces tanto de la pantalla como de los mandos a
distancia. Los usuarios realizaron varias tareas en dos de los cuatro
dispositivos: localizar la programación de una cadena, encontrar un
programa en la TV a la carta, hacer una búsqueda en la web y ver un vídeo
en Youtube, en caso de que el sistema dispusiera de esas funcionalidades.
Un investigador del equipo moderaba la sesión de test mientras otra tomaba
notas de lo sucedido en una hoja de observación (figura 3).
Los resultados del test pusieron de manifiesto problemas de usabilidad
relacionados con la comprensión de las opciones de los menús de
navegación, con la complejidad de los íconos de los mandos a distancia,
pero también con la frustración al encontrar que estos televisores no
cumplen sus expectativas: la carga es lenta, no están todas las aplicaciones
que les gustaría, la navegación es críptica, etc.
Uno de los problemas más recurrentes observados en este primer test fue
que los usuarios no lograban acceder fácilmente al servicio de TV a la carta.
En unos casos estos canales estaban en el menú “TV” en el mismo grupo
que las radios y Youtube, en otros bajo el menú “videos” y en otros bajo
“internet”. Pero el dispositivo que menos eficacia presentó para esta tarea
fue la caja Engel, precisamente la que usa el protocolo europeo HBB-V:
para acceder a la TV a la carta es necesario que el usuario entre al canal
correspondiente por TDT, y una vez ahí lea -y comprenda- un mensaje en
pantalla que indica que debe pulsarse un botón del mando a distancia. La
mayoría de los usuarios no finalizaron la tarea. Para esta tarea y este
dispositivo, se decidió testear con 20 usuarios más, esta vez grabando las
sesiones con un eye tracker, y así poder profundizar en los motivos por los
que esta tarea no se completaba de forma eficaz, eficiente y satisfactoria. Se
utilizó el sistema Tobii Glasses.
En este segundo test cada usuario realizó la tarea en los cuatro dispositivos.
Se quería saber cuántos usuarios veían el mensaje en pantalla, y de éstos
cuántos lo entendían. La muestra final se vio reducida a 14 usuarios por
problemas técnicos de la grabación: los rayos infrarrojos de los mandos a
distancia interferían con los rayos infrarrojos del eye tracker, lo que impedía
que la sesión se grabara correctamente.
Los resultados fueron muy interesantes: solo 4 usuarios fijaron su mirada en
el mensaje en la interfaz para acceder a la TV a la carta (figura 5), y de ellos
sólo uno lo comprendió y pulsó la tecla del mando que se indicaba.
Es interesante decir que el análisis de los datos del ET presentó varias
dificultades. Por un lado, los ficheros de vídeo eran muy pesados, lo que
requirió disponer de un disco externo de gran capacidad para gestionarlos,
además de más memoria RAM para el ordenador que computaba los datos,
y una tarjeta gráfica dedicada que soportara esta información. Por otro lado,
el marcado de los videos para obtener datos cuantitativos se tenía que
realizar manualmente. Eso fue así porque se trataba de interfaces dinámicas,
es decir, el acceso a la TV a la carta en este caso no se hacía desde un menú
previo, sino que el mensaje en este tipo de televisor aparecía mientras se
estaba viendo el programa de la cadena de la que se quiere acceder a la
carta. Eso requirió de este marcado manual para el que había que visionar
cada grabación, detectar en qué momento se cargaba el mensaje en pantalla
y cuándo desaparecía. Considerando que los usuarios entraban en la
pantalla, salían de ella para buscar en el menú, entraban de nuevo en ella, y
así sucesivamente, un mismo usuario podía tener frente a sus ojos el
mensaje sobre cómo ir a la TV a la carta varias veces. El marcado fue por
tanto un trabajo minucioso que se tuvo que hacer para cada vídeo.
5. En resumen
El eye tracking es una tecnología de seguimiento de la mirada utilizada para
conocer y analizar el comportamiento visual. Existen modelos de eye
tracker que van montados sobre la cabeza de los usuarios (casco o sobre
gafas) y modelos remotos, en los que el detector está en un dispositivo
frente al usuario. Con esta tecnología es posible estudiar la mirada en
entornos (en una tienda, en la calle, etc.) o en laboratorio (estudios de
interfaces web, de televisión, etc.). Los profesionales del diseño de
interfaces utilizan esta técnica para entender el comportamiento de los
usuarios en sistemas interactivos como sitios web, móviles, interfaces de
TV... y detectar problemas de usabilidad.
Los datos que se obtienen son cualitativos como cuantitativos. Los primeros
permiten observar cómo se comporta el usuario, y el vídeo de su mirada es
un buen complemento al test de usabilidad. Los cuantitativos precisan una
muestra relativamente alta para poder realizar cálculos estadísticos y
permiten detectar patrones de comportamiento visual.
En el caso de realizar un estudio cuantitativo, el eye tracking proporciona
una gran cantidad de métricas. Las más utilizadas son: tiempo hasta la
primera fijación en un área de la interfaz (mide la atracción del elemento
estudiado), tiempo de permanencia en un elemento (mide el interés del
elemento), y en el caso de analizar sitios web, el tiempo desde la primera
fijación en un área hasta realizar un clic en ella (mide la facilidad para
comprender el elemento o, según el caso, la conversión).
Los tests con eye tracking deben evitar que los participantes hablen durante
la grabación (CTA), ya que pueden distraerse y cambiar su comportamiento
visual. Es preferible que realicen la prueba, y después durante la entrevista
final se puede reproducir el vídeo y comentar sobre él sus percepciones
(RTA).
El eye tracking puede aplicarse a estudios de interfaces de distintas
tecnologías, entre ellas las de televisión. En casos como este, en que la
información a menudo es dinámica, la tecnología de ET requiere un pre-
procesado manual de datos que resulta costoso en tiempo.
Referencias
1. El Retrospective Think Aloud se contrapone a otra técnica, el Concurrent
Think Aloud (CTA), en el que el usuario habla mientras hace las tareas. El
CTA no debe aplicarse en estudios con ET ya que es posible que el usuario
se despiste al hablar y cambie su comportamiento natural, lo que afecta a
cómo mira la página ,y por lo tanto al número de fijaciones y a la duración
de estas.
Bibliografía
Barnum, C., Usability Testing Essentials: ready, set… test!, Morgan
Kaufmann, 2011.
Bojko, A., Eye tracking the user experience, 2012. [Ver en línea]
Duchowski, A., Eye Tracking Methodology, Springer, 2009.
Dumas, J.; Redish, J., A practical guide to usability testing, Norwood:
Ablex Publishing Corporation, 1999.
Hassan, Y.; Herrero, V., Eye Tracking en Interacción Persona-
Ordenador, No solo usabilidad, 2007. [Ver en línea Hassan y Herrero]
Jacob, R.; Karn, K., “Eye Tracking in Human-Computer Interaction
and Usability Research: Ready to Deliver the Promises (Section
Commentary)”, en: Hyona,J., Radach, R., Deubel, H. (eds.), The
Mind’s Eye: Cognitive and Applied Aspects of Eye Movement
Research, pp. 573-605, Elsevier Science, 2003, [Ver en línea Jacob
Eye Tracking]
Mansilla, V., Marcos, M.C., “User experience en Televisión
Conectada: un estudio con usuarios”, en: El Profesional de la
Información, vol. 22 (2), 2013, pp. 122-127.
Marcos, M.C., Diseño de experimentos con usuarios: lecciones
aprendidas, Anuario Hipertext.net, vol. 11, 2013, [Ver en línea Marcos,
M.C]
Marcos, M.C., Garcia-Gavilanes, R., Bataineh, E., Pasarin, L., “Using
Eye Tracking to Identify Cultural Differences in Information Seeking
Behavior”, Workshop “Many People, Many Eyes”, CHI 2013 (París),
[Ver en línea Marcos, M.C Usando Eye Tracking]
Marcos, M.C., Mansilla, V., “Video on Demand: Usability challenges
for Connected TV”, Workshop “Exploring and Enhancing the User
Experience for TV”, CHI 2013 (París), >
Marcos, M.C., Nettleton, D., Sáez, D. (2012), Evaluation of User
Search Behaviour using a Web Search Log and Log and Eye Tracking
data. Proceedings of the BCS HCI 2012, People & Computers XXVI
(Birmingham, UK), 262-267,
Nielsen, J., Pernice, K., Eyetracking Web Usability, New Riders Press,
2009.
Nielsen, J., Pernice, K., Técnicas de Eyetracking para Usabilidad Web,
Anaya Multimedia, 2010.
Pernice, K., Nielsen, J., Eyetracking Methodology: 65 Guidelines for
How to Conduct and Evaluate Usability Studies Using Eyetracking,
2009, [Ver en línea metodología de Eye Tracking]
Poole, A., Ball, L.J., “Eye Tracking in Human-Computer Interaction
and Usability Research: Current Status and Future Prospects”, en:
Ghaoui, C (Ed.), Encyclopedia of Human Computer Interaction, Idea
Group, 2004, [Ver en línea Eye Tracking in Human-Computer
Interaction]
Rello, L., Marcos, M.C., An Eye Tracking Study on Text
Customization for User Performance and Preference, LA-Web 2012
(Cartagena, Colombia, Octubre 2012), 2012.
Rello, L., Pielot, M., Marcos, M.C., Carlini, R. Size Matters (Spacing
not): 18 Points for a Dyslexic-friendly Wikipedia.,W4A2013,
Technical May 13-15, 2013, Río de Janeiro, Brasil, Co-Located with
the 22st International World Wide Web Conference .
Sauro, J., Measuring Usability, http://www.measuringusability.com
Tullis, T.; Albert, B., Measuring the user experience: collecting,
analyzing, and presenting usability metrics, Morgan Kaufmann, 2008.
Capítulo 14: Accesibilidad de un recurso educativo: El caso de la
Mapoteca, por Manuel Razzari
Licenciado en Tecnología Multimedial. Co-fundador de Con Vista Al Mar,
un estudio de diseño de interfaces web pionero en el abordaje integral de la
usabilidad y accesibilidad. Desde 1996 conceptualiza y desarrolla sitios
web, trabajando con estándares web y accesibilidad desde 2002. Miembro
activo de IxDA, la Asociación de Diseño de Interacción y co-fundador del
Movimiento de Diseño Inclusivo, dedicado al apoyo y difusión de
iniciativas sobre estas temáticas. Ha dictado cursos y presentado
conferencias sobre accesibilidad Web, maquetado y marcado semántico.
Más información:
Twitter: @mrazzari
Accesibilidad de un recurso educativo: El caso

de la Mapoteca
Acerca del proyecto
Este capítulo describe como caso práctico la experiencia con el proyecto
“Mapoteca” de educ.ar, una aplicación web para que estudiantes de nivel
medio interactúen con mapas escolares. Será distribuida en las 3,5 millones
de netbooks que el gobierno argentino brinda a alumnos de escuelas
secundarias públicas mediante el programa “Conectar Igualdad”.
La Mapoteca permite navegar mapas de las provincias argentinas, con las
herramientas a las que estamos acostumbrados para un mapa interactivo:
acercarnos y desplazarnos dentro de un visualizador, para recorrerlo.
Cada provincia tiene una decena de mapas, que incluyen no sólo los
clásicos político, mudo, y físico, sino también mapas temáticos: históricos,
económicos, ambientales, demográficos, turísticos.
Estos mapas se presentan como capas, que el alumno puede superponer con
transparencias para “calcar” de un mapa a otro. Por ejemplo puedo
superponer el mapa climático sobre el económico, y ver como la lluvia en
una región ha influido sobre su producción agrícola.
El visor de mapas interactivos incluye una serie de herramientas básicas de
dibujo: lápiz, texto, rectángulos y círculos, polígonos, y una paleta de
colores. Esto permite al docente dar tareas de dibujo en el mapa, como
trazar los ríos sobre un mapa político, o etiquetar las ciudades en un mapa
mudo. Estos mapas intervenidos pueden descargarse como imagen, para
entregar por e-mail, o imprimirse.
Se trata de más de 300 mapas que se complementan con 200 actividades
didácticas específicas a cada provincia y temática, con ejercicios de
investigación en línea y pautas para el trabajo con los mapas. Las
actividades se relacionan entre si por etiquetas y meta-datos.
Ilustración 1 / Un primer prototipo del visualizador de mapas, en su etapa

de wireframe.
El equipo
La creación de esta aplicación estuvo a cargo de “Con Vista Al Mar 1”, un
estudio de diseño y desarrollo de interfaces web que trabaja con estándares
web, usabilidad y accesibilidad.
El equipo del proyecto podría considerarse pequeño: un programador front-
end, un programador back-end, un diseñador, y un líder de proyecto. Cabe
destacar que no hay un rol específico de especialista o consultor en
usabilidad o accesibilidad. Son roles que permean la labor de cada miembro
del equipo, es decir, cada uno debe conocer e incorporar las técnicas que
informarán transversalmente las decisiones en su trabajo cotidiano 2.
El proyecto fue encomendado por educ.ar 3, el portal educativo del Estado
argentino, destinado a ejecutar políticas definidas por el Ministerio de
Educación en materia de integración de las TIC en el sistema educativo.
El equipo de Con Vista Al Mar se complementó con el equipo dentro de
educ.ar coordinando y supervisando el proyecto, y con un equipo externo de
cartógrafos y contenidistas especializados en la materia 4.
Límites de un estudio web
La mayoría de los proyectos “para clientes” llevados a cabo por estudios o
agencias se encuentra con límites prácticos a la hora de incorporar
usabilidad y accesibilidad en un proceso de diseño o desarrollo.
Los tiempos asignados siempre parecen cortos. Los costos son estimados
por hora de trabajo, con muchos clientes cuestionando cada hora del
presupuesto en el afán de bajar costos. Se genera la sensación de que apenas
hay tiempo para cumplir con los requerimientos, es decir “que funcione”,
que no haya errores visibles. No hay tiempo para el diferencial de calidad
que genera el diseño centrado en el usuario. A diferencia de lo que sucede
en los grandes sitios o “punto com”, el retorno sobre la inversión (ROI) no
es tenido en cuenta, por lo que resulta difícil presentar una propuesta de
valor enfocada en el largo plazo 5.
Del mismo modo, no siempre es posible un control “punta a punta”. Hay
actores externos al estudio que influirán en lo que termina publicado en el
sitio. Cuando hacemos un sistema de gestión de contenido, no podemos
asegurar que van a escribir texto alternativo apropiado, o que cargarán
imágenes con suficiente contraste, o que no pondrán media docena de
enlaces “clic aquí” en una misma página.
El desafío entonces es encontrar formas de hacer más en menos tiempo,
mediante lineamientos, mejores prácticas y componentes re-utilizables; que
nos permitan trabajar con una base sólida y nos liberen el poco tiempo
restante para optimizar los detalles. Esto es, una parte común a todos los
proyectos, que podemos llamar “de base”, y cuestiones específicas que
deberán evaluarse y ponerse a prueba en cada proyecto.
Un marco de trabajo para accesibilidad

cotidiana
Las mejores prácticas en maquetado y programación front-end son el pilar
de la accesibilidad web. Hoy en día hemos dejado atrás la diagramación con
tablas, y mediante propiedades de CSS como gradientes, bordes
redondeados, sombras, y fuentes personalizadas, se vuelve prácticamente
innecesario el uso de imágenes para representar el diseño. El uso de
marcado semántico, técnicas de JavaScript no invasivo y mejora progresiva,
es un requerimiento para empezar a trabajar la accesibilidad de un proyecto.
Sin ésto, el resto de las mejoras que realicemos tendrá poco sentido.
La selección apropiada de un gestor de contenido es fundamental a la
construcción de una web accesible. En principio, debe tener un editor de
texto enriquecido (también conocido como “RTE” o editor visual) que
genere HTML válido, anidando apropiadamente los elementos, evitando
etiquetas deprecadas o espacios de nombres XML no estándar (frecuentes al
copiar y pegar desde procesadores de texto).
Pero el editor no sólo debe generar HTML sintácticamente válido: debe
proveer ayudas para el marcado semántico. Es importante no darle a los
autores herramientas que les permitan tomar decisiones sobre el formato
visual del texto. Es decir, no pueden elegir fuentes, tamaños y colores. En
lugar de ésto, el editor de texto les permite elegir niveles de encabezados, u
otras etiquetas con apropiado valor semántico como citas, listas, y
destacados. Y provee cuadros de diálogo para definir texto alternativo en
las imágenes y meta-datos para tablas.
El programador debe evitar patrones difíciles de mantener, como la
generación de HTML mediante concatenación de cadenas (strings) en el
back-end o en JavaScript, o el uso de “controles” que generen grandes
fragmentos de HTML no modificables. En su lugar, debe trabajar con
plantillas que separen la lógica del back-end del HTML, de forma tal que el
maquetador pueda trabajar con su parte del código directamente. De lo
contrario, es difícil aplicar y sostener en el tiempo las mejoras de
accesibilidad.
Componentes accesibles
Tan importante como la elección de componentes adecuados en el back-
end, resulta la selección de fragmentos de código, plugins y librerías que
usemos en el front-end.
Por ejemplo al elegir un plugin de jQuery, en general hay muchas
alternativas para resolver una misma funcionalidad, y la búsqueda se centra
en la que más se parezca al diseño visual, o que sea más completa de
acuerdo al requerimiento, o esté mejor documentada, o simplemente sea
conocida y popular. Si nuestro proyecto prioriza la accesibilidad web,
entonces éste debe ser un factor clave a tener en cuenta, evaluándolo al
mismo nivel que otros. ¿Qué llevará más tiempo, hacer accesible un menú
desplegable bonito, o hacer bonito un menú accesible?
A veces nos apresuramos a descargar un plugin y utilizarlo, cuando en
realidad resulta sencillo hacer una serie de pruebas básicas mediante los
ejemplos provistos por el mismo. Estas pruebas incluyen probarlo en todos
nuestros navegadores objetivo, incluyendo lector de pantalla; verificar que
podemos usarlo íntegramente con el teclado (teclas tabulación, intro,
espacio, atajos con letras); hacer zoom del texto para saber rápidamente si
es escalable; y controlar que si hay enlaces, éstos apunten a una URL real (y
no a un onclick o “javascript:...”). Por supuesto, mejor aún si dice cumplir
con las recomendaciones WCAG o WAI-ARIA.
En el caso de aplicaciones web complejas, hay librerías que tienen una base
de accesibilidad muy sólida: jQuery UI, Dojo Toolkit, o YUI de Yahoo,
entre otras. Una vez más, si la accesibilidad es una prioridad o un
requerimiento, el uso de éstas nos ayudará a no “empezar de cero”, y poder
enfocar nuestro limitado tiempo en los detalles de accesibilidad específicos
a nuestra problemática.
Definición de problemas y prioridades

Una vez que la aplicación o página web está mínimamente funcional, y
consideramos que hemos hecho lo mejor posible en cuanto a una base
sólida, utilizando mejores prácticas, marcado semántico y componentes
accesibles, es necesario saber dónde estamos parados y cómo seguir.
Para este proyecto contamos con tres instancias de pruebas con usuarios, en
sucesivas etapas: wireframe, versión alpha y beta de la aplicación. Se probó
con personas representativas del usuario final, es decir alumnos de cuarto y
quinto año de colegios secundarios estatales de Capital y Gran Buenos
Aires.
Sin embargo, no tuvimos la posibilidad de hacer pruebas con alumnos con
discapacidad. Es preciso entonces valernos de otras técnicas que nos
permitan identificar los problemas de accesibilidad pendientes, detalles que
se nos escaparon e, igualmente importante, poder definir con qué prioridad
debe solucionarse, o no, cada problema.
Como primera medida utilizamos eXaminator 6, que nos apunta
rápidamente los errores y omisiones más groseros. Luego utilizamos otras
herramientas como T.A.W. 7, AChecker 8, y la eficaz barra de
Herramientas de Accesibilidad 9 de Firefox para hacer una revisión más
exhaustiva. Al haber realizado el maquetado con marcado semántico,
verificar directamente contra pautas WCAG 2.0 de Nivel AA resulta un
objetivo alcanzable. Por supuesto, si encontramos problemas de Nivel A,
éstos tienen prioridad.
Pero así como los validadores de HTML o CSS del W3C no pueden
decirnos si la página “se ve” correctamente, y entonces el maquetador
verifica visualmente las páginas en diversos navegadores y dispositivos, de
igual forma debemos sumar un programa lector de pantalla a esa matriz de
verificación multi-navegador, ya que los validadores de accesibilidad no
podrán saber como realmente “se escucha” la página.
Para esta tarea elegimos habitualmente la combinación de Firefox y el
lector NVDA 10, que combinan la gran disponibilidad de herramientas de
depuración de errores del primero, con la simplicidad de instalación y
gratuidad del segundo. Si bien la combinación de navegador y lector de
pantalla más utilizada en el mundo es, por un amplio margen, Internet
Explorer y JAWS, el uso de NVDA nos permitirá detectar las principales
barreras que presenta nuestra página a las ayudas técnicas. En el caso
específico de este proyecto se suma el dato, no menor, de que NVDA es el
lector de pantalla que se instala por defecto en las netbooks de Conectar
Igualdad.
Una última brújula para definir prioridades es la encuesta anual que hace la
organización WebAIM 11 a usuarios de lectores de pantalla, entre los que se
destacaron en 2012: Flash, Captcha, enlaces sin sentido e imágenes sin
texto alternativo como los ítems más problemáticos, seguidos de los
cambios inesperados de pantalla, formularios complejos, mala navegación
por teclado, falta de encabezados (h1, h2, ...) y el exceso de enlaces y
navegación.
Como aprendimos del proceso de diseño centrado en el usuario, ninguna de
estas técnicas reemplazará las pruebas con personas reales, y nos ponen más
bien del lado del cuestionado “diseñador genio” que imagina en base a su
gran experiencia y conocimiento, sin levantarse de su escritorio a conocer a
los usuarios 12. Pero en el campo de la accesibilidad resultan sin lugar a
dudas fundamentales al permitirnos hacer mucho, con poco, efectivamente
mejorando el día a día de las personas que utilizarán el resultado de nuestro
trabajo.
Accesibilidad en la Mapoteca
A continuación describiremos algunos problemas puntuales que surgieron
en este proyecto en relación a los mapas, y a la accesibilidad en proyectos
educativos en general, de cómo los solucionamos, pero también cómo
fallamos en anticipar algunos inconvenientes, o de cómo algunas soluciones
estaban fuera del alcance del proyecto.
Imágenes de texto
Tradicionalmente la accesibilidad de los mapas en la Web se ha relacionado
con la posibilidad de navegarlos utilizando el teclado, es decir con los
cursores para desplazarnos, y las teclas más/menos para acercarnos o
alejarnos. Esto cubre un área de la accesibilidad para nada menor, ya que da
acceso a los usuarios con movilidad reducida que no usan el mouse, sino
que sólo el teclado, ya sea físico, en pantalla, o pulsadores. También
permite a los usuarios con visión reducida ampliar el texto para poder
leerlo.
Pero como dice el cuento, “el emperador va desnudo”. Todos los mapas en
la web funcionan mediante un servidor de mapas que convierte los datos
geo-espaciales a un caché de mosaicos que son enviados al cliente
visualizador 13. Esto es lo que vemos en cualquier mapa en línea: que carga
por partes, “en cuadraditos”. Cada uno de estos cuadraditos es una imagen
JPG, y aquí estamos dejando de lado uno de los principios más caros a la
accesibilidad, que es el de las alternativas textuales.
Toda el área del mapa es, para el lector de pantalla, un agujero negro. No
hay forma de que el navegador pueda transmitirle al lector de pantalla los
nombres de ciudades y ríos que estamos viendo, simplemente porque el
mapa no es más que una gran imagen con texto.
Una de las personas que más sabe de accesibilidad Web en el mundo de
habla hispana me dio tranquilidad respecto a esta clara limitación en nuestro
proyecto: “la accesibilidad no pide milagros”, me dijo 14. Es bueno saber
hoy, sin embargo, y sin temor a ser grandilocuentes, que el milagro existe,
aún si un poco lejano a nuestra realidad. Me refiero a la aplicación de
mapas presentada por Apple en la versión 6 de su iOS. En lugar de
mosaicos de imágenes, ésta usa datos vectoriales que pueden ser leídos por
VoiceOver, el lector de pantalla incorporado al teléfono. El usuario puede
entonces tocar el mapa, y le serán leídos los nombres de calles y ciudades
mientras desplaza el dedo, en lo que representa un salto sin precedentes en
la accesibilidad de información cartográfica.
Mapas y ceguera al color

No todos los factores se tienen en cuenta con la debida anticipación, y este
fue el caso del uso del color en algunos mapas. El ambiental de la
Argentina, por ejemplo, está dividido en casi 20 climas, y por lo tanto
colores. Resulta frecuente que colores contiguos en el mapa se vean como
un mismo color por personas con algún tipo de daltonismo o ceguera al
color. Se suma a esto la dificultad de vincular visualmente la referencia al
pie del mapa, indicando qué representa cada color.
Si tenemos en cuenta que el daltonismo afecta a más de uno de cada diez
hombres, este problema no resulta nada trivial. Por ejemplo, alguien con
dicromacia roja (o protanopia), verá estas 20 regiones distintas del país,
como apenas variantes de azules y marrones, perdiendo por completo la
utilidad del mapa y de la referencia.
Este problema resultó un claro ejemplo donde, si no se tiene en cuenta la
accesibilidad desde el comienzo y por todos los actores involucrados en un
proyecto, resulta demasiado costoso volver atrás una vez que el
inconveniente fue detectado.
Las alternativas textuales y los contenidistas

Antes de dar comienzo a la carga de contenidos, se capacitó a los
contenidistas en el manejo de imágenes dentro de WordPress, el sistema de
gestión de contenidos que elegimos. No sólo en su diagramación y
posicionamiento, sino que se hizo especial hincapié en la importancia de
asignarles un texto alternativo, con qué criterio hacerlo según el contexto, y
la diferencia entre éste, el epígrafe, y el título de la imagen.
A pesar de ésta capacitación, se nos presentó aquí el clásico problema de
“texto invisible” que genera el atributo “alt” de las imágenes, a saber:
ausencia total de texto alternativo, texto con el nombre del archivo de
imagen, e incluso errores de tipeo y ortografía. Al no ser visible éste texto a
simple vista, resulta trabajoso integrarlo en el proceso de corrección por un
editor, y de auto-corrección por parte del mismo autor.
Tomó asimismo mucho tiempo de revisión y diálogo el aclarar las
diferencias entre el texto alternativo, que describe la imagen, y los
epígrafes, que se complementan con la imagen y le dan sentido.
Una vez que empezamos a recibir los contenidos, nos dimos cuenta de algo
imprevisto para nosotros, que no habíamos contemplado en la capacitación.
Al tratarse de materiales educativos, muchas de las imágenes caen dentro de
la excepción que proveen las Pautas de Accesibilidad para imágenes cuyo
contenido es una prueba o ejercicio para el usuario 15, que dejarían de ser
válidos como evaluación si los describimos. Si una consigna es “observen
las siguientes imágenes de paisajes áridos e identifiquen el factor erosivo”,
es necesario ser muy cuidadosos para no dar la respuesta en el texto
alternativo que proveemos.
La conclusión aquí es que, si bien es importante proveer un sistema que
posibilite o incluso requiera la carga de texto alternativo, es igual de crítico
capacitar a las personas que estarán haciendo esa carga en su uso apropiado,
e incorporar a este texto invisible como parte integral del proceso de
corrección de los contenidos.
Accesibilidad y usabilidad
Si consideramos la accesibilidad como un área de la usabilidad, con
objetivos de “efectividad, eficiencia, y satisfacción” cuyos usuarios
específicos son los discapacitados, y cuyo contexto específico son las
ayudas técnicas 16, no resulta difícil observar que muchas de las Pautas de
accesibilidad están muy cercanas a las recomendaciones de usabilidad.
Especialmente en cuanto a legibilidad, predictibilidad, consistencia, y
prevención de errores.
En este proyecto no hicimos pruebas con personas con discapacidad, pero si
hicimos pruebas de usabilidad con nuestros usuarios objetivo, alumnos de
colegios secundarios. Estas pruebas arrojaron algunos resultados por si
mismos interesantes, desde el punto de vista de la educación mediante
plataformas web, y que además resultan próximos a las problemáticas de la
accesibilidad.
La primer sorpresa con que nos encontramos es que estábamos probando
una interfaz de usuario, pero en realidad muchos alumnos tenían falencias
básicas en geografía. Queríamos probar si se entendía como funcionaba el
superponer un mapa físico con uno político, y el problema no fue de diseño,
sino que desconocían la diferencia misma entre un mapa físico y uno
político. Otros factores similares afectaron las pruebas, como el
desconocimiento del Río de la Plata o la diferencia entre una bahía y un río.
Algunos elementos estándar les resultaron extraños, no estaban
familiarizados con el comportamiento de las casillas de verificación
(checkboxes) por lo que necesitamos simplificar la interacción a botones
grandes de selección simple, dejando la selección múltiple para “uso
avanzado”. Tampoco resultaron intuíbles los botones para expandir y
colapsar información. Sí les resultó natural, en cambio, explorar
rápidamente la página completa, de arriba hacia abajo y de nuevo hacia
arriba, usando la barra de desplazamiento (scroll bar) del navegador.
Se sumó a esto un imprevisto relacionado con el dispositivo de entrada.
Para dibujar sobre los mapas, cuando probábamos en la oficina mientras
desarrollábamos, usábamos el mouse con absoluta ingenuidad, satisfechos
con la posibilidad de trazar el curso de un río, resaltar una región con un
polígono irregular. Al llegar a las pruebas con usuarios, el problema fue
evidente. Los alumnos usaban el trackpad de las netbooks. Al no tener
mouse, muchas acciones que resultan triviales con éste, se vuelven un
pequeño desafío motriz: arrastrar y soltar, o dibujar, con un dedo
deslizándose sobre el trackpad mientras la otra mano mantiene el clic
presionado. En este caso tuvimos que resignarnos, ya que la solución al
problema requeriría volver muy atrás en el proceso de desarrollo.
En definitiva, si bien no probábamos específicamente accesibilidad, la
información y el manejo de la interfaz de usuario se hizo más comprensible,
que es aquí uno de los principios más directamente influenciados por la
usabilidad como disciplina.
Conclusión
Mostramos aquí que resulta posible incorporar estas prácticas sin
desbarrancar el presupuesto, pero no resulta trivial: partimos de una base,
de aprendizajes previos, de decisiones tomadas sobre formas de hacer las
cosas. En definitiva ganar experiencia, que podremos obtener precisamente
al hacer de la usabilidad y la accesibilidad parte de un proceso iterativo,
cotidiano y orgánico; que no opere en forma aislada sino que se integre y
fluya junto al trabajo de redactores, diseñadores y programadores.
Aprendimos que es elemental definir desde un primer momento cuales son
los roles involucrados en el proyecto, y asegurarse de que cada uno conozca
las pautas sobre accesibilidad que competen a su rol. Esto tiene dos
ventajas. En principio, nos permite realizar “accesibilidad preventiva”, ya
que identificado el problema de antemano, en general su solución será de
muy bajo coste, porque pueden buscarse alternativas, no hace falta rehacer
lo que todavía no está hecho. En segundo lugar, la separación por roles
ayuda a dividir la tarea y que no sea algo inabarcable, a la vez que obliga a
cada uno a asumir responsabilidad por la parte que le corresponde, sin
depender del “evangelizador” o experto en accesibilidad que hay en el
equipo.
Vimos la importancia de identificar y generar componentes accesibles que
podamos reutilizar en sucesivos proyectos, no sólo en los planos de diseño
y desarrollo, sino también en lo que respecta a herramientas de capacitación
de los “invitados” a nuestro proyecto, desde contenidistas contratados hasta
líderes de proyecto en el equipo del cliente. Una vez elegido el gestor de
contenido podemos, por ejemplo, hacer un breve video explicando sus
características de autoría accesible.
Entendimos que las Pautas de Accesibilidad y en particular el documento
“Comprender las Pautas 17” nos dan una perspectiva exhaustiva sobre las
barreras que ponemos a las ayudas técnicas, perspectiva que nos sería
imposible adquirir por medio de nuestra propia experiencia, y que nos
permite dar accesibilidad a casos de uso que no tenemos la capacidad de
verificar por cuenta propia. Pero este mismo carácter exhaustivo ha
resultado históricamente intimidante para la comunidad de diseño y
desarrollo, que se vale de herramientas de validación como acceso directo a
la identificación de barreras más evidentes, a veces sin comprender del todo
el problema subyacente.
En este sentido la adopción del lector de pantalla como un agente de usuario
más en la matriz de navegadores que soportamos y verificamos nos permite
dar el siguiente paso, al pasar de lo que es correcto en teoría, a lo
empíricamente verificado. Esto sin olvidar que nuestras pruebas de
laboratorio, aunque bienintencionadas, complementan pero no reemplazan
el probar con usuarios reales, que nunca han visto nuestra aplicación, que
no están familiarizados con la estructura de la página. 18
A nivel organizacional, en un equipo informado por múltiples disciplinas y
múltiples motivaciones de sus miembros, donde los valores más preciados
para unos estarán en franca contradicción con las necesidades de las
personas con discapacidad, resulta imperativo que se priorice la
accesibilidad a nivel gerencia, en las contrataciones, y en la gestión de
proyectos; ya que sólo con prioridades claras podrán despejarse conflictos
de intereses, a favor de individuos y no de estadísticas, a favor de la
inclusión.
Referencias
1. Web de Con Vista Al Mar, http://convistaalmar.com.ar .
2. Veáse al respecto: Denis Boudreau, Desglose de responsabilidades sobre
la accesibilidad por roles, [borrador del W3C WAI, en inglés, consultado en
mayo de 2013].
3. Web de educ.ar, http://educ.ar.
4. El proyecto Mapoteca fue diseñado y desarrollado en Con Vista Al Mar
por Juan Allona, José Allona, Camilo Kawerín y Manuel Razzari, en
conjunto con el equipo de Educ.ar coordinando y supervisando el proyecto,
y un equipo externo de cartógrafos y contenidistas, según consta en
http://mapoteca.educ.ar/creditos. El esfuerzo y la intensidad creativa de
todos ellos hizo posible este proyecto, del que la accesibilidad es solo un
fragmento.
5. Veáse respecto al ROI del DCU el clásico de Aaron Marcus, Return on
Investment for Usable User-Interface Design: Examples and Statistics, [Ver
en línea ROI y DCU] [en inglés, formato PDF, consultado en mayo de
2013]
6. El eXaminator es un servicio de evaluación de accesibilidad desarrollado
por el argentino Carlos Benavidez. Puede usarse en forma gratuita en
http://examinator.ws para un informe rápido en relación a WCAG 2.0.
7. Test de Accesibilidad Web de la Fundación CTIC, España, en
http://tawdis.net .
8. Servicio de Evaluación de Accesibilidad del Centro de Investigación en
Diseño Inclusivo de la Universidad de OCAD, Canadá, en
http://achecker.ca.
9. Barra de Herramientas de Accesibilidad, extensión de Firefox, del Centro
de Tecnologías de la Información y Accesibilidad Web de la Universidad de
Illinois, Estados Unidos, en [Ver en línea barra de herramientas] .
10. NVDA es un lector de pantallas gratuito y de código abierto para
Windows, en http://nvda-project.org.
11. WebAIM es una organización del Centro para Personas con
Discapacidad de la Universidad Estatal de Utah, puede accederse a los
resultados de su encuesta anual en http://goo.gl/DXvVq .
12. Veáse Jakob Nielsen, The Myth of the Genius Designer, 2007, [Ver
"The Myth of the Genius Designer"] en contraposición a Cennydd Bowles,
Looking Beyond User-Centered Design, 2013,
13. Dos populares clientes de mapas son OpenLayers (usado en Mapoteca
por su espectro de funcionalidades y su soporte multi-navegador) en
http://openlayers.org y Leaflet (de más sencillo uso e integración) en
http://leafletjs.com .
14. Comunicación personal con Emmanuelle Gutiérrez y Restrepo,
coordinadora del Seminario SIDAR, durante la 5ta. Jornada “Por una Web
Sin Barreras para las Personas con Discapacidad”, junio de 2012, UTN
Buenos Aires.
15. W3C, Pautas de Accesibilidad para el Contenido Web 2.0, Pauta 1.1.
16. Parafraseando la definición de la norma ISO 9241-11 que aconseja
sobre usabilidad.
17. Ver bibliografía recomendada, W3C Consorcio World Wide Web,
Comprender las Pautas de Accesibilidad para el Contenido Web 2.0.
18. Veáse Yusef Hassan Montero y Sergio Ortega Santamaría, Informe
APEI sobre usabilidad, http://nosolousabilidad.com/manual que alerta sobre
la dificultad en comprender el modelo mental del usuario cuanto más está
involucrado el diseñador con el producto.
Bibliografía
Jim Thatcher, et al., Web Accessibility: Web Standards and Regulatory
Compliance, Estados Unidos, Friends of Ed, 2006. En inglés. En este libro
participan los principales autores y pioneros de la accesibilidad Web, es una
excelente introducción a la problemática, aunque necesita una
actualización.
W3C Consorcio World Wide Web, Comprender las Pautas de Accesibilidad
para el Contenido Web 2.0, [en línea], en su traducción al español por Sofía
Benavidez para SIDAR.org http://goo.gl/1aD7o – o en su versión oficial
más reciente en inglés http://goo.gl/qXJ22 [consultados en mayo de 2013].
Nos aclara casi cualquier duda que podamos tener sobre la teoría o práctica
de la accesibilidad Web.
Gez Lemon, pionero de la accesibilidad web y miembro de Paciello Group,
ha escrito una completa introducción a la especificación WAI-ARIA que se
encuentra disponible en español en [Ver WAI-ARIA en español]
[consultado en mayo de 2013].
Weblogs recomendados
http://accesibilidadenlaweb.blogspot.com - Sergio Luján Mora es Profesor e
investigador en la Universidad de Alicante. Tiene una introducción al tema .
http://olgacarreras.blogspot.com - Olga Carreras es consultora, referente
para la comunidad de habla hispana. Publica artículos propios; y resume y
traduce artículos, papers e informes de actualidad internacional.
http://blog.paciellogroup.com - Escriben, entre otros, Mike Paciello, uno de
los fundadores de la WAI, y Steve Faulkner, uno de los editores de la
especificación HTML dentro del W3C. En inglés.
http://deque.com/blog - Deque Systems es una de las grandes consultoras en
accesibilidad, desarrolladores de herramientas profesionales y gratuitas de
validación. En inglés.
http://www.marcozehe.de - Marco Zehe es un desarrollador que trabaja para
Mozilla en Accesibilidad. Previamente trabajó para la empresa que
desarrolla JAWS, el popular lector de pantalla. En inglés.
Capítulo 15: Elaboración de una Normativa de Usabilidad y
Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, por
Verónica Traynor
Diseñadora web con orientación en comunicación visual, a su vez estudió
Gestión de Recursos Humanos y Marketing. Durante el año 2009 llegó a ser
responsable del área de Usabilidad y Accesibilidad Web del Gobierno de la
Ciudad de Buenos Aires (GCBA), donde colaboró en la normativa que
explaya en este capítulo. Luego continuó especializándose en usabilidad de
e-commerce y sitios bancarios. Es Profesora Invitada DIEAU:
Especialización en Diseño de Interacción con estándares de accesibilidad y
usabilidad en la Universidad Tecnológica Nacional. Actualmente trabaja
como Consultora Independiente de Usabilidad y Experiencia de Usuario
para clientes en Estados Unidos, Europa y Latinoamérica.
Más información:
Ingresar al LinkedIn de la autora
Twitter: @verotraynor
Elaboración de una Normativa de Usabilidad y

Accesibilidad Web: El caso de la web de la
Ciudad de Buenos Aires
Introducción: El objetivo y el contexto

tecnológico
En el año 2009 como responsable de la incipiente área de Usabilidad y
Accesibilidad Web del Gobierno de la Ciudad de Buenos Aires (GCBA), mi
labor era validar los sitios que pronto serían publicados. La mayor parte era
diseñada y desarrollada por empresas externas y al momento de hacer las
evaluaciones, los proyectos se encontraban en su fase de cierre.
En esos años, las empresas de software contratadas carecían de
conocimientos sobre usabilidad y accesibilidad web.
Sus equipos estaban, en su mayoría, conformados por ingenieros ajenos
desde su formación a cuestiones vinculadas con relaciones humanas y, por
diseñadores gráficos nuevos en el mundo de Internet, orientados a
cuestiones estéticas o a paradigmas del mundo no Web. Sus procesos no
contaban con pruebas con usuarios, sus decisiones de interacción no se
basaban en investigaciones empíricas y su enfoque no era la construcción
de un diálogo humano-computadora.
La arquitectura de la información (AI) de los sitios se formulaba de acuerdo
a los modelos mentales de la propia gente del proyecto; por lo tanto la
psicología considerada no era la de las personas que iban a interactuar, sino
la de sus propios fabricantes.
Ejemplo de un sitio para mamás, cuyo el mensaje de ayuda dice: “Debes
tener un bebé como mínimo”. ¿Se encuentra adaptado a la comunicación
necesaria para una madre?
El usuario - en caso de ser nombrado - funcionaba como un ser justificador
imaginario. Los miembros del equipo solían asegurar en base a
presuposiciones, de qué modo iría a razonar el ser humano ajeno al
proyecto y cómo sería su interacción con la interfaz. Nos encontrábamos
frente a mecanismos proyectivos, autorreferenciales y arbitrarios. El
paradigma implicaba que eran las personas quienes debían esforzarse para
comprender y aprender la lógica impuesta por la interfaz con el fin de
intentar lograr sus objetivos.
La usabilidad como requisito

En ese entonces, la usabilidad de las interfaces no era planteada como
requisito para los proveedores desde el inicio de los proyectos. Por lo tanto,
a la hora de hacer la evaluación, su legítimo cuestionamiento era: “¿Acaso
el usuario no debe hacer el esfuerzo de aprender? ¿Cómo se mide la
usabilidad? ¿Dónde se encuentra definido?”.
Ejemplo de una ventana que les permite a los usuarios subir imágenes. Las
personas deben comprender que el botón “Close this window” es el que les
permitirá continuar con su navegación.
Esto creó la oportunidad y el desafío de escribir una normativa que resultara
de guía para los desarrolladores y los acompañe durante el proceso de
trabajo; en lugar de aparecer de un modo sorpresivo e intimidante en el
momento de intento de cierre.
Comprensión de las características de los

usuarios: escenarios humanos
Al plantear una interfaz, el primer interrogante a definir es quiénes serán los
sujetos que necesitarán entablar un vínculo con la máquina. Esto implica la
necesidad de comenzar cada proyecto con una etapa de investigación que le
explique y le cuente al equipo interdisciplinario, en qué escenarios se
encontrarán las distintas personas al momento de necesitar o desear
interactuar con la interfaz; cuáles son sus características físicas, culturales,
tecnológicas y sociales; y con qué expectativas tanto funcionales como
emocionales se acercarán al producto. Nos referimos entonces a acercarnos
a los usuarios para comprender sus problemáticas y sus escenas reales de
uso. Se trata de una etapa para comprender al otro interlocutor, con el fin de
humanizar la lógica del sistema y humanizar el diálogo.
El nuevo foco de este paradigma

Para diseñar interfaces centradas en los usuarios, es necesario replantear el
proceso de desarrollo en cascada para convertirlo en algo más semejante a
un espiral.
En la forma tradicional, las interfaces se analizaban y diseñaban en
abstracto, desenfocadas de las necesidades para el aprendizaje de las
personas; y se desarrollaban para que los sujetos se adapten.
En la filosofía del Diseño Centrado en el Usuario (DCU) el paradigma
cambia. La construcción de los flujos y las interfaces pasa a ser un
momento lúdico donde la metodología de trabajo incluye pruebas con
usuarios y el eje pasa a ser el ser humano con sus necesidades de
percepción, comprensión, operabilidad y aprendizaje.
Valentín Muro, quien se refiere a la ética del juego, nos dice: “Si nos
consideramos ‘jugadores’ y no meros ‘trabajadores’ ampliamos
inmediatamente la idea que tenemos de nosotros mismos y de lo que somos
capaces de hacer. Cuando jugamos existe un desafío, algo que se resiste,
que nos invita a indagar, por eso el juego es una de las mejores formas de
aprender. Se comprende jugando”.
El objetivo de los creadores de interfaces al construir una interacción, es
aprender sobre el ser humano. Y desde mi percepción: este aprendizaje se
logra jugando. Por lo tanto, las decisiones dejan de basarse en cuestiones
accidentales, verticalistas o arbitrarias. Todo gira en torno a la observación
empírica y metodológica de personas aprendiendo e interactuando. Esta
forma de trabajo evolutiva y en espiral les permite a los integrantes del
equipo avanzar y aumentar la calidad de sus bocetos de un modo más
certero; según los modelos mentales ya no de ellos mismos, sino de los
usuarios finales.
En conclusión, en este paradigma el foco es el vínculo que se genera entre
las personas y las interfaces; la metodología es la observación empírica de
esa dialéctica y la forma de trabajar es evolutiva y lúdica.
La observación como metodología

Resulta importante señalar que en nuestro proceso de investigación,
necesitamos distinguir entre las opiniones de los usuarios y la operabilidad
observada. Existe una diferencia significativa entre lo que les sucede a los
usuarios, lo que interpretan sobre lo ocurrido y lo que opinan que les
sucedió. El análisis del discurso sirve para medir la percepción, pero no nos
será suficientemente útil para comprender la raíz del problema del vínculo,
del cual los usuarios pueden llegar a no ser conscientes. Valentín Muro, en
la misma plática, habla sobre desarmar las cosas para comprenderlas:
“Hablo de entender como cuando desarmábamos los juguetes para ver
cómo funcionaban. Creo que la importancia de entender cómo funcionan las
cosas está en el poder que nos da para cambiar cómo funcionan”.
Cuando trabajamos en diseño de interacción es lo mismo: desarmamos con
nuestra observación los mecanismos del diálogo que se está generando, para
poder adaptar nuestra máquina a lo humano. Esto nos permitirá comprender
en profundidad la dialéctica generada, hacer modificaciones en las
interfaces y volver a hacer pruebas para validar la efectividad del cambio.
Se trata de un proceso cíclico, ágil y dinámico basado en la observación de
los seres humanos interactuando.
Los colores como parte del diálogo

Una vez definida la arquitectura de información y los mecanismos de
navegación, se deberá definir la estética. En este paradigma, la razón de ser
de los colores experimenta una metamorfosis de su función tradicional,
ubicándose al servicio de la señalética.
Me remito a dos conceptos del signo lingüístico.
La arbitrariedad: el vínculo que une el significado con el significante es
arbitrario.
La inmutabilidad: el signo precisa quedar instalado y no ser mutante.
Los elementos interactivos pasan a ser signos lingüísticos que precisan ser
aprendidos; por lo tanto son arbitrarios, pero necesitan consistencia para
generar estabilidad, orientación y diálogo.
En una interfaz, la función fundamental del color es la colaboración en el
aprendizaje y la comprensión del ser humano. Por lo tanto, dejamos de
hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero
fundamentalmente claro.
Aquí, sumado a la usabilidad, incorporamos los Lineamientos
Internacionales de Accesibilidad Web -que se explican debajo- como
referencia y respaldo: La accesibilidad como un derecho humano.
Primera versión de la Normativa de Usabilidad y

Accesibilidad Web
Aquí detallo la normativa de Usabilidad y Accesibilidad Web publicada el
año 2010 junto con su breve guía para desarrolladores. La misma es digna
de ser leída, pero con una necesidad suprema de ser actualizada. Los
lineamientos de accesibilidad y usabilidad web son:
1. Ámbito de Aplicación
Las disposiciones a las cuales se refiere la presente resolución son de
obligatorio cumplimiento para todos los sitios web pertenecientes al
Gobierno de la Ciudad Autónoma de Buenos Aires.
2. Objetivos
Los objetivos de la presente resolución son:
2.1. Garantizar un acceso equitativo a la información.
2.2. Contribuir con la construcción de un Gobierno que preste mejores
servicios a los ciudadanos, facilitando a los usuarios el alcance de objetivos
con eficacia y satisfacción a través de la optimización de las tecnologías de
información y comunicación.
3. Definiciones de usabilidad y accesibilidad

web
Un sitio web es accesible cuando sus contenidos son perceptibles,
comprensibles y operables para todo tipo de usuarios, independientemente
de sus capacidades, tipo y dispositivo de acceso a internet, sistema
operativo y/o programas utilizados.
La usabilidad es una medida empírica que califica qué tan fácil, rápido y
agradable es un sitio web para un cierto tipo de usuario, evaluando
determinado tareas y contextos de uso.
4. Definición de políticas y estándares de

accesibilidad
El Consorcio W3, organismo internacional encargado de crear y supervisar
los estándares en la Web, ha publicado una serie de pautas denominadas
Directrices1 de Accesibilidad del Contenido Web 2.0. (Versión en inglés
Web Content [Ver en línea Accessibility Guidelines WCAG-2.0] .
Traducción recomendada (aunque no oficial en español), las cuales son
aceptadas internacionalmente.
Las Pautas se organizan en cuatro principios básicos que constituyen su
base filosófica (perceptible, operable, comprensible y compatible). Las
mismas se encuentran clasificadas por niveles de conformidad (A, AA,
AAA).Las aplicaciones y sitios web pertenecientes a los organismos
mencionados, creados a partir de abril de 2010, deberán alcanzar el nivel de
conformidad AA. Las aplicaciones que ya se encuentran en vigencia
deberán adoptar dichas pautas en un plazo de dos años a partir del momento
en que la presente resolución entre en vigencia. Para verificar este aspecto
deberán utilizar como referencia las herramientas de validación descritas en
la de Guía de Usabilidad y Accesibilidad Web detallada debajo.
5. Adopción de una Guía de Usabilidad y

Accesibilidad Web
El área de Usabilidad y Accesibilidad Web creará una Guía para los
desarrolladores la que deberá ser solicitada al inicio de cada proyecto.
Debido a la dinámica propia de las tecnologías de comunicación, la
información de esta Guía, podrá actualizarse periódicamente. Para cada
proyecto se establecerá cuál es la versión de los lineamientos a aplicar los
que serán de obligatorio cumplimiento por parte de las entidades a las
cuales se refiere la presente resolución.
1. Requerimientos de Usabilidad
Se solicita a los diseñadores que entreguen al área de Usabilidad y
Accesibilidad Web del GCBA, los informes detallados debajo durante el
proceso de desarrollo, con el fin de garantizar que las aplicaciones y sitios
web del GCBA - ya sean de Internet o Intranet - cuenten con las siguientes
propiedades:
Facilidad de ser aprendido: que sean lo suficientemente fáciles de aprender,
de modo que los usuarios puedan rápidamente comenzar a utilizarlos sin
mayores inconvenientes.
Eficiencia: que permitan un alto grado de productividad.
Recordabilidad: que la modalidad de uso sea tal, que un usuario que no los
ha utilizado por un tiempo, pueda volver a utilizarlos, sin tener que
aprender nuevamente sus operatorias.
Baja tasa de errores: que al utilizarlos, los usuarios tengan una baja tasa de
errores y en caso de cometer equívocos, que el sistema disponga
alternativas sencillas para solucionarlos.
Satisfacción: que dejen una impresión subjetiva positiva en el usuario.
1.1. Informe 1: Perfiles, tareas y objetivos de

usabilidad
A partir de los objetivos establecidos en el inicio de la contratación, el
informe deberá contener los siguientes contenidos:
Análisis de los perfiles de usuarios que ingresarán al sitio.
Tareas principales.
Tiempo máximo estimado para efectuar cada tarea.
Tasa de errores aceptables para el usuario que ingresa por primera vez al
sitio.
Este informe deberá ser consensuado y validado por el área de Usabilidad
del GCBA, para luego testear los prototipos con usuarios reales.
1.2. Informe 2: Reporte de pruebas con usuarios

y documentación de cambios
Se deberá entregar un informe de las pruebas realizadas a los usuarios en las
distintas etapas del proyecto. Además, éste incluirá la documentación sobre
los cambios efectuados a partir del análisis de las mismas.
1.3. Evaluación de resultados de pruebas con

usuarios
El Área de Usabilidad y Accesibilidad Web del GCBA comparará los
resultados de los informes de los proveedores contra los realizados por
personal del gobierno, para verificar su validez; pudiendo solicitar
modificaciones sobre el diseño de la interfaz.
La evaluación del GCBA estará basada en los siguientes lineamientos:
1. Lenguaje: El lenguaje utilizado en las interfaces debe corresponder con el
lenguaje del usuario, tanto en idioma como formas de éste. El nivel del
lenguaje a utilizar estará determinado por los perfiles previamente
definidos.
2. Visibilidad del estado del sistema: La aplicación deberá mantener
informado al usuario sobre lo que está ocurriendo en cada momento.
3. Consistencia: Es necesario mantener la consistencia de la interfaz en
todos los aspectos y dimensiones de la interacción.
4. Flujo de trabajo y prevención de errores: El diseño de la interfaz debe
estar focalizado en guiar al usuario a cumplir su objetivo, evitando
divergencias que obstaculicen su tarea.
5. Prefiera elegir antes que recordar: Evite utilizar la memoria del usuario
como recurso.
6. Simplificación de las interfaces: En las interfaces debe predominar la
simplicidad por sobre la complejidad para facilitar la ejecución de las tareas
a los usuarios.
7. Ayudas: Las ayudas deben estar dispuestas, de un modo contextual y
visible, en el momento y lugar que sean necesarias.
8. Correcto uso de opciones por defecto: Las opciones seleccionadas por
defecto deben ser acordes al uso más frecuente o recomendado.
9. No brindar información que pueda desorientar al usuario: La información
que se presenta debe ser la que el usuario requiere en el momento.
10. Mensajes de error: Todo mensaje de error debe señalar el campo en
cuestión (la indicación no basarse sólo en el color, sino debe estar
acompañado de un ícono). La explicación de lo ocurrido debe evitar un
lenguaje técnico y debe ofrecer soluciones.
2. Requerimientos de Accesibilidad
2.1 Herramienta de validación automática

Para verificar la accesibilidad, se deberán utilizar como referencia las
siguientes herramientas de validación:
http://tawdis.net
W3C Tool
2.2 Listado de verificación de accesibilidad

adaptado a las necesidades del GCBA
Como herramienta de verificación, hemos redactado un listado adaptado a
las necesidades del Gobierno de la Ciudad Autónoma de Buenos Aires
dividido por las áreas de trabajo de diseño y maquetación.
2.2.1. Listado de verificación para el área de

diseño
Navegación: En caso de contar con sub-secciones ¿Incluye Mapa de Sitio o
Tabla de Contenidos?
¿Los elementos comunes están localizados en la misma posición en todas
las pantallas?
¿Los elementos interactivos se comportan de la misma forma todas las
veces que aparecen?
Textos: ¿Se distingue el color de los textos de su color de fondo?
Enlaces: ¿Se diferencian los enlaces del resto de los textos por su color,
subrayado u otra característica?
¿Cuentan todos los enlaces – ya sean textos, botones o íconos – con estado
Roll Over? (Se satisface con el atributo de CSS a:hover)
¿Queda señalada la solapa (botón/enlace) dónde se encuentra el usuario?
¿Los textos de los enlaces son lo suficientemente explícitos en su destino?
¿No existen hipervínculos distinguidos con las frases “click aquí” o “+
info”?
¿Cambian los colores de los enlaces ya seleccionados?
Colores: ¿La información transmitida a través de los colores también está
disponible sin color?
2.2.2. Listado de verificación para el área de

maquetación
HTML Y CSS
¿Las etiquetas utilizadas son sintácticamente correctas?
¿Están íntegramente independizados los estilos a través de CSS?
¿El uso de tablas se restringe a la tabulación de datos y no para diagramar el
contenido del Sitio Web?
¿Se puede navegar el Sitio íntegramente (incluyendo objetos incrustados) a
través de un teclado?
¿Existe alguna función crítica del sitio incluida en algún objeto de Flash y
está verificado que sea accesible?
Identificación del lenguaje:
El lenguaje está identificado de esta forma: <HTML lang=”es”>
Las abreviaturas se encuentran señaladas con el atributo <abbr>? (Ejemplo
“Alte”: <abbr title=”Almirante”>Alte.</abbr>)
Las abreviaturas se encuentran restringidas a las definidas por la Real
Academia Española (RAE).
¿Los acrónimos se encuentran señalados con el atributo <acronym>?
Ejemplo: “GCBA”: <acronym title=”Gobierno de la Ciudad de Buenos
Aires”> GCBA </acronym>)
Imágenes y animaciones:
¿Todas las imágenes y animaciones cuentan con un texto alternativo?
¿Los textos alternativos representan una alternativa válida para transmitir la
misma información que comunica el formato no textual? (NOTA: Quien
elabore el contenido debe proveer el texto alternativo para las imágenes
informativas, de forma que el programador pueda incluirlas) Ejemplos: El
texto alternativo de un banner debe incluir la descripción de los objetos y/o
textos que figuran en la imagen. No debe decir “banner”.El texto alternativo
de una flecha (botón) debe decir “siguiente” o “volver”. No debe decir
“flecha”.
¿Todas las animaciones pueden ser controladas (pausadas) por el usuario?
Multimedia
¿Los audiovisuales o archivos de audio se encuentran subtitulados o
incluyen el texto en un archivo tipo HTML u RTF?
¿La voz principal se distingue con facilidad del sonido ambiente?
PDF
¿Los documentos PDF pueden ser interpretados por un lector de pantallas
para no videntes? (validar con un lector de pantallas como NVDA)
Las imágenes del PDF ¿cuentan con un texto alternativo?
Si un documento PDF no fuera accesible, ¿existe una versión alternativa
accesible en HTML u RTF?
¿Todos los enlaces se encuentran acompañados con el ícono identificativo
de Adobe PDF?
Formularios: Carteles de error
¿Evitan el lenguaje técnico?
¿Señalan el campo en cuestión (basándose no sólo en el color sino
acompañándolo también de un ícono)?
Conclusiones
Las principales conclusiones del caso de Elaboración de una Normativa de
Usabilidad y Accesibilidad Web para la web de la Ciudad de Buenos Aires
han sido:
Que una interfaz es un objeto comunicacional que necesita profesionales y
procesos centrados en la psicología de los usuarios.
Que el diseño centrado en el usuario implica un cambio de paradigma y
precisa un replanteo de los flujos y roles de trabajo, justamente porque es
un proceso cíclico, ágil y dinámico basado en la observación de los seres
humanos interactuando.
Bibliografía
Norman, Donald, The design of Everyday Things.
Web Content Accessibility Guidelines (WCAG) 2.0, W3C
Recommendation, 11 Diciembe 2008.
Capítulo 16: Internacionalización Web, por Claudio Segovia
Difusor de temas relacionados con Internet, el software libre y la
presentación de la información en forma equitativa y accesible para todos.
Investigador, docente y consultor en accesibilidad en Internet. Miembro del
grupo de expertos de Seminario Iberoamericano de Accesibilidad a la Red (
SIDAR ). Miembro del grupo de Accesibilidad del capítulo argentino de la
Internet Society. Disertante en eventos nacionales e internacionales sobre
accesibilidad web e internacionalización en Internet.
Actualmente es docente de computación, tecnología, matemáticas y diseño
web y coordinador del club de ciencias “Misterios de la ciencia”.
Más información:
Internacionalización web
Introducción
Lo deseemos o no, vivimos inmersos en algo llamado globalización,
intentando aprovechar sus beneficios y también sufriendo sus
consecuencias.
Los últimos años nos han hecho cada vez más conscientes de la unidad
pero, al mismo tiempo, de la diversidad de la sociedad mundial. Por más
que algunos hayan insistido, no todo el mundo festeja Navidad, ni habla un
mismo idioma, ni comprende lo mismo con un gesto. La Web, desde sus
inicios, tiene una estructura internacional, por lo que en el transcurso del
diseño de un sitio web nos encontramos con una de sus consecuencias, que
es la forma en que debemos manejarnos ante las diversas culturas de los
distintos usuarios.
Conviene recordar que, una vez que creamos nuestra primer página web, y
aunque hablemos en ella de temas locales, será visitada por usuarios de
lugares muy diversos, en donde la cultura y todo lo que esto genera (modo
de hablar, escribir, medir el tiempo, formas de comparación y
ordenamiento, de usar el calendario... y un extenso etc.) puede ser muy
distinto.
¿Por qué nos puede interesar la

Internacionalización web?
Para que nuestra propuesta llegue a más clientes / usuarios / votantes /
colaboradores / asociados / fans / donantes / seguidores… etc..
Porque se utilizan los recursos de forma más eficiente, ya que implementar
la internacionalización como parte del proceso de desarrollo original
requiere menos recursos para pruebas y desarrollo que si se agrega la
compatibilidad después de comenzado el trabajo de desarrollo inicial.
Para promover un acceso a la información más amplio y justo para mayor
cantidad de personas.
Porque constantemente se suman nuevas herramientas que permiten usar
este conjunto de técnicas.
Se puede agregar rápidamente compatibilidad para nuevas referencias
culturales, ya que una vez finalizado el sitio inicial, no se necesitará ningún
desarrollo adicional para crear versiones traducidas. Sólo será necesario
traducir los recursos del sitio para la referencia cultural de destino.
Por curiosidad intelectual.
Una vez definidas las razones para “tener en cuenta al otro” (frase que guía
también otras áreas, como la accesibilidad web o la web semántica),
veamos qué pautas hay que tener en cuenta para hacer esto.
La Iniciativa de Accesibilidad a la Web (Web

Accessibility Initiative – WAI)
Existen varias pautas que intentan indicar de qué forma debemos tener en
cuenta la internacionalización web, pero se recomienda, por su origen,
tomar las incluidas en la Iniciativa de Accesibilidad a la Web 1, del
Consorcio W3C 2.
Como se sabe, hubo, en 1999, una versión 1.0 de estas pautas y en el año
2008, teniendo en cuenta los problemas y nuevas tecnologías que fueron
apareciendo, salieron las pautas versión 2.0. Veamos qué dice esta versión.
WAI versión 2.0 3 Pauta 3.1: “Legibilidad: Cree

contenidos legibles y fáciles de entender.”
Criterio de cumplimiento 3.1.1, nivel A: “Idioma de la página: El idioma
humano predeterminado de cada página web puede ser determinado por un
programa.”
Criterio de cumplimiento 3.1.2, nivel AA: “Idioma de las partes: El idioma
humano de cada pasaje o frase en el contenido puede ser determinado por
un programa, excepto los nombres propios, términos técnicos, palabras en
un idioma indeterminado y palabras o frases que se hayan convertido en
parte natural del texto que las rodea.”
Criterio de cumplimiento 3.1.6, nivel AAA: “Pronunciación: Se
proporciona un mecanismo para identificar la pronunciación específica de
las palabras cuando el significado de esas palabras, dentro del contexto,
resulta ambiguo si no se conoce su pronunciación.”
¿Cómo hacer esto?

La internacionalización de un sitio web, como vimos, no se refiere
solamente a crear un sitio multilingüe. Enumeremos los distintos aspectos,
para luego entrar en detalles:
Codificación de lenguas.
Negociación de contenidos.
Despliegue de caracteres e ideogramas.
Dirección del texto.
Uso semántico.
Evitar la ambigüedad lingüística.
Formatos de fechas y calendarios.
Preferencias del navegador.
Direcciones web multilingüales.
Comparación de cadenas o reglas de ordenación.
Ruby.
Otros: Colores , símbolos, gestos, direcciones postales, localismos...
Codificación de lenguas
Normas. Cada lengua tiene un código unívoco que la identifica y diferencia
del resto. En el principio, se intentó hacer esto a través de una norma ISO:
la ISO 639. Esta norma es de 1988 que actualmente consta de 6 partes.
Además hay otras normas que intentan complementarla o mejorarla.
Código. Una vez que sabemos de dónde sacar los códigos correspondientes
a cada lengua, veamos cómo “hacer la etiqueta” para los distintos lenguajes:
HTML. Si todo el texto de la página está escrito, por ejemplo, en guaraní,
agregaremos a la etiqueta <html> lo siguiente: <html lang=”gn”> Donde gn
es el código correspondiente al guaraní En el caso que insertemos en un
texto de un idioma una palabra o frase de otro, deberemos agregar el
atributo lang en la etiqueta span, por ejemplo: En mapuche, gente o
pueblo se dice che.
XHTML. Por compatibilidad entre HTML y XML, usaremos la siguiente
sintaxis: <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”es”
lang=”es”>
XML. Usaremos la etiqueta xml:lang de la siguiente forma: En
mapuche, gente o pueblo se dice che.
Negociación de contenidos
Uso de HTTP. El protocolo HTTP es el más usado por la Web. De hecho, es
el que nos permite ver y navegar las páginas web. Cuando un navegador se
conecta con un servidor web remoto, no sólo le solicita la página cuya
dirección el usuario ha escrito sino que le informa de detalles del
navegador, de la página solicitada, etc.
Luego, una vez que la conexión se realiza, el servidor también contesta
enviando una respuesta HTTP y a continuación la página solicitada.
Uso de HTTP desde el servidor. Es importante asegurarse de que toda
información sobre idioma y codificación de caracteres enviada por el
servidor web sea correcta, dado que la información incluida en el
encabezado HTTP anula la información que contiene el documento mismo.
Codificación de caracteres
La información de codificación inadecuada no sólo perjudica la capacidad
de lectura de un texto que se visualiza, sino que, además, puede significar
que sus datos no se encuentren en una búsqueda o que no se puedan
procesar de manera confiable de diversas formas.
Algunos ejemplos de caracteres incluyen la letra latina acentuada “á”, el
ideograma chino “請” o el caracter devanagari “ ”.
Los caracteres se agrupan en un conjunto de caracteres o set. Cuando a cada
carácter se le asigna un número en particular, a eso se lo denomina un set de
caracteres codificados.
Desafortunadamente, existen muchos sets y codificaciones de caracteres,
por lo que se intenta corregir con la iniciativa Unicode.
Unicode. Es un estándar de codificación de caracteres hecho para ayudar en
la visualización de textos de múltiples lenguas. Actualmente, la última
versión de Unicode es la 6.3.
La forma de codificación de datos de Unicode simplifica el desarrollo de
aplicaciones y sitios web de uso internacional, porque permite que todos los
caracteres internacionales estén representados con una única codificación.
Declaración del conjunto de caracteres. El Consorcio W3 dice 4 que todo
documento transmitido por HTTP que sea de tipo texto (texto plano,
HTML, etc.) debe tener un parámetro charset que especifique la
codificación de caracteres del documento.
<meta http-equiv=”Content-type” content=”text/html; charset=ISO-8859-1
“ />
<meta http-equiv=”Content-type” content=”text/html; charset=utf-8” />
Dirección del texto. Conviene recordar que existen varias lenguas que se
leen de derecha a izquierda:
Hebreo.
Árabe.
Sirio.
Persa.
Etc.
Además, algunas lenguas ideográficas, como el japonés, coreano, mongol o

el chino mandarín, son más flexibles en su dirección de escritura. En
algunos casos se escriben de izquierda a derecha o verticalmente de arriba
hacia abajo, aunque también se escriben (verticalmente) de derecha a
izquierda. Algunos diarios chinos, por ejemplo, a veces combinan todas
esas direcciones de escritura en una misma página 5.
¿Cómo trabajar con ellas?
Declarar Unicode para la página: <meta http-equiv=”Content-type”
content=”text/html; charset=utf-8” />
Si no todo el texto está escrito en una lengua, declarar el cambio de
dirección cuando se produce en el código: Texto en español ‫<ﻣﻔﺘﺎح ﻣﻌﺎﻳﻴﺮ اﻟﻮﻳﺐ‬/span> texto en
español.
También podemos agregar una traducción para el caso que algún usuario
use un navegador que admita la opción title: Estos países son Bahrein,
‫<ﻣﺼﺮ‬/span> y Kuwait.
Además, conviene recordar que, como occidentales, la costumbre de ver
una imagen o la estructura de un diario o sitio web de izquierda a derecha
tiene que ver, en parte, con que aprendimos a leer en esa dirección. Por esto,
también debemos pensar que deberemos cambiar la estructura de nuestro
sitio web si el mismo está destinado a un público habituado a leer de
derecha a izquierda 6.
A esto último (inversión del diseño de las ventanas, los menúes, los cuadros
de diálogo y demás elementos visuales de un sitio web) se lo llama, en
diseño web, reflejo 7.
Uso semántico
Ya en accesibilidad web se ve la necesidad de tener en cuenta el marcado
semántico. En internacionalización también se puede ver el resultado de
esto.
Asi, por ejemplo, debemos recordar que si enfatizamos un texto, debemos
usar la etiqueta y no la etiqueta . Esto se volverá más evidente si
el texto no está en una lengua occidental conocida, sino en otras como el
japonés, donde los ideogramas etiquetados con no mostrarán
visualmente ninguna diferencia con el resto del texto. En cambio, si usamos
, luego podremos darle con CSS2 un recuadro sombreado a esos
ideogramas (una de las opciones usadas en japonés, llamado amikake), o
indicarle que muestre un pequeño círculo sobre cada ideograma con CSS3
(la opción más común en japonés para mostrar énfasis, llamado Wakiken 8):
Si nuestro texto está en tibetano, pasará algo parecido. En esta lengua se
usan dos pequeñas marcas debajo de cada sílaba enfatizada, por lo que un
buen uso del marcado semántico nos ayudará 9:
En cirílico, el énfasis puede aparecer de varias formas:
Como un símbolo parecido a la tilde de nuestra ñ (й, ў).
El texto puede adoptar formas redondeadas 10.
Puede cambiar completamente de forma 11.
Evitar la ambigüedad lingüística

Una palabra puede ser muy clara en un idioma, pero no tanto al traducirla a
otro, por lo que debemos tener en cuenta esto a la hora de programar y
diseñar.
Por ejemplo, la frase “Empty folder” puede resultar un texto claro en inglés,
pero puede resultar una construcción ambigua al intentar traducirla a otro
idioma, ya que las cadenas se pueden traducir de forma diferente según las
funciones gramaticales de los componentes de dichas cadenas. Así, “empty”
puede ser tanto un verbo como un adjetivo y esto puede llevarnos a
traducciones diferentes en idiomas como el italiano o el francés.
Se recomienda, dependiendo de cada caso, que los sitios web tengan
referencias culturales e idiomáticas neutras.
Formatos de fechas y calendarios

El carácter internacional de Internet hace que nos encontremos con diversas
formas de representar las fechas, además de los calendarios no gregorianos:
Estados Unidos: 11/08/2012
Europa y parte de Latinoamérica: 08/11/2012
Japón: 2012年 11月 8日
China: 2012年 11月 8日12
Esto nos recuerda que, por más que nos parezca común, nuestra forma de
mostrar una fecha no es la común para todos en el mundo.
Calendarios. Actualmente coexisten en el mundo más de 40 calendarios 13:
Gregoriano.
Hebreo.
Árabe.
Japonés.
Coreano.
Chino.
Persa.
Etc.
¿Cómo atender a las necesidades de tal

variedad de usuarios?
Usar un formato local neutro. La norma ISO 8601 especifica que las fechas
se deben mostrar en el formato AAAA-MM-DD.
A favor: No resulta ambiguo. Es amigable para los usos informáticos que
deseemos darle a la fecha (bases de datos, búsquedas, ordenamientos, web
semántica, etc.).
En contra: No es un formato amigable para las personas. Ocupa más
espacio que una fecha en formato común.
Resulta confuso para los usuarios de países que tienen un calendario
alternativo, como por ejemplo en Tailandia, donde usan el calendario
budista. Explicitar los meses y años hasta la obviedad. Usar nombres para
los meses (abreviados o no) y 4 dígitos para los años.
A favor: No resulta ambiguo. Es amigable para los usuarios.
En contra: Es muy poco amigable para los usos informáticos. Ocupa más
espacio.
En algunas lenguas el uso de tres letras para el mes puede resultar
problemático (en francés, Junio y Julio son Juin y Juillet). No siempre los
meses serán fácilmente reconocibles en distintas lenguas (para un español
no hablante de inglés, Jan no le significará Enero).
Usar la cabecera de HTTP Accept-Language. La cabecera HTTP Accept-
Language, especifica las preferencias de la lengua del usuario, pero también
es usada para determinar preferencias locales 14.
A favor: No resulta ambiguo. Es amigable para los usuarios.
En contra: Este método funciona principalmente para páginas web
dinámicas, donde se inserta la fecha desde un almacenamiento externo. No
todos los servidores permiten configurar esta opción.
Preferencias del navegador

Cuando un navegador pide un documento a un servidor, y el servidor tiene
varias versiones de una página en distintos idiomas, esta información puede
usarse para recuperar la página en el idioma preferido. Si hay una única
versión de dicha página en ese servidor, esa es la que se recuperará.
La mayoría de los navegadores permiten cambiar las preferencias del
idioma, cuyo valor, como ya dijimos, es definido por las normas ISO 639,
que le brinda un código de dos o tres letras a cada idioma, seguido por un
subcódigo opcional de dos letras por país, por ejemplo: es para español y
es-AR para el español de Argentina.
En algunos navegadores es posible establecer más de un idioma, dándoles
un orden de preferencia, como se muestra a continuación:
Direcciones web multilingüales

Una dirección web es usada para apuntar a un recurso en la Web, como una
página web. Estas direcciones se expresan a través de Identificadores
Uniformes de Recursos. La sintaxis de las URIs restringe las direcciones
web a un pequeño número de caracteres:
Letras mayúsculas y minúsculas del alfabeto en inglés.

Numerales europeos.
Un pequeño número de símbolos.
Esto se debe a que la Web comenzó a desarrollarse en el ámbito

angloparlante. Pero al poco tiempo se vio que este ámbito se ampliaba a
pasos agigantados haciendo necesario el tener que usar caracteres de
cualquier lenguaje en las direcciones web. Una dirección web en nuestra
propia lengua es fácil de crear, recordar, transcribir, interpretar y relacionar.
Y esto nos lleva a mejores negocios, mejorar las búsquedas y las
comunicaciones. En resumen, mejora la Web.
Para lograr esto existe algo llamado Identificador de Recursos
Internacionalizado o IRIs. Actualmente varios formatos soportan IRI, pero
desgraciadamente, no muchos protocolos. Así, es posible encontrar una
dirección como la que sigue: http://納豆.例.jp
En donde la declaración del protocolo (http://) debe estar en caracteres
ASCII, mientras que el dominio es una mezcla de caracteres ASCII con
japoneses. Aquí aparece Unicode, transformando la dirección web en
caracteres ASCII de la siguiente manera: http://xn--jp-cd2fp15c.xn--fsq.jp
… para luego poder resolver dicha dirección en una dirección IP numérica.
Y esto no sólo es necesario para lenguas orientales. Veamos, por ejemplo, la
siguiente dirección sueca: http://räksmörgås.josefsson.org/mål/franzén.html
Comparación de cadenas o reglas de ordenación. Supongamos que desde
nuestro sitio ofrecemos la opción de mostrar, de acuerdo a las necesidades
del usuario, datos ordenados de acuerdo con diversos parámetros.
Bueno, no habría problemas si nos guiáramos solamente con nuestra lengua
y nuestro calendario. Pero si queremos tener en cuenta otras culturas, nos
encontraremos con algunas cositas más a tener en cuenta.
Fechas y calendarios. De acuerdo a lo que leímos anteriormente, no hay
UNA fecha ni UNA sola forma de mostrarla, asi que esa es una de las
opciones básicas a tener en cuenta. Si vamos a elegir una de las formas y
calendarios para mostrarlos ordenadamente, y siguiendo las pautas de
accesibilidad a la Web, deberemos informar de esto al usuario que hace la
consulta y, dentro de lo posible, darle la posibilidad de elegir otros
calendarios o formatos.
Caracteres distintos a los que usamos. De acuerdo a nuestra experiencia
cotidiana, ya sabemos que si nos piden ordenar determinados nombres en
orden alfabético, deberemos poner la A antes que las B (salvo que nos
pidan en orden inverso, claro.
Pero... ¿qué pasa si nuestros posibles clientes o usuarios hablan chino
mandarín, japonés o hindi, por citar tres lenguas MUY populares?
Bueno, deberemos tomarnos el trabajo de averiguar qué sistema usa cada
cultura.
El chino mandarín, por ejemplo, tiene dos formas distintas de ordenar
(obviamente que ninguna es “alfabética”, ya que no tiene un alfabeto, tal
como lo entendemos los occidentales): una por pronunciación y otra por el
número de trazos. La elección de uno u otro depende de la región del
usuario.
Aunque tampoco debemos irnos muy lejos en las distancias, para tener
problemas de ordenamiento.
Veamos los siguientes caracteres que aparecen en el teclado: ß, Æ, â, ë, ñ, ç
y muchos otros, dependiendo del origen del teclado o el mercado al que va
dirigido.
Algunos sabemos, o imaginamos, dónde deberemos colocarlos a la hora de
ordenar.
Pero... ¿estamos seguros de dónde irán ß o Æ?
Tomemos la ß. No es la letra griega beta (β) ni una B deformada. Se llama
ezeta, ese-zeta o ezsett. Es de uso muy común en los idiomas alemán y
danés. Es una letra minúscula y no hay versión en mayúscula. Se usa la
misma letra, con la misma forma, tanto en un texto en mayúscula como en
minúscula. Esto es algo que deberemos tener en cuenta si una decisión de
seguridad, por ejemplo, se basa en el resultado de una comparación de
cadenas o una operación de cambio de mayúsculas y minúsculas.
Además, en alemán la ß y la ss son consideradas equivalentes, por lo que un
orden alfabético aceptado en alemán es el siguiente:
kasse
kaßt
kosse
Ahora veamos el carácter Æ. Este carácter se usa en los idiomas inglés,

alemán, sueco y danés. Pero mientras que en el alemán se lo ubica luego de
la A, en el danés y sueco, se lo ubica luego de la Z. Y otra diferencia surge
en la forma en que se lo trata. En danés, se lo trata como carácter
individual, pero en inglés como símbolo especial, asi que las palabras
“Apple” y “Æble”, en danés irán en ese mismo orden, mientras que en
inglés será al revés, ya que a los símbolos especiales se los ordena antes de
la A en el alfabeto.
El uso de las diéresis también tienen sus características. En el sueco, crean
caracteres que son vistos como letras independientes del alfabeto, que
aparecen luego de la Z, por lo que un orden alfabético sueco sería:
cabe
cube
cäbe
Además, el orden de acentos y diéresis cambia en el francés, en

comparación con otras lenguas. Veamos el orden “común” y el orden del
francés:
General Francés
cabe cabe
cábé cäbe
cábë cábé
cäbe cábë
En checo, la secuencia “ch” es usada como una unidad simple y única para
ordenar, por lo que las palabras comenzadas con “ch” van luego de la “h” y
no luego de la “c”. Un orden alfabético normal en checo sería:
cabe
dabe
chabe
Ruby
Además de un lenguaje de programación muy conocido, Ruby es un tipo
particular de anotación que provee de transcripción fonética de caracteres
que el lector puede no comprender. Este tipo de anotaciones se realiza a
través de un etiquetado específico, que se agrega al etiquetado estándar
HTML, XHTML o XML. Es ampliamente usado en materiales de
educación escritos en lenguas del este asiático. También es usado en textos
para estudiantes occidentales que desean aprender lenguas orientales por su
pronunciación 15.
Por ejemplo, veamos la línea de una fecha con Ruby indicando la
pronunciación (en chino mandarín):
èr líng líng wû nián shíyî yuè bã rì
2011 年 11 月 8日
¿Eso es todo?
No, es sólo el comienzo. El tema de la internacionalización web excede los
alcances de un capítulo y merecería un libro entero, al menos. Falta todavía
recordar, por ejemplo, que las diferencias culturales pueden a veces resultar
más sutiles.
Colores. El uso de los colores puede resultar distinto. Por ejemplo el luto,
en la cultura japonesa, es representado por el blanco, y no el negro. De la
misma forma que no es lo común que una novia se vista de negro en
Occidente, cosa que no es raro en Oriente 16.
Símbolos. No siempre los símbolos tienen el mismo significado en todo el
mundo. Un buen ejemplo es nuestra conocida marca de tilde (√). En
algunos países significa incorrecto, no correcto. Otra diferencia a tener en
cuenta es que en Japón, los círculos (O) reemplazan estas marcas de tilde,
tal como se ve en la siguiente imagen 17:
Gestos. También el lenguaje corporal o los gestos pueden dar lugar a
problemas. Cada uno de los siguientes gestos pueden resultar ofensivos en
alguna parte del mundo.
Direcciones postales. Para un ruso o un japonés, las direcciones en las
cartas se escriben de lo general a lo específico, lo opuesto a nosotros. Asi
que ellos pondrán primero el país, luego la provincia, el código postal, la
localidad, la calle y número y, por último, el nombre del destinatario.
Recordemos esto cuando ofrezcamos, a través de una base de datos,
formularios de ingreso de datos, etiquetas postales u otra forma relacionada.
Otro tema es el uso del nombre y el apellido. Los chinos, y otros pueblos,
cuando escriben su nombre, ponen primero su apellido y luego su nombre.
Por ejemplo Mao Zedong, tenía por apellido Mao, no Zedong.
Localismos. Si en nuestros textos, información o publicidades vamos a
hacer referencia a chistes que se ven en la televisión o se oyen en la radio
de nuestra ciudad, es muy probable que el otro se “quede afuera” y no
entienda (o peor: entienda mal y se ofenda) el sentido de lo que queremos
transmitir.
En resumen. Ya citamos la frase “tener en cuenta al otro” para pensar en la
internacionalización web. Esto lo podemos tomar de dos formas. Por un
lado, como “otro problema” en el que tendremos que adentrarnos para
intentar solucionar las necesidades de los usuarios en aumento de nuestro
sitio web.
Pero por otro lado, es una oportunidad de ver el problema como el
comienzo de nuevas y apasionantes experiencias, en donde, a medida que
nos comencemos a interiorizar por la cultura “del otro”, también
comenzaremos un viaje interior, a nuestra propia cultura, y si tenemos la
suficiente paciencia, quizás descubramos, como a mí me ha pasado, que en
el fondo no hay un “ellos” y “nosotros”, sino que vivimos en una sociedad
mundial compleja y variadísima... pero única, fascinante y siempre
dispuesta a enseñarnos algo nuevo y alternativo con qué enriquecer nuestra
pequeña existencia.
Referencias
1. http://www.w3.org/WAI/
2. Además, hay una sección específica de este consorcio especializada en la
internacionalización, que se puede [Visitar sitio en línea].
3. http://www.w3.org/TR/WCAG20/ (hay una versión en español en
[Ingresar en la versión en español] ).
4. Configuración del parámetro charset de HTTP [Ver en línea]
5. La imagen es aportada por Richard Ishida en la siguiente dirección: [Ver
imagen en línea] , y forma parte del artículo que está en la página: [Ver sitio
completo] .
6. Esto se puede ver hasta en gráficos, tablas, hojas de cálculo, etc., como la
imagen que aparece adelanta, cuya fuente es: [Ver la fuente en línea], de
Richard Ishida.
7. Un detalle que puede resultarnos curioso y que puede llegar a influir a la
hora de diseñar una página, es que si justificamos un texto, no se mostrará
de la misma forma en todas las formas de escritura. Mientras que en las
lenguas occidentales, el justificado se realiza agregando espacio a los
espacios entre palabras, en lenguas como el árabe, lo que se “estira” es la
palabra, tal como podemos ver en las siguientes imágenes: Texto árabe sin
justificar . El mismo texto en árabe justificado .
8. El origen de las imágenes es: [Ver en línea la imágen] de la nota a pie de
página 8 , que forma parte de la página: [Ingresar al sitio Web] , de Richard
Ishida.
9. La imagen, provista por Richard Ishida, está en: [Ver en línea la imágen]
de la nota a pie de página 9 y forma parte de la página: [Ingresar al sitio
Web] de la nota a pie de página 9
10. La imagen de la derecha proviene de una provista por Richard Ishida
que se encuentra en: [Ver en línea la imágen] de la nota a pie de página 10 .
11. La otra imagen fuente de la de la derecha se encuentra en [Ver imagen
en línea] .
12. La fechas pueden también aparecer con el formato europeo, pero no es
lo más común (Mazel Sussman, Julie, “I can read that! A traveler’s
Introduction th Chinese Characters”, China Books & Periodicals, Inc.,
1994, San Francisco, Estados Unidos, página 31).
13. Un detalle de los mismos se puede leer en la página: [Ver texto
completo en línea]
14. En la página http://goo.gl/TLyGcK encontraremos la forma de
configurar esta cabecera en Java/JSP, ASP y Perl.
15. La especificación oficial de Ruby en el sitio del Consorcio W3 está en
la siguiente página: http://www.w3.org/TR/ruby/ .
16. Ishida, Richard, “Color”, en presentación “Introduction to Writing
Systems”, diapositiva 39, 10 de junio de 2003 http://goo.gl/33mTL2 .
17. Ishida, Richard, “Color”, en presentación “Introduction to Writing
Systems”, diapositiva 75, 10 de junio de 2003 http://goo.gl/3RdflV.
Bibliografía
Mazel Sussman, Julie, I can read that! A traveler’s Introduction th
Chinese Characters, China Books & Periodicals, Inc., 1994, San
Francisco, Estados Unidos.
Ouane, Adama (editor), Towards a Multilingual Culture of Education,
UNESCO, 2003.
Paolillo, John, Pimienta, Daniel, Prado, Daniel, Mikami, Yoshiki y
Fantognon, Xavier, Measuring Linguistic Diversity on the Internet,
UNESCO, Francia, 2005.
Xi, Xiandai, Han, Han, Cidian, Xi, Diccionario moderno español -
chino, chino - español. 1992.
Crystal, David, The Scope of Internet linguistics, 2005.
Holzschlag, Molly E., Internationalization: awakening the sleeping
giant, 2006.
Ishida, Richard, Practical & Cultural Issues in Web Design, 2003.
Ishida, Richard, Internationalizing the Web, 2005.
Valero, Pedro, Internacionalización, Universitat de València.
Capítulo 17: Prácticas participativas en el Diseño de Interacción: El
caso del Design Museum, por Mariana Salgado
Diseñadora e investigadora. Doctorada en Diseño de Interacción de la
Universidad de Arte y Diseño de Helsinki. Dirigió la Maestría en
administración de negocios, con especialización en diseño centrado en el
usuario, en la Universidad de Ciencias Aplicadas, Laurea. Trabaja
actualmente en el Media Lab, Facultad de Arte, Diseño y Arquitectura de la
Universidad de Aalto. Le interesan las prácticas relacionadas a la
participación porque cree que son claves en la formación de espacios
democráticos y abiertos.
Más información:
Ingresar al sitio web de la autora
Prácticas participativas en el Diseño de

Interacción: El caso del Design Museum 1
Comentar la exposición
Estuve explorando el tema de comentar la exposición en previos proyectos
en Ateneum Museum 2 y en Kunsthalle 3. En estos casos diferentes grupos
comentaron la exposición. En el caso de “Trazos sonoros” fue un grupo de
discapacitados visuales y en el caso de “Mapa en diálogo” fueron todos los
visitantes a la Bienal de Arte Joven, Pequeño paraíso. La idea principal es
exponer los comentarios de otros visitantes para permitir acercarse a las
obras expuestas desde diferentes perspectivas. Normalmente, cuando se
visita un museo es solo el material interpretativo que provee el curador el
que se expone en la sala. Este material tiene un carácter formal y objetivo.
Entonces la experiencia de la visita cambia dependiendo de quién nos
acompaña. La visita al museo sigue siendo solo para una elite que puede
entender y disfrutar el registro del material interpretativo del curador.
Salgado trabajó sobre la hipótesis que si en el museo provee comentarios de
carácter subjetivo que muestran a los visitantes que está permitido disfrutar
las obras expuestas de muchas maneras, entonces aparece un museo abierto.
Un museo abierto es un museo accesible e inclusivo de las diferentes voces
de nuestra sociedad. Es un museo que invita a participar y interactuar con
su contenido no solo desde lo intelectual sino también desde lo afectivo y lo
creativo.
La vida secreta de los objetos

El eje de este proyecto fue el contenido generado por los visitantes:
comentarios que se expondrían en la galería del museo para complementar
los textos del curador y para enriquecer la experiencia de la visita al museo
por medio de la inclusión. Se redefinió la noción de comentario para incluir
relatos, opiniones, recuerdos o sentimientos, no sólo en forma de texto
escrito, sino también de sonidos o imágenes. Para comunicar las nuevas
posibilidades asociadas a los comentarios, creamos talleres en los que los
visitantes escribían poemas, componían canciones, hacían dibujos y
sacaban fotos en relación con los objetos de la exposición permanente, y
exhibían esos ejemplos de comentarios a través de un mapa interactivo
ubicado en un stand que vinculaba el objeto con los comentarios e invitaba
a realizar nuevos aportes. Los talleres y eventos proporcionaron el material
inicial (relatos, ideas, recuerdos y nuevos objetos) para incluir en el mapa y
para impulsar el agregado de comentarios de los visitantes ocasionales.
Al mapa interactivo se podía acceder en línea y en la sala de la exposición a
través de un stand montado especialmente. Así, los visitantes podían
sumarse, desde la galería misma o desde una estación remota, en sus
hogares, a conversaciones iniciadas por quienes participaron de los talleres
o eventos. Además del mapa interactivo, creamos un weblog para describir
y comunicar la evolución del proyecto. 4
El primer taller, Esa and the Objects, fue diseñado para niños de cinco años
y se realizó en un jardín de infantes y en el museo. Consistía en cinco
sesiones dedicadas cada una a un objeto y estaba coordinado por tres
facilitadores del museo. En el taller se les proponía a los niños que hablaran
de las propiedades y el uso de los objetos de diseño y de la familiaridad que
tenían con ellos, y se les proporcionaban datos sobre el contexto histórico
de cada uno. Los niños crearon dibujos, móviles y otras interpretaciones
basados en los objetos.
El segundo taller, Sound of Objects, fue diseñado para un grupo de
adolescentes de once y doce años que estudiaban guitarra. Los alumnos
fueron al museo e hicieron una visita guiada en la que les hablaron sobre
seis objetos de diseño; luego improvisaron melodías a partir de ellos. Estas
melodías fueron grabadas y se podían escuchar desde el mapa.
El tercer taller, Odes for Objects, fue diseñado para dos grupos de
adolescentes que asistían a un taller literario. Después de hacer una visita
guiada centrada en seis objetos de diseño de la exposición, los adolescentes
escribieron un cuento basado en uno de ellos. Como cierre, cada uno
escribió una oda inspirada en otro de los objetos. Estas odas se podían leer
en línea desde el mapa y en el museo también estaban en las paredes
colgadas cerca de los objetos expuestos.
Los participantes del taller Ode to Objects escribieron los siguientes
poemas:
Oda a una luz (Ode to Objects)
La luz en bloque / brilla; / Calidez / Frescura / Alegría / el pasado / su forma
/ Misteriosa / nos llama / lo revela todo / Iina
Oodi valaisimelle (Oodi Esineille)
Palikkavalaisin / se loistaa; / lämpöä / kylmyyttä / Alegría iloa / mennyttä /
sen muoto – / on salaperäinen / luokseen kutsuva / kaikenpaljastava / Iina
Anti oda a una lámpara (Ode to Objects)
Un hombre inventa una lámpara / que no es una lámpara / La esconde / en
el hielo. / No entiendo / ya tengo frío / quiero una luz cálida, amarilla y
elegante. / Una mujer inventa una nueva lámpara / la coloca dentro / Todas
las mañanas / le sonríe / por entre las cortinas. / Nana
Anti Oodi Lampulle (Oodi Esineille)
Mies keksi lampun / joka ei ole lamppu / Hän piillottaa lampun – piilottaa /
jään sisään. / Minä en ymmärrä / minulla on muutenkin kylmä / haluan
lämmintä valoa keltaista / ja sulavaa / Nainen keksi uuden lampun / hän
laittaa sen auringon / sisään. / Joka aamu se hymyilee / hänelle / Nana 5
Etapas del Proyecto
El proyecto se desarrolló en dos etapas. En la primera (de octubre de 2007 a
febrero de 2008), se implementó el mapa interactivo como parte de un stand
de la exposición permanente del Design Museum, que desde hace seis años
ocupa el subsuelo del museo. En la primera etapa, en el mapa sólo se
incluía una pequeña selección de los objetos de la exposición. Hicimos un
seguimiento del modo en que fueron surgiendo las conversaciones en
distintas ocasiones (un fin de semana en familia, un evento y la
inauguración de una exposición) desde noviembre de 2007 hasta febrero de
2008. Cuando el stand estaba abierto había una persona que invitaba a los
visitantes a probarlo y los ayudaba a usar el mapa interactivo.
En la segunda etapa (iniciada en marzo de 2008 y todavía en curso en mayo
del mismo año), surgió la posibilidad de armar una versión temporaria de la
exposición permanente del museo, la cual llevó el nombre de nuestro
proyecto: ‘‘La vida secreta de los objetos, mapa interactivo del diseño
finlandés’’ (The Secret Life of Objects, an Interactive Map of Finnish
Design). Para esa etapa creamos un nuevo mapa (en tres idiomas: finés,
sueco e inglés) y un nuevo stand, mejoramos el software, creamos nuevos
textos para el mapa y conseguimos una conexión a Internet más rápida. Esta
vez, la mayoría de los objetos de la exposición (40 de los 50 objetos)
estaban también en el mapa para que los visitantes opinaran acerca de ellos.
Durante la exposición, que comenzó el 18 de marzo y terminó el 1 de junio,
el stand con el mapa interactivo estuvo en la galería sin ningún facilitador.
En esa etapa, mientras los visitantes ocasionales agregaban comentarios al
mapa, nosotros seleccionábamos algunos, los imprimíamos y los
colocábamos en el espacio de la exposición. Los comentarios de los
visitantes ocasionales aportaron una visión pluralista basada en los objetos.
El stand también tuvo dos versiones, una en la primera etapa del proyecto y
otra en la segunda, durante la nueva exposición. En la segunda había una
mesa, dos sillas, una computadora, un reproductor de DVD, folletos, un
cartel de ayuda (con la explicación básica de cómo usar el mapa), un
mouse, un monitor de computadora y dos pantallas grandes.
Todos los componentes del proyecto −el weblog, el mapa interactivo, el
stand, la exposición, los talleres y los métodos que se utilizaron para
documentarlos− proporcionaron una combinación de recursos que posibilitó
la creación de una plataforma participativa que motivó a los visitantes a
hacer comentarios.
El contenido creado por los visitantes en un
mapa interactivo
Los museos están incorporando a sus sitios web y a sus galerías
herramientas que motivan a los visitantes a crear material basado o
inspirado en las colecciones. Actualmente existe una gran cantidad de
proyectos en los que se exhibe el contenido generado por los visitantes en el
espacio de la exposición y en los sitios web de los museos, y en el marco de
los cuales se exploran las posibilidades que ofrecen los weblogs, podcasts u
otros recursos web 2.0. 6, 7, 8
En ‘‘La vida secreta de los objetos’’, el contenido generado por los
visitantes se reunió y exhibió usando los recursos disponibles. Por ejemplo,
se usó YouTube para mostrar en línea videos grabados durante los talleres,
como parte de un concepto más amplio: la creación de una WebTV del
museo. El software de código abierto ImaNote 9 nos permitió crear notas y
navegar por el mapa que contenía la disposición de la muestra. Entre las
funciones de ImaNote se incluye la capacidad de agregar comentarios y de
asociarlos a una imagen (en este caso, el mapa de la exposición). Los
comentarios muestran, entre otras cosas, mensajes de texto, enlaces a
recursos multimedia en la web (como la música compuesta por estudiantes
de guitarra en el taller) e imágenes. El software –desarrollado como
proyecto de investigación– nos permitió llevar a cabo la prueba y explorar
los desafíos que el contexto del museo planteaba.
En este caso particular, se usó un mapa como interfaz entre los objetos de la
exposición y los comentarios del público. Los visitantes podían hallar
fácilmente los objetos y el material basado en ellos. Salgado y Díaz-
Kommonen pusieron a prueba este concepto con anterioridad en un museo
de arte de Helsinki. 10 Por medio del mapa, reunimos y exhibimos
paralelamente los comentarios de los visitantes y los de los curadores.
La experiencia de los visitantes

Aunque el concepto de museo como foro de debate 11 es conocido, la
práctica concreta de comentar activamente sobre una exposición es nueva
para los visitantes. Por lo tanto, hace falta tiempo para instalarla como
práctica generalizada en la visita a un museo. El público no está
acostumbrado a tener esa posibilidad. En nuestro caso, durante los casi tres
meses en que el mapa interactivo estuvo en la exposición, obtuvimos
alrededor de cien comentarios.
Hay muchos tipos diferentes de comentarios. Los visitantes criticaron o
elogiaron los objetos o a los diseñadores, enviaron un mensaje personal al
diseñador, contaron recuerdos o relatos que los vinculaban con los objetos
(como qué uso le daban a un objeto), hicieron preguntas, agregaron material
relacionado con el objeto y les dieron sonido a los objetos. Por ejemplo,
Otto, de 6 años, agregó el siguiente comentario a una obra llamada Spider
(araña): “fgyhfgcbvgfhdg ffetrrdfvggbvvcg ffddsdsfsssssdvc
cdbdcvdfgghhghghfhghh”. Hay ejemplos de comentarios que plantean
preguntas filosóficas, como ‘‘Las arañas me dan escalofríos pero también
me fascinan… es rarísimo; les tengo miedo, pero al mismo tiempo quiero
mirarlas bien de cerca… ¡¿Será que el miedo y la admiración van de la
mano?!’’ o ‘‘Una vez tuve un sueño donde vi la misma araña y me
sorprendió que alguien haya soñado lo mismo antes que yo y decidiera
hacerlo realidad. ¿Ya está todo inventado, entonces?’’.
Después de observar y entrevistar al público durante la exposición, los
investigadores del equipo advertimos que la mayoría de los visitantes no
necesariamente tratan de usar el mapa interactivo a menos que se los anime
a hacerlo. Así y todo, la mayoría de los que lo usaron se llevaron una
impresión positiva. Los visitantes que entrevistamos leyeron los
comentarios impresos en la exposición y disfrutaron de que se integrara una
visión personal y multifacética a la exposición. El hecho de mostrar las
reacciones de los visitantes frente a las piezas del museo nos permitió
explorar el proceso de validación de los aportes y de estímulo de la
participación.
El valor de los comentarios

La idea de mantener en el mapa la voz del museo en paralelo a la voz de los
visitantes me llamó a considerar qué otras voces no estábamos teniendo en
cuenta. Por eso casi al final del proyecto también entrevisté a algunos de los
diseñadores que tenían sus objectos en esta exposiciones. Estas entrevistas
que fueron documentadas en video no se incluyeron en el mapa. Sin
embargo, me ayudaron a considerar que es importante incluir todos en la
comunidad del museo, no solo a visitantes y el personal educativo, sino
también a investigadores, diseñadores o artistas, personal de limpieza,
curadores, educadores, y todos los que tengan historias que se relacionen
con los objectos expuestos.
Cabe destacar que no fui yo quien registró los comentarios, sino que los
ingresaron las personas que participaron en las exposiciones. Silverman 12
sugiere que la forma en que registramos los datos es “importante porque
está conectada directamente con la calidad del análisis” (p. 142). Estos
comentarios hechos por la comunidad del museo pueden:
Facilitar el acceso del público nuevo al contenido.
Extender en el tiempo el compromiso de la gente con el material de la
exposición.
Contribuir al aprendizaje que tiene lugar en la exposición, invitando a las
personas a relacionarse activamente con ella.
Validar múltiples perspectivas y promover debates a partir del material de la
muestra.
Generar posibilidades de diálogo e intercambio dentro de la comunidad del
museo.
Ayudar a identificar y a integrar nuevos miembros de la comunidad y a
entender sus expectativas en relación con los museos y las salas de
exposición.
Aportar documentación complementaria y material interpretativo
relacionado con los objetos de la exposición.
Conclusión
La alianza entre los diseñadores e investigadores (del Laboratorio de
medios) y el equipo educativo del museo le dio un carácter original e
instructivo al proyecto. El mapa interactivo y los talleres tuvieron un
objetivo común: reunir material audiovisual que contara historias sobre los
objetos. Los eventos, los talleres, la documentación multimedia y el mapa
interactivo exhibido en el museo fueron co-diseñados como un todo
coherente en un grupo multidisciplinario.
El co-diseño sucede cuando los diseñadores aprenden de sus colaboradores
y viceversa. En este caso el personal del museo se apropió del mapa, lo re-
interpretó, y creó nuevas ideas y material interpretativo más accesible para
la colección. En una charla con una educadora que participó en proyecto
ella se refirió a este proyecto como una experiencia educativa para el
personal del museo porque los hizo pensar el material interpretativo de una
manera más accesible. Esta vez usaron un encuadre y un vocabulario que
pudiera ser entendido por un público menos especializado. Por otro lado,
los diseñadores en el proyecto aprendimos sobre las prácticas del museo y
sus valores. Fuimos testigos como el mapa se enriquecía a partir de las
ideas propuestas por el personal del museo y los visitantes.
Durante el tiempo de la exposición entrevisté a personal del museo,
visitantes y diseñadores. En base a estas entrevistas y a observaciones en la
exposición fui proponiendo cambios e implementándolos. Esta actitud
activa durante el momento de uso es fundamental para el diseñador de
interacción. Botero, Kommonen y Marttila 13 proponen la expansión del
espacio de diseño teniendo en cuenta este momento. Según ellos la
adopción de nuevas estrategias, nuevos espacios colaborativos de diseño
pueden ser explorados en el momento de uso. En muchos casos de diseño
de interacción en el museo, el equipo de diseñadores no trabaja durante el
proceso de incorporación de la pieza al espacio del museo, sino que su rol
termina cuando la pieza interactiva está instalada. Eso imposibilita entender
el contexto y encontrar ideas innovadoras para diseños futuros.
Creemos que fue una buena estrategia usar el material proveniente de los
talleres como disparador de comentarios entre los visitantes ocasionales. La
riqueza y creatividad de los comentarios reunidos se debe en parte a los
disparadores que los activaron. Dado que los comentarios incluían el punto
de vista de los visitantes, ¿podemos decir que se está construyendo un
nuevo museo participativo?. Un museo participativo necesita incluir a los
visitantes en el proceso de diseño, desde los primeros bocetos, para que este
grupo de co-diseñadores se amplie y no sea solo una colaboración entre el
museo y la universidad.
La participación del público sólo se puede medir en función de los
comentarios que dejan los visitantes. Sin embargo, podría incluir también
otros aspectos relacionados con el interés del público en la exposición,
como la lectura de comentarios de visitantes anteriores. Los entrevistados
valoran la presencia de los otros visitantes y disfrutan de leer comentarios.
Según parece, el público contribuye en mayor medida cuando ve que los
comentarios de otros han sido respetados y exhibidos como parte del
mensaje de la exposición. Esto es muy diferente a lo que sucede en un libro
de visitas donde los comentarios no están expuestos o en las carteleras
donde los visitantes pueden escribir pero sobre pequeños papelitos de
colores. En este caso los comentarios dejados en el mapa se leían como
parte de la exposición.
La participación es un factor de legitimación cuando se relaciona con
objetos de la vida diaria como en un museo de diseño y es una manera de
que los visitantes y el personal de los museos inicien un diálogo fluido que
pueda extenderse más allá de la visita. En muchos museos hay actividades,
como talleres, donde esa conversación se inicia. Sin embargo, el diálogo
termina junto con el taller. En el caso del proyecto ‘‘La vida secreta de los
objetos’’ realizado en el Design Museum Helsinki, nuestro objetivo fue que
el diálogo continúe después de la visita.
En este estudio de caso desarrollé estrategias para guiar la producción de
contenido consistían en invitar especialmente a diferentes miembros de la
comunidad y promover prácticas existentes, como establecer relaciones
entre la vida de las personas y la colección del museo. Los talleres llevados
a cabo dieron origen a contenidos creativos y personales que influyen en los
aportes futuros. Esos talleres fueron una manera de mostrarles a los
visitantes que sus aportes eran importantes pero, al mismo tiempo, le
demostraron al museo que con otros tipos de invitaciones se pueden incluir
en la muestra materiales novedosos y estimulantes, en este caso, poemas y
música.
Las prácticas participativas ofrecen enormes posibilidades de ampliar el rol
social del museo y también pueden darle un nuevo significado político a
una institución cultural tradicional.14 En el futuro, el mapa interactivo de
objetos de diseño del Design Museum podría servir de plataforma para una
variedad de temas, desde la ética del diseñador y el consumidor hasta
proyectos regionales de diseño colaborativo. Los objetivos y el estatus de la
interacción con el público dentro de la organización del museo adquieren un
carácter central (y este es un debate en curso en el ámbito de los museos).
¿Qué estatus tendrán los documentos producidos por los visitantes? ¿Cómo
se preservan y qué valor tienen en la organización del museo?
En el proceso de investigación basada en el diseño, la estrecha colaboración
con el departamento de educación del Design Museum fue natural dado el
rol tradicional de ese departamento como enlace entre el museo y el
público. ¿Cómo pueden integrarse los métodos y herramientas que
posibilitan prácticas participativas en todas las prácticas del museo, desde la
planificación de una exposición hasta las estrategias de marketing? Las
prácticas participativas podrían ser una herramienta que motive a los
visitantes a interesarse por la exposición y un recurso en el proceso de
diseño.
Referencias
1. Este artículo está basado en la traducción hecha por María Valeria Bech
en la residencia Odriozola-Grosman del Instituto de Enseñanza Superior en
Lenguas Vivas “Juan R. Fernandez”. L. Su versión original se llamaba
Codiseño de prácticas participativas en torno a una exposición del Design
Museum. Los autores de la versión anterior de este artículo son Leena
Svinhufvud, Andrea Botero, Mirjam Krafft, Hanna Kapanen, Diana
DeSousa, Elina Eerola, Anna Louhelainen y Susanna Vakkari.
2. Salgado, M. y A. Kellokoski, “Äänijälki: Opening Dialogues for Visually
Impaired Inclusion in Museums”, Proceedings of the International
Workshop “Re-Thinking Technology in Museums: towards a new
understanding of the people’s experience in museums”, L. Ciolfi, M.
Cooke, T. Hall, L. J. Bannon & S. Oliva, eds., Interaction Design Center,
University of Limerick, Irlanda, 2005: 10-17.
3. Salgado, M. y L. Díaz-Kommonen, “Visitors’ Voices”, en J. Trant y D.
Bearman (eds.) Actas del Congreso Museums and the Web 2006, en
Archives & Museum Informatics:[Ver en línea], Toronto, 1 de marzo de
2006. [Fecha de consulta: 15-5-08]
4. Weblog de ‘‘La vida secreta de los objetos’’ (en inglés): [Ver en línea la
vida secreta de los objetos]. [Fecha de consulta: 30.05.08]
5. Las traducciones están hechas por mí del finés al castellano.
6. Samis, P. y Pau S., “‘Artcasting’ at SFMOMA: First-Year Lessons,
Future Challenges for Museum Podcasters broad audience of use”, en J.
Trant y D. Bearman (eds.) Actas del Congreso Museums and the Web 2006,
en Archives & Museum Informatics: [Ver actas en línea], Toronto, 1 de
marzo de 2006. [Fecha de consulta: 9-5-08]
7. Von Appen, K., Kennedy, B. y Spadaccini, J., “Community Sites &
Emerging Sociable Technologies”, en J. Trant y D. Bearman, eds. Actas del
Congreso Museums and the Web 2006[Fecha de consulta: 15-5-08]
8. Salgado, M., ‘‘Breaking Apart Participation in Museums’’, en J. Trant y
D. Bearman (eds.) Actas del Congreso Museums and the Web 2008, en
Archives & Museum Informatics , Toronto, 31 de marzo de 2008. [Fecha de
consulta: 9-5-08]
9. Página web con publicaciones relacionadas con ImaNote (en inglés):
http://imanote.uiah.fi/ [Fecha de consulta: 30-5-08]
10. Salgado, M. y L. Díaz-Kommonen, op. cit.
11. Duncan, F. C. “The Museum, A Temple or the Forum”, Reinventing the
Museum. Historical and Contemporary Perspectives on the Paradigm Shift.
Gail Anderson Altamira Press, ed., EEUU., 2004: 61-73.
12. Silverman, D., “Doing qualitative research. A practical handbook”.
London: Sage Publications. 2001.
13. Botero, A., Kommonen, K.-H., & Marttila, S., “Expanding Design
Space: Design-In-Use Activities and Strategies”. Proceedings of the DRS
2010 Conference. Presented at the Design & Complexity, Montreal,
Canada: DRS. 2010. [Descargar .doc], [Descargar PDF] [Fecha de consulta:
15-2-13]
14. Sandell, R., Museums, Prejudice and the Reframing of Difference.
Routledge, Nueva York, 2007.
Agradecimientos
En primer lugar, queremos agradecer a todos los participantes de los talleres
y a los docentes Rody Van Gemert, Outi-Maria Takkinen, Nana Smulovitz-
Mulyana y Onnela Päiväkoti. Un agradecimiento especial a Matti Luhtala,
Lily Díaz, Merja Vilhunen, Marianne Aav, Harri Kivilinna, Tommi
Jauhiainen, Mikko Laitinen, Ilpo Kari, Atte Timonen y Vennu Nivalainen.
Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo
modalidad open-source, por Nahuel González
Ingeniero en Electrónica de la Universidad Tecnológica Nacional. Cuenta
con más de 15 años de experiencia en el área de tecnología. En el año 2006
crea MANA Desarrollos, una empresa dedicada a la innovación en el área
de discapacidad. Diseña dispositivos y software accesible para que todas las
mejoras puedan acceder a la información, a la educación y al trabajo. Ha
brindado charlas sobre diseño inclusivo en Argentina, Brasil y Turquía.
Actualmente se desempeña como Director de MANA Desarrollos, a su vez
es docente en el departamento de Electrónica de la Universidad Tecnológica
Nacional – Facultad Regional Buenos Aires.>
Más información:
Ingresar al LinkedIn del autor
Diseño y desarrollo de un editor de texto

accesible bajo modalidad open-source
Introducción
El diseño de una solución debe involucrar dos conceptos: usabilidad y
accesibilidad. A través de su comprensión y correcta implementación
podremos lograr que nuestra aplicación sea simple y útil, satisfaciendo así
las expectativas del usuario y permitiendo su uso independientemente de las
limitaciones funcionales de la persona.
Cuando nos referimos a usabilidad, hablamos de la forma y condiciones de
uso por parte de los usuarios, es decir, es una medida de la calidad de la
solución [Nielsen, 2012]; este concepto debe ser entendido en relación a
usuarios específicos en contextos específicos.
Al tratar el concepto de accesibilidad, se trata de eliminar barreras y que
nuestro diseño sea pensado para la diversidad y heterogeneidad de
necesidades.
El desarrollo de soluciones open-source permite que ellas puedan ser
modificadas, actualizadas y mejoradas por un grupo de personas que no
fueron inicialmente los creadores. Este concepto debe utilizarse en los
sistemas que tengan como objetivo la creación de herramientas que busquen
la inclusión social.
Muchas veces para que un diseño sea accesible se requiere de la
incorporación de ayudas técnicas, productos de apoyo o tecnología asistiva.
Se trata de elementos como un teclado o mouse alternativos (teclas más
grandes, con colores contrastantes, etc.), como así también diferentes
formas de realizar la acción de selección, es decir, el click izquierdo
(activación por tacto, soplido, pie, pera).
Este artículo plantea la necesidad de diseñar e implementar un editor de
texto accesible. A través del trabajo que realizo como profesional en el área
de tecnología y discapacidad, he notado las falencias que poseen la mayoría
de los programas, y los problemas a los que se enfrentan los usuarios para
poder interactuar con el software.
Marco teórico
El diseño centrado en el usuario (DCU) [Norman, 1986] es una filosofía de
diseño que persigue la satisfacción de las necesidades de los usuarios con el
mínimo esfuerzo de su parte.
El DCU nos invita a preguntarnos acerca de quiénes serán los usuarios,
cuáles son sus objetivos o metas, qué herramientas y qué información
necesitan para satisfacer sus objetivos.
Olga Carreras Montoto nos plantea en su trabajo “La usabilidad como
metodología para el desarrollo de una aplicación”, la existencia de cuatro
etapas: plan, análisis, diseño y evaluación, que permitirán llevar adelante
una metodología de trabajo para lograr los objetivos planteados.
Yusef Hassan Montero y Sergio Ortega Santamaría, en el “Informe APEI
sobre Usabilidad”, describen tres conceptos asociados al DCU: el modelo
conceptual (es el que realiza el diseñador del software), la interfaz (imagen
que se le presenta al usuario a través del sistema) y el modelo mental
(creado por el usuario a través de esa imagen).
Podemos ver al diseño centrado en el usuario como un sistema realimentado
que tomará información a través de la participación del usuario y su
observación (salida). Dicha información se inyectará en el equipo de trabajo
(entrada), el cual tomará decisiones acerca de las mejoras a efectuar. El
DCU es un proceso repetitivo que permitirá obtener una mayor satisfacción
por parte de los usuarios, a partir de contar con mayor cantidad de
opiniones que posibiliten un diseño más inclusivo.
El diseño centrado en el usuario aplicado al desarrollo de productos de
apoyo se encuentra apoyado en tres ejes: la necesidad del paciente, el
equipo de trabajo de profesionales de la salud (terapista ocupacional,
fonoaudióloga, estimuladora visual, maestra integradora, etc.) y el
diseñador tecnológico (ingenieros, diseñador industrial, desarrollador de
software, etc.).
Objetivos y metodología
A partir del relevamiento de necesidades de algunos pacientes se planteó la
necesidad de desarrollar un software de edición de textos que permitiese la
interacción del usuario independientemente de si posee o no limitaciones
funcionales.
Se investigó acerca de los programas existentes analizando sus ventajas y
desventajas [Sánchez Caballero, 2010]. Se encontró que la mayoría
atendían a una necesidad o a un conjunto acotado de necesidades.
A partir del trabajo conjunto de un equipo multidisciplinario se generó un
listado de necesidades a las que debía atender el software:
Mecanismos alternativos para la escritura (uso de teclado, uso de

mouse, uso de producto de apoyo).
Mecanismos para aumentar la velocidad de escritura.
Reproducción oral del texto escrito.
Facilidades para interactuar (generar un documento nuevo, abrirlo,
guardarlo, etc.).
Resultados
Desarrollo del sistema
Se desarrolló una aplicación de escritorio que cumple con las

funcionalidades de un editor de texto accesible (figura 2). Este fue
desarrollado utilizando C# como lenguaje de programación y mySQL como
motor de base de datos.
El modelo de programación orientada a objetos facilitó el desarrollo de
perfiles de forma que cada texto se adecue de acuerdo a las posibilidades de
cada persona.
A su vez, se desarrolló un sistema de predicción de palabras que permitió
reducir los tiempos de escritura a los usuarios.
El sistema creado permite ser utilizado mediante:
Un teclado convencional o adaptado

Un mouse convencional o adaptado
Un switch activado por diferentes medios (mano, pie, boca, pera,
soplido)
A su vez cuenta con predicción de palabras y utilización de frases

habituales. Puede complementarse con sintetizadores de voz (open-source)
de forma que pueda reproducirse en forma oral el texto escrito. A través de
menúes simples o íconos permite generar un nuevo documento, abrirlo,
editarlo, guardarlo, como así también ajustar el tamaño con el que se
visualiza el texto escrito.
La aplicación se ejecuta en pantalla completa. A través de la información
suministrada por el sistema operativo en relación a la resolución de la
pantalla, el contenido se ajusta de forma de lograr una mejor experiencia
por parte del usuario (responsive design). Los controles se ajustan y se
redistribuyen de forma que pueda mostrarse la información sin necesidades
de tener una versión para cada tipo de resolución.
Dentro de las opciones de configuración, al comenzar a trabajar, el usuario
o un asistente genera un perfil, es decir, el conjunto de opciones que
permitirán que la persona se encuentre cómoda al utilizar el sistema. Entre
estas opciones se pueden destacar:
Color de fondo de la aplicación

Color de los botones
Color de las letras
Color del texto
Color del fondo donde se presenta el texto
Tipo de teclado en pantalla a utilizar (qwerty o alfabético)
Velocidad de barrido (en el caso de utilizarlo)
Realimentación visual de la opción elegida
Si utiliza síntesis de voz o no y su correspondiente configuración
Realimentación sonora de la opción elegida
Carpeta donde almacenará sus documentos
Si posee documentos previamente creados y desea importarlos
Configuración de colores y tipografía
Como se ha mencionado, el sistema permite generar un perfil sobre las
opciones de preferencia del usuario, entre las cuales se encuentran los
colores, tipo de letras y tamaño de las letras y texto.
Configuración del tipo de teclado
El usuario puede optar por dos tipos de teclados estándar y de distribución

alfabética. A lo largo de diferentes pruebas, quienes poseían lecto-escritura
y no habían sufrido algún tipo de daño cognitivo prefirieron utilizar la
distribución convencional.
Tipo de teclado en pantalla a utilizar (qwerty o alfabético)
Velocidad de barrido (en el caso de utilizarlo)
Realimentación visual de la opción elegida
Si utiliza síntesis de voz o no y su correspondiente configuración
Realimentación sonora de la opción elegida
Carpeta donde almacenará sus documentos
Si posee documentos previamente creados y desea importarlos
Una vez establecidas las preferencias del usuario, podrán ser editadas en el
momento en que se requiera.
Abrir un documento
Al abrir un documento, el sistema nos permite obtener un listado ordenado
por fecha de modificación de los archivos que el usuario creó con este
editor o que haya importado (por haberlos creado previamente).
Guardar un documento
Al guardar un documento, si el usuario posee configurado el teclado en
pantalla en lugar del teclado convencional, se abre una ventana que permite
que se escriba el nombre del archivo por primera vez (“guardar como”).
Luego bastará con seleccionar la opción Guardar o el ícono
correspondiente.
Agregar nuevas palabras

Si al utilizar el sistema, la palabra no se encuentra dentro de la base, el
sistema nos brinda la opción de agregarla. Al hacerlo el sistema aumentará
el puntaje de esta palabra para que el usuario deba realizar menor cantidad
de acciones la próxima vez que la utilice para poder seleccionarla.
Configuración y utilización de frases

La configuración de frases permite alterar el orden de ellas, editarlas,
eliminarlas y solo dejar frases que se ajusten a las necesidades de cada
persona. Para poder acceder a las frases se utiliza el botón o ícono de frases.
Las frases se muestran en grupos de cinco y luego se cuenta con dos
botones para poder recorrer todo el listado.
Configuración y utilización del barrido

El barrido es un sistema que se utiliza cuando el usuario posee movimientos
disminuidos o acotados. En lugar de mover el mouse o utilizar un teclado
convencional, las opciones se “ofrecen” al usuario de forma que puede
“elegir” cual utilizar. Esta elección se realizará generalmente mediante un
switch, que puede ser activado de diferentes formas tal como se describió
previamente. Uno de los aspectos más importantes es que esta velocidad
con la cual se le ofrecen al usuario las diferentes posibilidades sea
configurable. Esta velocidad inicialmente se planteó en forma cuantitativa
con diferentes pasos; a través del uso del sistema por parte de los usuarios
se obtuvo una mejor apreciación al enmarcarlo dentro de dos límites (lento
y rápido). Esta cota permitió que la persona entendiese más fácilmente
dentro de los parámetros en los que se iba a mover. El valor que se indicaba
previamente (número) no era representativo para los usuarios.
Acceso a símbolos y números

Para un mejor aprovechamiento del espacio disponible en la interfaz, se
diseñó un acceso directo a los símbolos y números de forma que
reemplacen en forma momentánea a las letras solo en el momento en el que
el usuario necesita acceder a estos.
Utilización del sistema con barrido

Dentro de las posibilidades que posee el sistema se encuentra su uso a
través de la técnica de barrido. A medida que el cursor se desplaza se van
encendiendo en forma secuencial las letras que se encuentran en la primera
fila, luego en la segunda fila y así sucesivamente. A medida que se
seleccionan las letras, comienza a trabajar la predicción de palabras de
forma que en el sector superior se van mostrando las palabras disponibles.
Al seleccionar una de estas palabras se autocompletan las letras restantes
dentro del texto.
Casos de uso
El sistema diseñado ha sido utilizado y evaluado por 21 personas con
discapacidad. A través de la información suministrada por cada uno y por
su entorno (familia, terapistas ocupacionales, asistentes, etc.) se realizó un
listado de mejoras a realizar.
Hoy el sistema se encuentra en su versión 2.0 y entre los usuarios podemos
destacar a un estudiante de la Universidad Nacional de Santiago del Estero
de la carrera de Ciencias Económicas, que requería de un software que
permitiese realizar preguntas a los docentes en forma oral ya que él no
podía expresarse de esa manera.
Otro caso fue el de un adulto joven con esclerosis lateral amiotrófica (ELA)
que a través de un switch activado con la pera utilizó el sistema para poder
comunicarse con su familia y escribir su biografía.
Un tercer caso es el de una joven estudiante de psicopedagogía de la
Provincia de Buenos Aires que lo utilizó para poder tomar apuntes
velozmente y organizarse para cada materia en particular con una estructura
sencilla. La predicción de palabras y frases fue vital para su desempeño.
Un último caso es el de un adulto mayor con ELA que utilizaba el sistema
para comunicarse con su psicóloga y con sus nietos. A través de un switch
capacitivo activaba el sistema de barrido y hacía uso del software.
Discusión
En base a los resultados obtenidos a lo largo del desarrollo y en su
implementación, se ha evaluado la migración del presente sistema para que
pueda ser utilizado en Linux y en teléfonos inteligentes.
Hoy por hoy, se estná evaluando las herramientas para poder realizar dicha
migración; entre ellas podemos destacar el proyecto mono que permite
ejecutar CLI en Linux.
En futuras versiones, se espera poder incorporar dentro de las opciones de
configuración del usuario el tipo de botones que desea utilizar por ejemplo,
basado en texto, en imagen (ícono) o en una combinación.
A su vez, se prevé la incorporación de herramientas de comunicación
aumentativa alternativa que permitan su utilización como parte de un
proceso de rehabilitación en el caso de personas con afasia.
Conclusión
El desarrollo de sistemas debe contemplar las necesidades del usuario a
través de una visión global. La proporción de personas con discapacidad
está aumentando notoriamente, particularmente debido al envejecimiento de
la población (expectativa de vida) y las enfermedades crónicas a nivel
mundial.
El desarrollo de aplicaciones que persigan como objetivo la inclusión social
debe ser en un contexto de software open-source de forma que las mismas
puedan ser modificadas y mejoradas para satisfacer necesidades que
inicialmente no fueron contempladas.
El diseño centrado en usuarios permite que un equipo multi-disciplinario
pueda trabajar con una metodología simple y así juntos lograr comprender
los problemas a resolver de forma global.
Bibliografía
Carreras, Olga (2007), La usabilidad como metodología para el
desarrollo de una aplicación. [Ver en línea Olga Carrera 2007]
Hassan Montero, Yussef, y Ortega Santamaría, Sergio (2009), Informe
APEI sobre Usabilidad. Diseño centrado en el usuario
Nielsen, Jakob (2012), Usability 101: Definitions and Fundamentals
Norman, Don (1986), New Perspectives on Human-Computer
Interaction.
Sánchez Caballero (2010), Software libre y accesibilidad
Capítulo 19: Las métricas de accesibilidad desde una perspectiva
práctica: eXaminator, por Carlos Benavidez
Diseñador, Programador y Desarrollador para la web con respeto de
estándares de Accesibilidad y Diseño Universal. Profesor de DIEAU:
Especialización en Diseño de Interacción con estándares de accesibilidad y
usabilidad de la Universidad Tecnológica Nacional. Integra el equipo de
Investigación-Acción Sinapsis que depende de DIEAU - UTN. Es
Presidente de la Cooperativa de Trabajo Interacción Accesible - IACoop.
Las métricas de accesibilidad desde una

perspectiva práctica: eXaminator
Introducción
Los documentos denominados Pautas de Accesibilidad al Contenido en la
Web (WCAG) 1 explican cómo hacer que el contenido Web sea accesible
para todos los usuarios, incluyendo a las personas con discapacidad. Las
WCAG 2.0, publicadas en diciembre de 2008, definen 4 principios que
proporcionan los fundamentos de la accesibilidad web: perceptible,
operable, comprensible y robusto. Por debajo de los principios hay doce
pautas que proporcionan los objetivos básicos que los autores deben lograr
con el fin de crear un contenido más accesible.
Para cada pauta se proporcionan criterios de conformidad verificables
organizados en tres niveles de conformidad: A (el más bajo), doble A y
triple A (el más alto). Para que una página web sea conforme con las
WCAG 2.0, se deben satisfacer por completo uno o más de estos niveles de
conformidad. El grupo de trabajo de las WCAG 2.0 ha documentado
también una amplia variedad de técnicas para cada uno de los criterios de
conformidad. Las técnicas son informativas y se agrupan en dos categorías:
aquellas que son suficientes para satisfacer los criterios de conformidad y
aquellas que son recomendables. También se identifican los fallos más
comunes.
De esta manera, existe una compleja trama de técnicas de evaluación que
requieren ser revisadas individualmente, con el fin de determinar si una
página web logra la conformidad mínima con las WCAG 2.0 (el nivel A).
Se debe usar el mismo procedimiento con todos los criterios de
conformidad de nivel doble A para determinar si la página logra el nivel
doble A y lo mismo sucede con el nivel triple A.
Conformidad con las WCAG 2.0

Para evaluar la conformidad con las WCAG 2.0 se requieren pruebas
manuales y el juicio de evaluadores experimentados, porque las
herramientas de evaluación de accesibilidad web solo pueden comprobar
automáticamente un número limitado de requisitos de accesibilidad. Por
evaluador experimentado se entiende una persona que domina las Pautas de
Accesibilidad, el diseño de páginas web, las ayudas técnicas y conoce cómo
usan la web las personas con distintos tipos de discapacidad.
Es fácil advertir que la evaluación minuciosa de una página web supone un
costo elevado ya que debe ser llevada a cabo por un profesional experto en
accesibilidad dedicando varias horas de trabajo, considerando no solo la
revisión de todas las técnicas sino también la redacción de los informes y
recomendaciones necesarias para corregir los errores que se detecten.
Este costo debe multiplicarse por el número de páginas del sitio a evaluar.
Como generalmente no es factible evaluar cada una de las páginas de un
sitio web, en la Metodología de Evaluación de Conformidad con la
Accesibilidad en sitios Web (WCAG-EM) 2 se especifican los pasos
concretos para definir el alcance de la evaluación, cómo seleccionar una
muestra representativa de páginas, auditar la muestra seleccionada y
reportar los resultados de la evaluación mediante informes estructurados y
uniformes.
Evaluaciones automáticas
Algunas herramientas, como Hera 3, sirven de apoyo al proceso de
evaluación de un experto. Estas herramientas ofrecen resultados fiables para
una serie de pruebas y pueden no solamente acelerar el proceso efectuando
determinadas tareas de forma automática, sino también indicar los aspectos
donde los evaluadores expertos deben centrar su evaluación.
Por el contrario, eXaminator está diseñada para evaluar grandes cantidades
de páginas y tiene un funcionamiento autónomo, ya que en el trabajo
masivo no resulta posible la intervención de un experto por la lentitud de las
evaluaciones manuales y los altos costos que suponen.
Los proyectos de evaluación global de la accesibilidad web son necesarios
para obtener información acerca del estado y evolución de la accesibilidad
de los sitios dentro de un dominio específico o de una determinada
ubicación geográfica.
Un proceso sistemático y continuo de evaluación de los sitios web no solo
ayuda a explorar el nivel global de accesibilidad de los sitios sino que
también permite hacer estudios comparativos y alentar a la mejora de los
procesos.
Un primer problema a resolver cuando usamos un sistema automático para
realizar evaluaciones masivas, comparar los resultados entre los sitios y
monitorear la evolución de esos resultados, lo constituye la necesidad de
contar con una métrica cuantitativa en reemplazo de la métrica ordinal de
las WCAG 2.0.
Métricas de accesibilidad
Para medir la conformidad, las WCAG 2.0 usan una escala ordinal que
jerarquiza los criterios de conformidad de acuerdo a un rango (niveles A,
doble A y triple A). Los criterios de nivel A son aquellos que, de no
cumplirse, pueden provocar que ciertos grupos de usuarios no puedan
acceder a la información; por esa razón el nivel A es el mínimo exigible.
Los criterios de nivel doble A son aquellos que pueden hacer muy difícil el
acceso a los contenidos a determinados grupos de usuarios y los de nivel
triple A son los que pueden crear algunas dificultades a ciertos usuarios.
Pero esto no significa que todos los criterios de determinado nivel de
conformidad afecten por igual a todos los usuarios. La ausencia de textos
alternativos en los elementos no textuales es un error de nivel A porque los
usuarios de lectores de pantalla, que no pueden ver la página, no tienen
ninguna otra forma de saber qué información contienen los elementos no
textuales; pero hay otros usuarios, con otros tipos de discapacidad, para
quienes la falta de textos alternativos no representa ningún inconveniente.
El problema con la escala ordinal de las WCAG 2.0 es su falta de
sensibilidad: un sitio que cumple solo con los criterios de conformidad de
nivel A y ninguno de nivel doble A, obtendría el mismo valor de
accesibilidad que otro sitio que cumple con todos los criterios de nivel A, y
casi todos los de nivel doble A. La falta de precisión de esta escala tampoco
permite conocer cuánto le falta a un sitio que cumple con el nivel A para
alcanzar el nivel doble A.
Para resolver la falta de sensibilidad de la escala ordinal, eXaminator usa
una escala numérica de 1 (la puntuación más baja) a 10 (la más alta),
logrando que cualquier cambio producido en el contenido de una página
provoque un cambio en los resultados, aunque se debe advertir que el paso
de una escala ordinal a una escala numérica no se puede lograr sin cierto
grado de arbitrariedad.
Por ejemplo, podemos definir una nota subjetiva para la falta de textos
alternativos, pero no disponemos de un criterio válido para decidir la
relación con errores de otro tipo (por ejemplo, la falta de contraste de los
colores de la página) que afectan en distinto grado a otros grupos de
usuarios.
Entonces, una primera advertencia es que la accesibilidad no es una
cualidad que se pueda medir con valores absolutos y la nota de eXaminator
solo se puede considerar un indicador aproximado del estado de la
accesibilidad de una página que se utiliza al solo efecto de contar con una
escala más sensible y precisa para realizar las comparaciones.
Además, en las evaluaciones de accesibilidad a gran escala es importante
que los resultados individuales se puedan resumir en un resultado final que
resulte fácil de comprender y tenga una clara interpretación. De este modo
se hace posible comparar la situación de los diferentes sitios web o para
investigar las diferencias entre distintas versiones de una misma página
web.
Limitaciones de las herramientas automáticas

La principal limitación de las evaluaciones automáticas es que solo pueden
comprobar la conformidad de un pequeño subconjunto de criterios de
conformidad. Existen también criterios que pueden ser evaluados
parcialmente pero la mayoría de las técnicas que deben ser revisadas
necesitan del juicio de un experto.
La batería de pruebas de eXaminator no está conformada por las pruebas
más importantes, sino por aquellas que se pueden resolver
automáticamente; esto lleva a que coexistan pruebas muy significativas con
otras de menor valor. Un problema adicional es la cantidad de pruebas que
se pueden realizar en cada página.
En la web encontramos páginas de gran tamaño, con muchos elementos,
junto a pequeñas páginas, con unas pocas líneas de código. La estructura de
cada página determina cuántas pruebas se pueden hacer sobre ella, de modo
que ciertos documentos recibirán más de veinte pruebas, y habrá otros a los
que solo se les podrán efectuar cuatro o cinco pruebas. El problema con
esto es que un mismo error tendrá mayor influencia en el promedio general
a medida que disminuya el número total de pruebas posibles.
Por otra parte, ya no es común la elaboración por parte de un diseñador de
todas y cada una de las páginas de un sitio sino que se usan gestores de
contenidos u otros sistemas con plantillas prefabricadas hechas por otros
diseñadores. En sitios de cierta envergadura trabajan equipos de personas y
hay muchas manos añadiendo o modificando contenidos. Todo esto hace
que las páginas tengan una calidad de diseño variable entre sus secciones y
las pruebas automáticas pueden coincidir en mayor medida con una u otra
sección.
Para evitar que las limitaciones mencionadas sean un factor de desviación
de los resultados, es conveniente trabajar con grupos de páginas de un
mismo sitio porque así las excepciones y desproporciones que pueden darse
en algunas páginas individuales pierden su relevancia y las estadísticas
generales resultan indicios más confiables sobre el estado de la
accesibilidad.
Se debe tener en cuenta que las calificaciones no miden la accesibilidad
general sino el desempeño del grupo de páginas evaluadas con respecto a
las pruebas que realiza la herramienta. En general, la experiencia demuestra
que se pueden obtener buenos indicios sobre la accesibilidad pero no se
puede asegurar que el 8 de un sitio web represente el mismo grado de
accesibilidad que la misma nota en otro sitio.
Más importante que la magnitud de las calificaciones es la posibilidad de
establecer un marco de referencia con las puntuaciones máximas y mínimas
en una muestra de sitios o en los resultados de un mismo sitio a lo largo del
tiempo. Es decir, una calificación de 3 para un sitio adquiere mayor
importancia si existe otro, dentro de la muestra analizada, con una
puntuación de 9. Del mismo modo, si un sitio obtiene un 5 en un
determinado momento, esa nota no es tan significativa como la variación
que obtendrá cuando se realice la misma evaluación cierto tiempo después.
Las notas tienen el propósito de ordenar y comparar los resultados de
grupos de páginas y de sitios web pero la mayor utilidad de las evaluaciones
automáticas es que permiten detectar los errores más habituales y poner en
evidencia algunos procedimientos erróneos que suelen pasar desapercibidos
cuando solo se revisan las páginas individualmente.
Información técnica
Descartada la posibilidad de evaluar automáticamente la conformidad con
las Pautas de Accesibilidad, el objetivo principal de eXaminator es obtener
el mayor número de pruebas sobre la correcta aplicación de las técnicas
recomendadas por las WCAG 2.0.
Con ese propósito, evalúa tanto situaciones negativas como positivas
porque se considera que, a los fines de la obtención de indicios sobre la
correcta aplicación de las técnicas, la detección de algunas buenas prácticas
puede resultar tan valiosa como la comprobación de los errores.
Otras métricas, como la Métrica Cuantitativa de la Accesibilidad Web
(WAQM) 4 y la aplicada por la Metodología Unificada de Evaluación Web
(UWEM) 5, se basan en la tasa de fallo, es decir, la relación entre el número
de errores encontrados y el total de pruebas realizadas. De este modo, la
puntuación disminuye cuando una prueba falla más a menudo.
Un inconveniente de las métricas que miden la tasa de fallo es que la
fórmula de cálculo (número de errores / total de pruebas) se adecua solo a
aquellos casos en los que podemos identificar el total de pruebas, de modo
que el número de errores es siempre una porción de ese total. Por ejemplo,
en la prueba sobre los textos alternativos de las imágenes, el total de
pruebas es el número de imágenes revisadas y el número de errores son las
imágenes sin el atributo alt.
La tasa de fallo no se puede aplicar en aquellos casos en los que no existe
un número total de pruebas, por ejemplo, en la validación de código HTML
de una página. En esos casos, conocemos el número de errores pero no
existe un total de pruebas que nos permita calcular el porcentaje de fallos.
En otros casos, simplemente no es sencillo determinar el total de pruebas:
en la revisión de los atributos HTML obsoletos se podría considerar como
total el número de elementos de las páginas o solo el número de elementos
que tienen asignados atributos HTML.
En WAQM no se explicita cómo se resuelven estos casos dudosos pero
UWEM considera como total de casos el número de errores de validación, o
cero si no existen errores. Del mismo modo, considera como total el
número de atributos HTML obsoletos, o cero si no se usa ninguno de estos
atributos. La consecuencia es que esas pruebas tienen siempre un resultado
binario, ya que será cero si no existen errores y uno cuando los hubiera.
Para sortear estas dificultades, eXaminator apela a distintas fórmulas para
resolver los resultados. Estas fórmulas definen 4 tipos de pruebas que se
aplican en cada caso de modo tal que las calificaciones se correspondan con
estos juicios de valor:
Muy mal: 1
Mal: 2 o 3
Regular: 4 o 5
Bien: 6 o 7
Muy bien: 8 o 9
Excelente: 10
Las calificaciones son empíricas, de modo que existe un componente
subjetivo en las decisiones y también un cierto grado de arbitrariedad. La
escala anterior sirve como guía para determinar las calificaciones pero
decidir si un error merece 3 o 5 es siempre discutible.
La repetición de los errores es un dato importante que se debe tener en
cuenta en las calificaciones. Un único error se puede deber a un desliz pero
varios errores del mismo tipo indican claramente un concepto equivocado
de diseño o un gran descuido en el desarrollo. Además, las barreras de
accesibilidad aumentan en proporción directa al número de errores.
Cuando existe un total de pruebas bien definido, como es el caso de las
imágenes y el atributo alt, se utiliza la tasa de fallo para que la calificación
resulte menor cuanto mayor es la cantidad de errores detectados. Para los
errores de validación, por ejemplo, se aplica otra fórmula que también
disminuye la nota a medida que aumenta el número de errores pero en este
caso la escala de disminución es fija.
También hay pruebas que solo pueden tener resultados binarios. Por
ejemplo, el error que consiste en usar el elemento meta para refrescar la
página solo puede tener dos resultados: bien o mal. En otros casos la
contabilización de los errores, aunque posible, no es significativa. Por
ejemplo, el uso del elemento marquee es un error grave porque provoca
movimientos en el contenido, es un elemento anticuado, no estándar y su
uso denota un concepto pobre de diseño. Por eso, poco importa que se use
uno o más veces y simplemente merece ser calificado siempre con la nota
más baja.
En el cálculo se debe tener en cuenta que no todas las pruebas tienen la
misma importancia, de modo que es necesario ponderarlas para que su peso
relativo refleje esas diferencias. La Ponderación (P) es el producto del
grado de Confianza (C) y el Valor relativo de la prueba (V):
P=C×V
Valor
Indica la importancia relativa de las pruebas de acuerdo al grado en que las
situaciones evaluadas pueden afectar a los usuarios. El problema para hacer
estas valoraciones es que en accesibilidad no disponemos de un usuario tipo
al que podamos tomar como referencia sino que debemos considerar una
muy amplia gama de posibilidades.
Para superar esta dificultad, se definieron 5 perfiles de usuarios que reflejan
las principales barreras de acceso presentes en la web. Los perfiles
seleccionados corresponden a usuarios con:
Limitación total para ver

Limitación grave para ver
Limitación para controlar los miembros superiores
Limitación para comprender
Limitaciones derivadas del envejecimiento
En estos perfiles se intenta incluir a las personas con discapacidad y

también a quienes, por razones tecnológicas o de entorno, se encuentran con
limitaciones similares. Cada prueba recibe una valoración distinta en cada
perfil de usuario de acuerdo con la siguiente escala:
1. Indiferente. La técnica no afecta al usuario.

2. Prudente. La técnica puede beneficiar al usuario.
3. Útil. La técnica resulta de ayuda para el usuario.
4. Importante. La técnica es importante para el usuario.
5. Esencial. La técnica es esencial para el usuario.
Confianza
Indica la seguridad que se le otorga a las pruebas. En una escala de 0 a 1,
todas las pruebas de eXaminator merecerían un valor muy alto porque
aquellas que no ofrecen una alta seguridad de no fallar son descartadas y
por eso se toman en cuenta los pasos indicados en los procedimientos de
revisión de las técnicas relacionadas para definir la confianza de cada
prueba.
Por ejemplo, si el primer enlace de la página tiene como referencia un ancla
en la propia página, la técnica G1 6 de las WCAG 2.0 (“Agregar un enlace
al principio de cada página que lleve directamente al área de contenido
principal”) parece satisfecha pero, observando los procedimientos de
revisión manual, vemos que faltaría verificar manualmente si el enlace es
siempre visible, si el texto del enlace es correcto y si efectivamente el salto
es hacia el contenido principal.
Por cada uno de esos pasos que no es posible verificar automáticamente se
disminuye 0.1 y la confianza de la prueba G1 será 0.7. Este criterio no es
estricto pero proporciona la estrategia necesaria para resolver con cierta
coherencia la confianza de cada prueba.
Tipos de prueba
Para definir los resultados de las pruebas, eXaminator utiliza una matriz de
datos con la siguiente información:
Elemento (E)
Identifica un elemento del lenguaje HTML o un conjunto de estos
elementos. Por ejemplo, el elemento Controles de formulario que requieren
etiquetas asociadas comprende a los input de tipo text, checkbox, radio, file
y password, más los elementos textarea y select. La prueba es aplicable solo
cuando el elemento existe en la página. El elemento all es especial e indica
que la prueba resulta siempre aplicable.
Situación (S)
Identifica un elemento del lenguaje HTML o un conjunto de estos
elementos que cumplen determinada condición. Siempre se trata de un
subconjunto de elemento, excepto cuando el elemento es all. Se debe
encontrar al menos una situación para que la prueba sea aplicable, excepto
en las pruebas de tipo falso, en las que se aplica cuando no se encontró
ninguna situación en la página.
Nota (N)
Es la calificación de la prueba. En las pruebas de resultado variable, es la
calificación inicial a partir de la cual se efectuarán los cálculos posteriores.
En otras palabras, es la calificación que se aplica a la primera situación
detectada.
Tolerancia (T)
En las pruebas de tipo decreciente indica el umbral de tolerancia a los
errores, es decir, el valor a partir del cual se comenzará a disminuir la nota
inicial.
Fracción (F)
En las pruebas de tipo decreciente indica la cantidad de errores que
disminuyen en un punto la nota inicial. Tolerancia y Fracción son datos
exclusivos para las pruebas de tipo decreciente en las cuales cada situación
identifica siempre un error.
Pruebas de tipo verdadero/falso
Ambas pruebas consisten en evaluar una condición y, si esa condición se
cumple, el Resultado (R) es el producto de la Nota (N) y la Ponderación
(P):
R=N×P
Ambas pruebas son idénticas en todo sentido excepto que la condición se
debe evaluar como verdadera en un caso y como falsa en el otro para que la
prueba resulte aplicable.
Prueba de tipo proporcional

En esta prueba, la nota inicial disminuye en proporción al cociente entre
Situación (S) y Elemento (E).
R = N × (1 - S/E) × P
Por ejemplo, en la prueba sobre las alternativas textuales en las imágenes, el
Elemento (E) son las imágenes y la Situación (S) son las imágenes sin alt.
La prueba es aplicable cuando existen ambos. La Nota (N) es la calificación
inicial atribuida a este tipo de errores (en esta prueba la nota es 3 porque se
considera que está mal sin importar cuántas imágenes sin alt se encuentren).
Pero la calificación puede aun ser menor si consideramos la extensión de
los errores. Entonces, se calcula la tasa de fallo y luego el porcentaje a
sustraer de la nota inicial. Si las imágenes son 8 y hay 4 sin alt, sin tomar en
cuenta la ponderación, el cálculo sería:
R = 3 × (1 - 4/8) = 3 × (1 - 0.5) = 3 × 0.5 = 1.5
La calificación inicial (3) se reduce a la mitad (1.5) porque el error está
presente en el 50% de las imágenes encontradas.
Prueba de tipo decreciente

En esta prueba, la nota inicial va disminuyendo a medida que aumenta la
cantidad de errores. La Tolerancia (T) indica cuántos errores se permiten
antes de comenzar a restar de la nota; superado el umbral de tolerancia,
cada Fracción (F) disminuye en un punto la nota inicial.
R = (N - (S - T) / F) × P
Por ejemplo, cuando existen errores de validación, la nota inicial es 5 y la
tolerancia es 10. Es decir, se considera que hasta 10 errores de validación es
una situación que se puede calificar como regular (la tolerancia es bastante
alta por el efecto de arrastre que tienen algunos errores). Si existen más de
10 errores, la nota comienza a disminuir 1 punto por cada fracción, que en
esta prueba también es de 10. Suponiendo que encontramos 40 errores, sin
tener en cuenta la ponderación, sería:
R = 5 - (40 - 10) / 10 = 5 - 30 / 10 = 5 - 3 = 2
Entonces, la calificación es 5 cuando existen entre 1 y 10 errores; con 40
errores la nota baja a 2 y así, si se encuentran más de 50 errores de
validación la nota sería 1, la mínima.
Promedios
Por último, el resultado de la puntuación de una página es la división de la
sumatoria de las pruebas realizadas por la sumatoria de las respectivas
ponderaciones. Por ejemplo, si se consideran solo 2 pruebas: la prueba A
con ponderación 1 y la prueba B con ponderación 0.1, la sumatoria de las
ponderaciones es 1.1.
Si la nota en ambas pruebas es 9, la puntuación final será, lógicamente, 9.
El resultado ponderado de la prueba A es 9 (9 × 1) y el de la prueba B es
0.9 (9 × 0.1). La sumatoria de las pruebas ponderadas es 9.9 (9 + 0.9), que
al dividirla por la sumatoria de las ponderaciones (1.1) nos da 9 (9.9 / 1.1).
Si la prueba A tuviera un 2 como nota, de modo que la nota ponderada
fuera 2 (2 × 1) y la sumatoria de las pruebas fuera 2.9 (2 + 0.9), la
puntuación sería 2.6 (2.9 / 1.1) luego de redondear el resultado. Pero si es la
prueba B la que tiene 2, la sumatoria de las pruebas nos daría 9.2 (9 + 0.2) y
la puntuación sería 8.4 (9.2 / 1.1).
Con este ejemplo muy sencillo se puede apreciar la importancia de la
ponderación de las pruebas. Si promediáramos simplemente las notas 9 y 2,
obtendríamos 5.5 pero así estaríamos poniendo en un mismo nivel a las dos
pruebas cuando las ponderaciones indican que la prueba A tiene un valor
muy alto y es de máxima confianza, mientras que la prueba B es mucho
menos significativa. Entonces es lógico que la prueba B tenga un peso
mucho menor en la puntuación final. Observen que al promediar A, que
tiene una nota de 2, con B, que tiene 9, la puntuación final es 2.6, es decir,
el promedio queda muy cerca de 2, que es la nota de la prueba con mayor
ponderación.
En términos prácticos, las ponderaciones permiten establecer un necesario
balance entre las pruebas e impiden que el resultado de una página dependa
de una sola prueba, tal vez inexacta. Para obtener una mala puntuación el
balance de las pruebas debe ser claramente desfavorable. Es necesario que
se detecten varios errores y, por el contrario, que no se detecten buenas
prácticas en la cantidad y con la ponderación suficiente como para
compensar esos errores. No se puede atribuir a la casualidad una puntuación
muy baja así como una puntuación muy alta difícilmente se consiga por un
golpe de suerte.
Promedio general
Todas las operaciones descriptas anteriormente sirven para obtener una
calificación para cada uno de los perfiles de usuarios. Del mismo modo, en
el informe de resultados se indica la importancia que tiene cada prueba para
cada uno de los perfiles. Finalmente, la calificación final de la página se
obtiene del promedio simple de las cinco calificaciones parciales.
Esta estrategia tiene dos propósitos principales. En primer lugar sirve para
identificar los tipos de usuarios que se ven afectados por cada técnica,
indicando también en qué medida son afectados. Si bien esta información se
puede obtener leyendo la documentación de las pautas, es más evidente y
pedagógico si cada resultado incluye las valoraciones por tipos de usuarios.
Las calificaciones por tipos de usuarios permiten, además, realizar estudios
sobre la accesibilidad de un determinado sector de la web con relación a
uno o más perfiles de usuarios. Por ejemplo, una asociación de personas
con discapacidades neurológicas podría investigar el grado de accesibilidad
de los periódicos en línea para las personas con limitación para comprender
y recomendar a sus asociados los sitios con mejores calificaciones.
Documentación y ayuda
La calificación es solo un indicador cuyo objetivo es, principalmente,
ordenar y comparar las evaluaciones de grupos de páginas pero esta función
básica se complementa, en eXaminator, con una detallada información
sobre cada una de las pruebas realizadas.
Como las pruebas se relacionan directamente con una técnica de las WCAG
2.0, eXaminator proporciona enlaces a los documentos de esas técnicas y a
los de los Criterios de Conformidad relacionados. También identifica y
señala en las páginas los elementos revisados. Esto no solo permite detectar
los errores y ayuda a corregirlos sino que también sirve para comprobar si
la información proporcionada por la herramienta es correcta.
La documentación y ayuda adicional que proporciona eXaminator permite
que se la use para reparar los errores de accesibilidad de un sitio. En estos
casos puede resultar necesario establecer objetivos de trabajo y las
puntuaciones resultan un parámetro tentador porque permiten establecer
metas claramente definidas: se puede poner como objetivo que todas las
páginas del sitio alcancen una puntuación mínima de 7, por ejemplo.
El problema es que no se puede usar la puntuación de un modo escolar,
considerando que alcanza con 4 o 6 para aprobar la materia. Para establecer
objetivos precisos es más útil concentrarse en la corrección de los errores
más importantes o, incluso, de los errores más fáciles de corregir.
El informe de resultados incluye una tabla que muestra el detalle de las
pruebas efectuadas, la nota de cada prueba y su ponderación. Esta
información permite evaluar cuáles son los errores más importantes y fijar
estrategias para el trabajo futuro. También puede servir para llevar un
registro del avance de esos trabajos comparando las tablas de una misma
página en dos momentos distintos.
Arquitectura de programación
eXaminator está programado en PHP y hace un uso intensivo de la
extensión DOM y la clase DOMXPath para revisar la estructura de las
páginas. El proceso de revisión tiene tres etapas bien definidas:
Petición de la página
eXaminator actúa como un cliente HTTP para obtener las páginas web
mediante el método GET usando fsockopen o, alternativamente, cURL.
Aunque con capacidades más limitadas que un navegador web, tiene
soporte para un subconjunto de funciones útiles para comunicarse
eficientemente con los servidores web.
Una vez obtenida la página solicitada, se extrae alguna información de las
cabeceras HTTP y se separa el cuerpo de la respuesta para su
procesamiento. La información se guarda en una matriz que almacenará
todos los datos de la página, incluyendo las pruebas y los resultados
completos.
Análisis de la página
Para el análisis de la página web se utiliza la extensión DOM de PHP5. El
DOM proporciona un modelo abstracto del documento y una interfaz
estándar para acceder a los objetos de la página y sus propiedades.
Como paso previo a la obtención del DOM se realizan algunas operaciones
como la eliminación del BOM (Byte Order Mark) que suelen contener
algunos documentos codificados en UTF-8. Para obtener la DTD del
documento se recurre a las expresiones regulares de PHP ya que el DOM de
la página siempre contiene una DTD, aún cuando el documento original no
contenga esa declaración.
Una vez generado el DOM del documento se realiza un recorrido por todo
el árbol de nodos y se usa un contador para que cada nodo tenga asignado
un identificador único. Este identificador servirá para seleccionar los
elementos de la página que deben mostrarse en los informes de los
resultados.
El objetivo del recorrido de los nodos del DOM es detectar el número de
elementos y situaciones presentes en la página (el significado de elementos
y situaciones está explicado antes en Tipos de prueba). Por ejemplo,
eXaminator contiene varias pruebas sobre las imágenes y para definir los
resultados necesita obtener estos datos:
Cantidad total de elementos img (código: img)
Cantidad de elementos img sin atributo alt (código: imgAltNo)
Cantidad de elementos img con atributo alt nulo (código: imgAltNull)
Cantidad de elementos img con atributo alt muy extenso (código:
imgAltLong)
Cuando en el recorrido del DOM se detecta un nodo del tipo
XML_ELEMENT_NODE con el nombre img, se utiliza una función con el
mismo nombre para analizar detalladamente el nodo. Esta función verifica
si el elemento img contiene el atributo alt y, si no es así, suma uno al
elemento imgAltNo. Si existe ese atributo pero es nulo, suma uno a
imgAltNull y si el texto del atributo alt contiene más de 100 caracteres,
suma uno a imgAltLong.
A la vez que se suman los elementos, se anota el identificador del nodo. De
este modo, cuando se quieran mostrar las imágenes con alt nulo, por
ejemplo, bastará con realizar el mismo recorrido del árbol del DOM usando
el mismo sistema para numerar los nodos. Cabe mencionar que eXaminator
guarda una copia de la página evaluada para asegurarse de que todas las
operaciones futuras se realicen sobre la misma versión del documento.
Definición de los resultados

Como se explicó en Tipos de prueba, existe una matriz para guardar toda la
información necesaria sobre cada una de las pruebas. Para definir los
resultados, se recorre esta matriz de datos y se comprueba si en el
documento existe el elemento y la situación necesaria para que la prueba
resulte aplicable.
Cuando la prueba es aplicable, se usa la función específica para cada tipo de
prueba (verdadero, falso, proporcional o decreciente) y se calcula la
puntuación tomando en cuenta la nota y la ponderación de la prueba.
La ponderación es el producto del grado de confianza y el valor relativo de
la prueba pero, como cada perfil de usuario tiene un valor propio para cada
prueba, la operación se repite seis veces, una por cada perfil de usuario.
Una vez definidos los resultados de todas las pruebas aplicables, se
promedian los resultados correspondientes a cada uno de los perfiles de
usuarios. Para obtener la puntuación general de la página se promedian,
finalmente, las puntuaciones obtenidas por los seis perfiles de usuarios.
Conclusiones
El Informe de Investigación sobre Métricas de Accesibilidad Web 7 del
Grupo de Trabajo sobre Investigación y Desarrollo del WAI 8 plantea que
“las métricas de accesibilidad web son una herramienta muy valiosa para
los investigadores, desarrolladores, agencias gubernamentales y usuarios
finales. Las métricas ayudan a indicar el nivel de accesibilidad de los sitios
web, incluyendo el nivel de accesibilidad de los sitios web individuales, o
incluso las evaluaciones a gran escala de la accesibilidad de muchos sitios
web”. Pero ese informe también advierte que los métodos y ejemplos para
evaluar la validez de las métricas usadas en la actualidad son poco
frecuentes y que es necesario realizar más esfuerzos dirigidos a investigar
su confiabilidad y sus alcances.
eXaminator fue la primera herramienta en línea que, en el año 2005, aplicó
una métrica cuantitativa para calificar la accesibilidad de las páginas web.
Su metodología sufrió cambios sustanciales producto de la experiencia
adquirida, ya que desde el 2006 se utiliza en el monitoreo de miles de
páginas de la administración pública de Portugal.
Sin embargo, hasta la realización del Simposio en Línea sobre Métricas de
Accesibilidad Web 9 realizado en diciembre de 2011, eXaminator no contó
con la documentación necesaria para explicar su modo de operar, ni los
conceptos que servían de fundamento a su particular modo de evaluar la
accesibilidad.
En este trabajo se ha pretendido brindar la mayor cantidad de información
posible acerca de eXaminator como una forma de enmendar esa omisión
inexcusable, con la esperanza de que sirva también para acompañar los
esfuerzos actuales en la investigación de las métricas de accesibilidad.
Referencias
1 Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0; SIDAR
2 Website Accessibility Conformance Evaluation Methodology (WCAG-
EM) 1.0; W3C
3 Hera;
4 Quantitative Metrics for Measuring Web Accessibility; Descargar PDF
5 Unified Web Evaluation Methodology (UWEM); [Ver en línea
WebCluster]
6 Techniques for WCAG 2.0: G1; WCAG 2.0
7 Research Report on Web Accessibility Metrics; Accessibility Metrics
8 Research and Development Working Group [Ver en línea RDWG]
9 Website Accessibility Metrics
Glosario
Ayudas Técnicas
El término “ayudas técnicas” (en inglés assistive technologies) ha sido
sustituido por el de “producto de apoyo”, tal y como recomienda la
Norma UNE-EN ISO 9999:2007: Productos de apoyo para personas
con discapacidad. Clasificación y terminología (ISO 9999:2007), que
los define como “cualquier producto (incluyendo dispositivos, equipo,
instrumento, tecnología y software) fabricado especialmente o
disponible en el mercado, para prevenir, compensar, controlar, mitigar
o neutralizar deficiencias, limitaciones en la actividad y restricciones
en la participación”. Los productos de apoyo son por tanto dispositivos
diseñados para ayudar a las personas con discapacidad a realizar tareas
que de otra manera no podrían realizar. Dentro de la informática son
aplicaciones software o dispositivos hardware empleados para el uso
del ordenador y el acceso al contenido de la Web: lectores de pantalla,
ampliadores de pantalla, teclados alternativos, líneas braille, etc.
Back-end
El código de una página o aplicación Web que reside y es ejecutado en
el servidor. Éste accede a la información en la base de datos, determina
cómo y cuando mostrarla, y la entrega al navegador Web en forma de
páginas HTML. También se denomina de esta forma al gestor de
contenidos o “sistema de auto-administración” que puede tener un sitio
Web.
Closed Captions
Sistema de subtítulos destinado a permitir que las personas con
problemas de audición puedan ser conscientes de todos los sonidos de
una película o videojuego. A diferencia de los subtítulos comunes, que
sólo describen los diálogos, este sistema describe todo el audio
presente (incluyendo música de fondo y efectos de sonido) mediante
palabras o símbolos.
Colapsable
Un patrón de interfaz de usuario en el que la información se esconde y
se revela en forma gradual al usuario a medida que éste la solicita. Por
ejemplo, un menú desplegable, o un botón con signo “+” que al ser
activado despliega más texto en la misma pantalla.
Concurrent Think Aloud (CTA)
Aplicado al test de usuarios, es una técnica que consiste en que el
usuario expresa en voz alta sus pensamientos.
Daltonismo
El daltonismo es un defecto genético que ocasiona dificultad para
distinguir los colores. El grado de afectación es muy variable y oscila
entre la falta de capacidad para discernir cualquier color
(acromatopsia) y un ligero grado de dificultad para distinguir algunos
matices de rojo y verde.
Dojo Toolkit
Una librería JavaScript con componentes de interfaz de usuario,
utilidades y herramientas que facilitan la programación de aplicaciones
interactivas complejas.
Etiquetas (meta-dato)
Palabras clave, organizadas en forma no jerárquica, que describen el
contenido de un recurso de información, sea una noticia, una foto, un
artículo, producto, etc. Permite vincular con otros recursos que
compartan las mismas palabras clave.
Etiqueta (lenguaje de marcado)
En un lenguaje de marcado, las etiquetas se ubican alrededor de un
fragmento de texto, para diferenciarlo del resto. Por ejemplo se usa
 para indicar el comienzo de un párrafo, y para indicar donde
termina. El lenguaje HTML incluye más de 100 etiquetas como ésta,
incluyendo la etiqueta <a> que permite enlazar páginas entre si,
elemento esencial a la naturaleza hipertextual de la Web.
Etiquetas deprecadas
Se denomina así a etiquetas que se utilizaban en versiones anteriores
de HTML, pero cuyo uso ya no es recomendado por la última versión
de este estándar.
Eye tracking
Técnica que consiste en el seguimiento y grabación de la mirada.
Experiencia del Usuario (User eXperience, UX)
Se puede definir como “la sensación, sentimiento, respuesta
emocional, valoración y satisfacción del usuario respecto a un
producto, resultado del fenómeno de interacción con el producto y la
interacción con su proveedor” [Hassan-Montero, Y.; Martín-
Fernández, F. J. “La Experiencia del Usuario”: No Solo Usabilidad, nº
4, 2005
Framework
Marco de trabajo para el desarrollador. Se trata de un conjunto de
librerías de código, patrones de programación y criterios de trabajo.
Esto facilita la tarea del programador, optimiza tiempos, y promueve
mejores prácticas.
Front-end
El código de una página Web que se ejecuta en el navegador, de cara al
usuario. Incluye HTML, CSS y JavaScript, así como otras tecnologías
de la plataforma Web.
jQuery
Una muy popular librería de código JavaScript que facilita el trabajo
del programador front-end, simplificando la interacción con el DOM,
el uso de AJAX, y otras tareas comunes.
Lector de pantalla
Es un tipo de software incluido dentro de los denominados “productos
de apoyo”, que identifica e interpreta lo que se muestra en pantalla y lo
presenta al usuario mediante un sintetizador de voz o mediante una
línea braille.
Productos de apoyo.
Liveviewing
Aplicado al test de usuarios con eye tracking, es una técnica que
consiste en que el moderador “ve por los ojos del usuario”, es decir,
observa desde un monitor remoto la sesión, sin grabar o revisar
posteriormente los videos.
Marcado semántico
Refiere al uso apropiado de etiquetas HTML a fin de que el sentido de
un bloque de texto sea interpretable programáticamente. Por ejemplo,
si utilizo CSS para dar formato a una línea de texto de modo que se
vea grande y en negritas, entonces un programa (como el motor de
indexación de Google) no tiene forma de determinar que esto es un
encabezado. Corresponde entonces marcar “semánticamente” ese texto
utilizando una etiqueta <h1>, de esta forma está claro para cualquier
programa que se trata de un encabezado (heading) de nivel uno.
Mapa de calor
En una grabación con eye tracking, es el mapa que representa por
medio de colores las zonas que han recibido más miradas de los
usuarios.
Mapa de opacidad
En una grabación con eye tracking, es el mapa que oculta con color
negro las zonas que los usuarios no han mirado.
Mapa de recorrido
En una grabación con eye tracking, es el mapa que representa por
medio de líneas las sacadas y por medio de círculos las fijaciones de
cada usuario, numeradas en el orden en que ocurrieron.
Maquetado
La tarea de convertir el diseño visual de una página Web (hecho en
Photoshop por ejemplo) en una plantilla HTML y CSS, que funcione
correctamente en un navegador.
Meta-datos
Datos que describen otros datos. En el caso de una página Web, se
trata de atributos que se proveen en forma estandarizada o por
convención, para consumo de un programa (como el motor de
indexación de un buscador, o ayudas a la navegación). Esto incluye
información acerca de qué tipo de contenido es, quién es su autor,
fecha y otros datos de publicación, relaciones con otros artículos, etc.
MVC, arquitectura
Es un patrón de arquitectura de software, que propone separar el
código en “modelo, vista y controlador”. El modelo maneja la lógica
de negocio y el acceso a los datos. La vista es una representación de
los datos, por ejemplo mediante una plantilla HTML. El controlador
recibe datos del usuario, y media entre el modelo y la vista. Algunos
frameworks populares que utilizan este patrón o variaciones del mismo
son Ruby on Rails (Ruby), Django (Python), Backbone (JavaScript) y
Laravel (PHP).
Parálisis cerebral
Trastorno permanente y no progresivo que afecta a la psicomotricidad
del paciente. En un nuevo consenso internacional, se propone como
definición: “La parálisis cerebral describe un grupo de trastornos del
desarrollo psicomotor, que causan una limitación de la actividad de la
persona, atribuida a problemas en el desarrollo cerebral del feto o del
niño. Los desórdenes psicomotrices de la parálisis cerebral están a
menudo acompañados de problemas sensitivos, cognitivos, de
comunicación y percepción, y en algunas ocasiones, de trastornos del
comportamiento”.
Ratón facial
Programa de ordenador que, unido a una webcam USB estándar o
especial diseñada especialmente para esto, es capaz de reproducir las
funciones de un ratón (movimiento y pulsación de botones). El
movimiento del puntero del ratón se realiza en coordinación con la
zona del cuerpo que apunte la webcam y que previamente hemos
elegido (generalmente suele ser una parte de la cara). Las acciones de
los botones se realizan con gestos predefinidos o con un sonido.
Retrospective Think Aloud (RTA)
Aplicado al test de usuarios, es una técnica que consiste en que el
usuario, una vez terminado el test, ve el vídeo de la sesión y comenta
en voz alta lo que le ocurría en cada momento, en un storytelling.
RTA
(véase Retrospective Think Aloud)
Sacada
Movimiento ocular que hacen los ojos entre dos fijaciones.
Saccade
(véase Sacada)
Storytelling
Aplicado al test de usuarios, narración de una situación que se ha dado
durante el test.
Scroll
cuando una página individual, por la cantidad de contenido que
contiene, no entra en la pantalla, el navegador provee al usuario un
control de desplazamiento vertical, o scroll bar, que desplaza el
contenido como si fuera una larga hoja detrás de una ventana. En
dispositivos táctiles, este desplazamiento se logra arrastrando con el
dedo la pantalla de un extremo al otro.
SCRUM
Scrum es un marco de trabajo para la gestión y desarrollo de software
basada en un proceso iterativo e incremental utilizado comúnmente en
entornos basados en el desarrollo ágil de software.
Special Effect
Asociación sin ánimo de lucro de Reino Unido que se dedica a la
investigación y difusión de la accesibilidad en los videojuegos. Ir a la
Web de la Asociación.
Unity 3D
Motor y editor de videojuegos multiplataforma creado por Unity
Technologies
Visión foveal.
Visión registrada en la fóvea del ojo; es la visión más nítida debido a
que la fóvea tiene gran parte de los conos.
Visión parafoveal
Visión registrada en la zona que rodea la fóvea del ojo; es una visión
menos nítida que la foveal.
Visión periférica
Visión registrada en las zonas lejana a la fóvea del ojo; es la visión
menos nítida.
Wireframe
Boceto esquemático de una página, que permite prototipar a grandes
rasgos su contenido, organización y jerarquías; sin adentrarse en
detalles de diseño visual.
Web Accessibility Initiative (WAI)
http://www.w3.org/WAI/ Es un grupo de trabajo permanente del W3C
que, en coordinación con organizaciones alrededor de todo el mundo,
persigue la accesibilidad de la Web a través de cinco áreas de trabajo
principales: tecnología, directrices, herramientas, formación y
difusión, e investigación y desarrollo.
World Wide Web Consortium (W3C)
http://www.w3.org/ Es una comunidad internacional que desarrolla
estándares que aseguran el crecimiento de la Web a largo plazo con el
objetivo de guiar la Web hacia su máximo potencial.
XML
Lenguaje de marcado extensible. Permite definir nuevos lenguajes que,
como HTML, utilizan etiquetas para marcar fragmentos de texto, y
permite el intercambio de información estructurada entre diferentes
plataformas. Los nuevos lenguajes hechos posible por XML incluyen,
entre muchos otros: SVG (gráficos vectoriales), MathML (ecuaciones),
Atom y RSS (sindicación de contenidos) y SOAP (servicios web).
YUI de Yahoo
Librería de interfaz de usuario en HTML, CSS y JavaScript provista
por Yahoo como código abierto, para la creación de aplicaciones web
de interacción dinámica.

Pioneros I

Cargado por

Copyright:

Formatos disponibles

Pioneros I

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pioneros I

Cargado por

Copyright:

Formatos disponibles

Pioneros y hacedores.

Fundamentos y Casos de Diseño de interacción

Crearon este eBook accesible:

Julio Incarbone (Coordinador de DIEAU y Co-fundador de IAcoop) con el

Hernán Thomas por introducirme en la sociología de la tecnología.

El botón de los $300 millones

“No estoy acá para iniciar una relación”

No tan bueno para usuarios frecuentes tampoco

La solución de los $300 millones

Cómo usamos la Web realmente

Hecho de la realidad #1 Las páginas no se leen,

Hecho de la realidad #2 No tomamos óptimas

Hecho de la realidad #3 No nos interesa

Mobile Site vs. Full Site 1

¿Por qué las versiones web de los sitios no

Diseño de interacción, prácticas de

Explorar posibles futuros, partiendo de una situación concreta.

Las diferencias más significativas entre el diseño de interacción y otras

Imágen 2: La Imac original de Apple y el cuenta pasos PE316FM de Oregon Scientific de

El diseño y la construcción de los detalles de VisiCalc pueden no haber sido

Una contribución al conocimiento científico —una declaración en la

Si aceptamos la idea de que el diseño puede conducir al conocimiento,

Una tesis doctoral es un texto argumentativo, que empieza con una

Si bien podemos esperar la publicación de nuevas normas sobre la

Diseño participativo para la inclusión digital: El

Desarrollo del proyecto IPIT con la participación

Problemas con el Programa IPIT en los

El programa indígena de PRE-IT

Aparte de la política de admisión relajada probada en 2005, ha habido

Los procedimientos estándar de reclutamiento de estudiantes fueron

Los siguientes testimonios nos permiten conocer el Programa IPIT desde el

Colaboración con la comunidad aborigen local

Mini biografía de Sergio Ortega Santamaría

Entre la Arquitectura y la Información

Ventajas de la proliferación de espacios

Cómo hemos enfrentado estos retos hasta

¿Publicación o lugar? Ambos

Qué hacen los arquitectos tradicionales

Qué hacen los arquitectos de la información

Accesibilidad Web y SEO

¿Cómo se hace el contenido web accesible?

¿Cómo se mejora el posicionamiento en

Facilitar el rastreo y la indexación de las páginas por parte de los

El usuario ciego más rico del mundo

Alternativas textuales para elementos no

Las alternativas textuales permiten a las personas que no pueden percibir el

Teniendo en cuenta que los buscadores solo entienden texto, podrán

Título e idioma de las páginas

Desde el punto de vista SEO

Es imprescindible que el robot de los motores de búsqueda pueda rastrear

Encabezados y marcado semántico

El marcado semántico y el uso correcto de los encabezados de la página

Estándares y separación entre contenido y

Un código válido y de acuerdo a la especificación asegura que los agentes

La separación entre el contenido y la presentación genera páginas más

Mapa web y navegabilidad

Los requisitos para mejorar la navegabilidad nos benefician a todos, pero

Es más sencillo inferir la temática de un contenido textual claro, conciso y

Google indexa también archivos PDF [Google, 2011b] y SWF Flash

Mini biografía de Daniel Márquez