Máster Universitario en Desarrollo Ágil

de Software para la Web

Tema 2 – Desarrollo de interfaces

de usuario
Documentación

6 Créditos ETCS - Obligatoria

1 de 22
 índice
1 DESARROLLO DE INTERFACES DE USUARIO ............................................................................................... 3
1.1 ANÁLISIS (O DISEÑO) CENTRADO EN EL USUARIO ...................................................................................... 3
1.2 EJEMPLOS ................................................................................................................................................... 3
1.2.1 Ejemplo: proyecto interLiving ................................................................................................................ 3
1.2.2 Ejemplo: mapas de comunicación ......................................................................................................... 4
1.2.3 Ejemplo: sonda de comunicación .......................................................................................................... 4
1.2.4 Escenarios: prototipos de "baja calidad" ............................................................................................... 4
1.3 TÉCNICAS PARA DCU ....................................................................................................................................... 5
1.3.1 Técnicas básicas para DCU .................................................................................................................... 5
1.3.2 Técnicas recomendadas para DCU ........................................................................................................ 5
1.3.3 Card Sorting ........................................................................................................................................... 5
1.3.4 Contextual Inquiry ................................................................................................................................. 6
1.3.5 Focus Groups ......................................................................................................................................... 7
1.3.6 Entrevistas ............................................................................................................................................. 7
1.3.7 Análisis de logs ...................................................................................................................................... 8
1.3.8 Prototipos en papel................................................................................................................................ 8
1.3.9 Prototipos de baja calidad ..................................................................................................................... 9
1.3.10 Test de usabilidad ................................................................................................................................ 9
1.4 ANÁLISIS DE TAREAS......................................................................................................................................... 9
1.4.1 ConcurTaskTree ...................................................................................................................................10
1.4.2 GOMS...................................................................................................................................................10
1.4.3 Métodos heurísticos ............................................................................................................................12
1.4.4 DCU dentro del proceso unificado .......................................................................................................13
1.4.5 Ejemplo de metodología ......................................................................................................................13
1.5 DISEÑO .......................................................................................................................................................13
1.5.1 Diseño mediante principios .................................................................................................................13
1.5.2 Diseño mediante directrices (Guidelines) ............................................................................................14
1.5.3 Estándares de diseño ...........................................................................................................................14
1.5.4 Estándares “de iure” ............................................................................................................................15
1.5.5 ISO 9241...............................................................................................................................................16
1.5.6 ISO 11581.............................................................................................................................................16
1.6 ACCESIBILIDAD..............................................................................................................................................17
1.6.1 Principios de la accesibilidad ...............................................................................................................18
1.6.2 Evaluación y prueba ............................................................................................................................20
2 BIBLIOGRAFÍA ........................................................................................................................................ 22

2 de 22
1 Desarrollo de interfaces de usuario
1.1 ANÁLISIS (O DISEÑO) CENTRADO EN EL USUARIO

 El diseño centrado en el usuario (DCU) es una metodología de desarrollo dirigida por:

 Objetivos de negocio claramente especificados en forma de tareas.
 El reconocimiento de las necesidades, limitaciones y preferencias de los usuarios.
 Según Woodson DCU es:

La práctica de diseñar productos de forma que sus usuarios puedan servirse de ellos
con un mínimo de estrés y un máximo de eficiencia"

 La información obtenida en DCU se aplica (de manera objetiva - científica) al diseño, prueba e
implementación de productos y servicios.
 Los elementos fundamentales a tener en cuenta son usuarios, tareas y el contexto.

1.2 EJEMPLOS
1.2.1 Ejemplo: proyecto interLiving

 Concepto "disappearing computer"

 6 familias (3 francesas y 3 suecas).

o psicólogos,
o etnólogos e
o informáticos

 Primera reunión:

o Descripción del proyecto

o "Mapas de comunicación", "sondas"
o Entrevistas grabadas

