Usabilidad web: Problemas con el editor Gutenberg

Introducción

Una de las partes más importantes de WordPress, aparte de todas las personas que trabajamos en ello, es el editor, ya que es donde escribes tus contenidos y puedes aportar y ayudar ofreciendo todo el conocimiento que tienes, con la idea de hacer un WordPress mejor para todos.

Pero desde que está la posibilidad de utilizar este editor, veo que aún le queda mucho por mejorar y, que usarlo así de primeras, el cambio impresiona bastante. Pero bueno, aún así intentaré mostrar los principales problemas que nos podemos encontrar.

Principalmente, si pensamos en personas con dificultades físicas y/o con dificultades visuales que usen el editor, el esquema mental que tenido en su mente durante tanto tiempo, en un segundo se desbarata. Con lo cual tiene que volver a empezar y adaptarse a un cambio tan brusco cuesta, como a todos, pero a ellos más aún, y claro, teniendo tantas cosas para mejorar, la frustración es aún mayor.

Problemas de usabilidad con Gutenberg

La primera impresión al usar Gutenberg hace ya unos cuantos meses, y reconozco lo que he usado poco, era que al existir la posibilidad de mover bloques, cualquier persona que use el teclado y le dé por error se puede llegar a confundir, sobre todo si es una persona con visión nula. Y para una persona con problemas físicos, lo que ocurre es que se aumenta la carga motora innecesariamente, al tener que volver a colocar el bloque en el lugar que le corresponde. Bueno, en este caso, no tanto.

Pero cuando tienes que modificar estilos, sí. Porque tienes que pasar los estilos en cada uno de los bloques para seguir, a menos que uses las flechas de dirección o usar los comandos de teclado asignados para ello. Que a fin de cuentas es lo que se hace con el editor actual, y no nos encontramos con el problema de que al usar el TAB hay que pasar por los bloques y cada una de las opciones que tiene, lo cual es bastante cansado.

Me falla la barra de herramientas fija en la parte superior

Sí, así, tal y como lo lees. ¿Por qué? Porque si nos fijamos bien en las diferentes opciones del bloque, en la primera de ellas que es “Cambiar tipo de bloque”. Según lo que quieras poner ya sea una lista, un encabezado o una cita, la mejor solución es usar el comando correspondiente, porque es un pérdida de tiempo usar la tecla TAB si el usuario se equivoca al elegir qué quiere.

Yo pregunto: ¿Es necesario pasar con el teclado todas las opciones que se ven al desplegar esa opción? NO. Esto puede ser muy cansado para el usuario. Es cierto que beneficia a las personas que usan el ratón y es bastante rápido, pero nos olvidamos de los usuarios que no pueden usar un ratón y el problema principal es que se aumenta la carga motora sin necesidad. No sólo con eso, sino con todo. Porque se tiene que usar constantemente para estar editando y modificando las cosas. Y, también, todo esto puede marear a un usuario ciego.

Pero investigando por estos lares, me he dado cuenta de que existe la opción de “Fijar la barra de herramientas”. En el menú de puntos de la esquina superior derecha, en Ajustes. 
Opción Fijar barra de herramientas

Inserción de imágenes

He creado esta imagen para hacer ver uno de los problemas principales de usabilidad, al menos para mí y para muchos usuarios.

Problema de usabilidad de Gutenberg

Y aquí me encuentro con otro problema: que una vez que insertas una imagen, le das a Intro, y te obliga a poner otra y no hay forma de salir de ahí, hasta que no pasas varias veces con el TAB. Te vuelves loca. ¿Y si yo quiero poner un párrafo o un encabezado inmediatamente después? Con lo cual esto es un problema grave de usabilidad. Te interrumpe cada vez que quieres hacer algo.

En las imágenes es importante añadir el texto alternativo para que las personas ciegas puedan hacerse una idea de cual es la información de la imagen. Una leyenda es añadir algo más de información cuando se trata de una información adicional de la propia imagen, como explicar un gráfico o una imagen compleja, por ejemplo.

Atajos de teclado

Cuando se va a buscar el menú de los atajos de teclado y quieres desplazarte hacia abajo para seguir viendo el resto de comandos, no se puede, es dependiente de ratón.

Y tampoco se sabe cuáles son los atajos para poner los encabezados, algo muy importante para llevar a cabo el orden necesario en cuanto a accesibilidad web, y por lo tanto para ayudar a las personas ciegas a navegar y a entender el contenido.

Inserción de Enlaces

A la hora de insertar un enlace también da problemas. Cuando insertamos un enlace, se inserta bien, pero no te deja abrirlo en una ventana nueva. Una vez lo pones, no puedes comprobar que funciona porque no te deja. Para comprobar que funciona nos tenemos que ir a la opción “Ver entrada” y ya sale, cuando debería dejar hacerlo desde el propio enlace.

Inserción de  vídeos y Opción Incrustados

Hay un problema de usabilidad bastante grande con la inserción de vídeos. Directamente, es que no se puede. Esto, desde un primer momento crea bastante confusión a los usuarios, porque por ejemplo, al insertar un vídeo usando la opción de Vídeo se espera eso, poder insertar un vídeo sin problemas.

En la pestaña Incrustados, que aparece en el menú de bloques de la esquina superior izquierda, en cuanto a los vídeos, me parece un error poner todo lo que corresponde a las redes sociales, vídeos, así como las diferentes plataformas de música y fotos. Hay que intentar ser coherentes con lo que estamos haciendo. Si ya tenemos la opción de Vídeo, que en un primer momento sirve para eso, no podemos confundir al usuario con la palabra Incrustados.

Es más, como sugerencia, diría que hasta podría clasificar las opciones en función de su finalidad: Fotos, audio, vídeos y Redes Sociales. Sería mucho más cómodo a la hora de hacer las búsquedas de lo que se necesite en el momento.

Además de esto, es muy posible que algunas de las opciones no sean accesibles y seguramente tendrán que mejorar muchísimo en cuestión de accesibilidad. Con lo cual, ese menú puede suponer una pérdida de tiempo para los usuarios.

Menú de bloques

En cuanto al menú de bloques, que está dividido en diferentes pestañas que su vez despliegan un menú con diferentes opciones, me quedaba con: Más utilizados, Bloques comunes, Formatos y Elementos de diseño. Incluso, me plantearía redistribuir los Elementos y eliminaría alguno que otro porque lo único que hace es entorpecer y complicar las cosas. De los Formatos en las tablas no se puede tabular y es dependiente de ratón, con lo cual es un problema grave de usabilidad.

Los Widgets están siempre y cuando se pueda añadir una barra lateral y al no poderse hacer, o al menos yo no lo he descubierto, no tiene mucho sentido.

Y la opción de Reutilizable no entiendo para qué sirve. No le encuentro ningún sentido.

Conclusiones

Para mi gusto y por facilidad a la hora de trabajar con Gutenberg, es mucho más cómodo trabajar como lo he explicado anteriormente, con la barra de herramientas fija en la parte de arriba.

Y yo pregunto: ¿Por qué no se añade directamente la barra de herramientas fija a la parte superior? Una funcionalidad tan importante como esta no debe pasar desapercibida para nadie y mucho menos estar escondida en un menú. Se debería incluir esta opción siempre y así no frustra tanto a los usuarios.

Por cierto, lo último que he visto ha sido dentro del menú de cada uno de los bloques, las opciones “Insertar antes” e “Insertar después”, lo cual está bastante bien y mejora algo las cosas cuando estamos editando.

Y para finalizar, comento lo que toda la comunidad de WordPress lleva diciendo desde hace ya algunos meses:

Gutenber no está preparado para implementarse, necesita mejorar mucho en accesibilidad y en usabilidad para que se asiente como editor de textos en WordPress.

Usabilidad web: “Pensar primero” – Daniel Mordecki

En esta entrada os voy a hablar del libro “Pensar primero” de Daniel Mordecki.

pensar primero

No es un libro que le vaya a enseñar nada nuevo a un profesional de la usabilidad, pero sí que debería ser leído por todas las personas involucradas en el desarrollo de software como una excelente y amena introducción al Diseño de Interacción.

Resumo a continuación el contenido del libro, que como digo gira en torno al Diseño de Interacción. Quizás algún programador se sienta ofendido, por ello comentaré primero que el autor afirma que:

Los programadores son gente inteligente, desarrollan una tarea extremadamente exigente, que les requiere muchas veces jornadas muy largas de trabajo bajo la presión de cronogramas y fechas límites. No se empecinan en mantener interfaces pobres porque sí, sino porque en el acierto o en el error están absolutamente convencidos que son las más adecuadas. Las pruebas de usabilidad son uno de los pocos caminos para revertir estas opiniones cuando están equivocadas y probablemente sean la de mejor relación costo/beneficio.

El autor, lo que realmente defiende, es que el programador debe poder dedicar el 100% de su tiempo a programar, que no deben recaer sobre él tareas que habitualmente realiza y para las cuales no está formado.

Los objetivos de la programación y del diseño de interacción van por caminos separados, por lo que no es viable que quién esté programando sea capaz de diseñar (no hablamos de diseño gráfico). No sólo se trata de tareas disjuntas en el tiempo, dado que el diseño antecede a la programación, sino que las metodologías, objetivos y requisitos son completamente distintos.

Describe situaciones habituales en las que los programadores suelen poner el foco en la tarea misma, seguros de que cuántas más tareas sea capaz de realizar una aplicación más feliz va a ser el usuario, incapaces de entender a los que están al otro lado de la pantalla. Achacan los problemas de una aplicación a que los usuarios no leen los manuales, a que los usuarios deberían formarse más, ser más cuidadosos o prestar más atención.

El objetivo del libro es mostrar que los problemas no residen en los usuarios sino en el propio software.

El diseño de la interacción está focalizado en las necesidades de los seres humanos, la programación está centrada en las necesidades de las computadoras. Unas y otras son bien distintas. Mientras que los humanos somos imprecisos, nos equivocamos, somos ambiguos y cambiamos de opinión y gusto, las computadoras son exactas, precisas, inequívocas, lógicas y repetitivas.

El diseñador de la interacción se preocupará de que el software hable el lenguaje de quien lo va a usar y no el lenguaje de la computadora.

El autor hace hincapié en que demasiado a menudo se empieza a programar antes de diseñar la aplicación, insistiendo en que el Diseño de la Interacción debe realizarse obligatoriamente antes de programar: “diseñar primero, programar después”, es la máxima del libro.

Si pensáramos en sentido inverso y aplicáramos los usos y costumbres informáticos a la ingeniería civil, entonces después de una reunión de dos o tres horas, donde le indican al gerente de proyecto que se va a construir un edificio con 30 apartamentos de dos dormitorios, cocina, living comedor y otras facilidades, de 75m2 cada uno, con 15 cocheras y de categoría media, éste se dirige al terreno y sentencia: “muchachos, vayan haciendo un pozo acá de más o menos 5 metros como la vez pasada, creo que con eso va a alcanzar, así adelantamos mientras yo hago los planos. Si después hay alguna diferencia vemos”.

Diseñar antes de programar es menos costoso, genera software de mejor calidad y usuarios más satisfechos, todo lo cual se traduce en una relación costo/beneficio excelente comparada con las metodologías que no lo hacen así:

    • diseñar reduce la cantidad de cambios a realizar sobre la marcha
    • los programadores podrán concentrarse exclusivamente en su tarea: programar
    • el software tendrá menos parches, con un modelo de datos más refinado, con menos opciones ocultas, desarrollado por programadores focalizados 100% en la tarea, sin duda será más compacto y eficiente, y por lo tanto tendrá menores requerimientos de equipamiento

El código es como el hormigón: una vez que está escrito, la estructura endurece y los cambios se volverán inviables […] Los cambios se plasmarán en parches al código que, a pesar de que desarrollan la función solicitada por el cliente, aumentarán la probabilidad de introducir errores y dificultarán enormemente en el futuro el mantenimiento de la aplicación […]

