Más accesible a pesar de Blogger (2)

Este artículo es continuación de Más accesible a pesar de Blogger (1). El objetivo de esta serie de artículos es explicar el proceso que he seguido para intentar hacer más accesible mi bitácora en Blogger, algo que a veces no resulta nada fácil.

Lo cierto es que, aunque en el primer artículo me encontré frustada una y otra vez por los impedimentos a la accesibilidad que Blogger me imponía, esta vez no he tenido tantos problemas (tampoco es que me haya ayudado en mucho).

Como conclusiones de esta revisión voy extrayendo una serie de buenas prácticas a la hora de crear artículos con Blogger, de manera que el resultado sea más accesible, y una serie de tareas programadas que permitan realizar una revisión de los artículos ya publicados mejorando así su accesibilidad.

El proceso que he seguido se puede reproducir en cualquier sitio, no es específico para blogs realizados con Blogger.

Hoy abordo el tema de los atajos de teclado, la página de accesibilidad y personalización y los enlaces, tareas que he realizado en siete días, ordenadas en función del tiempo que he conseguido restarle a mi familia y a Morfeo. Aun habrá más puntos que revisar en futuras entradas.

Día 1: Atajos de teclado

El punto 9.5 de las WCAG (Web Content Accessibility Guidelines) recomienda incluir atajos de teclado para los enlaces importantes.

La Administración Pública del Reino Unido tiene definido un estándar de teclas rápidas en la guía para desarrolladores (Web handbook). Como defiende Accesibilidad Web y Alan en "Atajos de teclado en documentos Web" me ha parecido adecuado seguir esa convención.

Blogger no incluye el atributo accesskey en sus plantillas por defecto ni favorece su inclusión, es necesario ponerlo manualmente en la plantilla.

Para que los usuarios conozcan los atajos de teclado utilizados he realizado dos tareas:

• En el title del enlace he indicado su tecla de acceso rápido.
  
• En la página de accesibilidad he indicado todos los atajos que hay en la página y cómo acceder a ellos en los distintos navegadores.

Por cierto, me encantaría que todos los navegadores implementaran los atajos de teclado como Opera (Mayúsculas+Esc):

 

Día 2: Página "Accesibilidad"

Hoy voy a crear una de página de accesibilidad y personalización. Tal y como propone Emmanuelle Gutiérrez y Restrepo en "Navegación Semántica o Meta Navegación" la incluyo en la navegación semántica de la página mediante rel="personalizar".

En esta página, además de reflejar las intenciones de que el blog sea accesible para todos y las acciones que estoy llevando a cabo para ello, incluyo información importante como es:

• El listado de atajos de teclado y cómo acceder a ellos en los distintos navegadores.
  
• Información sobre cómo modificar el color o el tamaño del texto. Más información en el apartado "Menú superior 'Saltar a'" de "Enlaces más accesibles" de este artículo.

Días 3-7: Enlaces más accesibles

Este apartado aborda el tema fundamental de los enlaces, que son al fin y al cabo la base de nuestras páginas. Hay diversas tareas que se deben realizar para asegurar la accesibilidad de nuestros enlaces, yo las he dividido en cinco días.

Día 3: Enlaces rotos

En primer lugar compruebo que no haya enlaces rotos, puesto que las páginas externas a las que enlazo en los artículos han podido desaparecer.

Existen distintos validadores online: Link Analyser, W3C Link Checker,
links-rotos.com, etc.

El que me parece que da una información más útil es el W3C Link Checker

Una buena práctica es leer siempre un par de veces el artículo antes de publicarlo, revisando todos los enlaces que se incluyen. Añado como tarea programada revisar una vez al mes los enlaces para asegurarme de que ninguno ha dejado de existir.

Sería una buena propuesta para los desarrolladores de Blogger que incluyeran alguna herramienta automática con este propósito.

Día 4: Estilo de los enlaces

El objetivo de hoy es revisar que los enlaces tengan un estilo adecuado para ser reconocidos como tales sin problemas. Por ello los enlaces del blog tienen las siguientes características (1):

• tienen un color diferente al del texto, en este caso azul, puesto que me parece que ayuda a identificarlos claramente como enlaces
  
• el color del enlace tiene suficiente contraste con el color del fondo
  
• están subrayados
  
• los enlaces visitados tienen otro color, algo que es de gran ayuda cuando se busca información en un sitio y que no se respeta en muchos de ellos. He elegido un color morado, como es estándar "de facto", puesto que un problema que me encuentro en algunos sitios es que no se sabe qué color de los enlaces se corresponde con aquellos que ya se han visitado y cuál con los que no.

Día 5: Acceso mediante teclado, orden de tabulación y enlaces "saltar a"

Hoy me toca revisar que los enlaces sean accesibles sin ratón, es decir, utilizando sólo el teclado, y que además lo sean en el orden adecuado.

Una vez hecha esta comprobación decido buscar una solución a lo pesado que resulta navegar con el tabulador por culpa de la gran cantidad de enlaces que tiene la página.

Para ello creo dos nuevos tipos de menú:

Menú superior "Saltar a"

 

Al comienzo de la página, basándome en la solución de la web de la WAI (Web Accessibility Initiative), he incluido un menú con tres opciones:

• "Saltar al contenido", que permite ir directamente al contenido del artículo sin tener que pasar por todos los enlaces de interés de la columna izquierda. Esta opción es mejor que modificar el orden de tabulación lógico mediante el atributo TABINDEX. Por otro lado, ¿por qué ocultar nuestros enlaces de saltar navegación? Estoy de acuerdo con jlvelazquez.net, revindiquemos los enlaces de saltar navegación accesibles para todos los usuarios.
  
