Está en la página 1de 117

Marzo 2010

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


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Resumen

La accesibilidad en la Web se refiere a la posibilidad de la misma en ser percibida,

entendida, interactuada y navegada por personas con algún grado de discapacidad. Se incluyen

problemas visuales, auditivos, físicos, cognitivos, neurológicos y del habla. Existen pautas para

la creación de contenido Web accesible, así como también leyes en muchos países que

promueven el contenido Web accesible. Sin embargo, la aplicación de las pautas no está

generalizada y existe desconocimiento acerca de este tipo de prácticas.

Para detectar problemas a la accesibilidad en el contenido Web existen procesos de

evaluación tanto manuales como automáticos. Los métodos manuales, que se basan en la

ejecución de casos de prueba por parte de usuarios con discapacidad, son efectivos pero costosos.

Los métodos automáticos, que utilizan un software para verificar las páginas, son menos

completos: su resultado no contempla aquellos casos que exceden al control algorítmico básico

que realizan. Existen métricas asociadas a los procesos de evaluación que permiten cuantificar el

grado de accesibilidad obtenido.

En este trabajo se plantea un proceso de evaluación semiautomático que integra métricas

de accesibilidad Web, y es implementado por la aplicación “OceanAcc”. El objetivo del mismo

es optimizar la evaluación de sitios Web. Con poca intervención del usuario, se generan reportes

y métricas que aportan información cuantitativa. Esto permite detectar e informar las barreras

más importantes, reduciendo el esfuerzo de las evaluaciones no automáticas.

Maia Naftali 82.624 2 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Abstract

Web accessibility refers to the capability of the web to be perceived, understood,

interacted and navigated by people with disabilities. This includes visual, auditive, cognitive,

physical, neurological and speech disabilities. There are accessibility guidelines for Web content

creation, and many countries have adopted laws to promote the generation of accessible web

content. However, the implementation of the guidelines is not generalized at the moment and

those practices are ignored by many organizations and individuals.

Evaluation processes that detect accessibility problems are classified into manual or

automatic. Manual methods are based on test case execution by real users, being effective but

expensive. Automatic testing processes, based on a software application that evaluates web

pages, are fast and easy but incomplete: the results exclude those cases that exceed the scope of

the basic algorithms used. Evaluation processes also have metrics to quantify the accessibility

grade obtained in a test.

This works proposes a semi-automatic evaluation process that integrates Web

accessibility metrics. It’s implemented by a software application called “OceanAcc”. The aim is

to optimize Web sites accessibility evaluation. With little user intervention, the application

generates reports and metrics that give quantitative information about the results. This makes

possible to detect and inform the most important barriers found, reducing non-automatic

evaluation effort and also improving general results.

Maia Naftali 82.624 3 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Agradecimientos

A mis padres Sara y Marcelo, por todo lo que me dieron en este tiempo, y por haber estado a mi
lado.
A mi hermana Karen, por su paciencia y colaboración con los gráficos.
A mis amigos, por su apoyo incondicional y por los momentos de felicidad.
A mis compañeros de la facultad, que compartieron esta carrera que por momentos parecía
infinita.
A Osvaldo, mi director de tesis, por haber hecho posible este trabajo y confiado en mí en todo
momento.

Maia Naftali 82.624 4 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Tabla de Contenidos

Resumen ............................................................................................................................................... 2
Abstract ................................................................................................................................................. 3
Agradecimientos.................................................................................................................................... 4
Tabla de Contenidos.............................................................................................................................. 5
Objetivos ............................................................................................................................................... 7
Alcance.................................................................................................................................................. 7
Organización de la Tesis ....................................................................................................................... 7

Capítulo I: La Accesibilidad en la Web ................................................................................................... 9


1.1 La World Wide Web......................................................................................................................................... 9
1.1.1 Orígenes/ historia ..................................................................................................................................... 9
1.1.2 El w3 Consortium ................................................................................................................................... 10
1.2 Introducción: La Accesibilidad Web ............................................................................................................. 11
1.2.1 La entidad W3C-WAI y su rol ................................................................................................................. 11
1.2.2 Sobre la importancia de tener una Web accesible ................................................................................ 14
1.3 La Web no accesible ..................................................................................................................................... 14
1.3.1 Barreras.................................................................................................................................................. 14
1.3.2 Tipos de barreras a la accesibilidad ...................................................................................................... 16
1.3.3 Ejemplos de barreras a la accesibilidad ................................................................................................ 18
1.4.1 UAAG: User Agent Accessibility Guidelines ......................................................................................... 24
1.4.2 ATAG: Authoring Tools Accessibility Guidelines .................................................................................. 25
1.4.3 WCAG: Web Content Accessibility Guidelines ...................................................................................... 26
1.4.3.1 WCAG 1.0 ....................................................................................................................................... 26
1.4.3.2 WCAG 2.0 ....................................................................................................................................... 28
1.4.3.3 Evaluación ó Verificación del cumplimiento de las pautas para contenido .................................... 30
1.4.4 Análisis del modelo de pautas ............................................................................................................... 32
El enfoque holístico: modelo del Tangram ................................................................................................. 32
Una posible implementación de un modelo sobre WCAG ......................................................................... 34
1.5 Las normativas de Accesibilidad Web........................................................................................................... 35
1.5.1 Antecedentes ......................................................................................................................................... 35
1.5.2 Normativas particulares ......................................................................................................................... 35
Section 508 ................................................................................................................................................. 35
Unión Europea: eEurope ............................................................................................................................ 37
1.6. El problema de la creación de sitios Web accesibles .................................................................................. 38
1.6.1 Los Mitos de la accesibilidad Web ......................................................................................................... 38
1.6.2 El camino para lograr contenido Web accesible ................................................................................... 39
1.6.3 Dificultades que se presentan ............................................................................................................... 41
1.7 Estado del arte: ............................................................................................................................................ 49
1.7.1 Líneas de investigación en la actualidad ............................................................................................... 49

Capítulo II: Los Métodos de Evaluación de la Accesibilidad Web ................................................................. 51


2.1 Evaluación de sitios Web .............................................................................................................................. 51
2.1.1 Introducción al proceso de evaluación de accesibilidad ........................................................................ 51
2.1.2 Técnicas de evaluación propuestas por la WAI y su alcance................................................................ 52
2.1.2.1 Revisión preliminar (Preliminary Review) ....................................................................................... 52
2.1.2.2 Evaluación de conformidad (Conformance Evaluation) ................................................................. 53
2.1.2.3 Criterios de evaluación para contextos específicos (Approaches for Specific Content): ............... 53
2.1.2.4 Selección de herramientas de evaluación automáticas (Selecting a tool) .................................... 54
2.1.2.5 Involucramiento de usuarios (Involving Users)............................................................................... 55
2.1.2.6 Algunas conclusiones sobre la metodología de evaluación de la WAI .......................................... 55
2.1.3 UWEM ................................................................................................................................................. 56
2.1.3.1 UWEM: Introducción ....................................................................................................................... 56
2.1.3.2 UWEM Scoring ............................................................................................................................... 57
2.1.4 Barrier Walkthrough ............................................................................................................................. 57

Maia Naftali 82.624 5 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.1.4.1 Introducción .................................................................................................................................... 57


2.1.4.2 Procedimiento ................................................................................................................................. 57
2.1.4.2 Trabajos sobre Barrier Walkthrough ............................................................................................... 59
2.2. Métricas para evaluación de accesibilidad Web .......................................................................................... 60
2.2.1 Definición de métrica.............................................................................................................................. 60
2.2.2 Las métricas en la accesibilidad Web .................................................................................................... 60
2.2.3 Las métricas de evaluación de accesibilidad Web existentes: .............................................................. 61
2.2.3.1 FR (Failure Rate) ............................................................................................................................ 61
2.2.3.2 WAB Score ..................................................................................................................................... 62
2.2.3.3 UWEM Aggregation Formula .......................................................................................................... 63
2.2.3.4 A3 .................................................................................................................................................... 65
2.2.3.5 WAQM ............................................................................................................................................ 68
2.2.3.6 Mambo AI (Accessibility Index) ...................................................................................................... 70
2.3 Automatización en la evaluación de sitios accesibles .................................................................................. 72
2.3.1 Introducción ............................................................................................................................................ 72
2.3.1.1 Verificación algorítmica................................................................................................................... 73
2.3.2 Herramientas automáticas ..................................................................................................................... 74
2.3.2.1 Bobby .............................................................................................................................................. 74
2.3.2.2 T.A.W. ............................................................................................................................................. 74
2.3.2.3 WAVE ............................................................................................................................................. 74
2.3.2.4 HERA .............................................................................................................................................. 74
2.3.2.5 EvalAcces ....................................................................................................................................... 75
2.3.2.7 Achecker ......................................................................................................................................... 75
2.4 Conclusiones: Procesos de evaluación y métricas ....................................................................................... 76

Capítulo III: OceanAcc, Una aplicación que integra métricas en un proceso de evaluación
semiautomático ................................................................................................................................... 79
3.1 Motivación ..................................................................................................................................................... 79
3.2 Objetivos ........................................................................................................................................................ 79
3.3 Descripción de la aplicación .......................................................................................................................... 80
3.4 Documentación .............................................................................................................................................. 81
3.4.1 Modelo de datos ..................................................................................................................................... 81
3.4.2 Arquitectura ............................................................................................................................................ 82
3.4.3 Descripción del proceso de prueba de una página ............................................................................... 83
3.4.4 Sobre el proceso de evaluación con Achecker ...................................................................................... 84
3.4.5 Sobre las métricas generadas ............................................................................................................... 85
3.5 Caso de estudio ............................................................................................................................................. 87
3.5.1 Caso de estudio I: página de la Facultad de Ingeniería ........................................................................ 87
3.5.2 Tabla comparativa de métricas entre páginas: .................................................................................. 93

APENDICES ........................................................................................................................................ 98
Apéndice A: Glosario de afecciones abarcadas por la accesibilidad Web ......................................................... 98
Apéndice B: Glosario de Tecnologías asistivas ................................................................................................ 100

GLOSARIO........................................................................................................................................ 104

REFERENCIAS ................................................................................................................................. 108

Maia Naftali 82.624 6 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Introducción

Objetivos

• 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, mejorando la lectura de los resultados y el tiempo empleado.
• Desarrollar una aplicación que materialice dicho proceso y contribuya a una mejora en el
campo.

Alcance

El trabajo está centrado en los aspectos que refieren a los estándares y a la evaluación de la
accesibilidad en la Web. Queda fuera del alcance del trabajo todo lo relacionado a la usabilidad,
a las tecnologías que hacen uso de la Web y a los aspectos técnicos de la legislación.

Organización de la Tesis

El texto está organizado en tres capítulos. En el primero se analizan los aspectos generales de la
accesibilidad en la Web. En el segundo capítulo, se estudian los diferentes procesos de
evaluación y las métricas existentes. Finalmente, en el tercer capítulo se describe la aplicación
desarrollada y se trae como ejemplo de funcionamiento un caso de estudio.
Al final están las referencias bibliográficas y los apéndices, que incluyen los glosarios del
trabajo.

Maia Naftali 82.624 7 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo I:

La Accesibilidad en la Web

Maia Naftali 82.624 8 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo I: La Accesibilidad en la Web

“The dream behind the Web is of a common information space in which we communicate by sharing information.”
[Tim Berners-Lee, “The World Wide Web, a Very Short History”, 1997]

1.1 La World Wide Web

1.1.1 Orígenes/ historia

La World Wide Web, generalmente conocida como la Web, es un sistema de documentos


de hipertexto vinculado accesibles por Internet. Usando un programa conocido como Web
Browser se pueden ver páginas que pueden contener texto, imágenes, y medios continuos como
video o música.

Uno de los grandes aciertos del sistema fue la conexión entre las páginas a través de
hipervínculos. Esto permite hacer un recorrido no lineal entre los documentos, conocido como
navegación. La propuesta original de la Web fue redactada en la CERN (European Organization
for Nuclear Research) [Berners-Lee, 1989] en el año 1989 por Sir Timothy John Berners-Lee ,
tomando como idea precursora a un proyecto jamás materializado llamado Memex. Ideado por
Vannevar Bush en 1945, consistía en un dispositivo que almacenaría documentos de todo tipo
que serían consultados y editados a través de una especie de teclado con palancas [memex].

Marzo de 1989 es considerado como el hito que marca el nacimiento de Internet, y


posiciona Berners-Lee como padre [Berners-Lee, 1989]. La propuesta formal de la Web fue
presentada oficialmente en la CERN el 12 de Noviembre de 1990 [Berners-Lee & Cailliau, 1990]
en parte gracias a la colaboración de Robert Cailliau. Como miembro de la CERN, fue quien
decidió tomar la idea de Berners-Lee y ayudó tanto en la redacción como en la provisión de
recursos para concretar el proyecto. A fines de 1990 ya habían construido el primer servidor Web
en un sistema Next, y el primer software navegador-editor de páginas [link:Webbrowser].

Sin embargo no fue antes de abril de 1993 cuando la CERN decidió permitir el uso libre y
gratuito de la Web a la comunidad [HistoryInternet]. La aparición del primer browser MOSAIC
de la NCSA (National Center for Supercomputer Applications) marcó el comienzo oficial de la
Web como un sistema orientado a la comunidad.

Maia Naftali 82.624 9 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.1.2 El w3 Consortium

El Wc3 (World Wide Web Consortium) es un consorcio que agrupa a organizaciones


internacionales multidisciplinarias y miembros que trabajan en conjunto para desarrollar
estándares Web y pautas. Su lema es: “Guiar la Web hacia su máximo potencial a través del
desarrollo de protocolos y pautas que aseguren el crecimiento futuro de la Web” [AboutW3]. A
través de varios organismos, libera estándares y tecnologías sobre las cuales se basarán los
documentos en la Web. Dentro de los estándares más conocidos están el PNG para los gráficos,
el HTML para los sitios, CSS y SOAP.

Diagrama 1.1.2 Estándares que maneja el consorcio W3 [w3CStd]

Maia Naftali 82.624 10 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.2 Introducción: La Accesibilidad Web

La accesibilidad en la Web se refiere a la posibilidad ó capacidad de la misma en ser


percibida, entendida, interactuada y navegada por personas con algún grado de discapacidad.
Siguiendo pautas de diseño específicas, las páginas Web pueden ser accedidas por una variedad
de usuarios a lo largo de diferentes escenarios. Se incluyen problemas visuales, auditivos, físicos,
cognitivos, neurológicos y del habla [WAIintro & Thatcher et al., 2006].

Los usuarios con discapacidad operan las computadoras a través de dispositivos


especiales, llamados tecnologías asistivas. En ambientes con software conocido, esos
dispositivos tienen un funcionamiento esperado, pero no ocurre lo mismo cuando se navega por
la Web. Al ser ésta un sistema abierto y poseer documentos editados por millones de personas,
el comportamiento pasa a depender de la página abierta.

En un principio las páginas Web consistían en simples textos planos, y eso permitía que
se adaptaran muy fácilmente a cualquier tecnología asistiva. Con el tiempo, el HTML fue
evolucionando hasta llegar a una Web más “gráfica”. La complejidad agregada tanto a la
estructura como a la presentación de los documentos dificultó el trabajo de los sistemas de
asistencia. Todos los elementos en una Web que interfieren con la accesibilidad son
denominados “barreras”.

El número de usuarios de la Web que se ve afectado por las barreras a la accesibilidad no


es un dato menor. Una estadística realizada por el Trace Center en la Universidad de Wisconsin
[Wisconsin] arroja una tendencia en crecimiento de la población en edad adulta.
Más allá de los números, la importancia radica en conocer que un gran porcentaje de la audiencia
de los sitios Web presenta dificultades en el acceso y eso se contrapone a los objetivos originales
del fundador Tim Berners-Lee [Paciello, 2002].

1.2.1 La entidad W3C-WAI y su rol

Con el fin de crear un estándar en las tecnologías para el desarrollo Web, la W3C tiene un
organismo llamado WAI (Web Accessibility Initiative) [WAIabout].
La WAI, surgida en el año 1997, se dedica a desarrollar estrategias, pautas y recursos para hacer
la Web accesible a las personas con discapacidad.

Maia Naftali 82.624 11 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Una pauta (traducido de Guideline), a diferencia de una ley o normativa, es un conjunto de


recomendaciones detalladas y organizadas con puntos de control (de ahora en adelante,
Checkpoints). Cada pauta contiene sugerencias y ejemplos a seguir para lograr la conformidad
con cada uno de sus puntos de control. Existen tres componentes diferenciados sobre los cuales
la WAI genera pautas de accesibilidad:

1) Authoring tools and User Agents: Authoring Tool se denomina al software usado para la
creación de sitios Web, y un User Agent es un software cliente que se conecta a la red
(comúnmente se llama así a los navegadores Web o browsers). Es responsabilidad de las
empresas de desarrollo.
2) Tecnologías asistivas: Es la interfaz del lado del usuario (lectores de pantalla, dispositivos
Braille, etc.). Es responsabilidad de las empresas fabricantes del hardware/software.
3) Contenido: Está conformado por el conjunto de páginas Web. Es responsabilidad de los
desarrolladores y diseñadores.

Diagrama 1.2.1.a El modelo de pautas del consorcio W3 [WAI interdependences, 2005]

La idea original de la WAI al realizar esta separación entre partes fue lograr un
compromiso mutuo [WAI interdependences, 2005]. Si una parte tomaba la iniciativa y
comenzaba a implementar las recomendaciones sobre accesibilidad, el resto haría lo mismo.
Además, la responsabilidad de resolver la barrera se repartiría de forma balanceada [Chisholm &
Henry, 2005],

Maia Naftali 82.624 12 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Diagrama 1.2.1.b Los componentes de la accesibilidad y las barreras

El objetivo que se persigue es eliminar las barreras, y cada parte actuaría en consecuencia
adaptando el comportamiento. Incorporar una pauta a un navegador o tecnología asistiva implica
contemplarlo desde la visión del producto. Es por eso que la WAI cuenta con el patrocinio de las
principales empresas informáticas del mundo, quienes tienen el compromiso de implementar
dichas pautas en sus productos. Incorporar pautas de accesibilidad al contenido requiere la
adopción de las mismas en la construcción de las páginas Web.

El desbalance de esta estrategia no está en la separación de incumbencias, sino en el


volumen: La cantidad de productos o tecnologías es despreciable respecto de los millones de
páginas Web activas alojadas en Internet. Como plantea Chisholm en su estudio, se evita el
síndrome del “huevo y de la gallina” creando un juego de cooperación entre las partes. Sin
embargo, una de las condiciones necesarias para el éxito del modelo es contar con una fuerte
adhesión de las pautas para contenido. A lo largo de este trabajo se volverá sobre este aspecto
que explica por qué se alcanzó el actual grado de madurez.

Maia Naftali 82.624 13 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.2.2 Sobre la importancia de tener una Web accesible

“Worldwide, there are more than 750 million people with disabilities. As we move towards a highly connected
world, it is critical that the Web be usable by anyone, regardless of individual capabilities and disabilities”. Tim
Berners-Lee

Existen diversos factores por los cuales resulta importante tener una Web accesible [WAI
social factors & Thatcher et al., 2006]. El principal de ellos es el uso extensivo de la Web como
medio de comunicación: Muchos métodos tradicionales están siendo reemplazados por interfases
Web. Esta tendencia alcanza a la educación, el comercio, las comunicaciones, la participación
civil, el cuidado de la salud, la recreación y las noticias.

Resulta valioso que la Web sea accesible para dar acceso igualitario a las personas con
discapacidad para dar una participación más activa. Por otro lado, la Web ofrece una oportunidad
de acceso a la información que no tiene precedentes.

Además de ayudar a las personas con discapacidad, disponer de una Web accesible ofrece
beneficios implícitos que aplican a otros grupos. Entre ellos:
- Edad avanzada
- Personas que no manejan un lenguaje fluido
- Conexiones a Internet de baja velocidad
- Usuarios novatos y ocasionales

1.3 La Web no accesible

1.3.1 Barreras

Una barrera se define como cualquier obstáculo presente en una página, que impida ver el
contenido en la forma en que fue concebido por sus autores.
Existen múltiples escenarios cotidianos en donde los usuarios pueden encontrarse con barreras.
Cada tipo de discapacidad es susceptible a determinadas barreras, que generalmente están
asociadas a la presentación y al estilo de la página.

Maia Naftali 82.624 14 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Para comprender la complejidad del problema, será necesario estudiar la forma en la que
cada grupo percibe la Web según el tipo de discapacidad que presenta [Brewer, 1994].

Tecnología asistiva
Barreras Principales
utilizada
- Imágenes o videos que no se pueden describir con texto

- Dispositivos Braille - Desorden en la disposición del contenido: hace que la lectura del

Pérdida de visión - Sintetizadores del Habla o sintetizador no tenga sentido, o sea muy extensa
Lectores
- Documentos que no se pueden reconocer o leer por los
dispositivos

- Configuración de colores que no puede ser alterada


Daltonismo - Ajuste de colores
- Navegadores que no soportan los ajustes del usuario

