Alfonso Morcuende

Volviendo a la máxima de “Nunca te acostarás sin saber algo más”, ahora estoy realizando un curso de Accesibilidad con el CSIC, para la correcta implementación de WCAG 2.0. Bueno, el caso es que he descubierto, gracias a mis compañeros del foro, la extensión para FireFox de ColorChecker.

Lo que podemos hacer con ella es determinar concreta si los colores que estamos usando en una página Web cumple con los requerimientos de contraste en color de texto y fondo necesarios para poder cumplir con una “AA” o con una “AAA”.

Tienes varias opciones; seleccionar un elemento concreto y comprobar su contraste, el contras de la página completa, WCAG1, WCAG2.

Me ha parecido muy útil para controlar el contraste de color de una manera eurística y no como hasta ahora, que básicamente era “como Dios me de a entender”.

Desde IA nos ofrecen lo que seguro que mucha gente estaba esperando: La primera versión de un tema de OmniGraffle para los chicos que diseñen aplicaciones para el iPad. No está completa, pero plantean mantenerla actualizada a medida que vayan sacando sus propios diseños.

• Contiene backgrounds, title bars, buttons, selectors, y otros elementos de interface del iPhone
• Está basado en iPad PSD GUI creado por Teehan+Lax.
• El texto es editable en las listas, títulos, barras, botones y ruedas de scroll.

Este post no es más que una copia literal del publicado por IA. Además de este enlace me he enterado gracias a Torres Burriel, ¿Quién si no?

Me gustado mucho esta presentación, además de tener un contenido fantástico entre los que destacan:

- Para tener una sitio Web accesible es necesario involucrar a todos desde el cliente hasta el departamento de IT.

- Cuanto antes entre la accesibilidad en el proyecto, mayor será la reducción del coste del proyecto.

- Pero sobre todo me ha gustado, lo dificil que puede llegar a ser casar correctamente en un proyecto Usabilidad y Accesibilidad

La parte gráfica me ha gustado mucho por la simplicidad y lo bien que describen conceptos abstractos como los departamentos de una empresa.

Hoy tengo que preparar una presentación muy sencilla, pero muy gráfica que básicamente sea “Frase lapidaria” + “Imagen espectacular”. Así que, hoy venía preparado para buscar y rebuscar en un montón de directorios de imágenes libres de derechos, es decir, gastar un montón de tiempo en un montón de sitios Web.

Al grano, hoy al empezar a leer mis RSS me he encontrado con un post de “Utilidades para Webmasters” dónde ofrece un set de 481 fotos publicadas en Flickr, libres de derecho de autor, bueno siempre que citemos al autor: D Sharon Pruitt.

Autor que aparecerá de forma destacada en mi presentación, no os preocupéis

Ayer en el trabajo tuve que investigar un poco sobre Internet Explorer, por qué las aplicaciones que funcionan sobre este navegador funcionan más lentas o en algunos casos directamente no funcionan.

Tuve que buscar comparativas de rendimientos de navegadores y encontré una comparativa cuyos datos calqué en una presentación. A continuación pongo los puntos fundamentales de este estudio.
La velocidad de carga de nuestra página Web, está determinada por el código de nuestra página o aplicación, pero un punto determinante también será el navegador que estemos usando para cargar la página.

Las últimas pruebas realizadas a los últimos navegadores en el mercado (Mozilla Firefox 3.5, Google Chrome 3.0, Microsoft Internet Explorer 8.0, Opera 10.0, and Apple Safari 4.0) miden los siguientes indicadores:

• Velocidad JavaScript
• Uso de CPU en cargas de stress
• Selección de elementos DOM
• Velocidad de renderizado de CSS
• Tiempo de carga de Página
• Uso de Caché

Cada navegador fue testado tres veces y sus valores/resultados medios son estos:

Velocidad JavaScript

Uso de CPU en cargas de stress

Selección de elementos DOM

Velocidad de renderizado de CSS

Tiempo de carga de Página

Uso de Caché

Estos datos se realizarón sobre la siguiente plataforma:

• os: Windows Vista (32 bits)
• CPU Intel Core 2 Duo (2.16 Ghz)
• RAM 3Gb
• Equipo: Dell XP5 M1530

Estos resultados dejan a las claras que IE es el peor navegador que existe hoy por hoy en el mercado. También dejan a las claras que cualquier aplicación Web funcionará más lentamente en Internet Explorer.

Problemas específicos de nuestra página en IE

Estos datos no tendrían que suponer una demora tan importante en nuestras aplicaciones, la demora, además de estar motivada por el propio navegador, viene determinada por estos otros factores, medibles con herramientas tales como YSlow. Podéis encontrar información complementaria en español en esta entrada en microsiervos:

1. Reducir el número de peticiones HTTP
2. Usar una Red de Distribución de Contenidos (CDN)
3. Añadir la cabecera «Expires»
4. Comprimir con Gzip los componentes
5. Poner los CSS al principio
6. Mover los scripts al final
7. Evitar las Expresiones CSS
8. Hacer que los JavaScripts y CSS sean externos
9. Reducir las búsquedas en los DNS
10. Minificar los scripts de JavaScript
11. Evitar redirecciones
12. Eliminar scripts duplicados
13. Configurar los Etags

Si deseáis ampliar información sobre estos puntos. Una presentación en SlideShare que nos ayudará a entender más cosas.

Gracias a SEO Femenino he tenido acceso a un PDF oficial de Google SEO. En el que se nos informa en porcentajes, esto es lo realmente interesante, a detectar áreas dentro de nuestra página en las que podemos mejorar nuestra “optimización de buscadores”.

teniendo en cuenta sus recomendaciones podremos:

• Ayudar a nuestros usuarios a encontrar nuestras páginas en los motores de búsqueda.
• Arreglar errores que pueden molestar a nuestros usuarios, además de evitar la mala impresión que los motores de búsqueda puedan recibir de nuestras páginas.
• Servir como un buen modelo para webmasters y compañías a la hora de trabajar con sus páginas.