Archivos por categorías: Guías Prácticas para Profesionales Web

28ene / 2009

Guías Prácticas para Profesionales Web: Puntos de verificación de las Pautas de Accesibilidad al Contenido Web (WCAG) 2.0

Hacía aproximadamente un año y medio que no se publicaba nada nuevo en las Guías Prácticas para Profesionales Web. Ya iba siendo hora y, esta vez, nos toca ponernos al día y hablar de los checklists (puntos de verificación) de las WCAG 2.0.

Notas importantes:

Principios de fundamentales de accesibilidad (resumen)

Las WCAG 2.0, recomendación oficial desde el 11 de diciembre de 2008, como comentábamos hace mucho tiempo atrás, se organizan en 4 principios fundamentales para la accesibilidad del contenido:

  1. Perceptible
  2. Operable
  3. Comprensible
  4. Robusto

En total conforman 12 pautas o directrices (guidelines); los dos primeros principios tienen cuatro pautas asociadas, el tercero tiene tres y el último una pauta. Estas pautas proporcionan los objetivos básicos para hacer el contenido accesible, y sirven para comprender los criterios de éxito e implementarlos (Olga Carreras). Se han definido 60 criterios de éxito o puntos de comprobación que definen el nivel de accesibilidad (A, AA o AAA).

Perceptible

El contenido web debe estar disponible (ser perceptible) para los sentidos – vista, audición, y/o tacto.

Pauta 1.1. Alternativas textuales. Ofrezca alternativas en forma de texto para todo el contenido no textual.

Criterios de éxito Nivel Recomendaciones
1.1.1 Contenido no textual A
  • Todas las imágenes, botones de imagen de los formularios y las zonas activas de los mapas de imagen, tendrán un texto alternativo adecuado.
  • Las imágenes que no transmitan contenidos, sean decorativas o con el contenido ya presente como texto se ofrecerán con el texto alternativo vacío (alt="") o aplicadas como fondos de imagen CSS. Todas las imágenes enlazadas contarán con un texto descriptivo alternativo.
  • El contenido equivalente alternativo para las imágenes complejas se ofrecerá en una página (enlazada o referenciada mediante longdesc) aparte.
  • Los botones de los formularios tendrán nombres (value) descriptivos.
  • Los elementos de los formularios tendrán etiquetas textuales (label) asociadas o, si éstas no pueden utilizarse, un título (title) descriptivo.
  • Los elementos multimedia incrustados (embedded) se identificarán mediante textos accesibles.
  • Los marcos (frames) tendrán un título apropiado.

Pauta 1.2. Contenido dependiente del tiempo: ofrezca alternativas para los contenidos que dependan del tiempo.

Nota: si el audio o vídeo ha sido designado como una alternativa al contenido web (por ejemplo, una versión sonora o en lengua de signos de la página web), entonces, el contenido web por sí mismo funciona como la alternativa.

Criterios de éxito Nivel Recomendaciones
1.2.1 Sólo audio y sólo vídeo pregrabado A
  • Se ofrecerá una transcripción descriptiva (incluyendo todas las pistas e indicadores visuales y auditivos) para el audio grabado (no en directo) basado en web (podcast de audio, archivos MP3, etc.)
  • Se ofrecerá una descripción auditiva o textual para los vídeos grabados (no en directo) sin audio basados en web (por ejemplo, vídeos que no incluyen pistas de audio)
1.2.2 Subtítulos (Pregrabados) A
  • Se ofrecerán subtítulos para los vídeos grabados (no en directo) basados en web (vídeos de YouTube, etc.)
1.2.3 Audio descripciones o Contenidos "media" alternativos (Pregrabados) A
  • Se ofrecerá una transcripción O audio descripción de los vídeos basados en web grabados (no en directo)
1.2.4 Subtitulado (En directo) AA
  • Se ofrecerán subtítulos sincronizados con el audio para todo el contenido multimedia ofrecido en directo (emisiones sólo audio, web cast, videoconferencias, animaciones Flash, etc.)
1.2.5 Audio descripción (Pregrabado) AA
  • Se ofrecerán audio descripciones para todo el contenido de vídeo. Nota: sólo será necesario si el vídeo transmite contenido visual que no está disponible por defecto en la pista de audio.
1.2.6 Lengua de signos (Pregrabada) AAA
  • Se ofrecerá un vídeo en lengua de signos para todo el contenido "media" que contenga audio.
1.2.7 Audio descripción extendida (Pregrabada) AAA
  • Cuando una pista de audio descripción no se pueda añadir al vídeo debido a la sincronización del audio (por ejemplo, no existen pausas en el audio), se proporcionarán una versión alternativa del vídeo con pausas que permitan las descripciones de audio.
1.2.8 Alternativas "media" (Pregrabado) AAA
  • Se ofrecerá una transcripción descriptiva para todos los medios pregrabados que contengan una pista de vídeo.
1.2.9 Sólo audio (En directo) AAA
  • Se ofrecerá una transcripción descriptiva (por ejemplo, el guión de una presentación en vivo de audio) para todos los contenidos en directo que contengan audio.

Pauta 1.3. Adaptable: crea contenido que pueda presentarse de diferentes maneras (por ejemplo, un diseño simplificado) sin perder la información o estructura.

