UNIVERSIDAD NACIONAL DEL COMAHUE

FACULTAD DE ECONOMÍA Y ADMINISTRACIÓN

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

TESIS PARA LA CARRERA

LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN

Diseño de Interfaces Adaptado a Restricciones

de Accesibilidad Web

Brenda Valeria Bustos Torres

Mg. Adriana Martín

Dra. Alejandra Cechich

NEUQUÉN ARGENTINA
Agosto 2009
 PÁGINA PARA LOS EVALUADORES

Calificación:

Comentarios:

…………………………………… ……………………………………..

……………………………………

………………..…………………………………..
Lugar para la Fecha de la Evaluación
 III

DEDICATORIAS
Quisiera dedicar este trabajo a mamá y a mis hermanas, por ser parte de lo que soy
como persona, por sus valores y principios, por demostrarme que nuestros pasados y
circunstancias pueden haber influenciado en quienes somos, pero que somos
responsables por quien llegamos a ser.

Para mis amigos y familia por su paciencia y comprensión, por haber estado. Para
Matías especialmente, que es la persona que más directamente ha sufrido las
consecuencias de este trabajo. Por enseñarme que las cosas se miran con más calma,
pero con el interés de seguir creciendo, por su amor, por ser tal y como es.

Para mis amores del alma, mis sobrinos: Cata, Manu y Juan Cruz, sin duda son mis
referencias para el presente y futuro.

No por orgullo ni soberbia, también me lo quiero dedicar, por mi empeño y

perseverancia, por la fuerza de convicción en lo que deseaba, por el alma que le puse
a todos estos años de estudio.
IV

PREFACIO

Esta tesis es presentada como parte de los requisitos finales para optar al grado
académico Licenciada en Ciencias de la Computación, de la Universidad Nacional
del Comahue y no ha sido presentada previamente para la obtención de otro título en
esta Universidad u otras. La misma es el resultado de una investigación llevada a cabo
en el Departamento de Ciencias de la Computación en el período comprendido entre
Diciembre de 2007 y Agosto de 2009, bajo la dirección de Mg. Adriana Martín y la
codirección de Dra. Alejandra Cechich.

Brenda Valeria Bustos Torres

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
UNIVERSIDAD NACIONAL DEL COMAHUE
Neuquén, 06 de Agosto de 2009.
 V

AGRADECIMIENTOS

Primero, quisiera expresar mi más profundo y sincero agradecimiento a mi directora

de Tesis Mg. Adriana Martín por su guía, esfuerzo y dedicación plena, por
transmitirme en cada paso su pasión por la investigación y su amor por la
Universidad.
Sus conocimientos, sus orientaciones, su persistencia, su paciencia, su motivación,
han sido fundamentales para mi comienzo en la investigación y formación de este
trabajo. Ella ha inculcado en mí un sentido de seriedad, responsabilidad y rigor
académico. Me ha demostrado un ejemplo de profesionalidad que nunca voy a
olvidar. A su manera, ha sido capaz de ganarse mi lealtad y total admiración.
También me gustaría agradecer a mi codirectora la Dra. Alejandra Cechich y a los
profesores que he tenido en la carrera, por los consejos recibidos a lo largo de estos
años, de alguna manera u otra todos han aportado su granito de arena a mi formación.
A todos ellos muchas gracias.
VI

RESUMEN
Como una consecuencia del crecimiento vertiginoso de Internet, las aplicaciones con
plataforma de despliegue en la Web han evolucionado hacia aplicaciones de negocios y
servicios online de alta complejidad, convirtiéndose en recursos valiosos en la vida cotidiana
de las personas: educación, empleo, gobierno, comercio, entre otros. Al igual que cualquier
otro sistema interactivo de información, estas aplicaciones Web, no solo deben cumplir con
los objetivos funcionales para las que fueron creadas, sino que además deberían cumplir con
todos los principios y características deseables, que permitan calificarlas de “accesibles”. La
carencia de Accesibilidad en las interfaces de usuarios de los sitios Web es un dilema que
afecta actualmente a un gran número de personas. Que una aplicación Web sea “accesible”
significa que debe presentar la información a las personas de manera tal que,
independientemente de la tecnología que estas utilicen (dispositivos de escritorio y móviles) y
de las capacidades diferentes que posean (físicas y cognitivas), todas estas personas estén en
igualdad de condiciones en lo que al acceso a la información se refiere. Por lo tanto, derribar
barreras de Accesibilidad significa asegurar “a todos” el acceso a Internet independientemente
de la tecnología que utilicen y de las capacidades diferentes que posean.
Muchos países ya han legislado para custodiar la presencia de los principios de Accesibilidad
en los sitios relacionados con los organismos de gobierno, es decir aquellos destinados a la
administración y provisión de servicios públicos a sus ciudadanos. Así mismo han surgido
asociaciones y organizaciones en todo el mundo, que persiguen el objetivo de encaminar a la
Web a su máximo potencial: la posibilidad del Acceso Universal. Por ejemplo, el “World
Wide Web Consortium” (W3C) ha trabajado y trabaja incansablemente no sólo en la
confección de guías, estándares y herramientas de Accesibilidad sino que también en la
concientización con el firme propósito de inculcar porqué es tan importante hacer “accesible a
todos” el contenido de la Web. Basados en estas recomendaciones un gran número de
herramientas libres y comerciales para evaluar la Accesibilidad han surgido en los últimos
años y están disponibles para asistir a los desarrolladores Web en la generación de contenido
“accesible”.
Dado que es a nivel de interfaz de usuario donde finalmente se manifiestan las barreras de
Accesibilidad, nuestro trabajo apuesta al diseño de interfaces de usuario “accesibles”. En esta
tesis proponemos un enfoque para asistir a los desarrolladores en las tareas de diseño y
evaluación de la Accesibilidad en aplicaciones Web, desde los principios arquitectónicos del
diseño de sus interfaces de usuario. Particularmente nos centramos en presentar un Mapeo de
las pautas de la “Web Content Accessibility Guidelines 1.0” (WCAG 1.0) sobre un
framework arquitectónico que asocia las fortalezas del diseño de interfaces de usuario y del
patrón “Model View Controller” (MVC). El diseño arquitectural obtenido apunta
esencialmente a prevenir las barreras de Accesibilidad, pero aporta además a: (i) minimizar
los riesgos de cambios futuros, (ii) permitir el reuso a nivel arquitectural y (iii) disminuir en
gran medida los tiempos y costos en los que se incurre cuando un mal diseño conlleva a tareas
de re-desarrollo.
De esta manera nuestro enfoque fija su objetivo en asistir a los desarrolladores Web en la
toma de decisiones de diseño a los efectos de construir interfaces de usuario más “accesibles”
para personas con capacidades diferentes, contribuyendo a la concreción del ideal con el que
Tim Berners-Lee dio origen a la World Wide Web en 1989: “una Web para todos”.
 VII

SUMMARY
As a consequence of the vertiginous Internet growth, the applications with a spread out
platform in the Web have evolved into high complexity business and online services
applications, becoming valuable resources in the every day life of people: education, job,
government, commerce among others. Just as any other interactive information systems, these
Web applications not only have to fulfill the functional goals they were created for but they
also should comply with all the desirable principles and characteristics that allow them to be
qualified as “accessible”. Accessibility lack in Websites user interfaces is a dilemma currently
affecting a large number of people. A Web application being “accessible”, means that is has
to present the information to the people in such a way that independently of the technology
they use (desktop or portable devices) and the different capacities they may have (physical
and cognitive), all these people were in the same conditions to information access is referred.
So, the fact of throwing down Accessibility barriers means to ensure everybody gets access to
Internet, independently of the technology they use and the different capacities they have.
Many countries have already legislated to take care of keeping the presence of Accessibility
principles in the sites related to government departments, that is, those appointed to the
administration and provision of public services to their citizens. Likewise associations and
organizations all over the world have come forth pursuing the objective of putting the Web in
the right track towards its highest potential: the possibility of Universal Access. For instance
the “World Wide Web Consortium (W3C)” has working and tirelessly works on not only
drawing up guidelines, standards and Accessibility tools but also leading people is awareness
on the matter with the firm purpose of teaching why it is so important to make Web contents
“accessible to everyone”. Based on these recommendations during the last year a great
number of free and commercial tools have appeared and are available to assist the Web
developers in the production of “accessible” contents.
As it is at the user interfaces level where Accessibility barriers come up, our task aims at the
design of accessible users interfaces. In this thesis we propose an approach to assist
developers in the tasks of design and assessment of Web application’s Accessibility from the
architectural principles of user interfaces design. We essentially focus on presenting a pattern
mapping of the “Web Content Accessibility Guidelines 1.0” (WCAG 1.0) on an Architectural
framework which links the users interfaces design strengths and the “Model View Controller
(MVC)” pattern. The Architectural Design obtained mainly aims at preventing the Accessible
barriers, but also brings in: (i) to lessen the risks of future changes; (ii) to let it be used again
at architectural level and; (iii) to diminish times and cost greatly, factor where we fall we
never a wrong design takes redeveloping tasks.
Thus, our approach sets it objective in assisting Web designers in making their minds up so us
to built more “accessible” user interfaces for disabled people helping to fulfil Tim Berners-
Lee ideal when starting up the World Wide Web in 1989: “a Web for everyone”
Índice general
Capítulo 1......................................................................................................................................1
Introducción al Proyecto............................................................................................................1
1.1 Motivación ......................................................................................................................1
1.2 Objetivo...........................................................................................................................3
1.3 Organización ...................................................................................................................4
Capítulo 2......................................................................................................................................5
Accesibilidad Web.....................................................................................................................5
2.1 Un poco de Historia: La Importancia del Diseño Universal en la Web ..........................5
2. 2 ¿Qué es Una Interfaz de Usuario?..................................................................................7
2.2.1 Limitaciones de Acceso ...........................................................................................8
2.3 ¿Qué es la Accesibilidad Web? .....................................................................................10
2.3.1 ¿Por qué la Accesibilidad Web es Importante? .....................................................10
2.3.2 Referentes Técnicos: W3C - WAI .........................................................................14
2.3.3 Legislación existente..............................................................................................15
Capítulo 3....................................................................................................................................18
Un Framework para el Diseño de Interfaz de Usuario ............................................................18
3.1 Framework de diseño de LARSON ..............................................................................18
3.1.1 Criterios para determinar clases de decisión..........................................................19
3.1.2 Particiónamiento de decisiones de diseño de interfaz en clases ............................20
Capítulo 4....................................................................................................................................25
Model View Controller: Un Patrón que Prioriza la Interacción ..............................................25
4.1 Introducción a Patrones de Diseño................................................................................25
4.2 Patrón de Diseño Model View Controller.....................................................................26
4.2.1 Arquitectura Model View Controller.....................................................................26
4.2.2 Beneficios al aplicar MVC.....................................................................................28
4.3 Una Arquitectura para Diseñar con Clases de Decisión................................................29
Capítulo 5....................................................................................................................................30
Arquitectura de Software para Aplicaciones Web Accesibles ................................................30
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles..............................................................................................................30
5.1.1 Arquitectura con Clases de Decisión Accesibles...................................................31
Pauta 1 - Proporcione alternativas equivalentes para el contenido visual y
auditivo.....................................................................................................................32
Pauta 2: No se base sólo en el color .........................................................................36
Pauta 3. Utilice marcadores y hojas de estilo y hágalo apropiadamente ..................37
Pauta 4. Identifique el idioma usado ........................................................................41
Pauta 5. Cree tablas que se transformen correctamente ...........................................43
Pauta 6. Asegúrese de que las páginas que incorporan nuevas tecnologías se
transformen correctamente ......................................................................................48
 Pauta 7. Asegure al usuario el control sobre los cambios de los contenidos tempo-
dependientes .............................................................................................................52
Pauta 8. Asegure la Accesibilidad directa de las interfaces de usuario incrustadas .53
Pauta 9. Diseñe para la independencia del dispositivo.............................................54
Pauta 10. Utilice soluciones provisionales ...............................................................56
Pauta 11. Utilice las tecnologías y pautas W3C .......................................................59
Pauta 12. Proporcione información de contexto y orientación.................................61
Pauta 13. Proporcione mecanismos claros de navegación .......................................63
Pauta 14. Asegúrese de que los documentos sean claros y simples .........................69
Capítulo 6....................................................................................................................................72
Caso de Estudio .......................................................................................................................72
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. ................................72
6.1.1 Desarrollo - Objetos de la Interfaz de Usuario de la Aplicación Web GIE. ..........73
6.1.2 Construcción de la Interfaz de Usuario de la Aplicación Web GIE. .....................77
6.2 Resumen........................................................................................................................83
Capítulo 7....................................................................................................................................84
Trabajos relacionados ..............................................................................................................84
7.1 Propuesta de Hoffman et al. ..........................................................................................84
7.2 Propuesta de Brunet et al...............................................................................................87
Capítulo 8....................................................................................................................................92
Conclusiones y Trabajos Futuros.............................................................................................92
8.1 Resultados del Mapeo ...................................................................................................92
8.2 Publicaciones Derivadas de esta Tesis ..........................................................................94
8.3 Trabajos Futuros............................................................................................................94
Apéndice A..................................................................................................................................96
Glosario ...................................................................................................................................96
Pauta 1 - Proporcione alternativas equivalentes para el contenido visual y auditivo..........96
Pauta 3. Utilice marcadores y hojas de estilo y hágalo apropiadamente.............................97
Pauta 4. Identifique el idioma usado ...................................................................................97
Pauta 5. Cree tablas que se transformen correctamente ......................................................98
Pauta 6. Asegúrese de que las páginas que incorporan nuevas tecnologías se transformen
correctamente ......................................................................................................................98
Pauta 9. Diseñe para la independencia del dispositivo........................................................99
Pauta 10. Utilice soluciones provisionales..........................................................................99
Pauta 11. Utilice las tecnologías y pautas W3C..................................................................99
Pauta 13. Proporcione mecanismos claros de navegación ................................................100
Índice de figuras
3.1: Ejemplos de estilo de diálogo Menú Horizontal............................................................. 21
3.2: Ejemplos de estilo de diálogo Menú Vertical y Desplegable. ....................................... 21
3.3: Ejemplos de estilo de diálogo Formulario. ..................................................................... 22
3.4: Ejemplos de estilo de diálogo Lenguaje Natural. ........................................................... 22
3.5: Ejemplos de estilo de diálogo Manipulación Directa. .................................................... 22
3.6: Ejemplos de estilo de diálogo Interacción Asistida. ....................................................... 23
3.7: Ejemplos de Objetos de Interacción. .............................................................................. 23
4.1: Diagrama de clases de MVC [5]..................................................................................... 27
4.2: Ciclo de comunicación MVC. ........................................................................................ 28
6.1: Modelo de Clases Interfaz de Usuario Aplicación GIE.................................................. 75
6.2: Cuadro de Diálogo New Project (Visual Web Developer 2008) – Creación de Proyecto
Web GIE ................................................................................................................................ 77
6.3: Carpetas de aplicación - Proyecto Web GIE................................................................... 78
6.4: Clase FormgiController - Proyecto Web GIE................................................................. 79
6.5: Clase FormgiController - Proyecto Web GIE................................................................. 79
6.6: Archivo Site.css - Proyecto Web GIE............................................................................. 80
6.7: Archivo Site.Master - Proyecto Web GIE ...................................................................... 80
6.8: Archivo Formgi.aspx - Proyecto Web GIE..................................................................... 81
6.9: Código HTML generado correspondiente al procesamiento del archivo Formgi.aspx -
Proyecto Web GIE ................................................................................................................. 82
6.10: Archivo Formgi.resx - Proyecto Web GIE ................................................................... 83
6.11: Archivo Formgi.pt-br.resx - Proyecto Web GIE .......................................................... 83
7.1: Ejemplo de campos que comparten una misma etiqueta [12]......................................... 85
7.2: Señalización transmitida a través de elementos visuales [12]. ....................................... 85
7.3: Ejemplo de señalización efectiva en la barra de título: (A) la barra de título muestra un
error de información, (B) la barra de título muestra resultados de búsqueda [12]................. 86
7.4: Componentes de software de una solución accesible [4]................................................ 87
7.5: Solución accesible para una página Web [4]. ................................................................. 88
7.6: Patrón de diseño MVC [4]. ............................................................................................ 89
Índice de tablas
2.1: Breve descripción de los Principios Generales de Diseño Universal, enfocados en
aplicaciones Web [8].............................................................................................................. 6
2.2: Situaciones en que personas sin necesidades especiales pueden prescindir y verse
beneficiadas de interfaces accesibles [18]. ............................................................................ 12
6.1: Resumen del Mapeo utilizado como guía en el diseño de una de las interfaces de usuario
de la aplicación Web GIE. .................................................................................................... 73
Capítulo 1
Introducción al Proyecto
En este Capítulo se describe por competo el contexto de esta tesis, su objetivo y su estructura.
El detalle del contexto se instrumenta explicando la motivación que dio origen a este proyecto
y a estos efectos se incluyen conceptos y definiciones preliminares relacionados a la
Accesibilidad Web.

1.1 Motivación
La Web (World Wide Web) ha permitido un flujo de comunicación global a una velocidad de
cambio y evolución sin precedentes en la historia humana. Esta red universal de conocimiento
ha significado un enorme salto cualitativo y cuantitativo en lo que a adquisición y tratamiento
de información se refiere. Cultura, ciencia, idioma, arte, negocios… todo puede ser
compartido y diseminado digitalmente con el menor esfuerzo, haciéndolo llegar casi de forma
inmediata a cualquier otro punto del planeta, perdiendo de alguna manera las concepciones
tradicionales de distancia y tiempo. La Web, como nuevo medio de comunicación, tiene su
propio lenguaje y ha llegado a extenderse hasta áreas tales como el comercio electrónico (e-
commerce), el comercio móvil (m-commerce), los negocios electrónicos (e-bussiness) y las
organizaciones gubernamentales (e-government), permitiendo a las organizaciones: (i)
adaptarse rápidamente a patrones diferentes determinados por las necesidades y expectativas
de los usuarios en relación con la red, (ii) automatizar sus procesos de negocio y canales de
comunicación con sus clientes, y (iii) responder oportuna y adecuadamente a las necesidades
y requerimientos del mercado, manteniéndose competitivas en este.
Consecuentemente con el crecimiento de Internet, las aplicaciones Web también han
evolucionado rápidamente, hacia aplicaciones de negocios complejas y servicios online. Al
igual que cualquier otro sistema interactivo de información, estas aplicaciones, no solo deben
cumplir con los objetivos funcionales para las que han sido creadas, tarea que no es nada
fácil, sino que además deben cumplir con todos los principios y características deseables, que
permiten calificarlas como “accesibles”.
La norma ISO/TC 16027 [16], define Accesibilidad como la facilidad de uso en forma
eficiente, eficaz y satisfactoria de un producto, servicio, entorno o instrumento por personas
que poseen capacidades diferentes. Por lo tanto, Accesibilidad electrónica hace referencia a
que los productos y servicios electrónicos puedan ser utilizados por los usuarios con
efectividad, eficiencia y satisfacción en un contexto de uso determinado. En el caso de una
aplicación Web, que sea “accesible”, significa que debe presentar la información a las
personas, de manera tal que independientemente de la tecnología que utilicen (ordenador,
PDA1, teléfono, etc.) y de las capacidades diferentes que posean (físicas, psíquicas,
sensoriales u otras) estén en igualdad de condiciones en lo que al acceso a la información se
refiere.

1
PDA [37], del inglés Personal Digital Assistant, es un computador de mano originalmente diseñado
como agenda electrónica (calendario, lista de contactos, bloc de notas y recordatorios) con un sistema
de reconocimiento de escritura. Hoy día se puede usar como una computadora doméstica (ver películas,
crear documentos, juegos, correo electrónico, navegar por Internet, reproducir archivos de audio, etc.).
2 Capítulo 1 - Introducción al Proyecto

Las interfaces de las aplicaciones Web y su lenguaje asociado, juegan entonces un rol más
preponderante del que han tenido hasta el momento en aplicaciones tradicionales, como
consecuencia de la diversidad de usuarios, lenguajes y de la velocidad con que todos estos
factores están cambiando. Tal como se define en [18], debido a que la interfaz de usuario es:
(i) el principal punto de contacto entre el usuario y la computadora; (ii) la parte de la
aplicación Web con la que el usuario interactúa; y (iii) la puerta de acceso a la funcionalidad
del sistema subyacente, encargada de informar las posibles acciones a realizar, los cambios
producidos y estado actual de la aplicación Web, es justamente a nivel de interfaz de usuario
donde finalmente se manifiestan las barreras2 de Accesibilidad, debido a que lo que no es
posible expresar a través de la interfaz, permanece inaccesible a la persona o grupo de ellas
cuando interactúan con dicha aplicación Web.
Actualmente la mayoría de las interfaces de los sitios Web presentan barreras de
Accesibilidad, que afectan a un gran número de personas. Por ejemplo, los usuarios
discapacitados y las personas de edad avanzada tienen serias dificultades para interactuar con
Internet debido a impedimentos físicos y/o cognitivos para manipular los dispositivos y
entender los procedimientos y la navegación. Muchos países ya han legislado para velar por la
Accesibilidad de los sitios relacionados con los organismos del estado, es decir aquellos
referidos a la administración y provisión de servicios públicos a sus ciudadanos. Así mismo
han surgido asociaciones y organizaciones en todo el mundo, que persiguen el objetivo de
encaminar la Web a su máximo potencial, lo cual implica una Web para todos: un Acceso
Universal. Por ejemplo, el World Wide Web Consortium (W3C) [33], fue creado en Octubre
de 1994 con la visión “Universal Web Access: The Web Anywhere, for Everyone, at Anytime,
on Everything”. La W3C ha desarrollado guías de Accesibilidad denominadas Web Content
Accessibility Guidelines 1.0 (WCAG 1.0) [34] que son consideradas en la Unión Europea
como normas de facto, y citadas como referencia obligada en la mayoría de las legislaciones
sobre Tecnologías de la Información y Comunicación de todo el mundo. Estas
recomendaciones explican cómo hacer “accesible” el contenido de la Web a personas con
discapacidad y están pensadas tanto para los desarrolladores de contenido (autores de páginas
y diseñadores de sitios) como para los desarrolladores de herramientas de autor. Basados en
estas recomendaciones un gran número de enfoques han surgido en los últimos años y están
disponibles para asistir a los desarrolladores Web en la generación de contenido “accesible”.
En [19] se presentan y comparan quince de estos enfoques encontrados en la literatura
reciente en un framework de evaluación denominado WAAM “Web Accessibility Assessment
Model”.
Compañías que asisten en consultoría, no solo al sector privado sino también a la
administración pública, a países donde la Accesibilidad Web es un tema avanzado y legislado,
han investigado acerca de la carencia de Accesibilidad en las aplicaciones Web, arribando a
que uno de los factores determinantes es la significante brecha de conocimiento que existe
entre los desarrolladores de software y los especialistas de Accesibilidad. Por un lado, la
mayoría de los programadores no tienen conocimiento y experiencia, para lograr que su
código cumpla con los objetivos o características de Accesibilidad deseadas. Por otro lado, los
especialistas de Accesibilidad tienen limitaciones y poca experiencia en el desarrollo y más
aún en la programación, no siendo capaces de proveer ejemplos de trozos de código que
puedan ser usados por los desarrolladores para lograr aplicaciones “accesibles”. Además de lo
expresado, existe una carencia generalizada en la comprensión de las guías de Accesibilidad
para aplicaciones Web interactivas. Si bien existen un gran número de sitios que publican

2
Una Barrera de Accesibilidad es cualquier condición que dificulta a las personas alcanzar un objetivo
cuando está utilizando un sitio Web determinado a través de una tecnología de asistencia específica.
1.1 Motivación 3

información sobre Accesibilidad Web y las necesidades de los usuarios con capacidades
diferentes, se enfocan en el diseño de sitios Web estáticos o formularios Web básicos que no
reflejan los patrones de las aplicaciones actuales, dinámicas y con un alto grado de
complejidad, así como también introducen la Accesibilidad en el proceso de desarrollo, en
una etapa avanzada, en la que las aplicaciones ya se encuentran codificadas, y “volverlas
accesibles” puede significar un gran esfuerzo de rediseño y reprogramación, esfuerzo que
generalmente se encuentran fuera del alcance del proyecto, por no haber sido considerado en
su planificación y presupuesto inicial.
Motivados por esta situación nos focalizamos en la tarea de proponer un framework
integrador que sirva como instrumento para asistir a los desarrolladores en el diseño y
construcción de sus aplicaciones Web, desde el inicio del desarrollo, durante la toma de
decisiones de diseño y especificación de las interfaces de usuarios, para atender
simultáneamente los aspectos esenciales de diseño y las propiedades deseables de
Accesibilidad. Particularmente centramos nuestra esfuerzo en desarrollar un Mapeo de las
pautas de la WCAG 1.0 [34] a las clases de decisión de diseño del framework propuesto por
Larson en [17] y a los componentes del patrón arquitectónico más ampliamente utilizado en el
diseño de interfaces de aplicaciones Web: Model View Controller (MVC) [5]. En este punto
cabe señalar que cada una de las pautas de la WCAG 1.0 [34] se enfoca en un objetivo de
Accesibilidad y se compone de un conjunto de puntos de verificación. Cada punto de
verificación tiene a su vez su propio objetivo de Accesibilidad destinado a consolidar el
objetivo de la pauta a la que pertenece. Dada una página Web, asegurar la conformidad para
un determinado punto de verificación significa evitar la presencia de barreras de
Accesibilidad para determinados usuarios Web. El grado del aporte a la Accesibilidad de la
página Web que proporciona la conformidad de un determinado punto de verificación, se
refleja en el nivel de prioridad que tiene asignado. Estos conceptos que fundamentan la
filosofía de las guías de la WCAG 1.0 [34], se utilizaron para trabajar individualmente sobre
cada una da las pautas a través de sus respectivos puntos de verificación, "mapeándolos" a las
clases de decisión del framework de Larson [17] y a los componentes del patrón MVC [5].

1.2 Objetivo
El objetivo de este trabajo de tesis es asociar las pautas de recomendación de la WCAG 1.0
[34] con las clases de decisión de diseño del framework propuesto por Larson [17] y los
componentes del patrón arquitectural MVC [5], a los efectos de explicar como direccionar
arquitecturalmente los objetivos de cada punto de verificación de las pautas, en componentes
reusables, para fortalecer las decisiones de diseño tomadas en la etapa temprana del
desarrollo, contribuyendo a mejorar la Accesibilidad de una aplicación Web.
Los objetivos principalmente específicos de esta tesis son los siguientes:
• Estudio de las recomendaciones sobre Accesibilidad de la W3C. De esto se desprende
el estudio de las pautas de las WCAG 1.0 [34] como base para evaluar la
Accesibilidad de aplicaciones Web.
• Estudio del framework para el diseño de interfaces de usuario propuesto por Larson
en [17]. En este caso, se deberá analizar cada una de las clases de decisión de diseño
propuestas por el framework y sus relaciones con el patrón arquitectural MVC [5].
• Desarrollo de un Framework integrador que resulta del Mapeo de las pautas de las
WCAG 1.0 [34] a las clases de decisión de diseño propuestas por Larson en [17] y
sus relaciones con el patrón arquitectural MVC [5].
• Análisis de las ventajas del enfoque propuesto sobre un Caso de Estudio.
4 Capítulo 1 - Introducción al Proyecto

De esta manera es posible analizar las ventajas de nuestra propuesta desde el patrón MVC,
patrón cuyos conceptos han sido y son ampliamente aplicados al desarrollo de interfaces de
usuarios para productos modernos y tecnologías actuales.

1.3 Organización
Este trabajo de tesis se organiza de la siguiente manera:
1. En el Capítulo 2 se introduce el estado del arte en Accesibilidad Web, para
familiarizar al lector con los tópicos necesarios que le permitirán entender la
problemática fundada detrás de la Accesibilidad y el rol preponderante que asumen
las pautas de las WCAG 1.0 [34]. El Capítulo da inicio con una breve reseña histórica
para luego presentar la definición de Interfaz de Usuario y las limitaciones de acceso
que puede encontrar un usuario al navegar por una aplicación Web. Para finalizar
introduce el concepto de Accesibilidad Web y los referentes técnicos actualmente
vigentes.
2. En el Capítulo 3 se describe el framework para el diseño de interfaces de usuario
propuesto por Larson en [17] para comprender en profundidad que significa tomar
una decisión de diseño y como pueden ser agrupadas en clases de decisión. Esta
comprensión es indispensable para avanzar sobre la relación entre estas clases y el
patrón arquitectural MVC [5] (objetivo del Capítulo 4).
3. En el Capítulo 4 se presentan los tres componentes del patrón arquitectural MVC [5]
con el objetivo de comprender su relación arquitectural con el framework de clases de
decisiones de diseño de interfaces propuesto por Larson [17] (Capítulo 3) y su amplia
utilización por parte de los desarrolladores, como guía en el diseño de arquitecturas
de aplicaciones Web. Este Capítulo describe brevemente cada componente del patrón,
sus responsabilidades y el flujo de comunicación que existe entre ellos.
4. En el Capítulo 5 se forja el objetivo y corazón de este trabajo. En el se propone
nuestro Framework basado en el Mapeo propiamente dicho de las pautas de las
WCAG 1.0 [34] a las clases de decisión de diseño propuestas por Larson en [17] y a
los componentes del patrón MCV [5]. Esta actividad considera las 14 pautas de las
WCAG 1.0 [34] y las clases de decisión de diseño Diálogo, Presentación y
Pragmática dado que solo estas tres clases están relacionadas directamente con la
interacción usuario-sistema y por lo tanto involucradas directamente con la
Accesibilidad Web.
5. En el Capítulo 6 se presenta un Caso de Estudio en el que se utilizó específicamente
el Mapeo de las pautas de las WCAG 1.0 [34] a las clases de decisión de diseño
propuestas por Larson en [17] y a los componentes del patrón MCV [5], desarrollado
en el Capítulo 5. Él Mapeo fue utilizado como herramienta principal, para asistir al
diseño y desarrollo de la interfaz de usuario de la aplicación Web “Gestor de
Incidentes y Emisiones” (GIE). El objetivo planteado en el caso de estudio fue
demostrar como a través del uso del Mapeo como herramienta en la etapa de diseño
de la interfaz de usuario obtuvimos una interfaz con las características de
Accesibilidad deseadas.
6. En el Capítulo 7 se presentan los trabajos que guardan relación con esta tesis.
7. En el Capítulo 8 se presentan las conclusiones de los resultados obtenidos y los
posibles trabajos futuros destacando los aportes y limitaciones de esta tesis.
Capítulo 2
Accesibilidad Web
La información en la Web se ha convertido en la principal fuente de conocimiento para el
siglo XXI. La posibilidad o imposibilidad de acceder a los contenidos en la Web marcan los
límites de la denominada “brecha digital”. En el mundo virtual también existen barreras que
pueden dificultar el acceso a la educación, el trabajo o cualquier otro ámbito social. Para
comprender esta problemática, es fundamental conocer cuando una aplicación Web es
“accesible”, su importancia y beneficios, la visión de los diferentes países respecto de esta
temática, normas y legislaciones vigentes, así como también quienes son los protagonistas
que están de un lado y de otro de la Accesibilidad, objetivos del presente Capítulo.
Este Capítulo se organiza de la siguiente manera: en la Sección 2.1 se introduce el concepto
de Diseño Universal y su importancia; la Sección 2.2 presenta la definición de Interfaz de
Usuario y las limitaciones de acceso a esta; la Sección 2.3 desarrolla por completo la temática
de la Accesibilidad Web, su importancia, beneficios, normas y legislaciones vigentes en los
diferentes países, concluyendo con la situación actual en la Argentina.

2.1 Un poco de Historia: La Importancia del Diseño

Universal en la Web
Los seres humanos somos diferentes entre sí. Cuando una “diferencia personal” supera un
límite más o menos arbitrario a menudo recibe la etiqueta de discapacidad. Teniendo en
mente lo expresado en [10], introducimos a la discapacidad como un tema muy antiguo, que
cada civilización, cada cultura, cada país, cada comunidad, lo ha encarado desde diferentes
ángulos y con variadas propuestas.
En 1974, en la “Reunión del Grupo de Expertos sobre el Diseño Libre de Barreras” realizada
en Nueva York, se encuentran los primeros antecedentes sobre la necesidad de la eliminación
de obstáculos físicos que impiden a las personas con discapacidad participar plenamente de la
vida en sociedad, estableciendo el requisito de la inclusión del tema en la formación de
arquitectos, ingenieros, urbanistas y paisajistas. Surgen los primeros documentos sobre la
formación de los profesionales para la eliminación de barreras físicas. Más reciente es aún la
adecuación del entorno físico a las necesidades de las personas con discapacidad. Surge
entonces la necesidad de plantear la preocupación, ya no de derribar barreras sino, de
construir sin barreras y entonces se comenzó a difundir los conceptos relativos a
Accesibilidad Física Integral como condicionante para la integración y normalización de la
población involucrada en la denominación de personas con movilidad y comunicación
reducida.
Con el desarrollo de las tecnologías, de las telecomunicaciones y la informática se extendió el
tema de la Accesibilidad a estos medios que han invadido el mundo del trabajo, la recreación
y la interacción social. En 1994 en el Seminario Iberoamericano de Accesibilidad al Medio
Físico se planteó la superioridad del Diseño Universal sobre la Accesibilidad al Medio
Físico. La propuesta, establecía que todo el entorno debía servir para todos, sin contemplar
soluciones, muchas veces basadas en la discriminación positiva que trata de compensar las
diferencias de capacidades con diferencias en el medio físico que permiten equiparar
posibilidades. Aparece entonces el concepto de Diseño Universal, cuyo objetivo es la
realización y la composición de diferentes entornos y productos “accesibles” y
6 Capítulo 2 - Accesibilidad Web

“comprensibles”, a la vez que “usables3” en todo el mundo, en la mayor o menor medida y de

la forma más independiente y natural posible, sin la necesidad de adaptaciones ni soluciones
especializadas de diseño. El Diseño Universal establece entonces, tener en cuenta las
necesidades de todos los usuarios hipotéticos desde las primeras fases de los diseños de los
productos, de forma que tanto las personas mayores como aquellas que padecen alguna
discapacidad son tenidas en cuenta a la hora de elaborar cualquier oferta. Es importante
considerar también, que bajo el concepto de Diseño para Todas las Personas, intervienen en el
uso del entorno otros aspectos, como la calidad de ejecución, el mantenimiento, los recursos
económicos, las limitaciones propias de las personas, la cultura, el ambiente, etc.; que no
deben olvidarse. Todos estos podrían significar limitaciones al concepto propuesto de Diseño
Universal.
Existen una serie de principios de Diseño Universal redactados por un grupo de expertos en
el tema, aplicables en varios campos, como la arquitectura, la ingeniería y, por supuesto, a las
aplicaciones Web. Estos principios no tienen en cuenta aspectos cómo la estética, el coste, la
seguridad o el respeto a la diversidad; aspectos que también deberían tenerse en cuenta
durante el proceso de diseño. A continuación la Tabla 2.1 presenta una breve descripción de
los Principios Generales de Diseño, definidos en [8], que permitirán introducirnos en la
Accesibilidad de sistemas interactivos.

TABLA 2.1: Breve descripción de los Principios Generales del Diseño Universal para aplicaciones Web [8].
Principio Descripción Pauta a aplicar sobre el diseño
Uso La aplicación Web ha de ser • Proporcionar las mismas maneras de uso para todos los
equitativo usable4 y de un precio razonable usuarios: idénticas cuando es posible, equivalentes
para personas con diferentes cuando no lo es.
habilidades • Evitar segregar o estigmatizar a cualquier usuario.
• Igualdad de disponibilidad a todos los usuarios de
características de privacidad, garantía y seguridad.

Uso flexible El diseño de la aplicación Web
deberá contemplar que la misma
pueda ser usada por un rango
amplio de personas con distintos
gustos y habilidades.
• Ofrecer al usuario posibilidades de elección en los
métodos de uso.
• Acceso y uso tanto con la mano derecha como con la
izquierda.
• Facilitar al usuario la exactitud y precisión.
• Adaptar el paso al ritmo del usuario.

Uso simple e La aplicación Web deberá ser • Eliminar la complejidad innecesaria.

intuitivo fácil de entender,
independientemente de la
experiencia del usuario,
conocimiento, habilidades del
lenguaje y nivel de
concentración actual.
• Consistencia con las expectativas e intuición del usuario.
• Adaptar a un amplio rango de alfabetización y habilidades
lingüísticas.
• Dispensar la información de manera consistente con su
importancia.
• Proporcionar avisos eficaces y métodos de respuesta

3
El estándar ISO 9241-11 [15] presenta el concepto de Usabilidad como la medida en la que un
producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad,
eficiencia y satisfacción, en un contexto de uso especificado.
4
Jackob Nielsen define [23] Usabilidad de las aplicaciones Web como el atributo de calidad que mide
lo fáciles de usar que son las interfaces Web. Es por lo tanto fundamental tener en cuenta que una
buena Usabilidad es aquella que pasa totalmente desapercibida porque el usuario puede entender sin
esfuerzo, qué puede hacer, a dónde puede ir y qué le ofrece la página que consulta.
2.1 Un poco de Historia: La Importancia del Diseño Universal en la Web 7

durante y tras la finalización de la tarea.

Información El diseño de la aplicación Web
perceptible debe comunicar la información
necesaria de manera efectiva al
usuario, independientemente de
las condiciones ambientales
para las habilidades sensoriales
del mismo.
• Usar diferentes modos para presentar de manera
redundante la información esencial (gráfica, verbal o
táctil).
• Proporcionar contraste suficiente entre la información
esencial y sus alrededores.
• Ampliar la legibilidad de la información esencial.
• Diferenciar los elementos en formas que puedan ser
descritas (por ejemplo, que haga fácil dar instrucciones o
direcciones).
• Proporcionar compatibilidad con varias técnicas o
dispositivos usados por personas con limitaciones
sensoriales.