- Monitores grandes
- Lupas o aumentos - Páginas que no permiten cambiar el tamaño de la letra
Baja visión
- Configuraciones de contraste - Páginas con mala disposición que se deforman al agrandarse
especiales

- Falta de subtítulos en el audio de una página Web


- Sistema de subtitulado sobre
Pérdida de - Requerimientos de ingreso de voz en algunas páginas
audición el audio (Close Caption ó CC)
- Páginas cargadas de texto con poco material gráfico

- Ajuste de volumen
Hipoacusia - Falta de subtítulos en el audio de una página Web
- Sistema de subtitulado (CC)

- Hardware de entrada (en - Limitaciones en los tiempos de respuesta de las páginas


todas sus variantes ) especial - Falta de soporte a la navegación con teclado
Problemas
físicos - Software de rastreo - Formularios que no siguen un orden lógico en el ingreso
- Reconocimiento de voz - Avisos y pop-ups que bloquean la interacción con la página

Dificultad en el - Sintetizadores de voz - Páginas que requieren el ingreso de voz


habla
- Elementos que distraen la atención (carteles llamativos )
Problemas
- Elementos que parpadean o no están fijos
cognitivos y Ninguna en particular
relacionados con - Falta de una organización clara y consistente de la página
la edad
- Y cualquiera de las barreras anteriores
Tabla 1.3.1: Barreras de accesibilidad Web

Se puede establecer una clasificación de las barreras. Por un lado, están aquellas
relacionadas al estilo de la página (colores, tamaño, imágenes, audio y video), y por el otro están
las barreras vinculadas a la disposición de la información (layout). Este último grupo es el más
difícil de detectar porque requiere evaluar la forma en que se percibe una página según su
estructura de información [Sloan et al, 2006]. Puede ocurrir que la disposición del contenido no

Maia Naftali 82.624 15 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

siga un criterio lógico, o que utilice un vocabulario confuso. Ese aspecto conforma lo que es la
usabilidad de un sitio junto con su ontología.

Un punto importante es que la mayoría de las barreras aparecen cuando las páginas
escapan del esquema habitual del documento de texto. Cada interacción del usuario con
elementos multimediales genera un problema a la accesibilidad.

1.3.2 Tipos de barreras a la accesibilidad

A continuación se enumerarán las barreras genéricas que se pueden encontrar, independientes de


la tecnología.

(1) Vinculadas al diseño gráfico y al estilo de los elementos:


- Colores inapropiados: Uso de colores que no permiten distinguir contrastes.
- Tamaño de los objetos fijo: El texto y las imágenes tienen un tamaño fijo, o no se
muestran de forma correcta para todas las resoluciones de pantalla. Dificulta el trabajo
de las lupas.
- Mal uso de la tecnología para armar la distribución: El estándar HTML, Flash,
Silverlight, o cualquier otra tecnología mal usada, puede impedir la labor de los
lectores de pantalla.
- Usabilidad general deficiente: De los aspectos de usabilidad más generales, la barrera
principal sería el manejo de los tiempos de respuesta del usuario (por ejemplo, cuando
el texto avanza sólo y no se llega a leer). También se incluye la falta de soporte para
teclados y las distracciones innecesarias (Carteles, ventanas emergentes).

Son las barreras más fáciles de quitar desde el lado del desarrollo del sitio.

(2) Vinculadas a la organización de la información y la semántica


- Jerarquías mal definidas: La información no está bien categorizada (frecuente en
menúes y cuadros de selección carentes de criterio).
- Lenguaje confuso: El texto tiene una interpretación ambigua o dificultosa

Afectan a las personas con trastornos cognitivos, y en menor medida al resto de la


población. La solución implica la reorganización de la página, y la corrección del texto.

Maia Naftali 82.624 16 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Un punto polémico sobre estas barreras es saber en qué casos el texto no es


comprensible.

Si se tratara de un acertijo o un problema, lograr la comprensión iría en detrimento


del propio fin de resolver el desafío. Este tipo de paradojas son las que sostienen los
detractores de la “Accesibilidad Universal”, porque requieren un modelo de tratamiento
diferente.

(3) Elementos multimediales sin opciones alternativas


- Imágenes sin descripción: Las imágenes no tienen una descripción asociada que
permita a las personas no videntes conocer sobre la misma.
- Video sin subtítulos: El video no tiene subtítulos, y eso impide a los lectores de
pantalla reproducir el contenido, y no permite prescindir del audio.
- Audio sin transcripción: El sonido no está en forma de texto, e impide ser percibido
por personas con sordera o personas sin sistemas de audio.
- Aplicaciones on-line sin opción alternativa: El contenido forma parte de una
aplicación hecha en una tecnología que el usuario no posee o no puede reproducir, y
no hay una opción alternativa.

La más frecuente de las barreras es la de las imágenes sin descripción, ya la


mayoría de las páginas actuales poseen gráficos o fotos. La solución pasa por agregar
una descripción de texto a cada elemento gráfico presente en la página (Ese atributo
descriptivo es llamado “ALT” en el HTML).
Respecto al audio y al video, el agregado de subtítulos requiere que el usuario escriba
el texto y lo sincronice.

Las aplicaciones que corren dentro de páginas Web y no pueden ser reproducidas
deben brindar contenido alternativo. En muchos casos este tipo de barrera se presenta
porque la tecnología fue mal empleada, o la misma es susceptible a esos problemas.

Maia Naftali 82.624 17 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.3.3 Ejemplos de barreras a la accesibilidad


Algunas aclaraciones

Muchas barreras procedentes del uso de tecnologías diferentes del HTML son eliminadas
en versiones posteriores de las mismas; lo mismo ocurre con algunas de las prácticas de
construcción de sitios, que con el tiempo caen en el desuso.

Es erróneo asociar a las tecnologías directamente con el problema, ya que éstas poseen
métodos que permiten eliminar las barreras que pudieran presentar. La paradoja es que, si bien
las tecnologías más novedosas mejoran la accesibilidad, en los primeros tiempos de uso pueden
tener problemas de compatibilidad con el entorno de los usuarios. Esto podría derivar en otra
barrera si no se ofrece una opción compatible.

A continuación se exponen ejemplos sobre el avance de la accesibilidad a lo largo del


tiempo en las tecnologías más utilizadas al momento:

Adobe Flash/ Flex ®: Existen métodos nativos para otorgar accesibilidad a las imágenes y
formularios. Flash 6 fue la primera versión accesible. En cuanto a Flex, el fabricante
provee agregados para el lector de voz JAWS y extiende el soporte para lo que llaman
Accessible RIAs (Rich Internet Applications).

Silverlight y XAML®: Al estar basado en XML, los objetos gráficos de Silverlight poseen
atributos para ser leídos por tecnologías asistivas. El Framework 3.5 delega la interacción
con las tecnologías asistivas en el componente UIAccess, que hace de intermediario entre
el contenido y su presentación al usuario.

JavaScript: En la actualidad, la mayoría de los navegadores lo soportan. Originalmente era


una barrera por la compatibilidad, y tenía inconvenientes con los dispositivos móviles.

Youtube Videos ®: Permite agregar subtitulado a los videos con soporte multi-idioma.

PDF: Adobe® puso a disposición documentos que explican cómo generar PDFs
accesibles., y también proporciona una herramienta para verificar la accesibilidad en los
documentos.

Maia Naftali 82.624 18 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Ejemplos de Barreras:

Se analizarán las barreras desde cuatro aspectos: Inconveniente, causas por las cuales aparecen,
usuarios impactados por la barrera, y mitigación tecnológica (Ideas o mecanismos que se
ayudarían a resolver el problema haciendo uso de tecnologías no específicas)

1. Páginas con tamaño absoluto


Inconveniente: La página se deforma cuando se intenta aumentar o reducir el tamaño
Causas: Mala definición del layout, Uso de medidas en píxeles y no porcentuales,
Intención de ajustarse a resoluciones fijas, Uso de tecnologías anexas al HTML sin
opción de ajuste de tamaño, Incompatibilidades con las herramientas de autor.
Impacto: Usuarios con baja visión, usuarios de dispositivos móviles, netbooks ó pantallas
no convencionales
Mitigación tecnológica: Navegadores con lupa “gráfica” (no de caracteres).
Escenarios típicos: Generalizado.

2. Presencia de elementos intermitentes y rotativos


Inconveniente: El contenido no queda fijo, dificultando su lectura
Causas: Elección de diseño,
Impacto: Usuarios de edad avanzada, usuarios con epilepsia, usuarios con dislexia y
trastornos cognitivos.
Mitigación tecnológica: Botón de pausa para el contenido rotativo.
Escenarios típicos: Espacio publicitario, periódicos, páginas con animaciones y
elementos gráficos dinámicos

3. Códigos de seguridad o “Captcha”


Captcha es la sigla de “Completely Automated Public Turing test to Tell Computers and
Humans Apart”. En general, esta técnica es empleada para evitar que robots programados
puedan atacar al sistema en cuestión. Se le muestra al usuario una secuencia de números
en un formato gráfico, deformados mediante un algoritmo de ruido aleatorio. El usuario
debe interpretar esa secuencia e ingresarla [TuringTest].

Inconveniente: Los lectores de pantalla no pueden interpretar las secuencias (Si lo


hicieran, no tendría sentido el sistema como “freno” ante los robots).
Causas: Necesidad de verificar la presencia de un humano para evitar ataques o estafas.

Maia Naftali 82.624 19 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Impacto: Usuarios con baja visión, usuarios con ceguera, usuarios con problemas
cognitivos
Mitigación tecnológica: Ninguna ya que eso implicaría romper el algoritmo. La opción
alternativa consiste en brindar esa secuencia en formato de audio, o proporcionar algún
otro circuito que permita realizar esa operación.
Escenarios típicos: Alta y consulta de servicios (cuentas de correo electrónico,
suscripciones, juegos en línea, pagos).

4. Uso de tecnologías anexas al HTML, sin contenido alternativo


Inconveniente: El contenido puede no ser compatible con el navegador o la plataforma.
Causas: Uso de tecnologías diferentes del estándar HTML para mostrar el contenido, que
no contemplan una opción alternativa.
Impacto: Usuarios con tecnologías asistivas antiguas, usuarios con plataformas que no
poseen o no soportan dichas tecnologías
Mitigación tecnológica: -
Escenarios típicos: Páginas con versiones recientes, páginas con animaciones o
interacción gráfica, complementos Active-X bloqueados.

5. Falta de soporte a la navegación por teclado


Inconveniente: La página impide la interacción con el teclado
Causas: Uso de tecnologías anexas al HTML sin soporte para teclados y demás
dispositivos.
Impacto: Usuarios con problemas de motricidad, usuarios de edad avanzada, usuarios con
diversos dispositivos de entrada basados en el teclado.
Mitigación tecnológica: -
Escenarios típicos: Páginas que utilizan tecnologías diferentes al HTML, publicidades,
animaciones.
Esta barrera además afecta a la usabilidad de una página.

Maia Naftali 82.624 20 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

6. Páginas muy extensas sin marcas ó índice


Inconveniente: La cantidad de texto en la página obliga a los usuarios con lectores de
pantalla a realizar un recorrido lineal de principio a fin. La navegación se ve entorpecida.
Causas: Falta un índice o de marcas de posición en el texto para separar párrafos y
organizar el contenido.
Impacto: Usuarios con lectores de pantalla
Mitigación tecnológica: Las versiones más recientes permiten la lectura no secuencial
con marcas “inteligentes”.
Escenarios típicos: Contratos, resoluciones, normativas, publicaciones.

7. Uso de tablas anidadas para contener la información.


Es una práctica ampliamente utilizada, que debería ser reemplazada por estilos CSS.
Inconveniente: Los lectores de pantalla no interpretan correctamente el orden de la
página, interfiriendo con su interpretación. (Las tablas usuales en el HTML definen las
filas, y dentro de cada una las celdas. Eso define un recorrido por filas de izquierda a
derecha).
Causas: Uso de tablas anidadas para la disposición de la información. Fue una práctica
muy empleada cuando se dejaron de usar marcos en el HTML.
Impacto: Usuarios con lectores de pantalla.
Mitigación tecnológica: Lectores de pantalla que permiten la lectura no secuencial. Se
podría mitigar desde la inteligencia del lector, aunque no sería lo correcto.
Escenarios típicos: Prácticamente todas las páginas que no utilizan estilos de forma
correcta, o fueron hechas con herramientas de autor que resuelven las cuestiones de
diseño con tablas anidadas.

8. Limitaciones en los tiempos de respuesta de las páginas


Es una barrera que también interesa a los fines de la usabilidad.
Inconveniente: La página no permite al usuario tener control de los tiempos,
imposibilitando la navegación.
Causas: Presencia de animaciones o temporización de eventos con escaso margen.
Impacto: Usuarios de edad avanzada, usuarios con problemas cognitivos, baja visión, y
motricidad.
Mitigación tecnológica: Desde el navegador, se puede solicitar una pausa o pedido de
confirmación para cierto tipo de comportamiento.

Maia Naftali 82.624 21 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Escenarios típicos: Sitios con animaciones, publicidad, contenido rotativo, formularios,


exámenes, presentaciones de fotografías.

9. Presencia de contenido multimedia accesorio no solicitado ó que no tiene opción


alternativa
Inconveniente: Las páginas presentan contenido multimedial sin solicitarlo, y no
permiten deshabilitarlo o recibir en su lugar contenido accesible.
Causas: Elección de diseño
Impacto: Todos los usuarios
Mitigación tecnológica: En algunos casos, configurar el navegador para que no muestre
cierto tipo de contenido.
Escenarios típicos: Sitios con sonido emergente que no se puede apagar, sitios que
requieren escuchar/mirar un video, presentaciones que no permiten el retroceso.

10. PDFs protegidos


Inconveniente: Los lectores de pantalla no pueden interpretar el texto de los documentos.
Causas: Por protección del material, el contenido se bloquea para evitar la copia
Impacto: Usuarios con lectores de pantalla
Mitigación tecnológica: Desde el software del lector, se podría implementar el
reconocimiento de caracteres.
Escenarios típicos: Páginas con normativas, leyes, documentación digitalizada,
publicaciones varias.

11. Fórmulas matemáticas utilizando imágenes:


Inconveniente: Los lectores de pantalla no pueden interpretar las fórmulas
Causas: Uso de gráficos sin texto alternativo para expresar fórmulas en lugar del estándar
MathML, o imágenes con texto alternativo.
Impacto: Usuarios con lectores de pantalla.
Mitigación tecnológica: Uso de software para reconocimiento de caracteres (OCR) que
pueda detectar fórmulas sencillas.
Escenarios típicos: Páginas educativas, universidades, publicaciones, problemas.

Maia Naftali 82.624 22 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

12. Configuración de colores fija


Inconveniente: El contenido contiene colores de fondo fijos (sucede con los fondos
provenientes de archivos de imágenes). El software asistivo para cambio cromático no
puede intervenir, y los colores que se muestran no son percibidos por los usuarios con
ceguera al color.
Causas: Decisiones de diseño y estilo.
Impacto: Usuarios con ceguera al color, usuarios de edad avanzada o con baja visión.
Mitigación tecnológica: Filtros desde el monitor (requieren soporte del hardware gráfico).
Escenarios típicos: Páginas con elementos gráficos ó animaciones, publicidad.

13. Pop-Ups (Páginas Emergentes) que bloquean la interacción con la página


Inconveniente: La página que se estaba accediendo pierde el foco ante la aparición de una
ventana emergente con publicidad, avisos, contenido, etc.
Causas: Publicidad, decisiones de diseño.
Impacto: Usuarios con problemas cognitivos, edad avanzada, baja visión, ceguera.
Mitigación tecnológica: Bloqueo de ventanas emergentes desde el navegador. El
problema ocurre cuando las ventanas emergentes no son publicidades.
Escenarios típicos: Publicidades, avisos, excepciones, extensión de la página.

14. Páginas con elementos multimedia (Sonido, video) sin subtítulos, imágenes y
formularios sin texto o atributo descriptivo
Inconveniente: Los lectores de pantalla no pueden mostrar el contenido multimedia ó una
descripción del mismo.
Causas: Falta de soporte para subtítulos, omisión de los atributos de texto alternativo.
Impacto: Usuarios con ceguera, usuarios con baja visión, usuarios con baja audición,
usuarios con sordera, usuarios sin salida de audio, usuarios bajo situaciones especiales
(acceso por dispositivos móviles, ambientes ruidosos).
Mitigación tecnológica: Para el audio, se podría plantear un reconocimiento de voz que
trabaje con un buffer, aunque requeriría del uso de un idioma neutro junto con algún
algoritmo de aprendizaje para entrenar a la herramienta; En cuanto a las imágenes, se
podría leer parte de su título ó el nombre del archivo en el caso de que no posea texto
alternativo.
Escenarios típicos: Páginas con contenido multimedial, video streaming, radios.

Maia Naftali 82.624 23 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.4 Las pautas para lograr la accesibilidad Web

Como se expuso anteriormente, el consorcio W3 a través de su organismo para la


accesibilidad (WAI) desarrolló un modelo de pautas con tres niveles.
En esta sección se enunciarán las pautas en su nivel más elemental. Cada ítem de las pautas
posee documentos anexos que explican en detalle cómo alcanzarla y verificar su cumplimiento,
disponibles en la página de la WAI (Ver las referencias a los vínculos en el glosario).

1.4.1 UAAG: User Agent Accessibility Guidelines

User Agent es todo programa que recupera, reproduce y facilita la interacción entre el
usuario y el contenido [UAAG 2.draft, 2009]. Las pautas de accesibilidad para User Agents
“UAAG 1.0” fueron liberadas en el año 2002 (Existe un borrador de la versión que saldrá en el
año 2010). Apuntan a lograr que los navegadores o cualquier software que interprete contenido
Web no se comporte como barrera.

Conforman un marco de referencia para las empresas que desarrollan tecnología [link:
Testimonials]. HP, IBM, Sun, Opera, Microsoft, Macromedia y otras tantas están en la
necesidad de cumplir los 14 puntos de control (checkpoints) para sus productos:

Algunos de los puntos de control son los siguientes (La numeración no está relacionada
con el código que fijan las UAAG) [UAAG 2.0]:

1. Asegúrese de que la funcionalidad no basada en la Web sea accesible.


2. Asegúrese de que la funcionalidad basada en la Web sea accesible.
3. Dé soporte a las funcionalidades de accesibilidad de las tecnologías que interprete o
muestre.
4. Muestre el contenido acorde con la especificación.
5. Facilite el acceso a la programación por parte de terceros.
6. Provea acceso al contenido alternativo.
7. Permita operar el software con un teclado.
8. Provea acceso a manejadores de eventos.
9. Permita la interacción independiente del tiempo (nota: sin time out)
10. Permita a los usuarios evitar los parpadeos que se presenten.
11. Guarde las preferencias del usuario.

Maia Naftali 82.624 24 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

12. Provea búsqueda en el texto.


13. Provea navegación estructurada.
14. Provea barras de herramientas personalizadas.
15. Ayude a los usuarios a eludir mensajes de alerta innecesarios.

Muchos de los puntos están vinculados con la usabilidad. El foco está puesto en lograr un
software configurable y manejable, que tenga una forma abierta de comunicación mediante
eventos (una API, por ejemplo). Se trata de que las diversas tecnologías asistivas puedan
interactuar con el software sin impedimentos.

1.4.2 ATAG: Authoring Tools Accessibility Guidelines

Una Authoring Tool es una aplicación utilizada para crear, modificar o ensamblar
contenido Web para otras personas. Ejemplos de authoring tools son las herramientas de
blogging, los editores WYSIWYG (Dreamweaver, Frontpage, etc.), las funciones de “Guardar
Como HTML...”, los CMS, y demás aplicaciones que permiten generar páginas Web.

Al igual que en las pautas para User Agents, existe un borrador del documento a liberar
en el año 2010. La versión vigente hasta el momento es la 1.0.

En el documento de ATAG 1.0 se distinguen dos partes: la primera apunta a que el


software sea accesible, guardando la semejanza con las pautas UAAG; la segunda, de particular
interés, pone el foco en que el contenido de la Web generado por el programa sea accesible.
[ATAG 2.0, 2009]
De la segunda parte de ATAG 1.0, los puntos centrales son los siguientes:
1. De soporte a tecnologías de contenido Web que permitan la creación de contenido
accesible.
2. Asista a los usuarios cuando realicen un chequeo de los problemas de accesibilidad.
3. Asista a los usuarios al reparar los problemas de accesibilidad.
4. Asista a los autores a administrar, editar y reusar descriptores de texto para elementos
no textuales.
5. Asista a los autores con plantillas accesibles.
6. Asegúrese de que las acciones para lograr la accesibilidad sean integradas y
promovidas.

Maia Naftali 82.624 25 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

El foco está puesto en brindar asistencia al usuario creador de contenidos. Dado que son
recomendaciones, la redacción es muy genérica porque sólo habla de “asistencia”. Queda en el
criterio de los diseñadores de la herramienta la forma en la cual implementarán dicha asistencia.

1.4.3 WCAG: Web Content Accessibility Guidelines

