Front-end, Estándares web y Accesibilidad

Internet Explorer en su versión 6 y anteriores no soporta la transparencia del formato PNG.
Para solucionar este problema existen varias técnicas:

• A través del filtro Directx AlphaImageLoader.
• Con Behaviors.
• El conocido pngfix (con la ayuda de JavaScript).
• Algunas implementaciones pngfix para frameworks de JavaScript, como jquery.pngFix.js

Todas ellas presentan pros y contras. Dependiendo del proyecto puede que venga mejor uno u otro, o que simplemente alguno no funcione por conflictos de JavaScript o misteriosas razones que solo las meigas de IE conocen. Así que la única solución es probar y probar…

A continuación voy a desarrollar la primera de ellas.

AlphaImageLoader

#logo  { 
	background-image: none;
	filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(
		src='http://..../logo.png', 
		sizingMethod='crop'
	); 
}

El primero de los pasos es indicar que no hay ningún fondo background-image: none;, a continuación usamos filter y la llamada Directx de Microsoft para cargar imágenes que incorporan factor alfa. En el parámetro src va la ruta absoluta al fichero png.

Conflicto con los enlaces

Con lo dicho anteriormente el PNG es mostrado con transparencia y sin errores, pero los enlaces no realizan el comportamiento adecuado si se encuentran en el interior de un elemento que tenga aplicado el filtro AlphaImageLoader.

Para solucionar este último problema podemos recurrir al siguiente código CSS:

#logo a { 
	position: relative; 
	z-index: 1; 
}

Cuando se aplica un filtro el elemento tiene una posición estática y esto presenta problemas en los enlaces, por ello se fuerza por medio de CSS a que los enlaces dispongan de una posición relativa y con z-index en una capa inferior.

Solo para Internet Explorer

Otros navegadores modernos (Firefox, Opera, Safari, Chrome) soportan perfectamente el formato PNG y su grado de transparencia, por tanto sería bueno pensar en ofrecer esta técnica únicamente cuando el usuario se encuentra navegando con Internet Explorer. Para lograrlo podemos recurrir a los comentarios condicionales:

<!--[if lt IE 7]><link rel="stylesheet" href="ie6.css" mce_href="ie6.css" type="text/css" media="screen" /><![endif]-->

Mediante este comentario condicional ubicado en el head podemos indicar que solo aquellos navegadores que sean inferiores al Internet Explorer 7 [if lt IE 7] se enlace el fichero de esitlo “ie6.css” que a su vez contiene los códigos comentados para esta técnica.

De esta forma:

• No obligamos a que se interprete código propietario (no estándar) como el filtro AlphaImageLoader por parte de otro navegador que no sea IE6 o inferior.
• El sitio Web será estándar y válido según el W3C – Validator.
• Reducimos el código CSS innecesario para otros navegadores y con ello logramos una mejor optimización.

El atributo alt de una imagen u otro elemento debe proporcionar un texto alternativo que contenga la información que se pretendía transmitir. No olvidemos que la información textual es la de mayor grado de accesibilidad.

Usar textos alternativos lógicos y coherentes

• Si la imagen contiene texto, por ejemplo un número de teléfono, debemos transmitirlo completamente, alt="Teléfono: 000 000 000".
• Si la imagen es un icono de error, el texto debe transmitir esa misma idea, podemos usar simplemente alt="error".
• Si se trata de un icono “ZIP”, podemos usar algo como alt="fichero comprimido en ZIP".
• En el caso de una fotografía podemos describir lo que vemos, alt="Asturias, tierra de altas montañas".
• Si la imagen transmite acción, por ejemplo un enlace que tenga un icono de una impresora, debemos indicar dicha acción y no la descripción del icono, alt="imprimir".
• Si una imagen transmite lo mismo que un texto contiguo, debemos dejar el texto alternativo vació para no caer en redundancias, alt="".

Las votaciones

Supongamos que tenemos el clásico sistema de votaciones con estrellas:

Siguiendo las directrices de WCAG2 lo que podemos hacer es usar el atributo alt de la primera imagen para describir a todo el grupo e indicar la puntuación global. El resto de las imágenes que deberían estar situadas de forma contigua, tienen que tener alt="" vacio y no llevar ningún title, de esta forma son obviadas. Con ello se consigue que las ayudas técnicas (como por ejemplo lectores de pantalla) únicamente “lean” el texto alternativo de la primera imagen donde se da toda la información necesaria al usuario.

Ejemplo

