SISTEMATIZACIÓN DEL DESARROLLO Y ADAPTACIÓN DE

SITIOS WEB AJUSTADOS A LA NORMA NTC 5854

ANA MARIA NATES RODRÍGUEZ

JESÚS DAVID ROMERO MELO

PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS

FACULTAD DE INGENIERÍA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

BOGOTÁ, 31 de Julio 2018
SISTEMATIZACIÓN DEL DESARROLLO Y ADAPTACIÓN
DE SITIOS WEB AJUSTADOS A LA NORMA NTC 5854

ANA MARIA NATES RODRÍGUEZ

JESUS DAVID ROMERO MELO

Trabajo de grado presentado como requisito para optar al título de

INGENIERO DE SISTEMAS

Director: FERNANDO MARTINEZ RODRIGUEZ

Ingeniero
fmartinezro@gmail.com

PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS

FACULTAD DE INGENIERIA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
BOGOTÁ, 31 de Julio 2018
A quienes siempre estuvieron a nuestro lado para motivarnos,
apoyarnos y acompañarnos en este camino a ser profesionales
y egresados de esta universidad que tanto amamos
y por la que tanto luchamos.

“Es preciso soñar, pero con la condición de creer

en nuestros sueños. De examinar con atención la
vida real, de confrontar nuestra observación
con nuestros sueños, y de realizar
escrupulosamente nuestra fantasía.”
V.I.L.
 AGRADECIMIENTOS

Agradecemos en primer lugar a Dios por nuestras vidas y por llegar, después de tantas
experiencias, hasta este momento.
A nuestras familias, porque nos dieron la oportunidad de soñar un futuro distinto mediante
el camino de la Educación Pública. A ellas y ellos les agradecemos las atenciones y cuidados,
los llamados de atención, la paciencia y las lecciones que nos enseñaron, porque hoy somos
fruto de aquello.
A las y los profesores que a lo largo de la carrera despertaron en nosotros la curiosidad y el
amor a la ciencia y a la ingeniería, amor que despertó en nosotros el deseo de ejercer
responsablemente como ciudadanos y profesionales en esta sociedad carente y necesitada
de innovación con sentido humano.
Pasar por la Universidad Distrital fue para nosotros un camino lleno de alegrías,
preocupaciones, aprendizajes, crecimiento personal y profesional que nos enseñó que no
solo se trata de entender nuestro entorno, que no basta con observar, es necesario actuar
en él y transformarlo.
Agradecemos a quienes trabajaron antes, y con nosotros en el Proceso Constituyente de la
Universidad, porque nos enseñaron el valor de persistir, defender y construir desde el alma
y el corazón este proyecto de Universidad. Al Colectivo Piensa Libre donde crecimos como
estudiantes e ingenieros integrales, y a la ACEU, cuna del pensamiento crítico y forjadora
de soñadores incansables por una universidad critica, creadora y transformadora. Gracias a
todos los compañeros, amigos, profes y camaradas que estuvieron presentes para enseñar,
construir y compartir la alegría de pintar para la vida.

Agradecemos al Grupo Virtus y al docente Fernando Martínez por creer en este proyecto
desde el inicio, y brindar sin reparo su experiencia y ayuda para cristalizar este importante
logro.
A Colnodo, por depositar en nosotros la confianza para desarrollar un proyecto como este,
que demuestra que si son necesarios ingenieros con enfoque humano y social. Por poner a
nuestra disposición su experiencia como organización y por abrirnos las puertas a una nueva
etapa en nuestras vidas.
Tabla de contenido
RESUMEN ................................................................................................................................................................... 1
INTRODUCCIÓN ....................................................................................................................................................... 2
1 PLANTEAMIENTO DEL PROBLEMA........................................................................................................... 3
1.1 Descripción del problema .................................................................................................................... 3
1.2 Formulación del problema .................................................................................................................. 4
2 JUSTIFICACIÓN ................................................................................................................................................... 5
3 OBJETIVOS ............................................................................................................................................................ 6
3.1 Objetivo general ....................................................................................................................................... 6
3.2 Objetivos específicos .............................................................................................................................. 6
4 MARCO REFERENCIAL .................................................................................................................................... 7
4.1 Antecedentes o estado del arte.......................................................................................................... 7
4.2 Marco teórico ......................................................................................................................................... 10
5 MARCO METODOLÓGICO ............................................................................................................................ 15
5.1 Metodología de la investigación ..................................................................................................... 15
5.2 Ingeniería del proyecto ...................................................................................................................... 17
6 RESULTADOS Y DISCUSIÓN........................................................................................................................ 19
6.1 Sistematización del desarrollo ........................................................................................................ 19
6.2 Retos y recomendaciones para la aplicación de accesibilidad .......................................... 29
7 CONCLUSIONES ............................................................................................................................................... 37
8 RECOMENDACIONES..................................................................................................................................... 39
9 BIBLIOGRAFIA Y CIBERGRAFIA ............................................................................................................... 41
9.1 Bibliografía.............................................................................................................................................. 41
9.2 Cibergrafía ............................................................................................................................................... 43
10 ANEXOS .................................................................................................................................................................. 1
ANEXO 1: MANUAL DE ACCESIBILIDAD WEB ............................................................................................. 1
ANEXO 2: EVALUACIÓN DE ACCESIBILIDAD MOODLE ........................................................................... 1
ANEXO 3: EVALUACIÓN DE ACCESIBILIDAD MICROSITIOS ............................................................... 17
ANEXO 4: SOPORTES SITIO OBSERVATORIO DE TERRITORIOS ÉTNICOS Y CAMPESINOS 24
 LISTA DE FIGURAS

Gráfica 1. Conexiones a internet participación por tipo de acceso ……………………………..…..4

Gráfica 2. Actividades y criterios componente 1. Estrategia Gobierno en línea .…………...14
Gráfica 3. Campo de un formulario con un label y dos inputs relacionados .…………………..20
Gráfica 4. Footer con lista de información institucional accesible …………..……………….…...21
Gráfica 5. Vista de la rayuela accesible en un micrositio ………………..………..…………………...26
Gráfica 6. Vista del cabezote y menú principal del sitio web …………..………..…………………...30
Gráfica 7. Vista de la zona central de la página editorial …….…………..………..…………………...31
Gráfica 8. Vista de la zona central de la página Centro de documentación .…………………...31
Gráfica 9. Vista de la zona central de la página de Multimedia ………………...…………………...32
Gráfica 10. Vista del Sistema de Información Geográfica ……….………………...…………………...33
RESUMEN
Este proyecto es el resultado del desarrollo de los sitios web de la Contraloría de Córdoba y
el aula virtual de la Biblioteca Nacional de Colombia, evaluados y adaptados de acuerdo a
los lineamientos de la WCAG 2.0 y la NTC 5854, dejando una base de experiencias y retos
en el marco de la implementación de técnicas de accesibilidad en el desarrollo web.

A lo largo de la pasantía se sistematizó todo el proceso, recogiendo las evaluaciones,

correcciones y demás procesos que fueron la base para la producción de un manual de
accesibilidad, que describe de forma práctica y concreta, la implementación de las pautas
de accesibilidad web, pretendiendo simplificar la transición del enfoque de desarrollo
tradicional a un enfoque de desarrollo accesible, desmitificando el espectro complejo y
tedioso que se ha formado alrededor de la accesibilidad web y generando confianza y
conciencia en la necesidad de formarse y formar en esta tendencia, que con el auge agresivo
de la tecnología, se vuelve cada vez más imperativa.

El manual se estructura de 4 secciones, la sección de planeación formula sugerencias y

decisiones del orden general del proyecto que se deben considerar al iniciar el desarrollo,
como el grado de accesibilidad deseado y las consecuencias de esto, la preparación teórica
de los involucrados en el proyecto y aspectos de diseño. En la sección de desarrollo se
describe con cierto grado de detalle técnico pero concreto y digerible cómo implementar
los lineamientos guías en accesibilidad web. En la sección de Evaluación de Accesibilidad, se
describe una propuesta metodológica y los métodos de evaluación sugeridos, haciendo la
salvedad, que la forma en el que estos se apliquen (durante el desarrollo, al finalizar el
desarrollo, etc) depende de las características, necesidades y condiciones del proyecto
mismo. Por último, la Lista de Herramientas recoge los beneficios o desventajas en términos
de accesibilidad de las herramientas que hicieron parte del proyecto.

La accesibilidad no es un fin, es un proceso.

1
INTRODUCCIÓN
La evolución exponencial de las tecnologías de la información ha abierto la oportunidad de
que cada vez más personas tengan acceso a plataformas tecnológicas, y ha hecho que exista
una gran cantidad de información en la web, desde información irrelevante, hasta
conocimientos teóricos, incluso la prestación de servicios médicos e información oficial
estatal. Pero ¿está realmente abierta esta puerta al mundo para todos?

Según el Informe Mundial sobre Discapacidad de 2011, más de mil millones de personas en
el mundo viven con discapacidad, cerca del 15 % de la población mundial, y de acuerdo con
el informe de Global Monitoring Report, en 2015, cerca del 9,6 % de la población vivía en la
extrema pobreza. En la actualidad existen infinidad de contenidos y servicios médicos o de
cualquier índole alojados en internet, vitales para la cotidianidad de esta población. Urge
para el desarrollo de la humanidad ampliar el acceso a las plataformas tecnológicas que
faciliten el uso y acceso a Internet y todo su contenido.

Garantizar accesibilidad es garantizar que “personas con algún tipo de discapacidad van a
poder hacer uso de la Web”1 y que tendrán la oportunidad de vivir una experiencia
parcialmente completa a los contenidos audiovisuales y a la infinidad de información
presente en la web. Muchos gobiernos, incluido el colombiano, han definido que sus sitios
web cumplan estándares de accesibilidad en distintos niveles, sin embargo, aún existe una
amplia gama de sitios web oficiales, comerciales, de ocio, entre otros, que no son accesibles.

En búsqueda de cerrar esta brecha de acceso, y de generar elementos que agilicen y faciliten
la implementación de estándares accesibles en los sitios web de entidades del estado o de
interés para la población en condiciones de discapacidad, se plantea este proyecto, cuyo
objetivo es generar una guía para fortalecer esta línea de desarrollo y así llevar
progresivamente todos los beneficios del internet a esta población que por su condición se
ve limitada a acceder a un pequeño porcentaje de la información global. Esto se logrará
mediante el acompañamiento en el proceso de creación de sitios web gubernamentales
cumpliendo con la norma NTC 5854 en nivel AA; desde la discusión y definición de
requerimientos con el cliente hasta la entrega y puesta en línea del sitio,
sistematizando en cada etapa del proceso, buenas prácticas, herramientas de
desarrollo, apuestas gráficas alternativas, metodologías de desarrollo, validación y
verificación. Sobre esta base, se busca plantear el trabajo futuro para la investigación y
desarrollo de tecnologías web que aumenten el nivel de accesibilidad de los sitios en
Colombia, así como los retos en formación y ejecución que quedan en este campo.
Este proyecto cuenta con el apoyo y la experiencia de Colnodo, empresa dedicada al

1 LAWTON, Shawn y EOWG. Introducción a la Accesibilidad Web. W3C Web Accesibility Initiative [en línea],
septiembre de 2005 [revisado 10 junio 2017]. Disponible en
http://www.w3c.es/Traducciones/es/WAI/intro/accessibility

2
desarrollo de páginas web accesibles con más de 20 años de en mercado y
comprometidos con la misión de llevar el contenido de sus clientes a la mayor cantidad de
usuarios posibles.

1 PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIÓN DEL PROBLEMA
El Ministerio de Tecnologías de la Información y las Comunicaciones, en adelante MINTIC,
establece para el contexto colombiano la accesibilidad como “las condiciones que se
incorporan en sitios y herramientas web que favorecen el que usuarios en condiciones de
deficiencia tecnológica, física o sensorial o en condiciones particulares de entornos difíciles
o no apropiados, puedan hacer uso de recursos de la Web”2

Según el Departamento Administrativo Nacional de Estadística -Dane- en Colombia había

2.149.710 personas con discapacidades físicas, mentales o sensoriales en el 2012, lo cual
representaba el 4,7% de la población del país3. Sumado a esto, el Consejo Nacional de
Política Económica y Social -CONPES- declaró que existe una relación entre las cifras de
población con discapacidad y la población vulnerable en el país4.

Es decir, que si se quisiera mejorar el acceso para poblaciones en discapacidad, hay que ver
no solo hacia las personas con discapacidades físicas, mentales, sensoriales, sino también
hacia quienes usan la web en entornos de deficiencias tecnológicas, con acceso limitado a
redes estables de internet móvil o fijo, desde dispositivos móviles o computadores de gama
media o baja.

Por otro lado, de acuerdo con el Boletín Trimestral de las TIC del cuarto semestre de 20165,
el número de suscriptores a internet de los estratos 1, 2 y 3 ha aumentado en 9.2%, 5.9% y
9.5% respectivamente desde el 2015, mientras que los estratos 5 y 6 aumentaron en 8.7%.
Es decir que tanto sectores vulnerables de la sociedad colombiana, como aquellos con
mejores condiciones de vida siguen aumentando su conectividad a internet. Por ende, cada
vez más colombianos se comunican con el mundo, reciben noticias, servicios y acceden a

2 MINTIC. Manual para la implementación de la Estrategia de Gobierno en línea de la República de Colombia.

Bogotá. 2012. p.43

3 COLOMBIA. CONPES. Documento CONPES 166 de 2013 (9 de Diciembre 2013). “Política Pública nacional

de discapacidad e inclusión social”. Bogotá, 2013. p 55.

Disponible en internet:
http://www.mincultura.gov.co/areas/poblaciones/poblacion-con-discapacidad/Paginas/166.pdf
4 Ibid. p.21.
5 MINTIC. Op. cit.

3
cifras oficiales, notificaciones, trámites, atención al usuario y consulta de normas a través
de la web.
Estos servicios, como tantos otros ofertados por entidades de salud, establecimientos
comerciales y educativos, entre otros son frecuentados por los colombianos, a través de
conexiones móviles 3G y 4G, que aumentaron incluso en mayor proporción que el acceso a
internet por redes fijas del 2015 al 2016, tal como se ve en la gráfica 1.

Grafica 1 Conexiones a internet participación por tipo de acceso.

Fuente: BOLETÍN TRIMESTRAL DE LAS TIC. Ministerio de Tecnologías de la Información y las Comunicaciones.
Marzo de 2017. p. 9.

El mismo boletín, evidencia un aumento del 2015 al 2016 en usuarios de redes móviles ya
sea mediante suscripción (es decir plan de costo fijo) y por demanda o abonos de acuerdo
a la Resolución 5076 del 2016 de la Comisión de Regulación de Comunicaciones6

1.2 FORMULACIÓN DEL PROBLEMA

Las cifras presentadas en la sección anterior dan cuenta de la necesidad de transitar cada
vez más rápidamente hacia una web accesible y usable para la población colombiana,
puesto que la tendencia de accesos desde dispositivos móviles aumenta cada año, de
acuerdo con MINTIC7. De hecho, a raíz de ese aumento exponencial, y de las facilidades que
el internet brinda para que el estado garantice derechos a los ciudadanos (como acceso a
la información, ley anti trámites, transparencia, entre otros), el estado colombiano asume
en el 2012 el lineamiento “Gobierno en Línea”, que entre otras, busca garantizar que por
lo menos los sitios web del estado tengan nivel de accesibilidad AA según la NTC 5854. Sin
embargo, los resultados presentados en el Formulario Único de Reporte de Avances en la
Gestión (FURAG) de 20168 evidencia que solo el 45% de los sitios web de las alcaldías
cumplen satisfactoriamente con el componente de accesibilidad y usabilidad.

6 COLOMBIA. CRC. Resolución 5076. (29 de Diciembre de 2016). Bogotá, 2016. Disponible en internet:
https://www.crcom.gov.co/resoluciones/00005076.pdf
7 MINTIC, Op. cit. p. 25.
8 MINTIC, Indice GEL Nacional, Resultados 2016. Estrategia Gobierno el Línea

4
Ahora si este es el caso de las entidades que por lineamiento del MINTIC y presidencia
deben cumplir la NTC 5854, ¿qué se puede esperar del nivel de accesibilidad de otros sitios
web no gubernamentales? Redes sociales como Twitter iniciaron a pensarse la accesibilidad
web para sus usuarios, sin embargo en Colombia, la norma NTC 5854 sigue siendo una
norma desconocida y en tanto no sea obligatoria su implementación seguirá siendo un
desafío para los colombianos con discapacidades o limitaciones acceder a sitios web.
Entonces, ¿cómo hacer más sencilla y atractiva la implementación de la NTC 5854 para los
desarrolladores web gubernamentales y empresarios colombianos?

2 JUSTIFICACIÓN

El desarrollo del presente proyecto busca responder e incentivar el cumplimiento de lo

establecido por el MINTIC sobre accesibilidad y usabilidad en la estrategia Gobierno en
Línea: “Los sitios web correspondientes a sistemas de información deberán cumplir por lo
menos los criterios correspondientes a usabilidad y accesibilidad de la actividad ‘Centrar la
atención en el ciudadano’, del Componente de Elementos Transversales”9.

Implementando las normativas que reglamentan la accesibilidad y usabilidad del

documento citado, no sólo se cumpliría lo establecido en la ley 1680 de 201310, se abriría el
Internet y los servicios de las entidades públicas a los colombianos con discapacidades
físicas o motoras, y se abriría paso a campesinos y pobladores de todas las regiones del país
a acceder a la Internet y todos sus beneficios incluso con una conectividad baja y desde
dispositivos móviles como celulares y tabletas.

Por otro lado, para Colnodo, este proyecto representa un espaldarazo a la vocación y el
compromiso demostrado en todos sus años de existencia por el uso estratégico de Internet
para el desarrollo. Actualmente, son una empresa de reconocimiento en temas de
accesibilidad web, y han participado en espacios nacionales e internacionales para la
cooperación e implementación en accesibilidad. Un ejemplo, es el proyecto Internet para
la Rendición de Cuentas, que es la “herramienta orientada a fortalecer la transparencia de
la información pública y facilitar el control social”11 en la que Colnodo colaboró en el

9 MINTIC. OP. cit. p.2.

10 COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1680 (20 de noviembre de 2013) “Por la cual se garantiza a
las personas ciegas y con baja visión, el acceso a la información, a las comunicaciones, al conocimiento y a las
tecnologías de la información y de las comunicaciones”. Bogotá, 2013.
11 Internet para la Rendición de Cuentas. Sobre el proyecto. IPCR [en línea] Bogotá [revisado junio 2017]

Disponible en Internet: http://www.iprc.org.co/

5
desarrollo del sitio web modelo, a la medida de las necesidades y requerimientos de las
normas en el 2007 en Colombia, y que fue implementado por municipios y diversas
entidades territoriales. Sin embargo, la velocidad con la que avanzan las nuevas tecnologías
obliga a estar en constante revisión y renovación de los procedimientos y mecanismos de
desarrollo, aspecto central de análisis en el presente proyecto. Así mismo, resulta
conveniente para Colnodo el desarrollo de la investigación, por que suscita la discusión e
invita a nuevas y antiguas organizaciones con y sin ánimo de lucro a sumarse al desarrollo
accesible, facilitando los enlaces y canales de cooperación y las estrategias de
implementación de las normativas.

Finalmente, este trabajo permitirá a otros estudiantes y docentes interesados en la

investigación e implementación de desarrollos web accesibles, contar con una base teórica
y práctica inicial, conocer las debilidades y fortalezas de gestores como Moodle o el
framework Aplicaciones de Acción y de algunas herramientas web de uso frecuente, sus
potencialidades para enfocarse en el desarrollo y la innovación.

3 OBJETIVOS

3.1 OBJETIVO GENERAL

Crear una base teórica que permita simplificar el desarrollo posterior de nuevos sitios
accesibles que cumplan con la reglamentación técnica y jurídica del país; y que proyecte
nuevos retos e iniciativas a desarrollar.

3.2 OBJETIVOS ESPECÍFICOS

1. Acompañar el desarrollo de 3 proyectos web accesibles garantizando el
cumplimiento de la norma NTC 5854 en nivel AA, con el fin de estudiar los
requerimientos de los clientes, prácticas, metodologías herramientas y demás
detalles del proceso de desarrollo.
2. Sistematizar el proceso de desarrollo de los sitios web, recogiendo los elementos
técnicos y metodológicos más significativos del proceso, con el fin de elaborar un
Manual de Accesibilidad que contribuya a desarrollos futuros en esta área.
3. Hacer un análisis sobre el Manual de Accesibilidad elaborado para identificar los
retos que existen sobre formación e implementación dentro de este campo.

6
 4 MARCO REFERENCIAL
4.1 ANTECEDENTES O ESTADO DEL ARTE
La accesibilidad web es una temática que a pesar de ser reciente, cuenta con múltiples
estudios en busca de minimizar la esta brecha tecnológica y de información para personas
con discapacidades.

4.1.1 Lineamientos para la Accesibilidad Web

La Iniciativa para la Accesibilidad Web, WAI, por sus siglas en inglés, es la rama dedicada a
la accesibilidad web de la Word Wide Web Consortium, W3C. Desde su fundación, han
creado dos versiones de Pautas de Accesibilidad para Contenido Web, más conocidas por
sus siglas en inglés como WCAG. Estas pautas, aunque no son oficialmente reconocidas ni
cuentan con certificación de parte de organismos internacionales, estas se han convertido
en un estándar aceptado. Algunos estudios han planteado una serie de beneficios técnicos
y de acceso que permite la WCAG12, por ejemplo, el aplicar estas métricas, permite incluirlas
dentro de la fase de ingeniería web, logrando una comprensión desde el inicio, por parte
del equipo de desarrollo. Esto a su vez permite que todo el proceso esté enmarcado por
métricas definidas, asegurando un sitio accesible desde su diseño; las métricas de por sí
permiten un modelo de evaluación y clasificación de páginas web.

