Accesibilidad portales públicos Colombia

Accesibilidad en los portales de la
administración pública en Colombia, 2008
PEC1 presentado a la docente Mª Soledad Clemente Izquierdo
en el Módulo “Evaluación de la Accesibilidad Web”

Analista: Mario Carvajal

Universitat Oberta de Catalunya (UOC)
Máster en Tecnologías Accesibles para la Sociedad de la Información
Abril de 2008

Tabla de contenido

ADMINISTRACIÓN
1. SECTOR: LA ADMINISTRACIÓN PÚBLICA EN COLOMBIA 5

PORTALES
2. PORTALES 6

PORTAL 1: PRESIDENCIA DE LA REPÚBLICA DE C OLOMBIA 7
A) MUESTRA 7
B) JUSTIFICACIÓN DE LA MUESTRA 7
C) TABLA DE ELEMENTOS USADOS 7
D) VALORACIÓN DE ACCESIBILIDAD 8
PORTAL 2: MINISTERIO DE C OMUNICACIONES 19
A) MUESTRA 19
D) VALORACIÓN DE ACCESIBILIDAD 20
PORTAL 3: C IUDAD DE BOGOTÁ 34
A) MUESTRA 34
PORTAL 4: SECRETARÍA DISTRITAL DE GOBIERNO 35
A) MUESTRA 35
PORTAL 5: INSTITUTO N ACIONAL DE C IEGOS (INCI) 36
A) MUESTRA 36

3. CONCLUSIONES 37

PRESIDENCIA DE LA REPÚBLICA 37
MINISTERIO DE C OMUNICACIONES 38

2

C IUDAD DE BOGOTÁ 38
SECRETARÍA DE GOBIERNO DE BOGOTÁ 39
INSTITUTO N ACIONAL DE C IEGOS (INCI) 39

3

Introducción

Hemos visto durante este módulo un modelo metodológico para la evaluación de la accesibilidad
Web, ayudado por técnicas automáticas, manuales y pruebas de usuario. Ahora se trata de llevar la
teoría a la práctica y para ello se realiza el presente análisis.

Y aunque el objetivo sea evidentemente practicar sobre cómo realizar una muestra para un análisis
sectorial y luego cómo analizar las muestras según pautas fijadas en el enunciado, me parece que
el análisis puede servir para empezar a esbozar un panorama del estado actual de los portales Web
de la administración pública en Colombia, a la altura de 2008. Muy incipiente, tal vez, pero
empezamos por algo ¿verdad?

Bien, pues se trata entonces de tomar del sector elegido (yo lo elegí y en la parte de Justificación
explico claramente por qué) cinco portales Web y de cada uno seleccionar cuatro páginas internas
de muestra.

Se seleccionan dos de los cinco sitios para hacerles un análisis de cada uno de los siguientes
aspectos: imágenes, encabezados, listas, formularios, tablas de datos, maquetación y JavaScript. El
análisis debe tener en cuenta la prioridad 1 y 2 (la Prioridad 3 no aplica para este análisis).

Hubiera querido realizar el análisis completo de los cinco portales seleccionados, pero por razones
de tiempo no ha sido posible. Sin embargo, en la sección final de Conclusiones hago un esbozo
general tanto de los dos sitios analizados, como de los tres restantes.

Y ahora, empecemos con el análisis.

MARIO CARVAJAL
Bogotá, mayo de 2008

4

1. Sector: la administración pública en Colombia

Hemos seleccionado para el presente análisis de accesibilidad, el sector de la administración
pública en Colombia Me ha parecido interesante abordar este segmento porque el pasado 14 de
Colombia
ia.
abril de 2008, el Gobierno Nacional expidió el Decreto 1151 que establece los lineamientos
generales de la Estrategia Gobierno en Línea, de obligatorio cumplimiento para las entidades del
orden nacional y territorial.

Este decreto, establece en su artículo 6º que el Ministerio de Comunicaciones, a través de la Agenda
de Conectividad, expedirá el “Manual para la implementación de la Estrategia de Gobierno en
Línea”.

Aunque este manual se encuentra al día de hoy en un proceso de borrador, ya deja ver entre líneas
algunos aspectos de accesibilidad. Por ello, me atrevería a pronosticar que el documento final
contemplará las 14 pautas de accesibilidad de la WCAG.

Estos antecedentes nos sitúan en un momento coyuntural, muy importante para la accesibilidad
Web en Colombia. Así que empecemos por definir los portales a analizar.

5

2. Portales

En Colombia, la administración pública tiene entidades del orden territorial y del orden nacional. En
la siguiente muestra hemos querido dejar representadas cinco importantes entidades (tres del
orden nacional y dos del orden territorial). Son los siguientes:

Presidencia de la República Ministerio de Comunicaciones

Ciudad de Bogotá Secretaría Distrital de Gobierno

Instituto Nacional de Ciegos (INCI)

6

Portal 1: Presidencia de la República de Colombia

La Presidencia de la República máxima autoridad de Colombia, firmó el
República,
Decreto 1151 de Gobierno en Línea (abril de 2008). Creemos que este portal
debería ser el ejemplo a seguir para el resto de entidades, y por ello cobra vital
importancia para nuestro análisis de accesibilidad.

a) Muestra

1. Página de inicio: http://web.presidencia.gov.co/

2. Mapa del sitio: http://web.presidencia.gov.co/m_sitio/index.htm

3. Contacto: http://syscopre.presidencia.gov.co/publico/frmCiudadano.aspx

4. Comunicados de prensa: http://web.presidencia.gov.co/comunicados/

b) Justificación de la muestra

Aunque el portal Web de la Presidencia de Colombia puede llegar a las cien mil páginas Web
(según resultados a través de Google), una muestra de cuatro páginas puede ser muy
representativa de la totalidad del sitio, por cuanto hemos detectado que se repiten los mismos
errores en todas las páginas que hemos navegado manualmente (cerca de cien).

Por ejemplo, no encontramos ninguna página con uso de encabezados, tampoco con un correcto
marcado de listas. Todas las páginas están maquetadas en tablas y usan JavaScript, así que
consideramos que la muestra anterior constituye una visión general y aproximada del nivel de
accesibilidad del portal.

