Ingenieria Informatica

Marzo 2010
TESIS DE GRADO EN INGENIERA EN INFORMTICA
Anlisis e Integracin de
mtricas para la
Accesibilidad Web
Tesista: Maia R. Naftali

Director: Prof. Ing. Osvaldo Cla
Anlisis e Integracin de mtricas 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 algn grado de discapacidad. Se incluyen
problemas visuales, auditivos, fsicos, cognitivos, neurolgicos y del habla. Existen pautas para
la creacin de contenido Web accesible, as como tambin leyes en muchos pases que
promueven el contenido Web accesible. Sin embargo, la aplicacin de las pautas no est
generalizada y existe desconocimiento acerca de este tipo de prcticas.
Para detectar problemas a la accesibilidad en el contenido Web existen procesos de

evaluacin tanto manuales como automticos. Los mtodos manuales, que se basan en la
ejecucin de casos de prueba por parte de usuarios con discapacidad, son efectivos pero costosos.
Los mtodos automticos, que utilizan un software para verificar las pginas, son menos
completos: su resultado no contempla aquellos casos que exceden al control algortmico bsico
que realizan. Existen mtricas asociadas a los procesos de evaluacin que permiten cuantificar el
grado de accesibilidad obtenido.
En este trabajo se plantea un proceso de evaluacin semiautomtico que integra mtricas

de accesibilidad Web, y es implementado por la aplicacin OceanAcc. El objetivo del mismo
es optimizar la evaluacin de sitios Web. Con poca intervencin del usuario, se generan reportes
y mtricas que aportan informacin cuantitativa. Esto permite detectar e informar las barreras
ms importantes, reduciendo el esfuerzo de las evaluaciones no automticas.
Maia Naftali
82.624
2 - 117
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. Its 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
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 colaboracin con los grficos.
A mis amigos, por su apoyo incondicional y por los momentos de felicidad.
A mis compaeros de la facultad, que compartieron esta carrera que por momentos pareca
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
FI-UBA
Tabla de Contenidos
Resumen ............................................................................................................................................... 2
Abstract ................................................................................................................................................. 3
Agradecimientos.................................................................................................................................... 4
Tabla de Contenidos.............................................................................................................................. 5
Objetivos ............................................................................................................................................... 7
Alcance.................................................................................................................................................. 7
Organizacin de la Tesis ....................................................................................................................... 7
Captulo I: La Accesibilidad en la Web ................................................................................................... 9
1.1 La World Wide Web......................................................................................................................................... 9

1.1.1 Orgenes/ historia ..................................................................................................................................... 9
1.1.2 El w3 Consortium ................................................................................................................................... 10
1.2 Introduccin: 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 Evaluacin Verificacin del cumplimiento de las pautas para contenido .................................... 30
1.4.4 Anlisis del modelo de pautas ............................................................................................................... 32
El enfoque holstico: modelo del Tangram ................................................................................................. 32
Una posible implementacin 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
Unin Europea: eEurope ............................................................................................................................ 37
1.6. El problema de la creacin 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 Lneas de investigacin en la actualidad ............................................................................................... 49
Captulo II: Los Mtodos de Evaluacin de la Accesibilidad Web ................................................................. 51

2.1 Evaluacin de sitios Web .............................................................................................................................. 51
2.1.1 Introduccin al proceso de evaluacin de accesibilidad ........................................................................ 51
2.1.2 Tcnicas de evaluacin propuestas por la WAI y su alcance................................................................ 52
2.1.2.1 Revisin preliminar (Preliminary Review) ....................................................................................... 52
2.1.2.2 Evaluacin de conformidad (Conformance Evaluation) ................................................................. 53
2.1.2.3 Criterios de evaluacin para contextos especficos (Approaches for Specific Content): ............... 53
2.1.2.4 Seleccin de herramientas de evaluacin automticas (Selecting a tool) .................................... 54
2.1.2.5 Involucramiento de usuarios (Involving Users)............................................................................... 55
2.1.2.6 Algunas conclusiones sobre la metodologa de evaluacin de la WAI .......................................... 55
2.1.3 UWEM ................................................................................................................................................. 56
2.1.3.1 UWEM: Introduccin ....................................................................................................................... 56
2.1.3.2 UWEM Scoring ............................................................................................................................... 57
2.1.4 Barrier Walkthrough ............................................................................................................................. 57
Maia Naftali
82.624
5 - 117
FI-UBA
2.1.4.1 Introduccin .................................................................................................................................... 57

2.1.4.2 Procedimiento ................................................................................................................................. 57
2.1.4.2 Trabajos sobre Barrier Walkthrough ............................................................................................... 59
2.2. Mtricas para evaluacin de accesibilidad Web .......................................................................................... 60
2.2.1 Definicin de mtrica.............................................................................................................................. 60
2.2.2 Las mtricas en la accesibilidad Web .................................................................................................... 60
2.2.3 Las mtricas de evaluacin 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 Automatizacin en la evaluacin de sitios accesibles .................................................................................. 72
2.3.1 Introduccin ............................................................................................................................................ 72
2.3.1.1 Verificacin algortmica................................................................................................................... 73
2.3.2 Herramientas automticas ..................................................................................................................... 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 evaluacin y mtricas ....................................................................................... 76
Captulo III: OceanAcc, Una aplicacin que integra mtricas en un proceso de evaluacin
semiautomtico ................................................................................................................................... 79
3.1 Motivacin ..................................................................................................................................................... 79

3.2 Objetivos ........................................................................................................................................................ 79
3.3 Descripcin de la aplicacin .......................................................................................................................... 80
3.4 Documentacin .............................................................................................................................................. 81
3.4.1 Modelo de datos ..................................................................................................................................... 81
3.4.2 Arquitectura ............................................................................................................................................ 82
3.4.3 Descripcin del proceso de prueba de una pgina ............................................................................... 83
3.4.4 Sobre el proceso de evaluacin con Achecker ...................................................................................... 84
3.4.5 Sobre las mtricas generadas ............................................................................................................... 85
3.5 Caso de estudio ............................................................................................................................................. 87
3.5.1 Caso de estudio I: pgina de la Facultad de Ingeniera ........................................................................ 87
3.5.2 Tabla comparativa de mtricas entre pginas: .................................................................................. 93
APENDICES ........................................................................................................................................ 98
Apndice A: Glosario de afecciones abarcadas por la accesibilidad Web ......................................................... 98

Apndice B: Glosario de Tecnologas asistivas ................................................................................................ 100
GLOSARIO........................................................................................................................................ 104
REFERENCIAS ................................................................................................................................. 108
Maia Naftali
82.624
6 - 117
FI-UBA
Introduccin
Objetivos
Estudiar el modelo de accesibilidad vigente
Analizar y determinar las causas por las cuales no se generaliz la incorporacin de la

accesibilidad en la Web
Analizar y clasificar los diferentes procesos de evaluacin de accesibilidad en la Web y

las mtricas asociadas.
Proponer un proceso de evaluacin que integre mtricas y optimice la intervencin

manual del evaluador, mejorando la lectura de los resultados y el tiempo empleado.
Desarrollar una aplicacin que materialice dicho proceso y contribuya a una mejora en el
campo.
Alcance
El trabajo est centrado en los aspectos que refieren a los estndares y a la evaluacin de la
accesibilidad en la Web. Queda fuera del alcance del trabajo todo lo relacionado a la usabilidad,
a las tecnologas que hacen uso de la Web y a los aspectos tcnicos de la legislacin.
Organizacin de la Tesis
El texto est organizado en tres captulos. En el primero se analizan los aspectos generales de la
accesibilidad en la Web. En el segundo captulo, se estudian los diferentes procesos de
evaluacin y las mtricas existentes. Finalmente, en el tercer captulo se describe la aplicacin
desarrollada y se trae como ejemplo de funcionamiento un caso de estudio.
Al final estn las referencias bibliogrficas y los apndices, que incluyen los glosarios del
trabajo.
Maia Naftali
82.624
7 - 117
FI-UBA
Captulo I:
La Accesibilidad en la Web
Maia Naftali
82.624
8 - 117
FI-UBA
Captulo 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 Orgenes/ 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 pginas que pueden contener texto, imgenes, y medios continuos como
video o msica.
Uno de los grandes aciertos del sistema fue la conexin entre las pginas a travs de
hipervnculos. Esto permite hacer un recorrido no lineal entre los documentos, conocido como
navegacin. La propuesta original de la Web fue redactada en la CERN (European Organization
for Nuclear Research) [Berners-Lee, 1989] en el ao 1989 por Sir Timothy John Berners-Lee ,
tomando como idea precursora a un proyecto jams materializado llamado Memex. Ideado por
Vannevar Bush en 1945, consista en un dispositivo que almacenara documentos de todo tipo
que seran consultados y editados a travs 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 colaboracin de Robert Cailliau. Como miembro de la CERN, fue quien
decidi tomar la idea de Berners-Lee y ayud tanto en la redaccin como en la provisin de
recursos para concretar el proyecto. A fines de 1990 ya haban construido el primer servidor Web
en un sistema Next, y el primer software navegador-editor de pginas [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 aparicin 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
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
estndares Web y pautas. Su lema es: Guiar la Web hacia su mximo potencial a travs del
desarrollo de protocolos y pautas que aseguren el crecimiento futuro de la Web [AboutW3]. A
travs de varios organismos, libera estndares y tecnologas sobre las cuales se basarn los
documentos en la Web. Dentro de los estndares ms conocidos estn el PNG para los grficos,
el HTML para los sitios, CSS y SOAP.
Diagrama 1.1.2 Estndares que maneja el consorcio W3 [w3CStd]
Maia Naftali
82.624
10 - 117
FI-UBA
1.2 Introduccin: 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 algn grado de discapacidad.
Siguiendo pautas de diseo especficas, las pginas Web pueden ser accedidas por una variedad
de usuarios a lo largo de diferentes escenarios. Se incluyen problemas visuales, auditivos, fsicos,
cognitivos, neurolgicos y del habla [WAIintro & Thatcher et al., 2006].
Los usuarios con discapacidad operan las computadoras a travs de dispositivos
especiales, llamados tecnologas 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 pgina abierta.
En un principio las pginas Web consistan en simples textos planos, y eso permita que
se adaptaran muy fcilmente a cualquier tecnologa asistiva. Con el tiempo, el HTML fue
evolucionando hasta llegar a una Web ms grfica. La complejidad agregada tanto a la
estructura como a la presentacin 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 nmero de usuarios de la Web que se ve afectado por las barreras a la accesibilidad no
es un dato menor. Una estadstica realizada por el Trace Center en la Universidad de Wisconsin
[Wisconsin] arroja una tendencia en crecimiento de la poblacin en edad adulta.
Ms all de los nmeros, 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 estndar en las tecnologas para el desarrollo Web, la W3C tiene un
organismo llamado WAI (Web Accessibility Initiative) [WAIabout].
La WAI, surgida en el ao 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
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
creacin de sitios Web, y un User Agent es un software cliente que se conecta a la red
(comnmente se llama as a los navegadores Web o browsers). Es responsabilidad de las
empresas de desarrollo.
2) Tecnologas 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 pginas Web. Es responsabilidad de los
desarrolladores y diseadores.
Diagrama 1.2.1.a El modelo de pautas del consorcio W3 [WAI interdependences, 2005]
La idea original de la WAI al realizar esta separacin 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 hara lo mismo.
Adems, la responsabilidad de resolver la barrera se repartira de forma balanceada [Chisholm &
Henry, 2005],
Maia Naftali
82.624
12 - 117
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 actuara en consecuencia
adaptando el comportamiento. Incorporar una pauta a un navegador o tecnologa asistiva implica
contemplarlo desde la visin del producto. Es por eso que la WAI cuenta con el patrocinio de las
principales empresas informticas del mundo, quienes tienen el compromiso de implementar
dichas pautas en sus productos. Incorporar pautas de accesibilidad al contenido requiere la
adopcin de las mismas en la construccin de las pginas Web.
El desbalance de esta estrategia no est en la separacin de incumbencias, sino en el
volumen: La cantidad de productos o tecnologas es despreciable respecto de los millones de
pginas Web activas alojadas en Internet. Como plantea Chisholm en su estudio, se evita el
sndrome del huevo y de la gallina creando un juego de cooperacin entre las partes. Sin
embargo, una de las condiciones necesarias para el xito del modelo es contar con una fuerte
adhesin 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
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 comunicacin: Muchos mtodos tradicionales estn siendo reemplazados por interfases
Web. Esta tendencia alcanza a la educacin, el comercio, las comunicaciones, la participacin
civil, el cuidado de la salud, la recreacin y las noticias.
Resulta valioso que la Web sea accesible para dar acceso igualitario a las personas con
discapacidad para dar una participacin ms activa. Por otro lado, la Web ofrece una oportunidad
de acceso a la informacin que no tiene precedentes.
Adems de ayudar a las personas con discapacidad, disponer de una Web accesible ofrece
beneficios implcitos 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 obstculo presente en una pgina, que impida ver el
contenido en la forma en que fue concebido por sus autores.
Existen mltiples escenarios cotidianos en donde los usuarios pueden encontrarse con barreras.
Cada tipo de discapacidad es susceptible a determinadas barreras, que generalmente estn
asociadas a la presentacin y al estilo de la pgina.
Maia Naftali
82.624
14 - 117
FI-UBA
Para comprender la complejidad del problema, ser necesario estudiar la forma en la que
cada grupo percibe la Web segn el tipo de discapacidad que presenta [Brewer, 1994].
Tecnologa asistiva
utilizada
- Dispositivos Braille
Prdida de visin - Sintetizadores del Habla o
Lectores
Barreras Principales
- Imgenes o videos que no se pueden describir con texto
- Desorden en la disposicin del contenido: hace que la lectura del
sintetizador no tenga sentido, o sea muy extensa
- Documentos que no se pueden reconocer o leer por los
dispositivos
Daltonismo
- Ajuste de colores
- Configuracin de colores que no puede ser alterada

- Navegadores que no soportan los ajustes del usuario
- Monitores grandes
Baja visin
- Lupas o aumentos
- Pginas que no permiten cambiar el tamao de la letra
- Configuraciones de contraste - Pginas con mala disposicin que se deforman al agrandarse

especiales
Prdida de
audicin
Hipoacusia
Problemas
fsicos
Dificultad en el
habla
- Sistema de subtitulado sobre

el audio (Close Caption CC)
- Ajuste de volumen
- Sistema de subtitulado (CC)
- Falta de subttulos en el audio de una pgina Web

- Requerimientos de ingreso de voz en algunas pginas
- Pginas cargadas de texto con poco material grfico
- Falta de subttulos en el audio de una pgina Web
- Hardware de entrada (en
- Limitaciones en los tiempos de respuesta de las pginas
todas sus variantes ) especial
- Falta de soporte a la navegacin con teclado
- Software de rastreo
- Formularios que no siguen un orden lgico en el ingreso
- Reconocimiento de voz
- Avisos y pop-ups que bloquean la interaccin con la pgina
- Sintetizadores de voz
- Pginas que requieren el ingreso de voz
Problemas
cognitivos y
Ninguna en particular
relacionados con
la edad
- Elementos que distraen la atencin (carteles llamativos )

- Elementos que parpadean o no estn fijos
- Falta de una organizacin clara y consistente de la pgina
- Y cualquiera de las barreras anteriores
Tabla 1.3.1: Barreras de accesibilidad Web
Se puede establecer una clasificacin de las barreras. Por un lado, estn aquellas
relacionadas al estilo de la pgina (colores, tamao, imgenes, audio y video), y por el otro estn
las barreras vinculadas a la disposicin de la informacin (layout). Este ltimo grupo es el ms
difcil de detectar porque requiere evaluar la forma en que se percibe una pgina segn su
estructura de informacin [Sloan et al, 2006]. Puede ocurrir que la disposicin del contenido no
Maia Naftali
82.624
15 - 117
FI-UBA
siga un criterio lgico, o que utilice un vocabulario confuso. Ese aspecto conforma lo que es la
usabilidad de un sitio junto con su ontologa.
Un punto importante es que la mayora de las barreras aparecen cuando las pginas
escapan del esquema habitual del documento de texto. Cada interaccin del usuario con
elementos multimediales genera un problema a la accesibilidad.
1.3.2 Tipos de barreras a la accesibilidad
A continuacin se enumerarn las barreras genricas que se pueden encontrar, independientes de
la tecnologa.
(1) Vinculadas al diseo grfico y al estilo de los elementos:
-
Colores inapropiados: Uso de colores que no permiten distinguir contrastes.
Tamao de los objetos fijo: El texto y las imgenes tienen un tamao fijo, o no se
muestran de forma correcta para todas las resoluciones de pantalla. Dificulta el trabajo
de las lupas.
Mal uso de la tecnologa para armar la distribucin: El estndar HTML, Flash,

