1
Tesis de Grado en Ingeniería en Informática
Abril 2010
Tesista: Maia R. Naftali
Director: Prof. Ing. Osvaldo Clúa
Análisis e Integración de Métricas para la
Accesibilidad Web
2
ContenidoI. 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
II. Evaluación de la Accesibilidad Web– Procesos de evaluación– Métricas
III. OceanAcc, la herramienta– Objetivos– La aplicación– La experiencia– Conclusiones obtenidas
IV. Conclusiones generales
3
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
4
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
5
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 avanzada6
7
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
8
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
9
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.
10
El modelo según la WAI (W3C)
Guideline
Checkpoint 1
Checkpoint 2
..
Checkpoint N
11
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)
12
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)
13
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ó?
14
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.
15
Parte II:Evaluación de la Accesibilidad Web
16
2.1 Evaluación de la accesibilidad Web
• 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
Automática
• Prueba de presencia/ausencia de barreras.
• Uso de casos de prueba con usuarios reales.
• Método costoso pero eficaz.Manual
• Prueba de conformidad en una muestra aleat.
• Uso de herramientas automáticas y reportes.
• Benchmark. Fines de investigación.
Monitoreo
17
2.2. Procesos de evaluación: Ejemplos
• Desarrollado por la WAI (del W3C)• Propone niveles de pruebas, y la elección y
uso de las herramientas automáticasWAI (A)• Desarrollado por G.B., Investigador (It).• Propone una heurística y un mapeo entre
barreras y checkpoints• Define métricas y casos de prueba
Barrier Walkthrough
(M)• Desarrollado por laboratorio WABCluster
(Eu)• Define casos de prueba, métricas, criterios
de conformidad, metodología para el muestreo
UWEM (Mon)
18
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
19
Métricas existentes (1)
• Failure Rate (B)
• WAB Score
• UWEM Score
p
p
P
BFR
p
p vv
v
v
N
WNn
WABScore
n
j bb
pj
pj WP
B
nUWEM
1
111
20
b
pbub CSupA )1(1),(3
p
pb
pb
pb
pb B
B
N
BC
}3,2,1{1 },,,{ },{
1
xxyzz
NP
j RUOPx wey x
xyx AWNT
NT
NT
NT
NPWAQM
contrario caso en a,P
Ba
100/ba
100a
P
Bsi100,
b
100
P
B
A
xyz
xyz
xyz
xyz
xyz
xyz
xyz
• A3(B)
• WAQM (C)
Métricas existentes (2)
21
• AI
Métricas existentes (3)
22
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.).
23
Parte III:OceanAcc, la herramienta
24
3. 1 Objetivos
• Primarios– 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
25
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
26
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
27
3.3 OceanAcc: Proceso para una página
Usuario
AChecker
Crear Página
Crear Test
Importar resultados
Ejecutar Test
Metric ManagerTest manager
Editar resultados
Generar lista de barreras
Aprobar resultados Calcular métricas
Almacenar
28
• 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.4 OceanAcc: Métricas que se calculan
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
29
30
3.6 La Experiencia-Se ejecutó el proceso completo sobre el sitio de la facultad http://www.fi.uba.ar
1. Crear Página2. Crear Test3. Ejecutar prueba4. Filtrar5. Generar métricas
-Se repitió el proceso para otro conjunto de páginas
-Se generaron las métricas para todos
31
3.6 La Experiencia (2)
“Laboratorio”
32
• Sobre la evaluación de Fiuba, se filtraron los resultados que no aplicaban (Falsos Positivos).
3.6 La Experiencia (3)
33
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
34
3.6 La Experiencia (5): Análisis múltiple
-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.
Página FailurePoints
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) 25 0 0 0 0
36
Parte IV:Conclusiones generales
37
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
38
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.
39
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
40
¿Preguntas?. ¿Comentarios?…
41
F I N