Archivo de la categoría: Internet

El creador de Telegram y del ‘Facebook ruso’ afirma que las agencias de EE.UU. intentaron sobornarlo – RT

El creador de Telegram y del ‘Facebook ruso’ afirma que las agencias de EE.UU. intentaron sobornarlo

Origen: El creador de Telegram y del ‘Facebook ruso’ afirma que las agencias de EE.UU. intentaron sobornarlo – RT

Consejos para un linkeo responsable.

Fuente: http://circuloesceptico.com.ar/2014/01/consejos-para-un-linkeo-responsable .

Consejos para un linkeo responsable

shareEl movimiento escéptico no es ajeno al Efecto Streisand. ¿En qué consiste? Se trata del efecto indeseado de lograr un aumento en la difusión de algo (sitios y contenidos, en el caso de internet) cuando uno originalmente buscaba lo contrario. Parece una paradoja, pero a veces sucede que ese contenido se termina conociendo mucho más gracias a nuestra intervención de lo que se hubiera conocido de otra manera.

Un ejemplo reciente es el caso de Burzynski intimidando a un joven blogger que escribió un artículo crítico de sus “antineoplastones” y que sólo sirvió para difundir aún más las críticas contra él. O el de la multinacional homeopática Boiron, que amenazó con demandar a un blogger italiano y nuevamente se encontró con más mala publicidad. Sin embargo, la realidad es que este efecto va para los dos lados y como escépticos tenemos que cuidarnos de que nuestras críticas no resulten en más publicidad para los mercaderes de pseudociencia.

Esto no es un miedo infundado sino una realidad. Por ejemplo, el caso de una compañía que trataba mal a sus clientes para que éstos escribieran críticas en internet que aumentaban su ranking en las búsquedas en google (aunque algunos dudan de esta estrategia, google reaccionó). Los algoritmos de búsqueda no entienden la complejidad y la angustia de la existencia humana, sólo entienden los links.

Es por esto que en el Círculo Escéptico Argentino nos cuidamos de siempre usar el atributo NOFOLLOW cuando en un artículo linkeamos a un sitio pseudocientífico.  Con este atributo uno se asegura que esos links no aumenten el PageRank que Google le da a esa página. Pero una cosa que no se puede controlar son los links que se comparten en las redes sociales. Si desde nuestra cuenta de Twitter o página en Facebook compartimos contenido de algún sitio web bien magufo para reírnos de él, en parte estamos aumentando su popularidad. El efecto Streisand entra en acción.

unlike 1024x209 Consejos para un linkeo responsable

Pero los links compartidos en Facebook no sólo aumentan la popularidad de las páginas porque más gente puede verlas, sino que también sirven para aumentar la popularidad de las páginas de Facebook asociadas a esos sitios web. Aparentemente, el número de “Likes” y “Recomendaciones” que muestra una página en los pequeños botones para compartir no sólo refleja la cantidad de veces que se compartió mediante ese botón sino también las veces que la página se compartió mediante cualquier medio, incluso copiando y pegando la dirección en la biografía.

Eso quiere decir que cada vez que alguien comparte algún link en el grupo de facebook del CEA sólo para reírse y mostrar qué ridículo que es, ¡está aumentando la popularidad de ese contenido! Los escépticos nos encontramos entonces con un pequeño dilema. Queremos criticar a los vendedores de humo y la honestidad intelectual requiere mostrar el contenido que se critica, pero tampoco queremos promocionar su contenido y hacer que aparezcan en los primeros resultados de búsqueda en Google o como contenido recomendado en las redes sociales.