• "Ir al menu", que permite saltarse la columna izquierda y el contenido y acceder directamente al menú del blog en la columna derecha.
  
• "Cambiar el color y tamaño del texto", siguiendo de nuevo el ejemplo de la WAI, he decidido incluir este enlace que informa al usuario de cómo puede cambiar en su navegador el tamaño y color de la fuente. Esta alternativa es mucho más adecuada que los típicos iconitos como explica muy bien Juan Carlos García en "Botones para cambiar el tamaño de letra"
  

Enlaces "Saltar a" bajo las columnas de contenido

Siguiendo de nuevo la decisión de no ocultar los enlaces, he incluido debajo de cada columna un enlace visible que permita saltar con fluidez de unas columnas a otras.

Día 6: Texto e idioma de los enlaces. Parámetro "title"

El punto de verificación 13.1 de las WCAG (Web Content Accessibility Guidelines) dice:

13.1 Identifique claramente el objetivo de cada vínculo. [Prioridad 2]

El texto del vínculo tiene que tener significado suficiente cuando sea leído fuera de contexto (por sí mismo o como parte de una secuencia de vínculos). También debe ser conciso.

Por ejemplo, en HTML, escriba "información sobre la versión 4.3" en lugar de "pincha aquí". Además de textos de vínculos claros, los desarrolladores de contenidos deben aclarar el objetivo de un vínculo con un título informativo del mismo (por ejemplo, en HTML, el atributo "title"),


En primer lugar compruebo si el texto de los enlaces es significativo y si es necesario complementarlo con el parámetro title. Textos no significativos serían los típicos "pulse aquí", "comentabamos por aquí", que fuera de contexto no sabríamos a donde enlazan (recordemos que el usuario puede utilizar para navegar el listado de enlaces que le proporciona su agente de usuario: JAWS, Opera, Firefox, etc.)

Por la misma razón es necesario que no haya enlaces con el mismo texto pero que apunten a recursos diferentes, lo cual crearía confusión al usuario, especialmente si los lee fuera de contexto como en el caso anterior.

Como explica Emmanuelle Gutiérrez y Restrepo en Enlaces significativos no basta con añadirles el atributo title, es necesario que su literal sea diferente, pues hay agentes de usuario como JAWS que no muestran el atributo title en la relación de enlaces.

Como colofón de este artículo imprescindible, Emmanuelle concluye:

Los enlaces en una página deben ser concisos, significativos y únicos para cada destino, tal como piden las directrices de accesibilidad. Es decir: no ser demasiado largos, ser claros en cuanto a qué se encontrará el usuario si los selecciona o ejecuta (no ambigüos como el típico: "pincha aquí") lo que ayudará a quienes naveguen por enlaces y a quienes tengan deficiencias cognitivas, y un texto dado que conforme un enlace, si vuelve a aparecer en la página debe apuntar exactamente al mismo recurso.

El atributo title está para transmitir información complementaria sobre a dónde apunta el enlace, pero no tiene como misión especial el diferenciar unos enlaces de otros, pues las características del usuario, del agente que utilice o del contexto de uso, pueden hacer que el valor de dicho atributo no llegue nunca al usuario.

Incluso en el caso de que todos los agentes de usuario habilitaran la navegación secuencial, indicando tanto el contenido como el título del elemento, siempre habrá usuarios que no podrán o no querrán hacer uso de ella y que seguirán necesitando claridad, que los enlaces sean significativos. Por ejemplo, algunas personas con determinados tipos de deficiencia cognitiva. Porque se podría alegar que el contexto sería suficiente para diferenciar enlaces iguales (como en el caso del ejemplo 0) pero la experiencia demuestra que esto no es así para muchos usuarios (personas mayores, personas con deficiencias cognitivas, etc.) y el problema se acentúa cuando la persona se ayuda de un lector de pantalla o navegador parlante, pues ha de escuchar continuamente y tras una pausa un mismo texto repetidas veces.


Hay que tener en cuenta que el usuario puede que no esté leyendo la portada del blog o un artículo concreto, sino que puede estar leyendo todos los artículos de un mes o de una etiqueta, por ello hay que comprobar que en estos casos tampoco haya enlaces con el mismo texto pero diferente ruta.

También hay que tener en cuenta que Opera, al solicitar la vista de enlaces (Control+Alt+L), si hay dos o más enlaces con nombres distintos pero que apuntan al mismo recurso, sólo muestra el primero, por tanto también hay que evitar combinación.

Me encuentro dos problemas en Blogger:

• Cuando se ven varios artículos en una página, si estos tienen el mismo número de comentarios, el literal del enlace a los comentarios será el mismo (por ejemplo "3 comentarios"). Para solucionarlo he incluido a continuación del texto por defecto del enlace (<data:top.commentLabelPlural/>) el texto "en el artículo" seguido del título del artículo (que se inserta con el código <data:post.title/>)
  
• Cuando se visualiza un artículo con comentarios, hay diversos enlaces de una misma papelera "Eliminar comentario" que apuntan a distintas rutas. Me ha sido imposible modificar esto en Blogger. (Nota 16/10/08: obstáculo superado con el código que se explica en los comentarios) Lo mismo me ocurre con los iconos en forma caracteres flecha ▼ del menú "Archivo por fecha"
  