Criterios de éxito Nivel Recomendaciones
1.3.1 Información y sus relaciones A
  • El marcado semántico se usará para designar los encabezados (<h1>), listas (<ul>, <ol>, and <dl>), texto especial o enfatizado (<strong>, <code>, <abbr>, <blockquote>, por ejemplo), etc. El marcado semántico deberá usarse apropiadamente.
  • Las tablas se usarán para marcar los datos tabulados. Las celdas de datos (<td>) se asociarán con sus encabezados (<th>) donde sea necesario. Los títulos de las tablas (caption) y sus resúmenes (summary) se usarán de forma apropiada.
  • Las etiquetas (label) textuales se asociarán con sus campos (input) correspondientes en los formularios. Los elementos de los formularios que estén relacionados se agruparán mediante fieldset/legend.
1.3.2 Secuencia con significado A
  • El orden de navegación y lectura (determinado por el orden en el código fuente) será lógico e intuitivo.
1.3.3
Características sensoriales		 A
  • Las instrucciones no dependerán de la forma, tamaño o ubicación visual (por ejemplo, "Haga clic en el icono cuadrado para continuar" o "Las instrucciones están en la columna de la derecha").
  • Las instrucciones no dependerán del sonido (por ejemplo, "Un sonido beep le indica que puede continuar").

Pauta 1.4. Distinguible: facilite a los usuarios el ver y escuchar el contenido, incluyendo la separación entre el primer plano y el fondo.

Criterios de éxito Nivel Recomendaciones
1.4.1 Uso del color A
  • No use el color como el único método para transmitir el contenido o distinguir elementos visuales.
  • Los enlaces deben distinguirse de los elementos y texto que les rodean. Si utiliza el color para diferenciar los enlaces, use una forma adicional para distinguirlos. (por ejemplo, se subrayan cuando reciben el foco).
1.4.2 Control del audio A
  • Se debe ofrecer un mecanismo para poder parar, pausar, silenciar o ajustar el volumen de cualquier sonido que se reproduzca automáticamente en la página más de tres segundos.
1.4.3 Contraste (mínimo) AA
  • El texto o las imágenes de texto deben tener una relación de contraste de al menos 4.5:1, excepto en los siguientes casos:
    • En los textos grandes (de más de 18 puntos o 14 puntos en negrita) y las imágenes de texto grandes la relación de contraste debe ser de al menos 3:1.
    • En los textos, o las imágenes de texto, que forman parte de un componente de la interfaz de usuario inactivo, que son meramente decorativos, que no son visibles o que forman parte de una imagen cuyo significado es visual, no tienen un requisito mínimo de contraste.
    • Los textos que forman parte de un logotipo o de una marca comercial no tiene un requisito mínimo de contraste.
  • Nota del traductor: puede usar algunas herramientas para comprobar el contraste, por ejemplo, Color Contrast Checker o Luminosity Colour Contrast Ratio Analyser.
1.4.4 Tamaño del texto AA
  • La página deberá ser legible y funcional cuando se doble el tamaño del texto.
  • La interpretación del diseñador web Roger Johansson a este punto es que hasta que la amplia mayoría de los usuarios utilicen navegadores que soporten zoom (y el soporte del zoom de los navegadores mejore), deberíamos comprobar que el texto de nuestras páginas puede ser ampliado hasta un 200%.
1.4.5 Imágenes de texto AA
  • Si la misma representación visual puede realizarse usando sólo texto, no deben usarse imágenes para representar ese texto.
1.4.6 Contraste (aumentado) AAA
  • El texto o las imágenes de texto deben tener una relación de contraste de al menos 7:1.
  • Los textos grandes (de más de 18 puntos o 14 puntos en negrita) deben tener una relación de contraste de al menos 4.5:1.
  • Nota del traductor: utilice las herramientas de comprobación del contraste existentes para verificar esos valores, por ejemplo, Color Contrast Checker.
1.4.7 Bajo o sin sonido de fondo AAA
  • Compruebe que no hay o existe un ruido de fondo muy bajo que permita distinguir fácilmente las conversaciones.
1.4.8 Presentación visual AAA
  • Para bloques de texto de más de una frase de longitud:
    • No habrá más de 80 caracteres de ancho
    • No estarán justificados a ambos lados (alineados los márgenes izquierdo y derecho)
    • Tendrán un interlineado (de al menos la mitad de la altura del texto) y espacio entre párrafos (1.5 veces la medida del interlineado) adecuado.
    • Tendrán especificados un color de primer plano y fondo. Estos se pueden aplicar a elementos específicos de la página o en su totalidad utilizando CSS (y, por tanto, heredados por el resto de elementos).
    • No aparecerá desplazamiento horizontal cuando se doble el tamaño del texto.
1.4.9 Imágenes de texto (sin excepción) AAA
  • Sólo se usarán imágenes de texto para decorar cuando no transmitan información o cuando la información no pueda presentarse de ninguna otra manera (por ejemplo, cuando el texto forme parte del logotipo de una empresa).

Operable

Los formularios, controles, navegación y otros elementos de la interfaz deben permitir la interacción.

Pauta 2.1. Accesibilidad mediante el teclado: permita que toda la funcionalidad esté disponible usando el teclado

Criterios de éxito Nivel Recomendaciones
2.1.1 Teclado A
  • Todas funciones de las páginas deberán estar disponibles utilizando el teclado, excepto aquellas que de forma conocida no pueden realizarse con el teclado (por ejemplo, un dibujo a mano alzada).
  • Los atajos de teclado y accesskeys (que normalmente deberían evitarse) no deben entrar en conflicto con las presentes en el navegador y/o lector de pantalla.
2.1.2 Teclado no bloqueado A
  • El foco del teclado no deberá estar bloqueado o fijado en un elemento concreto de la página. El usuario deberá poder moverse por todos los elementos navegables de la página utilizando únicamente el teclado.