Por último, hemos seleccionamos como página libre, la de Comunicados de Prensa, por su
importancia dentro del sitio Web.

c) Tabla de elementos usados

La siguiente tabla representa aquellos elementos usados o no en cada una de las muestras:

Imágenes Encabezados Listas Formularios Tablas de datos Tablas de formato JavaScript

1 Sí No No Sí Sí Tablas Sí

7


2 Sí No No No No Tablas Sí
3 Sí No No Sí No Tablas Sí

d) Valoración de accesibilidad

Imágenes

Gracias a la herramienta de validación automática HERA, se detectaron cerca del 40% de imágenes
sin texto alternativo (incumplimiento punto 1.1)1. Y aunque muchas de estas corresponden a
imágenes meramente decorativas, es preocupante ver que el menú principal queda totalmente
invisible cuando un usuario deshabilite las imágenes en su navegador. Este grave error ocurre en las
cuatro páginas de muestra. Observemos:

Figura 1.1: Detalle del encabezado del portal de la Presidencia, basa su sistema de navegación en imágenes.
1.1:

Figura 1.2: El mismo detalle de la figura anterior, pero en un navegador con las imágenes
1.2:
deshabilitadas. Nótese cómo todo el sistema de navegación queda perdido

1
Punto 1.1: “Proporcione un texto equivalente para todo elemento no textual (p. ej. a través de "alt", "longdesc" o en el
1.1:
contenido del elemento)”. (Prioridad 1)

8

Además del error del menú principal, encontramos cerca de un 50% de las áreas de mapa de
imagen, sin texto alternativo (incumplimiento punto 1.1) en las cuatro páginas de muestra. Veamos:

Figura 1.3: Esta imagen tiene un mapa en el código fuente que habilita los hipervínculos para las tres
1.3:
diferentes entrevistas. Desafortunadamente ninguna de esas áreas posee texto alternativo.

Encabezados

El sitio Web de la Presidencia de la República no usa un solo encabezado (h1, h2, h3, h4, h5, h6), en
ninguna de las cuatro páginas de muestra (incumplimiento punto 3.5)1. Aunque nos pareció
inaudito, buscamos manualmente en más de cincuenta páginas, pero tampoco encontramos un
marcado estructural coherente. Esta búsqueda fue fácilmente realizada mediante la barra de
herramientas AIS.

Por ejemplo, en una página interna como la de presentación del señor Presidente, se usan
imágenes (sin el atributo “alt”), en vez de encabezados (incumplimiento punto 3.1)2. Veamos:

1
Punto 3.5: “Use elementos de encabezado para sugerir la estructura del documento y úselos siguiendo la especificación”.
(Prioridad 2)
2
Punto 3.1: “Utilice marcadores en vez de imágenes para transmitir información, si existe un lenguaje de marcado
apropiado”. (Prioridad 2)

9

Figura 1.4. Imágenes (sin atributo “alt”) ejercen la función de encabezados. Mala práctica.
1.4.

Figura 1.5: Suponiendo que el encabezado de primer nivel (h1) sea el título del sitio Web “Presidencia de la República
1.5:
de Colombia”, debería marcarse según el anterior esquema. Y por supuesto, para lograr los mismos efectos de diseño,
basta tan solo con unas cuantas líneas de CSS

Listas

En ninguna de las páginas de muestra pudimos encontrar una lista ordenada (ol), desordenada
(ul) o de definición (dl). Buscamos en una cantidad razonable de páginas internas (cerca de
cincuenta), y tampoco hallamos el uso de una sola lista (incumplimiento punto 3.6)1. Esta búsqueda
fue sencilla gracias a la barra de herramientas AIS, de Internet Explorer.

1
Punto 3.6: “Marque correctamente las listas y los ítem de lista”. (Prioridad 2)

10

A pesar de no tener una sola lista, detectamos que en realidad sí existen listas, pero marcadas
erróneamente, como tablas (incumplimiento punto 3.3 y 5.3)1. Se evidencia entonces una
equivocada concepción del marcado HTML, por cuanto se usa no con fines de dar significado, sino
con fines puramente de diseño gráfico, sin recurrir a agrupamientos naturales (incumplimiento
punto 12.3)2. Veamos:

Figura 1.6: Una lista encontrada en la página de inicio. Hemos dibujado en rojo las etiquetas que
1.6:
actualmente marcan la supuesta lista, todas pertenecientes a <td>, propias de una tabla.

Figura 1.7: representamos en verde las etiquetas que deberían usar, para marcar semánticamente el listado. Todos los
1.7:
efectos de diseño, pueden ser logrados (y de mejor forma) a través de unas sencillas reglas estilísticas de CSS.

1
Punto 3.3: “Use hojas de estilo para controlar la disposición y la presentación”. (Prioridad 2)
Punto 5.3: “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)”. (Prioridad 2)
2
Punto 12.3: “Divida los bloques de información largos en grupos más manejables cuando resulte natural y apropiado”.
(Prioridad 2)

11

Formularios

El formulario analizado fue el del “Contacto con el Presidente” (página 3 de la muestra), a través de
la herramienta TAW y HERA. Además de la decisión errada de lanzar el formulario en una nueva
ventana, sin los usuales controles de navegador (incumplimiento 10.1)1, encontramos errores como:

• Los manejadores de evento están basados únicamente en el dispositivo de ratón, y no
tienen en cuenta la posibilidad de teclado (incumplimiento puntos 8.1, 6.4 y 9.3)2.

• Hay 11 controles de formulario, pero no tienen asociado el elemento “label”
(incumplimiento punto 10.2)3.

• No asociar explícitamente ningún control de formulario a etiquetas, en ninguno de los
campos, a través del atributo “for” y el atributo “id” (incumplimiento punto 12.4)4.

• Hay campos de formulario que dependen de JavaScript para activarse, tales como
“Municipio” o “Subtema” (incumplimiento punto 6.3)5.