Silverlight, o cualquier otra tecnologa mal usada, puede impedir la labor de los
lectores de pantalla.
Usabilidad general deficiente: De los aspectos de usabilidad ms generales, la barrera

principal sera el manejo de los tiempos de respuesta del usuario (por ejemplo, cuando
el texto avanza slo y no se llega a leer). Tambin se incluye la falta de soporte para
teclados y las distracciones innecesarias (Carteles, ventanas emergentes).
Son las barreras ms fciles de quitar desde el lado del desarrollo del sitio.
(2) Vinculadas a la organizacin de la informacin y la semntica
-
Jerarquas mal definidas: La informacin no est bien categorizada (frecuente en

menes y cuadros de seleccin carentes de criterio).
Lenguaje confuso: El texto tiene una interpretacin ambigua o dificultosa

Afectan a las personas con trastornos cognitivos, y en menor medida al resto de la
poblacin. La solucin implica la reorganizacin de la pgina, y la correccin del texto.
Maia Naftali
82.624
16 - 117
FI-UBA
Un punto polmico sobre estas barreras es saber en qu casos el texto no es

comprensible.
Si se tratara de un acertijo o un problema, lograr la comprensin ira en detrimento
del propio fin de resolver el desafo. 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
-
Imgenes sin descripcin: Las imgenes no tienen una descripcin asociada que
permita a las personas no videntes conocer sobre la misma.
Video sin subttulos: El video no tiene subttulos, y eso impide a los lectores de
pantalla reproducir el contenido, y no permite prescindir del audio.
Audio sin transcripcin: 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 opcin alternativa: El contenido forma parte de una

aplicacin hecha en una tecnologa que el usuario no posee o no puede reproducir, y
no hay una opcin alternativa.
La ms frecuente de las barreras es la de las imgenes sin descripcin, ya la
mayora de las pginas actuales poseen grficos o fotos. La solucin pasa por agregar
una descripcin de texto a cada elemento grfico presente en la pgina (Ese atributo
descriptivo es llamado ALT en el HTML).
Respecto al audio y al video, el agregado de subttulos requiere que el usuario escriba
el texto y lo sincronice.
Las aplicaciones que corren dentro de pginas Web y no pueden ser reproducidas
deben brindar contenido alternativo. En muchos casos este tipo de barrera se presenta
porque la tecnologa fue mal empleada, o la misma es susceptible a esos problemas.
Maia Naftali
82.624
17 - 117
FI-UBA
1.3.3 Ejemplos de barreras a la accesibilidad

Algunas aclaraciones
Muchas barreras procedentes del uso de tecnologas diferentes del HTML son eliminadas
en versiones posteriores de las mismas; lo mismo ocurre con algunas de las prcticas de
construccin de sitios, que con el tiempo caen en el desuso.
Es errneo asociar a las tecnologas directamente con el problema, ya que stas poseen
mtodos que permiten eliminar las barreras que pudieran presentar. La paradoja es que, si bien
las tecnologas ms novedosas mejoran la accesibilidad, en los primeros tiempos de uso pueden
tener problemas de compatibilidad con el entorno de los usuarios. Esto podra derivar en otra
barrera si no se ofrece una opcin compatible.
A continuacin se exponen ejemplos sobre el avance de la accesibilidad a lo largo del
tiempo en las tecnologas ms utilizadas al momento:
Adobe Flash/ Flex : Existen mtodos nativos para otorgar accesibilidad a las imgenes y
formularios. Flash 6 fue la primera versin 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 grficos de Silverlight poseen
atributos para ser ledos por tecnologas asistivas. El Framework 3.5 delega la interaccin
con las tecnologas asistivas en el componente UIAccess, que hace de intermediario entre
el contenido y su presentacin al usuario.
JavaScript: En la actualidad, la mayora de los navegadores lo soportan. Originalmente era
una barrera por la compatibilidad, y tena inconvenientes con los dispositivos mviles.
Youtube Videos : Permite agregar subtitulado a los videos con soporte multi-idioma.
PDF: Adobe puso a disposicin documentos que explican cmo generar PDFs
accesibles., y tambin proporciona una herramienta para verificar la accesibilidad en los
documentos.
Maia Naftali
82.624
18 - 117
FI-UBA
Ejemplos de Barreras:
Se analizarn las barreras desde cuatro aspectos: Inconveniente, causas por las cuales aparecen,
usuarios impactados por la barrera, y mitigacin tecnolgica (Ideas o mecanismos que se
ayudaran a resolver el problema haciendo uso de tecnologas no especficas)
1. Pginas con tamao absoluto
Inconveniente: La pgina se deforma cuando se intenta aumentar o reducir el tamao
Causas: Mala definicin del layout, Uso de medidas en pxeles y no porcentuales,
Intencin de ajustarse a resoluciones fijas, Uso de tecnologas anexas al HTML sin
opcin de ajuste de tamao, Incompatibilidades con las herramientas de autor.
Impacto: Usuarios con baja visin, usuarios de dispositivos mviles, netbooks pantallas
no convencionales
Mitigacin tecnolgica: Navegadores con lupa grfica (no de caracteres).
Escenarios tpicos: Generalizado.
2. Presencia de elementos intermitentes y rotativos
Inconveniente: El contenido no queda fijo, dificultando su lectura
Causas: Eleccin de diseo,
Impacto: Usuarios de edad avanzada, usuarios con epilepsia, usuarios con dislexia y
trastornos cognitivos.
Mitigacin tecnolgica: Botn de pausa para el contenido rotativo.
Escenarios tpicos: Espacio publicitario, peridicos, pginas con animaciones y
elementos grficos dinmicos
3. Cdigos de seguridad o Captcha
Captcha es la sigla de Completely Automated Public Turing test to Tell Computers and
Humans Apart. En general, esta tcnica es empleada para evitar que robots programados
puedan atacar al sistema en cuestin. Se le muestra al usuario una secuencia de nmeros
en un formato grfico, 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 tendra 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
FI-UBA
Impacto: Usuarios con baja visin, usuarios con ceguera, usuarios con problemas
cognitivos
Mitigacin tecnolgica: Ninguna ya que eso implicara romper el algoritmo. La opcin
alternativa consiste en brindar esa secuencia en formato de audio, o proporcionar algn
otro circuito que permita realizar esa operacin.
Escenarios tpicos: Alta y consulta de servicios (cuentas de correo electrnico,
suscripciones, juegos en lnea, pagos).
4. Uso de tecnologas anexas al HTML, sin contenido alternativo
Inconveniente: El contenido puede no ser compatible con el navegador o la plataforma.
Causas: Uso de tecnologas diferentes del estndar HTML para mostrar el contenido, que
no contemplan una opcin alternativa.
Impacto: Usuarios con tecnologas asistivas antiguas, usuarios con plataformas que no
poseen o no soportan dichas tecnologas
Mitigacin tecnolgica: Escenarios tpicos: Pginas con versiones recientes, pginas con animaciones o
interaccin grfica, complementos Active-X bloqueados.
5. Falta de soporte a la navegacin por teclado
Inconveniente: La pgina impide la interaccin con el teclado
Causas: Uso de tecnologas anexas al HTML sin soporte para teclados y dems
dispositivos.
Impacto: Usuarios con problemas de motricidad, usuarios de edad avanzada, usuarios con
diversos dispositivos de entrada basados en el teclado.
Mitigacin tecnolgica: Escenarios tpicos: Pginas que utilizan tecnologas diferentes al HTML, publicidades,
animaciones.
Esta barrera adems afecta a la usabilidad de una pgina.
Maia Naftali
82.624
20 - 117
FI-UBA
6. Pginas muy extensas sin marcas ndice