Aparte de los beneficios técnicos mencionados, se ha comprobado la validez de la WCAG,

en su versión 2.0, directamente con los implicados, en un estudio muy particular, que busca
mediante las emociones de personas con dificultades auditivas medir su grado de
satisfacción al visitar un sitio web13. Los resultados de este estudio demuestran que en los
sitios que no garantizan los principios de la WCAG 2.0, se perciben emociones negativas
cuando se accede, y, las emociones de los usuarios se presentan positiva o neutralmente,
cuando se cumple la WCAG 2.0.

En cuanto a las personas con discapacidad visual se proponen 4 ámbitos que

12 VIGO, markel, BRANJNIK, Giorgio, O’CONNOR, Joshue. Research Report on Web Accessibility Metrics. En:
W3C WAI Research and Development Working Group (RDWG) Notes [en linea] 2012 [revisado junio 2018].
Disponible en internet: https://www.w3.org/TR/accessibility-metrics-report/
13 PASCUAL, Alfra. RIBERA, Mireia. GRANOLLERS, Toni. Impact of web accessibility barriers on users with a

hearing impairment. En: Dyna. Medellín, 26 de 2015.

7
fundamentalmente se deben cubrir para garantizar accesibilidad plena14: Sonidos no
vocales que permitan la ubicación y navegación dentro de la página; interfaz web y móvil
adaptativa; táctil con posibilidad de relieve; e interacción mediante gestos.

4.1.2 Accesibilidad para usuarios sordos

Otro avance notable en la accesibilidad implementado por MINTIC, Vive Digital y FENASCOL
es el “Centro de Relevo” espacio online para usuarios sordos que mediante plataformas
muy sencillas e intuitivas busca acercar a esta comunidad a las herramientas TIC, y que lleva
al aire más de 15 años. Algunos de los servicios ofertados son:
● Relevo de llamadas “permite la comunicación bidireccional entre personas sordas y
oyentes a través de una plataforma tecnológica que cuenta con intérpretes de LSC
en línea.”15
● Servicio de Interpretación en Línea SIEL, que “facilita la comunicación entre sordos
y oyentes que se encuentran en un mismo espacio al colocar a su disposición un
intérprete en línea, al cual pueden acceder desde un computador, una Tablet o un
celular con conexión a internet y sistema de amplificación de audio y micrófono”16
● Herramienta de Apropiación TIC, “ofrece contenidos y espacios donde la lengua de
señas y la lengua escrita prevalecen para el acceso a la información, el aprendizaje,
la comprensión, construcción de conocimientos y sobre todo la motivación al uso de
las TIC en las personas sordas”17
● Formación Virtual de Intérpretes que “los capacita constantemente en temas como
comunicación, traducción, lengua de señas, cultura sorda y atención al usuario”18

4.1.3 Integración de tecnologías web para la accesibilidad

En vías de continuar evolucionando en desarrollos en este campo, algunos estudios han a
propuesto soluciones como desarrollar contenido web solo de texto19, tema que contradice
de cierta manera los lineamientos expedidos por la WCAG, mientras otros han propuesto,

14 FERATI, Mexhid. En: Accessibility requirements for blind and visually impaired in a regional context: An
exploratory study. En Usability and Accessibility Focused Requirements Engineering (UsARE), 2014 IEEE 2nd
International Workshop on. IEEE, 2014. p. 13-16.
15 MINTIC. Relevo de llamadas. Centro de Relevo [en línea] [revisado junio 2018]. Disponible en internet:

http://www.centroderelevo.gov.co/632/w3-propertyvalue-15253.html
16 MINTIC. Servicio de Interpretación en línea SIEL. Centro de Relevo [en línea] [revisado junio 2018].

Disponible en internet:http://centroderelevo.gov.co/632/w3-propertyvalue-15254.html
17 MINTIC. Herramienta de apropiación TIC. Centro de Relevo [en línea] [revisado junio 2017]. Disponible en

internet: http://centroderelevo.gov.co/632/w3-propertyvalue-15255.html
18 MINTIC. Formación virtual de intérpretes. Centro de Relevo [en línea] [revisado junio 2017]. Disponible en

internet: http://centroderelevo.gov.co/632/w3-propertyvalue-15256.html
19 LOIACONO, Eleanor T.; MCCOY, Scott; CHIN, William. Federal Web site accessibility for people with

disabilities. En:IT professional, 2005, vol. 7, no 1, p. 27-31.

8
por ejemplo, la transformación del formato HTML utilizando el Modelo de Objetos del
Documento para lograr una mejor visualización y funcionalidad de la estructura20, esto,
mediante una ontología compuesta por nodos y uniones o relaciones que mediante un
archivo RDF genere el sitio web permitiendo que una entrada se convierta en 5 salidas:
cambiar de eje, ir hacia adelante, hacia atrás, leer y orientación dentro de la página,
traduciendo cada salida con un convertidor de voz.

4.1.4 Accesibilidad en CMSs

Los CMS son plataformas gestoras de contenido que facilitan la creación y manejo de la
estructura y del contenido de páginas web. Facilitar tantas tareas requiere una
programación por debajo, que no es sencilla de modificar, por lo tanto el implementar
estándares para garantizar accesibilidad en estos sitios, es aún más complicado. Se han
realizado varios estudios en este campo, que han demostrado efectivamente como muchas
plantillas de estos gestores, como Joomla21 vienen pre programadas y su desarrollo ha sido
bastante amplio, pero en contra de esta nueva tendencia accesible, dificultando la
modificación y adaptación de muchos sitios web.
Para estos casos, Lopez & et. plantean una serie de pasos22 para que la inmersión de la
accesibilidad en un sitio web que se base en un gestor de contenido no sea tan traumática:
Seleccionar el CMS y su configuración de tal forma de que queden habilitadas todas las
posibles opciones de accesibilidad; desarrollar una serie de muestras de páginas web para
asegurarse que las etiquetas y demás atributos HTML funcionen correctamente; utilizar
validadores de los estándares de la WCAG para realizar pruebas de los criterios de
accesibilidad; hechos estos pasos se procede a realizar un conjunto de ejemplos de páginas
web con toda la configuración realizada, se procede a realizar el desarrollo del sitio, donde
se debe hacer una revisión constante de la accesibilidad de cada página con más de un
validador; luego se debe analizar qué problemas de accesibilidad se tienen para identificar
y aplicar soluciones al sitio.

20 FAYZRAHMANOV, Ruslan. GÖBEL, Max. HOLZINGER, Wolfgang. KRÜP, Bernhard. BAUMGARTNER, Robert.
A unified ontology-based web page model for improving accessibility. En Proceedings of the 19th international
conference on World wide web. ACM, 2010. p. 1087-1088.
21 ALFONZO, Daiana E. CASARO Pedro L. MARIÑO, Sonia I. GODOY, María V. Mantenimiento Correctivo

Aplicado a un Sitio Basado en Joomla. Una Propuesta Centrada en la Accesibilidad. En: Revista
Latinoamericana de Ingeniería de Software, 2015, vol. 3, no 2, p. 101-107.
22 LÓPEZ, Juan Miguel., PASCUAL, Afra, MEDUIÑA, Cristina, & GRANDOLLERS, Toni. Methodology for

identifying and solving accessibility related issues in web content management system environments. En:
Proceedings of the International Cross-Disciplinary Conference on Web Accessibility. ACM, 2012. p. 32.

9
4.1.5 Otros tipos de accesibilidad

La accesibilidad entendida como el derecho que tienen todas las personas de acceder a una
plataforma web, también involucra a aquellas personas cuya conexión lenta no le permite
acceder a cierto contenido, para esto han propuesto23 un agente web de dos niveles, uno
local que identifique, registre y aprenda el comportamiento del usuario local y uno remoto
que interactúe con la red pública hablando con el agente local para registrar y aprender el
comportamiento de los usuarios e interactuando con otros agentes remotos; esto permite
que el usuario disfrute de una conexión más fluida.

Como se ve, la accesibilidad es una tendencia que da cuenta de la necesidad de involucrar

al grueso de la población en las tecnologías y el mundo de la información web, esto pasa
por las personas con discapacidad visual, auditiva, cognitiva o motora, pasa por adultos
mayores y personas con ancho de banda limitado, pero incluso como se plantea que se debe
empezar a hablar de la neutralidad de la red24, ya que pierde sentido empezar a hablar de
accesibilidad cuando incluso hay millones de casos de personas que no tienen la posibilidad
siquiera de acceder a la red o a aún peor, a una terminal informática llámese pc o móvil.
Esto para decir que todos los esfuerzos por avanzar tecnológicamente para brindar el
acceso a personas en alguna condición de discapacidad se vuelven mínimos si no se reduce
la brecha social por lo menos a nivel tecnológico.

4.2 MARCO TEÓRICO

4.2.1 WCAG (Web Content Accessibility Guidelines)

La Web Accessibility Initiative es una rama de la World Wide Web Consortium W3C que vela
por la accesibilidad web, desarrollando estrategias, guías y recursos. De esta iniciativa
surgen los lineamientos de accesibilidad para el contenido web, o WCAG.

La WCAG son una serie de lineamientos que definen cómo hacer la web accesible para
personas con alguna discapacidad. Esta accesibilidad comprende discapacidades como la
visual, auditiva, física, de habla, cognitiva, lingüística, de aprendizaje y de problemas

23 YEH, Ping-Jer; YUAN, Shyan-Ming; LO, Winston. Two-level Web agent for limited accessibility. En Computer

Software and Applications Conference, 1997. COMPSAC'97. Proceedings., The Twenty-First Annual
International. IEEE, 1997. p. 482-485.
24 COLNODO. Neutralidad en Internet: Factor que potencia el cierre de la brecha social digital.. Colnodo [en

línea] 4 diciembre 2013 [revisado junio 2018]. Disponible en Internet:

https://colnodo.apc.org/es/neutralidad-en-internet-factor-que-potencia-el-cierre-de-la-brecha-social-
digital-2

10
neurológicos; también hacen la web más usable para personas de edad avanzada y con
herramientas de baja gama.

Estas pautas se componen de 4 principios, cada principio tiene unos lineamientos y unos
criterios de éxito como se ve a continuación25:

● Perceptible:
o Textos alternativos:
o Todo el contenido sin texto debe tener un texto alternativo,
o Contenido multimedia basado en tiempo (Videos, Audios)
o Los contenidos de video y audio debe mostrar información equivalente a
este contenido.
o Adaptable:
La secuencia del contenido afecta su significado, esta debe ser determinada
mediante programación.
Las instrucciones para operar y entender el sistema no dependen
únicamente de las características sensoriales de los componentes.
o Distinguible:
El color debe tener un grado de contraste considerable.
Los audios deben tener la opción de control (volumen, tiempo, etc.).
● Operable:
o Teclado accesible: A todo el contenido debe poderse acceder mediante el
teclado.
o No debe haber componentes de los que no se pueda salir con el teclado.
o Suficiente tiempo: Si hay contenido controlado por tiempo, se debe poder
apagar, ajustar, extender, pausar, detener u ocultar.
o Convulsiones: Las páginas no deben tener contenido que flashee más de 3
veces en un segundo.
o Navegable:
Las páginas deben tener títulos que describan su tema o propósito.
Si el contenido está organizado secuencialmente los componentes que se
puedan enfocar deben corresponder lógicamente a esta secuencia.
o Los vínculos deben tener su descripción en texto.
● Entendible:

25W3C. Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recomendations [en línea] 11 de diciembre
2008 [revisado junio 2018]. Disponible en intenet: https://www.w3.org/TR/WCAG20/

11
 oLeíble: El lenguaje por defecto debe estar determinado mediante
programación.
o Predictible:
Cuando un componente sea enfocado el contexto de la página no debe
cambiar.
Cambiar la configuración de algún componente de interfaz del usuario no
debe automáticamente cambiar el contexto, a menos que el usuario sea
notificado del comportamiento antes de usar el componente.
o Asistencia para entrada de datos: Compatible:
Debe alertar si existe algún error.
Debe dar instrucciones claras mediante etiquetas.
● Robusto:
o Compatible:
Para el contenido con lenguaje de marcado, las etiquetas deben tener inicio
y final, elementos anidados según su especificación, no duplicar atributos y
tener un ID único.
Para todos los componentes de interfaz de los usuarios, el nombre y el rol
debe estar determinados.

La WCAG dependiendo la versión (1.0 o 2.0), clasifica los sitios web según el cumplimiento
de los principios en tres niveles: A, AA y AAA, siendo AAA el nivel que cumple con todos los
lineamientos, y A el que cumple solo algunos de ellos.

4.2.2 Colnodo
Colnodo26 es una organización que desde 1994 ha ofrecido servicios que han permitido el
intercambio de información electrónica a los colombianos. Con más de 500 clientes dentro
de su historia, Colnodo ha buscado ofrecer tecnologías de la información con enfoque
social, enfatizando temáticas como DDHH, mejoramiento de las condiciones de la mujer,
gobernabilidad, democracia y participación ciudadana, desarrollo sostenible, inclusión
digital y uso estratégico de las TIC para el desarrollo. Cuenta de esto es que son líderes y
pioneros en la implementación de la accesibilidad web además de ser colaboradores en la
construcción de la norma NTC 5854.

Colnodo, vela por la democratización de la información y de los canales de información,

para lograr así una inclusión real del grueso de la población en las plataformas y contenidos
electrónicos.

26 COLNODO. Nosotros. [en línea] 2018 [revisado junio 2018]. Disponible en internet:
https://colnodo.apc.org/es/nosotros

12
4.2.3 Norma Técnica Colombiana NTC 5854
Esta norma tiene como objetivo recoger las pautas de la WCAG para establecer un marco
jurídico en Colombia frente a accesibilidad web y así recoger la iniciativa de la WCAG, es
decir, reducir la brecha digital y expandir la inclusión laboral, educativa y social. El sitio web
de la norma ofrece autoevaluaciones para medir el conocimiento de esta, tutoriales y la
explicación técnica de cada ítem y área a tratar.

Desarrollada por el fondo de Tecnologías de la Información y las Comunicaciones, esta

norma ha sido adoptada por la estrategia de Gobierno en línea como parte fundamental
para su éxito, estableciendo su implementación como obligatoria para los sitios
gubernamentales y haciendo énfasis en temas como formularios de descarga, información
en audio y video, acceso desde dispositivos móviles, consultas a bases de datos, servicios
de interacción, trámites y servicios en línea, entre otros.

4.2.4 Gobierno en Línea

La Estrategia Gobierno el Línea, emitida por el MINTIC en el 2009 “determina los
lineamientos que deben seguir las entidades públicas y los particulares que desempeñan
funciones públicas en la implementación de la Estrategia de Gobierno en línea en
Colombia”27. Ha sido difundida desde entonces en distintas entidades territoriales y
organismos gubernamentales para su implementación.

Esta estrategia plantea 6 componentes, a saber, elementos transversales, información en

línea, interacción en línea, transacción en línea, transformación, y democracia en línea. A
su vez, éstos se componen de actividades, que se enmarcan en la ejecución de sub
actividades o criterios. Cada criterio tiene una ponderación que determina su impacto en la
actividad. Para evidenciar la estructura de los componentes y actividades, en la gráfica 2 se
muestran las actividades del componente 1 Elementos Transversales, entre los que se
define específicamente a la accesibilidad y usabilidad como criterios de la actividad
Centrar la Atención en el usuario.

27 MINTIC, Ob cit. p.2.

13
 Grafica 2 Actividades y criterios componente 1.
Fuente: Manual de Gobierno en Línea. MINTIC
En la más reciente versión de la estrategia, la 3.1, se incluyen 3 anexos. El primero, detalla
la descripción de las actividades, criterios responsables, y herramientas. Entre estas
herramientas, todos los componentes, referencian el cumplimiento de la norma técnica
colombiana NTC 5854, y otros lineamientos de publicidad, guías de usuario, de apertura de
datos y leyes nacionales. El segundo anexo amplía y detalla la Información mínima a
publicar. El tercer anexo, el más relevante para este proyecto: Accesibilidad Nivel de
Cumplimiento AAA, presenta “los criterios de la NTC 5854 para el nivel de cumplimiento
AAA (triple A), detallando cuáles son de obligatorio cumplimiento y cuáles opcionales”28.

Ahora, según los resultados del “Estudio de Nivel de Madurez de las Entidades Públicas
Colombianas en Gobierno Electrónico”29 elaborado durante el 2017 por Colombia Digital e
Ingram Micro, las entidades del gobierno han mostrado un avance en la implementación de
la estrategia Gobierno en Línea, puesto que el 55% de las entidades ha mejorado sus
servicios mediante las TIC, 92% recibe quejas, reclamos y peticiones de usuarios para el
diseño de sus servicios digitales, el 73% “recibe sugerencias de los ciudadanos por canales
digitales (web y redes sociales)”30, el 92% pública datos abiertos. Sin embargo, quedan
varios campos por mejorar, como “En cuanto a cultura de Gobierno Electrónico”.
Cabe resaltar que la priorización del presupuesto, según este informe, presenta en los
últimos lugares la capacitación y la difusión. Considerando que la adquisición de hardware

28 MINTIC, Ob. cit. p 78.

29 CORPORACIÓN COLOMBIA DIGITAL. ¿Cómo está Colombia en gobierno electrónico?. Colombia Digital [en
línea] Mayo 16 de 2017 [revisado julio 2017]. Disponible en https://colombiadigital.net/quienes-
somos/soluciones-tic/item/9728-estudio-como-esta-colombia-en-gobierno-electronico.html
30 Ibidem, pag 5.

14
y software y la contratación personal anteceden a este elemento, se puede pensar que en
un escenario a futuro, aumentarán los recursos para la capacitación y difusión de
contenidos GEL en las entidades gubernamentales.

4.2.5 Derechos en Internet

La Association for Progressive Communications (APC) emite en 2017, la carta de APC sobre
los Derechos en Internet, que reafirma la importancia de la accesibilidad, asegurando que
la “capacidad para intercambiar información y comunicarse libremente usando internet es
fundamental para la realización de los derechos consagrados en la Declaración Universal de
los Derechos Humanos (1948), el Pacto Internacional sobre Derechos Civiles y Políticos
(1976) y la Convención sobre la Eliminación de Todas las Formas de Discriminación contra
la Mujer (1980).”31 En ese sentido, la carta describe 7 enfoques de derechos ciudadanos
que internet debe garantizar, a saber, Acceso a internet para todos y todas, libertad de
expresión y asociación, Acceso al conocimiento, Intercambio de aprendizaje y creación,
Privacidad, vigilancia y encriptación, Gobernanza en internet, Conciencia, protección y
realización de los derechos.
El primer grupo de derechos contempla en especial los derechos relacionados con la
accesibilidad en distintas condiciones de infraestructura, a la formación para uso de la web,
a interfaces accesibles, la inclusión cultural y étnica, entre otras, aspecto fundamental que
retoma la definición de accesibilidad (incluso en bajas condiciones económicas y de acceso)
definida por MINTIC.

5 MARCO METODOLÓGICO
5.1 METODOLOGÍA DE LA INVESTIGACIÓN
Para el desarrollo de la investigación se requiere una metodología que permita abstraer
datos estadísticos (número de usuarios, grado de accesibilidad, entre otros), el
cumplimiento o no de los criterios establecidos en la NTC 5854, el nivel de avance en la
implementación del Gobierno en Línea, y muchas otras variables cuantitativas, así como
una serie de percepciones, evaluaciones y conceptos cualitativos emitidos por los usuarios,
las entidades gubernamentales y sus empleados, organismos nacionales e internacionales,
entre otros actores importantes. Por ende, una metodología mixta permitirá contrastar
estos dos aspectos para formular, por un lado soluciones integrales a quienes ofertan

31 APC. Carta de APC sobre derechos en Internet. Asociación para el Progreso de las Comunicaciones APC [en

línea] noviembre 2006 [revisado junio 2018]. Disponible en: http://www.apc.org/es/node/5795

15
servicios web, y por otro, un consolidado de experiencias que recoja el bagaje teórico y
técnico adquirido, y sirva de base para desarrollos futuros.

En el desarrollo del proyecto se abordó la creación de las aulas virtuales de la Biblioteca

Nacional de Colombia en Moodle y los micrositios de los cursos, y se acompañó el proceso
del sitio web de la Contraloría de Córdoba desarrollado mediante Aplicaciones de Acción.
El tercer sitio que se esperaba abordar en marco del proyecto, era el sitio de Etnoterritorios,
que requería una actualización de plataformas y algunas secciones nuevas. Sin embargo,
por la celeridad que requería el cliente, el proyecto terminó antes de la vinculación formal
del los pasantes a Colnodo, por lo cual este proyecto quedó fuera del proceso.

5.1.1 Participantes
La población objetivo de este proyecto son los usuarios finales de la web con discapacidades
visuales y auditivas o de bajo acceso y conectividad, así como aquellos con deficiencias
cognitivas leves. Durante el proceso de validación de uno de los proyectos, un usuario con
deficiencia visual severa hizo parte del equipo y ejecutó una prueba de accesibilidad y
usabilidad en la primera versión de los micrositios del proyecto de la Biblioteca Nacional.
Dado que el proyecto se desarrolló en conjunto con Colnodo, participaron de la ejecución
del mismo, el equipo de desarrollo (incluidos los diseñadores y equipo legal) y sus clientes.

5.1.2 Instrumentos y equipos

Para la realización de este proyecto, se hizo seguimiento al proceso de desarrollo de los
sitios web, registrando los procedimientos de toma de decisiones con el cliente, con el
equipo de desarrollo, validación, y otras acciones de impacto en el proyecto. Al momento
de la verificación de aplicación de la norma NTC 5854, fue necesario acudir al uso de
validadores automáticos como TAW, AChecker y NTC5854 Validator y lectores de pantalla
como NVDA, así como de revisiones manuales ejecutadas por los pasantes.

