Tecnologías Web y Alan

¿Dónde está la calidad en la agilidad? Charla de Dan North

2011-11-04T13:30:00.000+01:00

Ayer jueves pasado tuve la oportunidad de asistir a esta charla por Dan North, el inventor de Behaviour-driven Development (desarrollo guiado por el comportamientio). Básicamente Dan trataba la idea de que el desarrollo ágil no cuida la calidad, pero llegando a la conclusión que los principios expresados en el manifiesto ágil (Agile Manifesto) son los mismos que se necesitan para asegurar la calidad. Opina que la calidad se puede lograr de diferentes formas y que las prácticas ágiles nos permiten lograr el mismo objetivo con mayor flexibilidad. Podemos ver el vídeo y las diapsositivas en el sitio de Skills Matter.

Skills Matter es un centro de formación. Está situado en el distrito donde se encuentra silicon roundabout ("rotonda del silicio", en alusión al valle homónimo en California) en una zona barata al norte de la zona financiera de Londres

Congreso JAX London: Java, Ágil, Android

2011-11-04T10:09:00.000+01:00

La semana pasada tuve la suerte de asistir a las tres jornadas de este congreso, JAX London 2011 en Londres. El primer día escogía sesiones sobre Spring. El martes me elección se enfocaba sobre las técnicas ágiles (en vez de las sesiones Android) y el miércoles los ponentes trataban Java de forma más general. Las sesiones para mí más memorables eran:

Spring and Scala: por Eberhard Wolff.
Identity Management with Spring Security: Dave Syer (SpringSource/VMware).
Spring 3.1 in a Nutshell: Sam Brannen (Swiftmind).
Behind the Scenes at Spring Batch: Dave Syer (SpringSource/VMware)
WaveMaker, Spring Roo, SpringSource Tool Suite: Choosing the right tool for the right job. Por Martin Lippert (SpringSource/VMware)
Middleware Everywhere - Ready for Mobile and Cloud: Mark Little (Red Hat)
An Introduction to Neo4j (and Doctor Who): Ian Robinson (Neo Technology). Una base de datos de gráfos y una explicación de como ésta se puede usar para analizar la vida de las partes de un robot a través de muchos años de trabajo en una serie de ciencia-ficción.
Think you don't need software craftsmanship?: Sandro Mancuso (UBS).
Slow & Dirty: Jason Gorman (Codemanship Ltd).Muchas empresas de nueva creación (startups) creen que deben sacar un producto o servicio cuanto antes sin priorizar la calidad. Jason explicaba muy bien como estas iniciativas destruyen su propio porvenir por la falta de calidad y por tanto, de flexibilidad. Como dice, "El software es el negocio." Sin calidad desde el principio, el software no puede evolucionar, y la empresa tampoco.
Grails in the Java enterprise: Peter Ledbrook (VMware)
The Rise and Fall and Rise of Java: James Governor (RedMonk). A pesar de los años el ecosistema Java se mantiene más joven que nunca y sigue creciendo.
Thinking Distributed to Improve Agility: Jamie Allsop. Como los equipos ubicados en distintos zonas geográficas pueden sacar provecho de la distancia para trabajar mejor.
The (not so) Dark Art of Performance Tuning: Dan Hardiker, Jon Mort, (Adaptavist.com)
To Java SE 8 and Beyond!: Simon Ritter (Oracle)
Modular enterprise applications: Mark Nuttall (IBM)
Busy Java Developer’s Guide to NoSQL: Ted Neward. Esta charla fue como un flujo imparable de ideas que nos dio un repaso vertiginoso por toda este campo en algo más de una hora. Impresionante.

Por desgracia las dispostivas no están publicadas en el sitio web del congreso pero muchos sí aparecen en otros sitios (a buscar).

Java y JBoss, dos encuentros en Londres

2011-10-19T19:32:00.000+02:00

Cada mes la comunidad Java de Londres (London Java Community) organiza un encuentro social en un bar céntrico de la ciudad. Empieza a las 18:30 para coincidir con la salida de la oficina.

Eric Schabell charla sobre jBPM

En el mes de mayo estuve en el encuentro en el Porterhouse Covent Garden. La cita este mes de octubre ha sido en el bar de la cadena Slug and Lettuce de Hanover Street cerca de Oxford Circus en la zona comercial. El bar, como es de costumbre, tiene una sala privada en la primera planta. El organizador es Barry Cranford, que lleva una agencia de empleo especializada en Java. El encuentro es una oportunidad no solo para los desarrolladores Java de la ciudad a encontrarse entre ellos sino también para Barry a conocer posibles clientes y orientarnos sobre nuestra trayectoria profesional. Le ayuda un equipo de voluntarios que dan la bienvenida a lo nuevos, entre los cuales algunos de sus colaboradores de la agencia que también pueden dar consejos profesionales.

La noche anterior pude asistir al encuentro mensual del grupo de usuarios de JBoss (JBUG) de Londres. El evento tuvo en las oficinas de Atos Origin cerca de Warren Street. La charla principal fue sobre jBPM, el módulo de gestión de procesos de negocios de JBoss, por Eric Schabell de Red Hat. La charla de Eric fue precedida de dos charlas relámpago sobre OpenShift, un conjunto de servicios de la nube para la plataforma-como-servicio (PaaS) de Red Hat, y sobre JON (JBoss operations network) y como una empresa recopila estadísticas sobre el rendimiento de sus servidores y las trata mediante el paquete R para generar informes.

Taller en Madrid sobre Gestión Ágil de Proyectos

2011-09-14T21:17:00.001+02:00

Acabo de asistir a un taller aquí en Madrid sobre la Gestión Ágil de Proyectos, impartido por Ángel Águeda Barrero de QRP Management Methods International (con sede en Barcelona, para España). Después de tantos años de la tendencia hacia el desarrollo ágil, aún oigo a mucha gente en Madrid quejarse por de la reticencia de los clientes a aceptarla. Me pregunto si se trata de una cuestión cultural, sobre la cultura empresarial española, o si pasa lo mismo en otros países. Curiosamente, Ángel mencionó que algunas ministerios del gobierno español han realizado proyectos con metodologías ágiles. También mencionó su uso para algunos proyectos de defensa en el Reino Unido. La charla abarcó las diferentes metodologías especialmente DSDM Atern y Scrum, pero no mucho acerca de Lean, o Extreme Programming, ya que era más sobre las metodologías de mayor alcance. QRP ofrece cursos de formación y certificación (la misma empresa da la formación y luego pone el examen) en gestión de proyectos ágiles.

Jornada sobre evolución de la normativa de accesibilidad en Londres

2011-06-01T10:52:00.002+02:00

El 25 de mayo tuve la oportunidad de asistir a este seminario patrocinado por el British Computer Society en Londres

Lo temas principales en mi opinión fueron la nueva legislación sobre igualdad y la nueva norma sobre accesibilidad Web del BSI.

Jonathan Hassel dio un ponencia muy animada sobre la nueva normativa BS 8878:2010 Web accessibility. Code of practice (Accesibilidad Web: código de buenas prácticas). La norma complementa WCAG, y proporciona recomendaciones sobre la forma de implantar la accesibilidad en la organización. Se cita en el plan nacional de e-Accesibilidad del gobierno del Reino Unido como base de sus recomendaciones sobre el desarrollo de servicios accesibles online. Incluye recomendaciones sobre la participación de personas con discapacidad en el proceso de desarrollo y el uso de herramientas automatizadas para ayudar con las pruebas de acceso, y también la gestión de las normas y el proceso para el cumplimiento continuado de las directrices y las especificaciones de accesibilidad existentes. La norma complementa las pautas del W3C con un rigurosa y completa norma sobre el proceso. Se prevé su promoción hacía un norma ISO. Incluye un nuevo término "producto web" que abarca no sólo sitios web sino las nuevas "apps" (aplicaciones) y los contenidos generados por los usuarios. El BSI (el organismo de normalización) ha editado un díptico, una "guía para el consumidor" que explica lo que pueden esperar o exigir en cuanto a la accesibilidad y como reclamar. Es interesante que la guía menciona que si un sitio Web anuncia su cumplimiento de las pautas, pero en realidad no cumple, se le puede denunciar ante las autoridades por publicidad engañosa.

Ha sido gratificante la diversidad de los asistentes desde universidades, grandes y medianas empresas, la policía regional de Londres, bancos, Correos, la prensa y organizaciones de la discapacidad.

Reunión en Londres el grupo de educación y difusión de la WAI

2011-05-25T15:38:00.002+02:00

Los pasados días 23 y 24 de mayo se ha reunido en Londres este grupo de trabajo (Education and Outreach Working Group) de la Iniciativa para la Accesibilidad Web. La reunión ha tenido lugar en las dependencias de la BBC (la radiotelevisión de Gran Bretaña), un día en la BBC Media Village (la aldea de los medios) y el segundo en la emblemática sede Television Centre inaugurado ya hace 50 años.

El debate se ha centrado en como posicionar y difundir la nueva versión de las pautas de accesibilidad para las herramientas de edición (ATAG). Estas pautas consisten en dos partes, la segunda sobre la forma de generar contenidos accesibles conformes con las Pautas de Accesibilidad para los Contenidos Web, y la primera sobre la accesibilidad de las propias herramientas, es decir su interfaz de usuario. La accesibilidad de estas herramientas es muy importante, para permitir a todas las personas con y sin discapacidad crear contenidos. La versión existente (1.0) data del año 2000. En aquella época las herramientas de edición se planteaban como algo especializado para un grupo reducido de profesionales, mientras hoy en día el contexto ha cambiado de forma radical y todos somos autores de los contenidos Web a través de los blogs, y los Medios de Comunicación Social Interactiva. Entonces el modelo de los componentes esenciales de la accesibilidad Web que posiciona a los desarrolladores con las herramientas de edición en un lado y los consumidores con sus navegadores en otro ya no es correcto. Se mezclan los roles de autor y lector, y por lo tanto el planteamiento de las pautas debe adaptarse. Se comentó durante la reunión el buen ejemplo esperanzador de WordPress, que tras un primer contacto por paerte de la WAI, ha iniciado una iniciativa para tener en cuenta las recomendaciones de ATAG

Encuentro Social de Desarroladores Java en Londres

2011-05-19T22:58:00.004+02:00

El martes pasado tuve la oportunidad de participar en este encuentro mensual de la comunidad Java de Londres. Tienen lugar en la primera planta del pub Porterhouse del barrio de Covent Garden, lugar de encuentro de muchos de los profesionales de la zona al salir de la oficina.
El tema de la noche fue los tests (de conocimientos, no de los sistemas) y su relevancia en el campo del desarrollo. Había mucha charla profesional aunque no he detectado mucha sobre el tema anunciado. Hubo una serie de rompecabezas matemáticas del tipo que se han usado en las entrevistas de trabajo para filtrar a los candidatos, y premios de libros y camisetas para los ganadores. El organizador es Barry Cranford de la agencia de empleo especializada ClearView y un grupo de desarrolladores Java. Es un encuentro mensual y se anuncia en Meetup.com. Muy recomendable para el desarrollador Java que se encuentre por Londres el día del encuentro.

Programador Java certificado

2011-05-18T17:47:00.005+02:00

El lunes, por fin, aprobé el examen de la certificación "Oracle Certified Professional", Programador Java SE 6. Hace ocho años lo tenía preparado pero lo dejé para antes de especializarme en el campo de la accesibilidad. Ahora llega la hora de ampliar mi alcance profesional.

Caja de herramientas para la accesibilidad con Acrobat

2011-02-01T19:23:00.010+01:00

Adobe Acrobat incluye varias características para ayudarnos a mejorar la accesibilidad de los documentos. Sin embargo los que trabajamos con documentos que sean pequeños y sencillos sabemos lo difícil que puede resultar corregir los problemas que presentan los mismos. Una de las funcionalidades que siempre me ha hecho en falta es la posibilidad de buscar y reemplazar las etiquetas. Una pequeña empresa suiza ha creado una pequeña caja de herramientas que resulta muy potente y ahorra muchísimo trabajo.

PDF-TagRenamer es una extensión (plug-in) para Adobe Acrobat creada por la empresa suiza XY Media. Funciona en versión de prueba de 10 días y se puede comprar la licencia por 129€, que seguramente se puede amortizar rápidamente si necesitamos corregir documentos grandes. En la actualidad solo existe la versión en alemán. Incluyo en esta página un pequeño glosario alemán-español. Para descargarlo hay que acceder a la página de producto de PDF-TagRenamer (en alemán). En la sección Ausprobieren (probar) hay un enlace download. Para comprarlo hay un enlace Kaufen. La extensión aparece como una opción del menú "Avanzadas" de Acrobat. Proporciona cuatro funcionalidades no disponibles hasta el momento en Acrobat. Permite:

Cambiar rápidamente el nombre de las etiquetas.
Modificar las asignaciones de función.
Automatizar la creación de marcadores páginas.
Configurar la visualización inicial al abrir el documento.

Cambiar los nombres de las etiquetas

Al convertir documentos de otras aplicaciones se crean etiquetas de accesibilidad con nombres que no son estándar. Por ejemplo, el estilo "Título 1" de Microsoft Word se convierte no en <H1> sino en <Título 1>. El resultado es que las ayudas técnicas no reconocen los encabezados del documento, que es un problema grave de accesibilidad.

PDF-TagRenamer rastrea el árbol de etiquetas y crea una lista de las que contiene el documento. Permite definir los nombres de sustitución. Al lanzar la operación PDF-TagRenamer reemplaza de forma global los nombres en la lista. La lista se puede guardar para usar en futuros documentos similares.

Modificar las asignaciones de función

Para que las ayudas técnicas reconozcan las etiquetas no estándar es necesario corregir la tabla de asignación de funciones del documento. Con la lista de nombres de etiquetas PDF-TagRenamer permite definir su asignación de función. La herramienta actualiza la tabla de asignación de acuerdo con la lista. La lista se puede guardar para usar en futuros documentos similares.

Automatizar la creación de marcadores páginas

Si PDFMaker u otra aplicación de creación de PDF no reconoce correctamente los encabezados de sección, o su jerarquía, no se crearán los marcadores. PDF-TagRenamer permite definir la estructura de marcadores que se creará a partir de las etiquetas seleccionadas, el número de niveles, y la forma en que éstos se deben abrir. Se puede guardar la configuración para su uso posterior.

Configurar la visualización inicial al abrir el documento

Permite la configuración de la primera página que se abra, la vista (pantalla completa, una sola página, páginas opuestas, etc), ampliación, visibilidad del panel de marcadores, etc. igual que con las otras opciones, se puede guardar la configuración para su uso posterior.

Glosario Alemán-Español del Interfaz de PDF-TagRenamer

No es completo pero es suficiente para usar la herramienta.

