HTML5: situación actual y futuro

HTML5 es "el milagro, la piedra filosofal, el Dorado del desarrollo web". Los que llevamos muchos años en el desarrollo web la estábamos esperando desde hacía tiempo: una tecnología estándar, compatible con todos los dispositivos y con las suficientes características que nos permitan hacer todo lo que queramos sin tener que depender de terceras tecnologías. Una tecnología que nos permita construir desde un "Smart a un Hummer", desde un "Lada a un Lamborghini". Desgraciadamente, por ahora es un espejismo.

El artículo HTML5 still taking shape nos cuenta algunas cosas interesantes sobre la situación actual de HTML5 y sobre las expectativas que se han creado a su alrededor. Además, plantea el dilema entre desarrollar una aplicación nativa para cada dispositivo o el desarrollo de una aplicación web compatible con todos los dispositivos. A continuación, la traducción de los párrafos más interesantes:

Hoy en día, hay pocas dudas de que la industria ha adoptado HTML5 como la mejor solución para el desarrollo y distribución de aplicaciones ricas (rich applications) compatibles con múltiples navegadores y dispositivos. Somos testigos de la desaparición de Flex, del reposicionamiento de Flash, y del anuncio de Microsoft de que Silverlight 5 será la última versión para navegador.

[...]

"Esto no tiene precedentes en nuestra industria", dijo [Todd Anglin]. "Cada uno ha querido construir y poseer la plataforma, pero con la explosión de dispositivos en el mercado, ahora quieren ser dueños de las herramientas y los servicios".

¿Puede que todo esto se remonte a la decisión de Apple de no permitir plugi-ns y entornos de ejecución en su iPhone? En parte. Pero también se debe al creciente número de nuevos dispositivos que salen al mercado, cada uno con diferentes sistemas operativos. "Los plug-ins simplemente no se pueden mantener al día con el rápido aumento de todos estos dispositivos", dijo Anglin. "Incluso si se les permitiese, no podrían mantener el ritmo".

Jacobs citó un estudio que declaraba que dos mil millones de teléfonos móviles con navegadores estarán en circulación en dos años a partir de ahora, y todos esos navegadores afirman soportar los desarrollos basados en HTML5.

Pero es demasiado pronto para declarar a HTML5 el ganador en el desarrollo de aplicaciones web, afirman los expertos. De acuerdo con el sitio web builtwith.com, sólo el 8% de los principales 100.000 sitios web tienen algo de HTML5 detrás de ellos, y sólo el 14% de los principales 10.000 sitios tienen algo de HTML5, aunque sólo sea el empleo de Canvas. Además, sólo el 46% de los usuarios de Internet actuales tienen un navegador compatible con HTML5.

El problema, según Anthony Franco, presidente y cofundador de la empresa de desarrollo de software EffectiveUI, es que HTML5 aún no es un estándar. "Sólo porque alguien dice que su navegador es compatible con HTML5 no quiere decir que sea un estándar. Todos los navegadores soportan la recomendación del W3C [por HTML5] de diferentes formas", dijo.

[...]

Por lo tanto, ¿ha llegado HTML5 al nivel de Flash y Silverlight? La mayoría de los expertos dicen que todavía no, pero se está camino de ello.

[...]

También dijo el Grupo de Trabajo de Aplicaciones Web del W3C está trabajando en una nueva iniciativa para hacer frente "al acceso universal a las aplicaciones web mediante una amplia gama de dispositivos y por una gran diversidad de usuarios".

[...]

Uno de estos debates gira en torno a las necesidades del usuario y la experiencia del usuario. Montones de investigaciones muestran que los usuarios abandonan un sitio web si es lento en responder o no puede ofrecer lo que el usuario desea. Así que, una decisión a la que los desarrolladores web se deben enfrentar es la de escribir una aplicación que es nativa para un dispositivo, o utilizar los estándares web para llegar a más dispositivos.
[...]

¿Qué aproximación se debe adoptar?¿Flash? ¿Silverlight? ¿HTML5/JavaScript/CSS3/SVG?

Anthony Franco, presidente y cofundador de la empresa de desarrollo de software EffectiveUI, dijo que se debe contestar una serie de preguntas antes de elegir la plataforma de desarrollo:

1. ¿Cuál es la duración esperada de la aplicación? ¿Con qué frecuencia se volverá a rescribir?
2. ¿Cuál es el conjunto de habilidades de los desarrolladores? Las estadísticas muestran que hay cerca de 5 millones de desarrolladores web en el mundo, mientras que hay menos de 200.000 desarrolladores de Objective-C (para escribir aplicaciones nativas de iOS).
3. ¿Dónde tiene que residir la aplicación?
4. ¿Cómo de "rica" necesita ser la aplicación?
5. ¿Cómo de integrada en los sistemas software actuales necesita estar?
6. ¿Cuánto está dispuesto a poner en peligro las características de la aplicación en función de la plataforma elegida?

Más información:

• Accesibilidad en HTML5 (28/05/2011)
• ¿Qué le falta a la especificación de HTML5? (28/02/2011)
• Nuevo calendario para HTML5 (21/02/2011)
• El futuro de la accesibilidad web con HTML5 (04/11/2010)

Donación a Médicos Sin Fronteras

Hace unos meses organicé el curso Introducción a la accesibilidad web en la Universidad de Alicante. El importe íntegro de la matrícula del curso se destinó a una donación para Médicos Sin Fronteras. La donación fue de 2.400€: se matricularon 8 alumnos y el importe de la matrícula era de 300€.

Acabo de recibir una carta de Médicos Sin Fronteras en la que se certifica que la donación ha sido efectiva:

[...] 
2. Que con fecha 16/12/2011 hemos recibido un total de 2400,00 Euros de UNIVERSIDAD DE ALICANTE DTO DE LENGUAJES Y SISTEMAS INFORMATICOS con domicilio social en CAMPUS DE SANT VICENT DEL RASPEIG AP. 99 en SANT VICENT DEL RASPEIG (ALICANTE) en concepto de donación irrevocable destinada a apoyar los proyectos de Médicos Sin Fronteras.

2.400€ nos puede parecer poco dinero, "un vaso de agua para millones de bocas sedientas", pero en los países a los que se destina la ayuda de Médicos Sin Fronteras, 2.400€ puede salvar muchas vidas.

Recopilación de entradas sobre el control mental del ordenador

Ayer tuve una reunión con un grupo que hemos formado para plantear proyectos relacionados con la mejora de la calidad de vida de las personas mayores. Uno de los temas que estamos contemplando es la inclusión de los grandes dependientes y una de las posibilidades que nos hemos planteado es la aplicación de algún sistema de control mental para que puedan utilizar el ordenador.

El control mental (mind control en inglés) es la posibilidad de controlar un dispositivo simplemente con el pensamiento. Para ello se emplean interfaces cerebro-ordenador (brain-computer interfaces).

En el siguiente vídeo podemos ver un ejemplo de control mental de un brazo robótico por parte de una persona que ha perdido un brazo: no es exactamente un control mental completo, ya que este tipo de control mental se aprovecha de los nervios que controlaban el movimiento del brazo que perdió.



El control mental completo es el que podemos ver en el siguiente vídeo en el que un mono controla con su pensamiento un brazo robótico. Aunque no se puede ver, pero se puede intuir, el mono tiene un implante dentro de su cerebro al cual se conectan unos cables que transmiten sus señales eléctricas cerebrales a un ordenador que las procesa. Este sistema es invasivo, porque requiere de una cirugía cerebral que entraña grandes riesgos. Comercialmente, estos sistemas no tienen mucho futuro. Pero son el primer paso.



En la actualidad, lo que se intenta desarrollar es un sistema no invasivo, a modo de casco que se pueda quitar o poner el usuario en cualquier momento. Por ahora, los sistemas no invasivos obtienen peores resultados que los sistemas invasivos (los sensores captan mucho "ruido cerebral"), pero todo es cuestión de tiempo.

Ya existe algún sistema comercial que se puede comprar "en la tienda", como el sistema Emotiv Epoc. El precio de venta actual son $299, lo cual es una ganga si realmente se puede hacer lo que promete (que lo dudo). En el siguiente vídeo nos lo explican y nos lo muestran en funcionamiento.



El objetivo final de todo esto es poder utilizar el ordenador con la mente en vez de con el teclado y el ratón. Del avance más prometedor me hice eco el año pasado en la entrada Otros que se apuntan al control mental del ordenador (05/06/2011). En la Universidad Ben-Gurion de Negev, han logrado que una persona pueda escribir un correo electrónico de 12 caracteres en 7 minutos, pero después de que la persona haya recibido un entrenamiento específico para ello.