Por último reviso si se identifica correctamente el idioma del texto del enlace mediante el atributo lang y si se identifica claramente el idioma de la página a la que enlaza con el atributo hreflang.

Después de revisar estos puntos en la plantilla los añado como buenas prácticas y los incluyo dentro de las tareas programadas para revisar los artículos del blog.

Blogger no facilita la inclusión del atributo "title" ni advierte de problemas como los de las anclas o títulos repetidos o de enlaces con el mismo texto y ruta diferente o viceversa (que pueden no estarlo cuando creas un artículo concreto y sí estarlo cuando ves un mes o una etiqueta completa). Sería una buena recomendación a los desarrolladores de Blogger que advirtieran automáticamente de ello.

Día 7: Nuevas ventanas

El punto de verificación 10.1 de la pauta 10 de las WCAG (Web Content Accessibility Guidelines) 1.0 nos dice:

10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario. [Prioridad 2]

Por ejemplo, en HTML, evite usar un marco cuyo objetivo es una nueva ventana.

En las WCAG 2.0 podemos leer:

3.2.5 Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)

The intent of this Success Criterion is to encourage design of Web content that gives users full control of changes of context. This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive limitations.

No se debe por tanto utilizar ventanas nuevas, por ello decido eliminar todos los target="blank" que haya incluido a mano en los enlaces (pues no es una opción de Blogger).

Una vez eliminados de la plantilla lo recojo como buena práctica e incluyo en las tareas programadas revisarlo en los artículos ya publicados.

Hay una excepción. Vozme proporciona una versión hablada de los artículos, pero lo hace en ventana nueva. Se advierte de ello al usuario en el atributo "title" del enlace.

Tareas programadas para revisar el blog

Revisar los siguientes puntos en los artículos del blog:

• Revisar que no haya estilos definidos mediante los atributo "style" o "border" fruto de la inserción de imágenes, textos en negrita, etc.
  
• Revisar que las imágenes tenga un atributo "alt" correcto y en su caso un atributo "longdesc" adecuado acompañado de un enlace "D".
  
• Revisar que los cambios de idioma en el texto se especifican mediante el atributo "lang".
  
• Revisar que las abreviaturas y los acrónimos estén definidos (con la etiqueta correcta) al menos la primera vez que se usan, y en este caso que se haya expandido también su significado en el propio texto.
  
• Eliminar los target="_blank" de los enlaces
  
• Verificar que el texto de los enlaces es conciso, significativo (no ambiguo como 'pulse aquí') y único.
  
• Comprobar que se ha añadido el atributo title a los enlaces que necesitan información complementaria para que usuario sepa con qué se encontrará cuando lo pulse.
  
• Comprobar que no hay enlaces con el mismo texto y distinta ruta o con distinto texto pero con la misma ruta, ni siquiera cuando se complementen con el atributo title.
  
• Verificar que se ha incluir el atributo lang en los enlaces cuando el idioma del texto del enlace sea diferente al idioma del documento y el atributo hreflang cuando el idioma del recurso al que enlaza sea diferente al idioma del documento
  
• Comprobar que no hay anclas iguales en distintos artículos, pues al verse en una misma página (por ejemplo si están etiquetados igual) colisionan
  

Revisar una vez al mes:

• Vínculos rotos con W3C Link Checker

Comprobar:

• La adecuación o no de crear CSS específicas para impresión, dispositivos móviles, etc. alojadas en otro servidor.
  

Buenas prácticas para crear artículos accesibles

• Escribir el artículo en modo "Redactar", pasando al modo "Edición de HTML" sólo para incluir etiquetas o atributos no contemplados en el editor.
  
• Validar la sintaxis XHTML al terminar el nuevo artículo.
  
• Si se insertan imágenes eliminar los atributos "border" y "style" que incluye Blogger
  
• No utilizar los botones del editor de Blogger para poner el texto en negrita o itálica, sino incluir las etiquetas adecuadas manualmente.
  
• Añadir a las imágenes un atributo "alt" adecuado y caso de ser necesario un atributo "longdesc" más un enlace "D".
  
• Indicar los cambios de idioma en el texto mediante el atributo "lang".
  
• Etiquetar adecuadamente abreviaturas y acrónimos la primera que aparecen en el texto, expandiendo también su significado en el propio texto.
  
• Leer el artículo varias veces antes de publicarlo comprobando todos sus enlaces.
  
• No utilizar target="_blank" en los enlaces
  
• El texto de los enlaces debe ser conciso, significativo (no ambiguo como 'pulse aquí') y único.
  
• Se debe añadir el atributo title a los enlaces cuando sea necesario añadir información complementaria para que usuario sepa con qué se encontrará cuando lo pulse.
  
• No se deben incluir enlaces con el mismo texto y distinta ruta o con distinto texto pero con la misma ruta, ni siquiera cuando se complementen con el atributo title.
  
• Se debe incluir el atributo lang a los enlaces cuando el idioma del texto del enlace sea diferente al idioma del documento y el atributo hreflang cuando el idioma del recurso al que enlaza sea diferente al idioma del documento
  
• No repetir el título de los artículos, para serie como las de Imprescindibles, Noticias, etc. numerarlas.
  
• Evitar que un artículo se llame como una etiqueta para evitar enlaces iguales con rutas diferentes.
  
• Utilizar siempre anclas con un nombre único e irreptible para que no colisionen con las de otros artículos cuando se visualicen en una misma página. El código único a utilizar será: fecha_nº, por ejemplo, 01_10_08_1
  

