Usable y accesible

Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

2012-05-06T01:12:00.000+02:00

Falso Error 1: campo de texto sin LABEL asociado... pero que tiene un TITLE adecuado

Los criterios de conformidad 1.1.1, 1.3.1, 3.3.2 y 4.1.2 hacen referencia a que un campo de formulario debe estar correctamente identificado, lo que en las WCAG 1.0 era el punto de verificación 12.4 Asocie explícitamente las etiquetas con sus controles. [Prioridad 2]

En estos cuatro criterios de conformidad de las WCAG 2.0 se admite una de estas dos técnicas suficientes para cumplirlos:

H44: Using label elements to associate text labels with form controls
H65: Using the title attribute to identify form controls when the label element cannot be used

Aunque lo más recomendable siempre es utilizar la técnica H44 y asociar cada campo de formulario (salvo los de tipo button o los input de tipo image, submit, reset y hidden) con su correspondiente label, hay casos en los que no podemos usar label o este podría resultar confuso. En esos casos podemos usar la técnica H65, es decir, no etiquetar el campo con label sino usar el atributo title para etiquetar el campo e identificar su propósito.

Ejemplos en los que podríamos usar el atributo title de un campo de formulario para etiquetarlo en vez de etiquetarlo con label:

Cuando para introducir una fecha o un código de cuenta en un formulario tenemos varios campos (por ejemplo campos diferentes para día, mes, año). En estos casos podemos identificar cada uno de esos campos con el atributo title (sin necesidad de que cada uno tenga un label)
Cuando tenemos un campo de búsqueda y un botón Buscar sin una etiqueta previa "Buscar" o "Buscador". Si debemos respetar el diseño podemos etiquetar el campo de búsqueda mediante su atributo title. En este caso además contamos con la técnica suficiente G167 Using an adjacent button to label the purpose of a field, en la que se indica concretamente que un botón "Buscar" justo a continuación de un campo de búsqueda es suficiente para cumplir con el criterio de conformidad 3.3.2
Una tabla en la que el contenido de alguna de sus celdas sea un campo de formulario. Por ejemplo la tabla resumen de tu pedido en un ecommerce, en la que el contenido de una de sus columnas sea un campo editable con el número de unidades de cada producto.

Sin embargo, hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un campo sin un label asociado, aunque este tenga un atributo title adecuado.

Validadores que SÍ dan este falso error: Examinator

Validadores que NO dan este falso error: TAW, AChecker, Deque Worldspace Free Analysis, AccessMonitor

Falso Error 2: imagen que es un enlace y tiene ALT vacío... pero que va acompañada por un texto dentro del enlace

Es el siguiente caso, correcto como se puede consultar por ejemplo en la técnica H2, y que por tanto no está incumpliendo el criterio de conformidad 1.1.1:

<a href="ayuda.html"><img src="image/ayuda.gif" alt="" /> Ayuda</a>

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran una imagen dentro de un enlace si dicha imagen tiene ALT vacío, sin tener en cuenta que puede ser un caso como el descrito.

Validadores que SÍ dan este falso error: AChecker

Validadores que NO dan este falso error (o solo advierten que las imágenes decorativas es mejor incluirlas en las CSS): TAW, Examinator, Deque Worldspace Free Analysis, AccessMonitor

Falso Error 3: H2 presente en el código antes que un H1... sin tener en cuenta que estén bien marcados

La técnica H42 Using h1-h6 to identify headings, incluye un ejemplo 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".

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.

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un encabezado superior colocado en el código después de uno inferior, cuando solo deberían reportar una advertencia para que se revise que están bien marcados.

Validadores que SÍ dan este falso error: Deque Worldspace Free Analysis

Validadores que NO dan este falso error: TAW (en una versión anterior sí daba error pero ya está corregido), Examinator, AChecker, AccessMonitor

Falso Error 4: indicar en cualquier caso que es obligatorio incluir enlaces para saltar bloques de contenido y un primer enlace en la página que lleve al contenido principal de la misma

El criterio de conformidad 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web (Nivel A), se puede cumplir de dos formas diferentes (tal y como se puede consultar en Understanding SC 2.4.1):

Agrupando los bloques de contenido de manera que los productos de apoyo puedan reconocerlos y saltarlos: estructurar las páginas con encabezados, agrupando los enlaces en listas, etc.
Proporcionando enlaces para saltar los bloques de contenido, en cuyo caso se ofrece un listado de técnicas de las que es necesario elegir al menos una, entre ellas las dos que comento.

Por tanto, no se puede reportar siempre y en todos los casos como error que no haya un enlace al comienzo de la página para ir al contenido principal. Puede que la página esté bien estructurada y por tanto se esté cumpliendo con el criterio de conformidad 2.4.1. Puede además que no haya claramente un área de contenido principal y por tanto este enlace no resulte útil.

De la misma manera, no se puede reportar siempre y en todos lo casos que no haya enlaces para saltar bloques de contenido.

Y en cualquier caso, no se debería incluir como error ambas, sino indicar que al menos es necesario una de ellas.

Validadores que SÍ dan este falso error: Examinator, AccessMonitor

Validadores que NO dan este falso error: TAW, Deque Worldspace Free Analysis, AChecker

Hasta aquí los que he detectado por ahora. ¿Conocéis más falsos errores?

Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas

2012-03-28T00:21:00.008+02:00

El objetivo de este artículo es explicar cómo podemos tener una descripción extensa de una imagen en la propia página, de tal manera que:

sea accesible para los lectores de pantalla
se visualice cuando la imagen no esté cargada (bien porque tenemos las imágenes desactivadas, bien porque ya no se encuentra disponible, etc.)

Todo ello sin depender del atributo longdesc, que no siempre es soportado, ni de los típicos enlaces [D] junto a la imagen (conocidos como D-Link); y asegurando que no dé problemas cuando se deshabilita el javascript o las CSS.

Este artículo se me ocurrió después de leer el artículo de Steve Faulkner Detecting if images are disabled in browsers, en el cual explicaba cómo podemos detectar por javascript si las imágenes están deshabilitadas o no se han cargado.

Ver la página de ejemplo

Descargar el ejemplo (RAR, 13Kb)

La descarga y uso del ejemplo es completamente libre, pero os agradecería mucho que compartierais mejoras que se os ocurran o problemas que detectéis.

He probado su funcionamiento con NVDA, Explorer 7, Explorer 8, Explorer 9, Firefox 1.5, Firefox 2, Firefox 3, Firefox 11, Chrome 17, Opera 11, Safari 5 (para Windows) y desde una BlackBerry y una iPad. En Explorer 6 no hay problema para visualizar la descripción, pero se ve siempre presente como si el javascript estuviera deshabilitado.

HTML

El código HTML es XHTML 1.0 Strict válido y es el siguiente. En primer lugar tenemos la cabecera:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"  >
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
<title>Ejemplo descripción extensa accesible de imágenes< /title >
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta name="author" content="Olga Carreras" />
<meta name="description" content="Descripciones extensas de imágenes accesibles con lectores de pantalla y sin imágenes activas" />

<link href="estilos.css" type="text/css" rel="stylesheet" media="all" />
<script type="text/javascript" src="utils.js"></script>
</head>

Como se ve, estoy llamando a una CSS y a un JS que explico más adelante.

A continuación tenemos el cuerpo de la página:


<body>
<h1>Ejemplo de descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas</h1>
<p>Olga Carreras. Ejemplo del artículo <a href="http://olgacarreras.blogspot.com">"Descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas"</a></p>

Después de lo que es el título de la página y el enlace al artículo tenemos ya la imagen:


<div>
<img src="razones_uso_tecnologia_accesible.gif" alt="Razones de uso de la tecnología accesible" id="image1" class="images" />
<p><a href="#descripcion" title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible" id="linkDescripcion" class="oculto">Ver descripción de la imagen</a></p>
</div>

La imagen es un gráfico, por tanto el atributo ALT no es suficiente, necesitamos una descripción detallada la imagen.

Os preguntaréis la razón por la cuál he incluido a continuación de la imagen un enlace "Ver descripción de la imagen".

Ese enlace no es necesario puesto que si la imagen no está cargada se verá la descripción detallada y los lectores de pantalla no van a tener problemas para acceder a dicha descripción.

Sin embargo, puede darse el caso de usuarios con vista cansada o que accedan desde un dispositivo móvil y el tamaño de letra de la imagen les resulte pequeño (y no sepan o no puedan hacer zoom de la imagen)

En ese caso les puede ser de utilidad pulsar el enlace para ver la descripción.

El enlace es un ancla al comienzo de la descripción, después veremos que mediante javascript no intrusivo se le ha asignado una función que permite mostrar/ocultar la descripción detallada y personalizar el texto y el TITLE del enlace en función de si se visualiza o no la descripción.


<div id="descripcion" class="visible">
<h2>< < Descripción de la imagen: Razones de uso de la tecnología accesible</h2>
<h3>Por entorno laboral</h3>
<ul>
<li>Con discapacidad severa: 4%</li>
<li<Con discapacidad moderada: 3%</li>
<li<Sin discapacidad: 6%</li>
</ul>
[el resto de la descripción larga, no la pongo aquí toda]
</div>

Como vemos, a continuación se incluye la descripción detallada correctamente maquetada. Esta descripción se oculta una vez cargada la página mediante javascript no intrusivo, por tanto estará disponible tanto sin javascript activo como sin CSS activas, debajo de la imagen.

Con CSS activas, tanto si pulsas el enlace como si no se carga la imagen, la descripción se posiciona a la derecha de la imagen.

Por otro lado veremos que la descripción extensa se está ocultando de forma accesible, así que los usuarios que usan un lector de pantalla (podéis probarlo con NVDA) escuchan la descripción a continuación de la imagen y el enlace.


<div class="pie">
<p>Probad a deshabilitar javascript, css o imágenes. Para ver sin imágenes cargadas o sin javascript activo acordaros de recargar la página una vez que los desactivéis.</p>
<p>Para facilitaros verla sin la imagen cargada os dejo una copia de la misma página pero donde se ha escrito mal el nombre de la imagen y por tanto no la encuentra: <a href="descripcion_imagenes_accesibles_sinimg.html">Probar esta página cuando no se encuentra la imagen.</a></p>
</div>
</body>
</html>

En el pie de la página os recuerdo que si deshabilitáis el javascript, las CSS o las imágenes mientras visualizáis la página deberéis recargarla. Para facilitaros comprobar que, efectivamente, cuando no se carga la imagen se muestra por defecto la descripción a su lado, os pongo un enlace a una copia de la página donde he escrito mal el nombre de la imagen para comprobar cómo se ve la página sin la imagen cargada.

Como se observa, cuando la imagen no se ha podido mostrar, se ve en el hueco que ocuparía la imagen su ALT, y junto a la imagen aparece por defecto la descripción detallada. Ya no se muestra el enlace "Ver descripción de la imagen" porque no es necesario.

Me parece importante destacar que se ha separado:

el contenido: eso es únicamente lo que vemos en la página HTML
la presentación: no se especifica ningún estilo en la página, todos están recogidos en la CSS
el código javascript: no hay ningún evento, ninguna función, nada que haga sospechar que esta página incluye javascript (salvo la llamada al JS en el HEAD). Todo el javascript, incluso las funciones que se llaman en el onLoad de la página, están definidas de forma no intrusiva.

CSS

La CSS es CSS 2.1 válida. No pongo toda la CSS, sólo aquello que es relevante para el ejemplo.


.oculto{
position:absolute;
left:-999em;
}

Con esta clase general "oculto" oculto aquellos elementos que me interesa:

al cargarse la página compruebo si la imagen se ha cargado, en cuyo caso oculto por javascript la descripción. Sin javascript activo, por tanto, la descripción se verá.
el enlace "Ver descripción de la imagen" tiene esta clase "oculto" por defecto y una vez cargada la página lo hago visible. De esta manera, sin javascript activo, el enlace no se muestra puesto que ya no es necesario.

La forma de ocultar (mediante posicionamiento fuera de pantalla) permite que los lectores de pantalla sí puedan acceder al contenido oculto, algo que no ocurre con display:none. Más detalles en "Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página"

Otros estilos que me interesa comentar son los de la imagen:


.images{
width:auto;
height:auto;
}
.widthImage1{
width:393px;
height:363px;
}

Por defecto indico que el ancho de las imágenes sea "auto". No puedo poner por defecto el tamaño real de la imagen porque el script se basa en comprobar si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no está cargada.

Sin embargo tengo una clase con el tamaño real de la imagen porque en Safari y Chrome, si la imagen no tiene especificado su ancho y alto real, no se muestra su atributo ALT. Así que veremos que en el script, tras comprobar el ancho de la imagen para saber si la imagen está cargada, le aplico la clase "widthImage1", y de este modo en Safari y Chrome vemos su ALT.

JS


function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}

La función "addLoadEvent" es la que nos permite llamar a funciones en el onLoad de la página de forma no intrusiva.

¿Qué funciones estamos llamando? Primero a addLoadEvent(noimage)


var Image1Width=393;
function noimage(){
var objImagen = document.getElementById('image1');
var objDescripcion = document.getElementById('descripcion');
var linkDescripcion = document.getElementById( 'linkDescripcion' );
objDescripcion.className = 'oculto';
linkDescripcion.className = 'visible';
if (objImagen.offsetWidth != Image1Width)
{
objDescripcion.className = 'visible';
objImagen.className = 'widthImage1';
linkDescripcion.className = 'oculto';
}
}

Lo primero que hago, como ya he comentado, es ocultar la descripción larga de la imagen y mostrar el enlace "Ver descripción de la imagen".

A continuación compruebo si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no se ha cargado.

En la propuesta de S.Faulkner se comparaba si era igual a 1, pero esto no me funcionaba en todos los navegadores. Por eso lo comparo con el ancho real "393". Es más "sucio" porque no me sirve para todas las imágenes como el compararlo con 1, sino que he de personalizarlo para cada una, pero funciona en todos los navegadores.

Nota: Faulkner lo comparaba con 1 porque no le ponía ALT a las imágenes. Entonces el hueco de la imagen no se adaptaba al ALT y por eso su ancho era 1 cuando no estaba cargada. Como se debe poner ALT tenemos que hacerlo comparándolo con su ancho real. Por otro lado, indicar el ancho y alto de la imagen ayuda a las personas que ven la página sin la imagen cargada a hacerse una idea del tamaño que esta tenía.

En el caso de que la imagen no se haya cargado muestro la descripción, cambio la clase de la CSS aplicada a la imagen (ya he explicado en la CSS que es para que en Chrome y Safari se vea el atributo ALT dentro de la zona de la imagen) y oculto el enlace "Ver descripción de la imagen" porque el enlace ya no es necesario.

La otra función que llamo en el onLoad de la página es la siguiente:


addLoadEvent (function(){
var linkDescripcion = document.getElementById( 'linkDescripcion' );
var objDescripcion = document.getElementById('descripcion');
linkDescripcion.onclick = function(){
if (objDescripcion.className == 'oculto')
{
objDescripcion.className = 'visible';
linkDescripcion.innerHTML="Ocultar descripción de la imagen";
linkDescripcion.title="Ocultar la descripción de la imagen Razones de uso de la tecnología accesible"
}else{
objDescripcion.className = 'oculto';
linkDescripcion.innerHTML="Ver descripción de la imagen";
linkDescripcion.title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible"
}
}
}
)

Esta función añade al evento "onClick" del enlace "Ver descripción de la imagen" una función que:

Si la descripción de la imagen está oculta, al pulsar el enlace la mostraremos. Y a continuación cambiaremos el texto del enlace por su nueva acción "Ocultar descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de ocultar la descripción.
Si la descripción de la imagen está visible, al pulsar el enlace la ocultaremos. Y a continuación cambiaremos en texto del enlace por su nueva acción "Ver descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de mostrar la descripción.

Algo que no he hecho para que se viera más claro lo que hacían las funciones y que se debería hacer para separar el código javascript del texto concreto que queremos personalizar, sería definir esos literales en un fichero diferente de variables para que nos sean más sencillos de modificar. Así en el código sólo incluiriamos variables y no texto concreto.

Os animo ha que dejéis en los comentarios cualquier sugerencia de mejora o problema que detectéis.

Artículos relacionados:

Qué teclas de acceso rápido (accesskey) utilizar

2012-03-21T13:53:00.005+01:00

Artículo anterior:
Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

El punto de verificación 9.5 de las WCAG 1.0 de nivel AAA indica Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario. [Prioridad 3] Por ejemplo, en HTML, especifique los atajos a través del atributo "accesskey"

En las WCAG 2.0 deja de ser un criterio de conformidad y pasa a ser una técnica adicional del criterio 2.4.1 de nivel A Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web".

Aunque no es obligatorio, yo sí que recomiendo incluir atajos de teclado. La duda que surge entonces es ¿qué accesskey incluir de forma que no entren en conflicto con las teclas de atajo de los menús del navegador? ¿hay algún estándar?

UK Government accesskeys standard

El Gobierno del Reino Unido estableció en 2002 las siguientes teclas de acceso rápido para sus portales web:

S - Skip navigation
1 - Home page
2 - What’s new
3 - Site map
4 - Search
5 - Frequently Asked Questions (FAQ)
6 - Help
7 - Complaints procedure
8 - Terms and conditions
9 - Feedback form
0 - Access key details

