Itákora

Aunque parezca mentira, la accesibilidad en la web va más allá de las WCAG. También están las pautas para aplicaciones (user agent) y para herramientas de autor (authoring tools), entre otras. Lo que a continuación sigue es un traducción y resumen de las pautas de Authoring Tools . El original y oficial está en http://www.w3.org/TR/ATAG10/.

Pauta 1. Soportar la creación de contenidos accesibles.
Puntos de comprobación:
1.1 Asegurar que el autor pueda producir el contenido accesible en los diferentes lenguajes de código que soporte la herramienta. [Prioridad 1]
1.2 Asegurar que la herramienta conserva toda la información accesible durante la creación, transformación y conversión. [Prioridad 1]
1.3 Asegurar que, cuando la herramienta genera automáticamente código, éste se conforma con las pautas WCAG 1.0. [Prioridad relativa a lo que pidan las WCAG]
1.4 Asegurar que las plantillas proporcionadas por la herramienta se conforman con las pautas WCAG 1.0. [Prioridad relativa a lo que pidan las WCAG]

Pauta 2. Generar el código estándar válido.
Puntos de comprobación:
2.1 Utilizar las versiones más recientes de las recomendaciones de W3C cuando estén disponibles y apropiadas para una tarea. [Prioridad 2]
2.2 Asegurar que la herramienta genere automáticamente código válido. [Prioridad 1]
2.3 Si el código producido por la herramienta no se conforma con las especificaciones de W3C, informar al autor. [Prioridad 3]

Pauta 3. Apoyar la creación del contenido accesible.
Puntos de comprobación:
3.1 Invitar (Obligar) al autor proporcionar la información alternativa equivalente (e.g., subtítulos, descripciones auditivas, y transcripciones compaginadas del texto para el vídeo). [Prioridad relativa a lo que pidan las WCAG para ese elemento introducido]
3.2 Ayudar al autor a crear el contenido estructurado y a separar la información de la presentación. [Prioridad relativa a lo que pidan las WCAG]
3.3 Asegurar que el contenido generado se conforme con las pautas WCAG. [Prioridad relativa a lo que pidan las WCAG]
3.4 No generar automáticamente las alternativas equivalentes. No reutilizar las alternativas previamente creadas sin la confirmación del autor, excepto cuando la función se sabe con certeza. [Prioridad 1].
3.5 Proporcionar la funcionalidad para editar, corregir, y reusar los equivalentes alternativos para los objetos multimedias. [Prioridad 3]

Pauta 4. Proporcionar las maneras de comprobar y de corregir el contenido inaccesible.
Puntos de comprobación:
4.1 Comprobar e informar al autor de los problemas de la accesibilidad detectados. [Prioridad relativa]
4.2 Ayudar a los autores a corregir los problemas de la accesibilidad. [Prioridad relativa]
4.3 Permitir que el autor conserve el código no reconocido por la herramienta. [Prioridad 2]
4.4 Dar al autor un resumen del estado de la accesibilidad del documento. [Prioridad 3]
4.5 Permitir que el autor transforme un mal código a un código accesible. [Prioridad 3]

Pauta 5. Integrar las soluciones de la accesibilidad en el estilo de interacción de la herramienta.
Puntos de comprobación:
5.1 Asegurar que la introducción de contenido accesible esté integrada naturalmente en el estilo de interacción de la herramienta. [Prioridad 2]
5.2 Asegurar que el autor sienta que está generando contenido accesible de forma sencilla. [Prioridad 2]

Pauta 6. Promover la accesibilidad en la ayuda y la documentación.
Puntos de comprobación:
6.1 Documentar todas las características que promuevan la generación del contenido accesible. [Prioridad 1]
6.2 Asegurar que crea el contenido accesible es una parte integrada de forma natural dentro de la documentación, incluyendo ejemplos. [Prioridad 2]
6.3 En una sección dedicada, documentar todas las características de la herramienta que promuevan la producción del contenido accesible. [Prioridad 3]

Pauta 7. Asegurar que la herramienta de autor sea accesible a los autores con discapacidades.
Puntos de comprobación:
7.1 Utilizar todos los estándares y convenciones del sistema en el que se ejecuta.
En nuestro caso, como se ejecuta en la web, las pautas de WCAG
7.2 Permitir que el autor edite dentro de la vista de presentación sin afectar al código. [Prioridad 1]
7.3 Permitir que el autor corrija todas las características de cada elemento y objeto en una manera accesible. [Prioridad 1]
7.4 Asegurar que la vista de presentación permita la navegación a través de la estructura del documento de una manera accesible. [Prioridad 1]
7.5 Permitir corregir de la estructura del documento de una manera accesible. [Prioridad 2]
7.6 Permitir que el autor busque dentro del contenido dentro de la vista de presentación. [Prioridad 2]