Las pautas WCAG están dirigidas a quienes generan en contenido para la Web. Consisten
en recomendaciones puntuales, redactadas de una forma menos genérica que el resto de las
pautas anteriores. El foco está puesto en lograr que el contenido sea presentado de forma
accesible. La WAI elaboró guías anexas que explotan cada punto y detallan los pasos a seguir
para implementarlas y cumplirlas. Como se planteó en el capítulo 1.2 de este trabajo, este
modelo de pautas está centrado en el contenido.

1.4.3.1 WCAG 1.0

Es la primera versión de las pautas, y fue liberada en el año 1999. (En la actualidad está
siendo reemplazada por la versión 2.0, pero sigue en uso hasta el momento). WCAG 1.0
Consiste en catorce principios generales de diseño accesible. Cada uno de ellos define un punto
de control sobre el cual el cumplimiento es verificado. Los puntos están priorizados del 1 al 3:
[WCAG 1.0].
Prioridad 1: Debe ser cumplido. Es un requerimiento básico.
Prioridad 2: Debería ser cumplido. Remueve ciertas barreras.
Prioridad 3: Podría ser cumplido. Mejoraría la accesibilidad para ciertos grupos.

Del conjunto de prioridades presentes en el sitio, las pautas definen tres niveles de conformidad:
Nivel A: Todos los puntos de control de prioridad 1 son cumplidos.
Nivel AA: Todos los puntos de control de prioridades 1 y 2 son cumplidos.
Nivel AAA: Todos los puntos de control de prioridades 1,2 y 3 son cumplidos.

Las pautas genéricas para la accesibilidad definidas son las siguientes:


1. Provea alternativas equivalentes para contenido visual y auditivo.
2. Asegúrese de que tanto el texto como los gráficos se puedan ver sin color (modo
monocromático).

Maia Naftali 82.624 26 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3. Utilice maquetado y hojas de estilo para la estructura del documento.


4. Emplee un lenguaje claro en el contenido.
5. Cree tablas que puedan ser interpretadas por los lectores de forma correcta.
6. Asegúrese de que las páginas que contienen elementos de tecnologías nuevas se puedan
ver de forma correcta aún cuando éstas no se encuentren disponibles.
7. Asegúrese de que los objetos móviles o destellantes puedan ser controlados por el
usuario.
8. Asegure la accesibilidad de los objetos embebidos en su página.
9. Utilice un diseño independiente del dispositivo de entrada.
10. Utilice soluciones intermedias hasta que las tecnologías asistivas den soporte al diseño
original.
11. Siga las pautas, y en caso de resultar imposible, provea una solución alternativa paralela.
12. Provea información de contexto que oriente al usuario.
13. Provea mecanismos claros de navegación.
14. Asegúrese de que los documentos son claros y simples.

Existen ejemplos y casos puntuales en cada uno de los puntos, que de cumplirlos, darán un grado
de conformidad global.

La mayoría de las leyes sobre accesibilidad están basadas en el cumplimiento de estas


pautas, pese a la antigüedad que tienen. Existen además herramientas para validar y asistir al
desarrollo de contenidos, también basadas en 1.0.; sin embargo, la evolución de la Web hizo
necesaria una reforma. Esta versión está basada en el HTML y muchas de las recomendaciones
están concebidas según las formas de trabajo del HTML y de las hojas de estilo. Las nuevas
tecnologías para creación de páginas Web, no basadas en HTML, no pasarían la conformidad
más básica de las WCAG 1.0, aún siendo accesibles como se aclaró en la sección anterior.

Sobre WCAG 1.0 fueron creadas normativas regionales, y una gran variedad de software para
validar la accesibilidad de sitios Web.

Maia Naftali 82.624 27 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.4.3.2 WCAG 2.0

La versión más reciente al momento de las pautas WCAG fue liberada en diciembre del
2008 luego de dos años de revisiones y mejoras. El modelo 1.0 tenía el inconveniente de la
dependencia tecnológica. Las pautas hacen mención a “idioms” o prácticas recurrentes de
generación de contenidos.

Si bien el autor puede seguir WCAG y lograr la conformidad máxima, no hay un control
acerca de cómo el usuario está accediendo al contenido. [Kelly et al, 2007]. En diez años la
variedad de plataformas y tecnologías asistivas para acceder a la Web creció, y es necesario
replantear el significado de la conformidad. Los cambios más importantes que trajo la versión
2.0 son la separación tecnológica y la reorganización de las pautas. [WCAGdiff].

Así como WCAG 1.0 posee pautas con puntos de control de prioridades 1, 2 y 3, WCAG
2.0 está organizada en cuatro principios de diseño. Cada uno de ellos contiene pautas, de las
cuales existen tres diferentes criterios de éxito. [WCAG 2.0, 2009].
Los cuatro principios de diseño que siguen las pautas son los siguientes:
1. Perceptibilidad: El contenido debe ser mostrado de modo tal que los usuarios puedan
percibirlo.
2. Operabilidad: Los componentes de la interfaz de usuario y la navegación deben ser
operables.
3. Comprensibilidad: La información y el manejo de la interfaz de usuario debe ser
comprensible.
4. Robustez: El contenido debe ser lo suficientemente robusto como para ser interpretado en
múltiples agentes de usuario y tecnologías asistivas.

El nuevo documento de pautas es más extenso y detallado que su antecesor. Ante el


aumento de la abstracción, fue necesario ampliar cada pauta con un documento anexo que
explica posibles implementaciones. A continuación se mostrará el primer nivel de las pautas, que
se encuentra detallado en el documento original publicado por la WAI.

Perceptibilidad
 Proporcione alternativas textuales para el contenido no textual.
 Contenido multimedia dependiente del tiempo. Proporcione alternativas sincronizadas.

Maia Naftali 82.624 28 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

 Adaptabilidad: Cree contenidos que puedan presentarse de diferentes maneras (como una
composición más simple) sin perder la información ni su estructura.
 Haga más fácil para los usuarios ver y distinguir el contenido, incluyendo la separación
entre primer plano y fondo.

Operabilidad
 Accesible a través del teclado. Haga que toda la funcionalidad esté accesible por teclado.
 Tiempo suficiente. Proporcione al usuario el tiempo suficiente para leer.
 Ataques. No genere contenido destellante.
 Navegable. Proporcione al usuario ayuda a la hora de navegar y localizar el contenido.

Comprensibilidad
 Legibilidad: Haga el contenido textual legible y comprensible.
 Predecible. Cree páginas Web cuya apariencia y operabilidad sean predecibles.
 Ayuda a la entrada de datos. Ayude a los usuarios a evitar y corregir errores.

Robustez
 Compatible. Maximice la compatibilidad con los navegadores y las tecnologías asistivas.

Criterios de éxito ó Requisitos de conformidad para toda la página:

Dentro de cada pauta hay puntos a cumplir con criterios de éxito establecidos, y cada uno una
prioridad que va desde A (básico) hasta AAA.

Nivel A: La página satisface con todas las pautas de nivel A, ó existe una página
alternativa que las satisface.

Nivel AA: La página satisface todas las pautas de nivel A y AA, o bien satisface A y
existe una página alternativa que cumple con AA.

Nivel AAA: La página satisface A, AA y AAA, o bien satisface A, AA y existe una


página alternativa que lo hace con AAA.

Maia Naftali 82.624 29 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

El nivel de conformidad se aplica a páginas completas, tomando todo el conjunto de


puntos de control presentes. Si la página es parte de un proceso, se toma a todo el conjunto que
conforma la secuencia de pasos (Ejemplo, un sitio para ventas por Internet).

Aunque no se especifica una tecnología a adoptar, y la redacción de las pautas es


abstracta, se establece que la misma debe dar soporte para la accesibilidad, o bien, no interferir
con la opción alternativa accesible.
Otro punto central es que las páginas paralelas accesibles permiten cumplir con los niveles
de conformidad. Es decir, se pueden mantener dos versiones de una página (accesible y no
accesible), y aplicar en alguno de los niveles.

Esta medida tuvo detractores, citando a Joe Clarck (Autor de “Building Accesible Web Sites” y
pionero entre los activistas de la accesibilidad) como el más activo de ellos. Se oponía porque
asociaba al contenido alternativo con páginas de texto plano (sin estilo), y argumentaba que de
esa forma no se podría generar la misma experiencia al navegar [Clarck, 2003]. Con la
afirmación “The bottom line is that separate is not equal” (Trad: “La conclusión es que separar
no es igualitario)”, Clarck pretendía evitar una solución que utilice páginas de texto generadas
automáticamente por aplicaciones en los servidores Web. Realizó críticas a WCAG 2.0 aún
cuando estaba en borrador. En la actualidad ya no mantiene actividades en el área de pautas, y se
dedica a proyectos de doblaje de audio.

La separación de incumbencias que trae WCAG 2.0 (Percepción, Comprensión,


Operación, Robustez) mitiga los argumentos en contra de permitir páginas en paralelo que sean
accesibles. Es una medida consistente con la abstracción tecnológica del modelo.

1.4.3.3 Evaluación ó Verificación del cumplimiento de las pautas para contenido

La WAI desarrolló un conjunto de procedimientos para evaluar el cumplimiento de las


pautas para accesibilidad Web. Además de que cada punto de control (checkpoint) posee un
criterio de éxito, se toma al conjunto de páginas para realizar la revisión y calificar con A, AA ó
AAA [EvaluatingAccesibility].

Maia Naftali 82.624 30 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

WCAG 1.0 es más simple de evaluar por estar basada en el HTML y tener criterios de
éxito puntuales. Existen validadores automáticos que realizan el trabajo de verificar cada punto
de las pautas. Dentro de los más conocidos: Bobby, TAW, Hera. Una de las principales críticas
al modelo WCAG 2 es la mayor dificultad para evaluar las pautas que no dependen de una
tecnología específica. Fue una debilidad muy criticada cuando circularon los primeros
borradores. En consecuencia, la WAI puso el esfuerzo en generar documentos detallando y
explicando cada pauta y sus criterios.

El proceso de evaluación de las pautas propuesto por WCAG 2.0 requiere de la


intervención de un grupo de personas. Las herramientas automáticas fallan a la hora de detectar
barreras que provienen de la percepción.

Por otra parte, el cumplimiento de las pautas y el aseguramiento de la accesibilidad no


están directamente asociadas. El paso inductivo hacia la accesibilidad es cuestionable: el
cumplimiento de las pautas no garantiza en la totalidad de los casos que la página sea accesible
[Sloan et al, 2006]; como se mostró, una página con tecnologías no contempladas por las pautas
WCAG 1.0 también puede ser accesible pese a no cumplir los criterios de conformidad.

“Cumplimiento de Pautas” No implica “Accesibilidad”


Una excepción frecuente es la legibilidad del contenido. Las pautas expresan que el contenido
debe ser legible y comprensible, y proporcionan técnicas para conseguirlo. No obstante, el
criterio de éxito de este punto consiste en un desafío respecto de su evaluación. Se puede generar
contenido comprensible para un cierto grupo de usuarios, pero es incorrecto generalizar hacia
todos los demás grupos sin haberlo probado.

“Accesibilidad” No implica “Cumplimiento de Pautas”


David Sloan, Brian Kelly y equipo en su trabajo “Contextual Web Accessibility” traen el
contraejemplo de un sitio Web educativo (E-Learning) que debe ser accesible para ciertos grupos
de usuarios. Demostraron que con el enfoque tradicional de las pautas no podían reproducir la
misma experiencia: El texto alternativo sobre el ejercicio de examen otorgaría al usuario indicios
de la solución. Era necesaria otra técnica para lograr el entendimiento de dicha imagen, que por
carecer de texto alternativo, podría no cumplir con la conformidad

Maia Naftali 82.624 31 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Se puede afirmar solamente que el cumplimiento de las pautas empleando las técnicas
recomendadas garantiza la accesibilidad en la mayoría de los casos. Para contemplar al resto es
necesaria una validación más profunda. Los procesos de evaluación recomendados por la WAI
sugieren la formación de grupos heterogéneos de individuos para realizar las pruebas de
accesibilidad. Mejorando el tipo de pruebas es posible ampliar el grupo de usuarios para los
cuales la página es accesible.

En el segundo capítulo de éste trabajo se profundizará sobre la evaluación de páginas, y su


relación con la accesibilidad de las páginas Web.

1.4.4 Análisis del modelo de pautas

Las pautas para accesibilidad en la Web de la WAI conforman un estándar de hecho en la


actualidad. A pesar de su amplio alcance, existen estudios sobre diversos enfoques para
implementar las pautas en la práctica.

Como sucede con todos los modelos de referencia (por ejemplo ITIL ó CMMI), existe un
brecha entre la definición y la aplicación de los mismos.
Tanto CMMI como WCAG indican cuáles son las buenas prácticas a seguir para lograr un
objetivo, salvando la escala. El problema que presentan ambas es que, en el afán por lograr la
conformidad, se pierde de lado ese objetivo inicial.

La estrategia a adoptar debería incluir un análisis previo de las necesidades, y el


involucramiento de los usuarios críticos. La decisión acerca del nivel de conformidad a alcanzar
está determinada por los usuarios finales y la criticidad del contenido. Esto se contrapone a la
adopción de las pautas como una “receta de cocina”.

El enfoque holístico: modelo del Tangram

Sobre la problemática anterior, Brian Kelly, David Sloan y equipo plantean un enfoque
original sobre las pautas [Sloan & Kelly, 2006], llamado el “Enfoque Holístico” (An Holistic
Approach). (En [Thatcher et al, 2006] se induce a una idea similar, resaltando que lo más
importante es la presencia del usuario, y no tanto la conformidad con las pautas).

Maia Naftali 82.624 32 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

El propósito del enfoque es proveer una solución que maximice la utilidad hacia el
usuario final, en contraposición a la metodología basada en WAI que alienta a la aplicación
obligatoria de un conjunto limitado de pautas. La metáfora del Tangram fue hecha para aclarar
que las soluciones más apropiadas pueden ser obtenidas involucrando al usuario, en lugar de
aplicar las reglas [Sloan et al, 2008].

Diagrama 1.4.4: Gráfico del modelo del Tangram para desarrollo Web [Kelly et al, 2008]

El Tangram es un juego de siete piezas cuyo objetivo es formar figuras usando todas las piezas, y
la metáfora con este modelo de accesibilidad es que una figura se puede armar como suma y
combinación de partes.
Los autores partieron de la necesidad de proveer un conjunto de pautas más amplio y flexible.
Sería el desarrollador o el creador de contenido quien elegiría el subconjunto de las pautas a
aplicar según el contexto. Esto permitiría reutilizar las adaptaciones en contextos similares.
Las soluciones más adecuadas pueden obtenerse mediante la participación de los usuarios, en
lugar de limitarse a la aplicación de normas.

Dentro de las características de este planteo, se destacan:


- Es extensible.
- Alcanza la accesibilidad en IT, sin limitarse a la Web.
- Se puede implementar bajo muchas normativas,
- Tecnológicamente neutral.
- Proporciona una forma más realista de asegurar la accesibilidad.

Maia Naftali 82.624 33 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Una posible implementación de un modelo sobre WCAG

En el trabajo titulado “A Framework for Filtering Web Accessibility Guidelines”


[Baguma et al, 2009], se realiza una implementación práctica derivada del modelo del Tangram.
Las pautas para la accesibilidad del contenido son filtradas por cuatro aspectos. El desarrollador
debe indicar el tipo de discapacidad que afecta a los usuarios, qué nivel de información desea
obtener (técnica, consejos, explicación), qué contexto de uso (navegación, interfaz) y con qué
profundidad se mostrará la información solicitada.
Ingresando esos datos el desarrollador accede a la información sobre las pautas de forma
ordenada y limitada. Esto facilita su implementación y a la vez asegura la accesibilidad en esos
aspectos fijados por la matriz del filtro.

Maia Naftali 82.624 34 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.5 Las normativas de Accesibilidad Web


1.5.1 Antecedentes

Muchos países adoptaron las pautas para contenido del consorcio W3 bajo un marco
legal. Tomando parte de las pautas para contenido WCAG 1.0, se crearon leyes para garantizar la
accesibilidad Web de los sitios en esa jurisdicción [Thatcher et al, 2006].
Los antecedentes de este movimiento sucedieron alrededor del año 1995 tanto para la Unión
Europea como para los Estados Unidos.

La primera legislación sobre accesibilidad general en los Estados Unidos fue “American
and Disabilities Act”, conocida como ADA, y data del año 1992. Abarca al trabajo, la
construcción, la educación, el transporte, las comunicaciones (en donde se incluiría la
accesibilidad en la Web), la recreación, la salud y demás servicios. En ese momento el alcance de
Internet era limitado y la Web era mucho menos gráfica, por lo tanto garantizar la accesibilidad
no requería del soporte pautas ni lineamientos técnicos complejos. Para el año 1998, los Estados
Unidos adoptan la “Section 508”, que es la primera normativa específica para accesibilidad Web
de ese país [Paciello, 2002].

La Unión Europea inició diversos proyectos en el año 1994. A través de la entidad


“Information Society for All”, lanzada por la Comisión Europea en el año 1999, se iniciaron
acciones para liberar normativas que regulen la accesibilidad Web. Los planes de acción
“eEurope 200X”, basados en WCAG, alcanzan a los sitios del sector público. Por otro lado,
existe el “WAB Cluster”, entidad que se encarga de la evaluación y el monitoreo de los sitios
Web de todos los países, generando informes y métricas actualizadas [Thatcher et. al, 2006].

1.5.2 Normativas particulares

Section 508

En el año 1998 el congreso de los Estados Unidos promulgó el “Rehabilitation Act” para
exigir que los organismos oficiales hagan su tecnología de la información accesible para las
personas con discapacidad. La ley aplica para todos los organismos oficiales cuando desarrollan,
mantienen o utilizan de la electrónica y la tecnología de la información. Bajo esta ley, se debe
otorgar a empleados con discapacidades y demás miembros acceso público a la información
[Wikipedia Section 508].

Maia Naftali 82.624 35 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Section 508 está dirigida al cumplimiento legal a través del proceso de investigación de mercado
y contratación pública. Además tiene estándares técnicos para poder comparar y evaluar la
conformidad de los productos. Esta ley no aplica para páginas Web privadas, excepto que
reciban fondos federales o estén bajo un contrato de la agencia federal. Todos los proveedores
del estado la deben cumplir.

Reseña de los puntos centrales de la ley:


Aplicaciones de software y sistemas operativos: incluye accesibilidad para personas no videntes
garantizando el de soporte de tecnologías asistivas y pautas de diseño accesible.
Intranets y Aplicaciones Web: asegura la accesibilidad Web, utilizando pautas similares a
WCAG 1.0.
Telecomunicaciones: se enfoca en la accesibilidad para personas no oyentes o con hipoacusia.
Abarca la compatibilidad con teletipos (TTY), audífonos y demás tecnologías para mejorar la
audición.
Video y Multimedia: Incluye requerimientos para el subtitulado.
Productos cerrados o independientes: Se exige a los productos cerrados como fotocopiadoras,
impresoras y faxes, a incorporar la accesibilidad en su diseño.
Computadoras portátiles y de escritorio: Abarca la accesibilidad para usuarios con problemas de
movilidad. Requiere la posibilidad de incorporación de controles para operarla, como pantallas
táctiles, teclados especiales y comandos por voz.

Como WCAG 1.0 no fue desarrollada según el marco legal no fue posible que los Estados
Unidos lo adoptasen como estándar. Sin embargo, US Access Board reconoció que deberían
trabajar en conjunto con la WAI para lograr una ley que tome las últimas pautas para la
accesibilidad en vigencia.

Un punto a tener en cuenta es que Section 508 abarca sólo una fracción de las pautas
WCAG. Es necesario cumplir además con pautas no contempladas para otorgar accesibilidad a
una mayor cantidad de grupos [Thatcher et al, 2006].

Maia Naftali 82.624 36 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Unión Europea: eEurope

La iniciativa “eEurope – Una sociedad de la información para todos” fue lanzada en el


año 1999. En el plan de acción del año 2002 fueron incluidos aspectos de la accesibilidad Web.
A diferencia de lo que sucede con Section 508, la enmienda de la ley de los Estados Unidos,
eEurope emplea abiertamente las pautas de la WAI [eEuropeSidar]. Para el año 2001, se exigía a
las páginas Web de la administración pública cumplir con conformidad A de WCAG 1.0.
[eEurope]

En la declaración Ministerial de Riga, año 2006, se fijó que en el año 2010 todos los sitios
públicos deben se accesibles. En dicha declaración se enfatizan los puntos que deberían seguirse,
y se recomiendan políticas a seguir por la Unión Europea para difundir la accesibilidad Web.
Actualmente se están migrando las pautas hacia WCAG 2.0.

Además de mantener el tema en su agenda, la Unión Europea dispone de un laboratorio


para medir la accesibilidad global de forma automática. También a través de la UWEM (A tratar
en el capítulo II), proveen a los gestores de contenido Web de un proceso estudiado para probar
la accesibilidad de los sitios Web.

Maia Naftali 82.624 37 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.6. El problema de la creación de sitios Web accesibles

En esta sección serán tratados temas en torno a la problemática de la creación de páginas