Absatz: paragraph.
Absatzelemente: Elementos de bloque.
Alle vorhandenen tags: Todas las etiquetas disponibles.
Andere: Otros.
Ansicht wählen: Configurar vista.
Anwenden: Aplicar.
Anzahl erstellen: Numero a crear.
Anzahl Lesezeichenebenen: Numero de niveles de marcadores.
Anzeige: Ver (menú)
Anzeige beim Öffnen setzen: Configurar visualización al abrir.
Aufgeklappte Lesezeichenebenen: Numero de niveles de marcadores expandido.
Dockumenttitel: Título del documento.
Dockumentstruktur verwenden: Usar estructura del documento.
Dockumenttitel setzen: Definir título documento.
Eigenschaften: Propiedades.
Einstellung: Configuración.
Erweitert: Expandido (barra de herramientas o menú).
Farbe: Color.
geändert: Modificado.
Gruppenelemente: Elementos de agrupación.
Lesezeichen: Marcadores.
Lesezeichen erstellen: Crear marcadores.
Lesezeichen-Fenster und Seite: Panel de marcadores y página.
Lesezeichen eigenschaften: Propiedades de marcadores.
Listenelemente: Elementos de lista.
Löschen: Suprimir.
Menüleiste: Barra de menús.
Name: Nombre.
Neu: Nuevo.
Neuer Eintrag: Entrada nueva.
Neuer Tag-Name: Nombre nuevo de etiqueta.
Profil: Perfil.
Rollenzuordnung: Asignación de rol.
Schliessen: Cerrar.
Sonstiges: Otros.
Speichern: Guardar.
Speichern als: Guardar como.
Stil ebene X: Estilo nivel X.
Tabellenenelemente: Elementos de tabla.
Tab-reihenfolge bei allen Seiten setzen: Definir orden de tabulación para todas las páginas.
Tags: Etiquetas.
Tags scannen: Rastrear etiquetas.
Textelemente: Elementos de texto.
Unterteilung: División.
Vorhandene Tag-Name: Nombre actual de etiqueta.
Werkzeugleiste: Barra de herramientas.

Mensajes

Bei der Aktivierung ist ein Fehler aufgetreten (Fehler Code 255). Wollen Sie eine E-mail-Nachricht an das Support-Team automatisch erstellen lassen?: Durante la activación se produjo un error (código de error 255). ¿Desea crear un mensaje de correo electrónico al equipo de apoyo de forma automática?
Lesezeichen konnten nicht erzeugt werden, weil keine Tags für Überschriften vorhanden sind: No se pueden crear los marcadores porque no hay etiquetas de encabezado disponibles.
Wollen sie die bereits vorhandenen Eiträge überschreiben?: ¿Está seguro que desea sobrescribir las entradas existentes?
Wollen Sie Ihre vorgenommenen Änderungen als Tag-Profil speichern: ¿Guardar los cambios como perfil de etiquetado?

Webelo: Herramienta de Evaluación de Accesibilidad Web

2008-05-21T19:58:00.001+02:00

El proyecto AcTF (Accessibility Tools Framework) está trabajando en la creación de una colección de componentes base dentro de Eclipse, de código abierto, tal y como anuncié en este blog en septiembre del año pasado (Eclipse creará el Marco para Herramientas para la Accesibilidad).

Ya se ha anunciado la primera versión de prueba de ACTF Webelo. Webelo es una colección de componentes para Eclipse que permite a los creadores de contenidos Web y desarrolladores de aplicaciones Web a llevar a cabo evaluaciones de la accesibilidad de su trabajo. Webelo aprovecha el componente navegador Mozilla para evaluar el árbol de estructura creado por el navegador en vez del código fuente recibido del servidor. Se entrega con un paquete de reglas basado en la Lista de Comprobación de Accesibilidad de IBM. Es una versión muy preliminar de un producto en desarrollo y la documentación en inglés no es completa.

El anuncio original en inglés está en el sitio del proyecto en eclipse.org

WCAG 2.0 Se Mueve: Lista para Prueba de Conducción

2008-04-30T21:00:00.003+02:00

Las Pautas de Accesibilidad para los Contenidos Web 2.0 (WCAG 2.0) se han publicado como Recomendación Candidata del W3C hoy día 30 del abril 2008. La etapa de Recomendación Candidata significa que existe un amplio consenso sobre su contenido técnico, y el W3C anima a la implementación WCAG 2.0. Para mayor información (en inglés):

WCAG 2.0 Candidate Recommendation Implementation Information (información para la implementación de la recomendación candidata WCAG 2.0) antes del 30 de junio del 2008
How WAI Develops Accessibility Guidelines through the W3C Process (Cómo la WAI Desarrolla las Pautas de Accesibilidad a Través del Proceso W3C)
Overview of WCAG 2.0 Documents (Resumen de Documentos WCAG 2.0)

Se solicitan también comentarios antes del 30 de junio.

Visita a Technosite de Andrew Arch de la WAI

2008-04-29T09:57:00.002+02:00

Tras su paso por el Taller sobre Cognición y la Web en Granada (a que asistió también nuestro compañero Nacho Madrid) el Dr Andrew Arch ha visitado las oficinas de Technosite. Andrew, antiguamente de sección de accesibilidad Web de Vision Australia, trabaja en la Iniciativa para la Accesibilidad de la Web (WAI) del W3C. Es especialista en las necesidades de las personas mayores en cuanto al acceso a la Web y ha acudido a Technosite para aprender más sobre las necesidades de este colectivo en España.

El Grupo de Estudios Sociológicos de Technosite, liderado por Luis Miguel Bascones dentro del proyecto Inredis, junto con nuestro compañero Antonio Jiménez Lara, le informó sobre las investigaciones y “focus groups” que ha realizado el departamento con personas mayores sobre su uso de Internet en colaboración con los investigadores José Gimeno y Mercedes Turrero. Posteriormente mantuvimos una reunión con Carlos Martínez Ozcáriz y Paca Tricio de la Unión Democrática de Pensionistas, quienes nos informaron sobre las necesidades y reivindacaciones de los mas de un millón de pensionistas afiliados de UDP.

Andrew Arch está realizando un estudio sobre en el marco del proyecto WAI-AGE (Envejecimiento, Educación y Armonización) del W3C por encargo de la Comisión Europea. WAI-AGE durará 36 meses. Los objetivos del proyecto (cada uno descrito con más detalle en la página de la WAI) son:

Informar el desarrollo de extensiones para las distintas pautas WAI y los materiales formativos que las acompañan.
Informar mejor el trabajo de W3C/WAI en cuanto a las necesidades de las personas mayores, y fomentar el diálogo entre las comunidades de discapacitados y de mayores
Proporcionar recursos formativos orientados a la industria
Proporcionar recursos formativos orientados hacia las organizaciones que representan y sirven las comunidades de mayores, y hacia individuos con necesidades de accesibilidad relacionadas con la edad avanzada
Promover mayor armonización de estándares de accesibilidad Web...

La información recopilada en Madrid se incorporará en un Resumen de la Literatura y un Análisis Comparativa de las personas con necesidades especiales de accesibilidad relacionadas con la edad avanzada. Existe un documento borrador de requísitos para el trabajo.

¿Ha muerto la aplicación móvil? Algunos empresarios afirman que sí

2008-04-16T09:26:00.004+02:00

En un artículo “Is the Mobile Web Dead? Some Mobile Entrepreneurs Say Yes” el autor cita a dos corrientes de opinión. Uno, Russel Beattie (creador de Mowser y anteriormente evangelista de Web móvil para Yahoo!) en “The end of Mowser” afirma que la Web móvil está en vía muerta por falta de interés por parte de los usuarios (pero su negocio es la transformación de contenidos para dispositivos pequeños). El otro, “Mobile Applications, RIP” dice que al contrario las aplicaciones descargadas están en vía de desaparición por la proliferación de plataformas que hace que no sea económico el desarrollo (de múltiples versiones) pero que los dispositivos más potentes como iPhone y Android hacen más atractivo el desarrollo de aplicaciones en Web por basarse en el entorno unificado de la Web. Pero yo pregunto ¿cuántos usuarios en el mundo real tienen un iPhone? ayer anunciaron en el Reino Unido que venderán el iPhone por sólo 169 libras (€210) para atraer nuevos clientes. Según algunas fuentes las ventas del iPhone han sido menores de lo esperado.

Adiós Witty

2008-04-14T09:19:00.002+02:00

Ayer recibí la triste noticia que ha fallecido este sábado Witty, la perra guía de Lourdes. Me acuerdo que cuando nos anunciaron que vendría a trabajar con nosotros una persona con perro me extrañó mucho, pero Witty era tan amable, cariñosa y mansa que nos convenció enseguida. Todos disfrutamos mucho de trabajar junto con ella en la oficina. Esperemos que el proceso de asignación de otro perro de la ONCE no tarde demasiado. Parece que puede durar entre 18 meses y un año.

Pero hay una noticia feliz que es que tenemos una colega nueva, Sara, guiada por Jep, un Labrador negro (que además entiende inglés). Incluso Jep ha estado en grave peligro estos días tras tragar tres calcetines pero le operaron y afortunadamente ya se ha recuperado.

Como Usan la Web las Personas con Teléfono Móvil

2008-04-03T13:22:00.003+02:00

Últimamente el Grupo de Trabajo sobre Educación y Difusión (EOWG) de la WAI y el Grupo de Trabajo sobre Buenas Prácticas para la Web Móvil han trabajado sobre como ayudar a sus públicos respectivos mejor comprender las relaciones entre la accesibilidad de contenidos Web para las personas con discapacidad y la adecuación de los contenidos para los dispositivos móviles. Hemos publicado un borrador de un documento bueno aunque bastante complejo, pero nos damos cuenta de que hace falta algo más breve, con menos detalle y más fácil de comprender. Tenemos lo que llamamos el documento de “experiencias comunes” Experiences Shared by People with Disabilities and by People Using Mobile Devices (Experiencias comunes entre las personas con discapacidad y las que usan dispositivos móviles) que muestra que las barreras encontradas por las personas con discapacidades en muchos casos son paralelas a las impuestas por las características de diseño de los dispositivos móviles pero creo que hay una necesidad de un documento introductorio de aún más alto nivel para ayudar a la gente comprender la experiencia de la Web móvil desde el punto de vista del usuario. Serviría a los especialistas en accesibilidad Web y los desarrolladores novatos de Web móvil. Es muchas veces poco comprendido.

Existe un documento redactado por el EOWG (aun borrador interno tantos años después) llamado How People with Disabilities Use the Web. Hice una traducción de una versión anterior, Cómo utilizan la Web las personas con discapacidad. Tiene tres apartado principales:

Para el contexto móvil los dos primeros traducen a:

Escenarios de personas utilizando la Web con dispositivos móviles
Diferentes aspectos del contexto Web móvil que pueden afectar la experiencia de usuario

El tercero no parece tener equivalente puesto que el usuario poco puede hacer para superar las barreras causadas por los contenidos Web. Pero quizás sí. Pueden enchufar teclados alfanuméricos o usar pantallas grandes.

Los escenarios con móviles pueden ser por ejemplo:

Juan vive en un país en vía de desarrollo. Su familiar tiene un teléfono móvil que comparten que él usa para navegar por la Web. En su pueblo no hay ordenadores ni conexión por cable a Internet. El teléfono tiene una pequeña pantalla en blanco y negro. Cuesta muy caro conectar por lo que solo puede navegar poco tiempo.
Jorge viaja con frecuencia en avión y usa su smartphone de alta gama para mantenerse al día con las noticias de los negocios en los aeropuertos. Tiene una pantalla grande de color y teclado alfanumérico. Lleva siempre un teléfono pequeño para llamadas de voz. Su empresa paga todos los gastos de conexión.
María es ciega y usa su teléfono móvil con lector de pantalla para mantenerse al día con las noticias durante su viaje de una hora en tren para ir cada día a la oficina. No le interesa el diseño visual de las páginas porque no las puede ver, pero le ayuda mucho una maquetación sencilla con estructura clara.

El apartado “Diferentes aspectos del contexto móvil que pueden afectar a la experiencia de usuario” analizaría los aspectos tratados en los escenarios y los relacionaría con las Mejores Prácticas para la Web Móvil. Por ejemplo:

Pantalla pequeña
Alto coste de conexión
Teclado numérico

Este documento llevaría vinculos con el sobre “experiencias comunes” que a su vez funcionaría de enlace entre las recomendaciones Mejores Prácticas para la Web Móvil y las Pautas de Accesibilidad de los Contenidos Web.

Progreso con los tests MobileOK Pro

2008-03-25T17:54:00.001+01:00

Como ya adelanté en febrero (“Inicio de la redacción de los tests MobileOK Pro”) en el momento de la primera reunión, los integrantes del grupo de trabajo POWDER (estrechamente relacionado con las Buenas Prácticas para la Web Móvil) hemos aprovechado el momento para hacer una reunión de trabajo sobre estos tests para un sello de conformidad.

Hemos repasado la redacción para mejorarla e incorporar los comentarios recibidos. Hemos tenido en cuenta las opiniones en contra de este documento (en base a la dificultad de comprobar de manera fiable algunos de las buenas prácticas). He argumentado a favor pero reconociendo que algunas de las buenas prácticas no se pueden comprobar (por ejemplo TESTING y THEMATIC_CONSISTENCY). Technosite ha abogado por unos tests de “caja negra” (que se puedan comprobar desde fuera de la empresa productora sin tener acceso a los procesos internos del sitio Web) tal y como hemos usado para la accesibilidad.

Ponencia de Technosite en la jornada de difusión POWDER en Londres

2008-03-25T17:33:00.003+01:00

POWDER (Protocolo para Recursos de Descripción de Recursos) es un vocabulario de metadatos definido dentro del marco del W3C. Está previsto su uso para la descripción de grupos recursos en la Web mediante un formato legible por sistemas automatizados y la aplicación de reglas de razonamiento. El significado de los metadatos se basará en la semántica formal, lo que permitirá la síntesis a través de diferentes campos.

POWDER está previsto para reemplazar PICS, un formato creado en sus orígenes para permitir la creación de etiquetas para la protección de menores. La motivación para la creación de POWDER es que PICS es anterior a XML y UTF8 y no es suficientemente expresiva para aplicaciones semánticas avanzadas.

Uno de los problemas con POWDER ha sido una visión estrecha de su aplicación debido a sus orígenes en PICS. Muchas personas tienen la creencia equivocada que solo sirva para etiquetado de contenidos para la protección de menores. Por este motivo el grupo de trabajo POWDER (del cual Fundación ONCE es miembro activo) organizó una jornada de difusión en Londres el día 18 de marzo.

El evento tuvo lugar en las dependencias de la Asociación GSM. Participaron representantes de Hutchinson Whampoa, Vodafone, Segala, Technosite, AOL, Opera Software, Deutsche Telekom, Arqiva Satellite Media Solutions, Verizon, .mobi TLD y la propia Asociación GSM.

La ponencia de Technosite, como es de esperar trató los casos de uso de accesibilidad. Es decir la utilidad para los usuarios de los sellos de accesibilidad y el posible uso del vocabulario IMS Global en la enseñanza, y como los sellos se pueden relacionar con otros sellos POWDER de otros ámbitos. Los ejemplos de casos de uso aparecen en el documento “POWDER: Use Cases and Requirements”, traducido en mi artículo del mes de octubre del 2007, “El uso de los sellos automátizables en la accesibilidad”.

Soporte para WAI-ARIA en Internet Explorer 8

