Uninstallme

Desarrollo front-end, estándares web, accesibilidad y más

Cuestionando los diseños elásticos

Por kcmr, el 17 de julio de 2010 en Accesibilidad, CSS, Usabilidad

Until user agents…

Quienes suelan consultar las WCAG (Web Content Accessibility Guidelines), tendrán esta frase grabada en la memoria: Hasta que los agentes de usuario permitan…. Pues bien, estoy segura de que con la lenta agonía de Explorer 6, muchos nos habremos preguntado hasta qué punto tiene sentido seguir utilizando unidades relativas para los tamaños de fuente, ya que el resto de navegadores no tiene problemas para escalar fuentes cuando su tamaño ha sido expresado en píxeles. ¿Correcto? Pues no.

Internet Explorer no escala las fuentes en píxeles

Hace relativamente poco tiempo descubrí algo que desconocía por completo: ninguna versión de Internet Explorer escala las fuentes cuyo tamaño ha sido expresado en píxeles:

Es fácil no darse cuenta de este detalle porque cuando utilizamos la combinación de teclas Ctrl + o Ctrl – en Explorer (versiones superiores a la 6), activamos el zoom de página con resultados aparentemente similares a los que obtendríamos aumentando el tamaño de fuente, por lo tanto, sigue teniendo sentido utilizar unidades relativas para los tamaños de fuente.

Zoom de página y escalado de texto

Ahora bien, ¿hasta qué punto es correcto utilizar unidades relativas para todo? La mayoría de navegadores actuales, <ironia>excepto Explorer 6</ironia>, nos proporcionan inteligentemente dos formas de zoom: zoom de página completa o ampliar sólo texto.

Escalado de texto en Firefox

Escalado de texto en Firefox

Google Chrome y Opera sólo proporcionan zoom de página completa. Parece que a algunos usuarios de Chrome están algo descontentos: Need a text-only Zoom.

Teniendo en cuenta que la resolución mayoritaria, en portátiles y ordenadores de sobremesa, sigue siendo de 1024, y que las páginas se diseñan para esta resolución, en el momento en que hacemos zoom de página completa aparecen las molestas barras de scroll horizontales.

Si nuestro diseño es elástico, es decir, los tamaños de bloques contenedores se expresan en emes, estamos rompiendo la capacidad del navegador de ampliar sólo texto o hacer zoom de página, ya que al ampliar sólo texto aumentarán también los tamaños de bloques con las consecuentes barras de scroll horizontales, y si hay algo cierto, es que a nadie le gusta el scroll horizontal.

“Low-vision users don’t like horizontal scrolling.” I’ve not done extensive research in this area myself, so it’s hard to counter-argue. Besides, it’s safe to say nobody — good vision or not — likes horizontal scrolling.

We found during usability testing for a site with a large proportion of users with vision problems that most of them preferred to use text zoom instead of page zoom because page zoom almost always means horizontal scrolling.

¿La mejor elección de diseño?

Quizá el diseño perfecto sea el híbrido líquido-elástico (vaya nombrecito), pero es difícil de llevar a cabo y no está libre de problemas. Opera y Webkit (Safari / Google Chrome) comparten un bug: ignoran los decimales en porcentajes. (Demo del bug). Explorer tampoco se lleva especialmente bien con los porcentajes.

CSS 3 nos brinda nuevas posibilidades que nos permiten adaptar el diseño en función de la resolución de pantalla, las Media Queries, opción que podemos usar ya para los navegadores que pueden beneficiarse de ello, especialmente para iPhone y otros dispositivos móviles.

Mi elección

Personalmente, llevo una temporada utilizando la opción de expresar los tamaños de bloques en píxeles y los de fuentes en emes, siendo consciente de que el uso de píxeles está penalizadísimo, tanto por revisores automáticos de accesibilidad como humanos, e incluso diría que mal visto entre maquetadores, pero las “normas” siempre hay que cuestionárselas para llegar a mejoras. Como ejemplo, muchas de las pautas que se cuestionaban de las WCAG 1 en las Samuray Errata, se han modificado en las WCAG 2.

Qué dicen las WCAG

En las WCAG no se dicta una opción concreta a utilizar en cuanto a tipo de diseño, simplemente se ofrecen unas pautas y una serie de técnicas para ayudarnos a conseguirlas. Algunas de estas técnicas:

Using percentage values in CSS for container size

The objective of this technique is to make it possible for users who need to increase the size of text in order to read it will not have to scroll horizontally in order to read a line of text.

Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized

The purpose of this technique is to ensure that CSS is used in a way that allows users to view content in such a way that line length can average 80 characters or less. [...] This technique also allows for column width to grow wider as font sizes increase, which will reduce the possibility of clipping as the text size increases..

En ningún momento se propone la técnica de usar unidades absolutas para contenedores, sino más bien todo lo contrario. Si no me equivoco, tampoco se prohibe o desaconseja expresamente el uso de píxeles para contenedores, simplemente se insiste en que el texto pueda escalarse sin que aparezca cortado y a ser posible, sin que sea necesario utilizar el scroll horizontal para leer una línea completa.

