Uninstallme
Desarrollo frontend, estándares web, accesibilidad y más
Iniciar o detener Flash desde HTML con Javascript
Por kcmr, el 27 de Julio de 2009 en Accesibilidad, HTML, Javascript, flash
Etiquetas:Accesibilidad, flash
Es una buena práctica, sobretodo cuando se usan vídeos o animaciones flash que contengan sonido, el dejar la reproducción de la película en manos del usuario en vez de iniciarla automáticamente.
Las veces que esto se cumple se suele hacer colocando un control en la propia película flash, como un icono de Play o similar semitransparente.
El uso exclusivo de este método puede suponer un problema para usuarios de navegadores que no sean Internet Explorer y no utilicen ratón, ya que los flashes no pueden recibir el foco mediante teclado a no ser que se activen previamente con el ratón.
Incluir además unos enlaces en HTML para iniciar o detener la reproducción de Flash supondría una pequeña mejora de accesibilidad para estos usuarios.
Los pasos que hay que seguir para conseguirlo son:
- Dar un ID al object que contiene el Flash
- Detener la reproducción automática de la animación:
- Si la animación está en la línea de tiempo principal basta con usar el parámetro play con el valor false en el HTML
- Si la animación está en otra línea de tiempo tendremos que detenerla en el propio flash mediante un nombreDeInstancia.stop() en la línea de tiempo principal.
- Asignar la función de iniciar / detener a los enlaces correspondientes en HTML
Ejemplos de los dos casos
Object película Flash con animación en la línea de tiempo principal
HTML del flash
<object width="155" height="17" id="ejemplo-1" type="application/x-shockwave-flash" data="ejemplo.swf">
<param name="src" value="ejemplo.swf" />
<param name="play" value="false" />
</object>
Controles HTML (lo ideal para una degradación elegante sería pintarlos con Javascript, ya que sólo con Javascript habilitado pueden funcionar)
<ul id="controles-1">
<li><a href="#">Iniciar reproducción</a></li>
<li><a href="#">Pausar reproducción</a></li>
</ul>
Javascript
var control1 = document.getElementById('controles-1').getElementsByTagName('a');
control1[0].onclick = function(){
document.getElementById('ejemplo-1').Play();
return false;
}
control1[1].onclick = function(){
document.getElementById('ejemplo-1').StopPlay();
return false;
}
Demo
Object película Flash con animación en una línea de tiempo distinta a la principal
HTML del flash
<object width="165" height="48" id="ejemplo-2" type="application/x-shockwave-flash" data="ejemplo-2.swf">
<param name="src" value="ejemplo-2.swf" />
</object>
Javascript
En este caso, para iniciar o detener la animación tendremos que usar los métodos TPlay("ruta_a_linea_tiempo") y TStopPlay("ruta_a_linea_tiempo")
var control2 = document.getElementById('controles-2').getElementsByTagName('a');
control2[0].onclick = function(){
document.getElementById('ejemplo-2').TPlay("_root/mc_barra");
return false;
}
control2[1].onclick = function(){
document.getElementById('ejemplo-2').TStopPlay("_root/mc_barra");
return false;
}
Demo
Existen otros métodos predefinidos útiles para controlar la reproducción de una película Flash, como Rewind() o GotoFrame()
Aprovecho este post para recomendar un par de recursos que pueden sernos de gran utilidad a la hora de mejorar la accesibilidad de vídeo Flash (ya que por la página de recursos no se pasa ni GOOGLE):
- JW Player Controls
- Reproductor de Flash Vídeo que permite controlar la reproducción mediante teclado, añadir subtítulos y descripciónes de audio y además añade los atributos apropiados ARIA. Utiliza JW FLV Player junto con un plugin de accesibilidad. Los controles javascript se proporcionan mediante la librería Dojo.
- Ejemplos de control del reproductor JW Player mediante Javascript
- Varios ejemplos de control de la reproducción de contenido multimedia mediante Javascript usando JW Player.
Más información
Habilitar el botón volver del navegador en aplicaciones AJAX
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:
- 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.
- Versión de HistoryManager para Prototype.
- History Keeper. No utiliza ninguna librería.
- UpdateControls: UpdateHistory and AnimatedUpdatePanel. Para ASP.NET AJAX.
Un bookmarklet para superar el CSS Naked day
Por kcmr, el 9 de Abril de 2009 en Accesibilidad, Buenas ideas, Utilidades
Etiquetas:Accesibilidad, bookmarklets, legibilidad, tipografía, Usabilidad
Yo también me he sumado a esta iniciativa de dejar la web en pelotas, que pretende promover el correcto uso de Estándares Web y marcado semántico. Es el CSS Naked Day.
Me tengo que decir eso de “bueno, un día es un día” para tener la conciencia más tranquila, ya que aunque todo permanece perfectamente utilizable y comprensible sin estilos, la verdad sea dicha… resulta bastante incómodo de leer.
Una buena forma de superarlo, sobretodo cuando tenemos verdadero interés en leer algo, cosa que debe de ocurrir sólo durante un 5% del tiempo en que navegamos, es utilizar un bookmarket que aplica los estilos necesarios para mejorar la legibilidad a la parte de la página que contiene el contenido relevante, ocultando todos los demás elementos que pueden distraer la lectura, como banners, menús de navegación, etc. Se trata de Readability. En su web podemos elegir el estilo que más nos gusta entre varias opciones y una vez configurado, añadir el marcador al navegador.
Es un bookmarklet bastante útil y cómodo, no sólo para superar el día de hoy, sino para cuando nos encontramos con un tamaño de texto diminuto o longitud excesiva de líneas, dos cosas que dificultan y hacen poco apetecible la lectura.
Flash navegable mediante teclado en Firefox
Por kcmr, el 3 de Marzo de 2009 en Accesibilidad, Buenas ideas, Navegadores
Etiquetas:Accesibilidad, flash
Sí Flash ya es de por sí bastante problemático en cuanto a accesibilidad se refiere, en Firefox tiene una dificultad añadida: no se puede acceder a su contenido mediante teclado. Para navegar por los elementos de un flash en Firefox necesitamos clicar el flash. Una vez que hemos entrado ya no podemos salir usando el teclado, la tabulación queda atrapada en el flash. La buena noticia es que si hemos podido entrar en el flash, se supone que sólo hemos podido hacerlo mediante ratón, por lo que también se supone que también podremos salir del flash usando el ratón, a no ser que justamente decida fallar en ese preciso momento. En cualquier caso, este comportamiento de Flash en Firefox hace que sea dependiente de dispositivo.
No ocurre lo mismo en Internet Explorer, en el que sí podemos entrar y salir del Flash mediante teclado. Podemos imitar el comportamiento de Flash en Internet Explorer mediante Javascript y Actionscript. En el siguiente ejemplo tenemos un flash al que podemos acceder mediante teclado en Firefox, navegar por sus elementos y salir de él.
Para conseguir esto se han seguido los siguientes pasos:
- Dar un tabindex con valor 0 al object que contiene el flash.De esta manera conseguimos que pueda tener el foco en Firefox. El valor 0 permite que el objeto permanezca en el orden de tabulación en que aparece en la página, es decir, no se altera el orden de navegación de otros elementos. Debemos hacerlo mediante Javascript, porque sin él, podríamos entrar mediante teclado al flash pero no podríamos salir.
- Permitir la comunicación del Flash con Javascript.Para esto usamos el parámetro allowscriptaccess de Flash
<param name="allowScriptAccess" value="always" /> - Desde Flash llamamos a la función Javascript encargada de establecer el tabindex, de esta manera, sólo si hay flash se establecerá un tabindex para el object.
- Añadimos para el primer y último elemento navegables del flash una función para el evento onblur (en actionscript llamado onKillFocus) encargada de llamar a la función Javascript que desenfoca el object.
// primer elemento navegable bot_1.onKillFocus = function(newFocus){ if(newFocus == bot_3){ ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test'); } } // último elemento navegable bot_3.onKillFocus = function(newFocus){ if(newFocus != bot_2){ ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test'); } } - Por último, para evitar el “click para activar” en Explorer, se ha usado el método de publicación dinámica del SWFObject.
Descargar todos los archivos del ejemplo, incluido el .fla, en formato .zip
Una buena parte del “cómo conseguirlo” surgió de una cabeza inquieta de mi antiguo curro y creo, que hasta aquí puedo y debo leer.
El debate del H1
Por kcmr, el 8 de Febrero de 2009 en Accesibilidad, Cajón de sastre, HTML
Etiquetas:Accesibilidad, curiosidades
Si no teníamos suficiente con el típico debate sobre usar uno o varios encabezados de primer nivel, ahora tenemos otro para la colección: ¿H1 para el título principal de la página o para el logo del sitio?
La cosa llega al extremo de tener su propia web, en la que podemos ver los argumentos y votos dados a través de Twitter (me temo que nunca participaré.)
De momento va ganando la opinión de usar H1 para el título principal de la página. Yo comienzo a pensar que da un poco igual mientras se hayan hecho otras cosas bien, como usar un título (elemento <title>) descriptivo y una jerarquía de encabezados con sentido.
Preferencias y modos de uso de lectores de pantalla
Por kcmr, el 1 de Febrero de 2009 en Accesibilidad, Haciendo amigos, Navegadores, Programas
Etiquetas:Accesibilidad, aplicaciones, web 2.0
Hace cosa de un mes, WebAIM comenzaba a hacer una encuesta sobre el uso de lectores de pantalla, con el objetivo de mostrar las preferencias de usuarios reales y dar un poco de luz a los desarrolladores que normalmente nos basamos en suposiciones a la hora de intentar proporcionar páginas accesibles para este tipo de usuarios.
Ayer se publicaban los resultados, tras realizar la encuesta a un total de 1121 usuarios. A continuación muestro un resumen de cada punto que se analizó en la encuesta.
Datos sobre el tipo de usuario
La mayoría de las personas encuestadas eran usuarios habituales de lectores de pantalla (los usan siempre) debido a alguna discapacidad, de entre las que se dan con más frecuencia, están la ceguera o baja visión.
Sólo una pequeña parte de los encuestados, el 8%, se ha declarado usuario principiante, mientras que la mayor parte se considera usuario avanzado.
El programa más usado con clara diferencia es JAWS con un 74%, seguido de Windows Eyes con un 23%. También la mayoría de estos usuarios utilizan la versión más reciente de su programa.
También es muy interesante saber que los usuarios de lectores de pantalla sí personalizan sus programas y cambian las configuraciones por defecto.
Los navegadores más usados son, en primer lugar Internet Explorer 7 con un 68%, seguido de Firefox con un 39% y Explorer 6 con un 33%
Datos sobre el uso de páginas web
¿Qué hacen cuando llegan por primera vez a la home de un sitio desconocido?
La mayoría prefiere leerla entera y otra parte importante prefiere navegar a través de los enlaces de la página.
¿Se usan los links de saltar al contenido y los accesos directos?
En este caso no hay una tendencia que destaque sobre las otras, ya que casi en proporciones iguales se dan los casos en que estos links se usan siempre que existen, se usan a veces, muy raras veces o nunca. Tampoco hay una preferencia clara en cuanto a cuál debería ser el texto del enlace, si bien el 28% prefiere el literal "saltar al contenido principal".
Lo mismo ocurre con las teclas de acceso directo, los accesskeys, aunque en la página nos aclaran que los principiantes en el uso de lectores de pantalla parecen tener más tendencia a usarlas.
Encabezados
En este caso sí que se ve una tendencia clara a navegar por encabezados siempre que están disponibles. Un 52% eligió esta opción y sólo un 7% en total eligieron las opciones de muy raras veces o nunca.
Formularios de búsqueda
La mayoría de los encuestados mostraron tendencia a usarlos o siempre que existen, o con cierta frecuencia, mientras que sólo un 15% dijo usarlos pocas veces o nunca. En WebAIM aprovechan estos resultados para remarcar la importancia, no sólo de proporcionar estos formularios, sino de hacerlo de una forma en la que resulten fáciles de encontrar y usar.
¿Y cómo encuentran el formulario de búsqueda?
La mayoría lo intenta dirigiéndose al primer elemento FORM de la página o al primer cuadro de edición de texto. Una pista clara para saber dónde colocar estos elementos, tan fácil como no intentar reinventar la rueda.
Mapa Web
No parece haber una tendencia clara sobre el uso de los mapas web, si bien se puede extraer la conclusión de que no son muy usados por los usuarios de lectores de pantalla.
¿Se usan las versiones de sólo texto?
En este caso se muestran dos tendencias opuestas: o usarlas siempre que están disponibles o no usarlas casi nunca.
Dificultad de los pop ups
También en este caso los resultados son muy variados. Un 43% en total dice que los pop ups no le resultan muy difíciles, mientras que un 53% parece encontrar dificultades en el uso de pop ups. El análisis detallado de los resultados muestra una relación directa entre la experiencia en el uso de lectores de pantalla y la dificultad que se encuentra en estos elementos, que como es lógico, es mayor en usuarios principiantes de lectores de pantalla.
Accesibilidad de la Web 2.0 y las aplicaciones web dinámicas
Un 54% respondía "no lo sé".
Yo personalmente interpretaría los resultados como "¿Web 2.0? ¿Qué es eso?" y creo sincéramente que la gente de WebAIM le ha echado cierta imaginación al decir que los usuarios de Firefox parecen tener más tendencia a mostrar una respuesta favorable, quizá motivada por el soporte de ARIA en Firefox. Mi opinión es que WAI-ARIA se usa muy minoritariamente y, a pesar de que Firefox tenga soporte, el comportamiento de JAWS ante eventos javascript en este navegador es peor que en Explorer e incluso algo frustrante. Esto es lo yo veo como la triste realidad.
Imágenes decorativas
Aquí aparece un resultado curioso. Las WCAG nos dicen que proporcionemos un alt vacío para las imágenes meramente decorativas, pero los usuarios de lectores de pantalla prefieren mayoritariamente, con un 59%, que sean descritas. Parece que los usuarios más avanzados son los que prefieren encontrar descripciones para estas imágenes, quizá debido a que estos usuarios son más hábiles a la hora de ignorar la información no deseada.
Identificación de fotografías
Para la pregunta "Si la página web contiene una foto de la Casa Blanca, prefiero que la imagen sea identificada como…", un 80% eligió el literal "Foto de la Casa Blanca".
Desde WebAIM nos aclaran que no debemos interpretar este resultado como que todas las imágenes deben ser identificadas como imágenes, es decir, no debemos usar el lireral "Imagen de..", que resulta redundante, ya que el propio lector de pantalla notifica las imágenes como tal.
Identificación de logos
En cuanto al logo con enlace a la home, la mayoría prefiere que sea descrito como "Logo de -nombre del sitio- con enlace a la home".
Parecen ser los usuarios con discapacidades y los más experimentados los que prefieren una descripción más breve.
Múltiples enlaces a distintos sitios con el mismo texto de enlace
Con este tipo de enlaces hacen referencia a los típicos enlaces de "más información" o "ver más" que se repiten a lo largo de una página web.
Casi a partes iguales se dieron las respuestas de encontrar difíciles estos enlaces como encontrarlos fáciles. Nuevamente hay una relación directa entre la experiencia del usuario y la dificultad que encuentra en estos elementos.
Flash
En este caso sí que se ve una tendencia clara a encontrar el contenido Flash difícil o muy difícil. Nada sorprendente.
Marcos
Otra vez nos encontramos a partes iguales con los usuarios que los encuentran fáciles y los que los encuentran difíciles.
En WebAIM nos aclaran que no se hizo distinción entre frames e iframes.
Se vuelve a repetir una igualdad entre usuarios que lo encuentran fácil y usuarios para los que resulta difícil.
Conclusión
La conclusión que se puede sacar de los resultados de la encuesta es que no existe una formula perfecta que pueda satisfacer por igual a la variedad de usuarios que usan lectores de pantalla y es difícil ofrecer recomendaciones definitivas para muchas cosas, si bien hay puntos que parecen quedar muy claros, como la dificultad del uso de Flash o la importancia de proporcionar encabezados que describan el contenido al que preceden.
Fuente
Encuesta sobre preferencias de usuarios de lectores de pantalla en WebAIM
Ocultación de elementos con la carga del DOM sin usar librerías
Por kcmr, el 11 de Enero de 2009 en Accesibilidad, Buenas ideas, Javascript
Etiquetas:Accesibilidad, DOM, Javascript
Como ya he comentado más de una vez por aquí, cuando necesitamos ocultar un elemento HTML para mostrarlo u ocultarlo mediante Javascript (un menú desplegable, una capa colapsable, etc), no debemos ocultarlo previamente en el HTML, ya que ese elemento deberá permanecer visible cuando no haya Javascript.
Para ello se pueden utilizar varias técnicas como ocultar estos elementos mediante Javascript añadiendo el estilo display: none, (sí, en la mayoría de casos no será incorrecto que el elemento oculto también lo esté para lectores de pantalla), o bien añadiendo una clase “oculto”, “hidden” o similar definida en la CSS que se encargue de ocultar elementos.
El problema de esta técnica es que cuando no podemos usar alguno de los métodos que nos ofrecen las librerías Javascript para ejecutar funciones cuando el DOM está disponible (ready de jQuery, domready de Mootools o dom:loaded de Prototype), nos encontramos con el feo efecto de que nuestros elementos ocultos aparecen un instante visibles hasta que toda la página está cargada (onload).
Para evitar esto se suelen utilizar otras técnicas no muy limpias de la vieja escuela, como colocar el código Javascript en el HTML, o lo que es peor, usar estilos en línea en la capa o elemento que se ha de ocultar.
Pues bien, gracias a Scriptia, descubro este otro método para ocultar elementos que se basa en añadir una clase al elemento HTML mediante la propiedad documentElement del objeto document. Y cito lo que nos comenta Choan sobre document.documentElement:
- Para modificar ‘document.documentElement’ no es necesario esperar a que se complete la carga del documento.
- La especificación HTML 4.01 no permite el uso del atributo ‘class’ en el elemento ‘html’. En mi opinión, como la jugada la hacemos por scripting, esto no invalida el documento.
Para utilizarlo nos propone usar una variable en la que detectamos el soporte del DOM por el navegador:
var isSupported = document.getElementById && document.getElementsByTagName;
Y una sencilla instrucción:
if (isSupported) {
document.documentElement.className = "js";
}
Por último, para evitar tener rondando por ahí una variable global, podemos colocarlo todo dentro de una función anónima autoejecutable, o lo que también se conoce como closure, si no estoy equivocada:
(function(){
var isSupported = document.getElementById && document.getElementsByTagName;
if(isSupported){
document.documentElement.className = "js";
}
})();
En la CSS aplicaríamos el display none sólo a los elementos hijos de los que tienen la clase “js”:
.js .oculto{ display: none; }
He probado esta técnica en una página en la que he usado 4 imágenes pesadas, para comprobar que la capa que se oculta mediante Javascript, efectivamente lo hace sin necesidad de que la página esté cargada y ¡funciona!
Demo ocultación de elementos mediante javascript.
Por si alguien se pregunta quién va por el mundo con Javascript deshabilitado, no hace falta irse a buscar al usuario de Lynx o a ese otro que por alguna extraña razón decide rebuscar la opción de deshabilitar Javascript en su navegador aunque no sepa lo que es ni le importe. El individuo que va por ahí sin Javascript existe y puede ser perfectamente un usuario avanzado que usa un lector de feeds, un móvil con soporte limitado de Javascript, o ve una web desde su cliente de correo.
Diseños elásticos, Internet Explorer y font-size
Por kcmr, el 7 de Enero de 2009 en Accesibilidad, CSS
Etiquetas:Accesibilidad, CSS, css bugs, font-size, How to, ie bug, internet explorer
Los diseños elásticos en CSS son aquellos en los que se utilizan unidades relativas para las medidas de fuentes y capas contenedoras de manera que, manteniendo la apariencia y ventajas de los diseños fijos frente a los diseños líquidos, permiten redimensionar el tamaño de todos los elementos de la página al aumentar o disminuir el tamaño de fuente en el navegador.
Este comportamiento es posible gracias a la utilización de emes como unidad de medida para definir las dimensiones de todos los elementos de la página. Las emes son una unidad relativa, es decir, no se puede decir que tengan una equivalencia en píxeles de por sí, sino que su valor depende del tamaño de fuente del elemento en base al que son declaradas.
Por suerte, el tamaño de fuente por defecto en todos los navegadores (creo que esto no siempre ha sido así), es de 16 píxeles, con lo que a partir de esto se puede decir que 1em = 16px.
Calcular tamaños relativos a 16 píxeles no es nada apetecible, sin embargo, calcular tamaños en base a 10 píxeles es tan sencillo como dividir la medida en píxeles por 10, de manera que lo que en píxeles son 400, en emes sean 40.
Con el objetivo de establecer el valor de 1em en 10px, surge esta conocida regla:
body{ font-size: 62.5%; } // 100% = 16px => 62.5% = 10px
Y ya tenemos la equivalencia deseada de 1em con 10px en todos los navegadores. En todos menos en Internet Explorer (todas las versiones, incluso el “superestándar” Internet Explorer 8 )
Toda esta explicación e introducción, probablemente innecesaria, viene a cuento de una nueva herramienta on line que he visto unas cuantas veces durante los últimos días en mis feeds. Se trata de PXtoEM.com, que se basa en la anterior regla para hacer la conversión de píxeles a emes.
Si no somos demasiado pejigueros, la regla del 62.5% es aceptable cuando sólo se van a usar emes para los tamaños de fuente, pero no es válida para hacer un diseño elástico, ya que en el momento que se empiecen a usar imágenes de fondo en capas, las cosas empezarán a no cuadrar en Internet Explorer.
¿Cuál es el problema en Internet Explorer?
Cómo comentan en un mail en la lista de correo de css-discuss.incutio.com, Internet Explorer ignora el decimal en el porcentaje (62.5%), con lo que la equivalencia conseguida es de 9.92px en vez de 10px.
Se puede comprobar utilizando una imagen de fondo en una capa a la que damos las dimensiones de la imagen de fondo. En esta página test, hay una capa con una imagen de fondo de 300 x 200 píxeles (el borde es interior). El estilo para esta página contiene solamente dos reglas:
body{ font-size: 62.5%; background: #ccc;}
.capa-test{width: 30em; height: 20em; background: url(fondo.gif) 0 0 no-repeat;}
Si vemos esta página con cualquier versión de Internet Explorer, veremos que la imagen de fondo no aparece completa, le faltan los bordes derecho e inferior.
Captura de Internet Explorer 6
Captura de Internet Explorer 7
Captura de Internet Explorer 8 Beta 2
La solución peligrosa.
Hay una solución que funciona, basada en establecer el tamaño de fuente del elemento HTML en 62.5%, el del BODY en 100% para los navegadores que no son Explorer y en 101% para Explorer, lo que supone tener que usar hacks o selectores para uno u otro navegador con los riesgos que esto conlleva. No sabemos si una futura versión de Opera, Firefox o cualquier otro navegador, soportará estos selectores CSS usados como filtros.
La solución más simple.
Si el problema de Internet Explorer es que ignora el decimal en el porcentaje, simplemente podemos solucionarlo buscando una medida redonda. Esta medida es 125%, que equivale a 20 píxeles.
Dando al BODY un font-size de 125% y al bloque contenedor de todos los elementos de la página un tamaño de fuente de 0.5em (la mitad de 20), conseguimos la equivalencia buscada de 1em = 10px sin usar hacks ni medidas erróneas.
En esta otra página test se puede ver el resultado y comprobar que Internet Explorer interpreta correctamente el tamaño de fuente. En este ejemplo se ha añadido una capa que contiene a la capa con la imagen de fondo, a la que se le ha dado un tamaño de fuente de 0.5em:
body{font-size: 125%; background: #ccc;}
#contenedor{font-size: .5em;}
.capa-test{width: 30em; height: 20em; background: url(fondo.gif) 0 0 no-repeat;}
Los resultados en Internet Explorer usando esta técnica:
Captura de Internet Explorer 6
Captura de Internet Explorer 7
Captura de Internet Explorer 8 Beta 2
Actualización (12/01/2009)
No es necesario dar un tamaño de fuente de 0.5em a la capa contenedora más externa, ya que podemos dar diréctamente el tamaño de 125% al elemento HTML y el de 0.5em al BODY. De esta forma nos ahorramos dar un tamaño de fuente para cada capa que se genere fuera del bloque contenedor, como suele ser el caso de ventanas modales, capas que contienen iconos de cargando, etc.
La CSS quedaría finalmente así:
html{ font-size: 125%; }
body{ font-size: .5em; }
Se puede ver el resultado en esta página.
Fuentes y más información
Descubriendo los códigos QR y sus posibilidades
Por kcmr, el 3 de Enero de 2009 en Accesibilidad, Buenas ideas, Personal
Etiquetas:Accesibilidad, QR-Code, tecnología, web móvil
Hace cosa de un mes descubría esto de los códigos QR. Me he sentido algo aliviada al leer este post en el blog de QR Code, ya que parece que en España nos lo estamos tomando con cierta calma y no soy la última en enterarme 
Los códigos QR pueden contener un máximo de 256 caracteres alfanuméricos. Esta información puede ser leída y decodificada por un teléfono móvil con cámara y un programa para leer estos códigos mediante una fotografía. Esto permite acceder directamente a una URL o copiar los datos de un contacto en la agenda sin tener que introducirlos manualmente.
Puedes descargar un programa para leer códigos QR compatible con tu terminal en Kaywa Reader. La web de Kaywa también ofrece un generador de códigos QR.
Código QR de Uninstallme.
En Japón, el uso de estos códigos ya está muy extendido, y no sólo es frecuente encontrarlos en cualquier cartel publicitario por la calle, sino que llegan al extremo de usarlos en lápidas para proporcionar la URL de una web con datos sobre el difunto, fotos, etc.
Aunque, como comentaba anteriormente, en España su uso no está tan extendido, ya hay quien ha visto las posibilidades de esta tecnología para ofrecer mejoras de accesibilidad a personas invidentes o con visión reducida.
Accesibilidad en edificios
Me ha llamado la atención la iniciativa del CRE de San Andrés del Rabanedo (León), de colocar estos códigos QR en las puertas del edificio con la información que normalmente suele aparecer en un cartel expresada mediante texto o símbolos. (Ejemplo: aseos de señoras.)
En este vídeo se explica cómo una persona invidente puede escuchar la información de estos códigos usando un teléfono móvil equipado con un lector de pantalla.
Tarjetas de visita accesibles
Estas tarjetas incluyen el código QR con los detalles del contacto, de manera que con hacer una foto a la tarjeta, ya tenemos registrados todos los detalles de contacto en la agenda del móvil sin escribir una sola letra y, de paso, evitando posibles errores tipográficos. Más cómodo imposible.
Otros usos
Idealista.com ofrece un servicio de generación de fichas para imprimir y pegar en farolas, cristales, etc. Estas fichas llevan un código QR con una URL en la que se proporcionan fotos y otros datos sobre el inmueble en alquiler o venta.
En la tienda on line de QR-Code, se pueden encontrar camisetas, bolsos o tazas con todo tipo de mensajes graciosos para descifrar.
A mí se me ocurren ahora mismo usos relacionados con la geolocalización (ZXing ya está incorporando esta característica en su generador de códigos.) Por ejemplo, aprovechando que muchos móviles de última generación suelen incorporar GPS, estos códigos podrían conducirnos directamente hasta un determinado restaurante o, colocados en los típicos carteles de información (“Usted está aquí”), conectarnos con un servicio que nos diga qué tenemos a nuestro alrededor en una ciudad desconocida.
Fuentes y más información
- Código QR en la Wikipedia
- Generador de códigos QR para uso personal (detalles de contacto, links, mensajes)
- Blog sobre QR en español Su generador de códigos permite generarlos en color o en formato PDF.
- Extensión para Firefox para generar códigos QR a partir de URL’s o selecciones de texto
- Los códigos QR conectan a todas las cosas