Tip:
Highlight text to annotate it
X
Hola, soy Sergio Luján Mora, profesor de la Universidad de Alicante,
y esta es la segunda parte del videotutorial
sobre la accesibilidad de la página web del Senado.
En este videotutorial vamos a realizar un análisis rápido
de la accesibilidad de la página web del Senado de España,
vamos a ver los graves problemas que presenta
y al final veremos que no debería tener ningún problema
porque tienen la obligación legal de ofrecer una página web accesible.
Por tanto, el Senado incumple las mismas leyes que ellos crean.
O como dice el refranero español, haz lo que digo, pero no lo que hago.
Lo primero que podemos hacer es comprobar
la validez de los lenguajes de marcado de la página.
Para ello, me voy a ir a la página principal del World Wide Web Consortium, del W3C,
el organismo internacional que desarrolla los estándares de la Web.
En esta página web podemos encontrar un servicio,
el “HTML and markup validator”,
que me permite validar, comprobar el lenguaje HTML
que emplea cualquier página web que esté publicada en Internet.
Introduzco la URL de la página del Senado,
le doy al botón “chequear”
y en el resultado del análisis me dice que el documento no puede ser chequeado,
no puede ser validado.
Y si vamos al final del informe,
veremos que la razón es que se está empleando una declaración de documento,
un DOCTYPE incorrecto.
Si no nos queda claro el informe de este validador,
podemos usar otro.
Por ejemplo el del Web Design Group
que lo encontraremos en la página web www.htmlhelp.com.
En esta página del Web Design Group
encontramos otro validador de HTML,
su funcionamiento es similar,
introducimos la dirección de la página web del Senado,
le damos al botón “validar”.
Y en el informe nos dice que hay unas serie de errores y advertencias.
Y en concreto nos está diciendo
que hay un error porque el DOCTYPE empleado no se reconoce.
Más adelante,
cuando veamos el código fuente de la página web del Senado
entenderemos cuál es la causa de este error.
Lo siguiente que podemos hacer
es emplear una herramienta de análisis automático
de la accesibilidad de una página web, como puede ser el TAW.
Me voy a la página de TAW, que es tawdis.net.
Antes de continuar me gustaría remarcar que
las herramientas automáticas de evaluación de la accesibilidad web,
como por ejemplo TAW,
nos ayudan a tener una primera impresión de la accesibilidad de una página web,
pero no proporcionan un análisis definitivo.
Solamente un análisis manual por parte de un experto
puede ofrecer un análisis completo y fiable de la accesibilidad web de una página.
Para realizar el análisis,
primero tenemos que seleccionar el nivel del análisis,
voy a seleccionar el nivel triple A, el nivel máximo,
que significa que quiero que se analicen todos los puntos de verificación.
E introduzco la URL de la página web del Senado,
le doy al botón de “analizar”.
Y en el informe del análisis
vemos que efectivamente la página contiene numerosos errores.
Nos sale un informe detallado con los problemas encontrados en la página.
En la parte superior nos sale esta tabla resumen
y podemos ver para cada uno de los niveles de prioridad
de los puntos de verificación,
podemos ver el número de errores automáticos
y el número de errores manuales que se han encontrado.
Puede parecer que la página tiene pocos errores,
pero ello es debido a que la página que estamos analizando es la página inicial,
la que define la estructura de la página mediante marcos,
y esta página pues tiene poco contenido.
Vamos a analizar la accesibilidad de una página que ya tiene contenido,
que es la que se llama “home_9.html”.
Así que nos vamos hacia atrás
y le digo que me analice la página “home_9.html”
y veremos que esta ya tiene muchos más errores.
Como vemos,
esta sí que es realmente la página con el contenido
y el informe es más largo y el número de errores automáticos y manuales,
pues es mucho mayor.
La accesibilidad es un tema muy complejo,
y una herramienta automática como el TAW
nos puede ayudar, pero como he dicho no es fiable,
no es la solución definitiva.
Para hacer un buen análisis de una página web necesitamos más ayuda.
El W3C, el World Wide Web Consortium,
tiene un grupo de trabajo que desarrolla pautas
para hacer páginas web accesibles.
Estando en la página principal del W3C,
nos vamos al apartado “Accessibility”,
y llegamos al “Web Accessibility Initiative”,
que es el grupo de trabajo del W3C para la accesibilidad web.
En el apartado “Guidelines & Techniques”
tenemos acceso a toda la documentación que desarrollan.
En concreto, lo que yo voy a usar
se encuentra en el apartado “Web Content”
y en concreto voy a usar
el “Web Content Accessibility Guidelines 1.0”.
La versión 1.0, que es de 5 de mayo del año 99.
Voy a usar esta versión porque las leyes españolas
son las que marcan que hay que emplear lo que indican estas pautas.
Estas pautas las podemos encontrar traducidas al castellano.
Es muy fácil, nos vamos a un buscador como Google
y le digo que busque “pautas de accesibilidad al contenido en la web”,
“Web Content Accessibility Guidelines”.
Y en la página de resultado lo que voy a utilizar
es el tercer resultado que me lleva a una página de discapnet.es.
Y aquí tenemos las Pautas de Accesibilidad al Contenido en la Web 1.0
que ahora usaré.
En la primera parte de este análisis,
en la primera parte de este videotutorial,
se comentó que ofrecer una versión de sólo texto de una página web
era una mala idea y estaba desaconsejado.
Volviendo a este tema,
¿por qué no es una buena idea ofrecer una versión de sólo texto?
Para ello nos vamos a las Pautas de Accesibilidad al Contenido en la Web,
y en concreto vamos a consultar la pauta número 11
que nos dice “Utilice las tecnologías y pautas W3C”.
Y dentro de esta pauta encontramos
el punto de verificación 11.4 que nos dice
“Si, después de los mayores esfuerzos no puede crear una página accesible,
proporcione un vínculo a una página alternativa que use tecnologías W3C,
sea accesible, tenga información (o funcionalidad) equivalente
y sea actualizada tan a menudo como la página (original) inaccesible”.
Como vemos, el ofrecer una página alternativa,
el ofrecer una versión de sólo texto,
hay que hacerlo después de los mayores esfuerzos,
cuando no queda otra solución,
y es imposible hacer la página web normal accesible.
Y ese no es el caso,
esta página web se podría hacer muy fácilmente accesible.
Así que, lo de ofrecer una versión de sólo texto, sobra.
Veamos el código fuente de esta página.
Nos vamos a la opción “Ver código fuente de la página”
y a ver lo que encontramos.
El primer problema que encontramos es el DOCTYPE,
que nos salía cuando realizábamos un análisis con las herramientas de validación.
El problema está en que en el DOCTYPE,
se emplea un DOCTYPE, un DTD, no estándar.
Este DTD no está reconocido, no es estándar.
En concreto es un DTD que usaba este programa, el HotMetal PRO,
que era un programa de edición de páginas web
muy famoso a finales de los años 90,
pero que hoy está totalmente en desuso.
Otro problema que podemos ver,
que no afecta a la accesibilidad en sí,
pero que es importante no cometer este problema
es que se escriben etiquetas y atributos, como podemos ver,
en mayúsculas y en minúsculas.
Hay que intentar escribir el código de forma homogénea,
o todo en mayúscula o todo en minúscula.
Además, también podemos ver que las líneas
se cortan con saltos de línea de forma arbitraria
y se han dejado muchas líneas en blanco.
Otro problema importante de la página
es que no se establece un juego de caracteres,
lo cual puede ocasionar graves problemas de visualización.
Y también hay un problema importante,
que este sí que afecta a la accesibilidad directamente,
y es que no se identifica el idioma principal de la página.
Sí que hay una etiqueta, esta etiqueta hace referencia al idioma,
“language content” español, “es”,
pero esta no es la forma estándar de hacerlo.
Si nos vamos a las Pautas de Accesibilidad al Contenido en la Web,
en concreto a la pauta número 4,
nos dice “Identifique el idioma usado”.
Vamos a ver esta pauta.
Y en concreto lo que nos interesa es el punto de verificación 4.3
que dice “Identifique el idioma principal de un documento”.
¿Cómo se hace?
Si leemos a continuación nos dice
“Por ejemplo, en HTML, coloque el atributo lang en el elemento HTML”.
Es decir, en el código fuente se debería de haber indicado aquí,
en la etiqueta mediante el atributo lang,
se debería de haber indicado que el idioma de la página es el español.
Otro problema de accesibilidad,
y este también sí que es importante es que la página está definida mediante marcos,
una forma de crear páginas web que puede causar numerosos problemas de accesibilidad.
La pauta número 12 nos indica la razón de ello
y nos indica también la solución.
Nos vamos a la pauta número 12
“Proporcione información de contexto y orientación”.
Y en concreto nos interesan los puntos de verificación 12.1 y 12.2.
El 12.1 dice
“Titule cada marco para facilitar su identificación y navegación”.
Y nos dice que hay que utilizar el atributo “title” en los elementos FRAME.
Y luego, el punto de verificación 12.2 nos dice
“Describa el propósito de los marcos y como éstos
se relacionan entre sí,
si no resulta obvio solamente con el título del marco”.
Y nos dice que utilicemos el atributo “longdesc”.
Si volvemos al código fuente de la página del Senado
vemos que no se está empleando en ningún momento
ni el atributo “title” ni el atributo “longdesc”.
No hay ninguna orientación sobre el uso,
el significado de cada uno de los marcos de la página.
Y por ejemplo,
una persona ciega podría tener graves problemas de accesibilidad
en esta página.
Otra cosa curiosa que podemos ver aquí
es que se han dejado esta etiqueta vacía.
En una página web sólo puede haber una etiqueta inicial ,
esta que vemos aquí.
Esta que aparece al final habría que quitarla.
Pero sin duda,
el problema de accesibilidad principal
que presenta la página web del Senado
es que está toda ella formada por imágenes.
Estos textos que vemos aquí,
o estos textos que vemos aquí,
realmente no son textos, son imágenes que contienen los textos.
Y si por ejemplo,
desactivamos las imágenes de la página,
vemos que cambia completamente la página,
ha desaparecido mucho contenido.
Y una persona ciega tendría graves problemas para navegar por la página.
El World Wide Web Consortium nos indica
en sus Pautas de accesibilidad al contenido en la Web,
en concreto en la pauta número 1
“Proporcione alternativas equivalentes para el contenido visual y auditivo”,
nos indica que tenemos que emplear el atributo “alt”
para los elementos de tipo IMG, INPUT y APPLET,
o para las distintas áreas de un mapa de imágenes
para proporcionar una alternativa textual a las imágenes.
Y esto, como vamos a ver a continuación,
no se ha hecho.
Si nos vamos a la página web del Senado,
le damos a “Ver código fuente del marco”,
veremos como en las imágenes y en los mapas de imágenes,
a ver por aquí, en estas áreas de aquí,
pues no se ha definido un texto alternativo.
Sin embargo, de forma curiosa sí que hay algunas áreas
en las que sí que se define el texto alternativo.
En concreto, para esta barra de navegación
que tiene la página web,
vamos a activar las imágenes,
en concreto para esta zona de aquí
sí que se han definido los textos alternativos,
pero para el resto de las imágenes no se ha hecho.
Bastante curioso.
Y otro problema que tiene la página
es que se emplean tablas para la maquetación.
Eso lo vemos de la siguiente forma,
le voy a decir que me resalte las celdas de la tabla
y vemos como la página está dividida en dos celdas,
en dos columnas.
Esto tampoco hay que hacerlo.
Si nos vamos a las Pautas de Accesibilidad al Contenido en la Web
en concreto a la pauta número 5
“Cree tablas que se transformen correctamente”
y el punto de verificación 5.3 nos dice
“No utilice tablas para maquetar,
a menos que la tabla tenga sentido cuando se alinee”.
Por último, vamos a navegar por varias de las páginas web
del sitio web del Senado y vemos por ejemplo aquí la página del Saludo del Presidente.
Vemos que aparece esta barra de navegación.
Nos vamos a otra página, como por ejemplo a Novedades.
Aquí no aparece para nada la barra de navegación.
Y ahora, por ejemplo,
nos vamos a la Sala de Prensa y vemos como cambia absolutamente
el estilo de la página, no hay ninguna coherencia entre cada una de estas páginas.
Esto también es un error, y nos lo indica el W3C.
Por último,
los principales problemas que afectan a la accesibilidad
de la página web del Senado son:
La utilización de una “versión de sólo texto”.
El empleo de código HTML no estándar.
La ausencia del juego de caracteres.
La ausencia del idioma principal en la página.
El empleo de marcos.
La utilización de imágenes y mapas de imagen sin el atributo alt.
Y la maquetación de la página con tablas.
Y por último la ausencia de mecanismos de navegación coherentes.
Con esto finalizo esta parte de este videotutorial.
Si quieres más información o quieres contactar conmigo,
aquí tienes los datos de contacto.