1
Punto 10.1: “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”. (Prioridad 2)
2
Punto 8.1: “Cree los elementos de programación tales como scripts y applets de manera que sean directamente
accesibles o compatibles con las ayudas técnicas”. (Prioridad 1 si la funcionalidad es importante y no se presentó en otra
parte; en otro caso, Prioridad 2)
Punto 6.4: “Para los scripts y applets, asegúrese de que la ejecución de los manejadores de evento sea independiente del
tipo de dispositivo”. (Este punto incluye el 9.3). (Prioridad 2)
Punto 9.3: “Para los scripts, especifique manejadores de evento lógicos en vez de manejadores de evento dependientes
del dispositivo”. (Prioridad 2)

3
Punto 10.2: “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.” (Prioridad 2)

4
Punto 12.4: “Asocie etiquetas explícitamente con sus controles”. (Prioridad 2)

5
Punto 6.3: “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”. (Prioridad 1)

12

• No agrupar en bloques de información, a través de la etiqueta “fieldset”, a pesar de que
el formulario así lo requiere.

• Maquetar el formulario con tablas (incumplimiento punto 5.3)1.

En conclusión, el formulario de contacto con el Presidente no es accesible en ninguno de los
niveles de conformidad (A, AA, AAA). Así se muestra a través de la herramienta de evaluación
automática HERA.

Figura 1.8: Catorce errores automáticos detectados por la herramienta HERA
1.8:

Tablas de datos

Analizamos la única página de la muestra (página 1) que tenía una tabla de datos. Se trata de los
indicadores económicos que aparecen en la página de inicio del portal de la Presidencia de la
República. Errores encontrados:

• No tiene encabezados que identifiquen claramente el contenido de los datos
(incumplimiento punto 5.1)2

• Utiliza atributos desaconsejados en HTML 4.01 (incumplimiento 11.2)3, por ejemplo <table
width="195" border="1" align="center" bordercolor="#FFFFFF">

1
2
Punto 5.1: “En las tablas de datos, identifique los encabezados de fila y columna”. (Prioridad 1)
3
Punto 11.2: “Evite características desaconsejadas por las tecnologías W3C” (Prioridad 2)

13

Figura 1.9: Tabla de indicadores económicos que aparece en la página de inicio. No es accesible.
1.9:

Tablas de formato

Uno de los mayores errores del sitio Web de la Presidencia de la República de Colombia, consiste en
la maquetación basada en un complejo y anidado grupo de tablas. Por ejemplo, en la página de
inicio podemos llegar a tener 20 tablas cuya única función es tan solo la de maquetar, es decir,
ubicar los diversos elementos que componen la página Web (incumplimiento punto 5.3)1.

Esta cantidad tan exagerada de tablas, lleva a una recarga de código innecesario, que hace la carga
de cada página más lenta. El diseño gráfico hubiera sido posible de realizarlo en su totalidad bajo
maquetación CSS, separando el contenido de la presentación.

Un ejemplo muy claro del incorrecto uso de tablas para maquetar, lo encontramos en el siguiente
fragmento:

Figura 1.10: El diseñador del sitio Web de la Presidencia, recurre a tablas para maquetar este grupo de logotipos.
1.10:

Para ubicar los cinco logotipos anteriores, horizontalmente, uno tras de otro, el diseñador recurre a
tablas de maquetación, con más de 22 líneas de código. Veamos:

1

14

Figura 1.11: El código fuente usado para tan simple propósito (22 líneas de código, 1345 caracteres)
1.11:

Si al código anterior le quitáramos todas las etiquetas de tabulación, el resultado se reduciría de 22
a 5 líneas de código. Esto proporciona tiempos de carga más veloces, pero sobre todo un código
más limpio y accesible. Veamos:

Figura 1.12: Eliminando la tabla del código fuente, hemos reducido a tan solo cinco líneas
1.12:

El ejemplo anterior es tan solo una pequeña muestra del incorrecto uso de tablas en el sitio Web de
la Presidencia de la República. Si este mismo ejercicio se aplicara para las restantes 19 tablas de
maquetación, el resultado sería, indiscutiblemente, un portal Web más liviano y accesible.

JavaScript

Se usa recurrentemente JavaScript en las cuatro páginas de muestra. Observemos:

• Para activar el menú desplegable. Todo el sistema de navegación está basado en
desplegable.
JavaScript que activa y despliega un menú, por cada uno de los temas. Al realizar una
sencilla prueba con la barra del Web Developer de Firefox, deshabilitando todos los

15

JavaScripts, el sitio queda sin posibilidad de navegación, ya que no existen elementos
noscript que habiliten el contenido cuando el usuario haya deshabilitado o no tenga la
posibilidad de JavaScript en su computador.

Figura 1.13: Ejemplo del menú desplegable, activado mediante JavaScript
1.13:

Figura 1.14; El mismo menú anterior, pero con el JavaScript deshabilitado. ¿El
1.14;
problema? Pues que el menú no aparece por ninguna parte y el usuario queda sin
ninguna posibilidad de navegación

• Para abrir ventanas emergentes sin barra de navegador. Se usa un JavaScript en el
navegador.
momento de hacer clic en el vínculo “Escríbale al Presidente”. ¿Para qué un JavaScript aquí?
El diseñador seguramente lo ha puesto para abrir una nueva ventana, ocultándole al
usuario elementos propios de la interfaz del navegador, tales como los botones (Atrás,
Adelante, Refrescar, Favoritos), la barra de dirección, y todas las barras que usualmente
tenemos en el navegador. De hecho, esto es un error desde el punto de vista de la
usabilidad, pero es más grave, si se tiene en cuenta que al tener deshabilitado el JavaScript,
no se abriría ninguna ventana.

Figura 1.15: Botón “Escríbale al Presidente” que se activa únicamente a través de un JavaScript
1.15:

• Para imprimir la fecha y hora. En el encabezado se imprime la fecha y hora, a partir de un
hora.
JavaScript que toma la fecha y hora de la máquina del usuario. En realidad, no hay mucha
relevancia en esta información, así que si no aparece (al tener deshabilitado el JavaScript)
no habrá un efecto tan dañino.

