Diseño para Todos 1

DISEÑO WEB PARA TOD@S I
Carlos Firmado digitalmente por

Carlos Egea García
Nombre de reconocimiento
Egea
(DN): cn=Carlos Egea García,
o=Consultores Sociales
CEyAS sl., ou=Director,
email=carlos@ceyas.es, c=ES
García Fecha: 2007.11.08 19:22:25

+01'00'
diseño para todos.p65 1 08/11/2007, 12:17

PROGRAMA MODULAR EN
TECNOLOGÍAS DIGITALES Y SOCIEDAD DEL CONOCIMIENTO
DISEÑO WEB
PARA TOD@S I
ACCESIBILIDAD AL CONTENIDO EN LA WEB
Materiales elaborados por:

CARLOS EGEA GARCÍA
Con la colaboración de:
JUAN CARLOS RAMIRO IGLESIAS
ALICIA SARABIA SÁNCHEZ
SOCIEDAD DEL CONOCIMIENTO

Diseño de la cubierta: Carmen Rosa Redondo
© UNED (Universidad Nacional de Educación a Distancia)
© Carlos Egea García
Colaboradores: Juan Carlos Ramiro Iglesias y 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-630-6
Depósito legal: B-22.024-2007
Fotocomposición: Text Gràfic
Impreso en Romanyà/Valls, s.a.

Verdaguer, 1, Capellades (Barcelona)

ÍNDICE
Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Primera parte
DISEÑAR PARA TODOS
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Un acercamiento a la discapacidad . . . . . . . . . . . . . . . . . . . . . 14
Discapacidad y accesibilidad a las tecnologías digitales . . . . 17
Problemas de accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Problemas de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Elementos de los terminales de acceso . . . . . . . . . . . . . . . . . 26
Interfaz hombre máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Ordenadores e internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Accesibilidad en la web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
La accesibilidad en la web es importante . . . . . . . . . . . . . . . . 36
Las vertientes de la accesibilidad en la web . . . . . . . . . . . . . . 36
El Consorcio Mundial de la Web (W3C) . . . . . . . . . . . . . . . . . 38
La Iniciativa de Accesibilidad en la Web (WAI) . . . . . . . . . . . . 38
Las pautas para la accesibilidad en la web . . . . . . . . . . . . . . . 39
Legislación y otras normas en materia de accesibilidad

en la web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Legislación y otras normas en España . . . . . . . . . . . . . . . . . . 41
Otras normas internacionales . . . . . . . . . . . . . . . . . . . . . . . . . 44

Las herramientas de creación o de autor . . . . . . . . . . . . . 49
Accesibilidad en las herramientas de creación
más conocidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Las aplicaciones o agentes de usuario . . . . . . . . . . . . . . . 69

Accesibilidad en las aplicaciones de usuario más comunes . . 72
Aplicaciones de usuario alternativas . . . . . . . . . . . . . . . . . . . . 97
Las pautas de accesibilidad al contenido en la web

1.0 de w3c/wai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
¿Qué son las pautas de accesibilidad al contenido . . . . . . . .
en la web? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
¿Qué son las «prioridades», los «niveles de adecuación»? . . 104
¿Por qué son necesarias estas pautas? . . . . . . . . . . . . . . . . . 105
Algunos ejemplos de barreras habituales . . . . . . . . . . . . . . . . 105
en las páginas web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
¿Cómo se presentan las pautas? . . . . . . . . . . . . . . . . . . . . . . 106
PAUTA 1. Proporcione alternativas equivalentes para
el contenido visual y auditivo . . . . . . . . . . . . . . . . . . . . . . . 106
PAUTA 2. No se base sólo en el color . . . . . . . . . . . . . . . . . 107
PAUTA 3. Utilice marcadores y hojas de estilo y hágalo
apropiadamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
PAUTA 4. Identifique el idioma usado . . . . . . . . . . . . . . . . . 108
PAUTA 5. Cree tablas que se transformen correctamente . 109
PAUTA 6. Asegúrese de que las páginas que incorporan
tecnologías digitales se transformen correctamente . . . . . . 109
PAUTA 7. Asegure al usuario el control sobre los cambios
de los contenidos tempo-dependientes . . . . . . . . . . . . . . . . 110
PAUTA 8. Asegure la accesibilidad directa de las interfaces
de usuario incrustadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
PAUTA 9. Diseñe para la independencia del dispositivo . . . 110
PAUTA 10. Utilice soluciones provisionales . . . . . . . . . . . . . 111
PAUTA 11. Utilice las tecnologías y pautas W3C . . . . . . . . . 112
PAUTA 12. Proporcione información de contexto y
orientación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
PAUTA 13. Proporcione mecanismos claros de navegación 113

PAUTA 14. Asegúrese de que los documentos sean claros
y simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Segunda parte
CODIFICACIÓN HTML Y CSS
Codificación HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

HTML, SGML, XHTML, XML... . . . . . . . . . . . . . . . . . . . . . . . . 117
SGML y HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
SGML y XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
XML y XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Definición de tipo de documento . . . . . . . . . . . . . . . . . . . . . . . 121
Sintaxis de HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Etiquetas HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Atributos HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Atributos de eventos en HTML . . . . . . . . . . . . . . . . . . . . . . . . 129
¿Qué es CSS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

CSS soluciona problemas comunes . . . . . . . . . . . . . . . . . . . . 131
Las hojas de estilo ahorran trabajo . . . . . . . . . . . . . . . . . . . . . 132
Múltiples hojas de estilo en una. . . . . . . . . . . . . . . . . . . . . . . . 132
Sintaxis de CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Tercera parte
HACER UNA BITÁCORA ACCESIBLE
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Primeras instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Paso 1. ¿Para quién es la accesibilidad web? . . . . . . . . . 141
Paso 2. Elegir un DOCTYPE . . . . . . . . . . . . . . . . . . . . . . . . . 144
Paso 3. Identificar el idioma . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Paso 4. Elegir un título significativo . . . . . . . . . . . . . . . . . . . 147

Paso 5. Ayudas adicionales a la navegación . . . . . . . . . . 149
Paso 6. Colocar primero el contenido principal . . . . . . . . 150
Paso 7. El uso de los colores . . . . . . . . . . . . . . . . . . . . . . . . 153
Paso 8. Vínculos reales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Paso 9. Vínculos correctos y con títulos . . . . . . . . . . . . . . 158
Paso 10. Atajos de teclado . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Paso 11. No abrir nuevas ventanas . . . . . . . . . . . . . . . . . . . 163
Paso 12. Acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Paso 13. Tablas accesibles . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Paso 14. Usar listas reales . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Paso 15. Equivalente textual para imágenes . . . . . . . . . . 172
Paso 16. Atributo «alt» vacío . . . . . . . . . . . . . . . . . . . . . . . . . 175
Paso 17. Mapas de imagen accesibles . . . . . . . . . . . . . . . 177
Paso 18. Líneas horizontales . . . . . . . . . . . . . . . . . . . . . . . . . 180
Paso 19. Tamaños de fuente relativos . . . . . . . . . . . . . . . . 182
Paso 20. Encabezados correctos . . . . . . . . . . . . . . . . . . . . . 184
Paso 21. Verificar la accesibilidad . . . . . . . . . . . . . . . . . . . . 186
Anexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Web recomendadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Navegadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Información general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Empresas españolas comprometidas con
la accesibilidad web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Recursos para deficiencia visual . . . . . . . . . . . . . . . . . . . . . . . 195
Herramientas para evaluar y validar la accesibilidad web . . . 196

Prólogo
En este libro se recogen los materiales relativos a la primera parte

módulo «Diseño para tod@s» del Programa Modular en Tecnologías
Digitales y Sociedad del Conocimiento de la Universidad Nacional a Dis-
tancia (UNED).
El documento consta de tres partes:
1. «Diseñar para todos», con información general sobre la discapacidad,

las tecnologías digitales y cómo afectan a las personas con discapacidad,
la accesibilidad en la web y su normativa, las herramientas de creación
y las aplicaciones de usuario, así como el contenido de las «Pautas de
Accesibilidad al Contenido en la Web 1.0» de W3C/WAI.
2. «Codificación HTML y CSS», en la que se trata de realizar un acerca-
miento a la codificación de los lenguajes básicos de marcado (HTML y
CSS), sin los cuales es difícil comprender ciertas operaciones necesa-
rias para diseñar de forma accesible un documento web. La frecuente
utilización de herramientas de creación de páginas web que facilitan al
autor una presentación de los contenidos de forma visual, sin necesi-
dad de tocar el código subyacente, ha provocado entre los nuevos
diseñadores un general desconocimiento de las bases de codificación.
Claro exponente de este tipo de herramientas son los editores
Dreamweaver (de Macromedia) o FrontPage (de Microsoft), dos de los
más usados en la actualidad. Lo mismo ocurre con otras muchas herra-
mientas del tipo «gestor de contenidos» que, si bien facilitan la edición
y mantenimiento de los contenidos de los sitios web, no facilitan el con-
tacto con el código a las personas que las manejan.
3. «Hacer una bitácora accesible», que servirá de documento de sopor-
te para las posibles prácticas que se pueden desarrollar con los gesto-
res de contenido.

La finalidad de este documento es meramente didáctica y no tiene
pretensiones normativas o técnicas más allá de las relativas a la enseñan-
za de contenidos sobre accesibilidad en la web.
El autor de los materiales asume todas las responsabilidades deriva-
das de la necesaria interpretación de determinados aspectos que hoy día
se encuentran en fase de discusión y desarrollo en torno a este tema.
Carlos Egea García

Enero de 2007
10

Primera parte
DISEÑAR PARA TOD@S
11

12

Introducción
Sin lugar a dudas, los innumerables avances tecnológicos de los últimos

años han propiciado que nos veamos inmersos en una sociedad completa-
mente nueva, que está siendo denominada «Sociedad de la Comunicación
y la Información». Las connotaciones emergentes de esta nueva sociedad
hacen que, expandida hasta el último rincón del planeta, afecte en mayor o
menor medida a toda la población presente en él.
No obstante, esta enorme revolución está creando al mismo tiempo
una gran brecha social, que se ha venido a llamar «brecha digital». La
riqueza de cada país, su grado de desarrollo económico, las creencias
religiosas y el nivel cultural de su población influyen de manera decisiva
en la posibilidad de los ciudadanos de acceder a esta última revolución
social. No podemos dejar de observar que el tremendo potencial que
desarrollan las tecnologías digitales está incidiendo claramente en el cre-
cimiento de los países enmarcados en las sociedades avanzadas, al mis-
mo tiempo que los países en vías de desarrollo se encuentran en des-
ventaja para acceder a esta «Sociedad de la Comunicación y la
Información».
Las nuevas discriminaciones que esta sociedad nos presenta se ven
acentuadas en las denominadas «grandes minorías», existentes en todos
los países, con especial incidencia en la «gran minoría» de personas con
discapacidades presente en el mundo, a la que podríamos añadir el con-
junto de personas de la llamada «tercera edad». Las carencias y proble-
mas de accesibilidad a los medios físicos de entrada y salida de informa-
ción en los nuevos elementos tecnológicos, así como al contenido de la
información, hacen que un número considerable de personas con
discapacidad y personas mayores se encuentren inmersas en la brecha
digital, que entran de lleno en un riesgo evidente de «infoexclusión». De
este modo, el esfuerzo por lograr que las tecnologías digitales sean ac-
13

cesibles, tanto en su apartado físico como en el contenido, debe conside-
rarse como una necesidad incuestionable para eliminar este riesgo. Los
conceptos presentes en las líneas del «Diseño web para tod@s» deben
encontrarse necesariamente en cualquier desarrollo tecnológico para los
nuevos sistemas de acceso a la sociedad de la información, así como en
la elaboración de contenidos, con el fin de lograr la plena accesibilidad
universal.
La Organización Mundial de la Salud señala en sus informes que ac-
tualmente existen en el mundo entre 500 y 600 millones de personas con
discapacidad. En este contexto, el acceso a la formación y la educación en
tecnologías digitales de las personas con discapacidad constituye un factor
esencial para la integración y no discriminación de millones de personas.
Sólo accediendo en igualdad de condiciones y al mismo ritmo se puede
lograr que ninguna persona con discapacidad se vea relegada en la Socie-
dad de la Comunicación y la Información.
Un acercamiento a la discapacidad
La Organización Mundial de la Salud, a través de la Clasificación Interna-

cional del Funcionamiento, de la Discapacidad y de la Salud (CIF) del año
2001, define la discapacidad como «término genérico que incluye déficits,
limitaciones en la actividad y restricciones en la participación. Indica los
aspectos negativos de la interacción entre un individuo (con una ‘condición
de salud’) y sus factores contextuales (factores ambientales y persona-
les)». Explica los términos contenidos en la definición de la siguiente ma-
nera:
Condición de salud: «es un término genérico que incluye enfermedad

(aguda o crónica), trastorno, traumatismo y lesión. [...] Puede incluir
también otras circunstancias como embarazo, envejecimiento, estrés,
anomalías congénitas o predisposiciones genéticas.»
Deficiencia: «es la anormalidad o pérdida de un estructura corporal o
de una función fisiológica. Las funciones fisiológicas incluyen las funcio-
nes mentales. Con ‘anormalidad’ se hace referencia, estrictamente, a
una desviación significativa respecto a la norma estadística establecida
14

(por ejemplo, la desviación respecto a la media de la población obteni-
da a partir de normas de evaluación estandarizadas) y sólo debe usar-
se en este sentido.»
Limitaciones en la actividad: «son las dificultades que un individuo
puede tener para realizar actividades. [...] Abarca desde una desviación
leve hasta una grave en términos de cantidad o calidad, en la realiza-
ción de la actividad, comparándola con la manera, extensión o intensi-
dad en que se espera que la realizaría una persona sin esa condición
de salud.»
Restricciones en la participación: «son los problemas que puede ex-
perimentar un individuo para implicarse en situaciones vitales. La pre-
sencia [...] viene determinada por la comparación de la participación de
esa persona con la participación esperable de una persona sin
discapacidad en esa cultura o sociedad.»
Factores contextuales: «son los factores que constituyen, conjunta-
mente, el contexto completo de la vida de un individuo, y en concreto el
trasfondo sobre el que se clasifican los estados de salud en la CIF. Los
factores contextuales tienen dos componentes: factores ambientales y
factores personales.»
Factores Ambientales: «[...] se refieren a todos los aspectos del mun-
do extrínseco o externo que forman el contexto de la vida de un indivi-
duo, y como tal afecta el funcionamiento de esa persona. [...] Incluyen
al mundo físico natural con todas sus características, el mundo físico
creado por el hombre, las demás personas con las que se establecen o
asumen diferentes relaciones o papeles, las actitudes y valores, los ser-
vicios y sistemas sociales y políticos, y las reglas y leyes.»
Factores Personales: «son los factores contextuales que tienen que
ver con el individuo como la edad, el sexo, el nivel social, experiencias
vitales, etc...»
Facilitadores: «son todos aquellos factores en el entorno de una per-
sona que, cuando están presentes o ausentes, mejoran el funciona-
miento y reducen la discapacidad. Entre ellos se incluyen aspectos ta-
les como que el ambiente físico sea accesible, la disponibilidad de
tecnología asistencial adecuada [...]. Los facilitadores pueden prevenir
que un déficit o limitación en la actividad se convierta en una restricción
en la participación, puesto que contribuyen a mejorar el rendimiento
15

real al llevar a cabo una acción, con independencia del problema que
tenga la persona respecto a la capacidad para llevar a cabo dicha ac-
ción.»
Barreras: «son todos aquellos factores en el entorno de una persona
que, cuando están presentes o ausentes, limitan el funcionamiento y
generan discapacidad.»
Esta clasificación parte de un enfoque sustancialmente diferente del

que mantenía su predecesora, la Clasificación Internacional de Deficien-
cias, Discapacidades y Minusvalías (CIDDM) del año 1980, que definía los
términos básicos del siguiente tenor:
Deficiencia: «toda pérdida o anormalidad de una estructura o función

psicológica, fisiológica o anatómica.»
Discapacidad: «toda restricción o ausencia (debida a una deficiencia)
de la capacidad de realizar una actividad en la forma o dentro del mar-
gen que se considera normal para un ser humano.»
• Minusvalía: «una situación desventajosa para un individuo determina-
do, consecuencia de una deficiencia o de una discapacidad, que limita
o impide el desempeño de un rol que es normal en su caso (en función
de la edad, sexo y factores sociales y culturales).»
Como podemos observar, el cambio conceptual entre una y otra clasi-

ficación es muy importante. Si en la del año 1980 el problema se centraba
en el individuo (que era quien «padecía» la deficiencia, la discapacidad y
la minusvalía), en la CIF el enfoque pasa a incluir el contexto como ele-
mento esencial que «produce» una discapacidad si carece de facilitadores
que ayuden a superar la limitación en la actividad o interpone barreras que
restrinjan el funcionamiento.
Desde esta perspectiva, no es el individuo el que debe adaptarse, si
no quiere quedarse al margen de la sociedad, a los estándares de la po-
blación general, sino que el medio físico natural, el mundo físico creado
por el hombre, las demás personas con las que se establecen o asumen
diferentes relaciones o papeles, las actitudes y valores, los servicios y sis-
temas sociales y políticos, y las reglas y leyes, en suma, el contexto, han
de estar preparados para un acceso universal.
16

Discapacidad y accesibilidad a las tecnologías digitales
La diversidad funcional en el ser humano es enorme. Cada uno de noso-

tros goza de unas capacidades concretas y puede o no realizar determina-
das actividades, no sólo según el modo habitual de llevarlas a cabo por la
generalidad de la población, sino también siguiendo cauces alternativos de
funcionalidad.
En este contexto, las personas con discapacidad presentan una serie
de limitaciones para el acceso a los estándares normalizados de la Socie-
dad de la Información y la Comunicación, los cuales se convierten en ba-
rreras que impiden la accesibilidad a los medios de los que ésta se dota.
Así, las personas que carecen de visión no podrán acceder a los con-
tenidos visuales sin tecnologías supletorias y aquellas con visión escasa
precisarán tecnologías complementarias y de apoyo; las personas con dé-
ficit auditivo tendrán que ver compensada la privación en el acceso a los
medios y contenidos sonoros mediante dispositivos y opciones alternati-
vas. Las personas con dificultades motrices en sus miembros superiores
necesitarán dispositivos alternativos o adaptados y las personas con limita-
ciones intelectuales tendrán que disponer de software y contenidos que se
adecuen a sus características.
Pero todo ello debe cumplir unos estándares que aseguren, por una
parte, que la accesibilidad es real y, por otra, la compatibilidad de formatos
de forma que la información sea realmente comunicable, lo cual es el fun-
damento de la Sociedad de la Comunicación y la Información.
17

18

Problemas de accesibilidad
Para algunas personas con limitaciones funcionales (visuales, motoras,

auditivas o cognitivas) no es suficiente que existan en el mercado elemen-
tos físicos de acceso a las prestaciones que nos proporcionan las tecnolo-
gías digitales, ni que éstas estén repletas de información y servicios. Es
necesario además que tanto el elemento físico como el lógico (hardware y
software) sean accesibles en su manejo y en el contenido que ofrecen.
Las deficiencias de cada persona hacen que las dificultades y necesida-
des sean muy variadas. Por ello, en este apartado vamos a hacer un repaso
a los principales problemas que las personas con discapacidad encuentran
en cada uno de los aspectos relacionados con las tecnologías digitales.
Podemos englobar en tres grandes líneas las principales dificultades
que encuentran las personas con discapacidad en su relación con las tec-
nologías digitales:
– Posibilidad de manejo o acceso a los elementos físicos que nos

proporcionan las tecnologías digitales. Se trata de los conocidos como
terminales, entre los cuales podemos citar teléfonos, ordenadores, ca-
jeros automáticos o la televisión digital.
– Posibilidad de efectuar una interacción con las interfaces presen-
tes en cada medio. Las interfaces suelen estar compuestas de menús,
barras de navegación, botones y otros elementos estructurales que de-
ben adecuarse a pautas de Diseño web para tod@s con el fin de lograr
su accesibilidad.
– Posibilidad de acceder a los contenidos que nos presentan los ter-
minales, que cada vez van siendo mayores y más complejos. Hoy día
las tecnologías digitales nos permiten sacar una entrada para el cine,
manejar nuestros datos bancarios o realizar algunos trámites legales o
administrativos.
19

Problemas de acceso
Terminales de acceso
Acceder a las tecnologías digitales a través de los terminales de acceso

supone el primer gran problema para gran número de personas con limita-
ciones funcionales, debido principalmente a que no han sido diseñados en
base a los principios de accesibilidad universal. La imposibilidad o dificul-
tad en el manejo de los terminales supone dejar fuera de los servicios
prestados por las tecnologías digitales a un porcentaje de la población.
¿Qué ocurre si una persona con discapacidad física no puede marcar las
teclas de un teléfono móvil debido a su diseño? ¿Podrá establecer una
comunicación? ¿Podrá acceder a internet a través de él?
Hay una variedad muy grande de terminales, si bien la tendencia es a
reducirlos y acceder a todos los servicios a través de unos pocos, princi-
palmente el teléfono móvil, el ordenador y muy pronto nuestra pantalla de
televisión digital. Vamos a hacer un repaso escueto de los problemas de
accesibilidad que se presentan para algunas personas con discapacidad.
Teléfonos móviles
Desde los primeros teléfonos móviles hasta ahora se ha producido una

significativa evolución, tanto en sus funciones como en su diseño. Paradó-
jicamente, los primeros terminales eran mucho más accesibles que ahora,
debido principalmente al tamaño de las teclas. Hoy día, dependiendo de la
tecnología incorporada al móvil, hay mucha diferencia entre modelos. El
terminal que lleva tecnología WAP (Wireless Application Protocol, Protoco-
lo de Aplicación de Telefonía Inalámbrica) resulta más complejo en su
manejo debido principalmente a que incorpora un mayor número de opcio-
nes que uno con sistema GPS (Global Possitioning System, Sistema de
Posicionamiento Global). Los llamados de tercera generación o UMTS (Uni-
versal Mobile Telecommunications System, Sistema Universal de Teleco-
municaciones Móviles) cambian completamente en el manejo de la interfaz
al diseñarse con pantallas táctiles.
El mayor problema en los terminales que usan tecnología GSM y WAP
lo constituye su tamaño, cada vez más pequeño y, por consiguiente, las
reducidas dimensiones de los botones que permiten su manejo. De este
20

modo, las personas con deficiencias físicas graves o severas y con proble-
mas de destreza encuentran muchas dificultades en su uso, y en algunos
casos les resulta imposible utilizarlos. Del mismo modo, la reducción del
tamaño del terminal hace que las dimensiones de la pantalla también sean
menores, el texto que aparece es pequeño y, para las personas con dificul-
tad en la visión, su uso queda muy restringido. Para las personas invidentes
resulta imposible su manejo si no disponen de teclas resaltadas y lector de
pantalla para los mensajes que aparecen en ella. Algo parecido ocurre con
las personas que tienen deficiencias auditivas, al ser difícil y limitado el
control de voz y del timbre. Con la introducción de la tecnología UMTS
probablemente algunos de estos problemas puedan solucionarse, si los
fabricantes incorporan la posibilidad de modificar tipo y tamaños de los
caracteres que aparecen en pantalla. Aspecto éste importante si funcionan
con pantallas táctiles, para que pueda facilitarse su manejo si se tiene falta
de precisión o problemas de destreza.
Actualmente, existen terminales que hacen uso del reconocimiento de
voz. Pero su tecnología está aún por depurar, tanto en su funcionamiento
como en su diseño. En cualquier caso, es necesario incorporar los
parámetros de diseño universal en su fabricación si queremos que todas
las personas con discapacidad puedan hacer uso de todos los servicios
que van a ofrecer.
Teléfonos fijos
Un caso muy distinto lo constituyen los teléfonos fijos, que incluimos en

este apartado de tecnologías digitales al incorporar cada vez más funcio-
nes que dan acceso a los servicios que nos proporcionan las mismas.
Existen multitud de modelos fabricados por las diversas compañías pre-
sentes en el sector. A diferencia de los móviles, son terminales más grandes
y con mayor facilidad para su manejo por todas las personas con proble-
mas visuales, auditivos o de destreza o limitación física. Se fabrican desde
hace tiempo terminales con teclados de diversos tamaños y con otras ca-
racterísticas que facilitan su uso, como son amplificadores, sistemas de avi-
sos luminosos o reconocimiento de voz. También podemos encontrar telé-
fonos que funcionan en modo texto, que mediante un sistema especial hace
que personas sordas puedan establecer comunicación entre ellas.
21

En este campo, está desarrollada prácticamente cualquier tipo de so-
lución para cualquier necesidad. Sin embargo, al no comercializarse para
el gran público, quien desee acceder a ellas debe pagar un precio muy
superior al resto de terminales.
Cajeros automáticos y quioscos virtuales
Sin duda, los cajeros automáticos y quioscos virtuales se pueden incluir

dentro de los terminales que dan acceso a servicios mediante tecnolo-
gías digitales, al incorporar cada vez más opciones de este tipo. Nacidos
con el objeto de dar opción al usuario de extraer dinero de su cuenta
bancaria de forma autónoma, su evolución los ha convertido en verdade-
ros centros de servicios desde los que podemos gestionar nuestras cuen-
tas corrientes, recargar un móvil, comprar entradas para espectáculos o
pagar impuestos.
Su manejo se produce a través de una botonera o teclado, e incluso
incorporan una pantalla táctil. Para la mayoría de las personas ofrecen un
servicio útil, sin embargo, para gran número de personas discapacitadas
su uso es verdaderamente difícil. Su colocación y altura (algunos incrusta-
dos en las paredes) los hace inaccesibles para personas que usan sillas de
ruedas ya que no pueden llegar a los botones, a leer la pantalla o a colocar
la tarjeta en su ranura. Muchos de ellos, si bien lo van incorporando, care-
cen de sonido, lo que los hace inservibles para personas invidentes. Por
otro lado, aun cuando la interfaz y la navegación suelen ser sencillos a
base de menús, los colores utilizados en la pantalla suelen ser tenues o
con bajo contraste y el cristal ofrece demasiados reflejos, lo que los con-
vierte en terminales muy difíciles para personas con visión reducida.
Conforme los cajeros o quioscos virtuales ofrecen más servicios, las
interfaces tienden a complicarse. Se debería tener especial cuidado en su
diseño, ya que una excesiva complejidad podría dificultar su manejo a per-
sonas con problemas de aprendizaje.
Tarjetas con banda magnética o chip
El elemento físico que nos sirve para «entrar en conexión» con el cajero o
quiosco virtual lo constituyen las tarjetas de crédito. En ellas se incorporan
22

aquellos datos personales y financieros que nos van a dar acceso a los
servicios ofrecidos.
Algo tan simple como una tarjeta de estas características incorpora en
sí misma, sin embargo, serios problemas de accesibilidad. Al tener que ser
manejadas normalmente en una sola posición o dirección, su uso resulta
muy complejo en personas invidentes o con muy baja visión en el momen-
to de tener que introducirla en la ranura de acceso, ya que éstas no están
estandarizadas y para orientar al usuario se utilizan gráficos o imágenes
visuales. No todas las tarjetas de crédito tienen la numeración resaltada, lo
que orientaría a usuarios invidentes. Sería conveniente que pudieran incor-
porar signos en braille, pero hasta el momento esta opción no se contem-
pla en su diseño.
De modo similar, las personas con limitaciones funcionales, que están
afectadas de problemas severos de movilidad y con problemas de destre-
za para manejar objetos pequeños y de precisión, encuentran dificultades
para introducir las tarjetas en las ranuras de los cajeros o quioscos virtuales.
El diseño estructural de estos elementos sólo posee una opción de funcio-
namiento, a través de la inserción de la tarjeta. Para contemplar una acce-
sibilidad universal debieran observarse diversas formas alternativas de co-
nexión, como la lectura de su banda magnética o chip en forma plana
sobre una superficie mayor.
Ordenadores personales
Cuando a principios de los ochenta se empezaron a comercializar en serie

los primeros ordenadores personales, pocos podían pensar que se conver-
tirían en herramientas esenciales en nuestras vidas. Hoy por hoy, no existe
ningún otro terminal que nos proporcione mayor número de servicios y
recursos a través del software que incorpora, desde usar un mero progra-
ma de tratamiento de textos hasta realizar complejas bases de datos y
cálculos financieros. Y con la incorporación de internet se han convertido
en el elemento emblemático de acceso a la sociedad de la información.
Paradójicamente, igual que ocurría con los teléfonos móviles, su acce-
sibilidad era mucho mayor en sus inicios que actualmente. Teclados más
simples y pantallas monocromas por obligación hacían de él un elemento
muy útil para personas con discapacidad. Al mismo tiempo, el software
23

que incorporaban, de interfaces mucho más sencillas y menús más gran-
des, con mucha menos carga gráfica, los hacían relativamente más acce-
sibles que ahora. Hoy en día son múltiples los problemas de accesibilidad
que presentan. Si bien es cierto que su tamaño puede ser más grande que
los diseños comercializados, también su coste aumenta si queremos salir-
nos de los patrones estándares.
Las personas invidentes encuentran su mayor problema en la tenden-
cia a presentar la información en forma eminentemente visual. Un lector
de pantalla realiza la función de ofrecer información oral de todos aquellos
elementos que aparecen en la pantalla, bien sean elementos para interactuar
(botones o hiperenlaces) o del mismo contenido. En el diseño de los con-
tenidos no suele tenerse en cuenta que el acceso se puede realizar a tra-
vés de lectores de pantalla que sólo pueden leer correctamente si aquellos
están estructurados de forma correcta.
Para muchas personas con escasa visión, sin llegar a ser invidentes
totales, son necesarios monitores grandes o muy grandes. Esto hace que
muchas de ellas no puedan acceder a estas pantallas debido a su precio,
lo cual supone una discriminación (aunque ésta sea económica y no por
discapacidad), ya que a igual servicio el coste es mayor para quien tiene
una limitación funcional. Si bien es cierto que a través de opciones de
software para aumentar el tamaño de las letras se puede efectuar una
lectura mejor, esta práctica es muy dificultosa en monitores de 15 o 17
pulgadas, que son las más comunes en el mercado.
En el caso de personas con discapacidad auditiva, su dificultad para
reconocer sonidos y cambios de frecuencia les hace encontrarse desorien-
tados cuando el funcionamiento del ordenador se basa en elementos so-
noros. Con la incorporación a los sistemas operativos más usuales de la
opción «Showsound», que proporciona información textual de todos aque-
llos sonidos producidos en el manejo del ordenador, se puede solucionar
en cierta forma esta dificultad. Las personas con discapacidad auditiva que
además presentan un problema físico que les dificulta el manejo del tecla-
do, también encuentran serias dificultades al manejar los programas y ter-
minales de reconocimiento de voz.
En el caso de personas con discapacidad física que impide una des-
treza adecuada o movimientos de manos y miembros superiores, un tecla-
do puede resultar un elemento inservible, de igual modo que un ratón con-
24

vencional. Para solucionar estos problemas existen dispositivos específi-
cos de entrada de información muy variados, que abarcan desde el ya
mencionado sistema de reconocimiento de voz, ratones más grandes de
diseño trackball, joysticks o punteros diseñados para funcionar a través de
sensores.
Televisión
La televisión ha sido durante años el terminal de acceso por excelencia a

la sociedad de comunicación de masas en formato audiovisual. Aunque su
tecnología sólo ha permitido hasta ahora una transmisión unidireccional de
información, sin posibilidad de que el usuario interactuara sobre ella salvo
para cambiar de canal, la nueva televisión digital da un vuelco completo al
concepto de televisión tradicional. La televisión digital nos abre camino a
un mundo de servicios completamente nuevo, entre los que podemos en-
contrar muchos de los ofrecidos por nuestros ordenadores mediante el
acceso a internet.
Nos encontramos tres problemas esenciales en la accesibilidad de la
televisión:
El primero lo sufren las personas con discapacidad auditiva que no pue-