Tolerancia El diseño de la aplicación Web
para el error debe minimizar posibles
incidentes por azar y las
consecuencias adversas de
acciones no previstas.
• Disponer los elementos para minimizar los riesgos y
errores: elementos más usados, más “accesibles”; y los
elementos peligrosos eliminados, aislados o tapados.
• Proporcionar advertencias sobre peligros y errores.
• Proporcionar características seguras de interrupción.

Esfuerzo El diseño de la aplicación Web
físico mínimo debe proporcionar que la misma
se use de manera confortable y
eficiente con un mínimo de
fatiga.
• Permitir que el usuario mantenga una posición corporal
neutra.
• Utilizar de manera razonable las fuerzas necesarias para
operar.
• Minimizar las acciones repetitivas.
• Minimizar el esfuerzo físico continuado.

Tamaño y El diseño de la aplicación Web • Proporcionar una línea de visión clara hacia los elementos
espacio para debe proporcionar un tamaño importantes tanto para un usuario sentado como de pie.
poder apropiado de la interfaz para la • El alcance de cualquier componente debería ser
aproximarse y aproximación, alcance y uso de confortable para cualquier usuario sentado o de pie.
usar el diseño la misma. • Acomodar diferentes dispositivos de variado agarre para
diferentes tamaños de manos.
• Proporcionar el espacio necesario para el uso de ayudas
técnicas o de asistencia personal.

2. 2 ¿Qué es Una Interfaz de Usuario?

Un buen punto de partida para introducirnos en la Accesibilidad Web, es fijar el concepto de
Interfaz de Usuario, ya que creemos que es a este nivel donde finalmente se manifiestan las
barreras de Accesibilidad, presentadas en la Sección 2.2.1.
Cuando una persona usa una herramienta, accede o interactúa con un sistema, suele haber
“algo” entre esa persona y el objeto de interacción. Tal como se define en [1], la Interfaz es la
superficie de contacto entre ambos. En el caso de una puerta, por ejemplo, ese algo es el
picaporte, en la interacción persona-ordenador es el teclado, el monitor, el mouse, u otros
dispositivos. El usuario interactúa con el ordenador para poder realizar una tarea. La Interfaz
de Usuario es la parte del sistema que el usuario ve, oye, toca y con la que se comunica; es la
parte que le informa qué acciones son posibles realizar, el estado actual del sistema y los
cambios producidos.
En [22] se define que la Interfaz de Usuario de un sistema consiste de aquellos aspectos del
sistema con los que el usuario entra en contacto, físicamente, perceptivamente o
8 Capítulo 2 - Accesibilidad Web

conceptualmente. Los aspectos del sistema que están “escondidos” para el usuario formarían
parte de lo que se denomina implementación. De forma general se puede considerar entonces
como Interfaz de Usuario al conjunto de dispositivos y métodos que se utilizan para permitir
la interacción entre las máquinas y las personas que las utilizan. Por lo tanto, las interfaces de
usuario pueden tomar muchas formas, pero siempre cumplen dos requisitos fundamentales:
comunicar información desde la máquina al usuario y comunicar información desde el
usuario a la máquina.
Si bien en los últimos años, los dispositivos utilizados para implementar las interfaces de
usuario en los ordenadores no han cambiado sus características físicas sustancialmente, sí lo
ha hecho y a rápida velocidad, la forma o métodos en los que la pantalla puede usarse para
intercambiar información al usuario, junto con los sistemas de audio facilitando la
Accesibilidad a las aplicaciones. Como complemento a lo aquí vertido, posteriormente en la
Sección 3.1 del Capítulo 3, presentamos una breve descripción conceptual de los dispositivos
utilizados en la actualidad, que podrá servir como sustento al concepto de Interfaz de Usuario,
desarrollado en esta Sección.

2.2.1 Limitaciones de Acceso

Los Tipos de Limitaciones, en el acceso a aplicaciones, que pueden dificultar la utilización de
la Web se pueden clasificar en cinco categorías:
1.- Limitaciones Físicas
• Discapacidades Sensoriales
Visuales: Las deficiencias visuales más comunes son las debidas a la incapacidad
para captar correctamente los colores, a una visión reducida, ceguera o falta de visión
completa.
Auditivas: Las deficiencias auditivas pueden ser consideradas menos limitadoras en
el acceso y uso de contenidos digitales, debido a que el canal sonoro es mucho menos
utilizado en interfaces Web que el canal visual. Aún así, en ocasiones hay cierta
información que es necesario convertir en texto para que usuarios con deficiencias
auditivas sean capaces de seguirla, por ejemplo cuando los mensajes de alerta son
codificados como sonidos.
No menos importante son las limitaciones y barreras derivadas de esta discapacidad
como el caso de personas que utilizan el lenguaje de signos desde su nacimiento.
Estas personas a menudo tienen una reducción importante en el número de palabras
que conocen y utilizan por lo que los diseñadores deberían prestar especial atención
en el vocabulario utilizado.
• Discapacidades Motoras
Algunas personas tienen problemas para realizar ciertas tareas físicas, debido a
limitaciones de movimiento de alguno o diversos miembros o limitaciones posturales,
como mover un puntero, pulsar dos teclas a la vez o mantener apretada una tecla. En
el caso más extremo estas personas pueden no ser capaces de utilizar un teclado o un
mouse y simplemente pueden preferir utilizar un sistema alternativo de introducción
de datos, como por ejemplo: uno basado en voz o en movimientos de otras partes del
cuerpo (como la cabeza, la boca, etc.) También se pueden dar situaciones de
discapacidad transitoria, como por ejemplo: que una persona se lesione (quebradura)
el brazo.
2.- Características Intelectuales – Discapacidades Cognitivas y de Lenguaje:
2. 2 ¿Qué es Una Interfaz de Usuario? 9

En esta categoría se pueden agrupar dificultades de aprendizaje (hiperactividad,

desórdenes de atención, dislexia5, etc.), falta de memoria, bajo o nulo nivel de
alfabetización, falta de experiencia con tecnologías (usuarios inexpertos o con nivel
de inseguridad frente a la utilización de diversos dispositivos electrónicos),
dificultades con el idioma (habla extranjera o menor nivel cultural), entre otros.
Un problema que entra en esta categoría, pero diferente, es el de aquellas personas
que tienen un nivel intelectual normal en diversos aspectos, pero sin embargo
presentan deficiencias en aspectos concretos. Por ejemplo, hay personas con mucha
capacidad verbal pero baja inteligencia numérica o espacial. Estas personas no serían
capaces de realizar cálculos considerados sencillos, o también, de perderse dentro de
una estructura de navegación relativamente compleja.
3.- Problemas Derivados de la Edad Avanzada:
Un factor de gran importancia es el progresivo envejecimiento de la población y el
aumento de enfermedades degenerativas relacionadas con ella. Las personas de la
tercera edad pueden sufrir disminuciones de las capacidades físicas y mentales
(visión, oído, movilidad en las manos, memoria, capacidad de aprendizaje, etc.) y son
un colectivo que se debe tener muy presente.
4.- Limitaciones Tecnológicas:
Las limitaciones tecnológicas abarcan todo lo relacionado con el hardware, software
y medios de comunicación, utilizados por el usuario en el acceso a la información.
Estas limitaciones pueden alterar la manera en que el usuario capta información e
interactúa con la misma.
• Hardware
Limitaciones por los dispositivos que se usan (PC, PDA, teléfonos móviles, tipos de
conexión a Internet…). Las personas pueden disponer de dispositivos lentos o
antiguos. La tecnología avanza a un ritmo vertiginoso y no todo el mundo dispone de
los medios necesarios para, o simplemente no quiere, readaptarse constantemente a
los nuevos cambios. Existen además zonas de población (núcleos pequeños, la
cordillera, etc.) donde la tecnología llega con bastante retardo respecto a lo que lo
hace en las grandes concentraciones humanas.
Caso contrario al anterior, personas con dispositivos muy modernos, recién
aparecidos en el mercado, que encuentran multitud de dificultades debido a que las
infraestructuras no suelen estar preparadas para dichos mecanismos.
• Software
Existen distintos navegadores para los diferentes hardwares (Mozilla, Internet
Explorer, Opera, Safari, Konqueror…), cada uno con distintas versiones, motores
implementados, que pueden correr en diferentes plataformas (sistemas operativos) y
que pueden presentar diferencias de funcionamiento. Además de los navegadores
visuales (de texto o imágenes) también hay otros agentes de usuario (aplicaciones que
interpretan los documentos y recopilan información), como por ejemplo navegadores
no visuales (de audio o con lenguaje Braille), buscadores, proxies, etc.
• Comunicaciones
Las personas que navegan por la red a través de conexiones con muy pequeño ancho

5
Dislexia [36] (de dis – dificultad, anomalía, y lexia del griego habla o dicción): trastorno de la lectura
que imposibilita su realización correcta. En psicología y psiquiatría se define la dislexia como una
discrepancia entre el potencial de aprendizaje y el nivel de rendimiento de un sujeto, sin que existan
problemas sensoriales, físicos o, motores o deficiencias educativas
10 Capítulo 2 - Accesibilidad Web

de banda o que pagan altos costes de conexión (por ejemplo llamando mediante
teléfonos móviles) deben limitar por tanto el tamaño de la información transmitida.
• Ayudas técnicas
Teclados virtuales, programas de reconocimiento de voz…
5.- Condiciones ambientales:
Otras circunstancias externas pueden dificultar el acceso a la información, como por
ejemplo el ruido, la luz insuficiente, espacio reducido, etc.
Concluyendo, como indica Vanderheiden en [27], la discapacidad no es el único tipo de
limitación que dificulta la Accesibilidad de contenidos. Además de las limitaciones propias
del individuo, existen otras derivadas del contexto de uso y del dispositivo de acceso
empleado (hardware y/o software). Lo más interesante de este hecho es el paralelismo
existente entre limitaciones, ya que aún teniendo diferente origen suponen barreras similares
en el acceso a la información, Por ejemplo, comparten el mismo problema de visualización
aquellos usuarios con visión reducida, como aquellos que, sin padecer discapacidad visual,
utilicen pantallas pequeñas o accedan desde entornos llenos de humo.

2.3 ¿Qué es la Accesibilidad Web?

La Accesibilidad es la facilidad con la que algo puede ser utilizado, visitado o “accedido” en
general por todas las personas y especialmente por aquellas que tienen algún tipo de
discapacidad. Las barreras que los usuarios discapacitados y personas de edad avanzada
encuentran para interactuar con sistemas interactivos están relacionadas principalmente con
la interfaz de usuario e incluyen las dificultades físicas para manipular los dispositivos y las
barreras cognitivas para entender los procedimientos y la navegación. Usualmente las
interfaces se diseñan pensando en una persona estándar con todas las capacidades físicas y
cognitivas, lo que frecuentemente deja fuera a los colectivos de personas con “necesidades
especiales”.
La Accesibilidad aplicada al contenido de Internet se denomina “Accesibilidad Web”. La
Accesibilidad Web se basa en el concepto de que un producto o servicio Web pueda ser
accedido y usado por el mayor número posible de personas, indiferentemente de las
limitaciones propias del individuo o de las derivadas del contexto de uso [21]. En la
definición, ‘las limitaciones propias del individuo’ no solo engloban aquellas representadas
por discapacidades, sino también otras como pueden ser el idioma, conocimientos o
experiencia. En concreto, la Accesibilidad Web, hace referencia a un diseño Web que va a
permitir que cualquier persona, pueda percibir, entender, navegar e interactuar con la Web,
aportando a su vez contenidos. Así mismo, es importante destacar que la Accesibilidad se
proporciona por una combinación de hardware y software: el primero proporciona los
mecanismos físicos que permiten salvar ciertas discapacidades y el segundo proporciona la
manera eficaz de acceder a las funcionalidades e informaciones para estos dispositivos y a
otros programas (por ejemplo un navegador Web).

2.3.1 ¿Por qué la Accesibilidad Web es Importante?

A pesar de que el surgimiento de la World Wide Web, y su posterior crecimiento exponencial,
han supuesto un cambio radical en cuanto a la facilidad de difusión y disponibilidad de la
información, rompiendo, en ocasiones, las barreras físicas para usuarios con discapacidades,
abriéndoles una gran cantidad de oportunidades de relaciones sociales, educacionales,
opciones laborales, sanidad y de muchos tipos más. Las limitaciones y el mal uso por parte de
2.3 ¿Qué es la Accesibilidad Web? 11

los diseñadores de las tecnologías actuales de desarrollo Web, están dando lugar a situaciones
que imposibilitan el acceso a la información por parte de estos usuarios.
Actualmente, la mayoría de los sitios Web presentan barreras de Accesibilidad, lo que
dificulta o imposibilita la utilización de la Web para muchas personas con discapacidad. Uno
de los principales motivos, se debe a que la Accesibilidad es vista hoy en día cómo una
dificultad añadida al diseño de aplicaciones Web. Mientras que muchos desarrolladores
estarían de acuerdo en “pretender” que el mayor número de usuarios sea capaz de usar sus
productos, no todos ellos se sentirían tan dispuestos a realizar los esfuerzos necesarios para
lograrlo, ya que existe una percepción de que el volumen de la población con “necesidades
especiales” no es lo suficientemente importante. Percepción, sin embargo, posiblemente
errónea. Existen “millones” de personas con discapacidad que no pueden utilizar la Web. Otro
motivo y no menos importante, es que la mayoría de los programadores no tienen
conocimiento y experiencia, para lograr que su código cumpla con los objetivos o
características de Accesibilidad deseadas. Por otro lado los especialistas de Accesibilidad
tienen limitaciones y poca experiencia en el desarrollo de aplicaciones y más aún en la
programación.
Si bien, para solucionar los problemas de acceso a los recursos que ofrece Internet existen
numerosas ayudas técnicas, en función de la diversidad de limitaciones de los usuarios, para
poder acceder a los recursos recogidos en las páginas Web, es necesario que el diseño de las
mismas resulte “accesible”. Actualmente existe una carencia general de comprensión de estas
ayudas técnicas y guías. La mayoría se enfocan en el diseño de sitios Web estáticos o
formularios Web básicos que no reflejan los patrones de las aplicaciones actuales, dinámicas
y con un alto grado de complejidad, así como también introducen la Accesibilidad en el
proceso de desarrollo, en una etapa avanzada, en la que las aplicaciones ya se encuentran
codificadas, y “volverlas accesibles” puede envolver un significante esfuerzo de rediseño y
reprogramación, esfuerzo que generalmente se encuentran fuera del alcance del proyecto, por
no haber sido considerado en su planificación y presupuesto inicial.
Es sumamente importante que la Web sea “accesible” para así proporcionar un acceso
equitativo e igualdad de oportunidades a las personas con discapacidad. Una página Web
“accesible” puede ayudar a estas personas a que participen más activamente en la sociedad.
Cuanto más software y sitios Web “accesibles” estén disponibles, más personas con
discapacidad podrán utilizar la Web y contribuir de forma más eficiente. Por lo tanto, es
necesario evitar diseñar solamente atendiendo a características de grupos de población
específicos, imponiendo barreras innecesarias, posibles de evitar. No obstante, existen
muchas otras razones que se pueden encontrar para diseñar de forma “accesible”. Cualquier
producto que sea diseñado atendiendo a limitaciones derivadas de discapacidades
individuales, posibilitarán y facilitarán así mismo su acceso por usuarios que, sin padecer
estas discapacidades, se encuentren en contextos de uso desfavorables y de equivalente
limitación, por lo que el número de usuarios beneficiados de este modo de diseño sería mayor
que el representado por usuarios con discapacidad [25].
La Accesibilidad Web beneficia también a compañías, organizaciones y personas sin
discapacidad. Por ejemplo, un principio básico de la Accesibilidad Web es la flexibilidad,
cuyo objetivo es satisfacer diferentes necesidades, situaciones y preferencias. Esta flexibilidad
beneficia a todas las personas, incluyendo a quienes no tienen ninguna discapacidad pero que,
debido a determinadas situaciones, tienen dificultades para acceder.
A continuación presentamos y adaptamos el planteo establecido en [18] y [32], respecto a los
beneficios empresariales, técnicos y de otra índole para diferentes tipos de organizaciones y
compañías, y de los beneficios directos para las personas con discapacidades, que se pueden
obtener con una Web “accesible”.
12 Capítulo 2 - Accesibilidad Web

• Beneficio Social:
El creciente uso de Internet en todas las áreas de la sociedad hace que la Accesibilidad
represente un paso adelante para la independencia de las personas con discapacidades. La
Accesibilidad en las páginas Web proporciona un acceso equitativo, igualdad de
oportunidades, incremento de las posibilidades laborales y educativas, permitiendo a las
personas con discapacidades participar hasta en las actividades cotidianas, cómo leer el
periódico o realizar la compra semanal, etc.
• Beneficio para Todos los Usuarios:
El beneficio de la Accesibilidad no repercute solamente en las personas que realmente lo
necesitan; no se excluyen grupos de personas que potencialmente pueden formar parte del
los usuarios de las páginas Web, sino que tal como lo indica la Tabla 2.2 otros colectivos
también se ven favorecidos con estas adaptaciones.
TABLA 2.2: Situaciones en que personas sin necesidades especiales pueden verse beneficiadas por interfaces
accesibles [18].
Tipo de Personas afectadas Situaciones que provocan esta Tecnologías de
discapacidad discapacidad a otras personas Rehabilitación
Sin visión Ciegos - Ojos ocupados (al conducir) - Lectores de pantalla
- En la oscuridad
Poca visión Con limitaciones visuales - Visor pequeño - Pantallas más grandes
(pérdida parcial de la - Ambiente con humo - Fuentes mayores
visión, deficiencias en la - Aumento del contraste
percepción de los - Ampliaciones de
colores) pantalla

Operable sin Sordos - Entornos muy ruidosos - Show Sounds6

poder oír - Oídos ocupados
- Silencio forzado (en bibliotecas)

Oído limitado Duros de Oído7 - Entornos ruidosos (en - Show Sounds

confiterías, locales bailables)
Impedimento Con funciones motoras - Vestir ropa especial (p.e. - Eye Tracking8
físico limitadas (problemas de astronautas) - Teclados en la pantalla
coordinación, debilidad, - Dentro de un vehículo que se - Reconocedores de voz
dificultad de movimiento balancea - Dispositivos
en extremidades) apuntadores
alternativo

Impedimento Con discapacidades - Situación de distracción - Texto resaltado (para

cognitivo cognitivas (dificultad al - Situación de pánico problemas de lectura)
recibir información, de - Bajo influencia del alcohol - Reconocedores de voz
procesarla y de (para problemas de
comunicación) escritura )
Operable sin Ciertas discapacidades - De visita en un país del cual se - Internacionalización
poder leer cognitivas desconoce el idioma del software

6
Show Sounds: término en inglés utilizado para definir el proceso de presentar la información auditiva
en formato visual.
7
Duros de Oído: personas con dificultad para distinguir cambios de frecuencia sonora o de localización
de sonidos.
8
Eye Tracking: termino en inglés utilizado para definir el proceso de evaluar bien el punto donde se
fija la mirada (donde estamos mirando), o el movimiento del ojo en relación con la cabeza.
2.3 ¿Qué es la Accesibilidad Web? 13

- Olvido de los anteojos de lectura - Texto resaltado

• Beneficio Tecnológico:
- En el mundo de las aplicaciones y tecnologías Web, en continua evolución, cobra
sentido el diseñar el contenido y servicio de modo que pueda ser adaptado rápida y
eficientemente para cumplir cualquiera circunstancia nueva. El diseño “accesible”
fomenta el uso de diversas utilidades de los sistemas operativos y de los navegadores
(no se apuesta únicamente por los más utilizados), y facilita a que el sitio Web se
encuentre disponible a la cambiante (y creciente) base de usuarios y cualquier
tecnología nueva que éstos puedan escoger.
- El diseño “accesible” posibilita el acceso de usuarios con reducido ancho de banda.
Proporcionar contenido alternativo apropiado para conexiones de bajo ancho de
banda es una estrategia de crecimiento de mercado. A medida que se hace
“asequible”, la tecnología de banda ancha se convierte en una realidad para algunos
usuarios de la Web, pero la mayoría de los usuarios mundiales están limitados a
conexiones de bajo ancho de banda a causa de aislamiento geográfico, infraestructura
de comunicaciones subdesarrolladas, o limitaciones económicas. Incluso aquellos
residentes en áreas con acceso a infraestructuras de banda ancha pueden estar
limitados a aplicaciones de bajo ancho de banda por la tecnología que han elegido
usar (como teléfonos móviles, PDAs, etc.) o que están forzados a usar por
circunstancias económicas (por ejemplo sistemas antiguos).
- La Accesibilidad da soporte a la Web Semántica9, haciendo posible que la
información en la Web esté definida y enlazada de una forma que pueda ser usada por
máquinas no sólo para propósitos de representación, sino de automatización,
integración y reutilización de la información a través de varias aplicaciones. Las
organizaciones que adopten elementos de la Web Semántica se encuentran
posicionadas para incrementar sus audiencias conforme esta nueva tecnología se
desarrolla.
- La Accesibilidad mejora los listados de los motores de búsqueda y el descubrimiento
de recursos, ya que si los desarrolladores basan el contenido más importante del sitio
Web en texto, los motores de búsqueda u otras aplicaciones de explotación de datos
(minería de datos10) tienen significativamente más posibilidades de hallarlo. Desde un
punto de vista estratégico, todo lo que pueda hacer un desarrollador para incrementar
la probabilidad de que su sitio sea encontrado es un beneficio positivo para los
dueños del mismo.
- La Accesibilidad mejora la eficiencia de un sitio Web:
o Simplificando su desarrollo y mantenimiento: ciertas condiciones y requisitos
técnicos que recomienda la Accesibilidad dan como resultado mejoras en los
procesos de desarrollo. Conceptos como la separación de contenido y
presentación, o el uso de estándares, facilitan el desarrollo y mantenimiento. La
aplicación de los requisitos de Accesibilidad conlleva un ahorro de costes como
consecuencia de las mejoras en los procesos de desarrollo antes mencionadas.
o Reutilizando de recursos, como el contenido del sitio, a través de las practicas de
independencia de dispositivos.

9
La Web Semántica es una extensión de la Web actual en la que la información se ofrece con un
significado bien definido, facilitando que computadores y personas trabajen en cooperación.
10
La Minería de Datos (Data Mining) consiste en la extracción no trivial de información que reside de
manera implícita en los datos. Dicha información era previamente desconocida y podrá resultar útil
para algún proceso. En otras palabras, la minería de datos prepara, sondea y explora los datos para
sacar la información oculta en ellos.
14 Capítulo 2 - Accesibilidad Web

o Gestionando la carga del servidor Web, con peticiones de páginas satisfactorias

para el cliente ante un posible ancho de banda limitado, reducción del tráfico en
la conexión a Internet del sitio por desactivación de gráficos y utilización de
páginas livianas, por la separación del contenido de su estructura.
• Beneficio Económico.
- La Accesibilidad ofrece el potencial necesario para que las organizaciones y empresas
adquieran nuevos clientes y nuevos mercados:
o En cada Nación existen significantes cantidades de personas que no comparten el
mismo nivel de alfabetización que los profesionales que diseñan y escriben el
contenido de sus sitios Web. La Accesibilidad puede contribuir también a estos
usuarios con niveles de alfabetización diferentes.
o La Accesibilidad incrementa el soporte para la internacionalización, mejorando la
capacidad de una organización para llegar a una audiencia global. En un mercado
global en expansión, ignorar o alienar a potenciales clientes de otros países puede
ir en detrimento para una organización.
o Algunos beneficios para una organización, como la buena voluntad del público en
general, pueden ser menos tangibles que los económicos o técnicos descritos
anteriormente. Sin embargo, en un mercado mundial extremadamente
competitivo demostrar “responsabilidad social” no puede ignorarse, ya que
refuerza la actitud socialmente responsable de una organización.
Por todo lo hasta aquí expresado, se debe ver la Accesibilidad, no como una serie de
requisitos aislados para un grupo de usuarios concreto, sino como opciones de mejora
substancial de la calidad de la Web en general que aportará beneficios y permitirá estar mejor
preparados ante nuevos desafíos y futuras tecnologías Web.

2.3.2 Referentes Técnicos: W3C - WAI

El World Wide Web Consortium, o simplemente W3C, (Consorcio para la World Wide Web)
fue creado el octubre del 1994 para conducir a la World Wide Web a su máximo potencial
desarrollando protocolos de uso común que promocionen su evolución y asegurasen la
interoperabilidad. Constituye un consorcio industrial internacional, alojado por el
Massachusetts Institute of Technology Laboratory for Computer Science (MIT/LCS)
(Laboratorio de Ciencias de la Computación del Instituto de Tecnología de Massachusetts), en
los E.E.U.U.; el Institute National de Recherche en Informatique et en Automatique (INRIA)
(Instituto Nacional de Investigación en Informática y Robótica) en Europa (Francia); y la
Keio University Shonan Fujisawa Campus (Universidad Shonan Fujisawa de Keio) en Japón.
El consorcio está liderado por Tim Berners-Lee, director y creador de la World Wide Web, y
por Jean-François Abramatic, como presidente. El W3C esta formado por Organizaciones
Miembro, sin ánimo de lucro, que trabajan en la comunidad internacional para desarrollar
especificaciones y programas informáticos de referencia, que son distribuidos gratuitamente a
lo largo de todo el planeta. Las principales tareas de este organismo, son discutir, consensuar,
crear y promover los estándares de la Web, como las especificaciones de HTML [30], XML,
XHTML, CSS [28] [29], PNG, algunos de estos lenguajes descriptos en el Capítulo 5. Un
trabajo bastante complejo y no exento de dificultades, pero también muy importante, ya que
al crear estándares consensuados, evita desarrollos por caminos separados de especificaciones
propietarias incompatibles entre sí aunque persigan el mismo fin. El que un organismo, como
el W3C, reúna entidades con objetivos comunes, acelera el desarrollo de las tecnologías y
permite la máxima difusión y compatibilidad, favoreciendo a todos los estamentos implicados
en la Web, desde empresas desarrolladoras, hasta usuarios.
El grupo interno de trabajo permanente conocido cómo Web Accesibility Initiative (WAI)
[33], Iniciativa para la Accesibilidad de la Red, en coordinación con asociaciones y
organizaciones de todo el mundo, persigue la Accesibilidad de la Web a través de cinco
2.3 ¿Qué es la Accesibilidad Web? 15

actividades complementarias: tecnología, normativa, herramientas (de validación y

reparación), educación y formación, e investigación y desarrollo. De estas cinco actividades
mencionadas, la que capta mayor interés para esta tesis es el desarrollo de normativas con el
objetivo de proporcionar una serie de pautas que ayuden a los diseñadores de aplicaciones
Web a conseguir que estas sean “accesibles”. A continuación se mencionan los tipos de guías
redactados en relación a los objetivos finales que persiguen:
• Web Content Accessibility Guidelines (WCAG) [34]: se trata de un conjunto de
recomendaciones para que las páginas Web sean “accesibles” para todos con la ayuda de
la tecnología existente. Estas pautas no descartan los contenidos multimedia, solo apuntan
a que la información pueda accederse. Nos centraremos en esta guía y en particular en su
versión 1.0 en el siguiente Capítulo.
• Authoring Tool Accessibility Guidelines (ATAG): recomendaciones para que las
herramientas de diseño de páginas Web sean “accesibles” para todos, así como, el
resultado generado por ellas.
• User Agent Accessibility Guidelines (UAAG): recomendaciones para que los
navegadores y programas multimedia sean “accesibles” para todos y para que estas
herramientas puedan cooperar mejor con los dispositivos de tecnología asistida.
En particular, la normativa WCAG 1.0 [34] se compone de diferentes puntos de verificación a
satisfacer ponderados de acuerdo con el impacto al que pueden enfrentarse los posibles y
diferentes usuarios. Cada punto de verificación tiene asignado uno de los tres niveles de
prioridad:
• Prioridad 1: hace referencia a los puntos de verificación que el desarrollador “debe”
satisfacer; de lo contrario, algunos grupos de personas serán incapaces de acceder al
contenido de un sitio Web.
• Prioridad 2: hace referencia a los puntos de verificación que el desarrollador “debería”
satisfacer; sin ello alguien encontrará muchas dificultades para acceder a la información.
Satisfacer este punto salvará importantes barreras para acceder al contenido Web.
• Prioridad 3: hace referencia a los puntos de verificación que el desarrollador “podría”
satisfacer; de lo contrario, algunas personas hallarán dificultades para acceder a la
información. Ello mejoraría notablemente el acceso a los documentos Web.
Relacionado con estos niveles de conformidad o adecuación en los puntos de verificación, el
W3C presentó los Logotipos de Conformidad con las Directrices de Accesibilidad para el
Contenido Web. Los desarrolladores y propietarios de la Web pueden usar estos logotipos en
sus sitios, para indicar su declaración de conformidad son un nivel específico. Los “niveles de
adecuación” con estas directrices son:
• El nivel “A”: se satisfacen todos los puntos de Prioridad 1.
• El nivel “AA”: se satisfacen todos los puntos de Prioridad 1 y 2.
• El nivel “AAA”: se satisfacen todos los puntos de Prioridad 1, 2 y 3.

2.3.3 Legislación existente

La creciente importancia de la “sociedad de la información” y de las “tecnologías de la
información y la comunicación” ha generado la necesidad de una legislación que las regule y
que garantice el acceso, a todos los ciudadanos independientemente de sus discapacidades. Se
trata de iniciativas que intentan normalizar la Accesibilidad en Internet. Algunas de ellas
tienen fuerza de ley y otras son la base para la creación de esas leyes. Los objetivos de estas
normas son variados. Algunas intentan incentivar la integración a la “sociedad de la
información” a las personas con problemas de discapacidad y las personas mayores, mientras
que otras forman parte de un conjunto de pautas para el funcionamiento eficiente del
“gobierno electrónico” (e-government). A continuación presentamos una breve descripción de
16 Capítulo 2 - Accesibilidad Web

la situación actual en lo que se refiere a legislación y difusión de la Accesibilidad, haciendo

referencia a varios países del mundo y a la Argentina en particular.
Estados Unidos: La Sección 508 del "Acta de los Americanos con Discapacidad", de Estados
Unidos, creada en 1986, modificada en los años 92, 98 y en vigencia desde el 2001, exige
que cuando las Administraciones Públicas desarrollen, adquieran, mantengan, o usen
tecnología electrónica de la información, se aseguren que sus empleados con discapacidad
tengan el mismo acceso y uso de dichas tecnologías, que los empleados sin discapacidad, a
menos que constituya una carga excesiva. La Sección 508 también exige que los individuos
con discapacidad, que forman parte del público que busca información o servicios por parte
de una administración pública, tengan acceso a y el uso de la información y datos de manera
comparable a la que se proporciona al público que no son personas con discapacidad, a menos
que ello signifique una carga excesiva impuesta a la administración. La importancia de esta
ley es tal, porque no solo es aplicable a las páginas Web que ofrezcan servicios o productos a
la administración pública de ese país o sus ciudadanos sino que, debido a que muchas de las
empresas desarrolladoras de software son americanas, esta legislación están teniendo una gran
influencia en el desarrollo de herramientas de autor “accesibles” y que producen contenidos
“accesibles” para la Web.
España: En España la cantidad de normas que regulan la Accesibilidad Web es amplia, entre
las que destacamos:
o La Norma UNE 139802:1998 denominada "Informática para la salud. Aplicaciones
informáticas para personas con discapacidad. Requisitos de Accesibilidad de las
plataformas informáticas. Soporte lógico." fue la primera norma existente en todo el
mundo haciendo referencia a la creación “accesible” de páginas Web. Esta norma fue
revisada y ampliada, dividiéndose en dos y dando lugar a las normas UNE 139802:2003 y
UNE 139803:2004. Esta ultima norma es específica de "Requisitos de Accesibilidad para
Contenidos en la Web”.
o El Plan Info XXI responde a los objetivos establecidos en la iniciativa e-Europe,
aprobada en marzo de 2000 y entre las tres grandes líneas que se articula se encuentra “El
acceso de todos a la sociedad de la información”.
o La LEY 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de
Comercio Electrónico (LSSICE) establece que las administraciones públicas adoptarán
las medidas necesarias para que la información disponible en sus respectivas páginas de
Internet pueda ser “accesible” a personas con discapacidad y de edad avanzada de
acuerdo con los criterios de Accesibilidad al contenido generalmente reconocidos antes
del 31 de diciembre de 2005. Asimismo, podrán exigir que las páginas de Internet cuyo
diseño o mantenimiento financien apliquen los criterios de Accesibilidad antes
mencionados. También promoverá la adopción de normas de Accesibilidad por los
prestadores de servicios y los fabricantes de equipos y software, para facilitar el acceso
de las personas con discapacidad o de edad avanzada a los contenidos digitales.
o Como ejemplo de trabajo conjunto de organizaciones gubernamentales, la Consejería de
Trabajo Consumo y Política Social, la Secretaría Sectorial de Acción Social y la
Dirección General de Familia y Servicios Sectoriales de la Región de Murcia, comunidad
autónoma de España, han elaborado un conjunto de documentos, al que han llamado
“Diseño de páginas Web accesibles” [7]. Este conjunto recoge las traducciones,
adaptadas, de los documentos elaborados y publicados bajo el nombre de "Pautas de
Accesibilidad al Contenido en la Web 1.0” [34].

Brasil: En Brasil, en el 2004 fue sancionado el Decreto 5296, que regula las leyes 10.048, que
da prioridad de atención a las personas que especifica, y 10.098, que establece normas
generales y criterios básicos para la promoción de la Accesibilidad. El decreto define los
conceptos de: Barrera de Accesibilidad, Ayuda Técnica y Diseño Universal, y en el artículo
47 marca un plazo de 12 meses a partir de su publicación para que la Accesibilidad sea
2.3 ¿Qué es la Accesibilidad Web? 17

obligatoria en los portales y sitios electrónicos de la administración pública para el uso de

personas con discapacidad garantizándoles el acceso pleno a la información.
Japón: En Japón, se encuentra el programa e-Japan Priority Policy Program, confeccionado
en el 2001.
Argentina: Actualmente en la Argentina existe un proyecto de Ley sobre Acceso de las
Personas con Discapacidad a los Sitios de Internet, expediente 2954/0, en el Congreso de la
Nación, con media sanción de la Honorable Cámara de Diputados y en espera de ser aprobado
por la Cámara de Senadores. El proyecto establece que los entes que pertenezcan al Estado
Nacional, sus organismos descentralizados o autárquicos, los entes públicos no estatales, las
empresas del Estado y las empresas privadas concesionarias de servicios públicos, empresas
prestadoras o contratistas de bienes y servicios deberán respetar en los diseños de sus paginas
Web las normas y requisitos internacionales sobre Accesibilidad de la información que
faciliten el acceso a sus contenidos, a todas las personas con discapacidad para garantizar la
igualdad real de oportunidades y trato evitando así todo tipo de discriminación.
Las normas y requisitos de Accesibilidad serán las determinadas por la Oficina Nacional de
Tecnologías de la Información (ONTI), teniendo en cuenta las recomendaciones de nivel
internacional del W3C-WAI (Web Accesibility Initiative del World Wide Web Consortium) y
al respecto se deberán actualizar anualmente.
Seminario SIDAR [9] - Una referencia obligada para los hispanohablantes: Tan importante
como consensuar las especificaciones por parte del W3C y sus miembros, es la difusión de las
mismas. Los hispanohablantes cuentan con la Fundación SIDAR (acrónimo de «Seminario
Iberoamericano sobre Discapacidad y Accesibilidad en la Red» [9]). Las actividades de esta
fundación (por ejemplo, campañas, cursos, eventos, jornadas,…), servicios (como auditoria y
asesoría) y recursos, no sólo han servido para dar a conocer la Accesibilidad Web (con las
listas de correo que coordinan, o las aplicaciones desarrolladas), sino que también han
ayudado a difundir las nuevas tecnologías mediante la publicación de traducciones al
castellano, catalán y gallego de documentos del W3C (directrices, técnicas,
especificaciones,…, entre otras materias, de Accesibilidad Web).
Capítulo 3
Un Framework para el Diseño de Interfaz de
Usuario
En este Capítulo presentamos el framework para el diseño de interfaces de usuario propuesto
por Larson [17] con el objetivo de comprender en profundidad que significa tomar una
decisión de diseño y como pueden ser agrupadas en clases de decisión. Esta comprensión es
indispensable para avanzar sobre la relación entre estas clases y el patrón arquitectural MVC
[5] (objetivo del Capítulo 4) y posteriormente sobre el Mapeo de las pautas de las guías
WCAG 1.0 [34] en cada clase de decisión de diseño propuestas por Larson [17] (objetivo del
Capítulo 5).
Este Capítulo se organiza de la siguiente manera: en la Sección 3.1 se citan ventajas que
surgen de aplicar frameworks en el proceso de diseño, describe específicamente el framework
propuesto por Larson [17]; la Sección 3.1.1 explica los posibles criterios para determinar
clases de decisión y finalmente la Sección 3.1.2 detalla específicamente el modelo de clases
propiamente dicho.

3.1 Framework de diseño de LARSON

“La arquitectura de software11 representa las decisiones de diseño significativas que le dan
forma a un sistema, donde lo significativo puede ser medido por el costo del cambio" [3].
Una buena arquitectura debe proveer un marco adecuado para que las decisiones de diseño
significativas se logren establecer minimizando los riesgos de cambios futuros. Es un
principio básico de diseño que si los problemas son hallados en una etapa temprana del ciclo
de vida del proceso de software, estos son más fáciles de corregir. Una “arquitectura de
software” constituye un modelo intelectual, de cómo un sistema está estructurado y cómo sus
componentes trabajan en conjunto. Modelo que es transferible a través de sistemas que
exhiben requerimientos de dominio similares promoviendo el reuso a gran escala. Uno de los
tipos de reuso más importantes es el reuso del diseño. El reuso en un nivel arquitectural
facilita ampliamente el desarrollo de sistemas con requerimientos similares. Cuando las
decisiones arquitecturales pueden ser reusadas en varios sistemas, todas las consecuencias de
las decisiones tempranas también son transferidas.
El diseño de aplicaciones Web con necesidades de dominios específicas basado en un
“framework de aplicación12”, permitirá el reuso de todo o parte del sistema, aumentando la
facilidad de mantenimiento, integración, extensión y modularidad del mismo, disminuyendo
en gran medida los defectos, tiempos y costos incurridos en el proceso de desarrollo. Un

