Libro: Towards an Inclusive Future

Vía accessify, en su artículo Mobile access – the next big accessibility barrier?. Me encuentro a un recurso bastante interesante, concretamente un libro, Towards an Inclusive Future. Impact and wider potential of information and communication technologies (podemos traducir por Hacia un futuro inclusivo. Impacto y amplio potencial de las tecnologías de información y de comunicación). En sus más de 300 páginas en inglés, podemos encontrar un gran número de casos prácticos, donde las nuevas tecnologías han ayudado a las personas con discapacidad.
El libro lo podemos descargar libremente ya sea entero en un PDF (3,6 megas), o en sus diferentes capítulos en formato HTML ó PDF. ¿Dónde? en Towards an Inclusive Future. Aunque no tengas tiempo o ganas para leerte el libro, te recomiendo que te lo descargues y le des un vistazo. Te va a sorprender positivamente.

Prototipos en papel

Me confieso: mis conocimientos sobre prototipos de páginas web en papel es muy escaso (¡miento, es nulo!). Si te da vergüenza reconocer que más o menos sabes lo mismo que yo, puedes leer el artículo Paper Prototyping publicado en A list apart por Shawn Medero. En el artículo puedes ver porqué es útil e importante, además de cómo hacer pruebas de usuarios con este tipo de prototipos. También es interesante dar un vistazo a Paper Prototyping, una página web del libro homónimo, con interesantes recursos.

Consejos prácticos de accesibilidad web

Uno de esos artículos que me gustaría escribir pero nunca empiezo, ya sea por falta de tiempo, de una correcta planificación de la estructura y el contenido, o porque existen artículos fantásticos en internet, es uno sobre accesibilidad web. Mi idea se basa en un texto que parte desde un punto de vista práctico, empleando las pautas, pero sin ser una lista. El problema es que ya hay mucho escrito y muy bueno. Aquí os dejo un ejemplo extraído en origen del siguiente artículo: Practical, Entry-Level Web Accessibility de Mike Cherim, aunque ya no está disponible. Practical, Entry-Level Web Accessibility, de Mike Cherim

Es un artículo bastante completo, y os recomiendo su lectura. pero me gustaría destacar el apartado del uso apropiado de los vínculos. Sus consejos son los siguientes (no se trata de una traducción literal, e incluyo opiniones y explicaciones mías):

  • No usar el mismo texto para vínculos que tienen diferentes destinos (del tipo leer más, más información,…). ¿Motivos? Existen navegadores que muestran un listado con todos los vínculos de una página. ¿Tiene sentido que nos encontremos con diez vínculos con el mismo texto y diferentes destinos? Evidentemente no. Y en el punto siguiente hay más que añadir.
  • Usar un texto para el vínculo que sea descriptivo con su destino. Los vínculos suelen ser “focos de atención”, y en el caso de que no se haga una lectura completa, puede que al ojear uno de ellos nos llame la atención, pero no sepamos a donde nos lleva. Esto nos obliga a leer el contexto para ver de qué se trata. El tan mencionado “no uses haga click aquí” que aparece en las pautas de accesibilidad web es por algo. Suele ser una costumbre en los bloggers el usar en una frase (como por ejemplo: “como ya han dicho otros”), un vínculo para cada palabra. Esos textos de vínculos “como”, “ya”, “han”, “dicho” y “otros”, leídos de forma individual no nos dice nada sobre su destino. Sí podemos usar la barra de estado para ver su destino, pero no es correcto (aunque a veces queda muy gracioso, je je 🙂 )
  • Separa los vínculos para que no aparezcan de forma consecutiva. ¿Por qué? Porque a veces cuesta distinguir donde empieza un vínculo y donde termina otro. En el caso de que incluyas varios vínculos en una frase, intenta redactarla de forma que haya separación entre los vínculos, ya sea una coma, o alguna palabra. En el caso concreto de los menús horizontales (ya sea utilizando listas o como una serie de vínculos separados por más o menos espacios), conviene también utilizar al menos un carácter imprimible de separación. El problema es cuál utilizar… símbolos como “|”, “·”, “#”, podrían ser válidos, pero al usar un lector de pantalla puede resultar bastante molesto. Pero utilizando estilos, podemos indicar que no los oculte a los lectores de pantalla (luego falta que hagan caso, y aquí hay un problema).
  • Identifica los vínculos, para distinguirlos adecuadamente. No tiene porqué ser el subrayado azul por defecto, pero no es mala idea subrayarlos (sólo los vínculos) y/o utilizar un color distinto (atención a los problemas que puedan tener las personas con daltonismo).
  • Por último también recomiendan un cambio en el aspecto del vínculo cuando tiene el foco (ya sea con el tabulador, o al pasar el ratón por encima). Nada mejor que usar las pseudo-clases active y hover para cambiar el color, el fondo, el subrayado…