Web accesibles. En la actualidad, la generación de contenido para Web es por defecto no
accesible. Lograr ese estado requiere un esfuerzo importante por parte de quienes intervienen en
la elaboración de la página. La dificultad para recorrer el camino hacia la accesibilidad explica
los pobres resultados en el campo, y la falta de madurez de las técnicas para el aseguramiento.

1.6.1 Los Mitos de la accesibilidad Web

La mayoría de los mitos tienen origen en el avance de las tecnologías. Como se mencionó
anteriormente con las barreras, una implementación tecnológica nueva puede solucionar algunos
problemas del pasado.

Mito 1: Ofrecer una alternativa de sólo-texto hace a la página accesible.

Es falso, dependiendo de cómo se ubique el vínculo a esa página de texto puro. Puede ser una
barrera para personas con problemas cognitivos si fuera difícil de encontrar. Por otro lado, las
versiones de texto sin marcas o etiquetas no ofrecen una experiencia cómoda para quienes
acceden por lectores de voz sencillos como JAWS.

Mito 2: La accesibilidad hace que los sitios no sean visualmente atractivos

Es falso, y surge de la mala interpretación de las pautas desde la restricción absoluta. En WCAG
1.0 era común pensar en que no había que usar JavaScript; sin embargo, la pauta literalmente
decía que había que asegurarse de que los elementos como scripts ó applets se mostraran aún sin
disponer de soporte. En la actualidad la mayoría de las tecnologías ofrece mecanismos para
lograr la accesibilidad.

En “Accessibility and design, a failure of the imagination” [Regan, 2004], Bob Regan
analiza las causas por cuales hasta ese momento, el diseño y la accesibilidad no iban de la mano.
Regan sostiene que la compatibilidad entre los mundos requiere un cambio de paradigma por
parte de los diseñadores. El mundo del diseño se genera desde lo visual, y es necesario salir de él
para poder reproducir las experiencias desde los otros sentidos. La conclusión que extrae es que

Maia Naftali 82.624 38 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

los diseñadores perciben la estandarización como una restricción a su creatividad, y que no


existen motivos técnicos para separar la accesibilidad del diseño.

Mito 3: La accesibilidad es complicada y costosa

Es un mito que va a tender a desaparecer con el desarrollo de las tecnologías y las herramientas.
La WAI plantea una serie de beneficios, que incluyen a la mejora en el posicionamiento de los
buscadores, y a la posibilidad de que el sitio sea visto por una mayor cantidad de visitantes.

Se enuncian algunos beneficios vistos desde la lógica del negocio, pero lo cierto es que
existe un costo inicial en los proyectos accesibles. Se utilizan para capacitación, implementación
de pautas y pruebas con usuarios.

Mito 4: Las herramientas de evaluación pueden determinar si es accesible o no una página

Es falso. Como se verá en la segunda parte del trabajo, las herramientas sólo pueden verificar la
presencia o ausencia, pero no el sentido. Es necesario involucrar a personas en el proceso de
evaluación.

1.6.2 El camino para lograr contenido Web accesible

Una gran parte de la bibliografía recomienda seguir algunas prácticas y estándares de


codificación, con el fin de lograr conformidad con las pautas.
Se alienta a que desarrolladores y diseñadores cambien sus prácticas habituales de desarrollo y
generación de contenidos. Luego del cambio, se sugiere realizar una validación automática con
alguna herramienta que verifique las pautas, que además informará qué puntos están siendo
violados de las WCAG. El paso siguiente será entonces corregir y depurar la página, hasta
obtener el grado de conformidad con WCAG deseado. (Existen métodos más formales para el
testeo de la página tratados en la segunda parte, aunque lo usual es asociar este proceso a
herramientas automáticas).

Este enfoque puede que genere contenido accesible, pero demanda un alto grado de
conocimientos y compromiso, y no siempre soluciona la totalidad de los problemas de
accesibilidad.

Maia Naftali 82.624 39 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

La llamada Web 2.0 es una denominación (utilizada por el marketing, entre otros) para
caracterizar la tendencia creciente a la generación de contenidos por parte de los usuarios. Siendo
la Web una estructura creada por gente de conocimientos heterogéneos, la imposición de un
proceso como el anterior para alcanzar la accesibilidad difícilmente triunfe. Se requieren
capacidades técnicas que no se le pueden exigir a la comunidad, y eso atentaría contra el ideal de
la Web de Tim Berners-Lee [Byrne, 2009].

Aún así, el cumplimiento de las pautas es la forma empleada en la actualidad para lograr
contenido accesible. La mayoría de las fuentes recomiendan implementar la accesibilidad de esa
forma [Thatcher et al, 2006 & Paccielo 2002]. En contraposición se mostró el modelo del
Tangram, que propone adoptar grupos de pautas con criterios fijos marcados por los objetivos a
cumplir.

Maia Naftali 82.624 40 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.6.3 Dificultades que se presentan

En el siguiente diagrama de Ishikawa se resumen las causas que dificultan la implementación de


la accesibilidad en la Web. Cada nodo representa una posible causa del hecho central.

Diagrama 1.6.3: Dificultad en la implementación de una Web accesible.

Detalle de los recuadros:


I. Tecnologías: Abarca a aquellas empleadas para generar, mantener ó visualizar el
contenido de la Web.
II. Estrategias: Es el conjunto de pautas y prácticas que se aplican para eliminar las barreras
III. Personas: Son todos los individuos que generan contenido para la Web
IV. Empresas: Incluye tanto a las empresas que elaboran artefactos de software relacionados
con la Web, como aquellas que usan la Web como plataforma para sus negocios.
V. Normativas: Son todos los cuerpos de leyes que garantizan la accesibilidad en una
jurisdicción.
A continuación se analizará la incidencia de cada causa presente en el diagrama.

Maia Naftali 82.624 41 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

I. Tecnologías
a. Escalamiento poco aprovechado
Gran parte de las barreras relacionadas al contenido podrían ser eliminadas si se delegara
parte de la responsabilidad en el software que lo presenta. El contenido puede dar
información a componentes que se ocupen de presentarlo minimizando el impacto de las
barreras y mejorando la interacción con las tecnologías asistivas. Windows Presentation
Foundation, implementado además en “Mono Accessibility Project”, aplica parte de este
concepto con los descriptores de los objetos. Colocando una etiqueta a cada elemento,
hay un intermediario (UI Automation) que se encarga de identificarlo y proveer
información para que las tecnologías asistivas puedan mejorar el acceso.

b. Incompatibilidad
El software para utilizar una computadora, acceder a la Web o publicar contenidos
(Sistemas operativos, navegadores, herramientas, componentes o plug-ins) se actualiza
con frecuencia en todos sus aspectos, incluyendo el soporte para la accesibilidad. Sin
embargo, las tecnologías asistivas poseen un ciclo de vida más largo, especialmente
aquellas que son por hardware debido su alto costo. Este desfasaje redunda en nuevas
barreras temporales para las tecnologías incompatibles al estándar del momento.

c. Mal uso de la tecnología o del estándar para crear páginas


Muchas herramientas para crear contenido permiten incorporar elementos a la página que
atentan contra la accesibilidad Web.; Desde sitios no-HTML, hasta animaciones, sonidos
y gráficos destellantes. En general se provee una forma de realizar un diseño accesible,
pero no es el método por defecto.

Productos como Adobe Dreamweaver o Visual Studio por ejemplo, poseen validadores
de pautas WCAG en sus versiones más recientes. Pese a que informan sobre eventuales
barreras, su eliminación depende de cómo el usuario lo interprete y resuelva.

Maia Naftali 82.624 42 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

II. Estrategias
a. Proceso de evaluación inmaduro
La evaluación o testing de las páginas Web es un proceso aún inmaduro. Hay
metodologías como UWEM, tratada en el segundo capítulo, que definen casos de prueba
y pasos estandarizados para probar la accesibilidad de un sitio. Por otro lado existen
programas tanto por Web como aplicaciones de escritorio, llamados herramientas
automáticas, que realizan pruebas de accesibilidad a las páginas Web.

El inconveniente es que todas ellas aseguran la conformidad con las pautas, y se confunde
ese cumplimiento con la ausencia de barreras. Tanto la metodología de evaluación hecha
por la WAI como aquella propuesta por UWEM sugieren que parte del testing sea
realizado de forma manual. Por otra parte, existe una línea diferente que sostiene que la
evaluación debería enfocarse en la detección de barreras, y no en la conformidad con las
pautas.

El proceso de evaluación es crítico, y se debería disponer de técnicas más simples y


estandarizadas con indicadores directos. En el capítulo II se tratará con detalle este
problema, analizando las métricas que se proponen y su significado.

b. Reinvención de la rueda
La reinvención de la rueda es una expresión que se utiliza cuando se estudian soluciones a
problemas que fueron resueltos con anterioridad. En el caso puntual de las estrategias en
el campo de la accesibilidad hay una permanente reinvención de la rueda. Un sitio Web
puede tener un desarrollo único e irrepetible, al igual que todo proyecto. En consecuencia,
la implementación de pautas de accesibilidad en ese sitio sería sólo aplicable en esa única
instancia.

Para que puedan existir procesos que eviten esta “reinvención“, es necesario encontrar
una serie mínima de pasos que al ejecutarlos resuelvan todos los problemas de
accesibilidad.

Maia Naftali 82.624 43 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

i. Procesos artesanales
El proceso de hacer un sitio accesible es una tarea mayormente artesanal al
momento. En la sección anterior se propuso un enfoque alternativo que ataca este
problema, pero aún no tiene su correlación en la práctica. La forma de hacer sitios
accesibles cumpliendo pauta por pauta hasta la conformidad es un proceso repetitivo con
una fuerte intervención humana.

ii. Falta de patrones


Al momento, el uso de patrones y frameworks estandarizados para desarrollo son
conceptos teóricos del cual hablan algunos trabajos de investigación [Baguma et al &
Lopes, 2009], pero no tiene su correlación en la práctica.

Los trabajos están basados en la incorporación de ontologías de Web semántica


[Lopes et al 2009]. A través de Semantic Accessibility Assessment Framework (SAAF),
los desarrolladores de contenidos son provistos de elementos Web bien implementados
que construyen sitios accesibles por defecto.

El trabajo de Baguma (Web Design Framework for Improved Accessibility for


People with Disabilities (WDFAD)) plantea un modelo teórico que aplica en
requerimientos no funcionales (NFR) las necesidades de una Web accesible, y limita la
construcción y el cumplimiento de las pautas de acuerdo al nivel deseado.

c. Complejidad de las soluciones

Como se plantea en [Sloan et al, 2007], existen experiencias que requieren el planteo de
una presentación diferente. Se pone como ejemplo un sitio de aprendizaje, en donde
usuarios con baja visión debían navegar por un examen sin que la herramienta les dijera
la respuesta. La solución a este tipo de dilemas es compleja. Lo mismo ocurre con sitios
de imagen corporativa, videos y elementos multimediales.
Por otro lado, el contenido que tiene derechos de autor puede no ser accesible si posee
protección de la propiedad intelectual

Maia Naftali 82.624 44 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

d. Foco en el contenido
La mayor parte de la atención en el tema se centra en regular el contenido, y no tanto el
resto de los aspectos. Muchos planes de acción involucran mejoras desde este aspecto,
olvidando que el contenido de la Web es generado por millones de usuarios.
Una posible salida es el escalamiento hacia las herramientas de desarrollo y creación de
contenidos.

III. Personas

Existe una idea en el medio, de que gran parte del problema con la accesibilidad
en la Web es causado quienes generan el contenido. Los seguidores de esta línea de
pensamiento centran la responsabilidad en las personas.
La causa atribuida es la falta de compromiso y responsabilidad de quienes hacen páginas
Web. Dentro de ese encuadre, proponen como solución la necesidad en educar a quienes
generan el contenido en buenas prácticas sobre accesibilidad.

Esta visión no contempla el problema de forma global. Teniendo en cuenta de que


el contenido se genera desde múltiples fuentes, sólo se involucraría a las personas que
desarrollan en lenguajes de marcado o programación. Por otra parte, imponer un estándar
de facto a los millones de creadores de páginas es un proceso de escala astronómica.
Requiere cambiar la cultura de una forma radical, y los procesos no están preparados para
que la transición sea fácil. Por el contrario, la incorporación de la accesibilidad puede ser
vista como una carga que insume tiempo y esfuerzo.

a. Desconocimiento
Un estudio realizado en Brasil a 600 personas generadoras de contenido [Freire,
2009] mostró que sólo el 20% de los encuestados tenía conocimientos sobre la
accesibilidad. La encuesta estaba dirigida a un público del cual el 54% tenía maestrías ó
doctorados en su haber. El estudio además dio a conocer que cerca del 20% de los
individuos aprendieron sobre accesibilidad dentro de un aula (y sólo el 20% lo hizo por su
cuenta).

Maia Naftali 82.624 45 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Un dato a destacar es el siguiente: cerca del 73% de los encuestados respondió


que conocía o había escuchado acerca de cómo las personas con ceguera utilizaban la
Web, pero no sabía cómo generar sitios accesibles para ellos.
La encuesta deja ver que no es una falta de voluntad, sino un desconocimiento
generalizado.

b. Poca difusión de la accesibilidad Web


El estudio realizado en Brasil [Freire, 2009] arroja que la accesibilidad es un tema poco
difundido aún en el ambiente universitario. No existen estudios similares a nivel nacional,
y así como tampoco existen al momento políticas que promuevan la creación de sitios
accesibles.

c. Dificultad en la comprensión del proceso


El proceso de crear sitios accesibles partiendo de las pautas no es adecuado para todos los
potenciales generadores de contenidos.
En el año 2004, Bob Regan (Accessibility Manager de Macromedia) analizó la relación
entre la accesibilidad Web y los diseñadores gráficos. Ellos sentían que la imposición de
estándares de accesibilidad limitaba la creatividad, y resultaba en páginas aburridas y
poco vistosas. Regan encontró que los diseñadores eran personas “visuales” entrenadas
para concebir la interfaz gráfica desde ese lugar, y les costaba pensar en experiencias de
navegación Web diferentes a la interacción gráfica con mouse. En su compañía le llevó
varias sesiones hacer que comprendan el proceso de crear páginas accesibles [Regan,
2004].

d. Información de difícil acceso


Como se mencionó junto con los mitos, hay una gran parte de la información
sobre accesibilidad Web que no es correcta o está desactualizada. Otra gran fracción de
las fuentes posee un lenguaje que requiere conocimientos técnicos, o no es apropiada para
personas poco afines con la lectura de estándares.
En el sitio de la WAI están publicados los documentos de las pautas y estándares. Si bien
allí se proporciona información precisa y ordenada, se exige un alto compromiso del
lector. Sería poco aplicable imponer su lectura a todos aquellos que quisieran desarrollar
una página accesible simple.

Maia Naftali 82.624 46 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

IV. Empresas

a. Fuera de sus objetivos


Al margen de las normativas regionales que adopta cada país, la accesibilidad no
es un parámetro de calidad según las normas ISO. Al carecer de una motivación ú
obligación específica, tiende a ser un objetivo relegado por quienes construyen sitios
Web.

b. Visión basada en utilidades


Como toda industria, la ingeniería del software tiene un ojo puesto en la renta. Encarar un
proyecto que involucre a la accesibilidad puede ser costoso en tiempos si los equipos de
trabajo no conocen las técnicas.

Existen beneficios adicionales, pero difícilmente generen el retorno suficiente como para
que muchos empresarios lo incluyan en su análisis. En el caso de sitios masivos como
diarios, buscadores y portales, la accesibilidad significa una mayor cantidad de visitas y
por consiguiente una mejora en el valor de esa página.

c. Tiempo o presupuesto acotados


Las páginas Web encaradas como proyectos dentro de la industria del software poseen
limitaciones de tiempo, presupuesto y funcionalidad. Si el cliente no solicitara que la
accesibilidad sea garantizada, y la misma no formara parte de la política de calidad de la
empresa a cargo del desarrollo, difícilmente ésta sea tomada como un requisito a cumplir.

V. Normativas

a. Sólo existen en algunos países


Al momento existen países que no tienen leyes de accesibilidad sancionadas, como la
Argentina, siendo su eficacia un tema a debatir.

b. Atraso con respecto de la tecnología


La mayoría de las leyes de accesibilidad al momento (jul.-2009) [Thatcher et al,
2006] están basadas en WCAG 1.0. Al salir un nuevo estándar las leyes deberían ser

Maia Naftali 82.624 47 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

modificadas. Desde que los estados las promulgan, hasta que los proveedores generan
contenido bajo dichas leyes, corren el riesgo de quedar obsoletas.
Al margen de la utilidad y de las controversias acerca de tener una ley, el problema del
atraso agrega un factor en contra de implementar la medida.

Maia Naftali 82.624 48 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

1.7 Estado del arte:

En diez años de existencia, las pautas de accesibilidad Web no lograron imponerse como el
estándar de facto. El foco actual, centrado en el contenido, demostró que no contribuye a lograr
progresos en el campo.

La generación de contenido accesible sigue siendo un proceso complejo, ya que requiere que los
creadores reciban una preparación específica en estándares y cambien su método de trabajo.

Los estándares de accesibilidad han progresado, y en la actualidad las pautas WCAG 2.0 son
independientes de la tecnología. Este mayor nivel de abstracción le permite lograr conformidad
con tecnologías diferentes al HTML.

Sería más natural lograr que por defecto las páginas Web posean una baja cantidad de barreras,
sin efectuar cambios radicales en la forma en que esas páginas son construidas.

1.7.1 Líneas de investigación en la actualidad

Web Semántica y metadata


Se investiga la incorporación de un sistema de metadatos por detrás de la página, que incluya una
base de conocimientos. Al solicitar una página, el usuario contaría con información extra que le
permitiría mejorar la experiencia. Este tipo de sistemas es llamado “Accessibility Commons”. Su
actual desafío es estandarizar el formato de los datos por detrás y proveer de herramientas para
desarrollar bajo esta infraestructura [Kawanaka et al, 2008].

Frameworks y herramientas

Se investiga la creación de componentes accesibles que se integren a las herramientas de


creación de páginas. Dichos componentes se adaptarán al contexto de uso, permitiendo cierta
flexibilidad en el cumplimiento de las pautas [Baguma et al, 2009].

Maia Naftali 82.624 49 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo II:

Los Métodos de Evaluación de la


Accesibilidad Web

Maia Naftali 82.624 50 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo II: Los Métodos de Evaluación de la Accesibilidad


Web

2.1 Evaluación de sitios Web

2.1.1 Introducción al proceso de evaluación de accesibilidad

El proceso de evaluación, también conocido como proceso de prueba o “testing”, es una práctica
de la ingeniería del software que permite relevar la calidad de un determinado artefacto
[WikipediaSWTest]. Aplicado a sitios Web accesibles, tiene como objetivos particulares
detectar fallas que le impidan al sitio ser accesible.

De la información recolectada en la evaluación, es posible: 1) Optimizar recursos como tiempo,


esfuerzo, infraestructura, gente. 2) Apuntar a resultados predecibles y controlables. 3) Dar
soporte a procesos sustentables y repetibles. 4) Estandarizar el contenido y el formato de los
reportes. Muchos estudios han demostrado que los métodos de evaluación generan resultados
diferentes, dependiendo del evaluador [Brajnik, 2008a].

Brajnik define a los métodos de evaluación de la accesibilidad Web (AEM) como


procedimientos orientados a la búsqueda de problemas de accesibilidad, tales como violación a
las pautas, fallas, defectos y otros índices de los usuarios” [Brajnik, 2008b]. Un AEM:

• Define qué pasos, decisiones, criterios y condiciones serán usadas para detectar
problemas a la accesibilidad
• Podría definir cómo clasificar y priorizar problemas (en términos de severidad o
impacto).
• Podría definir cómo agregar información sobre problemas y cómo generar reportes o
informes.
• Podría definir cómo seleccionar una muestra de sitios para evaluar.

Existen tres enfoques diferentes de evaluación de la accesibilidad:


1) Pruebas de conformidad con las pautas
2) Pruebas para detección de barreras
3) Pruebas de monitoreo automatizado sobre una muestra

Maia Naftali 82.624 51 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Las pruebas de conformidad consisten en la verificación y la validación de cada ítem propuesto


por la pauta elegida. Estas pruebas asumen que si todas las pautas son cumplidas, la página en
cuestión será accesible. Incluyen a modo de validación pruebas con usuarios y tecnologías
asistivas para validar. El objetivo final es detectar puntos no cumplidos para que las páginas
involucradas sean reparadas.

Las pruebas de detección de barreras [Brajnik, 2008c] apuntan a la detección de posibles puntos
en los cuales una página podría no se accesible. Es un proceso completamente manual,
independiente de la pauta elegida, que fue propuesto por el investigador Giorgio Brajnik en una
serie de trabajos sobre calidad de sitios Web accesibles. El objetivo de esta prueba es identificar
tanto las barreras como su impacto, y poder eliminarlas una vez priorizadas.

Las pruebas de monitoreo automatizado generan un ranking entre páginas de una muestra,
midiendo el grado de accesibilidad en términos relativos. Estas pruebas son ejecutadas por los
laboratorios del WABCluster, y tienen como objetivo medir de forma cuantitativa el grado de
accesibilidad global en una región a lo largo del tiempo. Utilizan la conformidad con las pautas
como medida para realizar las comparaciones.