Inconveniente: La cantidad de texto en la pgina obliga a los usuarios con lectores de
pantalla a realizar un recorrido lineal de principio a fin. La navegacin se ve entorpecida.
Causas: Falta un ndice o de marcas de posicin en el texto para separar prrafos y
organizar el contenido.
Impacto: Usuarios con lectores de pantalla
Mitigacin tecnolgica: Las versiones ms recientes permiten la lectura no secuencial
con marcas inteligentes.
Escenarios tpicos: Contratos, resoluciones, normativas, publicaciones.
7. Uso de tablas anidadas para contener la informacin.
Es una prctica ampliamente utilizada, que debera ser reemplazada por estilos CSS.
Inconveniente: Los lectores de pantalla no interpretan correctamente el orden de la
pgina, interfiriendo con su interpretacin. (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 disposicin de la informacin. Fue una prctica
muy empleada cuando se dejaron de usar marcos en el HTML.
Impacto: Usuarios con lectores de pantalla.
Mitigacin tecnolgica: Lectores de pantalla que permiten la lectura no secuencial. Se
podra mitigar desde la inteligencia del lector, aunque no sera lo correcto.
Escenarios tpicos: Prcticamente todas las pginas que no utilizan estilos de forma
correcta, o fueron hechas con herramientas de autor que resuelven las cuestiones de
diseo con tablas anidadas.
8. Limitaciones en los tiempos de respuesta de las pginas
Es una barrera que tambin interesa a los fines de la usabilidad.
Inconveniente: La pgina no permite al usuario tener control de los tiempos,
imposibilitando la navegacin.
Causas: Presencia de animaciones o temporizacin de eventos con escaso margen.
Impacto: Usuarios de edad avanzada, usuarios con problemas cognitivos, baja visin, y
motricidad.
Mitigacin tecnolgica: Desde el navegador, se puede solicitar una pausa o pedido de
confirmacin para cierto tipo de comportamiento.
Maia Naftali
82.624
21 - 117
FI-UBA
Escenarios tpicos: Sitios con animaciones, publicidad, contenido rotativo, formularios,

exmenes, presentaciones de fotografas.
9. Presencia de contenido multimedia accesorio no solicitado que no tiene opcin
alternativa
Inconveniente: Las pginas presentan contenido multimedial sin solicitarlo, y no
permiten deshabilitarlo o recibir en su lugar contenido accesible.
Causas: Eleccin de diseo
Impacto: Todos los usuarios
Mitigacin tecnolgica: En algunos casos, configurar el navegador para que no muestre
cierto tipo de contenido.
Escenarios tpicos: 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 proteccin del material, el contenido se bloquea para evitar la copia
Impacto: Usuarios con lectores de pantalla
Mitigacin tecnolgica: Desde el software del lector, se podra implementar el
reconocimiento de caracteres.
Escenarios tpicos: Pginas con normativas, leyes, documentacin digitalizada,
publicaciones varias.
11. Frmulas matemticas utilizando imgenes:
Inconveniente: Los lectores de pantalla no pueden interpretar las frmulas
Causas: Uso de grficos sin texto alternativo para expresar frmulas en lugar del estndar
MathML, o imgenes con texto alternativo.
Impacto: Usuarios con lectores de pantalla.
Mitigacin tecnolgica: Uso de software para reconocimiento de caracteres (OCR) que
pueda detectar frmulas sencillas.
Escenarios tpicos: Pginas educativas, universidades, publicaciones, problemas.
Maia Naftali
82.624
22 - 117
FI-UBA
12. Configuracin de colores fija

Inconveniente: El contenido contiene colores de fondo fijos (sucede con los fondos
provenientes de archivos de imgenes). El software asistivo para cambio cromtico no
puede intervenir, y los colores que se muestran no son percibidos por los usuarios con
ceguera al color.
Causas: Decisiones de diseo y estilo.
Impacto: Usuarios con ceguera al color, usuarios de edad avanzada o con baja visin.
Mitigacin tecnolgica: Filtros desde el monitor (requieren soporte del hardware grfico).
Escenarios tpicos: Pginas con elementos grficos animaciones, publicidad.
13. Pop-Ups (Pginas Emergentes) que bloquean la interaccin con la pgina
Inconveniente: La pgina que se estaba accediendo pierde el foco ante la aparicin de una
ventana emergente con publicidad, avisos, contenido, etc.
Causas: Publicidad, decisiones de diseo.
Impacto: Usuarios con problemas cognitivos, edad avanzada, baja visin, ceguera.
Mitigacin tecnolgica: Bloqueo de ventanas emergentes desde el navegador. El
problema ocurre cuando las ventanas emergentes no son publicidades.
Escenarios tpicos: Publicidades, avisos, excepciones, extensin de la pgina.
14. Pginas con elementos multimedia (Sonido, video) sin subttulos, imgenes y
formularios sin texto o atributo descriptivo
Inconveniente: Los lectores de pantalla no pueden mostrar el contenido multimedia una
descripcin del mismo.
Causas: Falta de soporte para subttulos, omisin de los atributos de texto alternativo.
Impacto: Usuarios con ceguera, usuarios con baja visin, usuarios con baja audicin,
usuarios con sordera, usuarios sin salida de audio, usuarios bajo situaciones especiales
(acceso por dispositivos mviles, ambientes ruidosos).
Mitigacin tecnolgica: Para el audio, se podra plantear un reconocimiento de voz que
trabaje con un buffer, aunque requerira del uso de un idioma neutro junto con algn
algoritmo de aprendizaje para entrenar a la herramienta; En cuanto a las imgenes, se
podra leer parte de su ttulo el nombre del archivo en el caso de que no posea texto
alternativo.
Escenarios tpicos: Pginas con contenido multimedial, video streaming, radios.
Maia Naftali
82.624
23 - 117
FI-UBA
1.4 Las pautas para lograr la accesibilidad Web

Como se expuso anteriormente, el consorcio W3 a travs de su organismo para la
accesibilidad (WAI) desarroll un modelo de pautas con tres niveles.
En esta seccin se enunciarn las pautas en su nivel ms elemental. Cada tem de las pautas
posee documentos anexos que explican en detalle cmo alcanzarla y verificar su cumplimiento,
disponibles en la pgina de la WAI (Ver las referencias a los vnculos en el glosario).
1.4.1 UAAG: User Agent Accessibility Guidelines

User Agent es todo programa que recupera, reproduce y facilita la interaccin entre el
usuario y el contenido [UAAG 2.draft, 2009]. Las pautas de accesibilidad para User Agents
UAAG 1.0 fueron liberadas en el ao 2002 (Existe un borrador de la versin que saldr en el
ao 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 tecnologa [link:
Testimonials].
HP, IBM, Sun, Opera, Microsoft, Macromedia y otras tantas estn en la
necesidad de cumplir los 14 puntos de control (checkpoints) para sus productos:

Algunos de los puntos de control son los siguientes (La numeracin no est relacionada
con el cdigo que fijan las UAAG) [UAAG 2.0]:
1. Asegrese de que la funcionalidad no basada en la Web sea accesible.
2. Asegrese de que la funcionalidad basada en la Web sea accesible.
3. D soporte a las funcionalidades de accesibilidad de las tecnologas que interprete o
muestre.
4. Muestre el contenido acorde con la especificacin.
5. Facilite el acceso a la programacin 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 interaccin 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
FI-UBA
12. Provea bsqueda en el texto.

13. Provea navegacin estructurada.
14. Provea barras de herramientas personalizadas.
15. Ayude a los usuarios a eludir mensajes de alerta innecesarios.
Muchos de los puntos estn vinculados con la usabilidad. El foco est puesto en lograr un
software configurable y manejable, que tenga una forma abierta de comunicacin mediante
eventos (una API, por ejemplo). Se trata de que las diversas tecnologas asistivas puedan
interactuar con el software sin impedimentos.
1.4.2 ATAG: Authoring Tools Accessibility Guidelines

Una Authoring Tool es una aplicacin 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 dems aplicaciones que permiten generar pginas Web.
Al igual que en las pautas para User Agents, existe un borrador del documento a liberar
en el ao 2010. La versin 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
inters, 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 tecnologas de contenido Web que permitan la creacin 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. Asegrese de que las acciones para lograr la accesibilidad sean integradas y
promovidas.
Maia Naftali
82.624
25 - 117
FI-UBA
El foco est puesto en brindar asistencia al usuario creador de contenidos. Dado que son
recomendaciones, la redaccin es muy genrica porque slo habla de asistencia. Queda en el
criterio de los diseadores de la herramienta la forma en la cual implementarn dicha asistencia.
1.4.3 WCAG: Web Content Accessibility Guidelines

Las pautas WCAG estn dirigidas a quienes generan en contenido para la Web. Consisten
en recomendaciones puntuales, redactadas de una forma menos genrica que el resto de las
pautas anteriores. El foco est puesto en lograr que el contenido sea presentado de forma
accesible. La WAI elabor guas anexas que explotan cada punto y detallan los pasos a seguir
para implementarlas y cumplirlas. Como se plante en el captulo 1.2 de este trabajo, este
modelo de pautas est centrado en el contenido.
1.4.3.1 WCAG 1.0
Es la primera versin de las pautas, y fue liberada en el ao 1999. (En la actualidad est
siendo reemplazada por la versin 2.0, pero sigue en uso hasta el momento). WCAG 1.0
Consiste en catorce principios generales de diseo accesible. Cada uno de ellos define un punto
de control sobre el cual el cumplimiento es verificado. Los puntos estn priorizados del 1 al 3:
[WCAG 1.0].
Prioridad 1: Debe ser cumplido. Es un requerimiento bsico.
Prioridad 2: Debera ser cumplido. Remueve ciertas barreras.
Prioridad 3: Podra ser cumplido. Mejorara 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 genricas para la accesibilidad definidas son las siguientes:

1. Provea alternativas equivalentes para contenido visual y auditivo.
2. Asegrese de que tanto el texto como los grficos se puedan ver sin color (modo
monocromtico).
Maia Naftali
82.624
26 - 117
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. Asegrese de que las pginas que contienen elementos de tecnologas nuevas se puedan
ver de forma correcta an cuando stas no se encuentren disponibles.
7. Asegrese de que los objetos mviles o destellantes puedan ser controlados por el
usuario.
8. Asegure la accesibilidad de los objetos embebidos en su pgina.
9. Utilice un diseo independiente del dispositivo de entrada.
10. Utilice soluciones intermedias hasta que las tecnologas asistivas den soporte al diseo
original.
11. Siga las pautas, y en caso de resultar imposible, provea una solucin alternativa paralela.
12. Provea informacin de contexto que oriente al usuario.
13. Provea mecanismos claros de navegacin.
14. Asegrese de que los documentos son claros y simples.
Existen ejemplos y casos puntuales en cada uno de los puntos, que de cumplirlos, darn un grado
de conformidad global.
La mayora de las leyes sobre accesibilidad estn basadas en el cumplimiento de estas
pautas, pese a la antigedad que tienen. Existen adems herramientas para validar y asistir al
desarrollo de contenidos, tambin basadas en 1.0.; sin embargo, la evolucin de la Web hizo
necesaria una reforma. Esta versin est basada en el HTML y muchas de las recomendaciones
estn concebidas segn las formas de trabajo del HTML y de las hojas de estilo. Las nuevas
tecnologas para creacin de pginas Web, no basadas en HTML, no pasaran la conformidad
ms bsica de las WCAG 1.0, an siendo accesibles como se aclar en la seccin 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
FI-UBA
1.4.3.2 WCAG 2.0

La versin ms reciente al momento de las pautas WCAG fue liberada en diciembre del
2008 luego de dos aos de revisiones y mejoras. El modelo 1.0 tena el inconveniente de la
dependencia tecnolgica. Las pautas hacen mencin a idioms o prcticas recurrentes de
generacin de contenidos.
Si bien el autor puede seguir WCAG y lograr la conformidad mxima, no hay un control
acerca de cmo el usuario est accediendo al contenido. [Kelly et al, 2007]. En diez aos la
variedad de plataformas y tecnologas asistivas para acceder a la Web creci, y es necesario
replantear el significado de la conformidad. Los cambios ms importantes que trajo la versin
2.0 son la separacin tecnolgica y la reorganizacin 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 diseo. Cada uno de ellos contiene pautas, de las
cuales existen tres diferentes criterios de xito. [WCAG 2.0, 2009].
Los cuatro principios de diseo 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 navegacin deben ser
operables.
3. Comprensibilidad: La informacin 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
mltiples agentes de usuario y tecnologas asistivas.
El nuevo documento de pautas es ms extenso y detallado que su antecesor. Ante el
aumento de la abstraccin, fue necesario ampliar cada pauta con un documento anexo que
explica posibles implementaciones. A continuacin se mostrar el primer nivel de las pautas, que
se encuentra detallado en el documento original publicado por la WAI.
Perceptibilidad
Maia Naftali
Proporcione alternativas textuales para el contenido no textual.
Contenido multimedia dependiente del tiempo. Proporcione alternativas sincronizadas.
82.624
28 - 117
FI-UBA
Adaptabilidad: Cree contenidos que puedan presentarse de diferentes maneras (como una
composicin ms simple) sin perder la informacin ni su estructura.
Haga ms fcil para los usuarios ver y distinguir el contenido, incluyendo la separacin
entre primer plano y fondo.
Operabilidad
Accesible a travs 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 pginas 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 tecnologas asistivas.
Criterios de xito Requisitos de conformidad para toda la pgina:

Dentro de cada pauta hay puntos a cumplir con criterios de xito establecidos, y cada uno una
prioridad que va desde A (bsico) hasta AAA.
Nivel A: La pgina satisface con todas las pautas de nivel A, existe una pgina
alternativa que las satisface.
Nivel AA: La pgina satisface todas las pautas de nivel A y AA, o bien satisface A y
existe una pgina alternativa que cumple con AA.
Nivel AAA: La pgina satisface A, AA y AAA, o bien satisface A, AA y existe una
pgina alternativa que lo hace con AAA.
Maia Naftali
82.624
29 - 117
FI-UBA
El nivel de conformidad se aplica a pginas completas, tomando todo el conjunto de

puntos de control presentes. Si la pgina 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 tecnologa a adoptar, y la redaccin de las pautas es
abstracta, se establece que la misma debe dar soporte para la accesibilidad, o bien, no interferir
con la opcin alternativa accesible.
Otro punto central es que las pginas paralelas accesibles permiten cumplir con los niveles
de conformidad. Es decir, se pueden mantener dos versiones de una pgina (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 ms activo de ellos. Se opona porque
asociaba al contenido alternativo con pginas de texto plano (sin estilo), y argumentaba que de
esa forma no se podra generar la misma experiencia al navegar [Clarck, 2003]. Con la
afirmacin The bottom line is that separate is not equal (Trad: La conclusin es que separar
no es igualitario), Clarck pretenda evitar una solucin que utilice pginas de texto generadas
automticamente por aplicaciones en los servidores Web. Realiz crticas a WCAG 2.0 an
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 separacin de incumbencias que trae WCAG 2.0 (Percepcin, Comprensin,
Operacin, Robustez) mitiga los argumentos en contra de permitir pginas en paralelo que sean
accesibles. Es una medida consistente con la abstraccin tecnolgica del modelo.
1.4.3.3 Evaluacin Verificacin del cumplimiento de las pautas para contenido

La WAI desarroll un conjunto de procedimientos para evaluar el cumplimiento de las
pautas para accesibilidad Web. Adems de que cada punto de control (checkpoint) posee un
criterio de xito, se toma al conjunto de pginas para realizar la revisin y calificar con A, AA
AAA [EvaluatingAccesibility].
Maia Naftali
82.624
30 - 117
FI-UBA
WCAG 1.0 es ms simple de evaluar por estar basada en el HTML y tener criterios de
xito puntuales. Existen validadores automticos que realizan el trabajo de verificar cada punto
de las pautas. Dentro de los ms conocidos: Bobby, TAW, Hera. Una de las principales crticas
al modelo WCAG 2 es la mayor dificultad para evaluar las pautas que no dependen de una
tecnologa especfica. 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 evaluacin de las pautas propuesto por WCAG 2.0 requiere de la
intervencin de un grupo de personas. Las herramientas automticas fallan a la hora de detectar
barreras que provienen de la percepcin.
Por otra parte, el cumplimiento de las pautas y el aseguramiento de la accesibilidad no
estn 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 pgina sea accesible
[Sloan et al, 2006]; como se mostr, una pgina con tecnologas no contempladas por las pautas
WCAG 1.0 tambin puede ser accesible pese a no cumplir los criterios de conformidad.
Cumplimiento de Pautas No implica Accesibilidad
Una excepcin frecuente es la legibilidad del contenido. Las pautas expresan que el contenido
debe ser legible y comprensible, y proporcionan tcnicas para conseguirlo. No obstante, el
criterio de xito de este punto consiste en un desafo respecto de su evaluacin. Se puede generar
contenido comprensible para un cierto grupo de usuarios, pero es incorrecto generalizar hacia
todos los dems 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 podan reproducir la
misma experiencia: El texto alternativo sobre el ejercicio de examen otorgara al usuario indicios
de la solucin. Era necesaria otra tcnica para lograr el entendimiento de dicha imagen, que por
carecer de texto alternativo, podra no cumplir con la conformidad
Maia Naftali
82.624
31 - 117
FI-UBA
Se puede afirmar solamente que el cumplimiento de las pautas empleando las tcnicas
recomendadas garantiza la accesibilidad en la mayora de los casos. Para contemplar al resto es
necesaria una validacin ms profunda. Los procesos de evaluacin recomendados por la WAI
sugieren la formacin de grupos heterogneos de individuos para realizar las pruebas de
accesibilidad. Mejorando el tipo de pruebas es posible ampliar el grupo de usuarios para los
cuales la pgina es accesible.
En el segundo captulo de ste trabajo se profundizar sobre la evaluacin de pginas, y su
relacin con la accesibilidad de las pginas Web.
1.4.4 Anlisis del modelo de pautas

Las pautas para accesibilidad en la Web de la WAI conforman un estndar de hecho en la
actualidad.
A pesar de su amplio alcance, existen estudios sobre diversos enfoques para
implementar las pautas en la prctica.

Como sucede con todos los modelos de referencia (por ejemplo ITIL CMMI), existe un
brecha entre la definicin y la aplicacin de los mismos.
Tanto CMMI como WCAG indican cules son las buenas prcticas a seguir para lograr un
objetivo, salvando la escala. El problema que presentan ambas es que, en el afn por lograr la
conformidad, se pierde de lado ese objetivo inicial.
La estrategia a adoptar debera incluir un anlisis previo de las necesidades, y el
involucramiento de los usuarios crticos. La decisin acerca del nivel de conformidad a alcanzar
est determinada por los usuarios finales y la criticidad del contenido. Esto se contrapone a la
adopcin de las pautas como una receta de cocina.
El enfoque holstico: modelo del Tangram
Sobre la problemtica anterior, Brian Kelly, David Sloan y equipo plantean un enfoque
original sobre las pautas [Sloan & Kelly, 2006], llamado el Enfoque Holstico (An Holistic
Approach). (En [Thatcher et al, 2006] se induce a una idea similar, resaltando que lo ms
importante es la presencia del usuario, y no tanto la conformidad con las pautas).
Maia Naftali
82.624
32 - 117
FI-UBA
El propsito del enfoque es proveer una solucin que maximice la utilidad hacia el
usuario final, en contraposicin a la metodologa basada en WAI que alienta a la aplicacin
obligatoria de un conjunto limitado de pautas. La metfora del Tangram fue hecha para aclarar
que las soluciones ms apropiadas pueden ser obtenidas involucrando al usuario, en lugar de
aplicar las reglas [Sloan et al, 2008].
Diagrama 1.4.4: Grfico 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 metfora con este modelo de accesibilidad es que una figura se puede armar como suma y
combinacin de partes.
Los autores partieron de la necesidad de proveer un conjunto de pautas ms amplio y flexible.
Sera el desarrollador o el creador de contenido quien elegira el subconjunto de las pautas a
aplicar segn el contexto. Esto permitira reutilizar las adaptaciones en contextos similares.
Las soluciones ms adecuadas pueden obtenerse mediante la participacin de los usuarios, en
lugar de limitarse a la aplicacin de normas.
Dentro de las caractersticas de este planteo, se destacan:
Maia Naftali
Es extensible.
Alcanza la accesibilidad en IT, sin limitarse a la Web.
Se puede implementar bajo muchas normativas,
Tecnolgicamente neutral.
Proporciona
82.624
una
forma
ms
realista
de
asegurar
la
accesibilidad.
33 - 117
FI-UBA
Una posible implementacin de un modelo sobre WCAG

En el trabajo titulado A Framework for Filtering Web Accessibility Guidelines
[Baguma et al, 2009], se realiza una implementacin prctica 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 informacin desea
obtener (tcnica, consejos, explicacin), qu contexto de uso (navegacin, interfaz) y con qu
profundidad se mostrar la informacin solicitada.
Ingresando esos datos el desarrollador accede a la informacin sobre las pautas de forma
ordenada y limitada. Esto facilita su implementacin y a la vez asegura la accesibilidad en esos
aspectos fijados por la matriz del filtro.
Maia Naftali
82.624
34 - 117
FI-UBA
1.5 Las normativas de Accesibilidad Web

1.5.1 Antecedentes
Muchos pases 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 jurisdiccin [Thatcher et al, 2006].
Los antecedentes de este movimiento sucedieron alrededor del ao 1995 tanto para la Unin
Europea como para los Estados Unidos.
La primera legislacin sobre accesibilidad general en los Estados Unidos fue American
and Disabilities Act, conocida como ADA, y data del ao 1992. Abarca al trabajo, la
construccin, la educacin, el transporte, las comunicaciones (en donde se incluira la
accesibilidad en la Web), la recreacin, la salud y dems servicios. En ese momento el alcance de
Internet era limitado y la Web era mucho menos grfica, por lo tanto garantizar la accesibilidad
no requera del soporte pautas ni lineamientos tcnicos complejos. Para el ao 1998, los Estados
Unidos adoptan la Section 508, que es la primera normativa especfica para accesibilidad Web
de ese pas [Paciello, 2002].
La Unin Europea inici diversos proyectos en el ao 1994. A travs de la entidad
Information Society for All, lanzada por la Comisin Europea en el ao 1999, se iniciaron
acciones para liberar normativas que regulen la accesibilidad Web. Los planes de accin
eEurope 200X, basados en WCAG, alcanzan a los sitios del sector pblico. Por otro lado,
existe el WAB Cluster, entidad que se encarga de la evaluacin y el monitoreo de los sitios
Web de todos los pases, generando informes y mtricas actualizadas [Thatcher et. al, 2006].
1.5.2 Normativas particulares
Section 508
En el ao 1998 el congreso de los Estados Unidos promulg el Rehabilitation Act para
exigir que los organismos oficiales hagan su tecnologa de la informacin accesible para las
personas con discapacidad. La ley aplica para todos los organismos oficiales cuando desarrollan,
mantienen o utilizan de la electrnica y la tecnologa de la informacin. Bajo esta ley, se debe
otorgar a empleados con discapacidades y dems miembros acceso pblico a la informacin
[Wikipedia Section 508].
Maia Naftali
82.624
35 - 117
FI-UBA
Section 508 est dirigida al cumplimiento legal a travs del proceso de investigacin de mercado
y contratacin pblica. Adems tiene estndares tcnicos para poder comparar y evaluar la
conformidad de los productos. Esta ley no aplica para pginas Web privadas, excepto que
reciban fondos federales o estn bajo un contrato de la agencia federal. Todos los proveedores
del estado la deben cumplir.
Resea de los puntos centrales de la ley:
Aplicaciones de software y sistemas operativos: incluye accesibilidad para personas no videntes
garantizando el de soporte de tecnologas asistivas y pautas de diseo 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), audfonos y dems tecnologas para mejorar la
audicin.
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 diseo.
Computadoras porttiles y de escritorio: Abarca la accesibilidad para usuarios con problemas de
movilidad. Requiere la posibilidad de incorporacin de controles para operarla, como pantallas
tctiles, teclados especiales y comandos por voz.
Como WCAG 1.0 no fue desarrollada segn el marco legal no fue posible que los Estados
Unidos lo adoptasen como estndar. Sin embargo, US Access Board reconoci que deberan
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 slo una fraccin de las pautas
WCAG. Es necesario cumplir adems con pautas no contempladas para otorgar accesibilidad a
una mayor cantidad de grupos [Thatcher et al, 2006].
Maia Naftali
82.624
36 - 117
FI-UBA
Unin Europea: eEurope

La iniciativa eEurope Una sociedad de la informacin para todos fue lanzada en el
ao 1999. En el plan de accin del ao 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 ao 2001, se exiga a
las pginas Web de la administracin pblica cumplir con conformidad A de WCAG 1.0.
[eEurope]
En la declaracin Ministerial de Riga, ao 2006, se fij que en el ao 2010 todos los sitios
pblicos deben se accesibles. En dicha declaracin se enfatizan los puntos que deberan seguirse,
y se recomiendan polticas a seguir por la Unin Europea para difundir la accesibilidad Web.
Actualmente se estn migrando las pautas hacia WCAG 2.0.
Adems de mantener el tema en su agenda, la Unin Europea dispone de un laboratorio
para medir la accesibilidad global de forma automtica. Tambin a travs de la UWEM (A tratar
en el captulo 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
FI-UBA
1.6. El problema de la creacin de sitios Web accesibles

En esta seccin sern tratados temas en torno a la problemtica de la creacin de pginas
Web accesibles. En la actualidad, la generacin de contenido para Web es por defecto no
accesible. Lograr ese estado requiere un esfuerzo importante por parte de quienes intervienen en
la elaboracin de la pgina. La dificultad para recorrer el camino hacia la accesibilidad explica
los pobres resultados en el campo, y la falta de madurez de las tcnicas para el aseguramiento.
1.6.1 Los Mitos de la accesibilidad Web

La mayora de los mitos tienen origen en el avance de las tecnologas. Como se mencion
anteriormente con las barreras, una implementacin tecnolgica nueva puede solucionar algunos
problemas del pasado.
Mito
1:
Ofrecer
una
alternativa
de
slo-texto
hace
la
pgina
accesible.
Es falso, dependiendo de cmo se ubique el vnculo a esa pgina de texto puro. Puede ser una
barrera para personas con problemas cognitivos si fuera difcil de encontrar. Por otro lado, las
versiones de texto sin marcas o etiquetas no ofrecen una experiencia cmoda 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 interpretacin de las pautas desde la restriccin absoluta. En WCAG
1.0 era comn pensar en que no haba que usar JavaScript; sin embargo, la pauta literalmente
deca que haba que asegurarse de que los elementos como scripts applets se mostraran an sin
disponer de soporte. En la actualidad la mayora de las tecnologas 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 diseo 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 diseadores. El mundo del diseo se genera desde lo visual, y es necesario salir de l
para poder reproducir las experiencias desde los otros sentidos. La conclusin que extrae es que
Maia Naftali
82.624
38 - 117
FI-UBA
los diseadores perciben la estandarizacin como una restriccin a su creatividad, y que no

existen motivos tcnicos para separar la accesibilidad del diseo.
Mito 3: La accesibilidad es complicada y costosa
Es un mito que va a tender a desaparecer con el desarrollo de las tecnologas 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 lgica del negocio, pero lo cierto es que
existe un costo inicial en los proyectos accesibles. Se utilizan para capacitacin, implementacin
de pautas y pruebas con usuarios.
Mito 4: Las herramientas de evaluacin pueden determinar si es accesible o no una pgina
Es falso. Como se ver en la segunda parte del trabajo, las herramientas slo pueden verificar la
presencia o ausencia, pero no el sentido. Es necesario involucrar a personas en el proceso de
evaluacin.
1.6.2 El camino para lograr contenido Web accesible

Una gran parte de la bibliografa recomienda seguir algunas prcticas y estndares de
codificacin, con el fin de lograr conformidad con las pautas.
Se alienta a que desarrolladores y diseadores cambien sus prcticas habituales de desarrollo y
generacin de contenidos. Luego del cambio, se sugiere realizar una validacin automtica con
alguna herramienta que verifique las pautas, que adems informar qu puntos estn siendo
violados de las WCAG. El paso siguiente ser entonces corregir y depurar la pgina, hasta
obtener el grado de conformidad con WCAG deseado. (Existen mtodos ms formales para el
testeo de la pgina tratados en la segunda parte, aunque lo usual es asociar este proceso a
herramientas automticas).
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
FI-UBA
La llamada Web 2.0 es una denominacin (utilizada por el marketing, entre otros) para
caracterizar la tendencia creciente a la generacin de contenidos por parte de los usuarios. Siendo
la Web una estructura creada por gente de conocimientos heterogneos, la imposicin de un
proceso como el anterior para alcanzar la accesibilidad difcilmente triunfe.
Se requieren
capacidades tcnicas que no se le pueden exigir a la comunidad, y eso atentara contra el ideal de
la Web de Tim Berners-Lee [Byrne, 2009].
An as, el cumplimiento de las pautas es la forma empleada en la actualidad para lograr
contenido accesible. La mayora de las fuentes recomiendan implementar la accesibilidad de esa
forma [Thatcher et al, 2006 & Paccielo 2002]. En contraposicin 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
FI-UBA
1.6.3 Dificultades que se presentan
En el siguiente diagrama de Ishikawa se resumen las causas que dificultan la implementacin de

la accesibilidad en la Web. Cada nodo representa una posible causa del hecho central.
Diagrama 1.6.3: Dificultad en la implementacin de una Web accesible.
Detalle de los recuadros:

I.
Tecnologas: Abarca a aquellas empleadas para generar, mantener visualizar el

contenido de la Web.
II.
Estrategias: Es el conjunto de pautas y prcticas 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
jurisdiccin.
A continuacin se analizar la incidencia de cada causa presente en el diagrama.
Maia Naftali
82.624
41 - 117
I.
FI-UBA
Tecnologas
a. Escalamiento poco aprovechado
Gran parte de las barreras relacionadas al contenido podran ser eliminadas si se delegara
parte de la responsabilidad en el software que lo presenta. El contenido puede dar
informacin a componentes que se ocupen de presentarlo minimizando el impacto de las
barreras y mejorando la interaccin con las tecnologas asistivas. Windows Presentation
Foundation, implementado adems 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
informacin para que las tecnologas 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 tecnologas asistivas poseen un ciclo de vida ms largo, especialmente
aquellas que son por hardware debido su alto costo. Este desfasaje redunda en nuevas
barreras temporales para las tecnologas incompatibles al estndar del momento.
c. Mal uso de la tecnologa o del estndar para crear pginas
Muchas herramientas para crear contenido permiten incorporar elementos a la pgina que
atentan contra la accesibilidad Web.; Desde sitios no-HTML, hasta animaciones, sonidos
y grficos destellantes. En general se provee una forma de realizar un diseo accesible,
pero no es el mtodo por defecto.
Productos como Adobe Dreamweaver o Visual Studio por ejemplo, poseen validadores
de pautas WCAG en sus versiones ms recientes. Pese a que informan sobre eventuales
barreras, su eliminacin depende de cmo el usuario lo interprete y resuelva.
Maia Naftali
82.624
42 - 117
II.
FI-UBA
Estrategias
a. Proceso de evaluacin inmaduro
La evaluacin o testing de las pginas Web es un proceso an inmaduro. Hay
metodologas como UWEM, tratada en el segundo captulo, 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
automticas,
que
realizan
pruebas
de
accesibilidad
las
pginas
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 metodologa de evaluacin hecha
por la WAI como aquella propuesta por UWEM sugieren que parte del testing sea
realizado de forma manual. Por otra parte, existe una lnea diferente que sostiene que la
evaluacin debera enfocarse en la deteccin de barreras, y no en la conformidad con las
pautas.
El proceso de evaluacin es crtico, y se debera disponer de tcnicas ms simples y
estandarizadas con indicadores directos. En el captulo II se tratar con detalle este
problema, analizando las mtricas que se proponen y su significado.
b. Reinvencin de la rueda
La reinvencin de la rueda es una expresin 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 reinvencin de la rueda. Un sitio Web
puede tener un desarrollo nico e irrepetible, al igual que todo proyecto. En consecuencia,
la implementacin de pautas de accesibilidad en ese sitio sera slo aplicable en esa nica
instancia.
Para que puedan existir procesos que eviten esta reinvencin, es necesario encontrar
una serie mnima de pasos que al ejecutarlos resuelvan todos los problemas de
accesibilidad.
Maia Naftali
82.624
43 - 117
FI-UBA
i. Procesos artesanales
El proceso de hacer un sitio accesible es una tarea mayormente artesanal al
momento. En la seccin anterior se propuso un enfoque alternativo que ataca este
problema, pero an no tiene su correlacin en la prctica. La forma de hacer sitios
accesibles cumpliendo pauta por pauta hasta la conformidad es un proceso repetitivo con
una fuerte intervencin humana.
ii. Falta de patrones
Al momento, el uso de patrones y frameworks estandarizados para desarrollo son
conceptos tericos del cual hablan algunos trabajos de investigacin [Baguma et al &
Lopes, 2009], pero no tiene su correlacin en la prctica.
Los trabajos estn basados en la incorporacin de ontologas de Web semntica
[Lopes et al 2009]. A travs 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 terico que aplica en
requerimientos no funcionales (NFR) las necesidades de una Web accesible, y limita la
construccin 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 presentacin diferente. Se pone como ejemplo un sitio de aprendizaje, en donde
usuarios con baja visin deban navegar por un examen sin que la herramienta les dijera
la respuesta. La solucin a este tipo de dilemas es compleja. Lo mismo ocurre con sitios
de
imagen
corporativa,
videos
elementos
multimediales.
Por otro lado, el contenido que tiene derechos de autor puede no ser accesible si posee
proteccin de la propiedad intelectual
Maia Naftali
82.624
44 - 117
FI-UBA
d. Foco en el contenido
La mayor parte de la atencin en el tema se centra en regular el contenido, y no tanto el
resto de los aspectos. Muchos planes de accin 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 creacin 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 lnea de
pensamiento
centran
la
responsabilidad
en
las
personas.
La causa atribuida es la falta de compromiso y responsabilidad de quienes hacen pginas

Web. Dentro de ese encuadre, proponen como solucin la necesidad en educar a quienes
generan el contenido en buenas prcticas sobre accesibilidad.
Esta visin no contempla el problema de forma global. Teniendo en cuenta de que
el contenido se genera desde mltiples fuentes, slo se involucrara a las personas que
desarrollan en lenguajes de marcado o programacin. Por otra parte, imponer un estndar
de facto a los millones de creadores de pginas es un proceso de escala astronmica.
Requiere cambiar la cultura de una forma radical, y los procesos no estn preparados para
que la transicin sea fcil. Por el contrario, la incorporacin 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 slo el
20% de los encuestados tena conocimientos sobre la
accesibilidad. La encuesta estaba dirigida a un pblico del cual el 54% tena maestras
doctorados en su haber. El estudio adems dio a conocer que cerca del 20% de los
individuos aprendieron sobre accesibilidad dentro de un aula (y slo el 20% lo hizo por su
cuenta).
Maia Naftali
82.624
45 - 117
FI-UBA
Un dato a destacar es el siguiente: cerca del 73% de los encuestados respondi

que conoca o haba escuchado acerca de cmo las personas con ceguera utilizaban la
Web, pero no saba cmo generar sitios accesibles para ellos.
La encuesta deja ver que no es una falta de voluntad, sino un desconocimiento
generalizado.
b. Poca difusin de la accesibilidad Web
El estudio realizado en Brasil [Freire, 2009] arroja que la accesibilidad es un tema poco
difundido an en el ambiente universitario. No existen estudios similares a nivel nacional,
y as como tampoco existen al momento polticas que promuevan la creacin de sitios
accesibles.
c. Dificultad en la comprensin del proceso
El proceso de crear sitios accesibles partiendo de las pautas no es adecuado para todos los
potenciales generadores de contenidos.
En el ao 2004, Bob Regan (Accessibility Manager de Macromedia) analiz la relacin
entre la accesibilidad Web y los diseadores grficos. Ellos sentan que la imposicin de
estndares de accesibilidad limitaba la creatividad, y resultaba en pginas aburridas y
poco vistosas. Regan encontr que los diseadores eran personas visuales entrenadas
para concebir la interfaz grfica desde ese lugar, y les costaba pensar en experiencias de
navegacin Web diferentes a la interaccin grfica con mouse. En su compaa le llev
varias sesiones hacer que comprendan el proceso de crear pginas accesibles [Regan,
2004].
d. Informacin de difcil acceso
Como se mencion junto con los mitos, hay una gran parte de la informacin
sobre accesibilidad Web que no es correcta o est desactualizada. Otra gran fraccin de
las fuentes posee un lenguaje que requiere conocimientos tcnicos, o no es apropiada para
personas poco afines con la lectura de estndares.
En el sitio de la WAI estn publicados los documentos de las pautas y estndares. Si bien
all se proporciona informacin precisa y ordenada, se exige un alto compromiso del
lector. Sera poco aplicable imponer su lectura a todos aquellos que quisieran desarrollar
una pgina accesible simple.
Maia Naftali
82.624
46 - 117
IV.
FI-UBA
Empresas
a. Fuera de sus objetivos
Al margen de las normativas regionales que adopta cada pas, la accesibilidad no
es un parmetro de calidad segn las normas ISO. Al carecer de una motivacin
obligacin especfica, tiende a ser un objetivo relegado por quienes construyen sitios
Web.
b. Visin basada en utilidades
Como toda industria, la ingeniera 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 tcnicas.
Existen beneficios adicionales, pero difcilmente generen el retorno suficiente como para
que muchos empresarios lo incluyan en su anlisis. 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 pgina.
c. Tiempo o presupuesto acotados
Las pginas 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 poltica de calidad de la
empresa a cargo del desarrollo, difcilmente sta sea tomada como un requisito a cumplir.
V.
Normativas
a. Slo existen en algunos pases
Al momento existen pases que no tienen leyes de accesibilidad sancionadas, como la
Argentina, siendo su eficacia un tema a debatir.
b. Atraso con respecto de la tecnologa
La mayora de las leyes de accesibilidad al momento (jul.-2009) [Thatcher et al,
2006] estn basadas en WCAG 1.0. Al salir un nuevo estndar las leyes deberan ser
Maia Naftali
82.624
47 - 117
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
FI-UBA
1.7 Estado del arte:

En diez aos de existencia, las pautas de accesibilidad Web no lograron imponerse como el
estndar de facto. El foco actual, centrado en el contenido, demostr que no contribuye a lograr
progresos en el campo.
La generacin de contenido accesible sigue siendo un proceso complejo, ya que requiere que los
creadores reciban una preparacin especfica en estndares y cambien su mtodo de trabajo.
Los estndares de accesibilidad han progresado, y en la actualidad las pautas WCAG 2.0 son
independientes de la tecnologa. Este mayor nivel de abstraccin le permite lograr conformidad
con tecnologas diferentes al HTML.
Sera ms natural lograr que por defecto las pginas Web posean una baja cantidad de barreras,
sin efectuar cambios radicales en la forma en que esas pginas son construidas.
1.7.1 Lneas de investigacin en la actualidad

Web Semntica y metadata
Se investiga la incorporacin de un sistema de metadatos por detrs de la pgina, que incluya una
base de conocimientos. Al solicitar una pgina, el usuario contara con informacin extra que le
permitira mejorar la experiencia. Este tipo de sistemas es llamado Accessibility Commons. Su
actual desafo es estandarizar el formato de los datos por detrs y proveer de herramientas para
desarrollar bajo esta infraestructura [Kawanaka et al, 2008].
Frameworks y herramientas
Se investiga la creacin de componentes accesibles que se integren a las herramientas de
creacin de pginas. Dichos componentes se adaptarn al contexto de uso, permitiendo cierta
flexibilidad
Maia Naftali
82.624
en
el
cumplimiento
de
las
pautas
[Baguma
et
al,
2009].
49 - 117
FI-UBA
Captulo II:
Los Mtodos de Evaluacin de la
Accesibilidad Web
Maia Naftali
82.624
50 - 117
FI-UBA
Captulo II: Los Mtodos de Evaluacin de la Accesibilidad

Web
2.1 Evaluacin de sitios Web
2.1.1 Introduccin al proceso de evaluacin de accesibilidad
El proceso de evaluacin, tambin conocido como proceso de prueba o testing, es una prctica
de la ingeniera 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 informacin recolectada en la evaluacin, 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 mtodos de evaluacin generan resultados
diferentes, dependiendo del evaluador [Brajnik, 2008a].
Brajnik define a los mtodos de evaluacin de la accesibilidad Web (AEM) como
procedimientos orientados a la bsqueda de problemas de accesibilidad, tales como violacin a
las pautas, fallas, defectos y otros ndices de los usuarios [Brajnik, 2008b]. Un AEM:
Define qu pasos, decisiones, criterios y condiciones sern usadas para detectar

problemas a la accesibilidad
Podra definir cmo clasificar y priorizar problemas (en trminos de severidad o

impacto).
Podra definir cmo agregar informacin sobre problemas y cmo generar reportes o
informes.
Podra definir cmo seleccionar una muestra de sitios para evaluar.
Existen tres enfoques diferentes de evaluacin de la accesibilidad:

1) Pruebas de conformidad con las pautas
2) Pruebas para deteccin de barreras
3) Pruebas de monitoreo automatizado sobre una muestra
Maia Naftali
82.624
51 - 117
FI-UBA
Las pruebas de conformidad consisten en la verificacin y la validacin de cada tem propuesto