11
Una Arquitectura de Software es la organización fundamental de un sistema encarnado en sus
componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y
evolución [13].
12
Un Framework de Aplicación surge cuando un desarrollador personaliza un framework para una
aplicación particular al crear subclases y componer instancias de las clases del framework [11].
3.1 Framework de diseño de LARSON 19

“framework de aplicación”, es una categoría arquitectural que mantiene unidas las nociones
de: diseño, estructura, estilo, racionalidad, proceso y dificultad o costo del cambio.
Durante muchos años los desarrolladores de software se han enfocado en las consecuencias de
las decisiones de diseño tomadas durante el proceso de desarrollo, en el resultado de estas, en
la “arquitectura de software” seleccionada subyacente, representándola a través de gráficos
arquitecturales o de lenguajes de descripción de arquitecturas. Una de las consecuencias de
aplicar solo estas prácticas durante el desarrollo de una aplicación, es la pérdida del
conocimiento adquirido que los llevó a seleccionar la arquitectura subyacente, es decir, la
perdida del conocimiento de cada decisión de diseño en sí misma, conocimiento propio del
proceso de decisión.
Particularmente Larson propone [17] para este complejo proceso de decisión de diseño,
dividir las decisiones de diseño de interfaz de usuario, agrupándolas en diferentes clases, con
el objetivo de que los desarrolladores puedan concentrarse en cada clase por separado. De esta
manera, el framework propuesto, se compone de una colección de clases de decisión de
diseño, constituyendo las decisiones de diseño arquitecturales, la primera clase a instanciar en
la representación de la arquitectura de una aplicación.

3.1.1 Criterios para determinar clases de decisión

A continuación se detallan algunos de los criterios sugeridos por Larson, para ser utilizados
en la identificación y definición de clases de decisión de diseño. Durante el diseño de una
aplicación, en el momento de la toma de decisiones, algunos de estos criterios podrían ser
satisfechos más que otros:
• La capacidad de ser separados (Separability): las decisiones de cada clase deben ser
identificadas y separadas una de otras. Algunos criterios para lograr esta separación
serían:
- Decisiones de diseños determinadas en diferentes momentos podrían ser ubicadas
en clases diferentes. Por ejemplo, la información contenida en los mensajes que
serán intercambiados entre el usuario y la computadora, se definirá antes de la
especificación del formato, estilos, técnicas etc., que serán usadas tanto para el
ingreso de datos por parte de usuario y presentación al mismo de los resultados de
la información intercambiada.
- Decisiones de diseño tomadas por diferentes personas, podrían ser ubicadas en
clases separadas. Los distintos actores, con diferentes alcances, tareas y
responsabilidades, que forman parte del proceso de diseño y desarrollo de la
interfaz Web, necesitan tomar decisiones de diseño, estas deberían ser ubicadas
en diferentes clases. Por ejemplo un especialista en factores humanos es un buen
candidato para especificar el contenido de los mensajes intercambiados entre a
aplicación y el usuario, los aspectos de la secuencia y otras propiedades del
diálogo, mientras que un artista gráfico definiría los estilos, formatos y técnicas
de cómo el usuario ingresará la información, y de cómo serán mostrados los
resultados.
• Completitud (Completeness): Todas las decisiones necesarias deberían formar parte de
alguna de las clases de decisión.
• Suficiencia (Sufficiency): El conjunto de decisiones asignadas a una clase, debería ser lo
suficientemente grande para justificar la existencia de la clase.
• Fácil de entender (Undestandability): El conjunto de decisiones asignadas a una clase
debería ser lo suficientemente pequeño para que su significado y los efectos producidos
sobre el diseño de la interfaz puedan ser fácilmente entendidos.
20 Capítulo 3 - Un Framework para el Diseño de Interfaz de Usuario

• Independencia (Independece): El impacto de las decisiones tomadas en cada clase,

sobre las decisiones de otras clases debería nulo o minimizado.
• Reusabilidad (Resusability): Muchas de las decisiones tomadas en una clase para una
aplicación podrían ser aplicadas, en la correspondiente clase, en otras aplicaciones.
Tomando las mismas decisiones en las correspondientes clases de decisión, se
incrementa la uniformidad de interfaces de usuario a través de múltiples aplicaciones.
• Sensatez (Soundness): Las decisiones deberían fundamentarse en bases formales
sensatas. Por ejemplo Teoría de Lenguajes, Teoría de Compiladores e Intérpretes, etc.

3.1.2 Particiónamiento de decisiones de diseño de interfaz en

clases
Específicamente, las clases de decisiones de diseño de interfaz que componen el framework
propuesto por Larson son: Estructural, Funcional, Diálogo, Presentación y Pragmática. A
continuación explicamos cada una de estas clases.

1.- Estructural: En esta clase el analista de la aplicación especifica la estructura del “modelo
conceptual” del usuario final, es decir la descripción de los objetos conceptuales (dominio
de la aplicación) que serán manipulados (consumidos, producidos y/o accedidos) por los
usuarios a través de la interfaz. Esta especificación también incluye la descripción de las
restricciones y relaciones establecidas entre dichos objetos. Se excluyen los objetos
“independientes” de la aplicación, tal como ventanas, menús y otros objetos de
interacción que usualmente forman parte de la interfaz. Estos serán agregados al “modelo
conceptual” para formar la interfaz cuando las decisiones sobre presentación sean
tomadas.

2.- Funcional: En esta clase el analista de la aplicación especifica las funciones

(operaciones) que el usuario final puede aplicar a los objetos conceptuales. Es decir, se
describe en detalle: el significado (semántica) de cada función, la información requerida
para invocarlas (inputs), la información producida durante la ejecución de cada una
(outputs) y los errores que pueden ocurrir durante la ejecución. No forman parte de las
decisiones funcionales la secuencia de invocación de cada función.

3.- Diálogo: En esta clase el diseñador de diálogo especifica el contenido y secuencia del
intercambio de información entre el usuario y la aplicación. Es decir, especifica el “estilo
del diálogo”. Las respuestas a las siguientes preguntas, son una guía para los diseñadores,
para determinar las decisiones de diseño más importantes, asociadas a esta clase:
a. Cuales son las unidades de información que serán intercambiadas entre la
aplicación y el usuario?
Un “token semántico” es la menor unidad de información intercambiable entre el
usuario y la aplicación con un significado formalmente definido. Consiste de uno
o más tokens léxicos13, que en conjunto proveen el significado, a tal punto de no
poder ser dividido en tokens léxicos significativos capaz de ser interpretados por
la aplicación o el usuario individualmente. Un “token léxico” es un keystroke14,

13
Un Token Léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje
de programación. Pueden ser palabras clave (tales como if, while, int), identificadores, números,
signos, o un operador de varios caracteres (tal como :=) [24].
14
Un Keytroke representa el ingreso de un carácter presionando una tecla del teclado o dispositivo de
entrada equivalente, también el ingreso de un carácter específico de Java o de un modificador (alt,
3.1 Framework de diseño de LARSON 21

un movimiento del mouse, un click ingresado por el usuario sobre un carácter o

ícono, un sonido presentado al usuario. El tamaño de un token semántico es la
cantidad de información contenida en cada token. En esta clase de decisión, el
diseñador del diálogo determina el contenido y tamaño de cada token semántico
obtenido desde y presentado al usuario, así como también el contenido y tamaño
de cada token semántico obtenido y entregado a la aplicación Web.
b. Cómo serán estructuradas en mensajes de intercambio las unidades de
información definidas?
Un script especifica el contenido de mensajes transmitidos entre la aplicación y el
usuario. Cada mensaje debe contener al menos un token semántico.
c. Cuál es la secuencia de intercambio apropiada entre el usuario y aplicación? El
diseñador de diálogo determina si es necesario especificar una secuencia y en
caso afirmativo, cual seria. Algunas aplicaciones requieren que los tokens
semánticos sean ingresados o mostrados en una secuencia específica. Otras
consumen varios tokens semánticos al mismo tiempo, pudiendo ser ingresados de
manera arbitraria por el usuario.
Los estilos de diálogo difieren no solo en la apariencia, sino también en la secuencia y el
tiempo en que la información es intercambiada entre el usuario y la aplicación. Los
siguientes son algunos ejemplos de estilos utilizados frecuentemente en el diseño de
aplicaciones Web:
• Menús y Formularios: Un Menú es un conjunto de opciones visualizadas en
la pantalla, posibles de seleccionar. La selección de una o más de ellas
supone la ejecución de una orden subyacente, la que normalmente produce un
cambio en el estado de la interfaz. En las figuras 3.1 y 3.2 se muestran dos
ejemplos de tipo de Menú, Horizontal y Vertical – Desplegable
respectivamente.
La Figura 3.3 muestra un ejemplo de Formulario; un Formulario es una
sección de un documento que contiene contenido normal, código, elementos
especiales llamados controles (casillas de verificación (checkboxes),
radiobotones (radio buttons), menúes, etc.), y rótulos (labels) en esos
controles. Los usuarios normalmente "completan" un formulario modificando
sus controles (introduciendo texto, seleccionando objetos de un menú, etc.),
antes de enviar el formulario a un agente para que lo procese (por ejemplo, a
un servidor Web, a un servidor de correo, etc.).

FIGURA 3.1: Ejemplo Menú Horizontal FIGURA 3.2: Ejemplo Menú Vertical y Desplegable

shift, control) o combinación de ellos. Los Keystrokes son usados para definir acciones que
desencadenan eventos de alto nivel o alguna funcionalidad específica [26].
22 Capítulo 3 - Un Framework para el Diseño de Interfaz de Usuario

FIGURA 3.3: Ejemplo de Formulario.

• Lenguaje Natural: El Lenguaje Natural es el lenguaje oral y escrito utilizado

por la mayoría de los humanos para comunicarse entre sí. El diálogo se
restringe a un pequeño conjunto de sentencias en Lenguaje Natural. La Figura
3.4 muestra un fragmento de interfaz de Lenguaje Natural, en el que el
usuario ingresa un pedido y la aplicación responde.

>Liste todos los empleados que cumplieron con sus objetivos este mes
Salcedo Oscar
Ferrero Andrea
Garcia Roberto
>Compare los porcentajes con los empleados que no alcanzaron sus objetivos
Ferreira Olga 20%
Perez Victor 60%

FIGURA 3.4: Ejemplo de Interfaz de Lenguaje Natural.

• Manipulación Directa: Los entornos de Manipulación Directa persiguen la

intención de permitir al usuario manipular directamente los objetos que se le
presentan mediante acciones que corresponden (al menos vagamente) al
mundo físico. Crean una representación visual del mundo, visualizando
objetos (metáforas) y ejecutando acciones de interés. La Figura 3.5 presenta
un ejemplo de interfaz de Manipulación Directa muy común en la actualidad.

FIGURA 3.5: Ejemplos de interfaz de Manipulación Directa.

3.1 Framework de diseño de LARSON 23

• Interacción Asistida: La Interacción Asistida utiliza la metáfora del asistente

15
personal o agente que colabora con el usuario en el mismo ambiente de
trabajo, quien, en vez de dirigir la interacción, trabaja en un entorno
cooperativo en el que el y los asistentes se comunican, controlan eventos y
realizan tareas. La Figura 3.6 muestra dos ejemplos de interfaces con
Interacción Asistida.

FIGURA 3.6: Ejemplos de Asistentes de Interacción.

4.- Presentación: En esta clase el diseñador de diálogo selecciona los objetos de interacción
que componen la interfaz de usuario. Informalmente, se llaman objetos de interacción a
los objetos visible sobre la pantalla o cualquier otro dispositivo de salida, a través del cual
el usuario ingresa u obtiene los “tokens léxicos”. Ejemplos de objetos de interacción son
los controles mencionados en la Sección Menús y Formularios y ejemplificados en la
Figura 3.7. Los objetos de interacción representan para el usuario los tokens semánticos,
así como también son los objetos de interacción los que obtienen información semántica
desde el usuario, quien ingresa tokens léxicos en forma de keystokes, movimientos de
mouse, etc.
En esta clase de decisión, generalmente el diseñador de diálogo trabaja junto al artista
gráfico o diseñador gráfico a tomar las siguientes decisiones:
- La representación visual de los objetos de interacción: tamaño, figura, bordes,
color, textura, composición, estructuración y tipo de fuente, entre otras.
- La disposición de los objetos de interacción visibles respecto de otros objetos de
interacción.

Radio botones (radio buttons) Combo con lista de valores (comboBox)

Casillas de verificación (checkboxes) Cuadros de texto (textboxes)

FIGURA 3.7: Ejemplos de Objetos de Interacción.

15
Los Asistentes son entidades computacionales que asisten al usuario en el uso de las aplicaciones
existentes. Exponen de una manera fácil que es el que se ha de hacer y pueden entender palabras
escritas o habladas o acciones gráficas e interpretarlas. Interpretar quiere decir que el asistente puede
hacer acciones complejas u ordenes cortas.
24 Capítulo 3 - Un Framework para el Diseño de Interfaz de Usuario

5.- Pragmática: Las decisiones tomadas en esta clase abarcan todas las decisiones hardware
dependiente, es decir, todos los aspectos relacionados a gestión de espacio y dispositivos
de hardware que serán usados por el usuario para ingresar la información (valores y
comandos), y por la aplicación para devolver los resultados. Algunas de las decisiones de
esta clase son determinadas por los técnicos de hardware en conjunto con los
especialistas ergonómicos.
Capítulo 4
Model View Controller: Un Patrón que
Prioriza la Interacción
En este Capítulo presentamos el patrón de diseño Model View Controller (MVC) [5] con el
objetivo de comprender su relación arquitectural con el framework de clases de decisiones de
diseño de interfaz propuesto por Larson (Capítulo 3) y su amplia utilización por parte de los
desarrolladores, como guía en el diseño de arquitecturas de aplicaciones Web.
Este Capítulo se organiza de la siguiente manera: en la Sección 4.1 se presenta una breve
introducción a los patrones de diseño; en la Sección 4.2 se desarrolla específicamente el
patrón MVC detallando su arquitectura y los beneficios de su aplicación en la Sección 4.2.1 y
4.2.2 respectivamente. Finalmente, en la Sección 4.3 se establece su relación con el
framework propuesto por Larson [17].

4.1 Introducción a Patrones de Diseño

Los Patrones de Diseño de Software Orientados a Objetos tienen su origen en el campo de la
Arquitectura y por los trabajos de investigación y publicaciones del arquitecto Christopher
Alexander que a finales de los años 70 incorporó el concepto de Patrón Arquitectónico.
Alexander intentó resolver problemas en el campo de la arquitectura, extrayendo la parte
común a buenos diseños, con el objetivo de reutilizarla en otros diseños.
En “The Timeless Way of Building” [35] (obra de referencia donde se plantea por primera vez
la teoría de patrones aplicada a la Arquitectura Civil y Urbanismo), se define al patrón como:
“una regla de 3 partes, que expresa una relación entre un contexto, un problema y una
solución”. Si bien la teoría original de patrones aplica a la construcción de viviendas y
planeamiento urbanístico, el mismo concepto se llevó al diseño del software. Los Patrones de
Software facilitan la reutilización del diseño y de la arquitectura, capturando las estructuras
estáticas y dinámicas de colaboración de soluciones exitosas a problemas que surgen al
construir aplicaciones. Los Patrones de Diseño son pues una disciplina de problema-solución
que está en constate evolución entre los diseñadores y desarrolladores que trabajan con
lenguajes Orientados a Objetos.
En 1987, Ward Cunningham y Kent Beck diseñaron interfaces de usuario con el lenguaje de
programación Smaltalk y se basaron en los trabajos de Christopher Alexander, publicando
“Using Pattern Languages for Object-Oriented Programs”. Pero no fue hasta el año 1994
cuando Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, más conocidos como
the Gang of Four (GoF), publicaron el bestseller “Diseño de Patrones: Elementos de
Reutilización de Software Orientado a Objetos” [11], que los Patrones de Diseño se
convierten en “imprescindibles” para todos los diseñadores y desarrolladores de software
Orientado a Objetos. Gamma [11] define a los Patrones de Diseño como descripciones de
objetos y clases relacionadas que se personalizan para resolver un problema de diseño general
en un contexto particular. Por su parte Alexander cita en [11] “Cada patrón describe un
problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la
solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de
veces sin hacerlo ni siquiera dos veces de la misma forma.”
26 Capítulo 4 - Model View Controller: Un Patrón que Prioriza la Interacción

De las definiciones anteriores podemos resumir a un Patrón de Diseño como la descripción de

una estructura recurrente de componentes que se comunican para resolver un problema
general de diseño en un contexto particular. Cada patrón aborda un problema específico y
recurrente en el diseño o implementación de un sistema de software. Nomina, abstrae e
identifica los aspectos clave de una estructura de diseño común, lo que los hace útiles para: (i)
crear un diseño orientado a objetos reutilizable, (ii) acortar los esfuerzos de diseño, desarrollo
y mantenimiento y (iii) alcanzar atributos de calidad deseables. Identifica las clases e
instancias participantes, sus roles y colaboraciones y la distribución de responsabilidades.
Ayuda a construir sobre la experiencia colectiva de ingenieros de software experimentados,
capturando la experiencia existente y promoviendo las buenas prácticas de diseño.

4.2 Patrón de Diseño Model View Controller

El patrón de diseño Model View Controller (MVC) [5], será usado como referente en el
presente trabajo, por su amplia utilización como guía en el diseño de arquitecturas de
aplicaciones que ofrecen una fuerte interacción con los usuarios. MVC surge de la
publicación realizada en 1987 por Ward Cunningham y Kent Beck y fue usado por primera
vez en el lenguaje de programación Orientado a Objetos Smalltalk. Este patrón representa las
soluciones arquitecturales al problema de separar aspectos del código de la aplicación de los
aspectos de la interfaz de usuario, permitiendo a los diseñadores de las mismas incorporar
características deseables de la interfaz, desde una etapa temprana del diseño.
Es importante destacar que si bien en la actualidad existe gran cantidad de guías y estándares
para diseñar aplicaciones Web con interfaces de usuario accesibles, generalmente no es fácil
aplicarlas en virtud de que no se precisa el escenario bajo el cual puedan aplicarse o no se
conocen las consecuencias de su uso. En contraposición con la ventaja que presentan los
patrones de diseño de resolver el problema una vez, y canonizando el diseño, ayudar
considerablemente a los desarrolladores a lograr que la aplicación cumpla con las aptitudes de
Accesibilidad deseadas.

4.2.1 Arquitectura Model View Controller

Como fue mencionado en la Sección 4.2, MVC [5] es uno de los patrones de diseño mas
extendidos para el desarrollo de aplicaciones en las cuales se deben manejar interfaces de
usuarios. Ha sido portado a una gran cantidad de entornos y frameworks entre los que se
encuentran WinForms, ASP, .Net, etc. Las herramientas de programación visual como Visual
Basic, Visual Studio, .Net, etc., han aplicado también alguna variante del esquema del patrón
MVC. Desde la perspectiva de diseño de una aplicación Web, MVC separa: (i) los datos de la
aplicación, (ii) la interfaz de usuario, y (iii) la lógica de control, respectivamente en los
siguientes tres componentes:
1.- Modelo (Model): representa específicamente el dominio de la información sobre la cual
funciona la aplicación, es decir encapsula las funcionalidades y datos. El Modelo es
independiente de cualquier representación de salida y/o comportamiento de entrada.
2.- Vista (View): presenta al usuario el Modelo en un formato adecuado para interactuar,
normalmente un elemento de interfaz de usuario en una pantalla de un dispositivo de
salida.
3.- Controlador (Controller): responde a eventos, generalmente acciones del usuario, e
invoca cambios en el Modelo y probablemente en la Vista.
En la Figura 4.1, se puede apreciar que la principal característica del patrón MVC es aislar la
Vista del Modelo, separando las responsabilidades. El Modelo, representa únicamente el
estado y lógica de la aplicación y no tiene relación en como el estado es presentado al usuario
4.2 Patrón de Diseño Model View Controller 27

o como la información e instrucciones ingresada por el usuario son recibidas. La Vista, en

cambio, tiene como única responsabilidad la creación de la interfaz de usuario, en respuesta a
las actualizaciones genéricas recibidas desde el Modelo. La Vista no tiene relación con la
lógica de la aplicación o el procesamiento de las entradas ingresadas por el usuario y sólo
debe asegurarse que la interfaz refleje el estado actual del Modelo. Finalmente el componente
Controlador se ocupa únicamente de “escuchar” las notificaciones desde la Vista, basadas en
las entradas del usuario y reenviarlas en forma de cambios al Modelo. En este esquema las
vistas y los controladores conforman la interfaz de usuario. El Modelo debe proveer
mecanismos para que las vistas, por sí solas, puedan registrarse y desregistrarse, así como
también para administrar las vistas registradas. Tan pronto como el Modelo determine que su
estado ha cambiado significativamente, debe notificar a las vistas registradas. Un mecanismo
de propagación de cambios asegura la consistencia entre la interfaz y el Modelo. La
separación del Modelo de los componentes Vista y Controlador permite tener múltiples
representaciones de vistas para un mismo Modelo. Si el usuario cambia el Modelo a través del
Controlador de una Vista, todas las otras vistas dependientes deben reflejar los cambios. Por
lo tanto, el Modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas
recuperan los nuevos datos del Modelo y actualizan la información que muestran al usuario.

FIGURA 4.1: Diagrama de clases de MVC [5].

En algunos casos el Controlador podría también darle instrucciones a la Vista para que realice
cambios en la interfaz de usuario, a través de la invocación de métodos sobre esta. Los
cambios son enviados directamente a la Vista cuando corresponden puramente a “aspectos
gráficos o cosmética” y no tienen efecto sobre el Modelo. Asimismo, las vistas no
necesariamente tienen que representar el Modelo en su totalidad, es decir no necesitan
representar la misma información, podrían simplemente abarcar aspectos diferentes del
Modelo.
La Figura 4.2 muestra el “ciclo de comunicación” de un caso simple del patrón MVC, con un
solo Modelo, una sola Vista y un solo Controlador. Sin embargo, el común de los casos es
que existan 2 o más vistas para un mismo Modelo. En la Figura 6.1 ( Capítulo 6), se puede
observar como para el mismo Modelo se han creado múltiples vistas. Para las
implementaciones que contengan múltiples vistas por Modelo, cada Vista deberá tener
exactamente una instancia de Controlador y viceversa, cada Controlador estará dedicado a
prestar servicio a una única Vista, formando ambos un par indivisible.
28 Capítulo 4 - Model View Controller: Un Patrón que Prioriza la Interacción

Modelo

Datos y
Actualizaciones Lógica Modificaciones

Modificaciones
Vista Controlador

Interfaz Inputs

Envía eventos de entrada

FIGURA 4.2: Ciclo de comunicación MVC.

4.2.2 Beneficios al aplicar MVC

La división de responsabilidades que propone del patrón MVC entre sus tres componentes:
Modelo, Vista y Controlador otorga los beneficios que enumeramos a continuación:
• Promueve el Reuso.
• Provee bajo Acoplamiento:
o Desacopla las vistas del Modelo
o Desacopla el Modelo de la forma en que se muestran e ingresan los datos
• Provee mayor Cohesión:
o Cada componente del patrón esta altamente especializado en su tarea (la Vista
en mostrar los datos al usuario, el Controlador en las entradas y el Modelo en
su objetivo de negocio)
• Provee mayor Flexibilidad y Agilidad:
o Se pueden crear múltiples representaciones de vistas para un mismo Modelo.
o Permitir diseñar interfaces de usuario fáciles de adicionar, actualizar o eliminar
en tiempo de compilación y ejecución.
o Permitir anidamientos de vistas.
o Permitir a múltiples desarrolladores actualizar simultáneamente la interfaz,
lógica y entradas de una aplicación sin afectarse unos con otros.
o Ayudar a los desarrolladores a enfocarse en un solo aspecto de la aplicación por
vez.
o Permitir cambiar fácilmente las respuestas a las entradas del usuario en tiempo
de compilación y ejecución.
o Permitir sincronizar las vistas.
• Provee facilidad para el desarrollo de clientes “ricos” en múltiples dispositivos y
canales:
o Una Vista para cada dispositivo que puede varias según sus capacidades
o Una Vista para la Web y otra para aplicaciones de escritorio
• Provee Fácil Mantenimiento.
• Provee Mayor Escalabilidad.
4.3 Una Arquitectura para Diseñar con Clases de Decisión 29

4.3 Una Arquitectura para Diseñar con Clases de

Decisión
Es importante en este punto, describir al patrón MVC [5] desde una visión arquitectónica y
en relación al framework de clases de decisiones de diseño de interfaz propuesto por Larson
[17]. La razón en la que se basa esta asociación es lograr un framework arquitectónico sólido
donde discutir eficientemente el diseño de interfaces de usuarios “accesibles”. Ya señalamos
en la Sección 3.2 (Capítulo 3) cuales son las ventajas que aporta el enfoque de Larson a este
propósito. MVC por su parte provee un paradigma arquitectónico, cuya filosofía conceptual
es totalmente aplicable a las plataformas de desarrollo y entornos inter-organizacionales
actuales. Así, el objetivo buscado en esta asociación entre MVC y las clases de decisión de
diseño de Larson es especificar: (i) la estructura fundamental de la interfaz de usuario de una
aplicación Web; (ii) el conjunto de componentes predefinidos; y (iii) las responsabilidades,
reglas y guías para organizar las relaciones entre estos componentes. Entonces, revisando la
arquitectura de alto nivel del MVC podemos asociar las responsabilidades de sus tres
componentes principales a las clases del framework de Larson de la siguiente manera:
1.- Modelo (Model): contiene los algoritmos computacionales necesarios para dar soporte a
las clases de decisión Estructural y Funcional.
2.- Vista (View): contiene los algoritmos y heurísticas relacionadas a los aspectos de
visualización de información de la clase de decisión Presentación (outputs).
3.- Controlador (Controller): contiene los algoritmos y heurísticas relacionadas al ingreso de
información (instrucciones y datos) por parte del usuario, en relación a las decisiones
correspondientes a la clase de Presentación y todos los aspectos vinculados a la clase de
Diálogo (inputs).
Como se puede observar, la clase de decisión de diseño Presentación se divide en dos
subclases: Vista de la Presentación que abarca los aspectos relacionados a la visualización de
la información y Control de la Presentación que abarca los aspectos del ingreso de la
información. Esta última subclase se combina con la clase de decisión de diseño Diálogo para
formar el componente Controlador.
Capítulo 5
Arquitectura de Software para Aplicaciones
Web Accesibles
En este Capítulo se forja el objetivo y corazón de esta tesis, dado que en él, proponemos un
enfoque que le sirva a los desarrolladores Web como herramienta para evaluar, diseñar e
implementar la Accesibilidad de aplicaciones Web desde la perspectiva de los principios
arquitectónicos para el diseño de interfaces de usuario “accesibles”. Básicamente la actividad
concentra sus esfuerzos en “mapear” cada una de las pautas correspondientes a la WCAG 1.0
[34] a las clases de decisión de diseño propuestas por el framework de Larson [17] y a los
componentes del patrón MCV [5], con el objeto de contribuir desde las primeras etapas del
ciclo de vida al desarrollo de aplicaciones Web con interfaces de usuario más “accesibles”.
Este Capítulo se organiza de la siguiente manera: en la Sección 5.1 se introduce nuestra
propuesta; en la Sección 5.1.1 se detalla la metodología utilizada para desarrollar el Mapeo y
la forma en que ha sido estructurado o presentado el mismo. Finalmente en la Sección 5.1.1.1
se desarrolla el Mapeo propiamente dicho.

5.1 Herramienta para asistir al diseño, desarrollo e

implementación de arquitecturas de software accesibles
Como mencionamos en la Sección 2.3, la Accesibilidad Web se refiere a cómo se debe
codificar y presentar la información cuando se diseña un sitio Web para que las personas con
capacidades diferentes puedan percibir, entender, navegar e interactuar de forma efectiva con
la Web, creando y aportando contenido. Nuestro trabajo se encuadra dentro del área temática
Accesibilidad Web. Debido a que es a nivel de interfaz de usuario donde finalmente se
manifiestan las barreras de Accesibilidad, proponemos un enfoque para asistir a los
desarrolladores en tareas de diseño, desarrollo, implementación y evaluación de la
Accesibilidad en aplicaciones Web desde la perspectiva de los principios arquitectónicos del
diseño de interfaces de usuario. Particularmente nos centramos en presentar un Mapeo de las
pautas propuestas por la WCAG 1.0 [34] a las clases de decisión de diseño propuestas por
Larson en [17] y a los componentes del patrón arquitectónico más ampliamente utilizado en el
diseño de interfaces de aplicaciones Web: Model View Controller (MVC) [5]. De esta manera
nuestro enfoque es de gran aporte a los efectos proveer soluciones arquitecturales a los
problemas de Accesibilidad, mejorando el desarrollo de aplicaciones Web con interfaces de
usuario más “accesibles”.
Para desarrollar este Mapeo, consideramos las 14 pautas de las WCAG 1.0 [34], las clases de
decisión de diseño Diálogo, Presentación y Pragmática de Larson [17] y los tres componentes
del patrón MVC [5]: Modelo, Vista y Controlador. Cabe señalar que sólo se consideran para
el Mapeo las clases Diálogo, Presentación y Pragmática del framework, porque son las que se
relacionan directamente con la interacción usuario-sistema donde se manifiestan las barreras
de Accesibilidad. Las clases de decisión de diseño Estructural y Funcional se corresponden
con las decisiones de diseño asociadas a la representación específica del dominio de la
información sobre la cual funciona la aplicación Web, es decir encapsulan su lógica
(funcionalidades y datos).
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 31

5.1.1 Arquitectura con Clases de Decisión Accesibles

Cada una de las pautas de la WCAG 1.0 [34] se focaliza en un objetivo de Accesibilidad y se
compone de un conjunto de puntos de verificación. Cada punto de verificación tiene a su vez
su propio objetivo de Accesibilidad destinado a consolidar el objetivo de Accesibilidad de la
pauta a la que pertenece. Dada una página Web, asegurar la conformidad para un determinado
punto de verificación significa evitar la presencia de barreras de Accesibilidad para
determinados usuarios Web. El grado del aporte a la Accesibilidad de la página Web que
proporciona la conformidad de un determinado punto de verificación, se refleja en el nivel de
prioridad que tiene asignado. Estos conceptos que fundamentan la filosofía de las guías de la
WCAG 1.0 [34], se utilizaron para trabajar individualmente sobre cada una da las pautas a
través de sus respectivos puntos de verificación.
Ahora bien, preservar intacta esta filosofía de la WCAG 1.0 [34] es un requerimiento que
establecimos como prioritario al Mapeo sobre las clases de decisión de diseño de Larson y
componentes del patrón MVC. Es fundamental a nuestro enfoque que un punto de
verificación “mapeado” a su clase de decisión y componente arquitectural siga reflejando su
objetivo de Accesibilidad y nivel de prioridad. La preservación de esta información inherente
a cada punto de verificación permitirá a los diseñadores conocer la relevancia y determinar las
consecuencias (desde el punto de vista de la Accesibilidad) de tomar un conjunto de
decisiones de diseño al desarrollo de una interfaz de usuario con determinado nivel de
conformidad. A continuación explicamos las secciones en las que se organiza el trabajo
realizado sobre cada una de las 14 pautas de la WCAG 1.0 [34] a los efectos de preservar en
forma clara los contenidos inherentes a la filosofía de WCAG 1.0, esenciales a nuestro
enfoque. Para guiar el proceso de Mapeo, dividimos cada pauta en el siguiente conjunto de
entradas:
• [Nro de Pauta] – [Enunciado de la pauta u objetivo de Accesibilidad]
• Por cada punto de verificación asociado a la pauta:
Punto de Verificación: [Nro de punto de verificación] – [Enunciado del punto de
verificación u objetivo de Accesibilidad] – [Prioridad del punto de verificación]
Prescripción Mapeo

Ejemplo:
- Prescripción: explicación del punto de verificación y fundamentos que lo
sustentan.
- Ejemplo: provee tópicos de cómo implementar el punto de verificación utilizando
ejemplos bien formados en HTML.
- Mapeo: indica la clase de decisión de Larson y a través de ella el componente
MVC a la que se corresponde al punto de verificación.
- Convenciones de la Pauta: Cuando una palabra del [Enunciado de la pauta u
objetivo de Accesibilidad] o de la Prescripción, aparece subrayada y en letra
cursiva, hace referencia a una definición preliminar recogida en el Glosario
(Apéndice A, página 99).
Tal como podemos observar cada pauta pretende ser lo suficientemente autocontenida, como
para que cualquier diseñador pueda tener presentes cuáles son los principios que subyacen al
diseño de interfaces de usuario “accesibles” y cómo se vinculan estos con las clases de
decisiones de diseño y el componente MVC [5] respectivo para sustentar dicha
Accesibilidad.
32 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

Remitiéndonos específicamente al proceso de Mapeo, para determinar la existencia de una

correspondencia entre un punto de verificación de la WCAG 1.0 [34] y una clase de decisión
de diseño de Larson [17] ligada a un componente MVC [5], fijamos y detallamos los
siguientes criterios:
• El conjunto de decisiones que se toman para implementar cada punto de verificación
es lo suficientemente significativo para producir un efecto sobre el diseño de la
interfaz de usuario y justificar su correspondencia con alguna clase de decisión diseño
ligada a un componente MVC.
• Todos los puntos de verificación deben tener una correlación con alguna clase de
decisión de diseño y a través de esta con un componente MVC.
• Para establece una correspondencia de un punto de verificación con la clase de
decisión de diseño Diálogo y a través de esta con el componente MVC Controlador,
la implementación de dicho punto de verificación determina: (i) las unidades
semánticas de información que serán intercambiadas en la interacción usuario-
aplicación, (ii) la estructura de estas unidades en mensajes para su intercambio, y (iii)
la secuencia y el tiempo en que el usuario es forzado a intercambiar estas unidades
con la aplicación. A los efectos de aclarar este ítem cabe señalar que las aplicaciones
pueden requerir que las unidades de información sean ingresadas en una secuencia
específica, consumidas varias al mismo tiempo o ingresadas por el usuario en una
secuencia arbitraria. Es decir que estas decisiones apuntan a determinar si la
secuencia de intercambio de información es necesaria y si lo es, cuál es dicha
secuencia.
• Para establecer una correspondencia de un punto de verificación con la clase de
decisión de diseño Presentación y a través de sus subclases vista de Presentación y
control de Presentación con los componentes MVC Vista y Controlador
respectivamente, la implementación de dicho punto de verificación determina
aspectos puramente gráficos o de cosmética de apariencia “look-and-feel” de la
interfaz de usuario. Es decir que la implementación determina la selección de los
objetos de interacción u objetos visibles sobre la pantalla o cualquier otro dispositivo
de salida que componen la interfaz de usuario e interpretan la información semántica
provista por la aplicación y el usuario Web. Estas decisiones están relacionadas
directamente con la representación visual de los objetos de presentación y su
disposición respecto de otros objetos sobre el mismo dispositivo.
• Para establecer una correspondencia de un punto de verificación con la clase de
decisión de diseño Pragmática, la implementación de dicho punto de verificación
implica decisiones hardware dependiente, es decir aspectos relacionados a la gestión
de espacio y dispositivos de hardware que serán usados por el usuario para ingresar
la información y por la aplicación para devolver los resultados.
En el marco de nuestro enfoque, el grado de Accesibilidad alcanzado por una interfaz de
usuario estará determinado por el nivel de conformidad que reflejen las decisiones de diseño
tomadas dentro del framework clases de Larson-componentes MVC. A continuación, en la
Sección 5.1.1.1 damos paso al Mapeo propiamente dicho.

5.1.1.1 Mapeo de Pautas WCAG 1.0 a las Clases de Decisión de Diseño

Propuestas por Larson y a los Componentes del Patrón MCV
PAUTA 1 - PROPORCIONE ALTERNATIVAS EQUIVALENTES PARA EL CONTENIDO
VISUAL Y AUDITIVO
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 33

Punto de Verificación: 1.1 Proporcione un texto equivalente para todo elemento no

