La
Intranet como soporte de las aplicaciones de gestión en la empresa: ¿una nueva
barrera para las personas con discapacidad?.
Elena García Barriocanal
Dpto.
de Ciencias de la Computación. Escuela Politécnica.
Universidad
de Alcalá de Henares.
Miguel Ángel Sicilia Urbán
José Ramón Hilera González
Dpto. de
Ciencias de la Computación. Escuela Politécnica.
Universidad
de Alcalá de Henares.
Resumen
La migración progresiva de las aplicaciones informáticas empresariales al entorno de las llamadas Intranets extendidas y el desarrollo de nuevas aplicaciones (incluyendo las de teletrabajo) sobre esta tecnología, está redefiniendo el puesto de trabajo en muchas organizaciones. En este entorno, el diseño de la interfaz de las aplicaciones, basada en los conocidos navegadores, puede constituirse en una nueva “barrera” para las personas con discapacidad a la hora de incorporarse al mundo laboral. Para intentar que esto no ocurra hay que proporcionar las herramientas y conocimientos necesarios al profesional de la informática para que pueda construir aplicaciones accesibles, basadas en recomendaciones de accesibilidad existentes, como las de la iniciativa WAI del W3C.
Palabras
clave.
Accesibilidad, Intranet, Herramienta de Autor, Discapacidad, Empleo, Teletrabajo.
1.
Accesibilidad
en Internet: recomendaciones, software de verificación y otros recursos.
Cuando se trata de acceder a la información
por medio de Internet, las personas que sufren algún tipo de discapacidad
(sobre un 15% del total de los españoles, según datos del INE del 86, véase
[1]) se encuentran hoy en muchas ocasiones con otra barrera más: la falta de
accesibilidad a este medio en un gran número de sitios Web. La dificultad de acceso a la información radica
principalmente en que los diseñadores de las páginas, o de los programas que
las generan, no han tenido en cuenta que no todas las personas acceden a la
información con los mismos medios. Como consecuencia, nos encontramos con una
gran abundancia de elementos que dificultan que las páginas HTML sean de fácil
acceso para cualquier persona (personas que, por ejemplo, utilizan lectores de
pantallas, teclados virtuales o líneas
Braille para “navegar”), configurando el lamentable panorama de una “aldea
virtual” llena de nuevas “barreras arquitectónicas”[1].
Para
intentar normalizar y estructurar los criterios de accesibilidad que los
diseñadores de páginas Web deben seguir, el organismo de estandarización de
Internet, World-Wide-Web Consortium
(W3C) cuenta con una importante iniciativa denominada WAI (Web Accessibility Initiative) [2], que propone y especifica normas
de diseño[2]
que hacen de las páginas web páginas accesibles. Esta iniciativa del W3C está
respaldada por miembros tan importantes como IBM, Microsoft, Lotus, SoftQuad o
la misma Casa Blanca [3]. Pero a pesar de ser el organismo oficial en cuanto a
normativas en Internet, el W3C no es la única institución dedicada a la
accesibilidad. Las listas de recursos de acceso a la información son muchas —
entre ellas cabe destacar la de la fundación Yuri Rubinsky [4] o las guías de
criterios de accesibilidad del Trace Center [5]. En España también hay
importantes organizaciones que se dedican a propagar y estudiar las normas de
accesibilidad para datos en Internet. Por ejemplo, SIDAR es una organización
que investiga estos aspectos y promueve y traduce las normas que dicta el W3C,
organizándose en grupos de trabajo a los que los profesionales interesados
pueden incorporarse libremente [6].
En
cuanto a herramientas software hay que mencionar que existen algunos editores
HTML y herramientas de autor, como HoTMetaL PRO, de la casa SoftQuad, que
ayudan al diseñador a construir páginas Web accesibles, gracias a que la propia
aplicación revisa el código HTML una vez escrito o mientras se escribe. Por
ejemplo, verifica que cuando se ha introducido una etiqueta IMG también se ha
utilizado un atributo ALT donde se incluya el texto descriptivo de la imagen
para que pueda ser interpretado por los lectores de pantalla que utilizan las
personas invidentes.
Para comprobar el grado de accesibilidad de las páginas también existen también algunos verificadores, por ejemplo, el conocido y fiable test Bobby, que categoriza las páginas puntuándolas con “estrellas”. Sólo aquellas que consiguen una “puntuación de 4 estrellas” pueden lucir el certificado de Bobby Approved, que garantiza la completa accesibilidad del diseño.
Pero tenemos que resaltar que
tanto las herramientas de diseño como los test de orientación sólo son válidos
en el caso de generar o verificar código HTML estático, es decir, no podemos
revisar con el test Bobby todas las posibilidades del código HTML que sea
generado dinámicamente a través de un programa de servidor, ni podemos escribir
código en un lenguaje de programación con herramienta alguna que nos garantice
que el resultado vaya a ser accesible.
Como acabamos de exponer, los
esfuerzos para crear una red Internet accesible para todo el mundo son muchos y
muy importantes, pero cabe preguntarse si todo el trabajo que se realiza en
esta área está teniendo el correspondiente impacto dentro de las empresas, es
decir, en las redes Intranet privadas.
2.
La
Intranet como nuevo paradigma de aplicación de gestión.
Internet e Intranet son las dos tecnologías básicas sobre las que se construyen la mayor parte de las aplicaciones informáticas modernas, y ambas llevan camino de convertirse en estándares de hecho en cuanto a plataforma de desarrollo e integración de aplicaciones. Nuestro centro de atención en este trabajo es la Intranet, que podemos definir como “el uso de las tecnologías de Internet dentro de la empresa con el objetivo de incrementar la productividad”; también podemos también decir de ella que constituye “una infraestructura básica para compartir la información y permitir su proceso en grupo dentro de la empresa ”. Aunque estas afirmaciones son válidas, trazan una línea de separación entre los mundos Internet e Intranet que no refleja la realidad; en la actualidad, deberíamos hablar más bien de modelos híbridos, en particular de la denominada “Intranet extendida”, es decir, de las aplicaciones internas de la empresa que, basadas en las tecnologías Internet, permiten un acceso controlado de los clientes a través de la Red (los primeros ejemplos de estas aplicaciones fueron los sistemas de distribución de UPS y Federal Express).
Los usos y aplicaciones de Internet e Intranet son bien diferentes: el usuario de Internet consume fundamentalmente contenidos, y las aplicaciones a él destinadas son fundamentalmente las de correo electrónico, los buscadores y los portales, mientras que las aplicaciones de las Intranets son las que soportan los procesos del negocio de las empresas en sus diferentes niveles: desde el operativo hasta las aplicaciones de apoyo a la toma de decisión. Estas aplicaciones se dividen a su vez en dos categorías: las informales (colaboración, publicación), y las formales, que sustituyen a las aplicaciones informáticas de todo tipo que tradicionalmente se construían mediante terminales “tontos” y más recientemente, mediante aplicaciones de tipo cliente/servidor con interfaz gráfica de usuario. La Figura 1 esquematiza estas diferencias.
Figura 1. Internet e Intranet: idéntica infraestructura pero
diferentes usos.
Por todo lo
dicho, creemos que debe prestarse una atención especial a la accesibilidad en
la Intranet, y en concreto, en las aplicaciones de gestión básicas (a veces
llamadas aplicaciones formales) sobre
esa arquitectura. Como dato significativo, un informe de Zona Research [7]
apuntaba ya en 1995 que el volumen de usuarios de la Intranet se estimaba en 16
millones de usuarios, en contraste con los 5 millones de usuarios “activos” de
la Red. Por otro lado, la empresa de investigación de
mercados INPUT estimó en un informe de 1998 (véase [8]) que el mercado de las tecnologías
Internet/Intranet en su conjunto se extendería en el período 1997-2002 con un
ritmo de crecimiento anual del 50%, y con un volumen de negocio estimado para
el 2002 de 300 billones de dólares, sólo para la parte de software y servicios.
Otro estudio similar, en este caso de Killen & Associates [9], cifraba en
1996 el volumen esperado, sólo del mercado Intranet, en unos 20 billones de
dólares para el 2000.
Según vaticinaron los informes citados, muchas grandes empresas han completado con éxito la migración de sus aplicaciones a la Intranet. Nissan, que completó su proyecto Intranet en el 96 [10], obtuvo un retorno de la inversión que se cifró en un 661% – aunque en gran medida se debió al ahorro en la impresión de fotos de los vehículos. Su nueva aplicación de empresa se basó en la metáfora de un “vecindario”, con un personaje animado, Mr. K, que representaba al fundador de la empresa, y proporcionaba a los empleados un entorno más intuitivo, agradable y dinámico para el desarrollo de sus tareas.
Según todo lo expuesto, es previsible que los procesos de migración de aplicaciones a la Intranet se sigan produciendo a lo largo de la próxima década. Cabe concluir que la aplicación Intranet estará presente en una gran cantidad de puestos de trabajo en el futuro próximo, lo cual hace especialmente importante el concienciar a las empresas de que esas nuevas aplicaciones deben estar preparadas también para las personas con discapacidad.
3. El Teletrabajo a través de la Intranet Extendida.
Teniendo en cuenta el gran impacto social de Internet, si queremos entrar en el análisis de los nuevos mercados de trabajo no podemos dejar de hacer mención al teletrabajo. Se entiende por teletrabajo una forma flexible de organización del trabajo en la que éste se realiza, con la ayuda de las tecnologías de la información y las comunicaciones, en un lugar distinto y alejado del que ocupa la organización o la persona para la que se realiza el trabajo. Esta nueva forma de trabajo ofrece grandes oportunidades a las personas con discapacidad [7] de cara a su inserción laboral, ya que se eliminan algunos posibles inconvenientes, como los problemas de transporte, accesibilidad, dependencia de horarios rígidos o adaptaciones del puesto de trabajo. Es obvio que las aplicaciones que soportan y que soportarán el teletrabajo son y serán en su mayoría aplicaciones típicas de la Intranet Extendida.
Por otro lado,
el perfecto campo de desarrollo para el teletrabajo son las actividades del
sector terciario, tales como las tareas relacionadas con la producción, manejo
y transmisión de información; y podemos resaltar que, según encuestas de la
División Nacional de Ciencia de los Estados Unidos [8], el 52% de la población activa con discapacidad en ese país de
perfil científico- técnico se dedica a este tipo de actividades: el 37% se dedica a labores de
investigación y desarrollo y el 25% se dedica a labores administrativas o de
gestión.
Pero para que el teletrabajo
tenga éxito y consiga difundirse en todos los sectores de la población hace
falta (además de la formación de las personas con discapacidad en campos
tecnológicos, y de la información y actitudes de los interlocutores sociales
—empresarios— para que sean conscientes de la tecnología disponible) superar
los obstáculos derivados de la falta de atención a las necesidades específicas
de las personas con discapacidad en el diseño tecnológico que pueden
comprometer el adecuado acceso de este colectivo a las tecnologías de la
información y las comunicaciones. Y uno de estos obstáculos puede ser la
inaccesibilidad de las aplicaciones que tienen como base la tecnología que
sustenta en mayor medida el teletrabajo, la Internet/Intranet.
4. La necesidad de iniciativas de difusión del desarrollo accesible en las modernas “fábricas de software”.
Aunque la accesibilidad de la tecnología Internet está recibiendo bastante atención, fomentada fundamentalmente por las actividades del grupo WAI del W3C, corremos el riesgo de olvidar que las aplicaciones Intranet de las empresas son las que están determinando la posibilidad de obtención de un puesto de trabajo en gran cantidad de sectores, y también a través de los nuevos medios como el teletrabajo.
Cabría preguntarse si la accesibilidad es hoy un requisito más en el desarrollo de las aplicaciones Intranet, o si las empresas están dispuestas a afrontar el coste añadido de garantizar las directrices del W3C a este respecto. A falta de datos específicos que respondan a estas preguntas, nuestro interés se centra en llamar la atención sobre este problema potencial, que puede convertirse en la “barrera arquitectónica” para las personas discapacitadas en el nuevo entorno de la sociedad de la información. Nuestra llamada de atención apunta a las organizaciones de desarrollo de software (“fábricas de software” en una acepción más moderna), y por extensión, a sus clientes, como responsables de que las aplicaciones garanticen la accesibilidad. Creemos que son dos los esfuerzos fundamentales que se deben iniciar en este sentido: el primero, la inclusión de la accesibilidad en la filosofía de calidad total de las empresas de desarrollo, y el segundo, la provisión de los medios necesarios para facilitar el desarrollo accesible por parte de los profesionales de la informática. A continuación ofrecemos algunas ideas básicas de cómo afrontar cada uno de estos dos esfuerzos.
4.1. Calidad Total y accesibilidad
El diseño accesible, como ya hemos dicho, ha
de extenderse en la cultura empresarial de la organización de desarrollo de
software. El objetivo sería la incorporación de la accesibilidad en la cultura
de esas empresas, y un medio eficaz podría venir de la mano de la denominada
“función de calidad” dentro de las mismas. La accesibilidad es o debería ser un
factor de calidad más, soportado por los mecanismos habituales a través de los
procedimientos y/o normas.
Las normas AENOR poseen un
capítulo relativo a este tema en el apartado de “Informática para la salud”, en concreto la norma 139.802:
“Aplicaciones informáticas para personas con discapacidad. Requisitos de
accesibilidad de las plataformas informáticas. Soporte lógico”, la que hace
referencia al software accesible. Pero no tenemos datos de si, en la práctica,
estas normas son tenidas en cuenta por los auditores.
Cabe recordar que el software accesible,
según Trace Center[3], es aquel
que es:
·
Utilizable
por cualquiera
·
Flexible
a las preferencias del usuario.
·
Simple
e intuitivo, de fácil comprensión por cualquiera.
·
Debe
proporcionar la información necesaria.
·
Resistente
a errores, minimizando las consecuencias de errores no intencionados.
·
Bajo
esfuerzo física, que se pueda utilizar sin fatiga.
A otro nivel, la
Comunidad Europea también se hace eco de este fenómeno evidente en cuanto al
nuevo perfil de los puestos de trabajo y emite comunicaciones donde se hace
hincapié en el uso de las nuevas tecnologías desde la perspectiva del acceso e
inclusión de las personas con discapacidad en la sociedad de la información. La
comunicación, que lleva por título “La dimensión social y del mercado de la
sociedad de la información. Prioridad para las personas – Las próximas etapas” (COM
(97) 397, de 17 de julio de 1997), hace referencia a una mayor colaboración
entre las industrias, los organismos de investigación y los representantes de
los usuarios para establecer especificaciones técnicas adaptadas a las personas
con discapacidad, transformar los resultados de la investigación y del
desarrollo en productos asequibles y proporcionar asistencia y formación para
impulsar su utilización.[12]
4.2. El puesto de trabajo del desarrollador de software y sus herramientas.
El aspecto más importante, si se quiere hacer extensivo el desarrollo de aplicaciones accesibles, radica en proporcionar al profesional de la informática la formación, concienciación y herramientas necesarias para que integre los conceptos de accesibilidad en sus actividades cotidianas. Estas herramientas se pueden integrar en diferentes puntos del ciclo de vida de los desarrollos informáticos, que, siguiendo el ciclo propuesto por Jacobson, Rumbaugh y Booch —Figura 2—, serían:
·
En
la captura de requisitos: siendo la accesibilidad un requisito no funcional.
·
En
el diseño: estudiando con atención en el diseño de las interfaces gráficas.
·
En
la implementación: realizando una codificación que ofrezca resultados a los que
todo el mundo pueda acceder.
·
En
las pruebas: para comprobar el éxito del diseño.
Figura 2: Ciclo de vida de un desarrollo software, según el Proceso Unificado
Nuestra pequeña aportación a la
solución del problema consiste en
esbozar el segundo de los objetivos que acabamos de describir: ¿qué ayudas
necesita el desarrollador para que el diseño accesible se integre sin problemas
en su labor cotidiana? Si consideramos la accesibilidad como una tarea más del
desarrollo, ésta habrá de contar con el soporte automatizado que ya tienen
otras tareas como la depuración, gestión de configuración, prueba,
documentación, etc. En concreto, el elemento clave para la productividad en el
desarrollo es la herramienta CASE, o mejor, el entorno CASE integrado.
La adaptación de los entornos CASE a la accesibilidad debe, por supuesto, tener en cuenta las normas de herramientas de autor del WAI y las normas de accesibilidad de los contenidos del W3C, estudiando de manera especial aquellos aspectos que pueden automatizarse. Así pues hay que revisar, aunque sea brevemente, algunas posibilidades de automatización de los temas de accesibilidad propuestos por el WAI [2]:
· Separación de Estructura y Presentación: Este punto es difícil de automatizar y atañe mas al juicio humano.
· Equivalentes textuales: Se puede automatizar (tanto con comprobación “intrusiva” – mientras se escribe –, como a posteriori) la existencia de textos alterativos para los elementos gráficos, por ejemplo.
· Páginas alternativas: Se puede dar soporte automático para la creación de páginas paralelas, bien por requerimiento del usuario o bien al inicio del proyecto mediante contenidos prediseñados (layouts).
· Acceso vía teclado: La existencia de atajos para el acceso por teclado es de fácil verificación automática, así como la existencia de un orden preestablecido para el uso del tabulador.
· Navegación: La inserción de elementos necesarios para una navegación sencilla para todos los usuarios (mapas de situación, búsquedas, barras de navegación,..) puede hacerse de forma automática durante la creación del proyecto, modificando los layouts.
· Comprensión: La necesidad de realizar exposiciones claras para que las personas con trastornos de lecto-escritura no se desorienten y comprendan lo expuesto es algo que se escapa a la automatización, pero se pueden utilizar algoritmos para medir el índice de facilidad de comprensión de nuestros textos, como el algoritmo de Gunning-Fog.
· Negociación de contenidos: Se puede verificar de forma automática la inclusión de etiquetas que permiten indicar el tipo de contenido a el idioma utilizado (type, hreflang).
· Refresco automático de páginas: El refresco automático de páginas se puede verificar automáticamente, igual que se puede verificar que se ofrezca la posibilidad al usuario de que dicho refresco no se realice de manera automática sino a través de un enlace a la nueva página.
Como acabamos de justificar, la automatización del entorno de desarrollo tiene mucho que aportar a la accesibilidad, y quizá incluso fuese conveniente ampliar los temas de accesibilidad que acabamos de mencionar para tener en cuenta los aspectos específicos de los entornos de desarrollo Web modernos como InterDev de Microsoft o WebSphere de IBM.
5. Una propuesta concreta: la herramienta de desarrollo como garantía de la accesibilidad.
Desde nuestra perspectiva de profesionales de
la informática, consideramos que el medio más eficaz a corto plazo para
introducir la accesibilidad en las aplicaciones software es el darle soporte
automatizado en los entornos integrados de desarrollo (IDE, integrated development environment). La
alternativa de introducir la verificación de la accesibilidad a posteriori, mediante programas
externos al entorno de desarrollo, causaría un coste adicional en los proyectos
que haría difícil su justificación.
Muchos entornos integrados de
desarrollo están preparados para que
otras empresas puedan ampliarlos mediante los llamados mecanismos de extensibilidad. Algunos entornos poseen lenguajes de
programación sencillos, internos al entorno, para automatizar sus tareas (por
ejemplo, el ObjectScripting de C++
Builder 5), mientras que otros proporcionan bibliotecas e interfaces
predefinidas para programas complementos (el ejemplo más conocido son los
Complementos – del inglés Add-In – de
la familia de entornos VisualStudio de Microsoft).
Para concluir, y a modo de
ilustración de lo expuesto, describiremos brevemente un prototipo de
integración de la accesibilidad en el entorno de desarrollo construido por los
autores (véase [13]). En concreto, la aplicación desarrollada se instala como
complemento (véase la Figura 3) en la barra de herramientas del entorno de
desarrollo Visual InterDev 6 de
Microsoft, y permite la verificación de algunas de las normas de desarrollo
accesibles definidas por el W3C desde dentro del mencionado entorno[4].
El complemento se construyó con las bibliotecas de extensibilidad de Microsoft
en lenguaje VisualBasic 6, y, aunque se trata sólo de una pequeña prueba de
concepto, permite verificar los criterios de accesibilidad en el código fuente
de ficheros HTML o ASP generados con MS InterDev añadiendo funciones al entorno
que hacen cumplir algunas de las guías de consulta o directrices de la reciente
recomendación sobre accesibilidad y herramientas de autor del WAI [14]:
·
2ª
directriz: “Generar marcas estándar”, no es algo que se pueda
automatizar, puesto que las páginas generadas automáticamente por MS Interdev
no pasan la comprobación del test Validator
del W3C.
·
3ª
directriz: “Soportar la creación de contenidos accesibles”. A este
respecto, sólo decir que Microsoft no garantiza la accesibilidad de los temas
que el usuario puede introducir en sus proyectos (según recomienda el punto de
verificación 3.3), pero hemos podido modificar las opciones de configuración
general del proyecto durante su creación con MS InterDev para que se puedan
incluir elementos cuya accesibilidad se a comprobado a priori. De forma similar hemos modificado dicho proceso de
creación para poder generar proyectos con lo que se conoce como layouts (formatos prediseñados de
navegación en las páginas) que sigan las normas de accesibilidad.
·
4ª
directriz: “Proporcionar los medios para verificar y corregir los elementos
inaccesibles”, este es el punto que más fácilmente se puede automatizar,
puesto que MS Interdev no modifica el código HTML que el programador introduce
manualmente. Así que aunque la
herramienta no verifica e informa al programador de los problemas de
accesibilidad, se puede conseguir que el complemento realice estas funciones y
le ayude a corregirlas. Una vez activado el complemento, la interfaz principal
del add-in (véase la Figura 4)
permite que el programador realice tres posibles acciones: verificar ficheros,
editar los elementos prediseñados u obtener ayuda específica de la
accesibilidad. Si lo que se desea es verificar la accesibilidad de ficheros,
una vez seleccionada la opción correspondiente, la siguiente pantalla permite
que el programador seleccione los elementos relativos a la accesibilidad que
quiere verificar en su código. Siguiendo las recomendaciones a este respecto,
cuando el prototipo detecta algún fallo en la accesibilidad del programa, avisa
al programador para que corrija el error (Figura 5).
·
5ª
directriz: “Integrar las soluciones de accesibilidad en la apariencia de la herramienta”. Para conseguir esta integración se
puede incorporar un editor añadido para mostrar los resultados de la
verificación, e indicar con diferentes colores las etiquetas HTML válidas desde
el punto de vista de la accesibilidad. Otra medida de integración consiste en
que el complemento tenga la misma apariencia (que se inserte en el entorno, que
siga el mismo estilo que el resto de elementos de este,...). A la hora de
diseñar el prototipo se han tenido en cuenta estas características.
·
6ª
directriz: “Potenciar la accesibilidad en la ayuda y documentación”. En
lo referente a esta cuestión hay que indicar que la documentación MSDN viene en
formato HTML precompilado, por lo que es muy difícil modificarla. No obstante,
se puede incorporar una sección de ayuda (con la correspondiente opción en la
interfaz principal) en el complemento, donde se promuevan los contenidos
accesibles.
Figura 3.
Vista del interfaz general del Complemento desarrollado sobre Visual InterDev
6.
Figura 4.
Interfaz principal del Complemento.
Figura 5.
Detección de un error y requerimiento de la actuación del usuario.
6. Conclusiones
Nuestra intención era la de apuntar soluciones y justificar esfuerzos necesarios en el terreno de la accesibilidad dentro de la Intranet. Lo que aquí hemos presentado es un modesto primer paso de lo que creemos debería ser un esfuerzo serio de adaptación de las herramientas de desarrollo web a las normas de accesibilidad, mientras esperamos a que los propios fabricantes se ocupen de ello. El resto de las acciones necesarias que hemos propuesto, las relativas a la inclusión de la accesibilidad en la cultura de la empresa, sobrepasan el ámbito del ingeniero informático, y requieren refinamiento por parte de otras disciplinas.
Creemos que el esfuerzo está suficientemente justificado por los datos que hemos aportado, y que debería extenderse a las nuevas interfaces de aplicaciones que posiblemente proliferen en un futuro próximo. Nos referimos a las aplicaciones soportadas sobre la telefonía móvil y otros dispositivos móviles, que están comenzando a despegar sobre modelos bastante similares al de Internet, como demuestra el conocido protocolo WAP y su lenguaje de marcas WML.
7.
Referencias
[1] Instituto Nacional de Estadística, “Encuesta sobre Discapacidades, Deficiencias y Minusvalías” 1986.
[2] W3C, “Web Content Accessibility Guidelines 1.0 W3C Recommendation”
5-May-1999, disponible en http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
[3] W3C, “World Wide Web
Consortium (W3C) Members”, disponible en http://www.w3.org/Consortium/Member/List.php3
[4] Lista de recursos mantenidos
por la fundación Yuri Rubinsky, disponible en www.webable.com
[5] Trace Research and Development Center, Universidad de Wisconsin,
en http://trace.wisc.edu/
[6] Seminario de Iniciativas sobre Discapacidad y Accesibilidad en la Red (SID@R), Real Patronato de Prevención y de Atención a Personas con Minusvalía, en www.sidar.org
[7] Zona Research, “Hitting the
Elephant - Intranet Use and Applications”, Intranet Application Survey,
1996.
[8] INPUT, “Internet and
Intranet Market Forecast, Worldwide 1997-2002”, INPUT, 1997, Cornwall
House, 55-77, High Street, Slough, Berkshire.
[9] Killen, "Intranets:
When it Comes to Making Money", Killen & Associates, Palo Alto, California,
October, 1996, disponible a través de http://www.killen.com/studies/index.htm.
[10] MULLICH, J., “Enjoying the
intranet ride: Mr. K's Neighborhood' provides 661 percent ROI for Nissan”,
PC Week, October, 1998.
[11] Jiménez Lara, A.: “El impacto de las nuevas tecnologías en el empleo de las personas con discapacidad.”, disponible en www.discapnet.org.
Arlington, 1998, disponible en http://www.nsf.gov/sbe/srs/stats.htm.
[13]García, E., Sicilia, M.A.: “Un análisis de la problemática de la accesibilidad de la tecnología Internet desde el punto de vista del empleo”, Congreso Iberolatinoamericano de Informática y Educación Especial, CIIEE 2000.
[14] W3C, “Techniques
for Authoring Tool Accessibility Guidelines 1.0” 3-Febrero-2000,
disponible en http://www.w3.org/TR/2000/NOTE-ATAG10-TECHS-20000203/
[15]
Toledo, P.: “Estudio sobre la
accesibilidad de las web de las universidades españolas”, Congreso
Iberolatinoamericano de Informática Educativa Española, CIIEE 2000