En cuanto a equipos, se utilizaron dos computadores portátiles para uso de cada uno de los
pasantes del proyecto, así como aparatos móviles (como celulares o tabletas) suministrados
por Colnodo para la prueba de rendimiento y validación. En los contratos establecidos no
se definió el uso de alguna herramienta específica para el análisis de la accesibilidad del
sitio, por ende no fue necesaria la compra de software licenciado ni equipos adicionales. Y
ya que se considera como un factor de accesibilidad la conectividad, las redes de prueba y
validación deberán ser de distinta capacidad, velocidad, y tipo (móviles y fijas).

5.1.3 Procedimiento
Para lograr los objetivos es preciso dividir en cinco fases el proyecto:
1. Apropiación conceptual: de normas, procedimientos y teoría acerca de la temática. Se
desarrolla previo a iniciar el trabajo práctico con la empresa, y se refleja en el estado del

16
 arte y el marco teórico, sin embargo, de ser necesario, se ampliará durante el desarrollo
del proyecto.
2. Empalme y vinculación institucional: En un corto periodo de tiempo los pasantes
conocen la estructura administrativa de Colnodo, incluyendo los equipos de trabajo en
el área de desarrollo, jefes de procesos, diseñadores, programadores y otros roles. Esta
familiarización es importante para tener claros los flujos de tomas de decisiones y las
cadenas de mando y responsabilidades.
3. Desarrollo: En conjunto con el grupo de desarrollo de Colnodo, se acompaña cada una
de las fases de creación, verificación y evaluación de accesibilidad de sitios web. Esto
comprende el proceso contractual, la metodología de desarrollo, verificación, pruebas y
entrega al cliente. Esta fase demanda de los pasantes alto grado de dedicación pues se
ven implicados en los componentes netamente técnicos y de desarrollo web (hojas de
estilos, maquetación, entre otros). Es el núcleo práctico de la investigación.
La evaluación de accesibilidad en los sitios no solo se hace al final del desarrollo sino al
inicio de la pasantía (cuando ya había un avance en los proyectos) y en otros momentos
del desarrollo, según las particularidades de cada proyecto.
4. Sistematización del desarrollo: Esta etapa transcurre paralela a la fase de desarrollo,
pues por cada paso, llevó riguroso registro. Es nutrida por todos los documentos
derivados de la metodología de desarrollo (diagramas, imágenes, etc.). Es de vital
importancia que incluya registros de tiempos, número de personas desarrollando, horas
de trabajo, flujo de decisiones y demás variables asociadas. De igual forma se
consideraron los problemas y soluciones a lo largo del proceso, las herramientas
utilizadas, modificaciones a los planes, requerimientos y decisiones iniciales, para
garantizar una trazabilidad integral del proceso de desarrollo.
5. Análisis y consolidación de resultados: En esta etapa se contrasta la experiencia
sistematizada con las necesidades y requerimientos encontrados en las primeras fases
de la investigación. El objetivo es analizar la eficiencia de los procesos, buscar
alternativas más rápidas de desarrollo, mejores instrumentos de concertación con el
cliente, alternativas para la validación, entre otros derivados de la experiencia. Cabe
resaltar que las deficiencias en cuanto a herramientas alternativas de desarrollo son
importantes, porque consolidan la base de la innovación en el trabajo a futuro. En esta
última fase se consolidan los entregables como el Manual de accesibilidad, las
conclusiones prácticas y los enfoques de innovación futuros.

5.2 INGENIERÍA DEL PROYECTO

5.2.1 Descripción de la metodología en contexto

La realización de la fase descrita en el numeral 1.5.3, que es la que abarca el desarrollo de

los sitios web, se desarrolla de acuerdo a la metodología propia de trabajo implementada
por Colnodo, que cuenta con el siguiente orden:

17
 1. Contrato: En esta fase se establecen los acuerdos entre ambas partes para la
realización del proyecto en cuestión, se establecen limitaciones, alcances,
validaciones y precios.
2. Diagramación: La diagramación involucra la maquetación de lo establecido con
el cliente mediante herramientas de diseño para establecer gráficamente cual
es la proyección de la página en un .jpg y posteriormente materializarlo en html
y hojas de estilo css.
3. Creación del sitio web: En el proceso de desarrollo se crean casi
simultáneamente las hojas de estilo y el código HTML. Las primeras se cargan
mediante FTP al servidor web. El código HTML se introduce a través de las
Aplicaciones de Acción en las páginas o vistas (bloques de código que se insertan
en las páginas).
4. Validación: Aquí se realiza un proceso de pruebas y verificación de la
accesibilidad del sitio y de su contenido, cargando datos de prueba, realizando
consultas, pasando validadores automáticos por el sitio y realizando ajustes
manuales para que se cumpla con lo establecido en el proceso de contratación.
5. Certificado de conformidad: Una vez terminado el proceso de pruebas se expide
un certificado de conformidad donde se especifica en qué nivel de accesibilidad
se encuentra el sitio. Este certificado usualmente es opcional, y se establece
desde el inicio en la etapa de contratación.
6. Capacitación: De acuerdo a lo acordado inicialmente con el cliente, se realiza un
proceso de capacitación, donde se den lineamientos para que el sitio continúe
con el nivel de accesibilidad adecuado. Esta etapa es opcional.

Cabe resaltar que Colnodo no se rige por ninguna metodología ni lineamientos de desarrollo
tradicional, por ende se acordaron actividades y fechas de entrega de las mismas
acompasadas con el cronograma del equipo de diseño y las fechas concordadas con el
cliente.

5.2.2 Herramienta a utilizar

El presente proyecto requiere herramientas de desarrollo web para lenguaje de hojas de
estilo CSS, un entorno de desarrollo web en HTML y PHP. El CMS que utiliza Colnodo para
sus sitios web es Aplicaciones de Acción, por ende también será necesario una instalación
de la versión más reciente.

Por otro lado, para la realización de las pruebas, de la validación y la verificación de las hojas
de estilo y del sitio en general, es necesario tener al menos los exploradores web más
usados por los clientes, como Mozilla Firefox 57.0.1, Google Chrome 66.0.3 y Opera 53.0.
Para los contratos que incluyen la validación en dispositivos móviles, también se requieren
equipos como celulares y tabletas o en su defecto, los simuladores de estos dispositivos
instalados en los equipos de trabajo.

18
Otras herramientas de software indispensables para el desarrollo del proyecto son los
validadores automáticos de accesibilidad, como TAW, Cynthia Says, NTC 5854 validator. De
la misma forma, la NTC 5854 y la WCAG 2.0 son dos instrumentos de validación manual que
fueron requeridos para el análisis profundo de los sitios web. Por último, los lectores de
pantalla como NVDA, Jaws y Fire Voz, ayudaron a complementar la información
suministrada por los validadores y por la persona con deficiencia visual contratada para tal
fin, y permitieron garantizar el nivel real de cumplimento de la norma NTC 5854.

6 RESULTADOS Y DISCUSIÓN
6.1 SISTEMATIZACIÓN DEL DESARROLLO
Durante el ejercicio de pasantía se trabajó puntualmente en dos proyectos, uno con la
Contraloría de Córdoba y otro con la Biblioteca Nacional de Colombia. A continuación se
realiza un recorrido por los avances realizados en el proceso de desarrollo de dos sitios web
en Colnodo en torno al mejoramiento de sus prácticas de desarrollo sobre accesibilidad.

6.1.1 Contraloría de Córdoba

6.1.1.1 Descripción del proyecto

Colnodo desarrolló el sitio web de la Contraloría de Córdoba, a través de la plataforma
Aplicaciones de Acción, soportada en PHP. Al ser una entidad estatal, la Contraloría de
Córdoba debe permitir un fácil acceso para todo tipo de usuarios, tanto a la información
pública que la entidad debe suministrar (contratación, presupuesto, normatividad, control),
como en los servicios que ofrece a los usuarios, como quejas y reclamos, consultas, entre
otras.
En el diseño planteado para este sitio, se agrupan las funcionalidades principales en tres
grandes bloques (Peticiones, quejas reclamos y Denuncias PQRD; Atención e información al
ciudadano; y transparencia y acceso a la información), que se complementan con las
opciones desplegadas en el menú principal: Funciones y estructura, Normatividad,
Presupuesto, Planeación, Control y Contratación. En la presentación de la información se
usan diversos recursos y herramientas, como por ejemplo enlaces y documentos en PDF,
listas de contenidos organizados alfabéticamente, encuestas, acordeones, banners,
imágenes descriptivas, pestañas que presentan los contenidos, imágenes con títulos para
desplegar noticias, formularios, sistemas de búsquedas, calendario de actividades, tablas
con enlaces de descargas, cápsulas compuestas de información de funcionarios y
entidades, blogs, enlaces externos, entre otros.

19
6.1.1.2 Estado inicial
De acuerdo a lo planteado en la metodología, la vinculación a este proyecto se hace pasado
el proceso contractual con la Contraloría de Córdoba, cuando el diseño del sitio ya estaba
definido y el proceso de desarrollo estaba en curso. Por ende la primera tarea que se adopta
es la revisión de accesibilidad de los componentes desarrollados y de la estructura general
del sitio web, con el objetivo de hacer ajustes en los elementos implementados en el sitio,
y de proponer al equipo de desarrollo mejores prácticas que repercutan en menos vacíos o
fallas de accesibilidad para el resto del sitio web.
Para este momento se estudian la página de inicio y la estructura general del sitio (header,
footer, menús), los formularios de recepción de solicitudes y el calendario de actividades.

6.1.1.3 Evaluación de accesibilidad inicial

Mediante el validador de accesibilidad TAW, se encuentran errores relacionados sobre todo
con las imágenes e iconos sin atributo alt asignado. Estas se corrigen agregando este
atributo con contenido descriptivo o dejándolo vacío (alt=””), dado que muchos iconos
presentes están acompañados de letras o enlaces, por ende su función es decorativa. En
otras ocasiones, al anidar enlaces <a> e imágenes <img>, el validador señala que la etiqueta
<a> está vacía. Esta observación se resolvió dejando la imagen dentro del enlace, ya que no
era posible poner texto al enlace en si mismo.
Otro error recurrente detectado con TAW fue la estructura definida en los formularios. La
mayoría de éstos no contaban con atributos for para ligar los campos input con los campos
label; tampoco se creaban elementos fieldset para agrupar respuestas múltiples
(radiobuttons y check buttons), lo que generaba confusión al recorrer con el lector de
pantalla y con el teclado el formulario. Se agregaron estos elementos, encontrando mayor
dificultad en aquellos formularios en los que más de un input corresponde a un solo label
en el sentido estricto, como se puede apreciar en la siguiente imagen, en estos casos, una
opción es agrupar estos elementos, en un fieldset, por ejemplo, con un title o etiqueta que
describa su funcionamiento.

Grafica 3 Campo de un formulario con un label y dos inputs relacionados

Fuente: Formulario PQRD Contraloria de Córdoba

En uno de los menús que encapsulaba divs, imágenes (sin descripciones), enlaces y
encabezados en cada ítem. Se reacomodo el orden de cada uno de los elementos para evitar
etiquetas vacías, se agregaron descripciones a las imágenes y se eliminaron algunas
etiquetas caducas.

20
En las múltiples páginas en las que se presentan documentos públicos mediante enlaces
para descargar los archivos en PDF u otros formatos, se agregaron titles a los enlaces que
describieran al usuario claramente qué documento descargaría,y ya que en contadas
ocasiones estos enlaces estaban acompañados por iconos, también se incluye el alt=””.
Un problema reportado y que no es apreciable a simple vista, es el uso de etiquetas de estilo
en el HTML. En especial la etiqueta <center> y la etiqueta <i> En el primer caso se
modificaron las clases del contenedor de elementos para lograrlo centrar, y en el segundo
caso, se usaba el <i> exclusivamente para integrar un conjunto de características mediante
la hoja de estilos. En este sentido, se reemplazaron los <i> con <div> manteniendo las
propiedades asignadas mediante las clases de las hojas de estilo.
El calendario de actividades se despliega en una tabla que no contenía elementos
descriptivos que guiarán al usuario. Para esto se incluye la etiqueta caption en la misma con
una breve descripción del contenido desplegado

Otra metodología para la evaluación fue el recorrido manual y mediante el lector de

pantalla por distintas páginas del sitio. Este ejercicio permitió destacar y evaluar algunos
ítems de “alertas” o “no evaluados” reportados por TAW, como por ejemplo el título
coherente y claro de cada página, la estructura del sitio en general, que las imágenes en en
la parte superior tengan los atributos alt y que los enlaces tengan el title, la ubicación de
cada bloque de contenido de forma coherente y secuencial, entre otros,
Recorriendo por teclado el sitio, saltaron a la vista problemas de acceso a la información
que no fueron detectados por el TAW. En el footer del sitio, por ejemplo, se ubicó la
información institucional de contacto importante, pero a pesar de que la sección está “bien”
delimitada, no se podía acceder al conjunto de la información, pues los elementos <li>,
<div> y <span> usados para desplegarla son “invisibles” para quien recorre mediante tab el
sitio. En este sentido, se agregan atributos tabindex=”0” a cada elemento de la lista,
forzando al usuario y al lector de pantalla a recorrer cada uno de los elementos, tuviera o
no enlaces relacionados.

Gráfica 4: Footer con lista de información institucional accesible

Fuente: Sitio web Contraloría de Córdoba.

21
La revisión manual también sirvió para determinar que al recorrer el sitio web fuera
coherente y clara la información desplegada en las páginas y los menus de usuarios. Se
verificó, que por ejemplo, que en los menús desplegables no se leyera el contenido que no
era visible, hasta que el usuario los desplegara.

6.1.1.4 Declaración de Conformidad del sitio

Al final del desarrollo del sitio, después de las correcciones iniciales y después de compartir
con el equipo de desarrollo las observaciones buscando incorporar a las dinámicas de
trabajo cotidianas sencillos cambios en el desarrollo, se hace la revisión de accesibilidad
nuevamente para entregar el producto al cliente con la declaración de conformidad en nivel
de accesibilidad AA.
En la elaboración de este documento, surge la necesidad de seleccionar las páginas del sitio
de la Contraloría que se iban a evaluar. El criterio de selección incluyó los elementos en los
que se habían encontrado mayor número de problemas (especialmente con formularios), y
aquellas páginas con contenidos fuera de lo común (como presentación y descarga de
archivos) más la página de inicio.

Se aborda inicialmente, la evaluación del header, menu y footer del sitio web, que
permanece igual para todas las páginas. El desarrollo con las Aplicaciones de Acción permite
que los cambios realizados en estas vistas se mantengan para todas las páginas, por lo que
no se encuentran nuevos errores o advertencias en estas zonas.
Al abordar las páginas que incluyen documentos, fue fundamental la revisión con el lector
de pantalla que permitió saber si el contenido desplegado mediante listas era
suficientemente claro para los usuarios invidentes. Ya que el nombre del documento era el
contenido de la lista, los alt se configuraron para que solamente indicaran la acción:
descargar archivo, y así evitar la redundancia. En los formularios los ajustes mencionados
previamente se verificaron de nuevo, dando énfasis en la comprensión del usuario al
escuchar el formulario y los campos (es decir los atributos name y for) y en que tuvieran un
recorrido secuencial por las opciones múltiples, especialmente.
Para el momento de esta última revisión, el sitio y sus secciones habían aumentado
considerablemente respecto a la primera evaluación, por ende aunque no se refleje en la
declaración de conformidad, se revisaron páginas con listados, pestañas y tabs, en donde el
validador no encontró grandes dificultades, pero mediante la evaluación manual se
detectaron zonas “invisibles” al recorrer el sitio por teclado, como listados elementos div,
listas y span. A estos se les agregó el atributo tabindex=”0” para que se tuvieran en cuenta
a la hora de recorrer el sitio.
Por último, vale decir que, en general, todo el desarrollo del sitio fue realizado, por bloques
de contenido ubicados de izquierda a derecha y de arriba hacia abajo, facilitando el
recorrido total del contenido con el lector de pantalla de forma ordenada y coherente,
evitando que el usuario se pierda en el sitio web.

22
6.1.2 BNC
La Biblioteca Nacional de Colombia (BNC) es una entidad encargada de preservar el material
bibliográfico y documental del país en pos de ofrecerlo y ponerlo al servicio de la sociedad
en general32.

6.1.2.1 Descripción del proyecto

Colnodo fue contratado para el diseño, desarrollo e impulso de una plataforma virtual que
brinde una serie de cursos para bibliotecarios de todo el país, en donde puedan
autónomamente formarse en técnicas de manejo de bibliotecas con el objetivo de cualificar
las diferentes iniciativas que existen artesanalmente en todo el país.
La plataforma fue desarrollada en Moodle por su capacidad de gestión en cursos y aulas
virtuales, dentro de los cursos que se ofrecen y una de las razones fundamentales para
hacer este proyecto parte de este trabajo de grado es un curso focalizado en capacitar a los
bibliotecarios en brindar un servicio de biblioteca adecuado para personas con algún tipo
de discapacidad, y que más coherente, que este curso en sí mismo, esté disponible y sea
accesible para las personas en condición de discapacidad. Por otro lado hay que recordar
que los lineamientos de Gobierno en Línea exigen a los sitios gubernamentales adoptar las
medidas de la NTC 5854, por lo que la Biblioteca Nacional de Colombia no puede ser
indiferente y debe acatar dichos lineamientos.

6.1.2.2 Estado inicial

En el momento en que nos incorporamos al proyecto, el desarrollo se encuentra en su fase
naciente, el equipo de desarrollo de la organización realiza la adaptación de un tema de
Moodle según el estilo concertado con la BNC, lo que nos permite desde un principio
proponer prácticas para garantizar la accesibilidad del sitio, y por supuesto contribuir en el
desarrollo mismo del proyecto.
El diseño de cada curso individualmente, se encontraba en el mismo estado. Dado que el
esfuerzo más grande en este campo lo realizan profesionales en el área de la docencia
(diseño de contenidos curriculares y virtualización de temáticas), no hubo mayor trabajo,
aunque fue fundamental trabajar de la mano con el área de diseño gráfico para lograr
plantillas que garantizaran de entrada la accesibilidad de los cursos.

6.1.2.3 Estudio plataforma Moodle

Uno de los primeros resultados en este proyecto fue el estudio y la elaboración de un
documento que recoge errores de accesibilidad que tiene la plataforma Moodle 3.0, con la
ayuda de validadores automáticos y recorridos por teclado y con lector de pantalla.

32 ¿Quienes somos? Sitio Web Biblioteca Nacional de Colombia, disponible en:

http://bibliotecanacional.gov.co/es-co/Footer/biblioteca-nacional-de-colombia/quienes-somos

23
Este proceso está sistematizado en el Anexo 2.
En este estudio se simula un curso y algunas de las actividades que brinda el mismo para
realizar la evaluación. Las siguientes son algunas de las conclusiones, comentarios y
apreciaciones que se desprenden de este estudio.
Las secciones de una instalación estándar de Moodle analizadas aquí fueron:
● Página de validación o login
● Página principal
● Vista general de cursos
● Página de un curso
● Páginas de actividades
o Textos
o PDF
o Embebidos
o Exámenes
Se tomaron para el análisis estas secciones ya que en el diseño del sitio, únicamente estas
secciones del Moodle se van a utilizar.
El análisis automático realizado con la herramienta TAW arroja los errores sintácticos del
código que según la WCAG son problemáticos a la hora de querer garantizar accesibilidad
en una plataforma o sitio web. Moodle es una plataforma reconocida por facilitar de gran
manera la gestión de cursos virtuales con ayuda de múltiples herramientas, pero con
errores de accesibilidad bastante recurrentes.
Otra herramienta utilizada que fue fundamental para el análisis de páginas que requerían
un inicio de sesión fue el sitio ntc5854.org/validador/checker, ya que permite subir la página
a analizar, descargandola previamente. Esto fue de gran ayuda para lograr un análisis más
completo de la plataforma, que en su mayoría requiere dicho inicio de sesión.
En el análisis arrojado por las herramientas automáticas se pueden encontrar elementos
como:
● Mala jerarquización de los títulos.
● Errores de cierre de etiquetas y en el caso de los scripts una identificación errónea
de estos.
● Uso de etiquetas caducas.
● Imágenes sin una identificación ni descripción adecuada.
● Ítems de formularios sin una etiqueta que los identifique claramente.
Realizando un análisis manual de esas mismas páginas, es notable que los errores
detectados previamente, tienen gran repercusión al navegar en el sitio, elementos como,
omitir los textos alternativos, jerarquizar erróneamente los títulos y otros elementos
mencionados anteriormente, terminan extraviando a un posible usuario invidente dentro
del sitio. Además de esto, hay un elemento identificado bastante problemático, es el no

24
permitir acceder a ciertos elementos mediante tabulaciones, quitando sentido para las
personas que recorren de esta manera los sitios.
Es necesario decir que a pesar de realizar modificaciones que logran garantizar en cierta
medida la accesibilidad de una plataforma tan compleja, todavía hay mucho por mejorar en
este aspecto, la dependencia de JS, las interfaces de administración, son un ejemplo del
largo trabajo que se tiene en este campo, más aún cuando se habla de gestores de
contenido tan robustos.

6.1.2.4 Análisis de micrositios (cursos)

