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