3 de 22
1.2.2 Ejemplo: mapas de comunicación

1.2.3 Ejemplo: sonda de comunicación

Registro de todos los contactos durante una semana.

1.2.4 Escenarios: prototipos de "baja calidad"

4 de 22
1.3 Técnicas para DCU
1.3.1 Técnicas básicas para DCU

Proyecto TRUMP "Cost-effective UCD".

Tres elementos básicos:

 Una reunión con los participantes para obtener una idea global de los objetivos del producto y
la usabilidad.
 Evaluación temprana de conceptos de diseño antes del diseño detallado o codificación
(prototipos en papel).
 Evaluación de prototipos con usuarios reales.

1.3.2 Técnicas recomendadas para DCU

Son una extensión de las básicas:

 Análisis del contexto de uso con usuarios potenciales.

 Especificación de escenarios para algunas tareas.
 Evaluación del sistema existente.
 Obtener requisitos de usabilidad para la prueba posterior.
 Comprobar el uso de guías de estilo y directrices de diseño, provenientes de los requisitos de
usabilidad.
 Evaluación de prototipos, como versión reducida de los test de usuarios.

1.3.3 Card Sorting

Técnica experimental donde los elementos de información se escriben en "tarjetas" que los usuarios
ordenan en categorías de acuerdo a criterios predeterminados.

5 de 22
  Los usuarios explican por qué han incluido a cada elemento en cada categoría.
 10-20 usuarios.

Ventajas:

 Rápido y barato.
 No se requiere tecnología.

Inconvenientes:

 Es difícil obtener resultados en sesiones complejas.

 No revela problemas de interfaz.

Más información en:

Card sorting: a definitive guide

1.3.4 Contextual Inquiry

La investigación contextual (contextual inquiry) es un estudio de campo especializado

 Los diseñadores y miembros del proyecto visitan a los usuarios en su lugar de trabajo para
analizar sus hábitos, actividades, flujos y factores del entorno.
 No es una entrevista, ya que tanto el usuario como el desarrollador tienen el rol de expertos
(diseño participativo), y no hay un plan preparado de preguntas específicas: se trata de
observar el contexto de uso.

Ventajas:

 Observa a los usuarios en su entorno de trabajo.

 Útil especialmente en las fases tempranas del desarrollo.

Inconvenientes:

 Puede ser costoso en tiempo y difícil de ajustar por los horarios de trabajo.
 Las observaciones no están estructuradas, son dispersas.

Fases:

 Identificación de los usuarios finales.

6 de 22
  Formación de un grupo y plan de visitas.
 Fijación del "foco": los elementos a investigar.
 En el lugar de trabajo:

o Registrar cómo trabaja el usuario, las interferencias y cómo utiliza diferentes herramientas.

Es importante entender que:

 El contexto de trabajo determina las necesidades de los usuarios.

 Los usuarios son socios (partners) en el proceso de diseño.
 El foco debe guiar las entrevistas.

1.3.5 Focus Groups

Los usuarios participan en una discusión guiada donde comparten sus ideas y opiniones sobre el
sistema.

 Entre 6 y 10 usuarios, unas 2 horas de discusión

 Idea básica: obtener datos subjetivos de carácter cualitativo.
 Debe combinarse con técnicas de usabilidad menos sujetas a la subjetividad.

Ventajas:

 Hace emerger objeciones e inseguridades respecto al sistema que es difícil obtener con otras
técnicas.
 Puede generar grandes cantidades de datos en poco tiempo.

Inconvenientes:

 Requiere un moderador experimentado.

 Puede caer en el "efecto dominación" cuando un usuario lleva la discusión a su punto de
vista.
 Sujeto a inconsistencias conocidas entre lo que un usuario dice en una reunión y lo que
realmente hace.

1.3.6 Entrevistas

