Una web para todos. Comprendiendo y aplicando las WCAG 2.0 by Jorge Ivan Pincay Ponce

UNA WEB PARA TODOS

Colección Dossier Académico TECNOLOGÍAS DE LA INFORMACIÓN Y LA COMUNICACIÓN (T.I.C.) )

UNA WEB PARA TODOS Comprendiendo y aplicando las WCAG 2.0

Jorge Ivรกn Pincay Ponce

UNIVERSIDAD LAICA ELOY ALFARO DE MANABÍ Ciudadela universitaria vía circunvalación (Manta) www.uleam.edu.ec Autoridades: Miguel Camino Solórzano, Rector Iliana Fernández,Vicerrectora Académica Doris Cevallos Zambrano,Vicerrectora Administrativa Una web para todos. Comprendiendo y aplicando las WCAG 2.0 © Jorge Pincay Ponce Revisión pares académicos: Nombre: Diego Renato Sornoza Parrales Institución: Universidad Estatal del Sur de Manabí Tiempo completo, parcial o agregado: completo Teléfono: 0999513197 Email: diego.sornoza@unesum.edu.ec Nombre:Vicente Fray Romero Castro Institución: Universidad Estatal del Sur de Manabí Tiempo completo, parcial o agregado: completo Teléfono: 0983221182 Email:vicente.romero@unesum.edu.ec Consejo Editorial: Universidad Laica Eloy Alfaro de Manabí Director Editorial: Hernán Murillo Bustillos Diseño de cubierta: José Márquez Rodríguez Diseño y diagramación: José Márquez Rodríguez Estilo, corrección y edición: Alexis Cuzme (DEPU) ISBN: 978-9942-959-99-7 Edición: Primera. Septiembre 2017 Departamento de Edición y Publicación Universitaria (DEPU) Editorial Mar Abierto 2 623 026 Ext. 255 www.marabierto.uleam.edu.ec www.depu.uleam.blogspot.com www.editorialmarabierto.blogspot.com Manta - Manabí - Ecuador

ÍNDICE RESUMEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 AGRADECIMIENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 PRESENTACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 CAPÍTULO 1: COMPRENDIENDO LAS GUÍAS DE ACCESIBILIDAD AL CONTENIDO EN LA WEB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2. Organización de las WCAG 2.0 (principios, pautas, criterios, técnicas y fallos). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.1.1. Perceptible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.1.2. Operable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.1.3. Comprensible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.1.4. Robusto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.2. Pautas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.2.1. Pautas para la perceptibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.2.2. Pautas para la operabilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.2.3. Pautas para la comprensibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.2.2.4. Pautas para la robustez. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.2.3. Criterios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 CAPÍTULO II: HERRAMIENTAS DE EVALUACIÓN AUTOMÁTICA DE LA ACCESIBILIDAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2. Herramientas seleccionadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1. ACHEKERS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2. CHECKERS de la EIII. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3. CYNTHIASAYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4. Nibbler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.5. WebAIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3. Ejemplo de Test con CHECKERS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 CAPÍTULO III: EVALUACIÓN DEL SITIO WEB DE EJEMPLO. . . . . . . . . . . . . . . 31 3.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2. Página web 1. Página principal de vivero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3. Página web 2: Productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.4. Página web 3: ¿Dónde estamos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7

3.5. Página web 4: Contacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 CAPÍTULO IV: REDISEÑO DEL SITIO ORIGINAL, REEVALUACIÓN . . . . . . . . 45 4.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2. Modificaciones realizadas para cumplir WCAG 2.0 nivel AA . . . . . . . . . . . . . . . . . . 47 4.2.1. Modificaciones en el archivo index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.2. Modificaciones en el archivo productos.html . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.3. Modificaciones en el archivo donde_estamos.htmll. . . . . . . . . . . . . . . . . . . 55 4.3. Modificaciones realizadas para cumplir WAI-ARIA 1.0. . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1. Modificaciones en el archivo index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.2. Modificaciones en el archivo productos.html . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3.3. Modificaciones en el archivo donde_estamos.html. . . . . . . . . . . . . . . . . . . . 60 4.3.4. Modificaciones en el contacto.html. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4. Evaluación de la accesibilidad del sitio rediseñado. . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Índice de Tablas Tabla 1: Los 25 criterios de conformidad con el nivel A de WCAG 2.0 . . . . . . . . . . . . 22 Tabla 2: Los 25 criterios de conformidad con el nivel AA de WCAG 2.0. . . . . . . . . . . 23 Tabla 3: Los 25 criterios de conformidad con el nivel AA de WCAG 2.0. . . . . . . . . . . 23 Tabla 4: Modificaciones realizadas en la página principal, parte 1. . . . . . . . . . . . . . . . . . 48 Tabla 5: Modificaciones realizadas en la página principal, parte 2 . . . . . . . . . . . . . . . . . 49 Tabla 6: Modificaciones realizadas en la página principal, parte 3 . . . . . . . . . . . . . . . . . 49 Tabla 7: Modificaciones realizadas en la página principal, parte 4 . . . . . . . . . . . . . . . . . 50 Tabla 8: Modificaciones realizadas en la página principal, parte 5 . . . . . . . . . . . . . . . . . 51 Tabla 9: Modificaciones realizadas en la página principal, parte 6 . . . . . . . . . . . . . . . . . 52 Tabla 10: Modificaciones realizadas en la página principal, parte 7. . . . . . . . . . . . . . . . . 53 Tabla 11: Modificaciones realizadas en la página principal, parte 8 . . . . . . . . . . . . . . . . 53 Tabla 12: Modificaciones realizadas en la página principal, parte 9 . . . . . . . . . . . . . . . . 54 Tabla 13: Modificaciones realizadas en la página Contacto, parte 1. . . . . . . . . . . . . . . . 55 Tabla 14: Modificaciones realizadas en la página Contacto, parte 2. . . . . . . . . . . . . . . . 55 Tabla 15: Modificaciones realizadas en la página Contacto, parte 3. . . . . . . . . . . . . . . . 56 Tabla 16: Modificaciones realizadas en la página Contacto, parte 4. . . . . . . . . . . . . . . . 56 Tabla 17: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Tabla 18: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Tabla 19: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Tabla 20: Modificaciones realizadas para cumplir WAI ARIA 8

en la página Productos, parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Tabla 21: Modificaciones realizadas para cumplir WAI ARIA en la página Productos, parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Tabla 22: Modificaciones realizadas para cumplir WAI ARIA en la página Contacto, parte 1.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Tabla 23: Modificaciones realizadas para cumplir WAI ARIA en la página Contacto, parte 2.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Bibliografía. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Glosario de términos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Sobre el autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

RESUMEN Este libro tiene por objetivo ofrecer una mirada teórica y una aplicación práctica sobre la construcción o el rediseño de sitios web accesibles, entendiendo como accesibilidad del contenido en la web, a que personas con algún tipo de discapacidad puedan usar una web diseñada para resultarles perceptible, operable, comprensible y robusta en el sentido de soportar e interactuar con tecnologías de asistencia que la persona requiera. Como marco de referencia se ha considerado a las Guías del Contenido Accesible en la Web (WCAG) en su versión 2.0, guías difundidas bajo la responsabilidad del grupo de Iniciativas para la Accesibilidad Web (WAI) del Consorcio Mundial de Internet (W3C), y que son primordiales en el desarrollo de las tecnologías web y en la consolidación del marco legal de la accesibilidad en muchos países. Respecto a la aplicación de las guías, en este libro se rediseña un sitio web inaccesible que contiene información ficticia; se le readecúa la interfaz (incluyendo cambios en hojas de estilos CSS), se le aplican etiquetas HTML semánticas, se le implementan funcionalidades con JavaScript y se le edita el contraste en sus imágenes. Con lo descrito, se pretende ilustrar la aplicación técnica de las WCAG 2.0, pues según Tim Berners-Lee, el padre del Internet, “El poder de la Web está en su universalidad. Un acceso para todo el mundo independientemente de su discapacidad es un aspecto esencial”. PALABRAS CLAVE: WCAG, ARIA, HTML5, Rediseño web, Accesibilidad Web.

Este libro está dedicado a Dios quien es dueño de toda sabiduría y conocimiento, a mis padres amados, hermanos, familiares, los más fraternos amigos y por su supuesto a todo lector que llegue este libro, que busca ser un aporte para tener una web para todos. Jorge Pincay Ponce

AGRADECIMIENTO Agradezco a la que considero una gran comunidad académica, la Facultad de Ciencias Informáticas (FACCI) de la Universidad Laica Eloy Alfaro de Manabí (ULEAM). Noble institución donde me formé como ingeniero en sistemas y que me acoge como docente ocasional desde el año 2008. Esta comunidad es una razón e inspiración de mi formación personal y profesional, misma que puedo compartir generando retroalimentaciones cotidianas desde las aulas de clases. Jorge Pincay Ponce

PRESENTACIÓN

