Imaginemos por un momento que estamos en un aeropuerto. Aviones aterrizan y despegan con total coordinación. Los vuelos de decenas de compañías en ese aeropuerto se encuentran organizados y sincronizados con los de otros aeropuertos en el resto del mundo.

La torre de control aéreo recibe información de todas partes y toma las decisiones que le son entregadas a los pilotos para que todo se realice sin inconvenientes. Esto es mediator.js, una pequeña clase JavaScript que centraliza la comunicación y nos permite crear canales por los cuales se puede enviar o recibir información, sin tener que preocuparnos por el sincronismo del código que escribamos.

Cómo utilizarla

La forma de uso es muy sencilla: se crea un canal de datos con un nombre a nuestra elección. Luego, podemos elegir que parte del código va a utilizar ese canal, indicando si vamos a enviar datos (publicando en el canal) o sólo nos prepararemos a “escuchar” (suscribiendonos al canal) la información que pueda llegar a través de ese medio.

Para lograr esto, mediator.js nos provee de 4 métodos básicos en su API:

• publish: nos permite publicar información en un canal determinado, sin tener que preocuparnos por quién se encargará de hacer llegar esa información a los suscriptores.
• subscribe: a simples rasgos nos permite decir a qué canal de información nos suscribiremos y qué elegimos hacer con lo que recibamos allí.
• remove: nos permite eliminar un canal de información, para romper el lazo entre quien publica y sus suscriptores
• once: nos permite suscribirnos a un canal de información pero, esta vez sólo recibirá datos por única vez. Luego eliminará su suscripción.

Ejemplo

Para entender mejor el funcionamiento, podemos ver el ejemplo que propone Jack Lawson en la web oficial de esta clase:

var mediator = new Mediator();

// Muestra un alert box con los datos cuando el mensaje es publicado en el canal
// Subscribe retorna el objeto "Subscriber"
mediator.subscribe("message", function(data){ alert(data); });
mediator.publish("message", "Hello, world");