<img src="star1.png" alt="puntuación 4 de 5" />
<img src="star2.png" alt="" />
<img src="star3.png" alt="" />
<img src="star4.png" alt="" />
<img src="star5.png" alt="" />

Los emoticonos

Se tiene que transmitir de forma textual el mismo sentimiento que el representado. Por ejemplo: alt="Feliz".

<img src="http://aurea.es/wp-includes/images/smilies/icon_smile.gif" alt="Feliz" />

Supongamos que en vez de una imagen usamos texto (ASCII). En este caso podemos marcar los emoticonos como abreviaturas (semánticamente podrían ser considerados así) y con el atributo title="sentimiento"
Por ejemplo:

<abbr title="Feliz">:-)</abbr>

En la vieja escuela estábamos acostumbrados a identificar y definir cada abreviatura y acrónimo con intención de aportar más semántica a nuestro contenido.
Usamos el atributo title con la versión textual completa, dentro de las etiquetas abbr y acronym, para explicar el término sin interrumpir el flujo del documento.

Ejemplo de abreviatura – abbr

<p><abbr title="Teléfono">Tel</abbr></p>

Ejemplo de acrónimo – acronym

<p><acronym title="Real Academia Española">RAE</acronym></p>

Abreviaturas o acrónimos en otro idioma

Si el idioma de la abreviatura o el acrónimo es diferente al del documento, se debería indicar con los atributos lang y/o xml:lang.

Por ejemplo en el caso del documento siguiente en XHTML Strict en Inglés:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en" xml:lang="en" >

El marcado de la abreviatura sería:

<p><acronym title="Real Academia Española" lang="es" xml:lang="es">RAE</acronym></p>

Y ahora viene lo bueno…

Según la nueva escuela todo es abreviatura

• Se llama acrónimo a la palabra que se forma a partir de las letras iniciales de un nombre compuesto y a veces por más letras. Por ejemplo: RADAR (RAdio-Detection And Ranging).
• Se llama sigla al término que se forma a partir de la inicial de las palabras claves que forman el título o el nombre completo de algo. Por ejemplo: RAE (Real Academia Española).

Ambos casos (acrónimos y siglas) son considerados abreviaturas y por ello en la práctica se permite usar abbr para todo tipo de formas abreviadas.

Además, en las especificaciones HTML5 y XHTML2 queda eliminado el elemento acronym a favor de estándarizar únicamente abbr.

Me parece bueno todo lo que sea ahorrar confusiones y malos usos, por eso me gusta la interpretación de la nueva escuela

* A tener en cuenta: Como no podía ser de otra forma las versiones anteriores a Internet Explorer 7 no reconocen abbr.

Hace ya un buen tiempo descubrí de forma totalmente fortuita la página web de Los colores olvidados, cuyo diseño e ilustraciones me llamaron la atención. Navegaba y babeaba al mismo tiempo. Otro claro ejemplo de que el diseño no esta reñido con la usabilidad.

Leer más »

Retomando a Lev Manovich, descubro que habló sobre la usabilidad en una entrevista publicada por ArtNodes de UOC: Definitivamente, creo que estamos en el principio.

En una de las preguntas Manovich comenta que no le gustan los defensores de la usabilidad web, pues cree que no tienen ningún criterio estético y están proponiendo algo que resulta extremadamente aburrido.

En mi opinión, no puedo estar más en desacuerdo con esta postura.
El primer pensamiento que puede tener tanto un diseñador como un usuario es que la usabilidad puede mermar la creatividad y que las convenciones de diseño que a su vez favorecen al campo de la usabilidad van en detrimento de las posibilidades creativas. Se puede llegar a pensar que incluso si seguimos todas las convenciones favorables en usabilidad acabaríamos con un diseño global homogéneo y aburrido.

Nada más lejos de la realidad. Los diseñadores siempre han estado expuestos a convenciones y también a restricciones en todos los medios de expresión, desde la pintura en lienzo al diseño web. De hecho el diseño web es diseño de interacción por lo tanto estamos expuestos a tener en cuenta la conducta humana en este medio.

Las convenciones de usabilidad y las restricciones impuestas por el diseño de interacción más que minar nuestra creatividad la agudiza, haciendo que sigamos siendo creativos pero teniendo en cuenta dichos factores.

Recuerdo una cita que lo ilustra perfectamente:
Diseño es arte optimizado para conseguir objetivos Shimon Shmueli

Inclasificable, aunque interesante lo que voy a escribir en este post sobre mis interpretaciones de Lev Manovich y la relevancia que tienen en la actualidad la socialización en internet.

Leer más »