2.1.2 Técnicas de evaluación propuestas por la WAI y su alcance

Corresponden al grupo de “Pruebas de conformidad”. El proceso de evaluación propuesto por la


WAI provee un procedimiento genérico que aplica a los diferentes estados del ciclo de vida de
una página Web [Evaluating Accessibility].
Dependiendo de la profundidad de la evaluación, se proponen diferentes técnicas a emplear, que
se enunciarán a continuación:

2.1.2.1 Revisión preliminar (Preliminary Review)

El objetivo del proceso es la rápida identificación de problemas de accesibilidad en sitios Web.


Este método no es suficiente para determinar si conforma o no con las pautas. Combina técnicas
manuales sobre páginas representativas, junto con el uso de herramientas semi automáticas para
la evaluación de la accesibilidad. Las cinco tareas que propone:
o Selección de una muestra representativa de páginas.

Maia Naftali 82.624 52 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

o Evaluación con navegadores gráficos (IE, Firefox, Opera, Safari, etc.).


o Evaluación con navegadores especiales (de voz, textuales, etc.).
o Uso de herramientas de validación automáticas.
o Resumen de los resultados, y pasos a seguir.

2.1.2.2 Evaluación de conformidad (Conformance Evaluation)

Una evaluación de conformidad determina si una página Web cumple o no con los estándares de
accesibilidad, como las pautas WCAG. Combina técnicas automáticas, semi automáticas y
manuales de pruebas para sitios accesibles. Se enfoca en la evaluación técnica, y no involucra a
usuarios con discapacidad. Los pasos propuestos:
o Determinar el alcance.
o Elegir herramientas de evaluación automáticas.
o Realizar una evaluación manual de los sitios más representativos.
o Utilizar navegadores gráficos y especiales sobre esa muestra.
o Leer y evaluar el contenido textual para asegurar la comprensibilidad.
o Realizar un resumen de los resultados, y especificar las barreras encontradas y sus
soluciones.
Se diferencia con el anterior en el nivel de detalle de cada prueba. El alcance va a determinar la
exhaustividad de los tests a realizar.

2.1.2.3 Criterios de evaluación para contextos específicos (Approaches for


Specific Content):

Describe las consideraciones para evaluar sitios largos y complejos, durante el proceso de
desarrollo. Se centra en tratar las excepciones (monitoreo ante cambios, sitios con tecnologías
antiguas y sitios dinámicos). A continuación se resumirán los puntos centrales del proceso.
Para desarrollo:
o Establecimiento de requerimientos claros para el nivel de conformidad a alcanzar.
o Inclusión del tema en la planificación inicial.
o Asignación de tiempo de proyecto a la revisión.

Maia Naftali 82.624 53 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

o Provisión de información sobre el tipo de evaluación, para permitirle a los


desarrolladores ejecutar parte de la misma por sus propios medios.

Para monitoreo continuo:


o Establecimiento de requerimientos para el nivel de conformidad a alcanzar.
o Identificación de los individuos responsables del monitoreo. Seguimiento de las
actividades.
o Incorporación de feedback (intercambio de opiniones) en el sitio.
o Uso de herramientas automáticas.
o Creación de procedimientos para validar y evaluar páginas y cambios antes de
subirlos al ambiente productivo.

Para sitios dinámicos:


o Evaluación de los templates o plantillas generadoras del contenido HTML.
o Evaluación de la capacidad del Content Management System (CMS, generador de
contenido) al generar páginas, validando pautas ATAG.

2.1.2.4 Selección de herramientas de evaluación automáticas (Selecting a tool)

Las herramientas de evaluación automatizadas son programas o servicios online que ayudan a
determinar si un sitio es accesible. Se enumeran las ventajas y desventajas en el uso de
herramientas según la WAI:
Ventajas:
• Reducen el tiempo y el esfuerzo requerido en la ejecución de evaluaciones de
accesibilidad.
• Pueden ayudar en la eliminación de barreras, proporcionando consejos y soluciones
comunes.
• Ayudan a determinar la conformidad con cada punto de las pautas de forma automática.

Desventajas:
• Requieren el juicio humano.
• Pueden generar falsos positivos/negativos por problemas en la interpretación del código.
• No pueden determinar la accesibilidad de un sitio.

Maia Naftali 82.624 54 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

A lo largo del documento se enuncian recomendaciones para elegir una herramienta particular,
teniendo en cuenta algunos de estos criterios:
• Soporte de accesibilidad de la herramienta para los usuarios elegidos en las pruebas.
• Cobertura de los checkpoints y de las pautas elegidas.
• Configuraciones permitidas.
• Integración con otras tecnologías.
• Calidad de los resultados.
• Soporte de tecnologías.

2.1.2.5 Involucramiento de usuarios (Involving Users)

Se proporcionan recomendaciones y técnicas para involucrar a usuarios en el proceso de


evaluación de forma eficiente. Como primera recomendación, se aconseja ejecutar una prueba
preliminar para quitar del sitio barreras triviales.

2.1.2.6 Algunas conclusiones sobre la metodología de evaluación de la WAI

Existe una marcada diferencia entre la exhaustividad del documento de pautas y las
estrategias de evaluación. La metodología de evaluación que se propone es general. Describe
ciertos puntos que se deberían validar, y cada interesado debe darle forma para convertirlo en un
proceso útil.

El uso de herramientas automatizadas de evaluación no debería ser el único tipo de


prueba a utilizar. Es necesaria la inclusión de pruebas manuales, que en lo posible involucren
usuarios y diferentes tecnologías.

Maia Naftali 82.624 55 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.1.3 UWEM
2.1.3.1 UWEM: Introducción

La Metodología Unificada de Evaluación Web (UWEM) proporciona un procedimiento y ofrece


un sistema de principios y prácticas para evaluaciones de accesibilidad ejecutadas tanto por
expertos como por herramientas automáticas. La metodología está diseñada para brindar
conformidad con las pautas WCAG 1.0, aunque existe hasta la fecha un proyecto para migrar
hacia las pautas WCAG 2.0 [WABCluster].

El proyecto es uno de los tres que conforman el WABCluster. Esta es una agrupación de 23
instituciones de Europa para promover un enfoque común a la accesibilidad. Respecto de la
clasificación realizada en este trabajo, la UWEM corresponde al tercer grupo “Pruebas de
monitoreo automatizado sobre una muestra”, y además toma en cuenta la conformidad con las
pautas.

Los criterios de diseño que se tuvieron en cuenta fueron:


• Conformidad técnica con las pautas existentes de la WAI
• Independencia de la herramienta y del navegador: las preguntas y los casos de prueba
deben ser neutros
• Interpretación única: las preguntas deben tener una única interpretación
• Replicable: Diferentes evaluadores deben ejecutar las mismas pruebas en el mismo sitio,
y obtener resultados similares con cierta tolerancia.
• Cumplimiento con la regulación (EC) No 808/2004 del European Parliament.

La UWEM define tres pasos principales:


• Muestreo
• Ejecución de pruebas
• Generación de Reportes

Diagrama 2.1.3.1 Pasos definidos por la metodología UWEM

Maia Naftali 82.624 56 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Cada pauta tiene un caso de prueba definido [UWEM, 2008b], que puede ser automatizable o
manual. El resultado de las evaluaciones puede ser emitido en un formato de texto, o bien en un
archivo RDF ó XML para que sea la entrada de otro proceso.

2.1.3.2 UWEM Scoring

Con el resultado de las pruebas en gran escala se calcula el “UWEM Score”, una métrica que
muestra la probabilidad de hallar una barrera en una página. Con UWEM Score se comparan los
resultados en toda la muestra.

2.1.4 Barrier Walkthrough


2.1.4.1 Introducción

El método de Barrier Walkthrough (Recorrida por barreras) es una técnica basada en una
heurística para recorridas que propuso Giorgio Brajnik en el trabajo homónimo [BarrierW].
La evaluación es manual, y clasifica dentro del grupo de “Pruebas para la detección de barreras”.
Esta técnica es prioriza el impactos de las barreras según el tipo de contexto. Esto permite
conocer la severidad que tendrá cada una en sitio más allá de la conformidad con las pautas.

2.1.4.2 Procedimiento

En primera instancia, las barreras son catalogadas con la siguiente información:


• Categoría de usuario y tipo de discapacidad
• Tipo de tecnología asistiva a utilizar
• Actividad o tarea que la barrera obstaculiza y de qué forma
• Atributos de la página que presentan la barrera
Luego se define información del contexto de uso:
• Categorías de usuarios significativas (Personas con baja visión, personas con edad
avanzada, etc.).
• Objetivos o casos de uso (Llenar un formulario, leer un artículo, y otros.)
• Páginas a ser testeadas (listado de páginas).
• Escenarios de uso (ambientes ruidosos, a través de magnificadores, con
navegadores especiales, y otros).

Maia Naftali 82.624 57 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Por cada tipo de usuario, el autor elaboró planillas en donde figuran todas las barreras que
pueden afectar. Los evaluadores deben completarlas con las barreras que detecten. Datos de la
planilla para un caso de uso o página: Barrera, Impacto, Persistencia, Severidad, Detalle.

Con las planillas completas, se toman las barreras por cada tipo de usuario. A continuación se las
cruza contra el contexto de uso del escenario considerado, realizando una priorización. (Para
múltiples usuarios el autor propone una heurística para priorizar y juntar las planillas). Se asigna
por cada barrera un valor entre 1 y 3 (3 el más alto) para estimar el impacto que tiene, y la
persistencia con la que se presenta (es la frecuencia con la cual se presenta).

Para asignar un índice de severidad, se toma la siguiente medida:


Menor (1): la barrera es fácil de eludir y no afecta la seguridad o efectividad
Significativa (2): afecta a la ejecución de la tarea. Es difícil de eludir
Crítica (3): La barrera impide al usuario cumplir el objetivo

Con el impacto y la persistencia se genera una matriz para asignar severidades, que luego
servirán para tomar las barreras que presenten valores más altos.

Impacto Persistencia Severidad

1 1 Menor

1 2 Menor

1 3 Significativa

2 1 Significativa

2 2 Significativa

2 3 Crítica

3 1 Crítica

3 2 Crítica

3 3 Crítica
Tabla 2.1.4.1: Matriz de severidades, Barrier Walkthrough

Esta metodología de evaluación presentada tiene la ventaja de que se enfoca en la detección de


los problemas más severos, y permite medir el impacto de cada barrera para cada contexto de
uso. Los métodos tradicionales que buscan la conformidad contra las pautas solamente pueden
dar una idea de que cantidad de puntos fueron violados. Otra ventaja es que incluye en el análisis

Maia Naftali 82.624 58 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

el impacto del entorno y del tipo de usuario, y eso permite despreocuparse de ciertos tipos de
barreras que tienen una pauta asociada pero no aplicarían.
La desventaja principal es que este método requiere de evaluadores coordinados, y una gran
intervención del juicio humano para completar el proceso.

2.1.4.2 Trabajos sobre Barrier Walkthrough

El autor realizó pruebas experimentales sobre el Barrier Walkthrough. Fue hecha una
comparación contra la técnica de Conformance Review propuesta por la WAI [Brajnik, 2008a],
en una muestra de sitios evaluados bajo ciertas métricas. Los resultados obtenidos con Barrier
Walkthrough fueron más útiles e identificaron una mayor cantidad de barreras correctamente
juzgadas.

Maia Naftali 82.624 59 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.2. Métricas para evaluación de accesibilidad Web

2.2.1 Definición de métrica

Se conoce como métrica a cualquier medida destinada a conocer o estimar atributos de calidad de
un artefacto [WikipediaSWMetric].
Las métricas son importantes para controlar, entender y mejorar productos y procesos en el
desarrollo de software.

El enfoque GQM, propuesto por Basili, sugiere que las métricas deberían surgir naturalmente al
mirar los objetivos puntuales de un proceso. Esto evitaría la definición de métricas sin sentido,
que no brindan información y generan un costo [Basili, 1994].

2.2.2 Las métricas en la accesibilidad Web

Las métricas cuantitativas para la accesibilidad Web sintetizan el resultado las evaluaciones en
un valor que se corresponde con el grado de accesibilidad reflejado. El objetivo de estas métricas
es tener una noción acerca de cuán accesible es el artefacto evaluado. Es posible comparar
diferentes estados entre las versiones de una página ante cambios, y permiten tener una visión
global sobre una muestra.
Cada proceso de evaluación (Por pautas, barreras, de gran escala) maneja una o varias métricas.
En la sección siguiente se detallarán las más usuales.

Maia Naftali 82.624 60 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.2.3 Las métricas de evaluación de accesibilidad Web existentes:

2.2.3.1 FR (Failure Rate)

Fue el resultado del primer estudio publicado sobre la medición de la accesibilidad, propuesto
por Sullivan y Matson [Sullivan & Matson, 2000]. Esta métrica considera la relación entre el
número total de barreras encontradas en una página “p”, llamado “B (p)”, y el número de
barreras potenciales “P (p)”. Estas últimas representan al total de los elementos que podrían
comportarse como una barrera.

Nomenclatura:
B Cantidad de barreras o problemas encontrados en una página Web
P Cantidad de barreras potenciales en una página Web
W Coeficiente del peso de la barrera
NP Cantidad de páginas evaluadas
NT Cantidad de pruebas ejecutadas
Tabla 2.2.3.1.1: Símbolos FR

Fórmula:
Bp
Ip =
Pp
Qué mide:
Es una tasa entre las barreras potenciales y las barreras encontradas.

Lectura de los resultados:


Valores cercanos a 1 representan una pobre atención de las barreras de la accesibilidad.
Valores cercanos a 0 indican una baja cantidad de barreras presentes, y se infiere que se
trata de una página accesible.
Los valores de B y P dependen de la cantidad de casos de prueba que se estén tomando.

Ejemplo:
La página p1 contiene sólo 20 imágenes, de las cuales 19 tienen el atributo ALT:
P(p1) = 20 B(p1) = 1 (hay sólo una sin ALT)  I(p1) = 1/20.

Maia Naftali 82.624 61 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.2.3.2 WAB Score

Web Accessibility Barrier es una métrica propuesta por Parmanto & Zeng [Parmanto &
Zeng, 2005]. Agrega a la medición un peso que representa el problema potencial de cada barrera.
Utiliza como conjunto de pruebas a la verificación de 25 checkpoints de las pautas WCAG 1.
Los pesos son definidos como la inversa de la prioridad de cada checkpoint WCAG (1: A ,1/2:
AA ó 1/3: AAA). La fórmula toma en cuenta la totalidad de las páginas de un sitio.
[Hacket et al, 2004]

Nomenclatura:

p Total de páginas de un sitio


v Total de violaciones a una página
nv Violaciones a una página
Nv Cantidad de violaciones potenciales
Wv Peso de cada violación a las pautas, calculado como la inversa de la
prioridad (1:A; 2:AA, 3:AAA)
Np Total de páginas a verificar
Tabla 2.2.3.2.1: Símbolos WAB Score

Fórmula:
 nv 
∑∑  (Wv )
p v  Nv 
WABScore =
Np
Qué mide:
Calcula un ranking para todas las páginas de cada sitio. En lugar de considerar
“barreras”, como hace la métrica FR, toma en cuenta las violaciones a las pautas.

Lectura de los resultados:


Un puntaje de WAB más alto indica la presencia de más barreras a la
accesibilidad.
Si está cercano a cero denota que el sitio no viola ningún checkpoint.
Hay un umbral teórico fijado en 5.5. Por encima de ese valor el sitio se considera no
accesible.

Maia Naftali 82.624 62 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Ejemplo:
La página p1 tiene 20 imágenes. 19 poseen el atributo ALT, y 1 no lo tiene.
El checkpoint de “Imágenes sin texto alternativo”, de prioridad 1, se está violando en un
caso.
Valores: p = 1; v=1; nv =1; Nv=20; W(1)=1  WAB_Score = 1/20

2.2.3.3 UWEM Aggregation Formula

Esta métrica fue definida por la UWEM para su proceso de evaluación de páginas Web en gran
escala. Fue pensada para el monitoreo y la evaluación de sitios que provienen de un muestreo.
Actualmente se utiliza en las mediciones que anualmente ejecuta el WABCluster en Europa para
comparar entre los diferentes países de la región [Freire et al, 2008].

Nomenclatura:

Bpj Barreras halladas dada una página p y un test j


Ppj Barreras potenciales dada una página p y un test j
Wb Peso de la barrera, atributo experimental. Al momento los autores lo
fijan en 0.05 para cualquiera de ellas.
b Barrera
j Test
n Cantidad de test
Tabla 2.2.3.3.1: Símbolos UWEM

Fórmula:

1 n  B pj 
UWEM = ∑1 − ∏ 1 −
 Wb 
n j =1  P 
b
 pj 

Qué mide:
Mide la probabilidad de encontrar barreras en la página.

Dada una cantidad de test n corridos sobre una página, y conociendo la cantidad de
barreras potenciales que cada test podría detectar, se registra la cantidad de barreras
halladas. Con esos datos se genera el puntaje.

Maia Naftali 82.624 63 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Los tests son pequeñas pruebas unitarias definidas en la metodología UWEM, aunque se
podría extender la métrica y utilizar otro juego de pruebas.

Lectura de los resultados:


El resultado es una probabilidad y se encuentra siempre entre 0 y 1. Un valor
cercano a 0 indicaría que la página es accesible, dado que la probabilidad de hallar
barraras en ella es bajo. Por el contrario, un resultado cercano a 1 marcaría que el sitio es
poco accesible.

Limitaciones asumidas:
El peso de la barrera (Wb) es un dato experimental. Se asigna 0,05 a todas las barreras,
siendo el análisis de los valores mejorarían el resultado una mejora a futuro.

Ejemplo:
Para una página “p” se realiza un test “t”, donde se encuentra una única barrera
entre las 20 que podría tener. “Falta el atributo que identifica el lenguaje de la página”.
Esta barrera afecta a usuarios con ceguera (“c”) y baja visión (“Bb.”). El cálculo de la
métrica sería el siguiente:
Datos: BP = 1; P.D. = 20; Wi = 0.05 (es fijo) n=1; b=1
Resultado: 1- (1-(BP/P.D...) * Wi) = 1-0.9975 = 0.0025
 La probabilidad de encontrar una barrera en la página es 0.25%

Maia Naftali 82.624 64 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.2.3.4 A3

Bühler propone una métrica que es una mejora sobre UWEM Aggregation Formula
[Bühler et al, 2006]. Incorpora la complejidad de una barrera y el impacto sobre los diferentes
grupos de personas con discapacidad. Se enfoca en los requerimientos no cubiertos por UWEM
0.5 que son los siguientes: 1. Tomar en cuenta a los distintos grupos de usuarios con
discapacidad. 2. Permitir una interpretación única y repetible para la comparación de resultados.
3. Arrojar un rango continuo de valores. 4. Tener en cuenta el tamaño y la complejidad del sitio
o de la página Web.

Nomenclatura:

b Tipo de Barrera
u Tipo de discapacidad
i Identificador único de la ubicación (URL+cod+xpath) que fue evaluada
p Muestra evaluada. p= {i0; i1….. in} contiene todos los id. Únicos.
Reporte. Booleano que toma el valor de 1 si la barrera b es detectada en
Rib
la ubicación i
Npb Cantidad de reportes de aparición de la barrera b en la muestra p
Bpb Cantidad de reportes fallidos (Rib=1) para la barrera b
Bp Cantidad total de reportes fallidos para p
Np Cantidad total de reportes para p
S ub Severidad de la barrera b para el grupo u. En el intervalo [0;1]
Tabla 2.2.3.4.1: Símbolos A3

Fórmula:

A3 ( p, u ) = 1 − ∏ (1 − S ub )C pb Fórmula
b

B pb B pb
C pb = +
N pb Bp Función de complejidad

Qué mide:
Al igual que UWEM, mide la probabilidad de encontrar una barrera en el sitio. Se
pondera la severidad de todas las barreras de todos los tipos, y al valor obtenido se le
aplica un puntaje de complejidad en el exponente.

Maia Naftali 82.624 65 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Lectura de los resultados:


A3 obtiene una probabilidad (entre 0 y 1). Cuanto menor es el puntaje más accesible se
considera al sitio o la página, porque es menos probable encontrar barreras en él.
Respecto a la función de complejidad:
- Si no hay barreras encontradas del tipo b, no hay contribución a la función de
agregación( Bpb = 0  Cpb = 0)
- Si se encuentra una barrera de tipo b, el resultado de la función de agregación
decrecería. (Bpb>0  Cpb > 0)

La función de complejidad tiene en cuenta la relación entre las barreras potenciales y las
encontradas en el test. Además considera la relación entre el total de fallos y el número de
fallos por un solo tipo de barrera. Esto último asegura que la barrera sea tomada de
acuerdo a la proporción general de ocurrencias de todo el sitio Web.