2.1.3 Teclado (Sin excepción) AAA
  • Toda la funcionalidad de las páginas deberán estar disponibles utilizando el teclado.

Pauta 2.2 Suficiente tiempo: ofrezca a los usuarios el tiempo suficiente para que puedan leer y utilizar el contenido

Criterios de éxito Nivel Recomendaciones
2.2.1 Tiempo ajustable A
  • Si una página o aplicación tiene un límite de tiempo para realizar una tarea deberá ofrecer la opción de apagar, ajustar o aumentar ese límite de tiempo. No es un requisito para eventos en tiempo real (por ejemplo, una subasta) donde el límite de tiempo es absolutamente necesario, o si el plazo de tiempo es de más de 20 horas.
2.2.2 Pausar, parar, ocultar A
  • Todo movimiento automático, parpadeo o desplazamiento de más de tres segundos deberá poderse pausar, parar u ocultar por el usuario. El movimiento, parpadeo, o desplazamiento podrá usarse para llamar la atención del usuario o destacar un contenido si dura menos de tres segundos.
  • El contenido actualizado automáticamente (por ejemplo, una página recargada o redireccionada automáticamente, un ticker de noticias, la actualización de un campo mediante AJAX, un aviso, etc.) deberá poder ser pausado, parado u ocultado por el usuario o el usuario deberá poder controlar manualmente los tiempos de actualización.
2.2.3 Sin tiempo AAA
  • El contenido y funcionalidad no tendrá limitaciones de tiempo.
2.2.4 Interrupciones AAA
  • Las interrupciones (alertas, actualizaciones de las páginas, etc.) deberán poder ser pospuestas o canceladas por el usuario.
2.2.5 Re-autentificación AAA
  • Si la autentificación en una sesión termina (expira), el usuario podrá re-autentificarse y continuar con su actividad sin perder ningún dato de la página actual.

Pauta 2.3. Convulsiones: no diseñe los contenidos de tal forma que puedan provocar ataques o convulsiones

Criterios de éxito Nivel Recomendaciones
2.3.1 Tres destellos (flashes) o debajo del umbral A
  • No deberá crear contenidos que destellen más de tres veces por segundo a menos que el parpadeo sea lo suficientemente pequeño, los destellos sean de bajo contraste y no contengan demasiado rojo. (Véase el apartado sobre el destello en general y el umbral de destello del rojo, en inglés)
2.3.2 Tres destellos AAA
  • No deberá crear contenidos que destellen más de tres veces por segundo.

Pauta 2.4 Navegable: ofrezca métodos que ayuden al usuario a navegar, encontrar el contenido y determinar dónde se encuentra

Criterios de éxito Nivel Recomendaciones
2.4.1 Accesos directos A
  • Se ofrecerá un enlace para saltar la navegación y otros elementos que se repitan en todas las páginas.
  • Si una página cuenta con una estructura adecuada de encabezados, puede considerarse una técnica suficiente en lugar de un enlace del tipo "Ir al contenido principal". Tenga en cuenta que la navegación por encabezados todavía no está soportada en todos los navegadores.
  • Si una página utiliza un conjunto de marcos (frameset) y los marcos (frame) están apropiadamente titulados, puede considerarse una técnica suficiente para acceder directamente a cada marco individual.
2.4.2 Título de la página A
  • La página web deberá tener un título descriptivo e informativo de la misma.
2.4.3 Orden del foco A
  • El orden de la navegación por los enlaces, elementos de los formularios, etc. deberá ser lógico e intuitivo.
2.4.4 Propósito de los enlaces (en su contexto) A
  • Siempre que no sean ambiguos para los usuarios en general, los enlaces (o botones de imagen en un formulario, o zonas activas en un mapa de imagen) serán lo suficientemente descriptivos como para identificar su propósito (objetivo) directamente desde el texto enlazado o, en su caso, desde el enlace en su contexto (por ejemplo, en los párrafos que lo rodean, elementos de una lista, celdas o encabezados en una tabla, etc.).
  • Los enlaces (o botones de imagen en un formulario) con el mismo destino deberían tener las mismas descripciones (ser consistentes, según criterio de éxito 3.2.4), pero los enlaces con diferentes propósitos y destinos deberían tener diferentes descripciones.
2.4.5 Múltiples vías AA
  • Se deben ofrecer múltiples formas para encontrar otras páginas web en el sitio – al menos dos de las siguientes: una lista de páginas relacionadas, tabla de contenidos, mapa web, búsqueda en el sitio, o un listado de todas las páginas web.
2.4.6 Encabezados y etiquetas AA
  • Los encabezados (<h>) de las páginas y las etiquetas (<label>) para los controles interactivos de los formularios deberán ser informativos. Evite el duplicar los encabezados (por ejemplo, "Más detalles") y las etiquetas de texto (por ejemplo, "primer nombre") a menos que la estructura ofrezca una diferenciación adecuada entre ellas.
2.4.7 Visibilidad del foco AA
  • Compruebe que es visualmente evidente el elemento que tiene el foco actual del teclado (por ejemplo, si se mueve con el tabulador por la página, puede ver dónde se encuentra).
2.4.8 Ubicación AAA
  • Si la página web forma parte de una secuencia de páginas o está dentro de un sitio con una estructura compleja, deberá indicar la ubicación de la página actual, por ejemplo, a través de las migas de pan (breadcrumbs) o especificando el paso actual en la secuencia (por ejemplo, "Paso 2 de 5 – dirección de envío").