den recibir los sonidos emitidos por la televisión. Para ello es necesario
que las programaciones se subtitulen o se incluya la imagen de un in-
térprete de lengua de signos, aspecto éste que aún hoy en día se utili-
za muy poco pese a ser técnicamente posible.
En segundo lugar, la forma de manejo de la televisión se realiza a tra-
vés del mando a distancia. Éste suele tener las teclas excesivamente
pequeñas para las personas con dificultad en la movilidad o con falta
de fuerza; además, para las personas mayores y con baja visibilidad
los símbolos, numeración y letras de las teclas suelen tener escaso
contraste, lo que dificulta su lectura.
Y en tercer lugar, a las personas invidentes les resulta imposible acce-
der a las imágenes. Sí pueden, en cambio, seguir la programación
mediante técnicas de audiodescripción que van narrando todo lo que
sucede en la pantalla. No obstante, al igual que ocurre con la
subtitulación, su implantación es muy escasa todavía.
25

Radio
La radio que conocemos, primer aparato real de comunicación masiva de

información a través de ondas sonoras, siempre ha estado prohibida para
las personas con discapacidad auditiva.
Recientemente se están implantando tecnologías digitales de radio
digital que ofrecerán múltiples servicios, de modo parecido, salvando las
distancias, a la TV digital, que ofrecerán la presentación a través de una
pantalla del texto que se emita desde la cadena de radio.
Las personas invidentes tienen la posibilidad, si está implementado, de
seguir la programación televisiva a través de aparatos de radio y frecuen-
cias especiales que sintonizan con las frecuencias televisivas.
Elementos de los terminales de acceso
Para interactuar con los terminales vistos anteriormente existen diversos y

múltiples aparatos que nos sirven para introducir la información que se
debe procesar. Cada uno de ellos tiene sus propias particularidades y sus
propios problemas de accesibilidad que se describen a continuación en
grandes líneas.
Teclados
Usados principalmente como elemento de acceso al ordenador, no obs-

tante también son usados en otros terminales ya vistos, como los cajeros
automáticos o quioscos virtuales. Su diseño puede ser muy variado y de
diferente complejidad, puede ser alfanumérico y extenso para los ordena-
dores, simplemente numérico, con teclas que agrupan varios caracteres o
ilustrados mediante símbolos. Así, podemos encontrar teclados en ordena-
dores, teléfonos fijos y móviles, cajeros y mandos a distancia.
Para muchas personas con movilidad reducida o falta de destreza, los
teclados suponen verdaderas barreras. De igual modo lo suponen para las
personas invidentes, cuando las teclas no van acompañadas de su dibujo
en braille o resaltado. Para este último supuesto, el teclado debe ser de
mayores dimensiones, de forma que en sus teclas se puedan encontrar
26

dichos caracteres. Las letras, números y símbolos de cada tecla deben
estar lo suficientemente definidos y diseñados en colores, cuyo contraste
sea accesible a personas con visión reducida.
Ratones
Los ratones, en todas sus variantes, incluidos los trackballs,1 ópticos o pla-
cas táctiles, son usados en esencia para interactuar con el ordenador. Los
ratones estándares suelen ser difíciles de manejar para personas con es-
casa destreza o una mínima fuerza para realizar el movimiento de arrastre
del puntero y precisión para «pinchar» en una zona pequeña. Los ratones
incorporados de serie en ordenadores portátiles (placas táctiles) requieren
demasiada precisión en un espacio muy reducido, por lo que resultan im-
practicables para gran número de personas, entre las que se encuentran
muchas personas mayores.
El ratón debe ser configurable al menos para poder cambiar el tamaño
del puntero y su color, aspecto esencial para personas de baja visión o
daltónicas.
Jogs
Consisten en una plataforma que incorpora cuatro botones, distribuidos

simétricamente en la mayoría de los casos. Son similares a los que llevan
algunos mandos a distancia de vídeos, DVD y mandos a distancia, y cum-
plen la función de moverse en las cuatro direcciones a través de menús en
pantalla.
Presentan los mismos problemas de accesibilidad que los ya comenta-
dos para personas con escasa movilidad o destreza, al ser a veces difícil
seleccionar con la debida precisión las opciones. También, al igual que los
teclados, si no llevan incorporados los símbolos en braille resultan de muy
difícil manejo en personas invidentes.
1. Los trackballs son ratones que llevan la bola encima. Pueden ser manejados incluso con
las muñecas o la palma de la mano y suelen ser de un tamaño superior a los ratones convenciona-
les, lo que facilita su uso para muchas personas.
27

Ruedas
Con el tiempo, los ratones han ido incorporando más botones y otros ac-
cesorios adicionales como, por ejemplo, unas pequeñas ruedas o piezas
giratorias que, insertadas en el cuerpo del ratón, bien encima o a los lados,
sirven, entre otras funciones, para navegar y moverse verticalmente por
las páginas web. Suelen ser de reducido tamaño y requieren el movimien-
to de los dedos de la mano y una cierta precisión, por lo que a personas
que carecen de destreza o sufren limitación grave de movimientos en los
miembros superiores no les resulta practicable. De igual modo, a las per-
sonas con determinadas deficiencias mentales que limiten la concentra-
ción o fijación les resulta difícil su uso. Igual ocurre con personas mayores
que tienen enfermedades como el Parkinson, debido al temblor de manos
que éste produce.
Estas pequeñas ruedas también se han empezado a incluir en teléfo-
nos móviles que usan tecnología WAP o UMTS, las cuales presentan los
mismos problemas de accesibilidad que en los ratones.
Micrófonos
Con la introducción de sistemas operativos y software gráfico y multimedia,

se ha empezado a ver como habitual el micrófono para ordenadores. Este
micrófono también es usado para hablar por teléfono a través de internet y
en los sistemas de reconocimiento de voz. Asimismo, los teléfonos tam-
bién llevan un micrófono incorporado.
Estos elementos, muy útiles para determinadas deficiencias, como le-
siones físicas graves, carecen de utilidad para otras muchas. Las personas
mudas no pueden hacer uso de ellos, como tampoco aquellas que sin ser
mudas tienen problemas en el habla, debido a que no consiguen corregir
las tonalidades y defectos del hablante para manejar un sistema de reco-
nocimiento de voz, por ejemplo.
Pantallas táctiles
Con la evolución de la tecnología, nos encontramos con que desde hace un
tiempo se han empezado a utilizar las llamadas pantallas táctiles, sensibles
al contacto de la mano o de los dedos para interactuar con los elementos
28

que se nos presentan en dicha pantalla. Mediante un sencillo contacto táctil
podemos seleccionar menús, información y navegar por el contenido.
Inicialmente presentes en los quioscos virtuales, hoy las podemos en-
contrar también en los ordenadores y en los asistentes digitales personales
(PDA). En estos últimos se maneja utilizando un pequeño y fino punzón
que al contacto con los elementos de la pantalla va seleccionando conteni-
dos. En ambos casos se presentan los mismos problemas de accesibilidad
que estamos viendo sucesivamente. No pueden ser usados por personas
mayores con ciertas deficiencias, ni por personas con discapacidad física
severa y falta de destreza. En el caso de los PDA, las reducidas dimensio-
nes de la pantalla constituyen una barrera casi siempre infranqueable en
personas con visión reducida. Lo mismo les ocurre a las personas con
determinadas deficiencias cognitivas, ya que necesitan una visualización
clara mediante iconos bien definidos e intuitivos.
Pantallas
El dispositivo de salida más utilizado es la pantalla, presente en ordenado-

res, la televisión, teléfonos móviles, PDA, cajeros automáticos y otros.
Dependiendo del elemento al que correspondan, existen multitud de tama-
ños, desde escasas pulgadas en teléfonos móviles hasta más de cincuen-
ta en las nuevas televisiones de plasma. Hoy en día, con la evolución de la
tecnología y el software utilizados, todas presentan contenido multimedia.
En general, resultan poco accesibles a personas con escaso nivel de
visión, salvo en aquellas de muchas pulgadas. El contenido que se nos
presenta en la pantalla si está realizado de acuerdo a las normas adecua-
das, podrá ser leído por lectores de pantalla. En determinadas discapacida-
des, como es el caso de la epilepsia, se deberá tener especial cuidado con
los niveles de refresco de pantalla para evitar producirles crisis debidas a
la frecuencia de parpadeo.
Interfaz hombre-máquina
Lo visto hasta ahora constituye los elementos físicos que posibilitan la en-
trada y salida de información, elementos necesarios para que el individuo
29

pueda interactuar con los terminales. Lo que se nos presenta en los termi-
nales de salida lo constituye la llamada interfaz, que no es sino el software
o programas necesarios para dirigir, controlar y gestionar todo el conjunto
de terminales y sus elementos adicionales. Estos programas suelen pre-
sentar en la pantalla una serie de menús, botones interactivos, datos e
información que interrelacionados entre ellos y con combinaciones ade-
cuadas dan el acceso a las opciones, selecciones y servicios que se nos
proporcionan.
Al igual que los elementos y terminales físicos de entrada y salida de
información, la interfaz suele tener sus propios problemas de accesibilidad
por la carencia de diseño universal. Estos problemas de accesibilidad cons-
tituyen otra gran barrera para muchas personas con discapacidad que aun
pudiendo manejar los terminales no pueden interactuar con la interfaz.
Es fundamental un estudio adecuado de los colores que nos va a pre-
sentar la interfaz, debido a que personas con problemas en el reconoci-
miento de colores, como las daltónicas, pueden tener dificultad para dife-
renciarlos.
En su diseño es muy importante, asimismo, contemplar diversas formas
de interactuar con los elementos presentes en la interfaz. Si al diseñarla sólo
lo hacemos para poder ser manejada por medio de un ratón, sea del tipo
que sea, habrá muchas personas con deficiencias en la visión y con proble-
mas de movilidad y destreza que encontrarán prácticamente imposible su
uso. Lógicamente, si pensamos en desarrollar únicamente la interfaz en modo
gráfico plasmada en la pantalla, sin contemplar elementos sonoros o auditivos
que la describan en cada opción, las personas invidentes tampoco tendrán
acceso a ella, ya que no podrán utilizar elementos como el lector de pantalla
o un dispositivo de salida en braille (denominado «línea braille»).
Cuando la interfaz es realizada para que en determinados momentos
o selecciones sea necesaria la pulsación de varias teclas al mismo tiempo
(por ejemplo, alt+control), y no se presenta una forma alternativa (por ejem-
plo, la pulsación secuencial), las personas con problemas de destreza y de
coordinación no podrán realizarla en muchos momentos. Sería en este
caso necesario diseñar atajos o dejar abierta la posibilidad de poder confi-
gurar funciones para las teclas.
Las solicitudes de información, el rellenado de campos que se nos
soliciten y los formularios de peticiones han de ser aplicados de forma que
30

logremos la mayor sencillez posible. Debemos tener en cuenta que la
interfaz puede ser usada por personas con dificultad o retraso en el apren-
dizaje o que les resulte problemático mantener una concentración adecua-
da en formularios complejos o largos. Los campos activos a rellenar debe-
rán ser, además, fácilmente localizables y visibles.
La navegación y el movimiento por la interfaz deben ser sencillos,
intuitivos y diseñados con pautas lógicas. Para ello, el usuario deberá ser
capaz, incluso aquel con problemas de fijación y aprendizaje, de saber
dónde se encuentra en cada momento y tener siempre la opción clara-
mente visible de volver al principio o ser capaz de finalizar la utilización de
un programa o cerrar la sesión de trabajo con la interfaz.
Contenidos
Superados los problemas relativos a las barreras físicas de acceso de en-

trada y salida de información y las problemáticas que puede presentar un
deficiente diseño de la interfaz, llegamos a los contenidos almacenados,
principalmente los que se presentan a través de internet. Si tampoco con-
templamos los estándares de accesibilidad, éstos serán inaccesibles para
muchas personas.
Cuando estructuramos y ponemos el contenido de la información en
cualquier servidor, debemos hacerlo de forma que cualquier persona pue-
da acceder a él. Si volcamos el contenido que queremos hacer llegar al
usuario exclusivamente en formato gráfico, las personas invidentes que
utilicen lectores de pantalla encontrarán que les es imposible acceder a
esa información. Si incluimos archivos de audio sin alternativa, aquellas
personas que tengan una deficiencia auditiva severa o total no obtendrán
información. Es necesario proporcionar una versión alternativa mediante la
audiodescripción o el subtitulado, simultáneamente, mientras dura la pre-
sentación de los contenidos. Problema idéntico se plantea cuando utiliza-
mos o incorporamos archivos o películas de vídeo y no utilizamos las op-
ciones del subtitulado y la audiodescripción.
La presentación de la información debe estar, necesariamente, bien
estudiada y seguir una estructura lógica y coherente. Debemos ser cons-
cientes de que existen muchas personas con problemas de aprendizaje,
31

de concentración o de dispersión mental a las cuales les resultará inacce-
sible una presentación de la información irregular o anárquica.
Es muy conveniente que toda información textual esté acompañada o
complementada mediante algún gráfico, fotografía o iconos gráficos e
intuitivos, complementarios del texto, de forma que su lectura no se vuelva
monótona y dificulte la comprensión del contenido por parte de usuarios
que tienen dificultades en el manejo del lenguaje escrito. Este problema es
muy frecuente en personas sordas o con dificultad de aprendizaje. Del
mismo modo, en aquella información de carácter general y que tiene como
destinataria a toda la población, se debe utilizar un lenguaje claro y evitar,
en la medida de lo posible, giros y terminología compleja para evitar la
inaccesibilidad de la información a personas con dificultades e incluso con
escasa formación.
Ordenadores e internet
El ordenador, como principal elemento de acceso a la información, a las

tecnologías digitales y a la Sociedad de la Información a través de internet,
merece un apartado especial. Aun cuando la telefonía de tercera genera-
ción ya nos permite también el acceso a la Sociedad de la Información y
conectarnos a la web y a nuestro correo electrónico, la potencialidad y pres-
taciones del ordenador, unido a la utilización de pantallas con mucha ma-
yor dimensión, lo siguen haciendo el primer e imprescindible terminal en el
acceso a las tecnologías.
Desde que hace unos años los ordenadores empezaron a incorporar
el módem para conectarse a internet, el ordenador se ha convertido en
una potente estación de trabajo que nos abre las puertas a innumerables
posibilidades a través de este servicio. Hoy en día, desde el ordenador
podemos gestionar nuestras cuentas en los bancos, tenemos acceso a
realizar compras sin desplazarnos a un centro comercial, podemos entrar
y participar en proyectos de teleformación e incluso trabajar desde casa a
través del teletrabajo. Es decir, sin desplazarnos de nuestra habitación
podemos tener salida al mundo exterior con múltiples posibilidades de ac-
tuación. Pero el aspecto más importante es que podemos acceder a infor-
mación, formación y comunicación con otras personas.
32

Por ello, resulta tremendamente importante que tanto los medios físi-
cos de manejo y la forma de interactuar con el ordenador, así como la
información que se nos presenta, sean accesibles para todos los indivi-
duos. En caso contrario, dejaremos a muchas personas con discapacidad
y personas mayores al margen de la Sociedad de la Información, hacién-
dose realidad la infoexclusión. Anteriormente hemos repasado, en líneas
generales, estos problemas de accesibilidad que pueden acrecentar la lla-
mada «brecha digital» para muchas personas.
Crear contenidos e interfaces accesibles para nuestro ordenador no es
más costoso ni más difícil. Asimismo, diseñar contenidos accesibles según
los parámetros estandarizados, tanto para sitios web como para los pro-
gramas informáticos, tiene que suponer que sean menos atractivos o me-
nos vistosos. La accesibilidad no está reñida con la elegancia en el diseño.
Debemos perseguir que las herramientas que se usan normalmente para
el desarrollo de espacios web tengan la posibilidad de generar sitios acce-
sibles, y que además la interfaz del mismo programa sea accesible para
ser usada por personas con limitaciones funcionales. Lo mismo podemos
decir de los programas de creación o de autor y de aquellos que nos ayu-
dan a realizar tareas ofimáticas.
33

34

Accesibilidad en la web
El poder de la web reside en su universalidad. El acceso

para todo el mundo, a pesar de la discapacidad, es un
aspecto esencial.
TIM B ERNERS-LEE
Director e inventor de la Red Mundial Web (World Wide Web)
Para que un sitio web sea accesible, su contenido debe estar disponible
para todo el mundo, incluidas las personas con discapacidad. Un sitio web
accesible asegura:
Una transformación sin problemas: la información y los servicios de-

ben ser accesibles a pesar de las limitaciones físicas, sensoriales o
cognitivas de los usuarios y de las restricciones o barreras tecnológicas.
Un contenido comprensible y navegable: el contenido debe ser pre-
sentado de forma clara y simple y debe proporcionar mecanismos
comprensibles para navegar en y entre las páginas.
Un sitio web accesible:
1. puede ser percibido por todos;

2. puede ser navegado cumpliendo criterios de usabilidad;
3. puede ser utilizado con el teclado o con otros dispositivos además del
ratón;
4. puede ser comprendido fácilmente, incluso en situaciones de atención
dificultosa.
La accesibilidad y la usabilidad están íntimamente relacionadas, ya que

ambas mejoran la satisfacción, la efectividad y la eficiencia. Pero mientras
la accesibilidad está dirigida a hacer un sitio web abierto al más amplio
número de usuarios, la usabilidad se dirige a conseguir el objetivo de satis-
facer más a los usuarios, con un sitio web más eficaz y eficiente.
35

La accesibilidad en la web es importante
La accesibilidad se hace cada vez más importante porque:
1. Los diseñadores web están obligados a cumplir con la normativa so-

bre accesibilidad.
2. Los diseñadores web están cambiando su atención hacia la creación
de sitios web que sean accesibles para las personas con discapacidad
naveguen sin dificultad, movidos tanto por razones humanitarias como
por razones comerciales.
3. Las tecnologías digitales requieren sitios diseñados para ser ac-
cesibles por diferentes dispositivos (por ejemplo: usuarios de peque-
ñas pantallas en blanco y negro en sus teléfonos móviles, aquellos que
usan la navegación por voz en navegadores de coches o los que escu-
chan un navegador parlante a través de la línea telefónica). A estos
usuarios se les puede considerar también temporalmente personas con
discapacidad.
4. Hay unos usuarios muy importantes que encuentran dificultades para
usar un sitio si éste no es accesible: son las llamadas máquinas de
búsqueda. Google (por nombrar una de las más conocidas) puede apro-
vecharse plenamente de un sitio que es accesible e indexar sus pági-
nas con todas las palabras que encuentra, especialmente en los víncu-
los, imágenes, títulos y etiquetas. Además, Google puede activar todos
los vínculos de un sitio y escanear, por tanto, todas sus páginas. Un
sitio web que no sea accesible tiene muchas menos palabras que pue-
den ser usadas y muchos más vínculos no accesibles que no pueden
ser seguidos.
Las vertientes de la accesibilidad en la web
Para conseguir que un sitio web sea accesible para todos deberemos se-
guir determinadas reglas para conseguir que así sea. En la imagen 1 po-
demos ver, de forma gráfica y esquematizada, el proceso que supone la
creación de contenido web desde el momento en que un autor tiene la
idea de realizar una página web hasta que ésta llega a los distintos usua-
36

rios, teniendo siempre en cuenta los aspectos esenciales que han de te-
nerse en consideración para que sea un «diseño para tod@s».
Imagen 1. Elementos de accesibilidad a las páginas web.
En este esquema de elementos que intervienen en el proceso de ela-

boración de páginas web accesibles podemos distinguir distintas etapas o
momentos, que determinan la existencia de unas reglas a tener en cuenta
para conseguir dicho propósito. Así podemos hablar de reglas para:
Las herramientas con las que cuenta un autor para crear y dar forma al
contenido de la web.
Las aplicaciones con las que un usuario accede a los contenidos y
mediante las cuales puede navegarlos.
Los contenidos, propiamente dichos, de las páginas web, en cuanto a
su estructura y maquetación.
Para cada una de estas vertientes de la accesibilidad en la web se han

redactado unas «pautas» que sirvan de guía y referencia para desarrollar
de forma accesible los contenidos en la web y poder hacer uso de ellos
por parte de todos los usuarios.
De la redacción de estas «recomendaciones» se ha encargado el Con-
sorcio Mundial de la Web (World Wide Web Consortium), conocido mun-
dialmente por las siglas W3C, a través del grupo de trabajo Iniciativa de
Accesibilidad en la Web (Web Accessibility Initiative) y bajo las siglas WAI.
37

El Consorcio Mundial de la Web (W3C)
W3C es un consorcio industrial, internacional e independiente que aglutina

a organizaciones gubernamentales, no gubernamentales e industrias, cuya
finalidad es promover la evolución e interoperatividad de la web, para fo-
mentar su universalidad.
El objetivo que persigue es conseguir un acceso universal al servicio
de la web, dentro de un entorno de software versátil y con respeto a la
legalidad establecida.
Para conseguir este objetivo se desarrollan tareas como identificar los
requerimientos que son precisos, diseñar tecnologías que lo hagan posible
y estandarizar mediante la redacción de recomendaciones de aplicación
general para todos.
Las actividades que lleva a cabo se encuadran en cinco campos:
1. Arquitectura.
2. Interacción.
3. Tecnología y sociedad.
4. Accesibilidad.
5. Garantía de calidad.
En cada uno de ellos se desarrollan distintos proyectos mediante gru-

pos de trabajo. Para el objeto de este documento nos interesa el referido
en cuarto lugar (sin que ello suponga exclusión de las repercusiones que
suponen los trabajos realizados en los otros campos sobre la accesibilidad
de un sitio web).
Para más información, en inglés: http://www.w3.org/Consortium/
Overview.html; en castellano: http://www.w3c.es/Consorcio/
La Iniciativa de Accesibilidad en la Web (WAI)
La Iniciativa de Accesibilidad en la Web (Web Accessibility Initiative – WAI)

es uno de los grupos de trabajo del W3C, cuya finalidad es propiciar un
debate permanente sobre las necesidades y soluciones de accesibilidad
en la web. Proporciona un foro de discusión y sirve como elemento de
38

control, en materia de accesibilidad, para todas las actividades desarrolla-
das por W3C.
WAI, en colaboración con organizaciones de todo el mundo, persigue
la accesibilidad en la web a través de cinco áreas de trabajo:
1. Tecnología.
2. Pautas.
3. Herramientas.
4. Educación y difusión.
5. Investigación y desarrollo.
Para el propósito de este trabajo, nos es de particular interés la segun-

da de estas áreas de trabajo: la de elaboración de pautas para conseguir
un diseño accesible de páginas web.
Para más información sobre WAI y las actividades que desarrolla, se
puede consultar la página web: http://www.w3.org/WAI/about.html.
Las pautas para la accesibilidad en la web
Anteriormente hemos hablado sobre las distintas vertientes de la accesibi-

lidad en la web, y son tres las que deberemos considerar: contenidos, he-
rramientas de creación y aplicaciones de usuario.
Para cada una de estas vertientes, el grupo WAI ha redactado un do-
cumento de Pautas y sus correspondientes documentos anexos sobre téc-
nicas para la aplicación y lista de verificación. El resultado lo podemos
encontrar en las siguientes direcciones web:
Pautas de Accesibilidad al Contenido en la Web 1.0 (Web Content

Accessibility Guidelines 1.0):
• Texto original en inglés: http://www.w3.org/TR/WCAG10/.
• Traducción al castellano de Egea, Sarabia y Chuter: http://
www.teleservicios.es/accesibilidad/recursos/documentos/index.html.
Pautas de Accesibilidad para las Herramientas de Creación 1.0
(Authoring Tool Accessibility Guidelines 1.0):
• Texto original en inglés: http://www.w3.org/TR/ATAG10/.
39

Pautas de Accesibilidad para las Aplicaciones de Usuario (User Agent
Accessibility Guidelines 1.0):
• Texto original en inglés: http://www.w3.org/TR/UAAG10/
El grupo WAI también ha redactado unas Pautas específicas para los

desarrolladores de aplicaciones basadas en XML de cara a que éstas so-
porten los criterios de accesibilidad. Están disponibles en: http://www.w3.org/
TR/xag.html (en inglés).
Las pautas nos sirven de referencia normativa (no legal, pero sí técni-
ca) y junto a cada una de ellas se provee al desarrollador de un documen-
to técnico, donde se explica la manera de aplicarlas. Por otro lado, nos
pueden servir para verificar si hemos realizado correctamente el trabajo
(es decir, de forma accesible). Se las conoce como «lista de verificación».
40

Legislación y otras normas en materia de
accesibilidad en la web
Antes de entrar en materia, sería bueno echar un vistazo a cómo se en-

cuentra el marco normativo, tanto en su vertiente legal como técnica.
Tras una etapa de ausencia de una regulación tanto legal como en
materia de normas técnicas, los últimos tiempos han venido acompañados
de una fructífera cosecha que vamos a reflejar en este apartado.
Legislación y otras normas en España

LEY 34/2002, de 12 de julio, de Servicios de la Sociedad de la In-
formación y de Comercio Electrónico.
Establece en su disposición adicional quinta sobre «Accesibilidad para las
personas con discapacidad y de edad avanzada a la información propor-
cionada por medios electrónicos»:
1. Las Administraciones Públicas adoptarán las medidas necesarias

para que la información disponible en sus respectivas páginas de
internet pueda ser accesibles a personas con discapacidad y de
edad avanzada de acuerdo con los criterios de accesibilidad al conte-
nido generalmente reconocidos antes del 31 de diciembre de 2005.
Asimismo, podrán exigir que las páginas de internet cuyo diseño
o mantenimiento financien apliquen los criterios de accesibilidad
antes mencionados.
2. Igualmente, se promoverá la adopción de normas de accesibilidad
por los prestadores de servicios y los fabricantes de equipos y soft-
ware, para facilitar el acceso de las personas con discapacidad o de
edad avanzada a los contenidos digitales.
41

Ley 51/2003, de 3 de diciembre, de Igualdad de Oportunidades, No
Discriminación y Accesibilidad Universal de las Personas con
Discapacidad.
La Ley establece la obligación gradual y progresiva de que todos los
entornos, productos y servicios deben ser abiertos, accesibles y practica-
bles para todas las personas e impone plazos y calendarios para realiza-
ción de las adaptaciones necesarias.
Respecto a los productos y servicios de la Sociedad de la Información
la ley establece en su Disposición final séptima sobre «Condiciones bá-
sicas de accesibilidad y no discriminación para el acceso y utilización de
las tecnologías, productos y servicios relacionados con la sociedad de la
información y medios de comunicación social».
1. En el plazo de dos años desde la entrada en vigor de esta ley, el

Gobierno aprobará, según lo previsto en su artículo 10, unas condi-
ciones básicas de accesibilidad y no discriminación para el acceso y
utilización de las tecnologías, productos y servicios relacionados con
la sociedad de la información y de cualquier medio de comunicación
social, que serán obligatorias en el plazo de cuatro a seis años desde
la entrada en vigor de esta ley para todos los productos y servicios
nuevos, y en el plazo de ocho a diez años para todos aquellos exis-
tentes que sean susceptibles de ajustes razonables.
2. En el plazo de dos años desde la entrada en vigor de esta ley, el
Gobierno deberá realizar los estudios integrales sobre la accesibilidad
a dichos bienes o servicios que se consideren más relevantes desde
el punto de vista de la no discriminación y accesibilidad universal.
Con el objeto de favorecer la formación en diseño para tod@s, en su

Disposición final décima, sobre «Currículo formativo sobre accesibilidad
universal y formación de profesionales», establece:
El Gobierno, en el plazo de dos años a partir de la entrada en vigor de

esta ley, desarrollará el currículo formativo en «diseño para tod@s», en
todos los programas educativos, incluidos los universitarios, para la for-
mación de profesionales en los campos del diseño y la construcción del
entorno físico, la edificación, las infraestructuras y obras públicas, el
42

transporte, las comunicaciones y telecomunicaciones y los servicios de
la sociedad de la información.
Orden 1551/2003, de 13 de junio, por la que se desarrolla la Dispo-

sición final primera del Real Decreto 209/2003, de 21 de febrero,
por el que se regulan los registros y las notificaciones telemáticas,
así como la utilización de medios telemáticos para la sustitución de
la aportación de certificados por los ciudadanos.
La disposición Séptima, sobre «Protocolos y criterios técnicos de los dis-
positivos y aplicaciones de registro y notificaciones», en su inciso segundo
establece:
2. El registro telemático y el servicio de notificación telemática deberán

cumplir los requerimientos en materia de accesibilidad establecidos
por la Iniciativa para una Web Accesible (WAI) del Consorcio World
Wide Web y en particular las especificaciones de la Recomendación
de 5 de mayo de 1999 sobre Pautas de Accesibilidad del Contenido
en la Web, versión 1.0, en su nivel AA.
I Plan Nacional de Accesibilidad 2004-2012.

En este documento, de fecha 25 de julio de 2003, se establecen los si-
guientes objetivos:
• Consolidar el paradigma del Diseño para Todos y su implantación en

los nuevos productos, entornos y servicios. Difundir el conocimiento y
aplicación de la accesibilidad.
• Introducir la accesibilidad como criterio básico de calidad de la ges-
tión pública.
• Conseguir un sistema normativo para la promoción de la accesibili-
dad completo, eficiente y de elevada aplicación en el territorio.
• Adaptar progresivamente y de forma equilibrada los entornos, produc-
tos y servicios a los criterios de Diseño para Todos.
• Promover la accesibilidad en las tecnologías digitales.
43

II Plan de Acción para las personas con discapacidad 2003-2007.
En este documento, de fecha 5 de diciembre de 2003, se establece, entre
otras medidas:
• 323.4.- Impulso a la difusión e implantación de las «Directrices de
Accesibilidad a las páginas Web de la Administración General del
Estado».
• 341.1.- Inclusión de una cláusula que favorezca la accesibilidad en
los pliegos técnicos de los contratos que tengan por objeto la adquisi-
ción de bienes, productos y servicios por parte de las Administracio-
nes Públicas, especialmente, en el ámbito de las tecnologías digitales
y la sociedad de la información.
• 341.2.- Reforma de la legislación en materia de concesión de subven-
ciones, ayudas e incentivos públicos para vincular el disfrute de ayu-
das con la obligación de accesibilidad por parte de los beneficiarios,
cuando se trate de bienes y servicios a disposición del público.
Normas UNE.
En España, a través de la Asociación Española de Normalización y Certifi-
cación AENOR, se han aprobado y publicado varias normas técnicas que
afectan al tema de este módulo.
UNE 139801:2003 - Aplicaciones informáticas para personas con

discapacidad. Requisitos de accesibilidad al ordenador. Hardware.
discapacidad. Requisitos de accesibilidad al ordenador. Software.
discapacidad. Requisitos de accesibilidad para contenidos en la web.
Otras normas Internacionales

Plan de Acción eEurope 2002.
El Plan de Acción eEurope 2002 fue aprobado por el Consejo Europeo de
Feira en junio de 2000. Este Plan pretende convertir a la Unión Europea
en una economía basada en el conocimiento, más competitiva y dinámica,
44

con avances en materia de empleo y de cohesión social, con un horizonte
puesto en el año 2010.
Se han valorado con principales progresos durante el período de eje-
cución del Plan de Acción eEurope 2002:
La duplicación de la penetración de internet en los hogares.

La renovación del marco de las telecomunicaciones.
Disminución del precio del acceso a internet.
La conexión de casi todas las empresas y centros escolares.
Que Europa cuente con la red principal de investigación más rápida del
mundo.
La creación casi completa del marco jurídico del comercio electrónico.
La existencia de más servicios de la Administración Pública disponibles
en línea.
La aparición de una infraestructura de tarjeta inteligente.
La adopción y recomendación en los estados miembros de unas direc-
trices sobre accesibilidad de la web.
Plan de Acción eEurope 2005.

Este plan de acción es el sucesor del Plan de Acción eEurope 2002. Fue
lanzado en el Consejo de Europa de Sevilla en junio de 2002, durante la
presidencia española de la Unión Europea, y aprobado por el Consejo de
Ministros europeos en enero de 2003. En este Plan se establece que, para
2005, Europa deberá contar con:
Unos servicios públicos en línea modernos.

Una administración electrónica.
Unos servicios electrónicos de aprendizaje.
Unos servicios electrónicos de salud.
Un entorno dinámico de negocios electrónicos.
Para hacer posible todo ello, se necesitaría:
Un acceso de banda ancha ampliamente disponible y a precios compe-

titivos.
Una infraestructura de información segura.
45

El plan de acción se estructura en torno a cuatro líneas interrelacionadas:
Medidas políticas de revisión y adaptación de la legislación nacional