Entrevista con preguntas semi-estructuradas:

 Los entrevistados pueden ser usuarios, directivos, expertos en contenidos, etc.

 Cara a cara o a distancia (por teléfono)
 Puede incluirse el uso de un sistema existente durante la entrevista.
 Se recomienda grabar entrevistas largas, para evitar interferencias con la toma de notas.

Ventajas:

 Bajo coste, modo directo de obtener datos

 Eficaz para obtener necesidades y preferencias de los usuarios.

Inconvenientes:

7 de 22
  No revela informaciones que los usuarios quieren ocultar, o de las que no son conscientes.
 Depende de la memoria y actitud del entrevistado.
 Difícil de planificar si los usuarios tienen mucha sobrecarga de trabajo.

1.3.7 Análisis de logs

Examen de bitácoras (logs) de aplicación para buscar patrones de uso y áreas

potencialmente problemáticas.

Ventajas:

 Proporciona datos históricos de uso.

 Forma fácil de observar objetivamente el comportamiento del usuario.

Inconvenientes:

 No explica por qué se seleccionaron o evitaron ciertas opciones.

1.3.8 Prototipos en papel

Los usuarios explican sus elecciones e interpretaciones en las tareas sobre una versión de
"baja calidad" (low fidelity) del diseño del sistema.

 5-7 usuarios habitualmente.

Ventajas:

 Barato y rápido.
 Permite la prueba de componentes individuales sin invertir en codificación.
 Promueve que los usuarios comenten con libertad y hagan cambios (más que en una versión
más pulida en la cual parece que las cosas están terminadas).

Inconvenientes:

 No justifica la prueba final en el producto terminado.

 Difícil de acomodar a diseños que ofrecen múltiples caminos o alternativas.

8 de 22
1.3.9 Prototipos de baja calidad

1.3.10 Test de usabilidad

Los usuarios trabajan con un prototipo software para ciertas tareas.

 Los evaluadores y diseñadores observan el rendimiento y comportamiento

 "Hablar en voz alta" ayuda a comprender las acciones de los usuarios.
 5-12 usuarios

Ventajas:

 Cortas en duración.
 Encuentra más problemas reales que los métodos heurísticos.

Inconvenientes:

 La efectividad puede verse afectada por los nervios, el realismo de la situación y el efecto de
ser observado.
 Es necesario que las tareas sean como las del sistema final, o bastante similares.
 Planificación y análisis costosos

1.4 Análisis de tareas

El Análisis de Tareas estudia lo que un usuario tiene que hacer en términos de acciones y/o
procesos cognitivos para realizar una tarea.

 Relación con el Proceso Unificado (Paternó, 2001) referido a su modelo CCT:

o "Los actores son roles y los casos de uso pueden considerarse como tareas de alto-nivel"
o "la relación de inclusión puede hacerse corresponder con la descomposición jerárquica de
tareas"
o "la generalización requiere tanto descomposición como un operador de elección entre
alternativas específicas"
o "la extensión se expresa como tarea opcional o como tarea que se realiza cuando ocurre
cierta condición"

9 de 22
  Descomposición jerárquica.

o Ejemplo de Interaction Design, Preece Rogers and Sharp

1.4.1 ConcurTaskTree

1.4.2 GOMS

Familia de técnicas propuesta por Card, Moran, and Newell (1983), para modelar y describir
las prestaciones de las tareas desde el punto de vista humano

 GOMS es un acrónimo que significa Objetivos (Goals), Operadores (Operators), Métodos

(Methods), y Reglas de selección (Selection Rules).

10 de 22
 Externos. Acciones de usuario observables

o Presionar una tecla

o Esperar un evento
o Mover el cursor

 Mentales. Acciones de usuario internas

o Tomar una decisión básica

o Manipular un elemento de la memoria de trabajo
o Establecer un objetivo

 Objetivo (Goal):

o Objetivos del usuario: describen lo que pretende conseguir

 Operadores