Son como su propio nombre indica comentarios interpretados únicamente por Internet Explorer e incrustados en el código HTML, generalmente en el apartado HEAD y realizan su función únicamente si la condicional se cumple atendiendo al navegador y su versión.

Este mecanismo fue “un invento” de Microsoft (Internet Explorer), que en númerosas ocasiones no han seguido los estándares y pautas marcadas por la W3C. Mediante los comentarios condicionales podremos crear estilos propios atendiendo a las diferentes versiones de este navegador.

Las condicionales llevan un operador: “!” (negación), “lt” (menor que), “lte” (menor o igual que), “gt” (mayor que), “gte” (mayor o igual que). Con los operadores y las diferentes versiones del navegador ya podemos definir estilos atendiendo a las diferencias de cada caso.

Ejemplos

<!--[if !IE]> Cualquier navegador pero NO (!) Internet Explorer <![endif]-->

<!--[if lt IE 6]> Solo versiones MENORES de la 6 <![endif]-->

<!--[if lte IE 6]> Solo versiones MENORES o IGUAL a la 6 <![endif]-->;

<!--[if gt IE 5.5]> Solo versiones MAYORES a la 5.5  <![endif]-->

<!--[if gte IE 5.5]> Solo versiones MAYORES o IGUAL a la 5.5  <![endif]-->

CAPTION y TITLE

La etiqueta caption proporciona información sobre el contenido de la tabla al igual que el atributo <table title="">.

La única diferencia es que title no se muestra en los navegadores de pantalla (a excepción de mostrarse como tooltip o mensaje emergente). Por contra caption aparece como un texto centrado en la parte superior de la tabla.

Resulta innecesario usar ambos puesto que con uno de ellos ya aportamos la información sobre el contenido de la tabla.

SUMMARY

Podemos optar libremente por usar caption o title pero si es necesario (sobre todo por razones de accesibilidad) complementar la información con un resumen a través del atributo <table summary="">

Como resumen se debería de indicar la función informativa de la tabla, de una forma más ampliada que el caso de caption. También se puede indicar de forma muy resumida las relaciones entre las celdas.

TH

La etiqueta th sirve para identificar los grupos de encabezamiento. Las cabeceras que sirven de referencia, tanto si se trata de una disposición en columna como en filas.

SCOPE y HEADERS

Su función consiste en relacionar las celdas de los encabezados con las celdas que contienen los datos.

• El atributo scope podemos usarlo especialmente en tablas sencillas y en los encabezamientos th.
• El atributo headers cumple la misma misión pero de una forma más especifica, por ello es mejor reservarlo para tablas complejas.

Más información detallada de estos atributos en scope y headers en tablas para mejorar la accesibilidad.

En conclusión, con el uso de caption, th, thead, tbody, tfoot, colgroup, col, scope, headers, axis mejoramos sustancialmente la accesibilidad de nuestras tablas.

Hace alrededor de 2 años publique en este blog: La pirámide del diseño web, con mi idea sobre los elementos más relevantes en el proceso.

Ahora expongo una revisión de esta idea pero intentando tomar como base las premisas del DCU .

He elaborado un esquema en el siguiente documento: Diseño centrado en el usuario, una propuesta. (PDF – 188Kb)

Básicamente divido el proceso en 5 etapas:

1. Arquitectura de la información
   1. Análisis (información, objetivos, usuarios)
   2. Diseño conceptual (blueprints, wireframes)
2. Diseño
   1. Diseñó visual (mockups)
3. Desarrollo
   1. Front-end (web estática)
   2. Back-end (web dinámica)
4. Publicación
5. Mantenimiento

En la propuesta, la evaluación de interfaz/usuarios deber correr desde su inicio y en paralelo al proyecto.
Se harían interacciones de evaluación constante con los usuarios a través de: Blueprints (prototipo de baja fidelidad) > Wireframes (prototipo de media fidelidad) > Mockup (prototipo de alta fidelidad) > Web estática > Web dinámica.

Expongo a continuación algunos consejos para la optimización de nuestras hojas de estilos CSS.

1. Selectores ID, Classes, Tags

#logo { margin-top: 1em; }
.ico { margin-left: 1em; }
a { text-decoration:none; }

Los Selectores ID es la forma más eficiente y rápida que hay en CSS para otorgar estilo. Por contra no podemos sobrecargar nuestro CSS usándolos para cada elemento que requiera un mínimo de diseño. En este punto tenemos que pensar de forma creativa y global para usar los selectores de clase, las propias etiquetas y los principios de la cascada.

2. Un identificador no necesita más