// Otro ejemplo de uso, con objetos JS:
mediator.subscribe("channel", function(data){ alert(data.Message); }
mediator.publish("channel", { Message: "Hey!", From: "Jack" }); //alerts

Uso en el mundo real

Nosotros utilizamos esta clase para nuestro cliente DataFactory donde necesitamos procesar gran cantidad de estadísticas deportivas y mostrarlo en varias pantallas de una aplicación. Con mediator creamos un canal por incidencia (pases, tiros al arco, tiros libres, goles, etc), luego cada módulo que necesitaba esta información solo tenia que suscribirse al canal correspondiente, esperando que le lleguen los datos ya procesados.

Resumen

Finalmente podemos destacar que mediator.js no es sólo una herramienta muy útil para utilizar en un navegador (tanto como JavaScript nativo o cargándolo modularmente mediante RequireJS), ya que también es compatible con Node JS, (descargando por NPM el paquete mediator-js). Sin dudas este pequeño código de 1kb se merece un lugar en nuestros proyectos web.

Para más información recomendamos leer:

El patrón Mediator – Por Addy Osmani

Sitio oficial de mediator.js

Lo principal que se debe tener en cuenta para desarrollar esta página es tener claro el foco que se quiere dar, es muy diferente si estamos mostrando únicamente contenido informativo o bien queremos vender un producto, lo principal a tener en cuenta en ambos casos es un diseño profesional que muestre la importancia del sitio, mostrar claramente el producto o información y  algo que debe tener mucha importancia y no hay que obviar son los tiempos de respuestas.

Algunas cosas a tener en cuenta en el desarrollo de un landing page:

• El logo de la empresa debe ser lo principal, un título muy llamativo y texto bien organizado y breve, ya que como todos sabemos los usuarios no leen.  Adquirir la mayor confianza del usuario.
• El diseño debe ser creativo, debemos llamar la atención del usuario, pero lo principal es no distraerlo demasiado.
• Tiene que ser muy claro el punto de acción en la página que queremos transmitir, por ejemplo donde el usuario debe hacer click para adquirir un producto (click-to-action).
• Un formulario de contacto práctico, sin necesidad de solicitar demasiada información al usuario. “Registrate hoy y accede a …..”.
• Lo importante es ofrecer algún tipo de incentivo, oferta, descuentos, etc.
• Si es un producto, una foto de muy buena calidad, se debe seleccionar cuidadosamente las imágenes que se colocarán, ya que mejoran mucho la calidad de la página.
• No incluir enlaces que saquen al usuario de la página!.

Lo fundamental es obtener estadísticas e información que nos de la posibilidad de adaptar el diseño y distribución de los datos en la página según el comportamiento de los usuarios, necesitamos verificar como fué el impacto del landing page y de esta forma mejorar las conversiones.

Existe una herramienta que nos ayuda mucho en el intento de desarrollar un landing page perfecto, es el  Google Website Optimizer cuya función principal es realizar pruebas online en diferentes versiones de una misma página de forma aleatoria y analizar el comportamiento de los usuarios, permitiéndonos analizar los resultados y realizar los cambios necesario para el desarrollo del landing page. Esta herramienta es gratuita y Google garantiza la privacidad de la información.

Esta competencia trae aparejado en la euforia de salir victorioso la creación de sus propios estándares HTML para mostrar una clara diferencia con la competencia, dando un gran dolor de cabeza a los desarrolladores, ya que tenemos no solo que probar nuestro código en los diferentes browsers, sino que en muchas ocasiones adaptarlos por problemas de compatibilidad. FireFox es uno de los navegadores que más respeta la compatibilidad del código (salvo el recién salido Firefox 5 que ya nos hemos encontrado con diferencias en la visualización de algunos divs), así que diseñar y probar el código HTML en FireFox es una forma de asegurarse un código estándard. También el Chrome es un muy buen navegador que trae de forma nativa herramientas que ayudan a los desarrolladores a identificar los problemas.

En Braintive enfrentamos esta problemática basándonos siempre en los estándares HTML brindados por el W3C (The World Wide Web Consortium), una comunidad  internacional que trabaja para desarrollar estándares web, liderado por el ‘inventor de la web’ Tim Berners-Lee. La comisión además de brindar documentación y guías, posee una herramienta para realizar validaciones de nuestro código HTML e informarnos de las diferencias de compatibilidad, una herramienta muy útil para desarrolladores y diseñadores.

Cada desarrollo que realizamos es testeado no solo por el sector de control de calidad, sino también utilizamos una serie de herramientas que verifican la visualización del contenido HTML resultante en los diferentes navegadores, así como también como nos visualizarían los robots de búsqueda de Google, Yahoo, etc..

Un referente nuestro de usabilidad es Jakob Nielsen y citando su cuarta heurísticas de usabilidad dice:

Consistencia y estándares. Los usuarios no deben tener que preguntarse si las diversas palabras, situaciones, o acciones significan la misma cosa. En general siga las normas y convenciones de la plataforma sobre la que está implementando el sistema.

El futuro nos trae aún más problemas de compatibilidad y dolores de cabeza para los desarrolladores, el nuevo HTML5 y su soporte en cada navegador!.

La lentitud de la carga de la página web está básicamente relacionada con el peso o tamaño del html, imágenes, javascript y los diferentes objetos que se carguen, la idea principal es optimizarlo lo más que se pueda y disminuir la cantidad de peticiones que se hacen desde el navegador hacia el servidor, así como también el peso general de todo el contenido.

Existen muchas herramientas que ayudan a medir los tiempos y dan diferentes recomendaciones para poder mejorarlos eficientemente, un ejemplo es el Page Speed creado por Google que tiene una serie de extensiones para FireFox y Chrome, también posee una versión online.

Algunas cosas que deben tomarse en cuenta para optimizar las páginas son:

1. Implementar CSS Sprites, que consiste en generar una única imagen a partir de varias imágenes que se visualizan en una página y luego por medio de estilos mover parte de la imagen que se desea mostrar. Con esta técnica se reduce la cantidad de peticiones que se realiza hacia el servidor ya que únicamente se necesita una sola imagen.

2. Especificar las dimensiones de cada imagen, por medio de los atributos width y height de la etiqueta IMG.

3. Disminuir el tamaño de las imágenes lo más que se puede, tratando de no perder mucha calidad. Existen aplicaciones que optimizan las imágenes para que sean visualizadas via web.

3. Habilitar compresión gzip sobre el contenido estático, imágenes, archivo de estilos css, js, etc. El ahorro del tamaño de cada archivo es muy grande, se comprime alrededor de un 70%, dependiendo las configuraciones que se establezcan dentro del web server.

4. Utilizar paralización en la carga de imágenes, si todas las imágenes se encuentran en un único dominio, el browser va a ir encolando cada petición hasta cargar todas, en cambio sí se utilizan varios dominios el browser las solicita de forma paralela desde cada dominio img1.sitio.com, img2.sitio.com, etc. Se puede utilizar servicios externos para alojar las imágenes, por ejemplo Akamai.

5. Reducir el tamaño del archivo de estilos css y los archivos JavaScript, eliminar el código que no sea utilizado. Eliminar espacios, tabulaciones, comentarios, tamaño de variables, enters, etc., para que el archivo pese lo menos posible. Existen aplicaciones que ayudan a comprimir el contenido.

6. Habilitar el cache dentro de los dominios que sirven contenido estático (imágenes, css, javascript, etc).

7. Brindar el contenido estático desde dominios con cookies deshabilitadas, para reducir el tamaño de cada solicitud al servidor.

8. Verificar el html, primero que nada debe cumplir con las validaciones de la W3C, todo el código debe ser estandard. No abusar del uso de etiquetas que puedan ser reemplazadas por otras o por un manejo dentro de los estilos, evitar utilizar tabulaciones, contenido en mayúscula, tratar de poner todo en una sola línea. Todo lo que pueda sumar para reducir el tamaño general del html.

9. No abusar de la utilización de librerías de jQuery, no incluir archivos js que no son utilizados o únicamente se utilizan pocas funcionalidad, a veces es mejor desarrollar nuestras propias funciones y no incluir un GRAN archivo que contiene demasiadas cosas que  no son utilizadas.

10. Poner la inclusión de los archivos javascript al final?, esto es algo que realmente me genera ruido, aunque es una sugerencia que ya anda dando vueltas hace bastante, la idea es evitar el bloqueo de las solicitudes, al colocarlo al final se puede descomprimir un poco la carga. También se esta hablando mucho de “Deferred Javascript”, la carga diferida permite descargar scripts después que la página se ha cargado, lo que reduce las solicitudes de vuelta en la red con el servidor, para esto les dejo un link para que se entretengan un poco.

Un dato importante es que el tiempo promedio de carga en la web es de aproximadamente 2.5 segundos, siempre intentemos estar por debajo de ese número.

Jakob estudió 249 problemas de usabilidad y a partir de ellos diseñó lo que denominó las “reglas generales” para identificar los posibles problemas de usabilidad.

1. Visibilidad del estado del sistema: el sistema siempre debería mantener informados a los usuarios de lo que está ocurriendo, a través de retroalimentación apropiada dentro de un tiempo razonable.
2. Relación entre el sistema y el mundo real: el sistema debería hablar el lenguaje de los usuarios mediante palabras, frases y conceptos que sean familiares al usuario, más que con términos relacionados con el sistema. Seguir las convenciones del mundo real, haciendo que la información aparezca en un orden natural y lógico.
3. Control y libertad del usuario: hay ocasiones en que los usuarios elegirán las funciones del sistema por error y necesitarán una “salida de emergencia” claramente marcada para dejar el estado no deseado al que accedieron, sin tener que pasar por una serie de pasos. Se deben apoyar las funciones de deshacer y rehacer.
4. Consistencia y estándares: los usuarios no deberían cuestionarse si acciones, situaciones o palabras diferentes significan en realidad la misma cosa; siga las convenciones establecidas.
5. Prevención de errores: mucho mejor que un buen diseño de mensajes de error es realizar un diseño cuidadoso que prevenga la ocurrencia de problemas.
6. Reconocimiento antes que recuerdo: se deben hacer visibles los objetos, acciones y opciones, El usuario no tendría que recordar la información que se le da en una parte del proceso, para seguir adelante. Las instrucciones para el uso del sistema deben estar a la vista o ser fácilmente recuperables cuando sea necesario.
7. Flexibilidad y eficiencia de uso: la presencia de aceleradores, que no son vistos por los usuarios novatos, puede ofrecer una interacción más rápida a los usuarios expertos que la que el sistema puede proveer a los usuarios de todo tipo. Se debe permitir que los usuarios adapte el sistema para usos frecuentes.
8. Estética y diseño minimalista: los diálogos no deben contener información que es irrelevante o poco usada. Cada unidad extra de información en un diálogo, compite con las unidades de información relevante y disminuye su visibilidad relativa.
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores: los mensajes de error se deben entregar en un lenguaje claro y simple, indicando en forma precisa el problema y sugerir una solución constructiva al problema.
10. Ayuda y documentación: incluso en los casos en que el sistema pueda ser usado sin documentación, podría ser necesario ofrecer ayuda y documentación. Dicha información debería ser fácil de buscar, estar enfocada en las tareas del usuario, con una lista concreta de pasos a desarrollar y no ser demasiado extensa.

Estas reglas son las claves para poder facilitar el uso de cualquier persona, no solo dentro de los sitios web, sino en cualquier sistema de información.

 

Una de las herramientas (o mejor dicho servicio) que se puede utilizar para este fin es Google Website Optimizer. Este servicio nos permite trackear diferentes versiones de una misma página para saber cuál da mejor resultado de conversión.

Por ejemplo podemos crear 3 o 4 versiones diferentes de la registración de nuestro sitio web con diferentes campos, textos o validaciones. La idea es analizar cuál de estas diferentes versiones de la registración logró más conversiones. Esto se logra conociendo cuál de estas versiones llegó al paso final de la registración, o mejor dicho en vocabulario de Google WO: cuál de estas versiones logró más accesos a la conversion page.

¿Qué es conversion page?

La conversion page es la página que nos ayudará a medir la tasa de conversión de cada versión, es en realidad a dónde queremos que el usuario llegue por medio de un paso previo. Por cada usuario que llegue a esta página, contaremos una conversión exitosa.

Requerimientos básicos para comenzar a experimentar con Google WO

Cuando ingresamos por primera vez a Google Website Optimizer, nos explicará lo que tenemos que tener preparado para realizar lo que ellos llaman “experimentos”. Básicamente lo que se necesita es tener:

• mínimo conocimiento de HTML (o alguien que lo tenga por nosotros)
• crear 3 o más versiones diferentes de la página que queremos medir (por ejemplo varias versiones de la Home o de una registración)
• acceso a modificar los archivos de nuestro sitio.

¿Cuál es la idea de crear diferentes versiones de una misma página?

Website Optimizer se encargará de distribuir a los visitantes equitativamente a una versión diferente de la página, para de esta manera poder medir cuál es la más eficaz en la conversión.

Una vez creadas las distintas versiones de la página a medir, debemos poner un código javascript dentro del <head> de cada versión. También es necesario poner un código javascript diferente en nuestra página de conversión (ej: paso final de nuestra registración).

Cuando hayamos puesto el código javascript en las diferentes páginas, haremos click en Validate pages y se realizará la verificación para comprobar de que todo esté funcionando correctamente.

De esta manera, si hemos configurado adecuadamente lo necesario podremos arrancar el experimento y luego de un tiempo los datos irán apareciendo en el reporte.

Dependiendo del tráfico de nuestro sitio, luego de unas horas o unos días podremos ver cuál es la versión de la página que permite la mejor conversión. De acuerdo a estos resultados tendríamos que reemplazar nuestra página original por esta versión y finalizar el experimento.

En la imagen de ejemplo, por el momento la versión más efectiva de nuestro experimento es la número dos ya que tiene 18 conversiones sobre 54 visitas, siguiendo la original con 16 conversiones sobre 54 visitas y por último la tercera versión con 11 conversiones sobre 56 visitas.

Esta es otra de las maneras que tenemos para optimizar, o como la imágen de este post sugiere “afinar el lapiz” de nuestros sitios web para mejorar las conversiones de cualquier página.

no contar con un formulario adecuado, más allá del tipo de producto o contenido que esté brindando.

El radio de conversión mide el porcentaje de visitantes que logran realizar una determinada acción dentro de una página, por ejemplo cuantos visitantes logran realizar el envío del formulario de registración.

Esto es lo primero que debemos medir, cuál es nuestro porcentaje de conversión dentro de una registración, aquí nos vamos a dar cuenta en primera instancia qué cantidad de registros se están perdiendo. Por ejemplo si contamos con 100 visitantes diarios dentro de la registración y solo tenemos el 10% de conversiones (que hayan finalizado el proceso de registración), estamos perdiéndonos 90 registraciones diarias.

Cuando desarrollamos la registración, pensamos que cada objeto colocado tenía un propósito determinado y suponemos que el usuario lo entendería, pero en muchas ocasiones esto no sucede, los formularios no son claros y las acciones sobre los mismos no se comprenden.

Lo primero que se debe analizar para mejorar el porcentaje de registración es determinar si existen elementos dentro del formulario que pueden ser eliminados, tal vez estamos solicitando información de más, no relevante o privada que el usuario puede no querer ingresar y por dicho motivo fracasar la registración. Mientras más extenso sea el formulario, menos posibilidades se tiene de llegar a realizar el envío de los datos con éxito. Minimizando el ingreso del formulario ya vamos a notar un incremento del porcentaje de registración.

Otro punto muy importante son los textos y títulos, se conoce que los usuarios no leen los mensajes que se visualizan en la pantalla, por lo tanto se debe colocar mensajes precisos, claros y destacados donde corresponda y se debe brindar ayuda en campos que se consideren difíciles de entender.

Evitemos el envío de los datos que contienen errores, para luego refrescar la página y mostrar un largo listado de mensajes de validación, lo ideal es que el formulario se valide a medida que los datos son ingresados, para evitar el ‘post’ innecesario de los datos inválidos. Para realizar estas validaciones se puede utilizar Ajax y librerías de validaciones que son fáciles de implementar con jquery.

Hasta este momento podemos mejorar el porcentaje de registración, pero nos estamos perdiendo de un análisis más profundo en donde vamos a poder acceder a una cantidad muy importante de mejoras que ayudarán considerablemente a mejorar las conversiones. Existe una herramienta, entre otras, muy importante llamada ClickTale que nos permite ver un poco más allá y acceder a información que nos ayudará a mejorar los formularios. Esta herramienta nos permite obtener información sobre la experiencia que el usuario tuvo dentro del site.

Mapa de calor

Permite observar el movimiento que el usuario realizo con el mouse dentro de la página, dándonos una idea importante sobre la atención, dentro de un browser el movimiento del mouse emula la vista y nos da información sobre la ‘atención del usuario’.

Esto nos ayudará a reposicionar los objetos dentro del formulario.

Monitor en tiempo real

Permite acceder a grabaciones en donde se visualiza exactamente lo que el usuario realizó dentro del formulario, movimientos, datos ingresados, clicks, etc.
Hay una gran cantidad de datos que no nos llegan debido al fracaso de la registración, por ejemplo viendo estas grabaciones podemos darnos cuenta que existen varios usuarios que ingresan dentro del campo ‘número de calle’ el texto ‘km 25, sin numeración, etc.’ y nuestra validación solo permite números enteros. Gracias a esta información podemos darnos cuenta de un error al momento de plantear las validaciones del formularios y asumiendo que siempre debería venir un tipo de dato específico.

Esto nos hace dar cuenta de defectos del formulario, que no podríamos ver de otra manera, ya que no accedemos a los registros fallidos.

Errores javascript

Brinda información de todos los errores de javascript que sucedieron, muchas veces estas son cosas fundamentales por las cuales fracasa la registración y no nos damos cuenta ya que suceden en determinados momentos puntuales con datos precisos. De esta forma podemos acceder al error y correguirlos.

Analisis de formularios

Una de las funciones más importantes de esta herramienta es poder medir exactamente los porcentajes de conversión y que cantidades de intentos fracasaron en cada paso del tunel, esto nos da información muy importante.

Cuales son los campos en donde más tiempo pasa el usuario, esto ayuda a determinar la causa, ¿no se comprenden?, ¿datos difíciles?, ¿tiene que ir a buscar algún dato en otro lado?

Datos que son eliminados y vueltos a ingresar. (refill), ¿porque los usuarios necesitan modificarlos?

Que campos se dejan en blanco, si el porcentaje es muy grande tenemos que preguntarnos si son útiles realmente.

Campos que contienen datos originalmente en el formulario y el usuario los cambia. Si el porcentaje es muy grande, seguramente debemos cambiar el dato default.

Por supuesto que antes de colocar un formulario de registración debemos realizar todo un análisis de usabilidad y realizar todas las pruebas necesarias hasta obtenter un formulario sin errores y optimizado en profundidad, pero no siempre se cuenta con los recuersos necesario, con esta herramienta podemos obtener una ayuda muy importante.

El término se asocia directamente con la idea de compartir  información y la colaboración que los usuarios generan. Hablamos de wikis, blogs, fotoblogs,  redes sociales, etc.

Para mi el término web 2.0 debería asociarse directamente con una solución técnica que se pudo lograr con el avance de la tecnología utilizada para el desarrollo web y no con una idea revolucionaria de colaboración. Todos hablan de la web 2.0 como algo nuevo que surgió en los últimos años, cuando podríamos compararlos perfectamente con ideas del pasado.

Si nos remontamos hace 12 años atrás o más, nos encontraríamos con un llamado ‘portal horizontal’ como El Sitio, que era un lugar de entrada para una variedad muy grande de servicios que se brindaban a los usuarios, en donde muchos de esos servicios podríamos asociarlos hoy en día con sitios 2.0.

En ese entonces en Argentina (como en Latinoamérica) no se tenía un acceso general a  banda ancha, los usuarios utilizaban acceso mediante dial-up y el contenido era muy lento de cargar.

Podríamos hacer un paralelismo entre el ayer (El Sitio) y el hoy (Web 2.0).

CupidoNet = Facebook

Chat 3D = Second Life

Habitantes = Blogs

La cara del sitio = FotoBlogs

El problema principal por la cual los viejos portales horizontales no pudieron continuar hasta hoy fue por la falta de tecnología para resolver ciertas problemáticas de forma práctica y rápida, además lo pobre que era la velocidad de conexión a Internet. Como anécdota recuerdo que en ese entonces un problema grave para el Chat 3D (algo totalmente revolucionario en ese entonces, creado por El Sitio) fue que el plugin pesaba alrededor de 80kb para bajarlo, un peso que hoy es insignificante!.

Tanto Alfred como Yo, tuvimos el honor de participar en todos los avances tecnológicos que tuvo Internet en los últimos 15 años, fuimos parte del crecimiento y ayudamos al mismo desde nuestro humilde lugar.

Desde Braintive le deseamos un muy feliz día a INTERNET.

La accesibilidad en un sitio web se refiere a la capacidad del mismo para ser accedido por cualquier persona independientemente de sus limitaciones físicas (por ejemplo la discapacidad visual), también hace referencia no solo al acceso, sino también al uso, donde toca ya cuestiones de ‘usabilidad’.

Prácticamente nadie toma en cuenta esta premisa a la hora de desarrollar un sitio web y suponen que las personas detrás podrán acceder sin problemas al contenido, sin darse cuenta el potencial que tiene un sitio que puede ser accedido por cualquier persona, ya que los accesos en definitiva se traducen de alguna manera a un valor de retorno.

Por ejemplo, suponemos que una persona podría estar viendo un determinado botón de acceso al contenido, de un color, forma o tamaño pensado para  alentar al usuario a hacer click, cuando en realidad esta persona podría estar trabajando con el monitor apagado, ya que es una persona ciega. ¿Cómo puede ‘ver’ entonces el botón?,  son utilizados programas que leen el contenido y avisan al usuario donde pueden hacer click, el botón como figura no genera ningún valor, ya que no puede ser visto, el valor aquí lo genera el texto.

Las personas ciegas o con disminución considerable de la vista utilizan programas que leen el contenido de la página web y de esta forma pueden navegar sin problemas, se sorprenderían observar como ellos trabajan con el monitor apagado y pueden perfectamente ‘visualizar’ cualquier contenido. Un software utilizado para esto es el JAWS

En muchos países ya existe legislación que obliga a determinas páginas de organismos públicos o de algunas empresas a brindar contenido accesible en sus sitios web. El WAI (Web Accessibility Initiative) grupo perteneciente al W3C (The World Wide Web Consortium) también creó pautas para ayudar a desarrollar contenido accesible.

No es necesario sacrificar el diseño a la  hora de hacer un sitio web accesible, simplemente hay que seguir una serie de pautas para guiar el diseño de páginas web a un diseño accesible. Algunas ideas que implementamos en Braintive a la hora de desarrollar un sitio web, para no limitar el acceso de nadie al contenido:

• Todas las páginas deben tener la etiqueta de cabecera TITLE, explicando lo que el usuario va a encontrar, por ejemplo: Página principal, Listado de productos.
• Usar correctamente las etiquetas h1, h2, .. donde debe informar la importancia que tienen los títulos y textos dentro de la página.
• No utilizar tablas para centrar textos o colocar secciones, las tablas deben ser utilizadas para grillas, el posicionamiento de texto se deben realizar por medio de estilos css.
• Utilizar la etiqueta ABBR para brindar detalles sobre abreviaciones, por ejemplo si el texto dice cant. se debe informar que el texto correcto es ‘cantidad’.
• Todas las imágenes deben tener el atributo ALT con el texto al que hace referencia la imagen, si el botón es una imagen que dice ‘Aceptar’, el atributo ALT debe tener el mismo texto. Si se requiere mayor detalle se debe utilizar el atributo LONGDESC
• Los links deben tener el atributo TITLE informando la acción que genera el click, más allá del texto, por ejemplo si link dice ‘compras’, el atributo TITLE debería contener ‘Listado de mis compras mensuales’.
• No utilizar palabras comunes para definir links, como ‘aquí’, utilizar frases más descriptivas dentro de los links.
• Definir atajos de teclado en los links, atributo ACCESSKEY.
• Si se utilizan FRAMES se debe colocar el titulo descriptivo en el atributo TITLE.
• Los listados de selección o navegación deben ser colocados dentro de las etiquetas UL y LI, luego por medio de los estilos css se brinda un correcto diseño.
• Dentro de los formularios se debe utilizar etiquetas standards que son interpretadas por todos los lectores web, que luego por estilos css se puede colocar el diseño acorde al sitio web. Estas son: LEGEND, FIELDSET, LABEL. Por ejemplo la etiqueta LABEL relaciona el texto con el elemento del formulario.
• Tener en cuenta los colores que se asignarán a los botones, existen programas para evaluar como un daltónico los visualizará.
• Dar la posibilidad de agrandar el texto de las letras, por default deben tener un tamaño correctamente legible.
• Si se utiliza javascript, tener un plan B que funcione con javascript desactivado, ya que es posible que algunos lectores no lo soporten.
• Evitar el uso de FLASH! aunque las versiones nuevas de flash y componentes que se agregan a la hora de desarrollar dicen poseer soporte de accesibilidad, existe la posibilidad de incompatibilidad en la lectura del flash por medio del navegador que utiliza el usuario que tienen inconvenientes de accesibilidad. El FLASH es un binario (plugin) que no tiene las etiquetas estándares de HTML por lo tanto imposibilita la lectura por medio de los programas utilizados por personas ciegas para interpretar el contenido web.

No hay que considerar pérdida de tiempo en implementar estas técnicas, es fundamental no limitar el acceso al contenido.