textual (por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto
incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones
(por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", frames,
scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos,
sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos,
banda sonora del vídeo y vídeos. [Prioridad 1]
Prescripción Mapeo
Proporcionar texto equivalente para gráficos e información auditiva, Clase de Presentación -
dado que un contenido textual puede ser presentado al usuario a través Componente Vista:
de un sintetizador de voz, dispositivo braille o texto desplegado A los objetos de
visualmente. Los textos equivalentes deben ser escritos de manera que interacción existentes en la
transmitan todo lo esencial del contenido. Ver puntos de verificación presentación, se sumaran
6.3, 6.5. los nuevos elementos que
representaran los textos
equivalentes.
Ejemplo: proporcionar texto equivalente a través de atributos asociados a los elementos de
presentación. En HTML [30] a través del atributo "alt" para los elementos IMG, INPUT y APPLET,
“content” para los elementos OBJECT y APPLET o si se requiere contenido complejo "longdesc"
para los elementos IMG o FRAME.
<IMG src="lupa.jpg" width="50" heigth="100" alt="Botón para
acceder a la búsqueda">
<IMG src="navbarra.jpg" width="500" heigth="80" alt="Barra de
Navegación" longdesc="navbarra_desc.html">
Ver más ejemplos en puntos de verificación 1.3 y 1.5.
Punto de Verificación: 1.2 Proporcione vínculos redundantes en formato texto para cada
zona activa de un mapa de imagen del servidor. [Prioridad 1]
Prescripción Mapeo
Los mapas de imágenes procesados en el servidor se basan en la Clases de Presentación y
utilización de un archivo alojado en el servidor que define las Diálogo - Componentes
diferentes coordenadas de las zonas sensitivas o activas de la imagen. Vista y Controlador:
El procesamiento de este tipo de mapas se realiza a través del script A los objetos de
alojado en el servidor. Proporcionar la misma funcionalidad o interacción existentes en la
información de cada zona del mapa de imagen en una forma presentación, se sumaran
alternativa, “accesible”, facilitando un vínculo redundante de texto para los nuevos elementos de
cada una de las zonas activas, con el objetivo de posibilitar el acceso a presentación asociados a
cada vínculo mediante el teclado. los vínculos redundantes
textuales de cada zona
activa de la imagen. Se
podrá implementar un
Controlador por cada
Vista alternativa asociada
a la lista de vínculos.
Ejemplo: posibles técnicas para proporcionar una lista alternativa de las opciones del mapa son:
• Proporcionar la lista alternativa de vínculos después de la imagen, e indicar la existencia y
ubicación de esta usando por ejemplo, con el atributo "alt":
<A href ="http://www.mibuscador.com/cgi-bin/mapa1.map">
<IMG src="mapa1.gif" alt="Pulse en los círculos para
acceder a las diferentes secciones. (Vínculos textuales más
abajo)" >
</A>
<P>
[<A href="buscador.html">Buscador</A>]
34 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

[<A href="manualUsuario.html">Manual de Usuario del

Buscador</A>]
</P>
• Utilizando el elemento OBJECT: incluir vínculos alternativos en el cuerpo de este
elemento. (Ver Punto de Verificación 1.5).
• Crear una página alternativa que sea “accesible”.

Punto de Verificación: 1.3 Hasta que las aplicaciones de usuario puedan leer
automáticamente el texto equivalente de la banda visual, proporcione una descripción
auditiva de la información importante de la banda visual de una presentación multimedia.
[Prioridad 1]
Prescripción Mapeo
Las descripciones sonoras de la banda visual proporcionan una Clases de Presentación,
narración de los elementos visuales claves sin interferir con el sonido o Diálogo y Pragmática -
el diálogo de una película. Los elementos visuales claves incluyen Componentes Vista y
acciones, escenarios, lenguaje corporal, gráficos y el texto mostrado. Controlador:
A la interfaz de usuario de
la aplicación Web se
incorporará un nuevo
objeto de presentación,
asociado a la descripción
auditiva. Dependiendo de
las preferencias del
usuario, este nuevo
elemento interactuara con
el, modificando la
secuencia de diálogo. De
nada servirá mejorar la
Accesibilidad de la
aplicación incorporando
la descripción auditiva, si
la PC sobre la cual corre
la misma no cuenta con
los dispositivos de
hardware multimedia
necesarios, como por
ejemplo tarjeta de sonido.
Ejemplo: se puede proporcionar una presentación Flash que lea por si mismo el contenido,
eliminando la necesidad de lectores de pantalla. Se estará presentando en forma auditiva, cualquier
contenido que se presente visualmente en la presentación Flash. En HTML [30] incluir el archivo
.swf dentro del elemento OBJECT.
<OBJECT width="250" height="100">
<PARAM NAME="movie" VALUE="pelicula.swf">
<EMBED SRC="peliucla.swf" width="250" height="100">
</EMBED>
</OBJECT>
Si un usuario de lector de pantalla encuentra una presentación Flash que usa sonido, puede resultarle
difícil escuchar simultáneamente el lector y el sonido del Flash. En la mayoría de casos, se debería
proporcionar una opción para que los usuarios conecten el sonido cuando acceden por primera vez a
un sitio o darles instrucciones antes de acceder a la presentación sobre cómo desactivar el sonido
(quizás a través de un atajo de teclado). Si el sonido tiene que funcionar la primera vez que se
descarga la presentación, se tendrá que proporcionar una opción para apagar el sonido como primer
elemento de navegación en la presentación Flash.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 35

Punto de Verificación: 1.4 Para toda presentación multimedia tempo dependiente (por
ejemplo, una película o animación) sincronice alternativas equivalentes (por ejemplo,
subtítulos o descripciones de la banda de visual) con la presentación. [Prioridad 1]
Prescripción Mapeo
Las presentaciones sonoras deben ir acompañadas por transcripciones Clases de Presentación,
de texto, es decir equivalentes textuales de los eventos sonoros. Diálogo y Pragmática -
Cuando estas transcripciones se presentan de forma sincronizada con la Componentes Vista y
presentación visual, se denominan subtítulos y son utilizados por las Controlador:
personas que no pueden escuchar la banda sonora del material Los subtítulos o
audiovisual. Algunas tecnologías también permiten al usuario elegir descripciones sonoras
diferentes tipos de subtítulos para adecuarlos a sus capacidades serán los elementos que se
lectoras. adicionarán a la
presentación.
Sincronizarlos, como
también permitirle al
usuario decidir
visualizarlos, o
seleccionar el tipo de
subtítulo cambia la
secuencia original de
intercambio de tokens
semánticos entre este y la
aplicación Web. Ver
punto de verificación 1.3.
Ejemplo: debido a la naturaleza interactiva de Flash, los subtítulos pueden activarse o desactivarse
y pueden programarse para que se ejecuten de diversas formas.
Tanto Media Access Generator (MAGpie) de WGBH's National Center for Accessible Multimedia
como Hi-Caption™ SE de HiSoftware, permiten generar subtítulos que pueden incorporarse a la
presentación Flash. Para incorporar archivo swf en HTML ver ejemplo de punto de verificación 1.3.
Punto de Verificación: 1.5 Hasta que las aplicaciones de usuario interpreten el texto
equivalente para los vínculos de los mapas de imagen de cliente, proporcione vínculos en
formato texto redundantes para cada zona activa del mapa de imagen de cliente.
[Prioridad 3]
Prescripción Mapeo
Proporcionar la misma funcionalidad o información de cada zona Clases de Presentación y
activa del mapa de imagen de cliente en una forma alternativa, Diálogo - Componentes
“accesible”, facilitando un vínculo redundante de texto para cada una Vista y Controlador:
de estas zonas. Al Igual que cualquier vínculos, el texto debe tener Ver punto de verificación
sentido cuando se lee fuera de su contexto. 1.2.
Ejemplo: en HTML [30] las zonas o regiones que se pueden definir en una imagen se crean
mediante rectángulos, círculos y polígonos. En un mapa de imagen, la imagen original se inserta
mediante la etiqueta <IMG>. El atributo “usemap” indica que la imagen utiliza un mapa de imagen,
y el nombre del mapa se define en la etiqueta <MAP>. Esta etiqueta define las zonas o regiones de
la imagen. Cada zona es etiquetada con <AREA>, y su atributo “shape” indica el tipo de área y
coordenadas asociadas, cuyo significado depende del tipo de área definido. El enlace de cada área se
referencia mediante el atributo “href”. A través del atributo "alt.", se indica la existencia y
ubicación de los vínculos alternativos.
<IMG src="mapa1.gif" alt="Mapa de imagen de las secciones del
buscador" usemap="#map1">
<MAP name="map1">
<AREA shape="CIRCLE" coords="44,36,29"
href="buscador.html" alt="Pulse para usar el buscador">
<AREA shape="CIRCLE" coords="140,35,31"
href="manualUsuario.html" alt="Pulse para acceder al manual
36 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

de usuario del buscador">

</MAP>
</IMG>
En caso de implementar el mapa con el elemento OBJECT, se puede emplear el elemento A (Ver
Punto de Verificación 10.5) en vez de AREA para describir las regiones activas y proporcionar
vínculos redundantes al mismo tiempo:
<OBJECT data="mapa1.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P> Mapa de imagen de las secciones del buscador
[<A href="buscador.html" shape="CIRCLE"
coords="44,36,29">Pulse para usar el buscador</A>]
[<A href="manualUsuario.html" shape="CIRCLE"
coords="140,35,31">Pulse para acceder al manual de usuario
del buscador</A>]
</P>
</MAP>
</OBJECT>

PAUTA 2: NO SE BASE SÓLO EN EL COLOR

Punto de Verificación: 2.1 Asegúrese que toda la información transmitida a través de los
colores también esté disponible sin color, por ejemplo mediante el contexto o por
marcadores. [Prioridad 1]
Prescripción Mapeo
Asegurarse de que los textos y gráficos sean comprensibles cuando se Clase de Presentación -
vean sin color, implica lograr de que la información no sea transmitida Componente Vista:
sólo a través del color. Si por sí mismo se usa para transmitir Se deberán cambiar los
información, las personas que no puedan diferenciar ciertos colores, y objetos visuales que
los usuarios que no tengan pantallas en color o utilicen dispositivos de aportan significado
salida no visuales, no recibirán la información. semántico a través de su
color modificando los
efectos de los objetos
existentes, o incorporando
nuevos elementos
semánticos que
transfieran la misma
información.
Ejemplo: en HTML [30] implementar que la información este disponible a través de otros efectos
de estilo (por ejemplo un efecto de fuente subrayado, bordes redondeados) y a través del contexto
(por ejemplo, vínculos de texto detallados). Por ejemplo, en vez de escribir el mensaje: “por favor,
seleccione uno de los ítems indicados en verde” se debe escribir algo del estilo “por favor,
seleccione uno de los ítems subrayados”.
<P style = "font-style: italic"> Item en cursiva </P>
<P style = "text-decoration: underline"> Item Subrayado </P>
Punto de Verificación: 2.2 Asegúrese de que las combinaciones de los colores de fondo y
primer plano tengan suficiente contraste para que sean percibidas por personas con
deficiencias de percepción de color o en pantallas en blanco y negro. [Prioridad 2 para
las imágenes. Prioridad 3 para texto].
Prescripción Mapeo
Asegurar una adecuada combinación de las propiedades de estilo de la Clase de Presentación -
página Web (colores, tamaños, efectos visuales (o sonoros), es decir Componente Vista.
"cómo verá la página el usuario" permitirá que las combinaciones de
colores de fondo y primer plano sean percibidas por personas con
deficiencias de percepción de color o pantallas en blanco y negro.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 37

Ejemplo: en CCS [28] utilizar números en vez de palabras para definir los colores, ya que la gama
definida con palabras es muy limitada.
h1 {color: #808000} o h1 {color: rgb(50%,50%,0%)}
en vez de h1 {color: red}

PAUTA 3. UTILICE MARCADORES Y HOJAS DE ESTILO Y HÁGALO APROPIADAMENTE

Punto de Verificación: 3.1. Cuando exista un marcador apropiado, use marcadores en
vez de imágenes para transmitir la información. [Prioridad 2]
Prescripción Mapeo
Reemplazar en el código de la página Web las imágenes que Clase de Presentación -
proporcionan información y complementan la información textual Componente Vista:
(imágenes de contenido) por sus correspondientes marcadores y Reemplazar las imágenes,
elementos estructurales existentes en los lenguajes, cumpliendo lleva al diseñador gráfico
esencialmente con la misma función para el usuario final. Los a modificar la
elementos y atributos estructurales fomentan la coherencia en los presentación de la interfaz
documentos y aumentan la Accesibilidad de los mismos, proveyendo Web, incorporando los
información a otras herramientas (por ejemplo, herramientas de elementos estructurales y
indexación, motores de búsqueda, programas que extraen datos de sus correspondientes
tablas a bases de datos, herramientas de navegación que usan objetos de interacción en
elementos de encabezamiento). caso de ser necesarios.

Ejemplo: las ecuaciones matemáticas complejas definidas en la página Web, podrían ser marcadas
utilizando el lenguaje de marcado de matemática MathML 1.01 [31] o TeX. Luego, el documento
convertido a HTML para su publicación en la Web debe usar una sola descripción de la ecuación,
teniendo posiblemente pequeñas imágenes para partes y trozos de la misma.
La ecuación ax2+bx+c=0, con a>0 podría ser marcada de la siguiente forma:
<MATH>
<MROW>
<MI>a</MI>
<MSUP>
<MI>x</MI>
<MN>2</MN>
</MSUP>
<MO>+</MO>
<MI>bx</MI>
<MO>+</MO>
<MI>c</MI>
<MO>=</MO>
<MN>0</MN>
<MI></MI>
<MO>,</MO>
<MI>con a</MI>
<MO>></MO>
<MN>0</MN>
</MROW>
</MATH>
Punto de Verificación: 3.2 Cree documentos que estén validados por las gramáticas
formales publicadas. [Prioridad 2]
Prescripción Mapeo
Validar un documento Web implica asegurar que un documento escrito Clase de Presentación -
en un determinado lenguaje (por ejemplo HTML [30]) cumple con las Componente Vista:
normas y restricciones de ese lenguaje. El conjunto de normas, Al estar el documento
obligaciones y restricciones que se deben seguir al crear un documento Web validado por una
38 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

de un determinado tipo, se recogen en cada DTD (Document Type gramática formal, los
Definition). El proceso de validación consiste en probar página a desarrolladores han
página si su código (HTML [30]) pasa la prueba de validación. Que el utilizado adecuados
documento sea válido le permitirá al navegador del usuario conocer e marcadores y elementos
interpretar la estructura del documento. estructurales, definidos
para el lenguaje en
particular, como así
también, dependiendo de
los estricto que sea el
DTD, una clara
separación de los aspectos
de marcado de la
estructura y presentación
de la página Web.

Ejemplo: en HTML [30], en la primera línea del texto que figura en el código del archivo, con la
etiqueta DOCTYPE, se indica y valida la estructura del mismo contra algún estándar prefijado.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
En este caso indica que el documento que lo contiene está desarrollado bajo los estándares de
HTML 4.01 [30].
Otra forma de validar un documento es a través de una herramienta de validación. Algunos editores
de páginas Web incluyen sus propios validadores y el W3C ha creado una herramienta de acceso
gratuito para la validación de las páginas.
Si la página no pasa correctamente la prueba de validación, se muestra el listado completo de fallos
junto con la ayuda necesaria para resolver cada uno de los errores.
Punto de Verificación: 3.3 Utilice hojas de estilo para controlar la maquetación y la
presentación. [Prioridad 2]
Prescripción Mapeo
El uso de hojas de estilo permite que los usuarios definan sus propios Clase de Presentación –
estilos y a través de facilidades que ofrecen los navegadores los Componentes Vista y
impongan a los del autor, de esta forma pueden tener control total Controlador:
sobre contraste de colores o tamaños de letras para navegar los sitios La representación visual,
con comodidad, según sus necesidades. la ubicación de los objetos
de interacción (efectos
tipográficos, fuentes,
colores, background,
posición, etc.) dependen
de las reglas de estilo
definidas en el archivo
externo. El usuario será
quien a través de las
facilidades (alguna
acción) que ofrecen las
herramientas de
navegación, tendrá el
control total e impondrá
sus propios estilos, o
activará los definidos por
el autor.
Ejemplo: en HTML [30] a través de la etiqueta <LINK> se pueden enlazar las hojas de estilos
CSS [28] utilizadas por las páginas Web. Esta etiqueta se debe incluir dentro de la cabecera del
documento. Se pueden añadir tantas etiquetas <LINK> como hagan falta, pero siempre dentro de
<HEAD>...</HEAD>.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 39

<HEAD>
<LINK rel="stylesheet" type="text/css" href="/css/comun.css" />
</HEAD>
…
<DIV><H1>Buscador de Páginas Web</H1></div>
En caso de que existan definidos estilos para los mismos elementos en la propia página HTML o
establecidos por lector, el programa de navegación será quien optará por uno u otro estilo.
Punto de Verificación: 3.4 Utilice unidades relativas en lugar de absolutas al especificar
los valores en los atributos de los marcadores de lenguaje y en los valores de las
propiedades de las hojas de estilo. [Prioridad 2]
Prescripción Mapeo
Utilizar unidades de medida relativas en lugar de absolutas en los Clase de Presentación -
valores de los atributos de elementos estructurales de marcado (por componente Vista:
ejemplo FRAMES) así como en valores de propiedades de las hojas de Ante eventos y acciones
estilo permitiría que los elementos de presentación cambien su aspecto realizadas por el usuario,
de un medio a otro fácilmente (por ejemplo, de un monitor a una en el ejemplo, definir el
impresora láser). Las unidades de medida absolutas son útiles font-size para el
solamente cuando las propiedades físicas del medio de salida son encabezado, o
conocidas. dependiendo del medio
físico de salida, la
aplicación presenta
cambios en la Vista.
Ejemplo: en el lenguaje de hoja de estilo en cascada, CSS [28] utilizar las medidas relativas:
• em: la unidad em es igual al valor computado de la propiedad ‘front-size’ del elemento en
el que se usa. Puede usarse para longitudes verticales como horizontales.
• ex: la unidad ex es definida por la propiedad ‘x-height’ de la fuente.
H1 {line-height: 1.2em}: significa que la altura de línea de los elementos H1
será un 20% mayor que el tamaño de fuente de los elementos H1.
H1 {font-size: 1.2em}: significa que la propiedad font-size de los elementos H1
será un 20% mayor que el tamaño de fuente heredado por los elementos H1.
Punto de Verificación: 3.5 Utilice elementos de encabezado para transmitir la estructura
lógica y utilícelos de acuerdo con la especificación. [Prioridad 2]
Prescripción Mapeo
Los documentos largos se suelen dividir en una serie de capítulos, los Clase de Presentación -
capítulos tienen apartados, los apartados se dividen en distintas Componente Vista:
secciones, las secciones en párrafos, etc. Estos trozos semánticos de Los navegadores asignan
información constituyen la estructura del documento. de forma automática el
tamaño del título de cada
Las secciones deberían iniciarse con los elementos de encabezamiento.
sección en función de su
Así, los títulos de sección <H1> se muestran con el tamaño de letra
importancia. Así mismo,
más grande, ya que son el nivel jerárquico superior. La importancia del
como cada elemento de
resto de etiquetas es descendiente mientras que los títulos de sección
encabezado tiene un
<H6> se visualizan con un tamaño de letra muy pequeño, adecuado
significado esta semántica
para el nivel jerárquico de menor importancia.
es transmitida a aquellos
usuarios que busquen
información a través de
buscadores, o que solo
ojeen los encabezamientos
de los documentos.
Ejemplo: en HTML [30] las etiquetas que definen los títulos de sección son <H1>, <H2>, <H3>,
<H4>, <H5> y <H6>.
<HEAD>
40 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

<TITLE>Buscador WEB</TITLE>
<STYLE type="text/css"> /* Sangra el encabezamiento y el
contenido
siguiente */ DIV.section2 { margin-left: 5% }
</STYLE>
</HEAD>
<BODY>
<H1>Página principal buscador Web</H1>
... algún texto aquí ...
<DIV class="sección2">
<H2>Búsqueda simple</H2>
... texto para esta sección ...
</DIV>
<DIV class="sección2">
<H2>Búsqueda avanzada</H2>
... texto para esta sección ...
</DIV>
Punto de Verificación: 3.6 Marque correctamente las listas y los ítems de las listas.
[Prioridad 2]
Prescripción Mapeo
Agrupar determinadas palabras o frases en un conjunto de elementos Clase de Presentación -
que tienen significado de forma conjunta, bajo el marcado de listas componente Vista:
según los elementos provistos por los diferentes leguajes de Marcar las listas
programación. Cualquier usuario, y más aún, los usuarios no visuales correctamente incorporará
pueden sentirse perdidos, especialmente en las listas anidadas y nueva semántica a la
aquellas que no especifican el nivel de anidamiento para cada ítem. Es aplicación, que tendrá
muy importante proporcionar un medio para identificar claramente el mayor impacto en
contexto dentro de una lista, es decir, incluir el marcado de pistas herramientas como
contextuales. La lista "1, 1.1, 1.2, 1.2.1,1.3, 2, 2.1, ..." proporciona más lectores de pantalla, las
contexto que la misma lista sin números compuestos, que sería cuales permitirán
formateada de la siguiente manera: reconocer estos tokens e
1 intercambiarlos con el
usuario.
1
2
1
3
2
Y narrada por los lectores de pantallas como: "1, 1, 2, 1, 3, 2, 1".
Ejemplo: XHTML provee para el marcado de listas los elementos: UL, LI, para encerrar la lista
completa y cada elemento, OL, LI para listas ordenadas y DL, DT y DD para listas de términos y
definiciones.
<BODY>
<H1>Instrucciones</H1>
<OL>
<LI>Ingresar criterio de búsqueda</LI>
<LI>Pulsar el botón Buscar</LI>
<LI>Pulsar el enlace de la página a la que desea acceder</LI>
</OL>
</BODY>
CSS1 [28] y CSS2 [29] permiten a los usuarios controlar los estilos de números (para todos los tipos
de lista, no sólo las ordenadas) mediante las hojas de estilo del usuario. En CSS2 [29] se pueden
especificar los números compuestos para listas anidadas creadas tanto con elementos UL como OL.
Los ítems están numerados como "1", "1.1", "1.1.1", etc.
<STYLE type="text/css">
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 41
UL, OL { counter-reset: item }
LI { display: block }
LI:before {content: counters(item, "."); counter-increment:
item }
</STYLE>
Punto de Verificación: 3.7 Marque las citas. No utilice el marcador de citas para efectos
de formato tales como sangrías. [Prioridad 2]
Prescripción Mapeo
Marcar las citas externas mediante los elementos de marcado provistos Clase de Presentación -
por los lenguajes. No se debe utilizar el marcado de citas para efectos componente Vista: Marcar
de formato tales como sangrías. Los efectos de espaciado deben las citas correctamente
realizarse a través del correcto uso de elementos de marcado y sus incorporará nueva
propiedades. semántica a la aplicación,
que tendrá mayor impacto
en herramientas como
lectores de pantalla, las
cuales permitirán
reconocer estos tokens
semánticos (texto de la
cita y el autor de esta) al
mismo tiempo que
incorporan el efecto visual
de identar el texto que
contienen.
Ejemplo: HTML [30] provee el elemento BLOCKQUOTE para indicar de forma clara que el texto
es una cita externa. Los navegadores muestran por defecto, el texto del elemento
<BLOCKQUOTE> con un gran margen en la parte izquierda.
<BLOCKQUOTE cite="http://www.ejemplo.com/Accesibilidadweb">
<P> La discapacidad no es el único tipo de limitación que
dificulta la Accesibilidad de contenidos!!!
--- Henry, Shawn Lawton. (2002). Understanding Web
Accessibility
</P>
</BLOCKQUOTE>
Si el efecto que se quiere lograr en la aplicación Web es dejar sangría, se puede utilizar, por
ejemplo, la propiedad de CSS2 [29] "text-indent". No se debe utilizar BLOCKQUOTE o cualquier
otro elemento estructural para hacer sangrías en el texto.

PAUTA 4. IDENTIFIQUE EL IDIOMA USADO

USE MARCADORES QUE FACILITEN LA PRONUNCIACIÓN O INTERPRETACIÓN DE
TEXTO ABREVIADO O EXTRANJERO
Punto de Verificación: 4.1 Identifique claramente los cambios en el idioma del texto del
documento y en cualquier texto equivalente (Por ejemplo, leyendas). [Prioridad 1]
Prescripción Mapeo
Indicar el idioma de cada elemento de la página, permite a los agentes Clase de Presentación -
de usuario representar el contenido de forma más significativa según la Componente Vista:
práctica cultural aceptada para cada idioma en particular, por ejemplo La identificación de los
eligiendo variaciones de un signo para tipografía de alta calidad o cambios de idioma aporta
decidir la separación de palabras o un determinado espaciado. significado y semántica
para comprensión de la
página Web, por parte de
los usuarios. Los
sintetizadores de voz o
42 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

dispositivos braille
interpretarán y
presentarán la
información en el nuevo
idioma, cambiando
algunos elementos de
presentación al usuario
que hace uso de estas
herramientas.
Ejemplo: en HTML [30] la mayoría de los elementos disponen del atributo “lang” para indicar el
idioma del elemento:
<P><Q lang="es">Sus superpoderes son el resultado de las
radiaciones &gamma;,</Q> dijo él.</P>
En el ejemplo, aparecen caracteres del alfabeto griego dentro un texto escrito en español, por lo que
el agente de usuario debe intentar representar el contenido en español de una manera apropiada (en
lo que respecta a la puntuación de la cita) e intentar representar “&gamma”, lo mejor posible aunque
no sea un carácter español.

Punto de Verificación: 4.2 Especifique la expansión de cada abreviatura o acrónimo

cuando aparezcan por primera vez en el documento. [Prioridad 3]
Prescripción Mapeo
Clase de Presentación -
Cada abreviatura o acrónimo deberá ser marcado adecuadamente, por Componente Vista:
primera vez, en el documento Web por medio de la utilización de Describir claramente la
etiquetas destinadas a tal fin. expansión de cada
abreviatura y acrónimo
agrega información
semántica a la aplicación,
permitiendo en gran
medida al usuario final
saber afirmativamente que
está frente a uno de ellos e
interpretarlo, más aún
cuando se utilizan
herramientas como
lectores de pantalla. Los
nuevos objetos de
interacción, como líneas
punteadas y un pequeño
recuadro con la
descripción serán
mostrados por el
navegador al interpretar
las abreviaturas y
acrónimos.
Ejemplo: en el lenguaje HTML [30] la etiqueta <ABBR> marca las abreviaturas de un texto y la
etiqueta <ACRONYM> las siglas o acrónimos del texto.
<ACRONYM title="Uniform Resource Locator">URL</ACRONYM>
Los navegadores muestran por defecto un borde inferior punteado para todos los elementos
<ABBR> y <ACRONYM>. Al posicionar el puntero del mouse sobre la palabra subrayada, el
navegador muestra un pequeño recuadro (llamado tooltip en inglés) con el valor del atributo “title”
asociado a las etiquetas, valor que permitirá describir la naturaleza de cada elemento.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 43

Punto de Verificación: 4.3 Identifique el idioma principal de un documento. [Prioridad

3]
Prescripción Mapeo
Identificar del idioma principal del documento a través de una etiqueta Clase de Presentación -
de marcado. Componente Vista:
El valor asociado al
idioma principal del
documento provee una
información semántica
importante para aquellos
usuarios que estén
navegando a través de un
sintetizador de voz, un
dispositivo braille, o
simplemente para
usuarios que estén
intentando acceder por
medio de un buscador
Web. Los elementos de
presentación serán
adaptados por los
sintetizadores de voz o
dispositivos braille para
ser presentados con una
mejor pronunciación del
idioma especificado.
Ejemplo: el lenguaje natural de un documento HTML [30] se marca con el atributo "lang" en la
etiqueta <HTML>:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
<HTML lang="es">
<HEAD> <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<TITLE>Buscador Web</TITLE>
</HEAD>
<BODY>…

PAUTA 5. CREE TABLAS QUE SE TRANSFORMEN CORRECTAMENTE

Punto de Verificación: 5.1 En las tablas de datos, identifique los encabezamientos de fila
y columna. [Prioridad 1]
Prescripción Mapeo
Identificar las celdas que funcionan como encabezado mediante Clase de Presentación -
elementos de marcado, aportando así una estructura y significado a la Componente Vista:
información de la tabla. Usando los elementos de marcado Los tokens semánticos
correctamente y creando tablas que se transformen adecuadamente asociados al significado u
haría posible a los navegadores interpretar tablas de otra forma que objetivo de los elementos
como grilla en dos dimensiones, entre otras. de marcado de encabezado
se harán evidentes, para
usuarios cuyos
navegadores realizaban
una mala transformación
de las tablas, o más aún,
para usuarios que
dispongan de software
especializado, por ejemplo
44 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

lectores de pantalla.
Entenderán sin dificultad
la organización de la
página o cómo navegar
por ella.
Ejemplo: en HTML [30] utilice las etiquetas <TABLE> para crear la tabla, <TR> para crear cada
fila y <TD> para crear cada columna, y el atributo "headers" para especificar una lista de celdas de
encabezamiento (etiquetas de fila y columna) asociadas con la celda de datos actual.
<TABLE border="1"
summary="Esta tabla esquematiza el número de búsquedas
realizadas desde cada dirección IP, el tipo de búsqueda (simple
o avanzada) y si se ha ingresado a algún enlace del resultado.">
<CAPTION>Tazas de café consumidas por cada senador</CAPTION>
<TR>
<TH id="header1">IP</TH>
<TH id="header2">Búsquedas</TH>
<TH id="header3" abbr="Tipo">Tipo de búsqueda</TH>
<TH id="header4">¿Ingresó?</TH>
<TR>
<TD headers="header1">10.14.100.173 </TD>
<TD headers="header2">10</TD>
<TD headers="header3">Avanzada</TD>
<TD headers="header4">SI</TD> …
Punto de Verificación: 5.2 Para las tablas de datos que tienen dos o más niveles lógicos
de encabezamientos de fila o columna, utilice marcadores para asociar las celdas de
encabezamiento y las celdas de datos. [Prioridad 1]
Prescripción Mapeo
Es común que las tablas más avanzadas dispongan de una sección de Clase de Presentación -
cabecera, una sección de pie y varias secciones de datos. Además, Componente Vista:
también es posible agrupar varias columnas de forma lógica para poder Al usar los marcadores
aplicar estilos similares a un determinado grupo de columnas. Utilizar adecuados para
los marcadores apropiados para que los navegadores o cualquier implementar tablas más
software especializado puedan interpretar y diferenciar adecuadamente complejas, los tokens
las celdas de encabezamiento y de datos. semánticos asociados al
significado u objetivo de
estos elementos de
marcado se harán
evidentes, para usuarios
cuyos navegadores
realizaban una mala
transformación de las
tablas, o más aún, para
usuarios que dispongan de
software especializado,
por ejemplo lectores de
pantalla. Entenderán sin
dificultad la organización
de la tabla y cómo
navegar por ella.
Ejemplo: en el lenguaje HTML [30] las partes que componen las tablas complejas se definen
mediante las etiquetas <THEAD> para la cabecera, <TBODY> para la sección de datos y
<TFOOT> para el pié.
La etiqueta <TBODY> permite realizar agrupaciones de filas, pero en ocasiones se necesitan
agrupar columnas. Aunque su uso no es muy común, HTML [30] define dos etiquetas similares para
agrupar columnas: <COL> y <COLGROUP>.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 45
La etiqueta <COL> se utiliza para asignar los mismos atributos a varias columnas de forma
simultánea.
Por otra parte, la etiqueta <COLGROUP> se emplea para agrupar de forma estructural varias
columnas de la tabla. La forma habitual de indicar el número de columnas que abarca la agrupación
es utilizar el atributo “span”, que indica el número de columnas de cada agrupación.
<HTML>
<HEAD><TITLE>Ejemplo de tabla avanzada</TITLE></HEAD>
<BODY>
<H3>Histórico Buscador
<TABLE summary="Resultados de Búsqueda realizada por año">
<CAPTION>Resultados de Búsquedas por año</CAPTION>
<THEAD>
<TR>
<TH rowspan="2" scope="col">AÑO</TH>
<TH colspan="4" scope="col">Páginas accedidas</TH>
</TR>
<TR>
<TH scope="col">URL A</TH>
<TH scope="col">URL B</TH>
<TH scope="col">URL C</TH>
<TH scope="col">URL D</TH>
</TR>
</THEAD>
<TFOOT>
<TR>
<TH rowspan="2" scope="col">AÑO</TH>
<TH scope="col">URL A</TH>
<TH scope="col">URL B</TH>
<TH scope="col">URL C</TH>
<TH scope="col">URL D</TH>
</TR>
<TR>
</TR>
</TFOOT>
<TBODY>
<TR>
<TH scope="row">N-3</TH>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
<TD>-</TD>
</TR>
<TR>
<TH scope="row">N-2 </TH>
<TD>3</TD>
<TD>5</TD>
<TD>8</TD>
<TD>4</TD>
</TR>
<TR>
<TH scope="row">N-1</TH>
<TD>4</TD>
<TD>4</TD>
<TD>7</TD>
<TD>3</TD>
</TR>
<TR>
<TH scope="row">N</TH>
<TD>5</TD>
46 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

<TD>7</TD>
<TD>6</TD>
<TD>2</TD>
</TR>
</TBODY>
</TABLE>
</BODY>
</HTML>
Punto de Verificación: 5.3. No utilice tablas para maquetar, a menos que la tabla tenga
sentido cuando se transcriba línea a línea. Por otro lado, si la tabla no tiene sentido,
proporcione una alternativa equivalente (la cual debe ser una versión linearizada).
[Prioridad 2]
Prescripción Mapeo
Los contenidos deben ser maquetados, ubicados, colocados en capas y Clase de Presentación -
alineados mediante hojas de estilo. Las tablas utilizadas para maquetar Componentes Vista y
páginas, con celdas en el que el texto se extiende a través de más de Controlador:
una línea, plantean problemas para los lectores de pantalla antiguos, El posicionamiento visual
que no interpretan el código fuente o para los navegadores que no de los objetos de
permiten la navegación por celdas individuales de tablas. Estos lectores interacción en el
de pantalla leerán la página por líneas completas, leyendo las frases de documento, depende de
toda una línea pero de cada columna como si fueran una sola frase. las reglas de estilo
Si se utilizan tablas, solo es recomendable utilizarlas para maquetear definidas. En caso de
cuando el orden de la información en ella sea comprensible después de haberse utilizado archivos
transformarse en forma lineal. externos de hoja de estilo,
el usuario podría
controlar la posición
visual de casi cualquier
elemento con
independencia de donde
aparezca el elemento en el
documento. Siempre que
los desarrolladores hayan
diseñado el documento
para que tengan sentido
sin la hoja de estilo (por
ejemplo, el documento
esta escrito en un orden
“lógico”).
Ejemplo: en CSS1 [28] existen un conjunto de propiedades de colocación absoluta para darle
estilo de posicionamiento al contenido:
• Las propiedades “text-indent”, “text-align”, “word-spacing” y “font-stretch”, permiten a los
usuarios controlar el espaciado sin añadir espacios adicionales.
• Las propiedades “margin” “margin-top”, “margin-right”, “margin-bottom” y “margin-left”,
los desarrolladores pueden crear espacios en los cuatro lados del contenido de un elemento,
en lugar de añadir espacios de no separación (&nbsp;).
<INPUT type="text" name="nombreOperador" style="margin-
left:1em"> </INPUT>
Punto de Verificación: 5.4. Si se utiliza una tabla para maquetar, no utilice marcadores
estructurales para realizar un efecto visual. [Prioridad 2]
Prescripción Mapeo
Cuando se utilicen tablas para maquetar, no utilice etiquetas Clase de Presentación -
estructurales para crear formatos visuales. Componente Vista:
Utilizar hojas de estilo en
vez de marcadores
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 47
estructurales para dar un
efecto visual de formato,
son decisiones asociadas a
los aspectos de la Vista y
presentación de la
aplicación Web.
Ejemplo: en HTML [30], el elemento <TH> muestra visualmente el contenido de la celda centrado
y en negrita. Si una celda no es realmente el encabezamiento de una fila o columna de datos, se
deberían utilizar hojas de estilo o atributos de formateo del elemento.
Punto de Verificación: 5.5. Proporcione resúmenes de las tablas. [Prioridad 3]
Prescripción Mapeo
Proporcionar el resumen de una tabla permite describir el contenido de Clase de Presentación -
la misma. Un resumen de las relaciones entre las celdas es Componente Vista:
especialmente importante para las tablas con encabezamientos Al proporcionar el
anidados, celdas que ocupan varias columnas o filas, u otras relaciones resumen de una tabla, la
que no sean evidentes en un análisis de la estructura de la tabla, pero presentación de la
que sí se aprecian cuando la tabla se muestra visualmente. Un resumen aplicación Web no sufrirá
también puede describir como una tabla encaja en el contexto del ningún cambio para los
documento actual. usuarios con navegadores
comunes. Por lo contrario,
para los usuarios con
algún tipo de software
especializado, por
ejemplo lectores de
pantalla, incorporará
nuevos elementos de
interacción
correspondientes al texto
del resumen ingresado.
Ejemplo: en el lenguaje HTML [30] puede realizarse a través del atributo “summary”. Ver
ejemplo punto de verificación 5.2.
Punto de Verificación: 5.6. Proporcione abreviaturas para las etiquetas de
encabezamiento. [Prioridad 3]
Prescripción Mapeo
Proporcionar subtítulos para las etiquetas de encabezamiento puede Clase Presentación -
realizarse a través de atributos asociados a la cabecera de la tabla. Componente Vista: las
abreviaturas reducen la
repetición y el tiempo de
lectura, aportando nuevos
objetos de interacción en
la presentación de la
aplicación Web. Los
mismos serán
intercambiados en un
orden específico con el
usuario final, cuando sean
reconocidos por software
especializados o por
futuras tecnologías con
habla que puedan leer las
etiquetas de fila y columna
para cada celda.
Ejemplo: en HTML [30] el atributo "abbr" de la etiqueta <THEAD>.
48 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

<TH abbr="Criterios de Búsqueda a aplicar" cope="col"> Criterios

</TH>

PAUTA 6. ASEGÚRESE DE QUE LAS PÁGINAS QUE INCORPORAN NUEVAS

TECNOLOGÍAS SE TRANSFORMEN CORRECTAMENTE
Punto de Verificación: 6.1 Organice el documento de forma que pueda ser leído sin hoja
de estilo. Por ejemplo, cuando un documento HTML es interpretado sin asociarlo a una
hoja de estilo, tiene que ser posible leerlo. [Prioridad 1]
Prescripción Mapeo
Estableciendo un orden y una estabilidad en la distribución de los Clase Presentación -
contenidos de una aplicación Web, los usuarios finales pueden Componentes Vista y
visualizar o navegar en forma organizada y limpia por la página. Controlador:
Cuando el contenido está organizado lógicamente, por orden de El usuario a través de las
importancia por ejemplo, es interpretado de forma que la distribución facilidades (alguna
continúa siendo clara incluso cuando se desconecten o no se soporten acción) que ofrecen las
las hojas de estilo. Analizar el sistema estética y funcionalmente sin la herramientas de
presencia de hojas de estilo. navegación, podrá
desactivar las hojas de
estilo definidas por los
desarrolladores. La
presentación de la
aplicación va a sufrir
variaciones de aspectos
visuales, en la medida que
pueda ser leído sin la hoja
de estilo.

Ejemplo: el orden en que los objetos de interacción son distribuidos en la ventana del navegador
del usuario no debería ser diferente del orden en que aparecen en el documento fuente. Si esto
ocurriera, la ubicación de los mismos ha sido forzada o establecida en la hoja de estilo, y cambiará
al ser esta desconectada.
Punto de Verificación: 6.2 Asegúrese de que los equivalentes de un contenido dinámico
son actualizados cuando cambia el contenido dinámico. [Prioridad 1]
Prescripción Mapeo
El contenido dinámico, al igual que el estático debe tener asociado un Clases de Diálogo y
contenido equivalente que cumpla esencialmente la misma función o Presentación -
propósito en la presentación al usuario final, en el mismo contexto. Componentes Vista y
Este contenido equivalente debe estar siempre actualizado. Controlador: ante posibles
cambios en el contenido
dinámico, por eventos
ingresados por el usuario,
trasladados por el
Controlador, la Vista
actualiza consistentemente
la información que
muestran al usuario.
Ejemplo: para el contenido de cada frame se debe proporcionar un equivalente textual, asegurando
que los contenidos y las relaciones entre los frames tienen sentido, y que serán actualizados cuando
se presenten cambios. En HTML [30] cuando se implemente un frame con una imagen como
contenido, no se debe insertar directamente en el frame, por el contrario, la imagen debe estar en un
archivo HTML, y este debe ser el origen “scr” del frame.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 49
<HTML>
<HEAD>
<TITLE>Un documento de frames correcto</TITLE>
</HEAD>
<FRAMESET cols="100%" title="Conjunto de frames que
evolucionan">
<FRAME name="marcobueno" src="ordenadores.html"
title="Tipos de Ordenadores">
</FRAMESET>
</HTML>
<!-- En ordenadores.html -->
<P><IMG src="ordenadores.gif" alt="Tipos de Ordenadores">
De esta manera, si un vínculo causa la inserción de una nueva imagen en el frame:
<P>Consulte un tipo de
<A target="marcobueno" href="teclados.gif" title="Tipos de
Teclados">teclados</A>
El nuevo título del frame ("Tipos de Teclados") se corresponderá con el contenido actual del frame
("Tipos de Teclados").
Punto de Verificación: 6.3 Asegúrese de que las páginas sigan siendo utilizables cuando
se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto
no es posible, proporcione información equivalente en una página alternativa accesible.
[Prioridad 1]
Prescripción Mapeo
Algunos navegadores no disponen de soporte completo de lenguajes de Clases Presentación y
scripting. Otros permiten bloquear la ejecución de scripts parcialmente Diálogo - Componentes
e incluso algunos usuarios bloquean completamente el uso de objetos Vista y Controlador: Ante
programados porque creen que así navegan de forma más segura. Ante la configuración de los
cualquiera de estos casos, a través de la incorporación de “equivalentes navegadores o los eventos
textuales y no textuales”, el diseñador de la aplicación Web, debe disparados por los
asegurarse de proveer las mismas funciones o propósito para el usuario usuarios, la Vista de la
final. aplicación cambiará de
manera tal de que siga
siendo utilizable, es decir
reflejando el mismo
modelo, en caso de no
estar desconectados los
scripts, applets u otros
objetos programados.
Ejemplo: en HTML [30] la etiqueta <SCRIPT> sirve tanto para insertar un bloque de código en la
página como para enlazar un archivo externo. Esta etiqueta puede enlazar código que esté escrito en
algún lenguaje de Scripting, por ejemplo JavaScript. El elemento <NOSCRIPT> permite a los
diseñadores proporcionar contenido alternativo cuando un script no es ejecutado.
<SCRIPT type="text/tcl">
...un script Tcl para mostrar un resumen de búsquedas realizadas
realizada...
</SCRIPT>
<NOSCRIPT>
<P>Históricos de búsquedas realizadas por mes:</P>
<DL>
<DT>ENE 91, FEB 80.
<DD>
<A href="estadistica.html">Estadística de búsquedas por
páginas </A>
...mas resultados...
</DL>
50 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

</NOSCRIPT>
En el caso particular del elemento <APPLET>, el atributo "alt" dentro del contenido del elemento,
permite incorporar un equivalente textual, logrando una transformación satisfactoria del contenido
para aquellas aplicaciones de usuario que sólo soportan uno de los dos mecanismos ("alt" o
contenido).
<APPLET code="Press.class" widTH="500" height="500"
alt="Applet Java: estadística de búsquedas por criterios">
La cantidad de búsquedas realizadas en los últimos meses …
</APPLET>
Punto de Verificación: 6.4 Para los scripts y applets, asegúrese de que los manejadores
de evento sean independientes del dispositivo de entrada. [Prioridad 2]
Prescripción Mapeo
La interacción con el usuario se puede conseguir mediante la captura Clases de Presentación y
de eventos que este produce. Los eventos soportados estarán Pragmática -
determinados por el lenguaje de programación utilizado, por el sistema Componentes Vista y
operativo e incluso por eventos creados por el mismo programador de Controlador:
la aplicación. Algunos manejadores de eventos, cuando se invocan, La utilización de eventos
causan efectos puramente decorativos tales como resaltar una imagen o independientes del
cambiar el color del texto de un elemento. Otros causan efectos más dispositivo, generan un
importantes, tales como realizar un cálculo, proporcionar información comportamiento a nivel
importante al usuario, o enviar un formulario. Para manejadores de de aplicación, logrando la
eventos que solo cambian la apariencia de un elemento, los mayoría un efecto sobre
diseñadores de la aplicación deberían: los elementos de la
1. Emplear disparadores al nivel de aplicación en vez de presentación de la misma.
disparadores de nivel de interacción con el usuario. Los Las decisiones asociadas
eventos a nivel de aplicación son atributos diseñados para ser a la combinación y
independiente del dispositivo. secuencia de teclas,
2. Si se tiene que emplear atributos específicos de un movimientos y presión de
dispositivo, se debería proporcionar mecanismos redundantes botones del mouse, o
de interacción (es decir, especificar dos manejadores para un cualquier definición sobre
mismo elemento). dispositivo de entrada
3. No emplear manejadores de eventos que dependan de las deberán tomarse. Así
coordenadas del mouse porque esto impide la interacción mismo el Controlador
independiente de dispositivo. será quien deberá
determinar en función de
las entradas ingresadas
por el usuario, entre los
mecanismo redundantes
de interacción,
actualizando la Vista.
Ejemplo: en HTML [30] utilizar los atributos "onfocus", "onblur", "onselect", "onmousedown"
con "onkeydown", "onmouseup" con "onkeyup" y "onclick" con "onkeypress" para los elementos
de presentación que los soporten. El foco de la aplicación por ejemplo, se obtendrá sin importar el
dispositivo que lo dispare.
Punto de Verificación: 6.5 Asegúrese de que los contenidos dinámicos son accesibles o
proporcione una página o presentación alternativa. [Prioridad 2]
Prescripción Mapeo
Particularmente si los frames de una página no son soportados por el Clases Presentación,
navegador, los usuarios invidentes, no podrán percibir las relaciones Diálogo y Pragmática -
establecidas entre los contenidos de los distintos frames. Dentro de los Componentes Vista y
problemas de Accesibilidad asociados a frames encontramos que: Controlador:
• Algunos navegadores no los soportan o están configurados Ver punto de verificación
para no mostrarlos. 6.4.
• Sin scripts, los frames tienden a degradar la funcionalidad del
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 51
botón "página anterior" del navegador.
• Es imposible hacer referencia al "estado actual" de un
conjunto de frames con URI; una vez que cambien los
contenidos de un conjunto de frames, el URI original ya no es
válido.
• Al abrir el contenido de un frame en una nueva ventana puede
desorientar al usuario o simplemente molestarle.
Para scritps y applets ver puntos de verificación 6.2 y 6.3
Ejemplo: algunas de las formas de proveer alternativas accesibles al usuario:
1. En HTML [30] para frames inaccesibles, ofrecer una alternativa “accesible” equivalente a
través del elemento NOFRAMES, incluyendo entre la etiqueta <NOFRAMES > y su cierre
</ NOFRAMES > el contenido que sólo será interpretado por aquellos navegadores que no
soporten frames.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
<HEAD>
<TITLE>Este es arriba.html</TITLE>
</HEAD>
<FRAMESET cols="50%, 50%" title="Nuestro documento largo">
<FRAME src="principal.html" title="Donde se muestra el
contenido">
<FRAME src="tabla_de_contenido.html" title="Tabla de
contenidos">
<NOFRAMES>
<A href="tabla_de_contenido.html">Tabla de contenidos.</A>
<!-- otros vínculos de navegación visibles en principal.html
también son visibles aquí. -->
</NOFRAMES>
</FRAMESET>
</HTML>
2. Situar en el servidor scripts que generen versiones “accesibles” de la página solicitada. El
servidor ejecuta los scripts y se genera una página resultado, que solamente contiene
código HTML “accesible”. De esta manera, el cliente no puede ver los scripts, ya que se
ejecutan y transforman en HTML antes de ser enviados. Además son independientes del
navegador del usuario, ya que el código que reciben es HTML fácilmente interpretable.
3. Proporcionar un número de teléfono, fax, dirección de correo electrónico o postal donde la
información esté disponible y “accesible”, preferentemente las 24 horas del día.
4. Permitirle al usuario navegar a otra página diferente que sea “accesible” y contenga la
misma información que la página inaccesible, con la condición de que sea actualizada con
la misma frecuencia que la página inaccesible. Se podría proporcionar el vínculo al
principio, tanto de la página principal como de la alternativa, asegurando que este sea una
de las primeras cosas que el usuario vaya a percibir, permitiéndole moverse entre ellas. El
elemento LINK de HTML [30] permite enlazar recursos, apuntando a la página
“accesible” y relacionar unos recursos con otros. Su atributo “media” hace referencia al
medio para el que es válida la relación con el recurso enlazado. Los medios más comunes:
screen para los contenidos mostrados en pantalla, print para las impresoras y handheld
para los dispositivos móviles, entre otros. Las aplicaciones de usuario que soportan LINK
cargarán la página alternativa para aquellos usuarios cuyo tipo de navegador se identifica
como uno de los establecidos en el atributo “media”, por ejemplo: "aural", "braille", o "tty".
<HEAD>
<TITLE>Bienvenidos Buscador Virtual!</TITLE>
<LINK title="Versión solo texto"
rel="alternate"
href="solo_texto"
media="aural, braille, tty">
</HEAD>
<BODY><P>...</BODY>
52 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

Ver punto de verificación 6.3 para contenido alternativo de scripts y applets.

Ver punto de verificación 3.6 y pauta 5.1.4 para contenido alternativo de presentaciones
sonoras.

PAUTA 7. ASEGURE AL USUARIO EL CONTROL SOBRE LOS CAMBIOS DE LOS

CONTENIDOS TEMPO -DEPENDIENTES
Punto de Verificación: 7.1 Hasta que las aplicaciones de usuario permitan controlarlo,
evite provocar destellos en la pantalla. [Prioridad 1]
7.2 Hasta que las aplicaciones de usuario permitan controlarlo, evite el parpadeo del
contenido (por ejemplo, cambio de presentación en periodos regulares, así como el
encendido y apagado). [Prioridad 2]
Prescripción Mapeo
Una pantalla parpadeante o con destello puede provocar ataques en Clases de Diálogo,
usuarios con epilepsia foto sensitiva; por eso, los desarrolladores de Presentación y Pragmática
contenidos deben evitar causar destello de la pantalla. Si la acción de - Componentes Vista y
destello o parpadeo no es puramente decorativo, sino que se utiliza Controlador:
para transmitir cierta información o significado al usuario, se deberán Ver punto de verificación
incorporar mecanismos accesibles para proveer la misma función, 6.4.
semántica o propósito en la presentación del usuario, a través de
nuevos elementos de interacción o cambiando los atributos o
propiedades de algún objeto existente Si se toma la decisión de que el
parpadeo o destello que causa la ejecución de un objeto programado,
applet o script, continué, se debe proporcionar un mecanismo que le
permita al usuario detener este movimiento.
Ejemplo: en CSS2 [29] existen un conjunto de propiedades para darle estilo al texto: "text-
transform" para mayúsculas/minúsculas, "text-shadow" para efectos de sombra y "text-decoration"
para subrayado y suprasubrayado por ejemplo.
Mediante la captura de eventos que el usuario produce (Ver ejemplo pauta 6.4) o a través de
atributos como "text-decoration: blink", que producen el efecto de parpadeo, se le puede permitir al
usuario detener el parpadeo, desactivando las hojas de estilo o redefiniendo la regla en una hoja de
estilo definida por este. Se deben evitar usar los elementos BLINK o MARQUEE, o algún otro
elemento que no aparezca en ninguna especificación W3C para HTML (es decir, son elementos no
estándares).
Punto de Verificación: 7.3 Hasta que las aplicaciones de usuario permitan congelar el
movimiento de los contenidos, evite los movimientos en las páginas. [Prioridad 2]
Prescripción Mapeo
Asegúrese de que los objetos o páginas que se mueven o desplazan Clases de Diálogo,
puedan ser detenidos o parados. Algunas personas con discapacidades Presentación y Pragmática
cognitivas o visuales son incapaces de leer textos que se mueven con la - Componentes Vista y
suficiente rapidez. El movimiento puede también distraer de tal manera Controlador:
que el resto de la página se vuelve ilegible para las personas con El usuario a través de las
discapacidades cognitivas. Los lectores de pantalla son incapaces de facilidades (alguna acción)
leer textos móviles. Cuando una página incluye contenido móvil, que ofrecen las
proporcione un mecanismo dentro del objeto programado, script o herramientas de
applet que permita a los usuarios congelar el movimiento o navegación, podrá
actualización tal como fue mencionado en las pautas 7.1 y 7.2. desactivar las hojas de
estilo definidas por los
desarrolladores. La
presentación de la
aplicación va a sufrir
variaciones de los aspectos
visuales asociados a la
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 53
pérdida de los
movimientos.
Ejemplo: la posibilidad de combinar scripts con hojas de estilo para definir estilos con
movimiento, permite a los usuarios desconectar u obviar el efecto más fácilmente.
Punto de Verificación: 7.4 Hasta que las aplicaciones de usuario proporcionen la
posibilidad de detener las actualizaciones, no cree páginas que se actualicen
automáticamente de forma periódica. [Prioridad 2]
7.5 Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el
redireccionamiento automático, no utilice marcadores para redirigir las páginas
automáticamente. En su lugar, configure el servidor para que ejecute esta posibilidad.
[Prioridad 2]
Prescripción Mapeo
A veces, los desarrolladores de contenidos crean páginas que se Clases Presentación y
renuevan o cambian sin que lo pida el usuario. Esta técnica no debe ser Diálogo - Componentes
usada para simular tecnología push de servidor. Los desarrolladores no Vista y Controlador:
pueden saber de antemano cuanto tiempo necesitará el usuario para El usuario será quien
leer una página. Una actualización antes de tiempo desorienta al tendrá el control de
usuario. Los desarrolladores de contenidos deberían evitar la redireccionar o actualiza
actualización periódica y permitir a los usuarios elegir cuándo quieren las páginas. A partir de las
actualizar la información. decisiones tomadas por
este, se actualizará la Vista
de la aplicación.
Ejemplo:
1. No usar el encabezado REFRESH, configurando el número de segundos que debe emplear
el navegador en hacer la nueva petición de página. La página debería ser actualizada
cuando el usuario lo desee a través de la opción provista por el navegador y no
automáticamente cada un intervalo de tiempo preestablecido por el diseñador.
<META HTTP-EQUIV= refresh "CONTENT="5;
URL=http://www.terra.es/personal6/morenocerro2/index.html">
En donde 5 es el número de segundos que debe emplear el navegador en hacer la nueva
petición de página, y URL es la ruta absoluta y completa de la nueva página a pedir.
2. Configurar el servidor para que utilice el código de estatus HTTP apropiado (301) en los
mensajes http de respuesta. Los códigos de estado del tipo 30x proporcionan información
del tipo "traslado permanente" (moved permanently) o "traslado temporal" (moved
temporarily), permitiendo especificar redirecciones desde el servidor. Si se configura al
servidor para que se encargue de la redirección de las páginas, normalmente, el navegador
no debería redirigirse hacia la nueva URI sin una confirmación previa por parte del usuario.
3. Sustituir la página que sería redirigida por una página estática que contenga un vínculo
normal a la nueva página.

PAUTA 8. ASEGURE LA ACCESIBILIDAD DIRECTA DE LAS INTERFACES DE USUARIO

INCRUSTADAS
Punto de Verificación: 8.1 Haga los elementos de programación, tales como scripts y
applets, directamente accesibles o compatibles con las ayudas técnicas. [Prioridad 1 si la
funcionalidad es importante y no se presenta en otro lugar; de otra manera, Prioridad 2.]
Prescripción Mapeo
Cuando un objeto incrustado tiene su "propia interfaz", ésta (al igual Clases de Presentación,
que la interfaz de su navegador) debe ser “accesible”. Si la interfaz del Diálogo y Pragmática -
objeto no puede hacerse “accesible”, debe proporcionarse una solución Componentes Vista y
alternativa “accesible”. Por lo tanto se deberán considerar al momento Controlador.
de definir los elementos de programación que sus interfaces cumplan
las siguientes características:
• Proveer información importante y ocurrencia de eventos en
54 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

más de un medio (medio alternativo): la información asociada

con relaciones espaciales, imágenes, colores, características
de texto, cambios y eventos visuales, display análogos y
sonidos deberían ser presentadas en múltiples medios.
• Los eventos deberían poder ser disparados por acciones del
usuario; a través de movimientos del mouse, teclas de
desplazamiento en pantalla, etc.
• Permitir al usuario cambiar la presentación, formato y
contenido del componente o applet, dependiendo de la
plataforma en la que se desarrolle. Se debería permitir definir
el tamaño del texto, contraste, colores oscuros o claros, iniciar
o suspender actualizaciones de pantallas, el tipo de medio en
el cual deberá ser mostrado el contenido (por ejemplo: video
presentado con subtítulos, sonido presentado como texto,
texto presentado por sonido a modo de explicación).
• Describir el contenido, acciones y relaciones del componente
o applet. Presentar al usuario un resumen de la funcionalidad
del componente o un texto descriptivo del contenido, acciones
y relaciones que se hayan establecido en él. Cuando tenga
sentido, indicar cómo se debe hacer uso del mismo.
• Agrupar aquellos componentes que formen un grupo lógico
en la interfaz de usuario.
• No mezclar componentes “accesibles” con componentes
inaccesibles.
• Proveer un significado o sentido de navegación en el
componente o applet a través de movimientos del mouse y
una buena interfaz de teclado.
• Notificar al usuario de a través de diferentes medios o
alternativas los cambios visuales que se estén realizando y que
conlleven un significado o función específica. Por ejemplo:
cambios en el tipo de letra, tamaño, color, movimiento,
imagen, etc.
• Hacer el texto “accesible” por los dispositivos de tecnología
asistida. Algunos componentes de aplicaciones o applets no
son accesibles por dispositivos como lectores de pantallas.
• Proveer menús para ingresar comandos. Cuando los
comandos pueden ser accedidos a través de menús, los
softwares de acceso tienen muy pocos problemas en acceder
desde tanto al menú como a los comandos.
Ejemplo: desarrollados en pautas 1.3, 1.4, 6.2, 6.3, 6.5, 7.1, 7.2, 7.3, 7.4, 9.3, 10.1 entre otras.

PAUTA 9. DISEÑE PARA LA INDEPENDENCIA DEL DISPOSITIVO

Punto de Verificación: 9.1 Proporcione mapas de imagen controlados por el cliente en
lugar de por el servidor, excepto donde las zonas sensibles no puedan ser definidas con
una forma geométrica. [Prioridad 1]
Prescripción Mapeo
Como se describió en la pauta 1.5, con la etiqueta <AREA> se marcan Clases de Diálogo,
las distintas zonas sensibles definidas geométricamente en un mapa de Presentación y Pragmática
imagen. Cada área, indicada por la etiqueta <AREA>, tiene los - Componentes Vista y
siguientes atributos: Controlador:
• alt: indica un texto que se mostrará cuando situemos el mouse Para las zonas sensitivas
en el área. procesadas por un script
• shape: indica el tipo de área. del servidor, el usuario no
• coords: indica las coordenadas que definen el área. podrá independizarse del
• href: indica el destino del enlace correspondiente al área. dispositivo de
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 55

Los mapas de imagen controlados por el cliente permiten que el apuntalamiento, para el
usuario vea la URL actual asociada con las regiones mapeadas en la resto de las zonas podrá
barra de estado de su navegador Web e independizarse del dispositivo ingresar las coordenada
de apuntalamiento, así como también las personas que utilizan agentes para ingresar a las
de usuario no gráficos pueden interactuar con la aplicación de usuario mismas. Las acciones o
y saber si una región esta activa o no. eventos ingresados por el
usuario provocarán el
Para aquellas zonas de un mapa que no puedan ser definidas en forma
cambio en la Vista de la
geométrica, la pauta actual establece que se definan a través de un
aplicación.
mapa procesado en el servidor. Este tipo de mapas se basa en la
utilización de un archivo en el servidor, que define las diferentes
coordenadas de las zonas sensitivas de la imagen.

Ejemplo: las zonas de la imagen que pueden ser definidas en forma geométrica serán
proporcionadas por un mapa de imagen controlado por el cliente. En HTML indicando cada área y
tipo:
• shape="RECT": Crea un área rectangular. Para definirla se utilizan las coordenadas de los
puntos de la esquina superior izquierda y la esquina inferior derecha.
<area shape="RECT" coords="X1,Y1,X2,Y2" href="#">
• shape="CIRCLE": Crea un área circular, que se indica con la coordenada del centro del
círculo y el radio.
<area shape="CIRCLE" coords="X1,Y1,R" href="#">
• shape="POLY": Crea un área poligonal. Un polígono queda definido indicando todos sus
puntos, pero atención, los tenemos que indicar en orden, siguiendo el camino marcado por
el perímetro del polígono.
<area shape="POLY" coords=" X1,Y1, X2,Y2, X3,Y3, X4,Y4"
href="#">
Las zonas de la imagen que no puedan ser definidas en forma geométrica serán procesadas a través
de un script en el servidor.
<a href ="http://www.miservidor.com/cgi-bin/mapa1.map">
<img src="mapa1.gif" ismap border="0">
</a>
En el archivo mapa1.map estarían definidas las coordenadas de los enlaces de la imagen sensitiva
mapa1.gif , de manera que cuando se realiza un click sobre la imagen, se realiza sobre coordenadas
determinadas de la misma, que son enviadas al servidor y en función de estas se consulta el archivo
mapa1.map y se halla la dirección final del enlace.
Punto de Verificación: 9.2 Asegúrese de que cualquier elemento que tiene su propia
interfaz pueda manejarse de forma independiente del dispositivo. [Prioridad 2]
Prescripción Mapeo
Los usuarios deben poder interactuar con una aplicación Web Clases Diálogo y
utilizando los dispositivos de entrada y salida de su elección y acordes Pragmática - Componentes
a sus necesidades. Que las aplicaciones puedan manejarse Vista y Controlador:
independientemente del dispositivo, no implica que tenga que soportar Para cualquier contexto de
todos los dispositivos de entrada y salida, sino que deben ofrecer presentación de hardware,
mecanismos de entrada y salida redundantes para cada dispositivo que no dependiendo de una
sea soportado. combinación de hardware
Para que los desarrolladores logren esta independencia es necesario y software específica, el
que los lenguajes de etiquetado estándares usados funcionen con una usuario final utilizará la
amplia gama de dispositivos y tecnologías. También son necesarias aplicación Web con
técnicas de autor nuevas para ayudar a los desarrolladores, una independencia de los
negociación de contenido mejorada entre un agente de usuario y dispositivos, utilizando
servidores de contenido, es decir, es necesaria más información sobre una o varias modalidades
el contexto de envío (preferencias de los usuarios, características y (vista, sonido, teclado,
configuración de los dispositivos, contexto y entorno). voz, etc.). Según la
Este entorno genérico permite al agente de usuario, describir las configuración provista por
características del dispositivo, el contexto, y las preferencias del el usuario, el Controlador
usuario junto con las restricciones que sufre. presentará la Vista
56 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

correspondiente.
Ejemplo: si una aplicación de usuario soporta entradas de teclado y mouse, los usuarios deben
poder interactuar con toda la presentación utilizando cualquier teclado o mouse. Ver Ejemplo Punto
de verificación 6.4.
Punto de Verificación: 9.3 Para los "scripts", especifique manejadores de eventos lógicos
en vez de manejadores de evento dependientes de dispositivos. [Prioridad 2]
Prescripción Mapeo
Ver punto de verificación 6.4. Ver punto de verificación
6.4.
Ejemplo: ver punto de verificación 6.4.
Punto de Verificación: 9.4 Cree un orden lógico para navegar con el tabulador a través
de vínculos, controles de formulario y objetos. [Prioridad 3]
9.5 Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los
mapas de imagen de cliente), los controles de formulario y los grupos de controles de
formulario. [Prioridad 3]
Prescripción Mapeo
La navegación consiste en el modo en el que podemos recorrer las Clases de Presentación,
páginas de la aplicación. Para establecer un orden lógico de Diálogo y Pragmática -
navegación se debe estructurar y organizar el sitio Web con el objetivo Componentes Vista y
de que los usuarios puedan navegar por las páginas de la manera más Controlador:
sencilla e intuitiva posible. Siempre debe jugar a favor de la Los diseñadores de la
navegación, la facilidad de uso, la funcionalidad y objetivos a lograr aplicación analizarán la
por el sitio, de manera que la experiencia del usuario en él sea manera en que los
positiva. usuarios potenciales
Hay varias maneras de dirigir el foco hacia un elemento: usarán la aplicación para
• Designar el elemento con un dispositivo apuntador. definir la secuencia lógica
• Navegar de un elemento a otro con el teclado. de navegación y
• Seleccionar un elemento por medio de una tecla de acceso. establecer la combinación
de teclas de acceso. El
usuario será quien a través
de la navegación, definirá
las acciones a seguir,
utilizando como medios
físicos el teclado o algún
dispositivo de
apuntalamiento como un
mouse, lápiz óptico etc.
Ejemplo: en HTML [30] el atributo “tabindex” permite especificar la posición del elemento actual
dentro del orden de tabulación del documento actual. Este valor debe ser un número entre 0 y
32767. La navegación se produce desde el elemento con menor valor de “tabindex” hasta el
elemento con el valor más alto. Si hay elementos que tengan valores idénticos de “tabindex” debería
navegarse por ellos según el orden en que aparezcan en el flujo de caracteres.
Otra manera de dirigir el foco hacia un elemento de interacción en HTML [30] es a través de teclas
de acceso o atajos del teclado. El atributo “accesskey” permite asignar una tecla de acceso a un
elemento.

PAUTA 10. UTILICE SOLUCIONES PROVISIONALES

Punto de Verificación: 10.1 Hasta que las aplicaciones de usuario permitan desconectar
la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y
no cambie la ventana actual sin informar al usuario. [Prioridad 2]
Prescripción Mapeo
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 57

Las apariciones repentinas de nuevas ventanas o cambios en la ventana Clases Presentación y

actual, deben ser previamente informadas al usuario. Para un usuario Diálogo - Componentes
vidente, puede ser difícil percibir que se ha abierto una nueva ventana Vista y Controlador: Debe
y tener dificultades para navegar por ella como una continuación de lo haber un intercambio de
que hacía hasta ese momento. Para quienes usan tecnologías de apoyo, información con el
la apertura de una nueva ventana puede ser molesta y causar confusión, usuario alertándolo de los
ya que el comportamiento por defecto del vínculo se ha modificado. La cambios a realizarse y
aplicación de lenguajes de scripting por ejemplo, puede hacer dándole más tiempo en
imposible el cambio de tamaño o escala a aquellos que usan caso de que lo necesite, es
ampliadores de pantalla. decir dejar al usuario
decidir el momento de
hacerlo.
Ejemplo: en HTML [30], no especificar una nueva ventana como objetivo (target) de un enlace, es
decir no se debe usar con el atributo “target” el valor "_blank", sin especificar previamente al
usuario el cambio en la ventana actual o la apertura de una nueva ventana:
<A href="búsqueda.html" target="_blank">Lista de resultados
de la búsqueda realizada</A>
Punto de Verificación: 10.2 Hasta que las aplicaciones de usuario soporten
explícitamente la asociación entre control de formulario y etiqueta, para todos los
controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la
etiqueta está colocada adecuadamente. [Prioridad 2]
Prescripción Mapeo
En el caso de los controles que no tiene rótulos implícitos el Clase Presentación -
desarrollador de la aplicación debe especificarlos explícitamente. Al Componente Vista:
asociar cada control de un formulario a su rótulo correspondiente los A través de las
agentes de usuario, como sintetizadores de voz, leyendo la etiqueta asociaciones implícitas y
pueden interpretar la relación entre el control y el nombre, identificar explícitas de etiquetas a
el tipo de elemento de formulario que está seleccionado en ese sus respectivos controles,
momento y proporcionar los medios para completar, seleccionar, des- el diseñador de la
seleccionar o presentar ese elemento de formulario. Más aún, los aplicación incorpora
controles de tipo checkbox, por ejemplo, pueden tomar el foco al dar información semántica,
un click sobre cualquier parte del texto, sin necesidad de que el click que será de mayor
sea realizado sobre el pequeño cuadrado del chek. importancia para usuarios
que utilicen softwares
especiales para navegar
por la aplicación Web, y
probablemente de menor
relevancia para usuarios
sin discapacidades
visuales o cognitivas.
Ejemplo: en HTML [30] el elemento <LABEL> se utiliza para especificar rótulos de controles que
no tienen rótulos implícitos:
<FORM method="post" action="">
<P><LABEL for="nombre">Nombre
<INPUT id="nombre" type="text" name="text1" size="12" />
</LABEL></P>
Cada elemento LABEL se asocia exactamente con un control de formulario. Con el atributo “id” del
elemento INPUT se marcar el correspondiente identificador del campo (que puede tener el mismo
valor que el atributo “name”) y, después se indica en el atributo “for” de el identificador del campo
al que se asocia.
Punto de Verificación: 10.3 Hasta que las aplicaciones de usuario (incluidas las ayudas
técnicas) interpreten correctamente los textos contiguos, proporcione un texto lineal
alternativo (en la página actual o en alguna otra) para todas las tablas que maquetan
58 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

texto en paralelo, columnas envoltorio de palabras. [Prioridad 3]

Prescripción Mapeo
Las tablas utilizadas para maquetar páginas, que contienen celdas en Clase Presentación -
las que el texto se extiende a través de más de una línea, es decir, Componente Vista:
maquetean texto en paralelo, presentan problemas para los lectores de El diseñador de la
pantalla antiguos, que no interpretan columna por columna, sino que aplicación incorpora
hacen una lectura lineal, o para los navegadores Web, que no permiten información semántica,
la navegación dentro de celdas individuales de tablas. que será de mayor
importancia para usuarios
Por ejemplo, ante la siguiente tabla mostrada por pantalla:
que utilicen softwares
Hay un 30% de Las clases de la especiales para navegar
posibilidades de que Universidad de por la aplicación Web, y
llueva esta mañana, Wisconsin se probablemente de menor
pero debería parar reanudarán el 3 de relevancia para usuarios
antes del fin de septiembre. sin discapacidades
semana. visuales o cognitivas.

El lector de pantalla podría interpretarla de la siguiente manera:

Hay un 30% de posibilidades de que las clases
de la Universidad de Wisconsin se llueva esta
mañana, pero reanudarán el 3 de septiembre.
debería parar antes del fin de semana.
Los diseñadores de la aplicación deben proporcionar un texto lineal
alternativo a la tabla maqueteada, hasta que las aplicaciones puedan
realizar correctamente la interpretación de la misma, o proporcionar
una versión lineal de la tabla, por ejemplo basándose en las filas,
empezando con el encabezado de la fila, y precediendo cada celda con
el encabezado de columna de la celda.
Ejemplo: en HTML [30] se puede especificar un orden de recorrido de las columnas con el
atributo “dir”. Los valores del atributo pueden ser ltr=left to right (de izquierda a derecha) o rtl=right
to left (de derecha a izquierda).
<TH dir= "rtl" >primer elemento .1</TH>
<TH dir= "rtl" >segundo elemento .2</TH>
<TH dir= "rtl" >tercer elemento .3</TH>
Punto de Verificación: 10.4 Hasta que las aplicaciones de usuario manejen
correctamente los controles vacíos, incluya caracteres por defecto en los cuadros de
edición y áreas de texto. [Prioridad 3]
Prescripción Mapeo
Ver punto de verificación
Cada control tiene un valor inicial y un valor actual, ambos cadenas de
10.2
caracteres. En general, el "valor inicial" puede especificarse con el
atributo “value” del elemento de control. Sin embargo, para algunos
controles, por ejemplo el elemento TEXTAREA en HTML [30], el
valor inicial viene dado por su contenido. Si estos controles no
disponen de valores iniciales, las aplicaciones de usuario no tienen
texto inicialmente para representar, presentándose una dificultad a la
hora de intentar poner el foco sobre estos controles vacíos. Al no
disponer de un valor inicial, pueden no notarse bien los bordes de estos
campos, evitando que los usuarios puedan independizarse del medio o
dispositivo de acceso.
La presente pauta establece que para los controles vacíos de una página
Web se establezcan caracteres por defecto, de manera de que los
controles siempre contengan valores iniciales.
Ejemplo: agregar a los controles un rótulo o etiqueta <LABEL> Ver punto de verificación 10.2
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 59

Punto de Verificación: 10.5 Hasta que las aplicaciones de usuario (incluidas las ayudas
técnicas) interpreten claramente los vínculos contiguos, incluya caracteres imprimibles
(rodeados de espacios), que no sirvan como vínculo, entre los vínculos contiguos.
[Prioridad 3]
Prescripción Mapeo
Vínculos agrupados lógicamente, como las barras de navegación, por Clases de Diálogo y
ejemplo, son normalmente lo primero que el usuario encuentra en una Presentación -
página. Para usuarios con sintetizador de voz, la navegación implicaría Componentes Vista y
tener que escuchar una serie de vínculos antes de llegar a los Controlador:
contenidos interesantes de la página Cuando los vínculos se agrupan en La incorporación del
conjuntos lógicos, estos deberían estar etiquetados como una unidad, vínculo al inicio, o la
permitiendo a los usuarios con softwares especiales, saltar el grupo de agrupación de los
vínculos (tal y como hacen los usuarios videntes cuando ven el mismo vínculos, permitirán al
comienzo en cada página). Para lograrlo los diseñadores de las usuario elegir diferentes
aplicaciones pueden: caminos alternativos de
• Incluir un vínculo que permita al usuario saltar sobre el navegación, evitando una
conjunto de vínculos de navegación. navegación secuencial,
• Proporcionar una hoja de estilo que permita a los usuarios permitiéndolo saltar la
ocultar el conjunto de vínculos de navegación. información que ya
• Agrupar los vínculos e incluir caracteres imprimibles para conoce Así mismo, la
impedir que los lectores de pantalla viejos lean los enlaces presentación de la
adyacentes como un único enlace. aplicación también se
verá afectada por la
incorporación de estas
mejoras, permitiendo los
caracteres imprimibles
entre los enlaces dar una
distinción visual que
pueda ayudar a los
usuarios a diferenciar los
enlaces a simple vista.
Ejemplo: para agrupar vínculos, HTML 4.01 [30] provee el elemento MAP. Los vínculos están
separados por corchetes ([]) para impedir que los lectores de pantalla antiguos lean vínculos
adyacentes como si fueran un solo vínculo.
<MAP title="Barra de navegación">
[ <A href="#salto">Saltar Barra de navegación</A ]
[ <A href="prueba1.html">Sección 1</A ]
[ <A href="prueba2.html">Sección 2</A ]
[ <A href="prueba3.html">Sección 3</A ]
[ <A href="prueba4.html">Sección 4</A ]
[ <A href="prueba5.html">Sección 5</A ]
</MAP
<H1><A name="salto">Título del texto del sitio
</A></H1>

PAUTA 11. UTILICE LAS TECNOLOGÍAS Y PAUTAS W3C

Punto de Verificación: 11.1 Utilice tecnologías W3C cuando estén disponibles y sean
apropiadas para la tarea y use las últimas versiones que sean soportadas [Prioridad 2]
Prescripción Mapeo
La presente pauta sugiere, donde sea posible, la utilización de Clases de Diálogo,
tecnologías W3C (de acuerdo con las especificaciones), por varias Presentación y Pragmática
razones: - Componentes Vista y
Controlador.
60 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

• Las tecnologías W3C incluyen características “accesibles”

incorporadas.
• Las especificaciones W3C pronto serán revisadas para
asegurar que los temas de Accesibilidad se toman en
consideración en la fase de diseño.
• Las especificaciones W3C están desarrolladas en un proceso
abierto de laborioso consenso.

Ejemplo: Todos los ejemplos mencionados en la presente guía.

Punto de Verificación: 11.2 Evite características desaconsejadas por las tecnologías
W3C. [Prioridad 2]
Prescripción Mapeo
Los diseñadores deberían evitar el uso de versiones de lenguajes Clases de Diálogo,
estándares que podrían estar obsoletas o formatos y características no Presentación y Pragmática
estándar (elementos, atributos, propiedades y extensiones patentadas), - Componentes Vista y
haciendo las aplicaciones “accesibles” a usuarios que utilizan una Controlador.
amplia variedad de hardware y software. En caso de que se deba
utilizar tecnologías no accesibles, se debe proporcionar una página
equivalente “accesible”.
Ejemplo: en HTML 4.0 el elemento FONT ya no se usa más. En su lugar, para dar formatos de
fuente se deberían usar hojas de estilo CSS1 [28]. Ver punto de verificación 3.3.
Punto de Verificación: 11.3 Proporcione la información de modo que los usuarios
puedan recibir los documentos según sus preferencias (Por ejemplo, idioma, tipo de
contenido, etc.) [Prioridad 3]
Prescripción Mapeo
Proporcionar la información necesaria para que el usuario pueda Clases de Diálogo,
seleccionar el idioma, tipo o formato del recurso, características del Presentación y Pragmática
software utilizadas para el acceso, etc., con la finalidad de que reciba el - Componentes Vista y
contenido según sus preferencias. Controlador:
Los diseñadores de las aplicaciones podrán: El usuario podrá decidir,
según sus preferencias,
• Incluir vínculos a otras versiones del contenido ofrecido, por como recibir la
ejemplo en diferentes idiomas. información de la
• Usar negociación del contenido para proveer al usuario del aplicación. Dependido de
contenido que solicita, por ejemplo según el idioma que lo la información ingresada
representa. por el usuario, el
• Indicar tanto el tipo de contenido como el idioma en la Controlador invocará los
información cuando se disponga de estos datos. cambios en la Vista,
modificando la
presentación de la
aplicación Web.
Ejemplo: en HTML [30] también, el atributo “hreflang” del elemento <A>, indica el idioma con
que el usuario se va a encontrar si sigue el link. Por ejemplo: en para inglés fr para frances, es-ar
para español argentino, etc. El tributo title ayuda a describir mejor el destino del enlace que lo
contiene.
<A href="http://www.ietf.org/rfc/rfc1766.txt" hreflang="en"
title="Request for Comments 1766">RFC1766</A>
CSS2 [29] por ejemplo, dispone de propiedades que pueden ser utilizadas por los usuarios para
diseñar sus propias hojas de estilo e indicar al agente de usuario como debe ser mostrado el
contenido auditivo.
• “volumen” controla el volumen del texto hablado.
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 61

• “speak” determina si el contenido se anunciará y, en caso afirmativo, si se debe deletrear o

leer como palabras.
• “pause”, “pause-before”, y “pause-after” controla las pausas antes y después de anunciar el
contenido. Permite a los usuarios separar los contenidos para mejorar la comprensión.
• “cue”, “cue-before”, y “cue-after” especifican un sonido que se reproducirá antes y después
del contenido, lo que puede ser valioso para la orientación (parecido a una imagen visual).
• “play-during” controla los sonidos de fondo durante la presentación del elemento
(parecido a una imagen de fondo).
• “azimuTH” y “elevation” proporcionan una dimensión al sonido, lo que permite a los
usuarios distinguir las voces, por ejemplo
• “speech-rate”, “voice-family”, “pitch”, “pitch-range”, “stress”, y “richness” controlan las
cualidades de los contenidos hablados.
Punto de Verificación: 11.4 Si, después de los mayores esfuerzos, no puede crear una
página accesible, proporcione un vínculo a una página alternativa que use tecnologías
W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan
a menudo como la página (original) inaccesible. [Prioridad 1]
Prescripción Mapeo
Si al hacer uso de las Tecnologías W3C, los diseñadores de las Ver puntos de
aplicaciones Web, no obtienen una transformación correcta de sus verificación 6.5 y 13.9
páginas Web, deberán proponer páginas alternativas con contenido que
sea “accesible”. Las páginas alternativas deben implementarse solo
cuando otras soluciones fallen, una vez que se haya reconsiderado el
diseño de la página original, debido a que por lo general, las páginas
alternativas se actualizan con menor frecuencia que las páginas
primarias.
Ejemplo: ver puntos de verificación 6.5 y 13.9

PAUTA 12. PROPORCIONE INFORMACIÓN DE CONTEXTO Y ORIENTACIÓN

Punto de Verificación: 12.1 Titule cada frame para facilitar su identificación y
navegación de los mismos. [Prioridad 1]
12.2 Describa el propósito de los frames y como éstos se relacionan entre sí, si no resulta
obvio solamente con el título del frame. [Prioridad 2]
Prescripción Mapeo
Para los usuarios invidentes, las relaciones entre el contenido de los Clases de Presentación y
diferentes frames que existen en la página de una aplicación Web, (por Diálogo - Componentes
ejemplo, cuando un frame contiene el índice y otro el contenido Vista y Controlador:
principal) debe transmitirse al usuario final de una manera no visual. La incorporación de
Los diseñadores de las aplicaciones deben informar el título y información semántica
propósito de los frames explícitamente, para que los usuarios conozcan acerca del título y
la semántica de cada frame y la relación que existe entre ellos. propósito de cada frame,
cambia el diálogo original
establecido entre los
usuarios que utilizan
softwares especializados
como lectores de pantalla
y la aplicación. Estos
usuarios disponen
entonces de información
que les permita elegir
sobre qué frame navegar
primero.
62 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

Ejemplo: en HTML [30] los elementos FRAME, IFRAME y FRAMESET disponen de los
atributos <title> y <longdesc> para proveer el nombre y relación entre frames:
• <title> para proporcionar el título de cada frame.
• <longdesc> para proporcionar la dirección en la que puede encontrarse una descripción
larga del contenido del frame.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
<HEAD>
<TITLE>Las noticias de hoy</TITLE>
</HEAD>
<FRAMESET cols="10%,*,10%">
<FRAMESET rows="20%,*">
<FRAME src="promo.html" name="promo" title="promociones">
<FRAME src="barranavega.html" name="barranavega"
title="Barra de navegación global del sitio"
longdesc="frameset-desc.html#barranavega">
</FRAMESET>
<FRAME src="historia.html" name="noticia"
title="Noticia seleccionada - contenido principal"
longdesc="frameset-desc.html#noticia">
<FRAMESET rows="*,20%">
<FRAME src="titulares.html" name="indice"
title="Índice de otros titulares nacionales"
longdesc="frameset-desc.html#titulares">
<FRAME src="anuncio.html" name="espacioanuncio"
title="Publicidad">
</FRAMESET>
Por ejemplo, el texto contenido en la página frameset-desc.html puede ser el siguiente:
#barranavega - este frame contiene vínculos a las secciones
más importantes de este sitio: Noticias del mundo, Noticias
nacionales, Noticias locales, Noticias tecnología, y Noticias
del ocio.
#noticia - este frame contiene la historia actualmente
seleccionada.
#indice - este frame contiene vínculos a las noticias
principales de hoy dentro de esta sección.
Punto de Verificación: 12.3 Divida los bloques largos de información en grupos más
manejables cuando sea natural y apropiado. [Prioridad 2]
Prescripción Mapeo
Los diseñadores de diálogo de la aplicación Web, no deben crear Clases de Diálogo y
grupos de información de forma aleatoria, puesto que pueden Presentación -
confundir a los usuarios, por lo contrario, deberían utilizar mecanismos Componentes Vista y
de agrupación cuando sean apropiados y naturales, por ejemplo, Controlador:
cuando la información se dé en grupos lógicos, y proporcionar El agrupamiento de la
información de contexto y orientativa sobre la relación entre información incorpora
elementos. semántica a la aplicación
que les permite a los
usuarios entender su
propósito y al mismo
tiempo les facilita la
navegación con agentes
de usuario visuales y
agentes de usuario
basados en voz. Los
navegadores muestran de
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 63
forma destacada el título
de cada agrupación, de
forma que el usuario
pueda localizar más
fácilmente la información
deseada.
Ejemplo: en HTML [30]:
• El elemento FIELDSET (grupo de campos) permite agrupar temáticamente controles y
rótulos relacionados. El elemento LEGEND permite asignar un título a un FIELDSET.
<FORM action="..." meTHod="post">
<P>
<FIELDSET>
<LEGEND>Información Personal</LEGEND>
Apellido: <INPUT name="personal_apellido" type="text"
tabindex="1">
Nombre: <INPUT name="personal_nombre" type="text"
tabindex="2">
Dirección: <INPUT name="personal_dirección" type="text"
tabindex="3">
...más información personal...
</FIELDSET>
• El elemento OPTGROUP permite agrupar opciones relacionadas dentro de una lista
desplegable en grupos más pequeños. A través de su atributo “label” se puede indicar el
nombre de cada agrupación.
<FORM id="formulario" meTHod="post" action="">
<LABEL for="programa">Programa seleccionado</LABEL> <BR/>
<SELECT id="programa" name="programa">
<OPTGROUP label="Sistemas Operativos">
<OPTION value="Windows" selected="selected">Windows</
OPTION>
<OPTION value="Mac">Mac</ OPTION>
<OPTION value="Linux">Linux</ OPTION>
<OPTION value="OTHer">Otro</ OPTION>
</OPTGROUP>
• Los elementos THEAD, TBODY, TFOOT y COLGROUP permiten agrupar filas y
columnas de una tabla. Ver punto de verificación 5.2.
• Los elementos UL, OL y DL permiten anidar los ítems de las listas estructuralmente. Ver
punto de verificación 3.6
• Los elementos de encabezado (H1 - H6) permiten especificar la estructura lógica de los
documentos y separar tramos largos de texto. Ver punto de verificación 3.5.
Punto de Verificación: 12.4 Asocie explícitamente las etiquetas con sus controles.
[Prioridad 2]
Prescripción Mapeo
Ver punto de verificación 10.2 Ver punto de verificación
10.2
Ejemplo: Ver punto de verificación 10.2

PAUTA 13. PROPORCIONE MECANISMOS CLAROS DE NAVEGACIÓN

Punto de Verificación: 13.1 Identifique claramente el objetivo de cada vínculo.
[Prioridad 2]
Prescripción Mapeo
Un buen texto para un vínculo debería indicar la naturaleza del Clases Presentación y
64 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

objetivo del vínculo. El texto no debería ser demasiado general; ni Diálogo - Componentes
tampoco frases como “pinche aquí”, ya que no sólo es específica a un Vista y Controlador:
dispositivo (dispositivo de apuntamiento) sino que no indica nada Indicar claramente en el
acerca de lo que se encontrará si se sigue el vínculo. Si hay más de un título del vínculo es una
vínculo en una página con el mismo texto, todos estos vínculos deben incorporación semántica
remitir al mismo recurso. Si dos o más vínculos van referidos a significativa, sobre todo
objetivos diferentes pero comparten el mismo texto, se deberían para usuarios con
distinguir especificando un valor diferente para su título. dificultades cognitivas o
usuarios que no estén
familiarizados con el uso
de estas herramientas.
Esta información puede
ser determinante en la
navegación por la
aplicación Web, y la
determinación de las
acciones a realizar. Según
los eventos invocados por
el usuario, el Controlador
invocará los cambios en la
Vista de la Presentación.
Ejemplo: en HTML [30], tanto la etiqueta <A> como <LINK> disponen del “title” que permite
añadir información sobre la naturaleza de un vínculo. Ver punto de verificación 6.2 y 11.3
Punto de Verificación: 13.2 Proporcione metadatos para añadir información semántica a
las páginas y sitios. [Prioridad 2]
Prescripción Mapeo
Los desarrolladores de las aplicaciones Web deben utilizar metadatos Clases Presentación,
para añadir información semántica a las páginas y sitios. Los Diálogo y Pragmática -
metadatos de tipo descriptivos permiten a los usuarios descubrir Componentes Vista y
recursos (por ejemplo, búsqueda en la Web para encontrar colecciones Controlador:
digitalizadas sobre medio ambiente), los tipo estructurales facilitan la Los metadatos aportan
navegación, presentación de recursos electrónicos y proporcionan más información
información sobre la estructura interna de los recursos, incluyendo semántica para ser
página, sección, capítulo, numeración, índices, y tabla de contenidos; intercambiada entre el
por último los tipo administrativo facilitan la gestión y procesamiento usuario y la aplicación.
de las colecciones digitales tanto a corto como a largo plazo, incluyen Agentes de software tales
datos técnicos sobre la creación y el control de calidad; incluyen como sintetizadores de
gestión de derechos y requisitos de control de acceso y utilización. voz, dispositivos braile,
etc., pueden, a través de la
interpretación de la
metainformación
determinar el software,
hardware u otro
equipamiento necesario
para ejecutar u operar un
recurso, mejorar los
elementos de
presentación, por ejemplo
aplicando reglas de
pronunciación
dependientes del idioma
establecido, etc.
Ejemplo: en HTML [30] las maneras de incorporar metadatos a las páginas Web serían:
• A través del elemento <META>, incrustando los metadatos dentro del propio documento,
al mismo tiempo que este es creado. Generalmente embebidos y codificados en la cabecera
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 65
del documento.
<HEAD profile="http://www.acme.com/profiles/core">
<TITLE>Buscador Web</TITLE>
<META name="author" content="José Pérez">
<META name="copyright" content="&copy; 1997 Acme Corp.">
<!-- Para hablantes de inglés británico -->
<META name="keywords" lang="en"
content="advanced, standart, instructions">
<!-- Para hablantes de español -->
<META name="keywords" lang="es"
content="avanzada, estandar, instrucciones">
<META name="date" content="1994-11-06T08:49:37+00:00">
</HEAD>
• A través de otros elementos y atributos más específicos, como por ejemplo los elementos
<TITLE>, <ADDRESS>, <INS> y <DEL>, los atributos “title” y “cite”. También
incorporados en el propio documento.
• A través del elemento LINK, asociándolos por medio de archivos acoplados a los recursos
a los que describen. De esta manera pueden ser cambiados los metadatos sin cambiar el
contenido del recurso en sí mismo, y persisten aunque el documento ya no esté “accesible”.
<LINK rel="DC.identifier" type="text/plain"
href="http://www.ietf.org/rfc/rfc1866.txt">
Punto de Verificación: 13.3 Proporcione información sobre la maquetación general de
un sitio (por ejemplo, mapa del sitio o tabla de contenidos). [Prioridad 2]
Prescripción Mapeo
Ofrecer una visión global de la organización o estructuración de la Clases de Presentación,
información del sitio Web, para que el usuario pueda localizar lo que Diálogo y Pragmática -
busca de la forma más fácil, clara e intuitiva posible, dejándole la Componentes Vista y
elección del modo de acceder, más cómodo y adecuado para los fines Controlador:
que persigue. Una posible implementación es un mapa del sitio Web o La información de la
una tabla de contenido con las principales secciones ya desde la página maquetación general del
principal, o en otra página adicional que esté fácilmente “accesible”, sitio provee al usuario un
titulándola Mapa de Navegación, alto contenido semántico
Otra manera es emplear las llamadas fish-eye views o mapas ojo de pez a través del cual puede
que muestran todo el espacio hipertextual en un único gráfico en conocer los contenidos o
distintos niveles de detalle, ofreciendo más información sobre la conceptos incluidos en la
posición actual en la que se encuentra el usuario y disminuyendo los aplicación y determinar la
detalles de forma gradual según estén más alejadas las partes. Otras forma de acceder a ellos
opciones son los mapas táctiles o mapas sensibles, como animaciones para localizar lo que
o applets de Java para que los gráficos cambien de color al situar el busca. Dependiendo de
cursor sobre ellos. las acciones realizadas
por el usuario, se realizará
el intercambio de
información con este, y el
Controlador será quien
actualice las vistas.
Ejemplo: ver punto de verificación 3.6 y pauta 5.
Punto de Verificación: 13.4 Utilice los mecanismos de navegación de forma coherente.
[Prioridad 2]
13.5 Proporcione barras de navegación para destacar y dar acceso al mecanismo de
navegación. [Prioridad 3]
Prescripción Mapeo
Los diseñadores deberán proveer un sistema de navegación que Clases de Presentación,
posibilite una navegación simple, intuitiva, consistente, transparente y Diálogo y Pragmática -
flexible. Un estilo de presentación coherente entre las páginas Componentes Vista y
66 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

permitirá a los usuarios localizar los mecanismos de navegación más Controlador:

fácilmente, así como también “saltarlos” más rápidamente para Incorporar las
encontrar los contenidos más importantes. Conviene entonces que las herramientas de
barras de navegación sean fácilmente reconocibles, que dispongan de navegación mencionadas,
un ordenamiento claro de la información y que se encuentren aportarán al usuario un
preferiblemente en un mismo lugar y con una sola estética a lo largo alto contenido semántico
del sitio. También se debe tener en cuenta la cantidad de ítems o a través del cual podrá
categorías/secciones principales que contendría la barra. Es conocer los contenidos o
recomendable que sean pocas y concisas, si el sitio es muy grande, conceptos incluidos en la
mejor presentar las categorías principales y que éstas sean lógicos aplicación y determinar la
contenedores de subcategorías/subsecciones que puedan llegar a forma de acceder a ellos
presentarse. Estas decisiones ayudarán a las personas con discapacidad para localizar lo que
para el aprendizaje y la lectura, pero también facilitarán la navegación busca. Dependiendo de
a todos los usuarios. Se pueden elaborar un gran número de las acciones realizadas
herramientas que ayuden a la navegación y la hagan comprensible: en por el usuario, se realizará
forma de botones, barras de navegación, uso de metáforas, mapas el intercambio de
sensibles, FAQ o Preguntas más frecuentes (Frequently Asked información con este, y el
Question) entre otras. Todas estas herramientas son imprescindibles si Controlador será quien
se trata de aplicaciones grandes y complejas en las que el peligro de actualice las vistas.
pérdida del contexto aumenta cuando el usuario se aleja de la página
principal y se adentra por las ramas inferiores de una estructura
profunda o demasiado amplia.
Ejemplo: ver puntos de verificación 3.3, 6.5, 13.9 y Pauta 5.
Punto de Verificación: 13.6 Agrupe los vínculos relacionados, identifique el grupo (para
las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan,
proporcione una manera de evitar el grupo. [Prioridad 3]
Prescripción Mapeo
Ver punto de verificación 10.5. Ver punto de verificación
10.5.
Ejemplo: ver punto de verificación 10.5.
Punto de Verificación: 13.7 Si proporciona funciones de búsqueda, permita diferentes
tipos de búsquedas para diversos niveles de habilidad y preferencias. [Prioridad 3]
Prescripción Mapeo
Para paliar o resolver el problema del desbordamiento cognitivo, se Clases de Presentación y
deberá organizar la información de tal manera que el usuario pueda Diálogo - Componentes
recuperar la información más relevante o precisa por medio de Vista y Controlador:
búsquedas o consultas. Las herramientas de búsqueda deberán ofrecer Incorporar diferentes tipos
mecanismos que satisfagan diferentes niveles de habilidad y de búsquedas para
preferencias. La mayoría de los buscadores piden al usuario que diversos niveles de
introduzca palabras clave para buscar términos. Los usuarios con habilidad y preferencias,
dificultades para deletrear o los no familiarizados con el idioma del proveerán al usuario de un
sitio, tendrán dificultades para encontrar lo que necesitan si la alto contenido semántico
búsqueda requiere una ortografía perfecta. Los mecanismos de a través del cual podrán
búsqueda deberán incluir un revisor de ortografía, ofrecer alternativas acceder a los contenidos
de "la mejor opción", búsquedas mediante preguntas, búsquedas por incluidos en la aplicación
similitud, ofrecer información sobre cómo ampliar las posibilidades de y determinar la forma de
la búsqueda por en caso de que la búsqueda resultara nula, ofrecer acceder a ellos para
interfaces de búsqueda en todas las páginas del sitio (preferentemente localizar lo que busca.
con la misma ubicación y el mismo estilo, para que el usuario pueda Dependiendo de las
ubicarla en todas las páginas), etc. acciones realizadas por el
usuario, se realizará el
intercambio de
información con este, y
dependiendo del diálogo
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 67
establecido, el
componente Controlador
será quien actualice las
diferentes vistas.
Ejemplo: existen múltiples formas de permitir diferentes tipos de búsqueda con el uso de la
tecnología W3C a través de links, applets, scripts, etc.
Punto de Verificación: 13.8 Localice al principio de los encabezamientos, párrafos,
listas, etc., la información que los diferencie. [Prioridad 3]
Prescripción Mapeo
Ubicar al comienzo de los títulos, párrafos, listas, etc., las palabras, Clases de Presentación y
títulos o contenidos más importantes, de manera de que sean útiles Diálogo - Componentes
para describir la información que contienen, es decir, que orienten al Vista y Controlador:
usuario para que evalúe si le sirve o no leer el artículo. Esta técnica es Definir la manera de
comúnmente denominada front-loading (colocar al frente). Situar el presentar y ubicar los
contenido básico al principio de la frase o párrafo ayudará tanto a la conceptos principales, en
gente que está observando superficialmente la aplicación, como a los los encabezamientos,
que usan dispositivos seriales como un sintetizador de voz. “Observar listas, etc., de manera tal
superficialmente la aplicación”, aplicado a la voz, significa de que la primer
habitualmente que el usuario salta de encabezamiento a información
encabezamiento, o de párrafo a párrafo, y escucha sólo las palabras intercambiada entre la
suficientes como para establecer si el fragmento de información aplicación y el usuario sea
(encabezamiento, párrafo, vínculo, etc.) le interesa. Si la idea principal la más importante y le de
del párrafo se encuentra en el medio o al final del mismo, los usuarios a este una idea global del
con sintetizadores de voz tendrán que escuchar casi todo el documento contenido, determinará la
para encontrar lo información que buscan. forma en que se
intercambiará la
información con el
usuario y como será la
Vista de la aplicación.
Ejemplo: en HTML [30] los elementos estructurales tales como títulos, subtítulos, párrafos, citas,
(H1 a H6, P y CITE) deben estén marcados correctamente. En el caso de una lista de enlaces, el
atributo “title” del elemento <A> permite incluir mayor información del contexto al cual nos lleva.
<a href="pagina1.html" title="Ir a la sección 1: Cómo
ingresar" >Sección 1</a>
Punto de Verificación: 13.9 Proporcione información sobre las colecciones de
documentos (por ejemplo, los documentos que comprendan múltiples páginas. [Prioridad
3]
Prescripción Mapeo
Cuando un documento se extiende por varias páginas, como en el caso Clases Presentación y
de un libro dividido en capítulos o un libro como parte de una Diálogo - Componentes
colección, los diseñadores de las aplicaciones Web, no pueden prever Vista y Controlador:
por qué parte ingresarán los usuarios a la misma, ya que no hay un Proveer información
único camino ni un solo hilo conductor de navegación y lectura. asociada a la colección de
Cuanto más explícitas sean las relaciones semánticas entre las distintas documentos facilitará que
unidades del texto, más se facilitará la navegación y comprensión del el usuario vaya de una
mismo. Los diseñadores de la aplicación deben agregar información al página o de un tema a
contenido de esta, para que sea presentada al usuario como un paquete otro, sin desviarse del
coherente, evitando así, entre otros, el problema principal de la ámbito de la colección, y
desorientación. También se debe ofrecer un alto grado de flexibilidad en caso de olvidar como
en la navegación con el fin de que el usuario pueda elegir el tipo de llegó hasta un punto, o
lectura que mejor se adapte a sus necesidades y objetivos. por qué ha accedido a
determinada información.
Será el usuario quien a
través de sus acciones
68 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

ingrese la información
para que el Controlador
actualice las vistas de la
aplicación.
Ejemplo: en HTML [30] el elemento <LINK> es usado como conector de las partes de una
colección de documentos. Los siguientes son sus principales atributos:
• Href: uri: tipos de vínculo [CT]: especifica la localización de un recurso de la Web,
definiendo así un vínculo entre el elemento actual (el origen del vínculo) y el destino del
vínculo definido por este atributo.
• Rel: tipos de vínculo [CI]: describe la relación entre el documento actual y el destino del
vínculo, especificado por el atributo “href”.
• Rev: tipos de vínculo [CI]: describe un vínculo inverso desde el origen del vínculo,
especificado por el atributo “href”, y el documento actual.
Dentro de los tipos de vínculos que pueden utilizar los diseñadores para proporcionar acceso a los
documentos asociados se detallan:
• Alternate: Designa una versión alternativa del documento en que aparece el vínculo.
• Stylesheet: Se refiere a una hoja de estilo externa.
• Start: Se refiere al primer documento de un conjunto de documentos. Este tipo de vínculo
dice a los motores de búsqueda qué documento es considerado por el autor como el punto
de inicio de un conjunto.
• Next: Se refiere al siguiente documento en una secuencia lineal de documentos.
• Prev: Se refiere al documento anterior en una serie ordenada de documentos.
• Contents: Se refiere a un documento que sirve como tabla de contenidos.
• Index: Se refiere a un documento que proporciona un índice para el documento actual.
• Glossary: Se refiere a un documento que proporciona un glosario de términos que
pertenecen al documento actual.
• Copyright: Se refiere al aviso de copyright del documento actual.
• Chapter: Se refiere a un documento que actúa como capítulo en una colección de
documentos.
• Section: Se refiere a un documento que actúa como sección en una colección de
documentos.
• Subsection: Se refiere a un documento que actúa como subsección en una colección de
documentos.
• Appendix: Se refiere a un documento que actúa como apéndice en una colección de
documentos.
• Help: Se refiere a un documento que ofrece ayuda (más información, vínculos a otros
recursos informativos, etc.)
• Bookmark: Se refiere a una señal de lectura. Una señal de lectura (bookmark) es un vínculo
a un punto de entrada importante dentro de un documento extenso.
Comienzo del código <HEAD>
<LINK rel="index" href="index.html" />
<LINK rel="prev" href="doc1.html" />
<LINK rel="next" href="doc3.html" />
<LINK rel="copyright" href="copyright.html" />
<LINK rel="alternate" media="print" href="doc2-printer.html"
/>
<LINK rel="alternate" lang="en" href="doc-ingles.html" />
<LINK type="text/css" href="basic.css" media="screen" />
</HEAD>
Punto de Verificación: 13.10 Proporcione un medio para saltar sobre un dibujo ASCII
art de varias líneas. [Prioridad 3]
5.1 Herramienta para asistir al diseño, desarrollo e implementación de arquitecturas de
software accesibles 69

Prescripción Mapeo
Si los diseñadores deciden incorporar como objetos de presentación en Clases de Presentación,
sus aplicaciones Web, gráficos ASCII art, estas deberán proveer de un Diálogo y Pragmática -
“ancla” o enlace para poder ser saltados, y en caso que los dibujos Componentes Vista y
proporcionen información que enriquezca el contenido, se deberá Controlador:
agregar también un equivalente textual. Incorporar un medio para
saltar dibujos ASCII art,
proveerá de un orden de
lectura principal y otro
alternativo, en caso de
que el usuario “salte” al
navegar el gráfico.
Ejemplo: en HTML [30] mediante el elemento <A> se podrá crear un vínculo para saltar el dibujo
ASCII ART.
<A href="#salto">Saltar ASCII art</A>
,,
___( )___
/ \
/\/\/\||/\/\/\
^^
<A name="salto">Continua texto después del dibujo.</A>

PAUTA 14. ASEGÚRESE DE QUE LOS DOCUMENTOS SEAN CLAROS Y SIMPLES

Punto de Verificación: 14.1 Utilice el lenguaje apropiado más claro y simple para el
contenido de un sitio. [Prioridad 1]
Prescripción Mapeo
A la hora de redactar el contenido de una aplicación Web, los estilos de Clases Presentación y
redacción deben ayudar a hacer el contenido del sitio fácil de leer para Diálogo - Componentes
todos, especialmente para las personas con discapacidades para la Vista y Controlador:
lectura y/o cognitivas. Decisiones vinculadas a
cuales serán las unidades
Entre las sugerencias o aspectos a seguir en el diseño y redacción de
de información a
contenidos se podrían destacar:
intercambiar con el
• Seguir una estructura piramidal: la parte más importante del usuario, como serán
mensaje, el núcleo, debe ir al principio. Ver punto de estructuradas y en qué
verificación 13.8 secuencia serán
• Permitir una fácil exploración del contenido: el lector en intercambiadas. De estas
entornos Web, antes de empezar a leer, suele explorar decisiones dependerá el
visualmente el contenido para comprobar si le interesa. estilo diálogo y redacción
utilizados en la aplicación
• Un párrafo = una idea: cada párrafo es un objeto informativo.
Web.
Se deberían trasmitir ideas, mensajes... evitando párrafos
vacíos o varios mensajes en un mismo párrafo.
• Ser conciso y preciso: al lector no le gusta la pantalla como
medio de lectura.
• Utilización de descripciones claras y precisas para los
vínculos, que tengan sentido cuando se lean fuera del contexto
o como parte de una serie de vínculos (algunos usuarios
navegan saltando de vínculo a vínculo y leyendo sólo el texto
de estos).
• Vocabulario y lenguaje: se debería utilizar el mismo lenguaje
del usuario, no el de la empresa o institución. El vocabulario
debe ser sencillo y fácilmente comprensible. Evitar el uso de
argot, jergas y significados particulares de palabras comunes o
70 Capítulo 5 - Arquitectura de Software para Aplicaciones Web Accesibles

estructuras que no estén descriptas en el documento.

• Tono: cuanto más familiar y cercano (sin llegar a ser
irrespetuoso) sea el tono empleado, más fácil será que el
lector preste atención.

Ejemplo:
Punto de Verificación: 14.2 Complemente el texto con presentaciones gráficas o
auditivas cuando ello facilite la comprensión de la página. [Prioridad 3]
Prescripción Mapeo
Dependiendo del tipo de contenido de la aplicación Web, cierta Clases de Diálogo,
información es conveniente presentarla acompañada de gráficos o Presentación y Pragmática
sonidos que complementen el concepto. Información sobre procesos o - Componentes Vista y
procedimientos puede ser mejor interpretada y comprendida cuando es Controlador
explicada a través de animaciones, gráficos e infografías, una
traducción del texto puede ser acompañada con una presentación
animada en lenguaje de señas, o sonidos pre-grabados de música,
discursos hablados o efectos sonoros serían los indicados para el texto
de una presentación.
Ejemplo: Ver punto de verificación 1.3
Punto de Verificación: 14.3 Cree un estilo de presentación que sea coherente en todas las
páginas. [Prioridad 3]
Prescripción Mapeo
El estilo de presentación de la aplicación Web tiene una relación Clase Presentación -
directa con el aspecto visual de la misma. Es importante mantener una Componente Vista.
coherencia y estilo común entre todas las páginas de la aplicación Web
(posición de cada elemento, uso del tamaño y espacio ocupado,
utilización del contraste de color para discriminar y distribuir
información, uso de efectos tipográficos para enfatizar contenidos,
rotura de la simetría y uso de efectos de relieve / profundidad para
resaltar elementos, etc.) proporcionando una consistencia visual a toda
la aplicación. Para asegurar que esta coherencia se cumple, es útil que
el diseñador gráfico elabore un libro o guía de estilo que sirva de
documento referencia para todo el equipo de desarrollo. La utilización
de un número mínimo de hojas de estilo en el sitio, hojas de estilo
vinculadas en vez de estilos incrustados u hojas de estilo incrustadas,
también contribuirán a la coherencia visual de la aplicación.
Ejemplo: Ver pauta 2 y pauta 3
Capítulo 6
Caso de Estudio
A los efectos de poder llevar adelante una discusión sobre las ventajas de nuestro enfoque
(desarrollado en el Capítulo 5), mostramos en este Capítulo la instrumentación del Mapeo
como herramienta principal para asistir al diseño y desarrollo de la interfaz de usuario de una
aplicación Web (caso de estudio). El objetivo es obtener una interfaz que cumpla con las
características de Accesibilidad planteadas para dicho caso de estudio.

6.1 Implementación del enfoque propuesto en Aplicación

Web GIE.
Tal como se describe en el Capítulo 5, nuestro enfoque apuesta fuertemente a la etapa de
desarrollo de las interfaces de usuario proveyendo un instrumento que atiende
simultáneamente a los aspectos esenciales de diseño y de Accesibilidad. La fundamentación
de nuestro trabajo está basada en un Mapeo de las pautas de la WCAG 1.0 [34] a un
framework arquitectónico, que permite a los desarrolladores construir interfaces visualizando
el efecto que tendrán sus decisiones de diseño en el producto final.
Ahora bien, para no quedarnos sólo en la predica de las ventajas de nuestro enfoque,
mostramos su aplicación a un ejemplo usual al mundo de los negocios. Con el fenómeno de la
“globalización” la mayoría de las organizaciones en la actualidad llevan a cabo sus negocios
dentro de un esquema que normalmente se denomina inter-organizacional donde
organizaciones e individuos interactúan en la búsqueda y/o provisión de productos y
servicios. En este contexto, aplicamos nuestro trabajo a una empresa del medio, a la que por
confidencialidad llamaremos “Petróleo SA”. En esta organización, gran parte del diseño de
las aplicaciones corresponde a un modelo Web, sobre un estándar corporativo .NET16, en
donde los desarrollos están separados en distintas capas: la de datos, la de lógica de negocio y
la de presentación. Común a todos los equipos de desarrollo, la compañía cuenta con una
metodología de trabajo y guías que cubren los conceptos básicos de herramientas, estándares,
protocolos y servicios necesarios para desarrollar y ejecutar aplicaciones .NET [20].
Particularmente, existe un grupo de guías de buenas prácticas que persiguen como objetivo
proporcionar una recopilación de prescripciones a tener en cuenta para la realización de
interfaces de “calidad” de aplicaciones en el entorno Web; es decir interfaces que resulten
intuitivas, fáciles de usar y que permitan a los usuarios maximizar su eficiencia y efectividad
cuando las usan. Si bien estas guías abarcan un amplio conjunto de recomendaciones a tener
en cuenta, carecen en gran medida de las propiedades asociadas al diseño Web “accesible”.
Dadas las características de la empresa, pero fundamentalmente la de los usuarios de sus
aplicaciones: (i) edades, características físicas, cognitivas y de habla diferentes, (ii) gran

16 La Plataforma .NET [20] es la primera implementación que Microsoft hace de los estándares
necesarios para el desarrollo en múltiples capas: los webServices y el protocolo SOAP a los que se
añaden la experiencia de años en el estándar XML y potenciado por una ingente librería de clases
(llamada .NET FrameWork).
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 73

distribución geográfica (iii) condiciones de conectividad y de variedad de dispositivos

(notebooks, PDAs, celulares etc.), consideramos que Petróleo SA es un escenario ideal donde
nuestro enfoque puede contribuir de manera notable a la calidad de las aplicaciones
desarrolladas para el entorno Web. La aplicación seleccionada como nuestro caso de estudio,
denominada Gestor de Incidentes y Emisiones (GIE), administra la información asociada a
emisiones e incidentes medio ambientales ocurridos en instalaciones de la compañía, las
medidas tomadas y acciones llevadas a cabo, como así también sus respectivas
remediaciones. La disponibilidad de esta información tiene entre otros objetos informar a las
diferentes Autoridades (nacionales, provinciales y municipales), en determinados plazos de
tiempo, cumpliendo con las legislaciones establecidas vigentes. Actualmente esta aplicación
es usada en Petróleo SA para los países de Argentina y Brasil.
Fundamentado en este contexto de trabajo, el objetivo general que nos planteamos para el
caso de estudio, fue evaluar la Accesibilidad de la aplicación GIE, desde la perspectiva del
enfoque propuesto. Teniendo esta máxima en mente y considerando que la construcción de un
sistema interactivo, como GIE, implica un proceso cíclico de diseño, desarrollo y evaluación,
y que la realimentación que proporciona la evaluación sobre el diseño es fundamental para
refinar y pulir aspectos de Accesibilidad que son muy dependientes de los usuarios finales, es
que decidimos incorporar de manera evolutiva e incremental las propiedades de Accesibilidad
al diseño y construcción de la aplicación.

6.1.1 Desarrollo - Objetos de la Interfaz de Usuario de la

Aplicación Web GIE.
Como primera actividad sobre el caso de estudio, seleccionamos un subconjunto de puntos de
verificación de la WCAG 1.0 [14] que la aplicación GIE debía cumplir en primera instancia,
fundamentados en: (i) la necesidad de seleccionar una “arquitectura” y plantear un diseño
base para la interfaz de GIE, y (ii) el alto grado de uso de elementos etiquetas (labels) y
campos de texto (text fields) que la misma requiere. La Tabla 6.1 muestra como resultado de
este paso un resumen de los puntos de verificación seleccionados y su correspondiente Mapeo
en clases de decisión de diseño y componentes MVC [5]. Específicamente, las dos primeras
columnas en la Tabla 6.1 se corresponden con la lista de pautas y sus correspondientes puntos
de verificación de la WCAG 1.0 [14] y la tercera indica la clase de decisión y a través de ella
el componente MVC [5] a la que se corresponde el punto de verificación de la segunda
columna, concretando el Mapeo.
Como segunda actividad sobre el caso de estudio, y a partir de las decisiones de diseño, clases
y componentes mapeados para cada característica de Accesibilidad planteada en la Tabla 6.1,
elaboramos el Modelo de Clases de la Figura 6.1. En este Modelo no representamos todos los
conceptos de la interfaz, sino solo las clases, operaciones, atributos y relaciones necesarias
para aplicar el enfoque propuesto.
La Tabla 6.1 Mapeo utilizado como guía en el diseño de una de las interfaces de usuario de la aplicación
Web GIE.
Pauta Punto de Verificación Clase de Decisión de
Diseño
Componente MVC
Pauta 2: No se 2.1 Asegúrese que toda la información transmitida a Clase Presentación
base sólo en el través de los colores también esté disponible sin color, Componente Vista
color por ejemplo mediante el contexto o por marcadores.
Pauta 2 2.2 Asegúrese de que las combinaciones de los Clase Presentación
colores de fondo y primer plano tengan suficiente Componente Vista
contraste para que sean percibidas por personas con
deficiencias de percepción de color o en pantallas en
blanco y negro
74 Capítulo 6 - Caso de Estudio

Pauta 3: Utilice 3.3 Utilice hojas de estilo para controlar la Clase: Presentación
marcadores y maquetación y la presentación. Componentes: Vista y
hojas de estilo y Controlador
hágalo
apropiadamente
Pauta 3 3.4 Utilice unidades relativas en lugar de absolutas al Clase: Presentación
especificar los valores en los atributos de los Componente: Vista
marcadores de lenguaje y en los valores de las
propiedades de las hojas de estilo.
Pauta 4: 4.1 Identifique claramente los cambios en el idioma Clase Presentación
Identifique el del texto del documento y en cualquier texto Componente Vista
idioma usado. Use equivalente (Por ejemplo, leyendas).
marcadores que
faciliten la
pronunciación o
interpretación de
texto abreviado o
extranjero
Pauta 4 4.3 Identifique el idioma principal de un documento. Clase Presentación
Componente Vista
Pauta 6: 6.1 Organice el documento de forma que pueda ser Clase: Presentación
Asegúrese de que leído sin hoja de estilo. Por ejemplo, cuando un Componentes: Vista y
las páginas que documento HTML es interpretado sin asociarlo a una Controlador
incorporan nuevas hoja de estilo, tiene que ser posible leerlo.
tecnologías se
transformen
correctamente
Pauta 10: Utilice 10.2 Hasta que las aplicaciones de usuario soporten Clases: Presentación
soluciones explícitamente la asociación entre control de Componente: Vista
provisionales. formulario y etiqueta, para todos los controles de
formularios con etiquetas asociadas implícitamente,
asegúrese de que la etiqueta está colocada
adecuadamente.
Pauta 10 10.4 Hasta que las aplicaciones de usuario manejen Clases: Presentación
correctamente los controles vacíos, incluya caracteres Componente: Vista
por defecto en los cuadros de edición y áreas de texto.

Pauta 11: Utilice 11.3 Proporcione la información de modo que los Clases: Presentación ,
las tecnologías y usuarios puedan recibir los documentos según sus Diálogo y Pragmática-
pautas W3C preferencias (Por ejemplo, idioma, tipo de contenido, Componentes: Vista y
etc.) Controlador

Pauta 12: 12.4 Asocie explícitamente las etiquetas con sus Clases: Presentación
Proporcione controles. Componente: Vista
información de
contexto y
orientación
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 75

FIGURA 6.1: Modelo de Clases Interfaz de Usuario Aplicación GIE.

76 Capítulo 6 - Caso de Estudio

Para comenzar con nuestro diseño, utilizamos el patrón MVC [5], que nos permite separar el
modelo de las clases Vista y Controlador. Por sus características (detalladas en el Capítulo 3),
este patrón fue el seleccionado para direccionar arquitecturalmente la toma de las decisiones
de diseños en cumplimiento de cada una de las recomendaciones de la Tabla 6.1.
Para cumplimentar con los puntos de verificación 4.1 y 4.3 y dado que los países que
actualmente utilizan la aplicación GIE son Argentina y Brasil, consideramos necesario un
diagrama de clases que modelara la internacionalización de los textos asociados a las
etiquetas de la interfaz de usuario, lo que nos condujo a clasificarlos en dos subclases
diferentes: TextoCastellano y TextoPortugués. Así mismo, entendimos que un gran aporte
semántico para el programador era especializar la clase Vista en las clases
VistaExploradorPortugués y VistaExploradorCastellano, una por cada idioma en el que la
aplicación estará disponible, y la incorporación del patrón Abstrac Factory17 para la creación
de las mismas. El diseño obtenido permite que la aplicación sea compatible con el idioma de
preferencia del usuario, especificado por ejemplo, en el programa cliente, Internet Explorer
en este caso. La subclasificación en el modelo de la clase Vista, sin lugar a dudas aporta a la
flexibilidad, claridad y facilidad para incorporar ágilmente en futuros prototipos de la
aplicación, una nueva subclase de Vista, por cada agente de usuario que se utilice al acceder a
la aplicación, dada la característica inter-organizacional distribuida que tiene la compañía.
Así mismo, para cumplir con los puntos de verificación 6.1 y 3.3 se adicionaron al diagrama
las clases EstiloPermitidoEnHoja, Color, EstiloFuente, EstiloTexto, y Posicionamiento, junto
a los atributos necesarios que permiten definir las características visuales o de “estética” de
los elementos de la interfaz de usuario, como por ejemplo las etiquetas. Específicamente en
relación al punto de verificación 6.1, se decidió realizar una especificación entre las clases
EstiloPermitidoEnHoja, Posicionamiento y la asociación entre esta última y la clase Vista, de
manera de incorporar las restricciones necesarias a nivel de diseño. En este caso particular,
que el posicionamiento de los elementos de la interfaz no se pueda definir en la hoja de estilo,
logrando que los objetos de interacción queden distribuidos de igual forma que en el
documento fuente y que la aplicación cumpla con los estilos mínimos y necesarios para
funcionar de manera “accesible”, sin hoja de estilo. Para el punto de verificación 3.3, la
incorporación de la clase HojaEstilo y las posibles asociaciones a instanciar con las clases
Color, EstiloFuente y EstiloTexto, especificaciones de la clase EstiloPermitidoEnHoja, hacen
que la aplicación sea “accesible” utilizando una o varias hojas de estilo, permitiéndole a los
programadores y usuarios gozar de sus beneficios.
La definición como tipo de dato decimal, de los atributos de las clases Color, y la de tipo de
dato em o decimal de los atributos de las clases EstiloFuente y Posicionamiento, nos permitió
incorporar a nivel de diseño, la restricción asociada a las unidades de medidas utilizadas en
los valores de estas propiedades, limitando a que se correspondan únicamente con medidas
relativas, cumpliendo así el punto de verificación 3.4.
La agrupación explícita de los campos de texto (texts fields) que están lógicamente
relacionados, en la clase GrupoTextField a través de la relación todo-partes, y su asociación
con la etiqueta de texto (text label) de la clase Etiqueta que comparten, permitirá al cliente

17
Abstract Factory (Fábrica Abstracta) es un patrón de diseño para el desarrollo de software. El
problema que intenta solucionar este patrón es el de crear diferentes familias de objetos, permitiendo
trabajar con estos de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de
familia concreta que se esté usando.
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 77

Internet Explorer: (i) interpretar la relación entre el control y su etiqueta, (ii) identificar el
tipo de elemento de formulario que está seleccionado en ese momento y (iii) proporcionar los
medios para completar, seleccionar, des-seleccionar o presentar estos elementos de
formulario, cumpliendo con las pautas de Accesibilidad establecidas por los puntos de
verificación 10.2 y 12.4. Así mismo, que cada objeto de la clase TextField se encuentre
asociado sí o sí a un elemento de la clase Etiqueta, define por modelo que los campos de texto
vacíos de la interfaz, siempre contengan valores iniciales, cumpliendo entonces la pauta 10.4
de la guía.

6.1.2 Construcción de la Interfaz de Usuario de la Aplicación

Web GIE.
Como tercera actividad sobre el caso de estudio, construimos el primer prototipo de la interfaz
de la aplicación Web GIE. Este consistió en implementar una primera versión de la pantalla
de carga de Solicitudes de Aventamiento por Gases Inertes, utilizando la Arquitectura, Mapeo
y Diseño desarrollados en los pasos detallados en la Sección 6.1.1.
Dependiendo de la plataforma o entorno tecnológico seleccionado para la implantación de
una aplicación Web, queda determinado el conjunto de componentes reutilizables del que
dispondrán los desarrolladores para su construcción. Particularmente para nuestra aplicación
GIE, como mencionamos anteriormente, el framework tecnológico que se utilizó para su
desarrollo fue .NET Framework 3.5 [20]. A continuación describimos brevemente la
metodología utilizada, las tareas realizadas en cada etapa, las librerías y componentes
reutilizados. También mostraremos el resultado, la aplicación ASP.NET MVC creada, su
interfaz y código fuente.
1. Creamos un Proyecto Web denominado GIE, utilizando la plantilla ASP.NET MVC
Web Application, tal como se muestra en la Figura 6.2.

FIGURA 6.2: Cuadro de Diálogo New Project (Visual Web Developer 2008) para la Creación de Proyecto Web
GIE
78 Capítulo 6 - Caso de Estudio

La estructura de archivos y carpetas por defecto creada para la aplicación ASP.NET

MVC contiene principalmente 3 directorios: Controllers, Model y Views. El MVC
Framework es definido en el espacio de nombres System.Web.MVC, que es parte del
espacio de nombres System.Web. En el directorio Controllers es donde colocamos
nuestras clases que funcionan como controladores, en Models es donde van nuestras
clases que representan datos y finalmente en Views es donde colocamos nuestras
plantillas ASP.NET que se van a encargar de generar la interfaz HTML tal como
muestra la Figura 6.3

FIGURA 6.3: Carpetas de Aplicación para el Proyecto Web GIE

2. En el directorio /Controllers se creó la clase FormgiController.vb, instancia de la

clase Controlador de la Figura 6.1. En ASP.NET MVC existe una convención por
omisión acerca de como nombrar las clases que corresponden a los controladores.
Esta convención indica que, por ejemplo para el Controlador del formulario de
Solicitud de Gases Inertes, el nombre debe ser FormgiController, además de
derivarse de la base System.Web.MVC.Controller. Por lo tanto cuando el usuario
navegue hacia la URL /Formgi/, esta será manejada por el Controlador Formgi. Cada
Controlador responde a un grupo de acciones definidas para él, mediante métodos
públicos. Por lo tanto, para que FormgiController cargue la Vista correspondiente al
formulario de Solicitud de Gases Inertes, definimos la acción return View(), en la
función Formgi(), como se muestra en la Figura 6.4. Esta función es de tipo
ActionResult, este es un tipo especial que en nuestro caso cuando se ejecuta la
instrucción return View(), la Vista del formulario de Solicitud de Gases Inertes será
cargada y ejecutada para producir el código HTML que va a ser presentado en el
navegador Web.
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 79

FIGURA 6.4: Clase FormgiController para el Proyecto Web GIE

3. En el archivo Global.asax especificamos la configuración de ruteo de nuestro

proyecto WEB GIE. En él, el método RegisterRoutes tiene definida la manera por
omisión de como nuestra aplicación va a interpretar las URL que el usuario navegue.
Esta ruta especifica que la primera parte de nuestra URL corresponde al Controlador,
la segunda parte indica la acción a ejecutar y la tercera parte pertenece a los
parámetros tal como muestra la Figura 6.5.
En esta sección de nuestro programa es donde se agregarán las nuevas rutas con
diferentes características que satisfagan las necesidades de los futuros prototipos de la
aplicación Web GIE, solo hay que tener en cuenta que las rutas son evaluadas en el
orden que se registran.

FIGURA 6.5: Clase FormgiController para el Proyecto Web GIE

4. En el directorio /Content creamos el archivo Site.css correspondiente a la hoja de

estilo. En este creamos las clases que instancian a EstiloPermitidoEnHoja y que
modelan Color, EstiloFuente y EstiloTexto, como se muestra en la Figura 6.6.
80 Capítulo 6 - Caso de Estudio

FIGURA 6.6: Archivo Site.css para el Proyecto Web GIE

5. Dentro del directorio /Views encontramos un directorio Shared, que tal como muestra
la Figura 6.7, contiene un archivo de Master Pages: Site.Master. Este archivo es la
plantilla HTML que nuestra aplicación GIE va a utilizar. La naturaleza de este
archivo es proveer de una interfaz unificada en toda la aplicación. Esta plantilla
global cuenta con dos secciones que funcionan como contenedor, y serán llenadas con
el HTML generado por las vistas de GIE.

FIGURA 6.7: Archivo Site.Master para el Proyecto Web GIE

6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 81

Dentro del archivo Site.Master incluimos inline, la definición de estilos singulares, que
instancian con la clase Posicionamiento y definen parte de la apariencia del título y
cuerpo de las vistas. Así mismo mediante un link enlazamos el archivo externo Site.css.
6. Dentro del directorio /Views creamos el directorio Formgi, que una vez mas, obedece
a la convención de nombres sobre la cual funciona el framework. En este directorio
creamos el archivo Formgi.aspx cuyo nombre corresponden a las acciones del
Controlador FormgiController.vb. La extensión aspx del archivo, indica que es un
archivo ASP.NET, pero en realidad es una plantilla MVC.

FIGURA 6.8: Archivo Formgi.aspx para el Proyecto Web GIE

Como se observa en la Figura 6.8, en la Vista Formgi.aspx se colocaron los elementos

asp:label, asp:textbox, fieldset, que instancian con las clases Etiqueta,
GrupoCuadroTexto, CuadroTextoCompuesto y CuadroTexto de la Figura 6.1. Estos
elementos son objetos, activos de servidor (es decir, que se generan allí) y tienen
propiedades y métodos asociados. Estos controles se ejecutan en el servidor y luego
procesados traen código HTML común, o sea por ejemplo: <Input type="text"
name="nombreOperador" /> tal como muestra la Figura 6.9. En este código HTML se
puede observar detalladamente como fueron aplicadas las pautas de la WCAG 1.0 [34]
de la Tabla 6.1, a partir de haber utilizado como guía en el diseño de la interfaz de
usuario de la aplicación Web GIE, el Mapeo propuesto por nuestro enfoque.
82 Capítulo 6 - Caso de Estudio

FIGURA 6.9: Código HTML generado correspondiente al procesamiento del archivo Formgi.aspx para el
Proyecto Web GIE

7. Por último, para implementar la internacionalización de los textos asociados a las

etiquetas de la interfaz de usuario, se creó el directorio App_GlobalResources con dos
archivos de recursos, uno por cada idioma: Formgi.resx para castellano y Formgi.pt-
br.resx para portugués. Un archivo de recursos es un archivo XML que contiene las
cadenas que desea traducir a otros idiomas diferentes. El archivo de recursos contiene
pares de clave y valor. Cada par es un recurso individual. El archivo Formgi.resx es
el archivo de recurso predeterminado. En tiempo de ejecución, ASP.NET utiliza el
archivo de recursos que mejor coincide con la configuración de la propiedad
CurrentUICulture. La referencia cultural de la interfaz de usuario para el subproceso
se establece de acuerdo con la referencia cultural del navegador del usuario. Si la
referencia cultural del navegador es portugués-brasil, ASP.NET utilizará la versión
compilada del archivo Formgi.pt-br.resx. Si no hay ninguna coincidencia para la
referencia cultural de la interfaz de usuario actual, ASP.NET utilizará la reserva de
recursos, empezando con recursos para una referencia cultural específica (español-
argentina) y por último, el archivo de recursos predeterminado. En nuestro caso
coincide con la referencia español-argentina y las Figuras 6.10 y 6.11 muestran los
archivos de recursos creados.
6.1 Implementación del enfoque propuesto en Aplicación Web GIE. 83

FIGURA 6.10: Archivo Formgi.resx para el Proyecto Web GIE

FIGURA 6.11: Archivo Formgi.pt-br.resx para el Proyecto Web

6.2 Resumen
En este Capítulo hemos detallado como a partir de los requerimientos funcionales
propios de la empresa “Petróleo SA” y del conjunto de especificaciones no-
funcionales de Accesibilidad que se requirieron anexar, utilizamos el Mapeo de
recomendaciones de Accesibilidad de la WCAG 1.0 [34] en clases de decisión del
framework del Larson [17] (desarrollado en el Capítulo 4) para asistirnos
arquitecturalmente en el direccionamiento de los requerimientos de Accesibilidad en
un Modelo de Objetos Reusables. Este Modelo de Objetos tiene las propiedades de
fácil mantenimiento, integración, extensión y modularidad, permitiendo con
posterioridad utilizar con facilidad el Framework.Net como framework tecnológico de
implantación, disminuyendo los defectos, tiempos y costos incurridos en el proceso de
desarrollo actual y en el de los futuros prototipos a ser implementados.
Capítulo 7
Trabajos relacionados
Existe numerosa literatura en el campo de la Accesibilidad Web. Sin embargo es muy escasa
la evidencia hallada sobre la existencia de enfoques que planteen el tema de la Accesibilidad
Web desde una perspectiva arquitectural. En esta Sección nosotros nos remitiremos a
presentar dos trabajos [12] [4] que guardan relación con nuestra propuesta, ya que enfocan su
atención en el diseño de interfaces de usuario “accesibles” señalando como desde una visión
arquitectural y en etapas tempranas del ciclo de vida se puede asistir a concretar dicho diseño.

7.1 Propuesta de Hoffman et al.

En [12] se propone un trabajo donde se identifican las directrices para Arquitecturas de
Software que soporten a la Accesibilidad. El trabajo describe los problemas comunes de
Accesibilidad encontrados en la mayoría de las aplicaciones Web y explica como la
arquitectura puede ayudar a direccionar estos problemas a través de objetos “accesibles”
reusables, información complementaria, información visual para acceder a una página Web, y
manejadores de errores y notificaciones de time-out y recuperación. También se discute el
papel fundamental que puede jugar la arquitectura como apoyo para satisfacer las necesidades
de los distintos grupos de usuarios, a través de múltiples vistas de la interfaz de usuario.
Estas cuestiones que auxilian al desarrollo de una aplicación Web “accesible”, son
presentadas por el trabajo dentro de los siguientes grupos [12]:

Uso de Bibliotecas de Objetos Reusables. Soluciones comunes de Accesibilidad pueden

incorporarse en componentes de software reusables y repositorios de datos a través de
aplicaciones o incluso en suites de aplicaciones. Componentes reutilizables definen la
estructura y los atributos de un tipo particular de elemento en la página. Estos componentes
pueden usar repositorios de datos, por ejemplo archivos planos como los de propiedades de
Java, que contienen valores de atributos tales como etiquetas de campos y títulos.
Los siguientes son algunos de los objetos reusables que pueden ser diseñados para propiciar la
Accesibilidad:
• Campos con sus etiquetas asociadas: usar un objeto reusable asegura que las
etiquetas se leen con los campos apropiados de forma coherente en toda la aplicación.
• Conjunto de “radio buttons” con títulos: usar un objeto reusable asegura que el título
del radio button es leído cada vez que se accede y establece el radio button de forma
consistente en toda la aplicación.
El código de los objetos reutilizables puede ser desarrollado para forzar cierta codificación
estándar, tal como un requerimiento para proporcionar texto alternativo o complementario a
una imagen, un campo etiqueta, un enlace o un botón. Asimismo los objetos reutilizables
también pueden proporcionar la capacidad para incorporar características de Accesibilidad
cambiando solo un número relativamente pequeño de componentes reutilizables, en lugar de
cambiar individualmente varios controles, en múltiples páginas de una aplicación Web o
familia de aplicaciones Web. El uso de componentes reusables puede proveer un nivel de
consistencia que en muchos casos es difícil de lograr aun después de un exhaustivo testing y
ajuste del código de los componentes por separado.
7.1 Propuesta de Hoffman et al. 85

Información Complementaria. Uno de los problemas de Accesibilidad más comunes implica

que la información no está disponible o no tan fácilmente disponible, para los usuarios en
general, y esto sin mencionar a usuarios que padezcan algún tipo de discapacidad. Por
ejemplo, el propósito de algunos links, o de presionar un botón o de algunas etiquetas de
campos, podrían no estar claros para los usuarios con lectores de pantalla, sin el contexto del
entorno. Mas aun, los usuarios podrían no ser consientes de la existencia de mensajes de
error, de ayuda, de tópicos relacionados a campos, o simplemente al hecho de que un campo
es requerido, si la información no está incluida en la etiqueta del campo.
Por ejemplo, los campos relacionados son agrupados y etiquetados normalmente, de alguna
manera en la que se asume que los usuarios tienen conocimiento de esta agrupación. Sin
embargo, esto podría ser un reto para los usuarios ciegos que no pueden tener acceso al
contexto. Son varias las situaciones que comúnmente se presentan en este sentido, como la
que muestra la Figura 7.1 donde los campos comparten la etiqueta por estar relacionados
lógicamente.

FIGURA 7.1: Campos que comparten una etiqueta [12].

Los usuarios visuales pueden asociar la información por contexto con una simple exploración
con sus ojos, sin quitar el foco de los campos del formulario, pero los usuarios con lectores de
pantalla deben elegir entre una vista textual que permite la lectura de todo el contenido en
forma lineal y una vista de manipulación de campos que permite la manipulación de todos los
campos de datos de entrada.

Proveer Acceso a la Señalización sobre la Pantalla. Señalización se refiere a la información

visual de la página Web que comunica el título de la aplicación y la página, cualquier mensaje
esencial del sistema, y cualquier mensaje de estado o respuesta. La señalización es esencial
para ayudar a los usuarios a conocer donde están en una aplicación. Sin embargo los usuarios
con discapacidades podrían no tener acceso a los mensajes que muestran la información del
estado y ubicación actual.
Los usuarios visuales tienen la habilidad de leer rápidamente el texto y gráficos de
señalización en la pantalla y pueden ir directamente a la tarea en cuestión. En cambio, el
acceso de los lectores de pantalla es lineal, por ende sus usuarios no pueden realizar una
lectura visual. Probablemente además, deban escuchar una cantidad significante de texto
potencialmente irrelevante para determinar la ubicación de la funcionalidad o el estado del
sistema.

FIGURA 7.2: Señalización transmitida a través de elementos visuales [12].

86 Capítulo 7 - Trabajos relacionados

La Figura 7.2 muestra como la información correspondiente a la ubicación actual, incluyendo

el nombre de la aplicación y del sitio Web, la pagina y la sección, está disponible de un
vistazo. La información de estado incluyendo el número existente de errores, los resultados de
búsqueda encontrados, y los identificadores de usuarios y registros específicos está también
disponible de un vistazo.
La barra de título del navegador de la página, podría proporcionar un resumen de la ubicación
del usuario y de cualquier estado especial: el nombre de la aplicación, seguido por la sección
de la aplicación, seguido de la página, seguido de cualquier identificador de usuario o de
registro especifico. Tal como muestra la Figura 7.3, la información de estado, de existencia de
errores, de resultados de búsqueda o de falta de resultados de búsqueda, se puede insertar de
manera concisa al comienzo de la barra de título cuando corresponda.

FIGURA 7.3: Ejemplo de señalización efectiva en la barra de título: (A) la barra de título muestra un error de
información, (B) la barra de título muestra resultados de búsqueda [12].

Funcionalidad de “Time Out”. La funcionalidad de time out permite direccionar el intervalo

de tiempo en el cual una conexión a Internet permanecerá abierta sin ningún tipo de
transmisión de datos. Cuando esta función es usada en una aplicación de Internet, el usuario
debe recibir suficiente notificación (al comienzo de la aplicación o cuando el time out esta a
punto de ocurrir) y tener la posibilidad de indicar que necesita mas tiempo, como señala la
Sección 508 [12].
La funcionalidad de time out crea una necesidad relacionada con tres características de
Usabilidad: notificación al usuario, tiempo adicional requerido y recuperación de usuario. Sin
embargo la funcionalidad de time out es también un problema de Accesibilidad por que los
usuarios con discapacidades probablemente trabajen mas despacio sobre una aplicación y
requieran de más tiempo y por ende resultarán mas afectados por el tiempo de espera.
Es importante notificar a los usuarios con antelación de que una aplicación tiene time out.
Esta notificación debe aparecer al comienzo de cada solicitud y puede ser incluida como parte
de las instrucciones para completar dicha aplicación.
Para proveer esta solución de Accesibilidad en una aplicación Web o familia de aplicaciones
Web, se puede establecerse un componente de arquitectura reusable y consistente destinado a
proveer la funcionalidad de time out.

Múltiples Vistas de Interfaz de Usuario. A menudo, las mejoras de Accesibilidad mejoran la

Usabilidad general; otras veces no tienen ningún impacto en la Usabilidad, y otras ocasiones
aun pueden tener un efecto negativo sobre la Usabilidad general. Del mismo modo que la
Usabilidad normalmente tiene un impacto sobre los usuarios con discapacidades, pueden
existir veces en que las mejoras de Usabilidad tengan un impacto negativo sobre la
Accesibilidad. En resumen, la mejor solución para un grupo puede comprometer las
necesidades del otro grupo. Y hay veces en que diseñar una solución que cumpla con las
necesidades de todos resulta en una solución inadecuada para todos.
Un primer paso hacia resolver los requerimientos contradictorios puede ser el uso de
múltiples vista de una aplicación. Las siguientes son algunas de las características que pueden
ser implementadas a través del uso de una arquitectura de múltiples vistas:
7.1 Propuesta de Hoffman et al. 87

• Imágenes: múltiples vistas pueden permitir a usuarios visuales, ver la información de

imágenes por defecto y pueden reemplazar las imágenes con textos para usuarios
ciegos o con baja visión.
• Tamaño de fuentes y colores: El tamaño y el color de las fuentes pueden dar señales
claras y concisas a los usuarios visuales. Esas mismas señales deben adicionarse a
través del texto u otros medios para los usuarios con discapacidad visual.
• Título de atributos: generalmente los títulos de los atributos son un beneficio para
algunos usuarios sin obstaculizar a otros. La excepción puede ser para usuarios que
usan software de reconocimiento de voz. Una vista alternativa para personas con
impedimentos de movilidad puede eliminar los títulos de los atributos.
Este trabajo predica abordar los problemas de Accesibilidad en este tipo de arquitectura para
mejorar dicha Accesibilidad, sin limitarla, por el hecho de hacer frente a estos problemas
dentro de la arquitectura. Además el trabajo provee una introducción a la relación
Accesibilidad - Arquitectura de Software, describiendo problemas comunes de Accesibilidad
relacionados a la arquitectura y proveyendo guías para diseccionarlos. Estas guías fueron
escritas con el objetivo de proporcionar un punto de partida para arquitectos y desarrolladores
de software, quienes pueden necesitar conocer como las arquitecturas se pueden mejorar,
como así también para los especialistas en Accesibilidad quienes pueden necesitar especificar
requerimientos de Accesibilidad, cooperando con su labor en los equipos de desarrollo.

7.2 Propuesta de Brunet et al.

En [4] proponen, como una mejor manera de discutir una solución “accesible”, dividirla en
sus componentes: (i) la arquitectura de la plataforma “accesible”, (ii) la tecnología asistiva y
sistemas con características de Accesibilidad y (iii) el soporte para el desarrollador. La figura
7.4 ilustra estos componentes de software necesarios para entregar soluciones “accesibles”,
los cuales se presentan a continuación.

FIGURA 7.4: Componentes de software de una solución accesible [4].

Arquitectura de la Plataforma Accesible. Este trabajo define el término “plataforma” como

un entorno de ejecución de software en el que una aplicación (compuesta de uno o más
módulos ejecutables) puede ejecutarse. Una plataforma define un único conjunto de interfaces
de programación de la aplicación (APIs) y protocolos de ejecución (tales como el
88 Capítulo 7 - Trabajos relacionados

comportamiento de las aplicaciones para manejar eventos). Por ejemplo Microsoft WIN32
API (disponible en Windows XP) define una plataforma, mientras que Hypertext Markup
Labguage (HTML), Cascading Style Sheets (CSS) y JavaScript definen otras plataformas.
Las plataformas “accesibles” deben proporcionar la manera de que las aplicaciones exporten
información correspondiente a sus interfaces de usuario visuales para los productos de
tecnología asistiva (AT), como así también para que los dispositivos de productos de AT
observen el cambio de estado de los componentes de la interfaz de usuario. Adicionalmente
deben proveer un dispositivo de acceso independiente a las aplicaciones.

Tecnología Asistiva y Sistema con Características de Accesibilidad. Cuando una aplicación

es desarrollada para personas con discapacidad el producto es vinculado a tecnología asistiva
complementaria, que proporciona mecanismos alternativos de entrada y salida de
información, y crean una solución completa. Un ejemplo de AT son los lectores de pantalla
que usan un motor TTS (Text-To-Speach) para leer la aplicación a gente con discapacidad
visual, los dispositivos que muestran los subtítulos para personas con discapacidad auditiva y
especialmente teclados y dispositivos de entrada para gente con discapacidad motora.
Un AT puede ser efectivo únicamente cuando las interfaces del software y hardware con los
que interactúa son “accesibles”. Por ejemplo, un lector de pantalla no puede leer la
información de gráficos e imágenes de una página Web, a menos que el autor de la página
proporcione un atributo con texto alternativo. La Figura 7.5 ilustra el atributo “alt” de la
etiqueta de la imagen IMG permitiendo al AT hacer la página Web “accesible”.
Los sistemas con características de Accesibilidad son una clase especial de AT, para los
cuales la plataforma debe proporcionar acceso y la aplicación debe ser compatible. Por
ejemplo el navegador Mozilla y Java Swing, que corren en múltiples plataformas de sistemas
operativos, y ambos pueden responder a las configuraciones de fuentes y colores.

FIGURA 7.5: Solución accesible para una página Web. [4]

Soporte para Desarrolladores. Los desarrolladores pueden a menudo pasar por alto detalles
que deben ser y pueden ser fácilmente direccionados, para lograr Accesibilidad en las
aplicaciones. El resultado es la necesidad de soporte para asistir al desarrollador en crear una
solución “accesible”. Específicamente los desarrolladores necesitan guías, controles
“accesibles” reusables y herramientas de autor con ejemplos de código. Particularmente, los
desarrolladores Web necesitan herramientas para crear HTML accesible y otros contenidos
Web. Por ejemplo el grupo de trabajo conocido cómo Web Accesibility Initiative (WAI) [33]
el World Wide Web Consortium’s (W3C) [33] ha desarrollado un conjunto de
recomendaciones denominadas Authoring Tools Accessibility Guidelines (ATAG) [33], que
definen que debe hacer una herramienta de creación de contenido Web para promover la
creación de contenido Web “accesible”.
7.2 Propuesta de Brunet et al. 89

Otros dos aspectos en los hace fuerte hincapié este trabajo a los efectos de obtener una
aplicación “accesible” son: (i) la necesidad de poder acceder a información semántica y, (ii)
los requerimientos de Accesibilidad para los componentes de una solución “accesible”. A
continuación se describen estos dos aspectos proveyendo una síntesis del detalle original
provisto por el trabajo [4].

Necesidad de Acceder a Información Semántica. Desde este aspecto, los autores definen en
primer lugar el término “información semántica” como la información subyacente en una
aplicación, en contraposición a lo que se presenta de dicha información. Por ejemplo,
consideremos una interfaz de usuario de una aplicación que presenta una imagen de un
grafico de barras. En esta imagen no hay información acerca del significado de las barras del
gráfico y sus valores, la imagen es solo un arreglo de pixeles. Por lo tanto es esencial
mantener la “información semántica”, separada de la representación visual para hacer la
“información semántica accesible” a través de interfaces de programación. Capturar la
“información semántica” puede ser fácil cuando es utilizada únicamente la tecnología de
carácter I/O. El carácter I/O consiste en contenido de texto plano, normalmente limitado en su
extensión (como una red de 80x25). Un ejemplo de carácter I/O son las interfaces en línea de
comandos provisto por muchos sistemas operativos. Si la aplicación consiste únicamente de
indicadores y respuestas, toda la “información semántica” de la interfaz es codificada en
cadenas de texto. Los AT no necesitan realizar interpretaciones adicionales de la información,
las cadenas de caracteres pueden ser presentadas en interfaces físicas alternativas tales como
dispositivos Braile. En contraposición, las interfaces de usuario que explotan paradigmas
gráficos no son tan fáciles de tratar. El medio grafico de las interfaces consiste de una red de
pixeles (comúnmente mas grande de 1024x768) sobre las que el contenido es dibujado. El
contenido es entramado en una red pequeña de pixeles, pero otro contenido, como las
imágenes, es directamente dibujado. En este caso, los AT deben capturar la información
dibujada en la pantalla e intentar realizar ingeniería reversa de texto-semántica, si dicha
facilidad está disponible. Por lo tanto, el AT deberá presentar este contenido de una forma
aceptable para el usuario, independientemente de las habilidades de este. Esto implica una
mayor carga para el desarrollador de la aplicación, al tener que proveer la “información
semántica” adicional al contenido y presentación, para que este disponible a través de
interfaces de programación.

El trabajo reconoce al patrón MVC como un instrumento conceptual de valor al diseño de

soluciones “accesibles” que puede contribuir al acceso a “información semántica”. La
arquitectura MVC es un clásico enfoque para una variedad de aplicaciones interactivas.
Separa las tareas de mantenimiento del Modelo interno de una aplicación, de las tareas de
presentar una interfaz de usuario y procesar las entradas y salidas del usuario. La figura 7.6
muestra las tres partes del patrón de diseño MVC y la interacción entre ellas.

FIGURA 7.6: Patrón de diseño MVC [4].

La aplicabilidad del patrón de diseño al problema de interoperabilidad de la tecnología

asistiva es sencilla: cada AT debe crear vistas alternativas para el Modelo de la aplicación. A
veces estas nuevas vistas están estrechamente vinculadas a la representación visual de la
90 Capítulo 7 - Trabajos relacionados

aplicación sobre la pantalla de la computadora. Por ejemplo, un magnificador de pantalla tal

como ZoomText [4] construye su única vista mediante la ampliación de los contenidos de una
sección de la pantalla. En otros casos, sin embargo puede haber una perdida entre la
vinculación de la vista creada por el AT y la representación visual original del modelo de la
aplicación. IBM Home Page Reader (HPR) [4], es un ejemplo de este último caso. El AT,
además de generar nuevas vistas apropiadas para gente con discapacidad, debe en muchos
casos, entregar un nuevo control para la aplicación. El componente control de HPR, por
ejemplo, captura todos los eventos de entrada del mouse y combinación de teclas, y redefine
el manejo de mucho de estos eventos. Por ejemplo, el click del mouse sobre un párrafo de
texto causa que HPR lea el texto y reubique el cursor de lectura sobre esa ubicación.
El Modelo de la aplicación desde la perspectiva pura del patrón MVC se corresponde al
Modelo de los Datos que construyen la aplicación y las operaciones que los modifican.

Los Requerimientos de Accesibilidad para los Componentes de una Solución Accesible.

Desde este aspecto el trabajo evalúa los requerimientos de Accesibilidad para la arquitectura
de la plataforma “accesible”, para la tecnología asistiva y para las aplicaciones y
herramientas. Cada uno de estos requerimientos se presenta a continuación enumerando las
características que deben estar presentes a los efectos de cubrir dicho requerimiento.
• Requerimientos para la arquitectura de la plataforma accesible.
o Una aplicación IT debe ser estructurada de manera tal que el Modelo de la
aplicación, las vistas del Modelo y las funciones del Controlador que modifican
el estado del Modelo, estén bien aisladas unas de otras.
o Un Modelo de objetos robusto conteniendo la semántica necesaria debe ser
mantenido por la aplicación y comunicado a través de sus interfaces.
o El Modelo de objetos debe proveer una interfaz a través de la cual un AT pueda
obtener el conjunto de acciones y descripciones de cada objeto de la aplicación,
y el Modelo de objeto pueda hacer todas las acciones a través de accesos
programados.
o La arquitectura de la plataforma debe proveer métodos para describir las
relaciones entre los objetos del Modelo.
o La arquitectura debe proveer métodos para eventos de protocolos y eventos
semánticos a través de los cuales los ATs son informados del cambio del estado
actual del Modelo de la aplicación y de las entradas del usuario.
o Un solo Modelo de objetos estándar, como el definido en [2], debería ser usado
para acceder por todas las aplicaciones y todos los objetos de interfaz de usuario
que pueden aparecer sobre dispositivos visuales.
o La arquitectura debe permitir que los ATs puedan monitorear y modificar las
entradas del usuario.
• Requerimientos para la tecnología asistiva.
o El AT debe proporcionar para navegar todas las características y contenidos
utilizando dispositivos de entrada alternativos.
o Toda la información debe ser representada usando dispositivos de salida
alternativos.
o La personalización debe ser soportada a través de setings and scriptings.
o El AT debe responder rápidamente a las interacciones del usuario.
o El AT debe ser compatible con otros ATs.
• Requerimientos de Accesibilidad para aplicaciones y herramientas
7.2 Propuesta de Brunet et al. 91

o El Modelo de objetos de la aplicación conteniendo la semántica necesaria debe

ser mantenido por la aplicación en el contexto de Accesibilidad de la arquitectura.
o Las herramientas de desarrollo de la aplicación deben proporcionar una paleta de
controles de acceso y suministrar instrucciones cuando el contenido de la
aplicación se esta creando verificando y reparando el contenido inaccesible.
Capítulo 8
Conclusiones y Trabajos Futuros
El desarrollo de aplicaciones Web “accesibles” es un factor fundamental a la concreción de la
Universalidad de la Web. Las limitaciones y el mal uso por parte de los diseñadores de las
tecnologías vigentes están dando lugar a situaciones de imposibilidad de acceso a la
información no solo por parte de aquellos usuarios con discapacidad sino también para
individuos con limitaciones derivadas del contexto de uso y del dispositivo de acceso
empleado, entre otras.
Motivados por esta realidad, desarrollamos nuestro enfoque, que asiste al diseño de interfaces
de usuarios con un grado de Accesibilidad que depende directamente del nivel de
conformidad de las decisiones de diseño tomadas por el desarrollador, dentro del framework
de Larson-componentes MVC.
Específicamente nos centramos en presentar un Mapeo de las pautas recomendadas por la
WCAG 1.0 [34] a las clases de decisión de diseño propuestas por Larson en [17] y a los
componentes del patrón arquitectónico más ampliamente utilizado en el diseño de interfaces
de aplicaciones Web: Model View Controller (MVC) [5].
En el presente Capítulo, describimos las conclusiones que derivan de los resultados obtenidos
de alcanzar los objetivos que nos propusimos. Mencionamos también los aportes y ventajas
del presente trabajo, las publicaciones derivadas del mismo y, los futuros trabajos que se
pueden desarrollar analizándolos desde dos perspectivas: 1) mantenimiento del Mapeo ante la
evolución vertiginosa que caracteriza a la Web y 2) creación de herramientas que asistan a los
desarrolladores en la utilización de nuestro enfoque cuando diseñan sus páginas Web.

8.1 Resultados del Mapeo

La problemática actual sobre la que se basó nuestro trabajo, es el diseño de aplicaciones Web
“accesibles”, es decir, el diseño de aplicaciones que presenten la información de tal manera
que sus usuarios puedan acceder a ella independientemente del equipo hardware y de los
programas (software) que estén usando, y además independientemente de cómo naveguen
dicha aplicación Web.
Tal como ya hemos señalado, las pautas de la WCAG 1.0 [34] explican cómo hacer
“accesibles” los contenidos de la Web a personas con discapacidad y están pensadas para
todos los diseñadores de contenidos (autores de páginas, diseñadores de sitios) y para los
diseñadores de herramientas que asisten al diseño. Con la consigna de preservar intacta esta
filosofía de la WCAG 1.0 [34] nos planteamos la inquietud de ¿cómo se podrían aplicar estas
pautas desde una perspectiva arquitectural y en una etapa temprana del diseño?
Fundamentándonos en esta premisa, y sobre la base de conceptos arquitecturales, en la etapa
inicial de nuestro trabajo elegimos agrupar los puntos de verificación de cada una de las
pautas de la WCAG 1.0 [34], dentro de las clases de decisión de diseño del framework de
Larson. Luego y de acuerdo a los objetivos perseguidos por cada uno de los puntos de
verificación, analizamos las consecuencias de conformar dicho puntos a los efectos de
alcanzar los niveles de Accesibilidad deseados.
De esta manera, el diseño de aplicaciones Web que se desarrolle bajo nuestro Framework, no
solo alcanzará el nivel de Accesibilidad deseado, sino también permitirá el reuso de todo (o
8.1 Resultados del Mapeo 93

parte) del sistema propiciando a su vez: (i) la facilidad de mantenimiento, integración,

extensión y modularidad del mismo, (ii) la disminución de los defectos, tiempos y costos
incurridos en el proceso de desarrollo y (iii) la minimización de los riesgos de cambios
futuros, al proveer un marco adecuado para el establecimiento de las decisiones de diseño
significativas a la Accesibilidad.
Para la aplicación de este Mapeo de “decisiones de diseño de Accesibilidad”, los diseñadores
de aplicaciones Web pueden aplicar el patrón MVC [5] describiendo sus componentes en
términos de dicho Mapeo, con el objetivo de que su interacción resuelva, no solo el problema
general de separar los aspectos de los datos y la lógica de la aplicación de los asociados a la
interfaz de usuario, sino los diferentes problemas de acceso a los recursos de la aplicación
Web, inherentes a la Accesibilidad.

Por esta razón, nosotros además concentramos nuestros esfuerzos en mapear cada una de las
pautas correspondientes a la WCAG 1.0 [34] a las clases de decisión de diseño propuestas por
el framework de Larson y a los componentes del patrón MVC [5], preservando la filosofía
inherente a cada punto de verificación de las pautas de la WCAG 1.0 [34].
De esta manera al aplicar el patrón MVC, se logra: (i) abstraer e identificar los aspectos
claves para una estructura de diseño accesible de base, (ii) crear un diseño orientado a objetos
reutilizable, (iii) acortar los esfuerzos de diseño, desarrollo y mantenimiento y, (iv) alcanzar
los niveles de Accesibilidad deseados.
Es importante destacar que estas ventajas de nuestro enfoque no han quedado sólo en prédica,
sino que hemos aplicado el Mapeo como instrumento y herramienta principal para asistir al
diseño y desarrollo de la interfaz de usuario de una aplicación Web específica. Como caso de
estudio seleccionamos la aplicación Web GIE (Gestor de Incidentes y Emisiones), de la
compañía “El Petroleo SA”. Compañía que por las características de los usuarios de sus
aplicaciones: (i) edades, características físicas, cognitivas y de habla diferentes, (ii) gran
distribución geográfica (iii) condiciones tecnológicas, de conectividad y de variedad de
dispositivos (notebooks, PDAs, celulares etc.), consideramos el escenario ideal donde nuestro
enfoque podía contribuir de manera notable al principio de Accesibilidad y a través de este
factor de calidad, a la calidad de su aplicación Web GIE.
Una vez implementada la aplicación GIE, pudimos observar y evaluar a partir de su código
HTML generado, cómo utilizando nuestro enfoque, obtuvimos los niveles de Accesibilidad
deseados sobre los elementos de la interfaz de usuario tales como etiquetas (labels), cuadros
de textos (text fields), y otros aspectos que hacen a la Accesibilidad de una aplicación Web,
como por ejemplo el uso de hojas de estilo, el idioma de la aplicación, etc.
Cuando nos propusimos el objetivo de esta tesis y luego de familiarizarnos con el área de la
Accesibilidad Web, investigamos profundamente sobre la existencia de trabajos o enfoques
que plantearan el tema de la Accesibilidad Web desde una perspectiva arquitectural. Dentro
de la escasa evidencia hallada, encontramos algunas guías que los desarrolladores pueden usar
para introducir la relación Accesibilidad-Arquitectura de Software, como la propuesta de
Hoffman et al. [12] presentada en la Sección 7.1. Este trabajo si bien valioso, es ciertamente
incompleto, si lo evaluamos a luz de nuestra propuesta que ofrece un universo más amplio
para tratar problemas de Accesibilidad con un nivel de detalle técnico y de abstracción mayor
en las soluciones resultantes al propiciar el uso de múltiples vistas.

En este punto es importante destacar de que somos concientes, que nuestro enfoque estudia un
aspecto de la ecuación que lleva al diseño de aplicaciones Web “accesibles” dando respuesta
a ¿cuán accesible es el contenido en una aplicación Web?. Trabajos como el propuesto por
Brunet et al. [4] presentado en la Sección 7.2, abordan la discusión contemplando los otros
dos aspectos de la ecuación: la Accesibilidad de los navegadores y la Accesibilidad de las
herramientas para la creación de sitios respectivamente. Si bien este último trabajo enmarca
94 Capítulo 8 -Conclusiones y Trabajos Futuros

los componentes arquitecturales de una solución “accesible”, la forma de abordar los

requerimientos de Accesibilidad es desde un nivel de abstracción superior al de nuestro
enfoque por que centran la problemática desde una perspectiva más enunciativa y genérica, es
decir menos específica al enfoque propuesto en nuestro trabajo.
De todo el trabajo realizado en esta tesis, concluimos que hemos elaborado un instrumento
muy útil para los arquitectos y desarrolladores de aplicaciones Web. Concretamente nuestro
enfoque les permite resolver los problemas más comunes de Accesibilidad, que generan
barreras al contenido de una aplicación Web, desde su arquitectura. Nuestro Mapeo no sólo
permite identificar de manera temprana estos problemas de Accesibilidad, sino que relaciona
de manera efectiva el efecto de las posibles decisiones vinculadas al diseño con el
cumplimiento de los puntos de verificación de las pautas WCAG 1.0 [34]. A partir de esta
concientización sobre los efectos de Accesibilidad resultantes de seleccionar un determinado
diseño para una interfaz de usuario, la aplicación del patrón MVC [5] posibilita la mejora de
su arquitectura.

La identificación temprana de las características de Accesibilidad desde una perspectiva

arquitectural, es una frase clave que permite sintetizar el objetivo principal de esta tesis:
obtener un diseño de interfaz de usuario que contribuya a la Accesibilidad de las aplicaciones
Web. El resultado es la obtención de un diseño dentro de una arquitectura que previene las
barreras de Accesibilidad, minimizando los riesgos de cambios futuros, permitiendo el reuso a
nivel arquitectural y disminuyendo gran parte de los defectos, tiempos y costos incurridos en
el proceso de desarrollo.

8.2 Publicaciones Derivadas de esta Tesis

En el marco del Congreso Argentino de Computación 2008 (CACIC 2008) realizado en la
Provincia de La Rioja, publicamos un artículo “Extendiendo MVC para Diseñar Interfaces de
Usuario Accesibles” [6], en el que presentamos nuestro enfoque: el Mapeo de las pautas
recomendadas por la WCAG 1.0 [34] a las clases de decisión de diseño propuestas por Larson
en [17] y a los componentes del patrón arquitectónico: Model View Controller (MVC) [5]. En
el artículo especificamos el objetivo de nuestro trabajo, de asistir a los desarrolladores Web en
la toma de decisiones de diseño para la construcción de interfaces de usuario más “accesibles”
para personas con capacidades diferentes y adjuntamos, por razones de espacio, el mapeo de
solo seis de los puntos de verificación de Prioridad 1 correspondientes a las pautas 1, 4, 5, 6 y
12; dos puntos de verificación de Prioridad 2 correspondiente a las pautas 13 y 3; y un punto
de verificación de Prioridad 3 correspondiente a la pauta 5.

8.3 Trabajos Futuros

Del trabajo llevado a cabo en esta tesis, en esta sección planteamos los trabajos futuros desde
las siguientes dos perspectivas: 1) el mantenimiento del Mapeo en respuesta la rápida
evolución exhibida por la Web y, 2) el desarrollo de herramientas que asistan a los
desarrolladores y especialistas de Accesibilidad en la utilización de nuestro enfoque para el
diseño de las páginas de sus sitios Web. Consideramos que ambas perspectivas son
importantes al fortalecimiento y completitud de nuestro enfoque.
1) Mantenimiento del Mapeo en respuesta a la rápida evolución exhibida por la
Web