por la pauta elegida. Estas pruebas asumen que si todas las pautas son cumplidas, la pgina en
cuestin ser accesible. Incluyen a modo de validacin pruebas con usuarios y tecnologas
asistivas para validar. El objetivo final es detectar puntos no cumplidos para que las pginas
involucradas sean reparadas.
Las pruebas de deteccin de barreras [Brajnik, 2008c] apuntan a la deteccin de posibles puntos
en los cuales una pgina podra 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 pginas de una muestra,
midiendo el grado de accesibilidad en trminos 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 regin a lo largo del tiempo. Utilizan la conformidad con las pautas
como medida para realizar las comparaciones.
2.1.2 Tcnicas de evaluacin propuestas por la WAI y su alcance

Corresponden al grupo de Pruebas de conformidad. El proceso de evaluacin propuesto por la
WAI provee un procedimiento genrico que aplica a los diferentes estados del ciclo de vida de
una pgina Web [Evaluating Accessibility].
Dependiendo de la profundidad de la evaluacin, se proponen diferentes tcnicas a emplear, que
se enunciarn a continuacin:
2.1.2.1 Revisin preliminar (Preliminary Review)
El objetivo del proceso es la rpida identificacin de problemas de accesibilidad en sitios Web.
Este mtodo no es suficiente para determinar si conforma o no con las pautas. Combina tcnicas
manuales sobre pginas representativas, junto con el uso de herramientas semi automticas para
la evaluacin de la accesibilidad. Las cinco tareas que propone:
o Seleccin de una muestra representativa de pginas.
Maia Naftali
82.624
52 - 117
FI-UBA
o Evaluacin con navegadores grficos (IE, Firefox, Opera, Safari, etc.).