Tareas para futuras revisiones

• Estructura interna de las páginas (encabezados, elementos bien utilizados, etc.)
  
• Medidas relativas
  
• Usabilidad

Notas

(1)La única excepción es el título de los artículos (que linca con el enlace permanente de ese artículo) puesto que me parecía que se perdía legibilidad.

Imprescindibles (11)

Estos artículos han llamado mi atención últimamente:

¿DOM (Document Object Model) o innerHTML?

¿Cuál de los dos métodos es más rápido para generar grandes cantidades de contenido?

Podemos ver el resultado de esta pregunta, en función del navegador utilizado, en Benchmark - W3C DOM vs. innerHTML.

Nielsen: sólo el 7% de los usuarios utiliza los sitemaps

Así lo explica Jakob Nielsen en el estudio Site Maps Usability

Baquía nos reseña el estudio:

Según un estudio elaborado por Jakob Nielsen, apenas un 7% de los usuarios recurre a los mapas de una web. Sin embargo, es aconsejable mantenerlos, puesto que suponen una forma fácil y directa de acceder a todo el contenido de una web.

¿Te has preguntado de dónde obtienen sus beneficios las empresas web 2.0?

Web 2.0: ¿Dónde se esconde el negocio? (II)

Fundamentos teóricos de esta profesión

Usándolo nos los va resumiendo en distintos artículos:

• Leyes y principios: Fitts’ Law


• Principios de usabilidad: La regla de los 3 clicks

10 errores principales en el diseño de aplicaciones (Nielsen)

El artículo de Nielsen Top-10 Application-Design Mistakes es resumido y traducido por el blog del grupo SQUaC(Software Quality Usability and Certification).

Estos errores son:

1. Controles GUI (Graphical User Interface) no estándar


2. Inconsistencia


3. No mostrar claramente su funcionamiento


4. Sin retroalimentación


5. "He salido a comer" sin un indicador de progreso


6. Malos mensajes de error


7. Pedir la misma información varias veces


8. Sin valores por defecto


9. Usuarios "lanzados" contra la aplicación


10. No indicar cómo se usará la información


11. Funcionalidades centradas en el sistema


12. Error extra: botones de reset en formularios web

34 buenas prácticas para hacer tus páginas más rápidas

Las best practices for making web pages fast que propone el Yahoo!'s Exceptional Performance son:

1. Make Fewer HTTP Requests


2. Use a Content Delivery Network


3. Add an Expires or a Cache-Control Header


4. Gzip Components


5. Put Stylesheets at the Top


6. Put Scripts at the Bottom


7. Avoid CSS Expressions


8. Make JavaScript and CSS External


9. Reduce DNS Lookups


10. Minify JavaScript and CSS


11. Avoid Redirects


12. Remove Duplicate Scripts


13. Configure ETags


14. Make Ajax Cacheable


15. Flush the Buffer Early


16. Use GET for AJAX Requests


17. Post-load Components


18. Preload Components


19. Reduce the Number of DOM Elements


20. Split Components Across Domains


21. Minimize the Number of iframes


22. No 404s


23. Reduce Cookie Size


24. Use Cookie-free Domains for Components


25. Minimize DOM Access


26. Develop Smart Event Handlers


27. Choose <link> over @import


28. Avoid Filters


29. Optimize Images


30. Optimize CSS Sprites


31. Don't Scale Images in HTML


32. Make favicon.ico Small and Cacheable


33. Keep Components under 25K


34. Pack Components into a Multipart Document

La aventura de crear tu propia empresa

Aunque no tiene que ver con la temática del blog, me ha parecido una bitácora muy original e interesante. Jaime Estévez narra el día a día en la creación de su nueva empresa.

Jaime Estévez. 100 días en la vida de un emprendedor

Noticias (13)

Estas son las noticias que han llamado mi atención durante el mes de septiembre:

Premios TAW (Test de Accesibilidad Web) 2008

Los Premios TAW a la Accesibilidad Web se internacionalizan al abrirse a América Latina
La Fundación CTIC, con la colaboración del Gobierno del Principado de Asturias, convoca la cuarta edición de los Premios TAW a la Accesibilidad Web, dirigidos a todas aquellas personas y entidades, públicas o privadas, que promueven la accesibilidad de los sitios web. El plazo para concursar se extiende hasta el 9 de octubre de 2008 inclusive y, como novedad, este año la convocatoria adquiere carácter internacional al abrirse, en todas sus categorías, a América Latina.

Se pueden proponer candidaturas hasta el 9 de octubre mediante un formulario online.

World Wide Web Foundation

Tim Berners-Lee anuncia la creación de la nueva Fundación para acercar la Web a todo el mundo

Puedes ampliar más información en la web de la fundación.

XHTML(eXtensible Hypertext Markup Language) Basic 1.1 y Mobile Web Best Practices 1.0, recomendaciones del W3C (Consorcio World Wide Web)

Webposible nos informa del cambio de estado de los hasta ahora borradores.

Resultados de la consulta pública para mejorar la accesibilidad de Internet de la Comisión Europea

La Comisión Europea realizó una consulta pública para mejorar la eAccesibilidad como puedes consultar en La Comisión quiere una Internet mejor adaptada a las personas discapacitadas.

El 15% de los europeos sufre alguna forma de discapacidad y muchos sufren dificultades para leer los textos en letra pequeña de los sitios de Internet o hasta para saber cómo acceder a los sitios de Internet y los servicios en línea.

