Sergio Gago

Artículo dedicado al Business Angel que me intentó convencer de los millones que hacían falta para empezar un negocio en la Web, y que ya no se puede innovar en prácticamente nada de lo que se haga, porque ya se hizo todo en la (aquella) burbuja.

1. Leer este artículo con las 10 reglas básicas.

2. Tener una idea (el orden entre esta y la anterior no es obligatorio).

3. Conseguir 2 o 3 amigos que sepan de programación y de indexación. Conocimientos sobre servidores y el mundo geek en general también ayudarán.

4. Discutir con tus amigos la cantidad de gente que lo va a usar, cómo lo vas a lanzar y dar a conocer, que necesidades tendrás en el futuro, y si es viable o solo una idea para frikis (aunque quizá haya suficientes frikis para que sea viable!). Al fin y al cabo, cómo vas a conseguir ganar dinero para valer mucho y que te compre google. De todas formas, todo puede fallar.
5. Tener un blog y hacerse eco en la blogosfera.

6. Juntarse, preferiblemente en un garage, para seguir con la tradición, durante horas, con los ordenadores, pizzas y cervezas a maquinar y programar, sin tener en cuenta que el tiempo que dedicas debe constar en un plan financiero ni debe ser amortizado. También valen habitaciones bien ventiladas, incluso bares en las primeras reuniones.

7. Decirselo a todos tus amigos. Maldita sea, si te aguantan día tras día, seguro que podrán probar tu nuevo super-sistema Web. Y que te den mucho feedback!

8. Crea una beta privada, asi si fallas, solo se enterará muy poca gente (recuerda que en España está mal visto el fallo)

9. Cambia todo lo que necesites para adaptarte al mercado

10. Gana dinero, y comprueba dónde están tus vecinos de la 2.0!

En conclusión, que puedes gastarte muchos millones en montar un gran pitote con mucha gente, grandes equipos y unas oficinas muy cool, pero eso no te dará más posibilidades de triunfar que los cuatro colegas que se montan una gran idea en su garaje (A nadie le suena??)

Primero fueron los buscadores, que se fueron especializando y nos deban resultados diferentes en función de su algoritmo, y luego los portales del tipo directorio, que se basaban en indexación para aparecer “los primeros en google”.

Pero hoy en día, hemos llegado a un punto en una serie de servicios, en los que es una auténtica locura pasearse por todas las webs que se dedican a lo mismo. Trabajan en nichos de mercado donde lo normal es no pasar del 20% del market share, y por lo tanto, tienes que ir pasando, al menos, por 3 o 4 sitios diferentes, dejando todos tus datos y comprobando las novedades día a día.

¿Qué mercados son estos? Vivienda, automovil, trabajo, vuelos…

Hace tiempo, mientras buscaba piso, me pareció una locura, estar continuamente mirando fotocasa, loquo, idealista… y se me ocurrió una idea que dejé apuntada en mi “libreta de futuros negocios que nunca tendré tiempo de hacer”, en parte basado en otras cosas similares que ya había visto. ¿Qué tan bien funcionaría una web que buscara en todos los portales inmobiliarios, y me diera resultados en todos ellos, dirigiéndome a la página de producto de cada uno, pero con mi navegación?T

Pues bien, ya ha habido alguien que ha implementado esto, ¡y de que forma! Tenemos www.casabuscador.com, que nos hace búsquedas en los portales más importantes, y además implementa una búsqueda por mapa que resulta de lo más útil. Seguro que tendrá éxito.

Pero no se quedan ahi. También tenemos currobuscador.com y cochebuscador.com, una combinación potente.

Es cierto que la idea no es nueva. Yo llevo tiempo usando trabber.com, para vuelos, y los metabuscadores de “buscadores”, tipo metacrawler, llevan ya mucho tiempo. Pero sin duda, estos hechos son una buena prueba de que el nicho de mercado está ahi!

Si con la Web 2.0 no teníamos suficiente… ahora entramos en la Web 4.0. Para ello hemos tenido que atravesar la oficina 2.0, la era de los mashups, la búsqueda semántica que evolucionará en las bases de datos semánticas, la búsqueda distribuida y por fin, la era del sistema operativo vía web “WebOS” (que vaya nombre, oye). que tendrá como centro radical, supuestamente, los agentes inteligentes como red neuronal global.

Visto en barrapunto, noticia original en minding the planet. Muy interesantes los comentarios de la noticia.