El proceso de Diseño de la Interacción aplicado antes de la programación genera pues usuarios más satisfechos, entendiendo que la satisfacción de un cliente no es el resultado abstracto de un producto “bueno”, sino la relación entre su percepción del producto que recibe y las expectativas que tenía antes de recibirlo.

Cinco son objetivos del Diseño de la Interacción:

    • Definir el producto final: sin esta definición es imposible saber cuándo está el producto acabado.
    • Acotar y minimizar los costos: el costo no se dispara porque fue mal estimado, sino porque se estimó el costo de una solución muy distinta a la que se terminará implementado.
    • Poner el foco en el usuario.
    • Sacar la presión que el diseño implica para el equipo de programación.
    • Hacer creíbles y “cumplibles” los cronogramas.

Las tres herramientas del Diseño de Interacción son:

    • Los personajes
    • Los objetivos
    • Los escenarios

Personajes

Daniel menciona las típicas reuniones que todos hemos vivido en que gerente, programador, diseñador, etc. defiende con vehemencia que el usuario preferirá tal o cual solución. En realidad todos ven a un usuario completamente distinto… extremadamente parecido a sí mismo, a un amigo o a un conocido, y discute encarnizadamente para imponer su visión de lo que es mejor.

La solución son los personajes, que tendrán nombre propio, y dicho nombre sustituirá al término “usuario” que hay que desterrar. Los personajes son personas ficticias (nunca reales) pero con una descripción lo suficientemente detallada para que pueda contestar a las preguntas de qué necesita el usuario, para lo cual deberán ser representativos de las personas que usan el programa.

Tendremos tantos personajes como roles distintos. Además de los personajes principales podrá haber personajes secundarios, que no son destinatarios finales pero también tienen su relevancia.

Hay que tener en cuenta que cuantos menos personajes mejor, puesto que cada personaje agrega una enorme cantidad de complejidad adicional: si tiene más de 5 o 6 personajes, entre principales y secundarios, lo más probable es que esté haciendo las cosas mal.

Objetivos

Realizamos tareas, anhelamos objetivos. Es necesario reposicionar el foco y pasar del software que hace cosas al software que ayuda a quien lo usa a conseguir objetivos.

Diseñar es encontrar dentro del espectro de objetivos de nuestros personajes el nivel justo de detalle que los comprenda y describa de forma útil para el desarrollo de la aplicación. […] Los objetivos de los usuarios potenciales deben jugar el rol de equilibrar y amalgamar las funcionalidades del software en un todo único.

Escenarios

La función de los escenarios es vincular los objetivos de los usuarios con las acciones concretas que desarrollan al utilizar la aplicación. Cada uno de los objetivos debe ser analizado minuciosamente para encontrar la lista completa de las tareas que hay que realizar para alcanzarlo.

Cada tarea debe ser puntuada del 1 al 5 en tres atributos para más adelante ordenarlas y ubicarlas:

    • Nivel de importancia: cuán importante es la tarea para alcanzar el objetivo.
    • Nivel de dificultad de implementación: en combinación con el nivel de importancia, el nivel de dificultad nos va ayudar a ponderar el esfuerzo de diseño y programación que hay que poner en una tarea determinada.
    • Frecuencia: la frecuencia con que repetimos una tarea tiene una importancia vital para el diseño.

Existen distintos tipos de escenarios:

    • Los de uso diario: son la quintaesencia del diseño de aplicaciones porque es allí donde los usuarios serán infinitamente felices o rabiosamente desdichados.
    • Los de uso periódico: son aquellos que responden a algún objetivo de algún personaje, pero no son utilizados a diario sino de forma esporádica.
    • Los de uso necesario: no existen para satisfacer necesidades de los usuarios, sino necesidades de la aplicación, como por ejemplo las pantallas de configuración, que deberían ser eliminadas. Programe para averiguar la información que necesita en vez de preguntarla.
    • Situaciones límite: desde el punto de vista de la programación son vitales, desde el punto de vista del usuario no, siempre y cuando este conserve el trabajo realizado hasta el momento.

Daniel parte de que se debe proponer una metodología práctica que permita enfrentarnos a problemas concretos, con presupuestos concretos y otras restricciones también concretas. Por eso propone dedicar, desde el punto de vista del Diseño de Interacción: el 75% del esfuerzo para los escenarios de uso diario, el 20% para los de uso periódico, 5% para los de uso necesario y nada para los de caso límite.

Si está diseñando un sitio Web, dibuje un recuadro para cada página que tendrá que diseñar, verifique que están todas, y pinte con un color distinto cada página según pertenezca a un escenario de uso diario, periódico, necesario o de caso límite. Verificará con sorpresa que va a dedicar el 70% del tiempo en el diseño del 10% de las páginas.

Una vez completado el proceso de definición de los personajes, descriptos sus objetivos, desglosados estos objetivos en tareas que se agrupan en escenarios, estamos en condiciones de especificar cómo se presentará el sitio ante los ojos de los usuarios.

Especificar la interfaz es dar el paso siguiente y determinar unívocamente, sin ambigüedad alguna, cómo será cada uno de los elementos de la interacción del sitio.

Para ello se propone dos técnicas: o desarrollar un esqueleto estático o un StoryBoard.

En ambos casos deben estar comentados al detalle, puesto que los programadores están acostumbrados a ir añadiendo/modificando/improvisando elementos del interfaz a medida que lo programan, adaptando la interacción a la implementación, y el resultado acaba alejándose del diseño original.

El esqueleto estático es una colección de páginas Web vinculadas entre sí que simulan el funcionamiento que tendrá el sitio una vez que esté terminado, definiendo a la vez, de forma unívoca, la interacción del sitio con sus visitantes. No es un prototipo, puesto que los prototipos no son completos y el esqueleto sí: tiene el 100% de las páginas. Además los prototipos no contemplan todos los detalles pero el Diseño de Interacción debe necesariamente contemplarlos todos.

Siempre es mejor contar con el diseñador gráfico (aunque siempre hay quien decide que si no llama al diseñador tendrá un contendiente menos para discutir) al especificar la interacción, tendríamos así la maqueta completa, que le pasaríamos a los programadores.

El StoryBoard consiste en crear las pantallas del sitio en imágenes, es más rápido de crear y modificar o de hacer distintas versiones, pero también resulta menos preciso, más lineal y es más difícil representar la interacción.

Daniel pasa entonces de la disciplina del Diseño de Interacción al de la Usabilidad:

El diseño de la interacción es la herramienta para construir un sitio o una aplicación desde cero. La usabilidad testeará lo que el diseño construyó primero. Y las distintas soluciones a los problemas son producto del diseño, la usabilidad encuentra los problemas pero no los resuelve, esta es tarea del diseño de la interacción.

El desafío de la Usabilidad es entender cómo ven el software quienes lo utilizan, qué piensan cuando lo usan, qué pistas le otorgan a los usuarios las respuestas que el software les da, entender por qué toman sus decisiones cuando se deciden por una u otra opción. La Usabilidad tiene como objetivo analizar el nivel de coincidencia que el modelo de representación de una aplicación o sitio Web expresa a través de su interfaz, con el modelo mental del usuario que está sentado frente a ella.

Para ello es necesario realizar test de usuarios. Daniel, de forma muy pragmática, indica que siempre es mejor un test improvisado, con cualquier compañero no involucrado en el proyecto, que no realizar ningún test. Aunque afirma que cualquier cosa no puede ser considerada una prueba de usabilidad decente, cree que una prueba mínima, con cualquiera que encontremos en el pasillo, posiblemente nos mostrará errores obvios que tuvimos delante de nuestras narices 18 meses sin verlos.

La usabilidad produce dos entregables:

    • Un análisis de la aplicación que encuentra las debilidades que alejan a los usuarios de sus objetivos cuando interactúan con ella.
    • Una sistematización de lo aprendido en las pruebas de usabilidad para encontrar patrones de problemas, guías de usabilidad basadas en el análisis empírico de las distintas situaciones.

Los test de usabilidad no prueban una tesis a partir de una hipótesis como en un teorema, sino que constituyen un insumo vital, que sumado a la experiencia, conocimientos y sentido común del diseñador, le permitirán perfeccionar el comportamiento interactivo de una aplicación.

Por último, me hace gracia cómo consuela a los diseñadores con una gran verdad:

Cuanto mejor es el diseño, menos se nota, y por lo tanto menos elogios recibirá. El buen diseño de la interacción produce aplicaciones y sitios Web sencillos, directos, de comprensión inmediata: no recibirá ningún elogio por ellos, salvo de algún experto que conozca lo difícil que es alcanzar un resultado de calidad. Eso sí, no intente explicar que el éxito se debe al excelente diseño, todos le contestarán al unísono: “¿esas paginitas con dos o tres gif son un ‘excelente diseño’?”.

Como dice Daniel, eso es posiblemente lo que le pasó al diseñador de Google.

Usabilidad web: Taxonomías y Navegación en WordPress

Introducción

El diseño de la navegación de un sitio, esencial para el éxito del mismo, comprende numerosos componentes, pero los podemos agrupar en dos conjuntos: la navegación estructural y la navegación semántica.

La navegación estructural sirve para representar los contenidos principales del sitio y facilitar su recorrido, mientras que la semántica permite establecer las interrelaciones basadas en la similitud entre las diferentes entradas del sitio.

Estructura del sitio web
Navegación estructural (vertical) y navegación semántica (horizontal)

La cuestión es que, para todos estos tipos de navegación, las taxonomías son de una importancia vital, no solo para mejorar la navegación y la experiencia de usuario, sino para optimizar el SEO y otros aspectos igualmente importantes en los sitios intensivos en contenidos, y muy especialmente, en los sitios web de medios de comunicación (cibermedios).

Las taxonomías en WordPress

En términos generales, una taxonomía es una clasificación. Suelen estar basadas en relaciones jerárquicas de clase y subclase.

El origen del término procede de las clasificaciones propias de la biología, donde un taxón es una de las clases en las que se subdividen los seres vivos.

Las taxonomías como formas de unión de entradas similares

En el caso concreto de WordPress, una taxonomía es una forma de unir las entradas que comparten alguna característica mediante el uso de términos. Dicho de otro modo, en WordPress una taxonomía es una lista de términos en la que cada uno de ellos está asociado a un conjunto de entradas.

Un ejemplo sencillo:

  • Término 1 > Entrada 1, Entrada 3, Entrada 4
  • Término 2 > Entrada 3, Entrada 4, Entrada 5
  • Término 3 > Entrada 2, Entrada 3, Entrada 5

 

El ejemplo anterior muestra esta idea con una taxonomía de tres términos en un sitio con cinco entradas. Vemos que el Término 1 (p.e. Accesibilidad web) une las entradas 1, 3 y 4; mientras que el Término 2 (p.e. Usabilidad) une la 3, 4 y 5, etc.

Pero estos términos hay que engobarlos en taxonomías. Las dos taxonomías que encontramos en una instalación estándar de WordPress son las siguientes:

  • Categorías
  • Etiquetas

Las taxonomías en WordPress pueden (o no) ser jerárquicas y esto todo lo más que se puede decir de su complejidad. Pero, hay que señalar que aquello que las hace valiosas, no es su complejidad, sino los múltiples usos que el sistema permite darle.

Las taxonomías como páginas web

Además, para WordPress, cada categoría y cada etiqueta es una página web. Esto significa, literalmente, que si tenemos 10 categorías del estilo: Accesibilidad web, Usabilidad, Diversidad Funcional, etc., y el sitio tiene el dominio, por ejemplo, accesibilidadyusabilidad.com, entonces tenemos 10 páginas como éstas que WordPress ha creado automáticamente:

  • accesibilidadyusabilidad.com/accesibilidadweb/
  • accesibilidadyusabilidad.com/usabilidad/
  • etc

Exactamente lo mismo nos sucede con las etiquetas. Por esa razón, cuando editamos una categoría o una etiqueta, estamos editando a la vez la página que contendrá todas las entradas o noticias categorizadas con esa categoría o etiqueta.