2008-03-06T16:38:00.002+01:00

La creciente popularidad de Ajax y HTML dinámico con script ha creado importantes barreras para los usuarios con discapacidad, especialmente los usuarios invidentes con lector de pantalla.

Para intentar superar este problema dentro de la WAI (la Iniciativa para la Accesibilidad de la Web, del W3C) se está desarrollando desde hace unos años la especificación ARIA (aplicaciones Internet ricas y accesibles). El W3C define ARIA como un sintaxis para hacer accesibles los contenidos Web dinámicos y los controles de interfaz de usuario creados por el diseñador. Hasta ahora la solución ha sido la creación de versiones simplificadas estáticas para los usuarios de lector de pantalla. Con ARIA el desarrollador puede comunicar a las ayudas técnicas la funcionalidad (rol), estado y propiedades de sus elementos HTML. Por ejemplo, se puede manipular un DIV mediante script y transmitir a las ayudas técnicas que funciona como botón, una casilla de selección o una barra de deslizamiento.

ARIA está ya bastante avanzado, y se ha implementado en Firefox y otros navegadores y en lectores de pantalla, pero hasta ahora el gran obstáculo ha sido su implementación en Microsoft Internet Explorer que sigue siendo el navegador más usado. La buena noticia es según Microsoft “Internet Explorer 8 emplea información de rol, estado y propiedades a través de ARIA para communicar con las ayudas técnicas.” Fuente: Internet Explorer 8 Readiness Toolkit.

Rich Schwerdtfeger uno de los principales arquitectos de la especificación WAI ARIA comenta la noticia en su blog:

Me alegro saber que Microsoft ha añadido soporte por WAI-ARIA en Internet Explorer 8. Aunque estoy seguro que el soporte está [aún] incompleto, es una afirmación de compromiso por parte de Microsoft y apoya el esfuerzo con ya el 90% de los navegadores Web.

Más información

Internet Explorer 8 Beta 1 Whitepapers, W3C’s ARIA Support
Microsoft announces support for WAI-ARIA in IE 8 beta en el blog de Rich Schwerdtfeger

Gracias a Steve Faulkner, por publicar la noticia en el blog del Paciello Group.

Test para detección precoz del glaucoma

2008-03-06T16:02:00.005+01:00

Traducción rápida de un artículo publicado por la BBC (en inglés, “Test para detección precoz del glaucoma”).

Expertos en el Reino Unido están desarrollando un programa informático para detectar indicios del glaucoma antes de las pruebas convencionales.
El equipo del hospital de Londres, el Moorfields Eye Hospital afirman que la prueba hará posible evitar que muchos pacientes se queden ciegos.
Puede resultar difícil diagnosticar glaucoma, ya que muchos pacientes a menudo no se dan cuenta de los síntomas hasta que ya se ha perdido mucha vista para siempre.
Se estima que el glaucoma afecta a 67 millones de personas en el mundo, pero sólo la mitad de los casos están diagnosticados.
Están en situación de riesgo de glaucoma:

Las personas con una historia familiar de la enfermedad

Personas de más de 40 años de edad; el riesgo sigue aumentando con la edad

Las personas de origen africano occidental
Por eso se ha llamado el glaucoma la “enfermedad silenciosa de la ceguera”.
Se calcula que si sólo se detectaran el 10% de los casos de glaucoma del Reino Unido con tratamiento precoz se podría ahorrar hasta un €1,3 billones cada año.
Si se diagnostica a tiempo, la condición puede ser fácilmente tratado con gotas para los ojos.
La condición daña el nervio óptico, que lleva la información visual desde el ojo al cerebro.

A través de Internet
El test de detección de l movimiento Moorfields (“Moorfields Motion Detection Test” (MDT)) está diseñado para evaluar el campo visual. El software se puede descargar a un ordenador portátil, y, finalmente, se espera que este disponible directamente desde Internet. Un punto blanco central y varias líneas blancas se muestran en una pantalla gris. El paciente tiene que mirar atentamente al punto central y apretar el botón del ratón cada vez que ve una de las líneas moverse. Las líneas se mueven con la misma velocidad, pero las distancias cambian con el progreso de la prueba, lo que permite a los expertos detectar el grado de pérdida visual.
El hospital de Moorfields dice que la prueba es asequible, portátil, rápida - y tiene el potencial de detectar el glaucoma antes de las pruebas convencionales, y con mayor precisión.
El profesor Vis Viswanathan, el cirujano consultor en glaucoma en el hospital de Moorfields que ha desarrollado el sistema, afirma que las pruebas convencionales -que se concentran en la habilidad de ver la luz- no miden la capacidad del paciente para detectar movimiento. Sin embargo, la capacidad de percibir el movimiento es una de las primeras cosas que se pierden en las personas que padecen glaucoma.
A partir de abril, en clínicas de Toronto, Roma, en África y en Singapur será iniciarán pruebas del software con el fin de verificar su eficacia de forma independiente. El año que viene los investigadores esperan conseguir financiación para lanzar software en todo el Reino Unido.

Este jueves [6 de marzo] será el primer Día Mundial de Glaucoma, para aumentar la sensibilización sobre la condición.

Sitio Web de la prueba Moorfields Motion Displacement Test.

Progreso de WCAG 2.0

2008-03-06T09:15:00.004+01:00

Traducción del mensaje de Shawn Henry “March 2008 Update: Moving WCAG 2.0 to the next stage” enviado al Grupo de Interesados de la WAI.

Les comunico las últimas novedades en los trabajos de WCAG 2.0 para que sepan como ha progresado desde la publicación del Borrador de Última Convocatoria de diciembre de 2007.
A principios del mes de marzo el grupo de trabajo ya había resuelto la mayoría de los más de 200 comentarios técnicos y de redacción sobre el segundo Borrador de Última Convocatoria de WCAG 2.0. El grupo de trabajo está actualmente, ultimando las resoluciones de comentarios y respuestas a personas que han enviado comentarios. Se está preparando para la siguiente etapa del proceso W3C, “Recomendación Candidata”, que se explica en el documento How WAI Develops Accessibility Guidelines through the W3C Process.
El Grupo de Trabajo WCAG espera publicar WCAG 2.0 como “Recomendación Candidata” en abril o mayo de 2008. El enfoque entonces será en recopilar la “experiencia de implementación” de diseñadores y desarrolladores que usan WCAG 2.0 en sus proyectos Web. La WAI proporcionará más información sobre como ayudar en las pruebas de implementación y como proporcionar comentarios (feedback).
En función de cuanto dure la etapa de Recomendación Candidata, el último borrador de WCAG 2.0 (llamada “Propuesta de Recomendación”) podría estar disponible en el último trimestre del 2008.
Para más información, consulten [en el inglés original]:
Overview of WCAG 2.0 Documents
WCAG 2 FAQ

La televisión es importante para las personas ciegas

2008-03-04T08:53:00.004+01:00

Traducción libre y rápida de una noticia “TV 'is important to blind people'”publicada por la BBC (televisión de servicio público del Reino Unido) que relata como es la audio descripción de los programas de televisión en aquel país.

La televisión puede desempeñar un papel fundamental en la vida de millones de personas con discapacidades visuales, según el Real Instituto Nacional de Ciegos.
Un estudio indica que la mayoría de las 2 millones de personas con discapacidad visual en Gran Bretaña pasan tiempo viendo la televisión para descansar y como entretenimiento.
El RNIB anima a las personas con problemas discapacidad visual a aprovechar el servicio gratuito de audio descripción (AD) de la televisión digital. Es un comentario que describe el lenguaje corporal, las expresiones [de la cara] y movimientos.
La investigación, por la Universidad de Nottingham, ha encontrado que más de la mitad de los entrevistados afirman ver series y programas de actualidad.
Y casi las tres cuartas partes ven la televisión durante cinco horas o más por semana, y un 86% afirman que verían más si hubiera más DA disponible.
La Audio Descripción es un servicio de la TV digital disponible en Sky, Virgin Media and algunos descodificadores de programación gratuita.
Richard Orme, director de accesibilidad del RNIB, afirma: “la televisión es a menudo criticada como algo malo, pero nos une - y unirnos con los amigos puede depender más de saber lo que ha pasado en las últimas series, que en las noticias de la última crisis internacional”.
“Muchos de los momentos televisivos más queridos nunca han sido plenamente disfrutado por las personas ciegas y deficientes visuales.”
“La AD está cambiando esto. Además de dar a las personas con discpacidad visual acceso a los programas favoritos de series y entretenimiento, puede transformar su relación con el mundo que los rodea.”
Reclaman un aumento
El diputado David Blunkett, que es [ciego] apoya la campaña. Dice: “Sé por mi propia experiencia que las personas con discapacidad visual a menudo nos sentimos aisladas y frustradas en este mundo de cultura y entretenimiento predominantemente visuales.”
“Aumentar el número de programas de televisión con audio descripción es una forma muy simple de mejorar la vida de las personas invidentes o con visión reducida en todo el país.”
Según el RNIB, sólo el 13% de la programación actual se emite con audio descripción, de la cual el 85% son retransimisiones.
El RNIB reclama que los organismos de radiodifusión aumenten el número y la calidad de los programas que se ofrece con este servicio, del 10% al 20%.
El estudio de la Universidad de Nottingham consistió en dos grupos de enfoque con un total de 13 participantes ciegas y deficientes visuales, y una encuesta telefónica de 172 participantes.

Inicio de la redacción de los tests MobileOK Pro

2008-02-06T13:35:00.000+01:00

Los días 5 y 6 de este mes de febrero he participado en representación de Technosite en la reunión de trabajo del subgrupo (“taskforce” en inglés) encargado de redactar los tests para el sello MobileOK Pro. Este sello indicará los contenidos Web adecuados para su uso con dispositivos móviles. Los tests para la concesión del sello se han dividido en dos grupos, los que se pueden automatizar y los que no. Los trabajos del grupo hasta ahora han seguido este plan de trabajo:

Buenas prácticas para la Web Móvil
Una herramienta automática para la evaluación de contenidos Web
Un conjunto de tests automatizables adecuados para la herramienta (llamado MobileOK Basic)
Un sello de conformidad, pero sin definir las condiciones de uso
Actualmente, unos tests para el resto de las buenas prácticas

El documento MobileOK Basic recoge las buenas prácticas que se pueden evaluar de forma automática, que con un razonamiento bastante rebuscado, se supone que sean además las más importantes; sigo siendo bastante escéptico sobre este aspecto. Pero allí están y son una recomendación candidata del W3C.

Los tests no automatizables en los que estamos trabajando requiererán la intervención de un operador humano y por lo tanto no son de todo repetibles de forma fiable: por rigoroso que sea la deficnición del test, cada operador tendrá su interpretación particular. Esta ha sido la problemática con las pautas para los contenidos de la Web 1.0 del W3C, pero dentro de los proyectos del WAB Cluster, hemos consensuado una interpretación común, plasmada en la metodología UWEM 1.0, por lo menos para las prioridades 1 y 2. No obstante, las MWBP no tienen prioridades, y mientras muchas de las pautas WCAG 1.0 dejan margen de interpretación, muchas de las MWBPs apenas se pueden comprobar de ninguna forma. Por ejemplo, [TESTING] “Realice las comprobaciones con dispositivos reales, además de simuladores”. No obstante, la intención es definir un test para este punto. Por este motivo he propuesto dejar de lado las buenas prácticas que no se pueden comprobar, creando así una serie de prioridades en el sello.

La industria francesa de Internet reclama mayor accesibilidad

2008-01-29T19:30:00.000+01:00

En el país vecino del norte el agrupamiento Renaissance Numérique (Renacimineto Digital) reclama al gobierno francés un mayor compromiso con la accesibilidad de los servicios electrónicos.

Según la revista ZDNet en un reciente artículo “Accessibilité des sites: Renaissance Numérique met la pression sur le gouvernement” esta asociación que agrupa varios grandes actores en la industria basada en Internet junto con investigadores, ha reclamado mayor accesibilidad Web para las personas con discapacidad, afirmando que Francia está muy retrasada en sus obligaciones. Reclaman la aplicación inmediata de la ley aprobada en el año 2005. Según el estudio MeAC - Measuring Progress of eAccessibility in Europe (medición del progreso de la accesibilidad electrónica en Europa) realizado en octubre del pasado año 2007 para la Comisión europea "97% de los sitios públicos franceses no alcanzan ni siquiera el primer nivel de accesibilidad" de las Pautas de Accesibilidad de los Contenidos Web del W3C. Según veo en el informe el resultado de España fue un poco mejor, con solo un 80% de suspenso.

Además la asociación reclama la puesta en marcha del "referencial francés de accesibilidad de las administraciones francesas" (RGAA) una detallada redacción que se cierne a las pautas WCAG 1.0, pero añade tests, consejos y técnicas de aplicación, y prevé una escala de prioridad temporal para su implantación progresiva. RN reclama la publicación de este documento que estaba previsto para noviembre del pasado año 2007 pero que se sigue esperando. La versión anterior (y supongo todavía vigente) fue la metodología Accesiweb de nuestros socios Braillenet en colaboración con una agencia estatal. Accesiweb está basado en las pautas WCAG 1.0, pero con requisitos suplementarios y un cambio de prioridades, y 28 criterios de usabilidad.

RN reclama la aplicación de los requisitos de accesibilidad al conjunto de los sitios web en Francia, como es el caso en Estados Unidos y el Reino Unido (y para los grandes en España desde la ley de diciembre 2007). Reclaman la creación de una oficina para tratar las reclamaciones de los usuarios, que parece ser algo como la Oficina Permanente Especializada del Consejo Nacional de la Discapacidad que según la reciente legislación debe recibir las reclamaciones en España.

RN se define como un laboratorio de ideas, y agrupa a gran numero de los líderes en el mundo Web francés y varias figuras universitarias entre los cuales Pierre Kosciusko-Morizet (presidente de PriceMinister), Christophe Parcot (director general de Yahoo), Mats Carduner (director general de Google) y Alex von Schirmeister (director general de eBay Francia). Quizás hace falta en España una alianza de los actores en el campo para llevar a cabo una iniciativa similar.

Jornadas ICCHP 2008 y la Edad Avanzada

2008-01-29T09:01:00.000+01:00

Las jornadas ICCHP (Conferencia Internacional sobre los Ordenadores Ayudando a las Personas con Necesidades Espaciales) tendrán lugar en Linz, Austria del 9 al 11 de julio. El plazo para la recepción de las ponencias es el próximo 1 de febrero (quedan pocos días).

Este año se incluye una sesión especial temática sobre el tema de la Accesibilidad Web y la Edad Avanzada. Se solicitan ponencias sobre la accesibilidad Web y las dificultades relacionadas con al edad avanzada. La WAI (supongo por motivo de su proyecto europeo WAI-AGE) ha hecho un llamamiento a los investigadores, expertos usuarios y otros interesados en la accesibilidad y la edad avanzada y sugiere un enfoque en los siguientes áreas:

Pautas sobre los requisitos de la población de edad avanzada
Estudios e investigaciones sobre los requisitos en cuanto a accesibilidad de las personas mayores
Estudios e investigaciones sobre las prácticas de diseño y de edición de contenidos para la población de edad avanzada
Estudios e investigaciones sobre los beneficios de la inclusión de la población de edad avanzada