o Evaluacin con navegadores especiales (de voz, textuales, etc.).
o Uso de herramientas de validacin automticas.
o Resumen de los resultados, y pasos a seguir.
2.1.2.2 Evaluacin de conformidad (Conformance Evaluation)

Una evaluacin de conformidad determina si una pgina Web cumple o no con los estndares de
accesibilidad, como las pautas WCAG. Combina tcnicas automticas, semi automticas y
manuales de pruebas para sitios accesibles. Se enfoca en la evaluacin tcnica, y no involucra a
usuarios con discapacidad. Los pasos propuestos:
o Determinar el alcance.
o Elegir herramientas de evaluacin automticas.
o Realizar una evaluacin manual de los sitios ms representativos.
o Utilizar navegadores grficos 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 evaluacin para contextos especficos (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 tecnologas
antiguas y sitios dinmicos). A continuacin se resumirn los puntos centrales del proceso.
Para desarrollo:
o Establecimiento de requerimientos claros para el nivel de conformidad a alcanzar.
o Inclusin del tema en la planificacin inicial.
o Asignacin de tiempo de proyecto a la revisin.
Maia Naftali
82.624
53 - 117
FI-UBA
o Provisin de informacin sobre el tipo de evaluacin, 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 Identificacin de los individuos responsables del monitoreo. Seguimiento de las
actividades.
o Incorporacin de feedback (intercambio de opiniones) en el sitio.
o Uso de herramientas automticas.
o Creacin de procedimientos para validar y evaluar pginas y cambios antes de
subirlos al ambiente productivo.
Para sitios dinmicos:
o Evaluacin de los templates o plantillas generadoras del contenido HTML.
o Evaluacin de la capacidad del Content Management System (CMS, generador de
contenido) al generar pginas, validando pautas ATAG.
2.1.2.4 Seleccin de herramientas de evaluacin automticas (Selecting a tool)
Las herramientas de evaluacin 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 segn la WAI:
Ventajas:
Reducen el tiempo y el esfuerzo requerido en la ejecucin de evaluaciones de

accesibilidad.
Pueden ayudar en la eliminacin de barreras, proporcionando consejos y soluciones

comunes.
Ayudan a determinar la conformidad con cada punto de las pautas de forma automtica.
Desventajas:
Maia Naftali
Requieren el juicio humano.
Pueden generar falsos positivos/negativos por problemas en la interpretacin del cdigo.
No pueden determinar la accesibilidad de un sitio.
82.624
54 - 117
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.
Integracin con otras tecnologas.
Calidad de los resultados.
Soporte de tecnologas.
2.1.2.5 Involucramiento de usuarios (Involving Users)

Se proporcionan recomendaciones y tcnicas para involucrar a usuarios en el proceso de
evaluacin de forma eficiente. Como primera recomendacin, se aconseja ejecutar una prueba
preliminar para quitar del sitio barreras triviales.
2.1.2.6 Algunas conclusiones sobre la metodologa de evaluacin de la WAI

Existe una marcada diferencia entre la exhaustividad del documento de pautas y las
estrategias de evaluacin. La metodologa de evaluacin que se propone es general. Describe
ciertos puntos que se deberan validar, y cada interesado debe darle forma para convertirlo en un
proceso til.
El uso de herramientas automatizadas de evaluacin no debera ser el nico tipo de
prueba a utilizar. Es necesaria la inclusin de pruebas manuales, que en lo posible involucren
usuarios y diferentes tecnologas.
Maia Naftali
82.624
55 - 117
2.1.3
FI-UBA
UWEM
2.1.3.1 UWEM: Introduccin

La Metodologa Unificada de Evaluacin Web (UWEM) proporciona un procedimiento y ofrece
un sistema de principios y prcticas para evaluaciones de accesibilidad ejecutadas tanto por
expertos como por herramientas automticas. La metodologa est diseada 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 agrupacin de 23
instituciones de Europa para promover un enfoque comn a la accesibilidad. Respecto de la
clasificacin realizada en este trabajo, la UWEM corresponde al tercer grupo Pruebas de
monitoreo automatizado sobre una muestra, y adems toma en cuenta la conformidad con las
pautas.
Los criterios de diseo que se tuvieron en cuenta fueron:
Conformidad tcnica con las pautas existentes de la WAI
Independencia de la herramienta y del navegador: las preguntas y los casos de prueba

deben ser neutros
Interpretacin nica: las preguntas deben tener una nica interpretacin
Replicable: Diferentes evaluadores deben ejecutar las mismas pruebas en el mismo sitio,
y obtener resultados similares con cierta tolerancia.
Cumplimiento con la regulacin (EC) No 808/2004 del European Parliament.
La UWEM define tres pasos principales:
Muestreo
Ejecucin de pruebas
Generacin de Reportes
Diagrama 2.1.3.1 Pasos definidos por la metodologa UWEM
Maia Naftali
82.624
56 - 117
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 mtrica que
muestra la probabilidad de hallar una barrera en una pgina. Con UWEM Score se comparan los
resultados en toda la muestra.
2.1.4 Barrier Walkthrough
2.1.4.1 Introduccin
El mtodo de Barrier Walkthrough (Recorrida por barreras) es una tcnica basada en una
heurstica para recorridas que propuso Giorgio Brajnik en el trabajo homnimo [BarrierW].
La evaluacin es manual, y clasifica dentro del grupo de Pruebas para la deteccin de barreras.
Esta tcnica es prioriza el impactos de las barreras segn el tipo de contexto. Esto permite
conocer la severidad que tendr cada una en sitio ms all de la conformidad con las pautas.
2.1.4.2 Procedimiento
En primera instancia, las barreras son catalogadas con la siguiente informacin:
Categora de usuario y tipo de discapacidad
Tipo de tecnologa asistiva a utilizar
Actividad o tarea que la barrera obstaculiza y de qu forma
Atributos de la pgina que presentan la barrera
Luego se define informacin del contexto de uso:
Categoras de usuarios significativas (Personas con baja visin, personas con edad
avanzada, etc.).
Objetivos o casos de uso (Llenar un formulario, leer un artculo, y otros.)
Pginas a ser testeadas (listado de pginas).
Escenarios de uso (ambientes ruidosos, a travs de magnificadores, con

navegadores especiales, y otros).
Maia Naftali
82.624
57 - 117
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 pgina: Barrera, Impacto, Persistencia, Severidad, Detalle.
Con las planillas completas, se toman las barreras por cada tipo de usuario. A continuacin se las
cruza contra el contexto de uso del escenario considerado, realizando una priorizacin. (Para
mltiples usuarios el autor propone una heurstica para priorizar y juntar las planillas). Se asigna
por cada barrera un valor entre 1 y 3 (3 el ms 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 fcil de eludir y no afecta la seguridad o efectividad
Significativa (2): afecta a la ejecucin de la tarea. Es difcil de eludir
Crtica (3): La barrera impide al usuario cumplir el objetivo
Con el impacto y la persistencia se genera una matriz para asignar severidades, que luego
servirn para tomar las barreras que presenten valores ms altos.
Impacto Persistencia Severidad
1
Menor
Menor
Significativa
Significativa
Significativa
Crtica
Crtica
Crtica
Crtica
Tabla 2.1.4.1: Matriz de severidades, Barrier Walkthrough
Esta metodologa de evaluacin presentada tiene la ventaja de que se enfoca en la deteccin de

los problemas ms severos, y permite medir el impacto de cada barrera para cada contexto de
uso. Los mtodos 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 anlisis
Maia Naftali
82.624
58 - 117
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 aplicaran.
La desventaja principal es que este mtodo requiere de evaluadores coordinados, y una gran
intervencin 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
comparacin contra la tcnica de Conformance Review propuesta por la WAI [Brajnik, 2008a],
en una muestra de sitios evaluados bajo ciertas mtricas. Los resultados obtenidos con Barrier
Walkthrough fueron ms tiles e identificaron una mayor cantidad de barreras correctamente
juzgadas.
Maia Naftali
82.624
59 - 117
FI-UBA
2.2. Mtricas para evaluacin de accesibilidad Web

2.2.1 Definicin de mtrica
Se conoce como mtrica a cualquier medida destinada a conocer o estimar atributos de calidad de
un artefacto [WikipediaSWMetric].
Las mtricas son importantes para controlar, entender y mejorar productos y procesos en el
desarrollo de software.
El enfoque GQM, propuesto por Basili, sugiere que las mtricas deberan surgir naturalmente al
mirar los objetivos puntuales de un proceso. Esto evitara la definicin de mtricas sin sentido,
que no brindan informacin y generan un costo [Basili, 1994].
2.2.2 Las mtricas en la accesibilidad Web
Las mtricas 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 mtricas
es tener una nocin acerca de cun accesible es el artefacto evaluado. Es posible comparar
diferentes estados entre las versiones de una pgina ante cambios, y permiten tener una visin
global sobre una muestra.
Cada proceso de evaluacin (Por pautas, barreras, de gran escala) maneja una o varias mtricas.
En la seccin siguiente se detallarn las ms usuales.
.
Maia Naftali
82.624
60 - 117
FI-UBA
2.2.3 Las mtricas de evaluacin de accesibilidad Web existentes:

2.2.3.1 FR (Failure Rate)
Fue el resultado del primer estudio publicado sobre la medicin de la accesibilidad, propuesto
por Sullivan y Matson [Sullivan & Matson, 2000]. Esta mtrica considera la relacin entre el
nmero total de barreras encontradas en una pgina p, llamado B (p), y el nmero de
barreras potenciales P (p). Estas ltimas representan al total de los elementos que podran
comportarse como una barrera.
Nomenclatura:
B
Cantidad de barreras o problemas encontrados en una pgina Web
Cantidad de barreras potenciales en una pgina Web
Coeficiente del peso de la barrera
NP
Cantidad de pginas evaluadas
NT
Cantidad de pruebas ejecutadas

Tabla 2.2.3.1.1: Smbolos FR
Frmula:
Ip =
Bp
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 atencin 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 pgina accesible.
Los valores de B y P dependen de la cantidad de casos de prueba que se estn tomando.
Ejemplo:
La pgina p1 contiene slo 20 imgenes, de las cuales 19 tienen el atributo ALT:
P(p1) = 20
Maia Naftali
82.624
B(p1) = 1 (hay slo una sin ALT)
I(p1) = 1/20.
61 - 117
FI-UBA
2.2.3.2 WAB Score

Web Accessibility Barrier es una mtrica propuesta por Parmanto & Zeng [Parmanto &
Zeng, 2005]. Agrega a la medicin un peso que representa el problema potencial de cada barrera.
Utiliza como conjunto de pruebas a la verificacin 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 frmula toma en cuenta la totalidad de las pginas de un sitio.
[Hacket et al, 2004]
Nomenclatura:
p
Total de pginas de un sitio
Total de violaciones a una pgina
nv
Violaciones a una pgina
Nv
Cantidad de violaciones potenciales
Wv
Peso de cada violacin a las pautas, calculado como la inversa de la

prioridad (1:A; 2:AA, 3:AAA)
Np
Total de pginas a verificar

Tabla 2.2.3.2.1: Smbolos WAB Score
Frmula:
nv
(Wv )
p
v Nv
WABScore =
Np
Qu mide:
Calcula un ranking para todas las pginas de cada sitio. En lugar de considerar
barreras, como hace la mtrica FR, toma en cuenta las violaciones a las pautas.
Un puntaje de WAB ms alto indica la presencia de ms barreras a la
accesibilidad.
Si est cercano a cero denota que el sitio no viola ningn checkpoint.
Hay un umbral terico fijado en 5.5. Por encima de ese valor el sitio se considera no
accesible.
Maia Naftali
82.624
62 - 117
FI-UBA
Ejemplo:
La pgina p1 tiene 20 imgenes. 19 poseen el atributo ALT, y 1 no lo tiene.
El checkpoint de Imgenes 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 mtrica fue definida por la UWEM para su proceso de evaluacin de pginas Web en gran
escala. Fue pensada para el monitoreo y la evaluacin 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 pases de la regin [Freire et al, 2008].
Nomenclatura:
Bpj
Barreras halladas dada una pgina p y un test j
Ppj
Barreras potenciales dada una pgina 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.
Barrera
Test
Cantidad de test
Tabla 2.2.3.3.1: Smbolos UWEM
Frmula:
B pj
1 n
UWEM = 1 1
Wb
n j =1
P
b
pj
Qu mide:
Mide la probabilidad de encontrar barreras en la pgina.
Dada una cantidad de test n corridos sobre una pgina, y conociendo la cantidad de
barreras potenciales que cada test podra detectar, se registra la cantidad de barreras
halladas. Con esos datos se genera el puntaje.
Maia Naftali
82.624
63 - 117
FI-UBA
Los tests son pequeas pruebas unitarias definidas en la metodologa UWEM, aunque se
podra extender la mtrica y utilizar otro juego de pruebas.
El resultado es una probabilidad y se encuentra siempre entre 0 y 1. Un valor
cercano a 0 indicara que la pgina es accesible, dado que la probabilidad de hallar
barraras en ella es bajo. Por el contrario, un resultado cercano a 1 marcara 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 anlisis de los valores mejoraran el resultado una mejora a futuro.
Ejemplo:
Para una pgina p se realiza un test t, donde se encuentra una nica barrera
entre las 20 que podra tener. Falta el atributo que identifica el lenguaje de la pgina.
Esta barrera afecta a usuarios con ceguera (c) y baja visin (Bb.). El clculo de la
mtrica sera el siguiente:
Datos:
BP = 1;
Resultado:
1-
P.D. = 20;
(1-(BP/P.D...)
Wi = 0.05 (es fijo)

*
Wi)
n=1; b=1
1-0.9975
0.0025
La probabilidad de encontrar una barrera en la pgina es 0.25%
Maia Naftali
82.624
64 - 117
FI-UBA
2.2.3.4 A3
Bhler propone una mtrica que es una mejora sobre UWEM Aggregation Formula
[Bhler 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 interpretacin nica y repetible para la comparacin de resultados.
3. Arrojar un rango continuo de valores. 4. Tener en cuenta el tamao y la complejidad del sitio
o de la pgina Web.
Nomenclatura:
b
Tipo de Barrera
Tipo de discapacidad
Identificador nico de la ubicacin (URL+cod+xpath) que fue evaluada
Muestra evaluada. p= {i0; i1.. in} contiene todos los id. nicos.
Rib
Reporte. Booleano que toma el valor de 1 si la barrera b es detectada en

la ubicacin i
Npb
Cantidad de reportes de aparicin 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: Smbolos A3
Frmula:
A3 ( p, u ) = 1 (1 S ub )C pb
b
C pb =
B pb
N pb
Frmula
B pb
Bp
Funcin 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
FI-UBA

A3 obtiene una probabilidad (entre 0 y 1). Cuanto menor es el puntaje ms accesible se
considera al sitio o la pgina, porque es menos probable encontrar barreras en l.
Respecto a la funcin de complejidad:
-
Si no hay barreras encontradas del tipo b, no hay contribucin a la funcin de

agregacin( Bpb = 0 Cpb = 0)
Si se encuentra una barrera de tipo b, el resultado de la funcin de agregacin

decrecera. (Bpb>0 Cpb > 0)
La funcin de complejidad tiene en cuenta la relacin entre las barreras potenciales y las
encontradas en el test. Adems considera la relacin entre el total de fallos y el nmero de
fallos por un solo tipo de barrera. Esto ltimo asegura que la barrera sea tomada de
acuerdo a la proporcin general de ocurrencias de todo el sitio Web.
Ejemplo:
Utilizando el mismo ejemplo que en la seccin anterior (2.2.3.3), tenemos una
nica pgina con un nico test, que de 20 barreras potenciales posee slo una: le falta el
atributo LANG que identifica el lenguaje de la pgina. Esta falla afecta a dos tipos de
usuarios con discapacidad: usuarios con ceguera y con baja visin .Esta mtrica s toma
en cuenta el impacto para cada tipo de usuarios.
Datos:
(Nota: Los reportes equivalen a los resultados de la ejecucin 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 (aparicin de la barrera en la muestra p): 2
U = {u1,u2} = {usuarios con baja visin, usuarios con ceguera}
Matriz de impactos S(u: usuario, b:barrera) ;

o S(baja visin, LANG ) = 0,2;
o S(ceguera, LANG ) = 0,5
Clculo:
Cpb = 1/2 + 1/1 = 1,5
A3 (p, baja visin) = 1-(1-0,2^1,05) = 0,0890
Maia Naftali
82.624
66 - 117
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 visin, 8,9%. Para el resto de los usuarios la probabilidad es 0 (significa que es
accesible para ellos).
Maia Naftali
82.624
67 - 117
FI-UBA
2.2.3.5 WAQM
WAQM (Web Accessibility Quantitative Metric ) es una mtrica utilizada por un motor de
evaluacin de laboratorio llamado EvalAccess [Vigo et al., 2007b]. Este motor tiene la ventaja
de que permite elegir el juego de pautas. El clculo de la mtrica es automtico, y toma en cuenta
tanto los errores arrojados por la herramienta, como las advertencias y potenciales advertencias.
Nomenclatura:
{P,O,U,R}
Conjunto de checkpoints a evaluar, con cuatro subconjuntos

(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
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}
Valor de accesibilidad promedio
Ax
Accesibilidad del elemento x en {P,O,U,R}
Variable para la aproximacin por hiprbola en el eje y [0;100]
Variable para la aproximacin por hiprbola en el eje x [0;1]

Tabla 2.2.3.5.1: Smbolos WAQM
Frmula:
NTx
1 NP
WAQM =
NP j =1 x{ P ,O ,U , R} NT
Axyz
Maia Naftali
82.624
B xyz
Pxyz
y{e , w}
NTxy
NTx
W A
x{1, 2 , 3}
xyz
100
Bxyz
a 100
+ 100, si
<
b
Pxyz a 100/b
Bxyz
a
P
xyz
+ a, en caso contrario
68 - 117
FI-UBA
Algoritmo de clculo:
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} /* Evala la rama a usar por la aproximacin por hiprbola*/
Si
Bxyz
Pxyz
<
a 100
entonces
a 100/b
Hallar A xyz en la primera rama, usando la correccin por hiprbola b
fijada en [0;1]:
B xyz
Axyz =
Pxyz
100
b + 100
Sino
Hallar A xyz en la segunda rama, con la correccin a fijada en [0;100]
Bxyz
Axyz = a
P
xyz
+a
Fin
Fin loop z
3
Axy = k z Axyz
Paso a: Ponderacin de la tasa A por el peso de cada elemento
z =1
Fin loop y
Ax =
y
N xy Axy
Nx
Paso b: Ponderacin por la cant. de checkpoints entre x e y
Fin loop x
A=
x
Maia Naftali
82.624
N x Ax
Paso c: Ponderacin por la cant. de checkpoints entre x, y el total
N
69 - 117
FI-UBA
Qu mide:
El valor arrojado por esta mtrica est comprendido entre 0 y 100, donde un valor
mayor cercano a 100 significa un sitio accesible.
Un valor cercano a 100 significa un sitio accesible, mientras que un valor cercano a 0
indica que han fallado la mayora de las pruebas automticas sobre los checkpoints.
2.2.3.6 Mambo AI (Accessibility Index)
Mambo AI
es una mtrica ligada a la tcnica de evaluacin Barrier Walkthrough (BW),
descripta en la seccin 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
Tipo de discapacidad
Matriz de severidad. Se tabula la cantidad de barreras por cada tipo de

usuario, contra la severidad asociada a cada grupo
M[d,s]
Elemento de la matriz
Densidad de barreras.
wi
Peso que tiene el elemento i-esimo
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: Smbolos Mambo AI
Frmula:
f = F * M[](al 95% IC)
Maia Naftali
82.624
70 - 117
FI-UBA
Qu mide:
El valor resultante est relacionado con la probabilidad de que no existan barreras en la
pgina/sitio.
Cada trmino de la productoria expresa la probabilidad de que no existan barreras para el
grupo de usuarios con discapacidad d.
Un valor cercano a 0 expresa que el sitio tiene una baja probabilidad de contener barreras.
Es comparable a las mtricas UWEM Score y A3, que estn 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
FI-UBA
2.3 Automatizacin en la evaluacin de sitios accesibles

2.3.1 Introduccin
Las herramientas de verificacin automtica de accesibilidad, o simplemente validadores,
son programas que prueban la conformidad de una pgina con un juego de pautas determinado.
El uso de estas herramientas permite conocer rpidamente que puntos de las pautas (checkpoints)
estn siendo violados. Tambin proporcionan informacin descriptiva sobre los errores, a modo
de ayuda para el usuario que debe reparar esa seccin. Todas se basan en la verificacin de reglas
que hacen al cumplimiento de un punto.
Existen checkpoints que no son verificables con herramientas simples. Para los controles
ms especficos, como el contraste y todos aquellos vinculados al color, existen herramientas
auxiliares que realizan pruebas ms profundas. Para evaluar la complejidad y la comprensin del
contenido de una pgina no existen herramientas totalmente automticas. 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 informacin (Hera).
Un inconveniente que presentan todas las herramientas automticas 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 debera ser visto como un proceso que combina las herramientas automticas
con el juicio humano. La parte algortmica pregunta por la presencia o ausencia de atributos que
hacen accesibles a los objetos (por ejemplo, la presencia de alt), pero slo el juicio humano
puede determinar adems si ese atributo es coherente y cumple con la funcin.
Maia Naftali
82.624
72 - 117
FI-UBA
2.3.1.1 Verificacin algortmica

En la siguiente tabla se resumen algunas de las verificaciones tpicas que pueden realizar las
herramientas automticas. La implementacin vara con la tecnologa utilizada.
Pauta a prueba
Un equivalente textual
Verificacin
Se comprueba la existencia
Observaciones
No todas las imgenes importan lo mismo. La omisin de alt en
debe ser provisto ante
de elementos alt en las
los grficos decorativos tiene un impacto menor que en las
cada elemento grfico de
imgenes HTMLy la
imgenes principales; La descripcin provista puede sen un
la pgina
presencia de subttulos en los
espacio, o el nombre del archivo, y eso no lo volvera 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 decoracin
cada video
funciona con algunos
por ejemplo). Los subttulos pueden no ser acordes al contenido.
formatos)
La informacin de la
Se prueba que la diferencia
Es difcil de verificar si hay cambios de color en la mitad del
pgina debe poder ser
de colores entre el fondo y el
texto y fondos grfico.
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 realizara la deteccin de identificadores de
filas y columnas de la tablas.
cabeceras.
deben estar identificados
Esto vale para tablas de