Conclusión

Ahí están los problemas de los diseños elásticos y algunas de las recomendaciones para cumplir con las pautas de accesibilidad para que cada uno elija la opción más apropiada, teniendo siempre en cuenta el púbico objetivo de una web y las capacidades de los navegadores más usados en cada momento.

Más información

2 Comentarios

El uso del pseudoprotocolo (href="javascript:nombreFuncion();") en enlaces es una mala práctica de acuerdo con las normas del Javascript no intrusivo. Los enlaces deben tener una url válida que funcione sin Javascript. Por ejemplo, un enlace que abre una popup debe tener una url en su atributo href, de manera que sin Javascript siga siendo un enlace válido.

Pero no todos los enlaces que ejecutan alguna función Javascript tienen que tener una url en su atributo href. Algunos sirven para realizar acciones dentro de la propia página, como puede ser mostrar / ocultar una capa, pasar a la imagen siguiente en un carrusel, etc.

En estos casos, lo correcto es crear esos enlaces con Javascript, ya que sólo con Javascript habilitado tienen sentido (no deben estar previamente en el código HTML), y asignarles como atributo href una almohadilla (#) o dejarlo vacío.

En algún blog que no consigo encontrar proponían usar para este tipo de enlaces el pseudoprotocolo javascript: u otro que consideremos más apropiado (inventado), como podría ser imagen:.

De esta forma, estos enlaces proporcionan información acerca de su función al hacer rollover sobre ellos o cuando tienen el foco. Esta información suele aparecer en la barra de estado del navegador. También es útil para usuarios de lectores de pantalla que puedan tenerlos configurados para no leer el atributo title.

Atributo href del enlace mostrado en la barra de estado de Firefox

Atributo href del enlace mostrado en la barra de estado de Firefox

Habrá quien se preguntará si es correcto asignar este tipo de funciones a enlaces en lugar de a otros elementos HTML. La respuesta es que sí, ya que los enlaces pueden tener de forma natural el foco y ser activados cuando se utiliza el teclado para navegar y moverse por la página.

Sin comentarios

El uso de iconos de banderas para la elección de idioma en un sitio web plantea una serie de problemas, tanto de usabilidad como de accesibilidad, que no lo hacen recomendable. Si buscamos un poquito en Internet y le damos un par de vueltas podemos ver que no es una buena idea y sin embargo, su uso es tan frecuente que es fácil caer en este error de diseño.

Algunos problemas del uso de banderas

Usar sólo iconos de bandera (sin texto)

Como dice Roger Johansson en Indicating language choice: flags, text, both, neither?, usar sólo una bandera es un big no-no! (Me gusta esta expresión!)

Anteriormente comenté en este blog los problemas de usar sólo iconos como enlaces, llegando a la conclusión de que los iconos siempre deberían ir acompañados de un enlace textual, o mejor dicho, ser un complemento de este y no el elemento que transmita la mayor parte de la información.

Poniéndonos en el caso de las banderas, ¿qué ocurre si un usuario es daltónico y confunde los colores de una bandera o si simplemente desconoce a qué país representa una bandera o incluso qué idioma se habla en determinado país? Y no hace falta irse a pensar en usuarios con discapacidades de ningún tipo, simplemente en la cantidad de países cuya bandera usa tres bandas de color rojo, azul y blanco.

Como decía Johansson, a big no-no!

Icono de bandera acompañada del nombre del idioma en ese mismo idioma

Esta opción es algo mejor que la anterior pero sigue planteando problemas, como por ejemplo, el de que algunos usuarios se puedan sentir ofendidos. ¿Le agrada a un estadounidense ver su idioma representado con la bandera de inglaterra o viceversa? Pues como comentan en You should never use flags for language choice, parece ser que a algunos no.

Hmm, I DO speak English, but this is not the flag of my country. I hate when I see this!

Por si estas razones no son suficientes, tenemos un documento del W3C Working Group que sin más rodeos dice “Do not use flag icons to indicate languages.” y nos da una razón indiscutible para ello: Las banderas representan países, no idiomas.

Posibles alternativas al uso de banderas

Usar sólo texto en el idioma correspondiente

Una opción simple y sencilla que no deja lugar a dudas y no ofende a nadie, pero que tiene el inconveniente de no ser tan fácilmente localizable y reconocible como los enlaces acompañados de icono.

Un select con los idiomas disponibles

Esta opción es buena cuando hay bastantes idiomas, pero tampoco está libre de problemas. ¿Qué etiqueta usamos para el label del select? Si usamos “idioma”, ¿en qué idioma lo ponemos?
Si decidimos prescindir del label, ¿qué ponemos como opción por defecto para el select? ¿”Seleccione idioma”?

Podemos recurrir al uso de un icono como el globo del mundo o algo similar que preceda al select, pero volvemos al problema de usar sólo iconos para transmitir información. Además esto require un esfuerzo extra de interpretación.

Conclusión

Vistos los problemas y las posibles alternativas (seguro que hay más), quizá la mejor opción sea la de usar sólo texto en el idioma correspondiente (Español | English | Français) y si a pesar de todo uno se decanta por el uso de banderas, acompañarlas siempre de texto.

Más información

8 Comentarios

Acabo de descubrir varios script que hacen posible, tanto la navegación “normal” mediante el botón volver del navegador, como el añadir páginas a los favoritos o marcadores en aplicaciones AJAX. Una solución a dos de los grandes problemas de usabilidad que presentan este tipo de aplicaciones.

Dejo cuatro enlaces rápidos:

  1. HistoryManager. Funciona con Mootools.
    It solves the typical “Back-Button” and “Ajax Bookmarks” problems for accessible browsing and a better usability in Rich Internet applications.
  2. Versión de HistoryManager para Prototype.
  3. History Keeper. No utiliza ninguna librería.
  4. UpdateControls: UpdateHistory and AnimatedUpdatePanel. Para ASP.NET AJAX.

Sin comentarios

Ya sé que es una beta y que las mejoras se están haciendo por momentos sobre la marcha, pero en mis primeros días con él, como usuaria no puedo evitar echar de menos el panel de administración de WordPress 2.6

Exceptuando la facilidad de acualización de WordPress (ahora podemos hacerlo diréctamente desde el panel de administración, como con los plugins) todo lo demás me han resultado inconvenientes.

El principal inconveniente, para mi gusto, es la nueva navegación, orientada ahora en vertical. Ahora tenemos todas las opciones a menos clicks, aunque a cambio de tener diez iconos que agrupan varias acciones en el menú.

Esto implica que para ir a algunas opciones me tengo que desplazar hasta el final de la pantalla para encontrar lo que antes tenía en la cabecera.

La buena noticia es que podemos reducir el espacio vertical que ocupa este menú plegándolo, cosa que me ha costado dos días descubrir.

Icono de plegar el menú en WordPress

La mala noticia, es que una vez plegado, hay que adivinar qué representa cada icono, que como se puede ver, no siempre resulta muy claro.

Iconos confusos en el panel de WordPress 2.7

También hay que tener en cuenta que estos no serán los iconos definitivos, que se acaban de anunciar hoy en el blog de desarrollo de wordpress.

Al navegar entre páginas, no siempre se recuerdan las opciones del usuario y a veces me aparece el menú plegado, otras desplegado, vaya, cuestión de suerte.

Han tenido la delicadeza de agrupar los iconos por grupos de acciones, aunque también supone, primero darse cuenta de esta agrupación y segundo, hacer un esfuerzo mental para entender qué relación hay entre las acciones de cada grupo.

Una vez hecho este hallazgo, ya podemos acordarnos de que el primer grupo sirve para hacer cosas relacionadas con el contenido (publicación de páginas o posts, moderación de comentarios, etc.) y el segundo grupo sirve para hacer cosas relacionadas con la administración como cambiar de tema, asignar permisos a usuarios, modificar la configuración, apagar el blog… ¿apagar el blog?

Icono de administración confuso en WordPress 2.7

Ah no, que esto es la configuración y lo que parecía la configuración son las herramientas. Menos mal, que el menú desplegable (completamente inaccesible mediante teclado cuando está plegado) me lo deja todo claro.

Menú desplegable sobre el icono de configuración en WordPress 2.7

Menú desplegable del icono de herramientas en WordPress 2.7

En la última versión, han corregido la eliminación de estilos para los enlaces que tienen el foco, que aunque siguen sin su borde punteado (outline), por lo menos ahora cambian de color cuando navegamos por ellos con el teclado.

En fin, que WordPress me encanta, pero espero que corrijan algunas de estas cosas para la versión 2.7 definitiva.

Sin comentarios

Los iconos como enlaces en páginas web pueden ofrecer algunas ventajas. Dependiendo de las características del icono y del perfil del usuario, pueden ser asociados rapidamente con la acción o elemento que representan, además de ayudar a aprovechar espacios en pantalla o concentrar en un área una serie de elementos relacionados entre sí para que puedan ser localizados visualmente con facilidad. Un ejemplo de esto último podriá ser un grupo de acciones relacionadas con el documento como “enviar por correo” o “imprimir”.

Sin embargo, a la hora de codificarlos intentando ofrecer una solución accesible para todo tipo de usuarios, presentan algún que otro problema.

Sigue leyendo esta entrada »

4 Comentarios

Los menús de navegación desplegables pueden ser una solución de diseño para ahorrar espacio, sin embargo, su utilidad para el usuario es cuestionable. Siendo un poco drástica diría que no le aportan ningún beneficio, sino un click más para acceder a información que, de primeras, desconoce y no sabe siquiera si es de su interés, por lo que el usuario que navega sin rumbo fijo en busca del enlace que llame su atención, simplemente los ignorará. Hay que pensar que el usuario no tiene tanto interés en nuestros contenidos como para andar rebuscando.

Sigue leyendo esta entrada »

2 Comentarios