decir del Consorcio Mundial de Internet (W3C), la accesibilidad Web significa que personas con algún tipo de discapacidad van a poder hacer uso de una web diseñada para permitir que estas personas puedan percibir, entender, navegar e interactuar en y con la misma; aportando a su vez contenidos en diferentes escenarios de la vida: educación, empleo, gobierno, comercio, sanidad, entretenimiento, entre otros. Hay otros elementos adicionales a lo que la web “presenta” y para esos elementos el W3C también ha dedicado diversas investigaciones. Más específicamente es en el año 1997 cuando el W3C creó el grupo de trabajo Web Accessibility Initiative (WAI), responsable del desarrollo e impulso de las denominadas Web Content Accessibility Guidelines (WCAG), primordiales en el desarrollo de las tecnologías web y también primordiales para la consolidación del marco legal de la accesibilidad en muchos países.Tales guías de accesibilidad al contenido en la web tienen como soporte otras guías como las pautas de la accesibilidad de las herramientas de autor (ATAG), de los agentes de usuario (UAAG); estas también impulsadas por el W3C. El W3C es un consorcio internacional que genera recomendaciones y estándares que aseguran el crecimiento de la web a largo plazo y que se lo creó en octubre de 1994, en un acontecimiento liderado por el considerado padre de la internet: Tim Berners-Lee. Él siempre ha valorado la universalidad de la web y lo ha expresado en frases muy difundidas, como, por ejemplo: “El poder de la Web está en su universalidad. Un acceso para todo el mundo independientemente de su discapacidad es un aspecto esencial”. En este libro se explicará por medio de ejemplos, ¿Cómo implementar o rediseñar sitios web para que sean accesibles? Para ello se ha tomado como referencia a las mencionadas WCAG en su versión 2.0, publicadas en el año 2008. Las respuestas al citado ¿Cómo?, se plasman por medio de la evaluación y rediseño para la accesibilidad de un sitio web ficticio que presenta información sobre un vivero. Para fines de este libro, el sitio original sufrió readecuaciones de interfaz, empleo de etiquetas HTML semánticas, implementación de funcionalidades con JavaScript, valoración del contraste de imágenes… Comprendiendo y aplicando las WCAG 2.0. Jorge Pincay Ponce Profesor del grado de sistemas de la Universidad Laica Eloy Alfaro de Manabí – Ecuador

CAPÍTULO 1

COMPRENDIENDO LAS GUÍAS DE ACCESIBILIDAD AL CONTENIDO EN LA WEB

La sabiduría comienza por la definición de los términos: Sócrates

1.1. Introducción En la actualidad la accesibilidad web, es sinónimo de la web para todos, una premisa muy noble y técnicamente respaldada por diversas investigaciones y sus consecuentes estándares y tecnologías, pensadas en afrontar barreras que afectan a todas las personas en situaciones de limitación del contexto donde se esté navegando, independientemente de sus capacidades (Moreno, Martínez, & González, 2014) En muchos países, existe legislación en la que quedan explícitos los derechos de las personas con discapacidad (Sloan, et el, 2006) y para hacerla operativa, existen estándares y buenas prácticas de guía en el desarrollo de productos y servicios tecnológicamente accesibles. Respecto a las definiciones, a la fecha existen varias, por ejemplo, para (Raman, 1994) la accesibilidad es “la cantidad de información estructural capturada por la codificación; el grado en que esta información está disponible para otras aplicaciones y la disponibilidad de software adecuado para procesar esta estructura”, en tanto que para el Consorcio Mundial de Internet (W3C), “es el acceso universal a la Web, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localización geográfica y capacidades de los usuarios”. Sin duda, discapacidad no es sinónimo de soledad y en consonancia con esto corporaciones como Apple lo entienden y difunden así: “Creemos que la tecnología debe ser accesible para todo el mundo. La tecnología más poderosa del mundo es aquella que todos, incluso las personas con alguna discapacidad pueden usar para trabajar, crear, comunicarse, mantenerse en forma y entretenerse”. (Apple Inc, 2017) Por lo escrito, se establece que un sitio web accesible puede ayudar a personas con discapacidad a que participen más activamente en la sociedad. A continuación, se explican detalles a considerar para la evaluación y rediseño buscando la accesibilidad de un sitio web, específicamente se explica cómo comprender la organización de las WCAG 2.0 (principios, pautas, criterios, técnicas y fallos).

1.2. Organización de las WCAG 2.0 (principios, pautas, criterios, técnicas y fallos) Como punto de partida a esta sección, es importante comprender que los estándares sobre accesibilidad web ofrecen e impulsan un marco común para regular diferentes aspectos relacionados con el desarrollo y evaluación de sistemas web accesibles a través de protocolos de Internet, mediante un navegador web. Los navegadores también son clave en la accesibilidad web (Dyno Mapper, 2017) Uno de estos estándares, son las Pautas de Accesibilidad de Contenido Web 2.0 (WCAG 2.0 por sus siglas en inglés), estas cubren recomendaciones para hacer el contenido web más accesible para el mayor rango de personas con discapacidades, las que incluyen ceguera o visión deficiente, sordera y pérdida de audición, deficiencias de aprendizaje, limitaciones cognitivas, movilidad reducida, deficiencias del lenguaje y las combinaciones de todas estas. Las pautas WCAG 2.0 se han redactado como enunciados comprobables que no son específicos 19

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

de ninguna tecnología, sin embargo, las soluciones que se presentan en este libro se orientan al empleo de etiquetas HTML semánticas, implementación de funcionalidades con JavaScript, CSS y valoración del contraste de imágenes. Las WCAG, establecen 61 requisitos para las páginas web, basados en cuatro principios básicos, mismos que se revisan a continuación.

1.2.1. Principios Los cuatro principios básicos de las WCAG 2.0 son: Perceptible, Operable, Comprensible y Robusto; a continuación, se los detallará brevemente.

1.2.1.1. Perceptible La información y los componentes de la interfaz de usuario deben ser presentados a los usuarios de modo que ellos puedan percibirlos, más en detalle, significaría proporcionar alternativas textuales a contenidos no textuales; alternativas de sincronización para contenidos multimedia tempo dependientes; que tenga contenidos presentables de diversas maneras, pero manteniendo la información o estructura; y que permita la escucha de los contenidos y la lectura diferenciando el primer plano del fondo.

1.2.1.2. Operable Los componentes de la interfaz de usuario y la navegación deben ser operables, más en detalle, que la funcionalidad esté disponible también empleando teclados; que los usuarios con discapacidad dispongan de tiempo suficiente para leer y usar un contenido y que se proporcione soporte a los usuarios mientras navegan, para localizar contenidos y determinar dónde se encuentran.

1.2.1.3. Comprensible La información y el manejo de la interfaz de usuario deben ser comprensibles, más en detalle, que tengan apariencia y operabilidad predecibles; y permitan a los usuarios evitar errores o si se dan que les permitan corregirlos.

1.2.1.4. Robusto El contenido debe ser suficientemente robusto como para ser interpretado de forma fiable por una amplia variedad de aplicaciones de usuario, incluyendo las ayudas técnicas actuales y futuras a mediano plazo. Luego, estos 4 principios básicos, se descomponen en 12 pautas: 1.1, 1.2, …, 4.1 y las pautas se descomponen en 61 requisitos o criterios de conformidad 1.1.1, 1.1.2, …, 4.1.2. Además, estos 61 criterios de conformidad en WCAG 2.0 se agrupan en niveles mínimos (A, que deben cumplirse), extendidos (AA, que deberían cumplirse) y máximos (AAA, que podrían cumplirse) (World Wide 20

Capítulo 1: Comprendiendo las guías de accesibilidad al contenido en la web

Jorge Iván Pincay Ponce

Web Consortium (W3C), 2008)

1.2.2. Pautas Como se indicó en la sección precedente, WCAG 2.0 está dividido en cuatro principios distribuidos en 12 pautas de estructuración lógica de documentos, contenidos auto-explicables y que integran semántica adicional. Los cuatro principios son: ●● Perceptible: 1.1 Alternativas textuales, 1.2 Multimedia, 1.3 Adaptabilidad, 1.4 Distinguible. ●● Operable: 2.1 Teclado, 2.2 Tiempo suficiente, 2.3 Ataques, 2.4 Navegable. ●● Comprensible: 3.1 Legible, 3.2 Predecible, 3.3 Entrada de datos. ●● Robusto: 4.1 Compatible. Las 12 pautas, orientan a no basarse solo en características visuales como el color, tamaño o posición para transmitir información, sino a ir más allá, a hacer el contenido navegable y funcional mediante teclado, proporcionar alternativas textuales para el contenido no textual o estructurar y etiquetar el contenido de forma lógica, de manera que tenga sentido cuando se presente de forma simplificada, sin CSS por ejemplo. (Cool Z, 2010) En las siguientes subsecciones se establecen enlaces a más información sobre estas pautas (disponibles para la versión digital de este libro).

1.2.2.1. Pautas para la perceptibilidad − 1.1 Proporcione alternativas textuales para todo contenido no textual, de manera que pueda modificarse para ajustarse a las necesidades de las personas, como por ejemplo en una letra mayor, braille, voz, símbolos o un lenguaje más simple. − 1.2 Proporcione alternativas sincronizadas para contenidos multimedia sincronizados dependientes del tiempo. − 1.3 Cree contenidos que puedan presentarse de diversas maneras (como por ejemplo una composición más simple) sin perder la información ni su estructura. − 1.4 Haga más fácil para los usuarios ver y oír el contenido, incluyendo la separación entre primer plano y fondo.

1.2.2.2. Pautas para la operabilidad − 2.1 Haga que toda funcionalidad esté disponible a través del teclado. − 2.2 Proporcione a los usuarios con discapacidades el tiempo suficiente para leer y usar un contenido. − 2.3 No diseñe un contenido de manera que se sepa que puede causar ataques. − 2.4 Proporcione medios que sirvan de ayuda a los usuarios con discapacidades a la hora de navegar, localizar contenido y determinar dónde se encuentran.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

1.2.2.3. Pautas para la comprensibilidad − − −

3.1 Haga el contenido textual legible y comprensible. 3.2 Cree páginas web cuya apariencia y operabilidad sean predecibles. 3.3 Ayude a los usuarios a evitar y corregir errores.

1.2.2.4. Pautas para la robustez − 4.1 Maximice la compatibilidad con agentes de usuario actuales y futuros, incluyendo tecnologías asistivas.