La estructura del aula virtual para la BNC consiste en varios cursos que, de acuerdo al estilo
de desarrollo de Colnodo, se llamaron micrositios, y son sitios diseñados por fuera del
Moodle pero que se conectan con la base de datos y las funcionalidades de este. Estos
micrositios requerían para su diseño, una base que permitiera a todos mantener una
estructura similar.
El trabajo desarrollado aquí, consistió en revisar la plantilla base de micrositio construida y
realizar las modificaciones al código y al diseño para que el conjunto de los cursos tuvieran
una estructura y despliegue accesible.
Para la corrección de la plantilla base, el punto de partida fue una revisión realizada por un
experto en tecnologías accesibles, que ha empatado su experiencia de usuario con
discapacidad visual con los conocimientos técnicos adquiridos en esta área. Estos resultados
fueron fundamentales para el análisis tanto de los micrositios como del conjunto de
revisiones elaboradas, puesto que se entiende el porqué de algunas pautas de la NTC 5854;
ya que pueden parecer prácticas banales pero si no se implementan desorientan de gran
manera a usuarios en condición de discapacidad dentro de la página.
Como en la mayoría de los sitios, esta plantilla presentaba problemas con la jerarquización
de los títulos, la identificación por medio de title en algunos elementos e imágenes sin texto
alternativo que permita su reconocimiento. Llama la atención cómo estos errores que
parecen tan mínimos, los identificó el usuario mencionado, mediante su experiencia al
navegar, e incluso recomendaciones que arrojan las herramientas automáticas las detecta
este usuario, aunque con un nivel de precisión menor pero con gran certeza de lo que se
dice.
Una experiencia que arrojó importantes aprendizajes, fue generada por la necesidad de
desplegar un índice en forma de rayuela; visualmente era bastante estético y entretenido,
pero era absolutamente inaccesible, la navegación por tabulaciones no era posible, cada
casilla eran imágenes y el usuario no tenía ni idea a dónde le dirigía cada casilla.
Luego de la revisión se propusieron 3 alternativas orientadas a garantizar mayor
accesibilidad en la rayuela (pues era un requerimiento puntual del cliente). Luego de
discutir las alternativas con la persona al frente del diseño, y acordando las características
mínimas que el índice debía tener, se seleccionó una de las alternativas presentadas, la

25
que mejor garantizara la accesibilidad, y se procedió a desarrollar el código en CSS y en
HTML. Esto implicó reemplazar imágenes por enlaces debidamente etiquetados con
descripciones, y escritos como lista en orden ascendente, y para que se visualizará como
una rayuela real (de abajo hacia arriba) se crearon las clases para alterar el orden de
presentación de la lista de números y la creación de clases que permitieran mostrar la lista
de números como una cuadrícula de rayuela (en orden descendente).

Grafica 5 Vista de la rayuela accesible en un micrositio

Fuente: Micrositios Aula Virtual BNC

6.1.2.5 Correcciones
Las modificaciones realizadas en el Moodle, luego del análisis automático y manual se
presentan a continuación, y una explicación más detallada de los mismo se registra en el
Anexo 3.

 Títulos
Es importante ser claros al determinar los títulos de los módulos de los cursos, del aula
virtual y de la página en sí misma, la norma pide que sean claros y descriptivos.
Moodle respeta el uso ordenado de headers excepto en el título general del curso, señalado
con <h1> que es seguido por un <h3> en los subtítulos del sitio. Aquí se recomienda cambiar
el título del curso para que corresponda con el orden de anidación.
 Formularios acceso de usuario
Los formularios en Moodle no hacen validación previa al envío de información de los datos
ingresados. De considerarse necesario este aspecto, se requiere limitar los tipos de datos
que se ingresan a los formularios.
No todos los formularios cuentan con un campo fieldset para describir su contenido o
finalidad. Se sugiere agregarlos para mejorar la navegabilidad. Adicionalmente, se puede

26
mejorar la experiencia de usuario si se agregan etiquetas descriptivas a los campos de texto,
que parecen invisibles y poco claras al ser recorridas por el lector de pantalla.
 Botón “Back to top”
Este botón está presente en casi todas las páginas y aparece cuando el usuario ha recorrido
la página y está llegando a las secciones finales. El botón presenta varios problemas,
empezando con que el nombre del botón está en inglés y que no tiene atributos que guíen
al usuario. La recomendación es utilizar un título para el botón o un alt para el icono del
botón que permita comprender al usuario la funcionalidad del botón.
 Estilo de texto
Moodle ofrece un editor de HTML para la redacción de introducciones, textos, contenido,
etc. En estos elementos el uso de las etiquetas <i> y <b> debe evitarse, puesto que el lector
de pantalla no lo reconoce. A menos que sea irrelevante el estilo de la letra, deben usarse
las etiquetas <strong> o <em>.
 Focalizar elementos
Algunos cuadros de texto, lecturas, u otros elementos que no tienen un link, no son
focalizables al recorrer la página mediante tabulaciones, lo que hace que si se piensa
navegar de esta manera, se queda mucho contenido fuera del rango de accesibilidad. Para
corregir esto, basta con identificar dichos elementos que se quiere focalizar y agregarles
mediante el código fuente o editores HTML del mismo Moodle, el atributo
tabindex=”0”. Esta recomendación es fundamental para la página que despliega los temas
de los cursos, puesto que estos se despliegan en una lista que no se puede recorrer. Es decir,
agregar el atributo tabindex=”0” a los elementos ul en la clase.
 Contenido auditivo
Videos o audios serán imposibles de percibir por personas con discapacidad auditiva,
por lo que se recomienda generar los subtítulos para los videos o un texto alterno
que resuma o transcriba la información de dichos contenidos.

Del mismo modo, las correcciones realizadas en los micrositios señalados se presentan a
continuación, y pueden ser detalladas en el Anexo 3.
 Menú
El botón que despliega todo el menú, era una imagen sin ninguna descripción dejando
prácticamente invisible el conjunto de los cursos y herramientas que ofrecía el sitio.
Este menú estaba oculto a la vista hasta que dieran click al botón pero para el navegador
siempre estaba presente el menú, por lo que al recorrerlo con tabulaciones se perdía
recorriendo algo que no se veía pero estaba ahí. Solucionado agregando atributo hidden a
este menú y corrigiendo el script para dar el efecto original.
Por último se agrega un scrollbar a este menú.

27
  Títulos
Se corrige la jerarquía de los títulos según la lógica del sitio.
 Recursos
El micrositio brinda un repositorio de recursos según la necesidad del curso, gracias a la
revisión del experto mencionado, se vio la necesidad de identificar estos repositorios con
una descripción clara, ya que en caso de encontrarse vacíos, se confunde su usabilidad.
 Contenido
Los cursos requieren de contenido multimedia que ayuden al estudiante en su proceso de
aprendizaje, este contenido significa un gran reto ya que al ser multimedia se necesita de
opciones alternas para que el espíritu del contenido sea apropiado por cualquier
estudiante.
 Audios
La descripción de estos debe ir en dos vías, una que describa a que hace referencia este
audio y otra que de la instrucción de reproducción.
 Imágenes
Imágenes no decorativas llevan una breve descripción con atributos alt, otra buena práctica
es colocar pies de página a las imágenes dejando el texto alternativo vacío. Si la imagen en
sí misma tiene gran información (infografías, flyer, etc.), queda a opción según estilo, si usar
atributos longdesc o transcribir de la mejor manera esa información a un párrafo cerca a la
imagen.
 Lecturas PDF
El iframe utilizado en este sitio no permitía la lectura mediante lectores de pantalla, una
opción sugerida fue dejar la opción para descargar los PDFs y re abrirlo con el lector del
navegador que sí permite esta lectura.
Además de estos contenidos se agregaron recursos embebidas de aplicaciones exteriores,
que tienen algunas falencias de accesibilidad, pero al no permitir modificaciones, no fue
posible hacer accesibles este tipo de recursos. Este es un ejemplo de los casos en los que
por más cuidadosos y preventivos que se sea con la planeación y el desarrollo, no se puede
garantizar la accesibilidad al 100% en el sitio.
Se destaca la necesidad de vincular a todo tipo de contenidos y aplicaciones con las
prácticas de accesibilidad para evitar estas situaciones.

6.1.2.6 Declaración de conformidad

Este documento es presentado a la Biblioteca Nacional de Colombia, como una garantía
inicial de accesibilidad, dejando un precedente que asegure en qué estado de accesibilidad
se encuentra el sitio en una fecha determinada, puesto que las prácticas y contenidos
adicionales cargados al sitio posteriores a la entrega final pueden comprometer aspectos
de la accesibilidad, y contractualmente Colnodo no es responsable.

28
Se analizaron 5 páginas en este sitio, que se consideraban las más problemáticas y que
abarcaban la mayor parte del contenido, para poder tener una muestra significativa del
mismo. Empezando con el inicio que es fundamental para guiar desde un primer momento
al usuario, este debe garantizar el poder desplazarse y navegar por la mayor parte del aula
virtual sin mayor complicación. Desde acá se revisó que los elementos del header (menú,
buscadores, logos) y los del footer (redes sociales, información, contactos) que son los que
se replican en el conjunto de las páginas, tuvieran óptimas condiciones de accesibilidad. Las
otras páginas examinadas contenían elementos como formularios, calendarios, videos,
datos de contacto e instructivos de navegación del sitio, entre otras. La mayoría de estos
elementos atendieron las recomendaciones y modificaciones hechas inicialmente así como
en algunos casos, hubo necesidad de ajustar características y así presentar un sitio con un
nivel de accesibilidad AA.

6.1.3 OBSERVATORIO DE TERRITORIOS ÉTNICOS Y CAMPESINOS

El Observatorio de Territorios Étnicos y Campesinos es una instancia de investigación y
acompañamiento adscrito al Departamento de Desarrollo Rural y Regional de Facultad de
Estudios Rurales y Ambientales de la Pontificia Universidad Javeriana. Tiene como objetivo
contribuir a proceso de reconocimiento, ordenamiento, gobierno propio, titulación
colectiva y protección de la territorialidad étnica, con énfasis en comunidades afro
descendientes y campesinas del Cauca, el Chocó y el Caribe colombiano, entre otras
regiones33.

Colnodo se encargó de rediseñar y actualizar su plataforma web (www.etnoterritorios.org),

incluyendo una herramienta que permitiera la ubicación de los Consejos Comunitarios en
distintos departamentos del país (http://consejos.etnoterritorios.org). Desde el ejercicio de
esta pasantía se pretendía acompañar el proceso de diseño del sitio web, la diagramación
de las secciones nuevas (especialmente el mapa de los Consejos Comunitarios) y la
integración de éste con el sitio web principal y las Aplicaciones de Acción.

La herramienta incorporada consiste en un mapa interactivo que permite la navegar por

los departamentos y al seleccionar uno, se despliega la información de éste, incluyendo una
lista de todos los consejos comunitarios asociados al departamento; cada consejo tiene una
ficha de sistematización de información.

Durante este proceso, al igual que con los otros dos proyectos se esperaba realizar la
evaluación de accesibilidad del sitio web, específicamente de la herramienta usada para

33 ¿Qué es el observatorio? Disponible en línea http://etnoterritorios.org/QueObservatorio.shtml

29
desplegar el mapa de los consejos; mediante evaluaciones automáticas y un recorrido
manual del sitio, e ir aplicando las correcciones antes de la entrega del proyecto.

Sin embargo es necesario decir que los tiempos de la empresa y los de ésta pasantía no
coincidieron específicamente en este proyecto, dado que el desarrollo y la entrega del sitio,
terminó recién se empezó a trabajar sobre los proyectos acordados Anexo 4.

Atendiendo a las limitaciones inicialmente planteadas donde quedó estipulado que el

desarrollo de la pasantía se atenía a las condiciones de Colnodo y su equipo de desarrollo,
se presenta a continuación el resultado de este proyecto, resaltando que los pasantes no
tuvieron participación de este.

Grafica 6 Vista del cabezote y menú principal del sitio web

Fuente: Observatorio de territorios étnicos y campesinos

El sitio se centra en mostrar los proyectos en curso del Observatorio y sus resultados y
cuenta con las siguientes páginas:

● Descripción del observatorio.

● Editorial donde se encuentra la producción documental del observatorio. Los
elementos más importantes para la evaluación eran los textos alternativos de las
imágenes, la navegabilidad con tabulaciones y la correcta sintaxis del código fuente.

30
 Grafica 7 Vista de la zona central de la página editorial
Fuente: Observatorio de territorios étnicos y campesinos

● Centro de documentación donde se almacenan todos los documentos que

competen a la temática propia del observatorio, este cuenta con un buscador para
facilitar la navegabilidad en la documentación, categorizado por temáticas y
regiones. La evaluación contemplaba la correcta navegabilidad mediante
tabulaciones y la identificación de los ítems del formulario.

Grafica 8 Vista de la zona central de la página Centro de documentación

Fuente: Observatorio de territorios étnicos y campesinos

● Repositorio de archivos multimedia categorizado por regiones. Por su estructura, se

evaluaría la navegabilidad de la página y la presentación de los archivos multimedia,
en especial con el lector de pantalla.

31
 Grafica 9 Vista de la zona central de la página de Multimedia
Fuente: Observatorio de territorios étnicos y campesinos

● Sistema de información geográfica para facilitar la consulta de información

recopilada por el observatorio. La evaluación se centraría en evaluar la
navegabilidad y descripción de cada ítem de la herramienta.
De entrada por la forma en la que funciona el recorrido dentro del mapa, la
inexistencia de controles HTML, entre otras, habría que evaluar la pertinencia de
corregir las falencias en accesibilidad de la herramienta mediante el código fuente,
buscar alternativas distintas para la presentación de la información, o aclarar el
funcionamiento de la herramienta y sus limitaciones de acceso por ejemplo para
población ciega

32
 Grafica 10 Vista del Sistema de Información Geográfica
Fuente: Observatorio de territorios étnicos y campesinos

El sitio también cuenta con páginas para la consulta de noticias y artículos desarrollados. En
éstas la evaluación consistiría en una revisión mediante lectores de pantalla, la etiquetación
adecuada de imágenes, enlaces y formularios en el contenido central de cada sección,
puesto que en general el esquema (menús, etc) no cambia.

Este menú principal y los alternos de la zona derecha cuentan con algunas ventajas en
términos de accesibilidad, como la navegación mediante teclado y el cambio de estilo
bastante notable en los elementos que se recorren.

6.2 RETOS Y RECOMENDACIONES PARA LA APLICACIÓN DE ACCESIBILIDAD

Con el proceso desarrollado en Colnodo, es posible extraer aprendizajes y retos a nivel
organizativo y personal como desarrolladores en la implementación de la norma NTC 5854.
Estos aprendizajes, retos y recomendaciones se recogen de forma amplia en el Manual de
Accesibilidad (Anexo 1) sin embargo, en miras de interesar a otros estudiantes y
desarrolladores en el campo de la accesibilidad, se esbozan a continuación algunas
recomendaciones para abordar el desarrollo de un sitio web accesible de acuerdo a la
norma NTC 5854.

6.2.1 Conocer la norma

Antes de iniciar el desarrollo de un sitio accesible, hay que comprender qué aspectos hacen
que un sitio web sea accesible. Según la WCAG y la NTC 5854, el grado de accesibilidad de
un sitio se determina a través de cuatro principios: Perceptible, Operable, Comprensible y
Robusto. Cada principio contiene varios lineamientos sobre las características que en ese
ámbito debe cumplir el sitio web. Estos lineamientos tienen diferentes niveles de
cumplimiento según el grado de accesibilidad que se quiera cumplir.

33
Es importante que tanto el equipo de desarrollo como quienes harán la evaluación de
accesibilidad conozcan la norma, los aspectos que evalúa y los ámbitos de aplicación de
cada una de las recomendaciones.

En este sentido, un reto es la difusión y promoción de los contenidos de la norma, tanto

para organizaciones que trabajan con población en distintas condiciones de discapacidad,
como para las organizaciones que no, y para los desarrolladores en general, especialmente
cuando el índice de conocimiento en legislaciones de accesibilidad por parte de los
diseñadores web ascendía en el 2009 a tan solo el 21,9% y a 31,6% en cuanto a técnicas de
desarrollo de sitios web accesibles34.

6.2.2 Definición del grado de accesibilidad

Una vez familiarizados con la norma, es necesario que dependiendo de las especificaciones
de cada proyecto se defina el grado de accesibilidad necesario. Algunos factores
fundamentales para esta elección son: el tipo de usuarios que tendrá el sitio web y las
condiciones de discapacidad que pueden presentar; si el sitio a desarrollar debe cumplir
con los lineamientos establecidos en la estrategia de Gobierno en Línea; los tiempos de
desarrollo disponibles y la experiencia en desarrollos accesibles, el tipo de contenidos que
requiere desplegar el sitio y la flexibilidad para presentarlos. Un grado AAA de accesibilidad
limitará el uso de herramientas frecuentes, y requerirá mayor rigurosidad en el desarrollo
y la evaluación del sitio, mientras que un nivel A de accesibilidad requerirá conocer la norma
y aplicar las recomendaciones dadas. Por ende se debe ser conscientes que al iniciar un
proceso de desarrollo accesible hay que considerar que el tiempo de desarrollo puede variar
según la experiencia institucional y de los desarrolladores, entre otras variables, e incluir
estos costos de tiempo y posiblemente personal en el presupuesto y cronograma del
proyecto.

6.2.3 Desarrollo accesible

Al iniciar el proceso de evaluación de los sitios web fue notoria la ausencia de algunas
prácticas mínimas de desarrollo con enfoque accesible (como por ejemplo la inclusión del
atributo alt en las imágenes) que hicieron que en la primera evaluación automática se
registraran bastantes errores. Posterior a esto, al participar más activamente del proceso
de desarrollo y de corrección de los sitios, se evidenció que el equipo de generación de
contenidos logró asimilar con relativa facilidad pequeños cambios en la construcción de los
sitios, como reemplazar etiquetas, uso adecuado de los encabezados, etiquetas label y

34 Metodología de evaluación de accesibilidad web para personas con limitaciones visuales. Disponible en
línea http://repositorio.utp.edu.co/dspace/bitstream/handle/11059/1332/371911A811.pdf

34
títulos en imágenes, videos y otros recursos multimedia, que se vieron reflejados en una
evaluación con menos errores de forma, lo que dio más tiempo para dedicarse a asuntos
de carácter funcional del sitio.

Esta experiencia nos permitió reconsiderar la forma en la que se desarrollaba el proyecto,

evaluando los sitios sin mayor interacción con el equipo de desarrollo. En adelante, la
estrategia fue poner en conocimiento de todo el equipo de diseño y desarrollo los
resultados de la evaluación y las sugerencias y recomendaciones para que estuvieran al
tanto de los cambios ejecutados en las plataformas y poco a poco se fueron empapando
más de la norma y sus aplicaciones, e incluso de los mecanismos de verificación de algunos
aspectos de la norma, como el recorrido por teclado. Este canal de comunicación más
permanente permitió también, que mientras se diseñaban las plantillas de los micrositios,
por ejemplo, se hicieran evaluaciones manuales expres que evitaban que se perdiera
tiempo puliendo módulos que no eran accesibles, y más bien trabajar en la creación de
nuevos estilos que si cumplieran la norma.

En este sentido se ve de forma positiva la articulación permanente entre el equipo de diseño

y desarrollo, en especial en etapas de planificación y desarrollo inicial, y se establece como
un reto la forma en que las organizaciones puedan promover un trabajo sinérgico entre
éstos.

6.2.4 Metodología de evaluación

Existen diversas metodologías de evaluación de la accesibilidad ajustadas a las WCAG1.0
como la UWEM en Europa, las orientadas a la revisión de estándares mediante Evaluaciones
heurísticas, las Simulaciones de diseño, las Técnicas de filtrado, y Pruebas de usabilidad,
recopiladas en Ascencio & et.35 Estas metodologías coinciden en la necesidad de
complementar un análisis automático con herramientas como TAW, W3C Markup
Validation Service, WDG HTML Validator y AChecker, con una revisión manual que permita
analizar elementos que se escapan a los validadores como la pertinencia de textos
alternativos en las imágenes, la coherencia en el recorrido por teclado del sitio entre otras.
Sustentados en esta coincidencia y en las recomendaciones de De Oleo y Rodríguez36 se
formula una metodología que plantea la realización de la evaluación manual posterior a una
revisión automática, puesto que la evaluación automática abarca varios lineamientos y deja
una ruta de trabajo en los elementos no verificados o advertencias. Pero además, el
ejercicio práctico nos permitió distinguir un posible paso previo a la evaluación automática,

35Metodología de evaluación de accesibilidad web para personas con limitaciones visuales. Disponible en
http://repositorio.utp.edu.co/dspace/bitstream/handle/11059/1332/371911A811.pdf
36 Pautas, métodos y herramientas de evaluación de accesibilidad web. Disponible en

http://revistasum.umanizales.edu.co/ojs/index.php/ventanainformatica/article/viewFile/185/233

35
una evaluación o validación de la sintaxis del HTML y el CSS. A pesar de que este aspecto se
abarca en las revisiones automáticas bajo el principio Robusto, resulta mucho más sencillo
y práctico evaluarlo antes de hacer el análisis del sitio.

36
 7 CONCLUSIONES

● El desarrollo de los sitios web de la Biblioteca Nacional de Colombia y de la Contraloría

de Córdoba y su adaptación a la norma NTC 5854 fue sistematizado en documentos que
reflejan los resultados de las evaluaciones de accesibilidad y las correcciones
implementadas. Esta sistematización, complementada con la experiencia de participar
en el proceso de desarrollo de los sitios, permitió la creación de un manual de
accesibilidad acorde con los procesos, metodologías y herramientas propios de
Colnodo, que su vez es aplicable en otros entornos. Mediante la aplicación y
retroalimentación de los lineamientos establecidos en el manual, Colnodo tiene la
oportunidad de fortalecer sus prácticas y metodologías de desarrollo web accesible.
Esta primera versión del Manual de Accesibilidad permite a Colnodo compartir y
difundir la experiencia adquirida con otras organizaciones y desarrolladores.
● La experiencia en Colnodo permitió a los pasantes incorporar y naturalizar sencillas
prácticas como desarrolladores, que hacen los sitios más accesibles y enriquecen la
experiencia del usuario, sólo mediante el conocimiento, implementación y evaluación
de las pautas de accesibilidad y la NTC 5854.
● La presentación de forma sencilla y concreta de las pautas establecidas en la NTC 5854
para los equipos de desarrollo y la fácil apropiación que algunas de estas lograron tener,
develan que no es un imposible la transición de un desarrollo web tradicional hacia un
desarrollo web con elementos accesibles. El conocimiento de las normas y la definición
de una metodología de evaluación de accesibilidad concreta que cuente con el
compromiso de todo el equipo involucrado en la construcción del sitio, es suficiente
para que un sitio logre alcanzar niveles de accesibilidad A o AA aceptables para sitios
gubernamentales, sitios que no están dirigidos a una población en condición de
discapacidad, o para organizaciones como Colnodo, interesados en ofrecer sus
contenidos a una población más amplia. Alcanzar un grado de accesibilidad AAA,
necesario para sitios destinados a población en condición de discapacidad, por ejemplo,
sí implica que el desarrollo sea guiado casi en su totalidad desde un enfoque accesible,
lo cual demanda del cliente y el equipo de desarrollo disposición para “sacrificar”
aspectos técnicos, estéticos e incluso funcionales en pos de garantizar la accesibilidad.
● En cualquier caso, se debe establecer claramente desde el inicio del proyecto cuál es el
enfoque de éste y cuál es la prioridad que se dará a la accesibilidad a la hora de tomar
decisiones sobre el estilo, la funcionalidad, etc. Esta definición debe ser coherente con
el grado de accesibilidad que se quiere alcanzar (A, AA, AAA), decisión que también debe
tomarse desde el inicio del proyecto.
● El Manual de Accesibilidad Web recoge la experiencia adquirida durante el desarrollo
del proyecto y fue creado sobre la base de los documentos en los que se sistematizó
todo el proceso de evaluación, corrección y desarrollo de los sitios e incluye algunos
fragmentos de los mismos. Ya que la intención de este manual es servir de guía a
quienes quieren garantizar accesibilidad en sus desarrollos web, este se dividió en

37
 cuatro partes: Planeación, Desarrollo, Evaluación de Accesibilidad y Lista de
Herramientas. Se procuró tener sub secciones con títulos claros que permitan a quien
lee saltar a los contenidos que requiera durante el proceso de desarrollo.
● Sobre la experiencia adquirida en la evaluación de los sitios web, se ratifica la
importancia de implementar más de un método de evaluación de accesibilidad para
obtener sitios más accesibles y ajustados a la norma. Los métodos que se consideran
necesarios para una evaluación de accesibilidad integral son: i) La verificación de la
sintaxis del código HTML y CSS, para mantener la robustez del sitio web y evitar errores
de robustez en la siguiente fase, ii) la evaluación automática, por una o dos
herramientas disponibles en línea o pagas como como TAW y AChecker, y la corrección
de los errores detectados y iii) la evaluación manual, verificando las advertencias y no
verificados de la evaluación automática, apoyándose en listados de verificación de la
WCAG, y recorriendo los sitios por teclado y con lectores de pantalla como NVDA o Jaws.
● Como producto de la experiencia, también se puede sustraer la importancia de que el
equipo de diseño y desarrollo están en permanente comunicación y articulación con el
equipo que evaluará la accesibilidad del sitio (en caso que sean distintos) pues se
pueden solucionar dudas y falencias de accesibilidad en el momento en que se
implementan, agilizando el proceso de evaluación final. Además esta interacción generó
cambios en las prácticas de desarrollo de ambos equipos, puesto que conocieron los
aspectos que evalúa la norma y, aunque no en su totalidad, se apropiaron algunos
aspectos y técnicas de verificación.
● La evaluación de estos los sitios web creados mediante Moodle y Aplicaciones de Acción
permitió determinar qué tan accesibles resultan estas plataformas. Se logró establecer
que las Aplicaciones de Acción, al permitir la creación y modificación de todo el código
del sitio web, la implementación de vistas y la modularidad del desarrollo, facilitan la
inclusión de todo tipo de contenidos accesibles. Un reto implícito es mantener la
coherencia en la navegación entre vistas de una misma página, pero un proceso juicioso
de planeación puede ayudar a mantener al margen este tipo de problemas. El tema por
defecto de la versión de Moodle evaluada, la 3.0, aunque demostró tener aspectos
favorables en términos de accesibilidad, tiene elementos importantes (como
formularios, imágenes sin descripciones, evaluaciones o quices, entre otros) que
requieren modificaciones al código fuente. Este último punto se desarrolla con mayor
profundidad en el Anexo 2.
● Finalmente, se considera necesario comenzar a formar una cultura por el respeto digital
del total de la población, garantizando herramientas que cumplan mínimos de
accesibilidad. El desafío más grande está en que el sector público apropie e implemente
con mayor velocidad y rigurosidad la NTC 5854 y que el sector privado, se estimule y
empiece a incorporar prácticas de accesibilidad web. Para esto se debe generar un
proceso de concientización y de formación en cuanto a la necesidad de incluir estos
lineamientos en los proyectos web y sobre cómo vincularlos a las metodologías de
desarrollo existentes en cada organización. Este proyecto pretende contribuir a la
concientización y el fortalecimiento de esta cultura.