datos.
Las pginas deben estar
Se prueba que las
Es importante que el algoritmo tome en cuenta las transiciones
diseadas para evitar las
transiciones entre fotogramas
de contraste.
frecuencias de parpadeo
no estn 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 diseados para
del formulario tenga una
no automtica.
permitir el uso de
descripcin o texto. Se debe
tecnologas asistivas
probar el uso del teclado.
Los tiempos de espera
Se busca que no existan
El uso de tecnologas 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 ms

tiempo.
Tabla 2.3.1.1: Resumen de la verificacin algortmica principal de una pgina
Maia Naftali
82.624
73 - 117
FI-UBA
2.3.2 Herramientas automticas

Dentro de las herramientas automticas, las ms populares son:
2.3.2.1 Bobby
Watchfire Bobby fue una de los primeras herramientas comerciales de evaluacin de
pginas 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 validacin libre desarrollada por la Fundacin C.T.I.C.
(Centro Tecnolgico especializado en Tecnologas de Internet), sede espaola del W3C.
El validador se presenta en diferentes versiones: Validacin Web Online, desde un URL,
bajando una aplicacin en Java para escritorio. [TAW] (2010).
2.3.2.3 WAVE
W.A.V.E. (Web Accessibility Evaluation Tool) es una herramienta de validacin libre,
provista por la organizacin sin fines de lucro WEB.Aim. Tiene una versin para usar
desde la Web, una extensin para el programa de diseo Dreamweaver, y un servicio
Web para interactuar con otras aplicaciones que requieran validar pginas.
[WAVE](2010)
2.3.2.4 HERA
Hera es la herramienta de validacin de la fundacin 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 Iberoamrica [HERA] (2010).
Desarrollada en PHP, La herramienta posee un componente (plug-in) para el navegador
Mozilla Firefox. El cdigo fuente est disponible tambin.
Maia Naftali
82.624
74 - 117
FI-UBA
2.3.2.5 EvalAcces
EvalAccess es una herramienta desarrollada en la Universidad del Pas Vasco, que realiza
una validacin gratuita a travs de la Web [EvalAccess](2010). Permite evaluar pginas
HTML aisladas o sitios completos.
2.3.2.7 Achecker
Achecker es un validador gratuito de cdigo abierto desarrollado
por el grupo de
Tecnologas Adaptativas de la Universidad de Toronto (ATRC). Est implementado en

php, y es posible correr tanto pruebas on-line como locales. Tiene adems 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
FI-UBA
2.4 Conclusiones: Procesos de evaluacin y mtricas

Sobre los procesos de evaluacin:
Las evaluaciones de accesibilidad manuales son efectivas en cuanto a la deteccin de barreras,
pero tiene un alto costo. Por otra parte, las evaluaciones automticas ejecutadas desde diversas
herramientas son veloces y econmicas, 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 evaluacin
automtica existen diferencias en los resultados, debido a la implementacin que cada una hace
de la verificacin.
Existen metodologas como UWEM, que proponen casos de prueba y escenarios estandarizados.
La extensin de su uso contribuira a la deteccin eficiente de barreras, pero por su envergadura
es prcticamente inaplicable en proyectos pequeos con tiempo escaso o nulo para la
verificacin. En esos casos sera til contar con una evaluacin automtica rpida que al menos
permita detectar las barreras ms comunes.
Sobre las mtricas:
Las mtricas fueron creadas con la idea de medir el proceso de evaluacin. De las mtricas
analizadas,
se
distinguen
dos
grandes
grupos:
manuales
automticas.
Las mtricas de procesos automticos (WABScore, UWEM, A3, WAQM) enfatizan en

incorporar atributos y elementos matemticos con el fin de lograr ms precisin. Sin embargo,
los procesos que miden tienen un marcado desvo causado por los falsos positivos y los falsos
negativos. Las barreras provenientes del uso del lenguaje no podran ser verificadas de forma
automtica y eso podra causar un desvo an mayor al resultado de la formula. Dependeran de
la herramienta empleada y de sus resultados. La ventaja est en su facilidad de clculo.
Maia Naftali
82.624
76 - 117
Las mtricas de procesos manuales (BW, FR, WABScore)
FI-UBA
llevan un mayor tiempo de
elaboracin y cantidad de personas involucradas, pero contemplan pruebas que seran

irrealizables automticamente.
Existe una discusin acerca del real significado de una mtrica. Tom Demarco crey por dcadas
en su famosa frase You cant control what you cant measure (No puedes controlar lo que no
puedes medir). Hoy en da DeMarco propone una nueva frase: The more you focus on control,
the more likely youre working on a project thats striving to deliver something of relatively
minor value [DeMarco, 2009]. El foco de las mtricas cambi junto con la ingeniera del
software, que en la actualidad est en la bsqueda del valor y de la utilidad
Este anlisis, llevado al plano de las mtricas para accesibilidad Web, indica que se debe buscar
primero el valor en los procesos que hacen necesaria la presencia de las mtricas de elevada
complejidad. Reducir la cantidad de variables en juego (usuarios, severidad, prioridad, casos de
test) a la hora de evaluar la accesibilidad redundara en mtricas ms simples y procesos menos
costosos.
Maia Naftali
82.624
77 - 117
FI-UBA
Captulo III:
OceanAcc, Una aplicacin que integra

mtricas en un proceso de evaluacin
semiautomtico
Maia Naftali
82.624
78 - 117
FI-UBA
Captulo III: OceanAcc, Una aplicacin que integra mtricas

en un proceso de evaluacin semiautomtico
3.1 Motivacin
El proceso de evaluacin de la accesibilidad
no puede ser realizado de forma automtica
completamente por los falsos positivos que arrojan las herramientas de evaluacin. El ruido
generado debe ser filtrado por el juicio humano. Los procesos de evaluacin manual o artesanal
obtienen resultados ms cercanos, ligados a las barreras reales. Sin embargo, requieren del diseo
de casos de prueba y su adaptacin al contexto.
Sera til disponer de un proceso semiautomtico que permita un anlisis desde la deteccin de
barreras, y que adems cuente con mtricas que aporten una idea sobre el grado de accesibilidad
obtenido.
3.2 Objetivos
a. Primarios
Hacer ms eficiente al testing o evaluacin de accesibilidad Web, tanto manual como
automtico
Integrar mtricas al proceso de evaluacin, obtenidas de forma semi automtica
Generar informacin de valor de forma rpida
b. Secundarios
Simplificar la incorporacin del juicio humano a travs de una interfaz grfica simple y
eficiente
Maia Naftali
82.624
79 - 117
FI-UBA
3.3 Descripcin de la aplicacin

