Usable y accesible

Herramienta de ayuda para realizar una consultoría de accesibilidad web

2012-01-25T14:04:00.002+01:00

Servicio relacionado: Consultoría de accesibilidad web

Comparto con vosotros una herramienta personal que he creado para ayudar a realizar el informe resultante de una consultoría de accesibilidad web. Al final del artículo tenéis la descarga.

Consultar otros materiales de apoyo en la zona de descargas

Qué es y qué no es

NO es una herramienta para realizar una revisión automática de la accesibilidad web de un portal.

Es una herramienta que permite ir recogiendo los datos obtenidos durante la revisión automática y manual del sitio de acuerdo a la Norme UNE 139803, que es un poco más exigente que las WCAG 1.0 (ver diferencia entre las WCAG 1.0 y la Norma UNE 139803), y que te genera información de utilidad para realizar el informe.

Cuando redactas el informe que refleja los resultados de la consultoría hay dos apartados claves:

el análisis detallado donde incluyes por cada punto de verificación y página de la muestra qué se pretende evaluar y cómo se ha evaluado, qué errores se han cometido, cómo solucionarlos técnicamente y cómo evitarlos en el resto del portal. Este apartado debe estar orientado a los desarrolladores que van a realizar los cambios.
el resumen de la evaluación, que está destinado a las personas que han contratado la consultoría y que no tienen por qué tener conocimientos técnicos. En este resumen se indica de manera concisa y clara, sin entrar en aspectos técnicos, cuáles son los principales problemas en base a su criticidad y recurrencia, el nivel de adecuación alcanzado por la muestra y por cada una de sus páginas, etc.

Los datos que genera la herramienta que comparto son especialmente útiles para ese resumen de la evaluación. Genera un resumen del nivel de adecuación A y AA (tanto de la muestra en general como de cada una de sus páginas) datos estadísticos y gráficas que permiten resumir y presentar de forma concisa y muy gráfica los resultados. También nos ayuda a nosotros a identificar con rapidez cuáles son los puntos de verificación y las páginas que presentan más problemas.

Descripción de la herramienta

Está en formato Excel. Todos los campos están protegidos salvo aquellos que se deben ir rellenando. Es una herramienta de uso personal que he decidido compartir, así que su funcionamiento y organización están basados en mi manera habitual de trabajar.

La Excel está dividida en cuatro pestañas:

Pestaña 1: General

En esta pestaña se rellenan los datos generales sobre la web a analizar:

Fecha: rango de fechas entre las que se realiza la evaluación
Web: URL de la web que se analiza
Cliente: cliente para el que se realiza la consultoría
Evaluador: persona que lleva a cabo la evaluación
Nº de páginas de la muestra: nº de páginas que componen la muestra a evaluar. Está pensada para un máximo de 15.
Datos de las páginas de la muestra: alias por el cual haremos referencia a esa página y su URL. El alias que demos a cada página de la muestra será el que automáticamente se adjudique en el resto de la Excel para identificar a esa página.

Pestaña 2: A

La labor que debe hacer el evaluador en esta pestaña es indicar por cada una de las páginas de la muestra y por cada uno de los puntos de verificación de nivel A si dicha página cumple, no cumple o no se aplica el correspondiente punto de verificación que está analizando.

Por tanto por cada punto de verificación de nivel A y cada página de la muestra encontramos las siguientes columnas:

el punto de verificación a evaluar
el nivel de dicho punto. Se indica si es A, si es A sólo según la Norma UNE 139803, o si sólo es A en determinado contexto
un listado con las páginas de la muestra. El nombre que aparecerá será el alias que se le ha dado a cada página en la primera pestaña.
un desplegable por cada página para indicar si dicha página cumple con el punto de verificación. Es lo que debe rellenar el evaluador a medida que avanza en el análisis de accesibilidad de las páginas. Los valores disponibles son:
- Sí: la evaluación manual (o automática cuando sea posible) determina que cumple dicho punto de verificación.
- No: la evaluación manual (o automática cuando sea posible) determina que no cumple dicho punto de verificación.
- No se aplica: cuando el punto de verificación no es aplicable a la página porque no es posible una respuesta "sí" o "no". Por ejemplo, el punto de verificación 1.2 dice “Proporcione vínculos redundantes en formato texto para cada zona activa de un mapa de imagen del servidor”, si la página analizada no tiene mapas de imagen de servidor, no puedes indicar que se han proporcionado vínculos para cada zona activa ni que no se han proporcionado, simplemente no se aplica porque no se utilizan mapas de imagen de servidor.
un desplegable para indicar si la muestra en su conjunto cumple el punto de verificación. Los valores disponibles son los mismos que en el caso anterior. El evaluador deberá especificarlo en base a:
- si alguna de las páginas no cumple el punto de verificación, la muestra en su conjunto no lo cumple
- si el punto de verificación no se aplica a todas las páginas, dicho punto no se aplica a la muestra en su conjunto
- sí ninguna de las páginas no cumple el punto el punto de verificación (es decir, sólo hay páginas que lo cumplen o en las que no se aplica), la muestra en su conjunto cumple el punto de verificación

Para hacerlo más visual y localizar con más facilidad el tipo de datos insertados, en función del valor especificado se estable un código de color:

¿Que información nos genera esta pestaña?

En la imagen anterior se ve que por cada punto de verificación nos incluye un resumen del número de páginas de la muestra que cumple, no cumplen o en las que no se aplica dicho punto de verificación.

El grueso de la información generada la encontramos a la derecha de las columnas especificadas anteriormente:

Los datos que proporciona son:

una tabla resumen del cumplimiento de nivel A de la muestra en general. El nº de puntos que se cumplen, no se cumplen o no se aplican y qué porcentaje suponen respecto al número de puntos que hay que cumplir. Se ofrece el porcentaje de cumplimiento y no cumplimiento tanto teniendo en cuenta los puntos no aplicables como sin tenerlos en cuenta.
gráfico que refleja también el resultado del porcentaje de cumplimiento y no cumplimiento del nivel A de la muestra. Para la realización del gráfico no se tienen en cuenta los puntos no aplicables, es decir, a la hora de hacer la estadística se restan del número de puntos que hay que cumplir.

una tabla resumen por cada una de las páginas de la muestra. Por cada página podemos ver el número de puntos de nivel A que cumple, no cumple o no se aplican, y el porcentaje que suponen respecto al número de puntos que se han de cumplir. Se ofrece el porcentaje de cumplimiento y no cumplimiento tanto teniendo en cuenta los puntos no aplicables como sin tenerlos en cuenta.

gráfico de barras que refleja también el porcentaje de cumplimiento y no cumplimiento del nivel A de cada página de la muestra. Para la realización del gráfico no se tienen en cuenta los puntos no aplicables, es decir, a la hora de hacer la estadística se restan del número de puntos que hay que cumplir.

Esta información nos permite conocer el nivel de adecuación de la muestra y de cada página. Nos permite además localizar de forma visual las páginas que más problemas tienen.

Pestaña 3: AA

El funcionamiento y los datos que genera son equivalentes a la pestaña A pero para los puntos de verificación de nivel AA.

Los datos se generan para los puntos de verificación AA y para los puntos de verificación A+AA.

Los primeros son sólo a modo informativo y sirven también de base para calcular los realmente importantes, los datos A+AA.

Para alcanzar el nivel de adecuación AA es necesario cumplir con los puntos de verificación A y AA, por tanto los gráficos y estadísticas que nos informan del nivel de adecuación AA de la muestra son los datos A+AA.

Pestaña 4: Por puntos de verificación

Esta pestaña nos da una perspectiva global de los puntos de verificación que más problemas están generando. Por cada uno de ellos, en una tabla, agrupados por nivel A o AA, se indica el nº de páginas de la muestra que lo cumplen, no lo cumplen o en las que no se aplica.

Se generan una serie de gráficas que permiten identificar cuáles son los más o lo menos problemáticos.

Descarga de la herramienta

La descarga es gratuita.

Descarga de la herramienta de ayuda para realizar una consultoría web. Archivo excel .XLSX de 85.6 KB

Esta prohibido su uso comercial y su distribución sin permiso del autor.

Servicio relacionado: Consultoría de accesibilidad web

Artículos relacionados:

Consejos avanzados de accesibilidad web

2012-01-04T01:12:00.001+01:00

Artículo relacionado: Respuesta a 25 dudas habituales sobre accesibilidad web

Los hashtag de Twitter son efímeros, por ello recopilo en este artículo los 25 consejos de accesibilidad que publiqué en Twitter durante el 2011 bajo el hashtag #tipAA. Algunos están ampliados con más de 140 caracteres, tal y como los publiqué en Google + o Facebook, otros los he reescrito para este artículo.

En un formulario web se debe asociar explícitamente cada etiqueta con su control, pero ¿cómo realizar asociaciones complejas? Ejemplo de asociación compleja de radios y labels de forma accesible.
Al validar un formulario web ten en cuenta que: identificar los campos erróneos únicamente resaltándolos en rojo es transmitir información solo con el color, y por tanto incumple el punto de verificación 2.1 de las WCAG 1.0 (prioridad 1) y con el criterio de conformidad 1.4.1 de las WCAG 2.0 (nivel A)
Las WCAG 2.0 indican que puedes borrar el contenido de un input cuando este coge el foco, puesto que es un cambio de contenido pero no de contexto (criterio de éxito 3.2.2). Sin embargo no es correcto implementar que el foco salte al siguiente campo una vez que el actual se ha rellenado (como por ejemplo es habitual al rellenar los campos de una cuenta bancaria) pues en este caso sí se trata de un cambio de contexto. Más información en la técnica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
Las WCAG 2.0 admite el uso de target="_blank" con (X)HTML Transitional si indicas que el enlace se abre en otra ventana mediante un texto incluido dentro del enlace: <a href="ayuda.html" target="_blank">Ayuda (se abre en ventana nueva) </a> (nivel AAA) Más información en “¿Mi página es inaccesible si utiliza ventanas emergentes?”
En una página web, los enlaces o los campos de un formulario pueden coger el foco, sin embargo un DIV, por ejemplo, no. Aquellos elementos que vayan a cambiar dinámicamente tienen que poder coger el foco para que sean accesibles a los lectores de pantalla. Para que un elemento que no coge el foco pueda cogerlo deberá tener
tabindex="-1" Más detalles en el artículo “AJAX accesible”
El interlineado recomendado por las WCAG 2.0 es que el espacio entre líneas (interlineado) sea de, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos sea, al menos, 1.5 veces mayor que el espacio entre líneas. Consultar criterio de conformidad 1.4.8 (nivel AAA)
No utilices elementos desaconsejados por el W3C. Consulta la Cheat Sheet HTML 4.01, HTML 5, XHTML Elements
Incluye un menú de navegación semántica en el HEAD de las páginas. WCAG 1.0: punto de verificación 13.2 AA, 13.9 AAA; WCAG 2.0: Técnica H59: “Using the link element and navigation tools”
Si quieres ocultar contenido visualmente pero que sea accesible para usuarios de lectores de pantalla NO uses display:none. Consulta el artículo “Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página”
Identificar el idioma principal del documento, proporcionar resumen a las tablas y asegurar un orden lógico de tabulación: estos son los 3 puntos que pasan de ser nivel AAA en las WCAG 1.0 a A o AA en la Norma UNE 139803. Consultar “Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0”
Se debe incluir el atributo SUMMARY solo en las tablas que no se utilizan para maquetar (AA: Norma UNE 139803; AAA: WCAG 1.0)
Si tu web tiene contenido Flash consulta la “Checklist para validar contenido Flash de acuerdo con las WCAG 2.0”
¿Un formulario con varios botones que no dependa de javascript y sea accesible? Mi post más leído con 25.000 visitas: “Formulario con varios botones. Implementación usable y accesible”
Los enlaces y campos de formulario no solo deben coger el foco, sino que este debe ser visible. No usar :focus {outline:0;} o peor aun onfocus="blur()" Consultar Common Failures F55 y Common Failures F78
No es necesario que H1 aparezca en el código antes que H2, lo importante es que H1 sea de primer nivel y H2 de segundo nivel. Consultar “¿Es correcto que aparezca en el código HTML un H2 antes que un H1?”
El ancho de un párrafo no debe ser mayor de 80 caracteres: criterio de conformidad 1.4.8 (AAA) de las WCAG 2.0
Solo un sonido que dura más de 3 segundos debe tener la opción de pausarlo o detenerlo: criterio de conformidad 1.4.2 (nivel A) de las WCAG 2.0
Distinguir los enlaces dentro de un texto solo por el color (sin subrayar) es transmitir información solo con el color, y por tanto incumple el punto de verificación 2.1 de las WCAG 1.0 (prioridad 1) y con el criterio de conformidad 1.4.1 de las WCAG 2.0 (nivel A)
Checklist para validar formularios de acuerdo con las WCAG 2.0 (excel, 85 kb)
No es necesario marcar el cambio de idioma de nombres propios, términos técnicos y palabras extranjeras que se pronuncian igual en el idioma de tu página. Consultar “¿Debo indicar el cambio de idioma en cualquier tipo de palabra?”
No justifiques el texto u ofrece un mecanismo para evitarlo. Consulta “¿Cómo debo presentar el texto: justificado o alineado a la izquierda?”
Conoce las "Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0" (excel gratuita de correspondencias)
En una página de nivel de adecuación AA los vídeos deben incluir subtítulos sincronizados y transcripción de la banda sonora con descripción de la pista visual.
Una imagen que funciona como enlace no puede considerarse nunca decorativa. Se incluirá en la página con IMG con un ALT significativo.
Caso en el que una imagen que actúa como enlace puede tener alt=””:
<a href=”enlace.html”><img src=”icono.gif” alt=””>Texto del enlace</a>
Es decir, una imagen junto a un texto, siendo que el enlace los engloba a los dos.

Artículo relacionado: Respuesta a 25 dudas habituales sobre accesibilidad web

iPad, recomendaciones de usabilidad para tu web

2011-11-22T22:35:00.003+01:00

En este artículo doy 10 recomendaciones extraídas de mi experiencia para que tu web sea más usable cuando es accedida desde un iPad.

Si os interesa el tema os recomiendo: "Usability of iPad Apps and Websitse", de Jakob Nielsen. PDF gratuito de 134 pp. (14.8 MB)

1. Incluye un “favicon” específico para el iPad

Cuando visualizas una página web con el iPad tienes la opción de “Añadir a la página de inicio”. Esta opción crea un acceso directo en el escritorio cuyo icono es una zona de la web y resulta poco reconocible.

Para personalizar el icono es necesario incluir la siguiente línea en las páginas:

<link rel="apple-touch-icon" href="/apple-touch-icon.png" />

La imagen debe ser de 72x72 (también coge 57X57, propio del iPhone, pero la resolución evidentemente es menor)

También puedes indicar varios tamaños (el primero es para 57x57):

<link rel="apple-touch-icon" href="touch-icon-iphone.png" /> <link rel="apple-touch-icon" sizes="72x72" href="touch-icon-ipad.png" /> <link rel="apple-touch-icon" sizes="114x114" href="touch-icon-iphone4.png" />
[Ejemplo de Configuring Web Applications de iOS Developer Library]

En el siguiente ejemplo muestro el escritorio con dos enlaces directos a mi blog antes de ponerle una imagen específica y el tercero cuando ya se la he incluido:

2. No utilices Flash

Desde el iPad, de forma estándar, no se puede visualizar Flash ni se puede descargar el plugin para visualizarlo. De hecho, Adobe anunció este mes que abandona Flash para dispositivos móviles.

Es cierto que hay algunas maneras de visualizar Flash, por ejemplo con la aplicación gratuita iSwifter. Pero si quieres que sea accesible para todos debes abandonar el uso de Flash y pasarte a HTML5 (que iPad soporta) o en su defecto ofrecer alternativas.

Recordemos que dar una alternativa a Flash es un requerimiento de las WCAG 1.0, por tanto, si tu web fuera accesible también lo sería en un iPad.

Puede ser tan simple, cuando se trata solo de un banner, como:

<object type="application/x-shockwave-flash" data="flash.swf" width="230" height="100"> <param name="movie" value="flash.swf" /> <param name="quality" value="high" /> <img src="flash.gif" width="230" height="100" alt="Texto aternativo de la imagen" /> </object>

Pongo a continuación algunos ejemplos de cómo se visualizan en el iPad páginas con contenido en Flash:

Web de Disney: no muestra ninguna alternativa al contenido central que es un Flash, solo un texto y un enlace para descargar el plugin (que no podrá descargarse con el iPad)

Web de Caprabo: muestra texto alternativo a las animaciones Flash

Web Chocapic: es una web en Flash a la que no se podrá acceder. Solo muestra una imagen con un mensaje pero no hay una alternativa en HTML.

Web de Vodafone: muestra una imagen alternativa a la animación en Flash y un enlace a la descarga del plugin (que no podrá descargarse en el iPad)

El banner superior de elpais.com no muestra ni un mensaje ni una imagen alternativa. Por el contrario, la publicidad interior, que también es en Flash, sí se visualiza como una animación en el iPad:

3. Comprueba que los campos del formulario cogen el foco y lo hacen en un orden lógico

Cuando “tocas” un campo de texto se muestra el teclado de pantalla del iPad. Sobre este teclado aparecen dos enlaces “Anterior” y “Siguiente”

Mediante estos enlaces el usuario se mueve a los campos siguientes y anteriores. Por tanto, asegúrate de que todos los campos cogen el foco y lo hacen en el orden correcto. No hay nada más molesto que tener que volver a la pantalla para seleccionar un campo que no coge el foco.

Este es también un requerimiento de las WCAG, por tanto, volvemos a ver que si tu web es accesible también será más fácil de usar en el iPad.

4. Ayuda al usuario a rellenar los campos del formulario: indica el tipo de campo

Cuando relleno formularios con el iPad me molesta que no reconozca el tipo de dato que se pide y, en función del mismo, me muestre la versión del teclado adecuada.

Y sin embargo hay una manera de hacerlo:

Campo texto: <input type="text" /> Campo url: <input type="url" /> Campo numérico: <input type="number" /> Campo email: <input type="email" />

Los navegadores que no soportan HTML5 lo obviarán y los tratarán como campos de tipo texto (type="text").

Esto lo ví en Tip Precoz 5: teclados de iPhone/iPad. Pongo ejemplos de los diferentes tipos de teclado que se muestran en función del tipo de campo:

Campo type="text"

Campo type="url"

Campo type="number"

Campo type="email"

5. Recuerda que no tienes ratón

Comprueba que tus eventos de ratón funcionan en la pantalla táctil. En el iPad funciona por ejemplo el mouseover, pero te puedes encontrar con problemas asociados al drag&drop, por lo que puede ser necesario traducir los eventos de ratón a eventos táctiles:

Por ejemplo, el siguiente menú no se puede arrastrar con el iPad.

Por ejemplo, el siguiente menú ordenable no se puede ordenar con el iPad.

Por ejemplo, las columnas ordenables de esta tabla no se pueden ordenar con el iPad.

De nuevo nos encontramos con un requerimiento de las WCAG, así que una vez más, una web accesible es una web también accesible para el iPad.

Enlaces interesantes:

Touch Events version 1 del W3C
Developing for Multi-Touch Web Browsers de HTML5Rocks.

6. Recuerda que se navega con el dedo

¿Te has medido la yema del dedo? La zona de la yema con la que pulso mide más o menos 1cm x 1cm.

Ten cuidado con el tamaño y la separación entre los enlaces, los botones y los radiobuttons y checkbox para que sea fácil seleccionarlos sin tener que hacer zoom.

Para ello puede ser muy útil cargar una CSS específica para el iPad, donde el tamaño y los márgenes sean mayores.

Un ejemplo rápido (y un poco burdo). Tengo el siguiente formulario (visualizado con Explorer):

Para que sea más fácil de utilizar con el iPad, le he aplicado una CSS específica:

<link rel="stylesheet" media="only screen and (max-device-width:1024px)" href="ipad.css"/>

Efectivamente se aplica solo en iPad y, como se ve, presenta los elementos más grandes y separados:

Solo le falta el toque estético :)

Por ejemplo, en la web de Zara vemos que los iconos son muy pequeños y tanto estos como los menús están muy juntos y resulta muy difícil pulsarlos con el dedo, le vendría bien una CSS específica:

Jakob Nielsen recomienda que los iconos sean al menos de un 1cm x 1cm para que sean fáciles de pulsar con el dedo... supongo que también se ha medido la yema del dedo.

7. Revisa la visualización en vertical y en horizontal

Recuerda que si giras el iPad, tu web también rota y se adapta al ancho vertical u horizontal.

Quizás te puede interesar una CSS diferente para cada caso:

Es interesante el artículo iPad CSS Layout with landscape / portrait orientation modes:

Pero si lo haces, o juegas con el viewport, ten cuidado de que lo estés haciendo bien …

Mira este ejemplo de sativapedia.com, en horizontal la web se ve bien, pero en vertical no se adapta y el contenido queda cortado.

Enlaces de interés:

8. Cuidado con los plugins para escuchar música y ver vídeo

No uses plugins basados en Flash. Por ejemplo en http://www.masvoces.org/ con el iPad no se visualiza el reproductor de audio porque está basado en Flash.

Una buena idea es pasarse a las etiquetas HTML5 <audio> y <video>. Puedes consultar reproductores de video y audio basados en HTML 5 en 10 Beautiful HTML5 Video & Audio Players.

9. Ojo con position:fixed

Cuidado si utilizas en la CSS “position:fixed” porque puede que la capa no aparezca en el iPad donde deseas (cuando defines además un right y bottom para la capa)

La capa que muestro recuadrada en el siguiente pantallazo del iPad, en otros navegadores se ve en la esquina superior izquierda:

Para el uso correcto de “position:fixed” lo mejor es leer el artículo de quiksmode.org The fifth position value

10. ¿Por qué cargar la versión móvil?

En algunos sitios se carga por defecto, cuando navegas con el iPad, la versión para dispositivos móviles, para pantallas pequeñas, muchas veces porque no se está detectando correctamente el User Agent.

Lo he visto en algún blog, pero no digo en cuál para que nadie se dé por aludido. Os recomiendo que lo probéis.

Conclusión

La primera es que soy una pésima fotógrafa. La segunda que si hacemos web accesibles serán más fáciles de usar en diferentes dispositivos, actuales y venideros.

Pero como conclusión última cito un pasaje de Jakob Nielsen en "Usability of iPad Apps and Websitse", cuando indica que lo más importante es:

First and most importantly, you should test your site. See what the pain points are and then address them. Often fixes will improve the overall usability of your website on the desktop, as well. Some of the more obvious fixes include:
Getting rid of Flash content
Creating bigger targets and pad targets so that they tolerate touch better
Spacing links wherever possible
Detecting location
Minimizing the need for typing
Grouping controls or pieces of information that are related (to avoid having content ignored because it’s below the fold)

Otros enlaces importantes

Recursos de interés:

Otros artículos de este blog:

Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página

2011-11-13T03:01:00.003+01:00

Artículos relacionados:

El objetivo del artículo es explicar cuál es la mejor manera de ocultar visualmente contenido de una página web de tal manera que:

no comprometa el posicionamiento de la página con prácticas sancionables por Google
asegure la accesibilidad de las páginas para aquellas personas que utilicen lectores de pantalla

La idea de este artículo ha surgido a raíz de la conversación que ha suscitado mi último consejo de accesibilidad en Twitter: “Si quieres ocultar contenido pero que sea accesible para los lectores de pantalla NO uses display:none, usa text-indent:-999px”

Por tanto no lo hubiera escrito si no lo hubieran comentado: @cssbarcelona, @cottonfieldsbcn, @davidhidalgo, @martuishere, @ericalarcon, @htmlboy, @josegemar y @noekidotcom

¿Qué texto podemos desear ocultar? ¿deberíamos ocultarlo?

En un desarrollo accesible hay dos ejemplos típicos y habituales en los que se plantea ocultar texto:

el enlace “Saltar al contenido” que suele incluirse al comienzo de las páginas. Según la encuesta “Survey of Preferences of Screen Readers Users” de WebAim de 2009, el 38% de los usuarios de lectores de pantalla lo utiliza siempre que puede o a menudo y el 24% algunas veces (otros prefieren saltar de encabezado en encabezado). Recordemos que incluir este tipo de enlace es de prioridad AAA en las WCAG 1.0 (punto de verificación 13.6) y de prioridad A en las WCAG 2.0 (criterio de verificación 2.4.1)
el texto complementario a los enlaces del tipo “Leer más”, puesto que deben evitarse enlaces con el mismo texto pero con vínculos a páginas diferentes. Por tanto, cada uno de los enlaces “Leer más” (por ejemplo asociados a los titulares de varias noticias) es en realidad “Leer más sobre la Noticias 1”, “Leer más sobre la Noticia 2”, pero el texto que sigue a “Leer más” se oculta a la vista. Recordemos que evitar este tipo de enlaces con texto igual pero vínculo diferente es un requisito AA en las WCAG 1.0 (punto de verificación 13.1) y A o AAA en las WCAG 2.0 en función de si es comprensible el enlace en el contexto (criterio de verificación 2.4.4 y 2.4.9)

Por tanto se dan casos en los que para cumplir con las pautas de accesibilidad puede que pensemos que hay que ocultar algún texto. Digo que “puede que pensemos” puesto que antes de tomar esta decisión habría que meditar si es realmente necesario o conveniente ocultarlo.

Por ejemplo, en el primer caso, si bien es cierto que el enlace “Saltar al contenido” beneficia a los usuarios que utilizan lectores de pantalla porque les permite alcanzar el contenido principal de una forma sencilla y rápida (evitándoles escuchar la cabecera y el sistema de navegación en todas las páginas antes de llegar al contenido) también beneficia a las personas que acceden con el teclado, a aquellos que utilizan magnificadores de pantalla o a los que acceden desde un dispositivo móvil.

Sería por tanto recomendable incluirlo siempre visible, pero a veces se imponen otros criterios estéticos. Solo quería dejar ahí la reflexión. Pasemos ahora a ver, si los ocultamos, cómo deberíamos hacerlo.

Display:none

Aplicar el estilo display:none a un elemento de una página lo hace totalmente invisible: no genera una caja, no ocupa lugar, no afecta a la disposición. Oculta el elemento y sus descendientes no sólo visualmente sino también a los lectores de pantalla.

Para saber exactamente cómo interpretan diferentes lectores de pantalla display:none (pues no es cierto que todos los lectores de pantalla en todos los casos y con todos los navegadores no lean un elemento oculto con display:none) recomiendo el artículo de agosto de 2011 “JAWS, Window-Eyes and display:none: Return to 2007” de Jason Kiss.

Sobre el uso de display:none recomiendo el artículo “Do not use display:none to visually hide content intended for screen readers” de Roger Johansson.

Visibility:hidden

Con visibility:hidden ocurre algo similar, el contenido así oculto no siempre será leído por los lectores de pantalla, pero estos tampoco lo interpretan como un display:none. Por eso, cuando lo que se quiere es que algo esté oculto visualmente y oculto para todos los lectores de pantalla (lo contrario que estamos tratando aquí, que queremos ocultarlo visualmente pero que sea leído por los lectores de pantalla) lo que se recomienda es que se oculte con ambos:

.hide { display: none; visibility: hidden; }

Recomiendo leer el artículo “Screen readers sometimes ignore display:none” de Roger Johansson y el estudio “Empty Links and Screen Readers” de yuiblog.com donde se muestran esquemáticamente los resultados de utilizar display:none y visibility:hidden con diferentes navegadores y lectores de pantalla.