38
 8 RECOMENDACIONES
Impulsar la accesibilidad en sectores privados

Un buen número de las organizaciones que implementan los lineamientos para desarrollar
sitios accesibles, son de carácter gubernamental, ya que deben acogerse a los lineamientos
impulsados por la estrategia Gobierno en Línea, que apropia la Norma Técnica Colombiana
5854. Algunas organizaciones de carácter social y sin ánimo de lucro, entendiendo su
objetivo y la necesidad que tienen de llegar a más usuarios sin importar su condición,
entienden la necesidad de incluir esta característica dentro de su sitio web. El sector privado
al no verse obligado por una norma y teniendo otro fin en si mismo, no ha incursionado en
su gran mayoría, en la implementación y formación en estas técnicas. Existe un gran trabajo
y una gran responsabilidad en cuanto a poder llegar a cada vez más desarrolladores,
empresas, organizaciones, etc. para no solo garantizar navegabilidad en lo inmediatamente
necesario sino por el contrario escalar a que efectivamente la red conecte de verdad
personas de todo el mundo sin importar su condición.

Administración Moodle

Moodle según su sitio oficial establecen la meta de “ser completamente accesible y usable
para todos los usuarios sin distinción de capacidad”, el core es evaluado bajo prácticas
accesibles de la WCAG 2.0 y soporta lectores de pantalla desde su versión 2.7. Otro aspecto
importante es su solicitud a todos los desarrolladores asegurarse de seguir y evaluar su
trabajo bajo los parámetros de la WCAG. Desarrollando el aula de la BNC efectivamente se
da cuenta de su avance en accesibilidad y su compromiso con potenciar esta tendencia.
Muestra pequeña de esto, es la implementación de la navegabilidad por bloques, poco
implementada pero bastante útil para la agilidad con que se recorre el sitio.

En la experiencia que se tuvo con Colnodo adaptando un tema del gestor de cursos Moodle,
es de resaltar que inevitablemente hay cosas por los tiempos que requiere un proyecto, que
se salen de las manos, una de ellas que se pudo identificar fue todo el esquema de
configuración y administración que tiene Moodle, por su amplitud y complejidad es un
trabajo que conlleva bastante esfuerzo pero que si no se hace, le quita la posibilidad de
siquiera administrar una actividad de un curso a una persona con alguna discapacidad.

CMS accesibles

En el mundo actualmente existen más de mil millones de sitios al aire de los cuales el 30.9%
están desarrollados en Wordpress, el 3.1% en Joomla, el 2.1% en Drupal, por dar algunas

39
cifras37. Aunque los sitios desarrollados sin CMS seán la mayoría (48.3%) la cantidad de sitios
que si los manejan, es enorme. Hay que decir que Wordpress tiene avances interesante en
cuanto accesibilidad, dentro de su documentación se tiene un manual de buenas prácticas
para el manejo del contenido propio del sitio y para el manejo del core de la plataforma y
afirman que todas las actualizaciones lanzadas en Wordpress están conformes con los
lineamientos de la WCAG 2.0 en nivel AA38, pero sigue dependiendo, como todos los
gestores, de terceros que gestionan los módulos, plugin, etc., que dan la estructura del sitio.
Esos terceros pueden o no, tener pautas accesibles para el desarrollo de esas partes de
código, lo que no garantiza accesibilidad simplemente por el uso de este gestor. Por otro
lado Joomla y Drupal que son los segundos más populares no solo sufren del problema
identificado en Wordpress si no que de por sí su plataforma no ha tenido avances serios
que permitan verlos como opciones accesibles. Un colaborador de Joomla ha desarrollado
un módulo que ofrece beneficios como cambiar el tamaño de la tipografía, cambiar
contrastes, facilitar navegación por teclado y resaltar enlaces39 que si bien ofrece ayudas
bastante útiles no representan un avance serio en esta tendencia. Drupal por su parte ha
implementado en sus últimas versiones elementos en pro de la accesibilidad, como
funciones JavaScript para el lector de pantalla, un orden del sitio adecuado para recorrerse
por tabs, sintaxis HTML5, fieldsets en los formularios, textos alternativos por default y
alertas para los campos de los formularios40. Si bien estos elemento no lo vuelven la peor
opción en cuanto a accesibilidad tampoco lo hacen el cms que de entrada le garantice algún
nivel, pero va por un camino acertado que puede llegar a prometer de entrada un estándar
de accesibilidad, desde el core de la plataforma. Es necesario hacer un avance serio con
miras a que no solo el core de estas plataformas brinden características accesibles, sino que
los colaboradores de todo el mundo deben implementar por lo menos un mínimo de los
lineamientos emanados por la WCAG 2.0.

37 Estadísticas de cms usados en el mundo. Consultado en junio del 2018. Disponible en línea

https://w3techs.com/technologies/overview/content_management/all
38 Estándar de Wordpress para la codificación accesible. Consultado en junio del 2018. Disponible en línea

https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-
standards/
39 Módulo B-Accessibility para Joomla, desarrollado por Yair Lahav, Consultado en junio del 2018. Disponible

en línea https://extensions.joomla.org/browse/new/extension/style-a-design/accessibility/b-accessibility/
40 Drupal 8 características accesibles, consultado en junio del 2018. Disponible en línea.

https://www.drupal.org/docs/8/accessibility/drupal-8-accessibility-features

40
 9 BIBLIOGRAFIA Y CIBERGRAFIA
9.1 BIBLIOGRAFÍA

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. Manual

para la implementación de la Estrategia de Gobierno en línea de la República de Colombia.
Bogotá. 2012. p.43

COLOMBIA. CONPES. Documento CONPES 166 de 2013 (9 de Diciembre 2013). “Política

Pública nacional de discapacidad e inclusión social”. Bogotá, 2013 p 55. Disponible en
internet:
http://www.mincultura.gov.co/areas/poblaciones/poblacion-con-
discapacidad/Paginas/166.pdf

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. Boletín

Trimestral de las TIC. Bogotá, Colombia, marzo de 2017.

COLOMBIA. CRC. Resolución 5076. (29 de Diciembre de 2016) Bogotá, 2016. Disponible en
internet: https://www.crcom.gov.co/resoluciones/00005076.pdf

COLOMBIA. CONGRESO DE LA REPÚBLICA. Ley 1680 (20 de noviembre de 2013) “Por la cual
se garantiza a las personas ciegas y con baja visión, el acceso a la información, a las
comunicaciones, al conocimiento y a las tecnologías de la información y de las
comunicaciones”. Bogotá, 2013.

Internet para la Rendición de Cuentas. Sobre el proyecto. IPCR [en línea] Bogotá [revisado
junio 2017] Disponible en Internet: http://www.iprc.org.co/

VIGO, Markel, BRANJNIK, Giorgio, O’CONNOR, Joshue. Research Report on Web

Accessibility Metrics. En: W3C WAI Research and Development Working Group (RDWG)
Notes. 2012.

41
PASCUAL, Alfra. RIBERA, Mireia. GRANOLLERS, Toni. Impact of web accessibility barriers on
users with a hearing impairment. En: Dyna. Medellin, 26 noviembre de 2015.

FERATI, Mexhid. En: Accessibility requirements for blind and visually impaired in a regional
context: An exploratory study. En Usability and Accessibility Focused Requirements
Engineering (UsARE), 2014 IEEE 2nd International Workshop on. IEEE, 2014. p. 13-16.

ALFONZO, Daiana E. CASARO Pedro L. MARIÑO, Sonia I. GODOY, María V. Mantenimiento

Correctivo Aplicado a un Sitio Basado en Joomla. Una Propuesta Centrada en la
Accesibilidad. En: Revista Latinoamericana de Ingeniería de Software, 2015, vol. 3, no 2, p.
101-107.

LÓPEZ, Juan Miguel., PASCUAL, Afra, MEDUIÑA, Cristina, & GRANDOLLERS, Toni.
Methodology for identifying and solving accessibility related issues in web content
management system environments. En: Proceedings of the International Cross-Disciplinary
Conference on Web Accessibility. ACM, 2012. p. 32.

LOIACONO, Eleanor T.; MCCOY, Scott; CHIN, William. Federal Web site accessibility for
people with disabilities. En:IT professional, 2005, vol. 7, no 1, p. 27-31.

FAYZRAHMANOV, Ruslan. GÖBEL, Max. HOLZINGER, Wolfgang. KRÜP, Bernhard.

BAUMGARTNER, Robert. A unified ontology-based web page model for improving
accessibility. En Proceedings of the 19th international conference on World Wide Web.
ACM, 2010. p. 1087-1088.

YEH, Ping-Jer; YUAN, Shyan-Ming; LO, Winston. Two-level Web agent for limited
accessibility. En Computer Software and Applications Conference, 1997. COMPSAC'97.
Proceedings. The Twenty-First Annual International. IEEE, 1997. p. 482-485.

DE OLEO MORETA, Cinthia & RODRÍGUEZ BAENA, Luis (2013). Pautas, métodos y
herramientas de evaluación de accesibilidad web. En: Ventana Informática. No. 28 (ene.-
jun.). Manizales (Colombia): Facultad de Ciencias e Ingeniería, Universidad de Manizales. p.
99-115. ISSN: 0123-9678

42
9.2 CIBERGRAFÍA

LAWTON, Shawn y EOWG. Introducción a la Accesibilidad Web. W3C Web Accesibility

Initiative [en línea], septiembre de 2005 [revisado 10 junio 2017]. Disponible en
http://www.w3c.es/Traducciones/es/WAI/intro/accessibility

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia, Índice GEL

Nacional, Resultados 2016. Estrategia Gobierno en Línea [en línea] [Revisado junio 2017].
Disponible en internet:
http://estrategia.gobiernoenlinea.gov.co/623/w3-propertyvalue-14713.html

COLNODO. Neutralidad en Internet: Factor que potencia el cierre de la brecha social digital.
Colnodo [en línea] 4 diciembre 2013 [revisado julio 2017]. Disponible en Internet:
http://www.colnodo.apc.org/pol%C3%ADticas-de-tic.shtml

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. Relevo de

llamadas. Centro de Relevo [en línea] [revisado junio 2017]. Disponible en internet:
http://www.centroderelevo.gov.co/632/w3-propertyvalue-15253.html

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. Servicio de

Interpretación en línea SIEL. Centro de Relevo [en línea] [revisado junio 2017]. Disponible
en internet:
http://centroderelevo.gov.co/632/w3-propertyvalue-15254.html

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia.

Herramienta de apropiación TIC. Centro de Relevo [en línea] [revisado junio 2017].
Disponible en internet:
http://centroderelevo.gov.co/632/w3-propertyvalue-15255.html

Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. Formación

virtual de intérpretes. Centro de Relevo [en línea] [revisado junio 2017]. Disponible en
internet: http://centroderelevo.gov.co/632/w3-propertyvalue-15256.html

43
W3C. Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recomendations [en línea] 11
de diciembre 2008 [revisado julio 2017]. Disponible en internet:
https://www.w3.org/TR/WCAG20/

COLNODO. Nuestra organización. [en línea] 2017 [revisado julio 2017]. Disponible en
internet: http://colnodo.apc.org/nuestraOrganizacion.shtml

CORPORACIÓN COLOMBIA DIGITAL. ¿Cómo está Colombia en gobierno electrónico?

Colombia Digital [en línea] Mayo 16 de 2017 [revisado julio 2017]. Disponible
en https://colombiadigital.net/quienes-somos/soluciones-tic/item/9728-estudio-como-
esta-colombia-en-gobierno-electronico.html

APC. Carta de APC sobre derechos en Internet. Asociación para el Progreso de las
Comunicaciones APC [en línea] noviembre 2006 [revisado julio 2017]. Disponible
en: http://www.apc.org/es/node/5795

ASCENCIO G, Jhon Fredy; BUENO S. Julián Andrés; MIRA M, Maria Isabel. Metodología de
evaluación de accesibilidad web para personas con limitaciones visuales. Universidad
Tecnológica de Pereira [en línea] 2009 [revisado junio 2018]. Disponible en
http://repositorio.utp.edu.co/dspace/bitstream/handle/11059/1332/371911A811.pdf

UWEM, Unified Web Evaluation Methodology version 1.2. Web Accessibility Benchmarking
Cluster -WAB Cluster. [en línea] 3 de diciembre de 2007 [revisado junio 2018]
Disponible en: http://www.wabcluster.org/uwem1_2/

44
 10 ANEXOS

ANEXO 1: MANUAL DE ACCESIBILIDAD WEB

La implementación total de las WCAG 2.0 y la NTC 5854 para alcanzar un grado de
accesibilidad AAA implica que el desarrollo será guiado casi en su totalidad por los aspectos
de accesibilidad, lo cual a decir verdad, representa un gran esfuerzo de desarrollo, y
requiere que la organización o el equipo al frente del desarrollo estén dispuestos a
“sacrificar” aspectos técnicos, estéticos e incluso funcionales para garantizar la
accesibilidad. Sin embargo, existen casos en los que los sitios no están orientados a una
población con condiciones de discapacidad, pero existe un interés de garantizar un grado
de accesibilidad medio y hacer los contenidos accesibles, como es el caso de los sitios
gubernamentales, y concretamente, de los desarrollos de organizaciones como Colnodo,
que ofrecen a sus clientes características de accesibilidad como un plus en sus contratos.
En estos casos, las decisiones del desarrollo se orientan por las prioridades del contrato, no
necesariamente para garantizar la accesibilidad.
Este manual se pretende aportar a los desarrolladores y organizaciones que quieren
implementar prácticas accesibles en sus sitios web, mediante pautas que se puedan integrar
a los procesos de desarrollo presentes en la organización.
Estas pautas llevadas con rigurosidad y sumadas con ejercicios de evaluación constante y
retroalimentación interna, pueden derivar en progresos grandes en la implementación de
las WCAG 2.0 y la NTC 5854 al menos en un nivel AA para las organizaciones que las pongan
en práctica.

PLANEACIÓN
Grado de accesibilidad

Al inicio del proyecto la planeación es fundamental, como en cualquier proyecto, pero

hablando de accesibilidad, este tema cobra mayor sentido, ya que no solo se van a definir
las herramientas, la metodología, los tiempos y costos del desarrollo y todo lo que involucra
el planteamiento inicial de una plataforma, sino que se tendrán que definir estos aspectos
desde el enfoque accesible. Se tiene que ser muy sincero, con lo que se quiere, con lo que
se va a priorizar y el alcance, así como con de lo que no se va a priorizar.
Actualmente a pesar de ser muchos los avances que hay en el campo de la accesibilidad,
son muchos más los retos en cuanto herramientas, módulos, plataformas, gestores, etc,
que se suelen reutilizar a la hora de realizar un desarrollo, por eso es probable que algunas
de estas herramientas se tengan que reevaluar o desechar según la prioridad del proyecto,

1
por ejemplo, puede primar la funcionalidad o la estética sobre la accesibilidad. y cuando se
rehúsan elementos externos puede resultar complejo adaptarlos de forma accesible, y en
ocasiones hasta es imposible por su característica paga o de código cerrado.

Costos y tiempos

De acuerdo a las decisiones tomadas sobre el grado de accesibilidad deseado, es necesario

evaluar los tiempos y recursos disponibles para el proyecto. Si se escoge una herramienta
completamente inaccesible pero se piensa en adaptarla, esto puede tomar un tiempo
considerable, que hay que contemplar como tarea misma de desarrollo para no tener
posibles conflictos contractuales.

De la misma forma, al momento de efectuar compras, como por ejemplo plantillas, temas,
componentes, módulos, entre otros según la plataforma de desarrollo,

Preparación teórica
Es recomendable conocer y datearse de ventajas y desventajas en términos de la
implementación de accesibilidad de la plataforma de desarrollo seleccionada, así como del
contenido multimedia, secciones de la página, títulos, enlaces, contenido JavaScript, entre
otros. Existen prácticas muy sencillas de utilizar con este contenido complejo, que si están
claras desde un principio, se facilita la creación de un sitio accesible.

Este manual aborda elementos generales y de fácil implementación, pero para conocer más
de estas prácticas a profundidad, se recomienda visitar el sitio ntc5854.accesibilidadweb.co
desarrollado para MINTIC, que muestra de forma lúdica y digerible cómo seguir los
lineamientos establecidos por la NTC 5854.

Diseño

El diseño del sitio web por lo general es definido en esta etapa de planeación. Tenga en
cuenta los siguientes puntos para que este sea accesible:
● Presentar la información de la forma más clara y menos técnica posible, claro
dependiendo del contexto.
● Pensar la página de inicio sin información redundante.
● Definir cómo se presentarán los enlaces vínculos a otras secciones ¿mediante menús
desplegables, botones, listas, etc? esto ayudará a pensar un diseño que permita
coherencia y secuencialidad.

2
 ● Qué contenido se desplegará y mediante qué herramientas. Si se incluirán vídeos o
