Uninstallme
Desarrollo frontend, estándares web, accesibilidad y más
Suavizado de fuentes embebidas mediante @font-face en Internet Explorer
Por kcmr, el 21 de Marzo de 2010 en CSS, Navegadores
Etiquetas:@font-face, internet explorer, legibilidad
Cada vez son más los sitios que usan @font-face y por fin parece que el abanico de fuentes disponibles en páginas web deja de estar limitado a Arial, Verdana, Georgia y poco más. De todos los métodos que se han usado durante años para utilizar fuentes que no son de sistema, @font-face es sin duda el más accesible, pero ¡cómo no!, la cosa no podía ser tan fácil. Una vez más es Internet Explorer el que tenía que causar algún problema.
Cuando el suavizado de fuentes mediante ClearType está habilitado en Windows o el suavizado de fuentes está desactivado por completo, Internet Explorer muestra algunas fuentes embebidas mediante @font-face con un aspecto pixelado. Si el tamaño de fuente es pequeño se empeora la legibilidad.
Suavizado de texto desactivado
Suavizado de texto mediante ClearType
Este problema no ocurre cuando está activado el suavizado estándar.
Suavizado de texto estándar de Windows
Este efecto pixelado se puede corregir mediante una técnica algo sucia. Consiste en la utilización de un filtro CSS para desactivar el suavizado de texto. Funciona porque Internet Explorer no aplica el suavizado de texto mediante ClearType a los elementos con filtros CSS propietarios.
Código CSS:
.suavizado{ filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=hIEfix.png,sizingMethod=crop);
min-height: 0;
color: green;}
Utilizando este filtro el resultado es el que se puede ver en las siguientes capturas:
Suavizado de texto desactivado. Texto verde con filtro CSS
Suavizado mediante ClearType. Texto verde con filtro CSS.
Sin embargo esta técnica tiene otro problema, y es que al hacer zoom para aumentar el tamaño de fuente, aparecen bordes negros alrededor de la fuente que nuevamente dificultan su legibilidad. Eso sí, sobre fondo negro no se aprecia este fallo, pero sobre fondo blanco nos encontramos con este aspecto:
Zoom sobre texto con filtro CSS. Legibilidad empeorada.
Si decidimos utilizar esta técnica sería recomendable ofrecer también un método para desactivarla a petición del usuario, por ejemplo mediante la adición o eliminación de una clase CSS a los elementos afectados.
Quizá con Internet Explorer 9 tengamos más suerte.
Más información en Smoother @font-face embedding in IE 7 & 8
Suavizado de imágenes redimensionadas con CSS en Internet Explorer
Por kcmr, el 5 de Noviembre de 2009 en Buenas ideas, CSS, Navegadores
Etiquetas:CSS, ie, IE 6, int, internet explorer
Cuando forzamos el tamaño de una imagen mediante CSS reduciendo su ancho o alto original, nos encontramos con que Internet Explorer hace cosas feas. A falta de palabras para describirlo, nada mejor que una captura:
Imágenes redimensionadas en Explorer 7
En el blog de ZURB, que por cierto, me encanta, nos muestran un pequeño truco para suavizar las imágenes en Internet Explorer entre otras técnicas para mejorar la presentación visual en varios navegadores
img{-ms-interpolation-mode: bicubic;}
Este método no funciona en Internet Explorer 6, para el que proponen usar algo un poco más sucio que lo anterior:
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader (src='/path/to/image.jpg', sizingMethod='scale');
Afortunadamente, Internet Explorer 8 no tiene este problema.
Demo suavizado de imágenes (sólo para IE 7)
Actualización: script para aplicar el filtro a las imágenes redimensionadas
En este comentario proponen el uso de un pequeño script en jQuery para detectar si una imagen está redimensionada y en ese caso aplicarle el estilo correspondiente para IE 7 y el filtro para IE 6. De esta forma evitamos tener código no válido en la CSS y aplicamos estos estilos sólo a las imágenes que lo requieran. Ya que el código no aparece muy bien formateado en los comentarios, lo pego aquí.
Gracias por la aportación!
jQuery.each($('img'), function() {
ancho_forzado = $(this).width();
img = new Image();
img.src = $(this).attr('src');
ancho_real = img.width;
if (ancho_forzado != ancho_real) {
if ($.browser.version.substr(0,1) == '7') {
this.style.msInterpolationMode = "bicubic";
} else if ($.browser.version.substr(0,1) == '6') {
$(this).attr('width', ancho_forzado);
this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + img.src + "', sizingMethod='scale')",
this.runtimeStyle.paddingTop = this.height,
this.runtimeStyle.height = 0;
}
}
});
En el blog de Anieto2K aparecía hace un par de días la sentencia tajante: “No uses @import“. Y sí, después de comprobar que tiene más inconvenientes que ventajas, la sentencia no es ninguna barbaridad.
Yo también uso usaba esta técnica, que vi por primera vez en la web del W3C, donde todavía la siguen usando, y la verdad es que nunca me había dado por comprobar en qué orden cargaban los archivos. Efectivamente, usando @import dentro de una CSS, la carga de los archivos no se corresponde con el orden en que se llaman desde el HTML provocando que los script carguen antes que las hojas de estilo, etc.
Dejo aquí una captura del orden de carga de archivos tomada de la web del W3C, en la que se puede ver como home-import.css no se carga en el orden que cabría esperar, aunque como comenta Anieto, tiene toda su lógica que el orden sea el que es al usar este método.
Captura del orden de carga de archivos del W3C
Un poco de historia sobre el difunto @import
El uso de @import dentro de etiquetas <style> en el HTML se utilizaba anteriormente para esconder hojas de estilo a Netscape 4, que no entendía @import, de manera que, opcionalmente se podía proporcionar una CSS con estilos básicos para este navegador mediante <link> y otra con estilos “avanzados” para los demás mediante <style> y @import. Esta técnica, cuando no se proporcionaba una CSS alternativa mediante <link>, tenía el inconveniente del instante de contenido sin estilo en Internet Explorer. Existe otra técnica con la misma finalidad que no plantea ese inconveniente, basada en especificar “all” como valor para el atributo media de la etiqueta <link> o una combinación de varios medios, ya que Netscape 4 sólo entendía el valor “screen”:
<link rel="stylesheet" type="text/css" href="css/style.css" media="screen, projection" />
A día de hoy, Netscape 4 es un navegador completamente muerto, por lo que estas técnicas también pueden pasar a la historia con él.
En cuanto a @import dentro de la CSS, me parecía una buena forma de enlazar a una sola hoja de estilo en el HTML, pero visto lo visto, también podemos decirle adiós.
Más información
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.
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
Internet Explorer 8 usará Webkit como motor de renderizado
Por kcmr, el 28 de Diciembre de 2008 en Navegadores
Etiquetas:Navegadores
Pasado el día de las inocentadas, debo advertir que este post contiene un 25% de verdad y un 25% de afirmaciones sacadas fuera de contexto. El resto es completamente falso 
Los que nos dedicamos a esto de la maquetación estamos de enhorabuena con la noticia que se hacía pública ayer en el blog de IE de MSDN, y es que Microsoft pone fin a 13 años de “maltrato” a los estándares web, apostando por Webkit como motor de renderizado para el futuro Internet Explorer 8, que se lanzará finalmente a mediados del 2009.
Los rumores sobre la adopción de Webkit para Internet Explorer 8, comenzaban hace algo más de un mes, durante una conferencia en Australia, en la que Steve Ballmer, CEO de Microsoft, afirmaba estar interesado en el Open Source, y más concrétamente en Webkit.
Finalmente se ha confirmado que Internet Explorer mantendrá su interfaz propietaria y usará Webkit como motor de renderizado:
Each browser will have its own proprietary interface, unique set of features, but at least the rendering engine will be essentially the same.
No es la primera vez que algo así ocurre en la historia de los navegadores. Netscape tuvo una iniciativa parecida con su Netscape 6, con el que se saltaron la versión 5 apostando por una renovación completa y el uso de Gecko como nuevo motor de renderizado.
Aunque la noticia es esperanzadora, la lentísima actualización a la versión 7 por parte de los usuarios de Explorer y el desatino por parte de Microsoft al usar Internet Explorer 6 como navegador para la próxima generación de móviles basados en Windows Mobile, hacen que lamentablemente, tengamos que ver el desestancamiento en la implementación de nuevos estándares web como un futuro lejano.
Recordatorio: los estándares Web sirven para…
Por kcmr, el 1 de Diciembre de 2008 en Accesibilidad, Navegadores
Etiquetas:Accesibilidad, Estándares W3C, Estándares Web, iPhone, Navegadores, web móvil, webkit
- Garantizar el funcionamiento de las aplicaciones Web independientemente del dispositivo, sistema operativo o navegador con que se acceda a ellas.
- Evitar el uso de tecnologías propietarias con la consecuente creación de múltiples versiones.
- Garantizar la compatibilidad hacia adelante y favorecer la compatibilidad hacia atrás.
Todo esto tiene los siguiente beneficios:
- Menor coste de mantenimiento (una sola versión)
- Se mejora la accesibilidad favoreciendo el acceso universal.
- Se llega a un mayor número de usuarios.
Parece que a estas alturas, después de que la mayoría hayamos aceptado y promovido el uso de estándares Web, se hace necesario recordar para qué y por qué surgieron, ya que cuando aparece en escena el navegador o móvil de moda, algunos no dudan en crear aplicaciones que funcionarán sólo en estos dispositivos y cuya clave para ser compatible con otros, dependía simplemente del uso de estándares.
Parece que no hemos aprendido nada y, como sucedió durante la guerra de navegadores, volvemos a cometer los mismos errores utilizando las extensiones no estándar que los fabricantes de navegadores, tanto los “buenos” como los que van un paso por detrás, se empeñan en seguir implementando.
Creando aplicaciones específicas para uno u otro navegador, o frameworks de desarrollo para el iPhone, estamos favoreciendo la creación de múltiples versiones y una nueva guerra de navegadores.
Es simple, ¿por qué hacerlo para uno pudiendo hacerlo para todos?
Más información
¿Qué son los estándares web y por qué debería usarlos? en The Web Standards Project
Bug de IE Tester con PNG transparente
Por kcmr, el 22 de Septiembre de 2008 en Navegadores, Programas
Etiquetas:IE 6, ie bug, internet explorer, Navegadores, Programas
IE Tester es un emulador de varias versiones de Internet Explorer cuya gran ventaja respecto a otros emuladores es la capacidad para emular IE 6 en Windows Vista.
Sin embargo tiene un pequeño problema con los PNG transparentes de 24 bits. Usemos el método que usemos para “corregir” el fallo de IE 6 con la transparencia de los PNG, si vemos una página que está en un servidor, por ejemplo un http://localhost, el PNG transparente desaparece. Esto mismo no ocurre si estamos viendo esa misma página alojada en otra ubicación, por ejemplo C:\loquesea…
Limpiar flotaciones: otro método más
Por kcmr, el 12 de Septiembre de 2008 en CSS, Navegadores
Etiquetas:CSS, firefox, How to, IE 6, internet explorer, Navegadores
Hace unos meses escribía una técnica para limpiar flotaciones en la que se usaba la propiedad display: inline-block para Internet Explorer 7. El problema de esta técnica es que se basa en un error de interpretación de este valor de la propiedad display en IE 7, por lo que pone en peligro la compatibilidad hacia adelante y obliga a usar filtros o hacks para este navegador en concreto.
Por fin, Google Chrome
Por kcmr, el 3 de Septiembre de 2008 en Navegadores
Etiquetas:firefox, Google, Google Chrome, Navegadores, webkit
Hoy ha aparecido en todos mis feeds y mañana será tres cuartos de lo mismo. Por fin, a las 2:35 de la mañana, estoy probando el navegador de Google.
Andrés Nieto ya le ha hecho un repaso completo en Probando Google Chrome, el navegador de Google