A pesar de los repetidos llamamientos de los jefes de Estado y de Gobierno de la UE para atajar esta situación, los progresos son limitados: con gran diferencia, la mayoría de los sitios de Internet no recurre a soluciones de fácil uso aceptadas universalmente.

La Comisión Europea ha puesto en marcha hoy una consulta pública sobre otras medidas para hacer accesibles los sitios de Internet en Europa, empezando por los de las administraciones públicas, e invita a los interesados a dar su opinión. También aborda otras tecnologías como la televisión digital.

La consulta se cerró el 7 de septiembre. En Public consultation on Web accessibility se pueden leer las propuestas recibidas.

Evolución de la demanda por inaccesibilidad a la web de los almacenes Target

La cadena de almacenes estadounidense Target hará accesible su página web para internautas ciegos, noticia publicada en Discapnet.

La cadena de almacenes estadounidense Target hará accesible su página web para internautas ciegos, en virtud de una sentencia que resuelve la demanda presentada por un grupo de personas con esta discapacidad por la incompatibilidad del portal con los programas lectores de pantalla que utilizan para convertir el texto en audio, según informa la prensa estadounidense.

Target tendrá que introducir explicaciones en audio de las imágenes que utilice en su sitio web, así como garantizar que pueden manejarse todas sus funciones valiéndose sólo del teclado, sin utilizar el ratón.

Más información en:

• Welcome to the NFB Target lawsuit site


• Target Will Ensure That Web Site Remains Accessible to Guests Who Use Assistive Technologies

El iPhone acusado de inaccesibilidad

Apple y Telefónica (de nuevo) acusadas de publicidad engañosa

El organismo regulador ha entendido que la expresión utilizada en el anuncio del nuevo dispositivo móvil de Apple, el Iphone 3G, referente a las capacidades de acceso a Internet conducía a engaño en tanto que en el anuncio se mencionaba expresamente "Todos los rincones de Internet están en el iPhone" sin indicarse ninguna limitación cuando en realidad hay determinadas partes de las páginas web (programadas en java y flash) que no son accesibles a través de los dispositivos comercializados por O2.

También se puede leer la noticia en expansion.com

Google Phone

Es el turno de 'Google Phone'

HTC ha presentado en Nueva York el primer móvil basado en Android, el sistema operativo de código abierto diseñado por Google. El nuevo terminal, llamado HTC Dream se empezará a comercializar junto con el operador T-Mobile el 22 de octubre en Estados Unidos por 179 dólares (123 euros). A principios de noviembre, saldrá al mercado británico, y se irá introduciendo por el resto de Europa a lo largo del próximo año, según ha explicado la compañía.

Web 3.0

El ordenador ya puede comprenderte: reconoce el significado de las palabras

También se puede seguir la noticia en Web 3.0, computadoras ya entienden el significado de las palabras

Web móvil: el 30% de los españoles con teléfono 3G navega en la Red

Localización y servicios contextuales, pilares de la Web móvil/


El móvil, por fin, comienza a desbancar lentamente al ordenador y a la Internet fija para convertirse en la herramienta de socialización del futuro. Lo que toda una industria esperaba, audiencia, masa crítica, se va acercando. En España, el 37% del total de suscriptores móviles mayores de 13 años poseen un terminal 3G, según M:Metrics. Y el 30% lo utiliza para navegar por la Red, descargar juegos y vídeos o chatear con los amigos. La oportunidad aguarda a la vuelta de la esquina y una nube de start-ups en todo el mundo no quiere perdérsela.

Novedades en las WCAG 2.0 (1)

Artículos relacionados
[12-02-08] WCAG 2.0
[12-11-08] Novedades en las WCAG 2.0 (2)

WCAG 2.0 Implementations: Most done, a few to go. Since publishing Web Content Accessibility Guidelines (WCAG) 2.0 as a Candidate Recommendation, the WCAG Working Group has been collecting and evaluating implementations (that is, examples of how real Web sites meet WCAG 2.0). We have implementions for almost all success critieria, and need a few more. For an updated list of implementations needed, see the Update in the WCAG 2 FAQ.

The WCAG Working Group is meeting 1-3 October 2008 to address remaining issues. We are still hoping to complete WCAG 2.0 in 2008, and will provide another status update by November. See How WAI Develops Accessibility Guidelines through the W3C Process for the steps needed to complete WCAG 2.0.

Noticia en la página de la WAI (Web Accessibility Initiative): WCAG 2.0 Implementations: Most done, a few to go

Por lo visto sigue habiendo esperanzas de que el 2008 sea su año.

Artículos relacionados
[12-02-08] WCAG 2.0
[12-11-08] Novedades en las WCAG 2.0 (2)

Más accesible a pesar de Blogger (1)

Artículos relacionados
[15-10-08] Más accesible a pesar de Blogger (2)

Olga y la accesibilidad persiguen a Blogger, pero Blogger corre más deprisa.

Decidí hace unos días que no publicaba ningún artículo más hasta que no hubiera revisado a fondo el blog, tarea que llevo postergando demasiado tiempo.

Este post recoge una crónica resumen de dicha revisión, de mis peleas con Blogger, así como una serie de tareas programadas (que consisten en revisar cada día uno de mis artículos ya publicados chequeando determinados puntos) y unas buenas prácticas que se han de seguir para escribir artículos más accesibles a pesar de Blogger.