Ahora me queda una duda… ¿cual de todas estas versiones será el “Wow” de internet?

Aunque si ya domináis el tema a la perfección, esto no os va a ser de ayuda, si estáis empezando, o queréis hacer algo de forma muy rápida, os irá a las mil maravillas.

Hablo de ___layouts, inspirado en los YUI Grids de yahoo, que básicamente nos permite crear nuestro layout de columnas con CSS, en un código bastante limpio y estándar. De hecho lo que permite es lo siguiente:

• Diseños fluidos
• Diseños fijos de.
  • 640px
  • 760px
  • 900px
  • 1000px
• Personalización para cualquier tipo de anchura
• Posibilidad de hacer el layout flexible ante cambios del tamaño de letra.
• Columnas con clear por secciones, de forma que no hay problema con columnas que son más largas que otras.
• Centrar las columnas que queramos
• Sobreeescribir los CSS para modificar posiciones y tamaños a discrección.
• font.css basado en YUI fonts.css

(traducción libre del artículo original en Ajaxian)

Pero lo mejor es el builder, donde con un estilo wizard, haremos nuestro esquema con toda la complejidad que queramos en cuatro clicks.

Cada vez que ponemos un link, o que usamos un tag, que comentamos o que hacemos una referencia o relación, estamos enseñando a las máquinas a ordenar todos los datos que hay perdidos por la Web.

“La Web 2.0 es enlazar a gente que comparte, intercambia y colabora” (Traducción literal del video)

Hasta ahora la mejor descripción que he visto de la Web 2.0, con su impresionante video.

Visto en Grancomo.

Este es un tema en el que llevo pensando cierto tiempo, en parte gracias a Josep M., compañero de trabajo, con el que estoy haciendo ahora una muy productiva labor de arquitectura de la información y usabilidad en un proyecto.

¿Cómo ofrecer al usuario la posibilidad de elegir SU provincia con la máxima usabilidad? (Atención que hablo de su provincia)

Pues bien, a priori tenemos dos modelos básicos: La lista desplegable y el mapa, teniendo cada uno muchas variantes diferentes, y sus propios problemas y más. Estudiemos qué hacen algunos de los portales líderes en España (que se basan en la selección de provincia):

Idealista.com
Portal dedicado a la inmobiliaria. La navegación está basada en desplegables de 6 alturas, de forma que en los dos primeros solo tenemos que seleccionar el elemento buscado, y en el tercero, la provincia propiamente dicha, será donde tendremos que bajar hasta encontra el elemento buscado.

paginasamarillas.es
No hay mucho que decir. La provincia es un desplegable estándar de un solo nivel (más de 50 opciones), y una localida de campo libre.

fotocasa.es
Otro portal inmobiliario. Precisamente estos son los que más hincapié deben hacer en la localización geográfica. Optan por un modelo similar a idealista para las opciones (alquiler, compra…), pero se basan en un modelo de mapas para la localización de provincia. El resto de pantallas están basadas totalmente en mapas también, por localidad y zona (incluso barrio en ciudades grandes). La navegación del mapa es sensible y nos va indicando el nº de inmuebles encontrados).
loquo.com
Quizá uno de los portales de anuncios clasificados con más visitas. Utiliza (si no me equivoco) localización ip para redirigir al usuario a la ciudad adecuada, ya que en este caso son los anuncios los que están localizados geográficamente.
Aun así, como barra lateral nos ofrece todas las provincias donde existe loquo, por si algo ha fallado o simplemente quermos buscar en otro sitio.

infojobs.net
Portal líder de empleo en España. Aquí, lógicamente, la función de seleccionar la provincia donde quieres trabajar, es imprescindible. En este caso tenemos un desplegable de un solo nivel. (Luego veremos que también hay que valorar el espacio disponible).

atrea.com
Otro portal inmobiliario, del grupo BBVA, quizá menos conocido que idealista o fotocasa, pero que alexa no le trata nad mal. En este caso ofrecen las dos posibilidades: Tres listas desplegables de un solo nivel, que se autorrellenan con el anterior: País, provincia, y localidad. Y mapa que añade detalle en función de lo que vayamos seleccionando

enalquiler.com
En este portal ya asumimos que solo vamos a alquilar, de forma que los tres desplegables de 7 niveles son para el tipo de vivienda, la provincia y el precio. Eso si, los primeros elementos que muestran son los que más viviendas tienen. Tratando de simplificar el uso al mayor porcentaje de usuarios.