2.4.9 Propósito de los enlaces (enlaces sin contexto) AAA
  • Siempre que no sean ambiguos para los usuarios en general, los enlaces (o botones de imagen en un formulario, o zonas activas en un mapa de imagen) serán lo suficientemente descriptivos como para identificar su propósito (objetivo) directamente desde el texto enlazado.
  • No deberán existir enlaces (o botones de imagen en un formulario) con el mismo texto que vinculen a lugares diferentes (por ejemplo, "Lea más").
2.4.10 Encabezados de sección AAA
  • Además de proporcionar un documento con la estructura global del sitio, cada una de las secciones de contenido deberán ser designadas mediante encabezados (títulos), donde sea oportuno.

Comprensible

El contenido y la interfaz deben poder entenderse fácilmente y ser semánticamente ricos.

Pauta 3.1 Legibilidad: cree contenidos legibles y fáciles de entender

Criterios de éxito Nivel Recomendaciones
3.1.1 Idioma de la página A
  • El idioma principal de la página deberá estar identificado utilizando el atributo lang de HTML (por ejemplo, <HTML lang="es">).
3.1.2 Idioma de las partes AA
  • Si algunas secciones tienen contenidos en un idioma diferente al principal, éste deberá estar identificado utilizando el atributo lang (por ejemplo, <blockquote lang="en">) cuando sea apropiado.
  • Existen algunas excepciones: nombres propios, términos técnicos, palabras o frases en un lenguaje indeterminado o inventado, locuciones propias de la lengua (vernaculares) que se entienden dentro del contexto (por ejemplo, locuciones latinas en español).
3.1.3 Palabras inusuales AAA
  • Las palabras que puedan ser ambiguas, desconocidas o usadas de una forma muy específica, deberán definirse través de un texto adyacente, una lista de definiciones, un glosario, o de cualquier otro método.
3.1.4 Abreviaturas AAA
  • La explicación para las abreviaturas se realizará, usando el elemento <abbr> o enlazando a un glosario de términos, la primera vez que se utilicen en el contenido. Nota: WCAG 2.0 no hace excepciones con las abreviaciones conocidas en un determinado ámbito (por ejemplo, la abreviatura HTML utilizada en un sitio de desarrollo web deberá también ser explicado).
3.1.5 Nivel de lectura AAA
  • Una alternativa para hacer los contenidos más comprensibles es suponer que aquellos que sean más avanzados puedan ser razonablemente leídos por una persona con aproximadamente 9 años de educación primaria.
3.1.6 Pronunciación AAA
  • Si la pronunciación de una palabra es vital para comprenderla, su pronunciación se mostrará seguida de dicha palabra o mediante un enlace a un glosario.

Pauta 3.2. Predecible: cree páginas web que se muestren y funcionen de forma previsible

Criterios de éxito Nivel Recomendaciones
3.2.1 Foco A
  • Cuando un elemento reciba el foco no se deberá iniciar un cambio en la página que confunda o desoriente al usuario.
3.2.2 Cambios imprevistos A
  • Deberá advertir al usuario con antelación de los cambios, imprevistos o automáticos, en la configuración de cualquier elemento de la interfaz que causen una modificación en la página.
3.2.3 navegación consistente AA
  • Los enlaces de navegación que se repiten en las páginas web no deberían modificar su orden al navegar por el sitio.
3.2.4 Identificación consistente AA
  • Los elementos que tienen la misma funcionalidad a través de múltiples páginas web deberán identificarse de manera consistente. Por ejemplo, un campo de búsqueda en la parte superior de la página deberá etiquetarse siempre de la misma forma.
3.2.5 Solicitud de cambio AAA
  • Los cambios sustanciales de las páginas, la aparición de ventanas emergentes (pop-ups), los cambios no controlados del foco del teclado, o cualquier otro cambio que podría confundir o desorientar al usuario deberán ser iniciados por éste. Alternativamente, siempre se le deberá ofrecer al usuario una opción para desactivar dichos cambios.

Pauta 3.3. Asistencia en la introducción de datos: ayude a los usuarios a evitar y corregir los errores

Criterios de éxito Nivel Recomendaciones
3.3.1 Identificación de errores A
  • Ofrezca información al usuario sobre los campos obligatorios de un formulario, o aquellos que necesitan un formato, valor o longitud específica, utilizando el elemento <label> (si éste no está disponible ponga la información en el atributo de título title del elemento).
  • Si se usa la validación de datos de los formularios (del lado del cliente o del servidor), ofrezca la información sobre los errores y avisos de forma eficiente, intuitiva y accesible. Los errores deben estar claramente identificados, ofrecer un acceso rápido al elemento problemático, permitir que el usuario pueda fácilmente solucionar el error y reenviar los datos del formulario.
3.3.2 Etiquetas o instrucciones A
  • Se deberán proporcionar las suficientes etiquetas, avisos e instrucciones necesarios para los elementos interactivos. Use para ello instrucciones, ejemplos, posicionane adecuadamente las etiquetas (label) y agrupe e identifique los campos con fieldsets/legends
3.3.3 Sugerencias de error AA
  • Si se detecta un error al introducir un dato (mediante la validación en el lado del cliente o en el del servidor), deberá proporcionar sugerencias para solucionar el problema de forma oportuna y accesible.
3.3.4 Prevención de errores (Legales, financieros, de datos) AA
  • Si el usuario puede modificar o eliminar datos de carácter legal, financiero o de prueba, estas acciones deberán ser reversibles, verificadas o comprobadas.
3.3.5 Ayuda AAA
  • Si el usuario puede enviar, cambiar o eliminar información, la información deberá poder volver a estar disponible, y/o las acciones realizadas ser verificadas o confirmadas.