o Acciones básicas que se deben llevar a cabo para utilizar el sistema. Son dependientes
del sistema (pulsar la tecla 'X') o del modelo mental del usuario (leer el área de mensajes).

 Métodos

o Existen diferentes alternativas para la consecución de un objetivo. Por ejemplo en un

gestor de ventanas, ésta se puede cerrar bien mediante combinación de teclas (Alt-F4), o
ratón (Archivo-cerrar).

 Reglas de selección

o Elección entre posibles alternativas para alcanzar un objetivo. Se puede recoger el

método más adecuado para cada usuario mediante una serie de reglas que aconsejan la
estrategia más adecuada.

 KLM

o Keystroke Level Model - Card, Moran, Newell 1983

11 de 22
 o Utiliza una sola secuencia de operadores

 CMN-GOMS

o Añadido objetivos, sub-objetivos y métodos

 NGOMSL

o Lenguaje GOMS natural

o Basado en teoría de la complejidad cognitiva

 CPM-GOMS

o Cognitiva, perceptual, motores

o Añadido métodos paralelos, sujeto a restricciones de procesamiento, los modelos utilizan
gráficos PERT

Ejemplo NGOMSL:

1.4.3 Métodos heurísticos

 Revisión experta.

o Expertos revisan un prototipo o sistema, comentando su adherencia a buenas prácticas y

principios de diseño.

 Inspección guiada (guided walkthrough)

o Se guía a un usuario sobre un prototipo haciéndole preguntas sobre su comprensión del

sistema.

12 de 22
  Evaluación heurística.

o Un grupo de expertos aplica de manera sistemática un conjunto de criterios y principios

para evaluar el sistema.

1.4.4 DCU dentro del proceso unificado

El proceso unificado considera prototipos de interfaz en el análisis de requisitos.

 Pero no contiene modelos específicos de interfaces de usuario

Ejemplo de método completo: User Engineering de IBM.

1.4.5 Ejemplo de metodología

1.5 Diseño
1.5.1 Diseño mediante principios

 Objetivos generales que pueden ser útiles para organizar el diseño

o Sin embargo, no se especifican métodos para obtener esos objetivos, y está limitado al
uso práctico

 Ejemplo: Minimizar el trabajo del usuario

 Basados en principios de alto nivel y de aplicación muy general.
 Ejemplo: Principios de Simpson (1985):

13 de 22
 o Define los usuarios
o Deja el control a los usuarios
o Minimiza el trabajo de los usuarios
o Haz un programa sencillo
o Es necesario ser consistente
o Son necesarias las re-alimentaciones
o No cargues la memoria de trabajo
o Trata de no hacer un uso abusivo de la memoria a largo plazo

1.5.2 Diseño mediante directrices (Guidelines)

 Las directrices son objetivos más específicos que los especialistas en IPO concretan de los
principios para usuarios, entornos y tecnologías diferentes
 Ejemplos:

o Doble clic quiere decir clic + acción

o Pon botones de OK y CANCEL en cualquier caja de diálogo modal
o Utiliza verbos en la barra de título en cuadros de diálogo de funciones

 Las directrices pueden estar basadas en conocimiento experto o en estudios científicos:

o Véanse las directrices de usability.gov (PDF, 20,8 MB)

1.5.3 Estándares de diseño

Desarrollar estándares para la interfaz hace los desarrollos de software más fáciles y seguros,
estableciendo unos requisitos mínimos de fabricación, eliminando inconsistencias y variaciones
innecesarias en las interfaces

Tipos: "de iure" y "de facto"

14 de 22
 Beneficios:

 Una terminología común

o Permite a los diseñadores discutir los mismos conceptos y hacer valoraciones

comparativas.

 Facilita el mantenimiento y la evolución

o Todos los programas tiene la misma estructura y el mismo estilo.

 Una identidad común

o Lo que hace que todos los sistemas sean fáciles de reconocer.

 Reducción en la formación