Figura 1.16: Fecha que se imprime a partir de un JavaScript, tomando como
1.16:
referencia la fecha y hora del computador del usuario

16

• Para cambiar las imágenes del encabezado. Todas las páginas de la muestra tienen un
encabezado.
encabezado compuesto por una imagen que cambia aleatoriamente a partir de un
JavaScript. Cuando un usuario no tiene activado JavaScript en su navegador, simplemente
no aparecen las imágenes, y en cambio aparece el espacio en blanco. La única afectación,
aparte de la estética, es que se pierde el hipervínculo que cada encabezado tiene, y que
apunta a información especial.

Figura 1.17: Diferentes encabezados que son activados aleatoriamente a través de un JavaScript
1.17:

• Para validar el formulario de contacto. En la página de contacto el formulario es validado
contacto.
a través de JavaScript, antes de enviarse los datos al servidor. Esto permite que aquellos
campos considerados como obligatorios, no pasen en blanco (otro tema será que no existe
ningún tipo de información al usuario sobre qué campos son o no obligatorios). Hemos
probado desactivando JavaScript, pero de todas formas el formulario sigue siendo validado,
por lo que este JavaScript no tiene implicación en la accesibilidad del formulario.

17

Figura 1.18: Detalle del formulario cuando se intenta enviar sin rellenar los campos obligatorios.
1.18:
Aparecen entonces unos asteriscos rojos que hacen suponer al usuario que debe llenarlos. Sin
embargo, falla de usabilidad, es que estos asteriscos no señalen la obligatoriedad desde el principio.

• Para activar campos de formulario. Dos listas desplegables del formulario de contacto son
activadas a través de JavaScript. Se trata de “Municipio” que se activa cuando se selecciona
“Departamento”, y “Subtema” que se activa al seleccionar “Tema”. Realizamos la prueba
desactivando JavaScript a través de Web Developer y a pesar de seleccionar un
departamento, no se cargó la lista de municipios. Igual ocurrió con temas y subtemas.

Figura 1.19: Detalle del formulario de contacto con el Presidente: cuando está desactivado el
1.19:
JavaScript, no cargan dos listados desplegables.

18

Portal 2: Ministerio de Comunicaciones

Continuamos, en escala jerárquica, con el Ministerio de Comunicaciones
Comunicaciones,
entidad que tendrá la responsabilidad de expedir el Manual de Políticas y
Estándares, a más tardar el 14 de junio de 2008. Esta es una muy buena razón
para que el ente responsable de definir estas políticas cumpla con las pautas
de accesibilidad de la WCAG.

a) Muestra

1. Página de inicio: http://www.mincomunicaciones.gov.co/mincom/src/index.jsp

2. Mapa del sitio: http://www.mincomunicaciones.gov.co/mincom/src/index.jsp?page=mapa

3. Contacto:
http://www.mincomunicaciones.gov.co/mincom/src/index.jsp?page=./mods/queja/queja_
cliente&id=0&state=I

4. Eventos:
http://www.mincomunicaciones.gov.co/mincom/src/index.jsp?page=./mods/agenda/even
t_user_list


El portal del Ministerio de Comunicaciones tiene, según búsqueda de Google, poco más de
cincuenta mil páginas. Notamos, después de una navegación manual que todas se rigen por la
misma plantilla, así que la selección de las cuatro páginas de muestra puede representar el nivel de
accesibilidad del portal entero.

Son reiteradas las veces que se repiten los mismos errores. Por ejemplo, no encontramos en
ninguna de las páginas internas que visitamos manualmente, un solo elemento de encabezado (h1
– h6), tampoco listas de ningún tipo (ordenadas, desordenadas o descriptivas).

Seleccionamos como página libre, la de Eventos porque contenía un elemento importante a
Eventos,
evaluar: las tablas de datos.

19


Para el presente análisis hemos seleccionado siete elementos, y su respectivo cumplimiento en los
puntos de verificación para la prioridad 1 y 2 de la WGAC. La siguiente tabla representa la existencia
o no de estos siete elementos en las páginas de muestra:



d) Valoración de accesibilidad

Imágenes

Parece inverosímil: en ninguna de las páginas de muestra del portal del Ministerio de
Comunicaciones existe tan siquiera una sola imagen con texto alternativo (incumplimiento punto
1.1)1. Esto lo detectamos gracias a la herramienta Web Developer, al activar la opción que muestra
los atributos alt. Con la misma herramienta desactivamos las imágenes y el resultado fue poco
más que desolador. Veamos:

11

20

Figura XX: Comparación del sitio Web del Ministerio de Comunicaciones visto
con imágenes activadas (izquierda) y con las imágenes deshabilitadas (derecha).

La imagen anterior (obtenida de forma completa a través del complemento ScreenGrab! de
Firefox) nos permite ver que una buena pare de la navegación del sitio (encabezado, columna
derecha y pie de página), quedan inutilizables si un visitante deshabilita las imágenes (por ejemplo
en casos donde tenga que aligerar la conexión, por ser muy lenta) o para usuarios que necesitan de
lector de pantalla que les describa el contenido de la imagen.

Grave error el del portal del Ministerio: no usar atributo alt en elementos tan trascendentales
como los menús y botones de navegación. Inclusive el botón “Ir” que habilita las búsquedas
internas (hubiera sido preferible etiquetarlo como “buscar”) es una imagen sin texto alternativo. Así
que las búsquedas no se entenderían, para cierto grupo poblacional. Veamos:

Figura XX: El botón que activa las búsquedas (etiquetado como “ir”) también es una imagen, como
observamos a la izquierda. A la derecha lo vemos, cuando están deshabilitadas las imágenes

Apartándonos del error de no contar con texto alternativo en las imágenes, se usa un mapa de
imagen que tampoco tiene texto alternativo en las diversas áreas (incumplimiento punto 1.1).
Veamos:

21

Figura XX : En el pie de página hay una franja con diversos logotipos, que corresponden a una sola imagen. Esta
XX:
imagen tiene un mapa de áreas que se activan con el fin de tener hipervínculos hacia cada uno de los sitios Web
correspondientes. Cada área debería contar con un texto alternativo, pero no lo tiene.