laboris.net
Otro portal de empleo que usa dos desplegables de un nivel tanto para provincia como para categoría.

niumba.com
Niumba es un portal de alquiler de viviendas para vacaciones, por lo que las zonas con las que trabajan están muy localizadas. De hecho, permiten buscar por provincia o por zona (costas sobre todo), pero al igual que atrea, permiten una búsqueda por desplegables de un nivel, o una selección por mapa, que contextualmente nos dice dónde estamos y qué oferta hay en ese punto.

segundamano.es
Portal de anuncios de intercambio propietaria del grupo anuntis. En la home no nos ofrecen ningún buscador, sino una lista enorme de categorías y subcategorías, y ya dentro de una de ellas podemos seleccionar la provincia en un desplegable de un nivel.
compraventa.com
Otro portal de anuncios de compra venta, en cuya home en lugar de pedirnos la categoría nos piden la localización, con mapa o con listado de todas las provincias. Está claro que se centran mucho más en el lugar que en la categoría de anuncio.

Estos son solo algunos ejemplos de portales que comen todos los días cantidaes ingentes de tráfico, pero sin duda hay muchos otros (que si queréis podéis dejar en los comentarios).
El primer problema que nos encontramos está en cómo clasificar este elemento. Si estuviéramos hablando de nuestro menú propiamente dicho, se puede concluir que las listas desplegables están hechas para formularios, y que se deben buscar otros elementos.

Pero tampoco estamos hablando de un elemento de formulario propiamente dicho (al estilo tradicional, se entiende). Estamos viendo un elemento que se nos muestra desde la home de nuestra página, y que de su utilización depende el resto de la navegación en el sitio, vamos, con una criticidad demasiado alta para ser obviada, sobre todo cuando hablamos de portales que venden ítems centrados geográficamente.

Entonces, tenemos que tener en cuenta los siguientes factores:

• Espacio disponible y criterios:
  ¿Con cuánto espacio contamos? ¿Cuántos elementos más tenemos en la página? ¿Será el único modo de navegación o el usuario puede elegir otros criterios de búsqueda? Si nuestra búsqueda es impepinablemente por localización, quizá necesite más peso.
  Es importante también el dónde lo vamos a colocar, y los criterios anteriores que le hemos hecho seleccionar. Por ejemplo, si tenemos que elegir un tipo de vivienda, una provincia, luego un precio y luego introducir un término para buscar, probablemente pocos usuarios introduzcan ningún término, porque después de seleccionar tres ítems, es más fácil darle a un botón que pensar en un término:La búsqueda más crítica, deberá tener el máximo espacio y estar situada en un “hotspot” de nuestra página. El usuario debe captar la criticidad del elemento. Si hay varios elementos de búsqueda, dividámoslos, fuera frustración!

• Usuarios target
  ¿Quién es nuestro público? ¿Gente que quiere vender en su barrio? ¿Gente que busca un piso en cualquier provincia de España? ¿El público conoce bien su geografía? ¿Qué nivel tienen de internet? En general, la gente es lenta tecleando y buscando, por lo que tenemos que simplificar y adelantarnos a sus pensamientos.Si tu público conoce bien el mapa, puedes ponérselo, será más fácil que encuentren algo en un elemento conocido donde ven todos los ítems a la vez, que estar buscando en una lista. recuerda: hay pocos usuarios que sepan que en una lista desplegable, si das a la “v” te irá directamente a “Valencia”.

• Accesibilidad: ¿Cómo se verá sin JS o sin imágenes?
  ¿Qué va a ocurrir a nivel de accesibilidad? ¿Cómo se quedará tu página si la desnudas y la dejas sin JS? ¿Y sin CSS? ¿Tus mapas son en flash?Si usas tecnologías no estándar, ofrece alternativas a la navegación (aunque menos visuales). Si usas mucho javascript, o ajax, también. Haz pruebas de navegación desactivando todo esto a ver cómo aparece. Acuérdate de los lectores de pantalla y de las versiones HTML plano.

• Dispersión de los datos
  ¿Estás en todos los sitios, pero mucho más en unos que en otros? Si el 90% de tus usuarios entran en tu portal para buscar jamones, pónselo en portada.Si Madrid y Barcelona ocupan el 95% de tus ofertas de trabajo, pónles un atajo. Es cierto que supone “menospreciar” a los usuarios de lugares con menos oferta, pero se trata de llegar a un acuerdo.