y europea encaminadas a reforzar la competencia y la interoperatividad,
aumentar el grado de sensibilización y hacer gala de iniciativa política.
La aplicación de estas medidas políticas se verá respaldada por el de-
sarrollo, el análisis y la difusión de buenas prácticas. Se pondrán
en marcha proyectos que aceleren la implantación de aplicaciones e
infraestructuras de vanguardia.
La evaluación comparativa de los progresos conseguidos en el lo-
gro de los objetivos y de las políticas al servicio de dichos objetivos
permitirá efectuar un seguimiento de las medidas políticas y reorientar-
las si procede.
La coordinación global de las políticas existentes generará sinergias
entre las acciones propuestas. A través de un grupo de dirección, se
tendrá una visión de conjunto de la evolución de las políticas y se ga-
rantizará un adecuado intercambio de información entre los responsa-
bles nacionales y europeos y el sector privado.
La Sección 508 del «Acta de los Americanos con Discapacidad»

Aunque no tiene una aplicación directa en el ordenamiento jurídico espa-
ñol, citamos esta norma de los Estados Unidos, aprobada el 21 de julio de
2001, por su indudable influencia sobre los productos y servicios que nos
llegan desde aquellas tierras.
La finalidad y el alcance de esta norma quedan claramente recogidos
en el siguiente párrafo de la misma:
[...] La Sección 508 exige que cuando las agencias Federales desarro-
llen, adquieran, mantengan, o usen las tecnologías de la comunicación y
la información deben asegurarse de que las mismas permiten a los em-
pleados federales con discapacidad tener acceso a usar la información y
datos de manera similar al acceso y uso que tienen los empleados fede-
rales sin discapacidad, a menos que constituya una carga excesiva im-
puesta a la agencia. La Sección 508 también exige que las personas con
discapacidad, que forman parte del público que busca información o ser-
46

vicios por parte de una agencia Federal, tengan acceso y uso de la infor-
mación y datos de manera comparable a la que se proporciona al públi-
co sin discapacidad, a menos que ello signifique una carga excesiva
impuesta a la agencia.
La Sección 508, en su apartado 1194.22 «Web-based intranet and

internet information and applications» (Información y aplicaciones de
intranet e internet basadas en la web), determina las normas para la
creación de páginas y aplicaciones web, que son aplicables a todas las
agencias federales de Estados Unidos.
Como queda reflejado en sus objetivos, la Sección 508 no se ocupa
sólo de la accesibilidad de las páginas y aplicaciones web, también lo hace
del software y por tanto de las herramientas de autor y de los navegadores.
47

48

Las herramientas de creación o de autor
En la imagen 2 podemos ver cuáles son los elementos de accesibilidad a

las páginas web.
Imagen 2.- Elementos de accesibilidad a las páginas web.
Como primer escalón de este esquema de elementos nos encontra-

mos al autor que, tras tener la idea de generar unos contenidos para la
web, los tiene que estructurar y maquetar para colocarlos en un servidor.
Para llevar a cabo esta tarea, el autor utiliza unas herramientas a las que
denominamos herramientas de creación o herramientas de autor (en inglés
se conocen como «authoring tools»).
Éste es el primer paso para que el contenido de una web pueda ser
accesible para todos. Las herramientas de creación deben ser accesibles
y generar contenido accesible o ayudar al autor para que lo genere. Así
pues, la primera preocupación será dotar a estas herramientas de las fa-
cultades que propicien que esto sea así.
El 3 de febrero del año 2000, W3C elevó a rango de recomendación
la especificación denominada «Pautas de Accesibilidad para las Herra-
49

mientas de Creación 1.0» (en inglés: «Authoring Tool Accessibility
Guidelines 1.0»). En la actualidad se están revisando estas pautas y ya
existe un borrador para una versión 2.0. Este nuevo documento recoge lo
que considera como cuatro puntos básicos o pautas, que son:
1. Hacer accesible la interfaz de creación. El diseño de todos los as-

pectos de la herramienta de creación, incluyendo la interfaz de crea-
ción, el procedimiento de instalación, la documentación y los archivos
de ayuda, deben ser accesibles. Los requerimientos de accesibilidad
son indispensables para crear la interfaz de creación, prestando espe-
cial consideración al diseño de características específicas de las
interfaces de creación.
2. Permitir la producción de contenido accesible. La creación de
contenido accesible depende de las acciones de la herramienta y del
autor. Esta pauta delimita las responsabilidades que recaen exclusi-
vamente en la herramienta. La primera responsabilidad es apoyar
los formatos que proveen contenido accesible. Es más probable que
el contenido web producido por una herramienta de creación sea ac-
cesible si el contenido creado está en consonancia con los requeri-
mientos de las Pautas de Accesibilidad al Contenido en la Web
(WCAG) y se conserva en este estado a través de todo el proceso
de creación.
3. Apoyar al autor en la producción de contenido accesible. Las he-
rramientas de creación deben incluir características que proporcionen
apoyo y guía al autor en estas situaciones, de tal manera que las prác-
ticas de creación accesible puedan ser seguidas y el contenido accesi-
ble en la web pueda ser producido.
4. Promover e integrar soluciones accesibles. Esta pauta requiere
que las herramientas de autor tengan que promover prácticas de crea-
ción accesible con la herramienta así como integrar sin problemas
cualquier función añadida para satisfacer las otras exigencias de este
documento.
La documentación oficial (en inglés) de estas pautas se pueden con-

sultar en la dirección web: http://www.w3.org/TR/ATAG20/.
50

Accesibilidad en las herramientas de creación
más conocidas
Para la creación de contenidos web los autores manejan distintas he-

rramientas. En ocasiones se trata de programas específicos creados
por empresas de diseño y mantenimiento de páginas web, pero la ma-
yoría de los autores suelen usar herramientas comerciales que se po-
nen a su disposición de forma singular o integradas en paquetes
ofimáticos.
En este apartado vamos a ver dos de las herramientas más conocidas
y difundidas en el mercado: FrontPage de Microsoft y Dreamweaver de
Macromedia.
FrontPage de Microsoft
FrontPage es uno de los programas más populares para la edición de có-

digo HTML de los disponibles en el mercado. Ello es debido a algunas
razones de las que destacamos dos:
Su precio es relativamente bajo comparado con el de otros editores.

Se integra en el paquete MS Office, el paquete ofimático más vendido
del mercado.
Como cualquier otra herramienta, FrontPage tiene sus debilidades:
La plantilla por defecto que usa cuando comienza una nueva página
web no cumple con los estándares para los elementos de HTML, ya
que no incluye la declaración del tipo de documento (DOCTYPE).
Para cambiar las propiedades de los elementos puede, a veces, tener
que realizarse en varios pasos.
Algunas características básicas de accesibilidad deben ser aplicadas
manualmente.
A pesar de estos defectos, es posible crear páginas web accesibles

utilizando FrontPage, a menudo, sin necesidad de salir del entorno
51

WYSIWYG (del inglés «what you see is what you get» – «lo que ves es
cómo quedará»).
Veamos a continuación cómo proceder con FrontPage para crear pá-
ginas web accesibles.
CAMBIAR LA PLANTILLA POR DEFECTO POR UNA QUE SEA VÁLIDA
Uno de los puntos fuertes de FrontPage es la posibilidad de crear planti-

llas. Cuando se crea una plantilla accesible, se puede reutilizar la misma
plantilla para la totalidad de un sitio. Muchos desarrolladores de páginas
web utilizan lenguajes de guión (en inglés: scripting languages) para crear
plantillas, tales como Java Server Pages, PHP, Perl, Cold Fusion y otros.
Estos lenguajes se utilizan por su flexibilidad y capacidad para ser progra-
mados, mucho mayor que en las plantillas de FrontPage y sus caracterís-
ticos «temas». Pero el concepto es el mismo: utilizar plantillas y hacerlas
accesibles.
La página en blanco que muestra por defecto FrontPage al comenzar
no tiene una disposición accesible de forma directa, no cumple con el
estándar HTML. Hay tres cosas que se deben hacer para cambiarla:
1. Añadir una declaración DOCTYPE utilizando el método abreviado

Esta declaración debe ser la primera línea de nuestro documento y es
necesaria para decirle al navegador qué versión de HTML es la que se usa
en la página. Si no se hace, el navegador procesará la página en modo
Quirks (modo de compatibilidad), que podría no interpretar correctamente
el código de la página.
La DTD (definición del tipo de documento) es la estructura reglamenta-
ria, es decir, los elementos y atributos que están disponibles para cada tipo
de documento. Para HTML 4.01 (las versiones anteriores no son recomen-
dables debido a que no son del todo compatibles con las hojas de estilo),
existen 3 tipos de DTD:
1. HTML 4.01 transitorio

El HTML 4 transitorio incluye todos los elementos y cualidades de HTML
4 Strict, pero agrega cualidades de presentación, elementos desapro-
52

bados o elementos obsoletos. Se llama Transitional porque está pensa-
do como transición hacia HTML 4 estricto.
El modo de definirlo es:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN\">
2. HTML 4.01 Frameset:

Ésta es una variante de HTML 4 transitorio para los documentos que
utilizan Frames (marcos).
El modo de definirla es:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Frameset//EN\">
3. HTML Estricto:
Si declaramos este DTD, el navegador pasará a actuar en cumplimien-
to de los estándares (en inglés: standards compliance). Esto implica
que sólo podrán usarse las etiquetas de HTML 4.01. Éste es el modo
recomendado por el W3C, ya que es compatible con el CSS (hojas de
estilo en cascada) y puede ser interpretado correctamente por todos
los navegadores. Además, hace mucho más fácil el paso de nuestros
documentos al XHTML, que en estos momentos ya está sustituyendo
al HTML.
El modo de definirlo es:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN\">
Imagen 3. Declaración DOCTYPE insertada en la vista

de código HTML en FrontPage
53

Si queremos saber si nuestra página cumple con el DTD definido po-
demos comprobarlo desde http://validator.w3.org/
Para incluir la declaración del DOCTYPE en nuestro documento con
FrontPage debemos situarnos en la vista del código HTML y redactarla
en la primera línea del mismo. La versión 2003 de FrontPage tiene una
nueva utilidad que nos posibilita la inclusión de esta línea de código sin
que tengamos que teclearla. Colocando el cursor antes de la etiqueta
<html> presionamos Control+Intro y aparece una lista en la que podre-
mos seleccionar la que deseamos incluir. Al seleccionar, por ejemplo, «dt4»
se insertará el trozo de código correspondiente al DOCTYPE para HTML
4.01.
2. Cambiar la plantilla por defecto a una plantilla accesible