Por último, es importante señalar que WordPress incluye la posibilidad de desarrollar taxonomías personalizadas. En lo que sigue consideraremos únicamente el uso de las taxonomías tal como las provee WordPress en una instalación estándar.

Categorías

Las categorías pueden tener subcategorías, de modo que éstas permiten una organización (razonablemente) jerárquica de los temas de un sitio intensivo en contenidos.

En cambio, es importante notar que una subcategoría no puede formar parte de más de una categoría superior. Las polijerarquías, por tanto, no están permitidas.

La cuestión es que las categorías pueden utilizarse, si seguimos en el caso de un medio de comunicación, para representar las principales secciones temáticas del mismo (en un magazine de Cine y Televisión como Fotogramas, por ejemplo, serían Cartelera, Estrenos, Críticas, etc.)

Las categorías no deberían multiplicarse de forma descontrolada. Un número entre 5 y 10 de tales categorías y, si se considera necesario, un número de entre 2 y 5 subcategorías para cada una, podría formar una estructura bastante manejable y al mismo tiempo suficiente para acoger hasta 50 ítems temáticos distintos, cantidad más que suficiente.

A partir de aquí, el uso lógico de la taxonomía nos indica que cada entrada o cada noticia debe quedar asignada al menos a una categoría e, idealmente, solo a una categoría. Esto permitiría una estructura muy clara y enormemente fácil de manejar.

Pero otras consideraciones, en particular, tanto el SEO (queremos que la entrada sea muy visible) como la Experiencia de Usuario (queremos multiplicar los puntos de acceso), nos empujan en cambio en la dirección contraria: asignar tantas como sea posible.

Pero esto, a su vez, nos llevaría a una taxonomía que se volvería inútil a la larga, porque casi todas las entradas estaría asignada a casi todas las categorías. Así que la taxonomía no serviría para crear conjuntos (razonablemente) disjuntos, sino que, por el contrario, habría un solapamiento total.

Por lo tanto, el equilibrio entre la lógica intrínseca de las taxonomías y las exigencias del SEO nos lleva a proponer la norma de uso de este modo para el caso de un cibermedio que tuviera, por ejemplo, un total de 10 categorías principales:

Cada entrada o cada noticia debe quedar asignada al menos a una categoría y, en casos justificados, a una o dos categorías adicionales.

Esta asignación de categorías a las entradas o las noticias en WordPress constituye el primer paso obligado para lo que hemos llamado la polifuncionalidad de las taxonomías.

De hecho, es gracias a este primer paso que se puede considerar que las taxonomías son, en realidad, el corazón de un sitio bien diseñado con WordPress.

Etiquetas

Las etiquetas no son jerárquicas. Por tanto, no pueden tener subetiquetas. En cambio, pueden usarse mucho más liberalmente, ya que corresponden a la idea de las palabras clave con las que representar de modo sintético los temas de cada entrada o noticia individual.

La norma de uso de las etiquetas, interpretadas como palabras clave que describen de forma sintética todos y cada uno de los temas y entidades (personas, lugares, empresas, etc.) mencionados en una noticia se puede expresar así:

Cada entrada o cada noticia puede quedar representada por un mínimo de 2 y un máximo de 20 etiquetas

Las cifras anteriores marcan extremos. En el caso de las noticias, cualquier número más cerca de la franja entre las 4 y las 8 etiquetas, seguramente será una pauta más reconocible.

Cabe destacar que en el caso de las etiquetas los nombres propios (entidades), ya sea de personas, lugares, empresas, organismos, etc. se pueden considerar ejemplos válidos de etiquetas.

Como es fácil que el número de etiquetas (a diferencia de las categorías) se multiplique, es conveniente llevar algún tipo de control terminológico. En todo caso, conviene revisar regularmente el apartado de las etiquetas.De lo contrario, acabaremos usando diversas palabras para etiquetar los mismos conceptos, con lo que cual perderemos las ventajas de usar una taxonomía.

 El rol polifuncional de las taxonomías

Hemos hecho referencia anteriormente al hecho de que las taxonomías son en realidad el corazón de un sitio intensivo en contenidos bien diseñado.

Una de las mejores funciones, tanto de las categorías como de las etiquetas en el caso de WordPress (suponemos que otros CMS también permiten usos similares) es la de generar páginas bajos las cuales se reúnen las noticias asignadas a las mismas categorías (o etiquetas) y en las cuales, el nombre de la categoría forma parte de la URL.

Es decir, óbservese el múltiple papel de las taxonomías:

  • Caracterizar las entradas individuales, a modo de palabras clave destacadas para señalar de forma sintética sus contenidos principales.
  • Agrupar las mismas entradas o noticias bajo una misma etiqueta o categoría, lo que corresponde a una página que contiene un listado de las entradas asignadas a cada categoría.
  • Fundamentar la navegación semántica, ya que las etiquetas y categorías en una entrada son enlaces a la página que contiene la lista de todas las entradas asociadas a la misma.
  • Fundamentar el diseño de la navegación estructural, puesto que pueden aparecer en cualquier de los diferentes tipos de menús (principal, secundario, complementario, etc.) de esta clase de navegación.

 

Una vez más, la relativa sencillez de las taxonomías de WordPress no debe confundirnos. En un medio de comunicación o en general en un sitio intensivo en contenidos lo más lógico sería aplicar alguna clase de control terminológico, tanto de categorías como de etiquetas, pero sobre todo de estas últimas, a fin de usar siempre los mismos términos para representar los mismos conceptos.

Este control puede consistir en mantener una lista de los términos utilizados como etiquetas. En esta lista se debería poder distinguir entre términos sinónimos y términos preferentes; siendo éstos últimos los que se debería utilizar (en lugar de los demás sinónimos que deben quedar descartados).

En resumen:

  • Las categorías deberían reflejar las secciones principales (esto es la clase de contenidos principales) del sitio, y con más motivo si es un medio de comunicación. Deben ser pocas, por este mismo motivo, y mantenerse alrededor de la decena (siguiendo la norma del 7 más menos 2). Cada categoría puede tener subcategorías, en cuyo caso tampoco deberían ser muy numerosas (entre 2 y 5 por decir algo).
  • Las etiquetas deben reflejar el contenido concreto de cada entrada, por tanto, no hay un número óptimo máximo. Un sitio de comunicación puede necesitar centenares de etiquetas distintas. Por este motivo, necesitan a la vez mayor supervisión (control terminológico) para evitar que los mismos conceptos se representen con etiquetas distintas.

En este punto, es el momento de pasar a considerar la navegación estructural y sus diversos componentes.

Navegación estructural

Esta navegación tiene una triple misión: por un lado debe representar lo mejor posible la variedad de temas y subtemas que contiene un sitio web. En segundo lugar, es la navegación responsable de dar la máxima coherencia a todo el sitio.

Finalmente, debe asegurar un desplazamiento fácil por toda su estructura. Los tipos de menús componentes de la navegación estructural son, al menos (que nosotros sepamos, no hay una lista cerrada) los siguientes:

  • Principal
  • Secundario(s)
  • Al pie
  • Complementario(s)

Menú principal

El menú principal forma la parte principal de la llamada navegación constante, porque es la parte de la navegación que no cambia (con unas pocas excepciones) a lo largo de todo el sitio.

De manera óptima contiene un número limitado de componentes, siendo habitual referirse a este número con la expresión “7 más menos 2”, lo que implica que el menú principal puede tener entre 5 y 9 componentes.

En la mayor parte de los sitios, el menú principal estará ubicado en la parte superior de la página web. También en la parte superior si estamos pensando en el escritorio, o disponible para ser desplegado en el famoso “hamburguer menu”, si pensamos en la web móvil.

En el caso de un CMS como WordPress, aunque se pueden utilizar páginas en el mismo, la mejor opción consiste en utilizar las categorías de la taxonomía para construir este menú. En concreto, consiste en utilizar, típicamente, alrededor de 10 Categorías, que en un cibermedio se supone que deben coincidir con las principales secciones temáticas del mismo.

Eventualmente. en el menú principal podemos añadir una o dos páginas corporativas, por ejemplo, la página de contacto o la página de créditos, aunque estas últimas, en muchos cibermedios, se suelen incorporar en el menú al pie.

Menús secundarios

El término de menú secundario es polivalente e incluye, al menos estas posibilidades:

  • Menú local, es decir una parte de la navegación que es exclusiva de cada sección, por lo tanto,solamente se despliega en la sección determinada. Por ejemplo, una vez en la sección de Cultura de un medio de comunicación, se despliegan las opciones Cine, Literatura, Arte, etc.
  • Subelementos de un elemento principal de menú, situación generalmente identificada como una flecha o una convención similar. Para seguir con el mismo ejemplo, haciendo clic en el elemento Cultura del menú principal se desplegarían las opciones Cine, Literatura, Arte, etc.
  • Una línea secundaria de menú, como parte del menú constante (principal + secundario). La función aquí es añadir más opciones siempre disponibles, pero sin cargar el menú principal.

Las subcategorías pueden formar parte de cualquier nivel de menú: pueden estar en el menú principal o en cualquiera de las opciones que hemos señalado del menú secundario, así como en las que veremos despues en los menús complementarios.

Por último, en el caso de WordPress la idea de menús secundario puede corresponder al menú dedicado a las redes sociales. En algunos temas de WordPress entonces este menú queda visualmente asociado a cualquiera de los otros: el principal o el que situamos al pie, etc.

Menú al pie

Suele dedicarse a replicar toda o parte de la navegación principal, pero sobre todo suele utilizarse para añadir enlaces para acceder a información corporativa y legal.

Los temas de WordPress pueden permitir muchas opciones en este aspecto: añadir cualquir clase de enlaces relacionados, plugins, como el de búsqueda, acceso a las redes sociales del medio, un buscador, etc.

Menús complementarios

Solamente la imaginación (atemperada por un sentido elemental de la prudencia) limita las posibilidades de los menús complementarios. La razón es que los pluguins y los widgets que acompañan a los temas de WordPress proporcionan bastantes opciones donde elegir.

La idea esencial es que, proponer a los usuarios diversas formas de hacer lo mismo, o en el caso, de los sitios web, diversas formas de llegar al mismo contenido, siempre ha sido un consejo en el ámbito de la Usabilidad. Es por tanto, una buena práctica en el diseño de la navegación web.

Trasladar lo anterior al caso de un medio de comunicación (aka cibermedio) significa que podemos añadir formas de navegación como las siguientes:

  • Menús laterales (o al pie) basados en:
    • Categorías
    • Etiquetas
    • Páginas
    • Noticias más populares (más vistas)
    • Nubes de etiquetas
    • Últimas publicaciones
  • Archivo u orden cronológico basado en calendario
  • Sumarios en el interior de las entradas
  • Paginación al pie de entradas extensas
  • Ir a las entradas anteriores y posteriores a la que está en pantalla, etc.

Usabilidad web: Qué son las taxonomías y cómo aplicarlas

¿Qué es una taxonomía? Definición

Una taxonomía es una estructura de organización de la información que está formada por un conjunto de categorías y subcategorías, gracias a las cuales podemos unir cosas que comparten alguna característica común.

Por ejemplo, CineTelevisión comparten la característica de ser productos audiovisuales, por lo cual son subcategorías de la categoría Comunicación Audiovisual.

taxonomías

La primera idea de las taxonomías es que están formadas por términos. La segunda idea intrínseca de las taxonomías es que todos los términos están relacionados o conectados entre sí.

Todos los términos forman parte de un término superior o son el término superior del que dependen otros términos subordinados. A su vez, los términos de nivel superior forman parte de un término de máximo nivel.

Las taxonomías se pueden utilizar para una enorme variedad de fines, desde la organización de los libros en una biblioteca, hasta la organización de los contenidos de un sitio web. Así que, podemos decir que la función principal de una taxonomía es organizar las cosas que vamos a buscar en el sitio web e intentar reducir las interacciones necesarias.