Encabezados

Los encabezados son un aspecto de marcado de mucha importancia en una página Web, ya que
identifican con claridad la estructura de un documento. Además, le permiten a usuarios con
discapacidad visual, detectar cómo está estructurada la página, sin tener necesidad de “escucharla”
en su totalidad.

Desafortunadamente el portal del Ministerio de Comunicaciones no utiliza un solo encabezado (h1,
h2, h3, h4, h5, h6), en ninguna de las cuatro páginas de muestra (incumplimiento punto 3.5)1.
Pudimos constatar este hecho además de las cuatro páginas de muestra, en otras tantas más que
navegamos dentro del mismo sitio, en Internet Explorer con la herramienta AIS.

En la página interna de la Dirección de Acceso y Desarrollo Social el marcado utilizado se aleja por
completo del concepto de marcado semántico (etiquetar según el significado) y al parecer el
diseñador opta por un errado concepto de marcado visual (etiquetar según el diseño). Eso sin
hablar de profundos errores de validación, como tener duplicada la etiqueta body, o usar etiquetas
en desuso como la etiqueta b (en realidad debería ser strong). En la siguiente figura hemos
querido destacar el incorrecto marcado:

1
Punto 3.5: “Use elementos de encabezado para sugerir la estructura del documento y úselos siguiendo la especificación”.
(Prioridad 2)

22

.

Figura XX: Mala práctica de marcado, según la disposición visual. Nótese inclusive el uso de
etiquetas no recomendadas por el estándar HTML del W3C.

Figura XX: Un marcado con más sentido: eliminamos el doble título, y al título de la página
Web le asignamos un encabezado de segundo nivel (considerando que el encabezado de
primer nivel sea el título del sitio Web). Luego, los subtítulos tendrán encabezado de tercer
nivel, y el párrafo, pues será etiquetado como tal.

23

Listas

No encontramos en el portal del Ministerio de Comunicaciones una lista ordenada (ol),
desordenada (ul) o de definición (dl). Buscamos en una cantidad razonable de páginas internas
(cerca de cincuenta), y tampoco hallamos el uso de una sola lista (incumplimiento punto 3.6)1. Esta
búsqueda fue sencilla gracias a la barra de herramientas AIS, de Internet Explorer.

Sin embargo, hay elementos que deberían estar marcados como listas, pero que por
desconocimiento son marcados como tablas, con el objetivo de controlar la presentación
(incumplimiento punto 3.3 y 5.3)2. Hay, por lo tanto, un evidente error de conceptualización del
marcado HTML, por cuanto se usa no con fines de dar significado, sino con fines puramente de
diseño gráfico, sin recurrir a agrupamientos naturales (incumplimiento punto 12.3)3. Observemos
un ejemplo:

Figura XX : Buscamos en páginas distintas a la muestra y encontramos en la página de Tipos de
XX:
Trámites lo que en realidad podría ser una lista, pero maquetada con etiquetas de tabla.

1
Punto 3.6: “Marque correctamente las listas y los ítem de lista”. (Prioridad 2)
2
Punto 3.3: “Use hojas de estilo para controlar la disposición y la presentación”. (Prioridad 2)
3
Punto 12.3: “Divida los bloques de información largos en grupos más manejables cuando resulte natural y apropiado”.
(Prioridad 2)

24

Figura XX: Un correcto marcado implicaría generar una lista de definición (dl), y marcar los términos (dt) y las
XX:
definiciones (dd) como tal. Este sería un marcado correcto de lista.

Formularios

Analizamos a fondo la página de “Contáctenos”, que en realidad nos lleva a un formulario llamado
PQR, que por contexto deducimos significa “Peticiones, Quejas y Reclamos”. Aparte del incorrecto
uso de título (un tema más de usabilidad que de accesibilidad), y de no explicar mediante la
etiqueta acronym el significado de esta sigla (incumplimiento a prioridad 3, que en este ejercicio
no estamos evaluando) notamos que para llegar al primer cajón del formulario sin el ratón,
únicamente con la tecla TAB del teclado, es necesario teclear 37 veces y pasar por todo el menú. No
existe un atajo para llegar al contenido directamente.

Bien, ahora sí, observemos cómo el formulario de contacto del Ministerio con sus usuarios incumple
con las pautas de accesibilidad de la Prioridad 1 y 2.

El texto de los botones “Aceptar” y “Cancelar” (deberían llamarse “Enviar” y “Borrar”
respectivamente), no cumple con el suficiente contraste de brillo y color exigido por la WGAC

25