La plantilla por defecto (normal.htm) está localizada en el directorio
«templates» de Microsoft Office. En la mayoría de los ordenadores, este
documento se encuentra en:
C:\Archivos de programa\Microsoft Office\Templates\3082\Pages\normal.tem1
El archivo que hay que cambiar se llama «normal.htm». Hay que abrir
este archivo con cualquier editor de texto (podemos utilizar el Block de
Notas de Windows o cualquier otro similar). Luego cambiamos su conte-
nido para hacerlo compatible con HTML (o en su caso con XHTML o
XML).
La plantilla variará según esté basada en una u otra de las sintaxis de
HTML que se elija. Hay una sintaxis para cada una de las especificacio-
nes. Tendremos que asegurarnos de que la plantilla elegida es compatible
con el estándar, para lo cual podemos utilizar el «validador de HTML» de
W3C (http://validator.w3.org).
La plantilla normal.htm es la única utilizada por el programa cuando
se crean páginas en blanco a las que todavía no se ha asignado una
plantilla o tema de FrontPage. Si se usa cualquiera de las características
de las plantillas o temas, necesitaremos editar la página de la plantilla
para cada uno de estos ítems. Estos archivos de plantilla deberían estar
1. La carpeta «3082» puede llevar otra numeración.
54

localizados en el mismo directorio que el descrito más arriba para la plan-
tilla normal.htm.
3. Creación de plantillas múltiples

Esta técnica es una combinación de las dos anteriores. Si sabemos que
usaremos más de una versión de HTML, podemos crear plantillas múlti-
ples, una para cada versión HTML que planeemos utilizar. Hay dos méto-
dos para hacer esto:
Primero, creando una página de plantilla en FrontPage, o en cualquier

editor de texto, para cada versión HTML que queramos utilizar. Luego,
cuando se quiera crear una nueva página, simplemente abriremos la
plantilla apropiada en lugar de crear una nueva página.
La segunda opción (que sólo se nos ofrece en la versión 2003) es la
misma que la primera, excepto que guardaremos cada nueva plantilla
como un bloque de código en lugar de como un archivo HTML. Para
crear un nuevo bloque de código, iremos a Herramientas>Opciones
de página, luego seleccionaremos Bloques de código (en inglés: Code
Snippets) y pulsaremos en el botón Añadir. Se abrirá una caja con tres
campos:
• Palabra clave: para introducir la palabra que describe al bloque.
• Descripción: para añadir una descripción más larga.
• Texto: es donde introduciremos el código de la nueva plantilla o cual-
quier trozo de código que vayamos a utilizar frecuentemente.
El código generado se introducirá desplegando la barra «vista de códi-

go», presionando Control+intro en el lugar donde queramos introducir el
bloque dentro de la forma de visualización HTML.
AÑADIR EL ATRIBUTO ALT A LAS IMÁGENES

Añadir el atributo alt a las imágenes es sencillo con FrontPage. Pulsando
el botón derecho del ratón sobre la imagen, seleccionamos Propiedades
de la imagen o, con la imagen seleccionada, presionamos Alt+intro.
Después introduciremos el texto que vamos a darle al atributo alt
en el campo Texto del apartado Representaciones alternativas.
55

FrontPage 2003 permite, también, introducir una Descripción larga
utilizando la pestaña General del cuadro de diálogo Propiedades de la
página mediante el campo del mismo nombre que se sitúa debajo del
anterior.
Imagen 4. Cuadro de diálogo (FrontPage 2002)

que utilizaremos para introducir el texto
para el atributo alt.
CREAR MAPAS DE IMAGEN ACCESIBLES DEL LADO DEL CLIENTE

Para crear un mapa de imagen accesible del lado del cliente hay que se-
guir los siguientes pasos:
Insertar la imagen en la página web.

Asegurarse de que la barra de herramientas Imágenes está visible
(Ver>Barras de herramientas>Imágenes).
Utilizar los botones de zona activa rectangular, circular o en forma de
polígono para crear las zonas activas donde queramos que vayan los
enlaces.
56

Para cada zona activa, abriremos el cuadro de diálogo Insertar
hipervínculo, seleccionaremos el botón etiquetado Info. de panta-
lla…, donde introduciremos el texto para el atributo alt de cada área
definida.
La imagen 5 nos muestra el cuadro de diálogo donde podemos intro-

ducir el texto para la información de pantalla del hipervínculo, que hemos
abierto seleccionando el botón correspondiente (ambos aparecen
enmarcados por una elipse para destacarlos). Las versiones FrontPage
2000 y anteriores no disponen de esta utilidad.
Imagen 5. Introducción de texto para el atributo alt de una zona activa.
Se puede añadir el texto para el atributo alt haciendo doble click so-
bre la zona activa y siguiendo los pasos descritos más arriba. No se debe
dejar NUNCA vacío el atributo alt de las zonas activas. También la imagen
sobre la que diseñamos el mapa debe tener su atributo alt aunque, si nos
interesa, podemos dejarlo en blanco (alt=”“).
DEFINIR ENCABEZADOS DE TABLA

Para definir encabezados de tabla para una tabla de datos con FrontPage,
seleccionaremos la celda que queremos hacer de encabezado. Pulsamos
57

el botón derecho del ratón sobre la celda y seleccionaremos Propiedades
de la celda o bien seleccionaremos Tabla>Propiedades>Celda. En el
cuadro de diálogo, activaremos Celda de encabezado.
Imagen 6. Selección de celda de encabezado.
Si la tabla es usada para maquetar (no es una verdadera tabla de

datos) no es necesario especificar encabezados de tabla. Como veremos
más adelante, no es recomendable utilizar tablas para maquetar, ya que
éstas están reservadas para la presentación de datos y que para la coloca-
ción de los contenidos en pantalla tenemos la posibilidad de utilizar las
opciones que nos proporciona la Hoja de Estilos.
AÑADIR ETIQUETAS A LOS ELEMENTOS DE UN FORMULARIO

Seguiremos los siguientes pasos:
Crear un formulario usando Insertar>Formulario.
Cada elemento del formulario (cuadro de texto, botón de opción, casilla
de verificación, menú desplegable…) debe tener un texto descriptivo
que informe al usuario sobre qué debe introducir o seleccionar. La eti-
58

queta se debe poner adyacente al elemento del formulario (aunque téc-
nicamente puede ir en cualquier lugar de la página):
Insertar el elemento del formulario que se desee. Escribir, a continua-
ción el texto para la etiqueta. Seleccionar tanto el elemento como el
texto de la etiqueta y los asociaremos pulsando Insertar>Formulario>
Etiqueta. Ahora están asociados el elemento de formulario con su eti-
queta de texto. Hay que repetir esta operación para cada elemento del
formulario.
Algunas veces la opción Etiquetas de FrontPage no es suficiente. A
menudo, las etiquetas no están adyacentes a los elementos de formu-
lario (por ejemplo, cuando se usan tablas para maquetarlos). Cambiar
la etiqueta que no está adyacente a su elemento de formulario debe
hacerse en la forma de visualización HTML.
PONER TÍTULOS A LOS MARCOS (FRAMES)

Una página web con marcos es la que está definida por, al menos, dos
páginas web separadas, las cuales son combinadas en el mismo espacio
visual. Para el usuario es como si ambas páginas coexistieran como una
sola entidad, es decir, pueden ver los contenidos de múltiples páginas to-
das a la vez.
Los usuarios de algunos lectores de pantalla no pueden apreciar el
contenido de páginas múltiples y relacionar sus contenidos. Los marcos no
son inaccesibles para los modernos lectores de pantalla, pero pueden des-
orientar al usuario. Lo más importante para aumentar la accesibilidad de
los marcos es dar un título a cada uno.
En el nuevo FrontPage 2003 (no existe en versiones anteriores) es
posible crear los títulos para cada marco siguiendo una de estas dos op-
ciones:
1. Se puede hacer añadiendo un título cuando se guarda cada marco.

2. Pulsar el botón derecho del ratón sobre el marco y elegir Propiedades
del marco. En el cuadro de diálogo emergente aparecen varios cam-
pos. Hay que escribir el título descriptivo en el campo etiquetado Tí-
tulo.
59

AÑADIR ENCABEZADO Y SUB-ENCABEZADOS
Hay que usar los encabezados (h1 – h6) para estructurar el contenido y
no para dar formato al texto, de tal manera que parezca un tipo de fuente
o dar apariencia de texto en negrita. Las tecnologías de apoyo y los
navegadores alternativos dependen del lenguaje de marcas, de forma lite-
ral, que determina la estructura de la página.
Para etiquetar los encabezados de nuestra página en FrontPage colo-
caremos el cursor sobre la línea de texto, desplegaremos la lista de opcio-
nes que se nos muestra a la izquierda de la barra de herramientas Forma-
to (por defecto aparece seleccionado Normal) y seleccionaremos qué tipo
de encabezado le corresponde al texto que ya hemos escrito o vamos a
escribir. Al insertar un salto de párrafo, la selección del modo de texto vuel-
ve al estado Normal.
Una información más completa (en inglés) sobre las posibilidades de
construcción de páginas web accesible con FrontPage 2003 está disponi-
ble en: http://www.microsoft.com/office/frontpage/prodinfo/accessibility.mspx
Imagen 7. Lista de opciones del modo de texto

para seleccionar el nivel de encabezado.
60

Dreamweaver de Macromedia
Dreamweaver MX y MX 2004 son de las más populares y potentes aplica-

ciones para el desarrollo web disponibles hoy día. Se han mejorado mu-
cho las características de Dreamweaver MX 2004 con respecto a versio-
nes previas.
Se ha apostado claramente por la posibilidad de generar contenido
accesible, cosa que apreciamos desde el mismo momento en que abrimos
el programa y se nos muestra un cuadro de diálogo donde nos ofrecen la
posibilidad de crear páginas a partir de muestras con diseño accesible (ima-
gen 8).
Imagen 8. Cuadro de diálogo que nos ofrece la posibilidad de crear

páginas web en base a muestras diseñadas de forma accesible.
Las nuevas versiones de MX y MX 2004 permiten que el desarrollador

sea orientado para añadir atributos de accesibilidad cuando inserta algu-
nos elementos web. Desafortunadamente esta opción está desactivada en
las preferencias por defecto. Para activar esta opción, hay que seleccionar
Edición>Preferencias>Accesibilidad y activar las casillas de verificación
de Objetos de formulario, Marcos, Media e Imágenes (imagen 9).
61

Imagen 9. Forma de activar las opciones de accesibilidad
en Dreamweaver MX 2004.
Una vez seleccionado, Dreamweaver dispondrá de un sistema de orien-

tación para las características de accesibilidad cuando cada uno de los
elementos identificados sea insertado en el documento. Para que las orien-
taciones sobre accesibilidad estén disponibles, debe trabajarse sobre la
vista «Diseño» en la interfaz. Si se encuentra en la vista «Código» cuando
inserte alguno de los elementos, la orientación de accesibilidad no se mos-
trará.
Este programa de diseño puede ahora validar el contenido accesible
utilizando los estándares más comunes, así como proporcionar un informe
seleccionando Sitio>Informe.
Entre otros materiales de referencia se incluye uno sobre Accesibili-
dad. Los materiales provienen de UsableNet (http://www.usablenet.com).
Lamentablemente los materiales son demasiado técnicos y hacen preciso
estar familiarizado con HTML y las técnicas generales de accesibilidad.
Macromedia también ha aumentado la accesibilidad de la interfaz de
creación para permitir a los usuarios de lectores de pantalla crear contenido
web. Ahora son accesibles a los programas lectores de pantalla la mayoría
de los cuadros de diálogo, los menús y otros elementos de la interfaz.
62

TEXTO ALTERNATIVO PARA LAS IMÁGENES
Con las opciones de accesibilidad habilitadas en las preferencias, se mos-
trará un cuadro de diálogo para introducir el texto alternativo y el enlace a
la descripción larga cuando se inserte una imagen.
Imagen 10. Cuadro de diálogo para insertar el texto alternativo

y el enlace a la descripción larga.
Basta introducir el texto apropiado y equivalente a la imagen en el campo

Texto alternativo. Si la imagen es compleja, se puede introducir una di-
rección URL o un marcador de la propia página utilizado para una descrip-
ción larga (atributo longdesc de la etiqueta img). Si no se introduce conte-
nido en la descripción larga, el atributo longdesc no es introducido en el
código de la imagen. Si a la imagen no conviene darle texto alternativo
(por ser meramente decorativa o no proporcionar funcionalidad alguna) se
puede seleccionar <vacío> en el campo Texto alternativo que proporcio-
nará un texto alternativo de la siguiente manera: alt=’’’’.
Una vez que la imagen ha sido insertada en el documento, el texto
alternativo puede ser insertado o modificado utilizando el panel Propie-
dades que, por defecto, aparece bajo el área de diseño. También aquí
se puede seleccionar la opción <vacío> en el menú desplegable del
atributo alt. El atributo longdesc no puede ser insertado desde este
panel.
También se proporciona la opción de insertar texto alternativo a las
zonas interactivas del mapa de imagen del lado del cliente. Cuando se
inserta una zona interactiva en la imagen, aparece en el panel de Propie-
dades, entre otras, la opción de poner texto alternativo a ésta.
63

ETIQUETAS DE FORMULARIO
Con las opciones de accesibilidad habilitadas en preferencias, Dreamweaver
orientará para etiquetar de forma apropiada cuando se inserten los ele-
mentos de formulario en la página web.
Imagen 11. Cuadro de diálogo para el etiquetado

de los elementos del formulario.
Sólo hay que introducir el texto apropiado para la etiqueta en el campo

Etiqueta del cuadro de diálogo. Se puede seleccionar uno de los estilos
para la etiqueta: «Ajustar con la etiqueta de rótulo»; «adjuntar etiqueta de
título utilizando el atributo for»; o «no hay etiqueta de rótulo». El mejor
resultado se consigue seleccionando «adjuntar etiqueta de título utilizando
el atributo for». Esto permite a la etiqueta del formulario ser movida a
otra posición en la página y es más compatible con los lectores de pantalla
existentes. También se puede elegir la posición de la etiqueta de formulario
antes o después del ítem. El cuadro de diálogo «Atributos de accesibilidad
de la etiqueta de entrada» también proporciona opciones para introducir
tecla de acceso (Access key) e índice de fichas.
Para añadir etiquetas a los elementos del formulario ya insertados en
la página, hay tres métodos que pueden ser usados:
1. Borrar y luego reinsertar el elemento del formulario añadiendo la eti-

queta apropiada por medio del cuadro de diálogo.
2. Añadir la información apropiada a la etiqueta desde la vista de código.
3. Seleccionar la etiqueta y el elemento del formulario y seleccionar
Insertar>Formulario>Etiqueta. Para llevar a cabo este método de tra-
64

bajo, la etiqueta y el elemento de formulario deben estar adyacentes.
Cuando se usa este método, Dreamweaver rodea la etiqueta y el ele-
mento de formulario con la etiqueta de rótulo, lo cual limita la posibili-
dad de mover la etiqueta y no es completamente soportado por todos
los lectores de pantalla.
ACCESIBILIDAD EN LAS TABLAS DE DATOS

Hay tres principios implicados en la tarea de hacer tablas de datos accesi-
bles para los usuarios de lectores de pantalla:
1. Diseñar los encabezados de tabla.

2. Asignar una orientación (en inglés, scope) a los encabezados de fila y
columna.
3. Para tablas complejas, asignar atributos headers (encabezados) e id
(identificadores) a cabeceras y celdas de datos.
La interfaz visual de Dreamweaver soporta la opción 1 (asignación de

encabezados), parcialmente la 2 (asignación de orientación) y no soporta
la 3.
Para asignar encabezados a la tabla dispone de dos procedimientos.
Primero, si la tabla ya existe, se pueden identificar los encabezados de
tabla seleccionado la celda, fila o columna y luego seleccionar en el panel
Propiedades el campo Enc. (Encabezado).
Segunda, si las opciones de accesibilidad están disponibles en prefe-
rencias, se presentará un cuadro de diálogo cuando la tabla vaya a inser-
tarse. Se puede elegir que la tabla no tenga encabezados (Ninguna), en-
cabezados de fila (Izquierda), encabezados de columna (Superior) o
encabezados de fila y columna (Ambos).
Imagen 12. Selección de encabezado en una tabla de datos.
65

Se designarán las celdas correctas como encabezados de tabla utili-
zando la etiqueta <th>. Cuando se use el cuadro de diálogo proporciona-
do por las opciones de accesibilidad para seleccionar los encabezados,
también se insertará el atributo scope apropiado a esos encabezados (por
ejemplo: scope=col o scope=row).
Imagen 13. Segundo modo de elegir encabezados

para una tabla de datos.
Si se elige la opción Ambos para los encabezados, se designará la

celda superior izquierda como encabezado de columna. En algunos ca-
sos esta celda debe actuar como encabezado de fila o no ser encabeza-
do de nada. Debemos asegurarnos en cualquiera de los casos de borrar
o cambiar el atributo scope para esta celda en la vista de código para
que sea marcada de forma apropiada en el maquetado de la tabla de
datos.
La única manera de añadir el atributo scope a tablas que ya existen
en el documento es hacerlo manualmente en la vista de código. Para ta-
blas complejas con encabezados que abarcan filas o columnas y para las
cuales el atributo scope es insuficiente, se debe añadir atributos headers
e id a la tabla en la vista de código. La interfaz visual no soporta la adición
de los citados atributos.
66

El cuadro de diálogo también permite la adición de Texto para el pie
(Caption) y Resúmenes (Summary); ambos proporcionan información adi-
cional sobre los contenidos de la tabla.
TÍTULOS DE LOS MARCOS (FRAMES)

Si las opciones de accesibilidad se han seleccionado en las preferencias,
el programa proporciona orientación para colocar los títulos de los marcos
cuando se va a crear un documento con marcos.
Imagen 14. Cuadro de diálogo para introducir

títulos de marcos.
La opción Título debe ser una breve descripción del contenido y

funcionalidad del marco. Esta información será leída por los lectores de
pantalla para identificar el marco. El cuadro de diálogo «Atributos de acce-
sibilidad de la etiqueta de marco» sólo será mostrado si se crea un docu-
mento con marcos (Archivo>Nuevo>Conjunto de marcos) y no se mos-
trará si se modifica un documento existente en una página que ya tiene
marcos (Modificar>Conjunto de marcos>Dividir marco…).
67

68

Las aplicaciones o agentes de usuario
En la imagen 15 podemos ver cuáles son los elementos de accesibilidad a

las páginas web.
Imagen 15. Elementos de accesibilidad a las páginas web.
Para poder acceder a los contenidos que los desarrolladores colocan

en la web, los usuarios utilizan lo que conocemos como Aplicaciones o
agentes de usuario (en inglés: User agent). Lo habitual es que lo hagan
mediante programas de software a los que se conoce genéricamente como
Navegadores. Son programas que generalmente se distribuyen de forma
gratuita. Se han convertido en compañeros inseparables de todos los que
usan un ordenador para acceder a la información colocada en web, compi-
tiendo en horas de uso con los procesadores de texto. Su familiaridad hace
que casi no prestemos importancia a sus posibilidades, su utilidad y, algo
que nos importa particularmente, su accesibilidad.
La Iniciativa de Accesibilidad en la Web W3C/WAI, ha redactado una
«especificación» que proporciona pautas para los desarrolladores de las
aplicaciones de usuario. Su objetivo es que estas aplicaciones dispongan
69

de las medidas necesarias para que puedan ser usadas por personas con
limitaciones funcionales o que accedan mediante dispositivos no
estandarizados.
El 17 de diciembre de 2002, W3C elevó a rango de recomendación
la especificación denominada «Pautas de Accesibilidad para las Aplica-
ciones de Usuario 1.0» (en inglés: «User Agent Accessibility Guidelines
1.0» – UAAG10). En este documento se recogen los puntos básicos o
pautas que se consideran imprescindibles para hacer que esas aplicacio-
nes sean accesibles. Éstos son los doce puntos básicos que recoge la
recomendación:
1. Soportar la entrada y salida de datos, con independencia del dis-

positivo utilizado. Asegurar que el usuario puede interactuar con la
aplicación de usuario (y el contenido que presenta) a través de dife-
rentes dispositivos de entrada y salida de datos.
2. Asegurar que el usuario accede a todo el contenido. Asegurar que
el usuario tiene acceso a todo el contenido, particularmente al conte-
nido condicional (entendido como el que, por el formato de la especi-
ficación, debe estar disponible para el usuario a través de la interfaz
en ciertas condiciones, como el texto alternativo de la imágenes) que
debe haber sido proporcionado cumpliendo con los requerimientos de
las Pautas de Accesibilidad al Contenido en la Web 1.0 (en inglés:
Web Accessibility Content Guidelines 1.0 – WCAG10).
3. Permitir la configuración de manera que no deje algún contenido
que pueda reducir la accesibilidad. Asegurar que el usuario puede
desconectar la presentación del contenido (por ejemplo, audio, vídeo
o scripts) que pueda reducir la accesibilidad obstruyendo a otros con-
tenidos o desorientando al usuario.
4. Asegurar que el control de la presentación lo tiene el usuario.
Asegurar que el usuario puede seleccionar los estilos preferidos (por
ejemplo, colores, tamaños del texto presentado o las características
de la síntesis de voz) mediante la selección ofrecida por la aplicación
de usuario. Permitir al usuario anular los estilos especificados por el
autor y los estilos por defecto de la aplicación de usuario.
5. Asegurar que el control del comportamiento de la interfaz lo tie-
ne el usuario. Asegurar igualmente que el usuario puede controlar el
70

comportamiento de las ventanas del navegador y los controles de la
interfaz de usuario, incluyendo los que pueden ser manipulados por el
autor (por ejemplo, a través de scripts).
6. Aplicar interfaces de programación inter-operables para la apli-
cación. Aplicar interfaces inter-operables para comunicar con otros
programas (por ejemplo, tecnologías de ayuda, entornos del sistema
operativo y plug-ins).
7. Cumplir con las convenciones de los entornos del sistema ope-
rativo. Cumplir con dichas convenciones tanto en la interfaz de la apli-
cación de usuario, como en la documentación, la configuración de
entrada de datos y la instalación.
8. Aplicar las especificaciones que benefician la accesibilidad. Apo-
yar las características de accesibilidad de todas las especificaciones
aplicadas. Hay que tener en cuenta las Recomendaciones de W3C
cuando estén disponibles y sean apropiadas para una tarea.
9. Proporcionar mecanismos de navegación. Proporcionar acceso al
contenido a través de una variedad de mecanismos de navegación,
incluyendo navegación secuencial, navegación dirigida, búsquedas y
navegación estructurada.
10. Orientar al usuario. Proporcionar información que ayude al usuario a
entender el contexto de navegación.
11. Permitir la configuración y personalización. Permitir al usuario que
configure su aplicación de usuario para que las tareas que realiza con
frecuencia las haga bien y permitir al usuario aplicar sus preferencias.
12. Proporcionar en forma accesible la documentación y las ayudas
de la aplicación de usuario. Asegurar que el usuario puede entender
las características del software que benefician la accesibilidad en la
documentación aportada. Asegurar que la documentación es accesi-
ble.
La documentación oficial de estas pautas (en inglés) se puede consul-

tar en la dirección web: http://www.w3.org/TR/UAAG10/guidelines.html.
71

Accesibilidad en las aplicaciones de usuario
más comunes
Existe un gran número de aplicaciones de usuario que se utilizan para na-

vegar por la web. Pero sólo un reducido número de ellas son utilizadas por
los usuarios de forma habitual. Vamos a ver, en este apartado, las caracte-
rísticas de accesibilidad que presentan algunas de ellas. Las cuatro esco-
gidas lo son en función del gran número de usuarios que las utilizan. Éstas
son:
Internet Explorer 6.0 de Microsoft.

Firefox 1.5 de Mozilla.
Netscape 7.0 Navigator.
Opera 7.54.
Es importante tener en cuenta que los desarrolladores de navegadores

incorporan con cierta frecuencia nuevas versiones de sus programas. Es
esperable que las nuevas versiones de estos navegadores incorporen me-
jores utilidades para el acceso a la web y para la personalización de la
navegación por parte del usuarios, haciéndola más ajustada a sus necesi-
dades y demandas.
Características de accesibilidad de Internet Explorer
Para descargar de forma gratuita este programa:

http://www.microsoft.com/downloads/search.aspx?displaylang=es
Internet Explorer de Microsoft es el navegador web más utilizado en
todo el mundo. La causa no es otra que su integración en el sistema ope-
rativo que más ha calado en el mundo de la informática doméstica: Windows
de Microsoft. Por lo tanto, cualquier ordenador que tenga instalado este
sistema operativo, por defecto, llevará instalado el navegador IExplorer
(como se le conoce en abreviatura), lo que supone que la mayoría de los
ordenadores domésticos y muchísimos de los que se utilizan en el ámbito
laboral disponen de él.
72

Imagen 16. Internet Explorer 6.0 de Microsoft.
Dado el peso específico que tiene en la navegación por la web (según

fuentes se apunta que entre un 80% y un 95% de los usuarios de la Red
acceden con este navegador), el que disponga de características de acce-
sibilidad resulta muy importante.
OPCIONES DE ACCESIBILIDAD EN IEXPLORER

Las opciones que este navegador presenta para poder ser manejado en
condiciones de accesibilidad las encontramos en Herramientas>Opciones
de Internet donde se abre un cuadro de diálogo con varias pestañas. En
la General podemos encontrar distintas opciones, entre las que se en-
cuentra la de Accesibilidad.
73

Imagen 17. Cuadro de diálogo que ofrece acceso
a las opciones de accesibilidad.
Las posibilidades que nos ofrece seleccionar son las siguientes:
Omitir colores especificados en páginas web: Seleccionando esta

opción nuestro navegador mostrará las páginas web con los colores
por defecto asignados a los elementos por HTML (por ejemplo, los en-
laces los mostrará en azul, si no están visitados, y en granate una vez
los hayamos visitado, y no como los haya definido el autor). Puede ser
muy útil para orientar al usuario sobre dónde se encuentran los enlaces
y anular ciertas combinaciones de colores para aquellos que tengan
problemas de visualización.
Omitir estilos de fuentes especificados en páginas web: Con esta
opción hacemos que la visualización de las páginas se haga con el
estilo de fuente definido por defecto en nuestro navegador.
74

Omitir tamaño de fuentes especificado en páginas web: Esta op-
ción permite anular el tamaño especificado para las fuentes por el autor
y posibilita al usuario una cierta ampliación o reducción de ellas, si lo
precisa.
Dar formato a los documentos utilizando mi hoja de estilos: Selec-
cionando esta opción, el programa nos pide la ubicación de la hoja de
estilos que pretendemos aplicar y que previamente habremos construi-
do con nuestras preferencias. Esta hoja de estilos se aplicará a toda
las páginas que visitemos mientras tengamos seleccionada la opción y
nos permite elegir una amplísima gama de posibilidades para visualizar
el formato de las páginas de acuerdo a nuestras necesidades (fuentes
más grandes, cambio de colores, eliminación de fondos, etc.).
Imagen 18. Cuadro de diálogo Accesibilidad con

las opciones que podemos seleccionar.
AUMENTAR EL TAMAÑO DE LA FUENTE

IExplorer, como la mayoría de los navegadores, nos permite aumentar el
tamaño de la fuente en la página visualizada mediante Ver>Tamaño de
texto y seleccionando entre las cinco posibilidades que ofrece (mayor, gran-
de, mediana, pequeña y menor; por defecto viene seleccionada la media-
na).
75

Es importante tener en cuenta que esta opción no nos será de utilidad
si el autor ha definido en su hoja de estilo un tamaño en unidades absolu-
tas (pixels o centímetros) en lugar de haberlo hecho en unidades relativas
(porcentaje o em). Para modificar el tamaño de la letra en estos casos
tendremos que acudir a las opciones apuntadas en el párrafo anterior.
Imagen 19. Selección de aumento o disminución del tamaño del texto.
BLOQUEO DE VENTANAS EMERGENTES

Una de las situaciones que más despistan a los usuarios que no pueden
ver la pantalla del ordenador es cuando se abren nuevas ventanas en la
misma sin avisarlos. Esto sucede, por ejemplo, cuando el autor ha definido
una nueva ventana como destino de un enlace o cuando se incluyen Pop-
up publicitarios.
IExplorer permite bloquear la apertura de estas ventanas emergentes y
avisar al usuario de que el programa está tratando de abrir una nueva
ventana. Para seleccionar las distintas opciones de bloqueo que nos per-
mite, seguiremos la ruta Herramientas>Bloqueador de elementos
emergentes>Configuración del bloqueador de elementos emergentes.
76

Imagen 20. Cuadro de diálogo para la configuración
del bloqueador de elementos emergentes.
En el cuadro de diálogo para la configuración del bloqueador podemos

definir a qué sitios permitimos que nos presenten elementos emergentes,
la reproducción de sonido cuando se produzca un bloqueo, la presentación
de una barra que nos muestre la información del bloqueo y el nivel de
filtrado (alto, medio o bajo) que aplicamos para los elementos emergentes.
COMPATIBILIDAD CON TECNOLOGÍAS DE APOYO

IExplorer es compatible con algunas tecnologías de apoyo, como es el
caso de los lectores de pantalla. Probablemente es el navegador que ma-
yor compatibilidad presenta (no en vano a los propios lectores de pantalla
les interesa ser compatibles con el navegador más usado) como es el caso
de Jaws de Freedom Scientific (diseñado específicamente para trabajar
con Windows) o Home Page Reader de IBM.
También muestra una gran compatibilidad con las síntesis de voz que
se utilizan para dar instrucciones al programa durante la navegación (por la
77

misma razón apuntada en el párrafo anterior). Así, programas como Dragon
Naturally Speaking de ScanSoft o Via Voice de IBM no muestran ningún
problema de compatibilidad.
BARRA DE HERRAMIENTAS DE ACCESIBILIDAD AIS

Technosite (Fundosa Teleservicios S.A.) ha traducido y puesto a disposi-
ción de los usuarios de IExplorer una barra de herramientas para compro-
bar y promover la accesibilidad en la web.
Se trata de una herramienta denominada AIS (Accessible Information
Solutions) Web Accessibility Toolbar que nos permite:
Imagen 21. Barra de herramientas AIS incorporada al navegador IExplorer.
Validar el código HTML y CSS de la página que estamos visualizando

con distintas herramientas automáticas.
Especificar y personalizar de forma rápida el tamaño de visualización
(640x480, 800x600, 1024x768 o cualquier otro personalizado).
Activar, desactivar y mostrar las hojas de estilo aplicadas, así como
mostrar la existencia de elementos HTML 4 desaconsejados en la pági-
na visualizada.
Mostrar o no las imágenes en la página visualizada así como los textos
alternativos, en caso de existir.
Mostrar la página en escala de grises así como mostrar los colores
empleados en la página y analizar el contraste entre ellos.
Mostrar la estructura del documento en pantalla con un alto nivel de deta-
lle en cuando a los elementos estructurales incorporados a la misma.
Emplear una serie de utilidades que van desde analizadores automáti-
cos de la accesibilidad en el código de la página visualizada, hasta la
simulación de algunos efectos, como la lectura de la página por un
navegador sólo texto o cómo vería la página una persona daltónica. La
78

amplia variedad de utilidades que se presentan en este apartado impi-
de entrar en detalle en las mismas.
Ofrecer información sobre el documento en pantalla, como los
metadatos, el tamaño y tiempo de descarga o la lista de marcos o
enlaces.
Proporcionar referencias a documentos sobre pautas de accesibilidad,
recursos sobre accesibilidad y usabilidad y referencias del lenguaje de
codificación.
Proveer atajos para activar y desactivar elementos de IExplorer, cam-
biar el tamaño del texto o acceder al cuadro de diálogo de opciones de
accesibilidad antes descrito.
Disponer de una lupa de pantalla o magnificador que nos permite redu-
cirla (hasta un 25%) o ampliarla (hasta un 600%).
Esta barra de herramientas, en su versión en castellano, se puede des-

cargar de: http://www.technosite.es/software.asp
Características de accesibilidad en Firefox

Podemos descargar este programa de forma gratuita en:
http://www.mozilla-europe.org/es/products/firefox/
Imagen 22. Firefox 1.5 de Mozilla.
79

Se trata del navegador que está ocupando el segundo lugar (a mucha
distancia del IExplorer) en el ranking de más utilizados por los usuarios de
la web. Heredero de la trayectoria de los navegadores conocidos como
Mozilla, en sus distintas versiones, ha ido escalando puestos a gran veloci-
dad desbancando a otros navegadores de más solera.
Su gran compatibilidad y parecido en el aspecto externo con el
navegador de Microsoft, ha facilitado que muchos usuarios no hayan teni-
do remilgos en sustituir su habitual IExplorer por este nuevo programa.
Dispone de bastantes posibilidades en lo que se refiere a característi-
cas de accesibilidad, pero aquí veremos las más destacables.
OPCIONES DE ACCESIBILIDAD EN FIREFOX

Para acceder a las opciones de accesibilidad que presenta este navegador
debemos seguir la ruta Herramientas>Opciones>Avanzadas.
Imagen 23. Opciones de accesibilidad en Firefox 1.5.
Presenta sólo dos opciones, algo extrañas:
1. Mostrar el cursor del sistema con cambios foco/selección: sirve para

que, al navegar con lectores o magnificadores de pantalla, el cursor se
desplace a la aplicación que éstos enfocan.
80

2. Usar búsqueda al tipear (entiéndase este modismo como teclear o es-
cribir con el teclado): esta opción permite que cuando tecleamos el nom-
bre de una dirección web que queramos encontrar, vayan apareciendo
bajo la barra correspondiente los nombres de direcciones que anterior-
mente se hayan buscado y cargado desde ésta. Esta opción se presen-
ta por defecto en otros navegadores, como IExplorer, pero con Firefox
la debemos activar.
Éstas no son las únicas posibilidades que nos ofrece este navegador
en lo que se refiere a características de accesibilidad. Veamos algunas
más.
CAMBIAR EL TAMAÑO DEL TEXTO

Permite, como casi todos los navegadores, cambiar el tamaño del texto
(las imágenes permanecen con el mismo tamaño), pero en este caso lo
hace mediante una combinación de teclas:
Aumentar: pulsando control y la tecla +, hasta 8 veces.

Disminuir: pulsando control y la tecla -, hasta 8 veces.
Normal: para ver el tamaño de letra por defecto hay que pulsar control
y la tecla 0 (cero) en el teclado alfanumérico.
Esta opción la ejecuta con mayor eficiencia que otros navegadores

como IExplorer, ya que consigue cambiar el tamaño de fuentes que hayan
sido definidas en unidades absolutas (pixels o centímetros) en lugar de
relativas (porcentaje o em).
DESACTIVAR LOS ESTILOS DEFINIDOS POR EL AUTOR

Siguiendo la ruta Ver>Estilo de página podremos seleccionar la opción
Sin estilo, lo que desactivará los estilos definidos por el autor y aplicará
los que estén definidos por defecto en el navegador.
81

Imagen 24. Posibilidad de desactivar los estilos definidos
por el autor en Firefox 1.5.
Esto no supone la desactivación completa de la hoja de estilo, ni da la

posibilidad de aplicar una hoja de estilo definida por el usuario, como suce-
día en IExplorer.

Firefox permite bloquear la apertura de nuevas ventanas sin la participa-
ción activa del usuario. Siguiendo la ruta Herramientas>Opciones>Con-
tenidos podremos bloquear la apertura de ventanas emergentes.
Imagen 25. Opción para bloquear ventanas emergentes en Firefox 1.5.
82

Este navegador nos da la posibilidad de permitir que para los sitios
que el usuario defina se permita la apertura de ventanas emergentes.
Mediante este mismo cuadro de diálogo (Herramientas>Opciones>Con-
tenidos) el usuario puede prescindir de cargar imágenes, lo que posibilita
una navegación más rápida, y habilitar o no tanto Java como JavaScript.
FIREVOX, LECTOR DE PANTALLA PARA FIREFOX

Una de las características básicas de un navegador que proviene de las
prácticas llevadas a cabo entre los partidarios del software libre y el desa-
rrollo compartido, es la posibilidad de incorporar extensiones. Éstas son
desarrolladas voluntariamente por desarrolladores de programas y puestas
a disposición de todos de forma gratuita.
Una de las más relevantes para la accesibilidad es la denominada
Firevox (que puede ser descargada en http://firevox.mozdev.org/). Se trata
de un lector de pantalla para el navegador Firefox 1.5 que utiliza las voces
que nuestro ordenador tenga instaladas. Su sencillez de instalación y uso
convierte a esta extensión en una potente herramienta de accesibilidad,
que muestra una muy buena compatibilidad con otros lectores de pantalla
que el usuario pueda tener instalados en su ordenador.
Imagen 26. Acceso a las opciones de Firevox

desde la barra de tareas de Firefox 1.5.
83

Una vez instalada, esta extensión pone sus opciones a disposición del
usuario en la barra de tareas desde Herramientas>Firevox Options.
La única pega es que no existe (en estos momentos) una versión
castellanizada de los textos de esta extensión, si bien hace un buen uso de
las voces castellanas que se tengan instaladas.
WEB DEVELOPER TOOLBAR

Web Developer Toolbar (que podemos traducir como Barra de Herramien-
tas para Desarrolladores Web) es otra de las interesantes extensiones de
Firefox para la accesibilidad. De características similares a las descritas
para la Barra de Herramientas de Accesibilidad del IExplorer, es de gran
utilidad tanto para desarrolladores como para todos aquellos que quieran,
de forma rápida, activar o desactivar ciertas funciones, analizar el código
de una página y otras interesantes funciones.
Imagen 27. Web Developer Toolbar, barra de herramientas

para desarrolladores web de Firefox.
Son muchas las posibilidades que tiene esta extensión y exceden las
posibilidades de este documento. Por tal motivo, animo al lector a que
experimente directamente con ella.
Sólo se puede poner una pega a esta extensión: no está castellanizada
en estos momentos, lo que supone una considerable limitación para aque-
llos que no se manejen con suficiente soltura en inglés.
Características de accesibilidad en Netscape
Podemos descargar este programa de forma gratuita en:

http://www.aola.com/netscape/download/
Se trata de uno de los navegadores gratuitos de más historia, herede-
ro de un auténtico clásico: Mosaic. Compitió con el navegador de Microsoft,
aunque siempre a una discreta distancia, pero entre los usuarios ha perdi-
do, con el paso del tiempo, mucha clientela. Ha sido desbancado por el
84

navegador de Mozilla en el segundo puesto del ranking y ahora trata de
recuperar el campo perdido.
Imagen 28. Netscape 7.0 Navigator.
La peculiaridad de este programa es que no se trata de un simple

navegador, sino que ofrece la posibilidad de utilizar, también, una herra-
mienta de creación (denominada Composer), un programa de correo elec-
trónico, un servicio de mensajería instantánea (denominado ICQ) y una
libreta de direcciones.
OPCIONES DE ACCESIBILIDAD EN NETSCAPE

Al contrario de lo que sucede con los anteriores navegadores de los que
hemos hablado, Netscape no presenta opciones específicas de accesibili-
dad. Es decir, no encontramos un apartado en el que nos ofrezcan unas
opciones directamente encaminadas a facilitar la accesibilidad.
Ello no quiere decir que no posea algunas características que facilitan
la accesibilidad, aunque esto no es relevante en este navegador.
85

Si seguimos la ruta Editar>Preferencias accederemos a una ventana
de diálogo que nos permite la selección de preferencias para la navega-
ción. Como antes decíamos, no existe un apartado especial para la acce-
sibilidad pero sí encontramos la posibilidad de, mediante las opciones de
Navegación inteligente, posibilitar la función de completar automáticamente
el texto escrito en la barra de ubicación, lo que facilita a las personas con
poca funcionalidad en sus manos acelerar esta tarea para aquellas direc-
ciones web que ya han tecleado en alguna ocasión anterior.
Imagen 29. Función para completar automáticamente lo escrito en la barra de

ubicación en Netscape 7.
86

MODIFICACIÓN DEL TAMAÑO DEL TEXTO
Netscape posibilita modificar el tamaño de visualización del texto (la apli-
cación de esta opción no modifica el tamaño de las imágenes), lo cual
posibilita la adaptación de la visualización del texto en pantalla a las nece-
sidades del usuario.
Imagen 30. Aumentar o disminuir el texto con Netscape 7.
Para cambiar el tamaño del texto se nos ofrecen dos posibilidades.
1. La primera de ellas es mediante la combinación de las teclas Control y

la tecla «+» o «-« (según queramos aumentar o disminuir el tamaño).
Con esta opción se nos permite incrementar con la primera pulsación al
120% del tamaño original, con la segunda al 150% y con la tercera al
200%. Cuando lo que hacemos es disminuir, con la primera pulsación
el texto se muestra en un 90% del tamaño original, con la segunda un
75% y con la tercera un 50%.
87

2. La segunda es mediante la ruta Ver>Zoom de texto (tras la opción
Zoom de texto aparece el porcentaje que está seleccionado). Se des-
pliega una ventana de selección que nos permite elegir una de las op-
ciones predeterminadas u otro tamaño, mediante la apertura de una
ventana de diálogo donde podremos introducir un valor entre 1 y 2.000%.
La posibilidad de cambiar el tamaño del texto nos la ofrece Netscape

aunque el autor haya definido éste en forma absoluta (puntos, pixels o
centímetros) y no de forma relativa (porcentaje o em).
Características de accesibilidad de Opera
Para descargar este programa de forma gratuita (con publicidad):

http://www.opera.com/download/
Imagen 31. Navegador Opera 7.54.
Opera es un navegador que ha gozado del favor de los que nos dedi-
camos al mundo de la accesibilidad en la web por su apuesta, desde hace
años, por introducir este tipo de opciones dentro del formato estándar de
su programa. Se trata de un programa que, además del navegador, inclu-
88

ye un gestor de correo electrónico y una aplicación para llevar a cabo en-
cuentros en la web (los conocidos «chats»). Tiene una versión que está a
la venta por un precio módico y otra de descarga gratuita. Esta última
inserta un apartado de publicidad, que podemos configurar con nuestras
preferencias, pero del que no podremos deshacernos. La última versión
disponible en castellano está numerada como 7.54 y el área de publicidad
ha sido rediseñada y parece estorbar menos que en anteriores versiones,
permitiendo una visualización algo más grande del área de navegación.
OPCIONES DE ACCESIBILIDAD EN OPERA

Si seguimos la ruta Herramientas>Opciones se abre un cuadro de diálo-
go, muy completo, que nos permite configurar un gran número de opcio-
nes. Ésta es una de las virtudes de este navegador, su gran flexibilidad
para acoplarse a las necesidades del usuario. No encontraremos en este
cuadro un apartado concreto dedicado a las opciones de accesibilidad, ya
que ésta es considerada como algo estándar por los desarrolladores del
programa que está presente en todas las opciones estándar donde sea
precisa y, por tal motivo, ha descartado la introducción de un «apartado»
específico.
Imagen 32. Cuadro de diálogo para configurar las opciones

de usuario en Opera 7.54.
89

Por otro lado, muchas de las opciones que podemos configurar desde
este cuadro de diálogo, las tenemos disponibles en la interfaz de navega-
ción para hacer más rápida su configuración, sin tener que recurrir a los
varios clic que supone ir a través de la vía Herramientas>Opciones. Este
acceso rápido a ciertas funciones está disponible mediante unos botones
situados en la parte superior derecha del área de navegación, que nos
permiten:
La modificación del tamaño de la imagen (no sólo de la letra).

El acceso a las funciones de seguridad.
Cambiar las opciones de visualización de imágenes y del estilo de pre-
sentación de la página.
Imagen 33. Botones de acceso rápido para la modificación

de ciertas opciones en Opera 7.54.
También, como veremos más adelante, nos permite la modificación de

algunas opciones mediante teclas o combinaciones de teclas, lo que per-
mite al usuario interactuar más ágilmente con la interfaz.
Veamos ahora algunas de las características de accesibilidad más re-
levantes que presenta el navegador Opera.
AUMENTAR EL TAMAÑO DE LA VISUALIZACIÓN

En anteriores navegadores hemos visto cómo permitían incrementar el ta-
maño del texto, pero no permitían que se incrementara el tamaño de las
imágenes que lo acompañan. En el caso de Opera la función de incremen-
to o disminución del texto actúa como una lupa que modifica la visualiza-
ción de toda la página (tanto texto como imágenes), respetando el modo
de presentación.
La activación de esta opción se puede hacer, como ya se ha dicho en
el apartado anterior, a través de un botón que se sitúa en la parte superior
derecha del área de navegación ( ) que nos permite seleccio-
90

nar el porcentaje de aumento o disminución de toda la página visualizada
desde un 20 hasta un 1.000%. Por defecto está seleccionada la visualiza-
ción en un 100%, pero esto lo podemos modificar en el cuadro de diálogo
de Herramientas>Opciones seleccionando la visualización por defecto que
más nos interese en la opción Escala predeterminada de Estilo de pá-
gina.
Una forma más rápida de modificar la escala de visualización de la
página se nos presenta mediante el uso del teclado o del ratón:
Utilizando el teclado, podemos aumentar el tamaño de visualización

pulsando la tecla «+» (o la tecla «0», cero) o disminuirlo con la tecla «-
« (o la tecla «9»). El cambio de visualización se hará en intervalos de
un 10%. Si queremos una modificación más drástica, podemos pulsar
la tecla «Control» y las teclas «+» (u «8») o «-« (o «7»), con lo que se
producirán saltos de un 100%. Para regresar a la visualización por de-
fecto basta pulsar la tecla «*», asterisco, del teclado numérico (o «6»).
Si nuestro ratón dispone de rueda, podemos aumentar o disminuir la
visualización pulsando la tecla Control y moviendo la rueda hacia delan-
te (aumenta la visualización a intervalos de un 10%) o hacia atrás (dis-
minuye la visualización a intervalos de un 10%). Para regresar a la vi-
sualización por defecto, pulsamos Control y hacemos clic con la rueda
del ratón.
Como vemos, los desarrolladores de Opera han pensado en la posibi-

lidad de facilitar, particularmente a aquellos usuarios que tienen deficien-
cias visuales, la visualización de las páginas navegadas y han utilizado di-
ferentes vías (teclado o ratón) para realizar la función de modificación del
tamaño, que actúa tanto sobre el texto como sobre las imágenes.
CARGA DE IMÁGENES Y CAMBIO DEL ESTILO DE LAS PÁGINAS

En el mismo sentido de flexibilidad y adaptación a las necesidades del
usuario, Opera facilita una amplia gama de posibilidades para la visualiza-
ción de las páginas web. En este caso, como en el anterior, se dispone de
un botón de acceso rápido ( ) a las funciones de carga de imágenes
y modo de presentación de la hoja de estilos.
91

Imagen 34. Menú desplegado con las opciones de carga de imágenes
y de presentación de hoja de estilos en Opera 7.54.
Por defecto, el navegador tiene seleccionada la opción de mostrar to-

das las imágenes que presenta la página. Se nos da la posibilidad de mos-
trar sólo aquellas que ya tenemos en caché o no mostrar ninguna (en su
caso mostrará, si existe, el texto alternativo que haya aplicado el autor en
aquellas imágenes que se nos muestran). Esta opción facilita una navega-
ción más rápida y la verificación de la existencia de textos alternativos.
En lo que se refiere a la forma de presentación de los estilos de la
página nos ofrece la posibilidad de elegir entre dos opciones: mostrarla como
la diseñó el autor (aplicando, por lo tanto la hoja de estilo definida por éste)
o hacerla en «modo de usuario», donde es éste quien define qué estilo de-
berá aplicarse a la página visualizada. De las distintas opciones que presen-
ta este «modo de usuario» (que podemos ver en la imagen 32), podemos
seleccionar una o varias al mismo tiempo, de tal modo que las posibles
combinaciones de hoja de estilo para visualizar son muy numerosas.
Para configurar, por defecto, tanto el modo de autor como el de usua-
rio, deberemos hacerlo desde Herramientas>Opciones>Estilo de
página>Configurar modos, donde se posibilita elegir entre cinco posibili-
92

dades para cada una de ellas, sin que sean mutuamente excluyentes. Lo
que sí debemos tener claro es que al escoger las dos primeras (Hojas de
estilo de la página y Colores y fuentes de la página) las tres restantes no
tendrán efecto, ya que priman los estilos definidos por el autor).
Imagen 35. Cuadro de diálogo donde podemos seleccionar los modos

de presentación con sus opciones en Opera 7.54.
Puede ser un ejercicio muy instructivo ir visualizando una misma pági-

na con las distintas posibilidades que nos ofrece Opera.

Igual que el resto de los navegadores vistos hasta este momento, Opera
permite que el usuario pueda bloquear la presentación de páginas en ven-
tanas emergentes sin su participación.
Para bloquear las ventanas emergentes pulsaremos F12 o seguiremos
la ruta Herramientas>Opciones más a mano donde podremos escoger
entre permitir que se abran todas en primer o segundo plano, bloquear las
no deseadas o bloquear todas.
Esta lista desplegable nos ofrece otras opciones interesantes para la
accesibilidad como son:
La desactivación de las animaciones GIF, que pueden ser molestas para

algunos usuarios, e incluso, si tienen una cierta frecuencia, pueden de-
sencadenar ataques epilépticos, por ejemplo.
93

Deshabilitar el sonido de las páginas, si existe, que puede interferir con
el sonido de los lectores de pantalla.
Desactivar Java, JavaScript y otros conectores (PDF. Shockwave, Flash,
QuickTime, RealPlayer, etc.), que permiten al usuario adaptar la nave-
gación a sus características personales y a las de su equipo.
Imagen 36. Lista desplegable de las «opciones más a mano» donde

bloquear las ventanas emergentes en Opera 7.54.
ATAJOS DE TECLADO Y GESTOS DEL RATÓN

A algunos usuarios no les es posible manejar el ratón (o les supone una
tarea muy dificultosa) o, por el contrario, se puede dar el caso de que este
elemento lo manejan con más soltura que el teclado. Para ellos, Opera ha
definido una serie de opciones que les permita aligerar la tarea de navegar
94

y puedan así utilizar este programa en toda su extensión. Esto se ha hecho
mediante los denominados «atajos de teclado» y con los «gestos de ratón».
Los atajos de teclado están siempre disponibles para el usuario y la
extensa información con la relación de teclas y combinación de teclas ha-
bilitadas por Opera la podemos encontrar (en castellano) en la página de
ayuda a la que podemos acceder desde la ruta Ayuda>Ayuda de Opera,
o pulsando F1, donde seleccionaremos Teclado.
Los gestos de ratón no se encuentran habilitados por defecto, para no
interferir con las funciones asignadas de forma especial por algunos usua-
rios a sus ratones o mecanismos apuntadores. Para habilitarlos lo tendre-
mos que hacer desde Herramientas>Opciones>Ratón y teclado, donde
activaremos la función correspondiente.
Imagen 37. Cuadro de diálogo donde podemos activar los gestos

de ratón en Opera 7.54.
La novedad y escasamente conocido uso de la funcionalidad de los

gestos de ratón, nos alienta a recoger en este texto cuáles son éstos y qué
funcionalidad ponen al servicio de aquellas personas que, por las dificulta-
des que tienen en el uso del teclado, navegan con ratón o mecanismos
apuntadores:
95

Gestos de Navegación:
• Ir a la página anterior: Pulsar el botón derecho y hacer clic con el iz-
quierdo o pulsar el botón derecho y mover el ratón hacia la izquierda.
• Ir a la página siguiente: Pulsar el botón izquierdo y hacer clic con el
derecho o pulsar el botón derecho y mover el ratón hacia la derecha.
• Ir al directorio padre: Pulsar el botón derecho, mover el ratón hacia
arriba y luego hacia la izquierda.
• Saltar: Pulsar el botón derecho y mover a la derecha y hacia arriba
o pulsar el botón derecho y la tecla mayúsculas, mover hacia la
derecha.
• Rebobinar: Pulsar el botón derecho, mover a la izquierda y luego
abajo o pulsar el botón derecho y tecla mayúsculas, mover hacia la
izquierda.
• Ir a página principal: Doble clic en una página vacía.
• Recargar página: Pulsar el botón derecho, mover hacia arriba y lue-
go hacia abajo.
• Parar carga: Pulsar el botón derecho, mover hacia arriba.
Gestos de Página:
• Navegar en una página nueva: Pulsar el botón derecho y mover
hacia abajo, hacer doble clic en el espacio de trabajo o sobre la
barra de Páginas.
• Duplicar página: Pulsar el botón derecho y mover hacia abajo y lue-
go hacia arriba.
• Restaurar o maximizar página: Pulsar el botón derecho y mover hacia
arriba y luego hacia la derecha.
• Minimizar página: Pulsar el botón derecho y mover hacia abajo y
luego hacia la izquierda.
• Cerrar página: Pulsar el botón derecho y mover hacia abajo y luego
hacia la derecha o pulsar el botón derecho y mover derecha -iz-
quierda - derecha.
Gestos para enlaces:
• Abrir enlace en una nueva página: Colocar el puntero del ratón so-
bre un enlace, pulsar el botón derecho y mover hacia abajo.
• Abrir enlace en una página en segundo plano: Mover el puntero del
ratón sobre un enlace, pulsar el botón derecho y mover hacia abajo
y luego hacia arriba.
96

Gestos con la rueda:
• Deslizar arriba y abajo: Accionar la rueda del ratón arriba y abajo.
• Aumentar y disminuir la escala: Pulsar la tecla control y accionar la
rueda del ratón.
• Recuperar la escala predeterminada: Pulsar la tecla control y hacer
clic con la rueda del ratón.
• Moverse adelante y atrás por el historial: Pulsar la tecla mayúsculas
y accionar la rueda.
• Ciclo entre páginas abiertas: Pulsar el botón derecho y accionar la
rueda del ratón.
• Desplazar la página (panning): Hacer clic con la rueda del ratón y
moverlo.
La imagen 35 nos muestra otra de las opciones de accesibilidad que

antes hemos visto para otros navegadores. Nos referimos a la función de
autocompletar la dirección que queremos visitar mediante el despliegue de
una lista de páginas ya elegidas por el usuario con anterioridad y que per-
manecen en el historial del programa.
Aplicaciones de usuario alternativas
Para que ciertos grupos de personas puedan acceder a los contenidos que
se colocan en la web, se han desarrollado aplicaciones de usuario alterna-
tivas que facilitan dicha tarea. En este apartado vamos a ver algunas de
ellas, cuyas referencias han sido tomadas de la página sobre este tipo de
recursos que mantiene el grupo WAI (Web Accessibility Initiative, Iniciativa
para la Accesibilidad en la Web) de W3C (World Wide Web Consortium,
Consorcio Mundial de la Web), en la dirección:
http://www.w3.org/WAI/References/Browsing
La página citada fue actualizada por última vez en julio del año 2001,
lo que significa que algunos de los recursos que en ella se nombran no
están disponibles en la actualidad. Por tal motivo nos centraremos en aque-
llos cuya existencia actual sí hemos podido comprobar.
97

Navegadores diseñados especialmente para personas con
discapacidad
Para cada una de estas aplicaciones se da la dirección web, donde se

puede encontrar una breve descripción y se menciona qué características
adaptativas soporta. La mayoría de ellos están disponibles en su versión
en inglés, y sólo se señala la disponibilidad en castellano cuando ésta existe.
BRAILLESURF DE BRAILLENET
http://www.snv.jussieu.fr/inova/bs4/uk/index.htm
Disponible en castellano.
Funciona con los sistemas operativos Windows 95 y siguientes.
Se trata de un navegador sólo texto que dispone de un lector de pan-
talla, un magnificador para ampliar el tamaño del texto y es compatible
con los dispositivos de lectura braille.
Es de distribución gratuita.
BROOKESTALK DE OXFORD BROOKES UNIVERSITY

http://www.brookes.ac.uk/schools/cms/research/speech/spanish/spanish.htm
Disponible una versión en castellano, desarrollada en colaboración con
la ONCE.
Funciona para los sistemas operativos Windows 95 y siguientes. Sus
últimas actualizaciones datan del año 2001.
Se trata de un navegador por voz que presenta texto en imagen. Dis-
pone de búsqueda inteligente y magnificador de pantalla.
Se distribuye gratuitamente.
HOME PAGE READER 3.0 DE IBM

http://www-134.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?
catalogId=-724&storeId=724&categoryId=2644214&langId=-5&dualCurrId=1221
Está disponible en castellano.
1. ¡Ojo con esta dirección web que es muy larga!
98

Es un navegador web con voz que proporciona acceso a internet y
correo electrónico a las personas invidentes, con graves problemas de
visión y con dificultades para la lectura.
Sus principales características (según el fabricante) son:
Tecnología de ayuda autónoma para acceder a internet, que utiliza el

módulo de conversión texto-voz de IBM.
Detección automática del idioma de la página web hasta en siete idio-
mas en las versiones de idioma seleccionadas.
Servidor web integrado y funciones de correo electrónico.
Sincronización oral y visual de gráficos, texto y vistas de voz de páginas
web.
Posibilidad de buscar por todo el texto oído de la página web, que
incluye texto alternativo y metatexto.
Todos los menús y diálogos en voz.
Navegación a través de los controles estándar de Windows o un méto-
do de navegación opcional con el teclado numérico.
Una Guía de Aprendizaje integrada para los usuarios nuevos y los que
ya tienen experiencia.
No se trata de software gratuito, aunque tiene un precio asequible

(146,00 euros, en la actualidad). En versiones anteriores se ha distri-
buido una demo ejecutable, pero no para la versión actual.
SENSU INTERNET BROWSER

http://www.sensus.dk/sib10uk.htm
No disponible en castellano.
Se trata de un navegador por voz especialmente diseñado para entornos
Windows 95/98 e Internet Explorer 4.0.
Dispone de salida de voz, soporte para lector de línea braille y formato
de fuentes especiales.
Su distribución es gratuita.
99

SIMPLY WEB 2000
http://www.econointl.com/sw/
No disponible en castellano.
Otro navegador por voz que utiliza la ingeniería de Internet Explorer
(desde la versión 4.01) y funciona con todas las versiones Windows a
partir de la 95.
Su distribución es gratuita.
Lectores de pantalla
Un lector de pantalla es utilizado para permitir la navegación de la pantalla

presentada por nuestro sistema operativo mediante la salida de voz o braille
y, por lo tanto, puede operar en las principales aplicaciones. En el contexto
de navegación estos lectores se utilizan junto con un navegador estándar
del tipo de los descritos aquí (IExplorer, Netscape, Firefox, Opera) o con
otros navegadores del tipo «solo texto» (por ejemplo, Lynx). Veamos algu-
nos de ellos (todos proporcionan versiones de demostración):
ASAW DE MICROTALK
http://www.microtalk.com/
Sistemas operativos: DOS y versiones Windows 95 y siguientes.
Salida: Voz.
HAL DE DOLPHIN
http://www.dolphinuk.co.uk/
Salidas: Voz y braille.
JAWS DE FREEDOM SCIENTIFIC

http://www.hj.com/fs_products/JAWS_HQ.asp
Salidas: Voz y Braille.
100

LOOKOUT DE CHOICE TECHNOLOGY
http://www.screenreader.co.uk/
Sistemas operativos: Versiones Windows 95 y siguientes.
Salida: Voz.
SIMPLY TALKER DE ECONONET

http://www.econointl.com/
Sistemas operativos: Windows 95/98/ME
Salida: Voz.
VIRGO DE BAUM
http://www.virgo4.de/html/v45.htm
Sistemas operativos: Versiones Windows NT/2000/XP.
WINDOW-EYES DE GWMICRO
http://www.gwmicro.com/products/
WINVISION FROM ARTIC

http://www.artictech.com/whywv97.htm
Salida: Voz.
101

102

Las pautas de accesibilidad al contenido
en la web 1.0 de w3c/wai
¿Qué son las Pautas de Accesibilidad al Contenido

en la web?
Tal como sus redactores dicen:
Estas pautas explican cómo hacer accesibles los contenidos de la web a

personas con discapacidad. Las pautas están pensadas para todos los
diseñadores de contenidos de la web (autores de páginas y diseñadores
de sitios) y para los diseñadores de herramientas de creación. El fin
principal de estas pautas es promover la accesibilidad. De cualquier modo,
siguiéndolas, se hará la web más asequible también para todos los usua-
rios, cualquiera que sea la aplicación de usuario utilizada (por ejemplo,
navegador de sobremesa, navegador de voz, teléfono móvil, PC de au-
tomóvil, etc.), o las limitaciones bajo las que opere (por ejemplo, entornos
ruidosos, habitaciones infra o supra iluminadas, entorno de manos li-
bres, etc.). Seguir estas pautas ayudará también a cualquier persona a
encontrar información en la web más rápidamente. Estas pautas no desa-
lientan a los diseñadores para la utilización de imágenes, vídeo, etc.; por
el contrario, explican cómo hacer los contenidos multimedia más accesi-
bles a una amplia audiencia.
Las «Pautas de Accesibilidad al Contenido en la Web 1.0» son una

especificación del W3C que proporciona una guía sobre la accesibili-
dad de los sitios de la web para las personas con discapacidad. Han
sido desarrolladas por la Iniciativa de Accesibilidad en la Web (WAI) del
W3C.
La especificación contiene catorce pautas, que son los principios ge-
nerales para el diseño accesible. Cada pauta está asociada a uno o más
103

puntos de verificación que describen cómo aplicar esa pauta a las caracte-
rísticas particulares de las páginas web.
Un apéndice de estas pautas, la «Lista de puntos de verificación
para las Pautas de Accesibilidad al Contenido en la Web 1.0», presen-
ta los puntos de verificación clasificados por prioridades, para encontrarlas
fácilmente. Estas pautas no sólo hacen las páginas más accesibles para
las personas con discapacidad, sino que tienen el beneficio adicional de
hacerlas más accesibles para todos los usuarios, en particular para los que
utilizan navegadores diferentes o para los que manejan ordenadores por-
tátiles con pantallas pequeñas o basados en la voz.
¿Qué son las «prioridades», los «niveles

de adecuación»?
Cada punto de verificación tiene asignado uno de los tres niveles de prio-
ridad:
• La Prioridad 1 es para los puntos de verificación que el desarrollador

tiene que cumplir; si no, algunos grupos de personas serán incapaces
de acceder a la información de un sitio;
• La Prioridad 2 el desarrollador debe cumplirla; sin ello alguien encon-
trará muchas dificultades para acceder a la información;
• La Prioridad 3 el desarrollador puede cumplirla; de lo contrario, algu-
nas personas hallarán dificultades para acceder a la información.
La especificación tiene tres niveles de adecuación para facilitar la

referencia por otras organizaciones.
• El nivel de adecuación «A» (A) incluye los puntos de verificación de

prioridad 1;
• El nivel «Doble A» (AA) incluye las prioridades 1 y 2;
• El nivel «Triple A» (AAA) incluye las prioridades 1, 2 y 3.
104

¿Por qué son necesarias estas pautas?
Las personas con diferentes tipos de discapacidad pueden experimentar

dificultades para utilizar la web debido a la combinación de barreras en la
información de las páginas web, con las barreras de las «aplicaciones de
usuario» (navegadores, dispositivos multimedia o ayudas técnicas como
los lectores de pantalla o reconocedores de voz).
Estas Pautas tienen relación específicamente con la reducción de ba-
rreras en las páginas web. Para algunas personas con discapacidad, las
barreras pueden significar:
• La falta de acceso a información precisa para programas educativos.

• La falta de acceso a información relacionada con el empleo o en las
intranets del puesto de trabajo.
• La falta de acceso a información sobre actividades o programas cívicos.
• La incapacidad para participar en el comercio en la red.
• La falta de acceso a la información general de la web.
Algunos ejemplos de barreras habituales

en las páginas web
Estas pautas se refieren a las barreras que pueden encontrar en las pági-
nas web las personas con discapacidad física, visual, auditiva y cognitiva/
neurológica. Los problemas habituales de accesibilidad a los sitios web
incluyen:
• Imágenes sin texto alternativo.

• Ausencia de texto alternativo para los puntos sensibles de los mapas
de imagen.
• El uso incorrecto de los elementos estructurales en las páginas.
• Los sonidos no subtitulados o las imágenes no descritas.
• La ausencia de información alternativa para los usuarios que no pueden
acceder a los marcos («frames») o a los programas incrustados («scripts»).
• Las tablas difíciles de interpretar cuando se alinean.
• Los sitios con un contraste de colores pobre.
105

¿Cómo se presentan las PAUTAS?
Dentro del texto normativo, las catorce pautas o principios generales de

diseño accesible incluyen:
• Número de la pauta.
• Exposición de la pauta.
• El fundamento que sustenta la pauta y algunos grupos de usuarios que
se benefician de ella.
Pauta 1. Proporcione alternativas equivalentes para

el contenido visual y auditivo
Proporcione un contenido que, presentado al usuario, cumpla
esencialmente la misma función o propósito que el contenido visual
o auditivo
Algunas personas no pueden utilizar imágenes, películas, sonidos, applets,

etc directamente, pero sí pueden utilizar páginas que incluyen información
equivalente a los contenidos visuales o auditivos. La información equiva-
lente debe cumplir la misma finalidad que los contenidos visuales o auditivos.
Así un texto equivalente para la imagen de una flecha ascendente que
vincule con una tabla de contenidos, podría ser «Ir a tabla de contenidos».
En algunos casos, un equivalente debería describir la apariencia del conte-
nido visual (por ejemplo, para tablas complejas, carteles o diagramas) o el
sonido del contenido auditivo por ejemplo, para los ejemplos sonoros usa-
dos en educación).
Esta pauta enfatiza la importancia de aportar equivalentes textuales
para los contenidos no textuales (por ejemplo, imágenes, sonido pregrabado,
vídeo...). La importancia del texto equivalente radica en su capacidad para
ser interpretado por vías que son accesibles para personas pertenecientes
a diversos grupos de discapacidad usando diversa tecnología. El texto puede
ser interpretado por sintetizadores de voz o dispositivos braille y puede ser
presentado visualmente (en varios tamaños) en visualizadores de ordena-
dor y en el papel. El sintetizador de voz es esencial para personas ciegas
y para las que tienen dificultades de lectura que a menudo acompañan a
discapacidades cognitivas, de aprendizaje o sordera. El braille es esencial
106

para personas sordo-ciegas, tanto como para muchos individuos que sola-
mente son ciegos. La salida visual de texto beneficia tanto a los usuarios
sordos como a la mayoría de usuarios de la web.
Proporcionar equivalentes no textuales (dibujos, videos, sonido) del texto
es también beneficioso para algunos usuarios, especialmente los analfabe-
tos o personas con dificultad para la lectura. En las películas o presenta-
ciones visuales, la acción representada, tal como el lenguaje corporal u
otras pistas visuales, podrían no estar acompañadas de suficiente informa-
ción auditiva como para transmitir la misma información. A menos que se
proporcionen descripciones verbales de las acciones representadas, las
personas que no puedan ver (o visualizar) el contenido visual, no podrán
percibirlo.
Pauta 2. No se base sólo en el color

Asegúrese de que los textos y gráficos son comprensibles cuando se
vean sin color
Si el color por sí mismo se usa para transmitir información, las personas

que no puedan diferenciar ciertos colores, y los usuarios que no tengan
pantallas en color o utilicen dispositivos de salida no visuales, no recibirán
la información. Cuando los colores de primer plano y de fondo tienen un
tono similar, pueden no proporcionar suficiente contraste en las pantallas
monocromáticas, así como a las personas con diferentes tipos de deficien-
cias de percepción de los colores.
Pauta 3. Utilice marcadores y hojas de estilo y hágalo

apropiadamente
Marque los documentos con los elementos estructurales apropiados.
Controle la presentación con hojas de estilo en vez de con elementos
y atributos de presentación
El uso de marcadores de forma inapropiada (es decir, no de acuerdo con

las especificaciones) dificulta la accesibilidad. El mal uso de marcadores
para una presentación (por ejemplo, utilizando una tabla para maquetar o
un encabezado —etiqueta H— para cambiar el tamaño de la fuente) difi-
culta que los usuarios con software especializado entiendan la organiza-
107

ción de la página o cómo navegar por ella. Más aún, la utilización de los
marcadores de presentación en lugar de marcadores estructurales para
transmitir estructura (por ejemplo, construir lo que parece una tabla de datos
con un elemento HTML PRE) hace difícil interpretar una página de forma
inteligible a otros dispositivos.
Los desarrolladores de contenidos pueden sentir la tentación de usar
(o usar mal) construcciones que aseguren el formato deseado en los
navegadores antiguos. Deben darse cuenta de que estas prácticas causan
problemas de accesibilidad y deben considerar si el formato es tan impor-
tante como para hacer el documento inaccesible a algunos usuarios.
En el otro extremo, los desarrolladores de contenidos no deben sacrifi-
car el marcador apropiado porque un determinado navegador o ayuda téc-
nica no pueda procesarlo correctamente. Por ejemplo, es apropiado usar
el elemento TABLE en HTML para marcar información tabular aunque al-
gunos lectores de pantalla antiguos no manejen correctamente el texto
contiguo. Usar el elemento TABLE correctamente y crear tablas que se
transformen adecuadamente hace posible al software interpretar tablas de
otra forma que como rejilla en dos dimensiones.
Pauta 4. Identifique el idioma usado

Use marcadores que faciliten la pronunciación o interpretación de texto
abreviado o extranjero
Cuando los desarrolladores de contenido especifican los cambios en el

idioma de un documento, los sintetizadores de voz y los dispositivos braille
pueden cambiar automáticamente al nuevo lenguaje, haciendo el docu-
mento más accesible a usuarios multilingües.
Los desarrolladores de contenido deberían identificar el idioma predo-
minante del contenido de un documento (a través de un marcador o en el
encabezado HTTP). Deberían también proporcionar la expansión de las
abreviaturas y los acrónimos.
Además de apoyar a las ayudas técnicas, la identificación del idioma
usado permite a los motores de búsqueda localizar las palabras claves e
identificar los documentos en el idioma deseado. Los marcadores de idio-
ma mejoran también la legibilidad de la web para todo el mundo, incluso
para aquellos con discapacidades de aprendizaje, cognitivas o sordera.
108

Cuando los cambios en las abreviaturas y el idioma no son identifica-
dos, pueden ser indescifrables para los lectores de pantalla y los dispositi-
vos braille.
Pauta 5. Cree tablas que se transformen correctamente

Asegúrese de que las tablas tienen los marcadores necesarios para
transformarlas mediante navegadores accesibles y otras aplicacio-
nes de usuario
Las tablas deberían utilizarse solamente para marcar la información tabu-

lar («tablas de datos»). Los desarrolladores de contenidos deberían evitar
usarlas para maquetar páginas («tablas de composición»). Usar tablas para
cualquier finalidad crea también especiales dificultades para los usuarios
de lectores de pantalla.
Algunas aplicaciones de usuario permiten a los usuarios navegar entre
las celdas de las tablas y acceder a los encabezamientos y otras informa-
ciones de las celdas. A menos que marquemos apropiadamente las tablas,
éstas no proporcionaran a la aplicación de usuario la información necesa-
ria para ello.
Los puntos de verificación de esta pauta beneficiarán directamente a
las personas que accedan a la tabla por medios auditivos (por ejemplo un
lector de pantalla o un PC de automóvil), o a aquellos que sólo visualicen
una parte de la página cada vez (por ejemplo, los usuarios ciegos o de
escasa visión que utilicen un sistema auditivo o un dispositivo braille u otros
usuarios de dispositivos con pantallas pequeñas, etc.).
Pauta 6. Asegúrese de que las páginas que incorporan

tecnologías digitales se transformen correctamente
Asegúrese de que las páginas son accesibles incluso cuando no se
soportan las tecnologías más modernas o éstas estén desconectadas
Si bien se alienta a los desarrolladores de contenidos a usar tecnologías

digitales que superen los problemas que proporcionan las tecnologías exis-
tentes, deberán saber cómo hacer para que sus páginas funcionen con
navegadores más antiguos, y para quienes decidan desconectar esta ca-
racterística.
109

Pauta 7. Asegure al usuario el control sobre los cambios
de los contenidos tempo-dependientes
Asegúrese de que los objetos o páginas que se mueven, parpadean,
se desplazan o se actualizan automáticamente, puedan ser detenidos
o parados
Algunas personas con discapacidades cognitivas o visuales son incapa-

ces de leer textos que se mueven con la suficiente rapidez o en absolu-
to. El movimiento puede también distraer de tal manera que el resto de
la página se vuelve ilegible para las personas con discapacidades
cognitivas. Los lectores de pantalla son incapaces de leer textos móviles.
Las personas con discapacidades físicas podrían no ser capaces de
moverse tan rápida o certeramente como para interactuar con objetos
móviles.
Todos los puntos de verificación de esta pauta implican alguna res-
ponsabilidad por parte del desarrollador del contenido hasta que las aplica-
ciones de usuario proporcionen adecuados mecanismos de control de la
característica.
Pauta 8. Asegure la accesibilidad directa de las interfaces

de usuario incrustadas
Asegúrese de que la interfaz de usuario sigue los principios de un
diseño accesible: funcionalidad de acceso independiente del disposi-
tivo, teclado operable, voz automática, etc.
Cuando un objeto incrustado tiene su «propia interfaz», ésta (al igual que
la interfaz de su navegador) debe ser accesible. Si la interfaz del objeto
incrustado no puede hacerse accesible, debe proporcionarse una solución
alternativa accesible.
Pauta 9. Diseñe para la independencia del dispositivo

Utilice características que permitan la activación de los elementos de
la página a través de diversos dispositivos de entrada
El acceso independiente del dispositivo significa que el usuario puede

interactuar con la aplicación de usuario o el documento con un dispositivo
110

de entrada (o salida) preferido: ratón, teclado, voz, puntero de cabeza
(licornio) u otro. Si, por ejemplo, un control de formulario sólo puede ser
activado con un ratón u otro dispositivo de apuntamiento, alguien que use
la página sin verla, con entrada de voz, con teclado o quien utilice otro
dispositivo de entrada que no sea de apuntamiento, no será capaz de uti-
lizar el formulario.
Nota: Proporcionar textos equivalentes para los mapas de imagen o
las imágenes usadas como vínculos, hace posible a los usuarios interactuar
con ellos sin un dispositivo de apuntamiento.
Generalmente, las páginas que permiten la interacción a través del
teclado son también accesibles a través de una entrada de voz o una serie
de comandos.
Pauta 10. Utilice soluciones provisionales

Utilice soluciones de accesibilidad provisionales de forma que las
ayudas técnicas y los antiguos navegadores operen correctamente
Por ejemplo, los navegadores antiguos no permiten al usuario navegar a

cuadros de edición vacíos. Los antiguos lectores de pantalla leen las listas
de vínculos consecutivos como un solo vínculo. Estos elementos activos
tienen, por tanto, difícil o imposible el acceso. Igualmente, cambiar la ven-
tana actual o hacer aparecer inesperadamente nuevas ventanas, puede
ser muy desorientador para los usuarios que no pueden ver lo que está
ocurriendo.
Los puntos de verificación de esta pauta se aplican hasta que las apli-
caciones de usuario (incluidas las ayudas técnicas) solucionen estos pro-
blemas. Los puntos de verificación están clasificados como «provisiona-
les» lo que significa que el Grupo de Trabajo de las Pautas de Contenido
en la web los considera válidos y necesarios para la accesibilidad de la
web en el momento de la publicación de este documento. Sin embargo, el
Grupo de Trabajo espera que estos puntos de verificación no sean nece-
sarios en un futuro, una vez que las tecnologías de la web hayan incorpo-
rado las características y capacidades esperables.
111

Pauta 11. Utilice las tecnologías y pautas W3C
Utilice tecnologías W3C (de acuerdo con las especificaciones) y siga
las pautas de accesibilidad. Donde no sea posible utilizar una tecno-
logía W3C, o usándola se obtengan materiales que no se transforman
correctamente, proporcione una versión alternativa del contenido que
sea accesible
Las actuales pautas recomiendan las tecnologías W3C (por ejemplo, HTML,
CSS, etc.) por varias razones:
• Las tecnologías W3C incluyen características accesibles «incorporadas».

• Las especificaciones W3C pronto serán revisadas para asegurar que
los temas de accesibilidad se toman en consideración en la fase de
diseño.
• Las especificaciones W3C están desarrolladas en un proceso abierto
de laborioso consenso.
Muchos formatos no recomendados por W3C (por ejemplo, PDF,

Schockwave, etc.) requieren ser vistos bien con plug-ins o con aplicacio-
nes autónomas. A menudo, estos formatos no pueden ser visualizados o
navegados con aplicaciones de usuario estándares (incluyendo ayudas téc-
nicas). Evitar estos formatos y características no estándar (elementos, atri-
butos, propiedades y extensiones patentados), tenderá a hacer más acce-
sibles las páginas a más gente que utiliza una amplia variedad de hardware
y software. Cuando deba utilizar tecnologías no accesibles (patentadas o
no), debe proporcionar una página equivalente accesible.
Incluso cuando se utilicen tecnologías W3C, deben ser usadas de acuer-
do con las pautas de accesibilidad. Cuando utilice tecnologías digitales,
asegúrese de que se transforman correctamente.
Convertir los documentos (desde PDF, Postscript, RTF, etc.) a len-
guajes de marcado W3C (HTML, XML) no siempre crea un documento
accesible. Por tanto, valide cada página respecto a la accesibilidad y uti-
lidad después del proceso de conversión. Si una página no se convierte
de forma legible, revise la página hasta que su presentación original se
convierta adecuadamente o bien proporcione una versión en HTML o en
texto plano.
112

Pauta 12. Proporcione información de contexto
y orientación
Proporcione información de contexto y orientativa para ayudar a los
usuarios a entender páginas o elementos complejos
Agrupar los elementos y proporcionar información contextual sobre la rela-

ción entre elementos puede ser útil a todos los usuarios. Las relaciones
complejas entre las partes de una página pueden resultar difíciles de inter-
pretar para personas con discapacidades cognitivas o visuales.
Pauta 13. Proporcione mecanismos claros de navegación

Proporcione mecanismos de navegación claros y coherentes, (infor-
mación orientativa, barras de navegación, un mapa del sitio, etc.) para
incrementar la probabilidad de que una persona encuentre lo que está
buscando en un sitio
Los mecanismos de navegación claros y coherentes son importantes para

las personas con discapacidad cognitiva o con ceguera y benefician a to-
dos los usuarios.
Pauta 14. Asegúrese de que los documentos sean claros

y simples
Asegure que los documentos son claros y simples para que puedan
ser más fácilmente comprendidos
La maquetación coherente de páginas, los gráficos reconocibles y el len-

guaje fácilmente comprensible benefician a todos los usuarios. En particu-
lar, ayudan a personas con discapacidades cognitivas o con dificultades en
la lectura. Por tanto, asegúrese de que las imágenes tienen textos equiva-
lentes para los ciegos, los de baja visión o para cualquier usuario que no
puede o ha elegido no ver los gráficos.
La utilización de un lenguaje claro y simple promueve una comunica-
ción efectiva. El acceso a la información escrita puede ser difícil para per-
sonas con discapacidades cognitivas o de aprendizaje. La utilización de un
lenguaje claro y simple también beneficia a las personas cuyo primer idio-
ma es diferente al del autor, incluidas aquellas que se comunican principal-
mente mediante lengua de signos.
113

Segunda parte
CODIFICACIÓN HTML Y CSS
Carlos
Firmado digitalmente por
Carlos Egea García
Nombre de
reconocimiento (DN):
Egea
cn=Carlos Egea García,
o=Consultores Sociales
email=carlos@ceyas.es,
García c=ES
Fecha: 2007.11.08 19:26:25
+01'00'

116

Codificación HTML
HTML, SGML, XHTML, XML...
Probablemente hayamos leído que HTML es una aplicación de SGML.

Probablemente no sepamos muy bien qué significa eso. También habre-
mos leído sobre otros lenguajes más «exóticos» como XHTML y XML y,
probablemente, también nos preguntaremos qué son exactamente.
SGML y HTML
SGML significa Standard Generalized Mark-up Language o Lenguaje Ge-

neralizado Estándar para el Formato de Documentos («mark-up» es un
término de imprenta que significa el conjunto de instrucciones estilísticas
detalladas escritas en un manuscrito que debe ser tipografiado). Es un
estándar internacional que permite definir lenguajes para dar formato a
documentos (mark-up languages). Por ejemplo, el HTML, es un lenguaje
de formato de documentos definido de acuerdo con SGML (o, en otras
palabras, una aplicación de SGML) para dar formato a documentos de
hipertexto.
El HTML es un lenguaje muy simple. El formato de los documentos se
marca mediante etiquetas (tags) que indican el comienzo y el final de los
elementos que componen el documento. Cada uno de estos elementos
tiene un significado estructural diferente. Por ejemplo, el elemento «p» con-
tiene un párrafo de texto. El comienzo del párrafo se marca con la etiqueta
<p> y el final del párrafo se marca (opcionalmente) con la etiqueta </p>.
El elemento «h1» contiene un encabezado (por ejemplo, el título de un
capítulo) y está delimitado por las etiquetas <h1> y </h1>. El elemento
«a» indica un hipervínculo (o más concretamente el origen o el destino de
117

un hipervínculo, según cómo se marque en el documento) y está delimita-
do por las etiquetas <a> y </a>. Etcétera.
En teoría, el código HTML sólo contiene, por tanto, información sobre
la estructura de los contenidos. Si escribimos, por ejemplo, el siguiente
párrafo:
<p>Esto es un párrafo.
Aunque haga un salto de línea, seguirá siendo un

párrafo.</p>
Esto se representará en el navegador así:
Esto es un párrafo. Aunque haga un salto de línea, seguirá siendo un

párrafo.
La simplicidad del HTML es un punto a su favor: como los contenidos

están estructurados de manera lógica, pueden ser representados de acuerdo
con esa estructura por cualquier navegador, según sus capacidades. Él
mismo se encargará de escribir los títulos con un tipo más grande que el
de los párrafos, de poner el espacio entre párrafos, de dibujar los marca-
dores de las listas, de dibujar las líneas entre las celdas de una tabla, etc.,
sin que nosotros tengamos que preocuparnos de esos aspectos.
Sin embargo, los documentos así obtenidos carecen de atractivo vi-
sual. Hoy es posible utilizar hojas de estilo para especificar la apariencia
de los elementos, pero durante varios años ha sido necesario recurrir a
trucos y a elementos inventados para ello. Por ejemplo, el elemento <font>
para cambiar la fuente de un elemento, la utilización de tablas para colocar
los elementos en la pantalla en lugar de para contener datos tabulares o la
división de un mismo documento en marcos. Todo ello introdujo rápida-
mente problemas, ya que el HTML se complicó y los documentos se hicie-
ron menos accesibles. Los navegadores más antiguos ya no eran capaces
de entender la estructura de los nuevos documentos. De hecho los docu-
mentos perdieron su estructura, lo cual era la base misma del HTML.
La última especificación de HTML, la HTML 4.01 de 1997, declaró
todos los elementos de presentación como «desaconsejados» (en inglés:
118

deprecated), es decir, en riesgo de ser declarados como obsoletos en próxi-
mas especificaciones, de modo que los nuevos navegadores no se verían
obligados a soportarlos. En su lugar, deberían utilizarse hojas de estilo.
SGML y XML
Como hemos visto, desde su creación, el HTML ha ido aumentando su

complejidad para responder a las demandas de los usuarios de la web. Al
principio era suficiente para los físicos nucleares para los que iba a servir,
pero hoy los documentos HTML tienen gráficos, animaciones, música; cada
día llega a tecnologías diferentes (dispositivos portátiles, teléfonos móvi-
les) y algún día se convertirá en una web realmente interactiva. El lenguaje
de la web necesita seguir evolucionando.
XML es una respuesta a esta necesidad. XML no es un nuevo lenguaje
que vaya a suplantar a HTML. En realidad es, como el SGML, un
metalenguaje, es decir, un lenguaje para definir lenguajes. Es una versión
de SGML, más sencilla y más fácil de aplicar que el propio SGML, diseña-
da precisamente para hacer frente a los problemas de compatibilidad y
adaptabilidad de las tecnologías digitales a internet.
XML significa «Extensible Mark-up Language». En XML no hay ele-
mentos. Cada usuario (o grupo de usuarios) puede crear su propio lengua-
je para el formato de datos y documentos, su propio vocabulario, según
sus necesidades, siguiendo las reglas de XML. Por ejemplo, si quieres
crear una lista de libros, puedes definir tus propios elementos, encerrados
entre las etiquetas correspondientes: <titulo>, <autor>, <precio>,
<editorial>, etc. A partir de ahí, podrías definir una hoja de estilo para
definir la presentación de cada tipo de elemento en un navegador visual o
en una salida impresa; pero también podrías utilizar una aplicación (tal vez
una de las muchas aplicaciones ya existentes para el manejo de documen-
tos XML) para buscar libros por autor, para ordenarlos, etc. Si, por ejem-
plo, quisieramos vender los libros por internet podríamos utilizar estas apli-
caciones para permitir a nuestros clientes realizar búsquedas y hacer
pedidos.
Por supuesto, la idea no es que cada usuario se cree su propio len-
guaje, sino que haya estándares generales, y que se escojan los apropia-
119

dos combinándolos entre sí, si es necesario. La extensibilidad se refiere
precisamente a eso. Hay muchos lenguajes definidos de acuerdo con las
reglas de XML (aplicaciones XML). Por ejemplo, DocBook es un lenguaje
para el formato de libros electrónicos. MathML es un lenguaje para el for-
mato de ecuaciones matemáticas. En DocBook hay un elemento para pá-
rrafos (<Para>). En MathML hay definidos elementos útiles para las fór-
mulas matemáticas, como sumatorios (<sum>), exponenciales (<exp>), etc.,
pero no hay un elemento para párrafos.
Esto permite crear lenguajes específicos para cada aplicación o para
cada tecnología, lo cual finalmente puede simplificar las cosas. Por ejem-
plo, los teléfonos móviles tienen una capacidad de procesamiento mucho
menor que los ordenadores personales. Como el HTML es demasiado
complicado para ellos, se desarrolló un nuevo lenguaje simplificado lla-
mado WAP específico para teléfonos móviles. Desgraciadamente, WAP
no es una aplicación XML. En el futuro se espera que los teléfonos móvi-
les soporten XML, pero esto va a suponer esperar un tiempo de adapta-
ción que se podría haber evitado. Vemos aquí un ejemplo de cómo los
estándares pueden ayudar a facilitar la adaptación de tecnologías digitales
a la web.
XML y XHTML
Si con XML se pueden definir lenguajes para formato de documentos, ¿se

podría definir HTML como aplicación de XML? Sí. Es más, ya lo hicieron,
y lo llamaron XHTML 1.0. El XHTML 1.0 es exactamente igual que el HTML
4, excepto en que sigue las reglas de XML, que son más estrictas que las
de SGML. Por ejemplo, en HTML el elemento «p» no necesita la etiqueta
final </p>. En XHTML sí son necesarias, ya que todos los elementos
necesitan una etiqueta inicial y otra final. En HTML puedes escribir <p> o
<P>, no importa. En XHTML, las etiquetas tienen que ir obligatoriamente
en minúsculas.
Como podemos observar, son diferencias formales. Las capacidades
de XHTML 1.0 son exactamente las mismas que las de HTML 4.
¿Es necesario entonces escribir las nuevas páginas en XHTML? Real-
mente no, no va a haber ninguna diferencia. El XHTML es en el fondo la
120

forma que tuvo el W3C de dar a entender que habían decidido apostar por
la implementación de XML.
W3C creó XHTML para posibilitar en el futuro la modularización del
HTML. Hemos visto que para algunas aplicaciones conviene definir un
subconjunto simplificado del HTML; para otras podría ser interesante am-
pliarlo con nuevas capacidades. Una solución es dividir el HTML en partes
o módulos independientes y que cada navegador tome los que necesite
según sus capacidades: un módulo de texto, un módulo de imágenes, un
módulo de scripts, un módulo de formularios, etc.
Hoy XHTML ya es modular. Es de esperar que en el futuro existan
aplicaciones que permitan crear fácilmente documentos XHTML, utilizando
los módulos necesarios. Pero HTML no va a desaparecer de golpe. Los
millones de páginas web que existen hoy son HTML. Los navegadores
seguirán entendiendo HTML. La modularización de XHTML se ha hecho
con vistas a las tecnologías digitales, y hasta que no haya editores capa-
ces de crear documentos eficientemente, no deberíamos preocuparnos en
exceso. Sin embargo, las cosas evolucionan muy rápido, así que nunca
está de más mantenerse al día.
Definición de tipo de documento
EL W3C, encargado de la creación de los Standard Web, define que los

ficheros HTML, XML, XHTML deben tener una declaración de tipo de do-
cumento denominada DOCTYPE, que debe hacer referencia a una de las
tres definiciones del tipo de documento que existen.
Esta declaración debe ser la primera línea de nuestro documento y es
necesaria para decirle al navegador qué versión de HTML es la que se usa
en la página. Si no se hace, el navegador procesará la página en modo
Quirks (modo de compatibilidad) pudiendo no interpretar correctamente el
código de la página.
La DTD (definición del tipo de documento) es la estructura reglamenta-
ria, es decir, los elementos y atributos que están disponibles para cada tipo
de documento. Para HTML 4.01 (las versiones anteriores no son recomen-
dables debido a que no son del todo compatibles con las hojas de estilo),
existen 3 tipos de DTD:
121

1. HTML 4.01 transitorio
El HTML 4 transitorio incluye todos los elementos y cualidades de HTML
4 Strict (estricto) pero agrega cualidades de presentación, elementos
desaconsejados o elementos obsoletos. Se llama Transitional (transito-
rio) porque está pensado como transición hacia HTML 4 estricto.
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01
Transitional//EN\"
\"http://www.w3.org/TR/html4/loose.dtd\">
2. HTML 4.01 frameset:

Ésta es una variante de HTML 4 transitorio para los documentos que
utilizan Frames (marcos).
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01
Frameset//EN\"
\"http://www.w3.org/TR/html4/frameset.dtd\">
3. HTML estricto
Si declaramos esta DTD, el navegador pasará a actuar en cumplimien-
to de los estándares (Standards compílanse). Esto implicará que sólo
puedan usarse las etiquetas de HTML 4.01. Éste es el modo recomen-
dado por el W3C, ya que es compatible con el CSS y puede ser inter-
pretado correctamente por todos los navegadores, lo que hace mucho
más fácil el paso de nuestros documentos al XHTML que muy posible-
mente tienda a sustituir al HTML en los próximos años.
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"
\"http://www.w3.org/TR/html4/strict.dtd\">
Las mismas tres formulaciones (transitoria, frameset y estricta) existen

para la codificación XHTML 1.0. En la práctica no parece lógico utilizar
esta codificación en sus formulaciones transitoria y frameset, por lo que,
generalmente encontraremos su forma estricta. El modo de definirlo
sería:
122

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd">
Si queremos saber si nuestra página cumple con la DTD definida pode-

mos hacerlo desde http://validator.w3.org/.
Sintaxis de HTML
El HTML es un lenguaje que basa su sintaxis en un elemento de base al

que llamamos etiqueta (tag). La etiqueta presenta frecuentemente dos
partes:
1. Una apertura de forma general <etiqueta>

2. Un cierre de tipo </etiqueta>
Todo lo incluido en el interior de esa etiqueta sufrirá las modificaciones

que caracterizan a esta etiqueta.
Un documento HTML ha de estar delimitado por la etiqueta <html> y
</html>. Dentro de este documento, podemos asimismo distinguir dos
partes principales:
1. El encabezado, delimitado por <head> y </head> donde colocare-

mos etiquetas de índole informativo como, por ejemplo, el titulo de nues-
tra página.
2. El cuerpo, flanqueado por las etiquetas <body> y </body>, que será
donde colocaremos nuestro texto e imágenes delimitados a su vez por
otras etiquetas como las que hemos visto.
El resultado es un documento con la siguiente estructura:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//

EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
123

Etiquetas y contenidos del encabezado.
Datos que no aparecen en nuestra página pero que son
importantes para catalogarla: Titulo, palabras clave,
metadatos, vínculos relacionales como el de la hoja
de estilo...
</head>
<body>
Etiquetas y contenidos del cuerpo.
Parte del documento que será mostrada por el navegador:
Texto, imágenes, sonidos, elementos multimedia...
</body>
</html>
En HTML, las etiquetas pueden ser escritas con cualquier tipo de com-
binación de mayúsculas y minúsculas. <html>, <HTML> o <HtMl> son la
misma etiqueta. Resulta sin embargo aconsejable acostumbrarse a escri-
birlas en minúscula, ya que otras XHTML, que cada día tiene mayor grado
de aplicación, no es tan permisivo y nunca viene mal coger buenas cos-
tumbres desde el principio para evitar fallos triviales en un futuro.
Etiquetas HTML
Veamos ahora cuáles son las etiquetas que se utilizan en la codificación

HTML según la función que desempeñan (las que están desaconsejadas
se señala esta condición en el propósito).
Para leer la tabla hay que saber:
1. En la columna «etiqueta» figura la etiqueta de apertura, a la que le

corresponde una de cierre.
2. En la columna «propósito» aparece la utilidad de cada etiqueta.
3. En la columna «DTD» se indica qué declaración de tipo de documento
para XHTML 1.O está permitida la etiqueta (S = estricto; T = transitorio;
F = frameset).
124

Etiqueta Propósito DTD
Etiqueta básicas
<!DOCTYPE> Define el tipo de documento STF
<html> Define un documento html STF
<body> Define el elemento body STF
<h1> a <h6> Define los encabezados 1 a 6 (de mayor a menor nivel) STF
<p> Define un párrafo STF
<br> Inserta un salto de línea STF
<hr> Inserta una línea (gráfica) horizontal STF
<!—...—> Define un comentario STF
Formato texto
<b> Define texto en negrita STF
<font> DESACONSEJADO. Define el tamaño y color de la fuente
de texto TF
<i> Define texto en cursiva STF
<em> Define énfasis de texto STF
<big> Define texto grande STF
<strong> Define texto en negrita fuerte STF
<small> Define texto pequeño STF
<sup> Define texto en superíndice STF
<sub> Define texto en subíndice STF
<bdo> Define la dirección en la que se muestra el texto STF
<u> DESACONSEJADO. Define texto subrayado TF
Cómo se muestra
<pre> Define texto preformateado STF
<code> Define texto mostrado como código informático STF
<tt> Define texto de teletipo STF
<kbd> Define texto de teclado STF
<var> Define una variable STF
<dfn> Define un término de una definición STF
<samp> Define código informático de muestra STF
<xmp> DESACONSEJADO. Define texto preformateado
Bloques
<acronym> Define un acrónimo STF
<abbr> Define una abreviatura STF
<address> Define un elemento de dirección STF
<blockquote> Define una cita textual larga STF
<center> DESACONSEJADO. Define texto centrado TF
125

Bloques
<q> Define una cita textual corta STF
<cite> Define una cita STF
<ins> Define texto insertado STF
<del> Define texto borrado STF
<s> DESACONSEJADO. Define texto tachado TF
<strike> DESACONSEJADO. Define texto tachado TF
Enlaces
<a> Define un ancla (donde se sitúa el enlace) STF
<link> Define un recurso de referencia STF
Marcos
<frame> Define una sub-ventana (un marco) F
<frameset> Define un conjunto de marcos F
<noframes> Define una sección noframe TF
<iframe> Define una sub-ventana (marco) en línea TF
Entrada de datos
<form> Define un formulario STF
<input> Define un campo de entrada de datos STF
<textarea> Define un área de texto STF
<button> Define un pulsado (botón) STF
<select> Define una lista seleccionable STF
<optgroup> Define una opción de grupo STF
<option> Define un ítem en una caja de lista STF
<label> Define una etiqueta de control de formulario STF
<fieldset> Define un conjunto de campos STF
<legend> Define un título para un conjunto de campos STF
<isindex> DESACONSEJADO. Define un campo de entrada de una
línea: TF
Listas
<ul> Define una lista desordenada (con viñetas) STF
<ol> Define una lista ordenada (con números) STF
<li> Define un ítem de una lista STF
<dir> DESACONSEJADO. Define una lista de direcciones TF
<dl> Define una lista de definiciones STF
<dt> Define un término de definición STF
<dd> Define una descripción de una definición STF
<menu> DESACONSEJADO. Define una lista de menú TF
126

Imágenes
<img> Define una imagen STF
<map> Define un mapa de imagen STF
<area> Define un área dentro de un mapa de imagen STF
Tablas
<table> Define una tabla STF
<caption> Define un título (o subtítulo) de tabla STF
<th> Define una celda de encabezado de tabla STF
<tr> Define una línea de una tabla STF
<td> Define una celda de datos de una tabla STF
<thead> Define en encabezado de una tabla STF
<tbody> Define un cuerpo de una tabla STF
<tfoot> Define un pie de una tabla STF
<col> Define atributos para las columnas de una tabla STF
<colgroup> Define grupos de columnas de una tabla STF
Estilos
<style> Define una definición de estilo STF
<div> Define una sección en un documento STF
<span> Define una sección en un trozo de documento STF
Meta información
<head> Define información sobre el documento STF
<title> Define el título del documento STF
<meta> Define meta información STF
<base> Define una URL de base para todos los enlaces de una
página STF
<basefont> DESACONSEJADO. Define una fuente base TF
Programación
<script> Define un script STF
<noscript> Define una sección noscript STF
<applet> DESACONSEJADO. Define un applet TF
<object> Define un objeto incrustado STF
<param> Define un parámetro para un objeto STF
127

Atributos HTML
Las etiquetas del HTML pueden tener «atributos». Los atributos enumera-
dos aquí son los principales, los de idioma y los de teclado, que son
estándares para todas las etiquetas (con algunas excepciones).
Atributos principales
No son válidos en los elementos: base, head, html, meta, param, script,
style y title.
Atributo Valor Descripción

Class class_rule o style_rule La clase del elemento
id id_name Identificador de un único elemento
style style_definition Una definición de estilo en línea
title tooltip_text Un texto mostrado como un tool tip*
*Tool tip: cuadro emergente que muestra información de ayuda o amplía la información.
Atributos de idioma
No válidos en los elementos: base, br, frame, frameset, hr, iframe, param y
script.

dir ltr | rtl Establece la dirección del texto
lang language_code Establece el idioma en que está el código
Atributos de teclado:

accesskey character Establece un atajo de teclado para acceder a un elemento
tabindex number Establece el orden de tabulación para un elemento
128

Atributos de eventos en HTML
A partir de HTML 4.0 se tiene la posibilidad de ejecutar eventos en el

navegador, como iniciar un script cuando el usuario pincha sobre un ele-
mento. En las tablas siguientes se describen los atributos que se pueden
insertar en las etiquetas HTML para definir acciones de evento.
Eventos de ventana
Sólo válidos para en elementos de «body» y «frameset».

onload script Script se ejecuta cuando el documento se carga
onunload script Script se ejecuta cuando el documento se descarga
Eventos de elementos de formulario
Sólo valido para elementos de formulario.

onchange script Script se ejecuta cuando el elemento cambia
onsubmit script Script se ejecuta cuando el formulario se envía
onreset script Script se ejecuta cuando el formulario se reinicia
onselect script Script se ejecuta cuando el elemento es seleccionado
onblur script Script se ejecuta cuando el elemento deja de enfocarse
onfocus script Script se ejecuta cuando el elemento se enfoca
Eventos de teclado
No valido en los elementos: base, bdo, br, frame, frameset, head, html,
iframe, meta, param, script, style y title.

onkeydown script Qué hace cuando la tecla se presiona
onkeypress script Qué hace cuando la tecla se presiona y se libera
onkeyup script Qué hace cuando la tecla se libera
129

Eventos de ratón
No valido en los elementos: base, bdo, br, frame, frameset, head, html,
iframe, meta, param, script, style y title.

onclick script Qué hace cuando se pica con el ratón
ondblclick script Qué hace cuando se pica doble con el ratón
onmousedown script Qué hace cuando el botón del ratón se presiona
onmousemove script Qué hace cuando el puntero del ratón se mueve
onmouseover script Qué hace cuando el puntero del ratón se mueve sobre un
elemento
onmouseout script Qué hace cuando el puntero del ratón se mueve fuera de
un elemento
onmouseup script Qué hace cuando el botón del ratón es liberado
130

¿Qué es CSS?
CSS es la abreviatura de Cascading Style Sheet (Hojas de estilo en cas-

cada). Su finalidad es definir cómo se han de mostrar los elementos HTML
y con qué estilo se han de presentar. Los estilos son, normalmente, alma-
cenados en hojas de estilo y fueron añadidos en la codificación HTML para
solucionar algunos problemas. Las hojas de estilo externas pueden ahorrar
un buen montón de trabajo, como veremos más adelante y son almacena-
das en archivos CSS. Se pueden definir múltiples hojas de estilo para una
misma página web.
CSS soluciona problemas comunes
Las etiquetas HTML fueron diseñadas originalmente para definir el conteni-

do de un documento. Supongamos que decimos «Éste es un encabeza-
miento», «Éste es un párrafo», «Ésta es una tabla» y lo hacemos utilizan-
do etiquetas HTML como <h1>, <p> o <table>. La maquetación del
documento así realizada debe ser tomada con cuidado por el navegador si
no utiliza ningún formato para las etiquetas.
Dos de los más utilizados navegadores (Internet Explorer y Netscape)
añadieron nuevas etiquetas HTML y atributos, tales como <font>, a la
especificación original HTML. Esto supuso más dificultades a la hora de
crear sitios web, donde el contenido de los documentos HTML estaba cla-
ramente separado de la maquetación de presentación del documento.
Para resolver este problema, W3C creó los Estilos, como complemento
al HTML 4.0. Hoy día la mayoría de los navegadores soportan CSS.
131

Las hojas de estilo ahorran trabajo
Las hojas de estilo definen cómo se muestran los elementos HTML, tal
como lo hacía la etiqueta <font> o el atributo de color en HTML 3.2. Las
hojas de estilo se guardan, normalmente, en archivos CSS externos. Estas
hojas de estilo externas están disponibles para cambiar la apariencia y la
maquetación de todas las páginas de un sitio web, solamente editando un
documento CSS.
Las CSS son un gran paso adelante en el diseño web porque permiten
el control del estilo y la maquetación de muchas páginas desde una sola.
Un desarrollador puede definir un estilo para cada elemento HTML y apli-
carlos a tantas páginas como él quiera. Haciendo un cambio global, con un
simple cambio en el estilo, todos los elementos de una web son renovados
automáticamente.
Múltiples hojas de estilo en una
Las hojas de estilo permiten especificar la información sobre el estilo de

muchas maneras. Los estilos pueden ser especificados dentro de un ele-
mento HTML, dentro del elemento <head> de una página HTML o en un
archivo CSS externo. Incluso varias hojas de estilo externas pueden ser
referenciadas desde un solo documento HTML.
¿Qué estilo será usado cuando hay más de una especificación de es-
tilo para un elemento HTML? Hablando de forma genérica, podemos decir
que todo estilo está en una «cascada» en una nueva hoja de estilo «vir-
tual» siguiendo la siguiente regla, donde los números indican la prioridad:
1. Estilo en línea (dentro del un elemento HTML).

2. Hoja de estilo interna (dentro de la etiqueta <head> de la página web).
3. Hoja de estilo externa.
4. Hoja de estilo por defecto del navegador.
Así, el estilo en línea tiene la más alta prioridad, la cual significa que
anulará a la declaración de estilo dentro de la etiqueta <head> de la pági-
na, a la hoja de estilo externa o a la que usa por defecto el navegador.
132

Sintaxis de CSS
La sintaxis de CSS consta, básicamente, de tres partes:
1. Selector.
2. Propiedad.
3. Valor.
Su expresión escrita sería:
Selector {propiedad: valor}
El selector es, normalmente, un elemento o una etiqueta HTML al que

se desea definir; la propiedad es el atributo que se desea cambiar; y cada
propiedad puede tomar un valor. La propiedad y el valor están separados
por dos puntos y rodeados por corchetes.
Un ejemplo simple de sintaxis sería:
body {color: #000000}
Si el valor tiene varias palabras, éstas deberán ir entre comillas:
p {font-family: "sans serif"}
Si se desea especificar más de una propiedad para un selector, éstas

deberán ir separadas por punto y coma:
P {font-family: "sans serif"; text-align: center}
Para hacer más legible la definición se suele redactar de tal manera

que cada propiedad ocupe una línea:
Font-family: "sans serif";
Text-align: center
133

Se pueden agrupar selectores, separándolos con una coma.
h1, h2, h2, h4, h5, h6
color: #990099
A los selectores se les puede añadir una «clase» (class) de tal manera
que se pueden definir distintos estilos para un mismo elemento HTML.
Supongamos que queremos definir dos tipos de párrafos: uno alineado a
la izquierda y otro centrado. Lo podemos hacer con clases para el elemen-
to «p».
p.centrado {text-align: center}
p.izquierda {text-align: left}
Después basta especificar la clase para el selector dentro del código

HTML de la siguiente manera:
<p class="centrado">Este texto está centrado</p>
<p class="izquierda">Este texto está alineado a la

izquierda</p>
Sólo se puede definir una clase para un elemento en la codificación

HTML.
Se puede omitir el elemento que hace la función de selector y definir
una clase que será usada por todos los elementos HTML en la que se
defina. Por ejemplo:
.centrado {text-align: center}
Esta clase se la podremos aplicar a distintos elementos. Por ejemplo:
<p class="centrado">Texto</>
<h1 class="centrado">Encabezado</h1>
134

Tercera parte
HACER UNA BITÁCORA

ACCESIBLE
Carlos
Carlos Egea García
Nombre de reconocimiento
(DN): cn=Carlos Egea
Egea
García, o=Consultores
Sociales CEyAS sl.,
ou=Director,
García c=ES
Fecha: 2007.11.08 19:25:33
+01'00'
EJERCICIO PRÁCTICO
Esta práctica tiene una deuda personal con el trabajo realizado por Mark
Pilgrim en el año 2002 al crear su «Dive into accessibility» [«Inmersión en la
accesibilidad»]. En él nos hemos inspirado para realizar este trabajo y por
ello creo obligado recomendar su lectura para cualquiera que esté interesa-
do: http://www.diveintoaccessibility.org
135

136

Introducción
Esta parte del documento tiene una intencionalidad didáctica. Como el propio
nombre de este apartado indica, la práctica consistirá en realizar una bitá-
cora accesible. Para ello habrá que seguir los pasos que se detallan en
ella.
Se ha tomado como herramienta de edición para la bitácora la que pro-
porciona Blogger. Entremos en su sitio en la web (http://www.blogger.com),
solicitemos crear una bitácora y familiaricémonos con la herramienta.
Existe una versión en línea de esta documentación, realizada como
una bitácora, un tanto especial, con el editor de Blogger. La dirección de
esta bitácora es: http://usuarios.discapnet.es/disweb2000/blog/.
137

138

Primeras instrucciones
En primer lugar, nos debemos acostumbrar a la palabra «post», que es el

nombre que recibe cada uno de los pequeños artículos que componen la
bitácora.
Cualquier término que necesite aclaración, lo colocaremos entre comi-
llas y, justo detrás, encerrado entre corchetes [ ], daremos una breve expli-
cación.
139

140

Paso 1
¿Para quién es la accesibilidad web?
Si nos preguntamos: ¿para quién es la accesibilidad?, la respuesta es sen-

cilla: «Para todos». Pero mucho me temo que esto no convencería a mu-
cha gente, pese a que es completamente cierto.
Por ese motivo voy a dar una serie de explicaciones sobre a qué gru-
pos de personas, en concreto, la accesibilidad web va a beneficiar.
El grupo más evidente es el de personas con ceguera. No hace mu-
cho tiempo, charlando con un profesor universitario de informática sobre
unos cursos de accesibilidad en la web, éste se asombraba al saber que
estas personas se colocaban ante un ordenador y realizaban con él una
amplia gama de trabajos. «Pero, ¡si no ven!» fue su asombrada exclama-
ción. Tuve que explicarle que ellos acceden al contenido a través del oído,
mediante lectores de pantalla, o por el tacto, con sus dispositivos de salida
braille, que les leen el contenido en pantalla. «Y ¿cómo ven las imágenes,
los iconos y demás elementos no textuales». Ésa es la cuestión, no existe
(hoy día) ningún dispositivo que pueda interpretarlos de forma razonable
para las personas con ceguera. Por lo tanto, habrá que hacer algo para
que el contenido visual no textual pueda llegar a ellos. Esto lo veremos
más adelante al hablar del atributo «alt».
Pero con problemas visuales hay mucha más gente. Los hay que tie-
nen las conocidas como cegueras de color, que habitualmente asocia-
mos con el «daltonismo». Estas personas no distinguen determinados cam-
bios en el color, por lo que la información que trasmitamos mediante cambios
de color no los podrán percibir. Así, por ejemplo, en un catálogo de libros
donde se nos informe que los títulos en rojo no están disponibles habrá
personas que no puedan apreciar este cambio. Por ese motivo deberemos
dar otro tipo de alternativa si queremos que la información les llegue. Otro
típico problema con los colores es el contraste. Un texto o una imagen que
contraste poco con su fondo pueden no ser percibida por personas con
141

este problema visual. Todo ello lo veremos al hablar de los problemas con
el color.
Siguiendo en el ámbito de los problemas visuales, hay otro grupo de
personas que tienen problemas de agudeza visual. Éstas necesitan am-
pliar mucho el contenido de la pantalla, lo que hacen ampliando el tamaño
del contenido de nuestras páginas web o mediante programas
magnificadores de pantalla. Son capaces de ver el contenido pero, si las
letras o imágenes no están correctamente diseñadas para poder ser am-
pliadas, tendrán problemas para captarlo. También hablaremos de esto al
tratar sobre los tamaños relativos en la hoja de estilo.
No sólo las personas con problemas visuales encuentran barreras al
navegar por la web. Las personas con dificultades motrices en sus
manos pueden encontrar serios problemas para navegar si no diseñamos
nuestra web de tal manera que permita la navegación mediante teclado.
Para ello es muy útil definir atajos de teclado [acceskeys] para acceder a
los bloques o lugares destacados del contenido de nuestra web y sobre
ello también hablaremos.
Las personas con dificultades auditivas o sordera tendrán proble-
mas con los contenidos sonoros, si éstos no van provistos de una alterna-
tiva visual. También es posible, en el caso de usuarios de lengua de sig-
nos, que tengan dificultades para comprender contenido textual si éste utiliza
expresiones poco habituales o demasiado complejas sobre las que no ha-
cemos una explicación sencilla y comprensible para todos. Por ello debe-
mos hacer los contenidos comprensibles y proporcionar ayudas, como la
utilización de explicaciones para las abreviaturas o acrónimos, sobre los
que también hablaremos.
También las personas con dificultades de aprendizaje o con
discapacidades intelectuales encuentran obstáculos para navegar por la
web. Necesitan contenidos claros y ayudas visuales con iconos claros y explí-
citos de las funciones que cumplen. Las explicaciones, que podemos añadir
mediante el atributo «title», serán de mucha utilidad para estas personas.
Pero la larga lista de grupos de personas a las que beneficia un diseño
accesible de nuestras páginas web no acaba aquí. Ya lo dijimos al comien-
zo, beneficia a todos y no estábamos exagerando.
Las personas con poco dominio del idioma en que está escrita la web
se benefician de unos contenidos claros e intuitivos. Las personas que
142

manejan equipos antiguos con sistemas operativos basados sólo en texto
accederán a todo el contenido si las imágenes disponen de texto alternati-
vo. Las personas que manejan ordenadores en entornos ruidosos o con
deficiente iluminación captarán mejor el contenido si éste no se basa ex-
clusivamente en sonidos y dispone de colores con buen contraste. Pero
también las personas que manejan los nuevos dispositivos de acceso al
contenido web (teléfonos móviles, palmtop, etc.) se ven beneficiadas de
un correcto diseño que permita la flexibilidad suficiente para adaptarse a
sus pequeñas pantallas.
La lista es larga y, por lo tanto, justifica suficientemente los esfuerzos
que podamos realizar para hacer una web accesible.
Así pues, ¡felicidades! Has hecho una buena elección al tratar de apren-
der cómo hacer una bitácora accesible. Todo lo que explico aquí podrás
aplicarlo al diseño de cualquier tipo de página web. Mi pretensión es guiar-
te en una práctica sencilla que tiene como finalidad introducirte en el dise-
ño accesible. Más adelante podrás seguir profundizando hasta conocer los
más íntimos recovecos del «diseño para tod@s» aplicado a las web.
143

Paso 2
Elegir un DOCTYPE
Al igual que cuando comenzamos a escribir una frase lo hacemos con una
letra mayúscula, al comenzar una página web nuestro código debe co-
menzar con un DOCTYPE. Es una cuestión de gramática.
Hacerlo de forma correcta nos beneficia a todos, ya que algunas de
las funciones de nuestro navegador dependen de que la página visitada se
presente correctamente, identificándose con el DOCTYPE correspondiente
a su codificación.
El DOCTYPE es la forma que tiene nuestra página web de decirle al
navegador que la visita en qué «lenguaje» está escrita para que éste pue-
da saber cómo entenderse con ella.
Hay diferentes DOCTYPE, tantos como tipos de código recomendados
por W3C [World Wide Web Consortium - Consorcio Mundial de la Web]:
HTML 4.01 y XHTML 1.0 (en sus versiones «estricta» o «transacional»),
XHTML 1.1 y XML, básicamente.
En el caso de Blogger, por fortuna, los desarrolladores tuvieron en cuen-
ta este detalle y nos han ahorrado trabajo. Si editamos la plantilla principal
(seleccionando la solapa «plantilla» del editor del Blogger) podemos ver
que la primera línea de código fuente es:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict/

/EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd">
Ésta es una gran ventaja, ya que este paso no nos va a dar trabajo.
Compruébalo y recuerda que para otros desarrollos debes tener en
cuenta que la primera línea de código de tus páginas web en HTML tiene
que llevar este tipo de declaración.
Para aprender más cosas sobre DOCTYPE puedes visitar el sitio «HTML
conClase» (http://html.conclase.net).
144

Paso 3
Identificar el idioma
Sabemos en qué idioma estamos escribiendo, así que debemos decírselo

a nuestros lectores... y a los programas de navegación que estén usando.
Si lo hacemos correctamente, los programas lectores de pantalla, como
JAWS, podrán pronunciar las palabras correctamente al leer en voz alta el
contenido del documento. De otro modo sonará como si un inglés, sin co-
nocimientos de español, leyera un texto escrito en este idioma o viceversa.
También es útil para los buscadores del tipo Google, que indexan las
páginas que exploran por el idioma en que decimos que están escritos.
Para que nuestra página web le informe al navegador sobre el idioma
en que está escrito, existe una convención por la cual éstos se declaran
con dos letras. Así el castellano (o español) será «es», el inglés «en» o el
francés «fr». Se puede encontrar la larga lista de esta convención en:
http://www.loc.gov/standars/iso639-2/englangn.html.
Para hacer la declaración de idioma en nuestra bitácora tendremos

que recurrir de nuevo a la plantilla principal (seleccionando la pestaña «plan-
tilla» del editor de Blogger). Justo debajo del DOCTYPE encontraremos
una línea de código como ésta:
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en" lang="en">
Ahora nos toca modificarla así:
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="es" lang="es">
De origen, los diseñadores de las plantillas de Blogger definieron el

inglés como el idioma en que estará escrita nuestra página, pero nosotros
145

vamos a usar el castellano (español). Sin este cambio es posible que po-
damos confundir a los lectores de pantalla.
En las páginas con código HTML 4.01 el atributo «lang» lo colocare-
mos en la etiqueta que encontramos tras el DOCTYPE del siguiente modo:
<html lang="es">
Pero éste no es el único momento en que deberemos usar el atributo

«lang». Si a lo largo del texto de nuestro contenido insertamos frases en
otro idioma, deberemos declarar el cambio en la correspondiente etiqueta.
Este atributo se puede aplicar en todas las etiquetas excepto:
applet, base, basefont, br, frame, frameset, iframe,

param y script
Un ejemplo de su aplicación podría ser:
Y con suave voz le dijo en inglés:

<blockquote lang="en">I love you.</blockquote>
A partir de ese momento prevalecerá la declaración de idioma realiza-

da al comienzo y regresará a leer en castellano (español).
146

Paso 4
Elegir un título significativo
Toda página web debería tener un título único y significativo.

Para la página principal podemos elegir como título el mismo que tiene
todo nuestro sitio, pero para el resto sería recomendable elegir un título
que identificara su finalidad o contenido.
En el caso de una bitácora, podemos elegir para los agrupamientos de
páginas la combinación del título de nuestra web con el motivo del agrupa-
miento. Por ejemplo, si una de las categorías de agrupamiento fuera «le-
gislación», podríamos titular a esa página que agrupa los «post» pequeños
artículos] como «Nombre del sitio/Legislación».
Para cada uno de los «post» lo más indicado es que se titulen como el
propio «post» o una abreviatura del mismo, pero siempre recomendamos
que vaya acompañado (mejor precedido) por el título del sitio. Por ejem-
plo, la página de un «post» titulado «Accesibilidad en la Web» podríamos
llamarla «Nombre del sitio/Accesibilidad Web».
Si la mecánica de archivo que nos interesa hacer patente es la de
fecha de inserción del «post», siguiendo la misma lógica apuntada antes,
lo suyo sería poner el nombre del sitio y a continuación la fecha de inser-
ción del «post». Así, la página del «post» del 24 de mayo de 2006 la
titularíamos «Nombre del sitio/25-05-2006», por ejemplo.
Colocar títulos significativos a nuestras páginas beneficia a los navegan-
tes con lectores de pantalla, ya que lo primero que éstos hacen es leer ese
título. Pero también a los usuarios de navegadores sólo texto o con disposi-
tivos de lectura braille, que listan las páginas visitadas utilizando su título. A
las personas con dificultades de comprensión también les reporta beneficios,
ya que con una sola mirada ubican el contenido de la página entre otras que
puedan tener abiertas. Los robots de búsqueda también utilizan el contenido
de ese título de página para indexarlas. Así pues, reporta grandes beneficios
elegir un título significativo para nuestras páginas web.
147

Blogger realiza este trabajo por nosotros, ya que para titular la página
de inicio utiliza el nombre de nuestra bitácora, para las páginas de cada
«post» utiliza dicho nombre seguido del título del «post» y para las páginas
de las agrupaciones por meses toma el título de la bitácora al que hace
seguir el mes correspondiente en el que se inserta el «post». De nuevo
nos ahorra tiempo y se muestra como una buena elección para hacer nues-
tra bitácora accesible.
Si se quiere saber más sobre este tema (y se domina el inglés lo sufi-
ciente), sobre todo el comportamiento de otros programas para hacer
bitácoras, se puede leer sobre ello en el sitio recomendado «Dive into
Accessibility» de Mark Pligrim, concretamente en esta página:
http://diveintoaccessibility.org/
day_8_constructing_meaningful_page_titles.html.
148

Paso 5
Ayudas adicionales a la navegación
Seguimos todavía en esa parte oculta de las páginas web que no se muestra
en los navegadores, pero que podemos ver editando el código fuente de
las mismas. Otra etiqueta habitual en esta zona es <link>, que frecuente-
mente asociamos con las hojas de estilo en cascada, ya que la referencia
a ellas se hace mediante esta etiqueta. Además de servirnos para hacer
referencia a la hoja u hojas de estilo que queramos aplicar a nuestra bitá-
cora, nos puede ser útil para proporcionar ayuda a los navegantes, dando
la posibilidad de ir rápidamente a la página principal o a los «post» anterior
o posterior. Este efecto lo conseguiremos con un código parecido a este:
<link rel="Principal" title="Página principal"

href="http://dirección de la página principal" />
<link rel="Previa" title="Página anterior"
href="http://dirección de la página anterior" />
<link rel="Siguiente" title="Página siguiente"
href="http://dirección de la página siguiente" />
Esta ayuda es útil para ciertos navegadores no visuales como Lynx o

Links, aunque también en algunos de los navegadores visuales como Mozilla,
Firefox u Opera son de utilidad, ya que muestran al usuario estos enlaces
rápidos.
Lamentablemente, en el caso de Blogger la plantilla principal no nos
deja controlar esta posibilidad y no podremos automatizarla. Nos tendremos
que conformar con dar la posibilidad de proporcionar un acceso rápido a la
página principal si insertamos en el <head> la siguiente declaración:
<link rel="Principal" title="Página principal"

href="<$BlogUrl$>" />
149

Paso 6
Colocar primero el contenido principal
Las personas que navegamos por la web con navegadores visuales, del
tipo IExplorer, Opera, Mozilla o Firefox, dirigimos nuestra mirada al conte-
nido principal de la página, sin que la colocación de la barra de navegación
de la web visitada nos afecte para nada. Nos es indiferente que esté de
forma horizontal o vertical, a la derecha o a la izquierda. Pero esto no es
indiferente para las personas que navegan con lectores de pantalla (tipo
JAWS), sólo texto (como Lynx o Links) o con dispositivos de salida braille.
Para ellos una barra de navegación colocada antes del contenido principal
puede ser una auténtica tortura, ya que cada vez que visitan una página de
nuestra web tendrán que escuchar o navegar por toda ella hasta llegar a lo
que interesa: el contenido principal.
Por ello, a la hora de hacer nuestra bitácora accesible, podremos op-
tar por alguna de estas fórmulas:
• Podemos elegir una plantilla prediseñada que muestre el menú de na-

vegación en vertical a la derecha. Nos cercioraremos de que en el có-
digo fuente de la plantilla el contenido principal está colocado antes que
el menú de navegación. Ésta, seguro, es la más cómoda y sencilla de
las soluciones.
• Si optamos por elegir otra de las plantillas que llevan el menú de nave-
gación a la izquierda tendremos que emplear un pequeño truco. Edita-
remos la plantilla principal (en la solapa plantilla de editor de Blogger) y
seleccionaremos todo el texto contenido entre los comentarios <!—
Begin #sidebar —> y <!— End #sidebar —>, incluyendo ambos
comentarios, y lo trasladaremos detrás del contenido principal (que está
colocado entre <!— Begin #main —> y <!— End #main —>). Los
bloques <div> están maquetados y colocados en la página mediante
los estilos de nuestra página. Por ese motivo, da igual el orden que
150

lleven en el código fuente, siempre aparecerán en el lugar que les fija
el estilo. Pero para los lectores de pantalla y navegadores que no inter-
pretan las hojas de estilo, el orden del código fuente es el que se muestra
en pantalla.
• Otra posibilidad, si optamos por una barra de navegación colocada an-
tes que el contenido principal de la página, es proporcionar un marca-
dor o vínculo interno que posibilite el «salto de la barra de navegación».
¿Cómo podemos hacerlo?:
1. En la hoja de estilos se crea una clase (class) que puedes llamar
"ocultar" del siguiente modo: .ocultar {display:none;}
2. En el párrafo <p> donde se vaya a colocar el enlace interno debe-
mos dar esa clase de esta forma: <p class="ocultar"><a
href="#contenido">Salta menú</a>
3. Luego colocamos el vínculo interno "contenido" justo al comien-
zo del bloque que contiene el contenido principal.
• Pero hay personas que no tienen una limitación visual y navegan utili-
zando sólo el teclado, como es el caso de las personas con dificultades
motrices en sus manos. Para ellos no es buena la opción anterior. Como
el navegador no les muestra en pantalla el enlace para saltar la barra
de navegación, que hemos ocultado, tendrán que ir saltando cada uno
de los enlaces de nuestra barra de navegación hasta alcanzar el conte-
nido principal y navegar por el mismo. Para resolver este pequeño pro-
blema, podemos optar por no ocultar completamente nuestro vínculo
interno. Sólo lo ocultaremos visualmente, dando a sus letras el mismo
color del fondo de nuestra página. Igual que hicimos antes, esto lo po-
demos controlar mediante la hoja de estilo, creando una clase como
esta:
.letratransparente{font-color:#FFFFFF} (donde FFFFFF es

el color del fondo).
Luego basta con dar esta clase al párrafo <p> donde irá el salto de la
barra de navegación y todo arreglado.
Para aquellos que todavía maquetan con tablas (opción admitida, aun-
que no recomendada), les podemos aconsejar la siguiente fórmula.
151

Si su página está maquetada con una tabla de dos columnas donde la
izquierda es el menú de navegación y la derecha el contenido principal, en
lugar de la maquetación obvia:
<table>
<tr>
<td valign="top" align="left" width="25%">
... barra de navegación ...
</td>
<td valign="top" align="left">
... conetnido principal ...
</td>
</tr>
</table>
Pueden colocarla de esta forma:
<table>
<tr>
<!— imagen espaciadora en la celda superior izquier-
da —>
<td>
<img src="/images/1.gif" width="1" height="1"
alt="">
</td>
<!— contenido principal en la primera celda, con
rowspan=2 —>
<td valign="top" align="left" rowspan="2">
... contenido principal ...
</td>
</tr>
<tr>
<td valign="top" align="left" width="25%">
... barra de navegación ...
</td>
</tr>
<table>
152

Paso 7
El uso de los colores
Poco a poco nos vamos adentrando en tareas más complicadas. Dejamos

atrás el <head> y empezamos a trabajar con elementos del <body>, em-
pezando con el manejo del color.
La norma general es usar el color de forma segura. La manera de
hacerlo es asegurarse de que no trasmitimos información exclusivamente
a través del color.
Veamos un ejemplo:
Supongamos que en nuestra bitácora estamos informando sobre artí-
culos y documentos disponibles en la web sobre un determinado tema. La
web es un medio dinámico y algunos contenidos, pasado un tiempo, pue-
den desaparecer. A nosotros nos interesa mantener la información sobre
los artículos y documentos, pero debemos dar cuenta de aquellos que ya
han desaparecido. ¿Cómo podemos hacer para comunicar a nuestros visi-
tantes de que un documento ya no está disponible en la web?
Una forma, más usual de lo que debería ser, es decir algo así: «Los
artículos en rojo ya no están disponibles en la web». El problema es que
entre nuestros visitantes hay personas que no ven los colores o los perci-
ben de forma incorrecta. Si sólo hemos puesto el color rojo como pista
para saber que ya no está disponible el artículo, estas personas no sabrán
qué artículos de nuestra lista son.
Otra mala costumbre que cada día se está generalizando más con el
uso de las hojas de estilo es modificar la presentación de los vínculos de
nuestras páginas web de tal manera que no destacan en el texto. Esto
despista mucho a usuarios poco expertos y a personas que tienen proble-
mas con la percepción del color. Debemos procurar que los vínculos que-
den claramente perceptibles para nuestros visitantes en lugar de ocultarlos
visualmente. Y esto nos puede afectar a todos.
153

Del mismo modo, la presentación de vínculos exclusivamente median-
te el cambio de color puede suponer un problema para algunos usuarios
que al pasar sobre ellos el cursor del ratón o al colocar el foco sobre ellos
mediante el teclado no perciben este cambio. Un ejemplo lo tenemos aquí:
1. Este vínculo subrayado y en azul, que es el comportamiento por defec-

to.
2. Este vínculo coloreado y en negrita, usando estilos de nuestra hoja.
3. Este vínculo sólo coloreado, también usando estilos de nuestra hoja.
Una persona con problemas de visión para los colores, como el dalto-
nismo, vería estas tres frases del siguiente modo:
1. La primera frase no presenta problemas.

2. Una persona con daltonismo verá el color azul y tiene más pistas me-
diante el subrayado. La segunda frase pierde el color rojo, pero sigue
dando una pista con la letra negrita que resalta en el texto.
3. Sin embargo, la tercera frase pierde el color rojo y no da ninguna pista
del vínculo para quien tenga ceguera para el color rojo.
Una forma sencilla de solucionar la manera de destacar nuestros enla-

ces es mediante la hoja de estilo. Podemos incluir una categoría similar a
esta:
a {
color:#3333FF; /* el típico color azul de los vín-
culos, pero podemos usar cualquier otro */
text-decoration:underline; /* para que aparezca
subrayado */
font-weight:bold; /* para que aparezca en negrita */
}
De alguna manera, además de mediante el color, tenemos que trans-

mitir la presencia del vínculo. Si lo hacemos de más de una, seguro que
acertaremos con la más adecuada para cada usuario. Luego, también
mediante las hojas de estilo, podemos dar propiedades para cuando esta-
mos apuntando al vínculo ("hover") o cuando el vínculo ya ha sido visita-
154

do ("visited"). Pero lo más importante es no olvidar que la información
debe ser percibida independientemente del color.
Otro problema que suele dar el uso de colores es la falta de contraste
entre el fondo y la forma. Esto rige tanto para el texto como para las imá-
genes (sobre todo si éstas contienen texto). El W3C ha recomendado un
algoritmo que nos puede ser útil para saber si el contraste de los colores
que usamos es el adecuado. En función de ese algoritmo se han desarro-
llado algunas herramientas que nos pueden ayudar a aplicarlo. Personal-
mente, me gusta usar la denominada «Analizador de contraste de color»
(en inglés «Colour contrast analyser» CCA), desarrollada por Accessible
Information Solutions de NILS, en Australia. Dispone de una versión en
castellano [español] que se puede descargar gratuitamente en: http://
www.nils.org.au/ais/web/resources/contrast_analyser/versions/es/.
Otras referencias importantes para conseguir más información sobre
el correcto uso del color en nuestra web son éstas:
• Vischeck (http://www.vischeck.com/vischeck/), que simula la ceguera de

color y permite ver lo que las personas con ceguera de color ven.
• Color Vision de Carl Henderson (http://www.iamcal.com/toys/colors/), que
muestra el espectro de color tal como lo ven personas con diferentes
tipos de ceguera de color.
• Ishihara Test for Color Blind [Test para la ceguera de color Ishihara]
(http://toledo-bend.com/colorblind/Ishihara.html), que contiene una serie
de imágenes que las personas con ceguera de color para el rojo y el
verde ven de forma diferente o no las ven.
• La barra de accesibilidad de AIS (versión en castellano [español] en:
http://www.technosite.es/software.asp) dispone de una funcionalidad para
el análisis de color.
Ahora te toca a ti. Utiliza alguna de estas herramientas para compro-

bar que en tu bitácora se respeta el contraste de color.
155

Paso 8
Vínculos reales
Uno de los problemas que más molestan a los usuarios de páginas web es
el uso de vínculos en «javascript». Son pseudo-vínculos que ejecutan un
trozo de código JavaScript cuando pinchamos sobre ellos. ¿Por qué es un
problema? Porque algunos usuarios de internet no utilizan JavaScript por
diferentes motivos. Unos lo hacen por motivos de seguridad, ante posibles
intromisiones en su sistema, y otros simplemente porque sus navegadores
(ya sea por anticuados o por ser de características especiales) no lo so-
portan. También hay que tener en cuenta que buscadores, como Google,
no pueden indexar los enlaces en JavaScript, ya que no lo ejecutan. Este
último sería motivo suficiente para desistir de utilizar este tipo de pseudo-
vínculo.
Afortunadamente, los editores de bitácoras y, concretamente, el de
Blogger no utilizan la técnica del vínculo «javascript», pero si manejamos
alguna versión antigua podemos encontrarnos, para la edición de comen-
tarios, con un vínculo como éste o similar (este ejemplo sirve para las
viejas versiones de Movable Type):
<a href="javascript:OpenComments
(<$MTEntryID$>)">Comentarios(<$MTEntryCommentCount$>)
</a>
Si fuera así, debes sustituirlo por algo así:
<a href="<$MTCGIPath$>mt-comments.cgi?entry-
id=<MTEntryID$>" onclick="OpenComments
(<MTEntryID$>); return
false">Comentarios<(<$MTEntryCommentCount$>)</a>
156

En los navegadores con JavaScript habilitado, esto funcionará de igual
manera porque el atributo "onclick" tiene preferencia sobre el atributo
"href".
Como práctica habitual, olvide hacer sus enlaces mediante JavaScript.
Molestan a mucha gente y añaden poca funcionalidad a nuestro trabajo.
157

Paso 9
Vínculos correctos y con títulos
Lo más importante de una página web son sus vínculos. Son lo que les da
sentido. Si no existieran vínculos sería como compartir otro tipo de archi-
vos, que se puede hacer mediante otro tipo de protocolos, también dispo-
nibles en internet. Por lo tanto, es importante que los usuarios conozcan
para qué sirven los vínculos en un sitio web.
El texto que utilizamos para un vínculo es esencial. Así, esos frecuen-
tes vínculos con textos del tipo «pincha aquí» o, simplemente, «aquí» de-
jan de tener su utilidad si se les saca de contexto. Algunos navegadores,
tanto visuales como de otro tipo, proporcionan al usuario un listado de los
vínculos de la página visitada. Imaginemos que tengo un texto en el que
proporciono los siguientes vínculos:
Si quieres conocer mi currículum pincha aquí.

Desde aquí puedes acceder a las fotos de mi familia.
Mis aficiones favoritas las encontrarás aquí.
Cuando el navegador muestre o lea los vínculos de este texto, el usua-

rio se encontrará con:
pincha aquí
aquí
aquí
Este listado carece de utilidad para navegar, ya que desconocemos

que hay detrás de «aquí». Ese mismo texto sería más útil con los enlaces
colocados en otro lugar:
Si quieres conocer mi currículum pincha aquí.

Desde aquí puedes acceder a las fotos de mi familia.
Mis aficiones favoritas las encontrarás aquí.
158

Ahora el listado será mucho más significativo:
mi currículum
mi familia
Mis aficiones
La diferencia entre uno y otro texto es sólo el lugar donde hemos colo-
cado el vínculo. La próxima vez que encontremos un vínculo con texto
«aquí» miraremos a ver si se podría haber colocado en un mejor lugar
para hacer más comprensible el texto del vínculo. Seguro que lo encontra-
mos (al menos, en 9 de cada 10).
Otro factor que hace más comprensibles los vínculos es «titularlos».
Esto se hace mediante el atributo "title" colocado junto a la dirección
del vínculo. Esta forma de proceder, colocando títulos a los vínculos, hace
más comprensibles su uso y destino para mucha gente, principalmente
para gente con problemas de comprensión, y añade información para el
general de los usuarios.
Utilicemos la segunda frase del texto anterior para poner un ejemplo.
Veamos cuál sería su código fuente sin el atributo "title":
Desde aquí puedes acceder a las fotos de <a

href="http://mi/familia.com">mi familia</a>
No podemos decir que esto sea incorrecto, pero sí que no proporciona

ayuda complementaria al usuario. Con el uso del atributo «title» podemos
aumentar la información. Vemos como:
Desde aquí puedes acceder a las fotos de <a

href="http://mi/familia.com" title="Albúm de fotos
familiar de las pasadas vacaciones">mi familia</a>
Ahora tenemos más información sobre el destino del vínculo.

El uso del atributo "title" se vuelve especialmente importante en
los textos de nuestros menús de navegación. Solemos utilizar palabras
sueltas o frases muy cortas, por lo que muchas veces no transmiten la
suficiente información. Si usamos dicho atributo, a los usuarios que mane-
jen navegadores visuales les aparecerá una «tooltip» [cuadro emergente
junto al puntero]; a los usuarios de lectores de pantalla, si activan la op-
159

ción, su programa les leerá el contenido del mismo; y en ciertos navegadores
sólo texto, como Lynx, al pulsar una tecla o combinación de tecla les apa-
recerá un listado de los vínculos, acompañados del título explicativo.
En determinadas ocasiones nos puede interesar que no aparezca el
cuadro emergente que nos muestran los navegadores visuales (por ejem-
plo, cuando usamos determinadas imágenes como vínculo). Para ello po-
demos utilizar un título vacío (title=""), colocando como valor del atri-
buto sólo las comillas sin espacio entre ellas. Esto hay que valorarlo
seriamente, ya que ese cuadro emergente amplia información que puede
ser útil a algunas personas.
¡MUY IMPORTANTE!
No confundir el atributo «title» y sus funciones el atributo «alt» y las
suyas. Sobre este atributo hablaremos más adelante. Ambos tienen
una función explicativa, pero el primero se mostrará en todo tipo de
navegadores y el segundo sólo debería ser leído por los lectores de
pantalla o navegadores por voz (aunque en IExplorer el comporta-
miento de «alt» sea semejante al de «title», en ausencia de éste).
160

Paso 10
Atajos de teclado
Un atributo HTML de los menos conocidos es «accesskey» para los vínculos

y los formularios. Permite al diseñador definir atajos de teclado para los
vínculos utilizados con frecuencia (por ejemplo, los de su menú de navega-
ción), así como para posicionarse en los campos de formulario. Un atajo de
teclado es una combinación en la pulsación de las teclas que para Windows
es ALT más un número o letra de nuestro teclado y para Macintosh es CON-
TROL más el correspondiente número o letra. El efecto es que cuando utili-
zamos el atajo de teclado (pulsando la combinación pertinente) el navegador
enfocará al lugar donde hayamos definido con el atributo "accesskey".
Los navegadores más antiguos no saben interpretar este atributo, pero tam-
poco les resulta pernicioso, por lo que es útil emplearlo para dar facilidades
a las personas que navegan con el teclado, ya sea porque utilizan lector de
pantalla o porque no puedan utilizar el ratón u otro dispositivo apuntador.
No existe un estándar establecido que defina cuáles son las teclas de
acceso en los atajos de teclado, por lo que el diseñador deberá establecer
las suyas propias. Hay que tener cuidado de que éstas no interfieran con
los atajos de teclado que el propio programa navegador tiene definido por
defecto (dichos atajos se pueden encontrar en la documentación de ayuda
del programa).
Sí existe una cierta conformidad en utilizar al menos estos tres atajos
de teclado:
ALT + 1: Página de inicio.

ALT + 2: Saltar la barra de navegación para ir al contenido principal.
ALT + 9: Formulario de contacto.
Veamos ahora cómo podemos hacer para aplicarlos.

En nuestra plantilla principal de Blogger (otra vez recordamos que está
en la pestaña «plantilla» del editor de Blogger) buscamos <$BlogTitle$>,
161

normalmente al comienzo de <body>. Si no está colocado en una etiqueta
<a> le colocaremos una que nos lleve a nuestra página principal de la
bitácora. Deberá quedar algo así:
<a href="http://pagina.inicio.blog"
accesskey="1"><$BlogTitle$></a>
De este modo habremos configurado nuestro atajo de teclado al lugar

de nuestra página donde se ubica el enlace a nuestra página principal. Al
usuario le basta con pulsar ALT + 1 y después Intro para estar en la página
principal de la bitácora.
Si disponemos de un vínculo para saltar la barra de navegación (tema
del que hablamos con anterioridad en el paso 6) podemos proporcionarle
un atajo de teclado, que podría quedar más o menos así:
<a href="#saltabarra" accesskey="2">Saltar barra de

navegación</a>
Igual que antes, con la combinación ALT + 2 y después Intro, nuestro

visitante habrá saltado la barra de navegación y se habrá colocado en el
contenido principal de la página.
Si disponemos de un vínculo a un formulario de contacto o con nuestra
dirección de correo electrónico, podemos hacer una operación similar para
hacer un atajo de teclado:
<a href="mailto:yo@midominio.com"
acceskey="9">Mándame un correo electrónico</a>
Con la combinación ALT + 9 seguida de Intro, el usuario abrirá su progra-

ma de correo electrónico dispuesto para remitirnos un mensaje.
El atributo «accesskey» lo podemos colocar en cualquiera de estas
etiquetas o elementos HTML:
A, AREA, BUTTON, INPUT, LABEL, LEGEND o TEXTAREA
Pero recuerda que no existe ningún estándar, por lo tanto debemos

explicar al visitante cuáles son los atajos de teclado que utilizamos en nuestro
sitio.
162

Paso 11
No abrir nuevas ventanas
Este paso es rápido y fácil de explicar (¡Esta vez ha habido suerte!).

Algunos desarrolladores diseñan sus páginas para que el visitante no
las abandone al primer click en un vínculo. Pretenden permanecer en pan-
talla el máximo tiempo posible. Para ello utilizan una técnica nada conve-
niente como es la de abrir una nueva sesión del navegador para que se
muestre la página a la que nos lleva el vínculo que hemos seleccionado.
Esta forma de proceder desconcierta a muchos usuarios. Las perso-
nas que no ven su pantalla y están navegando mediante un lector de pan-
talla o navegador por voz no saben que acaban de abrir una nueva venta-
na y si tratan de regresar, mediante el botón «Atrás» de su navegador,
descubren que han perdido el hilo de su navegación y lo deberán encon-
trar entre las páginas abiertas en su ordenador. También las personas con
problemas de inteligencia o aquellas que tienen poco hábito de navegar
por la web pueden encontrar sorprendente que no puedan regresar a la
página de origen que les llevó a la página que visualizan en ese momento.
Algunos navegadores, como Opera o Firefox, permiten abrir distintas
páginas en una misma sesión del navegador. Pero el habitual IExplorer (al
menos hasta su versión actual 6) abrirá una nueva sesión con cada venta-
na abierta.
Este pequeño, pero incomodo, problema es fácil de solucionar: no
abramos páginas nuevas o, si a pesar de todo pretendemos abrirlas, infor-
memos al usuario que al seleccionar el enlace se abrirá el destino en una
nueva ventana.
Para corregir un hipotético problema de este tipo en nuestra bitácora,
busquemos si en alguno de los vínculos de la misma existe un atributo
«target» como el que mostramos a continuación:
<a href="direccion.de.destino"
target="_blank">Destino del vínculo</a>
Simplemente tendremos que eliminar target=«_blank» y habremos so-

lucionado el problema.
163

Paso 12
Acrónimos
Los acrónimos y abreviaturas son cada vez más usuales en el lenguaje

común y no digamos cuando estamos hablando jergas profesionales. En
este documento hemos empleado ya un número considerable (W3C, WAI,
HTML, XHTML, etc.) y, supongamos, que tendré que emplear unos cuan-
tos más. El problema está cuando no todo el mundo entiende los acrónimos
que se emplean, y son tantos que es bien difícil que conozcamos todos.
Una técnica clásica para resolver este problema es colocar en el pro-
pio contenido y junto al acrónimo su desarrollo completo. Por ejemplo:
W3C (World Wide Web Consortium). Pero si en un mismo texto tenemos
que repetir mucho este acrónimo se volvería muy farragoso colocar conti-
nuamente el texto entre paréntesis. Por ese motivo, se suele hacer la ex-
tensión del acrónimo la primera vez que aparece, dejando al lector la tarea
de que lo interprete en el resto.
En nuestras páginas web tenemos la posibilidad de dar esa informa-
ción mediante la etiqueta <acronym>. Si se coloca el cursor sobre los
acrónimos convenientemente etiquetado, aparece una «tooltip» [cuadro
emergente] con el contenido del título que le hemos dado a nuestro
acrónimo, que debe ser el texto extendido del mismo.
La forma de aplicar la etiqueta <acronym> es sencilla. Veamos cómo
lo haríamos para el acrónimo W3C:
<acronym title= "World Wide Web Consotium" lang=

"en">W3C</acronym>
Veamos algunos detalles. La etiqueta lleva dos atributos: «title», con el

que extendemos el texto, y «lang», ya que en este caso al estar en inglés
tenemos que avisar de ello a los lectores de pantalla y navegadores por
voz. Este segundo atributo no lo colocaremos cuando la extensión del
acrónimo esté en el mismo idioma que usamos para el resto del contenido.
164

En algunos navegadores, como Mozilla y Firefox, la apariencia visual
de los acrónimos en pantalla se adereza con una línea punteada de subra-
yado. Si queremos extender esta posibilidad al resto de navegadores, ya
que ésta es una buena opción para informar al visitante de que existe una
extensión para el acrónimo, podemos hacerlo en la hoja de estilo del si-
guiente modo:
acronym {
border-bottom: 1px dotted #000000;
}
Para cerrar este »post» comentaremos que existe otra etiqueta relati-
va a las abreviaturas: <abbr>. Existe una constante discusión sobre qué
es acrónimo y qué es abreviatura. Es evidente que lo mejor es etiquetar
cada cosa con lo que procede. Pero optamos por una solución más prác-
tica: como ninguna de las versiones del navegador más utilizado (IExplorer)
nos muestra una «tooltip» al colocarnos sobre un texto etiquetado con
<abbr>, nos decantamos por recomendar el uso de <acronym>.
165

Paso 13
Tablas accesibles
No es muy habitual encontrar tablas en las bitácoras. La única excepción

probablemente sea las que se utilizan para insertar un calendario. En todo
caso, para saber hacerlas correctamente vamos a dar tres instrucciones
que será preciso tener en cuenta.
Una aclaración previa. Vamos a hablar de tablas de datos y no de
tablas utilizadas para maquetar (que ya sabemos que no están recomen-
dadas y sólo se aceptan si, al alinear su contenido, éste es comprensible).
Nos puede ser útil el ejemplo de una hoja de calendario para las no-
ciones que vamos a explicar.
En primer lugar, hay que dar un título o subtítulo real a nuestra
tabla mediante la etiqueta <caption>.
En muchas ocasiones nos encontramos un supuesto título de la tabla
pero que realmente no es más una celda más de la tabla. El código fuente
que nos encontraríamos sería algo así:
<table border="1" width="30%">

<tr>
<td colspan="7" align="center">Junio 2005</td>
<tr>
<td align="center">Lu</td>
...
Lo que debemos hacer es sustituir esa primara línea

<tr> con el "falso" título por otra que contenga la
etiqueta <caption> del siguiente modo:
<table border="1" width="30%">

<caption>Junio 2005</caption>
<tr>
166

...
De esta forma los lectores de pantalla y ciertos navegadores sólo tex-

to, como Lynx, mostrarán el título real de la tabla como lo que es, infor-
mando al usuario de que no es un dato más en la tabla.
La segunda cuestión a tener en cuenta es proporcionar un resumen
para las tablas. Esta tarea se realiza mediante el atributo «summary» de
la etiqueta <table>. El uso de este atributo proporciona información que es
leída por los lectores de pantalla y navegadores por voz, de tal manera
que al usuario le puede llegar información previa del contenido de nuestra
tabla y de los datos relevantes que contiene. La forma de usarla, siguiendo
con el ejemplo anterior, es:
<table border="1" width="30%" summary="Calendario

mensual con vículos a los posts de cada día">
<tr>
...
Es importante que el texto del atributo «summary» sea lo más breve y

explicativo posible. No tratemos de informar al usuario, mediante este atri-
buto, del formato de la tabla (por ejemplo, «esta tabla tiene seis líneas y
siete columnas»). Esa información ya se la da el lector de pantalla. Debe-
mos informar del propósito de la misma, para qué sirve, y sobre el conte-
nido, al menos lo más destacado. En nuestro ejemplo, la tabla es un ca-
lendario mensual y en su contenido se puede encontrar el enlace a los
«posts» diarios de nuestra bitácora.
La tercera cosa que debemos hacer para que nuestra tabla sea acce-
sible es utilizar encabezamientos apropiados. Esto se consigue utilizan-
do la etiqueta <th>, en lugar de la etiqueta <td>, donde proceda. Lo prime-
ro que tenemos que tener claro es cuales son los encabezados en nuestra
tabla. Siguiendo con el ejemplo que venimos usando, en el caso de una
hora mensual de calendario está claro que los encabezados serán los nom-
bres de los días de la semana, que están en la primera línea de datos.
167

Extendemos algo más el código fuente que hemos venido usando y una
tabla correctamente etiquetada nos quedaría así:
<table border="1" width="30%" summary="Calendario

mensual con vículos a los posts de cada día">
<tr>
<th abbr="Lunes">Lu</th>
<th abbr="Martes">Ma</th>
<th abbr="Miércoles">Mi</th>
<th abbr="Jueves">Ju</th>
<th abbr="Viernes">Vi</th>
<th abbr="Sábado">Sa</th>
<th abbr="Domingo">Do</th>
</tr>
...
Hemos cambiando la etiqueta y también hemos quitado la alineación

central que le dábamos, porque el formato de <th> ya centra el texto en la
celda y si queremos proporcionarle alguna característica de estilo lo debe-
remos declarar en nuestra hoja de estilo. También hemos incluido el atribu-
to »abbr», que en este caso sí procede, ya que queremos que sea leído
por los lectores de pantalla y navegadores por voz, pero no necesitamos
que se muestre visualmente.
Para tablas más complejas habría que hacer otras cosas. Pero lo visto
hasta aquí sirve para la mayoría de las tablas simples que solemos incluir
en nuestras páginas web.
168

Paso 14
Usar listas reales
Las listas, en el código HTML, tienen sus propias etiquetas para marcarlas.
Usamos la etiqueta <ul> para las listas aleatorias (ésas que aparecen con
bolitas) y <ol> para las ordenadas (que aparecen con números o letras
consecutivos). Su apariencia puede resultarnos sosa o aburrida y quera-
mos darle un «toque de diseño». Entonces pensamos sustituir esos feos
bolitos que aparecen en nuestra lista con el menú de navegación por algo
más atractivo, por ejemplo, un pequeño trébol. Nos olvidamos del marca-
do correcto y hacemos algo así:
<img scr="/imagenes/trebol.jpg" width="C8" height="8"

alt="*2><a href=2principal.html2 title="Página
principal de la bitácora">Principal</a>< /br>
<img scr="/imagenes/trebol.jpg" width="8" height="8"
alt="*"><a href="contenidos.html" title="Tabla de
contenidos de la bitácora">Contenidos</a>< /br>
<img scr="/imagenes/trebol.jpg" width="8" height="8"
alt="*"><a href="hoy.html" title="El artículo del
día">Lo último</a>< /br>
Podemos preguntarnos si algo está mal en este código. Tiene atributo

«alt» (del que más adelante hablaremos) para la imagen, tiene el atributo
«title» para el vínculo y en principio parece que está todo correcto. Técni-
camente sí, pero semánticamente no. El usuario visual puede que lo perci-
ba como una lista aleatoria, pero los lectores de pantalla no la interpretan
como tal, porque no lo es. Sería demasiado osado decir que esto la hace
inaccesible, pero sí podemos afirmar que se puede hacer mucho mejor,
ajustándose a los criterios semánticos, y, me atrevería a decir, que de for-
ma mucho más sencilla.
169

Veamos cómo hacerla aprovechando las características de la hoja de
estilo. Lo primero que tenemos que definir es el estilo que le vamos a dar:
queremos que aparezcan unos pequeños tréboles en lugar de los sosos
puntos que aparecen por defecto en este tipo de listas. Vamos a definir un
estilo para nuestra lista del menú en la hoja de estilo:
ul.menu {
list-style: url(/imagenes/trebol.jpg) disc;
}
A continuación, ya podremos escribir nuestra lista usando marcadores

de lista apropiados:
<ul class="menu">
<li><a href="principal.html" title="Página principal
de la bitácora">Principal</a></li>
<li><a href="contenidos.html" title="Tabla de conte-
nidos de la bitácora">Contenidos</a></li>
<li><a href="hoy.html" title="El artículo del
día">Lo último</a></li>
</ul>
Los resultados que obtendremos son:
• Los navegadores modernos mostrarán la imagen del trébol como viñetas

de lista.
• Los navegadores más antiguos (por ejemplo, el clásico Netscape 4) y
los que tengan las imágenes deshabilitadas mostrarán la lista con las
viñetas negras.
• Los navegadores sólo texto ignorarán la hoja de estilo y mostrarán la
lista como tengan definido por defecto (normalmente con viñetas en
forma de asterisco).
• Los lectores de pantalla y navegadores por voz interpretarán de forma
semánticamente correcta que se encuentran ante una lista y así se lo
dirán al visitante.
Pero lo que queremos es hacer una lista donde no se vean las viñetas
y el texto esté alineado a la izquierda. Pues no hay problema. No tenemos
170

que tocar el código fuente de la lista. Sólo tenemos que dar unos retoques
a las características de la lista en la hoja de estilo para hacer desaparecer
la viñeta y alinear el texto a la derecha. Del siguiente modo:
ul.menu {
list-style: none;
text-align: right;
}
De igual manera, podremos dar cualquier otro estilo a la apariencia de

nuestra lista, sin tener que tocar el código fuente y sólo añadiendo o modi-
ficando características de la hoja de estilo. Fácil, bonito y, sobre todo, apro-
piado.
171

Paso 15
Equivalente textual para imágenes
Ha llegado el momento de hablar del atributo "alt". Probablemente éste

sea el elemento más conocido cuando se habla de accesibilidad en la web.
Pero no por conocido es menos necesario explicar su uso y, sobre todo, su
correcto uso.
Sin este atributo, las personas que utilizan navegadores sólo texto, lec-
tores de pantalla o navegadores por voz y todos aquellos que, por una u
otra razón, no tienen habilitada la descarga de imágenes, se quedarán sin
conocer su contenido y utilidad. Es, sin dudarlo, el elemento de accesibili-
dad que afecta a mayor número de personas y, por lo tanto, se merece
una atención relevante.
Vamos, en primer lugar, a ver cómo se utiliza el atributo "alt" para
las imágenes dentro de la etiqueta <img>.
Es primordial saber qué función tiene este atributo: pretende trasmitir
el contenido y la función de la imagen, cuando ésta no puede llegar al
usuario de forma visual. Responde por tanto a dos preguntas: «¿Qué es?
y ¿para qué sirve?».
Como siempre, tomaremos un ejemplo para saber cómo hacerlo de
forma correcta. Supongamos que en nuestra bitácora queremos insertar
una foto del autor que sirva de enlace a una página con un resumen
curricular de su trayectoria profesional. Si nos limitamos a colocar en el
sitio elegido la referencia al archivo de imagen y le colocamos un enlace
obtendremos algo así:
<a href="http://autor.htm">
<img src=http://../imagenes/foto.jpg />
</a>
Si lo dejamos con esa codificación habremos dejado fuera a todos

aquellos que relacionábamos al comienzo. Tenemos que modificar el códi-
172

go para que nos permita hacerlo accesible para todos. Recordemos qué y
para qué está la imagen: es la foto del autor y sirve para llevarnos a otra
página donde podemos conocer más sobre él. Eso es lo que debemos
transmitir en el atributo "alt" y lo tenemos que hacer de la manera más
breve y clara que podamos. Ésta sería una buena forma de hacerlo:
<a href="http://autor.htm">
<img src="http://../imagenes/foto.jpg" alt="Foto del
autor que enlaza con un resumen de su currículum"
title="Conoce al autor de esta bitácora" />
</a>
Hemos añadido dos cosas:
• Lo más importante ahora, hemos colocado el atributo "alt" en la eti-

queta <img> informando a los que no vean la imagen de qué es y para
qué sirve.
• También hemos colocado el atributo "title" para proporcionar infor-
mación adicional de forma visual, como ya explicamos en el paso 9.
Al colocar el texto alternativo para las imágenes debemos tener en

cuenta algunas cosas:
• No podemos utilizar marcadores de código en el texto alternativo, sólo

texto plano y caracteres especiales. Por ejemplo, no podemos intentar
dar énfasis a parte del texto alternativo del siguiente modo: alt="Foto
del autor que <em>enlaza</em> con el resumen de su
currículum". Las etiquetas dentro del atributo se leerán como texto
plano.
• No debemos poner como texto alternativo el nombre del archivo de
imagen. Por ejemplo, alt="foto.jpg".
• Algunas herramientas de edición de páginas web colocan un texto al-
ternativo por defecto a las imágenes para que éste sea sustituido por
uno correcto. Por ejemplo, no dejemos un texto alternativo del tipo
alt="Texto alternativo".
• No utilices como texto alternativo, cuando la imagen sirva como enlace,
un texto que ya desaconsejamos para los vínculos. Por ejemplo, no
pongamos nunca alt="¡Pinche aquí!".
173

• No nos pasemos de listos y hagamos algo tan sin sentido como este
ejemplo que vi en una página web: alt="Activar las imágenes".
Esto es algo así como si una persona ciega nos preguntara la hora y
mostrándoles nuestro reloj le dijéramos: «¡Mírala tú!».
174

Paso 16
Atributo «alt» vacío
En determinadas ocasiones, los diseñadores de páginas web utilizamos

las imágenes como meros recursos estéticos o para dar formato a la apa-
riencia de nuestra página. En esos casos no procede utilizar el atributo
"alt" de forma activa para los lectores de pantalla, para los navegadores
sólo texto o para quienes tienen deshabilitadas las imágenes. Pero tampo-
co podemos ir colocando imágenes en nuestra página que, por defecto,
dichos dispositivos lean diciendo algo así como «imagen» o aparezca este
texto en pantalla.
¿Qué podemos hacer para solucionarlo? Poner un atributo «alt» vacío,
y es tan sencillo como colocarlo dentro de la etiqueta <img>, pero sin po-
ner texto entre las comillas. Sería algo así:
<img src="http://ImagenEspaciadora.jpg" alt="">
Los lectores de pantalla reconocerán el atributo y leerán lo que contie-

ne: nada. En caso de no encontrar el atributo dirían «imagen» o leerían la
dirección del archivo que la contiene, según el caso.
Algunos navegadores sólo texto también reconocerán el atributo y
mostrarán en pantalla lo que contiene: nada. Otros mostrarán en cualquier
caso la palabra «imagen», porque siempre lo hacen, pongamos o no texto
alternativo. Hay gente que opina que para estos casos sería mejor poner
un texto alternativo del tipo «imagen decorativa» o «imagen espaciadora»,
pero eso «ensuciaría» mucho la lectura de otros navegadores. Demos un
voto de confianza a nuestros visitantes con este tipo de navegadores y, si
han visto que utilizamos correctamente el etiquetado de las imágenes en el
resto de la página, deberán suponer que esta imagen no trata de trasmitir
contenido.
175

Las personas que utilizan navegadores visuales y tienen deshabilitada
la carga de imágenes, por el motivo que sea, siempre verán el cuadro de
imagen que su navegador muestre por defecto y éste no tendrá texto alter-
nativo. Igual que en el caso anterior, tengamos fe en la capacidad de nues-
tros visitantes y hagamos uso del "alt" vacío.
Principalmente, deberemos usar el "alt" vacío:
• Cuando utilizamos imágenes decorativas, como ésas que redondean

las esquinas de los fondos de texto.
• Cuando utilizamos imágenes para separar texto u otras imágenes, aun-
que éste sea un artificio que no es recomendable y que podemos sus-
tituir por un buen diseño de bloques mediante la hoja de estilo.
• En general, cuando la imagen que colocamos no pretenda transmitir
contenido.
Es muy importante recordar que lo correcto para el "alt" vacío es

colocar las comillas seguidas (alt="") y no dejando un espacio entre ellas
(alt=""), ya que, entonces, los lectores de pantalla leerán «espacio».
Para las imágenes de fondo que colocamos dentro de etiquetas como
<body> o <td>, no precisan de texto alternativo, ni siquiera mediante el
«alt» vacío. Estas imágenes son meramente decorativas y son ignoradas
tanto por lectores de pantalla como por navegadores sólo texto.
176

Paso 17
Mapas de imagen accesibles
Es sorprendente la cantidad de sitios donde podemos encontrar mapas de

imagen. Muchos desarrolladores de sitios web piensan que colocar uno de
estos mapas de imagen es garantía de que la apariencia que ellos quieren
dar a su web llega al visitante tal como ellos la concibieron. Esto puede ser
cierto para un gran número de usuarios de la web que utilizan el navegador
más difundido en su última versión. Pero no es válido para todos. El espí-
ritu de la web va en contra de este rígido pensamiento. Su intención apun-
ta más hacia el control por parte del usuarios de los contenidos que otros
han colocado en internet.
Tampoco sería correcto renunciar a una de las posibilidades que nos
ofrece el diseño de páginas web. Lo importante es hacerlo bien y eso es lo
que vamos a ver ahora.
La primera norma es crear mapas de imagen del lado del usuario
(del cliente, como gusta decir en ciertos ámbitos). Deberemos hacerlo con
el atributo "usemap" (que define en la imagen que el mapa es controlado
por el dispositivo del usuario) y no con "ismap" (que lo define como con-
trolado por el servidor). Esto debe ser así para que la distinta manera de
presentar la imagen que tienen los navegadores sea la que defina el área
de la imagen que dispondrá de un vínculo y que sea el servidor quien
defina dichas coordenadas de forma absoluta sin conocer el tipo de
navegador y resolución que está empleando el visitante. Si el servidor, por
ejemplo, piensa que el usuario utiliza una resolución de 800 x 600 pixels,
pero éste la utiliza mayor o menor, puede estar definiendo el área sensible
con el vínculo fuera de la imagen que lo presenta o en un lugar distinto,
con lo que puede provocar graves equivocaciones.
La segunda cuestión es dar alternativas textuales tanto a la imagen
de la que haremos el mapa, como a cada una de las zonas sensibles
que éste contenga. Veamos cómo se hace con un ejemplo:
177

Supongamos que, por la razón que sea, queremos colocar como pie
de nuestra bitácora y en todas sus páginas un mapa de imagen que sirva
para contener los vínculos de navegación principales de nuestra bitácora.
Blogger nos permite hacer esto, ya que podemos colocar una imagen y
definir áreas o zonas sensibles que sirvan como vínculos (aunque lo ten-
dremos que hacer mediante el editor HTML, insertando manualmente el
código fuente). Por hacerlo sencillo, supongamos que en la imagen colo-
camos tres zonas sensibles para enlazar con la página principal de la bitá-
cora, con la que contiene el currículo del autor y con otra que tiene la tabla
de contenidos ordenados por temas. En principio podríamos tener un códi-
go fuente similar a éste (recordemos que siempre se utilizará un mapa de
imagen del lado del usuario):
<img src="MiMapa.jpg" width="500" height="200"

usemap="#map">
<map name="Map">
<area shape="rect" coords="203,114,258,129"
href="principal.html">
href="autor.html">
href="contenidos.html2>
</map>
Para hacer nuestro mapa accesible tendremos que colocar atributo

"alt" tanto a la imagen completa, como a cada una de las zonas sensi-
bles definidas dentro del mismo mediante la etiqueta <area>. Tendría que
quedarnos algo así:
<img src:"MiMapa.jpg" width="500" height="200"

usemap="#map" alt="Navegación por mi bitácora">
<map name="Map">
href="principal.html" alt="Página principal">
href="autor.html" alt="Conoce al autor">
178

href="contenidos.html" alt="Tabla de contenidos">
</map>
Es algo relativamente sencillo y que en herramientas de diseño, como

Dreamweaver de Macromedia, se puede hacer de forma interactiva en el
inspector de preferencias.
Todas las reglas para escribir un buen texto alternativo para las imáge-
nes, como vimos en el paso 15, son aplicables a los mapas de imagen.
También se puede añadir un title="" a la imagen principal y a cada
área para eliminar el «toolpip» [cuadro emergente] en los navegadores
visuales.
Una última advertencia. Los navegadores sólo texto no son capaces
de mostrar los textos alternativos de las zonas sensibles de un mapa de
imagen. La única posibilidad de hacerlo accesible es proporcionar un lista-
do de los enlaces del mapa de imagen en forma textual anexo a éste.
Y, ¿entonces para qué hago el mapa de imagen si al final tengo que
poner una lista de enlaces? Ése es uno de los problemas de hacer un
mapa de imagen. Es posible que la mejor opción sea no ponerlo y buscar
una alternativa vistosa y más accesible.
179

Paso 18
Líneas horizontales
Vamos a poner una línea marcar la división entre los «post». Las líneas
horizontales, marcadas con la etiqueta <hr>, pueden resultar sosas y abu-
rridas, así que, en su lugar queremos colocar una imagen. Eso funciona y
puede ser hecho accesible fácilmente añadiendo el atributo "alt" ade-
cuado.
Pero si queremos respetar la semántica correcta podemos utilizar las
características de la hoja de estilo para realizarlo. De esa manera, con los
nuevos navegadores se mostrará nuestra imagen decorativa utilizada como
línea horizontal. Los navegadores más antiguos y los navegadores sólo
texto ignorarán el CSS y sólo mostrarán una línea horizontal en su estilo
propio.
Si nos limitamos a poner una imagen en sustitución de la línea horizon-
tal, será tan sencillo como colocar el código siguiente:
<img src="/imagenes/LineaDecorativa.jpg" alt="—"

title="">
En el atributo "alt" no hace falta poner 80 o 90 guiones. Basta con

colocar 2 o 3 y será suficiente. Tengamos en cuenta que el lector de pan-
talla leerá para cada guión la palabra «guión». ¿No querremos que el visi-
tante pase un minuto oyendo «guión, guión, guión...?
Como ya dijimos, esta solución no plantea problemas de accesibilidad,
pero atenta contra la semántica propia del lenguaje de marcado de
hipertexto (HTML). Así que la solución más correcta será vía hoja de estilo.
Como el soporte de los navegadores a las etiquetas <hr> es extraño,
usaremos una etiqueta <div> sencilla para mostrar la imagen. En la hoja
de estilo colocaremos el siguiente código:
180

div.hr {display:none}
/*/*/a{}
div.hr{
display: block;
height: 25 px;
background-image: url(/imagenes/
LinedaDecorativa.jpg);
background-repeat: no-repeat;
background-position: center center;
margin: 1em 0 1em 0;
}
hr {display: none}
/* */
Donde la altura (heigth) debe ser la de la imagen que vamos a colo-

car como divisor y en background-image colocaremos la dirección donde
se ubica.
Con esto hecho, ya podemos colocar nuestra línea decorativa en el
lugar oportuno del código fuente poniendo:
<div class="hr"></div><hr />
Los resultados serán:
• Todos los navegadores visuales modernos mostrarán la imagen en lu-

gar de la línea horizontal plana normal.
• Algunos navegadores antiguos, como Nestcape 4, mostrarán una línea
horizontal normal.
• Los navegadores sólo texto siempre ignoran la hoja de estilo, por lo
que mostrarán una regla horizontal formada por guiones normales o de
subrayado.
181

Paso 19
Tamaños de fuente relativos
Aunque las páginas web cada vez contienen más imágenes, animaciones y
otros contenidos multimedia, su contenido principal sigue siendo las palabras
(noticias, artículos, opiniones, pensamientos, etc.). Con la permanente pre-
tensión de controlar la presentación de los contenidos, algunos diseñadores
se empeñan en definir el tamaño de la fuente (carácter o letra) con valores
absolutos, tales como puntos o pixels. Al hacer esto así, están provocando
problemas para la visualización y correcta lectura del contenido para aque-
llos que aumentan el tamaño de la fuente con su navegador. Al presentar un
tamaño absoluto, el navegador no es capaz de agrandar la fuente y siempre
la muestra con el tamaño definido por el autor.
Como no queremos que esas personas se queden sin poder acceder
a nuestros contenidos, tendremos que presentar la fuente con valores rela-
tivos, tales como unidades em, porcentaje o palabras clave (este último
realmente es un valor absoluto pero con un comportamiento flexible para
su interpretación por el navegador). Esto facilita la flexibilidad necesaria al
navegador para modificar el tamaño de la fuente y respeta la proporción
entre los distintos tamaños que utilizamos para destacar o diferenciar cier-
tos textos.
Se han escrito muchas reglas para explicar cómo hacer un texto con
tamaño de fuente relativo que trabaje correctamente con todos los
navegadores visuales (recordamos que esta característica de accesibilidad
es indiferente para los navegadores sólo texto —que siempre lo mostrarán
con el mismo tamaño— y para los lectores de pantalla que se limitan a leer
y presentar el contenido de forma oral). Podemos recomendar la lectura
de uno de los capítulos del texto de Mark Pilgrim «Dive into accessibity», el
del día 26 referido a «Usar tamaños de fuente relativos».
Mi particular experiencia me lleva a decantarme por el uso de porcen-
tajes al definir los tamaños de fuente en la hoja de estilos. Pero hay que
182

tener mucho cuidado y hacer muchas pruebas para ver que los resultados
de la aplicación de sucesivas reducción en bloques de contenido anidados
en otros no provoque una reducción de tal magnitud que haga ilegible el
texto. Señalamos que si el tamaño de fuente definido para el cuerpo gene-
ral de la página es del 90% y dentro de este bloque definimos otro, por
ejemplo para el tamaño de las fuentes en los «posts» del 90%, el resulta-
do será que la letra se mostrará al 81% (el 90% de 90%). Además, para
los navegadores más antiguos (aunque de éstos queden ya muy pocos
activos) este tipo de aplicación de porcentajes puede producir algunos efec-
tos muy poco deseables.
Blogger utiliza una curiosa mezcla entre palabras clave (que puede
tomar los valores xx-small, x-small, small, medium, large, x-large y xx-large)
y porcentajes que parece dar un buen resultado.
183

Paso 20
Encabezados correctos
Una página de una bitácora tiene, como la mayoría de los documentos

escritos, un esquema por niveles que podríamos describir así:
1. El nivel superior será el propio título de la bitácora.

2. El segundo nivel sería cada uno de los días en los que colocamos
«posts». Por ejemplo: «Martes, 7 de junio de 2006».
3. El tercer nivel lo ocuparía el título de cada uno de los «post» de cada
día.
4. En el cuarto nivel estaría la sección de «comentarios» para cada «post».
Cada uno de estos niveles responde a un nivel de encabezado en la

codificación HTML (existen hasta 6 niveles) que se marcan mediante las
etiquetas <h1>, <h2>, <h3> y <h4>.
El correcto uso de estas etiquetas facilita la navegación mediante
lectores de pantalla (que, en el caso de JAWS, tiene la posibilidad de
leer la relación de encabezados si se pulsa INSERT+F6 o navegar entre
encabezados con CONTROL+INSERT+INTRO). También el navegador
Opera nos permite saltar al siguiente encabezado pulsando la tecla «S»
y retroceder al anterior con la tecla «W». Los buscadores, como Google,
son capaces de indexar el contenido de nuestras páginas localizando los
encabezados de ella. Por eso es importante el uso correcto de estos
encabezados.
No es extraño encontrar páginas donde sus títulos y los de las seccio-
nes que la componen han sido definidos dando un simple formato al texto
y prescindiendo del correcto marcado con la etiqueta de encabezado. Esto
atenta contra la semántica de la codificación HTML y provoca inconvenien-
tes de navegación para ciertos usuarios que supondrán barreras al no en-
contrar la correspondiente etiqueta de encabezado.
184

Otras páginas utilizan el formato que proporciona la etiqueta de enca-
bezado para aumentar el tamaño de un texto, que realmente no es un
encabezado.
Debemos, por lo tanto, utilizar las etiquetas de encabezado y hacerlo
de forma correcta.
En Blogger, la plantilla principal define en su hoja de estilo la forma en
que se presentarán los encabezados y en el cuerpo del contenido a qué
textos se aplican.
185

Paso 21
Verificar la accesibilidad
Para considerar correctamente finalizado un trabajo, hay que verificar sus

resultados. Eso es lo que debemos hacer en este paso. No se trata de
hacer una «auditoría de accesibilidad» exhaustiva y profesional. Recomen-
damos comprobar una serie de pasos, rápidos y sencillos, para saber si
hemos conseguido el objetivo de hacer una bitácora accesible. El análisis
que proponemos no sirve para colocarse medallas ni obtener certificados.
Su pretensión es que aprendamos algo sobre verificación de la accesibili-
dad y nos acostumbremos a usarla en tus trabajos futuros en la web, an-
tes de colocar los contenidos a disposición de todos.
Veamos los pasos a dar:
• El primero de ellos será verificar si el código fuente de nuestra bitácora

se ajusta a las recomendaciones de W3C sobre HTML. En la dirección
http://validator.w3.org se puede encontrar la herramienta para realizarlo.
Basta con que pongamos la dirección web donde se ubica tu bitácora y,
de forma automática, el validador te presentará los resultados. Este pro-
cedimiento es completamente fiable, ya que la verificación del código
puede ser completamente realizada por una herramienta automática. Si
todo está bien, ¡felicidades! Si te devuelve una página en la que te muestra
los errores encontrados, debemos revisar el código y modificar con las
recomendaciones que ellos mismos nos proporcionan. La validación del
código HTML hay que hacerla para cada página.
• El siguiente paso será verificar el código de nuestra hoja de estilo, tam-
bién ajustándose a las recomendaciones de W3C para CSS. Para ello
disponemos de una herramienta automática que podemos encontrar en:
http://jigsaw.w3.org/css-validator/. Escribimos la dirección web donde se
encuentra la hoja de estilo, el validador realiza el análisis de forma auto-
mática. El código de la hoja de estilo es analizado tanto si ésta se en-
186

cuentra en un archivo propio (del tipo: estilo.css) como si está dentro
de una página web normal (del tipo: pagina.html). En este último caso,
el validador localiza el trozo de código que corresponde la hoja de estilo
(si está correctamente marcado) y lo analiza. De forma automática y
completamente fiable, presentará los resultados. Si la respuesta obtenida
del validador es que todo está bien, ¡felicidades! Si encuentra errores
nos los comunicará y deberemos revisarlos y modificarlos para adecuarlos
al estándar. Normalmente habremos utilizado una sola hoja de estilo, por
lo que sólo tendremos que hacer un análisis. Si son varias las aplicadas,
tendremos que realizar un análisis para cada una de ellas. Este validador
está, al menos en parte, «castellanizado», lo que puede hacer más fácil
su uso.
• Los dos pasos anteriores, aunque no lo parezca, tienen mucho que ver
con accesibilidad. Para hacer accesible una web, lo primero es hacerla
de forma correcta y adecuada a los estándares. En cuanto nos salga-
mos de éstos, posiblemente comencemos a poner en problemas a al-
gunas personas.
En este tercer paso vamos a hacer un análisis automático de los criterios
de accesibilidad promovidos por W3C en sus WCAG 1.0, elaboradas
por grupo WAI (dispones de una traducción al castellano [español] en:
http://usuarios.discapnet.es/disweb2000/WCAG2003/wcag10/WAI-
WEBCONTENT-19990505_es.html). Para ello vamos a utilizar la herra-
mienta desarrollada por la Fundación CTIC y conocida con el nombre
TAW (Test de Accesibilidad Web) que puedes encontrar en http://
www.tawdis.net/. El análisis automático de accesibilidad se puede reali-
zar en línea o se puede descargar, de forma gratuita, la herramienta e
instalarla en el ordenador. Recomendamos esta segunda opción porque,
entre otras ventajas, permite realizar el análisis de todas las páginas de
dominio de una sola vez, mientras que en línea tendríamos que hacerlo
página a página. Una observación importante es que el análisis de la
accesibilidad no se puede hacer al 100% de forma automática. Hay
muchos criterios cuya revisión tenemos que realizarla de forma personal
o manual. En cualquier caso, el análisis automático nos permite conocer
si hemos cometido errores que se pueden detectar de esta forma y nos
recomienda la verificación de otros criterios de forma personal. Con los
resultados que nos ofrece esta herramienta podemos saber si, en princi-
187

pio, todo está correcto en materia de criterios de accesibilidad (si es así,
¡felicidades!) o si debemos revisar y modificar algo en nuestras páginas.
Al estar completamente en castellano [español] su uso es más fácil y
comprensible.
• En este cuarto paso haremos un análisis del contraste de color del
sitio. Como ya vimos en el paso 7, al hablar del uso de los colores,
W3C ha promovido un algoritmo, muy exigente, para verificar el con-
traste de colores. Disponemos de una herramienta para hacer este
análisis, cuyo programa en castellano [español] podemos descargar gra-
tuitamente en esta dirección: http://www.nils.org.au/ais/web/resources/
contrast_analyser/versions/es/. El manejo de esta herramienta en muy
sencillo e intuitivo. Verifica que todos los colores que hemos empleado
superan los valores mínimos. Observamos que la herramienta ofrece
unos valores para la «visión normal» y otros para distintas «cegueras
de color». Debemos procurar que todos sean positivos para todos los
casos.
• Una última prueba es visualizar la bitácora quitando la hoja de estilo. La
forma más rápida y fácil es utilizando la barra de herramientas de ac-
cesibilidad desarrollada por el equipo de AIS que, en su versión
«castellanizada» (realizada por Technosite [Fundosa Teleservicios]), po-
demos descargarla gratuitamente desde:
http://www.technosite.es/software.asp.
Esta barra de herramientas sólo trabaja con el navegador IExplorer.
Para desactivar la hoja de estilo, tenemos que hacerlo desde la opción
etiquetada como «IE». Verifica que todo el contenido de las páginas de
tu bitácora se comunica correctamente sin la hoja de estilos. Si es así,
¡felicidades! En caso contrario, revisaremos y modificaremos lo que
corresponda.
Podemos hacer alguna prueba más, complementaria como:
• Deshabilitar las imágenes en el navegador y comprobar si los textos

alternativos están puestos correctamente y son comprensibles.
• Visitemos la bitácora con un navegador sólo texto o con un simula-
dor como Lynx Viewer y comprobemos como llegará a los usuarios
188

que dispongan de este tipo de navegadores el contenido de la bitá-
cora.
• Con la demo del lector de pantalla JAWS (la versión 5.01 de este pro-
grama en castellano [español] se puede encontrar en: ftp://ftp.once.es/
pub/utt/tiflosoftware/04_Revisor_Jaws/jaws_5.0) escucharemos cómo se
oyen los contenidos de la bitácora.
• Si tenemos alguna versión antigua de navegadores visuales, como
Netscape 4, que es muy peculiar, visitaremos la bitácora con ella para
ver los resultados.
189

190

Anexo
Web recomendadas
• Blogger:
http://www.blogger.com/
• Dive into Accessibility:
http://www.diveintoaccessibility.org/
• Pautas accesibilidad web:
http://usuarios.discapnet.es/disweb2000/WCAG2003/index.htm
• HTML con Clase:
http://html.conclase.com/
• Hojas de Estilo, CSS:
http://www.sidar.org/recur/desdi/mcss/index.php
• Analizador del Contraste de Color:
http://www.nils.org.au/ais/web/resources/contrast_analyser/versions/es/
• Barra de Herramientas de Accesibilidad:
http://www.technosite.es/software.asp
Navegadores
• Lynx:
http://www.fdisk.com/doslynx/lynxport.htm
• Links:
http://links.sourceforge.net/
• Opera:
http://www.opera.com/
191

• JAWS:
ftp://ftp.once.es/pub/utt/tiflosoftware/04_Revisor_Jaws/jaws_5.0
• IBM Home Page Reader:
http://www-3.ibm.com/able/solution_offerings/hpr.html
• Mozilla:
http://www.mozilla.org/
• iCab:
http://www.icab.de/
• Firefox:
http://www.mozilla-europe.org/es/products/firefox/
• MS Internet Explorer:
http://www.microsoft.es/
• Netscape:
http://www.netscape.com/es/
192

Enlaces de interés
(Actualizados a diciembre de 2006)
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/document_accesibilidad.asp
Paginas de Technosite (Fundosa Teleservicios) que ofrecen la traduc-
ción al castellano de las Pautas de Accesibilidad al Contenido en la
Web 1.0 y documentos relacionados (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).
193

• 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://accesibleweb.com.ar/default.htm
La argentina Andrea Stiparo mantiene este sitio con información sobre
accesibilidad web (castellano).
• 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://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).
194

• http://www.jlvelazquez.net/
Otra bitácora que toca los temas de accesibilidad web. Ésta la mantie-
ne José Luis 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.ceyas.es
Consultoría en temas discapacidad y dependencia, incluyendo la acce-
sibilidad web.
• 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.
195

• http://www.funcaragol.org/
Web de la Fundación Manuel Caracol con interesantes recursos
informáticos para personas ciegas y con deficiencia visual.
• 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 Test de Accesibilidad en la Web: Verificador de sitios y páginas,
incluye versión descargable (castellano).
• 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, que incluyen la extensión web Developer
para Firefox, la barra de herramientas de accesibilidad web AIS (caste-
llano) 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).
Carlos
Carlos Egea García
Nombre de
reconocimiento (DN):
Egea
cn=Carlos Egea García,
196 o=Consultores Sociales
García c=ES
Fecha: 2007.11.08 19:23:30
+01'00'

197


Diseño para Todos 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño para Todos 1

Uploaded by

Copyright:

Available Formats

DISEÑO WEB PARA TOD@S I

Carlos Firmado digitalmente por

García Fecha: 2007.11.08 19:22:25

diseño para todos.p65 1 08/11/2007, 12:17

Materiales elaborados por:

SOCIEDAD DEL CONOCIMIENTO

diseño para todos.p65 3 08/11/2007, 12:17

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

© Carlos Egea García

Colaboradores: Juan Carlos Ramiro Iglesias y Alicia Sarabia Sánchez

Coordinadora de la colección: Sara Osuna Acedo

Fotocomposición: Text Gràfic

Impreso en Romanyà/Valls, s.a.

diseño para todos.p65 4 08/11/2007, 12:17

Legislación y otras normas en materia de accesibilidad

diseño para todos.p65 5 08/11/2007, 12:17

Las aplicaciones o agentes de usuario . . . . . . . . . . . . . . . 69

Las pautas de accesibilidad al contenido en la web

diseño para todos.p65 6 08/11/2007, 12:17

Codificación HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

¿Qué es CSS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

diseño para todos.p65 7 08/11/2007, 12:17

Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

diseño para todos.p65 8 08/11/2007, 12:17

En este libro se recogen los materiales relativos a la primera parte

1. «Diseñar para todos», con información general sobre la discapacidad,

diseño para todos.p65 9 08/11/2007, 12:17

Carlos Egea García

diseño para todos.p65 10 08/11/2007, 12:17

DISEÑAR PARA TOD@S

diseño para todos.p65 11 08/11/2007, 12:17

diseño para todos.p65 12 08/11/2007, 12:17

Sin lugar a dudas, los innumerables avances tecnológicos de los últimos

diseño para todos.p65 13 08/11/2007, 12:17

La Organización Mundial de la Salud, a través de la Clasificación Interna-

Condición de salud: «es un término genérico que incluye enfermedad

diseño para todos.p65 14 08/11/2007, 12:17

diseño para todos.p65 15 08/11/2007, 12:17

Esta clasificación parte de un enfoque sustancialmente diferente del

Deficiencia: «toda pérdida o anormalidad de una estructura o función

Como podemos observar, el cambio conceptual entre una y otra clasi-

diseño para todos.p65 16 08/11/2007, 12:17

La diversidad funcional en el ser humano es enorme. Cada uno de noso-

diseño para todos.p65 17 08/11/2007, 12:17

diseño para todos.p65 18 08/11/2007, 12:17

Para algunas personas con limitaciones funcionales (visuales, motoras,

– Posibilidad de manejo o acceso a los elementos físicos que nos

diseño para todos.p65 19 08/11/2007, 12:17

Acceder a las tecnologías digitales a través de los terminales de acceso

Desde los primeros teléfonos móviles hasta ahora se ha producido una

diseño para todos.p65 20 08/11/2007, 12:17

Un caso muy distinto lo constituyen los teléfonos fijos, que incluimos en

diseño para todos.p65 21 08/11/2007, 12:17

Cajeros automáticos y quioscos virtuales

Sin duda, los cajeros automáticos y quioscos virtuales se pueden incluir

Tarjetas con banda magnética o chip

diseño para todos.p65 22 08/11/2007, 12:17

Cuando a principios de los ochenta se empezaron a comercializar en serie

diseño para todos.p65 23 08/11/2007, 12:17

diseño para todos.p65 24 08/11/2007, 12:17

La televisión ha sido durante años el terminal de acceso por excelencia a

El primero lo sufren las personas con discapacidad auditiva que no pue-

diseño para todos.p65 25 08/11/2007, 12:17