¿Forman parte de alguna clase más amplia de sistemas?

Las taxonomías forman parte de los sistemas de organización del conocimiento.

Hay al menos cuatro de ellos y están ordenados de menor a mayor complejidad.

  • listas de términos
  • taxonomías
  • tesauros
  • ontologías

 

¿En qué dimensiones de un sitio web impacta una taxonomía?

  • En la experiencia de usuario, al favorecer estructuras de navegación claras, lógicas y consistentes, así como al multiplicar las opciones de acceso a la información y las señales de orientación. Efecto “no me hagas pensar” (Krug)
  • En el SEO, al facilitar las estructuras, al sortear las palabras clave, favorecer el tiempo de permanencia de los usuarios al facilitar la navegación semántica y de paso reducir el tiempo de rebote.

 

¿Cuáles son sus principales componentes?

Los componentes principales de una taxonomía son los términos con los que forman las categorías y subcategorías.

¿Qué estructura tiene una taxonomía?

La estructura propia de una taxonomía es la jerarquía. Esta jerarquía está formada por categorías y subcategorías, con las categorías del mismo nivel en una relación de “hermanos” y las categorías y subcategorías en un relación “padre-hijo” entre ellas.

relaciones de las taxonomías

¿Cómo se eligen los términos?

En el momento de la selección de los términos que formarán parte de una taxonomía, pueden proceder:

  • De análisis de los contenidos del sitio, o del área de actividad del sitio, por tanto en el input también pueden intervenir diccionarios y enciclopedias especialmente la Wikipedia.
  • De los términos utilizados por los usuarios en la búsqueda web, por tanto, el input puede ser la investigación de palabra clave que suele hacerse en el SEO  y los datos de Google Analytics.
  • De los términos utilizados por los usuarios en la búsqueda interna del sitio, la analítica de nuestro sitio web.
  • De estudios de benchmarking.
  • De estudios de usuarios.

Una vez tenemos una taxonomía, ¿tenemos resuelta la navegación de nuestro sitio?

Depende. En algunos casos, la taxonomía se identificará con la mayor parte de las estructuras de navegación.

En otra clase de sitios, por ejemplo, en un comercio electrónico, seguramente aportará solamente una parte, aunque muy importante, de los componentes de las diferentes estructuras de navegación.

¿Qué relación tiene una taxonomía con la navegación de un sitio web?

Los términos de la taxonomía proporcionan parte de los componentes y parte de las estructuras de navegación de un sitio.

No existe una relación de identidad total porque la tipología de navegación debe contemplar otros requerimientos, por ejemplo, la navegación corporativa, así como las estructuras de navegación principales deben incluir otros componentes como landing pages, secciones que se desea promocionar, navegación por audiencias, entre otras, por no mencionar el carrito de la compra, avisos legales, etc.

¿De qué forma se aplican a sitios web?

En el caso de WordPress, las taxonomías, tanto las Categorías como las Etiquetas se pueden utilizar para agrupar entradas. Las Categorías corresponden a las grandes secciones del sitio, y expresan por tanto, el contenido de forma global. Las Etiquetas se aplican como palabras clave para expresar con un nivel específico los contenidos de cada entrada.

¿En qué lugar de un sitio web se pueden aplicar las taxonomías?

Una vez desarrollada, una taxonomía se aplica diversas estructuras de navegación y a otros sistemas de acceso a la información en un sitio web.

  • Sistema de menús
    • Menú principal
    • Menú secundario
    • Menús complementarios
    • Submenús
    • Menú desplegable
    • Nube de etiquetas
  • Navegación semántica
    • Categorías y Etiquetas en Entradas
    • Contenidos relacionados
  • Otras estructuras
    • Índices
    • Mapas
    • Migas de pan

¿Cuáles son sus principios de utilización y mantenimiento?

  • Consistencia. La clave en cualquiera taxonomía es la consistencia. Los términos de las taxonomías deberían ser autoexcluyentes y, a poder ser, utilizar un mismo principio de organización, ya sea temático, geográfico, cronológico, etc. No obstante, en algunos sitios web será inevitable usar más de un principio de categorización, como público, actividades, temas, etc. Las relaciones jerárquicas igualmente deberían ser consistente y estar basadas en algún principio lógico, como el de clase-subclase, o el de todo-parte.
  • Rotulación. Los rótulos o palabras para expresar los términos tanto de categorías como de subcategorías deben estar bien seleccionados, ser clarificadores y coherentes entre ellos. Por ejemplo, esta lista de Categorías (tomada de un sitio real) no tiene ningún sentido: Internacional | Mundo | Deportes…  ¿Qué diferencia hay entre Mundo e Internacional? Una más coherente podría ser Nacional | Internacional | Deportes… etc.
  • Formato. En ausencia de otros criterios, se suelen preferir sustantivos antes que verbos u otras formas: Juegos, en lugar de Jugar. Igualmente, se suele preferir el plural en cosas contables, mientras que se utiliza el singular para cosas incontables (agua, aire), nombres de disciplinas científicas  (Física, Derecho) y nombres de materiales (hierro, carbón). Se prefieren los así llamados unitérminos, como Turismo, en lugar de términos compuestos como Turismo en Europa. Es mejor utilizar Turismo y Europa como términos separados, y asignarlos a las Entradas que traten efectivamente, de turismo en Europa. En cambio, se deben mantener los nombres compuestos si su separación hace que pierdan su sentido, por ejemplo, Economía política, y no digamos si el término compuesto es un solo concepto, como en Vehículos a motor. Entre diversas formas de referirse al mismo concepto, se preferirá la que sea más conocida, frente a la más especializada.
  • Justificación. Por este principio, nos referimos a cuando o qué justifica crear un término taxonómico. Las categorías tiene una justificación muy clara: expresan los temas o funciones principales de un sitio.
  • Un concepto = un término. Este principio nos dice que no debe haber más de un término para el mismo concepto. Dicho de otro modo, no debe haber términos sinónimos. Corresponde elegir uno de los sinónimos y utilizar solamente uno. En sitios con un gran número de términos, se pueden utilizar reenvíos en caso de presentar índices de contenidos.
  • Cambios limitados. Este principio parece contradictorio con la idea de que deben editarse y mantenerse las taxonomías, una idea que implica cambios discrecionales. Sin embargo, hay que intentar conciliar ambos principios. La razón es la siguiente: cada término taxonómico en un CMS como WordPress es una página con una URL determinada. Si los cambios implican eliminar términos porque, por ejemplo, hemos detectado dos sinónimos y los fusionamos en un solo término, estaremos eliminando páginas del sitio, lo que implica necesidad de redireccionamientos o riesgo de enlaces rotos, internos o externos. Los redireccionamientos pueden ser una buena solución siempre que no acabemos generando cientos de ellos por cambios reiterados en las Etiquetas, por ejemplo.

 

¿Qué es una taxonomía facetada?

Una taxonomía facetada es una taxonomía múltiple. Por tanto, una taxonomía facetada consiste en un número de taxonomías diferentes, siendo cada una de ellas una faceta de la clase de entidades que son categorizadas, y de aquí su nombre. Es el conocido fenómeno de la polijerarquía.

Para saber si nos conviene o no una clasificación facetada hacemos lo siguiente: cuando vemos  que las polijerarquías afectan a las categorías (en vez de a las entradas), es posible que nuestra taxonomía gane en funcionalidad si usamos una taxonomía múltiple en lugar de una unitaria.

 

Accesibilidad web: Cómo hacer una navegación más accesible

En esta entrada voy a comentaros varios requisitos y técnicas de accesibilidad que nos ayudarán a tener una navegación más sencilla y más accesible.

Accesibilidad web: Cómo hacer una navegación más accesible

Cómo hacer una navegación accesible

Los requisitos a tener en cuenta son los siguientes:

  • Ofrecer varias vías de navegación para localizar el contenido
  • Facilitar la ubicación al usuario para que en ningún momento se sienta perdido
  • Mantener la consistencia lo largo del sitio

 

1. Múltiples vías  de navegación

Lo primero vamos a explicar es cómo establecer diferentes vías para mejorar la navegación de forma que los usuarios lo encuentren fácil y puedan satisfacer sus necesidades.

Para ello, tendremos en cuenta el criterio 2.4.5. “Múltiples vías: Se proporciona más de un camino para localizar una página web dentro de un conjunto de páginas web, excepto cuando la página es el resultado, o un paso intermedio, de un proceso. (Nivel AA)

Hay quienes prefieren usar el buscador a recorrer un menú de navegación largo. Otros prefieren usar tablas de contenidos o un mapa del sitios para navegar por el sitio

Por eso, las WCAG 2.0 establece que tenemos que aplicar dos o más técnicas para mejorar la navegación.

  • Mapa del sitio
  • Función de búsqueda
  • Enlaces a páginas relacionadas
  • Tabla de contenidos

 

Mapa del sitio

Es muy importante tener en cuenta la creación de un mapa web, que ayude a facilitar la comprensión del sitio web. Para ello, tenemos la técnica G63: Proporcionar un mapa del sitio y que debe cumplir una serie de requisitos:

  • Debe estar enlazado a todas las páginas, o desde cada una de las páginas que se listan en el mapa web.
  • Desde el mapa web se tiene que poder acceder a todas las páginas del sitio, directa o indirectamente. Por lo tanto, sus elementos deben ser enlaces.
  • La presentación y la estructura deben reflejar la orgnización del sitio, con elementos HTML, como son los encabezados y las listas.
  • El orden de lectura y de tabulación debe ser el correcto.
  • Se debe actualizar cada vez que se actualiza el sitio.

Función de búsqueda

Otra técnica a tener en cuenta es proporcionar una función de búsqueda en el sittio web, patra que los usuarios puedan acceder a buscar el contenido sin necesidad de entender el sitio o navegar por él. Es muy útil en sitios de gran tamaño.

La función de búsqueda se realizará mediando un campo de búsqueda que esté presente en las páginas del sitio. La técnica que habla de esto es la G161: Proporcionar una función de búsqueda para ayudar a los usuarios a encontrar contenido.

 

Enlaces a páginas relacionadas

Otra técnica que se puede emplear es enlaces a páginas relacionadas. De esta manera los usuarios ppueden encontrar información adicional. Técnica G125: Proporcionar enlaces para navegar a páginas relacionadas.

 

Tabla de contenidos

Otra técnica es utilizar una tabla de contenidos, que consiste en un índice con las secciones y subsecciones de una página, y que proporciona un acceso directo a una sección específica. Para más información sobre ello, se puede consultar la técnica G64: Proporcionar una tabla de contenidos.

Otras técnicas para sitios pequeños

Si el sitio es pequeño se pueden aplicar otras técnicas:

  • el menú de navegación incluye el acceso a todas las páginas del sitio.
  • todas las páginas están enlazadas desde la página de inicio.

Técnicas relacionadas:

 

Ubicación del usuario

Un requisito muy importante que hará que el sitio web sea más accesible es facilitarle la ubicación a los usuarios, proporcionarle inforción sobre dónde se encuentran.

Para ello, esta el criterio 2.4.8 Ubicación: se proporciona información acerca de la ubicación del usuario dentro de un conjunto de páginas web.

Hay varias técnicas para conseguir esto:

Migas de pan.

Las migas de pan van a ayudar a:

  • Comprender cómo se estructura el contenido de un sitio web.
  • Navegar por las páginas visitadas
  • Identificar la ubicación actual de una página dentro del sitio web.

¿Qué requisitos deben cumplir las migas de pan?

  • Deben estar siempre situadas en el mismo lugar en todas las páginas.
  • Maquetarlas mediante listas, aunque visualmente se presenten en línea.
  • Usar separadores visuales entre las mismas.
  • Deben ser enlaces.
  • Deben indicar el camino usado para llegar a la página actual o bien indicar su situación en la jerarquía u organización del sitio.

 

Indicar la situación actual en la navegación