En estos últimos años he escrito varias entradas sobre este tema. Todas ellas se encuentran disponibles en la etiqueta control mental, pero a continuación resumo algunas de las más importantes:

Universidades españolas

• Universidad de Zaragoza: Control mental, a la española (06/05/2009)
• Universidad de Cartagena: Investigación sobre control mental del ordenador (17/08/2009)
• Universidad Miguel Hernández: Otra noticia más sobre el control mental del ordenador (01/02/2010), Y siguen las noticias sobre el control mental del ordenador (02/02/2010)

Universidades extranjeras que investigan en control mental

• Universidad de Pittsburgh (EE.UU): Dos monos controlan un robot con la mente (30/05/2008), Un mono controla el brazo de un robot con su mente (14/06/2010)
• Universidad de Braunschweig (Alemania):  Control mental sin electrodos en contacto (19/06/2008)
• Universidad de Nueva York (EE.UU.): En la próxima década llegará el control telepático de los ordenadores (18/05/2010)
• Escuela Politécnica Federal de Lausana (Suiza): Control del ordenador con la mente (01/11/2010)
• Universidad de Tel Aviv (Israel): Investigación sobre el control mental del ordenador con la mente en Israel (18/11/2010)
• Universidad de Mahidol (Tailandia): Una noticia sobre investigación en control mental del ordenador en Tailandia (24/11/2010)
• INRIA (Francia): En Francia también investigan sobre el control del ordenador con la mente (16/01/2011)
• Universidad de Brown (EE.UU.): Un interfaz neuronal sigue funcionando después de 1000 días (29/03/2011)
• Universidad Ben-Gurion de Negev (Israel): Otros que se apuntan al control mental del ordenador (05/06/2011)
• Universidad de Duke (EE.UU.): Unos monos "mueven y sienten" objetos virtuales utilizando sólo el cerebro (06/10/2011)
• Centro de Excelencia para el Aprendizaje en Educación, Ciencia y Tecnología (EE.UU.): Otro centro en el que investigan el control mental del ordenador (25/10/2011)

Productos comerciales

• Emotiv: El control mental del ordenador avanza con pasos de gigante (30/06/2008), Más sobre control mental (07/06/2008)
• MindFlex: Control mental: ya lo podemos comprar (30/12/2009)
• Neurosky: Otra empresa que se apunta al control mental (02/07/2010)

BrailleTouch para iPhone e iPad

El artículo Georgia Tech Develops Braille-Like Texting App presenta un prototipo de aplicación gratuita para móvil con pantalla táctil que permite convertirlo en un teclado braille. Por ahora se trata de un prototipo para iPhone y iPad, pero ya están trabajando también en la versión para Android.

Un teclado braille es un dispositivo de entrada que permite representar cualquier carácter mediante la pulsación simultánea de unas pocas teclas, lo que permite alcanzar una gran velocidad de escritura. Los teclados braille suelen poseer 6 u 8 teclas principales, más una serie de teclas auxiliares. En el caso de BrailleTouch, el teclado es la pantalla táctil del móvil y está compuesta por 6 teclas que pueden pulsarse simultáneamente.

En principio, parece que lo han desarrollado para todo el público, no sólo para los usuarios ciegos, pero los usuarios ciegos se pueden beneficiar enormemente ya que un iPhone con este software puede sustituir a aparatos más caros y pesados como el PAC Mate Omni.

Un vídeo donde se explica su uso y se hace una demostración (incluye subtítulos en inglés que se pueden traducir automáticamente al castellano):

El proceso de estandarización del W3C

Ayer escribí la entrada De los estándares, normas, recomendaciones y otras "tonterías" en la que quise explicar lo importante que son los estándares en nuestras vidas y los beneficios que nos aportan. Aunque no nos demos cuenta, estamos rodeados de estándares por todas partes: el tamaño del papel que tengo encima de mi mesa, el casquillo de la bombilla que ilumina mi oficina, el conector USB del teclado y del ratón que estoy usando ahora mismo, la disposición de las teclas en el teclado que estoy usando ahora mismo para escribir este texto, etc., todo eso y mucho más está basado en estándares internacionales que nos hacen la vida un poco más sencilla. Sin los estándares, la vida podría ser un auténtico caos.

Y por supuesto, el lenguaje HTML, CSS, DOM y JavaScript con el que está creado Blogger y que me permite usarlo con cualquier navegador, lo que me evita el tener que tener un navegador concreto que me exija Google para poder usar Blogger. Mejor no imaginemos qué pasaría si no hubiese estándares en el desarrollo web...

Los estándares (también llamados normas) se pueden clasificar de diferentes formas. Así, por ejemplo, podemos hablar de:

• Estándar cerrado, abierto o libre.
• Estándar legal (de iure) o de hecho (de facto).
• Estándar nacional, internacional o industrial.

Los estándares normalmente son creados por organizaciones, públicas o privadas, como puede ser AENOR en España, DIN en Alemania, ANSI en Estados Unidos o ISO a nivel internacional. Estos estándares pueden estar oficialmente respaldados en el ordenamiento jurídico de un país, es decir, son de obligado cumplimiento por ley.

El World Wide Web Consortium (W3C) es un consorcio internacional e independiente que fue fundado en octubre de 1994. Está formado por empresas, organizaciones gubernamentales y no gubernamentales, que tiene como misión guiar la Web hacia su máximo potencial. Para ello, el W3C promueve la evolución e interoperatividad de la Web desarrollando especificaciones, protocolos y recomendaciones.

En la actualidad, el W3C no tiene el mismo peso legal que tiene, por ejemplo, ISO. Supongo que por ello, las especificaciones y protocolos que crea el W3C se llaman "recomendaciones", aunque en el mundo del desarrollo web reciben la misma consideración que cualquier estándar en otra industria. Las recomendaciones del W3C son estándares de hecho: estándares no oficiales, pero que debido a su enorme penetración y aceptación en el mercado, tienen el mismo peso que un estándar oficial.

Desgraciadamente, un estándar no es siempre la mejor opción posible entre todas las existentes, y muchas veces se tarda mucho en desarrollar un estándar porque hay que encontrar un consenso entre muchas partes, cada una con sus propios intereses (no creamos que W3C es una organización tan independiente como se pueda pensar, ya que está formada principalmente por personas de las empresas y organizaciones que más intereses tienen en el tema, como Microsoft, Google, Apple, Opera y Mozilla). Es el precio que hay que pagar para luego poder tener una serie de beneficios.

Para lograr el consenso entre todas las partes implicadas, el W3C tiene definido un proceso (World Wide Web Consortium Process Document). Este proceso consta de siete pasos:

1. Submission: un miembro del W3C puede enviar una propuesta de estándar al W3C.
2. Note: a menudo, la propuesta se convierte en una nota que se hace pública. Una nota es simplemente la exposición pública de una propuesta. No supone en ningún modo que tenga el apoyo del W3C, no supone que se haya iniciado ningún trabajo de estandarización y el único propósito es crear un foro de discusión.
3. Working Group: cuando el W3C reconoce que una propuesta tiene interés y se debe desarrollar, se establece un grupo de trabajo. El grupo de trabajo establece un calendario de trabajo y publica un primer borrador con la propuesta que se quiere estandarizar.
4. Working Draft: un borrador de trabajo es un documento que se expone públicamente para mostrar el progreso en el desarrollo de una nueva recomendación. Junto con su publicación se establece un calendario para que el público pueda participar y enviar comentarios y correcciones. Un borrador de trabajo nunca se debería emplear como material de referencia, porque puede ser actualizado, reemplazado o incluso declarado como obsoleto en cualquier momento.
5. Candidate Recommendation: una recomendación candidata es un borrador de trabajo que ha alcanzado un alto nivel de madurez, pero que también puede ser actualizado, reemplazado o incluso declarado como obsoleto en cualquier momento, como cualquier otro borrador de trabajo. El propósito de la recomendación candidata es que sea implementada y probada para comprobar que su uso es factible.
6. Proposed Recommendation: después de que todas las características de la recomendación candidata hayan sido implementadas, se publica la propuesta de recomendación que representa la última etapa previa a la publicación definitiva de la recomendación.
7. Recommendation: una vez que la propuesta de recomendación haya recibido el apoyo suficiente, se publica la recomendación, que ya tiene el carácter de documento estable. A partir de ese momento, el W3C sí que apoya y fomenta su uso y difusión.