Tal como señalamos en secciones anteriores, nuestro enfoque se fundamenta en las pautas de
Accesibilidad de la WCAG 1.0 [34] que es la normativa referente desde 1999 a nivel mundial.
Sin embargo, la WAI-W3C [33] ha seguido trabajando en el perfeccionamiento de pautas de
8.1 Resultados del Mapeo 95

Accesibilidad hasta proponer recientemente una nueva versión de la WCAG 2.0 [35] como
una alternativa a la WCAG 1.0 [34]. Este trabajo permanente es la respuesta apropiada a las
características de evolución inherente a los sistemas de información que tienen la Web como
plataforma de despliegue. Nuestro Mapeo debe también poder acompañar estos nuevos
requerimientos para seguir soportando con eficiencia la normativa dictada por futuras
versiones de la WAI-W3C.

2) Desarrollo de herramientas que asistan a los arquitectos, desarrolladores y

especialistas de Accesibilidad en la utilización de nuestro enfoque para el diseño
de las páginas de sus sitios Web.
Dependiendo en la etapa en la que se encuentre el proceso de desarrollo de la aplicación Web,
nuestro enfoque puede ser utilizado, por los analistas y especialistas de Accesibilidad en la
toma de requerimientos, por los arquitectos en la construcción de la arquitectura de la
aplicación o por los desarrolladores en el diseño y desarrollo de las páginas de sus sitios Web.
En este sentido, se puede construir alguna herramienta Case que de soporte a nuestro enfoque,
ya sea de tipo Upper Case para la obtención de requerimientos o Middle Case para el análisis
y diseño de la aplicación Web. Esta herramienta, permitirá al desarrollador modelar la
aplicación Web, así como también desarrollar su interfaz de usuario, siguiendo los
lineamientos arquitecturales de nuestro trabajo para alcanzar el nivel de Accesibilidad
deseado.
Apéndice A
Glosario
En este apartado presentamos el conjunto de definiciones preliminares asociadas a los
términos empleados en el Mapeo de Pautas de la WCAG 1.0 [34] en las clases de decisión de
diseño de Larson [17] y los componentes del patrón MVC [5].
Con el fin de que cada pauta sea autocontenida y de proveer una mayor claridad al presente
trabajo, hemos respetado la organización que utilizamos en el Mapeo, agrupando las términos
y sus definiciones según las Pautas de la WCAG 1.0 [34].