Otra técnica para facilitar la ubicación del usuario es indicar la situación actual en menús, barras de navegación, pestañas o pasos en un proceso. Todo cambio que se produzca se debe comunicar a los usuarios.

Por eso, el menú o paso en el que nos encontramos no solo se debe indicar visualmente, sino también estructural y semánticamente o mediante texto si fuera necesario como establece el criterio 1.3.1 Información y relaciones. Se puede obtener más información sobre este requisito en la técnica G128: Indica la ubicación actual dentro de las barras de navegación.

 

Elemento <link>

Otra técnica es incluir navegación semántica a través del elemento link

<head><title>Capítulo 2</title>
<link rel="index" href="index.html“ title="Índice" />

<link rel="start" href=“intro.html“ title="Introducción" />

<link rel="next" href=“cap3.html“ title="Capítulo 3" />

En este ejemplo estamos indicando, dentro de una colección de páginas: el índice, la primera página de la colección y la siguiente.

La ventaja de usar <link> para establecer las relaciones es que este elemento se puede interpretar mediante software. Se puede ampliar información en la técnica H59: Uso del elemento de enlace y las herramientas de navegación.

 

Consistencia

Otro aspecto que hace más accesible la navegación es la consistencia, tanto en la presentación y maquetación de los mecanismos de navegación, como en la identificación de los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas

  • 3.2.3 – Navegación coherente
  • 3.2.4 – Identificación coherente

Navegación coherente

Si los mecanismos de navegación que se repiten en diferentes páginas de un conjunto (como el buscador, el menú de navegación, las migas de pan, etc), se presentan en el mismo orden en las diferentes páginas del conjunto, los usuarios pueden predecir dónde estarán en cada página y localizarlos con más facilidad. Para más información se puede consultar la técnica G61.

Identificación coherente

Tan importante es la navegación coherente, como la identificación coherente, porque si en un sitio web se usan diferentes etiquetas para una misma función se dificulta considerablemente la comprensión y la interacción con el sitio, y en definitiva su uso.

Identificación coherente quiere decir, en los enlaces, que aquellos que tienen un mismo destino tienen el mismo texto de enlace.

Por ejemplo, si el destino del enlace es la página de inicio del sitio, el texto del enlace no puede ser unas veces “Ir a la home”, en otras “Ir a la página de inicio” y en otras “Ir a la página principal”.

El texto del enlace además deberá ser consistente con el título de la página, el nombre con el que se identifica a la misma en las migas de pan o en el mapa del sitio.
En el caso de destinos similares, los textos de enlace deberán ser consistentes.

Por ejemplo, en un portal de noticias, el texto del enlace para ampliar información sobre cada noticia, no puede ser en un caso “Más información”, en otro “Leer más” y en otro “Más info”.

La identificación coherente también se aplica al texto alternativo de los elementos no textuales.
Por ejemplo, si se usa el mismo icono en diferentes páginas, se entiende que con la misma función, debe tener el mismo texto alternativo, si tenemos un icono para descargar un fichero, su texto alternativo no puede ser en unos casos “descargar”, en otros “guardar” y en otros “bajar”.

Y la identificación coherente se aplica también a las etiquetas de los campos de formulario: los mismos controles de formulario deben estar etiquetados igual.

Por ejemplo, no podemos etiquetar el campo contraseña en unos casos como “password”, en otros como “contraseña” y otros como “clave”.

 

Accesibilidad web: Problemas con el foco de teclado

En esta entrada voy a hablar de un problema bastante habitual en los sitios web. Hay personas que navegan por un sitio web a través de teclado, porque no ven. Al carecer de visión no pueden llevar a cabo el manejo del ratón y la visualización de la pantalla para poder dirigir el puntero.

 

Accesibilidad web: Problemas con el foco de teclado

Navegación por el sitio web a través de teclado

Para muchas personas este el único medio que tienen poder acceder a los sitios web:

  • Personas que usan un lector de pantallas o teclado braille.
  • Personas con diversidad funcional física o motriz, que pueden usar:
    • teclados alternativos.
    • Licornios, punteros de cabeza o apuntadores de boca para interactuar con el teclado.
    • Pulsadores de soplado que simulan la navegación por teclado.
  • Usuarios expertos que se manejan más rápido por teclado que con el ratón.
  • Personas que usan un portátil, que prefieren la navegación por teclado, o cuando existe un problema que impide usar el ratón.

Accesibilidad por teclado

Las WCAG 2.0 tienen varios criterios que hacen referencia a la operabilidad de los sitios web mediante el teclado.

teclado

2.1 Accesible por teclado

  • 2.1.1 Teclado Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requiera una determinada velocidad para cada pulsación individual de las teclas, excepto cuando la función interna requiere de una entrada que depende del trayecto de los movimientos del usuario y no sólo de los puntos inicial y final. (Nivel A)
  • 2.1.3 Teclado (sin excepciones): Toda la funcionalidad del contenido se puede operar a través de una interfaz de teclado sin requerir una determinada velocidad en la pulsación de las teclas. (Nivel AAA)

 

Problemas con el foco de teclado

Hay varios problemas que impiden la navegación por los sitios web y que están relacionados con el foco de teclado. Estos problemas son:

  • El foco no está visible
  • El orden del foco no tiene sentido
  • Las páginas tienen trampas para el foco
  • Recibir el foco provoca automáticamente un cambio de contexto sin avisar al menos previamente al usuario.

1. El foco no está visible

Por defecto, cuando un enlace coge el foco aparece punteado alrededor.  O cuando un campo de formulario coge el foco también se aprecia visualmente, es decir, muestra un cursor parpadeando en su interior. El criterio de conformidad que recoge este problema es el 2.4.7 Foco visible.

El problema está en que hay sitios web en los que por razones estéticas, el foco no se encuentra visible, lo cual dificulta la navegación a muchos usuarios. Por lo tanto, el foco debe estar visible en todo momento.

El foco puede resaltarse con un borde más sólido y de color. Y usarse con la pseudoclase :hoveren la CSS y así resalta también con la interacción mediante ratón.

 

2. El orden del foco no tiene sentido

Otro de los problemas es que el orden del foco no tenga sentido. Por eso, es muy importante que el orden del foco sea el correcto, tal y como establece el criterio 2.4.3 de las WCAG 2.0.

Por ejemplo, si un enlace abre un menú desplegable, el siguiente elemento que debería coger el foco sería el primer elemento del menú.

No  sólo es necesario que el orden de lectura sea lineal y tenga sentido, sino también que el orden del foco por los elementos de interacción también lo tenga. De igual manera ocurre con el atributo global tabindex.

 

3. Trampas para el foco

El tercer problema que nos encontramos son las trampas para el foco. Son aquellas zonas a las que no podemos llegar mediante teclado, como son las ventanas modales o cuadros de diálogo, los controles de un reproducción de un vídeo o una animación en Flash. En estas interacciones sólo se puede volver atrás o ir a otra parte mediante el ratón.

Tal y como se puede leer en el criterio de conformidad 2.1.2 Sin trampas para el foco de teclado, vamos a seguir con el ejemplo del menú desplegable.

Si una vez que abrimos el menú, navegamos con la tecla TAB, y por cualquier razón no podemos volver a salir con el teclado, se consideraría una trampa para el foco.

 

4. Recibir el foco provoca un cambio de contexto

Otro de los problemas que se pueden dar es cuando se produce un cambio de contexto y reciben el foco sin advertir previamente al usuario.

Los cambios de contexto deberían producirse cuando el usuario realiza una acción, que normalmente se utilice para solicitar un cambio de contexto, como hacer clic en un enlace o un botón.

Los cambios inesperados en el contexto o que no puedan detectarlos pueden desorientar a los usuarios.

¿Qué es un cambio de contexto?

Es un cambio importante en el contenido de la página, que cuando se hace sin el consentimiento del usuario, puede desorientar a quienes no pueden ver la página o no pueden ver toda la página al mismo tiempo.

Esto incluye cambios en:

  • El agente de usuario. Como abrir un gestor de correo o un lector de PDF.
  • El foco: Mover automáticamente el foco a otro elemento. Una mala práctica muy habitual en los formularios es mover el foco de un control a otro automáticamente, por ejemplo al rellenar los campos de una cuenta bancaria. También es una mala práctica habitual utilizar  onfocus="blur()"para quitar el foco a un elemento cuando lo recibe.
  • El área de visualización del contenido: abrir otra ventana, otra pestaña o cambiar de marco.
  • El contenido. Cambios en el contenido que cambian el significado de la página: enviar un formulario, ir a otra página, o que lo parezca porque se cambia el orden del contenido de la misma.

Los criterios relacionados con este problema son:

3.2.1 Al recibir el foco

3.2.2 Al recibir entradas

3.2.5 Cambios a petición

 

Accesibilidad web: Las WCAG 2.1

El pasado 5 de junio, el W3C estableció como recomendación las WCAG 2.1, tras más de 10 de la publicación de las WCAG 2.0.

Accesibilidad web: WCAG 2.1

Introducción

Antes de empezar, me gustaría aclarar una cosa:

Un sitio web que aplique las WCAG 2.1 también cumple con las WCAG 2.0.

La novedad, es que los criterios ya no están ordenados por su nivel de conformidad. Para no cambiar el número de criterio a los criterios existentes, los nuevos siempre se han añadido al final de los actuales.

Para ello, hay una guía de referencia y ayuda, que permite filtrar los criterios por nivel, ya sea de las WCAG 2.0 o WCAG 2.1.

Filtro para los criterios en las WCAG 2.1

WCAG 2.1.

Como ya veníamos comentando desde hace unos meses, existen 17 nuevos criterios de conformidad, que son los siguientes:

 

Criterio 1.3.4: Orientación.

“El contenido no restringe su vista y funcionamiento a una única orientación de visualización, como vertical u horizontal, a menos que una orientación de visualización específica sea esencial.”

Este criterio hace referencia a que los sitios web deben admitir las dos orientaciones disponibles para que se pueda adaptar a todo tipo de usuarios, y asegurarse de que el contenido y la funcionalidad de la web estén disponibles. El contenido debe ser operable en todas las orientaciones de pantalla.

Criterio 1.3.5. Identificar el propósito de la entrada.

El propósito de cada campo que recoge información del usuario se puede determinar por software cuando:

  • el campo tiene un propósito identificado y concreto de los listados en el apartado 7. Input Purposes for User Interface Components (“name”, “country”, “postal-code”, etc.), cuya lista está basada en la de HTML 5.2 Autofill field section. Y
  • el contenido está implementado usando una tecnología con soporte para identificar el significado esperado del dato introducido en un campo de formulario.

Este criterio ayuda a que sea más fácil rellenar los campos de formularios, según las necesidades y las preferencias de los usuarios.

La técnica suficiente incluida es utilizar autocomplete con los atributos definidos en HTML 5.2 Autofill field section.

Criterio 1.3.6 Identificar el propósito.

“En el contenido implementado utilizando lenguaje de marcas, el propósito de los componentes de la interfaz de usuario, los iconos y las regiones se puede determinar mediante programación.”

Tiene el mismo objetivo que el criterio anterior en cuantro a las preferencias y necesidades de los usuarios. Por ejemplo, si se identifica que es un botón para enviar un email, este tipo de botón se podrá personalizar con un icono o un término comprensible para un usuario en particular; se podrá mostrar ayuda relacionada con esa función, renderizarlo más grande, etc.

Las técnicas suficientes que se incluyen son: agregar semántica a los elementos usando landmark roles ARIA.

Como técnicas recomendables se incluyen: el uso de los atributos ARIA aria-invalid y aria-required en los campos de formulario.

1.4.10 Reflow

“El contenido puede presentarse sin pérdida de información o funcionalidad y sin necesidad de hacer scroll en dos dimensiones*, para:

  • Contenido con desplazamiento vertical con un ancho equivalente a 320 píxeles CSS;
  • Contenido con desplazamiento horizontal con una altura equivalente a 256 píxeles CSS;

*excepto para partes del contenido que lo requieran para su uso o significado.

