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

1

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.

2

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

3

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.

4

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

5

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/

6

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.

7

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.

8

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.

9

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.

10

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

11

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:

25 W3C. 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/

12

o Leí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

13

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.

14

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.

15

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

16

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

17

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:

18

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.

19

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.

20

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.

21

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.

22

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.

23

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

24

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

25

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

26

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

27

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

28

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.

29

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

30

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.

31

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.

32

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

33

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.

34

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

35

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

36

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.

37

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

38

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.

39

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

40

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

41

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.

42

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

43

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

44

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/

1

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,

2

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.

3

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

4

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

5

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.

6

● 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

7

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

8

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

9

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

10

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.

11

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.

12

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

13

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,

14

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/

15

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

16

○ 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

17

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.

18

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.

19

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/

1

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.

2

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

3

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.

4

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.

5

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

6

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.

7

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.

8

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.

9

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.

10

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

11

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.

12

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.

13

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.

14

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.

15

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.

16

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.

17

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");

18

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

19

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.

20

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>

21

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

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

Jose de Caldas

22

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

23

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:

24

ANEXO 4: SOPORTES DESARROLLO SITIO OBSERVATORIO DE

TERRITORIOS ÉTNICOS Y CAMPESINOS