infografías, evaluar la relevancia de estos y si se les incluirán subtítulos y
descripciones escritas de los mismos (recomendable).
● Evitar que solo el color de los elementos determine su funcionalidad, por ejemplo
mensajes de confirmación y error. Aunque se pueden incorporar colores verdes para
acciones afirmativas, por ejemplo, estos se deben complementar con iconos
etiquetados con alt o mensajes textuales al usuario.
● Las acciones y efectos que se quieran presentar al pasar el mouse o el focus sobre
algunos elementos pueden confundir a usuarios con limitaciones visuales. Se
recomienda que estos efectos no comprometan la funcionalidad del sitio o se
anuncien al usuario.

Colores y contrastes

Establecer una paleta de colores con un contraste adecuado desde el inicio del proyecto es
fundamental, con ayuda de algunos sitios como WebAim Contrast Checker1, que establecen
el grado de accesibilidad de la paleta de colores e incluso brindan algunas recomendaciones
a implementar.
Tenga en cuenta que si se desea incluir la opción de cambio de colores del sitio para permitir
altos contrastes, blanco y negro, etc, estas paletas y diseños se deben definir también en
esta fase.

DESARROLLO

Un sitio web robusto

Uno de los ítems analizados por los validadores automáticos es la estructura como tal del
sitio web, es decir que la apertura y cierre de etiquetas y atributos que coincidan, en
ocasiones cuando no se hace, es fácil identificarlo por fallas en el funcionamiento y/o
aspecto del sitio, pero en otras ocasiones pasa desapercibido a simple vista. Por debajo
pueden ocasionar fallas en el orden del código, lo que a su vez ocasiona posibles errores de
interpretación por lectores de pantalla, estos errores están enmarcados dentro de los
parámetros de la WCAG 2.0 como errores de robustez.
Otra aspecto que se debe tener en cuenta durante todo el desarrollo es mantener
separados el código HTML del CSS, pues los validadores encuentran en la inclusión de
atributos style dentro de las etiquetas HTML un factor negativo. Hacer uso de las clases que
incluye Bootstrap, por ejemplo, y de clases personalizadas con características frecuentes en

1 Disponible en línea en https://webaim.org/resources/contrastchecker/

3
el sitio, como por ejemplo renglones para separar los elementos, o estilo de los títulos e
imágenes así como centrar los elementos, entre otras es una buena alternativa.
En cuanto al texto y su decoración, los validadores también evalúan negativamente la
presencia de etiquetas poco descriptivas como <b> o <i>, y en cambio se recomienda el uso
de etiquetas como <strong> y <em> que dan énfasis al texto incluso para los lectores de
pantalla.

Recorrido del sitio: de izquierda a derecha, de arriba a abajo

Cuando un usuario acceda al sitio usando un lector de pantalla, éste recorrerá la página en
el orden en el que estén escritos los elementos en el código, a pesar de que se visualicen de
forma distinta. por eso se recomienda no alterar el orden de los elementos como menús,
divs, etc mediante la hoja de estilos, a menos que sea el objetivo deseado, y en caso de
hacerlo, verificar que la información sea recorrida de forma coherente para el usuario.

La forma tradicional de ubicar los elementos para que tengan sentido para los usuarios, es
desde arriba hacia abajo, y en orden desde la izquierda a derecha. Por ejemplo elementos
listados horizontalmente en orden secuencial desde la izquierda hacia la derecha, y
continúan en una nueva fila debajo de la primera.

De igual forma, los elementos como listas, divs, bloques de texto, u otros elementos que no
son enfocables por defecto, pero que se consideren importantes durante el recorrido por
teclado de la página, se les debe agregar el atributo tabindex=”0” que permite incluirlos en
el flujo normal del recorrido el elemento etiquetado; tabindex=”n”, siendo n un número,
que fuerza a que el elemento sea enfocado en la n-ésima posición. Esta última opción no es
muy recomendada, a menos que se tenga total certeza de en qué momento se quiere
enfocar un elemento.

Bloques de elementos

Según el grado de accesibilidad que se quiere dar al sitio, se pueden agregar enlaces que
salten bloques completos de contenido. Estos son usados para facilitar el recorrido de

4
usuario con lector de pantalla o mediante el teclado y está implementado algunas
plataformas como Moodle.

El objetivo es evitar que el usuario que navega por un sitio tenga que recorrer el cabezote,
el menú principal o los menús secundarios, publicidad, banners o elementos permanentes
en todas las páginas de un sitio, y que en cambio pueda saltar estos bloques de contenido.

La implementación es bastante sencilla y solo requiere, como se ve en la imagen, que haya

un enlace antes del bloque de contenido a saltar (div inst5) que direccione hacia un área
siguiente en la página (div sb-4). La clase skip de Moodle permite ocultar en enlace, y
hacerlo visible solo cuando está enfocado. Así, cuando el usuario navegue, podrá omitir,
por ejemplo, el listado de herramientas o enlaces que aparecen en el menú de
administración, o en cualquier otro menú o área con más elementos.

Imagen tomada de https://aulavirtual.bibliotecanacional.gov.co/

Estos mismos enlaces se pueden agregar al inicio de la página, antes del encabezado del
sitio para que el usuario que está accediendo al contenido desde otra página del mismo
sitio (y ya conoce su estructura) salte directamente al contenido del sitio.

Títulos jerárquicos y secuenciales

Aparte de la estructura del sitio mencionada, la coherencia entre los títulos y subtítulos del
sitio web ayudan a que los usuarios se orienten y comprendan la jerarquía de los contenidos
presentados. Para el inicio del proyecto se recomiendan las siguientes técnicas:
● Asegurarse de que exista un h1 en el encabezado de la página para no tener
conflictos de títulos con el contenido que irá después. Una opción es situar el
nombre o logo del sitio web dentro del header.

5
 ● Los títulos de las vistas internas que llevarán el contenido del sitio deberán empezar
por h2 e intentar de la mejor forma manejar la jerarquía de allí en adelante sin
saltarse ni devolverse de manera incoherente.
● Los estilos definidos para estos títulos (h2,h2,h3,h4,h5 y, h6) deben ser plasmados
en la hoja de estilo de acuerdo con las expectativas de los títulos y subtítulos de cada
nivel en los contenidos, para que no sea una excusa la mantener la estética sobre la
coherencia en jerarquía del sitio.
Las Aplicaciones de Acción permiten manejar el total de la estructura del código y por lo
tanto implementar técnicas y características accesibles en la medida que el desarrollo
avanza.

Tablas

Las tablas deben tener una fila inicial para su descripción, o un campo <caption> que
funciona como título.
Como todo elemento debe tener atributo title fundamental para describir su función y en
especial para el lector de pantalla. En caso de que se use la tabla de forma decorativa el
atributo title, debe definir de la mejor manera su contenido.

Enlaces

Agregar a cada etiqueta <a> un atributo title permite que el usuario sepa la funcionalidad
del enlace. Ya sea un botón o un hipervínculo, es necesario guiar al usuario con estos títulos.
De la misma forma, anunciar si al hacer clic en el enlace se cargará una ventana modal, otra
ventana o pestaña, o se actualizará el contenido, como por ejemplo con los paginadores.

Es frecuente que el texto del enlace sea muy descriptivo, por ejemplo leer más, Ir a detalles,
enviar, etc. En estos casos es importante no saturar al usuario con información redundante,
es decir ser claros en la descripción o el título es claro hacia dónde se dirige el enlace no
repetirlo en el title.

En los elementos como imágenes, iconos o títulos que son enlaces, es importante incluir
algún efecto o cambio distinguible para el estado focus, por ejemplo que las letras o
imágenes cambien de color, pierdan o ganen subrayado, se opaquen, los icono se
agranden, etc. esto permitirá al usuario que recorre el sitio mediante el teclado saber
donde esta exactamente todo el tiempo.

Formularios

6
En el uso de formularios hay guiar al usuario a través de los campos. Para esto el formulario
debe tener un title descriptivo así como un label para cada input u otro elemento del
formulario, incluido el submit que envía la información.
Una vez se haga clic en el botón de envío, desplegar una página o mensaje de éxito que
haga saber al usuario que se hizo adecuadamente la operación, o por el contrario una
página o mensaje que permita conocer los errores o el estado fallido del envío del
formulario.
El método de envío del formulario debe estar definido para todos los formularios.
No puede existir formulario sin un input o elemento de tipo submit.

Contenido audiovisual

Para el contenido audiovisual, la norma NTC 5854 demanda varias características que
requieren mayor tiempo y dedicación (subtítulos en los videos por ejemplo). Por esto se
advierte que de la rigidez con la que se apliquen las siguientes pautas dependerá el nivel de
accesibilidad alcanzado.
Se parte de la premisa de que todos los elementos deben traer un atributo title.
Imágenes con propósito decorativo debe llevar ese atributo vacío.

Imagen tomada de http://ntc5854.accesibilidadweb.co

Imágenes para señalar algo dentro del sitio debe proporcionar la misma información
mediante el atributo title.
Imágenes netamente descriptivas: flyers, volantes o cualquier imagen con texto, debe
proporcionar esa información con el atributo longdesc, resumir sin cortar información con

7
title o colocando un pie de página con un párrafo con la suficiente información para
transmitir el contenido de la imagen.

Imagen tomada de https://www.contraloriadecordoba.gov.co/

Con los videos se debe procurar insertar videos con subtítulos o insertar los subtítulos al
video antes de subirlo, en caso de no tenerlos, una buena pero poco práctica técnica, puede
ser transcribir el contenido del video, o tratar de resumirlo en un párrafo contiguo al video,
indicando con qué objetivo se coloca el texto allí. El volumen debe ser controlado
independientemente del volumen global del equipo y debe tener controles para manejar el
curso del video.

Imágenes tomadas de http://ntc5854.accesibilidadweb.co

8
Con los audios, las opciones de transcripción del contenido son las únicas opciones para
llegar a usuarios con discapacidad auditiva. Debe tener control independiente del volumen
y del curso del audio.

Imágenes tomadas de http://ntc5854.accesibilidadweb.co

Herramientas externas

La reutilización de código para el desarrollo de componentes o funcionalidades del sitio web

se considera una buena práctica en el campo de la programación. Sin embargo al usar este
tipo de herramientas, se debe evaluar la forma en la que se acopla con el resto del
desarrollo sin afectar la accesibilidad.
Una herramienta se puede catalogar como poco accesible o inaccesible aplicando las
herramientas de diagnóstico automáticas2, además se puede complementar recorriendo
esas herramientas con un lector de pantalla, utilizando la tecla tab para navegar y verificar
su funcionalidad. Dependiendo los resultados y el cumplimiento de los criterios de la NTC
5854 se concluye el grado de accesibilidad de la herramienta a utilizar.
Es importante tener en cuenta que las herramientas externas pueden incluir errores de
accesibilidad y que estos podrían ser modificados o no, dependiendo de si la herramienta
es de código abierto o no. Al usar una herramienta externa de código cerrado se expone
el desarrollo a problemas de accesibilidad que el desarrollador no podrá solventar.
● Plantillas
Algunas herramientas externas de uso frecuente son elementos extraídos de plantillas
definidas de sitios completos, que cumplen una función en ocasiones un poco más
estética que en realidad funcional, algunos ejemplos son los acordeones, para encoger
y expandir contenido, los carruseles que despliegan un conjunto de imágenes, menús,

2 http://www.tawdis.net/ - http://ntc5854.org/validador/checker/index.php

9
entre otros; estos elementos al re utilizarlos, podemos adaptarlos de manera que
cumplan las pautas que se han mencionado.
● Sliders
Los sliders permiten desplegar contenidos de forma dinámica en los sitios web,
desplazando elementos o bloques a lo largo o ancho de la página. Estos efectos se logran
en una mezcla de HTML5 y CSS3, que en ocasiones se crea o se reutiliza de otras
plantillas o desarrollos.

Para estos elementos, es clave probar su funcionamiento mediante el recorrido con el

teclado y un lector de pantalla, verificando que:

 Los elementos fuera de vista no sean recorridos. Hay sliders que juegan con
las posiciones desde el CSS pero no ocultan los elementos en el código , por
ende estos siguen estando “escritos” en el código de la página y leídos en la
página así no sean visibles.
Para solucionarlo, se puede agregar la regla display:none en la clase de los
elementos ocultos o inactivos.
 Elementos de control etiquetados y visibles. Los sliders por lo general
cuentan con elementos de control, como flechas para avanzar o retroceder
o pausar la transición de elementos. Independientemente de si estos son
botones o enlaces, deben ser accesibles. Deben estar ubicados (en el código)
en un lugar que sea coherente para el usuario, ya sea al inicio o final del
listado o conjunto de elementos a desplegar. Debe describir claramente su
funcionamiento, mediante atributos title o desc. Deben presentar cambios
en la presentación cuando están en estado focused.
 Si el slider contiene imágenes, iconos, títulos o enlaces, estos deben contar
con las consideraciones de accesibilidad descritas en este manual

● Embebidos
Las herramientas embebidas son elementos mucho más funcionales y muy sencillos de
utilizar, basta con copiar el iframe del lugar que provee la herramienta y ya tenemos
toda la funcionalidad en nuestro sitio. En cuestiones de accesibilidad depende mucho
del sitio de donde se use la herramienta, ya que el iframe deja pocas opciones de
modificación, se le puede agregar algunos title para la identificación del elemento, y dar
algunas pautas para su utilización. En ocasiones cuando la herramienta no tiene ni
siquiera un mínimo de accesibilidad, se recomienda buscar alternativas para no
prescindir de la funcionalidad pero tampoco dejar un bache en la navegabilidad del sitio.

10
 Para lectores pdf se recomienda verificar que el lector de pantalla ingrese al texto, en
caso de no hacerlo, dar la opción de descarga del documento o de abrirlo con el
navegador.

En todo caso, si se considera necesario dar únicamente al usuario que usa un lector de
pantalla un contexto más amplio de lo que se presenta o incluso instrucciones de uso
para un iframe o embebido se puede utilizar clases como sr-only de Bootstrap 3, que
oculta a simple vista un div y permite que sea “visible” solo para el lector de pantalla.

● Plugins/Módulos/Extensiones
Cuando se utilizan CMS como Joomla, Wordpress, Moodle, etc, es muy común y casi
que necesario la utilización de estos elementos, que son desarrollados por
colaboradores externos y proveen funcionalidades específicas. Cuando estas
herramientas son de código cerrado, su adaptación, en caso de necesitarla, es muy
complicada, por lo que al igual que con los embebidos, se recomienda buscar
alternativas. Cuando son de código abierto y la evaluación arroja que es necesaria una
adaptación, basta con atender a las pautas mencionadas.

Vistas de uso frecuente

En las Aplicaciones de Acción, las vistas del header, el footer, el menú, botones, entre otras,
que estarán en la mayoría de páginas deben ser desarrolladas y diseñadas con el mayor
cuidado, ya que inconsistencias o falencias de accesibilidad en esta parte afectará al todo el
sitio y puede desorientar a un usuario.
Una revisión sobre el uso de los enlaces, divs, imágenes o elementos de la vista desde la
perspectiva de accesibilidad, y un recorrido mediante el teclado al momento de crear la
vista puede ahorrar esfuerzos en la evaluación final de accesibilidad.

EVALUACIÓN DE ACCESIBILIDAD

El proceso de evaluación de accesibilidad de un sitio web puede ser tan complejo y tomar
tanto tiempo como el desarrollo mismo del sitio. Por eso se proponen inicialmente algunas
prácticas que permitan hacer un desarrollo con aspectos accesibles, y por ende invertir la
menor cantidad de tiempo de la etapa de desarrollo en la revisión de accesibilidad. En este
punto, es necesario que todo el equipo de desarrollo se comprometa con el ejercicio
consciente del desarrollo accesible, sobre todo si este mismo equipo evaluará la
accesibilidad de los sitios web.

11
Se consideran necesarias la revisión y evaluación para poder garantizar confiadamente a
los clientes sitios con el grado de accesibilidad acordado, para ajustar los detalles que se
hayan pasado por alto o hayan sido ignorados en el desarrollo y verificar que los 4 principios
de la norma están presentes en el sitio. Vale recordar que la rigurosidad de la evaluación,
depende del grado de accesibilidad que se quiera alcanzar en cada sitio. Adicionalmente, es
útil para retroalimentar la metodología, estrategias y prácticas de desarrollo accesible
dentro de la organización.

Ahora, para realizar un proceso serio de evaluación, se requiere analizar de forma

concienzuda algunas preguntas desde el inicio del proyecto, como ¿qué metodología se
seguirá? ¿qué herramientas se usarán? ¿quienes desarrollaran el proceso? ¿se llevará
registro por escrito de este proceso, resaltando problemas y soluciones frecuentes de
acuerdo a la plataforma usada?, que sumadas con las que la organización considere
prudente, guiarán el proceso de evaluación de accesibilidad durante todo el desarrollo.

Metodología

La evaluación de accesibilidad debe hacer que el sitio se ajuste a la norma NTC 5854 y por
ende a la WCAG. Para lograrlo existen varios métodos, complementarios entre sí, pero entre
los que se destacan 3 que se consideran necesarios, y serán explicados más adelante: i)
validación del código, ii) Validación automática y iii) Validación manual. La organización,
puede agregar otros métodos o mecanismos de evaluación que considere pertinentes o
necesarios para las exigencias de sus clientes y sus estándares de calidad propios, pero se
recomienda no omitir ninguno de los 3 mencionados.
Por otro lado, hay que determinar cuándo se hará la evaluación. Una opción es ejecutarla
una sola vez al final del proceso de desarrollo. Esto podría hacer más “rápido” el proceso de
desarrollo, pero al evaluar, pueden generarse errores a lo largo y ancho del sitio y de todo
tipo, lo que requeriría modificaciones a las hojas de estilos, al código del sitio, quizás en
bloques de código reutilizados en el sitio, en la forma en la que se presentan los contenidos
principales, o rehacer secciones completas en el peor de los casos. Por esto no es la opción
más recomendable. Otra opción sería evaluar con los tres métodos cada parte, módulo o
página desarrollada. Este es otro extremo que si bien garantiza la accesibilidad en mayor
grado, requiere mucho más tiempo, y conocimiento de la norma por quien desarrolla. Sería
importante tenerla presente en el caso de que la accesibilidad sea el enfoque del proyecto.
Conscientes de que la accesibilidad no siempre será el enfoque desde el que se quiera
orientar el desarrollo, y que por el contrario puede orientarse a adquirir un nivel aceptable
de accesibilidad, se formulan las siguientes recomendaciones para determinar cuándo
evaluar la accesibilidad del proyecto:
● Al desarrollar bloques de código o vistas que se usen frecuentemente o se reúsen
durante el proyecto es recomendable hacer un proceso de revisión para corregir

12
 oportunamente errores e impedir su replicación en otra parte del proyecto.
La evaluación manual por si sola podría suplir la revisión de accesibilidad en estos
casos, depende del tamaño y complejidad del desarrollo.
● En caso de utilizar plantillas predefinidas, o herramientas externas evaluar qué
grado de accesibilidad se requiere de estas y contar de antemano con las
modificaciones que requiera o los baches de accesibilidad que representará. Evaluar
el impacto de estas inclusiones en el desarrollo.
● Establecer hitos en el proyecto o puntos de chequeo y evaluación, para garantizar
un avance “limpio” y no tener que devolverse en algún punto del desarrollo. Permite
detectar errores y llevar un panorama claro de accesibilidad del sitio. También
permite ir adquiriendo experiencia y pericia que fortalece el ámbito de desarrollo
accesible.
● Al finalizar el proyecto es necesaria la evaluación de accesibilidad completa, en
especial si se piensa establecer un acta de accesibilidad con el cliente. Por más
revisiones parciales que se hayan efectuado, hablando de accesibilidad el todo no
siempre es la suma de las partes.
En cualquier caso, es importante que quienes vayan a hacer la evaluación conozcan la
norma, si no a profundidad, al menos en cuanto a los aspectos que evalúa, así como el
funcionamiento de las herramientas utilizadas.

Métodos de evaluación

 Validación del código HTML y CSS:

Uno de los principios de la norma NTC 5854 contempla que el sitio debe ser robusto, y
evalúa que no existan errores en la estructura del sitio, errores de sintaxis, elementos mal
anidados o etiquetas sin cierre que hacen que el sitio no sea robusto y presente problemas
de procesamiento. Existen múltiples sitios disponibles en red que realizan esta verificación,

13
como el validador de Aborla3 y el Markup Validation Service4 de la W3C con los que es
posible introducir la URL o subir el archivo HTML del sitio que se quiere evaluar para ir al
error concreto y solucionarlo.

Imagenes tomadas de http://validator.aborla.net y https://validator.w3.org/

 Evaluación automática:
La detección de patrones indebidos, ausencia de elementos, aspectos de presentación, de
funcionalidad, operatividad, robustez y comprensibilidad son evaluados a la luz de las
WCAG en alguno de sus grados. Según la herramienta se señalan formas de implementación
recomendadas o se hace referencia a la guia como tal.
A continuación se exponen algunas de las herramientas que se consideran de gran
importancia, para realizar un ejercicio de evaluación completo.
o TAWDIS http://tawdis.net/
Tawdis es una herramienta que analiza automáticamente las páginas mediante la
url, en busca de faltas a la WCAG 2.0. Tal como en los lineamientos se divide el
análisis en 4 categorías, que a su vez analiza diferentes factores:
● Perceptible: Analiza que la información y los componentes de la interfaz del
usuario se presenten a los usuario de forma que lo puedan percibir.
● Operable: Analiza que los componentes de la interfaz de usuario y de
navegación sean operables.
● Entendible: Analiza que la información y la operación de la interfaz de
usuario sea entendible.
● Robusto: Analiza que el contenido sea lo suficientemente robusto de tal
manera que pueda ser interpretado por una gran cantidad de usuarios
incluyendo tecnologías asistidas.
El resultado arrojado por este validador, muestra en qué línea de código está la falla
y a que lineamiento está fallando.