Comparto todo ello con vosotros por si a alguien le es de utilidad. El orden de las tareas lo he decidido en función del tiempo libre que disponía cada día, y aunque la revisión podría haber abarcado muchos más puntos (al final del artículo incluyo una lista para futuras revisiones), es todo lo que esta vez ha dado de si mi tiempo.

Os agradecería que me dejarais en los comentarios cualquier propuesta de mejora de diseño, usabilidad o accesibilidad para incorporarlas a futuras revisiones.

ÍNDICE

• Día 1: Revisión del código XHTML (eXtensible Hypertext Markup Language)
  
• Día 2: Revisión de estilos y CSS (Cascading Style Sheets)
• Día 3: Revisión de imágenes
  
• Día 4: Revisión de idioma
  
• Día 5: Revisión de color
  
• Día 6: Revisión automática con TAW (Test de accesibilidad web)
  
• Día 7: Revisión en distintos navegadores, resoluciones y dispositivos
  
• Día 8: Revisión de abreviaturas y acrónimos
  
• Día 9: Revisión de la navegación semántica
  
• Día 10: Revisión de los scripts
  
• Tareas programadas para revisar el blog
  
• Buenas prácticas para crear artículos accesibles
  
• Tareas para futuras revisiones

DÍA 1: Revisión del código XHTML

Hoy he decidido revisar la sintaxis XHTML del blog y para ello voy a utilizar la herramienta del W3C (Consorcio World Wide Web) Markup Validation Service.

Imagino que el blog no va a tener demasiados problemas de este tipo, puesto que Blogger no te permite guardar la plantilla ni publicar los artículos con errores de sintaxis.

Sin embargo mi sorpresa es mayúscula: el validador anuncia más de 300 errores. Horrorizada los agrupo y comienzo a revisarlos.

Identifico tres tipos de errores:

Errores tipo 1: errores en la sintaxis de los comentarios

Por ejemplo que no se ha cerrado alguna etiqueta o que estas se han escrito en mayúsculas. No puedo (ni debo) modificar los comentarios, de modo que me es imposible corregir estos errores. Por supuesto el comentarista no tiene la obligación de saber XHTML, debería ser Blogger el que se preocupara de corregir este tema.

Errores tipo 2: duplicación de etiquetas

Si el artículo lo has creado en modo "Edición de HTML" y se te ha ocurrido incluir elementos "p", Blogger duplica estos elementos al publicar el artículo. Por otra parte, cualquier retorno de carro lo convierte en un elemento "br".

Por tanto añado como buena práctica escribir siempre en modo "Redactar" y no utilizar el modo "Edición de texto" mas que para añadir los elementos o atributos que el editor no permite (abreviaturas, acrónimos, cambios de edioma, etc.)

Errores tipo 3: rutas dinámicas

El resto de los errores se refieren a las rutas dinámicas en los atributos "href" que contienen símbolos &. La solución es sustituirlos por & pero Blogger los vuelve a publicar como &, de modo que, frustada, me he de resignar con la gran cantidad de errores de sintaxis que esto provoca. ¿Alguna idea para solucionarlo?

DÍA 2: Revisión de estilos y CSS

Hoy he decidido centrarme en la revisión de los estilos y las CSS.

En primer lugar elimino cualquier estilo definido directamente en los elementos mediante el atributo "style". En este punto me encuentro con el primer problema: cada imagen insertada por Blogger contiene una serie de estilos definidos directamente en el elemento mediante el atributo "style" y el atributo "border".

Apunto como buena práctica eliminar ambos atributos de todas las imágenes insertadas en los futuros artículos y añado como tarea programada la revisión de este punto en los artículos ya creados.

También es importante señalar que si utilizas los botones de Blogger para poner un texto en negrita o en itálica, te incluye un atributo "style" en vez de la etiqueta adecuada. Por ello añado como buena práctica no utilizar los botones del editor de Blogger sino incluir las etiquetas correspondientes manualmente.

A continuación pruebo que se puede aumentar el tamaño del texto del blog y reviso mediante la Web Accessibility Toolbar de Explorer que el blog es perfectamente legible sin estilos.

Por último compruebo la sintaxis de los estilos con el validador del W3C CSS Validation Service. Encuentro varios errores que puedo corregir, por ejemplo en la plantilla se habían definido atributos no permitidos como "break-word".

Sin embargo me encuentro con dos problemas insalvables:

Problema 1

La página sigue dando bastantes errores de CSS que no puedo corregir. Estos errores se encuentran en unas CSS cuya llamada se inserta dinámicamente en las páginas y a las cuales no tengo acceso.

Problema 2

Blogger no permite recoger los estilos de la plantilla en una CSS sino que los inserta en cada una de las páginas.

Me gustaría tener CSS diferentes para los distintos dispositivos (móviles, TV, impresión, etc.) así que apunto como tarea programada estudiar la creación de las mismas alojándolas en otro servidor.

DÍA 3: Revisión de imágenes

Hoy quiero revisar las imágenes del blog. En primer lugar me aseguro de que las imágenes decorativas estén definidas en la CSS y las imágenes que sean significativas tengan un atributo "alt" o "longdesc" adecuado (1).

Blogger no obliga a incluir un atributo "alt" a las imágenes que se insertan en los artículos, ni tampoco facilita la inclusión del atributo "longdesc", de modo que, aunque soy cuidadosa en este aspecto, incluyo este punto como buena práctica. Para corregir posibles deslices pasados añado una tarea programada para revisar los artículos ya publicados.

A continuación reviso mediante la Web Accessibility Toolbar de Explorer que efectivamente el blog se ve correctamente con la ausencia de imágenes.