o Conocimientos más fáciles de transmitir de un sistema a otro

 Salud y seguridad

o Si los sistemas han pasado controles de estándares es difícil que tengan

comportamientos inesperados.

1.5.4 Estándares “de iure”

Generados por un comité con estatus legal y gozan del apoyo de un gobierno o una
institución de estándares:

 Para hacer un estándar de iure se ha de iniciar un proceso complejo: documento preliminar,

enmiendas, aprobación…

Organizaciones con estatus legal:

 ISO: Asociación internacional de estándares

 ANSI: Instituto Nacional Americano para estándares
 IEEE: Instituto de Ingenieros Eléctricos y Electrónicos americano
 CEN: Comité Europeo para la estandarización
 JIS: Instituto Japonés para estándares
 W3C: World wide web consortium
 Etc.

ISO 9241 Ergonomic principles for visual display terminals.

ISO/IEC 10741 What happens to the cursor control when users interact with text editors.

ISO/IEC 11581 Usage and appropriateness of icons in the user interface.

ISO 13407 Designing user interfaces with humans in mind.

ISO/IEC 14754 Defines the basic gesture commands.

15 de 22
 ISO 14915 Recommendations for multimedia controls and navigation.

ISO/IEC 18019 A standard for the design and preparation of software user documentation.

1.5.5 ISO 9241

ISO 9241 Requisitos ergonómicos para el trabajo de oficina con terminales visuales

 ISO/TC 159 (Ergonomics), SC 4 (Ergonomics of human-system interactions), WG 5 (Software

ergonomics and human-computer dialogues)

Part 10: Principios de diálogo:

 Adecuación de la tarea
 Autodescripción
 Controlabilidad
 Conformidad con las expectativas del usuario
 Tolerancia al error
 Adecuación a la adaptación
 Adecuación al aprendizaje
 El estándar no contiene requisitos o recomendaciones, más bien discute cada uno de los
principios y da ejemplos de cómo se puede aplicar en las interfaces

1.5.6 ISO 11581

Símbolos y funciones de los iconos

 Este estándar internacional tiene seis partes, que se aplican a los iconos que se visualizan en
las pantallas del ordenador.

Parte 1: Iconos: conceptos generales

Parte 2: Object icons

 Contiene elementos y recomendaciones para 19 iconos de objetos usados comúnmente

Parte 3: Iconos apuntadores

 8 iconos apuntadores comunes

Parte 4: Iconos de control

Parte 5: Iconos de herramienta

 Contiene requisitos y recomendaciones para 20 iconos de herramienta comunes

Parte 6: Iconos de acciones

 Iconos de acciones o barra de herramientas. Representan acciones asociados con objetos.

23 iconos más frecuentes

16 de 22
Algunas guías de estilo comerciales

 CUA (Common User Access): Fueron publicadas en 1987 por IBM juntamente con Microsoft
fruto de una colaboración común

o Windows, OS/2 y Motif, son los estándares más importantes que siguen esta norma

 Common Desktop Environment (X-Windows), precursor de los gestores Linux

 Guías de estilo de Macintosh
 Microsoft visual identity guidelines (PDF, 7,77MB)
 Java Look & Feel Guidelines (PDF, 3.61MB)

1.6 Accesibilidad
La accesibilidad de una aplicación interactiva es el grado en que esa aplicación está
preparada para soportar diferentes dispositivos de interacción. En la web es el grado en que un sitio
web es utilizable por tantas personas como sea posible.

La mayoría de las aplicaciones que diseñamos se hacen pensando en un entorno típico, p. ej.,
imaginando a un usuario con un teclado, un ratón y un monitor.

Sin embargo, las personas con discapacidad utilizan dispositivos diferentes.

 Lectores de pantalla: "leen" al usuario invidente la interfaz, para que pueda interactuar con
ella.
 Todos podemos llegar a requerir medios alternativos en situaciones concretas, por ejemplo, al