OceanAcc es una aplicacin de escritorio que modela un proceso de evaluacin
semiautomtico con integracin de mtricas de accesibilidad. Emplea una evaluacin automtica
con las pautas WCAG2-A para hallar las violaciones ms importantes, y luego solicita la
intervencin del usuario para filtrar aquellos puntos detectados que son falsos positivos o no
aplican en el contexto. Una vez realizado ese refinamiento, calcula las mtricas de accesibilidad
ms usuales (Failure Rate, WabScore, UWEM) y dos mtricas propias del proceso (errores
aprobados/errores totales), WabScore*.
Posee adems reportes, y permite ver la historia de una pgina y analizar su evolucin a lo largo
de los tests ejecutados.
Para realizar las pruebas automticas se emplea el servicio Web provisto por la
herramienta Achecker, que devuelve un resultado en formato rest (XML).
Respecto de la relacin 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 violacin a un
checkpoint genera de 0 a N barreras.
Beneficios:
Permite enfocarse en la deteccin, correccin y prueba de las barreras ms frecuentes y costosas,
haciendo al proceso ms eficiente.
Considerando que en muchos proyectos el presupuesto para las pruebas de accesibilidad es
acotado, el aporte de esta informacin permitira liberar sitios Web con menos barreras.
Tecnologa:
.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
FI-UBA
3.4 Documentacin
3.4.1 Modelo de datos
Page
PK,I1
id
FK1
idsite
title
filename
type
failurePoints
TestBarrier
acheckermap
I1
I2
idtest
idbarrier
userveredict
q
PK,I1
id
name
year
Test
PK,I1
FK2,I2
FK1,I1
Guideline
FK1
FK2
idAchecker
idCheckpoint
errorTypeA
Element
id
date
guideline
page
tool
theresold
known
likely
potential
Checkpoint
PK,I2
id
FK1
I1
guideline
checkpoint
description
priority_score
inherits
TestResult
Barrier
BarrierDisability
PK,I1
FK2,I2
FK1,I1
iddisability
idbarrier
Disability
PK,I1
id
BarrierName
Description
PK,I1
idtestresult
FK2
FK1
idtest
checkpoint
result
comment
userveredict
errortype
sourceLine
sourceColumn
Severity
impact
persistence
severity
id
BarrierCheckpoint
disabilityname
FK1,I1
FK2,I2
idbarrier
idcheckpoint
impact
Diagrama 3.4.1 Modelo de datos
Maia Naftali
82.624
81 - 117
FI-UBA
3.4.2 Arquitectura
Se opt por desarrollar una aplicacin para escritorio. Dentro de las ventajas encontradas:
Es ms econmica la persistencia en una estructura de base de datos simple cuya

ubicacin la determina el usuario.
No requiere que el usuario suba las pginas locales. Las herramientas que corren bajo
plataforma Web son tiles si la pgina est alojada en un servidor.
La vista (UI) fue hecha en Windows Presentation Foundation, que brinda soporte a la
accesibilidad a travs de la interfaz UIAccess provista por el Framework .Net 3.5
Para el acceso a datos se implement el patrn Gateway.
WPF Classes
Report Templates
Object
Data Manager
Metric and Report

Manager
Parse and Import

module
Data Access
Gateway
DB
Input folder
Diagrama 3.4.2 Diagrama de Componentes
Maia Naftali
82.624
82 - 117
FI-UBA
3.4.3 Descripcin del proceso de prueba de una pgina

Metric Manager
Test manager
AChec
ker
Usuar
io
Crear Pgina
Crear Test
Ejecutar Test
Importar
resultados
Generar lista de
barreras
Editar resultados
Aprobar
resultados
Calcular mtricas
Almacenar
Diagrama 3.4.3 Diagrama de actividades
Funcionalidades de la aplicacin:
1. Crear o abrir una pgina
2. Agregar o abrir un test
3. Importar datos de la herramienta OceanAcc
4. Editar resultados
5. Generar mtricas
6. Abrir reportes
Maia Naftali
82.624
83 - 117
FI-UBA
3.4.4 Sobre el proceso de evaluacin con Achecker

El Web Service que ofrece Achecker recibe una peticin con la siguiente forma:
http://achecker.ca/checkacc.php?id=68320c641ac984e871fd61793e0364e57006f6
a0&output=rest&guide=WCAG2-A&offset=0&uri=http%3A%2F%2F
Se especifica el conjunto de pautas (WCAG2-A), la direccin 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><a href="
http://achecker.ca/checker/suggestion.php?id=49"
onclick="popup('http://achecker.ca/checker/suggestion.php?id=49'); return
false;" title="Suggest improvements on this error message"
target="_new">Document has invalid language code.</a>
</errorMsg>
<errorSourceCode><html xmlns="
http://www.w3.org/1999/xhtml"><head> <meta httpequiv="content-type" content="text/h ...</errorSourceCode>
<repair>Add a valid 2 letter or 3 letter language code as defined
in the ISO 639 specification to the HTML 'lang' 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
FI-UBA
La correlacin entre el cdigo 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 mtricas generadas
Para generar las mtricas es necesario contar con datos de entrada que en su mayora son
especficos de determinados procesos. Se mostrar para cada caso particular la forma en que se
obtienen los resultados:
Failure rate
Ip =
Bp
Pp
Esta mtrica 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 pgina, se le pregunta por la cantidad de elementos no
HTML (imgenes, 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
B pj
1 n
UWEM = 1 1
Wb
P
n j =1
b
pj
UWEM mide la probabilidad de encontrar barreras en un sitio, dado un subconjunto de

pruebas y barreras.
El algoritmo de clculo obtiene una la lista de las barreras potenciales, utilizando
la relacin entre la violacin 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
FI-UBA
barreras que el usuario acept que existan 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
WABScore =
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 aplicacin. 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)
WABScore =
nv

ve{ E ,W , P } N v
Esta mtrica es propia de la aplicacin OceanAcc. Consiste en una adaptacin de

WABScore que toma en cuenta los tres tipos de fallas: error advertencia problema
potencial.
Frmula: 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 mtrica tiene la ventaja de que separa las fallas ms importantes de aquellas poco
relevantes, omitiendo parte del ruido que generan todas las advertencias.
False Positive Rate: FPR (Tasa de falsos positivos)
FPR =
fallas _ validadas
total _ fallas _ det ectadas
Esta mtrica es propia de la aplicacin 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 obtencin de un valor
con alto desvo podra indicar un problema en el testing manual.
Maia Naftali
82.624
86 - 117
FI-UBA
3.5 Caso de estudio

3.5.1 Caso de estudio I: pgina de la Facultad de Ingeniera
Se realizar el proceso completo de evaluacin de una pgina, tomando como ejemplo la pgina
principal de la facultad.
Pantalla principal:
Imagen 3.5.1.1 Pantalla Principal de la aplicacin OceanAcc
1. Crear una pgina:

Se solicita al usuario los siguientes datos, todos opcionales excepto el URL: Ttulo, URL
o nombre del archivo, tipo de pgina, puntos de falla. Este ltimo atributo es utilizado para el
clculo de la mtrica 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 pgina (Imgenes, videos, tablas no accesibles, eventos temporales y
dems).
Tambin es posible abrir una pgina existente.
Maia Naftali
82.624
87 - 117
FI-UBA
Imagen 3.5.1.2: Pantalla para crear una nueva pgina
Imagen 3.5.1.3: Pantalla para abrir una pgina existente
2. Crear un nuevo test:
Imagen 3.5.1.4: Pantalla para crear un test
Maia Naftali
82.624
88 - 117
FI-UBA
Una vez que se carga la pgina, 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 opcin para importar resultados:
Imagen 3.5.1.6: Resultado de la importacin
Maia Naftali
82.624
89 - 117
FI-UBA
Antes de importar los resultados, se prueba la conexin contra el servicio Achecker. Si es

exitosa, habilita la opcin de carga de resultados (Load Results). En caso contrario, el sistema
permite cargar los resultados de un archivo .rest generado a travs de la Web de Achecker. Esto
permite la importacin an cuando el servicio no responde.
En las solapas se puede ver y exportar el cdigo rest devuelto, y una vista previa de la pgina.
4. Editar resultados
Imagen 3.5.1.7: Edicin de resultados
Aparecen en dos grillas los resultados de la evaluacin. En la superior figuran los errores, y en la
inferior las advertencias y potenciales problemas. Esta opcin por defecto es para facilitar la
seleccin, y asegurarse de que los errores ms 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 ms informacin del checkpoint, se
despliega una ventana al seleccionarlo con un texto descriptivo. Sumado a la lnea y columna del
error, el desarrollador podr ubicar en qu puntos hay fallas.
Maia Naftali
82.624
90 - 117
FI-UBA
Cuando el usuario termina de editar los checkpoints, pasa a editar y seleccionar las barreras:
Imagen 3.5.5.7: Edicin de resultados: barreras
Las barreras son buscadas de forma automtica. En la lista inferior aparecen ordenadas por
impacto y cantidad de apariciones (Q). Una barrera puede aparecer muchas veces por prueba, y
su
repeticin
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 relacin con el checkpoint.
El propsito de esta cuantificacin es lograr un orden que priorice las barreras con mayor
probabilidad.
Imagen 3.5.1.8: Ventana emergente con informacin de la barrera seleccionada
Maia Naftali
82.624
91 - 117
6.
FI-UBA
Generar mtricas
Las mtricas 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 mtricas basadas en las mismas no arrojen resultados precisos.
Imagen 3.5.1.9: Ventana de generacin de mtricas
Maia Naftali
82.624
92 - 117
FI-UBA
Anlisis de los resultados:

Failure Rate result en un valor elevado. De 158 puntos de falla, la evaluacin 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%. Slo se
seleccion la barrera ms recurrente e importante (falta de atributos descriptores de contenido

no textual (ALT)). Ningn elemento de la pgina posea ALT, por lo tanto el resultado es
coherente considerando todo el espacio de barreras.
La tasa de falsos positivos (FPR) no debera ser analizada, ya que se eligieron los
checkpoints violados ms recurrentes y se dejaron de lado las advertencias (warnings) y

problemas potenciales. Si todas las advertencias fueran errneas, la tasa de falsos positivos
sera cercana al 63% .
3.5.2
Tabla comparativa de mtricas entre pginas:

Se realiz una nueva corrida del programa con Fiuba, especificando una cantidad de puntos de
falla ms realista fijada en 166. Para obtenerlos se analiz el cdigo HTML en busca de
imgenes, tablas, formularios y dems recursos. La pgina de la ACM es el caso testigo, ya que
es accesible y cumple con WCAG y con Section 508.
Google
www google com
Failure
Points
2
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
Pgina
URL
FR
[0;1]
0,054
WABScore
UWEM
WABScore*
[0;5,5]U(5,5;N)
[0;1]
0,007752
0,02041
0,06781
Tabla 3.5.2: Comparativa de resultados entre pginas
Del resultado de las mtricas se pueden hacer las siguientes inferencias:
La pgina ms accesible segn las mtricas es Google, y el nico punto validado

por el usuario es que no especifica el idioma. En los sitios multiidioma eso podra
ser mitigado con cdigo que redireccione segn la cultura que tenga el sistema,
pero en este caso no se tuvo en cuenta.
Maia Naftali
82.624
93 - 117
FI-UBA
Del anlisis de UWEM para Fiuba, sale que la probabilidad de encontrar una
barrera es del orden del 30%. Ninguna de las 148 imgenes tena el atributo ALT
con la descripcin. En el caso de Google, la barrera se debe al idioma y tiene un
peso cercano al 7%. Por lo tanto, para esta mtrica el castigo de no informar un
idioma es mucho mayor que el de omitir el contenido de las imgenes.
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
anlisis.
Maia Naftali
82.624
94 - 117
FI-UBA
3.6 Conclusiones
El objetivo principal del trabajo fue hacer ms eficiente la evaluacin de la accesibilidad Web, y
a la vez integrar mtricas que puedan ser obtenidas fcilmente. Del anlisis de los procesos y de
las mtricas se puede concluir:
La generacin de resultados automticos da una idea del grado general de accesibilidad.

La precisin de las mtricas asociadas es excesiva respecto del ruido que pueden tener las
evaluaciones. Sin la intervencin del juicio humano resulta imposible filtrar los
resultados y quitar los falsos positivos.
Al tratarse de pruebas automticas, es posible lograr la conformidad con las pautas

trabajando sobre los puntos que arrojan errores, an sin otorgarle sentido a los cambios.
Un ejemplo est en la descripcin de las imgenes, que podran consistir en un texto que
diga texto y an as pasar las pruebas.
Los procesos manuales son precisos y efectivos. Estn menos difundidos que las
evaluaciones automticas, y podran ser adaptables para proyectos ms pequeos en
contextos reducidos.
La lectura de las mtricas provenientes de procesos automticos debera tener en cuenta

el carcter aproximado de las mismas. Resulta contradictorio la medicin exacta, cuando
los parmetros empleados son experimentales o estn definidos de forma arbitraria
Cada mtrica pondera una misma violacin individual a la accesibilidad de forma

diferente. Para poder extraer conclusiones y realizar comparaciones, es necesario conocer
en qu impacta cada violacin sobre el valor que se calcula. De otra forma no sera
correcto decir que la pgina X es N veces ms accesible que la pgina Y porque su
resultado se aproxima ms 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 mtrica sino la accesibilidad en general. Es
Maia Naftali
82.624
95 - 117
FI-UBA
decir, la utilidad de la mtrica sera conocer aproximadamente en qu posicin est una

pgina 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 ingeniera software. Explicaba la inexistencia de un elemento que
pudiera revertir instantneamente la situacin de aquel entonces.
Trazando la analoga 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 lneas de forma
coordinada. Los estndares y las normativas por s solos demostraron un alcance limitado. Se
requiere de herramientas de edicin Web que generen contenido accesible por defecto; de
intermediarios entre el contenido y el navegador que preparen mejor la informacin; de
estndares de calidad que incorporen la accesibilidad como atributo; de herramientas y procesos
de prueba ptimos; de un acercamiento de las prcticas a las empresas vinculadas a la Web; de
voluntad y de trabajo.
Aplicando el conjunto de las estrategias ser posible mejorar la accesibilidad. Esto aportara un
beneficio a toda la comunidad, permitiendo que ms individuos se sumen al medio de mayor
difusin de intercambio personal aparecido en la Historia de la Humanidad: la Web.
Maia Naftali
82.624
96 - 117
FI-UBA
APENDICES
Maia Naftali
82.624
97 - 117
FI-UBA
Apndices
Apndice A: Glosario de afecciones abarcadas por la
accesibilidad Web
A.1 Visuales
A.1.a. Ceguera
Prdida total del sentido de la vista.
A.1.b. Baja visin
Privacin parcial de la vista que no puede ser corregida adecuadamente con anteojos,
lentes de contacto, remedios o ciruga.
A.1.c. Daltonismo
Imposibilidad de distinguir los colores. Los tipos de daltonismo: Acromtico (slo negro
contra blanco), Monocromtico(slo poseen un cono), Dicromtico (slo poseen dos
conos), Tricromtico anmalo (poseen tres tipos de conos, pero perciben los tonos
alterados. Es el tipo ms comn).
A.2 Auditivas
A.2.a Sordera total
Imposibilidad de percibir el sonido.
A.2.b Hipoacusia
Prdida parcial de la capacidad auditiva.
A.3 Fsicas
Limitacin en el desempeo motor, que afecta a brazos o piernas.
A.4 Del Habla
Dificultad en la comunicacin oral. Disfluencia (trastorno del ritmo), Tartamudeo
(vacilaciones y repeticin involuntaria), Trastornos en la voz (anomala en calidad, tono y
volumen).
Maia Naftali
82.624
98 - 117
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 neurolgica y no tiene relacin con la inteligencia del individuo.
A.5.b Dficit de atencin (TDAH)
Trastorno de dficit de atencin e hiperactividad. Trastorno neurolgico del
comportamiento caracterizado por distraccin moderada a severa, perodos de atencin
breve, inquietud motora, inestabilidad emocional y conductas impulsivas.
A.5.c Sndrome de down
Trastorno gentico causado por la presencia de una copia extra del cromosoma 21 (o una
parte del mismo), en vez de los dos habituales (trisoma del par 21), caracterizado por la
presencia de un grado variable de retraso mental y unos rasgos fsicos peculiares que le
dan un aspecto reconocible. Es la causa ms frecuente de discapacidad psquica
congnita.
A.5.d Alzheimer
Enfermedad neurodegenerativa, que se manifiesta como deterioro cognitivo y trastornos
conductuales. Se caracteriza en su forma tpica por una prdida progresiva de la memoria
y de otras capacidades mentales, a medida que las clulas 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 clulas nerviosas (neuronas) del cerebro
envan seales errneas. Las personas pueden tener sensaciones y emociones extraas o
comportarse de una manera rara. Pueden tener espasmos musculares violentos o perder el
conocimiento
Maia Naftali
82.624
99 - 117
FI-UBA
Apndice B: Glosario de Tecnologas asistivas