Mucho más, y sobre todo mucho mejor, estaba disponible en Practical, Entry-Level Web Accessibility. Practical, Entry-Level Web Accessibility.

Lo que está pasando con la futura versión de HTML

Antecedentes: El 27 de Octubre del año 2006, Tim Bernes-Lee, director del W3C, escribe el artículo Reinventing HTML. El título de lo que escribí por aquel entonces W3C desarrollará de forma paralela HTML: HTML 4.x, XHTML 2… es bastante explicito con los planes del W3C en el futuro (si quieres, te lo puedes leer 🙂 ). Además, había una crítica implícita al éxito de XHTML e incluso a la forma de trabajar del W3C.
Esta noticia, desde mi punto de vista con una gran trascendencia, generó bastantes artículos en muchos e importantes blogs de gente muy respetada en este mundillo, yo destaco el que publicó A list apart titulado Have Your Say about the Future of HTML (y si quieres, puedes leer su traducción, publicada aquí mismo: Qué dirías acerca del Futuro de HTML), y aquí aparece en escena un “actor” importante de esta “película”: WHATWG, una especie de “consorcio” paralelo del que forman parte Mozilla, Opera y Apple (es decir, los navegadores Firefox, Seamonkey, Camino,… Opera y Safari) y cuyo objetivo es desarrollar aplicaciones webs más sencillas usando las actuales tecnologías. Su trabajo actual es Web Applications 1.0, también conocido por HTML5 ó XHTML5.

¿Y ahora, en qué punto está el W3C? Buena pregunta. No esperes aquí una respuesta clara, tan sólo algunas interesantes referencias a artículos publicados en 456 Berea Street (¡imprescindible subscribirte!).

Comenzamos con Elements and Attributes in HTML 5, una lista de algunas etiquetas nuevas que aparecen en la especificación de HTML5 (recuerda, es del WHATWG, no del W3C). Algunas las veo muy útiles desde el punto de vista semántico (footer, header, nav) y no olvides consultar un listado completo de las etiquetas en HTML5 Elements and Attributes (ojo, tiene frames).

Segunda referencia, New W3C HTML Working Group chaired by Microsoft, y es que Chris Wilson, como bien confirma el mismo en su artículo You, me and the W3C (aka Reinventing HTML), va a ser el responsable del grupo de trabajo de HTML. Y aquí empiezan los comentarios, porque mucha gente considera que en ese cargo no debería estar nadie relacionado directamente con alguna compañía que desarrolla navegadores (leed el artículo Daniel Glazman Future of the HTML WG). El motivo es obvio, independencia, y más en un grupo, que posiblemente sea el más importante del W3C. Nadie quiere que un representante de cualquier navegador (en este caso Internet Explorer), imponga su criterio al grupo de trabajo (ojo, no estoy diciendo que vaya a ocurrir, sino un extremo que nadie desea). Pero Roger Johansson, autor de 456 Berea Street también apunta otro punto de vista: ¿y si Chris Wilson acerca a Microsoft a los estándares? Y la verdad, sería bastante bueno, pero uno no tiene demasiada fe dado el conocimiento que tiene el presidente de esa compañía, Microsoft, sobre los estándares web: Bill Gates on Web standards: Huh? que nos conduce a un artículo de Molly E. Holzschlag (que por cierto, estuvo hace poco en Gijón), titulado Who Questions Bill Gates’ Commitment to Web Standards?. Ahora en serio, no se debe juzgar el trabajo de Chris Wilson, porque todavía no ha podido hacer demasiado. Desde aquí le deseo lo mejor, para él y para todos los implicados en el futuro de HTML. Pero retrocedamos al principio de este párrafo: el mismo, Chris Wilson, se ha encargado de responder a Daniel Glazman (sí, el mismo que ha escrito el artículo Future of the HTML WG que he mencionado antes) en su artículo Sigh. Hay que leerlo.
Y terminamos con el último vínculo a 456 Berea Street: Apple’s Safari team comments on the new W3C HTML WG charter, que nos lleva directamente al artículo de Surfin’ Safari titulado… (música tétrica de mucho miedo y apocalíptica): HTML Standards Process Returning from the Grave. Donde denuncia que en la práctica, sólo valen las decisiones de los representantes de aquellos navegadores que tengan al menos el 10% de cuota… es decir Explorer y Firefox. ¿Qué pasa con Opera? ¿Y Safari? ¿Y cualquier particular u organismo que quiera participar? Por eso, desde Safari proponen cambios, como por ejemplo una colaboración del HTML Working Group con otros grupos externos, como WHATWG o la comunidad de desarrolladores.