PAUTA 1 - PROPORCIONE ALTERNATIVAS EQUIVALENTES PARA EL CONTENIDO

VISUAL Y AUDITIVO
HTTP -- Protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol)
usado en cada transacción de la Web (WWW). HTTP define la sintaxis y la semántica que
utilizan los elementos software de la arquitectura Web (clientes, servidores, proxies) para
comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta
entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador o un spider) se
lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama
recurso y se la identifica mediante un URL. Estos recursos pueden ser documentos HTML,
imágenes, archivos de música, etc.
Contenido -- El contenido de un documento Web es lo que se quiere transmitir al usuario a
través del idioma o lenguaje natural, las imágenes, los sonidos, las películas, las animaciones,
etc. Es decir, el significado de los elementos de presentación dispuestos sobre la página Web.
Equivalente -- Un contenido es "equivalente" a otro cuando ambos cumplen la misma
función o propósito en la presentación al usuario. En el contexto de este trabajo, el
equivalente debe cumplir esencialmente la misma función para la persona con discapacidad
(al menos en la medida que sea posible, dada la naturaleza de la discapacidad y el estado de la
tecnología) como el contenido primario hecho para personas sin ninguna discapacidad. Un
texto es “equivalente” cuando trasmite todo el contenido esencial.
Elemento -- Básicamente un elemento es un constructor sintáctico, un tipo de contenido o un
constructor lógico.
Mapa de Imagen -- Un mapa de imagen es una imagen que tiene "zonas activas". Cuando el
usuario selecciona una de las regiones, ocurre una acción que puede activar un vínculo, enviar
datos al servidor, etc. Algunos lenguajes como HTML permiten dos tipos de mapa de imagen:
lado-cliente (el navegador del usuario procesa un URI) y lado-servidor (el servidor procesa
las coordenadas del punto seleccionado) precisando un dispositivo de entrada específico.
Vínculo o Enlace (link) -- Un vínculo o enlace se utiliza para establecer relaciones entre dos
recursos Web. Aunque la mayoría de los vínculos relacionan páginas Web, también es posible
enlazar otros recursos como imágenes, documentos Word, PDF, archivos HTML, programas,
etc. Un vínculo tiene dos extremos (llamados en inglés anchors, anclas), y una dirección o
sentido. “El enlace comienza en un extremo y apunta hacia el otro extremo”.
El comportamiento por defecto asociado a un vínculo es la obtención del recurso.
Normalmente se logra implícitamente seleccionando el vínculo (por ejemplo haciendo click
con el mouse, a través del teclado, por comando de voz etc.). Al activar estos vínculos los
usuarios pueden visitar los recursos.
Los agentes de usuario suelen representar los vínculos de modo tal que éstos son obvios para
los usuarios (subrayándolos, invirtiendo los colores, etc.). La representación exacta depende
del agente de usuario. La representación puede variar según que el usuario haya visitado ya el
vínculo o no.