3 Disponible para uso en línea en http://validator.aborla.net/index.php5?lang=es

4 Disponible para uso en línea en https://validator.w3.org/

14
 Imagen tomada de https://www.tawdis.net/

o Validador NTC 5854

Esta herramienta5 es similar al Tawdis, ya que analiza las páginas bajo los
lineamientos de la NTC5854, que son básicamente los mismos de la WCAG 2.0, el
elemento que los diferencia es que este último permite subir páginas, esto es
supremamente util para las páginas que necesitan logueo para acceder. Lo
recomendable es que se descarguen estas páginas y posteriormente se suban a esta
plataforma para tener un análisis completo del sitio.

Imagen tomada de http://ntc5854.org

5 Disponible para uso en línea en http://ntc5854.org/validador/checker/index.php

15
 ○ Validar contraste de color
El buen contraste de colores puede asegurarle o no, a una persona con algún
problema de visión, el visualizar el sitio y por consiguiente acceder a él. El Contrast
Checker6 de WebAim brinda la posibilidad de comparar diferentes paletas de colores
y establecer si el nivel de contraste es adecuado y está conforme a la WCAG 2.0.
También existe una extensión en Mozilla, WCAG Contrast Checker que realiza esta
verificación en tiempo real sobre el sitio desplegado en el navegador, bastante útil,
dado las múltiples herramientas con que cuenta Mozilla para mejorar la experiencia
del desarrollador.

 Evaluación manual:

Se busca evaluar aspectos que el validador automático pasa por alto o que no puede
comprobar, cómo la experiencia de usuario, ausencia o redundancia de atributos, recorrido
por teclado, entre otros.
Aunque la evaluación sea manual mediante el recorrido con la tecla TAB de todo el sitio,
por ejemplo, se debe ayudar con herramientas que simulan la experiencia de un usuario
con alguna discapacidad. A continuación se presentan algunas.
o Lectores de pantalla
Con lectores de pantalla como NVDA7 y JAWS8 se brinda una ayuda extra, es
necesario hacerlo ya que estas herramientas son las que utilizan las personas con
problemas para acceder a las plataformas. La mayoría de problemas los debería
detectar los validadores automáticos, pero es bueno despejar dudas y si es
necesario ajustar lo que haya que ajustar para garantizar una navegabilidad
adecuada en el sitio. Ayuda a detectar si hay problemas de navegabilidad o si los
nombres de algunos componentes no son lo suficientemente descriptivos.
o Checklist
La W3C ofrece un listado de verificación (Checklist of Checkpoints for Web Content
Accessibility Guidelines 1.09) para ir chequeando algunos puntos clave para la
accesibilidad del sitio, está ordenado por prioridades, siendo 1 lo más necesario y 3
lo no tan necesario. En cada prioridad se tienen listados con los items que debemos

6 Disponible para uso en línea en https://webaim.org/resources/contrastchecker/

7Disponible para descarga en https://www.nvaccess.org/
8 Disponible para descarga paga en

https://www.freedomscientific.com/Products/Blindness/JAWS
9 Disponible en línea https://www.w3.org/TR/WCAG10/full-checklist.html

16
 verificar en nuestro desarrollo. Dentro de los items a revisar estan los textos
alternativos de las imágenes, resúmenes de tablas, labels, formularios, etc.

LISTA DE HERRAMIENTAS

A continuación se presentan las herramientas que se vincularon a lo largo del proyecto,

categorizados como favorable y no favorable con una pequeña descripción de su
funcionalidad y ventajas y desventajas en este sentido.

Herramientas Favorables
Aplicaciones de acción

Las Aplicaciones de Acción o Action Apps (AA) son un framework de PHP desarrollado
por la Asociación para las Comunicaciones Progresivas (APC por sus siglas en inglés).
El desarrollo en las AA se basa en Canales que almacenan la información, Vistas en las
vistas se diseña la lógica y las secciones del sitio y Páginas que despliegan las vistas y
los contenidos del sitio. Las AA permiten el reuso de código y la edición del 100% de la
página.
Esta modularidad y flexibilidad, complementada con la sintaxis generadora de código
hacen de las AA una herramienta donde implementar los lineamientos de accesibilidad
es más sencillo que un CMS de mayor uso. Su desventaja es el bajo nivel de uso, una
curva de aprendizaje lenta y su comunidad de desarrollo reducida.

Bootstrap

Bootstrap es una kit de herramientas de código abierto para el desarrollos con HTML,
CSS y JS, que contribuye a la creación de sitios responsive y sin duda ha cambiado la
forma de desarrollar interfaz gráfica, por la facilidad con la que se implementan
layouts, estilos, elementos básicos como botones, formularios, tablas, etc, .
Con Bootstrap se puede crear interfaces completamente responsive, vinculando a la
población que cuenta con dispositivos móviles (que sigue en aumento). Por otro lado
es amigable con los lectores de pantalla. En su implementación requiere atención del
desarrollador para la implementación de los lineamientos, como cualquier otra
herramienta, pero es muy recomendada para ahorrar esfuerzos y tener buenos
resultados.

17
 Moodle

Moodle es una plataforma de aprendizaje virtual de distribución libre escrita en PHP.

Busca brindar ambientes de aprendizaje personalizados y seguros.

Según el sitio oficial de Moodle, “La meta de Moodle es ser completamente accesible
y usable para todos los usuarios, sin distinción de capacidad.” producto de esto, el
desarrollo del core de Moodle es evaluado bajo prácticas accesibles de la WCAG 2.9,
las ATAG 2.0, y desde la versión 2.7 soporta lectores de pantalla. En la práctica, sobre
la versión 3.0 se evidencian buenas prácticas de accesibilidad reflejados en una
evaluación con pocos errores y en los links para saltar bloques (poco usuales pero muy
útiles) pero también se detectan errores como el uso de etiquetas obsoletas,
formularios sin etiquetas, elementos invisibles para el recorrido por teclado, entre
otras.

Por tanto se considera una herramienta con bastantes ventajas en términos de

accesibilidad, aunque con mejoras que implementar.

JavaScript

JavaScript es un lenguaje de programación interpretado de uso frecuente para

mejorar la interfaz de usuario y páginas web dinámicas.
Si bien la NTC 5854 y la WCAG especifican que los sitios funcionen con normalidad con
el JS desactivado, esta no es una censura para el uso de este lenguaje usado en casi
todos los sitios web, La versatilidad y de JS permite agregar a los sitios funcionalidades
solicitadas en las mismas normas, como aumento del tamaño de fuente y el cambio
de colores en el sitio, entre otras. Los mismos validadores automáticos no detectan la
presencia de JS como un error, y por el contrario sugieren que se identifique de forma
precisa la presencia de scripts.
Por este motivo, se recomienda el uso de JS, procurando que el sitio web y su
funcionalidad no sea dependiente de JS, y mediante técnicas de separación de capas
de los contenidos con las funciones JS (unobtrusive JavaScript). Algunos
desarrolladores han implementado alternativas como PHP, Jquery, entre otros
lenguajes igualmente recomendados.

Herramientas No Favorables
EducaPlay

EducaPlay es una herramienta de gamificación que ofrece actividades educativas

(crucigrama, sopas de letras, etc), gestiona grupos, y permite la exportación de
recursos a cualquier LMS compatible con SCORM.

18
 Los recursos exportados no cumplen ningún lineamiento de accesibilidad, puesto que
no es posible recorrer con el teclado, ni las imágenes ni los enlaces tienes textos que
los describan, los identificadores de los campos no guían al usuario de ninguna manera
sobre la actividad. Al usar un lector de pantalla sobre los recursos, no se pueden leer
los elementos de ayuda, no algunos botones, en algunas no existe una descripción de
las actividades y es no se describen por completo los elementos y sus funcionalidades.

Joomla

Joomla es un sistema de gestión de contenidos para la creación de sitios web de

distribución libre. Existe una amplia gama de plantillas, módulos, componentes,
plugins y extensiones desarrollados por terceros para agregar funcionalidades a los
sitios Joomla.
En cuanto a accesibilidad, Joomla solo ha lanzado un módulo que da herramientas al
usuario, para cambiar el tamaño de la tipografía, cambiar contrastes, facilitar
navegación por teclado y resaltar enlaces, que por supuesto es bastante útil, pero que
deja a Joomla como herramienta poco favorable, dado que en el código fuente no hay
una adaptación a los lineamientos de accesibilidad, no existe un control sobre los
módulos, plugins, extensiones y plantillas que se desarrollan.
Sin embargo, plataformas como Joomla-Monster10 y Accesible Template11 han
desarrollado plantillas que, según los sitios oficiales, cumplen con las WCGA 2.0.

Adobe FlashPlayer

Adobe FlashPlayer es un estándar para el envío de contenido web como videos,

animaciones, etc. Recientemente, con las novedades de HTML5, CSS3 y otras
alternativas que permiten el despliegue de este tipo de contenidos en los sitios web
Flash ha disminuido su influencia en la web. La inaccesibilidad de flash pasa por su
obsolescencia y su vulnerabilidad. Cada vez son menos los navegadores que dan
soporte a esta tecnología y los navegadores móviles no acceden a los desarrollos
hechos en flash.

10 Blog Joomla-Monster: Make a successful accessible website with WCAG 2.0 & ADA & Section 508 compliant
Joomla template.
https://www.joomla-monster.com/blog/joomla-templates/this-joomla-template-follows-recommendations-
for-making-web-content-more-accessible-wcag-2-0
11 Sitio web de Accesible Template http://www.accessibletemplate.com/

19
 ANEXO 2: EVALUACIÓN DE ACCESIBILIDAD MOODLE

Informe Validación de
Accesibilidad Moodle 3.0
Sitio web http://temabnc.colnodo.apc.org/
Septiembre-Octubre 2017

El presente documento1 contiene el informe de la validación de accesibilidad a una

instalación de Moodle versión 3.0, el análisis de los resultados de los validadores
automaticos Taw y NTC5854.org (nivel AA), así como de la revisión manual ejecutada sobre
el sitio, apoyados en herramientas como el lector de pantalla NVDA.

Inicialmente se evalúan las páginas de acceso y validación a Moodle, la página de inicio, la

página que lista los cursos de un aula virtual y la página principal de un curso.
Posteriormente, se evalúan algunas herramientas propias de Moodle, como quices,
archivos en PDF, entre otros, que hacen parte del contenido que será incorporado en el
curso “Mi biblioteca Incluyente” de la Biblioteca Nacional de Colombia, con el fin de prever
situaciones que disminuyan el nivel de accesibilidad del curso.

1
Elaborado por Jesús David Romero y Ana Maria Nates Rodríguez, pasantes Universidad Distrital
Francisco José de Caldas.

1
 Página de validación o login
http://temabnc.colnodo.apc.org/login/index.php

Validación Automática: Taw

Problemas
El validador encuentra un problema en la categoría Perceptible, y dos en la categoría
Robusto.
El informe detallado, muestra que el problema de perceptibilidad es causado por el uso de
una etiqueta <b> en la barra de idiomas. Este inconveniente se resuelve al instalar un nuevo
tema.
Los problemas notificados en el criterio Robusto, hacen referencia scripts de estilos y de
javascript, ubicados en el head del documento que no tienen etiqueta de apertura y cierre
sino se usa la etiqueta de apertura y cierre abreviados <link />

Advertencias
Las advertencias que requieren revisión manual son de tres tipos, perceptible, referente a
contenido no textual; operable en el título de la página y el uso de encabezados y etiquetas;
y comprensible respecto a la identificación de errores, la sugerencias ante errores y la
prevención de errores en el formulario de registro.
La advertencia perceptible llama la atención sobre el uso del atributo longdesc para el
pequeño icono de pregunta junto al anuncio de cookies. Sin embargo no representa
problema para el lector de pantalla, que describe la ayuda para habilitar las cookies.
Frente a las advertencias operables, el título de la página por defecto es el nombre del aula
virtual seguido de dos puntos y el área del sitio, en este caso, “Entrar al Sitio”. Según la
estrategia de la WCGA, el título cumple los ítems de identificación de la organización
(nombre del aula virtual) y luego el tema o contenido de la página.
Las advertencias comprensibles, aparecen para los label del formulario de ingreso. En la
revisión del código fuente se comprueba que se usan adecuadamente las etiquetas <h1> y
<h2> para el título y el subtítulo, mientras que los textos de los campos del nombre de
usuario y contraseña tienen etiquetas <label for> en cada caso.
Las advertencias de tipo comprensible también están relacionadas con el formulario de
ingreso. Dos notas llaman la atención sobre los formatos especiales, que no son
necesarios, y los valores erróneos, que si están soportados. Otras observaciones están

2
 orientadas a las sugerencias para valores erróneos, que no son necesarias, dada la forma
de validación del formulario (post envío).
Finalmente, se presentan advertencias sobre la prevención de errores (legales, financieros,
datos) que por el tipo de contenido, en este caso, no aplica.

No verificados
Las pautas no verificadas en el criterio perceptible señalan aspectos como lo adaptable y
las características sensoriales que se cumplen adecuadamente en el sitio. Sobre las pautas
Distinguibles, no hay uso de color para información, el contraste usado es adecuado,
puesto que la paleta es fondo blanco con texto negro y azul, y por último, no hay imágenes
en el documento.
Sobre el criterio Operable, el movimiento del foco con teclado está habilitado para todo el
documento. Sobre la pauta tiempo ajustable, las técnicas recomendadas como límite de
tiempo, tiempo controlado con script, o lectura y control de textos en movimiento no aplican.
No existen elementos dentro del sitio con destellos. Finalmente, sobre los aspectos
navegables, si hay un orden lógico de navegación, hay enlaces para navegar entre sitios,
el foco no altera o da acceso a elementos dinámicos.
El criterio comprensible abarca el idioma, modificable desde un menú desplegable que se
puede detectar con el lector y modificar con el teclado. Sobre las actividades relacionadas
con el foco, todas están validadas de acuerdo a las técnicas de la WCGA 2.0, excepto la
identificación consistente, pues al entrar a los campos usuario y contraseña no hay una
identificación adecuada, más allá del label que no se reconoce al recorrer la página
mediante el teclado.
Sobre el criterio Robusto, solo requiere comprobación del nombre, rol y valor, que para el
caso específico no es requerido, más allá de la etiqueta que indica “Usted no está
identificado”, o el nombre del usuario que tiene abierta la sesión.

Revisión manual:
Lector de pantalla NVDA
El formulario para el registro de usuarios ni los label ni los input tienen texto auxiliar o
descriptivo, por lo que son invisibles cuando se recorre la pantalla con el teclado, sin
embargo son reconocidos por el lector al recorrer el sitio con el mouse.

Responsive
El sitio es responsive para distintos tipos de móviles y pantallas de resoluciones grandes,
medianas y pequeñas sin causar dificultades al lector o en el despliegue de la información.

3
 Página principal
http://temabnc.colnodo.apc.org/
Esta página muestra el panorama general de los cursos del aula virtual. En la sección
central se despliega (si está disponible) una descripción del aula virtual. En la barra lateral
izquierda la Navegación entre las páginas del sitio, como el Calendario y las Marcas; los
Cursos y el Calendario de actividades.

Validación automática: TAW

Problemas
El problema Perceptible hallado por el evaluador corresponde a un enlace “Back to top”
detectado por la herramienta, que no tiene descripción o información. Al revisar el código
aparece, pero este no es visible en el sitio ni en el recorrido mediante techado por la
pantalla.
El problema operable, corresponde al criterio de navegabilidad 2.4.4, y de nuevo está
relacionado con el enlace “Back to top” del aspecto anterior.
Los errores del criterio robusto, son los mismos identificados en la sección anterior sobre
los links en el head del HTML.

4
Advertencias
La advertencia del criterio perceptible corresponde a un pequeño logo ubicado junto al
nombre del curso, que indica el estado o usuario con el que se accede al moodle. Esta
etiquetada como img y tiene el atributo alt, pero no requiere un longdesc .
Las Operables, incluyen las observaciones sobre formularios hechas en la sección anterior.
También llama la atención sobre el uso de los encabezados. Una vez revisado el código,
hace se encuentra que el header h2 no aparece entre el h1 de título de la página y el nombre
del curso en h3. Otra advertencia es sobre el uso de alt en las imágenes, pero tienen
descrito el atributo alt todas menos el icono de navegación en uno de los menús; sin
embargo ninguna requiere una descripción larga.
Sobre las advertencias comprensibles, se detalla en la sección anterior, pues son las
mismas observaciones (introducción asistida de datos y criterios 3.3.1, 3.3.13 y 3.3.4).

No verificados
Las características perceptibles no verificadas corresponden al aspecto distinguible, el uso
de color, el contraste mínimo, y las imágenes de texto, elementos validados anteriormente.
En el criterio operable, llama la atención sobre el movimiento del foco, la selección y todos
los aspectos de navegación por teclado. No hay elementos que aparecen o desaparecen
de la pantalla. Adicionalmente, la página tiene bloques de contenido definidos y con un
enlace oculto a simple vista pero perceptible al lector de pantalla y al recorrido por teclado
para saltar un bloque de contenido.
Los aspectos sobre los que llama la atención los no verificados comprensibles son varios.
En primer lugar, los relacionados con el foco están conforme a la norma. La denominación
y navegación consistente también se ajustan a las recomendaciones y no generan
confusión para el usuario mediante el uso de lectores de pantalla. Por último, no hay
cambios de comportamiento que se registren a la hora de cambiar el estado de un elemento.

Validación Manual
Al verificar manualmente el sitio web se utiliza la herramienta de lectura de pantalla NVDA
que corrobora los resultados de la evaluación anterior. Adicionalmente, vale señalar que los
iconos ubicados a la izquierda de los títulos como Navegación, Calendario y Cursos no son
detectados por el lector de pantalla. Esto debido a elementos alt que no están definidos,
pero dado que son iconos decorativos no se considera relevante su descripción.
Por otro lado al navegar desde el teclado se detectan elementos como saltar bloques de
información como el Navegar, Calendario, etc. Como se mencionó anteriormente, el
recorrido por teclado es coherente con la posición de los elementos en la página.

Antes de proceder con la siguiente revisión, vale la pena resaltar que estos problemas
detectados hacen parte de la estructura general de visualización de Moodle, por ende al

5
 evaluar otras páginas de este mismo entorno, estos problemas no serán analizados
nuevamente.

Pagina principal de cursos

http://temabnc.colnodo.apc.org/course/index.php

Esta página despliega dos grandes bloques de información, un bloque que lista todos los
cursos vinculados al aula virtual, y un bloque de navegación como en las páginas analizadas
anteriormente. Al igual que las otras, también cuenta con una menú superior para el idioma,
un header con el nombre del aula virtual y una sección para seguir la navegación.
Dado a que esta vista requiere un acceso de usuario validado, la herramienta de evaluación
automática que se usará es el validador ntc5854.org

Validación automática: ntc5854.org

La herramienta detecta 4 problemas y 80 potenciales problemas que deben ser analizados

mediante revisión manual para corroborar si son elementos no accesibles.

Problemas detectados
Dos de los problemas detectados están relacionados con el texto alterno de dos iconos.
Como se había mencionado antes, estos elementos no son relevantes para la descripción
o comprensión del contenido, por lo que no son elementos críticos.

6
 Sobre el criterio Distinguible, hay tres errores detectados que hacen referencia al uso de la
etiqueta i para escritura de caracteres en estilo itálico. Estos elementos están dentro del
bloque de información central pero no son perceptibles a simple vista ni al recorrido por
teclado (ya que el atributo tabindex está definido en -1).
En el criterio navegable, se encuentra un problema relacionado con el botón “back to top”.
Este tiene un enlace al inicio de la página. Se puede acceder mediante el teclado, pero su
descripción no es clara. La recomendación es utilizar un título para el botón o un alt para el
icono del botón que permite al usuario determinar la funcionalidad del botón. Por último, se
encuentra un error en el uso de los headers, pues seguido al <h1> del título, le sigue un
<h3> en los subtítulos del sitio.

Problemas potenciales
El primer criterio evaluado tiene que ver con los elementos img y su descripción. El validador
encuentra que casi todos los iconos decorativos en la página no tienen un texto alternativo,
lo equivalente a 26 problemas potenciales.
Los iconos son creados dentro de las etiquetas de enlaces, por lo que no son recorridos por
el teclado al mismo tiempo que el texto del enlace. Ya que estos iconos son meramente
decorativos, no se considera necesario incluir un texto alternativo a las imágenes
mencionadas.
Por otro lado, el validador encuentra otras 12
imágenes, pero en este caso el texto alternativo
contiene una descripción corta. No se consideran
problemas , dado que no es texto decorativo,
sino enlaces con funciones específicas, como
por ejemplo ocultar un bloque de información, o
ir al sitio personal del usuario
en sesión. Además, el contenido de los alt tiene
información clara como “Oculta bloque Navegación” como se puede ver en las imágenes.

Los últimos problemas registrados de este criterio, hacen referencia al icono que acompaña
la imagen de ocultar los bloques de información. El validador recomienda revisar el uso
adecuado del alt para que concuerde con la acción del tag input, en este caso una imagen.
Como se observa en el fragmento de código, el elemento <input> ejecuta una función
controlada desde la hoja de estilos. Esta acción, al validar sobre el sitio web, oculta o
despliega el bloque de Navegación en este caso, justo como se describe en el atributo alt
del mismo.