En las notas se indica que, 320 píxeles CSS es equivalente a un viewport width inicial de 1280 píxeles CSS con un zoom de 400%. Para el contenido diseñado para escrolar horizontalmente, 256 píxeles CSS es equivalente a un viewport height inicial de 1024px con un zoom de 400%.

Los contenidos que pueden requerir doble scroll son: imágenes, mapas, diagramas, vídeo, juegos, presentaciones, tablas de datos, o interfaces donde es necesario mantener las barras de herramientas a la vista mientras se manipula el contenido.

Este criterio asegura que se puede hacer zoom de 400% sin pérdida de contenido o funcionalidad y se evitan los dobles scroll (salvo en los casos citados), pues el impacto del desplazamiento horizontal aumenta el esfuerzo de lectura 40-100 veces.

Las técnicas suficientes que se incluyen son: usar media queries y CSS grids o CSS Flexbox para reajustar los contenidos. Y también, calcular por programación los tamaños y posiciones de los elementos de manera que escalen con el tamaño del texto.

Como técnicas recomendables se incluyen: ajustar el tamaño de las imágenes y las tablas al viewport; y dar un mecanismo que permita cambiar a la vista móvil en cualquier momento.

Como errores comunes se nombran: usar tamaños y posiciones fijas; impedir el zoom; y usar texto preformateado o tratarlo como una excepción.

1.4.11 Contraste no textual

“La presentación visual de los siguientes elementos tiene una ratio de contraste de al menos 3:1 respecto a los colores adyacentes:

  • Componentes de la interfaz de usuario: información visual utilizada para identificar los componentes de la interfaz de usuario y los estados, excepto para componentes inactivos o cuando la apariencia del componente es determinada por el agente de usuario y el autor no la modifica.
  • Objetos gráficos: partes de los gráficos necesarias para comprender el contenido, excepto cuando una presentación particular de los gráficos es esencial para la información que se transmite (esencial como por ejemplo en los logotipos o en las banderas, en una captura de un sitio que muestra cómo es su apariencia, en un mapa de calor, en un diagrama médico que usa los colores utilizados en biología, etc.)

 

El criterio 1.4.3 solo abarca “la presentación visual de texto e imágenes de texto” y por tanto el criterio 1.4.11 lo complementa, porque el contraste sería también necesario para:

  • los iconos (que no van con texto)
  • los gráficos, por ejemplo, cada una de sus líneas
  • el borde o límites visuales de un campo de formulario o botón, siempre que no estuviera disabled
  • el indicador visual del valor actual en un control deslizante
  • el indicador del foco
  • etc.

Las técnicas suficientes para las gráficas son: que el contraste entre los colores de las gráficas sea suficiente así como el contraste de las líneas entre colores adyacentes.

Las técnicas suficientes para los textos de las gráficas son: que se incluyan en las gráficas etiquetas y valores; que las imágenes que transmiten información y los textos de las gráficas tengan suficiente contraste; o que haya un control con suficiente contraste que permita a los usuarios cambiar a una presentación que utilice suficiente contraste.

Como técnica recomendable, en el caso de los enlaces y controles que solo se identifican por el color, sería un ratio de contraste de 4,5:1 con el texto de alrededor y pistas visuales adicionales.

1.4.12 Espaciado de texto

El contenido implementado con lenguaje de marcas que soporte las siguientes propiedades, no se pierde contenido o funcionalidad ni por configurarlas, ni por no cambiar ninguna otra propiedad de estilo:

  • altura de línea (espaciado entre líneas): al menos 1.5 veces el tamaño de fuente
  • espaciado debajo de los párrafos: al menos 2 veces el tamaño de fuente
  • espaciado de letras (tracking): al menos 0.12 veces el tamaño de fuente
  • espaciado de palabras: al menos 0.16 veces el tamaño de fuente

 

La técnica suficiente que se incluye es: el espaciado del texto se pueda cambiar, siendo un error habitual usar medidas fijas.

Como técnicas recomendables se indican: usar las propiedades CSS letter-spacing, line-height y definir el tamaño de los contenedores en em

1.4.13 Contenido en Hover o Foco

Cuando el contenido se hace visible/oculto porque un componente de la interfaz coge/pierde el foco, lo siguiente es verdad:

  • Dismissable. Hay un mecanismo disponible para descartar el contenido adicional sin mover el puntero o el foco del teclado, a menos que el contenido adicional comunique un error en la entrada de datos, o no tape o reemplace otro contenido.
  • Hoverable. Si el puntero del cursor puede activar el contenido adicional, entonces el puntero se puede mover sobre el contenido adicional sin que desaparezca el contenido adicional.
  • Persistent. El contenido adicional permanece visible hasta que la activación del hover/focus se elimine, el usuario lo descarte o su información ya no sea válida.

 

Algunos ejemplos de contenidos a los que SÍ se aplica este criterio son: tooltips personalizados, submenús, pop-ups no modales que se muestran en el hover o en el focus, etc.

Las técnicas suficientes que se incluyen son: el uso de las pseudo-clases hover y focus.

Como técnicas recomendables: no escondas los elementos que desencadenan los cambios; y no escondas los nuevos mensajes cuando se haga hover sobre ellos, o hasta que el usuario los descarte o sean incorrectos.

2.1.4 Atajos de teclado de caracteres

si se implementa un atajo de teclado en el contenido usando una letra (incluidas mayúsculas y minúsculas), signo de puntuación, número o símbolo, entonces al menos una de las siguientes afirmaciones es cierta:

  • Desactivar: hay un mecanismo para desactivar el atajo.
  • Reasignar: hay un mecanismo para reasignar ese atajo de teclado, usando uno o más caracteres de teclado no imprimibles (Alt, Ctrl,…)
  • Activo solo en el foco: el atajo de teclado de un componente de la interfaz solo está activo cuando ese componente tiene el foco.

 

Este criterio tiene relación con los atajos de teclado personalizado.

Beneficia a los usuarios que utilizan programas de reconocimiento de voz que pueden activar varios atajos accidentalmente cuando estos están asociados a una sola tecla.

También puede evitar errores. El usuario de teclado puede pulsarla sin querer, especialmente aquellos que tienen problemas de movilidad.

Las técnicas suficientes se incluyen son: que los usuarios tengan una forma de desactivar los atajos de teclado de un solo carácter, o que exista un mecanismo que permite a los usuarios modificar los atajos de teclado y reasignarlos a caracteres no imprimibles.

2.2.6 Tiempos de espera

Se debe advertir a los usuarios de la duración de cualquier inactividad del usuario que pueda causar la pérdida de datos, a menos que los datos se conserven durante más de 20 horas cuando el usuario no realiza ninguna acción.”

2.3.3 Animación de interacciones

“Las animaciones de movimiento desencadenadas por una interacción pueden ser deshabilitadas, a menos que la animación sea esencial para la funcionalidad o la información que se transmite.”

Este criterio se aplica cuando una interacción del usuario inicia una animación inesperadamente.

Esto puede provocar no solo distracción, sino incluso en algunos usuarios con desorden vestibular, nauseas y dolores de cabeza.

Las técnicas suficientes que se incluyen son: que los usuarios puedan definir en sus preferencias que no haya animaciones.

2.5.1 Gestos del puntero

“Toda funcionalidad que usa gestos multipunto o basados en una trayectoria, puede ser operada con un solo gesto de puntero (single pointer) sin depender de un gesto basado en una trayectoria, a no ser que sea esencial un gesto multipunto o basado en una trayectoria.”

iconos-del-gesto-fijados-para-los-dispositivos-móviles-del-tacto

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes que se incluyen son: no basar la interacción solo en recorridos gestuales o en varios toques, ofrecer controles alternativos que permitan realizar la misma función pero que no requieran gestos complejos.

2.5.2 Cancelación del puntero

“Para la funcionalidad que se puede operar con un puntero único, al menos una de las siguientes afirmaciones es verdad:

  • No Down-Event: el down-event del puntero no se usa para ejecutar ninguna parte de la función
  • Abort or Undo: la finalización de la función está en el up-event, y hay un mecanismo disponible para abortar la función antes de completarse o deshacer la función una vez completada
  • Up Reversal: el up-event invierte cualquier resultado del down-event anterior.
  • Essential: completar la función en el down-event es esencial

 

“Down-event”, es cuando se presiona el dedo contra la pantalla.

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes se incluyen son: la activación de los controles en el up-event en HTML, iOS y Android; y que los eventos táctiles solo son activados cuando el toque se retira del control.

Como error a evitar, no actives un control en un down-event si el evento up-event no coincide con la misma localización del puntero.

2.5.3 Etiqueta en Nombre

“Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente. Y añade en una nota que una buena práctica es poner el texto de la etiqueta al comienzo del nombre.”

Si la etiqueta visible no es igual que la etiqueta no visible (el nombre accesible) los usuarios que acceden con programas de reconocimiento de voz pueden tener problemas. Hay que tener en cuenta que estos usuarios pueden decir el menú, el vínculo o la etiqueta del botón para activarlos.

Para los usuarios que utilizan un lector de pantalla pero visualizan la pantalla, también es mucho más claro que el nombre accesible que se les anuncia coincida con la etiqueta visual.

La técnica suficiente que se incluye es que las etiquetas visibles concuerden con los nombres accesibles.

Como técnica recomendable, si un icono no va acompañado de un texto, usa su texto “hover” como nombre accesible.

Los errores habituales que se listan:

  • El nombre accesible no contiene el texto visible de la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero las palabras de la etiqueta visible no están en el mismo orden.
  • El nombre accesible contiene el texto de la etiqueta visible, pero una o más palabras se entremezclan en la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero hay una o más palabras adicionales antes del texto de la etiqueta visible.

2.5.4 Actuación de movimiento

Toda funcionalidad que puede ser operada por el movimiento del dispositivo o por el movimiento del usuario, también puede ser operada mediante los componentes de la interfaz de usuario, y la respuesta al movimiento se puede desactivar para evitar el accionamiento accidental.

Incluye dos excepciones:

  • Supported Interface: el movimiento se utiliza para operar la funcionalidad a través de una interfaz compatible con la accesibilidad.
  • Essential: el movimiento es esencial para la función o si no se invalidaría la actividad.

Este criterio hace referencia a los sensores del dispositivo que detectan y responden a algún tipo de entrada del entorno físico. Por ejemplo, un movimiento como agitar el móvil, inclinar la tablet, etc.

Este criterio no se aplica a los sensores de geolocalización, ni a los movimientos que no sean movimientos intencionales del usuario, ni a los asociados al uso del teclado, el puntero o productos de apoyo.

Las técnicas suficientes que se incluyen son: proporcionar formas alternativas de introducir información cuando se usan los sensores de movimiento para activar funcionalidades y contenidos; y que el usuario pueda desactivar la actuación por movimiento.

2.5.5 Tamaño de la región de pantalla

Define que el tamaño mínimo del “target” (región de la pantalla que acepta la acción del puntero) debe ser 44×44 píxeles CSS.

Incluye ciertas excepciones:

  • Equivalent. Si el target está disponible a través de un enlace o un control equivalente, en la misma página, que tiene al menos 44×44 píxeles CSS.
  • Inline. Si el target está en una frase o en un bloque de texto.
  • User agent control. Si la apariencia del target es determinada por el agente de usuario y no es modificada por el autor.
  • Essential. Si una presentación particular del target es esencial para la información que se transmite.

 

El tamaño 44×44 que se define es el mínimo, pero se recomienda utilizar tamaños mayores, esto es especialmente importante en los siguientes casos:

  • El control se usa con frecuencia.
  • El resultado de la interacción no se puede deshacer fácilmente.
  • El control está situado en un lugar que será difícil de alcanzar o está cerca del borde de la pantalla.
  • El control es parte de una tarea esencial.

 

Las técnicas suficientes que se incluyen son: que las áreas interactivas tengan al menos 44*44px; y ofrecer un mecanismo que permita cambiar el tamaño de las áreas.