PAUTA 3. UTILICE MARCADORES Y HOJAS DE ESTILO Y HÁGALO APROPIADAMENTE

Marcador (markup) -- Los marcadores son utilizados para indicar las diferentes partes que
componen la información de un documento o página WEB. Cada una de las palabras que se
emplean para marcar el inicio y el final de una sección se denominan etiquetas, en general las
etiquetas se indican por pares:
▪ Etiqueta de apertura: carácter <, seguido del nombre de la etiqueta (sin espacios en
blanco) y terminado con el carácter >.
▪ Etiqueta de cierre: carácter <, seguido del carácter /, seguido del nombre de la etiqueta
(sin espacios en blanco) y terminado con el carácter >.
Gramática Formal -- Una gramática formal es un conjunto de normas y restricciones que se
definen para fijar la sintaxis que deben cumplir los documentos de un determinado tipo. Si se
define una gramática para la creación de documentos relacionados con libros, se puede
obligar a que cada libro tenga un título y sólo uno, que pueda tener uno o más autores, que la
información sobre el número de páginas puede ser opcional, etc.
Para documentos Web también existen gramáticas formales, en las que se definen las
etiquetas que se pueden utilizar, los atributos de cada etiqueta, el tipo de valores que puede
tener cada atributo, etc.
Hoja de Estilo -- Una hoja de estilo es una plantilla, o guía, o conjunto de instrucciones, que
dicta al navegador como debe ser mostrado el contenido de una o varias páginas Web.
Cualquier cambio en la plantilla de estilo se refleja en un cambio inmediato en la apariencia
de las páginas relacionadas, sin necesidad de modificar físicamente estas.
Una hoja de estilo se compone de reglas de visualización (reglas de estilo). Las reglas de
estilo pueden tener tres orígenes diferentes: estilos incluidos en la cabecera del propio
documento Web o definido inline dentro del documento, ambos definidos por el autor del
mismo, estilos externos definidos en un archivo CSS enlazado en el documento Web por su
autor, estilos definidos por los usuarios finales o lectores de la aplicación.
Las hojas de estilo traen a la edición Web una relativa libertad de diseño, ampliando el control
sobre la apariencia y posicionamiento de todos los elementos de la página, efectos
tipográficos, fuentes, colores, background, compatibilidad entre navegadores y sistemas
operativos, y páginas con código más reducido de más rápida descarga. Más aún, los valores
asignables mediante hojas de estilo son manipulables mediante scripts (Javascript, Jscript,
VBScript).
Cita -- Una cita es una referencia textual de un fragmento o totalidad del discurso de una
persona, referencia de un texto externo.
Unidades de Medida -- Hay dos tipos de unidades de medida: relativas y absolutas. Las
unidades de medidas relativas especifican una medida en relación a otra propiedad de medida.