1.2.3. Criterios Como se ha indicado hasta ahora, los 4 principios de WCAG 2.0 abordan 12 pautas y estos 61 criterios distribuidos en tres niveles de prioridad, de la siguiente manera: Tabla 1: Los 25 criterios de conformidad con el nivel A de WCAG 2.0 Nivel: A Prioridad: Debe cumplirse Número de Criterios: 25 1.1.1 Contenido no textual 1.2.1 Solo audio y solo vídeo (grabado) 1.2.2 Subtítulos (grabados) 1.2.3 Audiodescripción o Medio Alternativo (grabado) 1.3.1 Información y relaciones 1.3.2 Secuencia significativa 1.3.3 Características sensoriales 1.4.1 Uso del color 1.4.2 Control del audio 2.1.1 Teclado 2.1.2 Sin trampas para el foco del teclado 2.2.1 Tiempo ajustable 2.2.2 Poner en pausa, detener, ocultar 2.3.1 Umbral de tres destellos o menos 2.4.1 Evitar bloques 2.4.2 Titulado de páginas 2.4.3 Orden del foco 2.4.4 Propósito de los enlaces (en contexto) 3.1.1 Idioma de la página 3.2.1 Al recibir el foco 3.2.2 Al recibir entradas 3.3.1 Identificación de errores 3.3.2 Etiquetas o instrucciones 4.1.1 Procesamiento 4.1.2 Nombre, función, valor Fuente: Elaboración propia a partir de (World Wide Web Consortium (W3C), 2008)

Capítulo 1: Comprendiendo las guías de accesibilidad al contenido en la web

Jorge Iván Pincay Ponce

Tabla 2: Los 25 criterios de conformidad con el nivel AA de WCAG 2.0 Nivel: AA Prioridad: Debería cumplirse Número de Criterios: 13 1.2.4 Subtítulos (en directo) 1.2.5 Audiodescripción (grabado) 1.4.3 Contraste (mínimo) 1.4.4 Cambio de tamaño del texto 1.4.5 Imágenes de texto 2.4.5 Múltiples vías 2.4.6 Encabezados y etiquetas 2.4.7 Foco visible 3.1.2 Idioma de las partes 3.2.3 Navegación coherente 3.2.4 Identificación coherente 3.3.3 Sugerencias ante errores 3.3.4 Prevención de errores (legales, financieros, datos) Fuente: Elaboración propia a partir de (World Wide Web Consortium (W3C), 2008) Tabla 3: Los 25 criterios de conformidad con el nivel AA de WCAG 2.0 Nivel: AAA Prioridad: Podría cumplirse Número de Criterios: 23 1.2.6 Lengua de señas (grabado) 1.2.7 Audiodescripción ampliada (grabada) 1.2.8 Medio alternativo (grabado) 1.2.9 Solo audio (en directo) 1.4.6 Contraste (mejorado) 1.4.7 Sonido de fondo bajo o ausente 1.4.8 Presentación visual 1.4.9 Imágenes de texto (sin excepciones) 2.1.3 Teclado (sin excepciones) 2.2.3 Sin tiempo 2.2.4 Interrupciones 2.2.5 Re-autentificación 2.3.2 Tres destellos 2.4.8 Ubicación 2.4.9 Propósito de los enlaces (solo enlaces) 2.4.10 Encabezados de sección 3.1.3 Palabras inusuales 3.1.4 Abreviaturas 3.1.5 Nivel de lectura 3.1.6 Pronunciación 3.2.5 Cambios a petición 3.3.5 Ayuda 3.3.6 Prevención de errores (todos) Fuente: Elaboración propia a partir de (World Wide Web Consortium (W3C), 2008)

CAPÍTULO II

HERRAMIENTAS DE EVALUACIÓN AUTOMÁTICA DE LA ACCESIBILIDAD

"La accesibilidad nos permite abrir el potencial de todos".

2.1. Introducción Existen herramientas de evaluación que ayudan a realizar evaluaciones de accesibilidad, lo cual es importante y necesario de hacer desde las primeras etapas del inicio y/o rediseño de un sitio web (Addin, 2017). No obstante, ninguna herramienta en sí misma puede determinar si un sitio cumple o no las pautas de accesibilidad, por lo que tarde o temprano es necesaria la evaluación humana. Más allá de la mencionada realidad, el W3C actualiza periódicamente una lista de herramientas de evaluación automática de la accesibilidad, misma que actualmente contiene más de 125 herramientas con sus respectivos resúmenes y estadísticas de propiedades más importantes (Addin, 2017). En todo caso, la o las herramientas de pruebas de accesibilidad que se deben usar depende de las necesidades y el presupuesto de su sitio, entre muchos otros factores (Dyno Mapper, 2017) Las herramientas seleccionadas para las diversas pruebas en este libro son: ACHEKERS, CHECKERS de la EIII, CYNTHIASAYS, Nibbler y WebAIM. A continuación, se presenta una breve descripción de las mismas.

2.2. Herramientas seleccionadas 2.2.1. ACHEKERS El Inclusive Design Research Centre lanzó su programa de accesibilidad web AChecker el 19 de septiembre de 2008. Entre las características que hacen que este programa sea atractivo están el hecho de que es interactivo, internacional y personalizable, dependiendo de sus necesidades. AChecker permite a los usuarios crear sus propias directrices deseadas, así como escribir sus propias comprobaciones de accesibilidad. El programa está definido por el OAC (Open Accessibility Checks). Las directrices cubiertas por ACHEKERS son WCAG 1.0 y WCAG 2.0 del W3C, Section 508, Normas Federales de Contratación Estadounidenses, la regulación federal alemana Barrierefreie Informationstechnik-Verordnung (BITV) y la legislación italiana de accesibilidad STANCA ACT. El programa viene en inglés, alemán e italiano, y los formatos soportados incluyen CSS, HTML y XHTML. Es un comprobador en línea y un servicio alojado que comprueba automáticamente páginas web individuales, así como páginas protegidas con contraseña o restringidas. Una vez comprobados, los informes se generan con los resultados de la evaluación en formatos HTML, PDF, XML y EARL[1]. La herramienta es un servicio Web de licencia gratuita y de código abierto. La herramienta está disponible en: http://achecker.ca/checker/index.php.

Siglas en español de Lenguaje de Evaluación y Reporte. EARL es un proyecto del W3C para desarrolladores que deseen construir su propia herramienta de evaluación. 1

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 1: Logo de la herramienta ACHECKER

2.2.2. CHECKERS de la EIII Checkers es proyecto de la European Internet Inclusion Initiative, cofinanciado por el Séptimo Programa Marco de la Unión Europea. Checkers puede identificar barreras de accesibilidad en páginas web, sitios web y documentos PDF (EIII, 2017). La herramienta está disponible en: http:// achecker.ca/checker/index.php La directriz cubierta por Checkers es la WCAG 2.0 y los resultados se basan en pruebas automáticas de archivos (X) HTML, que cubren un subconjunto de WCAG 2.0. Específicamente CHECKERS cubre 44 pruebas, mismas que están detalladas en la página http://checkers.eiii.eu/ en/tests/ de su sitio web.

Imagen 2: Logo de la EIII

2.2.3. CYNTHIASAYS Cynthia Says es un programa ofrecido a través de HiSoftware que ayuda a los usuarios a identificar los errores de cumplimiento de accesibilidad web en su sitio, página por página. Una muy buena característica de Cynthia Says es que proporciona comentarios en un formato que es fácil de entender incluso para los menos expertos en tecnología (Dyno Mapper, 2017). Por lo que puede decirse que el producto educa a los usuarios en los conceptos detrás de la accesibilidad del sitio web. Cynthia Says es esfuerzo conjunto entre Cryptzone, el International Center for Disability Resources on the Internet (ICDRI), la Internet Society Disability and Special Needs Chapter (CRYPTZONE, 2017) Las directrices cubiertas por Cynthia Says son WCAG 2.0 y Section 508 de the Rehabilitation Act. Los formatos soportados incluyen CSS, HTML e Imágenes. Cynthia Says es un comprobador en línea, de software libre y está disponible en: http://www.cynthiasays.com/

Imagen 3: Logo de la herramienta Cynthia Says

Capitulo II: Herramientas de evaluación automática de la accesibilidad

Jorge Iván Pincay Ponce

2.2.4. Nibbler Nibbler es una herramienta multifuncional en la que basta introducir la dirección de cualquier sitio web y obtener un informe valorado de 0 a 10 en áreas claves entre las que están la accesibilidad, SEO, medios sociales y tecnología (NIBBLER, 2017). Nibbler es un programa bot, capaz de revisar varias páginas a partir de la página principal del sitio que se le proporcione y es gratuito en tanto esté limitado a tres informes. Respecto a la accesibilidad, esta herramienta en línea utiliza seis pruebas: Móvil, calidad de código, enlaces internos, encabezados, títulos de páginas y el formato de las URL. Finalmente es de destacar que se trata de un software libre disponible en: http://nibbler.silktide.com/

Imagen 4: Logo de la herramienta Nibbler

2.2.5. WebAIM WebAIM es una mantenida principalmente por la Organización WebAIM, con sede en la Universidad Estatal de Utah. La organización WebAIM ha proporcionado soluciones de accesibilidad web desde 1999, especializándose en el desarrollo y la adaptación de contenido web para la accesibilidad y su mantenimiento en el futuro (WebAIM, 2017) Las directrices cubiertas por WebAIM son WCAG 2.0 y Section 508 de the Rehabilitation Act. En la dirección http://webaim.org/standards/wcag/checklist está disponible lo que se evalúa de WCAG 2.0 y en http://webaim.org/standards/508/checklist lo que se evalúa de Section 508. WebAIM tiene varios evaluadores, siendo los principales: • Color Contrast Checker, disponible en: http://webaim.org/resources/contrastchecker • WAVE Web Accessibility Evaluation Tool, disponible en: http://wave.webaim.org/

Imagen 5: Logo de la herramienta WebAIM

2.3. Ejemplo de Test con CHECKERS A modo de ejemplo nos centramos en el lenguaje de partes de la página web, es decir el Criterio AA “3.1.2. Lenguaje de Partes”, Pauta “3.1. Legible” y Principio “3. Comprensible” de WCAG 2.0. El criterio indica que el lenguaje humano de frases o partes de la página pueda determinarse programáticamente, considerando nombres propios, términos técnicos y palabras 29

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