DÍA 4: Revisión de idioma

Hoy decido revisar si está correctamente especificado el idioma en el blog. Para ello compruebo que la plantilla tenga indicado el idioma y la codificación correctamente como expliqué en el artículo "Plantilla base XHTML". Aquí encuentro el primer problema, Blogger incluye como primera línea de la plantilla la codificación UTF-8 siendo esta imposible de modificar.

<?xml version="1.0" encoding="UTF-8" ?>

Aunque he tenido cuidado en señalar el cambio de idioma en el texto mediante el atributo "lang", Blogger tampoco facilita esta práctica, así que incluyo este punto como buena práctica y añado como tarea programada revisarlo en los artículos ya publicados.

Por otra parte, Blogger no permite indicar el cambio de idioma en el título o en el etiquetado de los artículos, puesto que pinta el elemento en vez de interpretarlo.

DÍA 5: Revisión de color

Hoy quiero centrarme en comprobar que no haya información basada en el color. Utilizo en primer lugar la herramienta Vischeck que simula la visualización de las páginas por personas con problemas de ceguera cromática.

A continuación, mediante la Web Accessibility Toolbar de Explorer, compruebo que el blog sea legible en escala de grises y reviso el contraste de color. Me veo obligada a cambiar el color de algún texto que no ofrecía suficiente contraste con el fondo.

DÍA 6: Revisión automática con TAW

Hoy me centro en la revisión automática de la accesibilidad con la herramienta TAW. El blog presenta dos errores que no puedo corregir:

Error de prioridad 1

Blogger inserta automáticamente una barra de herramientas en la parte superior de las páginas. Esta zona es un "iframe" que no presenta texto alternativo en el cuerpo del elemento.

 

Como no puedo acceder al cuerpo del "iframe" me tengo que conformar con incluir un elemento "noframes".

Error de prioridad 2

El problema se encuentra de nuevo en este "iframe". El validador detecta que utiliza unidades de medida absolutas en lugar de unidades de medida relativas.

Me siento bastante frustrada de no poder corregir estos errores, ¿alguna idea? ¿escribir a los desarrolladores de Blogger?

DÍA 7: Revisión en distintos navegadores, resoluciones y dispositivos

El 99% de las visitas que recibo son mediante cinco navegadores (en este orden): Firefox, Internet Explorer, Chrome, Safari y Opera; y con tres sistemas operativos: MAC, Linux y Windows.

Compruebo en primer lugar que no tengo problemas para visualizar el blog en ninguno de estos navegadores y sistemas operativos.

Después reviso su visualización en dispositivos móviles, para ello utilizo diferentes emuladores (ver Mis validadores)

A continuación lo reviso en un navegador sólo texto como Lynx.

Como la página es muy extensa, para mejorar la navegación incluyo tres enlaces: "Ir al contenido", "Ir a enlaces de interés" e "Ir al menú", que permiten saltar a determinados contenidos con agilidad.

También compruebo que el contenido es accesible con distintas resoluciones. Por último reviso la impresión de las páginas. Estas se imprimen correctamente con Explorer, Opera y Chrome, sin embargo no se imprime bien desde Firefox.

Me gustaría crear un CSS especial para la impresión, que permitiera además aprovechar mejor el papel imprimiendo sólo el contenido del artículo, sin embargo Blogger no permite subir ficheros CSS, así que apunto como tarea programada estudiar la creación de dicha CSS alojándola en otro servidor.

DÍA 8: Revisión de abreviaturas y acrónimos

El tema de las abreviaturas y acrónimos es un tanto peliagudo, más aun si no se tiene claro qué es una abreviatura y qué es un acrónimo y encima se leen los ejemplos erróneos que aparecen en las Técnicas de HTML para las Pautas de Accesibilidad del Contenido Web 1.0 o en la especificación de HTML 4.01.

Para aclarar este tema no hay mejor referencia que el artículo de SIDAR "Abreviaturas versus Acrónimos". En él, además de aclarar la diferencia entre abreviatura y acrónimo y por tanto cuándo se debe utilizar el elemento "abbr" y cuando el elemento "acronym" (2), se especifica que:

• Las abreviaturas y los acrónimos deben marcarse con su etiqueta correspondiente al menos la primera vez que se usan en el texto. La primera vez que se usan también debe expandirse su significado en el propio texto. Por ejemplo, "La ONU (Organización de Naciones Unidas) ha decidido...".
• Deben marcarse siempre las abreviaturas en las cabeceras de las tablas.
  
• Es una práctica recomendable recoger en una lista, en página aparte o en la misma, todas las abreviaturas y acrónimos para que el lector pueda acudir a ella en caso de duda.

Por otro lado hay que añadir que las abreviaturas de uso común, recogidas en el diccionario de la Real Academia de la Lengua, no requieren ser marcadas, puesto que los lectores de pantalla deberían incluirlas (y suelen hacerlo) en sus diccionarios.

Como no estoy segura de lo rigurosa que he sido en la aplicación de estas normas, decido añadirlas como buenas prácticas en la preparación de post futuros y como tarea programada que me permita revisarlo en los artículos pasado.

Por último, Blogger no permite indicar acrónimos o abreviaturas en el título o en el etiquetado de los artículos, puesto que pinta el elemento en vez de interpretarlo.

DÍA 9: Revisión de la navegación semántica

La plantilla no contiene ningún vínculo definido que permita la navegación semántica, tal y como recomienda el punto de verificación 13.2 de las WCAG 1.0 (Web Content Accessibility Guidelines).