PAUTA 4. IDENTIFIQUE EL IDIOMA USADO

USE MARCADORES QUE FACILITEN LA PRONUNCIACIÓN O INTERPRETACIÓN DE
TEXTO ABREVIADO O EXTRANJERO

Acrónimo -- Un acrónimo es un conjunto de letras formado por las iniciales de otras

palabras. El término procede el griego, donde: akros es punta y onymos es nombre. Por
ejemplo: URL (Uniform Resource Locator).
Abreviatura -- Una abreviatura es la representación escrita de una o varias palabras mediante
una o varias de sus letras, a fin de que la palabra o las palabras en cuestión resulten más
cortas en el texto. Como por ejemplo Mb. (Mega Byte).
PAUTA 5. CREE TABLAS QUE SE TRANSFORMEN CORRECTAMENTE
Tabla alineada (que puede leerse cuando su contenido se lee línea a línea) -- Proceso de
interpretación de una tabla donde los contenidos de una celda se convierten en una serie de
párrafos uno tras otro (por ejemplo, página abajo). Los párrafos se sucederán en el mismo
orden que las celdas definían en el documento original. Las celdas deben tener sentido cuando
se lean en orden, y deben incluir elementos estructurales (que generan párrafos,
encabezamientos, listas, etc.), para que la página tenga sentido tras su transformación para ser
leída línea a línea.

PAUTA 6. ASEGÚRESE DE QUE LAS PÁGINAS QUE INCORPORAN NUEVAS

TECNOLOGÍAS SE TRANSFORMEN CORRECTAMENTE
Contenido Estático -- El contenido estático es aquél que permanece invariable desde el
momento en que su autor lo crea. Es decir, no depende de quién lo visualice ni en que
momento lo haga. Por ejemplo, textos planos acompañados de imágenes y a lo sumo
contenidos multimedia como pueden ser videos o sonidos simples.
Contenido Dinámico -- El contenido dinámico es aquél que se genera automáticamente en el
momento que alguien solicita su visualización, por tanto, puede cambiar dependiendo de
quién lo solicite o en que momento lo haga. Es información que permite a una página ser
sensible a las acciones del usuario. Incluye cualquier efecto especial o funcionalidad, por
ejemplo, cuando el usuario apunta a un texto, y éste cambia de color.
Para incluir estos efectos especiales se deben agregar elementos mucho más complejos, como
por ejemplo applets de Java, vídeos en formato QuickTime o Flash, etc., desarrollados en
diferentes lenguajes de programación: Java Server Pages (JSP), Javascript y Visual Basic
Script (VBScript), etc.
Normalmente, este tipo de contenidos no son interpretados por el navegador de manera
directa, sino que hace uso de pequeños programas llamados plugins, encargados de tratar con
estos elementos complejos.
Applet -- Un applet es un componente de una aplicación que corre en el contexto de otro
programa, por ejemplo un navegador Web. El applet no puede correr de manera
independiente, sino debe hacerlo en un contenedor, proporcionado por un programa anfitrión
mediante un plugin, o en aplicaciones como teléfonos móviles que soportan el modelo de
programación por applets.
Normalmente lleva a cabo una función muy específica que carece de uso independiente,
ofrece información gráfica y a veces interactúa con el usuario. Típicamente carece de sesión y
tiene privilegios de seguridad restringidos. Ejemplos comunes de applets son los Java Applets
y las animaciones Flash.
Script -- Un script es un programa que puede acompañar a un documento HTML o que
puede estar incluido en él. Puede ser ejecutado en la máquina del cliente o en el servidor.
En el primer caso, el programa se interpreta y ejecuta en la máquina del cliente cuando se
carga el documento, o en algún otro instante, como por ejemplo cuando se activa un vínculo.
En el segundo caso, cuando la página es solicitada por parte de un cliente, el servidor ejecuta
los scripts y se genera una página resultado, que solamente contiene código HTML. Este
resultado final es el que se envía al cliente y puede ser interpretado sin lugar a errores ni
incompatibilidades, puesto que sólo contiene HTML.
Es el servidor quien maneja toda la información de las bases de datos y cualquier otro recurso,
como imágenes o servidores de correo y envía al cliente una página Web con los resultados
de todas las operaciones.
Evento -- Un evento es una acción del usuario ante la cual puede realizarse algún proceso
(por ejemplo hacer clikc sobre un botón o seleccionar un campo de un formulario). Cuando
alguno de los eventos esperados por la aplicación tenga lugar, esta pasará a ejecutar el código
del correspondiente manejador de evento. El proceso a realizar se efectúa mediante scripts
ejecutados automáticamente.
Frame -- El nombre de "frames" se debe a la traducción inglesa del vocablo "cuadro" o
"marco", y como su nombre indica, su función es la de dividir una página Web en varias
páginas (frames), diferentes pero que interactúan entre si.
Los frames son una técnica basada en la posibilidad de poder visualizar, en una misma página
Web, 2 o más páginas Web independientes, que tienen la característica de poder interactuar
entre ellas.

PAUTA 9. DISEÑE PARA LA INDEPENDENCIA DEL DISPOSITIVO

Dispositivo de entrada -- Los dispositivos de entrada pueden incluir dispositivos de
apuntamiento, teclados, dispositivos braille, punteros de cabeza, micrófonos y otros.
Dispositivo de Salida -- Los dispositivos de salida pueden incluir monitores, sintetizadores
de voz y dispositivos braille.
Orden de tabulación -- El orden de tabulación define el orden en que el foco se dirige hacia
los elementos cuando la navegación se realiza por medio del teclado y puede incluir
elementos anidados en otros elementos. En una aplicación Web, el usuario dirige el foco
hacia un elemento de interacción con el objetivo de que éste se active y realice sus funciones.
Atajo del teclado -- Un atajo del teclado es una tecla o secuencia de teclas que efectúa una
acción definida previamente (bien por el usuario, bien por el programador de la aplicación).
Estas acciones pueden realizarse habitualmente de otro modo más complejo, bien navegando
por los menús, bien tecleando una instrucción más extensa, o bien utilizando el mouse. El
usuario debe mantener presionada una tecla denominada modificadora y posteriormente
presionar y liberar la tecla asociada al acceso (no-modificadora), finalizando por soltar la
tecla modificadora. Al pulsar la tecla de acceso asignada a un elemento, el foco se dirige
hacia el elemento. La acción que tiene lugar cuando el foco se dirige hacia un elemento
depende del elemento. Por ejemplo, cuando un usuario activa un vínculo definido por el
elemento A, el agente de usuario normalmente sigue el vínculo.

PAUTA 10. UTILICE SOLUCIONES PROVISIONALES

Formulario -- Un formulario es una sección de un documento Web, que además de su
contenido normal, contiene código, elementos especiales llamados controles (casillas de
verificación (checkboxes), radiobotones (radio buttons), menús, etc.), etc. Los usuarios
normalmente "completan" un formulario modificando sus controles (introduciendo texto,
seleccionando objetos de un menú, etc.), antes de enviar el formulario a un agente para que lo
procese (por ejemplo., a un servidor Web, a un servidor de correo, etc.).
Tabla Alineada -- a alineación de una tabla es un proceso de interpretación de la misma,
donde los contenidos de una celda se convierten en una serie de párrafos uno tras otro (Por
ejemplo, página abajo). Los párrafos se sucederán en el mismo orden en que las celdas se
definieron en el documento original. La idea principal de la serialización es convertir los
datos de una forma a otra, de tabla a párrafos, pero manteniendo su significado.

PAUTA 11. UTILICE LAS TECNOLOGÍAS Y PAUTAS W3C

Tecnologías W3C -- Además del desarrollo de Guía de Pautas de Accesibilidad al Contenido
en la Web, WAI también trabaja internamente con W3C para asegurar que las tecnologías de
la Web, tales como HTML, CSS, SMIL, XML, DOM, etc., soporten la Accesibilidad. WAI
trabaja en conjunto con otras organizaciones para desarrollar herramientas que puedan ayudar
a la evaluación, a reajustar páginas y proporcionar soluciones alternativas para soportar la
Accesibilidad y coordina actividades de investigación y desarrollo que puedan afectar al
futuro del acceso a la Web. Entre las diferentes tecnologías sobre las que se encuentra
trabajando en la actualidad se detallan:
• MaTHML para ecuaciones matemáticas.
• HTML, XHTML, XML para documentos estructurados.
• RDF para metadatos.
• SMIL para crear presentaciones multimedia.
• CSS y XSL para definir hojas de estilo.
• XSLT para crear transformaciones de estilo.
• PNG para gráficos (aunque algunos se presentan mejor en JPG, que no es una
especificación W3C).
Plug-ins -- Programa que puede anexarse a otro para aumentar sus funcionalidades
(generalmente sin afectar otras funciones ni afectar la aplicación principal). No se trata de un
parche ni de una actualización, es un módulo aparte que se incluye opcionalmente en una
aplicación.
Por ejemplo las barras de búsquedas de Google, Yahoo!, Alexa, entre otras, son plugin para
los navegadores Web como Internet Explorer, Firefox, etc.
CSS2[29] -- Es un lenguaje de hoja de estilo que permite que los desarrolladores y los
usuarios asocien un estilo (por ejemplo, fuentes, espaciado y señales sonoras) a los
documentos estructurados (por ejemplo, documentos HTML y aplicaciones XML). Separando
el estilo de presentación del contenido de los documentos, CSS2 [29] simplifica la creación y
mantenimiento de los sitios Web. CSS2 [29] se cimenta en CSS1[28] y, con muy pocas
excepciones, todas las hojas de estilo CSS1 [28] válidas son hojas de estilo CSS2 [29] válidas.
CSS2 [29] brinda soporte a hojas de estilo específicas para cada medio, de modo que los
autores puedan adaptar la presentación de sus documentos a los browsers visuales, a los
dispositivos sonoros, a las impresoras, a los dispositivos braille, de mano, etc. Esta
especificación también soporta el posicionamiento de contenidos, fuentes descargables,
disposición de la página, aspectos para la internacionalización, contadores y numeradores
automáticos, y algunas características relacionadas con la interfaz del usuario.

PAUTA 13. PROPORCIONE MECANISMOS CLAROS DE NAVEGACIÓN

Metadato -- Un metadato es un dato estructurado sobre la información, o sea, información
sobre información, o de forma más simple, datos sobre datos. Los metadatos en el contexto de
la Web, son datos que se pueden guardar, intercambiar y procesar por medio del ordenador y
que están estructurados de tal forma que permiten ayudar a la identificación, descripción,
clasificación y localización del contenido de un documento o recurso Web y que, por tanto,
también sirven para su recuperación.
Existen distintos modelos de metadatos, cada uno de ellos con distintos esquemas de
descripción. En estos modelos, cada objeto se describe por medio de una serie de atributos y
el valor de estos atributos es el que puede servir para recuperar la información. De forma
general, podemos encontrar metadatos referidos a:
• el contenido del recurso (título, tema, descripción, fuente, lenguaje, etc.)
• aspectos formales relacionados con la instanciación del recurso (tipo, tamaño, fecha,
formato, identificador etc.)
• una propiedad intelectual (autor, editor, colaboradores, derechos, etc.)
• información de la autentificación del documento o recurso
• información sobre el contexto (calidad, condiciones o características de acceso, uso,
etc.)
Estructuración de un sitio Web -- La estructuración de un sitio Web engloba todas las
decisiones referidas al rotulado y organización de categorías; organización del sitio mediante
un mapa, esquemas de organización y estructura de directorios; aspectos referentes a la
búsqueda como elección del motor de búsqueda y la política de indización de contenidos,
metainformación y metaestructuras. En particular, la estructuración de la información consiste
en la fragmentación de la misma en nodos que posteriormente se organizarán estableciendo
distintas categorías que atiendan a diferentes aspectos: relaciones jerárquicas, cronológicas,
secuenciales, espaciales, etc. Además de los nodos, se precisa la creación de metanodos con
información sobre otros nodos: sumarios, índices, tablas de contenido, etc.
Mapa Conceptual -- Un mapa conceptual es una forma especial de un diagrama Web para
explorar el conocimiento y poder compartir la información. Un mapa conceptual se compone
de nodos cada uno de los cuales contiene un concepto, ítem o cuestión y de enlaces entre
ellos. Los enlaces se etiquetan para denotar el tipo de relación mediante un símbolo.
Mapa de Navegación -- Un mapa de navegación proporciona una representación
esquemática de la estructura del hipertexto, indicando los principales conceptos incluidos en
el espacio de la información y las interrelaciones que existen entre ellos. Un mapa es, por
ejemplo, una representación completa (o resumida) del sitio Web para orientar al
lector/usuario durante el recorrido o para facilitarle un acceso directo al lugar que le interese e
incluso lo ayuda a contextualizar el conocimiento contenido en la propia aplicación.
Barra de Navegación -- Las barras de navegación son conjuntos de enlaces que permiten que
el usuario acceda a los contenidos que ofrece un sitio Web.
Dibujo ASCII art -- Dibujos usando solo letras y símbolos. Estas letras y símbolos son los
que conforman la parte imprimible del código ASCII. Este código contiene 128 elementos, de
los que los 32 primeros son los llamados caracteres de control, que no se pueden imprimir o
ver en la pantalla, ya que sirven para dar órdenes al ordenador como hacer una pausa,
interrumpir una operación, hacer sonar el altavoz, etc. El resto de los elementos pueden verse
e imprimirse, pues son los que representan las letras del alfabeto que se usan al escribir en
lenguaje Inglés, símbolos como apóstrofes, tildes, paréntesis, etc.
Dragones, hadas, paisajes, aviones, animales, fichas de ajedrez, los conocidos smileys, son
algunos de los dibujos realizados en el arte ASCII. Entre los usos que se les da a estos dibujos,
está el de servir de pantalla de presentación en sistemas que no soportan gráficos o servicios
de Internet que sólo funcionan en modo texto, como pueden ser telnet o IRC.
Referencias
[1] Abascal, J. Cañas, J. Gea, M. Gil, A. Lorés, J. Martínez Prieto, A. Ortega, M. Valero, P.
Vélez, M.: Introducción a la interacción persona-ordenador, Asociación Interacción Persona-
Ordenador, AIPO, ISBN: 84-607-2255-4, 2002.

[2] Apparao, V. Byrne, S. Champion, M. Isaacs, S. Jacobs, I. Le Hors, A. Nicol, G. Robie, J.

Sutor R., Wilson, C. Wood, L.: W3C Recomendación Document Object Model (DOM) Level
1 Specification, 1998. Disponible en http://www.w3.org/TR/1998/REC-DOM-Level-1-
19981001.

[3] Booch, G.: Handbook of software architecture, 2000-2007. Disponible en

http://www.handbookofsoftwarearchitecture.com/

[4] Brunet, P. Feigenbaum, B. Harris, K Laws, C. Schwerdtfeger, R. Weiss, L.:

Accessibility requirements for systems design to accommodate users with vision impairments,
IBM Systems Journal, vol. 44, pp. 445 – 466, ISSN:0018-8670, 2005.

[5] Buschman, F. Meunier, R. Rohnert, H. Sommerlad, P. and Stal, M: Pattern Oriented

Software Architecture: A System of Patterns. John Wiley and Sons, ISBN: 978-0-471-95869-
7, 1996.

[6] Bustos, B. V., Martín A. E., Cechich A. S.: Extendiendo MVC para Diseñar Interfaces de
Usuario Accesibles, CACIC 2008, La Rioja - Argentina, 2008.

[7] Consejería de Trabajo, Consumo y Política Social Secretaría Sectorial de Acción Social
Dirección General de Familia y Servicios Sectoriales: Diseño de páginas web accesibles,
Región de Murcia, ISBN 84-87926-36-3, 2003.

[8] Fundación SIDAR, Seminario SIDAR: Principios del Diseño Universal o Diseño para
Todos. Disponible en http://www.sidar.org/recur/desdi/usable/dudt.php

[9] Fundación SIDAR, Seminario SIDAR: Seminario Iberoamericano sobre Discapacidad y

Accesibilidad en la Red. Disponible en http://www.sidar.org/

[10] Galloni Balmaceda, M.: Diseño universal vs. Accesibilidad integral - ¿Utopía o
realidad?, 2005. Disponible en http://www.accesible.com.ar/recursos/diversidad/un-poco-de-
historia-sobre-la-Accesibilidad/

[11] Gamma, E. Helm, R. Johnson, R. Vlissides, J.: Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1995.

[12] Hoffman, D. Grivel, E.Battle, L.: Designing software architectures to facilitate accessible
Web Applications, IBM Systems Journal, vol. 44, pp. 467 – 483, ISSN:0018-8670, 2005.

[13] IEEE 1471-2000, IEEE Recommended Practice for Architectural Description for
Software-Intensive Systems, Institute of Electrical and Electronics Engineers, ISBN: 0-7381-
2518-0, 2000.

[14] Iglesias, A. Albouy, J: Legislación sobre Accesibilidad para la Sociedad de la

Información. Disponible en http://www.sidar.org/recur/direc/legis/index.php
[15] ISO 9241 -11 International Organization for Standardization/Technical Specification.
Ergonomics of Human-System Interaction - Guidance on usability, 1998.

[16] ISO/TS 16071 International Organization for Standardization/Technical Specification.

Ergonomics of Human-System Interaction - Guidance on Accessibility for Human-Computer
Interfaces, 2002.

[17] Larson, J. Interactive Software: Tools for Building Interactive User Interfaces. Yourdon
Press Computing Series, Prentice Hall, ISBN: 0-13-924044-6, 1992.

[18] Lorés, J.Granollers, T.: La Ingeniería de la Usabilidad y de la Accesibilidad aplicada al

diseño y desarrollo de sitios web, Asociación Interacción Persona-Ordenador, V Congreso
Interacción Persona Ordenador 3 - 7 de mayo de 2004 Universitat de Lleida, ISBN: 1-4020-
4204-3.

[19] Martín, A. Cechich, A and Rossi, G: Comparing Approaches to Web Accessibility

Assessment. Handbook of Research on Web Information Systems Quality, Idea Group Inc.,
C. Calero, Mª Á. Moraga, M. Piattini (Eds.), ISSN: 0950-5849, 2008.

[20] Microsoft Corporation: Microsoft Visual Studio 2008/.NET Framework 3.5, 2007.
Disponible en: http://msdn.microsoft.com/es-es/library/ms178093.aspx

[21] Montero, Y. Fernández, F.: Qué es la Accesibilidad Web, No Solo Usabilidad journal,
Nº 2, ISSN: 1886-8592, 2003. Disponible en:
http://www.nosolousabilidad.com/articulos/accesibilidad.htm

[22] Morant, T. P.: The command language grammar: a representation for the user interface
of interactive systems en International Journal of manmachine studies, vol. 15, 1981.

[23] Nielsen, J.: Usability Engineering. Academic Press Professional: Chestnut Hill,
Massachusetts, 1993.

[24] Pratt, T. Zelkowitz, M.: Lenguajes de Programación: diseño e implementación, Prentice-

Hall, 1998.

[25] Shawn Lawton, H.: Understanding Web Accessibility, en Constructing Accessible Web
Sites, Glasshaus, ISBN: 1904151000, Abril 2002. Disponible en:
http://www.macromedia.com/macromedia/accessibility/pub/acc_sites_chap01.pdf

[26] Sun Microsystems, JDKTM 5.0 Documentation: Javax.swing Class KeyStroke.

Disponible en: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/KeyStroke.html

[27] Vanderheiden, G.: Fundamental Principles and Priority Setting for Universal Usability,
en: Proceedings of Conference on Universal Usability (CUU) 2000, Association for
Computing Machinery, pp32-38. Disponible en:
http://trace.wisc.edu/docs/fundamental_princ_and_priority_acmcuu2000/

[28] W3C Recomendación Cascading Style Sheets, level 1, 1996, revisado 2008. Disponible
en http://www.w3.org/TR/REC-CSS1.

[29] W3C Recomendación Cascading Style Sheets Level 2 Revision 1 (CSS 2.1)
Specification, 2009. Disponible en http://www.w3.org/TR/REC-CSS2
[30] W3C Recomendación HTML 4.01 Recommendation, 1999. Disponible en
http://www.w3.org/TR/1999/REC-html401-19991224/.

[31] Ion, P. Miner, R.: W3C Recomendación Mathematical Markup Language (MathML™)
1.01 Specification, 1999. Disponible en http://www.w3.org/TR/REC-MathML.

[32] W3C Web Accessibility Initiative (WAI): Auxiliary Benefits of Accesible Web Design.
http://www.w3.org/WAI/bcase/benefits.hml

[33] W3C Web Accessibility Initiative (WAI): Introduction to Web Accessibility.

http://www.w3.org/WAI/intro/accessibility.php

[34] WCAG 1.0 Web Content Accessibility Guidelines 1.0. World Wide Web Consortium
(W3C) Recommendations, 1999. Disponible en http://www.w3.org/TR/WAI-
WEBCONTENT/

[35] WCAG 2.0 Web Content Accessibility Guidelines (WCAG) 2.0, World Wide Web
Consortium (W3C) Recommendations, 2008. Disponible en:
http://www.w3.org/TR/WCAG20/.

[36] Wikipedia Enciclopedia de Contenido Libre Disponible en:

http://es.wikipedia.org/wiki/dislexia

[37] Wikipedia Enciclopedia de Contenido Libre Disponible en:

http://es.wikipedia.org/wiki/pda