Ejemplo:
Utilizando el mismo ejemplo que en la sección anterior (2.2.3.3), tenemos una
única página con un único test, que de 20 barreras potenciales posee sólo una: le falta el
atributo LANG que identifica el lenguaje de la página. Esta falla afecta a dos tipos de
usuarios con discapacidad: usuarios con ceguera y con baja visión .Esta métrica sí toma
en cuenta el impacto para cada tipo de usuarios.

Datos:
(Nota: Los reportes equivalen a los resultados de la ejecución de los casos de prueba).
• Bpb (cantidad de reportes fallidos para la barrera b)= 1;
• Bp (Cantidad de reportes fallidos en la muestra p ) = 1;
• Npb (aparición de la barrera en la muestra p): 2
• U = {u1,u2} = {usuarios con baja visión, usuarios con ceguera}
• Matriz de impactos S(u: usuario, b:barrera) ;
o S(baja visión, LANG ) = 0,2;
o S(ceguera, LANG ) = 0,5
Cálculo:
Cpb = 1/2 + 1/1 = 1,5

A3 (p, baja visión) = 1-(1-0,2^1,05) = 0,0890

Maia Naftali 82.624 66 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

A3 (p, ceguera) = 1-(1-0,5^1,5) = 0,3535

La probabilidad de hallar barreras para usuarios con ceguera es del 35%, y para usuarios
con baja visión, 8,9%. Para el resto de los usuarios la probabilidad es 0 (significa que es
accesible para ellos).

Maia Naftali 82.624 67 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.2.3.5 WAQM

WAQM (Web Accessibility Quantitative Metric ) es una métrica utilizada por un motor de
evaluación de laboratorio llamado “EvalAccess” [Vigo et al., 2007b]. Este motor tiene la ventaja
de que permite elegir el juego de pautas. El cálculo de la métrica es automático, y toma en cuenta
tanto los errores arrojados por la herramienta, como las advertencias y potenciales advertencias.

Nomenclatura:
Conjunto de checkpoints a evaluar, con cuatro subconjuntos
{P,O,U,R}
(P:Perceivable, O:Operable, U:Understandable, R:Robust}
Bxy ó E Cantidad de errores de accesibilidad en cada checkpoint
Pxy ó T Cantidad de casos de prueba ejecutados en cada pauta
Cantidad total de checkpoints con casos de prueba que posee la
N
herramienta (Para EvalAcc, 44)
Cantidad de checkpoints dado un elemento ‘x’ en {P, O, U, R} y otro
Nxy
elemento ‘y’ en {error,warning}
Ki Peso de los elementos con prioridad i: Valores {1:0,8; 2:0,16; 3:0.04}
A Valor de accesibilidad promedio
Ax Accesibilidad del elemento x en {P,O,U,R}
a Variable para la aproximación por hipérbola en el eje ‘y’ [0;100]
b Variable para la aproximación por hipérbola en el eje ‘x’ [0;1]
Tabla 2.2.3.5.1: Símbolos WAQM

Fórmula:

1 NP NTx NTxy
WAQM = ∑ ∑
NP j =1 x∈{ P ,O ,U , R} NT

y∈{e , w} NTx
∑W A
x∈{1, 2 , 3}
z xyz

 B xyz   − 100  Bxyz a − 100


 ⋅  + 100, si <
  b 
 Pxyz  Pxyz a − 100/b

Axyz =
  Bxyz 
 − a  + a, en caso contrario
 P 
 xyz 

Maia Naftali 82.624 68 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Algoritmo de cálculo:
Para cada checkpoint ‘x’ en {P,O,U,R}
Para cada tipo de checkpoint ‘y’ en {warning, error}
Para cada prioridad ‘z’ en {1,2,3} /* Evalúa la rama a usar por la aproximación por hipérbola*/
Bxyz a − 100
Si < entonces
Pxyz a − 100/b
Hallar A xyz en la primera rama, usando la corrección por hipérbola b
fijada en [0;1]:

 B xyz   − 100 
Axyz =  ⋅
  b  + 100
 Pxyz 
Sino
Hallar A xyz en la segunda rama, con la corrección a fijada en [0;100]

 Bxyz 
Axyz = − a +a
P 
 xyz 
Fin
Fin loop ‘z’

3
Axy = ∑ k z × Axyz  Paso a: Ponderación de la tasa A por el peso de cada elemento
z =1

Fin loop ‘y’

N xy × Axy
Ax = ∑  Paso b: Ponderación por la cant. de checkpoints entre x e y
y Nx
Fin loop ‘x’
N x × Ax
A=∑  Paso c: Ponderación por la cant. de checkpoints entre x, y el total
x N

Maia Naftali 82.624 69 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Qué mide:
El valor arrojado por esta métrica está comprendido entre 0 y 100, donde un valor
mayor cercano a 100 significa un sitio accesible.

Lectura de los resultados:


Un valor cercano a 100 significa un sitio accesible, mientras que un valor cercano a 0
indica que han fallado la mayoría de las pruebas automáticas sobre los checkpoints.

2.2.3.6 Mambo AI (Accessibility Index)

Mambo AI es una métrica ligada a la técnica de evaluación Barrier Walkthrough (BW),


descripta en la sección anterior. No se basa en la conformidad con las pautas. Se calcula
directamente del reporte proveniente del BW.

Nomenclatura:
s Severidad proveniente del Barrier Walkthrough
d Tipo de discapacidad
Matriz de severidad. Se tabula la cantidad de barreras por cada tipo de
M
usuario, contra la severidad asociada a cada grupo
M[d,s] Elemento de la matriz
F Densidad de barreras.
wi Peso que tiene el elemento i-esimo
k Factor de escala
Si la raya está arriba, expresa que el resultado está en un intervalo de
_____
confianza del N% (N=95 para el estudio)
Tabla 2.2.3.6.1: Símbolos Mambo AI

Fórmula:

f = F * M[](al 95% IC)

Maia Naftali 82.624 70 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Qué mide:
El valor resultante está relacionado con la probabilidad de que no existan barreras en la
página/sitio.
Cada término de la productoria expresa la probabilidad de que no existan barreras para el
grupo de usuarios con discapacidad d.

Lectura de los resultados:


Un valor cercano a 0 expresa que el sitio tiene una baja probabilidad de contener barreras.
Es comparable a las métricas UWEM Score y A3, que están en el mismo intervalo por
tratarse de probabilidades.

Tabla 2.2.3.6.1: Matriz de Severidad M al 95% [Brajnik, 2006a]

Las columnas representan los grados de severidad de las barreras, mientras que las
filas son los distintos grupos de usuarios con discapacidad afectados.
El valor de la derecha tiene aplicado el intervalo de confianza del 95%.

Maia Naftali 82.624 71 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.3 Automatización en la evaluación de sitios accesibles

2.3.1 Introducción

Las herramientas de verificación automática de accesibilidad, o simplemente validadores,


son programas que prueban la conformidad de una página con un juego de pautas determinado.
El uso de estas herramientas permite conocer rápidamente que puntos de las pautas (checkpoints)
están siendo violados. También proporcionan información descriptiva sobre los errores, a modo
de ayuda para el usuario que debe reparar esa sección. Todas se basan en la verificación de reglas
que hacen al cumplimiento de un punto.

Existen checkpoints que no son verificables con herramientas simples. Para los controles
más específicos, como el contraste y todos aquellos vinculados al color, existen herramientas
auxiliares que realizan pruebas más profundas. Para evaluar la complejidad y la comprensión del
contenido de una página no existen herramientas totalmente automáticas. Se opta por omitir los
casos de prueba relacionados a esos checkpoints (como sucede con Achecker), o bien se generan
advertencias ante la ausencia de elementos que sirvan para ordenar la información (Hera).

Un inconveniente que presentan todas las herramientas automáticas es el de los falsos


positivos y falsos negativos. Un falso positivo se da cuando la herramienta reporta un error pero
el juicio humano posterior detecta que no lo es. Un falso negativo sucede cuando la herramienta
directamente no detecta el error presente.

Como sostiene Thatcher en el libro “Web Accessibility” [Thatcher et al, 2006], todo test
de accesibilidad debería ser visto como un proceso que combina las herramientas automáticas
con el juicio humano. La parte algorítmica pregunta por la presencia o ausencia de atributos que
hacen accesibles a los objetos (por ejemplo, la presencia de alt), pero sólo el juicio humano
puede determinar además si ese atributo es coherente y cumple con la función.

Maia Naftali 82.624 72 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.3.1.1 Verificación algorítmica

En la siguiente tabla se resumen algunas de las verificaciones típicas que pueden realizar las
herramientas automáticas. La implementación varía con la tecnología utilizada.

Pauta a prueba Verificación Observaciones


Un equivalente textual Se comprueba la existencia No todas las imágenes importan lo mismo. La omisión de alt en
debe ser provisto ante de elementos “alt” en las los gráficos decorativos tiene un impacto menor que en las
cada elemento gráfico de imágenes HTMLy la imágenes principales; La descripción provista puede sen un
la página presencia de subtítulos en los espacio, o el nombre del archivo, y eso no lo volvería accesible
videos.
Una alternativa textual Se comprueba que los videos Algunos formatos no son soportados, y es necesario evaluar si
debe ser provista ante tengan subtitulado (eso tiene sentido que tengan subtitulado (publicidades o decoración
cada video funciona con algunos por ejemplo). Los subtítulos pueden no ser acordes al contenido.
formatos)
La información de la Se prueba que la diferencia Es difícil de verificar si hay cambios de color en la mitad del
página debe poder ser de colores entre el fondo y el texto y fondos gráfico.
vista sin depender de los texto, tenga un contraste
colores mayor al umbral.
Los encabezados de fila Se comprueba la presencia de El algoritmo debe detectar primero que son tablas de datos.
y columna en las tablas tags th y tr en las primeras Luego, se realizaría la detección de identificadores de
deben estar identificados filas y columnas de la tablas. cabeceras.
Esto vale para tablas de
datos.
Las páginas deben estar Se prueba que las Es importante que el algoritmo tome en cuenta las transiciones
diseñadas para evitar las transiciones entre fotogramas de contraste.
frecuencias de parpadeo no estén en ese rango, y lo
entre los 2hz y los 55 hz mismo con el cambio de
contrastes.
Los formularios deben Se verifica que cada elemento El acceso por diferentes dispositivos debe ser probado de forma
estar diseñados para del formulario tenga una no automática.
permitir el uso de descripción o texto. Se debe
tecnologías asistivas probar el uso del teclado.
Los tiempos de espera Se busca que no existan El uso de tecnologías no HTML como Flash y Silverlight
deben ser suficientes, y elementos temporales, como requiere un testeo aparte porque no se aplica el mismo
se debe alertar al usuario sesiones, scripting y algoritmo.
en su vencimiento para refrescos.
que pueda solicitar más
tiempo.
Tabla 2.3.1.1: Resumen de la verificación algorítmica principal de una página

Maia Naftali 82.624 73 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.3.2 Herramientas automáticas

Dentro de las herramientas automáticas, las más populares son:

2.3.2.1 Bobby

Watchfire Bobby fue una de los primeras herramientas comerciales de evaluación de


páginas bajo las pautas WCAG y Section 508. Evaluaba HTML y xHTML para verificar
el cumplimiento. En la actualidad fue adquirido por IBM e integrado a sus productos de
accesibilidad Web.

2.3.2.2 T.A.W.

T.A.W. es una herramienta de validación libre desarrollada por la Fundación C.T.I.C.


(Centro Tecnológico especializado en Tecnologías de Internet), sede española del W3C.
El validador se presenta en diferentes versiones: Validación Web Online, desde un URL,
ó bajando una aplicación en Java para escritorio. [TAW] (2010).

2.3.2.3 WAVE

W.A.V.E. (Web Accessibility Evaluation Tool) es una herramienta de validación libre,


provista por la organización sin fines de lucro “WEB.Aim”. Tiene una versión para usar
desde la Web, una extensión para el programa de diseño “Dreamweaver”, y un servicio
Web para interactuar con otras aplicaciones que requieran validar páginas.
[WAVE](2010)

2.3.2.4 HERA

Hera es la herramienta de validación de la fundación Sidar (Seminario de Iniciativas


sobre Discapacidad y Accesibilidad en la Red,). Poseen un grupo de trabajo permanente,
voluntario, en el que participan miembros de toda Iberoamérica [HERA] (2010).
Desarrollada en PHP, La herramienta posee un componente (plug-in) para el navegador
Mozilla Firefox. El código fuente está disponible también.

Maia Naftali 82.624 74 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.3.2.5 EvalAcces

EvalAccess es una herramienta desarrollada en la Universidad del País Vasco, que realiza
una validación gratuita a través de la Web [EvalAccess](2010). Permite evaluar páginas
HTML aisladas o sitios completos.

2.3.2.7 Achecker

Achecker es un validador gratuito de código abierto desarrollado por el grupo de


Tecnologías Adaptativas de la Universidad de Toronto (ATRC). Está implementado en
php, y es posible correr tanto pruebas on-line como locales. Tiene además un servicio
Web que permite ejecutar pruebas y obtener un resultado en un lenguaje basado en XML
[Achecker](2010).

Maia Naftali 82.624 75 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2.4 Conclusiones: Procesos de evaluación y métricas

Sobre los procesos de evaluación:

Las evaluaciones de accesibilidad manuales son efectivas en cuanto a la detección de barreras,


pero tiene un alto costo. Por otra parte, las evaluaciones automáticas ejecutadas desde diversas
herramientas son veloces y económicas, pero no pueden realizar todos los chequeos necesarios
para asegurar la accesibilidad.

Muchas de las herramientas en la actualidad siguen utilizando las pautas WCAG 1, basadas en el
HTML. Esto limita de forma innecesaria los recursos de los creadores, quienes deben restringir
el uso del HTML para lograr la conformidad. Entre las distintas herramientas de evaluación
automática existen diferencias en los resultados, debido a la implementación que cada una hace
de la verificación.

Existen metodologías como UWEM, que proponen casos de prueba y escenarios estandarizados.
La extensión de su uso contribuiría a la detección eficiente de barreras, pero por su envergadura
es prácticamente inaplicable en proyectos pequeños con tiempo escaso o nulo para la
verificación. En esos casos sería útil contar con una evaluación automática rápida que al menos
permita detectar las barreras más comunes.

Sobre las métricas:

Las métricas fueron creadas con la idea de medir el proceso de evaluación. De las métricas
analizadas, se distinguen dos grandes grupos: manuales y automáticas.

Las métricas de procesos automáticos (WABScore, UWEM, A3, WAQM) enfatizan en


incorporar atributos y elementos matemáticos con el fin de lograr más precisión. Sin embargo,
los procesos que miden tienen un marcado desvío causado por los falsos positivos y los falsos
negativos. Las barreras provenientes del uso del lenguaje no podrían ser verificadas de forma
automática y eso podría causar un desvío aún mayor al resultado de la formula. Dependerían de
la herramienta empleada y de sus resultados. La ventaja está en su facilidad de cálculo.

Maia Naftali 82.624 76 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Las métricas de procesos manuales (BW, FR, WABScore) llevan un mayor tiempo de
elaboración y cantidad de personas involucradas, pero contemplan pruebas que serían
irrealizables automáticamente.

Existe una discusión acerca del real significado de una métrica. Tom Demarco creyó por décadas
en su famosa frase “You can’t control what you can’t measure” (No puedes controlar lo que no
puedes medir). Hoy en día DeMarco propone una nueva frase: “The more you focus on control,
the more likely you’re working on a project that’s striving to deliver something of relatively
minor value” [DeMarco, 2009]. El foco de las métricas cambió junto con la ingeniería del
software, que en la actualidad está en la búsqueda del valor y de la utilidad

Este análisis, llevado al plano de las métricas para accesibilidad Web, indica que se debe buscar
primero el valor en los procesos que hacen necesaria la presencia de las métricas de elevada
complejidad. Reducir la cantidad de variables en juego (usuarios, severidad, prioridad, casos de
test) a la hora de evaluar la accesibilidad redundaría en métricas más simples y procesos menos
costosos.

Maia Naftali 82.624 77 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo III:

OceanAcc, Una aplicación que integra


métricas en un proceso de evaluación
semiautomático

Maia Naftali 82.624 78 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Capítulo III: OceanAcc, Una aplicación que integra métricas


en un proceso de evaluación semiautomático

3.1 Motivación

El proceso de evaluación de la accesibilidad no puede ser realizado de forma automática


completamente por los falsos positivos que arrojan las herramientas de evaluación. El ruido
generado debe ser filtrado por el juicio humano. Los procesos de evaluación manual o artesanal
obtienen resultados más cercanos, ligados a las barreras reales. Sin embargo, requieren del diseño
de casos de prueba y su adaptación al contexto.

Sería útil disponer de un proceso semiautomático que permita un análisis desde la detección de
barreras, y que además cuente con métricas que aporten una idea sobre el grado de accesibilidad
obtenido.

3.2 Objetivos

a. Primarios
• Hacer más eficiente al testing o evaluación de accesibilidad Web, tanto manual como
automático
• Integrar métricas al proceso de evaluación, obtenidas de forma semi automática
• Generar información de valor de forma rápida

b. Secundarios
• Simplificar la incorporación del juicio humano a través de una interfaz gráfica simple y
eficiente

Maia Naftali 82.624 79 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.3 Descripción de la aplicación

OceanAcc es una aplicación de escritorio que modela un proceso de evaluación


semiautomático con integración de métricas de accesibilidad. Emplea una evaluación automática
con las pautas WCAG2-A para hallar las violaciones más importantes, y luego solicita la
intervención del usuario para filtrar aquellos puntos detectados que son falsos positivos o no
aplican en el contexto. Una vez realizado ese refinamiento, calcula las métricas de accesibilidad
más usuales (Failure Rate, WabScore, UWEM) y dos métricas propias del proceso (errores
aprobados/errores totales), WabScore*.
Posee además reportes, y permite ver la historia de una página y analizar su evolución a lo largo
de los tests ejecutados.

Para realizar las pruebas automáticas se emplea el servicio Web provisto por la
herramienta Achecker, que devuelve un resultado en formato rest (XML).
Respecto de la relación entre las barreras y los checkpoints, se utilizó el mapeo propuesto por G.
Brajnik en su trabajo Barrier Walkthrough [BarrierW](2009). En el mismo, cada violación a un
checkpoint genera de 0 a N barreras.

Beneficios:
Permite enfocarse en la detección, corrección y prueba de las barreras más frecuentes y costosas,
haciendo al proceso más eficiente.
Considerando que en muchos proyectos el presupuesto para las pruebas de accesibilidad es
acotado, el aporte de esta información permitiría liberar sitios Web con menos barreras.

Tecnología:
.NET Framework 3.5, C# , WPF, base de datos con ODBC, rdlc reports, rest Web Service de
AChecker, XML.

Formato de las entradas:


Rest xml, ingreso manual.

Formato de las salidas:


Reportes en pdf, texto.

Maia Naftali 82.624 80 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.4 Documentación
3.4.1 Modelo de datos

Page Guideline

PK,I1 id PK,I1 id

FK1 idsite name


title year
filename
type
failurePoints

TestBarrier Test

PK,I1 id

FK2,I2 idtest date


FK1,I1 idbarrier FK1 guideline
userveredict FK2 page
q tool Checkpoint
acheckermap
theresold
PK,I2 id
known
likely
FK1 guideline
I1 idAchecker potential
I1 checkpoint
I2 idCheckpoint
description
errorTypeA
priority_score
Element
inherits

TestResult
Barrier PK,I1 idtestresult
BarrierDisability
PK,I1 id
FK2 idtest
FK1 checkpoint Severity
BarrierName
FK2,I2 iddisability result
Description
FK1,I1 idbarrier comment
userveredict impact
errortype persistence
sourceLine severity
Disability sourceColumn
PK,I1 id

disabilityname BarrierCheckpoint

FK1,I1 idbarrier
FK2,I2 idcheckpoint
impact

Diagrama 3.4.1 Modelo de datos

Maia Naftali 82.624 81 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.4.2 Arquitectura

Se optó por desarrollar una aplicación para escritorio. Dentro de las ventajas encontradas:
 Es más económica la persistencia en una estructura de base de datos simple cuya
ubicación la determina el usuario.
 No requiere que el usuario suba las páginas locales. Las herramientas que corren bajo
plataforma Web son útiles si la página está alojada en un servidor.

La vista (UI) fue hecha en Windows Presentation Foundation, que brinda soporte a la
accesibilidad a través de la interfaz UIAccess provista por el Framework .Net 3.5
Para el acceso a datos se implementó el patrón Gateway.

WPF Classes Report Templates

Object

Metric and Report Parse and Import


Data Manager Manager module

Data Access
Gateway

DB Input folder

Diagrama 3.4.2 Diagrama de Componentes

Maia Naftali 82.624 82 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.4.3 Descripción del proceso de prueba de una página

Test manager Metric Manager

Usuar AChec
io ker

Crear Página

Crear Test

Ejecutar Test

Importar
resultados

Generar lista de
barreras

Editar resultados

Aprobar
Calcular métricas
resultados

Almacenar

Diagrama 3.4.3 Diagrama de actividades

Funcionalidades de la aplicación:

1. Crear o abrir una página


2. Agregar o abrir un test
3. Importar datos de la herramienta OceanAcc
4. Editar resultados
5. Generar métricas
6. Abrir reportes