interactuar con una aplicación mientras vamos conduciendo.

Las convenciones de diseño de Sun ("Java Look & Feel guidelines") tienen en cuenta la
accesibilidad.

Algunos de los elementos que hacen una aplicación más accesible (no lo garantizan por completo, ya
que eso sólo puede hacerse mediante estudios de usabilidad con usuarios reales)

 Proporcionar nombres y descripciones accesibles a los componentes.

 Utilizar nemónicos y atajos de teclado.
 Proporcionar una navegación por teclado apropiada, por ejemplo, mediante la tecla de "Tab".

Todos los JComponent permiten introducir en nuestros diseños elementos que facilitan la
accesibilidad.

Accesibilidad en Web, Web Accessibility Initiative (WAI).

17 de 22
Uso de HTML y lenguajes relacionados para tratar de aumentar la accesibilidad

Cada decisión que toma un equipo afecta la accesibilidad de un sitio. Al igual que el contenido, el
diseño de interacción o el rendimiento de la web, la accesibilidad es una consideración central en la
creación de sitios web. Y, a diferencia de lo que muchos equipos suponen, no se puede abordar por
separado del resto del proceso de creación del sitio web. De hecho, si trabajas en la web en
cualquier capacidad, la accesibilidad es tu trabajo.

1.6.1 Principios de la accesibilidad

1er Principio: Uso equiparable

El diseño es útil y vendible a personas con diversas capacidades.

 Que proporcione las mismas maneras de uso para todos los usuarios: idénticas cuando es
posible.
 Que evite segregar o estigmatizar a cualquier usuario.
 La privacidad, garantía y seguridad deben estar igualmente disponibles para todos
 Que el diseño sea atractivo para todos los usuarios.

2º Principio: Uso flexible

El diseño se acomoda a un amplio rango de preferencias y habilidades

 Que ofrezca posibilidades de elección en los métodos de uso.

 Que pueda accederse y usarse tanto con la mano derecha como con la izquierda.
 Que facilite al usuario la exactitud y precisión, que se adapte a su paso o ritmo

3º Principio: Simple e intuitivo

El uso del diseño es fácil de entender, atendiendo a experiencia, conocimientos, habilidades

lingüísticas o grado de concentración actual del usuario.

 Que elimine la complejidad innecesaria, que sea consistente con sus expectativas e intuición.
 Que se acomode a un amplio rango de alfabetización y habilidades lingüísticas.
 Que dispense la información de manera consistente con su importancia.

18 de 22
  Que proporcione avisos eficaces y métodos de respuesta durante y tras la finalización de la
tarea.

4º Principio: Información perceptible

El diseño comunica de manera eficaz la información necesaria para el usuario, atendiendo a las
condiciones ambientales o a las capacidades sensoriales del usuario.

 Que use diferentes modos para presentar de manera redundante la información esencial
(gráfica, verbal o táctilmente)
 Que proporcione contraste suficiente entre la información esencial y sus alrededores.
 Que amplíe la legibilidad de la información esencial.
 Que diferencie los elementos en formas que puedan ser descritas (por ejemplo, que haga fácil
dar instrucciones o direcciones).
 Que proporcione compatibilidad con varias técnicas o dispositivos usados por personas con
limitaciones sensoriales.

5º Principio: Con tolerancia al error

El diseño minimiza los riesgos y las consecuencias adversas de acciones involuntarias o

accidentales.

 Que disponga los elementos para minimizar los riesgos y errores: elementos más usados,
más accesibles; y los elementos peligrosos eliminados, aislados o tapados.
 Que proporcione advertencias sobre peligros y errores.
 Que proporcione características seguras de interrupción.
 Que desaliente acciones inconscientes en tareas que requieren vigilancia.

6º Principio: Que exija poco esfuerzo físico