En cualquier caso, ni display:none ni visibility:hidden cumplirían el requisito que necesitamos de que el texto oculto sea leído por todos los lectores de pantalla.

Height:0

.element-invisible { height: 0; overflow: hidden; position: absolute;}

Hubiera estado bien, pero Jeff Burnz indica en “Using CSS clip as an Accessible Method of Hiding Content”, que desgraciadamente, aunque NVDA y Jaws leían el contenido, Apples Voice Over no lo lee.

Posicionar el texto fuera de pantalla

Por ejemplo con text-indent:-999em (no aplicable a los lenguajes que se leen de derecha a izquierda) o top: -999em;

Esta técnica es accesible para los lectores de pantalla. Pero debe tenerse en cuenta también a los usuarios que no usan un lector de pantalla y asegurarse de que el foco se haga visible. No puede ser que una persona que accede con el tabulador pierda el foco porque este se ha ido a una serie de elementos ocultos situados fuera de pantalla, de tal manera que debe tabular varias veces, sin saber dónde está el foco, hasta que este vuelve a ser visible.

Fijaros cómo lo resuelve la página Department of Homeland Security

a#skip, a#skip:hover, a#skip:visited {position:absolute; top:-100px; width:1px; height:1px; overflow:hidden; font-size:x-small;} a#skip:active, a#skip:focus {position:static;width:auto;height:auto;text-align:center;margin:0 auto} <a href="#content" id="skip" accesskey="2">Skip Navigation</a>

El enlace está fuera de pantalla, pero cuando el enlace coge el foco este se hace visible.

Os recomiendo también el artículo “Skip Navigation Links” de James W. Thatcher, donde recuerda también el tema del tabindex=”-1” y las anclas en Explorer.

Puede parecer entonces que esta opción, bien implementada, sería la solución ideal. Sin embargo surge la duda de si podemos tener un problema con el posicionamiento de la página.

Google dice que penaliza el contenido que se oculta, y contenido con text-indent negativo parece fácil de rastrear. Da igual que lo incluyas en la CSS porque también analiza las CSS. Si las restringimos en el fichero “robots.txt” no quiere decir que Google no pueda acceder a ellas y entonces puede que sí seamos realmente sospechosos.

¿Se debe por tanto dejar de utilizar text-indent negativo por miedo a ser penalizado? He estado leyendo experiencias de mucha gente y todos parecen coincidir al final en lo mismo: lo utilizan sin sufrir penalización cuando se hace sin intención maliciosa, es decir, cuando el texto oculto no incluye un relleno de palabras clave, así lo dicen incluso desde Google, cuya página, al fin y al cabo también utiliza el posicionamiento fuera de pantalla.

Resultan muy ilustrativos los comentarios del artículo ”Google, SEO and using CSS to hide text” o el artículo “Demystifying Google's text-indent mystery”

En fin, que después de horas leyendo no he encontrado a nadie que diga que utilizando text-indent de forma legítima, como los ejemplos que he expuesto, le hayan penalizado.

Aun así nos queda una última técnica.

Clip

.element-invisible { position: absolute !important; clip: rect(1px 1px 1px 1px); /* IE6, IE7 */ clip: rect(1px, 1px, 1px, 1px); }

Está técnica es explicada en “Using CSS clip as an Accessible Method of Hiding Content”. Según se indica, el texto así oculto trabaja en todos los navegadores y es leído por Jaws, NVDA y Apple Voice Over. En realidad hay que retocarlo para que esto sea realmente así según se explica en “Clip your hidden content for better accessibility”, de Thierry Koblentz.

Esta técnica la podemos mejorar para el tema del foco (cuando lo que ocultamos son elementos que cogen el foco, por ejemplo un enlace), tal y como veíamos en el ejemplo anterior, de tal manera que cuando coja el foco ponemos "clip" a "auto" y "position" a "static"

Por otra parte, Google no penaliza esta práctica. Así que parece la solución ideal: accesible y no compromete el posicionamiento. Pero siempre hay una pega, en este caso que clip: rect(1px 1px 1px 1px); no pasa el validador de sintaxis CSS. Resulta que IE6 y IE7 no siguen la especificación y para que funcione en estos navegadores los parámetros deben separarse sin comas.

Mi opinión es que, si las definiciones específicas para determinados navegadores:

no provocan conflictos con otros navegadores
no suponen un problema de accesibilidad
se agrupan en una CSS independiente

no deben coartar que se utilicen en aras precisamente de mejorar la accesibilidad de las páginas.

Conclusión

No usar display:none, visibility:hidden, ni height:0, puesto que no aseguran la accesibilidad de los textos ocultos en todos lectores de pantalla.
Se puede usar el posicionamiento fuera de pantalla porque es accesible, siempre y cuando lo utilices de forma lícita y no para incluir palabras clave, de lo contrario puedes ser penalizado.
Se puede usar la técnica del clip porque es accesible y no provoca problemas con el posicionamiento de la página, pero tienes que ser consciente de que la CSS no pasará el validador de sintaxis del W3C.

Artículos relacionados:

Aceptar/Cancelar o Cancelar/Aceptar

2011-10-21T18:48:00.004+02:00

Ayer me preguntaban en Twitter mi opinión sobre cuál debe ser en web el orden de los botones:

Aceptar/Cancelar, siguiendo el orden de lectura natural como hace Windows.
Cancelar/Aceptar, poniendo la conclusión, la acción que te lleva hacia delante a la derecha como hace Apple.

Antes de continuar recomiendo el artículo “OK–Cancel or Cancel–OK?” de Jakob Nielsen

En función del tipo de usuarios con los que testeemos, podremos encontrar preferencias para todos los gustos, a veces en función de la plataforma que usan y otras veces no.

Sin embargo, la respuesta según mi opinión, a cuál es el orden más recomendable no es ni la “a”, ni la “b”, ni siquiera que los pongas en función del porcentaje de usuarios Windows vs MAC que tengas según las estadísticas de tu sitio. Para mi, la respuesta adecuada es que el orden no es lo importante realmente como explico a continuación.

Supongamos que vamos a testear un formulario con los siguientes botones:

y que comprobamos que los usuarios se equivocan y esperan encontrar el botón “Aceptar” a la izquierda. ¿Lo importante es el orden? ¿es eso lo que debemos cambiar?

Veamos otras modificaciones posibles que no implican cambiar el orden de los botones pero que evitan las equivocaciones de los usuarios:

En este ejemplo, se busca un nombre más específico para el botón “Aceptar”, se muestra seleccionado por defecto, se centra con el formulario y su literal se pone en negrita y un poco más grande.

Da igual como los coloques, derecha o izquierda, la claridad de los mismos es independiente de su orden:

En función del formulario podemos buscar un literal también más específico para el botón “Cancelar”, que incluso se puede incluir como un enlace.

Y según el tipo de portal, la libertad en el diseño ayudará también a diferenciar los botones:

Por tanto, las claves para mí, no son el orden, sino:

mantener la consistencia en el orden y la presentación de los botones en todas las páginas del sitio
cuidar el literal de los botones para que sea lo más específico posible
pero sobre todo, diferenciar visualmente la acción principal de la opción secundaria como he ejemplificado antes

Desde un punto de vista de accesibilidad

Todo lo dicho anteriormente está enfocado a decidir si el orden de los botones ayuda a evitar errores a los usuarios que visualizan el formulario .

Sin embargo, hay otros factores asociados al tema del orden de los botones que puede ayudarnos a decidir cuál poner primero:

El primer botón será el que aparezca resaltado y el que responderá a la tecla Enter. Es verdad que esto se puede modificar, aunque con javascript.
El usuario que se mueve con el tabulador por el formulario llegará en primer lugar al primer botón. También esto se puede modificar, pero entonces incumpliríamos la pauta de mantener la coherencia entre el orden visual y el del foco.

Estos dos factores favorecen a los usuarios que utilizan lectores de pantalla, aunque hay que recodar que tienen atajos de teclado para acceder al listado de elementos del formulario, o para ir a los botones de la página.

Si la pregunta es cuál es el orden que yo prefiero, me viene a la memoria la discusión que duró días con una aplicación del Santander con la que se hizo al final un documento específico sobre el tema, y se puso Aceptar a la derecha. Es la opción que yo prefiero como usuaria (y lo soy de Windows) pues asocio Cancelar con Volver y Aceptar con Siguiente. Pero esto son ya preferencias personales y batallitas.

Artículos relacionados

ePub accesibles

2011-09-24T01:02:00.004+02:00

¿Qué es un ePub?

ePub (Electronic Publication) es un formato de código abierto para la creación y distribución de libros electrónicos (e-books) que se adapta a los diferentes tamaños de pantalla de los eReader del mercado y que se está convirtiendo en el estándar más aceptado.

Fue un hito hace dos años cuando Google Books comenzó a ofrecer más de un millón de libros no sólo en formato PDF sino también en formato ePub

Un fichero .epub es un contenedor comprimido con archivos XML y XHTML. Si renombras el fichero como .zip podrás ver que contiene un directorio OPS con los ficheros CSS, HTML (XHTML 1.1 que no pueden contener formularios, mapas de imagen, eventos o scripts) y las imágenes (admite JPG, PNG, GIF y SVG).

En el fichero “content.opf” se incluyen los metadatos con Dublin Core (siendo obligatorio definir el lenguaje y el título), el inventario de contenidos y el orden en el que se muestran. En “toc.ncx” se incluye la tabla de contenidos para el dispositivo de lectura mejorando así la accesibilidad del libro.

Estructura de un ePub vista con Sigil

Puedes consultar la descripción detallada de los elementos que componen un ePub en “Taller de creación de documentos ePub” de APEI

¿En qué dispositivos puedo leer un ePub?

Puede leerse en casi todos los dispositivos de lectura electrónica (eReaders) de forma nativa, a excepción de Kindle de Amazon, sin embargo pronto lo admitirá también [1], entonces podremos afirmar que es el formato generalizado de los e-books. Incluso eReaders antiguos se han actualizado vía firmware para poder leer ePub.

También podemos leer un ePub en otros dispositivos (ver lista completa de todos los lectores de e-books para los diferentes dispositivos):

en un iPad, iPhone y iPod Touch, con iBooks
en otros dispositivos móviles:
- en teléfonos Android, por ejemplo con Aldiko
- en teléfonos con sistema operativo Windows Mobile, por ejemplo con Freda
- en Blackberry, por ejemplo con Kobobooks
desde un PC o MAC, por ejemplo con Calibre, Stanza Desktop o Adobe Digital Editions

Al estar basado en HTML tampoco hay mucha dificultad para verlos con un navegador web. Por ejemplo, podemos instalar el complemento EPUBReader para Firefox o por ejemplo el complemento MagicScroll Ebook Reader para Chrome.

También existen sitios para leer libros ePub en línea como bookworm

¿Cómo creo un ePub?

Desde 2008 InDesign permite generar ePub, se puede consultar el vídeo “Creating an iBook (ePUB) for the iPad with InDesign CS5” o la guía “Making eBooks from InDesign (PDF, 4 MB)”, de InDesign Magazine nº32

Exportación a eBook de InDesign

Atlantis Word Processor es un editor para Windows que permite guardar en formato ePub. Está disponible en versión portable.

Exportación a eBook de Atlantis Word Processor

Recomiendan utilizar la plantilla “eBook.rtf”. Se pueden consultar otras recomendaciones en Atlantis Word Processor Online Help: eBooks

Pero también podemos crear un ePub desde un fichero ya existente: PDF, ODT, DOC, HTML, etc. con los siguientes programas:

dotePub

Es una extensión que permite crear un ePub desde una página web. Es compatible con Chrome, Firefox, Safari u Opera. Se puede ver cómo funciona en el vídeo Installing and using the dotEPUB bookmarklet

QualityEpub

Es un programa gratuito para Windows que permite generar un .epub a partir de un documento Word.

ToDoEpub

Es un programa gratuito para Windows escrito en.NET, que permite generar un .epub a partir de un documento HTML. También tiene opciones simples de edición.

Pantalla de edición de ToDoEpub

GrabMyBooks

Es una extensión para Firefox que nos permite crear libros electrónicos en formato .epub a partir de páginas web. Cada una de las páginas que vayamos guardando se acumulará dentro de un libro que luego podremos guardar en nuestro disco.

Gammata Conversor

Podemos convertir un HTML, DOC o PDF a EPUB

Pantalla principal de Grammata Conversor

Calibre

Los formatos de entrada que admite son: CBZ, CBR, CBC, CHM, EPUB, FB2, HTML, HTMLZ, LIT, LRF, MOBI, ODT, PDF, PRC, PDB, PML, RB, RTF, SNB, TCR, TXT, TXTZ

Los formatos de salida que admite son: EPUB, FB2, OEB, LIT, LRF, MOBI, HTMLZ, PDB, PML, RB, PDF, RTF, SNB, TCR, TXT, TXTZ

No admite DOC (sería necesario guardarlo como ODT) aunque si PDF, pero avisa que la conversión de PDF a ePub es siempre complicada.

El vídeo Pasar libro de PDF a EPUB te enseña cómo convertir un PDF en EPUB con Calibre

Jutoh

Permite crear un ePub desde TXT, ODT o HTML. La importación permite bastante personalización: metadatos, posibilidad de importar o no las imágenes y su tamaño, aplicar una CSS personal al fichero, importar sólo un fichero o un directorio, diseñar la cubierta, etc.

Pantalla de creación de Jutoh, puede crear un fichero desde cero o importar ficheros

Pero además, permite crear un ePub desde cero. Como veremos también permite la edición del ePub.

eCub

Es similar a Jutoh pero mucho más simple y con menos prestaciones. Permite convertir a ePub un fichero de texto o HTML, pero también crearlo desde cero y editarlo.

Pantalla de principal de eCub

Barra edit@

Permite a los usuarios del gestor de contenidos Alfredo convertir documentos DOC, ODT o HTML en ePUB

¿Cómo puedo editar un ePub?

Cómo hemos visto en el apartado anterior, las herramientas Jutoh, eCub y ToDoEpub permiten la edición de ficheros ePub.

La más recomendable de las tres es Jutoh:

Pantalla de edición de las propiedades del documento de Jutoh

Pantalla de edición de las imágenes de Jutoh, que permite poner texto alternativo a las mismas

Disponemos también de otra herramienta potente y muy recomendable: Sigil, que es gratuita.

En Sigil podemos ver las páginas en modo edición, en modo código o en modo mixto, lo cual nos permite modificar el código fuente de los XHTML.

Edición del código XHTML de las páginas del ePub con Sigil

Sigil tiene otras muchas prestaciones como la validación de ePub y la validación de errores estructurales, la generación de la tabla de contenidos a partir de los encabezados, un editor avanzado de metadatos. Sin embargo no podemos editar las propiedades de las imágenes o insertar un hipervínculo, acciones que deberemos hacer manualmente en la edición del código.

Se pueden consultar varios tutoriales como Crear un epub con Sigil o los vídeos Curso de eBooks con Word con capítulos dedicados a Sigil

¿Cómo validar un ePub?

No hablamos de validar la accesibilidad del ePub sino de validar que el ePub esté bien formado: que los metadatos sean correctos, que todas las imágenes resulten visibles, que la tabla de contenidos sea correcta y aparezcan en el orden apropiado, que la codificación sea UTF 8 o UTF 16, etc.

Las herramientas de edición Jutoh, eCub y Sigil que hemos visto en el apartado anterior incluyen también herramientas de validación.

Existe un validador online: Validate EPUB documents. También existe bookworm pero es necesario registrarse.

Otros validadores son: Epubcheck y Flightcrew

Sin embargo, como hemos visto, el contenido del ePub no deja de ser XHTML + CSS, así que podríamos pasarles también un validador de código como Unicorn del W3C o un validador de accesibilidad como TAW.

ePub accesibles

Las normas a seguir para que un ePub sea accesible no dejan de ser similares a las que aplicaríamos a un Word, a un PDF o un HTML, y que están definidas por el WCAG (Web Content Accessibility Guidelines)

Crear una tabla de contenidos, teniendo en cuenta que hay dos tipos, la que suele aparecer al comienzo del documento y la que se utiliza como mapa de navegación en los eReader (sería el equivalente a los Bookmarks de los PDF) Se podrá generar al exportar el documento (a partir de los estilos, de los encabezados) o crearla con los programas de edición de ePub
Asegurar el correcto contraste del texto y el fondo
Incluir metadatos
Incluir texto alternativo en los elementos no textuales
Que el contenido textual sea texto y no imágenes
Estructurar correctamente el contenido con las etiquetas adecuadas (formatear las tablas, columnas (en DOC y ODT) y las listas como tales, que los títulos estén marcados como encabezados y no sólo definidos por su aspecto visual, insertar correctamente los pies y cabeceras, etc.)
Utilizar un sistema de encabezados coherente
Utilizar una galería de estilos uniforme. Es muy importante cuando se trabaje con Word, InDesign, etc. utilizar siempre estilos pues estos serán utilizados para crear la CSS. Si se pone el texto simplemente en negrita o itálica, en vez de aplicarle un estilo, no se formateará en el ePub. Incluso la opción de InDesign de basar las hojas de estilo en el formato local da resultados impredecibles
Asegurar que el texto sea legible y que se pueda modificar su configuración (aumentar o disminuir su tamaño)
Asegurar un orden de lectura correcto, por ejemplo en DOC y ODT teniendo cuidado con los cuadros flotantes
Asegurar que se pueda convertir correctamente de texto a voz
etc.

Para ello será importante trabajar adecuadamente el fichero de origen asegurando que sea accesible.

Pero además habrá que tener en cuenta las peculiaridades de los ePub y que se pueden consultar detalladamente en “Making eBooks from InDesign”, de InDesign Magazine nº32, por ejemplo:

se ignorarán los números de página automáticos, los saltos de página y los retorno de carro extra entre párrafos
se debe eliminar los saltos de línea forzados que sí se mantendrán y producen un efecto extraño según el lector y el tamaño de letra
los hipervínculos se mantienen, incluyendo las referencias cruzadas o las anclas, pero no así se los enlaces que saltan a páginas específicas
las notas se mantienen pero se convierten en notas finales del libro o la sección. Se ignoran los estilos de los números de la nota y se convierten en números normales
se recomienda crear una archivo para cada sección. Al crear el ePub los programas permitirán seleccionar todos los ficheros que conformarán el eBook. De este modo se crea un XHTML para cada sección mejorando el rendimiento en el eReader
cuanto más complicada sea la maquetación (por ejemplo el caso de una revista) la diferencia entre cómo se vería en un PDF o en una versión impresa respecto a la versión del ePub será mayor, puesto que pondrá los elementos en un flujo continuo. En la guía se dan consejos para mitigarlo.
hay que tener en cuenta las fuentes. Se pueden incrustar fuentes, pero no todos los eReaders admiten las fuentes incrustadas, utilizando sus propias fuentes por defecto. Además de las diferencias en cuanto al estilo y tamaño de la fuente original y la fuente por la que se sustituye, si se incluyen caracteres especiales estos se sustituirán por otros o por un cuadrado. Deben evitarse pues dichos caracteres especiales puesto que además ofrecen problemas al convertirse de texto a voz.
tener cuidado con las tablas, pues aunque se exportan como tales se pierde el estilo y debería aplicarse después cuando editemos el ePub. Pero además no todos los eReader soportan las tablas formateadas.

Cuanto más accesible sea el fichero de origen menos modificaciones será necesario hacer en el ePub. Pero una vez creado podremos editarlo con alguna de las herramientas de edición que comenté anteriormente. Mis preferidas son Sigil y Jutoh. Con ellas podremos modificar el ePub si presenta problemas: podremos añadir texto alternativo a las imágenes, crear o modificar la tabla de contenidos o la metainformación, etc.

Finalmente será necesario validar el ePub con los validadores que hemos visto, visualizarlo con diferentes eReader y tamaños de letra y con un lector de pantalla.

Recomiendo también la lectura de Generic guidance for accessible ebook creation (Word, 229KB) que incluye incluso una checklist de verificación de la accesibilidad del eBook.

¿Qué es un libro DAISY?

El objetivo de este artículo era hablar de la accesibilidad de los ficheros ePub y no de otras alternativas a los mismos, pero no quiero terminarlo sin al menos nombrar los libros DAISY,

Daisy Accessible Information System (Sistema Digital de Información Accesible) es un estándar basado en XML que presenta un libro en formato acústico con navegación activada dentro de una estructura secuencial y jerarquizada de texto sincronizado con audio. Es un conjunto de archivos de audio, generalmente MP3, que contiene la voz de un lector narrándonos un libro, es decir, un audiolibro.

Para la conversión a Daisy se usan principalmente transformaciones XSLT (XSL, XPath) y TTS (Text to Speech), SSML (derivado de XML específico para síntesis de voz) y SMIL (Synchronized Multimedia Integration Language) para sincronizar los diferentes audios.

La accesibilidad del EPUB aumentará en breve, en cuanto se ponga a disposición la versión EPUB 3.0, puesto que se prevé que la nueva norma convergerá con las capacidades que ofrece la norma DAISY, siendo plenamente compatibles el estándar DTBook

La barra edit@ que comentábamos anteriormente permite crear libros DAISY.

En la última pestaña de exportación a eBook de Indesign se puede seleccionar guardarlo con formato XHTML o DTBook, que incluirá un fichero XML con la compilación DAISY

Se puede consultar un listado de lectores de libros DAISY en el artículo de Xavier Ciscar Presas Daisy en tu PC

Otros enlaces de interés

A lo largo del documento he incluido mucha documentación que recomiendo leer. Otros enlaces de interés son:

Making your information accessible, de RNIB
Accessible ebook creation. Key guidelines on creating accessible ebooks (DOC, 232 KB), de RNIB
Publicación en formatos accesibles Directrices para editoriales: las prácticas más difundidas (Word, 782 KB), Sarah Hilderley
IDPF (International Digital Publishing Forum), web del IDPF que desarrolla y mantiene el formato ePub

Servicios relacionados

Formación y cursos sobre creación de PDF accesibles. Conversión de PDF en PDF accesibles

[1] Michael Koz (18 de mayo de 2011). Amazon to Allow ePub eBooks on the Kindle e-Reader

Sirius. Nuevo sistema para la evaluación de la usabilidad web

2011-07-20T02:14:00.014+02:00

Última actualización: 06/09/2011

Novedad septiembre 2011

Nueva versión de la excel para la evaluación de la usabilidad web según la metodología Sirius.

Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3

Formato: Excel, 87 KB

Licencia: descarga directa. No require aceptación de contrato Coloriuris.

En esta nueva versión el cálculo del porcentaje de usabilidad del sitio evaluado se realiza completamente de forma automática. Ya no es necesario rellenar manualmente la columna relevancia ni es necesario habitar macros.

Las mejoras de esta nueva versión han sido realizadas por Cecilio Sánchez.

Más información sobre la excel

El objetivo de este artículo es doble:

por un lado difundir el nuevo sistema de evaluación de la usabilidad web propuesto por Mª del Carmen Suárez Torrente en su tesis: Sirius: Sistema de Evaluación de la Usabilidad Web Orientado al Usuario y basado en la Determinación de Tareas Críticas (PDF, 3.39 MB) de febrero de 2011
compartir una excel que ayude a evaluar la usabilidad de los sitios web según la nueva metodología: Checklist para la evaluación de la usabilidad web según la metodología Sirius (Novedad: versión 3 de la excel con cálculo completamente automático del porcentaje de usabilidad del sitio evaluado)

¿En que consiste el nuevo sistema de evaluación?

Es un sistema de evaluación de la usabilidad web que parte de la evaluación heurística pero que aúna una serie de características que la diferencia de otras propuestas:

se aplica a cualquier tipo de sitio web
es aplicable durante todo el ciclo de vida del sitio
da como resultado un valor porcentual del nivel de usabilidad del sitio evaluado, un dato por tanto cuantitativo, lo cual permite:
- cuantificar y comparar la mejora de usabilidad de un sitio en el tiempo
- comparar la usabilidad de diferentes portales de un mismo sector o que por ejemplo compitan por un premio de usabilidad
- establecer clasificaciones y rankings en base a la usabilidad
- comparar el nivel de usabilidad obtenido por un sitio en el tiempo con los resultados de las ventas obtenidas por dicho sitio en ese periodo de tiempo. En la tesis se incluye un ejemplo de este tipo, comprobando que efectivamente la mejora de la usabilidad impacta en las ventas y en qué medida.
- determinar la relación entre usabilidad y accesibilidad (si a mayor nivel de accesibilidad el portal consigue un mejor resultado en su valor de usabilidad)
se tiene en cuenta el tipo de sitio evaluado, de manera que la relevancia de los errores está relacionado con el tipo de sitio.
permite inferir los elementos a subsanar en el sitio atendiendo a su prioridad, pudiéndose ordenar por este criterio aquellas mejoras que son críticas.
permite desarrollar una herramienta de evaluación que dé soporte al sistema de evaluación planteado y facilite la validación empírica de la propuesta de evaluación.

Puesto que su propuesta se basa en la evaluación heurística, en el capítulo 3 repasa todas las propuestas de heurísticas y métricas asociadas más relevantes que existen, la de Shneiderman, Nielsen, Constantine, Instone, Tognazzini, etc. indicando por cada una de ellas sus limitaciones, que según cada caso pueden ser:

que no permitan obtener un valor cuantitativo de la usabilidad del sitio
que no proporcionen una relación de items a evaluar asociados a las heurísticas propuestas
que no sean aplicables a cualquier tipo de sitio web
que no tengan en consideración el tipo de sitio evaluado, en función del cual el impacto del incumplimiento de una heurística debería ser diferente

Este repaso constata además que diversos autores han propuesto diferentes conjuntos de heurísticas o principios a través de los cuales realizar la evaluación, lo cuál hace difícil actualmente poder establecer una sistemática en la evaluación.

Clasificación de sitios web

Como he indicado, la evaluación tiene en cuenta el tipo de sitio web, pues la relevancia del cumplimiento o no de un criterio será diferente en función del tipo de sitio.

Por ello realiza una clasificación de sitios web con el objetivo de:

Adaptar los resultados de la evaluación de un sitio a la categoría del mismo, ponderando los valores obtenidos en función del tipo de sitio considerado.
Determinar por cada tipo de sitio las tareas que se consideran críticas y el perfil de usuario más habitual del mismo. De esta manera, se facilita el diseño de las pruebas de evaluación que sería preceptivo realizar con los usuarios del sitio tras la realización de la evaluación heurística propuesta en el trabajo (y una vez subsanados los errores encontrados)

Ante la falta de consenso en las clasificaciones existentes, que repasa en el capítulo 4, elabora una nueva clasificación en base a su funcionalidad (cuya metodología para elaborarla explica en el capítulo 6):

Por cada uno de estos tipos determina su audiencia y las tareas críticas o relevantes en el mismo (páginas 112-115)

Heurísticos y subheurísticos

Se establece una única relación de elementos a evaluar denominados criterios (subheurísticas), agrupados en aspectos (heurísticas) que será utilizada por todos los expertos implicados en el
proceso de evaluación. Con una única relación de elementos a evaluar se consigue unificar los criterios para llevar a cabo una evaluación heurística de un sitio web.

Los heurísticos definidos y sus criterios evaluables son:

Aspectos generales

Elementos relacionados con los objetivos del sitio, el look & feel, coherencia y nivel de actualización de contenidos.

AG1: Objetivos del sitio web concretos y bien definidos
AG2: Contenidos y servicios ofrecidos precisos y completos
AG3: Estructura general del sitio web orientada al usuario
AG4: Look & feel general se corresponde con los objetivos del sitio web
AG5: Diseño general del sitio web reconocible
AG6: Diseño general del sitio web coherente
AG7: Se utiliza el idioma del usuario
AG8:Se da soporte a otro/s idioma/s
AG9: Traducción del sitio completa y correcta
AG10: Sitio web actualizado periódicamente

