Desarrollo de un sitio web corporativo accesible …oa.upm.es/9304/1/PFC_MARIA_PINTO_MARTIN.pdf · UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA Desarrollo de un sitio

UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA

Desarrollo de un sitio web corporativo

accesible usando Drupal Trabajo de Fin de Carrera

Autor: María Pinto Martín

Tutores: José Luis Fuertes Castro

Loïc Martínez Normand

Desarrollo de un sitio web corporativo accesible usando Drupal

[ii]


[iii]

A mis compañeros de trabajo, por su compresión,

a toda la gente de la Fundación,

a mis amigos de la carrera,

pero sobre todo a mis padres y a Rubén,

por su esfuerzo y apoyo incondicional.


[iv]


[v]

Contenido

1. INTRODUCCIÓN ...................................................................................................................................................................... 1

2. ESTADO DE LA CUESTIÓN ................................................................................................................................................. 5

2.1. ¿Qué es la accesibilidad web? .................................................................................................................................. 6

2.2. ¿Por qué es importante la accesibilidad web? ................................................................................................. 6

2.3. Cumplimiento de la accesibilidad web y legislación española ................................................................. 7

2.3.1. LEY 34/2002 ....................................................................................................................................................... 10

2.3.2. LEY 51/2003 ....................................................................................................................................................... 10

2.3.3. Real Decreto 1494/2007 ............................................................................................................................... 11

2.3.4. Ley 49/2007 ........................................................................................................................................................ 14

2.3.5. Ley 56/2007 ........................................................................................................................................................ 14

2.4. Introducción a las WCAG ........................................................................................................................................ 15

2.5. WCAG 2.0: Estructura y contenido ..................................................................................................................... 15

2.5.1. Los principios ..................................................................................................................................................... 16

2.5.2. Las pautas ............................................................................................................................................................. 17

2.5.3. Criterios de conformidad .............................................................................................................................. 22

2.6. Material de soporte para las WCAG 2.0 ............................................................................................................ 22

2.6.1. Documento “Understanding WCAG 2.0” .................................................................................................. 23

2.6.2. Documento “Techniques for WCAG 2.0” ................................................................................................... 23

2.6.3. Guía “How to meet WCAG 2.0” ...................................................................................................................... 24

2.6.4. Sección “Conformance” ................................................................................................................................... 24

2.7. Diferencias entre las WCAG 2.0 y las WCAG 1.0 ........................................................................................... 26

2.8. ¿Qué es la usabilidad web? .................................................................................................................................... 34

2.9. ¿Por qué es importante la usabilidad web? .................................................................................................... 35

2.10. Cómo implementar y medir la usabilidad web .......................................................................................... 36

2.10.1. Arquitectura de la información ................................................................................................................ 37

2.10.2. Diseño centrado en el usuario .................................................................................................................. 39

2.11. Tecnologías para el desarrollo web ................................................................................................................ 48

2.11.1. Lenguajes de programación ...................................................................................................................... 48

2.11.2. Herramientas de gestión de contenidos .............................................................................................. 56

2.11.3. Drupal .................................................................................................................................................................. 61

3. PLANTEAMIENTO DEL PROBLEMA ........................................................................................................................... 71

3.1. Estado actual del sitio web corporativo ........................................................................................................... 71

3.2. Problemas que presenta el sitio web actual ................................................................................................... 78

3.2.1. Resultados de la evaluación heurística del sitio corporativo ........................................................ 79


[vi]

3.2.2. Evaluación de accesibilidad del sitio web .............................................................................................. 82

3.2.3. Fallos de prioridad 1 y posibles soluciones .......................................................................................... 90



3.3. Conclusiones de los fallos ....................................................................................................................................... 92

3.4. Introducción de la Especificación de Requisitos Software ...................................................................... 93

3.4.1. Propósito .............................................................................................................................................................. 93

3.4.2. Ámbito del sistema ........................................................................................................................................... 93

3.4.3. Definiciones ......................................................................................................................................................... 94

3.4.4. Visión general de las siguientes secciones ............................................................................................ 94

3.5. Descripción general (ERS) ..................................................................................................................................... 94

3.5.1. Perspectiva del producto .............................................................................................................................. 95

3.5.2. Funciones del sistema ..................................................................................................................................... 95

3.5.3. Características de los usuarios ................................................................................................................... 97

3.5.4. Restricciones ....................................................................................................................................................... 98

3.5.5. Suposiciones ....................................................................................................................................................... 98

3.5.6. Dependencias ..................................................................................................................................................... 99

3.6. Requisitos específicos .............................................................................................................................................. 99

3.6.1. Requisitos funcionales .................................................................................................................................... 99

R-FUN-1: Búsqueda................................................................................................................................................................. 99

R-FUN-2: Opciones de publicación .................................................................................................................................. 99

R-FUN-3: Temas relacionados ........................................................................................................................................ 100

R-FUN-4: Obtención de estadísticas ............................................................................................................................. 100

R-FUN-5: Envío de consultas ........................................................................................................................................... 100

R-FUN-6: Envío de comentarios de accesibilidad .................................................................................................. 101

R-FUN-7: Alta de usuario ................................................................................................................................................... 101

R-FUN-8: Baja de usuario .................................................................................................................................................. 101

R-FUN-9: Modificación de usuario ................................................................................................................................ 101

R-FUN-10: Consulta de usuarios .................................................................................................................................... 102

R-FUN-11: Login de usuarios .......................................................................................................................................... 102

R-FUN-12: Administración de permisos .................................................................................................................... 102

R-FUN-13: Alta de noticias ............................................................................................................................................... 102

R-FUN-14: Baja de noticia ................................................................................................................................................. 103

R-FUN-15: Modificación de noticia ............................................................................................................................... 103

R-FUN-16: Consulta de noticias...................................................................................................................................... 103

R-FUN-17: Alta de evento .................................................................................................................................................. 104


[vii]

R-FUN-18: Baja de evento ................................................................................................................................................. 105

R-FUN-19: Modificación de un evento ......................................................................................................................... 105

R-FUN-20: Consulta de eventos ...................................................................................................................................... 105

R-FUN-21: Alta de anuncio ............................................................................................................................................... 106

R-FUN-22: Baja de anuncio ............................................................................................................................................... 106

R-FUN-23: Modificación de un anuncio ...................................................................................................................... 106

R-FUN-24: Consulta de anuncios ................................................................................................................................... 107

3.6.2. Requisitos no funcionales .......................................................................................................................... 107

R-NFUN- 1: Interfaz de usuario del gestor ................................................................................................................ 107

R-NFUN- 2: Integridad de la información .................................................................................................................. 107

R-NFUN- 3: Mantenimiento del gestor ........................................................................................................................ 107

R-NFUN- 4: Mantenimiento del sitio ............................................................................................................................ 108

R-NFUN- 5: Seguridad en el login .................................................................................................................................. 108

R-NFUN- 6: Detección de spam ....................................................................................................................................... 108

R-NFUN- 7: Accesibilidad en los contenidos ............................................................................................................. 108

R-NFUN- 8: Navegación del sitio web .......................................................................................................................... 109

R-NFUN- 9: Reproductor de vídeo................................................................................................................................. 109

R-NFUN- 10: Visor de anuncios ...................................................................................................................................... 109

R-NFUN- 11: Características de la página principal .............................................................................................. 110

R-NFUN- 12: Longitud de la página .............................................................................................................................. 110

R-NFUN- 13: Scripts accesibles ....................................................................................................................................... 110

R-NFUN- 14: Enlaces en el sitio web ............................................................................................................................ 111

R-NFUN- 15: Mapa web ...................................................................................................................................................... 111

R-NFUN- 16: Guía de navegación ................................................................................................................................... 111

R-NFUN- 17: Independencia del dispositivo............................................................................................................. 111

R-NFUN- 18: Estándares .................................................................................................................................................... 112

R-NFUN- 19: Organización de los contenidos .......................................................................................................... 112

R-NFUN- 20: Accesibilidad global .................................................................................................................................. 112

4. SOLUCIÓN ............................................................................................................................................................................ 113

4.1. Implementación de R-NFUN-10: Características de la página principal ........................................ 113

4.1.1. Sección “Últimas noticas” ........................................................................................................................... 116

4.1.2. Visor de anuncios ........................................................................................................................................... 116

4.1.3. Barra lateral derecha .................................................................................................................................... 116

4.2. Implementación de R-NFUN- 19: Organización de los contenidos ................................................... 118

4.3. Implementación del R-NFUN- 21: Navegación del sitio web ............................................................... 119

4.4. Implementación del R-FUN-1: Búsqueda ..................................................................................................... 125


[viii]

4.5. Implementación del R-FUN-2: Opciones de publicación ....................................................................... 127

4.6. Implementación del R-FUN-3: Temas relacionados ................................................................................ 128

4.7. Implementación del R-FUN-4: Obtención de estadísticas .................................................................... 130

4.8. Implementación del R-FUN-5: Envío de consultas .................................................................................. 131

4.9. Implementación del R-FUN-6: Envío de comentarios de accesibilidad .......................................... 133

4.10. Implementación de R-FUN-7 y R-FUN-10: Alta, baja, modificación y consulta de usuarios134

4.11. Implementación de R-FUN-11: Login de usuarios................................................................................. 134

4.12. Implementación de R-FUN-12: Administración de permisos .......................................................... 136

4.13. Implementación de R-FUN-17: Alta de evento ....................................................................................... 137

4.13.1. Tipo de evento .............................................................................................................................................. 138

4.13.2. Fotografía ....................................................................................................................................................... 138

4.13.3. Fecha, lugar y horario ............................................................................................................................... 140

4.13.4. Cómo llegar .................................................................................................................................................... 148

4.13.5. Galería fotográfica ...................................................................................................................................... 149

4.13.6. Galería de vídeos ......................................................................................................................................... 153

4.13.7. Documentación ............................................................................................................................................ 156

4.13.8. Información adicional ............................................................................................................................... 157

4.14. Implementación de R-FUN-20 y R-FUN-21: Baja y modificación de eventos ........................... 158

4.15. Implementación de R-FUN-20: Consulta de eventos ........................................................................... 159

4.16. Implementación de R-FUN-13: Alta de noticias ..................................................................................... 160

4.17. Implementación de R-FUN-15 y R-FUN-16: Baja y modificación de noticias ........................... 163

4.18. Implementación del R-FUN-17: Consulta de noticias .......................................................................... 164

4.19. Implementación de R-FUN-21: Alta de anuncio ..................................................................................... 165

4.20. Implementación de R-FUN-22 y R-FUN-23: Baja y modificación de anuncios ......................... 166

4.21. Implementación de R-FUN-24: Consulta de anuncios ......................................................................... 166

4.22. Implementación del R-NFUN- 11: Visor de anuncios .......................................................................... 167

4.23. Implementación del R-FUN-1: Interfaz de usuario del gestor ......................................................... 167

4.24. Implementación del R-NFUN-2: Integridad de la información ........................................................ 168

4.25. Implementación del R-NFUN-3: Mantenimiento del gestor ............................................................. 168

4.26. Implementación del R-NFUN-4: Mantenimiento del sitio .................................................................. 169

4.27. Implementación del R-NFUN-5: Seguridad en el login ........................................................................ 169

4.28. Implementación del R-NFUN-6: Detección de spam ............................................................................ 170

4.29. Implementación del R-NFUN-7: Accesibilidad de los contenidos .................................................. 170

4.30. Implementación del R-NFUN-9: Reproductor de vídeo ...................................................................... 170

4.31. Implementación del R-NFUN- 12: Longitud de la página ................................................................... 175

4.32. Implementación del R-NFUN- 13: Scripts accesibles ........................................................................... 177


[ix]

4.33. Implementación del R-NFUN- 14: Enlaces en el sitio web ................................................................. 181

4.33.1. Identificación del enlace .......................................................................................................................... 182

4.33.2. Nombrado y destino del enlace ............................................................................................................ 183

4.33.3. Propósito de los enlaces ........................................................................................................................... 183

4.34. Implementación del R-NFUN- 15: Mapa web .......................................................................................... 184

4.35. Implementación del R-NFUN- 16: Guía de navegación ....................................................................... 185

4.36. Implementación del R-NFUN- 17: Independencia del dispositivo ................................................. 185

4.37. Implementación del R-NFUN- 18: Estándares ........................................................................................ 187

4.38. Implementación del R-NFUN-20: Accesibilidad global ....................................................................... 188

4.38.1. Resultados de la evaluación de las WCAG 2.0 ................................................................................ 188

4.38.2. Estado final del sitio ................................................................................................................................... 217

4.38.3. Evaluación de accesibilidad según las WCAG 1.0.......................................................................... 220

4.39. Resumen de los módulo de Drupal ............................................................................................................... 220

5. Conclusiones....................................................................................................................................................................... 225

6. Líneas de trabajo futuras .............................................................................................................................................. 227

6.1. Integración de nuevos servicios ....................................................................................................................... 227

6.2. Mantenimiento del sitio ....................................................................................................................................... 229

7. BIBLIOGRAFÍA ................................................................................................................................................................... 231

A. Anexo ..................................................................................................................................................................................... 235

A.1. INTRODUCCIÓN....................................................................................................................................................... 235

A.2. HEURÍSTICAS............................................................................................................................................................ 235

A.3. Evaluación heurística ............................................................................................................................................ 238


1. INTRODUCCIÓN [1]

1. INTRODUCCIÓN

Este Trabajo de Fin de Carrera (TFC) trata sobre el rediseño del sitio web de una

Fundación cuyo sitio actual no cumple con la necesidad principal de la misma, hacer llegar

su trabajo al mayor número de gente posible. Esta situación viene motivada por problemas

tan importantes como la imposibilidad de los buscadores web para indexar los contenidos

o el coste de tiempo que supone subir determinados materiales de sus actividades

culturales a la página, entre otros. De estos y otros problemas se habla en el apartado

planteamiento del problema.

Con la intención de solucionar estos problemas se ha propuesto este Trabajo que diseñará

desde cero el sitio web y cubrirá los tres objetivos básicos propuestos por la Fundación:

Accesible: un sitio web que pueda verse en distintos navegadores, que pueda

posicionarse en buscadores, que pueda llegar a más personas y que cumpla con la

legislación vigente en temas de accesibilidad para personas con discapacidad.

Usable: un sitio web con una interfaz más familiar y fácil de navegar, con el

contenido bien clasificado y relacionado.

Buena gestión de los contenidos: una gestión sencilla de los contenidos para las

personas de la Fundación que trabajen con el sitio web, de forma que se puedan

gestionar los contenidos que se generan en las actividades y que se puedan

publicar en el sitio web.

Para que el lector pueda comprender la importancia del porqué de cada objetivo es

interesante que conozca de qué tratan la accesibilidad, la usabilidad y la gestión de

contenidos.

Para hablar de la accesibilidad hay que tener en cuenta que en estos últimos años Internet

ha crecido considerablemente. Esto se debe a que la web se ha abierto paso entre los

medios de comunicación y se ha convertido en uno de los más importantes. Hoy en día las

grandes empresas venden sus productos a través de una página de Internet, los diarios

tienen su versión digital, las cadenas de televisión tienen sus programas para que se

puedan volver a ver… ¿Quién no compra por Internet? o ¿quién no lee el periódico digital?

Todas las personas tienen derecho a acceder a este tipo de contenidos, en cualquier lugar,

con cualquier dispositivo e independientemente de su diversidad funcional [Romañach et

al, 2005]. Éste es el objetivo de la accesibilidad web.

La accesibilidad web hace referencia al grado en el que cualquier persona puede tener

acceso a una página y a sus contenidos, haciendo uso de los servicios que ésta pueda

prestar, independientemente de sus capacidades sensoriales, físicas e intelectuales o del

contexto de uso (dispositivos, entorno, etc.) en el que se encuentra. La accesibilidad web


[2] María Pinto Martín

trata de que todas las personas puedan acceder en igualdad de condiciones a los

contenidos.

Además, la accesibilidad web también puede beneficiar situaciones concretas de personas,

que independientemente de su diversidad funcional navegan desde su teléfono móvil de

última generación o tienen una conexión lenta y no reciben las imágenes de la página. O

incluso puede beneficiar a personas con diversidad funcional [Palacios et al. 2006]

temporal como la rotura de una mano o un brazo.

Existen unas pautas propuestas por el Consorcio de la Web, que indican qué requisitos

deben cumplir los contenidos web para ser accesibles. Estas pautas son las WCAG (del

inglés, Web Content Accessibility Guidelines). Hay dos versiones, las WCAG 1.0 [W3C, 1998],

que fueron aprobadas en mayo de 1999, y la nueva versión, las WCAG 2.0 [W3C, 2008e],

que han sido aprobadas en diciembre de 2008.

Por otra parte, en España existen leyes que regulan la accesibilidad en la sociedad de la

información. Las dos más relevantes para este trabajo son:

Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la

Información [BOE, 2007a]

Real Decreto 1494/2007 de 12 de noviembre, por el que se aprueba el Reglamento

sobre las condiciones básicas para el acceso de las personas con discapacidad a las

tecnologías, productos y servicios relacionados con la sociedad de la información y

medios de comunicación social. [BOE, 2007b]

Esta última establece como obligatoria, para determinadas empresas u organizaciones las

normas UNE 139803:2004 (internet) [AENOR, 2004] y cita las normas UNE 139801:2003

[AENOR, 2003a] (hardware) y UNE 139802:2003 (software) [AENOR, 2003b].

De estas leyes y normas se habla en el estado de la cuestión donde se comenta de ellas lo

que a este trabajo le compete cumplir de las mismas.

Un ámbito que está muy ligado a la accesibilidad y que establece cierta relación con ésta es

la usabilidad, confundidas en muchas ocasiones e incluso muchos expertos en ambas áreas

consideran que una forma parte de la otra.

La Organización Internacional de Estandarización (ISO) ofrece dos definiciones de

usabilidad. En el documento ISO/IEC 9126 [ISO, 1991] encontramos la siguiente

definición:

"La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser

atractivo para el usuario, en condiciones específicas de uso"

Esta definición hace énfasis en los atributos internos y externos del producto, los cuales

contribuyen a su funcionalidad y eficiencia. La usabilidad depende no sólo del producto


1. INTRODUCCIÓN [3]

sino también del usuario. Por ello, un producto no es en ningún caso intrínsecamente

usable, sólo tendrá la capacidad de ser usado en un contexto particular y por usuarios

particulares. La usabilidad no puede ser valorada estudiando un producto de manera

aislada [Bevan et al., 1994].

En el documento ISO 9241-11 [ISO, 1998] encontramos la siguiente definición:

“Es el grado en que un producto puede ser utilizado por usuarios especificados para lograr objetivos

concretos con eficacia, eficiencia y satisfacción, en un determinado contexto de uso"

Es una definición centrada en el concepto de calidad en el uso, es decir, se refiere a cómo

realiza el usuario tareas específicas en escenarios específicos con efectividad, eficiencia y

satisfacción.

Para el diseño y la evaluación de los sistemas interactivos se han identificado siete

principios de diálogo recogidos en la norma ISO 9241-110, [ISO, 2006].

Adecuación a la tarea: un sistema es adecuado para la tarea cuando ayuda al

usuario a llevarla a término, es decir, cuando la funcionalidad y el diálogo están

basados en las características de la tarea (más que en la tecnología elegida para

realizar la tarea).

Carácter autodescriptivo: un diálogo es autodescriptivo en la medida en que se

hace comprensible en cada una de sus etapas mediante las oportunas

explicaciones dadas al usuario con arreglo a las necesidades de éste, a través de

una retroalimentación adecuada. Conformidad con las expectativas del usuario: un

diálogo se ajusta a las expectativas del usuario si se corresponde con las

necesidades predecibles del usuario y con las convenciones normalmente

aceptadas.

Adecuación al aprendizaje: un diálogo es adecuado para el aprendizaje cuando

ayuda y guía al usuario en el aprendizaje de la utilización del sistema.

Controlable por el usuario: un diálogo es controlable cuando el usuario es capaz de

iniciar y controlar la dirección y el avance de la interacción hasta el punto en el que

se ha alcanzado el objetivo.

Tolerancia a errores: un diálogo es tolerante a errores cuando a pesar de existir un

error evidente en la entrada, puede alcanzarse el resultado sin acción del usuario o

con una mínima corrección.

Personalizable: un diálogo es personalizable cuando los usuarios pueden modificar

la interacción y la presentación de información para adaptarlo a sus capacidades y

necesidades.

Aunque uno de los objetivos del trabajo es conseguir un sitio web con mejores

características de usabilidad que el anterior, este Trabajo está centrado en la accesibilidad.

Al ser dos conceptos tan ligados, es claro que la accesibilidad favorece a la usabilidad y

viceversa. Consiguiendo un sitio web accesible, se obtienen beneficios como: una mejora



de la indexación y localización del sitio en los buscadores, alternativas de acceso a los

contenidos, garantía de legibilidad o lenguaje sencillo y contenidos ilustrados.

Estos son algunos de los muchos beneficios que se obtienen, los cuales también se pueden

lograr con un sitio web usable. Por tanto, se va a partir de la premisa “un sitio accesible es

más usable” y se va a enfocar el diseño desde el punto de vista de la accesibilidad.

Al comienzo de este Trabajo, el sitio web corporativo de la Fundación presentaba grandes

problemas en temas de usabilidad que tienen que ver con la robustez de la información, la

predictibilidad y consistencia de la interfaz y la multiplicidad de vías para realizar una

tarea.

Lo cual lleva al tercer y último objetivo de este proyecto, el almacenamiento correcto de la

información independientemente de su formato y su visualización correcta en un

navegador web. Este objetivo tiene que ver con los CMS (del inglés, Content Management

System).

Un sistema de gestión de contenidos o CMS es una herramienta que permite crear un

marco de trabajo (del inglés, framework) para la creación y administración de contenidos

por parte de los editores.

Un CMS consiste en una interfaz que controla una o varias bases de datos donde se aloja el

contenido del sitio. El sistema permite manejar de manera independiente el contenido y el

diseño. Así, es posible manejar el contenido y darle en cualquier momento un diseño

distinto al sitio sin tener que darle formato al contenido de nuevo, además de permitir la a

varios editores publicación fácil y controlada en el sitio.

Es importante que un gestor de contenidos proporcione una interfaz de usuario lo más

intuitiva posible dentro de su complejidad, que permita subir cualquier tipo de contenido

y que facilite su correcta visualización.

Drupal [Drupal, 2011a] es el gestor de contenido elegido para este TFC y por tanto, del que

se hablará a lo largo de todo este texto. Los motivos por los que se ha elegido éste y no

otro entre tantos CMS, se detallan en el estado de la cuestión. Además, se hace hincapié en

su funcionamiento y su arquitectura interna.

El resto de este TFC está estructurado en cinco grandes apartados. En el “estado de la

cuestión” se describe el estado actual de las áreas en las que se ha trabajado para

desarrollar este proyecto (accesibilidad, usabilidad y tecnologías de desarrollo). En el

apartado “planteamiento del problema” se expone la situación actual del sitio web y los

problemas que presenta. En el tercer apartado, la “solución”, se recoge los requisitos de

alto nivel, el diseño y la implementación de los mismos, así como las pruebas. Por último

están los apartados de conclusiones y líneas de trabajo futuras.


2. ESTADO DE LA CUESTIÓN [5]

2. ESTADO DE LA CUESTIÓN

Intentar centrar los ámbitos en los que se mueve este Trabajo es difícil, ya que son muchos

y muy amplios teniendo en cuenta todo lo que abarca la creación de un sitio web. Con

motivo del crecimiento de internet y del uso de la web, las tecnologías de desarrollo están

en continuo cambio y evolución. Los lenguajes que ayer se usaban para el desarrollo web

hoy ya son obsoletos, y versiones completamente renovadas ya se han estandarizado. Y la

tecnología que ayer se usaba para incorporar determinados tipos de contenidos en la web,

hoy ya no se usa porque existe una nueva tecnología más fácil de usar, más completa y más

compacta.

Por lo que se va a centrar el estado de la cuestión en dos grandes bloques para abarcar

todo lo que a este Trabajo compete y situar al lector. Los bloques son:

Ámbitos del desarrollo web

Tecnologías para el desarrollo web

Los ámbitos del desarrollo web que se van a tratar son la accesibilidad y la usabilidad. Un

concepto íntimamente ligado al de usabilidad es el de accesibilidad. Éste ya no se refiere a

la facilidad de uso, sino a la posibilidad de acceso. En concreto a que el diseño, como

prerrequisito imprescindible para ser usable, posibilite el acceso a todos sus potenciales

usuarios, sin excluir a aquellos con limitaciones individuales - discapacidades, dominio del

idioma,... - o limitaciones derivadas del contexto de acceso - software y hardware

empleado para acceder, ancho de banda de la conexión empleada, etc. - [Hassan, Y., Martín,

F., 2003a]

Estos dos conceptos tienden a confundirse, pero no representan lo mismo ni su objetivo

final es el mismo, aunque sí que es cierto que lograr uno ayuda a lograr el otro. En los

sucesivos apartados se va a hablar de cada uno de ellos para intentar encontrar qué los

diferencia.

Como tecnologías para el desarrollo web se consideran los lenguajes de programación y

las herramientas de gestión de contenidos. Dentro de los lenguajes de programación se

encuentran lenguajes de marcado y presentación como (X)HTML y CSS o lenguajes de

scripting como PHP o JavaScript. Respecto de las herramientas de gestión de contenidos,

existen muchas y de muy diversa índole. En este Trabajo se comparan algunas de ellas y se

centra la atención en la utilizada para la implementación del mismo, Drupal.



2.1. ¿Qué es la accesibilidad web?

El objetivo de la accesibilidad web es lograr que las personas con algún tipo de

discapacidad puedan hacer uso de la web. Más concretamente, que puedan percibir,

comprender, navegar e interactuar con la web del mismo modo que otra persona que no

tuviese esa discapacidad. También se persigue que estas personas puedan contribuir en la

web, creando nuevos contenidos. [Lawton, 2005]

La accesibilidad web también beneficia a personas sin una discapacidad permanente o a

empresas y organizaciones. Se toma el ejemplo de una organización que quiere gente que

se una a su movimiento. Si su formulario de inscripción no es accesible perderán a un

porcentaje de la población que podría estar interesada en ellos. Según cifras del año 2010

dadas por el INE (Instituto Nacional de Estadística), la tasa en España de población con

alguna discapacidad o limitación por edad y sexo es de 85,45 por cada 1.000 habitantes, es

decir el 8,5% de la población sufre alguna discapacidad [INE, 2010]. Si uno se pone desde

el punto de vista de una empresa que vende sus productos por Internet, también les

interesa que estos productos los pueda comprar un amplio abanico del mercado, lo que le

lleva a hacer un sitio web accesible. Si se piensa en personas con discapacidades

temporales puede ser cualquiera en un momento puntual, una mano rota, un hombro

dislocado… Son situaciones en las que ayuda que las cosas sean más fáciles. Y de esto trata

la accesibilidad.

La accesibilidad web abarca todas las posibles discapacidades que puedan afectar al

acceso de una página web, incluyendo la capacidad visual, auditiva, física, del habla,

cognitiva o neurológica.

Millones de personas poseen discapacidades que afectan al modo en que usan la web.

Actualmente, muchos sitios web tienen barreras de accesibilidad que dificultan o

imposibilitan el uso o acceso a la misma a personas con discapacidad. Cuantos más sitios

sean accesibles, más personas con discapacidad serán capaces de contribuir con la web de

manera más efectiva.

2.2. ¿Por qué es importante la accesibilidad web?

La web se ha ido abriendo paso y ha ido ganando importancia como recurso en muchos

aspectos de la vida: educación, trabajo, comercio, trámites públicos, cuidado de la salud,

ocio y más. Es importante que la web sea accesible con el fin de proporcionar un acceso

equitativo y dar las mismas oportunidades a todas las personas, con o sin discapacidad.

La web ofrece a las personas con discapacidad una posibilidad sin precedentes para

acceder a la información e interactuar con ella. Las barreras de accesibilidad, a la hora de

publicar audio y vídeo, pueden ser cubiertas más fácilmente haciendo uso de las nuevas

tecnologías de las web.



Además, una consideración importante que deben tener las empresas y organizaciones es

que existe una legislación que regula la accesibilidad web, lo cual la hacen obligatoria en

algunos casos.

2.3. Cumplimiento de la accesibilidad web y legislación española

El Consorcio de la Web, entre sus muchos ámbitos de trabajo, creó un grupo responsable

de la accesibilidad web. El grupo WAI (del inglés, Web Accesibility Initiative) [W3C, 2011]

se encarga de:

Desarrollar pautas que son consideradas como el estándar internacional de la

accesibilidad web. Hay pautas para el contenido web, para las herramientas de

autor y para las aplicaciones de usuario (los navegadores y otros programas que

acceden a la web).

Proporcionar material de soporte para ayudar a comprender e implementar la

accesibilidad web.

Proporcionar recursos a través de colaboración internacional.

Como fruto del trabajo de este grupo se publicaron el 5 de mayo de 1999 las WCAG 1.0

[Chisholm et al, 1999] (del inglés, Web Content Accesibility Guidelines), es decir, las

primeras pautas de accesibilidad para la publicación de contenidos en la web.

Las WCAG 1.0 se definen con 14 pautas de alto nivel, cada una de las cuales tiene sus

respectivos puntos de verificación. En total son 65 los puntos de verificación. Estos puntos

tienen asociada una prioridad que determina lo que implica no satisfacer dicho punto.

Estas prioridades son:

Prioridad 1: deben satisfacerse. En caso contrario para algunos grupos de usuarios

es imposible acceder al contenido. Si una página cumple todos estos puntos se dice

que tiene un nivel “A” de conformidad con WCAG.

Prioridad 2: deberían cumplirse. En caso contrario hay grupos de usuarios para

los que es muy difícil acceder al contenido. Si una página cumple todos estos

puntos y los de prioridad 1 se dice que tiene un nivel doble ‘A’ o “AA” de

conformidad con WCAG.

Prioridad 3: pueden cumplirse. En caso contrario hay grupos de usuarios para los

cuales puede ser difícil acceder a los contenidos. Si una página cumple todos estos

puntos y los de prioridad 1 y 2, se dice que tiene un nivel triple ‘A’ o “AAA” de

conformidad con WCAG.

La web evoluciona muy rápido y las nuevas tecnologías para crear contenidos no tienen

una implementación clara en estas pautas. Por ello, el WAI empezó a desarrollar las WCAG

2.0 con las que se pretende hacer más hincapié en cómo debe ser el contenido para ser

accesible de manera independiente a la tecnología que se utilice. De esta forma, las WCAG

2.0 se pueden aplicar tanto a las tecnologías actuales, como a las tecnologías futuras. Se



busca que sean más fáciles de usar y de comprender siendo de este modo más precisas

para evaluar tanto de forma manual como con herramientas de evaluación automática. El

11 de diciembre de 2008 se publicó la nueva versión de las WCAG, las WCAG 2.0 [Caldwell

et al, 2008]

La estructura de este nuevo documento es mucho más completa con el fin de proporcionar

a los desarrolladores más material de soporte para comprender e implementar las nuevas

pautas.

El nuevo documento se podría definir como un compendio de documentos que abarca el

documento de las WCAG 2.0 propiamente dicho, entre los que se encuentran el documento

de comprensión de las WCAG 2.0 titulado Uderstanding WCAG 2.0 [W3C, 2008a], el

documento que habla sobre técnicas de implementación y errores para conseguir cumplir

cada una de las pautas titulado “Techniques for WCAG 2.0” [W3C, 2010a] y una guía rápida

sobre las técnicas para cada pauta de las WCAG 2.0 titulado “How to meet WCAG 2.0” [W3C,

2008c]. En la Figura 1 se puede ver cómo se relacionan estos documentos entre sí y los

contenidos que presentan.

Figura 1: Estructura de los documentos que conforman las WCAG 2.0

Las WCAG 2.0 se estructuran en 4 principios: perceptible, operable, comprensible y

robusto. Estos 4 principios recogen todos los criterios necesarios para que un sitio web

sea accesible a nivel triple ‘A’. Para ello, se dividen en pautas, 12 en total. Para cada una de

estas pautas existen criterios de conformidad, cada uno de los cuales tiene una prioridad.

El significado de la prioridad se ha mantenido de las WCAG 1.0 a las WCAG 2.0.

En España las WCAG 1.0 han sido normalizadas y referenciadas en la legislación vigente

sobre accesibilidad como criterio para medir la accesibilidad de un sitio web, ya que las



leyes son anteriores a la publicación de las nuevas pautas. Aun así, es posible cumplir las

WCAG 2.0 y seguir cumpliendo las WCAG 1.0 y por tanto la ley española. Es más, dadas las

nuevas tecnologías y los nuevos lenguajes de programación web es recomendable aplicar

las nuevas pautas, ya que cubren todas las posibles situaciones de manera independiente a

la tecnología.

Este Trabajo ha implementado la accesibilidad web siguiendo las WCAG 2.0 de manera

que se mantenga la compatibilidad con las WCAG 1.0. En el apartado siguiente se habla de

estas últimas y se comenta su estructura. Pero antes, es necesario saber qué exige la ley y

como afecta al proyecto de esta Fundación.

A lo largo de los últimos años España ha visto la necesidad de adaptarse a las leyes y

normativas europeas sobre accesibilidad en la sociedad de la información. La primera

proposición no de ley que se aprobó en España fue la “Proposición no de ley para facilitar el

acceso de las personas mayores y con discapacidad en el portal de Internet de la

Administración General del Estado” [BOCG, 2001]

El 15 de marzo de 2001 fue aprobada por unanimidad en el Congreso de los Diputados la

Proposición No de Ley, presentada por el diputado Jordi Jané en nombre del Grupo

Parlamentario CIU, "para facilitar el acceso de las personas mayores y con discapacidad en

el portal de Internet de la Administración General del Estado" [Sidar, 2008].

En los apartados que vienen a continuación se van a comentar las siguientes leyes:

Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de

comercio electrónico [BOE, 2002]

Ley 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación

y accesibilidad universal de las personas con discapacidad [BOE, 2003]

Real Decreto 1494/2007 por el que se aprueba el Reglamento sobre las

condiciones básicas para el acceso de las personas con discapacidad a las

tecnologías, productos y servicios relacionados con la sociedad de la información y

medios de comunicación social. [BOE, 2007b]

Ley 49/2007 por la que se establece el régimen de infracciones y sanciones en

materia de igualdad de oportunidades, no discriminación y accesibilidad universal

de las personas con discapacidad. [BOE, 2007c]

Ley 56/2007 de Medidas de Impulso de la Sociedad de la Información [BOE,

2007a]

Ley 30/2007, de 30 de octubre, de Contratos del Sector Público [BOE, 2007d]

REAL DECRETO 366/2007 por el que se establecen las condiciones de

accesibilidad y no discriminación de las personas con discapacidad en sus

relaciones con la Administración General del Estado. [BOE, 2007e]

Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los

Servicios Públicos [BOE, 2007f]



Instrumento de Ratificación de la Convención de Derechos de las Personas con

Discapacidad, dado el 21 de abril de 2008 [BOE, 2008]

2.3.1. LEY 34/2002

En el año 2002 se aprobó la primera ley que regulaba entre otros puntos la accesibilidad

en los servicios de la sociedad de la información y de comercio electrónico. [BOE, 2002]

LEY 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio

electrónico fue publicada en el Boletín Oficial del Estado (BOE) el 12 de julio. Entrando en

vigor a los tres meses de su publicación, es decir el 12 de octubre de 2002, excepto las

disposiciones adicional sexta y finales primera, segunda, tercera y cuarta de esta Ley que

entraron en vigor el día siguiente al de su publicación en el BOE.

Sobre accesibilidad la ley dice, en su disposición adicional quinta:

Quinta. Accesibilidad para las personas con discapacidad y de edad avanzada a la información

proporcionada por medios electrónicos.

Uno. Las Administraciones Públicas adoptarán las medidas necesarias para que la

información disponible en sus respectivas páginas de Internet pueda ser accesible a personas

con discapacidad y de edad avanzada de acuerdo con los criterios de accesibilidad al

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

Dos. Igualmente, se promoverá la adopción de normas de accesibilidad por los prestadores de

servicios y los fabricantes de equipos y software, para facilitar el acceso de las personas con

discapacidad o de edad avanzada a los contenidos digitales.

2.3.2. LEY 51/2003

La ley 51/2003 es la ley de igualdad de oportunidades, no discriminación y accesibilidad

universal de las personas con discapacidad conocida como "LIONDAU" [BOE, 2003], viene

a llenar el vacío existente en España de un marco legal amplio y general, similar al que

proporcionan en otros países leyes similares.

La LIONDAU se basa y pone de relieve los conceptos de no discriminación, acción positiva

y accesibilidad universal.

La ley prevé, además, la regulación de los efectos de la lengua de signos, el reforzamiento

del diálogo social con las asociaciones representativas de las personas con discapacidad

mediante su inclusión en el Real Patronato y la creación del Consejo Nacional de la

Discapacidad, y el establecimiento de un calendario de accesibilidad por ley para todos los

entornos, productos y servicios nuevos o ya existentes.



Uno de los cambios más relevantes respecto a la legislación anterior, recogido en el

artículo 20 de la ley, es la inversión de la carga de la prueba, por la que será el demandado,

y no el demandante, quien deberá justificar las medidas tomadas para garantizar la

accesibilidad y deberá explicar qué ha hecho para proporcionar un servicio accesible.

La Ley establece, la obligación gradual y progresiva de que todos los entornos, productos y

servicios deben ser abiertos, accesibles y practicables para todas las personas y dispone

plazos y calendarios para realización de las adaptaciones necesarias.

Respecto a los productos y servicios de la Sociedad de la Información la ley establece:

Disposición final séptima. 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.

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

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 existentes que sean susceptibles de ajustes razonables.

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.

Y favoreciendo la formación en diseño para todos:

Disposición final décima. Currículo formativo sobre accesibilidad universal y formación de

profesionales.

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 todos>>, en todos los programas educativos, incluidos los

universitarios, para la formació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 transporte, las comunicaciones y

telecomunicaciones y los servicios de la sociedad de la información.

Para administrar la gradualidad en la puesta en marcha de la LIONDAU se consideró

conveniente la elaboración de instrumentos de planificación, y al tiempo de su redacción

se diseñaron dos planes: el "Plan Nacional de Accesibilidad 2004-2012" y el "II Plan de

Acción para las personas con discapacidad 2003-2007".

2.3.3. Real Decreto 1494/2007

El presente real decreto se inspira en los principios establecidos en la Ley 51/2003, de 2

de diciembre, fundamentalmente, accesibilidad universal y diseño para todos.



Este real decreto establece la Norma UNE 129803:2004 como las pautas que regulan la

accesibilidad de las páginas web en España, las cuales han incorporado las pautas

propuestas por el WAI (del inglés, Web Accessibility Initiative) con los tres niveles de

accesibilidad que se pueden alcanzar aplicando dichos criterios: A, doble A “AA” y triple

“A”.

Por otro lado, este real decreto también establece que las páginas de internet de las

administraciones públicas deben cumplir como nivel mínimo obligatorio las prioridades 1

y 2 de la Norma UNE anterior. [BOE, 2007b]

El “Reglamento sobre las condiciones básicas para el acceso de las personas con

discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la

información y medios de comunicación social” recoge en su capítulo II las “Condiciones

básicas de accesibilidad y no discriminación en materia de telecomunicaciones”.

En el capítulo 3 de este reglamento se recogen “Criterios y condiciones básicas de

accesibilidad y no discriminación en materia de sociedad de la información”. Entre

sus artículos se encuentra el siguiente:

Artículo 5

Criterios de accesibilidad aplicables a las páginas de internet de las administraciones públicas o con

financiación pública

Uno. La información disponible en las páginas de internet de las administraciones públicas

deberá ser accesible a las personas mayores y personas con discapacidad, con un nivel mínimo

de accesibilidad que cumpla las prioridades 1 y 2 de la Norma UNE 139803:2004.

Esta obligación no será aplicable cuando una información, funcionalidad o servicio no

presente una alternativa tecnológica económicamente razonable y proporcionada que

permita su accesibilidad.

Asimismo, respecto a la lengua de signos, las citadas páginas de internet tendrán en cuenta lo

dispuesto en la Ley 27/2007, de 23 de octubre, por la que se reconocen las lenguas de signos

españolas y se regulan los medios de apoyo a la comunicación oral de las personas sordas, con

discapacidad auditiva y sordociegas.

Dos. Excepcionalmente, las administraciones públicas podrán reconocer la accesibilidad de

páginas de internet conforme a normas técnicas distintas de las que figuran en el apartado 1

de este artículo, siempre que se compruebe que alcanzan una accesibilidad similar a la que

estas normas garantizan.

Tres. Las páginas de Internet de las administraciones públicas deberán contener de forma

clara la información sobre el grado de accesibilidad al contenido de las mismas que hayan

aplicado, así como la fecha en que se hizo la revisión del nivel de accesibilidad expresado.



Cuatro. Para poder acceder a financiación pública para el diseño o mantenimiento de

páginas de internet será necesario asumir el cumplimiento de los criterios de accesibilidad

previstos en el apartado 1 del presente artículo.

De igual modo, serán exigibles, y en los mismos plazos, estos criterios de accesibilidad para las

páginas de Internet de entidades y empresas que se encarguen, ya sea por vía concesional o a

través de otra vía contractual, de gestionar servicios públicos, en especial, de los que tengan

carácter educativo sanitario y servicios sociales.

Asimismo, será obligatorio lo expresado en este apartado para las páginas de Internet y sus

contenidos, de los centros públicos educativos, de formación y universitarios, así como, de los

centros privados sostenidos, total o parcialmente, con fondos públicos.

Cinco. Las páginas de internet de las administraciones públicas deberán ofrecer al usuario un

sistema de contacto para que puedan transmitir las dificultades de acceso al contenido de las

páginas de Internet, o formular cualquier queja, consulta o sugerencia de mejora. Los órganos

competentes realizarán periódicamente estudios de carácter público sobre las consultas,

sugerencias y quejas formuladas.

Por último en el cuarto y último capítulo del reglamento se establecen las “Condiciones

básicas de accesibilidad y no discriminación en materia de medios de comunicación

social”.

En las disposiciones transitorias de este real decreto se encuentra la disposición

transitoria única que establece los plazos de cumplimiento de la ley:

Plazos

Uno. Las obligaciones y medidas contenidas en este real decreto y el reglamento anexo serán exigibles

desde el 4 de diciembre de 2009 para todos los productos y servicios nuevos, incluidas las campañas

institucionales que se difundan en soporte audiovisual y desde el 4 de diciembre de 2013 para todos

aquellos existentes que sean susceptibles de ajustes razonables.

Dos. Las páginas de internet de las administraciones públicas o con financiación pública deberán

adaptarse a lo dispuesto en el artículo 5 de dicho reglamento, en los siguientes plazos:

a) Las páginas nuevas deberán ajustarse a la prioridad 1 de la Norma UNE 139803:2004 desde

la entrada en vigor del real decreto.

b) Las páginas existentes deberán adaptarse a la prioridad 1 de la Norma UNE 139803:2004 en

el plazo de 6 meses desde la entrada en vigor.

c) Todas las páginas, actualmente existentes o de nueva creación, deberán cumplir la prioridad

2 de la Norma UNE 139803:2004 a partir del 31 de diciembre de 2008. No obstante, este

plazo de adaptación y la citada norma técnica de referencia podrán ser modificados a efectos

de su actualización mediante orden ministerial conjunta, en los términos establecidos en la

disposición final tercera de este real decreto.



Tres. Las obligaciones que la disposición adicional primera de este real decreto introduce en el

reglamento aprobado por el Real Decreto 424/2005, de 15 de abril, deberán ser cumplidas a partir de

la entrada en vigor del presente real decreto, a excepción de lo en ella previsto para la accesibilidad a

la guía telefónica universal a través de Internet, a la que serán de aplicación los plazos establecidos en

el apartado anterior.

2.3.4. Ley 49/2007

La ley 49/2007, de 26 de diciembre establece el régimen de infracciones y sanciones como

garantía de las condiciones básicas de accesibilidad y no discriminación de las personas

con discapacidad, definidas en la Ley 51/2003, de 2 de diciembre. [BOE, 2007c]

En el capítulo I, “Infracciones”, el artículo 2 establece el “Objeto de las infracciones”:

A los efectos de esta Ley, se considerarán infracciones administrativas las acciones y omisiones que

ocasionen vulneraciones del derecho a la igualdad de oportunidades, no discriminación y

accesibilidad, cuando se produzcan discriminaciones directas o indirectas, acosos, incumplimiento de

las exigencias de accesibilidad y de realizar ajustes razonables, así como el incumplimiento de las

medidas de acción positiva legalmente establecidas, especialmente cuando se deriven beneficios

económicos para la persona infractora.

En la tabla 1 se resumen las infracciones posibles que se clasifican según tres niveles de

severidad como leves, graves y muy graves según el artículo 3, “Infracciones”.

Mínimo (€) Medio (€) Máximo (€)

Leves 301 – 6.000 6.001 – 18.000 18.001 – 30.000

Graves 30.001 – 60.000 60.001 – 78.000 78.001 – 90.000

Muy graves 90.001 – 300.000 300.001 – 600.000 600.001 – 1.000.000 Tabla 1: Sanciones económicas en función del grado de infracción

2.3.5. Ley 56/2007

La Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la

Información, [BOE, 2007a] es una actualización de la “LSSICE” (Ley de Servicios de la

Sociedad de la Información y de Comercio Electrónico) por lo que mantiene la obligación

de accesibilidad de las páginas públicas y además añade en su disposición adicional

tercera 20.5 la obligación a que las páginas de las empresas a las que les afecte el artículo 2

del capítulo I.

El capítulo I sobre “Medidas de impulso de la sociedad de la información” en su

artículo 2 establece la “Obligación de disponer de un medio de interlocución

telemática para la prestación de servicios al público de especial trascendencia

económica” a empresas que agrupen más de cien trabajadores o con un volumen anual de

operaciones superior a 6.010.121,04 € que estén dentro de los siguientes sectores,

también sean accesibles.



Servicios de comunicaciones electrónicas (según Ley General de

Telecomunicaciones)

Servicios financieros: bancos, inversiones, seguros, planes de pensiones…

Suministro de agua a consumidores

Suministro de gas a consumidores

Suministro eléctrico a consumidores

Agencias de viajes

Servicios de transporte de viajeros

Comercio al por menor

2.4. Introducción a las WCAG

La nueva versión de las WCAG presenta una mayor complejidad en la estructura del

documento. Para poder comprender la implementación y evaluación de la accesibilidad en

este Trabajo es necesario tener una visión global sobre las WCAG 2.0 y sus materiales de

soporte, así como conocer las diferencias con las WCAG 1.0.

Los documentos de las pautas de accesibilidad para contenido web recogen los requisitos

que deben cumplir los contenidos para que sean considerados accesibles para personas

con discapacidad. Cuando se habla de contenido web, generalmente se refiere a la

información que contiene una página web o una aplicación web incluyendo texto,

imágenes, formularios, sonidos y similares. [Lawton, 2008]

Las WCAG están pensadas para desarrolladores de contenidos web (autores de páginas

web, diseñadores de sitios, etc.), desarrolladores de herramientas web, desarrolladores de

herramientas de evaluación de accesibilidad web y otras personas que desean o necesitan

un estándar técnico sobre accesibilidad web.

Las WCAG y sus materiales relacionados tratan de cubrir las necesidades de diferentes

ámbitos como legisladores, responsables de sitios web o personas que son nuevas en la

accesibilidad web.

Existen dos versiones de las WCAG: WCAG 1.0 publicadas en mayo de 1999 y WCAG 2.0

publicadas en diciembre de 2008.

2.5. WCAG 2.0: Estructura y contenido

Las WCAG 2.0 se aplican a cualquier tecnología web y pretenden ser más fáciles de usar y

comprender siendo a la vez más precisas y verificables con herramientas de evaluación

automáticas o por evaluadores humanos. Actualmente el W3C recomienda el uso de las

WCAG 2.0 en lugar las WCAG 1.0. [W3C, 2008a]

Se estructuran en 4 principios que recogen los fundamentos necesarios para que cualquier

persona pueda acceder y usar un contenido web: perceptible, operable, comprensible y



robusto. Estos principios se dividen en un total de 12 pautas. Para cada una de las 12

pautas existen criterios de conformidad verificables que pueden ser de un nivel de

conformidad: A, AA y AAA.

2.5.1. Los principios

Para hacerse una idea de lo que se incluye en las WCAG 2.0 se presenta un breve resumen

de lo que recoge cada uno de los 4 principios:

Perceptible. La información y los componentes de la interfaz de usuario deben

presentarse a los usuarios de forma que puedan percibirlos. Esto quiere decir que los

usuarios deben ser capaces de percibir la información que está siendo presentada (no

puede ser invisible para todos sus sentidos). Algunas medidas para lograr contenido

perceptible son:

Proporcionar alternativas de texto para el contenido “no - textual”.

Proporcionar subtítulos y alternativas para el contenido de vídeo y audio.

Hacer que el contenido sea adaptable y que esté disponible para las tecnologías de

apoyo.

Hacer uso del contraste necesario para que las cosas se vean y oigan fácilmente.

Operable. Los componentes de la interfaz de usuario y la navegación deben ser operables.

Es decir, que los usuarios deben ser capaces de operar con la interfaz (la interfaz no debe

requerir interacción alguna que algún usuario no pueda llevar a cabo). Algunas medidas

para lograr contenido operable son:

Hacer que toda la funcionalidad sea accesible por teclado.

Dar a los usuarios tiempo suficiente para leer y usar el contenido.

No hacer uso de contenido que pueda causar ataques epilépticos o similares.

Ayudar al usuario a navegar y encontrar el contenido que busca.

Comprensible. La información y el funcionamiento de la interfaz de usuario deben ser

comprensibles. Esto quiere decir que los usuarios deben ser capaces de comprender la

tanto la información como la operativa de la interfaz (el contenido o la operativa no puede

estar más allá de su comprensión). Algunas medidas para lograr contenido comprensible

son:

Hacer que el texto sea legible y comprensible.

Hacer que el contenido aparezca y opere de manera predecible.

Ayudar al usuario a evitar y corregir errores.

Robusto. El contenido debe ser lo suficientemente robusto como para que pueda ser

interpretado por una amplia variedad de agentes de usuario (navegadores), incluyendo



tecnologías de apoyo. La medida principal para lograr un contenido robusto es maximizar

la compatibilidad con las tecnologías actuales y venideras.

Si alguno de estos principios no se cumplen, los usuarios con discapacidad no serán

capaces de usar la web.

2.5.2. Las pautas

Como ya se ha dicho, bajo cada principio hay pautas (en total 12) y criterios de

conformidad que ayudan a conseguir estos principios.

Uno de los objetivos de las pautas es asegurarse de que el contenido es directamente

accesible para el máximo de personas que sea posible y es capaz de ser representado de

diferentes formas para cubrir personas con diferentes habilidades sensoriales, físicas y

cognitivas. [W3C, 2008a]

Pauta 1.1. Proporcionar un texto alternativo para todo el contenido no textual.

El propósito de esta pauta es asegurar que todo el contenido no textual está disponible en

modo texto (no sirven imágenes de texto). El texto presenta la ventaja de ser un

mecanismo disponible visualmente o auditivamente.

Pauta 1.2. Proporcionar un alternativo para todo el contenido basado en el tiempo.

El propósito de esta pauta es proporcionar acceso al contenido basado en el tiempo, el cual

incluye el vídeo solo, el audio solo, el audio y vídeo y el audio o vídeo combinado con

interacción.

Los subtítulos permiten a las personas con discapacidades auditivas acceder a toda la

información de forma sincronizada con la presentación multimedia. Es decir, pueden ver

el contenido multimedia al mismo tiempo que leen los subtítulos y no están limitados a

acceder únicamente a una transcripción textual que, aunque proporciona toda la

información, limita significativamente su experiencia de usuario.

A diferencia de los subtítulos habituales, el subtitulado para sordos incluye todos los

contenidos sonoros, tanto los diálogos como los sonidos ambientales y todo sonido

significativo necesario para comprender el contenido multimedia: diálogos, identificación

de hablantes, música, risas, aplausos, sonidos significativos en general.

Si el contenido multimedia tiene varias pistas de audio en diferentes idiomas se debe

proporcionar subtítulos para todos los idiomas usados.

A nivel técnico se pueden diferenciar dos tipos de subtítulos:

Subtítulos abiertos



Los subtítulos abiertos son aquellos que no se pueden desactivar y están disponibles para

todo el mundo. Generalmente se trata de subtítulos incrustados en el propio video, es

decir, forman parte de la imagen.

Haciendo un símil, son como los subtítulos de las películas en VHS los cuales formaban

parte de la imagen. Si se emplean subtítulos abiertos, se pueden incluir en la presentación

multimedia original o bien proporcionar dos versiones de la presentación, una con

subtítulos y otra sin ellos.

Subtítulos cerrados

Los subtítulos cerrados, al contrario que los abiertos, se pueden activar y desactivar. Para

proporcionar estos subtítulos se pueden emplear diferentes tecnologías (como SMIL 1.0 o

SMIL 2.0) para sincronizar varios archivos en una presentación multimedia. Por ejemplo,

la presentación multimedia original con uno o varios archivos de texto que contienen los

subtítulos.

Siguiendo con los símiles, son como los subtítulos de las películas en DVD los cuales se

pueden seleccionar, mostrar y ocultar sobre la película original a voluntad de los usuarios.

A la hora de proporcionar subtítulos para un contenido multimedia se puede emplear

cualquiera de los dos tipos, tanto subtítulos abiertos como subtítulos cerrados.

Pauta 1.3. Crear contenido que pueda ser presentado de diferentes maneras sin perder la

información o la estructura.

El propósito de esta pauta es asegurarse que toda la información está disponible de

manera que pueda ser percibida por todos los usuarios. La información no puede estar

embebida de manera particular de forma que no pueda determinarse la estructura o la

información por una tecnología de apoyo.

La idea es que la mayoría de los usuarios perciben la estructura de los documentos de

forma visual, a través de la presentación. Por ejemplo:

Los encabezados se destacan del resto del contenido mediante el tipo y/o un

tamaño de letra proporcional a su importancia.

Los elementos de lista tienen una viñeta para diferenciarlos y se suelen mostrar

dentados.

Los párrafos se separan con una línea en blanco.

El texto enfatizado se reconoce porque usa un tipo de fuente en negrita o en

cursiva.

Un mismo color de fondo o un borde puede indicar la agrupación de varios

elementos relacionados.



Sin embargo, existen usuarios que no pueden percibir esta información visual (p. ej.

personas con ceguera que usan lectores de pantalla). Para que estos usuarios puedan

acceder a esta información es necesario indicar explícitamente la función estructural o

valor semántico del contenido, de forma que esta información se pueda determinar

mediante software. Es decir, que los agentes de usuario, productos de apoyo y otras

aplicaciones software sean capaces de reconocer la estructura y semántica del contenido

para transmitirla a los usuarios.

Pauta 1.4. Hacer que el usuario pueda ver y oír de manera sencilla el contenido separando

claramente el fondo del primer plano.

Mientras algunas pautas están enfocadas en hacer que la información esté disponible de

forma que pueda ser presentada en formatos alternativos, esta pauta se concentra en

hacer que la presentación por omisión sea tan fácil de percibir como sea posible a

personas con discapacidad. El objetivo principal es hacer que el usuario pueda separar lo

que es información de lo que no lo es.

Pauta 2.1. Hacer que toda la funcionalidad esté disponible mediante teclado.

Si toda la funcionalidad puede alcanzarse usando el teclado, puede llevarse a cabo por

todos los demás medios: usando sólo teclado, usando entradas de voz (las cuales crean

entradas de teclado), usando ratón (los cuales pueden usar el teclado por pantalla), etc.

Cualquier otra forma no presenta tanta flexibilidad o universalidad en el soporte.

Pauta 2.2. Proporcionar al usuario suficiente tiempo para leer o usar el contenido.

Muchos usuarios que poseen discapacidad necesitan más tiempo que la mayoría para

completar ciertas tareas. Esta pauta se centra en asegurarse de que todos los usuarios son

capaces de completar las tareas requeridas por el contenido en el tiempo que ellos

necesiten.

Por ejemplo, es el caso de las actualizaciones automáticas. Cuando se produce una

actualización automática los lectores de pantalla comienzan a leer la página desde el

principio. Esto, además de desorientar, impide que los usuarios de estos productos de

apoyo puedan acceder a todo el contenido de la página al reiniciarse continuamente la

lectura desde el comienzo. De igual forma, los usuarios de magnificadores de pantalla o las

personas con problemas de lectura también se desorientarán cuando se producen

actualizaciones automáticas. Por tanto, debemos permitir que los usuarios puedan

cancelar las actualizaciones automáticas o, al menos, que las puedan posponer.

Pauta 2.3. No diseñar el contenido de manera que se sepa que causa ataques epilépticos.



Algunas personas con epilepsia pueden tener ataques provocados por ciertos contenidos

visuales que destellan. Hay gente que no sabe que tiene este problema hasta que sufren el

primer ataque. Por tanto, el propósito de esta pauta es asegurarse de que el contenido

cumple con las medidas de frecuencia de destello adecuadas para no provocar estos

ataques.

El margen de seguridad a partir del cual se considera que los destellos tienen

consecuencias negativas es más permisivo que el que se aplicaba en las WCAG 1.0. En la

primera versión de las pautas no se permitía ningún contenido con destellos cuya

frecuencia estuviese entre 3Hz y 50Hz, independientemente de su tamaño. Así, un

contenido con destellos incluso de un tamaño de 1x1 píxeles incumplía las WCAG 1.0.

En cambio, en las WCAG 2.0 se han ampliado los márgenes de seguridad adaptándolos a

las circunstancias en las que realmente los destellos implican riesgos para los usuarios.

Para establecer estos márgenes se ha tomado como referencia las especificaciones

existentes para contenidos televisivos, adaptándolos a las particularidades de las pantallas

de ordenador, con menor distancia y mayor ángulo de visión.

El margen de seguridad se basa en la frecuencia de los destellos y el área de los mismos

(tamaño a partir del cual se consideran peligrosos).

Pauta 2.4. Proporcionar maneras para ayudar al usuario a navegar, encontrar contenido y

saber dónde se encuentra.

La intención de esta pauta es ayudar al usuario a encontrar el contenido que pueda

necesitar y permitirle saber en qué sección de un sitio web se encuentra. Estas tareas son

más difíciles para algunas personas con discapacidad. Es importante mantener una

consistencia en el orden y en la forma en que se presentan, ya que las personas con

discapacidades cognitivas pueden confundirse.

Los usuarios tienen que poder interactuar mediante el teclado, navegar secuencialmente

por el contenido y encontrar la información en el orden correcto. Esto no implica que el

orden de lectura lineal -p. ej. mediante un lector de pantalla- o el orden del foco deban

coincidir necesariamente con el orden de lectura de la presentación visual. Es posible que

haya ciertas diferencias siempre y cuando el orden del foco tenga sentido en todos los

casos.

Por otro lado, la mayoría de sitios web tienen contenido que se repite en varias páginas,

como los menús de navegación, cabeceras de documentos, zonas de anuncios, etc. Los

usuarios sin discapacidad pueden centrar su atención directamente en el contenido

principal y dirigir el ratón a los enlaces que deseen. Sin embargo, algunas personas con

discapacidad acceden al documento de forma lineal (p. ej. lectores de pantalla) y tienen

que recorrer los documentos desde el principio hasta acceder a la zona de contenido



principal, viéndose obligados a leer el mismo contenido repetido cada vez que accedan a

otra página del sitio web.

Para evitar estos problemas, hay que asegurarse que existe algún mecanismo que permita

saltar los bloques de contenido repetido en diferentes páginas. Esto sólo es necesario

cuando dicha funcionalidad no la implementa el agente de usuario. Por ejemplo, la

mayoría de navegadores permiten volver al comienzo de documento por lo que no sería

necesario proporcionar un enlace al final que permitiese volver al comienzo de la página o

un enlace para saltar el último bloque de contenido.

Pauta 3.1. Hacer que el contenido sea legible y comprensible.

La intención de esta pauta es permitir a los usuarios leer el contenido mediante una

tecnología de apoyo y asegurarse que la información necesaria para su comprensión está

disponible.

Es el caso del idioma del sitio web. Los lectores de pantalla que reproducen varios idiomas

tienen la capacidad de usar el acento y la pronunciación adecuados para cada idioma.

Identificar el idioma principal usado en la página evita que estos productos de apoyo

intenten pronunciar el texto en el idioma por defecto de éstas herramientas. Si un texto se

lee con una pronunciación que no se corresponde con el idioma usado es posible que dicho

texto resulte incomprensible. De igual forma, los agentes de usuario y navegadores

gráficos pueden mostrar los caracteres y sistema de escritura -alfabeto, signos de

puntuación, etc.- de forma correcta según el idioma. Asimismo, los reproductores

multimedia podrían mostrar los subtítulos adecuados según el idioma principal del

documento.

Pauta 3.2. Hacer que las páginas web aparezcan y operen de manera predecible.

La intención de esta pauta es ayudar a los usuarios con discapacidad presentando el

contenido en un orden predecible entre páginas web de un mismo contexto. Esto es

necesario para las personas que usan lectores de pantalla, ya que presentan el contenido

de manera plana.

Pauta 3.3. Ayudar al usuario a evitar y corregir errores.

Todo el mundo comete errores. Sin embargo, algunas personas con discapacidad tienen

más dificultad para crear entradas libres de error. Además, detectar los errores es más

duro para ellos . Típicamente, los métodos para indicar errores no resultan obvios porque

están limitados a un campo visual, a un color o a usar una determinada tecnología. Esta

pauta persigue reducir el número de errores críticos o irreversibles que se puedan

cometer.

Pauta 4.1. Maximizar la compatibilidad con los agentes de usuario actuales y futuros

incluyendo las tecnologías de apoyo.



Esta pauta persigue que haya compatibilidad con los agentes de usuario, actuales y futuros

y especialmente con las tecnologías de apoyo. Esto significa que los autores no desarrollen

códigos de marcado pobre o utilicen un marcado o código no convencional y que el

contenido esté creado de manera estándar para que las tecnologías de apoyo lo puedan

reconocer e interactuar con él.

2.5.3. Criterios de conformidad

Dentro de cada pauta, hay criterios de conformidad que describen específicamente qué

debe lograrse a fin de lograr la conformidad con las WCAG 2.0. Cada criterio de

conformidad está escrito como una afirmación que podrá ser verdadera o falsa cuando sea

evaluada en un contenido web específico. El criterio de conformidad está escrito de forma

neutra en cuanto a tecnologías web.

Todos los criterios de conformidad de las WCAG 2.0 están escritos como criterios

verificables con el fin de determinar si un contenido lo satisface o no. Mientras que

algunos pueden ser evaluados automáticamente usando herramientas de evaluación, otros

requerirán comprobaciones realizadas por seres humanos para parte o todo. Un test

humano debe hacerse por una persona que comprenda cómo usan la web las personas con

diferentes tipos de discapacidad. Suele ser recomendable que se incluyan grupos de

personas con discapacidad a la tarea de testear.

Cada criterio de conformidad de una pauta tiene enlaces al material de soporte que se

comenta más abajo. Este material es un compendio de documentos que complementan las

WCAG 2.0 aportando:

Técnicas suficientes para alcanzar el criterio de conformidad.

Técnicas recomendadas opcionales.

Descripciones de la intención del criterio de conformidad incluyendo beneficios y

ejemplos.

Hay que destacar que, incluso el contenido que cumple con la conformidad de más alto

nivel (nivel triple ‘A’), puede no ser accesible para personas con todo tipo de

discapacidades, particularmente con discapacidades cognitivas del lenguaje o del

aprendizaje.

2.6. Material de soporte para las WCAG 2.0

Nota: De aquí en adelante se encontrarán numerosos términos en inglés. Esto se debe a que

la documentación oficial de las WCAG 2.0 está en este idioma. Aunque se está trabajando en

la traducción autorizada al español todavía no se ha finalizado ni aprobado, por lo que se ha

decidido utilizar para la realización del proyecto la documentación en inglés.

Existen documentos que dan soporte a las WCAG 2.0 y que ayudan a los desarrolladores a

realizar las labores de evaluación e implementación de la accesibilidad más fácilmente.



Estos documentos son: “Understanding WCAG 2.0”, “Techniques for WCAG 2.0” y “How to

meet WCAG 2.0”. En las siguientes secciones se hace una breve descripción de cada uno de

ellos.

Además de estos documentos, existe una sección muy importante en las WCAG 2.0 que es

imprescindible para lograr la conformidad con éstas. Es la sección de los requisitos de

conformidad.

2.6.1. Documento “Understanding WCAG 2.0”

El documento “Comprendiendo las WCAG 2.0” (del inglés, Understanding WCAG 2.0) es una

guía esencial para comprender y usar las WCAG 2.0. El contenido de este documento es

informativo (proporciona una guía) y no normativo (no establece requisitos para lograr la

conformidad con las WCAG 2.0) [W3C, 2008a].

Understanding WCAG 2.0 proporciona información detallada sobre cada criterio de

conformidad, incluyendo su intención, los términos clave usados en él y cómo el criterio de

conformidad puede ayudar a personas con diferentes tipos de discapacidad.

También proporciona ejemplos de contenidos web que cumplen cada criterio de

conformidad usando varias tecnologías (HTML, CSS, XML) y ejemplos muy comunes que

no satisfacen el criterio. Este documento indica las técnicas específicas para lograr la

satisfacción de cada criterio de conformidad. Los detalles sobre cómo implementar cada

técnica figuran en el documento “Techniques for WCAG 2.0” que se comenta a continuación,

pero este documento proporciona información sobre la relación de cada técnica con cada

criterio de conformidad.

2.6.2. Documento “Techniques for WCAG 2.0”

El documento “Técnicas para las WCAG 2.0” (del inglés, Techniques for WCAG 2.0)

proporciona información para desarrolladores de contenido web que desean satisfacer los

criterios de conformidad de las WCAG 2.0. Las técnicas son prácticas autorizadas

específicas que pueden ser usadas como soporte a los criterios de conformidad de las

WCAG 2.0 [W3C, 2010a].

El documento proporciona por un lado técnicas generales que describen prácticas básicas

aplicables a cualquier tecnología web y por otro lado técnicas específicas para cada

tecnología web (HTML, CSS, script…). El consorcio de la web comenzó documentando sólo

técnicas para tecnologías sin propiedad intelectual; pero actualmente existe una nueva

versión de este documento que incluye técnicas para tecnologías como Flash. En próximas

versiones se esperan incluir técnicas para PDF o Silverlight.

Estas técnicas son suficientes para alcanzar cada criterio de conformidad, es decir, si se

implementan, se logra el criterio de conformidad relacionado.



Además de las técnicas suficientes, hay varias técnicas recomendadas (del inglés,

advisory techniques), que mejoran la accesibilidad pero que no son suficientes para lograr

todos los aspectos de un criterio de conformidad. Además, estas técnicas no son

verificables porque pueden ser buenas y efectivas en algunas circunstancias, pero no en

todos los casos.

El uso de las técnicas proporcionadas en este documento facilita que el contenido web sea

conforme con los criterios de conformidad de las WCAG 2.0. Pero estas técnicas no son

obligatorias, además de las técnicas proporcionadas en el documento del W3C pueden

existir otras que puedan ser usadas para la implementación de la conformidad de las

WCAG 2.0. El grupo de trabajo de las WCAG anima a que esas técnicas sean remitidas para

considerar su inclusión en este documento.

En este documento también se mencionan los fallos más comunes para algunos criterios

de conformidad. Estos fallos son ejemplos de implementaciones en tecnologías específicas

que no cumplen los requisitos del criterio de conformidad en cuestión.

Lo que se pretende mostrar con estos fallos es qué hábitos de implementación en

tecnologías como HTML o CSS no son los correctos y crean problemas a personas con

discapacidades diversas.

2.6.3. Guía “How to meet WCAG 2.0”

El documento “Cómo satisfacer las WCAG 2.0” (del inglés, How to meet WCAG 2.0) es una

guía rápida de los requisitos de las WCAG 2.0 (criterios de conformidad) y sus técnicas. En

él se listan todos los criterios de conformidad de las WCAG 2.0 y las técnicas para

alcanzarlos con enlaces a información más detallada. Estos enlaces se dirigen a

descripciones, ejemplos y recursos de las técnicas. La guía es un documento dinámico y

permite al usuario seleccionar los contenidos que se desea que muestre la guía según las

necesidades del proyecto que se esté desarrollando [W3C, 2008c].

2.6.4. Sección “Conformance”

Esta sección lista los requisitos para alcanzar la conformidad con las WCAG 2.0. Además,

proporciona información sobre cómo realizar la afirmación de conformidad, la cual no es

obligatoria [W3C, 2008d].

Ser conforme con un estándar significa que se alcanzan o satisfacen los requisitos del

mismo. Para las WCAG 2.0 los requisitos son los criterios de conformidad. Por tanto, para

ser conforme con las WCAG 2.0 es necesario satisfacer sus criterios de conformidad, es

decir que ningún contenido viole ninguno de los criterios de conformidad.

Muchos estándares sólo tienen un nivel de conformidad. Con el fin de acomodarse a

diferentes situaciones de accesibilidad, WCAG 2.0 presenta tres niveles de conformidad y

por tanto tres niveles de criterios.



Hay cinco requisitos que deben cumplirse para lograr la conformidad con las WCAG 2.0.

Estos requisitos se listan a continuación.

Requisito 1: Nivel de conformidad

Este requisito está relacionado con los niveles de conformidad.

Este criterio viene a decir que una página web debe cumplir en su totalidad alguno de los

siguientes niveles de conformidad:

Nivel A: Para un nivel A de conformidad (nivel mínimo), la página web cumple

todos los criterios de conformidad de nivel A, o bien se proporciona una versión

alternativa que cumpla este nivel.

Nivel AA: Para un nivel AA de conformidad, la página web cumple todos los

criterios de conformidad de nivel A y AA, o bien se proporciona una versión


Nivel AAA: Para un nivel AAA de conformidad, la página web cumple todos los

criterios de conformidad de nivel A, AA y AAA, o bien se proporciona una versión


Requisito 2: Páginas completas

Este requisito habla de la conformidad para toda una página, sin excluir ninguna sección

de ésta. No pueden hacerse afirmaciones sobre la conformidad de parte de una página.

Las páginas web han de ser conformes en su totalidad y no se pueden excluir partes de las

mismas. Las alternativas a parte del contenido de la página se consideran parte de la

página cuando estas alternativas se pueden obtener directamente a partir de la propia

página.

Por ejemplo, con el atributo longdesc del elemento <img> se puede enlazar a otra página

que contiene la descripción larga de una imagen. A la hora de cumplir este requisito, la

página con la imagen y la página con la descripción larga se consideran de forma conjunta

como una única página. Por otra parte, las alternativas también pueden estar incluidas en

la misma página, como puede ser el caso de una transcripción textual de un video.

Requisito 3: Procesos completos

Este requisito hace referencia al conjunto de páginas web que son parte de un proceso.

Todas estas páginas deben ser conformes al mismo nivel de conformidad no pudiendo ser

considerado el proceso conforme si alguna de las páginas no lo es. Para procesos no es

válida la conformidad parcial porque alguna de las páginas no cumple la conformidad.



Requisito 4: Uso de tecnologías de manera accesible

Deben usarse tecnologías de manera que sean soportadas por las tecnologías de apoyo de

los usuarios. En caso de no lograrse, debe proporcionarse una alternativa que sí que lo sea.

Para cumplir los criterios de conformidad sólo se depende de usos accesibles de la

tecnología. Cualquier información o funcionalidad que se proporcione de forma que no sea

compatible con la accesibilidad debe estar disponible también de forma que sí sea

compatible con la accesibilidad. Se considera que se depende de una tecnología si el

contenido podría no ser accesible cuando dicha tecnología está desactivada o no se

soporta.

Este requisito permite utilizar tecnologías usadas de forma no accesible siempre y cuando

no se dependa de ellas. Es decir, la página web puede ser conforme si existen alternativas

accesibles para el contenido que se incluye con tecnologías no accesibles o utilizadas de

forma no accesible.

En resumen, este requisito dice que el contenido y la funcionalidad sólo deben depender

de tecnologías accesibles usadas de forma accesible. Si se usa alguna tecnología de forma

no accesible entonces ha de proporcionarse la misma información y funcionalidad

mediante una alternativa accesible.

Requisito 5: Sin interferencias

Este requisito dice que las tecnologías que no tienen soporte accesible pueden usarse

siempre y cuando toda la información esté también disponible usando tecnologías que

tienen soporte accesible y el material no soportado no interfiere.

Si las tecnologías se usan de forma no compatible con la accesibilidad entonces no pueden

impedir la capacidad de los usuarios para acceder al resto de la página. Además, la página

web en su totalidad debe continuar siendo conforme cuando cualquier tecnología de la

que no se depende está activada en los agentes de usuario así como cuando esté

desactivada o no se soporte.

Es decir, se pueden usar tecnologías no accesibles siempre y cuando toda la información

también esté disponible usando tecnologías accesibles y el contenido no accesible no

interfiere con el resto.

2.7. Diferencias entre las WCAG 2.0 y las WCAG 1.0

Hasta ahora se ha visto qué son las WCAG, se ha comentado que existen dos versiones de

estas pautas y se ha hecho una breve introducción a las WCAG 2.0 y su material de soporte.

Pero no se ha comentado cuáles son las diferencias entre las dos versiones, diferencias que



es importante conocer para poder saber el impacto que podría tener el desarrollo del sitio

web cumpliendo las WCAG 2.0 y seguir cumpliendo las WCAG 1.0, ya que la ley vigente en

la actualidad obliga a cumplir la norma UNE 139803:2004 [AENOR, 2004] (equivalente a

las WCAG 1.0) con un nivel de prioridad 2.

A lo largo del documento se ha hecho hincapié en la ventaja más favorable de las WCAG 2.0

frente a las WCAG 1.0. La evaluación de los requisitos de las WCAG 2.0 es más objetiva con

herramientas de evaluación automática y con evaluaciones humanas. Debería desaparecer

así la ambigüedad en la interpretación de las WCAG 1.0. Además, las WCAG 2.0 son

independientes de tecnologías y no están centradas únicamente en HTML + CSS.

Para poder llevar a cabo una comparación más precisa de unas y otras se recuerda la

estructura de ambas:

Las WCAG 1.0 están organizadas en 14 pautas que tienen puntos de verificación

que son de prioridad 1, prioridad 2 o prioridad 3 (hay un total de 65). La base para

poder determinar la conformidad con las WCAG 1.0 es el cumplimiento de los

puntos de verificación.

Las WCAG 2.0 están organizadas alrededor de 4 principios de accesibilidad web.

Cada principio tiene pautas (hay 12) y cada una de estas pautas tiene criterios de

conformidad verificables de nivel A, AA o AAA (hay un total de 61). La base para

determinar la conformidad con las WCAG 2.0 es la verificación de los criterios de

conformidad.

Por tanto, una comparación entre ambas se hará en función de los puntos de verificación

de una y los criterios de conformidad de la otra. [Lawton, 2009]

Un primer ejemplo de la comparación es que en las WCAG 2.0 un mismo requisito técnico

puede cubrirse por más de un criterio de conformidad pero con diferentes niveles de

exigencia. Por ejemplo, el contraste de color entre el primer y el segundo plano en los

textos se cubre por dos criterios de conformidad:

Nivel AA: La presentación visual de texto o de imágenes de texto tiene un ratio de

contraste de al menos 4.5:1…

Nivel AAA: La presentación visual de texto y de imágenes de texto tiene un ratio de

contraste de al menos 7:1…

Esto no pasaba en las WCAG 1.0, ya que un requisito se cubría con un punto de verificación

que tenía una prioridad (a veces varios niveles de prioridad en función del tipo de

contenido):

2.2. Asegúrese de que el primer plano y el fondo tienen una combinación de

colores que proporciona suficiente contraste cuando es visto por alguien con



deficiencias de color o cuando es visto en una pantalla en blanco y negro.

(Prioridad 2 para imágenes. Prioridad 3 para texto)

Otra diferencia importante es la referente al material de soporte de ambas versiones. En

las WCAG 1.0 se incluían breves descripciones bajo cada pauta en el documento principal

de las WCAG. La mayor parte de los ejemplos que se incluían eran sobre contenido HTML.

Por el contrario en las WCAG 2.0 las pautas son independientes de la tecnología y los

criterios de conformidad no tienen descripciones adicionales dentro del documento

principal. Las descripciones están en los documentos de soporte Understanding WCAG 2.0

y Techniques for WCAG 2.0 comentado en el apartado anterior.

Como se comentó anteriormente, para comparar las dos versiones de las WCAG es

necesario hacerlo desde la base que determina el nivel de accesibilidad de un sitio web: los

puntos de verificación para las WCAG 1.0 y los criterios de conformidad para las WCAG

2.0. En la Tabla 2 se compara la versión en español de las WCAG 1.0 (que aparece en la

norma española UNE 139803:2004, [AENOR, 2004]) con las WCAG 2.0. La Tabla 3 muestra

nuevos requisitos que se contemplan en las WCAG 2.0 y que han originado criterios de

conformidad relacionados. [EOWG, 2008]

WCAG 1.0 Correspondencia con WCAG 2.0

Pto Nivel Descripción Descripción de la correspondencia

1.1 A

“Proporcione un texto equivalente para todo elemento no textual (p. ej. a través de de los atributos alt, longdesc o en el contenido del elemento)”.

1.1.1 Non-text Content (A) 1.2.1 Audio-only and Video-only (Prerecorded) (A) 1.2.9 Audio-only (Live) (AAA) Conformance requirement 1 Conformance requirement 4 Images used as bullets are also covered in Guideline 1.3 with regard to CSS usage. For framesets, noframes is no longer required. For multimedia, alternatives (beyond labels) are covered under Guideline 1.2.

1.2 A “Proporcione enlaces redundantes en formato texto para cada área activa de un mapa de imagen del servidor”

1.1.1 Non-text Content (A) 2.1.1 Keyboard (A) 2.4.4 Link Purpose (In Context) (A) Server-side image maps are not keyboard accessible.

1.3 A

“Hasta que las aplicaciones de usuario puedan leer en voz alta, automáticamente, el texto equivalente de la pista visual de una presentación multimedia; proporcione una descripción sonora de la información importante de la pista visual”

1.2.3 Audio Description or Media Alternative (Prerecorded) (A) 1.2.5 Audio Description (Prerecorded) (AA) 1.2.7 Extended Audio Description (Prerecorded) (AAA)

1.4 A

“Sincronice con la presentación equivalentes alternativos (p. ej. subtítulos o descripciones sonoras de la pista visual) para cualquier presentación multimedia tempo-dependiente (p. ej. una película o animación)”

1.2.2 Captions (Prerecorded) (A) 1.2.3 Audio Description or Media Alternative (Prerecorded) (A) 1.2.4 Captions (Live) (AA) 1.2.5 Audio Description (Prerecorded) (AA) 1.2.7 Extended Audio Description (Prerecorded) (AAA)



1.5 AA

“Hasta que las aplicaciones de usuario interpreten los textos equivalentes de los enlaces de los mapas de imagen de tipo cliente, proporcione enlaces redundantes, en formato texto, para cada zona activa del mapa de imagen de tipo cliente”

Las aplicaciones de usuario ya lo hacen. No hay criterio de conformidad equivalente.

2.1 A

“Asegúrese de que toda la información transmitida a través del color está también disponible sin color, por ejemplo mediante el contexto o el marcado”

1.4.1 Use of Color (A)

2.2 AA, AAA

“Asegúrese de que las combinaciones de color del fondo y del primer plano contrastan lo suficiente cuando son vistas por alguien que tiene una deficiencia de percepción del color o que utiliza un monitor en blanco y negro”

1.4.3 Contrast (Minimum) (AA) 1.4.6 Contrast (Enhanced) (AAA)

3.1 AA “Utilice marcadores en vez de imágenes para transmitir información, si existe un lenguaje de marcado apropiado”

1.4.5 Images of Text (AA) 1.4.9 Images of Text (No Exception) (AAA)Conformance Requirement 4

3.2 AA “Cree documentos que se ciñan a las gramáticas formales publicadas”

4.1.1 Parsing (A) Nota: la validación con gramáticas formales publicadas es más exigente que lo que se necesita para cumplir el criterio 4.1.1, pero la validación es una técnica suficiente para cumplirlo.

3.3 AA “Use hojas de estilo para controlar la disposición y la presentación”

Este criterio se corresponde con varias técnicas suficientes y recomendadas relacionadas con los criterios de conformidad 1.3.1 (A), 1.3.2 (A), 1.4.1 (A), 1.4.4 (AA), 1.4.5 (AA), 2.4.7 (AA), 1.4.8 (AAA), y 1.4.9 (AAA). No hay una correspondencia directa.

3.4 AA

“Use unidades relativas en vez de absolutas en los valores de los atributos del lenguaje de marcado y en los valores de las propiedades de las hojas de estilo”

1.4.4 Resize text (AA) Nota: algunos aspectos de este criterio de conformidad también están relacionados con el criterio 1.4.8 (AAA).

3.5 AA “Use elementos de encabezado para sugerir la estructura del documento y úselos siguiendo la especificación”

1.3.1 Info and Relationships (A) 2.4.10 Section Headings (AAA)

3.6 AA “Marque correctamente las listas y los ítem de lista”

1.3.1 Info and Relationships (A) Técnica H48: Using ol, ul and dl for lists

3.7 AA “Marque las citas. No use el marcado de citas para efectos de formato tales como la sangría”

1.3.1 Info and Relationships (A) Fallo F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content

4.1 A

“Identifique claramente los cambios en el lenguaje natural del texto de un documento y de cualquier texto equivalente (p. ej. leyendas)”

3.1.2 Language of Parts (AA)

4.2 AAA “Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento”

3.1.4 Abbreviations (AAA)

4.3 AAA “Identifique el lenguaje natural principal de un documento”

3.1.1 Language of Page (A)



5.1 A “En las tablas de datos, identifique los encabezados de fila y columna”

1.3.1 Info and Relationships (A) Técnica H51: Using table markup to present tabular information Técnica H63: Using the scope attribute to associate header cells and data cells in data tables

5.2 A

“Para las tablas de datos que tengan dos o más niveles lógicos de encabezados de fila o columna, utilice marcadores para asociar las celdas de datos con las celdas de encabezado”

1.3.1 Info and Relationships (A) Técnica H43: Using id and headers attributes to associate data cells with header cells in data tables

5.3 AA

“No use tablas para maquetar, a menos que el contenido de la tabla tenga sentido cuando se represente en forma lineal. De lo contrario, si la tabla no se entiende, proporcione un equivalente alternativo (que puede ser una versión lineal del contenido de la tabla)”

1.3.2 Meaningful Sequence (A)

5.4 AA “Si utiliza una tabla para maquetar, no utilice ningún marcado estructural para conseguir un efecto visual de formateo”

1.3.1 Info and Relationships (A) Fallo F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content.

5.5 AAA “Proporcione resúmenes de las tablas” No existe un criterio de conformidad. Sin embargo, en las tablas de layout, el atributo summary debe ser vacío u omitirse. Fallo F43 del criterio 1.3.1

5.6 AAA “Proporcione abreviaturas para las etiquetas de los encabezamientos”

No existe un criterio de conformidad, pero es una técnica potencialmente útil.

6.1 A “Organice los documentos de forma que puedan ser leídos sin hojas de estilo”

Conformance Requirement 4 Conformance Requirement 5

6.2 A “Asegúrese de que los equivalentes para el contenido dinámico se actualizan cuando cambia el contenido dinámico”

Fallo F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur

6.3 A

“Asegúrese de que las páginas pueden seguir siendo usadas cuando los scripts, applets u otros objetos de programación se desconectan o no son soportados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible”

Conformance Requirement 1 Conformance Requirement 4 Conformance Requirement 5 1.4.2 - Audio Control (A) 2.1.2 - No Keyboard Trap (A) 2.3.1 - Three Flashes or Below Threshold (A) 2.2.2 - Pause, Stop, Hide. (A)

6.4 AA “Para los scripts y applets, asegúrese de que la ejecución de los manejadores de evento sea independiente del tipo de dispositivo”

2.1.1 Keyboard (A) 2.1.3 Keyboard (No Exception) (AAA) Additional Notes: Device-independent event handlers are not explicitly required.

6.5 AA "Asegúrese de que los contenidos dinámicos sean accesibles o proporcione una página o presentación alternativas”

Conformance Requirement 1 Conformance Requirement 4

7.1 A “Hasta que las aplicaciones de usuario permitan al usuario controlarlo, evite provocar el parpadeode la pantalla”

2.3.1 Three Flashes or Below Threshold (A) 2.3.2 Three Flashes (AAA)

7.2 AA

“Hasta que las aplicaciones de usuario permitan al usuario controlar el destello, evite que el contenido destelle(por ejemplo, los cambios en la presentación a ritmo regular, como si se encendiera y apagase)”

2.2.2 Pause, Stop, Hide (A)



7.3 AA

“Hasta que las aplicaciones de usuario permitan congelar el contenido en movimiento, evite el movimiento en las páginas”

La clausula “hasta que las aplicaciones de usuario” ya se cumple. Por tanto, no es necesario evitar todo tipo de movimientos, siempre que los autores no interfieran en la habilidad del usuario para pausar dicho movimiento. Sustituido por el criterio de conformidad 2.2.2

7.4 AA

“Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el refresco, no cree páginas que periódicamente se auto-refresquen”

2.2.1 Timing Adjustable (A) 2.2.4 Interruptions (AAA) 3.2.5 Change on Request (AAA) Técnica G76: Providing a mechanism to request an update of the content instead of updating automatically

7.5 AA

“Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el re-direccionamiento automático, no utilice marcadores para redirigir las páginas automáticamente. En su lugar, configure el servidor llevar a cabo los re-direccionamientos”

2.2.1 Timing Adjustable (A) 3.2.5 Change on Request (AAA) Técnica SVR1: Implementing automatic redirects on the server side instead of on the client side Técnica G110: Using an instant client-side redirect

8.1 A

“Cree los elementos de programación tales como scriptsy applets de manera que sean directamente accesibles o compatibles con las ayudas técnicas”

4.1.2 Name, Role, Value (A) Conformance Requirement 1 Conformance Requirement 4 Conformance Requirement 5

9.1 A

“Proporcione mapas de imagen controladas por el cliente en vez de por el servidor, excepto cuando las áreas no puedan ser definidas con una forma geométrica”

1.1.1 Non-text Content (A) 2.1.1 Keyboard (A)

9.2 AA

“Asegúrese de que cualquier elemento que tenga su propia interfaz pueda manejarse de forma independiente del tipo de dispositivo”

2.1.1 Keyboard (A) 2.1.3 Keyboard (No Exception) (AAA)

9.3 AA “Para los scripts, especifique manejadores de evento lógicos en vez de manejadores de evento dependientes del dispositivo”

2.1.1 Keyboard (A) 2.1.3 Keyboard (No Exception) (AAA)

9.4 AAA “Cree un orden lógico de tabulación a través de los enlaces, controles de formulario y objetos”

2.4.3 Focus Order (A)

9.5 AAA

“Proporcione atajos de teclado para los enlaces importantes (incluyendo los de los mapas de imagen de tipo cliente), controles de formulario y grupos de controles de formulario”

Los atajos de teclado no se exigen para lograr la conformidad con las WCAG 2.0, pero son una técnica recomendada del criterio 2.4.1 (A)

10.1 AA

“Hasta que las aplicaciones de usuario permitan a los usuarios desactivar la generación de ventanas, no provoque que aparezcan llamadas emergentes u otras ventanas y no cambie el foco de la ventana actual sin informar antes al usuario”

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (A) 3.2.2 On Input (A) 3.2.5 Change on Request (AAA) TécnicaH83: Using the target attribute to open a new window on user request and indicating this in link text Técnica SCR24: Using progressive enhancement to open new windows on user request



10.2 AA

“Hasta que las aplicaciones de usuario soporten asociaciones explícitas entre las etiquetas y los controles de formulario, para todos los controles de formulario con etiquetas implícitamente asociadas, asegúrese de que la etiqueta está colocada adecuadamente”

Ahora las aplicaciones de usuario soportan la asociación explícita de etiquetas con controles de formularios.

10.3 AAA

“Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) interpreten correctamente los textos contiguos, proporcione un texto alternativo lineal(en la misma página o en alguna otra) para todas las tablas que presenten el texto en columnas paralelas, y desplazan el texto automáticamente a la siguiente línea cuando no cabe en la misma”

La clausula “hasta que las aplicaciones de usuario” se ha satisfecho. Este criterio ya no es necesario en las WCAG 2.0

10.4 AAA

“Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por omisión en los campos de edición y áreas de texto”

La clausula “hasta que las aplicaciones de usuario” se ha satisfecho. Este criterio ya no es necesario en las WCAG 2.0.

10.5 AAA

“Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) representen de forma diferenciada los enlaces adyacentes, incluya caracteres imprimibles no enlazados(rodeados de espacios) entre los enlaces adyacentes”

Esta técnica ya no es necesaria para las aplicaciones de usuario, pero sí es útil para personas con discapacidades.

11.1 AA

“Utilice las tecnologías del W3C cuando estén disponibles y sean apropiadas para la tarea, y use las últimas versiones en cuanto sean soportadas”

Esto ya no es necesario para las WCAG 2.0.

11.2 AA “Evite usar elementos obsoletos de las tecnologías del W3C”

Este punto ya no es necesario en las WCAG 2.0

11.3 AAA

“Proporcione información de manera que los usuarios puedan recibir los documentos según sus preferencias (p. ej. idioma, tipo de contenido...)”

Este punto de verificación no tiene correspondencia en las WCAG 2.0. Sin embargo, técnicas de algunos criterios de conformidad refieren algo similar.

11.4 A

“Si, a pesar de haberse esforzado, no consigue crear una página accesible, proporcione un enlace a una página alternativa que use las tecnologías del W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible”

Conformance Requirement 1

12.1 A “Titule cada marco para facilitar la identificación del marco y la navegación entre ellos”

2.4.1 Bypass Blocks (A) 4.1.2 Name, Role, Value (A)

12.2 AA “Describa el propósito de los marcos y cómo se relacionan entre sí, si no resulta obvio sólo con los títulos de marco”

Este criterio ya no es necesario para lograr la conformidad con las WCAG 2.0

12.3 AA “Divida los bloques de información largos en grupos más manejables cuando resulte natural y apropiado”

2.4.10 Section Headings (AAA)



12.4 AA “Asocie etiquetas explícitamente con sus controles”

1.3.1 Info and Relationships (A) 4.1.2 Name, Role, Value (A) Técnica H44: Using label elements to associate text labels with form controls

13.1 AA “Identifique claramente el objetivo de cada enlace”

2.4.4 Link Purpose (In Context) (A) 2.4.9 Link Purpose (Link Only) (AAA)

13.2 AA “Proporcione metadatos para añadir información semántica a las páginas y los sitios”

Este criterio ya no es necesario para lograr la conformidad con las WCAG 2.0

13.3 AA

“Proporcione información sobre la maquetación general de un sitio(por ejemplo, un mapa del sitio o tabla de contenidos)”

2.4.5 Multiple Ways (AA) Técnica G63: Providing a site map.

13.4 AA “Utilice mecanismos de navegación de manera consistente”

3.2.3 Consistent Navigation (AA) 3.2.4 Consistent Identification (AA) 2.4.10 Section Headings (AAA)

13.5 AAA “Proporcione barras de navegación para resaltar y dar acceso al mecanismo de navegación”

Este punto de verificación no tiene correspondencia con ningún criterio de conformidad de las WCAG 2.0

13.6 AAA

“Agrupe los enlaces relacionados, identificando el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de saltarse el grupo”

1.3.1 Info and Relationships (A) 2.4.1 Bypass Blocks (A)

13.7 AAA “Si proporciona funciones de búsqueda, facilite diferentes tipos de búsquedas para diversos niveles de habilidad y preferencias”

Este punto de verificación no tiene correspondencia con ningún criterio de conformidad de las WCAG 2.0Algunos aspectos se pueden relacionar con los criterios de conformidad: 2.4.2 (AA), 2.4.5 (AA), 3.3.3 (AA), 3.3.5 (AAA)

13.8 AAA “Coloque información distintiva al comienzo de encabezados, párrafos, listas, etc.”

Este punto de verificación no es requerido por ningún criterio de conformidad de las WCAG 2.0. Parcialmente se corresponde con una técnica recomendada del criterio 2.4.6 (AA)

13.9 AAA

“Proporcione información sobre las colecciones de documentos(por ejemplo, los documentos que comprendan múltiples páginas)”

No hay una correspondencia directa con ningún criterio de conformidad, parcialmente con el criterio 2.4.8 (AAA)

13.10 AAA “Proporcione un medio para saltar sobre un arte ASCII que ocupa varias líneas”

Se cubre con el criterio de conformidad 1.1.1 (A)

14.1 A “Utilice el lenguaje más claro y sencillo que sea apropiado para el contenido de un sitio”

No hay una correspondencia directa con ningún criterio de conformidad. Alguna técnica recomendada de la pauta 3.1 puede corresponderse.

14.2 AAA “Complemente el texto con presentaciones gráficas o sonoras cuando ello facilite la comprensión de la página”

Técnica G79: Providing a spoken version of the text Técnica G103: Providing visual illustrations, pictures, and symbols to help explain ideas, events, and processes

14.3 AAA “Cree un estilo de presentación que sea consistente en todas las páginas”

Aspectos de los criterios de conformidad: 3.2.3 (AA) y 3.2.4 (AA)

Tabla 2: Comparación entre los puntos de verificación de las WCAG 1.0 y los criterios de conformidad de las WCAG 2.0



La tabla que aparece a continuación muestra los requisitos que son nuevos en las WCAG

2.0 y que no se contemplan en las WCAG 1.0

Criterio de conformidad

Prioridad Título

1.2.6 Level AAA Sign Language (Prerecorded)

1.2.8 Level AAA Media Alternative (Prerecorded)

1.3.3 Level A Sensory Characteristics

1.4.2 Level A Audio Control

1.4.7 Level AAA Low or No Background Audio

1.4.8 Level AAA Visual Presentation

2.1.2 Level A No Keyboard Trap

2.2.3 Level AAA No Timing

2.2.5 Level AAA Re-authenticating

2.4.2 Level A Page Titled

2.4.6 Level AA Headings and Labels

2.4.7 Level AA Focus Visible

2.4.8 Level AAA Location

3.1.3 Level AAA Unusual Words

3.1.6 Level AAA Pronunciation

3.3.1 Level A Error Identification

3.3.2 Level A Labels or Instructions

3.3.3 Level AA Error Suggestion

3.3.4 Level AA Error Prevention (Legal, Financial, Data)

3.3.5 Level AAA Help: Context-sensitive help is available

3.3.6 Level AAA Error Prevention (All)

Tabla 3: Requisitos nuevos en las WCAG 2.0

2.8. ¿Qué es la usabilidad web?

En el ámbito del diseño web se puede aplicar la definición de Jakob Nielsen [Nielsen, 2003]

quien definió la usabilidad como:

“Un atributo de calidad que mide lo fáciles de usar que son las interfaces web”

Es decir, un sitio web usable es aquél en el que los usuarios pueden interactuar de la forma

más fácil, cómoda, segura e inteligentemente posible.

En general, se puede decir que la usabilidad quedaría definida por cinco componentes de

calidad:

Fácil de aprender: ¿Cómo de fácil es para los usuarios llevar a cabo tareas básicas

la primera vez que se encuentran con el diseño?

Eficiencia: Una vez que los usuarios han aprendido el diseño, ¿cómo de rápido

realizan las tareas?

Memorizable: Cuando los usuarios retoman el diseño tras un periodo sin usarlo,

¿cómo de fácil pueden retomar el grado de conocimiento que alcanzaron?

Errores: ¿Cuántos errores comete el usuario?, ¿cómo de graves son? y ¿cómo de

fácil es recuperarse de un error?



Satisfacción: ¿Cómo de agradable es usar el diseño?

Existen otros muchos atributos de calidad. Uno clave es la utilidad, que se refiere a la

funcionalidad del diseño: ¿el producto hace lo que el usuario necesita? La usabilidad y la

utilidad son igualmente importantes: algo fácil de usar es poco importante si no es lo que

queremos. Incluso no es bueno si el sistema puede hacer hipotéticamente lo que

queremos, pero no podemos lograrlo porque la interfaz de usuario es demasiado

complicada. [Nielsen, 2003]

La usabilidad de un sitio web está determinada por sus contenidos, cuanto más cercanos

sean al usuario, mejor es la navegación por el mismo y más acertada será la experiencia al

enfrentarse a la pantalla.

Lógicamente es imposible crear un sitio web cien por cien perfecto y en óptimas

condiciones, pues no se puede agradar al mismo tiempo a millones de usuarios, sin

embargo, los diseñadores y creadores deben tratar de mostrar todos los elementos de una

manera clara y concisa, minimizando el número de clics y de desplazamientos (scroll).

En ocasiones los usuarios se enfrentan a sitios webs de altísima calidad y contenido, pero

que presentan dificultades en su navegación. Por ejemplo, menús que están en una

ubicación difícil de encontrar, o cuando la herramienta de búsqueda no aparece en un

lugar visible.

La usabilidad depende en cierta forma del espacio donde se desenvuelve el usuario. Pero

lo importante en este caso es que éste no se deje consumir ni dominar por el sitio, es decir

que sea él mismo el que tome el control de la navegación por medio de un aprendizaje

sencillo y el dominio de los elementos necesarios, para encontrar finalmente y en el menor

tiempo posible, lo que busca. [Nielsen, 2000]

2.9. ¿Por qué es importante la usabilidad web?

La usabilidad es una condición necesaria para la supervivencia de una web. Si un sitio web

presenta dificultades para usarse, el usuario la abandonará. Si la página de inicio (del

inglés, homepage) no muestra a qué se dedica la compañía y qué puede encontrar el

usuario en ella, éste también la abandonará. Si un usuario se siente perdido en el sitio web,

sale de él. Si la información es difícil de leer o de encontrar y no responde a las preguntas

del usuario, pasará más de lo mismo. La primera regla del comercio electrónico es que si

un usuario no puede encontrar un producto, éste no podrá comprarlo.

Para las intranets, la usabilidad es un problema de productividad de los empleados. El

tiempo que gasta un empleado estando perdido o intentando entender instrucciones

imposibles es dinero que se está gastando la empresa en pagar al empleado por estar en el

trabajo sin que llegue a realizar su tarea [Nielsen, 2003].



Hay que tener en cuenta que los beneficios de hacer sitios web usables son grandes. Entre

ellos destacan:

Reducción de los costes de aprendizaje. Cuanto más cercano a los estándares

comúnmente aceptados en la web, más familiar será el sitio para el usuario y por

tanto menos le costará aprender a utilizarlo y navegar por él.

Disminución de los costes de asistencia y ayuda al usuario. Si la información es

fácil de encontrar y el sitio se estructura de manera simple y clara, el usuario podrá

lograr sus objetivos y no necesitará asistencia. llegar a ella, no necesitará ayuda.

Disminución en la tasa de errores cometidos por el usuario. Uno de los atributos

cuantificables de manera objetiva es la tasa de errores que un usuario comete al

realizar una tarea. Esta tasa mide la eficacia del sitio web.

Optimización de los costes de diseño, rediseño y mantenimiento. Se deben seguir

unos estándares internos dentro del sitio web, además de los externos

comúnmente aceptados. De esta manera, existirá una consistencia entre las

diferentes páginas del sitio, lo que ayudará a ahorrar costes en el diseño y una

posterior optimización de los costes en el rediseño y mantenimiento.

Aumento de la tasa de conversión de visitantes a clientes de un sitio web. Siempre

que la experiencia del usuario sea positiva, estos serán potenciales clientes del

sitio web.

Aumento de la satisfacción y comodidad del usuario. Este aspecto está nuevamente

ligado a la experiencia del usuario.

Mejora la imagen y el prestigio. Si los usuarios salen contentos del sitio web, la

imagen del mismo se verá realzada. Esto se consigue gracias a que el usuario

pueda lograr sus objetivos.

Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la

satisfacción y la productividad. En esto tienen mucho que ver la eficacia y la

eficiencia del sitio web. Reduciendo la tasa de fallos que comete un usuario se

mejora la eficacia y reduciendo el tiempo que necesita emplear un usuario para

lograr una tarea se mejora la eficiencia. Por otro lado, la satisfacción de uso sólo se

puede conocer interrogando al usuario.

Todos estos beneficios implican una reducción y optimización general de los costes de producción, así como un aumento en la productividad. La usabilidad permite mayor rapidez en la realización de tareas y reduce las pérdidas de tiempo.

2.10. Cómo implementar y medir la usabilidad web

Es fácil inferir que un buen diseño deberá ser comprensible, fácil de usar, amigable, claro,

intuitivo y de fácil aprendizaje para el usuario. Para poder asegurar que un diseño cumple

con estos requisitos no basta simplemente con una actitud empática del diseñador durante

el desarrollo de la aplicación; es imprescindible la adopción por parte de éste de técnicas,



procedimientos y métodos que aseguren empíricamente la adecuación del diseño a las

necesidades, habilidades y objetivos del usuario. [Hassan et al, 2004b]

Estas técnicas y procedimientos vienen dadas por el marco metodológico conocido como

Diseño Centrado en el Usuario. Aunque no es la metodología de diseño que se va a seguir

en este Trabajo, es necesario conocerla para poder comprender algunas de las técnicas y

disciplinas de las que sí se habla a lo largo del mismo como la Arquitectura de la

información.

2.10.1. Arquitectura de la información

Aunque para la mayoría de los usuarios "la interfaz es la aplicación" puesto que es la parte

que ven y a través de la cual interactúan [Hartson, 1998], se debe entender que la

usabilidad de la aplicación no depende sólo del diseño de ésta, sino también de su

arquitectura - estructura y organización -, en otras palabras, del componente no visible del

diseño. [Hassan et al, 2004b]

Para el enfoque del diseño web, que es el que ocupa a este Trabajo existe una disciplina

que ha cobrado cierta importancia en los últimos años, la arquitectura de la información

(AI), que se define como el arte y la ciencia de organizar espacios de información con el fin

de ayudar a los usuarios a satisfacer sus necesidades de información. La actividad de

organizar comporta la estructuración, clasificación y rotulado de los contenidos del sitio

web [Toub, 2000].

Existe gran cantidad de documentación sobre esta disciplina, pero se puede resaltar el

aspecto más importante de ésta para algunos autores especializados en temas de

usabilidad.

La Recuperación de la Información: El objetivo principal de definir una arquitectura de

información correcta es facilitar al usuario la recuperación de información. Esto se

consigue por un lado posibilitando que el usuario pueda encontrar información -diseño y

definición de índices, clasificaciones, taxonomías y sistemas de recuperación de

información o sistemas de búsqueda en el sitio web-, y por otro lado posibilitando que

cada elemento de información pueda ser encontrado -descripción a través de metadatos y

optimización del sitio para buscadores-. Este segundo caso es lo que se denomina

"encontrabilidad" (del inglés, findability), o visibilidad. [Hassan et al, 2004b]

La tarea de clasificar se define como la actividad de agrupar los elementos de información

de acuerdo a atributos o propiedades comunes entre ellos. Por tanto, definir un sistema de

clasificación es elegir en base a qué atributos se van a agrupar los contenidos y cómo se

van a organizar estos atributos. Atendiendo a la tipología de sistemas de clasificación

presentada por Rosenfeld y Morville en su libro "Information Architecture for the Word

Wide Web", se distingue entre sistemas exactos y ambiguos.



Los sistemas exactos son los que agrupan los contenidos en secciones perfectamente

definidas y diferenciadas del resto. Son útiles cuando el usuario va a realizar una búsqueda

o navegación por "elementos conocidos". Por ejemplo, cuando busca un número de

teléfono en una guía telefónica, porque conoce el nombre de la persona. Cuando busca una

definición en un diccionario, conoce el término. Cuando busca en su agenda qué reuniones

o tareas tiene programadas, conoce la fecha. Existen tres sistemas de clasificación exactos:

alfabética, cronológica y geográfica.

Hay veces que el usuario no sabe exactamente lo que busca, y se dedica a realizar una

exploración o navegación por los contenidos de forma aleatoria o azarosa (navegación

"serendípica"). Otras, aunque sabe lo que busca, no es capaz de expresarlo con palabras,

por lo que no utilizará el buscador para encontrarlo.

En estos casos es necesario ofrecer al usuario una forma de acceder a los contenidos a

través de opciones o enlaces a priori no conocidos. El usuario, explorando visualmente

estas opciones, deberá poder intuir dónde encontrar aquellos contenidos de su interés.

Los sistemas de clasificación ambiguos organizan los contenidos en categorías no

definidas de forma exacta y precisa. Es el tipo de sistema de clasificación más común y útil

en sitios web, aunque tiene ciertas desventajas. Por un lado, la subjetividad de la

clasificación puede desorientar al usuario. Por otro, la propia ambigüedad del lenguaje

natural (polisemia, sinonimia,...) puede resultar una barrera para el usuario en el proceso

de búsqueda o exploración.

Seguidamente se presentan los tipos de clasificación más habituales:

Clasificación temática o por categorías: es la más útil de las clasificaciones. Se trata de

organizar los contenidos en categorías definidas en función de la temática de los

contenidos a clasificar.

Clasificación orientada a tareas: los elementos se organizan en función de las posibles

tareas que puede realizar el usuario a través del sitio web. Un ejemplo de clasificación

orientada a tareas es la que utilizan muchas aplicaciones software (abrir, guardar, cerrar,

imprimir...).

Clasificación orientada a la audiencia: cuando un sitio web tiene una audiencia

claramente definida, con intereses y necesidades diferentes, resulta de gran utilidad

clasificar los contenidos en secciones específicas y adaptadas a cada grupo o clase de

usuarios.

Clasificación metafórica: es un tipo de clasificación cuyo objetivo es hacer familiar,

comprensible e intuitivo aquello que es novedoso o desconocido para el usuario. El

ejemplo más famoso de metáfora es el de la "metáfora del escritorio", utilizada por los

sistemas operativos para familiarizar el usuario con el uso de directorios, ficheros y

aplicaciones: En el escritorio, las herramientas y contenidos se organizan en carpetas;



cuando un documento no es útil, se "tira" a la papelera de reciclaje; el escritorio tiene

incluso su propio ordenador, "Mi PC". [Hassan, et al, 2004]

2.10.2. Diseño centrado en el usuario

El enfoque metodológico “User-Centered Design” o Diseño Centrado en el Usuario que se

va a explicar a continuación está adaptado para el diseño web.

El Diseño Web Centrado en el Usuario se caracteriza por asumir que todo el proceso de

diseño y desarrollo del sitio web debe estar conducido por el usuario, sus necesidades,

características y objetivos. Centrar el diseño en sus usuarios (en oposición a centrarlo en

las posibilidades tecnológicas o en nosotros mismos como diseñadores) implica involucrar

desde el comienzo a los usuarios en el proceso de desarrollo del sitio; conocer cómo son,

qué necesitan, para qué usan el sitio; probar el sitio con los propios usuarios; investigar

cómo reaccionan ante el diseño, cómo es su experiencia de uso; e innovar siempre con el

objetivo claro de mejorar la experiencia del usuario. [Hassan et al, 2004b]

Figura 2: Esquema de las fases del Diseño Web Centrado en el Usuario

Yusef Hassan y Francisco Martínez dividen el proceso de Diseño Web Centrado en el

Usuario en varias fases que siguen el esquema representado en la Figura 2. Las fases de

"diseño", "prototipado" y "evaluación" son cíclicas e iterativas. Esto quiere decir que todo

lo que se diseñe debe ser constantemente evaluado a través de su prototipado, para así

poder corregir errores de usabilidad desde los primeros momentos del desarrollo. Evaluar

el sitio web únicamente una vez finalizado su desarrollo haría mucho más costosa la



reparación de errores de usabilidad, ya que siempre es más económico reconducir un

diseño que rediseñar completamente el sitio.

A continuación se comentan los aspectos más destacables de las fases más relevantes para

este Trabajo:

Diseño

o Modelado del usuario

o Diseño conceptual

o Definición del estilo

o Diseño visual

o Diseño de contenidos

Prototipado

o Prototipos de baja fidelidad

o Prototipos de alta fidelidad

Evaluación

Método de inspección

Método de test.

Modelado del usuario

Toda la información obtenida de los estudios de usuarios realizados en la anterior fase de

planificación debe servir como base para comenzar el diseño, pero para ello se debe

resumir y sintetizar dicha información.

Este paso se denomina modelado del usuario y consiste en la definición de clases o perfiles

de usuarios en base a atributos comunes. Los atributos sobre los que se hará la

clasificación dependen de la información que se tenga de la audiencia, pero normalmente

se tratarán de atributos tales como necesidades de información, condiciones de acceso,

experiencia y conocimientos.

Mediante esta técnica, el diseñador tendrá en mente para quién diseña, qué espera

encontrar el usuario y en qué forma. El diseño del sitio web debe estar orientado al

usuario, organizando y estructurando la información según los modelos definidos de

usuarios.

Diseño conceptual

Es en esta fase de la metodología donde entra el enfoque de la arquitectura de la

información. El objetivo de la fase de Diseño Conceptual es definir el esquema de

organización, funcionamiento y navegación del sitio. No se especifica qué apariencia va a

tener el sitio, sino que se centra en el concepto mismo del sitio, es decir su arquitectura de

información.



Los sitios web son sistemas hipermedia formados por conjuntos de páginas

interrelacionadas por enlaces unidireccionales. La "estructura" del sitio web se refiere

precisamente a las conexiones y relaciones entre páginas, a la topología de la red de

páginas, así como a la granularidad de los elementos de información contenidos en las

páginas; y la "navegación" a las posibilidades y forma en que cada página presenta las

opciones de desplazamiento hacia otras páginas.

Las estructuras más comunes desde una aproximación descendente – estructuración del

‘todo’ a las ‘partes’ – son:

Estructuras secuenciales: Los páginas se encuentran interrelacionadas de forma

lineal. Esta estructura se utiliza en tareas de navegación o interacción en las que es

necesario que el usuario complete cada uno de los pasos ordenadamente (carrito

de compra, registro como usuario,...) o para la segmentación de bloques de

información de naturaleza secuencial (artículos, comics, diapositivas...). Se trata de

un tipo de estructura muy sencilla por lo que no provoca desorientación alguna al

usuario en la navegación. En la Figura 3 se representa este tipo de estructuras.

Figura 3: diagrama de estructuras secuenciales

Estructuras hipertextuales: El hipertexto es la base sobre la que se asienta la

Web. En una estructura hipertextual las páginas se enlazan por similitud o relación

directa entre los contenidos, permitiendo al usuario que se encuentra visualizando

una página 'saltar' hacia otras que le puedan interesar por contener información

relacionada. Este tipo de estructura, si bien ofrece mayor libertad y

dinamismo a la navegación puede ocasionar desorientación, provocando

que el usuario se sienta 'perdido'. Además, en este tipo de estructuras hay que

tener precaución para que ninguna página quede excesivamente descolgada o de

difícil acceso. En la Figura 4 se representa este tipo de estructuras.

Figura 4: diagrama de estructuras hipertextuales

Estructuras jerárquicas: Probablemente la jerárquica es la estructura de

información más común en sitios web, debido en gran medida a su popularización

por grandes portales y directorios temáticos. La organización en forma de árbol,



por un lado resulta lo suficientemente flexible y escalable como para posibilitar la

organización de grandes cantidades de páginas, y por otro resulta muy orientativa

para el usuario en su navegación. Normalmente, las estructuras jerárquicas se

utilizan junto a las hipertextuales, permitiendo al usuario una vez llegado a una

página de una rama 'saltar' hacia páginas de otras ramas pero relacionadas

temáticamente con la página actual. En este tipo de estructuras hay que intentar

mantener un equilibrio entre ancho y profundidad de la jerarquía. Jerarquías muy

profundas pueden provocar que las páginas finales queden muy distanciadas de la

página origen, y por tanto de difícil recuperabilidad o encontrabilidad. Por otro

lado, jerarquías muy anchas pueden desorientar y confundir al usuario al ofrecer

demasiadas opciones de navegación desde una misma página. En la Figura 5 se

representan este tipo de estructuras.

Figura 5: diagrama de estructuras jerárquicas

Una vez definida la estructuración del sitio es necesario documentarla, para así tener un

modelo de referencia sobre el que sustentar el desarrollo del sitio. La forma de

documentar arquitecturas se suele hacer a través de grafos y esquemas, con el objetivo de

que sean de fácil y rápida comprensión por todos los miembros del equipo de desarrollo.

Otras tareas a llevar a cabo por el Arquitecto de Información o diseñador en la fase de

Diseño Conceptual son: definir sistemas de clasificación para los contenidos; elaborar

índices y mapas del sitio; o aplicar metadatos a cada una de las páginas y sub-elementos de

información.

Entre las técnicas de Diseño Centrado en el Usuario a aplicar en la etapa de Diseño

Conceptual destacamos, por su utilidad y facilidad de ser llevada a cabo, la técnica de "card

sorting" u ordenación de tarjetas. Ésta se basa en la observación de cómo los usuarios

agrupan y asocian entre sí un número predeterminado de tarjetas etiquetadas con las

diferentes categorías o secciones temáticas del sitio web. De esta forma, partiendo del

comportamiento de los propios usuarios, es posible organizar y clasificar la información

de un sitio web conforme a su modelo mental. [Hassan et al, 2004a]



Diseño visual y definición de estilo

En esta fase se especifica el aspecto visual del sitio web: composición de cada tipo de

página, aspecto y comportamiento de los elementos de interacción y presentación de

elementos multimedia.

Con el objetivo de evitar la sobrecara informativa, en el diseño de cada interfaz se debe

tener en cuenta el comportamiento del usuario en el barrido visual de la página,

distribuyendo los elementos de información y navegación según su importancia en zonas

de mayor o menor jerarquía visual - por ejemplo, las zonas superiores del interfaz poseen

más jerarquía visual que las inferiores-.

Además de la posición de cada elemento en la interfaz, existen otras técnicas para

jerarquizar información como son: uso del tamaño y espacio ocupado por cada elemento

para otorgarle importancia en la jerarquía visual, utilización del contraste de color para

discriminar y distribuir información, uso de efectos tipográficos para enfatizar contenidos,

rotura de la simetría y uso de efectos de relieve / profundidad para resaltar elementos, etc.

Además de evitar la sobrecarga informativa jerarquizando los contenidos mediante las

técnicas descritas, para evitar la sobrecarga memorística se recomienda definir menús de

navegación con un número de opciones reducido, normalmente no más de nueve

diferentes.

Otro aspecto importante en el diseño visual del sitio es la accesibilidad. Este es el nexo de

unión más claro de estos dos ámbitos del desarrollo web de los que se viene hablando en

este Trabajo. Aspectos como el uso de colores que deben ofrecer suficiente contraste entre

texto y fondo para no dificultar la lectura, o la selección de combinaciones de colores

teniendo siempre en cuenta las discapacidades visuales en la percepción del color que

pudieran presentar nuestros usuarios, vienen marcados por criterios de accesibilidad.

El uso de imágenes en el diseño, por motivos de accesibilidad y comprensibilidad, deben

cuidar su resolución y tamaño desde el punto de vista de la usabilidad. Desde una

perspectiva más amplia del diseño visual del sitio es importante mantener una coherencia

y estilo común entre todas las páginas, proporcionando una consistencia visual a todo el

sitio. Este aspecto es contemplado tanto por la accesibilidad como por la usabilidad.

Diseño de contenidos

De lo que se trata es de diseñar contenidos interrelacionados y vinculados, manteniendo

cierta coherencia informativa, comunicacional y organizativa.

La escritura hipertextual se debe realizar de forma diferente a la tradicional. El nuevo

medio y sus características obligan a ser concisos, precisos, creativos y estructurados a la

hora de redactar. Debemos conocer a quién nos dirigimos y adaptar el lenguaje, tono y

vocabulario utilizado al usuario objetivo, aspecto también muy ligado a la accesibilidad.



Algunos consejos a seguir en el diseño y redacción de contenidos son:

Seguir una estructura piramidal: La parte más importante del mensaje, el núcleo,

debe ir al principio.

Permitir una fácil exploración del contenido: El lector en entornos Web, antes de

empezar a leer, suele explorar visualmente el contenido para comprobar si le

interesa.

Un párrafo = una idea: Cada párrafo es un objeto informativo. Se deben trasmitir

ideas, mensajes... evitando párrafos vacíos o varios mensajes en un mismo párrafo.

Ser conciso y preciso: Al lector no le gusta leer en pantalla.

Vocabulario y lenguaje: Se debe utilizar el mismo lenguaje del usuario, no el de la

empresa o institución. El vocabulario debe ser sencillo y fácilmente comprensible.

Tono: Cuanto más familiar y cercano (sin llegar a ser irrespetuoso) sea el tono

empleado, más fácil será que el lector preste atención.

Confianza: La mejor forma de ganarse la confianza del lector es permitiéndole el

diálogo, así como conocer cuanta más información posible acerca del autor.

Prototipado

Como se ha comentado al principio, la evaluación de la usabilidad debe realizarse desde

las primeras etapas de diseño. Para poder realizar la evaluación de un sitio web que

todavía no está implementado existen los prototipos.

La etapa de prototipado se basa en la elaboración de modelos o prototipos de la interfaz

del sitio. Su aspecto no se corresponde exactamente con el que tendrá el sitio una vez

finalizado, pero pueden servir para evaluar la usabilidad del sitio sin necesidad de esperar

a su implementación.

La utilidad real del prototipado se fundamenta en que no tendría sentido empezar a

implementar una interfaz web si no está asegurado antes que el diseño es usable.

Según el grado de fidelidad o calidad del prototipo se distingue entre:

Prototipado de alta fidelidad: El prototipo será muy parecido al sitio web una vez

terminado.

Prototipado de baja fidelidad: El aspecto del prototipo distará bastante del que

tenga el sitio web final.

En las primeras etapas de desarrollo del sitio web se puede hacer uso del prototipado en

papel o de bajo coste, que consiste en reproducir los aspectos básicos de la interfaz del

sitio en papel. Otra forma de realizar prototipos es mediante la reproducción del aspecto

del sitio a través de herramientas software.



Hay que recordar que estos prototipos son reproducciones, no estados tempranos de

implementación de la interfaz. Una vez que el prototipo se ha utilizado se tira, no es parte

del sitio web.

Método por inspección: evaluación heurística

Los métodos de inspección de la usabilidad de un sitio web son aquellos realizados por el

experto en usabilidad, y que se basan en el recorrido y análisis del sitio identificando

errores y problemas de diseño.

La evaluación heurística es un tipo de método de inspección, que tiene como ventaja la

facilidad y rapidez con la que se puede llevar a cabo.

El procedimiento heurístico, en general, puede ser descrito como el proceso en el que se

detectan problemas relacionados con el uso de un sistema interactivo a partir de una serie

de reglas (heurísticas) previamente determinadas.

La evaluación heurística, desarrollada por Nielsen y Molich en 1990 [Nielsen, et al, 1990],

se efectúa principalmente por evaluadores (los estudios de Nielsen [Nielsen, 2005]

muestran que un número de entre 3 evaluadores es suficiente), que en base a su propia

experiencia y fundamentándose en unos principios establecidos por la disciplina de la

Interacción Persona Ordenador (IPO), evalúan de forma independiente el sitio web,

contrastando finalmente los resultados. Éstos detectan aproximadamente el 42% de los

problemas graves de diseño y el 32% de los problemas menores, dependiendo del número

de evaluadores que revisen el sitio.

Existen diversos autores que proponen distintos conjuntos de principios de usabilidad

para este tipo de evaluación, quizá el más conocido sea el de [Nielsen, 1994]. Los autores

Yussef Hassan y Francisco Martínez proponen otra guía de evaluación heurística orientada

a evaluación de sitios web.

La guía está estructurada en forma de lista de comprobación (checklist), para facilitar la

práctica de la evaluación. Todos los puntos están formulados como preguntas, dónde la

respuesta afirmativa implica que no existe un problema de usabilidad, y la negativa que sí.

Los diferentes criterios en los que están clasificados todos los puntos a evaluar son:

Generales: Objetivos, look & feel, coherencia y nivel de actualización de contenidos

Identidad e información: Identidad del sitio e información proporcionada sobre el

proveedor y la autoría de los contenidos.

Lenguaje y redacción: Calidad de los contenidos textuales.

Rotulado: Significación y familiaridad del rotulado de los contenidos.

Estructura y navegación: Idoneidad de la arquitectura de información y

navegación del sitio.



Layout de la página: Distribución y aspecto de los elementos de navegación e

información en la interfaz.

Búsqueda: Buscador interno del sitio.

Elementos multimedia: Grado de adecuación de los contenidos multimedia al

medio web.

Ayuda: Documentación y ayuda contextual ofrecida al usuario para la navegación.

Accesibilidad: Cumplimiento de pautas de accesibilidad.

Control y retroalimentación: Libertad del usuario en la navegación [Hassan, et al,

2003b].

Hoy en día, en el contexto de evaluación de la usabilidad de los sistemas interactivos, la

técnica de la evaluación heurística está muy extendida y su realización es común, no

obstante, lo que no es tan fácil de encontrar es la forma de analizar exhaustiva y

rigurosamente los resultados obtenidos mediante esta técnica.

Para poder realizar la evaluación heurística y que ésta sea de calidad deben seguirse los

siguientes pasos [Nielsen, 2005]:

1. Entrenamiento previo: el evaluador debe familiarizarse con la interfaz durante

unos minutos para conocer la web y poder realizar la EH de manera ágil.

2. Evaluación: el evaluador sigue el conjunto de heurísticas para encontrar

deficiencias a la web o catalogarla como usable. Puede anotar observaciones.

3. Puntuar la severidad: se debe determinar la severidad de cada uno de los

problemas encontrados.

4. Revisión: Se trata de analizar cada una de las evaluaciones realizadas para

presentar un informe con todos los problemas y las posibles resoluciones,

teniendo en cuenta que el análisis obtenido es cualitativo.

El grado de severidad se puede usar para asignar más recursos a solucionar los problemas

más graves y puede proporcionar también una estimación aproximada de las necesidades

para esfuerzos adicionales de usabilidad.

La severidad de un problema de usabilidad es la combinación de tres factores:

La frecuencia con la que el problema ocurre: ¿es habitual o es raro?

El impacto del problema cuando ocurre: ¿será fácil para el usuario superarlo o

será difícil?

La persistencia del problema: ¿es un problema que ocurre una sola vez y los

usuarios saben cómo superarlo o es un problema molesto porque se repite?

Es necesario evaluar el impacto de los problemas de usabilidad, ya que éstos pueden tener

un efecto muy negativo sobre el producto a lanzar. La severidad tiene numerosos

componentes que se unen en un único ratio para facilitar la priorización y la toma de

decisión para cada problema de usabilidad.



La siguiente escala presenta los valores para medir la severidad de los problemas de

usabilidad:

0 = No es un problema de usabilidad

1 = Problema superficial: no necesita ser corregido salvo tiempo extra disponible

2 = Problema menor: asignación de prioridad baja para su resolución

3 = Problema mayor: corrección importante, prioridad alta

4 = Problema catastrófico: obligatoria su corrección antes de lanzar el producto

Una manera de clasificar los métodos de evaluación de la usabilidad es a partir del tipo de

resultado que se obtiene. Así, se distinguen métodos de evaluación de la usabilidad

cuantitativos y métodos de evaluación de la usabilidad cualitativos. Ambos tipos de

métodos son complementarios y no excluyentes. [González, et al., 2010]

Los métodos de evaluación de la usabilidad cuantitativos se asocian a la búsqueda de

resultados finales que condensen la ponderación de la usabilidad del sistema bajo

evaluación en un valor numérico final. Por otro lado, es común incluir métodos de

evaluación de la usabilidad cualitativos, ya que no existe actualmente una medida

cuantitativa medible que sea lo suficientemente expresiva como para representar

conceptos tan complejos como la satisfacción del usuario o el grado general en que todos

los problemas de usabilidad presentes en un sistema afectan su calidad [Pérez, 2002].

Además, el análisis cualitativo ofrece una gran riqueza y precisión en las observaciones

realizadas y el análisis cuantitativo puede ofrecer información que sea estadísticamente

significativa y resultados que puedan considerarse generalizables, por lo que es frecuente

y recomendable que se combinen ambos tipos.

Método de test con usuarios

El test con usuarios es una prueba de usabilidad que se basa en la observación y análisis

de cómo un grupo de usuarios reales utiliza el sitio web, anotando los problemas de uso

con los que se encuentran para poder solucionarlos posteriormente.

Es una prueba complementaria a la evaluación heurística, pero un test con usuarios es más

costoso, por lo que es recomendable realizarlo siempre después de una evaluación

heurística, ya que sería desperdiciar tiempo y dinero utilizarlo para descubrir errores de

diseño motivados por el no cumplimiento en el desarrollo de principios generales de

usabilidad (heurísticos).

La ventaja que ofrecen los test de usuarios frente a otro tipo de evaluaciones es que por un

lado es una demostración con hechos, por lo que sus resultados son más fiables, y por otro

porque posibilitan el descubrimiento de errores de diseño imposibles o difíciles de

descubrir mediante la evaluación heurística.



Llevar a cabo un test de usuarios formal obligaría a alquilar un local (laboratorio)

adecuado, contratar a evaluadores especializados, así como a delegar en alguna empresa la

selección y reclutamiento de los participantes de la prueba. Realmente sería bastante

costoso y poco viable para la gran mayoría de casos.

Existe otra forma de llevar a cabo un test con usuarios popularizada por Nielsen mucho

más económica y fácil de realizar, con resultados y utilidad similares, que son las

denominadas pruebas informales o test de 'guerrilla'. En [Hassan, et al, 2003c] se detalla

cómo llevar a cabo este tipo de pruebas: reclutamiento de participantes, elección del local

y materiales, realización de la prueba y elaboración del informe final.

2.11. Tecnologías para el desarrollo web

2.11.1. Lenguajes de programación

El diseño y desarrollo web es un ámbito complejo, hay cientos de disciplinas diferentes,

desde todos los tipos de lenguajes de programación, estándares web y paquetes de

software. La figura 3 representa las relaciones entre ellos, de manera que los paquetes

software aparecen en azul, los lenguajes de programación en beige y las tecnologías del

núcleo web están en verde. La infraestructura relacionada aparece en gris. [Brown, 2006]

Figura 6: Árbol con la familia de las tecnologías web

Como muestra la figura anterior existen diversos lenguajes de programación para el

desarrollo web, pero el resultado siempre será una página en (X)HTML que interpretará y

presentará un navegador web.



Estas páginas pueden ser estáticas o dinámicas respecto a sus contenidos. Una página

estática es aquella cuyo contenido no cambia frecuentemente, se localiza en una página

única para dicho contenido y su cambio debe ser manual. Por otro lado, las páginas de

contenido dinámico son aquellas cuyo contenido está almacenado en una base de datos y

se actualiza a través de un gestor de contenidos. Su carga es dinámica y la realiza el gestor

de contenidos en una plantilla que sirve para todos los contenidos del sitio web.

En cualquiera de los dos tipos de página el lenguaje de programación web puede ser

cualquiera de los presentados en la Figura 2. En el caso de este Trabajo, las páginas son

dinámicas respecto a su contenido porque son gestionadas a través de un CMS del cual se

habla en el siguiente apartado.

En función del lenguaje de programación que se use se consiguen páginas estáticas,

dinámicas del lado del cliente o dinámicas del lado del servidor respecto a la forma en la

que se obtiene el documento (X)HTML que interpretará finalmente el navegador.

Las páginas estáticas serán aquellas cuyo lenguaje de programación sea íntegramente

(X)HTML y no necesite ninguna interpretación adicional por ningún compilador o

intérprete que no sea el de HTML.

Las páginas dinámicas del lado del cliente son aquellas cuyo lenguaje de programación no

es sólo (X)HTML, sino que tiene incrustado en él otros lenguajes como Java, JavaScript, o

Flash y necesitan descargarse el código de estos objetos para ser interpretados en el

ordenador del usuario, a través de extensiones (plugins) de su navegador. Lo cual quiere

decir, que si el usuario no dispone de esa tecnología en su navegador, no podrá ver esa

parte de la página.

Las páginas dinámicas del lado del servidor son aquellas cuyo lenguaje de programación

es reconocido, ejecutado e interpretado en el servidor de manera que lo que se le envía al

cliente tras su petición es directamente el documento (X)HTML generado.

Las páginas dinámicas pueden serlo tanto del lado del cliente como del servidor al mismo

tiempo. Es decir, que se puede generar gran parte del código en el servidor y devolver al

cliente una página que contenga algún script que requiera su ejecución del lado de éste.

Los lenguajes que generan páginas estáticas íntegramente son HTML, XHTML y XML.

Algunos de los lenguajes que generan páginas dinámicas del lado del cliente son Java,

JavaScript o Flash, y los que generan páginas dinámicas del lado del servidor son ASP,

ASP.NET, AJAX, JSP, PHP o RUBY.

En este proyecto se generan páginas dinámicas tanto del lado del cliente como del lado del

servidor, lo cual se consigue haciendo uso de los lenguajes XHTML, PHP y JavaScript con su

biblioteca jQuery.



XHTML

XHTML (del inglés, Extensible Hypertext Markup Language) es una variante de HTML (del

inglés, Hypertext Markup Language) que usa la sintaxis de XML (del inglés, Extensible

Markup Language). XHTML tiene los mismos elementos que HTML, pero la sintaxis es un

poco diferente.

HTML es un lenguaje para describir la estructura de las páginas web. HTML permite:

Publicar documentos en línea con encabezados, texto, tablas, listas, fotos, etc.

Llegar a información a través de enlaces de hipertexto haciendo un solo clic.

Diseñar formularios para transacciones con servicios remotos, para realizar

búsquedas de información, hacer reservas, comprar productos, etc.

Incluir hojas de cálculo, video clips, canciones, y otras aplicaciones directamente

con sus documentos.

Con HTML los autores describen la estructura de las páginas usando marcado. Los

elementos del lenguaje etiquetan partes del contenido como párrafos, listas, tablas, y así.

[W3C, 2010b]

HTML 4 es una aplicación de SGML (del inglés, Standard Generalized Markup Language)

conforme al estándar internacional ISO 8879 y es ampliamente considerado como el

lenguaje de publicación estándar del World Wide Web.

SGML es un lenguaje para describir lenguajes de marcado, particularmente los usados

para el intercambio de documentos electrónicos, gestión de documentos y publicación de

documentos. HTML es un ejemplo de lenguaje definido mediante SGML.

SGML ha existido desde mediados de 1980 y se ha mantenido bastante estable. Mucha de

esta estabilidad se debe al hecho de que este lenguaje es a la vez rico en características y

flexibilidad. Esta flexibilidad, sin embargo, tiene un precio que es el nivel de complejidad

que ha inhibido su adopción en una diversidad de ambientes, incluyendo la web.

HTML, como se concibió originalmente, iba a ser un lenguaje para el intercambio de

documentos científicos y otros documentos técnicos, adecuados para su uso por parte de

especialistas. HTML abordó el problema de la complejidad de SGML especificando un

pequeño conjunto de etiquetas estructurales y semánticas adecuadas para la creación de

documentos relativamente simples. Además, para simplificar la estructura del documento,

HTML añadió soporte para hipertexto. Las capacidades multimedia se añadieron más

tarde.

En un espacio muy corto de tiempo, HTML se hizo muy popular y rápidamente superó su

propósito original. Desde la creación de HTML, ha habido una rápida invención de nuevos

elementos para su uso en HTML (como estándar) y para la adaptación de HTML a



mercados altamente especializados. Este conjunto de nuevos elementos ha dado lugar a

problemas de interoperabilidad de documentos a través de diferentes plataformas.

La migración o implementación del contenido a XHTML permite conseguir los siguientes

beneficios:

Los documentos XHTML son conformes a XML. Por lo que son fácilmente editados,

vistos, y validados con herramientas estándar de XML.

Los documentos XHTML pueden ser interpretados por navegadores y tecnologías

de apoyo, igual de bien que si hubiesen sido escritos en HTML 4.

Los documentos XHTML pueden utilizar aplicaciones (p.e. scripts o applets) que se

basan, ya sea en el HTML DOM (“Document Object Model”) o en el XML DOM.

[W3C, 2002]

CSS

CSS (del inglés, Cascading Style Sheets) es un lenguaje para describir la presentación de las

páginas web, incluye sus colores, las propiedades de sus capas y sus fuentes. CSS permite

adaptar la presentación a diferentes tipos de dispositivos, como pantallas grandes,

dispositivos móviles, o impresoras. CSS es independiente de HTML y puede usarse con

cualquier lenguaje de marcado basado en XML. La separación entre HTML y CSS hace más

fácil de mantener los sitios web, compartir las hojas de estilo entre páginas y migrar

páginas a diferentes entornos. Esto se conoce como la separación del contenido (y su

estructura) de la presentación. [W3C, 2010b]

CSS es la manera recomendada de controlar la presentación de las capas en un documento

web. La principal ventaja dl CSS sobre la presentación con marcado HTML es que el estilo

puede mantenerse enteramente separado del contenido. Es decir, que es posible

almacenar los estilos de presentación de, por ejemplo, 10.000 páginas de un sitio web en

un único fichero CSS, mientras que de la otra forma habría que redefinirlo para cada

página. CSS también proporciona un mejor control sobre la presentación de lo que

permiten los elementos de presentación de HTML.

Con la externalización de la capa de presentación CSS ofrece un gran número de

beneficios:

Todo el estilo se guarda en un número limitado de hojas de estilo. El impacto

positivo en el mantenimiento de un sitio web no puede ser subestimado – editar

una hoja de estilo es objetivamente más eficiente que editar 10.000 hojas HTML.

El ahorro total de ancho de banda es medible. Primero, las hojas de estilo se

almacenan en caché tras la primera solicitud al servidor y pueden reutilizarse para

cada página de un mismo sitio web, no teniendo que ser descargadas por cada

página visitada. En segundo lugar, la eliminación de todas las marcas de

presentación de las páginas web en favor del uso de CSS también reduce el tamaño



y uso de ancho de banda -más del 50% en muchos casos documentados-. Esto

beneficia al propietario del sitio, mediante la reducción de ancho de banda y los

costes de almacenamiento, así como los usuarios del sitio, para los que la carga de

las páginas web es más rápida.

La separación del contenido de la presentación hace más fácil a los propietarios del

sitio web reutilizar el contenido para otros fines, tales como el RSS (del inglés,

Really Simple Sindication)o la conversión de texto a voz.

Al separar las reglas de estilo se pueden usar diferentes medios de visualización.

Ya no se necesita crear diferentes versiones de cada página para la impresión –

simplemente se crea una única hoja de estilo para controlar cómo será imprimida

cada página .

Aunque CSS está diseñado para ser independiente de los lenguajes de marcado de

documentos a los que se aplica, en realidad es utilizado principalmente con HTML y XML

(incluyendo XHTML). [Olsson, 2007]

PHP

PHP es un acrónimo recursivo de PHP: Hypertext preprocessor. Es un lenguaje de scripting

de propósito general y ampliamente utilizado que está especialmente indicado para

desarrollo web y puede ser embebido en HTML.

En lugar de muchos comandos para la salida HTML (como se ve en C o Perl), las páginas de

HTML contienen código PHP embebido que hace "algo". El código PHP se incluye dentro de

instrucciones especiales de comienzo y final de procesamiento <?php y ?> que permiten

entrar y salir del “modo PHP”.

Lo que distingue a PHP de lenguajes del lado del cliente como JavaScript es que el código

se ejecuta en el servidor generando el HTML que se envía al cliente. El cliente recibirá los

resultados de ejecutar ese script, pero no conocerá el código subyacente. Se puede

configurar el servidor para que procese todos los ficheros HTML con PHP y realmente no

hay manera de que ningún usuario sepa qué se está haciendo.

Lo mejor de usar PHP es que su sintaxis es simple para principiantes, pero ofrece muchas

características avanzadas para programadores profesionales.

PHP está centrado principalmente en scripts del lado del servidor, por lo que puede

recoger datos de formularios, generar contenido dinámico en páginas o enviar y recibir

cookies. Además, PHP permite hacer mucho más.

Hay tres áreas principales donde se usan scripts de PHP:

Scripts del lado del servidor. Este es el campo más tradicional y el principal foco de

trabajo. Se necesitan tres cosas para que esto funcione. El intérprete de PHP , un

servidor web y un navegador. Es necesario hacer funcionar el servidor, con PHP



instalado. El resultado del programa PHP se puede obtener a través del navegador,

conectándose con el servidor web.

Scripts en línea de comandos: Se puede hacer un script en PHP que ejecuten sin un

servidor o navegador. Sólo se necesita que el intérprete de PHP esté configurado

para este modo. Este tipo de scripts es ideal para ejecuciones regulares desde cron

(en Linux) o Task Scheduler (en Windows). Estos scripts también puede usarse

para tareas simples de procesamiento de texto.

Aplicaciones con entorno gráfico: PHP no es el mejor lenguaje para crear

aplicaciones con entorno gráfico, pero si se conoce PHP muy bien y se quiere usar

algunas características avanzadas en aplicaciones del lado del cliente también se

puede hacer uso de PHP-GTK.

PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mercado

y soporta la mayoría de servidores web de hoy en día. De modo que, con PHP se tiene la

libertad de elegir el sistema operativo y el servidor. También hay posibilidad de usar

programación procedimental o bien orientada a objetos (OOP, del inglés, Object Oriented

Programming). Además, en su versión PHP 5 soluciona los puntos débiles de la OOP de

PHP 4 e introduce soporte completo para objetos.

Con PHP no se encuentra limitado a generar resultados en HTML. Entre las habilidades de

PHP se incluyen: creación de imágenes, archivos PDF e incluso películas Flash (usando

libswf y Ming) sobre la marcha. También puede presentar otros resultados, como XHTML

y cualquier otro tipo de ficheros XML. PHP puede autogenerar éstos archivos y

almacenarlos en el sistema de archivos en vez de presentarlos en la pantalla, creando un

caché en el lado del servidor para contenido dinámico.

Quizá la característica más potente y destacable de PHP es su soporte para una gran

cantidad de bases de datos. Algunas de las bases de datos soportadas actualmente son

FrontBase, mSQL, Direct MS-SQL, MySQL, ODBC, Oracle (OCI7 y OCI8) entre otras. Escribir

una página web con acceso a una base de datos es una tarea muy simple con PHP gracias a

la extensión específica que exporta para mysql o a la posibilidad de uso de una capa de

abstracción de orientación a objetos.

PHP tiene unas características muy útiles para el procesamiento de texto, desde

expresiones regulares POSIX extendidas o tipo Perl hasta procesadores de documentos

XML. Para procesar y acceder a documentos XML, PHP 4 soporta los estándares SAX y

DOM y también puede utilizar la extensión XSLT para transformar documentos XML. PHP

5 estandariza todas las extensiones XML en una sólida base de libxml2 y extiende las

características SimpleXML y soporte para XMLReader [PHP.net, 2010].

JavaScript y jQuery

JavaScript es un lenguaje de programación de scripts del lado del cliente. Un script del lado

del cliente es un programa que puede acompañar un documento HTML o estar embebido



directamente en él. El navegador web ejecuta ese programa en la máquina del cliente

cuando el documento se carga u otras veces cuando se activa un enlace. El soporte que

proporciona HTML para scripts es independiente del lenguaje de scripting que se esté

utilizando.

Los scripts de cliente permiten a los autores extender los documentos HTML con

interacción:

Los scripts pueden ser evaluados en la carga de un documento para modificar los

contenidos de manera dinámica.

Los scripts pueden acompañar un formulario para pre-procesar las entradas

introducidas. Se puede comprobar si los datos introducidos responden a un rango

de valores o un formato determinado, si se ha introducido algún valor en un campo

obligatorio o si dos campos de repetición son consistentes.

Los scripts pueden ser lanzados por eventos que afectan al documento, como la

carga, el foco sobre un elemento, el movimiento de ratón, etc.

Existen dos tipos de scripts que se pueden adjuntar a un documento HTML:

Aquellos que se ejecutan una sola vez cuando el documento se carga por el agente

de usuario. Estos scripts aparecen sin el elemento <script>.

Aquellos que se ejecutan cada vez que ocurre un evento específico. Estos scripts

pueden estar asignados a un número de elementos variable.

JavaScript fue inventado en 1995 por Netscape. A pesar de que hoy es plenamente

respetado tiene un pasado hasta cierto punto accidentado. Se consideraba un lenguaje de

programación para aficionados cuyos resultados no eran muy útiles, se veía en algunos

navegadores web cuando aparecían mensajes con efecto de desplazamiento a través de la

barra de estado o elementos que se movían siguiendo el ratón.

En los primero años era fácil encontrar en la web miles de programas gratuitos que no

funcionaban en todos los navegadores. Por lo que también sufrió las incompatibilidades

entre los dos navegadores en auge de aquellos años, Internet Explorer y Netscape.

Mientras se intentaban echar del mercado el uno al otro, se hacía muy difícil escribir

programas en JavaScript que funcionaran para ambos.

Lo peor de aquellos años ya es pasado y los navegadores contemporáneos como Firefox,

Safari o Chrome han estandarizado mucho los modos en que manejan JavaScript, haciendo

más fácil escribir programas que funcionen con casi todos ellos aunque hay todavía

algunas incompatibilidades.

En los últimos años JavaScript ha tenido un renacimiento alimentado por páginas web de

perfil alto como Google, Yahoo o Flickr que usan este lenguaje para crear aplicaciones web

interactivas.



Sin embargo, JavaScript no es sólo para páginas web. Se ha probado como un lenguaje de

programación tan útil que si se aprende se puede escribir programas para el iPhone e

intervenir en aplicaciones cerradas de programas de Adobe.

JavaScript no funcionaría sin los otros dos pilares del diseño web: HTML y CSS. Muchos

programadores hablan de los tres lenguajes como los que forman las capas de una página

web: HTML proporciona el nivel estructural organizando los contenidos de un modo

significativo; CSS proporciona el nivel de presentación, dando una buena apariencia al

contenido de HTML; JavaScript añade el nivel de comportamiento, aportando a la página

web interacción y dinamismo.

JQuery es una biblioteca de JavaScript que solventa muchos detalles cotidianos del

lenguaje. Evita determinadas acciones que consumen mucho tiempo. Se puede pensar en

esta biblioteca como en una colección de funciones prescritas en JavaScript que recogen

muchas acciones individuales en una sola línea que si no habría que escribir línea a línea y

depurarlas una a una. Existen otras muchas bibliotecas de JavaScript (Dojo Toolkit,

Prototype, Mootools o YUI) que se usan en sitios como Amazon, Apple, Microsoft, Twitter,

etc.

Las ventajas que presenta jQuery frente a otras bibliotecas son:

Tamaño del fichero relativamente pequeño: entre 55K y 30K.

Cómoda para los diseñadores: usa nomenclatura de CSS.

Está probada y funciona: Se usa en muchos sitios web como Dell, Warner Bros

Records o Google.

Es gratuita.

Tiene una comunidad grande de desarrollo. [Sawyer, 2008]

En el fragmento de Código 1 se muestra el código en jQuery que mueve el elemento de la

página cuyo identificador es “ejemplo” 100 píxeles a la izquierda. A continuación se

muestra un código similar en JavaScript que hace algo similar. Como se puede observar el

número de líneas de código usando JavaScript es bastante mayor y por tanto la cantidad de

errores que se puede cometer y el tiempo de depuración se ven aumentados.

// Código de jQuery

$(document).ready(function (){

$("#element").animate({ left: 100px; });

});

// Código de JavaScript

var example = null; // object

function doMove() {

example.style.left = parseInt(example.style.left)+1+'px';

setTimeout(doMove,20); // call doMove in 20msec

}



function init() {

example = document.getElementById('example'); // get the "example" object

example.style.left = '0px'; // set its initial position to 0px

doMove(); // start animating

}

window.onload = init;

Código 1: ejemplo de código en jQuery y en JavaScript

2.11.2. Herramientas de gestión de contenidos

Hoy día existe en el mercado una gran cantidad de CMS (del inglés, Content Management

System) tanto de pago como de código abierto. En cualquier caso, es necesaria una

adaptación del gestor de contenidos a la funcionalidad y el diseño deseados.

Los primeros sistemas de administración de contenidos fueron desarrollados por

organizaciones que publicaban una gran cantidad de contenido en Internet y necesitaban

de continuas actualizaciones, como revistas en línea, periódicos y publicaciones

corporativas.

En 1995, el sitio de noticias tecnológicas CNET sacó su sistema de administración de

documentos y publicación y creó una compañía llamada Vignette, pionero de los sistemas

de administración de contenido comerciales.

La evolución de Internet hacia portales con más contenido y la alta participación de los

usuarios directamente a través de blogs y redes sociales, ha convertido a los gestores de

contenidos en una herramienta esencial en Internet, tanto para empresas e instituciones

como para las personas. Los wikis y los sistemas groupware también son considerados

CMS.

Los CMS son herramientas que deben permitir la creación, edición y organización de

información en un sitio web. En la Figura 7 se muestra como un gestor de contenido de

propósito general integra estas funcionalidades.



ContactoNoticiasForos

Index.php

Base de datos

Figura 7: Esquema de un CMS de propósito general

Dado el foco de este Trabajo, se desea utilizar un CMS que permita crear sitos accesibles.

Para la elección de un CMS accesible algunos de los factores que se pueden considerar son

la capacidad técnica del personal que lo utilizará y el trabajo necesario para configurar y

personalizar el sistema. Lleva mucho tiempo comprobar la eficacia y viabilidad de un CMS

y más si es de código abierto, por lo que muchos se irán a empresas que ofrecen un

paquete comercial que ya está desarrollado y que realizarán la migración de contenido y

personalización del sistema. Para aquellos con un gran presupuesto esto puede ser una

solución viable, pero para los grupos de base comunitaria u otros con poco o ningún

presupuesto ¿hay sistemas disponibles que puedan hacer que la creación y administración

de contenidos sea una opción plausible para personas con una cantidad mínima de

conocimientos técnicos necesarios? [Juicy Studio, 2007]

La respuesta es sí, existen ese tipo de sistemas. Los principales criterios que tiene que

satisfacer el CMS para ser viable su uso en este Trabajo son:

Un CMS que sea funcional, accesible y usable para los editores que tienen un nivel

básico de las IT (del inglés, Information Technologies) y conocimientos de editores

de texto, pero no tienen soltura con lenguajes de marcado como HTML.

Un CMS que sea recomendado y promovido como accesible o que permita el

desarrollo de un sitio web accesible a través de sus módulos.

Un CMS que permita abarcar toda la funcionalidad requerida por el sitio que se

quiere desarrollar como publicación de libros, de noticias, de eventos, etc. De esta

funcionalidad se habla en detalle en el apartado “planteamiento del problema”.

Un CMS que usase PHP y su base de datos pudiese ser MySQL o similar, siempre

con licencia gratuita.



Las tablas que aparecen a continuación muestran las características más relevantes de los

gestores de contenidos evaluados para este Trabajo. En la Tabla 4 se analizan los

requisitos que debe tener un sistema para soportar el cada gestor. En la Tabla 5 se

analizan parámetros de seguridad que soporta cada gestor. En la Tabla 6 y la Tabla 7 se

recogen el soporte disponible para cada gestor y la facilidad de uso de los mismos

respectivamente.

Por otro lado, en la Tabla 8 se analizan aspectos de rendimiento como caché para temas o

balanceo de carga. En la Tabla 9 se analizan los aspectos de configuración que soporta

cada navegador. La Tabla 10 y la Tabla 11 comentan aspectos de integración con otras

tecnologías, así como aspectos flexibilidad de cada gestor respectivamente. Por último en

la Tabla 12 y la Tabla 13 se comparan las funcionalidades extensibles de cada gestor y la

integración con aplicaciones de comercio electrónico respectivamente. [CMSMatrix, 2010]

Requisitos de sistema Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10

Expression Engine 1.6.6

Drupal 6.10

Servidor Apache Zope Apache CGI Apache Apache

Licencia Libre Libre Libre Libre Desde 249$ Libre

Base de datos MySQL Otra MySQL MySQL MySQL MySQL

Lenguaje de programación PHP Python PHP PHP PHP PHP

Tabla 4: Requisitos del sistema

Seguridad Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Mantiene registro de quien añade, actualiza o borra contenido

Sí Sí No No Sí Sí

Captchas Módulo

libre Módulo

libre Sí

Módulo libre

Sí Módulo

libre

Permisos sobre funciones o partes de contenido

Sí Sí Sí No Sí Sí

Historial de sesiones Sí Módulo

libre Módulo

libre Sí Sí Sí

Notificación de problemas Sí Módulo

libre Sí No No No

Saber quién tiene su sesión abierta, qué está haciendo y echarle

Sí Módulo

libre Limitado Sí Limitado Sí

SSL compatible Sí Sí Módulo

libre Sí Sí Sí

Tabla 5: Características de seguridad

Soporte Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Plantillas de código para desarrollar nuevos módulos

Módulo libre

Sí No No Limitado Sí

Manuales comerciales Sí Sí Sí Sí Sí Sí

Soporte Sí Sí Sí Sí Sí Sí

Comunidad de desarrollo Sí Sí Sí Sí Sí Sí



Desarrollo de terceros Sí Sí Sí Sí Sí Sí

Test de funcionalidades Módulo

libre Sí No Sí No

Módulo libre

Tabla 6: Soporte para los gestores de contenidos

Facilidad de uso Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Arrastrar y soltar contenido Módulo

libre Sí No No No

Módulo libre

Foros e hilos Módulo

libre Módulo

libre No

Módulo libre

Sí Módulo

libre

Url limpias Sí Sí Sí Sí Sí Sí

Adaptar tamaño de imágenes Sí Sí No Sí Sí Módulo

libre

Subida masiva de ficheros Sí Sí No Sí Limitado Módulo

libre

Revisor de sintaxis Sí Módulo

libre Sí No Sí

Módulo libre

Suscripciones Módulo

libre Sí No

Coste extra

Sí Módulo

libre

Deshacer operaciones Sí Sí Sí No No Limitado

WYSIWYG Sí Sí Sí Sí Módulo

libre Módulo

libre

Tabla 7: Facilidad de uso

Prestaciones Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Cache avanzada para temas, contenido repetido

Sí Sí Sí Sí Sí Sí

Duplicación de base de datos Módulo

libre Sí No No No Limitado

Carga balanceada Sí Sí No Sí No Sí

Cache para páginas Sí Sí Sí Sí Sí Sí

Exportación de contenido Módulo

libre Módulo

libre No No No

Módulo libre

Tabla 8: Prestaciones del gestor

Administración Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Administración de anuncios Módulo

libre Módulo

libre Sí Sí No

Módulo libre

Reutilización de los contenidos Sí Sí Sí Sí Sí Sí

Portapapeles Sí Sí Sí No Limitado No

Administración web Sí Sí Sí Sí Sí Sí

Subsitios o subdominios Sí Sí No Sí Sí Sí

Temas Sí Sí Sí Sí Sí Sí

Basura Sí Módulo

libre Sí Sí No No

Estadísticas del sitio Módulo

libre Módulo

libre Sí Sí Sí Sí



Traducción de la interfaz Sí Sí Sí Módulo

libre Sí Sí

Flujo de trabajo Limitado Sí No No Sí Limitado

Tabla 9: Prestaciones de administración

Interoperabilidad Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

RSS Sí Sí Sí Sí Sí Sí

Soporte FTP Sí Sí No Sí Sí Limitado

Soporte UTF-8 Sí Sí Sí Sí Sí Sí

Cumplimiento WAI Módulo

libre Sí Limitado No No Sí

XHTML estándar Sí Sí Sí No Sí Sí

Tabla 10: Compatibilidad con otras tecnologías

Flexibilidad Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Perfiles de usuario extensibles Módulo

libre Sí

Módulo libre

Sí Sí Sí

Metadatos Sí Sí Sí Sí Limitado Sí

Internacionalización Sí Sí Sí Sí Sí Sí

Sitio multilenguaje Sí Sí Módulo

libre Módulo

libre Sí Sí

Reescritura de URL Sí Sí Sí Sí Sí Sí

Tabla 11: Flexibilidad del getor

Aplicaciones incorporables Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Blog Módulo

libre Sí Sí Sí Sí Sí

Chat Módulo

libre Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Aplicaciones diversas de entrada de datos

Módulo libre

Módulo libre

Módulo libre

Módulo libre

Limitado Módulo

libre

Foros e hilos Módulo

libre Módulo

libre Módulo

libre Módulo

libre Coste

añadido Sí

Calendario de eventos Módulo

libre Sí

Módulo libre

Módulo libre

Sí Módulo

libre

FAQ Módulo

libre Módulo

libre Sí Sí Sí Sí

Formatos de correos Sí Módulo

libre Sí Sí Sí

Módulo libre

Periódico Sí Módulo

libre Módulo

libre Módulo

libre Sí

Módulo libre

Mi página de inicio Módulo

libre Sí

Módulo libre

No Limitado Módulo

libre

Galería de fotos Módulo

libre Sí

Módulo libre

Módulo libre

Sí Módulo

libre

Gestión de productos Módulo

libre Sí

Módulo libre

Sí Sí Módulo

libre

Motor de búsqueda Sí Sí Sí Sí Sí Sí



Tabla 12: Funcionalidades extensibles del gestor

Comercio Typo3 4.4.0

Plone 3.0

Mambo 4.6.1

Joomla 1.5.10


Drupal 6.10

Administración de inventario Módulo

libre Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Plugins para pasarelas de pago Módulo

libre Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Plugins para coste de portes Módulo

libre Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Plugins para impuestos y tasas Módulo

libre Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Carro de la compra Módulo

libre Módulo

libre Módulo

libre Módulo

libre Sí

Módulo libre

Suscripciones No Módulo

libre Módulo

libre Módulo

libre No

Módulo libre

Tabla 13: Integración con comercio electrónico

Quizá de todos los gestores de contenido comparados en esta tabla el que más se adapta a

las necesidades de este proyecto es Drupal. Frente a otros CMS como Plone o Joomla,

Drupal presenta un gran abanico de funcionalidades con una interfaz sencilla y una curva

de aprendizaje no muy pronunciada.

Plone es un gestor mucho más potente pero requiere un entorno de servidor más

específico, más inusual y más caro. Además, su curva de aprendizaje es mucho más

pronunciada que la de Joomla o Drupal. Por otro lado, está implementado en Python que

es un lenguaje de programación muy potente pero es menos extendido que PHP. Por lo

que es más fácil encontrar un programador que extienda la funcionalidad de un gestor

como Drupal o Joomla que la de Plone.

Joomla es sencillo y su poder radica precisamente en eso. Quizá se presenta con las

mismas características incorporables a su núcleo que Drupal, pero tiene un serio

inconveniente desde el punto de vista de este proyecto, no se adapta a los estándares de la

web.

2.11.3. Drupal

Drupal es un gestor de contenido de código abierto que nació en enero de 2001 de la

mano de Dries Buytaert y Hans Snijder, dos estudiantes de la Universidad de Amberes. El

nombre de Drupal [Drupal, 2011], pronunciado en inglés “Droo-puhl”, deriva de la

pronunciación inglesa de la palabra flamenca “druppel” que significa arrastrar.

Inicialmente nació en el año 2000 como intento de red social para compartir ficheros e

ideas entre grupos de estudiantes y no fue hasta 2001 cuando derivó en lo que es ahora,

gracias al desarrollo y colaboración de la comunidad.

En 2008 salió la versión 6 que se hizo eco entre grandes nombres como MTV UK, Lifetime,

SONY BMG Records. También medios periodísticos como New York Observer, The Onion o

las revistas Popular Scince o Fast Company.



Drupal permite crear y organizar muchos tipos de contenido, proporciona herramientas

de gestión de usuarios para administradores y visitantes de su sitio web y da acceso a

miles de módulos y complementos de terceros para añadir nuevas funcionalidades.

A un nivel más conceptual, la pila de Drupal es la que se muestra en la Figura 8. Se podría

decir que es como una capa intermedia entre el entorno -de Internet- y la interfaz -lo que

se ve en un navegador.

CSS

Base de datos (MySQL, PostgreSQL)PHP

JavaScript

HTML

DRUPAL

Sistema de temas

Módulos core (User, Node, Block, …)

Subsistemas core

Servidor Web (Apache, Light, IIS, …)

Sistema Operativo (Linux, Windows, Mac, …)

Módulos contribuidos (Fivestar, Calendar, CCK, …)

Figura 8: Pila de un sitio web con la arquitectura de Drupal integrada

En las capas inferiores se encuentra el sistema operativo, el servidor web y la base de

datos. El sistema operativo realiza tareas de bajo nivel como controlar las conexiones de

red y los permisos de los archivos. El servidor web consigue que esa máquina sea accesible

desde Internet sirviendo los dominios. Y la base de datos mantiene toda la información del

sitio web que se ha creado. Es decir, toda la información que necesita Drupal para

funcionar, ajustes de configuración, cuentas de usuario, todo el contenido del sitio, etc.

Aunque PHP se muestra en la capa más baja de la arquitectura, este lenguaje está presente

en todo el código de Drupal ya que es su lenguaje de implementación. Esta capa es en la

que se refleja un requisito del sistema imprescindible para que Drupal funcione, una

abstracción entre la base de datos y Drupal.



Por encima de esta capa, aparece Drupal con los subsistemas del núcleo (core) que

manejan la sesión de usuario y autenticación, filtro de seguridad, e interpretación de

plantillas. Sobre esta capa aparecen los módulos que permiten añadir una funcionalidad

personalizable y generar los contenidos de cualquier página dada. Pero antes de mostrar

la página se pasará a través del sistema de temas que permite modificar y alterar la

presentación de la misma hasta adaptarla a las necesidades del diseñador.

Por último aparece la capa de salida que generalmente se presenta en XHTML. CSS se

utiliza para los estilos del diseño y JavaScript para los elementos dinámicos de la interfaz

administrativa de Drupal.

Los módulos de Drupal se pueden definir como un conjunto de archivos que contienen

código PHP y que proporcionan funcionalidades administrativas para el usuario en Drupal.

Se puede hablar de dos tipos de módulos en Drupal: módulos del núcleo (core) y

módulos contribuidos.

Módulos core: son los que se incluyen en la instalación original de Drupal. Algunos

de estos módulos son requeridos por el sistema y no se pueden desactivar. Otros

son opcionales y pueden activarse o desactivarse según las necesidades del sitio

web.

Módulos contribuidos: son proporcionados por la comunidad Drupal y deben ser

descargados y habilitados en Drupal para su uso de forma separada. Este tipo de

módulos suelen centrarse en hacer una sola cosa, pero hacerla bien y poder

combinarse con otros módulos.

Estos módulos son los que generan el contenido de una página determinada. [Byron,

2010]

Administración de contenido

Para Drupal cualquier contenido que se visualiza en un sitio web es un nodo. Y cada nodo

tendrá sus campos que le aporten toda la información necesaria.

Los nodos son uno de los bloque de construcción más importante de Drupal. Cuando se

realiza el diseño de un sitio web, uno de los pasos más importante es decidir con qué clase

de información se va a trabajar -referido por Drupal como “tipos de contenido”-. En casi

todos los casos, cada uno será un tipo diferente de nodo.

Todos los nodos, sin importar el tipo de contenido que almacenan, comparten una serie de

propiedades básicas:

Un Autor (el usuario del sitio web que creó el contenido).

Una fecha de creación.

Un título.

Contenido principal.



Además de los fundamentos y propiedades comunes de los nodos, todos ellos pueden

aprovecharse de ciertas funcionalidades integradas en Drupal, como flags que indican si se

encuentran publicados o no y ajustes para controlar cómo se visualiza cada tipo de nodo.

Los permisos para crear y editar cada tipo de nodo pueden ser también asignados a

diferentes roles de usuario.

La visualización de un tipo de nodo en Drupal tiene dos modos, la vista teaser y la vista

full-node. Ambas vistas permiten configurar qué información se quiere mostrar en ellas y

cómo se verá esa información. Es decir, la función de tema que se utilizará para ver esa

información. Para entenderlo mejor, supóngase el siguiente ejemplo:

Existe el tipo de nodo “Libro” que tiene, además de la información básica, un campo de

autores y una foto con la portada del libro. Se quiere que el campo autores no aparezca en

la vista de teaser, pero sí en la vista full-node y que la portada se vea en el teaser con un

tamaño de 80x100 y en la otra al 100% de su tamaño. A través de los ajustes de vista de

los campos (del inglés, display fields) de un tipo de nodo, Drupal permitirá configurar este

tipo de cosas.

Drupal viene configurado inicialmente con solamente dos tipos de nodo: Página e Historia.

Se pueden crear nuevos tipos de nodo como noticias, eventos, etc. Pero, ¿qué ocurre si se

necesitan más campos para almacenar más información que el título y el cuerpo? Los

módulos contribuidos, además de nuevas funcionalidades en Drupal, también permiten

añadir al sistema nuevos tipos de nodo y nuevos campos a los tipos de nodo.

Instalar módulos contribuidos para añadir funcionalidades adicionales a Drupal es una

tarea común en este gestor. A lo largo de este TFC se hablará de varios módulos instalados

para conseguir funcionalidades incluidas en la especificación de requisitos para este nuevo

sitio web.

Administración de usuarios

Otro bloque de construcción de Drupal son los usuarios. El usuario que se crea por defecto

cuando se instala Drupal es “user 1”. Este usuario es especial porque cuenta con permisos

para realizar cualquier acción sobre el gestor y sobre el sitio web. Dado que esta cuenta

elude cualquier control común de seguridad (permisos para crear, editar o borrar

contenido, o desinstalar funcionalidades en uso), se deben crear otros usuarios para la

edición diaria.

Los usuarios en Drupal están asociados a roles y es a estos últimos a los que se le asignan

permisos específicos sobre módulos. Estos permisos suelen ser del tipo: visualizar tipos de

contenido específicos, publicar tipos de nodos, crear, editar o borrar tipos de nodo, etc. Por

defecto, Drupal crea dos tipos de roles, usuario anónimo y usuario autenticado. Cualquier

usuario creado en Drupal, pertenece al rol “usuario autenticado”, y cualquier usuario que

visita la página sin autenticarse forma parte del rol “usuario anónimo”.



Según se van añadiendo módulos es necesario configurar los permisos de los roles sobre

las funcionalidades que integran éstos, ya que por defecto ningún rol tendrá permisos

sobre el mismo.

Administración de bloques

Los bloques son contenedores independientes de información que pueden ser situados en

diferentes partes del sitio web. Es decir, se pueden colocar en cualquiera de las regiones

definidas en el tema. Internamente son consultas en SQL sobre la base de datos que

muestran una información concreta.

El contenido mostrado en los bloques puede ser generado manualmente por un usuario, o

automáticamente por un módulo -core o contribuido-. Drupal tiene creados por defecto

algunos bloques como la búsqueda o el inicio de sesión entre otros.

Existe una página donde administrar los bloques, a través de la cual se puede ubicar a los

bloques en la región donde situarlo, las páginas del sitio web donde se va a poder ver este

bloque o qué usuarios pueden verlo.

Administración de temas

La gestión de temas que hace Drupal se hace en colaboración con los módulos. Se podría

decir que cada módulo tiene su propia gestión del tema, de manera que se puede

conseguir visualizar el contenido que gestiona dicho módulo de manera particular.

Para ello en la Figura 9 se muestra una visión global sobre el funcionamiento del sistema

de temas. Cada ruta en Drupal corresponde a un nodo concreto que es responsable de

tratar la solicitud de página. Por ejemplo, la ruta node/1 es manejado por el módulo

“Node” del core, admin/build/themes es manejada por el módulo “System” también del

core y así con cualquier ruta. Después de que el módulo cree los contenidos de la página,

llama al sistema de temas con una función especial llamada theme().

El sistema de temas es un motor de temas encargado de definir las partes dinámicas de la

página. El motor es capaz de configurar la estructura básica y etiquetado del contenido

para presentar la plantilla de página completa con el contenido de la página actual dentro

de ella.



Módulo Node

http://www.ejemplo.com/node/1

theme(‘node’, $node)

Motor de tema

Tema actualmente activado

Figura 9: Visión global de la tematización en Drupal

Este motor se basa en una estructura de archivos que se redefinen en cada tema según las

características del mismo.

Definición de un tema

Los temas son definidos por un archivo theme_name.info ubicado en el directorio

themes. Este archivo define los metadatos del tema, como el nombre, una descripción, la

compatibilidad con la versión del core de Drupal, y el motor de temas que se usa -en la

mayoría de los casos, phptemplate-.. Más allá de los aspectos básicos, también define las

regiones del diseño -header, footer, content, etc.-, las características que pueden ser

habilitadas desde las páginas de administración -logotipo, eslogan, nombre del sitio, etc.-,

las hojas de estilo –CSS- y los scripts –JavaScript- generales para todo el tema.

En el Código 2 puede verse la descripción inicial del tema “Bluemarine” para Drupal 6 que

usa el motor de plantillas phptemplate.

name = Bluemarine

description = Table-based muti-column theme with a marine and ash color scheme



core = 6.x

engine = phptemplate

Código 2: Cabecera del fichero bluemarine.info para definir el tema

Estos ficheros son los únicos requeridos para un tema y hacen posible la creación de éstos.

Las regiones son las zonas que se esbozan en el diseño del sitio web y que proporcionan la

estructura de contenidos en la maquetación: cabecera, menú, contenido central, barra

lateral, pie, etc. En Drupal, estas regiones permiten ubicar tanto bloques de contenidos

como otro tipo información generada por las plantillas.

Drupal trae configuradas unas regiones por defecto, asociadas al tema activo en la

instalación. Estas regiones se definen en el archivo .info tal y como recoge el Código 3. El

valor que figura dentro del corchete representa la variable en PHP con la que se podrá

imprimir el contenido de la región que representa. Este contenido se asocia a la región a

través de las páginas de administración de Drupal. Por otro lado, el valor que se muestra

tras la sentencia de asignación, es el nombre lógico que se le da a dicha región.

regions[sidebar] = Barra lateral

regions[content-top] = Contenido superior

Código 3: Definición de regiones en el fichero .info de un tema

Archivos de plantilla

Por otro lado están los archivos de plantilla cuya extensión es .tpl.php que permiten

añadir marcado adicional o mover determinados elementos a otra posición de la vista. Los

archivos de plantilla están creados en su mayoría en HTML con algo de PHP para

visualizar las partes dinámicas de la página. Comentarios, nodos, bloques, y la página

global son mapeados con sus plantillas que se nombran con el nombre del elemento que

controlan (comment.tpl.php, node.tpl.php, etc.).

Concretamente, el archivo de plantilla page.tpl.php es el que da la estructura global

cualquier página de un tema. De hecho su código marca el comienzo y el fin del (X)HTML.

El Código 4 muestra un fragmento del mismo en el que se imprime la cabecera del XHTML,

el cuerpo con la estructura de capas dentro de las cuales se mostrarán los contenidos de

las variables globales con la información a mostrar.

<?php // $Id: page.tpl.php,v 1.18.2.1 2009/04/30 00:13:31 goba Exp $ ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language-

>language ?>" lang="<?php print $language->language ?>" dir="<?php print

$language->dir ?>">

<head>

<?php print $head ?>

<title><?php print (t($head_title)); ?></title>



<?php print $styles ?>

<?php print $scripts ?>



</head>

<body>



…

<div id="wrapper-wrapper">

<div id="wrapper">

<div id="wrapper-content">

<div id="content-top">

<?php if ($breadcrumb): print $breadcrumb; endif; ?>

<?php if($top): print $top; endif; ?> 

</div> 

Código 4: Sección del archivo de plantilla page.tpl.php

Con este tipo de plantillas se pueden modificar las salidas de los elementos más globales

de Drupal, pero si se quiere poder modificar el marcado que trae por defecto para las

variables globales como $breadcrumb es necesario otros mecanismos.

Para ello cada tema trae un fichero llamado template.php cuyo contenido son funciones

en PHP que ya están definidas en el core de Drupal o bien en los módulos contribuidos y

que se redefinen para cambiar la apariencia con la que se muestran distintos elementos.

En la Figura 10 se muestra la lógica que usa Drupal para determinar qué función debe

llamar para visualizar un elemento más concreto -de un módulo contribuido- como una

fotografía, un enlace de descarga de un fichero, o una variable global del sistema como

$breadcrumb o $comment.

Drupal recorrerá una jerarquía de nombres para determinar qué versión de la función

debe emplear. Los nombres themename, phptemplate y theme son las tres posibilidades

de nombrado de funciones de tema, que van de la más específica a la más genérica. Drupal

comenzará la búsqueda por el más específico y dejará de buscar la función de tema que

aplicar en el momento que encuentre una de ellas declarada.



¿Existe una función llamada mytheme_breadcrumb()?

Se llama atheme(‘breadcrumb’, $breadcrumb)

Llama mytheme_breadcrumb()

¿Existe una función llamada phptemplate_breadcrumb()?

Llama phptemplate_breadcrumb()

Llama theme_breadcrumb()

Sí

No

No

Sí

Figura 10: Método que emplea Drupal para determinar las llamadas a funciones

Vistas

Otro elemento de construcción para un sitio web elaborado con Drupal, son las vistas o

views. Estas vistas se pueden generar gracias al módulo “Views”, un módulo contribuido de

Drupal. Este módulo permite al usuario crear bloques de contenido personalizados, así

como otro tipo de vistas que se adapten a distintas necesidades.

En muchos términos técnicos, “Views” es como un constructor visual de consultas SQL.

Cuando se crea una vista, lo que hace es construir una consulta que el módulo toma de la

base de datos del sitio web.

Este módulo presenta ventajas significativas frente a una codificación a mano.

No necesita escribir código para crear una lista de contenido.

Los módulos adicionales interactúan con “Views” para informar sobre la

información que almacenan en la base de datos cada uno. Por tanto, el usuario no

necesita conocer la base de datos internamente, para saber cómo se almacena

cada información dependiendo del módulo.

La misma vista puede ser usada para diferentes ubicaciones del sitio web.



Los resultados se pueden dividir en listados de varias páginas, usar columnas

ordenables, paginadores en AJAX, o menús desplegables.

Los tipos de vistas que permite crear este módulo son cuatro:

Attachment: Visualización complementaria que se puede mostrar encima y/o

debajo de otros tipos de visualizaciones.

Block: Crea una visualización de lista compacta que puede ser ubicada en cualquier

región de la página.

Feed: Crea un feed RSS personalizable al que se pueden suscribir los usuarios por

medio de un lector RSS.

Page: Crea una página con su propio URL donde la vista ocupa el contenido

principal.

Las vistas permiten gran cantidad de configuraciones. Hay que resaltar que permiten

asignar criterios de ordenación para la consulta, filtros para seleccionar la información a

mostrar, seleccionar el tipo de nodo o campos sobre los que se desea realizar la consulta, o

aplicarle una plantilla que estructure el HTML para crear listas, tablas, capas, etc., entre

otros. Este último ajuste comentado, es lo que hace al módulo de “Views” integrarse con la

gestión de temas de Drupal y aplicarle un tema personalizado a las vistas que se creen

para un sitio concreto. El módulo “Views” tiene archivos de plantilla -.tpl.php- para

modificar la presentación del HTML. Son varios los archivos de este tipo que tiene “Views”,

uno para cada tipo de estructura que ofrece: views-view-list.tpl.php, views-

view-unformatted.tpl.php, views-view-table.tpl.php, etc.



3. PLANTEAMIENTO DEL PROBLEMA

3.1. Estado actual del sitio web corporativo

El sitio web corporativo presenta de manera inequívoca una Fundación, cuyo contenido

principal son actividades culturales, exposiciones, publicaciones y un archivo histórico. El

diseño, mostrado en la Figura 11, de dicho sitio tiene sólo 3 años, pero su estética hace que

parezca más antiguo. Presenta un diseño a dos columnas con una resolución fija de

800x600 implementada con frames en JSP.

Figura 11: Página de inicio actual

La navegación del diseño está repartida en dos zonas. En la columna izquierda se

encuentra el bloque de navegación principal o menú principal del sitio. Su estilo es vertical

y sin elementos desplegables. En la esquina superior derecha se encuentra el menú

secundario con enlaces a la página de inicio –enlace “Inicio”-, al mapa web –enlace “Mapa



web”-, a la página del w3c –enlace “Accesibilidad”- y al formulario de contacto –enlace

Contacto-. El estilo de este menú es una serie de enlaces consecutivos en color rojo. Debajo

del menú secundario y centrado respecto al contenido principal se localiza el submenú del

menú principal. El estilo de esta navegación está basado en pestañas y botones

horizontales y se puede observar en las páginas internas, como la que se muestra en la

Figura 12.

Figura 12: Navegación interna

El bloque de vídeos de la página principal es estático: siempre reproduce los mismos

fragmentos de vídeos y no presenta controles para su reproducción (Figura 11). El resto

de enlaces del bloque son ventanas emergentes, tanto para ver los vídeos como para más

información sobre los mismos. En la Figura 13 se puede observar la ventana que se abre

cuando se reproduce un vídeo que no presenta maquetación y sólo carga el reproductor. El

reproductor es una instancia del reproductor Windows Media Player que carga el buffer

automáticamente y comienza la reproducción automáticamente.

Figura 13: Ventana del reproductor



El bloque de noticias de la página principal –ver Figura 11- es fijo en altura, se cargan 6

noticias que no deberían ocupar más de 85px de alto cada una y cuyos enlaces (“ampliar

noticia”), se abren en ventanas emergentes. Aunque lo parezcan, los títulos de las noticias

no son enlaces. Las ventanas en las que se abren los eventos tampoco conservan la estética

de la página y se ha desactivado el desplazamiento vertical por defecto del navegador para

insertar uno al contenido por CSS. Mantiene un ancho y alto fijo que no se adapta al

tamaño de la ventana –ver Figura 14-.

Figura 14: Ventana de un evento

En la Figura 15 se puede observar también cómo se muestra el resto de información de un

evento. Los documentos asociados a un evento se ponen uno detrás de otro en una

columna vertical. De la misma forma se visualizan las imágenes, a tamaño real una detrás

de otra en columna con el correspondiente pie de cada una. No se pueden adjuntar vídeos

en ningún tipo de evento. Los enlaces rotulados como “ABRIR DOCUMENTO” marcados en

azul abren otra ventana emergente con el siguiente texto:



“El tamaño del fichero puede hacer que la visualización del documento tarde varios

minutos, si lo prefiere haga clic en "Descargar" para almacenarlo y visualizarlo en su

equipo.”

Y se proporcionan dos botones uno de descarga y otro de visualización. El botón de

visualización carga el documento en una ventana nueva y cierra automáticamente la

ventana anterior.

Figura 15: Resto de información de un evento

Todos los enlaces del sitio web son dependientes de JavaScript y cualquier enlace que no

esté dentro de la navegación del menú principal generará una ventana nueva. Por el

contrario, los enlaces contenidos en el menú principal recargan los correspondientes

frames.

De manera independiente al diseño están la base de datos y el gestor de contenidos. La

base de datos en la que se almacena la información del sitio web es SQL Server con licencia

de Microsoft y el gestor de contenidos que sirve a todo el sitio web exceptuando la

editorial y su tienda es un gestor desarrollado a medida por una empresa cuya licencia es



privada. Existe un segundo CMS que controla la publicación de libros, revistas y otras

publicaciones de la Fundación, así como su tienda virtual. Éste último gestor y sitio web

externo no se va a tratar en este proyecto, ya que no se va a abarcar la parte de la tienda

virtual en el rediseño.

El gestor de contenidos principal trata cualquier bloque de contenido (noticias o

actividades) de la misma forma, es decir poseen los mismos campos a rellenar. El

formulario de alta para un evento se abre en una ventana emergente con los campos más

básicos para ese evento. La inserción de contenido adjunto al evento se debe insertar

después de haber creado dicho evento. En la Figura 16 se puede ver la primera parte de

los campos a rellenar para la creación de contenidos.

Figura 16: Formulario para dar de alta un evento en la web

Es decir, que cuando finalmente se crea un evento se debe buscar en la lista de todos los

eventos mediante un formulario de búsqueda para terminar de añadir la información que

falta. En la Figura 17 se puede observar dicho formulario de búsqueda en la parte superior

y el resultado de la búsqueda en la parte inferior.

El listado no proporciona información adicional sobre el estado de ese evento. Es decir, no

hay forma de saber si está publicado, promocionado en alguna lista, o está apareciendo en

la página inicial. Sólo cuando se edita el evento se puede comprobar si la opción

“Publicable en web” está seleccionada o no.



Respecto a la gestión de las listas de contenido es automática y se realiza por fecha. Sólo

las seis primeras noticias –no actividades- aparecen en la página principal y el hecho de

que estén visibles al inicio sólo depende de la fecha. Es decir, si se quisiese mantener una

noticia entre las primeras más tiempo habría que actualizar su fecha para que fuera más

actual que la del resto.

Figura 17: Listado de eventos dados de alta en el gestor

En la Figura 18 y Figura 19 se muestra cómo presenta el gestor los campos adicionales al

evento. En la Figura 16 no aparecían campos como temas y categoría y es en este segundo

paso donde se deben añadir. El funcionamiento para añadir temas y categorías es

mediante una ventana emergente que proporciona las opciones disponibles para cada

campo a modo de lista (Figura 19). Cuando una opción es seleccionada automáticamente

se cierra la ventana (Figura 19) y se inserta el valor en la ventana anterior (Figura 18). El

botón “Cerrar” de la ventana con las opciones sólo está pensado por si no se selecciona

ninguna opción disponible.

En la Figura 18 también se puede ver una sección rotulada como “Recursos”. Se

consideran recursos a imágenes, documentos, enlaces y organizaciones. El funcionamiento

para añadir recurso es mediante ventanas emergentes que contienen formularios. El

formulario para recursos presenta un campo de selección que permite elegir entre “URL”,

“Imagen” y “Otros”. En el momento en el que se selecciona cualquiera de ellas se recargan



los campos que aparecen a continuación, requiriendo la información necesaria para la

opción elegida.

Figura 18: Formulario para añadir información adicional al evento ya creado

El caso de la opción URL muestra dos campos de texto, Nombre y Leyenda. La opción

Imagen presenta el formulario que aparece reflejado en la Figura 20. Para poder adjuntar

una imagen a un evento primero hay que subir el fichero al gestor mediante el botón

“Subir fichero” y luego seleccionarla en el campo con el botón “Examinar”. Se desconoce el

propósito de la opción “Otros”.

La imagen por defecto no se redimensionará, sino que se mostrará en el tamaño original.

La opción disponible para modificar el tamaño en que se visualizará en la página es

asignándole un ancho y alto en píxeles. El nombre y la leyenda son el título y el pie de foto

de la imagen.

Como se ha podido comprobar la edición de contenidos es una tarea tediosa que cuesta

aprenderla y realizarla correctamente. Además, esta forma de gestionar los contenidos

tampoco está haciendo que la generación de los mismos se haga de forma correcta, es

decir que la visualización del contenido no es buena y el código generado no es correcto.



Figura 19: Lista de valores para el campo Temas

Tal y como está implantado el gestor de contenidos, la Fundación no dispone de permisos

de administración del mismo. Es decir, no puede crear usuarios nuevos con menos

privilegios, no puede cambiar la información del bloque de vídeos de la página de inicio,

no puede editar las páginas estáticas del menú Fundación, etc.

Figura 20: Formulario para adjuntar una imagen a un evento

3.2. Problemas que presenta el sitio web actual

Con las características presentadas en el apartado anterior es posible obtener gran

número de errores, problemas y necesidades suscitadas. Para valorar los problemas que



presenta el sitio actual se ha realizado una evaluación heurística de la usabilidad del

mismo y una evaluación de accesibilidad.

Este es el punto en el que se deben establecer de manera clara y concisa los objetivos del

sitio web.

Dar a conocer esta Fundación, a qué se dedica y sus líneas de trabajo.

Difundir sus actividades culturales, exposiciones y publicaciones.

Poner a disposición del público en general el material generado de cada una de las

actividades que se han realizado como pueden ser: vídeos, transcripciones o

conclusiones de ponencias, catálogos editados con las muestras de las

exposiciones, fotografías, etc.

Poner al servicio de quien lo necesite la consulta de los fondos del archivo

documental, fotográfico y de carteles del que dispone y gestionar la propiedad

intelectual de los mismos.

Ser un punto de venta de sus revistas trimestrales, libros, catálogos y

documentales.

3.2.1. Resultados de la evaluación heurística del sitio corporativo

Tomando como referencia el trabajo presentado en [González, et al, 2010] y la lista de

verificación propuesta por [Hassan, et al, 2003b] se ha elaborado una lista de heurísticas

que se recoge en la Tabla 25 del Anexo A de este Trabajo. Por otro lado, la evaluación

heurística se ha llevado a cabo por tres evaluadores, cuyos resultados se encuentran

compuestos en la Tabla 27 del mismo anexo. Estos evaluadores han valorado la severidad

sólo en dos de los tres factores, el impacto y la frecuencia. Para poder dar un valor

cuantitativo de la usabilidad del sitio web corporativo, se han convertido los resultados

obtenidos en valores de porcentajes individuales de cada grupo de heurísticas y

porcentajes globales sobre el total de heurísticas para poder analizarlos. Esos porcentajes

corresponden con valores de no usabilidad del sitio web.

En la Tabla 14 se recoge el resumen de la evaluación para cada grupo y el peor caso

posible. Se ha optado por estudiar los resultados como porcentajes, aunque ya se puede

ver que la navegación supera el valor medio de no usabilidad para su peor valor que es 84.

Grupo Frecuencia Impacto Peor caso

Diseño 50 51 124

Navegación 51 46 84

Organización 20 20 56

Funcionalidades 16 17 36

Tabla 14: Resumen de la evaluación



Para calcular el porcentaje de no usabilidad de cada grupo se ha calculado el peor caso

para cada uno de ellos y se ha dividido por el resultado obtenido de la evaluación. En la

Tabla 15 se muestran esos porcentajes con su gráfica.

Grupo Frecuencia Impacto

Diseño 40,32% 41,13%

Navegación 60,71% 54,76%

Organización 35,71% 35,71%

Funcionalidades 44,44% 47,22%

Tabla 15: Porcentajes de no usabilidad

En la Figura 21 se puede observar cómo todos los grupos presentan un alto porcentaje de

no usabilidad, lo que quiere decir que el sitio web no fue diseñado pensando en el usuario

y por tanto no es usable.

Figura 21: Diagrama de barras que representa el porcentaje de no usabilidad por grupo de heurísticas

La navegación representa la peor heurística evaluada para los dos factores (frecuencia e

impacto). El que los valores de frecuencia e impacto se desvíen tanto entre sí se debe a que

heurísticas como la que mide los enlaces rotos no supongan lo mismo desde el punto de

vista de la frecuencia o el impacto. En este caso, el número de enlaces rotos no es elevado,

luego su frecuencia es baja, pero el impacto que conlleva que el usuario se los encuentre es

elevado, porque puede que por ello no encuentre lo que busque y se vaya del sitio.

Los valores obtenidos en funcionalidades también son elevados y nuevamente sus valores

de frecuencia e impacto se desvían bastante entre sí. Esto se debe a algo parecido a lo que

pasa con los enlaces rotos. La ayuda no tiene por qué ser siempre necesaria en un sitio

web, pero existen casos en los que se debe tener. Un caso para necesitar esta ayuda puede

,000%10,000%20,000%30,000%40,000%50,000%60,000%70,000%

Porcentaje de no usabilidad por grupo

Frecuencia

Impacto



ser el hecho de que la información esté organizada de una determinada manera, siguiendo

ciertos criterios específicos que no son los esperados por el público objetivo.

Aunque el grupo de heurísticas funcionalidades tenga un porcentaje tan elevado de no

usabilidad, no representa tanto sobre el global. En la Tabla 16 se muestra el porcentaje de

cada grupo sobre el total de las heurísticas y su en la Figura 22 su representación gráfica.

Grupo Porcentaje

Diseño 16,67%

Navegación 17,00%

Organización 6,67%

Funcionalidades 5,33%

Tabla 16: Porcentaje sobre el total

Con esta gráfica se puede observar fácilmente cómo el diseño y la navegación son las más

representativas frente al porcentaje global de usabilidad del sitio web. Lo que quiere decir

que si no fuesen tan altos los porcentajes individuales del grupo funcionalidades y

organización, corrigiendo los otros dos obtendríamos un porcentaje de no usabilidad

bueno, ya que podría llegar a estar por debajo del 25%, que sería como un 7,5 de

usabilidad.

La no usabilidad global del sitio web está por encima del 45% lo que quiere decir que la

nota obtenida en usabilidad está por debajo del 5,5, siendo las heurísticas que más afectan

a dicha usabilidad global, la navegación y el diseño. Por lo que no se puede decir que el

grado de usabilidad sea bueno.

,000%

5,000%

10,000%

15,000%

20,000%

25,000%

30,000%

35,000%

40,000%

45,000%

50,000%

Porcentaje

Funcionalidades

Organización

Navegación

Diseño

Figura 22: Porcentaje de no usabilidad de cada heurística frente al total



3.2.2. Evaluación de accesibilidad del sitio web

Dado que se desconoce si existen plantillas de estilo para las páginas del sitio sería

necesario realizar la evaluación sobre cada página del mismo, pero el volumen de

información es tal que no sería viable. Por lo que la evaluación se ha realizado sobre un

conjunto de páginas representativo. Estas evaluaciones se han agrupado en la Tabla 17. La

evaluación de accesibilidad se ha hecho sobre las WCAG 1.0, ya que el sitio web tiene el

logo de conformidad de éstas para un nivel AA. Como apoyo para la evaluación de las

WCAG 1.0 se ha utilizado la herramienta HERA [Sidar, 2005]

WCAG 1.0 Resultado de la evaluación

Pto Nivel Descripción Bien Mal N/A Explicación

1.1 A

“Proporcione un texto equivalente para todo elemento no textual (p. ej. a través de “alt‟, “longdesc‟ o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto (incluyendo símbolos), áreas de mapas de imagen, animaciones (p. ej. GIF animados), applets y objetos programados, ASCII art, marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin la interacción del usuario), archivos exclusivamente auditivos, pista sonora del vídeo y vídeos”

X

Existen a imágenes con alt y ninguno es correcto. Además, las imágenes del sitio se meten sin alt, por tanto ninguna imagen o foto posee el atributo. Existe un vídeo que no tiene alternativo.

1.2 A

“Proporcione enlaces redundantes en formato texto para cada área activa de un mapa de imagen del servidor”

X No hay mapas de imagen en el servidor

1.3 A

“Hasta que las aplicaciones de usuario puedan leer en voz alta, automáticamente, el texto equivalente de la pista visual de una presentación multimedia; proporcione una descripción sonora de la información importante de la pista visual”

X El único vídeo que hay en el sitio web no presenta subtítulos ni audiodescripción para saber qué es lo que se está viendo.

1.4 A

“Sincronice con la presentación equivalentes alternativos (p. ej. subtítulos o descripciones sonoras de la pista visual) para cualquier presentación multimedia tempo-dependiente (p. ej. una película o animación)”

X Este punto de verificación falla por el mismo motivo que el anterior. El único vídeo del sitio carece de alternativos



1.5 AA

“Hasta que las aplicaciones de usuario interpreten los textos equivalentes de los enlaces de los mapas de imagen de tipo cliente, proporcione enlaces redundantes, en formato texto, para cada zona activa del mapa de imagen de tipo cliente”

X No hay mapas de imagen en el sitio web

2.1 A

“Asegúrese de que toda la información transmitida a través del color está también disponible sin color, por ejemplo mediante el contexto o el marcado”

X

No se usa el color para transmitir información

2.2 AA, AAA

“Asegúrese de que las combinaciones de color del fondo y del primer plano contrastan lo suficiente cuando son vistas por alguien que tiene una deficiencia de percepción del color o que utiliza un monitor en blanco y negro”

X Prioridad 2 para imágenes

X Prioridad 3 para texto. Existen colores de fondo y primer plano que no contrastan lo suficiente con textos.

3.1 AA

“Utilice marcadores en vez de imágenes para transmitir información, si existe un lenguaje de marcado apropiado”

X

Se utilizan imágenes para transmitir información. Los enlaces de navegación son imágenes a modo de botones con el texto del mismo.

3.2 AA “Cree documentos que se ciñan a las gramáticas formales publicadas”

X

Las páginas carecen de DTD (declaración del tipo de documento) por lo que no se puede evaluar su sintaxis y el código CSS posee 690 errores.

3.3 AA “Use hojas de estilo para controlar la disposición y la presentación”

X Se utilizan elementos HTML (<b>) y propiedades HTML (<img border="">) para controlar la presentación

3.4 AA

“Use unidades relativas en vez de absolutas en los valores de los atributos del lenguaje de marcado y en los valores de las propiedades de las hojas de estilo”

X Usa unidades absolutas en el CSS

3.5 AA

“Use elementos de encabezado para sugerir la estructura del documento y úselos siguiendo la especificación”

X

No se usan correctamente. Los frames de contenido interno carecen de H1-H6. Sólo se usa uno en el marco principal, que haya uno no es suficiente.

3.6 AA “Marque correctamente las listas y los ítem de lista”

X Los enlaces de navegación deberían estar marcados como una lista y no como una tabla

3.7 AA “Marque las citas. No use el marcado de citas para efectos de formato tales como la sangría”

X No se utilizan los marcados de cita para lograr efectos sobre el texto. Ni es necesario marcar ninguna cita

4.1 A

“Identifique claramente los cambios en el lenguaje natural del texto de un documento y de cualquier texto equivalente (p. ej. leyendas)”

X No se han detectado cambios de idioma en los textos

4.2 AAA “Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera

X En algunos textos aparecen acrónimos como UNED que carecen de marcado



vez en el documento”

4.3 AAA “Identifique el lenguaje natural principal de un documento”

X No se ha identificado el idioma en el HTML, además existe una versión en inglés y tampoco está indicado

5.1 A “En las tablas de datos, identifique los encabezados de fila y columna”

X

Toda la maquetación está hecha con tablas y ninguna información requiere presentarse de manera tabular por lo que no es necesario marcado semántico para la tabla.

5.2 A

“Para las tablas de datos que tengan dos o más niveles lógicos de encabezados de fila o columna, utilice marcadores para asociar las celdas de datos con las celdas de encabezado”

X No hay tablas de datos

5.3 AA

“No use tablas para maquetar, a menos que el contenido de la tabla tenga sentido cuando se represente en forma lineal. De lo contrario, si la tabla no se entiende, proporcione un equivalente alternativo (que puede ser una versión lineal del contenido de la tabla)”

X La representación lineal de la tabla es correcta

5.4 AA

“Si utiliza una tabla para maquetar, no utilice ningún marcado estructural para conseguir un efecto visual de formateo”

X No se utiliza marcado estructural para conseguir efectos visuales

5.5 AAA “Proporcione resúmenes de las tablas”

X No hay tablas de datos, por lo que no necesitan atributos semánticos

5.6 AAA “Proporcione abreviaturas para las etiquetas de los encabezamientos”

X No hay tablas de datos, por lo que no hay encabezamientos de tablas

6.1 A

“Organice los documentos de forma que puedan ser leídos sin hojas de estilo. Por ejemplo, cuando un documento HTML es interpretado sin las hojas de estilo asociadas, debe seguir siendo posible leer el documento”

X La página no se carga correctamente cuando se desactivan las hojas de estilo.

6.2 A

“Asegúrese de que los equivalentes para el contenido dinámico se actualizan cuando cambia el contenido dinámico”

X

No hay contenido dinámico que cambie. El vídeo de la página principal es siempre el mismo (secuencias de distintos documentales)

6.3 A

“Asegúrese de que las páginas pueden seguir siendo usadas cuando los scripts, applets u otros objetos de programación se desconectan no son soportados. Si esto no es posible, proporcione

X Todos los enlaces del sitio web dependen de javascript, por lo que no se puede navegar por ella sin dicha tecnología.



información equivalente en una página alternativa accesible”

6.4 AA

“Para los scripts y applets, asegúrese de que la ejecución de los manejadores de evento sea independiente del tipo de dispositivo”

X

Los manejadores de evento son dependientes de dispositivo. De hecho, los enlaces de navegación dependen de eventos onclick para poder lanzar la acción

6.5 AA

"Asegúrese de que los contenidos dinámicos sean accesibles o proporcione una página o presentación alternativas”

X

El vídeo es un contenido dinámico y no es accesible ni presenta alternativa alguna. No hay controles para el vídeo, no hay subtítulos o audiodescripciones ni información sobre qué se está viendo

7.1 A

“Hasta que las aplicaciones de usuario permitan al usuario controlarlo, evite provocar el parpadeo de la pantalla”

X Ninguna página provoca parpadeos

7.2 AA

“Hasta que las aplicaciones de usuario permitan al usuario controlar el destello, evite que el contenido destelle (por ejemplo, los cambios en la presentación a ritmo regular, como si se encendiera y apagase)”

X No hay destellos en la página.

7.3 AA

“Hasta que las aplicaciones de usuario permitan congelar el contenido en movimiento, evite el movimiento en las páginas”

X Existe un vídeo que comienza a reproducirse solo y no puede detenerse

7.4 AA

“Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el refresco, no cree páginas que periódicamente se auto-refresquen”

X Ninguna de las páginas del sitio se autorefresca

7.5 AA

“Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el re-direccionamiento automático, no utilice marcadores para redirigir las páginas automáticamente. En su lugar, configure el servidor llevar a cabo los re-direccionamientos”

X Existe un redireccionamiento, pero es transparente al usuario, ya que se hace en el servidor

8.1 A

“Cree los elementos de programación tales como scripts y applets de manera que sean directamente accesibles o compatibles con las ayudas técnicas”

X Los scripts son dependientes de dispositivo, por tanto no son compatibles con todas las ayudas técnicas

9.1 A

“Proporcione mapas de imagen controladas por el cliente en vez de por el servidor, excepto cuando las áreas no puedan ser definidas con una forma geométrica”

X No hay mapas de imagen en este sitio web



9.2 AA

“Asegúrese de que cualquier elemento que tenga su propia interfaz pueda manejarse de forma independiente del tipo de dispositivo”

X El reproductor de la página principal no tiene una interfaz de manejo independiente de dispositivo

9.3 AA

“Para los scripts, especifique manejadores de evento lógicos en vez de manejadores de evento dependientes del dispositivo”

X

Los manejadores son dependientes de dispositivo

9.4 AAA

“Cree un orden lógico de tabulación a través de los enlaces, controles de formulario y objetos”

X

Existe un orden lógico de tabulación dentro de las páginas, tanto en los formularios como en la secuencia de enlaces de las páginas

9.5 AAA

“Proporcione atajos de teclado para los enlaces importantes (incluyendo los de los mapas de imagen de tipo cliente), controles de formulario y grupos de controles de formulario”

X No existe ningún atajo de teclado

10.1 AA

“Hasta que las aplicaciones de usuario permitan a los usuarios desactivar la generación de ventanas, no provoque que aparezcan llamadas emergentes u otras ventanas y no cambie el foco de la ventana actual sin informar antes al usuario”

X Hay enlaces que abren ventanas nuevas y no se indica al usuario de esta acción

10.2 AA

“Hasta que las aplicaciones de usuario soporten asociaciones explícitas entre las etiquetas y los controles de formulario, para todos los controles de formulario con etiquetas implícitamente asociadas, asegúrese de que la etiqueta está colocada adecuadamente”

X

Se usan elementos de formulario fuera de formularios como un input para poner un enlace a la página principal con el logotipo conmemorativo de la empresa.

10.3 AAA

“Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) interpreten correctamente los textos contiguos, proporcione un texto alternativo lineal(en la misma página o en alguna otra) para todas las tablas que presenten el texto en columnas paralelas, y desplazan el texto automáticamente a la siguiente línea cuando no cabe en la misma”

X Esta condición ya se ha satisfecho, por lo que no es aplicable



10.4 AAA

“Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por omisión en los campos de edición y áreas de texto”

X Esta condición ya se ha satisfecho

10.5 AAA

“Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) representen de forma diferenciada los enlaces adyacentes, incluya caracteres imprimibles no enlazados(rodeados de espacios) entre los enlaces adyacentes”

X Existen enlaces consecutivos sin caracteres imprimibles que los separe

11.1 AA

“Utilice las tecnologías del W3C cuando estén disponibles y sean apropiadas para la tarea, y use las últimas versiones en cuanto sean soportadas”

X Todas las páginas del sitio web carecen de DTD.

11.2 AA “Evite usar elementos obsoletos de las tecnologías del W3C”

X Se usan elementos obsoletos

11.3 AAA

“Proporcione información de manera que los usuarios puedan recibir los documentos según sus preferencias (p. e. idioma, tipo de contenido...)”

X

No hay forma de conseguir el material adaptado a las necesidades del usuario porque no hay un formulario de contacto para solicitarlo.

11.4 A

“Si, a pesar de haberse esforzado, no consigue crear una página accesible, proporcione un enlace a una página alternativa que use las tecnologías del W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible”

X La página no es accesible y no se proporciona una alternativa

12.1 A “Titule cada marco para facilitar la identificación del marco y la navegación entre ellos”

X

La mayor parte de los contenidos del sitio web está construido con marcos y ninguno de ellos tiene título o descripción que los relaciones

12.2 AA

“Describa el propósito de los marcos y cómo se relacionan entre sí, si no resulta obvio sólo con los títulos de marco”

X No se proporciona información sobre los marcos ni su relación. No están accesibles



12.3 AA

“Divida los bloques de información largos en grupos más manejables cuando resulte natural y apropiado”

X

Es el caso contrario, el exceso de división hace que existan demasiadas páginas con poco contenido (dos párrafos o incluso uno)

12.4 AA “Asocie etiquetas explícitamente con sus controles”

X Se usan mal los elementos de formulario

13.1 AA “Identifique claramente el objetivo de cada enlace”

X

No se conoce el propósito de muchos enlaces de la página, ya que están fuera del contexto con el que tienen relación, porque están repetidos y apuntan a distintos sitios, o porque carecen de atributo title para saber a dónde llevan.

13.2 AA “Proporcione metadatos para añadir información semántica a las páginas y los sitios”

X No hay metadatos en ninguna de las páginas

13.3 AA

“Proporcione información sobre la maquetación general de un sitio (por ejemplo, un mapa del sitio o tabla de contenidos)”

X Se ofrece un mapa del sitio, pero no está bien construido.

13.4 AA “Utilice mecanismos de navegación de manera consistente”

X La navegación cambia de lugar, de estilo y de organización.

13.5 AAA

“Proporcione barras de navegación para resaltar y dar acceso al mecanismo de navegación”

X

La navegación se presenta de muchas formas, pero nunca como una barra. Quizás esto no sería tan importante si siempre se mostrase igual.

13.6 AAA

“Agrupe los enlaces relacionados, identificando el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de saltarse el grupo”

X

El menú de navegación es una tabla, para poder saltarlo debería ser una lista, tener algún encabezado o utilizar scripting para controlar su visibilidad.

13.7 AAA

“Si proporciona funciones de búsqueda, facilite diferentes tipos de búsquedas para diversos niveles de habilidad y preferencias”

X

Se proporciona un buscador en un par de páginas internas que carece de búsqueda avanzada y además no funciona, ya que el servicio siempre está fuera de servicio



13.8 AAA “Coloque información distintiva al comienzo de encabezados, párrafos, listas, etc.”

X

La información más importante no está colocada en la zona más importante de la jerarquía visual. Las opciones del menú llegan a ocupar más del 50% del espacio de la página.

13.9 AA

“Proporcione información sobre las colecciones de documentos(por ejemplo, los documentos que comprendan múltiples páginas)”

X No hay colecciones de documentos

13.10 AAA “Proporcione un medio para saltar sobre un arteASCII que ocupa varias líneas”

X No hay ningún arte ASCII en el sitio web

14.1 A “Utilice el lenguaje más claro y sencillo que sea apropiado para el contenido de un sitio”

X Hay textos que se presentan como si se almacenase la información en una base de datos.

14.2 AAA

“Complemente el texto con presentaciones gráficas o sonoras cuando ello facilite la comprensión de la página”

X Existen fotografías e imágenes que dan contexto y facilitan la comprensión del texto

14.3 AAA “Cree un estilo de presentación que sea consistente en todas las páginas”

X No todas las páginas son iguales. El estilo cambia, hay ventanas huérfanas

Tabla 17: Evaluación de las WCAG 1.0 en el sitio web corporativo

Como se ha podido observar hay un gran número de puntos de verificación que están mal.

En la Figura 23 se resume el resultado de la evaluación proporcionada por la herramienta

de evaluación HERA.

Figura 23: Resumen de la evaluación de las WCAG 1.0 para el sitio web antiguo

Las conclusiones que se pueden sacar de esta evaluación es que el sitio web corporativo

actual no es accesible en un nivel AA de las WCAG 1.0, ya que no se cumplen todos los

puntos de verificación de prioridad 1 y prioridad 2 y no se ofrece alternativa accesible

para aquellos casos en los que no se cumple dichos puntos.



Por tanto lo primero que habría que hacer en el sitio web es quitar el logo de conformidad

WAI – AA de las WCAG 1.0 y con los estándares del W3C. Seguidamente se pasa a valorar

las soluciones para corregir los fallos y plantear el rediseño.

3.2.3. Fallos de prioridad 1 y posibles soluciones

De entre los 9 fallos de prioridad 1, no serían imposibles de corregir puntos de verificación

como el 1.1, 1.3 o el 1.4 si no fuese porque dependen del gestor de contenidos. Es decir,

dotar de atributo alt a las imágenes sólo es posible si el gestor de contenidos permitiese

rellenar ese campo, pero no se recoge dicha información. Por otro lado, el gestor de

contenidos no permite configurar el reproductor que se utiliza en la página principal, por

lo que no se pueden subir subtítulos, audiodescripción o dotar al reproductor de barra de

reproducción.

Los fallos de los puntos 6.3 y 8.1 dependen de cómo está implementado por dentro el

gestor de contenidos, es decir que cada vez que se crean enlaces a través del gestor éste

los transforma en llamadas a eventos de jsp (Código 5). Lo cual tampoco tiene una

solución posible.

<a

href="javascript:AbrirVentana2('evento.jsp?accion=leer&clase=es.intecna.fp

i.estructura.Evento&cod_evento=325',563,400);" class="enlaceRojo">ampliar

noticia</a>

Código 5: Código de un enlace en el sitio web antiguo

El fallo del punto 6.1, que tiene que ver con la visibilidad de la página sin CSS, y el 12.1 que

tiene, que ver con el título de los marcos están relacionados entre sí. Ambos fallos se

deben a cómo se están generando las plantillas de estilo del gestor de contenidos que hace

uso y abuso de frames. Esta característica no se puede corregir sin modificar el gestor de

contenidos. Por último, el fallo 11.4 es fruto de no haber realizado una evaluación del sitio

web.

Por tanto, para poder solventar estos fallos la única solución pasa por buscar otro gestor

de contenidos que trate la información con otras tecnologías de la web y que sea conforme

a los estándares de las mismas, ya que el gestor de contenidos actual es de licencia privada

y no se puede modificar ni administrar.


Los fallos de prioridad 2 que tienen que ver con el marcado se deben a una mala

estructura de las plantillas y a una mala elección del DTD. Cuanto más permisivo es el DTD

que se elige más tendencia habrá a cometer errores de accesibilidad y más problemas se

encontrarán de compatibilidad con los nuevos navegadores debido al uso de elementos y

atributos obsoletos de HTML. Aunque el DTD no está especificado en las páginas del sitio

web -lo que provoca el fallo del punto 3.2-, se puede saber por el código generado cuál se

está usando: XHTML frameset.



Por ejemplo el fallo en el punto de verificación 3.3 que hace referencia a las hojas de estilo

para controlar la presentación de las páginas, se podría haber evitado usando un DTD

Strict, ya que la validación de este DTD no permite elementos de presentación ni atributos

de presentación dentro del cuerpo del código.

Respecto al resto de fallos que tienen que ver con el marcado son los puntos 3.5, 3.6, 10.1,

10.2, 11.2, 12.2, 12.3 y 12.4 que hacen referencia al uso de encabezados, al marcado de

listas, a la generación de ventanas, al uso de formularios, al uso de elementos o atributos

obsoletos, a las propiedades de los marcos y al uso de marcado para crear bloques de

información. Todos estos fallos se podrían evitar generando un maquetación sin tablas y

siguiendo una estructura sintácticamente correcta y semánticamente rica haciendo uso de

elementos de marcado como p, ul, ol, h1-h6, etc. para agrupar los bloques de

información relacionados.

Se desconoce cuáles son las plantillas de estilo utilizadas para generar estas páginas.

Cuando se está usando un gestor de contenidos, las plantillas de estilo suelen depender del

mismo, por lo que no se propone corregir dicha plantilla ni reutilizarla debido al cambio

de gestor de contenido. Se tendrán en cuenta todas estas características para que en el

nuevo gestor las plantillas se adapten a estas necesidades.


Los puntos de verificación de prioridad 3 suelen ser difíciles de conseguir y más para sitios

webs corporativos en los que la edición de contenidos depende de varias personas. Por

ello, el W3C no aconseja su compromiso para este tipo de sitios. Por otro lado, siempre

estará bien en la medida de lo posible intentar cubrir aquellos que no sean “imposibles”.

Dentro de aquellos que no son un imposible de cumplir, ya que no dependen de la

generación de contenido sino de la definición de la plantilla de estilo, son los puntos de

verificación 4.3, 9.5, 13.5, 13.6, 13.8 o 14.3.

El punto 4.3 cubre la identificación del idioma principal de la página, que se define en la

cabecera html. El punto 9.5 habla de los accesskey, que también se pueden definir por

plantilla en algunos casos. Los puntos 13.5 y 13.6 tienen que ver con el diseño de la página

y la manera en la que se crea el menú principal de navegación y cómo se asocian los

grupos de enlaces relacionados, por tanto estos puntos se podrían cumplir haciendo un

diseño con listas para los enlaces relacionados y creando una barra de navegación que se

oculta por script. El punto 13.8 tiene que ver con la jerarquía visual y cómo se aprovechan

las zonas más altas de esta jerarquía para destacar la información más relevante. Por

último, el punto 14.3 también tiene que ver con la presentación de las páginas dentro del

sitio web. Este punto se estaría cumpliendo en el momento en el que cualquier página

dentro del sitio web mantuviese una consistencia en el diseño respecto del resto.



Con estas correcciones sobre la plantilla de estilo se estarían cumpliendo 6 puntos de

verificación de prioridad 3 para las WCAG 1.0 de los 9 fallos que hay sólo quedarían 3 por

satisfacer.

De esos 3 que son el 4.2, 11.3 y 13.7, los dos últimos dependen de la funcionalidad que

proporcione el sitio web (búsqueda avanzada y solicitud de documentos adaptados). El 4.2

tiene que ver con el marcado de abreviaturas y acrónimos en el contenido, se convierte en

un imposible de controlar.

Por tanto para las WCAG 1.0 sería viable satisfacer hasta 11 de los 19 puntos de

verificación de prioridad 3 definidos dejando sólo uno (4.2) sin cumplir.

3.3. Conclusiones de los fallos

En los apartados 3.1 y 3.2 donde se han presentado las evaluaciones de usabilidad y

accesibilidad se ha dejado plasmado la gran cantidad de cambios que habría que realizar

para corregir todo lo que está mal. Se podría pensar en un simple rediseño y

reestructuración del sitio para mejorar la usabilidad del mismo y con ello la experiencia

del usuario, manteniendo de este modo el gestor de contenidos actual. Pero se estaría

dejando de lado algo tan importante como la accesibilidad del contenido que se presenta.

Esto quiere decir, que no sólo importa lo que visualmente se transmite, sino también lo

que internamente se transmite.

Por tanto, mantener un gestor de contenidos como este no sería beneficioso a largo plazo,

ya que la dependencia de ciertas tecnologías seguiría latente y la dificultad para encontrar

la información también. Hay que recordar que la encontrabilidad externa de la

información, aunque se mejorase la organización de los contenidos, no tendría solución

debido a cómo presenta la información el gestor de contenidos.

Por tanto, en el apartado siguiente se inicia la solución al problema con una especificación

de requisitos software que guiará la implementación y diseño del nuevo sitio web.

El motor que impulsa el desarrollo del nuevo sitio corporativo es la evidencia de una

creciente complicación y dificultad en la gestión de los contenidos y los graves problemas

de accesibilidad e indexación de los mismos en el sitio actual.

Se parte de la existencia de un sitio web que usa un gestor de contenidos que no puede

modificarse para solventar los errores que presenta, debido a la licencia privada del

mismo. Además, la información no tiene un buen diseño de sus campos no recogiendo así

todas las necesidades suscitadas por las actividades culturales que se realizan en la

Fundación. Por otro lado, la arquitectura de la información tampoco es correcta y tampoco

puede ser corregida ya que ésta depende de poseer privilegios de administración sobre

ese gestor y se carecen los mismos.



3.4. Introducción de la Especificación de Requisitos Software

A partir de esta sección se va a encontrar una Especificación de Requisitos Software (ERS)

para el nuevo sitio web corporativo de la Fundación.

Esta Fundación es española y su presupuesto depende tanto de donaciones privadas como

de fondos y subvenciones públicas por lo que se ha visto afectada por la legislación

española que regula la accesibilidad de las páginas web. Esto junto con problemas técnicos

en la gestión de la información en el sitio web actual ha planteado la realización de un

nuevo sitio web corporativo que permita un mejor manejo de la información y un diseño

más accesible y novedoso.

Esta especificación se ha estructurado inspirándose en las directrices dadas por el

estándar “IEEE Recommended Practice for Software Requirements Specification ANSI/IEEE

830 1998”.

3.4.1. Propósito

El objetivo de la especificación es definir de manera clara y precisa todas las

funcionalidades y restricciones del sitio que se desea construir. Esta sección va dirigida al

grupo de desarrollo, a la empresa de diseño y a la Junta Directiva de la Fundación. Esta

especificación será el canal de comunicación entre las partes implicadas, tomando parte en

su confección miembros de cada parte.

Esta especificación ha estado sujeta a revisiones, que se recogieron por medio de

versiones, hasta alcanzar su aprobación por las partes implicadas. Una vez aprobada sirvió

de base para la construcción del nuevo sistema.

3.4.2. Ámbito del sistema

El futuro sitio presentará un diseño renovado en el que esté disponible toda la

información de las actividades que realiza esta Fundación: exposiciones, actividades

culturales de otra índole, edición de libros, etc.

El nuevo sitio web permitirá relacionar las noticias con las actividades culturales y en un

futuro los contenidos de la editorial con del resto de actividades culturales. De manera que

se gestione toda la información a través de un único gestor de contenidos.

Por otro lado, deberá cumplir con la legislación vigente sobre accesibilidad web y lograr

que se posicione en los buscadores. Además, permitirá la realización de búsquedas dentro

del sitio mediante la indexación de sus contenidos.

El gestor de contenidos deberá permitir su administración completa para al menos un

usuario (el administrador) y permitir la creación de otros roles con menos privilegios para

la edición de contenidos.



La página principal del sitio web deberá recoger toda la información actualizada que está

realizando la Fundación, así como cuáles son los próximos eventos que se realizarán

cuando se conozcan. En un futuro también deberá mostrar las últimas publicaciones que

han salido.

El futuro sitio web no contemplará la funcionalidad de la tienda virtual para la editorial de

la Fundación, que permita la compra de libros, revistas, catálogos o audiovisuales que

publica, dejándose ésta para futuras líneas de trabajo. En esta versión del sitio web

tampoco se va a contemplar la funcionalidad de gestión y consulta del archivo histórico.

3.4.3. Definiciones

Término Definición

Usuario autenticado Aquella persona que tiene permisos para la edición de contenido en el gestor.

Usuario anónimo Aquella persona que carece de permisos para acceder al gestor y visita la página para consultar información.

Administrador Aquella persona que posee todos los permisos sobre el gestor de manera que accede a todas sus características de configuración.

Evento Toda aquella actividad cultural (exposiciones, conferencias, debates, etc.) que realiza la Fundación a la cual puede asistir todo el público en general.

Página principal Es la primera página del sitio web situada en la raíz del dominio. Es lo que se conoce como home o index.

Visor de anuncios Es una herramienta que permite mostrar imágenes con eslogan mediante una transición de una a otra con un tiempo de exposición para cada una. Tabla 18: Definiciones de la especificación de requisitos

3.4.4. Visión general de las siguientes secciones

Este apartado - Introducción de la Especificación de Requisitos Software - junto con los

dos siguientes forman un documento de Especificación de Requisitos Software (ERS). Esta

sección es la Introducción y proporciona una visión general de la ERS. En la sección

“Descripción general (ERS)” se da una descripción general del sistema, con el fin de

conocer las principales funciones que debe realizar, los datos asociados y los factores,

restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos

detalles. En la sección “Requisitos específicos” se definen con más detalle los requisitos

que debe satisfacer el sistema.

3.5. Descripción general (ERS)

En esta sección se presenta una descripción del alto nivel del sitio. Se presentarán las

principales áreas a las cuales el sitio debe dar soporte, las funciones que el sitio debe

realizar, la información utilizada, las restricciones y otros factores que afecten al

desarrollo del mismo.



3.5.1. Perspectiva del producto

El objetivo es que tanto los usuarios como el administrador puedan acceder al sitio desde

cualquier navegador web actual. Tanto los usuarios autenticados como el administrador

deberán tener facilidad de acceso a las funcionalidades del gestor. Lo ideal es que no

dependan nunca de terceras personas para hacer cambios en el contenido, o para realizar

cambios en el estilo o funcionalidades del sitio.

El sitio, en principio, se elaborará sobre un gestor de contenidos de libre distribución que

permita la edición de diversos tipos de contenidos web (incluidos vídeos, documentos e

imágenes) y que interactúe con un sistema de envío de correo electrónico para recoger

sugerencias, fallos de accesibilidad o cuestiones. A su vez, se quiere que el gestor

interactúe con un sistema de monitorización del tráfico del sitio web. En un plazo medio

de tiempo se desea que permita la inserción y venta de publicaciones que edita la editorial

de la Fundación (vía PayPal u otra pasarela de pago).

3.5.2. Funciones del sistema

En términos generales el nuevo sitio web corporativo deberá proporcionar las siguientes

funcionalidades:

Consulta y edición de noticias sobre la Fundación.

Consulta y edición de eventos que realice la Fundación.

Relación bidireccional entre noticias y eventos.

Monitorización del tráfico y obtención de estadísticas del sitio.

Envío de correo para dudas, consultas o fallos detectados.

Por otro lado, como aspectos no funcionales el sitio deberá:

Ser accesible según la legislación española.

Estar montado sobre un gestor de contenidos de fácil manejo y administración.

Base de datos fácilmente extensible, de cara a la posible fusión con los contenidos

del archivo histórico de la Fundación.

Lograr un mejor posicionamiento en los buscadores web más utilizados del

mercado.

A continuación se detallan algo más las características funcionales del sitio.

Consulta y edición de noticias sobre la Fundación

El objetivo de las noticias es mantener al día a los usuarios no autenticados de los eventos

que se realizan e informar de todo aquello que sea de interés para la Fundación (la

emisión de un documental producido por la misma, el incremento de fondos del archivo

histórico, las intervenciones de su presidente o director, etc.).



Para ello, el gestor debe proporcionar un tipo de contenido “noticia” que contenga los

campos de título, descripción, fecha de publicación, una fotografía y la relación con su

evento en caso de existir. Además, se quiere que la noticia pueda relacionarse con los

temas que aborda la Fundación en sus actividades (memoria histórica, política social,

economía, etc.). De esta manera se puede clasificar el contenido mediante una temática

común.

Por otro lado, el sitio proporcionará una consulta de todas las noticias publicadas

mediante algún sistema de paginación o algún elemento que muestre el listado de manera

acotada.

Consulta y edición de eventos que realice la Fundación

Los eventos pueden ser actividades tales como conferencias, debates, seminarios o

exposiciones. Todos ellos requieren que el gestor de contenidos permita almacenar de

alguna forma campos tan diversos como vídeos, galerías fotográficas, documentos (textos

de ponencias, invitaciones, trípticos, etc.), la fecha de realización y dónde va a tener lugar

dicho evento.

Para los campos de fecha y lugar hay que tener en consideración los eventos que son

exposiciones. Una exposición puede ser itinerante y por tanto, tener varios valores para

dichos campos.

Para el campo de documentos hay que considerar que se quiere poder almacenar

cualquier formato para los mismos, ya sea pdf, doc, txt, etc. Además, se quiere poder

proporcionar al usuario distintos formatos para un mismo documento.

Para el campo de vídeos hay que considerar las opciones de accesibilidad para cumplir con

la legislación. Los vídeos deben estar disponibles para la descarga de los usuarios cuando,

por algún motivo no se puedan ver en la misma página.

También hay que considerar que los eventos estarán relacionados con los mismos temas

que las noticias.

El sitio proporcionará una consulta de todos los eventos realizados por la Fundación

clasificados según el tipo de evento que sea: conferencia, curso, debate, encuentro,

jornada, mesa redonda, presentación, seminario o exposición; mediante algún sistema de

paginación o algún elemento que muestre el listado de manera acotada.

Relación bidireccional entre noticias y eventos

Se quiere poder relacionar las noticias con los eventos de tal forma que un evento pueda

tener ninguna, una o más noticas relacionadas y una noticia pueda tener relación con

ninguno o con un evento.



Esta relación deberá permitir la consulta entre elementos relacionados. Es decir, que se

podría consultar el evento relacionado desde una noticia. No se pretende que el evento

muestre todas sus noticias relacionadas.

Monitorización del tráfico y obtención de estadísticas del sitio

El gestor debe permitir de alguna forma, (o bien integrando algún sistema externo, o bien

porque posee la funcionalidad) la monitorización del tráfico del sitio web. Esta

funcionalidad deberá obtener datos de diversa índole (número de visitas recibidas y el

origen de las mismas, las páginas más visitadas y el tiempo de las visitas, etc.) y

proporcionar estadísticas sobre ellos.

Envío de correo para dudas, consultas o fallos detectados

El gestor debe permitir de alguna forma, (o bien integrando algún sistema externo, o bien

porque posee la funcionalidad) el envío de mensajes de correo electrónico tanto para

consultas, sugerencias o fallos detectados por medio de correo electrónico sin que las

direcciones de los mismos estén a disposición de los usuarios no autenticados para evitar

el envío de correo basura (spam).

El gestor permitirá derivar los correos a distintas direcciones en función del tema de la

consulta. El usuario no autenticado podrá elegir a qué departamento enviar su consulta.

En un primer momento se evitará el uso de herramienta de detección de spam –o

CAPTCHA (del inglés, Completely Automated Public Turing test to tell Computers and

Humans Apart)- por los problemas de accesibilidad que presentan. En caso de recepción

masiva de spam en un futuro se querrá disponer de una funcionalidad de CAPTCHA o

similar para intentar evitar el abuso de este servicio.

3.5.3. Características de los usuarios

El sitio web deberá ofrecer una interfaz simple, clara y renovada de manera que se

asemeje lo más posible a los diseños más comunes en la web. Con esto se pretende

conseguir que un usuario no autenticado acostumbrado a navegar por Internet no tenga

que realizar ningún esfuerzo por comprender el uso y la navegación del nuevo sitio.

El gestor de contenidos deberá ofrecer una interfaz de usuario lo más parecida posible a

un formulario web para la edición de contenido, de manera que sea fácil de aprender y

sencillo de manejar. Lo ideal sería que un usuario autenticado nuevo, con el único

prerrequisito de ser una persona acostumbrada al uso de un navegador web, se familiarice

con él en una hora.

http://es.wikipedia.org/wiki/Prueba_de_Turing



3.5.4. Restricciones

Dado que el gestor implementará la política y los procesos actualmente vigentes es de

esperar que futuros cambios en los modos de trabajo o en las políticas, ejerzan cierto

impacto sobre la configuración del gestor.

Debido a que el espacio de almacenamiento en el servidor es limitado y tiene un coste

asociado se deberá tener en cuenta aprovecharlo al máximo limitando el tamaño de los

archivos que puedan publicarse, tales como fotos, documentos o vídeos.

Una restricción importante es la naturaleza de la infraestructura software que se vaya a

utilizar, pues siempre será preferible utilizar software libre. Por tanto, se descarta el uso

de herramientas de gestión de contenidos de pago. El gestor de contenidos que se utilizará

será Drupal por la gran comunidad de desarrolladores que trabajan en él y la cantidad de

material de apoyo que tiene. Además, cubre todas las funcionalidades requeridas por el

sitio web.

Una restricción derivada de la elección del gestor es el uso del lenguaje de programación

PHP y del sistema gestor de bases de datos MySQL.

Asimismo la especificación de requisitos tendrá en consideración las restricciones

derivadas del Real Decreto 1494/2007 por el que se aprueba el Reglamento sobre las

condiciones básicas para el acceso de las personas con discapacidad a las tecnologías,

productos y servicios relacionados con la sociedad de la información y medios de

comunicación social.

3.5.5. Suposiciones

En esta especificación se expresan los requisitos en términos de lo que el sitio debe

proporcionar a los usuarios -no autenticados- que acceden a él para consultar y lo que el

gestor debe proporcionar a los usuarios –autenticados- que acceden a él para editar el

contenido. No obstante, el sitio no proporcionará nada útil a menos que haya alguien que

introduzca los datos. Se asumirá, por tanto, que (1) los usuarios autenticados serán los

responsables de realizar una carga inicial de datos, a partir de los datos actuales; (2)

quedarán eximidos los usuarios autenticados de la carga inicial de aquellos datos que por

su naturaleza se consideren no modificables (presentación, dónde estamos, patronato,

etc.) cayendo esta obligación sobre el administrador; y (3) se definirán responsabilidades

relativas al alta de nuevos eventos, así como del alta de otros datos que se consideren

necesarios sobre los mismos usuarios autenticados.

Se asume que los requisitos descritos en estas secciones son estables una vez que sean

aprobadas por la Junta Directiva de la Fundación. A partir de ese momento, cualquier

petición de cambios en esta especificación deberá ser aprobada por todas las partes,

previo análisis del impacto que dicha petición de cambio supondrá para el sitio, para el

gestor o para los usuarios.



3.5.6. Dependencias

En el día a día, el gestor se comunicará con los sistemas de envío de correos y de

monitorización del tráfico del sitio, de manera que el funcionamiento de estos servicios no

afecte a la visibilidad del sitio web.

Queda pendiente la posibilidad de interactuar con sistemas de pago por internet, tipo

PayPal, que permitan la compra por Internet de las publicaciones de la editorial.

Por otro lado, el sitio web presentará de manera temporal dependencias con otros

servidores para consultar el contenido del archivo histórico y la tienda virtual que permite

la compra de publicaciones. Las dependencias de la consulta de la biblioteca serán

permanentes, ya que el servicio lo proporciona una universidad.

3.6. Requisitos específicos

En este apartado se presentan los requisitos funcionales y no funcionales -requisitos de

calidad, fiabilidad, seguridad, usabilidad, etc.- que deberán ser satisfechos por el sistema.

Cada uno de ellos tiene un número y, además, los requisitos funcionales tienen un nombre

breve.

Cada requisito tiene asignada una prioridad de implementación, que puede ser alta,

media o baja. La prioridad alta es para aquellas funciones cuya ausencia no sería tolerable

en el futuro sitio. La prioridad media es para aquellas que necesitan más discusión.

Finalmente, la prioridad baja es para las funciones que no son necesarias ahora, pero

deberán incorporarse en el medio-largo plazo.

3.6.1. Requisitos funcionales

Aspectos generales

R-FUN-1: Búsqueda

Descripción: El sitio web debe proporcionar un formulario de búsqueda sencillo (que no permita añadir filtros a los términos de la búsqueda) de todo su contenido.

Razón: Permitir encontrar la información que necesita un usuario.

Prioridad: Alta Dificultad: Media Dependencias:

R-FUN-2: Opciones de publicación

Descripción: El gestor debe permitir retirar contenido publicado, de tal forma que no se pueda consultar dicho contenido desde el sitio web por un usuario no autenticado. Del mismo modo, el gestor debe permitir publicar contenido ya creado, de tal forma que se pueda consultar. La información sobre el estado de publicación de un contenido no debe ser visible por un usuario no



autenticado.

Razón: Ocultar o mostrar contenido según convenga sin necesidad de eliminar o volver a crear un mismo contenido.

Prioridad: Alta Dificultad: Baja Dependencias:

R-FUN-3: Temas relacionados

Descripción: El gestor debe almacenar una lista de temas relacionados pendientes de definir comunes a todo tipo de contenido (noticias y eventos). Esta lista sólo la podrá editar el administrador y será visible para el resto de usuarios.

Razón: Permitir realizar consultas sobre cualquier tipo de contenido mediante una clasificación por temas.


R-FUN-4: Obtención de estadísticas

Descripción: El gestor debe permitir la integración de la herramienta externa Google Analytics. De esta forma el administrador podrá acceder periódicamente a esta herramienta para obtener toda clase de datos estadísticos producidos por el acceso y uso del sitio web. Quedarán excluidas de estas estadísticas las páginas de administración, así como las visitas de los usuarios autenticados, ya que este uso es exclusivo del personal de la Fundación y no aporta información relevante.

Razón: Permitir analizar el uso que se hace de los servicios que ofrece el sitio web.


R-FUN-5: Envío de consultas

Descripción: Todos los usuarios podrán hacer uso de un formulario web para enviar consultas, dudas o sugerencias. Este formulario deberá generar un correo electrónico que se derivará a los distintos departamentos automáticamente en función de la selección que realice el usuario. Las opciones a seleccionar son: actividades culturales, administración, archivo y biblioteca, consulta sobre el sitio, editorial, exposiciones y presidencia. Cada una de ellas enviará la consulta a los buzones de los respectivos departamentos. Los campos que se recogerán son: el nombre, la dirección de correo electrónico, el departamento, el asunto y la consulta. La dirección de correo se usará para enviar una respuesta automática agradeciendo el uso del servicio. Se debe ocultar en todo momento las direcciones de correo utilizadas en los departamentos, incluso en la respuesta automática. Debido a la dependencia con el R-NFUN- 6 no se incorporará detección de spam.

Razón: Permitir otra forma de contacto con la empresa.

Prioridad: Alta Dificultad: Media Dependencias: R-NFUN- 6



R-FUN-6: Envío de comentarios de accesibilidad

Descripción: Todos los usuarios podrán hacer uso de un formulario web para enviar posibles problemas de accesibilidad detectados o para solicitar material adaptado a sus necesidades. Este formulario deberá generar un correo electrónico que se enviará al administrador del sitio web. Los campos que se recogerán son: el nombre, la dirección de correo electrónico, el asunto y la consulta. La dirección de correo se usará para enviar una respuesta automática agradeciendo el uso del servicio. Se debe ocultar en todo momento las direcciones de correo utilizadas, incluso en la respuesta automática. Debido a la dependencia con el R-NFUN- 6 no se incorporará detección de spam.

Razón: Obtener un feedback sobre accesibilidad en el sitio web.

Prioridad: Alta Dificultad: Media Dependencias: R-NFUN- 6

Gestión de usuarios

R-FUN-7: Alta de usuario

Descripción: El administrador podrá crear usuarios autenticados, proporcionando el nombre de usuario y contraseña. El gestor no debe permitir el alta de más de un usuario con el mismo nombre. Las contraseñas deben ser almacenadas de forma cifrada.

Razón: Permitir la existencia de usuarios autenticados para la edición de contenido sin privilegios de administración.


R-FUN-8: Baja de usuario

Descripción: El gestor debe permitir sólo al administrador borrar usuarios autenticados mediante el nombre de usuario. Los contenidos editados por este usuario autenticado permanecerán en el gestor conservando su autoría, pese a que su usuario deje de ser válido en el sistema. No se podrá eliminar un usuario que no haya sido previamente creado.

Razón: Denegar el acceso al gestor.

Prioridad: Alta Dificultad: Baja Dependencias: R-FUN-7

R-FUN-9: Modificación de usuario

Descripción: El gestor debe permitir modificar el nombre de usuario y la contraseña. La modificación de estos datos no podrá violar lo expuesto en el R-FUN-7 sobre la duplicidad de nombres en el gestor.

Razón: Permitir la renovación de contraseñas, reasignar contraseñas en caso de olvido, o corregir errores en el nombre.




R-FUN-10: Consulta de usuarios

Descripción: El gestor debe permitir listar todos los usuarios autenticados que hay dados de alta en el mismo. Esta opción sólo estará disponible para el administrador.

Razón: Permitir conocer los usuarios que hay en el gestor.


R-FUN-11: Login de usuarios

Descripción: El gestor debe permitir el acceso a usuarios autenticados y administradores mediante un nombre de usuario y una contraseña. Esta autenticación debe ser persistente manteniendo al usuario conectado hasta que éste cierre sesión.

Razón: Permitir el acceso de los usuarios autenticados al gestor.


R-FUN-12: Administración de permisos

Descripción: El gestor debe permitir administrar permisos al menos para, crear, borrar, editar y consultar tipos de contenido y el acceso a las distintas páginas de administración tanto para usuarios autenticados como no autenticados. Esta opción sólo estará disponible para el administrador.

Razón: Por motivos de seguridad en el sitio.


Gestión de noticias

R-FUN-13: Alta de noticias

Descripción: El gestor debe permitir crear nuevas noticias a los usuarios autenticados con los permisos específicos para realizar esta acción. Las noticias se definirán con un identificador único automático e incremental. En la noticia se debe almacenar los siguientes campos:

Título

Cuerpo de la noticia con un resumen

Autoría (fecha de creación y autor)

Estado de publicación (según recoge el R-FUN-2)

Fotografía: Este campo debe ser obligatorio. También se debe recoger un texto alternativo asociado a la misma. Sólo se admitirán archivos en formato .jpg, .png y .gif. Se debe comprobar que el tamaño del archivo no sea superior 500KB y que su resolución sea al menos de 670x320. El campo debe poder ser consultado tanto por usuario autenticados como no autenticados y sólo podrá ser editado por usuarios autenticados con permiso.



Evento relacionado: Este campo no es obligatorio. Sólo se hará uso de él cuando sea necesario relacionar una noticia con un evento. Debe permitir seleccionar un evento ya existente en el gestor mediante su título. Este campo debe poder ser consultado por todo tipo de usuarios y editado sólo por usuarios con permisos.

Temas relacionados: Este campo es obligatorio. Debe permitir elegir uno o varios temas relacionados previamente definidos. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Razón: Crear nuevas noticias.

Prioridad: Alta Dificultad: Alta Dependencias: R-FUN-2

R-FUN-14: Baja de noticia

Descripción: El gestor debe permitir borrar una noticia de manera todos sus campos también sean eliminados. Para el campo “fotografía” su archivo asociado será eliminado del sistema. Esta acción sólo la podrán realizar los usuarios autenticados con permisos para ello o el administrador.

Razón: Eliminar una noticia.


R-FUN-15: Modificación de noticia

Descripción: El gestor debe permitir la modificación de los campos referentes a una noticia. Los campos que se modifiquen estarán sujetos a las restricciones marcadas en el R-FUN-13. Para el caso concreto de la Fotografía que conlleve un cambio de archivo supondrá la eliminación del archivo previo existente en el sistema. Esta acción sólo podrán realizarla los usuarios autenticados con permisos para ello o el administrador.

Razón: Corregir posibles errores, actualizar información, etc.


R-FUN-16: Consulta de noticias

Descripción: El gestor debe permitir consultar todas las noticias existentes. Esta consulta devolverá una página con las noticias ordenadas por fecha de publicación. Si el número de noticias es mayor de ocho, se repartirá la consulta en varias páginas y se permitirá navegar entre ellas mediante algún mecanismo de paginación. La consulta de estos listados mostrará para cada noticia: el título, la fecha de publicación, la fotografía en tamaño de 80x80px, y un resumen de su texto.

Razón: Poder mostrar todas las noticias.




Gestión de eventos

R-FUN-17: Alta de evento

Descripción: El gestor debe permitir crear nuevos eventos a los usuarios autenticados con los permisos específicos para realizar esta acción. Los eventos se definirán con un identificador único automático e incremental. En el evento se debe almacenar:

Título

Descripción con un resumen del mismo

Autoría (fecha de creación y autor)

Estado de publicación (según recoge el R-FUN-2)

Fotografía: Este campo debe ser obligatorio. También se debe recoger un texto alternativo asociado a la misma. El formato de la imagen debe ser .jpg, .png o .gif. El tamaño del archivo no debe superar los 500KB de tamaño y su resolución debe ser al menos de 670x320. El campo debe poder ser consultado tanto por usuarios autenticados como no autenticados y editable sólo por autenticados.

Fecha de realización: Este campo debe ser obligatorio. Se debe recoger tanto la fecha de inicio como la de fin, en caso de que el evento dure más de un día. Este campo puede tener más de un valor en caso de las exposiciones debido a la itinerancia de las mismas. El campo debe poder ser consultado tanto por usuarios autenticados como no autenticados y editable sólo por autenticados.

Lugar: Este campo es obligatorio. Debe recoger el nombre de la ubicación, la dirección y el teléfono de contacto en caso de disponer de él. Este campo puede tener más de un valor en caso de las exposiciones debido a la itinerancia de las mismas. El campo debe poder ser consultado tanto por usuarios autenticados como no autenticados y editable sólo por autenticados.

Horario: Este campo no es obligatorio. No debe establecer un formato fijo en el horario dejando libertad al usuario. El campo debe poder ser consultado tanto por usuarios autenticados como no autenticados y editable sólo por autenticados.

Cómo llegar: Este campo no es obligatorio. Se debe poder almacenar un mapa de la ubicación del lugar y una pequeña ayuda textual que indique las diversas formas de llegar al sitio en caso de ser conocidas.

También se debe poder almacenar información adicional del evento como pudieran ser: las empresas colaboradoras, las personas que lo coordinan, dirigen o exponen, además de cualquier otra información que no pueda incluirse en los campos anteriores.

Temas relacionados: Este campo es obligatorio. Debe permitir elegir uno o varios temas relacionados previamente definidos. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Tipo de evento: Este campo es obligatorio. Se debe recoger el tipo de evento del que se trata, pudiendo ser: exposición, conferencia, curso, debate, encuentros, grupos de reflexión, jornadas, mesas redondas, presentaciones y seminarios. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Galería fotográfica: Este campo no es obligatorio. Debe permitir almacenar las posibles instantáneas que se tomen de un evento. Los formatos de los archivos serán jpg o png. Estos archivos deben llevar asociado un título y un texto descriptivo. El archivo no debe superar los 500KB de tamaño y su resolución debe ser al menos de 600x600. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Vídeos: Este campo no es obligatorio. Debe permitir almacenar cualquier vídeo que pueda generarse en la realización de un evento, pudiendo existir más de uno. El formato del archivo debe ser flv o mp4. El tamaño del archivo no debe superar los 100MB y su



resolución debe ser 480x320. Los vídeos tienen un título y una descripción breve de lo que tratan. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Documentos asociados: Este campo no es obligatorio. Debe permitir almacenar cualquier tipo de documentación que genere el evento: textos de ponencias, invitaciones, formularios de inscripción, trípticos o similares. Los formatos de los archivos deben ser txt, doc, ppt, o pdf. Estos documentos deben poder almacenarse en distintos formatos, incluso existiendo un mismo documento en varios de estos formatos. Los documentos tienen un título y una descripción asociados. Este campo debe ser visible para cualquier usuario y editable sólo para usuarios autenticados.

Razón: Recoger los eventos que se realizan.


R-FUN-18: Baja de evento

Descripción: El gestor debe permitir borrar un evento de manera que todos sus campos también sean eliminados. Para aquellos campos que requirieron un archivo externo (fotografía, galería, vídeo, documentación, etc.), dicho archivo asociado será eliminado del sistema. Esta acción sólo la podrán realizar los usuarios autenticados con permisos para ello o el administrador.

Razón: Eliminar un evento.


R-FUN-19: Modificación de un evento

Descripción: El gestor debe permitir la modificación de los campos referentes a un evento. Los campos que se modifiquen estarán sujetos a las restricciones marcadas en el R-FUN-17. Cuando el cambio se realice sobre archivos asociados, supondrá la eliminación del archivo previo existente en el sistema. Esta acción sólo podrán realizarla los usuarios autenticados con permisos para ello o el administrador.



R-FUN-20: Consulta de eventos

Descripción: El gestor debe permitir consultar todos los eventos existentes. Esta consulta devolverá una página con los eventos de un mismo tipo ordenados por fecha de realización del evento. Si el número de eventos es mayor que ocho, se repartirá la consulta en varias páginas y se permitirá navegar entre ellas mediante algún mecanismo de paginación. La consulta de estos listados mostrará para cada evento: el título, la fotografía en tamaño de 160x110px, la última fecha de realización del evento y un resumen de su texto.

En la consulta individual de un evento los campos de fecha y lugar mostrarán todos sus valores, del más actual al más antiguo. Para los campos de galería fotográfica y vídeos deberá existir algún



mecanismo de navegación para poder moverse entre sus elementos (tipo scroll o paginador). Para los documentos asociados existirá la posibilidad de consultar el formato que se desee cuando éste esté disponible.

Razón: Mostrar todos los eventos.


Gestión de anuncios

R-FUN-21: Alta de anuncio

Descripción: El gestor debe permitir crear anuncios de los eventos próximos y actuales a los usuarios autenticados con los permisos específicos para realizar esta acción. Los anuncios se definirán con un identificador único. En el anuncio se deben almacenar:

Imagen: Este campo debe ser obligatorio. El formato del archivo debe ser jpg, png o gif. Se debe comprobar que el tamaño del archivo no sea superior 250KB y que su resolución sea de 670x155. El campo debe poder ser consultado tanto por usuario autenticados como no autenticados y editable sólo por autenticados.

Eslogan: Este campo es obligatorio. Se debe recoger un eslogan para el anuncio. El campo debe poder ser consultado tanto por usuario autenticados como no autenticados y editable sólo por autenticados.

Fecha del evento: Este campo es obligatorio. Esta fecha se debe corresponder con las fechas de realización del evento. El campo debe poder ser consultado tanto por usuario autenticados como no autenticados y editable sólo por autenticados.

Evento relacionado: Este campo es obligatorio. Debe permitir seleccionar un evento ya existente en el gestor mediante su título. Este campo debe poder ser consultado por todo tipo de usuarios y editado sólo por usuarios con permisos.

Razón: Crear nuevas publicaciones.

Prioridad: Alta Dificultad: Alta Dependencias:

R-FUN-22: Baja de anuncio

Descripción: El gestor debe permitir borrar un anuncio de manera que todos sus campos también sean eliminados. Para el campo “imagen” su archivo asociado será eliminado del sistema. Esta acción sólo la podrán realizar los usuarios autenticados con permisos para ello o el administrador.

Razón: Eliminar un anuncio.


R-FUN-23: Modificación de un anuncio

Descripción: El gestor debe permitir la modificación de los campos referentes a un anuncio. Los campos que se modifiquen estarán sujetos a las restricciones marcadas en el R-FUN-21. Cuando el cambio se realice sobre archivos asociados, supondrá la eliminación del archivo previo existente en



el sistema. Esta acción sólo podrán realizarla los usuarios autenticados con permisos para ello o el administrador.



R-FUN-24: Consulta de anuncios

Descripción: El gestor debe permitir consultar los anuncios de los cuatro eventos más próximos o actuales en el tiempo. Esta consulta devolverá los anuncios ordenados por fecha de realización del evento del más futuro al más actual. Esta consulta estará disponible para todos los usuarios sólo en la página principal del sitio web.

Razón: Mostrar anuncios en la página principal.


3.6.2. Requisitos no funcionales

R-NFUN- 1: Interfaz de usuario del gestor

Descripción: La interfaz de usuario del gestor debe ser orientada a formularios y accesible a través de un navegador web.

Razón: Facilitar el manejo y el aprendizaje.

Prioridad: Alta Dificultad: Ninguna Dependencias:

R-NFUN- 2: Integridad de la información

Descripción: Es importante disponer de un sistema de copias de seguridad automatizado, que permita volver a un estado anterior consistente ante una incidencia. Este sistema debe realizar el respaldo diariamente almacenando toda la base de datos del gestor, así como todo el sistema de directorios y archivos que éste usa para su administración. Por otro lado, los archivos de información, debido a su tamaño sólo se respaldarán una vez por semana. El número de copias de seguridad que hay que almacenar debe ser 7 para el gestor y dos para los archivos.

Razón: Asegurar la disponibilidad de la información.

Prioridad: Alta Dificultad: Alta Dependencias: R-FUN-7, R-FUN-13, R-FUN-17, R-FUN-21

R-NFUN- 3: Mantenimiento del gestor

Descripción: El gestor avisará de sus revisiones de mantenimiento cuando existan versiones más nuevas o de seguridad del core, así como de los módulos adicionales que integre. Para el mantenimiento será necesario desconectar el sitio web durante el tiempo que lleve realizar las



actualizaciones. El estado de desconexión mostrará un mensaje de sitio desconectado a los usuarios que intenten acceder en ese momento lo que no provocará un error de acceso al servidor. Las tareas de mantenimiento se llevarán a cabo a través de la interfaz web del gestor y las actualizaciones de ficheros a través de un servidor ftp. Esta funcionalidad sólo estará disponible para el administrador.

Razón: Garantizar la seguridad del sitio. .


R-NFUN- 4: Mantenimiento del sitio

Descripción: El sitio web será revisado cada seis meses para asegurar su accesibilidad y su usabilidad. Por otro lado, se revisarán los fallos o problemas de los que se informe a través del formulario de accesibilidad que está disponible en el sitio con el fin de mejorar el servicio. Además, se actualizará su información diariamente.

Razón: Garantizar la accesibilidad, usabilidad y servicios del sitio web.


R-NFUN- 5: Seguridad en el login

Descripción: El acceso al gestor deberá utilizar algún mecanismo que preserve la privacidad de los datos utilizados para el acceso. Las contraseñas se almacenarán encriptadas en la base de datos.

Razón: Impedir el acceso a cualquier persona ajena a la empresa.


R-NFUN- 6: Detección de spam

Descripción: En un primer momento se rechaza la opción de utilizar cualquier herramienta de detección de correo no deseado (spam) en los formularios de consulta y accesibilidad. Esto se debe a los problemas de accesibilidad en el contenido que estas herramientas suelen provocar. En caso de que en un determinado, momento el número de mensajes recibidos de spam sea mayor que el número de mensajes de consulta, se estudiará la viabilidad de una herramienta anti-spam.

Razón: No dificultar el acceso a los formularios al mayor número de personas posibles.


R-NFUN- 7: Accesibilidad en los contenidos

Descripción: Todos los contenidos que se vayan publicando en el sitio web por los usuarios autenticados con permisos para ello, serán revisados periódicamente acorde a lo estipulado en el R-



NFUN- 4. Pese a estas revisiones, se dará un curso de formación sobre accesibilidad en los contenidos web a los usuarios que tengan que realizar esta labor.

Razón: Generar contenidos accesibles.

Prioridad: Alta Dificultad: Alta Dependencias: R-NFUN- 4

R-NFUN- 8: Navegación del sitio web

Descripción: Se creará un único bloque de navegación. Este bloque será una barra de navegación horizontal con un submenú desplegable en horizontal (dropline menu). El submenú sólo se mostrará cuando haya eventos over o focus sobre él. Si es necesario el uso de JavaScript para desarrollar el diseño de este bloque, no podrá violar el R-NFUN- 13.

Razón: Optimizar el espacio de la página, unificar la navegación en un único bloque.


R-NFUN- 9: Reproductor de vídeo

Descripción: El reproductor de vídeo que se vaya a utilizar debe cumplir lo siguiente:

Los controles del reproductor deben tener una opción de uso por teclado o, al menos no provocar una keyboard trap (trampa de teclado).

En caso de que el navegador utilizado carezca de la tecnología necesaria para su uso, deberá informar al usuario de este hecho y proporcionar una alternativa para poder visualizar el contenido.

Se deben poder mostrar subtítulos y audiodescripciones.

Razón: Conseguir un reproductor de vídeo accesible.


R-NFUN- 10: Visor de anuncios

Descripción: El visor debe permitir controlar la iteración de los anuncios, de manera que se pueda volver al anuncio anterior, pasar al siguiente o detener el movimiento. Si usan tecnologías adicionales a HTML, es necesario que se proporcione una alternativa para poder seguir viendo ese contenido.

Razón: Conseguir un visor de anuncios accesible.




R-NFUN- 11: Características de la página principal

Descripción: La página principal debe mostrar la información necesaria para que un usuario conozca a qué se dedica la Fundación, qué es lo último que está haciendo y lo próximo que va a realizar. Esta información se verá representada de la siguiente manera:

Un bloque de noticias donde se presenten las seis últimas y se pueda acceder al resto.

Un bloque de anuncios donde se presenten cuatro anuncios de eventos de manera cíclica y continua y se pueda acceder a cada evento para ampliar la información de los mismos.

Un bloque que liste los cinco últimos eventos realizados, actuales y próximos.

Un buscador.

Enlaces destacados de manera especial (con una imagen) para determinados contenidos como el último número de la revista o la memoria de actividades del último año.

Razón: Lograr claridad en la página principal y mostrar un “escaparate” de la empresa.

Prioridad: Alta Dificultad: Alta Dependencias: R-FUN-1, R-FUN-21, R-FUN-17, R-FUN-13

R-NFUN- 12: Longitud de la página

Descripción: Se debe controlar la longitud de la página, de manera que no crezca en exceso el scroll vertical. Para ello, se usará alguna técnica que permita contraer o expandir el contenido en función de las necesidades del usuario. Esto no implicará que se limite a un máximo el tamaño vertical de una página, pudiendo crecer o decrecer ésta todo lo que el usuario pueda necesitar para ver el contenido que desee. Además, se proporcionará un mecanismo que facilite al usuario volver arriba. Este requisito no debe violar el requisito sobre scripting.

Razón: Conseguir una página más usable.


R-NFUN- 13: Scripts accesibles

Descripción: Cualquier tecnología de scripting utilizada para insertar texto en el DOM de manera dinámica deberá ser no intrusiva, es decir que independientemente de la herramienta de navegación utilizada se pueda llegar a ese contenido. Aquellos eventos controlados por una tecnología de scripting deben ser independientes del dispositivo. Además, todas las acciones que se lleven a cabo por este tipo de eventos y que no puedan conseguir el mismo efecto sin el uso de esta tecnología, deben proporcionar una alternativa para lograr el mismo fin.

Razón: Hacer que el contenido sea accesible independientemente del dispositivo o la tecnología.




R-NFUN- 14: Enlaces en el sitio web

Descripción: Se debe evitar el uso de enlaces consecutivos que lleven al mismo sitio, enlaces “rotos”, enlaces fuera de contexto sin propósito claro (leer más, ver más, ampliar, más información, etc.) y enlaces con el mismo nombre que lleven a distintos sitios. También se deberá identificar los enlaces de manera clara, única e inequívoca en la presentación del sitio.

Razón: Facilitar el uso y el acceso a los contenidos del sitio web.


R-NFUN- 15: Mapa web

Descripción: Se proporcionará una página que contenga la estructura del sitio web con enlaces a cada una las secciones. Esta página debe estar enlazada desde cualquier página del sitio.

Razón: Proporcionar al usuario más de una forma de localizar contenido.


R-NFUN- 16: Guía de navegación

Descripción: Se proporcionará una guía de navegación para informar al usuario sobre cómo está organizado el contenido, cómo puede navegar a través del sitio web, cuáles son las teclas de acceso rápido por teclado, y cómo funcionan la galería fotográfica y el reproductor de vídeo. Esta página debe estar enlazada desde cualquier página del sitio.

Razón: Ayudar a los usuarios en caso de desorientación en el sitio web.


R-NFUN- 17: Independencia del dispositivo

Descripción: El diseño del sitio web deberá realizarse de manera que sea independiente del dispositivo con el que se acceda al sitio. Esto implica que se cumplan las siguientes características:

El diseño de la página debe ser elástico, de manera que se ajuste a cualquier resolución de pantalla.

La resolución mínima en la que se tiene que poder ver la página sin perder la estética normal es 1024x768. Para resoluciones inferiores es permisible que se tengan que perder determinados detalles meramente estéticos. Se evitará el desplazamiento horizontal (scroll) independientemente de la resolución.

El tamaño de la letra tiene que poder ser ampliable o reducible a un 200% del tamaño normal sin que esto conlleve una pérdida visual de información (quede tapada por elementos estéticos o se salga de su contenedor).

El diseño debe ser compatible con los navegadores más comunes en el mercado hoy en día. Además, debe intentar compatibilizar con versiones más antiguas de Internet Explorer



(por debajo de la versión 7).

Razón: Mejorar la accesibilidad en los contenidos.


R-NFUN- 18: Estándares

Descripción: El sitio web debe ser conforme a los estándares de tecnologías web que utilice para su desarrollo, evitando los errores en la sintaxis de los mismos.

Razón: Lograr una mayor compatibilidad con los navegadores y con la interpretación del código.


R-NFUN- 19: Organización de los contenidos

Descripción: No se usará un esquema de organización ambiguo basado en la organización interna de la Fundación, sino uno basado en el asunto o materia de la información.

Razón: Lograr mayor usabilidad en el sitio web.


R-NFUN- 20: Accesibilidad global

Descripción: El sitio web deberá cumplir con las WCAG 1.0 (de manera que se cumpla la legislación española vigente) y las WCAG 2.0 para un nivel “AA” e intentar cumplir todos aquellos requisitos de nivel “AAA” que sean viables.

Razón: Proporcionar un sitio web sin barreras con un “diseño para todos”



4. SOLUCIÓN [113]

4. SOLUCIÓN

En esta sección del documento se puede leer la implementación de los requisitos del

apartado anterior mismos mediante la configuración de Drupal, así como los módulos

instalados y las modificaciones realizadas sobre ellos. Este capítulo también alberga las

evaluaciones de accesibilidad realizadas sobre el sitio tras su implementación.

Los apartados de implementaciones se han ordenado de manera que ayuden a

comprender cómo está construido y estructurado el sitio y cómo se han incorporado en él

las distintas funcionalidades especificadas en los requisitos funcionales. Por ello, se ha

comenzado por los requisitos no funcionales que restringen las características de diseño y

presentación. A continuación le siguen los requisitos funcionales y los no funcionales

dependientes. Por último se encuentran los requisitos no funcionales restantes como el R-

NFUN- 20: Accesibilidad global donde se comenta toda la evaluación de accesibilidad y

posterior corrección de fallos detectados.

Por motivos de privacidad no se mostrará todo el código específico implementado para

lograr los cambios necesarios, aunque se indicará dónde ha sido necesario realizarlos y lo

que se ha logrado con ellos.

4.1. Implementación de R-NFUN-10: Características de la página

principal

Los contenidos que se quieren mostrar en la página principal servirán como medio para

dar a conocer las actividades que lleva a cabo esta Fundación. Hasta ahora no se ha

hablado del diseño ni de la presentación del sitio web, será en este apartado donde se

haga. Para poder situar los distintos bloques de información dentro del contexto del

diseño, se hablará del diseño global y de la maquetación del sitio, así como de los ajustes

en Drupal para conseguir las características de la página principal solicitadas.

El sitio web presentará una estructura a dos columnas con una sección de cabecera donde

se situará el logotipo de la empresa, el acceso al gestor, y el menú de navegación. También

contará con una sección de pie donde se situarán los enlaces secundarios del sitio web, los

derechos sobre los contenidos y los iconos de validación con los estándares. En la Figura

24 se muestra el esquema de la estructura del sitio web.

Las dos columnas se repartirán el grueso de la información que se mostrará en el sitio

web. La columna de la izquierda ocupa el 75% del ancho de la ventana lo que quiere decir

que contendrá el contenido principal de cada página del sitio. Esta columna está divida en

dos regiones: contenido superior y contenido central. El contenido superior sólo

contendrá las migas de pan para situar al usuario dentro del sitio, a excepción de la página

principal en la que sólo contendrá el visor de anuncios. La columna de la derecha,



denominada barra lateral o sidebar, contendrá todos los bloques de información

adicionales requeridos por este requisito, así como futuros contenidos que se quieran

destacar por motivos estratégicos.

Como puede deducirse de esta estructura y de los comentado hasta ahora sobre ella, la

página principal contendrá en su región de contenido central el bloque con las seis últimas

noticas del sitio y el acceso a las restantes y en la región de contenido superior los

anuncios. En la barra lateral se situarán el buscador, el bloque de eventos y los enlaces

destacados.

CABECERA

MENÚ DE NAVEGACIÓN PRINCIPAL

CONTENIDO BARRA LATERAL

PIE

CONTENIDO SUPERIOR

CONTENIDO CENTRAL

Figura 24: Esquema de la estructura de la página

La página principal del sitio web es un nodo especial para Drupal. Por defecto ese nodo ya

existe y se corresponde con el nodo 0, que está situado en la raíz del sitio. En este caso, la

implementación de la página principal se ha realizado aprovechando este nodo y

añadiéndole las vistas necesarias para generar todos los contenidos especificados en este

requisito.

En la Figura 25 se puede ver la disposición comentada hasta ahora de los bloques de

contenidos.


4. SOLUCIÓN [115]

Figura 25: Vista completa de la página principal



4.1.1. Sección “Últimas noticas”

Se muestran seis noticias en vista de teaser. Esta sección está construida como una vista de

bloque cuyo límite de elementos a mostrar es 6 y están ordenadas por fecha de

publicación (de la más reciente a la más antigua). El cómo se muestra en una noticia como

vista de teaser se comenta en el apartado “Implementación del R-FUN-17: Consulta de

noticias”. Por otro lado, para esta vista ha sido necesario redefinir el archivo de plantilla

views-view-fields.tpl.php para cambiar el nivel de encabezado de los títulos de las

noticias.

Esto se debe a que estando en la página principal el logotipo de la Fundación será el

encabezado de nivel 1 –h1 del HTML-, el nivel de encabezado 2 será el título del bloque

“Últimas noticias” –h2 del HTML- y por tanto, cada título de noticia se debe corresponder

con el nivel de encabezado 3 –h3 del HTML-. Esta vista de bloque sólo se muestra en la

página principal.

4.1.2. Visor de anuncios

El visor de anuncios que ocupa la región de contenido superior es otra vista de Drupal. El

cómo está construido este visor en el sitio web se explica en el apartado “Implementación

del R-NFUN- 11: Visor de anuncios” y el cómo se muestran anuncios en el apartado

“Implementación de R-FUN-21: Alta de anuncio”.

Esta vista se construye con los anuncios de los últimos cuatro eventos del sitio web. Para

lograr la presentación del visor ha sido suficiente con aplicar a la vista la plantilla del

módulo “Views SlideShow” – explicado en el apartado “Implementación del R-NFUN- 11:

Visor de anuncios” - no siendo necesario renombrar ningún archivo. La configuración del

visor de anuncios es específica para cada vista o instancia del mismo y se hace a través del

módulo “Views”. El visor cumple con los criterios de este requisito, ya que permite ajustar

el tipo de transición, enlazar a los nodos, y mostrar una barra de control para su manejo.

4.1.3. Barra lateral derecha

El primer bloque que aparece en la barra lateral es el buscador. La presentación y

configuración de este bloque está se comentada en el apartado Implementación del R-

FUN-1: Búsqueda.

Bloque de eventos

El siguiente bloque que aparece es la lista de eventos actuales, futuros y realizados. Esta

vista es bastante compleja y su implementación ha llevado varias etapas.

La primera de ellas era lograr un filtro tan complejo sobre la base de datos. Dada la

imposibilidad de éste, la solución viene dada por realizar tres vistas independientes que se

muestren como un único bloque mediante la capa de presentación. Por lo que


4. SOLUCIÓN [117]

internamente este “bloque” son tres vistas de bloque creadas en Drupal a través del

módulo “Views”.

Lo que diferencia a las tres vistas es el filtro. La vista de eventos actuales filtra los nodos en

función de si la fecha de inicio del evento es menor o igual que la actual y su fecha de fin es

mayor o igual que la actual. La vista de eventos futuros filtra los nodos en función de si la

fecha de inicio es mayor que la actual y la vista de eventos pasados tiene en cuenta que la

fecha de fin sea menor que la actual.

Una vez obtenidos esos tres listados, hay que lograr que se muestren de forma

consecutiva. La única solución para esto es, a través de la página de administración de

bloques de Drupal, activar la visibilidad de los bloques de manera consecutiva. Estos

bloques no sólo se van a mostrar en la página principal del sitio web, sino que

acompañarán al usuario en todo el sitio web, del mismo modo que el bloque del buscador.

Una vez que se ha conseguido que los bloques aparezcan juntos, es necesario preprocesar

el HTML generado por estas vistas para que se construya como un único bloque cuyo título

de bloque sea único, “Eventos”, y quede todo dentro de una misma capa que permita

insertar el CSS necesario. También es necesario que cada vista tenga su título propio,

“Actuales”, “Futuros” y “Realizados”, como encabezado de nivel 3 – h3 en HTML-. Por otro

lado los títulos de los eventos tienen que ser un encabezado de nivel 4 –h4 en HTML-. Para

conseguir esta última especificación se redefinirá el archivo de plantilla encargado de

presentar cada nodo de la consulta, views-view-list.tpl.php con el fragmento de

Código 6.

<?php if (!empty($title)) : ?>

<h3><?php print $title; ?></h3>

<?php endif; ?>

<<?php print $options['type']; ?> class="sidebar-event-list">

<?php foreach ($rows as $id => $row): ?>

<li class="<?php print $classes[$id]; ?>"><?php print $row; ?></li>

<?php endforeach; ?>

</<?php print $options['type']; ?>>

Código 6: nueva salida de HTML para la lista de eventos

Por último el preprocesado del HTML se hará creando una función interna en el archivo

template.php del nuevo estilo que tenga en cuenta lo siguiente:

Siempre existirán eventos realizados, pero no siempre eventos actuales o

próximos.

Cada vista debe llevar su título propio como encabezado de nivel 3.



La función llamada theme_event_sidebar_block es la encargada de realizar el

preprocesado. Esta función será llamada desde el archivo de plantilla block.tpl.php

renombrado para cada uno de los bloques generados por estas tres vistas.

Este bloque de información también tiene un script que permite contraer y expandir

contenido en función de las necesidades del usuario. Este script carga un manejador de

evento onclick para cada título de cada una de las listas de eventos. Cada título va

acompañado de un icono con un signo más o menos cuyo alternativo indica expandir o

contraer respectivamente, según el signo de la imagen. Por defecto, el script mantiene

expandidas las tres listas de eventos en la página principal del sitio. Para el resto de

páginas, las listas de eventos futuros y realizados aparecen ocultas y sólo queda visible la

lista de eventos actuales. Como pasaba con el script que controla la visualización de los

bloques de información de un evento, este script también permite ocultar o mostrar

cualquiera de las listas según desee el usuario.

Enlaces destacados

Por último, las dos imágenes que aparecen en la Figura 25 bajo el bloque de eventos son

los enlaces destacados. Para publicar un enlace de este tipo se ha optado por crear una

vista de bloque llamada banner-sidebar que permita mostrar una imagen ya existente en el

servidor con el texto correspondiente para enlazar al contenido que se considere

oportuno.

Esta vista es bastante sencilla y sólo necesita renombrar el archivo de plantilla

block.tpl.php para cada bloque/enlace que se quiera mostrar. Es necesario renombrar

este archivo para insertar unas clases especiales que identifiquen al bloque de la barra

lateral como un bloque especial simple que no requiere que herede estilos de CSS.

4.2. Implementación de R-NFUN- 19: Organización de los

contenidos

Como se comentó en el planteamiento del problema, el sitio web antiguo presentaba cierto

caos en la organización de los contenidos, en la “encontrabilidad” interna –del inglés,

findability- de la información. Estos problemas eran derivados de una mala organización

de los contenidos, de una mezcla de sistemas de organización, así como de una mala

estructura de los contenidos y navegación por el sitio. Por un lado, los contenidos estaban

ordenados según la organización interna que realizaba la empresa para clasificar las

actividades que realizaba: análisis y debate, historia y memoria, investigación y estudio e

internacional. Por otro lado, utilizaba un conjunto de temáticas relacionadas asociadas a

las actividades: cultura, derechos humanos, historia, memoria histórica, etc. Sin embargo

también aparecían clasificaciones por: cursos, jornadas, exposiciones, seminarios, etc.

Todo esto presentado de manera paralela y entremezclada en los menús de navegación,

hacía de la navegación y de la “encontrabilidad” una tarea enormemente complicada para

un usuario.


4. SOLUCIÓN [119]

De las posibles clasificaciones de información descritas en el estado de la cuestión, en este

Trabajo se eligió la clasificación por temas. Basándose en los elementos de menú del

antiguo sitio web, se hizo una reorganización y restructuración de dichos elementos,

eliminando aquellos que eran redundantes o que dificultaban la comprensión de la

organización. Todos los enlaces relacionados con la Fundación se englobarán dentro de

una sección denominada “Fundación”, cuyos enlaces serán: presentación, nuestra historia,

estructura, patronato, dónde estamos, memorias de actividades. Todas las actividades se

englobarán en una sección con este nombre, a excepción de las exposiciones que por

cuestiones estratégicas de la empresa se les dará mayor importancia colocándolas como

una sección. Otra sección será la “Editorial”, que aunque está fuera de este trabajo ha sido

necesario contar con ella en este punto. La editorial tendrá como elementos toda la línea

de publicaciones que edita esta Fundación: libros, catálogos, revistas y audiovisuales. Por

último, habrá una sala de prensa donde se contará con la sección de noticas, galerías y la

Fundación en prensa.

También se va a crear una clasificación categórica en función de los temas relacionados de

los que se ha estado hablando a lo largo de la solución en los distintos tipos de nodo. Estos

temas relacionados permiten relacionar distintos contenidos del sitio web, de manera que

un usuario interesado en ciertas temáticas pueda saber qué más ha realizado la Fundación

sobre éstas. Esto se debe a que la Fundación ya cuenta con un perfil de usuarios muy

definido que se centra en esta selección de temas.

Toda esta clasificación de la información va a generar dos tipos de navegación en el nuevo

sitio web. Por un lado una navegación jerárquica y por otro una navegación hipertextual.

En este caso, se ha mantenido el equilibrio entre ancho y profundidad de la jerarquía,

gracias al uso de sólo dos niveles de profundidad dentro de la jerarquía (dos niveles en el

menú de navegación) y al número de elementos que forman dicho menú (se han eliminado

los elementos de menú que hacían referencia a los temas relacionados).

Gracias a la clasificación por categorías se ha conseguido una estructura de navegación

hipertextual. Diferentes páginas de diferentes jerarquías están vinculadas por temas

relacionados comunes. Esto permite que los usuarios puedan navegar según sus

preferencias por determinados temas. Se ha tenido especial cuidado para que ninguna

página quede excesivamente descolgada o de difícil acceso.

4.3. Implementación del R-NFUN- 21: Navegación del sitio web

Este requisito no funcional restringe el diseño del sitio web, ya que define cómo debe ser

el bloque de navegación. En la Figura 26 se muestra una barra de navegación horizontal

que se ajusta a las necesidades del requisito. Los elementos que se muestran en la barra de

navegación son meramente orientativos. Estos elementos dependerán del sistema de

organización de la información que se aplique al sitio web.



Figura 26: Barra de navegación horizontal

Para la implementación de la barra de navegación ha sido necesario el uso de scripts para

controlar la visibilidad de los elementos del submenú. El script que controla los eventos

sobre el menú de navegación permite:

Recorrer el menú usando teclado: en orden de aparición, sin saltarse elementos,

desplegando cada submenú y recorriendo cada elemento de éste, hacia adelante y

hacia atrás.

Hacer uso del ratón: permite desplegar cada submenú al hacer over.

Acceder a cualquier elemento mediante ratón y teclado.

En la Figura 27 se puede ver cómo se despliega el submenú de un elemento primario de la

navegación. El submenú también se muestra en horizontal, con todos sus elementos en

línea. Este tipo de bloques de navegación no desorientan a usuarios con problemas

cognitivos, ya que no tapan espacios utilizados para mostrar otras informaciones.

Figura 27: Barra de navegación con un submenú desplegado

El código es ciertamente complejo y se ha desarrollado en jQuery. A continuación se

explica lo que hace este código.

1. Se carga en todos los enlaces de primer nivel del menú una función asociada a su

evento focus. Las acciones que realiza esta función serán: activar la visibilidad de

su submenú, marcar el elemento como seleccionado y desactivar la visibilidad de

cualquier otro submenú de otro elemento.

2. Cuando se pierde el foco de un enlace de primer nivel del menú (evento blur) para

volver a un enlace anterior hay que activar el foco sobre el último enlace de nivel

dos del enlace de primer nivel anterior al actual. Es decir, estando en Actividades,

se debería llegar al último enlace del submenú de Fundación. Para ello, se carga

una vez una función especial asociada al focus de Fundación, para que active su

último enlace de submenú.

3. Cuando se hace focus sobre el siguiente elemento del DOM que admite focus (es

decir, se está saliendo del menú por el final), hay que desactivar la visibilidad del

último submenú y la selección de su correspondiente enlace de primer nivel.

Además, se debe cargar una vez una función especial asociada al focus sobre el

último enlace de primer nivel para que active su submenú y traslade este foco

sobre su último enlace de nivel dos, ya que para volver sobre el menú el orden del

recorrido es el inverso.


4. SOLUCIÓN [121]

4. Cuando se hace focus sobre el anterior elemento del DOM que admite focus (es

decir, se está saliendo del menú por el principio), hay que desactivar la visibilidad

del primer submenú y la selección de su correspondiente enlace de primer nivel.

En este caso no hace falta cargar un focus especial sobre el primer elemento del

menú de navegación, ya que el recorrido si se iniciase de nuevo sería hacia delante.

se está recorriendo hacia delante y el primer elemento será el primer enlace del

menú primario.

5. Además, se debe tener una función para resetear cualquier evento cargado en los

elementos del menú, para cuando se recarga la página o se hace clic en cualquier

otro punto de la misma.

Para poder crear en Drupal un menú de navegación como el que se ha mostrado y permitir

la organización de la información es necesario instalar varios módulos contribuidos que

permitirán desarrollar al máximo la potencia de un menú.

Lo primero es saber qué implica tener un menú, un submenú y un elemento que cuelga

dentro de este. Esto generará una jerarquía en la información y por tanto una secuencia de

navegación para los usuarios. Con esta secuencia de navegación es importante que los

usuarios se sepan situar dentro de la jerarquía, es decir dentro del sitio web. Aquí es

donde entrará en juego el breadcrumb o migas de pan. Además, las rutas del sitio web

deberán presentarse de manera que también puedan ser recordadas y en el contexto de la

jerarquía de la información.

Para aprovechar la taxonomía ya creada para clasificar los tipos de nodo “Evento”, se

instalará en Drupal un módulo contribuido llama “Taxonomy Menu”. Este módulo permite

crear un menú de navegación a partir de una taxonomía de Drupal. Drupal ya gestiona los

menús de navegación a través de sus páginas de administración, pero esta funcionalidad

es básica y no permite utilizar las taxonomías para crear elementos de navegación. La

configuración de este tipo de menús se hará creando primero una taxonomía completa,

con todos sus vocabularios –enlaces primarios del futuro menú de navegación- y sus

términos –enlaces secundarios dentro del menú de navegación-. Luego se creará un menú

de navegación y se le asociará esta taxonomía, automáticamente Drupal construye un

bloque con la jerarquía generada a partir de la taxonomía que se puede ubicar en

cualquier región del sitio web.

El menú de navegación por taxonomías se integra con la filosofía de Drupal de los menús

de navegación. Es decir, generará rutas específicas para esos nodos y construirá las migas

de pan. El problema que presentan las rutas en Drupal generadas a partir de las

taxonomías reside en el nombrado. Esto se entiende mejor con un ejemplo: supóngase el

evento Conferencia 1, cuyo término de la taxonomía sería Conferencias del vocabulario

Actividades. La ruta para este evento sería: /actividades/conferencias/conferencia-1, pero

el módulo “Taxonomy Menu” construye, /taxonomy/term/#/nodo-#. Las almohadillas se

corresponden con los identificadores asignados por el gestor en el momento de su

creación.



Para poder tener una ruta como la esperada y no como la genera el módulo es necesario

activar en Drupal el módulo core “Path” y el módulo contribuido “Pathauto”, el segundo

depende del primero. Ambos permiten crear rutas “limpias” –fáciles de recordar,

entendibles por indexadores y permanentes- y crear patrones específicos para los tipos de

nodo y los vocabularios de las taxonomías. De esta manera, se creará un patrón para

construir las rutas de todos los tipos de nodos que se vayan creando el sitio de la siguiente

forma: /vocabulario/término/título-nodo. Se creará un patrón para todos términos de los

vocabularios que se vayan creando en el sitio de la siguiente forma: /vocabulario/término.

De esta manera, las páginas intermedias de los términos de taxonomía también tendrán su

ruta.

A partir de esta ruta Drupal genera las migas de pan, pero presenta ciertas

incompatibilidades con el “Taxonomy Menu”. Para solucionarlo se ha optado por

preprocesar la variable global $breadcrumb del gestor y modificarla de acuerdo con las

necesidades del sitio web. La función que preprocesa esta variable global es

phptemplate_breadcrumb que se ha redefinido en el template.php del nuevo estilo.

Las modificaciones en esta función se pueden ver en el fragmento de Código 7 y se centran

en reescribir por completo el breadcrumb generado por Drupal para garantizar que

siempre se generará correctamente.

function phptemplate_breadcrumb($breadcrumb) {

/* Se modifica el breadcrumb para hacerlo mediante el reconocimiento del path

* actual. De esta forma, se evitan errores en las páginas que no tengan

* taxonomias definidas.

*/

global $language;

// Se obtiene el url actual y se corta por los delimitadores

$path_split = explode('/', request_uri());

// Se consulta el base_path para saber donde empieza el breadcrumb

$base_split = explode('/', base_path ());

/* El base_path esta formado o bien por '/' o por '/namebase/' por lo que

* el elemento 2 del array de base_split es el que contiene el name de la

* base. Se debe recorrer el path_split hasta llegar a ese elemento, y los

* dos siguientes seran los elementos del menu. Si name de la base es null,

* entonces no se hace nada.

*/

$base_split = $base_split[1];

$i = 1; // Por defecto, se supone que basename es null

/* Se crea un array asociativo para mantener el breadcrumb modificado, donde

* el key es el nombre del path modificado y href es su enlace.

*/

$bread_mod = array(); // Se inicializa el array del breadcrumb modificado


4. SOLUCIÓN [123]

// Tiene basename y coinciden

if ($base_split && $base_split == $path_split[1]) {

$i = 2; // Se debe comenzar a buscar por el segundo elemento de path_split

}

if (!$path_split[$i]) // Si es vacio, retornamos null

return null;

if ($language->language != 'es')

$i++;

// Si el lenguaje activo no es spanish, se debe saltar un elemento mas.

/* Para cada uno de los elementos del path, se comprueba si tiene su

* string equivalente.

*/

$path = null;

for (; $i < count($path_split); $i++) {

$elem = $path_split[$i];

// el path siempre estara formado por todos los elementos hasta ahora

// recorridos

$path .= '/'. $elem;

// Se utiliza la funcion de busqueda para encontrar la conversion

$res = fpi_convert_menu ($elem);

// Se almacena como key el string equivalente y como valor su href

if ($res) {

// Si el elemento es historico o visitas-virtuales no debe aparecer en el path

if (!_elem_deprecated($elem))

$bread_mod[$res] = $path;

} else {

// Se debe comprobar si el elemento no encontrado es un nodo, ya que en

// este caso se debe recuperar el titulo

if (!preg_match ('/^[0-9]+_/', $elem, $nid))

// Se intenta recuperar el nid de la forma "nid_titulo"

preg_match ('/_[0-9]+/', $elem, $nid);

// Se intenta recuperar el nid de la forma "titulo_nid"

if ($nid) {

preg_match('/[0-9]+/', $nid[0], $numnid);

// Se consulta la tabla node para extraer el titulo del nodo.

$title = db_result(db_query("

SELECT title FROM {node}

WHERE nid = '%d'", $numnid[0]));

if ($title)



$bread_mod[$title] = $path;

}else {

if ($elem == 'taxonomy') {

/* Es un path no definido de taxonomias. Su estructura es

* taxonomy/term/[tid], asi que recuperamos ese id de termino, y

* realizamos la conversion a sus nombres.

*/

$i = fpi_convert_taxonomy (&$bread_mod, $path_split, $i+2);

}

else

$bread_mod[$elem] = $path;

}

}

}

/**

* El breadcrumb debe estar formado por una lista de enlaces. Si existe

* breadcrumb, siempre debera aparecer el elemento 'Inicio' que apunte a

* la pagina de inicio. El resto, deberán apuntar a sus paginas respectivas

*/

$str_res = null; // Inicializacion del resultado

if (!empty($bread_mod)) {

// Se crea el inicio del breadcrumb, que referencia a la pagina principal

$i_last = count($bread_mod);

$j = 1;

$str_res = '<ul id="breadcrumb">';

$str_res .= '<li class="first">';

$str_res .= '<a href="/'.$base_split.'">'. t('Home') .'</a></li>'."\n";

// Para cada elemento del bread modificado se recupera su nombre y su

// href, para insertarlo en la lista. Todos los elementos tendran su <a>

// excepto el ultimo.

foreach ($bread_mod as $bread_key => $bread_elem) {

if ($i_last > $j)

$str_res .= '<li><a href="'.$base_split.$bread_elem.'">';

$str_res .= t($bread_key) .'</a></li>'."\n";

else

$str_res .= '<li>'. t($bread_key) .'</li>'."\n";

$j++;

}

$str_res .= '</ul>'."\n";

}


4. SOLUCIÓN [125]

return $str_res;

}

Código 7: reconstrucción del breadcrumb

La función recoge la ruta generada por Drupal en la llamada al nodo, se separa por las

barras que marcan cada nivel de la jerarquía y se construye una lista de enlaces a partir de

cada uno, excepto el último elemento, que se insertará en la lista sin enlazar a ningún sitio,

ya que se supone que es el nodo que se está cargando en la página. Y con esto ya se tendría

la funcionalidad completa del menú. En la Figura 28 se puede ver el resultado de las migas

de pan en el sitio web.

Figura 28: Migas de pan o breadcrumb

4.4. Implementación del R-FUN-1: Búsqueda

Para cumplir este requisito se debe poder buscar cualquier contenido publicado en el sitio

web. Esto se refiere a que cualquier término o palabra clave que se introduzca para buscar,

y ésta forme parte del contenido de un nodo debe devolver un resultado. La funcionalidad

básica de búsqueda no contempla filtros o categorías para acotar los resultados devueltos.

Para poder implementar la funcionalidad de búsqueda en un sitio web, se debe:

Poder indexar el contenido para saber “qué hay” en el sitio web.

Proporcionar un mecanismo para que el usuario pueda ejecutar dicha búsqueda.

El mecanismo que se quiere proporcionar al usuario es un formulario web dentro de un

bloque de Drupal, que aparezca en todas las páginas del sitio web. Este formulario de

búsqueda debe estar compuesto por un campo de texto, donde el usuario inserte los

términos que quiere buscar, y un botón que ejecutará la búsqueda en sí.

En la Figura 29 se puede ver el bloque del buscador, que se posicionará en todas las

páginas en una barra lateral. Se ha modificado el bloque que genera Drupal por defecto,

sustituyendo el botón HTML “Buscar” por la imagen que se muestra en la figura. También

se ha ocultado la etiqueta (label) del campo de texto mediante la clase de CSS que se

muestra en el fragmento de Código 8.

Figura 29: Bloque del buscador



.hidden {

height: 1px;

overflow: hidden;

position: absolute;

top: -10px;

width: 1px;

}

Código 8: clase que oculta contenido sólo visualmente

Esta etiqueta está disponible para los lectores de pantalla, pero no visualmente. Para

ocultarla siempre habría sido necesaria la propiedad display. Para ello, ha sido

necesario renombrar la función template_preprocess_search_block_form cuyo

código se puede ver en el fragmento de

Código 9. Para lograr el estilo, sólo ha sido necesario utilizar las clases de CSS que Drupal

inserta en el bloque de búsqueda.

// Se substituye el texto del bloque por un image_button

// y se le da la ruta donde está la imagen a mostrar

$vars['form']['submit']['#type'] = 'image_button';

$vars['form']['submit']['#src'] =

'sites/default/themes/fpi/style/images/btn_buscar.gif';

$vars['form']['submit']['#title'] = 'Buscar';

// Rebuild the rendered version (submit button, rest remains unchanged)

unset($vars['form']['submit']['#printed']);

$vars['search']['submit'] = drupal_render($vars['form']['submit']);

// Se añade la clase hidden al label del formulario, para que se oculte

// mediante CSS

$vars['search']['search_block_form'] =

str_replace ('<label for="edit-search-block-form-1"',

'<label for="edit-search-block-form-1" class="hidden"',

$vars['search']['search_block_form']);

// Collect all form elements to print entire form

$vars['search_form'] = implode($vars['search']);

Código 9: Modificaciones sobre le función de template_preprocess_block_search_block_form

Drupal incorpora en el core un módulo que permite realizar búsquedas. La indexación de

contenidos en Drupal se realiza ejecutando cron, que no es más que el planificador de

tareas del sistema operativo. Drupal incluye en las tareas del sistema operativo sus tareas,


4. SOLUCIÓN [127]

entre las que se encuentra la búsqueda de actualizaciones o la indexación de contenidos de

la base de datos.

Con este módulo core, Drupal sólo es capaz de realizar búsquedas sobre el título, la

descripción y el autor de un nodo. Dadas las características del sitio web y la información

que se quiere presentar en el sitio web, es necesario instalar módulos contribuidos para

poder almacenar esta información en la base de datos. Para que Drupal indexe otros

contenidos dependientes de módulos contribuidos es necesario instalar el módulo “Field

Indexer”. Este módulo incluye automáticamente la indexación de nuevos campos de la

base de datos en las tareas de Drupal.

Para garantizar que los contenidos puedan buscarse, prácticamente en el instante de

haberse creado, se ha programado en el servidor una ejecución de cron diaria. De esta

manera, todo el contenido nuevo generado en un día, puede buscarse al día siguiente.

La ejecución del planificador de tareas del sistema, cron, funciona ejecutando scripts. Para

el caso de las tareas de Drupal, ha sido necesario incluir una línea que lanza el script cron-

lynx.sh.

4.5. Implementación del R-FUN-2: Opciones de publicación

Para cumplir este requisito, el gestor de contenidos debe permitir almacenar esta

información para cada nodo. Con ello se debe conseguir que el nodo en concreto se

muestre o no en el sitio web para usuarios anónimos.

Para implementar la funcionalidad se deben tener en cuenta las siguientes necesidades:

Disponer de un campo en el nodo para guardar la información.

Crear filtros en las consultas sobre la base de datos para que muestre o no los

nodos en función del estado y del tipo de usuario.

Indicar de alguna forma el estado del nodo al usuario autenticado y al

administrador.

Independientemente del estado del nodo, el usuario autenticado y el administrador deben

poder ver cualquier nodo en el gestor.

Para lograr que el estado del nodo se refleje visualmente de alguna forma al usuario

autenticado y el administrador, se ha utilizado una clase de CSS que colorea el fondo en

rosa de los nodos para el estado de no publicado.

Drupal, por defecto ya almacena esta clase de información en el nodo. Es decir, los nodos

en Drupal, tienen un campo específico para esta almacenar esta información. Además,

automáticamente y por defecto, no muestra los nodos no publicados a los usuarios

anónimos, y sí lo hace para los usuarios autenticados y el administrador. Por tanto, para



cumplir este requisito no se ha tenido que cambiar ninguna configuración de Drupal, ni se

ha tenido que modificar código.

Cabe destacar que Drupal maneja esta información con flags. En los formularios de edición

de nodos, presenta unas casillas de verificación que permiten activarse o desactivarse para

indicar el estado, cuyo valor en la base de datos será 0 o 1. Se puede configurar el valor por

defecto del estado de publicación para cada tipo de nodo. Es decir, para el tipo de nodo

“noticia” se puede establecer que su estado de publicación sea publicado, y para el tipo de

nodo “evento” sea no publicado.

4.6. Implementación del R-FUN-3: Temas relacionados

Para cumplir este requisito es necesario que el gestor de contenidos permita asociar cada

nodo a distintos temas relacionados. De manera que, al consultarse un tema, se devuelvan

todos los nodos –independientemente del tipo- asociados al mismo.

Hay que tener en cuenta las siguientes consideraciones para implementar este requisito:

Los temas relacionados son una forma de agrupar y relacionar contenidos. Este

tipo de relaciones se representan mediante las taxonomías.

Debe existir un campo en los nodos que permita almacenar esta información.

El campo debe permitir elegir de entre los mismos temas para cualquier tipo de

nodo.

El usuario autenticado no debe poder crear términos nuevos.

Hay que poder hacer filtros en las consultas según los temas relacionados.

Drupal por defecto permite crear taxonomías, pero no permite almacenar este tipo de

información en un nodo. Para que este tipo de información sea un campo en cualquier tipo

de nodo, es necesario instalar módulos contribuidos.

La idea es que en el formulario de edición de un nodo se muestre una lista desplegable de

selección múltiple con los términos disponibles. De esta manera, no se podrán añadir

términos nuevos. Con la idea de la taxonomía única se puede crear un campo que tenga

asociado esa taxonomía como valores posibles. Lo que el usuario anónimo verá como

resultado es una lista de términos relacionados –Figura 30-.

Figura 30: Lista de temas relacionados que parece al final de un evento

No es necesario añadir nuevas clases para el estilo. El CSS del tema utiliza las clases de

Drupal para insertar los atributos necesarios para la vista en línea de todos los enlaces.

Por otro lado, es necesario poder generar una página por término relacionado y una

página que liste todos los términos definidos en el sitio web.


4. SOLUCIÓN [129]

Para poder implementar este requisito en Drupal hay que activar el módulo core

“Taxonomy”, e instalar los módulos contribuidos “CCK”, “Content Taxonomy” y “Views”.

Con estos cuatro módulos se pueden crear taxonomías, añadir campos de taxonomías a la

edición de nodos y crear consultas sobre la base de datos, adaptadas a las necesidades del

administrador.

El módulo “Taxonomy” es un módulo del core que no viene activado en la instalación por

defecto de Drupal. La creación de taxonomías y de términos asociados a taxonomías

comienza a estar disponible en el momento de su activación.

Para que se pueda añadir un campo de diferentes tipos a un nodo, es necesario instalar

“CCK” (del inglés, Content Construction Kit). Este módulo permitirá definir campos de

texto, de número y referencias a nodos entre otros. Pero no permite añadir un campo de

tipo taxonomía. Para ello, es necesario instalar el módulo “Content Taxonomy” que

complementará al módulo “CCK”.

Este módulo permite crear campos asociados a taxonomías existentes en el gestor, en

forma de campos autocompletables por AJAX o listas desplegables. Con este módulo se

cubren todas las necesidades del requisito, ya que además permite dar permisos sobre la

creación de términos nuevos –hay que recordar que no se quiere permitir que los editores

de contenido creen términos nuevos-.

Por otro lado, con la instalación del módulo “Views” se va a lograr la personalización de las

consultas sobre la base de datos y la presentación de dicha consulta en el sitio web. Este

módulo es compatible con el módulo core “Taxonomy” y con el módulo “CCK”, de manera

que permitirá crear vistas sobre términos de taxonomía del tipo “Temas relacionados”.

Con esto último se pueden generar las páginas para cada tema relacionado y la página con

todos los temas relacionados del sitio web. Estas páginas, en realidad, serán vistas creadas

por el administrador desde el módulo “Views”.

Para lograr la presentación mostrada en la Figura 30 de los temas relacionados, ha sido

necesario renombrar el archivo content-field.tpl.php del módulo contribuido “CCK”

para que afecte a este campo concreto y no a todos los campos de contenido de Drupal. En

el fragmento de Código 10 se muestra el código de este fichero que se ha modificado para

añadir una imagen de separación entre enlace y enlace para que dejen de ser enlaces

adyacentes sin separación.

...

foreach ($items as $delta => $item) :

// Si sólo hay un elemento no se imprime la imagen separadora

if ((!$item['empty']) && $count == 1) : ?>

// Se modifica la ruta para que apunte a un alias

<?php $item['view'] = str_replace(



'taxonomy/term',

'temas-relacionados',

$item['view']);

?>

<?php print $item['view']?>

<?php $count++;

elseif ((!$item['empty']) && $count != 1): ?>

// Se modifica la ruta para que apunte a un alias

<?php $item['view'] = str_replace(

'taxonomy/term',

'temas-relacionados',

$item['view']);

?>

// Se imprime la imagen que separa los enlaces

<?php print '<img

src="/sites/default/themes/fpi/style/images/div-links.png"

alt="" style="padding:0 10px 0 5px;" />'.$item['view']

?>

<?php $count++;

endif;

endforeach;?>

Código 10: Content-field.tpl.php del módulo contribuido "CCK"

Para lograr la página de temas relacionados y cada página de un tema no ha sido necesario

renombrar ningún archivo del módulo “Views”.

4.7. Implementación del R-FUN-4: Obtención de estadísticas

Es posible cumplir este requisito gracias a la compatibilidad de Drupal con el paquete de

Google Analytics, de http://www.google.com/analytics/. En caso contrario, se tendría que

haber modificado el requisito y buscar otra manera de obtener estadísticas del sitio web.

El paquete de Google sólo necesita insertar una línea de JavaScript en todas las páginas del

sitio web. Para que esta línea se inserte en Drupal, es necesario instalar el módulo

contribuido “Google Analytics” que permite configurar el ID del sitio web, así como

insertar la línea de código necesaria o activar monitorizaciones sobre las búsquedas.

El ID del sitio web es un identificador único que proporciona Google para cada sitio que

debe monitorizar. Este identificador sólo se puede conseguir registrando el sitio web bajo

una dirección de correo electrónico del dominio de google.com.


4. SOLUCIÓN [131]

La interfaz de consulta de las estadísticas es ajena a Drupal, perteneciendo a Google, y por

tanto está fuera de este proyecto. En la Figura 31 se presenta una vista de la interfaz de

consulta. La información que aparece en ella es ficticia y no pertenece a ningún sitio web

real.

Evidentemente, este módulo es dependiente de JavaScript para su funcionamiento y por

tanto, las consultas realizadas con dispositivos que no soportan esta tecnología o la tienen

desactivada sobre el sitio web no serán monitorizadas. Pese a esto, la navegación en el

sitio web no se ve afectada.

Figura 31: Vista de la página de consulta de Google Analytics

4.8. Implementación del R-FUN-5: Envío de consultas

Para cumplir este requisito es necesario que un usuario anónimo –usuario no autenticado-

tenga acceso a algún método de contacto, a través del cual pueda mandar un correo

electrónico a los distintos departamentos de la Fundación.

Hay que tener en cuenta las siguientes consideraciones para poder desarrollar este

requisito:

Se debe poder recoger la siguiente información del usuario: nombre, dirección de

correo, asunto, departamento destinatario y el mensaje.

Se debe generar un correo electrónico destinado al departamento concreto, con la

información.

Toda la información del usuario debe estar siempre presente en los correos. Es

decir, que los campos no se podrán dejar en blanco para enviar la consulta.

Se debe enviar un correo electrónico al usuario agradeciéndole el uso del servicio,

sin que pueda responder a él.

El contacto tiene que estar presente en todas las páginas del sitio web.



La página de contacto se presentará como un formulario web con todos sus campos

obligatorios -Figura 33-. De esta manera, toda la información del usuario estará presente

en el correo electrónico. Por otra parte, para que el contacto esté presente en todas las

páginas del sitio, se añadirá en el pie de las páginas un enlace a la página con el formulario

de contacto –Figura 32-.

Figura 32: Pie del nuevo sitio web

Figura 33: Vista de la página de contacto a modo de formulario web

Se implementará un formulario web con los distintos campos de texto para que el usuario

introduzca la información pertinente en cada uno de ellos. El campo “mensaje”, será un

área de texto de 4 líneas redimensionable por JavaScript.

El departamento destinatario del mensaje se seleccionará mediante una lista desplegable

con las opciones disponibles. Por defecto, todos los correos se enviarán también al

administrador del sitio web para controlar la posible entrada de spam, puesto que no se

utilizará ninguna herramienta de detección de spam.


4. SOLUCIÓN [133]

Para poder implementar la página de contacto es necesario activar en Drupal el módulo

core, “Contact”. Este módulo permite añadir al sitio web una página de contacto a modo de

formulario web. Por defecto, esta página ya presenta los campos necesarios para cumplir

el requisito y además, son obligatorios.

Este módulo permite crear categorías a las que se puede enviar la consulta del usuario.

Estas categorías aceptan múltiples direcciones de correo electrónico, por lo que se pueden

reenviar los correos al administrador. Además, para cada categoría se podría generar una

respuesta automática diferente.

Pero todo este envío y recepción de consultas a través de un servicio de correo electrónico

no funciona en Drupal si no se instala el módulo contribuido, “PHPMailer”. Este módulo

permite configurar un servidor de correo saliente SMTP, de manera que el envío y

recepción de correos sea posible.

Los correos de repuesta automática presentan un fallo: no ocultan la dirección de correo

origen. Para que pueda usarse una dirección de correo por defecto, inexistente en el

servidor, y que no permita la respuesta al correo automático, se necesita el módulo

contribuido, “Contact Hide Email”. Este módulo permite que cada categoría pueda ocultar

las direcciones de respuesta automática, con la dirección [email protected].

4.9. Implementación del R-FUN-6: Envío de comentarios de

accesibilidad

Como se ha comentado en la solución del requisito anterior, el módulo “Contact” añade

una y sólo una página de contacto para el sitio web. Por lo que otros formularios web

deben generarse a través de otros módulos.

El módulo contribuido a instalar en Drupal para la creación de formularios web será

“Webform”. Este módulo permite la creación de formularios web a medida y seleccionar la

página en la que se visualizará dicho formulario. Con este módulo se podría haber creado

el formulario de contacto general del sitio, pero como el que venía por defecto se adaptaba

a las necesidades se decidió usar ese.

Este módulo trata los formularios de contacto como tipos de nodo en Drupal, por lo que se

pueden incluir en vistas, o ver una página propia del formulario.

El análisis, diseño e implementación de este requisito es exactamente igual que el anterior.

No ha sido necesario renombrar plantillas para crear el estilo, Drupal asigna las mismas

clases a los elementos de formulario y por tanto heredan el mismo CSS.



4.10. Implementación de R-FUN-7 y R-FUN-10: Alta, baja,

modificación y consulta de usuarios

Estos requisitos no necesitan ninguna configuración ni modificación del gestor de

contenidos o módulo del mismo. La idea de estos requisitos es que el gestor de contenido

que se eligiese tuviese estas características.

Por defecto, Drupal permite la gestión de usuarios mediante asignación de roles a los

cuales se les puede dar los permisos necesarios sobre acciones para cada módulo. Según

sean las necesidades de administración del sitio web, así se podrán crear determinados

roles con determinados permisos y asociar a los mismos los usuarios necesarios.

4.11. Implementación de R-FUN-11: Login de usuarios

Para cumplir este requisito es necesario tener en cuenta las siguientes consideraciones:

La autenticación de usuarios debe ser persistente, es decir se debe recordar al

usuario en el navegador hasta que este cierre sesión.

Es necesario ubicar el acceso donde no dé lugar a confusión dentro del sitio web,

ya que este servicio sólo es para usuarios dados de alta en el gestor.

Para lograr la persistencia en el login no es necesario cambiar ninguna configuración en

Drupal. Este gestor de contenidos implementa un login persistente mediante el uso de

cookies.

Para ubicar el acceso a usuarios autenticados en un lugar que no genere confusión, se debe

desactivar el bloque de acceso que incluye Drupal por defecto. Este bloque se desactiva a

través de la página de administración de bloques del gestor.

En lugar de este bloque, se añade en la plantilla de página -page.tpl.php-,

cuyo código se presenta en el fragmento de

// FUNCIÓN QUE CREA EL ENLACE (en template.php)

function _login(){

global $user;

global $base_path;

$output = '';

if (!$user->uid) {

$output = '<a href="'. $base_path. 'user" >' . t('Log in') . '</a>';

}

else {

$output = '<a href="'. $base_path. 'salir" >' . t('Log out') . '</a>';

}


4. SOLUCIÓN [135]

return $output;

}

Código 11, un enlace a la página de inicio de sesión, como el que se puede observar en la

Figura 34 y 34. La ubicación de este enlace será la parte superior derecha de la ventana

para que no interfiera en la visualización del contenido.

<?php

?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language-

>language ?>" lang="<?php print $language->language ?>" dir="<?php print

$language->dir ?>">

<head>


<title><?php print $head_title ?></title>

<?php print $styles ?>

<?php print $scripts ?>



</head>

<body<?php print phptemplate_body_class($left, $right); ?>>



<div id="wrapper-header-links">

<div id="header-links">

<a class="transparent" accesskey="2" href="#main-content">

Ir al contenido

</a>

<span class="hidden"> | </span>

<?php print _login(); /* Login */ ?>

<?php print $links; /* Alternador de idioma */ ?>

</div>

</div> 

// FUNCIÓN QUE CREA EL ENLACE (en template.php)

function _login(){

global $user;

global $base_path;

$output = '';

if (!$user->uid) {

$output = '<a href="'. $base_path. 'user" >' . t('Log in') . '</a>';



}

else {

$output = '<a href="'. $base_path. 'salir" >' . t('Log out') . '</a>';

}

return $output;

}

Código 11: Fragmento del archivo de plantilla page.tpl.php

Este archivo ha sido completamente modificado al nuevo estilo del sitio web. Sobre el

nuevo estilo y los cambios sobre este archivo y el .info que define las nuevas regiones se

habló en el apartado de la solución de “Implementación de R-NFUN- 11: Características de

la página principal”.

Este enlace debe ser condicional al estado de sesión. Es decir, si la sesión no ha sido

iniciada aún, se debe mostrar el enlace de la Figura 34. En caso contrario, se debe mostrar

el enlace de la Figura 35. En cada uno de ellos, se hará la llamada pertinente para cambiar

el estado de sesión.

Figura 34: Enlace al inicio de sesión Figura 35: Enlace para cerrar la sesión

La página de inicio de sesión ya existe en Drupal y no necesita ninguna configuración

adicional –Figura 36-.

Figura 36: Página de inicio de sesión

4.12. Implementación de R-FUN-12: Administración de permisos

Para este requisito tampoco ha sido necesario realizar ninguna configuración sobre el

gestor de contenidos, puesto que Drupal y sus módulos permiten esta asignación de

permisos sobre distintas acciones y tipos de contenido. En función de las necesidades del

administrador del sistema se irán creando los roles y usuarios pertinentes con los

permisos precisos para las tareas que tenga que desarrollar cada usuario.


4. SOLUCIÓN [137]

4.13. Implementación de R-FUN-17: Alta de evento

Este es uno de los apartados de la solución más complejos y que más tiempo ha requerido

para lograr su implementación completa. Para poder entender con claridad todo lo que ha

sido necesario realizar para cumplir los requisitos, el apartado se va a desglosar en partes

que comentarán detalladamente cómo se ha estudiado, diseñado e implementado cada

campo que debe tener un evento.

Lo primero, es recordar la información que debe tener un evento. Como cualquier nodo de

Drupal, el evento tendrá un título, una descripción, la autoría, y el estado de publicación.

Por otro lado también se desea almacenar:

Tipo de actividad que es: conferencia, curso, debate, encuentro, grupo de reflexión,

jornada, mesa redonda, presentación, seminario o exposición.

Fotografía

Fecha de realización, el lugar y el horario

Plano de ubicación con instrucciones de cómo llegar

Información adicional relacionada –colaboradores, programa, patrocinadores, etc.-

Temas relacionados

Tipo de evento

Galería de fotos

Galería de vídeos

Documentos asociados

Antes de pasar a los campos, hay una restricción del requisito que ya se está cumpliendo:

permisos de edición sobre el evento. Drupal, permite la asignación de permisos sobre

tipos de nodos nuevos. Además, todos los campos que se creen a través del módulo “CCK”

serán compatibles con la asignación de permisos y se le podrán asignar los valores

necesarios a cada campo en particular.

Para que la información del evento no se le presente al usuario de manera agobiante y sin

estructuración, se dividirá en bloques de información:

Presentación: contiene la descripción del evento y la fotografía.

Fecha y lugar: contiene la fecha y la dirección del lugar dónde se va a realizar el

evento. Además, recogerá las fechas de las itinerancias del evento.

Cómo llegar: contiene un mapa de Google y las instrucciones sobre cómo llegar.

Galería fotográfica: contiene las imágenes de la galería del evento.

Galería de vídeos: contiene el reproductor con la lista de reproducción de los

vídeos del evento.

Documentación: contiene todos los documentos relacionados con el evento.

Más información: contiene información adicional sobre el evento.



En la Figura 37 se puede observar la vista completa de un evento por defecto. Los tres

primeros bloques de información aparecen expandidos. El resto de bloques aparecen

contraídos y se indica a través de una imagen con un signo más la acción para

desplegarlos.

4.13.1. Tipo de evento

Este requisito recoge la necesidad de clasificar los eventos según el tipo de actividad

cultural que sea. Esta categorización se hará utilizando los módulos explicados en el

apartado de Implementación del R-FUN-3: Temas relacionados. No es necesario realizar

cambios sobre estos módulos. Basta con crearse el vocabulario “Actividades” que

contendrá todos posibles términos dados en el requisito. Lo siguiente será crearse un

nuevo campo para el “Evento”, que permita asociarle un vocabulario existente para

seleccionar un término del mismo.

4.13.2. Fotografía

Las restricciones dadas por el requisito indican que la fotografía debe tener una resolución

de, al menos 670x320, debe tener un texto alternativo y un tamaño máximo de 500KB.

Para lograr estas restricciones no ha sido necesario añadir nuevos módulos a Drupal. Se ha

reutilizado el campo de fotografía creado para el nodo “Noticia” que permite subir

archivos. Se ha mantenido el directorio de ubicación de los archivos en el gestor y se le ha

aplicado el mismo preset para su visualización en la vista de full-node.


4. SOLUCIÓN [139]

Figura 37: Vista full-node de un evento



4.13.3. Fecha, lugar y horario

Las restricciones que aparecen a continuación son las expuestas en el requisito sobre los

campos del evento.

La fecha de realización debe estar siempre presente. Tienen que poder almacenar

tanto una fecha de inicio como de fin, así como varias fechas en caso de que el

evento se haya repetido en el tiempo.

El lugar debe ser obligatorio almacenando un valor para cada fecha que se inserte.

La información que se debe almacenar es el nombre de la ubicación, la dirección

completa y el teléfono de contacto.

El horario no debe ser obligatorio y debe soportar distintos formatos de horario –

sólo horas, horas y días, días cerrados, días gratuitos, etc.-

La itinerancia de un evento puede ser muy larga en el tiempo, hasta el punto de moverse a

más de diez sitios. Nuevamente, para que la longitud de la página esté controlada se

utilizará una técnica de scripting para contraer y expandir toda esa información. Por

defecto, la última fecha en la que estuvo vigente ese evento permanecerá siempre visible.

En la Figura 38 se puede observar el bloque informativo de un evento con la fecha y el

lugar junto con la información de itinerancia oculta.

Figura 38: Bloque informativo de Fecha y lugar para un evento del tipo exposición

En la Figura 39 aparece este mismo bloque con la información de la itinerancia expandida

por el usuario. No toda la información sobre los lugares en los que estuvo está completa, lo

importante es saber dónde estuvo y en qué fechas. La dirección exacta del lugar puede

conseguirse por otros medios, ajenos al propósito de este campo.


4. SOLUCIÓN [141]

Figura 39: Bloque informativo de la fecha y lugar con la información de la itinerancia expandida

Para poder cumplir estas restricciones es necesario instalar varios módulos contribuidos

en Drupal.

Se podría pensar que el campo de fecha es un campo de texto libre, en el que se espera que

el usuario autenticado que introduzca la información, lo haga usando un formato de fecha

estándar. Esta opción podría ser válida si la información la introdujese siempre la misma

persona y ésta siempre se acordase de hacerlo igual, pero esto no es la realidad.

Además, hay que pensar que la fecha se utilizará para ordenar los eventos según fecha de

realización o que habrá vistas en las que los eventos estén clasificados según sean

actuales, próximos o realizados. Para todo este tipo de comparaciones es necesario que el

campo fecha esté en un formato que Drupal pueda interpretar como información numérica

temporal y pueda trabajar con ella.

Por tanto, para poder almacenar la fecha en Drupal se instalará el módulo contribuido

“Date”. Este módulo es compatible con “Views” y con “CCK”, por lo que permitirá crear

campos del tipo “Date”.

Para la presentación de este campo es necesario renombrar las funciones theme para

modificar la salida del HTML como se muestra en el Código 12. Este tipo de funciones,

como se vio en el estado del arte en la sección sobre Drupal, se redefinen en el archivo

template.php del tema en cuestión.

/** Ubicación de la función: date/date/date.theme **/



function theme_date_display_single($date, $timezone = NULL) {

//return '<span class="date-display-single">'. $date . $timezone .'</span>';

return $date. $timezone;

}

function theme_date_display_range($date1, $date2, $timezone = NULL) {

/*return '<span class="date-display-start">'. $date1 .'</span>'.

'<span class="date-display-separator"> - </span>' .

'<span class="date-display-end">'. $date2 . $timezone. '</span>';*/

return $date1 .' > ' .$date2 . $timezone;

}

Código 12: Funciones theme para la presentación de fechas

Como se ha podido ver en la Figura 38, la fecha tiene asociada una etiqueta que se muestra

siempre encima de la información. Esta etiqueta, según la jerarquía de la información, se

corresponderá con un encabezado de nivel 3 – h3 en HTML –. Para poder mostrarla,

Drupal permite configurar para cada campo la visibilidad de la etiqueta y la posición de la

misma: encima o en línea en la página de administración de campos, display fields, para un

tipo de nodo. Para que esta etiqueta se muestre como encabezado es necesario modificar

el HTML generado por el módulo “CCK” para los campos.

Este HTML se genera mediante un archivo de plantilla llamado content-field.tpl.php.

Este tipo de archivos se renombran insertando en el directorio del nuevo tema el archivo

original y el archivo modificado con el nombre original seguido por un guión y el nombre

del campo – content-field-field_date.tpl.php –.

<?php if (!$field_empty) : ?>

<div class="field field-type-<?php print $field_type_css ?> field-<?php print

$field_name_css ?>">

-- <?php if ($label_display == 'above') : ?>

-- <div class="field-label"><?php print t($label) ?>: </div>

-- <?php endif;?>

-- <div class="field-items">

<?php $count = 1;


if (!$item['empty']) : ?>

-- <div class="field-item <?php print ($count % 2 ? 'odd' : 'even') ?>">

-- <?php if ($label_display == 'inline') { ?>

-- <div class="field-label-inline<?php print($delta ? '' : '-first')?>">

-- <?php print t($label) ?>: </div>

-- <?php } ?><?php print $item['view'] ?>

++ <h3 class="subtitle-block-event"><?php print t($label) ?></h3>

++ <p><?php print $item['view'] ?></p>


4. SOLUCIÓN [143]

<?php $count++;

endif;

endforeach;?>

</div>

<?php endif; ?>

Código 13: content-field.tpl.php

En el fragmento de Código 13 se muestran las líneas originales borradas precedidas por

dos guiones y las líneas añadidas precedidas por dos ++, las líneas originales no se han

destacado. Se ha modificado la impresión de la etiqueta y se ha metido la fecha dentro de

un párrafo.

Respecto al almacenamiento del lugar se podrían utilizar campos de texto, pero vincular

estos campos de texto de manera que sean un único bloque de información es realmente

complicado. Por ello, la solución vendrá dada por un módulo que permita recoger este tipo

de información.

En este caso, ya existe en Drupal un módulo contribuido que permite almacenar toda clase

de información de localización de un lugar: dirección, teléfono, fax, ciudad, país, provincia

y otros. Es el módulo “Location”.

La instalación de este módulo genera un error en Drupal, este error se debe a un fallo en

su implementación y requiere la siguiente corrección. En el fragmento de Código 14 se

puede ver el error que da Drupal:

warning: array_filter() [function.array-filter]: The first argument should be

an array in

/sites/all/modules/location/contrib/location_cck/location_cck.module on line

385.

Código 14: Error generado por el módulo contribuido "Location"

Para quitar dicho error es necesario sustituir una línea de código en el fichero

location_cck.module en la función location_cck_token_values, que se muestra en

el fragmento de Código 15.

/** Línea original **/

'hide' =>

array_keys(array_filter($item['location_settings']['display']['hide']))

/** Línea de sustitución **/

'hide' => (isset($item['location_settings'])) ?

array_keys(array_filter($item['location_settings']['display']['hide'])) :

array(),

Código 15: Corrección del error

Para lograr la presentación de la Figura 38 es necesario redefinir la salida de HTML para

los campos que se quieren recoger. Para redefinir la salida, este módulo tiene un archivo

de plantilla llamado location.tpl.php, que será el archivo que hay que redefinir.



En el fragmento de

Código 16 se muestra el código desarrollado para lograr la presentación deseada. No se ha

mantenido nada del fichero original, ya que la salida mostraba más código del deseado y la

construcción del HTML no era semánticamente correcta. se puede ver el código original de

este fichero. Para el caso tan concreto que se está diseñando, muchos campos no se

recogerán y por tanto no se mostrarán. De modo que sólo se mantendrán los segmentos de

código que correspondan a los campos: nombre del lugar, información adicional, calle,

ciudad, provincia, código postal, país, teléfono y fax.

<p class="place"><em><?php echo $name; ?></em>

<?php if ($additional): ?>

<?php echo ' ('. $additional . ')'; ?>

<?php endif; ?></p>

<?php if ($street): ?>

<p class="street-address"><?php echo t('Address').': '.$street; ?>

<?php if ($city || $province || $postal_code) {

$city_province_postal = array();

if ($postal_code):

$city_province_postal[] = '. '. $postal_code;

endif;

if ($city):

$city_province_postal[] = $city;

endif;

if ($province):

$city_province_postal[] = '.'. $province;

endif;

echo implode(', ', $city_province_postal);

} ?>

<?php if ($country_name): ?>

<?php echo '('.$country_name.')' ?>

<?php endif; ?>

</p>

<?php endif;?>

<?php if (isset($phone) && $phone): ?>

<p><abbr title="<?php echo t('Telephone');?>">

<?php echo t('Phone');?>:</abbr>

<?php print $phone; ?>

<?php if (isset($fax) && $fax): ?>

<abbr title="Fax"><?php print t('Fax'); ?>:</abbr>

<?php print $fax; ?>


4. SOLUCIÓN [145]

<?php endif; ?>

</p>

<?php endif; ?>

Código 16: location.tpl.php

Con el nuevo código generado, la salida de HTML que se obtiene es que se presenta en el

fragmento de Código 17.

<p class="place"><em>Conde Duque</em> (Sala Juan de Villanueva)</p>

<p class="street-address">Dirección: C/ Conde Duque 9 y 11. 28015, Madrid

(España)</p>

<p>Teléfono: 912 345 678</p>

Código 17: Salida de HTML para la información del lugar

Como se puede observar en la Figura 38, también se inserta una etiqueta encima de la

información del lugar. Esta etiqueta tiene las mismas características que la de la fecha, por

lo que la manera de conseguir que aparezca y la presentación es la misma –también será

un encabezado h3 y su posición será encima-.

Para poder almacenar la información del horario no es necesario instalar ningún módulo

adicional. Esta información se insertará en un campo de texto y “CCK” ya permite insertar

campos de tipo texto.

Las características de este campo no serán otras que un área de texto de no más de cinco

líneas, que como en los casos anteriores tendrá una etiqueta y por tanto, será necesario

redefinir el archivo de plantilla content-field.tpl.php también para este campo.

Es necesario analizar la relación que tienen la fecha, el lugar y el horario. El requisito dice

que para cada fecha, se deberá almacenar un lugar relacionado y un horario. Para lograr

esto, la información debe estar asociada como un bloque. Drupal debe saber a qué fecha le

pertenece qué dirección y qué horario, para que el orden de las itinerancias sea correcto

cuando se muestre.

Para lograr esto, Drupal necesita asociar la información en la base de datos. Esta

asociación será posible gracias a un módulo contribuido llamado “Content Group”. Este

módulo permite combinar distintos campos en grupos que pueden repetirse y que

trabajan como un único campo. De esta manera cada grupo tiene asociado una posición –

que comienza en la 0 y es incremental- que hereda cada campo del grupo y lo vincula a

éste.

Los grupos se configuran del mismo modo que cualquier otro campo en Drupal.

Dependiendo del tipo de nodo, se le puede asociar un grupo con unos campos u otros y se

puede convertir en múltiple o simple. Este módulo no permite crear grupos dentro de

grupos.



Para poder controlar la presentación de los grupos, el módulo está implementado de

manera que llama a un archivo de plantilla, fieldgroup-simple.tpl.php. Este archivo

se redefine igual que el archivo de plantilla para los campos de “CCK” y el código

implementado se encuentra en el fragmento de Código 18. Este código no conserva nada

del original.

Como se puede ver en la Figura 38, los grupos tienen también una etiqueta para identificar

la información que se puede encontrar dentro de ellos. Dicha etiqueta se configura como

las etiquetas de los campos “CCK” y se imprime a través del fichero antes mencionado. En

este caso, la etiqueta serán un encabezado de nivel 2 –etiqueta h2 en HTML-.

<?php global $theme_path; ?>

<?php if ($content) : ?>

<div class="fieldgroup groupevent <?php print $group_name_css; ?>">

<?php if ($label): ?>

<div class="title">

<?php if($group_name_css == 'group-mediafiles'): ?>

<h2 id="media-player" class="news-title">

<?php elseif($group_name_css == 'group-moreinfo'): ?>

<h2 id="more-info" class="news-title">

<?php else: ?>

<h2 class="news-title">

<?php endif; ?>

<img src="/<?php print $theme_path ?>/style/images/btn_no_js.gif"

alt="" style="padding:0 10px 0 0;" />

<?php print $label; ?>

</h2>

</div>

<?php if ($description): ?>

<div class="description"><?php print $description; ?></div>

<?php endif; ?>

<?php endif; ?>

<div class="wrapper-content">

<div class="content">

<?php print $content; ?>

</div>

</div>

</div>

<?php endif; ?>

Código 18: fieldgroup-simple.tpl.php


4. SOLUCIÓN [147]

En la Figura 38 y Figura 39 se pueden ver las fechas de itinerancias del evento colapsadas

y expandidas respectivamente. Esto es posible gracias a la implementación de una función

que engloba las fechas – a partir de la posición 1-, dentro de una capa con un identificador

único sobre el que actuará un script. Dicho script - Código 19 - está desarrollado en jQuery

y ocultará la información y permitirá que el usuario la expanda y contraiga cuando le

convenga.

// Función que carga el evento clic sobre el enlace para contraer/expandir

function clickOnItinerancia(){

$('.itinerancia h3 a').click(function(evento){

evento.preventDefault();

if($(this).parent().next().css('display') == 'none'){

expandSubgroupBlock($('.group-locationdate'),'.itinerancia');

}

else{

collapseSubgroupBlock($('.group-locationdate'),'.itinerancia');

}

});

$('.itinerancia h3 a').keypress(function(evento){

if(evento.which == 13 || evento.which == 32){




}

else{


}

}

});

}

// Función que contrae el bloque

function collapseSubgroupBlock($group, strClass){

$group.find('h3.subtitle-block-event a img').

attr('src','/sites/default/themes/fpi/style/images/btn_mas.gif');

$group.find('h3.subtitle-block-event a img').attr('alt','Mostrar');

$group.find(strClass + ' .content-multigroup-wrapper').addClass('hide');

}

// Función que expande el bloque

function expandSubgroupBlock($group, strClass){

$group.find('h3.subtitle-block-event a

img').attr('src','/sites/default/themes/fpi/style/images/btn_menos.gif');



$group.find('h3.subtitle-block-event a img').attr('alt','Ocultar');

$group.find(strClass + ' .content-multigroup-wrapper').removeClass('hide');

}

Código 19: script para ocultar y expandir las fechas de un evento

Por defecto, esta información está visible. Es el JavaScript el que la contrae cuando el

documento está listo. De esta manera, cuando el navegador carezca de la tecnología

necesaria la información se mostrará como en la Figura 39.

4.13.4. Cómo llegar

La información sobre cómo llegar al lugar donde tendrá lugar el evento no debe ser

indispensable. Se quiere poder almacenar un mapa de la ubicación y unas pequeñas

indicaciones sobre cómo llegar si se conocen.

En la Figura 40 se puede observar cómo se vería el bloque de información de cómo llegar

para un evento. Por motivos de interacción con el usuario, se ha decidido que el mapa del

lugar sea un mapa de Google incrustado. Sin tener en cuenta cuestiones de accesibilidad en

este momento, se implementará de esta manera. Posteriormente se evaluará y

dependiendo de los resultados se decidirá qué hacer al respecto.

Figura 40: Bloque de información "Cómo llegar" de un evento

Para que en una página web se pueda insertar un mapa de Google es necesario usar

frames, más concretamente un elemento <iframe> de HTML. Este tipo de elementos no

están permitidos en el DTD XHTML 1.0 Strict, pero sí en el XHTML 1.1 Transitional.

Drupal puede permitir la inserción de este tipo de elementos a través de los campos de

texto, pero esta actividad puede generar problemas de seguridad. Para que en Drupal se

pueda insertar un mapa de Google mediante un <iframe> y garantizar la seguridad del

sitio se instalará el módulo contribuido “Google Maps Embed”.


4. SOLUCIÓN [149]

No es necesario redefinir ninguna función ni archivo para este módulo. La presentación

del mapa se puede conseguir utilizando sólo CSS y las clases que vienen insertadas por

defecto en el mapa.

Las instrucciones que se quieren mostrar sobre cómo llegar tienen características

similares al horario. No hay un formato fijo en la información que se va a introducir ni

unos valores predeterminados. Por tanto, será un campo texto de no más de 5 líneas.

Para lograr la vinculación de los campos de este bloque es necesario crear un grupo como

en el caso anterior. Sólo que este grupo no tendrá múltiples valores, ya que el requisito

dice que sólo se querrá almacenar la ubicación del último lugar en el que se realizó el

evento. En caso de que el evento esté activo actualmente, esa información se

corresponderá con el lugar actual. Por tanto, la visualización de la Figura 40 se consigue

redefiniendo el mismo archivo de plantilla del módulo “Content Group”.

4.13.5. Galería fotográfica

Para cumplir el requisito es necesario tener en cuenta que las imágenes para la galería

fotográfica no deben ocupar más de 500KB y deben tener una resolución de 600x600.

La galería fotográfica tendrá un mecanismo de navegación adecuado a la cantidad de

imágenes que puede llegar a tener ésta en un evento. Dado que la galería fotográfica de un

evento puede crecer considerablemente, se usará un paginador que permita recorrer las

imágenes en miniatura de seis en seis. Por motivos de diseño, la resolución de la miniatura

de la imagen debe ser de 105x74px.

Cuando se haga clic sobre una de las imágenes, ésta se deberá ampliar a su tamaño real y

mostrar su alternativo. Estando en la vista a tamaño real de la imagen también se podrá

navegar por toda la galería mediante otro mecanismo de paginación independiente del

anterior.

En la Figura 41 se puede observar el bloque de información de la galería fotográfica de un

evento. En esta vista se muestran las seis primeras fotos en miniatura de la galería de un

evento y en los extremos del bloque aparecen dos flechas que forman el paginador. La

flecha de la izquierda apenas se percibe porque está desactivada, lo que quiere decir que

no se puede retroceder a imágenes anteriores. La flecha de la derecha está resaltada con

color morado, lo que indica que existen más imágenes a las que se puede acceder haciendo

clic sobre ella.



Figura 41: Vista de la galería fotográfica desplegada de un evento

En la Figura 42 se observa la vista en tamaño real de una de las fotografías de la galería de

un evento. La fotografía se resalta sobre el fondo de la página oscureciendo dicho fondo y

posicionando la foto en el centro de la ventana. En los extremos laterales de la foto,

aparece un mecanismo de navegación que permite recorrer todas las imágenes de la

galería en tamaño real. En la esquina superior derecha aparece un botón en forma de aspa

para cerrar esta vista y regresar a la página. En el pie de la fotografía aparece un texto que

se corresponde con el título de la misma.

Figura 42: Fotografía en tamaño real de la galería de un evento

Para lograr la implementación de las galerías fotográficas de los eventos, se instalarán en

Drupal los módulos “Gallery Assist”, “Gallery Assist ImageCache”, “Gallery Assist

Lightboxes” y “Gallery Assist Views”.

Todos estos módulos son contribuidos. El módulo que permite la creación de galerías y

que proporciona la funcionalidad necesaria a Drupal para crear nodos del tipo “Galería” es

“Gallery Assist”, el resto permite integrar este módulo principal con otros módulos


4. SOLUCIÓN [151]

contribuidos como “Views” o “ImageCache”. El módulo FileField no es necesario para subir

imágenes en este caso. Será el módulo “Gallery Assist” el que proporcione esa

funcionalidad.

Estos módulos son bastante complejos de explicar cómo funcionan y todo lo que permiten

hacer está fuera del ámbito de este trabajo. Simplemente se van a comentar todas las

modificaciones que se han hecho para lograr una galería lo más accesible posible, teniendo

en cuenta las limitaciones que presenta un contenido meramente visual, y todas las

modificaciones que se han hecho para corregir algunos fallos de incompatibilidad con los

navegadores.

Para esta galería, el módulo que se ha tenido que modificar es “Gallery Assist Lightboxes”.

Este módulo utiliza una biblioteca de JQuery llamada fancybox, que permite crear el el

elemento de paginación mostrado en la Figura 41. Todo lo que tiene que ver con esta vista

está controlado por este módulo, el cual presenta ciertas incompatibilidades con versiones

de Internet Explorer 7 e inferiores para la versión de la biblioteca 1.3.1. Estas

incompatibilidades están en el fichero jquery.fancybox-1.3.1.css debido al código que se

utiliza para Internet Explorer. Estos problemas se ven solucionados en la versión

jquery.fancybox 1.3.2 [fancybox, 2011]. Por lo que se ha sustituido la versión de la

biblioteca que incorpora el módulo, por esta última.

Esta biblioteca genera el pie de la foto que aparece en la Figura 42 sólo a partir del título

que se le da a la foto. Sería necesario tener en consideración la inclusión del atributo

longdesc para poder ver una descripción más detallada de cada fotografía.

Para lograr esto habría que modificar la función gallery_assist_image_box($type,

&$item, $conf, $img) la cual no es ninguna función tema que se pueda redefinir y está

contenida en el fichero gallery_assist_lightboxes_display.inc del módulo. El

código de esta función es bastante complejo y no se va a mostrar, pero la idea sería

insertar un atributo más a la imagen que se corresponda con un longdesc. El valor de este

longdesc será la ruta hacia la página donde se mostrase el resto de información.

Para conseguir la presentación de la Figura 42 no es necesario modificar nada más de este

módulo. Pero para lograr la presentación de la Figura 41 y la funcionalidad de ese

paginador sí que es necesario modificar algunas funciones del mismo fichero de este

módulo. En este caso, las funciones son funciones de tema que se pueden redefinir el

template.php del nuevo estilo.

La primera función que hay que modificar es theme_gallery_assist_display, que

como su nombre indica es la encargada de mostrar la galería. Esta función se modifica por

completo de manera que se tengan las mismas capas con las mismas clases que para

cualquier otro bloque de información de un evento. Esta función genera desde el

encabezado de “Galería fotográfica” hasta las capas y elementos para el paginador de las



miniaturas. En el fragmento de Código 20 donde se muestra la parte de la función donde

se crean las capas de HTML.

...

$output = '<div id="gallery-container-'. $conf['nid'] .'" class="fieldgroup

groupevent '. $type .' gallery-container '.' clear-block">';//.

$conf['my_attr'] .'>';

$output .= '<div class="title">';

$output .= '<h2 id="gallery" class="news-title">';

$output .= '<img style="padding: 0pt 10px 0pt 0pt;" alt="Contraer"

src="/sites/default/themes/fpi/style/images/btn_no_js.gif" />';

$output .= 'Galería fotográfica</h2>';

$output .= '</div>';

//$output .= $conf['pager_position'] == 'top' || $conf['pager_position'] ==

'both' ? $pager : '';

$output .= '<div class="wrapper-content"><div class="content">';

// Empieza el paginador de la galeria

...

Código 20: parte del HTML que construye la galería de un evento

La siguiente función que se modificó es theme_gallery_assist_item_box, que como su

nombre indica es la encargada de presentar cada elemento de la galería. Esta función sólo

se modifica para añadir las clases necesarias a cada imagen para que el paginador pueda

actuar sobre ellas.

El paginador se ha implementado con jQuery. En el fragmento de Código 21 muestra cómo

se ocultan todos los grupos de imágenes mediante CSS menos el primero y se asocia un

evento clic en las flechas de los extremos de la galería que ejecute varias acciones

secuenciales. Las acciones se corresponderán con dos secuencias distintas, en función de

hacia qué lado se esté paginando.

Por ejemplo, si se avanza en la galería, es decir se hace clic sobre la flecha del extremo

derecho, la secuencia de acciones es la que se muestra en el fragmento de Código 21.

function clickOnNext(evt){

// Detener la accion por defecto (href)

evt.preventDefault();

// Si el boton "anteriores" esta desactivado, se activa

if (evt.data.obj.prev == 0)

enableButton($('#'+ evt.data.obj.strWrapper +' .prev-pager'),

evt.data.obj,

clickOnPrev);

// Antes de actualizar el estado, aplicamos el slide para realizar la

//transición del siguiente al actual


4. SOLUCIÓN [153]

slideEffectLeft($('#'+evt.data.obj.strContainerPager+'-'+evt.data.obj.now),

$('#'+evt.data.obj.strContainerPager+'-'+evt.data.obj.next));

evt.data.obj.prev = evt.data.obj.now;

evt.data.obj.now = evt.data.obj.next;

if (evt.data.obj.next == evt.data.obj.last) {

disableButton($('#'+ evt.data.obj.strWrapper +' .next-pager'));

evt.data.obj.next = 0;

}

else

evt.data.obj.next++;

// Actualizamos el paginador, si estaba definido en la llamada

if (evt.data.obj.objNumPager)

updateNumPager(evt.data.obj.objNumPager,

evt.data.obj.now,

evt.data.obj.last);

}

Código 21: Secuencia de acciones que se lanzan al avanzar en la galería.

Como se puede observar en este fragmento, el código del paginador es bastante complejo.

La idea que resume el código es la siguiente:

1. Se detiene la acción por defecto al hacer clic sobre un enlace en HTML.

2. Se comprueba el estado del botón “Anterior”, para activarlo si no lo está.

3. Se oculta el grupo de imágenes actual y se muestra el siguiente.

4. Se indica al Paginador el nuevo estado: cuál es el bloque actual, cuál el anterior y

cuál es el siguiente.

Aunque JavaScript no es un lenguaje orientado a objetos, la mejor solución era convertir el

elemento de paginación en un objeto.

4.13.6. Galería de vídeos

Para que este requisito sea satisfecho hay que tener en cuenta que el tamaño para los

vídeos no debe superar los 100MB, su resolución debe ser de 480x320 y cada vídeo debe

poder llevar un título y una breve descripción.

Todavía se desconoce la cantidad de información audiovisual que se puede generar en el

sitio web. Aun así, se ha supuesto que se pueda llegar a tener un vídeo por nodo de media

cuando la implantación del sitio sea definitiva.

Por ello, se ha optado por evitar tener que incrustar de manera manual un objeto con el

reproductor en cada nodo donde se necesite. Este problema se resuelve con la instalación

en Drupal del módulo contribuido “SWF Tools” [Google, 2011].



“SWF Tools” es un módulo que permite incrustar el código de un objeto que a su vez carga

un reproductor de vídeo, haciendo uso de la biblioteca SWFObject [Adobe, 2008]. Este

módulo puede utilizar dos reproductores: FlowPlayer [Flowplayer, 2011] y JW Media

Player [Longtail, 2011]. En este caso, el reproductor que se utilizará en todo el sitio web

será JW Media Player. Sobre el reproductor que se está utilizando, el por qué se ha elegido

éste y la accesibilidad del reproductor se hablará en la Implementación del .

El módulo “SWF Tools” es realmente complejo y, al igual que el módulo “Gallery Assist”,

está fuera del ámbito de este trabajo tratarlo en profundidad. Por tanto, sólo se va a

comentar lo que se ha tenido que modificar para lograr la presentación que se puede ver

en la Figura 43. El cómo se inserta este reproductor a través del módulo también se verá

en la Implementación del .

Hay que tener en cuenta que un evento puede tener varios vídeos y para éstos sólo se

quiere un reproductor único en el que se puedan ver todos. Primero se va a resolver cómo

insertar varios vídeos en un evento con la información asociada a cada uno. Para ello es

necesario crear un grupo de campos formado por un campo de texto para el título y otro

para subir el fichero al gestor. De esta forma, Drupal podrá saber a qué vídeo le

corresponde qué título. Visto así puede parecer que se está olvidando un campo de

información, la descripción del vídeo. A continuación se explica cómo se introduce ese

campo.

Se podría pensar que el módulo “FileField” es suficiente para subir archivos al gestor, pero

como se puede ver en la Figura 43, cada vídeo de la lista está acompañado por una imagen

en miniatura que contiene un frame del vídeo. Esta imagen se genera de manera

automática gracias a un módulo adicional que depende de “FileField”. Este módulo

adicional es “Video”, que además de poder generar varios frames a partir de los primeros

segundos de vídeo, permite ajustar la resolución y recoger la descripción del vídeo.

Como grupo de campos, la presentación de bloque de información se consigue mediante el

archivo de plantilla fieldgroup-simple.tpl.php como para cualquier otro grupo de

información –menos la galería fotográfica-.

Por otro lado, para lograr una única instancia del reproductor y que se muestre la lista de

vídeos de la Figura 43, es necesario instalar otro módulo contribuido. El módulo “XSPF

Playlist” será el encargado de generar la lista de reproducción en XML a partir de los datos

insertados en el evento. La presentación de esta lista se consigue a través de las clases que

integra el módulo y adaptando el CSS a las necesidades del nuevo estilo.


4. SOLUCIÓN [155]

Figura 43: Bloque de información de la galería de vídeos de un evento

Para que el reproductor funcione por listas de reproducción ha sido necesario añadirle la

librería jquery.playlist.js, una librería de jQuery, que carga acciones del reproductor sobre

los elementos de esta lista. Concretamente esta acción es la carga e inicio del vídeo en el

reproductor cuando se hace clic sobre el vídeo de la lista.

En este caso, dado que el evento no tendrá tantos vídeos como imágenes, la lista de

reproducción no utilizará ningún paginador. Para controlar la longitud de la lista, se

utilizará un scroll interno al bloque como el que se muestra en la Figura 44. Este caso es

muy extremo y se producirá pocas veces.

Este módulo es compatible con “SWF Tools” y es capaz de generar un archivo que

interpreta el reproductor. Aun así, para que el reproductor pueda extraer más información

de los vídeos de la que proporciona “XSPF Playlist”, se ha modificado el XML que se genera

incluyendo en la cabecera del XML la línea que aparece en el fragmento de Código 22.

'<playlist version="1" xmlns=http://xspf.org/ns/0/

xmlns:jwplayer="http://developer.longtailvideo.com/trac/wiki/FlashFormats">'

Código 22: Cabecera del XML de la lista de reproducción

http://xspf.org/ns/0/



Figura 44: Lista de reproducción con scroll vertical

Tanto en la Figura 43 como en la Figura 44, se puede ver al pie del reproductor un enlace

que pone “Mostrar barra de reproducción por teclado”. Sobre esta barra se hablará en la

Implementación del .

4.13.7. Documentación

Los documentos generados sobre un evento pueden estar en varios formatos y se debe

poder ofrecer en todos los formatos disponibles. Todos los documentos tendrán un título y

una descripción asociada.

Como se puede deducir de lo comentado hasta ahora sobre cómo subir archivos al gestor,

este campo hará uso del módulo “FileField”. Se creará un grupo multivaluado que tenga

campos para el título del documento, la descripción del documento y el documento en sí.

Nuevamente, para lograr la presentación de esta información como se muestra en la

Figura 45 se usará el mismo archivo de plantilla que para todos estos grupos.

Figura 45: Bloque de información de documentación de un evento


4. SOLUCIÓN [157]

Como se ha comentado con anterioridad, es importante tener más o menos acotada la

longitud de la página. El número de documentos de un evento no va a crecer mucho, a no

ser que éste tenga ponencias. Por ello, todas las ponencias se agruparán dentro de una

misma capa, como las fechas de itinerancia de un evento para ocultarlo por JavaScript.

Figura 46: Bloque de información de documentación de un evento con las ponencias expandidas

La idea es exactamente la misma que la expuesta en el campo de fecha y lugar. El script

debe contraer todas las ponencias, ocultándolas tras un botón que permita mostrarlas. De

este modo, cuando el usuario esté interesado las desplegará y en caso contrario las tendrá

ocultas. En la Figura 46 se puede ver cómo se mostrarían todas las ponencias disponibles

en un evento.

4.13.8. Información adicional

La información adicional sobre el evento puede ser muy variada, desde quien lo coordina,

las entidades colaboradoras, hasta el programa del mismo. Dadas las características de

este campo y la libertad que se necesita en él para insertar la información, se creará como

un grupo con un área de texto de longitud ilimitada.

La presentación de este campo es la que se puede ver en la Figura 47 que se consigue

mediante el archivo de plantilla para los grupos de campos. El resto de estilo, en principio

se hará escribiendo HTML de manera manual. Sólo tendrán permisos de edición sobre este

campo los usuarios autenticados con permisos específicos. Por ejemplo, para poder ver la

información de asistencia como se muestra en la figura, es necesario generar el fragmento

de Código 23. El problema que puede presentar esta forma de edición del contenido es que

se pierda la semántica de la página o que se cometan fallos de sintaxis de HTML por un mal

uso. Este campo debe estar sujeto a una revisión más exhaustiva y las personas

responsables de su edición deben tener o recibir conocimientos sobre HTML y

accesibilidad.



Figura 47: Bloque de información más información de un evento

<h3 class="subtitle-block-event">Asistencia</h3>

<p>La asistencia a este encuentro no tiene coste de matrícula. Aquellas

personas interesadas en asistir, deberán ponerse en contacto con la Fundación

en la dirección: <a

href="mailto:[email protected]">[email protected]</a> o bien en

el teléfono <span>12 345 67 67</span></p>

Código 23: Información sobre cómo asistir a un evento

Como línea de trabajo futura, se estudiará la instalación de un editor integrado en Drupal

para que mediante botones se inserte el código HTML necesario para crear cada estilo.

Este campo no requiere la instalación de ningún módulo adicional en Drupal.

4.14. Implementación de R-FUN-20 y R-FUN-21: Baja y

modificación de eventos

El cumplimiento de estos requisitos no ha requerido ninguna configuración adicional

sobre el gestor de contenidos, puesto que Drupal permite la baja y modificación de

contenidos existentes en el sistema, sólo a los usuarios con privilegios en el sistema.

Las restricciones sobre la eliminación de los archivos de imagen o la obligatoriedad de los

campos, también se están cumpliendo.


4. SOLUCIÓN [159]

4.15. Implementación de R-FUN-20: Consulta de eventos

Este tipo de consultas se crean a través de views o vistas. Para este caso concreto, se creará

una vista de tipo página que filtre por actividades publicadas y según el tipo de actividad.

La vista de los eventos que coincidan será de teaser y sólo contendrá el título, la imagen

con una resolución de 160x110, la fecha de realización y un resumen de su descripción.

Esta vista de teaser se visualiza como el bloque mostrado en la Figura 48. Además, se

añadirá un paginador para cuando el número de actividades sea mayor que 8. Parte de la

página generada por la consulta es la que se muestra en la Figura 49.

Figura 48: Vista de teaser para un evento

Como la información que se muestra en la vista resumen de un evento es ligeramente

diferente a la mostrada en una noticia, la vista no es exactamente igual. Para este caso,

debido al tamaño de la fotografía y la posición que ocupa dentro de la vista, tanto la

imagen como el texto serán un enlace al evento completo. Por otro lado, ha habido que

crear un preset nuevo para la fotografía con el módulo “ImageCache”, que se aplicará en

esta vista de teaser.

Figura 49: Consulta de los encuentros



4.16. Implementación de R-FUN-13: Alta de noticias

Para el alta de noticias es necesario tener en cuenta las siguientes especificaciones:

Se debe poder almacenar el título, el cuerpo de la noticia, la autoría, el estado de

publicación, una fotografía, y los temas relacionados.

También se debe poder establecer la relación con el evento que esté relacionada.

La selección del evento debe hacerse por el título del mismo, sin la necesidad de un

identificador interno.

Se tiene que poder asignar permisos sobre las noticias.

La fotografía debe ser obligatoria, debe tener un texto alternativo, no debe superar

los 500KB y su resolución debe ser de al menos de 670x320.

Una noticia no tiene por qué estar relacionada con un evento. Se debe permitir

seleccionar un evento ya existente en el gestor mediante su título.

Los temas relacionados son obligatorios y deben cumplir lo expuesto en el R-FUN-

3: Temas relacionados.

Dada la especificidad de los campos para este tipo de contenido, se creará un tipo de nodo

nuevo que sea “Noticia” –el tipo de nodo se nombrará en mayúsculas para distinguirla de

una instancia-.

Al tipo de nodo “Noticia” se le deben añadir nuevos campos, que por defecto Drupal no

puede almacenar. Estos campos serán: la fotografía, los temas relacionados y el evento

relacionado. El resto de campos requeridos por este tipo de contenido Drupal dispone de

ellos para almacenarlos.

El campo para los temas relacionados quedó solucionado en el apartado de

Implementación del R-FUN-3: Temas relacionados. El campo para el evento relacionado se

puede crear gracias al módulo contribuido “CCK”, del cual ya se ha hablado anteriormente.

Este módulo permite crear entre otros tipos de campos, el tipo node reference. Este tipo de

campo permite seleccionar un nodo existente a través de su título, mediante una lista de

selección o un campo de auto-completado.

Para que el módulo “CCK” permita crear campos a partir de imágenes se necesita instalar

el módulo contribuido “ImageField”. Este módulo se instala dentro del módulo “CCK” para

permitir este tipo de campos. La configuración de estos campos ya presenta las opciones

de restricción de este requisito. El campo fotografía permite restringir el tamaño de los

archivos, la resolución, y las opciones para su alternativo.

En la Figura 50 se puede observar la vista de una noticia en el sitio web. Aparece en primer

lugar el título de la noticia, destacado en negrita. A continuación, le sigue un recuadro

rotulado como “Presentación” que contiene la imagen de la noticia y su texto. Por último

aparecen dos campos en línea que tienen un enlace al evento relacionado y los temas

relacionados.


4. SOLUCIÓN [161]

Figura 50: Vista de una noticia en el sitio web

El requisito dice que la notica debe tener una resolución de, al menos 670x320, sin

especificar qué pasa con las imágenes más grandes. Según el diseño de la Figura 50, la

imagen no puede superar ese tamaño, dado que la imagen no cabría. Además, todas las

noticias tienen otra vista resumen para su página de consulta -Implementación del R-FUN-

17: Consulta de noticias-. Esta vista es un resumen de la noticia, con la misma fotografía en

un tamaño más pequeño.

Para lograr esta presentación en el sitio web ha sido necesario modificar en Drupal el

archivo de plantilla node.tpl.php. El archivo page.tlp.php y node.tpl.php dependen

del tema que esté instalado en el sitio web. Al crear un estilo propio, por lo general suele

ser necesario modificar estos archivos. Para este caso en concreto, se ha modificado el uso

de las cabeceras HTML para los títulos y las clases de las capas.

Desde este fichero se puede controlar la presentación tanto de la vista de teaser como de la

vista full-node. Por ello, para la primera también se han cambiado las clases y el uso de

encabezados. Un fragmento de este archivo se puede ver en Código 24.

<?php if($content): ?>



<div id="node-<?php print $node->nid; ?>"

class="node<?php if ($sticky) { print ' sticky'; } ?>

<?php if (!$status) { print ' node-unpublished'; } ?>">

// Si es la vista de teaser, creamos la estructura del título de manera que

// podamos meter las imágenes de fondo

<?php if ($node->teaser): ?>

<?php if (drupal_is_front_page()): ?>

<div class="title">


<a href="<?php print $node_url ?>"><?php print $title ?></a>

</h3>

<?php else: ?>

<div class="title">


<a href="<?php print $node_url ?>"><?php print $title ?></a>

</h2>

<?php endif; ?>

<?php if ($submitted): ?>

<p class="posted"><?php print $submitted; ?></p>

<?php endif; ?>

</div> 

<div class="wrapper-content">


<?php print $node->field_photography[0]['view'] . $content .

'</div>

</div>'; ?>

<?php // Si la vista es full-node construimos las clases del cuerpo de la

// noticia ?>

<?php elseif (($node->type == 'news')): ?>

<?php

$divbody = '<div class="groupevent group-presentation">';

$divbody .= '<div class="title"><h2 class="news-title">';

$divbody .= t('Presentation');

$divbody .= '</h2></div>';

$divbody .= '<div class="wrapper-content">';

$divbody .= '<div class="content">';

...

Código 24: fragmento de código del archivo de plantilla node.tpl.php


4. SOLUCIÓN [163]

Para poder subir un archivo externo a Drupal se necesita que el módulo “CCK” permita

crear campos de este tipo. Este módulo se complementa con el módulo “FileField”, para

que los campos puedan ser de tipo archivo. Este módulo permitirá explorar los directorios

locales para subir archivos de cualquier tipo. De este modo, se podrá crear un campo para

subir la imagen de la noticia al gestor de contenidos.

Para que la fotografía de la notica no tenga que subirse al sitio web en distintos tamaños y

se redimensione automáticamente según las necesidades de cada vista, existe en Drupal

un módulo contribuido que permite crear distintos tipos de vistas para imágenes.

El módulo “ImageCache”, que depende a su vez de una API para el redimensionamiento de

imágenes, “ImageAPI”, es el módulo que permite la generación de vistas de imágenes a

partir de un único archivo.

Con este módulo se pueden realizar muchos tipos de redimensionamientos de imágenes.

Recortar: recorte de una imagen en el rectángulo especificado por el

desplazamiento y dimensiones dados.

Desaturar: convertir una imagen en escala de grises.

Redimensionar: cambiar el tamaño de una imagen según las dimensiones dadas,

haciendo caso omiso de la relación de aspecto.

Girar: rotar una imagen.

Escalar: cambiar el tamaño de una imagen manteniendo la relación de aspecto

original (sólo es necesario especificar un valor).

Escalar y recortar: cambiar el tamaño de una imagen mientras se mantiene la

relación de aspecto, entonces se aplica el recorte con las dimensiones

especificadas.

Enfocar: enfocar una imagen con máscara de enfoque.

En los siguientes apartados se explican las vistas creadas para las fotografías de las

noticias en cada una de sus vistas.

Además de esto, es necesario configurar para el tipo de nodo “Noticia” dónde se

almacenan en el servidor los archivos y cuál es el criterio de nombrado. El módulo

“FileField” permite de manera global para un campo en un tipo de nodo en concreto

definir este tipo de configuraciones. Es decir, para el campo “fotografía” del tipo “Noticia”

se puede definir el directorio de archivos y el nombrado a utilizar sobre el archivo.


modificación de noticias








4.18. Implementación del R-FUN-17: Consulta de noticias

Para poder cumplir este requisito se debe tener en cuenta las siguientes consideraciones:

La consulta de las noticias generan páginas en el sitio web. Cada página mostrará

un máximo de 8 elementos.

Para navegar por el resultado de la consulta será necesario un paginador.

Los usuarios anónimos no podrán ver las noticias despublicadas.

Para la comodidad de los usuarios, la consulta de las noticias devolverá una vista

resumen de cada una de ellas.

La vista resumen mostrará el título, la fecha de publicación, la fotografía con una

resolución de 80x80px, un resumen de su texto y el evento relacionado, si lo tiene.

Sólo los usuarios con privilegios podrán filtrar las noticas por estado de publicación o

temas relacionados. En la Figura 51 se muestra la vista de una consulta de noticias. En esta

vista aparecen tres bloques, cada uno de ellos contiene una noticia con la información

indicada anteriormente.

Figura 51: vista de la página de noticias con el resumen de tres de ellas


4. SOLUCIÓN [165]

La implementación de estas consultas se ha realizado con el módulo “Views”. Se ha creado

una vista de página que filtra todos los nodos del tipo “Noticia” que están publicados y los

muestra a través de una ruta del sitio web. Además, los nodos aplican muestran su vista de

teaser.

Los campos que se deben mostrar en la vista de teaser, se configuran a través de la página

de display fields del tipo de nodo “Noticia”. Para la vista de la fotografía hay que crear

primero un preset con el módulo “ImageCache”.

El paginador y el número de elementos que se muestran se configuran también a través de

la vista. No ha sido necesario renombrar ningún archivo de “Views” para conseguir esta

presentación. Como se había comentado anteriormente, sí se ha modificado el archivo de

plantilla node.tpl.php para lograr esta vista de teaser de una noticia.

Para la vista full-node, todos los campos deben poder consultarse por lo que no se excluye

ninguno desde la página de administración de campos display fields. El formato de la

fotografía para esta vista será el mismo que para los eventos, por lo que una vez creado el

preset para ésta, se le podrá aplicar el mismo a la foto del evento.

4.19. Implementación de R-FUN-21: Alta de anuncio

Para cumplir estos requisitos es necesario tener en cuenta las siguientes restricciones:

La imagen del anuncio siempre debe estar presente. Tiene que tener una

resolución de 670x155 y un tamaño inferior a 250KB.

El eslogan del anuncio también debe estar presente siempre.

La fecha del evento debe acompañar al eslogan.

Además, tiene que ser posible ampliar la información del evento relacionado.

Para poder asociar un anuncio a un evento se ha optado por crear un grupo en el evento

formado por un campo imagen y un campo eslogan. El campo imagen tendrá las

restricciones expuestas anteriormente respecto al tamaño y la resolución, y el campo del

eslogan será un campo de texto con un límite de 512 caracteres por restricciones de

diseño.

Tanto para crear el grupo como los dos tipos de campos no es necesario instalar ningún

módulo adicional, ya que los módulos “CCK” y “Content Group” servirán para ello. Como se

vió en la Implementación de R-NFUN-10: Características de la página principal”, los

anuncios sólo se mostrarán en la página principal y por tanto, no se mostrarán como

información adicional en el evento. Por ello, estos campos tendrán una peculiaridad

especial, su visibilidad en el tipo de nodo “Evento” estará deshabilitada para sus dos vistas

–teaser y full-node-.



En la Figura 52 se puede ver el visor de anuncios que se muestra en la página principal del

sitio web. Si se observa con detenimiento la figura, se puede ver que el anuncio aparece

con una imagen, un eslogan y la fecha del evento. Anteriormente, cuando se habló del

grupo y sus campos no se dijo nada sobre la fecha del evento. Esto se debe a que la

consulta de los anuncios se hace a través de “Views”, desde el cual se puede consultar

cualquier información de un tipo de nodo.

Figura 52: Vista en la página principal del visor de anuncios

Es necesario crear el grupo Anuncio con los campos de imagen y eslogan para que se

pueda subir esta información al gestor. El mejor sitio donde insertar esta información es

dentro del evento con el que está relacionado el anuncio y de este modo obtener su fecha.

Por otro lado, para lograr la presentación que se muestra en la Figura 52 no ha sido

necesario renombrar ninguna función theme ni ningún archivo de plantilla, sólo aplicar

CSS a las capas que este ya posee. Sobre el funcionamiento del visor de anuncios se

hablará en la “Implementación del R-NFUN- 11: Visor de anuncios”.


modificación de anuncios






4.21. Implementación de R-FUN-24: Consulta de anuncios

Respecto de la solución de este requisito está todo prácticamente comentado en la

“Implementación de R-FUN-21: Alta de anuncio”. Destacar que es a través de la

construcción de una vista como se genera la consulta de los anuncios. La vista que se


4. SOLUCIÓN [167]

construye a través de “Views” la genera por defecto el módulo “Views Slideshow” y

permite crear todas las instancias necesarias dentro de esta vista por defecto. Para este

visor de anuncios se ha creado una instancia particular que consulta el campo eslogan de

un nodo, el campo fecha y el campo imagen del anuncio. Además, se le han añadido los

filtros para tipo de nodo “Evento”, que tengan anuncio, y que su fecha de inicio sea mayor

o igual que la actual.

Sólo hay que añadir que para que lograr que el número de anuncios sea 4 y que el orden

en el que aparecen sea el que se pide en el requisito R-NFUN- 11: Características de la

página principal, es necesario ajustar en la vista el número de resultados a mostrar a 4 y

definir un criterio de orden en función de la fecha de realización del evento,

respectivamente.

4.22. Implementación del R-NFUN- 11: Visor de anuncios

Para que los anuncios se muestren en la página principal y cumplan el R-NFUN- 11:

Características de la página principal sobre el visor de eventos es necesario instalar el

módulo contribuido “Views Slideshow”. Este módulo complementa a “Views” añadiendo

una librería de jQuery que permiten crear vistas con efectos de transición, más

concretamente haciendo la librería Cycle que permite crear efectos de transición y

transiciones cíclicas como si fuese una aplicación en Flash.

La ventaja de usar el módulo contribuido “Views Slideshow”, es que se pueden asignar los

parámetros de configuración sin necesidad de saber cómo funciona realmente esta

librería. Por tanto, las especificaciones que se indican en este requisito no funcional se ven

satisfechas con la simple configuración de la vista para los anuncios.

En este caso concreto, los ajustes se harán de manera que el visor de anuncios muestre

una barra de control para avanzar, pausar y retroceder los anuncios, así como que indique

qué anuncio está mostrando del total disponible.

Este visor de anuncios presenta un problema de accesibilidad que va a quedar pendiente

de solucionar. Este problema está causado por cómo funciona el visor de anuncios. Por un

lado, el visor oculta todos los anuncios a mostrar menos el primero haciendo uso de

código PHP. Por ello, si se carece de JavaScript en el navegador o esta tecnología está

desactivada, también se verá sólo el primer anuncio. Por otro, la carga de la barra de

control y de los enlaces a cada anuncio se realiza por JavaScript, lo que quiere decir que

cuando se carece de la tecnología o ésta está desactivada, no aparecerá ninguna de las dos.

4.23. Implementación del R-FUN-1: Interfaz de usuario del gestor

Este requisito no funcional se ha tenido en cuenta para la selección del gestor de

contenidos de entre toda la oferta del mercado. Se buscaba un gestor de contenidos con

una interfaz orientada a formularios y cuyos diálogos para subir archivos fuesen más



usables. Era importante que la curva de aprendizaje del gestor no fuese muy pronunciada,

de manera que el personal que fuese a trabajar con él no sintiese un cambio radical en sus

métodos de trabajo.

Figura 53: El formulario de edición fecha y lugar de un evento

4.24. Implementación del R-NFUN-2: Integridad de la información

Para lograr este requisito no funcional, Drupal dispone de un módulo contribuido llamado

“Backup and Migrate” que añade a las tareas de Drupal que se integran en cron el respaldo

de toda la base de datos y de los archivos del sistema. Este módulo permite seleccionar

una a una, las tablas que se desean guardar, así como los directorios. Respecto a los

archivos de información, su respaldo está programado directamente sobre cron, de

manera semanal.

4.25. Implementación del R-NFUN-3: Mantenimiento del gestor

Nuevamente, este requisito no funcional se ha tenido en cuenta para la selección del gestor

de contenidos. De entre todos los gestores disponibles, se descartaron todos aquellos que

no informaban de actualizaciones de seguridad o de nuevas versiones de su código. Drupal

se puede configurar para que compruebe las actualizaciones tanto de los módulos que


4. SOLUCIÓN [169]

tiene instalados como del núcleo y para que avise al administrador del sitio cuando el

gestor esté pendiente de actualizar.

Las actualizaciones del servidor deben hacerse en modo desconectado para garantizar la

consistencia en las tablas de la base de datos y el buen funcionamiento del código. Para

ello, Drupal permite en a través de las páginas de administración desconectar el sitio y

configurar un mensaje de sitio desconectado de manera que se evita un error de acceso al

servidor. Las tareas de mantenimiento se pueden realizar a través de la interfaz de Drupal

y la actualización de archivos se hace a través de un servidor SFTP montado en el servidor

donde se encuentra alojado Drupal.

4.26. Implementación del R-NFUN-4: Mantenimiento del sitio

Este requisito no funcional garantiza la calidad de los contenidos del sitio web, así como la

usabilidad y accesibilidad global del mismo. En un sitio web cuyo contenido se actualiza

diariamente, es difícil no cometer fallos. Por ello, de manera periódica es recomendable

este tipo de prácticas. Los problemas detectados vía formulario web serán estudiados y

comprobados de inmediato, con el fin de solventarlos lo antes posible.

El departamento de informática responsable del sitio web de la Fundación realizará un

guión de actuación donde se recoja cuáles serán las acciones a realizar y la periodicidad de

las mismas para garantizar el buen funcionamiento del sitio. Algunas de estas acciones

serán evaluaciones periódicas de accesibilidad, evaluaciones de fallos reportados a través

de formularios de contacto, o revisiones sobre la calidad de los contenidos y de la

información introducida.

Sobre este último aspecto, se adelanta que cada departamento será el responsable de los

contenidos que se publiquen y supervisará los mismos antes de que salgan publicados.

4.27. Implementación del R-NFUN-5: Seguridad en el login

Es importante que el acceso al gestor sea seguro, de manera que se garantice la seguridad

y la integridad de la información publicada. Del mismo modo y con mayor importancia, es

imprescindible que esta seguridad también exista para el acceso del administrador, ya que

éste tiene privilegios sobre todo el sistema.

Para ello, todas las páginas de acceso al sistema se montarán sobre el protocolo seguro

HTTPS. Esto es posible siempre que se instale en el servidor el certificado concedido a la

Fundación por una entidad emisora y se configure en Apache los puertos sobre los que se

monta este protocolo. Además, es necesario instalar en Drupal el módulo contribuido

“Secure Pages”, que permite configurar sobre qué páginas se quiere activar el protocolo

seguro.



4.28. Implementación del R-NFUN-6: Detección de spam

Este requisito no funcional no ha provocado ninguna configuración especial en Drupal. Por

defecto, este gestor de contenidos no presenta herramientas de detección de spam. Sólo

hay que tener en consideración que, si algún día hiciese falta dicho tipo de herramientas,

existen varios módulos que implementan diferentes mecanismos de detección de spam

sobre formularios. Algunos de estos módulos son:

Mollom: herramienta que analiza la actividad del usuario para determinar si el

envío es spam o no. En caso de ambigüedad genera un CAPTCHA.

Text CAPTCHA: herramienta que implementa preguntas lógicas como

discriminante.

Image-based CAPTCHA: herramienta que combina las preguntas lógicas con

mosaicos de imágenes para que selecciones la correcta.

En caso de necesitar una herramienta de este tipo, sería necesario un estudio previo del

impacto que tendría ésta sobre la accesibilidad global del sitio web.

4.29. Implementación del R-NFUN-7: Accesibilidad de los

contenidos

Este requisito no funcional no ha requerido desarrollo específico para el atributo alt de

las imágenes o el atributo title de la imagen. Sin embargo sí que ha requerido un

desarrollo específico para el atributo longdesc, el cual se explicó en el apartado de la

Galería fotográfica del evento.

4.30. Implementación del R-NFUN-9: Reproductor de vídeo

Los contenidos multimedia siguen siendo los contenidos de Internet que más barreras de

accesibilidad presentan. Adaptar este tipo de contenidos para cubrir el mayor número de

personas independientemente de su diversidad funcional es realmente complicado y

requiere de la inversión de grandes cantidades de dinero por parte de las empresas que lo

pretenden. La adaptación de los contenidos se resume en proporcionar la misma

información a través de distintos medios sensoriales, de manera que cubra toda la

diversidad funcional y el contexto del medio. Por ejemplo, a un tipo de contenido

multimedia con vídeo y audio pregrabado sería necesario añadirle subtítulos,

audiodescripciones, y la posibilidad de verlo si no se dispone de la tecnología necesaria

ese momento.

Además, es necesario tener en cuenta que el uso de la interfaz que se está proporcionando

para poder ver el contenido. Este es el punto en el que se centra este requisito: el

reproductor. Los reproductores de vídeo requieren de una interfaz propia para su manejo,

como en todo este trabajo, dicha interfaz tiene que presentar el menor número de


4. SOLUCIÓN [171]

barreras de accesibilidad posibles, lo cual es bastante complicado teniendo en cuenta que

los reproductores web suelen depender de ciertas tecnologías para su funcionamiento.

Estas tecnologías no siempre están presentes y cuando lo están no siempre son

compatibles con las ayudas técnicas ni con los agentes de usuario.

Las interfaces propias de los reproductores o lo que se entiende por barras de control,

suelen estar implementadas con la tecnología Flash de Adobe. Hoy en día es más fácil

encontrar reproductores de vídeo que permitan la implementación de una barra de

control por JavaScript. En el caso de este proyecto, existen varios factores que hay que

tener en cuenta para poder seleccionar un reproductor, siendo el más importante la

integración con el gestor de contenidos. Como ya se comentó en la “Implementación de “,

el reproductor elegido por la integración con Drupal es JW FLV Player. Además, este

reproductor presenta varios módulos para la implementación de barras de control por

JavaScript e inserción de subtítulos.

Al instalar el reproductor en Drupal se detectaron varios problemas de compatibilidad

entre los módulos de accesibilidad que ofrecía el reproductor y Drupal. Por ello, se utilizó

una versión adaptada [WAC, 2011] del mismo con el módulo de accesibilidad ya

implementado. Esta adaptación del reproductor está basada en la versión 4.0 de este

reproductor con un módulo de accesibilidad adaptado, una barra de control implementada

en JavaScript con la libería Dojo Toolkit [Dojo, 2011] que hace uso de SWFObject [Google,

2011] para embeber el Flash y los iconos FamFamFam Silk Icons para la barra.

La elección de este reproductor se debe a que todavía son muchas las aplicaciones en

Flash que no pueden utilizarse sólo mediante teclado. Salvo en el caso del navegador

Internet Explorer instalado en Windows que no presenta problemas para llegar mediante

foco de teclado a las aplicaciones Flash y salir de ellas del mismo modo, el resto de

navegadores no permiten alcanzar estas aplicaciones si no es con el uso del ratón. Para los

usuarios que dependen de teclado para la interacción con páginas web o las personas que

encuentran problemas en el uso de ratón, esto es un gran impedimento.

Según la encuesta realizada a los usuarios de lectores de pantalla por el WebAIM

[WebAIM, 2009] más del 70% de los usuarios que utilizan lectores de pantalla encuentran

dificultades en el uso de Flash. Muchos lectores de pantalla tienen diferentes modos de

navegación para distintos tipos de elementos de las páginas web. Los usuarios de lectores

de pantalla como JAWS, NVDA y Window-Eyes estarán familiarizados con los diferentes

modos de interacción para navegar por páginas e introducir datos. Pero cuando el

contenido es una película en Flash, algunos lectores necesitan activar en modo de

transferencia pasiva “pass-through” para poderse mover a lo largo de la película. Pero

además, este modo debe ser desactivado para poder interpretar el código en Flash que se

va encontrando. Este hecho hace que los lectores de pantalla reaccionen de manera

impredecible ante cambios dinámicos del código Flash y el usuario no sepa por qué. Otros

lectores de pantalla como VoiceOver en Mac no pueden extraer información útil del



contenido de aplicaciones en Flash incluso aunque el foco se encuentre sobre controles de

Flash.

El reproductor de vídeo adaptado que se ha elegido intenta cubrir las limitaciones en el

acceso que presenta Flash, proporcionar una mejor interfaz propia y mejorar el contraste

y la legibilidad de los subtítulos con un área de visualización alternativa de mayor

contraste.

Este reproductor presenta muchas características de accesibilidad frente a otros

reproductores comunes. La interfaz propia desarrollada con Dojo Toolkit proporciona una

alta compatibilidad con el uso por teclado y los lectores de pantalla, además de incluir

implementación de WAI-ARIA [WAI, 2011] y soporte con el modo “Alto Contraste” de

Windows. En la implementación ARIA se ha hecho uso de landmarks, roles, y labels.

Además, la implementación del panel de subtítulos de alto contraste redimensiona el

tamaño de la letra cuando el reproductor modifica el tamaño de su ventana. Los subtítulos

y las audiodescripciones pueden activarse o desactivarse a través de la barra de

reproducción. Si no están disponibles sus botones se desactivan y si no hay subtítulos el

panel de subtitulado de alto contraste no se muestra.

Existen unas instrucciones de uso disponibles para los lectores de pantalla a las que se

puede llegar mediante navegación por tabulación o por encabezados. Los lectores de

pantalla que sean compatibles con ARIA, pasarán automáticamente a modo “Transferencia

pasiva”, activando el buffer virtual y desactivando el cursor virtual del PC. Los lectores de

pantalla que no sean compatibles, o que tengan ARIA desactivado tendrán que activar este

modo manualmente.

Además, este reproductor de vídeo utiliza un subconjunto limitado de atajos de teclado

para el control del reproductor. Estos atajos permiten reproducir/pausar, parar, silenciar,

expandir el panel de alto contraste y redimensionar el reproductor.

Para que el módulo SWFTools cargue esta versión del reproductor se ha tenido que

modificar la función swftools_wijering4_swftools_preprocess_jwplayer4 del

módulo que llama al reproductor para construir su instancia, que posteriormente se

embeberá en el código HTML. Esta función se encuentra en el fichero

swtools_wijering4.module.

El fragmento de Código 25 muestra el script necesario para llamar al reproductor. Este

script no puede modificarse para que la llamada se pueda realizar.

<script type="text/javascript">

//Player configuration

var jwpc_videoheight = "320"; //Alto del video

var jwpc_videowidth = "420"; //Ancho del video


4. SOLUCIÓN [173]

// Accessibility related variables. Path can be relative or absolute

var jwpc_captionfile = "/media/captions.xml";

var jwpc_audiodescfile = "/media/desc";

var jwpc_advolume = "75"; // percent volume of audio description

//size in pixels of caption font within player screen

var jwpc_ccfontsize = "16"; // Path must be relative to player.html file

var jwpc_accessibilityplugin = "mediaplayer4/flashplayer/accessibility.swf";

// Video file can be a path relative to the player or a fully qualified URL

// Other variable paths can be relative to the HTML file or absolute.

var jwpc_videofile = "/media/video_file.flv";

var jwpc_previewimage = "/media/preview.jpg";

var jwpcplayer = "mediaplayer4/flashplayer/player.swf";

// setting true will show control bar in Flash movie and disables screen click

// for fullscreen

var jwpc_showflashcontrolbar = true;

var jwpc_token = null // see readme for notes on streaming security

var jwpc_skin = "mediaplayer4/flashplayer/stijl/stijl.swf";

var objplayer = null;

</script>

Código 25: Fragmento de código que sustituye la llamada del reproductor

Además del script para la carga del reproductor, éste necesita de una estructura especial

de HTML para que el JavaScript que lo genera pueda insertar correctamente cada parte del

reproductor. En el fragmento de Código 26 se muestra la estructura de HTML que se

necesita, las líneas precedidas por – son eliminadas y las precedidas por ++ son añadidas.

El resto son las líneas originales.



// AQUÍ VA EL SCRIPT DEL Código 25

<div class="tundra" id="jwpc_playercontainer" style="visibility:hidden">

<h4 class="jwpc_semantic" id="jwpc_toolbarheading">Begin Video Toolbar</h4>

-- <div id="jwpc_playertoolbar"></div>

<div id="jwpc_timer"><span id="jwpc_timerlabel"> </span></div>

<div id="jwpc_captionarea"></div>

<div id="jwpc_playerwrapper">

<div id="jwpc_playerplaceholder">

You will need <a href="http://www.macromedia.com/go/getflashplayer">

the Flash Player</a> to see this video.</div>

</div>

++ <div id="jwpc_playertoolbar"></div>



</div>

Código 26: Estructura del HTML para la inserción del reproductor

Este código se ha insertado renombrando la función theme_swftools_embed que es la

que realmente construye el elemento HTML embed. Esta función además, será la

encargada de crear una única instancia del reproductor aunque exista más de un vídeo por

“Evento”.

Respecto de la versión adaptada se han modificado los siguientes elementos.

Instrucciones de uso del reproductor: en la versión original las instrucciones

estaban ocultas por CSS, pero accesibles por teclado y por lectores de pantalla. En

la modificación se han sustituido por un enlace a la “Guía de navegación” donde se

pueden leer.

Barra por teclado: en la versión original, (Figura 54) la barra de reproducción se

mostraba encima del reproductor. Se ha modificado para que aparezca un enlace

que indica “Mostrar barra de reproducción por teclado” bajo el reproductor

(Figura 54).

Visibilidad de la barra por teclado: en la versión original la barra se mostraba

siempre, debido a que se había eliminado cualquier otra forma de controlar el

reproductor. En la modificación, se ha ocultado esta barra por teclado mediante

JavaScript ya que el reproductor presenta su barra de control por Flash. Esta barra

sólo se muestra cuando lo pide el usuario mediante la activación del enlace

descrito anteriormente.

Botones de la barra por teclado: en la versión original los controles de la barra

presentan otro aspecto. En la modificación, el aspecto se ha adaptado al diseño del

sitio web.

Tema del reproductor: en la versión original el reproductor presenta un tema sin

barra de control Flash. En la modificación se ha cambiado el tema que utiliza el

reproductor por uno que muestra una barra de reproducción completa.

Figura 54: Versión original del reproductor adaptado Figura 55: Versión del reproductor del sitio web


4. SOLUCIÓN [175]

Con este reproductor se está cumpliendo prácticamente la totalidad de las restricciones

del requisito: el funcionamiento mediante teclado, evitar la trampa de teclado y la

capacidad para contener subtítulos y audio-descripciones. Pero, y ¿la alternativa para

continuar accediendo al contenido? En este caso la solución no la proporciona el

reproductor, sino Drupal. La lista de reproducción que genera el módulo “XSPF” permite la

descarga de los vídeos para poder verlos en el equipo sin depender del navegador y la

tecnología del que éste disponga. Además, cuando se carece de la tecnología necesaria

para la carga del reproductor, se informa al usuario de este hecho.

4.31. Implementación del R-NFUN- 12: Longitud de la página

Es importante que el tamaño de la página no sea demasiado largo. Teniendo en cuenta que

los tamaños de las pantallas hoy en día, por contradictorio que parezca son más pequeñas

debido al uso de dispositivos móviles para navegar por internet, es necesario que la

longitud de la página se pueda controlar para que el scroll no sea tan largo que resulte

incómodo para su manejo.

Una restricción sobre el diseño global de un evento es controlar la longitud que puede

llegar a tener éste. Con la cantidad de campos que se quieren almacenar en un evento y la

cantidad de valores que puede tomar cada campo, se controlará la longitud de la página

para un evento completo mediante una técnica de scripting que permita expandir y

contraer los bloques informativos del evento.

Para ello, el script utilizado en el evento para contraer y expandir los bloques de

información de éste. La forma en la que está implementada este script se comentará en el

siguiente apartado (Implementación del R-NFUN- 13: Scripts accesibles), donde se

describe que este script no es intrusivo y permitir acceder siempre a la información,

independientemente de si se tiene JavaScript o no.

En el caso del evento, existen los enlaces de volver arriba debido a que este contenido

puede llegar a tener gran cantidad de información y el último bloque puede llegar a estar

bastante abajo si se expande todo el contenido. La idea es que un usuario con JavaScript

que pueda mostrar y ocultar los bloques que le interesen no necesite de estos enlaces,

pero cualquier otro usuario que carezca de esta tecnología sí le sea una ayuda para la

navegación. En la Figura 56 se muestra uno de los enlaces para volver arriba tras un

bloque de contenido del evento.

Otro caso en el que la longitud de la página puede ser molesta para el usuario, es en las

páginas de los elementos de menú. El contenido de este tipo de páginas no suele ser muy

extenso, pero las listas de eventos actuales, futuros y pasados pueden hacer que la página

crezca demasiado dejando mucho espacio en blanco. La manera de evitar esto es mediante

un script que contrae y expande dichas listas contenidas en la barra lateral. Como ya se ha

comentado sobre este script, no es intrusivo.



Figura 56: Enlace volver arriba tras la presentación del evento


4. SOLUCIÓN [177]

4.32. Implementación del R-NFUN- 13: Scripts accesibles

Para que se cumpla este requisito no funcional se ha tenido en cuenta una serie de técnicas

suficientes sobre scripting para lograr cumplir las pautas de accesibilidad sobre

contenidos web, técnicas que definidas en el documento de técnicas suficientes para

cumplir las WCAG 2.0.

Todos los scripts implementados en el sitio web cumplen las técnicas que comentan a

continuación, pero además todos permiten acceder al contenido aunque se carezca de la

tecnología o ésta esté desactivada en el navegador. Para lograr esto, los script se han

creado de manera que lo primero que hagan sea crear el elemento sobre el que cargar el

evento. Es decir, si se navegase sin JavaScript en un evento los títulos de los bloques de

información de éste no serían enlaces con un signo más o menos dependiendo del estado

del bloque, sino que se vería el título en color gris –lo que indica que no es un elemento

activo- acompañado de una imagen sin signo como lo que se muestra en la Figura 57.

Además, la información de cada bloque está presente, es decir el bloque está expandido.

Del mismo modo pasa con el bloque de eventos de la barra lateral. Los signos que

acompañan los títulos de cada lista desaparecen, cada título deja de ser un enlace y las tres

listas están expandidas. El caso de la galería de imágenes y de la galería de vídeos es

diferente.

Figura 57: Título de un bloque de información de un evento sin JavaScript

La galería fotográfica carga las imágenes como muestra la Figura 58. Esta carga es la que

se realiza cuando no hay JavaScript. Las imágenes por defecto son enlaces que apuntan a

una página con la foto cargada a tamaño real y la información de la misma. En esta página

se mostrarán todas las fotos de esa galería también en miniatura pero no se necesitará

JavaScript para poder ver todas esas imágenes en tamaño real.

Es el script el que agrupa las imágenes de seis en seis y carga los eventos para los

elementos de paginación.



Figura 58: Bloque de galería fotográfica de un evento sin JavaScript

Respecto a los vídeos, es de imaginar que el reproductor no va a funcionar debido a que

éste depende de JavaScript para su carga y su funcionamiento. El motivo de esto se debe al

uso de la biblioteca SWFObject que mejora la accesibilidad y la indexación de los vídeos en

Flash –según el centro de desarrollo de Adobe Flash Player [Adobe, 2008] -. SWFObject 2

utiliza JavaScript para resolver problemas que no se pueden solventar con etiquetas:

Detecta la versión de Flash Player para evitar que versiones antiguas del plugin

estropeen el contenido Flash y determinar si el contenido alternativo se debe

mostrar o no.

Ofrece funcionalidad para volver al contenido alternativo en caso de que la versión

del plugin no esté actualizada manipulando el DOM (Nota: Si el plugin de Flash no

está instalado, muestra automáticamente el contenido HTML del objeto HTML

anidado).

Ofrece la opción de utilizar la Instalación Express de Adobe para descargar la

última versión del Flash Player.

Resuelve el problema producido por algunos navegadores basados en versiones

anteriores del motor Webkits que ignoraban los elementos "param" anidados

dentro del elemento "embed" usando el elemento "embed" original (Nota: este es el

único lugar en el que se utiliza una etiqueta registrada y será descartado en el

futuro).

Ofrece la posibilidad de publicar contenido Flash con Javascript y en consecuencia

evitar posibles mecanismos que requieran "click para activar".

Ofrece una elaborada API Javascript que permite realizar tareas comunes con el

Flash Player y el contenido Flash.


4. SOLUCIÓN [179]

En el caso concreto de este sitio web el reproductor tendrá más de un vídeo por evento,

por tanto crear un alternativo único para todos los vídeos es más complicado. La solución

será proporcionar la descarga del vídeo a través de la lista de reproducción que aparece al

lado del reproductor. De esta manera, cualquier usuario puede ver el vídeo en su equipo.

En la Figura 59 se muestra el alternativo que aparece cuando la tecnología no está

disponible. Desde los enlaces de la lista de reproducción se pueden descargar los vídeos.

Figura 59: Alternativo del reproductor de vídeo

Por último el script que controla el menú de navegación del sitio web permite el uso de

tabulación para recorrer el menú y que se desplieguen los submenús correspondientes.

Sin el script el menú se puede recorrer con tabulación pero no se despliegan los submenús,

por tanto hay un problema para llegar a esta información cuando se carece de la

tecnología o ésta no está disponible. Para solventar este problema y que siempre se

puedan ver los enlaces de submenú de cada elemento primario del menú se han creado

unas páginas intermedias que contienen los enlaces de submenú para cada caso. Es decir,

que los enlaces de primer nivel del menú enlazan a páginas físicas que contienen sus

enlaces del submenú.

Estas páginas se han creado en Drupal como vistas de página que contienen bloques.

Existirá una vista de bloque por cada enlace de segundo nivel que mostrará los cinco

últimos nodos publicados asociados a ese término. En la Figura 60 se puede ver un

ejemplo de las páginas de menú.

Para la vista de página no se ha tenido que redefinir ningún archivo de plantilla del

módulo “Views”, pero para las vistas de bloque de cada enlace de nivel dos sí ha sido



necesario para convertirlo en una lista HTML –por motivos de creación de la vista no ha

sido posible aplicarle el estilo de lista HTML-. Los archivos de plantilla redefinidos son:

views-view-limit-grouping.tpl.php (Código 27) y views-view-fields.tpl.php

(Código 28). En el primer archivo se crea la lista y en el segundo cada elemento de la lista

que serán los cinco últimos nodos publicados en el sitio asociados a ese término. Ambos

códigos no tienen nada en común con los ficheros originales.

<?php if (!empty($title)): ?>

<?php print t($title); ?>

<?php endif; ?>

<ul>

<?php foreach ($rows as $id => $row): ?>

<?php print $row; ?>


</ul>

Código 27: renombrada la salida de la vista para crear una lista

<?php foreach ($fields as $id => $field): ?>

<li><?php print $field->content; ?></li>


Código 28: renombrada la salida de cada elemento para crear una lista

Por otro lado, es necesario que el título de cada bloque tenga un encabezado de nivel 2 –h2

en HTML- y que tenga ciertas clases de CSS para heredar el estilo mostrado en la Figura

60. Para ello, se ha redefinido para cada bloque el archivo de plantilla block.tpl.php. El

contenido de este archivo es la llamada a una función interna de nombre

theme_menu_page_block que crea el encabezado del bloque con el título y el icono en

función del título de este –cada bloque tiene su icono nombrado según el título de éste-,

añade las capas y las clases necesarias para que los bloques se muestren en dos columnas

y enlaza los títulos con las páginas a las que se llegaría a través de los elementos de

segundo nivel del menú.


4. SOLUCIÓN [181]

Figura 60: Página de un enlace de menú de primer nivel

Para que estas páginas sean del todo correctas, el orden en el que aparecen los bloques

tiene que corresponderse con el orden del submenú. Para ello, basta con ordenar la

visibilidad de cada bloque en la página de administración de bloques de Drupal. Donde

además, se indicará que cada bloque de este tipo sólo se mostrará en la página del

vocabulario al que pertenezcan.

Existen varias técnicas propuestas por el W3C para lograr la accesibilidad haciendo uso de

scripts. En la evaluación se deberán tener en cuenta todas aquellas aplicables al sitio.

comentan aquellas que pueden ser aplicables a este sitio y deben tenerse en cuenta en la

implementación de los mismos.

4.33. Implementación del R-NFUN- 14: Enlaces en el sitio web

Este requisito no funcional quizás abarque más aspectos de usabilidad que accesibilidad,

como la identificación de los enlaces como estándar interno al sitio web. Pero también

existen aspectos de accesibilidad que afectan a este requisito como el propósito de los

enlaces o la identificación de la página de destino.

En este requisito se han indicado varios puntos que hay que tener en cuenta para los

enlaces del sitio web:

Identificación del enlace



Nombrado del enlace

Destino del enlace

Propósito del enlace

4.33.1. Identificación del enlace

En el diseño del sitio web se ha tenido en cuenta que la representación de los enlaces sea

siempre igual, de manera que un usuario pueda reconocer de forma inequívoca sobre qué

elementos puede hacer clic y sobre cuáles no. Los enlaces se representan en color morado

y con el texto resaltado en negrita como se muestra en la Figura 61. Cuando un enlace

recibe el foco éste cambia su color a naranja manteniendo el resaltado de la fuente en

negrita como muestra la Figura 62.

Figura 61: Identificación de enlaces en el sitio web

Figura 62: Identificación del enlace con foco

Figura 63: Enlaces que colapsan o contraen contenido

Además, cuando los enlaces permitan realizar acciones fuera de la acción por defecto –

cargar una nueva página-, van acompañados de imágenes que representan la nueva acción

e informan al usuario de la misma. En la Figura 63 se puede ver el caso de dos tipos de

enlaces. El primero de ellos, “Cómo llegar”, va acompañado de una imagen cuadrada con

un signo menos. Si se pudiese ver la información alternativa de esta imagen mostraría el

texto “Contraer”. El segundo de los enlaces, “Galería fotográfica”, va acompañado de una

imagen cuadrada a modo de botón con un signo más. Nuevamente si se pudiese ver la

información alternativa de la misma, el texto sería “Expandir”.


4. SOLUCIÓN [183]

4.33.2. Nombrado y destino del enlace

Los enlaces suelen presentar problemas con el título del mismo. El texto del enlace debería

ser consistente con el título de la página a la que se llega a través de él. En caso de ser una

referencia interna dentro de una página, el texto del enlace debería ser el título de la

sección a la que se llega. Esto hace que el usuario no se desoriente y siempre sepa dónde

está, de esta manera se puede centrar en la información y no en la navegación.

La mayor parte de los enlaces generados en la página web serán generados por plantillas y

vistas a través de Drupal. Esto garantizará que los textos utilizados para generar los

enlaces coincidan con los títulos de los nodos a los que se enlaza. Pero los enlaces que se

inserten como referencias dentro de los contenidos de los nodos del sitio web, requerirán

una revisión periódica para garantizar este hecho.

El que el nombrado de los enlaces no coincida con el título del sitio al que se enlaza, puede

verse solventado si el propósito daba indicios de a dónde se iba a llegar. Pero, el hecho de

encontrar enlaces repetidos que enlazan a distintos sitios también desorienta al usuario,

porque puede que éste nunca sabe qué enlace activar para llegar donde quiere. Por tanto,

es un hecho que se ha evitado en el diseño del sitio.

La presentación de enlaces consecutivos que llevan al mismo sitio tiene más que ver con la

accesibilidad, que con la usabilidad. Este hecho también se ha evitado en el diseño del sitio

web.

Por último, se han revisado los enlaces generados dentro del contenido de los nodos para

que los destinos siempre sean válidos –no sean enlaces rotos-. Los enlaces rotos

convierten la experiencia de navegación del usuario en un hecho frustrante.

4.33.3. Propósito de los enlaces

Realmente, tanto el destino de los enlaces, como su propósito y su nombrado están

íntimamente relacionados. En principio, el propósito de un enlace que realiza la acción por

defecto está marcado por el texto del enlace y el destino al que enlaza. En otros casos, será

necesario analizar el contexto en el que se encuentra para conocerlo. Hay que tener en

cuenta, que el contexto visual de un enlace no se suele corresponder con su contexto de

lectura del HTML.

En el diseño del sitio web se han evitado los enlaces del tipo: “leer más”, “ver más”, “seguir

leyendo”, etc. Estos enlaces, fuera de contexto –tanto visual, como de lectura- no tienen un

propósito claro y por ello siempre deben llevar más información que ayude al usuario a

conocerlo. Es más fácil para todos que los enlaces sean autosuficientes en cuanto a su

propósito que pretenden se refiere. Por otro lado, sí que es cierto que un requisito de

accesibilidad de las WCAG 2.0 acepta que el propósito de un enlace dependa de su

contexto de lectura, pero la implementación de este tipo de contextos no siempre es fácil.

Por todo ello, no se generarán este tipo de enlaces.



Todos los enlaces del sitio web tendrán un texto, y en caso necesario, un title y una imagen

que complementen su información. De manera, que independientemente del contexto se

sepa el propósito del mismo.

4.34. Implementación del R-NFUN- 15: Mapa web

El mapa web del sitio se presenta como una lista, siguiendo la estructura del menú. Esta

página es un nodo de Drupal de tipo “Página”, cuyo contenido es dicha lista. Para que esta

página esté presente en todas las páginas del sitio web, al igual que el “Contacto”, la “Guía

de navegación” o la conformidad sobre “Accesibilidad”, se ha creado un bloque de menú de

navegación secundario que se ha incluido en la región del pie del sitio. Este menú de

navegación se ha creado a través de las páginas de administración de menús de Drupal. Lo

que diferencia a este menú del menú principal de navegación del sitio es que no depende

de ninguna taxonomía. Los enlaces de este bloque de menú se han creado de manera

manual y se han agrupado en un bloque de navegación por sus características comunes:

son páginas de asistencia a la navegación para el usuario y el feedback entre el usuario y la

empresa. En la Figura 64 se muestra el mapa web del sitio web.

Figura 64: Fragmento del mapa web

Esta decisión se tomó porque no se quería una tabla de contenidos sino un mapa del sitio

lo más simple posible. Por otro lado, los módulos que se han encontrado de Drupal no se

adecuaban a lo que se necesitaba y no se espera que la navegación cambie.

Es importante tener en cuenta que el mapa web debe ser un fiel reflejo de la navegación

del sitio web. En caso de que la navegación cambiase o se ampliase, el mapa web debería

adaptarse con los nuevos cambios. No basta con que exista un mapa web, éste debe ser

correcto.


4. SOLUCIÓN [185]

4.35. Implementación del R-NFUN- 16: Guía de navegación

La “Guía de navegación” se ha creado de la misma manera que el “Mapa web”. Es un nodo

de tipo “Página” que se ha incluido en el menú de navegación secundario del pie. El

contenido de este nodo es el recogido en el este requisito no funcional. En la Figura 65 se

puede ver un fragmento de la página. Como ya se comentó en la solución del requisito no

funcional sobre el reproductor de vídeo, éste contiene un enlace a las instrucciones del

mismo contenidas en esta guía de navegación.

Figura 65: Fragmento de la guía de navegación

Al igual que el mapa web, esta página también deberá actualizarse ante cualquier cambio

que sufra la estructura principal del sitio web, así como el funcionamiento de algunas de

sus secciones.

4.36. Implementación del R-NFUN- 17: Independencia del

dispositivo

Este requisito no funcional está relacionado con la accesibilidad de la página web, que será

evaluada en la Implementación del R-NFUN-20: Accesibilidad global. Para lograr que el

diseño cumpla con estas restricciones ha sido necesario evitar el uso de imágenes únicas

para presentar los bloques de información, que el tamaño de la fuente se defina en em y

que no se definan anchos ni alturas máximas y en caso de ser imprescindible que se haga

en em.



En la Figura 66 se puede ver cómo en la vista de teaser de una noticia el contenido se

adapta dentro de la imagen que rodea al contenido cuando la ventana se estrecha. Esto

sólo es posible si la imagen está fragmentada en trozos y mostrada como imagen de fondo

en distintas capas que engloban al contenido.

Figura 66: Teaser de una noticia estrechado por el ancho de la ventana

En la Figura 67 se puede ver un esquema de los fragmentos que conforman el efecto de

bloque. Son cuatro imágenes que pintan las cuatro esquinas redondeadas y los límites

superior e inferior. Además, las imágenes inferiores añaden una sombra a modo de relieve

y un degradado suave en escala de grises para completar el efecto de relieve.

El contenido tiene un ancho máximo y no se expandirá más de este ancho, por tanto el

montaje de las imágenes debe cubrir ese ancho máximo. Además, es importante el orden

en el que estas imágenes se insertan dentro de las capas del HTML, ya que al permitir

encoger el contenido éstas no debe solaparse. Por ello, teniendo en cuenta que las capas

más externas se pintan sobre las internas, las imágenes que deben ir en las capas externas

son las esquinas del lado derecho, y las imágenes del lado izquierdo deberán ir en capas

más internas.


4. SOLUCIÓN [187]

Toda la maquetación del sitio web está implementada teniendo en cuenta estas

restricciones de manera que cualquier bloque que se vea está creado siguiendo esta

filosofía de composición de imágenes para lograr el efecto de bloque único.

<div class="node views-row views-row-1 views-row-odd views-row-first">

<div class="title">


<a href="ruta/actividad ">

<img alt="" src="cartel.jpg" />

Génesis y evolución del estado en España

</a>

</h2>

</div>

<div class="wrapper-content view-taxonomy">


<div class="views-field-field-date-value">

<p class="field-content">07/09/2011 > 09/09/2011</p>

</div>

<p>Lorem ipsum dolor sit amet.</p>

</div> 

</div> 

</div>

Código 29: Estructura del HTML para insertar las imágenes de fondo

En el Código 29 se marca la estructura HTML necesaria para poder insertar las cuatro

partes que forman todo el bloque. La capa node contiene la esquina inferior izquierda, la

capa title tiene la esquina superior derecha, el encabezado h2 tiene la esquina superior

izquierda y la capa wrapper-content tiene la esquina inferior derecha.

Figura 67: Esquema de las imágenes que engloban la información

4.37. Implementación del R-NFUN- 18: Estándares

En Drupal, el DTD se define en el archivo de plantilla page.tpl.php. Esta plantilla se tuvo

que modificar para lograr la estructura deseada en el sitio web y que de esta forma todas



las páginas en el sitio tengan el mismo estilo deseado. El código de XHTML generado está

basado en el DTD XHTML 1.1 Transitional y es correcto, de esta forma se pueden usar los

elementos <iframe> para insertar de los mapas de Google Maps.

Por otro lado, el CSS se ha tenido que adaptar a la versión CSS 3.0 debido a la gran

cantidad de éste que se ha heredado de módulos contribuidos de Drupal y la dificultad en

su corrección. En algunos casos, la corrección del CSS implicaba cambiar la forma en la que

se colocaban ciertas capas en HTML para seguir logrando el mismo efecto. Realmente, no

es la versión más compatible con los navegadores actuales, pero no se ha podido dar otra

solución mejor.

4.38. Implementación del R-NFUN-20: Accesibilidad global

La accesibilidad se ha considerado desde la captura de requisitos y se ha intentado

arrastrarla hasta la implementación, pese a ello el sitio web no está exento de tener

errores de accesibilidad. Por ello, tras este primer ciclo de desarrollo se ha realizado una

evaluación al sitio para comprobar si existen errores. Todos los errores que se detecten se

deberán corregir para poder iniciar cualquier otro ciclo de desarrollo sobre este sitio web

para no arrastrar errores.

4.38.1. Resultados de la evaluación de las WCAG 2.0

En el anexo B de este documento se puede encontrar la evaluación realizada a algunas de

las páginas del nuevo sitio web. Estas páginas se han seleccionado teniendo en cuenta el

modo de funcionamiento por plantillas de Drupal.

Estos tres elementos se repetirán a lo largo de determinadas páginas, y por tanto su

ubicación dentro del conjunto de una página y su forma de insertarse siempre será la

misma. De esto se podría concluir que para realizar una evaluación de accesibilidad de las

páginas de contenido generadas por Drupal habría que evaluar cada plantilla, bloque o

vista. Pero esto no sería del todo correcto. Hay que tener en cuenta que el usuario no verá

cada elemento por separado sino dentro de un conjunto que conformará una página

completa. Por ello, se debe evaluar páginas completas y no elementos independientes de

contenido.

Sí que es cierto por tanto, que muchas páginas serán iguales en cuanto a su estructura del

HTML y su maquetación en CSS, aunque el contenido en sí difiera. De aquí que no se

evalúen todas las páginas del sitio web, sino sólo aquellas que muestran todas las distintas

estructuras y maquetaciones. De hecho, entre las páginas elegidas para la evaluación ya se

repiten elementos como el menú de navegación, el buscador, el bloque de eventos del que

se habló en la “Implementación de R-NFUN-10: Características de la página principal” o los

enlaces destacados.

Las páginas que se evaluarán serán las 9 que se listan a continuación:


4. SOLUCIÓN [189]

Inicio

Mapa web

Contacto

Accesibilidad

Guía de navegación

Página de menú de primer nivel (Fundación)

Página de menú de primer nivel (Sala de prensa)

Página de menú de primer nivel (Exposiciones)

Página de un evento completo

BIEN MAL N/A

Nivel A 15 7 3

Nivel AA 5 5 3

Nivel AAA 8 9 6

Tabla 19: Resumen de la evaluación de las WCAG 2.0

En la Tabla 19 se muestra el resumen global de los resultados de la evaluación de las

WCAG 2.0 para las 9 páginas tomadas como muestra del sitio web. En la

Inicio Mapa web

Contacto Accesibili

dad Guía de

navegación Fundación

Sala de prensa

Exposiciones

Evento

1.1.1 Non-text Content

F F F F F F F F F

1.2.1 Audio-only and Video-only (Prerecorded)

N N N N N N N N N

1.2.2 Captions (Prerecorded)

N N N N N N N N F

1.2.3 Audio Description or Media Alternative (Prerecorded)

N N N N N N N N F

1.2.4 Captions (Live)

N N N N N N N N N

1.2.5 Audio Description (Prerecorded)

N N N N N N N N N

1.2.6 Sign Language (Prerecorded)

N N N N N N N N F

1.2.7 Extended Audio Description (Prerecorded)

N N N N N N N N N

1.2.8 Media Alternative (Prerecorded)

N N N N N N N N F



Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento

1.2.9 Audio-only (Live)

N N N N N N N N N

1.3.1 Info and Relationships

V V V V V V F V F

1.3.2 Meaningful Sequence

V V V V V V V V V

1.3.3 Sensory Characteristics

N N V V N N N N N

1.4.1 Use of Color

V V V V V V V V V

1.4.2 Audio Control

N N N N N N N N N

1.4.3 Contrast (Minimum)

F F F F F F F F F

1.4.4 Resize text F V V V V V V V V

1.4.5 Images of Text

V V V V V V V V V

1.4.6 Contrast (Enhanced)

F F F F F F F F F

1.4.7 Low or No Background Audio

N N N N N N N N N

1.4.8 Visual Presentation

F V V V V V V V V

1.4.9 Images of Text (No Exception)

V V V V V V V V V

2.1.1 Keyboard F F F F F F F F F

2.1.2 No Keyboard Trap

V V V V V V V V V

2.1.3 Keyboard (No Exception)

F F F F F F F F F

2.2.1 Timing Adjustable

V N N N N N N N N

2.2.2 Pause, Stop, Hide

V N N N N N N N N

2.2.3 No Timing F V V V V V V V V

2.2.4 Interruptions

V N N N N N N N N

2.2.5 Re-authenticating

V V V V V V V V V

2.3.1 Three Flashes or Below Threshold

V V V V V V V V V

2.3.2 Three Flashes

V V V V V V V V V

2.4.1 Bypass Blocks

V V V V V V V V V

2.4.2 Page Titled

V V V V V V V V V

2.4.3 Focus V V V V V V V V V


4. SOLUCIÓN [191]

Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento

Order

2.4.4 Link Purpose (In Context)

V V V V V V V V F

2.4.5 Multiple Ways

V V V V V V V V V

2.4.6 Headings and Labels

V V V V V V V V V

2.4.7 Focus Visible

V V V V V V V V F

2.4.8 Location V V V V V V V V V

2.4.9 Link Purpose (Link Only)

V V V V V V V V F

2.4.10 Section Headings

V V V V V V V V V

3.1.1 Language of Page

V V V V V V V V V

3.1.2 Language of Parts

V V V V V V V V F

3.1.3 Unusual Words

N N N N N N N N N

3.1.4 Abbreviations

N N N N N N N N N

3.1.5 Reading Level

V V V V V V V V V

3.1.6 Pronunciation

N N N N N N N N N

3.2.1 On Focus V V V V V V V V V

3.2.2 On Input V V V V V V V V V

3.2.3 Consistent Navigation

V V V V V V V V V

3.2.4 Consistent Identification

V V V V V V V F V

3.2.5 Change on Request

F V V V V V V F F

3.3.1 Error Identification

N N V V N N N N N

3.3.2 Labels or Instructions

V V V V V V V V V

3.3.3 Error Suggestion

N N V V N N N N N

3.3.4 Error Prevention (Legal, Financial, Data)

N N N N N N N N N

3.3.5 Help V V V V V V V V V

3.3.6 Error Prevention (All)

F F F F F F F F F

4.1.1 Parsing V V V V V V V V V



Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento

4.1.2 Name, Role, Value

V V V V V V V V F

Conformance 1 F F F F F F F F F


Conformance 3 N N N N N N N N N

Conformance 4 F V V V V V V V F

Conformance 5 V V V V V V V V V

Tabla 20 se recogen los resultados individuales de cada página. Los criterios de

conformidad se muestran por fila y las páginas por columnas, el valor de cada casilla será

V si el criterio se cumple, F si el criterio falla y N si no es aplicable para esa página, con un

código de color redundante (verde para V, rojo para F y amarillo para N).

Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento


F F F F F F F F F

1.2.1 Audio-only and Video-only (Prerecorded)

N N N N N N N N N


N N N N N N N N F


N N N N N N N N F


N N N N N N N N N


N N N N N N N N N


N N N N N N N N F


N N N N N N N N N


N N N N N N N N F


N N N N N N N N N


V V V V V V F V F


V V V V V V V V V


N N V V N N N N N

1.4.1 Use of V V V V V V V V V


4. SOLUCIÓN [193]

Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento

Color

1.4.2 Audio Control

N N N N N N N N N


F F F F F F F F F

1.4.4 Resize text F V V V V V V V V


V V V V V V V V V


F F F F F F F F F


N N N N N N N N N


F V V V V V V V V


V V V V V V V V V

2.1.1 Keyboard F F F F F F F F F


V V V V V V V V V


F F F F F F F F F


V N N N N N N N N


V N N N N N N N N


2.2.4 Interruptions

V N N N N N N N N


V V V V V V V V V


V V V V V V V V V

2.3.2 Three Flashes

V V V V V V V V V

2.4.1 Bypass Blocks

V V V V V V V V V

2.4.2 Page Titled

V V V V V V V V V

2.4.3 Focus Order

V V V V V V V V V


V V V V V V V V F

2.4.5 Multiple Ways

V V V V V V V V V


V V V V V V V V V

2.4.7 Focus Visible

V V V V V V V V F



Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento



V V V V V V V V F


V V V V V V V V V


V V V V V V V V V


V V V V V V V V F

3.1.3 Unusual Words

N N N N N N N N N

3.1.4 Abbreviations

N N N N N N N N N

3.1.5 Reading Level

V V V V V V V V V

3.1.6 Pronunciation

N N N N N N N N N




V V V V V V V V V


V V V V V V V F V


F V V V V V V F F


N N V V N N N N N


V V V V V V V V V


N N V V N N N N N


N N N N N N N N N



F F F F F F F F F



V V V V V V V V F




Conformance 4 F V V V V V V V F


Tabla 20: Resultados de la evaluación de accesibilidad para las WCAG 2.0


4. SOLUCIÓN [195]

Criterio de conformidad 1.1.1

Este criterio trata sobre los alternativos de los contenidos no textuales y falla para todas

las páginas evaluadas. Existe un fallo común a todas las páginas en la imagen del botón del

buscador. Este botón, está construido como un type=image y por tanto, necesita de un

alternativo que describa su propósito. Este fallo se contempla en el documento de las

técnicas para las WCAG 2.0 como el F65 y se recoge como técnica suficiente para cumplirlo

en la H36. Su correcta implementación, que se propone en esta técnica se muestra en el

fragmento de Código 30 que se encuentra en la función de preprocesamiento del bloque de

búsqueda en el archivo template.php.

<input type="image" title="Buscar" alt="Buscar"

src="/sites/default/themes/fpi/style/images/btn_buscar.gif"

class="form-submit" id="edit-submit" value="Buscar" name="op" />

Código 30: Corrección del fallo F65

Las páginas de inicio, mapa web, contacto, accesibilidad, guía de navegación y fundación

no presentan más fallos en este criterio, pero en el resto de páginas sí que se dan otros

fallos.

En la página de la sección de menú sala de prensa entre sus contenidos se

muestra un listado de las últimas galerías fotográficas actualizadas en el

sitio web. Este listado presenta un subconjunto de las imágenes que se pueden

ver en la galería, concretamente cuatro imágenes. Este grupo debería tener un

alternativo para el grupo según presenta la técnica G196 -fragmento de

Código 31- y su corrección sería la que se muestra en el siguiente fragmento de código.

Este fallo es el mismo que el anterior – F65-, aunque su corrección sea diferente.

<div>

<span>

<img alt="Cuantro de las fotografías que se pueden ver en esta galería"

src="/ruta/foto1.jpg" />

</span>

<span><img alt="" src="/ruta/foto2.jpg" /></span>

<span><img alt="" src="ruta/foto3.jpg" /></span>

<span><img alt="" src="ruta/foto4.jpg" /></span>

</div>

Código 31: Alternativo para un grupo de imágenes

En la página de exposiciones donde se muestran listadas todas las exposiciones con un

paginador, cada enlace a una exposición está formado por un texto –que coincide con el

título de la exposición- y una imagen. Los alternativos de estas imágenes describen la

imagen, cuando deberían contener un alternativo vacío porque el propósito del enlace

queda claro con su texto. Este fallo está contemplado en el documento de técnicas en el

fallo F39. La imagen que acompaña al enlace en este caso es meramente decorativa,



funciona a modo de icono mostrando el cartel de la exposición como algo que ayude al

reconocimiento visual, por lo que debería ser ignorada por las ayudas técnicas. La técnica

que corrige este fallo es la técnica H67 y la H30.

<a href="/exposiciones/histórico/expo1">

<img alt="" src="ruta/foto1.jpg" />

Lorem ipsum dolor sit amet

</a>

Código 32: Alternativo para una imagen que debe ser ignorada por las ayudas técnicas

Por último, el evento falla en varias ocasiones para este criterio. Por un lado, los iconos

que se muestran para colapsar o expandir los distintos bloques de contenido no muestran

una alternativo correcto cuando hay JavaScript en la página. Unas veces, el alternativo es

vacío y otras dice “Contraer” cuando debería ser “Expandir” o viceversa. Este fallo se ve

reflejado en el fallo F30 que dice que si el texto alternativo no puede ser usado en lugar del

contenido no textual sin perder información o funcionalidad, entonces este alternativo

falla porque en realidad no es una alternativa al contenido no textual.

Por otro lado, el iframe que contiene al mapa de Google Maps contiene un conjunto de

imágenes que conforman la vista de mapa que ve el usuario. Estas imágenes contienen

alternativos vacíos, cuando en realidad presentan información relevante. Este fallo está

reflejado en el fallo F65 comentado anteriormente. La solución a este fallo pasaría por no

incluir este iframe en el sitio web, ya que el código del mismo pertenece a Google Maps y

por tanto no depende de los desarrolladores de este sitio web.

Por último, el evento presenta un problema con los alternativos de las fotografías de la

galería. Estas fotografías presentan como alternativo el título de la imagen y no su

alternativo real –que es más descriptivo- que se puede leer en la vista de la galería de la

sala de prensa. Además, cuando no hay JavaScript la fotografía se visualiza en una página

en blanco que contiene sólo la imagen sin información alguna. La corrección a este cúmulo

de fallos es por un lado, proporcionar un longdesc que enlace a la vista de la galería en la

sala de prensa siempre. De esta forma, tanto si hay como no JavaScript el usuario que

utilice lectores de pantalla podrá acceder a la información completa de la fotografía. Y por

otro lado, será necesario quitar el enlace al archivo para que no se acceda nunca a esta

vista huérfana de la fotografía.


Este Criterio de conformidad no es aplicable en ninguna página del sitio web, debido a que

este tipo de contenido multimedia – sólo vídeo y sólo audio – no existe en este sitio web.

Los vídeos de los eventos es un tipo de contenido multimedia descrito por las WCAG 2.0

como synchronized media y se les aplican otros requisitos de accesibilidad.


4. SOLUCIÓN [197]


Este criterio sólo será aplicable en los eventos, ya que el resto de páginas del sitio web no

tendrán contenidos multimedia, aun así no todos los eventos tienen porqué tener vídeos.

Si se recuerda el requisito sobre los eventos, este campo no es obligatorio para la creación

de este tipo de contenidos en el sito. Por otro lado, el que se cumpla o no, dependerá de

que el editor de contenidos del sitio suba el fichero de subtítulos, además del vídeo.

Actualmente, no se está cumpliendo este criterio en ningún evento con vídeo debido a la

ausencia de estos ficheros.

El reproductor integrado en el gestor de contenidos permite la inserción de subtítulos

cerrados, por lo que no es necesario editar la pista de vídeo para insertar subtítulos

abiertos, sino que basta con crear el archivo de subtitulado y subirlo a la vez que el vídeo.


Este criterio no es aplicable a ninguna página del sitio web, salvo a un evento con vídeo.

Para este caso, este criterio sigue fallando debido a que no se están proporcionando

audiodescripciones para los vídeos.


Este criterio no es aplicable a ninguna página del sitio web ni siquiera al evento, dado que

el criterio está relacionado con el subtitulado en tiempo real.


Este criterio de conformidad se ha considerado no aplicable a ninguna página de este sitio

web, dado que los vídeos que se publicarán en los eventos serán ponencias o conferencias

de inauguración de actividades sin información visual relevante. En estos casos, en los que

la información visual no es relevante este punto no es aplicable.

En caso de que el tipo de vídeo cambie y la información visual pase a tener importancia,

este criterio deberá tenerse en cuenta.


Este criterio no es aplicable a ninguna página del sitio web salvo en los eventos con vídeo.

En este último caso este punto falla, dado que no se presenta interpretación en lengua de

signos. Para solucionar este fallo sería necesario grabar a una persona interpretando el

vídeo y editar la pista para incluirla sincronizada con el vídeo.




Este criterio que trata sobre la audiodescripción ampliada no es aplicable por el mismo

motivo que el expuesto en el criterio 1.2.5.


Este criterio sólo es aplicable en la página de eventos con vídeo, además para este caso

falla. El criterio se centra en que se proporcione una alternativa para los medios

tempodependientes, tanto para todos los contenidos multimedia sincronizados grabados

como para todos los medios de sólo vídeo grabado siempre.


Este criterio no es aplicable en ninguna página del sitio web, ya que se centra en el

contenido que sea sólo audio.


El objetivo de este criterio es asegurar que la información y las relaciones existentes en el

contenido transmitidas a través de la presentación también estén disponibles cuando se

cambie el formato de presentación (por ejemplo, cuando se accede con un lector de

pantalla o cuando se sustituyen las hojas de estilo del sitio por hojas de estilo de los

usuarios), se aplica a cualquier página del sitio web.

Todas las páginas presentan la información de manera que existe esa correspondencia

visual con la determinable mediante software, excepto en la sala de prensa y en el evento.

En la sala de prensa se presenta lo que parece un listado de las últimas galerías

actualizadas, ya que presenta viñetas y está contenido dentro de un bloque, pero

internamente el XHTML que lo construye no es una lista. En el evento los enlaces a los

temas relacionados se presentan de manera consecutiva cuando deberían agruparse

internamente.

Este fallo está recogido por el F2 del documento de las técnicas. La corrección de éste es

convertir ese listado en una lista mediante el lenguaje de marcado que se está utilizando –

XHTML-, que está recogido en la técnica H48 como muestra el Código 33.

<?php if (!$field_empty) : ?>

<div class="field field-type-<?php print $field_type_css ?> field-<?php print

$field_name_css ?>">

<?php if ($label_display == 'inline') { ?>

<div class="field-label-inline<?php print($delta ? '' : '-first')?>">

<?php print t($label) ?>: </div>

<?php } ?>

<?php $count = 1;


4. SOLUCIÓN [199]

<ul>


if (!$item['empty']) : ?>

<?php $item['view'] = str_replace('taxonomy/term','temas-relacionados',

$item['view']); ?>

<li><?php print $item['view']?></li>

<?php $count++;

-- elseif ((!$item['empty']) && $count != 1): ?>

-- <?php $item['view'] = str_replace('taxonomy/term','temas-relacionados',

$item['view']); ?>

// Ya no son enlaces consecutivos y no hace falta insertar un caracter

// separador

-- <?php print '<img src="div-links.png" alt=""/>'.$item['view']?>

-- <?php $count++;

endif;

endforeach;?>

</ul>

</div>

<?php endif; ?>

Código 33: Estilo de lista para los enlaces de temas relacionados


Este criterio de conformidad tiene como objetivo lograr que los agentes de usuario puedan

proporcionar presentaciones alternativas del contenido manteniendo el orden de lectura

correcto para su comprensión. En este caso, el orden de lectura se corresponde con el

visual y por tanto es una secuencia correcta que asegura el significado.


Este criterio de conformidad que tiene por objetivo asegurar que todos los usuarios

puedan acceder al contenido y comprender las instrucciones para usarlo, incluso cuando

no puedan percibir la forma, tamaño o información sobre la localización espacial u

orientación, sólo es aplicable en las dos páginas donde se proporcionan instrucciones para

comprender y operar con un formulario web. En estos dos casos se cumple, ya que no

dependen de ningún aspecto visual.


Este criterio es correcto en todas las páginas del sitio web. No se utiliza el color para

transmitir información. Por ejemplo, en los formularios cuando los campos son

obligatorios no se ha utilizado el color para marcarlos, sino un asterisco.




Este criterio es aplicable cuando existe un audio que comience automáticamente y dure

más de 3 segundos. Este criterio de conformidad no se refiere exclusivamente a sonidos de

fondo incluidos en una página, sino a cualquier sonido existente, incluidos los

reproductores multimedia. Por ello, se ha optado por desactivar la configuración del

reproductor que hace que comience su reproducción de manera automática al cargar la

página. Y por tanto, no es aplicable en ninguna página del sitio.


Este criterio de conformidad falla para todas las páginas evaluadas del sitio web. Esto se

debe a que existen dos fallos comunes a todas ellas en el pie y en el bloque de eventos de la

barra lateral.

Todos los contrastes de color evaluados cumplen con el mínimo exigido por este criterio

salvo los enlaces del pie de la página. El pie tiene una imagen de fondo que crea un efecto

de degradado de blanco a gris, la cual no contrasta lo suficiente con el color de los enlaces

que se muestran en el pie. La solución ha sido crear una imagen cuyo degradado a gris sea

más prolongado para que no coincida con los enlaces y que la sustitución de esta imagen

sea un color intermedio del degradado y no el color final del mismo.

El otro fallo común del bloque de eventos se produce cuando se desactivan imágenes. Los

enlaces que permiten contraer y expandir cada lista de eventos tienen su texto de color

blanco sobre una imagen de fondo en color morado. Este contraste es suficiente, pero

cuando se desactivan imágenes, no hay color que sustituya la imagen de fondo y el texto se

mantiene en blanco. La solución para este error es sencilla, sólo hay que añadir el color

sólido de la imagen al fondo para cuando la imagen desaparezca.

Las páginas de contacto y de accesibilidad que presenta cada una de ellas un formulario,

también tienen un fallo común a ambas. El color rojo con el que se muestra el asterisco que

marca la obligatoriedad del campo no contrasta lo suficiente con el blanco de fondo. La

solución ha sido oscurecer el tono de rojo utilizado.


Este criterio de conformidad se cumple en todas las páginas del sitio web excepto en la

página principal. Pese a ser un diseño con gran carga de imágenes decorativas para

mostrar el contenido, se ha realizado de manera elástica. Aun así muchos de los módulos

instalados en Drupal tienen su propio estilo que no siempre es fácil sobrescribir, como es

el caso del módulo utilizado para la implementación del banner de la página principal.

En este caso concreto se está produciendo el fallo F69 que provoca que el eslogan del

anuncio activo se esconda cuando el texto se redimensiona. La solución a este fallo es

cambiar el CSS para que las capas no tengan anchos en píxeles y sean en porcentajes..


4. SOLUCIÓN [201]


Este criterio es correcto en todo el sitio web. Aunque el diseño contiene gran cantidad de

imágenes, la mayoría de ellas son meramente decorativas y como tal se incluyen por CSS.

Los enlaces destacados de la barra lateral podrían considerarse imágenes de texto, pero

para estos casos no es posible conseguir una presentación visual similar a la conseguida

mediante imágenes.


Este criterio falla en todas las páginas del sitio por el color que aplica a los enlaces cuando

se hace foco sobre ellos. La solución a este fallo pasaría por oscurecer el tono de los

enlaces cuando se produce este evento, pero por motivos de diseño no se aplicará. Hay que

tener en cuenta que el nivel de accesibilidad de este criterio es AAA, y que por tanto la

barrera de accesibilidad no es tan alta.


Este criterio de conformidad no es aplicable en ninguna página del sitio web, ya que se

centra en aquel contenido que es sólo audio grabado que contiene habla en primer plano,

que no es un CAPTCHA sonoro o un audiologo y que no es una vocalización cuya intención

principal es servir como expresión musical, que no se da en el sitio web.


Este criterio de conformidad es correcto en todas las páginas del sitio web, salvo en la

página principal por lo comentado en el criterio 1.4.4. Para cumplir este criterio se tienen

que estar dando las siguientes características:

1. Los colores de fondo y primer plano pueden ser elegidos por el usuario.

2. El ancho no es mayor de 80 caracteres o signos (40 si es CJK).

3. El texto no está justificado (alineado a los márgenes izquierdo y derecho a la vez).

4. El espacio entre líneas (interlineado) es de, al menos, un espacio y medio dentro de

los párrafos y el espacio entre párrafos es, al menos, 1.5 veces mayor que el

espacio entre líneas.

5. El texto se ajusta sin ayudas técnicas hasta un 200 por ciento de modo tal que no

interfiera con la legibilidad del mismo.

Se está aplicando la técnica G156 para cumplir el primer punto. Usar una tecnología que

disponga de agentes de usuario de uso común que permitan cambiar el color de primer

plano y del fondo de los bloques de texto. Por tanto, como se está usando (X)HTML no es

necesario hacer nada para cumplir este requisito porque los navegadores ya permiten que

los usuarios puedan configurar las combinaciones de colores según sus necesidades.



Para el punto 2 se está aplicando la técnica H87. Esto se ha logrado gracias a un diseño

elástico, de manera que la reubicación de texto de posible cuando se redimensiona la

ventana por encima de la cuarta parte del ancho de la misma. El objetivo es permitir que

los usuarios puedan redimensionar la ventana hasta conseguir un ancho de línea ideal sin

que se produzca scroll horizontal para leer una línea de texto.

Para el punto 3 se ha optado por la alineación de texto a la izquierda en la mayor parte de

los casos. En los formularios se ha optado por la alineación a la derecha, por estética en la

presentación de los campos. En ningún caso se ha justificado texto.

Para cumplir el punto 4 es suficiente con especificar en las hojas de estilo un espaciado

entre líneas adecuado (line-height), entre 1.5 y 2 espacios. El espaciado entre párrafos se

ha especificado con sus márgenes (margin, margin-top o margin-bottom).

Por último para cumplir el punto 5 basta con especificar el tamaño del texto en porcentaje

o em y el tamaño de los contenedores en porcentajes. Todas las páginas cumplen esto

salvo la página de inicio debido a lo comentado en el criterio 1.4.4.


Este criterio especifica lo mismo que lo expuesto en el criterio 1.4.5, sólo que en este caso

las excepciones quedan excluidas. Por tanto, se está cumpliendo como en el caso del 1.4.5.


Este criterio es aplicable en todas las páginas del sitio web, debido a que existen

manejadores de eventos comunes a cualquiera ellas en el bloque de eventos de la barra

lateral. De hecho estos manejadores comunes son los que hacen que este criterio esté

fallando en todas las evaluaciones realizadas.

Algunas de las técnicas que el W3C propone sobre scripting y que son aplicables al sitio

web son:

SCR2: Using redundant keyboard and mouse event handlers [W3C, 2010]

SCR20: Using both keyboard and other device-specific functions [W3C, 2010]

SCR21: Using functions of the Document Object Model (DOM) to add content to a

page [W3C, 2010]

SCR26: Inserting dynamic content into the Document Object Model immediately

following its trigger element [W3C, 2010]

SCR28: Using an expandable and collapsible menu to bypass block of content

[W3C, 2010]

En el caso concreto del menú de navegación, el script sólo implementa la funcionalidad por

teclado. La funcionalidad con dispositivos de apuntamiento se consigue mediante la

combinación de XHTML y CSS. Por tanto, este script cumple este criterio de conformidad


4. SOLUCIÓN [203]

es correcto. La barra de reproducción mediante teclado del reproductor de vídeo del

evento, como su nombre indica, es para dispositivos con interfaz de teclado o para teclado

y por tanto su implementación es correcta.

Sin embargo, este criterio de conformidad falla para el bloque de eventos de la barra

lateral, la página de inicio y la página del evento también presentan este mismo fallo en el

banner de anuncios –para la página principal- y en el paginador de la galería fotográfica y

el mecanismo que permite contraer y expandir los bloques de información del evento –

para la página del evento-.

Aunque onclick sea, en principio, un manejador de evento de ratón la mayoría de los

navegadores (X)HTML lo interpretan como el manejador de evento de acción por defecto

para enlaces y botones y se activa tanto con el ratón como con el teclado, siendo así

independiente de dispositivo. La acción por defecto se produce cuando se hace clic con el

ratón, cuando se sitúa el foco sobre el elemento y se presiona la tecla de retorno o la barra

espaciadora y cuando se acciona el elemento a través de la API de accesibilidad (p. ej. con

un producto de apoyo). Por tanto, para documentos (X)HTML , se puede usar el manejador

de evento onclick sin necesidad de duplicarlo con onkeypress, evitando así los posibles

problemas con la tabulación.

Por otro lado, en agentes de usuario no (X)HTML es posible que el comportamiento sea

diferente y no se interprete onclick como manejador de evento genérico de acción y

funcione sólo con ratón. En ese caso, sí se debe duplicar con onkeypress y, antes de

lanzar los eventos, controlar antes que se ha pulsado la tecla adecuada (p. ej. retorno o

barra espaciadora) para evitar los problemas de tabulación.

Si se replican todos los manejadores de eventos de ratón y de teclado se tienen que usar

onclick junto con onkeypress. Sin embargo, el manejador de evento onkeypress

reacciona ante cualquier tecla, incluido el tabulador, dando lugar a problemas con la

tabulación. Para evitar esto es necesario comprobar antes que se ha pulsado la tecla

adecuada (p. ej. retorno o barra espaciadora).

El fragmento de Código 34 son las líneas añadidas a todos estos eventos para que sean

completamente independientes de dispositivo.

$('.itinerancia h3 a').keypress(function(evento){

if(evento.which == 13 || evento.which == 32){




}

else{


}



}

});

Código 34: Manejador de evento para teclado


La dependencia de dispositivo en el manejo de los eventos, no implica que este criterio

tenga que fallar. De lo que trata este criterio es de asegurar que el contenido no deja

bloqueado el foco del teclado impidiendo que se pueda salir. Este es un problema habitual

cuando se combinan diferentes formatos de contenido (video, audio, multimedia)

mediante plugins o aplicaciones incrustadas.

Por ejemplo, es habitual ver cómo en algunas aplicaciones incrustadas (aplicaciones en

Flash, controles de reproductores multimedia, etc.) el foco puede entrar normalmente en

su interfaz con el teclado pero, una vez dentro, no vuelve a salir usando únicamente el

teclado y es necesario hacer clic con el ratón en una zona exterior para recuperar el foco

para el resto de la página. Esto representa un problema de accesibilidad ya que muchos

usuarios con discapacidad no pueden usar el ratón u otro dispositivo de apuntamiento y

dependen exclusivamente del teclado.

Se considera que el foco queda atrapado en parte del contenido si el foco entra

normalmente con el teclado pero, una vez dentro, los usuarios no pueden o no saben cómo

sacarlo usando únicamente el teclado. Esto no impide que el foco quede restringido a una

zona del contenido mientras se opera con él siempre que sea posible recuperar el foco con

el teclado de forma normal o se informa previamente cómo hacerlo.

En el caso concreto del reproductor de vídeo, como aplicación incrustada, no se producen

este tipo de errores.


Este criterio contempla lo mismo que el 2.1.1, sólo que excluye las excepciones propuestas

en el 2.1.1 la función interna requiere de una entrada que depende del trayecto de los

movimientos del usuario y no sólo de los puntos inicial y final. Este criterio continúa

fallando en todas las páginas del sitio por lo expuesto en el criterio 2.1.1.


Este criterio de conformidad sólo es aplicable en la página de inicio, ya que se considera un

límite de tiempo a cualquier proceso que ocurra cada cierto tiempo, o después de un

periodo de tiempo, incluyendo el contenido que se mueve o actualiza a un ritmo superior a

la capacidad de lectura o entendimiento de los usuarios.

En este caso existe un límite de tiempo en la lectura porque el contenido cambia,

actualizando el anuncio que se muestra, lo que implica estar introduciendo un límite de


4. SOLUCIÓN [205]

tiempo en la capacidad de los usuarios para leer el contenido. La técnica que se ha

utilizado para cumplir el criterio es la SCR33. El visor de anuncios del sitio web

proporciona un mecanismo para pausar el desplazamiento de los anuncios. Este

mecanismo no viene activado por defecto, sino que es una configuración opcional. Esta

interfaz de manejo del visor ha sido activada para que los usuarios puedan detener el

movimiento o reanudarlo, así como avanzar de uno en uno los anuncios. Este mecanismo

se muestra justo antes del visor de anuncios en la esquina superior izquierda.


Este criterio, como en el caso anterior sólo es aplicable para la página de inicio y, como se

ha comentado en el criterio anterior, existe un mecanismo que permite pausar el

movimiento y por tanto, se está cumpliendo.

Se podría pensar que en el evento también es aplicable por el reproductor, pero como se

dijo en el criterio 1.4.2, el reproductor no comienza a reproducir automáticamente tras la

carga de la página y por tanto, no se corresponde con lo que dice este criterio.


Este criterio es aplicable en todas las páginas del sitio web, y se cumple para todas salvo

en la página de inicio. Esto se debe a que el objetivo es proporcionar a los usuarios todo el

tiempo que sea necesario para que puedan completar una actividad. Por tanto, para un

nivel AAA, el sitio web no debería contener ninguna actividad que requiera una

interacción con un límite de tiempo, salvo que este límite de tiempo sea esencial.

No se propone una solución para este criterio, ya que el banner se mantendrá en la página

de inicio.


Este criterio es aplicable en la página de inicio. En este caso se está cumpliendo por lo

mismo que en los casos anteriores: existe un mecanismo que permite posponer la

actualización del contenido. Para el resto de páginas del sitio no es aplicable, ya que no

existen actualizaciones automáticas en ningún contenido del sitio web sin que se produzca

por acciones del usuario.


Por defecto en Drupal las sesiones no expiran, aún así esta configuración se ha modificado

en el servidor por temas de seguridad. La sesión sólo expirará cuando el usuario cierre el

navegador, pero nunca tendrá un límite de tiempo de inactividad. Esto garantiza que el

usuario autentificado tendrá el tiempo que necesite para realizar las tareas de gestión de

contenidos. Por tanto, se considera que se está cumpliendo el requisito.




Este criterio se cumple en todas las páginas del sitio debido a que no se incluye contenido

que provoque ningún tipo de destello.


Este criterio de conformidad se está cumpliendo en todas las páginas por el mismo motivo

expuesto en el criterio anterior.


El objetivo de este criterio es permitir a quienes naveguen de forma secuencial acceder de

forma directa al contenido principal.

Este criterio se cumple en todas las páginas del sitio ya que se repiten los mismos

mecanismos en todas ellas. Las técnicas utilizadas en el sitio web son:

G1: Adding a link at the top of each page that goes directly to the main content area

H69: Providing heading elements at the beginning of each section of content

SCR28: Using an expandable and collapsible menu to bypass block of content

La técnica G1 se ha logrado insertando en el archivo de plantilla page.tpl.php un enlace

cuya clase de CSS -Código 35- hace que esté oculto visiblemente tomando el color de

fondo, pero no para lectores de pantalla y cuando recibe el foco se muestra.

#header-links > a.transparent {

background: none repeat scroll 0 0 transparent;

color: white;

width: auto;

}

#header-links > a.transparent:hover, #header-links > a.transparent:focus {

background: none repeat scroll 0 0 #CF3300;

}

Código 35: CSS que oculta el enlace para saltar al contenido

La técnica H69 está implementada en todos los archivos de plantilla que se están

utilizando para la maquetación del HTML sitio web. A lo largo de la solución se han ido

comentando todas aquellas cabeceras que se han modificado para generar esa estructura

correcta de encabezados.

La técnica SCR28 está implementada en el script del menú.

Otra técnica utilizada, aunque no esté propuesta como tal en el documento de las técnicas

para saltar bloques de contenidos es agrupar los enlaces con elementos estructurales


4. SOLUCIÓN [207]

como listas desordenadas <ul>, listas ordenadas <ol>, o el elemento <map>, permitiendo

identificar dichos listados de enlaces como menús de navegación. Esta técnica está

implementada en el bloque de eventos de la barra lateral, cuyos enlaces están agrupados

en listas categorizadas por actuales, futuros y realizados o en el menú de navegación.

Al usar estos elementos los agentes de usuario y productos de apoyo los podrán reconocer

como menús de navegación y facilitar a los usuarios opciones que les permitan saltarlos

para acceder al contenido siguiente.


Este criterio se cumple en todas las páginas del sitio web gracias a la plantilla de página.

En el fragmento de se muestra el comienzo del HTML para el archivo de plantilla de página

del sitio web donde se genera en la cabecera del mismo el title de la página. Esta técnica

está contemplada en el documento de las WCAG como la técnica H25

<html xmlns="http://www.w3.org/1999/xhtml"

xml:lang="<?php print $language->language ?>"

lang="<?php print $language->language ?>" dir="<?php print $language->dir ?>">

<head>


<title><?php print (t($head_title)); ?></title>

Código 36: Comienzo del HTML de una página del sitio web


En todas las páginas del sitio el orden lógico de tabulación se corresponde con el orden

visual. Por otro lado, en ninguna se altera el orden de tabulación con elementos tabindex.

Además, en los scripts, la inserción de contenido en el DOM siempre se hace por debajo del

elemento que está recibiendo el foco.


Este criterio que se centra en ayudar a los usuarios a comprender el propósito de cada

enlace de forma que puedan decidir si seguirlo o no.

Aunque este criterio no obliga a que el propósito del enlace deba determinarse

independientemente de su contexto, en el sitio web se ha optado por crearlos de esta

manera. Esto se debe a que la implementación de manera automática es mucho más fácil

de esta forma, que si se tiene en cuenta el contexto en el que se encuentra el enlace. No

siempre es posible estructurar un contenido de manera que un enlace pueda estar

internamente dentro del elemento que le corresponde para determinar su contexto. Por

ejemplo, los enlaces leer más deberían ir dentro del párrafo al que hacen referencia para

determinar su propósito mediante su contexto. Es posible que la generación de este enlace



no se haga en el mismo instante de tiempo y su inserción no se pueda hacer dentro del

párrafo. Por este motivo, se han evitado este tipo de enlaces.

Todos los enlaces en el sitio tienen un propósito claro e independiente de contexto. Estos

enlaces se construyen de diferentes formas según se exponen en la técnica H30 y con la

técnica H33.

El fallo de este criterio se encuentra en la evaluación de la página del evento provocado

por los enlaces contenidos en el iframe de Google Maps. Estos enlaces no tienen ni texto

ni title que describa su propósito ni se encuentran dentro de un párrafo que ayude a

conocer el contexto de los mismos. La solución a este fallo es no incrustar este iframe, ya

que el código no puede corregirse. Por lo tanto no se puede corregir a menos que se

cambie la solución tecnológica para los mapas.


Asimismo, las personas con problemas cognitivos encontrarán más fácil el uso de

funciones de búsqueda que comprender mecanismos de navegación jerárquicos.

Este criterio se cumple en todas las páginas del sitio web gracias a la aplicación de las

siguientes técnicas para lograrlo:

G125: Providing links to navigate to related Web pages

G63: Providing a site map

G161: Providing a search function to help users find content

La técnica G125 se ha implementado desde el momento en el que se enlazan otras

páginas del sitio web desde cualquier otra página del mismo. Con los enlaces de

temas relacionados se enlazan páginas con contenidos relacionados por una

misma temática o con los enlaces a los eventos se relacionan eventos destacados

del sitio web.

La técnica G63 permite al usuario otro tipo de navegación. Esta técnica está

implementada mediante un mapa del sitio y no una tabla de contenidos, por lo que

es una copia idéntica del menú de navegación.

La técnica G161 se implementa con el buscador del sitio. Este tipo de herramientas

en un sitio web permiten al usuario encontrar contenido directamente sin

necesidad de navegar por el sitio.


Este criterio se cumple en las páginas gracias al uso de los encabezados y de etiquetas para

los elementos de interacción, como los controles de los formularios de contacto,

accesibilidad y búsqueda. Se ha intentado que los títulos de las noticias no sean


4. SOLUCIÓN [209]

excesivamente largos. Una información descriptiva no implica que deba ser larga, siempre

es mejor que sea breve y concisa.


Este criterio persigue que el indicador de foco se pueda localizar visualmente.

Este criterio es correcto en todas las páginas excepto en la página del evento, que falla

cuando los enlaces del iframe del mapa de Google Maps reciben el foco y no se marcan

visualmente. La solución a este fallo, nuevamente es eliminar el iframe cambiando la

tecnología utilizada para los mapas.


Las técnicas que se utilizan para situar al usuario dentro del sitio web son:

G65: Providing a breadcrumb trail

G63: Providing a site map

G128: Indicating current location within navigation bars

La técnica G65 se ha implementado en todas las páginas del sitio web menos en la página

principal, por ser la raíz. Todas las migas de pan están construidas a partir de un primer

enlace a la página principal y contruyendo el resto de la ruta dependiendo de los niveles

del menú de navegación que el usuario haya atravesado. Todas las páginas tienen una

implementación correcta.

La técnica G128 se ha implementado en todas aquellas página de enlace de menú de

navegación. Siempre que el usuario se encuentre en una página del menú de navegación

éste se le mostrará expandido y resaltado.

Respecto a la técnica G63 se habló en el criterio de conformidad 2.4.5.


Este criterio se cumple en todas las páginas del sitio excepto en la página del evento por lo

mismo que lo expuesto en el criterio 2.4.4.


Este criterio se cumple en todas las páginas ya que se hace uso de encabezados de HTML.

Además, este uso se hace siguiendo la recomendación de no saltar el orden de los

encabezados.




Este criterio se cumple en todas las páginas del sitio web, ya que Drupal inserta por

plantilla el idioma de la página haciendo uso de la técnica H57 como se muestra en el

fragmento de Código 37.

<html xmlns="http://www.w3.org/1999/xhtml"

xml:lang="<?php print $language->language ?>"

lang="<?php print $language->language ?>"

dir="<?php print $language->dir ?>">

Código 37: Idioma de la página


No hay cambios en el idioma principal de la página, por tanto no es necesario marcar

cambios. Para las páginas evaluadas y el contenido generado por el propio gestor este

criterio se cumple, salvo en el evento. En esta página se ha detectado parte de la interfaz

del reproductor sin traducir al español y sin marcar su cambio de idioma. La corrección

para este problema es traducir la interfaz de Drupal.

Aun así este criterio deben tenerlo en cuenta las personas que generen contenidos en el

sitio web cuando inserten nuevo contenido, ya que deben ser conscientes de marcar los

cambios de idioma en el texto.


Este criterio no es aplicable ninguna página del sitio por no usar palabras que requieran

definiciones.


Realmente no es aplicable a ninguna de las páginas evaluadas porque el contenido

específico de cada una de ellas no ha contenido ningún caso que lo requiriese. Como en el

criterio de conformidad 3.1.2, las personas encargadas de publicar contenidos en el sitio

deberán tener en cuenta este tipo de palabras para marcarlas expandidas, ya que el editor

de texto de Drupal está configurado para que acepte este tipo de marcado HTML.


Según el baremo que se establece para medir la legibilidad de la página, el nivel de

dificultad no debe superar el de un estudiante de entre primero y segundo de la

secundaria obligatoria española. En principio se considera que el nivel de lectura del sitio

no está por encima de este nivel. Aun así, esto entrará dentro de las revisiones periódicas

de accesibilidad para garantizar dicho nivel de compresión.


4. SOLUCIÓN [211]


Este criterio no es aplicable porque el idioma de la página es español.


Es importante entender qué significa un cambio de contexto para determinar el

cumplimiento de este criterio y los siguientes.

Se entiende por cambio de contexto un cambio importante en el contenido de la página..

Esto incluye cambios de:

Agente de usuario: abrir un gestor de correo, un lector de documentos PDF, etc.

Vista (área de visualización): nuevas ventanas o pestañas, marcos, etc.

Foco: cambiar el foco de un elemento a otro es un cambio de contexto.

Contenido que cambia el significado de la página: ir a una página nueva o un

cambio de contenido tal que parezca que se ha ido a una página nueva. También se

considera un cambio de contexto el cambio en el orden del contenido de la página.

Un cambio de contenido no es siempre un cambio de contexto a no ser que cambie algo de

lo anterior. Algunos ejemplos de cambios de contexto pueden ser:

Envío de un formulario de forma automática cuando un componente recibe o

pierde el foco.

Apertura de nueva ventana cuando un elemento recibe el foco.

Cambio del foco a otro componente cuando un componente recibe el foco.

Por otra parte, no se consideran cambios de contexto:

Expandir un submenú en el menú de navegación.

Expandir parte de contenido previamente oculto como, por ejemplo, las respuestas

a las preguntas de un FAQ.

El uso de pestañas para alternar entre diferentes partes del contenido de la página.

Por tanto este criterio se cumple en todas las páginas del sitio porque no se cargan

acciones que provoquen cambios de contexto en los eventos onfocus.


Del mismo modo que en el caso anterior, no se provocan cambios de contexto debidos a

cambios de estado de cualquier componente de interfaz de usuario

El único script que se ejecuta en los formularios de accesibilidad y contacto es sobre el

evento onsubmit, que provocará un cambio de contexto como consecuencia de una acción

ejecutada por el usuario – el envío del formulario-.




Una navegación coherente es útil para los usuarios que interactúan con contenidos

repetidos en un conjunto de páginas web y que necesitan localizar una funcionalidad o

información específica más de una vez. Este criterio se cumple porque la navegación se

presenta siempre de la misma zona de la página y no se altera el orden de los elementos de

navegación en distintas páginas.


Lo que se pretende con este criterio es identificar de forma consistente los componentes

funcionales que se repiten en un conjunto de páginas web. Si la misma función tiene

diferentes etiquetas a lo largo del sitio, el sitio es mucho más difícil de usar.

Esto se ve reflejado en el sitio porque se usan los mismos nombres y textos para referirse a

los contenidos que tienen la misma funcionalidad. Se usan las mismas etiquetas para los

mismos controles de formulario o se usa el mismo texto de enlace para el mismo destino.

También se utiliza una consistencia visual para identificar las mismas funcionalidades,

colores de enlaces o iconos para identificar los destinos.

Es en este criterio donde falla la página de exposiciones, por el elemento de paginación.

Drupal introduce la clase active a las listas de enlaces por defecto. Esta clase es la que se

introduce cuando un elemento de paginación está activo y por tanto, el enlace se muestra

de otra forma. Para solucionar este fallo se debe eliminar dicha clase de la función de tema

de las listas de enlaces. .


Como se ha comentado en los criterios 3.2.1 y 3.2.2 los cambios de contexto sólo se

producen por acciones del usuario, que es precisamente de lo que trata este criterio evitar

la confusión que producen los cambios de contexto inesperados dando a los usuarios un

control total sobre los mismos.

Además de los cambios de contexto contemplados en los criterio 3.2.1 y 3.2.2, existen

otros como las redirecciones, las actualizaciones automáticas de páginas enteras o la

apertura de ventanas nuevas. En el sitio web existen redirecciones automáticas de

servidor para poder mantener contenidos del sitio anterior. Este tipo de redirecciones no

afectan al usuario, ya que éste no se entera de ellas. Además, existen en el sitio enlaces que

se abren en ventanas nuevas cuando los enlaces salen del sitio web. Este tipo de enlaces

están marcados de forma especial para que el usuario sepa de este hecho y no sea

inesperado.

Respecto a este último aspecto de las ventanas nuevas, existe en el sitio un enlace que se

repite en la página de inicio, en la página de exposiciones y en la página del evento y que

abre una ventana nueva sin previo aviso al usuario. Este fallo está recogido en las técnicas


4. SOLUCIÓN [213]

para las WCAG 2.0 como el F22 y se corrige introduciendo el atributo target al enlace e

indicando en el enlace de este hecho - técnica H83 -.

En el fragmento de Código 38 se muestra cómo se le indica al usuario de este hecho a

través de una imagen dentro del enlace.

<a href="http://www.fueradeldominio.com" target="_blank">

Visitas guiadas a la exposición

<img alt="en ventana nueva" src="../images/ico_externo.png" />

</a>

Código 38: Enlace externo

Por otro lado, no se realizan actualizaciones automáticas de páginas completas. Por tanto,

este criterio se está cumpliendo en todas las páginas del sitio web.


Este criterio es aplicable en las páginas donde se detecten errores en la entrada de datos

del usuario, es decir en las páginas de accesibilidad y de contacto porque el formulario de

búsqueda no detecta errores. Por tanto, para el resto de páginas no es aplicable.

Para estas dos páginas, se cumple el criterio gracias al uso de las siguientes técnicas:

G83: Providing text descriptions to identify required fields that were not

completed

G85: Providing a text description when user input falls outside the required format

or values

SCR18: Providing client-side validation and alert

La técnica G83 se basa en mostrar los mensajes de error de los campos obligatorios que el

usuario ha dejado en blanco al rellenar el formulario. La Figura 68 muestra dichos

mensajes de error. Además estos mensajes son enlaces que apuntan al campo del error.

La técnica G85 consiste en mostrar descripciones para los errores de campos que

requieran un formato o un valor determinado, como por ejemplo el campo correo

electrónico. En la se muestra el error que se le muestra al usuario cuando no introduce un

valor válido en el campo de correo electrónico.

Por último la técnica SCR18 se ha implementado creando un script en jQuery que valida

los campos del formulario y alerta de los errores detectados. Por tanto, es técnica es la que

hace posible la implementación de las dos anteriores.



Figura 68: Errores de campos obligatorios en el formulario

Figura 69: Errores de campos con formato


Este criterio tiene por objetivo que se proporcionen instrucciones y etiquetas siempre que

se requiera la entrada de datos por parte del usuario.

Este criterio es aplicable en todas las páginas del sitio por el formulario de búsqueda que

está presente en las mismas. Aunque no sea visible la etiqueta está disponible para los

lectores de pantalla, además el campo input hace uso del atributo title para identificar

su propósito.

Por otro lado, los formularios de contacto y accesibilidad hacen uso de etiquetas e

instrucciones. Por tanto, este criterio se está cumpliendo.


Este criterio sólo es aplicable en los formularios de contacto y de accesibilidad, ya que

como se comentó en el criterio 3.3.1 en la búsqueda no se detectan automáticamente

errores en la entrada del usuario. En estos formularios no siempre existe una sugerencia


4. SOLUCIÓN [215]

para corregir el error, ya que saber si el usuario se ha confundido en datos como su

nombre o su dirección de correo no es posible. Sin embargo si el formato de los datos no es

el esperado sí se le indica cómo podría corregirlo. Por tanto, se considera que se cumple

para estas páginas y no es aplicable para el resto.


A ningún formulario de este sitio web actualmente aplicársele este criterio que está

orientado a formularios que impliquen compromisos legales o transacciones financieras,

que modifican o eliminan datos controlables por el usuario en sistemas de

almacenamiento de datos, o que envían las respuestas del usuario a una prueba.

En un futuro, si se crea una tienda en línea para la compra de publicaciones a través de la

editorial este criterio deberá cumplirse para alcanzar el nivel AA de las WCAG.


Este criterio se ha considerado correcto para todas las páginas teniendo en cuenta que la

ayuda contextual sólo es necesaria si las etiquetas usadas para los controles no son

suficientes para describir su funcionalidad. El formulario de búsqueda del sitio que carece

de instrucciones es una funcionalidad muy común para los usuarios y la identificación de

la funcionalidad -encabezado, etiqueta, title del input, alternativo de su botón- es

suficiente para comprender de qué se trata y cómo se usa.

Las instrucciones textuales al comienzo del formulario o grupo de controles describiendo

las restricciones de los campos o indicando el formato de los datos con un ejemplo, si son

lo suficientemente explicativas, pueden considerarse válidas como ayuda contextual de los

formularios. Sin embargo, siempre que sea necesario por la complejidad del formulario o

de los datos a introducir, es recomendable que incluir información de ayuda adicional de

forma explícita.

Para los otros formularios, dada la carencia de complejidad de los mismos esta técnica se

considera suficiente para cumplir este criterio.


Este criterio falla para todas las páginas del sitio web, debido a que no se contempla

excepción alguna para la prevención de errores. Aunque en las páginas de los formularios

de contacto y accesibilidad sí se esté proporcionando la detección de errores, esto no

implica que el usuario pueda revisar sus datos antes de enviarlos definitivamente. Por otro

lado, en el buscador no se ofrece tampoco esta opción. No se propone solución para este

fallo en ningún caso, dada la poca relevancia que implican los datos insertados para el

usuario.




Este criterio es correcto en todas las páginas del sitio ya que no hay errores de sintaxis en

el código y por tanto se están garantizando los aspectos de este punto. Aun así, es posible

que existan errores de sintaxis en un futuro, ya que no todo el código HTML es generado

por Drupal. Como se ha visto en la implementación de los requisitos algunos campos

permiten la inserción de HTML y por tanto se puede cometer un error. Es necesario que

las personas responsables de la edición de contenido


Este criterio de conformidad se cumple para todas las páginas del sitio web excepto para

la página del evento. El problema se presenta en el iframe del mapa de Google Maps que

carece de title que describa su propósito y por tanto los usuarios que utilizan

tecnologías de apoyo no pueden saber qué hay en él y decidir si explorarlo o no.

Requisito de conformidad 1

Este criterio no se cumplirá en ninguna página mientras existan errores en alguno de los

criterios de ese nivel, por tanto no se está cumpliendo.


Este criterio no se cumplirá hasta que todo el contenido de una página cumpla con los

criterios para un mismo nivel, por tanto no se está cumpliendo.


En el sitio web no hay páginas que formen parte de un conjunto de páginas dentro de un

proceso. Por tanto, se puede decir que este requisito de conformidad no es aplicable en

este sitio. En un futuro, si se implementa una tienda las páginas del proceso de compra

tendrán que cumplir con este requisito.


Este criterio falla para la página de inicio debido a la falta de alternativa cuando la

tecnología no está presente. El contenido no está accesible, porque sólo se carga el primer

anuncio. También falla para la página del evento, porque la galería fotográfica no carga la

misma información cuando no hay JavaScript. Por tanto, esta alternativa no es válida.

La corrección par el fallo del visor de anuncios podría ser un enlace a una página donde se

mostrarán los cuatro anuncios publicados. Esta información siempre estará actualizada

respecto a la original, de manera que sea un alternativo correcto según los criterios de

accesibilidad. Para lograr que esta información esté actualizada se puede duplicar la vista

creada para el visor de anuncios, sólo que en vez ser un bloque será una página y en vez de


4. SOLUCIÓN [217]

aplicar una presentación del módulo “Views Slideshow” será una vista de capas de HTML

simple. La información a mostrar, los criterios de ordenación y los filtros se mantendrán.

La corrección de los alternativos de la galería fotográfica consiste en construir la galería

mediante PHP para que cuando no haya JavaScript siga estando accesible la misma

información, y que el JavaScript realice los cambios necesarios sobre esta base para que

funcione la vista ampliada de las imágenes.


Existen una serie de criterios de conformidad (1.4.2, 2.1.2, 2.3.1 y 2.2.2) que son aplicables

a todo el contenido de la página, un fallo en cualquiera de estos criterios podría interferir

con el uso de toda página aunque no se dependa de la tecnología usada al tener una

alternativa accesible. Estos criterios de satisfacción están relacionados con el control

sobre la reproducción del audio, las trampas de teclado, los destellos y el contenido en

movimiento respectivamente.

Este requisito de conformidad se cumple en todas las páginas del sitio, ya que no se han

detectado fallos en ninguno de estos criterios.

4.38.2. Estado final del sitio

En el apartado anterior se han comentado tanto los fallos detectados como las soluciones a

los mismos. Por tanto, al final de toda esta sección se puede considerar que los errores se

han corregido y el estado del sitio se muestra en la Tabla 21. Como se puede ver se han

corregido todos los errores de criterios de satisfacción de nivel A y AA, siendo un total de

23 criterios correctos de nivel A, 10 de nivel AA y 13 de nivel AAA. No aplicables de nivel A

sólo hay 2 criterios en todo el sitio web, 3 de nivel AA y de nivel AAA hay 7. Por tanto,

existen 3 fallos en criterios de nivel AAA que no se van a corregir por que el sitio no

pretende alcanzar ese nivel de conformidad.

BIEN MAL N/A

Nivel A 23 2 -

Nivel AA 10 3 -

Nivel AAA 13 7 3

Tabla 21: Resumen del estado de la accesibilidad del sitio web

En la que aparece a continuación, se muestran los resultados de las evaluaciones de cada

página, tras la corrección de los fallos.

Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento


V V V V V V V V V

1.2.1 Audio-only and Video-only

N N N N N N N N N



Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento

(Prerecorded)


N N N N N N N N V


N N N N N N N N V


N N N N N N N N N


N N N N N N N N N


N N N N N N N N V


N N N N N N N N N


N N N N N N N N V


N N N N N N N N N


V V V V V V V V V


V V V V V V V V V


N N V V N N N N N

1.4.1 Use of Color

V V V V V V V V V

1.4.2 Audio Control

N N N N N N N N N


V V V V V V V V V

1.4.4 Resize text V V V V V V V V V


V V V V V V V V V


F F F F F F F F F


N N N N N N N N N


V V V V V V V V V


V V V V V V V V V

2.1.1 Keyboard V V V V V V V V V


V V V V V V V V V


4. SOLUCIÓN [219]

Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento


V V V V V V V V V


V N N N N N N N N


V N N N N N N N N


2.2.4 Interruptions

V N N N N N N N N


N N N N N N N N N


V V V V V V V V V

2.3.2 Three Flashes

V V V V V V V V V

2.4.1 Bypass Blocks

V V V V V V V V V

2.4.2 Page Titled

V V V V V V V V V

2.4.3 Focus Order

V V V V V V V V V


V V V V V V V V V

2.4.5 Multiple Ways

V V V V V V V V V


V V V V V V V V V

2.4.7 Focus Visible

V V V V V V V V V



V V V V V V V V V


V V V V V V V V V


V V V V V V V V V


V V V V V V V V V

3.1.3 Unusual Words

N N N N N N N N N

3.1.4 Abbreviations

N N N N N N N N N

3.1.5 Reading Level

V V V V V V V V V

3.1.6 Pronunciation

N N N N N N N N N




V V V V V V V V V



Inicio Mapa web

Contacto Accesibili

dad Guía de


Sala de prensa

Exposiciones

Evento


V V V V V V V V V


V V V V V V V V V


N N V V N N N N N


V V V V V V V V V


N N V V N N N N N


N N N N N N N N N



F F F F F F F F F



V V V V V V V V V






Tabla 22: Resultados de la evaluación tras la corrección de los errores

4.38.3. Evaluación de accesibilidad según las WCAG 1.0

En el anexo B de este documento, además de las evaluaciones realizadas a las páginas del

sitio web para las WCAG 2.0 también se puede encontrar la evaluación de las WCAG 1.0.

Aunque las pautas hayan cambiado sustancialmente, los fallos detectados son los mismos.

Por otro lado, habiendo aplicado las correcciones anteriormente comentadas estos fallos

quedan igualmente solventados y por tanto el estado del sitio web respecto a la

accesibilidad de estas páginas es el mismo (nivel AA de accesibilidad), cumpliéndose las

obligaciones legales del sitio web.

4.39. Resumen de los módulo de Drupal

En la Tabla 23 se presenta un resumen de los módulos de Drupal que se han instalado y

alterado para lograr los requisitos capturados para este desarrollo. Cuando se habla de

alteraciones se refiere a modificaciones de tpl –renombrados de archivo- o de funciones de

tema o maquetación de CSS de las clases por defecto de las salidas de los módulos para

lograr el estilo deseado, tal y como se ha explicado a lo largo de la solución.

En la columna “Modificado” se han marcado con una X aquellas funcionalidades de los

módulos que se han alterado. En la columna “Módulo” figuran los distintos módulos

instalados, la columna “Grupo” representa las relaciones entre dichos módulos.


4. SOLUCIÓN [221]

Grupo Modificado Módulo

CCK

X Content

X Content Multigroup

Content Permissions

X Content Taxonomy

Content Taxonomy

Autocomplete

Content Taxonomy Options

X Fieldgroup

X FileField

X Google Maps Embed

X ImageField

X Location CCK

Node Reference

Number

Option Widgets

Text

Fecha

X Date

Date API

Date Popup

Date Timezone

Filefield Paths

X FileField Paths

Image field

ImageAPI

X ImageAPI GD2

ImageAPI ImageMagick

X ImageCache

ImageCache UI

Location

X Location

Location Fax

Location Phone

Correo

Mime Mail

Mime Mail Action

PHPMailer

Media X Gallery Assist

Gallery Assist ImageCache



X Gallery Assist Lightboxes

Gallery Assist Views

X XSPF Playlist

XSPF Playlist Views

Otros contribuidos

Advanced help

BUEditor

CCK Field Indexer

Contact Hide Email

MimeDetect

Path redirect

Secure Login

Secure Pages

Secure Pages Hijack Prevention

Sub-path URL Aliasing

Token

Upload elements

Url alter

SWFTools

JW Media Player 4

SWF Tools

SWFObject2

Analíticas Google Analytics

Taxonomy Menu

X Taxonomy Menu

Taxonomy Menu Custom Path

Taxonomy Menu Hierarchy

X Taxonomy Menu Vocabulary

Path

jQuery

jQuery plugins

jQuery UI

jQuery Update

Video

X Video

Video FTP

Video Upload

Vistas

X Views

Views exporter


4. SOLUCIÓN [223]

X Views Grouping Row Limit

X Views Slideshow

Views Slideshow: SingleFrame

Views UI

Webform

X Webform

Webform Validation

Tabla 23: Módulos contribuido instalados y modificados

La tabla muestra los módulos del core activados. Estos módulos no se han modificado, por

tanto la columna “Modificado” se ha sustituido por “Activado”.

Grupo Activado Módulo

Core opcional

Aggregator

Blog

Blog API

Book

X Color

Comment

Contact

X Content translation

X Database logging

Forum

X Help

X Locale

X Menu

OpenID

X Path

X PHP filter

Ping

Poll

Profile

X Search

Statistics

Syslog

X Taxonomy



X Throttle

Tracker

X Trigger

X Update status

X Upload

Tabla 24: Módulos del core activados


6. LÍNEAS DE TRABAJO FUTURAS [225]

5. Conclusiones

Si bien es cierto que hoy en día es fácil crear una página web gracias a las herramientas

que existen en el mercado, no lo es tanto crear un buen sitio web. Un sitio web no es sólo

una página, sino un conjunto de muchas de éstas que usuarios potenciales llegarán a

visitar si encuentran lo que buscan y les gusta lo que ven en la página de inicio.

El diseño y la implementación de un sitio web no deben dejarse de ver como el desarrollo

de un software cuyo elemento principal y más importante es la interfaz de usuario. La

calidad de este software vendrá marcada por el grado de accesibilidad y usabilidad que

éste presente, así como por los contenidos que finalmente contenga.

A lo largo de este Trabajo se ha realizado el desarrollo de un sitio web accesible, partiendo

de unos requisitos que han sido fruto de la corrección de los errores cometidos en el sitio

web corporativo anterior y de las necesidades suscitadas en los últimos años y que ese

sitio ya no cubría.

La implementación de estos requisitos en el sitio web, se ha visto marcada por el uso de un

gestor de contenidos. Esto ha significado más una configuración del gestor que una

implementación propiamente dicha para poder cumplir dichos requisitos.

Respecto a la accesibilidad, aunque durante el desarrollo de todo el Trabajo se han tenido

en cuenta estas pautas, se han cometido errores que ha sido necesario subsanar tras la

evaluación final. Los errores no han implicado correcciones costosas, pese al nivel de

prioridad de accesibilidad que implicaban. Si la accesibilidad no se hubiese tenido

presente durante el desarrollo, los errores podrían haber implicado más horas y un alto

grado de dificultad. Supóngase el caso del reproductor de vídeo. Por un lado es necesario

integrar un módulo en el gestor que permita visualizar vídeos, por otro lado es necesario

configurar dicho módulo e integrarlo en el diseño para que funcione y se muestre

correctamente en una página del sitio. Si las características de accesibilidad no se hubiesen

tenido en cuenta desde el principio, todas estas tareas se tendrían que haber realizado dos

veces, es decir al menos se están duplicando los tiempos de desarrollo.

El resultado final es un sitio web accesible y más usable que el anterior, que cumple el

nivel AA de conformidad con las pautas de accesibilidad sobre contenidos web propuestas

por el W3C, tanto en su versión 1.0 como 2.0 y que marcará el desarrollo de las líneas

futuras de trabajo.

La usabilidad se puede ver reflejada en algunos aspectos evaluados en la accesibilidad

como la consistencia en la identificación de los elementos del sitio (estándares internos de

representación de elementos consistentes), función de búsqueda en el sitio, existencia de



un mapa web, migas de pan para situar al usuario en la navegación (el usuario sabe en

todo momento dónde se encuentra) o elementos de menú destacados en función de dónde

esté, encabezados identificando bloques de contenidos , título de las páginas, enlaces que

indican el destino correctamente, inexistencia de enlaces rotos, etc.

Este proyecto de desarrollo comenzó en septiembre de 2010 y las primeras

funcionalidades del sitio web fueron lanzadas en marzo de 2011, mismo mes en el que fue

presentado. Las sensaciones que causaron el nuevo diseño y la nueva página, fueron

positivas. Pese a que este diseño no fue desarrollado desde la Fundación, sino que se pidió

a una empresa externa, las decisiones de logotipo, cabecera, estructura y organización sí se

tomaron desde dentro.

A la empresa externa se le pidió un diseño a partir de un prototipo alta fidelidad, de

manera que sólo tuviesen que decir sobre el aspecto de los elementos –formas, colores,

iconografía, etc.-. Este diseño se demoró bastante y retrasó el lanzamiento, pero lo que

más tiempo llevó fue integrar todas las funcionalidades del sitio web en Drupal.

Entre las funcionalidades más costosas han estado la integración del reproductor de vídeo,

la funcionalidad del menú de navegación para que funcione por teclado y la galería

fotográfica.



6. Líneas de trabajo futuras

Este Trabajo de Fin de Carrera inicia un gran proyecto corporativo que estará en continuo

cambio y evolución. Por ello, definir las líneas de trabajo futuras es muy importante

porque no sólo marcarán lo que falta por hacer, sino las tareas que habrá que hacer

periódicamente desde hoy.

Las primeras líneas que se van a comentar están orientadas a la integración de nuevos

servicios o funcionalidades que se ofrecen en el sitio web. Las siguientes tienen que ver

con el mantenimiento del sitio web.

6.1. Integración de nuevos servicios

Búsqueda avanzada

Como se ha comentado en los requisitos y en la implementación, el sitio tiene un buscador

que permite localizar la información a través de palabras claves. Pero esta información

está creciendo demasiado deprisa y el buscador devuelve varias páginas de resultados

para determinados términos. Por tanto, un requisito suscitado de esta situación es

proporcionar a los usuarios determinados filtros para acotar los resultados de la búsqueda

de manera que si saben más información sobre lo que están buscando –rango de fechas,

noticias, actividades, exposiciones, fotografías, etc.- puedan localizarlos más rápidamente.

Por otro lado, con este servicio la carga sobre el gestor de contenidos se reduciría para

consultas con gran número de nodos con coincidencias.

Galerías fotográficas y videoteca

Sería interesante que en la sala de prensa se pudiesen consultar todas las galerías

fotográficas y todos los vídeos del sitio web. De esta forma el usuario no tendría que ir

nodo por nodo viendo cada galería, sino que tendría en una misma página todas las

galerías que quisiese ver. Esta misma idea sería aplicable para los vídeos.

Hay que tener en cuenta que la implementación de este tipo de páginas debe cumplir con

la normativa de accesibilidad que se ha visto a lo largo de este Trabajo. Para ello, habrá

que pensar en el diseño que se desea y aplicar a los requisitos estas características

especiales.

Publicaciones

Como se ha comentado en este Trabajo, esta Fundación tiene una editorial que saca

publicaciones periódicamente a lo largo del año. Este tipo de publicaciones abarcan



distintas líneas editoriales, desde libros pasando por revistas, catálogos de exposiciones y

algún que otro documental.

El objetivo que se persigue es que el catálogo de la editorial de la Fundación se pueda

consultar a través del nuevo sitio web. Es decir, que cualquier usuario pueda conocer los

libros, revistas, catálogos y documentales publicados y los datos más relevantes de los

mismos, además de poder saber los contenidos de las publicaciones mediante su índice.

Toda esta información se encuentra en una web externa, que difícilmente se vincula al

antiguo sitio web de la Fundación. Por tanto, el esfuerzo que podría requerir esta línea de

trabajo es bastante elevado.

Para poder realizarlo sería necesario tener en consideración los siguientes puntos:

Conocer cómo se estructuran las distintas líneas de la editorial, qué información

se debe mostrar de cada una de ellas, y cómo se quiere mostrar.

Establecer requisitos para el alta, campos, baja, modificaciones y consulta de

publicaciones, teniendo en cuenta aspectos de accesibilidad.

Estudiar el impacto de la migración de la información y cómo se puede realizar.

Revisar la accesibilidad del resultado final.

Venta de publicaciones

La editorial de esta Fundación distribuye sus publicaciones a librerías externas que utiliza

como puntos de venta. Por el perfil de estas publicaciones se distribuyen pocos números y

por tanto, sería muy conveniente poder venderlos a través de la propia editorial. De esta

manera, cuando un usuario consulta un libro y está interesado en conseguirlo, no tendría

por qué volverlo a buscar en otro sitio externo para comprarlo. Además, también se quiere

poder hacer descuentos sobre los precios habituales de determinados artículos con motivo

de conmemoraciones o de la feria del libro.

La implementación de este tipo de servicios en línea, una tienda virtual, es un trabajo

costoso. Cuando se buscó el gestor de contenidos se tuvo en cuenta esta posibilidad y se

comprobó que la implementación de este servicio sería posible de una manera poco

tediosa. Drupal proporciona un módulo externo llamado Ubercart [Ubercart, 2011] que

permite la implementación de este servicio en el sitio web.

Ubercart es un módulo complejo, cuya configuración no es obvia y sus características de

accesibilidad y usabilidad no son del todo buenas. Por tanto, aunque la implementación

básica esté hecha, su adaptación al sitio no será fácil.

Archivo histórico

Esta Fundación posee uno de los fondos de archivo más grandes de España y mucho de su

contenido está digitalizado y disponible para su consulta si se visita. Para evitar a los



usuarios interesados tener que desplazarse para hacer determinadas consultas, se decidió

poner a disposición de éstos parte de los fondos más demandados disponibles mediante

consultas web. Esta iniciativa se comenzó en el sitio web antiguo y su resultado final no

fue todo lo útil que se esperaba. El fracaso de esta iniciativa no fue porque la idea no fuese

buena, sino porque el diseño, la usabilidad y la accesibilidad no ayudaban a los usuarios a

utilizarlo.

A fecha de hoy, en el nuevo sitio web se realizan búsquedas de términos relacionados con

el fondo del archivo. Estos términos representan más del 50% del total de las búsquedas

que se realizan y no están devolviendo resultado porque no está implementado. Por ello,

una línea de trabajo sería recuperar esa consulta web en el nuevo sitio.

Para llevar a cabo la implementación de este servicio, es necesario tener en cuenta los

siguientes puntos:

Impacto de la integración de este servicio en el gestor de contenidos actual. El

tamaño de la información es tal, que podría dejar al servidor actual sin espacio,

podría ralentizar al gestor con las consultas y podría superar los límites de

descarga contratados. Por tanto, sería una opción a considerar externalizarlo

físicamente, pero manteniendo aspectos sobre usabilidad relacionados con la

imagen corporativa, localización y orientación del usuario.

Conocer cómo se estructura la información y qué relación existe entre ella, qué

información se debe y quiere mostrar de cada una de ellas, y cómo se quiere

mostrar.

Establecer los requisitos funcionales y no funcionales.

Estudiar el impacto de la migración de la información y cómo se puede realizar.

Revisar la accesibilidad del resultado final.

Hay que tener en cuenta que la información que se va a mostrar está digitalizada, por tanto

la accesibilidad de la misma puede presentar ciertos problemas. Habría que pensar en

alternativas para solucionar estos casos.

6.2. Mantenimiento del sitio

El sitio web corporativo descrito en este Trabajo ya está puesto en marcha. El sitio se

presentó y se lanzó a producción. Los contenidos publicados por las personas

responsables de estas tareas han hecho que la cantidad de los mismos haya crecido más

rápido de lo estimado. Se ha detectado que este contenido no siempre cumple con un

mínimo de calidad y que se publican determinados textos que se podrían omitir porque

son reiterativos. Es necesario poder garantizar un mínimo de calidad en los contenidos

que se publican, no se puede publicar cualquier cosa, ni de cualquier manera, además de

tener que garantizar la accesibilidad a los mismos por motivos de conformidad con las

WCAG.



Para que esto sea posible, se propone establecer un flujo de trabajo de manera que el

contenido pase por un revisor antes de publicarse. El revisor deberá tener conocimientos

sobre accesibilidad además de criterio para decidir qué se puede publicar y qué no. La idea

es que decida si el contenido cumple con los mínimos de calidad y con los aspectos de

accesibilidad que se le puedan aplicar –abreviaturas, enlaces en el contenido, alternativo

de la imagen principal, alternativos y títulos de las fotografías, subtitulado de vídeos,

cambios de idioma, etc.-, sabiendo que el resto de la página ya ha sido evaluada. La

decisión final sobre esta tarea compete a la Fundación, pero deberán implementar una

guía de actuación para el mantenimiento.

Para poder crear flujos de publicación en Drupal existe un módulo externo llamado Rules

[Drupal, 2011b] que en combinación con el módulo Trigger del core, permite gestionar

alertas y acciones. La idea del flujo es que el editor de contenido no tenga privilegios para

publicar contenido, y que cuando cree un nuevo contenido el revisor sea notificado por

correo electrónico para que revise el contenido. El revisor deberá leer y editar el

contenido para corregir los fallos y finalmente publicarlo. Pero si el contenido no tiene

suficiente calidad, el revisor tiene que poder descartar el contenido y el editor debe ser

notificado para que este contenido se cambie.

El flujo que se establezca no tiene por qué ser tan complejo, el revisor puede tener

capacidad para corregir por completo este contenido y publicarlo, sin necesidad de que

vuelva al editor. Lo que es obvio, tras los primeros meses publicando contenido, es que

siempre es necesaria una revisión previa a la publicación del mismo, incluso para algo tan

habitual como la ortografía.

Aun así, se debería planificar una revisión periódica con un máximo de seis meses para

revisar todas aquellas páginas que se creen nuevas desde la última revisión. Para ello,

sería necesario poder obtener un listado de los últimos contenidos creados. Además, si se

crean nuevas vistas en Drupal se debería adelantar esta revisión periódica para que se

evalúe antes de la publicación de la misma.


7. BIBLIOGRAFÍA [231]

7. BIBLIOGRAFÍA

[Adobe, 2008] Bobby van der Sluis, “Providing alternative content for SWF files”, Adobe, 2008, http://www.adobe.com/devnet/flashplayer/articles/alternative_content.html

[AENOR, 2004] AENOR, “Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos en la web”, Norma UNE 139803:2004, Madrid, diciembre 2004

[AENOR, 2003a] AENOR, “Aplicaciones informáticas para personas con discapacidad. Requisitos de

accesibilidad al ordenador. Hardware”, Norma UNE 139802:2003, Madrid, septiembre 2003

[AENOR,2003b] AENOR, “Aplicaciones informáticas para personas con discapacidad. Requisitos de

accesibilidad al ordenador. Software”, Norma UNE 139802:2003, Madrid, septiembre 2003

[Bevan et al., 1994] Bevan, N., Macleod, M., “Usability measurement in context”, 1994

[BOCG, 2001] Proposición no de ley para facilitar el acceso de las personas mayores y con

discapacidad en el portal de Internet de la Administración General del Estado, BOCG. Congreso de

los Diputados Núm. D-156 de 26/03/2001 Pág.: 28,

http://www.congreso.es/portal/page/portal/Congreso/Congreso/Iniciativas/Busqueda%20Avanz

ada?_piref73_1335465_73_1335464_1335464.next_page=/wc/servidorCGI&CMD=VERLST&BASE=

IWI7&PIECE=IWI7&FMT=INITXD1S.fmt&FORM1=INITXLTS.fmt&DOCS=2-

2&QUERY=%28I%29.ACIN1.+%26+%28PORTAL+DE+INTERNET+DE+LA+ADMINISTRACI%C3%B

3N+GENERAL+DEL+ESTADO%29.ALL.

[BOE, 2002] Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de

comercio electrónico (LSSICE), Boletín Oficial del Estado, 2002,

http://www.congreso.es/public_oficiales/L7/CONG/BOCG/A/A_068-13.PDF

[BOE, 2003] Ley 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y

accesibilidad universal de las personas con discapacidad, Boletín Oficial del Estado, 2003,

http://www.boe.es/diario_boe/txt.php?id=BOE-A-2003-22066

[BOE, 2007a] Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la

Información, BOE, 2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-22440

[BOE, 2007b] Real Decreto 1494/2007 de 12 de noviembre, por el que se aprueba el Reglamento

sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías,

productos y servicios relacionados con la sociedad de la información y medios de comunicación

social, Boletín Oficial del Estado, 2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-

19968

[BOE, 2007c] Ley 49/2007 de régimen de infracciones y sanciones en materia de igualdad de

oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad, BOE,

2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-22293

[BOE, 2007d] Ley 30/2007, de 30 de octubre de Contratos del sector público, Boletín Oficial del

Estado, 2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-18874

[BOE, 2007e] REAL DECRETO 366/2007, de 16 de marzo, por el que se establecen las condiciones

de accesibilidad y no discriminación de las personas con discapacidad en sus relaciones con la

http://www.adobe.com/devnet/flashplayer/articles/alternative_content.html

http://www.congreso.es/portal/page/portal/Congreso/Congreso/Iniciativas/Busqueda%20Avanzada?_piref73_1335465_73_1335464_1335464.next_page=/wc/servidorCGI&CMD=VERLST&BASE=IWI7&PIECE=IWI7&FMT=INITXD1S.fmt&FORM1=INITXLTS.fmt&DOCS=2-2&QUERY=%28I%29.ACIN1.+%26+%28PORTAL+DE+INTERNET+DE+LA+ADMINISTRACI%C3%B3N+GENERAL+DEL+ESTADO%29.ALL





http://www.congreso.es/public_oficiales/L7/CONG/BOCG/A/A_068-13.PDF









Administración General del Estado, BOE, 2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-

2007-6239

[BOE, 2007f] Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios

Públicos, BOE, 2007, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-12352

[BOE, 2008] Instrumento de Ratificación de la Convención de Derechos de las Personas con

Discapacidad, BOE, 2008, http://www.boe.es/diario_boe/txt.php?id=BOE-A-2008-6963

[Brown, 2006] Brown S., Web Technology Family Tree, 2006, http://modernl.com/article/web-

tech-family-tree

[Byron, 2010] Byron, A., et al., “Drupal”, Eds Anaya Multimedia, 2010

[Caldwell et al., 2008] Caldwell, B., Cooper, M., Guarino Reid, M., Vanderheiden, G. (eds), “Web

Content Accessibility Guidelines 2.0”, 2008, http://www.w3.org/TR/WCAG20/

[Chisholm et al, 1999] Chisholm, W., Vanderheiden, G., Jacobs, I. (eds), “Web Content Accesibility

Guidelines 1.0”, 1999, http://www.w3.org/TR/WCAG10/

[Chen, S. et al., 2005] Chen Y., Sherry et al., “The assessment of usability of electronic shopping: A

heuristic evaluation”, 2005, International Journal of Information Management 25,

http://www.elsevier.com/locate/ijinfomgt

[CMSMatrix, 2010] CMS Matrix, “Comparison”, 2010, http://www.cmsmatrix.org/

[Dojo, 2011] Dojo Foundation, “Dojo Toolkit”, 2011, http://dojotoolkit.org/

[Drupal, 2011a] Drupal, “Drupal concepts”, 2011, http://drupal.org/node/21951

[Drupal, 2011b] Drupal, “Rules”, 2011, http://drupal.org/project/rules [EOWG, 2008] Education

and Outreach Working Group, “Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical

Order”, 2008, http://www.w3.org/WAI/WCAG20/from10/comparison

[Fancybox, 2011] Fancybox, “Fancybox Lightbox”, 2011, http://fancybox.net/

[Flowplayer, 2011] Flowplayer, “Flowplayer – Flash video player for the web”, 2011,

http://flowplayer.org/

[González, et al., 2010] González, M., Masip, Ll., Granollers, A.,Oliva, M. , “Análisis Cuantitativo en un

Experimento de Evaluación Heurística”, http://www.aipo.es/articulos/2/28.pdf

[Google, 2011] Google, “SWFObject”, 2011, http://code.google.com/p/swfobject/

[Hartson, 1998] Hartson, H.R., “Human-computer interaction: Interdisciplinary roots and trends”,

1998, Journal of Systems and Software, Noviembre 1998, v. 43, n. 2, pp. 103-118.

[Hassan, et al, 2003a] Hassan, Y., Martín, F. J., “Qué es la Accesibilidad Web”, No Solo Usabilidad,

nº2, 2003, ISSN 1886-8592, http://www.nosolousabilidad.com/articulos/accesibilidad.htm

[Hassan, et al, 2003b] Hassan Y., Martín, F. J., “Guía de Evaluación Heurística de Sitios Web”, No Solo

Usabilidad, nº 2, 2003, ISSN 1886-8592,

http://www.nosolousabilidad.com/articulos/heuristica.htm

[Hassan, et al, 2003c] Hassan Montero, Y., Martínez Fernández, F. J., “Método de test con usuarios”,

No Solo Usabilidad, nº2, 2003, ISSN 1886-8592,

http://www.nosolousabilidad.com/articulos/test_usuarios.htm





http://modernl.com/article/web-tech-family-tree

http://modernl.com/article/web-tech-family-tree

http://www.w3.org/TR/WCAG20/

http://www.w3.org/TR/WCAG10/

http://www.elsevier.com/locate/ijinfomgt

http://www.cmsmatrix.org/

http://drupal.org/node/21951

http://drupal.org/project/rules

http://www.w3.org/WAI/WCAG20/from10/comparison

http://fancybox.net/

http://code.google.com/p/swfobject/

http://www.nosolousabilidad.com/articulos/accesibilidad.htm

http://www.nosolousabilidad.com/articulos/heuristica.htm


7. BIBLIOGRAFÍA [233]

[Hassan, et al, 2004a] Hassan, Y., Martín, F. J., “Sistemas de clasificación de información”, No Solo

Usabilidad, nº 3, 2004, ISSN 1886-8592,

http://www.nosolousabilidad.com/articulos/sistemas_clasificacion.htm

[Hassan, et al, 2004b]Hassan, Y., Martín, F. J., Ghzala Iazza, “Diseño Web Centrado en el Usuario:

Usabilidad y Arquitectura de la Información”, Hipertext.net, nº 2, 2004, ISSN 1695-5498,

http://www.hipertext.net/web/pag206.htm

[INE, 2010] Instituto Nacional de Estadística, “Encuesta de discapacidad, autonomía personal y

situación de dependencia - Tasa de población con alguna discapacidad o limitación por edad y

sexo”, 2008,

http://www.ine.es/jaxi/tabla.do?path=/t15/p418/a2008/hogares/p01/modulo1/l0/&file=02001.

px&type=pcaxis&L=0

[ISO, 1991] ISO/IEC, “Software product evaluation - Quality characteristics and guidelines for their

use”, ISO 9126, 1991

[ISO, 1998] ISO, “Ergonomic requirements for office work with visual display terminals (VDTs) -

Guidance on usability”, ISO 9241-11, 1998

[ISO, 2006] ISO, “Ergonomics of human-system interaction – Dialogue principles”, ISO 9241-110,

2006

[Juicy Studio, 2007] Juicy Studio, “Choosing an Accessible CMS”, Marzo 2007,

http://juicystudio.com/article/choosing-an-accessible-cms.php

[Lawton, 2005] Lawton Henry, S., “Introduction to Web Accessibility”, 2005,

http://www.w3.org/WAI/intro/accessibility.php

[Lawton, 2008] Lawton Henry, S., “Web Content Accessibility Guidelines (WCAG) Overview”, 2008,

http://www.w3.org/WAI/intro/wcag.php

[Lawton, 2009] Lawton Henry, S., “How WCAG 2.0 Differs from WCAG 1.0”, 2009,

http://www.w3.org/WAI/WCAG20/from10/diff.php

[Longtail, 2011] Longtail, “JW Player”, 2011, http://www.longtailvideo.com/players/jw-flv-player/

[Nielsen, J., 1994] Nielsen, J., “Ten Usability Heuristics”, 1994,

http://www.useit.com/papers/heuristic/heuristic_list.html

[Nielsen, 2000] Nielsen, J., “Designing web usability”, New riders publishing, 2000

[Nielsen, J. et al., 1990] Nielsen, Jakob, Molich, R., Heuristic evaluation of user interfaces.In the CHI

’90: Proceedings of the SIGCHI conference on Human factors in computing systems, 1990, pages

249-256, ACM Press.

[Nielsen, 2003] Nielsen, J., “Usability 101: Introduction to Usability”, 2003,

http://www.useit.com/alertbox/20030825.html

[Nielsen, J., 2005] Nielsen, Jakob, “Severity Ratings for Usability Problems”, 2005,

http://www.useit.com/papers/heuristic/severityrating.html

[Palacios et al, 2006] Palacios, A., Romañach, J., “El modelo de la diversidad: la bioética y los

derechos humanos como herramientas para alcanzar la plena dignidad en la diversidad funcional”.

Ediciones Diversitas-AIES, 2006

http://www.nosolousabilidad.com/articulos/sistemas_clasificacion.htm

http://www.hipertext.net/web/pag206.htm

http://www.ine.es/jaxi/tabla.do?path=/t15/p418/a2008/hogares/p01/modulo1/l0/&file=02001.px&type=pcaxis&L=0

http://www.ine.es/jaxi/tabla.do?path=/t15/p418/a2008/hogares/p01/modulo1/l0/&file=02001.px&type=pcaxis&L=0

http://juicystudio.com/article/choosing-an-accessible-cms.php

http://www.w3.org/WAI/intro/accessibility.php

http://www.w3.org/WAI/intro/wcag.php

http://www.w3.org/WAI/WCAG20/from10/diff.php

http://www.useit.com/papers/heuristic/heuristic_list.html

http://www.useit.com/alertbox/20030825.html

http://www.useit.com/papers/heuristic/severityrating.html



[Pérez, 2002]Pérez, C., “Análisis cualitativo y cuantitativo: herramientas para el tratamiento de los

córpora“, 2002, http://elies.rediris.es/elies18/25.html

[PHP.net, 2010] PHP.net, “¿Qué es PHP?”, 2010, http://es2.php.net/manual/es/intro-whatis.php

[Olsson, 2007] Olsson, T., O’Brien, P., “What is CSS?”, 2007, http://reference.sitepoint.com/css/css

[Romañach et al, 2005] Romañach, J., Lobato, M., “Diversidad funcional, nuevo término para la lucha

por la dignidad en la diversidad del ser humano”. Foro de Vida Independiente, mayo 2005.

Disponible en: http://www.asoc-ies.org/vidaindepen/docs/diversidad%20funcional_vf.pdf

[Sawyer, 2008] Sawyer, D., “JavaScript”, O’Reilly Media, Inc., 2008

[Sidar, 2005] Sidar, Hera, 2003 – 2005, http://www.sidar.org/hera/

[Sidar, 2008] Sidar, Legislación Española sobre Accesibilidad para la Sociedad de la Información,

2008, http://www.sidar.org/recur/direc/legis/espa.php

[Toub, 2000] Toub, S., “Evaluating Information Architecture: A Practical Guide to Assessing Web

Site Organization”, 2000, ARGUS Associates, http://argus-

acia.com/white_papers/evaluating_ia.html

[Ubercart, 2011] Ubercart, “Ubercart – The free open source e-commerce shopping cart solution”,

2011, http://www.ubercart.org/

[W3C, 1998] W3C, “Web Content Accessibility Guidelines 1.0”, 1998,

http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/

[W3C, 2002] W3C, “XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)”,

2002, http://www.w3.org/TR/2002/REC-xhtml1-20020801/#xhtml

[W3C, 2008a] W3C, “Understanding WCAG 2.0”, 2008, http://www.w3.org/TR/UNDERSTANDING-

WCAG20

[W3C, 2008c] W3C, “How to meet WCAG 2.0”, 2008, http://www.w3.org/WAI/WCAG20/quickref/

[W3C, 2008d] W3C, “Understanding Confromance”, 2008,

http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

[W3C, 2008e] W3C, “Web Content Accessibility Guidelines 2.0”, 2008,

http://www.w3.org/TR/2008/REC-WCAG20-20081211/

[W3C, 20010a] W3C, “Techniques for WCAG 2.0”, 2008, http://www.w3.org/TR/WCAG20-TECHS

[W3C, 2010b] W3C, HTML & CSS, 2010, http://www.w3.org/standards/webdesign/htmlcss

[W3C, 2011] W3C, “WAI Mission and Organization”, marzo 2011, http://

www.w3.org/WAI/about.html

[WAC, 2011] Web Accessibility Center – The Ohio State University, “Accessible web video”, 2011,

http://wac.osu.edu/examples/jwpc/

[WAI, 2011] Web Accessibility Iniciative, “WAI-ARIA Overview”, 2011,

http://www.w3.org/WAI/intro/aria.php

[WebAIM, 2009] Web Accessibility in Mind, “Survey of preferences of Screen Readers Users”, 2009,

http://webaim.org/projects/screenreadersurvey/

http://elies.rediris.es/elies18/25.html

http://es2.php.net/manual/es/intro-whatis.php

http://reference.sitepoint.com/css/css

http://www.asoc-ies.org/vidaindepen/docs/diversidad%20funcional_vf.pdf

http://www.sidar.org/hera/

http://www.sidar.org/recur/direc/legis/espa.php

http://argus-acia.com/white_papers/evaluating_ia.html

http://argus-acia.com/white_papers/evaluating_ia.html

http://www.w3.org/TR/2002/REC-xhtml1-20020801/#xhtml

http://www.w3.org/TR/UNDERSTANDING-WCAG20

http://www.w3.org/TR/UNDERSTANDING-WCAG20

http://www.w3.org/WAI/WCAG20/quickref/

http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

http://www.w3.org/TR/2008/REC-WCAG20-20081211/

http://www.w3.org/TR/WCAG20-TECHS

http://www.w3.org/standards/webdesign/htmlcss

http://www.w3.org/WAI/about.html

http://wac.osu.edu/examples/jwpc/

http://webaim.org/projects/screenreadersurvey/


ANEXO A [235]

A. Anexo

A.1. INTRODUCCIÓN

En este anexo se recoge la evaluación heurística realizada al antiguo sitio web con las

conclusiones obtenidas mediante un análisis cuantitativo de la misma.

La evaluación heurística se ha llevado a cabo por el personal del departamento de

informática de la empresa y se han tenido en cuenta los factores de frecuencia e impacto

para valorar la severidad de cada heurística. Las heurísticas se han agrupado en cuatro

grupos con un conjunto de heurísticas cada uno de ellos.

Esta evaluación está basada en el artículo “Análisis Cuantitativo en un Experimento de

Evaluación Heurística” de González, M. et al. que a su vez está basado en el proyecto de la

Iniciativa UsabAIPO. Las diferencias principales con estos dos proyectos es que no se han

tomado tantas funciones estadísticas para medir la usabilidad del sitio web, ya que sólo se

recogen los porcentajes globales y el estudio que se busca es más global y no tan

específico.

A.2. HEURÍSTICAS

En la Tabla 25 se muestran las subheurísticas que se han usado para evaluar cada uno de

los grupos.

Estas heurísticas se han creado tomando como referencia varias listas de comprobación de

heurísticas propuestas por varios autores. [Chen, et al, 2005], [Hassan, et al, 2003b] y

[Nielsen, 1994].

Diseño de la interfaz

H1. Claridad de los objetivos

¿Cumple el sitio con sus objetivos?

¿Los contenidos y servicios que ofrece se corresponden con esos objetivos?

¿El look & feel general se corresponde con los objetivos, características, contenidos y servicios del sitio web?

¿Tiene el sitio una interfaz amigable, con colores que concuerden con los objetivos y propósitos del sitio?

H2. Visibilidad del estado del sistema

¿Se informa constantemente al usuario acerca de lo que está pasando?

¿Se informa al usuario de lo que ha pasado?

¿Se ha controlado el tiempo de respuesta?



H3. Control y libertad para el usuario

¿Facilita que el usuario se sienta cómodo y con el control del sitio?

¿Tiene el usuario todo el control sobre el interfaz?

¿Posee el usuario libertad para actuar?

¿La tecnología utilizada en el sitio es compatible con el software y hardware de los usuarios objetivos? ¿No tendrán que descargar elementos como complementos (plugins) para poder usarlo?

Si es importante utilizar recursos técnicos que requieran la descarga de complementos, ¿se le informa al usuario de esta situación y se le explica la importancia de hacerlo?

¿Se ha controlado que no haya páginas "huérfanas"?

¿Es predecible la respuesta del sistema antes de hacer clic sobre el enlace?

¿Se proporciona información sobre la protección de datos de carácter personal de los clientes o los derechos de autor de los contenidos del sitio web?

¿Puede el usuario ponerse en contacto para hacer sugerencias comentarios?

H4. Reconocimiento más que memoria

¿Existen elementos que permitan al usuario saber exactamente dónde se encuentra dentro del sitio y cómo volver atrás?

¿Indican los enlaces claramente hacia dónde apuntan? ¿Está claro lo que el usuario encontrará detrás de cada uno?

Los rótulos, ¿son significativos?

¿Usa rótulos estándar?

¿Utiliza un sistema de rotulado controlado y preciso?

El título de las páginas, ¿Es correcto? ¿Ha sido planificado?

En menús de navegación, ¿Se ha controlado el número de elementos y de términos por elemento para no producir sobrecarga memorística?

¿Se ha evitado la sobrecarga informativa?

H5. Branding

¿Muestra la página de inicio la naturaleza del negocio?

¿Aparece la marca en un lugar importante dentro de la página?

¿Se muestra claramente la identidad de la empresa-sitio a través de todas las páginas?

El Logotipo, ¿es significativo?

El Logotipo, ¿identificable y suficientemente visible?

¿Se ofrece algún enlace con información sobre la empresa, sitio web, contacto con el administrador,...?

¿Se proporciona mecanismos para ponerse en contacto con la empresa? (email, teléfono, dirección postal, fax...)

Navegación simple

H6. Consistencia y estándares

¿Mantiene una coherencia en su apariencia?

¿Mantiene una consistencia en su funcionamiento?

¿Es reconocible el diseño general del sitio web?

¿Se mantiene una navegación consistente y coherente a lo largo del sitio?

¿Los enlaces son fácilmente reconocibles como tales? ¿su caracterización indica su estado (visitados, activos,...)?

H7. Flexibilidad y eficiencia de uso

¿Tiene una URL correcta, clara y fácil de recordar?

Y las URL de sus páginas internas, ¿Son claras y permanentes?

¿Se ha controlado que no aparezcan enlaces rotos?

¿Tiene el sitio un mapa del sitio o un buscador para quienes quieren acceder directamente a los contenidos sin tener que navegar?

H8. Diálogos estéticos y diseño minimalista


ANEXO A [237]

¿Aparece la navegación en un lugar prominente, donde se vea fácilmente?

Las imágenes que son enlaces, ¿se reconocen como elementos en los que se puede hacer clic?

¿Los enlaces que son imágenes tienen su atributo ALT escrito describiendo la página de destino?

Si ha usado JavaScript para la navegación ¿ha preparado también una navegación alternativa para el modo texto?

¿El sitio web se actualiza periódicamente?

¿Indica cuándo se actualiza?

¿Se ve el sitio exactamente igual en todos los navegadores?

¿Se aprovechan las zonas de alta jerarquía informativa de la página para contenidos de mayor relevancia?

¿Existen zonas en "blanco" entre los objetos informativos de la página para poder descansar la vista?

¿Se hace un uso correcto del espacio visual de la página?

¿Se utiliza correctamente la jerarquía visual para expresar las relaciones del tipo "parte de" entre los elementos de la página?

¿Se ha controlado la longitud de página?

Organización de los contenidos

H9. Adecuación al mundo y a los objetos mentales del usuario / lógica de la

información

¿El sitio web habla el mismo lenguaje que sus usuarios?

¿Emplea un lenguaje claro y conciso?

¿Es amigable, familiar y cercano?

¿Es coherente el contenido con el contexto de la página o sitio?

¿La redacción es corta y precisa?

¿Existen referencias cruzadas entre textos que están relacionados?

Cuando se produce un error, ¿se informa de forma clara y no alarmista al usuario de lo ocurrido y de cómo solucionar el problema?

¿Muestra de forma precisa y completa qué contenidos o servicios ofrece realmente el sitio web?

H10 Arquitectura de la información

¿Usa un único sistema de organización, bien definido y claro?

¿La estructura general del sitio web está orientada al usuario?

H11. Imágenes y animaciones

¿Se han optimizado las imágenes para reducir el tamaño?

¿Tienen las imágenes que lo requieran una descripción mediante el atributo ALT?

¿Las fotografías están bien recortadas? ¿son comprensibles? ¿se ha cuidado su resolución?

¿El uso de imágenes o animaciones proporciona algún tipo de valor añadido?

Funcionalidades diversas

H12. Prevenir errores

¿Se han previsto respuestas del sistema frente a interacciones del usuario?

H13. Ayuda

En enlace a la sección de Ayuda, ¿Está colocado en una zona visible y "estándar"?

¿Se ofrece ayuda contextual en tareas complejas? (transferencias bancarias, formularios de registro...)

H14. Búsqueda



¿Se encuentra fácilmente accesible?

¿Es fácilmente reconocible como tal?

¿Permite la búsqueda avanzada?

¿Muestra los resultados de la búsqueda de forma comprensible para el usuario?

¿La caja de texto es lo suficientemente ancha?

¿Asiste al usuario en caso de no poder ofrecer resultados para una consultada dada?

Tabla 25: Lista de heurísticas

A.3. Evaluación heurística

En la Tabla 26 aparece el total de subheurísticas de cada grupo y cuánto representa cada

una de ellas sobre el total. Con estos datos se puede saber cuánto representa cada uno de

ellos en la usabilidad global de la página.

Grupo

Total subheurísticas

Porcentaje


31 41,33%

H1. Claridad de los objetivos 4

H2. Visibilidad del estado del sistema 3

H3. Control y libertad para el usuario 9

H4. Reconocimiento más que memoria 8

H5. Branding 7

Navegación simple

21 28,00%

H6. Consistencia y estándares 5

H7. Flexibilidad y eficiencia de uso 4

H8. Diálogos estéticos y diseño minimalista 12


14 18,67%

H9. Adecuación al mundo y a los objetos mentales del usuario / lógica de la información

8

H10. Arquitectura de la información 2

H11. Imágenes y animaciones 4


9 12,00%

H12. Prevenir de errores 1

H13. Ayuda 2

H14. Búsqueda 6

Total 75 75 100,00%

Tabla 26: Total de subheurísticas y porcentaje representativo de cada grupo

En la Tabla 27 el resultado global de la evaluación según los tres evaluadores para los

factores de frecuencia e impacto, siendo la frecuencia de ocurrencia del error y el impacto,

lo fácil o difícil que puede ser superar el error por un usuario.



ANEXO A [239]

H1. Claridad de los objetivos

Cuestión Frec Imp Observaciones

¿Cumple el sitio con sus objetivos? 0 0

¿Los contenidos y servicios que ofrece se corresponden con esos objetivos? 3 3

No se proporcionan todos los servicios esperados, ya que no se pueden subir más vídeos que los que aparecen en la página de inicio.

¿El look & feel general se corresponde con los objetivos, características, contenidos y servicios del sitio web?

0 0

Por ejemplo, los colores empleados. Aunque el significado que comunica un determinado color es muy subjetivo y dependiente de la cultura y el entorno, y por lo tanto diferente para cada usuario, ciertas combinaciones de colores ofrecen una imagen más o menos formal, seria o profesional, como pueden ser los tonos de azules con el blanco, que trasmiten una imagen corporativista.

¿Tiene el sitio una interfaz amigable, con colores que concuerden con los objetivos y propósitos del sitio?

0 0

H2. Visibilidad del estado del sistema

¿Se informa constantemente al usuario acerca de lo que está pasando?

0 0

¿Se informa al usuario de lo que ha pasado?

0 0

¿Se ha controlado el tiempo de respuesta?

0 0

H3. Control y libertad para el usuario

¿Facilita que el usuario se sienta cómodo?

3 4

Aparecen nuevas ventanas para cada contenido que se visita de la página principal. Existe un vídeo que se repite y no tiene controles para pararlo o pausarlo. Además, las ventanas que se abren para ver los contenidos anulan la barra de navegación del navegador.

¿Tiene el usuario todo el control sobre el interfaz?

3 4 Se debe evitar el uso de ventanas pop-up, ventanas que se abren a pantalla completa, banners intrusivos... Ventanas emergentes, un reproductor que no se puede parar, etc.

¿Posee el usuario libertad para actuar? 4 4

Se debe evitar restringir la libertad del usuario: Evite el uso de animaciones que no pueden ser "saltadas", páginas en las que desaparecen los botones de navegación del browser, no impida al usuario poder usar el botón derecho de su ratón...

¿La tecnología utilizada en el sitio es compatible con el software y hardware de los usuarios objetivos? ¿No tendrán que descargar elementos como plugins para poder usarlo?

0 0

Se tendrán que descargar el plugin para la los pocos vídeos y no tendrán otra alternativa si quieren verlo. Tendrán que tener un navegador moderno que incorpore tecnología JavaScript para poder navegar por la página, ya que todos los enlaces dependen de la misma.

Si es importante utilizar recursos técnicos que requieran la descarga de plugins, ¿se le informa al usuario de esta situación y se le explica la importancia de hacerlo?

0 0

¿Se ha controlado que no haya páginas "huérfanas"?

3 4

Páginas huérfanas: que aún siendo enlazadas desde otras páginas, éstas no enlacen con ninguna. Todas las ventanas que se abren son huérfanas ya que no poseen la navegación de la página y por tanto no enlazan a ningún otro sitio.



¿Es predecible la respuesta del sistema antes de hacer clic sobre el enlace?

3 3

Ningún enlace de la página está marcado como enlace que abre una ventana nueva y hay gran número de este tipo de enlaces. Los enlaces que abren documentos no te dicen el formato del documento que se va a abrir o el tamaño del mismo, ni que se va a cargar una ventana nueva.

¿Se proporciona información sobre la protección de datos de carácter personal de los clientes o los derechos de autor de los contenidos del sitio web?

1 2 Existe un formulario para suscribirse a una lista de distribución y en ningún momento se le informa al usuario de qué se va a hacer con esos datos.

¿Puede el usuario ponerse en contacto para hacer sugerencias comentarios?

2 2 La página de contacto sólo tiene la dirección y el mapa.

H4. Reconocimiento más que memoria

¿Existen elementos que permitan al usuario saber exactamente dónde se encuentra dentro del sitio y cómo volver atrás?

4 4 Existe un breadcrumb pero no es correcto todas las veces que se genera.

¿Indican los enlaces claramente hacia dónde apuntan? ¿Está claro lo que el usuario encontrará detrás de cada uno?

3 3 Existen enlaces que se repiten como “Fundación” que no indican lo que se va a encontrar la segunda vez.

Los rótulos, ¿son significativos? 4 3

No proporcionan información significativa de lo que representan. Por ejemplo “Datos del evento” se podría eliminar y titular la información con el propio título de la actividad que es la información que se está mostrando.

¿Usa rótulos estándar? 0 0 Siempre que exista un "estándar" comúnmente aceptado para el caso concreto, como "Mapa del Sitio" o "Acerca de...".

¿Utiliza un sistema de rotulado controlado y preciso?

4 3

Por ejemplo, si un enlace tiene el rótulo "Quiénes somos", no puede dirigir a una página cuyo encabezamiento sea "Acerca de", o un enlace con el rótulo "Ayuda" no puede dirigir a una página encabezada con "FAQs”.

El título de las páginas, ¿es correcto? ¿Ha sido planificado?

4 3 Las páginas carecen de título por lo que se acceda a donde sea siempre se está en la página de inicio.

En menús de navegación, ¿se ha controlado el número de elementos y de términos por elemento para no producir sobrecarga memorística?

2 4

No se deben superar los 7±2 elementos, ni los 2 o, como mucho, 3 términos por elemento. Existe una página en la que se cargan 16 elementos en forma de botón a tres columnas que se puede observar en la Figura 1.

¿Se ha evitado la sobrecarga informativa?

2 1

Esto se consigue haciendo un uso correcto de colores, efectos tipográficos y agrupaciones para discriminar información. Al igual que en los elementos de un menú de navegación, los grupos diferentes de objetos informativos de una página, no deberán superar el número 7±2.

H5. Branding

¿Muestra la página de inicio la naturaleza del negocio?

0 0

¿Aparece la marca en un lugar importante dentro de la página?

0 0

¿Se muestra claramente la identidad de la empresa-sitio a través de todas las páginas?

4 3

Las ventanas emergentes no presentan una maquetación similar a la del sitio web. Entre los elementos que se pierden está el logotipo, el menú de navegación del sitio web, o la maquetación global a dos columnas.

El Logotipo, ¿es significativo? 1 1 No tiene ningún significado con respecto a la actividad o valores de la empresa.


ANEXO A [241]

El Logotipo, ¿identificable y suficientemente visible?

0 0

¿Se ofrece algún enlace con información sobre la empresa, sitio web, o contacto con el administrador',...?

0 0

¿Se proporciona mecanismos para ponerse en contacto con la empresa? (email, teléfono, dirección postal, fax...)

0 0

Navegación simple

H6. Consistencia y estándares

¿Mantiene una coherencia en su apariencia?

4 4

Se debe mantener una coherencia y uniformidad en las estructuras y colores de todas las páginas. Esto sirve para que el usuario no se desoriente en su navegación. Los enlaces no son representados siempre de la misma manera (colores, subrayados, etc.). Existen pestañas de navegación con el mismo nombre que llevan a distintos sitios. Se estilizan los rótulos a modo de botón cuando elementos de navegación están identificados así.

¿Mantiene una consistencia en su funcionamiento?

0 0

¿Es reconocible el diseño general del sitio web?

4 4

Cuánto más se parezca el sitio web al resto de sitios web, más fácil será de usar. El estilo de navegación es completamente atípico. Se utilizan botones de formulario para navegar, pestañas o enlaces dependiendo de dónde se sitúen las barras de navegación.

¿Se mantiene una navegación consistente y coherente a lo largo del sitio?

4 4

La navegación cada vez presenta un estilo: enlaces simples, botones o pestañas. Cada vez aparece en una zona de la página, no manteniendo si quiera una consistencia del estilo en función de la zona. Es decir, cuando aparece la navegación superior no siempre se cargan primero pestañas y luego botones, a veces se cargan primero botones y no se cargan nunca pestañas. Las ventanas nuevas carecen de la navegación del sitio web.

¿Los enlaces son fácilmente reconocibles como tales? ¿Su caracterización indica su estado (visitados, activos,...)?

4 3

Los enlaces no sólo deben reconocerse como tales, sino que su caracterización debe indicar su estado (para orientar al usuario), y ser reconocidos como una unidad (enlaces que ocupan más de una línea). Existen enlaces en forma de botón, enlaces resaltados en

color rojo (Figura 11), otros en color rojo subrayado (Figura 71), enlaces azules (Figura 14) e incluso enlaces que no están resaltados de ninguna forma como los que aparecen en la Figura 1.

H7. Flexibilidad y eficiencia de uso

¿Tiene una URL correcta, clara y fácil de recordar?

0 0

Y las URL de sus páginas internas, ¿Son claras y permanentes?

4 3

Las ventanas que se abren en la página de inicio presentan una dirección con una consulta como la que aparece a continuación: http://subdomino.dominio.es/nombrefundacion/abreviatura/evento.jsp?accion=leer&clase=es.dominio.acrónimo.estr



uctura.Evento&cod_evento=333&emergente=true No son permanentes ya que abusa de frames y los contenidos que no se lanzan en ventana nueva presentan la misma dirección que la de inicio. Por tanto, no se puede guardar en favoritos ni refrescar la página.

¿Se ha controlado que no aparezcan enlaces rotos?

2 3

Enlaces que no llevan a ningún sitio: Los enlaces rotos, y los que enlazan con la misma página que se está visualizando (por ejemplo enlaces a la "home" desde la misma página de inicio). En la Figura 1 se puede ver que existen explícitamente marcados como tal enlaces que no llevan a ningún sitio. Además, la página de inicio tiene un enlace a sí misma.

¿Tiene el sitio un mapa del sitio o un buscador para quienes quieren acceder directamente a los contenidos sin tener que navegar?

4 3

No presenta buscador global para el sitio. El mapa web no es correcto, ya que los enlaces de segundo nivel de algunos elementos del menú no aparecen listados cuando en realidad existen.

H8. Diálogos estéticos y diseño minimalista

¿Aparece la navegación en un lugar prominente, donde se vea fácilmente?

0 0

Las imágenes que son enlaces, ¿se reconocen como elementos en los que se puede hacer clic?

4 3 Existen imágenes a modo de botón para los rótulos de los eventos, pero no se puede hacer clic sobre ellas porque no son enlacesson clicables.

¿Los enlaces que son imágenes tienen su atributo ALT escrito describiendo la página de destino?

4 3

La navegación por pestañas de la Figura 8 (del documento principal) es una imagen cuyo ALT presenta la misma información para todas ellas “enviarConsulta”. Otras navegaciones por pestañas de la página no presentan ni siquiera esta información.

Si ha usado JavaScript para la navegación ¿ha preparado también una navegación alternativa para el modo texto?

4 4 Todos los enlaces del sitio web dependen de JavaScript por lo que no es posible navegar por ella si se carece de la tecnología.

¿El sitio web se actualiza periódicamente?

0 0

¿Indica cuándo se actualiza? 3 3

Las fechas que se muestren en la página deben corresponderse con actualizaciones, noticias, eventos...no con la fecha del sistema del usuario. No se muestra ninguna temporalidad en ninguna página del sitio web.

¿Se ve el sitio exactamente igual en todos los navegadores?

0 0

¿Se aprovechan las zonas de alta jerarquía informativa de la página para contenidos de mayor relevancia?

3 3 La zona de mayor jerarquía se usa para un contenido que no cambia nunca y se pospone otra información más relevante al final de la página inicial.

¿Existen zonas en "blanco" entre los objetos informativos de la página para poder descansar la vista?

0 0

¿Se hace un uso correcto del espacio visual de la página?

3 3

Es decir, que no se desaproveche demasiado espacio con elementos de decoración, o grandes zonas en "blanco", y que no se adjudique demasiado espacio a elementos de menor importancia. La página tiene un diseño fijo de 800x600, lo que quiere decir que ahora mismo para pantallas con resoluciones


ANEXO A [243]

superiores (1024x768 o 1280x720) se ve gran cantidad de color sólido sin información. Además, con el diseño de la navegación se desaprovecha casi el 50% del total de la zona principal de la página.

¿Se utiliza correctamente la jerarquía visual para expresar las relaciones del tipo "parte de" entre los elementos de la página?

0 0

¿Se ha controlado la longitud de página?

4 3

Se debe evitar en la medida de lo posible el scrolling. Si la página es muy extensa, se debe fraccionar. Se ha hecho tan pequeña que se ha creado un scroll vertical interno al del navegador provocando que éste sea demasiado extenso en algunos casos


H9. Adecuación al mundo y a los objetos mentales del usuario / lógica de la

información

¿El sitio web habla el mismo lenguaje que sus usuarios?

0 0

Se debe evitar usar un lenguaje corporativista. Así mismo, hay que prestarle especial atención al idioma, y ofrecer versiones del sitio en diferentes idiomas cuando sea necesario.

¿Emplea un lenguaje claro y conciso? 4 3

Los párrafos están titulados con textos ambiguos y poco explicativos. Por ejemplo en las figuras 10 y 11 (del documento principal) se puede observar que el título de la página de un evento es “Datos del evento”, uno de los contenidos está rotulado como “Datos”, otro como “Tipo Evento”, etc.

¿Es amigable, familiar y cercano? 0 0 Es decir, lo contrario a utilizar un lenguaje constantemente imperativo, mensajes crípticos, o tratar con "desprecio" al usuario.

¿Es coherente el contenido con el contexto de la página o sitio?

0 0

¿La redacción es corta y precisa? 0 0

¿Existen referencias cruzadas entre textos que están relacionados?

3 2 No es posible relacionar catálogos con exposiciones, o libros de textos de ponencias con sus conferencias.

Cuando se produce un error, ¿se informa de forma clara y no alarmista al usuario de lo ocurrido y de cómo solucionar el problema?

0 0

¿Muestra de forma precisa y completa qué contenidos o servicios ofrece realmente el sitio web?

2 3

Esto está relacionado directamente con el diseño de la página de inicio, que debe ser diferente al resto de páginas y cumplir la función de 'escaparate' del sitio. No hay forma de saber que se venden libros o revistas, ya que no se anuncia ni la publicación de los mismos en la página de inicio.

H10. Arquitectura de la información

¿Usa un único sistema de organización, bien definido y claro?

2 3

No se deben mezclar sistemas de organización diferentes. Los diferentes sistemas de organización son básicamente: alfabético, geográfico, cronológico, temático, orientado a tareas, orientado al público y orientado a metáforas.



¿La estructura general del sitio web está orientada al usuario?

3 3

Los sitios web deben estructurarse pensando en el usuario, sus objetivos y necesidades. No se debe calcar la estructura interna de la empresa u organización, al usuario no le interesa cómo funciona o se organiza la empresa. El contenido está claramente organizado según clasifica la fundación sus actividades. Esto se puede comprobar cuando se visitan las áreas temáticas en las que centra su trabajo y se obtienes 16 temas que trata y dentro de cada uno de ellos se pueden encontrar conferencias, mesas redondas, seminarios, exposiciones, jornadas, etc.

H11. Imágenes y animaciones

¿Se han optimizado las imágenes para reducir el tamaño?

0 0

¿Tienen las imágenes que lo requieran una descripción mediante el atributo ALT?

4 2 Todas las imágenes del sitio web carecen de atributos ALT.

¿Las fotografías están bien recortadas? ¿son comprensibles? ¿se ha cuidado su resolución?

0 0

¿El uso de imágenes o animaciones proporciona algún tipo de valor añadido?

1 2 Son siempre los mismos vídeos y no se actualizan a los nuevos editados por la editorial. Se deberían evitar las animaciones cíclicas a menos que tengan un propósito claro.


H12. Prevenir de errores

¿Se han previsto respuestas del sistema frente a interacciones del usuario?

0 0

H13. Ayuda

En enlace a la sección de Ayuda, ¿Está colocado en una zona visible y "estándar"?

3 3

Dadas las dificultades que presenta la página para la navegación y encontrar determinada información debería ser necesaria una ayuda que explique la categorización del menú y la organización de los contenidos en el sitio web. Del mismo modo, sería necesario proporcionar ayuda para las consultas del archivo.

¿Se ofrece ayuda contextual en tareas complejas? (transferencias bancarias, formularios de registro...)

3 2 En la tienda virtual no se ofrece ayuda adicional al usuario para seguir los pasos de la compra.

H14. Búsqueda

¿Se encuentra fácilmente accesible? 3 3

Directamente desde la página de inicio, y a ser posible desde todas las páginas del sitio, y colocado en la zona superior de la página. El buscador está presente en las páginas del archivo histórico solamente

¿Es fácilmente reconocible como tal? 0 0

¿Permite la búsqueda avanzada? 2 4 La búsqueda no funciona y no permite la búsqueda avanzada, ya que da un mensaje de error.

¿Muestra los resultados de la búsqueda de forma comprensible para el usuario?

0 0 El mensaje de error se entiende correctamente. El servicio está temporalmente fuera de servicio.


ANEXO A [245]

¿La caja de texto es lo suficientemente ancha?

2 2

¿Asiste al usuario en caso de no poder ofrecer resultados para una consultada dada?

3 3

La búsqueda es demasiado compleja, es necesario conocer demasiados datos de los que se está buscando para poder llevar a cabo la misma (ver Figura 3). El buscador no funciona, nunca devuelve ningún resultado y sólo dice: “No se ha podido realizar la búsqueda. Por favor, inténtelo más tarde”.

Tabla 27: Datos de la evaluación según frecuencia e impacto

Figura 70: Enlaces sin estilo

Figura 71: Enlaces rotos y marcados en color rojo subrayado



Figura 72: Buscador del archivo de carteles habiendo seleccionado la Guerra Civil

Documents

Desarrollo de un sitio web corporativo accesible …oa.upm.es/9304/1/PFC_MARIA_PINTO_MARTIN.pdf · UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA Desarrollo de un sitio