Se publican las pautas para ponencias completas y breves (en inglés) en http://www.icchp.org/call/papers. Las ponencias se redactan en inglés.

El año pasado acudi a las jornadas, también en Linz, y puedo confirmar lo interesante que es. La pena es que por el programa paralelo no se pueden escuchar todas las ponencias.

Primeros borradores públicos de los documentos sobre la Accesibilidad de los Contenidos Web y la Web Móvil

2008-01-22T23:58:00.000+01:00

En el W3C el Grupo de Trabajo sobre Buenas Prácticas para la Web Móvil (Mobile Web Best Practices Working Group) y el de la WAI sobre Educación y Difusión (Education and Outreach Working Group) acaban de publicar de forma oficial el borrador del documento sobre la "Relación entre las Buenas Prácticas para la Web Móvil 1.0 y las Pautas de Accesibilidad para los Contenidos Web" junto con dos documentos de soporte. Son tres documentos que forman un conjunto. Esto significa que aunque los documentos no están completos, han llegado a un momento en que los grupos de trabajo creen que están en condiciones de recibir su primera revisión por el público. Han sido aprobados por los grupos de trabajo y han superado un proceso de revisión de forma. Hay tres documentos (todos en inglés):

Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices (Accesibilidad de los Contenidos Web y la Web Móvil: Como hacer un sitio Web accesible a la vez para personas con discapacidad y para dispositivos móviles). Es una página que sirve de introducción al siguiente http://www.w3.org/WAI/mobile/
Relationship Between Mobile Web Best Practices 1.0 and Web Content Accessibility Guidelines (Relación entre las Mejores Prácticas para la Web Móvil 1.0 y las Pautas de accesibilidad para los contenidos Web). Este es el documento principal, el más importante de los tres y contiene los detalles técnicos. Es un primer borrador público de trabajo del W3C http://www.w3.org/TR/mwbp-wcag
Experiencias Comunes entre las Personas con Discapacidad y las Personas que Usan Dispositivos Móviles. Contiene una tabla que describe el paralelismo entre las experiencias de los dos perfiles de usuarios http://www.w3.org/WAI/mobile/experiences

Estos documentos describen para los objetivos de diseño el solapamiento entre las pautas de accesibilidad para personas con discapacidad y las mejores prácticas para los dispositivos móviles. En representación de Fundación ONCE soy el editor del segundo.

Los borradores constituyen una base para permitir a los interesados discutir y contribuir a este trabajo. En algunas partes hay texto borrador y en otros sólo hay un esquema mínimo del texto que se redactará posteriormente (en concreto los apartados WCAG 2.0 and MWBP Together y WCAG 1.0 to MWBP).

Me han preguntado si no se puede traducir los documentos al español para facilitar su revisión por las personas que no conocen el idioma o no tienen ánimo para leerlos en inglés. El problema es que cambian muy a menudo (cada semana) y no es práctico mantener versiones paralelas. No obstante, en diciembre publiqué en este blog una traducción al español de la Introducción al documento sobre la Web Accesible y Móvil como estaba entonces. El texto original ya ha cambiado pero permite tener una idea del alcance de los documentos.

Animo a todos los que estáis interesados en estos temas a repasar los documentos, especialmente el segundo de la lista anterior y enviar los comentarios o en inglés a public-bpwg@w3.org o en español a mí (achuter@technosite.es) preferentemente antes del 4 de marzo del 2008.

Inicio de los trabajos para las Buenas Prácticas para la Web Móvil 2.0

2008-01-16T12:04:00.000+01:00

Cada vez más se emplean aplicaciones entregadas mediante la Web de toda la vida, con interfaces "ricas" para dar mayor funcionalidad y una experiencia más dinámica. El grupo de trabajo del W3C ya da por concluidos los trabajos sobre las Buenas Prácticas para la Web Móvil 1.0 (con excepción de los tests pendientes) y ahora está iniciando una segunda fase, los trabajos para redactar la versión 2.0 (BP2). Ha lanzado sobre la lista pública una llamada para material y referencias como base de los trabajos.

Mientras BP1 trata la ampliación del uso de los contenidos Web (en la práctica, XHTML) hacía los dispositivos móviles, y en concreto los más limitados (el contexto de entrega por defecto), BP2 abarcará además los contenidos para los dispositivos más avanzados, las aplicaciones "Web 2.0" y la llamadas "aplicaciones Web", es decir aplicaciones dentro del navegador e independientes y fuera del mismo, a las cuales se acceda mediante las tecnologías Web existentes. Cito el comunicado del grupo:

El grupo de trabajo anima al público que sigue el BPWG a considerar como las innovaciones recientes en las aplicaciones Web y las tecnologías que las soportan, cuando se extienden a los contextos móviles se beneficiarán de unas pautas específicas similares a las [contenidas] en BP1 (al menos), por ejemplo usabilidad/accessibilidad, interoperabilidad, eficiencia. Esto puede incluir por ejemplo:
Referencias a buenas prácticas, pautas de desarrollo, y otras publicaciones existentes
Temas específicos de preocupación o oportunidad
La relación entre estos temas y los procesos de desarrollo de aplicaciones, por ejemplo herramientas, información sobre dispositivos, comunidades de desarrolladores, certificación
Se ruega esta información antes del 15 de febrero, para su incorporación en los borradores de trabajo de BP2 lo antes posible.
Se agradece u interés y apoyo al BPWG en este esfuerzo.

El mensaje original está disponible en el archivo público del grupo de trabajo.

Sitio social entorno a los libros

2008-01-09T16:03:00.000+01:00

Aunque lleva tiempo ha sido un descubrimiento para mi. LibraryThing es un sitio social entorno a los libros. No los libros electrónicos sino los de siempre, en papel. Aparte de saber los libros que tiene uno mismo, una de las ideas "sociales" es conocer quién más tiene cada libro para poder intercambiar comentarios.

También en el tema de bibliografía, en Technosite mantenemos la base de datos de bibliografía de Discapnet de libros relacionados con la discapacidad y la accesibilidad.

El diseño del sitio deja mucho que desear en cuanto a la accesibilidad (marcos sin descripción, controles de formularios sin etiqueta, por ejemplo) pero tengo intención de contactar con los gerentes para preguntar por qué. No pretendo que en la bibliografía de Discapnet no haya necesidad de mejoras.

Como digo, la modesta biblioteca de nuestro departamento de accesibilidad en Technosite biblioteca está ya catalogada: http://www.librarything.es/catalog/technosite.

Reaparece "Cómo utilizan la Web las personas con discapacidad"

2008-01-03T10:23:00.000+01:00

Me han llamado la atención a que esta traducción ya no estaba disponible desde la baja del dominio infoescena.es. Tenía intención de hacer un traslado ordenado a otros URL pero al final se me olvidó. Es interesante saber que estos documentos no se pierden, gracias al archivo Web "Wayback machine" que ya almacena 85 billones de páginas. En el caso de infoEscena.es podemos ver su contenido desde sus inicios en el año 1996. Estoy de acuerdo con el principio de no cambiar los URLs de los documentos pero con un esfuerzo razonable y por eso lo he trasladado con retraso a otro sitio.

Ya está publicado el documento en mi recién estrenado sitio en GooglePages, con el URL siguiente: http://achuter1.googlepages.com/pwd_use_web.html. Existe (en su inglés original) un borrador (interno al grupo de trabajo) más reciente de este documento de mayo del 2005 que debería de traducir un día pero no sé cuando será. Una década después de iniciarlo ya es hora de publicar una versión definitiva de este documento. Los recientes trabajos sobre la accesibilidad y la Web móvil, comentados ya en este blog, darán unos nuevos casos de uso para este documento y espero que volvemos a trabajar en él en el grupo de trabajo de la WAI.

Vídeo Testimonio de Second Life con Discapacidad

2007-12-14T10:34:00.000+01:00

Hace un par de semanas en las jornadas australianas OZeWAI 2007 (que no tienen que ver que con la WAI), Russ Weakley y Roger Hudson dieron una ponencia "La Web 2.0 y el concepto del Diseño Universal". Mostraron un vídeo de una persona, Judith, con paralisis cerebral que participa en el mundo virtual Second Life. Han publicado el vídeo en YouTube para permitir a las personas interesadas en la accesibilidad conocer mejor la experiencia de usuario con discapacidad.

Me parece muy interesante pero está en inglés y no muy fácil de comprender. Para facilitar la comprensión de las personas hispanohablantes (y las que no pueden oír el sonido), publico aquí una traducción de la transcripción en texto también disponible (la transcripción en inglés):

[Titulo: Wheeling in Second Life]

Judith: Trabajo durante el día y cuando llego a casa solo me quedan un par de horas. Entonces, cuando por fin me pongo con mi propio correo electrónico y la correspondencia que ha llegado durante el día me quedan como mucho 45 minutos o una hora para hacer lo que sea, entonces..

Russ: ¿Y cuál es la cosa que más te interesa en la Web actualmente?

Judith: Second Life. Tengo silla de ruedas en Second Life. Puedes elegir si quieres tener silla de ruedas o no. Puedes usar multas, en Second Life puedes tener la discapaidad que tienes en la vida real.

Russ: ¿En Second Life siempre permaneces en tu silla de ruedas?

Judith: No, no, no.

Russ: ¿En Second Life hay mucha gente en silla de ruedas?

Judith: Simon Walsh.

Russ: ¿Del Reino Unido?

Judith: Si. Y él siempre permanece en su silla de ruedas. Exactamente como en la vida real, me decepciona la actitud de la gente en Second Life. He hecho yo misma un experimento. Voy a ese [?] sitio Web y una persona sin discapacidad entra en la pista de baile y baila con diferentes avatares o personas o como los queires llamar, durante media hora. Entonces me retiro y me pongo en mi silla, vuelvo, y sigue allí la misma gente pero no querriían conocerme.

Russ: ¿Existen lugares especiales dóde las personas con silla de ruedas suelen estar?

Judith: Si, "Wheelies".

Russ: ¿Y, "Wheelies", qué es?

Judith: Es un club construido especialmente por personas, un chico, con parálisis cerebral, del Reino Unido.

Russ: ¿No puedes llevar allí?

Judith: Si.

[Título: Wheelies, fundado por Simon]

Judith: Por desgracia, como en la vida real, tienes que dar la vuelta a los obstáculos, no puedes pasar a través. Puedes volar encima. Oh, ¡allí está Simon!.

Russ: ¿Está allí, no?

Judith: Si. Estaba allí antes, allí dentro [...]

[Título: ¿Cuántas personas visitan "Wheelies"?]

[Diálogo de texto en pantalla: (Le pregunta Judith cuántas personas visitan Wheelies cada semana) "Wheelie o norm?" Unos cien creo.]

Judith: Cuando empecé logramos un par de cientos.

[Título: Entrar en la pista de baile.]

Judith: ¿Es Simon allí arriba? El avatar... [mirando hacia la pantalla] eso es él en la vida real.

Russ: ¿Salió él en Gran Hermano?

Judith: Si, en el Reino Unido. [girando hacia la pista de baile] Y esa es la DJ, esa chica de vestida verde y ella [?...] de DJ allí. Y te habla en esa cosa allí.

Russ: Ah, si?

Judith: Y me esta hablando.

Russ: ¿Crees que resultará ser una herramienta muy útil para las personas que no puede moverse mucho, que tegnan problemas de movilidad en la vida real?

Judith: Si, porque puedes tener amistades sin tener que salir físicamente para encontrarlos.

WCAG 2.0, otro borrador de última convocatoria

2007-12-12T11:35:00.000+01:00

El Grupo de Trabajo sobre las Pautas de Accesibilidad al Contenido en la Web (WCAG) ha publicado un segundo borrador de trabajo de última convocatoria de las Pautas de Accesibilidad del Contenido en la Web 2.0, así como los documentos que lo acompañan Comprender las WCAG 2.0 y las Técnicas para WCAG 2.0. Este hito significa que el grupo de trabajo ha respondido a y resuelto todos los cientos de comentarios recibidos sobre el borrador anterior y ahora solo se esperan comentarios no sustanciales. El plazo para los comentarios es hasta el 1 de febrero de 2008. Si se recibieran comentarios que diesen lugar a modificaciones sustanciales en el documento, se volvería a publicar otro "último" borrador. En caso contrario, pasado el plazo para resolver los comentarios el documento pasará a publicarse como "Recomendación Candidata", para permitir su aplicación práctica para resolver los problemas que puedan surgir.

Además del documento normativo, las pautas son acompañados por otros documentos de apoyo:

WCAG 2.0 Referencia Rápida (borrador de última convocatoria) es una herramienta para revisar los requisitos y trabajar con WCAG 2.0 con los títulos de las técnicas suficientes para su cumplimiento, que permite filtrar la lista para incluir solo las tecnologías y niveles de interés.
Técnicas para WCAG 2.0 (borrador de última convocatoria) contiene detalles concretos para el desarrollo de contenidos Web accesibles, con por ejemplo, muestras de código HTML.
Comprender WCAG 2.0 (borrador de última convocatoria ) entra en más profundidad en las intenciones del grupo de trabajo y información más detallada para aprender y aplicar WCAG 2.0 para las personas que desean conocer las pautas con más detalle.

En la edición actual, las técnicas individuales y los criterios de éxito en el documento "Comprender..." aparecen en páginas HTML separadas, una mejora notable para el lector.