Identidad e Información

Elementos relacionados con la identidad del sitio, la información proporcionada sobre el proveedor y la autoría de los contenidos.

II1: Identidad o logotipo significativo, identificable y suficientemente visible
II2: Identidad del sitio en todas las páginas
II3: Eslogan o tagline adecuados al objetivo del sitio
II4: Información sobre sitio web, empresa
II5: Existen mecanismos de contacto
II6: Se ofrece información sobre la protección de datos de carácter personal o los derechos de autor de los contenidos del sitio web
II7: Se ofrece información sobre el autor, fuentes y fechas de creación y revisión del documento en artículos, noticias, informes

Estructura y Navegación

Elementos relacionados con la idoneidad de la arquitectura de la información y la navegación del sitio.

EN1: Se ha evitado pantalla de bienvenida
EN2: Estructura de organización y navegación adecuadas
EN3: Organización de elementos consistente con las convenciones
EN4: Control del número de elementos y de términos por elemento en los menús de navegación
EN5: Equilibrio entre profundidad y anchura en el caso de estructura jerárquica
EN6: Enlaces fácilmente reconocibles como tales
EN7: La caracterización de los enlaces indica su estado (visitados, activos)
EN8: Se ha evitado la redundancia de enlaces
EN9: Se ha evitado la existencia de enlaces rotos
EN10: Se ha evitado que haya enlaces que lleven a la misma página que se está visualizando
EN11: En las imágenes de enlace se indica el contenido al que se va a acceder
EN12: Existe un enlace para volver al inicio en cada página
EN13: Hay elementos de navegación que orienten al usuario acerca de dónde está y cómo deshacer su navegación (migas, pestañas coloreadas)
EN14: Existe mapa del sitio para acceder directamente a los contenidos sin navegar

Rotulado

Elementos relacionados con la significación, corrección y familiaridad del rotulado de los contenidos.

RO1: Rótulos significativos
RO2: Sistema de rotulado controlado y preciso
RO3: Título de las páginas, correcto y planificado
RO4: URL página principal correcta, clara y fácil de recordar
RO5: URL de páginas internas claras
RO6: URL de páginas internas permanentes

Layout de la página

Elementos relacionados con la distribución y el aspecto de los elementos de navegación e información en la interfaz.

LA1: Se aprovechan las zonas de alta jerarquía informativa de la página para contenidos de mayor relevancia
LA2: Se ha evitado la sobrecarga informativa
LA3: Es una interfaz limpia, sin ruido visual
LA4: Existen zonas en blanco entre los objetos informativos de la página para poder descansar la vista
LA5: Uso correcto del espacio visual de la página
LA6: Se utiliza correctamente la jerarquía visual para expresar las relaciones del tipo "parte de" entre los elementos de la página
LA7: Se ha controlado la longitud de página
LA8: La versión impresa de la página es correcta
LA9: El texto de la página se lee sin dificultad
LA10: Se ha evitado el texto parpadeante/deslizante

Entendibilidad y facilidad en la interacción

Elementos relacionados con la adecuación y calidad de los contenidos textuales, iconos y controles de la interfaz.

EF1: Se emplea un lenguaje claro y conciso
EF2: Lenguaje amigable, familiar y cercano
EF3: Cada párrafo expresa una idea
EF4: Uso consistente de los controles de la interfaz
EF5: Metáforas visibles reconocibles y comprensibles (ej. iconos)
EF6: Si se usan menús desplegables, orden coherente o alfabético
EF7: Si el usuario tiene que rellenar un campo, las opciones disponibles se pueden seleccionar en vez de tener que escribirlas

Control y retroalimentación

Elementos relacionados con libertad del usuario en la navegación y la información proporcionada al
mismo en el proceso de interacción con el sitio.

CR1: El usuario tiene todo el control sobre la interfaz
CR2: Se informa al usuario acerca de lo que está pasando
CR3: Se informa al usuario de lo que ha pasado
CR4: Existen sistemas de validación antes de que el usuario envíe información para tratar de evitar errores
CR5: Cuando se produce un error, se informa de forma clara y no alarmista al usuario de lo ocurrido y de cómo solucionar el problema
CR6: Se ha controlado el tiempo de respuesta
CR7: Se ha evitado que las ventanas del sitio anulen o se superpongan
a la del navegador
CR8: Se ha evitado la proliferación de ventanas en la pantalla del usuario
CR9: Se ha evitado la descarga por parte del usuario de plugins adicionales
CR10: Si existen tareas de varios pasos, se indica al usuario en cual está y cuantos faltan para completar la tarea

Elementos multimedia

Elementos relacionados con el grado de adecuación de los contenidos multimedia al sitio web.

EM1: Fotografías bien recortadas
EM2: Fotografías comprensibles
EM3: Fotografías con correcta resolución
EM4: El uso de imágenes o animaciones proporciona algún tipo de valor añadido
EM5: Se ha evitado el uso de animaciones cíclicas
EM6: El uso de sonido proporciona algún tipo de valor añadido

Búsqueda

Elementos relacionados con el buscador implementado en el sitio web.

BU1: Si es necesaria, se encuentra accesible desde todas las páginas del sitio
BU2: Es fácilmente reconocible como tal
BU3: Se encuentra fácilmente accesible
BU4: La caja de texto es lo suficientemente ancha
BU5: Sistema de búsqueda simple y claro
BU6: Permite la búsqueda avanzada
BU7: Muestra los resultados de la búsqueda de forma comprensible para el usuario
BU8: Asiste al usuario en caso de no poder ofrecer resultados para una consultada dada

Ayuda

Elementos relacionados con la ayuda ofrecida al usuario durante la navegación por el sitio.

AY1: El enlace a la sección de Ayuda está colocado en una zona visible y estándar
AY2: Fácil acceso y retorno al/del sistema de ayuda
AY3: Se ofrece ayuda contextual en tareas complejas
AY4: FAQs (si la hay), es correcta tanto la elección como la redacción de las preguntas
AY5: FAQs (si la hay), es correcta la redacción de las respuestas

Métrica de evaluación

A la hora de valorar un criterio se establecen dos tipos de valores de medición (se aplica uno u otro según las características de cada criterio):

una escala de 0-10 que indica el grado de conformidad del evaluador con el cumplimiento del criterio. Se propone una escala proporcional a la que será el resultado de la métrica de evaluación del sitio (un valor comprendido entre 0-100) indicando nula o máxima usabilidad.
un valor textual, que indica si el criterio se cumple o no y en qué extensión del sitio web se detecta el problema en el caso de que el criterio no se cumpla. Este valor lo asigna el evaluador pero, a efectos de cómputo, se aplica el mismo intervalo de medición (de 0-10):
- NTS: no se cumple en todo el sitio (valor de 0)
- NEP: no se cumple en los enlaces principales (valor de 2.5)
- NPP: no se cumple en la página principal (valor de 5)
- NPI: no se cumple en alguna página interior (valor de 7.5)
- S: se cumple el criterio (valor de 10)
- NA: criterio no aplicable en el sitio

En las páginas 134 y siguientes se incluye la relación completa de aspectos, criterios y elementos de evaluación para llevar a cabo la evaluación. Por ejemplo, la tabla para el heurístico “Aspectos generales” sería:

Para la obtención de la medida cuantitativa del nivel de usabilidad y la indicación de la urgencia o prioridad en la mejora de los criterios en los que se ha detectado el fallo, se determinan los
valores de severidad de los aspectos y los criterios en función de los diferentes tipos de sitios considerados en el sistema de evaluación.

Este nivel de severidad es un indicador del nivel de importancia que tiene el incumplimiento de un criterio; al contrario que en otras propuestas NO es el evaluador el que asigna éste valor a la heurística revisada; en esta propuesta el evaluador únicamente se ocupa de cuantificar el incumplimiento, no la severidad o relevancia del mismo.

La relevancia de los aspectos (heurísticas), en función del tipo de sitio se pueden consultar en la tabla de la página 123 y se clasifican en muy alta, alta, media y baja.

La relevancia de los criterios (subheurísticos) en función del tipo de sitio se pueden consultar en las tablas de las páginas 125-131. Se clasifican en:

crítica (CR): el problema identificado es severo. El usuario no podrá completar la tarea y podría no desear seguir utilizando el sitio Web.
mayor (MA): es posible que el usuario complete la tarea pero tendrá mucha dificultad, frustración o incluso tendrá que ejecutar muchos pasos innecesarios. Podrá superarlo después de que se le haya mostrado cómo hacerlo.
media (ME): en la mayoría de casos, el usuario podrá completar la tarea, realizando un moderado esfuerzo para evitar el problema. Pueden necesitar investigar algunos enlaces para determinar que opción les permitirá completar la tarea propuesta. En navegaciones posteriores del sitio, los usuarios probablemente recordaran cómo ejecutar la tarea.
moderada (MO): el problema ocurre de manera intermitente y puede ser fácilmente superado, aunque es irritante para el usuario. Debido principalmente a problemas estéticos.

El valor de relevancia de los aspectos matizará los resultados de la evaluación, de manera que ante dos criterios de igual criticidad, será la relevancia del aspecto al que pertenecen la que determine cuál de ellos será prioritario en su arreglo.

Por último, la fórmula para obtener el valor cuantitativo considera los siguientes conceptos:

Factor de corrección: valor de ajuste que se aplica a cada uno de los criterios evaluados con el fin de obtener diferentes niveles de usabilidad dependiendo de la relevancia de los mismos en función del tipo de sitio web en evaluación. Los valores resultantes al aplicar este factor de corrección debieran llevar a obtener valores de usabilidad comprendidos siempre entre 0 y 100, por tratarse de un porcentaje.
Cálculo del Factor de Corrección: partiendo de los valores correspondientes a los diferentes niveles de relevancia de un criterio, el factor de corrección se calcula dividiendo cada valor de relevancia entre la suma de todos los valores de relevancia de los criterios evaluados.

La fórmula es la siguiente:

nce: número de criterios evaluados. Será como máximo 83, que son los propuestos en este sistema de evaluación. Se considera que alguno de los criterios pueda no ser aplicable al sitio en evaluación y, por lo tanto, no se evalúe.
vc: Valor de evaluación de un criterio (entre 0 y 10).
fc: Factor de corrección aplicado al criterio evaluado. El valor del factor de corrección de cada uno de los criterios evaluados se obtiene de la siguiente manera:

rc : Valor de relevancia que corresponde a un criterio

En este gráfico se resume el sistema de evaluación Sirius:

Herramienta de soporte al sistema de evaluación

La aplicación web que ha desarrollado Mª del Carmen Suárez Torrente como soporte al proceso de evaluación se llama Prometheus y entre sus características destacan:

presenta los criterios a chequear
proporciona el porcentaje de usabilidad obtenido por el sitio
proporciona la relación de criterios a mejorar ordenados por su prioridad, de manera que el primero de la lista es el que mayor incremento de la usabilidad proporcionará
permite visualizar los valores asignados por los evaluadores a cada uno de los criterios evaluados así como las observaciones realizados por los mismos durante el proceso de evaluación.
obtener un informe en formato EARL

Tiene gestión de usuarios, gestión de sitios (un dato básico es el tipo de sitio, que puede ser hibrido), consulta de los resultados de evaluaciones previas, etc.

Mientras la aplicación no sea pública, he preparado una excel para facilitar la aplicación de la metodología Sirius en la evaluación de la usabilidad web.

Excel para ayudar a la evaluación de usabilidad según la metodología Sirius

Se puede descargar de forma gratuita en: Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3 (Excel, 87 KB)

Las mejoras de esta nueva versión han sido realizadas por Cecilio Sánchez.

Versiones anteriores:

Versión 2 (27.07.11): Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 2
Versión 1 (20.07.11): Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 1

Descripción general de la Excel

La excel está compuesta por diferentes pestañas:

Datos del sitio: en esta pestaña se rellenan los datos generales de la evaluación y del sitio evaluado. El dato "Tipo del sitio" se selecciona de un desplegable. Son los tipos de sitio definidos por la metolología Sirius, la relevancia de los criterios a evaluar dependerá del tipo de sitio que se indique.
Pestaña de la 2-11: hay una pestaña por cada heurístico. En cada una se enuncian los criterios a evaluar. El evaluador debe valorar cada criterio seleccionando las opciones disponibles en la columna "Valor". Estas opciones son las definidas por la metodología y se seleccionan de un desplegable, cuya leyenda puede consultarse en cada pestaña. No debe rellenarse ningún campo más, el resto de valores se calculan automáticamente. Sí se pueden añadir comentarios a cada criterio. Se recomienda poner la referencia a un documento de texto externo donde se expliquen y se documenten.
Pestaña "Cálculo de % de usabilidad": una vez valorados los criterios de los 10 heurísticos se puede consultar en esta pestaña la puntuación que ha obtenido el sitio.
Las pestañas "Tabla de relevancia" y "Valores" sólo contienen datos para los cálculos del porcentaje de usabilidad.

Las limitaciones, frente a lo que sería la aplicación, serían:

no genera el informe EARL
no proporciona la relación de criterios a mejorar ordenados por su prioridad
está orientado a un único evaluador y por tanto no permite comparar las evaluaciones de varios evaluadores

La autora me ha confirmado que se encuentra desarrollando la nueva versión de la aplicación web.

Últimos artículos

Servicios relacionados

Consultoría de usabilidad web: evaluación heurística.

Arquitectura de información. Fundamentos

2011-07-14T11:30:00.005+02:00

Arquitectura de información, usabilidad, accesibilidad… todas ellas son disciplinas diferentes aunque íntimamente relacionadas, englobadas en una macrodiscisciplima denominada Experiencia de usuario (UX) que aglutina la arquitectura de información y la mayoría de las disciplinas cercanas a ella [1].

El objetivo de este artículo es introducir los fundamentos de la arquitectura de información (AI), es decir, los principios y cimientos de la disciplina. Para estructurar el contenido he tomado como guión uno de los mejores libros que existen sobre el tema “Arquitectura de información en entornos web” de Mario Pérez-Montoro Gutiérrez (Pérez-Montoro, 2010).

Para los que ya lo han leído, este artículo puede servir de esquema resumen. A los demás os animo a leerlo, pues en él se desarrollan en profundidad todos los apartados con gran rigor y muy bien documentados.

¿Qué es la arquitectura de información?

Disciplina (arte y ciencia) encargada de estructurar, organizar y etiquetar los elementos que conforman los entornos informacionales para facilitar de esta manera la localización (o el acceso) de la información contenida en ellos y mejorar, así, su utilidad y su aprovechamiento por parte de los usuarios (Pérez-Montoro 2010).

El arquitecto de información es la persona que debe identificar la misión (los objetivos) y la visión (las expectativas de los usuarios) de la pagina web, determinar los contenidos y funcionalidades de la página, facilitar el acceso mediante sistemas de organización, etiquetado, navegación y búsqueda y planificar en previsión de futuras modificaciones y crecimiento de la página (Morville y Rosenfeld, 1998)

Durante la fase de “estrategia” identifica los objetivos, en la fase de “alcance” las necesidades de los usuarios, en la fase de “estructura” especifica las funcionalidades y requerimientos de la web, en la fase de “esqueleto” el diseño de los sistemas de navegación, organización, etiquetado y búsqueda y en la fase de “interfaz” prototipa la página (Garret, 2003)

Tipos de necesidad de información

El objetivo habitual de un usuario al acceder a una web es satisfacer una necesidad de información y/o realizar una transacción (por ejemplo comprar un billete de tren). Desde el punto de vista de las necesidades informativas, se pueden distinguir tres tipos:

Necesidad de información concreta (NIC): por ejemplo, “¿qué precio tiene este producto?”
Necesidad de información orientada a problemas (NIOP), por ejemplo, “¿cuál es la relación entre la usabilidad y la arquitectura de información?”
Necesidad de información exploratoria (NIE), por ejemplo “quiero escoger un buen hotel para este fin de semana”
Necesidad de información sobre búsquedas previas (NIBP), es decir, localizar información que ya había localizado previamente.

Las estrategias de las que dispone un usuario para satisfacer estas necesidades de información en una página web son:

Búsqueda, utiliza la caja de búsqueda y analiza e interacciona con los resultados.
Navegación, explora a partir de los enlaces de la web.
Ayuda, por comodidad o desesperación reclama que se le oriente y señale dónde se encuentra el contenido.

El usuario utiliza una de estas estrategias - o una combinación de ellas- para localizar información que asimila y evalúa para así reformular o refinar su necesidad de información, hasta que considera que ha quedado resuelta. Es lo que se conoce como el modelo berrypicking o recolección de bayas (Bates, 1989). Ver también modelo pearl-growing

Componentes o anatomía de la arquitectura de información

Una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la vistan y consultan (Morville y Rosenfeld, 2006)

Los sistemas, estructuras o recursos para estructurar una web y que definen la AI de un sitio se llaman componentes o anatomía de la arquitectura de información y son los siguientes:

Sistemas de organización
Sistemas de etiquetado
Sistemas de navegación
Sistemas de búsqueda
Vocabularios o lenguajes documentales

Todos ellos son los responsables en gran de media de la findability de la página y los contenidos que alberga.

Sistemas de organización

Dependiendo de cómo organicemos la información contenida en una web lograremos que los contenidos que alberga sean más fáciles de encontrar por los usuarios. Para hacer un diseño adecuado del sistema de organización es necesario desarrollar correctamente los componentes que lo conforma:

Esquemas de organización: sistemas que organizan los grupos de ítems de información contenidos en una página web en grupos a partir de un criterio concreto:
- Exactos: grupos bien definidos y mutuamente excluyentes, sirven para conocer cosas previamente conocidas:
  - Alfabéticos
  - Cronológicos
  - Geográficos
- Ambiguos, para localizar contenidos que no conocemos:
  - Tema
  - Tarea
  - Audiencia
  - Metáfora, de la que no hay que abusar, pues si no está bien desarrollada su alta ambigüedad desorienta al usuario.
  - Híbrido, utilización de varios de los esquemas anteriores.
Estructuras de organización: sistemas que organizan los grupos de ítems de información resultantes de los esquemas mostrando las dependencias lógicas que existen entre ellos:
- Estructura jerárquica, una buena arquitectura de información incluye una jerarquía o taxonomía entre sus componentes. Permiten al usuario ubicarse y obtener un modelo mental de la estructura del sitio que visita:
  Consejos:
  - Diseñarla teniendo en cuenta a los usuarios.
  - Las opciones principales deben estar siempre visibles.
  - Combinarla con los otros tipos de estructuras para ofrecer al usuario flexibilidad a la hora de localizar la información.
  - Las categorías que la conforman deben ser mutuamente excluyentes. Si muchos contenidos pertenecen a varias categorías la taxonomía termina perdiendo su valor para localizar la información.
  - Sobre la anchura (nº de ítems al mismo nivel) y profundidad de la estructura (niveles de división verticales) recomendada se han escrito ríos de tinta [2]
  - Definir la estructura pensando en la escalabilidad del portal, que sea posible incluir nuevas categorías sin modificarla sustancialmente, sin provocar cambios en la imagen mental que tiene el usuario que ya la ha visitado y sin tener que introducir modificaciones visuales en la home.
- Basada en registros (o en el modelo de base de datos), idóneo para los contenidos bien estructurados y homogéneos
- Estructura hipertextual (o en red), que debe ser complemento de otros tipos de estructuras y no la única opción de organización de la información. Permite reflejar relaciones menos estructuradas y más creativas existentes entre los contenidos.
- Estructura secuencial, con un principio y un final claro y un único itinerario de consulta o exploración
- Estructura en tabla (o matriz), sólo para aquellos contenidos que admitan su representación en una tabla, y debe ser utilizado en combinación con otras estructuras.

Algunos problemas que debemos resolver al diseñar el sistema de organización son:

La ambigüedad del propio lenguaje lingüístico.
La heterogeneidad de los contenidos.
Las diferentes perspectivas, siendo imprescindible tener en cuenta a nuestro público objetivo.
Los intereses de la organización, que es necesario conocer a fondo.

El mejor consejo es que, dependiendo del contexto y los usuarios, elegir y articular aquellos sistemas que sean realmente útiles, intentando simultanear esquemas exactos y ambiguos para ofrecer al usuario diferentes vías para acceder y localizar la información. La combinación de diferentes estructuras, si se combinan adecuadamente, permiten obtener un sistema sólido, coherente y flexible.

Sistemas de etiquetado

A la hora de definir el sistema de etiquetado debemos tener cuidado con:

La ambigüedad intrínseca al lenguaje, tanto sintáctica, léxicas (sinonimia y polisemia) como semántica (uso de metáforas, ironía, etc.)
La arbitrariedad, evitando utilizar términos con un significado diferente con el que normalmente se asocian.
La desorientación que producen las etiquetas que no anticipan ni dan pista sobre lo que esconden.
Las etiquetas que utilizamos se asociación al branding de la empresa, y unas etiquetas mal elegidas pueden dar una mala impresión de la misma.

Todo ello puede suponer que el usuario abandone la página porque no encuentra lo que necesita.

Las etiquetas pueden ser textuales o icónicas, estas deben utilizarse siempre junto a las primeras porque son intrínsecamente ambiguas.

Los sistemas de etiquetado con formato textual que deben planificarse son:

Enlaces contextuales. Deben identificarse visualmente como tales, diferenciar los que sean externos y utilizarse de forma consistente. No deben ser ambiguos y se debe tener en cuenta el contexto en el que se insertan, siendo además independientes del mismo.
Títulos. Deben estructurar coherentemente el contenido y su diseño debe reflejar su jerarquía. Tienen que ser descriptivos y coherentes con los literales utilizados en los otros sistemas de etiquetado. Deben ser consistentes a lo largo del sitio tanto en su ubicación como en su aspecto.
Opciones del sistema de navegación. Deben ser consistentes y coherente siguiendo un mismo patrón visual y de ubicación a lo largo de todo el sitio. Deben describir adecuadamente los contenidos que incluyen y ser entre ellos lo más excluyentes posibles.
Términos de indización. Son el conjunto de etiquetas utilizadas para describir cualquier tipo de contenido en un entorno web y facilitar su localización, búsqueda y recuperación. Su enlace permite acceder al listado de todos los contenidos indizados con ese término y además alimentan el índice inverso del sistema de búsqueda. Cuando los propios usuarios o los autores de los contenidos proponen las etiquetas (tag) hablamos de marcadores sociales. Una folksonomía es el resultado de la agregación de las etiquetas o tags propuestos por uno más usuarios. Se pueden visualizar en forma de listado, nubes de etiquetas, los más populares, etc.

Consejos y recomendaciones

Acotar el significado de las etiquetas teniendo en cuenta a los usuarios.
Diseñar el sistema de etiquetado de forma global y no etiquetas de forma aislada.
Mantener la consistencia tanto en el literal como en el formato.
Usar el mismo registro: si usas “linfoma” no uses “dolor de cabeza” sino “cefalea”.
Reconocibles por ser conceptos familiares, el usuario no debe tener que aprender su significado.
Utilizar estrategias para desambiguar las etiquetas, por ejemplo mediante el contexto (acompañada de otros elementos similares; mediante un texto que la acompañe, etc.)

Orientaciones metodológicas

Crear una tabla con tres columnas: etiqueta, explicación de la etiqueta y contenido que representa, para detectar inconsistencias y duplicidades.
Involucrar a los autores de contenidos.
Involucrar a los usuarios con pruebas de cardsorting.
Ver cómo etiquetan nuestros contenidos los usuarios por ejemplo en Del.icio.us
Analizar los términos que utilizan los usuarios en el buscador de nuestra web.
Aprovechar tesauros y vocabularios controlados ya existentes que podamos adaptar y refinar, pero siempre deben coincidir con nuestra audiencia.

Sistemas de navegación

Son estructuras que ordenan y agrupan los contenidos de una página web bajo unas categorías que forman una clasificación. Nos permiten:

Identificar las relaciones entre los contenidos de la web y entre esos contenidos y la página que se está visitando en ese momento.
Habilitar y facilitar la navegación entre esos contenidos
Orientarnos, saber dónde estamos, que hay aquí, de dónde venimos y cómo podemos ir hacia donde deseamos ir.
Formar una imagen mental del tamaño y estructura del sitio.

Los usuarios pueden navegar de formas muy distintas: con dirección, cuando buscan una información determinada, sin dirección, cuando ojean la web sin un objetivo claramente preestablecido, además puede navegar en amplitud o en profundidad.

Tipos de sistemas de navegación

Sistemas básicos
- Sistemas integrados
  - Sistemas constantes (o globales)
  - Sistemas locales, deben estar correctamente articulados con el sistema constante.
  - Sistemas contextuales, que permiten identificar contenidos relacionados y enlazar con ellos. Es importante que los contenidos o páginas críticas se enlaces desde otros contenidos.
  Se deben articular estos tres sistemas sin saturar de enlaces y sin que ocupen todo el espacio de la página. Deben situarse de forma consistente, fija y diferenciada entre ellos.
- Sistemas complementarios, son recursos para localizar información y para orientarse que suelen ser páginas propias e independientes.
  - Mapa del sitio
  - Índices, listado de términos que representan el contenido del sitio, normalmente ordenados alfabéticamente
  - Guías, para introducir a los nuevos usuarios en los contenidos y la funcionalidad de una parte concreta del sitio: wizards, configuradores, visitas guiadas, tutoriales, etc.
Sistemas no básicos
- Sistemas de personalización, estructuras de navegación proactivas que se autodiseñan en función de lo que espera el usuario, ofreciéndole enlaces a partir de su perfil. El principal problema es que los comportamientos pasados no son garantía de inferir sus comportamientos futuros.
- Sistemas de customización: estructuras reactivas que permiten que el usuario pueda diseñar su propio sistema de navegación. El principal problema es que a los usuarios les pasen desapercibidas estas opciones, que si sus necesidades cambian deben redefinirlas o que simplemente no tengan tiempo de hacerlo.
- Sistemas de navegación visual, permiten explorar usando recursos icónicos o visuales.
- Sistemas de navegación social, inferidos a partir del comportamiento de la mayoría de usuarios que visitan la página (lo más popular, lo más comprado, etc.)

Recomendaciones

Utilizar recursos de contextualización que permitan al usuario saber dónde se encuentra, adónde puede ir y la relación del contenido con el resto del sitio: incluir siempre el logo de la organización, marcar visualmente las opciones de menú donde nos encontramos, incluir migas de pan, etc.
No anular funcionalidades del navegador. Al posicionar el cursor sobre un enlace la URL debe verse en el pie del navegador; no eliminar las barra de menú del navegador al abrir una ventana nueva; no impedir al usuario que utilice el menú contextual del botón derecho; no impedir que la página muestre el scoll cuando sea necesario; permitir que los enlaces visitados cambien de color, etc.
Diseño de navegación: incluir siempre un mapa web. Si se usan menús desplegables es mejor que se desplieguen al activarlos y se mantengan desplegados (Chaparro, Minnaert y Phipps, 2000).

Sistemas de búsqueda

Utilizados normalmente para localizar información a partir de una necesidad concreta. Ofrecen los resultados que coinciden con los definidos por el usuario en la ecuación de búsqueda. Los problemas a superar son:

Ruido: contenidos recuperados no pertinentes, se mide con el índice de precisión.
Silencio: documentos pertinentes no recuperados, se mide con el índice de exhaustividad.

Los sistemas de búsqueda pueden ser:

Reactivos: reaccionan frente a la conducta informativa del usuario.
Proactivos: ofrecen proactivamente la información al usuario sin que tenga que reclamarla continuamente:
- Sistemas de difusión selectiva de información (DSI), ofrecen una actualización informativa automatizada sobre un tema concreto a partir de la sindicalización de contenidos.
- Sistemas de workshop, suministran automáticamente la información dentro de un proceso a partir del perfil del usuario.
- Agentes inteligentes: infieren el perfil de interés informacional de un usuario a partir de criterios como su histórico de comportamiento o su similitud con el de otros usuarios.
RSS, es reactivo porque has de suscribirte y proactivo porque desde ese momento los recibes automáticamente.

Recomendaciones

Evaluar la necesidad de un vocabulario controlado y definir los metadatos implicados en su descripción.
Seleccionar como términos de indización ciertos componentes de los contenidos (título, url, etiquetas de los enlaces o títulos de las imágenes)
Si se indiza el texto completo de todos los contenidos, introducir recursos como la búsqueda por campos para refinar el resultado y evitar una tasa de ruido elevada.
Evaluar si se indiza sólo algunos contenidos, algunas zonas de esos contenidos o algunos componentes determinados de ellos.
Indizar los contenidos según el tipo de usuario o audiencia al que va dirigido.
Inferir patrones en el comportamiento de los usuarios.
Tratar de indizar las páginas según el tipo de contenido.
Incluir siempre que se pueda:
- corrector ortográfico: corrigen automáticamente la ortografía dando alternativas.
- herramientas fonéticas: para identificar términos con grafías diferentes pero fonéticamente idénticas
- herramientas de procesamiento del lenguaje natural: obvian las palabras vacías e introducen AND entre los términos propuestos.
- en función del proyecto, evaluar la inclusión de sugerencias de términos en la caja de búsqueda, que se va adaptando a lo que se escribe y que permiten identificar las búsquedas con más resultados.
Poder refinar y mejorar manualmente los resultados de las búsquedas más habituales.
Formar a los autores del contenido sobre cómo deben redactar los títulos o etiquetar el contenido.
La caja de búsqueda debe estar identificada como tal y cerca del sistema de navegación.
Diseñar la interfaz de búsqueda teniendo en cuenta a los usuarios, el tipo de necesidad informativa, la cantidad de información recuperada y el tipo de contenidos a recuperar.
En la página de resultado:
- indicar los términos por los que se ha buscado
- indicar el número de resultados mostrados y encontrados
- poner en negrita las coincidencias
- permitir refinar la búsqueda (no solo semánticamente sino por fecha, lengua, tipo de documento, etc.)
- permitir realizar búsquedas sólo en los resultados.
- permitir personalizar el número de resultados a mostrar.
- poder imprimir o enviar por email los resultados
- poder guardar la búsqueda, para ello es necesario que sea mediante GET para que tenga una URL propia.
- ofrecer opciones de ordenación (por precio, por relevancia, por cronología, etc.)

Vocabularios o lenguajes documentales

La indización es la operación en la que se asigna a cada contenido una serie de términos (palabras clave) que representan el tema o temas sobre los que versa. Es una operación de análisis. La clasificación es la operación por la cual se asigna a cada contenido un único término que representa el tema principal sobre el que versa ese documento. Es una operación de síntesis.

La información resultante de la indización y la clasificación suele incorporarse al contenido mediante metadatos asociados para que funcione con los sistemas de organización, etiquetado, navegación y búsqueda.

Un lenguaje documental se constituye a partir de un subconjunto de términos del lenguaje natural (acompañados a veces de números como en el caso de las clasificaciones) para facilitar la búsqueda y recuperación de la información contenida en los documentos.

Aunque el uso de un lenguaje documental reduce el ruido y el silencio en las búsquedas, su construcción y mantenimiento lleva asociado un coste de personal y de tiempo importante, además de que hay que asegurar que se hace correctamente. Por ello hay que evaluar con criterio la necesidad de ese esfuerzo y su viabilidad.

Un lenguaje documental está formado por:

El vocabulario del lenguaje documental: subconjunto del lenguaje natural. Se distingue:
- el término de indización principal (descriptor): es unívoco. Identifica la representación estándar de ese concepto. Por ejemplo, “sacerdote”.
- término de indización secundario: es sinónimo del principal y una buena representación del concepto que el primero también representa, pero se decide no identificarlo como la representación estándar. Por ejemplo: “cura”, “clérigo”
Relaciones semánticas entre los términos de indización, que pueden ser de:
- Equivalencia: sinónimos, acrónimos, abreviaciones, variantes léxicas, posibles errores ortográficos, cuasisinónimos.
- Jerarquía, que puede ser:
  - Genérica: soltero-hombre
  - Relación parte-todo: rueda-coche
  - Relaciones de instanciación: Mediterráneo-mar
- Asociativa: por afinidad semántica o evocación. Por ejemplo, veneno-toxicidad.

Tipos de lenguajes documentales

Libres, por ejemplo extraer automáticamente de un texto las palabras que no pertenecen al fichero de palabras vacías.
Controlados:
- Anillos de sinónimos, entre los términos se establecen relaciones de equivalencia pero no de jerarquía ni de asociación. Al hacer una búsqueda se recuperan también los indexados por sus sinónimos. Reduce el silencio en las búsquedas pero aumenta el ruido.
- Fichero de autoridades, listado de términos principales (con sus respectivos sinónimos) para describir y normalizar un conjunto de entidades (personas, organizaciones, lugares geográficos) ante la variedad de homónimos, sinónimos o nombres con los que puede ser denominada una persona, entidad, obra, tema o concepto. Se utiliza especialmente en la catalogación de los fondos de las bibliotecas.
- Lista de encabezamientos de materia (LEM), en el cual el encabezado condensa el tema del documento con uno o varios términos. Presentan relaciones asociativas, jerárquicas y de equivalencia. Se usan preferentemente en las bibliotecas y en los centros de documentación cuyos fondos son esencialmente enciclopédicos.
- Taxonomías, sus términos presentan relaciones de equivalencia y jerarquía pero no asociativas.
- Clasificación, representa entre sus términos relaciones asociativas, jerárquicas y de equivalencia y algunas veces asocia un código identificativo a cada uno de sus términos.
  La más utilizada en web es la clasificación facetada para poder clasificar simultáneamente desde distintos puntos de vista, o a partir de diferentes criterios, un mismo conjunto de objetos.
  Cada una de las clasificaciones o facetas es paralela a las demás en un mismo nivel semántico. Cada faceta sería una etiqueta del sistema de navegación global, o un campo de la base de datos; y las categorías de esa faceta serían las de uno de los sistemas de navegación local, o las de los posibles valores de un campo de la base de datos. Por ejemplo, cada faceta seria (corriente literaria, género literario, etc.) y las categoría (realismo, modernismo,…; novela, poesía,…).
- Tesauro, se encuentran integrados en los sistemas de navegación y búsqueda. Sus términos presentan relaciones asociativas (términos relacionados, TR), jerárquicas (términos genéricos, TG y términos específicos, TE) y de equivalencia.

En este apartado recomiendo también la lectura de dos artículo de Yusef Hassan Montero:

Bibliografía

BATES, M.J. (1989): “The Design of Browsing and Berrypicking. Tecniques for the Online Search Interfaces”, Online Reviews, vol. nº3, pp. 407-424

CHAPARRO, B., G.MINNAERTS y C.PHIPPS (2000): “Limitations of Using Mouse-Over with Menu Item Selection”, Human Factors and Ergonomics Society Annual Meeting Proceedings

GALLETTA, D., R. HENRY, S.McCOY y P.POLAK (2006), “When the Wait isn’t So Bad: The Interacting Effects of Website Delay, Familiarity, and Breadth”, Information Systems Research, vol. 17, núm. 1, pp. 20-37”

GARRET, J. (2003): The Elements of User Experience. User-Centered Design for the Web, Nueva York: American Institute of Graphic Arts

JACKO, J.A y G. SALVENDY (1996): “Hierarchical Menu Design: Breadth, Depth and Task Complexity”, Perceptual and Motor Skills, vol. 82, pp. 1187-1201

KRUG, S (2000): Don’t Make Me Think: A Common Sense approach to Web Usability, Indianápolis (Indiana): New Riders

MORVILLE, Peter y ROSENFELD, Louis (1998): Information Architecture for the World Wide Web, Sebastopol (California): O’Reilly Media Inc.

- (2006): Information Architecture for the World Wide Web, 3ª edición, Sebastopol (California): O’Reilly Media Inc.

MILLER, D.P (1981): “The Depth/Breadth Tradeoff in Hierarchical Computer Menus”, Proceedings of the Human Factors Society 25^TH Annual Meeting, pp. 296-300

MILLER, C. y R.REMINGTON (2002): “Effects of Structure and Label Ambiguity on Information Architecture”, Conference on Human Factors in Computing Systems, pp. 630-631

- (2004): “Modeling Information Navigation: Implications for Information Architecture”, Human-Computer Interaction, vol. 19, núm.3, pp. 225-271

PEREZ-MONTORO, Mario (2010): Arquitectura en entornos web, Gijón: Ediciones Trea

SNOWBERRY, K., S. PARKINSON y N. SISSON (1983): “Computer Display Menus”, Ergonomics, vol. 26, núm.7, pp. 699-712

[1] Consultar "Disciplinas relacionadas con la usabilidad"

[2] Miller, 1981 indica que el máximo de enlaces que retenemos mentalmente cuando navegamos es de 7.

Pero Krung, 2000 defiende que el número de enlaces que recordamos depende de lo que se tenga que recordar. Lo importante es utilizar etiquetas adecuadas al nivel cultural y profesional de los usuarios y discriminar visualmente lo principal de lo secundario.

Porter, 2003 demostró que la regla de los 3 clics es falsa y por tanto no debe fundamentarse en ella la selección de jerarquías anchas y poco profundas, pues lo importante es que cada clic sea significativo y no ambiguo (Krug 2000). Hay que tener en cuenta que las jerarquías muy anchas y poco profundas exigen un mayor esfuerzo cognitivo del usuario para elegir entre todas las opciones del mismo nivel, mientras que las jerarquías estrechas exigen menor esfuerzo cognitivo al tener que elegir entre pocas opciones, de modo que a medida que se avanza, se van desambiguando y da sensación de ser una web menos compleja (ver modelo modelo pearl-growing).

Miller, 1981 defiende que hay que buscar un equilibrio entre la anchura y la profundidad de la estructura. Si el usuario se encuentra demasiadas opciones en el menú principal, en una jerarquía muy ancha y poco profunda, tiene la sensación de escasez de contenido, y si es muy profunda puede sentirse perdido.

Snowberry, Parkison y Sisson, 1983 defienden las jerarquías anchas. Las profundas reclaman mayor memoria a corto plazo, y las anchas transmiten más sensación de orientación, aunque exigen mayor habilidad de análisis visual para identificar las correlaciones semánticas entre los contenidos categorizados.

Galletta, Henry, McCoy y Polak, 2006 defienden las estructuras planas cuando la web es lenta, concluyendo que lo importante realmente es la familiaridad de los contenidos que es lo que más reduce el tiempo de localizar la información.

Jacko y Salvendy, 1996 especifican que el tiempo para completar un tarea aumenta tanto en estructuras anchas como profundas (en este caso más) pero que minimizar la profundidad reduce la percepción de complejidad.

Si la ventaja de las jerarquías anchas es la sensación de orientación, Miller y Remington, 2002, 2004 defienden que un buen sistema de etiquetado no ambiguo en una estructura profunda alteraría la máxima de que las planas son más eficientes, que completaría la tesis de Galletta, Henry, McCoy y Polak, 2006 de que los efectos negativos de la estructura ancha se mitigan con se establece una relación de familiaridad con sus contenidos.

Últimos artículos

Servicios relacionados

Análisis de interfaz (AI & UX): Arquitectura de información. Diseño de interacción. Prototipado. Experiencia de usuario.

PDF Techniques for WCAG 2.0

2011-07-07T12:37:00.024+02:00

Última actualización 11 de enero de 2012

Lo primero que hay que advertir es que el documento PDF Techniques for WCAG 2.0 es de momento un documento de trabajo del WCAG WG. Por tanto, las técnicas PDF de las WCAG 2.0 no están incluidas por ahora en el documento Tecniques for WCAG 2.0, como por ejemplo sí lo están las técnicas Flash (ver mi artículo Checklist para validar contenido Flash de acuerdo con las WCAG 2.0)

Desde el 3 de enero de 2012 las técnicas PDF de las WCAG 2.0 están incluidas en el documento Tecniques for WCAG 2.0, tal y como lo están, por ejemplo, las técnicas para contenido Flash (ver mi artículo Checklist para validar contenido Flash de acuerdo con las WCAG 2.0). Durante el 2011, las técnicas PDF para cumplir con las WCAG 2.0 solo eran un documento de trabajo y no estaban incluidas en el documento Tecniques for WCAG 2.0.

Si no sabes muy bien qué son las WCAG 2.0 o sus técnicas asociadas te recomiendo que comiences leyendo el artículo WCAG 2.0

Si te estás introduciendo en el tema de la accesibilidad en ficheros PDF, te recomiendo que primero te leas los artículos PDF accesibles y PDF accesibles 2: Metodología

A continuación enumero las 23 técnicas y os doy una serie de consejos prácticos para cada una. La información que incluyo en cada técnica no es un resumen de lo que se dice en el documento (al cual os remito siempre) sino una serie de recomendaciones fruto de la experiencia. El título de cada una de las técnicas os llevará a su descripción en la documentación de las WCAG 2.0

Podéis consultar el índice de la técnicas en PDF Techniques for WCAG 2.0.

Nota para mis ex-alumnos: veréis que todas las técnicas se tratan en los pasos que explico en la metodología a seguir, es importante que se siga el orden de la metodología y no el orden de las técnicas.

PDF1: Applying text alternatives to images with the Alt entry in PDF documents

Asociado al criterio de conformidad 1.1.1 de nivel A

Se debe aplicar el mismo criterio que en web, es decir, sólo deben tener texto alternativo las imágenes que NO son decorativas. Nunca podremos considerar que una imagen es decorativa si es un enlace o si tiene texto (a no ser que sea decorativo)

En web recomendamos que las imágenes decorativas estén definidas en la CSS, el equivalente en un documento PDF es que se conviertan en artifacto para que no sean leídas por el lector de pantalla.

Al igual que en web, el texto alternativo de las imágenes debe proporcionar la misma información que la imagen, pero en este caso no disponemos del atributo LONGDESC, así que toda la información alternativa deberá incluirse en el campo "Texto alternativo" de la etiqueta Figure correspondiente. Es muy importante no incluir como imagen aquel contenido que podría maquetarse sin necesidad de una imagen (por ejemplo una tabla)

El texto alternativo de las imágenes se incluye después de etiquetar el documento.

PDF2: Creating bookmarks in PDF documents

Asociado al criterio de conformidad 2.4.5 de nivel AA

Lo más cómodo es que al crear el PDF indiques que se generen los marcadores. Si el documento de origen está bien estructurado estos se crearán correctamente aunque siempre es recomendable revisarlos.

También podemos crearlos automáticamente una vez tengamos el documento etiquetado o bien crearlos manualmente.

Hay que recordar que cuando asignamos un destino a un marcador, lo mismo que cuando creamos un enlace, el enlace recuerda el scroll y el zoom que tenías en la página. Es importante que la página esté escrolada en la zona de la página correcta y que mantengas un zoom constante, no hay cosa más incómoda que el documento cambie de zoom en función del enlace que pulses.

PDF3: Ensuring correct tab and reading order in PDF documents

Asociado al criterio de conformidad 1.3.2 (A), 2.1.1 (A), 2.1.3 (AAA), 2.4.3 (A)

Es imprescindible revisar el orden de lectura del documento mediante el panel "Retocar orden de lectura" y mediante un lector de pantalla como NVDA. Es especialmente importante cuando está maquetado en varias columnas o incluye notas al pie, en cuyo caso el orden dependerá de que se haya maquetado correctamente en el fichero de origen.

Si tienes dos columnas englobadas en un único bloque de lectura se leerán linealmente. Compruébalo con el lector de pantalla y divídelas en dos bloques de lectura.

Un error habitual en la revisión de accesibilidad mediante la herramienta de Adobe es "Páginas con un orden de tabulación que puede ser incoherente con el orden de estructura". Lo podemos solucionar seleccionando en las propiedades de la página la opción "Orden de tabulación>Usar estructura del documento"

Si el PDF tiene un formulario el orden de tabulación será el de la creación de los campos, pero puedes modificar el orden moviendo los campos dentro del árbol del panel "Campos".

PDF4: Hiding decorative images with the Artifact tag in PDF documents

Asociado al criterio de conformidad 1.1.1 de nivel A

Me remito a lo que he comentado en la técnica PDF1

PDF5: Indicating required form controls in PDF forms

Asociado al criterio de conformidad 3.3.1 (A), 3.3.2 (A), 3.3.3 (AA)

Si un campo de un formulario del PDF es obligatorio debes marcarlo como tal en sus propiedades. Además deberías seguir las mismas directrices de usabilidad que las que se aplican a un formulario web, para lo cual recomiendo el artículo Formularios usables: 60 Directrices de Usabilidad y Formularios accesibles según las WCAG 2.0

PDF6: Making tables accessible in PDF documents by using table elements

Asociado al criterio de conformidad 1.3.1 (nivel A)

Para que una tabla sea accesible es necesario en primer lugar que esté etiquetada correctamente como una tabla con las etiquetas TABLE, TR, TH (para los encabezados, indicando en la propiedad "Ámbito" a qué conjunto de celdas encabeza) y TD.

Pero además es necesario que se incluya un resumen de la tabla (lo que en web sería el SUMMARY) en la opción "Editar resumen de la tabla". También se debe relacionar correctamente las celdas con sus encabezados mediante el ID de los mismos. Recordad que estos IDs deben ser únicos en el documento y no sólo únicos en la tabla.

PDF7: Performing OCR on a scanned PDF document to provide actual text

Asociado al criterio de conformidad 1.4.5 (AA) y 1.4.9 (AAA)

Una comprobación inicial que debe hacerse siempre antes de comenzar a trabajar con el PDF es si tiene imágenes fruto de texto escaneado. En este caso no podremos buscar dentro de ese texto ni los lectores de pantalla tendrán acceso a él. Por ello será necesario convertirlo en texto mediante OCR, para lo cual es muy útil y funciona bastante bien la opción de Acrobat "Documento> Reconocimiento de texto OCR"

PDF8: Providing definitions for abbreviations via an E entry for a structure element

Asociado al criterio de conformidad 3.1.4 (AAA)

La primera vez que aparece en el documento un determinado acrónimo o abreviatura debes especificar su expansión (a no ser que esté expandida en el propio texto)

Si el documento tiene un índice de abreviaturas y acrónimos podemos poner un enlace a su entrada, y en caso contrario deberá indicarse su expansión en su propiedad "Texto alternativo".

La mayoría de las veces formará parte de un párrafo y será necesario convertirla en una etiqueta independiente para poder acceder a sus propiedades. Podremos hacerlo con la opción "Crear etiqueta a partir de la selección"

Recomiendo leer: "¿Cómo he de marcar correctamente las abreviaturas y acrónimos?", que aunque se refiere a web, hay muchos puntos en común con un PDF.

PDF9: Providing headings by marking content with heading tags in PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 2.4.1 (A)

Al igual que ocurre en web, el documento debe tener un sistema de encabezados lógico y coherente con la estructura del documento. Es importante validar el documento siempre con un lector de pantalla como NVDA para comprender los problemas que puede ocasionar un sistema de títulos mal definido.

No utilices nunca el lector de Adobe Acrobat, no se asemeja demasiado a lo que es un lector de pantalla de verdad.

PDF10: Providing labels for interactive form controls in PDF documents

Asociado al criterio de conformidad 1.3.1 (A), 3.3.2(A) y 4.1.2 (A)

El label de cada campo debe estar posicionado correctamente en relación con el campo.

Además, cada campo debe tener un nombre significativo en su propiedad "Nombre", que debería ser el de su label. Si no se incluye el campo “Nombre” el lector de pantalla leerá el tipo de campo, lo cual no resulta muy significativo.

En el tooltip incluirías el texto de ayuda contextual que tuviera asociado el campo, cuya información puedes ampliar si lo consideras necesario.

PDF11: Providing links and link text using the /Link structure element in PDF documents

Asociado al criterio de conformidad 1.3.1 (A), 2.1.1 (A), 2.1.3 (AAA), 2.4.4 (A), 2.4.9(AAA)

Los enlaces deben definirse antes de etiquetar el documento. Por tanto, si creamos desde el fichero de origen un PDF ya etiquetado, todos los enlaces necesarios del documento deberán estar definidos en el documento de origen (incluidos los de los acrónimos y abreviaturas al índice, los enlaces de la llamada de una nota a dicha nota, etc.)

Si etiquetamos el documento desde Adobe, primero deberemos comprobar si existen todos los enlaces y sino crearlos mediante la herramienta “Vínculo”.

Deberemos además comprobar en las etiquetas que es efectivamente de tipo LINK y que es interpretado correctamente por NVDA.

Es importante que el texto del enlace y el contexto en el que se incluye sea significativo, y en caso contrario añadir un texto alternativo en sus propiedades ("Texto alternativo"). Los lectores de pantalla sustituirán el texto del enlace por el del texto alternativo, por tanto hay que asegurarse de que el texto alternativo tiene sentido en el contexto del texto que tiene antes y después. El ejemplo más claro de un enlace en el cual ha de incluirse texto alternativo es todo aquel cuyo texto sea una URL.

PDF12: Providing name, role, value information for form fields in PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 4.1.2 (A)

Como he indicado en la técnica PDF10, todo campo de formulario de un PDF debe tener un nombre que coincida con su label y un tooltip con la información de ayuda contextual del campo (si la necesita) Además debemos rellenar la pestaña "Opciones" de sus propiedades para indicar su valor y estado por defecto.

Siempre será necesario comprobar con un lector de pantalla si podemos interactuar correctamente con los campos: activarlos, cambiar de valor, etc.

PDF13: Providing replacement text using the /Alt entry for links in PDF documents

Asociado al criterio de conformidad 2.4.4 (A) y 2.4.9 (AAA)

Me remito a la técnica PDF11 donde ya he tratado las alternativas textuales de los enlaces.

PDF14: Providing running headers and footers in PDF documents

Asociado al criterio de conformidad 2.4.8 (AAA) y 3.2.3 (AA)

Los encabezados y pies de página deben ser consistentes a lo largo de todo el documento e incluir información relevante, como el capítulo del documento dónde nos encontramos o el número de página. Ello ayuda, especialmente a los usuarios con una discapacidad intelectual, a ubicarnos dentro del documento.

Además, han de ser definidos como encabezados o pies de página en el documento de origen, lo cual beneficia a los lectores de pantalla. Los encabezados y pies de páginas definidos como tales desde el documento de origen son generados en el PDF como artifactos de página, que al contrario que los artifacto normales tienen asociados una lista de propiedades.

Por ejemplo, crea un Word con un encabezado, conviértelo en PDF, selecciona un texto que aparezca en dicho encabezado y busca su tag en el panel "Etiquetas". No lo encontrarás, es un artifacto y no será leído por los lectores de pantalla. Sin embargo búscalo en el panel "Contenido", verás que sí aparece. Editando el diccionario de su contenedor se observa que tiene propiedades como "Subtype" ("Header", si es un encabezado)

Más información en: About PDF Artifacts (PDF, 112 KB)

PDF15: Providing submit buttons with the submit-form action in PDF forms

Asociado al criterio de conformidad 3.2.2 (A)

Al igual que debemos hacer en un formulario web, en un formulario PDF el botón que envía el formulario debe ser un botón de tipo "Submit" (en Propiedades>Acciones)

PDF16: Setting the default language using the /Lang entry in the document catalog of a PDF document

Asociado al criterio de conformidad 3.1.1 (A)

Se debe indicar el idioma del PDF en las propiedades del mismo (pestaña "Avanzadas").

Tenemos que recordar que también es necesario marcar los cambios de idioma en el texto accediendo para ello a las propiedades de su etiqueta (consulta cuándo es necesario hacerlo en "¿Debo indicar el cambio de idioma de cualquier palabra?")

PDF17: Specifying consistent page numbering for PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 2.4.8(AAA), 3.2.3 (AA)

Si el documento incluye la paginación del mismo, por ejemplo en el pie, esta debe ser coherente con la paginación del propio documento en Acrobe. Lo puedes modificar en el panel "Páginas".

PDF18: Specifying the document title using the Title entry in the document information dictionary of a PDF document

Asociado al criterio de conformidad 2.4.2 (A)

Uno de los primeros pasos que ha de realizarse al modificar un PDF es acceder a sus propiedades para personalizar su metainformación. Uno de los datos más importantes, no sólo de cara a la accesibilidad del PDF sino también de cara al SEO, es personalizar su título.

Una de las recomendaciones que siempre doy y que hasta ahora no había visto documentada como técnica de accesibilidad es precisamente la que se indica en este pauta, no sólo añadir un título significativo sino indicar además que este sea el campo que se visualice en el título de la ventana del PDF (por defecto se muestra el nombre del PDF) Sería el mismo comportamiento que en una página web y se modifica en la pestaña "Vista inicial" de las propiedades del documento (en el campo "Mostrar> Título del documento")

PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents

Asociado al criterio de conformidad 3.1.1 (A) y 3.1.2 (AA)

Me remito a la técnica 16 donde ya lo he explicado. Si el texto en otro idioma está insertado dentro de un párrafo, será necesario convertirlo en una etiqueta independiente (SPAN) para poder acceder a sus propiedades. Podremos hacerlo con la opción "Crear etiqueta a partir de la selección"

PDF20: Using Adobe Acrobat Pro's Table Editor to repair mistagged tables

Asociado al criterio de conformidad 1.3.1 (A)

Me remito a la técnica 6 dónde ya he explicado lo referente a las tablas.

PDF21: Using List tags for lists in PDF documents

Asociado al criterio de conformidad 1.3.1 (A)

Al igual que en un página web, los elementos que forman parte de una lista deben estar etiquetados correctamente (L, LI, Lbl, LBody), esto permite al lector de pantalla informar de la lista (por ejemplo cuando empieza y termina) adecuadamente.

PDF22: Indicating when user input falls outside the required format or values in PDF forms

Asociado al criterio de conformidad 3.3.1(A) y 3.3.3(AA)

Al igual que en un formulario web, en un formulario PDF se debe indicar los campos que son obligatorios y los formatos requeridos (por ejemplo en un campo fecha); y en caso de que el usuario cometa un error se le debe informar apropiadamente.

Me remito a la técnica 5 donde ya lo hemos comentado. Se pueden ver ejemplos concretos en la explicación de esta técnica.

PDF23: Providing interactive form controls in PDF documents

Asociado al criterio de conformidad 2.1.1(A) y 2.1.3(AAA)

Una vez más, la forma de actuar es la misma que en un formulario web. El formulario PDF debe ser accesible no sólo mediante ratón, sino también por teclado.

Tabla resumen de los criterios de éxito a los que están asociados cada una de las técnicas PDF

Ampliación de la tabla del artículo WCAG 2.0 Techniques for PDF del blog de Adobe (en dicha tabla no aparecerían algunos criterios de nivel AAA que tienen asociados técnicas PDF)