Maia Naftali 82.624 83 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.4.4 Sobre el proceso de evaluación con Achecker

El Web Service que ofrece Achecker recibe una petición con la siguiente forma:
http://achecker.ca/checkacc.php?id=68320c641ac984e871fd61793e0364e57006f6
a0&amp;output=rest&amp;guide=WCAG2-A&amp;offset=0&amp;uri=http%3A%2F%2F

Se especifica el conjunto de pautas (WCAG2-A), la dirección URL, el tipo de salida, y un id que


corresponde al usuario registrado en su sitio.

La salida que se obtiene está en formato XML rest. El siguiente ejemplo es un fragmento de un
test ejecutado sobre Google:

<summary>
<status>FAIL</status>
<sessionID>d3fc039b44378199ee4e5937e6ca7bdf4d6a769c
</sessionID>
<NumOfErrors>3</NumOfErrors>
<NumOfLikelyProblems>7</NumOfLikelyProblems>
<NumOfPotentialProblems>44</NumOfPotentialProblems>

<guidelines>
<guideline>WCAG 2.0 (Level A)</guideline>
</guidelines>
</summary>

<results>
<result>
<resultType>Error</resultType>

<lineNum>3</lineNum>
<columnNum>1</columnNum>
<errorMsg>&lt;a href=&quot;
http://achecker.ca/checker/suggestion.php?id=49&quot;
onclick=&quot;popup('http://achecker.ca/checker/suggestion.php?id=49'); return
false;&quot; title=&quot;Suggest improvements on this error message&quot;
target=&quot;_new&quot;&gt;Document has invalid language code.&lt;/a&gt;
</errorMsg>

<errorSourceCode>&lt;html xmlns=&quot;
http://www.w3.org/1999/xhtml&quot;&gt;&lt;head&gt; &lt;meta http-
equiv=&quot;content-type&quot; content=&quot;text/h ...</errorSourceCode>

<repair>Add a valid 2 letter or 3 letter language code as defined


in the ISO 639 specification to the HTML &#039;lang&#039; attribute.</repair>

</result>

3.4.4 Formato de una salida

Del archivo rest XML se obtienen los resultados, que se importan en la base de datos como
resultados de un test.

Maia Naftali 82.624 84 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

La correlación entre el código de error (<errorSourceCode> ) que devuelve el servicio de


Achecker y el identificador del checkpoint violado figura en una tabla interna de la base de datos
de OceanAcc.

3.4.5 Sobre las métricas generadas

Para generar las métricas es necesario contar con datos de entrada que en su mayoría son
específicos de determinados procesos. Se mostrará para cada caso particular la forma en que se
obtienen los resultados:

• Failure rate
Bp
Ip =
Pp
Esta métrica es una tasa entre las barreras potenciales, y las barreras encontradas.
Las barreras potenciales se estiman con el dato de los puntos de falla (Failure points).
Cuando el usuario da de alta una página, se le pregunta por la cantidad de elementos no
HTML (imágenes, audio, video, tablas, etc.).
Las barreras encontradas se calculan con la cantidad de errores encontrados por la
herramienta, omitiendo las advertencias y los problemas potenciales.

• UWEM

1 n  B pj 
UWEM = ∑1 − ∏ 1 − Wb 
n j =1  P 
b
 pj 

UWEM mide la probabilidad de encontrar barreras en un sitio, dado un subconjunto de


pruebas y barreras.

El algoritmo de cálculo obtiene una la lista de las barreras potenciales, utilizando


la relación entre la violación de un checkpoint y las barreras asociadas. Se itera sobre esa
lista, solicitando la cantidad de veces que aparece esa barrera llamado q, y va a
representar a la cantidad potencial. El numerador de la tasa, Bpj, se obtiene con las

Maia Naftali 82.624 85 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

barreras que el usuario aceptó que existían y va a representar a la cantidad efectiva de


barreras. Siempre se toma para un único test, por lo tanto n es 1.

• WABScore

n 
∑∑  N (W )v
v

WABScore =
p v  v
Np
Para calcular WABScore es necesario conocer la cantidad de checkpoints que la
herramienta pone a prueba (Nv) para el conjunto de pautas WCAG2 A. Ese dato se
obtiene desde la aplicación. El numerador de la tasa (nv) representa la cantidad efectiva
de checkpoints violados. Se calcula tomando en cuenta todos los errores que el usuario
validó y marcó como existentes.

• WABScore * (adaptada)

 nv 
WABScore = ∑  
ve{ E ,W , P }  N v 

Esta métrica es propia de la aplicación OceanAcc. Consiste en una adaptación de


WABScore que toma en cuenta los tres tipos de fallas: error – advertencia – problema
potencial.
Fórmula: WabScore * = Tasa (cant. errores) + Tasa (advertencias) + Tasa (problemas),
donde “Tasa(tipo)” es la cantidad de fallas sobre checkpoints de ese tipo, sobre la
cantidad total de tests que la herramienta corre para ese tipo.
Esta métrica tiene la ventaja de que separa las fallas más importantes de aquellas poco
relevantes, omitiendo parte del “ruido” que generan todas las advertencias.

• False Positive Rate: FPR (Tasa de falsos positivos)


fallas _ validadas
FPR =
total _ fallas _ det ectadas

Esta métrica es propia de la aplicación OceanAcc. Se calcula dividiendo la


cantidad de fallas validadas por el usuario sobre las totales indicadas por la herramienta.
Siendo la tasa de falsos positivos un atributo de la herramienta, la obtención de un valor
con alto desvío podría indicar un problema en el testing manual.

Maia Naftali 82.624 86 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.5 Caso de estudio

3.5.1 Caso de estudio I: página de la Facultad de Ingeniería

Se realizará el proceso completo de evaluación de una página, tomando como ejemplo la página
principal de la facultad.

Pantalla principal:

Imagen 3.5.1.1 Pantalla Principal de la aplicación OceanAcc

1. Crear una página:

Se solicita al usuario los siguientes datos, todos opcionales excepto el URL: Título, URL
o nombre del archivo, tipo de página, puntos de falla. Este último atributo es utilizado para el
cálculo de la métrica “Failure Rate”. Si se desconoce, se puede estimar en el mismo
formulario, ingresando en el recuadro “Page Resources” la cantidad de recursos externos al
HMTL que tiene la página (Imágenes, videos, tablas no accesibles, eventos temporales y
demás).
También es posible abrir una página existente.

Maia Naftali 82.624 87 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Imagen 3.5.1.2: Pantalla para crear una nueva página

Imagen 3.5.1.3: Pantalla para abrir una página existente

2. Crear un nuevo test:

Imagen 3.5.1.4: Pantalla para crear un test

Maia Naftali 82.624 88 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Una vez que se carga la página, se muestra la pantalla principal:

Imagen 3.5.1.5: Pantalla con la URL cargada

3. Importar resultados
El usuario debe abrir el test, y se activará la opción para importar resultados:

Imagen 3.5.1.6: Resultado de la importación

Maia Naftali 82.624 89 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Antes de importar los resultados, se prueba la conexión contra el servicio Achecker. Si es


exitosa, habilita la opción de carga de resultados (Load Results). En caso contrario, el sistema
permite cargar los resultados de un archivo .rest generado a través de la Web de Achecker. Esto
permite la importación aún cuando el servicio no responde.
En las solapas se puede ver y exportar el código rest devuelto, y una vista previa de la página.

4. Editar resultados

Imagen 3.5.1.7: Edición de resultados

Aparecen en dos grillas los resultados de la evaluación. En la superior figuran los errores, y en la
inferior las advertencias y potenciales problemas. Esta opción “por defecto” es para facilitar la
selección, y asegurarse de que los errores más importantes sean considerados.

Si el usuario encuentra un falso negativo, puede ingresar el checkpoint manualmente en “Add a


checkpoint failure…”.
Se puede promover una falla, o quitarla. Para obtener más información del checkpoint, se
despliega una ventana al seleccionarlo con un texto descriptivo. Sumado a la línea y columna del
error, el desarrollador podrá ubicar en qué puntos hay fallas.

Maia Naftali 82.624 90 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Cuando el usuario termina de editar los checkpoints, pasa a editar y seleccionar las barreras:

Imagen 3.5.5.7: Edición de resultados: barreras

Las barreras son buscadas de forma automática. En la lista inferior aparecen ordenadas por
impacto y cantidad de apariciones (Q). Una barrera puede aparecer muchas veces por prueba, y
su repetición es indicio de que es probable que sea verdadera.
El impacto total de una barrera se calcula como la suma de los impactos parciales. A cada una se
le asigna un impacto entre 1 y 3 en la base de datos, en la relación con el checkpoint.
El propósito de esta cuantificación es lograr un orden que priorice las barreras con mayor
probabilidad.

Imagen 3.5.1.8: Ventana emergente con información de la barrera seleccionada

Maia Naftali 82.624 91 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

6. Generar métricas

Las métricas van a tener sentido si el usuario filtró los resultados provenientes del evaluador
Achecker e ingresó las barreras detectadas. Por defecto, no se dan de alta las presuntas barreras,
y eso hace que las métricas basadas en las mismas no arrojen resultados precisos.

Imagen 3.5.1.9: Ventana de generación de métricas

Maia Naftali 82.624 92 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Análisis de los resultados:

• Failure Rate resultó en un valor elevado. De 158 puntos de falla, la evaluación detectó 140
errores validados por el usuario (y otros 266 no validados).

• UWEM arroja que la probabilidad de hallar una barrera en Fiuba es cercana al 30%. Sólo se
seleccionó la barrera más recurrente e importante (falta de atributos descriptores de contenido
no textual (ALT)). Ningún elemento de la página poseía ALT, por lo tanto el resultado es
coherente considerando todo el espacio de barreras.

• La tasa de falsos positivos (FPR) no debería ser analizada, ya que se eligieron los
checkpoints violados más recurrentes y se dejaron de lado las advertencias (warnings) y
problemas potenciales. Si todas las advertencias fueran erróneas, la tasa de falsos positivos
sería cercana al 63% .

3.5.2 Tabla comparativa de métricas entre páginas:

Se realizó una nueva corrida del programa con Fiuba, especificando una cantidad de puntos de
falla más realista fijada en 166. Para obtenerlos se analizó el código HTML en busca de
imágenes, tablas, formularios y demás recursos. La página de la ACM es el caso testigo, ya que
es accesible y cumple con WCAG y con Section 508.

Failure FR WABScore UWEM


Página URL WABScore*
Points [0;1] [0;5,5]U(5,5;N) [0;1]
Google www google com 2 0,054 0,007752 0,02041 0,06781
Fiuba www fi uba ar 158 0,886 1,085271 2,85714 0,29486
Yahoo AR www yahoo com ar 25 0,305 0,023256 0,06122 0,08705
ACM www acm org 25 0 0 0 0

Tabla 3.5.2: Comparativa de resultados entre páginas

Del resultado de las métricas se pueden hacer las siguientes inferencias:

• La página más accesible según las métricas es Google, y el único punto validado
por el usuario es que no especifica el idioma. En los sitios multiidioma eso podría
ser mitigado con código que redireccione según la cultura que tenga el sistema,
pero en este caso no se tuvo en cuenta.

Maia Naftali 82.624 93 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

• Del análisis de UWEM para Fiuba, sale que la probabilidad de encontrar una
barrera es del orden del 30%. Ninguna de las 148 imágenes tenía el atributo ALT
con la descripción. En el caso de Google, la barrera se debe al idioma y tiene un
peso cercano al 7%. Por lo tanto, para esta métrica el castigo de no informar un
idioma es mucho mayor que el de omitir el contenido de las imágenes.

• Entre Yahoo y Google los valores de UWEM tienen una diferencia dentro del
mismo orden, y lo mismo ocurre con Yahoo y Fiuba para FR. UWEM se basa en
las barreras y distingue usuarios y prioridades, mientras que FR es una simple tasa
de fallos. Puede suceder que muchos fallos a los checkpoints generen pocas
barreras, si éstos son del mismo tipo, o el usuario final omitió esa barrera en el
análisis.

Maia Naftali 82.624 94 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

3.6 Conclusiones

El objetivo principal del trabajo fue hacer más eficiente la evaluación de la accesibilidad Web, y
a la vez integrar métricas que puedan ser obtenidas fácilmente. Del análisis de los procesos y de
las métricas se puede concluir:

• La generación de resultados automáticos da una idea del grado general de accesibilidad.


La precisión de las métricas asociadas es excesiva respecto del ruido que pueden tener las
evaluaciones. Sin la intervención del juicio humano resulta imposible filtrar los
resultados y quitar los falsos positivos.

• Al tratarse de 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.
Un ejemplo está en la descripción de las imágenes, que podrían consistir en un texto que
diga “texto” y aún así pasar las pruebas.

• Los procesos manuales son precisos y efectivos. Están menos difundidos que las
evaluaciones automáticas, y podrían ser adaptables para proyectos más pequeños en
contextos reducidos.

• La lectura de las métricas provenientes de procesos automáticos debería tener en cuenta


el carácter aproximado de las mismas. Resulta contradictorio la medición exacta, cuando
los parámetros empleados son experimentales o están definidos de forma arbitraria

• Cada métrica pondera una misma violación individual a la accesibilidad de forma


diferente. Para poder extraer conclusiones y realizar comparaciones, es necesario conocer
en qué impacta cada violación sobre el valor que se calcula. De otra forma no sería
correcto decir que la página X es N veces más accesible que la página Y porque su
resultado se aproxima más al ideal.

• Finalmente, 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. Es

Maia Naftali 82.624 95 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

decir, la utilidad de la métrica sería conocer aproximadamente en qué posición está una
página respecto de la accesibilidad.

“No silver bullet” (No existe una bala de plata) [Brooks, 1986] es una famosa frase que Brooks
acuñó durante la crisis de la ingeniería software. Explicaba la inexistencia de un elemento que
pudiera revertir instantáneamente la situación de aquel entonces.

Trazando la analogía en lo que respecta a la accesibilidad Web, no existe un único enfoque que
permita llegar al ideal de una Web sin barreras. Es necesario trabajar en todas las líneas de forma
coordinada. Los estándares y las normativas por sí solos demostraron un alcance limitado. Se
requiere de herramientas de edición Web que generen contenido accesible por defecto; de
intermediarios entre el contenido y el navegador que preparen mejor la información; de
estándares de calidad que incorporen la accesibilidad como atributo; de herramientas y procesos
de prueba óptimos; de un acercamiento de las prácticas a las empresas vinculadas a la Web; de
voluntad y de trabajo.

Aplicando el conjunto de las estrategias será posible mejorar la accesibilidad. Esto aportaría un
beneficio a toda la comunidad, permitiendo que más individuos se sumen al medio de mayor
difusión de intercambio personal aparecido en la Historia de la Humanidad: la Web.

Maia Naftali 82.624 96 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

APENDICES

Maia Naftali 82.624 97 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Apéndices

Apéndice A: Glosario de afecciones abarcadas por la


accesibilidad Web

A.1 Visuales
A.1.a. Ceguera

Pérdida total del sentido de la vista.

A.1.b. Baja visión

Privación parcial de la vista que no puede ser corregida adecuadamente con anteojos,
lentes de contacto, remedios o cirugía.

A.1.c. Daltonismo

Imposibilidad de distinguir los colores. Los tipos de daltonismo: Acromático (sólo negro
contra blanco), Monocromático(sólo poseen un cono), Dicromático (sólo poseen dos
conos), Tricromático anómalo (poseen tres tipos de conos, pero perciben los tonos
alterados. Es el tipo más común).

A.2 Auditivas
A.2.a Sordera total

Imposibilidad de percibir el sonido.

A.2.b Hipoacusia

Pérdida parcial de la capacidad auditiva.

A.3 Físicas

Limitación en el desempeño motor, que afecta a brazos o piernas.

A.4 Del Habla


Dificultad en la comunicación oral. Disfluencia (trastorno del ritmo), Tartamudeo
(vacilaciones y repetición involuntaria), Trastornos en la voz (anomalía en calidad, tono y
volumen).

Maia Naftali 82.624 98 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

A.5 Problemas cognitivos


A.5.a Dislexia

Trastorno del aprendizaje que se manifiesta con dificultades y retraso en la lectura. Está
asociado a una falla neurológica y no tiene relación con la inteligencia del individuo.

A.5.b Déficit de atención (TDAH)

“Trastorno de déficit de atención e hiperactividad”. Trastorno neurológico del


comportamiento caracterizado por distracción moderada a severa, períodos de atención
breve, inquietud motora, inestabilidad emocional y conductas impulsivas.

A.5.c Síndrome de down

Trastorno genético causado por la presencia de una copia extra del cromosoma 21 (o una
parte del mismo), en vez de los dos habituales (trisomía del par 21), caracterizado por la
presencia de un grado variable de retraso mental y unos rasgos físicos peculiares que le
dan un aspecto reconocible. Es la causa más frecuente de discapacidad psíquica
congénita.

A.5.d Alzheimer

Enfermedad neurodegenerativa, que se manifiesta como deterioro cognitivo y trastornos


conductuales. Se caracteriza en su forma típica por una pérdida progresiva de la memoria
y de otras capacidades mentales, a medida que las células nerviosas (neuronas) mueren y
diferentes zonas del cerebro se atrofian.

A.6 Epilepsia

Trastorno cerebral que hace que las personas tengan convulsiones recurrentes. Las
convulsiones ocurren cuando los grupos de células nerviosas (neuronas) del cerebro
envían señales erróneas. Las personas pueden tener sensaciones y emociones extrañas o
comportarse de una manera rara. Pueden tener espasmos musculares violentos o perder el
conocimiento

Maia Naftali 82.624 99 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Apéndice B: Glosario de Tecnologías asistivas

Tecnología Asistiva (AT) es la denominación que recibe de todo dispositivo tecnológico de


asistencia, adaptación y rehabilitación para personas con discapacidad. Mejorando y cambiando
los métodos de interacción con la tecnología, estos dispositivos habilitan a realizar tareas que se
verían impedidas. [Wikipedia AT](2010).

B.1 Lectores de pantalla

Los lectores de pantalla ó “Screen Readers” son programas que interpretan la información
mostrada por pantalla para que las personas con problemas de visión ó aprendizaje puedan
acceder a la información.
En los sistemas con interfaz gráfica (GUI) deben almacenar además los elementos (menúes,
ventanas, botones, cuadros de texto, etc.) para permitir al usuario moverse a través de la pantalla.
Los sistemas operativos del momento ofrecen APIs o interfases que intervienen en la interacción
y alimentan a estos sistemas, para permitir que diferentes tecnologías puedan ser leídas.
Dentro de los lectores más populares, se encuentran: JAWS – LSR (Linux Screen Reader) –
Microsoft Narrator – VoiceOver. Muchos de ellos vienen incluidos con el sistema operativo.

B.2 Teletipos (TTY)

Un TTY (Teletypewriter) ó TDD (Telecommunication Device for the Deaf) es un dispositivo


electrónico de comunicación textual que permite a las personas con sordera comunicarse a través
de las líneas telefónicas. Consiste en un teclado QWERTY junto con un visor, que operan bajo
un protocolo específico. Si bien no es específico en el uso de una computadora, este sistema fue
el precursor de tecnologías asistivas como el reconocimiento de voz o los teclados adaptados.

Imagen B.2 : Teletipo AT&T [Wikipedia TTY](2010)

Maia Naftali 82.624 100 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

B.3 Aumentadores de pantalla y corrección de color

Dentro de esta categoría se engloban las aplicaciones y dispositivos destinados a alterar la forma
en la cual se muestra la información en pantalla. Permiten a las personas con problemas de visión
y daltonismo acceder a la misma.

Los aumentadores de pantalla por software consisten en ventanas o recuadros que aumentan o
destacan el área de la pantalla seleccionada. Usualmente poseen funciones para la corrección de
colores, el suavizado (smoothing) de los elementos gráficos y algunas funciones básicas de
lectura de pantalla.

B.4 Reconocimiento de voz

Un sistema de reconocimiento de voz es una herramienta que procesa la señal de voz emitida
por el ser humano y reconoce la información contenida en ésta, convirtiéndola en texto. Permite
a las personas con problemas de visión operar una computadora a través de comandos por voz.

B.5 Sistemas de subtitulado oculto (Close Captioning)

Es un sistema de subtítulos para programas de televisión y video destinado a permitir que las
personas sordas o con dificultades para captar la señal de audio, puedan comprender lo que se
dice en televisión o en los videos. A diferencia de los subtítulos comunes, que sólo describen los
diálogos, este sistema describe todo el audio presente (incluyendo música de fondo y efectos de
sonido) mediante palabras o símbolos. Esta tecnología aplica tanto a la televisión como al
streaming de video por Internet o los juegos.

B.6 Dispositivos Braille

Estos dispositivos interpreta y/o generan lenguaje Braille, ayudando a las personas con ceguera a
interactuar con una computadora.
Hay tres clases de dispositivos Braille:

Maia Naftali 82.624 101 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

- Líneas Braille: Consisten en dispositivos que muestran en una línea el texto en