(incumplimiento 2.2)1. Esta prueba la realizamos a través del software libre Colour Contrast Analyzer,
y el resultado de analizar el color de la letra (#777) contra el color de fondo (#AFDEEE) fue de una
diferencia de color de 278 (lo mínimo es 500) y una diferencia en brillo entre los dos colores de 90,
(lo mínimo es 125). Observemos:

Figura XX: Botones de envío y borrado de formulario de contacto,
que no cumplen con el mínimo contraste de brillo y color

Los manejadores de evento están basados únicamente en el dispositivo de ratón, y no tienen en
cuenta la posibilidad de teclado (incumplimiento puntos 8.1, 6.4 y 9.3)2. Esto sucede, por ejemplo
en el botón que despliega una nueva ventana, donde se selecciona el tipo de servicio. Observemos
el código fuente:

<a href="javascript://"><img width="16" height="16" border="0"
onclick="WindowPopup('/mincom/src/com/Window/wlist.jsp?tag=queja&form=for
m1&name=id_servicio&search_label=nombre&selValues=',350,450);"
alt="Presione para escoger opción"
src="/mincom/src/images/flecha.gif"/></a>

En rojo y negrita hemos resaltado del código anterior el manejador de evento que se basa
únicamente en el clic del ratón (onclick), cuando debería haber redundancia para personas que no
usen ratón, solamente teclado.

Figura XX: El botón con la flecha diagonal contiene un manejador de evento que se basa únicamente en el ratón

1
Punto 2.2: 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. (Prioridad
2 para imágenes, 3 para textos)
2
Punto 8.1: “Cree los elementos de programación tales como scripts y applets de manera que sean directamente
accesibles o compatibles con las ayudas técnicas”. (Prioridad 1 si la funcionalidad es importante y no se presentó en otra
parte; en otro caso, Prioridad 2)
Punto 6.4: “Para los scripts y applets, asegúrese de que la ejecución de los manejadores de evento sea independiente del
tipo de dispositivo”. (Este punto incluye el 9.3). (Prioridad 2)
Punto 9.3: “Para los scripts, especifique manejadores de evento lógicos en vez de manejadores de evento dependientes
del dispositivo”. (Prioridad 2)

26

Por otra parte, notamos que hay 12 controles de formulario que no tienen asociado el elemento
“label” (incumplimiento punto 10.2)1. Además no se asocia explícitamente ningún control de
formulario a etiquetas, en ninguno de los campos, a través del atributo “for” y el atributo “id”
(incumplimiento punto 12.4)2. Y aunque este tema será tratado en la sección de JavaScript,
debemos señalar que hay campos de formulario que dependen de JavaScript para activarse, tales
como “Tipo de servicio”, “Departamento” o “Ciudad” (incumplimiento punto 6.3)3.

En cuanto a la maquetación del formulario, se han utilizado tablas (incumplimiento punto 5.3)4.
Además, no se agrupan bloques de información, a través de la etiqueta “fieldset”, a pesar de que
el formulario así lo requiere.

Finalmente podemos concluir que el formulario PQR (Peticiones, Quejas y Reclamos) del portal del
Ministerio de Comunicaciones no cumple ninguno de los niveles de conformidad (A, AA, AAA).

Tablas de datos

El portal del Ministerio de Comunicaciones actualmente tiene muchísimas tablas, pero mal usadas.
Es decir, usadas para maquetar (componer el diseño), pero no para su uso natural (tabular datos).
Así que recurrimos a la página libre del ejercicio, la de Eventos, que sí contiene una tabla de datos,
correspondiente al calendario de eventos. Veamos:

1
Punto 10.2: “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.” (Prioridad 2)
2
Punto 12.4: “Asocie etiquetas explícitamente con sus controles”. (Prioridad 2)
3
Punto 6.3: “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”. (Prioridad 1)
4

27

Figura XX: calendario de eventos del portal del Ministerio de Comunicaciones

Aunque hemos realizado una revisión automática con HERA, no hemos podido confiar plenamente
en sus resultados, ya que desafortunadamente esta página de “Eventos”, del portal del Ministerio
tiene dos etiquetas body, así que complementamos con el análisis manual:

Gracias a HERA, hemos detectado los siguientes errores Encontramos los siguientes errores.

• No tiene encabezados que identifiquen claramente el contenido de los datos
(incumplimiento punto 5.1)1

• Utiliza atributos desaconsejados en HTML 4.01 (incumplimiento 11.2)2, por ejemplo <td
align="center">

• El elemento caption de la tabla podría ser, perfectamente “Mayo 2008” o mejor aún
“Eventos en mayo de 2008”. Sin embargo, este título es usado como una celda más de la
tabla.

• Se utilizan imágenes sin su correspondiente texto alternativo (incumplimiento punto 1.1)3,
y vínculos sin claridad en el enlace (incumplimiento punto 13.1)4. Por ejemplo:

• Existe ambigüedad sobre qué elementos son o no hipervínculos (incumplimiento punto
13.4)5. Este problema trasciende todo el sitio, pues el diseñador mediante la hoja de estilo,

1
Punto 5.1: “En las tablas de datos, identifique los encabezados de fila y columna”. (Prioridad 1)
2
Punto 11.2: “Evite características desaconsejadas por las tecnologías W3C” (Prioridad 2)
33
4
Punto 13.1: Identifique claramente el objetivo de cada enlace. (Prioridad 2)
5
Punto 13.4: Utilice mecanismos de navegación de manera consistente. (Prioridad 2)

28

ha puesto a todos los enlaces de color negro y sin subrayar. Veamos lo que aparece en la
primera línea de la hoja de estilo en cascada (CSS), llamada mincom.css:

a:link {
color:#000000;
text-decoration:none;
}

Este error conceptual de diseño produce una confusión entre el texto normal y el
hipervinculazo. Observemos:

Figura XX: un fragmento de la página de Eventos, donde vemos dos textos, uno con
vínculo y otro sin vínculo. Ambos son negros, sin subrayar. Esto produce confusión.

Tablas de formato

Desafortunadamente para el Ministerio de Comunicaciones, su portal está diseñado bajo el
concepto de maquetación por tablas (incumplimiento punto 5.3)1. Es decir, se utiliza un elemento
de marcado (table) para posicionar los diferentes elementos de la Web: encabezado, columna
izquierda, derecha, parte central y pie de página.

Revisando el código fuente, pudimos encontrar, por ejemplo en la página de inicio 22 tablas
anidadas, cuya única función es posicionar los elementos. Toda esta mala práctica puede ser
sustituida por una mucho más limpia, como es usar hojas de estilo en cascada (CSS). Con buenas
prácticas como “separar el código de la presentación” el portal del Ministerio quedará más liviano y,
por supuesto, más cercano a niveles de accesibilidad conformes con la propuesta de Gobierno
Electrónico.

1

29

En la siguiente imagen podremos apreciar el concepto manejado por los diseñadores del sitio para
armar la composición gráfica. Observemos la cantidad tan grande de tablas innecesarias, que
pudieron ser reemplazadas por unas simples líneas de código CSS:

Figura XX: Composición de tablas anidadas para generar el diseño.
Grave error: no separar la presentación del contenido.

JavaScript

En el portal del Ministerio de Comunicaciones se usa recurrentemente el JavaScript para diversos
propósitos, tales como:

• Activación del menú . Todo el sistema de navegación está basado en JavaScript que activa
y despliega un menú, por cada uno de los temas. Al realizar una sencilla prueba con la barra
del Web Developer de Firefox, deshabilitando todos los JavaScripts, el sitio queda sin

30

posibilidad de navegación, ya que no existen elementos noscript que habiliten el
contenido cuando el usuario haya deshabilitado o no tenga la posibilidad de JavaScript en
su computador.

Figura XX : Ejemplo del menú desplegable, activado mediante JavaScript
XX:

Figura XX ; El mismo menú anterior, pero con el JavaScript deshabilitado. ¿El
XX;
problema? Pues que el menú no aparece por ninguna parte y el usuario queda sin
ninguna posibilidad de navegación

• Para abrir ventanas emergentes sin barra de navegador. Se usa un JavaScript en el
formulario “PQR”, en el momento de llenar el campo “Tipo servicio”. Al tener deshabilitado
el JavaScript, el ciudadano no podrá ver ninguna ventana emergente, y por lo tanto no
podrá enviar el mensaje.

31

Figura XX : Botón que despliega los tipos de servicios en una ventana emergente
XX:

• Para cargar la lista de departamentos y ciudades. En el mismo formulario “PQR”, es
ciudades
iudades.
necesario el uso de JavaScript para cargar la lista de Departamentos y Ciudades de
Colombia. Cuando inhabilitamos el JavaScript mediante la barra WebDeveloper nos damos
cuenta que no sale ningún listado.

Figura XX : Fecha que se imprime a partir de un JavaScript, tomando como
XX:
referencia la fecha y hora del computador del usuario

• Para validar el formulario de contacto. En la página de contacto el formulario es validado
a través de JavaScript, antes de enviarse los datos al servidor. Esto permite que aquellos
campos considerados como obligatorios, no pasen en blanco (otro tema será que no existe
ningún tipo de información al usuario sobre qué campos son o no obligatorios). Realizamos
la prueba retirando el JavaScript momentáneamente y el resultado fue una página de error
de servidor, indescifrable para un ciudadano de a pie.

32

Figura XX : Aviso emergente que se produce cuando se intenta enviar un
XX:
formulario, sin rellenar los campos obligatorios.

Figura XX: Si tenemos desactivado el JavaScript, no hay una validación del
lado del servidor, sino que sale un error http Status 500 como el de la figura.

33

Portal 3: Ciudad de Bogotá

Nos pareció importante incluir en el análisis al portal de la Ciudad de Bogotá,
Bogotá
capital colombiana. Este portal ya ha empezado a trabajar el tema de la
accesibilidad, así que esto nos permitirá ahondar más en el asunto. Por su
importancia, número de visitas y por ser uno de los primeros portales en
aportar en el tema de la accesibilidad, ha sido tenido en cuenta.

a) Muestra