Criterio de éxito	Nivel	Técnica PDF
1.1.1 Contenido no textual	A	PDF1 PDF4
1.2.1 Solo audio y solo vídeo(grabado)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-av-only-alt
1.2.2 Subtítulos (grabados)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captions
1.2.3 Audiodescripción o Medio Alternativo (grabado)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc
1.2.4 Subtítulos (en directo)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-real-time-captions
1.2.5 Audiodescripción (grabado)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc-only
1.3.1 Información y relaciones	A	PDF6 PDF9 PDF10 PDF11 PDF12 PDF17 PDF20 PDF21
1.3.2 Secuencia significativa	A	PDF3
1.3.3 Características sensoriales	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understanding
1.4.1 Uso del color	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color
1.4.2 Control del audio	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audio
1.4.3 Contraste (mínimo)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrast
1.4.4 Cambio de tamaño del texto	AA	G142
1.4.5 Imágenes de texto	AA	PDF7 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation
1.4.9 Imágenes de texto (sin excepciones)	AAA	PDF7
2.1.1 Teclado	A	PDF3 PDF11 PDF23
2.1.2 Sin trampas para el foco del teclado	A	G21
2.1.3 Teclado (sin excepciones)	AAA	PDF3 PDF11 PDF23
2.2.1 Tiempo ajustable	A	PDF3 G133
2.2.2 Poner en pausa, detener, ocultar	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause
2.3.1 Umbral de tres destellos o menos	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violate
2.4.1 Evitar bloques	A	PDF9 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip
2.4.2 Titulado de páginas	A	PDF18
2.4.3 Orden del foco	A	PDF3
2.4.4 Propósito de los enlaces (en contexto)	A	PDF11 PDF13
2.4.5 Múltiples vías	AA	PDF2 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-loc
2.4.6 Encabezados y etiquetas	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive
2.4.7 Foco visible	AA	G149 G165 G195
2.4.8 Ubicación	AAA	PDF14 PDF17
2.4.9 Propósito de los enlaces (sólo enlaces)	AAA	PDF11 PDF13
3.1.1 Idioma de la página	A	PDF16 PDF19
3.1.2 Idioma de las partes	AA	PDF19
3.1.4 Abreviaturas	AAA	PDF8
3.2.1 Al recibir el foco	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-receive-focus
3.2.2 Al recibir entradas	A	PDF15
3.2.3 Navegación coherente	AA	PDF14 PDF17 G61
3.2.4 Identificación coherente	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-consistent-functionality
3.3.1 Identificación de errores	A	PDF5 PDF22
3.3.2 Etiquetas o instrucciones	A	PDF5 PDF10
3.3.3 Sugerencias ante errores	AA	PDF5 PDF22
3.3.4 Prevención de errores (legales, financieros, datos)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-reversible
4.1.1 Procesamiento	A	Not Applicable: PDF is not implemented using markup languages
4.1.2 Nombre, función, valor	A	PDF10 PDF12

Servicios relacionados

Formación y cursos sobre creación de PDF accesibles. Conversión de PDF en PDF accesibles

Mi opinión sobre Google+: +1, -1

2011-07-02T01:41:00.005+02:00

Hoy estreno perfil de Google+, con el que llevo trasteando todo el día. Como varias personas me han pedido mi opinión os cuento mis impresiones.

-1: algunas cosas que me han decepcionado de Google+

1. No está integrado con Gmail

Es cierto que tenemos el nuevo tema "Vista previa" de Gmail:

Es cierto que en la barra superior podemos ir cambiando de Google+ a Gmail, eso sí, con el incordio de que te abre ventana nueva.

¿Pero qué costaba tener en Google+ un botoncito, un widget en la barra izquierda, algo que nos permitiera estar al tanto de los correos nuevos que nos llegan?

Me bastaría con el widget de Gmail para iGoogle (a ver si sacan también un tema nuevo para él):

Por lo que he leído por ahí más gente opina lo mismo, pídamoslo.

2. Integración con otras redes sociales muy mejorable

Puesto que podemos indicar nuestras cuentas en otras redes sociales, por ejemplo para que las incluya en el menú "Enlaces" de la pestaña "Sobre mí", esperaba:

Que al publicar algo me permitiera compartirlo también en otras redes sociales, tipo TweetDeck, ¿que mejor forma de centralizar la publicación de los usuarios en Google+?
Poder incluir una pestaña para cada una de mis redes sociales y el rss de mi blog. Otra vez lo mismo, si me dejas ver esa información en Google+ me fidelizas seguro.

Desde TweetDeck puedo publicar en la red social que quiero y también en Buzz, de esta manera, al menos mis publicaciones en otras redes sociales aparecen también en la pestaña "Buzz" de Google+ para quien las quiera seguir, pero me gustaría ver lo que dice la gente que sigo en otras redes.
Que pudiera sugerirme o buscar mis amigos en otras redes sociales para invitarles o ver si están en Google+, pero sólo puedo buscarlos por mi cuenta de Gmail, de Yahoo o de Hotmail. Actualización 3 de julio: he visto que una vez que uno de tus contactos de Twitter crea cuenta en Google+ sí que aparece ya en las recomendaciones de gente que quizás conoces.

Novedad (7/7/2011): con la extensión de Chrome "Ya puedes compartir una publicación en Facebook y Twitter"

3. Problema con la geolocalización

Con Internet Explorer 8 me indica "El navegador no permite añadir la ubicación", hubiera preferido que me diera una alternativa como por ejemplo la de Blogger o Twitter:

Lo que no estaría de más, y ninguno de los anteriores hace, es que en los otros navegadores se informará en el mensaje "Cargando" que se debe aceptar la barra superior que te aparece en el navegador... cuántos usuarios creerán que no les ha funcionado porque no se percatan de ello.

Por otro lado creo que se le podría haber sacado mucho más juego a la geolocalización, para poder pasarme también de Foursquare a Google+, empieza a ser complicado gestionar tanta red social.

4. No hay aplicación nativa para Blackberry

Sí hay aplicación web pero no me va demasiado bien porque tengo la versión 5 y, según indica, es para la versión 6. Espero que estén trabajando en ello.

5. ¿Y algún gadget para integrar Google+ en mi sitio?

Tipo los de Facebook o Twitter, aunque esto sí que es ya impaciencia :) entiendo que estando en beta no haya disponible todavía nada al respecto ni que necesiten promocionarse mucho cuando todo el mundo está hablando de Google+.

Nota 7/7/2011: lo que sí puedes es añadir el botón "+1". En Google Webmaster Tools te dan el código necesario, puedes monitorizar los +1 de tu sitio y ampliar información sobre cómo afecta al tráfico.

6. Muy poca accesibilidad

Basta desactivar javascript y la mitad de las cosas dejan de funcionar, por ejemplo el contenido de "Círculos" es una hoja en blanco.

Claro que, sí la página de Google (www.google.es), con lo sencilla que es, no es accesible, tampoco esperaba que lo fuera Google+. No parece estar entre sus prioridades.

7. No puedo personalizar ciertas cosas

Por ejemplo, no puedo decir qué círculo quiero ver por defecto en la Home, ni indicar que estén todos los círculos desplegados por defecto para ahorrarme un clic, ni ordenarlos (o al menos yo no he encontrado la manera)

Tampoco puedo modificar los intereses, me hubiera gustado que al menos se pudieran editar, ordenar o crear subintereses.

+1: lo que sí me ha gustado de Google+

1. Puedo separar mi vida privada de mi vida pública

Uno de los puntos fuertes de Google+ es que permite de forma muy sencilla gestionar tus círculos y dividir tus publicaciones en función de estos, por ejemplo las profesionales de las personales. Es una de las cosas que más me ha gustado por su claridad y sencillez.

Creo que este es uno de los problemas que tengo en Twitter, me gustaría a veces poder hacer comentarios más personales pero no quiero que los vea todo el mundo. Si como he dicho antes, Google+ me permitiera la opción de compartir en Twitter, sólo utilizaría Google+ y compartiría en Twitter o mi página de Facebook sólo lo profesional.

2. Diseño limpio. Además usable

Como leía hoy por ahí: Google +1, Facebook -1.

3. Adopta prácticas ya conocidas

Incluye el "@" para nombrar a alguien, también funciona con el "+".

Sin embargo me parece un fallo importante que no funcione "#" (o en su defecto cualquier otro método, o yo no lo he encontrado en la ayuda) para etiquetar los contenidos, es una pena.

3. +1s

Pestaña para mis +1. Con ella la opción +1 del buscador cobra sentido pleno. A partir de ahora se vuelve imprescindible que todas los artículos de blogs, periódicos, etc. incluyan un +1.

4. Puedo modificar mis entradas y comentarios

No hay cosa que más me moleste de Facebook y Twitter que no poder modificar una entrada sin borrados absurdos o explicaciones de más.

Unos truquillos: si pones una frase entre guiones en Google+, aparece tachada (en android no), así puedes indicar lo que corriges. Si pones una palabra entre asteriscos se pone en negrita.

5. Nada de juegos

Cada vez me da más pereza entrar en Facebook por lo molesto que me resulta ver decenas de entradas sobre galletas de la fortuna o animales conseguidos en una granja (aunque yo también estuve enganchada, lo reconozco) Al final resulta complicado encontrar lo importante entre tanta paja.

6. Iniciar una quedada

¡Qué bueno!

Pronto Facebook contraatacará con Skype.

7. Copia de seguridad

En "Configuración" puedo hacerme una copia de toda mi información incluida en Google+.

8. Puedo hacer una publicación en Google+ desde otras aplicaciones de Google

En Gmail, en GoogleDocs, en Picassa, desde la barra superior:

9. Drag and drop

Al igual que en Facebook, puedes arrastrar directamente una url de la barra de direcciones a la caja de publicaciones.

Pero hay otro drag and drop que me han gustado más, puedes seleccionar los contactos y arrastrarlos todos a un círculo:

Espero que muchos más os unais a Google+

Novedades de Axure 6

2011-06-28T00:06:00.000+02:00

Estaba deseando probar la nueva versión de Axure: Axure 6. Tengo que decir que algunas de las novedades me encantan.

Os las cuento.

1. Por fin tenemos guías

Se insertan arrastrando desde las reglas, exactamente igual que se hace en Photoshop. Además, en el menú Wireframes>Grid and Guides podemos ocultarlas, fijarlas o crearlas indicando si se aplican de forma general a todo el prototipo.

2. Podemos formatear el estilo de la página

Sí, un nuevo panel nos deja aplicar color de fondo y/o una imagen de fondo a la página. También podemos aplicar a todos los elementos de la página un nuevo grosor de línea, una nueva fuente o color de fuente.

Además hay un nuevo efecto "Sketchiness” que muestra los recuadros ondulados:

Lo mejor de todo es que podemos guardar las configuraciones para aplicarlas cómodamente en otras páginas.

3. Añadir acciones en una única pantalla

Esto nos va a ahorrar mucho tiempo. En una sola pantalla puedes definir la acción:

Desgraciadamente, seguimos sin poder seleccionar dentro de un elemento enlace o un elemento texto diferentes vínculos, esto obliga a crear un elemento enlace por cada vínculo que queremos hacer.

4. Mejoras importantes en la edición de los textos

¡Han incluido line spaccing y personalización del padding de las cajas! Por fin es posible personalizar la distancia entre las líneas de texto e indicar la distancia del texto respecto a la caja que lo contiene.

Lo más importante es que podemos guardarnos la configuración de estilo para aplicarlo fácilmente a otros elementos. Es posible crear la configuración manualmente, copiarla desde las características aplicadas a un elemento así como aplicarla a los objetos seleccionados.

También es muy útil que la información de tamaño y posición de un elemento se muestra ahora asociado al elemento:

También se muestra en la cabecera siempre editable sin tener que sacar el antiguo panel.

5. Mejora importante en las notas

Podemos formatear el texto de las notas (tipo de letra, color, estilo) lo cual se agradece de cara a su presentación en el prototipo y a la generación del Word para el funcional.

Además, la presencia de las notas en el prototipo es mucho más práctica, integrándose como una pestaña en el frame izquierdo y no en un frame inferior:

6. Podemos recuperar los frames del prototipo con facilidad

Una de las cosas más engorrosas cuando muestras el prototipo generado por Axure, es que al pulsar “Close frames” no puedes recuperar el índice de páginas sin volver a cargar la página inicial.

Ahora, una vez que cierras el frame del índice, un icono te permite volver a recuperarlo en la página en la que estás.

7. Más fácil modificar valores dinámicamente

Con la acción “Set Variable and Widget Values” podemos modificar dinámicamente los valores de otros campos o realizar operaciones aritméticas de manera mucho más sencilla:

Podéis ver una vídeo de ejemplo o descargaros los ejemplos en la página de Axure.

8. Publicar el prototipo de forma privada con pestaña para debate

Muy bueno. Te creas una cuenta gratuita en AxShare.Puedes subir hasta 10 ficheros RP de 10 MB. Te genera directamente el prototipo en HTML con el skin de Axure 6. Al prototipo le puedes poner una contraseña.

Tiene la ventaja de que incluye una pestaña Discuss para intercambiar comentarios.

Hay que decir que esta aplicación es una novedad pero que admite también prototipos de versiones anteriores, por tanto tampoco es propiamente una razón para pasarse a la versión 6.

Enlaces de interés

Recopilación de librerías para Axure.

Axureland, recursos para Axure

Totalwireframe, más recursos para Axure.

Servicio relacionado

Análisis de interfaz (AI & UX)

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA

2011-02-27T22:54:00.003+01:00

Como consultor de usabilidad y accesibilidad es fundamental, cuando formas parte del grupo de trabajo que va a desarrollar una aplicación Web, conocer el marco metodológico del Diseño Inclusivo para incluir los requisitos de accesibilidad y usabilidad a lo largo de todo el proceso de desarrollo. Ello permitirá crear aplicaciones usables y accesibles cuya calidad perdure en el tiempo.

El objetivo de este artículo es difundir el marco metodológico AWA para el desarrollo de aplicaciones web accesibles, pues es un excelente ejemplo de metodología de Diseño Inclusivo que ayuda a comprender las bases en las que se debe asentar un desarrollo que tenga la accesibilidad y la usabilidad presentes en todas las fases del proceso.

Para ampliar información o contactar con su autora recomiendo acceder directamente a su web: AWA (Accessibility for Web Applications) También recomiendo su presentación Tutorial: Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (PDF)

Índice del artículo

Introducción: marco metodológico AWA
Pre-requisitos para la aplicación de AWA
Fases y actividades
Estructura del soporte metodológico AWA
Checklist de seguimiento del cumplimiento de requisitos y mecanismos
Casos reales: portal corporativo con Drupal

Introducción: marco metodológico AWA

AWA (Accessibility for Web Applications) es el marco metodológico para el desarrollo de aplicaciones web accesibles elaborado por Lourdes Moreno es su tesis doctoral: “AWA, Marco metodológico específico en el dominio de la accesibilidad para el desarrollo de aplicaciones Web”, 2010 [PDF, 8.5 MB].

El objetivo del trabajo es ofrecer un soporte metodológico para incorporar los requisitos de accesibilidad en todo el proceso de desarrollo de una aplicación web, aportando sistematización y un enfoque DCU que situé al usuario como protagonista. El marco de trabajo es el Diseño Inclusivo que involucra a los usuarios con necesidades especiales y a expertos en este tipo de necesidades y discapacidades. El estándar de referencia a lo largo del trabajo son las WCAG (1.0 y 2.0) y el cumplimiento de las mismas en las páginas web finales de la aplicación Web.

Uno de los errores habituales es afrontar la revisión de la accesibilidad cuando el desarrollo está muy avanzado, siendo más costoso y complicado aplicar los requisitos necesarios. Por otra parte, cuando la accesibilidad no se ha sistematizado en el desarrollo es mucho más difícil mantenerla durante el ciclo de vida de la aplicación Web.

Los objetivos finales son pues:

conseguir que las páginas web finales generadas por la aplicación sean accesibles según las WCAG y usables desde el punto de vista del usuario,
garantizar la calidad, es decir, que esta accesibilidad sea estable en todo el ciclo de vida de la aplicación web.

Es una propuesta flexible para que pueda ser aplicada a cualquier proceso de desarrollo de software que cumpla con los pre-requisitos mínimos.

Pre-requisitos para la aplicación de AWA

La aplicación de esta metodología tiene como pre-requisito que la aplicación siga una arquitectura de modelo de más de dos capas (MVC) donde la lógica de negocio esté separada de la presentación, pues la separación de la presentación, la estructura y el contenido es un requisito imprescindible del diseño accesible. Además asegurará que las funcionalidades implementadas sólo en cliente (como AJAX) no dejen de funcionar.

Por otro la lado, la tecnología cliente deberá estar basada en estándares del W3C (XHTML, CSS, etc.) y tecnología servidor que no deje código en el lado del cliente (a excepción de AJAX que podrá ser utilizado junto con soluciones WAI-ARIA).

Fases y actividades

Presupone un proceso de desarrollo con un enfoque iterativo y un ciclo de vida incremental, cuyas fases y actividades son:

Comunicación con el cliente:

Análisis de negocio: identificación de metas y objetivos de la aplicación.
Actividad de formulación: captura de requisitos que involucre a todos los participantes.

Planificación:

Estimación de costes.
Evaluación de riesgos.
Planificación del desarrollo para definir tareas y plazos de cada incremento (plan de iteración)

Ingeniería:

Análisis:
1. Definición de requisitos técnicos, identificación de elementos de contenido y análisis del diseño gráfico.
2. Requisitos de interacción: relación de los elementos de contenido y su funcionalidad asociada.
3. Análisis de navegación: mecanismos de navegación que se van a proporcionar.
Diseño:
1. Diseño del contenido y diseño gráfico.
2. Diseño de la estructura y el comportamiento de la aplicación en sí, incluyendo arquitectura, navegación e interfaz.
Modelado: creación de modelos antes de la construcción.

Construcción:

Implementación: de los modelos procedentes de la fase de ingeniería para construir la aplicación Web. Integración con software intermedio.
Pruebas: para asegurar la calidad:
1. Verificación: comprobación de que la aplicación es correcta desde la perspectiva del diseñador en relación al contenido, arquitectura, presentación, interfaz y navegación
2. Validación: comprobación de que la aplicación hace y tiene la apariencia que el cliente esperaba.

Despliegue:

Evaluación e interacciones de cambios.

Estructura del soporte metodológico AWA

Componentes

AWA_Organización

Mecanismos para integrar planes y políticas de accesibilidad en la organización y equipo de desarrollo.

Se articula en torno a la elaboración de un Plan de accesibilidad (creación del grupo de accesibilidad, determinar la política de accesibilidad con el nivel de conformidad deseado, mecanismos para compartir el conocimiento sobre accesibilidad y plan de formación, seleccionar tecnologías accesibles, etc.) y la Gestión de la accesibilidad (procesos a nivel interno pero también externo como la elaboración de requisitos para proveedores externos o la gestión de sugerencias de los usuarios)

Consultar mapa conceptual de AWA_Organización

AWA_Interacción

Mecanismos para integrar un enfoque de DCU con inclusión, teniendo como instrumento base el estándar ISO 13470:1999 (PDF, p.121) que se introduce en las páginas 121 y siguientes.

Se articula en torno a dos principios fundamentales:

Involucrar a todos los usuarios, incluyendo al usuario con discapacidad en todo el proceso
Considerar las características del usuario con discapacidad y la diversidad de contextos de uso en la Web.

Engloba técnicas de usabilidad con inclusión como: perfiles de usuario, personas, escenarios, prototipo, tormenta de ideas, cardsorting, evaluación heurística y cuestionarios, entrevistas y encuestas, que se detallan en las páginas 129 y siguientes.

Consultar mapa conceptual de AWA_Interacción

En este capítulo 5 me parece muy interesante la tabla de correspondencia entre los criterios heurísticos de usabilidad y los criterios de conformidad de las WCAG 2.0 (PDF) (tabla que se explica en las páginas 155 y siguientes). Recurso muy útil para saber qué aspectos de la accesibilidad se están teniendo en cuenta cuando la usabilidad se incluye en un proyecto.

AWA_WCAG

Abstracción de las WCAG (1.0 y 2.0) de manera que su tratamiento pueda ser incluido desde el inicio del proceso de desarrollo de una aplicación Web.

Puesto que no todos los requisitos pueden ser incorporados desde el diseño se distingue estos (AWA_WCAG Diseño) de los que son a nivel de implementación (AWA_WCAG Implementación: presentación con CSS, acceso por teclado, cambio de contexto o compatibilidad con terceras tecnologías) y de los que han sido definidos para ser incorporados en la actividad de evaluación (AWA_WCAG Evaluación)

Consultar los mapas conceptuales de AWA_WCAG para las actividades de diseño, implementación y evaluación

Requisitos

AWA_Requisitos

Como resultado se definen unos requisitos de accesibilidad que tienen tres objetivos principalmente:

seguir las WCAG 1.0 y 2.0,
seguir un enfoque DCU con Inclusión
tener en cuenta la gestión de la accesibilidad considerando los requisitos de accesibilidad desde la organización como punto de partida.

En la notación de los requisitos se incluye el componente, por ejemplo: AWA_Requisito_{Organización} PLAN 01.02: Declaración de Política de accesibilidad

Los AWA_Requisitos_WCAG que hay que incorporar en la actividad de diseño se describen en las páginas 150 y siguientes, incluyendo por cada uno una tabla de correspondencia con las WCAG 1.0 y las WCAG 2.0. También se pueden consultar estas tablas accediendo en la web a cada una de las pautas WCAG 1.0 y WCAG 2.0

Consultar una tabla simplificada de correspondencias entre las WCAG 1.0, las WCAG 2.0, los AWA_Requisitos y los grupos de usuarios beneficiados.

Los AWA_Requisitos activan mecanismos de accesibilidad denominados AWA_Mecanismos.

Mecanismos

AWA_Mecanismos: Articulan la incorporación de los AWA_Requisitos desde el inicio del proceso. En la notación de los requisitos se incluye el componente, por ejemplo AWA_Mecanismo_{Organización} PLAN 01.02/02: Determinar Declaración de Política de Conformidad.

Checklist de seguimiento del cumplimiento de requisitos y mecanismos

Consultar checklist de seguimiento del cumplimiento de requisitos y mecanismos (PDF)

Casos reales

En el capítulo 7 se explican casos reales de aplicación, uno de ellos el de la web del Centro Español de subtitulado y Audiodescripción (CESyA) gestionada con Drupal.

Se explica el enfoque de Diseño Inclusivo en la captura de requisitos combinando las técnicas de perfiles de usuario, personas y escenarios.

Se detalla la utilización de la técnica Card Sorting (manual abierta, automática con WebSort y manual cerrada) para adecuar la arquitectura de la Información al modelo mental de los usuarios.

La elaboración de un prototipo de bajo coste y reuniones Visual Brainstorming antes de abordar el diseño gráfico, así como la elaboración posterior de un prototipo software funcional, evaluándolo por expertos (evaluación heurística) y mediante pruebas de usuarios con y sin discapacidad (consultar cuestionarios a los participantes en el test de usuarios y a los testers (PDF)).

Aplicando todo lo anterior se crearon las plantillas de Drupal y se validó su accesibilidad.

Me parecen fundamentales todos los mecanismos que se llevaron a cabo en Drupal para asegurar que la inclusión de contenido a través del gestor diera lugar a contenido accesible y por tanto páginas que cumplen los niveles de conformidad AA.

Para ello se incluyó un editor de contenido con criterios de accesibilidad que transformara los datos introducidos en código válido. Por ejemplo, al incluir una noticia se pide el título (que se incluirá como encabezado), el idioma (aplicará en el código la identificación del idioma si no se corresponde con el idioma de la página), etc.

Me gustaría destacar las características y restricciones que debe tener el editor de contenido de un CMS para que el contenido resultante sea accesible:

Edit text: permite escribir texto plano e incluye una opción guiada donde no se puede incluir tags (X)HTML
Specify language: puedes seleccionar el idioma mediante una select.
Add header: permite incluir un encabezado de un nivel específico, pero si existe un nivel de encabezado ya definido que englobe el actual documento, el nivel relativo se ajustará a ese nivel global, siendo relativo a éste. Se puede especificar también su idioma.
Add image: siendo obligatorio la URI y el texto alternativo, y opcionalmente el longdesc
Add multimedia: permite incluir vídeo siendo obligatoria la URL, el recurso de subtitulado y audiodescripción, y su lenguaje.
Add link: siendo obligatorio la URI y pudiendo incluir un title y el lenguaje de la página de destino.
Add abbreviation: que permita incluir un contenido con texto abreviado, pudiendo especificar su idioma.
Add acronym: permite incluir un acrónimo, pudiendo especificar su idioma.
Add list: añade una lista de diversos tipos.
Add table: permite incluir una tabla, indicando filas, columnas, encabezados, resumen, etc..
Add form: añade un formulario, permitiendo incluir los elementos típicos de formularios HTML mediante “Add element”. “Specify action” permite indicar la acción que realizará el formulario al ser enviado.
Finish editing: finaliza la edición del contenido, comprobando que éste cumple con las especificaciones definidas y lo inserta en el sistema de persistencia, quedando a la espera de una revisión de accesibilidad (AWA_Requisito_WCAG EVA 01) para su publicación definitiva.

Esta revisión manual del contenido incluido en el editor para que pueda publicarse tiene en cuenta los puntos de las tabla de la página 241.

Artículos relacionados:

Artículos recomendados

Diseño Inclusivo: Marco Metodológico para el Desarrollo de Sitios Web Accesibles

SEO y Accesibilidad. Accesible también para buscadores

2011-02-20T20:56:00.009+01:00

Recursos "Usable y accesible" relacionados:

Todas aquellas acciones que llevamos a cabo para hacer nuestra web más accesible repercuten directa y positivamente en su posicionamiento en los buscadores. No debemos olvidar que uno de los visitantes importantes de nuestra web no es humano y, que los problemas que suele tener para acceder al contenido, no difiere mucho de los que puede tener un usuario con una discapacidad visual.

Si los buscadores encuentran barreras que les impiden o les dificultan recorrer nuestras páginas e indexar su contenido, localizar sus temas principales y sus palabras clave, la consecuencia será que no estaremos en las páginas de resultado de los buscadores, o en posiciones poco relevantes, o indexados por palabras irrelevantes.

Hay muchas razones para hacer una web accesible, una de ellas es que mejora el posicionamiento en buscadores. Evidentemente, el principal motivo por el que hacemos páginas accesibles no es posicionar bien nuestras páginas, pero seguro que es un argumento que convence a muchos, así que bienvenido sea.

Este artículo explica cómo usabilidad, accesibilidad y SEO están estrechamente relacionados, de modo que las acciones que llevamos a cabo para que nuestras páginas sean más usables y accesibles repercuten directamente en su indexación y posicionamiento.

Índice

Texto equivalente para todo elemento no textual (punto de verificación 1.1 y 8.1)
Javascript (punto de verificación 6.2, 6.3, 10.1)
Código (XHTML) válido y separación de contenido y la presentación (punto de verificación 3.2, 3.3, 6.1, pauta 5, 11.2)
Marcado correcto y uso adecuado de encabezados (punto de verificación 3.1, 3.5, 3.6 y 3.7)
Escribir para la web (punto de verificación 12.3, 13.8, 14.1)
Enlaces (punto de verificación 1.2, 13.1)
Frames (punto de verificación 6.5 y 12.1)
Metainformación e idioma (punto de verificación 13.2, 13.9, y pauta 4)
Mapa web (punto de verificación 13.3)
Redireccionamiento automático (punto de verificación 7.5)

Texto equivalente para todo elemento no textual

Es sin duda, el punto de verificación más conocido de las WCAG 1.0:

1.1 Proporcione un texto equivalente para todo elemento no textual (Por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos [Prioridad 1].

SEO y aplicación del punto de verificación 1.1 de las WCAG 1.0

El robot del motor de búsqueda que recorre nuestras páginas es “ciego”. Puedes comprobar cómo “ve” tu página con la aplicación gratuita online Seo-browser. Por tanto, incluir equivalentes textuales en las imágenes ayuda a que Google comprenda la información que transmiten las imágenes y las pueda indexar correctamente. Si además estas imágenes son relevantes en relación con el contenido de la página, las alternativas textuales que incluyas tendrán palabras claves que ayudarán también al posicionamiento. Lo mismo se aplica a los vídeos o a los audios, para los cuales siempre se debe proporcionar una transcripción.

También influye que las imágenes tengan un nombre significativo, el tamaño de las mismas (las imágenes con un tamaño excesivo no indexan tan bien como las de un tamaño normal) y su contexto (el texto cercano que las acompaña), aspectos todos ellos que se tienen en cuenta al evaluar la usabilidad de una página.

Hay que tener también en cuenta que no ejecuta applets ni objetos, por ello también es importante para indexar su contenido incluir un texto alternativo en los elementos OBJECT y APPLET, tal y como indica el punto de verificación 1.1.

Por último tenemos el tema de Flash. Google ya indexa contenido en Flash (probad por ejemplo a incluir: accesibilidad filetype:swf en la caja de búsqueda) El problema con Flash es que si este es inacesible de forma nativa (todo el texto con imágenes, sin enlaces de texto, sin alternativas al contenido no textual, etc.) será inacesible para muchos usuarios pero también para el robot de Google.

Según las WCAG 2.0 las películas Flash deben ser accesibles de forma nativa ("Flash Techniques for WCAG 2.0"), y en caso contrario, como indican también las WCAG 1.0 en la pauta 8, tener una alternativa accesible. Asegurar la accesibilidad de las películas Flash, por tanto, permitirá que su contenido sea accesible para los usuarios y para los buscadores.

Javascript

El punto de verificación 6.3 dice: Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible. [Prioridad 1]

Uno de los requisitos para que una web sea accesible es que el javascript no suponga una barrera de acceso para los contenidos de la página.

SEO y aplicación del punto de verificación 6.3 de las WCAG 1.0

El robot del motor de búsqueda es uno de nuestros visitantes que accede sin javascript activo: no ejecuta los scripts.

Es fundamental que el robot pueda seguir tus enlaces, pero no podrá si generas tu menú por javascript o creas enlaces o abres pop-ups mediante javascript sin dar una alternativa accesible.

El típico enlace <a href=”javascript:mifuncion(‘parámetro’)”>Texto del enlace</a> no podrá ser seguido por Google.

El punto de verificación 10.1 de las WCAG 1.0 desaconseja el uso de ventanas emergente. En la técnica SCR24 de las WCAG 2.0 (SCR24: Using progressive enhancement to open new windows on user request) se indica cómo hacer un window.open accesible, que pasa por incluir un "href" con la ruta de la página: accesible para los usuarios y para los buscadores.

De la misma manera, si generas contenido mediante javascript y este no está disponible sin javascript activo, dicho contenido no podrá ser indexado por Google. En este caso es también fundamental, como indica el punto de verificación 6.2 de prioridad 1, que las alternativas se correspondan realmente con el contenido dinámico.

Es importante también intentar métodos alternativos al “noscript”, que Google mira con recelo por el abuso que se ha hecho de él por parte de los spammers. En especial si contiene enlaces.

En resumen, hacer tu web accesible sin javascript beneficia no sólo a los usuarios que no pueden ejecutarlo sino también a los robots que podrán seguir tus enlaces y acceder a todo el contenido, lo cual repercutirá en tu posicionamiento.

Es muy interesante el artículo de Google “Rastreo con AJAX: guía para webmasters y desarrolladores”

Código (X)HTML válido y separación de contenido y la presentación

El punto de verificación 3.2 indica Cree documentos que estén validados por las gramáticas formales publicadas [Prioridad 2], siendo además necesario evitar características desaconsejadas como por ejemplo el elemento "font" (pauta 11.2 de prioridad 2).

Por su parte, el punto de verificación 3.3 indica que es necesario separar el contenido de la presentación: Utilice hojas de estilo para controlar la maquetación y la presentación. [Prioridad 2], de modo que la página pueda ser leída correctamente sin CSS accediendo de forma lógica a todo su contenido (pauta 6.1 de prioridad 1).

En este sentido, las WCAG 1.0 (y también las WCAG 2.0) desaconsejan explícitamente maquetar mediante tablas en la pauta 5.

SEO y aplicación de los puntos de verificación 3.2 y 3.3 (y otros asociados) de las WCAG 1.0

Tener un código (X)HTML válido (se puede validar con el servicio online del W3C) repercute indirectamente en el posicionamiento desde el punto de vista de que permite al robot un acceso más sencillo a la información, que es más fácil de analizar y procesar.

Google lee código X(HTML) pero sólo indexará el contenido textual de la página, si los estilos están en las CSS y el código javascript en archivos externos, le estás facilitando su labor. Maquetar sin tablas y separar el contenido de la presentación mediante CSS genera un HTML más limpio y con menos líneas de código, de manera que nuestro contenido no se haya después de líneas y más líneas de código. Además de ser más fácil de entender por los buscadores, influye en el tamaño de la página (se suele aconsejar que no sea mayor de 150kb) Desde marzo de 2010 Google incluyó en su algoritmo la velocidad de carga de la página.

También hay que tener en cuenta que si la página tiene más de dos tablas anidadas se indexará peor (hay quien incluso dice que los robots obvian todo lo que se encuentre en las tablas anidadas a partir del tercer nivel de anidación), y que muchos expertos SEO indican que se tiene en cuenta la relación entre el número de líneas de código y el texto de la página.

Marcado correcto y uso adecuado de encabezados

El punto de verificación 3.1 indica Cuando exista un marcador apropiado, y se soporta, use marcadores en vez de imágenes de mapa de bits para transmitir la información [Prioridad 2]

Por su parte, el punto de verificación 3.5 señala Utilice elementos de encabezado para transmitir la estructura lógica y utilícelos de acuerdo con la especificación. [Prioridad 2] Por su parte los puntos de verificación 3.6 y 3.7 (ambas de prioridad 2) hacen referencia a marcar correctamente las listas y las citas.

SEO y aplicación de los puntos de verificación 3.1 y 3.5 (y otros asociados) de las WCAG 1.0

Ya hemos dicho que el robot es ciego y lee código (X)HTML. Si marcamos correctamente el código le estamos ayudando a interpretarlo, por ello es fundamental estructurar el contenido adecuadamente con encabezados, párrafos, etc.

No sólo tiene en cuenta la frecuencia de las palabras sino también su relevancia, y está es mayor en función de dónde se encuentran: si están en un encabezado, el nivel de encabezado que las contienen, si están marcadas como relevantes (con “strong” o “em”), etc.

Por tanto, usar correctamente los encabezados y el marcado de la página ayuda no sólo a los usuarios sino también a los buscadores: la estructura del contenido y la relevancia de cada uno de sus elementos es más evidente, lo cual ayuda a interpretar la página e indexarla correctamente.

Escribir para la web

El punto de verificación 14.1 dice Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]

La forma de redactar adecuadamente para la web, tal y como por ejemplo se explica en las técnicas asociadas a este punto de verificación, aborda aspectos tales como colocar el contenido más importante al comienzo, facilitar el escaneo de la información utilizando encabezados, listas o textos destacados, usar párrafos cortos y centrados en una idea o utilizar un lenguaje común (ampliar información en Reseña: "Cómo escribir para la Web" de Guillermo Franco)

Otros puntos de verificación relacionados son el 12.3 de prioridad 2 que insta a dividir los bloques largos de información en grupos más manejables o la 13.8 de prioridad 3 que indica que se debe localizar al principio la información diferencial.

SEO y aplicación del punto de verificación 14.1 (y otros asociados) de las WCAG 1.0

Es más sencillo inferir la temática de un contenido textual claro y conciso, sin paja y sin faltas de ortografía o gramaticales, siendo sin duda más fácil de rastrear e indexar correctamente.

Enlaces

La pauta 13.1 dice Identifique claramente el objetivo de cada vínculo. [Prioridad 2] para lo cual hay que prestar especial atención a la redacción del texto de los enlaces para que sean significativos y tengan sentido fuera de contexto, incluyendo el atributo “title” para clarificar su destino cuando no sea evidente.

SEO y aplicación del punto de verificación 13.1 de las WCAG 1.0

Ya he comentado que es imprescindible que el robot pueda rastrear nuestros enlaces, y que por ello se deben evitar prácticas como la generación de enlaces o menús por javascript, o también otras prácticas como los menús mediante combos de formulario que los robots no pueden seguir, o los enlaces dentro de mapas de imágenes sin alternativa accesible (como previene por ejemplo el punto de verificación 1.2 de prioridad 1), etc.

Si es importante que el robot pueda seguir nuestros enlaces para poder indexar las páginas, también lo será cómo realizas esos enlaces para que las páginas se indexen adecuadamente y se posicionen por las palabras claves que las definen. Tener enlaces con un texto significativo (y no por ejemplo “pulsa aquí”) como indica el punto de verificación 13.1 no sólo beneficia a tus usuarios sino que influirá positivamente en el posicionamiento de las páginas internas que enlazas.

Frames

Las WCAG no prohíben la utilización de frames pero sí que los desaconsejan por los problemas que pueden suponer para las personas que utilizan ayudas técnicas, siendo preferibles otras alternativas como los includes de servidor (más información en ¿Mi sitio es accesible si utiliza frames?)

Si a pesar de todo se usan frames, las WCAG indican que cada frame debe tener un atributo “title” y utilizar la etiqueta “noframes” para ofrecer una alterativa (puntos de verificación 12.1 y 6.5, de prioridad 1 y 2 respectivamente)

Por otro lado, desde un punto de vista de usabilidad, también se desaconseja el uso de frames por sus problemas asociados en cuanto a la impresión de la página, problemas con el botón “atrás” del navegador, etc.

¿Cómo repercute en SEO que tengamos en cuenta los problemas de accesibilidad y usabilidad de los frames?

Google no recomienda tampoco el uso de frames, como ellos mismo dicen Google intenta asociar el contenido enmarcado con la página que incluye los marcos, pero no puede garantizar resultados.

La "Guía de recomendaciones 'SEO' de posicionamiento en Internet" de Inteco resumen muy bien los problemas que suponen los frames para los robots de los motores de búsqueda:

complica la progresión lineal de los robots por los enlaces
aparecen dificultades como problemas de recursividad en la progresión
ambigüedad en la titulación de las paginas
descargas extras por residir el código de los marcos fuera de la pagina descargada

Por tanto, seguir la recomendación de no usar frames ayudará a que tu página sea más accesible también para los buscadores. Y si a pesar de todo usas frames, cumplir con las pautas de accesibilidad asegurará que por lo menos, gracias a la titulación de los frames y a la correcta redacción del “noframes” (sin mensajes del tipo “Su navegador no admite frames”), sean lo más accesibles posibles también para los buscadores.

Al igual que con la etiqueta “noscript” hay que tener cuidado con la etiqueta “noframes”, pues debido a su abuso por los spammers está en el punto de mira y puedes ser penalizado si no la usas correctamente.

Metainformación e idioma

La pauta 13.2 indica Proporcione metadatos para añadir información semántica a las páginas y sitios. [Prioridad 2] En relación con la cual, la 13.9 de prioridad 3 indica que se proporcione información sobre la colección de documentos con el elemento LINK y los atributos "rel" y "rev".

Por su parte, en la pauta 4 se especifica que se ha de identificar el idioma del documento así como los cambios de idioma en el contenido.

SEO y aplicación del punto de verificación 13.2 y la pauta 4 de las WCAG 1.0

La inclusión de metainformación en la página es quizás la norma de accesibilidad cuya repercusión en el posicionamiento de la página resulta más evidente. La información que proporcionemos a través de las etiquetas “meta” o el atributo “rel” es vital, pues estamos ofreciendo al buscador información sobre el título de la página, su descripción, sus palabras clave, su relación con otras páginas o e tipo de contenido que incluimos.

Por otra parte, identificar el idioma usado no sólo beneficia a los usuarios que utilizan ayudas técnicas, sino también permite a los motores de búsqueda localizar las palabras clave e identificar los documentos en el idioma deseado (pauta 4).

Relacionado con el idioma hay que tener en cuenta que a la hora de posicionar por aspectos geográficos también se tienen muy en cuenta otros factores como el país donde se aloja la web o la orientación geográfica que definas en “Herramientas para webmasters” de Google.

Mapa web

La pauta 13.3 indica Proporcione información sobre la maquetación general de un sitio (por ejemplo, mapa del sitio o tabla de contenidos). [Prioridad 2]

SEO y aplicación del punto de verificación 13.3 de las WCAG 1.0

El robot del motor de búsqueda debe ser capaz de llegar a todas las páginas de nuestra web. Incluir un mapa del sitio ayuda a mostrar su estructura y nos asegura que se pueda acceder a todas sus páginas. No hay que confundirlo con un “sitemap.xml” que es un mapa del sitio específico para los motores de búsqueda y que también es recomendable definirlo.

Redireccionamiento automático

La pauta 7.5 dice Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el redireccionamiento automático, no utilice marcadores para redirigir las páginas automáticamente. En su lugar, configure el servidor para que ejecute esta posibilidad. [Prioridad 2].

SEO y aplicación del punto de verificación 7.5 de las WCAG 1.0

Según este punto de verificación, una página que cumple con las WCAG utilizará un redireccionamiento de servidor 301 para una página movida permanentemente y no el meta "redirect". Podremos así acceder tanto a la vieja como a la nueva URL, manteniendo los backlinks y el PageRank.

Recursos "Usable y accesible" relacionados:

Artículos "Usable y accesible" relacionados:

Respuesta a 25 dudas habituales sobre accesibilidad web

2011-01-30T21:06:00.012+01:00

En los artículos Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad y Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad incluía las respuestas a 15 dudas de accesibilidad basándome en el documento "Techniques for WCAG 2.0" de las WCAG 2.0

A continuación listo el enlace a las 15 dudas ya resueltas en esos artículos anteriores y el ancla a las 10 nuevas dudas que se resuelven en este artículo.

16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?

Es el típico ejemplo de "Leer más" o "Más información" en un listado de noticias.

En las WCAG 1.0 se especifica en relación al punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo que si en la página hay dos o más vínculos con el mismo texto deben remitir al mismo recurso y de lo contrario se han de diferenciar por el atributo "title":

Si hay más de un vínculo en una página con el mismo texto, todos estos vínculos deben remitir al mismo recurso. Esta coherencia ayudará al diseño de la página tanto como a la accesibilidad.
Si dos o más vínculos van referidos a objetivos diferentes pero comparten el mismo texto, distinga los vínculos especificando un valor diferente para el atributo "title" de cada elemento A.
En "Técnicas HTML para las Pautas de Accesibilidad de los Contenidos Web 1.0" del W3C.

Las WCAG 2.0 también tienen dos criterios de conformidad (2.4.4 de nivel A y 2.4.9 de nivel AAA) que obligan a que se clarifique el propósito de un vínculo. Una de las técnicas suficientes para cumplir con el criterio de conformidad 2.4.4 es la "H33: Supplementing link text with the title attribute". Esta técnica consiste también en incluir el atributo "title" para clarificar el destino del vínculo cuando la información complementaria proporcionada por el atributo "title" es algo que el usuario debe saber antes de seguir el enlace.

Sin embargo, la propia técnica H33 de las WCAG 2.0 desaconseja el uso del atributo "title" para clarificar el destino de un vínculo por la falta de soporte del atributo "title" en muchos user-agent. De hecho, esta técnica no es válida para cumplir con el criterio de conformidad 2.4.9, que también se refiere a clarificar el destino de un vínculo pero es más estricto por ser de nivel AAA.

En esta técnica se recomiendan otras dos técnicas suficientes alternativas al uso de "title":

o bien que el enlace tenga el texto completo (sería la técnica H30) por ejemplo: "Leer más sobre el artículo 'WCAG 2.0'" en vez de "Leer más"
o bien ocultar mediante CSS el texto del enlace que sigue a "Leer más" (sería la técnica C7), lo cual resulta muy útil cuando el texto del enlace puede llegar a ser demasiado extenso. También se permite incluir un enlace o botón para ver u ocultar las versiones largas de los enlaces (serían las técnicas G189 y SCR30)

Estas alternativas permitirían cumplir con los criterios de conformidad 2.4.4 (nivel A) y 2.4.9 (nivel AAA).

En cuanto a la opción de ocultar por CSS parte del texto del enlace, es necesario que la ocultación del texto se haga de forma accesible para los lectores de pantalla, es decir, no se debe utilizar display:none sino localizarlo fuera de pantalla.

El ejemplo correcto sería el siguiente:

En la CSS:

a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }

En la página:

<dl>
<dt>Winnie the Pooh </dt>
<dd><a href="winnie_the_pooh.html">
<span>Winnie the Pooh  </span>HTML </a> </dd>
<dd><a href="winnie_the_pooh.pdf">
<span>Winnie the Pooh  </span>PDF </a> </dd>
<dt>War and Peace</dt>
<dd><a href="war_and_peace.html">
<span>War and Peace  </span>HTML</a></dd>
<dd><a href="war_and_peace.pdf">
<span>War and Peace  </span>PDF </a> </dd>
</dl>

Hay otra manera de cumplir con la pauta 2.4.4 (nivel A), pero que sin embargo no será válida para cumplir con la pauta 2.4.9 (nivel AAA), y por tanto es menos aconsejable, pues las WCAG 2.0 alientan a cumplir más criterios de los estrictamente necesarios para alcanzar un determinado nivel de adecuación.

Esta última alternativa es que será válido el enlace "Leer más" cuando esté correctamente contextualizado. Por ejemplo, en el caso de un párrafo (sería la técnica H78) el W3C propone el siguiente ejemplo:

Sería incorrecto:


<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.</p>
<p><a href="final15.html">[Read more...]</a></p>

Pero sería correcto:


<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>

De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)

17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?

La pauta 4.1 (prioridad 1) de las WCAG 1.0 indica Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente. De la misma manera, el criterio de conformidad 3.1.2 de las WCAG 2.0 también obliga a identificar los cambios de idioma pero establece una serie de excepciones. No es necesario identificar el cambio de idioma de:

los nombres propios
los términos técnicos, por ejemplo: Homo sapien, Alpha Centauri, hertz, habeas corpus (ejemplos textuales de la explicación del criterio)
las palabras en un idioma indeterminado
las palabras o frases que se hayan convertido en parte natural del texto que las rodea.

Para resolver las dudas que esto puede ocasionar recomiendan: If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?

La pauta 1.4.2 (nivel A) de las WCAG 2.0 indica que sólo es necesario si el sonido dura más de 3 segundos: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?

Es una práctica habitual utilizar :focus{outline:0;} o peor aun onfocus="blur()" para evitar que las imágenes queden punteadas alrededor cuando cogen el foco.

Las WCAG 1.0 indican mediante el punto de verificación 9.4 (de prioridad 3 y de prioridad 2 en la Norma UNE 139803) que es necesario poder acceder mediante el tabulador a vínculos, controles de formulario y objetos. Sin embargo no se especifica si es necesario que el foco sea visible.

Esto se corrige en las WCAG 2.0 Su criterio de conformidad 2.4.7 (nivel AA) especifica claramente que el foco debe ser visible, de hecho incluye como fallos habituales las dos prácticas comentadas:

Por tanto, no sólo se debe poder acceder mediante el tabulador a toda imagen que sea enlace, sino que además cuando coja el foco este debe ser visible como se aprecia en este ejemplo:

20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?

Una duda habitual es la anchura que debe tener (en número de carácteres) un bloque de texto para su óptima legibilidad. Hay muchos estudios al respecto, unos recomiendan entre 80-100 caracteres y otros entre 60-80 por ser el ancho preferido de los usuarios. Se pueden consultar esos estudios en el artículo "Columnas, anchos de línea y legibilidad" de Juan Carlos García.

¿Dicen algo al respecto las WCAG? El criterio de conformidad 1.4.8 (nivel AAA) indica que el ancho de un bloque de texto no debe ser mayor de 80 caracteres.

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.

En relación con este requisito, las técnicas que aseguran que sea así aunque se redimensione el navegador son :

En este criterio de conformidad también se especifica que el espacio entre líneas (interlineado) debe ser, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos, al menos, de 1.5 veces mayor que el espacio entre líneas.

People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is 'single spaced' (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line).

21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?

La técnica G174 de las WCAG 2.0 ofrece como alternativa para cumplir con los criterios de conformidad 1.4.3 y 1.4.6 referentes al contraste de color, el utilizar la cláusula de "Version alternativa" de los requisitos de conformidad e incluir un botón o enlace para visualizar la página en alto contraste. Un ejemplo de una web que ofrece una versión en alto contraste es: Media, del Ministerio de Educación.

Pero para que se utilice con éxito esta técnica es necesario:

El botón o enlace a la versión alto contraste debe cumplir con los requerimientos de contraste.
La versión alto contraste debe tener el mismo contenido y funcionalidad.
La versión alto contraste debe cumplir con todos los demás requisitos de accesibilidad.

Los dos últimos requisitos no deben suponer un problema si simplemente se carga una CSS diferente.

22. ¿Cuándo puedo ponerle a una imagen alt=""?

¿Qué entendemos por imagen decorativa? Cualquier imagen que no forma parte del contenido significativo de la página y que por tanto debería ser ignorada por los lectores de pantalla. Según la definición incluida en el criterio de conformidad 1.1.1: serving only an aesthetic purpose, providing no information, and having no functionality

Las imágenes decorativas deberían estar definidas en las CSS, pero si se incluyen en las páginas deben tener alt=""

El error cómun F39. Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive technology indica además que aunque es válido alt=" " (ojo, se admite un espacio en blanco pero no que contenga  ) es más recomendable usar alt="".

Además las imágenes decorativas no podrán tener el atributo "title" o este deberá estar vacío (ver técnica H67)

NO se puede considerar que una imagen es decorativa (y por tanto no puede estar definida en la CSS ni tener alt=""):

si es un enlace, a no ser que sea un icono que acompaña a un texto y el enlace los englobe a los dos, en cuyo caso el alt del icono sí deberá ser vacío (ver técnica H2)
si incluye texto, a no ser que dicho texto sea también decorativo, entendiendo como tal (ver criterio de éxito 1.4.9): Text is only purely decorative if the words can be rearranged or substituted without changing their purpose. Example: The cover page of a dictionary has random words in very light text in the background.

23. ¿Es correcto que el contenido de un `input` se borre al coger el foco?

En el criterio de éxito 3.2.2 se especifica que un cambio de contenido no siempre es un cambio de contexto. En este caso es válido que se borre el texto de un input al coger el foco pues supone un cambio de contenido pero no un cambio de contexto.

Por el contrario, no sería válido el comportamiento que se implementa a veces en los campos de fecha o de número de cuenta, en los que al terminar de incluir el contenido del campo el foco salta automáticamente al siguiente campo, pues en este caso sí que es un cambio de contexto. Según se especifica, si se implementa este comportamiento se debe incluir una explicación antes de los campos: consultar la ténica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made

24. ¿Qué se considera texto grande y texto pequeño?

En el criterio de conformidad 1.4.3 se indica:

large scale (text)
with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.

En cuanto al texto incluido en las imágenes se especifica:

Note: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.

25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

El criterio de conformidad 3.3.4 (nivel AA) indica que es necesario que:

los envíos sean reversibles,
o bien que se puedan comprobar los datos y dar la oportunidad al usuario de corregirlos,
o bien que se ofrezca un mecanismo para revisar, confirmar y corregir la información antes de enviarla.

El criterio 3.3.4 sólo obliga a las páginas que:

causen compromisos legales
supongan una transación económica
modifiquen o borren datos controlables por el usuario
envíen respuestas del usuario a algún tipo de prueba

Sin embargo, el criterio de conformidad 3.3.6, que es de nivel AAA y por tanto es más estricto, obliga a cualquier tipo de envío de información.

Se pueden consultar las distintas formulas para implementar estas opciones en las técnicas asociadas a este criterio 3.3.4

Artículos relacionados:

Reseña "WCAG 2.0 made easy" de Olga Revilla

2011-01-29T10:32:00.017+01:00

Autor: Olga Revilla

Nº páginas: 157

Formato: papel y ebook

Idioma: inglés

Web: WCAG 2.0 made easy

Referencia online: One Guideline a Day

Por fin tuve tiempo de leer con calma "WCAG 2.0 made easy" de Olga Revilla, que aunque está escrito en inglés es una lectura ágil, más aun si estás familiarizado con la temática.

"WCAG 2.0 made easy" es un libro muy práctico que recomiendo sin duda no sólo a todos aquellos que quieran comenzar con las WCAG 2.0, sino también a los que ya están trabajando con ellas, puesto que resulta una referencia rápida de gran utilidad (tanto como lo fue su iniciativa One Guideline a Day)

En la primera parte del libro se introducen de forma general las WCAG 2.0 y se explican de forma muy clara aspectos que siempre generan dudas, como son la declaración de conformidad o el tema de las tecnologías compatibles con la accesibilidad.

En los capítulos posteriores aborda cada uno de los criterios de conformidad (agrupados en sus correspondientes principios y pautas) de manera muy didáctica, pues resume las técnicas aplicables a cada uno en:

You must... (Sufficient Techniques)
You should... (Advisory Techniques)
Don`t do! (Commun Failures)

Lo cual resulta, como digo, muy útil y práctico.

No se incluyen las técnicas Flash, que se listan al final del libro en un apéndice. A los que os interese el tema os recomiendo complementariamente Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

Al final del libro incluye otros recursos como una checklist de validación, una tabla de correspondencias entre los puntos de verificación de las WCAG 1.0 y los criterios de conformidad de las WCAG 2.0 así como herramientas de validación. Este apartado es el que quizás podría ampliarse más.

Incluyo otras recomendaciones para el apartado de recursos:

La checklist de validación de Roger Hudson tiene a su favor que incluye las técnicas que se pueden aplicar a cada criterio de conformidad (aunque hay que recordar que el documento de las técnicas está en constante evolución): WCAG 2.0 Checklist
Como alternativa a la tabla de correspondecias entre las WCAG 1.0 y las WCAG 2.0, podéis consultar una en la que además se incluye la correspondencia con los requisitos de la norma UNE 139803 en: Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0
Sobre los validadores podéis consultar una lista más completa en: WCAG 2.0 Validar de acuerdo a las WCAG 2.0

Felicito desde aquí a Olga por su trabajo y le agradezco las palabras que en él me brinda, así como el ejemplar dedicado.

Artículos relacionados:

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

2011-01-21T22:00:00.002+01:00

Descripción: Tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc. (ver descripción detallada de la tabla)

Versión: [20.01.2011] versión 1.0 en castellano

Autor: Olga Carreras

Descarga: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements (Excel, 189 KB)

Descripción detallada de la tabla

La tabla consta de 14 columnas. Los encabezados de las columnas se han bloqueados para que estén siempre disponibles aunque se escrole la tabla verticalmente.

Columna A: Elemento

Incluye todas los elementos (X)HTML (incluidos los de HTML 5) en orden alfabético con enlace a su descripción en la especificación correspondiente. También se incluyen elementos que no están en ninguna especificación del W3C como marquee, spacer, etc. en cuyo caso enlazan con una web de referencia. Es en estos enlaces donde se puede consultar información sobre los atributos de cada elemento.

No se han incluido los elementos que sólo están presentes en XHTML 2. Como excepción se incluye el elemento h de XHTML 2 para documentar los encabezados en esta especificación. Se pueden consultar todas las etiquetas de XHTML 2 en: XHTMl 2.0. List of elements del W3C.

Está primera columna está bloqueada para tener siempre presente el elemento aunque se escrole la tabla horizontalmente.

Columna B: Descripción

Breve descripción del elemento.

Columna C: Desaprobado/No estándar/Obsoleto

En esta columna se indica si los elementos son:

Desaprobado (deprecated): son elementos que están en la especificación HTML 4.01 o XHTML pero que el W3C los ha marcado como "deprecated", desaprobando su uso. No están permitidos en documentos STRICT. Se indica el elemento alternativo que debe usarse.

No estándar: son elementos no estándar, que fueron implementados por algunos navegadores (y que aún las soportan en muchos casos) pero que no pertenecen a ninguna especificación (X)HTML. En cada caso se indica el navegador que las implementó y las alternativas a su uso.

Obsoleto: son elementos de especificaciones anteriores (se indica de cual).

HTML 5: elementos que sólo pertenecen a HTML 5.

En cualquier otro caso la celda correspondiente aparece vacía.

Columna D: Web Browser Support

He documentado el soporte de cada elemento (incluidos los de HTML 5) en las diferentes versiones de navegadores.

Referencias sobre soporte en navegadores:

HTML 4.01 / XHTML 1.0 Reference, about.com

HTML reference, sitepoint.com

HTML, XHTML, and WML support in Opera Presto 2.2, soporte en Opera 10

Web specifications support in Opera Presto 2.7, soporte en Opera 11

When can I use..., compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers

HTML5 Tutorial, w3school.

Comparison of layout engines (Non-standard HTML), wikipedia

En algunos casos se indica el test concreto que se ha realizado para validar un elemento concreto.

Columna E-L: Especificación

Las columnas son:

HTML 4.01

XHTML 1.0 Strict

XHTML 1.0 Transitional

XHTML 1.0 Frameset

XHTML 1.1

XHTML 1.1 Basic

HTML 5

XHTML 2

Cuando la celda correspondiente está verde con el texto "SI" indica que el elemento pertenece a esa especificación.

Cuando la celda correspondiente está roja con el texto "NO" indica que el elemento no pertenece a esa especificación.

Algunas celdas pueden aparecer naranjas con una advertencia dentro. Por ejemplo, en el caso de que el elemento pertenezca a HTML 4.01 pero esté desaprobado y no pueda usarse con HTML 4.01 Strict, la celda correspondiente a la columna E (HTML 4.01) estará coloreada en naraja con la advertencia en su interior.

Columna M: Notas de accesibilidad

En este apartado se incluyen notas relevantes como el soporte en lectores de pantalla, ejemplos cuando se trata de elementos poco habituales, mención a puntos de verificación de las WCAG relacionadas con el elemento en cuestión, etc.

Columna N: ¿Semántico?

En esta columna se indica si es una elemento semántico o si por el contrario es un elemento de presentación. En algunos casos, como se indica, puede depender del uso que se haga de ella.

Referencias:

Semantic (X)HTML, microformats.org

Presentational (X)HTML, microformats.org

Otros enlaces de interés:

Keryx (X)HTML Elements Best Practice Sheet

Podeis dejar en los comentarios cualquier propuesta o anotación para incluir en versiones posteriores.

Últimos artículos modificados (Enero 2011)

2011-01-21T00:10:00.004+01:00

[13.01.2011] Referencia sobre legislación española relacionada con la accesibilidad web. Incluidas novedades del 2010.
[17.01.2011] Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España. Actualizado y modificada la estructura del artículo para hacerlo más comprensible.
[20.01.2011] HTML 5, revisado y actualizado.
[16.01.2011] WCAG 2.0, revisado y actualizado.
[20.01.2011] Sobre el uso de lectores de pantalla, incluido estudio "7. Screen Readers lack emphasis" sobre el soporte de em, i, b, strong, del, ins, blockquote por los lectores de pantalla.
[16.01.2011] Mis validadores, revisado y actualizado.
[16.01.2011] Recursos gratuitos, revisado y actualizado.
[17.01.2011] Glosario: Terminología relacionada con la usabilidad y la accesibilidad, incluye 197 entradas.

Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

2011-01-03T22:12:00.000+01:00

En octubre, el W3C (World Wide Web Consortium) actualizó los documentos "Understanding WCAG 2.0" y "Techniques for WCAG 2.0" incluyendo 36 técnicas específicas para el contenido Flash.

Al igual que en su día preparé una checklist para validar formularios de acuerdo con las técnicas de las WCAG 2.0 (en "Formularios accesibles según las WCAG 2.0"), esta vez he preparado una checklist para validar contenido Flash de acuerdo con estas nuevas técnicas de las WCAG 2.0

Descargar "Checklist para validar contenido Flash de acuerdo con las técnicas de las WCAG 2.0" (Excel, 112 KB )

Es reseñable que el documento de técnicas Flash del W3C ("Flash Techniques for WCAG 2.0") antes de comenzar a explicar estas técnicas que permiten hacer un Flash accesible de forma nativa, incluye tres consideraciones especiales para el cumplimiento de las WCAG 2.0:

2.4.2 Page Titled - In order to meet 2.4.2, Flash content must be embedded within an HTML page that has a page title in the HTML title element. See H25: Providing a title using the title element (HTML).

3.1.1 Language of Page - The language of Flash content is established by the lang attribute of the containing object element in HTML, not within the Flash SWF file itself. Authors may include more than one Flash SWF in a single web page, each with a different language indicated in the object element's lang attribute. See FLASH13: Using HTML language attributes to specify language in Flash content (Flash).

3.1.2 Language of Parts - Since the language of Flash content is not established within the Flash SWF file, it is not currently possible to indicate changes of language within a single SWF file.

Otros artículos de Usable y accesible relacionados con las técnicas de las WCAG 2.0:

Formularios accesibles según las WCAG 2.0

AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

WCAG 2.0

10 razones para pasarse a las WCAG 2.0

WCAG 2.0 Checklist

Asociación compleja de radios y labels de forma accesible

2010-12-22T21:14:00.010+01:00

Una duda que surge a menudo cuando implementas un formulario de forma accesible es cómo asociar correctamente los campos con sus labels cuando estos se presentan de forma compleja.

Esta duda me surgió la semana pasada al ver el diseño de un formulario que incluía la selección del nivel de conocimientos de determinados idiomas, al estilo de:

Remití la duda a la lista de accesoweb y gracias a las sugerencias y aportaciones de sus miembros (especialmente de Gemma Beltrán) encontré el código que considero más adecuado para implementar ese formulario.

He subido el ejemplo a "Ejemplo de asociación compleja entre radios y labels de forma accesible" para que puedan consultar el código recomendado todos aquellos a los que les surja la misma duda.

Como se puede apreciar, visualmente es igual a la imagen anterior. Sin la CSS cargada su aspecto es el siguiente:

Podemos intuir con esta imagen cuál es su estructura, basada en una primera lista para los niveles y una serie de fieldset para cada bloque de selección. Los labels de cada radiobutton están ocultos visualmente (left:-9999em;) pero no así para los lectores de pantalla.

Podéis proponer cualquier propuesta de mejora.

Últimos artículos modificados (Junio 2010)

2010-10-06T14:56:00.003+02:00

Referencia sobre legislación española relacionada con la accesibilidad web
He incluido las novedades legislativas de este año sobre accesibilidad web y he añadido un nuevo apartado donde iré recogiendo a modo de histórico las denuncias por falta de accesibilidad en los portales web españoles.
Glosario de accesibilidad y usabilidad, que alcanza ya las 192 entradas.
Mis validadores, recopilación de herramientas útiles.
Recursos gratuitos, sigo incorporando referencias a recursos de utilidad gratuitos.
Enlaces de interés

Como he cambiado la plantilla, agredecería que me informarais de cualquier problema que detectéis. También se agradece cualquier sugerencia para añadir a los artículos enumerados.

Cambio de imagen

2010-10-05T22:19:00.001+02:00

Estoy cambiando la plantilla del blog. Disculpad por las molestias.

El CERMI denuncia a 9 grandes empresas por falta de accesibilidad de sus páginas de Internet

2010-10-04T09:18:00.001+02:00

El Comité Español de Representantes de Personas con Discapacidad (CERMI) ha denunciado ante el Ministerio de Sanidad y Política Social la ausencia de condiciones de accesibilidad de las páginas oficiales de Internet de nueve grandes empresas españolas.

Las empresas objeto de denuncia han sido la Corporación RTVE, Grupo Santander, Iberia, Alcampo, Grupo Avanza, Jazztel, Orange, Endesa y Gas Natural.

Leer noticia completa

Sobre el uso de lectores de pantalla

2010-02-25T10:38:00.037+01:00

Última actualización: 26 agosto de 2011

20.01.2011 - Añadido estudio 7. "Screen Readers lack emphasis" sobre el soporte de em, i, b, strong, del, ins, blockquote por los lectores de pantalla.
02.03.2011 - Añadido estudio 8. "Screen Reader User Survey 2001 de WebAIM"
26.08.2011 - Añadido resultado de la encuesta realizada por coaccesibilidad.com 9. Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla

Índice

Empty Links and Screen Readers, 2008, Yahoo.
Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos, Sidar
Survey of Preferences of Screen Readers Users, 2009, WebAIM
Screen Reader User Survey Results, 2009, WebAIM
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1, 2003, United States National Cancer Institute
What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users, 2007, Towson University
Screen Readers lack emphasis, 2010, Paciello Group Blog
Screen Reader User Survey 2011, 2011, WebAIM
Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla

1. Empty Links and Screen Readers

Realizado por Mike Davies, desarrollador de Yahoo y publicado en yuiblog.com en enero de 2008. Estudia los problemas de accesibilidad que se encuentran los usuarios de lectores de pantalla ante los diferentes tipos de enlaces.

Los casos que cubre este estudio son:

Enlaces normales con un texto de enlace apropiado
Enlaces sin texto de enlace o sin atributo "title"
Enlaces con atributo "title" pero sin texto de enlace
Enlaces cuyo texto de enlace son sólo espacios en blanco

Cada uno de estos enlaces fue implementado de la siguiente manera:

Se muestra de manera predeterminada (mediante el elemento A sin ocultarlo)
Posicionado fuera de pantalla (posicionamiento negativo)
Se oculta mediante visibility:"hidden"
Se oculta mediante display:"none"

Sus conclusiones son:

Los enlaces siempre deben tener un texto de enlace apropiado y asegurar que el texto del enlace tenga sentido en el contexto. Entonces el enlace puede ser ocultado por posicionamiento fuera de pantalla. Si el enlace se oculta con display:none (no será leído por los lectores de pantalla), garantizar que el contenido tenga sentido con y sin el texto del enlace en su sitio.
Nunca tener un ancla únicamente con el atributo HREF. El lector de pantalla lee la URL completa o trata de extrapolar algo legible de la misma o una combinación de ambas cosas. Esto puede llevar a resultados impredecibles.
Nunca use visibility: "hidden" para ocultar un enlace vacío de la vista. Esto conduce a que el atributo TITLE sea ignorado en JAWS/IE6, y la URL absoluta del enlace sea leída con Firefox. Además provoca una dependencia de las CSS para evitar una barrera de accesibilidad.
Nunca use sólo espacios en blanco como texto de un enlace. La elección del texto del enlace entre las configuraciones testeadas difiere significativamente, con todas las combinaciones se produjeron barreras de accesibilidad - ya sea de la lectura de la URL, o para adivinar el texto del enlace basándose en una extrapolación de la URL, o como en Window Eyes que anuncia un enlace pero sin texto de enlace que leer.
Nunca use display:"none" para ocultar un enlace, pues los lectores de pantalla no lo leen (ver artículo: "JAWS, Window-Eyes and display:none: Return to 2007").
Nunca confíe en el atributo TITLE como único medio para proporcionar una forma de texto del enlace ya que es inconcluyente si el atributo TITLE es permitido por todos los usuarios de lectores de pantalla.

2. Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos

Realizado por SIDAR. Complementa al artículo "Abreviaturas vs. Acrónimos"

Las pruebas indican que ninguna versión de los diversos lectores de pantalla analizados (JAWS hasta la versión 8) responde al atributo "title" de la etiqueta de abreviatura o de acrónimo.

Por ello es muy importante que, al menos la primera vez que se usan en el texto, se expanda su significado en el propio texto. Sería también muy útil que los autores ofrecieran una relación de las abreviaturas y acrónimos que se utilizan en la página.

3. Survey of Preferences of Screen Readers Users

Realizado por WebAIM (enero 2009)

El resultado de la encuesta lo comentó uninstallme en "Preferencias y modos de uso de lectores de pantalla" (01.02.2009)

Esta primera encuesta nos recuerda la importancia de:

Que los enlaces sean significativos, pues el 35% navega por el listado de enlaces de la página.
Incluir un enlace "Saltar al contenido", pues 38% lo utiliza siempre que puede o a menudo y un 28% algunas veces.
Incluir teclas de acceso rápido ("accesskey") pues un 35% las usa siempre que puede o a menudo y un 24% algunas veces.
Que los encabezados deben utilizarse para reflejar la estructura del contenido, pues el 76% navega por los encabezados siempre que puede o a menudo y un 14% algunas veces.
Que el buscador sea fácil de encontrar y usar. El 61% lo buscan dirigiéndose al primer FORM o campo de edición de texto de la página, por tanto debe ser el primero que encuentren.
No abusar de los pop-ups, pues los usuarios con menos experiencia en el uso de lectores de pantallas tienen bastantes dificultades con ellos.
Flash mejor no, el 71% consideran este contenido muy difícil o bastante difícil.

4. Screen Reader User Survey Results

Realizado por WebAIM (noviembre 2009)

La han comentado:

"Resultados de la encuesta a usuarios de lectores de pantalla", de accesibilidadweb.com (02.11.2009)
"Encuestas sobre uso de lectores de pantalla", de Accesibilidad en la web, (17.02.10)

Los elementos más problemáticos que se resaltan son:

CAPTCHA - imágenes que presentan texto para verificar que un formulario lo está rellenando un ser humano.
La presencia de contenido Flash inaccesible.
Enlaces o botones sin sentido.
Imágenes sin texto alternativo o descripciones no adecuadas.
Formularios complejos o difíciles.
Falta de accesibilidad mediante el teclado.
Pantallas o partes de la pantallas que cambian de forma inesperada.
Encabezados ausentes o no adecuados.
Demasiados enlaces o elementos de navegación.
Tablas de datos complejas.
Falta de enlaces "saltar al contenido principal" o "saltar navegación".
Funcionalidad de búsqueda inaccesible o ausente.

5. Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1

Realizado por el United States National Cancer Institute. Aunque es antiguo (2002-2003) resulta muy recomendable.

El objetivo del estudio es:

Comprender la relación entre accesibilidad y usabilidad.
Comprender como las personas ciegas y con poca visión interactúan con los sitios web
Desarrollar directrices de accesibilidad y usabilidad basadas en la investigación
Evaluar la usabilidad de sitios Web específicos para usuarios ciegos o con poca visión.

Establece 32 pautas a seguir:

Guideline 1. Write for the web. Write in short, clear, straightforward sentences. Use bulleted lists. Put the main point at the beginning of a paragraph. Write links that start with keywords.

Guideline 2. Use empty ALT text, ALT="" or use a space as ALT-text, ALT=" " for decorative elements on a page so that users do not have to listen to "decorative bullet image" or "decorative line." Using empty ALT text for decorative elements complies with 508 guidelines. When links are bulleted, there is no need to identify the bullet, just the link name.

Guideline 3. For developers of screen-reading software: Make the commands mnemonic and intuitive.

Guideline 4. For designers and developers of Web sites: Make the site structure clear and obvious. The more obvious the structure of the site, the easier it will be for screen-reader users (as well as for sighted users) to understand and use the site.

Guideline 5. For developers of the screen-reading software: Consider providing training to help users get the most value from the screen-reading software that they use. Consider building easy-to-use demos and tutorials on new features.

Guideline 6. Write "home page" as two words.

Guideline 7. Do not make up unusual names for products, services, or elements of a Web site. Do not combine two or more words into one name. (Of course, these names often predate the Web site, and designers and developers cannot change them. Just do not add to the problem – and alert others to the problem as well.)

Guideline 8. To make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the ACRONYM and ABBR tags as explained at http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr.

Guideline 9. For most Web sites, spend the available time and effort making one version that is accessible to all rather than creating and having to later maintain two separate versions.

Guideline 10. Include a "skip" link at the top of every Web page. Name it "Skip to main content." JAWS reads that correctly as the noun "content" with the accent on the first syllable. That wording was much more meaningful to participants than "skip navigation."

Guideline 11. Make links descriptive. Be sure that the link will be useful by itself, with no surrounding text. Do not use "click here," "more," "answer," or other repetitive words or phrases as links. Look at www.aarp.org for a site that consistently expands what used to be "more" into meaningful links, such as "more travel articles," "more of today's news," and so on.

Guideline 12. Start links with relevant keywords.

Guideline 13. Try not to have many links that start with the same word or phrase. In some ways, these guidelines are obvious and easy to implement. We know that even for sighted users, links should be descriptions of what they go to rather than "click here" or the URL

Guideline 14. Start question headings with a keyword followed by the question.

Guideline 15. Pay attention to the wording on pages and be sure that keywords that users would look up are actually on the page. (This is useful for sighted users, too.)

Guideline 16. Make sure that the keywords are not in images.

Guideline 17. For makers of screen-reading software: Make Find cycle through the entire page.

Guideline 18. Do not create subtle differences between the text on the page and the ALT text that can trip users up when they search for words on the page.

Guideline 19. Use a search engine that provides help with spelling, such as the one at www.google.com.

Guideline 20. Use anchor links when a page has several topics.

Guideline 21. Keep pages from refreshing when users select an anchor link. Do not include a time and date stamp on a page with anchor links.

Guideline 22. Encourage authors to use many headings in their content and to be sure that those headings are clear, meaningful, and parallel. This guideline is critical for both sighted users and screen-reader users.

Guideline 23. Be sure that the headings are coded properly in HTML, for example, as H1, H2, etc. JAWS looks for the heading tag.

Guideline 24. Put the keyword at the beginning of the heading. If many headings are about the same thing, differentiate them in meaningful ways.

Guideline 25. Do not put a lot of text on the same page as a form.

Guideline 26. Do not put a form far down on the page or far to the right.

Guideline 27. Make sure that all fields are coded so that users do not have to switch to and from Edit mode. Use the HTML [label] element. To add more information than is in the label, use the Title attribute.

Guideline 28. In addition to checking your site with an automated tool like Bobby or LIFT, listen to it with a screen reader.

Guideline 29. Do not put information between fields on a form.

Guideline 30. If the user has an option of filling out either of two fields, and they are mutually exclusive, inform the user with the label of the first field.

Guideline 31. Do not exclude labels from fields.

Guideline 32. Avoid making pages refresh.

6. "What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users" (PDF)

Realizado por Towson University en 2007.

Es destacable el apartado Motivos de frustación. Consultar la tabla resumen de los principales motivos de frustación.

7. Screen Readers lack emphasis

Estudio de Paciello Group Blog sobre el soporte de em, i, b, strong, del, ins por los lectores de pantalla. La última actualización del estudio es del 28.01.2010

La conclusión del estudio es que ni JAWS 8.0 ni Window Eyes 5.5 indican al usuario mediante el cambio de voz (o por otro medio) cuando el texto contiene estas etiquetas, ni tampoco tienen la opción de poder definirlo en las preferencias del programa.

Sin embargo, en una actualización posterior, indican que en el caso de JAWS, si bien no se puede configurar en las opciones habituales del programa (Utilities > Configuration Manager > Set Options) si que has a document proofreading scheme called Proofreading (attributes), using this scheme italicized, stricken and bolded text is indicated by a change in voice. Se puede acceder mediante las teclas INS+ALT+S. Se indica que no distingue entre em/i y strong/b.

Por otro lado se señala, ya en los comentarios, que ambos programas sí reconocen las etiquetas, puesto que se puede consultar la información de la fuente de un texto y se indicará si está en negrita, itálica, etc. El problema reside en que no se indica de forma automática al leer el texto (mediante por ejemplo el cambio de voz) la presencia de estas etiquetas.

En los comentarios se indica que VoiceOver (sobre OSX) no reconoce los elementos pero se para al llegar a ellos.

Se propone que el modo para cambiar el énfasis en estos elementos sea mediante la CSS media=audio.

Por último se indica que JAWS sí anuncia "blockquote" en el inicio y el final del texto marcado como tal (notificación que puede ser deshabilitada). Los usuarios pueden sacar una lista de blockquotes en la página mediante CTRL+ INSERT + Q o saltar entre ellos usando la tecla Q. Window Eyes cuenta con un apoyo a la etiqueta blockquote similar a JAWS.

8. Screen Reader User Survey 2011 de WebAIM

En diciembre de 2010 WebAIM realizó una encuesta a usuarios de lectores de pantalla, usuarios que en su amplia mayoría lo utilizan por una discapacidad y que tienen un nivel avanzado o intermedio de uso de la herramienta.

El lector de pantalla para uso general más utilizado fue JAWS (70%) seguido de lejos por Windows-Eyes(19%), VoiceOver(20%) y NVDA (35%), observándose un aumento significativo en el uso de este último (desde el 8% de uso en enero de 2009). También es significativo que el 47% usa más de un lector de pantalla.

Los navegadores con los que usan el lector de pantalla son: IE 8 (43.%), seguido de Firefox 3+ (23.5%), IE7 (12.5%), Safari (9.6%), IE 6 (5.2%) y IE 9 (4.5%). Por tanto Explorer supone un 65.3% de la cuota de navegador.

Los resultados más significativos son:

Sólo el 1.6% de los encuestados tienen javascript deshabilitado frente al 10.4% de 2009.
El 66.7% utilizan un lector de pantalla en el teléfono móvil (las plataformas más utilizadas fueron Nokia con un 42.4% y iPhone/iPod con un 32.6%) que supone un aumento del 550% respecto a enero de 2009.
El 27.5% de los encuestados usan las "accesskey", esto supone una disminución del 38%.
Hay un ligero descenso del uso de los enlaces "saltar".
Ha un incremento de los usuarios que buscan la información prioritariamente a través de los encabezados frente a los que buscan información con la opción de buscar o navegando a través de los enlaces.
Un 60.8% encuentran útil la propiedad LONGDESC aunque hay un 22.7% que la desconocen.
Aumenta el conocimiento de los ARIA landmarks, aunque sigue habiendo un 30.9% que no los conoce.

En contra de la mayoría de las recomendaciones, el 50.3% prefiere dos H1, uno para el nombre del sitio y otro para el título del documento. Sólo un 12.5% prefiere que el H1 sea el nombre del sitio frente al 37.1% que refiere que sea el título del documento.

9. Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla

Encuesta realizada en 2011 a 53 usuarios.

La barrera que menos preocupa a los usuarios es: "Páginas en las que no existe un título que resuma su objetivo o propósito"

Las barreras que más dificultan la navegación según los usuarios son:

Capcha sin alternativa accesible.
Formularios en los que no se indica cómo introducir los datos (etiquetas inexistentes o poco precisas) y en los que resulta complejo detectar qué errores has cometido al cumplimentarlos.
Imágenes con funcionalidad (por ejemplo, un enlace o botón) sin descripción alternativa.
Contenidos que recogen instrucciones visuales (incluyen referencias a colores o a zonas de la página) para ser comprendidos o para llevar a cabo acciones (por ejemplo, frases del tipo “marca el botón rojo”, “activa el enlace situado a la derecha de la imagen”).
Cambios en el contenido que no son percibidos por el lector de pantalla (por ejemplo, nuevos avisos que aparecen en la página, enlaces que aparecen y desaparecen en función de la acción que realizas, etc.)

Enlaces recomendados sobre el tema

Listado de lectores de pantalla y características, en Wikipedia
"Navegando una página Web con Jaws: consideraciones de accesibilidad para desarrolladores", deinterfaz.com (14.10.08)
"Using JAWS to Evaluate Web Accessibility", WebAIM
Mi lista de producción en YouTube "Sobre lectores de pantalla"
"WEB 2.0: Blind to an Accessible New World" (PDF)
"How People with Disabilities Use the Web", del W3C. Existe una traducción al castellano de Alan Chuter, aunque es de un borrador menos reciente que el de inglés "Cómo utilizan la Web las personas con discapacidad"
"Evaluación con lectores de pantalla: preguntas y respuestas", de Sergio Luján Mora
Sobre JAWS: "Assistive Technology Quick Reference", "Keyboard Shortcuts for JAWS", JAWS Keystrokes y Jaws Quick Start Guide (PDF)

Borrador de la traducción oficial al español de las WCAG 2.0

2010-01-11T14:46:00.004+01:00

El último mes he estado abducida por el trabajo. Repasando hoy mis alertas de Google me he llevado la grata sorpresa de que SIDAR ha publicado el borrador de la traducción oficial al español de las WCAG 2.0.

"Abierto el plazo de revision pública de las WCAG 2.0 en español", INTECO, 22/12/2009.

Artículos de este blog relacionado con las WCAG 2.0:

WCAG 2.0

WCAG 2.0

10 razones para pasarse a las WCAG 2.0

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

Formularios accesibles según las WCAG 2.0

WCAG 2.0 Checklist

Mapa conceptual de las WCAG 2.0

Comparativas

Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0

Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0

Validadores

Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

TAW WCAG 2.0

TAW Monitor

Incluir vídeos de YouTube de forma accesible

2009-12-14T08:46:00.014+01:00

Artículos relacionados
[12.04.09] Reseña: "Accesibilidad a los contenidos audiovisuales ..."
[20.11.07] Accesibilidad web y discapacidad auditiva

Insertar el vídeo mediante código válido

YouTube te indica para cada vídeo cuál es su URL y cuál es el código que se ha de insertar en una página para verlo en línea. El código que proporciona es como el que sigue:

   <object width="425" height="344">
<param name="movie"
value="http://www.youtube.com/elvideo">
<param name="allowFullScreen" value="true">
<param name="allowscriptaccess" value="always">
<embed src="http://www.youtube.com/elvideo"
type="application/x-shockwave-flash"
allowscriptaccess="always"  
allowfullscreen="true" 
width="425" height="344">
</object>

El problema de insertar el vídeo mediante ese código es que la página no será XHTML válida. El vídeo se debe insertar con el código que incluyo a continuación, de esta manera el resultado es el mismo pero la página es válida, gramaticalmente correcta.


<object type="application/x-shockwave-flash"
data="http://www.youtube.com/elvideo"
width="425" height="350">
<param name="movie"
value="http://www.youtube.com/elvideo" />
<param name="autostart" value="true" />
<param name="wmode" value="transparent" />
</object>

Recordemos que crear documentos que "estén validados por las gramáticas formales publicadas" (Punto de verificación 3.2 de las WCAG 1.0) es un requisito imprescindible para alcanzar el nivel de adecuación Doble-A.

Nota: es importante mantener los párametros WIDTH y HEIGHT, si sólo se incluye uno de los dos, en Firefox el vídeo no se ve.

Subtítulos

Otro requisito imprescindible para alcanzar el nivel de adecuación Doble-A es proporcionar subtítulos que describan todo el audio presente (Punto de verificación 1.4 de las WCAG 1.0).

Gracias a los subtítulos aquellos usuarios que no puedan oír el audio podrán leerlo:

Usuarios con problemas de audición.
Usuarios en ambientes ruidosos.
Usuarios con dispositivos sin tarjeta de sonido.
Usuarios con el audio desactivado (por ejemplo si no quieren que se entere toda la oficina de lo que están viendo [sonrisa])
etc.

Hay que tener en cuenta que otra ventaja de añadir subtítulos es que ahora que YouTube los va a traducir automáticamente, nuestros vídeos tendrán una audiencia significativamente mayor.

YouTube ya dispone de subtitulado automático en algunos canales y pronto estará disponible para todos los vídeos, aunque no podemos esperar que sea 100% fiable.

YouTube también permite incluir manualmente subtítulos en los vídeos. Como se ve en la siguiente imagen, en el apartado "Títulos y subtítulos" puedes subir uno o varios (en diferentes idiomas) ficheros de subtítulos:

Se han de subir ficheros ".srt" o ".sub".

Estos ficheros se pueden crear de forma muy sencilla con la herramienta online CaptionsTube, que te permite seleccionar el vídeo de YouTube, crear y editar los subtítulos y después descargarlos.

YouTube proporciona también desde hace poco tiempo la opción de subir un fichero con la transcripción completa del audio. De forma automática, por reconomiento de voz, incluirá cada subtítulo donde le corresponde. Está todavía en beta y sólo disponible en inglés (y tampoco podemos esperar que sea 100% fiable).

La transcripción se sube desde la misma pantalla de "Títulos y subtítulos" que veíamos antes, seleccionando la opción "Archivo de transcripción (sólo en inglés) beta" como se explica en este vídeo:

[Insertado con el código modificado]

[Insertado con el código habitual]

Transcripción completa

Por último, otro requisito que hay que cumplir para alcanzar el nivel de adecuación Doble-A es incluir una transcripción que transmita de forma completa toda la información: información de los personajes, trascripción completa, acciones, lenguaje corporal, contexto y cambios de escena, etc. (Punto de verificación 1.4 de las WCAG 1.0)

Gracias a la transcripción:

Los usuarios con problemas de visión podrán acceder a una descripción de lo que se ve en el vídeo.
Los usuarios que no puedan visualizar el vídeo, por el dispositivo que utilizan o su configuración, podrán acceder a su contenido.
Los motores de búsqueda indexaran el contenido del vídeo y se podrán realizar búsquedas en él.
Facilita el acceso al contenido a las personas que no hablan el idioma del vídeo.
etc.

La transcripción puedes hacerla tú mismo, pagar para que te la hagan o realizarla mediante software de reconocimiento de voz.

La opción más práctica y que asegura un resultado de mayor calidad es sin duda contratar a una empresa especializada que haga la transcripicón, puesto que los precios son suficientemente razonables (se puede encontrar por 60 euros la hora de audio). Hay empresas que te hacen los subtítulos, la transcripción y las traducciones a los idiomas que desees con descuentos interesantes.

La forma de incluir la transcripción puede ser mediante un enlace que lleve a un fichero de texto o HTML donde se incluya la transcripción, incluirlo directamente en la página o recurrir a otras prácticas llamativas como la que vemos en The New York Times o en su versión en rtve.es [visto en Sortega]

Sin entrar en la accesibilidad de este visor implementado en Flash, sí que es interesante ver como muestran la transcripción al lado del vídeo, la posibilidad de buscar palabras clave, el índice de temas y duración, o en la versión original la línea de tiempo.

Documentos que recomiendo conocer (8)

2009-12-13T11:35:00.001+01:00

Serie "Documentos que recomiendo conocer"

Manuales

"Involving Users in Web Projects for Better, Easier Accessibility" (WAI) y "Involving Users in Evaluating Web Accessibility" (WAI)

Este tema lo trate en:
- Reseña "Just Ask: Integrating Accessibility Throughout Design"
- "Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI"

"Diseño para todos, un conjunto de instrumentos", Francesc Aragall (PDF)

"Libro Blanco del Diseño para Todos en la Universidad", IMSERSO (PDF)

"Introduction to Goof Usability", Peter Conradie, 2008 (PDF)

"Mobile Web Developer's Guide", mTLD, 2007 (PDF)

"Cómo crear contenidos educativos accesibles para plataformas e-learning", Mª Ángeles Alonso Navarro, 2009 (PDF).

"Guía de recomendaciones de accesibilidad y calidad web", Inteco, 2009, en SlideShare

"Web Style Guide", Patrick J. Lynch and Sarah Horton, online.

"BlackBerry Browser. Content Design Guidelines"

Presentaciones

"¿Cómo convencer a mis clientes?", David Eguizábal, 2009, en SlideShare. Visto en Consultoría en red.

"¿Cómo atraer a mis clientes?", Marta Naudín, 2009, en SlideShare. Visto en Consultoría en red.

"The ideal UX Team and whay they produce", UX Toronto, 2009, en SlideShare. Visto en torresburriel.com

"A Kit for Building User Experience Teams", 2009, Paul Sherman, (PDF). Visto en Sortega.

"Informe APEI sobre Usabilidad", Yusef Hassan Montero y Sergio Ortega Santamaría, 2009, (PDF)

"Análisis de entrada a 23 webs", Arquinauta, 2009, en SlideShare.

Vídeos

"Accesibilidad Web y las pautas WCAG 2.0", Jesús García. Responsable Unidad de Accesibilidad y Estándares Web. Fundación CTIC

"Impacto de las pautas WCAG 2.0", José Angel Valderrama. Gerente de nuevas tecnologias. AENOR.

"Accesibilidad en las instituciones públicas". Mesa redonda.

Otros

"Multimedia Accessibility FAQ" del W3C

Cheatsheet W3C

Imprescindibles (18)

2009-12-12T17:49:00.000+01:00

Estos son los artículos que llamaron últimamente mi atención (no tienen porque ser recientes):

Serie "Imprescindibles" (recopilación de artículos de interés)

Enlaces en los que perderse (6)

2009-12-11T22:17:00.000+01:00

"An Introduction to Understanding and Implementing Web Usability ", speckboy.com, 2009

We have collected the best resources for learning about web usability; there are downloadable eBooks, online manuals, printable guidelines and useful checklists. Hopefully these resources will give you a better insight and understanding.

"50 Essential Free Open Courseware Classes for Web Designers", bestwebdesignschools.com, 2009

"30 Must Have WebDesign Books In Your Christmas Wishlist", 1stwebdesigner.com, 2009

Presentaciones del evento "Usabilidad en Latinoamérica", 2009

"Nuevas tendencias para promocionar websites de éxito a través del diseño", Maestros del web, 2009

Artículos relacionados:

Noticias... (22)

2009-12-10T11:30:00.004+01:00

Estas son las noticias que llamaron mi atención en el último mes:

Discapacidad auditiva

"Andalucía hará obligatorio por ley el lenguaje de signos en los servicios públicos", elmundo.es, 10.11.09

La norma, que amplía la legislación estatal de 2007, se aplicará en los servicios públicos, las relaciones con las administraciones, el transporte, los medios de comunicación, la participación política y las telecomunicaciones.
Artículo relacionado: "Referencia sobre legislación española relacionada con la accesibilidad web"
IU exige que se cumpla la ley que reconoce la LSE, Diario Signo, 02.12.09

Izquierda Unida de Albacete ha emitido un comunicado en que tras apoyar los derechos de las personas sordas, anuncia su intención de trasladar a los Ayuntamientos la exigencia de que se cumpla la ley que reconoce la Lengua de Signos Española en el ámbito regional y estatal.
"Google añade subtítulos automáticos para sordos en YouTube", gigle.net, 20.11.09

De momento esta nueva característica se está desplegando en la versión inglesa de YouTube en todo el mundo, aunque se espera que en breve se extienda al resto de lenguas. Estos subtítulos automáticos han sido habilitados en los canales de YouTube de la Universidad de Berkeley, Stanford, MIT, Yale, UCLA, Duke, UCTV, Columbia, PBS, National Geographic.
"Caser ofrece sus servicios en lengua de signos", caser.es, 26.11.09

SVIsual es un servicio gratuito y pionero en nuestro país,que permite a cualquier persona sorda contactar telefónicamente en tiempo real con otras personas oyentes a través de la figura del videointérprete, lo que garantiza una comunicación directa e inmediata entre emisor y receptor.

Para ello, sus usuarios pueden utilizar la lengua de signos española o cualquier otra modalidad comunicativa que soliciten en función de sus necesidades o características gracias a los servicios de signo y voz, mensajería instantánea o video mail, que permiten ofrecer un servicio personalizado.
"www.asorna.org, una propuesta para superar barreras", noticiasdenavarra.com, 25.11.09

Los menús con vídeos en la Lengua de Signos también se pueden ver en el portal de la Confederación Estatal de Personas Sordas.

"La administración de EE. UU quiere que sus páginas web sean accesibles para las personas sordas ", Diario Signo, 23.11.09

Las páginas web de la administración norteamericana deberán ser accesibles a las personas sordas. Una ley federal - la Ley de Rehabilitación - exige que las agencias federales electrónica y de tecnología de la información sea accesible a personas sordas.
"Unas gafas convierten la voz en subtítulos", seraccesible.net, 12.11.09

En el Tokyo International Forum han sido el producto estrella, unas gafas capaces de subtitular en tiempo real lo que el interlocutor que hay delante de la persona que las lleve puestas pronuncie.

Discapacidad visual

"Intel Reader: Un novedoso dispositivo de Intel para personas con capacidades disminuídas en la visión",ulczyk.blogspot.com, 13.11.09
Código de barras accesible, Al límite de mi capacidad, noviembre de 09.

La Empresa DATAMATRIX lanzó un código especial que permite que al hacer una foto con un móvil adaptado, una persona no vidente reciba la información a través de un mensaje de voz.

Otros

"Los sitios Webs de los ministerios parece que mejoran en materia de Accesibilidad Web", accesibilidadweb.com, 13.11.09
"IBM simplifica la navegación Web a través del móvil", en eWeekEurope, octubre 2009.

Para ayudar a los webmasters de todos los niveles, los investigadores (que se encuentran en Tokio) han desarrollado una tecnología basada en un editor visual que les permite organizar el contenido del sitio web en una secuencia lógica ordenada, sin modificar el contenido existente, para que se pueda leer fácilmente en las pantallas de los dispositivos móviles.

Además, la herramienta de edición también puede mejorar la experiencia de navegación para discapacitados visuales que utilizan navegadores de voz para leer el contenido Web, por ejemplo.
Extensiones para Google Chrome
Hoy se estrena el nuevo portal de la Universidad de Barcelona.
Asitente virtual e24Presenter

Serie "Noticias"

Reseña "Just Ask: Integrating Accessibility Throughout Design"

2009-11-10T12:30:00.016+01:00

Artículos relacionados:

En este artículo voy a resumir los puntos esenciales del libro "Just Ask: Integrating Accessibility Throughout Design" de Shawn Lawton Henry (2007), el cual está disponible en versión online en español ("Simplemente pregunta: Integración de la accesibilidad en el diseño").

El libro trata sobre los fundamentos de la inclusión de la accesibilidad en los procesos de Diseño Centrado en el Usuario (UCD).

Este libro es recomendado como guía de referencia por la WAI.

Matizan, como también se hace a menudo a lo largo del libro, que incluir a las personas con discapacidad en la evaluación reporta muchos beneficios pero no determina por sí mismo si un sitio es accesible, siempre debe combinarse con la evaluación conforme a las WCAG.

Principios básicos

Integrar la accesibilidad al principio y a lo largo de todo el proyecto.

Tener en cuenta la accesibilidad al principio en un proyecto de diseño es mucho más fácil, eficaz y barato que hacerlo posteriormente.
Contar con la participación de personas con discapacidad en tu proyecto

Los estándares y pautas son sólo una parte de la ecuación en lo que se refiere al adecuado desarrollo de productos accesibles. La otra parte es comprender los problemas de accesibilidad, y la mejor forma de hacerlo es trabajar con personas con discapacidad para saber cómo interactúan con tus productos.
Relacionarse con personas con discapacidad. Recomendaciones para relacionarse con las personas con discapacidad

Contexto: Accesibilidad en el Diseño Centrado en el Usuario

En este capítulo se introducen los conceptos básicos de accesibilidad, usabilidad y DCU.

El objetivo de incorporar la accesibilidad al Diseño Centrado en el Usuario es seguir un "proceso de creación de productos (dispositivos, entornos, sistemas y procesos) que sean usables para personas cuyas capacidades estén dentro del segmento más amplio posible y que se encuentren en situaciones (entornos, condiciones y circunstancias) dentro del espectro más amplio posible, siempre y cuando sea práctico desde el punto de vista comercial".

El proceso de Diseño Centrado en el Usuario se divide en tres fases principales: análisis, diseño y evaluación.

El DCU es un proceso para diseñar productos usables y la accesibilidad de los interfaces de usuario puede considerarse un subgrupo dentro de la usabilidad. Por tanto, se deduce que los diseñadores pueden utilizar el DCU para diseñar productos que sean accesibles. En la práctica, las técnicas de diseño accesible encajan bien con los procesos de DCU ya establecidos.

Después de añadir y adaptar algunos aspectos, los equipos de diseño pueden utilizar las prácticas típicas del DCU para centrar el diseño en la accesibilidad. Integrar la accesibilidad al DCU significa que los diseñadores deben tener en cuenta la muestra de usuarios y situaciones más amplia posible.

Análisis

Es la primera fase de un proceso de DCU.

Ten cuidado y no des por sentado que los comentarios de una persona con discapacidad se pueden aplicar a todas las personas con discapacidad. Una persona que tenga una discapacidad no tiene por qué saber necesariamente cómo van a interactuar otras personas con su misma discapacidad con esos productos, ni tiene por qué saber lo suficiente sobre otras discapacidades como para poder proporcionar consejos válidos sobre otros problemas de accesibilidad.

En este apartado se aborda cómo tener en cuenta los aspectos relacionados con la accesibilidad en la definición de perfiles de grupos de usuarios, en la creación de personajes y en la creación de escenarios.

Diseño

Es la segunda fase de un proceso de DCU.

Los diseñadores de productos a los que se les exige que cumplan con unos estándares de accesibilidad específicos suelen pasar directamente a la parte técnica del estándar sin llegar a entender los problemas de accesibilidad. Intentar cumplir con los estándares de accesibilidad sin entender qué es la accesibilidad no es sólo frustrante, sino que no da resultado.

[...]

Usar estándares y pautas te ayudará a garantizar que se tienen en consideración todos los problemas de accesibilidad y contar con la colaboración de personas con discapacidad te ayudará a abordarlos de una forma eficiente y eficaz.

[...]

Evaluar prototipos iniciales te ayudará a validar ciertos aspectos del diseño que funcionan correctamente y a encontrar barreras potenciales de accesibilidad en un momento en el que todavía es relativamente fácil y poco costoso arreglarlas.

Evaluación

Es la tercera fase de un proceso de DCU.

La evaluación de la accesibilidad suele verse limitada a la comprobación de la conformidad con los estándares de accesibilidad.

La conformidad con estos estándares es importante: en algunos casos es un requisito legal y en otros es sólo una buena forma de comprobar que se han tenido en cuenta, adecuadamente, todos los problemas de accesibilidad.

Sin embargo, cuando se presta atención solamente a los aspectos técnicos de la accesibilidad, el factor de la interacción humana puede llegar a perderse. Los métodos de evaluación de la usabilidad pueden comprobar la accesibilidad usable para garantizar que tus soluciones de accesibilidad son usables para las personas con discapacidad.

Técnicas de filtrado

Las técnicas de filtrado implican la utilización de estrategias de adaptación, dispositivos de ayuda y tecnologías de apoyo.

Por ejemplo, que un diseñador de software apague su monitor y utilice un lector de pantalla para interactuar con su aplicación o que un especialista en usabilidad utilice un puntero bucal o desenchufe su ratón para hacerse una idea de cómo de usable es su producto para las personas que no puede usar los brazos o las manos.

Las técnicas de filtrado no son simulaciones de discapacidades. Es probable que a las personas con discapacidad les resulte más fácil utilizar el producto que a las personas que estén utilizando técnicas de filtrado.

Se utilizan porque son fáciles, rápidas y económicas y identifican problemas potenciales de diseño en la fase inicial, lo que evita altos costes de rediseño y retrasos en el proceso.

Por ejemplo en "Preliminary Review of Web Sites for Accessibility" de la WAI se citan determinadas técnicas de filtrado.

Planificación de las pruebas de usabilidad

Los cuatro grupos más habituales de discapacidades (visuales, auditivas, físicas y cognitivas) no son suficientes para categorizar las características de los participantes en un estudio de usabilidad, debido a la diversidad que existe dentro de cada categoría (la discapacidad puede ser temporal o permanente, puede haber nacidocon ella o no, pueden usar diferentes tecnologías de apoyo, etc.).

Por otra parte, el número de participantes con discapacidad que forman parte de una prueba de usabilidad concreta suele estar determinado por los limitados recursos de un proyecto.

Teniendo en cuenta estas dos variables, el autor nos da una serie de consejos sobre la selección de las personas, siendo importante recalcar que hay que evitar cometer el error de pensar que un participante los representa a todos.

Cómo completemento proporciona un Formulario de selección de participantes que se utiliza para determinar si un participante potencial encaja con las características de usuario definidas en el protocolo de la prueba de usabilidad

A la hora de decidir dónde se realizan las pruebas de usabilidad es importante tener en cuenta las tecnologías de apoyo, por ejemplo puede que los participantes no sepan cómo configurar las tecnologías de apoyo en tu laboratorio para poder trabajar, porque están acostumbrados a que funcionen de una forma determinada en sus sistemas.

También es importante planificar el tiempo y los descansos en base a las características de cada discapacidad.

Preparación de las pruebas de usabilidad

En este capítulo se dan muchos consejos prácticos para la preparación de las pruebas (instalaciones, materiales, etc.)

Realización de las pruebas de usabilidad

En este capítulo se abordan las cuestiones que permitirán realizar con éxito las pruebas (acondicionamiento de la sala, orientación del participante, recogida de datos, etc.)

Elaboración de informes

Para analizar los datos y realizar informes sobre un estudio de usabilidad que ha contado con participantes con discapacidad, hay que tener en cuenta las siguientes consideraciones:

Distinguir entre los problemas de usabilidad (es decir, que influyen a todos los usuarios por igual, independientemente de sus características) y de accesibilidad (es decir, reducen el acceso de las personas con discapacidad a un producto).
Incluir parámetros relevantes del estudio, por ejemplo las estrategias de adaptación y tecnologías de apoyo que utiliza cada usuario y su experiencia con productos similares.
Tener cuidado con las categoriaciones y las comparaciones, especialmente si la amplitud del muestreo es pequeño.
Elaborar conclusiones claras. Hay que dejar claro qué afirma el informe y qué no. Por ejempplo, unos resultados positivos en las pruebas de usabilidad no garantizan que el producto sea accesible para todas las personas con discapacidad, ni que cumpla los estándares de accesibilidad.
Utilizar un lenguaje apropiado para referirse a las personas con y sin discapacidad.

Lista de verificación para las pruebas de usabilidad

Este apartado es muy útil porque resume todos los puntos tratados en los capítulos referidos a la fase de Evaluación en una checklist.

Recursos

Selección de recursos y enlaces de interés (no se actualiza desde 2004)

Artículos relacionados:

Cuando los problemas de usabilidad afectan a la vida real de las personas

2009-11-09T20:49:00.007+01:00

Estoy furiosa. Supongo que no debería escribir furiosa, pero que le vamos hacer.

Esta mañana me he vuelto a enfrentar a la web de "Cita previa" del Gobierno de Aragón, un servicio que debería facilitarnos la vida y no complicárnosla más.

Lo sencillo sería poder ver las franjas horarias de un día y de un vistazo comprobar las que están libres y seleccionar una. Eso sería lo sencillo, claro.

En su lugar tienes que introducir la hora a la que quieres la cita, el sistema hace la consulta y te sale una alerta (sí, sí, un "alert") proponiéndote la hora libre más cercana, a partir de ahí, a prueba y error, vas introduciendo horas hasta que te propone una que te va bien. Tampoco puedes probar mucho porque entonces te impiden seguir y tienes que salir y volver a entrar al sistema.

Tanteé varias horas, el sistema me propuso las 16:45 y acepté.

Saqué a la niña del colegio antes, cogí un taxi y esperé con ella hora y media en la consulta porque acumulaban mucho retraso. Entonces, cuando me tocaba entrar, llamaron a una persona que tenía hora para las 16:55, es decir, posterior a la mía.

En un momento de lucidez una terrible sospecha me vino a la cabeza... sería posible que...

Me acerco a recepción y le pido a la amable señorita que compruebe si mi cita está registrada. En efecto, lo estaba... pero, como sospechaba, para el día siguiente. La chica me consoló diciéndome que eso mismo le había pasado hoy a varias personas. Como el caso no era urgente siempre podía espera otra horita u horita y media para que la viera el médico.

Quien tiene hijos sabe que esperar hora y media en la consulta es una odisea, pero esperar tres es un suicidio. Así que volveremos mañana otra vez.

¿Que pasó? Como el día de hoy estaba completo, el sistema de "Cita previa" me dió la primera hora libre para el día siguiente. ¿Tanto costaba poner un mensaje indicando que para hoy no había horas libres? ¿Tanto costaba remarcar que la cita me la daban para otro día?

¿Es que los que han ideado esta web no piden cita a través de ella? Intentar pedir una revisión para un niño es imposible. Primero no puedes indicar que quieres una cita para revisión, segundo no te informan si para esa revisión debes pedir cita con la enfermera o también con el médico, en cuyo caso, ¿cómo podría a prueba y error encontrar un día y una hora en que ambos estén disponibles? ¿es un juego de azar para poner a prueba tu inteligencia o es un sistema para ayudar al ciudadano?

Por favor, si me lee algún responsable del sistema de "Cita previa", se lo suplico, háganos un favor a mucha gente, mejoren la usabilidad de la aplicación, no pido mucho, sólo que apliquen el sentido común.

En fin, como digo, estoy bastante enfadada.

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

2009-10-30T21:49:00.024+01:00

Artículos relacionados

Respuesta a 25 dudas habituales sobre accesibilidad web (enero 2011)

Formularios accesibles según las WCAG 2.0 (junio 2009)

WCAG 2.0 (febrero 2008)

1. ¿Cómo marcar adecuadamente un emoticon?

La técnica H86: Providing text alternatives for ASCII art, emoticons, and leetspeak de las WCAG 2.0 nos indica cómo hacerlo adecuadamente.

Recomienda cuando sea posible usar simplemente una palabra en vez de un icono gestual. Pero si se usa un emoticon debe tener siempre un texto alternativo.

El ejemplo de marcado correcto que propone la técnica es:

=8-0 (fright) <abbr title="fright">=8-0</abbr> <img src="fright.gif" alt="fright"/>

2. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?

En el diseño actual de páginas Web es habitual la maquetación en varias columnas. En este contexto, la pauta 3.5 de las WCAG 1.0 se puede convertir en un quebradero de cabeza, puesto que indica que "elementos H2 deberían seguir a los elementos H1, los H3 deberían seguir a los elementos H2, etc" ["Técnicas HTML para las Pautas de Accesibilidad al Contenido de la Web 1.0"]. De hecho, la validación automática dará un error en aquellas páginas en las que un H2 se encuentre antes que un H1.

Este problema se corrige en las WCAG 2.0. La técnica "H42: Using h1-h6 to identify headings" incluye un ejemplo significativo, en el cual el título del contenido principal coincide con el título de la página y está marcado como "H1" aunque no es el primero que aparece en la página. El contenido de la primera y tercera columna es menos importante y está marcado con "H2".

De modo que no es necesario que H1 aparezca antes que H2, lo importante es que realmente el título marcado como H1 sea de primer nivel y los marcados como H2 de segundo nivel.

Desgraciadamente el validador automático TAW para las WCAG 2.0 sigue mostrando un error en aquellas páginas que muestran un H2 antes que un H1 en el código.

La buena noticia es que me han dicho que lo van a corregir en la próxima versión.

3. ¿Es recomendable incluir una opción de "Leer está página"?

En algunos sitios nos encontramos una opción que permite leer el contenido de la página (por ejemplo con Vozme), ¿se recomienda esta práctica?

En respuesta a esta duda podemos consultar la técnica G79: Providing a spoken version of the text (asociada al criterio de éxito 3.1.5, de nivel AAA) en donde sí se recomienda.

A mí siempre me ha parecido que es útil cuando lee el contenido y no toda la página, puesto que para leer toda la página los usuarios que lo necesitan ya utilizan un lector de pantalla, que evidentemente tiene muchas más funcionalidades.

4. ¿Cuánto se ha de poder ampliar el tamaño de un texto?

El criterio de éxito 1.4.4 (nivel AA) indica que a excepción de los títulos y las imágenes de texto, el texto debe poder cambiar su tamaño, sin una tecnología asistiva, hasta un 200% (es decir, hasta dos veces el ancho y la altura) sin pérdida de contenido o funcionalidad:

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%.

Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing.

Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

5. ¿Cómo marcar la pronunciación de una palabra?

En el criterio de éxito 3.1.6 (nivel AAA) se indican distintas técnicas. La más sencilla es colocar la pronunciación entre paréntesis tras la palabra, pero hay otras como incluir un glosario con la pronunciación de las palabras o asociar la palabra con un fichero de audio donde se escuche su pronunciación.

Sin embargo, la solución que más ha llamado mi atención es la que se describe en la técnica H62: Using the ruby element, en la cual se propone utilizar el elemento RUBY.

Ejemplo:

When we talk about these guidelines, we often just call them WCAG ( Wuh-KAG )

Si estás usando Explorer, que soporta este elemento desde la versión 5.0, verás escrita la pronunciación sobre el acrónimo "WCAG"; si accedes desde Firefox, Opera o Chrome la pronunciación la encontrarás tras el acrónimo entre paréntesis; si accedes con un lector de pantalla como JAWS oirás "uve doble ce a ge abre paréntesis gu kag cierra paréntesis".

El código del ejemplo es:

<p>When we talk about these guidelines, we often just call them
  <ruby>
    <rb>WCAG</rb>
    <rp>(</rp>
      <rt>Wuh-KAG</rt>
    <rp>)</rp>
  </ruby>.
</p>

Hay que tener muy presente que esta solución sólo sirve para páginas XHTML 1.1, pues es un elemento que no está definido en versiones anteriores. Por tanto, si lo utilizas con HTML 4 o XHTML 1.0 la página no será válida.

Para más información sobre RUBY:

Ruby Annotation. W3C Recommendation 31 May 2001 (Markup errors corrected 25 June 2008).

Canal YouTube

2009-10-27T13:56:00.004+01:00

Este fin de semana me he estado divirtiendo personalizando el canal YouTube "Usable y accesible".

El objetivo del canal es recopilar vídeos relacionados con la accesibilidad y la usabilidad web. Cualquier sugerencia sobre vídeos que podría incluir será bien recibida.

Personalizar el canal es bastante sencillo, pero incluir un banner o enlaces, como se ve por ejemplo en el canal de Antena 3 o de U2, está sólo disponible para los parners de Youtube.

Cualquiera puede solicitar entrar dentro del programa de parterns, pero las solicitudes se revisan teniendo en cuenta diversos criterios, entre los que se incluyen el volumen de la audiencia, el país de residencia, la calidad del contenido y el cumplimiento de las "Normas de la comunidad" y de los "Términos de uso".

Así que si tu canal no es famoso ni tiene muchas visitas es difícil que te acepten la solicitud, en cuyo caso no puedes volver a presentarla durante dos meses.

YouTube te permite vincular la cuenta de YouTube, Twitter y Facebook, de esta manera es más fácil seguir las novedades del canal.