• Profundidad de los datos
  ¿Cuál es el nivel de selección? ¿Comunidad autónoma? ¿Provincia? ¿Localidad? ¿Otras? ¿Variadas? Este es un problema típico en las inmobiliarias. Si busco Valladolid, podríamos englobar, capital, y provincia, como mucho algunos pueblos grandes de alrededor. Sin embargo en Barcelona tiene sentido ver por separado la capital, del Vallès, Sitges, etc… ¿Hasta donde profundizaremos en nuestro mapa?En primera instancia, el usuario debe ser “universal”. No tiene sentido que un usuario que aún no nos ha dicho si es de Madrid o de Barcelona, pueda escoger Alcobendas. Según bajamos en la navegación podemos ir dándole más opciones, siempre con la opción de “todas las localidades”. Esto también depende de la dispersión de los datos. ¿Tenemos 500 inmuebles en Barcelona y 2 en Terrasa?

Para finalizar y concluir, me sigo quedando con los mapas, siempre, teniendo en cuenta los factores de arriba. Además, existe otro factor que he comentado y que también es muy importante: Nuestra Web debe ser homogénea. Las búsquedas de provincia deberán ser todas iguales.

¿Experiencias? ¿Opiniones?

Hoy navegando, he llegado por casualidad a la Web de una empresa de diseño Web, inicialmente muy parecida a las otras miles que hay por España. Pero cuando ha empezado a salir una sonrisa de mi boca ha sido cuando he llegado a su política de precios:

• 5 Pantallas destinadas a las diferentes necesidades de tu actividad o negocio, por ejemplo: Quienes Somos, Nuestros Servicios, Dónde Estamos, Solicita tu Presupuesto, etc.
  Con 5 basta, ni una más ni una menos.
• 1 Pantalla con un Formulario para que puedas recibir datos en tu E-mail (pedidos, información…).
  A sabe cómo está hecho el formulario… probablemente un “mailto:” en el action.
• 1 Pantalla para confirmación de envío del Formulario (siempre que tu servidor lo permita).
  Guau.. .tecnología punta
• 12 Fotografías que puedes distribuir en las 5 pantallas principales (facilitadas por ti).
  Ni una más ni una menos, no sea que tengamos que retocar más de lo debido en photoshop.
• Logotipo de tu empresa en cada pantalla (facilitado por ti).
  Por supuesto!
• 1 Diseño de pantalla estándar que puedes elegir entre los diferentes modelos que tenemos actualmente disponibles.

Y cuando dicen página estándar, dicen una colección de plantillazos sacados de variantes de template monster y derivados que aplican a varios clientes. Es más, peores derivados de template monster, porque ni siquiera cumplen estándares.

Precio: 250€, sin Iva, ni registro de dominio ni hosting.

Analizando un poco las webs generadas (estas cosas me fastidian más de lo debido, y le suelo dedicar algo de tiempo), vemos que:

• Están desarrolladas íntegramente con dreamweaver (vale, esto no es tan malo).
• El < ! DOCTYPE > brilla por su ausencia, así como el tipo de codificación utilizada.
• La mayoría de las etiquetas están en mayúsculas.
• Maquetan absolutamente todo con tablas (volvámos a los 90!)
• Por supuesto, no valida, se usan parámetros de estilo en el html no siempre válidos, y los alt de las imágenes no existen (y mira que el dreamweaver te lo pide!).

Eso si, puedes pedirles un presupuesto personalizado:

• Cada pantalla HTML con texto (tamaño a4): 35€
• Cada imágen: 2€
• Formulario: 38€
• Inserción de logotipo: 2€
• Pantalla HTML emergente (toma ya!): 10€
• 3 Banners rotativos: 6€
• Imágen de fondo por pantalla: 2€
• Midis por pantalla: 2€
• Contador de visitas: 9€
• Tablón de anuncios con CGI: 60€
• Lista de correo: 60€
• Diseño de interface con elementos de navegación: 60€
• Barra de navegación personalizada: 180€
• Mantenimiento y modificaciones. 9€
• Alta en 150 buscadores: 80€
• Ser un Webmaster de finales de los 90 en pleno fenómeno “2.0″ no tiene precio.

Y lo más divertido viene cuando en su página principal, “denuncian” a otras Webs por plagiar su plantilla… me pregunto qué pensarán sus clientes cuando vean que su web es exactamente igual que otra…

