Análisis e Integración de Métricas para la Accesibilidad Web Tesis de Grado en Ingeniería en Informática Análisis e Integración de Métricas para la Accesibilidad Web Tesista: Maia R. Naftali Director: Prof. Ing. Osvaldo Clúa Abril 2010

Contenido La Accesibilidad Web Introducción El modelo Cómo acceden a la web las personas con discapacidad Barreras Las pautas para la accesibilidad Web Normativas Evaluación de la Accesibilidad Web Procesos de evaluación Métricas OceanAcc, la herramienta Objetivos La aplicación La experiencia Conclusiones obtenidas Conclusiones generales

Parte I: La Accesibilidad de la Web “The dream behind the Web is of a common information space in which we communicate by sharing information.” Tim Berners-Lee

1. Introducción Por qué elegí este tema? Qué me motivó a seguir? Gran Importancia  Desconocimiento Uso de la tecnología para lograr una mejora en la sociedad Acercamiento con la industria Difusión en ámbitos académicos

Objetivos de la tesis: Estudiar el modelo de accesibilidad vigente Analizar y determinar las causas por las cuales no se generalizó la incorporación de la accesibilidad en la Web Analizar y clasificar los diferentes procesos de evaluación de accesibilidad en la Web y las métricas asociadas. Proponer un proceso de evaluación que integre métricas y optimice la intervención manual del evaluador

1.1 La Accesibilidad Web Definición: “Capacidad o posibilidad de la misma en ser percibida, entendida, interactuada y navegada por personas con algún grado de discapacidad”. Problemas visuales Problemas auditivos Problemas cognitivos y neurológicos Problemas del habla Problemas de motricidad Usuarios de edad avanzada

1.2 Cómo acceden a la web las personas con discapacidad? Tecnologías asistivas --> Dispositivos que permiten a las personas con discapacidad interactuar con una computadora SayIt! Sam Teclados Amplificadores y correctores de gamma Dispositivos Braille Filtros para mouse Lectores de pantalla

1.3 Barreras “Elementos en una página que impiden a las personas con discapacidad acceder a los recursos”. Algunos ejemplos de barreras en la Web: Aparición de ventanas emergentes (pop-up) Páginas que sólo se operan con un mouse Limitaciones en el tiempo de respuesta Imágenes que no tienen una descripción textual Elementos destellantes ó animados

1.4 Pautas para la accesibilidad web del consorcio W3 (W3C) UAAG User Agent Accessibility Guidelines Marco de referencia para empresas que desarrollan tecnología Objetivo: Eliminar barreras del software usado para navegar la Web ATAG Authoring Tool Accessibility Guidelines Aplican al software para edición web Objetivo: Eliminar barreras del software y del contenido editado WCAG Web Content Accessibility Guidelines Aplican a la generación de contenido Objetivo: Eliminar las barreras del contenido y de su presentación.

El modelo según la WAI (W3C) Guideline Checkpoint 1 Checkpoint 2 .. Checkpoint N

Ejemplo de pautas y checkpoints: WCAG 2.0 (1) “Pauta 2.2 Tiempo suficiente: Proporcione a los usuarios el tiempo suficiente para leer y usar un contenido. “ Checkpoint 2.2.4 Interrupciones: El usuario puede posponer o eliminar las interrupciones, excepto cuando las interrupciones vienen provocadas por una emergencia.(Nivel AAA)

Ejemplo de pautas y checkpoints: WCAG 2.0 (2) “Pauta 3.1 Legible: Haga el contenido textual legible y comprensible. “ Checkpoint 3.1.1 : 3.1.1 Idioma de la página: El idioma por defecto de cada página web puede ser programablemente determinado. (Nivel A)

Los problemas del modelo de pautas Basado en el contenido: 1:1000000! Poca difusión Mitos y desinformación Complejidad y dificultad de aprendizaje. Interpretación ambigua Testeo. Cómo probar que se cumplió?

1.5 Normativas de Accesibilidad Web Implementan WCAG Algunas regiones que las implementaron: EEUU (Section 508), Canadá, España, Unión Europea. Pro: Difusión y mayor alcance Contra: Leyes Basadas en pautas viejas.

Parte II: Evaluación de la Accesibilidad Web

2.1 Evaluación de la accesibilidad Web Automática Prueba de conformidad con las pautas. Uso de herramientas automáticas y algoritmos. Método de bajo costo pero requiere del filtro humano para eliminar ruido de falsos positivos Manual Prueba de presencia/ausencia de barreras. Uso de casos de prueba con usuarios reales. Método costoso pero eficaz. Monitoreo Prueba de conformidad en una muestra aleat. Uso de herramientas automáticas y reportes. Benchmark. Fines de investigación. procedimientos orientados a la búsqueda de problemas de accesibilidad

2.2. Procesos de evaluación: Ejemplos WAI (A) Desarrollado por la WAI (del W3C) Propone niveles de pruebas, y la elección y uso de las herramientas automáticas Barrier Walkthrough (M) Desarrollado por G.B., Investigador (It). Propone una heurística y un mapeo entre barreras y checkpoints Define métricas y casos de prueba UWEM (Mon) Desarrollado por laboratorio WABCluster (Eu) Define casos de prueba, métricas, criterios de conformidad, metodología para el muestreo