3.3.6 Prevención de errores (todos) AAA
  • Si el usuario puede enviar información, el envío deberá poder ser reversible, verificado o confirmado.

Robusto

El contenido debe ser lo suficientemente consistente y fiable como para permitir su uso con una amplia variedad de agentes de usuario, ayudas técnicas… y preparado para las tecnologías venideras.

Pauta 4.1. Compatible: mejore la compatibilidad con los agentes de usuario actuales y futuros, incluidas las ayudas técnicas.

Criterios de éxito Nivel Recomendaciones
4.1.1 Análisis A
  • Se deberán evitar los errores de sintaxis de HTML/XHTML. El código puede comprobarse, analizarse y validarse a través de http://validator.w3.org/
4.1.2 Nombre, función, valor A
  • Deberá utilizar el marcado de tal forma que se facilite la accesibilidad. Esto incluye el seguir las especificaciones oficiales de HTML/XHTML, utilizando la gramática formal de forma apropiada.

Publicado el Accesibilidad, Curiosidades, Guías Prácticas para Profesionales Web

Tags: , , , , , ,

Permalink 34 comentarios

28jun / 2006

Guías Prácticas para Profesionales Web: Buenas Prácticas en Web Móvil

Hacía tiempo que no se publicaba una nueva edición de las Guías Prácticas para Profesionales Web, en esta ocasión, hablamos sobre las Buenas Prácticas en Web Móvil 1.0

Los dispositivos móviles poseen una serie de características que suelen dificultar su uso:

  • Suelen tener pantallas pequeñas, con lo que se muestra poca información a la vez.
  • Actualmente, las conexiones son malas (lentas; con poco ancho de banda y alta latencia), inestables y caras.
  • Las interfaces de usuario son heterogéneas y dependen de cada dispositivo.
  • Son necesarias estrategias de diseño diferentes a los ordenadores comunes. Normalmente la interacción es costosa; los botones y teclas son pequeños, existe dificultad para escribir (gran control de la psicomotricidad fina), para poder leer…

Ya Jakob Nielsen, estando en Fundamentos Web 2005, dijo:

"Los servicios móviles que no sean muy fáciles de usar fracasarán"

Buenas Prácticas en Web Móvil 1.0

Para poner un poco de orden y criterio, el W3C ha lanzado Mobile Web Best Practices 1.0 o algo así como las "Buenas Prácticas para el Desarrollo Web en Dispositivos Móviles". Con este documento el W3C quiere ofrecer un conjunto de pautas que ayuden a los desarrolladores Web a proporcionar una mejor experiencia a los usuarios de dispositivos móviles.

Para los que se hayan peleado alguna vez con las Pautas de Accesibilidad al Contenido Web 1.0 (WCAG 1.0), muchos de los principios les serán bastante familiares. A continuación pongo una traducción libre al español del Summary of Statements – Mobile Web Best Practices 1.0 (versión candidata de 2006). El siguiente listado está también libremente reorganizado por mí:

Navegabilidad

  • URI. Intente que la URI de entrada al sitio sea tan corta como pueda.
  • Barra de navegación. Ofrezca en la cabecera de la página sólo la navegación mínima necesaria.
  • Recursos externos. Intente que los enlaces a recursos externos sean los mínimos posibles.
  • Navegación. Ofrezca mecanismos de navegación consistentes.
  • Equilibrio de enlaces. Valore el tener muchos vínculos en una página y que el usuario tenga que seguir muchos enlaces hasta encontrar lo que busca.
  • Teclas de acceso. Proporcione atajos de teclado (accesskeys) a los enlaces de navegación y a las funciones más usadas.
  • Enlaces. Identifique de forma clara el destino de cada enlace. No cambie el formato de los enlaces a menos que sepa que el dispositivo es compatible con la modificación.
  • Mapas de imagen. No utilice mapas de imagen a menos que sepa que el dispositivo los soporta. En cualquier caso, piense en vías alternativas para poder mostrar la información.
  • Ventanas emergentes (Pop-Up). No utilice ventanas emergentes. No cambie la ventana actual sin informar al usuario.

Control del usuario

  • Recarga automática. No haga que las páginas se recarguen automáticamente cada cierto tiempo, a menos que se informe al usuario de ello y se ofrezca una forma para poder detener dicha acción.
  • Redireccionamiento. No utilice código que redireccione automáticamente las páginas. En lugar de eso, configure el servidor para que encargue de redireccionarlas.
  • Pulsaciones de teclas. Intente que las teclas que tenga que pulsar el usuario sean las mínimas necesarias.

Contenido

  • Adecuación. Compruebe que el contenido es apropiado para su uso en un contexto móvil.
  • Claridad. Use un lenguaje claro y simple.
  • Limitación. Limite el contenido al que el usuario solicita.
  • Títulos de las páginas. Cree títulos de páginas cortos pero descriptivos.
  • Consistencia. Cerciórese de que el contenido es consistente cuando se accede desde diferentes dispositivos.
  • Jerarquía semántica. Verifique que el contenido más importante de la página aparece antes que el contenido secundario.

Imágenes

  • Imágenes. No use imágenes para lograr el posicionamiento de elementos, crear espacios, etc.
  • Tamaño de imágenes. No utilice imágenes que no puedan mostrarse en el dispositivo. Evite imágenes grandes o detalles de alta resolución. Defina el tamaño de las imágenes en el marcado si poseen una medida específica.
  • Imágenes de fondo. Cuando utilice imágenes de fondo, verifique que el contenido sigue siendo legible.
  • Escalado de imágenes. Si se deben escalar las imágenes a una medida específica, redimensiónelas desde el servidor.