Posteriormente, una recomendación puede ser actualizada para corregir errores y clarificar algunos aspectos que puedan ser confusos o ambiguos. Pero esto no se convierte en una nueva recomendación, sino que es una nueva edición de la recomendación ya existente. Por ejemplo, XML 1.0 ya va por su quinta edición (26 de noviembre de 2008), aunque la primera edición fue publicada el 10 de febrero de 1998.

Evidentemente, algunas especificaciones son más complejas que otras, y pueden requerir más tiempo, más pruebas y la participación de más gente. Por ejemplo, WCAG 2.0 fue publicada el 11 de diciembre de 2008. Pero podemos encontrar un borrador de trabajo del 25 de enero de 2001.

Y algunas no llegan nunca a ser recomendación. Por ejemplo, el W3C estuvo trabajando en XHTML 2.0 más de ocho años (existe un borrador de trabajo del 5 de agosto de 2002) para nada, ya que su desarrollo fue cerrado el 17 de diciembre de 2010 en favor de HTML5.

Por tanto, como podemos intuir por todo lo anterior, crear una recomendación dentro del W3C no es el resultado de "cinco amiguetes que se reúnen dos tardes y escriben un documento". Es el resultado de un largo y laborioso proceso.

Para el que quiera saber algo más, le recomiendo la lectura de How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute, que ha sido traducido al castellano en Como la WAI desarrolla las pautas de accesibilidad en el proceso de la W3C: Hitos y oportunidades para contribuir.

De los estándares, normas, recomendaciones y otras "tonterías"

En mi anterior entrada, Cada vez que llamas a una característica propietaria "CSS3", un gatito muere, me han dejado unos comentarios interesantes.

Por un lado tenemos, a Álvaro y Rogelio, que comentan como justificación de por qué emplear características propietarias que, si el cliente te las pide, al final tragas. Bueno, todo depende de las "tragaderas" que uno tenga. Un día vi en un restaurante alicantino como salió el cocinero a hablar con unos clientes extranjeros cuando se enteró de que habían pedido ketchup para la paella que había cocinado con mucho cariño. Les dijo que si iban a hacer eso, prefería que se levantasen y se fuesen del restaurante inmediatamente sin pagar nada.

Claro, no se puede comparar el dinero que va a dejar una mesa en un restaurante normalito con el dinero que puede dejar un desarrollo web. Y claro, el dinero es del cliente, y si el cliente lo quiere usar mal, no vamos a ser nosotros los que le detengamos. Pero hay cosas que no se deben hacer: parte de la labor del desarrollador web (o mucho mejor, del agente comercial que trate con el cliente) es asesorar y convencer al cliente de lo que es bueno o malo. Por ejemplo, ¿es bueno hacer un sitio web para que sea compatible con Internet Explorer 6? He oído muchas veces la misma historia en boca de profesionales y alumnos que hacen sitios web: he hecho el sitio web compatible con Internet Explorer 6 porque así lo quería el cliente o el jefe... por ejemplo, porque es el navegador que él usa. Pues el cliente o el jefe se tiene que enterar de que el sitio web no se hace para él, sino para el resto del mundo, y el resto del mundo (incluido Microsoft) pasa de Internet Explorer 6 desde hace tiempo (The Internet Explorer 6 Countdown). En última instancia, si aún así el cliente o el jefe quiere que sea compatible con Internet Explorer 6, lo que se debe hacer es cobrarle una cantidad adicional por el trabajo extra que supondrá lograrlo. Entonces quizás se lo piense dos veces.

Por otro lado, en otros comentarios, Rogelio pregunta por qué se tarda tanto en crear los estándares y Félix cita el artículo Every Time You Make a Good Business Decision, a Puppy Gets Cloned que ha aparecido como respuesta a la "masacre de los gatitos". En este artículo, aunque se comparten muchas ideas aparecidas en el primer artículo, también se defiende el uso de las características propietarias como impulsor de desarrollo web y defiende que los estándares web no se deben tomar como una religión. Esperar a que exista un estándar puede ser pernicioso, pero el uso de no estándares puede ser mucho más pernicioso.

Por ejemplo, en España hemos tenido que sufrir durante muchos años que no hubiese una comunicación directa de la red española ferroviaria con la red de los países vecinos porque el ancho de vía español es superior al europeo. Afortunadamente, las líneas de alta velocidad (AVE) emplean el ancho de vía europeo y poco a poco se va solucionando la situación, después de más de 150 años de existencia del ferrocarril en España.

En todo el mundo hemos tenido que sufrir durante muchos años la ausencia de un estándar en los cargadores de móvil. El impacto ecológico que ha tenido la ausencia de un estándar (millones y millones de cargadores desechados), el impacto en los bolsillos de millones de usuarios que se han tenido que comprar un cargador nuevo porque ninguno de los que tenían en casa les servía, o el inconveniente de no encontrar un cargador adecuado y no poder recargar la batería del móvil, no se puede valor pero seguro que tiene muchos ceros. Afortunadamente, desde el año pasado los fabricantes de móviles emplean un mismo conector de tipo microUSB.

Desgraciadamente, en todo el mundo tenemos que seguir sufriendo la falta de un estándar en los enchufes eléctricos, en el voltaje y en la frecuencia de la electricidad. Algo tan "sencillo", no se ha podido solucionar después de más de 100 años de uso de la electricidad en lo hogares y tenemos que sufrirlo y pagarlo, tanto los usuarios finales como los fabricantes de productos eléctricos.

En la Web hay millones y millones de usuarios. El uso de tecnologías no estandarizadas es un error de cara a los usuarios finales y, para el desarrollador, lo más normal es que suponga un mayor esfuerzo inicial y mayores problemas de mantenimiento futuros.

Esto no significa un NO rotundo a lo no estándar: se puede emplear, pero con cuidado, teniendo en cuenta, por ejemplo, el concepto de mejora progresiva (progressive enhancement).

Mañana escribiré sobre el W3C y veremos su proceso de estandarización (o normalización).

Cada vez que llamas a una característica propietaria "CSS3", un gatito muere

¿Y quién no sufre cuando un gatito muere?

Hace unos días escribí la entrada El dominio de Google y Apple, peor que con Microsoft, en la que comentaba que se debe evitar utilizar las propiedades de CSS específicas de un vendedor, las que comienzan con un prefijo como -webkit- o -moz-. Acabo de leer el artículo Every Time You Call a Propietary Feature "CSS3", a Kitten Dies (publicado en A List Apart, referencia en el desarrollo web y en defender el uso de los estándares), que incide sobre el mismo tema.

A continuación, la traducción de algunos de los párrafos más interesantes del artículo:

Anuncio de servicio público: Cada vez llamas a una característica propietaria "CSS3", un gatito muere. Cualquier característica -webkit- que no exista en una especificación (ni siquiera en el borrador del editor) no es de CSS3. Sí, normalmente son evangelizadas como tales, pero no son parte de CSS, absolutamente. Esta distinción no es excesivamente puntillosa. Es importante porque anima a ciertos vendedores(*ejem* Apple *ejem*) a eludir el proceso de estandarización, les anima a poner en práctica todo lo que venga con WebKit, y a continuación a evangelizarla a los desarrolladores como la mejor cosa desde el pan en rebanadas. Los juguetes nuevos y relucientes nos deslumbran y empezamos a promocionarlos, contribuiyendo a la cámara de resonancia.

En nuestro afán por utilizar la última novedad, a menudo nos olvidamos de cuánta gente luchó en la última década para que nosotros podamos escribir código sin bifurcaciones y trucos y esperar que sea interoperable. Si has estado en este campo más de unos pocos años, seguramente recordarás que no siempre fue así. La razón por la que ahora tenemos esta comodidad es gracias a los estándares web, duramente ganada en la guerra de los navegadores (Browser Wars). 

[...] 

Las características propietarias que no han pasado a través del proceso de normalización, por lo general sufren de un diseño pobre, aun cuando la idea general sea buena. Por ejemplo, los gradientes en CSS fueron una gran idea, pero -webkit-gradient() era un gran lío susceptible de numerosos errores. Los tipos de letra web son una gran idea, pero requerir el uso de los ficheros .eot no lo fue. El proceso de normalización no sólo ayuda a lograr la interoperabilidad, sino que también ayuda a mejorar el diseño de cada función, debido a la mayor cantidad y diversidad de opiniones. 

Así que, ¿cuáles son esas características infames? En CSS, algunas de las más populares son:

• -webkit-box-reflect

• -webkit-text-stroke

• -webkit-mask

• -webkit-background-clip

• -webkit-text-size-adjust

• -webkit-tap-highlight-color

• -webkit-text-fill-color

No todas las características que lleven el prefijo del vendedor tienen que ser propietarias. Algunas de ellas son sólo las implementaciones experimentales de características incluidas en los borradores de las especificaciones. 