Consultar en: Uk Guidelines for government websites (PDF) (capítulo 2 "Content of websites". Apartado 2.4 "Building in universal accessibility + checklist". Subapartado 2.4.4 "UK Government accesskeys standard".

Estas accesskey se siguen utilizando como se observa por ejemplo en la web Directgov (UK government's digital service for people in England and Wales)

Swedish Government accesskeys standard

En Suecia, en las Swedish National Guidelines for Public Sector Websites (2008) (PDF), que establecen las normas a seguir por los portales de la Administración Pública, se definen también las teclas de acceso rápido que se han de utilizar.

Según se indica, están basadas en las del Reino Unido (The choices of access keys are inspired by the UK Government access keys):

S - Skip navigation, go directly to text content
0 - “About the website”, accessibility information. Provided details on access keys
1 - “Home” page
2 - News. Collection of news
3 - Content outline. A site map, or perhaps A-Z
4 - Search. Should be connected to the search field that searches the entire website
5 - Frequently Asked Questions (FAQ)
6 - Help. For example, about a specific service.
7 - Contact us. Page with contact details to important functions within the government agency.
8 - Legal information. Page that describe the website’s privacy policy and how legal information such as cookies are handled.

Según se especifica, en la página "About the website" se deben indicar las teclas utilizadas y explicar su uso en diferentes navegadores y sistemas operativos.

Ninguna de estas teclas colisiona con los atajos de menú de los navegadores. La "S" no genera conflicto en los navegadores en castellano, aunque indican que en la versión sueca de IE6 sí colisiona con un menú.

Mi recomendación es que no reinventemos la rueda y usemos las accesskey propuestas por los gobiernos de Reino Unido y Suecia. Tienen la ventaja de no colisionar con el navegador y que son lo más cercano a un estándar "de facto" que existe, de modo que, si se generalizan, el usuario no deberá reaprenderlas de una web a otra.

Así que os animo a aplicar y difundir este estándar de accesskey.

Un ejemplo de uso y adaptación de estas accesskey lo implementamos en la web de la Clínica Universidad de Navarra.

Otros enlaces de interés

Artículos anteriores

HTML 5 y accesibilidad

2012-02-16T14:33:00.008+01:00

Última actualización: 13 de marzo de 2012

La especificación de HTML 5 pretende ser una especificación pensada para incluir dinamismo y a la vez accesibilidad desde su concepción. Por tanto, la ventaja principal que tendrá es que los desarrolladores que la utilicen podrán generar efectos de presentación muy atractivos sin limitar la interacción por parte de usuarios de ayudas técnicas. Pero en estos momentos es todavía un borrador, su implementación en los diversos navegadores no es completa aún y por tanto, aunque desde muchos sectores se alienta su uso, yo no lo haría tan alegremente.
Existe un sitio dedicado a informar sobre la implementación de HTML en los navegadores y sus consecuencias para la accesibilidad, así como posibles soluciones: http://html5accessibility.com/ Recomiendo vivamente estar al tanto de las actualizaciones y, sobre todo de las advertencias contenidas en ese sitio.
Entrevista a Emmanuelle Gutiérrez y Restrepo

Un recurso imprescindible, como recomienda Emmanuelle, es la web "HTML 5 Accesibility" donde se propociona información actualizada sobre el soporte en los diferentes navegadores (la última versión es de este mes, donde se sitúan a la cabeza Chrome y Firefox y a la cola Opera y Safari):

This site is a resource to provide information about which new HTML5 user interface features are accessibility supported in browsers, making them usable by people who rely upon assistive technology (AT) to use the web [...]
It is not intended to dissuade developers from using new HTML5 features. Sometimes there are better choices, sometimes developers have to add a little extra to make the feature useful or usable, and other times features have simply not been implemented by any browser or only by browsers that do not yet support assistive technologies. As a consequence it may not yet be practical to use a particular HTML5 feature.

Actualmente el grupo de trabajo WCAG WG está trabajando en las Técnicas HTML5 para las WCAG 2.0, tal y como existen ahora para HTML, PDF, Flash, etc. (Techniques for WCAG 2.0). Es una gran noticia, aunque de momento están en un estado muy inicial.

Otro documento de interés del W3C es HTML5: Techniques for providing useful text alternatives, sobre el correcto uso de las alternativas textuales para que estas sean efectivamente accesibles en cualquier contexto de uso.

Elemento `video` y accesibilidad

Uno de los objetivos más habituales para el uso actual de HTML 5 es la inclusión de contenido multimedia, especialmente la inclusión de vídeos con el elemento video. Un recurso muy interesante es: "Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5" (PDF, 2MB), trabajo fin de carrera de Alberto Sánchez-Heredero Pérez y tutorizado por Lourdes Moreno López (autora de "Accesibilidad a los contenidos audiovisuales en la web").

Otros artículos interesantes sobre la accesibilidad y el uso del elemento video de HTML5 son:

"An In Depth Analysis of HTML5 Multimedia and Accessibility" de Ian Devlin
"The State of HTML5 Video" de Jeroen Wijering

Combinar los nuevos marcadores semánticos con ARIA Roles

Sobre el soporte de HTML 5 por los lectores de pantalla son muy interesantes los artículos que tratan sobre cómo combinar los nuevos marcadores semánticos de HTML 5 (header, nav, section) con ARIA Roles (que usan actualmente páginas como Google o Yahoo. Más información en "AJAX accesible: WAI-ARIA", ) para que sean más accesibles para los lectores de pantalla.

"How screen readers speak a page with HTML5 and ARIA" de Lucica Ibanescu, incluye dos vídeos en los que se muestra como lee una página HTML 5 NVDA, JAWS y Windows Eyes con y sin roles.

Por otra parte, el artículo "HTML5 Accessibility Chops: ARIA landmark support", de Paciello Group Blog (que suele publicar buenos artículos sobre HTML 5 y accesibilidad) trata también este tema, incluyendo un listado detallado del soporte de ARIA Roles con diferentes lectores de pantalla (JAWS, NVDA, VoiceOver, Chrome, Windows Eyes).

Vídeos ilustraticos del soporte de ARIA Roles con diferentes lectores de pantalla son (todos en YouTube):

Puedes consultar todos los vídeos recomendados en mi lista de reproducción de Youtube "HTML 5 y accesibilidad".

Otro artículo muy interesante sobre el tema es: ARIA and Progressive Enhancement

Accesibilidad HTML 5 y RIA (Rich Internet Applications)

La siguiente PPT es todo un tesoro: "Accesibility of HTML5 y Rich Internet Applications" de Hans Hillen y Steve Faulker, presentada en CSUN 2012. En ella se explican los problemas habituales de accesibilidad en aplicaciones RIA y sus soluciones.

La primera parte y los ejemplos se pueden encontrar en "Accessibility of HTML5 and Rich Internet Applications - CSUN 2012 Workshop Material"

Otros artículos de interés sobre HTML 5 y accesibilidad

WebAIM elaboró en 2010 una serie de artículos denominados "Future Web Accesibility" donde comenta nuevas características que incorpora HTML 5 y que mejorarán la accesibilidad de los sitios web. Se puede consultar el enlace a estos artículos y una breve descripción de los mismos en el artículo de Sergio Luján "El futuro de la accesibilidad web con HTML5"
"Accessibility and HTML5 Block Links", de Derek Featherstone analiza los problemas de accesibilidad de utilizar bloques de contenido dentro de un enlace, algo aceptable en HTML 5.
"Accessible HTML5 Forms – Required Inputs", de Johnny Otis and Etta James, analiza los problemas de accesibilidad para el uso del nuevo atributo required de HTML 5 y lo compara con el uso de aria-required="true" de WAI-ARIA (más información sobre WAI-ARIA en "AJAX accesible: WAI-ARIA")
WAI ARIA support on iOS, septiembre de 2012, con el soporte para iPhone 4 e iPad 1

Iré actualizando este artículo con otros recursos de interés que vaya encontrando.

Herramienta de ayuda para validar de acuerdo a las WCAG 2.0

2012-02-14T16:34:00.002+01:00

En el artículo anterior "Herramienta de ayuda para realizar una consultoría de accesibilidad web" compartía y explicaba una herramienta de ayuda para realizar una consultoría de accesibilidad web respecto a las WCAG 1.0 y la Norma UNE 139803.

Ahora comparto la versión de esa herramienta para realizar una consultoría de accesibilidad en base a las WCAG 2.0

El funcionamiento es el mismo, por tanto se puede consultar la descripción detallada en el artículo anterior.

La única novedad es que en cada criterio de éxito incluyo una descripción amigable de lo que hay que revisar en cada uno de ellos. Esta descripción está basada en la traducción de WebAIM`s WCAG 2.0 Checklist por parte de Jose Ramón Quevedo.

Otra herramienta complementaria que os recomiendo es la WCAG 2.0 Checklist de Roger Hudson, en la cual incluye por cada criterio de éxito las técnicas a aplicar (está en formato Word y no genera datos automáticos como la que yo comparto)

La descarga es gratuita.

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 1.0/Norma UNE 139803. Archivo excel .XLSX de 85.6 KB

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0. Archivo excel .XLSX de 84 KB

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

Servicio relacionado: Consultoría de accesibilidad web

Artículos relacionados:

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

2012-01-25T14:04:00.003+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 de acuerdo a las WCAG 1.0 y la Norma UNE 139803. Al final del artículo tenéis la descarga.

Novedad febrero 2012. Incluyo una nueva versión para validar de acuerdo a las WCAG 2.0

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 de accesibilidad web de acuerdo a las WCAG 1.0/Norma UNE 139803. Archivo excel .XLSX de 85.6 KB

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0. Archivo excel .XLSX de 84 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.006+01:00

Última actualización: 16/04/2012

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 consejos de accesibilidad que publico en Twitter 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="0" 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 según las WCAG 2.0 los vídeos (grabados) deben incluir subtítulos sincronizados, transcripción de la banda sonora con descripción de la pista visual y audiodescripción.
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.
El ALT (texto alternativo) de una imagen debe tener siempre en cuenta el contexto en el que se inserta la imagen. Ejemplo "Accessibility: Images in Context" (vídeo de Youtube con subtítulos, con posibilidad de traducción al español)
Si tienes campos de formulario que se borran al coger el foco, revisa los problemas que les puede provocar a los usuarios con lectores de pantalla. En "Accessibility Testing: Correction Scenarios" Derek Featherstone nos explica casos concretos.
En (X)HTML podemos usar el manejador de evento "onclick" sin necesidad de duplicarlo con "onkeypress". Puesto que los navegadores (X)HTML lo interpretan como el manejador de evento de acción por defecto de enlaces y botones y se activa tanto con el ratón como por el teclado
Un elemento que no sea enlace o botón (por ejemplo: div, img, td, etc.) y tenga un evento "onclick" sí necesita que se duplique con "onkeypress" para ser accesible por teclado. Además se debe incluir el atributo tabindex="0" para que el elemento pueda coger el foco y por tanto ser efectivamente accesible por teclado.
Debe existir contenido textual entre encabezados consecutivos (H1-6) del mismo nivel, entre encabezados consecutivos (H1-6) cuando el segundo sea de mayor nivel que el primero; y entre el último encabezado y el final de página
¿Cómo incluir la descripción larga de una imagen de forma que sea accesible para los lectores de pantalla y se visualice por defecto cuando no se han cargado las imágenes? Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas
Las WCAG recomiendan usar accesskey para alcanzar el nivel AAA (en las WCAG 1.0) o como técnica adicional del criterio 2.4.1 (en las WCAG 2.0) ¿Pero cuáles utilizar? Qué teclas de acceso rápido (accesskey) utilizar
Que un párrafo esté incluido en un DIV no le exime de que obligatoriamente también deba estar incluido en un P
Para comprobar en un audio si el sonido de fondo es 20 dB más bajo que la voces para cumplir con el criterio 1.4.7, puedes usar WCAG 2.0 Audio Contrast Analysis Tool incluida en Audacity

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

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:

SEO y Accesibilidad. Accesible también para buscadores

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

Recursos "Usable y accesible" relacionados:

Tu usuario más importante es ciego. La mitad de las visitas a tu sitio vienen de Google, y Google sólo ve lo que un ciego puede ver. Si tu sitio no es accesible, tendrás menos visitas. Fin de la historia.
- Steven Pemberton -

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.057+01:00

Artículos relacionados: Consejos avanzados de accesibilidad web

Última actualización: 16/04/2012

A continuación se dan respuesta a 25 dudas habituales de accesibilidad respondidas de acuerdo a las WCAG 2.0 y su documento asociado Techniques for WCAG 2.0

¿Puedo utilizar ventanas emergentes?
¿Puedo utilizar frames?
¿Puedo utilizar tablas para maquetar?
¿Mi sitio Web es inaccesible si utiliza Flash?
¿Mi sitio Web es inaccesible si utiliza javascript?
¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
¿Cómo se especifica correctamente el color de fondo y de primer plano?
¿Cómo marcar adecuadamente un emoticon?
¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
¿Es recomendable incluir una opción de "Leer está página"?
¿Cuánto se ha de poder ampliar el tamaño de un texto?
¿Cómo marcar la pronunciación de una palabra?
¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
¿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 versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
¿Cuándo puedo ponerle a una imagen alt=""?
¿Es correcto que el contenido de un input se borre al coger el foco?
¿Qué se considera texto grande y texto pequeño?
¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

1. ¿Puedo utilizar ventanas emergentes?

Cuando hablamos de ventanas emergentes (pop-ups) nos referimos tanto a nuevas ventanas del navegador abiertas mediante el atributo TARGET como a ventanas que se abren mediante javascript con WINDOW.OPEN

El criterio de conformidad "3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)" de las WCAG 2.0 dice:

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

Asociado a este criterio hay dos técnicas que contestarán a nuestra pregunta:

H83: Using the target attribute to open a new window on user request and indicating this in link text

La técnica H83 dice así:

The objective of this technique is to avoid confusion that may be caused by the appearance of new windows that were not requested by the user. Suddenly opening new windows can disorientate or be missed completely by some users. In HTML 4.01 Transitional and XHTML 1.0 Transitional, the target attribute can be used to open a new window, instead of automatic pop-ups. (The target attribute is deleted from HTML 4.01 Strict and XHTML 1.0 Strict.)

Note that not using the target allows the user to decide whether a new window should be opened or not. Use of the target attribute provides an unambiguously machine-readable indication that a new window will open. User agents can inform the user, and can also be configured not to open the new window. For those not using assistive technology, the indication would also be available from the link text.

Es decir, aunque no se recomienda el uso de ventanas emergentes y se hace hincapié en los problemas que provocan, las WCAG 2.0 no prohíben el uso de TARGET con HTML 4.01 Transitional y XHTML 1.0 Transitional, eso sí, debe indicarse siempre mediante texto y dentro del enlace que se abrirá en ventana nueva.

Por ejemplo:

Show Help (opens new window)

¿Se puede ocultar la aclaración "se abre en ventana nueva" mediante la CSS? ¿Se puede indicar en el title del enlace?

El criterio de conformidad 2.4.4 (A) permite como técnicas suficientes para que los enlaces transmitan su próposito elegir (aparte de que el propio enlace sea suficientemente descriptivo):

que la aclaración se incluya con el atributo title. Es la técnica H33, pero en la misma, aunque permitida, se desaconseja su uso por las limitaciones del soporte del atributo title y se aconseja que el propio enlace describa su propósito aunque parte del mismo se oculte mediante la CSS.
incluir la aclaración dentro del enlace pero ocultarla por CSS

Sin embargo, para cumplir con el nivel AAA, sería obligatorio que la advertencia de que se abre en ventana nueva se incluya dentro del enlace puesto que:

así lo recomienda el texto y el ejemplo de la técnica H83 del criterio 3.2.5, tal y como hemos visto. Se especificaba que las ventanas emergentes no sólo causan problemas a personas con una discapacidad visual, sino también a personas con problemas motores o cognitivos que no están usando un lector de pantalla y para las cuales por tanto sería opaco el contenido oculto por CSS.
el criterio 2.4.9 (AAA) obliga a que el propósito de los enlaces esté especificado en el texto del enlace, aunque admite como técnica la ocultación de parte del texto del enlace mediante CSS. Pero no admite la aclaración en el atributo title del enlace.

SCR24: Using progressive enhancement to open new windows on user request
Tras advertir de nuevo de los problemas de las ventanas emergentes, se explica cómo hacer un WINDOW.OPEN de forma accesible mediante javascript no intrusivo.
Consultar la técnica para ver un ejemplo.
Conclusión
Hay muchas razones para no usar ventanas emergentes, sin embargo no están prohibidas por las WCAG 2.0, siempre y cuando se cumplan estas dos normas:
- Si te utiliza TARGET se debe indicar dentro del enlace y mediante texto que se abre una ventana nueva.
- Si se utiliza javascript el enlace debe tener un HREF con la ruta de la página y mediante javascript no intrusivo implementar el WINDOW.OPEN
Complementariamente se citan tres errores comunes a la hora de crear nuevas ventanas que sí reportan problemas de accesibilidad:
Es decir, no se debe abrir una ventana nueva al cargar la página sin que el usuario lo haya requerido, ni se deben abrir ventanas emergentes sin previo aviso cuando se introducen datos o se seleccionan campos en un formulario (cuando se cambia el estado de un check o un radio o se selecciona el elemento de una lista).
2. ¿Puedo utilizar frames?
La técnica H70: Using frame elements to group blocks of repeated material dice así:

The objective of this technique is to demonstrate how framesets can be used to group blocks of repeated material. Since most user agents and assistive technology provide a way to navigate from frame to frame, using frames to organize elements can provide a mechanism for easily bypassing blocks of repeated content. If the site uses framesets, organize the blocks of content into separate frames. Make certain that the repeated blocks of content appear in the same frame within the frameset of each Web page. In addition, each frame element must have a title attribute to describe the content of the frame. When frames are properly titled, users can use frame navigation to easily navigate between blocks of content.
This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames. An advisory technique about using noframes is available in Success Criterion 4.2.1.
Esta técnica, como se indica en la misma, NO está recomendando el uso de frames. Únicamente reconoce su utilidad para agrupar contenido repetido y da instrucciones sobre cómo identificarlos correctamente en caso de que ya se estén usando en el sitio web.
Si se utilizan frames habrá que ofrecer un NOFRAMES y cada frame deberá tener un TITLE como se explica en la técnica H64: Using the title attribute of the frame and iframe elements
Ambas técnicas están asociadas al criterio de conformidad 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)
Aunque no me gusten los frames, con las WCAG 2.0 en la mano podremos aconsejar que no se usen, pero no podremos mantener que es obligatorio eliminarlos si ya se están utilizando.
Conviene recordar que el uso de frames puede provocar diferentes problemas de usabilidad y accesibilidad en las páginas (si bien es cierto que hay soluciones para todos raramente se encuentran implementadas):
- Suelen impedir que funcione correctamente el botón "Atrás" del navegador.
- Aunque cambie el contenido de los frames, el URI del conjunto de frames no varía y por tanto no se puede hacer referencia a su estado actual con una dirección web.
- Algunos navegadores pueden tener problemas para añadir una página a los marcadores o favoritos.
- Los usuarios pueden tener dificultades para imprimir el conjunto de frames.
- Suele suponer problemas para indexar correctamente las páginas por los buscadores, que pueden indexar cada frame y no estos en su conjunto.
- El usuario podría acceder a un marco fuera de su contexto (por ejemplo a una página sin su cabecera o sin su menú de navegación).
3. ¿Puedo utilizar tablas para maquetar?
La técnica H73: Using the summary attribute of the table element to give an overview of data tables dice:

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. However, if a layout table is used, then the summary attribute is not used or is null. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A summary would “break" this transparency by calling attention to the table. A null summary (summary="") on layout tables is acceptable.
Es decir, aunque hay razones de sobra para no utilizar tablas para maquetar y por ello se desaconseja su uso (también por ejemplo en las técnicas G140: Separating information and structure from presentation to enable different presentations y G146: Using liquid layout), las WCAG 2.0 no las prohíbe.
Eso sí, se han de cumplir ciertas reglas:
- El SUMMARY de estas tablas debe estar vacío.
- Estas tablas no deben utilizar CAPTION, como se indica en la técnica H39: Using caption elements to associate data table captions with data tables:
 If a table is used for layout, the caption element is not used. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A caption would "break" this transparency by calling attention to the table.
- Tampoco se deben asociar las celdas como se indica en la técnica H43: Using id and headers attributes to associate data cells with header cells in data tables:
 
 This technique is not recommended for layout tables since its use implies a relationship between cells that is not meaningful when tables are used for layout.
Así que si a pesar de todo alguien insiste "¿pero si se usan tablas para maquetar la página es innaccesible? ¿cumple con las WCAG 2.0?", pues la realidad es que sólo podemos contestar que si se cumplen las normas citadas sí se pueden usar.
Que nadie interprete que yo las recomiendo, por favor, me limito a informar de lo que dicen las WCAG 2.0
4. ¿Mi sitio es inaccesible si utiliza Flash?
En la presentación "WCAG 2 Compliance With Flash" (PDF, 151 KB), de The Paciello Group Blog se explica como con la versión 6 y posteriores el contenido Flash puede ser accesible y cumplir con las WCAG 2.0 puesto que:
- All content exposed to AT
- Keyboard accessibility
- Accessible interactive components
En octubre de 2010 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, donde se explica como implementar Flash accesible de forma nativa.
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.
Como ocurre a menudo el problema no está en la tecnología en sí sino en los desarrolladores.
En resumen, si se utiliza la tecnología Flash de forma accesible (compatible con los productos de apoyo) NO deberemos ofrecer una alternativa accesible en HTML y en la declaración de conformidad se indicará que depende de la tecnología Flash.
Si se utiliza Flash de forma no accesible se deberá proporcionar una alternativa accesible en HTML y entonces en la declaración de conformidad no incluiríamos javascript como tecnología de la que se depende.
Si Flash se usa de forma no accesible y sin alternativa accesible en HTML deberemos excluir las páginas que lo utilizan de la declaración de conformidad.
Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia: si en una página se usa una tecnología que no es compatible con la accesibilidad o bien una que sí lo es pero usada de forma no compatible, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad cuando cualquier tecnología de la que no se depende está activada en los agentes de usuario así como cuando esté desactivada o no se soporte. Por ejemplo, no puede atrapar el foco con el teclado sin dejarlo salir, no puede tener destellos que puedan provocar ataques epilépticos, etc.
Lo mismo se aplicaría a los documentos PDF.
Otras referencias de interés sobre accesibilidad y Flash son:
- "Checklist para validar contenido Flash de acuerdo con las WCAG 2.0" de Olga Carreras.
- "Guía de accesibilidad en Flash" de Inteco
- "Flash navegable mediante teclado en Firefox" de Uninstallme.
- El blog Adobe Accessibility, donde se puede descargar: "Accessibility-only version of the Flash and Flex accessibility documentation" (ZIP, 2.84 MB).
- "Best Practices for Accessible Flash Design" de Adobe
- "Adobe Flash CS4 Professional accessibility" de Adobe
- "Can You Create Accessible Websites Using Flash?" de MSF&W
- "Video en Flash Accesible" de El Rallador.
- "Making Video Accessible" de Longtail Video
- "Flash Video Accessibility" de Illinois Department of Human Services.
5. ¿Mi sitio es inaccesible si utiliza javascript?
Javascript no era bienvenido en las pautas WCAG 1.0, no olvidemos que datan de 1999, pero el W3C sí que contempla javascript y AJAX en las WCAG 2.0. Es más, se recomiendan soluciones implementadas con javascript en numerosas técnicas: para abrir ventanas emergentes de forma no intrusiva, para cambiar de CSS de forma dinámica, etc.
Estas son todas las técnicas relacionadas con javascript y ARIA:
- Client-side Scripting Techniques for WCAG
- ARIA Techniques for WCAG 2.0
El problema no es utilizar o no javascript, sino cómo se utiliza.
En el artículo "Creating Accessible JavaScript" de WebAIM, cuya lectura se recomienda en las técnicas, se resumen muy bien las normas para crear javascript accesible:

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.
Making JavaScript accessible involves looking at the following issues.
- When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
- Content and functionality that is provided through scripting must be made accessible to assistive technologies.
- Web pages that utilize scripting must be fully navigable using a keyboard.
- JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
- When JavaScript cannot be made natively accessible, an accessible alternative must be provided.
¿Es necesario ofrecer una alternativa al JavaScript? ¿Se debe realizar una versión que funcione sin JavaScript?
La duda surge porque estamos acostumbrados a trabajar con las WCAG 1.0, en las cuales se especifica con claridad que es necesario una alternativa:
"Punto de Verificación 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page".
Las WCAG 2.0 lo que promueven es que el código JavaScript debe ser accesible nativamente. Es decir, si se implementa de forma no intrusiva, si es independiente del dispositivo (no requiere por ejemplo sólo el uso del ratón), si es accesible para los productos de apoyo, etc. no tiene porque suponer un problema de accesibilidad.
Pero si a pesar de todo no lo logramos, las WCAG 2.0 dicen en el Requisito de conformidad número 4:
4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.
En el documento "Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order" del W3C, el punto 6.3 se corresponde además con los requisitos de conformidad 1 (nivel de conformidad) y 5 (no interferencia). Como nota adicional se dice: There is no longer a requirement that pages work without script or other programmatic objects, only that those objects meet the conformance requirements listed above.
En resumen, si se utiliza la tecnología javascript de forma accesible (compatible con los productos de apoyo, según las técnicas de las WCAG 2.0 y la implementación de WAI-ARIA) no deberemos ofrecer una alternativa accesible y en la declaración de conformidad se indicará que depende de la tecnología javascript.
Si se utiliza javascript de forma no accesible se deberá proporcionar una alternativa accesible y entonces en la declaración de conformidad no incluiríamos javascript como tecnología de la que se depende.
Si javascript se usa de forma no accesible y sin alternativa accesible entonces deberemos excluir las páginas que lo utilizan de la declaración de conformidad.
Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia: si en una página se usa una tecnología que no es compatible con la accesibilidad o bien una que sí lo es pero usada de forma no compatible, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad cuando cualquier tecnología de la que no se depende está activada en los agentes de usuario así como cuando esté desactivada o no se soporte.
He hablado de javascript accesible en algunos artículos anteriores:
6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
La técnica H44: Using label elements to associate text labels with form controls asociada al criterio 1.3.1 (A) dice así:
The HTML and XHTML specifications allow both implicit and explicit labels. However, some assistive technologies do not correctly handle implicit labels (for example, <label>First name <input type="text" name="firstname"></label>).
- JAWS 7.10 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It reads the label for explicit and implicit labels for text fields in both virtual PC cursor and forms reading mode. In forms mode it does not read the label for implicit labels on checkboxes and radio fields.
- Window-Eyes 5.5 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It will always speak the label for an explicitly labelled form field. It does not speak the label for the implicitly labelled form control in browse on mode but will speak the implicit label when navigating from control to control in browse off mode.
Por dichas razones aconseja asociarlos de forma explícita como en estos ejemplo, es decir, mediante el atributo for del label y el id (que debe ser único en la página) del campo:
<label for="firstname">First name:</label> <input type="text" name="firstname" id="firstname" />
<input type="checkbox" id="markuplang" name="computerskills" checked="checked"> <label for="markuplang">HTML</label>
Además se especifica que:
- el label debe estar colocado antes del elemento del formulario al que etiqueta salvo que este sea un checkbox o un radiobutton (en cuyo caso se coloca detrás del mismo)
- el label sólo se usa con los textarea, select e input (de tipo text, checkbox, radio, file y password) pero NO se usa con button (cuyo contenido es su etiqueta) ni con los input de tipo image (su atributo alt será su etiqueta), submit y reset (su atributo value es su etiqueta) o hidden (no tienen etiqueta)
Por otro lado, hay que destacar que la técnica H65, también asociada al criterio 1.3.1 (A), admite el uso del atributo title para etiquetar los campos de formulario cuando NO se usa para ello label, bien porque en el diseño de la página no hay un texto que pueda etiquetarse como label o tenerlo podría generar confusión.
En esta técnica se explica que si no hay un label los lectores de pantalla y los agentes de usuario en general pueden leer o mostrar el valor del title asociado a un campo de formulario (mejor soportado que en el caso de los enlaces)
Se ponen varios ejemplos muy habituales. Por ejemplo, si tenemos varios campos de fecha (dia, mes, año) o de cuenta bancaria, sin un label para cada uno, podemos etiquetarlos con su atributo title.
En el caso de tener un campo de búsqueda y un botón "Buscar", bastaría con que el campo tuviera un atributo title del estilo "Escribe el término de búsqueda aquí". Pero incluso ni esto sería necesario, puesto que sería suficiente con la técnica G167 que indica que un botón adyacente a un campo puede hacer de label del mismo (si su texto es claro y ejecuta una acción sobre el campo) Es decir, en este caso no sería necesario etiquetarlo ni con label ni con title y pone precisamente como ejemplo el caso del campo y el botón buscar.
7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
La técnica G169: Aligning text on only one side dice así:
Many people with cognitive disabilities have a great deal of trouble with blocks of text that are justified (aligned to both the left and the right margins). The spaces between words create "rivers of white" running down the page, which can make the text difficult for some people to read. This failure describes situations where this confusing text layout occurs. The best way to avoid this problem is to create text layout that is fully justified.
Es decir, el texto no debe justificarse, puesto que algunas personas con discapacidades cognitivas o visuales pueden tener problemas para leer el texto que está justificado a ambos lados. Esta dificultad proviene de que las variaciones entre el espaciado entre las palabras puede provocar que las palabras estén demasiado juntas o por el contrario "ríos blancos", es decir, zonas del texto donde la separación de las palabras dejan grandes zonas continuas de espacio en blanco.
Sin embargo se ofrece como alternativa que el sitio ofrezca un mecanismo para eliminar la justificación del texto como se especifica en la técnica G172: Providing a mechanism to remove full justification of text:
The objective of this technique is to provide a version of the page that does not have full justification (justified both left and right). There may be circumstances when for layout purposes an author may want to have the text fully justified. In these cases, it is sufficient to provide a feature that removes the justification of text. The control should be easy to find and access and near the beginning of the page.

El problema de la justificación del texto se presenta también como un error común de accesibilidad en F88: Failure of SC 1.4.8 due to using text that is justified (aligned to both the left and the right margins)
Todas ellas están asociadas al criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
Hay varias técnicas relacionadas con el criterio de conformidad 3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA).
El marcado dependerá de si la abreviación tiene un único significado en la página o si tiene diferentes significados dentro de la misma página.
Si la abreviación tiene un único significado en la página
En este caso habrá que explicar o ampliar la abreviatura la primera vez que aparece de una de las siguientes maneras:
- G97: Providing the abbreviation immediately following the expanded form. Por ejemplo:
 "The United Nations High Commissioner for Human Rights (UNHCR) was established in 1950 to provide protection and assistance to refugees."
- G55: Linking to definitions
- H28: Providing definitions for abbreviations by using the abbr and acronym elements. Por ejemplo:
 The use of <acronym title="Keep It Simple Stupid">KISS</acronym> became popular in ...
Y habrá que explicar o ampliar la abreviatura en todas sus apariciones en la página de una de estas maneras:
Si la abreviación tiene diferentes significados dentro de la misma página
En este caso se deberá explicar o ampliar todas las veces que aparece siguiendo la técnica G55: Linking to definitions o la H28: Providing definitions for abbreviations by using the abbr and acronym elements.
Traté el tema de las abreviaturas y acrónimos en Más accesible a pesar de blogger (I). DÍA 8: Revisión de abreviaturas y acrónimos
9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
Asociado al criterio de conformidad 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) está la técnica G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent en la que se puede leer:
The purpose of this technique is to provide a mechanism on the Web page to incrementally increase the size of text. Many people with low vision do not use magnifying software, and they may not be familiar with browsers text size adjustments. This may be particularly true of older people who are learning about computers later in life and who may be experiencing age related vision loss. It may also be true of some people with cognitive disabilities who also require increased font size.
This technique provides a mechanism that some users will find easier to use. The mechanism may include links or buttons that will switch the visual presentation to a different style sheet or use scripts to change the text size dynamically.
To implement this technique, an author provides controls that allow the user to incrementally increase or decrease the text size of all of the text on the page to a size that is at least 200% of the default text size.
This can be achieved by providing links, buttons or linked images and the controls themselves should be as easy to find (ex. prominently positioned within the page, presented in a larger text size, hight contrast, etc.) as possible.
Está muy extendida la creencia de que los botones que permiten ampliar el tamaño de letra son un ejemplo de falsa accesibilidad, una moda, y que no deberían utilizarse (por ejemplo en Too much accessibility. GOOD INTENTIONS, BADLY IMPLEMENTED de Patrick H. Lauke).
Sin embargo vemos que es una técnica suficiente para cumplir con el criterio de conformidad 1.4.4 (AA) que puede ser útil para usuarios con baja visión que no usan magnificadores de pantalla y que no están acostumbrados a las opciones del navegador, como ejemplo personas mayores no habituadas al uso de ordenadores o personas con discapacidades cognitivas.
Para implementar correctamente estos botones (enlaces o imágenes) deben:
- permitir aumentar progresivamente el tamaño del texto de la página hasta al menos un 200% de su tamaño por defecto
- ser fáciles de localizar, con un tamaño grande y suficiente contraste
- estar correctamente etiquetados de forma que se reconozca claramente cuál es su función
10. ¿Cómo se especifica correctamente el color de fondo y primer plano?
En el criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA) se especifican las técnicas que aseguran que el usuario podrá seleccionar los colores de primer plano y fondo:
1. C23: Specifying text and background colors of secondary content such as banners, features and navigation in CSS while not specifying text and background colors of the main content (CSS)
 Example 1. An HTML Web page uses CSS to specify the text and background colors of all secondary content such as navigation bars, menu bars, and the table of contents. Neither the text color nor background of the main content is specified. The user sets their own color preferences in the browser so that they view the main content in colors and contrasts that work well for them. The distinction between the separate sections of the page are still visually obvious.
 Se puede consultar cómo modificar los colores en los principales navegadores en "Changing colours in your browser" de la BBC.
 OR
2. C25: Specifying borders and layout in CSS to delineate areas of a Web page while not specifying text and text-background colors (CSS)
 Example 1. A Web page is designed using HTML. CSS is used to specify border colors around discrete areas of the page and to layout the content so that the menu floats to the left of the main content area. Neither the text color nor background is specified. The user sets their own colors in the browser. They can view the page in colors and contrasts that work well for them without disrupting the layout.
 OR
3. G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text OR
4. G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults OR
5. G175: Providing a multi color selection tool on the page for foreground and background colors
En resumen, se debe usar una tecnología que disponga de agentes de usuario de uso común que permitan cambiar el color de primer plano y del fondo de los bloques de texto (como es el caso de XHTML) o en caso contrario proporcionar una herramienta de selección de los colores de primer plano y de fondo.
Si usamos XHTML los usuarios podrán configurar las combinaciones de colores en función de sus necesidades. Sin embargo, si la página tiene contenido secundario para el que es necesario mantener una agrupación visual, debemos asegurarnos que dicha agrupación se mantiene cuando los usuarios cambian los colores de primer plano y los colores de fondo. Para ello podemos utilizar algunas de las técnicas que ya se han indicado anteriormente:
- Especificar en las hojas de estilo el color del texto y fondo del contenido secundario, como banners o mecanismos de navegación, sin especificar un color del texto ni del fondo para el contenido principal.
- Especificar en las hojas de estilo los bordes para delimitar las áreas de contenido, sin especificar un color del texto ni del fondo para el contenido principal.
11. ¿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.
La técnica propone tres posibles marcados correctos:
=8-0 (fright): texto alternativo a continuación entre paréntesis
<abbr title="fright">=8-0</abbr>: marcarlo como abreviatura indicando en su atributo title su significado
<img src="fright.gif" alt="fright"/>: incluirlo como imagen con su correspondiente texto alternativo con alt
Relacionado con este punto también se indica que en el caso de un ASCII art largo, además de incluir la alternativa textual inmediatamente antes o después del dibujo, se debería incluir un enlace para saltarlo.
Por ejemplo, inmediatamente antes de un dibujo ASCII art largo de una persona, pondríamos un enlace Saltar dibujo con caracteres de una persona que vaya al contenido inmediatamente posterior al dibujo mediante un ancla. De este modo, el enlace sirve a la vez de descripción del dibujo y de enlace para saltarlo.
12. ¿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.
13. ¿Es recomendable incluir una opción de "Leer está página"?
En algunos sitios nos encontramos una opción que proporciona un audio del contenido de la página mediante alguna herramienta automática de conversión de texto a voz como Vozme.
¿Se recomienda esta práctica?
En respuesta a esta duda, la técnica G79: Providing a spoken version of the text (proporcionar una versión hablada del texto) es una técnica suficiente para cumplir con el criterio de conformidad 3.1.5 Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo (Nivel AAA)
En dicha técnica se indica que para determinado tipo de usuarios puede resultar muy útil escuchar el texto leído en voz alta. Indican también que esto es efectivo para pequeñas cantidades de texto y para documentos que no cambian a menudo. Por tanto, es útil cuando lee el contenido textual y no toda la página (cabecera, menús, pie, etc.) como se encuentra en muchos portales.
También hay que tener en cuenta que está asociado a un criterio que habla de texto que requiere un nivel de lectura más avanzado que el de secundaria.
14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?
El criterio de conformidad 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 un producto de apoyo, hasta un 200% (es decir, hasta dos veces el ancho y la altura) sin pérdida de contenido o funcionalidad. Por tanto, cuando el texto aumente no se deben producir desbordamientos o solapamientos de contenido que dificulten su percepción. Por ejemplo, porque algunos contenidos se salgan de su contenedor y se posicionen sobre otro contenido.

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.

15. ¿Cómo marcar la pronunciación de una palabra?
En el criterio de conformidad 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:
When we talk about these guidelines, we often just call them <ruby> <rb>WCAG</rb> <rp>(</rp> <rt>Wuh-KAG</rt> <rp>)</rp> </ruby>. 
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).
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">

Winnie the Pooh HTML </a> </dd>

<dd><a href="winnie_the_pooh.pdf">

Winnie the Pooh PDF </a> </dd>

<dt>War and Peace</dt>

<dd><a href="war_and_peace.html">

War and Peace HTML</a></dd>

<dd><a href="war_and_peace.pdf">

War and Peace 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:
```
Coming soon to a town near you...the final 15 in the

National Folk Festival lineup.

<a href="final15.html">[Read more...]</a>
```
Pero sería correcto:
```
Coming soon to a town near you...the final 15 in the

National Folk Festival lineup.

<a href="final15.html">[Read more...]</a>


```
De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)
De forma general, además de usar el texto de la frase que contiene al enlace, también podemos incluir la descripción adicional en aquellos elementos que los producto de apoyo como un lector de pantalla puede relacionar con el enlace. En estos casos es preferible que la información de contexto que aclara el propósito de los enlaces esté situada antes de los enlaces.
Entre los contextos que se pueden determinar por software tenemos:
- Elemento de lista (LI) que contiene al enlace.
- En listas anidadas, elemento de la lista padre (LI) que contiene la lista en la que se encuentra el enlace.
- Párrafo (P) que contiene al enlace.
- Celda (TD) de la tabla que contiene al enlace y sus encabezados asociados (TH)
- Elemento de encabezado anterior H1-H6
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 que se considere si la palabra se pronuncia igual que en el idioma del texto que la rodea (salvo por el acento o la entonación): 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:
- F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
- F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator.
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:
Si el foco es visible facilita el uso de las páginas web mediante el teclado al permitir reconocer visualmente y en todo momento cuál es el componente con el cual se está interactuando. Asimismo, resaltar los elementos cuando reciben el foco también sirve para que los usuarios sepan que se trata de elementos de interacción.
Por otra parte, las personas con problemas de atención, memoria a corto plazo o limitaciones para realizar procesos también se benefician al poder reconocer en todo momento dónde se encuentra el foco.
En caso de que queramos modificar la presentación del indicador del foco por defecto, debemos hacerlo de forma que mejoremos claramente su visibilidad (por ejemplo cuando un campo del formulario coja el foco que presente bordes anchos y otro color de fondo) y que se muestre tanto al coger el foco con el ratón como mediante el teclado.
También es importante otro aspecto relacionado con el foco, y es que los enlaces ocultos (por ejemplo para "saltar al contenido") deben ser visibles al menos cuando cojan el foco porque si siempre están ocultos generan desorientación y confusión a los usuarios de teclado al tabular por elementos no visibles.
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 o símbolos (40 si se trata de chino, japonés o coreano)..
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 :
- C20: Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized, o
- H87: Not interfering with the user agent's reflow of text as the viewing window is narrowed
Para cumplir este requisito es suficiente con no interferir en la reubicación del texto cuando se disminuye el tamaño de la ventana (hasta una cuarta parte del ancho de la pantalla). El objetivo es permitir que los usuarios puedan redimensionar la ventana hasta conseguir un ancho de línea ideal sin que se produzca scroll horizontal para leer una línea de texto.
Para ello el ancho de los contenedores principales de texto se deberá definir con unidades de medida relativas.
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 conformidad 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 conformidad 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 algunos criterios de conformidad de las WCAG 2.0 (1.4.3, 1.4.6) se establecen diferentes obligaciones en función de si el tamaño de texto es grande o no.
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 resumen, se considera texto grande al que tiene al menos 18 pt o 14 pt en negrita, medidas que, salvo para las fuentes muy delgadas o inusuales, se consideran suficientes para la mayor parte de las tipografías.
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:

Asociación compleja de radios y labels de forma accesible

2010-12-22T21:14:00.011+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.

Artículos relacionados:

Sobre el uso de lectores de pantalla

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

Última actualización: 14 de mayo 2012

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
30.01.2012 - Añadido el estudio Testing form control labelling support in popular browsers and screen readers sobre el soporte de legend y label (explícito e implícito)
17.02.2012 - Añadido estudio sobre el soporte de ARIA-Roles por los diferentes lectores de pantalla.
14.05.2012 - Añadido nuevo apartado sobre el soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles.

Í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
Testing form control labelling support in popular browsers and screen readers, publicado el 10.12.2012
Soporte de ARIA Roles con diferentes lectores de pantalla (JAWS, NVDA, VoiceOver, Chrome, Windows Eyes de Paciello Group Blog, publicado el 21.11.2011
Soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles de Henny Swan

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.)

10. Testing form control labelling support in popular browsers and screen readers

Resumen publicado el 12.01.2012 sobre el soporte de legend (en un fieldset) y label al etiquetar campos de un formulario web (implementado de forma explícita e implícita)

Se ha probado con JAWS 13, VoiceOver 4.0 y NVDA 2011.3 beta 1 sobre IE 9, Firefox 11.a2, Chrome 17beta, Safari 5.1.2 y Opera 11.6.

Se analiza también el soporte del atributo aria-labelledby

Destaca que tanto JAWS como NVDA sobre Chrome, como VoiceOver sobre Safari, leen el label y no el legend. En el resto de casos leen ambos.

El soporte de label, tanto de forma implícita como explícita es general, aunque en ciertos casos se lee dos veces.

11. Soporte de ARIA Roles con diferentes lectores de pantalla (JAWS, NVDA, VoiceOver, Chrome, Windows Eyes de Paciello Group Blog

Trato este y otros artículos de interés sobre el tema en el artículo: "HTML 5 y accesibilidad"

Puedes consultar diferentes vídeos donde se muestra el soporte de ARIA-Roles por diferentes navegadores en mi lista de reproducción de Youtube "HTML 5 y accesibilidad".

12. Soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles

Henry Swan tiene dos artículos muy interesantes:

Screen reader support for abbr and span on mobile, sobre el soporte de abbr y span con VoiceOver y otros lectores de pantalla de dispositivos móviles.
Use consistent text alternatives across desktop and mobile

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)

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"

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

2009-10-30T21:49:00.025+01:00

El contenido de este artículo se ha movido a la recopilación Respuesta a 25 dudas habituales sobre accesibilidad web

25 reglas para hacer CSS accesibles

2009-07-09T21:00:00.005+02:00

o "25 Normas de accesibilidad relativas a las CSS".

"Técnicas CSS para las Pautas de Accesibilidad al Contenido en la Web 1.0" del W3C:

Este documento describe unas técnicas para la creación de hojas de estilo en cascada (CSS) accesibles.
[...]
Aunque las técnicas descritas en este documento ayudarán a crear CSS conforme a las "Pautas de Accesibilidad al Contenido en la Web 1.0", estas técnicas no garantizan la conformidad y no son la única manera de crear contenidos conformes.

[Cita literal de dicho documento]

Este artículo recoge un resumen de las técnicas descritas. Se puede consultar el original para profundizar en cada punto.

Use un número mínimo de hojas de estilo en su sitio.

Use hojas de estilo vinculadas en vez de estilos incrustados (directamente en las etiquetas) y evite hojas de estilo incrustadas (directamente en la página).

Si tiene más de una, use el mismo nombre de clase ("class") para el mismo concepto en todas las hojas de estilo.

Use la unidad "em" para fijar el tamaño de letra.

Utilice unidades de medida relativas y porcentajes. Utilice medidas absolutas de longitud sólo cuando las características físicas del medio de salida sean conocidas, por ejemplo con imágenes de mapa de bits.

Proporcione un equivalente textual para cualquier imagen o texto importantes generados por la hoja de estilo (por ejemplo, mediante las propiedades "background-image", "list-style", o "content").

selectores de atributos.

la función attr() y la propiedad "content"

los seudo-elementos :before (antes) y :after (después)

Asegúrese de que todo contenido importante aparezca dentro del objeto del documento. El texto generado por las hojas de estilo no forma parte del código fuente del documento y no estará disponible para las ayudas técnicas que acceden al Modelo de Objeto del Documento Nivel 1 ([DOM1]).

CSS2 incluye diferentes mecanismos que permiten generar contenido desde la hoja de estilo:
- Los seudo-elementos :before y :after y la propiedad "content". Cuando éstos se emplean conjuntamente, permiten la inserción de marcadores antes o después del contenido del elemento.
- Las propiedades "cue", "cue-before", y "cue-after". Estas propiedades permiten a los usuarios reproducir un sonido antes o después del contenido de un elemento.
Especifique siempre un tipo de letra genérico por defecto.

Use las siguientes propiedades CSS2 para controlar la información de la fuente: "font", "font-family", "font-size", "font-size-adjust", "font-stretch", "font-style", "font-variant", y "font-weight", en lugar de los siguientes elementos y atributos de tipo de letra desaconsejados en HTML: FONT, BASEFONT, "face", y "size".

Si tiene que usar los elementos HTML para controlar la información sobre el tipo de letra, utilice BIG y SMALL, que no están desaconsejados.

Las siguientes propiedades CSS2 se pueden emplear para dar estilo al texto:
- Mayúsculas/minúsculas: "text-transform" (para mayúsculas, minúsculas y primera letra mayúscula).
- Efectos de sombra: "text-shadow"
- Subrayado: "text-decoration".
No use los elementos BLINK o MARQUEE. Estos elementos no aparecen en ninguna especificación W3C para HTML (es decir, son elementos no estándares)

Si se emplea contenido parpadeante (por ejemplo, un titular que aparece y desaparece a intervalos regulares), proporcione un mecanismo para detener el parpadeo. Con CSS, "text-decoration: blink" producirá el efecto de parpadeo y además permitirá al usuario detener el efecto desactivando las hojas de estilo o redefiniendo la regla en una hoja de estilo de usuario.

Utilice hojas de estilo para dar estilo al texto, mejor que representar el texto con imágenes. Usar texto en lugar de imágenes significa que la información estará disponible para un mayor número de usuarios y permitirá a los usuarios redefinir los estilos del autor y cambiar los colores o los tamaños de letra más fácilmente.

Si es necesario utilizar un mapa de bits para crear un efecto de texto (letra especial, transformación, sombras, etc.) el mapa de bits debe ser accesible.

Las siguientes propiedades CSS2 pueden ser usadas para controlar el formateo y posición del texto:
- Sangría: "text-indent". No utilice BLOCKQUOTE o cualquier otro elemento estructural para hacer sangrías en el texto.
- Espaciado de letras o palabras: "letter-spacing", "word-spacing". Por ejemplo, en lugar de escribir "H O L A" (que los usuarios generalmente reconocen como la palabra "hola", pero que un lector de pantalla leería como letras independientes) los autores pueden crear el mismo efecto visual aplicando a "HOLA" la propiedad "word-spacing". Los textos sin espacios serán transformados en discurso más fácilmente.
- Espacio en blanco: "white-space". Esta propiedad controla la interpretación del espacio en blanco del contenido de un elemento.
- Dirección del texto: "direction", "unicode-bidi".
- Los pseudoelementos: first-letter y :first-line permiten a los autores hacer referencia a la primera letra o línea de un párrafo del texto.
Use números en vez de nombres, para especificar colores.

Use estas propiedades CSS para especificar colores:
- "color", para el color de primer plano del texto.
- "background-color", para el color de fondo.
- "border-color", "outline-color" para colores de bordes.
- Para colores de vínculos, haga referencia a las pseudo-clases :link, :visited, y :active.
Asegúrese de que los colores de primer plano y de fondo tienen buen contraste. Si especifica el color de primer plano, siempre debe especificar también el color de fondo (y viceversa).

Asegúrese de que la información no se transmite sólo a través del color.

Emplee UL para listas sin ordenar y OL para las ordenadas (por ejemplo, utilizar marcadores de forma apropiada) conjuntamente con CSS para proporcionar indicaciones contextuales.(1)

Hasta que CSS2 sea ampliamente utilizada por las aplicaciones de usuario o éstas permitan al usuario controlar la interpretación de las listas a través de otros medios, los autores deberían considerar el proporcionar pistas contextuales en las listas anidadas no numeradas. (Ver ejemplo en el documento original)

Los contenidos deben ser maquetados, ubicados, colocados en capas y alineados mediante hojas de estilo (sobre todo mediante las propiedades CSS de float y colocación absoluta) y no mediante tablas:
- Las propiedades "text-indent", "text-align", "word-spacing" y "font-stretch", permiten a los usuarios controlar el espaciado sin añadir espacios adicionales. Utilice 'text-align:center' en lugar del elemento desaconsejado CENTER.
- Con las propiedades 'margin', 'margin-top', 'margin-right', 'margin-bottom' y 'margin-left', los autores pueden crear espacios en los cuatro lados del contenido de un elemento, en lugar de añadir espacios de no separación ( ).
- Con las propiedades "float", "position", "top", "right", "bottom" y "left", el usuario puede controlar la posición visual de casi cualquier elemento con independencia de donde aparezca el elemento en el documento. Las propiedades de ubicación pueden ser usadas para crear notas marginales (que se numerarán automáticamente), barras laterales, efectos similares a los marcos, encabezamientos y pies simples y otras más.
- La propiedad "empty-cells" permite a los usuarios dejar vacías celdas de tablas y poder proporcionarles bordes en la pantalla o en papel. Una celda de datos que debe estar vacía no debería ser llenada con un espacio en blanco o un espacio "non-breaking" sólo para lograr un efecto visual.
Proporcione textos equivalentes para todas las imágenes, incluyendo las imágenes invisibles o transparentes. Si los diseñadores de contenido no pueden usar hojas de estilo y deben utilizar imágenes invisibles o transparentes (por ejemplo, con IMG) para diseñar con imágenes en las páginas, deberían especificar alt="" para ellas.

Utilice las hojas de estilo para crear líneas y bordes. Las líneas y bordes pueden transmitir la noción de "separación" a los usuarios que pueden ver, pero este sentido no puede ser deducido fuera de un contexto visual.

Utilice las propiedades CSS para especificar los estilos de los bordes:
- "border", "border-width", "border-style", "border-color".
- Para las tablas, "border-spacing" y "border-collapse".
- Para contornos dinámicos, "outline", "outline-color", "outline-style" y "outline-width".
Asegúrese de que la presentación del contenido es comprensible cuando no se aplican hojas de estilo. Los autores deberían diseñar siempre documentos que tengan sentido sin hojas de estilo (por ejemplo, el documento debería escribirse en un orden "lógico") y entonces aplicar hojas de estilo para lograr efectos visuales.

Estudie la necesidad de utilizar propiedades auditivas de CSS2, las cuales proporcionan información para usuarios invidentes y usuarios de navegadores de voz de manera parecida al tipo de letra que proporciona información visual.

Las siguientes propiedades forman parte de hojas de estilo en cascada de CSS2.
- "volume" controla el volumen del texto hablado.
- "speak" determina si el contenido se pronunciará y, en caso afirmativo, si se debe deletrear o leer como palabras.
- "pause", "pause-before", y "pause-after" controla las pausas antes y después de anunciar el contenido. Permite a los usuarios separar los contenidos para mejorar la comprensión.
- "cue", "cue-before", y "cue-after" especifican un sonido que se reproducirá antes y después del contenido, lo que puede ser valioso para la orientación (parecido a una imágen visual).
- "play-during" controla los sonidos de fondo durante la presentación del elemento (parecido a un imagen de fondo).
- "azimuth" and "elevation" proporcionan una dimensión al sonido, lo que permite a los usuarios distinguir las voces, por ejemplo.
- "speech-rate", "voice-family", "pitch", "pitch-range", "stress", y "richness" controlan las cualidades de los contenidos hablados. Cambiando estas propiedades para diferentes elementos, los usuarios pueden ajustar con detalle la presentación sonora-auditiva de los contenidos.
- "speak-punctuation" y "speak-numeral" controlan la forma de decir los números y la puntuación, lo que afecta la calidad de la experiencia para la navegación por voz.
- la propiedad "speak-header" describe cómo se debe decir la información sobre los encabezados antes de una celda de tabla.
Cree distintas hojas de estilo para adaptar la presentación del documento a diferentes dispositivos de salida (Braille, sintetizadores de voz o dispositivos TTY, pantalla, móvil, etc.) mediante los "tipos de medios" de CSS2 (empleados con las reglas @media) Las reglas "@media" también pueden reducir los tiempos de descarga porque permiten a las aplicaciones de usuario ignorar reglas inapropiadas.

Notas
(1) La siguiente hoja de estilo CSS2 muestra cómo especificar números compuestos para listas anidadas creadas tanto con elementos UL como OL. Los ítems están numerados como "1", "1.1", "1.1.1", etc.

Ejemplo.


<style type="text/css">
    ul, ol { counter-reset: item }
    li { display: block }
    li:before { 
      content: counters(item, "."); 
      counter-increment: item;
    }
</style>

Imprescindibles (15)

2009-04-28T13:49:00.001+02:00

Estos son los artículos que han llamado mi atención últimamente (no tienen porque ser recientes):

Usabilidad

"Cómo ha de ser el diseño: una visión del análisis heurístico" de Torres Burriel.

"¿Cómo diseñar para móviles?" de Daniel Ulczyk.

"Para Nielsen las webs móviles deben ser simples y minimalistas", de Úsalo.

"Breadcrumb Navigation Increasingly Useful" de Jakob Nielsen.

"CRAP Design (traducción)" de MinaLab

"3 Pasos para crear una web profesional: Paso 1 Fijar objetivos" de Galería CSS.

"OPTGROUP y la usabilidad en SELECT" de Javier Fernández Rivera.

SEO

"Cómo asegurarnos de que Google visite a fondo nuestras páginas web en 10 pasos" de acceso.com

"Un buen plan SEO" de Daniel Ulczyk.

SEO CheatSheet

Navegadores

"Safari 4.0 es el navegador mas rápido" de Geekets.

"Rendimiento de los navegadores dependiendo del código HTML" de anieto2k.

Imprescindibles anteriores (recopilación de artículos de interés)

Noticias... (17)

2009-04-06T00:00:00.001+02:00

Estas son las noticias que llamaron mi atención el mes pasado:

"La web de Metro de Madrid denunciada por no ser accesible", accesibilidadweb.com (2/04/09)

[...] tanto el Cermi Estatal como el de la Comunidad de Madrid solicitan el inicio de la actuación administrativa que permita comprobar los hechos denunciados y la instrucción del expediente y la imposición de la sanción que corresponda.

"Pautas de accesibilidad para agentes de usuario (UAAG) 2.0: Borrador de Trabajo actualizado", W3C.es (11/03/2009)

"Arsys pone en marcha la fase de registro libre del nuevo dominio .tel", larioja.com (25/03/09)

Sobre Explorer 8
- "Internet Explorer 8, primeros impresiones técnicas", anieto2k
- "Nuevo internet explorer, nuevo lector de pantalla", en Programar a ciegas.
- "Microsoft lanza Internet Explorer 8 con la intención de mantener su cuota de mercado", en Libertad Digital.

Proyectos BBVA Open Talent relacionados con la accesibilidad:
- Sistema de Emergencias 112 Accesible (más información sobre el proyecto)
- Accescopio u Observatorio Automático de la Accesibilidad Web.

Noticias anteriores

Imprescindibles (14)

2009-03-08T16:21:00.007+01:00

Estos son los artículos que han llamado mi atención últimamente (no tienen porque ser recientes):

Usabilidad

Gestión y prevención de errores en interfaces de usuario de Deinterfaz.

¿Qué es necesario saber para dedicarse a la usabilidad? de Torres Burriel.

"Medir al consultor de usabilidad" de Alberto Lacalle.

Cómo evitar contenido duplicado de Daniel Ulczyk. Relacionado: "Multi categories website structure. Who needs the canonical tag?" de Ani López.

rel=”canonical”, lo último para combatir el contenido duplicado de Andrés Nieto.

User Experience Deliverables de Peter Morville.

Diseño defensivo en formularios de Usolab.

¿Conoces los microformatos que están por venir? de Torres Burriel.

Eyetracking, movimiento e información neuronal de Sopa de bits.

Consejos para diseñar emails de Sentido Web.

Diseño y maquetación

Reemplazo de textos – una comparación de Diseñorama.

A vueltas con los 72 dpi de Diario de un Infografista.

Accesibilidad

Survey of Preferences of Screen Readers Users de Webaim.

Accessibility footnotes (o cómo implementar de otra manera el LONGDESC) de Andy Clarke.

Varios

Qué acciones tomar cuando roban tus contenidos de Maestros del Web.

Enlaces en los que perderse (3)

2009-03-05T15:01:00.001+01:00

Accesibilidad

Curso de accesibilidad online y gratuito de SEDIC. El nivel es muy básico pero puede ser interesante el apartado de recursos sobre accesibilidad.

100 Killer Web Accessibility Resources: Blogs, Forums and Tutorials en WHDB.

Publicaciones de capaces.org

Accessibility en icant.co.uk de Christian Heilmann.

Usabilidad

Proyecto nuevo portal web Unicauca, ¿quieres seguir paso a paso la creación de un portal? Puedes consultar los wireframes, las pruebas de cardsorting, seguir el proceso de diagramación del portal o consultar el análisis de otros portales similares mediante evaluaciones heurísticas.

Publications, Nielsen Norman Group. Y por supuesto Useit de Jakob Nielsen

Usability Resources, Information & Design

Diseño

Preimpresión, "apuntes personales sobre el curso de diseño y producción editorial" por Percy Emerson (en español)

CSS Feeder Design Aggregator

Varios

Materiales de formación del CNICE

Documentos que recomiendo conocer (4)

2009-03-05T15:00:00.002+01:00

"Guía para la edición y publicación de las
páginas web de la Administración General del Estado" (España)

"Sitios Exitosos: De los Estándares Web a la Experiencia de Usuario" de Gabriel Porras.

En INTECO:

Documentos que recomiendo conocer (3)

2009-01-22T22:26:00.001+01:00

Artículos relacionados
[29-07-08] Documentos que recomiendo conocer (1)
[15-11-08] Documentos que recomiendo conocer (2)

Guía para la accesibilidad de discapacitados en los sitios Web de la administración del Estado (de Chile). Es un PDF de 29 páginas, fechado en diciembre de 2006, que resulta una buena introducción a la accesibilidad web.

Guía de Recomendaciones de posicionamiento SEO en Internet, como resume Libro de Apuntes, los 10 pasos a seguir para optimizar nuestra web son:
- Comprueba que las urls de tus páginas son adecuadas.
- Revisa cómo están escritos los enlaces en tus páginas.
- Optimiza los títulos.
- Optimiza el contenido de tus páginas.
- Mide tu tráfico.
- Analiza la actividad de las arañas de los buscadores.
- Mide tu ranking para tus principales palabras clave.
- Mide el número de páginas que tienes indexadas.
- Crea y optimiza un Robots.txt y un sitemap.
- Trabaja tus contenidos y consigue enlaces.

INTECO: Comprobación de la accesibilidad de objetos multimedia, o cómo debemos revisar las animaciones, vídeos y sonidos para asegurarnos que éstos son accesibles para todos los usuarios. En relación con este tema:
- "Accesibilidad al contenido web, una de tus herramientas" de ervdesign, que recoge unas normas elementales para trabajar con vídeos en la web.
- "Sobre vídeo y audio en páginas web", discusión en Accesoweb.

Imprescindibles (13)

2009-01-21T22:39:00.002+01:00

Estos son los artículos que han llamado últimamente mi atención (no tienen porque ser recientes):

"Best of CSS Design 2008" de WebDesigner Wall.

30 Usability Issues To Be Aware Of, un artículo imprescindible donde se resumen reglas, términos y principios relacionados con la usabilidad.

10 Reasons Clients Don't Care About Accessibility. Relacionado con Argumentos para vender accesibilidad

"¿Qué no es la experiencia de usuario?" de Itákora.

"Analizar y representar gráficamente los resultados de un card sorting" de deinterfaz.com. Y relacionado con el tema "Card sorting: un caso práctico en el diseño de un sitio web universitario" de NSU.

"Principios del diseño de interacción importantes para la accesibilidad" de areia.info

Imprescindibles (12)

2008-11-22T22:04:00.000+01:00

Estos son los artículos que han llamado últimamente mi atención (no tienen porque ser recientes):

Diseño

"Escogiendo tipografías", de Letritas.

Si estuviéramos trabajando en condiciones ideales, donde sólo nos debatimos a elegir entre las tipografías que tenemos, y todas funcionan correctamente (todas tienen "eñe", "acentos", y están bien espaciadas) ¿Cuál debiese ser nuestro principal criterio de elección?

"11 Images you might want to avoid in your designs", de snap2objects.

I will show some images I considered overused since the beginning of the web and could make your website (or any design) look generic, unimaginative and dated - if use them just for the sake of it.

Un recurso para cuando te piden que incluyas las típicas imágenes de manos dando apretones o edificios acristalados.

"Editores web que facilitan tu trabajo" de Maestros del Web.

Usabilidad

"12 preguntas clave para un proyecto web", de MoccaBlog Café.

El objetivo es definir el diseño y el acercamiento al usuario final (cliente de tu cliente).

"La evolución de los errores según Jakob Nielsen", de Interacciones. Relacionado con este post se puede leer el artículo "Error Message Guidelines" de Jakob Nielsen.

"Consejos para presentar los resultados de un test de usabilidad", deinterfaz.

Simplificando, podríamos decir que se pueden generar resultados rápidos (informes ligeros que van al grano) y resultados formales (informes completos y documentados), cada uno con sus ventajas y sus inconvenientes. Yo me voy a centrar los segundos.

Relacionado con este artículo está el de Jakob Nielsen: "Formal Usability Reports vs. Quick Findings"

"What reading Tufte won’t teach you: Interface design guidelines", de glyphobe

Estudio "Publicidad y Contenidos en medios de comunicación online Estudio de Eyetracking a diarios online chilenos" de AyerViernes.

Estudio "Eyetrack Medios España" de Alt64. Se puede descargar directamente en formato PDF.
Eyetracking Medios España tiene por objetivo:
- Estudiar el comportamiento visual de los internautas españoles.
- Estudiar la efectividad de la publicidad online.

"Eyectrack III: Cómo lucen los sitios web a través de los ojos de los lectores" de Steve Outing y Laura Ruel.

"Dónde estudiar HCI en España" en Itákora.

"Quién es quién en el mundillo de HCI española" de Itákora.

Accesibilidad

"Serie 'Guía breve para crear sitios web accesibles'", de Accesibilidad en la Web.

"Navegando una página Web con Jaws: consideraciones de accesibilidad para desarrolladores" deinterfaz.

Vamos a ver de qué manera un usuario que utiliza Jaws navega entre los diferentes elementos de una página Web y como un desarrollador de páginas Web debería actuar para alcanzar el nivel de accesibilidad Doble A (AA).

"Redactar una auditoría de Accesibilidad Web de alto nivel" de interfaz.

"Presentaciones sobre Accesibilidad" de Usabilidad y Accesibilidad.

"Data Table Accessibility Test Page" de Web Usability.

"Enlaces para 'leer más' que sean simples y accesibles" de Torres Burriel.

Documentos que recomiendo conocer (2)

2008-11-15T22:15:00.001+01:00

Artículos relacionados
[29-07-08] Documentos que recomiendo conocer (1)

Informe "Tecnología y discapacidad visual: necesidades tecnológicas y aplicaciones en la vida diaria de las personas con ceguera y deficiencia visual", coordinado por Xavier Grau Sabaté.

Este amplio informe, cuya elaboración y publicación han sido impulsadas por la Comisión de Nuevas Tecnologías e Informática Accesible del Consejo General de la ONCE, se estructura en tres grandes apartados en los que se abordan, respectivamente, la evolución general de las nuevas tecnologías, su aplicación a las necesidades de las personas con discapacidad visual y los avances tecnológicos que se han producido según las distintas áreas de interés para la vida cotidiana. Los 36 capítulos de que consta la obra han sido redactados por 22 expertos autores. Los aspectos generales del informe se recogen en el apartado final de conclusiones.

"Directrices europeas para facilitar la lectura", de la Asociación Europea ILSMH. Documento de 1998 que se puede consultar en SIDAR.

XML Accesibility Guidelines, W3C Working Draft 3 October 2002.

This document provides guidelines for designing Extensible Markup Language (XML) applications that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).

Too much accessibility. GOOD INTENTIONS, BADLY IMPLEMENTED de Patrick H. Lauke

"Fujitsu Web Accessibility Guidelines". Más información en su web Fujitsu Accessibility

"Design Guidelines for Accessible Information Communication Technology Systems" de tiresias.org

Artículos relacionados
[29-07-08] Documentos que recomiendo conocer (1)

Más accesible a pesar de Blogger (2)

2008-10-15T09:00:00.000+02:00

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

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

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

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

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

Día 1: Atajos de teclado

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

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

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

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

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

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

Día 2: Página "Accesibilidad"

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

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

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

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

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

Día 3: Enlaces rotos

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

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

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

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

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

Día 4: Estilo de los enlaces

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

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

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

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

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

Para ello creo dos nuevos tipos de menú:

Menú superior "Saltar a"

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

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

Enlaces "Saltar a" bajo las columnas de contenido

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Me encuentro dos problemas en Blogger:

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

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

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

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

Día 7: Nuevas ventanas

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

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

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

En las WCAG 2.0 podemos leer:

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

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

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

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

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

Tareas programadas para revisar el blog

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

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

Revisar una vez al mes:

Vínculos rotos con W3C Link Checker

Comprobar:

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

Buenas prácticas para crear artículos accesibles

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

Tareas para futuras revisiones

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

Notas

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

Usable y accesible

Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

Falso Error 1: campo de texto sin LABEL asociado... pero que tiene un TITLE adecuado

Falso Error 2: imagen que es un enlace y tiene ALT vacío... pero que va acompañada por un texto dentro del enlace

Falso Error 3: H2 presente en el código antes que un H1... sin tener en cuenta que estén bien marcados

Falso Error 4: indicar en cualquier caso que es obligatorio incluir enlaces para saltar bloques de contenido y un primer enlace en la página que lleve al contenido principal de la misma

Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas

HTML

CSS

JS

Qué teclas de acceso rápido (accesskey) utilizar

UK Government accesskeys standard

Swedish Government accesskeys standard

HTML 5 y accesibilidad

Elemento video y accesibilidad

Combinar los nuevos marcadores semánticos con ARIA Roles

Accesibilidad HTML 5 y RIA (Rich Internet Applications)

Otros artículos de interés sobre HTML 5 y accesibilidad

Herramienta de ayuda para validar de acuerdo a las WCAG 2.0

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

Qué es y qué no es

Descripción de la herramienta

Pestaña 1: General

Pestaña 2: A

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

Pestaña 3: AA

Pestaña 4: Por puntos de verificación

Descarga de la herramienta

Consejos avanzados de accesibilidad web

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

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

Display:none

Visibility:hidden

Height:0

Posicionar el texto fuera de pantalla

Clip

Conclusión

SEO y Accesibilidad. Accesible también para buscadores

Índice

Texto equivalente para todo elemento no textual

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

Javascript

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

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

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

Marcado correcto y uso adecuado de encabezados

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

Escribir para la web

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

Enlaces

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

Frames

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

Metainformación e idioma

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

Mapa web

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

Redireccionamiento automático

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

Respuesta a 25 dudas habituales sobre accesibilidad web

1. ¿Puedo utilizar ventanas emergentes?

H83: Using the target attribute to open a new window on user request and indicating this in link text

¿Se puede ocultar la aclaración "se abre en ventana nueva" mediante la CSS? ¿Se puede indicar en el title del enlace?

SCR24: Using progressive enhancement to open new windows on user request

Conclusión

2. ¿Puedo utilizar frames?

3. ¿Puedo utilizar tablas para maquetar?

4. ¿Mi sitio es inaccesible si utiliza Flash?

5. ¿Mi sitio es inaccesible si utiliza javascript?

¿Es necesario ofrecer una alternativa al JavaScript? ¿Se debe realizar una versión que funcione sin JavaScript?

6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?

7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?

8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?

Si la abreviación tiene un único significado en la página

Si la abreviación tiene diferentes significados dentro de la misma página

9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?

10. ¿Cómo se especifica correctamente el color de fondo y primer plano?

11. ¿Cómo marcar adecuadamente un emoticon?

12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?

13. ¿Es recomendable incluir una opción de "Leer está página"?

Elemento `video` y accesibilidad

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