El diseño puede ser usado eficaz y confortablemente y con un mínimo de fatiga.

 Que permita que el usuario mantenga una posición corporal neutra.

 Que utilice de manera razonable las fuerzas necesarias para operar.
 Que minimice las acciones repetitivas.
 Que minimice el esfuerzo físico continuado.

7º Principio: Tamaño y espacio para el acceso y uso

Que proporcione un tamaño y espacio apropiados para el acceso, alcance, manipulación y uso,
atendiendo al tamaño del cuerpo, la postura o la movilidad del usuario.

 Que proporcione una línea de visión clara hacia los elementos importantes tanto para un
usuario sentado como de pie.
 Que el alcance de cualquier componente sea confortable para cualquier usuario sentado o de
pie.
 Que se acomode a variaciones de tamaño de la mano o del agarre.
 Que proporcione el espacio necesario para el uso de ayudas técnicas o de asistencia
personal.

Más información en la página web de la Fundación SIDAR.

19 de 22
1.6.2 Evaluación y prueba

Cada vez que se prueba o evalúa un producto, se debe hacer con un plan de pruebas. Un
plan de pruebas asegura que se va a obtener algo al realizar las pruebas. También asegura que las
pruebas se ajusten al plan general del producto. Es poco probable que la realización de pruebas
excesivas sea un problema, pero lo que sí es seguro es que la realización de pruebas insuficientes
hace que no se detecten problemas.

El documento de pruebas debe contener:

 Los métodos de prueba que se utilizarán y cuándo se utilizarán en el proceso.

 Cómo los métodos de prueba apoyarán el progreso del equipo de producción hacia los
objetivos de usabilidad.
 Cómo se documentarán los resultados de las pruebas.
 Cómo se retroalimentarán los resultados de la prueba en el proceso para mejorar el producto.

1.6.2.1. Heurística y análisis

Las pruebas heurísticas son la forma más rápida de empezar y suponen pruebas en relación
a directrices existentes. A menudo estas pruebas son realizadas por las personas que ya están
trabajando en el proyecto. Se dividen en las revisiones de prototipos, revisiones de código y pruebas
automatizadas.

 Revisiones de los primeros diseños y prototipos

Estas revisiones pueden tomar la forma de evaluaciones heurísticas o paseos cognitivos.

Las evaluaciones heurísticas prueban una interfaz contra un conjunto de directrices como las
WCAG, pero también pueden tener en cuenta cualquier tema común que no esté cubierto por las
WCAG. Si se tiene una política propia de accesibilidad, es conveniente utilizarla, en caso contrario,
los criterios de las WCAG 2.0 cubren muchos de los casos de uso habituales.

 Revisiones del código

Las revisiones de los códigos pueden ser valiosas en las primeras etapas del proceso para
ayudar a identificar posibles problemas. Se deben realizar las revisiones con el código terminado,
para así poder evaluar los problemas de calidad y consistencia que podrían no ser detectados
durante las pruebas de usuario (ya que los usuarios no están expuestos directamente al código).

 Pruebas automatizadas
Aunque las pruebas automatizadas por sí solas no son suficientes, pueden asegurar que su
código se ajusta a los criterios de los estándares de un proyecto. Cuando se desea planificar las
pruebas automatizadas, hay que tener en cuenta que no todos los criterios de WCAG pueden ser
verificados automáticamente, ya que muchos criterios se centran en la experiencia del usuario.

1.6.2.2. Pruebas de dispositivos y navegadores

Las pruebas de dispositivos y navegadores implican probar su sitio en combinaciones de
diferentes dispositivos, sistemas operativos y navegadores.

20 de 22
  Elección del conjunto de pruebas
Lo ideal sería que nuestro producto funcionara con todos los dispositivos. Sin embargo,
siendo realistas, sólo se pueden hacer pruebas con un número finito de dispositivos durante la etapa
de desarrollo, por lo que es sensato tener una lista de dispositivos prioritarios y un presupuesto para
los dispositivos adicionales que sean necesarios.

 Máquinas virtuales