Color

  • Uso del color. Compruebe que la información transmitida por medio del color sigue estando disponible sin él.
  • Contraste del color. Compruebe que los colores de primer plano y del fondo contrastan lo suficiente.

Diseño

  • Página limitada. Divida la página en partes cuyos tamaños sean fáciles de utilizar en el dispositivo.
  • Peso limitado. Asegúrese de que el peso total de las páginas es el adecuado para las limitaciones de memoria del dispositivo.
  • Desplazamiento. Limite el desplazamiento de la página a una dirección, a menos que el desplazamiento secundario pueda evitarse.
  • Medidas. No use medidas definidas en píxeles. No utilice medidas absolutas en los valores de los atributos del marcado ni en los valores de las hojas de estilos.
  • Fuentes. No confíe en la compatibilidad de las fuentes tipográficas que se declaran en los estilos.
  • Capacidades. Aproveche las capacidades del dispositivo para ofrecer una experiencia de uso óptima.
  • Pruebas. Haga pruebas tanto con dispositivos reales como con emuladores.

Tecnologías y marcado

  • Marcado válido. Cree documentos que sean válidos con los estándares y tecnologías del W3C.
  • Minimice. Use un marcado conciso y eficaz.
  • Marcos. No use conjuntos de marcos.
  • Estructura. Use las características del lenguaje de marcado para indicar la estructura lógica del documento. Haga uso de un marcado semántico.
  • Tablas
    • No utilice tablas a menos que sepa que el dispositivo es compatible con ellas.
    • No utilice tablas anidadas.
    • No use las tablas para la maquetación
    • Cuando sea posible, ofrezca alternativas a la presentación de datos tabulados.
  • Scripts, objetos, applets y plug-ins: no use elementos incrustados en las páginas a menos que sepa que van a funcionar en el dispositivo. En cualquier caso, ofrezca alternativas para los usuarios que no puedan verlos.
  • Alternativas no textuales. Ofrezca alternativas textuales para cada elemento no textual.
  • Compatibilidad con la codificación de caracteres. Verifique que el contenido está codificado con un juego de caracteres que va a ser soportado por el dispositivo.
  • Codificación de caracteres. Indique el juego de caracteres que está utilizando.
  • Mensajes de error. Ofrezca mensajes de error informativos y significativos, con los mecanismos de navegación necesarios para salir del error y volver a la información útil.
  • Cookies. No confíe en que las cookies estén siempre disponibles.
  • Caché. Intente guardar en memoria la información de las respuestas HTTP.
  • Formato del contenido. Cuándo sea posible, envíe el contenido en un formato preferido y que sepa que va a ser compatible con el dispositivo.
  • Incompatibilidades. Sea prudente a la hora de trabajar con implementaciones deficientes.

Hojas de estilos

  • Use hojas de estilos para controlar la presentación, a menos que el dispositivo no sea compatible con ellas.
  • Organice los documentos de tal forma que sean legibles sin hojas de estilos.
  • Intente que las hojas de estilo sean pequeñas (en peso).

Formularios

  • Valores por defecto. Ofrezca valores preseleccionados por defecto y evite la introducción libre de texto cuando sea posible.
  • Modo de entrada. Si el dispositivo es compatible, especifique una forma por defecto de insertar texto, idioma y/o método de introducción.
  • Orden de tabulación. Cree un orden lógico entre los enlaces, controles de los formularios y objetos.
  • Etiquetado de controles. Etiquete adecuadamente todos los controles de los formularios y asocie explícitamente cada etiqueta a su control.
  • Posición de los controles. Coloque las etiquetas de tal forma que se muestren correctamente y en correspondencia con los controles de formulario a los que se refieren.

Comprobación automática

Los del W3C están en todo y estas "buenas prácticas" se pueden comprobar automáticamente con la herramienta (aún en desarrollo) W3C Mobile Web Best Practices checker

¿Más información?

Actualización del 5 de marzo de 2007: ahora puedes comprobar qué tal se leen tus páginas en ciertos dispositivos móviles.

Actualización del 15 de julio de 2008: la oficina española del W3C ha resumido las Buenas Prácticas en Web Móvil en formato tarjeta.

Actualización del 3 de marzo de 2009: el Observatorio de Internet Móvil ha publicado Líneas Maestras de Diseño para la Web Móvil, una traducción libre del Design Guide de la comunidad Volantis.

Publicado el Estándares Web, Guías Prácticas para Profesionales Web

Tags: , , , ,

Permalink 4 comentarios

06feb / 2006

Guías Prácticas para Profesionales Web: Pruebas de usuarios en la Web

Esta vez abandonamos la presentación habitual de las Guías Prácticas para Profesionales Web y las integramos en este formato por dos razones: unificar la información y aprovechar las ventajas tecnológicas que ofrece el blog (búsquedas, comentarios, sindicación…). En esta ocasión haremos una introducción a las Pruebas de usuarios en la Web, espero que lo disfruten.

Introducción

No existen dogmas inamovibles en el campo del diseño Web. Dos desarrolladores que se enfrentan a un mismo problema pueden encontrar soluciones diferentes. De igual forma, dos consultores Web pueden tener opiniones distintas ante una misma cuestión. Entonces, ¿quién puede ofrecernos datos fiables de que nuestras páginas están funcionando correctamente? La respuesta es clara: los usuarios de nuestro sitio.