de un idioma indeterminado (EIII, 2017) Esta prueba, según (EIII, 2017), verifica el valor del atributo xml:lang y especifica que si el desarrollador usa xml:lang para un elemento, necesitará añadir atributos de lang con el mismo valor también. El valor del lang y xml:lang son compuestos de una sucesión de una o más "sub etiquetas" divididos por "-", cada uno redefine un rango de idiomas, por ejemplo: “en” para el inglés, “en-US” para el inglés usado en Estados Unidos y “fr-CA” para el francés usado en Canadá. Entre los posibles resultados de este test están: − Error: Que no se haya indicado el lenguaje, lo que se identifica si es que xml:lang es especificado para el elemento pero no se ha encontrado el atributo lang. − Error: Que los atributos lang sean contradictorios al elemento xml:lan g. − Correcto: El elemento xml:lang contiene los mismos valores de los atributos lang.

CAPÍTULO III

EVALUACIÓN DEL SITIO WEB DE EJEMPLO

"El poder de la Web está en su universalidad. El acceso de todas las personas independientemente de la discapacidad es un aspecto esencial" Tim Berners-Lee

3.1. Introducción “El buen diseño capacita y el mal diseño discapacita” fue una frase acuñada durante la Declaración de Estocolmo del año 2004: EIDD[1]… A modo de ejemplo, en este capítulo de evaluación previo al rediseño se ha escogido el sitio web de Viveros de la Universidad de Alcalá, un sitio ficticio de información sobre un vivero. El sitio sufrió algunos cambios de readecuación de interfaz, empleo de etiquetas HTML semánticas, implementación de funcionalidades con JavaScript y valoración del contraste de imágenes. Es de destacar que se ha procurado no explicar repetidamente los fallos de accesibilidad detectados en el sitio original: www.vivero-original.oficentro.ecuador.com. Lo que se ha hecho es exponer, dentro de lo posible, un solo error por cada vez que se detectó en el sitio y por ende en el Capítulo IV se explicará una sola vez cada cambio reflejado en el nuevo sitio: www.vivero.oficentro-ecuador.com.