Es un hecho conocido que, dentro de la interacción hombre-máquina, cuanto menos inseguridades genere la máquina en el humano, mejor uso de ésta se hará. Todo esto viene a cuento de que, cuando ves un manual de instrucciones en el que la mitad de las palabras están mal escritas, lo primero que se te pasa por la mente es ’si así de mal han hecho el manual, habrá que ver cómo habrán hecho la máquina’. Ahora que levante la mano el que no se haya topado con una experiencia semejante.

Dentro de las auditorías de accesibilidad que realizo, una de las cosas en las que siempre ‘crujo’ es en la redacción y ortografía. Aunque pillado un poco por los pelos, me escudo en la pauta 14.1. Es que no cuesta nada cerciorarse si tienes dudas, caramba. Que no se está pidiendo un nivel de Premio Cervantes, sólo que esté bien escrito y que quede claro, para que la persona que lo use no diga ‘¡vaya chapuceros!’

Aunque falleció hace casi un año, me entero hoy del óbito del que fue el profesor más interesante de toda mi carrera.

Con él descubrí que la antropología, la psicología y la sociología tienen unos límites entre ellas muy difusos, y que se pueden aplicar a todas las situaciones de la vida. Su idea del “ordenador cerebral” me hizo ver que las máquinas que creamos los humanos no son muy distintas de nosotros mismos. Y si nos conocemos a nosotros mismos, podremos conocer la manera de diseñar mejores máquinas.

Originalidad no le faltaba a la hora de inventar conceptos, como “densitómetro emocional”, “robot emocional” o calificar la anorexia como “virus informático que afecta a la programación del cerebro”.

En clase sus lecciones no eran las clásicas de tomar apuntes como disciplinados escribas del siglo XX, sino que, a través de sus millones de anécdotas, nos introducía en tribalismos y sociedades totémicas. Si se estaba en desacuerdo con algo de lo que él decía, te invitaba a escribir un ensayo con tu postura, obligándote a razonar y buscar datos que apoyen tu punto de vista. Es decir, te obligaba a PENSAR.

Se reía de todo y de todos: de las fiestas de Pamplona, de la Iglesia, de los suizos clasistas, de los políticos y hasta de sí mismo. Con el final de su contrato como profesor para la universidad los alumnos montamos un buen pollo para que se quedara, pero no lo conseguimos. La última clase que dio estubo abarrotada por gente que no éramos de ese curso y le despedimos con una gran ovación, sabiendo que la universidad pública iba a perder a uno de sus mejores profesores.

Hasta pronto, ‘mister Lloregai‘

De forma un tanto rarita, he llegado a lo que se perfila como nueva web del Congreso Fundamentos Web que se celebrará en Oviedo del 3 al 5 de octubre. Entre las novedades un curioso concurso para vestir a la web con la css que los participantes quieran. Los precios, programa y ponentes son aún una incógnita, aunque para eso Manuel González creó un wiki para colaborar y ayudar a la organización de Fundamentos Web.

De momento todo lo que se pueda poner ahí lo consideraré provisional y no espero que nadie corra a reservar avión y hotel basándose en esas fechas. Como decíamos en la Web 1.0, el sitio está “en obras”

Actualización 11/04/2207 9:50: Ya han dejado de estar operativos los enlaces.

Actualización 11/04/2207 18:10: Ya está operativo el sitio oficial. Pero sigue estando “en obras”.

Dice mi manual de “Psicosociología aplicada al Trabajo” que un trabajador necesita de una serie de pausas para rendir mejor a lo largo de la jornada. Y vaya si está en lo cierto. Tras unas pequeñas vacaciones alejada (más o menos) de ordenadores, he vuelto a retomar mis proyectos:

• Doctorado. Me ha escrito mi tutor diciendo que mi propuesta de tesis le gusta y que puedo empezar a trabajar en ella. Puede parecer una tontería, pero llevo desde noviembre retocando el proyecto hasta que hemos dado en el clavo con el tema, la forma y el modo de hacerlo. Para los que no me conozcáis, resumiendo mucho, mi doctorado toca temas de aplicaciones e-learning, accesibilidad web y medición de eficiencia educativa.
• Congresos. Al hilo de mi anterior artículo, voy a presentar otro abundando en los aspectos de accesibilidad de una plataforma de e-learning. De momento el de mobile-learning lo voy a dejar aparcado hasta que termine éste. Lástima, porque se estaba poniendo interesante.
• Itákora. Le tengo que dar dos vueltas al diseño del sitio web. Ya se sabe que en casa del herrero…
• UPA. Le debo al grupo de traducción del Body of Knowledge un capítulo que me comprometí hace unas cuantas semanas.
• Listas de correo y RSS. Ovillo, Cadius y Accesoweb han estado muy activas y yo demasiado ocupada para leer todos sus mensajes. Con Google Reader cerré los ojos, suspiré y marqué “Todos como leídos”. Más de 500 me saturaron.

Investigando para el artículo sobre mobile learning, no dejo de sorprenderme de los avances y direcciones distintas que está tomando la tecnología móvil. En el fundamentos web del año pasado, Daniel Appelquist lo dijo muy clarito:

Tratar a los navegadores de móviles como ciudadanos de primera clase nos abrirá un nuevo mercado.

Sin embargo, cada empresa tira por su lado: en temas de buscadores, Nokia y Google van a partirse el pecho con buenas ideas pero opuestas, mientras que Microsoft apuesta por un navegador que se adapta a las páginas web, y no a la inversa. Por otro lado, empieza a tomarse en serio la interacción natural por voz.

Y todo para un mercado realmente emergente. Aunque hay servicios de todo tipo (mando a distancia de la domótica de tu casa, pedir comida a casa, encontrar aparcamiento, apuestas…) se usa poco más que para llamadas y mensajes. Ni siquiera para la música o leer feeds.

Entonces, ¿cómo pretender que los usuarios realicen tareas de aprendizaje? ¿cómo motivarles? ¿qué características debe tener el servicio de mobile learning para ser atractivo al usuario y que “de verdad” lo use? ¿Cómo convencer a estas personas de utilizar el móvil en sus ratos vacíos (véase esperar al autobús, ir en el metro, plantones…) ?

Preguntando a la gente me encuentro con respuestas bastante sensatas a qué les parecería realizar actividades formativas a través de un dispositivo móvil:

• si gasto la batería para eso, cuando la necesite porque me llamen no podré usar el móvil
• necesito concentrarme para estudiar, no puedo estar en medio de un gran ruido, sujetándome para no caerme y encima leyendo una pantalla pequeña
• prefiero leer un libro a leer en la pantalla del móvil
• no sabía que se puede estudiar a través del movil
• no tengo palm, sólo movil, y es un rollo leer en el movil
• paso de internet en el móvil, que suficiente pago ya al mes
• ¿y eso sirve para algo?

Esta es sólo una pequeña muestra de respuestas que me ha dado la gente cuando le he preguntado sobre la posibilidad de seguir un curso a trávés de un dispositivo móvil. Algunas conclusiones que he sacado:

• limitaciones económicas: internet es caro, las palm/ pda son caras
• limitaciones ergonómicas ambientales: ruido, movimiento
• limitaciones ergonómicas del aparato: la pantalla es pequeña, la batería aguanta poco
• limitaciones psicológicas: preferencia por otros medios (libros),
• otras limitaciones: desconocimiento y/o desprecio de la posibilidad

Como estudio previo es un poco incompleto, pero permite hacerme una idea de dónde atacar si lo que se quiere es potenciar el mobile learning:

• Aunque yo nunca dije nada de teléfonos móviles, la mayoría de las personas a las que pregunté asumieron que hablaba de ellos. Las Palm/pda y los mp3, ni siquieran se consideran. Para este estudio, he descartado al final a los ultramobile pc, dado que aún no se han implantado en el mercado. También descarto portátiles.
• La gente asimila “estudiar” con “leer contenidos”. No concibe los podcast o las películas documentales o escribir un ensayo. Sólo leer.
• La gente desconoce la existencia de cursos adaptados a dispositivos móviles, pero ya de entrada piensan que serían caros y poco útiles. Y eso que mucha gente no sabe cuánto paga de teléfono móvil.
• Prefieren utilizar el móvil para lo que sirve de forma nativa, el resto de aplicaciones son secundarias y sólo se usan en casos concretos en los que no existe alternativa (libros, mapas, juegos).

Interesantes puntos de partida que están sirviendo como base de mi estudio.

Por último, un link de regalo: Guía de desarrollo web para dispositivos móviles.