cosetes

Poco a poco HTML 5 va tomando fuerza y cada vez aparece más información acerca de la nueva versión del estándar de creación de páginas web.

Hoy leo en aNieto2K que la nueva versión de HTML incorpora un conjunto de tipos de enlaces predefinidos para determinar que clase de enlace es el que estamos poniendo. Al definir el tipo de enlace se da más información al usuario (a través de su navegador) y a los buscadores. De esta manera al usuario le resultará más fácil saber que debe hacer con ese enlace.

No es una gran utilidad para la mayoría de los creadores de páginas web pequeñas (que son una parte importante) pero si será útil para los creadores de páginas web grandes y, seguramente, para los bloguers. De todas formas, las “funcionalidades” de este tipo, que añaden complejidad (y en este caso más de lo que parece) no suelen ser bien recibidas por los usuarios que deben utilizarlas y demasiadas veces suelen caer en el olvido. ¿Será el caso?

Sea lo que sea, vale la pena leer el post de aNieto2K y empezar a familiarizarse con las novedades del HTML 5.

@inproceedings{1243455,
author = {Sandeep R Patil},
title = {Accessible image file formats:the need and the way (position paper)},
booktitle = {W4A '07: Proceedings of the 2007 international cross-disciplinary
             workshop on Web accessibility (W4A)},
year = {2007},
isbn = {1-59593-590-X},
pages = {40--43},
location = {Banff, Canada},
doi = {http://doi.acm.org/10.1145/1243441.1243455},
publisher = {ACM Press},
address = {New York, NY,USA},
}

ABSTRACT

Accessibility is one of the key checkpoints in all software’s products, applications & websites. Accessibility with digital images has always been a major challenge for the industry. Images form an integral part of certain type of documents & most of the Web 2.0 compliant websites. Audience challenged with blindness and many dyslexics only makes use of screen readers/ text readers/narrator software programs to access the computer and computer displayed information. Such audience cannot view digital images/pictures. Hence drafting accessible documents or designing accessibility enhanced websites containing digital images representing figures, diagrams, map, snaps etc is a challenges. There are various published best practices for accessibility of documents or website containing images so that they can be better understood by the visually impaired users. But these are truly not enough to cover all kind of practical scenarios and this paper positions a need for a more innovative solutions. The paper also proposes accessibility enhanced image formation technique with relevant modification required in screen readers/narrator software programs and positions its edge over the existing methods.

Este artículo propone un sistema de marcado de imágenes para accesibilidad a partir de la descripción de las diferentes partes que la componen. La idea es añadir metadatos que describan la imagen por partes. El ejemplo que usa, evidentemente bien escogido para que funcione, es un diagrama de flujo en el que se describen cada una de sus partes por separado. No está mal pero parece poco relevante pudiendo usar longdesc para facilitar una descripción completa de la imagen.

Seguimos con mis planteamientos problemáticos. Ahora mismo, el problema es conseguir una lista, amplia, pero real, de requerimientos que podría tener un objeto de aprendizaje que le impidiese mostrarse en todo su esplendor en un determinado dispositivo de usuario.

Empiezo por hacer un listado de posibles limitaciones de dispositivos de usuario. Creo que es una buena opción para empezar:

• Sin javascript
• Sin plugin de Flash
• Sin plugin de Silveligth
• Sin Java
• Sin XML
• Sin ActiveX
• Pantalla de 176 por 208
• Pantalla de 208 por 208
• Pantalla de 240 por 320
• Pantalla de 320 por 240
• Pantalla de 352 por 416
• Pantalla de 640 por 480
• Pantalla de 800 por 480
• Pantalla de 800 por 600
• Blanco y negro
• 16 colores
• 256 colores
• 65536 colores
• Sin ratón
• Teclado limitado (pda o móvil sin teclado qwerty)
• Sin sonido

¿Son pocas? Así, a primera vista sí, sin embargo parece que esas opciones deberían ser suficientes para determinar las necesidades del OA en cuanto a las características del cliente.

Hay un detalle que no me atrevo a poner pero que tal vez sea realmente relevante. El navegador y/o el sistema operativo. Preferiría que esas opciones fueran substituidas por el motivo por el cual un determinado navegador o un determinado sistema operativo no pueden ser usados. ¿Están incluidos todos los motivos que pueden eliminar a un SO o un navegador de la visualización de un OA?

Los que venís siguiendo este blog con más o menos regularidad (tres: Isma, César y Enric ) sabéis que me preocupa, de lo que estoy haciendo, esa obligatoriedad que se transmite en los foros que hablan de accesibilidad, a que todas las páginas sean accesibles y a no admitir páginas separadas más o menos accesibles.

Hoy, sin embargo, en mi lista de referencia, se trataba el tema de contenidos educativos y accesibilidad. Allí se defendía la posibilidad sobre la que se ha basado lo que he ido haciendo hasta ahora: Es perfectamente admisible que exista contenido no accesible en un material educativo, siendo recomendable que exista un contenido accesible alternativo.

Sí, es de lógica, pero al no encontrar nada escrito, así, claramente, me daba una cierta “cosa” el ser yo el que lo escribiese. Ahora ya hay personas reconocidas que lo afirman, ya estoy más tranquilo

Sigamos pues en lo que estábamos.

Llevo unos días dándole vueltas a la posibilidad de incluir metadatos de accesibilidad a los objetos de aprendizaje. Como tengo algunas lagunas, lo mejor que se me ocurrió fue buscar información de como esos OA incluyen los metadatos. Y, a partir de aquí, he empezado a buscar y leer información sobre SCORM, LOM e IMS.

Para poder entender bien los metadatos que se añaden habitualmente, ver de que manera quedan almacenados en el OA y que posibilidades tengo de ampliarlos, me propuse crear u OA sencillo y probarlo, primero solo y después dentro de un entorno de aprendizaje como Moodle.

La primera tarea fue buscar alguna herramienta que me permitiese generar OA de una manera fácil. Buscando por la red encontré algunos: RELOAD (con su player), Advanced SCORM Editor (de pago, 59 $) y Autore, una herramienta online de la Universidad del Pais Vasco / Euskal Herriko Unibertsitatea que aunque parece muy interesante, tiene algunas limitaciones.

Al final me decidí por RELOAD que, hecho en Java, es fácil de usar. Sin embargo, el código generado es horroroso y por supuesto no accesible. De momento he hecho pocas cosas y quiero hacer un objeto “en condiciones” para poder criticarlo con más criterio. De momento, sin embargo, dado que los metadatos se guardan en un fichero XML, no debería haber ningún problema para extenderlo añadiendo los datos necesarios de accesibilidad.

Seguiremos informando…

El objetivo de esta entrada es intentar explicar el problema que pretendo resolver y que solución propongo.

El problema

En un entorno de aprendizaje tenemos OA que incluyen recursos no accesibles. Para considerar esos OA accesibles deberíamos incluir la información necesaria para suplir las carencias que podrían encontrar algunos usuarios. Sin embargo, puede considerarse innecesario o poco útil realizar el esfuerzo de hacer accesible para ciegos un OA de una asignatura de gráficos, en que se habla del color. O tener dos versiones de una animación Flash, una para usuarios con PC y otra para usuarios con un dispositivo móvil.

Puede parecer una trivialidad hablar en estos términos, cuando existen soluciones para estos problemas de accesibilidad. Sin embargo, el coste de esas soluciones, cuando hablamos de realizar 1000 animaciones Flash en un año, puede ser muy elevado, más si tenemos en cuenta que es muy probable que ningún estudiante llegue a usar nunca muchas de ellas.

Ahora bien, si un estudiante está estudiando un determinado módulo de una asignatura, empaquetado en un OA, puede resultarle útil saber a priori si ese OA lo podrá usar en su dispositivo móvil o no. O si el ordenador que tiene en su lugar de vacaciones, será capaz de mostrarle las animaciones que incluye. Y debe ser el entorno de aprendizaje quien le proporcione esta información. Incluso el entorno de aprendizaje, conociendo adecuadamente las características (tanto técnicas como físicas) de un determinado usuario, podría, conociendo las características de los OA de una determinada asignatura optativa, recomendársela o no.

Propuesta de solución

Una vez descrito el problema, parece obvio que la solución pasa por etiquetar correctamente los OA, de manera que el entorno de aprendizaje, y el mismo usuario, puedan conocer sus características y, por tanto si pueden usarlo o no. Incluso, sin demasiada dificultad, dados dos objetos de aprendizaje que tratan el mismo tema, uno multimedia y el otro textual (tipo PDF), el entorno de aprendizaje podría ofrecer al usuario aquel OA que se ajustase más a sus características, de manera transparente, o indicándole la existencia del otro OA para que, de forma opcional, pudiese escogerlo si lo desease.

Dónde y cómo

Esa es la cuestión. Conocemos el problema y una posible propuesta de solución. Ahora resta poner en práctica la solución. ¿Qué pasos habría que dar? Primero, identificar los posibles casos de inaccesibilidad que se pueden dar en los materiales web de la UOC. Después habría que definir que metadatos podrían usarse para definir esas posibilidades y, sobre todo, de que manera se deberían poner en el OA, aunque parece bastante evidente que deberían ponerse en la definición del OA y no en las páginas web que lo componen, por lo que los microformatos y cosas similares no creo que sirviesen.

Es este un tema difícil, al menos para mi. Intento explicar cual es la base de la cual partimos, donde estoy y a donde quiero llegar.

Partida

La situación de partida es sencilla de entender. Tenemos materiales de aprendizaje con más o menos florituras, materiales web y materiales pdf. No tenemos (o tenemos pocos), aunque el objetivo es tender hacia ello, objetos de aprendizaje. Los materiales web actuales no cumplen las normas WAI (en algunas páginas ni en el nivel 1) y no se pueden usar en PDAs con sistema operativo Windows Mobile v.5 (me falta probarlas en symbian).

Resumiendo, tenemos unos materiales no accesibles y un interés en que lo sean y en que se conviertan en objetos de aprendizaje.

A pesar de que podamos poner todo nuestro empeño en hacer materiales accesibles, siempre tendremos el problema de los elementos multimedia en los materiales. Estos elementos no acostumbran a ser imprescindibles para el aprendizaje aunque sí muy útiles. Además, hay asignaturas donde no parece razonable la presencia de una persona con discapacidad. Aun así, siempre queda el tema del acceso con dispositivos móviles. Un tema harto complicado debido a la continua evolución de los aparatos electrónicos. Aun así, hay que tenerlos en cuenta y, además, en versiones ligeramente anticuadas para garantizar el acceso al máximo posible de estudiantes.

Ahora

Ha buscado información sobre tageado para accesibilidad y me está resultando muy difícil encontrar nada. Hay alguna cosa, pero parece que hablar de páginas alternativas accesibles sea un tema tabú y algunas personas lo critican con pasión.

La única cosa que me he encontrado que parece ir por una dirección similar a la que hemos tomado es del DCMI Accessibility Community y dice:

The focus of the work of the Community is to ensure that DC metadata users can describe resources and services in a way that will increase the accessibility of information for everyone. This supports the ‘AccessForAll’ approach to accessibility that differs from previous reliance solely on good resource design and construction. The AccessForAll approach:

• makes it easier, or possible, to find accessible resources;
• makes it more likely that a resource of use to an individual user will be found, even when it is not generally ‘accessible’, and
• enables accessibility services to deconstruct resources containing inaccessible material and to replace, augment or transform that material before replacing it in the composite resource and delivering it to the user.

Esto se acerca a lo que hemos estado trabajando y pensando, aunque no desde el mismo lugar.

Sin embargo este grupo de trabajo tiene una propuesta de metadatos que nos puede ser útil para ampliarla o mejorarla, según nuestras necesidades.:

En principio parece hablar de marcado semántico para facilitar contenidos accesibles a contenidos no accesibles, pero podría ser similiar a lo que pretendemos hacer nosotors al marcar aquel material no accesibile, ofreciendo a cambio una alternativa accesible.

Pero no he explicado la situación actual, pero es que no tiene mucho que explicar. El exceso de trabajo de este último mes me ha dejado fuera de juego para mirarme nada más que lo que acabo de explicar :(.

Además el poder probar unas cuantas páginas web en un dispostivo móvil me ha hecho ver cuan lejos está Internet de ser accesible para este tipo de dispositivos, lo cual, posiblemente, me ha dispersado más de la cuenta.

¿A dónde vamos a parar?

El objetivo es marcar los objetos de aprendizaje con metadatos sobre su accesibilidad, de tal manera que el gestor de contenidos sobre el que se trabaje pueda decidir si aquel OA es adecuado para ese estudiante o no. Evidentemente, el paso siguiente es poder ofrecer al estudiante un objeto de aprendizaje con el mismo o similar contenido que si sea usable por él.

Hace unos días me enteraba, gracias a Logicola de la existencia de las “machine tags“. No es una cosa nueva, de hecho he encontrado artículos de enero del 2006 aunque definiéndolos como TripleTags

¿Qué son los machine tags y para que sirven?

El primer punto importante es que son tags. Además, sus nombres nos dan ideas de su utilidad y la manera como están creados. Así, “machine tags” nos da idea de que su función es que sean usados por las máquinas, no por las personas. Y “triple tags” nos indica que están formados por un conjunto de tres elementos (”namespace”, predicado y valor).

Su utilidad no la tengo muy clara. Es evidente que es un nuevo intento de añadir semántica a la web, pero desde el punto de vista de las máquinas, como el RDF. Sin embargo igual que en el caso de los microformatos, el hecho de que no haya un estándar detrás, parece complicar su uso.

Si se está hablando ahora de “machine tags” es porque flickr las soporta, aunque no tengo demasiado claro para que las usa.

Precisamente en el grupo de discusión de la API de flickr se explican las características de los componentes de una “machine tag”:

• “namespace”: Deben empezar por una letra del alfabeto inglés (a - z) y el resto de caracteres pueden ser dichos caracteres, los dígitos del 0 al 9 y el carácter de subrayado. Se pueden usar mayúsculas y minúsculas indiferentemente (”case-insensitive”)
• predicado: Deben empezar por una letra del alfabeto inglés (a - z) y el resto de caracteres pueden ser dichos caracteres, los dígitos del 0 al 9 y el carácter de subrayado. Se pueden usar mayúsculas y minúsculas indiferentemente (”case-insensitive”)
• valor: Puede contener cualquier carácter, incluidos espacios (en este caso es necesario poner el valor entre comillas).

Además, es conveniente saber que el “namespace” y el predicado se separan con el carácter de dos puntos, y que el predicado y el valor se separan con el carácter de igual ([namespace]:[predicado]=[valor]). En consecuencia, podemos tener “machine tags” como estos:

• geo:locality=barcelona
• flora:tree=”pinus pinea”

Las páginas web de la administración de los Países Bajos deben cumplir, desde septiembre del año pasado los siguientes requisitos (entre otros):

• Usar HTML 4.01 o XHTML 1.0 válido
• Usar CSS y HTML semántico, separando la presentación del contenido.
• Usar el W3C DOM (en vez del de Microsoft (document.All)) (para JavaScript)
• Poner nombres descriptivos a las clases y los id
• Poner descripciones con sentido en los atributos alt de las imágenes

También obliga a ofrecer en formato libre aquellos documentos que se ofrezcan en un formato propietario (como Word).

Más información en la página original (en holandés): Besluit Kwaliteit Rijksoverheidswebsites o en Quirksmode.org: New Dutch accessibility law.

Gracias a César

¿Para qué?

Tenemos un entorno virtual de aprendizaje (EVA) y unos objetos de aprendizaje (OA) a los que se accede a través del EVA. Queremos que, en un momento dado, un usuario determinado, reciba los OA que puede usar. Para ello, contamos con que el EVA conocerá las características del usuario (tipo de máquina que usa (tamaño de pantalla, colores disponibles, limitaciones de software o/y hardware, plugins disponibles), limitaciones físicas o psíquicas (tanto temporales como permanentes), idioma/s, …) y que el OA conocerá los requerimientos que debe cumplir el usuario para ser usado adecuada y provechosamente.

Para que el OA pueda proporcionar la información que el EVA necesita, debemos definir las características del OA de alguna manera. Podemos definir metadatos que especifiquen las “necesidades” del OA o mirar de hacerlo con microformatos.

Sin embargo, los microformatos están pensados para añadir información semántica al contenido que se muestra en la web. Y no es nuestro caso, pues la información que nos interesa tener sobre el OA, al usuario no le interesa para nada.

Los microformatos son una aproximación a la web semántica y lo que nosotros queremos hacer no es semántica.

Y sin embargo, no está de más tener presente los desarrollos que se hacen para la web semántica, porqué siempre pueden ser útiles para los objetos de aprendizaje.

Actualización: César me ha dejado un comentario que me ha hecho dar una vuelta de tuerca más al tema (ventajas de escribir en un blog y de tener compis dispuestos a echar una mano).

Yo veía la información de accesibilidad del OA (creo que habría que buscarle otro nombre), como una información no relevante en cuanto a contenido (lo cual es cierto) y, por tanto, no interesante para los buscadores. Pero pensándolo mejor, sí es una información que pueda ser relevante para los buscadores (o, mejor dicho, para los usuarios que usan los buscadores), aunque no forme parte del contenido. Recomiendo la lectura de los comentarios para seguir mejor el razonamiento. Y, por supuesto, se aceptan más comentarios y sugerencias.

Actualización 2: Ahora bien, de hecho si lo que me interesa es que el buscador entienda que mi OA tiene unas determinadas características “de accesibilidad” tampoco tengo porqué poner esas características en un microformato. También pueden estar en un metadato. De nuevo volvemos a que para temas de accesibilidad, de hecho, los microformatos no son estrictamente necesarios…