Diseño para Todos 2

WEB PARA TODOS.
p65 1 12/11/2007, 12:17

WEB PARA TODOS.p65 2 12/11/2007, 12:17
DISEÑO WEB PARA TOD@S II
WEB PARA TODOS.p65 3 12/11/2007, 12:17

WEB PARA TODOS.p65 4 12/11/2007, 12:17
PROGRAMA MODULAR EN
TECNOLOGÍAS DIGITALES Y SOCIEDAD DEL CONOCIMIENTO
DISEÑO WEB
PARA TOD@S II
CREANDO UNA WEB ACCESIBLE
Materiales elaborados por:

CARLOS EGEA GARCÍA
Con la colaboración de:
ALICIA SARABIA SÁNCHEZ
SOCIEDAD DEL CONOCIMIENTO
WEB PARA TODOS.p65 5 12/11/2007, 12:17

Diseño de la cubierta: Carmen Rosa Redondo
© UNED (Universidad Nacional de Educación a Distancia)
© Carlos Egea García
Colaboradores: Alicia Sarabia Sánchez
Coordinadora de la colección: Sara Osuna Acedo
© De esta edición
Icaria editorial, s.a.
Arc de Sant Cristòfol, 11-23 - 08003 Barcelona
www.icariaeditorial.com
ISBN: 978- 84-7426-957-4

Depósito legal: B-52.806-2007
Fotocomposición: Text Gràfic
Impreso en Romanyà/Valls, s.a.

Verdaguer, 1, Capellades (Barcelona)
WEB PARA TODOS.p65 6 12/11/2007, 12:17

ÍNDICE
Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
CREANDO PÁGINAS WEB ACCESIBLES
Creando hojas de estilo en cascada accesibles . . . . . . . 19

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
¿Qué son las hojas de estilo en cascada? . . . . . . . . . . . . . . . 19
¿Por qué se las llama «en cascada»? . . . . . . . . . . . . . . . . . . 20
El aspecto del control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Usando CSS a nuestro favor . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Dificultades de CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Pautas aplicables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Creando imágenes accesibles . . . . . . . . . . . . . . . . . . . . . . . . 31

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Ilustraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Iconos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Vídeo y multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Color y contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Texto con gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Gráficos que pueden causar ataques epilépticos . . . . . . . . . . 39
Texto alternativo (alt text) efectivo . . . . . . . . . . . . . . . . . . . . . . 40
Mapas de imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Imágenes de fondo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
WEB PARA TODOS.p65 7 12/11/2007, 12:17

Descripciones largas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Creando marcos (frames) accesibles . . . . . . . . . . . . . . . . . 59

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Accesibilidad en los marcos (frames) . . . . . . . . . . . . . . . . . . . 60
Creando tablas accesibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Tablas de maquetación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Tablas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Creando formularios accesibles . . . . . . . . . . . . . . . . . . . . . . 79

Accesibilidad general de los formularios . . . . . . . . . . . . . . . . . 79
Accesibilidad del lector de pantalla al formulario . . . . . . . . . . 82
Asociación de etiquetas con elementos de formulario . . . . . . 85
Controles de formulario accesibles . . . . . . . . . . . . . . . . . . . . . 87
Usando Dreamweaver y FrontPage . . . . . . . . . . . . . . . . . . . . 92
Creando JavaScript accesible . . . . . . . . . . . . . . . . . . . . . . . . 95

¿Qué es JavaScript? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Manejadores de evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Usando manejadores de evento independientes
del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Otros aspectos de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 102
Alternativas a JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Resumen de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Creando contenido accesible con Flash de Macromedia 113

Visión general de la accesibilidad de Flash . . . . . . . . . . . . . . . 113
Tecnologías de apoyo soportadas por Flash . . . . . . . . . . . . . . 115
Accesibilidad con lector de pantalla . . . . . . . . . . . . . . . . . . . . . 117
Equivalentes textuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
WEB PARA TODOS.p65 8 12/11/2007, 12:17

Accesibilidad del teclado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Otras técnicas y consideraciones de accesibilidad . . . . . . . . . 129
Verificando la accesibilidad en páginas web . . . . . . . . . . . 139

Verificando el código HTML y CSS . . . . . . . . . . . . . . . . . . . . . 139
Verificando la accesibilidad web con herramientas
automáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Verificando la accesibilidad con Dreamweaver 2004 MX . . . . 148
La barra de herramientas de accesibilidad web de AIS
para Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
La barra de herramientas Web Developer para Firefox . . . . . 161
Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Información general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Empresas españolas comprometidas
con la accesibilidad web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Recursos para deficiencia visual . . . . . . . . . . . . . . . . . . . . . . . 165
Herramientas para evaluar y validar la accesibilidad web . . . 166
WEB PARA TODOS.p65 9 12/11/2007, 12:17

WEB PARA TODOS.p65 10 12/11/2007, 12:17
The power of the Web is in its universality.
Access by everyone regardless of disability is an essential aspect.
Tim Berners-Lee, W3C Director and inventor of the World Wide Web
El poder de la Web está en su universalidad.

El acceso para todos, a pesar de la discapacidad,
es un aspecto esencial
Tim Berners-Lee, Director de W3C e inventor de World Wide Web
WEB PARA TODOS.p65 11 12/11/2007, 12:17

12
WEB PARA TODOS.p65 12 12/11/2007, 12:17

Prólogo
La irrupción del servicio web a través de internet ha supuesto un cambio