3.2. Página web 1. Página principal de vivero (http://vivero-original.oficentro-ecuador.com/index.html) La que sigue es la página principal del sitio web de Viveros, en ella se muestra información de la empresa, datos de horarios de atención y de contactos. Entre sus principales problemas accesibilidad están la falta de: • Textos alternativos en imágenes, • Títulos descriptivos en elementos iframe, • Títulos descriptivos en enlaces, • Leyendas en iframes, • Definición de lenguaje principal, • Errores de contrastes de colores.

EIDD son las siglas de European Institute for Design and Disability, que es una red europea fundada en Dublin – Ireland en 1993. Esta red tiene como misión mejorar la calidad de vida a través del diseño para todos para hacer una sociedad mejor para todos. 1

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 6: Vista parcial de la página principal de la aplicación Vivero, versión original disponible en http://vivero-original.oficentro-ecuador.com/index.html

Imagen 7: Vista parcial de la página principal de la aplicación Vivero, versión modificada disponible en http://vivero.oficentro-ecuador.com/index.html

Capítulo 111: Evaluación del sitio web de ejemplo

Jorge Iván Pincay Ponce

Imagen 8: Resumen de fallos de accesibilidad presentados en la página principal del sitio original de acuerdo con la herramienta CHECKERS de la EIII

3.3. Página web 2: Productos (http://vivero-original.oficentro-ecuador.com/paginas/ productos.html) La que sigue es la página de productos del sitio web original de Viveros, en ella se muestra información de los productos, imágenes, enlaces descriptivos a Wikipedia, datos de horarios de atención y de contactos. Entre sus principales problemas accesibilidad están la falta de: • Textos alternativos en imágenes, • Títulos descriptivos en elementos iframe, • Títulos descriptivos en enlaces, • Leyendas en iframes, • Definición de lenguaje principal, • Diseño responsivo, • Focus visible, • Resize de elementos como imágenes, • Errores de contrastes de colores. 35

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 9: Vista parcial de la página Productos de la aplicación Vivero, versión original disponible en http://vivero-original.oficentro-ecuador.com/paginas/productos.html

Imagen 10: Vista parcial de la página Productos de la aplicación Vivero, versión modificada disponible en http:// vivero.oficentro-ecuador.com/paginas/productos/productos.html

Capítulo 111: Evaluación del sitio web de ejemplo

Jorge Iván Pincay Ponce

Imagen 11: Resumen de fallos de accesibilidad presentados en la página Productos del sitio original de acuerdo con la herramienta CYNTHIASAYS.

3.4. Página web 3: ¿Dónde estamos? (http://vivero-original.oficentro-ecuador.com/paginas/ localizacion.html) La que sigue es la página “¿Dónde estamos?” del sitio web original de Viveros, en ella se muestra información de dirección y horarios de atención y mapas (Google Maps). Entre sus principales problemas accesibilidad están la falta de: • Textos alternativos en imágenes, • Títulos descriptivos en elementos iframe, • Títulos descriptivos en enlaces, • Leyendas en iframes, • Definición de lenguaje principal, • Diseño responsivo, • Focus visible, • Resize de elementos como imágenes, • Errores de validación HTML, 37

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

•

Errores de contrastes de colores.

Imagen 12: Vista parcial de la Página ¿Dónde estamos? de la aplicación Vivero, versión original disponible en http:// vivero-original.oficentro-ecuador.com/paginas/localizacion.html

Capítulo 111: Evaluación del sitio web de ejemplo

Jorge Iván Pincay Ponce

Imagen 13: Vista parcial de la página ¿Dónde estamos? de la aplicación Vivero, versión modificada disponible en http://vivero.oficentro-ecuador.com/paginas/localizacion/donde_estamos.html

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 14: Resumen de fallos de accesibilidad presentados en la página ¿Dónde estamos? Del sitio original de acuerdo con la herramienta CYNTHIASAYS

2.5. Página web 4: Contacto (http://vivero-original.oficentroecuador.com/paginas/contacto.html) La que sigue es la página Contacto del sitio web original de Viveros, en ella se muestra información de dirección, horarios de atención, un formulario de contactos (que evidencia fallos de accesibilidad) y mapas (Google Maps). Entre sus principales problemas accesibilidad están la falta de: • Textos alternativos en imágenes, • Títulos descriptivos en elementos iframe, • Títulos descriptivos en enlaces, • Leyendas en iframes, • Definición de lenguaje principal, • Diseño responsivo, • Focus visible, • Resize de elementos como imágenes, • Errores de validación HTML, • Identificación del control que tiene el focus, 40

Capítulo 111: Evaluación del sitio web de ejemplo

• •

Jorge Iván Pincay Ponce

Identificadores html duplicados, Errores de contrastes de colores.

Imagen 15: Vista parcial de la página Contacto de la aplicación Vivero, versión original disponible en http://viverooriginal.oficentro-ecuador.com/paginas/contacto.html

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 16: Vista parcial de la pรกgina Contacto de la aplicaciรณn Vivero, versiรณn modificada disponible en http://vivero.oficentro-ecuador.com/paginas/contacto/contacto.html

Imagen 17: Resumen de fallos de accesibilidad presentados en la pรกgina Contacto del sitio original de acuerdo con la herramienta CYNTHIASAYS.

Como se puede apreciar existen diversos fallos en diferentes niveles de conformidad, dando un total de 11 fallos en la pรกgina Contacto del sitio original.

Capítulo 111: Evaluación del sitio web de ejemplo

Jorge Iván Pincay Ponce

Imagen 18: Resumen de fallos de accesibilidad presentados para todo el sitio original de Viveros, de acuerdo con la herramienta NIBBLER.

CAPÍTULO IV:

REDISEÑO DEL SITIO ORIGINAL, REEVALUACIÓN

“Tenemos que hacer que cada cosa sea accesible a todas las personas con una discapacidad”. Stevie Wonder

4.1. Introducción

En base a barreras identificadas en el portal web actual, en este capítulo se analizan y aplican modificaciones a nivel de código fuente para “derribar” tales barreras, identificadas con ACHEKERS, CHECKERS, CYNTHIASAYS, NIBBLER y WebAIM; obteniendo un portal web rediseñado (ver imagen de la izquierda). Se ha procurado conservar la apariencia general del sitio y desterrando mitos que existen como por ejemplo que la accesibilidad web es cara y supone un coste extra en el desarrollo de un sitio web, sin que los beneficios sean importantes (Luján Mora, 2017)

4.2. Modificaciones realizadas para cumplir WCAG 2.0 nivel AA En general se hicieron adecuaciones en casi todo el código del sitio web, ahora, en todas las páginas del sitio se usa HTML semántico dando apoyo a WAI-ARIA y varios criterios de conformidad de WCAG 2.0. También eliminaron los diseños tabulares, ahora, en ninguna de las páginas del sitio se usan tablas para su diseño, pues las tablas deben ser usadas solo para contener datos tabulares. Un sitio web bien construida debe utilizar elementos div y CSS para crear el diseño deseado.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 19: Un reporte de la herramienta NIBBLER sobre la semántica HTML y CSS del sitio web reconstruido.

4.2.1. Modificaciones en el archivo index.html, http:// vivero.oficentro-ecuador.com/index.html Tabla 4: Modificaciones realizadas en la página principal, parte 1 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: El DOCTYPE empleado no soporta <!DOCTYPE html> HTML5 y muchas funcionalidades de WAI-ARIA. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/ xhtml1/DTD/xhtml1-transitional.dtd">

COMENTARIOS Todas las páginas del sitio están reconstruidas empleando e ti q u e t a s semánticas. En concordancia con WAI ARIA y HTML5.

Problema: Algunas imágenes no tenían información <img src="imagenes/Cabecera.jpg" Se ha especificado textual asociada. alt="Centro de jardinería y vivero de texto alternativo a

plantas, revise horario de primavera en la cada imagen, para <img src=”imagenes/Cabecera.jpg” alt=”” página: ¿Dónde estamos?" width="60%" cumplir el criterio width=”100%” height=”100%” /> height="60%"/> de conformidad 1.1.1. (A). Problema: En algunos casos los títulos de las páginas <h1>¿Qué es Vivero U.A.H.?</title> diferían mucho del h1, que debe ser el encabezado ... principal de cada página.

<title>Vivero UAH</title>

<h1>¿Qué es Vivero U.A.H.?</h1>

Se ha escrito un título de la página relacionado con el h1 de la misma. Esto permite cumplir el criterio 2.4.6. de encabezados y etiquetas (AA).

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: En algunos casos no había secuencias entre <h1>¿Qué es Vivero U.A.H.?</h1> los encabezados, por lo que algunas páginas partían del h2 sin tener h1…

<h2>Desde sus inicios</h2> <h3>Información de Contacto</h3>

COMENTARIOS Se ha escrito ordenadamente los encabezados en la página. Esto permite cumplir el criterio 2.4.6. de encabezados y etiquetas (AA).

Tabla 5: Modificaciones realizadas en la página principal, parte 2 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: Algunos h1, h2… h6 aparecían h1{ marginados desde el borde izquierdo de la página. margin-left: 5%; } … h2{ margin-left: 10%; }

Problema: No se había marcado <body dir=”LTR”> la dirección del texto, lo cual es importante para la internacionalización, es decir, dir va de la mano con Lang. <body>

Problema: En algunos casos era posible que se <li> <a href="index.html" title = "Ir al inicio" presentacen problemas de contraste, pues se class="n" style="color: red; backgroundespecificaba color de fuentes u otros, pero no de fondo. color:white">Inicio</a></li> Había que asegurarse de que los usuarios puedan

leer el texto que se presenta sobre un fondo.

<li color="#564647"><a href="paginas/productos. html">Productos</a></li>

COMENTARIOS Se agregó c ó d i g o CSS para presentar los encabezados en el mismo margen que el resto de la página. Esto permite cumplir el c r i t e r i o 3.2.3. de Navegación coherente (AA). Se e s p e c i fi c ó dirección del texto como de izquierda a derecha, si se quisiera de derecha a izquierda sería RTL. Esto permite cumplir el criterio 1.3.1. de Información y Relación (A).

Se e s p e c i fi c ó color de fondo (en class=”n”) y en este caso color de texto también, conforme al criterio de conformidad 1.4.3. (AA).

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Tabla 6: Modificaciones realizadas en la página principal, parte 3 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: No se había definido el propósito de <li> <a href="index.html" title = "Ir muchos de los enlaces del sitio. al inicio" class="n" style="color: red;">Inicio</a></li> <li color="#564647"><a href="paginas/productos. <li> <a href="paginas/productos/ html">Productos</a></li> index.html" title = "Ir a productos" <li><a href="paginas/localizacion.html">Dónde class="n">Productos</a></li> estamos</a></li> <li> <a href="paginas/localizacion/ <li><a href="paginas/contacto.html">Contacto</ index.html" title = "Ir al localización" a></li> class="n">Dónde estamos?</a></li>

COMENTARIOS Se ha descrito el propósito de los enlaces, para cumplir los criterios de conformidad 2.4.4. (A) y 4.1.2. (A).

Problema: No se definía el lenguaje de las páginas y <html xmlns=http://www.w3.org/1999/ Se ha especificado las tecnologías de asistencia podrían fallar a leer las xhtml lang=”es”> el idioma de cada páginas web. página en el sitio e

incluso en partes de las páginas, para cumplir el criterio de conformidad 3.1.1. (A).

Problema: En varios casos había contrastes mínimos body{margin:0; padding:0; font-size:13px; Se ha establecido en los colores. font-family:Georgia, "Times New Roman", mediante CSS el

Times, serif; color:black; background- color de fondo body{margin:0; padding:0; font-size:13px; font- color:white;} blanco y letra family:Georgia, "Times New Roman", Times, serif; negra, de acuerdo color:#605B5B; background-color:#FFFFFF;} con el criterio de conformidad 1.4.3. (AA). Problema: En varios casos había información redundante, pero de contenido inaccesible en la web.

<div id="leyenda1"> <h2>Localízanos</h2> <iframe title=”observa el mapa” width=”350” height=”250” frameborder=”0” scrolling=”si” marginheight=”0” marginwidth=”0” src=”https:// www.google.com/maps/...”></iframe> </div>

Se eliminó esta sección y el mapa ahora se muestra solo en la página “¿Dónde estamos?”

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

Tabla 7: Modificaciones realizadas en la página principal, parte 4 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: En varios casos había información redundante, pero de contenido inaccesible en la web.

Se eliminó esta sección pues la página no tiene mucho contenido y la redundancia de enlaces podría provocar fallos de inconsistencias de destino de enlaces, además estos enlaces ya estaban en el menú principal.

<div id="leyenda1"> <h2>Vivero UAH</h2> <ul> <li><a href="index.html">Inicio</li> <li><a ref="paginas/productos.html">Productos</ li> <li><a href="paginas/localizacion.html">Dónde estamos</li> <li><a href="paginas/contacto.html">Contacto </a></li> </ul> </div> Problema: Existían errores de sintaxis que generaban incidencias en el procesamiento de la página por errores HTML. Por ejemplo, en la segunda línea de este ejemplo se abre una etiqueta <a> y no se ha cerrado otra abierta en la primera línea.

<li><a href="../index.html">Inicio</li> <li><a href="productos.html">Productos</li>

COMENTARIOS

<li><a href="../index.html">Inicio</a></li> <li><a href="productos.html">Productos</ a></li>

Se corrigió el error reportado por los validadores de HTML. Esto permite cumplir el criterio 4.1.1. (A) de procesamiento.

Problema: En varios casos se usaba código obsoleto, que <hr width = "90%" color="#008F54"/> Los validadores de HTML por ejemplo no es compatible con el navegador Firefox. reportaron múltiples

errores, como por ejemplo este “;” de más; que se lo pondría en CSS pero no donde estaba. Además, la etiqueta <hr> no estaba cerrada. Esto permite cumplir el criterio 4.1.1 (A) de procesamiento.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Tabla 8: Modificaciones realizadas en la página principal, parte 5 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: En algunos casos se usaba código <hr class=”linea”/> obsoleto, por lo que algunos atributos de HTML fueron agregados a instrucciones CSS. Línea.css queda así:

Los validadores de HTML reportaron múltiples errores, siguiendo con la línea anterior se re e m p l a zó los atributos width y color, porque ser obsoletos y en su lugar se instanció un CSS que contenía esas configuraciones. Esto permite cumplir el criterio 4.1.1 de procesamiento (A).

Problema: En varios casos se empleaban códigos La línea se sustituyó por un div o elementos que generaban incompatibilidad con <div class="linea"/> navegadores como Firefox.

Firefox no podía ejecutar el elemento <hr> del mismo modo que Chrome, Explorer y Edge; pero, si procesa este CSS. Esto permite cumplir el criterio 4.1.1 de procesamiento (A).

Y el CSS de la clase es:

Tabla 9: Modificaciones realizadas en la página principal, parte 6 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: Había muchas etiquetas Div extraviadas, <div class=”wrapper col3”> como esta. <div id=”featured_slide”> <img src="../imagenes/Carrusel4.jpg" <div class=”wrapper col3”> alt="" /> <div id=”featured_slide”> </div> <img src="../imagenes/Carrusel4.jpg" alt="" /> </div> </div> </div> </div>

COMENTARIOS Los validadores de HTML reportaron el error descrito, el cual se corrigió. Este fragmento de código tiene otros errores, pero, en este ítem se analiza uno y se lo corrige, esto permite cumplir el criterio 4.1.1 de procesamiento (A).

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: El nombre del iframe no está definido, <iframe class="margen" width="45%" Se ha descrito además le faltaba título asociado. height="70%" title="Localízanos en el el propósito del

mapa" aria-label="Localízanos en el <iframe width="200" height="250" mapa" src="https://www.google.com/ frameborder="0" s c r o l l i n g = " n o " embed?..."></iframe> marginheight="0" marginwidth="0" src="https:// www.google.com/maps/......." />

iframe, para cumplir los criterios de conformidad 2.4.4. de propósitos de los links (A) y 4.1.2 de nombre, rol y valor (A).

Problema: Varias secciones div estaban marcadas  como headers. <header role="banner">

Se reemplazó el <div> original que contenía el encabezado del sitio, por una sección header que le dio más sentido s e m á n ti c o . En concordancia con ARIA4, ARIA12 y los criterios 1.3.1 (A), 2.4.1 (A) y 4.1.2 (A).

Tabla 10: Modificaciones realizadas en la página principal, parte 7 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: En todas las páginas, no había formas … de evitar bloqueos yendo desde las páginas del <a href="#" rel="home"> sitio a la página principal del mismo. Se ha aplicado a cada página del sitio el correctivo indicado en los comentarios.

<p><strong>Información de Contacto</ strong></p> <p>Carretera de Barcelona- Autovía A2 Km. 16,500 sentido Madrid. San Fernando de Henares, Madrid, 28830.</p> <p>tel: +34 91 555 55 55.</p> <p class="last">Carretera de Barcelona- Autovía <p>fax: +34 91 555 55 55.</p> A2 Km. 16,500 sentido Madrid<br /> San Fernando de Hernares, Madrid, 2883o<br /> tel: +34 91 555 55 55<br /> fax: +34 91 555 55 55<br /> Problema: En algunos casos se estaba diseñando con muchos saltos de líneas en un párrafo y además los encabezados se usaban con fines decorativos. En general, había problemas de manejo de encabezados y etiquetas.

COMENTARIOS Se ubicó cómo p r i m e r o s hipervínculos en cada página, enlaces a la página principal, para que las personas tengan acceso más directo al contenido principal del sitio web, ante algún bloqueo. Esto permite cumplir el criterio 2.4.1 que trata sobre de evitar bloqueos (A). Se e m p l e a ro n e l e m e n t o s adecuados para el diseño html. Esto permite cumplir el Criterio 2.4.6 de Encabezados y etiquetas (AA) y el criterio 1.3.1 de Información y relaciones (A).

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Tabla 11: Modificaciones realizadas en la página principal, parte 8 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: Los tamaños de las fuentes eran fijos y el W3C recomienda como buenas prácticas de programación web, que las páginas estén basadas en diseños escalables.

COMENTARIOS Se usará en todo el sitio la medida EM. En el ejemplo se presenta el código CSS para todo el texto que se usará en la sección body de cada página. Esto permite cumplir el Criterio 1.4.4 de tamaños “automático” de textos (AA).

No se ha incluido código por qué el problema era en todo el sitio.

Tabla 12: Modificaciones realizadas en la página principal, parte 9 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: La lista no incorporaba elementos <ul id="nav" class="example" semánticos y por tanto no daba soporte para role="toolbar" tabindex="2" ariala interacción por teclado. activedescendant="boton1"> <li aria-expanded="false" id="boton1" <ul> role="button">... <ul> <li aria-expanded="false" id="boton2" <li> role="button">... <div align="center"><a href="../index.html" <li aria-expanded="false" id="boton3" class="Estilo1">Inicio</a></div> role="button">... </li> <li aria-expanded="false" id="boton4" <li color="#564647"><a href="productos. role="button">... html">Productos</a></li> </ul> <li><a href="localizacion.html">Dónde estamos</a></li> <li><a href="contacto.html">Contacto</a></ li> </ul>

COMENTARIOS Para cumplir el criterio 2.1.1 (A), se ha añadido tabindex=”2” para que se pueda acceder a la barra de herramientas por teclado. Se ha incluido el atributo aria-activedescendant para que inicialmente el foco se sitúe en el botón “boton1”. Para mejorar la semántica: − Se ha añadido el role “toolbar” para indicar que la lista funciona como una barra de herramientas. − Se ha añadido el role “button” a todas las opciones de la barra.

4.2.2. Modificaciones en el archivo productos.html, http:// vivero.oficentro-ecuador.com/paginas/productos/productos. html Todos los cambios realizados en este archivo, para el cumplimiento del nivel AA de WCAG 2.0, son del mismo tipo que los realizados en los archivos: Index.html, donde_estamos.html y Contacto.html. Por tal razón, no se los describe en esta sección. En general, para el análisis del cumplimiento del nivel AA de WCAG 2.0, en este documento 54

Capítulo IV: Rediseño del sitio original, reevaluación

Jorge Iván Pincay Ponce

se detallan los cambios en los archivos index.html y contacto.html.

4.2.3. Modificaciones en el archivo donde_estamos. html, http://vivero.oficentro-ecuador.com/paginas/localizacion/ donde_estamos.html Todos los cambios realizados en este archivo, para el cumplimiento del nivel AA de WCAG 2.0, son del mismo tipo que los realizados en los archivos: Index.html, producto.html y Contacto. html. Por tal razón, no se los describe en esta sección. En general, para el análisis del cumplimiento del nivel AA de WCAG 2.0, en este documento se detallan los cambios en los archivos index.html y contacto.html. 4.2.4. Modificaciones en el archivo contacto.html, http://vivero.oficentro-ecuador.com/paginas/ contacto/contacto.html Tabla 13: Modificaciones realizadas en la página Contacto, parte 1 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: El DOCTYPE empleado <!DOCTYPE html> no soporta HTML5 y muchas funcionalidades de WAI-ARIA. <!DOCTYPE html PUBLIC "-//W3C// DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/ xhtml1-transitional.dtd">

COMENTARIOS Todas las páginas del sitio están reconstruidas empleando etiquetas s e m á n ti c a s . En concordancia con ARIA y HTML5.

Tabla 14: Modificaciones realizadas en la página Contacto, parte 2 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: El objeto fieldset no tenía una leyenda que interactúe con las tecnologías de asistencia y que ayude a la comprensión de usuarios con alguna discapacidad.

<fieldset style=”background-color:white”> <legend>Estimado <cite>Usuario</cite> déjenos su mensaje:</legend> <p><label for="nombre">Nombre *</ label><br/> ...

Se proporcionó una etiqueta (legend) para el Frame (formulario de contacto), así los usuarios pueden determinar de qué es o contiene el frame y entrar a explorar en detalle si desean. Esto de acuerdo con el criterio de conformidad 2.4.1 (A) y 4.1.2. (A).

Problema: El archivo aviso_legal.php < i n p u t re q u i re d t y p e = " c h e c k b ox " no existía. name="condiciones" value="condiciones" /> He leído y acepto las Condiciones Generales</a> <input required type="checkbox" n a m e = " c o n d i c i o n e s " ... value="condiciones" /> He leído y acepto las <a href ="aviso_legal. php">Condiciones Generales</a>

Se eliminó este enlace a un destino inexistente. Esto de acuerdo con el criterio de conformidad 2.4.9. de propósito del link (AAA) y 4.1.1. de procesamiento (A).

<fieldset> <p><label for="nombre">Nombre *</ label><br/> ...

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: No se usan técnicas para Nombre: *<br/> Se agregó un placehoder prevenir errores de ingreso de datos. <input required size=”30px” type=”text” (HTML5) para ofrecer un id=”name” name=”name” value=”” mensaje que prevenga Nombre: *<br/> placeholder=”Jorge Pincay”/> errores de ingreso de <input required size=”30px” </p> datos. Esto de acuerdo type=”text” id=”name” name=”name” con el criterio de value=”” /> conformidad 3.3.3 de </p> prevención de errores (AA). Tabla 15: Modificaciones realizadas en la página Contacto, parte 3 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: El contraste de colores predefinido de los placeholder es mínimo, por lo que urgía cambiarlo. No había un trato “especial” para los placeholder, se estaba usando “value”.

COMENTARIOS Los colores por defecto del placeholder no ofrecen suficiente c o n t ra s t e y se contraponen al criterio 1.4.3 Contraste mínimo (AA). Por tanto, se han modificado los estilos de los placeholder para hacerlos accesibles en términos de contraste tanto de Chrome, Firefox, Explorer, Safari.

Problema: Se usaban tamaños input id="nombre" placeholder="JORGE IVAN" estáticos para muchos controles, en required aria-required="true" width="38%" lugar de tamaños relativos. type="text" onfocus="toggleFocus(this)" onblur="toggleBlur(this)"/> Nombre: *<br/> <input required size=”30px” type=”text” id=”name” name=”name” value=”” placeholder=”Jorge Pincay”/> </p>

Se cambió a medidas relativas el placehoder para mantener la presentación visual, conforme al criterio 1.4.8. de mantener presentación visual (AAA).

Problema: No se proporcionaba información acerca de la ubicación del usuario dentro de un conjunto de páginas web.

Mediante CSS se proporcionó información visual acerca de la ubicación del usuario dentro del sitio, conforme al criterio 2.4.7. de focus visible (AA).

Tabla 16: Modificaciones realizadas en la página Contacto, parte 4

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: No resultaba evidente para las tecnologías de asistencia que un control input o textarea tuviese el enfoque.

input id=”nombre” placeholder=”JORGE IVAN” required aria-required=”true” width=”38%” type=”text” onfocus=”toggleFocus(this)” onblur=”toggleBlur(this)”/>

Se requería que cualquier interfaz de usuario operable por teclado, tenga una forma de operar en la cual el indicador del foco del teclado resultara visible, entonces se implementó una solución por medio de código JavaScript. Esto conforme al criterio 2.1.1 (A), 2.1.2 (A) y 2.1.3. (AAA) de teclado accesible.

input id="nombre" p l a c e h o l d e r = " J O RG E I VA N " required aria-required="true" width="38%" type="text" o n fo c u s = " t o g g l e F o c u s ( t h i s ) " onblur="toggleBlur(this)"/>

Problema: No se etiquetaban algunos <p> controles en un formulario. <label for="mensaje">Mensaje *</label> <br/>

<p> Mensaje: <br/> <textarea required size=”40px” name=”message” rows="3" cols="40"></textarea> </p>

Se ha vinculado la frase “Mensaje*”, con la caja <textarea de texto en la que el placeholder="Ahora describiré el asunto de mi usuario debe escribir mensaje" el Mensaje. Conforme required aria-required=”true” al criterio 2.4.6. de width=”42%” type=”text” encabezados y etiquetas id=”mensaje” (AA) y 3.3.2. de etiquetas name=”nmensaje” rows=”3” e instrucciones (AA). onfocus=”toggleFocus(this)” onblur=”toggleBlur(this)” title=”Su mensaje”></textarea> </p>

4.3. Modificaciones realizadas para cumplir WAI-ARIA 1.0 4.3.1. Modificaciones en el archivo index.html, http:// vivero.oficentro-ecuador.com/index.html Tabla 17: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 1 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS Todas las páginas del sitio están reconstruidas empleando etiquetas semánticas. En concordancia con ARIA y HTML5.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Problema: Esta y muchas imágenes no “podían” recibir focus y por ende no soportaban la especificación de WAI-ARIA para tener un sitio comprensible respecto al focus en los elementos de la página.

<img src="imagenes/Cabecera. jpg" alt="Centro.." width="60%" height="60%" class="margen" aria-expanded="false" tabindex="0" onclick="a()" <p align="left"><img src="imagenes/Cabecera. onkeypress="a()"/> jpg" alt="" width="100%" height="100%"/></p>

Todas las páginas del sitio están reconstruidas para que un elemento como esta imagen que de forma predeterminada no recibe el foco, pueda recibirlo y de paso pueda ser accedido mediante el tabulador; el orden de tabulación vendrá definido por su posición en el documento. En concordancia con ARIA.

Problema: Se carecía de roles que vinculen  coherentemente la información y sus relaciones. <header role=”banner”> <img src="imagenes/Cabecera. <div class=”wrapper col1”> jpg" alt="Centro de jardinería <div id=”header”> y vivero de plantas, revise <p align=”left”> horario de primavera en la <img src=”imagenes/Cabecera. página: ¿Dónde estamos?" jpg” alt=”” width=”100%” height=”100%” /> width="60%" height="60%" </p> class="margen"/> </header> </div> </div>

Se reemplazó el <div> original que contenía el encabezado del sitio, por una sección header que le dio más sentido semántico. En concordancia con ARIA4, ARIA12 y los criterios 1.3.1 (A), 2.4.1 (A) y 4.1.2 de Nombre, función y valor (A).

Tabla 18: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 2 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: En algunos casos se carecía de roles <ul id=”nav” class=”example” que vinculen coherentemente la información y role=”toolbar”> sus relaciones. <li role="button"> <a href="index.html" title = "Ir al <ul> inicio" class="n" style="color: <li><a href="index.html">Inicio</li> red;">Inicio</a></li> …

COMENTARIOS Para mejorar la semántica se ha añadido el role “toolbar” para indicar que la lista funciona como una barra de herramientas (<ul>). Esto da soporte los criterios de conformidad 1.3.1 Info and Relationships (A) y 2.4.1 Bypass Blocks (A) y 4.1.2 de Nombre, función y valor (A). En general también a ARIA4 y a HTML5.

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

<section> <article> <header> <div class=”wrapper col3”> <div class=”wrapper col3”> <img src=”imagenes/gifplanta. <div id=”featured_slide”> gif” alt=””/> </div> <img src=”imagenes/gifplanta.gif” alt=”” /> </header> <p id="inicio"><strong>¿Qué </div> es Vivero?</ </div> strong><br/><br/>Viveros …</ <div id="texto_inferior"> p> <p>Viveros es una empresa familiar creada en </article> 1889, disponemos de 15.000m2 de exposición </section> en nuestro centro de jardinería de Madrid. Contamos con una sólida y dilatada experiencia en este sector, lo que nos permite poner a disposición de nuestros clientes un amplio surtido de especies vegetales.</p> </div> </div>

Problema: La información estaba bien organizada, pero sin sentido semántico para las tecnologías de asistencia, pues carece de roles que vinculen coherentemente la información y sus relaciones.

COMENTARIOS Se modificó este fragmento de código para diseñar una sección ARTICLE dentro otra SECTION y proporcionarle sentido semántico al sitio. Esto da soporte los criterios de conformidad 1.3.1 Info and Relationships (A), 2.4.1 Bypass Blocks (A) y 4.1.2 de Nombre, función y valor (A). En general también a ARIA4 y HTML5.

Tabla 19: Modificaciones realizadas para cumplir WAI ARIA en la página Principal, parte 3 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: La lista no incorporaba elementos <ul id="nav" class="example" semánticos y no da soporte para interactuar por r o l e = " t o o l b a r " teclado. tabindex="2" ariaactivedescendant="boton1"> <ul> <li aria-expanded="false" <ul> id="boton1" role="button">... <li> <li aria-expanded="false" <div align="center"><a href="../index.html" id="boton2" role="button">... class="Estilo1">Inicio</a></div> <li aria-expanded="false" </li> id="boton3" role="button">... <li color="#564647"><a href="productos. <li aria-expanded="false" html">Productos</a></li> id="boton4" role="button">... <li><a href="localizacion.html">Dónde estamos</ </ul> a></li> <li><a href="contacto.html">Contacto</a></li> </ul>

COMENTARIOS Para mejorar la semántica se ha añadido el rol “toolbar” para indicar que la lista funciona como una barra de herramientas. También se ha añadido el rol “button” a las opciones de la barra; esto para cumplir el criterio 2.1.1 (A) y se ha añadido tabindex=”2” para que se pueda acceder a la barra de herramientas por teclado. También se ha incluido el atributo aria-activedescendant para que inicialmente el foco se sitúe en el botón “boton1”.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

4.3.2. Modificaciones en el archivo productos.html, http://vivero.oficentro-ecuador.com/paginas/productos/ productos.html Tabla 20: Modificaciones realizadas para cumplir WAI ARIA en la página Productos, parte 1 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: No se proporcionaba etiqueta <div id="datos" aria-label="Datos útiles descriptiva al div (que no soporta el de contacto"> atributo title) de los datos de contacto. El usuario que utilice una ayuda técnica no sabrá que esos datos son importantes. <div id="datos">

COMENTARIOS Se proporcionó etiqueta descriptiva al div (que no soportan title) de los datos de contacto, para el usuario que utilice una ayuda técnica sepa que esos datos son importantes. Este cambio implementa la técnica ARIA6 recomendada por W3C, para ayudar a cumplir el criterio 1.1.1 (A).

Tabla 21: Modificaciones realizadas para cumplir WAI ARIA en la página Productos, parte 2 CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: No se proporcionaba etiqueta descriptiva al link. El usuario que utilizaba una ayuda técnica no sabía a donde le llevaría el link.

<a href="https://es.wikipedia.org/wiki/ Madera" class="nc inicio" title="Leer en Wikipedia sobre Madera" arialabel="Leer en Wikipedia sobre Madera">Madera</a>

Se proporcionó etiqueta descriptiva del objetivo de los links en la página de productos, a cada producto. Este cambio implementa la técnica ARIA8 recomendada por W3C, para ayudar a cumplir los criterios 2.4.4 (A) y 2.4.9 (AAA).

<a href="https://es.wikipedia.org/wiki/ Madera" class="nc inicio" title="Leer en Wikipedia sobre Madera">Madera</a>

4.3.3. Modificaciones en el archivo donde_estamos. html, http://vivero.oficentro-ecuador.com/paginas/localizacion/ donde_estamos.html Todos los cambios realizados en este archivo, para el cumplimiento de técnicas WAI-ARIA, son del mismo tipo que los realizados en los archivos: Index.html, productos.html y contacto.html. Por tal razón, no se los describe en esta sección.

Jorge Iván Pincay Ponce

Capítulo IV: Rediseño del sitio original, reevaluación

4.3.4. Modificaciones en el contacto.html, http://vivero. oficentro-ecuador.com/paginas/contacto/contacto.html Tabla 22: Modificaciones realizadas para cumplir WAI ARIA en la página Contacto, parte 1. CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: Se requería asociar elementos <!DOCTYPE html> con “auto información” relevante para la compatibilidad con ARIA, la web semántica, y, la interoperabilidad con tecnologías de asistencia.

COMENTARIOS Todas las páginas del sitio están reconstruidas empleando etiquetas semánticas. En concordancia con ARIA y HTML5.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">

Tabla 23: Modificaciones realizadas para cumplir WAI ARIA en la página Contacto, parte 2. CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

COMENTARIOS

Problema: Para fines de prueba, se agregó un campo “descripción del trato”, que no estaba en la aplicación; se lo incluyó para dejar al menos un campo como no obligatorio dentro del formulario de contactos.

<p> <label for=”trato”>Trato</ label><br /> <input id=”trato” placeholder=”Sr.” width=”38%” type=”text” aria-describedby=”tratoDesc” onfocus=”toggleFocus(this)” onblur=”toggleBlur(this)”/> </p> <p id="tratoDesc">Escriba como desea ser tratado, por ejemplo, ingeniero, señor, doctor, etc.</p>

Para mejorar la semántica, se han añadido las propiedades y aria-describedby a los inputs del formulario, en concordancia con ARIA1 y como ayuda para cumplir los criterios 1.3.1 de información y relaciones (A) y 3.3.2 de etiquetas o instrucciones (A).

Problema: Las tecnologías de asistencia <div id="datos" aria-label="Datos Se proporcionó etiqueta descriptiva no detectaban información relevante en útiles de contacto"> al div de los datos de contacto, algunos elementos, como este div. para el usuario que utilice una ayuda técnica sepa que esos datos <div id="datos"> son importantes en concordancia con ARIA6 y ARIA10 como ayuda para cumplir el criterio 1.1.1 de contenido no textual (A).

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

CÓDIGO FUENTE ORIGINAL

CÓDIGO FUENTE MODIFICADO

Problema: Las tecnologías de asistencia <label for="nombre">Nombre *</ no detectaban como obligatorios a label><br /> algunos elementos Input. <input id="nombre" placeholder="JORGE IVAN" Nombre: *<br/> required <input required size="30px" type="text" aria-required=”true” id="name" name="name" value="" /> width="50px" type="text" onfocus="toggleFocus(this)" onblur="toggleBlur(this)"/>

COMENTARIOS Para mejorar la semántica de los campos del formulario, se ha añadido el estado aria-required, para el usuario que utilice una ayuda técnica sepa que esos campos son obligatorios, en concordancia con ARIA1 y como ayuda para cumplir los criterios 1.3.1 de información y relaciones (A), 3.2.2 de etiquetas e instrucciones (A) y 3.3.3 de sugerencia de errores (AA).

4.4. Evaluación de la accesibilidad del sitio rediseñado

Imagen 20: Página Principal revisada con CHEKERS de EIII. Fuente: (EIII, 2017)

Capítulo IV: Rediseño del sitio original, reevaluación

Jorge Iván Pincay Ponce

Imagen 21: Página Principal revisada con CHEKERS de EIII,

Imagen 22: Página Productos revisada con CHEKERS de EIII

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

El objetivo de este test (1.4.1.), es evitar situaciones en las que personas que no pueden percibir las diferencias de color, no puedan identificar vínculos, por lo que se aconseja el subrayado del enlace o alguna otra distinción visual que no sea el color. Si bien algunos enlaces pueden ser visualmente evidentes desde el diseño y el contexto de la página, como los vínculos de navegación, los enlaces dentro del texto a menudo se entienden visualmente a partir de sus propios atributos de visualización. Eliminar el subrayado y dejar sólo la diferencia de color para estos enlaces sería un fracaso porque no habría ninguna otra indicación visual de que es un enlace. En la página Productos, del rediseñado sitio de Viveros, CHECKERS encontró 11 enlaces y todos superaron este test, satisfaciendo así el criterio de conformidad 1.4.1 de WCAG 2.0 (EIII, 2017)

Imagen 23: Página de Productos revisada con CHEKERS de EIII.

Imagen 24: Página de ¿Dónde estamos? revisada con CHEKERS de EIII.

Capítulo IV: Rediseño del sitio original, reevaluación

Jorge Iván Pincay Ponce

Imagen 25: Página de Contactos revisada con CHEKERS de EIII.

Imagen 26: Página Principal revisada con ACHEKERS.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 27: Página de Productos revisada con ACHEKERS.

Imagen 28: Página de ¿Dónde estamos? revisada con ACHEKERS.

Capítulo IV: Rediseño del sitio original, reevaluación

Jorge Iván Pincay Ponce

Imagen 29: Página de contactos revisada con ACHEKERS.

Imagen 30: Resumen de la herramienta WebAIM, sólo en la página principal se recurre 13 veces a técnicas HTML5 y ARIA. No hay errores de contrastes de colores.

UNA WEB PARA TODOS: Comprendiendo y aplicando las WCAG 2.0

Imagen 31: Resumen de la herramienta WebAIM, solo en la página Productos se recurre 32 veces a técnicas HTML5 y ARIA. No hay errores de contrastes de colores.

CONCLUSIONES La mayoría de los sitios web tienen algún tipo de barrera de accesibilidad que dificulta que una persona con discapacidad use los mismos, afortunadamente existen herramientas de software (inclusive de forma gratuita), que están disponibles para revisar y evaluar de forma automatizada a las páginas web y algunos otros elementos del software, como archivos PDF. En ocasiones, cuando sea necesario concentrarse en problemas específicos de accesibilidad, convendrá realizar comprobaciones manuales de páginas representativas en un sitio web, es decir, aquellas en las que es más probable que las personas ingresen a su sitio. En el ejemplo del sitio web rediseñado en este libro, se logró cumplir con algunos criterios de conformidad de los niveles A, AA y AAA de WCAG 2.0; e incluso, se cumplieron algunas directrices de WAI-ARIA 1.0. La aplicación de ejemplo estaba constituida por cuatro páginas web y en ellas se empleaban tecnologías CSS (1, 2 y 3) y HTML (4, y 5). Es de acotar que, para cumplir con algunos criterios de conformidad, en el rediseño del sitio fue necesario recurrir a JavaScript como tecnología del lado del cliente. En cuanto a los tiempos de implementación de código de soporte para accesibilidad, estos son siempre relativos, dependiendo del conocimiento de las tecnologías web, contexto o actividad del sitio y de la experiencia diseñando sitios para usuarios que hayan empleado tecnologías de asistencia. La evaluación durante el proceso de desarrollo del sitio es uno de los consejos esenciales para evaluar la accesibilidad en la web, sin embargo, como decía Fred Brooks para referirse a las actualizaciones del software: “Deberíamos rehacer el software cada siete años para eliminar los problemas latentes”.

BIBLIOGRAFÍA Addin, O. (Enero de 2017). Web-Accessibility Automatic Checking Tools and Evaluation in Saudi Arabia: A Systematic Literature Review. International Journal of Engineering Science and Innovative Technology (IJESIT), 6(1), 14-17. Recuperado de https://goo.gl/dxBNZQ Apple Inc. (2017). Apple. Recuperado de Accesibilidad: https://www.apple.com/la/accessibility/ Cool Z. (4 de Mayo de 2010). Cool Z. Recuperado de ¿A quién beneficia una web accesible?: http:// www.cool-z.com/blog/2010/a-quien-beneficia-una-web-accesible/ CRYPTZONE. (2017). Cynthia Says™. Recuperado de Welcome to the Cryptzone® Cynthia Says™ Portal: http://www.cynthiasays.com/ Dyno Mapper. (28 de Abril de 2017). Top 25 Awesome Accessibility Testing Tools for Websites. Recuperado de Why is Web Accessibility needes?: https://goo.gl/D9je83 EIII. (2017). European Internet Inclusion Initiative. Recuperado el Junio 2 de 2017, de http://eiii.eu/ Luján Mora, S. (2017). Accesibilidad Web. Recuperado de ¿Qué es la accesibilidad web?: https://goo. gl/MyTLco Moreno, L., Martínez, P., & González, Y. (2014). Guía para elaborar documentación digital accesible. Recomendaciones para Word, PowerPoint y Excel de Microsoft OFFICE 2010 (Vol. 5). Centro Nacional de Tecnologías de la Accesibilidad (CENTAC). NIBBLER. (2017). NIBBLER. Recuperado de About Nibbler: http://nibbler.silktide.com Raman,T.V. (1994). Audio system for technical readings. Tesis doctoral sin publicar, Cornell University, Faculty of the Graduate School. Recuperado de https://goo.gl/QEsgJs Sloan, D., Heath, A., Hamilton, F., Kelly, B., Petrie, H., & Phipps, L. (2006). Contextual web accessibilitymaximizing the benefit of accessibility guidelines. Proceeding W4A ‘06 Proceedings of the 2006 international cross-disciplinary workshop on Web accessibility (W4A): Building the mobile web: rediscovering accessibility?, 121-131. doi:10.1145/1133219.1133242 WebAIM. (2017). WebAIM. Recuperado de We have web accessibility in mind: http://webaim.org/ World Wide Web Consortium (W3C). (11 de Diciembre de 2008). Web Content Accessibility Guidelines (WCAG) 2.0. Recuperado de https://www.w3.org/TR/WCAG20/

GLOSARIO DE TÉRMINOS TÉRMINO

SIGNIFICADO

Accesibilidad Web

Según el W3C, la accesibilidad Web significa que personas con algún tipo de discapacidad van a poder hacer uso de la Web.

ATAG

Siglas en inglés de Pautas de Accesibilidad para Herramientas de Autor, son un conjunto de normas que deben cumplir las herramientas de autor para ser accesibles y generar contenidos también accesibles.

Consorcio Mundial Es un consorcio internacional que genera recomendaciones y estándares que aseguran el de Internet (W3C) crecimiento de la World Wide Web a largo plazo. Discapacidad

La discapacidad es aquella condición bajo la cual ciertas personas presentan alguna deficiencia física, mental, intelectual o sensorial que a largo plazo afectan la forma de interactuar y participar plenamente en la sociedad.

EARL

Siglas en inglés de Lenguaje de Evaluación y Reporte. EARL es un proyecto del W3C para desarrolladores que deseen construir su propia herramienta de evaluación.

ICDRI

Siglas en inglés de Centro Internacional de Recursos para Discapacitados en Internet, con sede en Estados Unidos, es un centro de políticas públicas internacionalmente reconocido y organizado por y para personas con discapacidades.

Section 508

La Section 508 exige que toda la tecnología electrónica y de la información que sea desarrollada o adquirida por las Agencias Federales se accesible a las personas con discapacidad. En realidad, se trata de una enmienda a la ley Workforce Rehabilitation Act de 1973.

Tecnologías Asistencia

de Las tecnologías de apoyo o tecnologías de asistencia (también conocidas como AT, del inglés assistive technologies) son cualquier producto (incluyendo dispositivos, equipos, instrumentos, tecnología y software) que es usado para incrementar, mantener o mejorar las capacidades funcionales de personas con discapacidad.

UUAG

Siglas en inglés de Pautas de accesibilidad para agentes de usuario. Las UAAG definen como los navegadores, los reproductores multimedia y otros “agentes de usuario” deberían soportar la accesibilidad para gente con discapacidades y trabajar con tecnologías de asistencia.

WAI

Siglas en inglés de Iniciativa para la Accesibilidad Web, es una rama del World Wide WebConsortium (W3C) que vela por la accesibilidad de la Web.

WAI-ARIA

WAI-ARIA, son las siglas de Web Accessibility Initiative - Accesible Rich Internet Applications, y, es un estándar del W3C, desde el año 2014, pensado para hacer más accesible el contenido dinámico –principalmente JavaScript y Ajax- transmitiendo a las APIs de accesibilidad información sobre el comportamiento de la interfaz y su estructura, para que los productos de apoyo puedan acceder a dicha información.

XHTML

Siglas en inglés de Lenguaje de Marcado de Hipertexto Extensible, es una versión más estricta y limpia de HTML, que nace precisamente con el objetivo de remplazar a HTML ante su limitación de uso con las cada vez más abundantes herramientas basadas en XML.

SOBRE EL AUTOR Jorge Iván Pincay Ponce, (Ecuador, 1983); Ingeniero en Sistemas por la Universidad Laica Eloy Alfaro de Manabí (Ecuador), a nivel de postgrados tiene un Diplomado en Educación Universitaria por Competencias por la Universidad de Cuenca (Ecuador), un Máster en Gestión de Tecnologías de la Información y de las Comunicaciones por la Universidad Nacional de Piura (Perú) y un Máster en Ingeniería de Software para la Web por la Universidad de Alcalá (España). Desde el año 2008 se desempeña como docente ocasional en la Facultad de Ciencias Informáticas en la Universidad Laica Eloy Alfaro de Manabí, tutorando asignaturas relacionadas a la Ingeniería de Software e Inteligencia Artificial. Ha investigado sobre el desarrollado de videojuegos, accesibilidad web y gestión de tecnologías de la información especialmente en las PYMES, habiendo publicado varios artículos. Y libros; además de haber participado en ponencias sobre estas temáticas.