Los comentarios se pueden enviar según se explica (en inglés) en las instrucciones para comentarios (http://www.w3.org/WAI/WCAG20/comments/). Sidar mantiene un grupo WCAG2-espa para recopilar en español los comentarios para enviarlos conjuntamente al grupo de trabajo.

Esperemos que el borrador sea adecuado y que no de lugar a modificaciones sustanciales, para lograr pronto la largamente esperada aprobación definitiva de esta norma que tanta falta nos hacen.

Introducción al documento sobre la Web Accesible y Móvil

2007-12-02T21:14:00.000+01:00

Siguen los trabajos en los grupos de Buenas Prácticas para la Web Móvil (MWBP) y el Grupo de Educación y Difusión de la WAI para la redacción del documento con el grandioso título "Relación entre las Buenas Prácticas para la Web Móvil 1.0 y las Pautas de Accesibilidad para los Contenidos Web". El documento está disponible en su inglés original pero para difundir el mensaje a un público más amplio me parece interesante citar la introducción al documento en traducción española:

Para el diseñador de contenidos para la Web móvil, este documento explica por qué es importante tener en cuenta las necesidades de todos los usuarios, incluidas las personas con discapacidad, y cómo usan los dispositivos móviles para acceder a la Web. Para una persona con discapacidad que accede a la Web con un dispositivo móvil, explica que existen otras pautas diferentes a las WCAG que pueden mejorar su experiencia con la Web móvil. Para los que trabajan en el campo de la discapacidad o la accesibilidad Web explica cómo las Buenas Prácticas para la Web Móvil pueden mejorar la accesibilidad para las personas con discapacidad, y con un poco más de esfuerzo y comprensión esas buenas prácticas pueden producir una diferencia aun mayor.
Muchos sitios Web ya han adoptado las Pautas de Accesibilidad para los Contenidos Web (llamadas en este documento WCAG). WCAG explica como hacer accesibles los contenidos Web para personas con discapacidad. En muchos casos el cumplimiento de WCAG es obligatorio. Las Buenas Prácticas para la Web Móvil 1.0 (llamadas en este documento MWBP) especifica buenas prácticas para proporcionar los contenidos Web a los dispositivos móviles. El objetivo principal es el de mejorar la experiencia del usuario en la Web cuando se accede desde estos dispositivos.
Cada vez más, se diseñan los contenidos Web para cumplir uno u otro de estos conjuntos de pautas o buenas prácticas. Sin embargo, una comprensión incorrecta de los requisitos y supuestos acerca de las características de usuario o de dispositivo sobre los cuales se basan da lugar a una implementación no óptima. Es uno de los propósitos de este documento servir de ayuda para justificar o argumentar el cumplimiento de alguna de las recomendaciones. Los beneficios incluyen:

A menudo se gasta un esfuerzo y un coste innecesarios para cumplir con las recomendaciones de forma separada o consecutiva. Este documento explica los solapamientos entre las dos recomendaciones, para mejorar la eficiencia.

Los proveedores de contenidos pueden decidir no adoptar alguna de las recomendaciones debido al coste que puede imaginar. Este documento explica los solapamientos y sinergias entre las dos recomendaciones y las formas en que una vez se adopte una recomendación, la otra es menos onerosa.

Los especialistas en los campos de la “accesibilidad Web” o la “Web móvil” pueden desconocer la importancia uno del otro y pueden tener dificultad para comunicarse. Este documento puede ayudar a difundir el conocimiento y mejorar la comunicación ayudando a los especialistas en los diferentes campos comprender que son aspectos relacionados y paralelos. Ayudará a los formadores de alumnos que ya conozcan uno de los campos, a usar la terminología y los conceptos con los cuales estén familiarizados y evitar repetir material que los alumnos ya conocen.

Los vendedores de herramientas de evaluación pueden gastar un esfuerzo y un coste innecesarios para desarrollar implementaciones de tests que ya existen para otra recomendación. Este documento les permitirá comprender cómo pueden fácilmente reutilizar o adaptar implementaciones existentes.
Puede resultar útil para la justificación de la adopción o de WCAG o de las MWBP en un sitio Web que ya cumple uno de ellos, o para la adopción de ambos conjuntamente. Para la accesibilidad, la Iniciativa para la Accesibilidad de la Web proporciona un documento de ayuda Developing a Web Accessibility Business Case for Your Organization.

La norma UNE 139803 y la armonización de la accesiblidad Web

2007-11-22T16:51:00.000+01:00

La reciente publicación del Real Decreto 1494/2007, de 12 de noviembre, que requiere el cumplimiento de la norma UNE 139803 ha dado lugar a mucha discusión en blogs y foros. Según un reciente mensaje, "es compatible con las WCAG 1.0 y salvo un par de detalles (algún requisito de la UNE tiene más prioridad que en las WCAG 1.0, como el 4.3 que pasa a tener prioridad 1) si se hace un sitio web conforme con la prioridad 1 y 2 de las WCAG 1.0 también se cumple con casi todos requisitos de la norma UNE". Pues no exactamente,

Para lograr UNE nivel A al realizar una evaluación WCAG 1.0 nivel A, es necesario cumplir además los puntos UNE:

4.4.4 (WCAG 4.3, prioridad 3, "Identifique el idioma principal...")
4.5.1 (WCAG 13.1, prioridad 2, "Identifique claramente el objetivo de cada vínculo")

Para lograr UNE nivel doble-A al realizar una evaluación WCAG 1.0 nivel doble-A, es necesario cumplir además los puntos UNE:

4.3.9 (WCAG 5.5, prioridad 3, "resúmenes de las tablas")
4.4.4 (WCAG 4.3, prioridad 3, "Identifique el idioma principal...")
4.5.9 (WCAG 9.4, prioridad 3, "orden lógico para navegar con el tabulador").

Como no está permitida la reproducción de dicha norma no puedo citar el texto de los requisitos, pero quedará claro por su aproximada equivalencia con los puntos de los puntos de comprobación de las pautas WAI.

Cada país desarrolla sus propias normas o pautas. Lo que no todo el mundo entiende es que una de los mayores obstáculos a la creación de sitios Web accesibles es la falta de herramientas de edición que ayuden a cumplir con las pautas. Y una de las excusas de los fabricantes es que hay tantas normas que no pueden conocerlas todas y menos aun cumplir con ellas. ¿Qué tiene que hacer el fabricante de herramientas de edición o gestores de contenidos para permitir a sus clientes cumplir con la normativa en cada país? O cada región o provincia; he leído hoy que en Canadá (cuyas pautas de diseño para los sitios Web públicos son la envidia de otros países) la provincia de Quebec está desarrollando unas pautas propias. ¿Cuanto tardarán Cataluña y Canarias en sacar su propias pautas también?

Está previsto que a partir de ahora los sellos Technosite de nueva concesión cubran además los puntos WCAG necesarios para cumplir además con la norma UNE para intentar que la accesibilidad Web en España tenga el mismo significado que en el resto de Europa.

Accesibilidad y las Buenas Prácticas para la Web Móvil en las jornadas del W3C

2007-11-12T17:23:00.001+01:00

La semana del 5 al 9 de este mes de noviembre ha tenido lugar en Cambridge, Massachussetts (Estados Unidos) en el plenario técnico anual del W3C. En representación de Fundación ONCE y Technosite He participado en las reuniones de los grupos de trabajo de Educación y Difusión de la (EOWG) de la Iniciativa para la Accesibilidad de la Web (WAI) y del Mobile Web Best Practices Working Group (grupo de trabajo sobre Buenas Prácticas para la Web Móvil, en adelante MWBP).

Para mi lo más llamativo ha sido la aceptación por parte del grupo MWBP del documento sobre la relación entre las Pautas de Accesibilidad para los Contenidos Web (WCAG) y las Buenas Prácticas para la Web Móvil. El grupo MWBP ha decidido trabajar sobre el documento en el grupo principal en no en un subgrupo (como he descrito en un artículo anterior “Inicio de los trabajos sobre accesibilidad y las Buenas Prácticas para la Web Móvil”). No obstante la falta de interés por parte de muchos miembros del grupo fue palpable durante la reunión. En el grupo EOWG hemos tratado el documento también, no tanto en sus aspectos técnicos sino acerca de su facilidad de comprensión y adecuación al público objetivo. La WAI ha expresado su preocupación por el enfoque en WCAG 1.0 en vez de 2.0. El argumento es que el documento de buenas prácticas para moviles está basado en WCAG 1.0, y esa versión es la que más se usa en la actualidad y probablemente así seguirá durante la vida del documento. Hemos acordado incluir referencias al borrador de WCAG 2.0 junto a las para WCAG 1.0.

El segundo día los dos grupos hemos participado en una sesión conjunta. Fue un momento importante, la primera vez que el grupo de móviles se ha encontrado con un grupo de trabajo de accesibilidad.

Avance de WCAG 2.0

2007-11-12T17:04:00.000+01:00

Muy a menudo se me pregunta “¿Cuando estará definitivo WCAG 2.0?” Pues el grupo de trabajo ha resuelto casi todos los comentarios del borrador del pasado mes de mayo y ha anunciado que está resolviendo este mes de noviembre todos los comentarios recibidos y que el (ya segundo) último borrador de Las Pautas de Accesibilidad para los Contenidos Web 2.0, estará listo este mes de diciembre. Entonces habrá un plazo de unas semanas o incluso meses para resolver estos comentarios. Si los cambios necesarios son sustanciales, el documento volverá a la etapa de ultimo borrador; en caso contrario (esperemos que sí) pasará a ser candidato a recomendación para permitir su implementación en proyectos reales. Posteriormente pasará a la etapa de propuesta de recomendación y se someterá a la aprobación por los socios del W3C. Entonces está ya más cerca el gran día pero queda camino delante todavía.

Reorganización en la WAI

2007-11-05T21:58:00.000+01:00

En las ultimas semanas se han ido anunciando cambios en la organización en la Iniciativa para la Accesibilidad de la Web (WAI) del W3C. En la reciente reunión del W3C este mes de Noviembre hemos conocido los últimos nombramientos.

Sigue como directora Judy Brewer de la WAI. Shadi Abou-Zahra lleva desde hace unos años el grupo de trabajo sobre herramientas de evaluación y corrección (Evaluation and Repair Tools) a partir ahora será el responsable de la que con nombre grandiosa se llama “Oficina del Programa Internacional” (International Program Office) que reune las actividades no técnicas, especialmente el grupo de trabajo de Educación y Difusión (Education and Outreach Working Group, en adelante EO).

Desde su incorporación en la WAI hace unos años Shawn Henry ha llevado el trabajo del día a día del grupo EO. A partir de ahora Shawn preside el grupo aunque Judy seguirá participando activamente.

En el W3C existe la figura del contacto en el equipo W3C que es empleado del mismo mientras los presidentes de los grupos de trabajo suelen ser empleados de los organismos miembros del consorcio. Michael Cooper sigue como contacto para el grupo de trabajo sobre las Pautas de Accesibilidad de los Contenidos Web (WCAG), y el de Protocolos y Formatos (PFWG).

En las ultimas semanas se ha iniciado el trabajo sobre el nuevo proyecto que la WAI realizará por encargo de la Comisión Europea sobre la accesibilidad Web y las personas mayores, WAI-AGE. El trabajo se llevará a cabo dentro del grupo de trabajo EO. Nos ha sido una grata sorpresa conocer la buena nueva de que ha sido nombrado nuevo miembro del equipo del W3C y responsable del proyecto Andrew Arch. Antes de su incoporación en el W3C Andrew ha trabajado en Vision Australia. Andrew ha sido compañero del grupo EO desde hace muchos años.

Últimamente el grupo EO ha tenido una carga creciente de trabajo con la documentación de usuario de la nueva tecnología WAI-ARIA y para WCAG 2.0 además del nuevo proyecto WAI-AGE. Esperemos que los nuevos cambios sirvan para agilizar el trabajo tan importante del Education and Outreach Working Group.

El uso de los sellos automátizables en la accesibilidad

2007-10-25T19:12:00.000+02:00

En representación de Technosite participo en el grupo de trabajo del W3C sobre sellos legibles por sistemas automáticos. Esta tecnología tiene sus orígenes en los sistema de protección de menores para permitir a los sitios "adultos" etiquetar sus contenidos para permitir a los sistemas de protección impedir el acceso por los menores. El pionero en el campo es el FOSI o Instituto de Seguridad Online Familiar.

Tras el éxito de esa aplicación, y tras un largo periodo de esfuerzo para lograr la aceptación por la comunidad Web (por temor al uso de los sellos para propósitos de censura) el uso de los sellos en formato RDF se ha consolidado y ampliado gracias al proyecto Quatro. Este proyecto ha creado un vocabulario de metadatos, llamado RDF-CL (en inglés “RDF Content Labelling”) y unas herramientas para el proveedor de contenidos, el proveedor de sellos y para el usuario. Entre los socios españoles están IQUA (calidad de los contenidos) y Web Mèdica Acreditada (fiabilidad de la información médica). Uno de los miembros del grupo, Segala ya emplea sellos RDF en la certificación de accesibilidad.

Para consolidar y consensuar el trabajo el W3C ha creado el grupo de trabajo Powder (Protocolo para recursos de descripción en la Web). Para guiar la redacción de los documentos, se han definido una serie de casos de uso, que son los usos que que los distintos actores esperan obtener de los documentos. Como parte del trabajo el grupo me ha encargado redactar nuevos casos de uso para la tecnología en cuanto a la accesibilidad. Espero que estos caso de uso sirvan también para ilustrar a los que no estáis en el grupo la utilidad de los sellos para promover la accesibilidad de la Web. Por ese motivo los presento aqui en traducción.

Es importante tener en cuenta los tres aspectos diferenciados en los dos casos:

Quién emite el sello: El autor del contenido (caso B) o terceros (Caso A)
Qué describe el sello: El cumplimiento de pautas (caso B) o las características del contenido (caso B).
Quién interpeta el sello: El sello se presenta directa o indirectamente al usuario para que éste elija el contenido (caso A) o el usuario avisa de sus preferencias a un sistema externo que decida de forma automática lo que mejor le conviene al usuario (caso B).

Caso de uso A (sello de terceros, cumplimiento de pautas, elección por el usuario)

Iris participa en un grupo de autoapoyo de voluntarios que evalúan accesibilidad de contenidos Web. Los miembros evalúan el cumplimiento de las Pautas de Accesibilidad de los Contenidos Web (WCAG) y en el servidor Web del grupo publican sellos aplicables a sitios Web. Los sellos expresan el cumplimiento como resultados de tests en EARL, el Lenguaje de Evaluación y Reporte.
Un servicio de búsqueda Web coopera con el grupo y recopila metadatos de los sellos que publica el grupo. Esto le permite incluir información de accesibilidad en los resultados de la búsqueda y proporcionar listados de resultados según las preferencias del usuario con prioridad a las páginas que cumplen ciertos puntos de comprobación de las pautas.
Janet desea comprar discos por Internet. Tiene destreza limitada y por lo tanto le resulta difícil usar el ratón. El servicio de búsqueda tiene en cuenta su preferencia para las páginas que facilitan la navegación por teclado (por ejemplo cumplimiento de la Pauta 9. Diseñe para la Independencia del Dispositivo de WCAG 1.0). Janet busca discos de su artista preferido con el interfaz 'búsqueda de tiendas' del servicios de búsqueda.
El servicio de búsqueda recupera un conjunto de URIs de su índice que corresponden con su consulta y usa su base de datos de metadatos de los sellos para indicar los sitios que no cumplen con WCAG 1.0 pauta 9, para permitir a Iris elegir los sitios que cumplen.

Caso de uso B (sellos propios, características de contenido, correspondencia de perfiles)

Colin es alumno en la Universidad Mundial. A veces Colin estudia en casa con su equipo especial Braille pero mientras está en el campus prefiere escuchar el material de curso con lector de pantalla (perfil 1). Su hermana María estudia algunos temas comunes y, a veces, estudia con él, compartiendo un ordenador describiendo ella lo que ocurre en pantalla (perfil 2). Cuando María estudia a solas no usa ayuda técnicas (perfil 3). Pero entre los dos tienen tres perfiles de necesidades y preferencias y pueden cambiar entre ellos. Los perfiles imponen diferentes requisitos para los recursos que Colin y María pueden usar adecuadamente.
El personal docente de la universidad produce material didáctico en versiones alternativas para satisfacer de la mejor manera posible, las diferentes necesidades de usuario. El personal está formado para saber cómo crear sellos que describan las características de accesibilidad de su material con metadatos AccessForAll (medadatos "acceso para todos").
El sitio Web de la universidad dispone de una aplicación que almacena los perfiles de necesidades de usuario, también expresadas en metadatos AccessForAll. El sistema analiza los sellos de contenidos incrustados en el material didáctico y usa reglas para descubrir versiones alternativas de contenidos adecuadas al perfil activo del usuario.
Cuando María estudia a solas (perfil 3) un diagrama complejo se puede presentar en su versión original pero si está estudiando con Colin pueden activar el perfil 2 y el sistema descubre y entrega la misma imagen del diagrama junto con una descripción detallada en forma de texto. Si Colin está estudiando solo y no puede ver la imagen y selecciona el perfil 1 puede leer sólo la descripción textual.

El texto original en inglés está en la Nota del Grupo de trabajo Powder, “POWDER: Use Cases and Requirements”.

Ultimatum sobre Accesibilidad para los Sitios Web Públicos del Reino Unido

2007-10-22T13:09:00.000+02:00

En un borrador interno de propuestas para el Reino Unido se contempla que a los sitios Web públicos que sigan sin cumplir las pautas de accesibilidad se les retirará el uso de los dominios “gov.uk” informa el boletín mensual gratuito “e-Access Bulletin.”

La nueva norma, “Proporcionar Sitios Web Inclusivos: Accesibilidad Centrada en el Usuario” es un borrador que redacta la Oficina Central de la Información, una agencia del gobierno central que ayuda a los organismos públicos con sus campañas de información.

Si se aprueba la norma, los sitios existentes tendrán que cumplir con las Pautas de Accesibilidad de los Contenidos Web en su nivel doble-A antes de diciembre del 2008. Los sitios nuevos deberían cumplir inmediatamente.

Los sitios que no cumplen serían objetos del proceso de retirada para los nombres de dominio .gov.uk (dominio de segundo nivel reservado para los sitios públicos) según la normativa vigente. Es una medida que recuerda las reglas de uso del dominio de primer nivel .mobi, cuyos contenidos deben cumplir las buenas prácticas o correr el peligro de ver su dominio suspendido según la política de cumplimiento .mobi.

Sería muy problemático cumplir con la norma afirma “e-Access Bulletin” basándose en los datos disponibles. En la actualidad no cumplía ningún sitio público según las investigaciones publicadas por el propio gobierno en el año 2005 durante la Presidencia de la Unión Europea. Solo un 3% de los sitios públicos cumplían el nivel A que es el mínimo. En España la situación no es más esperanzadora. Según el informe del Observatorio de la Infoaccesibilidad de Discapnet "Portales web de las Comunidades Autónomas" en el mismo año no cumplía ningún sitio y según el informe “Accesibilidad de los servicios electrónicos de la Administración General del Estado” solo uno de los servicios analizados alcanzó el cumplimiento del nivel doble-A.

Technosite particpa en Techshare 2007

2007-10-11T13:56:00.000+02:00

Este año, Technosite ha participado en Techshare 2007. Techshare son unas jornadas que "resalta el papel de la tecnología en la vida cotidiana de las personas con discapacidades, con una mirada no solo a la Web sino al software, móviles, estándares, conformidad y mucho más". Technosite ha participado a nivel de empresa en la ponencia sobre la certificación europea de acesibilidad Web Euracert que dío Pierre Guillou (con mi participación en la parte de preguntas y respuestas). En el sitio Web de Techshare se publica el resumen de la ponencia. Las diapositivas están en el sitio de Euracert.

Roni Hang, investigadora en movilidad para peronas ciegas de Australia presentó una interesante comparativa entre cuantro soluciones de posicionamiento por GPS: Route 66 con lector de pantalla, Trekker de Humanware, StreetTalk con Destinator y WayFinder (la ponencia Beyond turn-by-turn instructions).

Dick Lunenborg de la Fundación Bartiméus (Holanda) dio un ponencia sobre las experiencias en un instituto de educación especial para facilitar el acceso a la informática para jóvenes con múltiples discapacidades con aplicaciones “sociales”. Resumen de la ponencia “Overcoming the challenge of Computer Access For the Multiply Disabled Visually Impaired”

También me resultó muy relevante una comparativa entre los lectores de pantalla Hal, JAWS y Window-Eyes con Microsoft Office 2007 por Steve Griffiths y Jonathan Tyrer ambos del RNIB. Los problemas con la cinta de menus demuestra que las mejoras de usabilidad no siempre son ventajosas para todos. Resumen de la ponencia en A comparison of Hal, JAWS and Window-Eyes in Office 2007.

En paralelo tuvo lugar la también interesante Techshare Expo con muestras de numerosos fabricantes de ayudas técnicas.

Estado de avance de la metodología UWEM

2007-10-11T11:30:00.000+02:00

Me han preguntado sobre el progreso con la nueva versión de la metodología UWEM (versión 1.2). UWEM ha sido desarrollado por los proyectos SupportEAM, BenToWeb y EIAO dentro del agrupamiento WAB Cluster. Esta versión como la anterior está basada como no puede ser de otra manera en las Pautas de Accesibilidad de los contenidos de la Web (WCAG) 1.0. A pesar de sus avances WCAG 2.0 sigue lejos de llegar a una versión definitiva.

La nueva (¿definitiva?) versión de de la metodología Unificada de Evaluación de la Web (UWEM) será la UWEM 1.2. Esta versión está todavía en fase de comentarios. Así que animo a todos a repasar el documento y enviar comentarios con el formulario (OpenDocument, Word) previsto. El proyecto BenToWeb está trabajando en una herramienta que permitirá diferentes vistas de los tests y están a la espera de tener esta herramienta para poder publicar la nueva versión. Por el momento no hay plazo fijo para la publicación. El proyecto EIAO (que produce una herramienta automatizada de evaluación masiva) ha pedido una extensión de 5 meses. BenToWeb terminó oficialmente a finales de septiembre pero seguirá contribuyendo hasta la siguiente revisión de seguimiento del proyecto. Después de eso no sabemos qué pasará...

Eclipse creará el Marco para Herramientas para la Accesibilidad

2007-09-18T12:46:00.000+02:00

Poco conocido en el mundo de la accesibilidad, Eclipse es una comunidad cuyos proyectos son de código abierto y enfocados en la creación de una plataforma abierta de desarrollo que consiste en marcos (frameworks) extensibles, herramientas y bibliotecas de código para la construcción, despliegue y gestión de software en todo su ciclo de vida. el componente más conocido es el entorno integrado de desarrollo, pero abarco más de 60 otros proyectos de código abierto.

En los últimos años el panorama de la accesibilidad de las tecnologías de la comunicación y la información ha cambiado mucho. Por ejemplo, para permitir la accesibilidad de las Aplicaciones Enriquecidas en Internet (RIA), el Consorcio World Wide Web (W3C) y su Iniciativa para la Accesibilidad de la Web (WAI) está desarrollando un conjunto de tecnologías Web llamadas Aplicaciones Accesibles Enriquecidas en Internet (ARIA). Para dar soporte a la accesibilidad en documentos “office”, el consorcio OASIS recientemente ha terminado las mejotras de accesibilidad en la versión 1.1 del formato Open Document Format (ODF). IBM ha creado un nuevo interfaz de programación de aplicaciones (API) para la accesibilidad llamado IAccessible2, que está actualmente en proceso de normalización en el grupo de trabajo Free Standards Group Accessibility para permitir a los lectores de pantalla presentar al usuario los contenidos basados en los estándares de accessibilidad para documentos y aplicaciones.

Dentro de la comunidad Eclipse el marco de herramientas para la accesibilidad (Accessibility Tools Framework, ACTF) es un proyecto de código abierto dentro del Proyecto de Tecnología Eclipse. Proporcionará un marco para la creación de nuevas herramientas para la accesibilidad, y para demostrar el concepto incorporará dos herramientas ejemplares, versiones mejoradas de las actualmente disponibles en alphaWorks de IBM: aDesigner y RAVEN. Es importante comprender que son sólo ejemplos, AcTF proporcionará la infraestructura y los servicios para crear nuevas herramientas de desarrollo y evaluación.

Technosite participará en la localización del interfaz y su evaluación en entornos Linux y Windows con usuarios con discapacidad y con lector de pantalla. El proyecto acaba de empezar y está actualmente migrando el código existente al repositorio de Eclipse. Se esperan los primeros resultados a finales del 2007.

Jornadas MWeb'07 en Zaragoza

2007-09-14T10:10:00.000+02:00

Los días 12 y 13 de este mes de septiembre mi colega José Montes y yo hemos asistido en representación de Technosite, a las jornadas MWeb'07 en Zaragoza, sobre la Web móvil. Es parte del Segundo Congreso CEDI, una una semana de veinte y siete jornadas sobre diversos aspectos de las TIC en Zaragoza. Me parece que es una indicación de la madurez del sector de las TIC en España: un congreso importante para informáticos españoles en español. Las sesiones MWeb'07 tuvieron una asistencia de unas 30 a 40 personas, todas, con la excepción del invitado especial Rotan Hanrahan, aparentemente españoles. La ciudad de Zaragoza está actualmente llena de obras para el Expo 2008 sobre Agua y Desarrollo Sostenible y los trabajos alrededor de la estación del AVE.

MyMobileWeb es una aplicación española de código abierto basada en Java para generar de forma dinámica contenidos personalizados para diferentes dispositivos móviles, como canal especial móvil (no con el planteamiento "Web Única"). MyMobileWeb fue el tema de una ponencia presentada por José Manuel Cantera de Telefónica I+D el segundo día. La primera ponencia fue sobre otro proyecto, basado en MyMobileWeb que emplea RDF para permitir la gestión de datos para auto completar formularios Web en móviles, de los autores Fundación CTIC, Telefónica I+D, y la Universidad Politécnica de Madrid, presentada por Diego Berrueta. Rellenar los campos de texto es especialmente penoso para los usuarios de dispositivos móviles con teclados limitados. Se puede proporcionar los datos desde el servidor por el propietario del sitio con lo que ha averiguado sobre el usuario, o en el cliente por el propio usuario.

Nuestro amigo Samuel Martín dio una ponencia sobre los trabajos de su equipo en la Universidad Politécnica de Madrid sobre el desarrollo de metodologías para evaluar la accesibilidad de las aplicaciones Web para móviles.

Se puede usar la monitorización del trafico en el servidor para seleccionar entre distintas estrategias alternativas para adaptar los contenidos para dispositivos móviles diversos y para analizar la calidad de servicio que se les proporciona. Alberto Mijares de Fundación CTIC dio la ponencia.

El Ayuntamiento de Zaragoza ha sido pionero en España en proporcionar una experiencia Web unificada para sus ciudadanos. María Jesús Fernández e Ignacio (“Nacho”) Marín nos describieron la colaboración durante varios años entre sus respectivos organizaciones. Nacho continuó el segundo día, con el planteamiento del Ayuntamiento basado en la propuesta de recomendación del W3C, las Buenas Prácticas para la Web Móvil.

Un equipo de la Universidad de Salamanca ha estado desarrollando una aplicación de servidor con componentes de código abierto y un cliente basado en Java para acceder al sistema de e-Learning ClayNet, que adapta el contenido para el entorno m-Learning para alumnos en desplazamiento. Ha dado la ponencia Miguel Ángel Conde.

Con el tema “Web de escritorio o diseño indpendiente del dispositivo: puntos de partida para la web móvil” terminamos la tarde del primer dóa con una mesa redonda con el antiguo jefe de Technosite, Enrique Varela, ahora consultor independiente y responsable de I+D de Fundación ONCE.

Una serie de aplicaciones móviles usados por la administración pública para llegar a los ciudadanos y los empleados públicos ha sido el tema de una ponencia por Joan Borrás. Muchas de las aplicaciones para el público son (me parece) sistemas "push" basados en mensajería SMS (alertas de niveles de polen, espera de autobús), mientras las que usan tecnologías Web son aplicaciones indpendientes para empleados mas que la Web propiamente dicha.

Telefónica es miembro del consorcio mTLD (.mobi), y Fernando Soriano nos ha dado una charla interesante (e interesada) sobre las bondades del dominio de alto nivel .mobi.

Rotan Hanrahan de la Iniciativa para la Web Móvil dio una conferencia invitada sobre los "Esfuerzos de estandarización alrededor de la Web Ubicua" que me pareció muy clara y fácil de comprender.

El evento terminó el jueves con una mesa redonda sobre "¿Es posible la Web Única?" con María Jesús Fernández del Ayuntamiento de Zaragoza como moderadora, con yo mismo entre los integrantes de la mesa. Se perdió el hilo un poco, hacía por qué la Web Móvil no está teniendo el éxito esperado, y cuando un miembro de la mesa dijo "Levantad las manos los que usáis el móvil para navegar por la Web" hubo una molesta falta de movimiento.

En general las dos jornadas nos han dado una buena impresión de lo que se está haciendo en España en la actualidad. Aunque las grandes empresas con la excepción de Telefónica, se notaban por su ausencia, como patrocinadores y participantes, es evidente que hay numerosos pequeñas y medianas empresas y universidades trabajando en aplicaciones innovadoras, con muchas ya en explotación con éxito.

Inicio de los trabajos sobre accesibilidad y las Buenas Prácticas para la Web Móvil

2007-09-04T09:51:00.000+02:00

Como ya adelanté hace durante el periodo de vacaciones ("La accesibilidad y las buenas prácticas para la Web móvil") el Mobile Web Best Practices Working Group (grupo de trabajo sobre Buenas Prácticas para la Web Móvil) decidió crear un subgrupo para trabajar sobre los aspectos de accesibilidad de citas buenas prácticas.

El alcance del subgrupo es crear un documento que contendrá la correspondencia entre las Pautas Pautas de Accesibilidad al Contenido en la Web 1.0 (WCAG) y las Buenas Prácticas para la Web Móvil (MWBP). Ya existe un borrador público inicial del esquema del documento de correspondencia.

El documento de correspondencia no describirá como hacer los contenidos Web accesibles en dispositivos móviles (para ello deben servir las pautas existentes) y no creará ningún requisito distinto a los definidos en las recomendaciones existentes. Describirá las relaciones, solapamientos y diferencias entre ambas. Para ayudar la comprensión también describe como las barreras experimentados por los usuarios de la Web con discapacidad son similares a los de los usuarios en general en el contexto móvil.

Puede ayudar a comprender los objetivos del documento, los casos de uso definidos por el grupo.

Casos de uso para el documento

Un interesado ha logrado el cumplimiento de una de las recomendaciones y ahora desea cumplir con la otra. El documento debe explicar qué esfuerzo adicional será necesario y como puede aprovechar su inversión existente para cumplir con la otra recomendación de forma eficaz.
Un interesado está confuso o desconoce la relación entre WCAG y las Buenas Prácticas para la Web Móvil; los ve como distintos y disconjuntos, y no se da cuenta de la sinergia y solapamiento entre ambas. El documento debe explicar de qué forma son similares y como se diferencian, y que los procesos de desarrollo y evaluación son similares.
Un proveedor de contenidos cumple con una de las recomendaciones y está consciente de las similitudes con la otra. La organización es consciente que puede mejorar la usabilidad para todos si cumple con los puntos de comprobación de la otra recomendación (cumplimiento parcial) con solo un pequeño esfuerzo, pero necesita saber como hacerlo. El documento debe proporcionar información sobre como cumplir, con un esfuerzo mínimo, los puntos de comprobación o buenas prácticas de la otra recomendación (unión de los dos conjuntos).
Un proveedor de contenidos se ha comprometido a cumplir con una de las recomendaciones y necesita estimar el coste del cumplimiento con la otra, ambas al mismo tiempo. El documento debe clarificar el esfuerzo adicional necesario (la diferencia entre los dos conjuntos).
Un proveedor de contenidos desea cumplir con ambas recomendaciones en el alcance del mismo proyecto, como parte de una estrategia comprensiva de calidad de los contenidos, y desea integrar los requisitos. El documento debe proporcionarle un resumen unificado e integrado de ambas recomendaciones.

Esperamos vuestras sugerencias y comentarios en la lista publica del grupo.

La accesibilidad y las buenas prácticas para la Web móvil

2007-07-20T14:33:00.000+02:00

Este jueves (19 de julio) he dado una charla al Grupo de Trabajo sobre Buenas Prácticas para la Web Móvil del W3C en Londres. La ponencia estaba enfocada en los paralelismos y las sinergias entre las buenas prácticas para la Web Móvil y la accesibilidad para personas con discapacidad. También hablé de los paralelismos entre las necesidades de las personas con discapacidad (con cualquier dispositivo) y las de los usuarios de dispositivos móviles, y expliqué que un conocimiento de una de las Recomendaciones del W3C (WCAG o Mobile Web Best Practices) puede promover la adopción de la otra. Como resultado el grupo de trabajo ha aprobado la creación de un subgrupo para redactar un documento sobre el tema. He publicado las diapositivas de la ponencia (en inglés y de interés para los presentes en la reunión).

¿Segunda vida accesible?

2007-06-24T16:54:00.000+02:00

“Cuando entré por primera vez en Second Life, descubrí que había adquirido otras capacidades. Puedo andar (en el mundo real no puedo); puedo volar; incluso me puedo teletransportar.” Así inició Judy Brewer la reciente charla sobre “Accesibilidad en el entorno tridimensional: Mundos Virtuales y Personas con Discapacidad” en Second Life.

Second Life es un mundo virtual tridimensional construido y mantenido por sus habitantes. Se ha descrito como un “vasto continente digital”, un lugar donde tu “avatar” o personalidad virtual, puede comprar un terreno, construir una casa, encontrar a otras personas, y en general estar allí.

Second Life, o vida secundaria proporciona enormes posibilidades a las personas que en la vida primaria tienen discapacidades. Una persona que no puede salir de casa de repente tiene libre acceso a todo un mundo nuevo. Además, con su propia divisa, el dólar Linden, Second Life (SL) proporciona oportunides reales para ganarse la vida. Los habitantes de SL pueden hacer negocios con la compraventa de terrenos, ropa y accesorios. Puedes fabricar lo que quieras, vender y comprar. Incluso hay un fabricante de sillas de ruedas virtuales. Pero en SL no hay reglamento sobre la construcción, y es más sobre barreras arquitectónicas. Pero tampoco existen las limitaciones físicas del mundo real. No obstante, no todos prefieren abandonar su discapacidad y los últimos avances permiten crear un avatar en silla de ruedas o hasta con andador o bastón. Algunos usuarios prefieren mantener su discapacidad en SL. Es el caso de Simon Stevens que describe su segunda vida en “Virtually the same”. Stevens cuenta como a través del primer club-bar para personas con discapacidad “Wheelies” ha conseguido concienciar a la empresa que gestiona SL sobre la importancia de la discapacidad, además de proporcionar apoyo a otros usuarios discapacitados y ayudarles a “salir del armario” y manifestar su discapacidad en SL.

¿Pero es cierto que todo el mundo tiene acceso a todo ese mundo? SL tiene sitios Web pero su interfaz es un cliente gráfico. Cada vez más las empresas tienen presencia en este mundo virtual, por lo que su accesibilidad es un asunto de gran importancia. Peter Abrahams de Bloor Research escribió en su blog un artículo “Second Life Class Action” sobre la inaccesibilidad del cliente SL y la posibilidad de una protesta masiva que ha provocado un debate (a veces agresivo) sobre la accesibilidad de SL y una serie de propuestas sobre como realizarlo. Los principales problemas que ha identificado son:

Es inaccesible para usuarios de lector de pantalla, porque el cliente no expone la información, incluso la que aparece en forma de texto. SL proporciona una representación puramente visual del terreno, de los avatares cercanos, y cualquier objeto con el cual se puede interactuar. Nada de esta información, ni siquiera las instrucciones, son accesibles con lector de pantalla.
Gran parte de SL es inaccesible con teclado, aunque la última versión (escribía en enero del 2007) tiene mejor soporte para teclado

Desde enero el cliente SL se distribuye bajo licencia GPL (libre distribución y modificación) con lo que la base ya existe. Falta un grupo de programadores dispuestos a emprender la tarea, o de mejorar el cliente existente o iniciar otro nuevo. La otra cara de la moneda de la publicación bajo licencia GPL es que puede permitir a la empresa eludir la responsabilidad con la respuesta “hagalo usted mismo”. Las mejoras que propone Abrahams, especialmente los últimos de la lista que sigue, nos ayudan a comprender mejor las posibilidades y las barreras para las personas discapacitadas en un mundo virtual tridimensional. Son:

Incluir una sección sobre la accesibilidad en Ayuda
Permitir el acceso a las pantallas de ayuda sin ratón
Permitir aumentar el tamaño de texto en la Ayuda
Permitir modificar el tamaño y colores del texto en todo SL
Permitir asignar números a los objetos, para poder seleccionarlos por voz en vez de con el ratón
Lectura hablada de texto en estéreo para permitir al usuario averiguar la ubicación de cada avatar (personaje en pantalla), y la posibilidad de asignar a cada uno una voz característica.
Proporcionar una lista en forma de texto de los avatares en las inmediaciones, y anuncios por voz de sus entradas y salidas.
Simulación del bastón blanco.

Ya existe un mundo virtual 3‑D con cliente accesible con interfaz a la vez visual y sonora que implementa estas ideas, Terraformas.

Según informa Scarlett Qi en “Experts debate how accessible virtual worlds are to the disabled”, una conferencia reciente patrocinada por la Oficina para Programas de Información Internacional del Departamento de Estado de EEUU y la Escuela Annenberg de Comunicación de la Universidad de California del Sur, trató el tema de la accesibilidad de Second Life. Presidían Judy Brewer, la directora de la Iniciativa para la Accesibilidad de la Web (WAI) del Consorcio World Wide Web (W3C) y Bruce Bailey de la Access Board (comité gubernamental sobre accesibilidad). Unos treinta invitados escucharon y participaron en la ronda de preguntas.

Fue evidente el esfuerzo realizado para hacer la conferencia accesible dentro de lo posible para las personas con discapacidad auditiva. Los ponentes hablaron mediante canal de audio, pero con subtitulos. Judy Brewer empezó hablando de la ausencia de restricciones en el mundo virtual para una persona con discapacidad física, y describió las dificultades funcionales que puede experimentar una persona con discapacidad. “Una persona con discapacidad visual puede necesitar una alternativa para el entorno visual de Second Life. Se podría ampliar una zona para hacerla más fácil de visualizar. Un lector en voz alta podría leer el texto escrito en un chat. Si una persona es sorda o dura de oído, se debe proporcionar una alternativa al sonido. Esta alternativa puede ser sonora para un chat de texto incorporada en el programa. Los usuarios con problemas físicos o de destreza necesitan la opción de emplear múltiples pulsaciones de teclas para desplazarse en pantalla como alternativa al ratón. Para los que tienen discapacidad cognitiva o neurológica, es necesario revisar la facilidad de aprendizaje del entorno. Se deben evitar destello en las imágenes porque puede provocar ataques [epilépticos] en algunas personas.”

Bruce Bailey habló sobre el papel de la administración pública: “La administración no debe invertir en cualquier cosa que crea barreras a la participación plena.” En respuesta a una pregunta sobre como los particulares y las islas corporativas podían cumplir con la sección 508, Bailey contestó “No deben usar solo imágenes. Cualquier cosa que se puede ver debe aparecer también como texto.”

Aunque aproximadamente 18% de la población del mundo real tiene alguna discapacidad se desconoce cuantos usuarios de SL tienen problemas de accesibilidad.

Alan (Parsley Pinion en SL)

Fuentes

Los documentos siguientes tienen más información relevante sobre este tema.

“Experts debate how accessible virtual worlds are to the disabled” por Scarlett Qi.
Artículo en el blog del Web Access Centre del RNIB, “Judy Brewer visits Second Life”.
Artículos en el blog de Peter Abrahams, “Second Life open source accessible client” y “Second Life Class Action”
Artículo de blog de Simon Stevens “Virtually the same”.
Sitio Web de Terraformas.

Disponible nueva versión beta de la Barra de Herramientas de Accesibilidad 2.0

2007-06-14T20:18:00.002+02:00

Ya está disponible la última versión beta (de pruebas) para descarga la Barra de Herramientas de Accesibilidad para Internet Explorer. Un conjunto de herramientas imprescindible para evaluar la accesibilidad de los contenidos Web y el cumplimiento de las pautas desarrollado por Steve Faulkner y Jun y sus colaboradores. La versión actual está disponible solo en inglés aunque como hicimos con la anterior Technosite tiene intención de realizar la traducción al español en cuanto esté disponible una versión definitiva. Es importante tener en cuenta que es una versión en pruebas.

Novedades en esta versión

Compatible con Internet Explorer 7 y Windows Vista
Todas las funciones (excepto las de terceros) ya no son externos.
La mayoría de las funciones ya funcionan con JavaScript desactivado
La mayoría de las funciones funcionan en marcos y marcos en línea (donde están presentes)
El validador de HTML comprueba archivos servidor o directorio local

Nuevas funcionalidades

Ventana registro (log): con el recuadro de texto log abierto, los mensajes proporcionados por una función se escriben a esa ventana en vez de a un cuadro de alerta. También el usuario puede escribir texto en el recuadro de texto y guardar el texto en un archivo.
Abrir en Firefox y Opera: botones para abrir la página actual en estos navegadores
Validación HTML rápida: proporciona un resumen de los resultados del validador W3C
Lista de marcos: proporciona acceso a los documentos contenidos en marcos
Resaltado de código fuente generado: vista del código fuente generado con resaltado de los elementos deseados
Resaltado del foco
Evaluador de Accessibilidad Funcional (servicio de la Universidad de Illinois)
Y otras funciones nuevas y mejoras en las de siempre

No olvidemos que también existen versiones definitvas de la Barra de Herramientas para Internet Explorer en español y para la Barra de Herramientas para Opera.

Analizador de Contraste de Color para WCAG 2.0

2007-06-11T22:07:00.000+02:00

Me he enterrado que desde hace un mes el equipo de Jun y Steve Faulkner han creado una nueva versión de esta herramienta que tanto nos ayuda. En las Pautas de Accesibilidad de los Contendidos Web 2.0 en el borrador de mayo del 2007 se introduce, entre otras novedades para el contraste de colores, un nuevo algoritmo para el cálculo. Esta versión implementa el nuevo algoritmo. La versión 1.0 no incluye algoritmo de cálculo sino que usamos el que encontramos en las pautas para de accesibilidad para agentes de usuario, que fue solo una sugerencia. entonces entiendo que podemos usar el algoritmo de WCAG 2.0.

La nueva versión de las pautas introduce otros cambios importantes, entre los cuales equiparar texto con imágenes de texto, pero con un ratio de contraste mayor en el nivel triple A. El texto pequeño (normal) debe tener mayor ratio de contraste que el texto de tamaño grande. Otra mejora es la incorporación de una simulación de de distintas discapacidades visuales que es muy fácil de usar.

Otra aclaración en WCAG 2.0 que me gusta es "Para caracteres con alias [suavizado de bordes], use el valor de luminosidad relativa que se mide a dos píxeles desde el borde de la letra." Este es el caso más común para imágenes de texto y muchas veces es difícil saber dónde medir el color. Han hecho bien de concretar un poco como se debe medir. Podemos descargar la nueva versión en la página de información sobre el analizador de contraste en el sitio Web del Paciello Group.

Atajos de teclado en documentos Web

2003-10-23T10:37:00.000+02:00

Con HTML el diseñador puede definir teclas de acceso rápido a diferentes elementos de la página. Parece una idea estupenda, pero en la práctica no siempre cumple con su objetivo. Las teclas de acceso rápido pueden mejorar la accesibilidad, pero sólo si sabemos usarlas adecuadamente.

Este artículo explica las teclas de acceso rápido en HTML; porqué parecen una buena idea, y porqué no ayudan tanto como era de esperar. En Technosite ha sido desde hace mucho tiempo causa de confusión, por lo que he decidido investigar a fondo el tema. Y no es fácil explicar. Si no tienes tiempo para leerlo todo, puedes saltar directamente a mis recomendaciones o conocer una alternativa.

Introducción

El usuario experto del ordenador conoce un secreto para trabajar con menos esfuerzo: los atajos de teclado. Para copiar un texto no necesita coger el ratón: con un rápido control+C se realiza la misma operación y en un tiempo mucho menor que el usuario novato. No obstante, pocos saben que pueden, o podrían hacer lo mismo para navegar dentro de una página web.

Pero no son sólo los usuarios expertos que sacan provecho de su teclado: hay usuarios que no utilizan el ratón (por ejemplo los que usan ordenador portátil que no dominan el "touchpad") y muchos que no pueden manejar ratón por discapacidad. Los usuarios invidentes no ven el puntero del ratón; tienen que usar el teclado. Y un usuario invidente con lector de pantalla puede trabajar más rápido que uno vidente con ratón.

Pensando en estos dos grupos de usuarios (sobre todo el segundo), el W3C incorporó en HTML la posibilidad de asignar una tecla de acceso rápido a los elementos de la página. HTML 4.01 lo describe así:

Este atributo asigna una tecla de acceso a un elemento. Una tecla de acceso es un carácter único del conjunto de caracteres del documento...
Al pulsar la tecla de acceso asignada a un elemento, el foco se dirige hacia el elemento. La acción que tiene lugar cuando el foco se dirige hacia un elemento depende del elemento. Por ejemplo, cuando un usuario activa un vínculo definido por el elemento <a></a>, el agente de usuario normalmente sigue el vínculo. Cuando un usuario activa un radiobotón, el agente de usuario cambia el valor del radiobotón. Cuando el usuario activa un campo de texto, éste permite la entrada de texto, etc.

El punto 9.5 de las pautas WCAG nos instan a proporciona atajos de teclado:

9.5 Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario.

Aunque sólo es de prioridad 3. Es decir que si no definimos atajos de teclado, esto no significa que el sitio sea inaccesible. Este punto recomienda asignar teclas para los elementos de formulario. En este artículo sólo considero atajos para hipervinculos, aunque los mismos principios son de aplicación para formularios (y creo que un formulario bien diseñado no necesita atajos de teclado.)

El principio es fácil de comprender: el autor de la páginas asigna una tecla a los distintos elementos de la página, por ejemplo el enlace a la página principal en la barra de navegación, o la casilla de búsqueda. Entonces para activar el enlace basta con teclear la letra o el número correspondiente. Parece muy bien, pero la realidad es bien distinta.

Primero repasamos los problemas más importantes que tiene esta forma de acceder a la página, y luego las posibles soluciones.

Si fuera tan sencillo...

Por desgracia, a pesar de su aparente utilidad, pocas páginas definen estos atajos de teclado, y aun menos usuarios saben aprovecharlos. ¿Si la idea es tan buena, por qué no se utilizan más? No comprendemos bien las teclas de acceso rápido, y tienen varios problemas que dificultan su implementación.

El usuario no sabe si están definidos o no

En primer lugar, pocas páginas definen los atajos de teclado. Cuando sí existen, el usuario no se da cuenta. No existe una manera fácil y bien conocida entre los usuarios, para indicar la existencia de teclas rápidas.

Soluciones: Advertir al usuario de la existencia de teclas rápidas

El usuario no sabe qué teclas hemos asignado

Si superamos el primer problema, y el usuario se da cuenta que existen teclas rápidas para la página. ¿Cómo puede saber cúales son? Casi ningun navegador indica la definición de los atajos de teclado (iCab sí lo hace).

El navegador iCab indica la letra de acceso rápido entre parentesis. (Gracias a Charles McathieNevile por la imagen.)

Cada diseñador asigna las teclas a su manera, por lo que el usuario tiene que aprenderlas de nuevo para cada sitio. El usuario no sabe qué elementos tienen una tecla asignada, y no sabe qué teclas el diseñador ha asignado. ¿Qué letras elegimos? Para la página de inicio, por ejemplo: ¿I para Inicio? ¿P para Principal? ¿H para Home? No lo olvides, nuestro propósito es facilitar la navegación, no dificultarla. El usuario se confunda más todavía si asignamos teclas rápidas a muchos enlaces en la página.

Solución: Informar al usuario sobre las teclas definidas

Solución: Sólo asignar teclas a elementos de uso frecuente que ayudarán de verdad

Las teclas causan conflicto con las del navegador

Peor aún, las teclas del documento tienen prioridad sobre las del navegador. Si la página asigna la letra F, el usuario no puede acceder al menu de favoritos con el teclado (si no sabe un truco con la tecla ALT). Si comparamos los distintos navegadores y sus distintas teclas de menú, nos quedamos con un conjunto muy reducido. Si quitamos las teclas empleadas por los navegadores Opera, Netscape y IE en ingles, por ejemplo (en un mensaje al grupo WAI-IG) sólo nos quedan 14 carácteres disponibles ( {cijklopqrsuxyz 0123456789 `-=[]\;',./} de los cuales las letras no son exactamente los más útiles).

Y el problema no termina ahí: Aunque el diseñador elija bien las teclas para no coincidir con las de los navegadores en su idioma, ¿cómo sabe cuáles son las teclas para navegadores en otros idiomas? El idioma del interfaz del navegador no es necesario el mismo de la página. El idioma del usuario no será necesariamente el del navegador: puede ser un castellano hablante en un país con otro idioma o con un navegador nuevo que sólo existe en inglés, por ejemplo. Si el usuario trabaja, por ejemplo, con la versión francesa, alemana o rusa del navegador, este tendrá reservadas otras teclas. Yo mismo soy testigo: uso las versiones inglesas de diferentes navegadores, porque el inglés es mi idioma materno, pero leo todos los días páginas en castellano. Suponemos que el diseñador de la página asigna la tecla T a un elemento, y comprueba que en IE/Windows no está asignado a la barra de menú. Muy bien, pero yo, con mi navegador en inglés, no puedo acceder al menú de herramientas (Tools). Es verdad que existe una manera de superar este problema en IE/Windows. ¿Pero, cuántos usuarios lo conocen? ¿Lo conoces tú? (Respuesta).

Uno de los peores problemas es el conflicto no con los navegadores gráficos, sino con las ayudas técnicas para invidentes, especialmente Homepage Reader de IBM y WindowEyes de GW Micro. Con HomePage Reader la combinación de teclas Alt+L esta reservada para leer en modo sólo enlaces y esta combinación deshabilita la asignación en la página. En España hay pocos usuarios de WindowEyes, pero en otros países sí es muy utilizado. Las pautas de diseño Web del Gobierno de Canadá desaconsejan su uso precisamente por este motivo. Me parece que los atajos de teclado pueden ayudar a los usuarios con discapacidad motriz que trabajan con teclado, a coste de algunos usuarios invidentes que utilizan ciertos navegadores de voz.

Soluciones: Elegir teclas que no causen conflicto con las del navegador

El usuario no puede teclear el caracter

Aunque hablamos de teclas de acceso rápido, lo que definimos es un carácter. Tenemos que pensar en cómo el usuario puede teclear el carácter. El teclado del diseñador de la página no es necesariamente igual al teclado del usuario. La eñe es fácil con el teclado español, pero no para el usuario griego o alemán. ¿Puedes teclear "Œ"?

Bien, tecla rápida, Ñ ¡Vaya! ¿Dónde está la tecla?

Soluciones: Elegir caracteres fáciles de teclear

¿Entonces qué hacer?

Es importante tener en cuenta que para aprovechar los atajos de teclado que hemos definido, primero el usuario tendrá que hacer cierto esfuerzo:

Enterarse de que los hemos definido
Averiguar cuáles son
Aprender y recordar las teclas
Conseguir teclear el carácter correspondiente
Superar los eventuales conflictos entre página y navegador

Tenemos que evaluar la frecuencia de uso de cada elemento al cual pensamos asignar una tecla. ¿Cuántas veces el usuario va a accionar ese elemento? ¿Le compensará aprender la tecla?

Cada uno de estos problemas tiene una solución.

Advertir al usuario de la existencia de teclas rápidas

Problema: El usuario no sabe si están definidos o no

El navegador no informa al usuario que la página define teclas rápidas. Este es, curiosamente, el aspecto más problemático.

Una solución es indicar la tecla junto al enlace o dentro del texto del mismo, o directamente o mediante CSS. Otra es de proporcionar una página sobre la accesibilidad del sitio y esperar que el usuario averigue que en esta página se describen las teclas.

La mejor solución sería mejorar el diseño de los navegadores para que indiquen las teclas, pero es una propuesta a largo plazo.

Recomendación: Crear una página sobre accesibilidad, con la lista de teclas y un enlace en la página principal.

Informar al usuario sobre las teclas definidas

Problema: El usuario no sabe qué teclas hemos asignado.

Existen varias soluciones a este problema, ninguna plenamente satisfactoria.

Solución: Indicar cada tecla en el contenido de la página. Por ejemplo esta página indica el carácter entre parentesis, mediante CSS. Muchos diseñadores no lo harán de esta manera por consideraciones de estética. Y con razón: la mayoría de los usuarios no quieren usar las teclas y no quieren ver esta informacíon. Si esperamos muchos usuarios discapacitados (por ejemplo Discapnet), nos compensa esta solución, sino no es aconsejable.

Solución: Proporcionar una lista de las teclas.

En una página aparte (o en la página sobre accesibilidad) proporcionar una lista de las teclas. La lista debe ser fácil de comprender e imprimir (el usuario visual la puede imprimir para tenerla siempre a mano).

Solución: Sólo asignar teclas a elementos de uso frecuente que ayudarán de verdad

El usuario tiene una memoria finita y en la realidad no aprenderá mas de tres o cuatro.

Solución: Permitir al usuario conocer y recordar las teclas.

Como diseñadores tenemos que calcular si compensa o no al usuario hacer el esfuerzo de averiguar y aprender las teclas rápidas. Muy posiblemente le resultará más cómodo usar la tecla tabulador repetidamente. Si es un sitio de uso frecuente, por ejemplo, una entidad bancaria, probablemente sí, se recompensará el esfuerzo. Si es un sitio particular que el usuario probablemente sólo consulta una vez, no le interesa un acceso de teclado que le costará trabajo aprender, pera sólo utilizar una vez.

En el Reino Unido la administración pública edita una guía para los responsables y diseñadores de los sitios web públicos (Web handbook). Dicen:

"Cuando un usuario visita el sitio web de su departamento por primera vez, éste aporta su experiencia aprendida en otros sitios. Es entonces importante que todos los sitios públicos del Reino Unido adopten un estándar coherente de teclas rápidas. Cualquier desviación de esta norma dificultará la navegación para los usuarios por obligarles a aprender un nuevo conjunto de teclas cada vez."

Si todos los sitios utilizaran las mismas teclas, los usuarios podrían aprender las teclas de memoria. El Web handbook (Reino Unido), en las pautas de diseño sección 2.4.4, define una lista para todos los sitios de los web de la administración.

S - Saltar navegación
1 - Página de incio
2 - Novedades
3 - Mapa del sitio
4 - Búsqueda
5 - Preguntas frecuentes (FAQ)
6 - Ayuda
7 - Reclamaciones
8 - Términos y condiciones
9 - Contactar
0 - Definición de teclas rápidas

La única tecla en la lista que no es numérica es la S. Según mis investigaciones no provoca conflicto con los navegadores comunes en su versión castellana.

¿Si este conjunto de teclas es adecuado para los sitios públicos de un país como el Reino Unido y son independientes del idioma (con excepción de la S, que también vale para "saltar" en castellano) porqué no lo podemos adoptar para los sitios públicos españoles? Insto al Ministerio de Administraciones Públicas a tomar la inivciativa y imponer este conjunto de teclas en los sitios públicos españoles. En la actualidad el sitio del MAP un buen ejemplo de teclas rápidas bien intencionadas pero inservibles (a, b, c, d...).

Recomendación: Adoptar el conjunto de teclas de la lista anterior.

Recomendación: Crear una página sobre accesibilidad, con la lista de teclas y un enlace en la página principal.

Elegir teclas que no causen conflicto con las del navegador

Problema: Las teclas causan conflicto con las del navegador

La realidad es que no podemos saber qué teclas utilizarán los navegadores y las ayudas técnicas, y no es una exageración desaconsejar cualquier asignación de teclas para evitar cualquier conflicto.

Debemos evitar carácteres con acentos u otros que requieren una combinación de teclas en el teclado del usuario esperado.

Los navegadores definen teclas rápidas con letras, por lo que el consenso es que sea mejor emplear las teclas numéricas de cero a nueve. Opera no permite el uso de las teclas numéricas, pero la nevegación con Opera en una página bien diseñada es mucho mas fácil (el usuario puede saltar entre encabezados también), por lo que se puede argumentar que esto no representa un problema importante.

Recomendación: Sólo asignar teclas numéricas

Elegir caracteres fáciles de teclear

Problema: El usuario no puede teclear el carácter

Como he explicado anteriormente si el carácter es difícil o imposible de teclear para el usuario, hemos fracasado en el intento de mejorar la accesibilidad. Recomiendo sólo asignar teclas numéricas, que son comunes a todos los teclados. Entonces la recomendación es la misma:

Recomendación: Sólo asignar teclas numéricas

Recomendaciones

Después de tanta explicación, lo importante es saber como actuar. Los atajos de teclado pueden mejorar la usabilidad y accesibilidad de la página si observamos unas pautas sencillas:

Crear una página sobre accesibilidad, con la lista de teclas y un enlace en la página principal
Adoptar el conjunto de teclas descrito en este documento.

Si por algun motivo no es posible usar este conjunto de teclas, recomiendo lo siguiente:

Elegir caracteres fáciles de teclear y que no causen conflicto con las del navegador
Sólo asignar teclas a elementos de uso frecuente que ayudarán de verdad
Sólo asignar teclas numéricas
Proporcionar una lista de las teclas o una indicación directamente en cada enlace

Una alternativa

Después de explicar todo esto, tengo que decir que existe otra solución para facilitar la navegación entre páginas (aunque no dentro de la página) que resuelve los problemas que he descrito quí. El elemento <link> define la relación entre páginas y deja al navegador la tarea de crear un menu de navegación y un conjunto de teclas de acceso. Espero describir esta técnica en otro artículo futuro.

Adivinanza

Hemos asignado dentro del documento una tecla usada por el navegador para la barra de menú. ¿Cómo puede el usuario acceder al menú con esa tecla? Respuesta: En Windows, para acceder a la barra de menú aun cuando la tecla correspondiente está asignada en la página, tecleas ALT, y sueltas la tecla, para activar la barra de menú. Luego tecleas la letra, sin ALT. Ya lo sabes.

Enlaces externos

Jornadas sobre formación en Palo Alto, California

2003-07-31T16:40:00.000+02:00

En julio del 2003 tuve el placer de participar en Palo Alto, California, en las jornadas sobre la formación en accesibilidad Web organizadas por el grupo WAI-EO del W3C.

Las jornadas de Palo Alto tuvieron lugar los días 16, 17 y 18 de julio 2003. Asistí en representación de Fundosa Teleservicios. Las jornadas fueron organizadas por HP con ayuda de Wells Fargo.

Reunión de trabajo, miércoles

Dedicamos el primer día a una reunión de trabajo del grupo Education and Outreach Working Group (de educación y diseminación). En la sesión de la mañana repasamos la redacción del documento "Building the Case for Web Accessibility Resource Suite".

En la sesión de la tarde tratamos el rediseño del sitio del grupo WAI-EO según los principios de diseño centrado en el usuario, y las pruebas de usuario que se realizarán después. Las carencias en la estructura y diseño del sitio de la WAI son conocidas. La discusión mas importante fue sobre los posibles perfiles de usuarios para las pruebas.

Por la noche los asistentes disfrutamos de una cena en un restaurante japonés invitados por el banco Wells Fargo.

Intercambio de mejores prácticas, jueves

La participación en esta jornada fue restringida a los miembros del grupo WAI-EO y los expertos invitados. Yo tuve la oportunidad de dar una charla sobre los cursos de formación que ha impartido Fundosa Teleservicios dentro de las actividades organizadas por la IWASP. Para los asistentes norteamericanos una de las características mas notables de estos cursos es su duración (cinco días). En Estados Unidos los cursos suelen durar poco, un día o dos. Las diapositivas están disponibles en línea (en inglés).

Intercambio de información, viernes

La última jornada tuvo una participación mas amplia, en el auditorio Spyglass de HP. Presentaciones por Shawn Lawton Henry y por Wendy Chsiholm. Pierre Guillou dio una charla sobre el proyecto europeo EuroAccessibility.

La participación europea estuvo representada por Pierre Guillou de Braillenet (Francia), y Helle Bjarnø (Dinamarca) y por mi, Alan Chuter de Fundosa Teleservicios (España). Durante las jornadas conocí al nuevo miembro del equipo de la WAI, basado en Europa, Shadi Abou-Zahra. Shadi es el coordinador para las actividades de la WAI en Europa

Ocio, fin de semana

Al terminar la jornada del viernes, algunos asistentes nos dirigimos hacía San Francisco. Pasé allí el fin de semana haciendo turismo antes de regresar a España. El sábado hicimos un agradable paseo turístico en coche por la ciudad con Shadi (nuestro conductor), Mimi y Pierre (en la foto).