Pero no es el único comentario que hacen. Consideran que la dirección actual del grupo de trabajo de HTML es buena, pero también realizaron una serie de sugerencias para resolver algunos problemas. Normalmente este tipo de comentarios se suelen hacer en privado con el W3C, pero ellos lo han publicado en el artículo antes mencionado: HTML Standards Process Returning from the Grave. No quiero hacer un resumen y olvidar involuntariamente algo importante.

Para terminar… no se muy bien como explicar las sensaciones que tengo, pero aquí dejo algunos pensamientos:

  • No me gusta una evolución paralela de XHTML y HTML, desde mi punto de vista lo lógico sería seguir la dirección XHTML 2, pero si es demasiado complejo…
  • Creo necesaria una evolución y en WHATWG he visto buenas ideas.
  • Parece que la forma de trabajar de los grupos de trabajo del consorcio, no es tan abierta como a muchos les gustaría, hay gente muy válida y con muy buenas ideas: espero que de una u otra manera las puertas del W3C estén abiertas y que sean receptivos.

De todas formas, con el tiempo iremos viendo cómo va todo. En principio las labores del grupo de trabajo de HTML (HTML Working Group Charter) terminarán el 31 de Diciembre del año 2010 (aunque ya sabemos que pasa con las fecha previstas en cualquier proyecto). Por otro lado, las tareas del grupo de trabajo de XHTML2 (XHTML2 Working Group Charter), terminarán el 31 de Diciembre del 2009.

Postdata: Lo que podría escribir Enrique Dans con todo este material 🙂

Wikipedia y Web Semántica (dbpedia). Flickr y machine tag

dbpedia

Me siento cohibido al escribir de algo que ya ha hecho anteriormente Manu: (pseudo)RDF en Flickr / RDF Powa!. Pero por si acaso algún lector de esta bitácora no lee simplelógica (que por supuesto, es imposible, por mucho que en artículo anterior tenga una prueba, falsa evidentemente) y por algún oscuro motivo no se ha enterado (por ejemplo lee sus feeds en orden alfabético inverso), hago referencia a un par de artículos que he leído en Planet RDF (por cierto, dentro de poco puede haber una entrada en castellano y estoy deseando leerla). Son los siguientes:

De la Wikipedia y la Web Semántica, ya hable hace muuucho tiempo en años-webposible (¿Y si la wikipedia fuese también una herramienta colaborativa para crear ontologías?), pero lo que he visto en el proyecto dbpedia, me ha sorprendido muchísimo. En pocas palabras, se trata de extraer información estructurada de la Wikipedia, para ponerla a disposición de la Web Semántica.

Para ello, podemos generar:

Para mí esto tiene unas posibilidades tremendas y bajo mi punto de vista (y mis nulos conocimientos de Web Semántica), ha conseguido algo importantísimo, como es ofrecer en un lenguaje comprensible para las máquinas, toda una enciclopedia con un increíble número de artículos, escritos por seres humanos.

¿Quieres ejemplos? Aparte del que indica Manu, puedes encontrar unas cuantas consultas complejas usando información de Leipzig Dataset. ¡No olvides este vínculo jamás!

Machine tag de flickr

Por otro lado, hablamos de una interesante funcionalidad para, probablemente, la mayor colección de imágenes de la Web (sí es flickr). Esta nueva característica, se llama “machine tag“, una forma más precisa de etiquetar las fotos (y por tanto, también de encontrarlas). Para ello las etiquetas serían del tipo namespace:predicado=valor. Por ejemplo, si utilizamos Dublin Core, podría ser dc:creator:fotoposible. Otros namespaces que se mencionan en la presentación, son: flickr, flora, medium, geo (éste ya funciona) y Dublin Core.

De momento, en los ejemplos que utilizan, sólo he podido comprobar que funciona flickr:?username=naturales71 (supongo que hará falta la API de la que habla Manu).

Por cierto, la información más completa, la puedes encontrar en Flickr API / Discuss: Machine tags.