7
El criterio adaptable presenta varias observaciones. En primer lugar, habla de las listas que
pueden estar mal demarcadas. Al proceder con la validación del código fuente se encuentra
que los elementos listados están demarcados por las etiquetas li, ol y ul de forma adecuada
y son reconocidos por el lector de pantalla, a pesar de que los estilos definidos para cada
lista sean distintos.
Otro elemento de revisión son las marcas unicode de lectura de derecha a izquierda y de
izquierda a derecha. Al validar el sitio, es evidente que no existen bloques de texto que
requieran ser leídos en distintas direcciones, por tanto no es necesario hacer
modificaciones.
En la definición del body del documento se define que la dirección de texto es de izquierda
a derecha. En ningún lugar del sitio web es necesario modificarlo, por lo que este problema
relacionado con la etiqueta dir no se considera.
Finalmente, el validador identifica un potencial error en la cercanía que debe haber entre el
text field de búsqueda del curso y un elemento de control. Se valida esta condición en el
código fuente del sitio, y se encuentra que el text field y el botón de búsqueda se encuentran
dentro de un fieldset y un formulario, y el botón sucede al área de búsqueda en el HTML,
por lo que no existe error.

Los problemas del criterio distinguible, incluyen el contraste de los iconos con el fondo de
pantalla y en general el uso de color para determinar comportamientos.
Sobre lo primero, vale resaltar que no existen en el momento de la validación imágenes de
texto dentro del sitio web. Al validar el aspecto de uso de color en el sitio web y los scripts,
se encuentra que el color por sí solo no determina el comportamiento de los elementos, y
los scripts lo modifican en eventos como mouseover, que funcionan incluso con el
javascript sin activar.

En el criterio Navegable aparecen nuevamente aspectos como la navegación por teclado,

los links para saltar contenido, y que la descripción de los links sea suficientemente clara.
Al validar sobre el sitio estos elementos se encuentra que el recorrido por pantalla en los
elementos del sitio está habilitado para todo el sitio, y es coherente .Así mismo, el lector de
pantalla reconoce los enlaces y sus títulos son claros.

8
 Otro elemento a evaluar es la existencia de un mapa del sitio. El bloque Navegación,
pretende hacer las veces de mapa del sitio y está complementado con la barra de
navegación presente en todas las páginas al inicio.

Página de un curso
http://temabnc.colnodo.apc.org/course/view.php?id=2
Esta página despliega el contenido del curso, como los temas o semanas (según la
configuración del curso), además de el menú de navegación y herramientas adicionales del
curso, como el acceso a foros, avisos recientes, eventos y la actividad reciente del curso.
Esta y las páginas de las actividades del curso, son en las que el usuario dedica más tiempo
en el desarrollo del curso, por ende tiene gran importancia.

Validación automatica ntc5854.org

Al evaluar el sitio con la herramienta ntc5854.org, el resultado es 9 problemas detectados,
y 263 potenciales problemas. Cabe recordar que aquellos problemas que han sido descritos
en otros sitios no se analizaran.

9
Problemas detectados
El primer problema detectado es sobre imágenes usadas como hipervínculos sin el atributo
alt definido. Al revisar el código fuente y el sitio web, se encuentra que hay elementos en la
sección del contenido del curso que contienen imágenes que sirven como enlaces sin el
atributo alt determinado, motivo por el cual el lector de pantalla los reconoce como enlaces
invisibles. Además dentro del enlace se encuentra un span con una etiqueta que acompaña
al botón, pero que no suple las funciones del alt, como se puede detallar en el siguiente
código correspondiente a la zona de “Avisos”. Casi todos los elementos de esta sección,
contiene enlaces con las mismas características, el validador encontró 5 correspondientes
a los enlaces de recursos en el aula virtual.

Los otros problemas están relacionados con el uso de etiquetas <i> y el problema del botón
back to top.

Problemas probables
Los errores probables se refieren a los alt de las imágenes e
iconos. De nuevo se recalca que no hay imágenes de texto y que
las únicas imágenes que requieren alt y no lo tienen son las
descritas anteriormente.
Sobre el criterio de accesibilidad desde el teclado, existe otro
inconveniente importante. El área donde se despliegan las
actividades semana a semana del curso están desplegadas como
listas con etiquetas ul y li bien utilizadas.

El problema surge al detallar los elementos dentro de las listas,

en este caso, por ejemplo el primer tema del curso (en la imagen
“Tema prueba 1”). Este elemento navegando mediante el teclado
es totalmente invisible, puesto que el elemento li no tiene activado
el atributo tabindex, ni ninguno de los elementos en los que
está contenido (un div y un h3).
El resultado entonces al recorrer la página es saltar del enlace
“Avisos” directamente hasta “Cuestionario prueba 1” sin anunciar

10
 al usuario que saltó el primer tema que no contiene elementos con el focus activado ni
anunciando en qué temática se encuentra actualmente.
La solución propuesta, es agregar el atributo tabindex="0" a los elementos li pertenecientes
a la clase "section main clearfix", que corresponde a todos los Temas principales. Otras
listas como las de los quices, pruebas o PDFs del Tema 2 ya son enlaces y si son
reconocidos al recorrer la pantalla, por lo que no es necesaria su modificación.
Los otros posibles problemas detectados hacen alusión a elementos y revisados como
contraste, uso de formularios , navegación consistente, el uso de headers, el mapa del sitio,
los bloques de saltar contenido, entre otros derivados y presentes en las normas.

Páginas de actividades del curso

Revisadas las páginas principales del aula virtual, se procede ahora a evaluar las páginas
a las que se tiene acceso desde los cursos.

Cuestionario
Esta es la página que despliega un cuestionario con dos preguntas cerradas de opción
múltiple. Al igual que las otras páginas, esta también tiene unos bloques para la navegación
por la plataforma por lo que los errores provenientes de esta sección no se analizaran de
nuevo.

11
 La pagina se descarga para subir el archivo a la plataforma
http://ntc5854.org/validador/checker ya que el inicio de sesión no permite utilizar el validador
que se venía utilizando (TAW). Estas claridades se replican para las siguientes actividades
a evaluar.

Problemas detectados
Dejando de lado los problemas detectados y analizados en la sección anterior, causados
por la barra de navegación y otros elementos genéricos; el analizador detecta que el
formulario que provee los radio buttons no tiene la etiqueta fieldset y legend que permiten
identificar a que hace referencia este formulario, añadiendo estas etiqueta el formulario
queda descrito. Por otro lado el titulo curso prueba 1 es un h1 y luego hay un h3
ocasionando un error en el anidamiento de títulos, basta con cambiar el h1 por un h2.

Problemas potenciales
Los problemas potenciales detectados en secciones anteriores se retoman acá, como las
imágenes, los textos alternativos, y el contraste de colores en diferentes partes de la página.

Validación manual con NVDA

Cuando se pasa el lector de pantalla por la página, se detectan algunos problemas de
navegabilidad.
Mediante tabulación no se puede acceder al enunciado de las preguntas, únicamente a las
opciones de respuesta.
El título de la pregunta tampoco es identificado por la tabulación lo que puede ocasionar
desubicación dentro del sitio.
Para estos problemas de tabulación se agrega el atributo tabindex = “0” bien sea desde el
editor HTML de Moodle o directamente en el código fuente según sea la necesidad.

En el cuestionario hay un video, que no garantiza la recepción del contenido a personas

sordas, ya que no presenta ayuda de subtítulos, igual problema puede presentar un audio,
se recomienda en estos casos buscar videos que tengan esta ayuda o adaptarlos
manualmente, o en última instancia generar un texto con el resúmen o con la transcripción
del contenido.

12
 Textos

Esta página únicamente tiene un texto escrito, con posibilidad de agregar material
audiovisual, o contenido embebido externamente.

La evaluación realizada con http://ntc5854.org/validador/checker no arroja muchas

novedades, más que los errores básicos de accesibilidad en el texto, como etiquetas <i> y
<b>.

Validación manual con NVDA

Al recorrer la página con NVDA mediante tabulaciones, no se enfoca el texto escrito, por
lo que NVDA no lo lee quedando esta página muy poco funcional para personas con
discapacidad visual.
El editor de HTML permite agregar el atributo tabindex=”0” al texto escrito, así ya puede
ser recorrido con facilidad mediante tabulaciones.

PDF

Subir archivo
En esta página se sube el archivo pdf mediante el gestor de Moodle, quedando la página
de la siguiente forma.

13
Embeber
Por otro lado se puede utilizar el tag <embed> para que en esta misma página aparezca el
pdf.

Al hacer la evaluación automática no son muchos los errores que se muestran, solo
cuando se embebe muestra que hace falta una etiqueta <noembed> que describe lo
embebido.

14
Validación manual con NVDA
Con el lector de pantalla no hubo problema al recorrer el documento, se recomienda
utilizar en los documentos PDF un nombre sencillo y descriptivo que facilite al usuario
saber qué está leyendo y para evitar confusiones.

Resumen de modificaciones
Retomando los elementos de la evaluación de la sección anterior, se resumen aca las
modificaciones necesarias para cumplir las observaciones de nivel AA para los cursos
virtuales en la plataforma Moodle en los cuatro criterios evaluados por la norma, a saber,
perceptible, operable, comprensible y robusto.
Se tendrán en cuenta los resultados de la validación automática con herramientas como
TAWs y el sitio web ntc5854.org, y la validación manual compuesta de revisión del código
fuente, recorrido por teclado y herramientas como el lector de pantalla NVDA.

Títulos
Es importante ser claros al determinar los títulos de los módulos de los cursos, del aula
virtual y de la página en sí misma, la norma pide que sean claros y descriptivos.
Moodle respeta el uso ordenado de headers excepto en el título general del curso, señalado
con <h1> que es seguido por un <h3> en los subtítulos del sitio. Aquí se recomienda
cambiar el título del curso para que corresponda con el orden de anidación.

Formularios acceso de usuario

Los formularios en Moodle no hace validación previa al envío de información de los datos
ingresados. De considerarse necesario este aspecto, se requiere limitar los tipos de datos
que se ingresan a los formularios.
No todos los formularios cuentan con un campo fieldset para describir su contenido o
finalidad. Se sugiere agregarlos para mejorar la navegabilidad.Adicionalmente, se puede
mejorar la navegación si se agregan etiquetas descriptivas a los campos de texto, que
parecen invisibles y poco claras al ser recorridas por el lector de pantalla.

Botón “Back to top”

Este botón está presente en casi todas las páginas y aparece cuando el usuario ha recorrido
la pagina y esta llegando a las secciones finales. El botón presenta varios problemas,
empezando con que el nombre del botón está en inglés y que no tiene atributos que guíen
al usuario. La recomendación es utilizar un título para el botón o un alt para el icono del
botón que permita comprender al usuario la funcionalidad del botón.

15
Estilo de texto
Moodle ofrece un editor de HTML que para la redacción de introducciones, textos, contenido
etc. En estos elementos el uso de las etiquetas <i> y <b> debe evitarse, puesto que el
lector de pantalla no lo reconoce. A menos que sea irrelevante el estilo de la letra, deben
usarse las etiquetas <strong> o <em>.

Focalizar elementos
Algunos cuadros de texto, lecturas, u otros elementos que no tienen un link, no son
focalizables al recorrer la página mediante tabulaciones, lo que hace que si se piensa
navegar de esta manera, se queda mucho contenido fuera del rango de accesibilidad. Para
corregir esto basta con identificar dichos elementos que se quiere focalizar y agregarles
mediante el código fuente o editores HTML del mismo Moodle, el atributo tabindex=”0”.
Esta recomendación es fundamental para la página que despliega los temas de los cursos,
puesto que estos se despliegan en una lista no recorrible. Es decir, agregar el atributo
tabindex=”0” a los elementos ul en la clase "section main clearfix".

Contenido auditivo
Videos o audios serán imposibles de percibir por personas con discapacidad auditiva, por
lo que se recomienda generar los subtítulos para los videos o un texto alterno que resuma
o transcriba la información de dichos contenidos.

16
 ANEXO 3: EVALUACIÓN DE ACCESIBILIDAD MICROSITIOS

Ajustes de Accesibilidad
Plantilla de micrositios
Biblioteca Nacional de Colombia

A continuación se presentan los cambios a realizar en la plantilla del micrositio alojado en

la direccion http://mro.colnodo.apc.org/2017bibnal/micrositio/# resultado de la evaluación
de accesibilidad manual y automática. Se presenta según el estado del sitio a 26 de
Noviembre del 2017.

1. Agregar texto alternativo icono menu

Archivo: index.html
Linea 40: <img src="graficasMicrositio/menu.png" class="img-
responsive"/>
Corrección: añadir atributo alt=”Menú de contenidos del Módulo”
a la etiqueta <img>

2. Menu
El menú a pesar de estar oculto se sigue recorriendo con tab, lo que se recomienda es
dejarlo oculto con el atributo hidden=”true”, y cambiarle el valor a false cuando se haga click
mediante el script.

Archivo: index.html
Línea 41: <div id="sidebar-wrapper">
Corrección: añadir atributo hidden=”true”

Línea 56: $("#sidebar-wrapper").toggleClass("active");

Corrección: añadir la línea: $("#sidebar-wrapper").attr("hidden",false);

Línea 61: $("#sidebar-wrapper").removeClass("active");

17
 Corrección: añadir la línea: $("#sidebar-wrapper").attr("hidden",true);

Además, una vez desplegado el menú, no se puede visualizar completamente, se propone

añadir un scrollbar y modificar el tamaño de este div emergente.

Archivo: micrositios.css
Línea 213: reglas del .sidebar-nav
Corrección: Añadir las líneas:height:50%;
overflow: scroll;

Por último, el enlace y la imagen para cerrar el menú no tienen elementos descriptivos de
su función.
Archivo: include-menu.html
Línea 3: <img src="graficasMicrositio/cierra.png" … >
Corrección: Agregar el atributo title=”Cerrar Menú”.

3. Encabezado
Existe un problema en el uso de los encabezados. El nombre del curso es un h1, pero el
nombre del módulo y las temáticas son h2, lo cual genera confusión en el usuario y errores
de anidamiento de encabezados. Se propone asignar de forma ordenada los encabezados
de sección, lo cual implica cambiar las etiquetas del encabezado y reasignar las reglas css:

Archivo: index.html
Línea 75: :<h2 class="tematica">Temática 1. La preservación de colecciones
fotográficas en bibliotecas de investigación</h2>
Corrección: Modificar la etiqueta h2 por h3

Archivo: micrositio.css
Línea162 : .encabezado h2.tematica{
Correción: Cambiar el nombre de la regla, de “.encabezado h2.tematica” a
“.encabezado h3”

4. Pestañas Recursos
La revisión automática de Norbey Salazar hace otras apreciaciones sobre el contenido de
los enlaces (por ejemplo que están vacíos o sin descripción) que se debe al estado
prematuro del sitio pero que deben tenerse en cuenta.

Para mejorar la experiencia de usabilidad, se recomienda agregar etiquetas descriptivas a

los elementos <div> que encabezan cada una de las pestañas: Asociados a esta temática
y Asociados a este módulo.

Archivo: index.html
Línea 148: <div …. id="headingOne">

18
 Corrección: Agregar el atributo: title=”Haga click para desplegar los Recursos
Asociados a esta Temática”

Línea 192: <div …. id="headingTwo">

Corrección: Agregar el atributo title=”Haga click para desplegar los Recursos
Asociados a este Módulo”

En la lista de recursos de ambas pestañas, los iconos no tienen un alt. Se requiere describir
qué tipo de archivo contiene el recurso (PDF, audio, video, etc).

Archivo: index.html
Corrección:Definir claramente en el <p> el tipo de archivo, el nombre del mismo y
una descripción corta, más la información pertinente.

Archivo: index.html
Lineas: <img src="graficasMicrositio/ico-[tipo de archivo].png" …. >
Corrección: Agregar un atributo alt=”Icono [tipo de archivo]” siendo el tipo de
archivo documento PDF, video, audio, etc.

5. Contenido de la página
Una primera observación, es que el texto que encabeza el
contenido de los módulos no es un encabezado, sino un div
con una clase específica “subtítulo”, lo cual confunde al
usuario sobre si es un título o el texto del contenido. La solución es ajustar el estilo de uno
de los headers de acuerdo al anidamiento, por ejemplo el h4.

Archivo: index.html
Línea 106:: <div class="contenidos-titulo">Fundamentos y prácticas de
catalogación
Corrección: Modificar el div por h4 y mantener la clase "contenidos-titulo"

Se recomienda aplicar el mismo cambio a todos los títulos de las demás páginas.

5.1. Botones
Cuándo se señala un botón no hay un cambio gráfico perceptible que permita ubicar al
usuario qué botón está señalando. Para esto se propone agregar en el CSS un cambio al
cual aplicar las transiciones definidas, por ejemplo, el color del background cuando se
enfoque un botón.

19
 Archivo: micrositio.css
Línea 461: .boton a:hover, .boton a:focus{}
Corrección: en la regla agregar un atributo background:<color>; colocando un
color que permita identificar el cambio en el hover.

5.2. Audios
En los audios es recomendable colocar el atributo title para dar una pista al visitante de lo
que hace referencia el audio, o para dar la instrucción de reproducción.

Archivo: pag3.html
Línea 122: <audio id="player2" preload="none" controls style="max-width:100%;">
Corrección: agregar atributo title=”Audio alusivo a la temática”

5.3. Imágenes
Todas las imágenes del contenido que están actualmente
no son solo decorativas, sino que acompañan la temática
del contenido. Por ende se sugiere agregarle un texto
descriptivo a cada una de ellas con el atributo alt=”Texto
corto descriptivo de la imágen”.

Cuando la imagen cuenta con un pie de foto que ayuda a

describir el contenido de la misma, se recomienda dejar
vacío el atributo alt=””.

5.4. Lecturas PDF

El iframe que se inserta para la lectura de los PDF incluye elementos para facilitar la
navegación mediante teclado, pero es inaccesible para lectores de pantalla, puesto que
las “páginas” que muestra en la lectura del PDF son imágenes. La norma pide agregar un
longdesc con la transcripción del contenido de cada página. Una alternativa para evitar
esta tediosa labor, es advertir al usuario la falencia de la herramienta y sugerir la descarga
del PDF. Esta alternativa también soluciona el problema que pueden encontrar usuarios
con el JavaScript desactivado o desactualizado.

Archivo: lecturas.html
Línea 51: <iframe src="..../index.html" allowfullscreen></iframe>

20
 Corrección: Agregar el siguiente código antes del iframe:
<div class= “sr-only”><p>"Esta aplicación permite visualizar cada página del
documento PDF como una imagen con efectos visuales. Requiere activar el
JavaScript en el navegador. Si no puede visualizar el documento, vaya al botón
Descargar PDF y acceda al contenido desde su lector de PDF favorito"</p></div>

Corrección: Agregar atributo title=”Visualizador de documentos PDF” a la etiqueta

iframe.

Recomendaciones de Accesibilidad para Micrositios

Biblioteca Nacional de Colombia

Las siguientes pautas2 buscan garantizar que el contenido nuevo de los micrositios
vinculados a los cursos de la Biblioteca Nacional de Colombia cumpla con los estándares
de accesibilidad AA según la NTC 5854.

Títulos y estructura de la página

Para facilitar la comprensión de la estructura de la página y la jerarquía de los títulos y
subtítulos, se hace necesario usar los encabezados de sección de HTML de la siguiente
forma:
Encabezado Uso

H1 Nombre del curso (en mayúsculas)

H2 Número y nombre del módulo

2Elaboradas por Ana Maria Nates y Jesús Romero, pasantes de la Universidad Distrital Francisco
Jose de Caldas

21
 H3 Número y nombre de la Temática

H4 Título del contenido del micrositio

En la siguiente imágen se puede ver el uso correcto de los encabezados de sección en

una de las páginas de los micrositios:

Imágenes
Muchas veces se utilizan imágenes como guía dentro de la página o como alternativas para
la presentación de información vital. Para las personas con discapacidad visual es necesaria
una descripción detallada del contenido del sitio, por lo que cuando se presenten estos
casos con contenido gráfico, es necesario agregar una descripción textual de lo que se
pretende expresar con la imagen.

<img alt="Descripción de la imagen">

Si la imagen no transmite contenido importante, se debe indicar, colocando el atributo alt

vacío; de igual forma, cuando la imagen viene acompañada de un pie de foto que la
describa, no hay necesidad de llenar el atributo alt, cómo se muestra a continuación:

<img alt="">

Iframes y elementos embebidos

Los elementos exportados de otras plataformas o con recursos externos pueden resultar
incomprensibles para lectores de pantalla, inaccesibles mediante el teclado, o confusos
para algunos usuarios.
Por tal motivo, es necesario agregar el atributo

22
 title="Texto corto que describe el elemento"

a las etiquetas <iframe>, <embeded>, entre otros. El texto que se introduce en las comillas
debe ser corto y claro, para que el usuario comprenda la función del recurso insertado.

Para el caso de lecturas en PDF, la herramienta Flip, no es accesible para usuarios con
dispositivos sin JavaScript activado o lectores de pantalla. Por ende se debe informar al
usuario que no podrá acceder al contenido, mediante la siguiente etiqueta div:

<div class= "sr-only"><p>"Esta aplicación permite visualizar cada

página del documento PDF como una imagen con efectos visuales.
Requiere activar el JavaScript en el navegador. Si no puede
visualizar el documento, vaya al botón Descargar PDF y acceda al
contenido desde su lector de PDF favorito"</p></div>

Adicionalmente, se debe incluir en el <iframe> embebido el atributo

title="Visualizador de documentos PDF"

Pestañas de recursos
Las pestañas de recursos cuentan con iconos y textos que describen el acceso a distinto
tipo de materiales (audios, documentos PDF, videos, entre otros). El estándar de
accesibilidad recomienda agregar un atributo a las imágenes que oriente al usuario sobre
el contenido de la misma. Por ende, se recomienda agregar en cada icono el atributo title
(dentro de la etiqueta <img>) especificando el tipo de recurso:

alt="Icono Video"
alt="Icono Documento en PDF"
alt="Icono Audio"

De igual forma, es recomendable, al ingresar el nombre del recurso describir claramente

el tipo de recurso, el nombre, y si se desea, una breve descripción:

23
ANEXO 4: SOPORTES DESARROLLO SITIO OBSERVATORIO DE
TERRITORIOS ÉTNICOS Y CAMPESINOS

24