1. Página de inicio: http://www.bogota.gov.co/portel/libreria/php/decide.php?patron=01.

2. Mapa del sitio: http://www.bogota.gov.co/portel/libreria/php/decide.php?patron=01.14

3. Contacto: http://www.bogota.gov.co/portel/libreria/php/decide.php?patron=01.1201

4. Aerolíneas: http://www.bogotaturismo.gov.co/directorios/aerolineas/


De los cinco sitios escogidos, el Portal de Bogotá es el más grande en términos de contenido.
Google arroja de ese solo sitio más de 350 mil resultados. Pero no es necesario recorrer cada una de
estas miles de páginas para tener una idea del grado de accesibilidad del portal. Hemos
seleccionado una muestra de cuatro páginas: página de inicio, mapa del sitio, buzón de contacto y
una página con información de aerolíneas, que escogimos porque en el portal fue muy difícil hallar
una tabla de datos.

Con esta muestra hemos logrado tener la gran mayoría de elementos escogidos para este análisis
sectorial.


La siguiente tabla representa la existencia o no de estos siete elementos en las páginas de muestra:

JavaScript

1 Sí No Sí Sí No Tablas Sí
2 Sí No Sí No No Tablas Sí

34

Portal 4: Secretaría Distrital de Gobierno

Una de las más importantes entidades del orden distrital en la capital de
Colombia, es la Secretaría de Gobierno Ella depende de la Alcaldía de
Secretaría Gobierno.
Bogotá. Tiene un sitio Web de aparición reciente, que ha sido trabajado con
estándares Web y con administrador de contenidos Joomla, software libre.

a) Muestra

1. Página de inicio: http://www.gobiernobogota.gov.co/index.php

2. Mapa del sitio: http://www.gobiernobogota.gov.co/component/option,com_joomap/Itemid,128/

3. Contacto: http://www.gobiernobogota.gov.co/component/option,com_contact/Itemid,346/

4. Población en situación de desplazamiento:
http://www.gobiernobogota.gov.co/content/view/46/117/


Tal vez el sitio de la Secretaría de Gobierno sea el de más reciente aparición (abril de 2008), por eso
tiene no más de 2.400 resultados en Google, lo que nos indica que es el sitio más pequeño del
análisis sectorial. Seleccionamos cuatro páginas, muy representativas de la totalidad del sitio: la
página de inicio, el mapa del sitio, el contacto y una página que nos servirá para testear la tabla de
datos, pues no encontramos muchas en este sitio.




1 Sí Sí Sí Sí No CSS Sí
4 Sí Sí Sí Sí Sí CSS Sí

35

Portal 5: Instituto Nacional de Ciegos (INCI)

Finalmente, escogimos como quinto portal al Instituto Nacional
de Ciegos (INCI ). Sobran razones para querer hacer el análisis del
INCI)
portal del INCI, pero nos llama sobre todo la atención que sea
uno de los pocos portales colombianos con los logos de
validación de accesibilidad AA.

a) Muestra

1. Página de inicio: http://www.inci.gov.co/

2. Mapa del sitio: http://www.inci.gov.co/mapa_sitio.shtml

3. Contacto: http://www.inci.gov.co/formulario_contactenos.shtml

4. INCIdencias: http://www.inci.gov.co/incidencias.shtml