Tecnologa Asistiva (AT) es la denominacin que recibe de todo dispositivo tecnolgico de
asistencia, adaptacin y rehabilitacin para personas con discapacidad. Mejorando y cambiando
los mtodos de interaccin con la tecnologa, estos dispositivos habilitan a realizar tareas que se
veran impedidas. [Wikipedia AT](2010).
B.1
Lectores de pantalla
Los lectores de pantalla Screen Readers son programas que interpretan la informacin
mostrada por pantalla para que las personas con problemas de visin aprendizaje puedan
acceder a la informacin.
En los sistemas con interfaz grfica (GUI) deben almacenar adems los elementos (menes,
ventanas, botones, cuadros de texto, etc.) para permitir al usuario moverse a travs de la pantalla.
Los sistemas operativos del momento ofrecen APIs o interfases que intervienen en la interaccin
y alimentan a estos sistemas, para permitir que diferentes tecnologas puedan ser ledas.
Dentro de los lectores ms 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
electrnico de comunicacin textual que permite a las personas con sordera comunicarse a travs
de las lneas telefnicas. Consiste en un teclado QWERTY junto con un visor, que operan bajo
un protocolo especfico. Si bien no es especfico en el uso de una computadora, este sistema fue
el precursor de tecnologas 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
B.3
FI-UBA
Aumentadores de pantalla y correccin de color

Dentro de esta categora se engloban las aplicaciones y dispositivos destinados a alterar la forma
en la cual se muestra la informacin en pantalla. Permiten a las personas con problemas de visin
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 correccin de
colores, el suavizado (smoothing) de los elementos grficos y algunas funciones bsicas de
lectura de pantalla.
B.4
Reconocimiento de voz
Un sistema de reconocimiento de voz es una herramienta que procesa la seal de voz emitida
por el ser humano y reconoce la informacin contenida en sta, convirtindola en texto. Permite
a las personas con problemas de visin operar una computadora a travs de comandos por voz.
B.5
Sistemas de subtitulado oculto (Close Captioning)
Es un sistema de subttulos para programas de televisin y video destinado a permitir que las
personas sordas o con dificultades para captar la seal de audio, puedan comprender lo que se
dice en televisin o en los videos. A diferencia de los subttulos comunes, que slo describen los
dilogos, este sistema describe todo el audio presente (incluyendo msica de fondo y efectos de
sonido) mediante palabras o smbolos. Esta tecnologa aplica tanto a la televisin 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
FI-UBA
Lneas Braille: Consisten en dispositivos que muestran en una lnea el texto en

Braille. Cada lnea est compuesta por celdas dinmicas de 6 8 puntos que
suben o bajan de forma dinmica.
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 cognicin o movilidad utilizar una computadora.
Abarcan a los teclados especiales, mobiliario ergonmico de soporte, y diferentes tipos de
interruptores y dispositivos de entrada con su interfaz de conexin.
Maia Naftali
82.624
102 - 117
FI-UBA
GLOSARIO
Maia Naftali
82.624
103 - 117
FI-UBA
GLOSARIO
Tabla de traducciones de trminos:

Ingls
Espaol
Assistive Technologies
Tecnologas asistivas
Authoring Tool
Herramientas de diseo
Boolean
Booleano
Browser
Navegador
Checkpoint
Punto de verificacin
Guideline
Pauta
Pop-Up
Pgina Emergente
Script
Cdigo de programacin
Stakeholder
Interesado
User Agent
Agente de Usuario
W3 Consortium
Consorcio World Wide Web
Walkthrough
Recorrida guiada
Glosario:
Assistive Tecnologies (Tecnologas asistivas)
Dispositivos tecnolgicos de asistencia, adaptacin y rehabilitacin para personas con
discapacidad
ATAG (Authoring Tool Accessibility Guidelines)
Pautas de accesibilidad del consorcio W3 para herramientas de diseo.
Authoring Tool
Aplicacin 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 dems
aplicaciones que permiten generar pginas Web.
Maia Naftali
82.624
104 - 117
FI-UBA
Barrera (a la accesibilidad)
Elemento en una pgina que impide a las personas con discapacidad acceder al recurso.
Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart)
Prueba desafo-respuesta utilizada en computacin para determinar cundo 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
mquina no es capaz de comprender e introducir la secuencia de forma correcta por lo
que solamente el humano podra 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.
Heurstica
Tcnica experimental que ayudan a la resolucin de problemas. Los mtodos heursticos
aplican una estrategia para llegar a una solucin aproximada de forma ms rpida.
OCR (Optical Character Recognition)
Proceso que reconoce el texto de una imagen y lo convierte en caracteres o letras del
alfabeto.
Section 508 (Seccin 508 de Rehabilitation act)
Seccin de la ley Rehabilitation Act, que a partir del ao 2001 establece estndares
obligatorios de accesibilidad que aplican a todas las agencias gubernamentales. Tiene
alcance sobre todos los programas informticos y perifricos que se utilizan.
Stakeholder (Interesado)
Persona, grupo organizacin 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
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 especficas de uso.
User Agent (Navegador)
Aplicacin informtica que funciona como cliente en un protocolo de red. El nombre
aplica generalmente para referirse a aquellas aplicaciones que acceden a la Web
(navegadores, araas de buscadores, telfonos mviles, lectores de pantalla y otros).
UAAG (User Agent Accessibility Guidelines)
Pautas del consorcio W3 que explican cmo hacer agentes de usuario accesibles para
personas con discapacidad, y cmo incrementar la accesibilidad al contenido Web.
UWEM (Unified Web Evaluation Methodology)
Metodologa para la evaluacin del cumplimiento de las pautas WCAG, desarrollada por
la agrupacin europea WAB Cluster. Consiste en un procedimiento de evaluacin que
abarca un sistema de principios y de prcticas para la evaluacin de la accesibilidad de la
Web tanto por un experto humano como de manera automtica.
W3Consortium
Consorcio que agrupa a organizaciones internacionales multidisciplinarias y miembros
que trabajan en conjunto para desarrollar estndares Web y pautas.
WAI (Web Accessibility Initiative)
Grupo de inters del Consorcio W3 sobre asuntos de accesibilidad en la Web.
WCAG (Web Content Accessibility Guidelines)
Pautas del consorcio W3 que explican cmo desarrollar contenido accesible para la Web.
Maia Naftali
82.624
106 - 117
FI-UBA
REFERENCIAS
Maia Naftali
82.624
107 - 117
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,
Proposal
for
Robert
a
Caillau,
HyperText
WorldWideWeb:
Project,
1990.
http://www.w3.org/Proposal.html
[Berners-Lee, 1989]
Tim
Berners-Lee.
WorldWideWeb:
Proposal
for
HyperText Project. 1989

.http://www.w3.org/History/1989/proposal.html
[Brajnik, 2008a]
G. Brajnik. A Comparative Test of Web Accessibility

Evaluation Methods. ASSETS08, October 1315, 2008,
Maia Naftali
82.624
108 - 117
FI-UBA
Halifax, Nova Scotia, Canada. Copyright 2008 ACM 978-159593-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. 6380, 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. 112121, 2008. Springer-Verlag Berlin
Heidelberg 2008.
[Brajnik & Lomuscio, 2007]
G. Brajnik, R. Lomuscio. SAMBA: A Semi-Automatic

Method
for
Measuring
Barriers
of
Accessibility.
ASSETS07, October 1517, 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/
[Brewer, 2004b]
J. Brewer. Web Accessibility Highlights and Trends, 2004.

ACM SIGCAPH Newsletter 15 No. 76, June 2003, pg. 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.
[Bhler et al, 2006]
C. Bhler, 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
FI-UBA
2006, LNCS 4061, pp. 184191, 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 07407459) .
[eEurope] (2009)
eEurope. European Commission ,Information Society: Web

Accessibility.
http://ec.europa.eu/information_society/activities/einclusion/po
licy/accessibility/Web_access
[eEuropeSidar] (2007)
Fundacin Sidar. eEurope,Una Sociedad de Informacin

para Todos
http://www.sidar.org/recur/direc/eeuro/index.php
ltimo acceso: 08/07/2009
[EvalAccess] (2010)
Evalaccess: Tool for evaluating Web Accessibility.

Maia Naftali
82.624
110 - 117
[Evaluating Accesibility] (2009)
W3C-WAI
FI-UBA
Evaluating Web Sites for Accessibility:
Overview. http://www.w3.org/WAI/eval/Overview.html
[Freire et al, 2008]
A. Freire, R. Fortes, M. Turine, D. Paiva. An Evaluation of

Web Accessibility Metrics based on their Attributes.
SIGDOC08, 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 1820, 2004.
Pg. 32-39. Atlanta, Georgia, USA. Copyright 2004 ACM 158113-911-X/04/0010
[Hera] (2010)
Hera. Qu es Hera. http://www.sidar.org/hera.

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

http://tenyears-www.Web.cern.ch/tenyearswww/Welcome.html
[Kawanaka et al, 2008]
S. Kawanaka, Y. Borodin, J. Bigham, D. Lunn, H. Takagi,

G. Asawaka. Accessibility Commons: A Metadata
infraestructure for Web Accessibility. ASSETS08, October
1315, 2008, Halifax, Nova Scotia, Canada. Copyright 2008
ACM 978-1-59593-976-0/08/10.
Maia Naftali
82.624
111 - 117
[Kelly et al, 2007a]
FI-UBA
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. Carrio, D. Tzovaras, S.

Likothanassis. Towards The Universal Semantic Assestment
of Accesibility, SAC09 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. Pg 29-38. Copyright 2004 ACM
1581139039/04/0005.
Maia Naftali
82.624
112 - 117
[Sloan & Kelly, 2006]
FI-UBA
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. Pg. 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, Pg. 138-147. 2007,
Banff, Canada. Co-Located with the 16th International World
Wide Web Conference. Copyright 2007 ACM 1-59593-5908/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

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

Guidelines (UAAG) 1.0 Recommendation.
http://www.w3.org/2002/12/uaag10-testimonials .
[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
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/.
[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
[UWEM, 2008a]
A. Nietzio, N. Ulltveit-Moe, T. Gjster, M. Goodwin

Olsen, M. Snaprud. UWEM Indicator Refinement, 2008.
http://www.wabcluster.org/uwem1_2.
[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.
[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 0708, 2007,
Banff, Canada. Co-Located with the 16th International World
Wide Web Conference. Copyright 2007 ACM 1-59593-5908/06/0010
Maia Naftali
82.624
114 - 117
[w3CStd] (2008)
FI-UBA
Imagen de estndares W3C

http://www.w3c.es/Presentaciones/2008/1201accesibilidadCATIC-MA/img/tech-stack.png
[WABCluster] (2009)
WAB Cluster. The EU Web Accessibility Benchmarking

Cluster. http://www.wabcluster.org/
[WAI interdependences, 2005]
S. L. Henry. Essential Components of Web Accessibility.

http://www.w3.org/WAI/intro/components.php.
[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
[WAIabout] (2009)
W3C-WAI. About WAI. http://www.w3.org/WAI/

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

http://www.w3.org/WAI/gettingstarted/Overview.html
[WAVE](2010)
WAVE .About Wave. http://wave.Webaim.org/about

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

http://www.w3.org/WAI/WCAG20/from10/diff.php
Maia Naftali
82.624
115 - 117
[WCAG 1.0] (2009)
FI-UBA
W3C-WAI. Authoring Tool Accessibility Guidelines (ATAG)

2.0 W3C Working Draft 21 May 2009.
http://www.w3.org/TR/ATAG20/.
[WCAG 2.0, 2009]
W3C-WAI. Web Content Accessibility Guidelines (WCAG)

2.0
W3C
Recommendation
11
December
2008.
http://www.w3.org/TR/WCAG20/.
[Webbrowser] (1990)
Tim
Berners-Lee.
The
WorldWideWeb
browser.
http://www.w3.org/People/Berners-Lee/WorldWideWeb

[Wikipedia AT](2010)
Wikipedia. Assistive technology.

http://en.wikipedia.org/wiki/Assistive_technology.
[Wikipedia Braille](2010)
Wikipedia. Dispositivo Braille.

http://es.wikipedia.org/wiki/Dispositivo_Braille.
[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
[WikipediaSWMetric] (2009)
Wikipedia. Software Metric.

http://en.wikipedia.org/wiki/Software_metric
[WikipediaSWTest] (2009)
Wikipedia. Software Testing.

http://en.wikipedia.org/wiki/Software_testing
Maia Naftali
82.624
116 - 117
FI-UBA

[Wikipedia TTY](2010)
Wikipedia: Telecommunications device for the deaf.

http://en.wikipedia.org/wiki/Telecommunications_device_for_t
he_deaf.
[Wiscosin] (2001)
University of Wiscosin. Disability as a function of Age.

http://trace.wisc.edu/docs/function-aging/
Maia Naftali
82.624
117 - 117

Ingenieria Informatica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria Informatica

Cargado por

Copyright:

Formatos disponibles

Marzo 2010

TESIS DE GRADO EN INGENIERA EN INFORMTICA

Tesista: Maia R. Naftali

Anlisis e Integracin de mtricas para la Accesibilidad Web

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

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

En este trabajo se plantea un proceso de evaluacin semiautomtico que integra mtricas

Anlisis e Integracin de mtricas para la Accesibilidad Web

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

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

Anlisis e Integracin de mtricas para la Accesibilidad Web

Anlisis e Integracin de mtricas para la Accesibilidad Web

1.1 La World Wide Web......................................................................................................................................... 9

Captulo II: Los Mtodos de Evaluacin de la Accesibilidad Web ................................................................. 51

Anlisis e Integracin de mtricas para la Accesibilidad Web

2.1.4.1 Introduccin .................................................................................................................................... 57

3.1 Motivacin ..................................................................................................................................................... 79

Apndice A: Glosario de afecciones abarcadas por la accesibilidad Web ......................................................... 98

Anlisis e Integracin de mtricas para la Accesibilidad Web

Estudiar el modelo de accesibilidad vigente

Analizar y determinar las causas por las cuales no se generaliz la incorporacin de la

Analizar y clasificar los diferentes procesos de evaluacin de accesibilidad en la Web y

Proponer un proceso de evaluacin que integre mtricas y optimice la intervencin

Anlisis e Integracin de mtricas para la Accesibilidad Web

Anlisis e Integracin de mtricas para la Accesibilidad Web

Captulo I: La Accesibilidad en la Web

1.1 La World Wide Web

Anlisis e Integracin de mtricas para la Accesibilidad Web

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

Diagrama 1.1.2 Estndares que maneja el consorcio W3 [w3CStd]

Anlisis e Integracin de mtricas para la Accesibilidad Web

1.2 Introduccin: La Accesibilidad Web

ambientes con software conocido, esos

Anlisis e Integracin de mtricas para la Accesibilidad Web

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

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

Anlisis e Integracin de mtricas para la Accesibilidad Web

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

Anlisis e Integracin de mtricas para la Accesibilidad Web

1.2.2 Sobre la importancia de tener una Web accesible

1.3 La Web no accesible

Anlisis e Integracin de mtricas para la Accesibilidad Web

- Configuracin de colores que no puede ser alterada

- Pginas que no permiten cambiar el tamao de la letra

- Configuraciones de contraste - Pginas con mala disposicin que se deforman al agrandarse

- Sistema de subtitulado sobre

- Falta de subttulos en el audio de una pgina Web

- Hardware de entrada (en

- Limitaciones en los tiempos de respuesta de las pginas

todas sus variantes ) especial

- Falta de soporte a la navegacin con teclado

- Formularios que no siguen un orden lgico en el ingreso

- Avisos y pop-ups que bloquean la interaccin con la pgina

- Pginas que requieren el ingreso de voz

- Elementos que distraen la atencin (carteles llamativos )

Tabla 1.3.1: Barreras de accesibilidad Web

Anlisis e Integracin de mtricas para la Accesibilidad Web

Colores inapropiados: Uso de colores que no permiten distinguir contrastes.

Mal uso de la tecnologa para armar la distribucin: El estndar HTML, Flash,

Usabilidad general deficiente: De los aspectos de usabilidad ms generales, la barrera

Jerarquas mal definidas: La informacin no est bien categorizada (frecuente en

Lenguaje confuso: El texto tiene una interpretacin ambigua o dificultosa

poblacin. La solucin implica la reorganizacin de la pgina, y la correccin del texto.