La mejor forma de conocer las opiniones de los usuarios de nuestras páginas es hablando directamente con ellos y realizando pruebas de usuarios (user testing).

¿Qué es una prueba de usuarios?

También llamado test de usuarios, es una medida empírica de la usabilidad de una herramienta, sitio Web o aplicación, tomada a partir de la observación sistemática de usuarios que realizan unas determinadas tareas. Estas pruebas nos permiten:

  • Comprobar la existencia de problemas de usabilidad.
  • Buscar posibles soluciones para los problemas que se detecten.
  • Obtener una medida concreta inicial de la usabilidad que nos permitirá comparar los resultados ante competidores, una modificación o rediseño, futuros desarrollos, etc.

La usabilidad

Por si a alguien no le suena a estas alturas la palabra usabilidad, me gustó la definición que hizo Javier Cañada: "la usabilidad es la cualidad de los objetos o sistemas interactivos que pueden ser usados con comodidad y satisfacción". También pueden ver una definición más completa de Juan Carlos García.

¿Cuándo hacer las pruebas?

La situación ideal es que, previamente a las pruebas de usuarios, nuestras páginas hayan pasado una evaluación heurística por expertos. Un profesional experimentado de la usabilidad puede detectar de forma rápida y eficaz muchos problemas de usabilidad de un sitio Web, sin tener que recurrir a una prueba de usuarios y evitando sus costes, pudiendo eliminar los errores graves y dejando a los usuarios a que nos ayuden a resolver problemas de usabilidad más sutiles, errores imprevistos, depurar el diseño, etc.

Las pruebas con usuarios pueden ser de gran utilidad en varias fases: durante las primeras etapas del desarrollo de un nuevo sitio, antes de un proceso de rediseño o como revisión periódica de un sitio ya publicado. Realmente sólo hay que tener en cuenta que cuando se hagan las pruebas debemos escuchar lo que los usuarios nos van a decir y ser consecuentes con sus opiniones. Si lo que queremos es simplemente oír lo maravillosas que son nuestras páginas es mejor que no malgastemos nuestro dinero y el tiempo de nuestros usuarios.

Planificación

Todo lo que necesitamos para comenzar a realizar las pruebas de usuarios es, obviamente, un usuario, un ordenador donde probar el sitio Web, papel y lápiz para tomar las anotaciones necesarias y a un consultor que se encargue de tutelar la experiencia.

Algunos consultores de usabilidad utilizan, además, otros recursos tecnológicos como videocámaras, cuartos de observación separados por cristales espejados por una cara (como los utilizados en las salas de reconocimiento policial), etc. Estos recursos no son estrictamente necesarios. Sólo hay que tener en cuenta que debemos prestar más atención a la conducta y opiniones de los usuarios que a si la cámara está o no funcionando.

¿Dónde realizar las pruebas?

Básicamente tenemos dos opciones, en nuestras oficinas o en el lugar habitual de nuestros usuarios. En el primer caso es más cómodo para nosotros y nos permite planificar mejor las pruebas, en el segundo, obtenemos una información adicional que hace más precisa y enriquecedora la experiencia: el entorno del usuario, es decir, el ordenador y monitor que realmente usa, si el ambiente es relajado o ruidoso…

¿Cuántos usuarios deben participar?

La mejor forma de realizar las pruebas es de uno en uno: un usuario con un consultor. No es necesario contar con muchos usuarios para que las pruebas sean efectivas. Al respecto, estudios realizados por Jakob Nielsen establecen que la mayoría (entre el 65 – 85%) de los problemas de usabilidad pueden detectarse con tan sólo 5 usuarios. En cualquier caso siempre podemos realizar una segunda prueba con más usuarios. Quince parece ser una cifra suficiente para detectar casi la totalidad de los posibles problemas de usabilidad.

Elegir al consultor

El consultor, también denominado como evaluador, entrevistador, moderador o facilitador en algunos manuales, es la persona que hará las pruebas con los usuarios, los observará, registrará los resultados y presentará un informe con las conclusiones finales. Lo lógico es contar con un consultor profesional para estos menesteres; sin embargo, en determinadas ocasiones, los consultores pueden ser una solución demasiado cara. Si no se tiene dinero para contratar a un consultor en usabilidad, nosotros mismos podemos intentarlo, siempre que se cumplan una serie de requisitos y cualidades.

Cualidades de un consultor

La más importante es que tiene que ser capaz de ser objetivo e imparcial, además de utilizar buenos métodos, tareas bien diseñadas, medidas significativas, etc.. Ninguna implicación con el desarrollo del sitio debe afectar a la neutralidad de las pruebas, es lo que Richard Saul Wurman, consultor y arquitecto de la información (creador, entre otras cosas, del término "arquitectura de la información") define como "la enfermedad de la familiaridad".

El test es básicamente observación y, si esta es honesta, puede hacerlo tanto el creador del sitio, como un consultor ajeno al proceso. Normalmente, las compañías de desarrollo Web contratan a un consultor de usabilidad, o equipo de usabilidad, externo para estas tareas. En este caso lo importante es que los profesionales que se contraten se impliquen con todo el equipo de desarrollo para evitar pérdidas en el traspaso de la información y para que, juntos, aprendan a crear una mejor experiencia de uso de su producto.

Otra cualidad a considerar es la experiencia y conocimientos. El consultor debe tener la experiencia y conocimientos necesarios para realizar las pruebas de forma sencilla y efectiva. Las pruebas con usuarios no forman parte de una ciencia exacta, pero esto no quiere decir que no se deba conocer y elaborar cuidadosamente la metodología, estrategias y la planificación. Hacer una prueba con usuarios tiene cierta complejidad y requiere el dominio de ciertos conocimientos teóricos y metodológicos que eviten conclusiones erróneas.