No se cuánto facturarán (ni me importa demasiado), pero al final tendrán fecha de caducidad…

Nota: No he puesto su Web a propósito, pero si alguien la quiere, me la puede pedir personalmente.

Esta entrada tiene dos motivos, por un lado presentar enseñaros una presentación de Bob Martin, y por otro, presentar InfoQ, una web para desarrolladores repleta de buenas presentaciones, como ésta de Los principios del diseño ágil orientado a objetos. Hay una buena colección de presentaciones, algunas acompañadas con sus transparencias que van cambiando conforme avanza el tema. Peeeeero, en inglés.
Y la otra parte es la presentación vinculada: La gestión de la dependencia, mal utilizada, es frágil, inelástica, no reutilizable, y muy rígida. En esta presentación, Bob Martin nos presenta sus principios del desarrollo ágil, en una presentación bastante divertida para los que sepáis suficiente inglés. Como decía Bertrand Meyer: “Los módulos deben ser abiertos a la extensión pero cerrados a la modificación”, a lo que amplía Bob, la clave está en la abstracción.

Desde que conocí la metodología de programación extrema hace unos años, me di cuenta de que estaba hecha para la Web. Aunque inicialmente estuviera pensada para cualquier tipo de desarrollo (sobre todo Java), realmente encaja a la perfección con un proceso de desarrollo Web normal.

La XP es uno de los muchos procesos ágiles que hay ahora mismo disponibles, y que se basa fundamentalmente en olvidarse de que no podemos adelantarnos a los cambios de requisitos, y a que los clientes siempre serán aleatorios y caóticos. De modo que nos propone varias pautas a seguir a la hora de gestionar nuestro proyecto. Copio los epígrafes del artículo en la wikipedia, adaptándolos a un desarrollo web medio - grande.

• Desarrollo iterativo e incremental: El desarrollo en espiral evolucionado. No podemos presentar directamente la imágen a un cliente, o a unos usuarios. Aquí entra la labor de bocetado, prototipado, pruebas de usabilidad, etc. Poco a poco vamos aumentando fidelidad a los prototipos hasta que desarrollamos la lógica de negocio completamente (donde el cliente ya pinta poco). Y como decía hace unos días: Da igual que tu algoritmo sea el mejor y más eficiente… si es feo, al cliente no le va a gustar!
  Y respecto a incremental, el hecho de ir añadiendo módulos, o funcinoalidades hace que el desarrollo sea menos caótico, algo nada nuevo dentro del desarrollo Web.

• Pruebas unitarias continuas. Hoy en día con Firebug, esto es más fácil que nunca. A la hora de desarrollar la GUI, trabajar con los efectos JS y el CSS (sobre todo con librerías), cada vez que vamos al navegador y pulsamos F5 para comprobar los efectos del último hack incluido no estamos haciendo más que pruerbas unitarias. Esto inicialmente estaba pensado para JUnit, y para la preparación de los casos de prueba de las clases antes de la programación de las mismas. Esto también lo podemos hacer en la lógica de negocio de nuestras clases. De hecho una técnica para fidelizar al 100% los prototipos es desarrollar toda la lógica de presentación apuntando a clases de prueba, que en lugar de sacar los datos de una capa de acceso a datos, tiene un contenido dummy (arrays escritos a pelo en una clase PHP). De esta forma, la interfaz da la impresión de estar terminada, pero realmente no hay nada por debajo.

• Programación por parejas: Esta es la parte que más me gusta, y que aunque parezca mentira realmente funciona. Mientras uno codifica, el otro va diseñando y realizando pruebas, preparando la codificación y comprobando lo que va haciendo el otro. Cuando hay un error que se nos atasca no hay nada mejor que pedir a alguein que lo eche un vistazo, y la programación por parejas va un poco por ahi. En el mundo del desarrollo Web es común hacer esto en parejas de diseñador gráfico - maquetador, o programador - analista, pero la idea es que haya cuatro ojos mirando el mismo monitor.

• Frecuente interacción del equipo de programación con el cliente. De hecho, el método propone que haya un miembro de la empresa cliente en el equipo de desarrollo. Esto es bastante inviable en el 99% de los casos, pero lo que si se puede hacer es un constante trabajo de pruebas y mejoras continuas. De nuevo, volvemos al prototipado y las pruebas con el cliente. Desde diagramas de casos de uso que sean entendibles, hasta documentación (no técnica), pasando, claro, por reuniones de seguimiento y de pruebas, documentadas y en acta.