Los algoritmos no diferencian entre crítica y recomendación. Tim Farley (el genio detrás de What’s the Harmrecomienda un par de alternativas en lugar de compartir links directamente:

  • Escribir un post en un blog: Quien tenga un blog puede escribir una crítica del contenido que se quiere compartir, siempre linkeando con el atributo NOFOLLOW, y luego compartir ese contenido (presumiblemente de buena calidad) en vez del contenido de mala calidad que se quiere criticar.
  • Compartir un post de otro blog: Si uno no tiene un blog propio o no tiene tiempo o conocimiento para escribir un artículo completo, es muy probable que alguien más haya escrito sobre el tema. Eso es lo que podemos buscar y difundir.
  • Compartir una versión archivada del contenido: Archive.org es un excelente sitio web con la misión de archivar la internet para futuras generaciones. Si la página web que se quiere compartir no está archivada, se puede hacer un archivo de la misma.

Finalmente, una muy buena herramienta si no queda otra y uno tiene muchas ganas de compartir es DoNotLink. Se trata de un servicio para acordar direcciones web como Bit.ly pero con la característica de que utiliza una serie de técnicas para asegurarse de que el link no se cuente como una recomendación en Facebook ni afecte el PageRank de Google. Ni siquiera hace falta entrar al sitio para crear el link, sólo hace falta agregar “http://donotlink.com/” antes de la dirección que se quiere compartir.

Entonces, si uno quiere compartir el sitio de la Asociación Médica Homeopática Argentina (http://www.amha.org.ar/), queda “http://donotlink.com/www.amha.org.ar”. Para hacer las cosas aún más fáciles, yo modifiqué el bookmarklet oficial de Facebook para que comparta la página que uno está viendo usando DoNotLink. Arrastren este link a su barra de favoritos y cuando quieran compartir algo de dudosa calidad, sólo queda hacer click en ese botón.

Es un poco más de trabajo, sí, pero es importante que no amplifiquemos el mal contenido en la web. El tema central es NUNCA linkear directo a contenido pseudocientífico. Cuidemos nuestros links.

La inteligencia británica tiene «pinchada» la red global de cables de fibra óptica

via Facebook http://www.abc.es/internacional/20130621/abci-espionaje-cables-britanicos-201306211947.html

Sangakoo: Red social para aprender matemáticas.

Fuente:

http://www.sangakoo.com/

En Sangakoo los usuarios aprenden matemáticas generando sus propios problemas e intercambiándolos mediante una red social muy especial.

Sangakoo es una nueva manera de aprender matemáticas: Eliges el tema por el que quieres empezar, resuelves los ejercicios y creas tus propios problemas de matemáticas.

Puedes interactuar con otros usuarios desde cualquier lugar del mundo y a la hora que quieras.

Problemas de accesibilidad asociados al color.

Fuente:

http://www.juanhidalgoreina.com/2011/03/problemas-de-accesibilidad-asociados-al-color/

Problemas de Accesibilidad asociados al color.

Publicado
14 de marzo, 2011.
Autor
Juan Hidalgo Reina

Primero indicar que es necesario no basarse en el color, tal y como se indica en las WCAG.

En el punto de verificación 2.1 de las WCAG 1.0 se indica ” Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores”.

Pongamos un ejemplo, que ocurre cuando por alguna razón diseñamos una tabla con barras de diferentes tonalidades de rojos, y ponemos unatablita indicando que significa cada tono de rojo. Vale, preciosa tabla, pero y si esa persona tiene por ejemplo Protanopia?. Los usuarios que tiene esta “disfunción visual“, tienen una carencia de sensibilidad al color rojo.

Genial hemos conseguido que los usuarios con esa discapacidad no puedan acceder, ni comprobar la información, solo por que hemos decidido poner ese color.

Puedo decir sin animo de equivocarme que la mayoría de los sitios que certifican Accesibilidad (no digamos los que no certifican), tienen carencias graves en los valores de brillo y contraste de los tonos empleados. Algunas veces por un leve descuido, otro por que el diseñador tiene mayor peso que la necesidad implícita de Accesibilidad, y otras por que no se ha tenido en cuenta. Existen otras situaciones pero prefiero obviarlas por los términos que se suelen emplear.

Información transmitida por el color.

Por ejemplo observemos este ejemplo, en el observamos un error de lo mas común. Indicamos y planteamos una funcionalidad basada en el color. El campo obligatorio está en color rojo.

Uso incorrecto de transmisión de información por el colorUso incorrecto de transmisión de información por el color.

Esto es un grave problema para muchos usuarios, pues en cierta medida anteponemos criterios estéticos y comportamientos visuales corporativos a toda costa, sin valorar ni constatar el perjuicio que estamos ocasionando.

Como se resuelve este tipo de problemas?

Pues simplemente debemos poner por ejemplo, “Los campos obligatoriosestán marcados en rojo y con asterisco”, tal y como aparece en el ejemplo siguiente. La información se sigue transmitiendo por el color, pero tambiénpor el marcado. Independientemente del dispositivo o de la discapacidad visual, el asterisco está perfectamente marcado.

Caso de uso de transmisión de información por el color y marcado.Caso de uso de transmisión de información por el color y marcado.

Brillo y color

El Punto de Verificación 2.2 de las WCAG 1.0 nos indica que lascombinaciones de color de fondo y de primer plano deben ofrecer suficiente contraste para ser visualizadas por personas con discapacidad visual, o tener el suficiente contraste para pantallas en blanco y negro.

Para ello el W3C nos sugiere la utilización de un algoritmo que nos determinará un valor de contraste suficiente.

Por ejemplo debemos tener mucho cuidado con las combinacionesempleadas en el site. Los diseñadores tenemos una facilidad innata por poner tonos imposibles (muchos de mis profesores, dirían que en determinadas situaciones atentan contra la teoría del color), y sobre todo por poner una degradaciones de color, que queden bellísimas pero que a simple vista puedan pasar inadvertidas por muchos usuarios que no tengan ningún tipo de discapacidad visual, por lo que imaginemos lo que puede ocurrir con los que si la tengan.

A continuación os pongo una captura de mi pagina de FACEBOOK, en la que se puede observar como ese tono NO cumple las necesidades requeridas para validar en Brillo y Color.

Problemas de color en FacebookProblemas en el todopoderoso Facebook.

En la captura de imagen anterior, podéis observar una de mis herramientas de cabecera, un magnifico plugin para Firefox(ColorChecker). Os animo a que lo instaléis, y que por ejemplo probéishaciendo click en la casilla de verificación “Selector de texto“,

Revisad por encima las siguiente webs, y comprobad que tipo de problemas de accesibilidad tienen los cuerpos de texto.

http://www.bde.es/webbde/es/

http://www.iberia.es

http://mailchimp.com/

Ahora bien, a pesar de que el W3C en las WCAG 1.0 recomienda la utilización del algoritmo anteriormente citado, el cual se basa en la diferencia de brillo y color, os recomiendo lo que a mi me han recomendado desde que salieron las WCAG 2.0.

Hay que utilizar el nuevo algoritmo de Luminosidad. Por que? pues por que las WCAG 2.0 conllevan una serie de revisiones y mejoras, el nuevo algoritmo ya es una mejora evidente.

Diferencias entre algoritmos

WCAG 1.0 (Algoritmo de Brillo y Color)

  • La diferencia de brillo debe tener un rango igual o superior a 125 como mínimo.
  • La diferencia de color debe tener un valor mínimo de 500.

OJO hay muchos sitios en los que los validadores o chequeadores de color, comentan algunas variaciones realizadas por HP creo recordar.

WCAG 2.0 (Algoritmo de Luminosidad)

  • En función de la tamaño y estilo del texto e incluso de nivel de conformidad, se establecen como ratio mínimo de luminosidad, 3:1, 4.5:1 o 7:1.

Brillo y color en imágenes, logotipos, etc.

Cuando por ejemplo las imágenes lleven texto, esa información debe aparecer si o si en el ALT.

En las WCAG 2.0 los logotipos están exentos de cualquier tipo de restricción por contraste. Anteriormente en las WCAG 1.0 no es que se obligase a cumplir la restricción y ahora en las WCAG 2.0 no, simplemente que antes no se tenían en cuenta algunas particularidades como la implantación, o la experiencia documentada que genera el tiempo transcurrido entre las ambas WCAG .

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Fuente:

http://olgacarreras.blogspot.com/2011/02/accesibilidad-integrada-en-todas-las.html

Domingo 27 de febrero de 2011.

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Como consultor de usabilidad y accesibilidad es fundamental, cuando formas parte del grupo de trabajo que va a desarrollar una aplicación Web, conocer el marco metodológico del Diseño Inclusivo para incluir los requisitos de accesibilidad y usabilidad a lo largo de todo el proceso de desarrollo. Ello permitirá crear aplicaciones usables y accesibles cuya calidad perdure en el tiempo.

El objetivo de este artículo es difundir el marco metodológico AWA para el desarrollo de aplicaciones web accesibles, pues es un excelente ejemplo de metodología de Diseño Inclusivo que ayuda a comprender las bases en las que se debe asentar un desarrollo que tenga la accesibilidad y la usabilidad presentes en todas las fases del proceso.

Para ampliar información o contactar con su autora recomiendo acceder directamente a su web:AWA (Accessibility for Web Applications) También recomiendo su presentación Tutorial: Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (PDF)

Índice del artículo

  1. Introducción: marco metodológico AWA
  2. Pre-requisitos para la aplicación de AWA
  3. Fases y actividades
  4. Estructura del soporte metodológico AWA
  5. Checklist de seguimiento del cumplimiento de requisitos y mecanismos
  6. Casos reales: portal corporativo con Drupal.

Introducción: marco metodológico AWA.

AWA (Accessibility for Web Applications) es el marco metodológico para el desarrollo de aplicaciones web accesibles elaborado por Lourdes Moreno es su tesis doctoral: “AWA, Marco metodológico específico en el dominio de la accesibilidad para el desarrollo de aplicaciones Web”, 2010 [PDF, 8.5 MB].

El objetivo del trabajo es ofrecer un soporte metodológico para incorporar los requisitos de accesibilidad en todo el proceso de desarrollo de una aplicación web, aportando sistematización y un enfoque DCU que situé al usuario como protagonista. El marco de trabajo es el Diseño Inclusivo que involucra a los usuarios con necesidades especiales y a expertos en este tipo de necesidades y discapacidades. El estándar de referencia a lo largo del trabajo son las WCAG (1.0 y 2.0) y el cumplimiento de las mismas en las páginas web finales de la aplicación Web.

Uno de los errores habituales es afrontar la revisión de la accesibilidad cuando el desarrollo está muy avanzado, siendo más costoso y complicado aplicar los requisitos necesarios. Por otra parte, cuando la accesibilidad no se ha sistematizado en el desarrollo es mucho más difícil mantenerla durante el ciclo de vida de la aplicación Web.

Los objetivos finales son pues:

  1. conseguir que las páginas web finales generadas por la aplicación sean accesibles según las WCAG y usables desde el punto de vista del usuario,
  2. garantizar la calidad, es decir, que esta accesibilidad sea estable en todo el ciclo de vida de la aplicación web.

Es una propuesta flexible para que pueda ser aplicada a cualquier proceso de desarrollo de software que cumpla con los pre-requisitos mínimos.

Pre-requisitos para la aplicación de AWA.

La aplicación de esta metodología tiene como pre-requisito que la aplicación siga una arquitectura de modelo de más de dos capas (MVC) donde la lógica de negocio esté separada de la presentación, pues la separación de la presentación, la estructura y el contenido es un requisito imprescindible del diseño accesible. Además asegurará que las funcionalidades implementadas sólo en cliente (como AJAX) no dejen de funcionar.

Por otro la lado, la tecnología cliente deberá estar basada en estándares del W3C (XHTML, CSS, etc.) y tecnología servidor que no deje código en el lado del cliente (a excepción de AJAX que podrá ser utilizado junto con soluciones WAI-ARIA).

Fases y actividades.

Presupone un proceso de desarrollo con un enfoque iterativo y un ciclo de vida incremental, cuyas fases y actividades son:

Espiral en la que se señalan las fases y actividades que se enumeran a continuación:

Comunicación con el cliente:

  1. Análisis de negocio: identificación de metas y objetivos de la aplicación.
  2. Actividad de formulación: captura de requisitos que involucre a todos los participantes.

Planificación:

  1. Estimación de costes.
  2. Evaluación de riesgos.
  3. Planificación del desarrollo para definir tareas y plazos de cada incremento (plan de iteración)

Ingeniería:

  1. Análisis:
    1. Definición de requisitos técnicos, identificación de elementos de contenido y análisis del diseño gráfico.
    2. Requisitos de interacción: relación de los elementos de contenido y su funcionalidad asociada.
    3. Análisis de navegación: mecanismos de navegación que se van a proporcionar.
  2. Diseño:
    1. Diseño del contenido y diseño gráfico.
    2. Diseño de la estructura y el comportamiento de la aplicación en sí, incluyendo arquitectura, navegación e interfaz.
  3. Modelado: creación de modelos antes de la construcción.

Construcción:

  1. Implementación: de los modelos procedentes de la fase de ingeniería para construir la aplicación Web. Integración con software intermedio.
  2. Pruebas: para asegurar la calidad:
    1. Verificación: comprobación de que la aplicación es correcta desde la perspectiva del diseñador en relación al contenido, arquitectura, presentación, interfaz y navegación
    2. Validación: comprobación de que la aplicación hace y tiene la apariencia que el cliente esperaba.

Despliegue:

  1. Evaluación e interacciones de cambios.

Estructura del soporte metodológico AWA.

Estructura de soporte metodológico AWA: AWA_ Organización, AWA_Interacción y AWA_WCAG proponen AWA_Requisitos que activan AWA_Mecanismos

Componentes.

AWA_Organización.
Mecanismos para integrar planes y políticas de accesibilidad en la organización y equipo de desarrollo.

Se articula en torno a la elaboración de un Plan de accesibilidad (creación del grupo de accesibilidad, determinar la política de accesibilidad con el nivel de conformidad deseado, mecanismos para compartir el conocimiento sobre accesibilidad y plan de formación, seleccionar tecnologías accesibles, etc.) y laGestión de la accesibilidad (procesos a nivel interno pero también externo como la elaboración de requisitos para proveedores externos o la gestión de sugerencias de los usuarios)

Consultar mapa conceptual de AWA_Organización

AWA_Interacción.
Mecanismos para integrar un enfoque de DCU con inclusión, teniendo como instrumento base el estándar  ISO 13470:1999 (PDF, p.121) que se introduce en las páginas 121 y siguientes.

Se articula en torno a dos principios fundamentales:

  1. Involucrar a todos los usuarios, incluyendo al usuario con discapacidad en todo el proceso
  2. Considerar las características del usuario con discapacidad y la diversidad de contextos de uso en la Web.

Engloba técnicas de usabilidad con inclusión como: perfiles de usuario,personasescenariosprototipotormenta de ideascardsortingevaluación heurísticacuestionarios, entrevistas y encuestas, que se detallan en las páginas 129 y siguientes.

Consultar mapa conceptual de AWA_Interacción

En este capítulo 5 me parece muy interesante la tabla de correspondencia entre los criterios heurísticos de usabilidad y los criterios de conformidad de las WCAG 2.0 (PDF) (tabla que se explica en las páginas 155 y siguientes). Recurso muy útil para saber qué aspectos de la accesibilidad se están teniendo en cuenta cuando la usabilidad se incluye en un proyecto.

AWA_WCAG.
Abstracción de las WCAG (1.0 y 2.0) de manera que su tratamiento pueda ser incluido desde el inicio del proceso de desarrollo de una aplicación Web.

Puesto que no todos los requisitos pueden ser incorporados desde el diseño se distingue estos (AWA_WCAG Diseño) de los que son a nivel de implementación (AWA_WCAG Implementación: presentación con CSS, acceso por teclado, cambio de contexto o compatibilidad con terceras tecnologías) y de los que han sido definidos para ser incorporados en la actividad de evaluación (AWA_WCAG Evaluación)

Consultar los mapas conceptuales de AWA_WCAG para las actividades de diseño, implementación y evaluación

Requisitos.

AWA_Requisitos.
Como resultado se definen unos requisitos de accesibilidad que tienen tres objetivos principalmente:

  1. seguir las WCAG 1.0 y 2.0,
  2. seguir un enfoque DCU con Inclusión
  3. tener en cuenta la gestión de la accesibilidad considerando los requisitos de accesibilidad desde la organización como punto de partida.

En la notación de los requisitos se incluye el componente, por ejemplo:AWA_RequisitoOrganización PLAN 01.02: Declaración de Política de accesibilidad

Los AWA_RequisitosWCAG que hay que incorporar en la actividad de diseño se describen en las páginas 150 y siguientes, incluyendo por cada uno una tabla de correspondencia con las WCAG 1.0 y las WCAG 2.0. También se pueden consultar estas tablas accediendo en la web a cada una de las pautas WCAG 1.0 y WCAG 2.0

Consultar una tabla simplificada de correspondencias entre las WCAG 1.0, las WCAG 2.0, los AWA_Requisitos y los grupos de usuarios beneficiados.

Los AWA_Requisitos activan mecanismos de accesibilidad denominados AWA_Mecanismos.

Mecanismos.

AWA_Mecanismos.
Articulan la incorporación de los AWA_Requisitos desde el inicio del proceso. En la notación de los requisitos se incluye el componente, por ejemploAWA_MecanismoOrganización PLAN 01.02/02: Determinar Declaración de Política de Conformidad.

Checklist de seguimiento del cumplimiento de requisitos y mecanismos

Consultar checklist de seguimiento del cumplimiento de requisitos y mecanismos (PDF).

Casos reales.

En el capítulo 7 se explican casos reales de aplicación, uno de ellos el de la web del Centro Español de subtitulado y Audiodescripción (CESyA) gestionada con Drupal.

Se explica el enfoque de Diseño Inclusivo en la captura de requisitos combinando las técnicas de perfiles de usuario, personas y escenarios.

Se detalla la utilización de la técnica Card Sorting (manual abierta, automática con WebSort y manual cerrada) para adecuar la arquitectura de la Información al modelo mental de los usuarios.

La elaboración de un prototipo de bajo coste y reuniones Visual Brainstorming antes de abordar el diseño gráfico, así como la elaboración posterior de un prototipo software funcional, evaluándolo por expertos (evaluación heurística) y mediante pruebas de usuarios con y sin discapacidad (consultar cuestionarios a los participantes en el test de usuarios y a los testers (PDF)).

Aplicando todo lo anterior se crearon las plantillas de Drupal y se validó su accesibilidad.

Me parecen fundamentales todos los mecanismos que se llevaron a cabo en Drupal para asegurar que la inclusión de contenido a través del gestor diera lugar a contenido accesible y por tanto páginas que cumplen los niveles de conformidad AA.

Para ello se incluyó un editor de contenido con criterios de accesibilidad que transformara los datos introducidos en código válido. Por ejemplo, al incluir una noticia se pide el título (que se incluirá como encabezado), el idioma (aplicará en el código la identificación del idioma si no se corresponde con el idioma de la página), etc.

Me gustaría destacar las características y restricciones que debe tener el editor de contenido de un CMS para que el contenido resultante sea accesible:

  1. Edit text: permite escribir texto plano e incluye una opción guiada donde no se puede incluir tags (X)HTML
  2. Specify language: puedes seleccionar el idioma mediante una select.
  3. Add header: permite incluir un encabezado de un nivel específico, pero si existe un nivel de encabezado ya definido que englobe el actual documento, el nivel relativo se ajustará a ese nivel global, siendo relativo a éste. Se puede especificar también su idioma.
  4. Add image: siendo obligatorio la URI y el texto alternativo, y opcionalmente el longdesc
  5. Add multimedia: permite incluir vídeo siendo obligatoria la URL, el recurso de subtitulado y audiodescripción, y su lenguaje.
  6. Add link: siendo obligatorio la URI y pudiendo incluir un title y el lenguaje de la página de destino.
  7. Add abbreviation: que permita incluir un contenido con texto abreviado, pudiendo especificar su idioma.
  8. Add acronym: permite incluir un acrónimo, pudiendo especificar su idioma.
  9. Add list: añade una lista de diversos tipos.
  10. Add table: permite incluir una tabla, indicando filas, columnas, encabezados, resumen, etc..
  11. Add form: añade un formulario, permitiendo incluir los elementos típicos de formularios HTML mediante “Add element”. “Specify action” permite indicar la acción que realizará el formulario al ser enviado.
  12. Finish editing: finaliza la edición del contenido, comprobando que éste cumple con las especificaciones definidas y lo inserta en el sistema de persistencia, quedando a la espera de una revisión de accesibilidad (AWA_RequisitoWCAG EVA 01) para su publicación definitiva.

Esta revisión manual del contenido incluido en el editor para que pueda publicarse tiene en cuenta los puntos de las tabla de la página 241.

El Ipad que cambió la vida de Leo, un niño con autismo.

Fuente:

http://www.yaestaellisto.com/el-ipad-que-cambio-la-vida-de-leo-un-nino-con-autismo/

EL IPAD QUE CAMBIÓ LA VIDA DE LEO, UN NIÑO CON AUTISMO

Escrito por Alfred

Imagen (c) 2010 Shannon Des Roches Rosa.

Shannon Des Roches comenzó a escribir su blog Squidalicious en el 2003, cuando su hijo Leo contaba con tres años de edad.

Leo padece autismo y Shannon estaba convencida que el plasmar todas sus dudas, vivencias, visitas a especialistas y el día a día junto a su hijo ayudaría a llevarlo mejor, a la vez que abría un puente de comunicación con otros padres de niños autistas.

Como cualquier otro progenitor, con un hijo en esas circunstancias, Shannon se esforzaba por conocer más a fondo este trastorno que afectaba a los vínculos de comunicación de Leo con los demás.

Ese ánimo por investigar y conocer más profundamente el autismo desde otras muchas perspectivas la llevo a publicar los librosCan I Sit With You? y ‘Can I Sit With You Too?

A principios de mayo de 2010, Shannon observó como el iPod Touch recién adquirido despertaba interés en su hijo, aunque la torpeza del niño con las tareas motoras hacía que el manejo de éste fuese dificultoso.

Pero dos semanas después un boleto de 5 dólares para una rifa escolar cambió la vida de Leo y toda su familia al completo.

Imagen (c) 2010 Shannon Des Roches Rosa.

Ese boleto fue agraciado con un iPad y al recibirlo Shannon decidió dejárselo usar a Leo.

Al contrario que el iPod Touch, el Ipad parecía hecho a la medida de Leo y sus dedos. En tan solo un día descubrió la infinidad de posibilidades que tenía con el dispositivo y como se desenvolvía con él.

Tareas tan básicas como las de escribir o dibujar habían sido complicadas hasta aquel momento, mientras que con el iPad realizaba sencillos dibujos utilizando su dedo sobre la pantalla táctil. Programas de aprendizaje para niños pequeños eran de una gran utilidad y en pocos días los dominaba a la perfección.

El hecho de poder realizar todo a través de la pantalla y no tener que utilizar un teclado o lápiz hicieron que Leo desarrollase rápidamente nuevos intereses por aprender, quedando en muchos momentos absorto en su distracción con el dispositivo.

Imagen (c) 2010 Shannon Des Roches Rosa.

Hasta hacía muy pocos días, Leo había sido dependiente de otras personas para poder entretenerse, aprender, jugar o comunicarse, desde que el iPad entró en aquel hogar cambió por completo la vida de todos sus habitantes.

Tal es la satisfacción de Shanon y su familia que en uno de sus post decía:

(…)I may erect a tiny altar to Steve Jobs in the corner of our living room(…) (Puedo erigir un pequeño altar a Steve Jobs en una esquina de nuestra sala de estar)

A través de sus entradas en el blog, Shannon ha ido publicando toda la evolución, desarrollo y mejoría de comunicación que ha tenido su hijo Leo.  Puedes seguirlo a través de este link: www.squidalicious.com

También puedes visionar algunos de los vídeos de Leo con su iPad que Shannon ha ido subiendo a la red:

(Fuentes y más info: squidalicious blogher).