[...] 

La regla de oro es fácil: evita por completo las características propietarias. No las uses, no las evangelices, y sin duda alguna, no dependas de ellas.

Para finalizar, en el artículo The Future of CSS: Experimental CSS Properties, podemos encontrar una lista de características propietarias QUE NO DEBEMOS UTILIZAR (aunque en ese artículo nos inviten a ello). Además, en la mayoría de los casos, su utilidad es bien escasa.

Segundo encuentro sobre accesibilidad de las TICs en Madrid

El próximo martes 21/02/2012 se celebrará en Madrid el segundo encuentro sobre accesibilidad de las TICs, que es gratuito y al cual está invitado todo el mundo al que le interese este tema.

Por ahora, los temas que están anunciados que se van a tratar son:

1. Errores comunes: descripciones largas de imágenes, por Félix Zapata.
2. La CNMV en busca del AA, por Jesus Miguel Gimeno.
3. B.A.D: la demostración del antes y después de la WAI, por Alan Chuter
4. Como organizar los eventos futuros: Temáticas, formatos (charlas cortas, ponencias largas, mesas redondas, quedar para tomar cañas...)
5. Otros temas pendientes: ¿Te animas a compartir con nosotros tus conocimientos de algún tema relacionado con la accesibilidad? ¿Contarnos algo que te fastidia en un sitio Web inaccesible? Lo puedes proponer en el foro del grupo o por correo a los organizadores.

Curso "Accesibilidad web en base a las pautas WCAG 2.0"

TECNALIA organiza el curso Accesibilidad web en base a las pautas WCAG 2.0 en sus instalaciones del Parque Tecnológico de Bizkaia del 5 al 8 de marzo de 2012. El curso es gratuito y posee el siguiente contenido:


Accesibilidad web

• Accesibilidad: qué es, a quiénes afecta, ventajas
• Marco legislativo actual
• W3C y WAI

WCAG 2.0: Web Content Accessibility Guidelines

• Diferencias entre WCAG 1.0 y WCAG 2.0
• Proporcionar alternativas para los contenidos no textuales
• Multimedia accesible
• Crear contenidos que puedan presentarse de diferentes formas
• Hacer el contenido más fácil de ver y oír
• Operabilidad mediante el teclado
• Proporcionar tiempo suficiente
• Evitar los ataques
• Proporcionar ayudas a la navegación
• Hace comprensible el contenido
• Hacer contenidos predecibles
• Evitar y corregir errores
• Maximizar la compatibilidad 

Casos prácticos

• Casos prácticos de procedimientos para aplicar las WCAG 2.0
• Visualización de webs accesibles, buenas prácticas 

Metodología de evaluación 

• Revisiones automáticas: herramientas y recursos
• Revisiones manuales: técnicas heurísticas

Versión accesible del sitio web de la Sexta

El sitio web de la programación de televisión de la Sexta ofrece una versión accesible. En esta imagen podemos ver el aspecto de la versión "normal":

Justo al lado de los botones que permiten seleccionar el canal (la Sexta, la Sexta2 o la Sexta3), hay un enlace para acceder a la versión accesible:

Al acceder a dicha versión accesible aparece lo siguiente:

Me he quedado un poco horrorizado al ver esta página, porque se han cometido los dos típicos errores de alguien que quiere hacer un sitio web accesible, pero no tiene mucha idea:

• Versión accesible: versión alternativa, un segundo sitio web accesible simplificado.
• Versión accesible: versión fea, sin hojas de estilo.

Si exploramos el código de ambas páginas, veremos que la segunda, la supuestamente accesible, es un subconjunto de la anterior. La mayoría de las estructuras de contenido escritas en HTML, los identificadores o los nombres de las clases de CSS son los mismos. En realidad, la versión accesible no los necesita para nada, porque no se enlaza ningún CSS, pero los tiene.

A la vista del código HTML, me imagino que la gente de Genera, que son los que figuran como creadores del sitio web, debieron pensar y hacer algo como "quita el CSS, elimina el código JavaScript, borra algo de contenido para simplificar la página web y ya tenemos versión accesible, listos".

Pero se pasaron de listos, porque algo tan simple como un correcto uso de los encabezados (estructura de encabezados según HeadingsMap):

o el uso de enlaces significativos y que no repitan el mismo texto (lista de enlaces según Fangs):

o escribir un texto alternativo correcto y no cosas como:

• cosas_que_hacer_en_denver_cuando_estas_muerto
• directos_a_tu_corazon
• el_principe_de_las_mareas 

seguramente, consideraron que no era importante. Por no decir que, una vez en la versión accesible, los enlaces que contiene la página nos llevan otra vez a la versión normal (que se supone que es no accesible). Y no sigo porque tengo mejores cosas que hacer.

Espero que el desarrollo de esta supuesta versión accesible no haya supuesto un sobrecoste en el desarrollo del sitio web, porque habría sido una verdadera tomadura de pelo.

¿WCAG 1.0, WCAG 2.0, Norma UNE 139803 o qué?

El otro día me dejaron el siguiente comentario:

Tremendo lio tengo... muchos cursos ya estan orientados a WCAG 2.0, pero claro si te presentas a algún proyecto "avanza" te requieren las WCAG 1.0, por ley también...

La duda es razonable: ¿qué debo aplicar? ¿WCAG 1.0? ¿WCAG 2.0? ¿Norma UNE 139803?

Desde mi punto de vista, la respuesta es clara: si hay una ley que nos obligue a algo, lo que diga la ley, ya que eso es lo que nos van a exigir, aunque sea incorrecto (normalmente, es inútil discutir con un funcionario o político este tipo de cosas). Por tanto, en España, y hasta que no haya una nueva ley, lo que hay que aplicar es la Norma UNE 139803. Otro cosa es que no estemos "bajo el imperio de la ley": en ese caso, entre WCAG 1.0 y WCAG 2.0, mejor WCAG 2.0. Así, por lo menos nos olvidaremos de los puntos de control desfasados que comienzan con "Hasta que las aplicaciones de usuario permitan...".

Sin embargo, sí que tiene mucho sentido discutir si WCAG 1.0, WCAG 2.0 o la Norma UNE 139803 son el mejor camino o lo único que debemos de tener en cuenta para lograr la accesibilidad web.

Sobre este tema ya escribí hace un tiempo:

• ¿Las pautas de WCAG garantizan realmente la accesibilidad? (30/09/2009)
• ¿Las pautas de WCAG garantizan realmente la accesibilidad? (01/03/2010)

Cualquiera que desarrolle sitios web con el requisito de la accesibilidad, se habrá encontrado con situaciones en las que cumplir las pautas de accesibilidad existentes no sea la mejor elección. Y sin embargo, hay que hacerlo si se quiere lograr la conformidad y "demostrar" que el sitio web es accesible.

Sobre este tema hay dos buenos artículos que recomiendo:

• Beyond Conformance: The Role of Accessibility Evaluation Methods, de Giorgio Brajnik, publicado en el congreso WISE 2008.
• Evaluating Web Site Accessibility: Validating the WAI Guidelines through Usability Testing with Disabled Users, de Dagfinn Rømen y Dag Svanæs, publicado en NordiCHI 2008.

Mi consejo: las pautas y normas son un buen punto de inicio, pero no son lo único. Muchas veces, hay que aplicar el sentido común. Y en caso de duda, lo mejor es simular la posible situación conflictiva (por ejemplo, desactivar las imágenes de una página) o, mucho mejor, consultar a un usuario final que se pueda ver afectado.

El dominio de Apple y Google, peor que con Microsoft

No lo digo yo, lo dice la noticia W3C co-chair: Apple, Google power causing Open Web crisis, que salió ayer publicada en CNET. El resumen de la noticia dice:

The dominance of Apple and Google mobile browsers is leading to a situation that's even worse for Web programming than the former dominance of Internet Explorer, a standards group leader warned today.

Traducido al castellano:

El dominio de Apple y Google en el mercado de los navegadores para móviles está llevando a una situación que es aún peor para la programación web que con el antiguo dominio de Internet Explorer, un líder del grupo de estandarización advirtió hoy.

El problema que se explica en este artículo es que muchos programadores web se están centrando en los navegadores de Apple y Google, ambos basados en WebKit, y por contra, se están olvidando de los navegadores Firefox, Internet Explorer y Opera. Esto está ocurriendo porque los navegadores de Apple (Safari) y de Google (Chrome) son los mayoritarios entre los dispositivos móviles (teléfonos), que es el segmento de dispositivos con conexión a Internet que más está creciendo en los últimos años.