h1 #logo { margin: 1em; }

Las etiquetas con un atributo de identificador son irrepetibles, solamente hay uno por página, por tanto es redundante añadir cualquier referencia adicional.
El ejemplo anterior más optimo sería:

#logo { margin: 1em; }

3. Agrupar selectores con mismas propiedades

En vez de:

h2 { font-weight: 700; }
h3 {  font-weight: 700; }
.bold { font-weight: 700; }

Mejor usar:

h2, h3, .bold { font-weight: 700; }

Este es un ejemplo muy obvio pero puede ser más complejo dependiendo del tamaño de la hoja de estilos.

4. Escribir el CSS de formas abreviada

Las llamadas Shorthand es una forma de escribir las reglas de forma abreviada, lo cual repercute directamente en la optimización (siguiendo el principio menos es más).
Este asunto lo he tratado en un post anterior llamado “Formas abreviadas para optimizar CSS“.

5. Más restrictivo a la derecha

ul li span.linklist a { border: 1px solid red; }

Ante un ejemplo como este podemos pensar que el navegador interpreta de izquierda a derecha los selectores, cuando en realidad es justamente a la inversa. Primero analiza A, luego mira que se su padre sea SPAN.linklist, su abuelo LI y su bisabuelo UL, si esto se cumple se pone la propiedad de estilo border: 1px solid red;.

El problema es que pueden existir muchas etiquetas de enlace en una página y la cantidad de proceso será mayor, por lo tanto tendríamos que poner el selector más restrictivo más a la derecha. Ante esto se me ocurren dos soluciones:

• Disminuir las descendencias, por ejemplo: span.linklist a
• Otorgar una clase a.linklist y prescindir del resto

6. Menos descendencia y más herencia

Es aconsejable no recurrir a selectores con descendencias, hijos, hermanos, etc. Siempre que sea posible usar únicamente Selectores ID, clases y etiquetas.

En cambio si es positivo heredar (inherit) el mayor número de propiedades posibles entre diferentes elementos. Tengamos en cuenta también la herencia por defecto para no escribir reglas redundantes.

7. Poner el CSS en HEAD

El situar los estilos en el HEAD hace posible que la página muestre el contenido-estilo de forma progresiva, lo que mejora la experiencia de uso.

Por otro lado la especificación HTML también recomienda la etiqueta LINK dentro del HEAD para incorporar nuestras hojas de estilo.

8. CSS como fichero externo (style.css)

Esto hace que la cache pueda hacer su trabajo, de lo contrario si incorporamos el CSS en linea, será descargado una y otra vez con la página.

Otra ventaja es la mejora en la escalabilidad pudiendo gestionar todos los estilos y el diseño de una forma más centralizada.

9. LINK mejor que @import

En algunas versiones de IE usar @import es parecido a usar LINK fuera de HEAD, por esta razón y teniendo en cuanta lo dicho anteriormente, es recomendable usar un enlace al fichero y no importarlo.

Más información en Don’t use @import.

10. Minimizar el número de peticiones LINK

Supongamos el siguiente ejemplo:

<link rel="stylesheet" href="style1.css" type="text/css" media="screen" />
<link rel="stylesheet" href="style2.css" type="text/css" media="screen" />

En el fichero style2.css a penas hay unas pocas lineas de código y su gestión no lleva a confusiones, entonces es mejor tener un solo fichero style.css con todas las reflas CSS, reduciendo el número de peticiones LINK al servidor.

En este sentido tener en cuanta también la modularidad, pueden existir ficheros CSS que por esta razón es mejor mantenerlos bien separados y organizados.

11. Evitar las “CSS Expressions”

No son estándares y se procesan repetidas veces para establecer sus propiedades dinámicas.
En No me gustan las CSS Expressions planteo algunos problemas que derivan en la falta de optimización.

12. Evitar filtros

Siempre que sea posible evitar el uso de filtros como por ejemplo “AlphaImageLoader“, estos filtros consumen una gran cantidad de memoria para su funcionamiento.

Herramientas para la optimización y compresión

Existen muchas, pero las que más uso son:

• CleanCSS – Limpiar y optimizar nuestras hojas de estilo
• Firebug + PageSpeed + YSlow
• YUI Compressor

Las dos primeras te ayudarán a chequear y encontrar mejores formas de optimización, la tercera se encarga de comprimir el fichero CSS.

La experiencia hace que en cada proyecto tengamos menos trabajo que optimizar e invertir menos tiempo delante de estas herramientas.

Por cierto, ¿se os ocurren más formas para optimizar CSS?