Braille. Cada línea está compuesta por celdas dinámicas de 6 ú 8 puntos que
suben o bajan de forma dinámica.

Imagen B.6: Dispositivo de celdas Braille [Wikipedia Braille] (2010)

- Teclados Braille: Consisten en teclados para el ingreso de caracteres en


Braille.
-
- Impresoras Braille: Son impresoras con percutores o punzones, que imprimen
el texto en su equivalente de caracteres en Braille.

B.7 Hardware adaptado

Son dispositivos de hardware, tanto de entrada como de salida, que han sido modificados para
permitir a usuarios con problemas de cognición o movilidad utilizar una computadora.
Abarcan a los teclados especiales, mobiliario ergonómico de soporte, y diferentes tipos de
interruptores y dispositivos de entrada con su interfaz de conexión.

Maia Naftali 82.624 102 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

GLOSARIO

Maia Naftali 82.624 103 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

GLOSARIO

Tabla de traducciones de términos:

Inglés Español
Assistive Technologies Tecnologías asistivas
Authoring Tool Herramientas de diseño
Boolean Booleano
Browser Navegador
Checkpoint Punto de verificación
Guideline Pauta
Pop-Up Página Emergente
Script Código de programación
Stakeholder Interesado
User Agent Agente de Usuario
W3 Consortium Consorcio World Wide Web
Walkthrough Recorrida guiada

Glosario:

Assistive Tecnologies (Tecnologías asistivas)


Dispositivos tecnológicos de asistencia, adaptación y rehabilitación para personas con
discapacidad

ATAG (Authoring Tool Accessibility Guidelines)


Pautas de accesibilidad del consorcio W3 para herramientas de diseño.

Authoring Tool
Aplicación utilizada para crear, modificar o ensamblar contenido Web para otras
personas. Ejemplos: herramientas de blogging, editores WYSIWYG (Dreamweaver,
Frontpage, otros.), las funciones de “Guardar Como HTML...”, los CMS, y demás
aplicaciones que permiten generar páginas Web.

Maia Naftali 82.624 104 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Barrera (a la accesibilidad)
Elemento en una página que impide a las personas con discapacidad acceder al recurso.

Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart)
Prueba desafío-respuesta utilizada en computación para determinar cuándo el usuario es o
no humano. Consiste en que el usuario introduzca un conjunto de caracteres que se
muestran en una imagen distorsionada que aparece en pantalla. Se supone que una
máquina no es capaz de comprender e introducir la secuencia de forma correcta por lo
que solamente el humano podría hacerlo.

Guideline (Pauta, referido a la accesibilidad)


Conjunto de recomendaciones detalladas y organizadas con puntos de control
(Checkpoints). Cada pauta contiene sugerencias y ejemplos a seguir para lograr la
conformidad con cada uno de sus puntos de control.

Heurística
Técnica experimental que ayudan a la resolución de problemas. Los métodos heurísticos
aplican una estrategia para llegar a una solución aproximada de forma más rápida.

OCR (Optical Character Recognition)


Proceso que reconoce el texto de una imagen y lo convierte en caracteres o letras del
alfabeto.

Section 508 (Sección 508 de “Rehabilitation act”)


Sección de la ley “Rehabilitation Act”, que a partir del año 2001 establece estándares
obligatorios de accesibilidad que aplican a todas las agencias gubernamentales. Tiene
alcance sobre todos los programas informáticos y periféricos que se utilizan.

Stakeholder (Interesado)
Persona, grupo ú organización interesada en un proyecto, cuyos intereses se ven afectados
por el éxito o el fracaso del mismo.

Usabilidad (ISO/IEC 9126)

Maia Naftali 82.624 105 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido,


usado y ser atractivo para el usuario, en condiciones específicas de uso.

User Agent (Navegador)


Aplicación informática que funciona como cliente en un protocolo de red. El nombre
aplica generalmente para referirse a aquellas aplicaciones que acceden a la Web
(navegadores, arañas de buscadores, teléfonos móviles, lectores de pantalla y otros).

UAAG (User Agent Accessibility Guidelines)


Pautas del consorcio W3 que explican cómo hacer agentes de usuario accesibles para
personas con discapacidad, y cómo incrementar la accesibilidad al contenido Web.

UWEM (Unified Web Evaluation Methodology)


Metodología para la evaluación del cumplimiento de las pautas WCAG, desarrollada por
la agrupación europea WAB Cluster. Consiste en un procedimiento de evaluación que
abarca un sistema de principios y de prácticas para la evaluación de la accesibilidad de la
Web tanto por un experto humano como de manera automática.

W3Consortium
Consorcio que agrupa a organizaciones internacionales multidisciplinarias y miembros
que trabajan en conjunto para desarrollar estándares Web y pautas.

WAI (Web Accessibility Initiative)


Grupo de interés del Consorcio W3 sobre asuntos de accesibilidad en la Web.

WCAG (Web Content Accessibility Guidelines)


Pautas del consorcio W3 que explican cómo desarrollar contenido accesible para la Web.

Maia Naftali 82.624 106 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

REFERENCIAS

Maia Naftali 82.624 107 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

REFERENCIAS

[AboutW3] (2009) Ian Jacobs “About the World Wide Web Consortium (W3C)”
http://www.w3.org/Consortium/ .
Último acceso: 01/05/2009.

[Baguma et al, 2009] R. Baguma, R. Stone, J. Lugega, P. Van der Weide. “A


Framework for Filtering Web Accessibility Guidelines”.
W4A2009 - Communication, April 20-21, 2009, Madrid,
Spain. Co-Located with the 18th International World Wide
Web Conference. Copyright 2009 ACM 978-1-60558-561.

[BarrierW] (2009) G. Brajnik. “Barrier Walkthrough - Heuristic evaluation


guided by accessibility barriers”.
http://users.dimi.uniud.it/~giorgio.brajnik/projects/bw/bw.html
Último Acceso: 13/09/2009.

[Basili et al, 1994] V. Basili, G. Caldiera, H. Dieter Rombach. “The Goal


Question Metric Approach”. Encyclopedia of Soft. Eng., vol.
2, September 1994, pp. 528-532, John Wiley & Sons, Inc.

[Berners-Lee & Cailliau, 1990] Tim Berners-Lee, Robert Caillau, “WorldWideWeb:


Proposal for a HyperText Project”, 1990.
http://www.w3.org/Proposal.html
Último Acceso: 01/05/2009.

[Berners-Lee, 1989] Tim Berners-Lee. “WorldWideWeb: Proposal for a


HyperText Project”. 1989
.http://www.w3.org/History/1989/proposal.html
Último Acceso: 07/05/2009.

[Brajnik, 2008a] G. Brajnik. “A Comparative Test of Web Accessibility


Evaluation Methods”. ASSETS’08, October 13–15, 2008,

Maia Naftali 82.624 108 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Halifax, Nova Scotia, Canada. Copyright 2008 ACM 978-1-


59593-976-0/08/10.

[Brajnik, 2008b] G. Brajnik. “Beyond Conformance: The Role of Accessibility


Evaluation Methods”. S. Hartmann et al. (Eds.): WISE 2008,
LNCS 5176, pp. 63–80, 2008. Springer-Verlag Berlin
Heidelberg 2008.

[Brajnik, 2008c] G. Brajnik. “Measuring Web Accessibility by Estimating


Severity of Barriers”. S. Hartmann et al. (Eds.): WISE 2008,
LNCS 5176, pp. 112–121, 2008. Springer-Verlag Berlin
Heidelberg 2008.

[Brajnik & Lomuscio, 2007] G. Brajnik, R. Lomuscio. “SAMBA: A Semi-Automatic


Method for Measuring Barriers of Accessibility”.
ASSETS’07, October 15–17, 2007, Tempe, Arizona, USA.

[Brewer, 2004a] J. Brewer. “How People with Disabilities Use the Web”,
2004. http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/
Último Acceso: 05/05/2009.

[Brewer, 2004b] J. Brewer. “Web Accessibility Highlights and Trends”, 2004.


ACM SIGCAPH Newsletter 15 No. 76, June 2003, pág. 15 y
16.

[Brooks, 1986] J. P. Brooks. “No Silver Bullet. Essence and Accidents of


Software Engineering.”. ISBN No. 0444-7077-3, H. J. Kugler,
Ed., Elsevia Science Publishers B.V. (North-holland) IFIP
1986.

[Bühler et al, 2006] C. Bühler, H. Heck, O. Perlick, A. Nietzio, N. Ulltveit-Moe.


“Interpreting Results from Large Scale Automatic Evaluation
of Web Accessibility”. K. Miesenberger et al. (Eds.): ICCHP

Maia Naftali 82.624 109 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

2006, LNCS 4061, pp. 184–191, 2006. © Springer-Verlag


Berlin Heidelberg 2006.

[Byrne, 2009] J. Byrne. “Jim Byrne of Jim Byrne and Associates –


Interview”. http://totallyaccessible.com/blog/2009/05/jim-
byrne-of-jim-byrne-and-associates-interview/ Último Acceso:
17/09/2009.

[Chisholm & Henry, 2005] W. Chisholm, S.L. Henry. “Interdependent Components of


Web Accessibility”. W4A at WWW2005, 10th May 2005,
Chiba, Japan. Copyright 2005 ACM 1-59593-036-1/05/05

[Clarck, 2003] J. Clarck. “Building Accessible Web Sites”. 2003. New


Riders.

[Demarco, 2009] T. DeMarco. “Software Engineering: An Idea Whose Time


Has Come and Gone?”. 2009. IEEE Software (ISSN 0740-
7459) .

[eEurope] (2009) eEurope. “European Commission ,Information Society: Web


Accessibility”.
http://ec.europa.eu/information_society/activities/einclusion/po
licy/accessibility/Web_access
Último acceso: 08/07/2009.

[eEuropeSidar] (2007) Fundación Sidar. “eEurope,Una Sociedad de Información


para Todos”
http://www.sidar.org/recur/direc/eeuro/index.php
Último acceso: 08/07/2009

[EvalAccess] (2010) Evalaccess: “Tool for evaluating Web Accessibility”.


Último acceso: 20/02/2010.

Maia Naftali 82.624 110 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

[Evaluating Accesibility] (2009) W3C-WAI “Evaluating Web Sites for Accessibility:


Overview”. http://www.w3.org/WAI/eval/Overview.html
Último Acceso: 01/05/2009.

[Freire et al, 2008] A. Freire, R. Fortes, M. Turine, D. Paiva. “An Evaluation of


Web Accessibility Metrics based on their Attributes”.
SIGDOC’08, September 22-24, 2008, Lisbon, Portugal.
Copyright 2008 ACM 978-1-60558-083-8/08/0009.

[Freire, 2009] A. Freire, C. Russo, R. Fortes. “A Survey on the Accessibility


Awareness of People Involved in Web Development Projects in
Brazil”. W4A2008 Technical, April 2122, 2008, Beijing,
China. CoLocated with the 17th International World Wide
Web Conference. Copyright 2008 ACM

[Hacket et al, 2004] S. Hackett, B. Parmanto, X. Zeng. “Accessibility of Internet


Websites through Time”. ASSETS'04, October 18–20, 2004.
Pg. 32-39. Atlanta, Georgia, USA. Copyright 2004 ACM 1-
58113-911-X/04/0010

[Hera] (2010) Hera. “Qué es Hera”. http://www.sidar.org/hera.


Último acceso: 20/02/2010.

[HistoryInternet] (2003) Tim Berners-Lee “10 years Public Domain”


http://tenyears-www.Web.cern.ch/tenyears-
www/Welcome.html
Último acceso: 10/12/2008.

[Kawanaka et al, 2008] S. Kawanaka, Y. Borodin, J. Bigham, D. Lunn, H. Takagi,


G. Asawaka. “Accessibility Commons: A Metadata
infraestructure for Web Accessibility”. ASSETS’08, October
13–15, 2008, Halifax, Nova Scotia, Canada. Copyright 2008
ACM 978-1-59593-976-0/08/10.

Maia Naftali 82.624 111 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

[Kelly et al, 2007a] B. Kelly, L. Neville, E.A. Draffan, S. Fanou. “One World,
One Web … But Great Diversity”. Located with the 17th
International World Wide Web Conference. Copyright 2008
ACM. Copyright 2007 ACM 1-59593- 590-8/06/0010

[Kelly et al, 2008] B. Kelly, D. Sloan, S. Brown, J. Seale, H. Petrie, P. Laucke,


S. Ball. “Accessibility 2.0: People, Policies and Processes”.
W4A2007 - Technical Paper, May 07-08, 2007, Banff, Canada.
Co-Located with the 16th International World Wide Web
Conference. Copyright 2007 ACM 1-59593-590-8/06/0010

[Lopes et al, 2009] R. Lopes, K. Votis, L. Carriço, D. Tzovaras, S.


Likothanassis. “Towards The Universal Semantic Assestment
of Accesibility”, SAC’09 March 812,
2009, Honolulu, Hawaii, U.S.A. Copyright 2009 ACM
9781605581668/09/03.

[memex] (1945) Vannevar Bush “As we may Think”. http://www.ps.uni-


sb.de/~duchier/pub/vbush/vbush-all.shtml
Último acceso 05/05/2009

[Paciello, 2002] M. Paciello. “Web Accessibility for People with Disabilities”.


CMP Books.

[Parmanto & Zeng, 2005] Parmanto and X. Zeng. “Metric for Web accessibility
evaluation”. Journal of the American Society for Information
Science and Technology, 56(33):1394-1404, 2005.

[Regan, 2004] B. Regan. “Accessibility and Design: A Failure of the


Imagination”. W4A at WWW2004, May 18, 2004, New York,
New York, USA. Pág 29-38. Copyright 2004 ACM
1581139039/04/0005.

Maia Naftali 82.624 112 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

[Sloan & Kelly, 2006] D. Sloan, B. Kelly. “Reflections on the development of a


Holistic Approach to Web Accessibility”. Accessible Design in
the Digital World. Conference Proceedings. The University of
York. 22-24 September 2008.

[Sloan et al, 2006] D. Sloan, B. Kelly, A. Heath, H. Patrie, F. Hamilton, L.


Phipps. “Contextual Web Accessibility - Maximizing the
benefit of Accessibility Guidelines”. W4A at WWW2006,
23rd-26th May 2006, Edinburgh, UK. Pág. 121-131. Copyright
2006 ACM 1-59593-281-x/06/05.

[Sloan et al,2007] D. Sloan, B. Kelly, S. Brown, J. Seale, H. Petrie, P. Lauke –


S.Ball. “Accessibility 2.0: People, Policies and Processes”.
W4A2007 - Technical Paper, May 07-08, Pág. 138-147. 2007,
Banff, Canada. Co-Located with the 16th International World
Wide Web Conference. Copyright 2007 ACM 1-59593-590-
8/06/0010.

[Sullivan & Matson, 2000] T. Sullivan and R. Matson. “Barriers to use: usability and
content accessibility on the Web's most popular sites”. In CUU
'00: Proceedings on the 2000 conference on Universal
Usability, pages 139-144, New York, NY, USA, 2000. ACM
Press.

[TAW] (2010) TAW, Inicio. http://www.tawdis.net


Último acceso: 20/02/2010.

[Testimonials] (2002) W3C-WAI. “Testimonials for User Agent Accessibility


Guidelines (UAAG) 1.0 Recommendation”.
http://www.w3.org/2002/12/uaag10-testimonials .
Último Acceso: 08/05/2009.

[Thatcher et al, 2006] J. Thatcher, M. Burks, C. Heilman, S. Lawton Henry, A.


Kirkpatrick, P. Lauke, B. Lawson, B. Regan, R. Rutter, M.

Maia Naftali 82.624 113 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Urban, C. Waddell. “Web Accessibility: Web standards and


regulatory compliance”. 2006. Friendsoft (UK).

[TuringTest] (2005) M. May. “Inaccessibility of CAPTCHA Alternatives to Visual


Turing Tests on the Web”. http://www.w3.org/TR/turingtest/
Último Acceso: 13/09/2009

[UAAG 2.0 draft, 2009] W3C-WAI. “User Agent Accessibility Guidelines (UAAG) 2.0
W3C Working Draft 11 March 2009”.
http://www.w3.org/TR/2009/WD-UAAG20-20090311/.
Último Acceso: 17/09/2009

[WAM4,2007] E. Velleman, C. Velasco, M. Snaprud “D-WAB4 Unified


Web Evaluation Methodology (UWEM 1.2 Core)”, 2007.
http://www.wabcluster.org/uwem1_2/UWEM_1_2_CORE.pdf
Último Acceso: 17/09/2009

[UWEM, 2008a] A. Nietzio, N. Ulltveit-Moe, T. Gjøsæter, M. Goodwin


Olsen, M. Snaprud. “UWEM Indicator Refinement”, 2008.
http://www.wabcluster.org/uwem1_2.
Último Acceso: 17/09/2009

[UWEM, 2008b] E.Velleman, J. Koch, C. Velasco, C. Strobbe, A. Nietzio, M.


Snaprud. “UWEM Tests for Conformance”, 2008.
http://www.wabcluster.org/uwem1_2.
Último Acceso: 17/09/2009

[Vigo et al., 2007b] M. Vigo, M. Arrue, G. Brajnik, R. Lomuscio, J. Abascal.


“Quantitative Metrics for Measuring Web Accessibility”.
W4A2007 – Pg. 99-107. Technical Paper, May 07–08, 2007,
Banff, Canada. Co-Located with the 16th International World
Wide Web Conference. Copyright 2007 ACM 1-59593-590-
8/06/0010

Maia Naftali 82.624 114 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

[w3CStd] (2008) Imagen de estándares W3C


http://www.w3c.es/Presentaciones/2008/1201-
accesibilidadCATIC-MA/img/tech-stack.png
Último acceso: 01/09/2009

[WABCluster] (2009) WAB Cluster. “The EU Web Accessibility Benchmarking


Cluster”. http://www.wabcluster.org/
Último Acceso: 17/09/2009

[WAI interdependences, 2005] S. L. Henry. “Essential Components of Web Accessibility”.


http://www.w3.org/WAI/intro/components.php.
Último Acceso: 17/09/2009

[WAI social factors] (2009) S.L. Henry & Andrew Arch. “Social Factors in Developing a
Web Accessibility Business Case for Your Organization”.
http://www.w3.org/WAI/bcase
Último Acceso: 01/09/2009

[WAIabout] (2009) W3C-WAI. “About WAI”. http://www.w3.org/WAI/


Último Acceso: 01/09/2009

[WAIintro](2009) W3C-WAI .“Getting Started, Overview”.


http://www.w3.org/WAI/gettingstarted/Overview.html
Último Acceso: 01/09/2009

[WAVE](2010) WAVE .“About Wave”. http://wave.Webaim.org/about


Último Acceso: 20/02/2010

[WCAGdiff] W3C-WAI. “How WCAG 2.0 Differs From WCAG 1.0”


http://www.w3.org/WAI/WCAG20/from10/diff.php
Último Acceso: 01/06/2009

Maia Naftali 82.624 115 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

[WCAG 1.0] (2009) W3C-WAI. “Authoring Tool Accessibility Guidelines (ATAG)


2.0 W3C Working Draft 21 May 2009”.
http://www.w3.org/TR/ATAG20/.
Último Acceso: 17/09/2009

[WCAG 2.0, 2009] W3C-WAI. “Web Content Accessibility Guidelines (WCAG)


2.0 W3C Recommendation 11 December 2008”.
http://www.w3.org/TR/WCAG20/.
Último Acceso: 17/09/2009

[Webbrowser] (1990) Tim Berners-Lee. “The WorldWideWeb browser”.


http://www.w3.org/People/Berners-Lee/WorldWideWeb .
Último Acceso: 10/12/2008

[Wikipedia AT](2010) Wikipedia. “Assistive technology”.


http://en.wikipedia.org/wiki/Assistive_technology.
Último Acceso: 20/02/2010

[Wikipedia Braille](2010) Wikipedia. “Dispositivo Braille”.


http://es.wikipedia.org/wiki/Dispositivo_Braille.
Último Acceso: 20/02/2010

[Wikipedia Section 508](2009) Wikipedia. “Section 508 Amendment to the Rehabilitation Act
of 1973”.
http://en.wikipedia.org/wiki/Section_508_Amendment_to_the_
Rehabilitation_Act_of_1973
Último Acceso: 03/07/2009

[WikipediaSWMetric] (2009) Wikipedia. “Software Metric”.


http://en.wikipedia.org/wiki/Software_metric
Último Acceso: 17/09/2009

[WikipediaSWTest] (2009) Wikipedia. “Software Testing”.


http://en.wikipedia.org/wiki/Software_testing

Maia Naftali 82.624 116 - 117


Análisis e Integración de métricas para la Accesibilidad Web FI-UBA

Último Acceso: 13/09/2009

[Wikipedia TTY](2010) Wikipedia: “Telecommunications device for the deaf”.


http://en.wikipedia.org/wiki/Telecommunications_device_for_t
he_deaf.
Último acceso: 20/02/2010

[Wiscosin] (2001) University of Wiscosin. “Disability as a function of Age”.


http://trace.wisc.edu/docs/function-aging/
Último acceso: 09/05/2009

Maia Naftali 82.624 117 - 117