Desarrollo front-end, estándares web, accesibilidad y más
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.
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.
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
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.
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.
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.
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:
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.
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.
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.
Por kcmr, el 16 de mayo de 2010 en Accesibilidad, Buenas ideas, Javascript, Usabilidad
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
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.
Por kcmr, el 16 de abril de 2009 en Accesibilidad, Javascript, Usabilidad
Etiquetas: ajax, Javascript, RIA's, Usabilidad
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:
It solves the typical “Back-Button” and “Ajax Bookmarks” problems for accessible browsing and a better usability in Rich Internet applications.Por kcmr, el 18 de noviembre de 2008 en Haciendo amigos, Usabilidad, Wordpress
Etiquetas: Usabilidad, Wordpress
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.
![]()
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.
![]()
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?
![]()
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.
![]()
![]()
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.
Por kcmr, el 2 de octubre de 2008 en Accesibilidad, Usabilidad
Etiquetas: Accesibilidad, CSS, HTML, Navegadores, Usabilidad
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.
Por kcmr, el 8 de enero de 2008 en Accesibilidad, Javascript, Usabilidad
Etiquetas: Accesibilidad, Javascript, Usabilidad
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.