2.3 Las métricas para la accesibilidad Web Medida destinada a conocer o estimar atributos de calidad de un artefacto. Se calculan con el resultado de las pruebas. Dan una idea del grado de accesibilidad. Permiten comparar entre páginas Se conoce como métrica a cualquier medida destinada a conocer o estimar atributos de calidad de un artefacto Las métricas son importantes para controlar, entender y mejorar productos y procesos en el desarrollo de software.

Métricas existentes (1) Failure Rate (B) WAB Score UWEM Score

Métricas existentes (2) A3(B) WAQM (C)

Métricas existentes (3) AI

Conclusiones sobre las métricas Enfasis en incorporar atributos matemáticos para ganar precisión, pero…. Procesos “poco precisos”: Alto desvío por falsos positivos y negativos. Barreras que no pueden ser probadas con métodos automáticos: El impacto sobre el resultado no está ponderado. Alto costo en generar y mantenter las métricas. Muchas variables en juego (usuarios,severidad, prioridades, etc.).

Parte III: OceanAcc, la herramienta

3. 1 Objetivos Primarios Secundarios Hacer más eficiente la evaluación de la accesibilidad Web (Manual y automática). Integrar métricas al proceso de evaluación obtenidas de forma semiautomática Generar información de valor de forma rápida   Secundarios Simplificar la incorporación del juicio humano a través de una interfaz gráfica simple y eficiente

3.2 OceanAcc: La aplicación Aplicación Desktop C# .Net 3.5 – WPF - Base de datos por odbc Consume WebService para validar páginas “Achecker”, desarrollado en la Universidad de Ontario Reportes rdlc

3.2 OceanAcc: La aplicación (2) Funcionalidad de la aplicación:   Ejecutar prueba Importar resultados Filtrar resultados de una prueba Generar métricas Mostrar reportes Crear/Eliminar Prueba Crear/Modificar/Eliminar Página Configurar parámetros

3.3 OceanAcc: Proceso para una página

3.4 OceanAcc: Métricas que se calculan Métricas existentes: Failure Rate UWEM Score WABScore Métricas Propias: WABScore* : Adaptación mejorada de WABScore False Positive Rate: Tasa de falsos positivos

3.5 OceanAcc: Cómo funciona Llamada a rest webservice Importación de resultados Mapeo checkpoint-barrera Edición de resultados (checkpoints y barreras) Generación de métricas

3.6 La Experiencia Se ejecutó el proceso completo sobre el sitio de la facultad http://www.fi.uba.ar Crear Página Crear Test Ejecutar prueba Filtrar Generar métricas Se repitió el proceso para otro conjunto de páginas Se generaron las métricas para todos

3.6 La Experiencia (2) “Laboratorio”

3.6 La Experiencia (3) Sobre la evaluación de Fiuba, se filtraron los resultados que no aplicaban (Falsos Positivos).

3.6 La Experiencia (4): Análisis Fiuba Resultados de las métricas: FR = 0.886  Se ingresaron menos puntos de falla de los existentes. Aún así dio elevado. UWEM = 0.2863  La probabilidad de encontrar una barrera es cercana al 30% (Alto). FPR = 0.6331  Cerca del 37% de las advertencias son correctas

3.6 La Experiencia (5): Análisis múltiple Página Failure Points FR [0;1] WABScore [0;5,5]U(5,5;N) WABScore* UWEM [0;1] Google 2 0,054 0,007752 0,02041 0,06781 Fiuba 158 0,886 1,085271 2,85714 0,29486 Yahoo AR 25 0,305 0,023256 0,06122 0,08705 ACM (Testigo) La página más accesible según la experiencia es Google (ACM es el caso testigo). La forma en que la métrica computa el peso de la barrera castiga/beneficia a ciertos errores. Barrera no es checkpoint! Muchos fallos pueden generar pocas barreras.

3.6 La Experiencia (6): Conclusiones Las métricas son útiles para comparar entre páginas y versiones. Las métricas sirven para saber en qué orden se encuentra una página La lectura aislada para un solo sitio no genera información útil. Hay una variación extra que depende del conocimiento del usuario que filtra

Parte IV: Conclusiones generales

Conclusiones generales(1/3) Los estándares, las pautas y las normativas por sí solos demostraron un alcance limitado. Las métricas son útiles para comparar entre páginas y versiones: En qué orden se encuentra La lectura aislada para un solo sitio no genera información útil. Resulta contradictoria la medición exacta, cuando los parámetros empleados son experimentales o están definidos de forma arbitraria

Conclusiones generales(2/3) Precisión de las métricas   ruido en evaluaciones Sin la intervención del juicio humano resulta imposible filtrar los resultados y quitar los falsos positivos. En pruebas automáticas, es posible lograr la conformidad con las pautas trabajando sobre los puntos que arrojan errores, aún sin otorgarle sentido a los cambios.

Conclusiones Generales (3/3) Es útil disponer de un valor que de una idea del grado de accesibilidad que estamos obteniendo, siempre y cuando se tengan en cuenta todas las dispersiones presentes, y no se trabaje para mejorar la métrica sino la accesibilidad en general

¿Preguntas?. ¿Comentarios? …

F I N