Como técnica recomendable, el área interactiva de un párrafo que es un enlace también tiene al menos 44*44px.

2.5.6 Mecanismos de entrada concurrentes

“El contenido web no restringe el uso de las modalidades de entrada (teclado, interfaz de teclado, ratón, pantalla táctil, habla, etc.) disponibles en una plataforma, excepto cuando la restricción es esencial, necesaria para garantizar la seguridad del contenido o respetar la configuración del usuario.”

En la mayoría de los dispositivos, es posible que los usuarios cambien entre diferentes medios de entrada de datos en la misma sesión (por ejemplo, entre pantalla táctil y teclado).

La aplicación o sitio web no debe asumir que el usuario siempre utilizará exclusivamente un mecanismo de entrada particular, y deberá permitir a los usuarios operar con cualquier mecanismo de entrada a su disposición.

Las técnicas suficientes que se incluyen son: usar solo manejadores de evento JS de alto nivel, independientes de la modalidad de entrada (focus, blur, click); o incluir manejadores de evento redundantes para las diferentes modalidades de entrada.

4.1.3 Mensajes de estado

“en el contenido implementado mediante lenguaje de marcas, los mensajes de estado pueden ser determinado por software a través de roles y propiedades, de modo que puedan ser presentados a los productos de apoyo sin recibir el foco.”

Se debe proporcionar una notificación para cada cambio del contenido de la página. No se trata tanto de que se vean esos mensajes, sino de que sean anunciados por el lector de pantalla. Esto se hace con el atributo aria-live de ARIA y sus roles específicos.

Los mensajes serán del tipo: “El formulario se ha enviado correctamente”

Las técnicas suficientes que se incluyen son:

  • Si el mensaje de estado advierte del éxito o el resultado de una acción o el estado de una aplicación: se usa role="status", informando de que el datos se ha enviado correctamente.
  • Si el mensaje de estado transmite una sugerencia o una advertencia ante la existencia de un error: se usa role=alert, en combinación con alguna de otras técnicas ya existentes como dar una descripción textual para identificar los campos requeridos no completados, así como los campos con valores o formatos no permitidos; permitir saltar a los errores; dar sugerencias de corrección o proporcionar una revisión ortográfica y sugerencias para la entrada de datos.
  • Si el mensaje de estado transmite información sobre el progreso de un proceso: se usa el role="log", role="progressbar" o role="status"

 

Nota adicional: 5.2.2 Páginas completas.

Este requisito de conformidad trata de que una página es conforme si es conforme en su totalidad, lo cual incluye las alternativas a las que enlaza (como por ejemplo una página con descripciones extensas de imágenes o con presentaciones alternativas de un vídeo).

Esta nota añade que las distintas variaciones de la página, como las generadas automáticamente para diferentes resoluciones de pantalla, también forman parte de esa página y deben ser conformes todas ellas.

Usabilidad web: Arquitectura de información y wireframes

En esta entrada voy a hablar de un concepto importante para todas las personas relacionadas con el mundo del diseño y la usabilidad: Los wireframes o prototipos.

Pero antes de empezar, toca hacer una pequeña introducción sobre los wireframes. El primer paso que hay que dar para llevar a cabo los wireframes es la representación mediante diagramas para establecer el contenido de la interfaz y la estructura que contiene. Sirve para la propuesta del producto final.

 

 

La definición de Arquitectura de Información la acuñó Richard Saul Wurman en 1975. La define como:

El estudio de la organización de la información con el objetivo de permitir al usuario encontrar su vía de navegación hacia el conocimiento y la comprensión de la información

En la Arquitectura de Información existen dos tipos de diagramas: Planos o mapas web, (blueprints) y maquetas (wireframes).

A los planos o mapas web sencillos se les denomina diagramas de organización y funcionamiento. Estos diagramas tienen un objetivo: mostrar cuál será la estructura del sitio web y su flujo de navegación.

A las maquetas se les denomina diagramas de presentación, donde podemos hablar de diferentes tipos de prototipos.

Los prototipos pueden tener múltiples niveles de detalle y pueden dividirse en dos categorías en términos de fidelidad: Baja fidelidad y alta fidelidad.

  • Baja fidelidad: Se caracteriza por un dibujo en bruto o un boceto rápido, los wireframes de baja fidelidad tienen menos detalles y son rápidos de producir. Estos wireframes ayudan a un equipo de proyecto a colaborar más efectivamente debido a que son más abstractos, usando rectángulos y etiquetas para representar el contenido. Para dibujos sencillos o de baja fidelidad, los prototipos en papel es una técnica común. Como estos son sólo representaciones, las notas al margen para explicar comportamientos son útiles.

Ejemplo de ello son los sketches, que son bocetos rápidos para transmitir cualquier idea. Es una forma eficaz de comenzar el prototipado de un sitio web, pues permite trabajar ágilmente con varias ideas y esquematizar las páginas.

  • Alta fidelidad: Los wireframes de alta fidelidad o maquetas son usados a menudo para documentar, porque ellos incorporan un nivel de detalle que se acerca más al diseño final de una página web, pero toma más tiempo para ser creado.

Algunas herramientas permiten incorporar interactividad, incluyendo animación en Flash, y tecnologías de presentación web como HTML, CSS, y JavaScript.

¿Qué son los wireframes (o prototipos)?

Un wireframe o prototipo es un boceto donde se representa visualmente, de una forma muy sencilla y esquemática la estructura de un sitio web. Es una representación gráfica del contenido del sitio web.

El objetivo de estos es definir el contenido y la posición de los diversos bloques del sitio web. Esto incluye los menús de navegación, bloques de contenido, botones, formularios, listas…etc Además, te permite ver cómo interactuarán estos elementos entre sí.

Propósitos de los wireframes

Los wireframes tienen varios propósitos:

  • Garantizar que el sitio o la aplicación se desarrolle de conformidad con los fines acordados. La creación de wireframes establece expectativas sobre cómo se implementarán las funciones, mostrando cómo funcionarán, dónde estarán ubicadas y cuántos beneficios ofrecerán. Se puede eliminar una función porque no se adecúa a los objetivos de tu página web.
  • Centrarse en la facilidad de uso. La creación de diagramas ofrece una mirada objetiva de los nombres de enlaces, rutas de conversión, facilidad de uso, navegación, y disposición de las funciones. Te ayudan a identificar fallos en la arquitectura del sitio o las funciones y te indican cómo fluye desde la perspectiva del usuario.
  • Capacidad de crecimiento del contenido. Si sabes que tu página web crecerá en un futuro próximo, tu sitio debe estar preparado para que ese crecimiento tenga un impacto mínimo en el diseño, la facilidad de uso y la arquitectura del sitio. La creación de wireframes puede revelar estas importantes oportunidades de crecimiento del contenido y cómo adaptarse a ellas.
  • Comentarios e iteración sin esfuerzo. Los wireframes garantizan que el diseño y los elementos creativos en un solo paso, se aborden de forma separada. Esto permite a los interesados brindar comentarios en etapas más tempranas del proceso.

 

Tipos de wireframes

Hay tres tipos de wireframes diferentes que varían desde el más simple (planos o modelos en blanco y negro) hasta el más complejo (casi simula el producto real):

  • Wireframes básicos: Modelos en blanco y negro.
  • Con anotaciones y navegación: Contiene información básica a través de bloques de funcionalidad, crea fluido de navegación y el agrupamiento de contenidos.
  • Wireframes detallados y en plataformas: Wireframes realizados con todas las funcionalidades y las herramientas necesarias para ello.

Ventajas de usar wireframes

  • Sirven para plasmar ideas: Son el primer paso para que las ideas abstractas sean concretas y visibles
  • Son rápidos y baratos de crear: Al ser bocetos esquemáticos, son rápidos de crear y tienen un coste muy bajo. Esto te permite realizar múltiples versiones hasta encontrar la adecuada sin que ello suponga un problema de tiempo o dinero.
  • Ayuda a detectar y corregir los problemas antes: Al ser sencillos y rápidos de realizar, te permiten exponerlos rápidamente a una retroalimentación y resolver problemas básicos relacionados con la usabilidad y las funcionalidades propuestas.
  • Obtener mejoras: Sirve para repasar las mejoras que se puedan realizar en el diseño, el posicionamiento de los elementos o la estructura de los contenidos.
  • Mejora la usabilidad: Definir previamente la estructura y los elementos de la página web te permitirá mejorar la usabilidad, evitando así los errores que se puedan dar sobre la marcha.
  • Permiten a los diseñadores tener libertad para diseñar la interfaz.
  • Permite la comunicación del equipo de trabajo y los usuarios.

Libro: Experiencia de usuario. Principios y métodos.

Esta semana toca hablar de un libro de usabilidad. Se titula Experiencia de usuario: Principios y métodos. El autor es Yusef Hassan Montero.

El libro se estructura en tres grandes bloques.

Conceptos fundamentales

En él se describen y explican los conceptos esenciales para comprender y fundamentar los siguientes capítulos: usabilidad, accesibilidad, arquitectura de información, diseño centrado en el usuario, interacción y estilos de interacción, affordance, modelos mentales, necesidades y estrategias de búsqueda de información y relación esfuerzo-beneficio.

Portada del libro de Yusef Hassan Montero. Experiencia de usuario: Principios y métodos

Dedica a cada concepto dos o tres páginas, los explica de forma clara y concisa, e incluye al final de cada uno una bibliografía relacionada.

Principios de diseño

En este apartado se recogen y desgranan los principios de diseño más destacados sobre los que partir a la hora de tomar decisiones de diseño: clasificación, color, eficiencia, error humano, estética, fotografías, gestalt, iconos, inteligencia colectiva, jerarquía visual, legibilidad e inteligibilidad, ley de Fitts, mapeo natural, ordenación, relevancia, taxonomías, toma de decisiones, y visibilidad y retroalimentación.

De nuevo explica cada uno de ellos de forma concisa, en este caso con una media de cuatro páginas por principio. Incluye en cada uno ejemplos, bibliografía y una relación de los principios con los que está relacionado.

Métodos

En esta parte se describen los métodos y técnicas más importantes del Diseño Centrado en el Usuario: analítica web, card sorting (y treejack), diagramas de interacción, diseño modular, encuestas y entrevistas, evaluación heurística, personajes y escenarios (y User Journey Maps), pruebas A/B, pruebas con usuarios, ROI y wireframes.

La organización es la misma que en los apartados anteriores, una media de cuatro páginas para cada uno, indicando su función y procedimiento, con ejemplos, bibliografía y las etapas del proceso para las que resultan pertinentes.

Es un libro muy recomendable. Sirve para todos aquellas personas que se quieran introducir en el mundo de la experiencia de usuario, y sirve como consulta para los expertos en el tema.  Es claro, es conciso, con ejemplos y con bibliografía asociada a cada concepto. El propio diseño y estructura del libro hace que sea muy cómodo de leer, tanto de forma lineal como a modo de consulta, como un glosario muy detallado.

Directiva europea 2016/2012 sobre la accesibilidad de los sitios web y aplicaciones móviles

Tras un proceso de 4 años, el 26 de octubre de 2016 se aprobó la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público.

directiva europea 2016_2012

Objetivo de la directiva

El objetivo de la directiva es armonizar los requisitos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público:

La presente Directiva establece las normas por las que se exige a los Estados miembros que garanticen que los sitios web, independientemente del dispositivo empleado para acceder a ellos, y las aplicaciones para dispositivos móviles de los organismos del sector público cumplan los requisitos de accesibilidad.

Lo primero que deberíamos aclarar es qué es una directiva en el marco jurídico de la Unión Europea.

¿Qué es una directiva?

Las directivas son actos legislativos en los cuales se establecen objetivos que todos los países de la UE deben cumplir. Sin embargo, corresponde a cada país elaborar sus propias leyes sobre cómo alcanzar estos objetivos.

La directiva obliga a los Estados miembros destinatarios (uno, varios o todos ellos) en cuanto al resultado que debe conseguirse, dejándoles, sin embargo, la elección de la forma y de los medios.