• Corrección de todos los errores. Lo ideal es que cada “entrega” o “hito” no dure más de una semana. Cuanto más cortos mucho mejor, pues se genera menos ruido o caos en el código general. Y una filosofía que pocos apliacan. No se añaden funcionalidades hasta que se han solventado todos los errores de las existentes. En Web esto es muy importante. No nos sirve de nada implementar un mashup de google maps en nuestra aplicación, si la página no se ve bien en firefox!

• Refactorización del código. Aunque depende mucho del sistema que usemos (Java con struts y JSP, PHP, Ruby on Rails….), es importante refactorizar el código para aumentar la escalabilidad y el mantenimiento. En prácticamente todos los desarrollos informáticos acabas utilizando más librerías o implementando más funciones de las que necesitas. Muchas veces haces código duplicado, y otras podrías haber usado algún patrón de diseño para mejorar el código y hacerlo más claro. Lo idea es que cada iteración de la aplicación sufra una refactorización total, por supuesto sin modificar las funcionalidades. ¿Qué implica esto en el D. Web? Separar los CSS por tipo de presentación y módulo, juntar los JS de funciones similares, o separar los que no tengan nada que ver, buscar herencias y polimorfismos en el código e implementarlos, etc… Aquí la diferencia se nos dará en clarificación de código, y tiempo de carga (pasar de cargar código javascript de 80kb a cargar 30kb).

• Propiedad del código compartida: Todo el código es de todos y cualqueira puede modificar cualquier parte. Aquí estoy de acuerdo sólo si usas un buen control de versiones. Pero en los desarrollos Web es más común que un pequeño cambio afecte a toda la aplicación, de forma que se hace necesario que todos los desarrolladores conozcan todo el código y estén capacitados para modificarlo.

• Simplicidad en el código. Esto está claro, pero ampliarlo a simplicidad en la interfaz, en el diseño (no solo gráfico, sino de la aplicación), y por supuesto, cumplir con estándares y validaciones.

En general es útil cuando los equipos no son muy grandes (no más de 8 personas), y cuando son ágiles. La consultora tradicional tendrá muchos problemas para adaptarse. Sin embargo el equipo de jóvenes desarrolladores de una start-up, lo tendrán como el modelo ideal. Ergo concluyo: La programación extrema puede ser el mejor paradigma de programación para la creación de start-ups.

Más info en la web de difusión del extreme programming.

Llevo tiempo pegándome con las aplicaciones Ajax para conseguir hacerlas más accesibles.

Por una parte, el hecho de ser más dinámicas nos permite una interacción mejor, y si ésta está más cuidada, podemos hacerla mucho más compatible con muchos timpos de deficiencias, sobre todo visuales (a nivel cromático, por ejemplo). De hecho, no resulta dificil en una aplicación ofrecer un cambio cromático accesible, o un aumento del tamaño del texto.

El problema estaba en los lectores de pantalla, que hasta ahora parseaban la página al entrar (casi como un robot web), y cualquier actualización posterior no conllevaba a la lectura. Es decir, que al entrar en una Web, JAWS nos leería el primer contenido que nos encontraba, pero si cambiabamos cualquier cosa con innerHTML, el lector no se enteraría de nada, salvo que hiciéramos unos hacks poco recomendables.

Pues bien, leo en Sentido Web, que la gente de Juicy Studio ha estado trabajando en ello y ahora es posible dar más accesibilidad a nuestras Webs que usen Ajax. ¿How-to?

Primero estaría bien dar una pasada rápida a cómo funcionan los lectores de pantalla. En este artículo lo explican bastante bien, denotando los problemas con Ajax, y los modos de lectura.

JAWS utiliza un buffer virtual, que de forma normal, se actualiza de forma síncrona en función de las acciones del usuario. Pero al igual que Ajax lo que hace es “asincronizar” nuestra aplicación, también debemos “asincronizar” dicho buffer virtual, haciendo que nuestras llamadas al servidor también actualicen a JAWS (hablando rápido y mal).

Si vais a la página del artículo podéis ver el pseudocódigo que haría esto, bastante claro y sencillo. Al final, se trata de un hack o engaño al programa, pero que nos puede servir para cumplir nuestros objetivos de accesibilidad, y quizá una alternativa al formato “texto plano”.