Por último, el consultor debe ser una persona tranquila, abierta, cordial, que inspire confianza y empatía hacia el usuario.

Los usuarios

Llega una de las partes clave: encontrar a los usuarios que van a participar en las pruebas. El primer paso a seguir consiste en conocer a la audiencia a la que se dirigen nuestras páginas. Normalmente, el público objetivo es definido en las primeras fases de la planificación del sitio Web. Una vez tenemos claro el abanico de usuarios, es el momento de buscar a los participantes.

¿Dónde encontrarlos?

Los participantes potenciales de las pruebas pueden encontrarse a través de listas de consumidores, organizaciones o asociaciones relacionadas con la temática de nuestro sitio, listas de discusión en la Red, en determinados eventos o conferencias, etc. Algunas empresas especializadas en el estudio de la usabilidad cuentan con diferentes grupos de usuarios (panelistas) que se pueden ajustar a nuestras necesidades, lo que nos puede ahorrar bastante tiempo, no dinero, en la búsqueda.

Condiciones

Los participantes han de ser completamente honestos y sinceros en las pruebas. Es aconsejable que tengan cierta experiencia y se desenvuelvan con soltura en el uso del Web.

¿Pagar o no a los participantes?

No es, ni mucho menos, obligatorio, pero, dado el caso, este hecho podría ayudar a acelerar el proceso de selección de los participantes, si tenemos que establecer una cuantía, parece ser que entre 20 a 50 euros por persona son cifras que funcionan muy bien para captar la atención del público objetivo. El incentivo no tiene por qué ser necesariamente económico, también puede servir, por ejemplo, ciertas ventajas o descuentos en los servicios que se pretenden evaluar, en empresas asociadas, etc.

Debemos dejar claro a los participantes que se les compensa por su tiempo y su honestidad y no para que digan sólo cosas favorables de las páginas que evalúan.

Las preguntas

Durante una prueba de usuario, el objetivo principal debe ser la observación pasiva, pero antes de comenzar con la prueba propiamente dicha debemos conocer algunos aspectos básicos sobre nuestros participantes. Para ello no necesitamos realizar un cuestionario exhaustivo con toda la información sobre sus gustos y hábitos, unas pocas cuestiones servirán, por ejemplo: nombre del usuario y nivel de experiencia en la Web.

En este punto, es importante dejar claro qué es lo que se espera del participante y cuáles son las "reglas del juego". Se debe intentar explicar que estamos interesados en descubrir qué opinan sobre el sitio Web que vamos a analizar, tanto lo bueno como lo malo. La prueba no es un concurso, así que no hay respuestas erróneas. Deben decir en voz alta todo lo que piensen, vean o experimenten con el sitio mientras lo están usando.

Para obtener medidas fiables, debemos pedir a los usuarios que completen diferentes tareas que simulen su comportamiento real, por ejemplo, buscar una determinada información, comprar un determinado producto, comparar información, etc.

Una vez finalizada la prueba (unos 30 minutos suele ser suficiente) podríamos preguntarles sobre aspectos más generales, como la opinión general del sitio, la valoración sobre la empresa (imagen de marca)…

Analizar los resultados

Después de realizar las pruebas, se deberán poner en orden las observaciones tomadas. Lo mejor es hacerlo cuanto antes; cuanto más se tarde en pasar a limpio nuestras apreciaciones más probable será que olvidemos detalles no escritos sobre las pruebas o que se malinterpreten ciertas anotaciones.

¿Qué se busca en los resultados?

Recordemos que las pruebas de usuarios no son una ciencia exacta. Las mejores pistas se encontrarán en los patrones de conducta, es decir, en aquellas observaciones y comentarios que se han repetido en los diferentes usuarios. Así pues, no deberemos dar la misma importancia a un comentario aislado sobre nuestro sistema de navegación que a si la mayoría de usuarios han tenido dificultades en ese aspecto, lo que indicaría claramente que nuestra navegación está mal planteada.

Será de gran utilidad registar nuestros resultados en alguna base de datos, esto nos permitirá ordenarlos y filtrarlos por determinados factores de manera más cómoda, ágil y eficiente.

Para finalizar se preparará un informe que resuma las áreas problemáticas de nuestro sitio. Los descubrimientos deberán ser expuestos y discutidos con todo el equipo implicado en el desarrollo del sitio Web para buscar las soluciones pertinentes.

Algo más

Coincidiendo con las fechas en la que preparaba este artículo, Nelson Rodríguez, realizó unas anotaciones sobre la evaluación de la usabilidad en las que definía el laboratorio portátil y una simplificación del mismo, sin duda, unos buenos complementos a esta lectura.

Actualización del 9 de febrero de 2006: se han incluido una serie de comentarios realizados por Humberto Matas. Gracias Humberto.

Actualización del 7 de julio de 2008: Preparing for User Research Interviews: Seven Things to Remember.

Actualización del 28 de julio de 2008: Silverback, una gran aplicación de la gente de Clearleft; simple, barata y efectiva, desarrollada para hacer test de usabilidad de guerrilla sin complicaciones en Mac.

Actualización del 9 de octubre de 2008: Consejos para presentar los resultados de un test de usabilidad, por Iván Marnet (DeInterfaz).

Publicado el Experiencia de usuario, Guías Prácticas para Profesionales Web

Tags: , , , , , ,

Permalink Un comentario