El legislador nacional debe adoptar un acto de transposición en el Derecho interno mediante el que se adapte la legislación nacional a tenor de los objetivos definidos en la directiva.

Este acto de transposición es el que en esencia confiere derechos e impone obligaciones al ciudadano. Los Estados miembros disponen de facultades discrecionales en la transposición al Derecho nacional, lo que les permite tener en cuenta las particularidades nacionales.

La transposición debe efectuarse en el plazo establecido por la directiva. Al transponer las directivas, los Estados miembros deben garantizar la eficacia del Derecho de la Unión, de conformidad con el principio de cooperación leal consagrado en el artículo 4, apartado 3, del TUE.

En principio, las directivas no son directamente aplicables. Sin embargo, el Tribunal de Justicia de la Unión Europea ha considerado que, de forma excepcional, determinadas disposiciones de una directiva pueden tener efectos directos en un Estado miembro sin que sea necesario que este último haya adoptado un acto de transposición previo, siempre que: a) la directiva no haya sido transpuesta o lo haya sido de forma incorrecta; b) las disposiciones de la directiva sean incondicionales y suficientemente claras y precisas; y c) las disposiciones de la directiva confieran derechos a los individuos. Si se reúnen estas condiciones, un particular puede hacer valer las disposiciones de la directiva ante cualquier autoridad pública.

Por tanto, la directiva es de obligado cumplimiento pero no es directamente aplicable, sino que ahora España (y de igual forma cada país) debe elaborar una ley que respete, como mínimo, el alcance y los requisitos de accesibilidad estipulados en esta directiva.

La ley española deberá respetar “como mínimo” el alcance y los requisitos de accesibilidad de la directiva porque el artículo 2 lo establece así:

Artículo 2. Armonización mínima

Los Estados miembros podrán mantener o introducir medidas conformes al Derecho de la Unión que vayan más allá de los requisitos mínimos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles dispuestos en la presente Directiva.

Es decir, que la ley de un país podrá ser luego más exigente que lo estipulado en la directiva. De hecho, la propia directiva anima a ampliar su alcance.

También puede darse el caso de que en algunos casos la propia legislación del país puede ser ya más exigente que la directiva europea.

 

¿Cuánto tiempo tiene España para elaborar la ley que adapte la directiva a su legislación?

Los Estados miembros tienen un plazo estipulado para llevar a cabo la adaptación de la directiva, en caso contrario, la Comisión abrirá un procedimiento de infracción:

Cuando un país no transpone una Directiva, la Comisión puede incoar un procedimiento de infracción e instruir un procedimiento contra el país ante el Tribunal de Justicia de la UE (el incumplimiento de la sentencia dictada con este motivo puede derivar en una nueva condena que puede concluir en la imposición de multas).

En Directivas de la Unión Europea, Eur-lex

En consecuencia, podemos estar bastante seguros de que la directiva será transpuesta a nuestra legislación para evitar sanciones. El plazo que estipula la directiva para ello es el 23 de septiembre de 2018:

Artículo 12. Transposición

Los Estados miembros pondrán en vigor a más tardar el 23 de septiembre de 2018 las disposiciones legales, reglamentarias y administrativas necesarias para dar cumplimiento a lo establecido en la presente Directiva. Informarán inmediatamente de ello a la Comisión.

¿Cuándo deben empezar los sitios web y apps del sector público español a cumplir con la directiva?

En primer lugar, como hemos visto, deberemos esperar a que España apruebe una ley propia en la que transponga la directiva europea.

Pero la directiva ya estipula los plazos en los que entraría en vigor la obligación de cumplir con los requisitos de accesibilidad:

  • Sitios web nuevos (publicados después del 23 de septiembre de 2018): deberán ser accesibles a partir del 23 de septiembre de 2019.
  • Resto de sitios web (publicados antes del 23 de septiembre de 2018): deberán ser accesibles a partir del 23 de septiembre de 2020.
  • Aplicaciones para dispositivos móviles: deberán ser accesibles a partir del 23 de junio de 2021.

 

El 23 de septiembre de 2018, los estados deben haber transpuesto la directiva a sus legislaciones o de lo contrario serían sancionados.

Norma EN 301 549

La norma EN 301 549 es el estándar europeo que dicta los requisitos de accesibilidad de cualquier producto y servicio: páginas web, software incluidas apps nativas, documentos, hardware, etc.

La Directiva (UE) 2016/2102 “sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público”, establece como norma a seguir la EN 301 549.

En estos momentos, ya tenemos el borrador de la que será la próxima versión EN 301 549  (PDF). En ella se incluye un anexo A. “Relationship between the present document and the essential requirements of Directive 2016/2102”, con dos tablas:

  • Tabla A: requisitos que se aplican a las páginas web: capítulo 9 (WCAG 2.0) y capítulo 12 “Documentación y servicios de atención al cliente”, y otros capítulos condicionalmente
  • Tabla B: requisitos que se aplican a las aplicaciones móviles: capítulo 11 “Software” (WCAG 2.0 con excepciones y criterios adicionales) y 12 “Documentación y servicios de atención al cliente”, y otros capítulos condicionalmente.

 

¿Quiénes están obligados a cumplir con los requisitos de accesibilidad de la directiva?

La Directiva establece los requisitos de accesibilidad que deben cumplir los sitios web y aplicaciones móviles del sector público. NO incluye a las empresas privadas.

¿Qué se entiende por “sector público”?

Artículo 3. Definiciones

1) «organismo del sector público»: el Estado, las entidades territoriales, los organismos de Derecho público según se definen en el artículo 2, apartado 1, punto 4, de la Directiva 2014/24/UE, o las asociaciones constituidas por una o más de dichas entidades o uno o más de dichos organismos de Derecho público, si esas asociaciones se han establecido con el propósito específico de atender necesidades de interés general, sin tener carácter industrial ni comercial;

Los organismos de Derecho público se definen así en la Directiva 2014/24/UE:

4) «Organismo de Derecho público»: cualquier organismo que reúna todas las características siguientes:

a) que se haya creado específicamente para satisfacer necesidades de interés general que no tengan carácter industrial o mercantil;

b) que esté dotado de personalidad jurídica propia, y

c) que esté financiado mayoritariamente por el Estado, las autoridades regionales o locales, u otros organismos de Derecho público, o cuya gestión esté sujeta a la supervisión de dichas autoridades u organismos, o que tenga un órgano de administración, de dirección o de supervisión, en el que más de la mitad de los miembros sean nombrados por el Estado, las autoridades regionales o locales, u otros organismos de Derecho público.

Sin embargo, se establecen algunas excepciones.

NO se aplica a los siguientes sitios web y aplicaciones móviles

3. La presente Directiva no se aplica a los siguientes sitios web y aplicaciones para dispositivos móviles:

a) sitios web y aplicaciones para dispositivos móviles de prestadores del servicio público de radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan un mandato de servicio público de radiodifusión;

b) sitios web y aplicaciones para dispositivos móviles de ONG que no presten servicios esenciales a los ciudadanos ni servicios que traten específicamente las necesidades de las personas con discapacidad o estén diseñados para ello.

5. Los Estados miembros podrán excluir del ámbito de aplicación de la presente Directiva los sitios web y las aplicaciones para dispositivos móviles de escuelas, jardines de infancia o guarderías, excepto en lo relativo a las funciones administrativas esenciales en línea.

(33) Las funciones administrativas esenciales en línea de escuelas, jardines de infancia y guarderías deben ser accesibles. Cuando ese contenido esencial se proporcione de manera accesible en otro sitio web, no debe ser necesario que también sea accesible en la página web del centro de que se trate.

A pesar de ello, la directiva anima a los estados a ampliar el ámbito de aplicación de la Directiva:

(34) […] debe animarse a los Estados miembros a que amplíen la aplicación de la presente Directiva a las entidades privadas que ofrezcan instalaciones y servicios abiertos al público o de uso público, entre otros en los ámbitos de la asistencia sanitaria, la asistencia infantil, la inclusión social y la seguridad social, así como en el sector del transporte y la electricidad, el gas, la calefacción, el agua, las comunicaciones electrónicas y los servicios postales

(35) Si bien la presente Directiva no se aplica a los sitios web ni a las aplicaciones para dispositivos móviles de las instituciones de la Unión, se anima a estas a cumplir los requisitos de accesibilidad de la presente Directiva.

La legislación española ya obliga a las empresas privadas de más de 100 trabajadores o que facturen más de 6 millones de euros a tener sitios web accesibles, especialmente a las empresas “de los sectores de mayor incidencia en la actividad económica, entre otras, compañías dedicadas al suministro de electricidad, agua y gas, telecomunicaciones, entidades financieras, aseguradoras, grandes superficies, transportes, agencias de viaje” (Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información).

Habrá que esperar a la transposición de la directiva para ver si se mantienen estas exigencias extras de la actual legislación española. Esperemos que sí.

¿A qué tipo de contenidos afecta?

Se aplica al contenido de sitios web y a las aplicaciones para dispositivos móviles, cuyo alcance se concreta detalladamente en la directiva:

2) «aplicaciones para dispositivos móviles»: las aplicaciones informáticas diseñadas y desarrolladas por organismos del sector público o por su cuenta, para ser usadas por el público en general en dispositivos móviles, como teléfonos inteligentes y tabletas. No incluyen el software que controla dichos dispositivos (sistemas operativos para dispositivos móviles) ni el equipo informático;

(19) El contenido de los sitios web y de las aplicaciones para dispositivos móviles incluye la información tanto textual como no textual, los documentos y formularios que se pueden descargar, así como las formas de interacción bidireccional, como el tratamiento de formularios digitales y la cumplimentación de los procesos de autenticación, identificación y pago.

Por tanto, por si quedaba alguna duda, los PDF u otros archivos que se pueden descargar de una web deben ser también accesibles.

La directiva establece una serie de exclusiones, algunas temporales y otras permanentes, e indica que “esas exclusiones deben volver a valorarse en el contexto del examen de la presente Directiva a la luz de los futuros avances de la tecnología”.

Otras medidas para fomentar la accesibilidad

En la directiva se tratan también otras medidas:

  • fomentar y facilitar programas de formación sobre cómo crear, gestionar y actualizar contenidos de sitios web y aplicaciones para dispositivos móviles accesibles,
  • medidas de concienciación,
  • consultas periódicas por parte de los Estados miembros a las organizaciones que representan los intereses de las personas con discapacidad y personas de edad avanzada,
  • la promoción por parte de los Estados miembros del uso de determinadas herramientas de autor que permitan una mejor aplicación de los requisitos de accesibilidad,
  • la cooperación entre los Estados miembros para intercambiar buenas prácticas, o revisar el mercado o la evolución de la tecnología en materia de accesibilidad web.

 

Antes de finalizar, os dejo un resumen de las fechas importantes a tener en cuenta.

Esquema de la directiva

Año 2016 – Se aprueba y entra en vigor la directiva

  • 26 de octubre: Se aprueba la directiva
  • 2 de diciembre: Se publica en el Diario Oficial de la Unión Europea. (DOUE)
  • 22 de diciembre: entra en vigor.

 

Año 2018 – Fecha límite para la transposición nacional de la directiva

  • 23 de septiembre: transposición nacional
  • 23 de diciembre: La Comisión proporcionará modelo de declaración de conformidad, la metodología para el seguimiento y las disposiciones paera la presentación de informes.
  • Ese mismo día, los estados comunicarán el organismo de la aplicación de la directiva y del seguimiento y la presentación de informes.

Año 2019 – Obligación para los sitios web nuevos

  • 23 de septiembre: Deberán ser accesibles los sitios publicados después del 23 de septiembre de 2018

Año 2020 – Obligación para todos los sitios web

  • 23 de septiembre: Deberán ser accesibles todos los sitios web.

Año 2021 – Obligación para las apps

  • 23 de junio: deberán ser accesibles las app
  • 23 de diciembre: los estados presentarán su primer informe