Muchos programadores web emplean propiedades de CSS específicas para estos dos navegadores. Estas propiedades, que comienzan con el prefijo -webkit, puede ser que ya estén estandarizadas o que estén camino de serlo y, por tanto, que sean compatibles con otros navegadores. Pero al anteponer el prefijo específico del vendedor, sólo funcionan en el navegador especificado.

Esto es un completo error, y se debe evitar utilizar las propiedades de CSS específicas de un vendedor. Pero si por alguna razón es imprescindible su uso, entonces lo más conveniente es emplear la propiedad sin el prefijo (para que el CSS sea compatible con las futuras versiones de los navegadores) y con el prefijo de los navegadores más populares, para que sea compatible con los navegadores actuales.

Por ejemplo, si se quiere emplear la nueva propiedad transform de CSS3, lo correcto es:

div
{
  transform: rotate(7deg);
  -ms-transform: rotate(7deg); /* IE 9 */
  -moz-transform: rotate(7deg); /* Firefox */
  -webkit-transform: rotate(7deg); /* Safari y Chrome */
  -o-transform: rotate(7deg); /* Opera */
}

Si no se hace así, algunos grupos de usuarios podrán sufrir problemas en el uso. Ni más ni menos que un problema de accesibilidad web, en esta ocasión producido por una discriminación tecnológica.

Curso "Accesibilidad Web WCAG 2.0"

La Fundación CTIC organiza una nueva edición de su curso Accesibilidad Web WCAG 2.0. El curso comienza el 1 de marzo de 2012 y finaliza el 4 de mayo de 2012.

Los contenidos del curso son:

• MÓDULO 0: Introducción
• Introducción a la accesibilidad web
• Introducción a las WCAG 2.0
• MÓDULO 1: Principio 1 - Perceptible
• Alternativas textuales
• Accesibilidad en contenido multimedia
• Adaptabilidad del contenido
• Contenido fácilmente perceptible
• MÓDULO 2: Principio 2 – Operable
• Contenido accesible mediante teclado
• Tiempo suficiente para realizar tareas
• Contenido libre de trastornos
• Facilidad de navegación
• MÓDULO 3: Principio 3 - Comprensible
• Legibilidad del contenido
• Contenido predecible
• Entrada de datos asistida
• MÓDULO 4: Principio 4 - Robusto
• Compatibilidad con navegadores y ayudas técnicas
• MÓDULO 5: Evaluación de la accesibilidad
• Proceso de evaluación de la accesibilidad
• Herramientas de evaluación automática (TAW)
• Herramientas de evaluación manual
• Monitorización

Accesibilidad de las redes sociales

El próximo jueves 16/2/2012, se va a celebrar una jornada técnica sobre Redes Sociales y Discapacidad: oportunidades y retos en la Fundación ONCE en Madrid. Para aquellas personas que no puedan asistir al acto, el desarrollo del mismo se emitirá por Internet a través del portal Discapnet y de la página de Discapnet en Facebook.

Desgraciadamente, este tipo de actos son necesarios porque la mayoría de las redes sociales actuales no son tan sociales como se podría pensar, ya que discriminan a algunos grupos de usuarios al no ser accesibles. Por ejemplo, hace tiempo publiqué un vídeo en el que mostraba que en Twitter, algo tan simple como el captcha sonoro que se emplea como alternativa al captcha visual, no es accesible para un usuario español porque está en inglés.

A mediados del año 2010, Daniel Torres Burriel escribió un artículo sobre la Web 2.0 y su falta de accesibilidad. El año pasado me hice eco de una encuesta sobre la accesibilidad de las redes sociales (he buscado los resultados, pero no los encuentros) y también comenté algunos consejos para mejorar la accesibilidad de las redes sociales.

Ahora acabo de leer el artículo Social networks and accessibility: A rather sad picture, de diciembre de 2011. En este artículo se comenta la accesibilidad de las principales redes sociales:

• Twitter: marcado incorrecto, problemas cuando se maneja exclusivamente con el teclado.
• Facebook: falta de estructura.
• Google Plus: problemas con lectores de pantalla y cuando se maneja exclusivamente con el teclado.
• Yammer: red social a nivel empresarial, problemas cuando se maneja exclusivamente con el teclado.
• identi.ca: basada en código abierto (open source), es la única realmente accesible en esta lista.

El apoyo de Bill Clinton al WAI

El WAI (Web Accessibility Initiative) del W3C se formó oficialmente en abril de 1997. Antes de que se metiese en líos, Bill Clinton, presidente de los Estados Unidos, mostró su apoyo al WAI:

Congratulations on the launch of the Web Accessibility Initiative - an effort to ensure that people with disabilities have access to the Internet's World Wide Web.

New information and communications technologies can improve the quality of life for people with disabilities, but only if such technologies are designed from the beginning so that everyone can use them. Given the explosive growth in the use of the World Wide Web for publishing, electronic commerce, lifelong learning and the delivery of government services, it is vital that the Web be accessible to everyone. The Web Accessibility Initiative will develop the tools, technology, and guidelines to make it possible to display information in ways that are available to all users.

I commend the World Wide Web Consortium, industry sponsors, and the Yuri Rubinski Foundation for launching this important project. I am pleased that the Department of Education will provide funding for the Web Accessibility Initiative, and that the National Science Foundation is considering expanding its support for research and development in this area. My administration is committed to working with these and other organizations to ensure that this innovative project is a success.

Que traducido al castellano es, más o menos:

Felicidades por el lanzamiento de la Iniciativa para la Accesibilidad Web - un esfuerzo para asegurar que las personas con discapacidad tengan acceso a la World Wide Web de Internet.

Las nuevas tecnologías de comunicación pueden mejorar la calidad de vida de las personas con discapacidad, pero sólo si esas tecnologías se han diseñado desde el principio para que todos puedan usarlas. Dado el crecimiento explosivo en el uso de la World Wide Web para la publicación, el comercio electrónico, el aprendizaje permanente y la prestación de servicios públicos, es vital que la Web sea accesible para todos. La Iniciativa para la Accesibilidad Web desarrollará las herramientas, la tecnología y las directrices que harán posible la visualización de la información de maneras que estén disponibles para todos los usuarios.

Felicito al World Wide Web Consortium, a los patrocinadores de la industria, y a la Fundación Yuri Rubinski por el lanzamiento de este importante proyecto. Me complace que el Departamento de Educación proporcionará fondos para la Iniciativa para la Accesibilidad Web, y que la National Science Foundation está considerando ampliar su apoyo a la investigación y el desarrollo en esta área. Mi administración está comprometida a trabajar con estas y otras organizaciones para asegurar que este innovador proyecto es un éxito.

Curioso, ¿no?

Más información: WAI History.

Lector de pantallas para Apple

Este fin de semana he recibido este correo electrónico:

Hola buenos dias, me pongo en contacto con usted a fin de preguntarle si existe un software disponible para Apple Mac, con lector de contenidos, es para un a persona que recientemente se ha quedado sin la posibilidad de ver por un accidente.
Mucho le agradeceria me informe al respecto.
Sin mas lo saludo muy atentamente,
X Y Z
Buenos Aires, Argentina

Mi contestación fue la que muchos esperaréis:

Hola.
Supongo que se refiere a un lector de pantallas. Mientras que en Windows es necesario adquirir este software por separado, en Apple Mac OS X existe en el sistema. Se llama VoiceOver y funciona muy bien. Hay que aprender a usarlo, pero una vez que se sabe, el resultado es excelente.
Te paso unos enlaces con información oficial:
http://www.apple.com/es/accessibility/voiceover/
http://www.apple.com/mx/accessibility/voiceover/downloads.html
http://www.apple.com/mx/accessibility/voiceover/reasons.html
Un saludo.

La pregunta de este correo electrónico me sorprendió, porque cuando nos dedicamos a un tema concreto, damos por supuesto que "todo el mundo" sabe lo que nosotros sabemos. Pero no es así. Por cierto, para el que necesite más información sobre lectores de pantalla, en mi página sobre lectores de pantalla tengo un listado con los más conocidos.

He aprovechado este correo para revisar las principales características de VoiceOver y me he sorprendido al encontrar algunas muy interesantes que desconocía completamente:

• Gestos: "Un cursor de VoiceOver marca el elemento descrito en cada momento, y cuando el usuario arrastra un dedo por el trackpad, VoiceOver atenúa la parte de la pantalla que no se corresponde con la zona del trackpad en cuestión. De este modo los usuarios no invidentes pueden seguir más fácilmente lo que ocurre en la pantalla".
• Teclados braille en espejo: "El braille en espejo permite a múltiples usuarios de braille colaborar en el mismo ordenador sin necesidad de compartir el teclado braille. Además, usuarios sordos e invidentes pueden colaborar en el mismo ordenador a la vez, y los estudiantes que usan braille pueden seguir lo que el profesor está explicando a sus compañeros de clase no invidentes".
• Lugares web: "Lamentablemente, muchas páginas web no cumplen las directrices de accesibilidad, no están bien estructuradas o no usan correctamente el HTML estándar, lo que dificulta su navegación con un lector de pantalla. Para superar esta barrera, Apple patentó nuevas tecnologías disponibles únicamente en VoiceOver que entienden e interpretan las complejas relaciones visuales de una página web. VoiceOver usa esta información para crear y asignar etiquetas visuales, llamadas lugares web, que marcan puntos importantes de la página en función de su diseño visual para identificar elementos de interés y facilitar la navegación de la página". 
• Punto exacto: "Si hay una parte concreta de una página que te gusta visitar, por ejemplo, para informarte sobre el tiempo o leer un artículo de tu columnista favorito, puedes crear un «punto exacto». El punto exacto siempre ocupa el primer puesto del menú de lugares web, y cuando se carga la página, VoiceOver va a él en primer lugar".

¡Simplemente genial! Las dos primeras opciones ayudan a la integración de las personas con discapacidad y evitan que el ordenador sea una barrera más. Las dos últimas opciones no deberían existir, todas las páginas web deberían ser accesibles, pero como se sabe que no es así (y, desgraciadamente, nunca lo será), son una gran solución.

¿Seguirá el lector de pantalla más popular para Windows, JAWS, el mismo camino?

Versión accesible del periódico El Mundo, para tirarla a la basura

Bueno, cuando me he encontrado con esto, que ha sido de casualidad, he pensado "¿qué diablos es esto?". Me he enfadado bastante.

Resulta que el periódico El Mundo tiene una versión accesible, versión que de accesible tiene bien poco.

En primer lugar, ¿qué es eso de tener una versión accesible separada? ¿Es eso realmente accesibilidad? Para colmo, en el pie de página aparece el logotipo de la ONCE, con el texto alternativo "logotipo de la ONCE con el texto encima de asesor técnico". Sólo les ha faltado poner en el texto alternativo que "ONCE está escrito con un tipo de letra sans-serif, en color verde y sobre un fondo amarillo". ¿Está versión accesible del periódico El Mundo tiene el visto bueno de la ONCE? Sí es así, entonces mejor "apaga y vámonos..."

En la edición actual, la página principal de la versión normal tiene enlaces a más de 30 noticias, enlaces a numerosos reportajes y enlaces a numerosos servicios adicionales. La versión accesible tiene enlaces a sólo 8 noticias y unos enlaces a algunas secciones, no todas, del periódico.

En la cabecera de la página, el texto alternativo del logotipo es "elmundoesmovil". Por el aspecto de la página y por este texto alternativo, me inclino a pensar que esta página es un refrito de una antigua versión para dispositivos móviles, que ya no tiene sentido ahora que la mayoría de los dispositivos móviles pueden utilizar la versión normal sin problemas, y que se ha reconvertido en una supuesta "versión accesible".

En la esquina superior derecha hay un minúsculo icono con el texto alternativo "Lector de noticias", que lleva a una página web donde está disponible un fichero de audio MP3 con los titulares que se muestran en la página. No entiendo bien el sentido de este enlace, porque un usuario que utilice su propio lector de pantallas no lo necesita para nada. Y para el resto de usuarios, es muy difícil de distinguir (yo lo he visto al explorar el código fuente de la página).

Los encabezados (h1, h2, ...) están usados de pena como se puede ver en la siguiente imagen en la que se muestra la estructura que proporciona HeadingsMap: no se identifica con un h1 el título principal de la página, y se utilizan los encabezados h1 y h4, sin utilizar h2 o h3.

Cada noticia tiene un enlace para acceder al texto completo de la noticia. En todas las noticias, el texto de ese enlace es "»", por lo que se repiten varios enlaces con el mismo texto pero distinto destino, como se puede ver en la siguiente captura en la que se ve la lista de enlaces de la página según Fangs.

El texto alternativo de las fotografías que acompañan algunas noticias es siempre "[Fotonoticia]". Para eso, es mucho mejor que se hubiese dejado un texto alternativo nulo (alt=""). ¿Y qué significan los corchetes?

Todos los titulares de noticia son enlaces que contienen un atajo de teclado (accesskey) con el mismo valor (el número 1). ¿Para qué?

En definitiva, que se puede hacer mal, pero no peor que esto.

Si alguien de la ONCE lee esta entrada, me gustaría que nos explicase en qué consiste su asesoramiento técnico.

La nueva web de Madrid 2020

Hace unos días se presentó el nuevo logotipo y la nueva web de la candidatura de Madrid para organizar los juegos olímpicos de 2020 (y ya van unos cuantos intentos). Como de costumbre, en la presentación sobresalieron algunas "chapuzas", como la confusión que crea el logotipo que parece que pone "20020", que hayan puesto "madríd" con tilde o que se les haya olvidado el color negro (¿Madrid 2020 o 20020?). Y ya puestos, el logo se parece mucho al de una empresa que vende juguetes (Una empresa que fabrica muñecos gays dice que Madrid 2020 les copió). Bueno, hoy en día no creo que alguien sea tan tonto como para copiar tan descaradamente, porque más tarde o temprano se descubrirá. Pero lo que sí que es de tonto integral es no realizar una búsqueda previa de imágenes y diseños para comprobar que no pasen estas cosas. Y también es de tonto el declarar que no se va a cambiar nada de nada (El polémico logo olímpico no se cambia).

Respecto a la web de Madrid 2020 (¿o tengo que escribir madríd 2020?), en diversas noticias se afirma que es "accesible, multimedia y participativa".

¿Accesible? ¿Alguien ha intentado utilizar este sitio web con el teclado? Yo no consigo saber dónde estoy. Para un usuario que acceda con el teclado, la página principal es totalmente inaccesible.

[Actualización 10/02/2012]
Los problemas con el logo de Madrid 2020 continúan: Madrid 2020, obligada a indemnizar a un artista por robarle su 'tipografía'.

Y siguen los correos no accesibles

Bueno, ayer escribí la entrada Accesibilidad de los correos electrónicos en la que comentaba la costumbre que tienen en la Universidad de Alicante de mandar correos no accesibles y hoy lo han vuelto a hacer, ¡¡y peor!!

Este es el mensaje con los problemas, tal como se ve en Mozilla Thunderbird:

¿Dónde está el problema? El mensaje no contiene texto, lo que parece texto, ¡¡es una imagen!! Y por supuesto, los enlaces que aparecen en el texto no se pueden emplear. Si alguien quiere consultar las páginas que se indican en el mensaje, tendrá que teclear la dirección. Ya no sólo es totalmente inaccesible, sino que además es inútil.

Y aquí tenemos la imagen que llevaba el mensaje:

Y si hay alguna duda más, aquí está parte del código fuente original del mensaje, donde se puede ver que lo que contiene es una imagen (he destacada la etiqueta img de HTML que hace referencia a la imagen):

La Sociedad de la Información en España 2011

Hace unos pocos días se publicó el informe anual La Sociedad de la Información en España 2011, editada por Ariel y la Fundación Telefónica.

El sitio web en el que está disponible este informe es un auténtico bodrio. En primer lugar aparece la siguiente página:

Al pulsar en el botón "On-Line" se abre una nueva ventana del navegador con la siguiente página:

Y al pulsar en el botón "OK" se abre una tercera ventana flotante que tiene el siguiente aspecto y contenido:

Esta ventana, si se intenta hacer más grande, no se puede (la ventana sí, pero el contenido no). Sorprendente, ¿no? ¿Cómo puede ser que una compañía como Telefónica (bueno, su Fundación) haga estas tonterías? Afortunadamente, el informe se puede descargar en formato PDF.

En realidad, en esta entrada quería contar que en el informe no se hace ninguna referencia a la accesibillidad o a las personas con discapacidad.

[Actualización 7/8/2012]
Si te interesan este tipo de informes y estudios, también te interesará Informe eEspaña 2012.

Accesibilidad de los correos electrónicos

Esta mañana he recibido un correo electrónico institucional de la Universidad de Alicante, el lugar donde trabajo. El cuerpo del correo sólo contenía lo siguiente:

APERTURA DE L'EXPOSICIÓ MUA. LA COL·LECCIÓ
http://www.mua.ua.es/postales/lacoleccion.jpg
__________________________________________
APERTURA DE LA EXPOSICIÓN MUA. LA COL·LECCIÓ
http://www.mua.ua.es/postales/lacoleccion.jpg

El subrayado bajo "_" está así en el mensaje original. El enlace, como se puede ver, lleva a una imagen JPG en la que está toda la información sobre la exposición (el lugar, la fecha de la apertura, el horario de visita, la fecha de finalización de la exposición y alguna cosa más). Pero claro, transmitir la información mediante una imagen presenta problemas de accesibilidad. He publicado un pequeño análisis sobre los problemas de accesibilidad que presenta este correo electrónico.

¿Es muy inteligente enviar un correo electrónico así? Esto lo he visto en muchos sitios, no sólo en la Universidad de Alicante. Las empresas es muy normal que en sus boletines (newsletters) incluyan directamente una imagen en vez de texto.

He revisado la legislación en materia de accesibilidad de las comunicaciones y no he encontrado ninguna mención expresa al correo electrónico. Lo más cercano que he encontrado es la Ley 56/2007, en su disposicional adicional undécima Acceso de las personas con discapacidad a las tecnologías de la Sociedad de la Información, que dice: Las Administraciones Públicas, en el ámbito de sus respectivas competencias, promoverán el impulso, el desarrollo y la aplicación de los estándares de accesibilidad para personas con discapacidad y diseño para todos, en todos los elementos y procesos basados en las nuevas tecnologías de la Sociedad de la Información.

El correo electrónico forma parte de la Sociedad de la Información y, por tanto, se entiende que también debería ser accesible. Pero una cosa es "promover" y otra "estar obligado a ello". ¿Alguien conoce alguna ley o decreto que indique que los correos electrónicos de las Administraciones Públicas deban ser accesibles?


[Actualización 31/01/2012]
Valentín ha dejado un comentario en el que comenta la LEY 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.

En el artículo 3 se establece los ámbitos de aplicación de esta ley, entre los que destacan las telecomunicaciones y la sociedad de la información y, expresamente, las relaciones con las Administraciones públicas.

El artículo 10 impone al Gobierno la obligación de regular unas condiciones básicas de accesibilidad y no discriminación que garanticen unos mismos niveles de igualdad de oportunidades a todos los ciudadanos con discapacidad.

La cadena "user agent" o "agente de usuario"

Según la definición de agente de usuario en la Wikipedia:

Un agente de usuario es una aplicación informática que funciona como cliente en un protocolo de red; el nombre se aplica generalmente para referirse a aquellas aplicaciones que acceden a la World Wide Web. Los agentes de usuario que se conectan a la Web pueden ser desde navegadores web hasta los web crawler de los buscadores, pasando por teléfonos móviles, lectores de pantalla y navegadores en Braille usados por personas con discapacidades. 

Cuando un usuario accede a una página web, la aplicación generalmente envía una cadena de texto que identifica al agente de usuario ante el servidor. Este texto forma parte del pedido a través de HTTP, llevando como prefijo User-agent: o User-Agent: y generalmente incluye información como el nombre de la aplicación, la versión, el sistema operativo, y el idioma. Los bots, como los web crawlers, a veces incluyen también una URL o una dirección de correo electrónico para que el administrador del sitio web pueda contactarse con el operador del mismo.

Acabo de leer el artículo History of the browser user-agent string, en el que nos explican con un poco de gracia el origen del uso del user-agent y cómo se ha llegado a los user-agent que se emplean hoy en día que prácticamente no aportan ninguna información útil, porque todos los navegadores pretenden ser lo que no son.

La cadena user-agent se empleó al principio de la Web para distinguir los navegadores entre sí y ofrecer un contenido diferente a cada uno. Por ejemplo, "hace mucho tiempo, en una galaxia muy, muy lejana", había navegadores web con y sin soporte de marcos (frames). Algunos desarrolladores web creaban dos versiones de sus sitios web, una versión con marcos y otra sin marcos, que se enviaba al navegador en función de su cadena user-agent. Ahí empezó la mala costumbre de hacer un sitio web "optimizado para el navegador XYZ" y mucha gente olvidó que uno de los principios fundamentales de la Web es que debe ser una, lo que se conoce por One Web:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.

La página UserAgentString.com muestra y explica la cadena user-agent del navegador. Por ejemplo, cuando me conecto con Google Chrome 16, aparece:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7

Resulta que Google Chrome está basado en Apple WebKit, por lo que dice que también es Safari/535.7, el navegador de Apple que también usa WebKit. Pero WebKit está basado a su vez en KHTML, que pretende ser compatible con Gecko, que es el motor de Mozilla... ¡Un lío!

Además, para liarlo un poco más, en la mayoría de los navegadores se puede cambiar la cadena user-agent fácilmente, tal como explican en Changing Browser User Agent Strings. Por tanto, tampoco te puedes fiar del valor que envía un navegador. Y además, constantemente aparecen nuevos navegadores y nuevas versiones de los navegadores.

Mi consejo: nunca realizar un desarrollo web en el que se detecte la cadena user-agent y se genere un contenido en función de su valor, es una pérdida de tiempo.

Simplext, sistema automático de simplificación de textos

Hace unos años escribí la entrada Simplificar los textos. Esa entrada la escribí cuando descubrí que las personas sordas de nacimiento tienen problemas para comprender los textos escritos complejos, ya que sus esquemas mentales y su forma de entender el idioma es distinta. Por eso hay algunos sitios web que ofrecen explicaciones mediante vídeos con la lengua de signos. Pero no solamente las personas sordas se benefician de la simplificación de los textos: las personas con problemas cognitivos o de aprendizaje y las personas extranjeras que no tengan un gran conocimiento del idioma que se emplea también se benefician.

La Pauta 14 Asegúrese de que los documentos sean claros y simples de WCAG 1.0 nos indica que hay que emplear un lenguaje claro y sencillo porque algunos usuarios con discapacidades cognitivas o de aprendizaje pueden tener problemas para entender textos largos y complejos.

La Pauta 3.1 Legible: Hacer que los contenidos textuales resulten legibles y comprensibles de WCAG 2.0 nos indica que hay que evitar las palabras inusuales, hay que proporcionar mecanismos para identificar y expandier las abreviaturas y hay que escribir textos con un nivel de lectura adecuado.

Acabo de encontrar Simplext, un proyecto español que tiene como objetivo desarrollar un sistema automático de simplificación de textos. Según pone en la página web del proyecto:

Simplext favorece la inclusión tecnológica de personas con capacidades cognitivas limitadas a través de la simplificación automática de contenidos utilizando el paradigma de la fácil lectura.

En el proyecto Simplext aúna los esfuerzos de dos campos de investigación bien definidos, como son el procesamiento computacional del lenguaje natural y la investigación lingüística en la simplificación, así como las tendencias tecnológicas en accesibilidad para la obtención de un producto de apoyo ubicuo e interoperable.

El proyecto está liderado por Technosite, empresa tecnológica de Grupo Fundosa y dependiente de Fundación ONCE. Technosite es muy conocida en el mundo de la accesibilidad web, entre otras cosas, porque auditan y certifican la accesibilidad web.

Análisis de la accesibilidad de la página web del Ayuntamiento de Crevillent

He publicado el análisis de la accesibilidad de la página web del Ayuntamiento de Crevillent.

El informe se puede descargar en formato PDF.

Los principales problemas detectados son: 

• Diseño fijo en vez de líquido.
• El código HTML y CSS no valida correctamente.
• Todas las páginas tienen el mismo título (<title>).
• No se emplean los encabezados todo lo bien que se debería.
• No hay enlaces "saltar a" para ir directamente al contenido principal de la página.
• En numerosos enlaces, el atributo title se emplea para repetir el texto del enlace.
• En numerosas imágenes, el texto alternativo no es el adecuado.
• Algunos enlaces son difíciles de reconocer.
• Al navegar sin imágenes desaparece parte del contenido.
• La navegación por medio del teclado es mejorable.

Congresos y conferencias sobre accesibilidad web 2012

En el sitio web WebAxe han recopilado una lista de las conferencias sobre accesibilidad web que se van a celebrar durante el año 2012. Por ahora, en la lista aparecen los siguientes congresos y conferencias:

ATIA 2012 Orlando
January 25-28, 2012
Orlando, FL U.S.A.


Techshare India 2012 "Bridging the Barriers"
6-7 February 2012
New Delhi, India


International Technology & Persons with Disabilities Conference
Feb 27-March 3, 2012
Manchester Grand Hyatt Hotel
San Diego, CA U.S.A.