drástico y no previsto en la forma de acceder a la información, sin que ni
los más aventurados escritores de ciencia ficción de principios del siglo XX
pudieran anticipar su impacto social para finales de él.
Las posibilidades que se abren a todos los ciudadanos para democra-
tizar el acceso a la información se han visto incrementadas por la aparición
de este nuevo sistema de comunicación. Desde cualquier punto conectado
a internet podemos acceder a un inmenso mundo de información hasta la
fecha inabarcable.
Estos avances han supuesto, también, para las personas con limitacio-
nes funcionales la apertura de expectativas hace poco impensables. Las
«ventanas» de internet pueden suponer la eliminación de barreras físicas
que obstaculizaban el acceso a medios y servicios que antes no podían
ser utilizados por algunas personas.
Pero la web, con su «poder universal», de poco sirve si en su diseño
no tenemos en cuenta las especiales características de algunos de sus
usuarios. Para tal fin, el Consorcio Mundial de la Web (World Wide Web
Consortium), conocido por las siglas W3C, puso en marcha una iniciativa
encaminada a definir y difundir las pautas para la accesibilidad de la web.
La Iniciativa de Accesibilidad en la Web (Web Accessibility Initiative), cono-
cida por sus siglas WAI, comenzó su andadura redactando un documento
de bases en el que se recogieran, como recomendaciones técnicas, los
criterios a tener en cuenta para diseñar de forma accesible las páginas
web.
El resultado final de estos trabajos en pro de una normativa técnica
para hacer accesibles los contenidos de la web se plasmó en un documen-
to que fue aprobado como Recomendación W3C, con el nombre de «Pau-
tas de Accesibilidad al Contenido en la Web 1.0» («Web Content
13
WEB PARA TODOS.p65 13 12/11/2007, 12:17

Accessibility Guidelines 1.0»), también conocidas por sus siglas WCAG 1.0.
Esta Recomendación, junto a otras dedicadas a las herramientas de edi-
ción y las aplicaciones de usuario, conforman la referencia de normativa
técnica para aplicar los criterios para un diseño accesible de la web.
En sus catorce pautas se recogen los principios básicos para conse-
guir el objetivo de poner los contenidos de la web a disposición de TODOS.
Para llevar a efecto dicha tarea, junto al documento normativo, se redactó
un anexo que recoge las técnicas para aplicar los criterios de accesibilidad.
Éstos y otros documentos pueden encontrarse en la web que, dentro del
sitio de W3C, mantiene el grupo WAI (http://www.w3.org/WAI/). También
está disponible una versión traducida al castellano de estos documentos,
que se puede encontrar en una de estas direcciones:
• http://usuarios.discapnet.es/disweb2000/WCAG2003/index.htm
• http://www.technosite.es/document_accesibilidad.asp
Las frecuentes preguntas sobre cómo aplicar los criterios de accesibi-

lidad han llevado a algunos grupos de trabajo a redactar sus propios docu-
mentos que, con un afán pedagógico, tratan de explicar a quienes se acer-
can a la «accesibilidad web» el procedimiento para conseguir el objetivo
propuesto.
Una de estas iniciativas es la llevada a cabo por la web «Web
Accessibility In Mind» («Teniendo en cuenta la accesibilidad en la web»),
conocida por las siglas WebAIM. Entre los trabajos que este sitio web (http:/
/www.webaim.org) pone a disposición de todos, destacan aquellos referi-
dos a las «técnicas y conceptos».
Tomando como referencia algunos de los documentos que WebAIM
ha realizado, hemos elaborado este material sobre cómo aplicar a deter-
minadas tareas de diseño los criterios de accesibilidad para el contenido
en la web.
El resultado es este documento que trata de orientar a aquellos que
pretenden conseguir una web para todos.
14
WEB PARA TODOS.p65 14 12/11/2007, 12:17

Introducción
Los materiales que recoge este libro sirven de referencia para la segunda
parte del módulo sobre «Diseño para todos», dentro del Programa Modu-
lar en Tecnologías Digitales y Sociedad del Conocimiento de la Universi-
dad Nacional de Educación a Distancia (UNED). Sin el conocimiento y la
comprensión de los materiales correspondientes a la primera parte de este
módulo,1 puede que el contenido de este documento no sea entendido.
Con el nombre genérico de Creando páginas web accesibles, presen-
tamos en este documento una serie de capítulos que tratan de orientar al
desarrollador sobre qué tareas debe realizar para conseguir este objetivo.
Comenzaremos por ver cómo hacer que nuestra hoja de estilos haga
que los contenidos de nuestras páginas web sean accesibles. El segundo
capítulo recoge uno de los apartados claves: el referido a la creación de
imágenes, de todo tipo, que sean accesibles. Los dos siguientes capítulos
se dedican a la correcta y accesible aplicación de marcos (frames) y tablas
(tanto de maquetación como de datos).
La creación de formularios accesibles, el procedimiento para hacer un
javascript siguiendo los criterios de accesibilidad y la forma de realizar un
flash que no suponga una barrera insalvable para aquellos que manejan
aplicaciones de usuario especiales, son los contenidos que tratamos en los
siguientes tres capítulos.
El capítulo «Verificando la accesibilidad en páginas web» lo dedica-
mos a describir herramientas y procedimientos para la evaluación y valida-
ción de la accesibilidad de las páginas web. Su correcto uso nos propor-
ciona indicadores de la accesibilidad de un sitio web, lo que nos permitirá,
1. Egea García, C., (2007), Diseño Web para Todos I, Icaria, Barcelona.
15
WEB PARA TODOS.p65 15 12/11/2007, 12:17

conociendo los errores, hacer un diseño que se ajuste a las necesidades
de cualquier persona con independencia de sus limitaciones, ya sean per-
sonales o de equipamiento.
El último bloque de este libro se reserva para una serie de referencias
en la web con documentos que nos proporcionan información y herramien-
tas para la aplicación de todo lo tratado en este módulo.
Carlos Egea García

Febrero de 2007
16
WEB PARA TODOS.p65 16 12/11/2007, 12:17

Creando páginas web
accesibles
Traducción y adaptación
sobre textos de WebAIM por
CARLOS EGEA GARCÍA Y ALICIA SARABIA SÁNCHEZ
17
WEB PARA TODOS.p65 17 12/11/2007, 12:17

18
WEB PARA TODOS.p65 18 12/11/2007, 12:17

Creando hojas de estilo
en cascada accesibles
Introducción
Durante años, la única manera de maquetar HTML con un aspecto atracti-

vo era usando tablas, aunque las tablas fueron creadas originalmente para
mostrar datos tabulares. A medida que la web evolucionó y se hizo más
sofisticada, los diseñadores querían hacer algo más que mostrar texto,
querían emular los documentos escritos. Querían hacer una exposición ar-
tística. Eso no es malo. De hecho, las tablas se pueden usar para maquetar
sin arruinar por ello la accesibilidad de un sitio. Sí, está bien usar tablas
para maquetar.
Sin embargo, podemos elevar el nivel de diseño de una web eliminando
las tablas completamente. La forma de hacerlo es mediante las CSS (hojas
de estilo en cascada). Antes de avanzar demasiado, puntualizaremos que
también se puede crear un sitio web INaccesible usando CSS. No hay nada
mágico en las CSS que elimine las barreras a la accesibilidad.
La fuerza de las CSS reside en su capacidad para separar el contenido

de la presentación y para permitir un control más preciso sobre la
maquetación.
¿Qué son las hojas de estilo en cascada?
Las hojas de estilo en cascada, o CSS, permiten modificar las propieda-

des de las etiquetas HTML existentes. Todos los navegadores web están
basados en una hoja de estilo incorporada. Esta hoja de estilo forma parte
del programa y no es visible. Da instrucciones al navegador sobre cómo
mostrar aspectos o elementos particulares de su página. Por ejemplo, cuan-
do el navegador ve la etiqueta <p>, sabe que tiene que saltar de línea y
19
WEB PARA TODOS.p65 19 12/11/2007, 12:17

empezar una nueva sección, ya que ésta es la información que le da la
hoja de estilo incorporada. Las etiquetas <b>, <table> y cualquier otra
de HTML se definen en esta hoja de estilo: tamaño, color, posición y otras
características, que están definidas en ella. Cuando el usuario añade su
propia hoja de estilo a una página web, puede anular la hoja de estilo
incorporada y dar instrucciones al navegador sobre cómo mostrar los ele-
mentos de una forma diferente, de acuerdo con su propia hoja de estilo.
Aunque la mayoría de etiquetas permiten añadir atributos para darles
ciertas características (por ejemplo, color= «rojo»), con las hojas de estilo
tenemos mayor flexibilidad y la capacidad de añadir bastantes atributos
que no están disponibles en el HTML normal. Una de las ventajas de las
hojas de estilo (o simplemente «estilos», para abreviar) es que no se tie-
nen que añadir atributos extra a las etiquetas individuales, sino que, en su
lugar, se puede definir un estilo para que esa etiqueta cumpla con ese
atributo cada vez que se use. Así, si queremos que todos los párrafos de
una página tengan un cierto tamaño, no tenemos porqué usar la etiqueta
<font> (fuente o tipo de letra) en cada uno. En su lugar, la CSS le dice al
navegador que cada vez que lea la etiqueta <p> coloque el elemento al
que ésta se refiere en el tamaño que hayamos seleccionado. Igualmente,
los estilos son fáciles de editar y cambiar; en lugar de tener que encontrar
y editar cada etiqueta HTML que aparezca, podemos cambiar el estilo que
estuviera definido para esa etiqueta y todas las etiquetas de ese tipo de la
página web (o del sitio completo) se cambiarán.
¿Por qué se las llama «en cascada»?
Las Hojas de Estilo en Cascada aplican una jerarquía de importancia. El

usuario tiene el máximo nivel de control. Mediante la aplicación de una
hoja de estilo seleccionada por el usuario, éste tiene el completo control
sobre los estilos de la página web. El siguiente nivel descendente de jerar-
quía está en el propio documento. Si se aplica un estilo a la etiqueta, tiene
preferencia sobre cualquier otra declaración de estilo (excepto para los
estilos del propio usuario). Más abajo en la jerarquía se encuentran los
estilos especificados mediante el <head> (encabezado) de una sola pági-
na y después los estilos especificados en documentos externos. Se puede
20
WEB PARA TODOS.p65 20 12/11/2007, 12:17

decir que el documento especificado más recientemente es el que real-
mente se aplica. Esta cascada de jerarquías es la razón por la que se
denominan «hojas de estilo en cascada».
Imagen 1. Jerarquía de la cascada de estilos.
Del mismo modo, si se declara más de una vez un estilo para el mis-
mo elemento, se aplicará el último estilo que se declare. Echemos un vis-
tazo a los mismos atributos de estilo de abajo:
h1
{
color:red;
background-color:yellow;
}
h1
{
color:blue;
background-color:red;
}
h1
{
color:white;
background-color:black;
}
21
WEB PARA TODOS.p65 21 12/11/2007, 12:17

En este ejemplo, hay tres combinaciones de colores diferentes para la
etiqueta h1. Las dos primeras combinaciones de colores serán ignoradas.
Sólo se aplicará la última. La última de la cascada prevalece sobre las
demás.
El aspecto del control
El hecho de que el usuario final sea quien tiene el máximo control sobre
los estilos de una página web beneficia la accesibilidad. Ello significa que
una persona con una visión extremadamente baja puede convertir el color
de fondo de todas las páginas web en negro, y la fuente en un texto blanco
en negrita aumentado al 300% (o cualquier otro estilo que beneficie las
necesidades de ese individuo). Algunos diseñadores son reticentes a en-
tregar el control sobre el aspecto y sensación de sus creaciones. La ver-
dad es que ellos nunca han tenido ese control. La web es un formato elec-
trónico. La gente puede verla con cualquier navegador que elija y puede
manipularla tanto como quiera.
Por ejemplo, estamos acostumbrados a ver el sitio web de Google así:
Imagen 2. Vista de la página principal de Google con un navegador estándar.
22
WEB PARA TODOS.p65 22 12/11/2007, 12:17

No obstante, si lo viéramos en un navegador sólo texto, tendría un
aspecto similar a éste:
Imagen 3. Vista de la página principal de Google con un navegador sólo texto.
Cuando uno cae en ello, se da cuenta que la idea de que los desarro-
lladores de web tienen control sobre cómo se muestran sus contenidos
es una mera ilusión.
El aspecto y sensación finales siempre han estado bajo control del

usuario. Con las hojas de estilo, este control simplemente se incrementa.
En vez de luchar contra ello, los desarrolladores web deberían simplemen-
te aceptarlo y asegurarse de que sus documentos se transforman bien
cuando se aplique una hoja de estilo diferente de la especificada por ellos.
Usando CSS a nuestro favor

Separando el contenido de la presentación
Tal y como hemos mencionado anteriormente, uno de los primeros benefi-

cios de las CSS es que permiten a los autores separar el contenido de su
presentación. Contenido incluye el texto, las imágenes y otros elementos
que constituyen el núcleo del documento. Presentación es el modo en
que ese contenido se presenta. La forma más fácil de hacerlo es con el
navegador Opera (disponible en www.opera.com).
23
WEB PARA TODOS.p65 23 12/11/2007, 12:17

Imagen 4. Pantalla de la opción de Opera que le permite ir
a Modo de usuario y deshabilitar los estilos de página.
Sin los estilos, el sitio parece otro completamente diferente. La presen-

tación del contenido está separada del contenido en sí mismo. El conteni-
do puede presentarse con diversas combinaciones de estilos, pero el con-
tenido en sí mismo no cambiará. Esto es lo que significa separar el contenido
de la presentación.
Alterando la maquetación alineada

Con las hojas de estilo tenemos mayor control sobre la maquetación que
con las tablas. Uno de los beneficios de accesibilidad de este control es
que se puede cambiar la maquetación alineada de una página sin alterar
la maquetación visual. La maquetación alineada se refiere al orden de los
elementos de una página web cuando se han eliminado todos los estilos y
formateos. El orden de lectura alineada del contenido web es importante
para los usuarios de lectores de pantalla, porque ese es el orden en que
los lectores de pantalla acceden al contenido. Los lectores de pantalla ig-
noran cualquier estilo del contenido web. Todo lo que queda es el conteni-
do, sin ninguna presentación. Esta versión «desnuda» de las páginas web
es todo a lo que acceden los lectores de pantalla.
24
WEB PARA TODOS.p65 24 12/11/2007, 12:17

¿Cómo se puede decir cuál será el orden de lectura alineada de una
página web? Aquí está la respuesta:
El orden de lectura alineada de una página web es el orden literal del

contenido en el marcado HTML.
Una de las cosas buenas de las hojas de estilo es que no se tiene que
alterar el formateo visual de una página web cuando se altera el orden de
lectura alineada. Esto puede ser útil cuando se quiera asegurar que los
usuarios de lectores de pantalla acceden al contenido de la página en un
cierto orden.
Mediante la etiqueta <div> que rodea el contenido principal podemos
colocarlo al principio del documento, poniéndolo al inicio del orden de ali-
neación. Este ejemplo es un poco simple, pero esperamos que dé una
pista de algunas de las posibilidades que tiene usar hojas de estilo.
Sin embargo, no se debe suponer que siempre es mejor colocar el conte-
nido principal al inicio. La mayoría de los usuarios de lectores de pantalla es-
tán acostumbrados a tener la navegación al principio de la página. Es siempre
mejor proporcionar los medios para saltarse los elementos de navegación.
El vínculo que permite a los usuarios saltarse la barra de navegación
suele estar oculto a la vista y sólo se puede acceder a él con un lector de
pantalla. Ello nos lleva al asunto del uso de CSS oculto con fines de acce-
sibilidad.
Usando CSS oculto
He aquí un pequeño secreto: algunos sitios tienen un vínculo oculto al prin-

cipio de la página que dice «Saltar al contenido principal». Este vínculo no
se percibe cuando se accede al contenido de una página en forma visual,
pero se puede detectar si se accede al sitio web a través del teclado. Si no
lo ha hecho todavía, use la tecla de tabulación para navegar por los víncu-
los de una página web (o mediante las teclas «a» y «q» si usa Opera).
Cuando tabulamos al vínculo para saltarnos la navegación, el texto apare-
ce de repente, aunque antes era invisible.
El vínculo no tiene porqué estar oculto en absoluto. Podría haber sido
visible para cualquiera, pero por cuestiones estéticas en muchas ocasiones
25
WEB PARA TODOS.p65 25 12/11/2007, 12:17

interesa ocultarlo. El vínculo para saltarse la barra de navegación podría
parecer un poco fuera de lugar. A muchos diseñadores no les gusta la
forma en que este tipo de vínculo interfiere en sus diseños. Su reticencia a
usar vínculos para saltarse la barra de navegación es comprensible porque
de hecho alteran la apariencia de la maquetación. No obstante, ésta no es
una excusa suficientemente buena para eliminarlos completamente del di-
seño del sitio. Saltarse la barra de navegación es una característica útil
tanto para aquellos que usan lectores de pantalla como para aquellos que
dependen del teclado por otras razones, como tener algunos tipos de
discapacidad motórica. La idea de saltarse los elementos de navegación
es demasiado valiosa para ignorarla. Probablemente en un futuro este tipo
de solución será obsoleta, pero de momento es todavía una de las mejo-
res maneras de permitir a los usuarios saltar directamente al contenido
principal de una página web.
Para ocultar el salto de la barra de navegación, en primer lugar, el
texto y el fondo deben tener el mismo color. Si el fondo es blanco, el color
de la fuente que usemos será también blanco. En segundo lugar, para
hacer el vínculo visible cuando se tabule a él, proporcionaremos al vínculo
un estilo CSS propio que cambiará el color del fondo del vínculo. El mar-
cador HTML para el propio vínculo sería:
<div id="skipnav"><a href="#maincontent">Saltar

al contenido principal.</a></div>
Usando CSS, crearemos un estilo separado para el elemento de vín-

culo dentro del elemento div «skipnav». El estilo da al texto un color de
fuente que es igual que el color del fondo.
#skipnav a
{
color:#FFFFFF;
}
Además, si hay un estilo que resalta los vínculos poniéndoles un color

de fondo cuando se pasa sobre ellos con el ratón, o cuando se tabula a
ellos desde el teclado, necesitaremos crear un estilo adicional que cancele
26
WEB PARA TODOS.p65 26 12/11/2007, 12:17

este resalte cuando el ratón pase por encima (si bien el efecto se mantie-
ne para aquellos que navegan con teclado).
El resultado final es un vínculo que es invisible hasta que la gente utili-
za el teclado para acceder a él. Este vínculo es también completamente
accesible para los lectores de pantalla. El efecto de pasar por encima po-
dría haberse dejado intacto para el vínculo de saltar la barra de navega-
ción, pero entonces la gente lo hubiera encontrado con el ratón. Este des-
cubrimiento sería una sorpresa y podría confundir a los usuarios,
especialmente porque los usuarios de ratón generalmente no saben para
qué utilidad tiene un vínculo de saltar la navegación. Para ellos, parece
innecesario: pueden saltarse la navegación simplemente mirando más abajo.
No tienen que pinchar o hacer algo para obviarla.
Hay otros modos más complejos de ocultar texto usando CSS, pero
puede ser un reto hacer un trabajo aceptable para todos los navegadores.
Por ejemplo, usando display:none or visibility:hidden, el estilo
evitaría que el texto se mostrara en el navegador. Algunos lectores de panta-
lla también siguen las indicaciones de estos estilos, por lo que el contenido
queda oculto también para los usuarios de lectores de pantalla. Sin embar-
go, hay formas de trabajar este problema, como cambiar la visibilidad de las
propiedades mostradas del vínculo cuando se enfoca desde el teclado. He
aquí un ejemplo de un conjunto de estilos que causarían un efecto similar:
#skipnav a
{
display:none;
}
#skipnav a:active,
#skipnav a:focus
{
background-color:#ffffcc;
color:#000000;
display:inline;
}
En el ejemplo de arriba, el estilo display: none se aplica al vínculo

en su estado inactivo (cuando no se ha tabulado a él). Se aplica otro estilo
27
WEB PARA TODOS.p65 27 12/11/2007, 12:17

distinto display: inline cuando el vínculo está activo o enfocado. El
estilo «inline» provoca que el texto «aparezca» visualmente en el lugar en
que está. También se han aplicado un ligero color amarillo de fondo
(#ffffcc) y texto negro (#000000) al vínculo cuando es visible.
Si todo esto parece demasiado complejo, no es ningún error hacer el
vínculo visible a todo el mundo, incluso si altera en cierta forma la
maquetación de la página.
Dificultades de CSS
Revolver el contenido
Algunas de las fortalezas de las hojas de estilo son también sus debilida-
des. Por ejemplo, la posibilidad de cambiar el orden de lectura alineada de
su contenido sin cambiar la maquetación visual puede conducir a algunas
soluciones de accesibilidad maravillosas, pero también puede crear un te-
rrible desorden. Si, sin darnos cuenta, creamos un orden de lectura alinea-
da contrario al orden lógico de lectura de la página, habremos creado una
barrera de accesibilidad más que una solución de accesibilidad.
Los problemas con el orden de lectura alineada surgen principalmente
cuando se usan posicionamientos absolutos. En CSS esto se llama
«position: absolute». Con el posicionamiento absoluto, tendremos un con-
trol total y absoluto sobre la maquetación visual, así que podemos encon-
trarnos a nosotros mismos recolocando elementos posicionados de forma
absoluta hasta no tener ni idea de cuál es el orden de lectura alineada. Es
fácil encontrar salida a esto: simplemente hay que ir al código y mirar el
orden de lectura literal del contenido. Si ese orden tiene sentido, no se
necesita cambiar nada. Si no lo tiene, tendremos que mover algunas eti-
quetas hasta que el orden tenga sentido.
Aspectos de soporte del navegador
Cuando usemos CSS tendremos que aceptar el hecho de que en algunos

navegadores su contenido no se verá como nosotros (los diseñadores)
queremos. Internet Explorer y Netscape no intentaron soportar CSS hasta
la versión 4.0, por lo que todas las versiones anteriores no mostrarán los
28
WEB PARA TODOS.p65 28 12/11/2007, 12:17

estilos del autor. Sin embargo, esto no debe preocuparnos: en la medida
en que el contenido se muestre (degrade en terminología web) de forma
elegante seguirá siendo accesible. Uno de los elementos principales de la
elegancia de una degradación es la alineación del contenido.
Pautas aplicables
Se aplican a las Hojas de Estilo en Cascada las siguientes Pautas WCAG

1.0:
Prioridad 1:
• 6.1. Organice el documento de forma que pueda ser leído sin hoja
de estilo. Por ejemplo, cuando un documento HTML es interpretado
sin asociarlo a una hoja de estilo, tiene que ser posible leerlo.
Prioridad 2:
• 3.3. Utilice hojas de estilo para controlar la maquetación y la pre-
sentación.
• 3.4. Utilice unidades relativas en lugar de absolutas al especificar
los valores en los atributos de los marcadores de lenguaje y en los
valores de las propiedades de las hojas de estilo.
Prioridad 3:
• 14.3. Cree un estilo de presentación que sea coherente para todas
las páginas.
29
WEB PARA TODOS.p65 29 12/11/2007, 12:17

30
WEB PARA TODOS.p65 30 12/11/2007, 12:17

Creando imágenes accesibles
Introducción
Algunas personas piensan que los gráficos son malos para la accesibili-
dad. La verdad es que los gráficos pueden ser un gran beneficio para la
accesibilidad de una página web, porque proporcionan ilustraciones, iconos,
animaciones y otras claves visuales que facilitan la comprensión a quienes
ven la página. También, a menudo, olvidamos que cuando diseñamos para
personas con discapacidades, no estamos diseñando sólo para ciegos.
Debemos considerar discapacidades de todo tipo. Los gráficos pueden ser
especialmente útiles para individuos con ciertas dificultades para la lectura
o discapacidades del aprendizaje, como desórdenes por déficit de aten-
ción y discapacidades cognitivas.
Ilustraciones
Muchos conceptos se comunican con mayor efectividad con la incorpora-

ción de ilustraciones. Imaginemos tratar de aprender la anatomía humana
en un libro (o página web) sin ilustraciones. ¿Sería efectivo? Podemos ver
un ejemplo con la ilustración en la página siguiente de los músculos de la
mano.
Probablemente encontraremos difícil imaginar que una descripción úni-
camente textual pueda ser tan comprensible como un texto complementa-
do con ilustraciones. Las ilustraciones hacen el contenido más accesible.
Las ilustraciones pueden beneficiar no sólo a aquellos que ven, sino
que pueden ser especialmente beneficiosas para quienes tienen
discapacidades de aprendizaje o desordenes de lectura. Los desarrolladores
de materiales educativos deberían considerar especialmente el uso de ilus-
traciones para realzar la comprensión.
31
WEB PARA TODOS.p65 31 12/11/2007, 12:17

Imagen 5. Músculos de las manos.
Animaciones
Animaciones que distraen
Las animaciones raras veces se usan para realzar la accesibilidad del con-
tenido web. La mayoría de las veces son simplemente molestas. Los anun-
cios mediante «banners» se aprovechan de las cualidades de las anima-
ciones con el propósito de distraernos del tema principal del documento.
En las escuelas elementales es habitual usar animaciones atractivas que
no sirven para su propósito real, sin embargo quizá se puede argumentar
que las animaciones capturan la atención de los niños. Esto puede ser
cierto, pero la mayoría de estas animaciones en realidad distraen la aten-
ción de los niños del propósito real de la página.
Por ejemplo, una animación muy usada es la de un buzón de correos
que se abre y se cierra. La pregunta que debemos hacernos es si la ani-
mación es o no el contenido central de la página. ¿El propósito de la pági-
na es animar a la gente a enviar correos electrónicos? Es posible, pero
probablemente no. Este tipo de animación se encuentra muy a menudo en
la parte baja de una página cuyo propósito principal no tiene nada que ver
32
WEB PARA TODOS.p65 32 12/11/2007, 12:17

con enviar mensajes de correo electrónico a la persona que escribió la
página. La animación es una distracción, incluso cuando se usa en sitios
web para niños. Sería mejor eliminar esta distracción.
Animaciones que realzan la comprensión
Que los gráficos sean usados muy a menudo para distraer la visión no
quiere decir que no puedan servir a propósitos más útiles. Las animacio-
nes pueden ilustrar movimientos o procedimientos de una forma que sería
muy difícil de hacer con un texto. Supongamos, por ejemplo, que quere-
mos aprender los pasos de una danza. Podríamos tener una descripción
de los pasos en un texto y quizá esto funcionaría, pero para mucha gente
resultará más fácil ver una animación de cada uno de los pasos, para po-
der imitar los movimientos de la animación. En el caso de individuos con
discapacidades de lectura o cognitivas, el beneficio de las animaciones es
incluso más acentuado.
Naturalmente, la descripción textual sería necesaria para quienes son
ciegos, pero trataremos de este tema un poco más tarde.
Iconos
Muchos programas de ordenador usan iconos que o suplementan o reem-

plazan el texto de las barras de menú (pensemos en Microsoft Word, por
ejemplo, y los iconos para abrir archivo, imprimir , etc.). A conti-
nuación podemos ver un grupo de iconos de la barra de navegación de
Internet Explorer:
Imagen 6. Iconos de la barra de navegación de Internet Explorer.
Éste es un grupo similar de iconos del navegador web Opera:
Imagen 7. Iconos de la barra de navegación de Opera.
33
WEB PARA TODOS.p65 33 12/11/2007, 12:17

La utilidad de un icono depende de:
Que esté bien dibujado.

Que el concepto se transmita bien.
Que el público objetivo entienda bien el concepto.
Que el icono focalice bien en la idea que se intenta transmitir.
Los iconos necesitan ser simples y fácilmente entendibles. Su mérito

artístico es una cuestión secundaria, aunque los iconos que no son atracti-
vos pueden tener un efecto negativo en su comprensión.
Uno de los problemas con los iconos es que raramente son entendidos
de la misma forma por todos los que los ven. La mayoría de la gente
occidental asocia una flecha que apunta a la izquierda (como la que ve-
mos a continuación) con el concepto de regresar o ir hacia atrás, pero en
los idiomas donde se escribe de derecha a izquierda (por ejemplo, el ára-
be) lo opuesto puede ser cierto.
Imagen 8. Icono que representa «regresar» o «ir hacia atrás».
No hay iconos completamente compartidos por todas las culturas e

idiomas. Incluso dentro de la misma cultura e idioma, los iconos pueden
ser malinterpretados con bastante facilidad. Digamos que alguien decide
añadir un icono a una página para indicar que los ítems de un párrafo
concreto son sólo especulaciones y no deberían ser tenidos como verda-
des generalmente aceptadas. Para indicar esto, se coloca un signo de
interrogación, como el que aparece abajo, antes de cada uno de estos
tipos de párrafos.
Imagen 9. Icono que representa «ayuda».
34
WEB PARA TODOS.p65 34 12/11/2007, 12:17

¿Sabríamos inmediatamente qué quiere decir el signo de interroga-
ción? Probablemente no. No obstante, si explicásemos el significado del
signo de interrogación antes de usarlo, el icono sería útil. Se pueden usar
iconos y, de hecho, pueden incrementar la comprensión, pero sólo cuando
los usemos sensatamente.
Para la población general los iconos pueden ser útiles, pero no son
siempre absolutamente necesarios. No obstante, algunos individuos con
cierto tipo de discapacidades cognitivas deben ver los iconos para poder
comprender la materia. Algunos sitios se desarrollan específicamente
con esta población en mente. Incluso con las ilustraciones y los iconos,
estos individuos a menudo también requieren la asistencia de otra per-
sona al principio, pero pueden aprender la interfaz icónica con algo de
práctica.
Vídeo y multimedia
Aunque no entraremos en detalles sobre vídeo y multimedia ahora mismo,

debemos mencionar que estos elementos pueden usarse para realzar la
comprensión, de la misma forma que las ilustraciones, las animaciones y
los iconos. En lo que concierne al vídeo, aunque proporcionemos una
trascripción del texto (para los ciegos) y subtítulos (para los sordos), debe-
mos ser conscientes de que estos elementos realzan la comprensión más
que eliminan los problemas de accesibilidad. En lo que se refiere a otros
tipos de multimedia, como Flash, los aspectos de accesibilidad son un poco
más complejos, pero habitualmente es posible presentar el contenido de
forma que sea accesible a las personas con discapacidades.
Color y contraste
Color
La regla de accesibilidad establece que no debemos usar sólo el color

para transmitir significado. Esta frase es un poco confusa para algunos.
¿Qué quiere decir transmitir significado sólo con el color? Tomemos un
trozo del plano del Metro de Madrid (que, intencionadamente, hemos
35
WEB PARA TODOS.p65 35 12/11/2007, 12:17

escaneado en «escala de grises») para nuestra discusión sobre ceguera
de color:
Imagen 10. Trozo del plano del metro de Madrid, en blanco y negro.
Una persona que pudiera verlo en colores no tendría problemas en

distinguir entre la línea roja, la línea azul, la verde y etc. Una persona que
no puede ver bien los colores, debido a ceguera de color o baja visión,
probablemente no podrá distinguir las diferentes rutas fácilmente. Los cie-
gos no podrán verlas en absoluto. ¿Cómo sabríamos qué línea debemos
tomar para llegar desde Alonso Martínez a Callao?
Antes de que vayamos más lejos, deberíamos indicar que las personas
con ceguera de color pueden ver algunos colores (con la excepción de unos
pocos casos particulares). Así pues, el dibujo en escala de grises de arriba
no es representativo de la ceguera de color, es meramente un ejemplo de
una imagen en la cual se ha usado el color para transmitir significado. Cuan-
do se quita el color, las diferentes rutas son casi imposibles de distinguir.
Debemos verificar las páginas web asegurándonos de que no se pier-
de ninguno de los significados cuando quitamos los colores. Podemos ha-
cerlo imprimiendo la página en una impresora de blanco y negro, asegu-
rándonos de que en las preferencias la impresión incluye los colores de
36
WEB PARA TODOS.p65 36 12/11/2007, 12:17

fondo. Si trabajamos con el navegador Explorer, también podemos hacer
la verificación mediante la barra de herramientas de accesibilidad AIS,1
utilizando la opción «Escala de grises» del botón «Color».
Imagen 11. Opción «Escala de grises» en la barra de herramientas

de accesibilidad AIS.
Contraste
Tomemos como ejemplo la barra de navegación del sitio «Onobox». Aun-

que la que presentamos es una impresión de pantalla de la página en la
que el texto es considerablemente más pequeño y está un poco más
desenfocado en la página actual, notaremos que todo el texto es fácilmen-
te distinguible de los colores de fondo que lo rodean. Donde hay un color
de fondo más claro, hay un texto más oscuro. Donde hay un color de
fondo oscuro, el texto es claro. Las personas con baja visión no tendrán
dificultad en distinguir entre los diferentes niveles de contrastes del texto y
el fondo.
Si se hubiera elegido un color más claro para el fondo de las pestañas
de recursos, el texto sería difícil de leer.
Imagen 13.- Barra de navegación de Onobox, en escala de grises.
Tenemos que ser cuidadosos cuando elijamos los colores de fondo

para que no reduzcan el nivel de contraste hasta el punto de hacer el texto
ilegible.
1 Una versión en castellano de esta barra de herramientas de accesibilidad la podemos en-

contrar en el sitio de Teleservicios: http://www.technosite.es/software.asp.
37
WEB PARA TODOS.p65 37 12/11/2007, 12:17

Texto con gráficos
Pixelación de la ampliación de imágenes
A menudo, los gráficos contienen texto como parte de la imagen. Por ejem-
plo, el gráfico de más abajo contiene la palabra «Universidad». Algunos
usuarios con baja visión utilizan programas para ampliar los elementos en
su pantalla para poder verlos más fácilmente. Desafortunadamente, cuan-
do se amplía el texto de una imagen, a menudo se vuelve «pixelado» y de
más difícil lectura. Veamos un ejemplo:
Imagen 14. Imagen con la palabra «Universidad» aumentada, donde se aprecia

la deformación que provoca el efecto de «pixelado».
Al ampliar el gráfico, el texto es difícil de leer. Si hubiera sido usado

texto real, habría sido mucho más fácil de leer, como en el ejemplo si-
guiente:
Imagen 15. Palabra «Universidad» en un tamaño de grande usando texto real.
¿Significa esto que no deberíamos usar texto en los gráficos? En un

mundo perfecto quizá, pero con las actuales tecnologías resulta difícil con-
seguir ciertos diseños sin utilizar texto en los gráficos. Uno de los sitios
donde el texto dentro del gráfico puede estar justificado es en los logotipos
y las imágenes de marca. internet no ofrece una manera de transmitir el
texto de este tipo de imagen sin emplear un plug-in, como Flash o SVG.
De todas formas, si hay una manera de usar texto real, se debería hacer
así. Si se tiene que usar texto gráfico, debemos seguir algunas pautas:
Hacer el tamaño de letra tan grande como sea posible.

Usar letras de bloque simple cuando sea posible.
Utilizar un buen color de contraste entre el texto y el fondo.
38
WEB PARA TODOS.p65 38 12/11/2007, 12:17

Una buena herramienta para verificar el contraste de color puede encon-
trarse en http://www.nils.org.au/ais/web/resources/contrast_analyser/versions/
es/ donde se puede descargar un programa para instalación en local. Otra
buena herramienta, on line, para analizar el contraste de color (en inglés)
está disponible en: http://www.snook.ca/technical/colour_contrast/colour.html
El texto «pixelado» puede ser especialmente difícil de leer cuando hay
otros elementos en el fondo, como en esta ampliación de la cubierta del
libro «Diseño accesible de páginas web»:
Imagen 16. Cubierta del libro Diseño accesible de páginas web aumentada
desde una imagen muy pequeña.
Aunque el texto contrasta bastante bien con el fondo oscuro, el diseño

del fondo oscurece el texto un tanto.
Gráficos que pueden causar ataques epilépticos

Parpadeo y efecto estroboscópico2
No hay mucho que decir sobre este tema, pero es muy importante. El
punto esencial es:
Los efectos visuales de parpadeo o producidos como un efecto estrobos-

cópico pueden causar ataques epilépticos en algunos individuos.
2. Efecto que permite ver como lentos o inmóviles objetos que se mueven de forma rápida y
periódica, mediante su exposición intermitente.
39
WEB PARA TODOS.p65 39 12/11/2007, 12:17

Los ataques inducidos por el parpadeo o los efectos estroboscópicos
son conocidos como ataques «foto-epilépticos», y pueden ser peligrosos
para quien los sufra. No sea responsable de causarlos.
¿Cómo saber si un gráfico puede causar ataques?
No hay un umbral absoluto a partir del cual una inofensiva animación se

transforma en un peligroso gráfico que provoca ataques. Ahora bien, las
pautas utilizadas en Estados Unidos dentro de la Sección 508 del Acta de
Rehabilitación (que regula temas relativos a la accesibilidad en la web para
los productos y servicios que se quieran vender al gobierno federal) mar-
can el umbral entre los 2 y los 55 parpadeos por segundo. Esto NO quiere
decir que lo que se mueva en ese rango causará ataques, porque eso
haría in-usables todos los vídeos y animaciones. La cuestión no es el mo-
vimiento, sino el parpadeo y los efectos estroboscópicos.
La mayoría de los diseñadores no crean gráficos que se aproximen al
umbral de riesgo de provocar ataques, pero algunos desarrolladores
multimedia se aventuran en este territorio. Los diseñadores de Flash son
especialmente conocidos por crear animaciones «modernas» que parpa-
dean o producen efectos estroboscópicos en la pantalla. Tenemos que ser
cuidadosos al diseñar animaciones y procurar no causar ataques. Pode-
mos ver un ejemplo extremo en: http://www.webaim.org/media/graphics/
singleuse/images/seizure2.gif.
Texto alternativo (alt text) efectivo

Visión general
Ahora entramos en un apartado con el que mucha gente está al menos un

tanto familiarizada: el texto alternativo («alt text»). Por cierto, no existe
algo llamado etiqueta alt («alt tag»), aunque la gente a menudo se refiere
al texto alternativo por ese nombre. Para ser técnicamente correcto, es el
atributo alt de la etiqueta <img> (imagen). Su nombre no es tan importante
como su función, sin embargo, echemos una ojeada a lo que significa te-
ner un texto alternativo efectivo.
40
WEB PARA TODOS.p65 40 12/11/2007, 12:17

Pautas para el texto alternativo:
1. Asegúrese de que los textos alternativos comunican el propósito del

gráfico con precisión y sucintamente.
2. Proporcione texto alternativo vacío o nulo para los gráficos que no trans-
miten contenido.
3. Proporcione texto alternativo tanto para la imagen principal como para
cada punto sensible de los mapas de imagen.
4. No repita el texto alternativo de una imagen en el texto adyacente.
5. No coloque imágenes importantes en el fondo.
La importancia del texto alternativo
Uno de los mayores problemas de la accesibilidad en la web hoy día es la

carencia de texto alternativo para los gráficos y las imágenes. Las perso-
nas ciegas a menudo utilizan lectores de pantalla o dispositivos Braille que
leen el texto de la página para ellos. Cuando estas tecnologías de apoyo
atraviesan imágenes sin texto alternativo, son incapaces de comunicar su
significado.
Cuando un lector de pantalla atraviesa una imagen sin el atributo «alt»,
pueden ocurrir un par de cosas:
1. Puede, simplemente, saltar la imagen como si ésta no estuviera en la

página.
2. Puede encontrar algún texto que se asocie con la imagen, tal como el
nombre del archivo, y ser esto lo que lea.
El comportamiento exacto del lector de pantalla varía entre marcas de

lectores de pantalla y según las circunstancias de la página web en sí mis-
ma, pero de cualquier manera el resultado es indeseable. El usuario, o
bien pierde el contenido de la imagen completamente, o consigue un texto
que probablemente no tenga sentido.
41
WEB PARA TODOS.p65 41 12/11/2007, 12:17

Añadir texto alternativo
Echemos un vistazo a un ejemplo de imagen:
Imagen 17. Retrato de Silvia.
El código HTML para esta imagen es:
<img src="silvia1-8-web2.jpg" alt="Retrato de Silvia

Alvarez" width="311" height="350" />
Podemos escribir el código exactamente como lo hemos visto arriba

en un editor de texto o podemos usar la interfaz de una herramienta de
autor, tal como Dreamweaver o FrontPage, para realizar esto.
En Dreamweaver, el texto alternativo se añade desde la ventana de
Propiedades, tal como vemos en la imagen de abajo.
Imagen 18. Ventana de Propiedades de Dreamweaver, resaltando donde

se coloca el texto alternativo para las imágenes.
42
WEB PARA TODOS.p65 42 12/11/2007, 12:17

En FrontPage, podemos hacer doble clic sobre la imagen y aparecerá
el cuadro de diálogo Propiedades de la Imagen. Luego añadiremos el
texto alternativo en el campo Texto, en el apartado de Representaciones
alternativas.
Imagen 19. Ventana de Propiedades de FrontPage, resaltando donde

se coloca el texto alternativo para las imágenes.
Otros editores tienen funciones similares para añadir texto alternativo.

Consulte la documentación de su editor para ver las instrucciones sobre
cómo añadir el atributo «alt».
Ahora que tenemos una mejor idea de qué es un atributo «alt» y lo
simple que es añadirlo a una imagen, hablaremos sobre qué debe conte-
ner el atributo «alt».
Para qué usamos las imágenes

Las imágenes en los sitios web se usan principalmente con tres fines:
1. Para trasmitir contenido importante.

2. Para proporcionar un realce visual sin contenido real.
3. Para vincular a otras áreas del sitio.
43
WEB PARA TODOS.p65 43 12/11/2007, 12:17

El texto alternativo más apropiado para una imagen depende de para
qué se use ésta. De hecho, la misma imagen puede ser usada por diferen-
tes razones y bajo diferentes circunstancias y en cada ocasión esta ima-
gen podría tener diferente texto alternativo. Tenemos que grabar la siguiente
regla en la mente:
El texto alternativo más apropiado es aquel que comunica el propó-

sito del gráfico, no su apariencia.
Con esto en mente, la información más importante a trasmitir en el

texto alternativo de la imagen del ejemplo es que el usuario puede pinchar
en esta imagen para ir a otra área del sitio.
Comunicando el propósito de un gráfico
Imágenes que tienen contenido importante

Si la imagen del gráfico contiene información que es relevante para el con-
tenido del sitio, el atributo «alt» debería también proporcionar este conteni-
do, de manera coherente con el propósito de la imagen. Recordemos que
el propósito de la imagen no es necesariamente el mismo que la aparien-
cia de la imagen.
EJEMPLO 1
Supongamos un sitio dedicado al cine que usa imágenes para su navega-
ción principal, tal como muestra la imagen de abajo.
Imagen 20. Barra de navegación basada en imágenes.
44
WEB PARA TODOS.p65 44 12/11/2007, 12:17

Esta imagen aparece como un negativo de película de cine. El texto
de cada uno de los enlaces (que son imágenes) está en un color. Cuando
se selecciona el cuadro de enlace, se invierten los colores.
Imagen 21. Opción del menú destacada mediante inversión de colores.
Parte del texto está en mayúsculas y otra parte en minúsculas. Todos

estos detalles son importantes para el aspecto y la sensación del sitio web,
pero para aquellos que no pueden ver cómo es la apariencia del sitio, el
aspecto y sensación son irrelevantes. La cuestión más importante de estos
gráficos es que vinculan a otras áreas del sitio. Así pues, deberíamos pro-
porcionar un texto alternativo que transmita el hecho de que el usuario
puede pinchar esta imagen e ir a otra área del sitio. En este caso, el des-
tino del vínculo sería el apartado de Cine Clásico. El texto alternativo más
apropiado para esta imagen sería: «Cine Clásico».
En este caso, el texto alternativo coincide, al menos en parte, con el
texto que aparece en el gráfico. En muchos casos donde hay un texto en
la imagen, ésta es la mejor solución. No importa la descripción de la ima-
gen. Lo importante a saber sobre ella es su propósito y no su apariencia.
EJEMPLO 2
Tomaremos de nuevo la imagen del retrato de Silvia que aparece abajo:
Imagen 22. Retrato de Silvia.
45
WEB PARA TODOS.p65 45 12/11/2007, 12:17

Este gráfico puede ser usado de muchas formas diferentes y con mu-
chos propósitos distintos. He aquí unas pocas posibilidades:
En una escuela primaria la profesora crea un sitio web para explicar las
diferencias entre pintura, dibujo y escultura e incluye algunos ejemplos
diferentes de cada tipo de arte. En el texto de la página, describe las
diferencias entre estos tres medios y utiliza el retrato de Silvia como
uno de los cuatro ejemplos de pintura. Un posible texto alternativo en
este caso podría ser «Pintura de una joven dama». Esto es probable-
mente suficiente, ya que la profesora ha descrito adecuadamente que
el gráfico es un ejemplo de una pintura.
El miembro de una familia está recopilando una lista de la gente de su
familia, a través de los retratos de los individuos de ésta. Ya que todas
las imágenes son retratos, un texto alternativo apropiado podría ser
«Silvia Álvarez».
Un profesor de arte de enseñanza secundaria crea un sitio web para
mostrar diferentes tipos de pintura. Utiliza la pintura como ejemplo de
un retrato y explica en el texto de la página qué es un retrato. Un texto
alternativo apropiado en este caso sería «Retrato».
Un estudioso de historia del arte está creando un catálogo de retratos
de diferentes artistas. El texto alternativo debería incluir información re-
levante para la historia del arte, tal como el título del trabajo, el nombre
del artista, el medio utilizado y la fecha. El texto alternativo debería
decir «Silvia Álvarez, óleo sobre lienzo, de Paul Bohman, 2002».
Como podemos ver, no hay un texto alternativo concreto para una ima-
gen en particular, ello depende del contexto y del propósito de la imagen.
Esto es un criterio que debe decidir el autor de la página.
Precisión y brevedad
La alternativa textual para las imágenes debe ser tan precisa y tan sucinta
como sea posible. Hay que asegurar que el texto transmite toda la infor-
mación relevante para su propósito, pero sin cargar al usuario con un texto
alternativo excesivamente largo. Los lectores de pantalla y los dispositivos
Braille siempre leen el texto alternativo, lo cual puede hacer la imagen más
46
WEB PARA TODOS.p65 46 12/11/2007, 12:17

pesada en páginas bastante largas. Si necesitamos una descripción más
larga de la imagen deberíamos añadir el atributo para la descripción larga,
«longdesc», a la etiqueta imagen <img> (explicaremos este punto más
adelante).
Texto alternativo nulo

IMÁGENES DECORATIVAS
La web se ha convertido en un entorno gráfico en el cual los desarrolladores
a menudo añaden imágenes a sus páginas simplemente para realzar la
apariencia visual del sitio. Por ejemplo, la imagen de más abajo puede ser
utilizada para formar parte de un borde redondeado en una página.
Imagen 23. Imagen decorativa para hacer un borde redondeado a un fondo.
Imágenes de este tipo no proporcionan ningún contenido al usuario,

simplemente se utilizan con propósito meramente decorativo, por lo que
no tienen valor para aquellos que no pueden ver la página. El adecuado
marcado HTML para este tipo de imagen es atribuirle un texto alternativo
vacío o nulo, descrito como alt=””. Esto es: alt igual comillas comillas,
sin espacio entre ellas. El código para la imagen de este ejemplo podría
ser:
<img src=”esquina.gif” width=”84” height=”90” alt=”” />
Los lectores de pantalla ignorarán los gráficos con texto alternativo vacío,
que es lo que queremos en este caso. Podríamos preguntarnos por qué es
necesario especificar un texto alternativo nulo. ¿No tendría más sentido
simplemente dejar la imagen sin el atributo alt? Ésta es una buena pregun-
ta, pero la respuesta es que eliminar el texto alternativo es peor que poner
47
WEB PARA TODOS.p65 47 12/11/2007, 12:17

texto alternativo nulo, porque algunos lectores de pantalla leen el nombre
del archivo de la imagen, el cual puede ser confuso para el que lo oye.
Cuando añadimos texto alternativo nulo, los lectores de pantalla saltan so-
bre la imagen sin leer nada en absoluto.
Dreamweaver MX permite al autor crear texto alternativo nulo en el
cuadro de diálogo Propiedades:
Imagen 24. Opción «vacío» para la alternativa textual en la ventana

de propiedades de Dreamweaver con.
Desafortunadamente, muchos otros editores HTML no permiten crear

atributos alt vacíos mediante la interfaz gráfica, de manera que debere-
mos hacerlo directamente sobre el código fuente HTML. Para ello, tendre-
mos que localizar la imagen en el código y añadir alt=»» a la etiqueta de la
imagen.
IMÁGENES TRANSPARENTES Y ESPACIADORAS

Los desarrolladores a menudo utilizan imágenes transparentes y
espaciadoras para crear espacio entre los elementos de una página. Aun-
que los usuarios videntes no vean la imagen transparente, ésta puede ser
visible para los individuos que utilizan navegador de texto o lectores de
pantalla. Deberíamos añadir un texto alternativo vacío para todas las imá-
genes transparentes y espaciadoras.
IMÁGENES REDUNDANTES
Algunas veces, los desarrolladores web añaden a una imagen un texto
alternativo que es exactamente el mismo que el texto del contenido de la
48
WEB PARA TODOS.p65 48 12/11/2007, 12:17

página o que el texto colocado junto un gráfico, como el ejemplo de más
abajo:
Imagen 25. Imágenes complementadas con texto.
En casos como éste, se debe añadir un texto alternativo nulo, para

que los usuarios de lectores de pantalla no tengan que leer la misma infor-
mación dos veces. El lector de pantalla JAWS, para la imagen anterior,
dirá: «Imagen: ‘Enfermedades de la espalda’, Enfermedades de la espal-
da», cuando lea esta sección del contenido de la web, lo cual puede ser
confuso o al menos irritante.
Mapas de imagen
Mapas de imagen del lado del cliente
Todas las herramientas comunes de desarrollo web crean mapas de ima-

gen tanto del lado del cliente como del lado del servidor. Tal como sugiere
el nombre, los mapas de imagen del lado del servidor requieren un
«scripting» especial en el servidor, mientras que los del lado del cliente son
procesados solamente en el navegador del cliente. Los mapas de imagen
del lado del cliente pueden ser accesibles, mientras que los del lado del
servidor no pueden serlo.
Los mapas de imagen del lado del cliente requieren texto alternativo
para cada imagen y para cada uno de los puntos sensibles (hot spots).
Supongamos un ejemplo con la imagen de la página siguiente:
49
WEB PARA TODOS.p65 49 12/11/2007, 12:17

Imagen 26. Menú de navegación basado en un mapa de imagen.
Hay una sola imagen, pero tiene 5 puntos sensibles. Cada uno de és-
tos dirige a una diferente localización en el sitio web, así que es necesario
transmitir el propósito de navegación de cada uno de ellos. El texto alter-
nativo de estos puntos sensibles podría ser exactamente el mismo texto
que en la imagen: Inicio, Productos, Servicios, Contacto e Índice. Ahora
tenemos el texto alternativo para los puntos sensibles, pero, ¿qué hay de
la imagen en sí misma? Aparte de los puntos sensibles, esta imagen no
transmite una información significativa. El texto alternativo más apropiado
para la imagen completa sería un texto nulo. Éste sería el código para la
imagen y los puntos sensibles:
<img src=”imagemap.jpg” alt=”” width=”199”

height=”303” border=”0” usemap=”#Map”>
<map name=”Map”>
<area shape=”rect” coords=”7,9,191,54” href=”#maps”
alt=”Inicio”>
<area shape=”rect” coords=”7,68,191,114" href=”#maps”
alt=”Productos”>
<area shape=”rect” coords=”7,127,190,172”
href=”#maps” alt=”Servicios”>
<area shape=”rect” coords=”6,186,190,229"
href=”#maps” alt=”Contacto”>
<area shape=”rect” coords=”7,245,189,289"
href=”#maps” alt=”Índice”>
</map>
50
WEB PARA TODOS.p65 50 12/11/2007, 12:17

No todas las imágenes usadas como mapas de imagen tendrán un
texto alternativo nulo. Según el contexto, deberemos determinar el más
apropiado para cada situación (por ejemplo, para este caso podríamos
haber optado por dar un texto alternativo a la imagen completa del tipo
alt=»menú de navegación»).
Mapas de imagen del lado del servidor
No hay forma de hacer mapas de imagen del lado del servidor accesibles,
el consejo más simple es no usarlos. A algunos diseñadores les preocupa
que los mapas de imagen del lado del cliente no puedan crear las formas
de las figuras geométricas que quieren diseñar y saben que es posible
hacerlo con los mapas de imagen del lado del servidor. La verdad es que
los mapas de imagen del lado del cliente pueden dibujar cualquier forma,
siempre que el desarrollador tenga la paciencia de crear todas las coorde-
nadas.
Imágenes de fondo
Es imposible añadir texto alternativo a las imágenes de fondo, así que

deberíamos poner imágenes en el fondo sólo si no transmiten un conte-
nido importante.
Si la imagen del fondo contiene texto importante u otra información

visual clave, deberemos escribir de nuevo el HTML para que la imagen
esté en primer plano, de modo que se le pueda aplicar la propiedad de
texto alternativo.
Descripciones largas
Cuándo proporcionar descripciones largas
En algunos casos, una imagen es demasiado compleja para describirla en

unas pocas palabras. Gráficos y gráficas son los ejemplos principales de
tales imágenes. Aunque aquí no se ha mencionado ningún límite de longi-
51
WEB PARA TODOS.p65 51 12/11/2007, 12:17

tud para los textos en el atributo «alt», éste debería ser relativamente cor-
to. Es un abuso de este atributo escribir más que unas pocas palabras o, a
lo sumo, unas pocas frases cortas. La respuesta, por lo tanto, está en
proporcionar un texto breve en la descripción «alt» de la imagen y luego
proporcionar una descripción larga en otro sitio.
Métodos para proporcionar descripciones largas
Hay varias maneras de proporcionar una descripción larga para las imáge-
nes. Las distintas opciones se detallan a continuación, de la más a la me-
nos recomendable:
1. Proporcionar la descripción larga en el contexto del mismo documento.

2. Proporcionar un vínculo a una descripción larga mediante un vínculo de
texto normal.
3. Proporcionar un vínculo a una descripción larga mediante el atributo
<longdesc>.
4. Proporcionar un vínculo a una descripción larga mediante el vínculo
«d».
Quienes están familiarizados con las técnicas de accesibilidad quizá

se sorprendan al encontrar que el atributo <longdesc> y el vínculo «d»
estén al final de la lista. La razón para esto es que ambos métodos son
bastante oscuros. El atributo <longdesc> es invisible (e inaccesible para
algunos navegadores) para las personas que no estén usando un lector de
pantalla. El vínculo «d» no es convencional y puede ser confuso para las
personas que no están familiarizadas con su propósito. La forma más sim-
ple de hacer las descripciones largas accesibles es hacerlas obvias y dis-
ponibles para todo el mundo, tenga o no discapacidad.
Proporcionar la descripción larga en el contexto del propio

documento
Poniendo la descripción larga correctamente en el contexto del documento

donde el gráfico aparece, se pone al servicio de todos y no sólo para aque-
llos que tienen una discapacidad. Todos podrán leer la descripción larga y
52
WEB PARA TODOS.p65 52 12/11/2007, 12:17

se beneficiarán de ella. Éste es un ejemplo de cómo podemos hacerlo con
la imagen de un gráfico.
1.800.000
1.600.000
1.400.000
1.200.000
1.000.000
800.000
600.000
400.000
200.000
0
Chimpancés
«El gráfico de barras de arriba muestra la población de chim-

pancés de diferentes países de Asia. El número estimado de
chimpancés para cada país es el siguiente:
• China: 1.545.458
• Birmania: 945.421
• Laos: 545.845
• Vietnam: 785.752
• Bangladesh: 352.548
• Tailandia: 489.238
• Camboya: 885.465»
Imagen 27. Gráfico sobre datos de la población de chimpancés.
En el ejemplo anterior, los datos aparecen detrás de la imagen y son

accesibles para todos.
Proporcionar un vínculo a una descripción larga mediante

un vínculo de texto normal
La segunda mejor manera de proporcionar una descripción larga es tan

simple como un vínculo. No hay aquí un código sofisticado o una técnica
53
WEB PARA TODOS.p65 53 12/11/2007, 12:17

complicada. Sólo un vínculo a una descripción, tal como vemos en el si-
guiente ejemplo:
2.000.000
1.500.000
1.000.000
500.000
0
Chimpancés
«La descripción textual de este gráfico está disponible en otra página.»
Imagen 28. Gráfico de datos sobre chimpancés con un enlace

a su descripción textual.
La información también está disponible para todos mediante este mé-

todo, tan sólo tienen que pinchar sobre el vínculo para acceder a ella. El
vínculo es percibido por todos y pueden elegir si lo siguen o no.
El atributo <longdesc>
El atributo <longdesc>, que se puede añadir a la etiqueta <img> (ima-

gen), no hace más que proporcionar un vínculo a otra página donde está
disponible la descripción larga. Actúa de la misma forma que en el ejemplo
anterior, excepto que el vínculo es invisible para los lectores visuales.
Los que acceden visualmente perciben que no hay nada sobre el atri-
buto <longdesc>. Por lo que a ellos respecta, no está allí. Los únicos que
pueden acceder al atributo <longdesc> fácilmente son los que utilizan
lectores de pantalla modernos, ya que los lectores de pantalla más anti-
guos tampoco interpretan este atributo. Incluso entre los que utilizan la úl-
tima versión del lector de pantalla, hay muchos que no están familiarizados
con este atributo (porque no se usa frecuentemente) y no saben cómo
acceder a él, aunque su lector de pantalla sepa interpretarlo.
54
WEB PARA TODOS.p65 54 12/11/2007, 12:17

La aplicación del atributo <longdesc> beneficia por tanto a una pe-
queña audiencia, a pesar de que tanto las Pautas de WAI (WCAG) como
las de la Sección 508 del Acta de Rehabilitación de Estados Unidos la
recomienden.
Ésta es la forma de marcar el atributo <longdesc>:
<img src=”chimpgraph.gif” width=”494” height=”253”

alt=”Gráfica del número de chimpancés, por países,
en Asia.” longdesc=”chimpgraphdesc.htm”>
El vínculo «D»
Antes de que el atributo <longdesc> fuera interpretado por los lectores

de pantalla, un grupo de personas decidieron que necesitaban un método
equivalente que fuera soportado y, así, inventaron el vínculo «d». La letra
«d» significa «descripción». Este vínculo «d» no es más que un vínculo
normal a otra página en la que el texto del mismo es la letra «d». Pode-
mos ver un ejemplo de uso del vínculo «d»:
2.000.000
1.500.000
1.000.000
500.000
0
Chimpancés
Imagen 29. Gráfico sobre chimpancés con vínculo «d».
Podemos usar la letra en mayúsculas (D) o minúscula (d), no hay dife-

rencia. El vínculo «d» se coloca, normalmente, a la derecha, tras la ima-
gen. Esta técnica funciona con todos los navegadores y consigue el propó-
sito de acceder a la descripción larga, pero es menos elegante
(estéticamente hablando) que otros métodos. Algunos se confundirán al
ver un vínculo de una sola letra. Otros, simplemente, lo ignorarán. Pode-
55
WEB PARA TODOS.p65 55 12/11/2007, 12:17

mos usar este método, pero sólo si tenemos una buena razón para no
usar otros.
Ésta sería la forma de marcar el vínculo «d»:
<img src=”chimpgraph.gif” width=”494” height=”253”

alt=”Gráfica del número de chimpancés, por países,
en Asia.”><a href=”chimpgraphdesc.htm”
title=”Descripción gráfica del número de chimpancés
en Asia”>D</a>
Pautas aplicables
Se aplican a las imágenes las siguientes pautas WCAG 1.0:
Prioridad 1:
• 1.1 - Proporcione un texto equivalente para todo elemento no tex-
tual (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 anima-
dos), «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), ar-
chivos exclusivamente auditivos, banda sonora del vídeo y vídeos.
• 1.2 - Proporcione vínculos redundantes en formato texto para cada
zona activa de un mapa de imagen del servidor.
• 1.4 - Para toda presentación multimedia tempo dependiente (por
ejemplo, una película o animación) sincronice alternativas equiva-
lentes (por ejemplo, subtítulos o descripciones de la banda visual)
con la presentación.
• 2.1 - Asegúrese de que toda la información transmitida a través de
los colores también esté disponible sin color, por ejemplo mediante
el contexto o por marcadores.
• 6.2 - Asegúrese de que los equivalentes de un contenido dinámico
son actualizados cuando cambia el contenido dinámico.
• 7.1 - Hasta que las aplicaciones de usuario permitan controlarlo, evite
56
WEB PARA TODOS.p65 56 12/11/2007, 12:17

provocar destellos en la pantalla.
• 9.1 - Proporcione mapas de imagen controlados por el cliente en
lugar de por el servidor, excepto donde las zonas sensibles no pue-
dan ser definidas con una forma geométrica.
Prioridad 2:
• 2.2 - Asegúrese de que las combinaciones de los colores de fondo y
primer plano tengan el suficiente contraste para que sean percibidas
por personas con deficiencias de percepción de color o en pantallas
en blanco y negro [Prioridad 2 para las imágenes. Prioridad 3 para
los textos].
• 3.1 - Cuando exista un marcador apropiado, use marcadores en vez
de imágenes para transmitir la información.
• 7.2 - Hasta que las aplicaciones de usuario permitan controlarlo, evite
el parpadeo del contenido (por ejemplo, cambio de presentación en
periodos regulares, así como el encendido y apagado).
Prioridad 3:
• 1.5 - Hasta que las aplicaciones de usuario interpreten el texto equi-
valente para los vínculos de los mapas de imagen de cliente, pro-
porcione vínculos de texto redundantes para cada zona activa del
mapa de imagen de cliente.
• 9.5 - Proporcione atajos de teclado para los vínculos más importan-
tes (incluidos los de los mapas de imagen de cliente), los controles
de formulario y los grupos de controles de formulario.
• 14.2 - Complemente el texto con presentaciones gráficas o auditivas
cuando ello facilite la comprensión de la página.
57
WEB PARA TODOS.p65 57 12/11/2007, 12:17

58
WEB PARA TODOS.p65 58 12/11/2007, 12:17

Creando marcos (frames) accesibles
Introducción
• Proporcione títulos con sentido para los marcos en los que se descri-
ba el propósito del marco.
• Proporcione contenido con sentido para <noframes>.
Un grupo de marcos («frameset») es una página web que define una

colección de al menos otras dos páginas separadas, cuya combinación se
muestra en un mismo espacio visual. Los usuarios videntes habitualmente
perciben los grupos de marcos como una entidad cohesionada. Ellos pue-
den ojear el contenido de múltiples páginas, todas a la vez.
Aquellos que utilizan lectores de pantalla no pueden ojear rápidamente
los contenidos de múltiples páginas. Todo el contenido se percibe en forma
lineal, un marco cada vez. Los marcos no son inaccesibles a los modernos
lectores de pantalla, pero pueden desorientar.
El lector de pantalla JAWS habitualmente lee todos los marcos de un
grupo de marcos, casi como si pertenecieran a la misma página. Avisa al
usuario de que hay un grupo de marcos y luego continúa leyendo todas las
páginas del grupo de marcos. Existe un atajo de teclado que permite al
lector saltar rápidamente entre los marcos.
Otros programas manejan los marcos de forma distinta. Home Page
Reader no lee automáticamente las páginas de un grupo de marcos, sino
que presenta al usuario una lista de los marcos del grupo y le permite
elegir cuál de los marcos irá el primero.
59
WEB PARA TODOS.p65 59 12/11/2007, 12:17

Accesibilidad en los marcos (frames)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01

Frameset//EN" "http://www.w3.org/TR/html4/
frameset.dtd">
<HTML>
<HEAD>
<TITLE>Una página que contiene marcos.</TITLE>
</HEAD>
<FRAMESET cols="15%, 85%">
<FRAME src="menu.html" title="Menú de navegación."
name="menu">
<FRAME src="content1.html" title="Contenido
principal." name="contenido">
<NOFRAMES> <P> Este grupo de marcos contiene:
<UL> <LI><A href="menu.html">Página de navegación </
A></LI>
<LI><A href="content1.html">Contenido principal</A></
LI> </UL>
</NOFRAMES>
</FRAMESET>
</HTML>
Una de las cosas más importantes que podemos hacer para aumentar
la accesibilidad de los marcos es dar un título («title») a cada marco:
Cuando un usuario de lector de pantalla escucha la lista de los marcos,

le es útil saber el propósito de cada uno. Los títulos de los marcos
permiten a los desarrolladores web comunicar el propósito de cada
marco a los usuarios de lectores de pantalla.
Cuando no ponemos títulos a los marcos, los lectores de pantalla bus-
can otras fuentes de información, tales como el atributo «nombre»
(«name») de los marcos o la denominación del archivo. Algunas ve-
ces estas otras fuentes de información no son muy útiles. Si a un
marco se le da un atributo nombre o un nombre de archivo del tipo
«default3» (o algo por el estilo, nada descriptivo), no hay manera de
60
WEB PARA TODOS.p65 60 12/11/2007, 12:17

saber que contiene ese marco, de no ser mediante sistema de ensa-
yo y error.
Los mejores títulos para los marcos son breves y descriptivos. Los títu-
los apropiados en un grupo con dos marcos pueden ser «marco de
navegación» y «contenido principal».
Una página que usa marcos debería tener correctamente definido el

tipo de documento. El código de ejemplo, antes citado, muestra un
«DOCTYPE» (declaración de tipo de documento) para una página que
usa lenguaje de hipertexto HTML 4 y que contiene un grupo de marcos.
El contenido NOFRAMES debería estar siempre disponible si el usua-
rio no puede o elige no ver el contenido del marco. El contenido NOFRAMES
debería indicar qué contienen los marcos y proporcionar vínculos individua-
les a las páginas de los marcos, si es apropiado.
Pautas aplicables
Se aplican a los marcos (frames) las siguientes Pautas WCAG 1.0:
Prioridad 1:
• 12.1 -Titule cada marco para facilitar su identificación y navegación.
Prioridad 2:
• 12.2 - Describa el propósito de los marcos y cómo éstos se relacio-
nan entre sí, si no resulta obvio solamente con el título del marco.
61
WEB PARA TODOS.p65 61 12/11/2007, 12:17

62
WEB PARA TODOS.p65 62 12/11/2007, 12:17

Creando tablas accesibles
Tablas de maquetación
Introducción
Si como alumnos tenemos que consultar un sitio web para saber dónde va
a tener lugar la clase 205 de biología, iremos a una página web que tiene
esta información en formato tabla. Aunque algo abigarrada, no será com-
plicado averiguar la información deseada (se celebrará en el aula 6).
Código
de Matricu- Matricu- Hora
Depar- Número lación lación Número Hora de de fina-
tamento de clase Sección máxima actual de aula Días comienzo zación Profesor
BIO 100 1 15 13 5 Lun, Mié, 10:00 11:00 Martínez
Vie
100 1 15 7 5 Mar, Jue 11:00 12:30 López
205 1 15 9 6 Mar, Jue 9:00 10:30 Martínez
315 1 12 3 6 Lun, Mié, 13:00 14:00 López

Vie
BUS 150 1 15 15 13 Lun, Mié, 9:00 10:00 García
Vie
210 1 10 9 13 Lun, Mié, 8:00 9:00 Pérez
Vie
Supongamos por un momento que somos usuarios de un lector de

pantalla. Iremos a la página web que tiene esta información, y esto es lo
que oiremos:
Tabla con 10 columnas y siete filas. Código de Departamento, Número

de clase, Sección, Matriculación máxima, Matriculación actual, Número
63
WEB PARA TODOS.p65 63 12/11/2007, 12:17

de aula, Días, Hora de comienzo, Hora de finalización, Profesor, BIO,
100, 1, 15, 13, 5, Lun, Mié, Vie, 10:00, 11:00, Martínez, 100, 1, 15, 7, 5,
Mar, Jue, 11:00, 12:30, López, 205, 1, 15, 9, 6, Mar, Jue, 9:00, 10:30,
Martínez, 315, 1, 12, 3, 6, Lun, Mié, Vie, 13:00, 14:00, López, BUS, 150,
1, 15, 15, 13, Lun, Mié, Vie, 9:00, 10:00, García, 210, 1, 10, 9, 13, Lun,
Mié, Vie, 8:00, 9:00, Pérez.
Después de escuchar esta información, ¿tendremos alguna idea acer-

ca de dónde se supone que se impartirá Biología 205? Probablemente no.
Cuando escuchamos tablas todas de seguido, sin usar el modo de lectura
de tablas en un lector de pantalla, este tipo de información puede ser bas-
tante confusa. Incluso si usa el modo de lectura de tabla, seguirá siendo
muy confuso si la tabla no está marcada apropiadamente.
Usos de las tablas
Hay dos usos básicos de las tablas en la web: como tablas de datos y
como tablas de maquetación. El uso original de las tablas HTML era para
datos. Una tabla es una tabla de datos cuando hay encabezamiento de
filas, encabezamiento de columnas o ambos. Por ejemplo, he aquí una
tabla de datos simple:
Hijas de Sonia
Nombre Edad Cumpleaños
María 5 5 de abril
Isabel 8 14 de enero
En la práctica, las tablas se usan de forma mayoritaria para maquetar

páginas. Las tablas de maquetación no tienen encabezamientos lógicos de
los que se pueda trazar un mapa con la información de las celdas de la
tabla. He aquí un ejemplo simple de tabla de maquetación:
64
WEB PARA TODOS.p65 64 12/11/2007, 12:17

Imagen 30. Contenido web «Pensamientos de Benjamin Franklin»
maquetado mediante tablas.
Algunos defensores de la accesibilidad dicen que el uso de tablas para

maquetar es una mala idea, y que es preferible usar técnicas de
maquetación CSS. Tienen razón en lo que dicen, pero, siendo honesto, el
uso de tablas para maquetar no es lo peor que se puede hacer en térmi-
nos de accesibilidad. Las personas con todo tipo de discapacidades pue-
den acceder fácilmente a las tablas, siempre que se hayan diseñado te-
niendo en mente la accesibilidad.
Alineación de contenidos
La alineación de contenidos se refiere al orden del contenido cuando se

elimina todo el formato. Si eliminamos la tabla de las citas de Benjamín
Franklin, vemos en la siguiente página el orden de alineación de la lectura
que se obtiene:
65
WEB PARA TODOS.p65 65 12/11/2007, 12:17

(Esta imagen deberá llevar texto alternativo)
Pensamientos de Benjamín Franklin
Lea éstos en segundo lugar:
«Bendito quien no espera nada, porque nunca quedará decepcionado».
«Cuando hayas acabado de cambiar, estarás acabado».
Lea éstos primero:
«Aquellos que aman profundamente nunca envejecen; puede que mueran a una
edad avanzada, pero morirán jóvenes.»
«No escondas tus talentos. Fueron hechos para usarlos. ¿Qué sería de la aguja
del reloj de sol cuando está en la sombra?»
Imagen 31. Contenido alineado de la maquetación con tablas anterior.
Como vemos, las citas del lado derecho se han leído antes que las
citas del lado izquierdo. En el orden de alineación de lectura de esta tabla,
hemos terminado leyendo las frases en el orden equivocado. El resultado
es probablemente el contrario al orden en que pensamos que se leería el
contenido. Cuando miramos la tabla, la revisamos visualmente de izquier-
da a derecha, sin embargo, el lado derecho es leído antes que el izquier-
do. Esto es debido a las filas y columnas cruzadas que componen esta
tabla. La tabla no es tan sencilla cuando miramos el código.
Muchos de los sitios de internet usan tablas para maquetar, y muchos
usan filas y columnas cruzadas para conseguir efectos de formato. El re-
sultado final es que el orden de lectura alineada puede no ser el mismo
que el orden de lectura visual. Esto puede llevar a confusión a aquellos
que acceden al orden de lectura alineada, como las personas que utilizan
lectores de pantalla.
66
WEB PARA TODOS.p65 66 12/11/2007, 12:17

Los lectores de pantalla ignoran esencialmente el hecho de que el
contenido está dentro de una tabla. El lector de pantalla simplemente lee
el contenido en el orden literal que aparece en el código. Si el orden
literal del contenido del código es lógico, el orden de lectura alineada
será lógico.
Los lectores de pantalla leen el contenido de las páginas web como

si no fueran HTML. Lo leen todo en el orden en que aparece en el
código.
Éste es un concepto muy importante. Vamos a ver otro caso en el que

esta circunstancia se convierte en una cuestión que hay que tener en cuen-
ta. He aquí una tabla creada con fines de efectos visuales:
Imagen 32- Contenido sobre el uso del inodoro, maquetado con tablas.
El lector vidente leerá: «Los aseos del sótano deben limpiarse tirando
de la cadena hacia arriba».
El usuario de lector de pantalla oirá (o notará en el Braille) «Los aseos
hacia arriba del sótano limpiarse tirando de la cadena deben».
¿Por qué existe esta diferencia entre el orden visual y el orden del
lector de pantalla? Para responder a esta cuestión, tenemos que mirar la
estructura de la tabla. He aquí la misma tabla, a la que se han añadido los
67
WEB PARA TODOS.p65 67 12/11/2007, 12:17

bordes. También se ha añadido un número a cada celda para indicar el
orden en que las leerá el lector de pantalla:
Imagen 33. Orden de lectura de la tabla utilizada para maquetar los contenidos.
He aquí el código de marcadores de la tabla original. Observemos el

orden del texto:
<table border="0" style="/*/*/background-

color:#ffffcc">
<tr>
<td><span style="/*/*/font-size:120%;font-
weight:bold;">Los aseos</span></td>
<td> </td>
<td> </td>
weight:bold;">hacia arriba.</span></td>
</tr>
<tr>
<td valign= "top"><span style="/*/*/font-
size:120%;font-weight:bold;">del sótano</span></td>
<td><img src="toilet.jpg" alt="inodoro" width="118"
height="144"></td>
68
WEB PARA TODOS.p65 68 12/11/2007, 12:17

weight:bold; ">limpiarse tirando de la cadena</
span></td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> <div style="/*/*/text-align:right"><span
style="font-size:120%;font-weight:bold;">deben</
span></div></td>
<td> </td>
<td> </td>
</tr>
</table>
Revisión de la buena alineación de la tabla

Una forma de revisar el orden de lectura de las celdas de la tabla es usar
el navegador Opera (www.opera.com), ya que éste permite al usuario
deshabilitar las tablas completamente.
En Opera 7, se selecciona Modo de usuario>Deshabilitar tablas.
Imagen 34. Opción para deshabilitar las tablas en el navegador Opera 7.
69
WEB PARA TODOS.p65 69 12/11/2007, 12:17

Una vez hecho esto, se puede activar o desactivar el Modo de Usuario
con un clic del ratón.
También nos daremos cuenta de que el modo de usuario deshabilita
los colores y estilos. Esto se debe a que está usando su hoja de estilo, con
lo cual, si nosotros no tenemos especificada una, no habrá ninguna hoja
de estilo. Cuando eliminamos las tablas y estilos de una página, nos hare-
mos una idea adecuada de qué aspecto tiene la página para los usuarios
de lectores de pantalla.
Etiquetas de encabezado
Cuando utilizamos la etiqueta de encabezado de tabla (<th>), la mayoría

de navegadores hacen que el texto aparezca en negrita y centrado, lo cual
puede producir un bonito efecto visual, pero la etiqueta <th> sólo debería
usarse en tablas de datos. No la utilice para maquetar tablas porque pue-
de confundir a los usuarios de lectores de pantalla, haciéndoles pensar que
están en una tabla de datos cuando no lo están.
Usemos tamaño proporcional en lugar de tamaños absolutos
Los documentos de internet y las páginas web son distintos de sus corres-
pondientes impresos en papel. Las páginas impresas tienen un tamaño
absoluto, que no se puede cambiar. Las páginas web no. Podemos exten-
der nuestro navegador hacia arriba, abajo, a la derecha, a la izquierda y
conseguir casi cualquier tamaño. La maquetación web debe ser fluida para
encajar con la naturaleza fluida del navegador web.
Una tabla de maquetación con un ancho prefijado no varía su tamaño
para encajar con el área de visión de la ventana del navegador. Si el área
de visión es muy pequeña, exigirá al usuario que se desplace demasiadas
veces de un lado para otro utilizando la barra de desplazamiento (scroll
bar). Puede ser bastante molesto para las personas con baja visión que
deben usar un programa especial para ampliar el área de visión. Este pro-
grama, que suele ser denominado programa de magnificación, puede am-
pliar los contenidos de la pantalla mucho más de lo que puede hacerlo el
sistema operativo. Algunas personas tienen una ampliación tan alta que
70
WEB PARA TODOS.p65 70 12/11/2007, 12:17

sólo pueden ver una o dos palabras a la vez. Más habitualmente, los usua-
rios fijarán una ampliación de entre un 200% y un 500%.
Imagen 35. Opción para ampliar la visualización de contenidos en Opera 7.
Los desarrolladores pueden usar el navegador Opera para simular los

efectos del uso de un magnificador de pantalla. Opera puede aumentar el
tamaño de las páginas web hasta un 1.000%. La opción de magnificación
se encuentra en la esquina superior derecha de la ventana del documento.
Cuando ampliemos las páginas, nos daremos cuenta de que aumenta
significativamente la cantidad de deslizamiento horizontal. Esto no puede
evitar, pero podemos reducir su impacto especificando unidades relativas,
tales como porcentajes, en el maquetado de las tablas en lugar de unida-
des prefijadas como píxeles.
Usemos la configuración de tabla lo más simple posible
Algunos diseñadores se vuelven locos con las tablas de maquetación. Crean

todo tipo de filas y columnas innecesarias, usando filas y columnas cruza-
das de todas las formas posibles, hasta que la tabla no parece en absoluto
una tabla. Todo ello resultará invisible para el usuario vidente si el borde de
la tabla se coloca en cero, pero los usuarios ciegos lo «verán». Los lecto-
res de pantalla les informarán del número de filas y columnas de la tabla.
71
WEB PARA TODOS.p65 71 12/11/2007, 12:17

Cuando intenten navegar de un área a otra de la tabla, se desorientarán.
La regla principal aquí es «lo más simple es lo mejor».
Tablas de datos
Marcado de tablas de datos
Las tablas de datos son diferentes de las tablas de maquetación. La finali-

dad de las tablas de datos es presentar información en una parrilla, o ma-
triz, y tener columnas o filas que muestren el significado de la información
en la parrilla.
Cuando los lectores de pantalla leen linealmente las tablas de datos,
especialmente las grandes, es fácil que los usuarios se pierdan.
Para que las tablas de datos sean accesibles, deben tener el marca-
dor apropiado en HTML. Cuando éste está colocado en su sitio, los usua-
rios de lectores de pantalla pueden navegar por la tabla de datos de celda
en celda, y el lector les dirá la fila y columna en que están situados.
Designemos los encabezados de fila y columna usando

la etiqueta <th>
El primer paso para crear una tabla de datos accesible es designar los
encabezados de fila y/o columna. Esto es fácil de hacer. La mayoría de las
herramientas de autor proporcionan un método para convertir las celdas
de datos en celdas de encabezado. En el marcado, la etiqueta <td> se usa
para las celdas de la tabla de datos y la etiqueta <th> se usa para las
celdas de encabezado de la tabla. Volviendo a nuestro ejemplo de tabla
«Hijas de Sonia», los encabezados de columna para esta tabla son Nom-
bre, Edad y Fecha de Nacimiento. Los encabezados de fila son María e
Isabel.
Hijas de Sonia
Nombre Edad Cumpleaños
María 5 5 de abril
72
WEB PARA TODOS.p65 72 12/11/2007, 12:17

Asociemos las celdas de datos con los encabezados
adecuados
Ahora que hemos creado los encabezados, necesitamos asociar las cel-
das con los encabezados adecuados. Hay dos maneras de asociar las
celdas de datos con sus encabezados.
Scope (alcance)
Deberíamos usar el atributo «scope» en las tablas simples de datos, como
la del ejemplo. He aquí el marcador para la tabla, usando el atributo
«scope»:
<table border="1" align="center">

<caption>Hijas de Sonia</caption>
<tr>
<th scope="col">Nombre</th>
<th scope="col">Edad</th>
<th scope="col">Fecha de nacimiento</th>
</tr>
<tr>
<th scope="row"">María</th>
<td>5</td>
<td>5 de abril</td>
</tr>
<tr>
<th scope="row">Isabel</th>
<td>8</td>
<td>14 de enero</td>
</tr>
</table>
La etiqueta «scope» le dice al navegador y al lector de pantalla que

todo lo que está debajo en la columna se refiere al encabezado que hay
arriba, y que todo lo que hay a la derecha del encabezado de fila se refiere
a ese encabezado. Es un concepto sencillo.
73
WEB PARA TODOS.p65 73 12/11/2007, 12:17

Encabezados («headers») e «id»
Otra forma de conseguir el mismo objetivo es usar los atributos "headers"
e "id". Este método NO se recomienda para tablas sencillas como la del
primer ejemplo. El método "headers" e "id" sólo debe usarse cuando
en la tabla hay más de un nivel lógico y cuando es necesario vincular a una
celda de datos más de dos encabezados. Si ampliamos el ejemplo inicial,
podemos crear una tabla que encaje con este criterio. En la tabla de aba-
jo, los datos tienen tres encabezados cada uno, por lo cual es apropiado
usar una técnica más compleja.
Hijas de Sonia
Nombre Edad Fecha de nacimiento
María 5 5 de abril
Por nacimiento
Por matrimonio Juana 12 12 de febrero
El código de marcado HTML es:
<table border="1">
<tr>
<td> </td>
<th id="nombre">Nombre</th>
<th id="edad">Edad</th>
<th id="nacio">Fecha de nacimiento</th>
</tr>
<tr>
<th rowspan="2" id="nacimiento">Por nacimiento</th>
<th id="maria">María</th>
<td headers="nacimiento maria edad">5</td>
<td headers="nacimiento maria nacio">5 de abril</td>
</tr>
<tr>
74
WEB PARA TODOS.p65 74 12/11/2007, 12:17

<th id="isabel">Isabel</th>
<td headers="nacimiento isabel edad ">8</td>
<td headers="nacimiento isabel nacio"> 14 de enero</
td>
</tr>
<tr>
<th id="matrimonio">Por matrimonio</th>
<th id="juana">Juana</th>
<td headers ="matrimonio juana edad ">12</td>
<td headers="matrimonio juana nacio ">12 de
febrero</td>
</tr>
</table>
De nuevo, debemos remarcar que este método es más complejo.

Debería usarse con tablas de naturaleza más complicada, en las que el
atributo «scope» no funciona.
Otra advertencia: el lector de pantalla JAWS, que es el más usado, no
maneja bien las filas y columnas cruzadas. Si es posible, evitemos las
tablas de datos complejas o representemos los datos de la forma menos
compleja posible, preferiblemente con no más de dos encabezados para
cada celda de datos.
Usemos tamaño proporcional en lugar de tamaños absolutos
La regla aplicable a tablas para maquetar también se aplica a las tablas de

datos. Dejemos que la ventana del navegador determine el ancho de la
tabla cuando sea posible, para reducir el desplazamiento horizontal que
requieren las personas con baja visión.
Proporcionemos nombres o títulos a las tablas de datos

usando la etiqueta <caption>
Las tablas deben tener algún tipo de título o «caption». Esto se hace co-
rrectamente usando la etiqueta «caption» justo después de la etiqueta de
apertura <table>, de la siguiente manera:
75
WEB PARA TODOS.p65 75 12/11/2007, 12:17

<table border="1" align="center">
No es absolutamente necesario tener etiquetas «caption» en todas las

tablas de datos para favorecer la accesibilidad, pero sigue siendo una bue-
na práctica.
Proporcionemos resúmenes usando el atributo <summary>
Esta pauta no es un requerimiento necesario para las tablas sencillas, pero

puede incrementar la comprensión de las tablas más complejas para las
personas que utilizan lectores de pantalla. Una tabla compleja de datos
sobre el clima debería tener un resumen que diga:
Se ha observado una tendencia al caldeamiento en el Valle de

Escombreras, con temperaturas que superan en cerca de 5 grados las
medias históricas de los últimos 2 meses, con un máximo de diferencia
de temperatura de 25 grados sobre la media.
Esta descripción debería resaltar los elementos importantes de la tabla

y ayudar al usuario sobre qué buscar en los datos.
Algunos defensores de la accesibilidad insisten en que todas las tablas
tengan resúmenes, incluyendo las tablas de datos. La verdad es que este
esfuerzo no merece la pena. A los lectores de pantalla no les es necesario
escuchar las palabras «Esta tabla sólo se usa para maquetar» al principio
de cada tabla de un sitio. Algunos sitios usan tantas tablas que este texto
añadido sólo provoca confusión e incrementa el tiempo que se tarda en
escuchar la página. Sería mejor usar los resúmenes de tabla cuando cum-
plen la función para la que fueron diseñados: proporcionar breves resúme-
nes de datos complejos.
Evitemos las tablas con más de dos niveles de encabezado de

fila y/o columna
Hay métodos de marcado de tablas de mayor complejidad que los ex-

puestos aquí. Algunos lectores de pantalla pueden leer estos marcadores y
76
WEB PARA TODOS.p65 76 12/11/2007, 12:17

mostrar el contenido de forma adecuada. La triste verdad es que el lector
de pantalla más popular, JAWS, no puede hacerlo tan fácilmente. Si es
posible, utilicemos tablas simples, unidimensionales o bidimensionales sin
filas o columnas cruzadas. Es la apuesta más segura.
Pautas aplicables
Se aplican a las tablas las siguientes pautas WCAG 1.0:
Prioridad 1:
• 5.1 - En las tablas de datos, identifique los encabezamientos de fila
y columna.
• 5.2 - Para las tablas de datos que tienen dos o más niveles lógicos
de encabezamientos de fila o columna, utilice marcadores para aso-
ciar las celdas de encabezamiento y las celdas de datos.
Prioridad 2:
• 5.3 - No utilice tablas para maquetar, a menos que la tabla tenga
sentido cuando se alinee. Por otro lado, si la tabla no tiene sentido,
proporcione una alternativa equivalente (la cual debe ser una ver-
sión alineada).
• 5.4 - Si se utiliza una tabla para maquetar, no utilice marcadores
estructurales para realizar un efecto visual de formato.
Prioridad 3:
• 5.5 - Proporcione resúmenes de las tablas.
• 5.6 - Proporcione abreviaturas para las etiquetas de encabezamiento.
• 10.3 - Hasta que las aplicaciones de usuario (incluidas las ayudas
técnicas) interpreten correctamente los textos contiguos, proporcio-
ne un texto lineal alternativo (en la página actual o en alguna otra)
para todas las tablas que maquetan texto en paralelo, en columnas
de palabras.
77
WEB PARA TODOS.p65 77 12/11/2007, 12:17

78
WEB PARA TODOS.p65 78 12/11/2007, 12:17

Creando formularios accesibles
Accesibilidad general de los formularios

Introducción
Hay dos medios principales en la web para recibir información de un sitio web:
el correo electrónico y los formularios. El correo electrónico no suele tener
ningún gran problema de accesibilidad, y permitir a los usuarios de un sitio
web acceder a una dirección de correo electrónico de contacto es una gran
herramienta para la usabilidad y accesibilidad. Los formularios proporcionan, a
menudo, un medio de comunicación mejor. Pueden ser enviados fácilmente y
no requieren de un programa de correo o un servicio web. Con los formularios
también se puede obtener la información específica que se necesita. Pero los
formularios también suponen algunos problemas de accesibilidad.
Cuando hablamos de la accesibilidad de los formularios, solemos refe-
rirnos a su accesibilidad para los lectores de pantalla y las personas con
discapacidades visuales. Las personas con otros tipos de discapacidades
suelen verse menos afectadas por los formularios defectuosos que care-
cen de algunas de las características de accesibilidad de HTML. Debemos
puntualizar, no obstante, que todo el mundo resulta beneficiado si los for-
mularios están bien organizados, especialmente las personas con
discapacidades cognitivas. La maquetación visual puede ser importante para
los usuarios videntes. Cuanta menos explicación precise el formulario, mejor.
Sin embargo, el objetivo de este ejercicio es básicamente la elaboración
de un formulario que pueda ser leído por un lector de pantalla.
Asegurémonos de que los formularios son accesibles desde el

teclado, lógicos y fáciles de usar
Muchos usuarios tienen que utilizar el teclado para navegar y usar la web.
Hay que asegurarse de que los formularios de un sitio web pueden
79
WEB PARA TODOS.p65 79 12/11/2007, 12:17

cumplimentarse usando sólo el teclado. Sólo unas pocas cosas pueden
hacer que un formulario no sea usable desde el teclado, la más común de
las cuales es JavaScript. Por ello, hemos de tener cuidado cuando use-
mos JavaScript para manipular los datos de los formularios, ubicar el foco,
cambiar elementos del formulario o mostrar formularios. Cada una de es-
tas acciones puede convertir al formulario en imposible de cumplimentar o
comprender sólo con el uso del teclado. Hay que revisar siempre la acce-
sibilidad de los formularios del sitio web.
Un uso de los formularios que se ha hecho común en la web son los
menús desplegables para navegar. Ello permite situar muchos ítems de
navegación en un espacio realmente pequeño de la página. El usuario puede
seleccionar un ítem del menú desplegable que se corresponda con un lu-
gar de la web. En tanto que esos formularios no causan por sí mismos
problemas de accesibilidad, sí que interfiere en la misma si se utiliza
JavaScript para presentar los datos del formulario cuando el usuario selec-
ciona el menú desplegable. Estos formularios utilizan a menudo el evento
de JavaScript onChange, lo que significa que cuando los ítems del formu-
lario se cambian, el navegador tiene instrucciones de ir automáticamente a
una página web. Este evento onChange se dispara cuando el usuario suel-
ta el botón del ratón después de seleccionar el ítem del menú desplegable
que desea. No obstante, si el usuario no está utilizando un ratón, tiene que
usar las flechas del teclado para navegar por los ítems del menú desple-
gable. Cada vez que avanza o retrocede por los ítems del menú, el
JavaScript detecta un evento onChange, que conduce al navegador a una
nueva página. La solución a este problema es no usar JavaScript para
cambiar automáticamente la ubicación del navegador web. En lugar de
eso, permitamos que el usuario seleccione el ítem del menú y seleccione
entonces un botón adyacente de formulario para ir a la página correspon-
diente al ítem que ha seleccionado.
Los formularios deberían también estar organizados de una manera
lógica. Coloquemos la etiqueta del formulario (por ejemplo, Primer Nom-
bre) adyacente al elemento de formulario (por ejemplo, cuadro de texto,
cuadro de verificación, botón de radio, lista de menú). Proporcionemos
instrucciones buenas y claras sobre qué información se desea. Si se re-
quiere rellenar obligatoriamente algún elemento de formulario, indiquémos-
lo así. Asegurémonos de que el orden en que se accede a los elementos
80
WEB PARA TODOS.p65 80 12/11/2007, 12:17

del formulario es lógico y sencillo. Esto puede ser problemático en ocasio-
nes si se usan tablas para controlar la maquetación de los ítems del formu-
lario. Para revisar el orden de alineación de los ítems de la página, pode-
mos utilizar el navegador de Opera como muestra la imagen.
Imagen 36. Opción para visualizar en orden de los controles del formulario
con el navegador Opera 7.
Otra herramienta que nos puede servir para revisar el orden de alinea-
ción de los ítems de la página es la barra de accesibilidad de NILS, que se
ejecuta con el navegador IExplorer de Microsoft (se puede encontrar en
castellano en: http://www.technosite.es/software.asp).
Imagen 37. Barra de herramientas de accesibilidad de AIS para IExplorer.
Ahora que hemos aprendido cómo incrementar la accesibilidad de los

formularios para todos los usuarios, vamos a aprender técnicas específi-
cas que ayudarán a los usuarios de lectores de pantalla.
81
WEB PARA TODOS.p65 81 12/11/2007, 12:17

Accesibilidad del lector de pantalla al formulario
Conceptos clave
• Coloque las etiquetas de formulario al lado de sus correspondientes

controles de formulario.
• Proporcione marcadores para las etiquetas del formulario utilizando la
etiqueta de HTML <label>.
• Agrupe los elementos del formulario relacionados entre sí usando la
etiqueta de HTML <fieldset>.
• Proporcione un título o leyenda para cada grupo de elementos relacio-
nados mediante la etiqueta de HTML <legend>.
• Agrupe los botones de radio en una etiqueta de HTML <fieldset> y
proporcione una <label> para cada cuadro de verificación.
• Agrupe los cuadros de verificación en una etiqueta de HTML
<fieldset> y proporcione a cada cuadro de verificación una <label>.
• Proporcione siempre un botón para mostrar los formularios. No utilice
JavaScript para mostrarlos automáticamente.
Proporcionemos una maquetación lógica del formulario
Una de las formas más habituales de navegar por un formulario es usando

la tecla de tabulación (). Una persona rellena un campo, pulsa el tabulador,
rellena el siguiente campo y así hasta que llega al final del formulario. Para
los usuarios videntes es fácil, porque las etiquetas están colocadas de for-
ma que parecen estar vinculadas a sus controles correspondientes. Sin
embargo, a una persona ciega que usa un lector de pantalla la maquetación
visual no le será de mucha ayuda. Tiene que haber en el marcador alguna
manera de vincular la etiqueta con su control. Veamos un ejemplo para
demostrar la posible confusión que puede producirse con un formulario
que esté escasamente marcado y mal organizado.
Imagen 38. Formulario maquetado sobre una tabla.
82
WEB PARA TODOS.p65 82 12/11/2007, 12:17

Visualmente la tabla tiene al menos algún sentido (aunque produzca
un poco de confusión). Para la mayoría, una persona que vea puede ima-
ginarse que la etiqueta de Nombre se corresponde con el control que está
debajo de ella, y que la etiqueta de Correo Electrónico va con el control
que está a su derecha. ¿Qué ocurre entonces cuando eliminamos los colo-
res y el formato? Un lector de pantalla leerá la tabla de arriba en el si-
guiente orden:
Imagen 39. Orden de lectura de los contenidos del formulario maquetado

con una tabla.
Aunque un lector de pantalla no mostrará los colores, se han dejado

con el fin de poder comparar. Si confrontamos el orden de lectura con el
orden visual de la tabla de arriba, observaremos que las etiquetas y los
elementos de formulario no encajan muy bien. Es muy probable que las
personas que usen un lector de pantalla se queden muy confundidas y
cumplimenten el formulario de manera incorrecta, colocando la informa-
ción en los lugares equivocados.
Usando las etiquetas de formulario adecuadamente
Hay dos cosas que podemos hacer para arreglar la tabla anterior:
• Poner las etiquetas adyacentes a sus controles.

• Usar marcadores de HTML para asociar explícitamente los controles
con sus etiquetas.
Una forma de arreglar los problemas de accesibilidad de la tabla de

arriba sería reducir la tabla a dos columnas, colocando las etiquetas direc-
tamente a la izquierda de los elementos del formulario, como vemos en la
imagen siguiente, y añadirles las etiquetas de HTML correspondientes (más
adelante veremos el uso de marcadores HTML).
83
WEB PARA TODOS.p65 83 12/11/2007, 12:17

Imagen 40. Formulario en tabla con las etiquetas de los controles
relacionados por proximidad.
Creando etiquetas para los elementos de formulario utilizando

la etiqueta de HTML <label>
Cuando un usuario de lector de pantalla está navegando por los elementos
de formulario de una página web, el programa lector de pantalla identifica-
rá el tipo de elemento de formulario que está seleccionado en ese mo-
mento y proporcionará los medios para completar, seleccionar, des-selec-
cionar o presentar ese elemento de formulario. Sin embargo, cuando se
navega por el formulario, a menudo no hay indicaciones sobre qué infor-
mación se desea en un ítem particular del formulario. Por ejemplo, si el
usuario navega a un cuadro de texto usando el tabulador, puede no haber
ninguna indicación sobre si es en ese cuadro de texto donde se debe po-
ner el nombre, la dirección, el teléfono, un mensaje, un número o cualquier
otra cosa. Esto puede solucionarse asociando las etiquetas de formulario
con los ítems de formulario de la página. La etiqueta debería colocarse
siempre abarcando al propio ítem de formulario para que se asocien implí-
citamente. Más adelante daremos detalles específicos sobre cómo asociar
etiquetas con ítem de formulario. Cuando un lector de pantalla accede a
un ítem de formulario que tiene asociada una etiqueta, leerá la etiqueta e
indicará qué tipo de ítem de formulario es (por ejemplo, «Cuadro de texto,
nombre», o «Cuadro de verificación, edad»). Todos los elementos del for-
mulario necesitan etiquetas, excepto los botones, ya que el lector de pan-
talla puede leer el texto que esté en el botón (por ejemplo, «Botón de
presentación»).
84
WEB PARA TODOS.p65 84 12/11/2007, 12:17

Elementos de formulario agrupados usando la etiqueta de HTML
<fieldset>
Cuando tenemos numerosos elementos asociados a un formulario, pue-
den ser agrupados mediante la etiqueta <fieldset>. Cada «juego de
campos» debería tener una etiqueta. La leyenda es el texto que describe
el grupo de ítem de formulario asociado. En el ejemplo anterior, están
definidos «juegos de campos» para «Tipo de ordenador» y «Velocidad de
conexión». En Internet Explorer y en Netscape 6 se ven los «juegos de
campos» con un cuadro alrededor de los campos que lo componen.
El «juego de campos» está definido por el borde que rodea los tres
cuadros de verificación y sus etiquetas adyacentes. Las leyendas de los
«juegos de campos» son las palabras Tipo de ordenador y Velocidad de
conexión. El «juego de campos» es importante porque sin él, si el lector
de pantalla accediera al cuadro de verificación, leería algo así como: «vein-
tiocho punto ocho. No verificado». Aunque es valioso, no proporciona des-
cripción acerca de para qué es el dato. ¿Se refiere 28,8 a la velocidad de
internet, a la edad, la altura, el coeficiente intelectual o a otra cosa? Si
colocamos el «juego de campos» en su lugar, el lector de pantalla leería
algo como: «Velocidad de internet: veintiocho punto ocho. No verificado».
Los «juegos de campos» deben usarse cuando hay un grupo de cuadros
de verificación o de botones de radio. También pueden usarse con otros
elementos de formulario que estén asociados.
Incluso si el lector de pantalla es incapaz de leer las etiquetas de HTML
<label>,<fieldset> y <legend> que se han añadido (como sucede
con algunos lectores de pantalla antiguos), la tabla mejorada anterior está
organizada de tal manera que hace posible entender qué etiqueta va con
qué controles.
Asociación de etiquetas con elementos de formulario

Muestra del código
He aquí el marcador de HTML del formulario anterior. Prestaremos espe-
cial atención a las etiquetas de HTML de <label>, <id>, <fieldset>
y <legend>. Más adelante veremos cómo puede hacerse accesible cada
tipo de control de formulario.
85
WEB PARA TODOS.p65 85 12/11/2007, 12:17

<form method="post" action="">
<p><label for="nombre">Nombre
<input id="nombre" type="text" name="text1"
size="12" />
</label></p>
<p><label for="apellidos">Apellidos
<input id="apellidos" type="text" name="text2"
size="12" />
</label></p>
<p><label for="contrasena">Contraseña
<input id="contrasena" type="text" name="text3"
size="1" />
</label></p>
<p><label for="telefono">Teléfono
<input id="telefono" type="text" name="text4"
size="12" />
</label></p>
<p><label for="pais">País
<input id="pais" type="text" name="text5" size="12"
/>
</label></p>
<fieldset>
<legend>Tipo de ordenador</legend>
<label for="pc">
<input id="pc" type="radio" name="radiobutton1"
value="radiobutton" />
PC</label>
<label for="mac">
<input id="mac" type="radio" name="radiobutton1"
Mac</label>
</fieldset>
<fieldset>
<legend>Velocidad de conexión </legend>
<label for="28k">
<input id="28k" type="radio" name="radiobutton2"
86
WEB PARA TODOS.p65 86 12/11/2007, 12:17

28.8k</label>
<label for="56k">
<input id="56k" type="radio" name="radiobutton2"
56k </label>
<label for="sup">
<input id="sup" type="radio" name="radiobutton2"
<abr title="Superior">Sup.</abr></label>
</fieldset>
</form>
El formato de visualización en pantalla lo podremos controlar con la

hoja de estilo que apliquemos, mediante la definición de estilos para cada
uno de los elementos que hemos utilizado en este sencillo ejemplo.
Vamos a ver ahora los elementos de formulario específicos a los que
se han añadido características de accesibilidad.
Controles de formulario accesibles
He aquí algunos ejemplos de controles de formulario a los que se han

añadido características de accesibilidad:
Tipo de control: INPUT (entrada)
Nombre:
Éste es el marcado HTML:
<label for="nombre">Nombre
<input id="nombre" type="text" name="textfield" />
</label>
87
WEB PARA TODOS.p65 87 12/11/2007, 12:17

Tipo de control: TEXTAREA (área de texto)
Explica tus motivos:
Éste es el marcado HTML:
<label for="motivos">Explica tus motivos:

<textarea id="motivos" cols="25" rows="5"
name="textfield2"></textarea></label>
Tipo de control: CHECKBOXES (cuadros de verificación)
Elija un color: Azul Verde Amarillo
Éste es el marcado de HTML
<fieldset>
<legend>Elija un color:</legend>
<label for="azul">
<input id="azul" type="checkbox" name="checkbox1"
value="checkbox" />Azul</label>
<label for="verde">
<input id="verde" type="checkbox" name="checkbox1"
value="checkbox" />Verde</label>
<label for="amarillo">
88
WEB PARA TODOS.p65 88 12/11/2007, 12:17

<input id="amarillo" type="checkbox" name="checkbox1"
value="checkbox" />Amarillo</label>
</fieldset>
Tipo de control: RADIO BUTTONS (botones de radio)
Elija un coche: Seat Toledo Renault Espace Peugeot 607
Éste es el marcado de HTML:
<fieldset>
<legend>Elija un coche:</legend>
<label for="seat">
<input id="seat" type="radiobutton" name="radiobutton1"
value="seat" />Seat Toledo</label>
<label for="reanult">
<input id="renault" type="radiobutton"
name="radiobutton1" value="renault" />Renault
Espace</label>
<label for="peugeot">
<input id="peugeot" type="radiobutton"
name="radiobutton1" value="peugeot" />Peugeot 607</
label>
</fieldset>
Tipo de control: SELECT (seleccionar)
¿Cuál es su ciudad favorita?: Amsterdam
Éste es el marcado de HTML:
<label for="favorita">¿Cuál es tu ciudad favorita?

<select id="favorita" name="select1">
<option value="1">Amsterdam</option>
<option value="2">Nueva York</option>
89
WEB PARA TODOS.p65 89 12/11/2007, 12:17

<option value="3">Interlaken</option>
<option value="4">Moscú</option>
<option value="5">Dresden</option>
<option value="6">Salt Lake City</option>
<option value="7">Montreal</option>
<option value="8">Buenos Aires</option>
<option value="9">Asunción</option>
<option value="10">Hong Kong</option>
<option value="11">Tokyo</option>
<option value="12">Nueva Dehli</option>
</select>
</label>
Para mejorar todavía más la accesibilidad de esta lista, podríamos

añadir etiquetas de HTML <optgroup>", para agrupar la información. Hay
que tener en cuenta, de forma general, que los lectores de pantalla no
soportan las etiquetas de HTML <optgroup>.
Éste es el marcado de HTML, con «optgroup»:
<label for="favorita2">¿Cuál es tu ciudad favorita?

<select id="favorita2" name="favorita2">
<optgroup label="Europa">
<option value="1">Amsterdam</option>
<option value="3">Interlaken</option>
<option value="4">Moscú</option>
<option value="5">Dresden</option>
</optgroup>
<optgroup label="Norte America">
<option value="2">Nueva York</option>
<option value="6">Salt Lake City</option>
<option value="7">Montreal</option>
</optgroup>
<optgroup label="Sur America">
<option value="8">Buenos Aires</option>
<option value="9">Asunción</option>
</optgroup>
90
WEB PARA TODOS.p65 90 12/11/2007, 12:17

<optgroup label="Asia">
<option value="10">Hong Kong</option>
<option value="11">Tokyo</option>
<option value="12">Nueva Dehli</option>
</optgroup>
</select>
</label>
Tipo de control: BUTTON (botón)
No hay etiquetas de HTML especiales para los botones. Éstos serán acce-
sibles en tanto se use el botón estándar.
Enviar Reiniciar
<input type="submit" name="Submit" value="Enviar" />

<input type="reset" name="Submit2" value="Reiniciar" />
Tipo de control: IMAGE BUTTON (botón de imagen)
Si usamos un botón gráfico en vez de un botón estándar, tendremos que

incluir un texto alternativo adecuado.
Imagen 41. Botón de imagen utilizado para «enviar» un formulario.
<input type="image" alt="Enviar" border="0"

name="campoimagen" src="graphics/submit.gif" />
91
WEB PARA TODOS.p65 91 12/11/2007, 12:17

Tipo de control: Menús de salto de JAVASCRIPT
Estos menús no se consideran accesibles desde el teclado, puesto que no

es posible desplazarse por la lista sin seleccionar una de las opciones.
Sería mejor proporcionar un botón de remisión separado de la lista de
opciones.
Usando Dreamweaver y FrontPage

Usando Dreamweaver para crear formularios accesibles
Dreamweaver MX proporciona una opción que permite aplicar todas las

características de accesibilidad de los formularios. Utilicemos el menú In-
sertar > Formularios > Juego de campos para insertar un «juego de
campos». Dreamweaver MX sugerirá que pongamos la leyenda del «juego
de campos».
Imagen 42. Opción «etiqueta» para un juego de campos en Dreamweaver.
Cuando se activan las características de accesibilidad para los formu-

larios en las Preferencias (Edición > Preferencias > Accesibilidad >
Objetos de formulario), Dreamweaver sugerirá que coloquemos una eti-
queta de formulario para cada ítem que añadamos (Insertar > Formula-
rio > …). También podemos elegir si colocamos la etiqueta antes o des-
pués del ítem de formulario.
Si el formulario ya está creado, se pueden asociar fácilmente las eti-
quetas con los ítems de formulario. Simplemente hay que seleccionar el
ítem de formulario y su etiqueta adyacente. A continuación seleccionare-
mos Insertar > Formulario > Etiqueta. Dreamweaver MX asociará de
forma automática la etiqueta con el ítem de formulario insertando la eti-
queta de HTML <label> correcta. Para añadir etiquetas en otros lugares de
92
WEB PARA TODOS.p65 92 12/11/2007, 12:17

la página, seleccionaremos Insertar > Formulario > Etiqueta y
Dreamweaver insertará la etiqueta de HTML <label>, aunque hay que aso-
ciar manualmente la etiqueta con un elemento de formulario. Éstas y otras
técnicas de accesibilidad más avanzadas tienen que llevarse a cabo en la
ventana de Vista de Código de Dreamweaver.
Usando FrontPage para crear formularios accesibles
Microsoft FrontPage también soporta la funcionalidad de la etiqueta de for-

mulario <label>. Para asociar las etiquetas con los ítems de formulario,
primero hay que crear el formulario y hacerlo que trabaje y se muestre
como queramos. Asegurémonos de colocar las etiquetas de texto adya-
centes al ítem de formulario al que estarán asociadas. Seleccionemos tan-
to la etiqueta como el ítem de formulario y seleccionemos Insertar > For-
mulario > Etiqueta. Actualmente FrontPage permite añadir «juego de
campos» (que denomina «Cuadro de grupo») y las leyendas que lo acom-
pañan (Insertar > Formulario > Cuadro de grupo).
Imagen 43. Opción «Cuadro de grupo» en FrontPage.
93
WEB PARA TODOS.p65 93 12/11/2007, 12:17

Pautas aplicables
Se aplican a los formularios las siguientes Pautas WCAG 1.0:
Prioridad 2:
• 10.2 - Hasta que las aplicaciones de usuario soporten explícitamen-
te la asociación entre control de formulario y etiqueta, para todos los
controles de formularios con etiquetas asociadas implícitamente,
asegúrese de que la etiqueta está colocada adecuadamente.
• 12.4 - Asocie explícitamente las etiquetas con sus controles.
Prioridad 3:
• 10.4 - Hasta que las aplicaciones de usuario manejen correctamen-
te los controles vacíos, incluya caracteres por defecto en los cua-
dros de edición y áreas de texto.
94
WEB PARA TODOS.p65 94 12/11/2007, 12:17

Creando JavaScript accesible
¿Qué es JavaScript?
Se puede definir mejor diciendo qué NO es JavaScript. En primer lugar, no

es HTML. JavaScript no utiliza etiquetas HTML ni se atiene a ninguna de
las reglas generales del lenguaje HTML. Sin embargo, se puede usar
JavaScript con HTML en una página web. En segundo lugar, JavaScript no
es Java. Aunque a menudo se llama Java al JavaScript, ambas cosas no
son lo mismo. Java fue desarrollado por Sun Microsystems y es un lengua-
je de programación por sí mismo. Por otra parte, JavaScript, fue desarro-
llado por Netscape Corporation. Aunque es similar a Java en la sintaxis,
JavaScript no es un lenguaje de programación por sí mismo; para que
funcione debe formar parte de una página web que utilice un navegador
que comprenda el lenguaje JavaScript. El lenguaje de programación Java
de Sun puede ser aplicado en una página como programa de construc-
ción, en tanto que los «guiones» (scripts) de JavaScript dependen del or-
denador del cliente (del visitante) para funcionar.
Repetimos que JavaScript no es HTML ni una versión de éste. HTML
es leído y procesado por el navegador web. Cuando el navegador lee el
código JavaScript en el documento de HTML, procesa el código y muestra
el resultado en la página web. El ordenador que esté leyendo un JavaScript
tiene que tener un intérprete de JavaScript, un programa que interprete el
«guión» (script) y lo ejecute, y este intérprete debe estar disponible.
HTML, por sí solo, crea páginas muy estáticas. Hay poca interacción
del usuario y escaso contenido dinámico en una página en particular. HTML
no tiene la capacidad de ejecutar operaciones matemáticas, acumular va-
riables o mostrar contenido dinámico. JavaScript permite que se pueda
realizar las mencionadas acciones. Aunque muchos programas de Script
del lado del servidor (como PHP, JPS, ASP o ColdFusion) tienen la capa-
95
WEB PARA TODOS.p65 95 12/11/2007, 12:17

cidad de ejecutar esas funciones, JavaScript puede ejecutarlas desde el
navegador del lado del cliente. Puesto que JavaScript es un lenguaje de
«guión» (script), permite a los desarrolladores implementar pequeñas apli-
caciones en sus páginas. Estos programas pueden hacer desde cosas tan
simples como cambiar un gráfico cuando se le pasa el ratón por encima,
hasta algunas tan complejas como ejecutar fórmulas matemáticas avanza-
das que introduzca el usuario.
Cuestiones de accesibilidad de JavaScript
JavaScript permite que los desarrolladores añadan una mayor interacción,

procesamiento de información y control del contenido de la web. No obs-
tante, JavaScript introduce también algunas cuestiones de accesibilidad.
Éstas incluyen:
• Navegación. Imposibilidad o dificultad para navegar por medio del te-

clado o tecnologías de apoyo.
• Contenido oculto. Presentación de contenido o funcionalidades que
no son accesibles para las tecnologías de apoyo.
• Control por el usuario. Falta de control por el usuario de los cambios
automáticos de contenido.
• Confusión/desorientación. Alteración o des-habilitación del funciona-
miento normal de la aplicación de usuario (navegador) o aparición de
eventos de los que el usuario no es consciente.
Una página web que contenga JavaScript será plenamente accesible

si la funcionalidad del script1 es independiente del dispositivo (no requiere
sólo un ratón o sólo un teclado) y la información (el contenido) está dispo-
nible para las tecnologías de apoyo. Desafortunadamente, no hay una so-
lución que pueda ser fácilmente aplicada para resolver todos los proble-
mas de accesibilidad asociados a JavaScript. La única forma de asegurar
la accesibilidad de JavaScript es evaluar cada script de forma indepen-
1. Utilizamos, a partir de este momento, el término inglés «script» sin referir su traducción al
castellano (guión), ya que es un término muy común entre los desarrolladores y diseñadores de
páginas web y no queremos enmarañar demasiado este documento.
96
WEB PARA TODOS.p65 96 12/11/2007, 12:17

diente y concebir una solución especial para el problema de accesibilidad
que presenta. Los desarrolladores tienen que familiarizarse con las cues-
tiones que se refieren a la accesibilidad de JavaScript y aplicar técnicas
para conseguir uno o ambos de los siguientes puntos:
1. Asegurarse de que JavaScript es directamente accesible.

2. Proporcionar una alternativa accesible sin JavaScript.
JavaScript que no choca con la accesibilidad

Sólo porque se utilice JavaScript en una página, no significa que ésta sea
inaccesible. En muchos casos, JavaScript puede usarse para incrementar
la accesibilidad. Podemos proporcionar al usuario información adicional,
advertencias o instrucciones a través de avisos de JavaScript. Por ejem-
plo, según las pautas de la ya mencionada Sección 508 de Estados Uni-
dos, tenemos que avisar al usuario cuando solicitemos una respuesta del
mismo y darle tiempo suficiente para que indique si necesita más tiempo.
Esta funcionalidad sería muy difícil sólo con HTML.
En ocasiones, se utiliza JavaScript para crear elementos visuales de
interfaz que no afectan a la accesibilidad. JavaScript se usa comúnmente
para renovar las imágenes, donde una imagen reemplaza a otra cuando
se pone el ratón encima; por ejemplo, cuando cambia un ítem de navega-
ción para mostrar una sombra, un brillo o una iluminación cuando se pone
el ratón sobre él.
Estos usos de JavaScript no necesitan incorporar características adi-
cionales de accesibilidad, ya que este «scripting»2 no muestra contenido
importante ni introduce funcionalidades.
Hacer JavaScript accesible implica tener en consideración los siguien-
tes aspectos. Trataremos cada uno de ellos más adelante:
• Cuando se utilicen manejadores de evento, usemos sólo aquellos que

sean independientes del dispositivo (por ejemplo, que no exijamos que
sólo se use el ratón).
2. Usamos el término inglés «scripting», de difícil traducción al castellano en este contexto,

para referirnos a la forma de redactar el guión o script.
97
WEB PARA TODOS.p65 97 12/11/2007, 12:17

• El contenido y funcionalidad proporcionados a través de los «scripting»
deben ser accesibles para las tecnologías de apoyo.
• Las páginas web que utilicen «scripting» tienen que ser completamente
navegables usando el teclado.
• JavaScript no debe modificar o anular la funcionalidad normal del
navegador de forma que cause confusión.
• Cuando JavaScript no pueda hacerse accesible originalmente, se tiene
que proporcionar una alternativa accesible.
Comparación de las pautas JavaScript
La Sección 508 del Acta de Rehabilitación de Estados Unidos y las Pautas

de Accesibilidad al Contenido Web (WCAG) 1.0 de W3C tratan sobre la
accesibilidad de los elementos de «scripting». Exigen que la funcionalidad
y los contenidos de los scripts sean accesibles para las tecnologías de
apoyo, como los lectores de pantalla. Además, se debe dar a los usuarios
el control sobre los cambios de contenido tempo-dependiente. No obstan-
te, hay diferencias entre ambas normas técnicas de accesibilidad. WCAG
exige que el contenido y la funcionalidad sean accesibles cuando se
desactiven los «scripting» y que se avise al usuario si JavaScript cambia la
apariencia o funcionalidad de la ventana del navegador, en tanto que la
Sección 508 sólo exige que se haga el «scripting» accesible o que se pro-
vea una alternativa accesible.
Evaluación de la confianza de JavaScript
Tal y como hemos expuesto más arriba, nuestras páginas web deberían ser
totalmente accesibles si se deshabilita JavaScript. Éste es uno de los requeri-
mientos de las Pautas de Accesibilidad al Contenido en la Web de W3C/WAI
con Prioridad 1. La Sección 508 no exige que la página funcione si el JavaScript
está deshabilitado, pero exige que el script sea por sí mismo originalmente
accesible. Este documento enseñará estrategias para hacer los script accesi-
bles desde el inicio y asume que si nosotros, como desarrolladores, queremos
alcanzar un alto grado de accesibilidad para cumplir las Pautas de Accesibili-
dad al Contenido en la Web, también evaluaremos las páginas para asegurar-
nos de que funcionan igualmente con JavaScript deshabilitado.
98
WEB PARA TODOS.p65 98 12/11/2007, 12:17

Manejadores de evento
Visión general
JavaScript puede ser procesado utilizando elementos y manejadores de

evento <script>. El elemento <script> puede contener el código
JavaScript directamente:
<script type="text/javascript">
<!—
function doit();
—>
</script>
O puede abrir un archivo externo JavaScript (.js):
<script type="text/javascript" src="scripts.js">
El elemento <script> se procesa cuando la página se ha cargado y

no requiere intervención del usuario. Los contenidos y funcionalidad del
script procesado con el elemento <script> tienen que ser directamente ac-
cesibles o se tiene que proporcionar una alternativa accesible del conteni-
do y la funcionalidad.
Los manejadores de evento acompañan al código HTML existente y
son disparados por el navegador o la aplicación de usuario, como cuando
se carga la página, cuando el usuario pincha con el ratón o cuando son las
ocho de la mañana. Algunos manejadores de evento dependen del uso del
ratón o del teclado. Éstos son llamados manejadores de evento depen-
dientes del dispositivo. Otros manejadores de evento son independientes
del dispositivo y son disparados tanto por el ratón como por el teclado o
por otros medios. La utilización de manejadores de evento dependientes
del dispositivo puede provocar que el contenido sea inaccesible para aque-
llos que no sean capaces de manejar el dispositivo requerido por ese
manejador de evento específico.
En este documento, revisaremos los manejadores de evento y cómo
pueden afectar a la accesibilidad. También aprenderemos las múltiples for-
mas en las que el contenido y funcionalidad producidos por JavaScript
99
WEB PARA TODOS.p65 99 12/11/2007, 12:17

pueden interferir con la accesibilidad. Finalmente, vamos a revisar los
manejadores de evento, dependientes del dispositivo e independientes del
dispositivo, y proporcionaremos técnicas para asegurar que son accesibles.
onMouseOver y onMouseOut
El manejador de evento onMouseOver se dispara cuando el cursor del

ratón («mouse») se coloca sobre un ítem. Como su nombre indica, exige
el uso de un ratón, por lo tanto es un manejador de evento dependiente
del dispositivo y puede provocar cuestiones de inaccesibilidad. onMouseOver
y su acompañante, onMouseOut, pueden ser usados siempre que cual-
quier contenido o funcionalidad importantes esté también disponible sin usar
el ratón.
onFocus y onBlur
Estos manejadores de evento se usan habitualmente con elementos de

formulario, como campos de texto, botones de radio y botones de envío.
onFocus se dispara cuando se coloca el cursor sobre o en un elemento de
formulario específico. onBlur se dispara cuando el cursor abandona un ele-
mento de formulario.
Estos dos manejadores de evento son independientes del dispositivo,
lo que significa que pueden ejecutarse con el ratón, el teclado u otra tec-
nología de apoyo. Deben analizarse las acciones que se llevan a cabo
como resultado de la actuación de estos manejadores de evento para ver
si causan problemas de accesibilidad. Habitualmente, estos eventos no
provocan cuestiones de accesibilidad a menos que modifiquen el compor-
tamiento por defecto del navegador web o interfieran con la navegación de
la página con el teclado.
onClick y onDblClick
El manejador de evento onClick se dispara cuando se presiona el ratón en

el momento en que está sobre un elemento HTML. Se entiende que onClick
es un manejador de evento dependiente del ratón. Sin embargo, si se usa
el manejador de evento onClick con vínculos de hipertexto o controles de
100
WEB PARA TODOS.p65 100 12/11/2007, 12:17

formulario, la mayoría de navegadores y tecnologías de apoyo disparan el
onClick si se presiona la tecla «Intro» cuando se está sobre el vínculo o
control. En estos casos, onClick es un manejador de evento independiente
del dispositivo. No obstante, la tecla «Intro» no disparará el evento onClick
si se utiliza con elementos que no sean vínculos o controles como texto
plano o celdas de tablas.
El manejador de evento onDblClick se asocia con el doble clic del ra-
tón en un elemento HTML seleccionado. No hay equivalente independiente
del dispositivo para onDblClick, el cual debe evitarse.
onChange y onSelect
El manejador de evento onChange se dispara cuando se selecciona y cam-

bia un elemento de formulario (por ejemplo, cuando se selecciona inicial-
mente un botón de radio o cuando cambia el texto del cuadro de texto). El
manejador de evento onSelect se procesa cuando se selecciona un texto
en un campo de texto o un área de texto. Aunque estos manejadores de
evento son independientes del dispositivo y pueden activarse usando el
ratón, teclado u otro dispositivo, tienen que analizarse las acciones realiza-
das como resultado de estos manejadores de evento para determinar si
causan problemas de accesibilidad.
Usando manejadores de evento independientes

del dispositivo
Tal y como hemos mencionado anteriormente, muchos manejadores de

evento son independientes del dispositivo, como onFocus, onSelect,
onChange y onClick (cuando onClick se usa con vínculos o con ele-
mentos de formulario). Cuando sea posible, utilicemos manejadores de
evento independientes del dispositivo.
Otros manejadores de evento son dependientes del dispositivo, lo que
significa que dependen completamente de un único tipo de dispositivo de en-
trada. Por ejemplo, onMouseOver, onMouseOut y onDblClick depen-
den del uso de un ratón. También hay algunos manejadores de evento que
dependen del uso de teclado (onKeyDown, onKeyUp, etc.). Se pueden
101
WEB PARA TODOS.p65 101 12/11/2007, 12:17

usar juntos varios manejadores de evento dependientes del dispositivo para
permitir que el JavaScript se active tanto con el ratón como con el teclado.
Por ejemplo, podemos usar onMouseOver y onFocus (así como onMouseOut
y onBlur) para que se active un script, tanto con teclado como con ratón. El
uso conjunto de múltiples manejadores de evento dependientes del dispositi-
vo como medio para aplicar la independencia del dispositivo exige una gran
cantidad de evaluaciones con diferentes navegadores y tecnologías de apoyo
para verificar que no limitamos de alguna forma la accesibilidad.
Otros aspectos de JavaScript

HTML dinámico y accesibilidad
El HTML Dinámico (DHTML) es habitualmente una combinación de Hojas

de Estilo en Cascada (CSS) y JavaScript. DHTML permite a los
desarrolladores mostrar, esconder o mover la información en función de la
demanda del usuario o de comandos pre-programados. La mayoría de los
sistemas de menú desplegables o «fly-out» que se encuentran en las pági-
nas web también usan DHTML. Puesto que la mayoría de estos elementos
DHTML se modifican en función de las entradas realizadas con el ratón,
son habitualmente inaccesibles para los usuarios que no utilizan ratón.
Cuando se usa DHTML tenemos que evaluar dos cuestiones para determi-
nar su impacto en la accesibilidad:
1. ¿Se utiliza el evento para disparar un cambio independiente del dispo-

sitivo? Si se exige el ratón, no es completamente accesible.
2. ¿Son accesibles por sí mismos los contenidos o la funcionalidad
DHTML? Si las tecnologías de apoyo no pueden acceder adecuada-
mente al contenido o funcionalidad DHTML disparados, no es comple-
tamente accesible.
Usando document.write
La información dinámica constantemente cambiante como, por ejemplo, la

que muestra la hora actual en una página web, se escribe usando el co-
mando document.write de JavaScript. En la mayoría de casos, el con-
102
WEB PARA TODOS.p65 102 12/11/2007, 12:17

tenido escrito en la página usando JavaScript es accesible a las tecnolo-
gías de apoyo. No obstante, si el contenido dinámico está cambiando cons-
tantemente o interfiere de cualquier modo con la navegación o funcionalidad
del navegador, puede causar problemas de accesibilidad.
Cuando usemos información dinámica, tendremos primero que pregun-
tarnos si es necesario o imprescindible para la función o contenido de la
página. Si lo es, a menudo, hay otro camino para proporcionar el conteni-
do sin tener que utilizar JavaScript inaccesible. Por ejemplo, podemos es-
cribir la hora actualizada en la página cuando se carga utilizando un script
del lado del servidor. Aunque no se actualice constantemente, será sufi-
ciente. También podemos dirigir al usuario hacia un botón o vínculo que lo
lleven a otra página que muestra la hora actualizada mediante un procesador
del lado del servidor. Otra forma que usa una implementación más accesi-
ble de JavaScript sería proporcionar un vínculo o botón que permita al
usuario ver la hora actualizada cuando lo solicite.
Ventanas emergentes que se abren solas
Las ventanas emergentes que se abren solas suponen un problema espe-

cial de accesibilidad. En primer lugar, la mayoría de expertos en usabilidad
están contra las ventanas emergentes que se abren solas excepto en los
casos más extremos. Si tenemos que usar ventanas emergentes que se
abren solas, debemos saber que provocan muchos problemas de accesi-
bilidad. Para un usuario vidente, puede ser difícil percibir que se ha abierto
una nueva ventana y tener dificultades para navegar por ella como una
continuación de lo que hacía hasta ese momento. Para quienes usan tec-
nologías de apoyo, la apertura de una nueva ventana puede ser molesta y
causar confusión, ya que el comportamiento por defecto del vínculo se ha
modificado. La aplicación de JavaScript puede hacer imposible el cambio
de tamaño o escala a aquellos que usan magnificadores de pantalla. Para
alguien ciego, habitualmente no hay indicadores de que se esté navegan-
do una nueva ventana. Cuando el usuario de lector de pantalla intenta vol-
ver a la página anterior seleccionando el botón «atrás», queda confundido
al encontrarse con que no funciona.
Cuando se usa JavaScript para abrir nuevas ventanas, se pueden
modificar el tamaño y posición de la nueva ventana. También se puede
103
WEB PARA TODOS.p65 103 12/11/2007, 12:17

añadir o eliminar funcionalidades de la ventana, tales como la capacidad
de cambiar de tamaño, mostrar barras de desplazamiento, mostrar barras
de herramientas, etc. Tenemos que ser muy cuidadosos cuando cambie-
mos el comportamiento por defecto de la ventana del navegador. Si un
usuario tiene baja visión y necesita aumentar de tamaño el contenido, una
ventana pequeña que no pueda ser ampliada y no muestre barras de des-
plazamiento será muy inaccesible. Los usuarios con discapacidad motriz
pueden tener que depender de barras de desplazamiento grandes para
controlar con precisión el navegador web, por lo que quitarlas o modificar-
las puede introducir dificultades para estos usuarios.
Como podemos observar, el uso de ventanas emergentes que se abren
solas crea muchas dificultades tanto de usabilidad como de accesibilidad.
Debemos llevar cuidado cuando decidamos usarlas. Si se utilizan, es fun-
damental hacer test de su aplicación para asegurar la accesibilidad. Avise-
mos siempre al usuario del hecho de que se va a abrir una ventana emer-
gente.
Redireccionamiento y refresco de ventanas del navegador
Cuando la página que está visualizando el navegador cambia o se refres-

ca de pronto, la persona que está viendo esa página puede desorientarse
o quedarse confundida, especialmente si es usuaria de tecnologías de apo-
yo. La Sección 508 exige que se dé a los usuarios el control sobre los
cambios de contenidos tempo-dependientes. Ello implica no cambiar o re-
frescar automáticamente la ventana del navegador sin avisar al usuario de
lo que va a suceder y darle la posibilidad de deshabilitar o posponer el
cambio.
Usando CSS puro como alternativa a JavaScript
Los parámetros de las Hojas de Estilo en Cascada (CSS) a menudo se

modifican con JavaScript para crear páginas dinámicas cambiantes
(DHTML). Sin embargo, con la llegada de la versión 2 de CSS, gran parte
de la funcionalidad dinámica disponible en JavaScript está incluida en las
especificaciones de CSS. Esto permite construir elementos de presenta-
ción y navegación dinámicos sin necesidad de los eventos de JavaScript.
104
WEB PARA TODOS.p65 104 12/11/2007, 12:17

Se pueden crear menús de desplazamiento, imágenes interactivas y otras
interesantes características en los sitios web sin tener que preocuparse
sobre los manejadores de evento dependientes del dispositivo. No obstan-
te, los navegadores modernos como Internet Explorer, no soportan com-
pletamente los estándares CSS. Igualmente, los lectores de pantalla tam-
poco soportan completamente CSS, especialmente cuando se encuentran
con contenido que puede ser visibilizado o in-visibilizado usando los estilos
d i s p l a y : n o n e («mostrar:nada») o v i s i b i l i t y : h i d d e n
(«visibilidad:oculto»). Muchos lectores de pantalla no leen el contenido que
tenga asignados esos estilos, aunque el contenido sea parte de la estruc-
tura subyacente de la página. Hasta que tanto los navegadores web como
las tecnologías de apoyo soporten mejor CSS, sólo debemos emplear CSS
para producir contenido dinámico después de probarlo con múltiples
navegadores y lectores de pantalla.
Alternativas a JavaScript
Si JavaScript no puede ser hecho accesible de por sí usando las técnicas

anteriores, tiene que proveerse una alternativa accesible. Igualmente, to-
davía son pocos los agentes de usuario, como los teléfonos móviles con
acceso a la web y los PDA, que utilizan JavaScript. Hay muchos modos de
proporcionar alternativas accesibles cuando no se pueden hacer accesi-
bles los «scripting» o cuando el usuario final no tiene activado JavaScript.
Procesando del lado del servidor
En muchos casos, la funcionalidad provista por JavaScript puede ser dupli-

cada por «scripting» del lado del servidor. Por ejemplo, JavaScript se utili-
za a menudo para validar los elementos de un formulario antes de enviar
éste. En lugar de aplicar esa programación JavaScript y las técnicas co-
rrespondientes de accesibilidad, se podrían usar script del lado del servidor
para validar los elementos del formulario. Con frecuencia se usa JavaScript
para escribir información dinámica en una página web, tal como la fecha u
hora actuales. De nuevo, el uso de un script del servidor o del lado del
servidor elimina la necesidad de aplicar accesibilidad adicional.
105
WEB PARA TODOS.p65 105 12/11/2007, 12:17

Usando el elemento <noscript>
Es muy importante hacer el JavaScript accesible de por sí. No obstante,

en algunos casos, puede que el usuario final no tenga habilitado el
JavaScript, o puede que esté utilizando tecnologías que no soporten
JavaScript (por ejemplo, teléfono móvil, PDA, etc.). En estos casos, pode-
mos proveer alternativas sin JavaScript para los usuarios que no pueden o
elijan no ver el contenido JavaScript.
Cuando se usa JavaScript en una página web, el camino más sencillo
para proporcionar una alternativa al contenido generado con JavaScript es
proporcionar contenido con el elemento <noscript>. El elemento
<noscript> puede usarse en una página para mostrar el contenido en
navegadores que no soportan o tienen deshabilitado el JavaScript. No obs-
tante, si JavaScript ESTÁ activado, el elemento <noscript> será igno-
rado.
Proporcionar una alternativa accesible con el elemento <noscript> para

un script inaccesible no hará que la página sea accesible. El contenido
<noscript> sólo se mostrará si JavaScript está deshabilitado. La ma-
yoría de usuarios de lectores de pantalla tienen JavaScript habilitado,
por lo que se encontrarán con el script inaccesible y no con el elemento
<noscript>.
El elemento <noscript> proporciona texto alternativo al JavaScript.

Si el contenido o funcionalidad del script necesitan una alternativa accesi-
ble cuando el JavaScript está deshabilitado, es preciso un <noscript>.
El contenido <noscript> debería, idealmente, tener un contenido o
funcionalidad equivalentes a los que se proporcionen con el script. Sin
embargo, a menudo esto no es posible. No es suficiente con indicar sim-
plemente «Su navegador no soporta JavaScript». Esto no hace nada para
hacer el contenido accesible. Se puede, en lugar de ello, por ejemplo,
proporcionar un vínculo a una alternativa HTML accesible o a una página
que utilice «scripting» del lado del servidor. O, como mínimo, describir el
tipo de contenido que se mostraría si el JavaScript estuviera habilitado.
Debemos usar <noscript> cada vez que necesitemos un contenido
o funcionalidad alternativos (o no-JavaScript).
106
WEB PARA TODOS.p65 106 12/11/2007, 12:17

A continuación vemos un breve ejemplo de cómo se aplicaría el ele-
mento <noscript> en el código HTML:
<script type="text/javascript">
<!—
document.write("La hora actual es " + currenttime)
—>
</script>
<noscript>
<!—vinculo a la página que muestra la hora mediante
script del lado del servidor —>
<a href="hora.htm">Vea la hora actual</a>
</noscript>
Resumen de JavaScript
JavaScript permite a los usuarios agregar al contenido basado en la web

más interacción, procesamiento de información y control. JavaScript tam-
bién puede crear problemas de accesibilidad a través de la limitación de la
navegación cuando se usa el teclado o una ayuda técnica, ya que podría
presentar contenido o funcionalidad no accesibles a las tecnologías de
apoyo, podría limitar el control del usuario sobre los cambios automáticos
de contenido y podría modificar la funcionalidad normal del navegador. A
la vista de los problemas de accesibilidad de JavaScript, podemos hacer
algo de lo siguiente:
• Asegurar que JavaScript es directamente accesible.

• Proporcionar una alternativa accesible no-JavaScript.
A menudo se usa JavaScript para hacer cambios estéticos o de conte-

nido que no afectan a la accesibilidad. El contenido escrito en una página
usando JavaScript será accesible:
• Si se usan manejadores de evento independientes del dispositivo.

• Si el contenido y funcionalidad habilitados con JavaScript son accesi-
bles a las tecnologías de apoyo.
107
WEB PARA TODOS.p65 107 12/11/2007, 12:17

• Si las páginas y elementos de script son navegables con el teclado.
• Si no se modifica la funcionalidad normal del navegador de tal forma
que cause confusión o inaccesibilidad.
• Si se proporciona una alternativa accesible cuando JavaScript no pue-
de hacerse accesible de por sí.
Hay dos tipos de manejadores de eventos en JavaScript:
• Dependientes del dispositivo.

• Independientes del dispositivo.
Cuando se apliquen manejadores de eventos, se tiene que usar, bien

un manejador de evento independiente del dispositivo, bien múltiples
manejadores de eventos dependientes del dispositivo, para acomodarse a
todos los usuarios. A continuación hay una lista de manejadores de even-
tos habituales y sus aspectos de accesibilidad asociados:
onMouseOver y onMouseOut:
• Dependientes del dispositivo (requieren el uso de ratón).
• Tenemos que asegurarnos de que no se introducen contenido o
funcionalidad importantes con estos manejadores de evento.
• Debemos utilizarlos junto con los manejadores de evento onFocus
y onBlur para permitir la accesibilidad desde el teclado.
• Tenemos que proporcionar una alternativa accesible si el contenido
o la funcionalidad no pueden hacerse accesibles de por sí.
onFocus y onBlur:
• Independientes del dispositivo (funcionan tanto con el teclado como
con el ratón).
• Hemos de verificar para asegurarnos de que no se afecta la accesi-
bilidad.
onClick y onDblClick:
• Dependientes del dispositivo (requieren el uso de ratón).
• onClick se activa con la tecla «Intro» cuando se usa en vínculos y
elementos de formulario.
• No hay equivalentes independientes del dispositivo o accesibles desde
el teclado para estos manejadores de eventos.
108
WEB PARA TODOS.p65 108 12/11/2007, 12:17

•También tenemos que hacer accesibles la funcionalidad y contenido
que proporciona el manejador de evento onClick.
onChange y onSelect:
• Independientes del dispositivo (funcionan tanto con el teclado como
con el ratón).
• La funcionalidad y contenido que proporcionan los manejadores de
evento onChange y onSelect también tienen que hacerse accesi-
bles.
• Los ítems del menú de navegación desplegable que se disparan
con onChange no son completamente accesibles desde el teclado.
Cómo decíamos anteriormente, el HTML dinámico (DHTML) es una com-

binación de JavaScript y Hojas de Estilo en Cascada (CSS). Por su propia
naturaleza, DHTML puede presentar contenido que cambia dinámicamente.
A menudo el DHTML se dispara por las interacciones del usuario, tales como
mover el ratón. Cuando se aplique DHTML, hay que asegurarse de que se
dispara de forma independiente del dispositivo y de que el contenido y la
funcionalidad que proporciona DHTML también son accesibles.
JavaScript también puede usarse para escribir contenido dinámico en
una página web. En la mayoría de casos, este contenido es accesible, a
menos que el contenido esté cambiando constantemente o interfiera de
cualquier otro modo en la accesibilidad de la página.
JavaScript también puede afectar al comportamiento por defecto del
navegador web y a ciertos elementos de HTML. JavaScript y los
manejadores de evento de JavaScript pueden disparar la aparición de ven-
tanas que se abren solas. Si no avisamos al usuario del hecho de que se
está abriendo sola una ventana, puede confundirse o desorientarse, por-
que este comportamiento no es natural del navegador web. Otras modifi-
caciones de las ventanas del navegador para quitar las barras de despla-
zamiento, las barras de estado, las barras de menú o las barras de
herramientas también pueden causar problemas de accesibilidad. Utilice-
mos con cuidado las ventanas que se abren solas y, si las usamos, avise-
mos de ello siempre al usuario. También debemos avisar al usuario cuan-
do usamos JavaScript para ejecutar automáticamente funciones del
navegador como el redireccionamiento, el refresco o el desplazamiento
automático. En todos los casos, los test de usuario y los test con tecnolo-
109
WEB PARA TODOS.p65 109 12/11/2007, 12:17

gías de apoyo pueden proporcionar información valiosa respecto a la ac-
cesibilidad de las aplicaciones específicas de JavaScript.
Hay muchas formas de proporcionar alternativas a JavaScript. Las
versiones más nuevas de CSS pueden tener un comportamiento similar al
de JavaScript por sí mismas. Pueden hacerse menús desplegables, ba-
rras de navegación e imágenes interactivas sin depender de JavaScript.
No obstante, la aplicación de CSS en los navegadores y las tecnologías
de apoyo todavía es variada y problemática.
Cuando el propio JavaScript no pueda ser hecho accesible de por sí,
tenemos que proveer una alternativa accesible. Esto puede hacerse dupli-
cando o sustituyendo el comportamiento de JavaScript por un procesamien-
to del lado del servidor. También podemos proveer un contenido <noscript>
que sea accesible cuando el usuario final deshabilite o no tenga JavaScript.
Pautas aplicables
Se aplican a JavaScript las siguientes Pautas WCAG 1.0:
Prioridad 1:
• 6.3 - Asegúrese de que las páginas son usables cuando estén des-
conectados o no se soporten scripts, applets u otros objetos de pro-
gramación. Si no es posible, proporcione información equivalente en
una página accesible alternativa.
Prioridad 2:
• 6.4 - Para los scripts y applets, asegúrese de que los manejadores
de evento son independientes del dispositivo de entrada.
• 6.5 - Asegúrese de que el contenido dinámico es accesible o pro-
porcione una presentación o página alternativas.
• 7.4 - Hasta que las aplicaciones de usuario proporcionen la posibili-
dad de detener el refresco, no cree páginas que se auto-refresquen.
• 7.5 - Hasta que las aplicaciones de usuario proporcionen la posibili-
dad de detener el auto-redireccionamiento, no use marcadores para
redireccionar páginas automáticamente. En lugar de eso, configure
el servidor para que realice los redireccionamientos.
110
WEB PARA TODOS.p65 110 12/11/2007, 12:17

• 8.1 - Haga los elementos de programación, tales como los scripts y
applets, directamente accesibles o compatibles con las tecnologías
de apoyo.
• 10.1 - Hasta que las aplicaciones de usuario permitan desconectar
la apertura de nuevas ventanas, no haga que aparezcan solas ven-
tanas y no cambie la ventana actual sin informar al usuario.
111
WEB PARA TODOS.p65 111 12/11/2007, 12:17

112
WEB PARA TODOS.p65 112 12/11/2007, 12:17

Creando contenido accesible con Flash
de Macromedia
Visión general de la accesibilidad de Flash
El contenido de Flash Macromedia puede visualizarse en casi todos los

ordenadores. La tecnología Flash, en general, es posiblemente una de
las más ampliamente difundidas de las usadas en la web. Para los desarro-
lladores, la posibilidad de programar una presentación multimedia que
pueda ser visualizada de igual manera en prácticamente todos los orde-
nadores, hace esta tecnología muy atrayente. Sin embargo, para las per-
sonas con discapacidades, Flash puede introducir problemas de accesi-
bilidad únicos.
Debido a la naturaleza multimedia de Flash, éste puede usarse para
enviar contenidos a través de diversos medios (gráficos, textos, vídeo, audio,
etc.) Su capacidad y flexibilidad le proporcionan el potencial para presentar
el contenido web de forma totalmente accesible. He aquí algunos ejem-
plos de cómo Flash puede incrementar la accesibilidad:
• Múltiples modos de presentación: Flash puede proporcionar el con-

tenido de muchos modos diferentes.
• Escalabilidad: Puesto que Flash se basa en objetos vectoriales (líneas
y formas definidas matemáticamente) en lugar de en tecnologías de
«raster» (píxels de diferentes colores), la mayoría del contenido Flash
puede modificarse fácilmente a cualquier tamaño sin distorsión. Las
personas con baja visión pueden interactuar con el contenido Flash de
formas en las que no es posible hacerlo con los contenidos HTML.
• Accesibilidad del teclado: Flash permite un grado de interacción con
el teclado mayor que el que permite HTML. Muchas presentaciones
Flash pueden hacerse más funcionales, potentes y fáciles de usar si se
permite el acceso a través del teclado.
113
WEB PARA TODOS.p65 113 12/11/2007, 12:17

• Atractivo: Flash puede atraer a los que están aprendiendo a través de
la interactividad, la animación, los sonidos, los gráficos y de muchas
otras formas. Las personas con discapacidades cognitivas o del apren-
dizaje pueden aprehender mejor y prestar mayor atención a algún con-
tenido de Flash. Podemos usar los Flash multimedia para complemen-
tar el contenido HTML estático.
• Auto-lectura: Debido a las capacidades de audio de Flash, éste puede
presentar el contenido a través de sonido, eliminando pues la necesi-
dad de que un lector de pantalla extraiga el contenido sonoro de la
presentación de Flash.
A pesar de la capacidad de Flash de crear contenidos altamente acce-

sibles, hay algunos aspectos fundamentales que deben tenerse en cuenta
respecto a Flash y la accesibilidad. Casi todos los conceptos que afectan a
la accesibilidad del HTML pueden aplicarse a Flash. Éstos incluyen el uso
de mucho contraste, la consistencia en la navegación, el lenguaje com-
prensible, etc. He aquí algunas estrategias específicas para hacer accesi-
ble Flash a diferentes tipos de discapacidad:
• Discapacidades auditivas: proporcionar subtítulos sincronizados para

cualquier sonido que transmita contenido.
• Epilepsia fotosensible: eliminar el contenido estroboscópico que emi-
ta con una frecuencia de entre 2 y 55 veces por segundo.
• Discapacidades motoras: asegurar que el contenido es accesible a tra-
vés del teclado y que no plantea tareas que requieran motricidad fina.
• Discapacidades cognitivas: proporcionar a los usuarios el control so-
bre el contenido sensible al tiempo; proporcionar controles y esquemas
de navegación fáciles de usar; ser consistente; y utilizar el lenguaje
más claro y simple adecuado al contenido.
• Baja visión: proporcionar mucho contraste y permitir que el contenido
Flash pueda ser ampliado de tamaño.
• Ceguera: asegurar la accesibilidad para el lector de pantalla o propor-
cionar una alternativa accesible; asegurar la accesibilidad del teclado;
no interferir con el sonido del lector de pantalla o con los comandos de
teclas; y proporcionar equivalentes textuales para todos los elementos
no textuales que transmiten contenido o proporcionan una función.
114
WEB PARA TODOS.p65 114 12/11/2007, 12:17

Aunque cada una de estas estrategias puede incrementar la accesibili-
dad, el contenido Flash rara vez es diseñado para que incluya todas ellas
al mismo tiempo, haciéndolo por tanto en cierta forma inaccesible. Si apli-
camos a Flash todas estas estrategias, puede ser universalmente accesi-
ble, quizás más incluso que HTML, porque se elimina la necesidad de ayu-
das técnicas específicas (con las limitaciones que conllevan). Sin embargo,
este esfuerzo puede ser difícil, e incluso imposible, con la mayoría del
contenido Flash. En resumen, si no aplicamos todas las técnicas de
accesibilidad recogidas en este documento, puede que el Flash no
sea accesible.
Tecnologías de apoyo soportadas por Flash
La mayoría del contenido Flash no puede ser hecho originalmente

accesible a los lectores de pantalla.
Debido a su propia naturaleza, el contenido Flash no se presta de por

sí a la accesibilidad para los lectores de pantalla. El contenido Flash está
basado en el tiempo y a menudo cambia a lo largo del mismo. El contenido
HTML es más o menos estático. La naturaleza estática de HTML permite
al lector de pantalla acceder al contenido HTML de una manera lineal. Cuan-
do un usuario vidente accede a una película Flash, puede «escanear»
visualmente el contenido de la misma y enfocar su atención directamente
en el contenido o función importantes. El lector de pantalla del usuario no
puede «escanear» el contenido del Flash y sólo puede acceder de una
manera lineal, en el orden en que el desarrollador del Flash ha elegido
presentarlo. Puesto que el contenido Flash es normal que cambie de forma
constante, se limita la capacidad del lector de pantalla de leer el contenido
de forma eficiente. El lenguaje de programación y temporización de Flash
(ActionScript) permite cambiar constantemente, dinamizar y actualizar los
objetos para que se muevan, desaparezcan o se dupliquen por sí mismos,
en cualquier momento que el desarrollador de Flash lo elija (o incluso de
forma aleatoria si quiere). De hecho, la accesibilidad para Flash podría es-
tar más relacionada con los aspectos de accesibilidad de las transmisiones
televisivas, excepto que el Flash es interactivo y las televisiones no.
115
WEB PARA TODOS.p65 115 12/11/2007, 12:17

A pesar de los problemas que Flash puede suponer para los usuarios
de lectores de pantalla, podemos aplicar algunas técnicas para hacer Flash
más accesible.
Por ahora, sólo las versiones actualizadas de los lectores de pantalla

JAWS y Window-Eyes que usan un Flash 6+ pueden proporcionar un
acceso marginal al contenido Flash. Su soporte para la accesibilidad de
Flash en las herramientas de autor, la ejecución y los lectores de panta-
lla deja mucho que desear. Para hacerlo completamente accesible a los
lectores de pantalla, el contenido debe ser desarrollado usando Flash
MX o posterior.
La opción de Accesibilidad de Microsoft Active (Microsoft Active

Accessibility, MSAA) se usa para enviar el contenido desde el programa
Flash al lector de pantalla. MSAA es una tecnología de Microsoft que ac-
tualmente sólo funciona en ordenadores con Internet Explorer en Windows
que tengan instalada la versión 6+ o una posterior del programa Flash.
Aunque la mayoría de las tecnologías de apoyo tienden a ser aplicadas en
Windows con Internet Explorer, los lectores de pantalla desarrollados para
otras plataformas no pueden beneficiarse de las características de accesi-
bilidad de Flash. También hay muchos lectores de pantalla que funcionan
con otros sistemas operativos. Además, alguien con una discapacidad
motora puede que no use Internet Explorer. De igual modo, el usuario final
puede no tener instalada la versión más reciente del programa Flash. De
hecho, puede no tener instalado Flash (debido a la amplia inaccesibilidad
del contenido de Flash, muchos usuarios de lectores de pantalla han
desactivado el contenido Flash). Por todo ello, debemos animar al
desarrollador a que pruebe con una gama de usuarios finales, plataformas,
navegadores y ayudas técnicas para asegurar que el contenido Flash es
accesible al más amplio rango de usuarios.
Puede que necesitemos reevaluar el uso de Flash, ya que quizás otra
tecnología funcione mejor. Puesto que la inmensa mayoría del contenido
Flash no puede hacerse originalmente accesible, será vital que proporcio-
nemos alternativas sin Flash para aquellos que no puedan o elijan no acce-
der a su Flash multimedia.
116
WEB PARA TODOS.p65 116 12/11/2007, 12:17

Accesibilidad con lector de pantalla
Hay tres maneras de hacer el contenido Flash accesible a los usuarios de

lectores de pantalla:
1. Hacer el contenido Flash naturalmente accesible al lector de pantalla.

2. Hacer que Flash lea por sí mismo el contenido, eliminando la necesi-
dad de lectores de pantalla.
3. Proporcionar una alternativa accesible al contenido Flash.
La mayoría de este material didáctico estará centrado en la primera

propuesta: cómo hacer la presentación Flash naturalmente accesible. Pero
vamos a hablar brevemente sobre las otras dos opciones.
Si hacemos que la presentación Flash lea por sí misma el contenido,
eliminaremos la necesidad de lectores de pantalla. En esencia, estaremos
asumiendo la función del lector de pantalla proporcionando de forma auditiva
cualquier contenido que se presente visualmente en la presentación Flash.
Debemos advertir al usuario de lector de pantalla de que el programa es
auto-lector, de modo que pueda detener el lector de pantalla mientras la
presentación Flash muestra el contenido sonoro. Cualquier contenido im-
portante que se proporcione de forma visual debe también presentarse de
forma sonora. Podemos asimilarlo a la audición de un encuentro deportivo
por la radio (aunque no podamos ver la acción, los comentaristas propor-
cionan todos los detalles importantes a través del sonido). Podemos que-
rer proporcionar una presentación que lea por sí misma como alternativa a
una presentación Flash sin sonidos o proporcionar una opción para conec-
tar o desconectar la funcionalidad de auto-lectura. Recordemos que si es-
tamos proporcionando cualquier contenido auditivo que no resulta visible
en la presentación visual, debemos proporcionar subtítulos para los sordos
y los que tienen dificultades auditivas. La presentación debe ser también
accesible desde el teclado.
La tercera opción es proporcionar una alternativa equivalente a la pro-
pia presentación Flash. Esto sólo debe hacerse cuando no se pueda hacer
la presentación accesible de ninguna otra forma. Puede ser difícil justificar
que un tutorial HTML sea equivalente a un tutorial Flash multimedia
interactivo. La clave es hacer un contenido equivalente accesible, no nece-
117
WEB PARA TODOS.p65 117 12/11/2007, 12:17

sariamente de sólo-texto. En lugar de proporcionar dicha página de sólo-
texto, con largas extensiones de texto, el equivalente debería ser una pági-
na web bien formateada y accesible, con imágenes, iconos, párrafos y
color. Sólo porque alguien acceda a la alternativa equivalente, no significa
que sea ciego y que no le importe qué apariencia tiene la página o cómo
funciona. A menudo, la alternativa puede estar en la misma página con el
propio Flash. En algunos casos, podemos dar al usuario la opción de acti-
var o desactivar el contenido Flash.
Equivalentes textuales
Debemos proporcionar equivalentes textuales en Flash para todo elemento

no textual que aporte contenido importante. Esto significa que los gráficos,
animaciones y vídeos deben tener equivalentes textuales a los que pueda
acceder cualquiera que no pueda ver dichos elementos. De igual forma,
debemos proporcionar un equivalente textual (subtítulos y/o transcripcio-
nes) para todo el contenido sonoro que no se muestre también mediante
los elementos visuales de la presentación.
Proporcionar subtítulos en Flash facilita la accesibilidad a los usuarios
que no pueden escuchar o comprender plenamente el contenido sonoro.
Debido a la naturaleza interactiva de Flash, los subtítulos pueden activarse
o desactivarse y pueden programarse para que se ejecuten de diversas
formas. Si el contenido del Flash multimedia es primordialmente sonoro,
debemos proporcionar también una trascripción.
Tanto Media Access Generator1 (MAGpie) de WGBH’s National Center
for Accessible Multimedia como Hi-Caption™ SE2 de HiSoftware, permi-
ten generar subtítulos que pueden incorporarse a la presentación Flash.
Podemos proporcionar equivalentes textuales para los elementos grá-
ficos con Flash usando el panel Accesibilidad de Flash, disponible en
Ventana > Otros paneles > Accesibilidad en Flash o presionando ALT +
F2.
1. Referencia web: http://ncam.wgbh.org/webaccess/magpie/.

2. Referencia web: http://www.hisoftware.com/hmccflash/index.html.
118
WEB PARA TODOS.p65 118 12/11/2007, 12:17

Nota: todos estos ejemplos usan Flash MX 2004 Profesional. El as-
pecto y funcionalidad pueden ser ligeramente diferentes a los de otras ver-
siones de Flash.
Imagen 44. Opciones en el panel de Accesibilidad de Flash.
Hay muchas opciones disponibles en el panel de Accesibilidad. Los

ítems visibles en él varían dependiendo del objeto que esté seleccionado
en ese momento. A continuación se describen algunos:
Hacer la presentación accesible:

Si está seleccionado (por defecto), las características de accesibilidad de
Flash se mostrarán al lector de pantalla. Si no está seleccionado, el lector
de pantalla identificará que hay una presentación Flash, pero no accederá
a ningún contenido de la misma.
Hacer el objeto accesible:

Si la opción no está seleccionada, el objeto actualmente seleccionado se
hará invisible para el lector de pantalla y el equivalente textual, así como
cualquier texto anexo al símbolo actual, no serán accesibles al lector de
119
WEB PARA TODOS.p65 119 12/11/2007, 12:17

pantalla. Esto puede ser útil si el símbolo no proporciona contenido impor-
tante. Por defecto, la opción de hacer los objetos accesibles está seleccio-
nada, pero debemos asegurarnos de tener seleccionada esta opción si el
objeto contiene texto importante o proporciona contenido.
Hacer que los objetos secundarios sean accesibles:

Si tenemos otros objetos o símbolos insertos en el objeto seleccionado,
podemos ocultarlos seleccionando esta opción. Esto resulta útil para sím-
bolos que están compuestos por múltiples objetos, pero que como unidad
sólo necesitan un único equivalente textual. Por ejemplo, si un símbolo de
una presentación contiene una animación de texto en la que cada letra de
una palabra se mueve de forma independiente, no querremos que el lector
de pantalla lea cada letra individual. Para solucionarlo, deberíamos añadir
texto alternativo a la propia presentación y desactivar el «Hacer que los
objetos secundarios sean accesibles» para esconder los ítems animados
de la presentación.
Etiquetado automático:
Esta opción ordena a Flash que asocie botones con texto que está en, o
cerca de, el botón. Si todos los botones tienen texto dentro o adyacente,
«Etiquetado automático» puede asociarlos automáticamente y leerá el tex-
to como una alternativa textual al botón. Los resultados no son siempre los
esperados y debemos llevar cuidado cuando utilicemos «Auto-etiquetado».
Nombre:
Aquí es donde debemos insertar el texto alternativo para un objeto Flash,
ya que esto es lo que leerá el lector de pantalla en lugar del objeto selec-
cionado. Podemos introducir un nombre o descripción breve del objeto (una
o dos frases cortas).
Descripción:
Se usa para descripciones más largas de los objetos Flash y no es nece-
sario a menos que se precise una descripción adicional a la que permite
«Nombre». Si proporcionamos tanto «Nombre» como «Descripción», el
lector de pantalla leerá primero el nombre y luego la descripción.
Funcionalmente, no hay diferencia entre ambas.
120
WEB PARA TODOS.p65 120 12/11/2007, 12:17

Atajo (shortcut):
Permite indicar al usuario qué atajo se atribuye a un objeto específico. No
programa el atajo de teclado, simplemente alerta al usuario sobre para
qué sirve el atajo.
Cómo funciona el equivalente textual de Flash
Por defecto, el texto inserto en Flash se muestra al lector de pantalla a

través de MSAA. No tenemos que hacer nada especial para hacer un tex-
to accesible a los lectores de pantalla. Si la presentación Flash no es más
que texto estático, probablemente será accesible a los lectores de pantalla
sin ninguna otra modificación. Por supuesto, rara vez se usa Flash para
mostrar texto estático. En tanto que los elementos textuales no requieren
modificación por parte del diseñador o desarrollador, otros elementos sí la
necesitan. Los diseñadores y desarrolladores pueden usar el panel «Acce-
sibilidad» de Flash Macromedia para añadir un texto equivalente o incluso
ocultar elementos de las tecnologías de apoyo.
Cuando un lector de pantalla accede a una página con contenido Flash,
lo indica. JAWS lee «Comienza la presentación de Flash Macromedia»
(esto es elegible en la configuración de JAWS) y Windows-Eyes lee «Tie-
ne Flash». Con esto, se alerta al usuario sobre lo que está ocurriendo si la
página comienza a leer información que confunde o si la página no parece
ser accesible desde el teclado debido al contenido Flash. Cuando se acce-
de a la presentación Flash, el lector de pantalla leerá todo el texto y los
textos alternativos de la presentación Flash. Cuando ha terminado, lo indi-
cará. Todo el texto que contenga la presentación Flash cuando acceda el
lector de pantalla, será leído por éste.
Debido a la naturaleza lineal de los lectores de pantalla, sólo pue-
den leer el contenido mostrado en el momento en que acceden a un
lugar específico de la presentación Flash. Por ejemplo, si ésta tiene una
serie de citas que se muestran de forma aleatoria cada diez segundos
en la presentación Flash, el lector de pantalla sólo leerá la cita que esté
desplegada en el momento en que acceda a esa parte de la presenta-
ción. Si la cita cambia mientras se está accediendo al elemento de Flash,
el lector de pantalla es alertado de que algo ha cambiado y comienza
otra vez a leer desde el principio de la página. Este hecho provoca que
121
WEB PARA TODOS.p65 121 12/11/2007, 12:17

la mayoría del contenido de Flash sea inaccesible para los lectores de
pantalla.
Evitemos exponer animaciones o cambios de texto al lector de pantalla.

Cada vez que cambia un elemento expuesto de la presentación Flash, el
lector de pantalla comenzará a leer por el principio de la página.
Podemos evitar este problema, bien evitando los textos animados en

Flash o bien ocultándolos al lector de pantalla, tal y como se muestra más
adelante.
Cuando el lector de pantalla accede a la presentación, lee cualquier
texto incluido en la presentación Flash. Ello incluye al texto inserto en boto-
nes. Con el entorno de creación de Flash MX, se pueden añadir equivalen-
tes textuales para los elementos gráficos, siempre que los elementos estén
definidos como símbolos de «clip de películas» o botones. Los símbolos
definidos con el comportamiento «gráfico» no soportan los equivalentes
textuales. Si un ítem gráfico no tiene definido un texto alternativo, el lector
de pantalla lo ignora.
Añadir equivalentes textuales
Para añadir un equivalente textual, seleccionaremos un ítem del escenario

e introduciremos una breve descripción del objeto en el campo «Nombre»
del panel de «Accesibilidad». Si es necesaria una descripción más larga,
puede añadirse en el campo «Descripción» de ese panel. El lector de pan-
talla leerá en ese caso el texto en lugar del objeto. Tenemos que asegurar-
nos de que el nombre y la descripción de Flash son totalmente invisibles,
excepto para los lectores de pantalla. Flash no ofrece ninguna indicación
visual o «tool tip» (breve descripción que aparece al apuntar a un icono o
un botón) para los equivalentes textuales, como puede ocurrir con el atri-
buto «alt» en HTML para algunos navegadores. Los ítems de Flash que
son texto no necesitan un equivalente textual, ya que se leerá el propio
texto. Debemos asegurarnos de que los ítems de texto son realmente tex-
to y contienen palabras inteligibles. Las configuraciones gráficas, así como
muchos elementos de texto que se ponen juntos para formar imágenes de
palabras, no pueden ser leídos correctamente como texto. En estos casos,
122
WEB PARA TODOS.p65 122 12/11/2007, 12:17

debemos colocar estos elementos en un símbolo de «clip de película» al
que asignaremos la adecuada alternativa textual para el grupo en el cam-
po «Nombre». Tenemos que desactivar la opción «Hacer que los objetos
secundarios sean accesibles» en el panel de accesibilidad para esconder
los contenidos internos del símbolo de «clip de película» al lector de panta-
lla. Debemos añadir equivalentes a los ítems de texto si éste está definido
como un texto dinámico, en cuyo caso el texto inserto en la caja de texto
dinámico será ignorado y en su lugar se leerá el equivalente textual.
El equivalente textual («Nombre» o «Descripción») no tiene porqué ser
exactamente igual al contenido. Podemos proporcionar información adicio-
nal o menor, según se desee. Cuando asignemos texto alternativo en Flash,
debemos usar las mismas técnicas que se utilizan para determinar el texto
alternativo para las imágenes de HTML. No obstante, y debido a su natu-
raleza dinámica, puede a veces no ser apropiado usar un equivalente exacto.
Por ejemplo, si una película tiene docenas de palabras volando por la pan-
talla para llamar la atención, puede no ser adecuado proporcionar un texto
alternativo para dichas palabras. En lugar de eso, podemos o bien propor-
cionar texto alternativo para una o dos o bien describir en general lo que
está pasando; o podemos incluso no proporcionar una alternativa para esas
palabras, si consideramos que no aportan contenido relevante.
Tal y como se ha expuesto anteriormente, si animamos un texto, la
presentación Flash indicará que hay un cambio y puede que el lector de
pantalla empiece a leer la página desde el principio. No obstante, los grá-
ficos animados no son un problema para los usuarios de lectores de panta-
lla si se proporciona el equivalente textual para el gráfico, puesto que lee-
rán éste. Los gráficos animados pueden ser problemáticos para aquellos
que tengan epilepsia fotosensible si la animación parpadea o destella.
Hay tres métodos para hacer los botones accesibles en Flash (listados
en orden de fiabilidad y facilidad de uso):
1. Colocar el texto dentro del símbolo del botón. El texto se leerá cuando
se acceda al botón.
2. Proporcionar una alternativa equivalente en los campos de «Nombre»
y/o «Descripción» del panel de Accesibilidad.
3. Colocar el texto adyacente al botón y utilizar la característica de «Eti-
quetado automático» del panel de Accesibilidad.
123
WEB PARA TODOS.p65 123 12/11/2007, 12:17

Si el texto está dentro del símbolo del botón, el lector de pantalla lo
leerá cuando se acceda al botón. Si el símbolo del botón no contiene en sí
mismo el texto, debemos proporcionar un equivalente textual en el panel
de Accesibilidad. Por defecto, el lector de pantalla indicará que hay un
botón y leerá el texto contenido en él o el equivalente textual. JAWS lee el
texto y luego lee «botón». Windows-Eyes lee «botón» y después el texto.
Si el botón contiene más de un elemento de texto, Flash cogerá (apa-
rentemente de forma aleatoria) sólo uno de los ítems de texto y lo leerá.
Tal y como hemos indicado anteriormente, Flash tiene también una
característica de «Etiquetado automático» que se encuentra en el panel de
Accesibilidad. Esta opción aparece en el panel cuando no hay ningún es-
cenario seleccionado. Cuando está seleccionado «Etiquetado automático»,
si no hay especificado un equivalente para un botón ni aparece texto en el
botón, Flash intentará asociar por sí mismo cualquier texto que esté por
encima o cerca del botón y lo leerá como un equivalente. Esto funciona
bien en tanto que la etiqueta de texto adecuada para un botón esté ubica-
da de forma que Flash la relacione con el botón correcto. Los resultados
del uso del «Etiquetado automático» son tan aleatorios, que habitualmente
es mejor dejarlo desconectado y colocar siempre el texto, bien dentro del
botón o en el panel de Accesibilidad. Si se utiliza el «Etiquetado automáti-
co», debemos usar un lector de pantalla compatible para verificar si se ha
asociado por sí mismo el texto adecuado con el botón correspondiente de
la presentación.
El lector de pantalla no leerá la animación de texto realizada con algu-
no de los estados del botón (arriba, sobre, debajo o pulsado, «up, over,
down o hit») y puede provocar que aquél comience continuamente a leer
desde el principio de la página web. Si un botón contiene texto animado,
debemos desactivar «Hacer que los objetos secundarios sean accesibles»
en el panel de «Accesibilidad» y en su lugar debemos proporcionar un
equivalente textual (en «Nombre» y/o «Descripción»).
Proporcionar equivalente textual para la presentación

completa
Si es adecuado, podemos proporcionar fácilmente un equivalente textual

para la presentación completa, en lugar de preocuparnos de proporcionar
124
WEB PARA TODOS.p65 124 12/11/2007, 12:17

accesibilidad a las partes individuales de la presentación. Esto sería algo
similar a proporcionar un equivalente textual para una página web comple-
ta. Simplemente, tenemos que seleccionar el panel de Accesibilidad y des-
conectar «Hacer que los objetos secundarios sean accesibles» para es-
conder los contenidos internos de la presentación. Luego desconectaremos
el «Etiquetado automático» y añadiremos un breve «Nombre» y, si es ne-
cesario, una «Descripción» más larga.
Imagen 45. Uso de las opciones «nombre» y «descripción» en el panel

de accesibilidad de Flash.
La mayoría de los anuncios hechos con Flash pueden hacerse más

accesibles de esta manera, aunque si contienen un botón, pueden interferir
con la navegación por teclado, tal y como se describe en la sección de
«Accesibilidad del teclado».
Accesibilidad del teclado
A menos que estemos usando la versión 7 del programa Flash en Internet

Explorer para Windows, cuando Flash enfoca sobre una página web, se
125
WEB PARA TODOS.p65 125 12/11/2007, 12:17

mantiene ese foco. Esto significa que una vez se pincha o se tabula en
una presentación Flash, no se puede usar el teclado para navegar a otros
ítems de la página. Los lectores de pantalla que soportan Flash (como las
versiones actuales de JAWS y Windows-Eyes) contienen una funcionalidad
que llevará el foco de vuelta a la página web después de que se haya
accedido a todos los ítems del Flash. Los navegadores corrientes con ver-
siones anteriores del programa Flash, sin embargo, no tienen esta
funcionalidad.
Aquellos que usen Mozilla, Netscape 7 u Opera se darán cuenta de
que se salta el contenido Flash completo cuando se navega con la tecla
«Tab» (o las teclas Q y A en Opera). Para acceder a los elementos de la
presentación Flash con estos navegadores, el usuario debe utilizar el ratón
para pinchar en la presentación. A partir de ese momento, no le será posi-
ble navegar fuera de la presentación Flash sin usar el ratón.
Esto puede ser un aspecto a tener en cuenta para las personas con
discapacidades motoras que tienen que usar el teclado para navegar.
Podemos aliviar esto colocando sola la presentación en una página
web, de forma que no sea necesario navegar a otros ítems de la página.
Si la presentación comparte página web con otros elementos, podemos
hacer la presentación invisible para el navegador web o hacer inaccesibles
todos los botones de la presentación en el panel de Accesibilidad. No obs-
tante, ambas opciones hacen inaccesible la propia presentación desde el
teclado y sólo deben ser utilizadas si se proporciona una alternativa HTML
o si la presentación no contiene información o funcionalidad importantes.
Los usuarios interactúan con la presentación Flash usando botones.
Tal y como se ha mencionado anteriormente, los botones deben tener un
equivalente textual añadido en el panel de Accesibilidad o deben contener
texto en su interior para ser fiablemente accesibles. A menudo están pro-
gramados para mostrar contenido durante los estados de «sobre» y «de-
bajo» («over» y «down»). El programa Flash sólo enviará un único ítem
de texto al lector de pantalla desde los estados «over» o «down» de
un botón e ignorará cualquier ítem de texto, gráficos o «clip de pelí-
cula» adicionales. Los estados «over» y «down» pueden también ser dis-
parados con el teclado. Cuando el usuario tabula a un botón se muestra el
estado «over» y cuando presiona la barra espaciadora o la tecla de Intro
se activa el estado «down».
126
WEB PARA TODOS.p65 126 12/11/2007, 12:17

Cuando se usa el teclado para navegar por Flash, el ítem que está acti-
vo en ese momento o está enfocado por el teclado se mostrará rodeado
por un rectángulo amarillo, denominado en Flash «focusrect» («rectán-
gulo enfocado»). El rectángulo amarillo desaparece si se mueve el ratón
sobre la presentación Flash. El brillante rectángulo amarillo muestra cla-
ramente el botón o el ítem del formulario seleccionados, pero es tan
horrible que a menudo los desarrolladores lo desconectan colocando la
propiedad _focusrect como falsa. Si hacemos esto, es imperativo que
todos los botones tengan un estado «over» distinguible, de forma que el
usuario pueda diferenciar visualmente qué ítem de la presentación Flash
está enfocado.
Imagen 46.- El botón derecho muestra la propiedad «focusrect» activa.
Orden de tabulación y lectura
Puesto que Flash no se basa en código lineal como HTML, la navegación

y el orden de lectura de los ítems en una presentación Flash están deter-
minados, aproximadamente, por su distancia desde algún punto situado
en la esquina superior izquierda. En algunos casos, la maquetación de
objetos en el escenario puede hacer que la lectura y la tabulación funcio-
nen de forma lógica. Pero otras veces no. Podemos verificar el orden de
tabulación de los ítems usando el teclado, aunque sólo podremos verifi-
car el orden de lectura de los ítems de la presentación Flash con un
lector de pantalla. Si la presentación tiene una maquetación compleja,
podemos resolver el problema de tener que colocar los ítems en esa
teórica posición cerca de la esquina superior izquierda de la presenta-
ción, usando «ActionScript» para especificar un orden de tabulación y
lectura de los elementos de formulario, botón, texto y «clip de película»
dentro de la presentación Flash.
127
WEB PARA TODOS.p65 127 12/11/2007, 12:17

Para especificar un orden de tabulación o lectura, se tienen que cum-
plir dos condiciones:
1. TODOS los textos de la presentación deben ser primero definidos como

entrada o texto dinámico.
2. TODOS los símbolos (apariciones de cualquier símbolo) en la presen-
tación tienen que recibir un nombre de caso.
La primera condición presenta problemas para la mayoría de los

desarrolladores, puesto que se tienen que incluir los perfiles de fuente con
las entradas y el texto dinámico en el fichero «.swf» para que el texto
tenga bordes suavizados y sea escalable. Incrustar los perfiles de fuente
incrementa el tamaño del fichero de la presentación Flash. La segunda
condición puede resultar bastante difícil, ya que se tiene que seleccionar y
dar un nombre de instancia a cada objeto del escenario. Esto se hace
seleccionando el ítem del escenario y tecleando el nombre en la casilla
«nombre de instancia» en el panel de Propiedades.
Imagen 47. Opción «nombre de instancia» en el panel de Propiedades de Flash.
Se tiene que asignar un nombre de caso a los elementos creados

dinámicamente usando «ActionScript». Si alguna de estas condiciones no
se cumple, Flash volverá al modo de lectura por defecto. Estas condicio-
nes se aplican a todos los elementos que están en una presentación, inclu-
so aquellos que se muestran fuera del escenario y los que son invisibles.
Si queremos especificar un orden de tabulación de los elementos en la
presentación, tenemos que convertir todos los objetos de texto estáticos
en objetos de texto dinámicos. Ahora añadiremos la información del índice
128
WEB PARA TODOS.p65 128 12/11/2007, 12:17

de tabulación («tabIndex») en un marco de teclas («keyframe») en el mar-
co 1 de la presentación:
_root.Homepage.tabIndex = 1
_root.Contact.tabIndex = 2
_root.FirstName.tabIndex = 3
_root.LastName.tabIndex = 4
_root.SubmitButton.tabIndex = 5
Si estamos usando el Flash MX 2004 Profesional, podemos mostrar

una opción de orden de tabulación en el panel de Accesibilidad. Es mejor
especificar el orden de tabulación en el panel que utilizar ActionScript.
Para que esto funcione, TODOS los ítems de texto tienen que ser de-
finidos como entradas o texto dinámico, y se tiene que especificar un or-
den de tabulación para CADA UNO de los botones, «clip de películas» y
objetos de texto del escenario que hayamos establecido como accesible
en el panel de Accesibilidad. Si olvidamos aunque sólo sea uno, los lecto-
res de pantalla no tendrán en cuenta en absoluto el índice de tabulación
diseñado.
Otras técnicas y consideraciones de accesibilidad

Esconder contenido Flash no importante
Algunos contenidos de Flash, como los anuncios publicitarios («banner»)

añadidos o las decoraciones de las páginas, a menudo son innecesarios
para el contenido de la página. Debido a las limitaciones de la versión 6 y
anteriores del programa Flash, la inclusión de una presentación Flash en
una página web podría en muchos casos hacer el resto del contenido HTML
de esa página completamente inaccesible. Si el usuario final tiene instala-
da una versión antigua del programa Flash, el objeto de presentación Flash
de la página se mantendrá como foco del teclado en la presentación tan
pronto como se enfoque. Esto significa que los usuarios de teclado se
quedarán atascados en la presentación Flash y no podrán navegar los otros
elementos de la página. Para esconder el contenido no importante de Flash
tanto para los navegadores web como para los lectores de pantalla, ten-
129
WEB PARA TODOS.p65 129 12/11/2007, 12:17

dremos que añadir la opción WMODE con un valor de OPAQUE tanto para el
OBJECT como para las etiquetas EMBED de la página web que contiene
una presentación Flash.
<object ...>
<param name="wmode" value="opaque">
<embed wmode="opaque" ...>
</embed>
</object>
Esto conseguirá esconder de forma efectiva la presentación Flash para

el lector de pantalla y el teclado. Todavía será visible en la página, pero
cuando se navegue por ella el teclado se saltará el contenido del Flash y el
lector de pantalla actuará como si no estuviera. Usaremos esta técnica
sólo si la presentación no aporta contenido importante o si proporcionamos
una alternativa accesible para el contenido de la presentación. Si ésta sí
contiene información importante, o bien tendremos que mostrar la presen-
tación en una página web sólo para ella o bien incluiremos un vínculo para
descargarse la última versión del programa Flash e informaremos a los
usuarios de que necesitan usar esta versión.
Las versiones más actuales de Mozilla, Opera, y Netscape siempre
tratarán el contenido de Flash como si estuviera escondido y no permitirán
el acceso a él a través del teclado.
Como alternativa, podemos también desactivar la opción «Hacer la pre-
sentación accesible» en el panel de Accesibilidad de Flash. Cuando se
desactiva esta opción, el lector de pantalla identificará que hay un objeto
de Flash, pero no accederá a ningún contenido de la presentación. Los
usuarios de lectores de pantalla no podrán acceder a ninguno de los conte-
nidos o botones de la presentación. No obstante, si alguien no está usando
un lector de pantalla, sí que podrá acceder a los botones de la presenta-
ción Flash cuando tabule a través de ella y puede quedar atrapado en la
presentación Flash si usa una versión antigua del programa Flash.
En resumen, colocar el WMODE para opacar deshabilitará completa-
mente el teclado para acceder a los contenidos y botones para todos los
usuarios, en tanto que si desactivamos la opción de «Hacer accesible la
presentación» se notificará a los usuarios de lectores de pantalla que hay
130
WEB PARA TODOS.p65 130 12/11/2007, 12:17

una presentación Flash a la que no podrán acceder; sí vale que otros usua-
rios de teclado sí podrán navegar los botones de la presentación Flash.
Detección de lectores de pantalla
Quizás queramos proporcionar una interfaz u opciones de Flash diferentes

para los usuarios que utilizan lectores de pantalla. Por ejemplo, podemos
querer proporcionar botones adicionales o activar las características de lec-
tura por sí mismas cuando la persona que vea la presentación esté usando
un lector de pantalla. Se pueden detectar los lectores de pantalla mediante
el uso de ActionScript. La función Accessibility.isActive()devolverá «verda-
dero» («true») si se detecta un lector de pantalla capaz de acceder al
contenido Flash (actualmente sólo las versiones últimas de Windows-Eyes
y Jaws). Por ejemplo, podemos añadir:
if (Accessibility.isActive()) {
_root.selfVoicing.play();
}
AVISO: Puesto que hay un pequeño retraso entre que empieza la pre-
sentación y se detecta el lector de pantalla, Accessibility.isActive()puede
devolver un mensaje de «falso» durante los primeros momentos de eje-
cución de la presentación. La presentación Flash tiene que estar enfoca-
da para que esto funcione. Podemos resolver esto asociando el
ActionScript con un botón de la presentación Flash. El método para de-
tectar un lector de pantalla no detecta todos los lectores de pantalla.
Sólo detectará las versiones más recientes de lectores de pantalla que
soportan MSAA y tienen instalado el programa Flash 6+.
Este método es, por cierto, el único modo de detectar automáticamente

lectores de pantalla en la web. Si queremos proporcionar contenido alter-
nativo para los usuarios de lectores de pantalla, podemos utilizar una pre-
sentación Flash para detectar la presencia de un lector de pantalla y
redireccionarlo adecuadamente. No obstante, eso implica suponer que el
usuario tiene instalado el programa Flash (como hacen la mayoría de ellos).
Si el usuario no tiene Flash, no funcionará la detección y el usuario se
enfrentará a aspectos de accesibilidad adicionales. También debemos lle-
131
WEB PARA TODOS.p65 131 12/11/2007, 12:17

var cuidado de proporcionar contenido alternativo para los usuarios de lec-
tores de pantalla. El contenido alternativo debe mantenerse actualizado y
proporcionar la misma información y funcionalidad que el contenido no di-
rigido a lectores de pantalla. He aquí el código para redireccionar basado
en la presencia de un lector de pantalla:
if (Accessibility.isActive()) {
getURL(screenreaderpage.htm);
} else {
getURL(normalpage.htm);
}
Accesibilidad de los componentes de Flash
Hay disponible un conjunto de componentes interactivos de Flash en Flash

MX 2004, que podemos ver en la siguiente imagen:
Imagen 48-.- Componentes interactivos de Flash.
132
WEB PARA TODOS.p65 132 12/11/2007, 12:17

Los siguientes componentes permiten las opciones de accesibilidad
(como la navegación por teclado), aunque estas opciones no están habili-
tadas por defecto:
• Botón (button)
• Caja de verificación (check box)
• Botón de radio (radio button)
• Etiqueta (label)
• Entrada de texto (text input)
• Área de texto (text area)
• Caja de combo (combo box)
• Lista (list)
• Ventana (window)
• Alerta (alert)
• Rejilla de datos (data gris)
Para habilitar las características de accesibilidad de estos componen-

tes, utilizaremos el comando «enableAccessibility()». Por ejemplo, para in-
cluir las características de accesibilidad del componente «Botón», usare-
mos el siguiente código:
import mx.accessibility.ButtonAccImpl;
ButtonAccImpl.enableAccessibility();
Este código sólo necesita ser incluido una vez para cada tipo de com-
ponente y debería agregarse en el primer marco de la presentación.
Cuando usemos los componentes, debemos hacer un test para asegu-
rar que se ha logrado la accesibilidad.
Epilepsia fotosensible
Si la presentación Flash es estroboscópica o produce destellos, puede pro-

vocar un ataque epiléptico en las personas con propensión a ello. Por tan-
to, tenemos que evitar los elementos con destellos brillantes que se emitan
más de dos veces por segundo.
133
WEB PARA TODOS.p65 133 12/11/2007, 12:17

Áreas de pulsación (hit)
Un área de pulsación (hit) es un botón que no tiene nada en los estados
«arriba» («up»), «sobre» («over») o «debajo» («down»), pero tiene defini-
da una forma en el estado «pulsado» («hit»), lo que lo hace un botón invi-
sible pinchable. Estos botones de área de pulsación pueden colocarse en
la presentación para permitir la interacción, pero no se muestran de forma
visible al usuario. Habitualmente están situados encima del texto o los ele-
mentos gráficos, de forma que estos elementos parecen funcionar como
un botón, pero están separados del botón invisible. Son útiles para los
desarrolladores de Flash que quieren crear un botón «invisible» que pueda
usarse para interpretar «ActionScript», pero que de otra manera no mues-
tran nada. Sin embargo, los lectores de pantalla ignorarán completamente
los botones que no tengan algo en los estados de «up», «over» o «down»,
incluso si se proporciona texto alternativo («Nombre» y/o «Descripción»)
para el botón. Podemos solucionar esto colocando un elemento en uno de
esos tres botones de estado. Si queremos mantener el beneficio que pro-
porciona el botón «invisible», podemos colocar un símbolo de «clip de pe-
lícula» con alpha colocado en 0 en uno de los estados, lo que hace el
contenido invisible al ojo. Puesto que ahora el botón contiene algo, será
accesible para el lector de pantalla. Recordemos añadir alternativas tex-
tuales si son necesarias.
Vínculos al plug-in de Flash

Los estándares de accesibilidad requieren que, si se usa un plug-in, se
tiene que proporcionar un vínculo para que el usuario pueda descargarse
ese plug-in. Aunque este proceso está semi-automatizado en la mayoría
de los navegadores actualizados, aún así deberíamos proporcionar al usua-
rio un vínculo para que pueda descargarse la versión más reciente del
plug-in de Flash ANTES de que el contenido del Flash se presente en la
página web.
Uso del sonido en Flash

Si un usuario de lector de pantalla encuentra una presentación Flash que
usa sonido, puede resultarle difícil escuchar simultáneamente el lector y el
134
WEB PARA TODOS.p65 134 12/11/2007, 12:17

sonido del Flash. En la mayoría de casos, podemos proporcionar una op-
ción para que los usuarios conecten el sonido cuando acceden por primera
vez a un sitio o darles instrucciones antes de acceder a la presentación
sobre cómo desactivar el sonido (quizás a través de un atajo de teclado).
Si el sonido tiene que funcionar la primera vez que se descarga la presen-
tación, tendremos que proporcionar una opción para apagar el sonido como
primer elemento de navegación en la presentación Flash.
Tal y como mencionamos al principio de este libro, crear una presenta-
ción que se lea por sí misma es una opción muy viable para hacer Flash
accesible a los usuarios de lectores de pantalla.
Atajos de teclado (método abreviado)
Cuando hay un botón seleccionado en el escenario, se mostrará una op-

ción para Atajos (método abreviado) en el panel de Accesibilidad.
Imagen 49. Método abreviado en el panel de Accesibilidad de Flash.
Ello permite indicar al usuario qué tecla o secuencia de teclas se usa

para activar ese elemento Flash. Cuando especifiquemos el atajo de tecla-
do, pongamos los nombres de las teclas tales como «Ctrl» o «Alt». Utiliza-
remos letras mayúsculas para los caracteres alfabéticos y usaremos el sig-
no de suma (+) entre los nombres de las teclas, sin espacios. Por ejemplo,
«Ctrl+A». Especificar el nombre del atajo no activa el atajo de teclado; por
ello, será necesario programar un ActionScript adicional en la presentación
para capturar esa secuencia de teclado. Los atajos habitualmente sólo son
útiles en los botones o los objetos del «clip de película».
135
WEB PARA TODOS.p65 135 12/11/2007, 12:17

Hay que ser cuidadoso en la selección de los atajos de teclado. Debe-
mos realizar muchos test de usuario para verificar que los atajos de tecla-
do seleccionados no interfieren con la navegación normal o con la
funcionalidad de las tecnologías de apoyo. Puesto que los usuarios de lec-
tores de pantalla no usan habitualmente el ratón, hay muchos más atajos
de teclado para los lectores de pantalla que los que existen para los
navegadores web típicos.
Interacciones sólo con ratón
No debemos utilizar elementos interactivos en la presentación Flash que

requieran el uso del ratón. Los más habituales son «pinchar-arrastrar-sol-
tar» («drag-and-drop») y «doble clic». No existe alternativa de teclado para
estos actos. Los elementos de Flash, tales como barras de desplazamien-
to («scroll bars») y los «deslizadores» («sliders»), tienen que incluir una
funcionalidad que permita que puedan usarse mediante el teclado.
No debemos exigir tareas de motricidad fina para navegar la presenta-
ción. Tampoco mover los botones que el usuario puede querer seleccionar
y debemos asegurarnos de que los ítems de navegación tienen un tamaño
suficiente.
Control del tiempo por el usuario
Debemos dar al usuario el control sobre los cambios del contenido impor-
tantes y permitir que el usuario controle cuándo se presenta el contenido
nuevo. Las personas con discapacidades cognitivas o del aprendizaje pue-
den necesitar más tiempo para llevar a cabo una tarea o comprender una
parte del contenido. Un lector de pantalla tiene que tener tiempo suficiente
para completar la lectura del contenido de una sección antes de que cambie.
Escalar el contenido
Puesto que Flash está basado en vectores, puede cambiarse fácilmente de

tamaño y mantener su apariencia original. Los elementos vectoriales no es-
tán «pixelados» y pueden ampliarse infinitamente en la pantalla sin que pier-
dan su forma o calidad. Esta característica es muy útil para las personas
136
WEB PARA TODOS.p65 136 12/11/2007, 12:17

con baja visión. Cuando sea posible, debemos permitir que el contenido del
Flash se escale automáticamente a un valor porcentual del ancho y alto del
navegador, en lugar de especificar valores de píxel para el ancho y el alto.
Ello permite que pueda ampliarse el contenido si la página es ampliada con
navegadores y tecnologías de apoyo que permitan esta funcionalidad.
Entorno de creación de Flash
Debido a la naturaleza visual del entorno de creación de Flash, es casi

completamente inaccesible tanto para los lectores de pantalla como para
los usuarios de teclado. Aunque los ítems del menú, los paneles y las he-
rramientas de dibujo se muestran a los lectores de pantalla y puede
accederse a ellos a través del teclado, es imposible usar las herramientas
para añadir elementos al escenario Flash sin usar un ratón.
Pautas aplicables
Se aplican a Flash las siguientes Pautas WCAG 1.0:
Prioridad 1:
• 1.1 - Proporcione un equivalente textual para todo elemento no tex-
tual (por ejemplo, a través de «alt», «longdesc» o en el contenido
del elemento). Ello incluye imágenes, representaciones gráficas de
texto (incluyendo símbolos), regiones de mapas de imágenes, ani-
maciones (por ejemplo, GIFs animados), applets y objetos de pro-
gramación, ascii art, marcos, scripts, imágenes usadas como listas
de viñetas, espaciadores, botones gráficos, sonidos (mostrados con
o sin interacción del usuario), archivos de sólo sonido, bandas sono-
ras de vídeo y vídeos.
• 1.3 - Hasta que los agentes de usuario puedan leer automáticamente
en voz alta el equivalente textual de una banda visual, proporcione
una descripción sonora de la información importante de la banda
visual de una presentación multimedia.
• 1.4 – Para cualquier presentación multimedia basada en tiempo (por
ejemplo, una película o animación) sincronice con la presentación
137
WEB PARA TODOS.p65 137 12/11/2007, 12:17

alternativa equivalentes (por ejemplo, subtítulos o descripciones so-
noras de la banda visual).
Prioridad 3:
• 14.2 - Complemente el texto con presentaciones gráficas o sonoras
cuando ello mejore la comprensión de la página.
138
WEB PARA TODOS.p65 138 12/11/2007, 12:17

Verificando la accesibilidad
en páginas web
Los esfuerzos por hacer páginas web accesibles pueden resultar estériles
si no tenemos la posibilidad de verificar que nuestro trabajo se está reali-
zando correctamente. W3C/WAI nos proporciona, junto con el documento
normativo de las «Pautas de Accesibilidad al Contenido en la web 1.0»,
una tabla de verificación que nos puede ser útil para una revisión manual
del grado de cumplimiento con esta norma técnica. La versión en castella-
no de esta tabla de verificación la podemos encontrar en:
• http://usuarios.discapnet.es/disweb2000/WCAG2003/wcag10/full-checklist.html
• http://www.technosite.es/accesibilidad/recursos/documentos/wcag10/full-checklist.html
Realizar una revisión manual completa de los 65 puntos de verificación

(16 de Prioridad 1, 30 de Prioridad 2 y 19 de Prioridad 3) puede ser muy
tedioso y desalentaría al desarrollador.
Para facilitar esta tarea existen diferentes herramientas automáticas o
semi-automáticas que nos serán de gran utilidad. Pero, en cualquier caso,
la verificación manual será indispensable para alguno de los puntos de
verificación.
Verificando el código HTML y CSS
Si nos ajustamos a la normativa técnica para la codificación de nuestras

páginas, tanto en el código HTML como en el de las Hojas de Estilo, ten-
dremos gran parte del camino andado. Por ese motivo comenzamos con
la tarea de verificar dicha codificación.
Esta verificación, al tratarse de código, puede realizarse de forma to-
talmente automática y, para ello, la propia W3C ha desarrollado sendas
herramientas.
139
WEB PARA TODOS.p65 139 12/11/2007, 12:17

• Para el código HTML o XHTML: http://validator.w3.org
Imagen 50. Pantalla del validador HTML de W3C.
• Para el código CSS: http://jigsaw.w3.org/css-validator/
Imagen 51. Pantalla del validador de CSS de W3C.
La operación es tan sencilla como introducir el URI de la página u hoja

de estilo que queremos verificar y se nos proporcionará una respuesta con
los resultados de análisis. Si existen errores, se nos indica dónde y se nos
sugieren posibles modificaciones para su adecuación.
140
WEB PARA TODOS.p65 140 12/11/2007, 12:17

Imagen 52. Pantallas de resultados de las validaciones HTML y CSS.
Verificando la accesibilidad web con herramientas

automáticas
Hay diversas herramientas que de una manera automática, al menos para

algunos de los puntos de verificación de las WCAG 1.0, analizan la acce-
sibilidad de nuestra página web.
TAW, Test de Accesibilidad Web
El más conocido, en lengua castellana, es TAW, Test de Accesibilidad Web

(en mayo de 2005 se presentó su versión 3.0): www.tawdis.net.
Imagen 53. Logotipo del Test de Accesibilidad Web en su versión 3.
Esta herramienta ha sido desarrollada por la Fundación CTIC, que

mantiene la oficina W3C para España (ver: www.w3c.es), con el apoyo
económico de la Secretaría de Estado de Asuntos Sociales, Familia y
Discapacidad (a través del Centro Estatal de Autonomía Personal y Ayu-
das Técnicas).
141
WEB PARA TODOS.p65 141 12/11/2007, 12:17

El análisis de accesibilidad (de acuerdo a las WCAG 1.0) se puede
realizar a través de la web:
Imagen 54. Pantalla de la versión on-line de TAW.
También se puede realizar en modo local, descargando el programa

gratuito Taw3, que es ejecutable en distintas plataformas (Windows, MacOS
X, Linux, Solaris, AIX, HP-UX y Unix).
Imagen 55. Pantalla de la versión off-line de TAW.
Su sencillez de manejo (basta escribir el URI que deseamos analizar)

y las recomendaciones para corregir los defectos detectados, la hacen una
herramienta muy útil, incluso para aquellos que tengan poca experiencia
en temas de accesibilidad web.
142
WEB PARA TODOS.p65 142 12/11/2007, 12:17

Debemos dejar claro que, como todas las herramientas automáticas,
no es capaz de analizar absolutamente todos los puntos de verificación de
WCAG 1.0, por lo que debe complementarse con cierta revisión manual.
Al tratarse de una máquina, el ser humano es capaz de engañarla y gene-
rar «falsos positivos». De igual modo, genera también ciertos «falsos ne-
gativos», al interpretar la norma técnica de la forma más estricta. Por ello,
los verificadores que la utilicen deben ser conscientes de estas limitaciones
y saber que la verificación manual es inevitable.
Examinator
Desarrollada por Carlos Benavídez en Argentina, esta herramienta «en lí-

nea» de evaluación de la accesibilidad web proporciona información al
desarrollador sobre grado de cumplimiento de los criterios en la página
analizada, proporcionándole una puntuación (de 0 a 10) y un completo
informe sobre el estado de cada uno de los ítems analizados
Imagen 56. Logotipo de la herramienta de evaluación eXaminator.
Se encuentra en la dirección web: http://www.accesible.com.ar/

examinator/.
Imagen 57. Pantalla de la herramienta de evaluación eXaminator.
143
WEB PARA TODOS.p65 143 12/11/2007, 12:17

HERA
Otra herramienta de verificación automática (con idénticas limitaciones que

TAW) de la accesibilidad en castellano es HERA, desarrollada por Carlos
Benavídez para la Fundación SIDAR.
Imagen 58. Logotipo de la herramienta de evaluación HERA.
Esta herramienta presentó su segunda versión también en mayo de

2005 y está disponible en http://www.sidar.org/hera/.
Imagen 59. Pantalla de la herramienta de evaluación HERA.
En este caso, el análisis sólo se puede realizar a través de la web, sin

posibilidad de descarga en local.
Bobby - WebXACT
La más clásica de las herramientas automáticas de verificación de la ac-

cesibilidad web es Bobby, desarrollada en su día por CAST y más tarde
adquirida por la empresa Watchfire, que actualmente la comercializa. Está
144
WEB PARA TODOS.p65 144 12/11/2007, 12:17

íntegramente en inglés. En la actualidad, prestan un servicio de análisis
en la web de forma gratuita que, además de accesibilidad, también ana-
liza calidad y privacidad, bajo el nombre de WebXACT: http://
webxact.watchfire.com.
Imagen 60. Logotipo de la herramienta de evaluación WebXact.
También su manejo es sencillo, basta escribir el URI a analizar, y pre-

senta resultados muy completos, como hemos dicho, en materia de acce-
sibilidad, calidad y privacidad de la página analizada.
Imagen 61. Pantalla de la herramienta de evaluación WebXact.
Cynthia Says
Aunque con menos años, también en inglés, encontramos otra herramienta

con cierta trayectoria Cynthia Says de HiSoftware: http://www.cynthiasays.com.
Imagen 62. Logotipo de la herramienta de evaluación Cynthia Says.
145
WEB PARA TODOS.p65 145 12/11/2007, 12:17

También realiza el análisis a través de la web y con la misma facilidad
y limitaciones que se han apuntado en las restantes herramientas.
Imagen 63. Pantalla de la herramienta de evaluación Cynthia Says.
WAVE
Otra herramienta en inglés con cierta trayectoria es la desarrollada por

WebAIM bajo el nombre WAVE, actualmente en su versión 3.0, disponible
en: http://www.wave.webaim.org/wave/.
Imagen 64. Logotipo de la herramienta de evaluación Wave 3.0.
146
WEB PARA TODOS.p65 146 12/11/2007, 12:17

Imagen 65.Pantalla de la herramienta de evaluación Wave 3.0.
Además de la posibilidad de analizar páginas a través de la web, nos

permite descargar una barra de herramientas que realizará el análisis en
local, pero con conexión a la Red.
Imagen 66. Barra de la herramientas de evaluación Wave 3.0.
Torquemada
Para que todo no sean herramientas en inglés, podemos encontrar una en

italiano. Se trata de Torquemada, desarrollada por la Fundación Ugo Bor-
dón, que es miembro de W3C: http://www.webxtutti.it/testa.htm.
Imagen 67. Logotipo de la herramienta de evaluación Torquemada.
Su funcionamiento y limitaciones son similares a las anteriores herra-

mientas.
147
WEB PARA TODOS.p65 147 12/11/2007, 12:17

Imagen 68. Pantalla de la herramienta de evaluación Torquemada.
Insistimos en que no existe «la» herramienta automática que pueda

realizar una verificación completa y correcta de la accesibilidad web. Siem-
pre es imprescindible la participación humana con una verificación manual.
Verificando la accesibilidad con Dreamweaver 2004 MX
La herramienta de creación de Macromedia Dreamweaver 2004 MX pre-

senta una utilidad para ayudarnos en la verificación de la accesibilidad web
para las páginas que generemos con ella.
Imagen 69.- Utilidad de verificación de la accesibilidad en Dreamweaver.
148
WEB PARA TODOS.p65 148 12/11/2007, 12:17

Cuando hayamos editado nuestra página, podemos solicitar al pro-
grama que nos haga un informe sobre el estado de la misma con respec-
to a los criterios de accesibilidad tanto de la Sección 508 (Acta de Reha-
bilitación, USA), como de las WCAG 1.0 (de W3C/WAI). Para ello
seguiremos la ruta Archivo > Comprobar página > Comprobar accesi-
bilidad.
Los resultados, obtenidos automáticamente por el programa, se mues-
tran en la parte baja de la ventana de edición, bajo la pestaña Resulta-
dos, en un listado donde aparecen el nombre del archivo, la línea de códi-
go y una descripción de la eventualidad localizada, expresando si necesita
revisión manual o es un fallo detectado automáticamente.
Imagen 70. Panel de Resultados de la verificación de accesibilidad

en Dreamweaver.
No podemos afirmar la fiabilidad completa de esta utilidad para verifi-

car la accesibilidad web, pero, sin duda, se trata de una ayuda estimable
desde la herramienta de creación para lograr que el diseño web se haga
accesible.
Más información sobre cuestiones relacionadas con la accesibilidad en
el sitio de Macromedia la podemos encontrar, una parte de ella en caste-
llano, en: http://www.macromedia.com/es/help/accessibility.html.
La barra de herramientas de accesibilidad web de AIS

para Internet Explorer
A la hora de verificar la accesibilidad web, podemos citar como una herra-

mienta ágil y efectiva la barra de herramientas de accesibilidad web de
AIS.
149
WEB PARA TODOS.p65 149 12/11/2007, 12:17

Imagen 71. Barra de herramientas de accesibilidad web de AIS.
La barra de herramientas ha sido desarrollada por el equipo de

Accessible Information Solutions (AIS) del National Information and Library
Service (NILS), Australia y ha sido traducida por Technosite (Fundosa
Teleservicios, Fundación ONCE).
La barra de herramientas de accesibilidad web se ha desarrollado para
facilitar el examen manual de diversos aspectos de la accesibilidad de las
páginas web. Consiste en una serie de funciones para:
• identificar los componentes de una página web;

• facilitar el uso de aplicaciones en línea proporcionadas por terceros;
• simular la experiencia de diferentes tipos de usuarios;
• proporcionar enlaces a referencias y recursos de información adicio-
nales.
Esta barra de herramientas está diseñada para ser incorporada al

navegador Internet Explorer de Microsoft, por lo que será imprescindible
trabajar con él para realizar las verificaciones.
Veamos, de forma resumida, las opciones de verificación que nos ofrece
esta barra de herramientas (esta información ha sido extraída de la página
de documentación sobre esta herramienta del sitio de Technosite http://
www.technosite.es/software.asp):
Accessible Informations Solutions [ctrl + alt + 0]
Función Descripción
Accessible Information Enlaces a información sobre los servicios de AIS
Solutions (AIS)
Technosite Enlace a información sobre Technosite, empresa que ha
realizado la traducción y adaptación de esta barra de
herramientas.
Contactar con Technosite Enviar un mensaje a Technosite.
150
WEB PARA TODOS.p65 150 12/11/2007, 12:17

Opciones barra de • (Des)activar visualización teclas rápidas - Activar o
desactivar la visualización de las teclas de acceso
rápido en los botones.
• (Des)activar teclas rápidas - Activar o desactivar las
teclas de acceso rápido.
• (Des)activar visualización íconos en botones - Mostrar
u ocultar los iconos en los botones del menú.
• Actualizar barra de herramientas - Descargar la
versión más reciente del archivo de configuración del
servidor de NILS.
• Desinstalar - Información sobre cómo desinstalar la
barra de herramientas
Documentación barra Página de información sobre la funcionalidad de la barra
de herramientas de herramientas.
Acerca de - Barra de Información acerca de la versión de la barra de
herramientas accesibilidad herramientas y su desarrollo.
Actualizado: aaaa-mm-dd La fecha del archivo de configuración. La barra de
herramientas comprueba la disponibilidad de una
actualización cada siete días.
Validar [ctrl + alt + L]
Validador HTML del W3C Comprobar el código HTML de la página (o páginas)
• Validar HTML actual con el Validador HTML del W3C.
• Validar HTML Nota: Validar HTML (enviar el archivo), cuando se abre
(nueva ventana) un archivo HTML local, con el recuadro de diálogo
• Validar HTML Archivo/Abrir (no a través de un servidor web, por
(enviar el archivo) ejemplo, c:\ejemplo.html) en Internet Explorer, esta
opción envía el código HTML al validador de forma
automática.
Validador CSS del W3C Comprobar las definiciones CSS en la página actual
• Validar CSS de la con el Validador CSS del W3C.
página actual
• Validar CSS
(nueva ventana)
151
WEB PARA TODOS.p65 151 12/11/2007, 12:17

HTML Tidy del W3C Comprobar el código HTML de la página actual. Ofrece
• Comprobar / la opción de visualizar y/o descargar una versión de la
corregir HTML misma arreglada con la herramienta HTML Tidy.
• Comprobar /
corregir HTML
(nueva ventana)
Verificador de enlaces Comprobar los hipervínculos en uno o varios
W3C documentos HTML o XHTML con el Verificador de
• Verificar página actual enlaces W3C. Es útil para encontrar enlaces rotos, etc.
• Verificar página actual
(nueva ventana)
• Verificar páginas
vinculadas (nueva
ventana)
Validador HTML del WDG Comprobar el código HTML de la página o páginas
• Validar HTML actuales con el Validador HTML de WDG. Teclear
• Validar HTML código (nueva ventana) - Un enlace con la página del
(nueva ventana) validador WDG en la cual se puede insertar código
• Teclear código HTML en un formulario para su validación. Validar sitio
(nueva ventana) (nueva ventana) - Validar todas las páginas del sitio
• Validar páginas en que contiene la página actual.
marcos (nueva ventana)
• Validar sitio
(nueva ventana)
WDG Link Valet Verificar enlaces (hipervínculos) en uno o varios
• Comprobar páginas documentos HTML o XHTML. Es útil para encontrar
vinculadas enlaces rotos, etc., con el WDG Link Valet.
• Comprobar páginas
vinculadas
(nueva ventana)
Validador P3P del W3C Comprueba la existencia y validez de información de
privacidad en formato P3P.
Tamaño [ctrl + alt + T]

640 x 480 píxeles Cambiar el tamaño de la ventana actual del navegador a
640 píxeles de ancho y 480 de alto.
800 x 600 Cambiar el tamaño de la ventana actual del navegador a
152
WEB PARA TODOS.p65 152 12/11/2007, 12:17

1024 x 768 Cambiar el tamaño de la ventana actual del navegador a
Especificar alto y ancho Cambiar la ventana actual del navegador a unas
dimensiones definidas por el usuario.
Especificar alto y ancho > Enlace a una herramienta en línea, Screen Size Tester
Screen Size Tester para comprobar el tamaño de la pantalla e información
(nueva ventana) acerca de tamaños de pantalla para diferentes
navegadores, resoluciones de pantalla y plataformas.
CSS [ctrl + alt + S]
Activar y desactivar CSS Activar y desactivar las hojas de estilo externas.
Desactivar CSS en Suprimir el atributo ‘style’ (si existe) de todos los
elementos HTML elementos de la página actual.
Mostrar hojas de estilo En una ventana nueva, muestra todos los estilos
aplicadas asociados con el contenido actualmente debajo del
puntero del ratón.
Script de Simon Willison.
Mostrar hoja de estilo Muestra el contenido de la hoja de estilo vinculada con
la página actual (en una ventana nueva).
Verificar hojas de estilo Editar y aplicar estilos a la página actual de forma
dinámica (en ventana nueva)
Script de Simon Willison
HTML desaconsejado Mostrar los elementos de la página actual desaconseja-
dos en HTML 4.0. En la versión actual, no indica los
atributos desaconsejados.
Imágenes [ctrl + alt + 4]
Lista de imágenes Mostrar (en ventana nueva) una lista de imágenes con
el elemento <img> correspondiente. Desarrollado a partir
de un script de Lioren.
Intercambiar imagen y Sustituir los elementos <img> en la página actual con el
texto ALT contenido de sus atributos «alt» entre comillas. Si un
elemento <img> no lleva el atributo «alt» la imagen se
sustituye con el texto «NoAlt!»
153
WEB PARA TODOS.p65 153 12/11/2007, 12:17

Mostrar imágenes Mostrar un elemento <img> a lado de cada imagen
(junto con el valor del atributo «alt»; si la imagen no
lleva atributo «alt» se muestra el texto «¡Sin ALT!») y
pone un borde rojo a cada una.
Color [ctrl + alt + R]
Escala de grises Mostrar la página actual en blanco y negro.
Nota: no funciona con imágenes en formato PNG.
Colores empleados Mostrar (en ventana nueva) una lista de todos los
colores encontrados en el CSS asociado con la página
actual. Origen milov.nl.
Analizar contraste Abre el Analizador de contraste de colores de Juicy
Studio (en ventana nueva).
Estructura [ctrl + alt + 5]
Encabezados Muestra todos los elementos de encabezado en la
página actual.
Estructura de Muestra el título del documento, los encabezados (<h1>
encabezados a <h6> con sus contenidos) en ventana nueva. Basado
en una función de The Wave 3.5.
Ítems de listas Muestra los elementos de las listas ordenadas (<ol>),
no ordenadas (<ul>) y de definiciones (<dl>) de la
página actual.
Fieldset y label Muestra los elementos fieldset, legend y label de la
página actual. Muestra el atributo for de los elementos
label si existen, y el texto «¡Ningun For!» si este no
existe. Muestra el atributo ID (id=»») de cada control de
formulario si existe.
Acrónimos y abreviaturas Muestra los elementos <acronym> y <abbr>, y el valor
del atributo title, de la página actual.
AccessKey Muestra el valor del atributo accesskey en elementos de
la página actual.
154
WEB PARA TODOS.p65 154 12/11/2007, 12:17

Manejadores de eventos Muestra una advertencia al lado de cada elemento si
éste:
• lleva el atributo onmouseover sin el correspondiente
onfocus
• lleva el atributo onclick sin el correspondiente
onkeypress
• es un elemento select que lleva el atributo onchange
• lleva el atributo onfocus pero no puede recibir el foco
Muestra una burbuja informativa al lado de un
elemento si éste:
• lleva el atributo onmouseover con el correspondiente
onfocus
• lleva el atributo onclick con el correspondiente
onkeypress
El texto alt de cada icono burbuja contiene información
acerca de porque aparece.
TabIndex Muestra los atributos tabindex encontrados en los
elementos de la página actual.
Tabla de datos simple Muestra elementos <table>, <th> y <td> en la página
actual juntos con los atributos recomendados para el
etiquetado de tablas de datos simples (summary,
scope). Un atributo vacío indica que el atributo no se
emplea pero se recomienda.
Tabla de datos compleja Muestra elementos <table>, <th> y <td> en la página
actual juntos con los atributos recomendados para el
etiquetado de tablas de datos complejas (summary,
scope, <id>, <headers>). Un atributo vacío indica que el
atributo no se emplea pero se recomienda.
Bordes de tablas Muestra bordes en todas las tablas y celdas de la
página actual.
Orden de celdas de tabla Muestra el orden de lectura (con números) y bordes en
las celdas en la página actual.
Linearizar (desactivar Suprime todos los elementos <table>, <td> <tr>, <th> y
tablas) <div> en la página actual.
Bordes en marcos Muestra bordes en todos los elementos de marcos en la
página actual.
Nombre o título Muestra (en ventana nueva) una lista de páginas en
del marco marcos junto con el contenido de los atributos name y
title de cada elemento frame.
155
WEB PARA TODOS.p65 155 12/11/2007, 12:17

Mostrar DIVs Muestra el orden de tabulación (números) y bordes de
los elementos <div> de la página actual.
Mostrar otros elemento(s) Muestra un recuadro de entrada de texto de JavaScript
para permitir teclear el nombre de un elemento.
Entonces muestra otro diálogo para teclear un código de
color (rojo por defecto). Como resultado todas las
ocurrencias del elemento especificado en la página
actual llevarán bordes del color deseado. El color será
uno de los 16 definidos como palabra clave CSS aqua,
black, blue, fuchsia, gray, green, lime, maroon,
navy, olive, purple, red, silver, teal, white, y yellow.
Desarrollado a partir de un script en Centricle.
Utilidades [ctrl + alt + 7]
TAW (Test de Enviar el URL de la página actual a la herramienta de
Accesibilidad Web, comprobación de accesibilidad TAW (dos opciones:
español) ventana actual o nueva).
The Wave (inglés) Enviar el URL de la página actual a la herramienta de
comprobación de accesibilidad Wave (dos opciones:
ventana actual o nueva).
Torquemada (italiano) Enviar el URL de la página actual a la herramienta de
comprobación de accesibilidad Torquemada (dos
opciones: ventana actual o nueva).
Cynthia Says (inglés) Enviar el URL de la página actual a la herramienta de
comprobación de accesibilidad Cynthia Says (dos
opciones: ventana actual o nueva).
Bobby (inglés) Enviar el URL de la página actual a la herramienta de
comprobación de accesibilidad Bobby (dos opciones:
WCAG 1.0 (ventana nueva) o Sección 508 (ventana
nueva)). NOTA: Actualmente funciona en el mismo sitio
de Webxact.
156
WEB PARA TODOS.p65 156 12/11/2007, 12:17

Juicy Studio Tools • Enviar el URL de la página actual a la herramienta de
(inglés) comprobación de accesibilidad Juicy Studio:
Link Analyser (nueva ventana)
Image Analyser (nueva ventana)
Readabillity Test (nueva ventana)
• Abrir el Analizador de Contraste de Colores de Juicy
Studio (ventana nueva, en español).
• Abrir el Analizador de Accesibilidad CSS de Juicy
Studio (ventana nueva).
Webxact (inglés) Enviar el URL de la página actual a la herramienta de
comprobación de accesibilidad Webxact para comprobar
calidad, accesibilidad, y privacidad. (dos opciones:
ventana actual o nueva).
Ver código fuente Mostrar el código fuente de la página actual en Bloc de
notas.
Ver código fuente Mostrar el árbol del DOM de la página como HTML
generado (ventana nueva).
Ver código fuente parcial Mostrar el DOM del contenido seleccionado como
HTML y una copia del contenido seleccionado (ventana
nueva).
Guardar como HTML Abrir el recuadro de diálogo «Guardar como» del
navegador.
Utilidades > Simulaciones
Desactivar plugins Suprimir Applets Java, Flash, música de fondo, y
elementos iframe de terceros. Desarrollado a partir de
un script en Jesse’s Bookmarklets Site.
Desactivar el ratón Impide el acceso por parte del usuario a la funcionalidad
de la página actual mediante el ratón con el botón
secundario y eventos de selección (la versión actual no
deshabilita los eventos basados en mouseover o
onmouse). Cuando el usuario aprieta el botón secunda-
rio se muestra una advertencia.
Nota: el botón primario no se deshabilita.
157
WEB PARA TODOS.p65 157 12/11/2007, 12:17

Retinopatía diabética Coloca sobre la página actual una máscara en forma de
imagen para simular el efecto visual que experimentan
personas con Retinopatía diabética Nota: no se puede
interactuar con la página durante la simulación.
Cataratas Muestra la página borrosa para simular el efecto visual
experimentado por personas con Cataratas
Degeneración macular Coloca sobre la página actual una máscara en forma de
imagen (una oscura sombra redonda, semi-transparente
en su periferia) para simular el efecto visual que
experimentan las personas con Degeneración macular.
Se arrastra la sombra seleccionándola con el botón
primario del ratón. Nota: no se puede interactuar con la
página durante la simulación.
Glaucoma Coloca sobre la página actual una máscara en forma de
imagen (negra, con una zona transparente mas o menos
ovalada) para simular el efecto visual que experimentan
las personas con Glaucoma. Se arrastra la zona
transparente seleccionándola con el botón primario del
ratón. Nota: no se puede interactuar con la página
durante la simulación.
Daltonismo Coloca sobre la página actual una máscara en forma de
imagen que altera la paleta de colores de la página para
simular la paleta típica visible por una persona con
deficiencia de percepción de color rojo-verde. Nota: no
se puede interactuar con la página durante la simula-
ción. Esta funcionalidad está proporcionada por Q42.
Contraste reducido Coloca sobre la página actual una máscara en forma de

imagen que permite al usuario reducir la opacidad (30%,
60%, 90%) para simular la reducción en la sensibilidad
al contraste que ocurre progresivamente con la edad.
Esta funcionalidad está basada en la comprobación de
contraste de colores de Q42. Nota: no se puede
interactuar con la página durante la simulación.
Escala de grises Simulación de cómo se ve la página en una pantalla de
blanco y negro.
Lynx Viewer Abre la página actual (en ventana nueva) en el simulador
Lynx Lynx Viewer. Este servicio permite a los diseñadores
web ver una aproximación de cómo se presentarán sus
páginas en Lynx, un navegador modo texto.
158
WEB PARA TODOS.p65 158 12/11/2007, 12:17

Demo. imágenes Abre una ventana nueva con una demostración de
parpadeantes frecuencias de destello. Esta demostración ayuda a los
diseñadores a saber cuando los contenidos que diseñan
pueden provocar problemas para algunos usuarios
debido a la frecuencia de destello.
Información documento (Doc.) [ctrl + alt + 8]
Información página Muestra (en ventana nueva) información sobre la página
actual: titulo (<title>), tamaño de archivo, fecha de
creación, número de imágenes, enlaces, formularios,
scripts. Desarrollado a partir de un script en el sitio web
de Oregon State University.
Metadatos Muestra (en ventana nueva) una lista de todos los
elementos meta en la página actual, y su contenido.
Tamaño y tiempo de Muestra (en un recuadro de alerta) el tamaño del
descarga documento y el tiempo aproximado de descarga a
diferentes velocidades de transmisión. Desarrollado a
partir de un script en sam-i-am.com.
Informe tiempo de Envía el URL de la página actual al analizador en línea
descarga web Page Analyser (en ventana nueva) proporcionado
por websiteoptimazation.com.
Lista de marcos Muestra (en ventana nueva) una lista de los URLs de
las páginas en marcos y los nombres de los elementos
<frame>, de la página actual.
Lista de enlaces Muestra (en ventana nueva) una lista del URL, el
contenido y el valor del atributo <title> (si existe) de
cada enlace encontrado en la página actual.
Lista de enlaces a PDFs Muestra (en ventana nueva) una lista a de enlaces a
documentos PDF encontrados en la página actual.
Referencias (Ref.) [ctrl + alt + 9]

Esta sección contiene enlaces a recursos de información relevantes en la
web, tales como: Pautas de accesibilidad; recursos sobre accesibilidad y
usabilidad; y referencias de lenguaje.
159
WEB PARA TODOS.p65 159 12/11/2007, 12:17

IE [ctrl + alt + O]
Activar imágenes Activar y desactivar imágenes mediante el recuadro de
[ctrl + alt + I] diálogo de Internet Explorer > Herramientas > Opciones
de internet > Opciones avanzadas > Mostrar imágenes.
Activar JavaScript Activar y desactivar Javascript mediante el recuadro de
[ctrl + alt + J] diálogo de Internet Explorer > Herramientas > Opciones
de internet > Seguridad > Nivel personalizado >
Secuencias de comandos ActiveX.
Nota: Dado que mucha de la funcionalidad de la barra
de herramientas está basada en JavaScript, muchas
funciones no funcionarán mientras está deshabilitado
JavaScript.
Activar ActiveX Habilitar o deshabilitar ActiveX mediante el recuadro de
[ctrl + alt + A] diálogo de Internet Explorer > Herramientas > Opciones
de internet > Seguridad > Nivel personalizado > Ejecutar
controles y complementos ActiveX. Es útil para compro-
bar páginas con Flash, etc.
Opciones de Abrir el recuadro de diálogo de Internet Explorer >
accesibilidad Herramientas > Opciones de internet > Accesibilidad.
[ctrl + alt + D]
Activar CSS Activar y desactivar soporte CSS en Internet Explorer.
[ctrl + alt + C] Nota: Esta no es una función proporcionada por
Microsoft. Desactivar el soporte para CSS puede afectar
la apariencia de las ventanas y recuadros de diálogo
fuera de Internet Explorer que dependen del soporte
CSS. No olvide volver a habilitar el soporte para
CSS antes de cerrar el navegador. Si nota efectos
extraños abra IE y vuelva a habilitar CSS.
Tamaño de texto La misma funcionalidad que el menú de IE Ver >
Tamaño de texto. Se proporcionan atajos de teclado:
Menor (ctrl + alt + X), Mediana (ctrl + alt + Y), Mayor
(ctrl + alt + Z).
Tamaño de texto [ctrl + alt + M]
Tamaño de texto Ampliar y reducir el tamaño (25% a 600%) del contenido
de la página actual.
160
WEB PARA TODOS.p65 160 12/11/2007, 12:17

La barra de herramientas Web Developer para Firefox
Para el navegador Firefox de Mozilla existe una barra de herramientas si-

milar a la descrita en el apartado anterior. Se trata de una de las extensio-
nes gratuitas que se ofrecen para este navegador, denominada Web
Developer y desarrollada por Chris Pederick. La principal diferencia con la
barra descrita en el apartado anterior es que sólo está disponible en inglés
en el momento en se escribe este manual.
Imagen 72. Barra de herramientas Web Developer para Firefox.
Podemos encontrar y descargar esta herramienta en la dirección web

del sitio Mozilla: https://addons.mozilla.org/firefox/60/.
Información adicional sobre su instalación, funcionamiento y ayuda «en
línea» (todo ello en inglés) se puede encontrar en el sitio web de su
desarrollador en la dirección: http://chrispederick.com/work/webdeveloper/
documentation/.
161
WEB PARA TODOS.p65 161 12/11/2007, 12:17

162
WEB PARA TODOS.p65 162 12/11/2007, 12:17

Enlaces de interés
Para completar este texto, incluimos a continuación una lista de enlaces de

interés con información sobre los aspectos tratados en este documento.
Información general
• http://www.w3.org
Sitio del Consorcio Mundial de la Web, imprescindible referencia en
materia de normativa y desarrollo de la web (inglés).
• http://www.w3.ogr/WAI
Páginas de la Iniciativa de Accesibilidad en la Web con amplia informa-
ción sobre sus actividades y todos los documentos que elaboran, de
especial interés las WCAG 1.0 (inglés).
• http://www.technosite.es/recursos.asp
Páginas de Technosite (Fundosa Teleservicios) sobre recursos en ma-
teria de accesibilidad web, incluyendo las traducciones de las WCAG
1.0 y la barra de herramientas de accesibilidad web AIS (castellano).
• http://usuarios.discapnet.es/disweb2000/webaccesible/index.htm
Páginas sobre accesibilidad web en el sitio de Carlos Egea:
DisWeb2000. Información y acceso a la traducción de las WCAG 1.0,
incluyendo el formato PDF de las dos ediciones impresas (castellano).
• http://www.webaim.org
Sitio de la iniciativa Web Accessibility in Mind en la que podemos en-
contrar recursos, técnicas, artículos y material formativo sobre accesibi-
lidad web (inglés).
163
WEB PARA TODOS.p65 163 12/11/2007, 12:17

• http://diveintoaccessibility.org/
Mark Pilgrim escribió este didáctico manual de introducción a la accesi-
bilidad web, que ha sido traducido a algunos idiomas (inglés).
• http://www.ni4.org/
AFANIAS y el Instituto de Apoyo Empresarial mantienen esta web so-
bre “Navegación fácil” que toca la accesibilidad web desde el punto de
vista de la discapacidad intelectual. Han elaborado un protocolo de cum-
plimiento de criterios de accesibilidad web para este colectivo (castella-
no).
• http://www.sidar.org
Sitio de la Fundación SIDAR y de su Seminario Iberoamericano sobre
Discapacidad y Accesibilidad en la Red con mucha información sobre
el tema (castellano).
• http://accesibleweb.com.ar/default.htm
Andrea Stiparo mantiene, desde Argentina, este sitio con información
sobre accesibilidad web (castellano).
• http://www.webaccessibile.org/
Mucha información sobre accesibilidad web en este sitio italiano, pero
de fácil lectura por hispano parlantes (italiano).
• http://www.webxtutti.it
Sitio de la Fundación Ugo Bordoni con información, normativa y reco-
mendaciones de accesibilidad, incluyendo una herramienta de evalua-
ción (italiano).
• http://www.seraccesible.net/
Bitácora de Marco Giacomuzzi sobre accesibilidad en la web (castella-
no e italiano).
• http://www.webposible.com/
Sitio de Alejandro Gonzalo Bravo García con información, recursos y
artículos sobre accesibilidad web (castellano).
• http://ferguweb.tx.com.ru/
Bitácora de Fernando Gutiérrez Ferreira sobre temas de accesibilidad y
usabilidad en la web (castellano).
164
WEB PARA TODOS.p65 164 12/11/2007, 12:17

• http://www.jlvelazquez.net/
Otra bitácora que toca los temas de accesibilidad web. Ésta la mantie-
ne José Luís Velázquez (castellano).
• http://webmastercristiano.com/
Bitácora de Daniel Calisaya que toca, entre otros, temas de accesibili-
dad web (castellano).
Empresas españolas comprometidas

con la accesibilidad web
• http://www.technosite.es
Consultoría, estudios y diseño web accesible.
• http://www.accesibilidadweb.com/
Consultoría y diseño web accesible.
• http://www.acctiva.com
Asesoramiento y estudios sobre accesibilidad web.
• http://www.lotura.com
Diseño de sitios web accesibles.
• http://www.timon.com
Asesoramiento, diseño y estudios sobre accesibilidad web.
Recursos para deficiencia visual

• http://cidat.once.es
Web del Centro de Investigación, Desarrollo y Aplicación Tiflotécnica de
la ONCE.
• http://www.vialibre.es/catalogo_ortopedia/Page0001.asp
Catálogo de ayudas técnicas que distribuye TecnicAID, empresa del
grupo FUNDOSA.
• http://www.funcaragol.org/
Web de la Fundación Manuel Caragol con interesantes recursos
informáticos para personas ciegas y con deficiencia visual.
165
WEB PARA TODOS.p65 165 12/11/2007, 12:17

• http://www.catalogo-ceapat.org/
Catálogo de ayudas técnicas para personas con discapacidad del Cen-
tro Estatal de Autonomía Personal y Ayudas Técnicas del IMSERSO.
Herramientas para evaluar y validar la accesibilidad web
• http://www.tawdis.net
TAW: Verificador de sitios y páginas, incluye versión descargable (cas-
tellano).
• http://www.sidar.org/hera
HERA: Verificador de páginas (castellano).
• http://webxact.watchfire.com
BOBBY: Verificador de páginas gratuito en su versión web, de pago la
versión descargable (inglés).
• http://www.wave.webaim.org
WAVE: Herramienta de evaluación de páginas web (inglés).
• http://www.webxtutti.it/testa.htm
TORQUEMADA: Herramienta de evaluación de páginas web (italiano).
• http://www.technosite.es/software.asp
Páginas de Technosite (Fundosa Teleservicios) sobre recursos en ma-
teria de accesibilidad web, incluyendo la extensión Web Developer para
Firefox, la barra de herramientas de accesibilidad web AIS (castellano)
y una versión de evaluación de JAWS.
• http://www.visionaustralia.org.au/info.aspx?page=959
Analizador de Contraste de Color 1.0, descargable (castellano).
• http://www.wat-c.org/tools/CCA/1.1/
Analizador de Contraste de Color 1.1, descargable. Evolución del ante-
rior (inglés).
166
WEB PARA TODOS.p65 166 12/11/2007, 12:17

167
WEB PARA TODOS.p65 167 12/11/2007, 12:17

WEB PARA TODOS.p65 168 12/11/2007, 12:17

Diseño para Todos 2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Diseño para Todos 2

Caricato da

Copyright:

Formati disponibili

WEB PARA TODOS.

p65 1 12/11/2007, 12:17

WEB PARA TODOS.p65 3 12/11/2007, 12:17

Materiales elaborados por:

SOCIEDAD DEL CONOCIMIENTO

WEB PARA TODOS.p65 5 12/11/2007, 12:17

© UNED (Universidad Nacional de Educación a Distancia)

© Carlos Egea García

Colaboradores: Alicia Sarabia Sánchez

Coordinadora de la colección: Sara Osuna Acedo

ISBN: 978- 84-7426-957-4

Fotocomposición: Text Gràfic

Impreso en Romanyà/Valls, s.a.

WEB PARA TODOS.p65 6 12/11/2007, 12:17

CREANDO PÁGINAS WEB ACCESIBLES

Creando hojas de estilo en cascada accesibles . . . . . . . 19

Creando imágenes accesibles . . . . . . . . . . . . . . . . . . . . . . . . 31

WEB PARA TODOS.p65 7 12/11/2007, 12:17

Creando marcos (frames) accesibles . . . . . . . . . . . . . . . . . 59

Creando tablas accesibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Creando formularios accesibles . . . . . . . . . . . . . . . . . . . . . . 79

Creando JavaScript accesible . . . . . . . . . . . . . . . . . . . . . . . . 95

Creando contenido accesible con Flash de Macromedia 113

WEB PARA TODOS.p65 8 12/11/2007, 12:17

Verificando la accesibilidad en páginas web . . . . . . . . . . . 139

Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

WEB PARA TODOS.p65 9 12/11/2007, 12:17

El poder de la Web está en su universalidad.

WEB PARA TODOS.p65 11 12/11/2007, 12:17

WEB PARA TODOS.p65 12 12/11/2007, 12:17

La irrupción del servicio web a través de internet ha supuesto un cambio

WEB PARA TODOS.p65 13 12/11/2007, 12:17

Las frecuentes preguntas sobre cómo aplicar los criterios de accesibi-

WEB PARA TODOS.p65 14 12/11/2007, 12:17

WEB PARA TODOS.p65 15 12/11/2007, 12:17

Carlos Egea García

WEB PARA TODOS.p65 16 12/11/2007, 12:17

WEB PARA TODOS.p65 17 12/11/2007, 12:17

WEB PARA TODOS.p65 18 12/11/2007, 12:17

Durante años, la única manera de maquetar HTML con un aspecto atracti-

La fuerza de las CSS reside en su capacidad para separar el contenido

¿Qué son las hojas de estilo en cascada?

Las hojas de estilo en cascada, o CSS, permiten modificar las propieda-

WEB PARA TODOS.p65 19 12/11/2007, 12:17

¿Por qué se las llama «en cascada»?

Las Hojas de Estilo en Cascada aplican una jerarquía de importancia. El

WEB PARA TODOS.p65 20 12/11/2007, 12:17

Imagen 1. Jerarquía de la cascada de estilos.

WEB PARA TODOS.p65 21 12/11/2007, 12:17

El aspecto del control

Imagen 2. Vista de la página principal de Google con un navegador estándar.

WEB PARA TODOS.p65 22 12/11/2007, 12:17

Imagen 3. Vista de la página principal de Google con un navegador sólo texto.

El aspecto y sensación finales siempre han estado bajo control del

Usando CSS a nuestro favor

Tal y como hemos mencionado anteriormente, uno de los primeros benefi-

WEB PARA TODOS.p65 23 12/11/2007, 12:17

Sin los estilos, el sitio parece otro completamente diferente. La presen-

Alterando la maquetación alineada

WEB PARA TODOS.p65 24 12/11/2007, 12:17

El orden de lectura alineada de una página web es el orden literal del

Usando CSS oculto

He aquí un pequeño secreto: algunos sitios tienen un vínculo oculto al prin-

WEB PARA TODOS.p65 25 12/11/2007, 12:17