Con poco más de cinco mil resultados en Google, el portal del INCI se le nota un trabajo mucho
más consciente de los estándares Web, y de las pautas de accesibilidad WCAG. Así que con la
muestra tomada creemos que se puede dar una idea muy cercana de cómo ha sido trabajado todo
el sitio Web. Escogimos: la página de inicio, el mapa del sitio, la página de contacto y como página
libre escogimos “INCIdencias”, porque es una página que cambia constantemente por ser la que
presenta las noticias del Instituto y tal vez es la más vulnerable a cometer errores de validación y de
accesibilidad, pues es una página que se construye con posterioridad a la revisión inicial de
accesibilidad.



Imágenes Encabezados Listas Formularios
Formularios Tablas de datos Tablas de formato JavaScript

1 Sí Sí No No No CSS No
2 Sí Sí Sí No No CSS No
3 Sí Sí No Sí No CSS/Tabla Sí
4 Sí Sí No No Sí CSS No

36

3. Conclusiones

Podríamos pensar en un panorama desolador, en relación a la accesibilidad de sitios Web en la
administración pública de Colombia, producido no solo por la ausencia de iniciativas legales (hasta
la fecha), si no también por la falta de formación, educación y consciencia por parte de quienes
diseñan los sitios, así como de quienes generan los pliegos de condiciones de los contratos
relacionados con el desarrollo de sitios Web.

Sin embargo, con esta pequeña muestra y el anterior análisis, breve, nos damos cuenta que
empiezan a surgir iniciativas en pro de la accesibilidad, como la del INCI y los esfuerzos de la
Secretaría de Gobierno de Bogotá, inclusive los de la Alcaldía de la capital colombiana.

Pero aún falta, y mucho. Ya hay un antecedente que llena de esperanza el porvenir de la
accesibilidad Web en Colombia: el Decreto 1151 del 14 de abril de 2008, que como ya dijimos, abre
la puerta a la posibilidad de una legislación sobre accesibilidad, en el marco del Gobierno
Electrónico.

Deben empezar pues con el ejemplo los sitios de mayor importancia (al menos jerárquica): la
Presidencia de la República de Colombia y el Ministerio de Comunicaciones.

A continuación, queremos finalizar nuestro informe con unas breves conclusiones sobre el análisis
de cada uno de los cinco portales Web (aunque de tres de ellos no hayamos profundizado, ni
registrado cada error encontrado):

Presidencia de la República

“Deben replantearse la filosofía Web y
rediseñar el portal totalmente”
Creemos que más que los paños de agua tibia que significaría corregir los errores detectados, se
debería hacer un planteamiento total de la filosofía de diseño a seguir. ¿El portal cumplirá con
estándares Web? ¿Con pautas de accesibilidad? ¿Qué prioridad cumpliría? Son las tres preguntas
cruciales que debe realizar el equipo de desarrollo Web de la Presidencia. Y si las respuestas van

37

encaminadas a las buenas prácticas (sí cumpliremos estándares XHTML, CSS, sí cumpliremos con las
pautas WCAG y en un nivel AA), creemos que el rediseño total es inminente.

Ministerio de Comunicaciones

“El claro ejemplo de lo que no se debe
hacer: precisa rediseño total”
Tal vez fue el que peor salió librado de los cinco portales. Es un claro ejemplo de lo que no debe ser
un portal Web (desde el punto de vista de la accesibilidad). Nos sirve para ejemplificar todos los
errores que uno pudiera cometer cuando diseña para la Web. Si a esto le sumamos la
responsabilidad histórica que tiene el Ministerio de emitir unas pautas y una guía para la
elaboración de portales Web en aras del cumplimiento de los objetivos del Decreto de Gobierno
Electrónico, es inminente la necesidad de una remodelación con carácter urgente. No pensaríamos
tampoco en arreglos o remiendos de código, sino en una reestructuración total, basado en una
nueva filosofía de diseño Web, que llene al equipo de desarrollo del Ministerio de las más altas
ganas de ser los verdaderos pioneros en Colombia de publicar un portal con un nivel AA de
accesibilidad.

Ciudad de Bogotá

“Buena voluntad. Rediseñar será
sencillo: ya existe la sensibilidad”
Interesante ver que han sido uno de los primeros portales en preocuparse por la accesibilidad Web.
Sin embargo, su desarrollo ha ido en vía contraria a las pautas de accesibilidad de la WGAC. La
voluntad toca acompañarla de unos resultados efectivos, y estos no los puede mostrar un portal
que se divide en a) El portal para los no discapacitados y b) El portal copia para los discapacitados.
No se trata de tener dos versiones, sino de ser capaces con la misma de hacer accesibles los
contenidos. Así que este importantísimo portal deberá replantear su estrategia de accesibilidad.
Creo que será sencillo en la medida en que ya existe la sensibilidad del tema, y solo es cuestión de
aplicar las técnicas adecuadas. Y por supuesto, de olvidarse de una vez por todas de las tablas para
maquetar.

38

Secretaría de Gobierno de Bogotá

“Muy buena base, código limpio. Con
unos cuantos detalles aspiraría a AA”
Creo que este portal tiene un muy buen comienzo, una excelente base, por su limpieza en el
código, por la conciencia de su grupo de desarrollo en cumplir estándares Web, con cero errores de
validación en XHTML y CSS. Todo eso muy bonito. Pero le faltan detalles de accesibilidad que se
pueden arreglar de una manera muy simple. Lograr un nivel AA de conformidad no será nada difícil.

Instituto Nacional de Ciegos (INCI)

“El más accesible de la muestra. Solo
unos detalles, para ser ejemplo”
El portal que más favorecido salió, según nuestro breve análisis. Se le nota un trabajo arduo detrás, y
en muchas páginas que revisamos muy a vuelo de pájaro, es justa la medalla del doble A. En otras
hace falta más rigurosidad. A este portal sí le podríamos aplicar pañitos de agua tibia para que el
cumplimiento sea estricto y para que sirva como modelo para otros portales de la administración
pública en Colombia.

39

Accesibilidad portales públicos Colombia

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Similaire à Accesibilidad portales públicos Colombia

Similaire à Accesibilidad portales públicos Colombia (20)

Plus de Mario Carvajal

Plus de Mario Carvajal (15)

Accesibilidad portales públicos Colombia