Power Up 2010 Conference and Expo
April 2 and 3, 2012
Columbia, Missouri U.S.A.
Holiday Inn Executive Center
presented by Missouri Assistive Technology


W4A 2012
9th International Cross-Disciplinary Conference on Web Accessibility
16-17 April 2012
Lyon, France


John Slatin Access U (from Knowbility)
May 15-17, 2012
Austin, Texas U.S.A.


Penn State Web 2012 Conference
June 11-12, 2012
Pennsylvania U.S.A.


The Accessibility Conference
University of Guelph (Ontario, Canada)
TBD


ICCHP
13th International Conference on Computers Helping People with Special Needs
July 11-13, 2012; Pre-Conference July 09-10, 2012
University of Linz, Altenbergerstraße 69, 4040 Linz, Austria


AHEAD: Association on Higher Education And Disability
July 9-14, 2012
New Orleans, Louisiana U.S.A.
The Sheraton Hotel


Illinois Web Accessibility Conference and Expo
TBD


HighEdWeb Association (Higher Education Web Professionals)
October 7-10, 2012
Milwaukee, Wisconsin U.S.A.


ASSETS 2012
The 13th International ACM SIGACCESS Conference on Computers and Accessibility
October 22-24, 2012
Boulder, Colorado, U.S.A.


Accessing Higher Ground
Accessible Media, Web and Technology Conference
TBD
Colorado, U.S.A.


OZeWAI Conference
Australian Web Adaptability Initiative
Melbourne, Australia
Late November

También se puede consultar la lista de los congresos del año 2011 y 2010.

[Actualización 25/01/2012]
III Congreso Iberoamericano sobre Calidad y Accesibilidad de la Formación Virtual (CAFVIR 2012)
25-27 de Abril de 2012
Alcalá de Henares, España

Programa Social Inclusite

Hace unos meses escribí sobre Inclusite, un sistema desarrollado por una empresa española radicada en Valencia que permite dotar a un sitio web de interfaces accesibles que se adaptan a las necesidades de diferentes usuarios. La principal ventaja de este sistema es que se puede emplear desde cualquier ordenador sin tener que instalar ningún tipo de software adicional.

Ahora me ha llegado la noticia de que han puesto en marcha el Programa Social Inclusite. En este programa participan dos tipos de organizaciones: las organizaciones donantes o colaboradoras y las organizaciones beneficiarias.

Las organizaciones donantes, que son las que contratan alguno de los servicios de Inclusite, podrán seleccionar, si así lo desean,  la entidad a la que quieren destinar la donación, que disfrutarán del servicio de Inclusite de forma totalmente gratuita.

Para ser una organización beneficiaria, se debe ser una organización sin ánimo de lucro, de tamaño moderado y tener una web que cumpla determinados requisitos.

Una idea interesante, esperemos que funcione y muchos sitios web se beneficien de ella.

A quién denunciar la falta de accesibilidad

Volvamos a mis entradas Lista de denuncias contra sitios web no accesibles en Estados Unidos y ¿Denunciar la falta de accesibilidad? Inútil en España que escribí hace unos días. Resumamos esas entradas:

• En Estados Unidos (y otros países, como Australia) ha habido denuncias por falta de accesibilidad de algunos sitios web desde hace más de 10 años, en algunos casos con sanciones muy cuantiosas.
• En España tenemos legislación que establece que algunos sitios web deben cumplir un mínimo de accesibilidad desde hace años.
• En España tenemos legislación que establece unos requisitos mínimos de accesibilidad al medio físico desde hace muchos más años.
• Sin embargo, no se tiene constancia de ninguna sanción, ni por incumplimiento de la accesibilidad web ni por incumplimiento de la accesibilidad al medio físico (esto último es cierto, al menos, en la Comunidad de Madrid, donde no se ha impuesto nunca una sanción).
• En un comentario, Félix Zapata nos contaba sus problemas para obtener información sobre las denuncias y sanciones al ponerse en contacto con algunos ministerios.

Acabo de descubrir que en la web del Ministerio de Sanidad, Servicios Sociales e Igualdad existe una página sobre la protección de los derechos de las personas con discapacidad. En esta página podemos leer:

La protección de los derechos de las personas con discapacidad, establecidos en las leyes, hacen necesario el desarrollo de sistemas de control y sancionadores que velen por la aplicación de los principios establecidos en aquéllas.
En este sentido; 

se creó la Oficina Permanente Especializada (OPE), órgano especializado en realizar funciones de asesoramiento, análisis y estudio de las denuncias y consultas realizadas por personas con discapacidad que manifiesten haber sido objeto de discriminación. 

se ha implantado un Sistema Arbitral encargado de la resolución extrajudicial de las quejas y reclamaciones en materia de igualdad de oportunidades, no discriminación y accesibilidad por razón de discapacidad, siempre que no sean constitutivas de derechos. 

se ha creado la unidad de Infracciones y Sanciones, que sanciona administrativamente las vulneraciones de los derechos de las personas con discapacidad cuando se produzcan discriminaciones directas o indirectas, acosos, incumplimiento de las exigencias de accesibilidad y de realizar ajustes razonables, así como el incumplimiento de las medidas de acción positiva legalmente establecidas.

Esto está muy bien, pero a mí que confunde bastante que existan estos tres órganos o departamentos para "algo" que debería hacer uno solo. Mi confusión la reafirmo en el hecho de que para realizar una consulta o queja, se ofrecen sendos modelos en la web de la Oficina Permanente Especializada, mientras que para formular una denuncia, encontramos el modelo en la web de Infracciones y Sanciones. ¿Por qué no lo ponemos todo junto en un único sitio y luego lo enlazamos desde donde haga falta?

En la web de la Oficina Permanente Especializada podemos encontrar los informes anuales de este organismo (por ahora, están disponibles del año 2005 al 2010). Un pequeño resumen:

• Año 2005: 50 consultas, peticiones de asesoramiento y quejas, ninguna relacionada con la accesibilidad web.
• Año 2006: el informe anual sólo contiene los informes particulares, pero no hay un resumen anual.
• Año 2008: el resumen anual está incompleto, como si fuera una plantilla pero sin los datos concretos.
• Año 2009: 579 consultas y 136 quejas. En este informe podemos encontrar el expediente número Q/322/09, en el que se denuncia que "La página de Internet oficial de la Universidad Autónoma de Madrid, www.uam.es, no observa los niveles generales de accesibilidad establecidos por la legislación vigente para las páginas de Internet de entidades de carácter público, por lo que contraviene lo dispuesto en el Real Decreto 1494/2007". Desgraciadamente, no aparece información sobre quién hizo la denuncia o sobre cuál fue el resultado de la misma.
• Año 2010: 115 consultas, 123 quejas y 23 denuncias. En este informe destaca en la página 40 la siguiente tabla en la que se resumen los plazos de cumplimiento de las leyes de accesibilidad en cuanto a la sociedad de la información.

En el informe del año 2010 aparecen las siguientes denuncias en materia de accesibilidad web:

• Expediente 15/10: Denuncia la Web de Transportes Metropolitanos de Barcelona por ausencia de accesibilidad.
• Expediente 16/10: Denuncia la Web del Corte Inglés por ausencia de accesibilidad.
• Expediente 17/10: Denuncia la página Web de AGBAR por ausencia de accesibilidad.
• Expediente 158/10: Queja por ausencia de accesibilidad página Web Openbank.
• Expediente 213/10: Denuncia página Web de Iberia por no observar nivel medio de accesibilidad.
• Expediente 214/10: Denuncia página Web de Corporación RTVE por no observar nivel medio de accesibilidad.
• Expediente 215/10: Denuncia página Web de Corporación Endesa por no cumplir nivel medio de accesibilidad.
• Expediente 216/10: Denuncia página Web del Grupo Gas Natural por no observar nivel medio de accesibilidad.
• Expediente 217/10: Denuncia página Web de Jazztel por no observar nivel medio de accesibilidad.
• Expediente 218/10: Denuncia página Web de ORANGE por no ser accesible.
• Expediente 219/10: Denuncia página Web de Corporación RTVE por no observar nivel medio de accesibilidad.
• Expediente 220/10: Denuncia página Web de Grupo Santander por no observar nivel medio de accesibilidad.
• Expediente 221/10: Denuncia página Web de Grupo Avanza por no obtener nivel medio de accesibilidad.

Desgraciadamente, no aparece información sobre cómo se resolvió cada queja o denuncia.

[Actualización 11/04/2012]
En mi entrada Guía para la autodefensa de las personas con discapacidad se hace referencia a una guía que proporciona el CERMI para redactar y presentar denuncias por falta de accesibilidad.