En Plantilla base XHTML explico en detalle cómo y para qué agregar esta información a las páginas.

 

Como se ve en la imagen, la barra de navegación semántica de Explorer tiene ahora los botones activos. Me hubiera gustado también añadir los vínculos al "artículo anterior" y al "artículo siguiente" pero no he encontrado en Blogger la etiqueta que permita añadir esta ruta automática a la plantilla, ¿alguna idea?.

DÍA 10: Revisión de scripts

Un 6% de los navegadores con los que me visitan no son compatibles con javascript o no lo tienen habilitado, por ello hoy he decidido desactivar los scripts (en las preferencias del navegador) para revisar si se puede interactuar correctamente con el blog.

Compruebo que la búsqueda en el blog funciona y que la agenda sigue siendo accesible.

Como se aprecia en la imagen, aparece un mensaje advirtiendo de que se puede consultar la agenda en formato texto pulsando un enlace. La agenda es un "iframe" a cuyo contenido no tengo acceso, por tanto no puedo modificar el mensaje que aparece. Hubiera deseado mejorar la redacción del mismo y que el texto del enlace fuera diferente a la ruta.

Al final he decidido incluir un enlace siempre visible (señalado en la imagen con una flecha) a la versión texto de la agenda, de este modo, los usuarios que por ejemplo no pueden visualizar los "iframes", o que a pesar de tener activo el javascript utilicen tecnologías asistivas que le impidan acceder al contenido de la agenda, no tengan problemas en consultarla.

Por otro lado, todos los artículos tenían al final una opción "escuchar este post". Este enlace fallaba cuando los artículos eran demasiado extensos (lo cual es muy habitual en mí) de modo que lo he cambiado por "escucha el texto seleccionado". Estas funcionalidades las proporciona vozme.com mediante un "script" que hay que incluir en la plantilla. Este script no tiene una alternativa accesible, de modo que no me ha quedado más alternativa que advertir de esta circunstancia en el elemento "noscript".

Al final de cada artículo hay también una serie de iconos que permiten añadir el artículo a Digg, Technorati, etc.

 

La única manera de incluir en sus enlaces la dirección dinámica del artículo fue mediante javascript, de modo que añado un elemento "noscript" con dichas direcciones para que sean accesibles sin el javascript activo.

Por último me doy cuenta de que no aparece el icono de las estadísticas, puesto que el "script" que proporciona StatCounter pinta la imagen. Como las estadísticas son de carácter privado y por tanto su ausencia no resta funcionalidad a la página, no le doy mayor importancia. Tampoco aparece el tooltip de Coloriuris, pero como la información de esa ventanita está disponible en la página a la que enlaza el icono, la ausencia de esta ventana no resta accesibilidad a la página.

Tareas programadas para revisar el blog

Revisar los siguientes puntos en los artículos del blog:

• Revisar que no haya estilos definidos mediante los atributo "style" o "border" fruto de la inserción de imágenes, textos en negrita, etc.
• Revisar que las imágenes tenga un atributo "alt" correcto y en su caso un atributo "longdesc" adecuado acompañado de un enlace "D".
• Revisar que los cambios de idioma en el texto se especifican mediante el atributo "lang".
• Revisar que las abreviaturas y los acrónimos estén definidos (con la etiqueta correcta) al menos la primera vez que se usan, y en este caso que se haya expandido también su significado en el propio texto.

Estudiar la adecuación o no de crear CSS específicas para impresión, dispositivos móviles o TV alojadas en otro servidor.

Buenas prácticas para crear artículos accesibles

• Escribir el artículo en modo "Redactar", pasando al modo "Edición de HTML" sólo para incluir etiquetas o atributos no contemplados en el editor.
• Validar la sintaxis XHTML al terminar el nuevo artículo.
  
• Si se insertan imágenes eliminar los atributos "border" y "style" que incluye Blogger
• No utilizar los botones del editor de Blogger para poner el texto en negrita o itálica, sino incluir las etiquetas adecuadas manualmente.
  
• Añadir a las imágenes un atributo "alt" adecuado y caso de ser necesario un atributo "longdesc" más un enlace "D".
  
• Indicar los cambios de idioma en el texto mediante el atributo "lang".
  
• Etiquetar adecuadamente abreviaturas y acrónimos la primera que aparecen en el texto, expandiendo también su significado en el propio texto.
  

Tareas para futuras revisiones

• Atajos de teclado
• Estructura interna de las páginas (encabezados, elementos bien utilizados, etc.)
• Medidas relativas
• Enlaces (enlaces rotos, nuevas ventanas, "title", orden de tabulación, revisar enlaces con el mismo literal, colores de los enlaces, acceso mediante ratón, enlaces tipo "pulsar aquí, comentamos por aquí", etc.)
  

NOTAS

(1) Como por ejemplo en la imagen del artículo "Disciplinas relacionadas con la Usabilidad", que tiene atributo "alt", "longdesc" y un enlace "D".

(2) El truco para saber si la forma abreviada que vamos a utilizar es una abreviatura o es un acrónimo está en ver si la traducimos, si va terminada en punto o si conserva la tilde (en cuyo caso será una abreviatura como por ejemplo: Sr., págs.) o si por el contrario la leemos tal cual está escrita, no va terminada en punto ni conservan la tilde (en cuyo caso es un acrónimos como W3C, XHTML)

Artículos relacionados
[15-10-08] Más accesible a pesar de Blogger (2)