Las máquinas virtuales como VirtualBox y Vmware permiten probar otros navegadores y
plataformas instalando diferentes sistemas operativos. Esto puede ser muy valioso si se está
tratando de probar una configuración desactualizada, como Internet Explorer 7 en Windows XP, o
para probar un nuevo sistema operativo cuando no es posible adquirir hardware nuevo.

 Usando una matriz de pruebas

En un artículo en A List Apart1, Anne Gibson recomendó seguir una matriz de pruebas con
una lista de salidas en la parte superior y de entradas en la parte lateral. Las casillas
correspondientes se deben rellenar a medida que se hace la prueba con cada combinación de
entrada y salida. La matriz es una buena manera de asegurar que la prueba realizada es completa,
ya que tiene en cuenta muchas configuraciones diferentes.

 Haciendo un esfuerzo extra

Si durante las pruebas se encuentran problemas que se deben a la tecnología de asistencia o
a las peculiaridades del navegador, es necesario considerar la posibilidad de proporcionar una
solución al problema en vez de culpar a la tecnología.

1.6.2.3. Validadores y verificadores

Hay muchas herramientas de prueba rápida para señalar problemas que podrían perjudicar la
experiencia del usuario o hacer que el producto se muestre de forma extraña en el navegador. Estos
validadores, emuladores y verificadores pueden ser utilizados durante el proceso de diseño y
construcción para evitar inconvenientes habituales, independientemente de que se esté
programando, o se estén diseñando interfaces.

 Validadores
Los validadores permiten comprobar si el código de la página web desarrollada es válida.
Para ello se debe pegar la URL o el código, y el validador lo evaluará y presentará una lista de
resultados para ese producto. El validador suele calificar el trabajo, diciendo si es válido o si tiene
errores o advertencias.

Sin embargo, los validadores tienen un enfoque muy estricto en cuanto a la lectura de las
marcas. No entienden los matices del código, o la razón por la que se eligió usar un elemento HTML
en vez de otro, únicamente se califica como correcto o incorrecto. Por esta razón, los validadores se
suelen utilizar más como una prueba rápida que permite detectar problemas sencillos.

 W3C
El validador más conocido es probablemente la herramienta de validación de marcas del
W3C, también conocida como validador de HTML. Entre otras advertencias, informa si no existe una
etiqueta de cierre, una comilla o un atributo obligatorio, y si se ha utilizado un elemento donde no
está permitido, o un elemento o atributo que no existe realmente.

1
https://alistapart.com/article/reframing-accessibility-for-the-web/

21 de 22
  Los controles de contraste de colores
Los correctores de contraste de colores son una buena forma de asegurarse de que el
contraste del color del texto sea legible con respecto al fondo para la mayoría de los lectores, en
particular para aquellos con problemas visuales y daltonismo.

Estos correctores tienden a seguir un patrón similar: se introduce un color de primer plano y
otro de fondo y el corrector dice si son accesibles de acuerdo con las pautas de contraste de colores
del W3C. Muchas herramientas ofrecen una prueba visual de los colores, otras indican si la paleta de
colores se ajusta a los niveles AA o AAA de WCAG. Por ejemplo, la herramienta Color Oracle,
superpone toda la pantalla con un filtro de color para simular diferentes tipos de daltonismo.

 Verificadores de legibilidad
Los verificadores de legibilidad comprueban la facilidad con la que el producto se puede leer y
entender, generalmente califican el producto mediante una nota. Como estas pruebas están
automatizadas, no pueden sustituir a una persona real a la hora de juzgar si el texto se entiende
fácilmente, pero pueden dar una idea aproximada de la dificultad.

2 Bibliografía
 Libro Accessibility for Everyone: Laura Kalbag, Editorial A Book Apart, Mayo de 2017, ISBN:
9781937557621

22 de 22